FAQ: Gestione del cambiamento

Un’iniziativa con Lokad mira a ottimizzare la supply chain del cliente con decisioni automatizzate di alta qualità - tipicamente sostituendo compiti quotidiani noiosi come gli ordini di acquisto e le scelte di allocazione delle scorte. Questa pagina affronta domande e preoccupazioni riguardanti il cambiamento portato da questa iniziativa e come gestirlo efficacemente. Gli esperti di Lokad sono sempre disponibili per aiutare i clienti a navigare nel processo.

Destinatari: I reparti di supply chain e/o pianificazione.
Last modified: 19 dicembre 2023

Panoramica della gestione del cambiamento

La Quantitative Supply Chain (QSC), come pionierizzata e promossa da Lokad, si discosta significativamente dalla prospettiva tradizionale. Le differenze sono sia essenziali che le ragioni fondamentali per cui Lokad può offrire miglioramenti così drastici nella supply chain. Detto ciò, la gestione del cambiamento associata all’implementazione di un’iniziativa QSC è più semplice di quanto i nostri clienti comunemente pensino.

Ad esempio, Lokad elimina molti punti di contatto e processi non necessari, invece di sostituire semplicemente uno spreco con un altro spreco. Così, il cambiamento da gestire è tipicamente duplice: prima, adattarsi al fatto che decisioni quotidiane e ripetitive nella supply chain sono ora automatizzate; seconda, accettare che la qualità di queste decisioni automatizzate supera ciò che i dipendenti riuscivano a ottenere con strumenti alternativi (sistemi legacy, fogli di calcolo, e spesso un po’ di entrambi).

Un’iniziativa QSC è guidata dai Supply Chain Scientists. Questi esperti consolidano molti ruoli che normalmente sarebbero svolti da più persone in iniziative simili con altri fornitori di software. Un Supply Chain Scientist funziona come integratore di sistemi, data engineer, analista aziendale, data scientist, esperto di supply chain e project manager (tra gli altri ruoli). I Supply Chain Scientists (SCSs) forniscono tutto il coaching, la formazione, la guida e il supporto necessari affinché i clienti adottino l’approccio quantitativo della supply chain di Lokad.

Il dispiegamento con successo di Lokad (in production) generalmente produce due risultati notevoli: risparmi sostanziali grazie a decisioni migliori nella supply chain e significativi risparmi di produttività grazie a decisioni nella supply chain (per lo più) automatizzate.

In termini di gestione del cambiamento, i risparmi nella supply chain non rappresentano normalmente un problema. L’azienda potrebbe infine decidere di reinvestire il capitale operativo liberato altrove, ma questo tipo di decisione normalmente supera l’ambito dell’iniziativa Lokad. Tuttavia, i notevoli risparmi di produttività generati da Lokad vengono solitamente reinvestiti in altre attività che apportano un valore aggiunto molto maggiore per l’azienda cliente rispetto al processo legacy.

In breve, prima di Lokad, le attività dei professionisti della supply chain all’interno dell’azienda cliente erano quasi esclusivamente incentrate internamente: produrre una previsione, trasformare la previsione in un piano, regolare i livelli min/max di stock sulle SKU, comporre ordini d’acquisto, ordini di produzione, movimenti di stock, ecc.

Una volta che Lokad è in production, la maggior parte delle attività sono orientate all’esterno: identificare ciò che i clienti percepiscono come qualità del servizio, identificare ciò che i fornitori considerano un ostacolo a una ulteriore riduzione dei prezzi, identificare quello che i trasportatori percepiscono come le cause principali della loro inaffidabilità, ecc.

Queste intuizioni vengono poi continuamente integrate nella soluzione di Lokad grazie al supporto costante dei SCSs.

Per i dirigenti della supply chain, il cambiamento più significativo è l’eliminazione (per lo più) della gestione quotidiana delle emergenze. La soluzione di Lokad fornisce decisioni automatizzate progettate per affrontare casi limite fastidiosi, riducendo così sostanzialmente la capacità che i dirigenti devono dedicare all’analisi di comportamenti di mercato erratici. Questo libera i dirigenti della supply chain per pianificare strategie e progetti, invece di gestire in micro dettaglio le conseguenze continue di decisioni subottimali.

Domande Frequenti (FAQ)

1. Implementazione e Gestione del Progetto

1.1 Offrite servizi di gestione di progetto per l’implementazione?

Sì. Questi servizi sono forniti dai Supply Chain Scientists (SCSs) di Lokad. Questi esperti non solo gestiscono l’implementazione, ma guidano anche l’iniziativa insieme all’azienda cliente. Ciò include numerose attività, come fornire rassicurazioni quantitative alla gestione della supply chain per dimostrare la validità delle ricette numeriche di Lokad prima del loro dispiegamento. Gli SCSs forniscono anche materiali di formazione per supportare l’adozione delle pratiche e dei processi raccomandati da Lokad all’interno dell’azienda cliente.

Oltre a ciò, questi esperti rimangono impegnati per il successo a lungo termine dell’iniziativa, anche dopo l’implementazione iniziale, fornendo supporto continuo mentre l’iniziativa transita nella fase di ‘miglioramento continuo’.

Consultate le lezioni di Lokad su the Supply Chain Scientist e A day in the life of a Supply Chain Scientist per maggiori informazioni sul ruolo degli SCS nel processo di ottimizzazione.

1.2 Qual è la vostra timeline di implementazione e quali sono i passaggi o fasi inclusi in questa timeline? Quali sono gli obiettivi di ogni fase (dal kick-off dell’implementazione del progetto al Go-Live)?

Dall’inizio alla fine, l’implementazione richiede solitamente circa 6 mesi. Lokad distingue la fase di onboarding dalla fase di production. L’obiettivo della fase di onboarding è portare la ricetta numerica di Lokad in production. Al termine della fase di onboarding, le decisioni di supply chain di interesse (definite in collaborazione con il cliente) dovrebbero essere automatizzate. Tuttavia, l’automazione è tipicamente solo un effetto collaterale (sebbene molto evidente) dell’intento reale: migliorare le prestazioni della supply chain. L’obiettivo della fase di ‘production’ è quello di affinare, migliorare e riallineare continuamente le ricette numeriche, quelle che permettono l’automazione in primo luogo.

Suddivisione della timeline

La fase di onboarding dura tipicamente 6 mesi e può essere suddivisa in tre sottofasi di 2 mesi ciascuna.

• La prima sottofase è la configurazione del data pipeline. L’obiettivo è creare un pipeline completamente automatizzato per l’estrazione dei dati del cliente verso Lokad. I due aspetti più impegnativi del data pipeline sono stabilire la ‘semantica’ dei dati e rendere il processo di pipeline (quasi) perfettamente affidabile. Un data pipeline, a differenza di un’estrazione dati una tantum, è fondamentale per mantenere le raccomandazioni della supply chain generate da Lokad pertinenti alle attuali preoccupazioni aziendali del cliente.

• La seconda sottofase è la progettazione delle ricette numeriche uniche del cliente - i componenti logici del software che guidano le decisioni della supply chain. L’obiettivo è ottenere ricette che siano coerenti, affidabili e senza fronzoli. La stesura delle ricette numeriche iniziali è rapida, generalmente non richiede più di una o due settimane. Tuttavia, queste bozze sono solo dei punti di partenza, e vengono rapidamente migliorate attraverso iterazioni successive dai Supply Chain Scientist responsabili del rispettivo account. Questo elimina rapidamente quei fastidiosi casi limite presenti nelle bozze iniziali.

• La terza sottofase è il dual run. La ricetta numerica non produce più errori, e i fattori economici che guidano l’ottimizzazione sono stati concordati. Tuttavia, la ricetta non è ancora di livello production. Per procedere, si avvia un dual run. La ricetta numerica viene eseguita in parallelo con il processo legacy. Poiché la ricetta è automatizzata, il sovraccarico organizzativo è ridotto. Ogni giorno, i professionisti della supply chain possono confrontare le decisioni e osservare lo sviluppo di schemi (ad es., la stagionalità). Attraverso diverse settimane di dual run, si acquisisce la fiducia necessaria per procedere con il roll-out in production.

Alla fine della fase di onboarding - e se tutti i passaggi sono stati completati - inizia il roll-out in production. Questo roll-out consiste nel lasciare che l’automazione prenda il controllo del processo legacy. Questo passaggio può anche essere graduale, a seconda della capacità del cliente di supervisionare la gestione del cambiamento necessaria.

Consultate la panoramica della timeline per una descrizione più dettagliata di ogni fase coinvolta nel processo di ottimizzazione.

1.3 Lokad documenta e pubblica un piano di gestione del progetto che dettagli l’ambito, il programma/cronoprogramma, le tappe critiche, il resourcing, i deliverables, le responsabilità, il piano di gestione dei costi, il piano di gestione della qualità, il piano di gestione dei rischi e il piano di gestione e comunicazione degli stakeholder?

Sì. Tutti questi elementi, e altro ancora, sono raccolti in un unico Manuale di Procedura Congiunta (JPM) per l’iniziativa. I Supply Chain Scientists (SCSs) sono responsabili dell’avvio e del mantenimento del JPM per tutta la durata dell’iniziativa.

Il JPM di Lokad si concentra sulle domande del “perché?”. I JPM sono ben scritti e destinati ad essere accessibili anche a un pubblico meno tecnico e/o non specializzato. Il JPM cattura l’essenza dell’intento alla base dell’iniziativa e consolida le intuizioni fondamentali man mano che vengono acquisite durante l’iniziativa.

Lokad sostiene che molte (se non la maggior parte) iniziative aziendali sono ostacolate dalla produzione di documenti inutili, che in pratica risultano impossibili da leggere (cioè, sono noiosi o impenetrabilmente tecnici). Tali documenti non hanno nessun altro scopo se non quello di compilare caselle fittizie. Inoltre, molti terzi (ad es., integratori, consulenti e persino la burocrazia interna) hanno una forte tendenza a privilegiare la quantità rispetto alla qualità nella documentazione del progetto.

Al contrario, i JPM di Lokad sono concepiti per essere sia leggibili che effettivamente letti. I JPM sono strumenti utilizzati dagli stessi SCSs per gestire l’iniziativa. Pur avendo linee guida dettagliate su ciò che ci si aspetta di trovare in un JPM, spetta infine agli SCSs prendere decisioni ponderate su ciò che richiede maggiore attenzione e sforzo, in base alle specificità dell’iniziativa.

