Chiedete a chiunque sia a capo di un’azienda di commercio digitale quale sia la cosa più frustrante nell’ambito delle trasformazioni digitali e vi dirà che è il processo di replatforming da una soluzione commerciale a un’altra. Il solo pensiero di intraprendere un progetto di tale complessità, costo e impegno può essere spiacevole. Potrebbe sembrare un compito scoraggiante e rivoluzionario (perché può esserlo!), ma quando un progetto di replatforming è fatto bene può sbloccare opportunità di crescita che non erano disponibili al tempo dell’implementazione della tua attuale piattaforma. Ho imparato che con il giusto approccio il processo di replatforming può essere semplice.
Come ex vicepresidente dell’ecommerce di Tommy Hilfiger, so in prima persona cosa comporta questo tipo di processo, avendo lavorato su un progetto di replatforming multinazionale che coinvolgeva più marchi e che si muoveva da una serie composita di soluzioni a una singola piattaforma aggiornata. Per quanto “facile” e veloce possa essere la migrazione a una nuova soluzione, indipendentemente dalla piattaforma, ci sono molti aspetti di questo processo di cui nessuno ti avvisa fin dal principio. Condividendo le preziose lezioni che ho imparato dalla mia esperienza, spero di evitare ad altri possibili grattacapi e trabocchetti, perché le ragioni per cui le cose vanno male sono spesso realmente prevedibili ed evitabili.
Quindi ecco le 10 cose che avrei voluto sapere prima di fare il replatforming di un’operazione di ecommerce:
La sfida più difficile non sarà la selezione di un fornitore di piattaforme, ma ottenere il consenso da parte dei vertici dell’azienda e dei principali stakeholder. In passato progetti come questo richiedevano l’approvazione e il coinvolgimento di un team molto più piccolo di responsabili, ma poiché la complessità e la scala dei processi di replatforming sono cresciuti considerevolmente, ora è uno sforzo (e un investimento) molto più grande di quello che era una volta. Coinvolgere tutti gli stakeholder nel processo fin dall’inizio è vitale per ottenere il successo. Se non lo fai, rischi rallentamenti significativi o rivalutazioni del budget e degli obiettivi quando ne verranno a conoscenza in seguito. Infatti oltre il 70% dei processi di trasformazione falliscono a causa di una mancanza di comunicazione sufficiente e del consenso1 a livello organizzativo. Certo non è sempre facile ottenere un consenso sui progetto, ma ecco alcuni suggerimenti per aiutarti a ottenerlo rapidamente:
Tra le scelte più importanti c’è quella di selezionare il partner giusto che si prenderà il tempo di conoscere il tuo business e le tue peculiari esigenze. Ma anche tu dovresti occuparti di conoscere bene il tuo partner: dovresti parlare anche con i System Integrator (SI) quando incontrerai i fornitori di piattaforma in modo da conoscere veramente i tuoi partner nel progetto. I System Integrator sono così essenziali per il successo del progetto che sarà il caso di valutare non solo il software, ma il software e i SI insieme. Non stai assumendo un’azienda, stai assumendo alcuni individui di quell’azienda. Quindi sii selettivo!
Per far sì che il progetto proceda con semplicità ed evitare inutili intoppi, è importante designare una (e una sola) persona del tuo team interno come responsabile dedicato al progetto. Questa persona non ha bisogno di essere coinvolta in ogni singola decisione, ma può prendere decisioni nei casi in cui c’è un disaccordo 50/50 o quando è necessaria una risposta rapida. Sarà anche il principale punto di contatto per le domande del team SI, quindi assicurati che sappia che quando sorgono conflitti ha sempre l’ultima parola per arrivare a una soluzione.
Oltre al tuo responsabile principale, ci sono altri due ruoli da prendere in considerazione che avranno un grande impatto sul tuo progetto. Questi sono il Business Analyst del team SI e il Project Manager. Il Business Analyst può tradurre esattamente ciò di cui hai bisogno in requisiti per gli sviluppatori, e c’è una grande differenza tra ottenere ciò che vuoi e ottenere qualcosa che assomiglia vagamente a quello che vuoi. Avere un Project Manager interno e capace aiuterà anche il tuo team a gestire le numerose parti mobili e i requisiti lungo il percorso. Il team conoscerà i limiti di ciò che può gestire da solo, e ciò che ha bisogno di essere scalato, e può aiutare a trasmettere i compromessi necessari ai diversi passaggi: se vale la pena di portare qualcosa ad una seconda fase, o se rimandare le scadenze per fare qualcosa subito.
È importante riconoscere che le funzionalità “out-of-the-box” implicano cose diverse su piattaforme diverse e, nella maggior parte dei casi, un approccio unico non funzionerà per tutte. Il tuo business è unico e avrai senza dubbio esigenze e requisiti particolari che devono essere supportati dalla nuova piattaforma. Se ci sono funzionalità “out-of-the-box” che vuoi personalizzare per le tue particolari esigenze di business (o rimuovere completamente), chiedi subito quanto sia difficile fare questi o altri cambiamenti.
Anche se queste piattaforme moderne sono sofisticate, molto più sofisticate e flessibili rispetto a sette o otto anni fa, cambiare o rimuovere una funzionalità integrata può ancora richiedere molto tempo. È importante essere molto, molto specifici su quali sono i tuoi bisogni e valutare dalla demo come il fornitore gestirà i tuoi requisiti specifici. Potresti scoprire che alcune funzionalità valgono il tempo e lo sforzo extra, mentre di altre potresti fare a meno. L’uso del metodo “MoSCoW” può aiutarti a dare la giusta priorità alle funzionalità:
Il tuo progetto di replatforming non richiede solo la definizione dello scopo della tua soluzione commerciale, ma devi anche assicurarti di raggiungere un allineamento completo del sistema tra tutti i tuoi sistemi di archiviazione esistenti. Un ottimo modo per iniziare è quello di tenere un incontro per il kick-off che coinvolga tutti gli stakeholder che saranno toccati da questo progetto, che nella maggior parte dei casi sarà un grande gruppo che si estende attraverso le aree di marketing, finance, distribuzione, servizio clienti, ufficio legale. Ognuno di questi stakeholder lavora con sistemi di interazione o archiviazione che devono essere presi in considerazione e valutati in termini di cosa cambierà o dovrà essere reintegrato. Questo è anche un ottimo momento per chiedere loro quali problemi attuali hanno con i loro sistemi o strumenti e vedere se ci sono modi per incorporare miglioramenti durante il processo di replatforming.
Vorrai lavorare a stretto contatto con i System Integrator per delineare esattamente ciò che sarà necessario per ogni gruppo di stakeholder nel corso del progetto e per stabilire chiare aspettative. Non c’è modo di evitarlo: avrai bisogno di aiuto e di input da ognuno di loro, a volte molti input. Quindi sii diretto e preciso su ciò che sarà necessario, e invia loro qualcosa di carino alla fine del progetto per mostrare il tuo apprezzamento.
Come ho detto prima, è fondamentale assicurarsi che il tuo progetto di replatforming rimanga strettamente allineato ai tuoi obiettivi di business, dall’inizio alla fine. In molti casi, è il dipartimento IT a guidare questo tipo di iniziative tecnologiche, anche se spesso sono ignari delle esigenze più ampie e degli obiettivi del business. Per quanto noi enfatizziamo la “centralità del cliente”, è sorprendente vedere quanto spesso essa non venga tenuta in considerazione quando si tratta di scegliere quale tecnologia implementare. Sì, nella prima fase del tuo percorso di replatforming potresti dover fare dei compromessi tra le funzionalità di cui beneficiano i tuoi utenti e quelle di cui beneficia il cliente: questa è una transizione impegnativa e devi assicurarti che il tuo team veda il beneficio immediato del replatforming. Ma questo non significa che dovresti perdere di vista gli obiettivi di business e i benefici per i clienti che in definitiva sono il principale stimolo del cambiamento.
La chiave qui è assicurarsi che gli obiettivi di business rimangano sempre in evidenza, al punto da arrivare ad appendere alle pareti cartelloni che delineano gli obiettivi di progetto. È facile bloccarsi sui dettagli, ma avere qualcosa a cui puntare quando il tuo team sta cercando di capire quale sia la giusta direzione o è alle prese con varie alternative, aiuterà a mantenere le cose in movimento verso i giusti obiettivi finali.
Mentre l’istinto iniziale potrebbe essere quello di completare il progetto il più rapidamente possibile per ridurre le interruzioni e dimostrare il ROI più velocemente, la velocità non è sempre una buona cosa e può compromettere ciò che si ottiene come risultato finale. Da un lato, se le cose iniziano a muoversi più lentamente di quanto originariamente previsto, si può sempre scegliere di ridimensionare la portata e spingere alcune funzionalità in un momento successivo per mantenere la data di lancio. Ma in molti casi, la mossa migliore è semplicemente rimandare la data di lancio per evitare circostanze spiacevoli e sacrificare le funzionalità che vorresti avere.
Quando si tratta di mettere in preventivo una linea temporale, può essere utile creare un programma di lavoro a partire dalla tua data di lancio ideale (ma flessibile). Includi il tempo assegnato e le date di completamento per i traguardi importanti, con checkpoint più perseguibili lungo il percorso. Due aree in particolare che finiscono sempre per richiedere una quantità sorprendente di tempo sono la gestione dell’esecuzione del catalogo dal sistema attuale (e poi il suo caricamento nel nuovo sistema), e la connessione della nuova piattaforma agli altri sistemi dell’azienda, come l’ERP, per esempio. Dovrai anche notare tutte le dipendenze (quelle tasks che non possono essere completate fino a quando altre task non sono state a loro volta completate), e tenerne conto nel calcolo dei tempi. Con i traguardi principali, i checkpoint e le dipendenze mappate, puoi iniziare ad assegnare compiti individuali agli stakeholder e leader di progetto in modo che tutti sappiano esattamente cosa è richiesto loro durante ogni fase.
Anche con un programma di lavoro dettagliato, è importante ricordare che questi progetti sono complessi e spesso richiedono più tempo di quanto si pensi. Qualunque sia la quantità di tempo inizialmente preventivata, probabilmente non sarà sufficiente, e va bene così. Basicamente è meglio ipotizzare di avere una quantità di tempo flessibile per consentire un’esecuzione completa che massimizzerà l’impatto della nuova piattaforma, consentendo anche gli inevitabili intoppi.
Questo ci porta al mio prossimo punto…
Il replatforming spesso si rivela più complicato di quanto ci si possa aspettare all’inizio. I tuoi sistemi esistenti potrebbero rivelarsi tecnicamente più complicati di quanto pensassi inizialmente, o potresti imbatterti in certe funzionalità che richiedono implementazioni personalizzate. Ci saranno cose che filano lisce e poi ci saranno quegli imprevisti che saltano fuori inaspettatamente e frenano bruscamente tutto il progetto. Questo è precisamente il motivo per cui è importante impostare aspettative realistiche con gli stakeholder fin dall’inizio e assicurarsi che tutti capiscano che ci saranno inevitabili ritardi e ostacoli sulla strada, specialmente con quegli stakeholder che non hanno un background tecnico. Essi aspetteranno con ansia il ROI di questo progetto che sta costando un bel po’ di soldi e potrebbero essere sorpresi di vedere i tipi di complessità e bug che possono sorgere lungo il percorso, anche quando ci si avvicina al go-live. È fondamentale stabilire la trasparenza e gestire le aspettative fin dall’inizio, sottolineandole spesso, per mantenere alta la fiducia ed evitare la frustrazione durante il progetto.
Probabilmente incontrerai una certa resistenza al cambiamento, perché dopo tutto, gli esseri umani non amano i cambiamenti. Per quanto ovvio possa essere che la tua azienda abbia bisogno di una soluzione nuova e moderna, ci saranno quelli che pensano che i vecchi modi vadano “bene” e potrebbero opporsi. Non importa quanto impeccabile sia l’implementazione della nuova piattaforma, essa avrà successo solo quando verrà adottata in tutta l’azienda. Stabilire una strategia di gestione del cambiamento aiuterà a includere i dipendenti all’interno della nuova piattaforma. Ecco alcuni consigli per iniziare:
Durante il processo di replatforming, dovrai probabilmente bilanciare tra il mantenimento delle funzionalità esattamente come erano nella vecchia piattaforma e l’adattamento delle stesse alla nuova piattaforma. Mentre i System Integrator avranno fatto i test necessari, vorrai comunque condurre il UAT (User Acceptance Testing) per assicurarti che tutto funzioni bene dal punto di vista dell’esperienza utente.
Un elemento in più, ma che non può essere trascurato!
Non c’è niente di più deludente e imbarazzante che arrivare alla fine del progetto di replatforming e fare il go-live solo per scoprire che il sistema non riesce a tollerare il carico. Oppure subito dopo il go-live le cose sembrano andare bene, ma quando si raggiungono i picchi di traffico il sistema crolla. Condurre un test delle prestazioni approfondito e realistico può aiutare a evitare questi problemi.
Ecco quindi le cose che avrei voluto sapere prima di affrontare il replatforming delle operazioni di ecommerce. Quali sono le cose più importanti che vorresti sapere?