# Gnral Dveloppement > ALM > Modlisation > Schma >  Modliser la gestion des interventions de maintenance

## voxben

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 donnes 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 sr 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 !

----------


## escartefigue

Bonjour voxben et bienvenue dans ce forum.

Vous avez rdig les rgles de gestion, c'est trs bien, vous avez structur votre MCD par domaine, c'est trs bien aussi, bravo !

*Uner remarque d'ordre gnral :*

il est plus facile de contrler la conformit du MCD aux rgles en utilisant le mme verbe dans les rgles de gestion et dans les noms d'associations. Par exemple

R01 - un client peut *possder* un ou plusieurs sites
R02 - un site *appartient*  un et un seul client

 remplacer par

R01 - un client peut *possder* un ou plusieurs sites
R02 - un site *est possd 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 incohrences entre rgles 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 mme demande peut tre envoye sur plusieurs mdia, mais comment sait on qu'il s'agit de la mme demande ?
Y a-t-il une rfrence 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 systmes et elle peut galement gnrer un ou plusieurs ODS qui sont galement en relation avec un systme.
Aucune rgle de gestion ne prcise si le systme dsign par l'ODS de la demande doit tre cohrent avec le systme cit par la demande.
Si la cohrence doit tre assure, alors il faut ajouter une rgle de gestion en ce sens et la matrialiser par une contrainte d'intgrit  d'inclusion sur le MCD.

La partie "traitement oprationnel" ncessite plus de temps, j'y reviendrai plus tard.

----------


## voxben

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 :




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


association renomme.




> Pour le reste, il y a quelques incohrences entre rgles 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 plutt dire " possede zero ou plusieurs" ?




> Pour la partie "demandes client", une mme demande peut tre envoye sur plusieurs mdia, mais comment sait on qu'il s'agit de la mme demande ?
> Y a-t-il une rfrence 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 "analyse" par un collegue, c'est pour cela que j'ai pense un creer une notion de ODS qui filtrera et classera les demandes.




> La demande peut citer un ou plusieurs systmes et elle peut galement gnrer un ou plusieurs ODS qui sont galement en relation avec un systme.
> Aucune rgle de gestion ne prcise si le systme dsign par l'ODS de la demande doit tre cohrent avec le systme cit par la demande.
> Si la cohrence doit tre assure, alors il faut ajouter une rgle de gestion en ce sens et la matrialiser par une contrainte d'intgrit 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 crer une contrainte d'integrit)

----------


## escartefigue

> 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 plutt dire " possede zero ou plusieurs" ?


En effet "peut" exprime le caractre facultatif, mais "un  plusieurs" est contradictoire
Je prfre "peut possder zro  plusieurs" ou "peut possder plusieurs" pour lever toute ambiguit  :;): 






> 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 crer une contrainte d'integrit)


Je me suis mal exprim, ce n'est pas une contrainte d'intgrit, mais une contrainte d'inclusion.
Dans LOOPING, a se code en deux tapes, la premire consiste  utiliser l'outil contrainte (cercle jaune), en choisir le type (inclusion) puis la faire pointer en premier sur l'association cible, puis l'association d'origine et enfin sur les entits pivot.
Ensuite, on clique sur la contrainte pour y ajouter le code SQL qui la contrlera (ALTER TABLE... ADD CONSTRAINT...)

----------


## escartefigue

*Concernant la partie "traitement oprationnel"*

Je suppose que les interventions ncessitent des comptences particulires et que tous les techniciens n'ont pas toutes les comptences.
Auquel cas il faut affecter un technicien comptent pour l'intervention.
Pour ce faire, il faut que chaque intervention soit associe  une ou plusieurs typologies pour s'en assurer.

Exemple : 
l'intervention I1 requiert des comptences 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 comptent  la fois en lectricit et en plomberie.
La multicomptence n'est peut-tre pas de mise si en ce cas vous crez plusieurs ODS (un par comptence) ou plusieurs interventions (idem)
Il faut sans doute aussi prvoir des dpendances entre interventions : par exemple, il faut faire intervenir le plombier avant l'lectricien.
Peut-tre faut il mme prvoir des niveaux de comptence (plomberie niveau 1, niveau 2...).
 dtailler.

