Essilor on-site

Xavier: Supply chain europe. Flux vers les opticiens et vers les dépôts. Direct vers les magasins avec un last miler. SC très polymorphe, mutli-réseaux.

Il sera patron de tout les planeur européens.

Les usines doivent garder le moins de stock possible. Pushflow. En Europe il y a des stocks mais ne veulent plus garder de stocks. Mass prod (produit finit verre simple miopie pas trop de paramètres)→ distribution center (verre progressive) → filiale

Il y a un programme pour rassembler tout les stockage en europe.

Besoin: MRP qui tourne, des stocks hebdo, sur lequel on peut automatiser une bonne partie, le planeur apprend et prend des commandes. Situation journalière, des anomalies au niveau du stock et réaction ponctuelle d'urgence.

(MRP oracle)

Tout est intégré chez Essilor. Extrêmement fragmenté. 1million de référence stocké (SKU)

Machine learning et planeur de stock. Un planeur arrive le matin, et vérifie mes problèmes spécifique.

Ils veulent automatiser le planning ( quoi faire dans le jour et la semaine).

Minimiser les produits à jeter

Ils vont travailler sur les standards de réaction l'année prochaine.

A chaque fois y'a une réinvention de la gestion de crise.

ML objectif: rendre efficace le planeur, optimiser le travail, automatiser tt les jours

On focus le planeur que dans les exceptions

Automatiser les choses à faire par jour pour le planeur ( prédire à l'avance ls risques, anomalies et ruptures)

Données marketing, ventes ou autres peuvent influencer le planning.

Détecter les vrais//faux anomalies.

Si on construit un assistant planer ils sont chaud (et rajouter du collaborative, du chat, la traçabilité des décisions)

Autre problème: Ou est physiquement notre commande (en terme de transport).

Rigoureux côté IT.

Note JB

Passe une commande X proposée par le système.

⇒ Journalière, anomalies. Réaction ponctuelle d'urgence.

MRP, Re-balancing, Redéploiement.

⇒ Travailler avec qqch de très découplé, réappro avec un min max. :⇒ remise à coeur du dispositif.

Déployer un calcul de DRP ⇒ Oracle. Prend pas simplement le min max mais un besoin.

Proposition de PO à réaliser. Charge au planner d'alimenter et de faire un dispatch.

⇒ Equipe qui travaille sur un réseau.

Plan d'appros c'est des milliers de lignes. ⇒ standard de réactions.

1M de références stockés.

20 personnes travaillent sur la réappro. des filiales européennes

Planner de stocks. ⇒ gérer les exceptions.

S'il manque des verres.

RED = Stock disponible 50%. Si stock = 0, réappro en cours.

⇒ Homepage avec tous les problèmes par portefeuille de produit.

Masse prod sur les filiales. ⇒ DRP apporte des avantages (mettre tout le monde sur une même plateforme). Déployer une méthode commune.

ERP partialisés ⇒ plein d'erp différents

Analyse ⇒ poser une question avec telle personne. Liste de questions.

Scrap les produits pas vendus. ⇒ Au niveau global comment piloter l'obsolence.

⇒ Savoir quand arrêter la production et la stratégie de consommation en fonction de la fin de vie.

Globalement, travail sur des standards de réaction l'année prochaine.

Visibilité des stocks en temps réel. ⇒ en cours de déploiement.

ML ⇒ rendre plus efficace le planner. Automatiser certaines actions. Démarrer courant de l'année prochaine.

Réseau distribution. Idéal, plus personne qui regarde la partie MRP et planner focus sur exception.

Statut des familles. Calcul qui tombe toutes les semaines.

⇒ traitement par écart. Intelligence dans mon cerveau est automatisable. Actual cohérent avec le forecast ?

Standard Oracle du calcul MRP. ⇒ Alertes statiques.

Order Management. ⇒ exception double commandes, ...

⇒ 2 gros stocks aux US qui servent le petit client et le key account.

Côté algorithmique ⇒ certaines règles ne donnent pas d'anormal mais en fait le sont.

Informations extérieurs : marketing, ventes, ... nécessaires pour détecter certaines anomalies.

⇒ qui arrête le produit ?

Construire l'assistant planner ⇒ Comprendre pourquoi on a pris cette décision, alerter.

Exception ⇒ où est physiquement la commande.