Conception et réalisation d'un système d'information pour le suivi des commandes des pièces de rechange à Toyota Algérie SPA

Conception et réalisation d'un système
d'information pour le suivi des commandes
des pièces de rechange
TOYOTA ALGÉRIE SPA

GHEMATI Mohamed Lamine

2007/2008

Promotion 2007/2008

Ministère de l'enseignement supérieur et de la recherche
scientifique

Institut National de formation en Informatique (INI)
Oued Smar - Alger

MÉMOIRE DE FIN D'ÉTUDES

Pour l'obtention du diplôme d'ingénieur d'état en informatique
(Option système d'information)

Thème :

Conception et réalisation d'un système d'information pour le suivi
des commandes des pièces de rechange

TOYOTA ALGERIE SPA

Document de base

Réalisé par : Encadré par :

GHEMATI M^ed Lamine Mme BOURBON Nedjma

(c) GHEMATI Mohamed Lamine, 2008.

INSTITUT NATIONAL D'INFORMATIQUE

Conception et réalisation d'un système d'information pour le
suivi des commandes des pièces de rechange

GHEMATI Mohamed Lamine
TOYOTA ALGÉRIE SPA

MEMOIRE PRÉSENTÉ EN VUE DE L'OBTENTION

DU DIPLÔME D'INGENIEUR D'ETAT EN INFORMATIQUE
(SYSTEMES D'INFORMATION)

JUIN 2008

REMERCIEMENTS

Au nom de Dieu le Miséricordieux

Je voudrais adresser mes remerciements les plus sincères aux enseignants et à tout le personnel de l'INI pour tout ce qu'ils m'ont apporté durant mon cursus.

Je tiens à remercier aussi chaleureusement toute l'équipe de Toyota Algérie pour leur accueil, leur aide et leurs encouragements tout au long de cette année, toute l'équipe du CPD et surtout Mme BELLOUCIF, DJALAL, IMENE et spécialement Mme BOURBON Nedjma, qui a consenti beaucoup d'efforts pour que je puisse accomplir ma tâche dans les meilleures conditions, ainsi que toute l'équipe du CPD.

Je dédie ce mémoire à mes très chers parents que j'aime et qui n'ont jamais été avares de quoi que ce soit afin de m'offrir tout ce dont j'avais besoin, et sans qui je n'aurais sans doute jamais pu réussir dans ma vie (que DIEU les préserve de tous les malheurs), à NAZIM, à AMIRA, à toute ma famille et mes proches, vivants ou disparus, et à tous ceux qui m'ont soutenu et à qui je dois ce travail et qui se reconnaîtront.

En dernier lieu, c'est à toi que je dédie ce travail, parce que tu as toujours été là pour moi. Dans les moments les plus durs et les plus pénibles, tu as su me remonter le moral et me pousser à m'accrocher et à me remettre au travail quand je n'avais plus de force, je ne sais pas ce que j'aurais fais sans toi.

MERCI KAHINA.

Résumé de l'étude

Notre étude à porté sur la gestion des commandes de la pièce de rechange au niveau de TOYOTA ALGERIE. Le processus principal consiste à calculer les quantités de réapprovisionnement, d'émettre des commandes, de suivre l'état de ces commandes jusqu'à la réception des marchandises et de contrôler les factures correspondantes.

Le volume important des données traitées lors de ce processus (plus détaillé en problématique), et l'absence d'outils automatisés empêchent parfois le bon accomplissement des différentes tâches par les employés qui, à répétition, peut provoquer des pertes à l'entreprise à moyen et long terme.

L'exemple suivant illustre parfaitement ce problème : à l'arrivée d'une facture, les prix mentionnés ne sont pas vérifiés et comparés avec les prix à la commande. Une différence peut passer inaperçu, et l'accumulation de ces différences s'avère désastreuse pour la société.

Nous avions donc pour but d'apporter des solutions en proposant des changements des procédures en cours actuellement et une application capable de traiter les commandes avec le volume actuel et plus, selon les besoins futurs de l'entreprise. Et pour cela nous avons conçu un système en nous basant complètement sur l'avis des utilisateurs, et en suivant une méthode qui repose sur trois aspects : fonctionnel, statique et dynamique guidé par les diagrammes du langage UML.

Enfin, pour la réalisation du projet nous avons pris en compte le fait que l'application sera intégrée à l'ERP ORACLE qui est en plein phase de paramétrage par l'équipe du département informatique de TOYOTA ALGERIE.

Conclusion ..44

SOMMAIRE

Introduction 12

Présentation générale de l'organisme d'accueil	..13
Toyota Motors Corporation	13
Toyota Algérie	15
Daihatsu - Hino	..16
Organigramme de TOYOTA ALGÉRIE	17
Situation informatique de TOYOTA ALGERIE	18
Présentation du cadre de l'étude	..19
Organigramme de la division pièce de rechange	.20
Problématique	..22
Objectifs de l'étude	..24
PARTIE 1 : Synthèse de l'étude de l'existant
Description du système actuel	26
Etude des postes et procédures de travail	27
Présentation des principaux documents manipulés au CPD envoyés par le fournisseur TME	..31
Diagramme de flux d'informations INVENTORY	.32

Diagramme de flux d'informations entre structures INVENTORY-RECEPTION 34

Diagramme de circulation des informations 35

Lecture du DCI 37

Méthodes de transmissions des commandes 38

Les différents types de commandes 39

Diagramme d'activité ..40

Analyse critique .42

Projection des futurs besoins 43

PARTIE 2 : Etude conceptuelle

Introduction & Objectifs du nouveau système 46

Présentation de la démarche adoptée ..47

SECTION É : Modélisation fonctionnelle .48

Identification des acteurs du système	49
Diagramme de contexte statique	50
Identification des cas d'utilisation	.50
Diagramme des cas d'utilisation	52
Description des cas d'utilisation	53
Regroupement en packages	63
SECTION ÉI : Modélisation statique	64
Détermination des classes candidates	65
Les règles de gestion & diagramme des classes final	68
Classes et attributs de classes	69
SECTION ÉII : Modélisation dynamique	.73

Diagrammes de séquence ..74

Diagrammes d'états-transitions .83

PARTIE 3 : Réalisation de la nouvelle application

PASSAGE AU MODÈLE RELATIONNEL		86
Schéma de la base de données		86
Script de création de la base de données		87
Architecture globale de la nouvelle application		..94
Présentation des outils de développement		96
Choix du langage	96
Choix du SGBD	.96
ASPECT SÉCURITÉ	97
Aperçu de la nouvelle application	99
CONCLUSION GÉNRÉALE	..103
BIBLIOGRAPHIE & WEBOGRAPHIE	.105

LISTE DES FIGURES :

FIG. 01 : Organigramme de l'entreprise TOYOTA ALGÉRIE SPA 15

FIG. 02 : Organigramme de la division pièce de rechange de TOYOTA ALÉGRIE 18

FIG. 03 : Processus d'une commande client ..26

FIG. 04 : Diagramme de flux d'informations INVENTORY 43

FIG. 05 : Diagramme de flux d'informations entre structures 45

FIG. 06 : Diagramme de circulation des informations ..76

FIG. 07 : Toyota Network System Overseas (TNS-O) .78

FIG. 08 : Échange de Données Informatisé 78

FIG. 09 : Diagramme d'activité .80

FIG. 10 : Diagramme de contexte statique 89

FIG. 11 : Diagramme de cas d'utilisation .89

FIG. 12 : Catégories de cas d'utilisation ..102

FIG. 13 : Diagramme de classes candidates N°1 ....104

FIG. 14 : Diagramme de classes candidates N°2 .105

FIG. 15 : Diagramme de classes candidates N°3 .105

FIG. 16 : Diagramme de classes candidates N°4 .106

FIG. 17 : Diagramme de classes ..107

FIG. 18 : Diagramme de séquence N°1 113

FIG. 19 : Diagramme de séquence N°2 114

FIG. 20 : Diagramme de séquence N°3 115

FIG. 21 : Diagramme de séquence N°4 116

FIG. 22 : Diagramme de séquence N°5 117

FIG. 23 : Diagramme de séquence N°6 118

FIG. 24 : Diagramme de séquence N°7 119

FIG. 25 : Diagramme de séquence N°8 120

FIG. 26 : Diagramme de séquence N°9 121

FIG. 27 : Diagramme d'états-transitions N°1 ..122

FIG. 28 : Diagramme d'états-transitions N°2 ..123

FIG. 29 : Diagramme d'états-transitions N°3 ..123

FIG. 30 : Schéma relationnel de la base de données 124

FIG. 31 : Architecture de la nouvelle application 134

FIG. 32 : Exemple de code QR 134

LISTE DES TABLEAUX :

TAB. 01 : Liste des cas d'utilisation 90

TAB. 02 : La classe Piece .108

TAB. 03 : La classe Piece-ICC .108

TAB. 04 : La classe Piece-CMD ...108

TAB. 05 : La classe Piece-SUB 109

TAB. 06 : La classe Ligne-Commande .109

TAB. 07 : La classe Commande 109

TAB. 08 : La classe Facture .109

TAB. 09 : La classe Ligne-Facture 109

TAB. 10 : La classe Expedition 110

TAB. 11 : La classe Etat-Comptable 111

TAB. 12 : La classe Reception ..111

TAB. 13 : La classe Fournisseur 111

TAB. 14 : Mesures sécuritaires à entreprendre .137

Liste des abréviations :

CPD: Central Part Division; C'est la division de la pièce de rechange.

TPS: Toyota Production System (Système de production Toyota)

TA: Toyota Algérie

INV: Invoice (Facture)

POSS: Parts Order Status Sheet (Rapport de l'état des commandes)

BO: Back Order (Commandes ajournées)

TME: Toyota Motors Europe; Fournisseur des pièces de rechange de Toyota Algérie

TMC: Toyota Motors Corporation; La maison mère de Toyota

EDI: Electronic Data Interchange (échange de données informatisé)

PDR: Parts Discrepancy Report (rapport de l'état des pièces reçues)

SMR: Spare Parts Mispacking Report (rapport de l'état des pièces reçues)

NMPL: New Modal Part List (Liste des nouvelles références)

ERP: Entreprise resource planning (Progiciel de gestion intégré)

UML: Unified Modeling Language (Langage de modélisation unifié)

INVENTORY MANAGEMENT: Service gestion de stock.

LOST SALES: Ventes perdues ou non effectuées.

ON HAND: Quantité en stock actuellement.

ON ORDER: Quantité en commande.

MIP: Maximum Inventory Position ; La quantité maximale tolérée en stock

SOQ: Suggested Order Quantity ; Quantités quotidiennes à commander

MAD : Monthly Average Demand ; c'est la demande moyenne mensuelle.

O/C : Order Cycle ; ou cycle de commande, c'est le nombre de commandes par mois.

L/T : Lead Time ; ou Délai de livraison, temps séparant la commande de l'entrée physique en

stock (système)

SSdemand : Safety Stock for demand ; ou stock de sécurité pour la demande, cela couvre la

fluctuation de la demande.

SSl/t : Safety Stock for Lead Time ; stock qui couvre la fluctuation du délai de livraison.

INTRODUCTION

GÉNÉRALE

12

Introduction

INTRODUCTION :

Il n'est plus à démontrer de nos jours que le service après vente a une importance fondamentale dans le secteur de l'automobile, et que c'est un facteur déterminant dans le succès des entreprises. Ce service peut néanmoins être défaillant si les pièces de rechange requises pour la maintenance ou l'assistance technique ne sont pas disponibles à temps.

Un autre facteur de ce succès est tout simplement la disponibilité de la pièce de rechange pour les particuliers, spécialement dans notre pays où les accidents de la route sont fréquents et où les pièces sont rapidement usées à cause de l'état du réseau routier.

La gestion des achats de la pièce de rechange, le suivi des commandes et du transport des marchandises jusqu'à leur réception apparaît dès lors comme une étape stratégique à ne pas négliger pour la réussite du processus global de vente et pour la satisfaction du client.

Toyota Algérie, qui est leader des ventes de véhicules, a conscience de l'évolution de ce secteur et de l'augmentation du nombre de pièces qui accompagnent chaque nouveau modèle introduit sur le marché et veut réduire ses pertes financières liées à la gestion de la pièce de rechange en mettant en place un nouveau système qui devra garder une trace et informer de l'état de chaque commande à tout moment, c'est-à-dire de la préparation et l'envoi de la commande jusqu'à l'entrée en stock de la marchandise.

C'est dans ce cadre que s'inscrit notre étude qui s'intitule conception et réalisation d'un système d'information pour le suivi des commandes des pièces de rechange au niveau de l'entreprise Toyota Algérie SPA.

Ce système doit être un véritable pont qui relie entre les différents fournisseurs de Toyota Algérie, son service des achats de la pièce de rechange ainsi que du service de réception pour que l'opération d'acquisition de la marchandise soit optimale et réponde à une demande de plus en plus croissante en raison de l'explosion du marché de l'automobile en Algérie.

13

Présentation générale

Présentation générale de l'organisme d'accueil

TOYOTA MOTOR CORPORATION (TMC)

L'entreprise Toyota est l'un des plus grands constructeurs automobiles au monde.

Créée en 1937 par Kiichiro Toyoda, la firme Toyota Motors Corporation (TMC) dont le siège principal est à Toyota (une ville qui se trouve à proximité de Nagoya) se classe parmi les dix premières entreprises dans le monde (selon le magazine fortune portant classement des 500 plus grandes entreprises au monde, édition 2006), et ceci grâce à la vente de ses véhicules, tous modèles confondus (y compris DAIHATSU ET HINO) et qui vient de dépasser cette année le chiffre de 8,8 millions d'unités.

L'une des clés de cette réussite : la FLEXIBILITE

L'expérience Toyota s'est forgée en repoussant toujours plus loin les limites de la technologie industrielle, en développant un système de contrôle de qualité ainsi qu'une organisation et un système de production devenus un modèle pour les industriels du monde entier. Ce dernier se caractérise notamment par l'approvisionnement de la pièce détachée selon la demande, au bon endroit et au bon moment, en quantités suffisantes et sans gaspillage.

Afin d'éviter tout stock inutile, et contrairement à ce qui se faisait généralement dans ce domaine, le système de production de Toyota (TOYOTA PRODUCTION SYSTEM ; TPS) est conçu de telle sorte que seule la production répondant à une demande précise, à un moment donné, sorte des chaînes de fabrication.

En outre, Toyota a mis en place un système de réactivité basé sur un processus d'amélioration constante qui lui a permis d'enregistrer des temps records de reconfiguration de machines et de changements de moules pour les nouvelles pièces, bien au-delà de ceux établis par la concurrence.

Il est à préciser que le système TPS, qui se base aussi sur la valeur de l'engagement du personnel et la qualité, est une des plus grandes contributions de Kiichiro Toyoda.

14

Présentation générale

La philosophie du groupe Toyota (Toyotisme):

Nous allons à présent détailler un peu plus ce système de production Toyota. Celui-ci repose sur plusieurs méthodes d'organisation et de gestion de production. Nous proposons la présentation des trois méthodes les plus pertinentes :

1- Le juste-à-temps : C'est l'ensemble des techniques logistiques visant à améliorer le
retour sur investissement d'une entreprise en réduisant les en-cours de production, les stocks et les coûts induits par ces stocks. Il se base entre autres sur des signaux visuels tel l'absence d'un produit sur une étagère ou sur un tableau à fiches (étiquette, ou Kanban en japonais), ce qui induit la mise en production (ou de la commande) du produit manquant.

2- Le KAIZEN : Le mot Kaizen est la fusion des deux mots japonais kai et zen qui
signifient respectivement « changement » et « bon », pris ensemble, cela signifie l'amélioration continue. Le Kaizen est une démarche qui repose sur des petites améliorations quotidiennes recherchées par chaque travailleur sur son lieu de travail, ce qui a pour effet de réduire les investissements financiers en matière de recherche de solutions et d'innovations. Cette démarche est conditionnée par la motivation des employés.

3- Le KANBAN : Le terme Kanban signifie simplement « fiche » ou « étiquette » en
japonais. Cette méthode a été inventée par l'ingénieur Japonais Taiichi Ohno. C'est une sorte de mini système d'information qui relie deux postes de travail « adjacents » dans un système de production généralement répétitif. Le poste en aval transcrit les opérations à effectuer si cela est nécessaire sur le Kanban et le passe au poste en amont et celui-ci le retourne en arrière en cas de besoin. Ainsi, l'opération en amont doit produire uniquement la quantité de matière nécessaire pour l'opération en aval.

Ces méthodes et techniques sont devenues une philosophie appelée Toyotisme et qui tend à réaliser l'objectif dit des cinq zéros : zéro panne, zéro défaut, zéro papier, zéro délai, zéro stock.

Actuellement, la firme Toyota concentre ses recherches pour construire des véhicules propres, respectueuses de l'environnement et contribuer à lutter contre les émissions nocives et le réchauffement de la planète. Elle s'est engagée en faveur du développement

15

Présentation générale

durable en produisant notamment des voitures hybrides ou totalement électriques. Elle est aussi leader dans le domaine des piles à combustible utilisées dans ce genre de véhicules.

TOYOTA ALGERIE

Toyota s'est implantée en 1993 en ALGERIE sous son ancien nom JALCO (Jameel ALgérie COmpany) spa. Ses ventes, cette année là, atteignirent les 232 véhicules, alors qu'en 2006 on enregistrait plus de 23 000 véhicules vendus (tout types confondus), ce qui place les ventes des véhicules Toyota parmi les meilleures en Algérie. Cette performance est le fruit des efforts faits pendant toutes ces années pour répondre aux attentes d'une clientèle de plus en plus exigeante en matière de fiabilité, de confort, d'esthétique, de puissance et bien sûr tout en étant économiquement concurrentiel.

De plus, Toyota Algérie a renforcé sa percée notamment par :

- Un réseau de distribution fort de ses 36 concessionnaires et 5 succursales (Alger, Ouargla,

Annaba, Oran et Blida) assurant une des meilleures couvertures du territoire Algérien ;

- Un souci constant de satisfaire sa clientèle ;

- Une garantie de 2 ans pour tous les véhicules Toyota ;

- Une pièce de rechange disponible.

Le capital social de Toyota Algérie est de 400.000.000 DA.

La superficie globale du siège sis à HYDRA est de 21 000 m², répartie comme suit :

- Direction générale: 6200 m²

- Stock véhicules: 6200 m²

- Magasins de pièces de rechange: 4450 m²

- Atelier réparation: 3000 m²

- Show room: 1300 m²

16

Présentation générale

FILIALES DE TOYOTA :

Le groupe Toyota est aussi propriétaire de plusieurs autres marques; dont Lexus, Scion (marque disponible uniquement aux Etats-Unis), Hino (marque de camions) et Daihatsu.

DAIHATSU

Daihatsu est le plus ancien constructeur automobile japonais. En effet, depuis 1907, il est spécialisé dans la production de véhicules compacts et détient à lui seul 8% du marché japonais. Cette firme ; dont 51% du capital est détenu par le groupe Toyota contribue activement au développement et à la recherche dans le domaine du Compact Cars et du respect de l'environnement.

HINO

La vente des poids lourds HINO a été reprise récemment par Toyota Algérie, une marque qui appartient à TMC depuis 1966. L'entreprise HINO a été fondée en 1910 et commença ses activités le 1er mai 1942. HINO commercialise une gamme importante de véhicules : des camions, des autobus, des véhicules utilitaires légers, des véhicules de transport, ainsi que divers types de moteurs et de leurs pièces détachées.

Ces deux dernières marques étant commercialisées en Algérie, Toyota s'occupe exclusivement de la distribution de leur pièce de rechange au niveau national.

17

Présentation générale

18

Présentation générale

Situation informatique de TOYOTA ALGERIE

Nous allons présenter en quelques lignes la situation informatique globale de TOYOTA ALGERIE (siège social) afin d'avoir une petite idée sur les capacités réelles de l'entreprise.

Parc informatique :

Toyota Algérie dispose d'un matériel assez conséquent et relativement neuf, car soumis à une politique de renouvellement constant. Ces chiffres relatent l'importance de son parc informatique :

- 500 Desktops

- 100 Laptops

- 250 Imprimantes

- 40 Serveurs

15 Switch

-

- 10 Routeurs

- 3 Firewall

- 2 Modems

Applications informatiques et licences :

Les principales applications utilisées à Toyota Algérie sont :

- SAGE Line 100 (Commercial, comptabilité, CPD, Service après vente)

- ERP Oracle E-Buisness Suite (Immigration imminente vers ce progiciel)

- Windows Server 2003

- KASPESKY Antivirus Pack

- EDI (Echange de données informatisé) : Ligne spéciale reliée au fournisseur de pièces

- Autres applications développées en interne

Standards de développement :

Pour la conception de logiciels en interne, l'équipe IT de l'entreprise Toyota Algérie privilégie le langage UML et les différentes méthodes qui l'utilisent, sans toutefois rejeter la méthode merise. Quand à la programmation, l'équipe favorise l'environnement DOT NET de MICROSOFT^(c) pour ses nombreux avantages ainsi que le SGBD ORACLE pour ses performances.

19

Présentation du cadre de l'étude

Présentation du cadre de l'étude :

La division pièce de rechange (Central Part Division)

Central Part Division (CPD) est la division de Toyota Algérie qui s'occupe de l'approvisionnement, du stockage, de la vente et de la distribution de la pièce de rechange de Toyota, Daihatsu et Hino sur tout le territoire national ainsi que des accessoires automobiles.

En plus du département administratif, la division comporte trois autres grands départements :

1- Ware/House Management : (Gestion des entrepôts et magasins) Ce département s'occupe de toutes les activités relatives au stock « physique » :

- La réception des marchandises, assurée par l'équipe « Receiving Operations »

- Le stockage dans l'entrepôt, assuré par l'équipe « Storage Management »

- Le déstockage des marchandises, assuré par l'équipe « Shipping Operations »

2- Sales & Marketing : (Ventes et marketing)

Ce département est chargé d'un coté de promouvoir les produits auprès des différents revendeurs et autres acheteurs potentiels, et d'un autre coté d'assurer sa principale tâche qui est la vente de la pièce de rechange, et cela concerne le traitement des commandes de tous les clients (Branches, revendeurs, atelier Toyota, particuliers....etc.) et la facturation.

3- Inventory Management : (Gestion de stock)

C'est le département le plus concerné par notre étude. Son rôle est de contrôler et réguler les quantités présentes en stock en suivant les standards de la société Toyota Motors Corporation, d'assurer le réapprovisionnement quotidien auprès des différents fournisseurs en prenant compte des commandes non satisfaites pour cause d'indisponibilité, de la demande quotidienne, des délais de livraisons et des niveaux d'alerte de chaque référence déjà présente en stock.

20

Présentation du cadre de l'étude

PROBLÉMATIQUE

&

OBJECTIFS DE L'ÉTUDE

22

Problématique & Objectifs

Problématique :

Grâce à son département `Inventory' qui gère les achats pour alimenter son magasin central, ses 05 succursales ainsi que ses 60 agents agrées, TOYOTA ALGERIE arrive, plus ou moins, à faire face à une demande moyenne de 1000 références/jour en quantités diverses et de plus en plus croissante, due principalement à l'augmentation des ventes de véhicules

qui croît d'une année à une autre d'une centaine d'unités (notamment avec le
développement du secteur du crédit à la consommation).

L'équipe de l'Inventory traite principalement avec le fournisseur européen de Toyota - Toyota Motors Europe (TME) - en lui adressant quotidiennement 01 commande de réapprovisionnement qui contient en moyenne quelques 500 lignes et quelques fois des commandes spéciales. La marchandise sera reçue et stockée par l'équipe de réception du CPD avant d'être distribuée aux branches de Toyota Algérie ou vendue aux particuliers.

Ce processus rencontre toutefois quelques problèmes que nous avons constatés à différents niveaux lors de notre étude, et que nous essaierons de résumer ainsi :

- Accès à l'information : La première des anomalies que nous avons remarqué et qui

nous a interpellé est cette difficulté à retrouver la bonne information, et ceci à cause des multiples versions des mêmes documents présentes dans chaque poste, avec des traitements propres à chacun, ce qui altère l'exactitude de la donnée, si ce n'est la perte d'une ou plusieurs informations chez quelques-uns et/ou l'absence d'une mise à jour de l'information chez d'autres personnes. D'autre part, il est parfois pénible d'obtenir des informations relatives aux références (ventes, ventes ratées...etc.) car il faut exporter du système SAGE (qui est parfois saturé par les multiple accès simultanés) des données brutes avant de les filtrer sous EXCEL, en sachant qu'il s'agit de 500 références au quotidien, et chaque référence est traitée en 1 minute environ. Il n'existe aussi aucun outil de recherche de données selon tel ou tel critère.

- Absence de vérification des prix : Chaque mois, le département de la pièce de

rechange reçoit sur support externe (CD-ROM) la liste des prix des 9000 références disponibles. Cette mise à jour est enregistrée sous forme de fichier ACCESS assez volumineux. Cette opération de conversion requiert 1 heure de temps. Ce fichier est accessible à travers l'intranet de la société, ce qui fait perdre en moyenne 15 minutes à celui qui recherche le prix d'une certaine pièce de rechange en raison du volume du fichier et du trafic dans le réseau. En outre, les commandes passées au fournisseur ne contiennent pas d'informations pouvant valoriser la marchandise commandée (prix unitaires et total de la commande), on ne connaît donc pas la valeur de la marchandise commandée. D'autre part, lors de la réception des factures fournisseur, il n y a aucune vérification des prix facturés par rapport aux prix des pièces lors du lancement de la commande. En effet les prix peuvent augmenter d'un mois à l'autre, et le fournisseur doit prendre en compte le prix d'une pièce affiché lors de la réception de la commande. Les différences ne sont souvent constatées que lors de la comptabilisation des factures, et donc trop tard pour émettre des réclamations.

Les pertes financières qui en résultent peuvent se chiffrer parfois en milliers de dollars.

Préposé à la

Réception et mise à jour du stock (01 journée) réception

J-25

23

Problématique & Objectifs

- Les références substituts : Le fournisseur procède quelquefois au remplacement des

références de quelques pièces, généralement par mesure de sécurité (pour éviter la contrefaçon). Le CPD en est informé par le biais d'un fichier adressé au chef de département qui ajoute cette donnée au système, mais comme celui-ci ne peut ajouter ces nouvelles références déjà présentes sur les systèmes des succursales ou bien leur associer les nouvelles références, les employés de ces branches utiliseront de fait deux ou plusieurs références ultérieurement sans savoir qu'elles désignent la même pièce de rechange. Il en résulte un problème de taille lors du comptage, de la prise de commande ou de l'inventaire car une pièce « X » peut être présente en stock en grandes quantités par exemple sous une référence substitut « X2 » et indisponible (dans le système) selon la référence X1, ce qui les amènent à commander cette pièce auprès du siège alors qu'ils la possèdent en stock. En sachant qu'autre que les pertes financières dues à ce problème (l'exemple d'un lot de références qui a coûté 23 000 $ retrouvé après l'inventaire de fin d'année au niveau de la branche de Annaba), le fournisseur peut ne pas livrer quelques commandes en raison des procédures de Toyota qui n'autorisent que des commandes en quantités justifiées.

Avec les dysfonctionnements que nous avons recensés, le processus suit actuellement le schéma suivant :

J-0

ICC

Traiter les données (01 journée) Classifier les données (1/2 journée)

MATRIX

Tri et calcul final (1/2 journée)

Calcul des quantités à commander (1/2 journée)

Préparateur Commandes

Etablissement des fichiers OnHand/BackOrder/OnOrder

(1/2 journée)

Suivi des marchandises (20 jours)

Suivi expéditions

Calcul coût de revient (1/2 journée)

24

Problématique & Objectifs

Ceci nous conduit à nous poser quelques questions pertinentes, telles :

- Comment peut-on réduire les pertes financières et de temps au niveau du CPD ?

- La centralisation des données est-elle une bonne alternative à la situation actuelle ?

- Comment coordonner les départements Inventory et réceptions pour assurer une

qualité de travail irréprochable et un rendement efficace ?

- Où et comment doit-on optimiser les tâches pour avoir une répercussion positive à
court, moyen et long terme sur toute l'entreprise ?

Objectifs de l'étude :

Les problèmes que nous avons recensés et qui sont expliqués dans la problématique démontrent de la nécessité de mettre en place une réelle application capable de gérer tous les aspects cités, en se basant d'abord sur l'organisation qui existe déjà tout en modifiant les points qui posent problème, et en mettant en place par la suite de nouvelles règles et/ou procédures qui auront essentiellement pour objectifs ce qui suit :

- Centraliser l'information cohérente et la mettre à la disposition des employés du

département et des succursales en temps voulu et leur permettre une bonne exploitation de celle-ci, notamment avec l'identification des références de substitut.

- Réduire de 2 à 3 jours la durée globale du processus.

- Réduire les pertes financières induites par la non vérification des prix à la facturation

(100%) et valoriser les commandes afin d'avoir une idée des coûts avant l'achat.

Étude de l'existant Étude des postes

PARTIE 1 :

Synthèse de

L'étude de l'existant

26

Étude de l'existant

Description du système actuel :

Les procédures en vigueur actuellement sont à moitié manuelles et à moitié informatisées. Les données sont stockées en local mis à part quelques fichiers qui se trouvent dans un répertoire accessible via le réseau local de l'entreprise. Par conséquent, les échanges de données entre les différents acteurs s'effectuent soit par e-mail, soit par l'intranet ou par supports externes pour des fichiers volumineux. Quelques informations sont extraites du système SAGE qui concerne plus les ventes et la gestion de stock des pièces, ce qui induit la plupart du temps des lenteurs causées par l'utilisation des ressources par plusieurs personnes de différents services simultanément.

Allant de la préparation de la commande jusqu'à la réception des marchandises, tout se fait sous fichiers EXCEL, transmis d'un poste à un autre avec quelques fois des copies papiers imprimés si nécessaire. La commande est cependant transmise au fournisseur sous un autre format pris en charge par un utilitaire qui transforme aussi les factures fournisseur en documents EXCEL.

Étude de l'existant Étude des procédures

27

Synthèse de l'étude des postes de travail

Postes de travail	Rôles
Chef de département	Assurer la coordination entre les postes ; Affecter les tâches et contrôler le travail accompli
Préparateur ICC matrix	Calculer les quantités maximales pouvant être stockées ; Préparer les rapports d'activités concernant les mouvements de stock ainsi que les indices de performance et les taux de service
Préparateur commandes	Calculer les quantités à commander ; Contrôler et mettre à jours les quantités commandées ; Etablir l'inventaire logique
Rédacteur de rapports	Etablir les différents rapports quotidiens, hebdomadaires et mensuels (ventes, comptes rendus....etc.) de la division pièce de rechange de toutes les succursales de TOYOTA ALGERIE
Suivi des expéditions	Assurer le suivi du déplacement physique des pièces commandées, des formalités administratives et douanières des importations et de la comptabilité
Préposé à la réception	Préparer et contrôler la réception des marchandises et leur entrée en stock et mise à jour des données

Étude de l'existant Étude des procédures

28

Synthèse de l'étude des procédures de travail

1/ Préparation de la matrice ICC (Inventory Class Control)

Cela consiste à recueillir différentes données sur chaque références afin d'appliquer des formules visant à obtenir comme résultats la quantité maximale devant se trouver en stock pour chaque pièce de rechange et une classification des références selon leur vitesse de rotation en stock

2/ Etablissement des commandes

Le principe est de calculer d'abord ce qu'on appelle la « quantité suggérée » pour chaque référence, quantité qui résulte de l'application d'une formule contenant le résultat de la procédure précédente ainsi que d'autres paramètres. Ces quantités seront généralement transformées en quantités commandées sauf cas spécial ou écart inattendu.

3/ Vérification et envoi des commandes

Après avoir préparé la commande, le chef d'équipe la transmet au chef de département pour vérification et l'envoie au fournisseur après d'éventuelles modifications.

4/ Suivi des expéditions

Le but de cette procédure est de connaître à chaque moment l'état des livraisons correspondant à telle ou telle facture pour réaliser le suivi au niveau des compagnies de transport et de transit ainsi que la douane, et pour planifier les futures réceptions au niveau du magasin central.

5/ Comptabilité

Le chargé de suivi des expéditions est aussi tenu d'assurer le calcul du coût de revient pour chaque livraison afin de faciliter le travail du service comptabilité en incluant toutes les charges supportées à chaque étape de l'acheminement des marchandises.

6/ Réception des marchandises

Lors de l'approche d'un arrivage, le chargé du suivi des livraisons informe le service de réceptions pour que celui-ci puisse préparer et planifier les tâches à effectuer selon le volume attendu ainsi que les étiquettes de réception et les différents rapports. Une fois la marchandise déchargée, elle sera vérifiée et mise en stock en signalant les anomalies et en mettant à jours les quantités entreposées.

Étude de l'existant Étude des procédures

29

Liste des documents étudiés :

- Back Order (Avant et après modification)

- POSS (Avant et après modification)

- Facture fournisseur TME (Avant et après modification)

R/A Code

-

-

Liste des prix TME (EPM)

- Rapport de clarification de commande (OCR)

- Suivi des commandes en attente (BO Follow up)

- Export BO clients

- Préparation de la commande

- Bon de commande

- Rapport de l'état des pièces reçues

- Suivi des factures TME

- Etat des factures

- Rapport de déchargement des marchandises

- Planification de réception

- Coût de revient

- Etiquette de réception

- Liste des nouveaux modèles

Étude de l'existant Présentation des documents

31

Présentation des principaux documents manipulés au CPD envoyés par le fournisseur TME :

1. Rapport de l'état des commandes (Parts Order Status Sheet ; POSS) : C'est un
document qui nous informe de la réception effective des commandes ainsi que des différents traitements relatifs aux pièces commandées. Exemples :

- Dans le cas d'un rejet d'une ligne commande, le POSS indique le code qui explique la

cause de ce rejet.

- Dans le cas d'un changement de référence d'un certain produit, le POSS nous informe
de ce changement en mentionnant la nouvelle référence à prendre en considération.

- Si un produit n'est pas disponible en stock chez le fournisseur, le POSS nous fait
savoir que la ligne commande correspondante sera en Back Order.

2. Facture fournisseur (Invoice INV) : Document qui, en plus d'informer des coûts
d'achat et de servir en comptabilité fournit des informations sur les produits facturés avant de les expédier ; Il inclut aussi quelques détails comme le numéro des caisses qui vont contenir chaque produit expédié, le temps approximatif de livraison, le poids, le volume...etc.

3. Rapport d'expédition (Shipment) : Contient des informations sur les containers, les
dates d'envoi et d'arrivée...etc.

4. Commandes ajournées (Back Order ; B/O) : Informe des pièces qui ne sont pas
disponibles en stock lors de la commande et donne un état estimatif du réapprovisionnement.

Etude de l'existant Diagramme de flux d'informations

32

Diagramme de flux d'informations du département INVENTORY

Nous allons à présent proposer un diagramme de flux d'informations du département concerné par notre étude et qui vise, d'une part, à visualiser les flux échangés entre différents acteurs du système et d'autre part l'établissement d'une liste des principaux documents circulant dans ce département.

Représentation graphique :

Etude de l'existant Diagramme de flux d'informations

(FIG. 04)

33

Liste des flux d'informations :

N° du flux	Description	Observation
1	Ventes, Back Orders et lost sales	A partir d'exports du SAGE
2	Back Orders des clients	A partir d'exports du SAGE
3	ICC Matrix (MIP pour chaque produit)
4	La commande (Daihatsu en particulier)
5	Demande de clarification de commande	Si la commande est jugée anormale
6	Rapport de clarification de commande (OCR)
7	Facture fournisseur (+POSS+BO)
8	Facture traitée
9	Suivi et état des factures et délais d'expédition
10	Demande de facture détaillée	Correspondant à l'expédition (à chaque réception imminente)
11	Facture détaillée
12	Rapport de l'état des pièces à la réception (PDR)	Si il y a écart à la réception
13	Rapport de l'état des pièces (SMR)
14	Suivi des backs orders (BOF)
15	Liste des prix (EPM)	Une fois par mois
16	Coût de revient + ETA	A chaque facturation
17	Etat et suivi des factures

Etude de l'existant Diagramme de flux d'informations

Diagramme de flux d'informations entre l'Inventory et le service de

réceptions :

(3)

(5)

INVENTORY
MANAGEMENT

SERVICE DES
RECEPTIONS

(1)

(3)

DFI N^°2

Représente les informations qui circulent entre l'Inventory

et le service des

réceptions

(FIG. 05)

34

Liste des flux d'informations :

N° du flux	Description	Observation
1	Suivi des factures et des délais d'expédition	Tous les documents sont des fichiers Excel partagés sur le réseau, mis à jours à chaque opération (donc il y a flux d'informations).
2	Etat des factures
3	Facture du fournisseur
4	Rapport de l'état des pièces reçues

Etude de l'existant Diagramme de circulation des informations

35

Le diagramme de circulation des informations (DCI):

Le diagramme de circulation des informations est un outil efficace pour cerner les différents processus d'une organisation et de visualiser plus clairement comment l'information circule dans une structure ou un service donné.

Il permet entres autres de :

- Détecter les données : Où sont-elles recueillies ? Où sont-elles traitées ? Qui a besoin de quelle information ? Où les informations sont-elles stockées ?

- Identifier les postes ou structures surchargés et mettre en évidence les goulots d'étranglement

- Observer les durées de vie et différents cycles par lesquels cheminent les différents documents

- Définir les principaux points de décision qui déterminent les chemins à emprunter.

Représentation graphique :

Etude de l'existant

Diagramme de circulation des informations

36

Temps

[CC MATRIX

Team leader

^Fournisseur (TMME)

Group leader

SuivE SHIPMENT

Service réceptions

/ Exports

Jour 9

Préparation dela matrice ICC

Vérifier pieces are stock

r

r

n Substituts---

NHIPL

Y

Jour 2

ICC Matrix

Traitement

Oill.0K7/J/ Sao

Entrée en Systeme

Jour 3

Frepara ion de id commande

Commands

Verifier CM

V ;

I

Jour 4

Traitement commande

Mise à jour sygtrrne

V

mite cmd

Crier>.

·

aCg -

---I+ ti-- Remplir

Documents De réception + ETA

- '

--

OCR

Jour 5

Etdhl'r Facture

Traiter facture

ie

Mettre â Jour Le suivi des

factures-tiJ e

Etat factures

Facture + POSS + BO

-

w

Suivi comptable

Prgparer La réception

Mise €jour sj'stertle

cents

P€anification Pty

^ion

1 Rapp ^Il marchanelk dede

dr$

Jour 25

J,

Réception

I^,

PDR ~

Verifier

Pikes. Etiquette:

^4:441 Non i

SMR ~,---,

i

Oui

ff FOR +

Jour 30

Mise é jour Systeme

y

Entrée en stock

Etude de l'existant Lecture du DCI

37

LECTURE DU DCI

Á travers l'analyse du diagramme ci-dessus, on peut conclure que :

L'information naît principalement du système des ventes (SAGE). Les données sont recueillies par le préparateur ICC MATRIX ainsi que le préparateur de commandes pour être transformées en lignes commande quotidiennement. On remarque qu'en parallèle, le chef de département s'attèle à d'autres tâches tout en attendant la commande afin de la vérifier. Il s'occupe aussi des différents échanges avec le fournisseur et fournit à d'autres postes différentes informations telles les factures qui sont principalement traitées par l'équipe de la réception ainsi que le suivi des expéditions.

Ce dernier s'occupe d'autre part de la comptabilité avec le calcul des coûts de revient de chaque expédition, et des réclamations adressées au fournisseur lorsqu'il y a des erreurs dans les quantités livrées. L'équipe de la réception est le dernier maillon de la chaîne, le processus peut être décrit comme étant « linéaire » et sa durée moyenne varie entre 25 et 30 jours.

Les quantités en stock sont ensuite modifiées dans le système SAGE.

On remarque que les principaux documents utilisés sont la commande et la facture. Ce sont en effets des documents qui passent par pratiquement tous les postes et qui sont indispensables au bon déroulement du processus.

Enfin, il est à signaler que le processus ne connaît pas beaucoup de points de décisions, étant simple et répétitif, il revient à chaque poste de déterminer les quantités à traiter selon la situation du stock et des commandes clients.

Etude de l'existant Méthodes de transmission des commandes

Méthodes de transmissions des commandes :

Les différentes méthodes pour passer une commande à un fournisseur TMC sont :

1. Toyota Network System Overseas (TNS-O) : C'est une méthode de transmission de

données qui utilise une ligne spécialisée entre le fournisseur et le distributeur. Les commandes sont envoyées directement vers le fournisseur où elles sont automatiquement traitées par le système de TMC. Celui-ci envoie par la suite la facture et les différents documents associés par la même voie. En utilisant ce type de transmission, on réduit le temps de traitement des commandes au niveau du fournisseur ainsi que les éventuels erreurs dus aux procédures manuelles. Cela implique entre autres la réduction du temps de livraison.

FIG. 07: Toyota Network System Overseas
(TNS-O)

Opérations

1. Prise des commandes		2. Traitement des commandes
3. à 6. Envoi du POSS Envoi du B/O Envoi de la facture Envoi du rapport d'expédition

38

2. EDI (Electronic Data Interchange) : Ou échange de données informatisé ; Est un

système de communication par satellite fourni et contrôlé par la GENERAL ELECTRIC. La différence entre cette méthode et celle citée précédemment est que l'EDI est un réseau qui propose plus de fonctionnalités tel l'échange de fichiers volumineux ou d'e-mails.

FIG. 08 : EDI. Echange de Données
Informatisé

Etude de l'existant Types de commandes

39

Les différents types de commandes :

Les commandes sont regroupées en différentes catégories ; chaque catégorie contient plusieurs types de commandes. Les principales catégories sont :

a- Réapprovisionnement de stock : C'est les commandes journalières « normales » qui
suivent la logique du SELL ONE BUY ONE (vendre un / acheter un) pour éviter un stock important pour un produit donné. Les quantités ne doivent pas dépasser un certain intervalle qui dépend toujours de la demande actuelle et de celle du mois précédent. La quantité commandée est toujours vérifiée par le fournisseur et celui-ci envoie une demande de confirmation en cas de quantités anormalement élevées afin d'éviter des erreurs de frappe ou de calcul.

b- Commandes spéciales : C'est des commandes en quantités irrégulières passées pour
satisfaire un cas spécial (promotion, commande du gouvernement...etc.) ; Elles concernent aussi les commandes dont le montant est trop élevé.

c- Vehicle Off Road (VOR) : C'est également une commande spéciale mais qui est
considéré comme plus urgente. Destinée généralement à l'atelier pour réparation d'un véhicule, cette commande est traitée différemment au niveau du fournisseur ; En effet, les pièces qui apparaissent en VOR sont disposées dans une même caisse séparément des autres pièces pour éviter une perte de temps à rechercher ces pièces à la réception ; Cela est fait directement à l'usine de fabrication en cas de rupture de stock du fournisseur. Cette commande est expédiée par avion (sauf si le volume ou le poids ne le permet pas), alors que pour les catégories précédentes, les livraisons se font par avion ou bateau, cela dépend de l'urgence de la commande ainsi que d'autres paramètres comme le volume.

Les types de commandes sont quand à eux plus importants pour le fournisseur, parce qu'ils déterminent la raison d'une demande et lui permettent aussi de répondre de la façon la mieux appropriée à cette demande.

Dans certains cas, la commande doit être accompagnée d'un E-mail notifiant que c'est une demande spéciale.

Un autre type de document peut être reçu de la part du fournisseur à la demande, c'est la facture proforma. Mais ceci ne concerne pas Toyota Algérie qui reçoit la liste de tous les prix mis à jour mensuellement.

Dans le cas d'une commande d'un nouveau modèle, il faut le spécifier dans le type de commande (Nouveau modèle au lieu de Réapprovisionnement).

Etude de l'existant Diagramme d'activité

40

Diagramme d'activité :

Avant de passer à une étape ultérieure, et dans le but de mettre en avant les activités du département Inventory, nous nous proposons d'établir un diagramme d'activité qui résume et schématise de manière claire et précise le déroulement du processus étudié et permet aussi de garder une certaine vision des principales procédures suivies.

Représentation graphique :

Etude de l'existant

Diagramme d'activité

ICC matrix I Team leader

Fournisseur (TMME)

Group leader

Suivi Shipment

Service réceptions

Calcul de la matrice ICC

Matrice

Etablie

Etablir la command

I

Commande

Passée

Traiter commande

Facture Envoyee

Traitement facture

V

: Dossier expédition

:SMR

Traitée

Facture

Suivre l'expédition

V

: Suivi factures

= Mis à jour

Etablir SMR

:PDR

Réception marchandise

41

Diagramme d'activité

Représente les procédures
utilisées au sein de l'Inventory.

Etude de l'existant Analyse critique

42

Evaluation du système actuel : (Diagnostic)

Analyse critique :

A travers l'étude détaillée des documents manipulés, des postes de travail ainsi que des procédures au niveau du département de l'Inventory, il nous a semblé utile de mentionner quelques anomalies afin d'y remédier lors de l'étape de conception.

Critique des documents :

- La liste des prix (EPM) contient des informations qui ne sont jamais utilisées telles: R/A code, Product code, Price class (à ne pas confondre avec le prix unitaire qui est le Sales Price) LEXUS ID, Tariff Code, PartACC Code.

- Le bon de commande n'est pas valorisé ; Il ne contient ni les prix unitaires des pièces commandées, ni le total de la commande. Nous n'avons donc aucune idée sur la valeur de la marchandise commandée.

- Dans le document planification de réception, le champ « Volume » désigne en vérité le nombre de pièces, ce qui prête à confusion.

- Les deux documents SMR et PDR représentent la même chose du point de vue « contenu », la seule différence est que le premier document cité est envoyé au fournisseur alors que le deuxième est archivé.

- Les étiquettes des pièces à recevoir sont imprimées avant les réceptions en mentionnant la quantité reçue comme étant égale à la quantité commandée, et ce n'est qu'après vérification que la quantité reçue est modifiée en cas d'erreur.

- Notons aussi qu'un même document circule entre les employés en étant copiés, et donc chaque document existe en minimum 05 copies.

Tout cela peut provoquer une perte de temps et d'information conséquente, ainsi qu'une difficulté à retrouver la dernière version mise à jour d'un document donné.

Critique des postes de travail :

Group Leader : Le chef de département comme nous l'avions mentionné précédemment répartit les tâches entre les différents employés et assure la coordination. D'autre part, il s'occupe de la vérification des quelques 500 lignes commande et 350 lignes facture en moyenne au quotidien, ainsi que la saisie des nouveaux modèles, de la clarification des commandes si nécessaire (OCR), du suivi des commandes spéciales...etc. En ne prenant en compte que la vérification des lignes commande et facture, et en supposant que la vérification « effective » d'une seule ligne se fait en 30 secondes, cela demanderait pour les 850 lignes plus de 7 heures. Bien évidemment cela est impossible et démontre que le chef de département passe à coté de plusieurs erreurs, mais surtout que ce poste est surchargé de tâches qui pourraient être attribuées à d'autres employés ou bien être automatisées.

Suivi expéditions : Le chargé du suivi des expéditions est aussi soumis à une charge de travail conséquente en considérant qu'il traite en moyenne 03 expéditions par semaine, qu'une expédition peut contenir deux à trois factures (environ 700 lignes facture) et que pour chaque expédition il est tenu de connaître le tracé à tout moment, de faire le point avec le

Etude de l'existant Analyse critique

43

fournisseur, les compagnies de transport et de transit, des douanes et de renseigner l'équipe de la réception. Il se doit aussi de calculer pour chaque livraison les coûts de revient et établir le document de réclamation (PDR) en cas d'erreurs lors des livraisons et de l'envoyer au fournisseur.

- Lors de l'étude, on ne se souciait que de la pièce de rechange et non de l'accessoire

qui est considéré comme un département à part, mais quelques postes de l'Inventory s'occupent quand même de quelques tâches relatives à l'accessoire, une dissociation totale serait donc bénéfique pour la bonne gestion de la pièce de rechange.

Critique des procédures de travail :

Les principales remarques concernant les procédures de travail à l'Inventory de Toyota Algérie sont :

Réception :

- Les différences qui peuvent apparaître lors d'une réception ne sont pas mentionnées en temps réel sur le système et peuvent être négligées par la suite.

- L'échange de document entre l'équipe de la réception et l'équipe de l'Inventory se fait manuellement, ces allers-retours des gens de la réception entraînent une gêne pour les deux équipes et une perte de temps considérable (un aller retour coute 10 minutes en moyenne).

Inventory :

- Absence de la vérification des prix mentionnés sur les factures reçues.

- La saisie des factures des autres fournisseurs (hors TME) effectuée en raison de l'absence d'application qui permettrait d'importer directement les factures dans le système occasionne la perte d'une (01) journée entière par un des employés affecté à la cette tâche

- Toutes les données manipulées ne sont pas sécurisées, qu'il s'agisse de leur stockage (Ordinateurs accessibles par tous et exposés aux dangers tels les vols), de l'accès à ces données (non protégé) ou des moyens utilisés pour les échanges (Serveur de messagerie et intranet exposés aux attaques et aux virus).

Projection des besoins futurs :

- Avec l'introduction imminente de nouveaux véhicules TOYOTA sur le marché (AURIS, RAV4...etc.), le département de la pièce de rechange devra s'attendre à l'augmentation du volume de travail de plus de 15% et passer d'une commande quotidiennement à deux voir trois commandes.

- L'arrivée de l'ERP ORACLE créera certainement le besoin d'autres services à consulter les données relatives aux commandes de pièces de rechange qui seront centralisées au niveau du serveur de données.

- L'ouverture prochaine de deux nouvelles succursales à HASSI MESSAOUD et DAR EL BEIDA augmentera le volume des commandes de pièces d'au moins 20%.

Etude de l'existant Conclusion

44

Conclusion

Nous venons de cerner les points principaux relatifs au processus de commandes au niveau de la division des pièces de rechange de la société Toyota Algérie SPA.

De la présentation de ses structures à l'étude des postes et procédures de travail en passant par les différents documents manipulés, nous sommes arrivés à comprendre comment l'information naît, se développe, se diffuse et circule à travers des situations diverses et concrètes ;

Cette étude a permis de localiser des dysfonctionnements dans le processus global qui provoquent des pertes de temps et d'argent. Ces maux doivent être traités en procédant à des changements organisationnels mais surtout en mettant en place un système fiable qui va centraliser et sécuriser les informations, tout en les laissant accessibles aux bonnes personnes.

La phase conceptuelle du projet est le moment ou doivent se concrétiser les idées qui se dessinent lors de la précédente étape, et où apparaît l'ossature du logiciel projeté. Il est donc plus qu'important de lui accorder la place qu'elle mérite et de conjuguer tous nos efforts en s'inspirant de théories vues en cours ou de la bibliographie,des connaissances acquises à travers les expériences passées et de sa propre culture personnelle, ainsi que des avis divers des utilisateurs qui sont les premiers concernés.

Enfin, les critiques (positives ou négatives) qui apparaissent dans toute l'étude, nous serviront de première base à la future étape qu'est la conception.

PARTIE 2 :

Étude conceptuelle

Etude conceptuelle Introduction

46

INTRODUCTION

La conception du nouveau système doit obligatoirement représenter l'image que l'on s'est fait de la future application tout en répondant aux besoins fonctionnels des utilisateurs.

Partant de l'identification des acteurs et des cas d'utilisation et de la description des différents points de vue du système à travers plusieurs scénarios, cette étape devra permettre aussi de représenter les interactions qui existent entre les utilisateurs et le système sans pour autant oublier l'aspect technique qui prévaudra à la mise en oeuvre de l'application.

Une fois cette étape lancée, il faudra néanmoins songer à revenir à l'étape précédente et aux utilisateurs qui restent les principaux bénéficiaires de cette étude, ainsi qu'à la phase de réalisation pour que cette étape de conception puisse être aussi un relais entre toutes les étapes suivies.

OBJECTIFS DU NOUVEAU SYSTÈME :

Pour concevoir notre application, nous allons suivre une certaine méthodologie et passer par quelques étapes bien définies et standardisées, mais que devra apporter notre conception du nouveau système concrètement ?

Ces quelques points devraient répondre à cela :

- Permettre au personnel de charger les prix envoyés par le fournisseur et d'y accéder

facilement et à tout moment.

- Proposer aux utilisateurs des outils de recherches de données (références, pièces...etc.)

et de calcul de leurs formules.

- Lier les différentes données du système en les centralisant notamment.

- Vérifier automatiquement chaque document en entrée et en sortie.

- Avertir en temps réel de l'état de chaque dossier d'expédition et de réception.

Etude conceptuelle Démarche suivie

47

Présentation de la démarche adoptée :

Notre conception est basée sur le langage de modélisation UML (UNIFIED MODELING LANGUAGE) qui utilise différents types de diagrammes et qui nous permet d'avoir une représentation simplifiée de la réalité et de simuler le système d'une certaine manière.

La méthode que nous avons suivie s'appuie principalement sur ces trois modèles :

1- Le modèle fonctionnel :

La modélisation fonctionnelle nous permettra de définir une abstraction du futur système d'un point de vue fonctionnel en identifiant les acteurs, leurs différentes façons d'utiliser le système, d'établir précisément les frontières du système et de déterminer les cas d'utilisation et leurs descriptions.

2- Le modèle statique :

La modélisation statique sert à décrire les objets et les associations entre ces objets. Elle repose essentiellement sur le diagramme de classes qui est l'un des diagrammes les plus importants de la phase conceptuelle.

3- Le modèle dynamique :

La modélisation dynamique repose sur certains diagrammes (états, séquence...) qui décrivent le comportement des objets et leur cycle de vie. Les relations et évènements décrits dans le modèle dynamique suivent une certaine chronologie ; ils dépendent entièrement de l'état du système à un temps donné.

MODÉLISATION

FONCTIONNELLE

Etude conceptuelle Modélisation fonctionnelle

Section I : Modélisation fonctionnelle Identification des acteurs du système :

Avant de s'atteler à la difficile tâche de l'identification et la description des cas d'utilisation du futur système, il nous faudra déterminer ses acteurs principaux et secondaires. Précisons seulement qu'un « acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié ». Et celui-ci peut « consulter et/ou modifier directement l'état du système, en émettant et/ou en recevant des messages susceptibles d'être porteurs de données ». [UML01]

Acteurs primaires :

a) Les employés ; c'est-à-dire les postes identifiés lors de la phase étude de l'existant :

- Préparateur ICC MATRIX

- Préparateur commande

- Chargé du suivi livraisons

- Rédacteur de rapports

- Préposé à la réception

- Group leader

b) L'administrateur du système, et qui s'occupera aussi de sa maintenance.

Acteurs secondaires : Afin de permettre au personnel du service des ventes de pièces de rechange de Toyota Algérie de connaître l'état de telle ou telle commande, et par la suite pouvoir renseigner les clients, nous considérerons le département des ventes (qui pourrait être considéré comme un système externe) comme acteur secondaire ayant uniquement le droit de consulter une partie de notre application.

Diagramme de contexte statique :

Afin d'avoir une meilleure vision et répertorier tous les acteurs en un seul schéma, et pour spécifier le nombre d'instances d'acteurs connectées au système à un moment donné, nous réalisons un diagramme de contexte statique. Pour cela, la notation suivante a été utilisée :

49

0..1 ; 0..* : Nombre d'instances connectées en même temps.

Etude conceptuelle Modélisation fonctionnelle

50

- FIG. 10 : Diagramme de contexte statique - Identification des cas d'utilisation :

Un cas d'utilisation est l'image ou le comportement du système du point de vue d'un ou de plusieurs utilisateurs. Il reflète l'ensemble d'actions réalisées par le système (déclenchées en réponse à des stimulations d'acteurs externes en général) qui produisent un résultat tangible et intéressant pour l'utilisateur. On note toutefois que l'on décrit le quoi d'un cas d'utilisation sans mentionner le comment.

On peut considérer le cas d'utilisation comme étant la représentation la plus exhaustive possible des besoins d'un acteur donné qui sont recentrés et restructurés de façon à obtenir d'une part une liste de besoins réels en réduisant les imprécision, la complexité et les éventuels oublis ; et d'autre part pour concrétiser le futur système sur la base de ces besoins, car le système est avant tout destiné à ses futurs utilisateurs. L'intérêt principal des cas d'utilisation est donc la possibilité de décrire le caractère fonctionnel du futur système et de pouvoir modéliser les principales tâches effectuées par les acteurs.

Etude conceptuelle Modélisation fonctionnelle

51

« Chaque cas d'utilisation correspond à une fonction métier du système ». [UML 01]

« Un cas d'utilisation est un classificateur qui modélise une fonctionnalité d'un système ou d'une classe. L'instanciation d'un cas d'utilisation se traduit par l'échange de messages entre le système et ses acteurs ». [UML 02]

Partant de ces définitions, nous avons pu distinguer ces différents cas d'utilisation relatifs à notre étude :

N°	Cas d'utilisation	Acteur(s) concerné(s)
01	Réaliser la matrice ICC	Préparateur ICC MATRIX
02	Préparer la commande	Préparateur commandes
03	Etablir statistiques et rapports	Rédacteur de rapports
04	Suivi livraisons	Chargé du suivi livraison
05	Suivi comptable	Chargé du suivi livraison
06	Vérifier marchandise	Préposé à la réception
07	Gérer les références pièces	Chef de département
08	Vérifier commandes	Chef de département ; Préparateur commandes
09	Traiter factures	Chef de département ; Préparateur commandes
10	Consulter commandes	Service des ventes
11	Administrer le système	Administrateur système
12	S'authentifier	Tous les utilisateurs

- TAB. 01 : Liste des cas d'utilisation -

En transcrivant ces informations sur un schéma en utilisant la notation présentée ci-dessous, on obtient notre diagramme de cas d'utilisation.

Etude conceptuelle Modélisation fonctionnelle

52

- FIG. 11 : Diagramme de cas d'utilisation -

Etude conceptuelle Modélisation fonctionnelle

Description des cas d'utilisation :

A présent nous allons documenter nos cas d'utilisation en utilisant la description textuelle, on aura plus loin (modélisation dynamique) l'occasion d'illustrer chaque cas énuméré par un diagramme de séquence.

CAS N° 1 : Réaliser la matrice ICC

- Acteur principal : Préparateur ICC matrice

- Précondition :

· L'utilisateur possède les droits d'accès.

- Scénario nominal :

1. L'utilisateur sélectionne les références à traiter.

2. Il charge les paramètres (1).

3. Le système calcule la demande globale et moyenne pour chaque référence et établit les classes de références. Il calcule par la suite le MIP pour chaque pièce.

4. Le système compare les résultats avec les chiffres précédents et signale d'éventuels écarts importants.

5. Le système demande la confirmation de l'utilisateur avant d'enregistrer les résultats.

6. Le système enregistre les modifications et informe les autres utilisateurs concernés de la disponibilité des nouveaux chiffres (mis à jour).

- Scénario alternatif :

A1 : Login ou mot de passe erroné ; l'authentification est demandée à nouveau.

A2 : L'utilisateur prend en compte les écarts détectés par le système ; le processus reprend en 3

A3 : L'utilisateur ferme l'application avant d'avoir enregistré ; le système lui demande s'il veut enregistrer les modifications.

A4 : L'ordinateur s'arrête de fonctionner normalement ou n'est plus sous tension ; le système enregistre une version de récupération.

- Contraintes :

Lors des calculs et des mises à jour des données, l'accès à ces données doit être momentanément verrouillé pour empêcher de travailler avec d'anciennes versions.

Les références dont le MIP est nul doivent être mises en évidence par le système en raison de leur traitement spécial.

53

(1) : Ventes, BO et LOST SALES qui sont des paramètres d'un autre système.

Etude conceptuelle Modélisation fonctionnelle

CAS N° 2 : Préparer la commande

- Acteur principal : Préparateur commandes

- Précondition :

· L'utilisateur possède les droits d'accès.

- Scénario nominal :

1. L'utilisateur sélectionne les références à traiter.

2. Il charge les paramètres (2).

3. Le système calcule les quantités à commander (SOQ)

4. Le système compare les résultats avec les chiffres précédents et signale d'éventuels écarts importants

5. L'utilisateur crée une nouvelle commande.

6. Le système met à disposition une nouvelle commande avec toutes les informations requises (entête, N° de la commande, date...etc.)

7. L'utilisateur sélectionne les références à transformer en lignes commandes.

8. Le système ajoute aux références leurs prix unitaires et calcule le total (en HT et/ou TTC)

9. L'utilisateur enregistre la commande sous un certain format*

10. Le système demande la confirmation de l'utilisateur avant d'enregistrer les résultats.

11. Le système enregistre la commande et informe le chef de département de la disponibilité de la nouvelle commande.

- Scénario alternatif :

A1 : Login ou mot de passe erroné ; l'authentification est demandée à nouveau.

A2 : L'utilisateur prend en compte les écarts détectés par le système ; le processus reprend en 3

A3 : L'utilisateur ferme la commande sans avoir enregistré ; le système demande confirmation

A4 : L'utilisateur ferme l'application avant d'avoir enregistré ; le système lui demande s'il veut enregistrer les modifications.

A5 : L'ordinateur s'arrête de fonctionner normalement ou n'est plus sous tension ; le système enregistre une version de récupération.

- Contraintes :

Les références dont le MIP est nul doivent être mises en évidence par le système, il en résulte un SOQ négatif. L'utilisateur pourra le changer manuellement.

54

(2) : On Hand et BO qui dépendent d'un autre système.

Etude conceptuelle Modélisation fonctionnelle

55

CAS N° 3 : Etablir statistiques et rapports

- Acteur principal : Rédacteur de rapports

- Précondition :

· L'utilisateur possède les droits d'accès.

- Scénario nominal :

1. L'utilisateur consulte les références, les factures et les commandes, et définit les lignes
qui sont en back order et qui ne sont pas des commandes spéciales.

2. Il les copie à la section Back Order Follow Up datée du jour même.

3. L'utilisateur enregistre les données.

4. le système offre certains outils statistiques.

5. Le système lui demande la confirmation avant d'enregistrer le résultat.

6. Le système demande à l'utilisateur s'il veut imprimer un rapport, et envoie un message aux différents utilisateurs pour prévenir de la mise à jour.

- Scénario alternatif :

A1 : Login ou mot de passe erroné ; l'authentification est demandée à nouveau.

A2 : L'utilisateur ferme l'application avant d'avoir enregistré ; le système lui demande s'il veut enregistrer les modifications.

A3 : L'ordinateur s'arrête de fonctionner normalement ou n'est plus sous tension ; le système enregistre une version de récupération.

Etude conceptuelle Modélisation fonctionnelle

56

CAS N° 4 : Suivi livraisons

- Acteur principal : Chargé du suivi livraison

- Préconditions :

· L'utilisateur possède les droits d'accès.

· Réception d'une facture et de son avis d'expédition.

- Scénario nominal :

1. Le système crée un nouveau dossier « livraison » dés l'arrivée d'une facture.

2. Lorsque l'avis d'expédition est reçu, l'utilisateur complète alors les informations requises, et enregistre le dossier.

3. L'utilisateur met à jour les informations relatives à une réception à chaque arrivée d'un document du fournisseur.

4. Le système commence à calculer (dynamiquement) le délai de livraison, et alerte l'utilisateur à chaque étape réalisée par une livraison.

5. Le système alerte le service de réception et les utilisateurs concernés de l'état de l'expédition avant l'arrivée d'une livraison.

6. Le système met à jour quelques données comme la moyenne du temps de livraison après chaque dossier fermé.

- Scénario alternatif :

A1 : Login ou mot de passe erroné ; l'authentification est demandée à nouveau.

A2 : Une livraison concerne plus d'une facture ; L'utilisateur sélectionne les factures concernées afin de les regrouper en seul dossier de livraison.

A3 : Le dossier est refermé sans enregistrement des données ; Le système demande la confirmation de l'utilisateur.

A4 : L'utilisateur ferme l'application avant d'avoir enregistré ; le système lui demande s'il veut enregistrer les modifications.

A5 : L'ordinateur s'arrête de fonctionner normalement ou n'est plus sous tension ; le système enregistre une version de récupération.

- Contraintes :

Le système doit alerter l'utilisateur à plusieurs étapes de la livraison selon les informations introduites au fur et à mesure, le système doit donc anticiper l'étape suivante et rappeler l'utilisateur la suite à entreprendre.

Cette partie du système doit être multi utilisateurs, en effet le statut d'une livraison plus particulièrement doit être accessibles à plusieurs utilisateurs en même temps (réception notamment).

Etude conceptuelle Modélisation fonctionnelle

57

CAS N° 5 : Suivi comptable

- Acteur principal : Chargé du suivi livraison

- Préconditions :

· L'utilisateur possède les droits d'accès.

· Réception d'une facture et de son avis d'expédition.

- Scénario nominal :

1. Le système crée un nouveau dossier « comptabilité » dés l'arrivée d'une facture.

2. L'utilisateur doit saisir les informations relatives à la comptabilité à chaque arrivée d'un document (douane, transitaire, compagnie maritime, assurance...etc.)

3. Le système met à jour les données telles le coût de revient et le temps de livraison.

4. Le système prévient l'utilisateur en cas d'oubli ou de retard dans le traitement des données.

- Scénario alternatif :

A1 : Login ou mot de passe erroné ; l'authentification est demandée à nouveau.

A2 : Le dossier est refermé sans enregistrement des données ; Le système demande la confirmation de l'utilisateur.

A3 : L'utilisateur ferme l'application avant d'avoir enregistré ; le système lui demande s'il veut enregistrer les modifications.

A4 : L'ordinateur s'arrête de fonctionner normalement ou n'est plus sous tension ; le système enregistre une version de récupération.

- Contraintes :

Le système doit offrir à l'utilisateur des données supplémentaires, dont le taux de change de la devise utilisée pour les transactions par rapport au dinar algérien principalement.

Etude conceptuelle Modélisation fonctionnelle

58

CAS N° 6 : Vérifier marchandise

- Acteur principal : Préposé à la réception

- Préconditions :

· L'utilisateur possède les droits d'accès.

· Existence du dossier de livraison.

- Scénario nominal :

1. Le système prépare les étiquettes de réception à imprimer (Lorsque l'arrivée d'une marchandise est imminente) ainsi que la planification de réception.

2. L'utilisateur informe le système des données restantes (nombres de personnes affectées à la réception, zone de stockage temporaire, localisation finale...etc.).

3. L'utilisateur déclenche le chronomètre avant de commencer la vérification physique.

4. L'utilisateur remplit au fur et à mesure de la vérification de l'état et du nombre de pièces reçues.

5. Le système renvoie à la fin de l'opération le rapport de déchargement de la marchandise ainsi que de l'état des pièces si anomalie il y a.

6. Le système informe les autres utilisateurs concernés de la fin de l'opération et des résultats observés.

7. Le système enregistre les données et imprime le rapport si demandé par l'utilisateur.

- Scénario alternatif :

A1 : Login ou mot de passe erroné ; l'authentification est demandée à nouveau.

A2 : Un problème inattendu survient lors de la réception ; L'utilisateur (qui dispose de ce privilège) peut suspendre le chronométrage en identifiant la cause.

A3 : L'utilisateur ferme l'application avant d'avoir enregistré ; le système lui demande s'il veut enregistrer les modifications.

A4 : L'ordinateur s'arrête de fonctionner normalement ou n'est plus sous tension ; le système enregistre une version de récupération.

Etude conceptuelle Modélisation fonctionnelle

59

CAS N° 7 : Gérer les références pièces

- Acteur principal : Chef de département

- Précondition :

· L'utilisateur possède les droits d'accès.

- Scénario nominal :

1. L'utilisateur choisis une des deux options : ajout d'une référence pièce (à partir du NMPL) ou modification d'une référence qui existe.

2. L'utilisateur saisi les données concernant la (les) pièce(s) de rechange et enregistre.

3. Le système vérifie si les données n'existaient pas auparavant.

4. Le système enregistre les nouvelles données.

- Scénario alternatif :

A1 : Login ou mot de passe erroné ; l'authentification est demandée à nouveau.

A2 : La pièce de rechange ajoutée existait déjà ; Le système demande confirmation (remplacement) ou annulation de l'ajout.

A3 : L'application est refermée sans enregistrement des données ; Le système demande une confirmation de la part de l'utilisateur.

A4 : L'ordinateur s'arrête de fonctionner normalement ou n'est plus sous tension ; le système enregistre une version de récupération.

Etude conceptuelle Modélisation fonctionnelle

60

CAS N° 8 : Vérifier les commandes

- Acteurs principaux : Chef de département ; Préparateur commandes

- Préconditions :

· L'utilisateur possède les droits d'accès.

· La commande est prête à être lancée.

- Scénario nominal :

1. L'utilisateur consulte la dernière commande établie.

2. L'utilisateur peut modifier les quantités à commander ou ajouter ou supprimer les lignes commandes.

3. L'utilisateur enregistre les modifications.

4. Le système enregistre les nouvelles données après confirmation de l'utilisateur et avertit les autres utilisateurs de la mise à jour de la commande concernée.

5. L'utilisateur enregistre la commande sous un format particulier pour pouvoir l'envoyer au fournisseur.

- Scénario alternatif :

A1 : Login ou mot de passe erroné ; l'authentification est demandée à nouveau.

A2 : La commande n'existe pas ; Le système demande à l'utilisateur de vérifier le numéro de la commande recherchée.

A3 : L'utilisateur ne procède à aucune modification ; Le scénario va directement à la fin (au N°5).

A4 : L'application est refermée sans enregistrement des données ; Le système demande une confirmation de la part de l'utilisateur.

A5 : L'ordinateur s'arrête de fonctionner normalement ou n'est plus sous tension ; le système enregistre une version de récupération.

- Contraintes :

La commande doit être vérifiée avant d'être envoyée, et le système enregistre la date et l'heure de l'envoi de la commande.

Etude conceptuelle Modélisation fonctionnelle

61

CAS N° 9 : Traiter les factures

- Acteurs principaux : Chef de département ; Préparateur commandes

- Préconditions :

· L'utilisateur possède les droits d'accès.

· La facture a été reçue de la part du fournisseur.

- Scénario nominal :

1. L'utilisateur charge la facture reçue et les documents attachés (POSS, BO).

2. Le système traite les données en ne gardant que les informations nécessaires et enregistre les documents ainsi transformés.

3. L'utilisateur vérifie les documents et confirme l'enregistrement.

4. Le système prévient les autres utilisateurs de l'arrivée d'une nouvelle facture.

- Scénario alternatif :

A1 : Login ou mot de passe erroné ; l'authentification est demandée à nouveau.

A2 : Les données n'ont pas été totalement chargées ; L'utilisateur doit remplir les champs perdus.

A3 : L'utilisateur ferme la facture par erreur ; Le système demande à l'utilisateur s'il veut enregistrer avant de quitter.

A4 : L'utilisateur ferme l'application avant d'avoir enregistré ; le système lui demande s'il veut enregistrer les modifications.

A5 : L'ordinateur s'arrête de fonctionner normalement ou n'est plus sous tension ; le système enregistre une version de récupération.

- Contraintes :

Le système doit mettre à jour les informations dans tout ce qui est relatif à la facturation. Il met en évidence l'information plus spécialement pour le préposé au suivi de livraison ainsi qu'au service de réception.

Etude conceptuelle Modélisation fonctionnelle

62

CAS N° 10 : Consulter des commandes

- Acteur principal : Service des ventes

- Préconditions :

· L'utilisateur possède les droits d'accès.

- Scénario nominal :

1. L'utilisateur fait une recherche selon un certain critère particulier pour retrouver une commande (Numéro, référence ...etc.).

2. Le système renvoie l'information à l'utilisateur. Les critères de recherche sont enregistrée séparément afin d'établir des statistiques par la suite.

3. Le système rend la mais à l'utilisateur qui pourra effectuer d'autres recherches.

- Scénario alternatif :

A1 : Login ou mot de passe erroné ; l'authentification est demandée à nouveau.

A2 : La commande recherchée n'existe pas ; Le système propose à l'utilisateur de vérifier les données ou de faire une autre recherche.

CAS N° 11 : Administrer le système

- Acteur principal : Administrateur système

- Préconditions :

· L'utilisateur possède les droits d'accès.

- Scénario nominal :

1. L'utilisateur introduit son login et mot de passe avec privilèges administrateur.

2. Le système donne accès à tous les volets fonctionnels et d'administration de l'application (administration des profils, des privilèges et des comptes en général) ainsi que l'accès à la base de donnée.

3. L'administrateur peut ajouter, supprimer ou modifier n'importe quelle partie de l'application et de la base de données.

- Scénario alternatif :

A1 : Login ou mot de passe erroné ; l'authentification est demandée à nouveau.

A2 : L'ordinateur s'arrête de fonctionner normalement ou n'est plus sous tension ; le système enregistre une version de récupération.

Etude conceptuelle Modélisation fonctionnelle

CAS N° 12 : S'authentifier

- Acteurs: Tous les utilisateurs

- Préconditions :

· L'utilisateur possède un login et un mot de passe.

- Scénario nominal :

1. L'utilisateur saisit son login et son mot de passe

2. Le système vérifie la présence et la correspondance des champs saisis

3. Le système connecte l'utilisateur à l'application selon les privilèges attribués à son compte ainsi que son profil.

- Scénario alternatif :

A1 : Login ou mot de passe erroné ; l'authentification est demandée à nouveau.

A2 : L'utilisateur oublie son mot de passe ou son login ; Le système lui demande des informations complémentaires, ou de s'adresser directement à l'administrateur.

Regroupement des cas d'utilisation en catégories :

À présent nous allons structurer les cas d'utilisations décrits en ensembles cohérents appelés PACKAGES. Nous les regrouperons selon le domaine fonctionnel de chaque cas, comme suit :

PACKAGE N^°1 PACKAGE N^°2 PACKAGE N^°3

ACHATS
PIECES

LIVRAISONS
PIECES

SUPPORT ECHNIQUE

63

CAS 1,2,8,9,10 CAS 4,5,6 CAS 3,7,11,12

- FIG. 12 : Catégories de cas d'utilisation -

MODÉLISATION

STATIQUE

Etude conceptuelle Modélisation statique

Section II : Modélisation statique

Le modèle statique représente la structure de notre système en termes d'objets et de relations entre ces objets. Il repose essentiellement sur le diagramme des classes et des relations (ou associations) issues des cas d'utilisation recensés lors de la modélisation fonctionnelle. Une classe est une abstraction d'un ensemble d'objets de la réalité qui possèdent des caractéristiques communes alors qu'une association définit une relation sémantique durable entre deux classes.

« Le diagramme de classes est le point central dans un développement orienté objet....Il a pour objectif de décrire la structure des entités manipulées par les utilisateurs....Il met en oeuvre des classes contenant des attributs et des opérations, et reliées par des associations ou des généralisations » [UML01]

Nous débuterons donc par déterminer les classes candidates à partir de chaque cas d'utilisation pertinent avant de les compléter, détailler et les affiner pour construire notre futur diagramme de classes.

Détermination des classes candidates :

À partir des cas d'utilisation nous avons essayé de construire des diagrammes contenant les informations les plus utiles que nous rajouterons ou modifierons étape par étape, nous présentons ces diagrammes ci-dessous :

Diagramme N°1 :

65

- FIG. 13 : Diagramme de classes candidates N°1 -

Etude conceptuelle Modélisation statique

Ligne-Commande

Expédition

En regardant de très prés l'utilisation de la classe PIÈCE dans les trois cas d'utilisation 1,2 et 7 on se rend compte qu'elle est définie de manière différente dans chacun de ces cas. C'est une même classe qui joue différents rôles selon l'utilisateur concerné. Le fait est que cette classe est le principal maillon de notre diagramme, on décide de fractionner cette classe selon les fonctions pour la « décharger » de quelques unes de ses fonctions en introduisant les notions de généralisation et de spécialisation comme suit :

Diagramme N°2 :

Pièce

Réception

Pièce-CMD

Pièce-ICC

Pièce-sub

Commande Facture

- FIG. 14 : Diagramme de classes candidates N°2 -

De même qu'on pourrait compléter ce diagramme en ajoutant deux aspects fonctionnels étudiés lors de l'étude de l'existant, à savoir l'état comptable de la facture qui est établi après l'enregistrement de l'expédition et les lignes factures qui regroupent toutes les informations nécessaires à l'état de chaque ligne commandée. On obtient dés lors le diagramme suivant :

Diagramme N°3 :

66

- FIG. 15 : Diagramme de classes candidates N°3 -

Etude conceptuelle Modélisation statique

Pendant la première phase de notre étude, nous avons stipulé que la société TOYOTA ALGERIE travaille essentiellement avec le fournisseur TME, mais qu'elle s'occupe aussi de deux autres marques, et donc deux autres fournisseurs, ainsi qu'elle pourrait être appelée à traiter avec de nouveaux fournisseurs. Voilà pourquoi nous décidons de lier la classe « Commande » à une nouvelle classe « Fournisseur » qui contiendra les informations relatives à ceux-là. Ce qui nous permet de dresser le dernier diagramme des classes candidates qui suit :

Diagramme N°4 :

67

- FIG. 16 : Diagramme de classes candidates N°4 -

Afin d'obtenir notre diagramme de classes final, il nous faudra déterminer les multiplicités à chaque extrémité d'une association en vue de préciser le nombre d'instances qui participent à une relation, et ceci en passant par l'énumération de quelques règles de gestion internes ; Quelques opérations seront aussi transcrites dans le diagramme et nous finirons par décrire les propriétés de chaque classe mentionnée.

Etude conceptuelle Modélisation statique

Les règles de gestion :

1- Une pièce appartient à une ou plusieurs lignes commande.

2- Une ligne commande contient une et une seule pièce.

3- Une ligne commande appartient à une et une seule commande.

4- Une commande contient une ou plusieurs lignes commande.

5- Une commande concerne un et un seul fournisseur.

6- Un fournisseur peut recevoir plusieurs commandes.

7- Une commande est concernée par une ou plusieurs factures.

8- Une facture peut concerner plusieurs commandes.

9- Une facture est composée d'une ou de plusieurs lignes facture.

10- Une ligne facture appartient à une seule facture.

11- Une expédition peut concerner plusieurs factures.

12- Une facture n'est concernée que par une seule expédition.

13- Un état comptable concerne une seule expédition/facture à la fois.

14- Une réception concerne une et une seule expédition.

15- Une expédition peut-être concernée par plusieurs réceptions.

D'où le diagramme de classes final suivant:

68

- FIG. 17 : Diagramme de classes -

Etude conceptuelle Modélisation statique

69

Définition des classes et de leurs attributs :

La classe « Piece »

Attributs	Description	Type
Ref_Piece	Référence de la pièce	Char
Designation	Désignation de la pièce	Char
Poids	Poids net de la pièce	Number
IsSubstitut	Présence d'un substitut	Boolean
DateDebProd	Date début de la production	Date
DateFinProd	Date fin de la production	Date
Qty_Pkg	Quantité dans un PACK	Number
Pays_Origine	Origine de la pièce	Char
Volume	Volume de la pièce	Number
Vor_Max	Quantité maximale pour une commande VOR	Number
TMC_Stock_Code	Code en stock du fournisseur	Char
Danger_Code	Code de dangerosité du produit	Char
PU	Prix unitaire	Number

La classe « Piece-ICC »

Attributs	Description	Type
Ventes	Nombre de ventes des 6 derniers mois	Number
BackOrders	Nombre de back orders des 6 derniers mois	Number
LostSales	Ventes ratées des 6 derniers mois	Number
SSdemand	Stock de sécurité pour la demande	Number
SSleadtime	Stock de sécurité pour les délais	Number
OrderCycle	Nombre de commandes	Number
LeadTime	Délai de livraison	Number
ClassePiece	Classe de la pièce	Char
DemandeGlobale	Demande des 6 derniers mois	Number
DemandeMoyenne	Demande moyenne mensuelle	Number
MIP	Quantité maximale à commander	Number
Ref_Piece	Référence de la pièce	Char

La classe « Piece-CMD »

Attributs	Description	Type
MIP	Quantité maximale à commander	Number
ClassePiece	Classe de la pièce	Char
OnHand	Quantité présente en stock	Number
OnOrder	Quantité déjà commandée au fournisseur	Number
BackOrder	Quantité commandée par des clients	Number
SOQ	Quantité à commander	Number
Ref_Piece	Référence de la pièce	Char

Etude conceptuelle Modélisation statique

70

La classe « Piece-SUB »

Attributs	Description	Type
Ref_Substitut	Référence substitut	Char
Ref_Piece	Référence de la pièce	Char

La classe « Ligne-Commande »

Attributs	Description	Type
Num_Commande	Numéro de la commande qui contient la ligne	Char
Num_Ligne_Commande	Numéro de la ligne	Char
Ref_Piece	Référence de la pièce commandée	Char
Qty_Commandee	Quantité commandée	Number
PUC	Prix unitaire (commande)	Number
Total_Ligne	Prix unitaire * Quantité commandée	Number
Etat_Ligne	Etat de la ligne à un moment donné	Text

La classe « Commande »

Attributs	Description	Type
Num_Commande	Numéro de la commande	Char
Num_Fournisseur	Fournisseur concerné	Char
Date_Commande	Date d'émission de la commande	Date
Nbr_Ligne_Commande	Nombre de ligne qu'elle contient	Number
Montant_HT	Montant de la commande en hors taxe	Number
Montant_TTC	Montant de la commande en TTC	Number

La classe « Facture »

Attributs	Description	Type
Num_Facture	Numéro de la facture	Char
Date_Facture	Date de la facturation	Date
Montant_Facture_HT	Montant de la facture en hors taxe	Number
Montant_Facture_TTC	Montant de la facture toutes taxes comprises	Number
Nbr_Ligne_Facture	Nombre de lignes facturées	Number
Nbr_Caisse	Nombre de caisses envoyées	Number
Num_Expedition	Numéro de l'expedition	Char

La classe « Ligne-Facture »

Attributs	Description	Type
Num_Facture	Numéro de la facture	Char
Num_Ligne_Facture	Numéro de la ligne	Number
Ref_Piece	Référence de la pièce	Char
Qty_facturee	Quantité facturée	Number
PUF	Prix unitaire facturé	Number
Num_Commande	Numéro de la commande associée	Char
Num_Ligne_Commande	Numéro de la ligne	Number
Num_Caisse	Caisse qui contient la pièce(s)	Char

Etude conceptuelle Modélisation statique

71

La classe « Expedition »

Attributs	Description	Type
Num_Expedition	Numéro de l'expédition	Char
Somme_Qty	Quantités facturées	Number
Nbr_Caisse_E	Nombre de caisses envoyèes	Number
Date_Facture_Système	Date d'enregistrement de la facture	Date
Date_Facture_Origine	Date d'arrivée de la facture par DHL	Date
Date_Rec_Connaissement	Date de réception du connaissement	Date
Num_Connaissement	Numéro du connaissement	Char
Date_Connaissement	Date du connaissement	Date
Date_Deb_Domiciliation	Date début de domiciliation	Date
Date_Fin_Domiciliation	Date de fin de domiciliation	Date
Date_Declaration	Date de déclaration en douane	Date
Num_Remorque	Numéro de la remorque	Char
Poids_Marchandise	Poids de la marchandise	Number
Volume_Marchandise	Volume de la marchandise	Number
Embarquement	Date d'embarquement	Date
Accostage	Date d'arrivée au port d'Alger	Date
Debarquement	Date de débarquement de la marchandise	Date
Dem_Cheque_Transitaire	Date de demande de chèque du transitaire	Date
Dem_Cheque_Interne	Date de demande de chèque au service comptabilité	Date
Remise_Cheque_Interne	Date de remise de chèque	Date
Remise_Cheque_Transitaire	Date de remise de chèque au transitaire	Date
Remise_Bon_Enlevé	Date de remise du bon enlevé	Date
Date_Livraison	Date de livraison annoncée	Date
Debut_Reception	Date du début de la réception	Date
Fin_Reception	Date de la fin de la réception	Date
Lead_Time	Délai de livraison total	Number
Dossier_Complet	Date de fermeture du dossier	Date
Remise_Comptabilite	Date de remise du dossier à la comptabilité	Date
Observations	Observations	Text

Etude conceptuelle Modélisation statique

72

La classe « Etat-Comptable »

Attributs	Description	Type
Num_Expedition	Numéro de l'expédition	Char
Type_Shipment	Voie d'acheminement	Char
Type_Container	Type de container	Char
Taux_Change	Taux de change de la monnaie de transaction	Number
Montant_FOB	Montant sans charges	Number
Montant_Fret_Loading	Montant transport + Chargement	Number
Montant_Assurance	Montant de l'assurance	Number
Droit_Douane	Droits douaniers	Number
Montant_Transit	Frais de transit	Number
Montant_SDV	Frais compagnie maritime	Number
Cout_Revient	Total coût de revient	Number
LC_Factor	Facteur coût de revient	Char

La classe « Reception»

Attributs	Description	Type
Num_Reception	Numéro de la réception	Char
Num_Expedition	Numéro de l'expédition	Char
Nbr_Caisse_R	Nombre de caisses reçues	Number
Num_Container	Numéro du container	Char
Date_Arrivee	Date d'arrivée	Date
Start_Time	Heure de début de la réception	Date
End_Time	Heure de fin de la réception	Date
IsError	Erreur à la réception	Boolean
Qty_Recue	Quantité reçue	Number
Qty_Manque	Quantité manquante	Number
Qty_Exces	Quantité excédante	Number
Qty_Endommagee	Quantité endommagée	Number
Code_Erreur	Code erreur fournisseur	Char
Code_CPD	Code erreur du client	Char
Code_Paker_Picker	Code emballage	Char
Remarques	Remarque du CPD	Text

La classe « Fournisseur»

Attributs	Description	Type
Num_Fournisseur	Code du fournisseur	Char
Nom_Fournisseur	Désignation du fournisseur	Char
Adr_Fournisseur	Adresse du fournisseur	Char
Tel_Fournisseur	Téléphone du fournisseur	Number
Fax_Fournisseur	Fax du fournisseur	Number
Mail_Fournisseur	E-mail du fournisseur	Char
Web_Fournisseur	Site internet du fournisseur	Char

MODÉLISATION

DYNAMIQUE

Etude conceptuelle Modélisation dynamique

74

Section III : Modélisation dynamique

Pour étudier les comportements de nos objets au fil du temps et lorsqu'ils sont confrontés à diverses situations, nous allons les représenter sous forme de diagrammes de séquence, et si cela est nécessaire, de diagrammes d'état. Ces diagrammes reposeront essentiellement sur les scénarios des cas d'utilisations.

CAS N° 1 : Réaliser la matrice ICC

Système / ICC

Préparateur ICC matrix

Sélectionne les références

Créer l'espace de travail

Charger les paramètres

Calcul de données et comparaison

Résultats

Si écart» alors ALERTE

Enregistrement des données

Demande de confirmation

Confirmation

Sauvegarde des données et mise à jour

Confirmation de sauvegarde

- FIG. 18 : Diagramme de séquence N°1 -

Etude conceptuelle Modélisation dynamique

CAS N° 2 : Préparer la commande

Système / Commande

Préparateur commandes

Sélectionne les références

Créer l'espace de travail

Charger les paramètres

Calcul de données et comparaison

Si écart» alors ALERTE

Résultats

Créer une commande

Création de la commande

Editer commande

Enregistrement des données

Demande de confirmation

Confirmation

Sauvegarde des données et mise à jour

Confirmation de sauvegarde

75

- FIG. 19 : Diagramme de séquence N°2 -

Etude conceptuelle Modélisation dynamique

CAS N° 3 : Etablir statistiques et rapports

Système / Statistiques

Préparateur rapports

Sélectionne les références

Créer l'espace de travail

Charger les paramètres

Etablir les rapports

Enregistrement des données

Demande de confirmation

Confirmation

Sauvegarde des données et mise à jour

	Confirmation de sauvegarde

76

- FIG. 20 : Diagramme de séquence N°3 -

Etude conceptuelle Modélisation dynamique

77

CAS N° 4 : Suivi livraisons

Système / Expédition

Chargé du suivi livraison

Créer dossier livraison

Créer l'espace de travail

Charger les paramètres

Mise à jour des données

Charger les paramètres

Charger les paramètres

Enregistrement des données

Demande de confirmation

Confirmation

Sauvegarde des données et mise à jour

Confirmation de sauvegarde

Avertir les utilisateurs concernés

- FIG. 21 : Diagramme de séquence N°4 -

Etude conceptuelle Modélisation dynamique

CAS N° 5 : Suivi comptable

Système / Comptabilité

Chargé du suivi comptable

Créer dossier comptabilité

Créer l'espace de travail

Charger les paramètres

Mise à jour des données

Charger les paramètres (douane)

Charger les paramètres (transit)

Charger les paramètres (Assurance)

Mise à jour des données

		Enregistrement des données
		Demande de confirmation
		Confirmation

78

Sauvegarde des données et mise à jour

Confirmation de sauvegarde

Avertir les utilisateurs concernés

- FIG. 22 : Diagramme de séquence N°5 -

Etude conceptuelle Modélisation dynamique

79

CAS N° 6 : Vérifier marchandise

Système 1 Réception

Préposé à la réception

Préparer les étiquette et les données de la réception

Données prévisionnelles

Démarrer le chronomètre (début réception)

Enregistrement des données

Mise à jour des données

Fin de la réception
Rapports
Enregistrement des données
Demande de confirmation
Confirmation

Sauvegarde des données et mise à jour

Confirmation de sauvegarde

Avertir les utilisateurs concernés

- FIG. 23 : Diagramme de séquence N°6 -

Etude conceptuelle Modélisation dynamique

80

CAS N° 7 : Gérer les références pièces

Système / Gestion références

Chef de département

Ajouter ou modifier une pièce

Mise à jour des données

Enregistrement des données

Demande de confirmation

Confirmation

Sauvegarde des données et mise à jour

Confirmation de sauvegarde

Avertir les utilisateurs concernés

- FIG. 24 : Diagramme de séquence N°7 -

Etude conceptuelle Modélisation dynamique

CAS N° 8 : Vérifier les commandes

Système / Commande

Chef de département		Vérifier commande
		Editer commande

Mise à jour des données

		Enregistrement des données
		Demande de confirmation
		Confirmation

81

Sauvegarde des données et mise à jour

Confirmation de sauvegarde

Avertir les utilisateurs concernés

- FIG. 25 : Diagramme de séquence N°8 -

Etude conceptuelle Modélisation dynamique

82

CAS N° 9 : Traiter les factures

Système / Facture

Chef de département

Charger facture et autres documents

raitement des données

Vérifier le résultat des traitements

Enregistrement des données

Demande de confirmation

Confirmation

Sauvegarde des données et mise à jour

Confirmation de sauvegarde

Avertir les utilisateurs concernés

- FIG. 26 : Diagramme de séquence N°9 -

Etude conceptuelle Modélisation dynamique

À présent nous allons essayer de cerner les états et comportements dynamiques des différents objets manipulés dans le nouveau système (Les plus importants du moins) à travers les différentes situations déclenchées par des évènements internes ou externes, ainsi que les multiples transitions entre ces états, et cela à travers le diagramme d'états-transitions qui est proposé par UML à cet effet.

1) L'objet ligne-commande :

/ Préparation

/ Vérification

Vérifiée

Préparée

/ Envoi de la commande

/Justifier la demande

Lancée

/ Non justifiée

Annulé

/ Si non disponible

En Back Order

Facturée

/ Erreur à la réception

En réclamation

Reçue

/ Disponible

83

- FIG. 27 : Diagramme d'états-transitions N°1 -

Etude conceptuelle Modélisation dynamique

2) L'objet commande :

Passée

Facturée

Livrée

En attente

Comptabilisée

Archivée

- FIG. 28 : Diagramme d'états-transitions N°2 -

2) L'objet expédition :

84

- FIG. 29 : Diagramme d'états-transitions N°3 -

PARTIE 3 :

RÉALISATION

Etude conceptuelle Passage au modèle relationnel

Passage au modèle relationnel :

86

- FIG. 30 : Schéma relationnel de la base de données -

Etude conceptuelle Passage au modèle relationnel

87

Script de la création des tables de la base:

create table Piece

(

Ref_Piece VARCHAR2 (50) not null,

Poids NUMBER,

IsSubstitut BOOLEAN,

DateDebProd DATE,

DateFinProd DATE,

Qty_Pkg NUMBER,

Pays_Origine VARCHAR2 (50),

Volume NUMBER,

Vor_Max NUMBER,

TMC_Stock_Code VARCHAR2 (10),

Danger_Code VARCHAR2 (10),

PU NUMBER

)

alter table Piece

add constraint PK_Piece primary key (Ref_Piece);

create table PieceICC

(

Ref_PieceICC VARCHAR2 (50) not null,

Ventes NUMBER,

BackOrders NUMBER,

LostSales NUMBER,

SSdemand NUMBER,

SSleadtime NUMBER,

OrderCycle NUMBER,

LeadTime NUMBER,

ClassePiece CHAR,

DemandeGlobale NUMBER,

DemandeMoyenne NUMBER,

MIP NUMBER,

Ref_Piece VARCHAR2 (50) not null

)

alter table PieceICC

add constraint PK_PieceICC primary key (Ref_PieceICC);

alter table PieceICC

add constraint FK_PieceICC_Piece foreign key (Ref_Piece) references Piece (Ref_Piece);

Etude conceptuelle Passage au modèle relationnel

88

create table PieceCMD

(

Ref_PieceCMD VARCHAR2 (50) not null,

MIP NUMBER,

ClassePiece CHAR,

OnHand NUMBER,

OnOrder NUMBER,

BackOrder NUMBER,

SOQ NUMBER,

Ref_Piece VARCHAR2 (50) not null

)

alter table PieceCMD

add constraint PK_PieceCMD primary key (Ref_PieceCMD);

alter table PieceCMD

add constraint FK_PieceCMD_Piece foreign key (Ref_Piece)

references Piece (Ref_Piece);

create table PieceSUB

(

Ref_PieceSUB VARCHAR2 (50) not null,

Ref_Substitut CHAR,

Ref_Piece VARCHAR2 (50) not null

)

alter table PieceSUB

add constraint PK_PieceSUB primary key (Ref_PieceSUB);

alter table PieceSUB

add constraint FK_PieceSUB_Piece foreign key (Ref_Piece)

references Piece (Ref_Piece);

create table LigneCommande

(

Num_Ligne_Commande VARCHAR2 (50) not null,

Num_Commande VARCHAR2 (50) not null,

Ref_Piece VARCHAR2 (50) not null,

Qty_Commandee NUMBER,

PUC NUMBER,

Total_Ligne NUMBER,

Etat_Ligne VARCHAR2 (100)

)

alter table LigneCommande

add constraint PK_LigneCommande primary key (Num_Ligne_Commande,

Num_Commande );

alter table LigneCommande

add constraint FK_LigneCommande_Commande foreign key (Num_Commande)

references Commande(Num_Commande);

alter table LigneCommande

add constraint FK_LigneCommande_Piece foreign key (Ref_Piece)

references Piece(Ref_Piece);

Etude conceptuelle Passage au modèle relationnel

89

create table Commande (

Num_Commande VARCHAR2 (50) not null,

Num_Fournisseur VARCHAR2 (50) not null,

Date_Commande DATE,

Nbr_Ligne_Commande NUMBER,

Montant_HT NUMBER, Montant_TTC NUMBER )

alter table Commande

add constraint PK_Commande primary key (Num_Commande);

alter table Commande

add constraint FK_Commande_Fournisseur foreign key (Num_Fournisseur) references Fournisseur(Num_Fournisseur);

create table LigneFacture

(

Num_Facture VARCHAR2 (50) not null,

Num_Ligne_Facture VARCHAR2 (50) not null,

Ref_Piece VARCHAR2 (50) not null,

Qty_Facturee NUMBER,

PUF NUMBER,

Num_Ligne_Commande VARCHAR2 (50) not null,

Num_Commande VARCHAR2 (50) not null,

Num_Caisse VARCHAR2 (50)

)

alter table LigneFacture

add constraint PK_LigneFacture primary key (Num_Facture, Num_Ligne_Facture);

alter table LigneFacture

add constraint FK_LigneFacture_LigneCommande foreign key (Num_Ligne_Commande, Num_Commande)

references LigneCommande(Num_Ligne_Commande, Num_Commande);

alter table LigneFacture

add constraint FK_LigneFacture_Commande foreign key (Num_Commande) references Commande(Num_Commande);

alter table LigneFacture

add constraint FK_LigneFacture_Facture foreign key (Num_Facture) references Facture(Num_Facture);

Etude conceptuelle Passage au modèle relationnel

90

create table Expedition

(

Num_Expedition VARCHAR2 (50) not null,

Somme_Qty NUMBER,

Nbr_Caisse_E NUMBER,

Date_Facture_Système DATE,

Date_Facture_Origine DATE,

Date_Rec_Connaissement DATE,

Num_Connaissement VARCHAR2 (50),

Date_Connaissement DATE,

Date_Deb_Domiciliation DATE,

Date_Fin_Domiciliation DATE,

Date_Declaration DATE,

Num_Remeorque VARCHAR2 (50),

Poids_Marchandise NUMBER,

Volume_Marchandise NUMBER,

Embarquement DATE,

Accostage DATE,

Debarquement DATE,

Dem_Cheque_Transitaire DATE,

Dem_Cheque_Interne DATE,

Remise_Cheque_Interne DATE,

Remise_Cheque_Transitaire DATE,

Remise_Bon_Enlevé DATE,

Date_Livraison DATE,

Debut_Reception DATE,

Fin_Reception DATE,

Lead_Time NUMBER,

Dossier_Complet DATE,

Remise_Comptabilite DATE,

Observations VARCHAR2(2000)

)

alter table Expedition

add constraint PK_Expedition primary key (Num_Expedition);

create table Facture

(

Num_Facture VARCHAR2 (50) not null,

Date_Facture DATE,

Montant_Facture_HT NUMBER,

Montant_Facture_TTC NUMBER,

Nbr_Ligne_Facture NUMBER,

Nbr_Caisse NUMBER,

Num_Expedition VARCHAR2 (50)

)

alter table Facture

add constraint PK_Facture primary key (Num_Facture);

alter table Facture

add constraint FK_Facture_Expedition foreign key (Num_Expedition)

references Expedition(Num_Expedition);

Etude conceptuelle Passage au modèle relationnel

91

create table EtatComptable

(

Num_EtatComptable VARCHAR2 (50) not null,

Num_Expedition VARCHAR2 (50) not null,

Type_Shipment VARCHAR2 (50),

Type_Container VARCHAR2 (50),

Taux_Change NUMBER,

Montant_FOB NUMBER,

Montant_Fret_Loading NUMBER,

Montant_Assurance NUMBER,

Droit_Douane NUMBER,

Montant_Transit NUMBER,

Montant_SDV NUMBER,

Cout_Revient NUMBER,

LC_Factor VARCHAR2 (30)

)

alter table EtatComptable

add constraint PK_EtatComptable primary key (Num_EtatComptable);

alter table EtatComptable

add constraint FK_Etatcomptable_Expedition foreign key (Num_Expedition) references Expedition (Num_Expedition);

create table Reception

(

Num_Reception VARCHAR2 (50) not null,

Num_Expedition VARCHAR2 (50) not null,

Nbr_Caisse_R NUMBER,

Num_Container VARCHAR2 (50),

Date_Arrivee DATE,

Start_Time DATE,

End_Time DATE,

IsError BOOLEAN,

Qty_Recue NUMBER,

Qty_Manque NUMBER,

Qty_Exces NUMBER,

Qty_Endommagee NUMBER,

Code_Erreur VARCHAR2 (30),

Code_CPD VARCHAR2 (30),

Code_Paker_Picker VARCHAR2 (30),

Remarques VARCHAR2(2000)

)

alter table Reception

add constraint PK_Reception primary key (Num_Reception);

alter table Reception

add constraint FK_Reception_Expedition foreign key (Num_Expedition)

references Expedition (Num_Expedition);

Etude conceptuelle Passage au modèle relationnel

92

create table Fournisseur

(

Num_Fournisseur VARCHAR2 (50) not null,

Nom_Fournisseur VARCHAR2 (100), Adr_Fournisseur VARCHAR2(200), Tel_Fournisseur NUMBER,

Fax_Fournisseur NUMBER,

Mail_Fournisseur VARCHAR2 (100), Web_Fournisseur VARCHAR2 (100) )

alter table Fournisseur

add constraint PK_Fournisseur primary key (Num_Fournisseur);

create sequence SEQ_lignefacture minvalue 1 maxvalue 999999999999999999999999999 start with 1 increment by 1

nocache;

create sequence SEQ_lignecommande minvalue 1 maxvalue 999999999999999999999999999 start with 1 increment by 1

nocache;

create sequence SEQ_fournisseur minvalue 1 maxvalue 999999999999999999999999999 start with 1 increment by 1

nocache;

create sequence SEQ_expedition

minvalue 1 maxvalue 999999999999999999999999999 start with 1 increment by 1

nocache;

Etude conceptuelle Passage au modèle relationnel

93

create sequence SEQ_reception

minvalue 1

maxvalue 999999999999999999999999999

start with 1

increment by 1

nocache;

create sequence SEQ_comptabilite minvalue 1 maxvalue 999999999999999999999999999 start with 1 increment by 1

nocache;

Il faut toutefois commencer par créer un schéma de base de données sous Oracle comme suit :

SQL> CONN SYSTEM/MANAGER;

SQL> Create User «user-name« identified by «mot-de-passé« ;

SQL> Grant connect, DBA, resource to «user-name« ; // Allouer les privileges au user

SQL> Conn user-name/mot-de-passe

SQL> Create table.....etc

Réalisation de la nouvelle application Architecture

94

Architecture globale de la nouvelle application :

En ce qui concerne la structure globale de notre application, nous avons opté pour un schéma simple comportant un serveur de données centralisé permettant ainsi de conserver l'intégrité des données relié aux différents postes du domaine, suivant ainsi le modèle d'architecture réseau clients/serveur. Notons aussi que nous prévoyons de mettre en place une version mobile du module réception afin de pouvoir mettre à jour des données au niveau du magasin lors des livraisons sans faire d'aller-retour, et ceci soit en reliant directement les appareils mobiles au serveur, ou en les synchronisant avec le poste concerné avant d'effectuer une mise à jour ultérieure. Une telle solution mobile pour les réceptions serait, selon nous, profitable si elle était accompagnée de la mise en place d'un nouveau dispositif d'étiquetage que nous allons introduire comme suit :

La marchandise reçue doit être étiquetée à la livraison, or on dispose de toutes les données requises au préalable (référence, quantité commandée, localisation de la pièce en stock, numéro de la facture correspondante, numéro de la caisse contenant la pièce), sauf la quantité reçue qui sera enregistrée sur place, à la vérification. A partir de là se justifie l'emploi de la technologie mobile, qui contiendra les données citées précédemment, auxquelles on rajoutera les données manquantes au fur et à mesure du déroulement de la réception. Et on imprimera sur place les étiquettes, que nous prévoyons aussi de remplacer par un codage en deux dimensions utilisé couramment au japon : le QR Code.

Le QR Code est un code-barres en 2 dimensions (code matrice) pouvant stocker jusqu'à 7089 caractères numériques, 4296 caractères alphanumériques (contrairement au code barre "traditionnel" qui lui ne peut stocker que de 10 à 13 caractères) ou 2953 octets . Il a l'avantage de pouvoir stocker beaucoup d'informations tout en étant petit et rapide à scanner. Ainsi, le sigle « QR » dérive de « Quick Response » car le contenu peut être décodé rapidement. (Source Wikipédia).

Ce dispositif permettrait d'apporter de l'aide aussi à la gestion du stock et de l'inventaire en mettant par exemple dans chaque rayon des QR codes contenant les quantités présentes en stock mises à jour régulièrement dans le système. L'avantage du QR Code réside aussi qu'il n'a pas besoin de lecteur spécifique pour le décoder, une simple application installée sur un smart phone ou n'importe quel appareil mobile permet de le faire.

Une autre technologie existe dans ce sens : La RFID (Identification par radio fréquence) et dont on pourrait faire usage à l'avenir. Il s'agit d'une minuscule puce reliée à une antenne qui permet d'identifier un objet, d'en suivre le cheminement et d'en connaître les caractéristiques à distance grâce à une étiquette émettant des ondes, attachée ou incorporée à l'objet. La technologie RFID permet la lecture des étiquettes même sans ligne de vue directe, ce qui permettrait par la suite de faciliter la traçabilité et la localisation de n'importe quel pièce en stock.

Réalisation de la nouvelle application Architecture

Serveurs

Team Leader

Chef de département

Données

Service réception

Reports

Shipment

ICC

- FIG. 31 : Architecture de la nouvelle application -

95

- FIG. 32 Un exemple de code QR -

Réalisation de la nouvelle application Outils de développement

96

Présentation des outils de développement :

Choix du langage :

Le choix s'est porté sur le C#.NET. Une des grandes forces de ce langage réside dans le fait qu'il supporte de nombreuses variétés de bases de données, ainsi que l'accessibilité et la fiabilité. C#.NET est probablement aussi l'un des meilleurs langages pour écrire des applications clientes graphiques. L'environnement de travail qui l'accompagne « Microsoft Visual Studio 2005 » est considéré comme la plate forme de développement la plus complète qui existe, notamment grâce au FRAMEWORK.NET qui fournit un accès à des technologies clés simplifiant le développement d'applications Web ASP et de Services Web XML et aux multiples langages et outils qui l'accompagnent.

Choix du SGBD:

D'autre part, l'implémentation de la partie données se fera sous Oracle en utilisant la version ORACLE 10g afin de permettre principalement l'exploitation de cette partie une fois le passage à l'ERP Oracle Business Suite effectué. Mais cette « obligation » ne diminue en rien les performances d'Oracle qui est l'un des SGBD les plus puissants qui existent. Il se caractérise principalement par :

- Fonctionne sur de nombreuse plate forme.

- PL/SQL, langage de programmation propre à Oracle, utilisé pour créer des triggers lors de l'insertion, la modification ou l'effacement d'éléments

- Gestion de très grands volumes de données, taille maxi de 65 536 fichiers de 128 To chacun en utilisant les BigFiles de la version 10gR2 ou 10.2.

- Gestion centralisée de plusieurs instances

- Accès aux données système via des vues, bien plus aisément manipulable que des procédures stockées.

- Un système de droits et de mots de passe très souples et sécurisés, qui vérifie aussi les hôtes se connectant. Les mots de passe sont bien protégés, car tous les échanges de mot de passe sont chiffrés, même lors des connexions.

Réalisation de la nouvelle application Sécurité

97

SECURITE :

La sécurité des systèmes d'information (SSI) est l'ensemble des moyens techniques, organisationnels, juridiques et humains nécessaires et mis en place pour conserver, rétablir, et garantir la sécurité de l'information et du système d'information.

(Source : WIKIPEDIA)

Partant de cette définition qui nous a paru la plus juste, nous préconisons de déployer un ensemble de mesures relatives à la sécurisation qui ont pour objectifs de :

1. Assurer la disponibilité des services et des informations (ordinateurs, réseaux,
périphériques, applications, données, fichiers...) en permettant une accessibilité aux utilisateurs selon leurs droits d'accès et privilèges.

2. Assurer la confidentialité des informations en définissant des privilèges et des droits
d'accès.

3. Assurer l'intégrité du système en n'autorisant la mise à jours de ses données qu'aux
personnes appropriées.

Nous résumons ces mesures à travers ce tableau bidimensionnel :

Réalisation de la nouvelle application Sécurité

98

Actions Moyens	Conserver la sécurité	Rétablir la sécurité	Garantir la sécurité
Techniques	- Mettre en place un système de gestion des incidents relatifs à l'application. - Cybersurveillance (Réseau) - Diagnostic périodique des machines - Sauvegarder régulièrement ses données	- Serveur de secours en cas de panne et copie de sauvegardes des données et fichiers dans des endroits géographiquement différents.	- Contrôle des accès avec la gestion des mots de passe. - Traçabilité totale au niveau des accès. - Utilisation de logiciel antivirus, pare-feu...etc. - Installation d'onduleurs - Sécuriser l'accès aux locaux ou sont installés les serveurs - Confier l'administration de l'application à l'administrateur système du service informatique.
Organisationnels	- Prendre des mesures disciplinaires à l'encontre des utilisateurs non respectueux de la charte informatique.		- Mettre en place des procédures pour la gestion des données métiers de ceux du personnel.
Juridiques	- Protection des droits de propriétés à chaque version nouvelle de l'application.		- Protection des droits de propriété intellectuelle et industrielle. - Protection des informations personnelles ou relatives à la vie privée des utilisateurs.
Humains	- Mettre en place une charte proposée à l'utilisateur dés son enregistrement afin qu'il soit informé des différents points à respecter en utilisant l'application.	- Définir les actions à entreprendre et les personnes à contacter en cas de détection d'une intrusion.	- Formation et sensibilisation des utilisateurs quand à le sécurité de l'application et des données. - Empêcher l'accès physique aux personnes non autorisées.

- TAB. 14 : Mesures sécuritaires à entreprendre -

Réalisation de la nouvelle application Aperçu

99

Aperçu de la nouvelle application :

Identification :

Partie administration :

Réalisation de la nouvelle application Aperçu

100

Outil de recherche :

Vérification des factures :

Réalisation de la nouvelle application Aperçu

101

Comptabilité :

CONCLUSION

GÉNÉRALE

103

Conclusion générale

CONCLUSION GÉNÉRALE :

Ce document est l'aboutissement d'une année d'efforts et de travail où nous avons essayé d'apporter les meilleures solutions à des problèmes identifiés par les employés ou par nous même.

Le logiciel qui représente le résultat tangible de tous ces efforts a permis de rendre plus fluide et plus cohérent le travail accompli tout au long du processus en le réduisant (selon nos calculs) de 3 journées de travail grâce à l'automatisation de certaines tâches ; D'avoir en temps réel un aperçu sur l'état de n'importe quel commande (puisque on trace les lignes commande qui deviendront lignes facture et références réceptionnées au final) ; De diminuer sensiblement voir totalement les pertes liées aux erreurs de facturation grâce au module de chargement des factures.

Néanmoins, il ne faut pas oublier que le système demeure un premier essai, et donc il reste sujet à modifications et amélioration, essentiellement dans la partie réception qui, comme nous l'avions mentionné lors de la partie réalisation, devra évoluer en un module à part capable de gérer des données à l'extérieur lors de l'arrivée des livraisons grâce à une technologie mobile et synchroniser ces données recueillies avec les données de la base de donnée centralisée.

En dernier lieu, l'intégration de notre projet à l'ERP ORACLE sera notre ultime satisfaction, ce qui n'a pas encore eu lieu jusqu'à présent en raison du non déploiement de l'ERP à ce jour, ce qui nous donne aussi une autre vision des difficultés qu'on aura à affronter en tant qu'informaticiens responsables d'un projet aussi important que la mise en place d'un système d'information ou de la migration d'un système à un autre. Cependant : « À coeur vaillant rien d'impossible ».

BIBLIOGRAPHIE

&

WEBOGRAPHIE

105

Bibliographie & webographie

1. `UML par la pratique' - Études de cas et exercices corrigés, Pascal ROQUES,
Deuxième édition, Éditions EYROLLES, 2001. [UML01]

2. `Modélisation objet avec UML', Pierre-Alain MULLER, Nathalie GAERTNER,
Deuxième édition 2000, Troisième tirage 2001. [UML02]

3. Mémoire de fin d'étude de l'Institut National de formation en Informatique (INI),
Conception et réalisation d'une application de gestion électronique des documents sur une plate forme DOCUMENTUM pour le département Finances & Administration de l'entreprise BRC, CHERCHALI Nabil, MAKHOUKH Amine, Promotion 2004/2005.

4. Mémoire de fin d'étude de l'Institut National de formation en Informatique (INI),
Conception et réalisation d'un système d'information pour le service après vente chez TOYOTA ALGÉRIE, EZZIANE Djallal Eddine, GHALAMALLAH Adda, Promotion 2006/2007.

5. C#.NET Web Developer's Guide, Adrian TURTSCHI, Jason WERRY, Greg
HACK, Published by Syngress Publishing Inc., 2002.

6. APPRENTISSAGE DU LANGAGE C#, Serge TAHÉ, - ISTIA - Université
d'Angers, Mai 2002.

7. WORKING WITH MICROSOFT® VISUAL STUDIO® 2005, Craig SKIBO,
Marc YOUNG, Brian JOHNSON, published by Microsoft Press, 2006.

8. ORACLE Database 10g: The Complete Reference, Kevin Loney, McGraw-
Hill/Osborne, 2004.

9. SQL*Plus® User's Guide and Reference, Release 8.1.6, ORACLE®, October
1999.

10. http://www.developpez.com

11. http://www.commentcamarche.net

12. http://uml.free.fr/

13. http://wikipedia.org/

14. http://www.toyota.com

15. http://www.toyota.fr

16. http://www.cristallin.com/irris-docs/Stock%20-20Gestion%20des%20commandes.pdf

17. http://www.ic.gc.ca/epic/site/dir-ect.nsf/fr/h_uw00381f.html

18. http://websigo.obspm.fr/sigo/comptabilite/nabuco/documentation/depenses/ gestion_des_commandes.pdf