Introduction Faurecia - >>> CREX · Faurecia Lean Office - Compta – Arts et Métiers - Mars 07...

Technical perfection, automotive passion.

Introduction Faurecia

Catherine Chabiron

Marie-Pierre Callaud

2 Faurecia Lean Office - Compta – Arts et Métiers - Mars 07

Qui est Faurecia ?

Equipementier automobile (2ème européen, 9ème mondial)

6 modules : siège, planche de bord, porte, module

acoustique, bloc avant et échappement

60 000 collaborateurs, 180+ sites industriels, 28 pays

28 centres de R&D et de D&D

CA 12 Mds € : 81 % en Europe mais développement en

Amérique du Nord, du Sud, et en Asie


Qui est Faurecia ?

Panneaux de porte

Planche de bord / Cockpit

Bloc avant

Sièges

Echappement

Module acoustique

Panneaux de porte n°1 en Europe n°1 monde

Planche de bord / Cockpit n°1 en Europe n°1 monde

Bloc avant n°1 en Europe n°2 monde

Sièges n°2 in Europe n°3 worldwide

Echappement n°1 en Europe n°1 monde

Module acoustique n°3 en Europe


Introduction au Lean

Faurecia

Marie-Pierre Callaud - Mars 07


PE

OP

LE

JID

OK

A

JU

ST

E A

TE

MP

S

STANDARDS DE TRAVAIL

KAIZEN

CUSTOMER

SATISFACTION


PE

OP

LE

JID

OK

A

JU

ST

E A

TE

MP

S


KAIZEN

CUSTOMER

SATISFACTION Séquence d’opérations à

réaliser dans l’ordre,

sans gaspillage (muda)

et dans un temps donné

(Takt-time)


PE

OP

LE

JID

OK

A

JU

ST

E A

TE

MP

S


KAIZEN

CUSTOMER

SATISFACTION Amélioration continue,

élimination des

gaspillages


PE

OP

LE

JID

OK

A

JU

ST

E A

TE

MP

S


KAIZEN

CUSTOMER

SATISFACTION

Flux tirés, continu

et au takt time

Arrêt au premier défaut,

arrêter de produire des

rebuts


PE

OP

LE

JID

OK

A

JU

ST

E A

TE

MP

S


KAIZEN

CUSTOMER

SATISFACTION Implication et

développement

du personnel


PE

OP

LE

JID

OK

A

JU

ST

E A

TE

MP

S


KAIZEN

CUSTOMER

SATISFACTION

Objectifs

Qualité, coût et délai


Lean

Un état d’esprit

Quelques outils très simples

Pour la satisfaction du client

En impliquant les opérateurs


Lean Office – comptabilités

Fournisseurs

Faurecia

Marie Pierre Callaud – Faurecia – Mars 07


Pourquoi du lean dans les bureaux ?

Faurecia bénéficie d'une solide expérience du lean

manufacturing dans ses usines

L'extension aux centres de développement et aux

fonctions support était donc logique et a été mise en

place entre 2003 et 2004


Nous avons commencé par les comptabilités

fournisseurs :

Les tâches y sont répétitives et quotidiennes et le

traitement des factures reçues s'apparente à une usine

fabriquant des bons à payer.

La comptabilité fournisseurs se situe en bout de chaîne,

puisqu'elle est l'aboutissement d'un processus d'achats.

– Partir du traitement aval pour identifier les problèmes

– puis remonter toutes les étapes amont pour les résoudre et ainsi

optimiser les flux d'informations.


Les tâches à valeur ajoutée ne dépassent

pas 10 à 20 % du total

900 à 1000 factures par comptable et par mois

= 8 mn par facture (si on exclut 2 jours de clotûre comptable)

Saisie right first time = 1 mn en moyenne

Tri et archivage = 2 mn max

Temps restant (5 mn) = retouches (gestion du Not Right First Time) et

validations

Soit 7 mn sur 8 sans valeur ajoutée

total

saisie

temps

Tri, classement,

retouches,

validations


Nous avons donc attaqué ces 80 à 90 % de tâches

sans valeur ajoutée :

Deux exemples parmi d'autres pour illustrer le propos :

