FAQ: Cambiamento Gestione

Pubblico di riferimento: I reparti supply chain e/o pianificazione.

Ultima modifica: 19 dicembre 2023

Panoramica della Gestione del Cambiamento

Quantitative supply chain (QSC), come pioniere e promotore da Lokad, si discosta notevolmente dalla prospettiva tradizionale. Le differenze sono sia essenziali che le ragioni principali per cui Lokad può offrire miglioramenti così drastici alla supply chain. Detto ciò, la gestione del cambiamento associata all’implementazione di un’iniziativa QSC è più semplice di quanto pensino solitamente i nostri clienti.

Ad esempio, Lokad elimina molti punti di contatto e processi non necessari, piuttosto che sostituire semplicemente uno spreco con un altro. Così, il cambiamento da gestire è tipicamente duplice: in primo luogo, adeguarsi al fatto che decisioni ripetitive e banali della supply chain sono ora automatizzate; in secondo luogo, accettare che la qualità di quelle decisioni automatizzate supera 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 funziona come integratore di sistemi, data engineer, analista aziendale, data scientist, esperto di supply chain e project manager (tra gli altri ruoli). I Supply Chain Scientist (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 dispiegamento con successo di Lokad (in produzione) generalmente produce due risultati notevoli: significativi risparmi grazie a migliori decisioni sulla supply chain e importanti risparmi di produttività tramite decisioni sulla supply chain (in gran parte) automatizzate.

In termini di gestione del cambiamento, i risparmi sulla supply chain sono tipicamente un aspetto secondario. L’azienda potrebbe alla fine decidere di reinvestire il capitale operativo liberato altrove, ma questo tipo di decisione normalmente eccede l’ambito dell’iniziativa Lokad. Tuttavia, i considerevoli risparmi di produttività generati da Lokad vengono solitamente reinvestiti in altre attività che apportano un valore aggiunto molto maggiore per l’azienda cliente rispetto al processo legacy.

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

Una volta che Lokad è in produzione, la maggior parte delle attività è orientata verso l’esterno: identificare ciò che i clienti percepiscono come qualità del servizio, identificare ciò che i fornitori vedono come un ostacolo a una ulteriore riduzione del prezzo, identificare ciò che i trasportatori considerano le cause principali della loro inaffidabilità, ecc.

Queste intuizioni vengono quindi continuamente incorporate nella soluzione di Lokad tramite il supporto costante dei SCSs.

Per i dirigenti della supply chain, il cambiamento più significativo è l’eliminazione (in gran parte) della gestione quotidiana delle crisi. La soluzione di Lokad fornisce decisioni automatizzate progettate per affrontare casi limite fastidiosi, riducendo così in modo sostanziale la capacità di elaborazione che i dirigenti devono dedicare all’analisi di comportamenti di mercato erratici. Ciò libera i dirigenti della supply chain per definire strategie e progetti relativi alla supply chain, invece di micro-gestire le conseguenze continue di decisioni subottimali.

Domande Frequenti (FAQ)

1. Implementazione e Gestione del Progetto

1.1 Offrite servizi di project management per l’implementazione?

Sì. Questi servizi sono forniti dai Supply Chain Scientist 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 al management della supply chain per dimostrare la validità delle ricette numeriche di Lokad prima del loro dispiegamento. I SCSs forniscono inoltre materiali di formazione per supportare l’adozione delle pratiche e dei processi raccomandati da Lokad all’interno dell’azienda cliente.

Oltre a ciò, questi esperti rimangono impegnati per il successo a lungo termine dell’iniziativa oltre l’implementazione iniziale, offrendo supporto continuo mentre l’iniziativa transita verso la fase di “miglioramento continuo”.

Consultare le lezioni di Lokad sul Supply Chain Scientist e Una giornata nella vita di un Supply Chain Scientist per ulteriori informazioni sul ruolo dei SCS nell’ottimizzazione.

1.2 Qual è la timeline di implementazione e quali step o fasi sono inclusi in questa timeline?

Dall’inizio alla fine, l’implementazione solitamente richiede circa 6 mesi. Lokad distingue la fase di onboarding dalla fase di produzione. L’obiettivo della fase di onboarding è portare in produzione la ricetta numerica di Lokad. Al termine della fase di onboarding, le decisioni sulla supply chain di interesse (come definite in collaborazione con il cliente) dovrebbero essere automatizzate.

Suddivisione della timeline

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

• Mesi 1-2: Configurazione della Data Pipeline - La prima sottofase consiste nell’installare la data pipeline. L’obiettivo è creare una pipeline completamente automatizzata per l’estrazione dei dati del cliente verso Lokad. I due aspetti più impegnativi della data pipeline sono stabilire la “semantica” dei dati e rendere il processo di pipelining (quasi) perfettamente affidabile.

• Mesi 3-4: Progettazione della Ricetta Numerica - La seconda sottofase consiste nella progettazione della ricetta numerica unica del cliente - i blocchi di logica software che guidano le decisioni sulla supply chain. L’obiettivo è ottenere ricette che siano coerenti, affidabili e prive di fronzoli. La redazione delle ricette numeriche iniziali è rapida, solitamente non richiede più di una o due settimane.

• Mesi 5-6: Esecuzione in parallelo - La terza sottofase è l’esecuzione in parallelo. La ricetta numerica non produce più risultati insensati, e i driver economici che guidano l’ottimizzazione sono stati concordati. La ricetta viene eseguita fianco a fianco con il processo legacy. Attraverso diverse settimane di esecuzione in parallelo, si acquisisce la fiducia per procedere con il dispiegamento in produzione.

Al termine della fase di onboarding - e se tutti gli step sono stati soddisfatti - inizia il dispiegamento in produzione. Questo dispiegamento consiste nel lasciare che l’automazione subentri al processo legacy.

1.3 Lokad documenta e pubblica un piano di project management?

Sì. Tutti quegli elementi, e altro ancora, sono raccolti in un unico Manuale di Procedura Congiunta (JPM) per l’iniziativa. I Supply Chain Scientist (SCSs) sono incaricati di avviare e mantenere il JPM per l’intera durata dell’iniziativa.

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

L’approccio di Lokad è che molte (se non la maggior parte) iniziative aziendali sono ostacolate dalla produzione di documenti poco utili, che in pratica sono impossibili da leggere (cioè, sono tediosi o tecnicamente impenetrabili). Tali documenti non servono a altro che a spuntare caselle inventate. Inoltre, molte terze parti (ad esempio, integratori, consulenti e persino la burocrazia interna) tendono fortemente a privilegiare la quantità rispetto alla qualità quando si tratta della documentazione del progetto.

Al contrario, i JPM di Lokad sono concepiti per essere sia leggibili che letti. I JPM sono strumenti utilizzati dagli stessi SCSs per gestire l’iniziativa. Sebbene disponiamo di linee guida dettagliate su ciò che ci si aspetta di trovare in un JPM, spetta in ultima analisi ai SCSs esercitare un giudizio accurato su cosa richiede maggiore attenzione e impegno considerando le specificità dell’iniziativa.

Consultare la lezione “Scrivere per le Supply Chains” per ulteriori informazioni sull’etica documentale di Lokad.

1.4 Lokad è responsabile del mantenimento e della definizione del piano di project management, soggetto all’approvazione del comitato direttivo del progetto? Nel caso in cui sorgessero deviazioni dal piano, le comunicherete chiaramente insieme alle opzioni di mitigazione?

Sì. Le responsabilità elencate sono gestite dai Supply Chain Scientist di Lokad (SCSs). I dettagli della gestione della comunicazione con l’azienda cliente sono tipicamente dipendenti e definiti dai termini contrattuali relativi all’iniziativa.

Occasionalmente, ci sono significativamente più dipendenti coinvolti dalla parte cliente del progetto rispetto a quella di Lokad, pertanto, per migliorare la produttività dei SCSs che gestiscono il conto, molti dei nostri clienti designano un unico punto di contatto per l’iniziativa. Questa persona – o piccolo team – è incaricata di trasmettere le informazioni rilevanti a – e di raccogliere feedback da – tutte le parti coinvolte nella parte cliente del progetto. Per un’iniziativa particolarmente complessa, Lokad istituisce un comitato direttivo dedicato composto da membri chiave sia di Lokad che dell’azienda cliente. Sebbene questa riunione serva come meccanismo per ottenere un’approvazione formale, la maggior parte del lavoro sostanziale avviene al di fuori del comitato stesso. I SCSs di solito interagiscono quotidianamente con vari team del cliente. Questi team vengono costantemente aggiornati su eventuali deviazioni dal piano e si assicurano che l’intera iniziativa rimanga sulla buona strada. Queste interazioni quotidiane sono un modo molto più efficace per discutere e superare problemi tecnici non appena sorgono, piuttosto che cercare di esaminare grandi quantità di problematiche durante una sessione del comitato direttivo. Pertanto, il comitato direttivo, in quanto tale, agisce più come un organo di supervisione che come un gruppo di riflessione per l’iniziativa.

Nota: le iniziative di quantitative supply chain sono note per incontrare frequentemente “deviazioni positive”. Si tratta di sorprese benefiche nella ricetta che si manifestano durante la manutenzione continua dell’iniziativa. In sostanza, sono opportunità troppo vantaggiose per essere ignorate. In tal senso, un vantaggio chiave dell’approccio di comunicazione di Lokad è la capacità di trasmettere prontamente ed efficientemente queste deviazioni positive al cliente non appena si presentano, aumentando così significativamente l’impatto e l’agilità dell’iniziativa.

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

Sì. I Supply Chain Scientist di Lokad (SCSs) sono responsabili di tali compiti. I dettagli della gestione della comunicazione all’interno dell’azienda cliente sono tipicamente dipendenti dai termini contrattuali relativi all’iniziativa.

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

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

Mentre Lokad chiarisce i criteri e le linee guida per l’escalation, vale la pena sottolineare che un Supply Chain Scientist Senior di Lokad è incaricato di gestire qualsiasi domanda o preoccupazione relativa all’iniziativa. Pertanto, per quanto riguarda l’escalation, la risoluzione di un problema preoccupante viene tipicamente trasferita da un Supply Chain Scientist Junior a uno Senior. Questo si è storicamente dimostrato sufficiente, con pochissime situazioni che richiedono ulteriori escalation.

Lokad considera tutte le problematiche – per quanto possano apparire minori – meritevoli di un’analisi approfondita. Sebbene i loro effetti siano facili da risolvere, i problemi minori possono rappresentare ostacoli futuri se le cause alla base non vengono comprese e affrontate. Ciò impedisce a un problema minore di diventare ricorrente. Pertanto, Lokad preferisce impiegare in prima linea persone altamente competenti, in grado di affrontare sia il problema immediato sia di identificare le cause profonde sottostanti. Questo approccio è preferibile rispetto al 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 è studiato per garantire risoluzioni rapide e durature.

1.6 Garantirete che il piano di project management sia approvato da tutte le parti interessate come parte della fase di avvio del progetto?

Sì. Più in generale, i Supply Chain Scientist di Lokad (SCSs) seguono qualsiasi processo sia stato negoziato e concordato con ciascun cliente – secondo i termini contrattuali formali. Questo principio rimane applicabile per tutta l’iniziativa, dall’inizio alla fine. L’avvio del progetto è senz’altro importante, anche se, dato che Lokad non richiede un impegno a lungo termine fin dal primo giorno, questa questione è di minore rilevanza – specialmente se confrontata con i nostri concorrenti.

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

1.7 Distribuirete un project manager dedicato da Lokad che opererà presso la sede centrale dell’azienda cliente, accompagnato da esperti in materia 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 schierare dipendenti presso la sede centrale dell’azienda cliente, ciò ovviamente aumenta il costo dell’iniziativa. La maggior parte delle nostre iniziative viene realizzata in remoto e supportata da visite mensili o trimestrali a seconda della portata dell’iniziativa. Questa pratica è solitamente percepita da tutte le parti come più efficiente rispetto al fatto di avere dipendenti di Lokad sempre presenti negli uffici del cliente. Va notato che, anche se Lokad accetta di schierare un team permanente presso la sede centrale dell’azienda cliente, i dipendenti ruoteranno nel tempo.

Tali pratiche beneficiano tutti i soggetti coinvolti, poiché i Supply Chain Scientists (SCSs) di Lokad seguono 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 dalla seniority. Pur osservando che molti fornitori enterprise consentono ai loro dipendenti di operare per mesi, se non anni, presso le sedi remote dei clienti, Lokad è convinto che tale pratica non sia compatibile con una fornitura affidabile ed efficiente di programmi di formazione di alta qualità.

In particolare, uno dei maggiori punti di forza dei Supply Chain Scientists di Lokad è il loro set di competenze eccezionalmente diversificato e ampio. Ogni SCS è formato per operare in una varietà di ruoli, come: esperto di settore, business analyst, technical interface expert, data scientist e consulente per la supply chain. Queste funzioni normalmente verrebbero svolte da più dipendenti, con un conseguente aumento significativo dei costi per il cliente. In Lokad, ogni SCS fornisce tutti questi servizi.

Di conseguenza, gli SCS tendono ad essere nettamente più produttivi (meno persone significano generalmente meno attriti nella comunicazione) e garantiscono livelli di prestazione più elevati. In realtà, le supply chain dipendono in maniera critica da una coerenza end-to-end, cosa molto più facile da ottenere con una presenza ridotta di personale.

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

Per una tipica iniziativa di Lokad, raccomandiamo che l’azienda cliente assegni un esperto della supply chain con comprovata esperienza come coordinatore dell’iniziativa e che nomini anche un executive della supply chain come supervisore dell’iniziativa. Il coordinatore funge da punto di contatto tra il team di Supply Chain Scientists (SCSs) di Lokad e l’azienda cliente. Inizialmente, il coordinatore trasmetterà le richieste di informazioni e, successivamente, quelle di feedback. Parallelamente, i Supply Chain Scientists di Lokad lavorano con le ricette numeriche atte a produrre le decisioni di supply chain di interesse.

Raccomandiamo un incontro settimanale per esaminare i progressi dell’iniziativa fino al completamento della fase di onboarding. Tale incontro è sistematicamente frequentato dal coordinatore, dal supervisore e dal principale SCS dell’account di Lokad. Altri partecipanti possono unirsi se necessario, ma la loro presenza continua di solito non è indispensabile durante tutta la fase di implementazione/onboarding.

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

Successivamente, i SCS dovranno raccogliere approfondimenti qualitativi sui processi esistenti, nonché i dettagli di tutte le priorità e restrizioni della supply chain. Solitamente, a sostegno di questo processo, si tengono una serie di interviste facilitate dai coordinatori. Più tardi, una volta che i SCS avranno sviluppato la/e ricetta/e numerica/e, si svolgerà un’altra serie di interviste per esaminare le cifre generate da tali ricette e permettere ai SCS di perfezionarle e migliorarle.

Il contributo del supervisore è importante sia per allineare Lokad con la strategia di alto livello perseguita dall’azienda, sia per evitare che l’iniziativa si fermi a causa dell’indecisione. 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 tali opzioni in termini non tecnici, ma in definitiva occorrono alcune scelte strategiche.

Ovviamente, tutto quanto sopra dipende dalle specifiche esigenze 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 mette a disposizione numerose lezioni dedicate all’ottimizzazione di una supply chain di successo.

2. Gestione delle risorse e requisiti

2.1 Quali sono le necessità di personale per l’implementazione del progetto presso l’azienda cliente?

Una tipica iniziativa di Lokad richiede all’incirca da 0.5 a 2 FTE (equivalenti a tempo pieno) di risorse dall’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à almeno 0.25 FTE.

In termini di risorse richieste ad ogni fase di una iniziativa “tipica”, durante la fase di onboarding abbiamo:

• Mesi 1 e 2: L’impostazione del data pipeline richiede 4 settimane di lavoro a tempo pieno da parte di un data officer, tipicamente impiegato dall’IT del cliente. Il data officer dovrebbe conoscere bene il panorama applicativo dell’azienda.

• Mesi 3 e 4: La progettazione della ricetta numerica richiede 2 o 3 giorni a settimana da parte del coordinatore (azienda cliente) dell’iniziativa, un minimo di 10 ore settimanali da parte di vari esperti di supply chain per fornire approfondimenti di alto livello e, successivamente, per fornire feedback sulle cifre prodotte da Lokad.

• Mesi 5 e 6: Le necessità sono sostanzialmente le stesse della fase precedente, tuttavia il focus cambia. Il coordinatore ora dedica la maggior parte del tempo alla preparazione del roll-out adeguato e alla comunicazione con tutti gli esperti di supply chain interessati.

Vedi anche Project Implementation & Management 1.2.

2.2 Garantite che sia pianificata una quantità adeguata di personale per supportare la transizione del prodotto?

Sì. In linea di massima, Lokad raccomanda di mantenere la stessa quantità di risorse (ad es., gli stessi Supply Chain Scientists) durante la transizione dalla fase di onboarding a quella di produzione. Il ritorno potenziale sull’investimento di una soluzione ben mantenuta e continuamente migliorata è notevole.

È importante notare che, poiché Lokad automatizza le decisioni della supply chain, non sussiste un’urgenza stringente nel riqualificare tutti gli esperti di supply chain del cliente con un nuovo processo per mantenere il funzionamento della supply chain – l’automazione stessa è progettata per occuparsene.

Questo approccio snello è in netto contrasto con le grandi – e costose – “task forces” che solitamente richiedono i fornitori di software enterprise per l’avvio.

2.3 Potete garantire che sul sito della sede centrale dell’azienda cliente siano disponibili sufficienti risorse di personale e di knowledge product (KP) per supportare la transizione del prodotto?

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

Vedi anche Project Implementation & Management 1.7.

Vedi anche Resource Management & Requirements 2.2.

2.4 Organizzate delle sessioni di revisione dei requisiti con i proprietari del prodotto aziendale per raccogliere ed documentare i requisiti?

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

Tuttavia, la principale preoccupazione di Lokad è comprendere il “problema” in esame, cosa che non sempre viene agevolata dal semplice elenco dei “requisiti”. Ad esempio, se un cliente afferma di richiedere una gestione speciale dei “slow movers”, comprendiamo che il basso volume rappresenta una problematica da affrontare. Tuttavia, gestire in modo speciale quegli SKU è solo una delle tante opzioni disponibili per far fronte a tale problematica.

In questo esempio, la nostra preferenza sarebbe di determinare la vera natura dei “slow movers”. Infatti, dopo aver esaminato i punti critici della supply chain del cliente, potrebbe risultare che i “slow movers” sono SKU che sono stati prezzati, raggruppati e/o assegnati in maniera inadeguata. Una volta compreso meglio il problema (slow movers), la strategia di intervento cambia completamente, rendendo spesso più semplice affrontarlo.

Di conseguenza, pur raccogliendo e documentando tutti i requisiti del cliente, il nostro approccio enfatizza la scoperta della vera natura del problema, anziché accettare a valore nominale lo stato attuale della supply chain del cliente.

Vedi Fall in Love with the Problem, Not the Solution per ulteriori approfondimenti sulla dicotomia problema-soluzione.

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

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

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

A differenza della maggior parte dei software enterprise, la programmabilità è una caratteristica fondamentale per Lokad. Gli script Envision sopra menzionati non rappresentano una “personalizzazione” della soluzione Lokad nel senso consueto, né la loro presenza costituisce una deviazione dal ramo principale dello sviluppo della soluzione. Al contrario, la ricca programmabilità di Lokad è il percorso di implementazione prescelto.

Di conseguenza, vi è un grado estremamente elevato di certezza associato alle nostre stime (costi, tempi, ecc.). La stragrande maggioranza dei progetti resta nei limiti delle stime/budget iniziali (in ogni senso). Ciò contrasta con numerosi concorrenti di Lokad, per i quali costosi ritardi e riformulazioni dei termini sono all’ordine del giorno.

Vedi Case Study sul fiasco SAP da 500 milioni di euro di Lidl per ulteriori approfondimenti su questo punto.

2.6 Implementerete e manterrete una strategia di retention ragionevole finalizzata a trattenere il personale chiave che esegue i servizi per la durata dell’accordo? Manterrete anche piani di successione attivi per ciascuna delle posizioni chiave di Lokad?

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

Questa retention è attribuibile a salari competitivi e all’investimento continuo di Lokad nella formazione dei propri team. In particolare, il materiale relativo alla supply chain pubblicato da Lokad sul proprio sito web – in particolare la nostra serie di lezioni sulla supply chain – può essere considerato un sottoprodotto dell’attenzione di Lokad alla formazione del proprio personale. Generalmente, i fornitori di software enterprise che non dispongono di materiali didattici pubblici quasi mai offrono materiali formativi interni (anche se sosterranno il contrario).

Per quanto riguarda i piani di successione, adottiamo due pratiche importanti. Innanzitutto, ogni iniziativa di Lokad è corredata da un Joint Procedure Manual (JPM). Il JPM è il documento principale utilizzato da un nuovo SCS per familiarizzare rapidamente con tutte le informazioni e le tecnicalità rilevanti dell’iniziativa. In secondo luogo, ogni iniziativa prevede – in ogni momento – sia un SCS primario che secondario. Anche se il SCS secondario non contribuisce direttamente all’iniziativa, Lokad riserva abbastanza tempo per assicurarsi che questa persona sia pronta a prendervi il controllo qualora se ne presentasse la necessità. Tale pratica riduce notevolmente le complicazioni legate ad assenze impreviste o al turnover.

3. Ruoli, Responsabilità & 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 complessivamente è molto superiore a quanto solitamente atteso da un fornitore di software enterprise. Le questioni legate alla supply chain non sono ugualmente rilevanti per tutte le aziende, pertanto la collaborazione tende ad essere più intensa per quelle in cui la supply chain è l’elemento portante (riconosciuto) delle loro attività.

Il termine “partner” è stato diluito al punto che anche i fornitori di prodotti software banali (come ad esempio il software per il monitoraggio del tempo) finiscono per essere definiti “partner”. Tuttavia, dopo uno o due anni, la maggior parte dei nostri clienti definisce la loro relazione con Lokad come una partnership “autentica” – nel vero senso della parola. Hanno volti noti in Lokad che hanno guadagnato la loro fiducia e, di conseguenza, queste persone – tipicamente i Supply Chain Scientists (SCSs) – conoscono intimamente il loro business. Inoltre, i nostri risultati sono frequentemente ritenuti sufficientemente notevoli da essere presentati personalmente al CEO e/o al consiglio di amministrazione, anche in grandi aziende.

La collaborazione in corso con Lokad consente ai nostri clienti di riprogettare in modo positivo l’intera pratica della supply chain. In definitiva, l’intera catena viene rinnovata, incidendo positivamente sia sui clienti che sui fornitori. Va notato che Lokad non intende sostituire la fondamentale competenza strategica presente nell’azienda cliente. Piuttosto, Lokad intende automatizzare l’aspetto/i più banale/i e ripetitivo/i dei processi decisionali della supply chain. Questo approccio libera successivamente risorse significative - e spesso scarse - dei clienti che possono essere reindirizzate verso usi migliori.

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

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

• The Supply Chain Leader: Questo ruolo sottolinea l’importanza del coinvolgimento del top management nell’iniziativa quantitativa della supply chain. Pur non essendo previsto che si addentri nei dettagli tecnici, questa persona deve comprendere e comunicare le intuizioni strategiche dell’iniziativa. Il suo compito non è creare metriche e KPI, ma piuttosto valutarle criticamente e metterle in discussione, garantendo l’allineamento con la strategia complessiva.

• The Supply Chain Coordinator: Essenziale per garantire il buon funzionamento dell’iniziativa, questa persona funge da ponte tra i vari team interni. La sua responsabilità principale è raccogliere feedback, comunicare con gli stakeholder e confermare/chiarire processi e decisioni. Garantisce che l’iniziativa si allinei con i flussi di lavoro esistenti nell’azienda, mantenendo al contempo una mente aperta a possibili revisioni future dei processi.

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

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

Vedi project roles per maggiori informazioni sulle diverse designazioni all’interno di un’iniziativa quantitativa della supply chain.

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

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

Ancora più importante, i Supply Chain Scientists (SCSs) internalizzano questo tipo di matrice per prendere decisioni adeguate e rapide man mano che l’iniziativa procede. Per quanto riguarda le questioni legate all’ottimizzazione della supply chain, il punto cruciale è individuare il modo migliore per inquadrare il problema. Successivamente, l’attenzione si sposta nel determinare chi, all’interno dell’organizzazione, è nella posizione migliore per affrontarlo. In maniera critica, tutta questa analisi deve essere eseguita rapidamente per preservare lo slancio dell’iniziativa.

A tal fine, i SCSs di Lokad sono incaricati di guidare l’iniziativa e di assumersi la responsabilità della qualità dei risultati generati dalla ricetta numerica di Lokad.

In quanto tali, si tratta di un piccolo nucleo di specialisti altamente qualificati che sono responsabili delle decisioni di supply chain generate da Lokad – piuttosto che di un elaborato “sistema” o “processo” di delega di porzioni di responsabilità tra un gran numero di stakeholder. La posizione di Lokad è che tali sistemi tendono a diluire la responsabilità, anziché renderla più rigida. I nostri SCSs sono dunque formati per 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 (Responsibility, Accountability, Consulted, and Informed) per tutti gli stakeholder coinvolti nel progetto? Garantirai che questo documento venga discusso e concordato da tutte le parti coinvolte?

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

Il JPM serve anche come risorsa continua per l’iniziativa ed è redatto dai SCSs assegnati all’azienda cliente. La produzione di questo documento con parole proprie dimostra che i SCSs hanno dedicato tempo considerevole per indagare, diagnosticare e analizzare la supply chain del cliente e la soluzione complessiva (senza limitarsi a rigurgitare la letteratura preesistente del cliente).

Eventuali revisioni al JPM vengono condivise con l’azienda cliente. Lo stesso JPM viene abitualmente discusso durante le sessioni di lavoro tra Lokad e l’azienda cliente.

A proposito, la nostra esperienza indica che, qualora sorgessero disaccordi, questi di solito riflettono una questione organizzativa da risolvere all’interno dell’azienda cliente. Per questo motivo, raccomandiamo che l’azienda cliente nomini un Supply Chain Executive per supervisionare l’iniziativa. Uno dei loro contributi chiave è agire da tramite quando si presentano tali casi.

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

Sì. In linea di principio, seguiamo qualsiasi processo ritenuto necessario e formalmente concordato con l’azienda cliente. Gli elementi concordati (e qualsiasi modifica apportata man mano che l’iniziativa procede) sono documentati nel Joint Procedure Manual (JPM), che include dettagli riguardanti il gruppo di lavoro di progetto e i gruppi direttivi. Attraverso i Supply Chain Scientists (SCSs) 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 – siano essi di supply chain o burocratici per natura. Col 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 “in produzione” - cioè, le nostre raccomandazioni automatizzate per la supply chain che guidano efficacemente i processi decisionali desiderati dal cliente.

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

È interessante notare che la complessità della supply chain stessa non ha un impatto così rilevante come potrebbe sembrare, poiché Lokad si impegna a definire uno scopo sufficientemente preciso da essere realizzabile entro il lasso di tempo previsto. La nostra esperienza indica che fasi di onboarding che durano più di 6 mesi mettono l’iniziativa a rischio di stagnazione. Pertanto, progettiamo attivamente l’ambito per mitigare questo rischio.

Tali ritardi hanno poco a che fare con la configurazione tecnica di Lokad stessa. Nel complesso, la timeline suggerita non solo serve a scopi tecnici (automatizzare l’estrazione dei dati, testare le ricette numeriche, ecc.), ma permette anche ai Supply Chain Scientists (SCSs) di Lokad di diventare pienamente competenti su tutte le specificità dell’azienda cliente, e alle squadre di supply chain di “assimilare” l’approccio di Lokad – qualcosa che tipicamente rappresenta una deviazione dal processo legacy del cliente.

4.2 Quante visite in sede prevedi? Quanti workshop in sede prevedi?

Il numero di visite e workshop in sede viene negoziato come parte dei termini contrattuali specifici con l’azienda cliente, anche se va notato che i costi di viaggio possono influenzare le tariffe applicate da Lokad. Pertanto, l’inclusione di visite in sede è in ultima analisi una decisione che spetta all’azienda cliente, e Lokad si adatterà 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 sede. Raccomandiamo questo approccio per aziende più piccole (fatturato annuo inferiore a 100M USD) e per aziende che generalmente sono a loro agio con contributori remoti (come le grandi aziende di eCommerce). Circa la metà delle iniziative condotte da Lokad rientra in questa categoria.

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

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

4.3 Qual è il giusto equilibrio tra riunioni remote e in sede?

Per un’iniziativa quantitativa della supply chain, la maggior parte delle riunioni dovrebbe essere remota. La maggior parte degli incontri sono brevi (30 minuti o meno) e coinvolgono solo due partecipanti: un Supply Chain Scientist di Lokad e un operatore della supply chain dell’azienda cliente. Inoltre, le riunioni remote sono utili per compiti tecnici specifici, poiché tutti i partecipanti hanno accesso al proprio setup informatico, compresi monitor di grandi dimensioni. Questo è particolarmente utile quando i partecipanti devono analizzare report complessi.

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

Questo approccio consente ad entrambe le parti di mantenere le riunioni remote informali, convenienti 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, inclusa l’installazione delle interfacce?

Sì. In effetti, Lokad va oltre l’assistenza all’azienda cliente nella valutazione della prontezza al go-live. Una delle principali responsabilità dei Supply Chain Scientists (SCSs) di Lokad è quella di assumersi la responsabilità della 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. Essa garantisce l’accuratezza, la rilevanza e l’adeguatezza dell’intera pipeline di elaborazione dei dati, tenendo in considerazione anche le preoccupazioni commerciali complessive del cliente.

Data la loro natura soggetta a errori, le interfacce software meritano un’attenzione specifica, e il SCS è ben equipaggiato per assistere nella valutazione della loro integrità. Lokad valuta tale integrità sia sul lato di ingresso (quando Lokad riceve dati storici dall’azienda cliente) sia su quello 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 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 Prepari il documento di strategia per la transizione e migrazione in produzione per gestire la transizione senza interruzioni delle operazioni aziendali (dall’applicazione aziendale esistente a quella nuova) per l’azienda cliente?

Sì. La transizione è documentata nel nostro Joint Procedure Manual (JPM). Questa ampia documentazione, prodotta dai Supply Chain Scientists (SCSs) di Lokad, garantisce che sia gli operatori della supply chain che gli executive della supply chain abbiano accesso a materiali ben scritti che spiegano adeguatamente il processo in termini comprensibili. I SCSs fanno notevoli sforzi per assicurare che questo documento sia accessibile a un pubblico non tecnico (anche se alcuni allegati possono essere piuttosto tecnici).

Inoltre, l’approccio dual-run di Lokad è particolarmente adatto a garantire una transizione fluida dal processo legacy alla nuova soluzione. “Dual-run”, in questo contesto, si riferisce alla pratica in cui Lokad opererà in parallelo con il processo decisionale legacy su l’intero ambito dell’iniziativa. Questa pratica è resa possibile solo grazie alla natura robotizzata del processo decisionale legacy di Lokad, e garantisce che le ricette numeriche implementate dai SCSs di Lokad siano state eseguite in condizioni di produzione esatte per settimane prima del go-live effettivo, quando le decisioni di Lokad sovrastano il processo legacy.

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

4.6 Fornisci l’ambito, le tempistiche e i criteri di successo per il pilot run da revisionare e approvare dall’azienda cliente?

Sì. L’ambito è sempre dettagliato nell’accordo contrattuale tra Lokad e l’azienda cliente. Solitamente assume la forma di un dato tipo di decisione della supply chain (ad esempio, il rifornimento di magazzino o l’allocazione delle scorte) su un insieme di sedi e/o su un insieme di sistemi aziendali.

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

In termini di criteri di successo, la decisione è sempre presa unilateralmente dalla società cliente. Sebbene possiamo documentare i principi guida che dovrebbero supportare questa decisione, una decisione non unilaterale sarebbe inusuale. In altre parole, un fornitore non dovrebbe trovarsi nella posizione di decidere che il pilot ha avuto successo se il cliente ritiene il contrario.

Vedi anche Implementazione e Gestione del Progetto 1.2.

Si prega di consultare Assessing the Success of a Quantitative Supply Chain Initiative per ulteriori informazioni su questo punto delicato.

4.7 Organizzerete la conduzione di prove pilota per garantire a) l’adeguatezza dei dati, b) la configurazione del sistema e la prontezza dell’applicazione, c) la conformità dei processi/sistemi, e d) l’idoneità complessiva allo scopo?