Consultate la lezione Scrittura per la Supply Chain per maggiori informazioni sull’etica della documentazione di Lokad.

1.4 Lokad è responsabile del mantenimento e della definizione delle linee base del piano di gestione del progetto, previo l’approvazione da parte del comitato direttivo del progetto? Qualora emergessero deviazioni dal piano, le comunicherete chiaramente insieme alle opzioni di mitigazione?

Sì. Le responsabilità elencate sono gestite dai Supply Chain Scientists (SCSs) di Lokad. I dettagli della gestione della comunicazione con l’azienda cliente dipendono tipicamente e sono definiti nei termini contrattuali dell’iniziativa stessa.

Talvolta, ci sono significativamente più dipendenti coinvolti dal lato cliente rispetto a quelli di Lokad; per migliorare la produttività degli SCSs che gestiscono il conto, molti dei nostri clienti designano un unico punto di contatto per l’iniziativa. Questa persona - o piccolo team - è incaricata di trasmettere le informazioni rilevanti e di raccogliere feedback significativi da tutte le parti coinvolte dal lato cliente del progetto.

Per un’iniziativa particolarmente complessa, Lokad istituisce un comitato direttivo dedicato composto dai membri chiave sia di Lokad che dell’azienda cliente. Sebbene questo incontro serva come meccanismo per ottenere l’approvazione formale, la maggior parte del lavoro sostanziale avviene al di fuori del comitato stesso. Gli SCSs interagiscono quotidianamente con vari team del lato cliente. Tali team vengono costantemente aggiornati su eventuali deviazioni dal piano e si assicurano che l’intera iniziativa rimanga sulla giusta strada. Queste interazioni quotidiane sono un modo molto più efficace per discutere e superare i problemi tecnici non appena si presentano, piuttosto che cercare di analizzare grandi quantità di problemi durante una sessione del comitato direttivo. Pertanto, il comitato direttivo, in quanto tale, agisce come un organo di supervisione piuttosto che come un think tank per l’iniziativa.

Nota: Le iniziative di quantitative supply chain sono note per incontrare frequentemente “deviazioni positive”. Queste sono sorprese benefiche nelle ricette che si rivelano durante il mantenimento continuo dell’iniziativa. In sostanza, sono opportunità troppo vantaggiose per essere lasciate perdere. Pertanto, un vantaggio chiave dell’approccio di Lokad alla comunicazione è la capacità di trasmettere tempestivamente ed efficacemente queste deviazioni positive al cliente non appena si presentano, aumentando così significativamente l’impatto e l’agilità dell’iniziativa.

1.5 Documenterete il piano di comunicazione, che include stand-up giornalieri, report di stato settimanali dei gruppi di lavoro e sessioni di revisione, nonché report mensili del comitato direttivo e sessioni di revisione? Delineerete i criteri di escalation e assicurerete un accordo reciproco tra l’azienda cliente e Lokad su questi dettagli?

Sì. I Supply Chain Scientists (SCSs) di Lokad sono responsabili di questi compiti. I dettagli della gestione della comunicazione all’interno dell’azienda cliente dipendono tipicamente dai termini contrattuali dell’iniziativa stessa.

Lokad partecipa volentieri agli stand-up giornalieri quando è in sede presso la headquarters dell’azienda cliente. Di solito, tuttavia, i nostri SCSs operano presso gli uffici di Lokad.

Consolidiamo tutta la documentazione dell’iniziativa in un Manuale di Procedura Congiunta (JPM) che funge effettivamente da guida completa per l’intero progetto. Il JPM include le note di tutte le sessioni di lavoro, compresi i report del comitato direttivo (quando applicabile).

Sebbene Lokad chiarisca i criteri e le linee guida per l’escalation, vale la pena sottolineare che ci si aspetta che un Senior SCS di Lokad gestisca qualsiasi domanda o preoccupazione riguardante l’iniziativa. Pertanto, per quanto riguarda l’escalation, la risoluzione di un problema critico viene tipicamente portata dal Junior SCS a un Senior SCS. Ciò si è storicamente dimostrato sufficiente, con pochissime situazioni che richiedono ulteriori escalation.

Lokad considera ogni problema – per quanto possa sembrare insignificante – degno di un’analisi approfondita. Sebbene i loro effetti siano facili da risolvere, i problemi minori potrebbero causare complicazioni future se le cause profonde non vengono comprese e affrontate. Ciò impedisce che un problema minore diventi ricorrente. Pertanto, Lokad predilige mettere in prima linea persone altamente capaci, in grado di affrontare sia il problema immediato sia di individuare le cause profonde sottostanti. Questo approccio è preferibile rispetto a fare affidamento su personale di supporto non addestrato che affronta continuamente gli stessi problemi – una prassi troppo spesso adottata da molti fornitori di software per imprese.

Pertanto, il processo di escalation conciso di Lokad è intenzionale, garantendo soluzioni rapide e durature.

1.6 Garantirete che il piano di gestione del progetto venga approvato da tutti gli stakeholder come parte della fase di avvio del progetto?

Sì. In generale, i Supply Chain Scientists (SCSs) di Lokad seguono il processo che è stato negoziato e concordato con ogni cliente – secondo i termini contrattuali formali. Questo principio rimane applicabile per tutta l’iniziativa, dall’inizio alla fine. L’avvio del progetto è certamente importante, anche se, dato che Lokad non richiede un impegno a lungo termine fin dal primo giorno, questa questione è di minore importanza – soprattutto se confrontata con i nostri concorrenti.

Va notato che non abbiamo mai osservato una supply chain funzionare male a causa di una ‘mancanza’ di burocrazia e di altri processi frivoli. Al contrario, le burocrazie inutili e i processi insensati sono i problemi più comuni riscontrati nelle supply chain moderne – presenti anche in aziende che altrimenti sembrano avere supply chain ad alte prestazioni.

1.7 Distribuirete un project manager dedicato di Lokad presso la sede centrale dell’azienda cliente, accompagnato da esperti di prodotto, analisti aziendali ed esperti di interfacce tecniche?

Sì, se tali disposizioni fanno parte dei termini contrattuali concordati per l’iniziativa. Sebbene Lokad non si opponga a schierare dipendenti presso la sede centrale dell’azienda cliente, ciò naturalmente aumenta il costo dell’iniziativa. La maggior parte delle nostre iniziative viene eseguita in remoto e supportata da visite mensili o trimestrali a seconda della portata dell’iniziativa. Questa prassi è solitamente percepita da tutte le parti come più efficiente rispetto alla presenza continua di dipendenti Lokad negli uffici del cliente. Va notato che, anche se Lokad accetta di assegnare un team permanente presso la sede centrale dell’azienda cliente, i dipendenti ruoteranno nel tempo.

Tali prassi avvantaggiano tutti i soggetti coinvolti, poiché i Supply Chain Scientists (SCSs) di Lokad sono soggetti a un programma di formazione continuo. Questo programma è fondamentale per garantire che i nostri dipendenti continuino ad acquisire nuove competenze o a perfezionare quelle vecchie, indipendentemente dall’esperienza o dalla seniority. Pur osservando che molti fornitori di software per imprese consentono ai propri dipendenti di operare per mesi, se non anni, presso siti remoti dei clienti, Lokad è convinto che questa prassi non sia compatibile con la fornitura affidabile ed efficiente di programmi di formazione di alta qualità.

In particolare, una delle maggiori forze dei SCSs di Lokad è il loro insieme di competenze eccezionalmente variegato e ampio. Ogni SCS è formato per operare in diverse mansioni, come: esperto di materia, analista aziendale, esperto di interfacce tecniche, data scientist e consulente di supply chain. Queste funzioni sarebbero normalmente svolte da più dipendenti, comportando un notevole aumento dei costi per il cliente. In Lokad, ogni SCS fornisce tutti questi servizi.

Di conseguenza, i SCSs tendono a essere molto più produttivi (meno persone significano generalmente meno attriti nella comunicazione) e raggiungono livelli di prestazione più elevati. In realtà, le supply chain dipendono criticamente da una coerenza end-to-end, qualcosa di molto più facile da ottenere con un numero ridotto di persone.

1.8 Durante la fase di implementazione, quale organizzazione proponete? Dove dovrebbero essere allocate le risorse?

Per una tipica iniziativa in Lokad, raccomandiamo che l’azienda cliente assegni un esperto di supply chain come coordinatore dell’iniziativa e nomini anche un dirigente di supply chain come supervisore dell’iniziativa. Il coordinatore funge da punto di contatto tra il team di Supply Chain Scientists (SCSs) di Lokad e l’azienda cliente. Inizialmente, il coordinatore trasmetterà le richieste di informazioni, e in seguito quelle di feedback. In parallelo, i SCSs di Lokad lavorano sui modelli numerici volti a produrre le decisioni di supply chain di interesse.

Raccomandiamo un incontro settimanale per esaminare l’avanzamento dell’iniziativa fino al completamento della fase di onboarding. Questo incontro è sistematicamente preso in carico dal coordinatore, dal supervisore e dal principale SCS di Lokad dedicato al cliente. Altri partecipanti possono unirsi se necessario, ma la loro presenza continua di solito non è indispensabile durante tutta la fase di implementazione/onboarding.

Alcune risorse IT devono essere allocate per l’installazione del data pipeline all’inizio dell’iniziativa. Lokad è più efficiente rispetto alla maggior parte dei suoi pari in questo ambito. Ad esempio, estraiamo automaticamente e direttamente i dati transazionali del cliente, senza alcuna pulizia o preparazione lato cliente. A meno che l’azienda cliente non stia vivendo una situazione di vendor lock-in, questa configurazione tecnica richiede meno di 4 settimane di lavoro per un singolo collaboratore - e talvolta molto meno quando è già presente un data lake.

Successivamente, i SCSs dovranno raccogliere informazioni qualitative sui processi esistenti, nonché sui dettagli di tutte le priorità e vincoli della supply chain. Di solito si svolge una serie di interviste, facilitate dai coordinatori, per supportare questo processo. In seguito, una volta che i SCSs hanno sviluppato i modelli numerici, si terrà un’altra serie di interviste per revisionare le cifre generate da tali modelli e permettere ai SCSs di perfezionarli e migliorarli.