Une équipe comptable a amélioré sa productivité de 15 % en 8 mois en faisant descendre son taux de NRFT de 22 à 14 %, tout en diminuant de 30 % son stock de factures non traités (gestion des files d'attente).

Une autre équipe a augmenté sa productivité de 30 % en 10 mois en éliminant des tâches inutiles et en améliorant la qualité des informations amont pour les déclarations de TVA et intrastat.


Quels outils utilisons-nous ?

Identification des gaspillages :

– Analyses de déroulement des flux d'infos ou de documents

– Flow mapping

– Spaghetti charts

– 5S

Maitrise des retouches :

– Mise en oeuvre d'outils de management visuel

– Mesure du not right first time et typologie des incidents

– Analyse détaillée des causes d'incidents

Standards de travail


Avant de commencer, il faut identifier le client

Comprendre, avec l'ensemble de l'équipe, qui sont les clients,

qu'est ce qu'ils attendent et pour quand ?

– Comptas fournisseurs : fournisseurs (être payés le montant prévu à

l'échéance) et contrôleurs (qualité des comptes et provisions en fin de

mois)

– Paie : employés (être payés sans erreur et à la date prévue), banques

(avoir toutes les données de virements à temps et complètes en fin de

mois), contrôleurs (qualité des comptes et provisions en fin de mois)

– Achats : émetteurs de la demande (demande transformée en commande

rapidement), patrons d'usine (avoir les meilleurs prix, pouvoir contrôler les

coûts, des fournisseurs de qualité ne venant pas perturber la production) etc

…


Analyse de chaque étape d'un

process en identifiant le type

d'opération :

– opération,

– attente,

– déplacement,

– contrôle,

– archivage

Mesure également du temps,

des déplacements en mètres,

de la fréquence etc …

Première étape : identifier les gaspillages



Le process est alors

dessiné, avec

identification des

gaspillages (le plus

souvent : opérations

inutiles et

retouches)


Le spaghetti chart

vient étayer la

description du

process actuel et

facilite

l'identification des

déplacements

inutiles



Priorité : quick wins

Avant d'attaquer les problèmes plus complexes, on va chercher à

corriger ce qui peut l'être par décision rapide au sein de l'équipe en

charge du process :

– Sur-contrôles

– Déplacements inutiles

– Formulaires obsolètes ou redondants

– Double saisies

– Opérations d'archivage inutiles

– Photocopies inutiles …

Objectif : ouvrir les yeux de l'équipe sur les gaspillages dans le

process et la convaincre de l'intérêt de la méthode


Etape suivante : les retouches

Prenons notre exemple de comptabilité fournisseurs :

– Une facture fournisseurs est rapprochée des données de

commandes et de réception et comptabilisée en 3 mn en

moyenne

– Une facture en retouche (écart de prix, pas de réception, écart

de quantité …) va représenter un traitement moyen de 18 mn

– Si on arrive à faire passer le taux de retouches de 30 % à 10 %,

on peut gagner 40 % de productivité sur le temps du

comptable !



Il faut d'abord apprendre à repérer la retouche en :

– La visualisant (bac rouge)

– L'isolant du flux (on la traitera après la saisie) :

Before :

Pb

Pb

Pb

To do Done

To do Done

To do Done

After :

Bac rouge

Bac rouge

Bac rouge

To do

To do

To do



On peut alors mesurer le taux de Not Right First Time :



Interco reconciliation issues

0%

5%

10%

15%

20%

25%

Litig

ation

on m

inor

%

of in

voic

e

Wro

ng

BA

U

Late

decla

ration

No d

eta

ils

No

answ

er,

no

decla

ration

Litig

ation

on d

ue

date

wro

ng

price

No p

rior

agre

em

ent

late

invoic

e

On prioritise par le biais d'un pareto :



On cherche à comprendre quels sont les facteurs (root causes)

dominants

Et on analyse sur ces facteurs dominants les 5 pourquoi.

Error in

cost center

Error in

Legal entity

No

cost center

Problem

AMEX

invoicing error

Why Why Why

Requester

not aware of

consequences

Why

FAURECIA

requester

mistake

on ETO

Old and

unclear

ETO used

FAURECIA

requester

uses an

old version

ETO cost center

truncated

(field only

takes numeric)

AMEX build

its ETO

like this

FAURECIA

did not

request

alpha-numeric

