Cosa devi sapere sull'integrazione della piattaforma

Oggi ogni azienda è un'azienda digitale, ma fare il salto per trasformare la propria organizzazione in modo che sia adatta allo scopo è una prospettiva scoraggiante sia per coloro che costruiscono una piattaforma da zero sia per coloro che riproducono la piattaforma da un sistema legacy. Dove iniziare? E come evitare le insidie ​​comuni che possono far deragliare un progetto e far esplodere il suo budget, facendo sì che i dirigenti ne mettano in dubbio l'attuazione?

Ho parlato con Brian Walker, un esperto globale di piattaforme di e-commerce che guida la strategia, il marketing e l'ecosistema di SAP Hybris sulle lezioni apprese dall'aiutare un'ampia varietà di aziende a implementare piattaforme che si evolveranno insieme alle esigenze dei clienti, forniranno prestazioni eccezionali e aiuteranno le organizzazioni ottimizzano il loro business per il futuro. Qui, Brian offre alcune riflessioni su ciò che ogni azienda deve sapere per garantire una transizione senza intoppi.

Greg Williams: Hai un cliente che vuole intraprendere un progetto di platforming o re-platforming con te. Quali sono i primi passi di quel viaggio?

Brian Walker: Innanzitutto, i clienti avranno il maggior successo quando non proveranno a far bollire l'oceano – non cercare di realizzare uno scopo troppo grande tanto per cominciare. Quando questo tipo di progetti viene finanziato, tende a esserci una domanda repressa di nuove funzionalità e nuove capacità, tutti sono molto ansiosi di vedere affrontate un sacco di cose. Questo è naturale, ma è davvero importante che le aziende non cerchino di raggiungere tutti i loro obiettivi attraverso un unico progetto. Il modo per vederlo è come un programma in corso. In effetti, non sarà mai davvero fatto in quanto queste capacità saranno fondamentali per il modo in cui coinvolgere e servire i clienti.

GW: Quindi la prima regola è: non avere fretta?

BW: Può esserci un senso di urgenza perché il panorama sta cambiando così rapidamente e molte, se non la maggior parte delle aziende, si sentiranno come se fossero rimaste molto indietro prima di iniziare. Ma quando cercano di ottenere troppo, non hanno un buon governo, ed è qui che lo 'scope creep' alza la sua brutta testa.

GW: Qual è?

BW: un insieme di requisiti in evoluzione e scarsamente definito che introduce modifiche a metà strada. In genere ciò è causato dal fatto che le parti interessate non possono definire ciò che vogliono fino a quando non sono ben inserite nel progetto, oppure i processi aziendali non sono ben compresi. Troppi cuochi in cucina possono significare che ciò che stai cercando di realizzare diventa un obiettivo mobile, il che porta inevitabilmente a sforamenti di budget e ritardi significativi. Questo quindi erode la fiducia di tutti, compresi i vertici aziendali, per quanto riguarda le probabilità di successo. È in quel momento che le persone iniziano a chiedersi: " Questo darà mai i suoi frutti?" Quindi è davvero importante che le persone vedano un rapido time-to-value, che vedano i progressi, anche se la portata è alquanto limitata rispetto a ciò che si desidera ottenere alla fine. È qui che la governance e la disciplina del progetto sono così importanti: mantenere i progetti sui binari.

GW: Quali altre lezioni hai imparato?

BW: È davvero importante concentrarsi e definire le interfacce tra i sistemi nel tuo panorama. Supponiamo che tu abbia il tuo prodotto principale che fornisce dati dal back-end o che tu abbia bisogno di dati di inventario o di accesso ai dati dei clienti da più sistemi. La definizione delle interfacce e l'investimento in interfacce standardizzate scalabili e altamente ripetibili consentono di spostarsi molto più velocemente in seguito.

Quando il lavoro viene svolto nell'ambito di un progetto di grandi dimensioni, ma non c'è abbastanza tempo da dedicare alla codifica e al test di progettazione adeguati, soluzioni alternative o hack attorno a quelle interfacce che ti costeranno in seguito possono facilmente insinuarsi. Questo è un altro luogo in cui molto spesso , ci sono sforamenti di costi e tempi.

La migliore pratica consiste nell'eseguire tali interfacce in anticipo. Prima che si verifichi un'implementazione di grandi dimensioni, creare quelle API che consentono di connettere più sistemi. Definisci queste interfacce in anticipo e investi tempo per integrare correttamente i tuoi sistemi esistenti in modo che siano nell'ambito di queste nuove soluzioni che stai aggiungendo.

Abbiamo investito in alcuni strumenti di integrazione che consentono ai clienti SAP di semplificare notevolmente quella parte di questi progetti, sia che si stia integrando a sistemi SAP o non SAP, ma può comunque essere un ostacolo che molte aziende incontreranno quando si imbarcheranno in un programma come questo.

GW: Cos'altro dovrebbe essere evitato?

BW: In genere per progetti di grandi dimensioni hai assunto una società di consulenza che ti fattura migliaia di dollari al giorno: hai architetti di sistemi, sviluppatori, analisti aziendali, un intero esercito di persone, oltre a tutte le tue risorse interne. Eppure non è nemmeno iniziato il lavoro per definire l'esperienza dell'utente. Tutti sono in giro a dire: " Beh, non possiamo davvero iniziare a lavorare finché non sappiamo come dovrebbe essere ".