Il contributo del supervisore è importante sia per allineare Lokad con la strategia di alto livello perseguita dall’azienda sia per evitare che l’iniziativa si blocchi a causa dell’indecisione. Ad esempio, Lokad può proporre diverse opzioni per modellare i costi associati alla mancanza di qualità del servizio. Possiamo spiegare i vantaggi e gli svantaggi di queste opzioni in termini non tecnici, ma, in definitiva, devono essere prese alcune scelte strategiche.

Naturalmente, tutto quanto sopra dipende dalle esigenze specifiche dell’iniziativa. Siamo aperti ad altri approcci organizzativi se meglio si adattano al contesto e agli obiettivi specifici dell’azienda cliente.

Per ulteriori informazioni, Lokad offre diverse lezioni dedicate alla esecuzione tattica e strategica di una ottimizzazione di supply chain di successo.

2. Gestione delle Risorse & Requisiti

2.1 Quali sono i requisiti di personale per l’implementazione del progetto presso l’azienda cliente, in particolare il numero di risorse e il loro livello di competenza? Potete definire in modo preciso il numero di risorse per ogni fase e sottofase del progetto?

Una tipica iniziativa di Lokad richiede circa 0,5 fino a 2 FTE (equivalenti a tempo pieno) di risorse dipendenti dell’azienda cliente durante i primi 6 mesi – ovvero, la fase di onboarding. Una volta che l’iniziativa entra in produzione, una stima ragionevole è che il progetto richieda comunque almeno 0,25 FTE. Naturalmente, queste stime variano sostanzialmente in base alle dimensioni e alla complessità dell’azienda cliente e alle specifiche esigenze della supply chain.

In termini di risorse richieste in ogni fase di un’iniziativa “tipica”, durante la fase di onboarding abbiamo:

• Mesi 1 e 2: L’installazione del data pipeline richiede 4 settimane di impegno a tempo pieno da parte di un data officer, tipicamente impiegato nell’IT del cliente. Il data officer dovrebbe essere abbastanza familiare con il panorama applicativo dell’azienda cliente. Questo requisito può essere ridotto se è già presente un data lake, ma al contrario, aumenterà se il data pipeline deve gestire molteplici sistemi aziendali (ad es., 1 ERP per paese). Una volta che il data pipeline è operativo, la sua manutenzione non dovrebbe richiedere più di poche ore al mese da parte del data officer.

• Mesi 3 e 4: La progettazione del modello numerico richiede 2 o 3 giorni a settimana dal coordinatore (dal lato cliente) dell’iniziativa, un minimo di 10 ore a settimana da vari operatori della supply chain per fornire intuizioni ad alto livello e, successivamente, per fornire feedback sulle cifre prodotte da Lokad. Si prevede che il coordinatore sia familiare con l’azienda e la sua supply chain, e che si senta a suo agio con il lavoro analitico. Tuttavia, questa posizione non richiede competenze IT specializzate né specifiche competenze di data science. La revisione settimanale dell’iniziativa richiede mezza giornata a settimana da parte di un dirigente della supply chain.

• Mesi 5 e 6: I requisiti sono sostanzialmente gli stessi della fase precedente, tuttavia, il focus cambia. Il coordinatore ora trascorre la maggior parte del suo tempo preparando il corretto roll-out e comunicando con tutti gli operatori della supply chain interessati. Allo stesso modo, il dirigente della supply chain supervisiona il change management interno legato ai nuovi processi derivanti dall’iniziativa di Lokad.

Vedi anche Implementazione e Gestione del Progetto 1.2.

2.2 Garantite che venga pianificato un adeguato organico per supportare la transizione del prodotto?

Sì. Come regola empirica, Lokad raccomanda di mantenere lo stesso quantitativo di risorse (ad es., gli stessi Supply Chain Scientists) durante la transizione dalla fase di onboarding a quella di produzione. Il potenziale ritorno sull’investimento di una soluzione ben mantenuta e continuamente migliorata è sostanziale. È un errore affrontare la risoluzione di tali sfide con un approccio “set-and-forget”, poiché qualsiasi soluzione tecnica finirà inevitabilmente – e continuamente – per diventare irrilevante e obsoleta se non adeguatamente monitorata e mantenuta.

Vale la pena notare che, dato che Lokad automatizza le decisioni della supply chain, non c’è un’urgenza stringente nel formare nuovamente tutti gli operatori della supply chain del cliente con un nuovo processo per mantenere in movimento le ruote della supply chain - l’automazione stessa è progettata per occuparsene. Di conseguenza, non è raro che la completa riorganizzazione della struttura della supply chain del cliente – innescata dall’iniziativa di Lokad – venga completata pochi mesi dopo il lancio del progetto.

Questo approccio snello è in netto contrasto con le grandi – e costose – “task force” spesso richieste dai fornitori di software per imprese per andare live.

2.3 Potete garantire che un organico sufficiente e risorse di knowledge product (KP) siano disponibili onsite presso la sede centrale dell’azienda cliente per supportare la transizione del prodotto?

Sì, tali disposizioni e requisiti sono coperti dai termini contrattuali specifici e concordati reciprocamente per l’iniziativa.

Vedi anche Implementazione e Gestione del Progetto 1.7.

Vedi anche Gestione delle Risorse & Requisiti 2.2.

2.4 Organizzate sessioni di revisione dei requisiti con i responsabili di prodotto aziendale per elicitarli e documentarli?

Sì. Uno dei primi obiettivi del Supply Chain Scientist è acquisire tutte le informazioni necessarie sulla supply chain del cliente. Questo processo viene tipicamente condotto attraverso interviste con gli stakeholder rilevanti, compresi i responsabili di prodotto aziendale. Cerchiamo inoltre di esaminare attentamente i documenti esistenti (quando disponibili) per trarne il massimo vantaggio per tali interviste.

Tuttavia, la principale preoccupazione di Lokad è capire il “problema” in esame, cosa che non viene sempre favorita dall’elencare i “requisiti”. Ad esempio, se un cliente menziona di avere bisogno di una gestione speciale per i “slow movers”, comprendiamo che il volume ridotto è una problematica da affrontare. Tuttavia, trattare in modo particolare quegli SKU è solo una delle molte opzioni disponibili per affrontare questa problematica.

In questo esempio, la nostra preferenza sarebbe determinare la vera natura dei “slow movers”. Infatti, dopo aver indagato sui punti dolenti della supply chain del cliente, potrebbe emergere che i “slow movers” siano SKU che sono stati mal prezzati, raggruppati e/o allocati. Una volta compreso meglio il problema (i slow movers), la strategia di intervento cambia completamente, spesso rendendo più facile l’affronto.

Pertanto, anche se Lokad estrae e documenta tutti i requisiti del cliente, il nostro approccio enfatizza la scoperta della vera natura del problema, piuttosto che accettare per certo lo stato attuale della supply chain del cliente.

Vedi Innamorati del Problema, non della Soluzione per maggiori dettagli sulla dicotomia problema-soluzione.

2.5 Fornite stime sugli sforzi, i costi e i tempi per le funzionalità che richiedono personalizzazione, comprese le interfacce di sistema, e le condividete dopo il workshop di analisi fit-gap del processo?

Sì. Queste stime sono generalmente incluse nella nostra proposta commerciale iniziale. Se viene organizzato un workshop per preparare l’iniziativa, utilizzeremo le informazioni raccolte per perfezionare ulteriormente la nostra proposta.

La piattaforma Lokad è programmabile. Pertanto, l’implementazione è concepita per essere supportata da script, scritti in Envision, il nostro DSL (linguaggio di programmazione specifico per il dominio) dedicato all’ottimizzazione predittiva delle supply chain. Di conseguenza, Lokad è particolarmente adatto a fornire funzionalità e interfacce su misura, siano esse destinate alle persone o ai sistemi aziendali dell’azienda cliente.

A differenza della maggior parte dei software per imprese, la programmabilità è una caratteristica centrale per Lokad. Gli script Envision menzionati non rappresentano una “personalizzazione” della soluzione Lokad nel senso usuale. Né la presenza di tali script costituisce una deviazione dal ramo principale di sviluppo della soluzione Lokad. Piuttosto, la ricca programmabilità di Lokad è il percorso d’implementazione previsto.

Di conseguenza, c’è un grado estremamente elevato di certezza associato alle nostre stime (costi, tempi, ecc.). La stragrande maggioranza dei progetti rimane nei limiti delle stime/budget iniziali (in ogni senso). Questo contrasta con ciò che accade con diversi concorrenti di Lokad, per i quali ritardi costosi e riformulazioni dei termini sono comuni.

Vedi Case Study sul Debacle SAP da 500 Milioni di € di Lidl per ulteriori informazioni su questo punto.

2.6 Implementerete e manterrete una strategia di retention ragionevole volta a trattenere il personale chiave che svolge i servizi per la durata dell’accordo? Mantenete inoltre piani di successione attivi per ciascuna delle posizioni chiave del personale di Lokad?

Sì. Manteniamo i dipendenti per una durata media di 3,5 anni, quasi il doppio della permanenza lavorativa rispetto a coorti simili (ingegneri di talento nel settore IT o in settori affini) in mercati analoghi (Nord America e Europa Occidentale). Questo segmento del mercato del lavoro è estremamente competitivo e, sebbene ci sia sempre margine di miglioramento, ciò pone Lokad ben al di sopra della maggior parte dei nostri concorrenti. Di conseguenza, la maggior parte delle iniziative di Lokad beneficia del fatto di avere gli stessi Supply Chain Scientists (SCSs) da un anno all’altro.

Questo tasso di fidelizzazione è attribuibile a salari competitivi e all’investimento continuo di Lokad nella formazione dei propri team. In particolare, i contenuti relativi alla supply chain pubblicati da Lokad sul proprio sito web, in particolare la nostra serie di lezioni sulla supply chain, possono essere visti come un sottoprodotto dell’attenzione di Lokad alla formazione del proprio personale. In generale, i fornitori di software per imprese che non dispongono di materiali formativi pubblici quasi mai hanno anche materiali formativi privati (anche se in ogni caso sostengono il contrario).

