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 delle scorte. Questa pagina affronta domande e preoccupazioni sul cambiamento che questa iniziativa comporta e su come gestirlo in modo efficace. Gli esperti di Lokad rimangono sempre disponibili per aiutare i clienti a navigare nel processo.

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

Panoramica della Gestione del Cambiamento

La Supply Chain Quantitativa (QSC), come introdotta e promossa da Lokad, si discosta significativamente dalla prospettiva tradizionale. Le differenze sono sia essenziali che le ragioni principali per cui Lokad può offrire miglioramenti così drastici nella supply chain. Detto questo, 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 superflui, anziché semplicemente sostituire sprechi con sprechi diversi. 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 normalmente sarebbero svolti da più persone in iniziative simili con altri fornitori di software. Un Supply Chain Scientist funge da integratore di sistema, ingegnere dei dati, analista aziendale, scienziato dei dati, esperto di supply chain e project manager (tra gli altri ruoli). Gli scienziati della supply chain (SCS) forniscono tutto il coaching, la formazione, l’orientamento e il supporto necessari affinché i clienti adottino l’approccio quantitativo di Lokad alla supply chain.

Il corretto utilizzo di Lokad (in produzione) produce tipicamente due risultati notevoli: risparmi consistenti attraverso decisioni migliori sulla supply chain e risparmi di produttività consistenti attraverso decisioni sulla supply chain (in gran parte) automatizzate.

Per quanto riguarda la gestione del cambiamento, i risparmi sulla supply chain sono di solito irrilevanti. L’azienda potrebbe decidere alla fine di reinvestire il capitale di lavoro liberato altrove, ma questo tipo di decisione normalmente va oltre lo scopo dell’iniziativa Lokad. Tuttavia, i notevoli risparmi di produttività generati da Lokad vengono di solito 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 all’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 stock, ecc.

Una volta che Lokad è in produzione, la maggior parte delle attività sono rivolte all’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 scarsa affidabilità, ecc.

Queste informazioni vengono quindi continuamente incorporate nella soluzione di Lokad attraverso il supporto continuo degli SCS.

Per i dirigenti della supply chain, il cambiamento più grande è l’eliminazione (in larga misura) dei continui interventi d’emergenza. La soluzione di Lokad fornisce decisioni automatizzate progettate per affrontare casi limite fastidiosi, riducendo così notevolmente 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 in modo dettagliato le conseguenze continue di 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 di formazione per supportare l’adozione delle pratiche e dei processi consigliati da Lokad all’interno dell’azienda cliente.

Oltre a ciò, questi esperti si impegnano a garantire il successo a lungo termine dell’iniziativa oltre all’implementazione iniziale, fornendo supporto continuo durante la transizione dell’iniziativa alla fase di “miglioramento continuo”.

Per ulteriori informazioni sul ruolo degli SCS nel processo di ottimizzazione, consulta le lezioni di Lokad su the Supply Chain Scientist e A day in the life of a Supply Chain Scientist.

1.2 Qual è la tempistica di implementazione e quali sono le fasi incluse in questa tempistica? Quali sono gli obiettivi di ogni 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 è quello di 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’obiettivo effettivo: migliorare le prestazioni della supply chain. L’obiettivo della fase di “produzione” è quello di continuare a perfezionare, migliorare e allineare continuamente le ricette numeriche, quelle che consentono l’automazione in primo luogo.

Suddivisione della tempistica

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

• La prima sottofase è la configurazione del data pipeline. L’obiettivo è creare una pipeline di dati completamente automatizzata per l’estrazione dei dati del cliente verso Lokad. Gli aspetti più impegnativi della pipeline di dati sono stabilire la “semantica” dei dati e rendere il processo di pipelining stesso (quasi) perfettamente affidabile. Una pipeline di dati, a differenza di una singola estrazione di dati, è fondamentale per mantenere le raccomandazioni della supply chain generate da Lokad rilevanti per le attuali esigenze aziendali del cliente.

• La seconda sottofase è la progettazione delle ricette numeriche uniche del cliente, i pezzi di logica 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, di solito dura non 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 sottofase è la dual run. La ricetta numerica non produce più assurdità e i driver economici che guidano l’ottimizzazione sono stati concordati. Tuttavia, la ricetta non è ancora pronta per la produzione. Per procedere, viene avviata una dual run. La ricetta numerica viene eseguita parallelamente al processo legacy. Poiché la ricetta è automatizzata, l’onere organizzativo è basso. Ogni giorno, gli operatori della supply chain possono confrontare le decisioni e vedere come si sviluppano i modelli (ad esempio, la stagionalità). Attraverso diverse settimane di dual run, si acquisisce fiducia per procedere con il rollout di produzione.

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

Vedi panoramica della timeline per una suddivisione più dettagliata di ogni passaggio coinvolto nel processo di ottimizzazione.

1.3 Lokad documenta e pubblica un piano di project management che dettaglia l’ambito del progetto, la pianificazione/tempistica, le milestone critiche, 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 questi elementi e altri ancora sono raccolti in un unico Manuale di Procedura Congiunta (JPM) per l’iniziativa. Gli Scienziati della Supply Chain (SCS) 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 sono destinati ad essere 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 durante l’iniziativa stessa.

Lokad ritiene che molte (se non la maggior parte) delle iniziative aziendali siano ostacolate dalla produzione di documenti inutili, che sono, nella pratica, 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 privilegiare la quantità rispetto alla qualità quando si tratta della documentazione del progetto.

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