Sì. In linea di massima, trattiamo un pilot – destinato a fornire supply chain optimization – esattamente come tratteremmo un’iniziativa “reale” destinata ad essere messa in produzione. In pratica, per quanto riguarda la supply chain optimization, 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 quanto sopra. Secondo la nostra esperienza, l’adeguatezza dei dati è raramente un problema nelle aziende che si sono digitalizzate molti anni (se non decenni) fa. Finché esiste un sistema aziendale per tracciare ciò che viene acquistato, prodotto, immagazzinato e venduto, l’iniziativa è quasi garantita ad avere dati adeguati. La sfida consiste nel dare senso ai dati che non sono stati originariamente raccolti per supportare l’optimization della supply chain.

Vedi bad data per ulteriori informazioni su questo punto.

5. Gestione del Cambiamento e dei Rischi

5.1 Quale supporto potete offrire alla società cliente per aiutare nella gestione del cambiamento associato all’implementazione dell’iniziativa?

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

• Proporre miglioramenti ai processi esistenti per i supply chain practitioners impiegati dalla società cliente.
• Produrre materiale formativo per l’integrazione dei membri/team della società cliente.
• Assistere il management della supply chain quantificando in dollari o euro (o nella valuta scelta dal cliente) l’impatto delle modifiche apportate alla supply chain.

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

