WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

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

( Télécharger le fichier original )
par Dismas MANIRAKIZA
Institut supérieur d'informatique de Dakar - Brevet de technicien supérieur en informatique 2009
  

Disponible en mode multipage

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

    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 : manidis1985@hotmail.com.

    - 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 mamab@gamail.com

    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






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Qui vit sans folie n'est pas si sage qu'il croit."   La Rochefoucault