Vedi la lezione Scrittura per la Supply Chain per ulteriori informazioni sull’etica della documentazione di Lokad.

1.4 Lokad è responsabile di mantenere e basare il piano di project management, previa approvazione del comitato di steering del progetto? Se si verificano deviazioni dal piano, le comunicherete chiaramente insieme alle opzioni di mitigazione?

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

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

Per un’iniziativa particolarmente complessa, Lokad istituisce un comitato di steering dedicato composto da membri chiave sia di Lokad che dell’azienda cliente. Sebbene questa riunione serva come meccanismo per ottenere l’approvazione formale, la maggior parte del lavoro sostanziale avviene al di fuori del comitato stesso. Gli SCS si impegnano tipicamente in interazioni quotidiane con vari team lato cliente. Questi team vengono aggiornati continuamente su eventuali deviazioni dal piano e si assicurano che l’intera iniziativa rimanga in linea. Queste interazioni quotidiane sono un modo molto più efficace per discutere e superare i problemi tecnici man mano che si presentano, piuttosto che cercare di investigare grandi lotti di problemi durante una sessione del comitato di steering. Pertanto, il comitato di steering, come 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à che sono 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 si presentano, aumentando significativamente l’impatto e l’agilità dell’iniziativa.

1.5 Documenterete il piano di comunicazione, che include riunioni giornaliere, rapporti di stato settimanali del gruppo di lavoro e sessioni di revisione, nonché rapporti e sessioni di revisione mensili del comitato di steering? 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 (SCS) sono responsabili di queste mansioni. I dettagli della gestione della comunicazione all’interno dell’azienda cliente dipendono tipicamente dai termini contrattuali dell’iniziativa stessa.