Pertanto, i termini contrattuali negoziati tra Lokad e ogni cliente specificano la quantità di risorse – cioè, la dimensione del team di SCSs – che sarà disponibile per supportare l’iniziativa. Le nostre proposte commerciali generalmente prevedono che gli SCSs forniscano un certo supporto nella 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 con successo della nuova soluzione?

Una volta che Lokad è in produzione, un’intera classe di decisioni della supply chain viene automatizzata. L’obiettivo è trasformare la pratica della supply chain in un’impresa capitalistica. Ogni ora trascorsa da un supply chain practitioner dovrebbe contribuire al miglioramento continuo delle ricette numeriche. Questo rappresenta una deviazione dalla pratica “mainstream” della supply chain, in cui la stragrande maggioranza degli sforzi in un determinato giorno è destinata a mantenere l’azienda in attività per un giorno in più. Naturalmente, la transizione verso questa forma a valore aggiunto della supply chain è graduale.

• La prima tappa è far riconoscere ai supply chain practitioners che Lokad consente loro di abbandonare gran parte dei processi legacy. Ad esempio, ha senso rivedere le quantità giornaliere di rifornimento quando queste quantità sono spesso errate. Tuttavia, per design, le quantità generate da Lokad sono già affidabili e non necessitano di ulteriori revisioni. Di fatto, l’assenza totale di errori (0%) nelle cifre generate da Lokad è il criterio principale per l’avvio della produzione. La fiducia che i supply chain practitioners possono riporre nelle cifre di Lokad libera naturalmente molto tempo, che può essere impiegato in modo più produttivo.

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

