Disponibilité sur la Value Stream Map : Uptime, Availability ou OEE dans la case ?
Points clés
- Inscrivez la Availability mesurée dans la case uptime : temps de fonctionnement divisé par le temps de production planifié, sur des vraies équipes.
- Ajoutez l'OEE dans la boîte de données et utilisez-la pour la vérification de capacité par rapport au takt time.
- L'uptime seul masque la lenteur, les arrêts courts et les rejets, donc la carte montre une capacité que la ligne n'a pas.
- Dans l'exemple, l'uptime de mémoire montrait que le doseur était 20% au-dessus de la demande. L'OEE a montré qu'il manquait 2 160 bouteilles par équipe.
- Le choix peut déplacer le goulot d'étranglement, et avec lui chaque kaizen burst sur la carte de l'état futur.
Inscrivez la Availability mesurée dans la case uptime d'une value stream map, et ajoutez l'OEE à côté. Puis vérifiez chaque processus par rapport au takt time avec l'OEE, pas avec l'uptime. L'uptime seul omet la lenteur et les rejets, donc la carte peut placer le goulot au mauvais endroit.
Ce guide vient de Fabrico, la plateforme OEE et light MES. Il compare les trois nombres sur une ligne d'embouteillage et montre comment chacun change la carte. Pour la méthode elle-même, voir notre guide de value stream mapping.
Que signifie la case uptime sur une value stream map ?
Chaque processus sur une value stream map a une boîte de données en dessous, avec le cycle time, le temps de changement, l'uptime, les opérateurs, la taille de lot et les équipes. Le format vient de Learning to See, le workbook de 1998 de Mike Rother et John Shook, publié par le Lean Enterprise Institute.
L'uptime doit indiquer quelle part du temps planifié le processus peut réellement fonctionner. En pratique c'est souvent un nombre de mémoire, d'une bonne semaine ou la fiche du fournisseur de la machine. C'est là que la carte commence à dériver par rapport à l'atelier.
Uptime, Availability ou OEE : quelle est la différence ?
| Nombre | Comment il est calculé | Ce qu'il omet |
|---|---|---|
| Uptime | Temps de fonctionnement sur une base temporelle qui varie : l'équipe, le jour ou toutes les heures | Une base temporelle fixe, plus la lenteur, les arrêts courts et les rejets |
| Availability | Run time / temps de production planifié | Lenteur, arrêts courts sous votre seuil, et rejets |
| OEE | Availability x Performance x Quality, ou bon compte x cycle time idéal / temps de production planifié | Seulement le temps en dehors du plan |
Uptime et Availability sont proches, mais l'uptime n'a pas de définition fixe. Notre guide sur availability vs uptime couvre l'écart. L'OEE ajoute les deux pertes qu'une boîte de données ne montre jamais : vitesse et qualité. Notre guide OEE vs availability explique pourquoi les deux peuvent être très éloignés.
Quel nombre doit aller dans la case uptime ?
Utilisez la Availability mesurée, afin que la case garde sa signification habituelle. Ajoutez ensuite une ligne pour l'OEE, et utilisez l'OEE pour la vérification de capacité, car le client ne prend que les unités bonnes.
- Case uptime : Availability, avec la fenêtre à côté, par exemple "80.0%, 15 shifts".
- Nouvelle ligne OEE : OEE sur la même fenêtre, au moins pour le goulot.
- Case cycle time : le cycle time idéal, pas la vitesse d'une bonne journée.
- Vérification de capacité : cycle time effectif = cycle time idéal / OEE. Comparez-le au takt time.
Christoph Roser d'AllAboutLean cite la prise de la vitesse d'une bonne journée comme la manière idéale parmi les trois façons courantes dont l'OEE est trafiqué. Le même artifice fait paraître une boîte de données meilleure que l'atelier.
Comment le choix change-t-il la carte ?
Le goulot est le processus avec le cycle time effectif le plus long. Changez le nombre dans la case et le goulot peut se déplacer. Quand il se déplace, la carte d'état futur change :
- Les kaizen bursts vont au processus qui limite réellement la production.
- Les buffers se placent devant le vrai goulot, pas devant le processus au plus faible uptime.
- La question de capacité change de "avons-nous besoin d'une nouvelle ligne ?" à "quelle perte retirons-nous d'abord ?".
Notre guide d'analyse des goulots montre comment confirmer la contrainte sur le plancher.
Exemple d'uptime sur une value stream map : une ligne d'embouteillage, trois nombres
Ligne d'exemple (chiffres illustratifs, pas d'un client) : une chaîne d'embouteillage de sauce avec un remplisseur, un étiqueteur et un conditionneur. Une équipe a 450 minutes de temps de production planifié. Le client a besoin de 33 750 bouteilles par équipe, donc le takt time est 27 000 secondes / 33 750 = 0,80 seconde par bouteille. Chaque bouteille rapporte 0,10 $, ou 0,10 € dans une usine en euros.
La vieille carte utilisait l'uptime de mémoire. L'équipe a ensuite mesuré chaque processus sur 15 équipes :
| Processus | Cycle time idéal | Uptime, vieille carte | Availability, mesurée | OEE, mesurée | Cycle time effectif |
|---|---|---|---|---|---|
| Filler | 0.60 s | 90% | 80.0% | 70.2% | 0.85 s |
| Labeller | 0.50 s | 88% | 78.0% | 74.5% | 0.67 s |
| Case packer | 0.48 s | 90% | 86.0% | 79.8% | 0.60 s |
- Vue uptime. Le remplisseur, à 100 bouteilles par minute, peut produire 45 000 x 90% = 40 500 bouteilles par équipe : 20% au-dessus de la demande. Chaque processus dépasse le takt. L'étiqueteur a le plus faible uptime, donc le kaizen burst va là.
- Vue Availability. Le remplisseur produit 45 000 x 80.0% = 36 000, juste 2 250 au-dessus de la demande. L'étiqueteur paraît toujours le pire, à 78.0%.
- Vue OEE. Le remplisseur fonctionne aussi à 90.0% de Performance et 97.5% de Quality, donc l'OEE est 80.0% x 90.0% x 97.5% = 70.2%. Cela fait 45 000 x 70.2% = 31 590 bouteilles bonnes, 2 160 en dessous de la demande. Son cycle time effectif, 0.60 / 0.702 = 0.85 secondes, est au-dessus du takt.
- L'étiqueteur va bien. Son OEE est 78.0% x 96.0% x 99.5% = 74.5%, environ 40 200 bouteilles bonnes par équipe sur 54 000 possibles.
Ce que ça coûte. Au prix de 0,10 $ la bouteille, l'écart du remplisseur est de 216 $ par équipe (216 €), soit 162 000 $ (162 000 €) sur 750 équipes par an. Aujourd'hui l'usine compense avec des heures supplémentaires. La vieille carte a envoyé l'équipe vers l'étiqueteur, qui n'a jamais été la contrainte.
La nouvelle boîte de données du remplisseur indique : cycle time 0.60 s, changement 25 minutes, uptime (Availability) 80.0% sur 15 shifts, OEE 70.2% sur 15 shifts.
Comment mesurez-vous l'uptime pour une value stream map ?
- Utilisez le même modèle temporel que pour votre OEE. Le temps de production planifié est la base, et les changements comptent comme temps perdu, comme dans les six grandes pertes.
- Mesurez par machine, pas par ligne. Un chiffre par ligne cache quelle case est la limite.
- Prenez assez d'équipes : 15 ou plus, couvrant votre mix de SKU normal.
- Indiquez votre seuil d'arrêt court. Il n'y a pas de norme, alors écrivez le vôtre et gardez-le fixe.
- Utilisez des données machine, pas la mémoire. Les registres papier perdent les arrêts courts, et IoT Analytics trouve que 54.4% des petits et moyens fabricants fonctionnent encore au stylo et papier ou avec des feuilles de calcul.
Puis comparez chaque cycle time effectif avec le takt time et redessinez la timeline.
Quelles erreurs font mentir une value stream map sur l'uptime ?
- Écrire l'uptime de mémoire, ou à partir de la meilleure semaine de l'année.
- Utiliser la vitesse nominale de la machine comme cycle time alors qu'elle tourne plus lentement.
- Mélanger les bases temporelles : une case sur le temps d'équipe, la suivante sur toutes les heures.
- Mettre l'uptime de la ligne dans chaque case.
- Laisser de côté les rejets, alors que le client ne prend que les unités bonnes.
- Dessiner seulement le flux matière. La carte de Rother et Shook montre aussi le flux d'information, la partie que beaucoup de cartes omettent.
Où se situe Fabrico
Fabrico est une Manufacturing Performance Platform activée par computer vision. OEE et light MES viennent en premier : les arrêts sont enregistrés automatiquement, et l'OEE est en direct par ligne et par équipe. Pour une value stream map, cela signifie des boîtes de données mesurées.
- Availability, Performance, Quality et OEE par machine, sur les équipes que vous choisissez.
- Pertes valorisées en argent et classées, pour que les kaizen bursts aillent à la perte la plus coûteuse au goulot.
- L'opérateur confirme la raison en une tape, pour que les changements et pannes soient comptés séparément.
- Un clip caméra comme preuve d'un arrêt, quand une caméra surveille la machine.
Fabrico mesure les boîtes. Votre équipe dessine la carte et décide de l'état futur. Il n'y a pas de plan gratuit et il n'y a pas de niveaux : chaque usine reçoit un devis. Voyez comment un light MES complète le flux d'information de la carte.
Foire aux questions
Qu'est-ce que l'uptime sur une value stream map ?
L'uptime est la part du temps planifié qu'un processus peut réellement fonctionner, écrite dans la boîte de données sous chaque processus. Il doit être mesuré, pas retenu en mémoire. Le choix le plus clair est la Availability : temps de fonctionnement divisé par temps de production planifié, sur un nombre d'équipes indiqué.
L'uptime est-il la même chose que l'OEE ?
Non. L'uptime, comme la Availability, compte seulement le temps pendant lequel la machine est à l'arrêt. L'OEE compte aussi la lenteur, les arrêts courts et les rejets. Dans l'exemple travaillé le remplisseur a 80.0% de Availability mais 70.2% d'OEE, et seule l'OEE vous dit combien d'unités bonnes il produit.
Comment calcule-t-on l'uptime pour une value stream map ?
Prenez le temps de production planifié de chaque processus sur au moins 15 équipes. Soustrayez le temps d'arrêt, les changements inclus, pour obtenir le temps de fonctionnement. Divisez le temps de fonctionnement par le temps de production planifié et écrivez le résultat dans la case uptime avec le nombre d'équipes.
Une value stream map doit-elle utiliser l'OEE au lieu de l'uptime ?
Utilisez les deux. Gardez la Availability dans la case uptime pour que la carte se lise comme d'habitude, et ajoutez une ligne OEE. Utilisez l'OEE pour la vérification de capacité par rapport au takt time, car elle montre les unités bonnes que chaque processus produit réellement en équipe.
Quel est un bon uptime sur une value stream map ?
Il n'y a pas un seul bon chiffre. Ce qui compte, c'est si chaque processus, à son OEE mesuré, produit ce que le client demande en équipe. Un processus rapide avec un uptime faible peut aller, et un processus avec un uptime élevé peut quand même être le goulot.
Voyez vos boîtes de données dans une démo
Apportez une ligne et quelques équipes récentes. Nous montrerons Availability, Performance, Quality et OEE par machine, prêt pour votre value stream map.
Articles connexes

Tuiles Fabrico réelles, données d'exemple.











