ECOLE NATIONALE DES SCIENCES APPLIQUEES TANGER
UNIVERSITE ABDELMALEK ESSAÂDI
PROJET DE FIN D’ETUDES Présenté à l’école pour obtenir le diplôme
D’INGENIEUR D’ÉTAT en Génie Industriel et Logistique Titre
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Réalisé par Mlle. KALIL Oumaima
Encadré par M. Arbaoui Hicham-Encadrant industriel M. Kamach Oualid-Encadrant pédagogique Mme. Sabil Jalila-Encadrante pédagogique
SOUTENU LE 25 Juin 2016
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
2
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
2
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
AVANT- PROPOS Nom et prénom des élèves stagiaires de l’ENSAT : Rami Hassan & Kalil Oumaima
Intitulé du travail : Monitoring et amélioration de la performance des lignes d’assemblage. d’assemblage.
Coordonnées Coordonnées de l’établissement d’accueil : d’accueil : Delphi Packard Tanger, Tanger Free Zone - TFZ, ilot 53, lot 1 - 90000 Tanger Tél : 05 39 398 700 / Fax : 05 39 39 87 09 Site : www.delphi.com
Nom et prénom de l’encadrant du projet dans l’établissement d’accueil : M. Arbaoui Hicham, Manager d’EOS & CI à DPT
Coordonnées Coordonnées de l’école : Ecole Nationale des Sciences Appliquées de Tanger, BP1818, Route Ziaten, Tanger Tél : 05 39 39 37 44 / Fax : 05 39 39 37 43 Site : www.ensat.ac.ma
Nom et prénom des encadrants pédagogique à l’ENSA de Tanger : Mme, Sabil Jalila et M. Kamach Oualid, Professeur de
Date de début et de fin de stage : Du 01/03/2016 Au 24/06/2016
Soutien financier : Stage non rémunéré
3
l’ENSA-Tanger
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
DEDICACE
A nos chers parents, A nos frères et sœurs, A nos familles et tous nos amis.
4
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
REMERCIEMENT C’est avec un grand plaisir que nous réservons ces lignes en gage d’obligeance et de gratitude à tous ceux qui ont contribué à l’élaboration et la réus site de ce travail. Ainsi nous remercions tout le corps professoral et administratif de l’école nationale des sciences appliquées de Tanger qui ont fait de leurs mieux afin de nous offrir une bonne qualité des études.
Mention spéciale pour l’équipe de la filière Génie Industriel et Logistique et de la formation du cycle des études supérieures spécialisées en management des systèmes industriels et logistique. Nos vifs remerciements vont conjointement à M. Hicham Arbaoui, M. Oualid Kamach et Mme, Sabil Jalila pour leur encadrement permanent malgré leurs préoccupations, leurs instructions pertinentes et directives fructueuses tout au long de ce projet. Merci pour tout ! Nous remercions également tous les membres du jury d’avoir accepté d’évaluer la pertinence de notre travail.
Nos vifs remerciements s’adressent aussi à l’ensemble du personnel de l’entreprise Delphi Packard Tanger et spécialement à Grosscheld Michael, Ouadie Belkadi, Yassine Allouch, Rahhali El Mehdi, Achraf Ettazrouti, Hafid Bakkali, Ilham ElKhayati, Abdellah El haskouri
qui n’ont épargné aucun effort pour nous aider et nous fournir toutes les informations nécessaires pour l’aboutissement de ce projet. Nous éprouvons un réel plaisir à remercier nos professeurs M. Noureddine Motaki et M. Abdelfettah Sedqui ainsi que M. Benaissa Amami, enseignant à la Faculté des Sciences et Techniques de Tanger pour leurs orientations avisées et les précieux conseils qui ont fortement
contribué à l’accomplissement de ce travail. Enfin, toute personne nous ayant accordé du temps, donné des conseils, qu’elle trouve ici l’expression de notre sincère respect.
5
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
RESUME Ce rapport présente le travail réalisé dans le cadre de notre projet de fin d’étude qui s’est effectué au sein de l’entreprise Delphi Packard Tanger sur la
période allant du 1 Mars 2016 au
24 Juin 2016 de la même année.
Le travail réalisé s’inscrit dans le cadre de l’amélioration continue ayant pour objectif principal de mettre en place un tableau de bord affichant en temps réel les indicateurs de performance
des lignes d’assemblage. Pour gérer le projet, nous avons déployé la méthodologie Scrum, reposant sur trois itérations incrémentales, de durées courtes, appelées « Sprints ». Ceci, en appliquant une panoplie
d’outils industriels et informatiques à savoir le modèle de développement en cascade, la démarche DMAIC, l’AMDEC, le diagramme des cas d’ utilisation, le vote pondéré, la matrice de décision, le logiciel LabVIEW… etc. Le résultat de notre projet est une application Qlik sense affichant en temps réel un ensemble
d’indicateurs, permettant ainsi le monitoring de la performance, l’amélioration du système de reporting existant, et par conséquent, l’accélération de la prise de décision et la résolution de s problèmes.
Mots clés : Tableau de bord, Temps réel, indicateur de performance, Scrum, Sprint, modèle en cascade, DMAIC, Labview, Qlik sens e, reporting, prise de décision… etc.
6
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
TABLE DES MATIERES AVANT- PROPOS .................................................................................................................... 3 DEDICACE................................................................................................................................ 4 REMERCIEMENT .................................................................................................................... 5 RESUME.................................................................................................................................... 6 LISTE DES FIGURES ............................................................................................................. 10 LISTE DES TABLEAUX ........................................................................................................ 12 TERMINOLOGIE.................................................................................................................... 13 INTRODUCTION GENERALE.............................................................................................. 14 Chapitre 1 : Cadre général du projet ........................................................................................ 15 I.
Introduction ................................................................................................................... 16
II.
Présentation de l’organisme d’accueil ....................................................................... 16
1.
Présentation de Delphi au niveau mondial ................................................................ 16
2.
Présentation de Delphi Packard Tanger..................................................................... 17
III.
Présentation du cahier des charges ............................................................................ 20
1.
Contexte pédagogique ............................................................................................... 20
2.
Acteurs du projet ....................................................................................................... 20
3.
Problématique ............................................................................................................ 21
4.
Expression du besoin ................................................................................................. 21
5.
Objectif et attentes ..................................................................................................... 23
IV.
Management du projet ............................................................................................... 24
1.
Planification ............................................................................................................... 24
2.
Conduite du projet ..................................................................................................... 25
3.
Méthodologie de travail ............................................................................................. 25
4.
Outils informatiques utilisés ...................................................................................... 29
V.
Conclusion..................................................................................................................... 30
Chapitre 2 : Etude préalable ..................................................................................................... 31 I.
Introduction ................................................................................................................... 32
II.
Analyse de l’existant ................................................................................................. 32
III.
Choix de la chaine pilote ........................................................................................... 34
IV.
Définition du groupe de travail .................................................................................. 36
V.
Analyse des risques du projet .................................................................................... 38
VI.
Backlog de produit..................................................................................................... 40
1.
Enquête par questionnaire ......................................................................................... 40 7
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
2.
Hiérarchisation des indicateurs de performance selon leur importance .................... 43
3.
Sélection des indicateurs de performance par ordre de priorité ................................ 44
4.
Backlog de tableau de bord ....................................................................................... 45
VII.
Documentation des indicateurs .................................................................................. 46
VIII.
Conclusion ............................................................................................................. 46
Chapitre 3 : Déroulement du SPRINT 1 .................................................................................. 47 I.
Introduction ................................................................................................................... 48
II.
Planification ............................................................................................................... 48
III.
Analyse des besoins ................................................................................................... 51
1.
Capture des besoins ................................................................................................... 51
2.
Diagramme des cas d’utilisation. ............................................................................... 52
3.
Analyse des cas d’utilisation ..................................................................................... 54
IV.
Conception ................................................................................................................. 55
1.
Architecture technique ............................................................................................... 55
2.
Eléments constitutifs du tableau de bord ................................................................... 55
V.
Codage et déploiement .............................................................................................. 57
1.
Modification de la base de données ........................................................................... 57
2.
Chargement des données ........................................................................................... 57
3.
Modélisation des données .......................................................................................... 60
VI.
Revue et rétrospective du premier Sprint .................................................................. 65
1.
Revue de Sprint ......................................................................................................... 65
2.
Rétrospective de Sprint .............................................................................................. 65
VII.
Conclusion ................................................................................................................. 65
Chapitre 4 : déroulement des Sprints 2 et 3 ............................................................................. 66 I.
Introduction ................................................................................................................... 67
II.
Définir ........................................................................................................................ 67
1.
Planification des Sprints ............................................................................................ 67
2.
Mêlée quotidienne ..................................................................................................... 69
3.
Graphique d’avancement ........................................................................................... 69
III.
Mesurer et Analyser ................................................................................................... 69
1.
Temps d’arrêt d’assemblage ...................................................................................... 69
2.
La réparation .............................................................................................................. 70
3.
Le temps de première qualité (FTQ) ......................................................................... 70
4.
Le temps de cycle ...................................................................................................... 71
IV.
Innover ....................................................................................................................... 71 8
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
1.
Suivi du temps d’arrêt d’assemblage ......................................................................... 71
2.
Suivi de la réparation ................................................................................................. 72
3.
Suivi du temps de première qualité ........................................................................... 73
4.
Suivi du temps de cycle ............................................................................................. 75
V.
Contrôler .................................................................................................................... 75
VI.
Bilan........................................................................................................................... 76
1.
Bilan de gains ............................................................................................................ 76
9
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
LISTE DES FIGURES Figure 1: Siège de Delphi (Michigan) aux Etats-Unis ............................................................. 16 Figure 2 : Organigramme de DPT ............................................................................................ 18 Figure 3 : Exemple de faisceaux électrique pour voiture ......................................................... 19 Figure 4 : Processus de production au sein de DPT ................................................................. 19 Figure 5 : Expression du besoin ............................................................................................... 22 Figure 6 : Diagramme de GANTT réel .................................................................................... 24 Figure 7 : Vue globale du cadre SCRUM ................................................................................ 26 Figure 8 : Flux d'information existant de DPT......................................................................... 33
Figure 9 : Analyse d’écart Par projet ........................................................................................ 35 Figure 10 : Analyse d'écart par famille .................................................................................... 36 Figure 11 : Résultat du vote pondéré ....................................................................................... 44 Figure 12 : Matrice de décision ................................................................................................ 45 Figure 13 : Planning du premier Sprint .................................................................................... 48 Figure 14 : Planning du premier Sprint .................................................................................... 48 Figure 15 : Photo du tableau Scrum ......................................................................................... 50 Figure 16 : Diagramme des cas d'utilisation ............................................................................ 53 Figure 17 : Architecture technique du tableau de bord ............................................................ 55 Figure 18 : éléments constitutifs du tableau de bord ................................................................ 55 Figure 19 : Partie du Script de chargement de données ........................................................... 58 Figure 20 : Modèle de données du tableau de bord.................................................................. 58 Figure 21 : Aperçu de la dimension hiérarchique créée ........................................................... 61 Figure 22 : Filtre projet ............................................................................................................ 61 Figure 23 : Affichage du nombre de faisceaux testés et emballés ........................................... 62 Figure 24 : Affichage de l'efficience ........................................................................................ 63 Figure 25 : Affichage de l'effectif ............................................................................................ 63 Figure 26 : Présentation des indicateurs par shift .................................................................... 64 Figure 27 : Aperçus de l'interface du tableau de bord .............................................................. 64 Figure 28 : Planning de Sprint 2............................................................................................... 67 Figure 29 : Planification de Sprint 3 ........................................................................................ 68
Figure 30 : La face avant de l’application calculant le temps d’arrêt ...................................... 71 Figure 31 : Message affiché après le scan d'un manifest déjà scanné ...................................... 73 10
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Figure 32 : Interface de l’application du test électrique avant et après le test d’un faisceau réparé .................................................................................................................................................. 73 Figure 33 : Interface de sélection des défauts .......................................................................... 74 Figure 34 : Incrémentation du nombre de défauts par shift ..................................................... 74 Figure 35 : Expression de calcul du temps de cycle de shift 1 ................................................. 75 Figure 36 : Affichage du temps de cycle par shift ................................................................... 75
11
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
LISTE DES TABLEAUX Tableau 1: Fiche Technique de DPT ........................................................................................ 17 Tableau 2 : Application de la méthode SMART ...................................................................... 23 Tableau 3 : Equipe Scrum ........................................................................................................ 37 Tableau 4 : Grille de notation d'AMDEC projet ...................................................................... 38 Tableau 5 : Evaluation de la criticité des risques projet ........................................................... 38 Tableau 6 : AMDEC projet ...................................................................................................... 39 Tableau 7 : Criticité des risques après la prise en compte des solutions .................................. 40 Tableau 8 : Indicateurs concernés selon le QVC ..................................................................... 41 Tableau 9 : Echantillon de l'enquête ........................................................................................ 42 Tableau 10 : Tableau du vote pondéré ..................................................................................... 43 Tableau 11 : Backlog de produit .............................................................................................. 45 Tableau 12 : Backlog du premier Sprint .................................................................................. 49 Tableau 13: Fiche des cas d'utilisation ..................................................................................... 54 Tableau 14 : Descriptif du modèle de données ........................................................................ 59 Tableau 15 : Backlog de Sprint 2 ............................................................................................. 68 Tableau 16 : Backlog de Sprint 3 ............................................................................................. 68
12
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
TERMINOLOGIE
EN COURS DE REDACTION
13
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
INTRODUCTION GENERALE Dans un environnement marqué par la mondialisation, l’évolution et la concurrence, piloter son entreprise efficacement est devenu indispensable à la pérennité d’une structure. Or un pilotage efficace impose une grande réactivité et par conséquent une information de gestion standardisée, pertinente et disponible qui permettrait une prise de décision appropriée en temps opportun. Dans cette optique que Delphi Packard Tanger, spécialisée dans la fabrication des faisceaux
électriques pour l’industrie automobile, s’est engagée dans une démarche d’amélioration continue, visant à mettre en place des processus simples, fiables, acc essibles à tous et hautement
automatisés pour permettre aux responsables de consacrer tout leur temps à l’analyse, à l’interprétation des résultats et à la résolution des problèmes pour améliorer la performance de l’entreprise. Notre projet de fin d’études s’inscrit dans cet objectif : Monitoring et amélioration de la performance des lignes d’assemblage à travers la mise en place d’un tab leau de bord de gestion plus adapté. Dans le souci de mieux répondre aux attentes des responsables en un temps limité, nous allons dans le cadre de ce travail appliquer une méthode agile : SCRUM, qui s’appuie sur le découpage du projet en itérations encore nommées « Sprints ».
Le présent rapport résumera l’ensemble du travail réalisé tout au long du projet, il se compose de quatre chapitres Pour présenter ce projet, nous avons développé le travail en quatre chapitres : le premier chapitre présente le cadre
générale du projet, c’est là où nous présentons de près l’entreprise
Delphi Packard Tanger, le cahier des charges ainsi que le management de notre projet. Dans le
second chapitre nous présentons une étude préalable effectuée pour analyser l’existant, choi sir la chaine pilote, définir le groupe de travail, analyser les risques et déterminer les fonctionnalités attendues du tableau de bord. Nous développons dans le troisième et quatrième chapitre le déroulement des Sprints, exécutés, respectivement, suivant le modèle de développement en cascade et la démarche DMAIC. Nous dédions également la dernière partie du quatrième chapitre à une synthèse globale du projet avec soulignement des gains escomptés derrière ce projet, du bilan personnel, des contraintes rencontrées et des perspectives du projet. Nous terminons le rapport par une conclusion générale. 14
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Chapitre 1 : Cadre général du projet
15
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
I.
Introduction
Dans ce présent chapitre, nous commençons par présenter la socié té Delphi, son organigramme, les services consultés et concernés par notre projet ainsi que son processus d e production. Nous exposons par la suite le cahier des charges qui comporte la problématique, le besoin exprimé en utilisant le diagramme « bête à cornes
», et l’objectif formulé avec la méthode
SMART. La dernière partie concerne le management de notre projet, ou nous présentons le planning réel, des estimations concernant la conduite du projet ainsi que la méthodologie de travail, les démarches suivies et les outils informatiques utilisés.
II.
Présentation de l’organisme d’accueil
1. Présentation de Delphi au niveau mondial 1.1.
Groupe Delphi
Delphi est un groupe multinational américain, créé en 1888. Actuellement, la société est l'un des fabricants d'équipements les plus modernes dans le monde, travaillant essentiellement dans le domaine automobile et l'industrie du transport, et dont la clientèle s'étend de plus en plus vers des secteurs de haute technologie comme les télécommunications,
le
matériel
médical, Figure 1: Siège de Delphi (Michigan) aux Etats-Unis
l'informatique et ses périphériques.
Son siège se situe dans la ville de Troy (Michigan) aux Etats-Unis, il est issue d'une filiation de General Motors et fournisseurs de plus de 30 marques de voitures, emploie plus de 205 700
personnes à travers le monde (USA, Canada, Asie Pacifique, Mexique, Portugal, Suède,…), et compte 190 sites de production, 43 joint-ventures, 51 centres client et bureaux de vente, et 32 centres techniques dans 37 pays.
1.2.
Divisions du groupe
Chez Delphi, on distingue six divisions dont chacune opère dans un domaine d’activités en offrant une diversité de produits. Ces divisions sont le résultat du regroupement de sociétés plus petites, dont la création remonte à plus d'un siècle et qui n'ont cessé d'évoluer. 16
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Les différentes divisions de DELPHI sont :
Delphi Packard Electric : qui produit les faisceaux électriques (câblage pour voiture).
Delphi Thermal & Interior
Delphi Product & Service Solutions
Delphi Energy & Chassis
Delphi Steering.
Delphi Electronics & Safety
1.3.
Delphi Maroc
Le groupe Delphi dispose de quatre usines au Maroc :
Delphi Automotive Systems Maroc (DASM), implantée à Tanger en 1999.
Delphi Packard Tanger (DPT), Où on a effectué notre stage, installée en 2008 à la zone franche de Tanger.
Delphi Packard Kenitra (DPK), démarrée à Atlantic Free Zone de Kenitra en 2013.
Delphi Packard Meknès (DPM), verra le jour à la fin de 2016.
2. Présentation de Delphi Packard Tanger 2.1.
Fiche technique
Le tableau ci-dessous présente la carte d’identité
Raison social Nationalité Forme juridique Siège social Superficie Secteur d’activité Effectif actuel Produit Directeur général Début de la production Capital Téléphone Fax Site web
de DPT Résumant toutes ses caractéristiques.
Delphi Packard Tanger – DPT Multinationale américaine, Warren, Ohio à Etats-Unis Société anonyme – SA Ilot 53, lot n° 1, Tanger Free Zone 60.000 m² Industrie Automobile 3000
Faisceaux électriques pour l’industrie automobile Khalid Andaloussi Août 2008 12.500.000 millions euros 05.39.39.87.00 05.39.39.87.09 www.delphi.com Tableau 1: Fiche Technique de DPT
Delphi est certifié ISO 9001, ISO 14001 et ISO TS 16949. 17
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
2.2.
Organigramme et services concernées
L’organigramme, présenté sur la figure 4, illustre l’organisation des différents départements de l’usine DPT.
Figure 2 : Organigramme de DPT
Le personnel de Delphi Packard Tanger est composé du directeur général de l’usine et des managers de départements. Chaque département possède ses propres coordinateurs, ingénieurs et opérateurs. On est affecté officiellement dans la période de stage à la direction générale sous l’encadrement
de M. Hicham Arbaoui, Le manager d’EOS & CI dont la mission principale est de travailler en transversalité avec tout le staff de l’usine et avec les différentes p arties prenantes qui assurent les fonctions externalisées, son rôle est de garantir les missions des EOS à travers des OSA et le suivi des projets 6sigma, MCIP, et IMCIP. Cependant, les missions qui nous ont été confiées concernaient aussi les services, qualité, IT, production, maintenance, logistique, ingénierie avec lesquels nous avons travaillé aussi.
18
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
2.3.
Produit et Clients
DPT est spécialisée dans la fabrication de faisceaux électriques pour voitures (voir figure 2). Ces faisceaux sont les premiers composants qui se fixent sur la carrosserie et dont le rôle est d'alimenter électriquement tous les composants et les options de la voiture. Ses clients sont parmi les grands constructeurs automobiles : FORD, PSA et BMW.
2.4.
Figure 3 : Exemple de faisceaux électrique pour voiture
Processus de production
La production des faisceaux électriques passe par plusieurs étapes, donc par plusieurs zones de production : Magasin des matières premières, la zone de coupe et préparation, la zone
d’Assemblage, et finalement le Magasin des produits finis ( voir figure 3).
Figure 4 : Processus de production au sein de DPT
La matière première provenant du fournisseur passe par le laboratoire de contrôle de qualité pour subir
un contrôle de réception à partir d’un plan et d’une fiche d’inspection avant d’être
stockée dans le magasin de matière première avec un DPN. Le stock quotidien passe à la zone de coupe et de préparation. Dans cette zone, En trouve des presses automatiques pour effectuer les opérations de coupe, dénudation et sertissage. 19
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
A ce niveau, les conducteurs sont préparés pour passer à la zone d’assemblage. L’assemblage se fait soit sur des tableaux fixes pour les câbles de petites dimensions, soit sur des tableaux roulants avec un temps de cycle bien définit. Ceci se fait en conformité avec l es schémas fournis
par l’ingénierie. Les chaines de montage sont subdivisées en plusieurs familles en fonction du câble final produit par cette chaine, on distingue plusieurs câbles : Câblage principal (Main, Floor), Câblage moteur (Engine), Câblage sol (Body), Câblage porte (Door), Câblage toit (Roof) et Câblage tableau de bord (IP). Ces faisceaux passent ensuite par un test électrique, où on vérifie la continuité électrique entre les différents extrémités du circuit, et la présence des éléments secondaires (sécurité des
connecteurs, passe fil,…). De là, les faisceaux subissent un autre contrôle qui est celui de contention, au cours duquel les différentes côtes et les points à marquer sont vérifiés, avant la
phase d’emballage et livraison client.
III. Présentation du cahier des charges 1. Contexte pédagogique Ce projet s’inscrit dans le cadre des projets de fin d’études de la formation du cycle des études supérieurs spécialisés et de la formation d’ingénieur d’état à l’ENSA de TANGER.
2. Acteurs du projet Maitre d’œuvre : Le maitre d’œuvre est l’Ecole Nationale des Sciences Appliquées de
Tanger, représentée par : -
M. Rami Hassan, étudiant en troisième année cycle des études supérieures spécialisées en management des systèmes industriels et logistique.
-
Mlle. Kalil Oumaima, étudiante en troisième année cycle ingénieur, filière génie industriel et logistique.
Maitre d’ouvrage : Le maitre d’ouvrage est la société Delphi Packard Tanger.
Tuteurs pédagogiques : -
Mme, Sabil Jalila et M. Kamach Oualid, Enseignants
à l’ENSA de Tanger.
Tuteur technique : M. Arbaoui Hicham, Manager d’EOS & CI.
20
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
3. Problématique La problématique à laquelle répond notre projet concerne le système de reporting interne de Delphi Packard Tanger.
Autrement dit, nous allons se focaliser sur l’opération de la communication des données de l’activité de production, destinée à en informer ceux chargé de la supervision des résultats et la résolution des problèmes. Au sein de DPT, Les enregistrements des différents indicateurs de
la zone d’assemblage sont
remplis manuellement à la fin de chaque shift dans les cartes de production par les contremaîtres. Ces enregistrements manuels sont déposés par la suite au département production. Le lendemain à 6h du matin, deux agents de saisie collectent les cartes de production, les classent par ordre pour faciliter leur saisie, corrigent les erreurs et l’écriture qui n’est pas claire puis saisissent les données dans un fichier Excel.
La vérification est nécessaire avant d’envoyer les documents à l’assistante du département qui, à son tour, valide les résultats avec les coordinateurs. Enfin le rapport de production du jour-1 est envoyé aux responsables des départements à 10h. Après la réception des résultats, il est indispensable de préparer un autre fichier Excel dont le format dépond de chacun, pour comparer avec les objectifs et visualiser les écarts sous format de graphes. Ce travail nécessite 15 minutes du temps de chaque responsable. En analysant ce processus, les problèmes suivants sont remarquables :
Retard dans la communication des résultats de la production.
Concentration sur des taches secondaires par rapports aux autres prioritaires.
Possibilité de communiquer aux dirigeants des données non fiables et erronées.
Gaspillage des papiers pour l’impression des cartes de production.
Déplacements inutiles des contremaitres.
Manque d’un format standard pour la visuali sation des données.
Retard dans la résolution des problèmes.
4. Expression du besoin En vue d’exprimer la finalité et le besoin derrière la réalisation de notre projet, on l’a schématisé en utilisant le diagramme « Bête à cornes » ou le « Schéma du besoin » (Voir figure 5). 21
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Figure 5 : Expression du besoin
-
Contrôle de validité du besoin
Pourquoi le besoin existe-t-il ?
Parce qu’il y a
un retard dans la prise de décision et la résolution des problèmes concernant les
lignes d’assemblage . -
Pour quoi le besoin existe-t-il ?
Pour mesurer les indicateurs de performance en temps réel comparés aux objectifs, chose qui va améliorer le système de Reporting existant et qui va accélérer la prise de décision et la résolution des problèmes. -
Qu’est ce qui pourrait faire évoluer ou disparaitre le besoin ?
La mise en place d’un Système d’exécution des fabrications (MES), fournissant un tabl eau de bord de pilotage de production. Le besoin est donc validé. 22
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
5. Objectif et attentes Afin de répondre correctement à la problématique posée par le cahier des charges, il s’est avéré nécessaire de mesurer en temps réel la performance des lignes d’assemblage.
En effet, le monitoring de la performance est un processus destiné à surveiller d’une manière continue le déroulement des activités planifiées afin de s’assurer de l’atteinte des objectifs fixés des programmes. Le but principal du monitoring de la performance est de suivre les changements des indicateurs afin de générer de bons résultats à maintenir voire renforcer. Pour obtenir ce système, la solution adoptée et qui sera le livrable de notre projet est un tableau de bord mesurant la performance des lignes d’assemblage en temps réel, la comparant avec les objectifs et sollicitant ainsi la réaction rapide des responsables pour corriger les écarts. Les responsables visés sont
: le directeur d’usine ainsi que les managers et coordinateurs des
départements : production, logistique, qualité, ingénierie, coupe & préparation, Process et maintenance.
Cet outil va jouer le rôle d’assistance et d’anticipation. C'est aussi un moyen de motivation des collaborateurs pour faire mieux puisque tout ce qui est mesurable peut être amélioré, en particulier lorsque l’information pour la prise de décision est formulé, disponible et exploitable rapidement. En outre, la formulation claire de
l’objectif du stage est une étape importante à leur atteinte.
Pour cela, nous avons utilisé la méthode SMART résumée sur le tableau 2 ci-dessous. Mettre en place un tableau de bord affichant en temps réel les indicateurs de
Enoncé de performance des lignes d’assemblage sur les ordinateurs des responsables d’ici l’objectif le 24 juin. Spécifique
En lisant l’énoncé, il est clair qu’il faut réaliser un tableau de bord rassemblant les indicateurs de performance des lignes d’assemblage et l’afficher sur les ordinateurs des responsables.
Nous mesurerons l’atteinte de l’objectif par l’élaboration d’un tableau de bord Mesurable répondant aux besoins des utilisateurs.
Atteignable Nous appliquerons une méthodologie pour faciliter la réalisation de l’objectif. Réaliste Temporel
L’objectif s’accomplira par une équipe de travail, en utilisant des outils et logiciels bien déterminés.
A la fin de la période de 4 mois, on va pouvoir affirmer si l’objectif a été atteint. Tableau 2 : Application de la méthode SMART
23
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
IV.
Management du projet
1. Planification Pour atteindre l’objectif fixé, l a planification du projet dans le temps est une étape indispensable. Afin d’affecter une durée à chaque tâche, visualiser d'un seul coup d'œil le retard ou l'avancement des travaux et de respecter le délai prédéterminé à la livraison du travail final, nous avons réalisé un planning du projet sous forme d’un diagramme de GANTT en utilisant le logiciel de gestion de projet : GANTT PROJECT. La figure 6 ci-dessous illustre le déroulement réel de notre projet. Afin de ne pas surcharger notre lecteur, nous aborderons les détails du planning le moment venu dans les chapitres qui suivent.
Figure 6 : Diagramme de GANTT réel
Vous trouverez en Annexe 1 le diagramme de GANTT prévisionnel. 24
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
A noter que la rédaction du présent rapport a débuté juste après
l’élaboration du cahier des
charges et s’est déroulé en parallèle avec les autres taches pour être sûr de ne pas oublier d’éléments indispensables.
2. Conduite du projet Nous présentons ci-dessous des précisions liées à la conduite de notre projet :
Le nombre de réunions effectuées entre nous dans le cadre de la méthodologie suivie est estimé à 53 réunions dont chacune a durée 15 minutes.
Le nombre de conférences téléphoniques effectuées avec le développeur du système
d’étiquetage de Delphi est estimé à 48 t éléconférences dont chacune a sa propre durée qui varie généralement entre 1 et 2 heures.
Le nombre de réunions effectuées avec les membres de l’équipe est à peu près 30 réunions dont la durée de chacune varie entre 30 et 60 minutes.
15 présentations d’état d’avancement ont été réalisées pour suivre l’avancement du projet avec les encadrants.
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
A noter que la rédaction du présent rapport a débuté juste après
l’élaboration du cahier des
charges et s’est déroulé en parallèle avec les autres taches pour être sûr de ne pas oublier d’éléments indispensables.
2. Conduite du projet Nous présentons ci-dessous des précisions liées à la conduite de notre projet :
Le nombre de réunions effectuées entre nous dans le cadre de la méthodologie suivie est estimé à 53 réunions dont chacune a durée 15 minutes.
Le nombre de conférences téléphoniques effectuées avec le développeur du système
d’étiquetage de Delphi est estimé à 48 t éléconférences dont chacune a sa propre durée qui varie généralement entre 1 et 2 heures.
Le nombre de réunions effectuées avec les membres de l’équipe est à peu près 30 réunions dont la durée de chacune varie entre 30 et 60 minutes.
15 présentations d’état d’avancement ont été réalisées pour suivre l’avancement du projet avec les encadrants.
Le nombre de visites du terrain est estimé à 35 visites dont l’une s’est déroulée avec la présence de M. Kamach Oualid d’une durée de 2 heures et une autre , de la même durée, avec M. Arbaoui Hicham.
3. Méthodologie de travail 3.1.
SCRUM
Le développement traditionnel fait de groupes monofonctionnels, de boucles de feedback
limités et tardives, de plannings préétablis et prédictifs, et d’un flux séquentiel de l’analyse jusqu’aux tests, chose qui n’est pas vraiment efficace pour la gestion de notre projet . Cette approche retarde le feedback, l’apprentissage, ainsi que le retour sur investissement potentiel car elle ne délivre le logiciel opérationnel qu’en fin de la dernière étape, occasionnant durant les phases un manque de transparence, un
manque de capacité d’amélioration, une diminution
de la flexibilité, et une augmentation des risques métiers et techniques. Afin de réduire considérablement voire complétement ces risques, on a choisi SCRUM, proposé par nos encadrants, un cadre de travail pour développer notre tableau de bord de manière
itérative et incrémentale, par des équipes responsabilisées avec l’objectif de répondre, dans un délai contraint, aux besoins – qui peuvent changer- des utilisateurs, tout en produisant une application de grande qualité. 25
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
SCRUM est une méthode agile, se composant de plusieurs éléments. Chaque élément a une
raison d’être spécifique qui le rend indispensable à la réussite de l’application de SCR UM. La figure 7 ci-dessous donne une vue d'ensemble des éléments principaux de SCRUM avec leurs interactions.
Figure 7 : Vue globale du cadre SCRUM
Passant ce schéma en revue en commençant par la gauche et en progressant vers la droite.
Le propriétaire de produit détient la vision de ce qu’il veut voir produire. Le projet est décomposé en plusieurs blocs fonctionnels qui sont placés par priorités décroissantes dans la liste appelée le Backlog de produit.
La production d’un gro upe de blocs fonctionnels correspond à une itération appelée Sprint qui englobe toute la séquence de développement avec une durée limitée à un mois calendaire. Dans
le schéma, le Sprint correspond à la grande boucle. Puisque le nombre d’éléments dans le Backlog
du produit est en général bien supérieur à ce qu’il est possible de produire dans un
cycle de Sprint, l’équipe de développement doit sélectionner dans le Backlog de produit au début de chaque Sprint un sous ensemble d’objectifs appelé Backlog de Spri nt. Cela correspond à l’activité de planification de Sprint. Elle est montrée du côté gauche, juste à droite de la liste du Backlog de produit.
26
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Pendant l’exécution de Sprint, une réunion quotidienne, appelée Mêlée quotidienne, permet aux membres de l’équip e de garder le contrôle du flux de taches, elle sert à synchroniser, inspecter et faire une planification adaptative.
En fin d’exécution de Sprint, l’équipe doit avoir abouti à un incrément fonctionnel livrable du produit qui incorpore une portion de la vision définie par le propriétaire du produit.
L’équipe Scrum clôture le Sprint par deux activités successives d’inspection et d’adaptation. La première est la revue de Sprint. Elle réunit l’équipe Scrum pour inspecter le produit résultant du Sprint. La sec onde réunion est le rétrospective de Sprint. Elle s’intéresse au processus adopté pour réaliser le produit. Les conclusions de ces activités peuvent dégager des besoins
d’adaptation qui pourront se propager jusqu’au Backlog de produit ou être incorporées d ans le processus de développement standard de l’équipe. Après ces deux réunions, le cycle de Sprint est fini pour qu’un autre commence. L’équipe de développement sélectionne les prochains éléments prioritaires du Backlog de produit pouvant être réalisés.
Au bout d’un certain nombre de Sprints, la vision définie par le prioritaire du
produit est concrétisée et la solution complète peut être diffusée.
Le Scrum Master est responsable de la compréhension, de l’adhésion et de la mise en œuvre de la méthode, il assiste chaque rôle de l’équipe Scrum dans son
activité dans le but de maximiser
le rendement des membres. Notre projet était divisé en trois Sprints dont chacune a ses propres objectifs, chose qui a
nécessité de combiner Scrum avec d’autres démarches présentées ci-après.
3.2.
Modèle de développement en cascade
Le premier Sprint a concerné le développement d’un tableau de bord affichant des indicateurs disponibles dans le système d’information existant de DPT, pour cela, on a suit le modèle en cascade pour le réaliser.
Ce modèle considère le développement logiciel comme une succession d’étapes réalisées de façon strictement séquentielle que voici :
Analyse des Besoins
: l’expression, le recueil et la formalisation des besoins des
utilisateurs.
Conception : il
s’agit de l’élaboration des spécifications de l’architecture technique de
l’application ainsi que la définition de ses sous -ensembles.
Codage : Réalisation des fonctionnalités définies. 27
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Test d’intégration : les différents sous-ensembles de l’application sont mis ensemble pour former le tableau de bord complet et vérifier ainsi les interactions entre les sousensembles.
Déploiement
: loin d’être la dernière étape de l’installation de l’ap plication, le
déploiement est la mise à disposition de l’outil et son utilisation.
3.3.
DMAIC
Au niveau des deuxième et troisième Sprints, on a traité des indicateurs non disponibles dans
le système d’information existant de DPT, alors il était nécessaire de t rouver des solutions pour améliorer ce dernier et le
rendre capable d’acquérir de nouveaux indicateurs.
A ce stade, on a décidé d’adopter la démarche DMAIC de résolution des problèmes, structurée en 5 étapes. Chacune des lettres composant le sigle D.M.A.I. C.
est l’initiale de la fonction
significative de l’étape correspondante :
Définir les objectifs et les attentes des utilisateurs.
Mesurer l’ampleur du problème grâce à des
Analyser les données obtenues lors de
Innover par l’implémentation des solutions et options permettant de combler les attentes
outils de mesure.
l’étape précédente.
des utilisateurs.
Contrôler et vérifier que le travail accompli fonctionne et les solutions mise en place sont efficaces.
3.4.
Outils industriels
Durant ce projet, nous avons fait appel à plusieurs outils industriels, à savoir :
Le diagramme « Bête à corne »
SMART
AMDEC
Le vote pondéré
La matrice de décision
Le diagramme des cas d’utilisation
Brainstorming
Questionnaire…
Ces outils seront abordés le moment venu dans les chapitres concernés.
28
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
4. Outils informatiques utilisés 4.1.
Qlik Sense Entreprise
Qlik Sense Entreprise est une application Windows, proposée par le développeur faisant partie de notre équipe, pour
créer facilement notre tableau de bord d’une manière personnalisé e et
dynamique sans nécessité de connaitre de Script. Qlik Sense permet de combiner de multiples sources de données sécurisées et cohérentes pour créer des analyses visuelles et des applications simples et sophistiquées par simple glisserdéposer. Il est caractérisé par une conception souple permettant aux utilisateurs de partager les informations, communiquer plus efficacement et travailler en collaboration.
Les responsables de DPT ont remarqué que l’utilisation des fichiers Excel induit des défaillances au niveau de la gestion des données :
Traçabilité non assurée sur la provenance des données, celles-ci pouvant être issues
d’autres sources non identifiées ou bien saisies en local par l’utilisateur.
Fiabilité incertaine sur le mode de calcul des données agrégées liée à la multiplicité des
macros dont le contenu n’est pas toujours documenté.
Restrictions sur la taille des fichiers, ce qui pose problème quand la volumétrie des
données ne fait que s’accroitre. Pour toutes ces raisons et bien d’autres, nous avons utilisé Qlik sense, outre que Excel, caractérisé par :
Des visualisations en mode « glisser-déposer » pour révéler des informations cachées.
Une recherche intelligente, activée en tapant simplement des mots clés, révèle les associations entre les données et affiche les informations concernées.
Une exploitation de multiples sources de données depuis une seule applicati on.
Un accès aux analyses partout, tout le temps, depuis n’importe quel périphérique mobile.
A noter que parmi les critères de choix de ce logiciel est le fait que Delphi au niveau mondial dispose de sa licence. Son utilisation a nécessité un ordinateur se connectant au réseau interne de Delphi Packard Tanger.
Pour cela, il s’es t avéré nécessaire de demander son installation auprès du service Qlik Sense. Ce dernier offre des options d’assistance et de consultation 24h/24.
29
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
4.2.
LabVIEW
LabVIEW (Laboratory Virtual Instrument Engineering Workbench) est un environnement de développement graphique. Comparativement aux langages textuels, il offre la même puissance de programmation, mais sans le côté abstrait et complexe lié à la syntaxe. Orienté tests et mesures, il dispose de nombreuses fonctions permettant de piloter facilement
des cartes d’acquisition et autres instruments, mais aussi d’ana lyser et présenter les données. Nous avons utilisé ce logiciel pour tester et simuler une application calculant le temps d’arrêt. L’application réalisée avec labVIEW est appelée VI (pour Virtual Instrument). Un VI est composé de deux composantes principales :
Face-avant : sert d’interface utilisateur.
Diagramme : Contient le code source graphique qui définit les f onctionnalités du VI.
4.3.
PowerDesigner
PowerDesigner est une puissante solution de modélisation des systèmes d’informations. Cet ensemble d’outils supporte plusieurs techniques de modélisation standard comme la modélisation Merise. Ce logiciel a été utilisé afin
de réaliser le diagramme des cas d’utilisation.
A noter que nous avons utilisé le diagramme des cas d’utilisation pour recueillir, analyser et organiser les besoins des utilisateurs.
4.4.
SmartDraw
SmartDraw permet de dessiner des organigrammes, des schémas techniques, des diagrammes
d’organisation… Ce logiciel a servi pour réaliser l’architecture technique de notre application.
V. Conclusion Dans ce premier chapitre, nous avons présenté le cadre général du projet.
En effet, nous avons donné une brève présentation de l’organisme d’accueil DPT au niveau mondial ainsi qu’au niveau national. Ensuite nous avons détaillé le contenu du cahier des charges, tout en citant la problématique, le
besoin et l’objectif. Finalement, nous avons traité la partie management de notre projet incluant le planning, la conduite du projet ainsi que la méthodologie suivie et les outils informatiques utilisés. 30
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Chapitre 2 : Etude préalable
31
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
I.
Introduction
Ce deuxième chapitre commence par une analyse de la situation actuelle dont le but est l’étude du flux informationnel existant, son diagnostic, et
l’ébauche de solution.
Ensuite, il présente le déroulement du choix de la chaine pilote, la définition du groupe de travail ainsi que la démarche utilisée pour analyser les risques du projet. Enfin, ce chapitre présente la première étape dans SCRUM qui consiste à élaborer le Backlog du produit, une liste ordonnée de tous ce qui doit être requis dans le futur tableau de bord, les
techniques utilisées ainsi qu’une documentation sur les indicateurs concernés par notr e projet.
II.
Analyse de l’existant
ALS, signifie Assembly Labeling System,
est un système d’étiquetage qui a été implémenté en
2011 au sein de DPT afin d’assurer la traçabilité des faisceaux électriques. Ce système utilise une base de données, nommée ALS Database pour stocker les données. La figure 8, de la page suivante, représente un schéma des différentes communications entre la
base de données du système ALS et les autres systèmes d’information. Nous présentant cidessous des spécifications nécessaires pour la compréhension de ce schéma :
ALS Database est un système de gestion de base de données Oracle version 9i. Il assure la sauvegarde, la restauration et la manipulation des données.
Oracle forms est un outil de développement d’Oracle permettant d’automatiser la création d’applications s’interfaçant avec la base de données sans connaissances préalables du langage SQL.
Oracle CAS est une application développée avec Oracle forms pour sélectionner, modifier et supprimer les données dans ALS Database.
Les données d’ingénierie sont communiquées à la base de données ALS via le SAP PN1.
Le planning de production est importé via l’application PPSS, chose qui permet de le transférer au terrain.
OPS est une application qui gère l’impression des ordres de fa brication en se basant sur le planning de production.
Le manifest est une étiquette accompagnant le faisceau éle ctrique après son assemblage pour assurer une identification fiable, rapide et directement utilisable informatiquement via un code barre. 32
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Figure 8 : Flux d'information existant d e DPT
33
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Les faisceaux assemblés dans les chaines de montage passent au contrôle électrique où
l’opérateur commence par scanner le Manifest (DPN ; SN) pour lancer le programme de test propre à la référence concernée. Le faisceau est monté par la suite sur le banc du contrôle électrique, appelé aussi ROB, pour vérifier la continuité électrique entre les différentes extrémités du circuit et la présence des éléments secondaires (sécurité des connecteurs, passe-fil, brides…).
Une fois le controle est achevé, l’étiquette du test électrique est imprimé. L’application ROB_STARTER.EXE installée sur l’ordinateur lié au ROB incrémente le nombre des faisceaux testés et envoi le résultat à la base de données ALS.
A noter que le nombre d’opérateurs ainsi que le nom d’équipe est insérer manuellement au début de chaque shift sur L’application ROB_STARTER.EXE, communiquant ainsi ces données à ALS database. Par la suite, un contrôle de contention est assuré pour vérif ier visuellement le faisceau électrique et mesurer ses deux côtes. A ce stade, le faisceau électrique est validé, il passe à la dernière
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Les faisceaux assemblés dans les chaines de montage passent au contrôle électrique où
l’opérateur commence par scanner le Manifest (DPN ; SN) pour lancer le programme de test propre à la référence concernée. Le faisceau est monté par la suite sur le banc du contrôle électrique, appelé aussi ROB, pour vérifier la continuité électrique entre les différentes extrémités du circuit et la présence des éléments secondaires (sécurité des connecteurs, passe-fil, brides…).
Une fois le controle est achevé, l’étiquette du test électrique est imprimé. L’application ROB_STARTER.EXE installée sur l’ordinateur lié au ROB incrémente le nombre des faisceaux testés et envoi le résultat à la base de données ALS.
A noter que le nombre d’opérateurs ainsi que le nom d’équipe est insérer manuellement au début de chaque shift sur L’application ROB_STARTER.EXE, communiquant ainsi ces données à ALS database. Par la suite, un contrôle de contention est assuré pour vérif ier visuellement le faisceau électrique et mesurer ses deux côtes. A ce stade, le faisceau électrique est validé, il passe à la dernière
étape du processus d’assemblage, c’est l’emballage. Une foi s le câble est emballé, il est mis dans des palettes destinées au magasin des produits finis.
L’application PACKAGING.EXE installée sur l’ordinateur du poste d’emballage contrôle et compte le nombre des faisceaux emballés et envoie les résultats à la base de données ALS.
SAP Shipping label est une étiquette Gallia qui est automatiquement imprimée une fois la palette atteint la quantité définie. L’opérateur scanne cette étiquète pour avoir la traçabilité du processus complet. Dans cette analyse que nous avons menée sur le système d’information existant de DPT, il
est
remarquable que ce dernier n’est pas exploité. En effet, le système de reporting existant est traité d’une manière manuelle malgré la présence d’ALS qui communique avec la chaine d’assemblage et collecte un certain nombre d’indicateurs en temps réel. La solution que nous avons proposée est de communiquer le futur tableau de bord avec ALS et rendre ce dernier capable de collecter en temps réel tous les indicateurs que nous aurons besoin.
III. Choix de la chaine pilote Pour conduire l’action, il fallait choisir le chantier pilote de notre projet qui servira comme vitrine et doit pouvoir démontrer facilement l’efficacité du futur tableau de bord. 34
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
En effet, l’intérêt de ce chantier pilote est de nous fournir une zone d’application pratique de la solution, d’y démontrer la faisabilité et les gains immédiats, avant d’y étendre aux autres lignes d’assemblage. Son choix était donc très important et ne peut en aucun cas être quelconque. Pour cela, une réunion de
Brainstorming s’est déroulée.
Les critères de choix retenus sont :
Disponibilité pendant la période de stage.
Existence du système d’information ALS.
Impact sur l’efficience globale de l’entreprise.
L’idée était de choisir la chaine d’assemblage la plus critique impactant la performance globale de l’usine afin de voir rapidement l’efficacité des solutions proposées. Plus la situation initiale est dégradée d’autant plus la moindre amélioration sera visible. Dans ce cadre, Nous avons consulté le département ingénierie pour avoir un fichier appelé ‘Gap
Analysis’ du mois Mars. Ce fichier compare l’efficience actuelle avec l’efficience désirée et il classe les projets selon leur pourcentage d’impact sur l’écart. Les données sont résumées sur le graphe ci-dessous.
Analyse d’écart par projets 110% 105% 2.4%
100%
e c n 95% e i c 90% i f f E 85%
1.3%
1.2%
0.6%
0.5%
0.3%
0.0%
102%
Puma
Prince PSA
Prince BMW
Mfg. Model
4.2% 5.5% 7.6% 78.6%
80% 75% 70% Actual
CD4.1
CD4.2
Panther
CD4 PP
Others
LP Cutting Efficiency Efficiency
Figure 9 : Analyse d’écart Par projet
Ce graphe montre que le projet CD4.2 est celui le plus impactant la performance de l’usine, son pourcentage dans l’écart par rapport à l’objectif de l’efficience est 5.5 %.
35
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Nous avons par la suite tracé un autre graphe classant les familles du projet CD4.2 selon leur
pourcentage d’impact sur l’écart par rapport à l’objectif. Les résultats sont présentés sur la figure 10 ci-dessous.
Analyse d’écart par familles du projet CD4.2 110%
100% 9.2%
100% 9.0%
90%
e c n 80% e i c i f 70% f E 60%
15.6%
66.2%
50% 40% Actual
Floor
IP
Engine Bay
Mfg. Model
Figure 10 : Analyse d'écart par famille
Ce graphe montre que la famille Floor est celle la plus impactant l’efficience du projet CD4.2, son pourcentage dans l’écart par rapport à l’objectif est 15.6 %. En se basant sur ces résultats et en vérifiant à la fois les deux autres critères, à savoir la
disponibilité pendant la période du stage et l’existence du système d’information ALS, la chaine d’assemblage pilote de notre projet sera celle de la famille FLOOR du projet CD4.2 propre au client FORD.
IV. Définition du groupe de travail Nous avons sollicité plusieurs opérants du terrain et représentants de chaque département pour
construire l’équipe SCRUM. Dans Scrum il y a trois rôles : le propriétaire de produit, l’équipe de développement et le Scrum Master. Ensemble ils forment l’équipe Scrum.
Le Propriétaire de produit est le point central du pilotage du produit. Il représente l'unique autorité pouvant décider quelles fonctions il faut réaliser et dans quel ordre. Le propriétaire de produit est le garant de la vision globale de ce que l'équipe Scrum doit réali ser, il se charge de communiquer cette vision à tous les autres participants.
L’équipe de développement est chargé de construire le produit défini. Elle inclut toute l’expertise nécessaire pour fournir une version du produit potentiellement livrable à chaque Sprint. Chaque personne dans l’équipe de développement est simplement qualifiée de membre 36
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
car il n’y a pas de titre de spécialiste au sein du groupe. Tous les membres travaillent ensemble durant chaque Sprint, par tous les moyens appropriés et nécessaires à l’atteinte de l’objectif fixé.
Le Scrum Master est responsable de :
s’assurer que Scrum est compris et mis en œuvre par l’équipe.
Trouver des techniques de gestion efficace du Backlog du produit.
Faciliter les événements Scrum lorsque demandé ou requis.
Éliminer les obstacles au progrès de l’Équipe de Développement .
Le tableau 3 de la page suivante regroupe les rôles joués par les personnes qui ont participé au projet ainsi que leur poste.
Rôle
Personnage
Poste
Propriétaire de produit
Arbaoui Hicham
Manager d’EOS & CI
Rami Hassan
Responsable IT
Kalil Oumaima
Stagiaire
Rami Hassan
Responsable IT
Kalil Oumaima
Stagiaire
Grosscheld Michael Ouadie Belkadi
Responsable des applications IT Manager IT
Abdellah El haskouri
Coordinateur Production
Ilham ElKhayati
Coordinatrice Planification
Yassine Allouch Hafid Bakkali
Coordinateur Ingénierie industrielle Responsable Maintenance
Achraf Ettazrouti
Coordinateur qualité
Rahhali El Mehdi
Coordinateur Ingénierie industrielle
Scrum Master
Equipe de développement
Tableau 3 : Equipe Scrum
A noter qu’il est important d’avoir un Scrum Master engagé et travaillant énergiquement à la résolution des problèmes auxquels sont confrontés aussi bien l’équipe que le propriétaire de produit. Vue la criticité de ce rôle et pour éviter le risque de son indisponibilité, nous avons occupé ce
rôle ensemble sous l’encadrement de M. Kamach Oualid. 37
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
V.
Analyse des risques du projet
Pour gérer les risques et les problèmes pouvant survenir et empêcher le bon déroulement de notre projet, nous avons adopté une approche préventive visant à minimiser la criticité de ces problèmes. La méthode AMDEC (Analyse des modes de défaillances, de leurs effets et de leur criticité) est la méthode
la plus appropriée dans ce cas, permettant ainsi d’étudier tous les risques
organisationnels détectés détectés afin d’envisager par la suite des actions correctives nécessaire à mettre en place au bon moment pour éviter ces risques. Pour ce faire, une réunion de Brainstorming était réalisée. Cette réunion avait pour but de recenser les risques qui peuvent survenir durant le déroulement du projet et décider quelles sont
les actions à mettre en place en cas d’apparition de ces risques. L’AMDEC repose sur la noti on de criticité C de chaque problème qui représente le produit de la fréquence ou probabilité d’apparition du problème F, la gravité G et la probabilité de non détection D.
L’évaluation des trois critères est faite sur une échelle de 4. Le tableau 4 ci -dessous représente la grille de notation utilisée.
Cotation
G : Gravité
F : Fréquence
D : Détection
1
Négligeable
Jamais rencontré
Fortement détectable
2
Mineure
Rarement rencontré
Détectable
3
Majeure
Rencontré régulièrement
Peu détectable
4
Très grave
Rencontré toujours
Non détectable
Tableau 4 : Grille de notation d'AMDEC d'AMDEC projet
Evaluation de la criticité des risques est détaillée sur le tableau 5 suivant. Risque majeur
C>27
Risque moyen
8
Risque mineur
C<8 Tableau 5 : Evaluation de la criticité des risques projet
Le tableau 6 de la page suivante représente le tableau AMDEC projet avant les actions préventives. 38
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Risque
Cause
Effet
Non-respect du planning fourni
Mauvaise gestion des priorités Démission ou décès
Absence d’un membre de l’équipe.
G
F
D
C
4
3
4
48
Solution
Suivi quotidien de l’accomplissement des tâches. Nouvelle affectation des taches entre les membres d’équipe en attendant le remplacer par une autre personne ayant le même profil.
Retard du projet 3
3
3
27
Absence maladie ou départ en congé
Consulter le calendrier de chaque membre avant la planification des réunions. Répartition des taches sur les autres membres disponibles.
Perte des données
Endommagement du PC portable
Retard des livrables
4
4
2
32
Sauvegarde journalière des données actualisées sur un disque dur externe.
Arrêt d’usine
Incendie…
Inaccomplissement du projet
4
1
4
16
Chercher les entreprises de même activité ayant un besoin similaire et reporter la soutenance à la deuxième session.
Nom coopération du personnel
Résistance au changement
Difficulté de convaincre le personnel d’adhérer aux changements proposés
3
2
3
18
Difficulté dans la conception du tableau de bord
Non maitrise des outils informatiques
d’avancement du
4
2
2
16
Apparition des contraintes techniques
Perte du temps
2
2
3
12
Tache inachevée par un
membre d’équipe
Convaincre le personnel par des arguments basés sur
Blocage projet
les gains apportés par la solution
Autoformation sur les outils de programmation Contacter les informaticiens au sein de DPT
Informer
l’équipe pour analyser contraintes et achever la tâche.
Tableau 6 : AMDEC projet
39
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
L’AMDEC après la prise en compte des solutions est présenté au niveau du tableau 7. Risque
G
F
D
C
Non-respect du planning fourni
2
2
1
4
Absence d’un membre de l’équipe
1
2
3
6
Perte des données
2
2
2
8
Arrêt d’usine
2
1
4
8
Nom coopération du personnel
2
2
2
8
Difficulté dans la conception du tableau de bord
1
2
2
4
Tache inachevée par un membre d’équipe
1
2
3
6
Tableau 7 : Criticité des risques après la prise en compte des solutions
Le tableau montre que les solutions proposées ont permis de diminuer la criticité des risques.
VI. Backlog de produit Dans Scrum, la première étape correspond à l’élaboration du Backlog de produit, une liste
les
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
L’AMDEC après la prise en compte des solutions est présenté au niveau du tableau 7. Risque
G
F
D
C
Non-respect du planning fourni
2
2
1
4
Absence d’un membre de l’équipe
1
2
3
6
Perte des données
2
2
2
8
Arrêt d’usine
2
1
4
8
Nom coopération du personnel
2
2
2
8
Difficulté dans la conception du tableau de bord
1
2
2
4
Tache inachevée par un membre d’équipe
1
2
3
6
Tableau 7 : Criticité des risques après la prise en compte des solutions
Le tableau montre que les solutions proposées ont permis de diminuer la criticité des risques.
VI. Backlog de produit Dans Scrum, la première étape correspond à l’élaboration du Backlog de produit, une liste ordonnée des fonctionnalités attendues du produit. Pour ce faire, nous avons commencé par une enquête par questionnaire afin de collecter les indicateurs qui devant être affichés dans le tableau de bord lors de livraisons futures. Par la suite, nous avons appliqué le vote pondéré pour hiérarchiser les indicateurs selon leur ordre d’importance, ainsi que la matrice de décision pour
sélectionner ces indicateurs par ordre
de priorité et construire, finalement, le Backog de tableau de bord.
1. Enquête par questionnaire Nous avons contacté les représentants de chaque département pour collecter tous les indicateurs
de performance de l’usine. Ensuite, on a planifié une séance de Brainstorming avec le Propriétaire de produit pour choisir que les indicateurs qui concernent directement les chaines
d’assemblage et qui vont être l’objet de notre projet. Après la réunion, 7 indicateurs ont été sélectionnés.
Le terme QVC (Qualité, volume et cout) est largement utilisé par l’entreprise Delphi Packard Tanger pour classer les indicateurs de performance employés pour mesurer et suivre la performance des différents processus de fabrication. Le tableau 2 suivant présente les indicateurs concernés par notre projet selon le QVC.
40
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Indicateur
Description
Temps de première qualité
Les produits de bonne qualité obtenue dès la première production
Réparation
Le nombre de faisceaux réparés
Temps d’arrêt d’assemblage
Le temps d’arrêt de la chaine d’assemblage
Nombre de faisceaux produits
Le nombre de faisceaux produits
Temps cycle
Le temps donné à un opérateur pour réaliser ses taches
Effectif
Le nombre d’opérateurs
Efficience
Les heures produites sur les heures payées
Q
V
C
Tableau 8 : Indicateurs concernés selon le QVC
Pour identifier les besoins des responsables, nous avons eu recours à une enquête par questionnaire basée sur les indicateurs déjà sélectionnés. Pour la construction du questionnaire, nous avons précédé à une formulation claire et précise du problème et des objectifs de l’étude avant de
1.1.
suivre des étapes bien précises.
Objet
Notre enquête porte sur les indicateurs de performance des lignes d’assemblage.
1.2.
Objectif
On cherche à travers ce questionnaire à :
Identifier pour chaque indicateur de la liste son degré d’importance.
Ajouter d’autres indicateurs non listés et nécessaires.
Avoir des remarques d’amélioration.
1.3.
Population et univers de l’enquête
Les personnes concernées par les objectifs de l’enquêt e sont les coordinateurs et les managers des départements : production, logistique, qualité, ingénierie, coupe & préparation, Process et maintenance.
1.4.
Détermination de l’échantillon
Puisque l’univers de l’enquête est petit, on a retenu tous ses individus. L’échantillon à partir duquel est effectuée l’enquête est présenté dans le tableau ci-dessous : 41
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Département
Personnes interrogés
Poste
Ali Benabdessadak
Manager
Yassine Allouch Hilal Sidiahmed Ingénierie
Sofia ElHassani
Coordinateur
Zakaria Chaouai Rahhali El Mehdi Said Oualla Production
Manager
Anas Ghammat Abdellah El Haskouri
Coordinateur
Abdellah Abairrou Abdelhamid Abudar Qualité
Manager
Achraf Ettazrouti Oussama Laaraichi
Coordinateur
Mostapha Hemmid Mohamed Amine Saidi Coupe
Samy Tarfaoui Adil Lazara
Manager Coordinateur
Dadda Sufiane Process
Maintenance
El kasmi
Coordinateur
Benaija Alaa
Manager
Saad Boughaba
Coordinateur
Taoufik Mesbahi
Manager
Ilham ElKhayati Logistique
Faris Albarrak
Coordinateur
Mouaffak Yassine Tableau 9 : Echantillon de l'enquête
1.5.
Prétest
Au niveau de cette étape, le propriétaire de produit a évalué la clarté et la précision des termes
utilisés et des questions posées, et l’efficacité de la mise en page.
42
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
1.6.
Questionnaire définitif
On a utilisé deux modes d’administration pour présenter le questionnaire aux responsables :
Le premier mode est par enquêteur : on a posé face à face les questions aux coordinateurs puis ils ont noté leurs réponses.
Le deuxième mode est l’auto -administration : l’assistante de chaque département était chargée de distribuer le questionnaire au manager de son département qui a répondu tout seul.
La version finale du questionnaire qui a été soumis aux enquêtés est présenté à l’annexe 2. Nous présentons dans l’annexe 3
un questionnaire remplis.
2. Hiérarchisation des indicateurs de performance selon leur importance Lorsque les questionnaires sont rentrés, nous avons procédé à leur analyse en utilisant le vote pondéré. Chaque enquêté a classé les indicateurs par ordre d’importance. En attribuant le poids 5 pour
ce qui lui parait le plus important (excellent), le poids 3 pour l’indicateur qui vient en deuxième position, et ainsi de suite jusqu’au poids 0 pour l’indicateur non appliqué. Nous avons additionné les points des votants, et classé les indicateurs dans l’ordre décroissant selon le total de points alloués à chaque indicateur (voir tableau ci-dessous).
Degrés d’importance Pondération Temps d’arrêt d’assemblage Nombre de faisceaux produits Efficience Temps de première qualité Réparation Effectif Temps Cycle
Moyenne Elevé
Faible 1 0
2 1
3 7
4 15
83
3
0
1
7
14
79
4
0
2
5
14
75
5
0
1
10
9
68
5
0
2
9
9
67
6
2
2
6
9
60
5
1
6
11
2
54
Tableau 10 : Tableau du vote pondéré
43
Maximum
Total des points
Non applicable 0 2
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Le résultat obtenu est présenté sur le graphe ci -dessous.
KPIs par ordre d'importance 83 79 75 68
67 60 54
Temps d’arrêt d’assemblage
Nombre de faisceaux produits
Efficience
Temps de première qualité
Réparation
Effectif
Temps Cycle
Figure 11 : Résultat du vote pondéré
La figure montre que le temps d’arrêt d’assemblage est l’indicateur le plus im portant à superviser, puis le nombre de faisceaux produits qui a été classé à la deuxième position, ensuite
l’efficience, le temps de première qualité, la réparation, l’effectif, et le temps cycle qui représente l’indicateur le moins important. Ce classement
n’était pas suffisant, il fallait prendre un autre critère en considération pour
sélectionner les indicateurs par ordre de priorité et construire par la suite le Backlog de produit.
3. Sélection des indicateurs de performance par ordre de priorité Au niveau de cette étape, nous avons établis des priorités parmi les indicateurs déjà hiérarchisés
par ordre d’importance. Pour ce faire, la matrice de décision a été utilisée. Nous avons commencé d’abord par définir les critères de sélection. Les critères retenus sont :
La disponibilité : l’indicateur est facilement extrait des systèmes d’information existants.
L’importance : le degré d’importance de l’indicateur pour les responsables.
Ensuite, nous avons affecté pour les deux critères le poids 1 car il s’agit en fait de donner la priorité pour les indicateurs à la fois importants et disponibles. 44
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Finalement, nous avons donné des points pour chaque indicateur allant de 1 à 7 en regard de chaque critère. La matrice de décisions est représentée sur le tableau ci-dessous.
Critères Pondération Nombre de faisceaux produits Effectif Efficience Temps d’arrêt d’assemblage Réparation Temps de première qualité Temps cycle
Importance
Disponibilité
Total des points
1
1
6
7
13
2
7
9
5
3
8
7
1
8
4
1
5
3
1
4
1
1
2
Figure 12 : Matrice de décision
Après le calcul des notes totales et leur classement par ordre décroissant, on a obtenu le Backlog de produit.
4. Backlog de tableau de bord Pour construire le Backlog de tableau de bord, nous avons listé les besoins identifiés avec leur ordre de priorité. Un Item est une exigence du tableau de bord à développer.
Items
Priorité
En tant qu’utilisateur, je peux surveiller en temps réel le nombre de faisceaux produits
1
En tant qu’utilisateur, je peux surveiller en temps réel l’effectif
2
En tant qu’utilisateur, je peux surveiller en temps réel l’efficience
3
En tant qu’utilisateur, je peux surveiller en temps réel le temps d’arrêt d’assemblage
4
En tant qu’utilisateur, je peux surveiller en temps r éel la réparation
5
En tant qu’utilisateur, je peux surveiller en temps réel le temps de première qualité
6
En tant qu’utilisateur, je peux surveiller en temps réel le temps cycle
7
Tableau 11 : Backlog de produit
45
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
VII. Documentation des indicateurs Une fois le Backlog du tableau de bord élaboré et l es indicateurs concernés sélectionnés, Nous avons établi une « fiche indicateur» qui rassemble les informations suivantes :
La définition et caractéristiques de l’indicateur : nom de l’indicateur, formule de calcul, périodicité, source de données.
Les référentiels de comparaison du résultat : s ource de l’objectif, période à laquelle on compare.
Les formes de présentation : tableau, graphe, illustration...
La fiche indicateur que nous a vons élaborée est représentée dans l’annexe 4.
VIII.Conclusion Dans ce deuxième chapitre, nous avons effectué une étude préalable de notre projet. En effet, nous avons commencé par analyser la situation actuelle, chose qui nous a montré
l’existence d’un système d’information : ALS. Ce dernier communique directement avec les outils de production et récupère un certain nombre d’indicateurs pour les sto cker dans une base de données Oracle. A la lumière de cette étude nous avons décidé d’exploiter la base de données ALS pour collecter les indicateurs déjà disponibles et rendre ce système capable d’acquérir les indicateurs que nous aurons besoin en temps réel. Par la suite, il était nécessaire de choisir une chaine pilote pour effectuer nos tests, démontrer
facilement l’efficacité des solutions qui seront proposées et convaincre le personnel du bienfondé du futur tableau de bord. Son choix était donc très important, pour cela nous avons vérifié un certain nombre de critères pour décider par la suite que la famille FLOOR du projet CD4.2 propre au client FORD servira comme chaine pilote pour notre projet.
L’étape suivante a concerné la définition de l’équipe de travail en se basant sur les rôles définis par SCRUM, à savoir, le propriétaire de produit, l’équipe de développement et le Scrum Master. Maitriser et identifier les risques est nécessaire pour la bonne conduite du projet. Pour cette raison nous avons mis en place une démarche AMDEC.
Enfin, SCRUM a commencée par l’élaboration du Backlog de produit qui résume toutes les fonctionnalités et exigences du tableau de bord à développer. Ce travail a nécessité l’application du vote pondéré pour hiérarchiser les besoins selon leur degré d’importance ainsi que la matrice de décision pour les sélectionné par ordre de priorité. 46
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Chapitre 3 : Déroulement du SPRINT 1
47
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
I.
Introduction
SCRUM structure le développement en cycles de travail appelés Sprints. Ces itérations ne
durent jamais plus de quatre semaines, s’enchainent l’une après l’autre sans interruption et produisent ce qui est officiellement appelé un incrément du produit potentiellement livrable. Dans ce chapitre nous allons développer les phases de déroulement du premier Sprint correspondants aux étapes du modèle de développement en cascade. Une fois le Sprint terminé, nous allons présenter la revue de Sprint et son rétrospective.
II.
Planification
Au démarrage du premier Sprint une réunion de planification a eu lieu. Cette réunion a été devisée en deux réunions distinctes.
Dans la première partie de la planification du Sprint, nous avons collaboré avec l’équipe de développement et le propriétaire de produit pour envisager les fonctionnalités à développer et nous avons décidé que le Backlog de premier Sprint comportera les trois premiers éléments du Backlog de produit.
Une fois l’objectif du sprint fixé et les Items choisis, nous avons déterminé,
lors
de
la
deuxième partie de la planification du Sprint, comment s’organiser pour réaliser cet objectif, en estimant la durée de chaque phase. Le planning du premier Sprint élaboré est représenté s ur la figure ci-dessous.
Figure 14 13 :: Planning Planning du dupremier premier Sprint Sprint Figure
Pour chaque élément sélectionné du Backlog de produit, nous avons créé une liste des taches
constituée de tous les taches nécessaires pour réaliser l’élément ainsi que les membres de l’équipe concernés. Cette liste des taches est appelée le Backlog de Sprint (Voir tableau 12).
48
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Items
Priorité Taches du Sprint
Volontaire
Effort initial estimé (h)
Analyse des besoins Hassan & Oumaima
En tant qu’utilisateur, je peux surveiller en temps réel le nombre de faisceaux produits
1
Conception
Hassan & Oumaima
Codage
Grosschedl Michael
Test d’intégration
Hassan & Oumaima
Déploiement
Team
Analyse des besoins Hassan & Oumaima
En tant qu’utilisateur, je peux surveiller en temps réel l’effectif .
2
Conception
Hassan & Oumaima
Codage
Grosschedl Michael
Test d’intégration
Hassan & Oumaima
Déploiement
Team
Analyse des besoins Hassan & Oumaima
En tant qu’utilisateur, je peux surveiller en temps réel
3
l’efficience
Conception
Hassan & Oumaima
Codage
Grosschedl Michael
Test d’intégration
Hassan & Oumaima
Déploiement
Team
Tableau 12 : Backlog du premier Sprint
L’effort initial est estimé en heures, il représente le temps dédié à chaque volontaire pour accomplir sa tâche.
Pour suivre l’avancement de notre projet et avoir une vision claire du travail à accomplir, en cours et terminé, nous avons fait appel à un outil visuel de suivi des taches, sous la forme d’un tableau mural, appelé tableau SCRUM. Sur ce tableau, les taches, écrites sur des post-it magnétiques, avancent de colonnes en colonnes. Ces colonnes sont étiquetées « A faire », « En cours » et « Réalisée ». La figure 15 de la page suivante représente le tableau SCRUM réalisé et qui a été mis dans le bureau du propriétaire de produit.
49
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Figure 15 : Photo du tableau Scrum
Toujours dans le cadre de management visuelle, nous avons utilisé un code couleur pour les post-it :
Couleur Verte si la tâche n’a pas dépassé la moitié de la durée totale estimée.
Couleur orange si la tache a dépassé la moitié de la durée mais n’a pas encore dépassé la durée totale estimée.
Couleur rouge si la tache a dépassé la durée totale estimée.
Sur le tableau figure le planning du Sprint, le planning global du projet ainsi qu’un graphique d’avancement. Ce dernier permet de suivre la quantité de travail restante dans le Backlog de Sprint, déterminer la rapidité avec laquelle l’équipe a effectué se s taches et prévoir le moment où l’objectif sera atteint. En outre, nous avons utilisé le graphique d’avancement pour anticiper de façon relativement fiable les échéances futures en cours durant l’exécution du présent Sprint et résoudre les problèmes le plus vite possible. 50
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Pour tracer le graphique d’avancement, il fallait actualiser la charge de travail restante (en heures) en fonction du temps (en jours) lors de chaque mêlé e quotidienne. Les mêlées quotidiennes ainsi que les détails d’élaboration des graphiques d’avancement seront abordés au niveau du chapitre 4.
Le graphique d’avancement du premier Sprint est représenté sur l’ annexe 5.
III. Analyse des besoins Partant d’une expression initiale des besoins fonctionnels par les utilisateurs , nous avons passé à leur analyse en utilisant le diagramme
des cas d’utilisation.
La détermination des besoins a été réalisé suite à plusieurs entrevus avec les utilisateurs et le propriétaire de produit.
1. Capture des besoins La phase de capture des besoins est la première phase dans le développement du tableau de bord du premier SPRINT.
1.1.
Spécification des besoins fonctionnels
Les actions que doit effectuer le système en réponse aux demandes présentées par les utilisateurs sont celles présentées dans le Backlog du premier Sprint. Le tableau de bord doit permettre la supervision en temps r éel du nombre de faisceaux produits,
l’effectif et l’efficience. A noter que les utilisateurs insistent sur le fait que le nombre de faisceaux emballés n’est pas suffisant comme indicateur. Pour cette raison, il faut afficher aussi le nombre de faisceaux testés par le ROB.
1.2.
Présentation des acteurs
Un acteur est toute entité externe qui interagit avec notre tableau de bord dans le but d’atteindre son objectif et récupérer un résultat. Notre application interagit
avec un seul acteur qui est l’utilisateur. C’est le responsable qui
assure le suivi et le pilotage des lignes d’assemblage. Plus précisément, c’est un acteur généralisé qui représente les managers et coordinateurs des départements suivants : production, logistique, qualité, ingénierie, coupe & préparation, Process et maintenance. 51
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
La maintenance du tableau de bord sera la responsabilité de chaque utilisateur. La maintenance de la future application désigne le s modifications qui lui seront apportées après
sa mise en œuvre pour corriger les fautes, l’améliorer, ou encore l’adapter à un environnement modifié.
1.3.
Spécification des besoins non fonctionnels
Les exigences internes pour le futur tableau de bord et cachées vis à vis des utilisateurs sont :
l’ergonomie : l’application doit être facile à manipuler. Ces interfaces doivent être compréhensibles, et bien organisées.
L’extensibilité : Le tableau de bord doit permettre l’intégration de nouvelles fonctionnalités.
La sécurité des données : Sécuriser les données revient à appliquer une stratégie d’autorisation et de contrôle de chaque tentative d’accès à ces données. Dans notre tableau de bord l’accès aux indicateurs est autorisé pour tous les utilisateurs, or, l’accès à la base de données source
n’est autorisé qu’aux personnes propriétaires et selon un
privilège qui détermine les droits d’accès.
2. Diagramme des cas d’utilisation Le diagramme des cas d’utilisation réalisé est l’ensemble des cas d’utilisation et des acteurs intervenant dans le tableau de bord.
Les cas d’utilisation permettent de capturer et dé crire les besoins fonctionnels, pas la solution. Ils modélisent les différents services rendus par le système aux utilisateurs et ils apportent une valeur ajoutée notable dans l’utilisation de
l’application à l’acteur concerné.
Les cas d’utilisation sont le fil conducteur du projet : au niveau de l’analyse, de la conception puis des scénarios et tests.
La figure 16 de la page suivante présente le diagramme des d’ utilisation propre au premier Sprint.
Il s’agit de modéliser les fonctionnalités de l’application telles quelles sont perçues par les acteurs et les présenter sur le
diagramme des cas d’ utilisation en utilisant le logiciel
PowerDesigner.
Chaque cas d’utilisation est accompagné d’une description résumée permettant de comprendre son intention principale. 52
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Figure 16 : Diagramme des cas d'utilisation
53
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
3. Analyse des cas d’utilisation Au niveau de cette étape, on a réalisé une fiche détaillée dans laquelle nous avons mentionné le
scénario principal à suivre pour chaque cas d’utilisation. La figure ci-dessous
présente la fiche réalisée pour quelques cas d’utilisation, la suite est
présentée dans l’annexe 6.
Cas d’utilisation
Scénario principal
Filtrer les indicateurs par clients, projets,
1. Le superviseur sélectionne les filtres dont il a besoin : les clients, projets, chaines
chaine d’assemblage, Equipes, groupe de produit, CPN, et DPN.
Filtrer les indicateurs selon la semaine, la date et le shift.
Afficher le nombre de faisceaux produits sur un histogramme et son objectif sur une courbe dans le même graphe.
d’assemblage, équipes, groupe de produits, CPN, et DPN. 2. Le tableau de bord affiche les indicateurs par filtres sélectionnés. 1. Le superviseur sélectionne les semaines, les dates, ou les shifts 2. Le tableau de bord affiche les indicateurs filtrés. 1. Le tableau de bord affiche le nombre de faisceaux produits avec son objectif sur un graphique combiné : Output sur un histogramme.
Afficher l’effectif et l’objectif sur un graphique en courbes
1.
Le tableau de bord affiche l’effectif avec son objectif sur un graphique en courbes.
1.
Consulter les indicateurs par client, par projet, par chaine d’assemblage et par Equipe
L’objectif sur une courbe.
Le tableau de bord affiche l’indicateur par
clients. 2. Le superviseur choisit le client à superviser. 3. Le tableau de bord affiche l’indicateur des projets propres au client sélectionné. 4. Le superviseur choisit le projet à superviser. 5. Le tableau de bord affiche l’indicateur des
chaines d’assemblage propres au projet sélectionné. 6. Le superviseur
choisit
la
chaine
d’assemblage à superviser. 7. Le tableau de bord affiche l’indicateur de s équipes propres à la chaine d’assemblage sélectionnée. Tableau 13: Fiche des cas d'utilisation
54
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
IV. Conception 1. Architecture technique Le tableau de bord visé sera structuré selon une architecture 2-tiers (voir figure 17). Elle est composée de deux éléments : La base de données Oracle 9i ainsi que le poste client sur lequel sera installé le client Oracle 9i et Qlik sense disktop.
Le poste client sera connecté à la base de données via le réseau local de DPT à l’aide d’ un câble RG 45. A noter que l ’architecture technique est réalisée avec le logic iel SmartDraw.
Figure 17 : Architecture technique du tableau de bord
2. Eléments constitutifs du tableau de bord Le tableau de bord réalisé est une application Qlik Sense qui représente un ensemb le d’éléments de données, de feuilles et de récits réutilisables. Il s’agit d’une entité autonome qui comprend les données à analyser dans un modèle de données structuré. Les éléments constitutifs du tableau de bord sont schématisés sur la figure 18.
Figure 18 : éléments constitutifs du tableau de bord
55
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
La figure 17 montre que l’application Qlik Sense est constituée d’une base et des éléments visuels.
2.1.
Structure et éléments visuels
Feuilles
Une feuille désigne l'endroit où les graphiques et les tables sont placés pour la visualisation des données. Une structure signifie un groupement des visualisations ayant le même objectif sur la même feuille.
Favoris
La création des favoris sert à enregistrer les sélections actives et un emplacement particulier, chose qui donne la possibilité de rouvrir les favoris par la suite afin de rétablir l'état antérieur
des sélections. L’utilisation du favori permet d’accéder à la feuille explorée au moment de la création du favori.
Récits
Les récits sont basés sur des instantanés de visualisations, ils permettent de présenter les données et amènent vers de nouvelles réflexions.
2.2.
Base
Script de chargement de données
Le script de chargement de données permet de charger des données dans l'application. Le script se connecte à une source de données et récupère l es données.
Modèle de données
Les données chargées sont structurées dans un modèle de données. Il faut éditer le script de chargement de données puis recharger les données afin de créer le modèle de données souhaité.
Mesures
Les mesures représentent les calculs et expressions utilisés dans les visualisations du tableau de
bord et qui sont représentés sur l’axe des ordonnées.
Dimensions
Les dimensions servent à déterminer la méthode de groupement des données dans les
visualisations et ils sont représentés sous l’axe des abscisses. 56
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
V.
Codage et déploiement
Dans cette partie, nous allons donner un aperçu du tableau de bord en présentant des images écran au niveau de chaque étape de la phase codage. En parallèle, nous allons présenter son déploiement qui a été réellement commencé après la validation
du test d’intégration.
1. Modification de la base de données Dans la base de données
oracle propre au système d’information ALS, les clients ne sont pas
tous définis et les noms des projets ainsi que les noms des chaines d’assemblage n’existaient pas. La solution proposée consiste à actualiser la liste des clients et remplacer des champs non
utilisés dans la base de données Oracle par ces informations, d’une façon à faire correspondre pour chaque chaine d’assemblage le projet correspondant ainsi que le client concerné. Mais il fallait tout d’abord collecter ces informations et les vérifier sur terrain. L’ annexe 7 présente le tableau résumant les résultats. Une fois ces informations ont été collectées, nous avons contacté le département IT pour avoir
le fichier d’installation d’Oracle CAS qui permet via une interface graphique, de gérer les objets de la base (gérer les droits d’accès, modifier les données…). Après l’installation, nous avons ajouté les clients, les projets et les chaines d’assemblage. Ensuite, nous avons identifié les groupes de produits de chaque chaine d’assemblage. Et enfin, nous avons pu définir pour chaque groupe de produits le projet et le client correspondant. Cette opération a nécessité un grand effort car il fallait modifier les informations qui concernent 98 groupes de produits.
L’annexe 8 présente la base de données avant et après modification.
2. Chargement des données Après l’adaptation de la base de données à nos besoins, nous avons installé puis configuré le client Oracle 9i.
Une fois Qlik sense lancé et l’application vide créée, la première étape con siste à y charger les données. Nous avons utilisé le connecteur ODBC pour se connecter à la base de données ALS. Concernant les cibles de chaque indicateur, nous avons utilisé un fichier Excel incluant la déclaration des objectifs. Pour se connecter à ce dernier, nous avons utilisé une connexion de type dossier qui définit un chemin d'accès à des dossiers de fichiers locaux. 57
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
La figure 19 représente une partie de la syntaxe du Script de chargement de données créé à
l’aide de l’éditeur prévu à cet effet.
Figure 19 : Partie du Script de chargement de données
Le script, qui doit respecter la syntaxe de script de Qlik Sense, est codé par couleur pour différencier plus facilement les éléments les uns des autres. Les mots-clés de la syntaxe de Qlik Sense sont signalés en bleu et chaque ligne du script est numérotée. Les données sont chargées par des instructions
LOAD/SELECT et les noms des champs sont
modifiés par as.
Après l’exécution du Script, Les données chargées sont structurées dans un modèle de données, chose qui permet de vérifier la façon dont elles sont structurées et les organiser de manière à répondre au besoin des utilisateurs.
Figure 20 : Modèle de données du tableau de bord
58
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
La figure 20 de la page précédente présente un aperçu des données contenues dans les tables et les champs dans le visionneur de modèle de données. Chaque table de données est représentée par une boîte dont le titre correspond au nom de la table et qui répertorie tous les champs figurant dans la table. Le tableau suivant donne pour chaque champ, sa signification.
Source
Table
RBDSBL1
Base de données ALS
Champs
Signification
WEEK
la semaine de production
PRODUCTION DATE
La date de production
SHIFT
Le shift
CUSTOMER
Le client
PROJECT
Le projet
VALUE STREAM
La chaine d’assemblage
TEAM
L’équipe
PRODUCT GROUPE
Le groupe de produit qui représente un ensemble de références
DPN
la référence produite
CPN
un numéro connu par le client de la référence produite
WSD
le temps nécessaire pour qu’un seul opérateur produit un seul faisceau électrique
WSD UOM
L’unité du WSD, Généralement par minute
ROB OUTPUT
Le nombre de faisceaux testés par le ROB
PACKAGING OUTPUT
Le nombre de faisceaux emballés
LINE
La ligne qui représente le numéro du banc
électrique utilisé dans la chaine d’assemblage concernée
RBDSBL1
Fichier de déclaration des cibles
Feuil 1Feuil 2
SHIFT, LINE, PRODUCTION DATE
Sont les mêmes figurants dans la première table, Déjà expliqués.
EFFICIENCY
L’efficience
EFF_HRS
Les heures produites
MAX_HRS
Les heures payées
HEAD COUNT
L’effectif
SHIFT, LINE, PRODUCTION DATE
Sont les mêmes figurants dans la première table, déjà expliqués.
OUTPUT_TARGET
Le nombre de faisceaux produits ciblé
HEADCOUNT_ L’effectif ciblé TARGET EFFICIENCY_ TARGET L’efficience ciblée Tableau 14 : Descriptif du modèle de données
59
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Qlik Sense identifie la date de production, le shift et la ligne comme étant des champs communs aux différentes tables afin de les associer et il les signale comme étant des clés synthétiques. Une fois les données chargées dans Qlik Sense, el les sont stockées dans l'application. L'analyse a toujours lieu lorsque l'application n'est pas directement connectée à ses sources de données. L'actualisation des données nécessite donc le rechar gement du script.
3. Modélisation des données Après avoir chargé les données dans l’application, nous avons commencé à y ajouter des visualisations afin de présenter les données de manière compréhensible pour les utilisateurs.
Cette partie présentera les étapes requises pour créer l’interface du tableau de bord composée d’une feuille, d’une dimension et des visualisations.
3.1.
Création d’une feuille
Notre application inclue une seule feuille représentant l’interface vide du tableau de bord. La feuille vide créée est représenté dans l’annexe 9.
3.2.
Création d’une dimension hiérarchique
Les utilisateurs ont besoin de consulter les indicateurs du premier Sprint par clients, projets,
chaines d’assemblage et équipe. Pour répondre à ce besoin, il fallait pour chaque indicateur quatre graphes, donc pour trois
indicateurs qui sont le nombre de faisceaux produits, l’effectif et l’efficience, il fallait deuze graphes.
Afin d’éviter la surcharge de l’interface, on a défini un groupe hiérarchique de champs comme dimension hiérarchique.
Lorsqu’un groupe hiérarchique est utilisé comme dimension dans un graphique, le graphique utilise le premier champ de la liste de champs du groupe qui compte plusieurs valeurs possibles. Si les sélections actives font que le champ n'a qu'une seule valeur possible, c'est le champ suivant de la liste qui est utilisé à la place, à condition qu'il ait plus d'une valeur possible. Si aucun champ de la liste ne compte plusieurs valeurs possibles, le dernier champ est utilisé à défaut. La dimension hiérarchique est désormais enregistrée dans la catégorie Dimensions parmi les éléments principaux, son aperçu affiche son type ainsi que les champs qu'elle inclut (voir figure 21). 60
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Figure 21 : Aperçu de la dimension hiérarchique créée
3.3.
Création des visualisations
3.3.1. Les volets de s filtres Pour contrôler les données affichées dans les visualisations de la feuille, on a créé des filtres permettant de filtrer simultanément les données des dimensions suivantes :
Semaine, date et shift de production.
Client, projet, chaine d’assemblage, équipe, groupe de produits, DPN et CPN.
L’image suivante illustre le filtre projet créé .
Figure 22 : Filtre projet
Il existe quatre états possibles pour les volets de filtre. Outre l’état sélectionné (en vert), les valeurs peuvent être définies sur l’état possible (en blanc), l’etat alternatif (en gris clair) et l’état exclu (en gris foncé). 61
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
A noter que les captures d’écran qui seront présenté es dans les parties suivantes, affichent les indicateurs de performance de l’équipe 46 de la chaine 2.3 L PETROL S55X durant le premier shift du 29/04/2016.
3.3.2. Graphiques Notre application contient deux graphiques combinés et un graphique en courbes. Le graphique combiné associe des barres et des lignes dans le même graphique, ils sont affichés pour chaque valeur de dimension. Leur longueur correspond à la valeur de leur mesure numérique. Les mesures sont les calculs utilisés dans les graphiques, représentés sur l'axe des ordonnées. Elles sont créées à partir d'une expression composée de fonctions d'agrégation.
Avg() renvoie la moyenne agrégée de l'expression ou du champ itéré(e) sur les dimensions du graphique. Sum() calcule le nombre total de valeurs fournies par l'expression ou le champ sur les données agrégées. Le premier graphe combiné est représenté sur la figure 23, utilise la dimension hiérarchique déjà créé et les mesures suivantes :
La somme des faisceaux testés par le ROB créée à partir de la fonction Sum([ROB OUTPUT]).
La somme des faisceaux emballés issue de l'expression Sum([PACKAGING OUTPUT]).
La somme des faisceaux ciblée créée à partir de la fonction Sum([OUTPUT_TARGET]).
Figure 23 : Affichage du nombre de faisceaux testés et emballés
Le deuxième graphe combiné est représenté sur la figure 24, il utilise aussi la dimension hiérarchique déjà créé et les mesures suivantes : 62
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
La moyenne d’efficience réelle créée à partir de la fonction Avg(EFFICIENCY).
La moyenne d’efficience ciblée issue de l'expression Avg(EFFICIENCY_TARGET).
Figure 24 : Affichage de l'efficience
Le graphique en courbes présenté sur la figure 25, utilise la dimension hiérarchique déjà créée et les mesures suivantes :
La Somme de l’effectif réelle créés à partir de la fonction Sum([HEAD COUNT]).
La somme de l’effectif ciblée issue de l'expression Sum(HEADCOUNT_TARGET).
Figure 25 : Affichage de l'effectif
Les résultats sont groupés au moyen de la dimension hiérarchique déjà créée. Dans notre cas, les chemins de navigation Client > Projet > chaine d’assemblage> équipe permettent de monter et descendre dans la hiérarchie. Le champ client est utilisé comme
dimension du graphique jusqu’à ce qu’un seul client soit sélectionné. Le graphique affiche ensuite projet. Si un seul projet est sélectionné, le graphique passe à la chaine d’assemblage puis à l’équipe. 63
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
3.3.3. Indicateur KPI Pour afficher la valeur des indicateurs des trois shifts ainsi que leurs totaux, on a eu recours à des visualisations de type indicateur de performance clé (Voir figure 26).
Figure 26 : Présentation des indicateurs par shift
3.3.4. Interface du tableau de bord La réunion de ces éléments donne l’interface du tableau de bord (voir figure ci-dessous).
Figure 27 : Aperçus de l'interface du tableau de bord
Les courbes rouges des objectifs ne sont pas visibles car nous avons inséré seulement les
objectifs de la chaine d’assemblage 2.3 L PETROL S55X. L’analyse des résultats sera présentée au niveau de la partie suivante. 64
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
VI. Revue et rétrospective du premier Sprint 1. Revue de Sprint Une revue de Sprint est tenue à la fin du Sprint pour inspecter l’incrément réalisé et adapter le Backlog du produit si nécessaire. Pendant cette réunion, nous avons échangé sur ce qui a été fait durant le Sprint. En se basant la dessus, nous avons détecté un problème de fiabilité des
données. En effet, au début de chaque shift l’opérateur insère une valeur erronée de l’effectif. Pour cela, nous avons proposé comme solution de réaliser une routine de sensibilisation hebdomadaire aux opéra teurs
de l’importance de cet indicateur et que l’information sera
contrôlée dorénavant. En outre, et pour éliminer ce problème définitivement, nous avons proposé comme perspective
d’exploiter la base de données du pointage tout en vérifiant l’affectation des opérateurs aux chaines
d’assemblage afin de récupérer automatiquement l’effectif sans aucune intervention
manuelle.
2. Rétrospective de Sprint La rétrospective de Sprint est survenue après la revue de Sprint et avant la prochaine réunion de planification. C’était l’occasion pour s’inspecter et créer un plan d’amélioration qui sera mis en place au cours du prochain Sprint. Le résultat de cette réunion était la décision de réduire la durée des prochains Sprints et le limiter à 3 semaines vue que nous avon s
assez d’expérience pour accélérer au niveau exécution et
déploiement de SCRUM.
VII. Conclusion Ce chapitre a présenté les étapes de l’application du modèle de développement en cascade utilisé pour l’exécution du premier Sprint. Plusieurs techniques ont été utilisées pour réussir l’itération commençant par le management visuelle basé sur le tableau SCRUM jusqu’au diagramme des cas d’utilisation. La réalisation du tableau de bord répondant aux besoins des utilisateurs été le fruit de travail avec la
d’un mois
collaboration de tous les membres de l’équipe.
L’application Qlik Sense réalisée permet de surveiller en temps réel le nombre de faisceaux emballés et testés, l’ effectif ainsi que l’efficience. 65
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Chapitre 4 : déroulement des Sprints 2 et 3
66
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
I.
Introduction
Directement après la clôture du premier Sprint, qui a livré une version potentielle ment utilisable du tableau de bord, le deuxième Sprint a commencé. Le troisième
n’a débuté qu’ après la
conclusion du précédent. Dans ce chapitre, nous allons combiner le déroulement des Sprint 2 et 3 dans le développement des phases de la Démarche DMAIC. Par la suite, nous allons terminer par un bilan récapitulant les gains, les contraintes ainsi que les perspectives de notre projet.
II.
Définir
1. Planification des Sprints De même que le premier Sprint, le travail à effectuer durant les Sprints 2 et 3 a été élaboré à la réunion de planification de chacun.
En tant que des Scrum Master, nous avons veillez à ce que l’événemen t ait lieu et que les membres de l’équipe en comprennent le but. En collaboration avec le propriétaire du produit nous avons décidé que les items à réaliser durant le deuxième Sprint sont :
En tant qu’utilisateur, je peux surveiller en temps réel le temps d’arrêt d’assemblage.
En tant qu’utilisateur, je peux surveiller en temps réel la réparation.
En outre, Les Items à réaliser durant le troisième Sprint sont :
En tant qu’utilisateur, je peux surveiller en temps réel le temps de première qualité .
En tant qu’utilisateur, je peux surveiller en temps réel le temps cycle .
Pour mener au bon déroulement des Sprints, des plannings en été réalisés (voir figures 28 et 29).
Figure 28 : Planning de Sprint 2
67
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Figure 29 : Planification de Sprint 3
Une fois l’objectif est fixé et le planning réalisé, nous avons élaboré le Back log de Sprint avec l’estimation des heures de travail nécessaires pour chaque tache ainsi que le volontaire y concerné (Voir tableaux 15 et 16).
Items
Priorité
Taches du Sprint
Volontaire
En tant qu’utilisateur, je
Mesurer
Hassan & Oumaima
peux surveiller en temps
Analyser
Hassan & Oumaima
Innover
Hassan & Oumaima & Michael
Contrôler
Team
Mesurer
Hassan & Oumaima
Analyser
Hassan & Oumaima
Innover
Hassan & Oumaima & Michael
Contrôler
Team
réel le temps d’arrêt d’assemblage.
1
En tant qu’utilisateur, je peux surveiller en temps réel la réparation.
2
Effort initial estimé
Tableau 15 : Backlog de Sprint 2
Items
Priorité
En tant qu’utilisateur, je peux surveiller en temps réel le temps de première qualité
1
En tant qu’utilisateur, je peux surveiller en temps réel le temps cycle
2
Taches du Sprint
Volontaire
Mesurer
Hassan & Oumaima
Analyser
Hassan & Oumaima
Innover
Hassan & Oumaima & Michael
Contrôler
Team
Mesurer
Hassan & Oumaima
Analyser
Hassan & Oumaima
Innover
Hassan & Oumaima & Michael
Contrôler
Team
Tableau 16 : Backlog de Sprint 3
68
Effort initial estimé
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
2. Mêlée quotidienne La mêlée quotidienne est un événement limité à 15 minutes, que nous réalisons généralement au début de chaque journée pour créer un plan pour les prochaines 8 heures. Nous avons utilisé
cette réunion comme outil pour inspecter notre progression vers l’objectif
de chaque Sprint et l’achèvement du travail prévu. Les mêlées quotidiennes
réalisées nous ont permis d’améliorer la communication au sein de
l’équipe, de révéler les obstacles et les supprimer, chose qui nous a encouragés pour la prise de décision rapide.
3. Graphique d’avancement Chaque jour dans la mêlée quotidienne, nous actualisons nos estimations du reste à faire pour les taches en cours du Backlog de Sprint. Par la suite nous additionnons les efforts restants
pour l’ensemble de l’équipe, et nous le traçons sur le graphique d’avancement. Ce dernier montre, chaque jour, une nouvelle estimation du reste à faire pour terminer les taches. Ce
graphique se présente idéalement sous la forme d’une courbe inclinée vers le bas, suivant une trajectoire visant à atteindre « zéro effort restant » le dernier jour du Sprint. Les graphiques d’avancement des Sprints 2 et 3
sont présentés dans l’annexe 10.
En réalité, la trajectoire était parfois bonne, parfois moins. Dans le cas où la courbe
n’a pas
suivi l’inclinaison nécessaire pour l’achèvement des travaux à l’approche de la fin du Sprint , il
fallait s’adapter et récupérer le retard. Pour ce faire, il y’avait deux possibilité, soit , rester à DPT jusqu’au 22h pour terminer les travaux ou travailler le weekend. A noter que durant chaque Sprint, le graphique d’avancement est affiché sous for mat papier sur le tableau SCRUM réalisé (voir figure 15). Les mises à jour sont réalisées au feutre.
III. Mesurer et Analyser Au niveau de cette partie, nous allons évoquer la mesure
et l’analyse de tous les indicateurs
manipulés tout au long des Sprints 2 et 3.
1. Temps d’arrêt d’assemblage Le temps d’arrêt de la chaine d’assemblage est calculé actuellement par un compteur numérique lié au variateur de vitesse de la chaine. Ce système s’actualise automatiquement au début de chaque shift sans laisser aucune traçabilité de la valeur calculée. 69
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Le temps d’arrêt est catégorisé selon le département y responsable, à savoir, la maintenance, la coupe, la logistique ou les autres départements. Pour cela, le contremaitre de chaque chaine d’assemblage enregistre manuellement la valeur du
temps d’arrêt estimée, à l’aide du compteur numérique, dans les cartes de productions soulignées auparavant.
2. La réparation La réparation représente le nombre de faisceaux électriques réparés. En cas de détection de défaut, le faisceau est identifié par un auto-refus : une étiquette rouge, et
envoyé par la suite au poste de réparation. L’opérateur de réparation, qualifié par le département qualité, assure manuellement la traçabilité sur un registre des autos-refus, et utilise les outils définis de réparation pour réparer le défaut concerné. Les faisceaux nécessitants une réparation sont généralement détectés au poste du test électrique,
à la contention ou à l’emballage.
3. Le temps de première qualité (FTQ) Le FTQ est rapporté en nombre de défauts par million de défaut (partie par million). Il projette
le nombre en ppm des défauts sur un lot, et reflète l’image du processus de fabrication et sa capacité à fabriquer bon du premier coup. Les défauts r épétitifs
en FTQ présentent un risque potentiel d’un prochain incident qualité.
Alors, Il permet de surveiller la stabilité du processus et réagir rapidement aux dérives
potentielles. C’est un outil d’amélioration continue de la qualité. Le calcul du FTQ est définit comme suit :
FTQ = (Nombre de faisceaux rejetés / Nombre de faisceaux vérifiés) × 1000000 Le total des faisceaux produits inclus à la fois les faisceaux conformes et les faisceaux rejetés. Les faisceaux rejetés incluent les faisceaux rebutés et réparés avant la livraison au client.
Le FTQ collecte l’ensemble des défauts enregistrés en prise des données à n’importe quelle étape du processus de production où le faisceau a été rejeté.
70
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
4. Le temps de cycle Le temps de cycle de production réel est le temps qui a été accordé à chaque poste de travail
pour l’achèvement d’un ensemble de taches. Autrement dit, c’est l’intervalle de temps d’acquisition d’un faisceau électrique.
Temps de cycle = (460 / Nombre de faisceaux produits par shift) 460 : Temps, en minutes, travaillé par shift (8h-20min de la pause).
IV. Innover Cette phase présente un ensemble de solutions proposées, et actions entreprises pour améliorer
l’acquisition des indicateurs .
1. Suivi du temps d’arrêt d’assemblage La solution proposée est une application
de contrôle de temps d’arrêt réalisée avec le logiciel
LabVIEW. La figure 30 ci-dessous représente la face-avant de l’applicat ion réalisée.
Figure 30 : La face avant de l’application calculant le temps d’arrêt
L’objectif principal de l’application est de calculer le temps d’arrêt causé par la maintenance, la logistique, la coupe, ainsi que les autres départements.
Nous présentons dans l’annexe 11 l’image écran de la fenêtre diagramme, ainsi qu’un descriptif détaillé du VI réalisé. 71
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Après la simulation de l’application, le résultat était validé par le propri étaire de produit. L’étape suivante était de déterminer le matériel nécessaire pour l’acquisition des données. Pour cela, nous avons contacté le service Process qui nous a donné une carte d’acquisition, les détails
de cette dernières sont présentés dans l’annexe 12. Pour la tester, nous avons contacté, M. Benaissa Amami, enseignant à la faculté des Sciences et Techniques de Tanger. Le résultat du test était positif mais pour programmer la carte, une adresse de base était nécessaire.
2. Suivi de la réparation Les faisceaux réparés sont testés électriquement pour la deuxième fois en utilisant un manifest quelconque à condition qu’il soit de même référence. Or, ALS, ne fait pas la déférence entre la réparation et les faisceaux Scannés pour la première fois et calcule le total comme étant le nombre de faisceaux testés par le ROB. La solution proposée consiste à rendre ALS capable de collecter le nombre de faisceaux réparés
et le faire afficher sur l’application du test électrique
qui va communiquer le résultat à la base de données ALS ainsi que notre tableau de bord.
L’idée est la suivante : Si un faisceau passe par le test électrique et signal un problème, il sera envoyé au poste de réparation puis il sera testé par le ROB encore une fois. A cette étape le manifest sera scanné pour la deuxième fois et le compteur « Réparation » s’incrémente. Cette solution nécessite que chaque faisceau soit identifié par un seul manifest jusqu’au poste
d’emballage, chose n’existant pas actuellement. En effet, le manifest n’ est pas respecté, il est jeté au poste de test électrique et il a un très grand risque d’être endommagé. Or, si ce risque aura lieu, la production sera bloquée.
Pour éviter l’endommagement du manifest, nous avons proposé de le faire tourner sur le faisceau produit et le fixer par le ruban tissus
d’une façon à laisser le code barre visible pour le
scan. A noter que cette idée a été propos ée
sans savoir qu’elle est déjà appliquée au niveau de
quelques familles. Chose qu’il l’a validée. Pour tester la solution proposée, nous avons modifié la configuration des entrées de la base de
données ALS après l’approb ation des managers des services production et IT. Une fois le manifest du faisceau réparé est scanné pour la deuxième fois, un message s’affiche indiquant à l’opérateur que le présent manifest est déjà scanné. Pour autoriser le deuxième scan l’opérateur doit sélectionner « allow RE-TEST of OPS-ID » (voir figure 31).
72
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Figure 31 : Message affiché après le scan d'un manifest déjà scanné
Après l’accomplissement du deuxième test, la valeur du « second test » s’incrémente, or que le nombre de faisceaux produits c.-à-d. testés pour la première fois reste le même (voir figures 32).
Figure 32 : Interface de l’application du test électrique avant et après le test d’un faisceau réparé
3. Suivi du temps de première qualité Nous avons proposé comme plan d’action de maitriser le
FTQ du ROB. La solution consiste à
afficher, une liste prédéfinie de tous les défauts qui peuvent se détectés au niveau du teste
électrique et inviter l’opérateur à insérer, en cas d’apparition des défauts, les informations suivantes.
« Type » : le type de défaut détecté qui peut êtr e soit visuel, électrique ou Spécial.
« Error code » : le code du composant défectueux.
« Défect » : le type de défaut.
La figure 33 de la page suivante présente l’interface développée incluant la liste des défauts.
73
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
Figure 33 : Interface de sélection des défauts
Une fois le défaut sélectionné, la valeur de « errors per shift » s’incrémente (voir figure 34 ).
Figure 34 : Incrémentation du nombre de défauts par shift
74
MONITORING ET AMELIORATION DE LA PERFORMANCE DES LIGNES D’ASSEMBLAGE
4. Suivi du temps de cycle Comme signalé auparavant, le temps de cycle représente le rapport entre 460, qui représente le temps (en minutes) travaillé par shift, et le nombre de faisceaux produit par shift. Or, ce dernier est disponible dans le tableau de bord que nous avons réalisé dans le premier Sprint. La solution proposée consiste à ajouter une nouvelle feuille dans l ’application
Qlik Sense
réalisée et créer un indicateur affichant le temps de cycle réel.
L’expression de la mesure utilisé e pour afficher le temps de cycle de shift 1 est représentée dans la figure 35 ci-dessous.
Figure 35 : Expression de calcul du temps de cycle de shift 1
De la même façon, nous avons créé les mesures des temps de cycle des shifts 2 et 3. La figure 36 ci-dessous représente la feuille créée pour le calcul du temps de cycle par shift.
Figure 36 : Affichage du temps de cycle par shift
Pour que les données affichées tout au long de ce présent rapport restent cohérentes. Nous avons utilisé les mêmes filtres des visualisations présentés au chapitre précédent. Les valeurs, affichées sur la figure ci-dessus, sont propres à la chaine 2.3 L PETROL S55X durant le premier shift du 29/04/2016.
V.
Contrôler
Afin de contrôler et évaluer les résultats de la phase précédente dans le cadre de SCRUM, deux réunions ont été tenus à la fin de chaque Sprint :
75