• La terza tappa consiste nel fare in modo che la maggior parte dei supply chain practitioners guardi all’esterno (clienti e fornitori) piuttosto che all’interno. In ultima analisi, la supply chain deve garantire un allineamento che vada oltre i confini della società cliente. Questo amplia il bacino di intuizioni raccolte e aiuta a perfezionare ulteriormente le ricette numeriche.

La nuova organizzazione si avvicina molto a quella di una società software. Ci sono poche attività ripetitive della supply chain gestite manualmente, poiché tali compiti ripetitivi sono ora automatizzati. Inoltre, le emergenze sono molte meno (ancora, grazie all’automazione). La riduzione delle attività di routine comporta un aumento della varietà delle mansioni per il supply chain practitioner. Tipicamente, questo si traduce in meno tempo e sforzi dedicati al controllo della supply chain, ma ci si aspetta che il management investa di più nella formazione dei dipendenti, in modo che possano capitalizzare sul maggior tempo e impegno a disposizione.

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

5.3 Come gestite il cambiamento dei workflow per gli utenti finali? In primo luogo, con l’onboarding di Lokad, in secondo luogo con l’evoluzione stessa di Lokad.

Per design, le decisioni della supply chain generate da Lokad non richiedono workflow. Infatti, l’automazione di tutti i passaggi coinvolti nella generazione delle decisioni della supply chain è l’organizzazione desiderata.

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

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

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