field

Accounting

reworks

all errors

never informs

requesters

Nobody has

tried to

determine

root causes

Accounting

identifies

it as its task

90%

10%

Intranet not

systematically

used

AMEX accepts

old versions

No systematic

analysis on

cost center

& project n°

specifications

Root causes

addressed

in action plan



Chaque résolution de problème est suivie :


Mais on travaille aussi les files d'attente

On identifie les flux simples :

– Des postes sont dédiés à la saisie simple, avec file unique

– D'autres aux retouches du bac rouge et aux saisies complexes

Gain : diminution des stocks de documents non traités

Before :

Pb

Pb

Pb

To do Done

To do Done

To do Done

After :

Pb

Simple

Complex

Bac rouge

Bac rouge


Et les standards de travail

Le standard de travail a pour but essentiel de repérer la séquence de travail la plus efficace (telle qu'elle est identifiée à l'instant t)

Le standard peut porter sur :

– L'organisation de la journée de travail

– Une tâche précise

– La gestion d'un litige ou d'un problème

Le standard se fait à partir d'une observation et d'une discussion avec les opérateurs

Le standard devient le pivot :

– Tout problème commence à être analysé comme un écart au standard (ou une absence de standard)

– Les idées d'amélioration portent sur l'optimisation du standard


Clé du succès : impliquer les opérateurs

Tout ce qui précède est fait sur le terrain avec les opérateurs du

process

L'amélioration de l'efficacité de l'équipe et de la qualité du process ne

peut se faire que par le biais d'un travail d'amélioration continue

D'où la mise en place

dans chaque équipe

d'un kit d'outils :

– Indicateurs QCD

– Idées d'amélioration

– Top 5 quotidien

– Outils de résolution de

problèmes …


Clés du succès

Implication du management et des opérateurs

Identification des causes du not right first time et

correction du process amont à l'origine des retouches

Capacité à identifier et mettre en oeuvre les quick wins :

– un rapport supplémentaire,

– la meilleure utilisation d'un outil,

– une simplification du process ou des contrôles


Conclusion


Le challenge du lean dans l'administratif

Améliorer le taux de "right first time"

Et, une fois qu'on l'a fait, définir comment on peut le faire

avec une personne en moins


Lean Office - Systèmes

d'Information

Faurecia

Catherine Chabiron - March 07

36 36 36 Faurecia Lean Office - SI – Arts et Métiers – Mars 07

Que nous disent les clients de

l'informatique ?


analyse des tâches informatiques importantes et leur ranking en terme

de valeur ajoutée utilisateur (*)

gauche : faible valeur ajoutée -> droite : forte valeur ajoutée

Support et Opérations et valeur

ajoutée

Tâches informatiques Valeur ajoutée

client (utilisateur)

Support to end users

Workstation set-up & support

Training

Operations, network

Virus, patch management

Maintenance

Projects

Data recovery

Reporting

External customer interface

Purchasing

Documentation

Inventory of assets

NB : cela dépend des projets

On découvre

que des tâches

IT essentielles

n'ont aucune

valeur ajoutée

pour le client :

il faut donc

qu'elles soient

très efficaces

(*) analyse faite par la communauté informatique


quelles sont les attentes des utilisateurs (par ordre d'importance) (*) ?

Customer satisfaction survey

0%

5%

10%

15%

20%

25%

training support in

system

use

availability

of support

time to

deliver

solution

time to

start w ork

on issue

feedback integration quality

(*) worldwide customer satisfaction survey launched end 06


l'infrastructure informatique et sa gestion sont aussi essentielles et

évidentes que la fourniture en eau ou en électricité : pas de droit à

l'erreur ni à l'inefficacité

les projets doivent apporter une véritable valeur ajoutée pour

entraîner l'adhésion (quel est le problème que je cherche à résoudre

ou la valeur ajoutée que je cherche à capturer ?)

les interfaces avec les utilisateurs doivent être particulièrement

travaillées pour accroître la crédibilité informatique :

– démarrage de projets

– formation

– support à une meilleure utilisation du système

– réactivité et solutions de qualité pour toute demande d'évolution

Premiers enseignements


Eliminer les gaspillages dans les projets

informatiques


Gaspillages dans les projets informatiques