Lokad partecipa volentieri alle riunioni giornaliere quando è in loco presso la sede dell’azienda cliente. Di solito, tuttavia, i nostri SCS 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 steering (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 portata all’attenzione di un SCS Junior. Questo si è dimostrato sufficiente storicamente, con pochissime situazioni che richiedono ulteriori 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 non si comprendono e si affrontano le cause di fondo. Ciò impedisce a un problema minore di diventare ricorrente. Pertanto, Lokad preferisce mettere persone altamente capaci in prima linea in grado di affrontare sia il problema immediato che di identificare le cause di fondo sottostanti. Questo approccio è preferibile rispetto alla dipendenza da personale di supporto non addestrato che affronta continuamente gli stessi problemi - un modello troppo spesso adottato da molti fornitori di software aziendali.

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 tutte le parti interessate come parte della fase di avvio del progetto?

Sì. Più in generale, gli Scienziati della Supply Chain di Lokad (SCS) seguono il processo che è stato negoziato e concordato con ciascun cliente - secondo i termini contrattuali formali. Questo principio rimane applicabile durante l’intera iniziativa, dall’inizio alla conclusione. L’avvio del progetto è certamente importante, anche se 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 che si comporta 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 moderne supply chain - presenti anche in aziende che sembrano avere supply chain ad alte prestazioni.

1.7 Verrà assegnato un project manager dedicato di 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. Sebbene Lokad non sia 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 è considerata da tutte le parti come più efficiente rispetto al collocamento dei dipendenti di Lokad presso l’ufficio 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 soggetti coinvolti, poiché gli Scienziati della Supply Chain di Lokad (SCS) 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 esistenti, indipendentemente dall’esperienza o dall’anzianità. Mentre osserviamo che molti fornitori aziendali permettono ai loro dipendenti di operare per mesi, se non anni, presso siti remoti 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 diversità e ampiezza di competenze. Ogni SCS è addestrato per agire in una varietà di ruoli, come: esperto di materia, analista aziendale, esperto di interfaccia tecnica, data scientist e consulente di supply chain. Queste funzioni normalmente sarebbero svolte da più dipendenti e comporterebbero un aumento significativo dei costi per il cliente. Presso Lokad, ogni SCS fornisce tutti questi servizi.

Di conseguenza, gli SCS tendono ad essere molto 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 in modo critico dalla coerenza end-to-end, cosa che è 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 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 (SCS) di Lokad e l’azienda cliente. Il coordinatore inizialmente trasmetterà le richieste di informazioni e successivamente trasmetterà le richieste di feedback. Parallelamente, gli SCS di Lokad lavorano con le formule numeriche volte 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 se necessario, 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 della 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 sia vincolata da un fornitore, questa configurazione tecnica richiede meno di 4 settimane di lavoro per un singolo contributore, e talvolta 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 i vincoli della supply chain. Un’ulteriore serie di interviste, facilitate dai coordinatori, avrà luogo per supportare questo processo. Successivamente, una volta che gli SCS avranno sviluppato le formule numeriche, si svolgerà un’altra serie di interviste per rivedere i dati generati da tali formule e consentire agli SCS di perfezionarli e migliorarli.

Il contributo del supervisore è importante sia per allineare Lokad con la strategia di alto livello pursueda dall’azienda, sia per evitare che l’iniziativa si blocchi a causa di indecisioni. 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 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 ha diverse lezioni dedicate all’esecuzione tattica e strategica di un’ottimizzazione di supply chain di successo.

2. Gestione delle risorse e 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? È possibile definire precisamente il numero di risorse per ogni fase e sottofase del progetto?

Una tipica iniziativa di Lokad richiede circa 0,5-2 FTE (equivalenti a tempo pieno) di risorse aziendali 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 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 ogni fase di una 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 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 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 da parte del 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 informazioni di 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 sia a suo agio con il lavoro analitico. Tuttavia, questa posizione non richiede competenze IT specializzate o specifiche competenze di data science. 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 suo tempo preparando il rollout adeguato e comunicando con tutti i professionisti della supply chain interessati. Allo stesso modo, il dirigente della supply chain supervisiona la gestione del cambiamento interno legato 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 consiglia di mantenere la stessa quantità 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 è notevole. È un errore affrontare la risoluzione di tali sfide con una mentalità di impostazione e dimenticazione, poiché qualsiasi soluzione tecnica inevitabilmente - e continuamente - tenderà a diventare irrilevante e obsoleta se non monitorata e mantenuta correttamente.

Vale la pena notare che, dato che Lokad automatizza le decisioni sulla supply chain, non c’è una stretta urgenza 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 è raro che la completa revisione dell’organizzazione 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 aziendali per il lancio.

2.3 Puoi garantire che siano disponibili presso la sede dell’azienda cliente risorse sufficienti in termini di manodopera e conoscenza 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 dei primi obiettivi dello Supply Chain Scientist è acquisire tutte le informazioni necessarie sulla supply chain del cliente. Questo processo viene tipicamente svolto attraverso interviste con le parti interessate pertinenti, compresi i proprietari del prodotto aziendale. Cerchiamo anche di esaminare attentamente i documenti esistenti (quando disponibili), al fine di sfruttare al massimo tali interviste.

Tuttavia, la preoccupazione principale di Lokad è capire il “problema” in esame, cosa che non sempre viene facilitata dall’elenco dei “requisiti”. Ad esempio, se un cliente menziona che richiede una gestione speciale dei “slow movers”, comprendiamo che il basso volume è una preoccupazione da affrontare. Tuttavia, la gestione speciale di tali SKU è solo una delle molte opzioni che abbiamo a disposizione per affrontare questa preoccupazione.

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

Pertanto, sebbene Lokad raccolga e documenti tutti i requisiti del cliente, il nostro approccio enfatizza la scoperta della vera natura del problema, piuttosto che accettare senza riserve 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 per l’impegno, i costi e i tempi per le funzionalità che richiedono personalizzazioni, 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 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 dell’azienda cliente.

A differenza della maggior parte dei software aziendali, la programmabilità è una caratteristica fondamentale per Lokad. Gli script Envision sopra menzionati non sono una “personalizzazione” della soluzione Lokad nel senso usuale. La presenza di tali script non rappresenta neanche 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 associato 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 Case Study sul Disastro SAP da €500 Milioni di Lidl per ulteriori informazioni su questo punto.

2.6 Implementerete e manterrete una strategia di conservazione 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 di Lokad?

Sì. Tratteniamo i dipendenti in media per 3,5 anni, che è quasi il doppio della durata dell’impiego rispetto a coorti simili (ingegneri talentuosi nell’IT o in settori 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 margine di miglioramento, ciò mette 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 Scientist (SCSs) di un anno all’altro.

Questa trattenuta è 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 considerati 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 atto. In primo luogo, ogni iniziativa di Lokad viene fornita con un Manuale di Procedura Condiviso (JPM). Il JPM è il documento principale utilizzato da un nuovo SCS per familiarizzare rapidamente con tutte le informazioni e le tecniche rilevanti dell’iniziativa. In secondo luogo, ogni iniziativa ha - in ogni momento - sia un SCS primario che un SCS 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 mano l’iniziativa nel caso in cui ce ne sia mai bisogno. Questa pratica mitiga in gran parte le complicazioni legate a congedi/turnover imprevisti.

3. Ruoli, Responsabilità e Gestione degli Stakeholder

3.1 Quale livello di cooperazione hai 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 legate alla supply chain non sono altrettanto importanti per tutte le aziende, quindi la collaborazione tende ad essere più forte per le aziende in cui la supply chain è la colonna portante (riconosciuta) delle loro attività.

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

La collaborazione continua con Lokad consente ai nostri clienti di ristrutturare 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 intenzione di sostituire l’importante competenza strategica che esiste nell’azienda cliente. Piuttosto, Lokad desidera automatizzare gli aspetti più banali e ripetitivi dei processi decisionali della supply chain. Questo approccio libera successivamente risorse significative - e spesso scarse - dell’azienda cliente che possono essere ridirezionate verso utilizzi migliori.

3.2 Quali ruoli e responsabilità ti aspetti che 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 di supply chain di Lokad.

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

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

• L’Ufficiale dei Dati: I dati sono il fondamento dell’iniziativa quantitativa della supply chain e questa persona ne garantisce l’accessibilità e l’affidabilità. Incaricata di estrarre set di dati completi (come la cronologia delle vendite e degli acquisti), è responsabile dell’automazione e della pianificazione dell’estrazione dei dati. Sebbene il suo ruolo sia più intensivo all’inizio dell’iniziativa, il suo contributo è cruciale per il suo successo.

• Lo Scienziato della Supply Chain: Questo ruolo unisce le intuizioni del Coordinatore della Supply Chain ai dati dell’Ufficiale 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à dei dati. Successivamente formalizza le strategie in decisioni operative, come le quantità di riordino, e implementa dashboard e KPI per la trasparenza e il controllo.

Vedi ruoli del progetto per ulteriori informazioni sulle diverse designazioni all’interno di un’iniziativa quantitativa della 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 esplicitamente presentate come una tabella RACI se l’azienda cliente lo ritiene importante.

Ancora più importante, gli Scienziati della Supply Chain (SCSs) di Lokad interiorizzano questo tipo di matrice al fine di prendere decisioni adeguate e rapide durante lo sviluppo dell’iniziativa. Per quanto riguarda le questioni legate all’ottimizzazione di una supply chain, la questione cruciale è capire il modo migliore per formulare il problema. Successivamente, l’attenzione si sposta sull’individuazione di chi nell’organizzazione è il più adatto per affrontare il problema. È fondamentale che tutta questa analisi venga effettuata rapidamente per preservare il momentum dell’iniziativa.

A tal fine, gli SCS di Lokad sono designati per guidare l’iniziativa e assumersi la responsabilità della 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 delle responsabilità tra un grande gruppo di stakeholder. La posizione di Lokad è che tali sistemi tendono a diluire la responsabilità, anziché renderla più rigida. I nostri SCS sono quindi formati per adottare e operare con questa responsabilità, e ciò include garantire che gli stakeholder pertinenti dell’azienda cliente vengano consultati e informati in modo completo sull’iniziativa.

3.4 Documenterai i ruoli e le responsabilità utilizzando una matrice RACI (Responsibility, Accountability, Consulted, and Informed) per tutte le parti coinvolte nel progetto? Ti assicurerai che questo documento venga discusso e concordato da tutte le parti coinvolte?

Sì. Tutti questi elementi (e altri ancora) vengono raccolti e documentati nel Manuale di Procedura Condiviso (JPM). Il JPM è prodotto dagli SCS di Lokad (con informazioni raccolte direttamente dall’azienda cliente). In questo documento vengono dettagliati i parametri del ruolo e delle responsabilità di ciascuna persona.

Il JPM serve anche come risorsa continua per l’iniziativa ed è redatto dagli SCS assegnati all’azienda cliente. La produzione di questo documento con le loro parole dimostra che gli SCS hanno dedicato molto tempo 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 vengono condivise con l’azienda cliente. Il JPM stesso viene regolarmente discusso durante le sessioni di lavoro tra Lokad e l’azienda cliente.

A proposito, la nostra esperienza indica che in caso di disaccordi, di solito riflettono un problema organizzativo da risolvere all’interno dell’azienda cliente. Ecco perché consigliamo all’azienda cliente di nominare un Responsabile della Supply Chain per supervisionare l’iniziativa. Uno dei loro contributi principali è agire come intermediario quando si verificano tali casi.

3.5 Ti assicurerai che il gruppo di lavoro del progetto e i gruppi di coordinamento siano formati da 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 e concordato formalmente con l’azienda cliente. Gli elementi concordati (e eventuali modifiche apportate durante l’iniziativa) vengono documentati nel Manuale di Procedura Condiviso (JPM), che include dettagli relativi al gruppo di lavoro del progetto e ai gruppi di coordinamento. Attraverso gli SCS di Lokad, disponiamo delle risorse necessarie per installare e monitorare questi processi.

Aneddoticamente, uno dei contributi più apprezzati di Lokad è la nostra capacità di semplificare i processi, sia che si tratti di supply chain che di burocrazia. Nel tempo, lavoriamo attivamente per rimuovere strati burocratici superflui 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 quando Lokad è “in produzione”, ovvero le nostre raccomandazioni automatizzate sulla supply chain guidano efficacemente il processo decisionale desiderato del cliente.

Questa durata può essere ridotta di 1 mese se è già presente un data lake - un data lake ben strutturato e documentato può abbreviare ulteriormente la fase di onboarding. Al contrario, questa fase viene di solito aumentata di 1 a 3 mesi quando il software o l’ambiente di sistema del cliente sono eccessivamente complessi o obsoleti.

Curiosamente, 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 a rischio l’iniziativa di stallo. Pertanto, progettiamo attivamente lo scope per mitigare questo rischio.

Tali ritardi hanno poco a che fare con l’installazione tecnica di Lokad stessa. Nel complesso, la linea temporale suggerita serve non solo a scopi tecnici (automazione dell’estrazione dei dati, test delle formule numeriche, ecc.), ma consente anche agli Scienziati della Supply Chain di Lokad (SCSs) di diventare pienamente competenti in tutte le specificità dell’azienda cliente e alle squadre della supply chain di “digestire” l’approccio di Lokad, il che rappresenta tipicamente una deviazione dal processo ereditato del cliente.

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

Il numero di visite e workshop effettuati in loco viene negoziato come parte dei termini contrattuali specifici con l’azienda cliente, anche se va notato che i costi di viaggio possono influire sulle tariffe addebitate da Lokad. Pertanto, l’inclusione di visite in loco è in definitiva una decisione da prendere da parte dell’azienda cliente e Lokad si adeguerà alla frequenza desiderata.

Quando l’obiettivo dell’azienda cliente è quello di mantenere l’iniziativa il più snella possibile, siamo a nostro agio con un’iniziativa completamente remota, ovvero senza visite in loco. Raccomandiamo questo approccio per le piccole aziende (fatturato annuo inferiore a 100 milioni di dollari) e per le aziende che sono generalmente a loro agio con i collaboratori remoti (come le grandi aziende di e-commerce). Circa la metà delle iniziative portate avanti da Lokad appartiene 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 dollari), raccomandiamo almeno una visita/workshop trimestrale in loco. Questo approccio aiuta a sviluppare un allineamento a livello aziendale, specialmente quando sono coinvolte squadre di grandi dimensioni.

Per i nostri clienti in Europa occidentale, tendiamo ad avere più visite (di solito della durata di un solo giorno) rispetto ai 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) rispetto alle visite quando siamo in loco. Questa differenza è una semplice questione di costi di viaggio e logistica associati.

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

