Gestion et approvisionnement d'un stock. Cas de l'Hôpital principal de Dakar

SOMMAIRE

SOMMAIRE - 1 -

DEDICACES - 4 -

Ce travail est dédié : - 4 -

REMERCIEMENTS - 5 -

AVANT PROPOS - 6 -

INTRODUCTION - 7 -

PREMIRE PARTIE : CONCEPTS DE MERISE - 8 -

I .DEMARCHE DE MERISE - 9 -

I.1 Introduction - 9 -

I.2 Présentation de MERISE - 10 -

I.2.1 L'esprit Merise - 10 -

I.2.2 Les cycles de Merise - 10 -

Niveaux d'abstraction - 11 -

Cycle de décision - 11 -

Temps Hiérarchie des décisions - 11 -

Cycle de vie - 11 -

I.3 Les démarches de Merise - 12 -

I.3.1 Principes de Merise - 12 -

Cycle d'abstraction - 13 -

I.3.2 La démarche par niveaux - 14 -

Traitements - 19 -

Contenu - 19 -

Quoi - 19 -

MOT - 19 -

MLT - 19 -

O - 19 -

I.3.3 La démarche par étapes - 20 -

II. LES PHASES D'UNE ÉTUDE MERISE - 21 -

II.1 Enchaînement des modèles dans la démarche par étapes - 23 -

II.2 Enchaînement des modèles dans la démarche par niveaux - 24 -

DEUXIEME PARTIE : ETUDE PREALABLE - 29 -

I. PRESENTATION GENERALE DE LA SOCIETE - 30 -

- 1 -

I.1 HISTORIQUE DE L'HOPITAL PRINCIPAL DE DAKAR - 30 -

L'entrée de l'Hôpital Principal au début du 20^ème siècle - 37 -

L'Hôpital Principal et en arrière plan, la caserne des Madeleines - 37 -

L'Hôpital Principal aujourd'hui. - 37 -

Le pavillon Saint-Louis. Ce bâtiment centenaire conserve son charme d'époque - 38 -

I.2 SITUATION GEOGRAPHIQUE - 38 -

I.3 Mission de H.P.D - 40 -

I.4 Organisation - 40 -

I.5 Signification des termes utilisés - 41 -

I.6. ORGANIGRAMME HPD - 42 -

II.ETUDE DE L'EXISTANT - 43 -

II.1. DESCRIPTION DES DIFFERENTES PROCEDURES - 43 -

II.1.1. PROCEDURE DE GESTION DE STOCK - 43 -

II.1.2. PROCEDURE APPROVISIONNEMENT - 44 -

II.2. Délimitation du champ d'étude - 45 -

II.3. DIAGRAMME ACTEUR /FLUX - 45 -

II.3.1. Définition et concepts - 45 -

II.4. MODELE CONCEPTUEL DE TRAITEMENT (M.C.T) - 50 -

II.4.1. Définition - 50 -

II.4.2. Formalisme - 51 -

II.4.3. MODELE CONCEPTUEL DE TRAITEMENT (M.C.T) GESTION STOCK - 55 -

II.4.4. M.C.T APPROVISIONNEMENT - 57 -

II.5. Modèle Conceptuel de Données (MCD) - 58 -

II.5.1. Définition - 58 -

II.5.2. Formalisme - 62 -

II.5.3. Quelques règles de gestion - 62 -

II.5.4. Dictionnaire de données (D.D) 71

II.5.5. Modèle Conceptuel des données (M.C.D) 73

TROISIEME PARTIE : ETUDE DETAILLEE 74

I. MODELE ORGANISATIONNEL DE TRAITEMENT (M.O.T) 75

I.1. Définition et concepts 75

I.1.1. Définition 75

I.1.2. Concepts 75

I.2. Formalisme 79

I.3. DIAGRAMME DE DESCRIPTION DES PF 80

I.3.1. MODELE ORGANISATIONNEL DE TRAITEMENT (M.O.T) GESTION STOCK 80

I.3.2. MODELE ORGANISATIONNEL DE TRAITEMENT (M.O.T) APPROVISIONNEMENT 82

I.4. Tableau descriptif des PF 87

I.4.1. Procédure : Gestion de stock 87

- 2 -

I.3.2. Procédure : Approvisionnement 88

II.5. FICHE DESCRIPTIF DES PF 89

I.5.1. GESTION DE STOCK 89

I.5.2. APPROVISIONNEMENT 90

II.LES ECRANS 94

III. DIAGRAMMES DE REPARTION DES TACHES HOMME/MACHINES 107

III.1 DIAGRAMME DE REPARTITION DES TACHES HOMMES MACHINES POUR L'APPROVISIONNEMENT 110

IV. MODELE EXTERNE ET VALIDATION 119

IV. 1. MODELE EXTERNE 119

IV.1. a) Définition 119

V.2. MODELE EXTERNE RELATIF 120

V.2.1. MODELE EXTERNE RELATIF A LA LIVRAISON : Ecran 1, PF1 120

V.2.2. MODELE EXTERNE RELATIF A LA DISTRIBUTION : Ecran 2, PF2 120

V.2.3. MODELE EXTERNE RELATIF A L'ETAT MENSUEL DES DEPENSES : Ecran 3, PF3 121

V.2.4. MODELE EXTERNE RELATIF AU BON D'ACHAT : Ecran 4, PF1 121

V.2.5. MODELE EXTERNE RELATIF AU BON DE COMMANDE : Ecran 4, PF2 122

V.2.6. MODELE EXTERNE RELATIF A LA FACTURE : Ecran 6, PF5 122

V.2.7. MODELE EXTERNE RELATIF A L'APPEL D'OFFRE : Ecran 7, PF6 123

V.2.8. MODELE EXTERNE RELATIF A UNE COMMANDE : Ecran 8, PF8 123

V.2.9. MODELE EXTERNE RELATIF AU BON DE RECEPTION : Ecran 9, PF9 124

V.2.10. MODELE EXTERNE RELATIF AU BON DE PAIEMENT : Ecran 10, PF10 124

V.2.11. MODELE EXTERNE RELATIF AUX PREVISIONS ANNUELLES DES SERVCES : Ecran 11,

PF12 125

V.2.12. MODELE EXTERNE RELATIF A L'ACHAT ANNUEL : Ecran 12, PF13 125

VI. VALIDATION 125

VI.1. Validation des objets 125

VI.2. Validation des propriétés 127

VI.3. Validation des attributs et des cardinalités 130

VII. MCD Validé 133

VIII. MLD 134

VIII. 1. Définition Règles de passage du MCD au MLD 134

1ère Règle : Relation de type « Père-Fils » 134

2ème Règle : Relation plusieurs à plusieurs 135

3ème Règle : Les autres cas 136

VIII.2. MLD DU MCD VALIDE 137

CONCLUSION 140

BIBLIOGRAPHIE 141

WEBOGRAPHIE 141

ANNEXE 142

- 3 -

DEDICACES

Ce travail est dédié :



Au Seigneur tout puissant ;

A Mes parents feu Simon BUKENGUJE et feu M. Margueritte MPFANUGUHORA ;

A ma tante Angélique MBONIHANKUYE ;

A la famille Didier Garcia;

A SOS Kinderdorf International ;

A mon oncle Jérémie NGENDAKUMA ;

Au gouvernement du Burundi ;

Au corps professoral de l'I.S.I ;

A La famille Cariton NDABASHIKIRE ;

A mes frères et soeurs

- 4 -

REMERCIEMENTS

Je tiens à exprimer ma profonde gratitude aux personnes suivantes qui ont et qui oeuvrent pour leur soutient moral, matériel et intellectuel au cours de ma formation :

Mes parents feu Simon BUKENGUJE et feu M. Margueritte MPFANUGUHORA qui m'ont mis à l'école, que Dieu vous accueille dans son paradis ;

La famille Sylvain NZIGAMIYE pour son amour, son soutient qu'elle ne cèsse de me témoigner ;

Famille Jérémie NGENDAKUMANA pour son soutient;

La famille Didier Garcia pour son amour inéstimable ;

La famille Cariton NIBASHIKIRE pour son effort et amour qu'elle aménage envers moi afin d'avoir un avenir meilleur;

La famille Evariste MIBURO BUNDOYI pour son accueil et mon intégration à Dakar ;

La famille Pontien NDABASHINZE pour son accueil et mon intégration à Dakar ;

SOS (Save Our Soul) children village qui a pris la relève après le décès de mes parents;

Helman Gmeiner le fondateur de SOS Children Village d'avoir fondé SOS Kinderdorf International.

- 5 -

AVANT PROPOS

Ce document parle de la gestion de l'Hôpital Principal de Dakar et spécialement la gestion du Département Administratif et Logistique. Il se focalise surtout sur l'approvisionnement et la gestion de stock de cet institut.

C'est un document conçu à bases des connaissances que j'ai acquises durant deux ans de formation à l'ISI (Institut Supérieur d'Informatique).

Vous y trouverez le maximum des informations que nous avons pu collecter durant les trois mois de stages passés dans cet hôpital et la solution que nous propons pour le problématique identifié.

Néanmoins, ce document n'étant pas la Bible ou le Coran, et étant donné qu'en analyse le modèle acceptable et celui qui est accepté par la majorité ; vos contributions dans ce travail sont les bienvenues. N'hésitez pas de nous contacter au courriel suivant : [e-mail].

- 6 -

INTRODUCTION

En Janvier 1975 Ed Roberts invente le premier micro-ordinateur l'Altair commercialisé en kit et il fallait beaucoup d'habilité pour le monter.

Paul Allen né en 1953, alors employé par Honeywell et Bill Gates né le 28 Octobre 1955 alors étudiant en deuxième année à Harvard étaient des amis tous les deux passionnés de l'informatique ; deux hackers. L'article de Popular Electronics sur l'Altair les incita à programmer un interpréteur Basic pour ce micro-ordinateur : Ce sera le premier langage de programmation pour microordinateur et la base de la programmation.

Grâce à ces deux hommes, le monde connaît la programmation jusqu'à nos jours et c'est grâce à ces deux hommes que le monde connait des progrès en ce qui concerne l'informatisation des systèmes d'informations.

En effet, l'informatisation et l'automatisation procurent beaucoup d'avantages dont :

réduire les tâches manuelles, donner la situation réelle de son Entreprise, diminuer la fraude, diminuer les fiches d'enregistrements manuelles, ect

C'est pour cela que le monde d'aujourd'hui se tourne vers l'informatique en général et l'informatisation en particulier.

Pour ce faire, l'Hôpital Principal de Dakar veut informatiser sa gestion de stock et son approvisionnement afin de se conformer au monde d'aujourd'hui et profiter ainsi des avantages d'informatisation et d'automatisation ci_haut cités.

Néanmoins, le parc informatique de l'Hôpital Principal Comprend un nombre important de machines mais l'automatisation des tâches reste encore un grand processus. C'est pour cela que notre travail consiste à automatiser la gestion de stock et l'approvisionnement.

- 7 -

PREMIRE PARTIE : CONCEPTS DE MERISE

- 8 -

I .DEMARCHE DE MERISE

I.1 Introduction

Merise est une méthode globale de troisième génération dont l'approche est systémique.

Une méthode globale prend en compte l'ensemble des aspects d'un processus d'informatisation et pas seulement un point particulier (schéma directeur, conduite de projet, conception et réalisation).

La troisième génération des méthodes d'analyse démarre à la fin des années soixante-dix.

Comme toutes les évolutions, elle intègre les nouveautés technologiques matérielles et logicielles, notamment dans le domaine des concepts liés aux bases de données. C'est aussi le triomphe de la modélisation et l'adoption unanime du modèle entité-relation. La mise en oeuvre de telles méthodes est facilitée par le développement des ateliers de génie logiciel permettant d'automatiser partiellement l'élaboration des modèles.

Enfin Merise est une méthode systémique. Ces méthodes passent par la modélisation du système étudié pour mieux le comprendre. Elles prennent en compte les interactions entre les éléments constitutifs et leur environnement extérieur, en fonction de leur organisation et de leur objectif. Ces méthodes fonctionnent par niveaux successifs d'abstraction, aussi bien du point de vue statique (les données) que du point de vue dynamique (le temps et les traitements). Certaines de ces méthodes proposent des modèles séparés (étude statique puis dynamique), d'autres des modèles qui synthétisent les deux aspects.

- 9 -

Une tendance forte en ce début de millénaire consiste à choisir MERISE pour la modélisation des données, y compris à travers un langage de modélisation comme UML (Unified Modeling Language). La modélisation des traitements quant à elle, est explorée à travers les diagrammes comportementaux d'UML.

I.2 Présentation de MERISE

I.2.1 L'esprit Merise

MERISE est une méthode d'analyse systémique destinée à concevoir et à développer des systèmes d'information. Elle conduit à recenser et à décrire toutes les informations nécessaires au bon fonctionnement de l'entreprise, que ces informations soient traitées manuellement ou à l'aide des machines. Cette description est instantanée (elle concerne les informations actuellement traitées) mais elle se veut également prospective dans la mesure où les informations, qui ne deviendront pertinentes que quelques années plus tard, doivent être recherchées et recensées. Elle est aussi objective en permettant la confrontation des points de vue des différents acteurs. La vision fonctionnelle et globale de la direction peut ainsi être rapprochée, avec profit, de celle plus sensible aux difficultés et aux cas particuliers de fonctionnement des "acteurs du terrain". De façon à rendre ces descriptions facilement et rapidement compréhensibles, la méthode fait appel à un formalisme spécifique qui ne doit cependant pas être considéré comme un carcan. Dans ce domaine comme dans d'autres, la liberté d'action reste grande. Ceci a l'avantage de faciliter la communication et de rendre possible l'emploi de techniques de validation et de vérification de cohérence.

I.2.2 Les cycles de Merise

Trois cycles concourent à l'étude d'un système d'information et permettent d'en situer les étapes : le cycle de vie, le cycle de décision et le cycle d'abstraction.

- 10 -





Cycle d'abstraction

Niveaux d'abstraction



Cycle de décision



Temps Hiérarchie des décisions



Cycle de vie

Le cycle de vie ou démarche

Il permet de décrire la vie du système d'information. MERISE distingue trois périodes :

La conception du système d'information qui aboutit à la conception détaillée des spécifications fonctionnelles et techniques, (Gestation + Conception)

La réalisation qui consiste à produire des programmes et des consignes d'utilisation correspondant aux spécifications détaillées, (Développement, Mise en oeuvre)

La maintenance du système d'information qui a pour objectif l'adaptation aux évolutions de son environnement. (Exploitation + Evolution)

- 11 -

Le cycle de décision ou maîtrise

Il concerne les différents choix qui sont effectués tout au long du cycle de vie. La plupart de ces décisions marquent la fin d'une étape et le début d'une autre. Pour chaque étape Merise prévoit trois actions : préparer, exécuter, contrôler.

Le cycle d'abstraction ou raisonnement

Il offre les concepts nécessaires à la description du monde réel dans le système d'information.

On y trouve les quatre (ou trois) niveaux d'abstraction de MERISE (conceptuel, organisationnel, logique et physique).

La nécessité des cycles

Une méthode sans cycle de vie est inimaginable car il faut nécessairement des démarches de durée limitée pour bâtir des modèles (abstraction) et prendre des décisions.

I.3 Les démarches de Merise

I.3.1 Principes de Merise

Merise se caractérise par une double vision (globale et partielle) mais surtout par une double démarche : par niveaux et par étapes.

La démarche par niveaux a pour objectif de formaliser le futur système tant sous ses aspects techniques et organisationnels que sur le plan des règles de gestion et de la stratégie d'entreprise.

L'objectif de la démarche par étapes est de hiérarchiser les décisions au cours de la conception, du développement, de la mise en oeuvre et de la généralisation d'un nouveau système d'information mais aussi lors de son évolution. (C'est de la conduite de projet).

- 12 -

Cette double démarche permet de maîtriser les risques (coûts, délais, effets sur le personnel) et les enjeux (efficacité, productivité).

Elle favorise également l'introduction de nouvelles technologies (bases de données relationnelles ou objets, systèmes experts...) et apporte une aide au règlement des problèmes sociaux, économiques ou techniques (réarrangement des postes de travail, responsabilisation...). Enfin, elle facilite l'évolution du système d'information en redéfinissant les modalités de pilotage et en prenant en compte les besoins nouveaux.



Cycle d'abstraction

Physique

Logique

