Discussion :

[RunCodePhp]

Salut à tous

J'envisage de créer une appli avec les technos Web pour la gestion d'un parc de machines à café.

Je suis très hésitant sur la manière de concevoir cela.

A lors actuelle j'ai les tables suivantes : (sur papier, rien de fait pour le moment)
categories : id | id_parent | libelle
A savoir qu'il y a peu de catégories, la théorie veut qu'un seul niveau suffirait, mais sait on jamais je prévois plusieurs niveaux, d'où le champ "id_parent".


- Table materiel : id | (id_categorie) | id_model | id_reference
Donc ici je prévois de créer une table "materiel" pour répertorier toutes les divers machines (les divers modèles selon chaque catégories).
(Quelque part, on peu considérer cette comme les divers types de machines.)
Il y aurait quelque chose comme une 20ène (il y a donc peu de types).


- Table materiel_etat : id | id_materiel | (id_categorie) | id_site | num_serie
Celle-ci stockera toutes les machines sans exception de manière individuelle (le N° série entre autre).


- Table materiel_historique : id | id_materiel_etat | id_etat | historique
Enfin, une table pour tracer chaque opération effectuée sur chaque machine.
(On peu considérer cette table comme la liste des fiches de chaque machine)
-> remplacement de telle ou telle pièces
-> Son état (ou statut, correspondant à quelque chose comme : Livrée, En service, En panne, Réparée, Hors service)


1/ Je me pose la question de la réelle utilité de la table "materiel".
- D'un coté je me dit que celle serait ni plus ni moins une table "model" (il y a une table "model", ce qui ferait doublon).
- De l'autre je me dit quelle serait tout de même utile car 1 matériel (ou type de machine) est une combinaison de "catégorie" et "model".
De plus, cela me permettrait de la lier à une table "pieces_detachees" pour obtenir toutes les pièces que composera chaque type de machine.


2/ Je m'interroge aussi sur le champ "id_site" de la table "materiel_etat".
Ce "id_site" c'est pour identifier où ce trouve chaque machine (Atelier, un bar, un resto (un client en faite)).
Ce pendant, je prévois aussi un champ "id_etat" dans la table "materiel_historique".
Ce "id_etat" désigne pas loin la même chose (en service, hors service, etc ...).
Si je procède ainsi, il peu avoir une incohérence entre ces 2 champs "id_site" et "id_etat", comme avoir :
-> pour "id_site" : un identifiant correspondant à un bar (donc la machine chez un client)
-> pour "id_etat" : un identifiant correspondant à livrée


3/ Je me dis que ce champ "id_site" de la table "materiel_etat" serait peut être mieux dans la table "materiel_historique" car dans la pratique les machines sont remplacées par celles réparées dans l'atelier.
Ceci me permettrais de "tracer" chaque machine.


Si vous avez des suggestions sur la manière de gérer/concevoir cela, sur ces 3 points évoqués ci-dessus ou autre, cela m'aiderais beaucoup.

Merci à vous, et bon week end par la même occasion.

[rawsrc]

Salut,

A priori, tu pars en galère. Comme tu le présens tu éparpilles des informations qui sont proches les unes des autres et c'est vraiment risqué.

Voici une autre approche :
t_categorie : OK

t_catalogue_machine :
- Informations : fabricant, poids, dimensions, produits proposés...
- id_categorie

t_machine :
- Informations principales dans l'environnement de ta société
- id_catalogue_machine

t_magasin_piece :
- pour la maintenance
- id_catalogue_machine

t_machine_suivi :
- Cahier de suivi individuel à chaque machine
- horodatage, livraison, réapprovisionnement, réparation, intervention sur site...
- ici tu gères aussi le statut (en service, hors service) et le site (localisation géographique de la cafetière)

t_client

t_contrat
- id_machine
- id_client

Au cahier de suivi tu peux adjoindre un cachier de maintenance plus technique.
Bref, fait rapidement en 10 minutes mais ce genre d'outil peut t'amener très loin dans les détails.

[RunCodePhp]

Salut Rawsrc

Effectivement, rien qu'à la nomination des tables j'étais mal parti.

Ton modèle me semble nettement plus clair, simple, et vraiment correspondre à cette gestion de parc de machines.

Concernant la table t_machine_suivi, d'accord sur les champs "horodatage, réparation, intervention sur site".
Par contre, je visualise mal les champs "livraison , réapprovisionnement".

Il est vrai qu'il y a des livraisons ou réapprovisionnement de pièces pour les machines, mais dans la pratique on peu dire que ces pièces (tout le stock même) n'est pas vraiment destinée à 1 machine en particulier.
En faite, comme toutes les machines appartiennent à la société (donc pas aux clients), dans la pratique les pièces sont extrêmement échangées entre machines, c'est presque du quotidien.