Per un’iniziativa quantitativa sulla supply chain, la maggior parte delle riunioni dovrebbe essere remota. La maggior parte delle riunioni è breve (30 minuti o meno) e coinvolge solo due partecipanti: uno Scienziato della Supply Chain di Lokad e un praticante della supply chain dell’azienda cliente. Inoltre, le riunioni remote sono vantaggiose per compiti tecnici specifici, poiché tutti i partecipanti hanno accesso alla propria configurazione informatica, compreso l’accesso a grandi monitor. 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 facilitano spesso 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 le riunioni in loco (ad esempio, settimanali/mensili/trimestrali…). Lokad considera tali riunioni in loco come eventi significativi, soprattutto quando Lokad ospita il cliente.

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

4.4 Assisterete l’azienda cliente nella conduzione di un controllo di qualità dell’ambiente di produzione per valutare la prontezza per il go-live, compresa la configurazione delle interfacce?

Sì. In effetti, Lokad va oltre l’assistenza semplice all’azienda cliente nella valutazione della sua prontezza per il go-live. Una delle principali responsabilità degli Scienziati della Supply Chain di Lokad (SCSs) è prendere in carico la soluzione end-to-end consegnata all’azienda cliente. In altre parole, sebbene un sistema meccanizzato (una flotta di macchine) generi i risultati, è comunque una persona che si assume la responsabilità personale del sistema. Garantiscono l’accuratezza, la pertinenza e l’adeguatezza del flusso di elaborazione dei dati end-to-end, tenendo conto anche delle preoccupazioni generali dell’azienda cliente.