Maintenance et Evolution

Généralisation

Mise en oeuvre

Organisationnel

Production logicielle

Étude technique

Étude détaillée

Conceptuel

Étude préalable

Schéma directeur

Cycle de décision

Gestation

Conception

Développement

Mise en service

Exploitation

Décision sur Décision sur le

le contenu développement

Cycle de vie

- 13 -

I.3.2 La démarche par niveaux

C'est un des points forts de MERISE par rapport aux méthodes antérieures. Lors d'une étude d'informatisation, il faut répondre à des préoccupations de nature très différentes comme la définition des données et leur localisation, la définition des fonctionnalités et la répartition des traitements entre l'homme et la machine, les choix de matériels et de logiciels ... Merise propose de rassembler ces préoccupations en niveaux d'intérêts homogènes, correspondant à différents niveaux d'abstraction.

Merise retient quatre niveaux d'abstraction :



Le niveau

organisationnel

Le niveau physique ou opérationnel

Le niveau conceptuel

Le niveau logique

Système d'information

informatisé

Système d'information

organisationnel

Système d'information

- 14 -

Les deux premiers niveaux correspondent à la description du Système d'Information et de son organisation, les deux derniers à la conception du Système d'Information Informatisé (SII).

Au sein du SI, le niveau conceptuel exprime les choix fondamentaux de gestion indépendamment des moyens à mettre en oeuvre alors que le niveau organisationnel exprime les choix d'organisation des ressources humaines, matérielles et financières.

Au sein du SII, le niveau logique exprime les choix de moyens et ressources informatiques sans se soucier de leurs caractéristiques techniques précises alors que le niveau physique prend en compte ces spécificités.

Mais, à la différence de l'ANSI SPARC qui privilégie les données, MERISE propose une approche parallèle pour les données et les traitements, les études séparées pouvant même être menées par des équipes différentes. A chaque niveau correspondent des modèles de données et de traitements.

Le niveau conceptuel

Le niveau conceptuel permet de décrire l'ensemble des données et traitements nécessaires à l'activité de l'entreprise à partir des choix et objectifs de gestion retenus. Il oblige les décideurs à se prononcer sur les orientations et les choix de gestion tout en fixant le cadre global du projet.

Cette approche facilite la mise en évidence des interfaces entre projets, pousse à la cohérence des systèmes d'information et permet d'appréhender les conséquences des choix de gestion. Ce niveau est indépendant des choix d'organisation et des choix techniques. Il rend compte des phénomènes les plus stables dans la vie de l'entreprise.

Il s'agit de répondre à la question « Quoi ? ».

Le Modèle Conceptuel de Données (MCD) constitue la description des informations significatives sur lesquelles repose le système d'information. Il fait appel au formalisme entité -association aussi appelé objet - relation ou individuel. C'est la traduction du monde dans lequel évolue l'entreprise en termes d'individus (ou entités) et de relations.

- 15 -

Par exemple : des clients (entité) commandent (relation) des fournitures (entité).

Le Modèle Conceptuel de Traitement (MCT) décrit les entités par leurs sollicitations et par les réactions qu'elles déclenchent au sein du système d'information. Ce sont donc les traitements dont elles sont les causes ou les conséquences qui sont abordés. Ceci se fait en termes d'événements, de synchronisations et d'opérations.

Ainsi, le fait qu'un contribuable (entité) paye son premier tiers hors délais (événement) après avoir été sollicité une seconde fois par le trésor public (événement) entraîne dès réception (synchronisation) la mise à jour de son dossier (opération).

La synchronisation, qui précise la coexistence dans le temps de plusieurs événements, décrit une condition de déclenchement de l'opération. Cette dernière, quant à elle, décrit l'enchaînement d'actions élémentaires à effectuer (consultation ou tri de table, calculs, contrôles, etc.) pour obtenir un résultat (édition d'une facture, d'un rappel, etc).

Le niveau organisationnel

C'est la réalité telle qu'elle est perçue par les acteurs qui sont exprimée à ce niveau. On y apporte les réponses aux questions « QUI ? » ( l'homme ou la machine), « OÙ ? » et « QUAND ? ». Ce niveau prend en compte l'organisation et les contraintes de l'entreprise mais demeure indépendant des choix techniques. C'est donc à ce niveau que se décide ce qui sera effectivement informatisé.

Le Modèle Organisationnel des Données (MOD), précise quelles sont les données retenues pour le système futur, leur répartition et leur localisation par site, ou encore leur confidentialité pour chaque intervenant. C'est à ce niveau que s'effectue le passage des données aux informations, leur quantification et la détermination de leur durée de vie. Il y a « transformation » des données en informations mais pas enrichissement. La création de redondances ou de données calculées à des fins d'optimisation n'est pas une création d'informations nouvelles !

- 16 -

Le Modèle Organisationnel de Traitements (MOT), permet de décrire d'une façon globale puis d'une façon détaillée les choix effectués en matière d'organisation et de fonctionnement des services, les modes d'automatisation retenus, les postes de travail et les tâches associées. Il précise les ressources humaines et matérielles mobilisées avec leur organisation dans le temps et l'espace.

Le niveau logique

Le niveau logique exprime les choix de moyens et ressources informatiques sans se soucier de leurs caractéristiques techniques précises. Il apporte les premières réponses à la question « COMMENT ? »

Le Modèle Logique de Données (MLD), est issu des modèles conceptuels puis organisationnel de données. Il est traduit du MOD dans un formalisme compatible avec un choix de classe ou de famille (système de fichiers classique, bases de données navigationnelles, relationnelles ou objets).

Ce modèle est ensuite quantifié, valorisé et optimisé en fonction des spécificités de l'outil associé pour devenir le modèle physique. La dérivation du MCD en MLD se fait par de simples règles de passage en fonction de la famille choisie.

Le Modèle Logique de Traitement (MLT), définit comment les tâches informatisables décrites dans le MOT sont conçues en terme de logiciel. Le MLT se préoccupe d'une vision interne des moyens que l'informaticien utilise pour construire les applications demandées : enchaînement des transactions, découpage en modules. Il tient compte des ressources et contraintes matérielles et logicielles et des principes généraux de l'ergonomie. L'informaticien se demande comment il va concevoir son logiciel par rapport aux fonctionnalités souhaitées.

- 17 -

Le niveau physique ou opérationnel

C'est une représentation des moyens qui vont effectivement être mis en oeuvre pour gérer les données et réaliser les traitements.

Il permet de décrire les solutions techniques retenues pour prendre en compte les aspects suivants :

Performances, conditions d'accès, mode de traitement et d'enregistrement, matériels, logiciels et utilitaires choisis. Il répond lui aussi à la question « COMMENT ? ».

Le Modèle Physique de Données (MPD), est la traduction du modèle logique. Il y a passage d'une classe de solutions à un élément de cette classe. Un modèle navigationnel entraîne l'utilisation d'un système de gestion de bases de données (SGBD) tel qu'IDS2 ou SOCRATE. Un modèle relationnel, quant à lui, amène l'usage d'un SGBD relationnel comme INGRES, ORACLE ou INFORMIX. Les données sont décrites et manipulées à l'aide des langages spécifiques au système choisi (langage de description de données et langage de manipulation de données). Les fonctionnalités du système peuvent permettre d'optimiser le modèle en créant des index et des structures de stockage adaptées.

Le Modèle Opérationnel ou Physique de Traitement (MOpT ou MPT), est constitué par l'ensemble des programmes décidés au niveau logique en fonction des moyens mis à disposition.

Ces programmes sont, suivant la terminologie technique adoptée, désignés par les termes transactions, programmes, unités de traitement .... Il n'y a pas de formalisme particulier de représentation. On y décrit l'architecture des programmes (structures et algorithmes) qui vont activer les différentes tâches dévolues à l'ordinateur (menu de l'application, sécurité, procédures fonctionnelles, sauvegardes, etc.) à l'aide d'un pseudo langage. La programmation proprement dite n'a lieu que lors de la réalisation.

Les modèles par niveau d'abstraction

Les niveaux intermédiaires sont souvent fusionnés sous le terme de « Niveau organisationnel et logique », et on retient uniquement les modèles suivants :

- 18 -

le MLD pour les données et le MOT pour les traitements. L'aspect organisationnel des données est alors traité avec le niveau logique tandis que l'aspect logique des traitements est étudié au niveau physique.

NIVEAU	Données	Traitements	Questions	Contenu		S I I
CONCEPTUEL	MCD	MCT	Quoi	- Informations manipulées - Règles de gestion - Enchaînement des activités
ORGANISATIONNEL	MOD	MOT	Qui Quand Où	- Partage des tâches homme/machine - Temps réel ou différé - Traitement unitaire ou par lots - Répartition géographique des traitements - Organisation des données retenues - postes de travail	S I
LOGIQUE	MLD	MLT		- Classe de mise en oeuvre des données - Découpage en modules et transactions	O

- 19 -
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

PHYSIQUE ou	MPD	MOPT	Comment	- Enregistrements	S
OPERATIONNEL
				- Ecrans, états	I
				- Programmes ou unités de traitement
				- Matériels
				- Réseau
				- Logiciels

I.3.3 La démarche par étapes

Les étapes du processus d'informatisation couvertes par MERISE sont : le schéma directeur

l'étude préalable

l'étude détaillée

l'étude technique

la production logicielle

la mise en oeuvre

la généralisation

la maintenance et l'évolution

Au sein du Ministère de la défense, la conduite de projet n'est pas abordée par Merise mais avec la méthode SDM/S .

- 20 -
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

II. LES PHASES D'UNE ÉTUDE MERISE

Connaître les principes, les démarches et les modèles de Merise constitue une excellente entrée en matière, mais ne suffit pas pour se lancer dans sa première analyse. Encore faut-il savoir comment et dans quel ordre utiliser les modèles. C'est l'objet de cette partie.

Une analyse est toujours entreprise dans l'objectif d'informatiser ou « réinformatiser » tout ou partie du système d'information étudié. Elle est donc tournée vers le futur. Doit-on pour autant faire table rase du passé ? Une telle décision conduit à prendre de nombreux risques pour chaque intervenant :



Le maître d'oeuvre :

réitérer des erreurs,

faire des oublis,

ne pas coller aux besoins des utilisateurs, dépasser les objectifs,

ne pas respecter les coûts et les délais



Le maître d'ouvrage :

ne pas savoir où il va, bouleverser son organisation et son fonctionnement sans en maîtriser les conséquences humaines et financières,

ne pas obtenir une livraison conforme à ses attentes et celles des utilisateurs

Par conséquent toute analyse commence par l'étude du système d'information existant et c'est à partir des résultats de ces travaux que sont élaborés les premiers modèles Merise, puis certains modèles formalisant les propositions pour le futur système, et enfin l'ensemble des modèles détaillant la solution retenue.

- 21 -

L'enchaînement des modèles qui en découle est présenté ci-après, avec les phases intermédiaires de validation, d'abord sous l'angle de vue de la démarche par étapes puis sous celui de la démarche par niveaux. Il s'agit seulement d'angles de vue différents puisque Merise procède de la double démarche. Le schéma II.1. est à comprendre pas à savoir.

- 22 -

II.1 Enchaînement des modèles dans la démarche par étapes



Etude

Préalable

Etude Détailée

Etude Technique

Extension du MCD

Si MOD

MCD Provisoire

MCD Existant

MCD futur

Confrontation

Critique de l'existant

MCD définitif

MCD validé

Analyse des flux

MPD

MCD enrichi

MLD

Rapport

Confrontation détaillée

Tâches conversationnelles

MOT futur simplifiés

MCT futur

MOT Existant

MCD - MOT vues externes

MOT enrichis

MOT définitifs

MPT

MLT

Nouveaux besoins + contraintes + Objectifs

Tâches

Extension MCT

- 23 -

Conceptuel

Organisat ionnel

Logiqu

	Bilan et critique · Contraintes · Objectifs-orientations · Nouveaux besoins · Critques de l'existant		·	Senari futurs MCDs futurs MCTs futurs Validation Choix de solution			Description conceptuelle MCD étendu MCT complet

o MCD existant



Formalisation et synthèse

o Dictionnaire ses données

o DCI ou MOTs
existants

o Analyse des flux

Description organisationnelle MOTs niveau global

Choix

MOTs niveau détaillé

Validation MOT - MCD par les vues externes et obtention du MCD définitif

Passage au MLD (avec contraintes MOD)

Physiqu



II.2 Enchaînement des modèles dans la démarche par niveaux

Les phases d'étude sont disposées par rapport à une courbe qu'on appelle "courbe du soleil" et qui représente le cheminement du processus de conception et d'étude à mettre en oeuvre.



Recueil de l'existant

· Définition du champ d'étude

· Collecte de l'existant

· Système documentaire

· Entretiens

· MPD, MPT si existants
Délimitation du champ d'étude

Description opérationnelle

Scénario de développement et de mise en oeuvre

Confidentialité, ergonomie, outils MPD

MOpT

Dossier des choix

- 24 -
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

Courbe du soleil Pour cela, MERISE préconise de partir des niveaux physique et logique existants. Les éléments recueillis permettent alors de bâtir un modèle conceptuel ne conservant que les grandes finalités de l'entreprise, indépendamment des contraintes organisationnelles ou physiques.

Cette vue synthétique permet de passer au système futur en intégrant de nouveaux éléments de gestion.

On se situe alors au niveau conceptuel de l'état futur; la description est ensuite complétée par des composantes organisationnelles pour élaborer le niveau organisationnel et logique du système futur. Enfin, l'introduction des contraintes techniques au niveau physique permet de réaliser le système futur.

Organisationnel



Recueil de l'existant

Définition du champ d'étude Collecte de l'existant

Système documentaire

Entretiens

MPD, MPT si existants



Délimitation Champ d'étude

Formalisation et synthèse

MCD existant

Dictionnaire des données DCI ou MOTs existants

- 25 -

Analyse des flux



Bilan et critique

Contraintes

Objectifs-Orientation Nouveaux besoins Critique de l'existant



Scénari futurs

MCDs futurs

MCTs futurs

Validation

Choix de solution





Description conceptuelle

MCD étendu

MCT complet Physique Description organisationnelle MOTs niveau global

Choix

MOTs niveau détaillé

Validation MOT-MCD par les vues externes et Obtention du MCD définitif Passage au MLD (avec contraintes MOD)



Description opérationnelle

Scénario de développement et de mise en oeuvre Confidentialité, ergonomie, outils

- 26 -

MPD

MOpT

Dossier des choix

Existant Futur :

Conceptuel

Logique

Ce processus de description présente des avantages :

- Il limite les erreurs possibles de la description en partant du concret.

-La description du système existant rend possible une vérification du bien fondé de la représentation proposée en permettant une participation active des non informaticiens.

La prise en compte directe du futur système d'information ne se justifierait que si l'organisme était constamment en train de modifier ses modes de fonctionnement. Ce n'est pas le cas : les systèmes à construire se situent nécessairement dans la continuité des systèmes antérieurs.

Merise étant basé sur l'indépendance des données et des traitements, les modèles sont réalisés successivement ou parallèlement.

Une phase de validation est réalisée entre le MCD et le MCT futurs puis entre les vues externes obtenues à partir des MOTs détaillés et ce même MCD :

- La première relecture croisée entre MCD et MCT consiste à vérifier que les entités et relations nécessaires au MCT existent dans le MCD.

- Au niveau du MOT la description des tâches atteint un niveau de détail qui met en scène les données manipulées (création, modification, consultation ou suppression). Il est alors possible de créer des vues externes (mini MCD nécessaires aux traitements) et de vérifier que toutes lesdonnées indispensables ont été décrites au niveau du MCD.

- 27 -

On appelle cette dernière phase devalidation la confrontation des données et des traitements. Après cette validation, le MCD prend le nom de MCD validé et il peut être dérivé en MLD puis MPD.

Cet enchaînement peut également se résumer ainsi :

		DONNEES	TRAITEMENTS	QUESTIONS
CONCEPTUEL		3-MCD	3-MCT	OUI ?
		MCD validé	6
ORGANISATION ET LOGIQUE	-2- DICTIONNAIRE DES DONNEES	7- MLD	5- MOT	OUI ? QUAND ? OU ?		PHYSIQUE
-1- ETUDE EXISTANT	8- MPD	8-MPT	COMMENT
		ETAT ACTUEL	ETAT FUTUR

- 28 -
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