Per quanto riguarda i piani di successione, adottiamo due pratiche importanti. Innanzitutto, ogni iniziativa di Lokad è accompagnata da un Joint Procedure Manual (JPM). Il JPM è il documento principale utilizzato da un nuovo SCS per familiarizzare rapidamente con tutte le intuizioni e le specificità tecniche dell’iniziativa. In secondo luogo, ogni iniziativa prevede - in ogni momento - sia un SCS primario che uno secondario. Anche se lo SCS secondario non contribuisce direttamente all’iniziativa, Lokad dedica il tempo necessario per assicurarsi che questa persona sia pronta a prendere in carico l’iniziativa qualora sorgesse la necessità. Questa pratica mitiga in gran parte le complicazioni legate a assenze impreviste o al turnover.

3. Ruoli, Responsabilità & Gestione degli Stakeholder

3.1 Qual è il livello di cooperazione che intrattenete con l’azienda cliente?

Il livello di cooperazione che intratteniamo con i nostri clienti varia, ma complessivamente è molto superiore rispetto a quello generalmente atteso da un fornitore di software per imprese. Le problematiche legate alla supply chain non sono ugualmente importanti per tutte le aziende, pertanto la collaborazione tende a essere più intensa per le aziende in cui la supply chain è la spina dorsale (riconosciuta) delle loro attività.

Il termine ‘partner’ è stato banalizzato al punto che anche i fornitori di prodotti software di poco conto (come il software per il tracciamento del tempo) finiscono per essere definiti ‘partner’. Tuttavia, dopo uno o due anni, la maggior parte dei nostri clienti definisce la propria relazione con Lokad come una partnership ‘autentica’ – nel vero senso della parola. Hanno volti noti in Lokad che hanno guadagnato la loro fiducia e, di conseguenza, queste persone – tipicamente i Supply Chain Scientists (SCSs) – conoscono a fondo il loro business. Inoltre, i nostri risultati sono spesso considerati sufficientemente notevoli da essere presentati personalmente al CEO e/o al consiglio di amministrazione, anche nelle grandi aziende.

La collaborazione continua con Lokad permette ai nostri clienti di ristrutturare positivamente l’intera pratica della supply chain. Alla fine, l’intera catena viene rivisitata, con un impatto positivo sia sui clienti che sui fornitori. È importante notare che Lokad non ha alcuna intenzione di sostituire la fondamentale competenza strategica esistente nell’azienda cliente. Piuttosto, Lokad intende automatizzare gli aspetti più banali e ripetitivi dei processi decisionali della supply chain. Questo approccio libera risorse significative – e spesso scarse – dell’azienda cliente, che possono essere reindirizzate verso usi migliori.

3.2 Quali ruoli e responsabilità vi aspettate siano in atto, sia all’interno dell’azienda cliente che in Lokad, per massimizzare l’efficacia della soluzione?

Ci sono 4 ruoli tipici coinvolti nelle iniziative quantitative della supply chain di Lokad.

• Il Supply Chain Leader: Questo ruolo sottolinea l’importanza del coinvolgimento del top management nell’iniziativa quantitativa della supply chain. Pur non essendo previsto che si immerga nei dettagli tecnici, questa persona deve comprendere e comunicare le intuizioni strategiche dell’iniziativa. Il suo compito non è creare metriche e KPI, bensì valutarli e metterli in discussione in modo critico, garantendone l’allineamento con la strategia complessiva.

• Il Supply Chain Coordinator: Fondamentale per garantire il regolare funzionamento dell’iniziativa, questa persona funge da ponte tra i vari team interni. La sua responsabilità principale è raccogliere feedback, comunicare con gli stakeholder e confermare/chiarire processi e decisioni. Assicura che l’iniziativa sia in linea con i flussi di lavoro esistenti dell’azienda, mantenendo allo stesso tempo una mente aperta a possibili revisioni future dei processi.

• Il Data Officer: I dati sono la spina dorsale dell’iniziativa quantitativa della supply chain e questa persona ne garantisce l’accessibilità e l’affidabilità. Incaricato di estrarre set di dati completi (come le cronologie di vendite e acquisti), è responsabile dell’automatizzazione e della programmazione dell’estrazione dei dati. Pur essendo il suo ruolo più intenso all’inizio dell’iniziativa, il suo contributo è cruciale per il successo.

• Il Supply Chain Scientist: Questo ruolo unisce le intuizioni del Supply Chain Coordinator con i dati forniti dal Data Officer per automatizzare i processi decisionali. A partire dalla preparazione dei dati, il Supply Chain Scientist collabora strettamente con il Coordinator per chiarire eventuali ambiguità nei dati. Successivamente, formalizza strategie in decisioni operative, come le quantità di riordino, e implementa dashboard e KPI per garantire trasparenza e controllo.

Vedi ruoli del progetto per maggiori informazioni sulle diverse designazioni all’interno di un’iniziativa quantitativa della supply chain.

3.3 Avete una tabella RACI (Responsible / Accountable / Consulted / Informed) completa per la fase di implementazione e per quella di produzione?

Sì. Queste informazioni possono essere presentate esplicitamente sotto forma di tabella RACI, se ritenuto importante dall’azienda cliente.

Ancora più importante, i Supply Chain Scientists (SCSs) interiorizzano questo tipo di matrice per prendere decisioni adeguate e rapide man mano che l’iniziativa avanza. Per quanto riguarda le questioni relative all’ottimizzazione della supply chain, il punto cruciale è capire il modo migliore di inquadrare il problema. Successivamente, l’attenzione si sposta sull’individuare chi, all’interno dell’organizzazione, è nella posizione migliore per affrontare il problema. Fondamentale è che tutta questa analisi venga fatta rapidamente per mantenere lo slancio dell’iniziativa.

A tal fine, gli SCS di Lokad sono designati a guidare l’iniziativa e a prendersi la responsabilità della qualità dei risultati generati dalla ricetta numerica di Lokad.

In tal modo, è un piccolo nucleo di specialisti altamente formati a essere responsabile delle decisioni relative alla supply chain generate da Lokad – piuttosto che un elaborato “sistema” o “processo” di delega di porzioni di responsabilità tra un ampio gruppo di stakeholder. La posizione di Lokad è che tali sistemi tendano a diluire la responsabilità, piuttosto che a renderla rigida. I nostri SCS sono, pertanto, formati per adottare e operare con questa responsabilità, il che include assicurarsi che gli stakeholder rilevanti nell’azienda cliente siano consultati e pienamente informati sull’iniziativa.

3.4 Documenterete ruoli e responsabilità utilizzando una matrice RACI (Responsibility, Accountability, Consulted, and Informed) per tutti gli stakeholder coinvolti nel progetto? Garantirete che questo documento venga discusso e approvato da tutte le parti coinvolte?

Sì. Tutti questi elementi (e altro ancora) sono raccolti e documentati nel Joint Procedure Manual (JPM). Il JPM è redatto dai Supply Chain Scientists (SCSs) di Lokad (con intuizioni raccolte direttamente dall’azienda cliente). In questo documento vengono dettagliati i parametri del ruolo e delle responsabilità di ciascuna persona.

Il JPM funge anche da risorsa continua per l’iniziativa ed è redatto dagli SCS assegnati all’azienda cliente. Redigere questo documento con parole proprie dimostra che gli SCS hanno dedicato tempo considerevole a esaminare, diagnosticare e analizzare la supply chain del cliente e la soluzione generale (senza limitarsi a ripetere la letteratura preesistente del cliente).

Eventuali revisioni del JPM vengono condivise con l’azienda cliente. Il JPM stesso viene discusso regolarmente durante le sessioni di lavoro tra Lokad e l’azienda cliente.

A proposito, la nostra esperienza indica che qualora sorgessero disaccordi, questi rispecchiano solitamente una problematica organizzativa da risolvere all’interno dell’azienda cliente. Per questo motivo, raccomandiamo all’azienda cliente di nominare un Supply Chain Executive per supervisionare l’iniziativa. Uno dei loro contributi chiave è quello di fungere da tramite quando si presentano tali situazioni.

3.5 Garantirete che il gruppo di lavoro del progetto e i gruppi di indirizzo siano formati con risorse nominate degli stakeholder del progetto? Garantirete che il ritmo operativo venga concordato da tutte le parti coinvolte?

Sì. Come principio generale, seguiamo qualsiasi processo ritenuto necessario dall’azienda cliente e formalmente concordato con essa. Gli elementi concordati (e le eventuali modifiche apportate man mano che l’iniziativa procede) sono documentati nel Joint Procedure Manual (JPM), che include dettagli riguardanti il gruppo di lavoro del progetto e i gruppi di indirizzo. Attraverso i Supply Chain Scientists (SCSs) di Lokad, disponiamo delle risorse necessarie per implementare e monitorare questi processi.

Aneddoticamente, uno dei contributi più spesso apprezzati di Lokad è la nostra capacità di semplificare i processi – siano essi relativi alla supply chain o di natura burocratica. Nel tempo, lavoriamo attivamente per eliminare strati burocratici superflui dalle supply chain dei nostri clienti.

4. Transizione del Sistema & Go-Live

4.1 Qual è la durata della transizione dal kick-off al go-live?

La durata tipica della fase di onboarding è di 6 mesi. Questa fase inizia con il kick-off e termina quando Lokad è ‘in produzione’ - cioè quando le nostre raccomandazioni automatizzate per la supply chain guidano efficacemente i processi decisionali desiderati dal cliente.

Questa durata può essere ridotta di 1 mese se è già presente un data lake – un data lake ben strutturato e documentato può ulteriormente abbreviare la fase di onboarding. Al contrario, questa fase viene solitamente prolungata da 1 a 3 mesi quando l’ambiente software o di sistemi del cliente è eccessivamente complesso o obsoleto.

Curiosamente, la complessità della supply chain in sé non è così impattante come potrebbe sembrare, poiché Lokad si sforza di definire uno scope sufficientemente preciso da essere realizzabile entro il lasso di tempo previsto. La nostra esperienza indica che fasi di onboarding superiori a 6 mesi mettono l’iniziativa a rischio di stagnazione. Pertanto, ingegniamo attivamente lo scope per mitigare questo rischio.

Tali ritardi hanno poco a che fare con l’assetto tecnico di Lokad stesso. Complessivamente, la timeline suggerita non serve solo a scopi tecnici (automatizzazione dell’estrazione dei dati, test delle ricette numeriche, ecc.), ma consente anche ai Supply Chain Scientists (SCSs) di Lokad di diventare pienamente competenti in tutte le specificità dell’azienda cliente, e alle squadre della supply chain di “assimilare” l’approccio di Lokad – qualcosa che solitamente rappresenta una deviazione dal processo storico del cliente.