Sì. La piattaforma di Lokad include un proprio issue/ticket/task manager interno. Questa funzione offre tutte le consuete capacità che ci si aspetta da un tale strumento, come la gestione degli stati, delle priorità, delle assegnazioni, delle notifiche, ecc. Inoltre, manteniamo separatamente un Joint Procedure Manual (JPM) che fornisce una presentazione completa e ben organizzata dell’iniziativa con tutte le timeline di alto livello rilevanti. I Supply Chain Scientists (SCSs) di Lokad sono responsabili della supervisione del task manager. Si assicurano che problemi e preoccupazioni vengano affrontati prontamente.

Le escalation sono possibili ma rare. Lo stesso SCS che gestisce/revisiona i compiti li risolverà anche. I Senior SCSs di Lokad ricoprono una vasta gamma di ruoli: esperto della supply chain, data engineer, data integrator, business analyst, data scientist, project manager, change consultant, ecc.

La possibilità di contattare facilmente gli SCSs è qualcosa che i nostri clienti menzionano regolarmente come un aspetto molto positivo. Il cliente può interagire immediatamente con la persona il cui compito è supervisionare la risoluzione soddisfacente di eventuali problemi, invece di dover attraversare diversi strati di burocrazia per cercare, si spera, di parlare con qualcuno in grado di aiutarli.

Nel caso in cui ci sia un problema che richieda competenze al di fuori dell’esperienza di un SCS (ad esempio, un problema tecnico con l’architettura della piattaforma), questi superviseranno comunque la risoluzione tempestiva del problema e agiranno come primo punto di contatto per il rispettivo cliente.

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

Sì, se la società cliente desidera che la sua partnership con Lokad includa servizi di consulenza per la gestione del cambiamento. Va notato che 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 della supply chain. Questo approccio, se implementato, limiterebbe il numero di terze parti coinvolte nel progetto.

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

6. Personalizzazione & Funzionalità del Sistema

6.1 Organizzate sessioni per dare priorità ai requisiti di personalizzazione, garantendo una comprensione degli impatti aziendali dovuti alle carenze del prodotto e raggiungendo un accordo reciproco sulla priorità di rilascio delle personalizzazioni?

Sì. I Supply Chain Scientists (SCSs) di Lokad sono responsabili di questo processo. Infatti, Lokad si distingue su due fronti per quanto riguarda questa prioritizzazione. Primo, un SCS è in grado di implementare autonomamente la personalizzazione e, di conseguenza, di fornire chiare indicazioni su ciò che è in gioco in termini di risorse e tempi.

Ciò migliora notevolmente la qualità della prioritizzazione, poiché la società cliente beneficia di un esperto in grado di bilanciare prontamente i vantaggi di un qualsiasi cambiamento nella supply chain con i costi associati a tale cambiamento.

Secondo, il “Quantitative Supply Chain” – la filosofia globale di Lokad – enfatizza una prospettiva puramente finanziaria. Pertanto, l’SCS supporta la società 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 debba essere prioritizzato. Invece, Lokad semplifica questo processo dando la priorità alle questioni che comportano il maggior impatto finanziario.

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

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

