Traitement des AFFAIRES

Présentation au sujet: "Traitement des AFFAIRES"— Transcription de la présentation:

1 Traitement des AFFAIRES
Rueil le 10 Octobre 2002

2 AFFAIRES: PROCESSUS CIBLE
P. Connaissance et influence du Marché P. Obtention de la commande P. Traitement de la commande/ Réalisation d ’affaire

3 Pr. CONNAISSANCE DU MARCHE
2 Cibler client, bâtir plan promo 3 Mettre en œuvre plan promo 4 Analyser les projets clients 5 Enrichir les projets clients Piloter les plans action c-iaux

4 Pr. CREATION D ’OFFRE & OBTENTION DE LA COMMANDE
7 Définir la stratégie de réponse 8 Communiquer la stratégie 9 Etablir la solution technique 10 Etablir la proposition commerciale 11 Adapter et négocier la proposition Piloter les réponses aux projets clients

5 7 Définir la stratégie de réponse
Prendre en compte la demande Client PCDC Dossier analyse risque matrice analyse 8 Communiquer la stratégie Outils « SOL »

6 9 Etablir la solution technique
Bien comprendre l ’environnement et le besoin client CDC ? Raisonner par fonction Privilégier les solutions éprouvées Maîtriser l ’évolution des écarts re-formulation besoin client évolution spécification évolution propo fournisseurs Capitaliser les solutions

7 10 Etablir la proposition commerciale
établir le prix de vente…en fonction de: marché, concurrence, coûts de revient, rentabilité Présenter les éléments techniques et commerciaux Rédiger offre en f(besoin client) exemple trames pour CEN pour TGV

8

9 11 Adapter et négocier la proposition
EMPORTER LA DECISION dans LES MEILLEURES CONDITIONS POSSIBLES

10 Pr. TRAITEMENT COMMANDE / REALISATION D ’AFFAIRE
13 Enregistrer,accuser réception, Mettre en place les éléments contractuels 14 Lancer l ’affaire, Valider le budget et le planning 15 Réaliser les études 16 Lancer les appros, consultations et achats 17 Lancer la réalisation des équipements 18 Tester et intégrer en Plateforme 19 Réceptionner en usine 20 Emballer,expédier et facturer 21 Réaliser le chantier et la mise en service 22 Assurer la réception sur site 23 Gérer la garantie, clôturer Piloter l ’affaire planning de réalisation suivi économique suivi contractuel suivi qualité

11 13 Enregistrer,accuser réception, Mettre en place les éléments contractuels
Faire la revue de contrat Réduire les écarts Enregistrer commande engagement budget et Faire l ’AR

12 14 Lancer l ’affaire, Valider le budget et le planning
Valider budget Valider planning

13 15 Réaliser les études METHODOLOGIE de DEVELOPPEMENT Etudier matériels
plans schémas logiciels dossier chantiers Lancer achats suivre réalisation sous-traitants METHODOLOGIE de DEVELOPPEMENT

14 Méthodologies de développement des Systèmes automatisés
Introduction Méthodologie de développement : résultat de l ’expérience acquise par Schneider basée sur les travaux du GIMELEC Ne s ’intéresse qu’à la partie commande Est confrontée quotidiennement aux exigences des utilisateurs Met l ’accent sur les risques / contraintes contractuelles

15 1.Comment définir un système automatisé ?
Description par le but de son emploi : besoins remplis fonctions spécifiques Description par la fourniture qui permet de réaliser de tels objectifs matériels : logiciels de base logiciels d ’application

16 Fournir un système d ’automatisme c ’est :
Engagement pris par un ensemblier-automaticien de fournir : quelque chose qui n ’existe pas pour un prix forfaitaire dans un délai fixé de manière rentable

17 Qu ’attend l ’utilisateur de son fournisseur ?
Fournir un système répondant à des performances nominales ne suffit plus : les exigences se sont complexifiées sous la pression économique et/ou de qualité des consommateurs: Le fournisseur doit apporter des engagements de résultats plus larges : disponibilité des installations : taux de défaillance temps de réparation : taux de défaillance du système L’information de production devient stratégique avec l ’explosion des NTIC : abandon des structures pyramidales (structures CIM) systèmes où l ’information est banalisée et accessible

18 Pour assurer l ’ensemble de ces exigences une démarche a vu le jour :
Démarche qui résulte de la mise en commun des expériences des industriels : constructeurs et intégrateurs d ’une part représentés au sein du GIMELEC prescripteurs et utilisateurs finaux d ’autre part représentés au sein de l ’EXERA

19 Les principes Utilisation d ’une démarche décomposant le projet en phase successives distinguant nettement : Analyse Conception Réalisation Utilisation de logiciels de base permettant de développer les programmes applicatifs de manière : structuré modulaire

20 Le cycle de développement en « V »
Appel d ’offre Spécification du procédé Manuel opératoire Spécification fonctionnelle Recette définitive Conception Préliminaire Recette plate-forme Conception détaillée Tests unitaires Réalisation, codage

