IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Modéliser la gestion des interventions de maintenance


Sujet :

Schéma

  1. #1
    Nouveau membre du Club
    Inscrit en
    mars 2008
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : mars 2008
    Messages : 30
    Points : 37
    Points
    37
    Par défaut Modéliser la gestion des interventions de maintenance
    Bonjour,

    des clients nous envoient des demandes d'intervention le plus souvent par mail
    ces mails sont transcrit en lignes dans un tableau excel qui contient
    comme colonnes toutes les données necessaire (client, contact, site, dates..., etat avancement, technicien, remarque, numFacture....).

    apres reflexion, je me retrouve avec quelques regles de gestion et un MCD (ci-joint).
    j'ai volontairement reduit l'analyse au minimum, je veut etre sûr avant d'etoffer l'ensemble.

    qu'en penser vous ?

    merci par avance pour l'aide que vous pourriez m'apporter.


    ps : la comptabilité ne fait pas vraiment partie de mon analyse, la facture n'est là que pour recuperer le numero de facture !
    Images attachées Images attachées   

  2. #2
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    8 999
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 8 999
    Points : 33 727
    Points
    33 727
    Billets dans le blog
    3
    Par défaut
    Bonjour voxben et bienvenue dans ce forum.

    Vous avez rédigé les règles de gestion, c'est très bien, vous avez structuré votre MCD par domaine, c'est très bien aussi, bravo !

    Uner remarque d'ordre général :

    il est plus facile de contrôler la conformité du MCD aux règles en utilisant le même verbe dans les règles de gestion et dans les noms d'associations. Par exemple

    R01 - un client peut posséder un ou plusieurs sites
    R02 - un site appartient à un et un seul client

    à remplacer par

    R01 - un client peut posséder un ou plusieurs sites
    R02 - un site est possédé par un et un seul client

    et du coup, dans le MCD, on nomme l'association correspondante (posseder)

    Pour le reste, il y a quelques incohérences entre règles de gestion et MCD, ce sont sans doute des erreurs d'étourderie.
    Par exemple R01 stipule un ou plusieurs sites, mais sur le MCD, on a 0,n, il y a d'autres cas semblables.

    Pour la partie "demandes client", une même demande peut être envoyée sur plusieurs média, mais comment sait on qu'il s'agit de la même demande ?
    Y a-t-il une référence externe émise par le client qui serait commune et qui permettrait de s'y retrouver ? Auquel cas il faut ajouter cet attribut dans la demande.

    La demande peut citer un ou plusieurs systèmes et elle peut également générer un ou plusieurs ODS qui sont également en relation avec un système.
    Aucune règle de gestion ne précise si le système désigné par l'ODS de la demande doit être cohérent avec le système cité par la demande.
    Si la cohérence doit être assurée, alors il faut ajouter une règle de gestion en ce sens et la matérialiser par une contrainte d'intégrité d'inclusion sur le MCD.

    La partie "traitement opérationnel" nécessite plus de temps, j'y reviendrai plus tard.

  3. #3
    Nouveau membre du Club
    Inscrit en
    mars 2008
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : mars 2008
    Messages : 30
    Points : 37
    Points
    37
    Par défaut
    Bonjour escartefigue,

    ci-joint mon nouveau MCD
    apres relecture des regles et du MCD, j'ai effectué quelques modifications en tenant compte de vos remarques :

    Citation Envoyé par escartefigue Voir le message
    ...et du coup, dans le MCD, on nomme l'association correspondante (posseder)
    association renommée.

    Citation Envoyé par escartefigue Voir le message
    Pour le reste, il y a quelques incohérences entre règles de gestion et MCD, ce sont sans doute des erreurs d'étourderie.
    Par exemple R01 stipule un ou plusieurs sites, mais sur le MCD, on a 0,n, il y a d'autres cas semblables.
    j'ai cru que pour exprimer (0,n) il suffisait de dire "peut posseder un ou plusieurs" et pour (1,n) il fallait dire "possede un ou plusieurs"
    ou alors pour exprimer (0,n) doit-je plutôt dire " possede zero ou plusieurs" ?

    Citation Envoyé par escartefigue Voir le message
    Pour la partie "demandes client", une même demande peut être envoyée sur plusieurs média, mais comment sait on qu'il s'agit de la même demande ?
    Y a-t-il une référence externe émise par le client qui serait commune et qui permettrait de s'y retrouver ? Auquel cas il faut ajouter cet attribut dans la demande.
    remarque pertinante, on ne le sait pas, coté client aucune reference n'existe, actuellement les demandes clients sont "analysée" par un collegue, c'est pour cela que j'ai pensée un creer une notion de ODS qui filtrera et classera les demandes.

    Citation Envoyé par escartefigue Voir le message
    La demande peut citer un ou plusieurs systèmes et elle peut également générer un ou plusieurs ODS qui sont également en relation avec un système.
    Aucune règle de gestion ne précise si le système désigné par l'ODS de la demande doit être cohérent avec le système cité par la demande.
    Si la cohérence doit être assurée, alors il faut ajouter une règle de gestion en ce sens et la matérialiser par une contrainte d'intégrité sur le MCD.
    je rajoute une regle R14A - le systeme designé dans un ods doit etre citer dans la ou les demandes qui ont generé cet ods
    (pour l'instant je ne sait pas comment créer une contrainte d'integrité)
    Images attachées Images attachées   

  4. #4
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    8 999
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 8 999
    Points : 33 727
    Points
    33 727
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par voxben Voir le message
    j'ai cru que pour exprimer (0,n) il suffisait de dire "peut posseder un ou plusieurs" et pour (1,n) il fallait dire "possede un ou plusieurs"
    ou alors pour exprimer (0,n) doit-je plutôt dire " possede zero ou plusieurs" ?
    En effet "peut" exprime le caractère facultatif, mais "un à plusieurs" est contradictoire
    Je prèfère "peut posséder zéro à plusieurs" ou "peut posséder plusieurs" pour lever toute ambiguité



    Citation Envoyé par voxben Voir le message
    je rajoute une regle R14A - le systeme designé dans un ods doit etre citer dans la ou les demandes qui ont generé cet ods
    (pour l'instant je ne sait pas comment créer une contrainte d'integrité)
    Je me suis mal exprimé, ce n'est pas une contrainte d'intégrité, mais une contrainte d'inclusion.
    Dans LOOPING, ça se code en deux étapes, la première consiste à utiliser l'outil contrainte (cercle jaune), en choisir le type (inclusion) puis la faire pointer en premier sur l'association ciblée, puis l'association d'origine et enfin sur les entités pivot.
    Ensuite, on clique sur la contrainte pour y ajouter le code SQL qui la contrôlera (ALTER TABLE... ADD CONSTRAINT...)

  5. #5
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    8 999
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 8 999
    Points : 33 727
    Points
    33 727
    Billets dans le blog
    3
    Par défaut
    Concernant la partie "traitement opérationnel"

    Je suppose que les interventions nécessitent des compétences particulières et que tous les techniciens n'ont pas toutes les compétences.
    Auquel cas il faut affecter un technicien compétent pour l'intervention.
    Pour ce faire, il faut que chaque intervention soit associée à une ou plusieurs typologies pour s'en assurer.

    Exemple :
    l'intervention I1 requiert des compétences en électricité et en plomberie : je choisis le technicien T1 pour l'électricité et le technicien T2 pour la plomberie, ou la perle rare, le technicien T3 compétent à la fois en électricité et en plomberie.
    La multicompétence n'est peut-être pas de mise si en ce cas vous créez plusieurs ODS (un par compétence) ou plusieurs interventions (idem)
    Il faut sans doute aussi prévoir des dépendances entre interventions : par exemple, il faut faire intervenir le plombier avant l'électricien.
    Peut-être faut il même prévoir des niveaux de compétence (plomberie niveau 1, niveau 2...).
    À détailler.

    Dans votre MCD, un ODS concerne un et un seul système, mais potentiellement plusieurs interventions et plusieurs travaux qui eux mêmes sont associés à un système.
    En l'état, le système désigné par l'ODS peut être différent de celui ou certains de ceux désignés par les travaux des interventions.
    Là aussi, il faut préciser si c'est acceptable ou pas, rédiger les règles de gestion correspondantes et positionner les éventuelles contraintes.


    Concernant la partie "facturation"

    Le modèle ne permet pas de faire le lien entre la demande du client et la facture.
    On ne pourra donc pas mentionner le ou les n° de demandes du client sur la facture, c'est fâcheux.
    S'il s'agit de clients particulier, c'est peut-être acceptable, mais s'il s'agit de commandes d'entreprises ou d'institutionnels, ça ne va pas.
    Pire : on peut sur une même facture, prendre en compte des PV d'interventions issues de différents ODS de différents clients, là c'est illégal

  6. #6
    Nouveau membre du Club
    Inscrit en
    mars 2008
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : mars 2008
    Messages : 30
    Points : 37
    Points
    37
    Par défaut
    Bonsoir escartefigue,

    j'avance à petit pas ...
    pour preciser le contexte, nous maintenons des systemes de securités à savoir (videosurveillance, control d'acces, detection incendie, detection intrusion,...)
    nos techniciens sont qualifiés sur tout les systemes, seul leur niveau de competance varie.

    Citation Envoyé par escartefigue Voir le message
    Concernant la partie "traitement opérationnel"

    Je suppose que les interventions nécessitent des compétences particulières et que tous les techniciens n'ont pas toutes les compétences.
    Auquel cas il faut affecter un technicien compétent pour l'intervention.
    Pour ce faire, il faut que chaque intervention soit associée à une ou plusieurs typologies pour s'en assurer.

    Exemple : l'intervention I1 requiert des compétences en électricité et en plomberie : je choisis le technicien T1 pour l'électricité et le technicien T2 pour la plomberie, ou la perle rare, le technicien T3 compétent à la fois en électricité et en plomberie.
    Citation Envoyé par escartefigue Voir le message
    Peut-être faut il même prévoir des niveaux de compétence (plomberie niveau 1, niveau 2...).
    Pour ce faire, j'ai crée l'entité competence (niveau de competence), nos techniciens etant qualifié sur tout les systemes que nous maintenons).

    Citation Envoyé par escartefigue Voir le message
    La multicompétence n'est peut-être pas de mise si en ce cas vous créez plusieurs ODS (un par compétence) ou plusieurs interventions (idem)
    un ods est crée par systeme, et une intervention peu regrouper plusieurs ods
    le niveau de competence requis est determiné au niveau de l'intervention en fonction de critere empirique (en gros c'est le responsable maintenance qui decide en fonction des disponibilités, des urgences et de l'age du capitaine...)

    Citation Envoyé par escartefigue Voir le message
    Il faut sans doute aussi prévoir des dépendances entre interventions : par exemple, il faut faire intervenir le plombier avant l'électricien.
    vu la nature de nos interventions, pour l'instant ce types de dependances, ne me parait pas necessaire.


    Citation Envoyé par escartefigue Voir le message
    Dans votre MCD, un ODS concerne un et un seul système, mais potentiellement plusieurs interventions et plusieurs travaux qui eux mêmes sont associés à un système.
    En l'état, le système désigné par l'ODS peut être différent de celui ou certains de ceux désignés par les travaux des interventions.
    Là aussi, il faut préciser si c'est acceptable ou pas, rédiger les règles de gestion correspondantes et positionner les éventuelles contraintes.
    en effet, une fois sur site, le technicien peut toucher à un systeme même si celui-ci n'est pas designer par un ods, ou cité par une demande (erreur de formulation client ou defaut constaté sur site), ce qui importe au final c'est "l'acceptance" (signature client sur PV).


    Citation Envoyé par escartefigue Voir le message
    Concernant la partie "facturation"

    Le modèle ne permet pas de faire le lien entre la demande du client et la facture.
    On ne pourra donc pas mentionner le ou les n° de demandes du client sur la facture, c'est fâcheux.
    S'il s'agit de clients particulier, c'est peut-être acceptable, mais s'il s'agit de commandes d'entreprises ou d'institutionnels, ça ne va pas.
    Pire : on peut sur une même facture, prendre en compte des PV d'interventions issues de différents ODS de différents clients, là c'est illégal
    au depart je ne comptais pas modeliser la facturation, ce qui m'interresse c'est la recuperation du numero de facture au niveau du pv pour pouvoir cloturer le cycle de vie d'une demande.
    finalement j'ai rajouté :
    la relation signer entre client et pv
    la relation imputer entre client et facture
    du coup une facture correspond à un et un seul client et un pv est signer par un et un seul client.

    voilà où j'en suis.
    Merci, pour votre aide precieuse.
    Images attachées Images attachées   

  7. #7
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    8 999
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 8 999
    Points : 33 727
    Points
    33 727
    Billets dans le blog
    3
    Par défaut
    La signature apporte une sécurité, mais le MCD en l'état autorise toujours de nombreuses failles ou interrogations que j'ai déjà citées ainsi que quelques nouvelles questions.
    Par exemple ici, le signataire du PV n'est pas forcément le technicien qui a fait l'intervention. Normal, pas normal ?

    Quoi qu'il en soit, le numéro de demande client me semble indispensable. Il est presque certain que ce numéro existe chez le client, il faut le récupérer et le stocker. Pour le reste, je ferai une contre-proposition de MCD qui garantisse que la facturation se rapporte bien à un et un seul client. Ca demande un peu de temps que je n'ai pas pour l'instant, mais j'y reviendrai.

    Note : il manque les entités-pivot des contraintes.

  8. #8
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    8 999
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 8 999
    Points : 33 727
    Points
    33 727
    Billets dans le blog
    3
    Par défaut
    Que se passe-t-il si le contact d'une demande change (démission, mutation, départ à la retraite... du contact)
    Je pense que l'émetteur de la demande est le client (invariant) et non pas le contact
    Vous confirmez ?

    Auquel cas on aurait deux associations :
    • l'une invariante entre demande et client (la demande pourrait être identifiée relativement au client)
    • l'autre entre demande et contact, modifiable, éventuellement historisée si besoin, entre demande et contact


    Par ailleurs, pour pouvoir rapprocher la facture de la demande du client, je pense qu'un ODS ne peut concerner qu'une seule demande, et qu'une intervention ne doit concerner qu'un ODS, quitte à consolider plusieurs interventions sur une même facture si besoin, mais on saura ainsi contrôler que ces interventions concernent le même client.

    Ce qui donnerait pour la première partie du MCD :

    Nom : MCD.png