4.2 Quante visite in loco prevedete? Quanti workshop in loco pianificate?

Il numero di visite e workshop in loco è negoziato come parte dei termini contrattuali specifici con l’azienda cliente, sebbene sia da notare che i costi di viaggio possono influire sulle tariffe applicate da Lokad. Di conseguenza, l’inclusione delle visite in loco è, in ultima analisi, una decisione che spetta all’azienda cliente, e Lokad si adeguerà alla frequenza desiderata.

Quando l’obiettivo dell’azienda cliente è mantenere l’iniziativa il più snella possibile, siamo a nostro agio con un’iniziativa completamente remota, cioè senza visite in loco. Raccomandiamo questo approccio per le aziende più piccole (fatturato annuo inferiore a 100M USD) e per quelle aziende che generalmente sono a loro agio con collaboratori remoti (come le grandi aziende di eCommerce). Circa la metà delle iniziative realizzate da Lokad rientra in questa categoria.

Quando l’obiettivo dell’azienda cliente è massimizzare le probabilità di gestire con successo il cambiamento, siamo a nostro agio con visite mensili - e possibilmente con una frequenza ancora maggiore se necessario. Per le grandi aziende (fatturato annuo superiore a 1B USD), raccomandiamo almeno una visita/workshop in loco ogni trimestre. Questo approccio aiuta a sviluppare un allineamento a livello aziendale, soprattutto quando sono coinvolti team di considerevoli dimensioni.

Per i nostri clienti in Europa Occidentale, tendiamo ad effettuare più visite (solitamente della durata di una singola giornata) rispetto ai workshop quando siamo in loco. Per i nostri clienti al di fuori dell’Europa Occidentale, tendenzialmente realizziamo più workshop (solitamente della durata di più giorni) rispetto alle visite in loco. Tale differenza è semplicemente una questione di costi di viaggio e logistica.

4.3 Qual è l’equilibrio ideale tra riunioni remote e in loco?

Per un’iniziativa quantitativa della supply chain, la maggior parte delle riunioni dovrebbe essere remota. La maggior parte degli incontri è breve (30 minuti o meno) e coinvolge solo due partecipanti: un Supply Chain Scientist di Lokad e un operatore della supply chain dell’azienda cliente. Inoltre, le riunioni remote sono vantaggiose per compiti tecnici specifici, poiché tutti i partecipanti hanno accesso alla propria postazione informatica, inclusi monitor di grandi dimensioni. Ciò è particolarmente utile quando i partecipanti devono analizzare report complessi.

Tuttavia, Lokad non sottovaluta il valore degli incontri in loco con i clienti. Le riunioni in sede facilitano la comunicazione di idee complesse, la discussione di prospettive e/o la revisione delle aspettative tra le parti. Pertanto, raccomandiamo di adottare un ritmo regolare per gli incontri in loco (ad esempio, settimanali/mensili/trimestrali…). Lokad considera tali incontri in sede come eventi significativi, soprattutto quando Lokad ospita il cliente.

Questo approccio consente a entrambe le parti di mantenere le riunioni remote informali, comode e frequenti quanto necessario.

4.4 Assistete l’azienda cliente nel condurre un controllo di qualità dell’ambiente di produzione per valutare la prontezza al go-live, inclusa l’installazione delle interfacce?

Sì. In effetti, Lokad va oltre il semplice supporto all’azienda cliente nella valutazione della prontezza per il go-live. Una delle responsabilità principali dei Supply Chain Scientists (SCSs) di Lokad è quella di prendersi carico della soluzione end-to-end consegnata all’azienda cliente. In altre parole, sebbene i risultati siano generati da un sistema meccanizzato (una flotta di macchine), è comunque una persona che si assume la responsabilità personale del sistema. Essa garantisce l’accuratezza, la pertinenza e l’adeguatezza dell’intero flusso di elaborazione dei dati, tenendo in considerazione anche le preoccupazioni aziendali complessive del cliente.

Data la loro natura soggetta a errori, le interfacce software meritano un’attenzione specifica, e gli SCS sono ben attrezzati per aiutare a valutare la loro integrità. Lokad valuta questa integrità dal lato ingress (quando Lokad riceve dati storici dalla società cliente) e dal lato egress (quando Lokad restituisce supply chain decisions alla società cliente). Per questo compito, Lokad sfrutta metodologie e tecnologie specifiche.

Consultate programming paradigms for supply chain per comprendere meglio il tipo di tecnologie che Lokad utilizza per garantire la prontezza al go-live.

4.5 Preparate il documento di strategia per la transizione e migrazione in produzione per gestire il passaggio senza soluzione di continuità delle operazioni aziendali (dall’applicazione aziendale esistente a quella nuova) per la società cliente?

Sì. La transizione è documentata nel nostro Joint Procedure Manual (JPM). Questa vasta documentazione, prodotta dagli Supply Chain Scientists (SCSs) di Lokad, garantisce che sia i supply chain practitioners che i supply chain executives abbiano accesso a materiali ben scritti che spiegano adeguatamente il processo in termini comprensibili. Gli SCSs si adoperano notevolmente per assicurare che tale documento sia accessibile anche a un pubblico non tecnico (sebbene alcuni allegati possano risultare piuttosto tecnici).

Inoltre, l’approccio dual-run di Lokad è particolarmente adatto a garantire una transizione fluida dal processo legacy alla nuova soluzione. “Dual-run”, in questo contesto, si riferisce alla pratica in cui Lokad opera in contemporanea con il processo decisionale legacy su tutto l’ambito dell’iniziativa. Questa pratica è resa possibile unicamente grazie alla natura robotizzata del processo decisionale legacy di Lokad, che garantisce che le ricette numeriche implementate dagli SCSs di Lokad siano state eseguite in condizioni di produzione esatte e soddisfacenti, su tutto l’ambito, per settimane prima del vero go-live, momento in cui le decisioni di Lokad sostituiscono il processo legacy.

Va notato che tale dual-run generalmente non è possibile con tecnologie e metodologie alternative, come quelle proposte dai nostri concorrenti. Infatti, poiché non robotizzano le decisioni della supply chain, i costi aggiuntivi associati a un dual-run sono significativi. Di conseguenza, il dual-run viene, nel migliore dei casi, realizzato su un ambito ristretto che non riflette realmente le condizioni di produzione. Pertanto, quando si adotta un simile approccio, l’espansione tardiva dell’ambito porta invariabilmente a incidenti in produzione che sarebbero stati interamente evitabili con un dual-run a pieno raggio.

4.6 Fornite l’ambito, le tempistiche e i criteri di successo per il pilot run da revisionare e approvare dalla società cliente?

Sì. L’ambito è sempre dettagliato nell’accordo contrattuale tra Lokad e la società cliente. Di solito, assume la forma di un determinato tipo di supply chain decision (ad es., inventory replenishment o stock allocation) su un insieme di sedi e/o su un insieme di sistemi aziendali.

La tempistica è tipicamente inferiore a 6 mesi (dal kick-off alla produzione). Sebbene una tempistica prevista sia sempre inclusa nella nostra proposta commerciale, potrebbe non essere specificata nell’accordo contrattuale. La tempistica vincolante rappresenta un impegno reciproco, e il ritmo dell’iniziativa Lokad dipende dall’esecuzione tempestiva di determinate fasi da parte della società cliente, in particolare dalla costruzione di una pipeline dati verso Lokad.

Per quanto riguarda i criteri di successo, la decisione viene sempre presa unilateralmente dalla società cliente. Sebbene possiamo documentare i principi guida che dovrebbero supportare tale decisione, una decisione non unilaterale sarebbe inusuale. In termini semplici, un fornitore non dovrebbe trovarsi nella posizione di stabilire il successo del pilot se la società cliente ritiene il contrario.

Vedi anche Project Implementation & Management 1.2.

Consultate Assessing the Success of a Quantitative Supply Chain Initiative per ulteriori dettagli su questo punto sfumato.

4.7 Organizzerete la conduzione dei pilot run per garantire a) l’adeguatezza dei dati, b) la configurazione del sistema e la prontezza dell’applicazione, c) la conformità del processo/sistema, e d) l’idoneità complessiva?

Sì. In linea di massima, trattiamo un pilot – destinato a fornire supply chain optimization – esattamente come tratteremmo un’iniziativa “reale” destinata a essere portata in produzione. A tutti gli effetti, per quanto riguarda l’ottimizzazione della supply chain, un pilot adeguato è indistinguibile da una configurazione pre-produzione approvata per l’uso in produzione.

Il team degli Supply Chain Scientists (SCSs) di Lokad è responsabile di tutto quanto sopra. Nella nostra esperienza, l’adeguatezza dei dati rappresenta raramente un problema nelle aziende che sono diventate digitali molti anni (se non decenni) fa. Finché esiste un sistema aziendale per monitorare ciò che viene acquistato, prodotto, stoccato e venduto, l’iniziativa ha quasi la garanzia di disporre di dati adeguati. La sfida consiste nel dare senso ai dati che non sono stati originariamente raccolti per supportare l’ottimizzazione della supply chain.

Vedi bad data per ulteriori informazioni su questo punto.

5. Gestione del Cambiamento e del Rischio

5.1 Quale supporto potete offrire alla società cliente per affrontare la gestione del cambiamento associata all’implementazione dell’iniziativa?

Tutti i clienti beneficiano del pieno impegno degli Supply Chain Scientists (SCSs) di Lokad, tutti formati per gestire i requisiti tecnici e non tecnici di un’iniziativa di ottimizzazione della supply chain. Gli SCSs assistono nel processo di gestione del cambiamento in numerosi modi, tra cui:

• Proporre miglioramenti ai processi esistenti per i supply chain practitioners impiegati dalla società cliente.

• Produrre materiali formativi per l’onboarding dei membri/team della società cliente.

• Assistere la gestione della supply chain quantificando in Dollari o Euro (o nella valuta scelta dal cliente) l’impatto dei cambiamenti apportati alla supply chain.

Va notato che la gestione del cambiamento può rappresentare un impegno significativo in termini di tempo per un SCS. Sebbene ogni SCS possieda competenze ed esperienze uniche nell’aiutare la leadership della supply chain nella gestione del cambiamento, questo compito compete con tutte le loro altre responsabilità.

Pertanto, i termini contrattuali negoziati tra Lokad e ciascun cliente specificano la quantità di risorse – ossia il dimensionamento del team di SCSs – che sarà disponibile per supportare l’iniziativa. Le nostre proposte commerciali solitamente prevedono che gli SCSs forniscano un certo supporto per la gestione del cambiamento. Tuttavia, le nostre proposte non riflettono di solito alcun tipo di supporto “su larga scala” per il change management, a meno che ciò non venga esplicitamente richiesto dal cliente.

5.2 Durante la fase di produzione, qual è la vostra visione per la gestione del cambiamento? Quali sono le principali tappe? E come apparirà la nuova organizzazione dopo il successo dell’implementazione della nuova soluzione?

Una volta che Lokad entra in produzione, un’intera classe di supply chain decisions viene automatizzata. L’obiettivo è trasformare la pratica della supply chain in un’attività capitalistica. Ogni ora spesa da un supply chain practitioner dovrebbe contribuire al continuo miglioramento delle ricette numeriche. Questo segna una svolta rispetto alla pratica “mainstream” della supply chain, in cui la stragrande maggioranza degli sforzi in un determinato giorno è destinata a mantenere l’azienda operativa per un altro giorno. Naturalmente, la transizione verso questa forma di supply chain che aggiunge valore è graduale.

• La prima tappa consiste nel far riconoscere ai supply chain practitioners che Lokad permette loro di scartare la maggior parte del processo legacy. Ad esempio, ha senso rivedere quotidianamente le quantità di inventory replenishment quando tali quantità risultano frequentemente errate. Tuttavia, per come è strutturato, le quantità di Lokad sono già corrette e non necessitano di ulteriori revisioni. Di fatto, l’assenza totale di errori nelle cifre generate da Lokad è il criterio principale per un go-live in produzione. La fiducia che i supply chain practitioners ripongono nelle cifre di Lokad libera naturalmente molto tempo che può essere impiegato in modo più produttivo.

• La seconda tappa consiste nell’avere alcuni “early adopters” tra i supply chain practitioners. Questi sono tipicamente soggetti che riescono rapidamente a separarsi dal processo legacy che non aggiunge valore – ad esempio, il controllo manuale delle cifre – per concentrarsi sul miglioramento continuo della supply chain tramite le sue ricette numeriche. Possono iniziare ad affrontare numerose questioni importanti, oltre ai semplici aspetti tecnici minori (ad esempio, la società cliente valuta la qualità del servizio dalla giusta prospettiva?).

• La terza tappa consiste nel far sì che la maggior parte dei supply chain practitioners si rivolga verso l’esterno (clienti e fornitori) anziché verso l’interno. In ultima analisi, la supply chain deve fornire un allineamento che trascende i confini della società cliente. Ciò amplia il bacino di intuizioni raccolte e contribuisce a perfezionare ulteriormente le ricette numeriche.

La nuova organizzazione assomiglia molto di più a una software company. Poche attività ripetitive della supply chain vengono gestite manualmente – poiché tali attività sono ora automatizzate. Inoltre, vi sono molte meno emergenze (ancora, grazie all’automazione). La riduzione delle attività routinarie comporta un aumento della varietà dei compiti per il supply chain practitioner. Tipicamente, ciò si traduce in meno tempo e sforzi dedicati al controllo della supply chain, mentre il management è chiamato a formare ulteriormente i dipendenti affinché possano capitalizzare sul tempo e sulle energie disponibili.

Vedi (Software) Product-oriented Delivery for Supply Chain per ulteriori dettagli su questa transizione.

5.3 Come gestite il cambiamento del workflow per gli utenti finali? Primo, con l’onboarding di Lokad, secondo, con l’evoluzione di Lokad stesso.

Per progetto, le supply chain decisions generate da Lokad non richiedono workflow. Infatti, l’automazione di tutti i passaggi coinvolti nella generazione delle supply chain decisions è la modalità auspicata.

Tuttavia, se esplicitamente richiesto dal cliente, Lokad è in grado di introdurre un “workflow” che rispecchi quello legacy. Questo, si deve intendere, serve esclusivamente a facilitare la gestione del cambiamento e non rappresenta in alcun modo un requisito per il successo della ricetta numerica. Man mano che i dipendenti del cliente acquisiranno maggiore familiarità – e fiducia – nelle decisioni generate da Lokad, il “workflow” potrà essere gradualmente semplificato, fino a quando non verrà completamente eliminato.

Per quanto riguarda l’evoluzione di Lokad, la nostra piattaforma è programmatica e gestita da Envision (il nostro linguaggio di programmazione specifico per il dominio). Qualsiasi modifica o aggiornamento a Envision viene eseguito mediante script automatizzati, e questo processo è programmato in modo tale che le iniziative della supply chain ospitate da Lokad rimangano inalterate.

5.4 Potete mantenere un registro di Issues & Risk che includa un piano di mitigazione, compiti, responsabilità, tempistiche e stato (non iniziato, in corso, chiuso, in sospeso)? Il Project Manager di Lokad sarà responsabile del monitoraggio di tutti gli Issues & Risk e dell’assicurare risoluzioni tempestive o della gestione delle escalation quando necessario?

Sì. La piattaforma di Lokad è dotata di un proprio gestore interno di issue/ticket/task. Questa funzione offre tutte le capacità standard comunemente attese da tale strumento, come la gestione di stati, priorità, assegnazioni, notifiche, ecc. Inoltre, manteniamo separatamente un Joint Procedure Manual (JPM) che fornisce una presentazione completa e ben organizzata dell’iniziativa con tutte le tempistiche di alto livello rilevanti. Gli Supply Chain Scientists (SCSs) di Lokad sono responsabili della supervisione del task manager e si assicurano che problemi e criticità vengano affrontati tempestivamente.

Le escalation sono possibili, ma rare. Lo stesso SCS che gestisce/rivede i task li risolverà anche. Gli SCSs senior di Lokad ricoprono una vasta gamma di ruoli: supply chain expert, data engineer, data integrator, business analyst, data scientist, project manager, change consultant, ecc.

La possibilità di contattare facilmente gli SCSs è un aspetto che i nostri clienti citano regolarmente come estremamente positivo. Il cliente può interagire immediatamente con la persona incaricata di supervisionare la risoluzione soddisfacente di eventuali problemi, invece di dover attraversare vari livelli di burocrazia per poter – si spera – parlare con qualcuno in grado di aiutarlo.

Nel caso in cui si manifesti un problema che richiede competenze al di fuori dell’expertise di un SCS (ad es., un problema tecnico con l’architettura della piattaforma), questi vigilano comunque affinché il problema venga risolto tempestivamente, fungendo anche da primo punto di contatto per il cliente interessato.

5.5 Offrite consulenza per la gestione del cambiamento organizzativo per affrontare l’introduzione e la modifica dei processi aziendali, oltre alla dismissione dei processi esistenti?

Sì, se la società cliente desidera che la sua partnership con Lokad includa servizi di consulenza per la gestione del cambiamento. Va notato che la principale competenza di Lokad risiede nell’ottimizzazione predittiva della supply chain e non nella gestione del cambiamento. Il nostro approccio al change management è inoltre più convenzionale rispetto alle nostre pratiche per la supply chain. Tale approccio, se implementato, limiterebbe il numero di terze parti coinvolte nel progetto.

In alternativa, se la società cliente preferisce avvalersi dei servizi di uno specialista in gestione del cambiamento per integrare Lokad, lo sosterremo condividendo tutto ciò che la società ritiene opportuno.

6. Customizzazione e Funzionalità del Sistema

6.1 Organizzate sessioni per dare priorità ai requisiti di customizzazione, garantendo la comprensione degli impatti aziendali dovuti a lacune del prodotto e raggiungendo un accordo reciproco sulla priorità per il rilascio delle customizzazioni?

Sì. Gli Supply Chain Scientists (SCSs) di Lokad sono responsabili di questo processo. Infatti, Lokad si distingue su due fronti per quanto riguarda questa priorizzazione. Innanzitutto, un SCS è in grado di implementare autonomamente la customizzazione e, di conseguenza, può fornire chiarimenti precisi su ciò che è in gioco in termini di risorse e tempistiche.

Ciò migliora notevolmente la qualità della priorizzazione, poiché la società cliente beneficia di un esperto in grado di bilanciare prontamente i benefici di un determinato cambiamento nella supply chain con i costi ad esso associati.

In secondo luogo, ‘Quantitative Supply Chain’ - la filosofia complessiva di Lokad - enfatizza una prospettiva puramente finanziaria. Pertanto, gli SCS supportano l’azienda cliente nel fornire stime quantitative (in dollari o euro) dell’impatto di un potenziale cambiamento da apportare alla soluzione. Questa strategia perfeziona l’iniziativa evitando il tradizionale collo di bottiglia del dibattito su cosa dare priorità. Invece, Lokad semplifica questo processo dando priorità alle problematiche che comportano il maggiore impatto finanziario.

6.2 Potete condurre uno studio fit-gap di tutti i processi aziendali per identificare opportunità di automazione, documentare i processi futuri desiderati e determinare le lacune nella funzionalità del prodotto? Potete suggerire soluzioni alternative accettabili quando vengono identificate lacune nella funzionalità del prodotto?

Sì. Gli Supply Chain Scientists (SCS) di Lokad sono responsabili di questo processo. Sebbene uno studio iniziale venga condotto all’inizio dell’iniziativa, questo processo è in corso per tutta la fase di produzione. Fa parte del nostro approccio perseguire continui miglioramenti della soluzione.

Per quanto riguarda l’ottimizzazione della supply chain, le lacune raramente riguardano la ‘funzionalità’, bensì la ‘prestazione’. Ad esempio, la sfida non è solo generare le quantità di riapprovvigionamento (funzionalità), ma garantire che le quantità generate siano quelle più redditizie (prestazione).

Pertanto, gli SCS si occupano di identificare e affrontare le ‘lacune di prestazione’, che a volte richiedono funzionalità aggiuntive o una re-ingegnerizzazione della soluzione. Ciò può comportare l’aggiunta o la rimozione di funzionalità per ottimizzare le prestazioni complessive.

A proposito, la piattaforma di Lokad è programmabile. Pertanto, eventuali ‘lacune di funzionalità’ percepite possono essere risolte introducendo (o modificando) alcune righe di Envision code. Questa programmabilità è proprio ciò che permette a Lokad di fornire soluzioni su misura per ogni cliente.

6.3 Potete fornire un’agenda dettagliata per i workshop di analisi fit-gap del processo, includendo le aspettative degli SME (Subject Matter Expert) da parte del cliente, almeno una settimana prima dell’inizio dei workshop?

Sì. Gli Supply Chain Scientists (SCS) di Lokad forniscono un’agenda per ogni workshop. Ci assicuriamo che l’agenda sia comunicata almeno una settimana prima dell’evento. Se l’azienda cliente fornisce istruzioni esplicite, come una scadenza per presentare l’agenda, le seguiremo. In assenza di istruzioni, struttureremo i workshop (inclusa la timeline e il trasporto di tutti i passaggi necessari lato cliente) in modo intelligente e professionale.

6.4 Garantite che i documenti dei requisiti di personalizzazione del prodotto siano revisionati e approvati congiuntamente dall’azienda cliente?

Sì, questi documenti saranno forniti all’azienda cliente e successivamente approvati da quest’ultima.

Si noti che le scelte progettuali della piattaforma di Lokad eliminano in gran parte la necessità di ‘customization’ – almeno nel senso in cui questo termine è comunemente inteso negli ambienti del software enterprise. La piattaforma di Lokad è programmabile, utilizzando Envision – il nostro DSL (linguaggio di programmazione specifico di dominio) dedicato all’ottimizzazione predittiva della supply chain.

Pertanto, le soluzioni di Lokad sono sempre ‘customized’ nel senso che sono completamente su misura per le esigenze specifiche dell’azienda cliente. Tuttavia, tale personalizzazione viene fornita in modo da mantenere la soluzione come parte della linea principale di prodotti di Lokad. Questo è l’approccio preferito (e deliberatamente concepito) da Lokad, e non presenta problemi di manutenibilità.

6.5 Assistete l’azienda cliente nell’instaurare la connettività delle interfacce con sistemi esterni, nonché nel testare e certificare le interfacce?

Sì. Gli Supply Chain Scientists (SCS) di Lokad forniscono supporto per configurare, testare, validare e documentare le interfacce tra i sistemi operati dall’azienda cliente e Lokad. Gli SCS potrebbero essere affiancati da alcune risorse IT interne di Lokad per gli aspetti tecnici a basso livello, come il networking o i protocolli di sicurezza.

Le interfacce di sistema non sono generalmente ‘certificate’ da un ente di certificazione terzo. Le interfacce sono ‘formalmente specificate’ attraverso specifiche tecniche concordate congiuntamente tra il dipartimento IT dell’azienda cliente e Lokad. Queste specifiche tecniche supportano gli obblighi reciproci delle aziende: in breve, l’azienda cliente si impegna a fornire a Lokad i dati richiesti in tempo; Lokad, a sua volta, si impegna a restituire i risultati in tempo.

6.6 Fornite documenti di specifica dell’interfaccia durante i workshop, inclusi messaggi di esempio?

Sì, Lokad fornisce specifiche delle interfacce durante i workshop. I messaggi di esempio possono essere inclusi se richiesto dall’azienda cliente.

Data la natura del servizio di Lokad, i “messaggi di esempio” avranno molto probabilmente la forma di tabelle – in quanto rappresentano in modo più accurato l’output che Lokad genera per il cliente. A titolo esemplificativo, la stragrande maggioranza delle specifiche tecniche per le interfacce si concentrerà sulle tabelle e sui loro formati, nonché sui modelli di estrazione delle tabelle e sui programmi di trasferimento.

6.7 Condividete i processi di gestione delle richieste di modifica e delle release?

Sì. Gli Supply Chain Scientists (SCS) di Lokad sono responsabili di questo processo. È importante notare che Lokad adotta due livelli di modifiche e rilasci, cosa diversa rispetto al software enterprise tipico.

In primo luogo, le modifiche realizzate specificamente per i clienti vengono implementate dagli stessi SCS. Queste modifiche avvengono frequentemente, spesso più volte al giorno, in particolare durante la fase di onboarding. Tali modifiche sono una risposta diretta alle esigenze dell’azienda cliente e comportano una notevole comunicazione tra le parti.

In secondo luogo, apportiamo aggiornamenti alla piattaforma di Lokad, tipicamente tramite aggiornamenti a Envision – il nostro DSL (linguaggio di programmazione specifico di dominio) dedicato all’ottimizzazione predittiva della supply chain. Queste modifiche sono progettate per essere trasparenti per le aziende clienti. Se desiderato, i dettagli su questi aggiornamenti possono essere forniti, e gran parte di queste informazioni viene resa pubblica.

Vedi Envision VM Environment and General Architecture per ulteriori informazioni sull’evoluzione della piattaforma di Lokad.

7. User Acceptance Testing (UAT)

7.1 Assistete l’azienda cliente nell’installare l’ambiente di test UAT (User Acceptance Testing) con dati contestuali specifici e configurazioni di sistema?

Sì. Gli Supply Chain Scientists (SCS) di Lokad sono responsabili di questo processo. Lokad offre innovazioni metodologiche e tecniche uniche a supporto di ciò.

In termini di metodologia, favoriamo la creazione di elenchi prioritizzati, in cui gli elementi sono ordinati in base al ritorno sull’investimento (ROI) decrescente per l’azienda. Questo aspetto è cruciale per assicurarsi che il tempo degli utenti finali non venga sprecato esaminando grandi quantità di dati per lo più irrilevanti.

In termini di tecnologia, la piattaforma di Lokad è stata progettata specificamente per supportare simultaneamente più ambienti per ogni iniziativa. Questi ambienti sono una caratteristica nativa della nostra piattaforma SaaS multi-tenant e quindi possono essere implementati con un impatto minimo, sia in termini di risorse di calcolo che di tempo di amministrazione del sistema.

Vedi anche User Acceptance Testing 7.3.

7.2 Configurate gli ambienti UAT (User Acceptance Testing) di pre-produzione, produzione e formazione secondo i processi ToBe definiti?

Sì. Data la ricca programmabilità della piattaforma di Lokad, possiamo esercitare il pieno controllo sulle configurazioni. Ciò è reso possibile grazie a Envision – il nostro DSL (linguaggio di programmazione specifico di dominio) dedicato all’ottimizzazione predittiva della supply chain.

Questo approccio permette a diversi ambienti di utilizzare la stessa configurazione per tutte le parti non soggette a modifiche – utilizzando lo stesso codice ove possibile. Ciò riduce notevolmente le differenze accidentali tra ambienti, che potrebbero confondere gli utenti e compromettere l’integrità del processo UAT.

Inoltre, il passaggio da una fase all’altra della configurazione è semplice con il nostro design. L’utilizzo di un codice base per le modifiche configurative è più efficiente rispetto ai metodi tradizionali basati sull’interfaccia utente.

7.3 Fornite ambienti separati per UAT (User Acceptance Testing), migrazione dei dati, fase di produzione (pre-prod), produzione e formazione per il prodotto (comprese le interfacce richieste) all’azienda cliente e ai sistemi esterni?

Sì. La piattaforma di Lokad è stata progettata specificamente per supportare simultaneamente più ambienti per ogni iniziativa. Questi ambienti sono una caratteristica nativa della nostra piattaforma SaaS multi-tenant e quindi possono essere implementati con un impatto minimo, sia in termini di risorse di calcolo che di tempo di amministrazione del sistema.

Con Lokad, duplicare l’intero ambiente di produzione, inclusi tutti i dati di produzione, avviene senza raddoppiare l’impronta di archiviazione dei dati. Internamente, i dati identici tra i due ambienti vengono mutualizzati. Inoltre, il nostro design a tempo costante garantisce che il carico di lavoro di un ambiente non influisca negativamente sulle prestazioni di un altro ambiente.

Tuttavia, la maggior parte dei fornitori di software enterprise aggira il problema limitandosi a ‘clonare’ la configurazione principale. Il cloning – o la duplicazione diretta – è semplice ma sprecone. Clonare significa che la quantità di risorse (umane e macchinari) aumenta linearmente con il numero di ambienti — ad esempio, tre ambienti triplicano i costi originari. Per una supply chain di rilevanza, ciò si traduce in costi consistenti.

7.4 Garantite la risoluzione tempestiva di tutti i difetti per assicurare che il UAT (User Acceptance Testing) venga completato entro le tempistiche concordate?

Sì, a condizione che si possano concordare definizioni sfumate di ‘risoluzione’ e ‘difetto’. In generale, gli Supply Chain Scientists (SCS) di Lokad sono responsabili della risoluzione di tutte le problematiche che compromettono l’obiettivo principale dell’iniziativa: aumentare il ritorno sull’investimento. In uno scenario tipico, l’SCS propone un’azione appropriata e una timeline corrispondente, che l’azienda cliente valida o aggiorna a sua discrezione.

È fondamentale sottolineare che, in ambito supply chain, non esistono soluzioni perfette, ma solo tradeoffs migliori o peggiori. In altre parole, non si può risolvere realmente un problema in cui due o più valori sono in completa opposizione.

Ad esempio, l’inventario deperibile scaduto rappresenta uno spreco, ma nel gestire prodotti deperibili tale spreco non può essere completamente eliminato senza creare un conseguente problema di quality of service. È necessario trovare un equilibrio tra stock in eccesso e stock-out. Tuttavia, sia l’eccesso di stock che gli stock-out sono, in un certo senso, difetti.

In breve, gli SCS possono risolvere problemi ‘banali’ man mano che si presentano, come ad esempio correggere un errore di parsing durante la lettura di un file (un bug del software). Tuttavia, l’obiettivo primario di una soluzione quantitative supply chain non è “risolvere problemi” bensì aumentare il ritorno sull’investimento (in dollari o euro). Lokad raggiunge questo tipo di “risoluzione” attraverso un approccio intelligente e finanziariamente orientato ai tradeoffs della supply chain.

7.5 Assistete l’azienda cliente nella revisione degli scenari UAT (User Acceptance Testing), dei casi di test e dei dati di test?

Sì. Gli Supply Chain Scientists (SCS) di Lokad sono responsabili di questo processo.