Date le loro caratteristiche soggette ad errori, le interfacce software meritano una particolare attenzione 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 sulla supply chain all’azienda cliente). Per questa attività, Lokad sfrutta metodologie e tecnologie specifiche.

Si prega di consultare i 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 di strategia di transizione e migrazione di 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 (SCSs), garantisce che sia i professionisti della supply chain che i dirigenti della supply chain abbiano accesso a materiali ben scritti che spieghino adeguatamente il processo in termini comprensibili. Gli SCSs 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 doppio 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 al processo decisionale legacy su tutto il campo d’azione dell’iniziativa. La pratica è resa possibile solo 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 modo soddisfacente in condizioni di produzione esatte, su tutto il campo d’azione, 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 sulla supply chain, gli oneri associati a una doppia esecuzione sono significativi. Di conseguenza, la doppia esecuzione viene effettuata al massimo su un campo d’azione limitato che non riflette realmente le condizioni di produzione. Di conseguenza, quando viene adottato un tale approccio, l’estensione tardiva del campo d’azione porta inevitabilmente a incidenti di produzione che sarebbero stati completamente evitabili con una doppia esecuzione a campo d’azione completo.

4.6 Fornite lo scopo, i tempi e i criteri di successo per il pilot run da revisionare e approvare da parte dell’azienda cliente?

Sì. Lo scopo è sempre dettagliato nell’accordo contrattuale tra Lokad e l’azienda cliente. Di solito assume la forma di un determinato tipo di decisione sulla supply chain (ad esempio, riassortimento delle scorte o allocazione delle scorte) su un insieme di sedi e/o su un insieme di sistemi aziendali.

Il periodo di tempo è 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 di Lokad dipende dall’esecuzione tempestiva di determinati passaggi da parte dell’azienda cliente, in particolare dalla costruzione di un flusso di dati 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 supportare questa decisione, una decisione non unilaterale sarebbe insolita. In poche parole, un fornitore non dovrebbe essere in grado di decidere che il pilot è stato un successo se il cliente la pensa diversamente.

Vedi anche Implementazione e Gestione del Progetto 1.2.

Consulta Valutare il Successo di un’Iniziativa Quantitativa sulla Supply Chain per ulteriori informazioni 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ì. Come regola generale, trattiamo un pilot - inteso a fornire ottimizzazione della supply chain - esattamente come tratteremmo un’iniziativa “reale” intesa a essere portata in produzione. Per 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 di Supply Chain Scientists (SCSs) di Lokad è responsabile di tutto quanto sopra. Sulla base della 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 tenere traccia di ciò che viene acquistato, prodotto, immagazzinato e venduto, l’iniziativa ha quasi certamente dati adeguati. La sfida consiste nel dare un senso ai dati che non sono stati originariamente raccolti per supportare l’ottimizzazione della supply chain.

Vedi dati non validi per ulteriori informazioni su questo punto.

5. Gestione del Cambiamento e dei Rischi

5.1 Che tipo di supporto potete offrire all’azienda cliente per aiutare a gestire il cambiamento associato all’implementazione dell’iniziativa?

Tutti i clienti hanno il pieno impegno degli Supply Chain Scientists (SCSs) di Lokad, tutti addestrati per gestire le esigenze tecniche e non tecniche 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 di formazione 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.

Va notato che la gestione del cambiamento può rappresentare un impegno di tempo significativo per un SCS. Sebbene ogni SCS abbia competenze e esperienze uniche per 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 - ovvero la dimensione del team di SCSs - che saranno disponibili per supportare l’iniziativa. Le nostre proposte commerciali di solito prevedono che gli SCSs forniscano 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 ciò non sia 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? Come appare la nuova organizzazione dopo l’implementazione di successo della nuova soluzione?

Una volta che Lokad è in produzione, una classe intera di decisioni sulla supply chain viene automatizzata. L’obiettivo è quindi trasformare la pratica della supply chain in un’attività capitalistica. Ogni ora trascorsa da un professionista della supply chain dovrebbe contribuire al miglioramento continuo delle ricette numeriche. Questo rappresenta una deviazione dalla pratica della supply chain “mainstream” in cui la maggior parte degli sforzi in un determinato 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 obiettivo è far sì che i professionisti della supply chain riconoscano che Lokad consente loro di eliminare la maggior parte dei processi obsoleti. Ad esempio, ha senso rivedere le quantità di rifornimento giornaliere quando tali quantità sono frequentemente errate. Tuttavia, per design, le quantità di Lokad sono già corrette e non necessitano di ulteriori revisioni. In effetti, il criterio principale per il passaggio alla produzione è che le cifre generate da Lokad siano prive di errori al 100%. La fiducia che i professionisti della supply chain possono riporre nelle cifre di Lokad libera naturalmente molto tempo che può essere impiegato in modo migliore.

• Il secondo obiettivo consiste nel coinvolgere alcuni “early adopter” tra i professionisti della supply chain. Queste persone sono tipicamente coloro che riescono rapidamente a separarsi dai processi obsoleti che non aggiungono valore - ad esempio, la revisione manuale delle cifre - per concentrarsi sul miglioramento continuo della supply chain attraverso le ricette numeriche. Possono iniziare ad affrontare numerose domande importanti oltre agli aspetti tecnici minori (ad esempio, l’azienda cliente sta valutando la qualità del servizio dal punto di vista corretto?).

• Il terzo obiettivo è che la maggior parte dei professionisti della supply chain guardi verso l’esterno (clienti e fornitori) anziché verso l’interno. Alla fine, la supply chain deve fornire un allineamento che va oltre i confini dell’azienda cliente. Questo espande il pool di informazioni 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à delle attività per il professionista della supply chain. Tipicamente, ciò si traduce in meno tempo e sforzo dedicati al controllo della supply chain, ma si richiede di più alla direzione per migliorare le competenze dei dipendenti in modo che possano sfruttare il tempo e lo sforzo disponibili in modo più efficace.

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

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

Per design, le decisioni sulla supply chain generate da Lokad non richiedono flussi di lavoro. Infatti, l’automazione di tutti i passaggi coinvolti nella generazione delle decisioni sulla supply chain è l’arrangiamento desiderato.

Tuttavia, se esplicitamente richiesto dal cliente, Lokad è in grado di introdurre un “flusso di lavoro” che riflette quello precedente. Questo, va capito, è puramente per facilitare la gestione del cambiamento e non è un requisito per il successo delle ricette numeriche in alcun modo. Man mano che i dipendenti del cliente diventano più familiari e sviluppano maggiore fiducia nelle decisioni generate da Lokad, il “flusso di lavoro” può essere gradualmente semplificato, fino a quando non viene completamente eliminato.

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

5.4 Puoi mantenere un registro di problemi e rischi che includa un piano di mitigazione, attività, responsabilità, tempi e stato (non avviato, in corso, chiuso, in attesa)? Il Project Manager di Lokad sarà responsabile del monitoraggio di tutti i problemi e rischi e garantirà risoluzioni tempestive o gestirà le escalation quando necessario?

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

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

La possibilità di contattare facilmente gli SCS è qualcosa che i nostri clienti citano abitualmente come un grande vantaggio. Il cliente può interagire immediatamente con la persona il cui compito è supervisionare la risoluzione soddisfacente di eventuali problemi anziché dover navigare attraverso diverse gerarchie burocratiche per - si spera - 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), essi supervisionano comunque la risoluzione tempestiva del problema e agiscono come primo punto di contatto per il cliente rispettivo.

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 la partnership 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 sulla 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 nella gestione del cambiamento per integrare Lokad, li supporteremo condividendo tutto ciò che l’azienda cliente ritiene opportuno.

6. Personalizzazione e Funzionalità di Sistema

6.1 Organizzate sessioni per dare priorità ai requisiti di personalizzazione, garantendo una 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 autonomamente la personalizzazione e, quindi, è in grado di fornire chiare indicazioni su ciò che è in gioco in termini di risorse e tempi.

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

In secondo luogo, la filosofia generale di Lokad, “Supply Chain Quantitativa”, enfatizza una prospettiva puramente finanziaria. Pertanto, lo SCS supporta l’azienda cliente fornendo 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 dando priorità alle questioni che comportano il maggior impatto finanziario.

6.2 Puoi condurre uno studio di adattamento-lacuna 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. Sebbene uno studio iniziale venga condotto all’inizio dell’iniziativa, questo processo continua 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 “prestazioni”. Ad esempio, la sfida non è solo generare quantità di rifornimento (funzionalità), ma assicurarsi che le quantità generate siano le più redditizie (prestazioni).

Pertanto, gli SCS si occupano di identificare e affrontare “lacune di prestazione”, che a volte richiedono funzionalità aggiuntive o la rielaborazione 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 affrontate introducendo (o modificando) alcune righe di codice Envision. Questa programmabilità è precisamente ciò che consente a Lokad di fornire soluzioni su misura per ogni cliente.

