DESS CCI (Compétence Complémentaire en Informatique)

Cours de SGDT  : Michel Tollenaere.

Séances du 12 et 26 Mars 2001

Vérifier les workflows et les impacts lors de la mise en oeuvre des cinq types de modifications supportées par le progiciel :
  1. les ECR (engineering change request)
  2. les ECO  (engineering change order)
  3. les Deviations (derogations)
  4. les Stop-ship (arrêt de production)
  5. les MCO (Manufacturer Change Order)
Vous identifierez précisément dans chacun des cas les impacts sur les autres objets à chaque stade de leur cycle de vie (statut). L'ensemble des écrans que vous trouverez sur l'archive Zippé (attention 49 MO) ci jointe est issu d'une mission d'audits chez un industriel en vue d'implanter un système d'information technique. Il vous est demandé d'analyser à partir des fonctionnalités d'Agile Anywhere, l'adéquation de cette solution logicielle à tout ou partie des besoins exprimés.

Vous remettrez un rapport d'audit, et une base Agile servant d'exemples des fonctionnalités que pourrait apporter cet outil.
Le travail s'effectuera en trois groupes de cinq étudiants, chaque groupe disposant de trois ordinateurs.
Je reste à votre disposition pour toute question technique d'usage des logiciels et pour toute question sur le sujet lui même.

Vous avez à votre disposition :
- un login Administrateur d'Agile
- trois postes de travail équipés d'AutoCAD 2000 (attention Agilev5 ne lit que les fichiers de la version R14 !).
    AutoCAD permet de sauvegarder en .dwg, .dxf, .bmp et vrml. Les interfaces IGES et STEP ne sont pas disponibles.
- des accès aux logiciels Excel, Powerpoint, Access....
- des tests d'interface entre logiciels CAO (DXF, IGES, STEP) effectués en 99/2000.

Vous proposerez des profils utilisateur et les mettrez en oeuvre.

Je vous recommande l'usage de la méthodologie suivante :

  • Identifier et lister les concepts, les articles, les tâches, les fichiers et documents manipulés dans les processus d'ingénierie (Items). Pour les fichiers, définir leur type informatique.
  • Identifier et lister les liens entre ces concepts (lien entre articles, lien entre document et tâche, ...). Les classer par type en fonction de la manière dont ils sont exploités.
  • Certains documents apparaitront alors comme des états des items et des liens : c'est typiquement le cas des nomenclatures. Les référencer, mais à priori, ils ne devront pas figurer dans le "modèle minimal" de la 6ème étape. Des parties de document peuvent aussi être dans ce cas. Dans ce cas de figure, séparer le document en 2 concepts (ou plus).
  • Pour chacun de ces "items", précisez la codification (identification) utilisée, les cycles de vie de ces objets, les différents états qu'ils peuvent avoir et les droits et devoirs (création, lecture, "découverte", modification, évolution, destruction) associés à ces états. 
  • Pour chacun des types de lien, précisez la codification (identification du lien) utilisée (il est fréquent qu'aucune codification n'identifie le lien), les cycles de vie des liens, les différents états qu'ils peuvent avoir et les droits et devoirs (création, lecture, "découverte", modification, évolution, destruction) associés à ces états. 
  • On obtient alors un modèle de données minimal. La difficulté est de rester au juste niveau de détail dans l'analyse des concepts. Il est très important de définir parallèlement les statuts ou états des objets dans leur cycle de vie. Définir ce qui est confidentiel (à priori le minimum).
  • Identifier les services (ou les acteurs) qui interviennent sur ces données.
  • Identifier les tâches des processus liés aux données produit. Pour chaque tâche, veillez à définir : les informations en entrée, les informations consultées (ne pas entrer dans le détail), les informations en sortie. Ne pas chercher, à ce stade, les enchainements de tâches qui ne sont pas toujours pertinent. Les enchainement doivent reposer sur des nécessités et non sur des habitudes. De plus, la tension des délais sur les processus fait beaucoup évoluer les enchainements. 
  • Vous obtiendrez alors une cartographie de l'existant en terme de système d'information produit (SIP).
  • Mettre en évidence les redondances dans les processus, les rationaliser, faire un bon BPR.
  • Définir un état cible du système d'information produit (SIP).
  • Définir des priorités de migration en fonction des gains apportés par chaque évolution du SIP. Appliquer strictement la règle des 80-20, sans quoi la loide Murphy vous guette.
  • Assurer vous que le (ou les) logiciel(s) cible assure les fonctions essentielles mises en évidence.


    • On parle d'évolution de statut (ou d'état) d'objet, lorsque :

    • les droits d'accès à l'objet changent.
    • les façons de faire évoluer les objets (modifier, détruire) évoluent.