Atto II: L'anticamera
Il wine retailer e l'apparato che non manteneva niente
Il wine retailer aveva sette mercati UE, dodici categorie di prodotto e un processo di pricing che in otto anni si era evoluto in qualcosa che nessuno aveva più mappato per intero da quando la persona che l’aveva costruito se n’era andata.
Ogni lunedì, un membro del team pricing scaricava l’export del catalogo master e apriva il workbook. Il workbook aveva una tab per ogni mercato—FR, DE, IT, ES, NL, BE, AT—e dentro ogni tab, una matrice di moltiplicatori per categoria. Gli spumanti avevano una riga. I vini fermi avevano una riga. Le casse avevano una riga. Gli accessori e i gift set erano una storia a parte, che era anche una tab a parte. I moltiplicatori non erano identici tra le categorie, e non erano identici tra i mercati. Per ciascuno c’era una ragione. La ragione, in gran parte, era stata messa per iscritto, da qualche parte, a un certo punto. Il foglio di calcolo era esso stesso la documentazione.
Un secondo membro del team rivedeva l’output prima dell’upload. La revisione era a campione. La dimensione del campione era cresciuta insieme al catalogo. I file di upload passavano per uno step di compliance—in alcuni mercati i prezzi in EUR dovevano essere numeri interi, o almeno questa era stata l’interpretazione dal 2017 in poi. Poi i file venivano caricati.
L’intero processo si portava via quasi tutto il martedì, quando andava bene.
Quando arrivò il brief della migrazione, c’era una riga contrassegnata come non negoziabile:
Bisogna preservare la flessibilità di pricing per categoria e per mercato.
Lo diceva con il peso di otto anni di abitudine operativa.
Abbiamo chiesto, nelle prime fasi della discovery, cosa stesse effettivamente ottenendo la differenziazione per categoria.
In particolare: nei sette mercati, i ricarichi degli spumanti e dei vini fermi erano davvero diversi gli uni dagli altri in modo significativo?
La responsabile del pricing aprì il foglio di calcolo. Eseguì il confronto lei stessa, durante la riunione. Spumanti, Germania: 1,27. Fermi, Germania: 1,24. Spumanti, Francia: 1,31. Fermi, Francia: 1,30.
La differenza era reale. Ammontava anche a circa tre euro su una bottiglia da venticinque euro.
Abbiamo chiesto se la differenza avesse mai, a memoria di qualcuno, influenzato una decisione d’acquisto. Ci fu una pausa. Abbiamo chiesto se le suddivisioni a livello di categoria fossero state impostate deliberatamente o si fossero accumulate attraverso aggiustamenti individuali nel tempo. Ci fu una pausa più lunga.
La risposta, ricostruita nell’arco di due sessioni, fu questa: i moltiplicatori erano stati impostati deliberatamente, nel 2017, da qualcuno che ne aveva compreso la logica e che da allora aveva lasciato l’azienda. Da quel momento erano stati mantenuti—con cura, correttamente, con disciplina—perché esistevano e perché nessuno aveva chiesto a cosa servissero.
L’apparato manteneva una precisione che si rivelò non esistere.
Il requisito che erediti non è il requisito che hai davvero.
Abbiamo introdotto questa idea prima, in questo libro, come un accenno—una cosa da tenere a mente per dopo—e ora la stiamo dicendo con il peso che merita, in una stanza con un foglio di calcolo e sette mercati UE e una responsabile del pricing che per anni aveva fatto il suo lavoro con fedeltà, e che, quando qualcuno finalmente fece la domanda giusta, scoprì che quel lavoro era diverso da quello che credeva di fare.
Qui vogliamo andarci cauti, perché questa è la parte della storia che è facile raccontare nel modo sbagliato.
La presa di coscienza non fu vissuta come una vittoria. Non in quella stanza. Il foglio di calcolo era stato costruito con cura. Il processo era stato presidiato, documentato, iterato. Il rituale del lunedì non era spreco—era disciplina, e la disciplina ha un valore, e le persone che l’avevano mantenuto non erano sciocche. Stavano facendo esattamente ciò che l’organizzazione aveva chiesto loro, ovvero mantenere qualcosa che nessuno aveva mai esaminato.
È così che le organizzazioni accumulano complessità. Non per malizia. Non per negligenza. Per l’ordinario trascorrere del tempo e per l’ordinaria riluttanza umana a riaprire ciò che è già in funzione. Lo script di pricing funzionava. I prezzi venivano caricati. I mercati ricevevano un output corretto. Il fatto che una percentuale piatta a livello di mercato avrebbe prodotto gli stessi prezzi al consumatore, a meno dell’arrotondamento, per ogni SKU del catalogo—questo non era visibile dall’interno del processo. Lo si può vedere solo da fuori. La migrazione fu la prima volta in cui qualcuno ci stette fuori.
Il team pricing costruì l’apparato. Lo mantenne bene. Non è questo il fallimento. Il fallimento è che passarono otto anni senza che nessuno facesse un passo indietro per chiedersi a cosa servisse.
La domanda non è cosa dobbiamo replicare?
La domanda è: cosa abbiamo pagato per mantenere che non abbiamo mai avuto bisogno di avere?
Questa domanda fa male a farla ad alta voce. Implica, per le persone presenti nella stanza, che il lavoro che hanno fatto potrebbe non essere stato necessario. Vale comunque la pena farla—con genuina curiosità, non con accusa, perché l’obiettivo non è mettere sotto processo il team, ma capire l’organizzazione. La migrazione ti offre una scusa rara. Usala.
Lo schema non è esclusivo del pricing. L’abbiamo visto nel checkout: campi che esistono per un requisito di compliance fiscale di uno Stato verso cui il brand non spedisce più, ancora contrassegnati come obbligatori, ancora testati in QA, ancora difesi nelle discussioni di scope. L’abbiamo visto nelle integrazioni con l’ERP: un webhook che esiste perché un webhook più vecchio si era rotto, il webhook più vecchio rimosso da un pezzo, quello più nuovo che ora spara dentro un sistema che a un certo punto, negli anni intercorsi, ha smesso di riceverlo, le email di errore che si accumulano in silenzio in una casella che nessuno controlla. L’abbiamo visto nel CMS: un workflow di approvazione a quattro fasi, perché diversi anni fa c’era una brand voice manager che doveva dare il via libera a tutti i testi prima della pubblicazione, il ruolo della brand voice manager eliminato da tempo, il workflow a quattro fasi mantenuto con cura in sua assenza.
Non sono casi eccezionali. In ogni migrazione enterprise che abbiamo gestito su scala seria, da qualche parte tra il workshop di discovery e il build, abbiamo trovato un apparato come il foglio di calcolo del pricing. A volte ne abbiamo trovati tre. Non sono visibili dall’interno dell’organizzazione che li mantiene. È esattamente per questo che sopravvivono.
Il requisito che erediti non è il requisito che hai davvero. Dillo di nuovo: il requisito che erediti non è il requisito che hai davvero.
C’è un failure mode che vale la pena nominare, perché è costoso ed è comune.
Quando Shopify Markets dice non puoi fare regole di pricing a livello di categoria, ci sono due possibili risposte.
La prima: allora ci serve un PIM.
La seconda: perché pensavamo di averne bisogno?
La prima non è sbagliata. Ci sono brand con veri requisiti di pricing a livello di categoria—strutture di margine diverse per tipo di prodotto, condizioni contrattuali con i fornitori che operano per categoria, architetture di catalogo in cui una percentuale piatta a livello di mercato produce un output genuinamente sbagliato. Per quei brand, un PIM è lo strumento giusto. Il soffitto è reale.
Ma neanche la seconda risposta è sbagliata. Ed è quella che si fa più di rado, perché richiede di mettersi davanti alle persone che hanno costruito il requisito e insinuare, con delicatezza, che ciò che hanno costruito potrebbe non essere stato necessario. È una conversazione scomoda da avviare in discovery. È una conversazione sostanzialmente più scomoda da avere al sesto mese, dopo che il PIM è stato licenziato, dopo che il lavoro sul feed custom è stato messo a scope e stimato, e dopo che è stato tirato su un Expansion Store per i permessi dei team regionali—quando qualcuno finalmente chiede se i moltiplicatori di categoria siano davvero differenziati.
Shopify Markets ha limitazioni reali. Ma una parte della complessità che non riesce ad accogliere non è mai stata necessaria quanto sembrava.
Il soffitto è reale. Il soffitto è anche uno spunto. Il momento per cogliere lo spunto è in discovery, non in QA.
E i workaround si sommano. Un PIM per il pricing, più il lavoro sul feed custom per lo stack di app, più un Expansion Store per l’accesso dei team regionali—hai costruito qualcosa di più fragile di ciò che stavi sostituendo, e l’onere di manutenzione ti segue in avanti. Ribattezzato ma intatto.
Non abbiamo fatto la domanda giusta abbastanza presto, in abbastanza progetti, prima di capire questo. (Chiedici come facciamo a saperlo.)
Caro lettore: da qualche parte nel tuo stack c’è un apparato come questo.
Non possiamo dirti quale. Possiamo dirti che c’è, perché c’è sempre, e perché le uniche organizzazioni in cui non c’è sono quelle che sono appena uscite da una migrazione. La migrazione lo trova. È una delle cose a cui servono le migrazioni.
Trovalo in discovery. Fai la domanda prima di licenziare il PIM. Chiedi al team pricing—non nella riunione di gruppo dove emerge la versione ufficiale, ma in una stanza più piccola, con il foglio di calcolo aperto, con la domanda fatta in modo schietto: la precisione che stiamo mantenendo sta producendo risultati che contano?
Loro lo sapranno. Spesso se lo sono già chiesto. Stanno aspettando qualcuno con l’autorità per farla, quella domanda.
Un’ultima cosa. Owen Caldwell, che ha condotto con cura il suo workshop di discovery e ha inoltrato la solution proposal con una nota che diceva Tutto bene—siamo pronti a partire con il build, ha un apparato tutto suo che il workshop non ha fatto emergere. Non diremo ancora di cosa si tratta. Diremo che c’è, e che Owen non sa che c’è, e che quando torneremo da Greycott & Co., sarà stato trovato.
È ancora nella posa, mentre scriviamo. Non l’ha chiusa.
Se la terrà aperta abbastanza a lungo è la domanda che ci portiamo avanti.
Qui giace lo script di pricing.
Ha girato senza errori per otto anni.
Stava risolvendo il problema sbagliato.