Affichages : 17
Taille : 70,7 Ko


    Voici le DDL correspondant à ce modèle, ici j'ai opté au pif pour SQL server, quel est votre SGBD ? :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    CREATE TABLE CL_client(
       CL_ident INT IDENTITY,
       CL_numero CHAR(6) NOT NULL,
       CL_nom VARCHAR(50) NOT NULL,
       PRIMARY KEY(CL_ident),
       UNIQUE(CL_numero)
    );
     
    CREATE TABLE CT_contact(
       CL_ident INT,
       CT_seq SMALLINT,
       CT_nom VARCHAR(50) NOT NULL,
       PRIMARY KEY(CL_ident, CT_seq),
       FOREIGN KEY(CL_ident) REFERENCES CL_client(CL_ident)
    );
     
    CREATE TABLE MD_media(
       MD_ident INT IDENTITY,
       MD_code CHAR(4) NOT NULL,
       MD_libelle VARCHAR(50) NOT NULL,
       PRIMARY KEY(MD_ident),
       UNIQUE(MD_code)
    );
     
    CREATE TABLE DE_demande(
       CL_ident INT,
       DE_ident SMALLINT,
       DE_num_cde_client CHAR(10) NOT NULL,
       MD_ident INT NOT NULL,
       CL_ident_contact INT,
       CT_seq_contact SMALLINT,
       PRIMARY KEY(CL_ident, DE_ident),
       FOREIGN KEY(CL_ident) REFERENCES CL_client(CL_ident),
       FOREIGN KEY(MD_ident) REFERENCES MD_media(MD_ident),
       FOREIGN KEY(CL_ident_contact, CT_seq_contact) REFERENCES CT_contact(CL_ident, CT_seq)
    );
     
    CREATE TABLE OD_ods(
       CL_ident INT,
       DE_ident SMALLINT,
       OD_seq SMALLINT,
       OD_descriptif VARCHAR(50) NOT NULL,
       OD_etat CHAR(2) NOT NULL,
       PRIMARY KEY(CL_ident, DE_ident, OD_seq),
       FOREIGN KEY(CL_ident, DE_ident) REFERENCES DE_demande(CL_ident, DE_ident)
    );
     
    CREATE TABLE IT_intervention(
       CL_ident INT,
       DE_ident SMALLINT,
       OD_seq SMALLINT,
       IT_seq SMALLINT,
       IT_dtdeb_prevue DATE NOT NULL,
       IT_dtdeb_reelle DATE,
       PRIMARY KEY(CL_ident, DE_ident, OD_seq, IT_seq),
       FOREIGN KEY(CL_ident, DE_ident, OD_seq) REFERENCES OD_ods(CL_ident, DE_ident, OD_seq)
    );
     
    ALTER TABLE DE_demande
       add constraint DE_CHK_001
       check (CL_ident_contact = CL_ident or CL_ident_contact is null)
    ;


    EDIT comme indiqué précédemment, j'ai ajouté la notion de n° de commande client dans DE_demande pour éviter qu'une même demande reçue à la fois par mail et par fax (par exemple) fasse l'objet de deux ODS redondants. Ca me semble indispensable. On contrôlera soit qu'on n'enregistre qu'une seule occurrence de DE_demande pour une même commande client (auquel cas une simple contrainte UNIQUE fera l'affaire), soit qu'une seule au plus occurrence de DE_demande d'une même commande client fait l'objet d'un ODS (contrôle à faire par TRIGGER lors de la création de l'ODS)

    Est-ce que cette première partie pourrait coller ?

Discussions similaires

  1. Gestion des identifiants & réindexation, maintenance
    Par Nonoleplongeur dans le forum HyperFileSQL
    Réponses: 6
    Dernier message: 03/02/2010, 17h06
  2. [MCD] Modéliser la gestion des projets
    Par Guelykoy dans le forum Schéma
    Réponses: 10
    Dernier message: 14/02/2009, 19h42
  3. [MCD] gestion des interventions et helpdesk
    Par pipo7610 dans le forum Schéma
    Réponses: 7
    Dernier message: 03/09/2008, 13h25
  4. Gestion des actions de maintenance préventive
    Par moilou2 dans le forum Modélisation
    Réponses: 11
    Dernier message: 04/07/2008, 10h46
  5. [MEA] Comment modéliser la gestion des années ?
    Par ronando dans le forum Schéma
    Réponses: 6
    Dernier message: 10/11/2004, 18h25

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo