FAQ: Gestione del Cambiamento

Un’iniziativa con Lokad mira a ottimizzare la supply chain del cliente con decisioni automatizzate superiori - sostituendo tipicamente compiti quotidiani noiosi come gli ordini di acquisto e le scelte di allocazione di magazzino. Questa pagina affronta domande e preoccupazioni sul cambiamento che questa iniziativa porta, e su come gestirlo in modo efficace. Gli esperti di Lokad rimangono sempre disponibili per aiutare i clienti a navigare nel processo.

Pubblico previsto: i dipartimenti della supply chain e/o di pianificazione.
Ultima modifica: 19 dicembre 2023

Panoramica della Gestione del Cambiamento

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

Ad esempio, Lokad elimina molti punti di contatto e processi non necessari, anziché semplicemente sostituire sprechi con altri sprechi. Pertanto, il cambiamento da gestire è tipicamente duplice: primo, adattarsi al fatto che le decisioni noiose e ripetitive della supply chain sono ora automatizzate; secondo, accettare che la qualità di tali decisioni automatizzate superi ciò che i dipendenti erano in grado di ottenere con strumenti alternativi (sistemi legacy, fogli di calcolo e spesso un po’ di entrambi).

Un’iniziativa QSC è guidata dai Supply Chain Scientist di Lokad. Questi esperti consolidano molti ruoli che tipicamente sarebbero svolti da più persone in iniziative simili con altri fornitori di software. Un Supply Chain Scientist funge da integratore di sistema, ingegnere dati, analista aziendale, scienziato dei dati, esperto di supply chain e project manager (tra gli altri ruoli). Gli scienziati della supply chain (SCSs) forniscono tutto il coaching, la formazione, l’orientamento e il supporto necessari affinché i clienti adottino l’approccio quantitativo alla supply chain di Lokad.

Il successo dell’implementazione di Lokad (in produzione) porta tipicamente a due risultati significativi: risparmi sostanziali attraverso decisioni migliori sulla supply chain e risparmi di produttività sostanziali attraverso decisioni sulla supply chain (in larga parte) automatizzate.

In termini di gestione del cambiamento, i risparmi sulla supply chain sono tipicamente irrilevanti. L’azienda potrebbe alla fine decidere di reinvestire il capitale di lavoro liberato altrove, ma questo tipo di decisione supera normalmente il campo di applicazione dell’iniziativa Lokad. Tuttavia, i notevoli risparmi di produttività generati da Lokad vengono tipicamente reinvestiti in altre attività che portano molto più valore aggiunto 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 sono quasi esclusivamente rivolte verso l’interno: produrre una previsione, trasformare la previsione in un piano, regolare i livelli di stock minimi/massimi sugli SKU, comporre ordini di acquisto/ordini di produzione/movimenti di magazzino, ecc.

Una volta che Lokad è in produzione, la maggior parte delle attività sono rivolte verso l’esterno: identificare ciò che i clienti percepiscono come qualità del servizio, identificare ciò che i fornitori percepiscono come un ostacolo per abbassare ulteriormente il prezzo, identificare ciò che i trasportatori percepiscono come le cause principali della loro non affidabilità, ecc.

Queste informazioni vengono poi continuamente incorporate nella soluzione di Lokad attraverso il supporto continuo dei SCSs.

Per i dirigenti della supply chain, il cambiamento più grande è l’eliminazione (in larga parte) degli interventi di emergenza. La soluzione di Lokad fornisce decisioni automatizzate progettate per gestire casi limite fastidiosi, riducendo così sostanzialmente la banda che i dirigenti devono dedicare all’analisi del comportamento erratico del mercato. Ciò libera i dirigenti della supply chain per pianificare gli obiettivi e i progetti della supply chain, anziché gestire dettagliatamente le conseguenze continue delle decisioni non ottimali.

Domande Frequenti (FAQ)

1. Implementazione e Gestione del Progetto

1.1 Offrite servizi di gestione del progetto di implementazione?

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

Oltre a ciò, questi esperti rimangono impegnati nel successo a lungo termine dell’iniziativa oltre l’implementazione iniziale, fornendo supporto continuo durante la transizione dell’iniziativa alla fase di ‘miglioramento continuo’.

Consulta le lezioni di Lokad su lo Scienziato della Supply Chain e Una giornata nella vita di uno Scienziato della Supply Chain per ulteriori informazioni sul ruolo degli SCS nel processo di ottimizzazione.

1.2 Qual è il vostro cronoprogramma di implementazione e le fasi incluse in questo cronoprogramma? Quali sono gli obiettivi di ciascuna fase (dall’avvio del progetto di implementazione al Go-Live)?

Dall’inizio alla fine, l’implementazione di solito richiede circa 6 mesi. Lokad distingue la fase di onboarding dalla fase di produzione. L’obiettivo della fase di onboarding è portare la ricetta numerica di Lokad in produzione. Alla fine della fase di onboarding, le decisioni della supply chain di interesse (come definite in collaborazione con il cliente) dovrebbero essere robotizzate. Tuttavia, l’automazione è tipicamente solo un effetto collaterale (sebbene molto visibile) dell’intento effettivo: migliorare le prestazioni della supply chain. L’obiettivo della fase di ‘produzione’ è continuare a perfezionare, migliorare e riallineare le ricette numeriche, quelle che consentono l’automazione in primo luogo.

Suddivisione del cronoprogramma

La fase di onboarding di solito dura 6 mesi e può essere suddivisa in tre sotto-fasi di 2 mesi ciascuna.

• La prima sotto-fase è la configurazione del data pipeline. L’obiettivo è creare un data pipeline completamente automatizzato per l’estrazione dei dati del cliente su Lokad. Gli aspetti più impegnativi del data pipeline sono stabilire la ‘semantica’ dei dati e rendere il processo di pipelining stesso (quasi) perfettamente affidabile. Un data pipeline, rispetto a un’estrazione dati singola, è fondamentale per mantenere le raccomandazioni sulla supply chain generate da Lokad rilevanti per le preoccupazioni aziendali attuali del cliente.

• La seconda sotto-fase è la progettazione delle ricette numeriche uniche del cliente - i pezzi di logica software che guidano le decisioni della supply chain. L’obiettivo è ottenere ricette coerenti, affidabili e senza fronzoli. La stesura delle ricette numeriche iniziali è rapida, di solito non dura più di una settimana o due. Tuttavia, queste bozze sono solo punti di partenza e vengono rapidamente migliorate attraverso iterazioni successive dagli Scienziati della Supply Chain responsabili del rispettivo account. Ciò elimina rapidamente i casi limite fastidiosi presenti nelle bozze iniziali.

• La terza sotto-fase è la doppia esecuzione. La ricetta numerica non produce più assurdità e i driver economici che guidano l’ottimizzazione sono stati concordati. Tuttavia, la ricetta non è ancora di grado di produzione. Per procedere, viene avviata una doppia esecuzione. La ricetta numerica viene eseguita fianco a fianco con il processo legacy. Poiché la ricetta è automatizzata, l’onere organizzativo è basso. Ogni giorno, i professionisti della supply chain possono confrontare le decisioni e vedere come si sviluppano i modelli (ad esempio, la stagionalità). Attraverso diverse settimane di doppia esecuzione, si acquisisce fiducia per procedere con il lancio in produzione.

Alla fine della fase di integrazione - e se tutti i passaggi sono stati soddisfatti - inizia il lancio in produzione. Questo lancio 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 il necessario cambiamento gestionale.

Consulta la panoramica della timeline per una scomposizione più dettagliata di ciascun passaggio coinvolto nel processo di ottimizzazione.

1.3 Lokad documenta e pubblica un piano di gestione del progetto dettagliato che definisce l’ambito del progetto, il programma/le scadenze, i punti di svolta critici, le risorse, i deliverable, 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 quegli elementi e altro ancora sono raccolti in un unico Manuale di Procedura Condiviso (JPM) per l’iniziativa. Gli Scienziati della Supply Chain (SCSs) sono responsabili di avviare e mantenere il JPM per l’intera durata dell’iniziativa.

Il JPM di Lokad si concentra sulle domande ‘perché?’. I JPM sono ben scritti e pensati per essere in gran parte accessibili anche a un pubblico meno tecnico e/o non specialista. Il JPM cattura l’essenza dell’intento dietro l’iniziativa e consolida le intuizioni fondamentali man mano che vengono acquisite lungo l’iniziativa stessa.

Il punto di vista di Lokad è che molte (se non la maggior parte) delle iniziative aziendali sono ostacolate dalla produzione di documenti inutili, che, nella pratica, sono impossibili da leggere (cioè sono noiosi o impenetrabilmente tecnici). Tali documenti non servono a nulla oltre a spuntare caselle inventate. Inoltre, molti terzi (ad esempio, integratori, consulenti e persino la burocrazia interna) hanno una grave tendenza a favorire la quantità rispetto alla qualità quando si tratta della documentazione del progetto.

Al contrario, i JPM di Lokad sono pensati per essere sia leggibili che letti. I JPM sono strumenti utilizzati dagli SCSs stessi per gestire l’iniziativa. Sebbene abbiamo linee guida dettagliate su cosa ci si aspetta di trovare in un JPM, alla fine spetta agli SCSs prendere decisioni oculate su ciò che richiede maggiore attenzione e sforzo considerando le specificità dell’iniziativa.

Consulta la lezione Scrittura per le Supply Chain per ulteriori informazioni sull’etica documentale di Lokad.

1.4 Lokad è responsabile della gestione e del baseline del piano di gestione del progetto, soggetto ad approvazione(i) del comitato di direzione del progetto? Se dovessero sorgere deviazioni dal piano, le comunicherete chiaramente insieme alle opzioni di mitigazione?

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

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

Per un’iniziativa particolarmente complessa, Lokad istituisce un comitato di direzione dedicato composto da membri chiave sia di Lokad che dell’azienda cliente. Sebbene questa riunione serva come meccanismo per garantire l’approvazione formale, la maggior parte del lavoro sostanziale avviene al di fuori del comitato stesso. Gli SCSs di solito interagiscono quotidianamente con vari team dal lato del cliente. Questi team vengono aggiornati continuamente su eventuali deviazioni dal piano e si assicurano che l’intera iniziativa rimanga in pista. Queste interazioni quotidiane sono un modo molto più efficace per discutere e superare i problemi tecnici man mano che sorgono, piuttosto che cercare di investigare grandi lotti di problemi durante una sessione del comitato di direzione. Pertanto, il comitato di direzione, in quanto tale, agisce come un organo di supervisione piuttosto che come un think-tank per l’iniziativa.

Nota: Le iniziative quantitative della supply chain sono note per incontrare frequentemente “deviazioni positive”. Si tratta di sorprese benefiche nella ricetta che si rivelano durante la manutenzione in corso dell’iniziativa. Fondamentalmente, sono opportunità troppo buone per essere lasciate passare. Pertanto, un vantaggio chiave dell’approccio di Lokad alla comunicazione è la capacità di trasmettere prontamente ed efficientemente queste deviazioni positive al cliente man mano che sorgono, aumentando significativamente l’impatto e l’agilità dell’iniziativa.

1.5 Documenterete il piano di comunicazione, che include stand-up giornalieri, rapporti di stato settimanali del gruppo di lavoro e sessioni di revisione, nonché rapporti e sessioni di revisione mensili del comitato di direzione? Definirete i criteri di escalation e garantirete un accordo reciproco tra l’azienda cliente e Lokad su questi dettagli?

Sì. Gli Scienziati della Supply Chain di Lokad (SCSs) sono responsabili di queste attività. 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 loco presso la sede dell’azienda cliente. Di solito, però, i nostri SCSs operano presso gli uffici di Lokad.

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

Sebbene Lokad chiarisca i criteri di escalation e le linee guida, vale la pena sottolineare che ci si aspetta che un Senior SCS di Lokad gestisca eventuali domande o preoccupazioni sull’iniziativa. Pertanto, per quanto riguarda l’escalation, la risoluzione di un problema preoccupante viene tipicamente escalata da un Junior SCS a un Senior. Storicamente ciò si è dimostrato sufficiente con pochissime situazioni che richiedono ulteriore escalation.

Lokad considera tutti i problemi - per quanto minori possano sembrare - meritevoli di un’analisi approfondita. Anche se i loro effetti sono facili da risolvere, i problemi minori possono causare problemi futuri se le cause profonde non sono comprese e affrontate. Ciò impedisce che un problema minore diventi ricorrente. Pertanto, Lokad preferisce mettere persone altamente capaci in prima linea capaci di affrontare sia il problema immediato che di identificare le cause profonde sottostanti. Questo approccio è preferibile rispetto a fare affidamento su personale di supporto non addestrato che affronta continuamente gli stessi problemi - un modello troppo frequentemente adottato da molti fornitori di software aziendale.

Pertanto, il processo di escalation conciso di Lokad è intenzionale, garantendo risoluzioni 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ì. Più in generale, gli Scienziati della Supply Chain di Lokad (SCSs) seguono qualsiasi processo sia stato negoziato e concordato con ciascun cliente - secondo termini contrattuali formali. Questo principio rimane applicabile per tutta l’iniziativa, dall’inizio alla conclusione. 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 - specialmente se confrontata con i nostri concorrenti.

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

1.7 Verrà assegnato un project manager dedicato da Lokad da collocare presso la sede dell’azienda cliente, accompagnato da esperti di prodotto, analisti aziendali ed esperti di interfaccia tecnica?

Sì, se tali disposizioni fanno parte dei termini contrattuali concordati per l’iniziativa. Anche se Lokad non è contrario a collocare dipendenti presso la sede dell’azienda cliente, ciò aumenta naturalmente il costo dell’iniziativa. La maggior parte delle nostre iniziative viene svolta a distanza e supportata da visite mensili o trimestrali a seconda della portata dell’iniziativa. Questa pratica di solito è percepita da tutte le parti come più efficiente rispetto a collocare i dipendenti di Lokad presso gli uffici del cliente tutto il tempo. Va notato che, anche se Lokad accetta di collocare un team permanente presso la sede dell’azienda cliente, i dipendenti si alterneranno nel tempo.

Tali pratiche sono vantaggiose per tutti i coinvolti, poiché gli Scienziati della Supply Chain di Lokad (SCSs) sono soggetti a un programma di formazione in corso. Questo programma è fondamentale per garantire che i nostri dipendenti continuino ad acquisire nuove competenze o a perfezionare quelle vecchie, indipendentemente dall’esperienza o dall’anzianità. Mentre osserviamo che molti fornitori aziendali permettono ai propri dipendenti di operare per mesi, se non anni, presso sedi remote dei clienti, Lokad è convinta che questa pratica non sia compatibile con la fornitura affidabile ed efficiente di programmi di formazione di alta qualità.

In particolare, una delle maggiori forze degli SCS di Lokad è la loro eccezionale e ampia gamma di competenze. Ogni SCS è addestrato per agire in una varietà di ruoli, come: esperto di materia, analista aziendale, esperto di interfaccia tecnica, scienziato dei dati e consulente di supply chain. Queste funzioni normalmente sarebbero svolte da diversi dipendenti e comporterebbero un aumento significativo dei costi per il cliente. Da Lokad, ogni SCS fornisce tutti questi servizi.

Di conseguenza, gli SCS tendono ad essere notevolmente più produttivi (meno persone tendono a significare meno attrito nella comunicazione), oltre a garantire livelli di performance più elevati. In realtà, le supply chain dipendono criticamente dalla coerenza end-to-end, qualcosa che è molto più facile da raggiungere con un basso numero di dipendenti.

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

Per un’iniziativa tipica presso Lokad, raccomandiamo che l’azienda cliente assegni un praticante esperto di supply chain come coordinatore dell’iniziativa, e che nomini un dirigente di supply chain come supervisore dell’iniziativa. Il coordinatore funge da punto di contatto tra il team di Scienziati della Supply Chain di Lokad (SCSs) e l’azienda cliente. Il coordinatore trasmetterà inizialmente le richieste di informazioni e successivamente le richieste di feedback. Parallelamente, gli SCS di Lokad lavorano con le ricette numeriche mirate a produrre le decisioni di supply chain di interesse.

Raccomandiamo un incontro settimanale per rivedere i progressi dell’iniziativa fino al completamento della fase di onboarding. A questo incontro partecipano sistematicamente il coordinatore, il supervisore e lo SCS principale dell’account di Lokad. Altri partecipanti possono unirsi secondo necessità, ma la loro presenza continua di solito non è necessaria durante l’implementazione/fase di onboarding.

Alcune risorse IT devono essere allocate per la configurazione del data pipeline all’inizio dell’iniziativa. Lokad è più efficiente rispetto alla maggior parte dei suoi concorrenti in questo senso. Ad esempio, estraiamo automaticamente e direttamente i dati transazionali del cliente, senza alcuna pulizia o preparazione richiesta dal lato del cliente. A meno che l’azienda cliente non stia vivendo un blocco del fornitore, questa configurazione tecnica richiede meno di 4 settimane di lavoro per un singolo contributore - e a volte molto meno quando è già presente un data lake.

Successivamente, gli SCS dovranno raccogliere informazioni qualitative sui processi esistenti e sui dettagli di tutte le priorità e vincoli della supply chain. Una serie di interviste, facilitate dai coordinatori, avrà luogo tipicamente per supportare questo processo. Successivamente, una volta che gli SCS hanno sviluppato le ricette numeriche, si svolgerà un’altra serie di interviste per rivedere i dati generati da tali ricette e permettere agli SCS di perfezionarli e migliorarli.

Il contributo del supervisore è importante sia per allineare Lokad con la strategia di alto livello pursued dall’azienda e per evitare che l’iniziativa si blocchi a causa dell’incertezza. Ad esempio, Lokad può proporre varie 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 alla fine, devono essere prese alcune scelte strategiche.

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

Per ulteriori informazioni, Lokad ha diverse lezioni dedicate all’esecuzione tattica e strategica di una corretta ottimizzazione della supply chain.

2. Gestione delle risorse e requisiti

2.1 Quali sono i requisiti di manodopera per l’implementazione del progetto presso l’azienda cliente, in particolare il numero di risorse e il loro livello di competenza? Puoi definire con precisione il numero di risorse per ciascuna fase e sottofase del progetto?

Un’iniziativa tipica di Lokad richiede approssimativamente da 0,5 a 2 risorse equivalenti a tempo pieno (FTE) dall’azienda cliente durante i primi 6 mesi - alias, la fase di onboarding. Una volta che l’iniziativa entra in produzione, una stima ragionevole è che il progetto richiederà comunque almeno lo 0,25 FTE. Naturalmente, queste stime variano notevolmente in base alla dimensione e complessità dell’azienda cliente e alle specifiche esigenze della supply chain.

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

• Mesi 1 e 2: La configurazione del data pipeline richiede 4 settimane di impegno a tempo pieno da parte di un responsabile dei dati, di solito impiegato dall’IT del cliente. Il responsabile dei dati dovrebbe essere piuttosto familiare con il panorama applicativo dell’azienda cliente. Questo requisito può essere ridotto se è già presente un data lake, ma al contrario, sarà aumentato se il data pipeline deve far fronte a più sistemi aziendali (ad esempio, 1 ERP per paese). Una volta che il data pipeline è operativo, la sua manutenzione non dovrebbe richiedere più di qualche ora al mese dal responsabile dei dati.

• Mesi 3 e 4: La progettazione della ricetta numerica richiede 2 o 3 giorni a settimana dal coordinatore (lato cliente) dell’iniziativa, un minimo di 10 ore a settimana da vari professionisti della supply chain per fornire spunti di alto livello e successivamente per fornire feedback sulle cifre prodotte da Lokad. Ci si aspetta che il coordinatore sia familiare con l’azienda e la sua supply chain, e a suo agio con il lavoro analitico. Tuttavia, questa posizione non richiede competenze informatiche specializzate o specifiche competenze in scienze dei dati. La revisione settimanale dell’iniziativa richiede mezza giornata a settimana da un dirigente della supply chain.

• Mesi 5 e 6: I requisiti sono essenzialmente gli stessi della fase precedente, tuttavia, il focus cambia. Il coordinatore trascorre ora la maggior parte del tempo preparando il corretto lancio e comunicando con tutti i professionisti della supply chain interessati. Allo stesso modo, il dirigente della supply chain supervisiona la gestione del cambiamento interno legata ai nuovi processi derivanti dall’iniziativa di Lokad.

Vedi anche Implementazione e Gestione del Progetto 1.2.

2.2 Ti assicuri che sia pianificata una manodopera adeguata per supportare la transizione del prodotto?

Sì. Come regola generale, Lokad raccomanda di mantenere lo stesso numero di risorse (ad esempio, gli stessi Supply Chain Scientists), durante la transizione dalla fase di onboarding alla fase 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 una mentalità di impostare e dimenticare, poiché qualsiasi soluzione tecnica inevitabilmente - e continuamente - tenderà verso l’irrilevanza e l’obsolescenza se non viene monitorata e mantenuta correttamente.

È importante notare che, dato che Lokad automatizza le decisioni della supply chain, non c’è un’urgenza rigorosa nel riaddestrare tutti i professionisti 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 è insolito che il completo rinnovamento dell’organizzazione della supply chain del cliente - innescato dall’iniziativa di Lokad - sia completato pochi mesi dopo che il progetto va live.

Questo approccio snello è in netto contrasto con i grandi - e costosi - “task force” spesso richiesti dai fornitori di software aziendale per andare live.

2.3 Puoi garantire che siano disponibili sul posto presso la sede dell’azienda cliente risorse sufficienti di manodopera e conoscenze del prodotto (KP) per supportare la transizione del prodotto?

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

Vedi anche Implementazione e Gestione del Progetto 1.7.

Vedi anche Gestione delle Risorse e Requisiti 2.2.

2.4 Organizzi sessioni di Revisione dei Requisiti con i proprietari del prodotto aziendale per raccogliere e documentare i requisiti?

Sì. Uno degli obiettivi principali dello Supply Chain Scientist è acquisire tutti gli spunti necessari sulla supply chain del cliente. Questo processo viene tipicamente condotto attraverso interviste con le parti interessate rilevanti, inclusi i proprietari del prodotto aziendale. Cerchiamo anche di esaminare attentamente i documenti esistenti (quando disponibili), al fine di sfruttare al meglio tali interviste.

Tuttavia, la preoccupazione principale di Lokad è capire il ‘problema’ in esame, cosa che non è sempre facilitata dall’elenco dei ‘requisiti’. Ad esempio, se un cliente menziona che richiede un trattamento speciale per i ‘prodotti lenti’, comprendiamo che il basso volume è una preoccupazione da affrontare. Tuttavia, il trattamento speciale di quegli SKU è solo una delle molte opzioni disponibili per affrontare questa preoccupazione.

In questo esempio, la nostra preferenza sarebbe quella di determinare la vera natura dei ‘prodotti lenti’. Infatti, dopo aver indagato sui punti critici della supply chain del cliente, potrebbe essere il caso che i ‘prodotti lenti’ siano SKU che sono stati prezzati, raggruppati e/o allocati in modo improprio. Una volta compreso meglio il problema (prodotti lenti), cambia completamente la strategia di intervento, rendendola spesso più facile da affrontare.

Pertanto, sebbene Lokad rilevi e documenti tutti i requisiti del cliente, il nostro approccio enfatizza la scoperta della vera natura del problema, piuttosto che accettare a prima vista lo stato attuale della supply chain del cliente.

Vedi Innamorati del Problema, Non della Soluzione per ulteriori informazioni sulla dicotomia problema-soluzione.

2.5 Fornite stime di sforzo, costi e tempi per le funzionalità che richiedono personalizzazione, inclusi gli interfacce di sistema, e li condividete dopo il workshop di analisi di adattamento?

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

La piattaforma Lokad è programmabile. Pertanto, l’implementazione è destinata ad essere supportata da script, scritti in Envision, il nostro DSL (linguaggio di programmazione specifico del dominio) dedicato all’ottimizzazione predittiva delle supply chain. Di conseguenza, Lokad è particolarmente adatto per fornire funzionalità e interfacce personalizzate, che siano destinate alle persone o ai sistemi aziendali della società cliente.

A differenza della maggior parte del software enterprise, la programmabilità è una caratteristica fondamentale per Lokad. Gli script Envision sopra menzionati non sono una ‘personalizzazione’ della soluzione Lokad nel senso usuale. Né la presenza di quegli script è una deviazione dal ramo principale dello sviluppo della soluzione Lokad. Piuttosto, la ricca programmabilità di Lokad è il percorso di implementazione previsto.

Di conseguenza, c’è un grado estremamente elevato di certezza legato alle nostre stime (costi, tempi, ecc.). La stragrande maggioranza dei progetti rimane entro le stime/budget iniziali (in tutti i sensi). Questo è in netto contrasto con diversi concorrenti di Lokad, per i quali ritardi costosi e riformulazioni dei termini sono comuni.

Vedi Studio di Caso sul Disastro SAP da €500 Milioni di Lidl per ulteriori informazioni su questo punto.

2.6 Implementerete e manterrete una strategia di trattenimento ragionevole progettata per trattenere il personale chiave che svolge i servizi per il termine dell’accordo? Manterrete anche piani di successione attivi per ciascuna delle posizioni chiave del personale di Lokad?

Sì. Manteniamo i dipendenti in media per 3,5 anni, che è quasi il doppio della permanenza lavorativa rispetto a coorti simili (ingegneri talentuosi in IT, o domini adiacenti all’IT) in mercati simili (America del Nord e Europa Occidentale). Questo segmento del mercato del lavoro è estremamente competitivo e, sebbene ci sia sempre spazio per miglioramenti, questo pone Lokad ben al di sopra della maggior parte dei nostri concorrenti. Di conseguenza, la maggior parte delle iniziative di Lokad beneficia del fatto che gli stessi Supply Chain Scientists (SCSs) rimangono di anno in anno.

Questa trattenzione è attribuibile a salari competitivi e all’investimento continuo di Lokad nella formazione dei suoi team. In particolare, i contenuti sulla supply chain pubblicati da Lokad sul proprio sito web, in particolare la nostra serie di lezioni sulla supply chain, possono essere visti come un prodotto collaterale del focus di Lokad sulla formazione del proprio personale. In generale, i fornitori di software aziendale che non hanno materiali di formazione pubblici quasi mai hanno nemmeno materiali di formazione privati (anche se inevitabilmente affermeranno il contrario).

Per quanto riguarda i piani di successione, abbiamo due pratiche importanti in gioco. In primo luogo, ogni iniziativa di Lokad è corredata da un Manuale di Procedura Condiviso (JPM). Il JPM è il documento principale utilizzato da un nuovo SCS per familiarizzarsi rapidamente con tutte le informazioni rilevanti e le tecniche dell’iniziativa. In secondo luogo, ogni iniziativa ha - in ogni momento - sia un SCS primario che uno secondario. Anche se il SCS secondario non contribuisce direttamente all’iniziativa, Lokad dedica abbastanza tempo per assicurarsi che questa persona sia pronta a prendere in carico l’iniziativa nel caso dovesse mai sorgere la necessità. Questa pratica mitiga in larga parte le complicazioni legate a assenze/imprevisti.

3. Ruoli, Responsabilità e Gestione degli Stakeholder

3.1 Quale livello di cooperazione avete con l’azienda cliente?

Il livello di cooperazione che abbiamo con i nostri clienti varia, ma nel complesso è molto più elevato rispetto a quello che di solito ci si aspetta da un fornitore di software aziendale. Le preoccupazioni sulla supply chain non sono ugualmente importanti per tutte le aziende, quindi la collaborazione tende ad essere più forte per le aziende in cui la supply chain è la spina dorsale riconosciuta delle loro attività.

Il termine ‘partner’ è stato diluito al punto che persino i fornitori di prodotti software banali (come software di tracciamento del tempo) finiscono per essere definiti ‘partner’. Tuttavia, dopo un anno o due, la maggior parte dei nostri clienti si riferisce alla loro relazione con Lokad come una ‘vera’ partnership - nel vero senso della parola. Hanno volti familiari a Lokad che si sono guadagnati la loro fiducia e, di conseguenza, quelle persone - tipicamente Supply Chain Scientists (SCSs) - sono intimamente familiari con il loro business. Inoltre, i nostri risultati vengono spesso ritenuti sufficientemente notevoli da essere presentati personalmente al CEO e/o al consiglio di amministrazione dell’azienda, anche in aziende di grandi dimensioni.

La collaborazione continua con Lokad consente ai nostri clienti di riprogettare positivamente l’intera pratica della loro supply chain. Alla fine, l’intera catena viene rivoluzionata, avendo un impatto positivo sia sui clienti che sui fornitori. Va notato che Lokad non ha alcuna intenzione di sostituire l’importante competenza strategica che esiste nell’azienda cliente. Piuttosto, Lokad desidera automatizzare gli aspetti più noiosi e ripetitivi dei processi decisionali della supply chain. Questo approccio libera successivamente risorse significative - e spesso scarse - del cliente che possono essere reindirizzate a utilizzi migliori.

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

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

• Il Leader della Supply Chain: Questo ruolo sottolinea l’importanza del coinvolgimento della dirigenza nell’iniziativa quantitativa sulla supply chain. Pur non essendo previsto che si addentri nei dettagli tecnici, questa persona deve comprendere e comunicare le intuizioni strategiche dell’iniziativa. Il loro ruolo non è quello di creare metriche e KPI, piuttosto, il loro ruolo è quello di valutarli criticamente e sfidarli, garantendo l’allineamento con la strategia generale.

• Il Coordinatore della Supply Chain: Essenziale per garantire il corretto funzionamento dell’iniziativa, questa persona agisce da ponte tra vari team interni. La loro responsabilità principale è raccogliere feedback, comunicare con gli stakeholder e confermare/chiarire processi e decisioni. Si assicurano che l’iniziativa sia allineata con i flussi di lavoro aziendali esistenti, mantenendo anche una mente aperta per eventuali revisioni dei flussi di lavoro in futuro.

• Il Responsabile dei Dati: I dati sono il fondamento dell’iniziativa quantitativa sulla supply chain, e questa persona ne garantisce l’accessibilità e l’affidabilità. Incaricati di estrarre set di dati completi (come storici di vendite e acquisti), sono responsabili dell’estrazione automatica e della pianificazione dei dati. Sebbene il loro ruolo sia più intenso all’inizio dell’iniziativa, il loro contributo è cruciale per il suo successo.

• Lo Scienziato della Supply Chain: Questo ruolo fonde le intuizioni del Coordinatore della Supply Chain con i dati del Responsabile dei Dati per automatizzare i processi decisionali. Partendo dalla preparazione dei dati, lo Scienziato della Supply Chain collabora strettamente con il Coordinatore per chiarire eventuali ambiguità nei dati. Formalizzano quindi le strategie in decisioni operative, come le quantità di riordino, e implementano dashboard e KPI per trasparenza e controllo.

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

3.3 Hai una tabella RACI (Responsabile / Accountable / Consulted / Informed) completa per la fase di implementazione e per la fase di produzione?

Sì. Queste informazioni possono essere presentate esplicitamente come una tabella RACI se ritenuto importante dall’azienda cliente.

Più importantemente, gli Scienziati della Supply Chain (SCSs) di Lokad interiorizzano questo tipo di matrice per prendere decisioni adeguate e rapide man mano che l’iniziativa progredisce. Per quanto riguarda le questioni legate all’ottimizzazione di una supply chain, il punto cruciale è capire il modo migliore per formulare il problema. Successivamente, l’attenzione si sposta sull’individuare chi nell’organizzazione è il più adatto ad affrontare il problema. In modo critico, tutta questa analisi deve essere fatta rapidamente per preservare il momentum dell’iniziativa.

A tal fine, gli SCSs di Lokad sono designati per guidare l’iniziativa e assumersi la responsabilità sulla qualità dell’output generato dalla ricetta numerica di Lokad.

Pertanto, si tratta di un piccolo nucleo di specialisti altamente addestrati che sono responsabili delle decisioni sulla supply chain generate da Lokad, piuttosto che di un elaborato “sistema” o “processo” di delega di porzioni di responsabilità tra un vasto gruppo di stakeholder. È posizione di Lokad che tali sistemi tendano a diluire la responsabilità, piuttosto che renderla più rigida. I nostri SCSs sono quindi formati ad adottare e operare con questa responsabilità, e ciò include garantire che gli stakeholder rilevanti dell’azienda cliente siano consultati e pienamente informati sull’iniziativa.

3.4 Documenterai ruoli e responsabilità utilizzando una matrice RACI (Responsabilità, Accountabilità, Consultato e Informato) per tutti gli stakeholder coinvolti nel progetto? Ti assicurerai che questo documento sia discusso e concordato da tutte le parti coinvolte?

Sì. Tutti questi elementi (e altri) sono raccolti e documentati nel Manuale di Procedura Condiviso (JPM). Il JPM è prodotto dagli Scienziati della Supply Chain (SCSs) di Lokad (con intuizioni raccolte direttamente dall’azienda cliente). In questo documento, sono dettagliati i parametri del ruolo e della responsabilità di ciascuna persona.

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

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

Su una nota correlata, la nostra esperienza indica che in caso di disaccordi, di solito riflettono un problema organizzativo da risolvere all’interno dell’azienda cliente. Per questo motivo, raccomandiamo all’azienda cliente di nominare un Esecutivo della Supply Chain per supervisionare l’iniziativa. Uno dei loro contributi principali è agire come intermediario in caso di tali situazioni.

3.5 Ti assicurerai che il gruppo di lavoro del progetto e i gruppi di steering siano formati con risorse nominate dagli stakeholder del progetto? Ti assicurerai che il ritmo operativo sia concordato da tutte le parti coinvolte?

Sì. Come principio generale, seguiamo qualsiasi processo ritenuto necessario da - e formalmente concordato con - l’azienda cliente. Gli elementi concordati (e eventuali modifiche apportate durante l’iniziativa) sono documentati nel Manuale di Procedura Condiviso (JPM), che include dettagli riguardanti il gruppo di lavoro del progetto e i gruppi di steering. Attraverso gli Scienziati della Supply Chain di Lokad (SCSs), abbiamo le risorse necessarie per installare e monitorare questi processi.

Aneddoticamente, uno dei contributi più apprezzati di Lokad è la nostra capacità di semplificare i processi - che siano di supply chain o di natura burocratica. Nel tempo, lavoriamo attivamente per rimuovere strati burocratici non necessari dalle supply chain dei nostri clienti.

4. Transizione del Sistema e 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 con Lokad che è ‘in produzione’ - cioè, le nostre raccomandazioni automatizzate sulla supply chain guidano efficacemente il processo decisionale desiderato del cliente.

Questa durata può essere accorciata di 1 mese se è già presente un data lake - un data lake ben costruito e documentato può accorciare ulteriormente la fase di onboarding. Al contrario, questa fase viene tipicamente aumentata di 1 a 3 mesi quando l’ambiente software o di sistemi del cliente è eccessivamente complesso o obsoleto.

Interessante notare che la complessità della supply chain stessa non è così impattante come potrebbe sembrare, poiché Lokad si impegna a definire uno scope sufficientemente preciso che sia fattibile entro il tempo previsto. La nostra esperienza indica che le fasi di onboarding che durano più di 6 mesi mettono l’iniziativa a rischio di stasi. Pertanto, lavoriamo attivamente per progettare lo scope per mitigare questo rischio.

Tali ritardi hanno poco a che fare con l’impostazione tecnica di Lokad stessa. Nel complesso, la timeline suggerita serve non solo a scopi tecnici (automatizzazione dell’estrazione dei dati, test di ricette numeriche, ecc.), ma fornisce anche agli Scienziati della Supply Chain di Lokad (SCSs) la possibilità di diventare pienamente competenti con tutti i dettagli dell’azienda cliente e per i team di supply chain di “digerire” l’approccio di Lokad - qualcosa che rappresenta tipicamente una deviazione dal processo legacy del cliente.

4.2 Quante visite in loco hai pianificato? Quanti workshop in loco hai pianificato?

Il numero di visite e workshop effettuati in loco è negoziato come parte dei termini contrattuali specifici con l’azienda cliente, anche se va notato che i costi di viaggio possono influenzare le tariffe addebitate da Lokad. Quindi, l’inclusione di visite in loco è in ultima analisi una decisione da prendere da parte dell’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. Consigliamo questo approccio per le piccole aziende (fatturato annuo inferiore a 100 milioni di USD) e per le aziende che sono generalmente a loro agio con i collaboratori remoti (come le grandi aziende di eCommerce). Circa la metà delle iniziative portate avanti da Lokad appartengono a 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 più frequenti se necessario. Per le grandi aziende (fatturato annuo superiore a 1 miliardo di USD), raccomandiamo almeno una visita/workshop trimestrale in loco. Questo approccio aiuta a sviluppare un’allineamento aziendale a livello aziendale, specialmente quando sono coinvolti team numerosi.

Per i nostri clienti nell’Europa occidentale, tendiamo ad avere più visite (di solito della durata di un giorno) che workshop quando siamo in loco. Per i nostri clienti al di fuori dell’Europa occidentale, tendiamo a fare più workshop (di solito della durata di più giorni) che visite quando siamo in loco. Questa differenza è una semplice questione di costi di viaggio associati e logistica.

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

Per un’iniziativa quantitativa di supply chain, la maggior parte delle riunioni dovrebbe essere remote. La maggior parte delle riunioni sono brevi (30 minuti o meno) e coinvolgono solo due partecipanti: uno Scienziato della Supply Chain di Lokad e un praticante di supply chain dell’azienda cliente. Inoltre, le riunioni remote sono utili per compiti tecnici specifici, poiché tutti i partecipanti hanno accesso alla propria configurazione informatica, compreso l’accesso a monitor di grandi dimensioni. Questo è particolarmente utile quando i partecipanti devono investigare report complessi.

Tuttavia, Lokad non sottovaluta il valore delle riunioni in loco con i clienti. Le riunioni in loco rendono spesso più facile comunicare idee complesse, discutere prospettive e/o rivedere le aspettative tra le parti. Pertanto, raccomandiamo di adottare un ritmo regolare per le riunioni in loco (ad esempio settimanali/mensili/trimestrali…). Lokad tratta tali riunioni in loco come eventi significativi, specialmente quando Lokad ospita il cliente.

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

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

Sì. In effetti, Lokad va oltre semplicemente assistere l’azienda cliente nella valutazione della sua prontezza per un go-live. Una delle principali responsabilità degli Scienziati della Supply Chain di Lokad (SCSs) è assumersi la responsabilità della soluzione end-to-end consegnata all’azienda cliente. In altre parole, anche se un sistema meccanizzato (una flotta di macchine) genera i risultati, è comunque una persona che si assume la responsabilità personale del sistema. Garantiscono l’accuratezza, la rilevanza e l’appropriatezza del flusso di elaborazione dei dati end-to-end, tenendo conto anche delle preoccupazioni aziendali complessive del cliente.

Date le loro natura incline agli errori, le interfacce software meritano attenzione specifica e lo SCS è ben attrezzato per assistere nella valutazione della loro integrità. Lokad valuta questa integrità sul lato di ingresso (quando Lokad riceve dati storici dall’azienda cliente) e sul lato di uscita (quando Lokad restituisce decisioni di supply chain all’azienda cliente). Per questo compito, Lokad sfrutta metodologie e tecnologie specifiche.

Si prega di consultare paradigmi di programmazione per la supply chain per comprendere meglio il tipo di tecnologie che Lokad utilizza per garantire la prontezza al go-live.

4.5 Preparate il documento strategico di transizione e migrazione della produzione per gestire la transizione senza soluzione di continuità delle operazioni aziendali (dall’applicazione aziendale esistente alla nuova applicazione aziendale) per l’azienda cliente?

Sì. La transizione è documentata nel nostro Manuale di Procedura Condiviso (JPM). Questa documentazione estesa, prodotta dagli Scienziati della Supply Chain di Lokad (SCS), garantisce che sia i praticanti della supply chain che i dirigenti della supply chain abbiano accesso a materiali ben scritti che spieghino adeguatamente il processo in termini comprensibili. Gli SCS fanno notevoli sforzi per garantire che questo documento sia accessibile a un pubblico non tecnico (anche se alcuni allegati possono essere piuttosto tecnici).

Inoltre, l’approccio a doppia esecuzione di Lokad è particolarmente adatto per garantire una transizione senza intoppi dal processo legacy alla nuova soluzione. “Doppia esecuzione”, in questo contesto, si riferisce alla pratica in cui Lokad funzionerà contemporaneamente con il processo decisionale legacy su tutta la portata dell’iniziativa. La pratica è resa possibile solo grazie alla natura robotizzata del processo decisionale legacy da parte di Lokad, garantisce che le ricette numeriche implementate dagli SCS di Lokad siano state eseguite in modo soddisfacente in condizioni di produzione esatte, su tutta la portata, per settimane prima del go-live effettivo, dove le decisioni di Lokad sostituiscono il processo legacy.

Va notato che una tale doppia esecuzione non è tipicamente possibile con tecnologie e metodologie alternative proposte dai nostri concorrenti. Infatti, poiché non robotizzano le decisioni di supply chain, i costi indiretti associati a una doppia esecuzione sono significativi. Di conseguenza, la doppia esecuzione viene eseguita al meglio su una piccola portata che non riflette genuinamente le condizioni di produzione. Di conseguenza, quando viene adottato un tale approccio, l’estensione tardiva della portata porta inevitabilmente a incidenti di produzione che sarebbero stati completamente evitabili con una doppia esecuzione a piena portata.

4.6 Fornite la portata, i tempi e i criteri di successo per l’esecuzione pilota da revisionare e approvare da parte dell’azienda cliente?

Sì. La portata è sempre dettagliata nell’accordo contrattuale tra Lokad e l’azienda cliente. Di solito assume la forma di un determinato tipo di decisione di supply chain (ad esempio, rifornimento di magazzino o allocazione di stock) su un insieme di sedi e/o su un insieme di sistemi aziendali.

Il periodo temporale è tipicamente inferiore a 6 mesi (dal kick-off alla produzione). Sebbene una tempistica proiettata 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 di Lokad dipende dall’esecuzione tempestiva di determinati passaggi da parte dell’azienda cliente, in particolare dalla costruzione di un data pipeline verso Lokad.

Per quanto riguarda i criteri di successo, la decisione è sempre presa unilateralmente dall’azienda cliente. Sebbene possiamo documentare i principi guida che dovrebbero sostenere questa decisione, una decisione non unilaterale sarebbe insolita. In poche parole, un fornitore non dovrebbe essere in grado di decidere che l’esecuzione pilota è stata un successo se il cliente la pensa diversamente.

Vedi anche Implementazione e Gestione del Progetto 1.2.

Si prega di consultare Valutare il Successo di un’Iniziativa Quantitativa di Supply Chain per ulteriori informazioni su questo punto sfumato.

4.7 Organizzerete lo svolgimento delle esecuzioni pilota 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ì. Come regola generale, trattiamo una prova pilota - destinata a fornire ottimizzazione della supply chain - esattamente come tratteremmo un’iniziativa “reale” destinata a essere portata in produzione. Per tutti gli effetti pratici, per quanto riguarda l’ottimizzazione della supply chain, una prova pilota adeguata è indistinguibile da una configurazione pre-produzione approvata per l’uso in produzione.

Il team di Supply Chain Scientists (SCSs) di Lokad è responsabile di tutto quanto sopra. Nella nostra esperienza, l’adeguatezza dei dati è raramente un problema nelle aziende che sono passate al digitale molti anni (se non decenni) fa. Finché c’è un sistema aziendale per tracciare ciò che viene acquistato, prodotto, messo in magazzino e venduto, l’iniziativa è quasi garantita di avere dati adeguati. La sfida è dare un senso ai dati che non sono stati originariamente raccolti per supportare l’ottimizzazione della supply chain.

Consulta dati non validi per ulteriori informazioni su questo punto.

5. Gestione del Cambiamento e del Rischio

5.1 Che supporto potete offrire all’azienda cliente per aiutare a gestire la gestione del cambiamento associata all’implementazione dell’iniziativa?

Tutti i clienti hanno il pieno impegno dei 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 professionisti della supply chain impiegati dall’azienda cliente.

• Produrre materiali formativi per integrare i membri/i team dell’azienda 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.

Deve essere notato che la gestione del cambiamento può rappresentare un impegno significativo di tempo per un SCS. Anche se ogni SCS ha competenze e esperienze uniche adatte ad aiutare la leadership della supply chain nella gestione del cambiamento, questo compito compete con tutti gli altri compiti.

Pertanto, i termini contrattuali negoziati tra Lokad e ogni cliente specificano la quantità di risorse - cioè la dimensione del team di SCSs - che saranno disponibili per supportare l’iniziativa. Le nostre proposte commerciali di solito prevedono che gli SCSs forniranno un certo supporto alla gestione del cambiamento. Tuttavia, le nostre proposte di solito non riflettono alcun tipo di supporto “su larga scala” per la gestione del cambiamento - a meno che questo non venga esplicitamente richiesto dal cliente.

5.2 Durante la fase di produzione, qual è la vostra visione per la gestione del cambiamento? Quali sono i principali traguardi? Come apparirà la nuova organizzazione dopo l’implementazione riuscita della nuova soluzione?

Una volta che Lokad è in produzione, una classe intera di decisioni sulla supply chain è automatizzata. L’obiettivo è quindi trasformare la pratica della supply chain in un’attività capitalista. Ogni ora trascorsa da un professionista della supply chain dovrebbe contribuire al miglioramento continuo delle ricette numeriche. Questo è un cambiamento rispetto alla pratica della supply chain “mainstream” in cui la stragrande maggioranza degli sforzi in un dato giorno è dedicata a mantenere l’azienda in attività per un altro giorno. Naturalmente, la transizione a questa forma di supply chain che aggiunge valore è graduale.

• Il primo traguardo è far sì che i professionisti della supply chain riconoscano che Lokad permette loro di scartare la maggior parte dei processi ereditati. Ad esempio, ha senso rivedere le quantità di rifornimento giornaliere quando tali quantità sono frequentemente errate. Tuttavia, per progettazione, le quantità di Lokad sono già corrette e non necessitano di ulteriori revisioni. Di fatto, il 0% di assurdità nei numeri generati da Lokad è il criterio principale per il passaggio alla produzione. La fiducia che i professionisti della supply chain possono riporre nei numeri di Lokad libera naturalmente molto tempo che può essere impiegato meglio.

• Il secondo traguardo consiste nel avere alcuni “early adopters” tra i professionisti della supply chain. Queste sono tipicamente persone che riescono rapidamente a separarsi dal processo ereditato non aggiuntivo di valore - ad esempio, la revisione manuale dei numeri - per concentrarsi sul miglioramento continuo della supply chain attraverso le sue ricette numeriche. Possono iniziare ad affrontare numerose domande importanti oltre agli aspetti tecnici minori (ad esempio, l’azienda cliente sta guardando alla sua qualità del servizio dal giusto punto di vista?).

• Il terzo traguardo è quello di avere la maggior parte dei professionisti della supply chain che guardano verso l’esterno (clienti e fornitori) piuttosto che verso l’interno. In definitiva, la supply chain deve fornire un allineamento che vada oltre i confini dell’azienda cliente. Questo espande il pool di conoscenze raccolte e aiuta a perfezionare ulteriormente le ricette numeriche.

La nuova organizzazione è molto più simile a un’azienda di software. Ci sono poche attività ripetitive della supply chain che vengono gestite manualmente - poiché le attività ripetitive sono ora automatizzate. Ci sono anche molto meno emergenze (di nuovo, grazie all’automazione). La riduzione delle attività di routine comporta un aumento della varietà di compiti per il professionista della supply chain. Tipicamente, ciò si traduce in meno tempo e sforzi dedicati al controllo della supply chain, ma ci si aspetta di più dalla gestione per potenziare i dipendenti in modo che possano capitalizzare sul tempo e sforzi disponibili aumentati.

Vedi (Software) Consegna orientata al prodotto per la Supply Chain per ulteriori informazioni su questa transizione.

5.3 Come gestisci il cambiamento del flusso di lavoro per gli utenti finali? Prima, con l’onboarding di Lokad, poi con l’evoluzione di Lokad stessa.

Per progettazione, le decisioni sulla supply chain generate da Lokad non richiedono flussi di lavoro. In realtà, l’automazione di tutti i passaggi coinvolti nella generazione delle decisioni sulla supply chain è l’organizzazione desiderata.

Tuttavia, se esplicitamente richiesto dal cliente, Lokad è in grado di introdurre un “flusso di lavoro” che riflette quello ereditato. Questo, va capito, è puramente per facilitare il change management, e non è un requisito per il successo della ricetta numerica in alcun modo. Man mano che i dipendenti del cliente diventano più familiari con - e sviluppano maggiore fiducia nelle - le decisioni generate da Lokad, il “flusso di lavoro” può essere gradualmente semplificato, fino a quando non viene completamente rimosso.

Riguardo all’evoluzione di Lokad, la nostra piattaforma è programmabile e gestita da Envision (il nostro linguaggio di programmazione specifico del dominio). Eventuali modifiche/aggiornamenti a Envision vengono effettuati tramite script automatizzati, e questo processo è programmato in modo che le iniziative della supply chain ospitate da Lokad rimangano intatte.

5.4 Puoi mantenere un registro di problemi e rischi che includa un piano di mitigazione, compiti, responsabilità, tempi e stato (non iniziato, in corso, chiuso, in attesa)? Il Project Manager di Lokad sarà responsabile del monitoraggio di tutti i problemi e rischi e dell’assicurarsi che le risoluzioni siano tempestive o della gestione delle escalation quando necessario?

Sì. La piattaforma di Lokad è dotata del proprio gestore interno di problemi/ticket/compiti. Questa funzione fornisce tutte le capacità usuali che ci si aspetta comunemente da uno strumento del genere, come la gestione degli stati, delle priorità, degli assegnamenti, delle notifiche, ecc. Inoltre, manteniamo separatamente un Manuale di Procedura Condivisa (JPM) che fornisce una presentazione completa e ben organizzata dell’iniziativa con tutti i tempi di alto livello rilevanti. Gli Scienziati della Supply Chain di Lokad (SCSs) sono responsabili della supervisione del gestore dei compiti. Si assicurano che i problemi e le preoccupazioni siano affrontati prontamente.

Le escalation sono possibili ma rare. Lo stesso SCS che gestisce/revisiona i compiti li risolverà anche. Gli SCS senior di Lokad svolgono una vasta gamma di ruoli: esperto di supply chain, ingegnere dei dati, integratore dei dati, analista aziendale, scienziato dei dati, project manager, consulente per il cambiamento, ecc.

La capacità di contattare facilmente gli SCS è qualcosa che i nostri clienti citano abitualmente come un grande punto di forza. Il cliente può interagire immediatamente con la persona il cui compito è supervisionare la risoluzione soddisfacente di eventuali problemi anziché dover navigare attraverso diversi livelli di burocrazia per - sperabilmente - parlare con qualcuno in grado di aiutarli.

Nel caso si verifichi un problema che richiede competenze al di fuori dell’esperienza di un SCS (ad esempio, un problema tecnico con l’architettura della piattaforma), loro supervisioneranno comunque la risoluzione tempestiva del problema e agiranno come primo punto di contatto per il rispettivo cliente.

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

Sì, se l’azienda cliente desidera che il loro partenariato con Lokad includa servizi di consulenza sulla gestione del cambiamento. Va notato che l’esperienza principale di Lokad risiede nell’ottimizzazione predittiva della supply chain e non nella gestione del cambiamento. Il nostro approccio alla gestione del cambiamento è anche più convenzionale rispetto alle nostre pratiche di supply chain. Questo approccio, se implementato, limiterebbe la quantità di terze parti coinvolte nel progetto.

In alternativa, se l’azienda cliente preferisce mantenere i servizi di uno specialista della gestione del cambiamento per integrare Lokad, li supporteremo condividendo quanto l’azienda cliente reputi prudente.

6. Personalizzazione e Funzionalità del Sistema

6.1 Organizzate sessioni per prioritizzare i requisiti di personalizzazione, garantendo la comprensione degli impatti aziendali dovuti alle lacune del prodotto e raggiungendo un accordo reciproco sulla priorità per il rilascio delle personalizzazioni?

Sì. Gli Scienziati della Supply Chain di Lokad (SCSs) sono responsabili di questo processo. In effetti, Lokad si distingue su due fronti per quanto riguarda questa prioritizzazione. In primo luogo, un SCS è in grado di implementare indipendentemente la personalizzazione e, quindi, è in grado di fornire chiare visioni su ciò che è in gioco in termini di risorse e tempi.

Questo migliora notevolmente la qualità della prioritizzazione, poiché l’azienda cliente beneficia di un esperto che può bilanciare prontamente i benefici di qualsiasi cambiamento nella supply chain con i costi associati a questo cambiamento.

In secondo luogo, la ‘Supply Chain Quantitativa’ - la filosofia predominante di Lokad - enfatizza una prospettiva puramente finanziaria. Pertanto, l’SCS supporta l’azienda cliente nel fornire stime quantitative (in dollari o euro) dell’impatto di un potenziale cambiamento da apportare alla soluzione. Questa strategia affina l’iniziativa evitando il tradizionale collo di bottiglia del dibattito su cosa dovrebbe essere prioritizzato. Invece, Lokad semplifica questo processo prioritizzando le questioni che comportano il maggior impatto finanziario.

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

Sì. Gli Scienziati della Supply Chain di Lokad (SCSs) sono responsabili di questo processo. Mentre uno studio iniziale verrà condotto all’inizio dell’iniziativa, questo processo è in corso durante la fase di produzione. Fa parte del nostro approccio perseguire miglioramenti continui della soluzione.

Per quanto riguarda l’ottimizzazione della supply chain, le lacune sono raramente una questione di ‘funzionalità’, ma piuttosto una questione di ‘performance’. Ad esempio, la sfida non è solo generare quantità di rifornimento (funzionalità) ma garantire che le quantità generate siano le più redditizie (performance).

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

Su un altro fronte, la piattaforma di Lokad è programmabile. Pertanto, eventuali ’lacune di funzionalità’ percepite possono essere affrontate introducendo (o modificando) alcune righe di codice Envision. Questa programmabilità è precisamente ciò che consente a Lokad di fornire soluzioni su misura per ciascun cliente.

6.3 Puoi fornire un’agenda dettagliata per i workshop di analisi di adattamento delle lacune dei processi, inclusa le aspettative degli SME (Subject Matter Expert) dal lato del cliente, almeno una settimana prima dell’inizio dei workshop?

Sì. Gli Scienziati della Supply Chain di Lokad (SCSs) forniscono un’agenda per ogni workshop. Ci assicuriamo che l’agenda venga comunicata almeno una settimana prima dell’evento. Se vengono fornite istruzioni esplicite dall’azienda cliente, come una tempistica per fornire le agende, allora le seguiremo. In assenza di istruzioni, struttureremo i workshop (inclusa la tempistica e la comunicazione di tutti i passaggi necessari dal lato del cliente) in modo intelligente e professionale.

6.4 Ti assicuri che i documenti di requisiti di personalizzazione del prodotto siano congiuntamente esaminati e approvati dall’azienda cliente?

Sì, questi documenti saranno forniti - e successivamente approvati - dall’azienda cliente.

Si noti che le scelte di progettazione della piattaforma di Lokad eliminano in gran parte la necessità di ‘personalizzazione’ - almeno come questo termine è comunemente inteso nei circoli del software aziendale. La piattaforma di Lokad è programmabile, utilizzando Envision - il nostro DSL (linguaggio di programmazione specifico del dominio) dedicato all’ottimizzazione predittiva della supply chain.

Pertanto, le soluzioni di Lokad sono sempre ‘personalizzate’ nel senso che sono completamente adattate alle esigenze specifiche dell’azienda cliente. Tuttavia, tale personalizzazione viene fornita in modo da mantenere la soluzione parte della linea principale di prodotti di Lokad. Questo è l’approccio preferito (e deliberatamente progettato) di Lokad, e non presenta problemi di manutenzione.

6.5 Assisti l’azienda cliente nell’instaurare la connettività dell’interfaccia con i sistemi esterni, e nel testare e certificare le interfacce?

Sì. Gli Scienziati della Supply Chain di Lokad (SCSs) forniscono supporto per configurare, testare, convalidare e documentare le interfacce tra i sistemi gestiti dall’azienda cliente e Lokad. Gli SCS potrebbero essere supportati da risorse IT interne a Lokad per gli aspetti tecnici di basso livello, come reti o protocolli di sicurezza.

Le interfacce di sistema di solito non sono ‘certificate’ da un organismo 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 i dati richiesti a Lokad 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 dell’interfaccia durante i workshop. I messaggi di esempio possono essere inclusi se desiderato dall’azienda cliente.

Date le caratteristiche del servizio Lokad, però, i “messaggi di esempio” molto probabilmente assumeranno la forma di tabelle, poiché questo rappresenta più accuratamente l’output generato da Lokad per il cliente. Per riferimento, la maggior parte delle specifiche tecniche per le interfacce si concentrerà sulle tabelle e sui loro formati, nonché sui modelli di estrazione delle tabelle e sugli orari di trasferimento.

6.7 Condividete i processi di richiesta di modifica e di gestione dei rilasci?

Sì. Gli Scienziati della Supply Chain di Lokad (SCSs) sono responsabili di questo processo. È importante notare che Lokad ha due livelli di modifiche e rilasci, che differiscono dal software aziendale tipico.

In primo luogo, le modifiche apportate specificamente per i clienti sono implementate dagli SCS stessi. Queste modifiche avvengono frequentemente, spesso più volte al giorno, soprattutto durante la fase di integrazione. Tali modifiche sono in risposta diretta alle esigenze dell’azienda cliente e coinvolgono una comunicazione considerevole tra entrambe le parti.

In secondo luogo, apportiamo aggiornamenti alla piattaforma di Lokad, tipicamente attraverso aggiornamenti a Envision - il nostro DSL (linguaggio di programmazione specifico del dominio) dedicato all’ottimizzazione predittiva della supply chain. Questi cambiamenti sono progettati per essere trasparenti per le aziende clienti. Se desiderato, i dettagli su questi aggiornamenti possono essere forniti, e molte di queste informazioni sono rese pubblicamente disponibili.

Vedi Envision VM Ambiente e Architettura Generale per ulteriori informazioni sull’evoluzione della piattaforma di Lokad.

7. Test di Accettazione Utente (UAT)

7.1 Assisti l’azienda cliente nell’allestire l’ambiente di test UAT (User Acceptance Testing) con dati specifici del contesto e configurazioni di sistema?

Sì. Gli Scienziati della Supply Chain di Lokad (SCSs) sono responsabili di questo processo. Lokad offre innovazioni metodologiche e tecniche uniche a supporto di questo.

Dal punto di vista metodologico, favoriamo la progettazione di elenchi prioritari, dove gli elementi sono classificati in base al ritorno sugli investimenti (ROI) decrescente per l’azienda. Questo aspetto è fondamentale per garantire che il tempo degli utenti finali non venga sprecato nella revisione di grandi quantità di dati in gran parte irrilevanti.

Dal punto di vista tecnologico, la piattaforma di Lokad è stata appositamente progettata per supportare contemporaneamente più ambienti per qualsiasi iniziativa. Questi ambienti sono una caratteristica nativa della nostra piattaforma SaaS multi-tenant, e quindi possono essere introdotti con un overhead minimo, sia in termini di risorse di calcolo che di tempo di amministrazione di sistema.

Vedi anche User Acceptance Testing 7.3.

7.2 Configuri l’ambiente di test UAT (User Acceptance Testing) pre-produzione, produzione e di formazione secondo i processi ToBe definiti?

Sì. Data la ricca programmabilità della piattaforma di Lokad, possiamo esercitare un controllo completo sulle configurazioni. Questo è reso possibile attraverso Envision - il nostro DSL (linguaggio di programmazione specifico del dominio) dedicato all’ottimizzazione predittiva delle supply chain.

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

Inoltre, avanzare da una fase all’altra è semplice con il nostro design. Utilizzare una base di codice per le modifiche alla configurazione è più efficiente rispetto ai metodi tradizionali basati sull’interfaccia utente.

7.3 Fornite ambienti separati di test UAT (User Acceptance Testing), migrazione dei dati, fase di produzione (pre-prod), produzione e di formazione per il prodotto (inclusi gli interfacce richieste) alla società cliente e ai sistemi esterni?

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

Con Lokad, duplicare l’intero ambiente di produzione, compresi tutti i dati di produzione, avviene senza raddoppiare l’occupazione dello spazio di archiviazione dei dati. Internamente, i dati identici tra i due ambienti sono mutualizzati. Inoltre, il nostro design a tempo costante garantisce che il carico di lavoro da un ambiente non influenzi negativamente le prestazioni di un altro ambiente.

Tuttavia, la maggior parte dei fornitori di software aziendale evita completamente il problema semplicemente ‘clonando’ l’impostazione principale. Clonare - o duplicare direttamente - è facile ma sprecone. Clonare significa che la quantità di risorse (persone e macchine) aumenta linearmente con il numero di ambienti - ad esempio, tre ambienti triplicano i costi originali. Per qualsiasi supply chain di dimensioni considerevoli, ciò si traduce in costi considerevoli.

7.4 Garantite la risoluzione tempestiva di tutti i difetti per assicurare che il test UAT (User Acceptance Testing) sia completato entro i tempi concordati?

Sì, a condizione che si possano concordare definizioni sfumate di ‘risoluzione’ e ‘difetto’. Nel complesso, gli Scienziati della Supply Chain (SCSs) di Lokad sono responsabili della risoluzione di tutti i problemi che minano l’obiettivo principale dell’iniziativa: aumentare il ritorno sugli investimenti. In uno scenario tipico, gli SCS propongono un’azione appropriata e una relativa tempistica, che la società cliente convalida o aggiorna a loro discrezione.

È fondamentale sottolineare che quando si tratta di supply chain, non ci sono soluzioni perfette, solo tradeoff migliori e peggiori. In altre parole, non si può davvero risolvere un problema in cui due o più valori sono in completa opposizione.

Ad esempio, l’inventario deperibile scaduto è spregevole, ma quando si gestiscono prodotti deperibili, tale spreco non può essere eliminato completamente senza creare un conseguente problema di qualità del servizio. Bisogna trovare un equilibrio tra il magazzino morto e le scorte esaurite. Tuttavia, sia il ‘magazzino morto’ che le ‘scorte esaurite’ sono difetti in un certo senso.

In breve, gli SCS possono risolvere problemi ‘banali’ man mano che sorgono, come correggere un errore di analisi durante la lettura di un file (un bug software). Tuttavia, l’obiettivo principale di una soluzione quantitativa della supply chain non è “risolvere i problemi” ma aumentare il ritorno sugli investimenti (in dollari o euro). Lokad raggiunge questo tipo di “risoluzione” attraverso un approccio intelligente e finanziariamente orientato ai tradeoff della supply chain.

7.5 Assisterete la società cliente nella revisione degli scenari di test, dei casi di test e dei dati di test del test UAT (User Acceptance Testing)?

Sì. Gli Scienziati della Supply Chain (SCSs) di Lokad sono responsabili di questo processo.

Tuttavia, per quanto riguarda l’ottimizzazione della supply chain, i set di dati più piccoli rispetto all’intera configurazione di produzione non sono generalmente sufficienti. In pratica, gli scenari, i casi di test e i dati di test devono essere (quasi) grandi quanto la configurazione di produzione per riflettere una prospettiva end-to-end della supply chain. Questo requisito non ha nulla a che fare con Lokad; è semplicemente la natura della supply chain.

7.6 Garantite il supporto in loco presso la sede della società cliente durante la fase di test UAT (User Acceptance Testing)?

Sì. Il supporto in loco è regolato dall’accordo contrattuale tra Lokad e la società cliente. Questo aspetto viene sempre negoziato caso per caso.

Va notato che un’iniziativa quantitativa della supply chain con Lokad prevede un miglioramento continuo della supply chain, quindi non c’è un periodo UAT fisso. Di solito i test iniziano alla fine del secondo mese, raggiungono il picco entro il quarto mese, per poi stabilizzarsi a partire 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 abbia un’iniziativa aggiornata.

Vedi anche Implementazione e Gestione del Progetto 1.7.

8. Supporto Post-Implementazione e Audit

8.1 Potete garantire che le osservazioni dalle esecuzioni pilota siano documentate e che eventuali azioni siano assegnate agli interessati nei dipartimenti Tecnico, IT e Fornitori della società cliente, e che siano anche monitorate fino alla chiusura?

Sì. Gli Scienziati della Supply Chain (SCSs) di Lokad creano e mantengono un Manuale di Procedura Condiviso (JPM) per ciascuna iniziativa. Include tutte le informazioni pertinenti per l’iniziativa. È importante notare che il JPM è progettato per essere accessibile a un pubblico non tecnico (anche se alcune sezioni e allegati sono piuttosto tecnici).

Le azioni di alto livello sono documentate nel JPM. Tuttavia, le azioni minori sono tipicamente gestite con il gestore delle attività sulla piattaforma di Lokad. Queste azioni minori sono di breve durata e il gestore delle attività facilita il monitoraggio e la chiusura meglio del JPM.

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

Sì. Gli Scienziati della Supply Chain (SCSs) di Lokad implementano tipicamente strumenti dedicati a questo scopo durante l’ultima fase di integrazione, poco prima dell’avvio ufficiale.

Inoltre, Lokad può tracciare l’allineamento tra le decisioni della supply chain che genera e le decisioni effettive prese nella supply chain. Questo viene fatto per identificare potenziali fonti di divergenza, come bug o problemi nei sistemi del cliente, che potrebbero influenzare l’attuazione delle raccomandazioni di Lokad.

8.3 Condurrete un audit annuale dell’applicazione e fornirete feedback per migliorare l’utilizzo e l’adozione del sistema da parte degli utenti finali, al fine di ottenere un ROI (ritorno sugli investimenti) più veloce?

Sì, un audit annuale dell’intera soluzione (end-to-end) è una prassi operativa standard. Detto ciò, gli Scienziati della Supply Chain (SCSs) di Lokad auditano tipicamente l’intera soluzione più 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 ciascuna iniziativa.

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

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

Sì. Il team di Scienziati della Supply Chain (SCSs) di Lokad si occupa di questo compito. I nostri SCSs sono ampiamente formati sia per migliorare continuamente l’iniziativa che per fornire supporto continuo al cliente. La presenza continua in loco degli SCSs sarà negoziata e chiarita nell’accordo contrattuale con il cliente, se questo è qualcosa che il cliente desidera perseguire.

Su una nota correlata, Lokad raccomanda vivamente di mantenere un impegno attivo e continuo per il miglioramento della soluzione, in particolare dal lato del cliente. Ridurre gradualmente gli sforzi di miglioramento continuo, nella nostra esperienza, indebolirà la forza dell’iniziativa. Qualsiasi cambiamento dal lato del cliente, inclusi modesti aggiustamenti nel panorama applicativo o nei vincoli, può influenzare la qualità delle decisioni generate da Lokad, pertanto si consiglia vigilanza attiva e miglioramento continuo.

Vedi anche Implementazione e Gestione del Progetto 1.7.

9. Gestione degli Incidenti e dei Difetti

9.1 Potete garantire che tutti i difetti e le richieste di modifica indispensabili (elementi critici e ad alta priorità) siano affrontati come priorità e consegnati, al fine di evitare ritardi nei tempi di go-live dell’azienda cliente?

Sì. Gli Scienziati della Supply Chain (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 modo rapido e autonomo.

La piattaforma di Lokad è programmabile, il che è reso possibile attraverso Envision - il nostro DSL (linguaggio di programmazione specifico del dominio) dedicato all’ottimizzazione predittiva delle supply chain. Questa programmabilità significa che gli SCSs possono consegnare prontamente correzioni e implementare le modifiche richieste all’iniziativa, e a un livello di precisione non comune nel software enterprise.

Oltre alla tecnologia, gli SCSs di Lokad sono formati per svolgere una serie di 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 correzioni e aggiornamenti mantenendo sempre presenti le priorità principali del cliente.

Vedi anche Personalizzazione e Funzionalità di Sistema 6.2.

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

Sì, la piattaforma Lokad è dotata del proprio sistema di gestione dei compiti / ticket / problemi. Queste capacità ci consentono di seguire con precisione la risoluzione tempestiva dei problemi. Queste risoluzioni sono gestite dai team di Scienziati della Supply Chain (SCSs) impiegati da Lokad.

Tuttavia, è importante non confondere “difetti” e “problemi di usabilità”. Ad esempio, una previsione di domanda inaccurata è un “difetto”. Sta influenzando negativamente la supply chain. Tuttavia, a seconda delle condizioni di mercato in cui opera l’azienda cliente, questo “difetto” potrebbe non essere mai risolto, ma solo mitigato. Quando si tratta di ottimizzare in modo predittivo le supply chain, le soluzioni sono sempre un compromesso, risolvendo un difetto, creandone un altro (sperabilmente più piccolo).

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

9.3 Potete garantire che i difetti riscontrati durante i test delle release (prima della produzione) saranno affrontati e risolti tempestivamente, in modo da non influenzare la tempistica dell’azienda cliente per il lancio della release?

Sì. Se i difetti identificati riguardano il codice specifico del cliente (scritto in Envision), allora i difetti saranno corretti dagli Scienziati della Supply Chain (SCSs) di Lokad. Se i difetti identificati riguardano la piattaforma di Lokad, allora i difetti saranno corretti dai team di ingegneria del software di Lokad.

In entrambi i casi, il processo di rilascio di Lokad prevede test approfonditi per garantire che i difetti siano identificati e risolti prima del rilascio (go-live).

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

Gli Scienziati della Supply Chain (SCSs) trattano tutti i report di incidenti - indipendentemente dalla fonte - con massima serietà. L’accordo contrattuale tra Lokad e l’azienda cliente specifica quanti SCSs saranno assegnati al progetto, nonché le ore settimanali di supporto diretto che il cliente può aspettarsi siano disponibili.

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

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

Infine, una volta affrontato il problema, lo SCS valuterà la vera causa del problema segnalato, anche se alla fine il report è stato diagnosticato come non un problema. Di solito, c’è un problema sottostante da qualche parte che deve essere affrontato. Affrontando la causa radice più profonda, Lokad elimina proattivamente problemi simili in futuro.

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

Sì. È prassi standard creare una voce corrispondente all’interno della piattaforma Lokad quando riceviamo un report attraverso un canale diverso dal gestore dei compiti/ticket/problemi. Questa prassi facilita un tracciamento e una conformità accurati.