S&D Control Center
Equilibrant l'automatització amb machine learning i la intervenció humana per a equips d'operacions que gestionen 60 milions d'euros l'any.
Lead Product Designer, 2024
Resum
- Les eines de supply i demand de Stuart s'havien fragmentat en 13 solucions separades per país, i una incidència crítica va posar en risc relacions clau amb grans clients.
- Vaig liderar el disseny, proposant un model d'“automatitzar i sobreescriure” que va resoldre la tensió entre operacions (que volien control manual) i enginyeria (que volien automatització total).
- Vam llançar una plataforma global única on les recomanacions del model ML són visibles i fàcilment ajustables, amb previsió de despesa en temps real.
- La majoria de tarifes ara es configuren automàticament, els equips d'operacions només intervenen per excepcions.
El problema
Stuart utilitza incentius per equilibrar l'oferta de missatgers amb la demanda dels clients. Quan no hi ha prou missatgers en una zona, augmenta les tarifes de pagament per atraure'n més. Els Area Multipliers són l'eina principal per gestionar-ho. Controlen 60 milions d'euros l'any en pagaments a tota Europa.
El 2022, les eines van fallar. Un script que s'executava des del portàtil d'algú va deixar de funcionar. Les comandes van arribar tard i Stuart va incomplir SLAs clau, posant en risc relacions amb grans clients empresarials.
Quan ho vam investigar, els problemes anaven més enllà d'un script trencat. Cada país havia construït les seves pròpies solucions. La gent ni tan sols entenia el desgavell que havia crescut orgànicament.
Operacions volia control manual perquè els models no sempre podien gestionar la seva complexitat. Enginyeria volia escalabilitat perquè els processos manuals es trencaven constantment. L'empresa en general volia més automatització.
Com a Lead Product Designer, em van cridar per ajudar a decidir què calia fer.
Entendre què teníem
Abans de dissenyar res, necessitava entendre tot el sistema. No s'havia mapejat i ningú en tenia una visió prou completa.
Vaig dedicar temps amb el Head of Global Operations documentant què existia, com es connectaven les eines, qui les feia servir, quins problemes resolien i on fallaven.
Vam trobar 13 solucions separades fent feina similar. Algunes eren aplicacions pròpiament dites. Altres eren fulls de càlcul amb scripts. Cadascuna s'havia construït per resoldre un problema local.
Al mateix temps, un argument es repetia en la majoria de converses:
Necessitem controlar-ho manualment. Els models no poden gestionar la nostra complexitat.
Necessitem automatitzar-ho tot.
Mentre es plategess com una tria entre una cosa o l'altra, les coses no avançaven prou ràpid.
Automatitzar i sobreescriure
Vaig proposar una cosa diferent. En lloc de preguntar si havíem d'automatitzar o mantenir el control manual, preguntem-nos: com dissenyem perquè les dues coses funcionin juntes?
- Utilitzar el model ALMO per fer la feina repetitiva: analitzar patrons, suggerir tarifes. Però fer fàcil que la gent sobreescrigui quan detecti alguna cosa que el model no ha vist.
- Perquè la gent pugui acceptar o sobreescriure amb confiança, necessita veure el que veu el model. Visualitzar les suggerències del model de forma clara.
- Posar les suggerències del model i les edicions manuals a la mateixa interfície. No obligar la gent a canviar d'eina.
- Construir un sol sistema per a tots els països en lloc d'eines específiques per país, amb prou flexibilitat per a les necessitats locals.
Vam utilitzar aquestes 4 idees per prendre decisions al llarg del projecte.
Com això va donar forma al disseny
Fer visible el model
El model ALMO genera suggerències setmanals de tarifes utilitzant patrons històrics de demanda, previsions meteorològiques, esdeveniments locals i restriccions pressupostàries.
Vaig dissenyar el calendari per mostrar aquestes suggerències com a punt de partida. Les suggerències s'accepten per defecte, però els equips d'operacions poden ajustar-les o substituir-les completament.
El model fa la feina de volum. Les persones gestionen les excepcions i les coses que el model no pot veure.
Mostrar què passarà
Els equips demanaven una cosa constantment: mostrar-nos què costaran els canvis abans de publicar-los.
Gastar de més perjudica els marges. Gastar de menys significa lliuraments amb retard i SLAs incomplerts. Necessitaven equilibrar ambdues riscos abans de confirmar.
Vaig dissenyar previsions de despesa en temps real. Mentre edites tarifes, veus la despesa total actualitzant-se, amb una comparació amb l'objectiu de pressupost per a aquella zona.
Accions massives i control granular
Els equips d'operacions gestionen centenars de zones de lliurament cada setmana. Necessitaven treballar en bloc per ser eficients, però també necessitaven ajustar zones individuals quan passava alguna cosa inusual.
La interfície suporta les dues coses:
- una graella de calendari on pots veure els valors i arrossegar per editar múltiples franges
- un panell d'edició massiva
- sobreescriptures individuals fàcilment disponibles
La restricció tècnica era que cada canvi dispara crides a l'API. Amb 100 zones en 7 dies i múltiples franges horàries, això són potencialment milers de crides.
Vaig treballar amb Enginyeria per agrupar peticions i dissenyar la interfície al voltant d'un flux de treball de primer-massiu-després-refinar. Mostràvem el temps de processament perquè la gent pogués veure què estava passant.
Resultats
- El model ML ara configura la majoria de tarifes automàticament
- Els equips d'operacions només intervenen per excepcions, no per treball rutinari
- De 13 solucions separades a 1 plataforma amb adopció global
- Zero incidències causades per les eines de S&D
Explorat però no llançat
Un cop la plataforma funcionava, vaig explorar tenir una vista de staging i permetre als equips d'operacions descriure canvis en llenguatge natural.
Puja Central London 0.3 el dissabte al vespre.
La IA generaria una vista de staging on l'usuari pot revisar i refinar.
El 2024, era massa aviat. Vam estimar l'esforç com a molt més gran del que sembla avui amb els avenços recents en models d'IA.
El sistema que vam llançar permetia que el model fes la feina de volum i les persones gestionessin les excepcions. Havia resolt el problema, i podíem passar a abordar altres reptes.