6.3 Puoi fornire un’agenda dettagliata per gli workshop di analisi di adattamento-lacuna dei processi, inclusa l’aspettativa degli SME (Subject Matter Expert) dal lato dell’azienda 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 l’azienda cliente fornisce istruzioni esplicite, come una scadenza per fornire le agende, le seguiremo. In assenza di istruzioni, struttureremo i workshop (inclusa la pianificazione temporale e la comunicazione di tutte le necessarie fasi dal lato dell’azienda cliente) in modo intelligente e professionale.

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

Sì, questi documenti verranno forniti all’azienda cliente e successivamente approvati da essa.

Si noti che le scelte di progettazione della piattaforma di Lokad eliminano in gran parte la necessità di “personalizzazione”, almeno per come questo termine è comunemente inteso nei circoli del software aziendale. La piattaforma di Lokad è programmabile, utilizzando Envision - il nostro 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 specifiche esigenze dell’azienda cliente. Tuttavia, questa personalizzazione viene fornita in modo da mantenere la soluzione parte della linea principale dei prodotti di Lokad. Questo è l’approccio preferito (e deliberatamente progettato) di Lokad e non presenta problemi di manutenibilità.

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 SCSs potrebbero essere supportati da risorse IT interne a Lokad per gli aspetti tecnici di basso livello, come la rete o i protocolli di sicurezza.

Le interfacce di sistema di solito non vengono “certificate” da un ente di certificazione terzo. Le interfacce vengono “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 Fornisci 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 richiesto dall’azienda cliente.

Data la natura del servizio di 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. A titolo di 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 sui programmi di trasferimento.

6.7 Condividi i processi di richiesta di modifica e gestione delle release?

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

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

In secondo luogo, apportiamo aggiornamenti alla piattaforma di Lokad, di solito attraverso aggiornamenti di Envision - il nostro linguaggio di programmazione specifico del dominio dedicato all’ottimizzazione predittiva della supply chain. Queste modifiche sono progettate per essere trasparenti per le aziende clienti. Se desiderato, è possibile fornire i dettagli su questi aggiornamenti e molte di queste informazioni sono rese pubblicamente disponibili.

Per ulteriori informazioni sull’evoluzione della piattaforma di Lokad, consultare Envision VM Environment and General Architecture.

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.

