Runink FACE · Scénarios financiers et mise à l'épreuve d'hypothèses
Ceci est un scénario pour Runink FACE, le Fulfilment Autonomous Claims Engine. FACE tourne sur la plateforme Runink core, mais le travail décrit sur cette page est celui de FACE.
En Bref
- Le changement doit être écrit avant de pouvoir être débattu. Une hypothèse est énoncée explicitement, avec les règles qu'elle touche — les points de commande, les délais, les engagements de service sur lesquels votre activité fonctionne déjà. L'essentiel de la valeur est dans cette étape, et c'est l'étape qu'on saute d'ordinaire.
- Ce qui revient est un raisonnement, classé, avec la règle qu'il a invoquée. Chaque conséquence est rattachée à la règle précise dont elle découle, de sorte que vous pouvez la contester sur le fond. C'est un argument que vous pouvez vérifier, pas un chiffre à accepter.
- Rien n'est exécuté, et rien n'est branché. Le moteur n'a aucun chemin d'écriture vers vos systèmes et ne les touche pas. Il raisonne sur les règles que vous lui avez données, sur votre propre matériel — le scénario ne quitte jamais les murs.
- Vous pouvez le rendre rude exprès. Décalez une liaison d'une semaine. Retirez un fournisseur. Laissez un chargement se réchauffer. Les plans qui ne marchent que si tout se passe bien le montrent ici, et non à la clôture du trimestre.
Écrivez Le Plan Avant D'en Débattre.
Quand un port ferme ou qu'une usine s'arrête, vous avez environ une journée pour choisir un nouvel itinéraire. Les chiffres qui trancheraient sont dans quatre systèmes, et les réunir prend plus de temps que le choix ne peut attendre.
Où Cela Dérape
Une grève ferme un port le lundi. Le mardi, quelqu'un doit dire s'il faut faire venir les pièces par avion, tenir la ligne, ou passer par un autre port. La réponse dépend de ce que chacune coûte, du temps que chacune prend, et des commandes qui sont en risque dans un cas comme dans l'autre.
Alors quelqu'un monte un tableur. Cela prend deux jours. Il tient une seule version des événements, il repose sur des chiffres tapés à la main, et il est jeté dès que la décision est prise. La prochaine fois que cela arrive, le travail repart de zéro.
Ce n'est pas le plan qui est difficile. C'est d'avoir les chiffres à temps.
Et personne ne veut essayer un nouveau plan dans le système en production. C'est le système sur lequel tournent l'usine, l'entrepôt et la comptabilité. Une expérience là-dedans n'est pas une expérience.
À Qui Cela S'adresse
Trois personnes dans la même salle le mardi, qui argumentent à partir de trois jeux de chiffres différents.
- Directeur des opérations. Ce qui arrive aujourd'hui, c'est un port fermé le lundi et une décision à prendre pour le mardi, avec les chiffres qui trancheraient répartis dans quatre systèmes. Ce qui change, c'est ce que vous emportez en réunion : le changement écrit en une phrase claire, les règles qu'il heurte, et l'ordre dans lequel elles mordent.
- Responsable de la planification. Ce qui arrive aujourd'hui, c'est un plan discuté à partir de points de commande, de délais et d'engagements de service qui vivent dans la tête de trois personnes — d'où l'heure que deux d'entre elles passent à découvrir qu'elles décrivaient deux plans différents. Ce qui change, c'est l'ordre du travail. Les hypothèses sont écrites avant la discussion plutôt que reconstituées après, et chaque conséquence nomme la règle dont elle découle, si bien qu'un collègue peut la contester sur le fond.
- Directeur financier. Ce qui arrive aujourd'hui, c'est une ligne de fret urgent dans les comptes fournisseurs que personne ne rattache à la décision qui l'a causée. Ce qui change, c'est que l'option choisie et le nom de la personne qui l'a choisie sont conservés ensemble, si bien que la question posée six mois plus tard se lit au dossier et non dans la réunion.
Ce Qui Se Passe À La Place
Soyons clairs sur ce que c'est, car la catégorie est pleine d'outils qui restent vagues là-dessus. Le moteur ne fait pas tourner une simulation sur vos données de production et il ne calcule pas un résultat. Vous énoncez le changement comme une hypothèse et vous lui remettez les règles qui gouvernent ce que vous changez — points de commande, délais, engagements de service, l'hypothèse de réserve. Il raisonne sur ces règles et renvoie une lecture classée de ce qui en découle, chaque conséquence étant rattachée à la règle d'où elle vient.
Ce qui revient est donc un argument, pas une réponse. C'est cela qui est utile, et cela vaut d'être dit franchement : une projection présentée comme une décision est pire que pas de projection, car elle déplace le jugement de quelqu'un qui en répond vers un logiciel qui n'en répond pas. Ce que ceci apporte à la pièce, c'est le dossier déplié — quelles règles le changement heurte, dans quel ordre elles mordent, et ce qu'il faudrait croire pour que le plan tienne. La décision reste là où elle était.
Deux conséquences de cela valent la peine. Énoncer l'hypothèse force les présupposés à l'écrit, ce qui est l'étape que les équipes sautent et la raison pour laquelle deux personnes peuvent débattre une heure et découvrir qu'elles parlaient de plans différents. Et comme le raisonnement a lieu sur votre propre matériel, le scénario que vous envisagez — quel fournisseur vous pourriez retirer, quelle liaison vous pourriez couper — ne quitte jamais les murs.
Vous pouvez aussi le rendre rude exprès. Faites rouler la liaison avec une semaine de retard. Retirez la deuxième source. Laissez un chargement réfrigéré dériver. Un plan qui ne tient que si la semaine se passe bien s'effondrera ici, devant vous, tant que le découvrir ne coûte encore rien.
L'exécution ne choisit pas pour vous. Elle met les options en rang. Quand quelqu'un en choisit une et la transmet pour qu'on agisse, l'option retenue et son nom sont consignés ensemble, de sorte que la question posée six mois plus tard se répond depuis le dossier et non depuis la réunion.
Comment Vous Sauriez Que Cela A Marché
Chaque chiffre ci-dessous est le vôtre, pas le nôtre. Notez où vous en êtes aujourd'hui, car ce point de départ est perdu pour de bon dès que quelque chose change.
- Les heures entre une rupture et une décision. Prenez vos pires journées de l'an dernier. Depuis le journal des incidents et la trace des courriels : quand le port a fermé, et quand le nouvel itinéraire a été réservé.
- Combien d'options vous avez réellement chiffrées. Sortez de vos archives les dernières grandes décisions d'itinéraire. Comptez les options dont le coût était établi avant la décision, face à celles qui ont été débattues au feeling.
- Ce que vous dépensez en fret en urgence. Les lignes de surprime et d'aérien dans vos comptes fournisseurs, sur un trimestre entier, triées par la décision qui a causé chacune.
- Les jours de stock sur lesquels vous êtes assis. Les jours de couverture par référence depuis votre système de planification, et la part qui est là parce que personne n'a pu chiffrer le risque d'en tenir moins.
Apportez une liaison et votre dernière grande décision d'itinéraire.
Statut : hypothétique — non mesuré
La fermeture de port décrite ci-dessus est dessinée pour montrer la forme du travail. Ce n'est pas le compte rendu d'une mission chez un client, et rien sur cette page n'est un résultat mesuré. Runink ne publie aucun chiffre de retour sur investissement, aucun pourcentage et aucun nom de client — non pas parce qu'ils seraient peu flatteurs, mais parce que nous ne les avons pas mesurés, et le dire coûte moins cher que de se faire prendre.
Les Questions À Poser Avant Le Prochain Mauvais Lundi
Ce que vous lui donnez, ce qu'il vous rend, et qui décide toujours.