Dans votre MCD, un ODS concerne un et un seul systme, mais potentiellement plusieurs interventions et plusieurs travaux qui eux mmes sont associs  un systme.
En l'tat, le systme dsign par l'ODS peut tre diffrent de celui ou certains de ceux dsigns par les travaux des interventions.
L aussi, il faut prciser si c'est acceptable ou pas, rdiger les rgles de gestion correspondantes et positionner les ventuelles contraintes.


*Concernant la partie "facturation"*

Le modle 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 fcheux.
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 mme facture, prendre en compte des PV d'interventions issues de diffrents ODS de diffrents clients, l c'est illgal  ::aie::

----------


## voxben

Bonsoir escartefigue, 

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




> *Concernant la partie "traitement oprationnel"*
> 
> Je suppose que les interventions ncessitent des comptences particulires et que tous les techniciens n'ont pas toutes les comptences.
> Auquel cas il faut affecter un technicien comptent pour l'intervention.
> Pour ce faire, il faut que chaque intervention soit associe  une ou plusieurs typologies pour s'en assurer.
> 
> Exemple : l'intervention I1 requiert des comptences 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 comptent  la fois en lectricit et en plomberie.





> Peut-tre faut il mme prvoir des niveaux de comptence (plomberie niveau 1, niveau 2...).


Pour ce faire, j'ai cre l'entit competence (niveau de competence), nos techniciens etant qualifi sur tout les systemes que nous maintenons).




> La multicomptence n'est peut-tre pas de mise si en ce cas vous crez plusieurs ODS (un par comptence) ou plusieurs interventions (idem)


un ods est cre 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 disponibilits, des urgences et de l'age du capitaine...)




> Il faut sans doute aussi prvoir des dpendances 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.





> Dans votre MCD, un ODS concerne un et un seul systme, mais potentiellement plusieurs interventions et plusieurs travaux qui eux mmes sont associs  un systme.
> En l'tat, le systme dsign par l'ODS peut tre diffrent de celui ou certains de ceux dsigns par les travaux des interventions.
> L aussi, il faut prciser si c'est acceptable ou pas, rdiger les rgles de gestion correspondantes et positionner les ventuelles contraintes.


en effet, une fois sur site, le technicien peut toucher  un systeme mme 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).





> *Concernant la partie "facturation"*
> 
> Le modle 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 fcheux.
> 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 mme facture, prendre en compte des PV d'interventions issues de diffrents ODS de diffrents clients, l c'est illgal


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.

----------


## escartefigue

La signature apporte une scurit, mais le MCD en l'tat autorise toujours de nombreuses failles ou interrogations que j'ai dj cites ainsi que quelques nouvelles questions. 
Par exemple ici, le signataire du PV n'est pas forcment le technicien qui a fait l'intervention. Normal, pas normal ?

Quoi qu'il en soit, le numro de demande client me semble indispensable. Il est presque certain que ce numro existe chez le client, il faut le rcuprer 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 entits-pivot des contraintes.

----------


## escartefigue

Que se passe-t-il si le contact d'une demande change (dmission, mutation, dpart  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 identifie relativement au client)l'autre entre demande et contact, modifiable, ventuellement historise 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 mme facture si besoin, mais on saura ainsi contrler que ces interventions concernent le mme client. 

Ce qui donnerait pour la premire partie du MCD :




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



```

```



*EDIT* comme indiqu prcdemment, j'ai ajout la notion de n de commande client dans DE_demande pour viter qu'une mme demande reue  la fois par mail et par fax (par exemple) fasse l'objet de deux ODS redondants. Ca me semble indispensable. On contrlera soit qu'on n'enregistre qu'une seule occurrence de DE_demande pour une mme commande client (auquel cas une simple contrainte UNIQUE fera l'affaire), soit qu'une seule au plus occurrence de DE_demande d'une mme commande client fait l'objet d'un ODS (contrle  faire par TRIGGER lors de la cration de l'ODS)

Est-ce que cette premire partie pourrait coller ?

----------