DEUXIEME PARTIE : ETUDE PREALABLE

- 29 -

I. PRESENTATION GENERALE DE LA SOCIETE

L'H.P.D est une structure sous double tutelle des Forces Armés Sénégalaises et de la République Française. Ses locaux se situent à Dakar plateau sur la route Nelson Mandela depuis 1857.

L'H.P.D est une véritable entreprise où la gestion des ressources humaines concerne un effectif de plus de 1200 personnes dont la plupart sont des ressortissants du Ministère des Forces Armés sénégalaises ; mais aussi comprend des militaires français et des civils.

I.1 HISTORIQUE DE L'HOPITAL PRINCIPAL DE DAKAR

Le projet de la construction de l'hôpital remonte à 1862 et les travaux débutent en 1880 avec la fermeture de l'hôpital de Gorée soupçonné d'entretenir le risque épidémique suite à la tragique épidémie de fièvre jaune de 1878 qui frappa Gorée et Dakar, puis Rufisque et Saint-Louis et qui avait fait 750 décès.

Situé sur la presqu'île de Dakar, en bordure de l'anse Bernard, l'Hôpital fût inauguré en août 1884. Il comprenait sept bâtiments à étages avec des arcades de briques qui se faisaient face, trois à trois et fut complété en 1897 par deux bâtiments de logements à deux niveaux. Une galerie à arcades réunit ces deux constructions avec une façade tournée vers le Palais du gouverneur.

Ce premier ensemble de bâtiments constituant le noyau central de l'hôpital subsiste de nos jours et lui confère tout son charme.

A partir de 1898, l'Hôpital Militaire s'agrandit. Il se complète d'annexes : cuisines, lingerie, chapelle, morgue. Avec l'épidémie de fièvre jaune de 1900, de nouveaux bâtiments furent construits pour renforcer le Lazaret de la Quarantaine du Cap Manuel et abriter les contagieux.

- 30 -

On construisit aussi des logements pour les tirailleurs et les infirmiers sénégalais entre l'hôpital et la rue Paul Doumer (où se trouve un baobab maintenant centenaire) au-dessus de la corniche. Ils existent encore en l'état sous l'appellation de « Camp des Mariés ».

La deuxième grande période architecturale se situe entre 1922 et 1930 avec la construction de quatre bâtiments dans le pur style colonial :

Le magnifique bâtiment à étage de la Maternité en 1922.

La Pharmacie d'approvisionnement des Troupes de l'AOF surélevé d'un étage de 'logements en 1923.

Fermeture du parc intérieur avec une galerie en cloître à deux niveaux reliant les bâtiments centraux et les sept bâtiments latéraux en 1927.

Le Pavillon des Dames (devenu Service Boufflers) en 1930.

Pendant la dernière période de l'Afrique Occidentale Française (A.O.F.), de nouvelles infrastructures furent réalisées, délaissant le style colonial et prenant le tournant de la modernité.

En 1940, le Médecin-Colonel Huart fit aménager un bloc opératoire souterrain qui reçut les blessés de l'opération « anglo-gaullliste » sur Dakar et fût abandonné après les combats.

En 1941, le Gouverneur général Brévié fait construire une garderie d'enfants qui portera le nom de son épouse Marie-Louis et qui constitue la partie centrale de l'actuelle clinique Brévié.

En 1957, la Pédiatrie qui comptait 67 lits à l'époque est construite sur deux étages avec une conception moderne et européenne rompant avec le charme des bâtiments antérieurs.

Le Sénégal acquiert son indépendance le 04 avril 1960. Mais jusqu'en 1965, l'hôpital dépend du Commandant des Troupes de l'A.O.F., puis entre en autogestion et dépend de l'Ambassade de France. Il fonctionne en autonomie totale jusqu'en 1983. Pendant cette époque dite moderne et jusqu'en 2004, de nouvelles infrastructures voient le jour et de nouveaux services sont créés :

- 31 -

1961 : création de la Banque de sang

1962 : création du laboratoire de Biochimie 1965 : création du laboratoire de Biologie

1965 : installation de la pharmacie de l'hôpital dans les deux bâtiments et les annexes de l`ancienne pharmacie d'approvisionnement des troupes de l'A.O.F.

1965 : la Stomatologie et la Kinésithérapie se partagent l'ancienne pharmacie.

Entre 1975 et 1978 : construction du second bâtiment du laboratoire de biologie et création du service de Réanimation et Soins Intensifs actuel et d'Hémodialyse.

1981-1982 : construction du nouveau Bloc opératoire qui, avec son unité de stérilisation complète la capacité opératoire.

1991 : construction d'un nouveau bâtiment du Service des Entrées. 1997 : installation d'un scanner.

2000 : rénovation du service de Psychiatrie.

2001 : création d'un service de réanimation chirurgicale et de brûlés.

2002 : création d'un centre d'explorations fonctionnelles multidisciplinaires.

2003 : début de la construction du service d'accueil des urgences (S.A.U.) et d'un secteur d'intervention médicalisée de relève des blessés (SMUR)

2004 : implantation d'un deuxième scanner de dernière génération. 2005 : inauguration du nouveau Service d'Accueil des Urgences.

EVOLUTION DU STATUT DE L'HOPITAL PRINCIPAL DE DAKAR

« L'Ambulance Militaire » de 1880 devient « Hôpital Militaire » à partir de 1890.

- 32 -

La création de l'A.O.F en 1895 et l'élévation de Dakar au rang de capitale de l'A.O.F lui conféreront un statut privilégié qu'il conservera quand Dakar devient capitale du Sénégal.

Le « Règlement de 1912 )) qui définit le fonctionnement des hôpitaux d'Outremer, rattachera l'établissement devenu « Hôpital Colonial )) au Gouverneur Général de l'A.O.F et lui assigne comme mission le traitement des malades et blessés de toute catégorie à l'exception de ceux qui relèvent de l'assistance médicale gratuite pris en charge par l'Hôpital Central Indigène (actuel hôpital Aristide Le Dantec). Il reçoit des malades de tout le Sénégal, de la Mauritanie, du Soudan et les médecins appartiennent au corps de santé colonial. L'appellation d' « Hôpital Principal )), correspondant à son niveau hiérarchique dans l'organisation sanitaire, vient de ce règlement.

En avril 1958, par une convention passée entre le Président du Grand Conseil de l'A.O.F et le Haut Commissaire de la République, l'Hôpital Principal est reversé au budget de la France d'Outre-Mer, mais il conserve son statut d'hôpital militaire français jusqu'en 1971, onze ans après l'indépendance du Sénégal.

En 1971, une convention signée entre la France et le Sénégal place l'Hôpital Principal sous la double tutelle des Forces Armées Sénégalaises et de la République française. Les terrains, les bâtiments et le matériel sont transférés au Sénégal et la France en assure la gestion, sous tutelle du Ministère de la Coopération. Un accord d'établissement rédigé en accord avec les représentations syndicales et qui en fixe les modalités de fonctionnement est toujours en vigueur en 2004.

Dans le cadre de la politique sanitaire nationale, l'Hôpital Principal se voit chargé de la fonction d'Hôpital d'Instruction du Service de Santé des Armées Sénégalaises pour la formation des premiers médecins militaires dont il assure la préparation aux différents niveaux de spécialisation, mais aussi de la formation continue des personnels paramédicaux.

Le 24 décembre 1999, un nouvel accord de coopération signé entre le Sénégal et la France transfère définitivement toutes les responsabilités et en particulier financières aux autorités sénégalaises.

- 33 -

Cette nouvelle convention confirme les liens d'amitié qui unissent les deux pays et précise les nouvelles modalités de coopération concernant l'Hôpital Principal. Elle marque le début d'une nouvelle ère pour l'hôpital.

Avec la loi 2000-01 du 10 janvier 2000, portant réforme hospitalière, L'Hôpital Principal de Dakar devient, au même titre que tous les autres hôpitaux du pays, un Etablissement Public de Santé, mais avec un statut spécial. Il reste sous la tutelle du Ministère des Forces Armées.

En 2004, trois ans après le changement de statut, et conformément aux objectifs de l'accord de 1999, l'Hôpital Principal acquiert son autonomie avec ses avantages, mais aussi ses contraintes.

La plupart des postes de chef de service et de chef de département sont maintenant tenus par des officiers sénégalais. Les personnels paramédicaux et des services communs sont essentiellement civils et sénégalais. Une collaboration harmonieuse entre les cadres sénégalais et français (19 coopérants) permet une émulation scientifique de bon aloi. La contribution française porte sur :

le domaine technique (spécialistes médecins et pharmacien)

le domaine administratif et financier (directeur de l'hôpital et gestionnaire),

la formation par l'attribution de bourses

l'aide à l'investissement technique (centrale électrique, unité centrale de stérilisation, réanimation chirurgicale, service d'accueil des urgences, etc...)

Une nouvelle convention est signée le 17 février 2005. Elle découle du bilan de l'accord du 24 décembre 1999. Les deux parties sont résolues à confirmer à l'Hôpital Principal de Dakar sa vocation d'hôpital d'instruction du service de santé des armées. La France et le Sénégal désirent poursuivre une coopération exemplaire pour faire de l'Hôpital Principal de Dakar un établissement public de santé unique en son genre, au service des deux pays.

- 34 -

Cette convention a pour objet de fixer le cadre et les modalités de la coopération franco-sénégalaise au bénéfice de l'Hôpital Principal d'une part et d'autre part, d'assurer le transfert effectif de l'ensemble des postes de responsabilité et de gestion à la partie sénégalaise. Elle est conclue pour une durée de quatre (04) ans.

En 2006, l'hôpital a sécurisé son avenir. Les lignes budgétaires des subventions de l'Etat sont passées du ministère de la santé au ministère des forces armées sur ordre du Président de la République. L'hôpital s'est ancré définitivement dans son rôle d'hôpital d'instruction des armées, terrain de stage et de formation du personnel du service de santé militaire sénégalais. C'est la pièce maîtresse de l'école d'application du service de santé des armées créée par décret du président de la République N°2006-619/PR/MFA du 10 juillet 2006.

Il est intégré dans le groupe hospitalier militaire dakarois dont l'élément complémentaire est l'hôpital militaire de Ouakam.

Un arrangement technique avec le service de santé des armées français a été signé à Paris le 26 septembre 2006 et un fonds de solidarité prioritaire du ministère des affaires étrangères vient d'être mis en place. Ces éléments contribueront grandement à pérenniser les échanges en terme de formation des personnels et de partenariat avec des institutions françaises civiles ou militaires.

En 2007 l'établissement va de l'avant avec 420 lits et 1170 personnels. L'encadrement est militaire sénégalais. Actuellement 9 professeurs agrégés du Val de Grâce et 31 spécialistes sont affectés dans les services. 30 assistants sont en formation. 15 assistants techniques français restent présents, agissant en partenariat total avec les cadres nationaux, tant au niveau de la direction que des services cliniques et paracliniques. Un département d'ingénierie biomédicale a été créé et permet d'optimiser la maintenance des matériels médico-techniques sophistiqués. L'unité de résonance magnétique nucléaire avec un appareil de 1,5 Tesla est opérationnelle. Le chantier de la fédération des laboratoires touche à sa fin. Les projets liés à al mise à niveau de l'établissement pour la conférence islamique prévue en 2008 vont débuter :

- 35 -

Construction d'une clinique des personnalités, du nouveau département de chirurgie spéciale, réfection des blocs opératoires et des services de réanimation, construction d'une hélistation.

L'Hôpital Principal de Dakar s'ouvre ainsi au troisième millénaire. Il trouvera sa pérennité dans ce concept original, unique et harmonieux d'hôpital d'instruction des armées du Sénégal avec sa composante biculturelle, vivier de formation et de coopération médicale francophone internationale.

Le début de l'histoire



L'hôpital séparé du Palais du Gouverneur général par les champs des cultivateurs.



- 36 -

L'entrée de l'Hôpital Principal au début du 20^ème siècle



L'Hôpital Principal et en arrière plan, la caserne des Madeleines

L'Hôpital Principal aujourd'hui



Vue aérienne de l'hôpital. Au fond, le pavillon Saint-Louis fait face à l'océan.

- 37 -

L'entrée principale



Le pavillon Saint-Louis. Ce bâtiment centenaire conserve son charme d'époque

I.2 SITUATION GEOGRAPHIQUE

L'H.P.D se situe sur la corniche Est de la presqu'île de Dakar-plateau. Il est sur la route Nelson Mandela et est entouré par la présidence sénégalaise, l'Ambassade de la Grande Bretagne, le Building qui abrite gouvernement sénégalais, l'océan Atlantique et le building qui abrite l'antenne de la société de téléphonie mobile TIGO.

- 38 -

CHROQUIS HPD



- 39 -
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

I.3 Mission de H.P.D

Elles sont d'ordre général et spécifique :

*MISSIONS GENERALES :

Ce sont celles dévolues aux Etablissements Publics de Santé (E.P.S) de niveau III.

Ces dernières s'articulent sur :

- La diagnostic ; -Le traitement ; -La prise en charge des urgences médico-chirurgicales ;

-La participation en service public hospitalier ;

*MISSIONS SPECIFIQUES :

Ce sont celles lieux au caractère particulier de l'Etablissement Générale conforme au statut d'Hôpital d'Instruction des Armées.

Ces missions s'articulent autour de :

-La formation des médecins spécialistes des Armées ; -L'expertise et le traitement des pathologies tropicales ; -Le soutien des Forces Armées.

I.4 Organisation

- 40 -

Confert organigramme

I.5 Signification des termes utilisés

H.P.D : Hôpital Principal de Dakar

MCT : Modele Conceptuel de Traitement

MOT : Modele Organisationnel de Traitement

MCD : Modèle Conceptuel de Donées

DAF : Diagramme Acteur/Flux DL : Direction Logistique

MLD : Modèle Logique de Données D.D : Dictionnaire de données

OP : Opération

- 41 -

I.6. ORGANIGRAMME HPD



- 42 -
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

II.ETUDE DE L'EXISTANT

II.1. DESCRIPTION DES DIFFERENTES PROCEDURES

Après avoir consulté le chef de département logistique, le chef de la cellule achat, le chef de la cellule marché, les magasiniers et un chef de service ; nous avons recueilli les informations suivantes :

II.1.1. PROCEDURE DE GESTION DE STOCK

L'Hôpital Principal de Dakar (HPD) possède deux magasins, un de petit matériel (les fournitures de bureau, les produits d'entretien, des consommables informatiques, du matériel d'imprimerie, le petit matériel d'hôtellerie et le gaz butane) et un autre magasin des ateliers.

Ces produits sont rangés sur étagères suivant leurs rayons dont le rayon 1, 2, 3,4 et 5.

A la vraison d'un article, le fournisseur accompagne son article d'un bon de livraison sur lequel est mentionné le numéro, la désignation, la quantité livrée, le prix unitaire, le total, le nom du fournisseur, la signature, la signature du fournisseur et la date de livraison. Ce bon est établi en trois exemplaires pour le réceptionniste, le magasinier et le fournisseur.

Tout article conforme aux normes exigées par l'Hôpital est répertorié dans un fichier de stock après récéption.

Le fichier sert à suivre le stock en magasin.

Après la livraison, le magasinier rédige un bordereau des entrées. C'est une pièce comptable qui permet de mettre à jour la rubrique du stock. Il comprend le numéro d'ordre, la date, la rubrique budgétaire, le numéro du bon de livraison, la désignation, le nom de fournisseur, la quantité et l'observation.

- 43 -

A l'arrivée en stock, le magasinier établit une fiche de stock sur laquelle est mentionné le numéro d'ordre, la date de livraison, la désignation, l'année, le numéro du bon de livraison, le nom du fournisseur, la quantité reçue et la rubrique budgétaire.

A chaque début du mois, les services font des bons de commande pour les fournitures de bureau et les produits d'entretien sur lesquels sont mentionnés le numéro du bon, la désignation, la signature du major, la signature du chef de service du département de logistique ou son délégataire, la quantité demandée, le nom du service, la quantité accordée et la date. Aussi bien, les services peuvent faire des commandes journalières au cas où la commande mensuelle ne parvient pas à couvrir tout le mois.

A chaque fin du mois, le magasinier établit l'état mensuel de distribution sur lequel est mentionné la désignation du produit, la quantité distribuée à chaque service, le nom du service et le total distribué.

Il est à noter que le magasinier dépose toutes les pièces comptables justificatives à la comptabilité excepte la fiche de stock.

II.1.2. PROCEDURE APPROVISIONNEMENT

Lorsque le cumul minimum que le magasinier s'est fixé est atteint, celui-ci établit un bon d'achat qu'il soumet au sein de la cellule achat.

La cellule achat établit un bon de commande qui sera visé par le chef de service du matériel et enfin validé par le gestionnaire.

Si l'achat n'est pas important, celle-ci peut se faire par facture, sinon la Direction de Logistique lance un appel d'offre aux différents fournisseurs.

Ces derniers soumettent leurs offres à la cellule marché qui compare les prix et sélectionne le fournisseur gagnant. La cellule marché envoie la soumission du fournisseur gagnant à la cellule achat qui envoie le bon de commande au fournisseur sélectionné à son tour.

- 44 -

Ce dernier livre le produit au magasin et établit un bon de livraison en trois exemplaires destinés au réceptionniste, au magasinier et concerve le troisième.

Après la livraison, le magasinier transmet le bon de livraison à l'agence comptable puis ce dernier procède au paiement du fournisseur.

A chaque fin d'année, les services expriment leurs besoins annuels et les envoient au département logistique. Ce dernier rassemble tous ces besoins, rédige un cahier de charge et fait un appel d'offre annuel.

II.2. Délimitation du champ d'étude

Notre analyse se focalise sur l'approvisionnement le stockage et à la

distribution. Ceci veut dire que notre progiciel pourra gérer tout ce qui est de l'approvisionnement et la distribution puisque nous avons fait l'analyse dans toutes les structures de gestion de l'H.P.D

II.3. DIAGRAMME ACTEUR /FLUX

II.3.1. Définition et concepts

II.3.1.1. Définition

Il permet de schématiser les flux échangés entre différents acteurs du système.

L'acteur représente une unité active, humaine ou non, intervenant sur le fonctionnement du système, ou dans le fonctionnement du système.

Le flux représente un échange d'information entre les acteurs. II.3.1.2. Concepts

L'établissement des frontières du domaine étudié et champ d'étude amène à différencier les acteurs externes des acteurs internes.

- 45 -

L'acteur interne appartient au domaine étudié. Il participe activement : transformation, décision ...

L'acteur externe appartient généralement à l'environnement, ou bien ne participe au référentiel de l'étude que de manière limitée : apport ou extraction d'informations.

II.3.1.3. Autres définitions

Le diagramme acteur/flux est un diagramme qui permet de représenter les flux entre acteurs du système et les acteurs externes.

Un acteur externe est un élément émetteur ou récepteur de données ou d'informations situé en dehors du système d'informations étudié.

Un acteur interne est un élément émetteur ou récepteur de données ou d'informations situé à l'intérieur du système d'informations étudié.

Un flux est un transfert d'informations entre composants (acteurs) du système. Le composant peut-être une activité, un domaine ou un acteur externe.

II.3.1.4. FORMALISME



NON_DOMAINE

Acteur Externe_1

Flux_1

Acteur Externe_2

Flux_2

Flux_3

Acteur
Interne_1

Fl ux_5

Fl ux_4

Acteur Interne_2

Remarques :

Seuls les flux mettant en jeux un acteur interne sont représentés et on note acteur son représentant ;

- 46 -

En fonction du détail recherché dans la circulation des informations entre les différents, on distingue plusieurs types de diagramme des flux ;

Les acteurs externes n'échangent jamais d'informations.

II.3.1.5. DIAGRAMME ACTEUR/FLUX (D .A.F) GESTION STOCK

GESTION STOCK



7 6

Comptabilité

Gestionnaire

3

Magasinier

D R

2

1

5

2

4

5

Fournisseur

Service

II.3.1.5. 1. Les flux

1. Produit

2. Bon de livraison

- 47 -

3. Bordereau d'entrées

4. Bon de commande

5. Bon de commande visé

6. Etat mensuel des dépenses

7. Bordereau de sortie

II.3.1.5 .2. Les acteurs

*Internes

Magasinier

Gestionnaire

Direction logistique (DL) Comptabilité

*Externes



Fournisseur

Service

II.3.1.6. DIAGRAMME ACTEUR/FLUX (D.A.F) APPROVISIONNEMENT

- 48 -

APPROVISIONNEMENT

1)

II.3.1.6 .1. Les flux



3

Gestionnaire

Cellule Achat

4

2

3

6

DL

1

Service

Agence Comptable

8

Magasinier

11

Cellule Marché

5

10

7

4

9

6

Fournisseur

Bon d'achat

2) Bon de commande

3) Bon de commande visé

4) Bon de commande visé définitivement

5) Appel d'offre

6) Soumission (offre)

7) Livraison

8) Besoins (Budget) d'un service

9) Paiement

- 49 -

10) Avis d'acceptation

11) Bon de livraison

II.3.1.6.2. Les acteurs

*Internes

Magasinier Cellule achat

Chef de service matériel (DL)

Gestionnaire Cellule marché Service

Agence comptable

*Externes :

Fournisseur

II.4. MODELE CONCEPTUEL DE TRAITEMENT (M.C.T)

II.4.1. Definition

Le M.C.T est une représentation d'une image d'un schéma du système en activité c'est-à-dire à l'état dynamique.

Remarque générale :

- 50 -





Dans un M.C.T, il peut exister les opérations isolées ou des groupes d'opérations parallèles.

Le changement d'opération doit obéir exclusivement dans un enchaînement des opérations à l'attente obligatoire d'un événement extérieur.

II.4.2. Formalisme



Evenement déclencheur_1

Evenement
déclencheur_2

<---------------------------->

Nom_synchronisation

C O		NON_OPERATION
	Action_1
D
E	Action_2
O
P
E	Action_i
R	Action _n
A
T
I
O
N

Acteur
Externe

RegleEmission_

RegleEmission_

RegleEmission_

Résultat_y

Résultat_1

Résulat
quelconque

Résultat_X

- 51 -

Un événement est un fait réel qui chaque fois qu'il se produit, provoque la réaction du système ou qui provient de la réaction du système.

L'événement qui provoque la réaction d'un système est appelé « événement déclencheur » tandis que l'événement qui provient de la réaction du système est appelé « Résultat ».

La synchronisation est une condition préalable (Précondition) devant être satisfaite par les événements avant la réaction du système.

Une opération est un ensemble, une suite, une séquence d'actions ininterruption, ne nécessitant aucun autre événement déclencheur en dehors des déclenchés initiaux, ou initial.

Une action est un traitement élémentaire pouvant être accomplis par un système.

C'est une combinaison à l'aide des structures algorithmiques, des primitifs de traitement sur les données qui sont la lecture, l'enregistrement, la mise à jour, la modification, la suppression et la recherche.

Une règle d'émission est une condition devra être satisfaite par l'opération avant d'émettre un ou plusieurs résultats.

La durée limitée de participation d'un événement à une synchronisation est le temps pendant lequel l'occurrence est valable (au dessus duquel l'occurrence n'est plus valable).

- 52 -

Notation



[Capacité]

Evenement

Participation

DL=<Temps>

O

P

i

Operation_1

RegleEmission

Résultat

Par défaut, la durée est infinie (illimitée).

La cardinalité d'un résultat est le nombre d'exemplaires identiques de résultats que le système doit produire.

Notation



Evenement

O

P
i

Operation_1

RegleEmission

Cardinalité

Résultat

Par défaut, la cardinalité égale à un (1).

Un processus est un ensemble d'opérations dont les résultats appartiennent à un même domaine d'activités.

- 53 -

Remarques :

La capacité est supérieure ou égale à la participation (la nécessité doit être supérieure à la réalisation).

Donc, dans une synchronisation, deux événements liés par un ET ne doivent pas avoir une durée limitée nulle simultanément.

Un événement interne au système peut-être :

-Interne à un processus quand il est résultat d'une opération d'un processus et résultat d'une opération d'un même processus (EX : un dakarois et un sénégalais).

-Externe à un processus quand il est résultat d'une opération d'un processus et déclencheur d'une opération d'un autre processus.

Les parties acteurs internes, code opération et détail des opérations sont facultatifs mais sont généralement conseillés pour les besoins de clarté le schéma.

Le nombre d'éléments déclencheurs n'a aucun lien avec le nombre de résultats et aucun rapport avec le nombre de règles d'émissions.

- 54 -

II.4.3. MODELE CONCEPTUEL DE TRAITEMENT (M.C.T) GESTION STOCK



A l'arrivée d'une
commande

A

S1

O

P 1	LIVRAISON
	-Recevoir bon de livraison -Recevoir matériel -Vérifier matériel -Répertorier le matériel dans un fichier stock -Rédiger bordereau d'entrées -Etablir fichier de stock -Stocker matériel
	Matériel conforme Matériel non_conforme	Toujours



Matériel stocké

O P 2	DISTRIBUTION
	-Recevoir bon de commande -Vérifier disponibilité produit en stock -Servir produit
	Disponible Non_disponible

A B

ET

Matériel renvoyé

(B) Matériel vérifié

C

A chaque début du

mois



Demande d'achat émise
(C)

Produit servi
(D)

- 55 -



O

P

3

D

-Etablir état mensuel des dépenses -Sommer la consommation mensuelle -Déposer état mensuel des dépenses -Déposer fichier des entrées

-Déposer fichier des sorties

-Déposer bon de livraison

-Déposer bon de commande service

ETABLISSEMENT ETAT MENSUEL

a b

Toujours

Pièces
comptables
déposées

ET

A la fin du mois

- 56 -



Appel d'offre émus
(C)

II.4.4. M.C.T APPROVISIONNEMENT

Cumul atteint
(A)

S1

TRAITEMENT_ACHAT

O

P

1

-Etablir bon d'achat

-Envoyer bon d'achat è la cellule achat

-Recevoir

-Etablir bon de commande -Viser bon de commande

-Signer définitivement bon de commande

-Etablir appel d'offre

-Lancer appel d'offre

-Etablir facture

-Envoyer facture

-Recevoir offres

-Comparer les prix

-Selectionner fournisseur gagnant _Envoyer soumission fournisseur gagnant è la cellule achat

-Etablir bon de commande fournisseur gagnant

-Evoyer bon de commande au fournisseur gagnant

-Recevoir bon de livraison -Recevoir produit

-Vérifier conformité produit

Matériel conforme

Touj ours

Matériel non_conforme

Li vrai son

livraison réçue renvoyée

A chaque début
d'année

(B)

A

ET

- 57 -

O

P 2	ACHAT_ANNUELS
	-Exprimer besoins services annuels -Envoyer besoins è direction logistique -Rassembler besoins -Rédiger cahier de charges -Lancer appel d'offre annuel
	Touj ours



O
P
3

C

-Recevoir bon de livraison1 - Etablir bon de paiement -Payer fournisseur

Fournisseur payé
(C)

PAIEMENT

Toujours

ET

B

II.5. Modèle Conceptuel de Données (MCD) II.5.1. Definition

Le MCD est la représentation structurée des données exprimant, avec un haut niveau d'invariance, l'activité d'un organisme en termes d'objets et de relations sans se référer aux conditions d'utilisation par tel ou tel traitement.

II.5.1. 1. Autres définitions :

II.5.1. 1.1. Objet :

C'est l'entité du monde réel, pourvu d'une existence propre.

C'est l'ensemble d'éléments ayant les mêmes caractéristiques. Ces éléments sont appelés « occurrences ».

- 58 -

II.5.1. 1.2. L'occurrence

C'est la représentation réelle d'une propriété qui caractérise l'entité.



Ex :

Client

Codeclient Nomclient Prenomclient Telclient Rueclient E_mailclient

<

000N7

MAMADOU

Ba

77 315 90 35

Blaise Diagne X 29 [e-mail]

Occurrence_client

II.5.1.1.3. Relation :

C'est une association ou lien (pourvu d'un sens) qui existe entre les différents objets du système.

EX :

II.5.1.1. 4. Propriété :



Nom_objet_1

0,n

Non_relation

0,n

Nom_objet_2

C'est une information qui caractérise un objet

II.5.1.1. 5 Identifiant :



Nom_objet_1

propriété 1
propriété_2
propriété_3

propriété_n

0,n

Non_relation

0,n

Nom_objet_2

propriété 19 propriété_20 propriété_21 propriété_22 propriété_23

propriété_n

C'est une des propriétés d'un objet qui permet de caractériser d'une manière unique (clé primaire) un objet.

- 59 -



Matricule Prenom Nom

Adresse Age

Personne

Occurrence_personne

00K98B MANIRAKIZA Dismas Medina

1985

<pi>

II.5.1.1.6 Cardinalité :

C'est le nombre minimum est maximum de fois qu'une occurrence d'un objet peut participer à une relation.



II.5.1. 1.6.1 Cardinalité minimale :

0 : un objet ne participe pas à une relation

1 : Un objet participe au moins une seule fois dans la relation II.5.1.1.6.1 Cardinalité Maximale :

1 : Un objet participe à une relation une seule fois n : Un objet participe plusieurs fois à la relation.



Matricule Prenom Nom

Adresse Age

Personne

0,1 0,n

Etre

Numsalle Libellesalle

Salle

II.5.1.1.7 Attribut de relation :

C'est une propriété portée par une relation ; elle dépend des objets liés à l'association.

EX :



Nump Nomp qtep Date qtestock

Produit

0,n 1,n

Qtecmd

Etre

Attribut

Commande

Numcmd
Datecmd

<

Ici, l'attribut de la relation « Etre » est « Qtecmd »

- 60 -

II.5.1.1. 8 Contraintes d'intégrité fonctionnelle (C.I.F)

II.5.1.1.8.1 Definition

La contrainte d'intégrité fonctionnelle entre des objets associés pour une relation exprime le fait qu'un objet peut être déterminé sans équivoque par la connaissance des autres.

L'objet déterminé est appelé « cible » et les autres ou l'autre source de la contrainte d'intégrité fonctionnelle (C.I.F)

Notation



Matricule NomE PrenomE

Etudiant

0,n 1,n

CIF 0,n

0,n

Posséder

Codecahier

Cahier

Remarque :

· La CIF entre deux objets associés par relation exprime une dépendance fonctionnelle forte.

· La cardinalité 1,1 dans une relation exprime une CIF avec pour source l'objet de la cardinalité 1,1.

·



Se situer 1,1

1,1

Ville

Pays

Numville
Nomville

Codepays

... N

1,n

CIF

CIF

Continent

Codecontinent Nomcontinent

Ex :

- 61 -

Un CIF ne peut pas relier deux entités qui se ressemblent comme 1,1 à 1,1 par exemple.

II.5.2. Formalisme

Ex : soit les propriétés suivantes :

Numéro propriétaire, numéro de location, nom propriétaire, prénom propriétaire, l'adresse de location, le nombre de personnes, nom de location, date début, coût mensuel, numéro contrat, date fin, ville, code tarif, durée, B.P. Etablir le MCD



Propriétaire

Locataire

Numpro Nompro Prenompro B.P

0,n

Louer

1,1

Numloc Nomloc Prenomloc tel.loc

1,n

1,n

1,n

Signer

Appliquer

Posséder

1,1

1,1

Contrat

1,n

Tarif
Code tarif

Numlo Nomlo Cout_mensuel

Location

Nombre_parsonne 1,n

1,1

Porter

Numcontrat Durée

Date début Date fin

II.5.3. Quelques règles de gestion

II.5.3. 1. La non redondance

Cette règle s'applique aux propriétés, aux objets et aux relations. Chacun ne peut apparaître qu'une seule fois dans le MCD.

II.5.3. 2. Atomicité des propriétés

Toute propriété doit être élémentaire, c'est-à-dire non décomposable.

- 62 -

II.5.3.3. Unicité de valeur des propriétés

Les propriétés qui caractérisent un objet doivent dépendre exclusivement de l'identifiant de cet objet. Cela signifie que la connaissance de la valeur de l'identifient détermine la valeur unique de chacune des propriétés. L'absence ou la multiplicité de valeurs nécessitent de sortir la propriété en objet.



Numperso Nomperso Prenoperso Tel.perso

Personne

<

Illustration :

RG1 : Une personne possède de 1 à 3 prénoms

RG2 : Une personne possède 0 ou 1 numéro de téléphone. La représentation ci-contre est fausse et doit être modifiée.

La cardinalité 1, n au lieu de 1,3 serait tout aussi juste.



Numperso Nomperso Prenoperso Tel.perso

Personne

1,3

0,1

Communiquer

Posséder

0,n

0,n

Téléphone

NumTel <

Prénom

Prénom

II.5.3. 4. Propriétés et dépendances fonctionnelles

Si une propriété dépend de plusieurs identifiants, elle doit être placée dans la relation qui associe les objets identifiés par ceux-ci.



Fournisseur

Numfour
Nomfour

<

Vendre
0,n 1,n

Nump Désignation Prix_p

Produit

Dans le cas ci-dessus, le prix du produit est lié au produit. A un produit
particulier correspond u et un seul prix quel que soit le fournisseur qui le vend.

- 63 -

Si le prix et variable en fonction du fournisseur, alors il faut choisir la modélisation suivante.

Produit

1,n

0,n Vendre

Identifiant_1



Nump Désignation

Prix_p



Fournisseur

Numfour
Nomfour

<

II.5.3. 5. Dépendance fonctionnelle transitive ou « objet imbriqué »

Si une propriété dépend de l'identifiant de l'objet qui la porte mais également d'une autre propriété de cet objet, cela signifie que l'on est en présence d'un objet imbriqué. Il faut alors l'extraire.

Illustration :

Soit le MCD et un extrait des règles de gestion associées.



Numcontrat NomAssuré PrénomAssuré AdresseAssuré ImmatriculationAu DateAchatAuto ValeurArgusAuto

Contrat

1,n

MontantFranchise

Assurer

1,1

Risque

Coderisque LibelléRisqu

Identifiant_

Chaque contrat est identifié par un numéro de contrat.

On prend en compte le nom, le prénom usuel et l'adresse de l'assuré. Le contrat assure contre des risques.

Chaque risque possède un code et un libellé.

Le montant de franchisse de la franchisse varie en fonction du risque et du contrat.

On note l'immatriculation de l'unique véhicule assuré par le contrat.

On note également la valeur argus et la date d'achat de ce véhicule. Que dire de la modélisation proposée ?

- 64 -

La connaissance du numéro de contrat détermine bien de manière unique chacune des propriétés placées dans l'objet CONTRAT.

Cependant en regardant plus attentivement, il apparaît que « DateAchatAuto )) et « ValeurArgusAuto )), dépendent bien de « NumContrat )) mais aussi de la propriété non identifiante « ImmatriculationAuto )). On est en présence d'u objet imbriqué et il faut sortir cet objet. Après correction, le modèle suivant est obtenu :



Numcontrat NomAssuré PrénomAssuré AdresseAssuré

Identifiant_1 <

Contrat

MontantFranchise <Indéfini>

1,n

1,1

Assurer

0,n

CodeRisque LibelléRisque

Déclarer

Risque

1,1

ImmatriculationAuto DateAchatAuto ValeurArgusAuto

Véhicule

II.5.3. 6. Unicité de l'objet dans une relation

Pour chaque occurrence d'une relation, il ne peut exister qu'une occurrence de chacun des objets participant à la relation. (La seule exception étant, naturellement, la relation réflexivité !).



1,n

NumFour
NomFour

<

Fournisseur

Produit

Quantité

Livrer

1,n

Nomprod Conditionnement

Occurrences de Fourniseur

Occurrences de produit:

(F1, DUBETON)

(F2, DUCAILLOUX)

<pi

(Plâtre, sac 50 Kg) (SableBlanc, Sac 20kg) (Briques, Lot 100)

Ainsi, le fait que F002 livre la même quantité « 25 )) pour Plâtre et Brique ne s'écrit pas de cette manière :

- 65 -

Fournisseur	Produit	Quantité
F002	Briques, Plâtre	25

Cette occurrence traduirait le modèle ci-dessous :

Ce qui doit contraire au modèle initial.

On doit donc écrire les occurrences de la relation de la manière suivante :

Fournisseur	Produit	Quantité
F002	Briques	25
F002	Plâtre	25

II.5.3. 7. Unicité de la relation

Cette règle est systémique de la précédente.

Pour chaque collection d'objets participant à une relation, il ne peut exister qu'une seule occurrence de relation.



Quantité

Livrer

1,n

Nomprod Conditionnement

Produit



Fournisseur

NumFour
NomFour

<

1,n

Le diagramme d'occurrences suivant serait donc faux :

Fournisseur	Produit	Quantité
F001	Plâtre	10
F001	Plâtre	5

Il ne peut y avoir qu'un couple (F001, Plâtre) pour la relation livrer.

La deuxième occurrence de la relation vient donc « écraser » la première.

- 66 -

Fournisseur	Produit	Quantité
F001	Plâtre	5

On peut aussi envisager que les deux quantités se cumulent :

Fournisseur	Produit	Quantité
F001	Plâtre	15 (cumul de 10 et 5)

II.5.3. 8. Dépendance fonctionnelle complète

Les propriétés d'une relation doivent dépendre de la totalité de l'identifiant de celle-ci. Si ce n'est pas le cas, il faut la décomposer en autant de relations que nécessaire.



Entreprise

NomEntreprise Adresse Téléphone

0,n

Travaux

Tarif <Ind

Réaliser

0,n

CodeTravail Description



Client

NumClient
NomClient

0,n

Cette relation traduit le fait que des entreprises réalisent des travaux au profit de clients. Elle précise que le tarif de ces réalisations dépend et de l'entreprise, et du travail et du client. Si ce n'est pas le cas, et si le tarif dépend uniquement et du travail, alors il faut opter pour la modélisation cidessous.



Réaliser

NomEntreprise Adresse Téléphone

Entreprise

0,n

0,n

0,n

CodeTravail Description

Travaux

0,n

Tarif <

Couter

Client

NumClient
NomClient

0,n

- 67 -

La réalisation « REALISER » est conservée car elle traduit un phénomène réel mais sans propriété. La propriété Tarif est alors placée dans une nouvelle relation pour traduire la règle de gestion énoncée.

II.5.3. 9. Non option

La participation d'un objet à une relation ne peut pas être optionnelle. Pour chaque occurrence d'une relation, il doit obligatoirement exister une valeur et une seule des identifiants des objets participants.

Si une participation est optionnelle, alors il faut décomposer en autant de relations que nécessaire.

Illustration :



CarteBancaire



NumCaisse DateHeure MonatPerçu MontantRendu

Espece

CodeBanque Numchèque MontantChèque

Chèque

Facture

NumTransaction

NumCarte MontantPrélévé

NumFacture DateFacture MontantTotalFacture

Il s'agit de traduire qu'une facture peut être réglée par plusieurs moyens de paiement, par exemple partie en chèque, partie en espèces, partie par carte bancaire. Toutes les combinaisons sont possibles et plusieurs factures peuvent être réglées simultanément.



CarteBancaire

NumTransaction NumCarte MontantPrélévé

0,n

Chèque

NumFacture DateFacture MontantTotalFacure

Facture

1,n

Regler

0,n

0,n

CodeBanque NumChèque MontantChèque

Espèce

NumCaisse DateHeure MontantParçu MontantRendu

- 68 -

Une erreur serait de proposer la modélisation suivante :

En effet, avec cette représentation, il faut pour chaque occurrence de la relation « REGLER » une occurrence de chacun des objets carte bancaire, chèque et espèce. Cela signifierait que chaque facture doit être obligatoirement payée avec chacun de ces moyens de paiement.

La représentation est en réalité celle-ci :



NumFacture DateFacture MontantTotalFacture

Facture

0,n

0,n

0,n

Prelever

Payer

Liquider

1,n

1,n

1,n

NumTransaction NumCarte MontantPrélévé

CodeBanque Numchèque MontantChèque

NumCaisse DateHeure MonatPerçu MontantRendu

CarteBancaire

Espece

Chèque

II.5.3. 10. Cohérence des cardinalités

Après avoir contrôle l'ensemble du modèle, il reste à vérifier que les cardinalités autour d'un objet sont cohérentes.



NumAssuré NomAssuré PrénomAssuré AdresseAssuré

Assuré

0,n

0,n

Souscrire

Déclarer

1,n

1,n

ContratAssurVoitu

Immatriculation Marque

Couleur

NumContrat
DateContrat

Voiture

<pi

- 69 -

Un client possède des véhiculent pour lesquels il souscrit des contrats d'assurance.

Pour une occurrence de l'objet ASSURE, il a au moins une occurrence de la relation SOUSCRIRE, ce qui signifie que chaque client géré a au moins souscrit un contrat d'assurance voiture.

Pour une occurrence de l'objet ASSURE, il peut ne pas y avoir d'occurrence de la relation DECLARER, ce qui signifie qu'un client peut ne pas avoir de voiture.

Il y a donc probablement une incohérence entre ces deux cardinalités.

Il faut que ces deux cardinalités soient identiques (0, n) ou (1, n) en fonction des règles de gestion.

- 70 -

II.5.4. Dictionnaire de données (D.D)

CODE	DESIGNATION	TYPE	STRUCTURE	TAILLE	OBJET	IDENTIFIANT
NumBL	Numéro du bon de livraison	Alphanumérique	Simple	5	BL	Oui
DateBL	Date du d'établissement du bon de livraison	Date	Simple	10	BL	Non
DesignationBL	Désignation Du bon de livraison	Alphanumérique	Simple	25	BL	Non
Signature_liv	Signature de la livraison	Alphanumérique	Simple	5	BE	Oui
NumBE	Numéro du bordereau d'entrée	Alphanumérique	Simple	10	BE	Non
DateBE	Date d'établissement du bordereau d'entrée	Date	Simple	10	BE	Non
DésignationBE	Désignation du bon d'entrée	Alphanumérique	Simple	10	BE	Nom
Numstock	Numéro du stock	Alphanumérique	Simple	5	ST	Oui
Libelle_stock	La libellé du stock	Alphanumérique	Simple	30	ST	Non
Numapoff	Numéro d'appel d'offre	Alphanumérique	Simple	7	AO	Oui
Libelle_apoff	Libelle de l'appel d'offre	Alphanumérique	Simple	50	AO	Non
Numf	Numéro du fournisseur	Alphanumérique	simple	5	FR	Oui
Nomf	Nom du fournisseur	Alphanumérique	Simple	25	FR	Non
Prenomf	Prénom du fournisseur	Alphanumérique	Simple	20	FR	Non
Adressef	Adresse du fournisseur	Alphanumérique	Simple	50	FR	Non
Tel_f	Numéro de téléphone du fournisseur	Numérique	Simple	15	FR	Non
Numcomtype	Numéro du type de commande	Alphanumérique	Simple	4	CT	Oui
Libellecomtype	Libelle du type de commande	Alphanumérique	Simple	100	CT	Non
NumBC	Numéro du bon de commande	Alphanumérique	Simple	10	BC	Oui
DesignationBC	Désignation du bon de commande	Alphanumérique	Simple	20	BC	Non
DateBC	Date d'établissement du bon de commande	Date	Simple	10	BC	Non
Numserv	Numéro du service	Numérique	Simple	2	SC	Oui
Nomserv	Nom du service	Alphanumérique	Somple	20	SC	Non
Tel_major	Téléphone du major du service	Numérique	Simple	10	SC	Non
Tel_secretaire	Téléphone du secrétaire du service	Numérique	Simple	10	SC	Non
Numpt	Numéro du type de produit	Alphanumérique	Simple	6	PT	Oui
Libellept	Libellé du type de produit	Alphanumérique	Composée	100	PT	Non

71

Nump	Numéro du produit	Alphanumérique	Simple	6	PD	Oui
DesignationP	Désignation du produit	Alphanumérique	Simple	20	PD	Non
Numfact_type	Numéro du type de facture	Alphanumérique	Simple	5	FT	Oui
Designationfact_type	Désignation du type de facture	Alphanumérique	Simple	20	FT	Non
Numfact	Numéro de la facture	Alphanumérique	Simple	7	FR	Oui
Designationfact	Désignation de la facture	Alphanumérique	Simple	20	FR	Non
Datefact	Date d'établissement de la facture	Date	Simple	10	FR	Nom
Matricule	Matricule du magasinier	Alphanumérique	Simple	15	MG	Oui
Prenom_M	Prénom du magasinier	Alphanumérique	Simple	20	MG	Non
Nom_M	Nom du magasinier	Alphanumérique	Simple	15	MG	Non
Tel_M	Téléphone du magasinier	Numérique	Simple	10	MG	Non
Adresse_M	Adresse du magasinier	Alphanumérique	composéé	30	MG	Non
Num_TVA	Numéro de la TVA	Alphanumérique	Simple	7	TV	Oui
Taux_TVA	Taux de la TVA	Alphanumérique	simple	5	TV	Non

72

II.5.5. Modèle Conceptuel des données (M.C.D)



1,1

Etablir 3

Facture

Gerer

Stock

1,n

Numfact
Datefact

Magasinier

1,n

1,1

Appartenir 1

1,n

Concerner 1

Etablir 4

Quantitefact Nu

Bordereau_Entrees

Etablir 2

1,n

1,1

Produit_type

NumBE
DateBE

1,n

Numpt Libellept

Facture_type

1,n

0,n

1,n

Etre 2

Produit

1,1

Numfact type Libellefact_type

Matricule Prenom_M Nom_M Tel_M Adresse_M

1,1

1,n

1,n

Numstock Libelle_stock

1,n

Bordereau_sorties

Concerner

NumBS
DateBS

QuantiteBE

0,1

Soumettre

0,n

0,n

0,n

1,n

TVA

Concerner 3

1,n

1,n

Num tva Taux_TVA

Nump

Designationp

Prix Unitairep Quantite_stock Date_Mise_en_stock

1,n

Contenir

1,n

Commander

Service

Qtecmd <Ind

Fournir

1,n

Appel Offre

Bon_Livraison

1,n

Concerner 5

NumBL
DateBL

QuantiteBC

1,n

1,1

Etablir

Bon_Commande

1,n

Numserv Nomserv Tel_Major Tel_Secretaire

Qte_fourni Prix_unitair Date

QuantiteBL Prix UnitaireBL

Numapoff Libelleapoff Dateapoff

0,n

1,1

1,n

1,n

Fournisseur

Etablir 1

NumBC
DateBC

Recevoir

Commande_type

0,n

0,n

Numcomtype Libellcomtype

Numf Nomf Prenomf Adressef Tel_f

73

TROISIEME PARTIE : ETUDE DETAILLEE

74

I. MODELE ORGANISATIONNEL DE TRAITEMENT (M.O.T)

I.1. Définition et concepts

I.1.1. Définition

Le M.O.T est une image, une représentation des traitements selon l'organisation que le système s'est donné pour les exécuter.

Remarque :

o Dans un MOT, plusieurs PF peuvent contenir exactement les mêmes tâches.

o Une tâche peut se trouver dans un ou plusieurs PF même s'ils ne sont pas identiques.

o Dans le diagramme d'enchaînement des PF, une PF peut être représenté par unique résultant ou les résultats des autres.

I.1.2. Concepts

I.1.2.1. Elaboration du MOT

I.1.2.1.1. A partir de l'analyse de l'existant

Après le recueil de l'existant, on dispose généralement de la liste des tâches par :

Poste de travail ;

Les documents utilisés pour chaque tâche ; Les ressources utilisées pour chaque tâche ; Les événements déclencheurs ;

Les règles d'organisation.

Donc, pour faire le MOT, on a généralement besoin de transformer les documents en évènements.

75

I.1.2.1.1.1. Passage de documents en évènements

A partir du document, on forme le MOT correspondante en faisant ressortir l'idée matérialisée par le document

I.1.2.1.1.2. ^ProcédéAprès le MCT, on obtient généralement des évènements d'ordre temporel,

de gestion, des actions, des règles d'émission, les synchronisations, les résultats. Tous ces concepts doivent être traduits au niveau organisationnel

I.1.2.1.1.3. De l'évènement conceptuel à l'évènement organisationnel

L'évènement conceptuel doit être préalablement traduit en terme organisationnel en précisant les valeurs, les supports, etc ...

Ex :

E1 : Début de la journée (conceptuel) / 08h (Relatif organisationnel)

E2 : Achat désiré / Bon d'achat reçu

Les évènements temporels sont après géré par la chronologie tandis que les évènements de gestion seront utilisés dans le déclenchement des PF.

I.1.2.1.1.4. De l'action à la tâche

De l'action, on précise les aspects organisationnels nécessaires à son exécution (qui l'exécute ? , Acteur, où est-elle exécutée ? Lieu, Comment est-elle exécuter ? Les ressources (manière), Quand est-elle exécutée ? Le moment).

