Traitement des AFFAIRES Rueil le 10 Octobre 2002
AFFAIRES: PROCESSUS CIBLE P. Connaissance et influence du Marché P. Obtention de la commande P. Traitement de la commande/ Réalisation d ’affaire
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
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
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 »
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
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
11 Adapter et négocier la proposition EMPORTER LA DECISION dans LES MEILLEURES CONDITIONS POSSIBLES
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é
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
14 Lancer l ’affaire, Valider le budget et le planning Valider budget Valider planning
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 !
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
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
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
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
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
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
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 ...
24 Piloter l ’affaire Planning de réalisation Suivi économique Suivi contractuel Suivi qualité:
Quelques références Les projets d ’automatisation recommandations aux acteurs et intervenants par EXERA et GIMELEC sites : http://www.exera.com http://www.gimelec.com http:///schneider-electric.fr