Gaspillages dans les projets SI selon Mary Poppendieck* :

– Travail partiellement fait (partially done work)

– Processus inutiles (extra processes)

– Développements ou fonctionnalités inutiles (extra features)

– Passer d'un projet à l'autre (task switching)

– Attentes (waiting)

– Déplacements (motion)

– Défauts, retouches (defects)

* Lean Software Development – an agile toolkit by Mary and Tom Poppendieck



Quelques exemples réels :

– Temps d'écoulement 7 mois

– Temps d'exécution 4 à 5 mois

– Temps de valeur ajoutée (design, développement, formation) 3 mois

Gaspillages :

•attente

budget,

•attente test et

validation

utilisateurs



Quelques exemples réels (suite) :


– Temps d'exécution 12 mois

– Temps valeur ajoutée (design, développement, formation) 8 mois

Gaspillages :

•attente

information sur

besoin,

•attente

approbation

formelle,

•attente

données

utlisateurs et

tests



Quelques exemples réels (suite) :


– Temps d'exécution 5 mois

– Temps valeur ajoutée (design, développement, formation) 1.5 months

Gaspillages :

•Trop de temps perdu sur

budget (contraintes

ressources)

•1 mois perdu du fait du

fournisseur (pas de ressources

disponibles)

•Pas de chef de projet dédié

Valeur ajoutée


Petite typologie de projets et de problèmes

Projet fonctionnel :

– un besoin fonctionnel est identifié et lancé avec enthousiasme avec un

prestataire de services sans vraiment associer l'informatique

Gaspillages :

– expertise technique insuffisante ou mal encadrée pouvant déboucher

sur des pertes significatives ou des projets avortés,

– dépendance totale vis à vis des livreurs / éditeurs de la solution,

– formation utilisateurs insuffisante car besoin sous-estimé

– support et maintenance non gérés / négociés : pas de support ou

support tardif et onéreux

– fonctionnalités inutiles

– redondances avec solutions existantes (pas de recherche préalable sur

solutions existantes ni de saturation de la capacité existante)


Petite typologie de projets et de problèmes

Projet informatique :

– une hétérogénéité de systèmes et de solutions est identifiée sur une même fonction et on se lance dans une standardisation pour réduire les coûts de support

Gaspillages :

– standardisations de solutions sans arbitrage fonctionnel (on cherche à réduire le coût des opérations et du support en éliminant les solutions customisées ou les spécifiques)

– on ne livre pas la solution répondant au besoin du client,

– fonctions hésitantes à approuver le budget,

– key users non disponibles

– formation utilisateurs insuffisante

– projets qui s'éternisent faute d'enthousiasme des clients (démarrages retardés pour diverses raisons …)


Améliorer la situation

7 grandes zones de gaspillages reconnues dans les projets

Pour chaque zone, et pour chaque jalon important de projet (gate

reviews), une série de questions ouvertes

Le chef de projet fait une évaluation en amont de chaque grand

jalon, avec son équipe (implication des opérateurs)

Ce n'est pas un modèle de décision mathématique mais

l'opportunité d'exercer son meilleur jugement sur les zones de

gaspillages et les actions correctrices à prendre


7 grandes zones de gaspillages

Fonctions à bord

– Les sponsors & utilisateurs supportent-ils la solution ?

– Sont-ils régulièrement impliqués dans la construction de la solution ?

– Jouent-ils leur rôle dans le déploiement (tests, formation) ?

– Les key users sont-ils disponibles ?

Adapter la solution au besoin

– Quel est le problème qu'on cherche à résoudre ?

– Est ce que nous sommes en train de bâtir la bonne solution ?

– Couvre : Périmètre / Technologie / Software / Fonctionnalités



Contrôler les ressources

– Les ressources (budget, personnes) sont-elles appropriées, disponibles et contrôlées ?

– Recouvre (yc motivation et expertise) :

équipe projet,

contractants,

key users,

éditeurs de la solution,

intégrateurs …

– Mesurons-nous notre performance (temps, coûts, qualité) ?



Gérer les risques applicatifs

– Avons-nous évalué les risques de l'application quand elle sera en production ? Avons-nous construit les moyens de réduire ces risques?

– Couvre : Accès / Confidentialité / Disponibilité / Protection des données ..