Ainsi, en fonction de ces aspects organisationnels, une action peut donner plusieurs tâches.

Ex : a1 : Inscrire étudiant à l'I.S.I

						T1 : Saisir données de l'étudiant T2 : Sauvegarder données T3 : Imprimer carte Etudiant
Secrétariat			Secrétaire
Secrétaire

Directeur

76

ANALYSE DE LA GSTION DE SCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE des études

T4 : Signer carte Etudiant

T5 : Remettre care d'Etudiant

I.1.2.1.1.5. Différents sortes de PF PF temps réel

Comme toutes les PF, la PF temps réel sera aussi décrite par sa fiche descriptive. Elle est généralement automatisée conversationnelle et déroule une succession de dialogue entre l'homme et la machine. En général, l'homme exécute les tâches suivantes :

Frappe des caractères ;

Consultation des documents papier ; Lancer des commandes ;

Ses renseignements auprès des interlocuteurs ;

Exploitation des résultats ; Introduire des consommables.

Quand à la machine, elle exécute les tâches suivantes :

Afficher à l'écran ;

Sauvegarder les données ; Imprimer sur papier ; Exécuter commande ;

Communication de données à d'autres machines en réseaux ;

Mis à jour des données ;

Calcul arithmétique et logique ;

Traitement de contrôle ;

77



Dans l'élaboration de la PF temps réel, on peut pour des raisons économiques ou techniques subdiviser la PF en plusieurs « dialogues » ou morceaux appelées transactions.

Cette répartition du travail entre l'homme et la machine va être schématiser généralement à l'aide d'un graphique appelé diagramme de répartition des tâches Homme/Machine ou Interface Homme/Machine noté IHM.

Une tâche peut être :

Manuel (M) : sans l'intervention de la machine

Automatique (A) ou Temps Réel (TR) : Traité avec l'intervention de la machine uniquement

Semi-Automatique (SA) ou Temps Différé (TD) :Intervention de la machine et de l'homme.

Remarques:

Un PF est caractérisé par un même acteur, un même lieu, un même moment

Un MOT est fait à base du MCT Action : Traitement élémentaire Règle d'organisation : qui, quand, où Tâche= action + Règle d'organisation

78

I.2. Formalisme

Période	ENCHAINEMENT DES PF		POSTE DE T RVAIL	Type
<Début PF> <Durée PF> <Fin PF>	Evenement _1 Evenement _n < >		<Lieu exécution PF> <Résponsable du Lieu> <Ressources utilisés>	<Temps réel> Manuel <Temps différé>
	P F	NOM_PF
		i Tache_1 Tache_2 Tache_3 Tache_n
		RegleEmission_1 RegleEmission_2 RegleEmission_3
	Resultat_1 Résultat_2 Résultat_3

79

I.3. DIAGRAMME DE DESCRIPTION DES PF

I.3.1. MODELE ORGANISATIONNEL DE TRAITEMENT (M.O.T)
GESTION STOCK

Période

ENCHAINEMENT DES P.F

Lieu

Type

A la livraison Variable

Besoin de matériel

Commande

Magasinier Magasin Ordinateur

Différé

ET

P F 1

LIVRAISON

-Recevoir Bon de Livraison -Recevoir matériel -Vérifier matériel -Etablir Bordereau d'Entrées -Stock le matériel -Etablir une fiche de stock

Matériel conforme

Matériel non_conforme

Toujours

Matériel stocké

Matériel renvoyé

Matériel vérifié

Automatique

Magasinier Magasin Ordinateur

haque fin du m Variable

ET

P F 2

DISTRIBUTION

-Recevoir Bon de Commande -Vérifier disponibilité produit -Sevir produit

Disponible

Non_disponible

Produit servi (A) Demande d'achat émise

80

Période	ENCHAINEMENT DES P.F							Lieu	Type
A la fin du mois Variable	A							Magasinier Magasin Imprimante + Ordinateur	Automatique
	P F 3	ETAT MENSUEL DES DEPENSES
		-Etablir Etat Mensuel des Depenses -Sommer les consommations de chaque service
		Toujours
						Etat mensuel établi
Après Etablissement Etat Mensuel des Dépenses Variable
								Magasinier Agence Comptable	Manuel
				P F 4	DEPOT PIECES
					-Déposer Etat Mensuel des Dépenses -Dépot Fiche des Entrées -Dépot fiche des sorties -Dépot bon de livraison -Depot bon de commande service
					Toujours
			Pièces comptables déposées

81

I.3.2. MODELE ORGANISATIONNEL DE TRAITEMENT (M.O.T)
APPROVISIONNEMENT

Période

ENCHAINEMENT DES P.F

Lieu

Type

En cas de besoin Variable

Cumul atteint D (F) a b

Magasinier Magasin Ordinateur + Imprimante

Différé

OU

P F 1

ETABLISSEMENT BON D'ACHAT

-Etablir bon d'achat -Envoyer bon d'achat à la cellule achat

Toujours

Bon d'acahat établi

Après établissement bon d'achat Variable

Secrétaire cellule achat Secrétariat cellule achat Ordinateur + Imprimante

Différé

P F 2

ETABLISSEMENT BON DE COMMANDE

-Recevoir bon d'achat -Etablir bon de commande -Envoyer bon de commande

Toujours

Bon de commande envoyé (A)

82

Période

ENCHAINEMENT DES P.F

Lieu

Type

Après l'envoie du bon de commande Variable

A a

Achat non_ important b

Chargé du matériel Direction Logistique

Manuel

ET

P F 3

APPOSITION SIGNATURE

-Recevoir bon de commande -Viser bon de commande -Remettre bon de commande

Toujours

Bon de commande visé et remis

Après signature bon de commande Variable

Gestionnaire Direction Général

Manuel

P F 4

APPOSITION SIGNATURE DEFINITIF

-Recevoir bon de commande visé -Signer bon de commande définitivement -Remettre bon de commande signé définitiv

Toujours

Bon de commande signé définitivement et remis

Après signature définitif du bon de commande Variable

Chef de cellule achat Cellule achat Ordinateur + Imprimante

Différé

P F 5

ACHAT NON_IMPORTANT

-Etablir facture -Envoyer facture

Toujours

Facture envoyé

83

Période

ENCHAINEMENT DES P.F

Lieu

Type

Après l'envoie de bon de commande Variable

A

^Chargéd'approvisionn- ement Cellule marché Ordinateur + Imprimante

Automatique

P F 6

ETABLISSEMENT APPEL D'OFFRE

-Recevoir bon de commande -Etablir appel d'offre -Lancer appel d'offre

Toujours

Appel d'offre lancé

A la réception des offres Variable

H OU

^Chargéd'approvionne ment Cellule marché

Manuel

P F 7

CHOIX FOURNISSEUR

-Recevoir offre -Comparer le sprix -Séléctionner fournisseur gagnant -Envoyer offre fournisseur gagnant à cellule

Toujours

Offre fournisseurgagnant envoyé

_

Après envoie offre fournisseur_gagnant Variable

Chef de cellule achat Cellule achat Ordinateur + Imprimante

Différé

P F 8

ENVOIE COMMANDE

-Recevoir offre fournisseur_gagnant P -Etablir bon commande fournisseur gagnant F -Envoyer bon de commande du fournisseur gagnant 5

Toujours

Bon de commande fournisseur gagnant envoyé

84

Période

ENCHAINEMENT DES P.F

Lieu

Type

Après envoie bon de commande fournisseur_gagnant Variable

K

Magasinier Magasin Ordinateur

Différé

P F 9

RECEPTION PRODUIT

-Recevoir bon de livraison -Recevoir produit -Enregistrer produits -Vérifier conformité produit

Non_conforme

Conforrme

Toujours

Livraison renvoyée (D)

Livraison réçu

Conformité vérifiée

Après la livraison Variable

Comptable de l'gence comptable Agence comptable Ordinateur + Imprimante

Différé

ETABLISSEMENT BON DE PAIEMENT

P F 10

-Recevoir bon livraison -Etablir bon de paiement

Toujours

Bon de paiement signé

Après établissment bon de livraison Variable

Comptable Agence comptable Ordinateur

Différé

P F 11

PAIEMENT

-Payer fournisseur -Enregister le paiement

Toujours

Fournisseur payé

85

Période	ENCHAINEMENT DES P.F									Lieu	Type
A chaque fin d'année Variable	F									Major_service Service Ordinateur + Imprimante	Différé
	P F 12	PREVISION ANNUELLE SERVICE
		-Repértorier besoins -Saisir besoins -Enregistrer listedes besoins Imprimer liste des besoins -Envoyer liste des besoin à la direction logistique
		Toujours
	Liste besoins envoyée
Après recéption des prévisions annuels Variable										Chargé d'approvision nement Direction logistique Ordinateur + Imprimante	Différé
			P F 13	ACHAT ANNUELS
				-Rassembler besoins des services -Rédiger cahier de charges -Lancer appel d'offre annuel
				Toujours
						Bon	de paiement signé (H)

86

I.4. Tableau descriptif des PF

I.4.1. Procédure : Gestion de stock

CHRONOLOGIE			ECHAINEMENT DES PF			POSTE DE TRAVAIL
Début	Durée	Fin	Code	Désignation	Nature	Responsable	Lieu	Ressources
A la livraison	-		PF1	Livraison	SA	Magasinier	Magasin	Ordinateur
A chaque début du mois	-	-	PF2	Distribution	TR	Magasinier	Magasin	Ordinateur
A la fin du mois	-	-	PF3	Etat mensuel des dépenses	A	Magasinier	Magasin	Ordinateur + Imprimante
Après établissement E.M.D	-	-	PF4	Dépôt pièces	SA	Magasinier	Agence comptable	Manuel

87
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT

I.3.2. Procédure : Approvisionnement

CHRONOLOGIE			ENCHAINEMENT DES PF			POSTE DE TRAVAIL
Début	Durée	Fin	Code	Désignation	Nature	Responsable	Lieu	Ressources
Cumul atteint	-	-	PF1	Etablissement B.A	A	Magasinier	Magasin	Ordinateur + Imprimante
Après établissement B.A	-	-	PF2	Etablissement B.C	A	Secrétaire C.A	Secrétariat C.A	Ordinateur + Imprimante
Après l'envoie de commande	-	-	PF3	Apposition signature	M	Charge du matériel	D.L	-
Après signature B.C	-	-	PF4	Apposition signature définitif	M	Gestionnaire	D.G	-
Après signature définitif BC	-	-	PF5	Achat non important	SA	Chef cellule achat	C.A	Ordinateur + Imprimante
Après envoie BC	-	-	PF6	Etablissement appel d'offre	SA	Chargé d'Appro	C.M	Ordinateur + Imprimante
A la recéption des offres	-	-	PF7	Choix fournisseur	M	Chargé d'Appro	C.M	-
Après envoie O.F	-	-	PF8	Envoie commande	SA	Chef cellule achat	C.A	Ordinateur + Imprimante
Après envoie BCFG	-	-	PF9	Réception produit	SA	Magasinier	Magasin	Ordinateur
Après la livraison	-	-	PF10	Etablissement B.P	SA	Comptable AC	AC	Ordinateur + Imprimante
Après E.B.L	-	-	PF11	Paiement	M	Comptable AC	AC	-
A chaque fin d'année	-	-	PF12	Prévision annuelle service	SA	Major	Service	Ordinateur + Imprimante
Après réception besoins	-	-	PF13	Achat annuel	SA	Chargé d'Appro	D.L	Ordinateur + Imprimante

88
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT

II.5. FICHE DESCRIPTIF DES PF


I.5.1. GESTION DE STOCK

PF DISTRIBUTION

Code : PF2

Nature : TR

Objet : Distribution du matériel

Action : Mise à jour de la base de données Evénement déclencheur : -Matériel vérifié

-Matériel stocké

Résultat : -Produit servi

-Demande d'achat émise

Poste de travail : Magasinier- Magasin- Ordinateur

PF DEPOT PIECES

Code : PF4

Nature : SA

Objet : Déposer tous les pièces comptables Action :

Evénement déclencheur : Etat mensuel établi

Résultat : Pièces comptables déposées

Poste de travail : Magasinier- Agence comptable

PF LIVRAISON

Code : PF1

Nature : SA

Objet : Enregistrer la livraison du matériel Action : Mise à jour de la base de données Evénement déclencheur : Besoin matériel Résultat : Matériel stocké

-Matériel renvoyé

-Matériel vérifié

Poste de travail : Magasinier- Magasin- Ordinateur

PF ETAT MENSUEL DES DEPENSES Code : PF3

Nature : A

Objet : Sommer les consommations des services

Action :

Evénement déclencheur : Produit servi Résultat : Etat mensuel établi

Poste de travail : Magasinier- Magasin- Ordinateur + Imprimante

89
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

I.5.2. APPROVISIONNEMENT

PF ETABLISSEMENT BON D'ACHAT Code : PF1

Nature : A

Objet : Solliciter l'approvisionnement

Action :

Evénement déclencheur : -Cumul atteint Résultat : Bon d'achat établi

Poste de travail : Magasinier- Magasin- Ordinateur + Imprimante

PF APPOSITION SIGNATURE Code : PF3

Nature : M

Objet : Signer le bon de commande Action :

Evénement déclencheur : Bon de commande envoyé

Résultat : Bon de commande visé et remis

Poste de travail : Chargé du matériel- Direction logistique

PF ETABLISSEMENT BON DE
COMMANDE

Code : PF2
Nature : A

Objet : Etablir et envoyer le bon de commande

Action : enregistrer le bon d'achat

Evénement déclencheur : -Bon d'achat établi

Résultat : -Bon de commande envoyé

Poste de travail : Secrétaire Cellule achat- Secrétariat cellule achat- Ordinateur +

PF APPOSITION SIGNATURE
DEFINITIF

Code : PF4

Nature : M

Objet : Signer le bon de commande définitivement

Action :

Evénement déclencheur : Bon de commande signé et remis

Résultat : Bon de commande signé définitivement et remis

Poste de travail : Gestionnaire - Direction générale

90
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

PF ACHAT NON IMPORTANT Code : PF5

Nature : SA

Objet : Acheter par facture

Action :

Evénement déclencheur : -Bon de commande signer définitivement et remis

Résultat : Facture envoyé

Poste de travail : Chef cellule achat- Cellule achat- Ordinateur + Imprimante

PF CHOIX DU FOURNISSEUR Code : PF7

Nature : M

Objet : Choisir un fournisseur

Action :

Evénement déclencheur : Appel d'offre lancé

Résultat : Offre fournisseur gagnant envoyé