La definizione e la progettazione dell'esperienza utente possono iniziare con largo anticipo rispetto all'implementazione dei sistemi. Certo, ci sarà un processo di razionalizzazione per garantire che il design possa adattarsi al progetto o per mettere in fase le caratteristiche, ma nel complesso questo può snellire considerevolmente un progetto. In genere, c'è solo una finestra di tre settimane in un piano di progetto per la progettazione dell'interfaccia utente. Ed è spesso a questo punto che tutto va di traverso quando il senior management o uno stakeholder chiave vengono improvvisamente coinvolti. Forse non sapevano bene cosa volevano, ma sanno che non lo vogliono! Quindi il progetto si ferma quasi a un punto morto mentre i problemi di progettazione vengono risolti. Non bene. Con un po' di pianificazione, è una situazione completamente evitabile.

GW: I piani e le scadenze possono essere concordati, ma immagino che attenersi ad essi sia tutta un'altra sfida...

BW: Hai bisogno di qualcuno che agisca da cane da guardia nell'ambito del progetto e che sia assolutamente impegnato a consegnarlo in tempo. Le persone possono lanciare scadenze ridicolmente aggressive per, ad esempio, una grande implementazione commerciale o un grande sistema di marketing. Il sistema stesso potrebbe non essere necessariamente di grandi dimensioni, ma sono progetti di trasformazione che interessano ogni parte dell'azienda. Ci sarà sempre un piano di progetto: hai bisogno di qualcuno che lo protegga e lo gestisca fermamente, ma sia anche disposto a ridurre la portata delle cose per portare il progetto in tempo. Come ho detto prima, devi vederlo come un programma rispetto a un progetto.

GW: E chi dovrebbe essere quella persona?

BW: Il punto in cui ho visto il maggior successo è dove viene coinvolto un project manager indipendente molto anziano. Non dovrebbe essere qualcuno della società di consulenza che hai assunto per fare l'implementazione dei sistemi, e non dovrebbe essere qualcuno che lavora per il team IT o anche per gli stakeholder aziendali. Hai bisogno di qualcuno in grado di fornire le notizie in modo diretto e il cui unico obiettivo è mantenere il progetto in carreggiata.

GW: E se fosse il lancio di un sito completamente nuovo?

BW: La sfida più grande per un nuovo sito è che a volte il piano e l'ambito del progetto non tengono conto del cambiamento del processo aziendale. Tutti coloro che stanno interagendo con il nuovo sistema devono sapere come usarlo. Potrebbero derivare da un modo abbastanza rozzo e altamente manuale di gestire il proprio sito Web, il processo di vendita o il marketing. È probabile che il nuovo sito e il nuovo sistema siano molto migliori, ma il cambiamento è difficile. Si è tentati di volere strumenti e sistemi che facciano le cose "come se funzionasse qui". Questo può facilmente portare ancora una volta al creep dell'oscilloscopio.

Tuttavia, se non sanno come utilizzare il nuovo sistema e non ci sono contenuti, il processo si ferma. Il contenuto richiesto – contenuto del prodotto, dati dei clienti, contenuto del sito e così via – spesso non è stato realmente preso in considerazione. È necessario creare contenuti per il nuovo sito in modo che sia pronto per l'uso una volta implementato il sistema. Queste sono cose ovvie che finiscono per creare ritardi in termini di costi e tempi che possono essere facilmente risolti in anticipo.

GW: SAP Hybris si è evoluto negli ultimi anni. Puoi accompagnarci in quel viaggio?

BW: Hybris ha iniziato concentrandosi sulle soluzioni commerciali. Ben presto è diventata una delle piattaforme leader a livello mondiale per le aziende per gestire e-commerce su larga scala online e su dispositivi mobili, una piattaforma di commercio omnicanale in grado di gestire e supportare tutti i canali.

Ciò si è evoluto al punto che oggi le soluzioni SAP Hybris coprono l'intero front-office, dall'esperienza del cliente, al commercio, alla fatturazione e al marketing fino agli strumenti per gli addetti alle vendite e all'assistenza sia nei contact center che sul campo.

Il nostro è un insieme molto completo di soluzioni che funzionano insieme, o da sole, per aiutare un insieme diversificato di clienti in tutto il mondo con il modo in cui coinvolgono e servono i clienti. Quindi siamo passati dall'essere una piattaforma di commercio orientata alle transazioni a qualcosa di più onnicomprensivo che offre soluzioni di coinvolgimento dei clienti.

GW: L'e-commerce si sta muovendo in modo incredibilmente rapido. Come l'hai aggiornato per gestire il ritmo veloce del commercio moderno?

BW: C'è una lunga lista di cose che abbiamo fatto per supportare i requisiti aziendali in rapida evoluzione, non solo per l'e-commerce ma attraverso tutti i canali e le funzionalità di front-office. Una cosa che vorrei sottolineare è che un'innovazione più recente è il lancio della nostra nuova piattaforma di microservizi, SAP Hybris-as-a-Service, o quello che chiamiamo YaaS. Questo ambiente di piattaforma consente agli sviluppatori di avviare microservizi per estendere e supportare requisiti univoci nel cloud. Gli sviluppatori possono utilizzare la loro lingua preferita senza vincoli di fornitore per scrivere, testare e lanciare nuovi servizi nel cloud. E forse ancora più eccitante è il mercato che stiamo offrendo a partner, sviluppatori indipendenti e persino clienti per vendere questi microservizi. È una soluzione molto dirompente e sarà molto eccitante vedere come si evolve.