Prêts pour le démarrage ?

– Organisons-nous correctement la validation & les tests utilisateurs ?

– Les utilisateurs sont-ils disponibles pour ce faire ?

– Notre approche de tests est-elle efficace ?

non regression, integration, tests de charge, user acceptance

mais aussi le lissage de l'effort (petits lots, prototypage)

design develop test

Change requests

Launch



Transfert

– Avons-nous correctement transféré l'application aux utilisateurs (formation, documentation) ?

– Avons-nous correctement transféré l'application au support et aux opérations

Fermer le projet et capitaliser

– Quelles sont les conditions pour fermer un projet ?

– Quelle est la liste des problèmes non résolus ?

– Les utilisateurs / le propriétaire de l'application sont ils prêts à prendre le relais ?

– Le support et les opérations sont-ils prêts à prendre le relais ?

– Partageons-nous les leçons de ce projet ? Comment ?


Gate

Review

2a

Gate

Review

2b

Gate

Review

3

Gate

Review

4

Gate

Review

1

IT Project framework

Gap Analysis

(Current vs Target

Processes)

Kick-Off

Design

Target Application

Prototype, Build & Unit Tests

Develop add-ons

& interfaces

Design Technical

Architecture

Closing

INITIATION

1 ANALYSIS

& DESIGN

2a PRODUCTION

SET-UP

& TRAINING

3 LAUNCH

4 5 SUPPORT PRODUCTION

BUILD &

TEST

2b

Data migration &

non-regression tests

Monitor

Open Points

User acceptance

Tests

Go Live

Communication

Production Set-Up

User Trainings

Post Go-Live

support

Training &

Change Requests

Support &

Operate

Go /

No-Go

Integration

Tests

Monitor KPIs (Business, SLA)

Challenge

IT solutions

& negociate

contracts

Develop

CAR

Define Project

Organization

Define

Business needs

Develop

SOW

SOP


Check lists pour les gate reviews

Key Project Risks List of Questions assessmen

t

Adapt solution to

need

If GR1 assessment was negative, have we clarified the situation ?

Adapt solution to

need

Are the functional specifications clear enough to launch the application set-up in phase 2b ?

Adapt solution to

need

At this stage, can we confirm that the KPIs for the application that have been defined at GR1 to monitor

business process and performance when in production, wil l indeed show an improvement in the

performance ? Examples : inventory reduction, unbil led delivery reduction, headcount reduction, month

end close time reduction

Adapt solution to

need

Has the proposed solution been screened in terms of FCP compliance by the functional sponsors and /

or key users ? Is it compliant ?

Adapt solution to

need

Has the IRR calculation (or the costs vs benefits analysis) been revised and updated ?

Adapt solution to

need

If global assessment negative, escalate to IT and functional management : it may stil l be time to stop

the project

Control Resources Do we have the right number of internal and external resources to cope with the workload ? Are we

efficient enough ?

Control Resources What is the situation of the actual costs vs budget ? Is it closely monitored, including the time tracking ?

Control Resources Have the contracts with the external service providers finally been reviewed and signed?

Control Resources Are external consultants and team members tracking their time on the time tracking tool, in order to

control al l the project costs ?

Control Resources Do we have some team members (internal or external) that are clearly not on board or competent to

build and launch the solution ? If yes, what actions have been taken ?

Control Resources If global assessment negative, take immediate action (corrective action plan). Freeze the project if the

contract with third parties has not been signed.

Functions on Board If GR1 assessment was negative, have we solved the problem ?

Functions on Board Are the key users available and on board ?

Functions on Board Is the team organised by functional area to animate a network of key users on that area ? Objective for

each section is to find a way to propose, deliver, review prototypes, challenge and test very regularly

with the impacted key users throughout the build and test period.

Functions on board Is the steering committee in place and regularly updated of the project progress ? Does the steering

committee arbitrate the change requests ?

Functions on Board Are the sponsors available and supporting the project ?

Functions on Board If global assessment negative, escalate to IT and functional management : it may stil l be time to stop

the project

Handover At this stage, have we secured resources from IT operations to build the infrastructure both for

development and production ?

Handover If answer is no, take immediate action

Manage Risks Are the risks identified for the application when in production periodically monitored and included in the