21 Le cycle de développement en « V »
Spécification du procédé Manuel opératoire Spécification fonctionnelle Contrat Recette Conception Préliminaire Tests d ’intégration Conception détaillée Tests unitaires Réalisation, codage

22 Pourquoi un cahier des charges fonctionnel ?
C ’est un document essentiel valeur contractuelle  importance du contenu ! Exprimer le besoin utilisateur en termes mesurables , quantifiables Les principales erreurs à ne pas commettre : ne décrire que le mode automatique : pas de description des autres modes de marche pas de quantification des indisponibilités acceptables décrire la solution Des réunions utilisateurs/fournisseurs sont toujours nécessaires une validation des exigences / contraintes du cahier des charges est parfois utile

23 Pourquoi un dossier des spécifications fonctionnelles (1/2) ?
Exprimer en termes techniques les fonctions du cahier des charges . C ’est le document de référence durant tout le cycle du développement sert de base à la recette utilisateur document de référence en cas d ’évolution ultérieure du système il doit être validé par l ’utilisateur C ’est un document contractuel : il devient prépondérant par rapport au cahier des charges terme de paiement Il contient : description des fonctions analyse des fonctions

24 Pourquoi un dossier des spécifications fonctionnelles (2/2) ?
La démarche d ’analyse : menée par le fournisseur participation forte de tous les acteurs : exploitants , maintenance , qualité Utilisation de guides méthodologiques propres à chaque fournisseur Recensement : exhaustif des besoins des contraintes techniques des compétences et savoir-faire de l ’utilisateur des modes de marche des conséquences d ’une indisponibilité d ’une fonction : Préparation du cahier de recette

25 Modifier les spécifications fonctionnelles
Pourquoi des modifications ? Précisions arrivées tardivement / projet Evolutions au sein de l ’entreprise utilisatrice Evaluation des modifications : elles sont coûteuses elles engendrent des risques techniques (faisabilité) elles engendrent des risques sur les délais Elles doivent être prises en compte de manière très formalisée formulaire de demande réponse associée

26 Développement / Codage
C ’est la phase la plus courte du projet elle ne met en œuvre que les ressources du fournisseur Elle repose sur des logiciels de base structurés modulaires gérant automatiquement le dossier de l ’application utilisant des langages normalisés Chaque fonction du dossier des spécifications fonctionnelles est associée à une tâche clairement identifiable dans le dossier Le codage se fait en utilisant le langage le mieux approprié techniquement en fonction des exploitants

27 Exemple de règles de structuration de programmes
Modes de marche : Graphes maîtres gèlent , activent , inactivent des graphes esclaves Un graphe esclave par mode de marche A chaque étape est associée une tâche du dossier de spécification. Le codage des tâches se fait en langage structuré , relais... Les modules de commandes associent : bits image de la commande (positionné par un tâche amont) fonctions de sécurité générales commande des actionneurs  Une seule ligne de commande par actionneur !

28 18 Tester et intégrer en plate forme
Test unitaires Test intégration Ils sont réalisés à partir des fiches de test produites lors de l ’ élaboration du dossier de conception

29 19 Recettes en usine Recette = ensemble des vérifications exécutées sur le système en présence de l ’utilisateur Mesure satisfaction du client Traitement des écarts / ou non conformité PV de recette

30 Quel contenu pour les recettes ?
Très variable selon les utilisateurs : tests exhaustifs : tests unitaires d ’une base de donnée tests par sondage Très variable selon le temps prévu : très forte contrainte de démarrage de production  définition très précise à faire dans le cahier des charges

31 Les clauses contractuelles liées aux recettes
Transfert de risque : date à laquelle le matériel est assuré par l ’utilisateur : souvent à la livraison parfois à la réception définitive Transfert de propriété : date à laquelle l ’utilisateur devient propriétaire du système : à la réception définitive aux paiements à la livraison souvent lié aux paiements des taxes

32 21 Les contraintes de mise en service
Description des modalités : disponibilité des installations disponibilité des exploitants Maîtriser les dérives Délais de mise en service : plus souvent : date de redémarrage des installations  Durée d ’intervention (droit du travail !) Travail en équipe Préparation des équipements avant l ’arrêt  Interventions sans arrêt de production le cas échéant :méthode EVOLUTEL

33 22 Réceptionner sur site Vérification des fonctionnalités du système dans son environnement de production conformité / cahier des charges PV de réception Provisoire durée de fonctionnement probatoire Définitif levée des réserves

34 23 Gérer la garantie Matériel livré :
pièce : garantie classique : 1 an main d œuvre : variable selon le contrat Logiciels de base : conformité du logiciel livré aux caractéristiques techniques livraison de correctifs si « bug » connus et identifiés assistance technique par Hot-line Logiciel d ’application: pas de garantie que le logiciel sera exempt d ’erreur engagement à réparer : délai d ’intervention garantie parfois Limites toujours à préciser : coût , pénalités ...

35 24 Piloter l ’affaire Planning de réalisation Suivi économique
Suivi contractuel Suivi qualité:

36 Quelques références Les projets d ’automatisation
recommandations aux acteurs et intervenants par EXERA et GIMELEC sites :