Poste de travail : Chargé d`approvisionnement - Cellule marché

PF ETABLISSEMENT APPEL D'OFFRE Code : PF6

Nature : SA

Objet : Chercher fournisseur

Action :

Evénement déclencheur : -Bon de commande envoyé

Résultat : Appel d'offre lancé

Poste de travail : Chargé d'approvisionnement- cellule marché- Ordinateur + Imprimante

PF ENVOIE COMMANDE Code : PF8

Nature : SA

Objet : Envoyer une commande au fournisseur gagnant

Action :

Evénement déclencheur : Offre fournisseur gagnant envoyé

Résultat : Bon de commande fournisseur gagnant envoyé

Poste de travail : Chef cellule achat - Cellule achat - Ordinateur + Imprimante

91
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

PF RECEPTION PRODUIT Code : PF9

Nature : SA

Objet : Recevoir les produits livrés par le fournisseur

Action : Mise à jour base de données

Evénement déclencheur : -Bon de commande fournisseur gagnant envoyé

Résultat : -Livraison reçue -Livraison renvoyé

Poste de travail : Magasinier- Magasin- Ordinateur

PF PAIEMENT

Code : PF11

Nature : M

Objet : Payer le fournisseur

Action : Mise à jour de la base d e données

Evénement déclencheur : Bon de paiement signé

Résultat : Fournisseur payé

Poste de travail : Comptable- Agence comptable

PF ETABLISSEMENT BON DE
PAIEMENT

Code : PF10

Nature : SA

Objet : Faire signer le bon de paiement pour le fournisseur

Action : Mise à jour de la base de données Evénement déclencheur : - Livraison reçue Résultat : -Bon de paiement signé

Poste de travail : Comptable- Agence
comptable- Ordinateur + Imprimante

PF PREVISIONS ANNUELLES SERVICE Code : PF12

Nature : SA

Objet : Répertorier les besoins annuels de son service

Action :

Evénement déclencheur : Cumul atteint Résultat : Besoins envoyé

Poste de travail : Major - Service - Ordinateur + Imprimante

92
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

PF ETABLISSEMENT BON D'ACHAT Code : PF13

Nature : SA

Objet : Faire un achat annuel

Action :

Evénement déclencheur : Besoins envoyés Résultat : Appel d'offre émis

Poste de travail : Chargé d'approvisionnement- Direction logistique- Ordinateur + Imprimante

93

II.LES ECRANS

MENU GENERAL

LIVRAISON DISTRIBUTION ACHAT ANNUEL

ENVOIE COMMANDE

ETABLISSEMNT BO DE PAIEMENT

RECEPTION PRODUIT

ETABLISSEMENT BON DE COMMANDE

ETABLISSEMENT BON D'ACHAT

ETAT MENSUEL DE DEPENSES

ETABLISSEMENT APPEL D'OFFRE

ACHAT NON IMPORTANT

PRESVISION ANNUELLE SERVICE

QUITTER

94

LIVRAISON

Numéro bon de livraison :....

Date de la livraison : / /

Numéro fournisseur : Prénom Fournisseur : Nom Fournisseur : Tel / Fax Fournisseur : B.P Fournisseur :

Numéro produit

Désignation

Quantité

Prix unitaire

Montant

Valider QUITTER Annuler

95

DISTRIBUTION

Code service :

Date : / /

Tel. Major :

Numéro produit

Désignation

Quantité demandée

Quantité servie

Prix unitaire

Montant

Valider QUITTER Annuler

96
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

		ETAT MENSUEL DES DEPENSES
	Code service : Nom service :						Date : / /
	Tel. Major : Tel. Secrétaire :
	Numéro produit		Désignation	Quantité		Prix unitaire		Montant
Valider QUITTER Annuler

97
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

			BON D'ACHAT
	Numéro bon achat :				Date : / /
	Numéro produit	Désignation				Quantité
Valider QUITTER Annuler

98
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

BON DE COMMANDE

Date : / /

Numéro :

Numéro produit

Désignation

Quantité

Prix unitaire

Montant

Valider QUITTER Annuler

99
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

FACTURE

Numéro Facture :

Date : / /

Numéro fournisseur : Prénom Fournisseur : Nom Fournisseur : Tel / Fax Fournisseur : B.P Fournisseur : E-mail fournisseur : Site web fournisseur :

Numéro produit

Désignation

Quantité

Prix unitaire

Montant

Valider QUITTER Annuler

100
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

			APPEL D'OFFRE
		Numéro Appel d'offre :			Date : / /
	LIBELLE APPEL D'OFFRE
Valider QUITTER Annuler

101
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

COMMANDE

Numéro commande :

Date : / /

Numéro fournisseur : Prénom Fournisseur : Nom Fournisseur : Tel / Fax Fournisseur : B.P Fournisseur : E-mail fournisseur : Site web fournisseur :

Numéro produit

Désignation

Quantité

Prix unitaire

Montant

Valider QUITTER Annuler

102
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

BON DE RECEPTION

Numéro bon de réception :

Date : / /

Numéro fournisseur : Prénom Fournisseur : Nom Fournisseur : Tel / Fax Fournisseur : B.P Fournisseur : E-mail fournisseur : Site web fournisseur :

Numéro produit

Désignation

Quantité

Prix unitaire

Montant

Valider QUITTER Annuler

103
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

BON DE PAIEMENT

Numéro bon de paiement :

Date : / /

Numéro fournisseur : Prénom Fournisseur : Nom Fournisseur : Tel / Fax Fournisseur : B.P Fournisseur : E-mail fournisseur : Site web fournisseur :

Numéro produit

Désignation

Quantité

Prix unitaire

Montant

Valider QUITTER Annuler

104
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

				PRIVISIONS ANNUELLES
		Code service : Nom service :				Date : / /
		Tel. Major : Tel. Secrétaire :
	Numéro produit		Désignation					Quantité
Valider QUITTER Annuler

105
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

			APPEL D'OFFRE ANNUEL
		Numéro Appel d'offre :			Date : / /
	LIBELLE APPEL D'OFFRE
Valider QUITTER Annuler

106
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

III. DIAGRAMMES DE REPARTION DES TACHES HOMME/MACHINES



DIAGRAMME DE REPARTITION DES TACHES ENTRE L'HOMME ET LA MACHINE

HOMME

MACHINE

REMARQUES

1. Livraison

Lancer application

Ecran de connexion

ok

NON_ok

MENU GENERAL (M)

Choix

1

3 2

4 1

5

7 6 8

9

Ecran livraison

Entrer le numéro de la livraison, la date de livraison, les libellés du produit et du fournisseur

Incrémenter le stock

Choisir réponse

Valider

Quitter

Annuler

Début

12

11

10

107



REMARQUES

MACHINE

DIAGRAMME DE REPARTITION DES TACHES ENTRE L'HOMME ET LA MACHINE

2. Distribution

2

Valider

Quitter

Annuler

Entrer le code et le
nom service, la date,
Designationp ,
quantitep

Choisir réponse

Décrémenter le stock

Afficher la quantité
disponible en stock

Ecran distribution

108

DIAGRAMME DE REPARTITION DES TACHES ENTRE L'HOMME ET LA MACHINE

HOMME

MACHINE

REMARQUES

3. Etat mensuel des dépenses

Ecran état mensuel

3

des dépenses

Entrer code et non service, Tel major et secrétaire, date et libellé produit

Afficher l'invitation à valider, à annuler la saisie

ou à quitter

Choisir menu imprimer

Impression

Afficher précèdent suivant

Choisir réponse

Précèdent

Suivant

109

III.1 DIAGRAMME DE REPARTITION DES TACHES HOMMES
MACHINES POUR L'APPROVISIONNEMENT

DIAGRAMME DE REPARTITION DES TACHES ENTRE L'HOMME ET LA MACHINE

HOMME

MACHINE

REMARQUES

4. Bon d'achat

4

Ecran bon d'achat

Entrer numéro, date et libellé bon d'achat

Afficher l'invitation à valider, à annuler la saisie ou à quitter

Choisir réponse

Valider

Quitter

Annuler

110
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

DIAGRAMME DE REPARTITION DES TACHES ENTRE L'HOMME ET LA MACHINE

HOMME

MACHINE

REMARQUES

5. Bon de commande

5

Ecran Bon de commande

Saisie numéro bon, date, numéro produit, quantité, prix unitaire,

Afficher l'invitation à valider, à annuler la saisie ou à quitter

Choisir réponse

Valider

Quitter

Annuler

111
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

DIAGRAMME DE REPARTITION DES TACHES ENTRE L'HOMME ET LA MACHINE

HOMME

MACHINE

REMARQUES

6. Facture

6

Ecran facture

Saisir numéro produit, quantité, prix unitaire et la date

Afficher l'invitation à valider, à annuler la saisie

ou à quitter

Choisir réponse

Valider

Quitter

Annuler

112

DIAGRAMME DE REPARTITION DES TACHES ENTRE L'HOMME ET LA MACHINE

HOMME

MACHINE

REMARQUES

7. Appel d'offre

Ecran Appel d'offre

7

Entrer le libellé d'appel d'offre

Afficher l'invitation à

valider, à annuler ou

la saisie à quitter

Choisir réponse

Valider

Quitter

Annuler

113

DIAGRAMME DE REPARTITION DES TACHES ENTRE L'HOMME ET LA MACHINE

HOMME

MACHINE

REMARQUES

8. Commande

Ecran Commande

8

Enter le code produit le produit, la quantité, date d'établissement de la de commande fournisseur

Afficher l'invitation à valider, à annuler la saisie ou à quitter

Choisir réponse

Valider

Quitter

Annuler

114

DIAGRAMME DE REPARTITION DES TACHES ENTRE L'HOMME ET LA MACHINE

HOMME

MACHINE

REMARQUES

9. Bon de réception

Ecran bon de réception

9

Enter le non quantité,

le code produit, du produit, la

date de mise en stock

Afficher l'invitation à valider, à annuler la saisie

ou à quitter

Choisir réponse

Valider

Quitter

Annuler

115

DIAGRAMME DE REPARTITION DES TACHES ENTRE L'HOMME ET LA MACHINE

HOMME

MACHINE

REMARQUES

10. Bon d'achat

10

Bon

d'achat

Enter le libellé fournisseur, la quantité, le prix unitaire

Afficher l'invitation à valider, à annuler la saisie ou à quitter

Choisir réponse

Valider

Quitter

Annuler

116

DIAGRAMME DE REPARTITION DES TACHES ENTRE L'HOMME ET LA MACHINE

HOMME

MACHINE

REMARQUES

11. Prévisions annuelles

11

Ecran prévision annuel

Entrer date

Choisir le produit, la quantité, d'établissement

des

l'observation besoins et

Afficher l'invitation à valider, à annuler la saisie ou à quitter

Choisir réponse

Valider

Quitter

Annuler

117

DIAGRAMME DE REPARTITION DES TACHES ENTRE L'HOMME ET LA MACHINE

HOMME

MACHINE

REMARQUES

12. Appel d'offre annuel

Ecran Appel D'Offre d'Annuel

12

Saisir le produit, la quantité, date d'appel d'offre

Afficher l'invitation à valider, à annuler la saisie ou à quitter

Choisir réponse

Valider

Quitter

Annuler

118

IV. MODELE EXTERNE ET

VALIDATION

IV. 1. MODELE EXTERNE

IV.1. a) Definition

Un modèle externe est une représentation des données utilisées dans un PF automatique pour un type de traitement.

On distingue deux types de traitements : La mise à jour ;

La consultation.

La mise à jour représente toutes les tâches de modification, de suppression, d'ajout et de création tandis que la consultation représente toutes les tâches d'affichage, d'impression ou d'édition.

Remarque :

Dans un PF automatique, on peut ainsi avoir plusieurs modèles externes selon les différents types rencontrés.

119

V.2. MODELE EXTERNE RELATIF

V.2.1. MODELE EXTERNE RELATIF A LA LIVRAISON : Ecran 1, PF1



NumBL DesignationBL

Bon_livraison

Quantite Prix_unitaire Date

Concerner

1,n 1,n 1,n

1,n

NumBS DesignationBS QuantiteBS Prix_unitaireBS DateBS

Borderau_sorties

<

<

1,n

Contenir_1

Nump Designationp Quantitep Prix_unitairep Date_mise_stock

1,1

Produit

Lister

1,n

Figurer

1,1

1,n

Numfs Rublique_budgetaire Designationfs Quantitefs

Prix_unitairefs

Datefs sortiefs Entreefs

Fiche_stock

1,n

Contenir

Fournir

1,n

1,n

Lister_1

1,n

Numfour Nomfour Prenomfour Tel_four Site_web_four E_mail_four

1,1

NumBE DesignationBE QuantiteBE Prix_unitaireBE DateBE

Fournisseur

Bordereau_entrees

<p

V.2.2. MODELE EXTERNE RELATIF A LA DISTRIBUTION : Ecran 2, PF2



Bon de commande_service

NumBC Serv Num_Serv Nom_Serv DesignationBC_Serv QuantiteBC_Serv

<pi>

1,n

Contenir

1,n

Nump Designationp Quantite_stock Prix_unitairep Date_de_stockage

Produit

120

V.2.3. MODELE EXTERNE RELATIF A L'ETAT MENSUEL DES
DEPENSES : Ecran 3, PF3



Bon de commande_service

NumBC Serv Num_Serv Nom_Serv DesignationBC_Serv QuantiteBC_Serv

<pi>

1,n

Contenir

1,n

Nump Designationp Quantite_stock Prix_unitairep Date_de_stockage

Produit

1,n

NumServ NomServ Tel_Major Tel_Secretaire

Consommer

Service

1,n

1,1

Concerner

1,n

Etat mensuel des dépenses

NumEMD Libellé

<pi> Numérique Caractère (

V.2.4. MODELE EXTERNE RELATIF AU BON D'ACHAT : Ecran 4, PF1



Bon d'achat

NumBA DesignationBA QuantiteBA

1,n

Concerner Date_achat

1,n



Nump Designationp Quantite_stock Prix_unitairep Date_de_stockage

Produit

121

V.2.5. MODELE EXTERNE RELATIF AU BON DE COMMANDE : Ecran 4,
PF2



NumBC DesignationBC QuantiteBC Prix_unitaireBC DateBC

Bon_commande

1,n

Contenir

<pi>

1,1

1,1

1,n

Nump Designationp Quantitep Prix_unitairep Date_mise_stock

Concerner

Produit

Recevoir

1,n 1,1

NomAO LibelleAO DateAO

Appel_offre

1,n

1,n

<

Numfour Nomfour Prenomfour Tel_four E-mail_four Site_four

Founisseur

Subir

Nums Designations Quantites Prix_unitaires Dates

Soumission

V.2.6. MODELE EXTERNE RELATIF A LA FACTURE : Ecran 6, PF5



Produit

Contenir

1,n

Nump Designationp Quantitep Prix_unitairep Date_mise_stock

1,n

Facture

Numfacture Designationfacture Quantite_facture Prix_unitaire_facuret Date_facture

1,1

Recevoir

1,n



Nomfour Prenomfour Tel_four E-mail_four Site_web_four B.P_four

Fournisseur

122
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE

DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT SUPERIEUR D'INFORMATIQUE DE DAKAR

V.2.7. MODELE EXTERNE RELATIF A L'APPEL D'OFFRE : Ecran 7, PF6



Produit

Contenir

1,n

Nump Designationp Quantitep Prix_unitairep Date_mise_stock

Nums Designations Quantites Prix_unitaires Dates

Soumission

1,n

1,1

Bon_commande

NumBC DesignationBC QuantiteBC Prix_unitaireBC DateBC

<pi>

1,1

Concerner

Subir

1,n

1,n

Appel_offre

NomAO LibelleAO DateAO

<

V.2.8. MODELE EXTERNE RELATIF A UNE COMMANDE : Ecran 8, PF8



Bon d'achat

NumBA DesignationBA QuantiteBA

1,n

Concerner Date_achat

1,1

Concerner_1

1,n



Nump Designationp Quantite_stock Prix_unitairep Date_de_stockage

Produit

1,n



NumBC DesignaionBC QuantiteBC Prix_unitaireBC DateBC

Bon_de_commande

<pi>

123

V.2.9. MODELE EXTERNE RELATIF AU BON DE RECEPTION : Ecran 9,

PF9



NumBL DesignationBL

Bon_livraison

<

1,n

Quantite Prix_unitaire Date

Contenir

Produit_type

Nump type Libellé

1,n

1,n

Nump Designationp Quantitep Prix_unitairep Date_mise_stock

Etre

Produit

1,1

V.2.10. MODELE EXTERNE RELATIF AU BON DE PAIEMENT : Ecran 10,

PF10



NumBL DesignationBL

Bon_livraison

1,1

<

1,n

Quantite Prix_unitaire Date

Contenir

Etablir

Fournisseur

1,n

Numfour Prenomfour Nomfour Tel_four E-mail_four Site_web_four

<

1,n

NumBP LibelleBP DateBP

Bon_paiement

<pi> < < <

124

V.2.11. MODELE EXTERNE RELATIF AUX PREVISIONS ANNUELLES DES
SERVCES : Ecran 11, PF12



NumServ NomServ Tel_Major Tel_Secretaire

Service

<

1,n

Demander
Qté <Ind

1,n

Nump Designationp Quantitep Prix_unitairep Date_mise_stock

Produit

V.2.12. MODELE EXTERNE RELATIF A L'ACHAT ANNUEL : Ecran 12,
PF13



NumServ NomServ Tel_Major Tel_Secretaire

Service

<

1,n

Appel_offre

NumAP LibelleAP DateAP

Demander

1,n

Concerner

1,n

1,n

Nump Designationp Quantitep Prix_unitairep Date_mise_stock

Produit

VI. VALIDATION

VI.1. Validation des objets

CONCEPTUEL	EXTERNE	Validation
Produit	Produit	Valider
Fournisseur	Fournisseur	Valider
Magasinier	_	A ajouter

125

Stock	_	A ajouter
Produit_type	Produit_type	Valider
Service	Service	Valider
TVA	_	A ajouter
Facture	Facture	Valider
Facture_type
Bordereau_entrees	Bordereau_entrees	Valider
Bordereau_sorties	Bordereau__sorties	Valider
Appel offre	Appel offre	Valider
Bon_livraison	Bon_livraison	Valider
Commande_type	_	A ajouter
Bon_commande
_	Soumission	A ajouter
_	Bon_paiement	A ajouter
_	Fiche_stock	A ajouter
_	Bon d'achat	A ajouter
_	Bon de commande_service	A ajouter
_	Etat- mensuel_depensees	A ajouter

126

VI.2. Validation des propriétés

CONCEPTUEL	EXTERNE	VALIDATION
Nump	Nump	Valider
Designationp	Designationp	Valider
Quantitep	Quantitep	Valider
Prix_unitairep	Prix_unitairep	Valider
Date_mise_stock	Date_mise_stock	Valider
Numfour	Numfour	Valider
Prenomfour	Prenomfour	Valider
Nomfour	Nomfour	Valider
Tel_four	Tel_four	Valder
E_mail-four	E_mail_four	Valider
Site_web_four	Site_web_four	Valider
_	B.P_four	A ajouter
NumServ	NumServ	Valider
NomServ	NomServ	Valider
Tel_Major	Tel_Major	Valider
Tel_Secretaire	Tel_Secretaire	Valider
Matricule	_	A ajouter
Nom_M	_	A ajouter
Prenom_M	_	A ajouter

127

Tel_M	_	A ajouter
Adresse_M	_	A ajouter
NumStock	_	A ajouter
Libelle_stock	_	A ajouter
Numfacture	Numfacture	Valider
Designationfacture	Designationfacture	Valider
Numfact_type	_	A ajouter
Libellefact_type	_	A ajouter
Numpt	Numpt	A ajouter
Libellept	Libellept	A ajouter
Num_tva	_	A ajouter
Taux_TVA	_	A ajouter
NumBS	NumBS	Valider
DateBS	DateBS	Valider
_	DesignationBS	A ajouter
_	QuantiteBS	A ajouter
_	Prix_unitaireBS	A ajouter
NumBE	NumBE	Valider
_	DesignationBE	A ajouter
_	QuantiteBE	A ajouter
DateBE	DateBE	Valider
_	Numfs	A ajouter

128

_	Designationfs	A ajouter
_	Quantitefs	A ajouter
_	Prix_unitairefs	A ajouter
_	Datefs	A ajouter
_	Sortiefs	A ajouter
_	Entreefs	A ajouter
Numapoff	Numapoff	Valider
Libelleapoff	Libelleapoff	Valider
Dateapoff	Dateapoff	Valider
NumBL	NumBL	Valider
LibelleBL	LibelleBL	Valider
NumBC	NumBC	Valider
DateBC	DateBC	Valider
_	DesignationBC	A ajouter
_	QuantiteBC	A ajouter
_	Prix_unitaireBC	A ajouter
Numcomtype	_	A ajouter
Libellecomtype	_	A ajouter
_	NumBP	A ajouter
_	LibelleBP	A ajouter
_	DateBP	A ajouter
_	Quantite_facture	A ajouter

129

_	Prix_unitaire_facture	A ajouter
_	NumBA	A ajouter
_	DesignationBA	A ajouter
_	Prix_unitaireBA	A ajouter
_	NumBC_Sev	A ajouter
_	NumServ	A ajouter
_	NomServ	A ajouter
_	DesignationBC_SERV	A ajouter
_	QuantiteBC_Serv	A ajouter
_	NumEMD	A ajouter
_	LibelleETM	A ajouter
_	Nums	A ajouter
_	Designations	A ajouter
_	Prix_unitaires	A ajouter
_	Quantites	A ajouter
_	Dates	A ajouter

VI.3. Validation des attributs et des cardinalités

CONCEPTUEL	EXTERNE	CARDINALITES		Validation
		CONCEPTUEL	EXTERNE
Etablir 3	_	[(1,1) (1, n)]	_	A ajouter

130

Gerer	_	[(1,1) (1, n)]	_	A ajouter
_	Contenir	_	[(1, n) (1, n)]	A ajouter
_	Contenir_1	_	[(1, n) (1, n)]	A ajouter
_	Figurer	_	[(1, n) (1, n)]	A ajouter
_	Lister	_	[(1, 1) (1, n)]	A ajouter
Fournir	Fournir	[(1, n) (1, n)]	[(1, n) (1, n)]	Valider
Etablir 2	_	[(1, n) (1, 1)]	_	A ajouter
Etablir 4	_	[(1, n) (1, 1)]	_	A ajouter
Concerner	contenir	[(1, n) (1, n) (1,n)]	[(1, n) (1, n)]	A ajouter
Concerner 3	Concerner	[(0, n) [1,n)]	[(1, n) (1, n)]	A ajouter
Recevoir	_	[(0, n) (0, n)]	_	A ajouter
Contenir	Concerner	[(1, n) (1, n)]	[(1, n) (1, n)]	Valider
Etablir	Etablir	[(1, 1) (0, n)]	[(1, 1) (1, n)]	A ajouter
Concerner 5	Contenir	[(1, n) (1, n) (1,1)]	[(1, n) (1, n)]	A ajouter
Etablir 1	_	[(1, n) (1, n)]	_	A ajouter
Commander	Demander	[(1, n) (0, n)]	[(1, n) (1, n)]	A ajouter
Soumettre	_	[(0, n) (0 n)]	_	A ajouter
Etre 1	_	[(1, 1) (1, n)]	_	A ajoutter
Concerner 1	Contenir	[(1, n) (1, n)]	[(1, n) (1, n)]	Valider
Appartenir 1	_	[(1, 1) (1, n)]	_	A ajouter
_	Recevoir	_	[(1, n) (1, n)]	A ajouter

131

_	Concerner	_	[(1, 1) (1, n)]	A ajouter
_	Contenir	_	[(1, n) (1, n)]	A ajouter
_	Lister	_	[(1, 1)(1,1) (1, n)]	A ajouter
_	Concerner	_		A ajouter
Contenir	Contenir	[(1, n) (1, n)]	[(1, n) (1, n)]	Valider
Etre 2	Etre	[(1, 1) (1, n)]	[(1, 1) (1, n)]	Valider

132

VII. MCD Validé



Numfact type Libellefact_type

NumBA DesignationBA QuantiteBA

Facture_type

Bon d'achat

Concerner_1

11

Bon_Commande

NumBC DesignationBC QuantiteBC Prix UnitaireBC DateBC

1,n

1,1

1,n

Num tva Taux_TVA

TVA

1,n

1,n

Etablir 1

Appartenir 1

1,n

Numserv Nomserv Tel_Major Tel_Secretaire

Concerner Date_achat

1,n

1,1

0,n

Service

1,1

1,1

Commande_type

Numfact Designationfacture Quantite_facture Prix_unitaire_facture Datefact

Numcomtype Libellcomtype

Soumettre

Produit_type

Numpt Libellept

Concerner

1,n

Facture

1,n

Concerner 5

Fournir

QuantiteBC

1,n

1,n

Commander

Qtecmd
Qteservi

1,1

NumEMD Libellé

1,n

Etat mensuel des dépenses

Etre 2

<In
<In

Etablir 3

Quantitefact

Concerner 1

Recevoir_2

Concerner 7

0,1

1,n

1,1

1,n

1,n

1,n

Matricule Prenom_M Nom_M Tel_M Adresse_M

Magasinier

Nump

Designationp

Prix Unitairep Quantite_stock Date_Mise_en_stock

Qte_fourni Prix_unitair Date

1,n

1,n

1,n

Produit

0n

1,n

Fournisseur

Numf Nomf Prenomf Adressef Tel_f

1,n

1,n Etablir 2 1,n

1,1

QuantiteBL Prix UnitaireBL

1,n

Etablir

Contenir

1,n

1,n

0,n

Gerer

1,1

QuantiteBE

Concerner

1,n

Recevoir

Bon_Livraison

NumBL DesignationBL

1,n

NumBP LibelleBP DateBP

Bon_paiement

1,n

Bordereau_Entrees

NumBE
DateBE

Numstock Libelle_stock

1,n

0,n

Stock

1,1

1,n

1,n

Lister

Numapoff Libelleapoff Dateapoff

Appel Offre

1,n

Quantite Prix_unitaire Date

1,n

Contenir

1,n

Numfs Rublique_budgetaire Designationfs Quantitefs

Prix_unitairefs

Datefs sortiefs Entreefs

Subir

Fiche_stock

Concerner 3

1,1

1,n

1,1

Nums Designations Quantites Prix_unitaires Dates

Etablir 4

Soumission

NumBS
DateBS

Bordereau_sorties

0,n

133
ANALYSE DE LA GESTION DE STOCK ET DE L'APPROVISIONNEMENT DE L'HOPITAL PRINCIPAL DE DAKAR PAR Dismas MANIRAKIZA, ETUDIANT A L'INSTITUT

SUPERIEUR D'INFORMATIQUE DE DAKAR

VIII. MLD

NIVEAU	DONNEES	TRAITEMENT
Niveau conceptuel	MCD	MCT
Niveau organisationnel	MLD	MOT

VIII. 1. Définition Règles de passage du MCD au MLD
1ère Règle : Relation de type « Père-Fils »

Fils	Père
(0,1)	(0, n)
(0,1)	(1, n)
(1,1)	(1, n)
(1,1)	(0, n)

Le père est celui dont la cardinalité maximale est n tandis que le fils est celui dont la cardinalité maximale est 1.

Remarque :

Tous les objets deviennent des tables en conservant leurs identifiants La relation disparaît

La clé du père migre vers le fils

Ex :



Codes Libellés

Classe

1,n

S'inscrire

1,1

Matricule Nom

Prenom

Etudiant

Possèder

1,1

1,n

Ref Titre

Livre

134

Classe (Code, Libellé)

Etudiant (Matricule, Nom, Prénom, #code) Livre (Ref, Titre, #Matricule)

2ème Règle : Relation plusieurs à plusieurs

Fils	Père
(0, n)	(0, n)
(0, n)	(1, n)
(1, n)	(1, n)

Remarque :

o Tous les objets deviennent de stables en conservant leurs identifiants

o La relation devient une table dont la clé primaire sera la concaténation des clés primaires des objets participant à la relation

o Eventuellement, si la relation possède d'attribut, ces attributs iront dans la table nouvellement créée.

Ex :



Codes Libbes

Numprof Nomprof Prenomprof

Salle

Professeur

1,n

1,n

Enseigner

Jour

Heure début Heure fin

1,n

1,n

CodeM LibelleM

Matière

Codec Libelléc

Classe

135

Classe (Codec, libellec)

Professeur (Numprof, Nomprof, Prenomprof)

Matière (CodeM, LibelleM)

Salle (Codes, Libelles)

Enseigner (codec,Numprof,CodeM,Codes,Jour ,Heure début, Heure fin)

3ème Règle : Les autres cas

Le père est celui qui a pour cardinalité (0,1)

CARDINALITE MAXIMALE		CARDINALITE MINIMALE
Père	Fils	Père	Fils
n	1	0	1

Le fils est celui qui a pour cardinalité (1,1) Ici, on applique la 1^ère règle (Père - fils)

Ex :



Avoir

0,1

Nmembre Nom

Prenom

Membre

Carte

Ncarte DareEditio

Identifiant

1,1

Carte (Ncarte, DateEdition, #Nmembre) Membre (Nmembre, Nom, Prénom)

*Cas de : (0,1) - (0,1) = (0,n)(0,n)

On applique la 2^ème règle (plusieurs à plusieurs) Ex : Mariage à l'Eglise catholique

136



CodeH NomH

Homme

<p

0,1

Se marier

Date
Lieu

<In
<In



0,1

CodeF NomF

Femme

Homme (CodeH,NomH)

Femme (CodeF,NomF)

Se marier (CodeH,CodeF, Date, Lieu) *Cas : de (1,1) - (1,1)

Ce cas n'existe pas dans un MCD ; pour cela, on fusionne les objets pour avoir un seul objet.

Ex :



Ncand Nomcand

Candidat

1,1

Avoir

1,1

Nparti
Nomp

Parti

<

Un seul objet et les propriétés des deux relations appartiennent à ce dernier (migrent dans ce dernier).



NElect Ncand Nparti Nomp Nomcand

Election

VIII.2. MLD DU MCD VALIDE

Facture_type (Numfact type, libellefact_type)

Facture (Numfact, Designationfacture, Quantite_facture,

Prix_unitaire_facture, Datefact, #Facture_type, #Matricule)

Produit_type(Numpt, Libellept)

Magasinier (Matricule, Prenom_M, Nom_M, Tel_M, Adresse_M) Concerner 1 (Numfact, Nump, Quantitefact)

137

Produit(Nump,Designationp,Quantite_stock,Prix_unitairep, Date_mise_en_stock, #Numpt, # Numstock, #Num_tva)

Stock (Numstock, Libelle_stock)

Etablir 4 (Matricule, NumBS)

Bordereau_sorties (NumBS, DateBS, #Numfs)

Fiche_stock (Numfs, Rubrique_budgetaire, Designationfs, Quantitefs, Prix_unitairefs, Datefs, Sortiefs, Entreefs)

Bordereau_Entrees (NumBE, DateBE, #Numfs)

Etablir 2 (Matricule, NumBE)

Concerner (Nump, NumBE, QuantiteBE)

Concerner 3 (Nump,Numapoff)

Contenir (NumBP, NumBL, Quantite,prix_unitaire,Date) Bon_paiement (NumBP, LibelleBP, DateBP)

Bon_Livraison (NumBL, DesignationBL, #Numfour)

Fournisseur (Numfour, Prenomfour, Nomfour,Tel_four,Adressefour, E_mail_four, Site_web_four)

Recevoir (Numfour,Numapoff)

Appel offre (Numapoff, Libelleapoff, Dateapoff)

Soumission (Nums, Designations, Quantites, Prix_unitaires, Dates, #Numapoff)

Bon_commande (NumBC, DesignationBC, QuantiteBC, Prix_unitaireBC, DateBC, #Numapoff, #NumEMD, #Numfour)

Etat mensuel des depensees (NumEMD, Libelle) Commande_type (Numcomtype, Libellecomtype) Concerner 5 (Numcomtype,NumBC, Nump, QuantiteBC)

138

Service(Numserv, Nomserv,Tel_Major, Tel_Secretaire) Etablir 1 (Numserv,NumBC)

Commander (Nump, Numserv,Qtecmd,Qteservi) Fournir (Nump,Numfour,Qte_fourni,Prix_uitaire,Date) TVA (Num tva, Taux_TVA)

Bon d'achat (NumBA, DesignationBA,QuantiteBA, #NumBC) Concerner (NumBA,Nump)

139

CONCLUSION

Cette étude visait à améliorer la gestion de stock et l'approvisionnement de l'Hôpital Principal de Dakar (HPD). Le dispositif actuel de gestion de stock et d'approvisionnement de cet hôpital connaît une certaine lenteur suite à la non informatisation des stocks et la non automatisation de la gestion de stock et d'approvisionnement. Les procédures sont presque manuelles.

L'informatisation des stocks, l'automatisation de la gestion des stocks et
d'approvisionnement, peut procurer un gain important dans la gestion du

temps pour avoir toute information dont on a besoin en temps réel et ^ainsifacilter la gestion.

140

BIBLIOGRAPHIE Mémoire Papa Laity Diop promotion 2005/2007

Cours par correspondance préparatoire à l'EA2/FS/E5 du BSTAT Domaine MSI

Comprendre Merise outils conceptuels et organisationnels de Jean Patrick MATHERON

WEBOGRAPHIE

www.hpd.sn

www.commentçamarche.com

www.africacomputing.com

141

www.marhepublic.sn

ANNEXE

HOPITAL PRINCIPAL DE DAKAR

Cellule d'Information Médicale Poste : 58 15

CODES SERVICES

CODES	SERVICES
41	BREVIE
42	JAMOT A
43	PELTIER
44	BOUFFLERS
47	PSYCHIATRIE
49	M. SANE
52	SOHIER A
53	LAPALLE
54	FUSTEC
56	MATERNITE
59	SOHIER B

142

61	OPHTALMOLOGIE
62	O R L
63	STOMATOLOGIE
65	REANIMATION
71	CRECHE
72	PEDIATRIE A
73	PEDIATRIE B
81	U S I C
82	SUC SOHIER B
85	UHCD
91	ORTHO II
37	SAU

143