solution design ? Security, confidential ity, availabil ity, back up needs, archiving ...

Manage Risks Will the codification of master data be changed ? What wil l be its impact in production ?

Manage Risks Do we have a global vision of the data flows ? Are the interfaces between the different functional areas

correctly identified and covered ?

Manage Risks Have we started to identify the required access profiles taking into account security, confidential ity,

segregation of duties ?

Manage Risks If global assessment negative, take immediate action to identify top 3 risks of the application, when in

production, and include the solution in the design of the application. Address other risks via an action

plan.

OK for Launch Will the business scenarios be delivered in time for the tests by key users and / or functions ?

OK for Launch Is the development and test environment available?

OK for Launch Is the test plan appropriately defined according to the solution being developed (at minimum non

regression, integrated testing including interfaces with other systems, and unit testing, if possible user

testing, load testing, data migration testing …) ?

OK for Launch If global assessment negative, take immediate action to organize the tests and developement and test

environments

Zones de

gaspillages Action

recommandée

si évaluation

globale de la zone

est <0

Evaluation

du projet


Améliorer l'efficacité du support et des

opérations en améliorant la technique de

résolution de problèmes


ITIL par exemple

montre comment passer d'un

problème générique, récurrent, à

une contre-mesure générique

En éliminant la cause

racine, on peut décroître la

charge de support

mais ITIL n'explique pas

comment trouver la cause racine

Que nous disent les standards

informatiques ?


video

Les techniques de résolution de

problèmes ont été développées en usine


On commence par :

– Une mesure du problème

– Ou une analyse des incidents récurrents

Il est également recommandé de faire un mapping des flux de

données et des systèmes en place :

– Cela permet de partager la même compréhension du process

– Cela permet d'identifier les entrées et sorties de données

– Et de commencer à repérer où les incidents peuvent être générés

Approche QRQC


Exemple :

Final

replication

of PCC

on Score

PC

Plant

buyers

PCC

Nanterre

1

2

4

Application

owner

Import on

local server

Replication

Control

5

Agregation

6

Alert

Score team

Score

team

7

8 Export to

Datawarehouse

and reporting

FTP server

PCC on local

servers

7

3 Export to

FTP server Replication of

PCC data

before

agregation

on Score PC

13:00 (1) 18:00 (1)

(1) Nanterre time, if everything is right first time

17:00 (1) 19:00 (1) 21:00 (1)


– Description du problème (is / is not)

– Produits ou Processus qui pourraient être impactés

– Mesures de sécurisation immédiates

– Identification des facteurs d'occurrence et de non détection par

rapport à un standard :

Réalité O, standard X

Réalité X, standard O

Réalité X, standard X

– Validation ou élimination de ces facteurs

– 5 pourquoi sur les facteurs validés

– Plan d'actions correctives sur cause(s) racine

– Capitalisation (lessons learned)

Approche systématique de type 8D


Lieu de travail réel

– Où et quand c'est arrivé

Pièces réelles (= transactions réelles, écrans en informatique)

– Quel est le défaut ? Comparer bon et mauvais

Données réelles

– Pas de devinette, de bla bla bla

– Discuter avec les données réelles comparées au standard

Les 6 points clés du QRQC


Réponse rapide

– Répondre rapidement, protéger le client d'abord

Approche logique

– Quel est le problème ?

– Quelles sont les causes ?

– Quelles sont les contre-mesures ?

– Comment empêcher que cela ne se reproduise ?

Coaching sur le terrain

– Gérer

– Former

– Supporter

– Reconnaître

Les 6 points clés du QRQC


> Access through Faurecia intranet

8D – problem solving report for Quality

D1. Description & Sketch _

D2. Risk on similar products and

processes

_

D3. Containment In 1 day

D4. Root cause of non detection _

D5. Root cause of non conformance _

D6. Countermeasure to non detection and

non conformance

In 10 working days

D7. Effectiveness of action plan _

D8. Lessons learned In 60 working days

Combien de temps cela doit prendre ?

Standard usines :

Informatique : à confirmer

Date post:	23-Apr-2018
Category:	Documents
Upload:	lamdien
View:	222 times
Download:	1 times

Introduction Faurecia - >>> CREX · Faurecia Lean Office - Compta – Arts et Métiers - Mars 07...

Documents