Ceci va rendre très compliqué le suivi des machines (de leur pièces), et aussi provoquer une grosse perte de temps sur les réparations des machines.
En somme, je vois mal comment on pourrait imposer de ne pas (ou plus) faire ces échanges de pièces, car cela obligera d'immobiliser des machines en attente de livraison de pièces.

Ou alors il faudrait augmenter le stock de machines en réserve opérationnelles pour pouvoir "tourner" en attendant les réapprovisionnement de pièces.
En tout cas dans la pratique ce n'est pas du tout la méthode de travail, c'est peut être pour ça qu'il y a jamais eu de gestion dans ce service.

C'est peut être l'objectif qu'il faudrait viser pour avoir une gestion plus clair, plus réelle (genre connaitre le temps d'usure des certaines pièces par rapport au volume de café effectué).


La dessus, merci Rawsrc pour ces suggestions avisées, c'est fort apprécié.

[rawsrc]

Bonjour,

Le suivi c'est dans l'optique d'archiver exhaustivement tous les évènements concernant une machine.
La souplesse vient du fait qu'il y ait un ou pas de contrat, tu pourras suivre la vie d'une machine dès qu'elle rentre dans ton périmètre.

Au niveau de la maintenance, tu gères un catalogue de pièces qui sont compatibles avec une ou plusieurs machines. Il n'y a aucun problème avec ça.
Pour chaque machine, tu peux très bien faire correspondre une liste de pièces compatibles.

Pour tes pièces provenant d'autres machines, la rigueur voudrait que tu procèdes ainsi :
- à la réception d'une machine, elle est démontée et les pièces réutilisables doivent être obligatoirement rentrées en stock magasin (statut: occasion)
NB: A l'achat de pièces, ces dernières doivent aussi être toujours rentrées en magasin (statut: neuf)
Au moment de faire l'échange d'une pièce sur une machine, tu dois toujours la sortir d'un stock magasin et jamais directement d'une autre machine.
Le stock magasin sert de tampon d'échange pour tout.

L'intérêt de cette approche c'est que tu conserveras toujours une traçabilité totale de toutes les machines et de toutes les pièces échangées (provenance, retour, destination...)
Pour faire le SAV des machines, il faut mettre le paquet sur la gestion des entrées/sorties du stock qui centralise tous les mouvements.

Après au quotidien, c'est simple, avec le suivi des évènements pour chaque machine, tu sauras exactement tout son passé, ses différents statuts, adresses et interventions.
Avec le stock magasin, tu suivras toutes les pièces, leur disponibilité, provenance et affectation.

Pour être complet , tu peux très bien pousser un peu plus loin et projeter tes états de stock de pièces. Je m'explique : à chaque commande de pièces, tu dois bien t'assurer au préalable avoir une référence en stock correspondante, vu que tu sauras la date de livraison, tu pourras ainsi prédire l'état de ton stock en conséquence. De même pour les interventions planifiées sur du matériel existant, même logique. Le rêve pour le SAV.

Bref, y a du boulot crois-moi surtout si tu pars d'une feuille blanche. Yapuka

[RunCodePhp]

Pour tes pièces provenant d'autres machines, la rigueur voudrait que tu procèdes ainsi :
- à la réception d'une machine, elle est démontée et les pièces réutilisables doivent être obligatoirement rentrées en stock magasin (statut: occasion)
NB: A l'achat de pièces, ces dernières doivent aussi être toujours rentrées en magasin (statut: neuf)
Au moment de faire l'échange d'une pièce sur une machine, tu dois toujours la sortir d'un stock magasin et jamais directement d'une autre machine.
Le stock magasin sert de tampon d'échange pour tout.

Je partage aussi ta remarque sur cette méthode de travail.
D'ailleurs, lors de ma toute 1ère rencontre avec le gérant le plus concerné pour ce service, la gestion du stock (pièces/machines) a été le tout 1er point abordé.

Cependant, la méthode de travail actuelle est tellement différente que ça va être assez chaud de bousculer tout ça rapidement.
Le nombre de mouvement est assez important pour un effectif (humain) extrêmement réduit (c'est une toute petite structure, pour ne pas dire mini, 2/3 techniciens, moi même y compris).
En faite, c'est l'ensemble de l'atelier qu'il va falloir revoir, à commencer par le rangement/classement des machines et pièces.


Malgré tout, je vais partir sur cette base là car je la trouve excellente, cela colle avec une organisation qu'il faudrait avoir.
Va falloir tout de même convaincre le gérant en question.

Je marque le sujet comme résolu. S'il y a quelques autres petits points encore hésitants j'en ferais part.
Si tu en as d'autres, n'hésites pas non plus.

Bref, y a du boulot crois-moi surtout si tu pars d'une feuille blanche

C'est le cas, et à mon sens, ç ne sera pas peut être pas celui qui demandera le plus de travail.
Mais dans les temps qui court, on ne va pas se plaindre


Grand merci à toi Rawsrc