Atto II: L'anticamera
Big bang o phased (ovvero: come scegliere una porta)
Decima settimana.
Nella sala riunioni c’era una timeline stampata appesa al muro—formato A3, codificata a colori, approvata al kickoff. La data del cutover stava sul bordo destro della timeline, in una barra rossa in grassetto. Sotto la barra qualcuno aveva scritto, con lo stesso pennarello rosso, D-Day. Era stata una battuta. Non lo era più.
Greycott & Co. si era impegnata su un cutover big bang da Magento → Shopify. L’opzione dual-run era stata sul tavolo durante la fase di proposta. L’avevamo stimata. L’avevamo quotata. Tutti erano d’accordo che fosse la strada più sicura. Tutti erano anche d’accordo che fosse troppo costosa. Costruire e mantenere il layer di integrazione tra Magento e Shopify—il mirroring degli ordini tra DTC, wholesale e i tre sistemi POS retail, la propagazione dell’inventario in entrambe le direzioni, i record cliente coerenti tra i canali—aveva un numero attaccato che il CFO si era portato a casa, aveva letto due volte e aveva riportato il lunedì successivo con la parola no scritta a matita accanto. Abbiamo rispettato il no. Siamo passati al big bang.
Il motivo per cui ti raccontiamo questa storia è che, alla decima settimana, qualcuno nella stanza disse, con calma, senza che nessuno alzasse la voce: dobbiamo riaprire la conversazione sul dual-run.
Quello che era cambiato non era la matematica. La matematica era la stessa. Quello che era cambiato era che il panorama delle integrazioni si era rivelato.
Lo stack Magento di Greycott era stato integrato, nell’arco di quasi un decennio, con NetSuite per l’ERP, un 3PL per il fulfillment DTC, un sistema separato di order management per il wholesale che un consulente aveva imbullonato a lato di NetSuite nel 2019 e che da allora nessuno aveva più toccato, una piattaforma di marketing automation, un motore fiscale che gestiva le imposte sulle vendite in quarantatré stati, un servizio di stampa etichette per il ramo wholesale, e il POS dei tre negozi retail—ciascuno dei quali era stato configurato sotto una versione leggermente diversa del software POS, e ora si aspettava payload di webhook leggermente diversi. Nessuna di queste integrazioni era esotica. Ciascuna di esse, presa singolarmente, era ragionevole. Il problema era che non potevi fare un cutover pulito verso Shopify senza ricostruirle tutte sulla nuova piattaforma nello stesso giorno. E ricostruirle, in parallelo, con scadenze di lancio rigide, contro vendor che impiegavano due settimane a rispondere a un ticket di supporto—questa era la parte che la fase di proposta aveva modellato per difetto.
Il big bang è concentrazione del rischio. L’avevamo detto nella proposta. Non avevamo, alla prima settimana, capito la forma della concentrazione. L’abbiamo capita alla decima.
La conversazione sul dual-run tornò. Il CFO rifece i conti. Il numero era ancora grande. Il numero non era più il numero più grande sul tavolo.
Il piano cambiò.
Cambiò senza che nessuno alzasse la voce. Non fu un panico. Fu il team che aveva già avuto una volta la conversazione sul phased, nella proposta—sapendo che l’alternativa esisteva nell’architettura, avendo tenuto della flessibilità in riserva proprio perché questa conversazione della decima settimana potesse avvenire senza ricostruire il progetto da zero.
Daniel Okafor era nella stanza quando il piano cambiò. Lo stava prendendo con molto garbo.
Ti diremo tra un minuto perché.
Riguarda, in particolare, il fatto che la maggior parte dei brand non prende mai la decisione che abbiamo appena descritto.
La maggior parte dei brand prende questa decisione per default invece che per design, di solito perché la loro agenzia sa farlo in un solo modo. L’agenzia fa big bang perché gli ultimi tre progetti erano big bang, il team è bravo nei big bang, e i case study sul sito parlano di big bang. Oppure l’agenzia fa rollout phased perché fattura più ore sui rollout phased. In ogni caso, la risposta è la risposta che ti avrebbe dato anche prima di averti conosciuto.
Questo è il failure mode che vogliamo prevenire. Non il big bang. Non il phased. Il defaulting.
Quindi attraverseremo entrambi, con i costi in vista, i rischi nominati, e le domande che dovresti porti alla prima settimana—non alla decima.
Il big bang è esattamente ciò che sembra. Costruisci la nuova piattaforma, alzi la leva il giorno del lancio, e mandi in pensione il vecchio sistema. Tutto si sposta in una volta sola.
È una strategia legittima. Ci sono brand per i quali è la strategia migliore. Le condizioni hanno questo aspetto. Vuoi mantenere una sola piattaforma alla volta, il che abbassa il costo dell’infrastruttura e rimuove il sovraccarico cognitivo di gestire due admin, due superfici di reporting, due conversazioni sulla source of truth. Hai un layer di integrazione minimo—un payment provider, un corriere, magari un webhook ERP—e ricostruirli sulla nuova piattaforma è un workstream contenuto, non un progetto a sé. Il tuo tech stack è lineare. Mercato unico. Canale unico. Un catalogo non esotico. Un checkout che non ha accumulato logica custom nel corso di diversi anni. Il tuo volume d’ordini è abbastanza moderato che un intoppo nel peggiore dei casi al lancio—una giornata degradata, qualche centinaio di ordini da riconciliare a mano—è un problema che puoi assorbire senza archiviarlo come un incidente a livello di board.
Quando queste condizioni reggono, il big bang è la strada più efficiente verso Shopify. Le migrazioni phased hanno costi ingegneristici reali—ci arriveremo—e pagare quei costi quando non ne hai bisogno è a sua volta un failure mode.
Il guaio è il rovescio della medaglia, cioè la concentrazione del rischio. Quando tutto va in produzione in una volta sola, tutto può rompersi in una volta sola. Se la tua migrazione dei dati ha edge case che non hai colto nei test—e ci sono edge case che non hai colto nei test; è un’affermazione sul mondo, non sul tuo team—li scopri il giorno in cui la posta in gioco è più alta. Se un’integrazione di terze parti si comporta diversamente sotto carico di produzione rispetto a come faceva sotto carico di staging, lo scopri lo stesso giorno. Se il tuo team di customer service non ha ancora interiorizzato quale piattaforma sia la source of truth per i rimborsi, lo scopri lo stesso giorno, mentre una coda di ticket di rimborso si accumula.
Il rollback è spesso impossibile. Nel momento in cui inizi a prendere ordini sul nuovo sistema, i tuoi dati cliente e ordini divergono da quelli del vecchio. I due database non sono più lo stesso database. Tornare indietro dal cutover significa scegliere quale insieme di record tenere e quale buttare, e la risposta a quella domanda è nessuno dei due, per favore, ma nessuno dei due non è un’opzione.
Per un brand che fa duecentomila dollari di fatturato giornaliero, anche poche ore di downtime o di performance degradate durante un cutover andato male si traducono in centinaia di migliaia di dollari di vendite perse—più il caos operativo di riconciliare ordini, inventario e clienti tra due sistemi che non erano mai stati progettati per girare in parallelo, più il colpo alla fiducia dei clienti, più il colpo al morale del team, più la chiamata al board. I numeri si sommano.
Questo è ciò che intendiamo per concentrazione del rischio. Il big bang prende ogni rischio della tua migrazione e li impila tutti sulla stessa ora.
Una migrazione phased adotta l’approccio opposto. Invece di spostare tutto in una volta, migri in modo incrementale, validando ogni passo prima di allargare lo scope. L’obiettivo è ridurre il blast radius di un singolo fallimento—così che, quando qualcosa va storto, e qualcosa andrà storto, colpisca un segmento piccolo e contenuto del tuo business invece dell’intera operazione.
Ci sono tre modi comuni di fare phasing, e quello giusto dipende meno dalle preferenze che dalla forma del tuo business.
Il primo è mercato per mercato. L’approccio più comune per i brand con operazioni internazionali. Lanci Shopify in un mercato a basso volume, lo fai girare a fianco della piattaforma legacy, e fai il rollout di mercati aggiuntivi man mano che acquisisci fiducia. Il tuo mercato a più alto volume va per ultimo. Utile quando il tuo business si affetta in modo naturale per geografia.
Il secondo è canale per canale. Lo stesso principio, affettato per canale di vendita invece che per geografia. Va per primo un portale wholesale. Oppure un brand secondario. Oppure uno storefront B2B che gira a volume più basso e serve una base clienti più tollerante. Il tuo storefront DTC di punta—quello che genera il fatturato da titolo di giornale e lo scrutinio da titolo di giornale—resta sulla piattaforma legacy finché i canali di seconda fascia non hanno collaudato quella nuova.
Il terzo è feature per feature. L’opzione tecnicamente complessa, e una su cui passeremo un intero capitolo più avanti a cambiare idea. Il feature-by-feature ha senso solo in un’architettura headless, dove il frontend è disaccoppiato dal backend commerce e le singole pagine possono essere migrate alle API di Shopify mentre il resto dell’esperienza continua a girare sul sistema legacy. (La lista dei brand che possono fare phasing feature-by-feature in modo responsabile è corta, e abbiamo cose da dire sul perché sia corta. Più avanti.)
Non si escludono a vicenda, tra l’altro. Un brand può fare phasing per mercato sullo storefront e phasing per canale sul lato wholesale. La forma può essere ibrida. Il punto è scegliere la forma che mappa sulla tua superficie di rischio, non la forma che mappa sul template di slide preferito dalla tua agenzia.
Il pivot di Greycott, alla decima settimana, fu dal big bang al canale-per-canale. Il mercato-per-mercato non avrebbe funzionato—Greycott vende in un solo mercato, con un lento filo di vendite verso il Canada abbastanza piccolo da non contare. Nemmeno il feature-per-feature avrebbe funzionato; lo storefront stava migrando verso un setup standard ospitato su Shopify, non verso uno headless. La spaccatura naturale erano i canali stessi, che erano stati operativamente distinti per anni e che portavano profili di rischio molto diversi.
L’ordine del phasing, quando si concretizzò, fu: prima il wholesale, poi il retail, per ultimo il DTC.
Il wholesale venne per primo perché la base clienti era la più indulgente. Un buyer di una catena di supermercati regionale che riordina gli stessi SKU ogni sei settimane tollera un checkout goffo la prima volta in un modo in cui un cliente DTC che sceglie un gift set natalizio non lo farà. Gli ordini wholesale passavano anche attraverso un workflow di fulfillment separato presso il 3PL, il che significava che la superficie di integrazione per il canale wholesale era contenuta: un endpoint di fulfillment, un flusso fiscale, un modello di account cliente. Il costo di sbagliare il wholesale era una settimana di telefonate frustrate e qualche riordino in ritardo. Il costo di sbagliare il DTC era ogni parte della storia che stavamo cercando di evitare.
Il retail venne per secondo. L’integrazione POS era la più ostica dal punto di vista operativo—l’inventario doveva sincronizzarsi tra Shopify e i tre negozi retail quasi in tempo reale, e lo staff di quei negozi doveva essere riaddestrato su una nuova UI del POS senza che nessuno abbandonasse la memoria muscolare di quella vecchia. Ma il volume del retail era modesto rispetto al DTC, e la superficie di rischio era visibile: se la sincronizzazione dell’inventario si rompeva, potevi vederla rompersi alla cassa, immediatamente, e tirare la leva. (Confrontalo con un guasto silenzioso di un’API DTC, che scopri tre giorni dopo in un canale Slack che nessuno stava guardando.)
Il DTC venne per ultimo, perché il DTC era il canale in cui un fallimento catastrofico era catastrofico.
Far girare Magento e Shopify in parallelo—per il periodo tra il go-live del primo canale e il cutover dell’ultimo—richiedeva, come minimo, quanto segue. Ogni ordine wholesale piazzato su Shopify doveva essere mirrorato su Magento affinché i processi di fulfillment e contabilità già legati a Magento continuassero a funzionare. Gli ordini non arrivavano in due sistemi contemporaneamente per caso; arrivavano perché era il layer di integrazione a farli arrivare. Ogni aggiornamento di inventario dal 3PL e dai negozi retail doveva propagarsi a entrambe le piattaforme. Se una cassa di olio d’oliva usciva dalla porta, entrambe le piattaforme dovevano saperlo—e saperlo abbastanza in fretta che il prossimo cliente DTC ad atterrare sulla pagina prodotto non vedesse stock che non esisteva più. Ogni record cliente doveva restare coerente. I clienti wholesale con termini net-30 dovevano essere riconoscibili tra i canali. I clienti DTC con punti fedeltà dovevano vedersi rispettati quei punti se entravano in un negozio retail e presentavano il telefono alla cassa. (Se ti sei mai chiesto perché il data modeling dei clienti compare nello scope di una migrazione prima che qualcuno abbia toccato lo storefront, è per questo.)
Questo non è lavoro di integrazione astratto. Sono webhook, chiamate API dirette, strumenti di normalizzazione, dashboard di monitoring, turni di on-call per il layer di integrazione stesso, e una lista di divergenze note che riconcilieremo a mano ogni venerdì che crebbe e poi si ridusse e poi crebbe di nuovo nel corso del rollout.
C’è anche un layer meno tecnico di cui nessuno ti avverte, cioè la complessità organizzativa. Il team doveva capire quale piattaforma fosse autoritativa per quali dati in quale canale. Lo staff di supporto doveva imparare due interfacce admin e le regole su quando usare quale. Il reporting diventò più difficile, perché il fatturato viveva in due sistemi e la logica di consolidamento andava costruita (e rivista trimestralmente, e corretta alla settima settimana di quel trimestre quando qualcuno si accorse che i numeri non tornavano). Il team finance teneva un piccolo foglio di calcolo, separato dal tool di BI, che nessuno aveva chiesto loro di tenere. L’avevano costruito la seconda settimana del rollout. Non l’avevano spento dopo la fine del rollout.
Niente di tutto questo era gratis. Costava soldi veri e attenzione vera.
Significava anche che, quando i problemi venivano a galla—e lo facevano, per tutto il tempo—colpivano un canale invece dell’intero business. Il team imparò i workflow di Shopify in un vero ambiente di produzione, con clienti veri, ordini veri, edge case veri, mesi prima che andasse in produzione il canale a più alta posta in gioco. Quando il DTC fece il cutover, il team aveva già fatto girare centinaia di giornate reali di produzione su Shopify in wholesale e retail. Il cutover del DTC fu un evento logistico, non un salto nel buio.
Il senso di raccontarlo qui è più ristretto: questo è ciò che il phased costa, e questo è ciò che il phased ti compra, e i due valgono la pena di essere modellati alla prima settimana contro l’alternativa.
L’obiezione più comune alla migrazione phased è il costo. Sì—costruire e mantenere un layer di integrazione tra due piattaforme si aggiunge al budget del progetto. C’è un numero attaccato. Il numero è reale.
La domanda rilevante è rispetto a cosa?
Il costo di una migrazione phased è visibile e prevedibile. Il costo di una migrazione big bang andata male è invisibile finché non succede, e a quel punto è enorme.
Puoi mettere nello scope il lavoro di integrazione. Puoi stimare l’infrastruttura aggiuntiva. Puoi pianificare la timeline estesa. Il numero sulla proposta è il numero, più o meno un margine difendibile. È un numero che puoi mettere su una slide e difendere davanti a un CFO che legge slide per mestiere.
Il costo di un big bang andato male non è una slide. È un postmortem.
Se processi duecentomila dollari di fatturato giornaliero e un cutover andato male ti costa dodici ore di downtime più una settimana di operatività degradata, l’impatto finanziario fa impallidire il layer di integrazione. La voce di costo del dual-run che sembrava costosa nella proposta sembra piccola accanto alla voce di costo per il giorno in cui abbiamo messo offline il nostro checkout durante la spinta di dicembre perché il motore fiscale girava su una config obsoleta. Il primo costo è messo a voce di costo nel progetto. Il secondo costo è messo a voce di costo in una lettera di scuse al board.
Lo diciamo con cautela, perché la modellazione dei costi del rischio catastrofico è una di quelle cose che le organizzazioni fanno male. Per male, intendiamo: la fanno non facendola. Il rovescio del big bang è un tail risk, e i tail risk hanno la proprietà di essere facili da ignorare fino al giorno in cui non lo sono. Il compito del piano di migrazione è mettere un numero su quel tail risk e metterlo sulla stessa pagina del costo del dual-run, così che i due numeri possano essere confrontati sulla pagina in cui verranno effettivamente confrontati, che è quella dello steering committee.
Quando il confronto è fatto onestamente, il phased spesso ne esce davanti alla scala enterprise. Non sempre. Spesso.
E c’è un beneficio del phased che è facile trascurare perché non compare affatto sul lato dei costi. Le migrazioni phased hanno un time-to-value più precoce. Poiché stai lanciando Shopify in un canale reale presto nel progetto, il tuo team inizia a imparare la piattaforma, a iterare sull’esperienza, e a catturare parte dell’upside che ha motivato la migrazione mesi prima di quando andrebbe in produzione un lancio big bang. Ogni giorno in cui sei parzialmente su Shopify è un giorno in cui stai catturando parte del valore che ha motivato la migrazione in primo luogo. Questo si compone, sia finanziariamente sia in capacità del team. Viene modellato raramente. Dovrebbe esserlo.
Ora possiamo rispondere alla domanda che abbiamo lasciato in sospeso alla fine del cold open. Perché Daniel stava prendendo con garbo il pivot della decima settimana.
La questione del big bang contro il phased lo aveva raggiunto alla terza settimana.
Daniel è il Lead Engineer di Greycott. Ha ereditato lo stack Magento dall’agenzia che lo costruì nel 2018 e dall’ingegnere che lo mantenne fino al 2024. Sa dove vive ogni workaround. Aveva passato le prime due settimane del progetto ad annuire con garbo mentre accompagnavamo lo steering committee attraverso il nostro piano di default, che era big bang, con una sicurezza di cui da allora abbiamo imparato a diffidare leggermente quando ci viene non sollecitata in noi stessi.
Alla terza settimana, fece la domanda. Potevamo modellare entrambi?
Dicemmo di sì, certo, andava bene—anche se l’implicazione nella stanza, se siamo onesti, era che avevamo già modellato entrambi, e che il big bang era chiaramente la risposta giusta, e che fare questo esercizio era una formalità.
Daniel fece comunque la modellazione. Si costruì un foglio di calcolo da solo. Aveva due tab. Il primo tab stimava il costo del layer di integrazione per un rollout canale-per-canale—DTC, wholesale, i tre negozi retail, la superficie di integrazione abbozzata onestamente su tutti quanti. Il secondo tab stimava il costo di un big bang andato male. Usò tre scenari—caso migliore, caso atteso, caso di coda—e attaccò una probabilità a ciascuno. Non si inventò le probabilità; le basò su quello che avevamo detto sui nostri ultimi quattro progetti durante la proposta, che Daniel si era segnato su un taccuino.
Portò il foglio di calcolo alla riunione successiva dello steering committee. Il nostro project lead diede un’occhiata al secondo tab, gli diede un’altra occhiata, e chiese di portarselo a casa per guardarlo con più attenzione.
Il piano non cambiò.
Tornammo la settimana dopo con un contro-modello che metteva più peso sul costo dell’integrazione e meno peso sul tail risk, e lo steering committee—che, tra te e noi, aveva già deciso cosa voleva fare—scelse il big bang. Avevamo detto le cose giuste. Le avevamo anche dette in un modo che non scompigliava la stanza. (Chiedici come lo sappiamo.)
Daniel non insistette con forza. Aveva detto la sua. Aveva costruito il modello. L’aveva consegnato. Se fosse stato un ingegnere del tipo più rumoroso, avrebbe potuto insistere, e il capitolo ora parlerebbe di lui che insiste. Non era quel tipo di ingegnere. Era il tipo di ingegnere che diceva la cosa vera una volta, con calma, e poi tornava a fare il lavoro. Archiviò il suo foglio di calcolo in una cartella chiamata migration/planning/scenarios e proseguì con la sua settimana.
Poi arrivò la decima settimana, e lo steering committee fece marcia indietro, e la conversazione sul dual-run tornò, e Daniel era nella stanza quando successe. Stava prendendola con garbo perché le persone che stavano invertendo la decisione erano le stesse persone che non avevano preso sul serio il suo modello alla terza settimana—e una di quelle persone, dovremmo ammetterlo, eravamo noi.
Non fu, ovviamente, del tutto riabilitato. Il pivot della decima settimana fu una decisione ragionevole. Se fosse la decisione giusta per Greycott—se tutto quanto sia andato a finire nel modo in cui il modello di Daniel diceva che sarebbe andato—lo scoprirai più avanti nel libro. Tutto quanto sta facendo un po’ di lavoro in quella frase.
Quello che possiamo dirti, qui, è che l’esercizio di modellazione in sé era la mossa. La scelta tra big bang e phased non è un lancio di moneta; è un calcolo. Il calcolo richiede che qualcuno con autorità nella stanza insista perché entrambe le opzioni vengano modellate—e, quando il modello dice qualcosa di scomodo, che qualcuno con autorità rilegga il modello invece di contro-modellarlo.
Daniel fu il primo qualcuno in Greycott. Noi imparammo a essere il secondo.
Il libro è, in parte, un argomento a favore del fatto che ogni migrazione ha bisogno di entrambe le persone. Se stai leggendo questo e non sai ancora quale delle due sei, probabilmente sei entrambe.
La strategia di migrazione giusta dipende dalla tua scala, dalla tua complessità di integrazione, dalla capacità del tuo team e dal tuo appetito per il rischio. Il big bang funziona per i brand con stack più semplici e volume più basso. Il phased si guadagna il suo costo quando operi su scala, hai una superficie di integrazione complessa, o non puoi assorbire il rischio concentrato di un singolo cutover.
La decisione dovrebbe essere fondata sui numeri, non sull’istinto—e di sicuro non su qualunque opzione la tua agenzia abbia preferito già entrando nella stanza. L’esercizio è in tre passi. Stima il costo del phased: il layer di integrazione, l’infrastruttura doppia, la timeline estesa, la complessità organizzativa, le cose che scoprirai a metà strada di cui nessuno ti aveva avvertito. Stima il costo del rischio del big bang: potenziale downtime, errori nei dati, time-to-value ritardato, disruption del team, il postmortem che non vuoi scrivere. Confrontali onestamente. Le risposte saranno diverse per ogni brand. Almeno starai scegliendo a occhi aperti invece di andare di default su qualunque approccio la tua agenzia abbia proposto per primo.
L’obiettivo, ancora una volta, è ridurre il blast radius di un singolo fallimento. È questo il motto. Non ti dice quale strada scegliere. Ti dice quale domanda tenere in testa mentre stai scegliendo.
Il pivot di Greycott, alla decima settimana, non fu una crisi. Fu il prodotto di aver tenuto aperta la conversazione presto—aver quotato l’opzione dual-run, aver capito la sua forma, aver riservato abbastanza flessibilità nell’architettura da poter fare il cambiamento senza ricostruire il progetto da zero.
Il pivot esisteva perché la domanda era stata posta presto.
La domanda è il capitolo.