In termini di metodologia, preferiamo la progettazione di liste prioritarie, in cui gli elementi sono classificati in base al ritorno sull’investimento (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.

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

Vedi anche User Acceptance Testing 7.3.

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

Sì. Grazie alla ricca programmabilità della piattaforma di Lokad, possiamo esercitare un controllo completo sulle configurazioni. Questo è reso possibile attraverso Envision - il nostro 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 quando possibile. Ciò 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 di configurazione è più efficiente rispetto ai metodi tradizionali dell’interfaccia utente.

7.3 Fornisci ambienti separati di test UAT (User Acceptance Testing), migrazione dei dati, stage di produzione (pre-prod), produzione e formazione per il prodotto (inclusi gli interfacce richieste) all’azienda cliente e ai sistemi esterni?

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

Con Lokad, la duplicazione dell’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 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 aziendali evita completamente il problema semplicemente “clonando” l’allestimento principale. Clonare - o duplicare direttamente - è facile ma inefficiente. 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 Garantisci la tempestiva risoluzione di tutti i difetti per assicurare che il test UAT (User Acceptance Testing) venga completato entro i tempi concordati reciprocamente?

Sì, a condizione che si possano concordare definizioni sfumate di “risoluzione” e “difetto”. Nel complesso, gli scienziati della supply chain di Lokad (SCSs) sono responsabili della risoluzione di tutti i problemi che compromettono l’obiettivo principale dell’iniziativa: aumentare il ritorno sull’investimento. In uno scenario tipico, lo SCS propone un’azione appropriata e una timeline corrispondente, che l’azienda cliente convalida o aggiorna a sua discrezione.

È fondamentale sottolineare che quando si tratta di supply chain, non esistono “soluzioni perfette”, solo “trade-off” migliori o peggiori. In altre parole, non è possibile risolvere un problema in cui due o più valori sono in completa opposizione.

Ad esempio, l’inventario deperibile scaduto è uno spreco, ma quando si gestiscono prodotti deperibili, tale spreco non può essere completamente eliminato senza creare un conseguente problema di “qualità del servizio”. È necessario trovare un equilibrio tra il “dead stock” e le “stockouts”. Tuttavia, sia il “dead stock” che le “stockouts” sono difetti in un certo senso.

In breve, gli SCS possono risolvere problemi “banali” man mano che si presentano, come correggere un errore di analisi durante la lettura di un file (un bug del software). Tuttavia, l’obiettivo principale di una soluzione quantitativa per la supply chain non è “risolvere problemi”, ma aumentare il ritorno sull’investimento (in dollari o euro). Lokad raggiunge questa forma di “risoluzione” attraverso un approccio intelligente e finanziario ai trade-off della supply chain.

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

Sì. Gli scienziati della supply chain di Lokad (SCSs) sono responsabili di questo processo.

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

7.6 Garantisci il supporto in loco presso la sede dell’azienda cliente durante la fase di test UAT (User Acceptance Testing)?

Sì. Il supporto in loco è regolato dall’accordo contrattuale tra Lokad e l’azienda cliente. Questo aspetto viene sempre negoziato caso per caso con il cliente.

Va notato che un’iniziativa quantitativa per la supply chain con Lokad prevede un continuo miglioramento della supply chain, quindi non esiste un periodo UAT fisso. I test di solito iniziano alla fine del secondo mese, raggiungono il picco entro il quarto mese, per poi stabilizzarsi a partire dal sesto mese.

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

Vedi anche Implementazione e Gestione del Progetto 1.7.

8. Supporto post-implementazione e auditing

8.1 Puoi garantire che le osservazioni dalle esecuzioni pilota siano documentate e che eventuali azioni siano assegnate agli interessati dei dipartimenti tecnici, IT e dei fornitori dell’azienda cliente, e che siano anche tracciate fino alla chiusura?

Sì. Gli scienziati della supply chain di Lokad (SCSs) creano e mantengono un Manuale di Procedura Condiviso (JPM) per ogni iniziativa. Esso include tutte le informazioni pertinenti per l’iniziativa. È importante sottolineare che il JPM è progettato per essere accessibile a un pubblico non tecnico (anche se alcune sezioni e allegati sono abbastanza tecnici).

Le azioni di alto livello vengono documentate nel JPM. Tuttavia, le azioni minori vengono generalmente gestite con il task manager sulla piattaforma di Lokad. Queste azioni minori sono di breve durata e il task manager facilita il monitoraggio e la chiusura meglio del JPM.

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

Sì. Gli scienziati della supply chain di Lokad (SCSs) implementano tipicamente strumenti dedicati a questo scopo durante l’ultima fase dell’onboarding, 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. Ciò viene fatto per identificare potenziali fonti di divergenza, come bug o glitch nei sistemi del cliente, che potrebbero influire sull’implementazione delle raccomandazioni di Lokad.

8.3 Effettuerai un’audit annuale dell’applicazione e fornirai un feedback per migliorare l’utilizzo e l’adozione del sistema da parte degli utenti finali, al fine di ottenere un ROI (ritorno sull’investimento) più rapido?

Sì, un’audit annuale dell’intera soluzione (end-to-end) è una procedura standard. Detto ciò, gli scienziati della supply chain di Lokad (SCSs) effettuano tipicamente l’audit dell’intera soluzione più volte durante l’anno. L’audit annuale di solito porta 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’utilizzo, nella pratica, gli SCSs implementano in modo proattivo 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 rappresenti 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 driver di un aumento del ROI in un’iniziativa quantitativa di supply chain.

8.4 Puoi garantire che il team di supporto dedicato al 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 di Lokad (SCSs) si occupa di questa attività. I nostri SCSs sono ampiamente formati per migliorare continuamente l’iniziativa e fornire supporto continuo al cliente. La presenza continua degli SCSs in loco sarà negoziata e chiarita nell’accordo contrattuale con il cliente, se questa è una cosa che il cliente desidera perseguire.

A tal proposito, Lokad raccomanda vivamente di mantenere un impegno attivo e continuo per il miglioramento della soluzione, in particolare da parte del cliente. Ridurre gli sforzi di miglioramento continuo, secondo la nostra esperienza, indebolisce la forza dell’iniziativa. Eventuali cambiamenti da parte del cliente, compresi piccoli aggiustamenti nel panorama applicativo o nei vincoli, possono influire sulla qualità delle decisioni generate da Lokad, pertanto si consiglia di essere vigili e di migliorare continuamente.

Vedi anche Implementazione e Gestione del Progetto 1.7.

9. Gestione degli incidenti e dei difetti

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

Sì. Gli scienziati della supply chain di Lokad (SCSs) 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 linguaggio di programmazione specifico per il 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 con un livello di precisione non comune nel software aziendale.

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 Puoi implementare un meccanismo di monitoraggio dei difetti per garantire la chiusura tempestiva di tutti i difetti e i 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 dei problemi. Queste 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 inaccurata della domanda è 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 ottimizzazione predittiva delle supply chain, le soluzioni sono sempre un compromesso, risolvere un difetto significa crearne un altro (sperabilmente di dimensioni minori).

Al contrario, i problemi di usabilità sono tipicamente facili 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 Puoi garantire che i difetti riscontrati durante i test delle release (prima della produzione) saranno affrontati e corretti tempestivamente, in modo da non influire sulla timeline dell’azienda cliente per il go-live 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 di Lokad (SCSs). 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 un’ampia fase di test per assicurarsi che i difetti vengano identificati e corretti prima del rilascio (go-live).

9.4 Come affronterai gli incidenti che potrebbero essere segnalati dall’azienda cliente attraverso uno dei seguenti canali: telefono, email, office communicator e/o inserimento diretto nel tool di gestione degli incidenti?

Gli scienziati della supply chain (SCSs) trattano tutti i rapporti sugli incidenti - indipendentemente dalla fonte - con la massima serietà. L’accordo contrattuale tra Lokad e l’azienda cliente specifica quanti SCSs saranno assegnati al progetto, nonché il numero di ore settimanali di supporto diretto che il cliente può aspettarsi.

La risoluzione di un tipico incidente inizia con uno SCS che crea una nuova voce nel sistema di gestione dei task/ticket/issue. Questo assicura che ci sia una tracciabilità per l’incidente.

Successivamente, lo SCS effettuerà una diagnosi del 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 radice dell’incidente segnalato, anche se alla fine è stato diagnosticato come un problema non rilevante. Di solito, c’è un problema sottostante da qualche parte che deve essere affrontato. Affrontando la causa radice più profonda, Lokad elimina in modo proattivo 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 - registrerai il difetto nel tool non appena viene segnalato per un corretto tracciamento e conformità?

Sì. È pratica comune creare una voce corrispondente all’interno della piattaforma Lokad quando riceviamo una segnalazione tramite un canale diverso dal sistema di gestione dei task/ticket/issue. Questa pratica facilita un tracciamento accurato e la conformità.