Per quanto riguarda la supply chain optimization, le lacune raramente riguardano la “funzionalità”, ma piuttosto la “performance”. Ad esempio, la sfida non è solo generare quantità di rifornimento (funzionalità), ma assicurarsi che le quantità generate siano le più redditizie (performance).

Pertanto, gli SCSs si occupano di identificare e affrontare le “lacune di performance”, che talvolta richiedono funzionalità aggiuntive o il re-engineering della soluzione. Ciò può comportare l’aggiunta o la rimozione di funzionalità per ottimizzare la performance complessiva.

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

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

Sì. I Supply Chain Scientists (SCSs) di Lokad forniscono un’agenda per ogni workshop. Ci assicuriamo che l’agenda venga comunicata almeno una settimana prima dell’evento. Se la società cliente fornisce istruzioni esplicite, come una timeline per la consegna dell’agenda, le seguiremo. In assenza di istruzioni, struttureremo i workshop (inclusi la timeline e la comunicazione di tutti i passaggi necessari per il cliente) in modo intelligente e professionale.

6.4 Assicuratevi che i documenti sui requisiti di personalizzazione del prodotto siano esaminati e approvati congiuntamente dalla società cliente?

Sì, questi documenti saranno forniti alla società cliente e successivamente approvati da essa.

Si prega di notare che le scelte progettuali della piattaforma di Lokad eliminano in gran parte la necessità di “customization” – almeno nel senso in cui questo termine è comunemente inteso nei circoli del software enterprise. La piattaforma di Lokad è programmatica, utilizzando Envision – il nostro DSL (domain-specific programming language) dedicato alla predictive optimization della supply chain.

Pertanto, le soluzioni di Lokad sono sempre “customizzate” nel senso che sono pienamente adattate alle esigenze specifiche dell’azienda cliente. Tuttavia, tale customizzazione viene fornita in modo da mantenere la soluzione come parte della linea principale dei prodotti di Lokad. Questo è l’approccio preferito (e deliberatamente progettato) da Lokad, e non comporta alcun problema di manutenibilità.

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

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

Le interfacce di sistema non sono solitamente “certificate” da un ente di certificazione terzo. Le interfacce sono “specificate formalmente” 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 puntualmente; Lokad, a sua volta, si impegna a restituire i risultati in tempo.

6.6 Fornite documenti di specifica delle interfacce durante i workshop, inclusi messaggi di esempio?

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

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

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

Sì. I Supply Chain Scientists (SCSs) di Lokad sono responsabili di questo processo. È importante notare che Lokad dispone di due livelli di modifiche e release, cosa che si differenzia dal software enterprise tipico.

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

In secondo luogo, apportiamo aggiornamenti alla piattaforma di Lokad, tipicamente tramite aggiornamenti a Envision - il nostro DSL (domain-specific programming language) dedicato all’ottimizzazione predittiva della supply chain. Queste modifiche sono progettate per essere trasparenti per le aziende clienti. Se desiderato, i dettagli riguardanti questi aggiornamenti possono essere forniti, e gran parte di queste informazioni è resa pubblica.

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

7. Test di Accettazione Utente (UAT)

7.1 Assistete l’azienda cliente nell’allestimento dell’ambiente di test per il UAT (User Acceptance Testing) con dati specifici del contesto e configurazioni di sistema?

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

In termini di metodologia, favoriamo la progettazione di liste prioritarie, in cui gli elementi sono ordinati per ROI (return on investment) 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 progettata specificamente per supportare in maniera concorrente più ambienti per qualsiasi iniziativa. Questi ambienti sono una caratteristica nativa della nostra piattaforma SaaS multi-tenant, e pertanto possono essere introdotti con un sovraccarico minimo, sia in termini di risorse computazionali che di tempo di amministrazione del sistema.

Vedere anche User Acceptance Testing 7.3.

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

Sì. Data la ricca programmabilità della piattaforma di Lokad, possiamo esercitare un controllo totale sulle configurazioni. Ciò è reso possibile tramite Envision - il nostro DSL (domain-specific programming language) 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 ove possibile. Ciò riduce notevolmente le differenze accidentali tra gli ambienti, che potrebbero confondere gli utenti e compromettere l’integrità del processo di UAT.

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

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

Sì. La piattaforma di Lokad è stata progettata specificamente per supportare in maniera simultanea più ambienti per qualsiasi iniziativa. Questi ambienti sono una caratteristica nativa della nostra piattaforma SaaS multi-tenant, e pertanto possono essere introdotti con un sovraccarico minimo, sia in termini di risorse computazionali che di tempo di amministrazione del sistema.

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

Tuttavia, la maggior parte dei fornitori di software enterprise elude il problema semplicemente “clonando” l’impostazione principale. Il cloning – o semplice duplicazione – è facile ma dispendioso. Clonare significa che la quantità di risorse (umane e macchine) aumenta in modo lineare con il numero di ambienti — ad esempio, tre ambienti triplicano i costi iniziali. Per qualsiasi supply chain di dimensioni rilevanti, ciò si traduce in costi considerevoli.

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

Sì, a condizione che si possano concordare definizioni sfumate di “risoluzione” e “difetto”. In generale, i Supply Chain Scientists (SCSs) di Lokad sono responsabili della risoluzione di tutti i problemi che compromettono l’obiettivo principale dell’iniziativa: aumentare il return on investment. In uno scenario tipico, gli SCS propongono un’azione appropriata e una tempistica corrispondente, che l’azienda cliente convalida o aggiorna a sua discrezione.

È fondamentale sottolineare che, quando si tratta di supply chain, non esistono soluzioni perfette, ma solo compromessi migliori o peggiori. In altre parole, non si può veramente risolvere un problema in cui due o più valori sono in totale opposizione.

Ad esempio, l’inventario deperibile scaduto è uno spreco, ma quando si gestiscono prodotti deperibili, tale spreco non può essere completamente eliminato senza creare conseguenti problemi di qualità del servizio. Bisogna trovare un equilibrio tra stock invenduto e mancanza di scorte. Tuttavia, sia lo “stock invenduto” che le “mancanze di scorte” sono, in un certo senso, difetti.

In breve, gli SCSs possono risolvere problemi “banali” man mano che si presentano, come ad esempio correggere un errore di parsing durante la lettura di un file (un bug software). Tuttavia, l’obiettivo principale di una soluzione quantitativa per la supply chain non è “risolvere problemi” bensì aumentare il return on investment (in dollari o euro). Lokad raggiunge questo tipo di “risoluzione” attraverso un approccio intelligente e finanziariamente orientato ai compromessi nella supply chain.

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

Sì. I Supply Chain Scientists (SCSs) di Lokad sono responsabili di questo processo.

Tuttavia, per quanto riguarda l’ottimizzazione della supply chain, dataset di dimensioni inferiori 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) delle stesse dimensioni della configurazione di produzione per rispecchiare 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 on-site presso la sede centrale dell’azienda cliente durante la fase di UAT (User Acceptance Testing)?