Tuttavia, per quanto riguarda l’ottimizzazione della supply chain, dataset inferiori all’intera configurazione di produzione generalmente non sono sufficienti. In pratica, scenari, casi di test e dati di test devono essere (quasi) altrettanto vasti quanto la configurazione di produzione per riflettere una visione end-to-end della supply chain. Questo requisito non ha a che fare con Lokad; è semplicemente la natura della supply chain.

7.6 Garantite supporto in sede presso la sede centrale dell’azienda cliente durante la fase di UAT (User Acceptance Testing)?

Sì. Il supporto in sede è regolato dall’accordo contrattuale tra Lokad e l’azienda cliente. Questo aspetto è sempre negoziato su base individuale per ogni cliente.

Va notato che un’iniziativa quantitative supply chain con Lokad prevede un miglioramento continuo della supply chain, pertanto non esiste un periodo fisso per il UAT. I test tipicamente iniziano alla fine del secondo mese, raggiungono il picco al quarto mese, per poi stabilizzarsi dal sesto mese in poi.

Dedicando risorse continue al perfezionamento delle nostre ricette numeriche (algoritmi dedicati all’ottimizzazione della supply chain), Lokad garantisce che ogni cliente disponga di un’iniziativa aggiornata.

Vedi anche Project Implementation & Management 1.7.

8. Post-Implementation Support & Auditing

8.1 Potete garantire che le osservazioni dai run pilota siano documentate e che eventuali punti d’azione siano assegnati ai relativi stakeholder dei reparti Tecnico, IT e Fornitori dell’azienda cliente, e inoltre monitorati fino alla chiusura?

Sì. Gli Supply Chain Scientists (SCS) di Lokad creano e mantengono un Joint Procedure Manual (JPM) per ogni iniziativa. Esso include tutte le informazioni pertinenti all’iniziativa. È importante sottolineare che il JPM è progettato per essere accessibile anche a un pubblico non tecnico (sebbene alcune sezioni e allegati siano piuttosto tecnici).

I punti d’azione di alto livello sono documentati nel JPM. Tuttavia, i punti d’azione minori sono generalmente gestiti tramite il task manager sulla piattaforma di Lokad. Questi punti minori hanno una durata breve e il task manager facilita il loro monitoraggio e la loro chiusura meglio del JPM.

8.2 Potete garantire che siano disponibili report sufficienti sulla qualità e conformità per monitorare l’utilizzo e l’adozione del sistema?

Sì. Gli Supply Chain Scientists (SCS) di Lokad implementano tipicamente strumenti dedicati a questo scopo durante la fase finale dell’onboarding, subito prima del kick-off ufficiale.

Inoltre, Lokad può monitorare l’allineamento tra le decisioni di supply chain che genera e quelle effettivamente prese nella supply chain. Ciò viene fatto per identificare potenziali fonti di divergenza, come bug o malfunzionamenti nei sistemi del cliente, che potrebbero influire sull’implementazione delle raccomandazioni di Lokad.

8.3 Conduciate un audit annuale dell’applicazione e fornite feedback per migliorare l’utilizzo e l’adozione del sistema da parte degli utenti finali, al fine di realizzare il ROI (return on investment) più rapidamente?

Sì, un audit annuale dell’intera soluzione (end-to-end) è la procedura operativa standard. Detto ciò, i Supply Chain Scientists (SCSs) di Lokad solitamente auditano l’intera soluzione diverse volte durante l’anno. L’audit annuale porta di solito a una presentazione dettagliata della roadmap per la leadership del cliente. Questo è in linea con il nostro approccio di miglioramento continuo per ogni iniziativa.

Per quanto riguarda l’uso, nella pratica, i SCSs implementano proattivamente strumenti dedicati fin dall’inizio per monitorare l’uso, l’adozione e la conformità con le decisioni della supply chain generate da Lokad. Sebbene un audit annuale rappresenti un’eccellente opportunità per apportare gli aggiustamenti necessari, i nostri SCSs sono molto proattivi quando si tratta dell’adozione delle raccomandazioni sulla supply chain di Lokad. Questa questione sarà discussa durante le nostre sessioni di lavoro settimanali, poiché l’adozione delle raccomandazioni di Lokad è il driver primario per un aumento del ROI in un’iniziativa quantitativa della supply chain.

8.4 Potete garantire che il team di supporto al prodotto dedicato, con sede presso la sede centrale dell’azienda cliente, continui a supportare il prodotto per almeno 6 mesi dopo il go-live?

Sì. Il team di Supply Chain Scientists (SCSs) di Lokad si occupa di questo compito. I nostri SCSs sono ampiamente formati per migliorare continuamente l’iniziativa e fornire un supporto costante al cliente. La presenza continua in sede dei SCSs sarà negoziata e chiarita nell’accordo contrattuale con il cliente, se quest’ultimo desidera perseguirla.

A proposito, Lokad raccomanda fortemente di mantenere un impegno attivo e costante nel miglioramento della soluzione, in particolare lato cliente. L’eliminazione graduale degli sforzi di miglioramento continuo, secondo la nostra esperienza, indebolirà la forza dell’iniziativa. Qualsiasi cambiamento lato cliente, inclusi lievi aggiustamenti nel panorama applicativo o vincoli, può influire sulla qualità delle decisioni generate da Lokad, pertanto si consiglia una vigilanza attiva e un miglioramento costante.

Vedi anche Implementazione e Gestione del Progetto 1.7.

9. Gestione di Incidenti e Difetti

9.1 Potete garantire che tutti i difetti imprescindibili e le richieste di modifica (elementi critici e ad alta priorità) siano trattati come una priorità e consegnati, al fine di evitare ritardi nella timeline del go-live dell’azienda cliente?

Sì. I Supply Chain Scientists (SCSs) di Lokad sono responsabili di questo processo. La nostra piattaforma è progettata in modo tale da consentire loro di affrontare difetti e richieste di modifica in maniera rapida e autonoma.

La piattaforma di Lokad è programmabile, ciò è reso possibile tramite Envision - il nostro DSL (linguaggio di programmazione specifico per il dominio) dedicato all’ottimizzazione predittiva delle supply chain. Questa programmabilità significa che i SCSs possono fornire prontamente soluzioni e implementare le modifiche richieste all’iniziativa, con un livello di precisione non comunemente riscontrato nel software aziendale.

Oltre alla tecnologia, i SCSs di Lokad sono formati per ricoprire numerosi ruoli chiave, il che riduce naturalmente il numero di persone necessarie per affrontare difetti e richieste di modifica. Questi ruoli includono esperto di supply chain, analista aziendale, data scientist, data engineer e system integrator. Sono quindi ben addestrati per fornire soluzioni e aggiornamenti, tenendo sempre a mente le priorità principali del cliente.

Vedi anche Personalizzazione e Funzionalità del Sistema 6.2.

9.2 Potete implementare un meccanismo di monitoraggio dei difetti per garantire la chiusura tempestiva di tutti i difetti e dei problemi di usabilità?

Sì, la piattaforma di Lokad è dotata del proprio sistema di gestione dei task / ticket / issue. Queste capacità ci consentono di seguire con precisione la risoluzione tempestiva delle problematiche. Tali risoluzioni sono gestite dai team di Supply Chain Scientists (SCSs) impiegati da Lokad.

Tuttavia, è importante non confondere “difetti” e “problemi di usabilità”. Ad esempio, una previsione della domanda inaccurata è un “difetto”. Impatta negativamente sulla supply chain. Tuttavia, a seconda delle condizioni di mercato in cui opera l’azienda cliente, questo “difetto” potrebbe non essere mai risolto, solo mitigato. Quando si tratta dell’ottimizzazione predittiva delle supply chain, le soluzioni comportano sempre trade-off: risolvere un difetto e crearne un altro (si spera più piccolo).

Al contrario, i problemi di usabilità sono generalmente semplici da affrontare. Pertanto, per questa categoria di problemi, siamo disposti e impegnati a garantire una risoluzione tempestiva, poiché affrontare il problema non crea, in genere, altri problemi.

9.3 Potete garantire che i difetti riscontrati durante i test delle release (prima della produzione) saranno gestiti e rettificati in modo tempestivo, in modo che non incidano sulla timeline del go-live dell’azienda cliente?

Sì. Se i difetti identificati riguardano il codebase specifico per il cliente (scritto in Envision), allora i difetti saranno rettificati dai Supply Chain Scientists (SCSs) di Lokad. Se i difetti identificati riguardano la piattaforma di Lokad, allora i difetti saranno rettificati dai team di ingegneria del software di Lokad.

In entrambi i casi, il processo di rilascio di Lokad prevede test approfonditi per assicurarsi che i difetti siano identificati e corretti prima della release (go-live).

9.4 Come affronterete gli incidenti che potrebbero essere segnalati dall’azienda cliente attraverso uno qualsiasi dei seguenti canali: telefono, email, Office Communicator, e/o inserimento diretto nel Tool di Gestione degli Incidenti?

I Supply Chain Scientists (SCSs) trattano tutte le segnalazioni di incidenti - indipendentemente dalla loro provenienza - con la massima serietà. L’accordo contrattuale tra Lokad e l’azienda cliente specificherà quanti SCSs saranno assegnati al progetto, nonché le ore settimanali in cui il cliente può aspettarsi supporto diretto.

La risoluzione di un tipico incidente inizia con un SCS che crea una nuova voce nel gestore di task/ticket/issue. Questo garantisce una tracciabilità dell’incidente.

Successivamente, l’SCS diagnosticherà il problema. Se il problema richiede una correzione da parte di Lokad, l’SCS mobiliterà immediatamente le risorse necessarie per risolvere il problema - tipicamente lo stesso SCS.

Infine, una volta risolto il problema, l’SCS valuterà la vera causa principale del problema segnalato, anche se la segnalazione è stata infine diagnosticata come un non-problema. Di solito, c’è un problema sottostante da qualche parte che necessita di essere affrontato. Affrontando la causa principale, Lokad elimina proattivamente problemi simili in futuro.

9.5 Se un difetto viene segnalato al di fuori del Tool di Gestione degli Incidenti – attraverso un altro canale come l’email – lo registrerete nel tool non appena segnalato, per un tracciamento e una conformità adeguati?

Sì. È prassi standard creare una voce corrispondente all’interno della piattaforma di Lokad quando riceviamo una segnalazione attraverso un canale diverso dal gestore di task/ticket/issue. Questa prassi facilita un tracciamento accurato e la conformità.