Sì. Il supporto on-site è regolato dall’accordo contrattuale tra Lokad e l’azienda cliente. Questo aspetto viene sempre negoziato caso per caso con ciascun cliente.

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

Dedicaando risorse continue al perfezionamento delle nostre ricette numeriche (algoritmi dedicati all’ottimizzazione della supply chain), Lokad garantisce a ciascun cliente un’iniziativa aggiornata.

Vedere anche Project Implementation & Management 1.7.

8. Support post-implementazione e auditing

8.1 Potete garantire che le osservazioni delle fasi pilota siano documentate, che le eventuali azioni da intraprendere siano assegnate agli stakeholder interessati nei dipartimenti Tecnico, IT e Fornitori dell’azienda cliente, e che vengano monitorate fino alla chiusura?

Sì. I Supply Chain Scientists (SCSs) di Lokad creano e mantengono un Manuale di Procedura Congiunto (JPM) per ogni iniziativa. Esso include tutte le osservazioni pertinenti all’iniziativa. È importante sottolineare che il JPM è progettato per essere accessibile a un pubblico non tecnico (sebbene alcune sezioni e allegati siano piuttosto tecnici).

Gli elementi d’azione di alto livello sono documentati nel JPM. Tuttavia, le azioni minori sono solitamente gestite con il task manager della piattaforma di Lokad. Questi elementi minori hanno una durata breve e il task manager ne facilita il monitoraggio e la chiusura meglio del JPM.

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

Sì. I Supply Chain Scientists (SCSs) di Lokad implementano tipicamente strumenti dedicati a questo scopo durante l’ultima fase di onboarding, poco prima del kick-off ufficiale.

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

8.3 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 accelerare il ROI (return on investment)?

Sì, un audit annuale dell’intera soluzione (end-to-end) è una procedura operativa standard. Detto questo, i Supply Chain Scientists (SCSs) di Lokad solitamente auditano l’intera soluzione diverse 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, in pratica, gli SCSs implementano in modo proattivo strumenti dedicati fin dall’inizio per monitorare l’uso, l’adozione e la conformità alle decisioni di supply chain generate da Lokad. Mentre un audit annuale rappresenta un’ottima opportunità per effettuare gli aggiustamenti necessari, i nostri SCSs sono molto proattivi per quanto riguarda l’adozione delle raccomandazioni di Lokad per la supply chain. Questa questione sarà discussa durante le nostre sessioni di lavoro settimanali, poiché l’adozione delle raccomandazioni di Lokad è il principale motore per l’aumento del ROI in un’iniziativa quantitativa per la supply chain.

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

Sì. Il team di Supply Chain Scientists (SCSs) di Lokad si occupa di questo compito. I nostri SCSs sono adeguatamente formati sia per migliorare continuamente l’iniziativa sia per fornire un supporto costante al cliente. La presenza continua degli SCSs on-site sarà negoziata e chiarita nell’accordo contrattuale con il cliente, se questi desidera procedere in tal senso.

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

Vedere anche Project Implementation & Management 1.7.

9. Gestione degli incidenti e dei difetti

9.1 Potete garantire che tutti i difetti essenziali e le richieste di modifica (elementi critici e ad alta priorità) vengano trattati come priorità e consegnati, al fine di evitare ritardi nelle tempistiche di go-live dell’azienda cliente?

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

La piattaforma di Lokad è programmatica, resa possibile grazie a Envision - il nostro DSL (domain-specific programming language) dedicato all’ottimizzazione predittiva delle supply chain. Questa programmabilità significa che gli SCSs possono prontamente fornire correzioni e implementare le modifiche richieste all’iniziativa, con un livello di precisione non comunemente riscontrato nel software enterprise.

Oltre alla tecnologia, gli SCS di Lokad sono formati per svolgere numerosi ruoli chiave, il che riduce naturalmente il numero di persone necessarie per affrontare difetti e richieste di modifica. Questi ruoli includono supply chain expert, analista aziendale, data scientist, data engineer e system integrator. Sono quindi ben addestrati a fornire correzioni e aggiornamenti, tenendo presente le principali priorità del cliente.

Vedi anche Customization & System Functionality 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 Lokad è dotata di un proprio sistema di gestione di task/ticket/issue. Queste capacità ci consentono di seguire con precisione la risoluzione tempestiva dei problemi. Tali risoluzioni sono seguite dai team di Supply Chain Scientists (SCSs) impiegati da Lokad.

Tuttavia, è importante non aggregare “difetti” e “problemi di usabilità”. Ad esempio, una previsione della domanda imprecisa è un “difetto”. Impatta negativamente la supply chain. Tuttavia, a seconda delle condizioni di mercato in cui opera l’azienda cliente, questo “difetto” potrebbe non essere mai corretto, ma soltanto mitigato. Per quanto riguarda l’ottimizzazione predittiva delle supply chains, le soluzioni rappresentano sempre un trade-off: risolverne uno crea, spesso, un altro (si spera minore).

Al contrario, i problemi di usabilità sono generalmente di facile soluzione. Pertanto, per questa categoria di problemi, siamo disposti e impegnati a garantirne una risoluzione tempestiva, poiché affrontarli non comporta, solitamente, la creazione di ulteriori problemi.

9.3 Puoi garantire che i difetti riscontrati durante i test delle release (prima della produzione) siano gestiti e rettificati in modo tempestivo, affinché non influenzino il calendario dell’azienda cliente per il go-live della release?

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

In entrambi i casi, il processo di rilascio di Lokad prevede test approfonditi per assicurarsi che i difetti vengano 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, office communicator e/o inserimento diretto nello Strumento di Gestione degli Incidenti?

I Supply Chain Scientists (SCSs) trattano tutti i report di incidenti – indipendentemente dalla loro fonte – con la massima serietà. L’accordo contrattuale tra Lokad e l’azienda cliente specificherà quanti SCS saranno assegnati al progetto, nonché le ore settimanali durante le quali il cliente potrà aspettarsi un supporto diretto.

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

Successivamente, l’SCS diagnosticherà il problema. Se il problema richiede una correzione da parte di Lokad, l’SCS mobiliterà immediatamente le risorse necessarie per risolverlo – tipicamente l’SCS stesso/a.

Infine, una volta affrontato il problema, l’SCS analizzerà la vera causa alla radice della segnalazione, anche se in seguito la segnalazione fosse stata diagnosticata come non rilevante. Di solito, esiste un problema sottostante da risolvere. Affrontando la causa radice, Lokad elimina proattivamente problemi simili in futuro.

9.5 Se un difetto viene segnalato al di fuori dello Strumento di Gestione degli Incidenti – tramite un altro canale come l’email – verrà registrato nello strumento non appena segnalato per garantire un tracciamento e una conformità adeguati?

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