Ivanti Blog: Post di

Come evitare questi due problemi comuni nell’applicazione mensile delle patch

Tue, 25 Jul 2023 14:02:27 Z

È arrivato il momento: bisogna applicare le patch agli endpoint. Forse è un’attività che ti piace, ma probabilmente non è così. L’applicazione delle patch può essere un compito impegnativo e, poiché molte organizzazioni la gestiscono ancora manualmente, richiede più tempo e risorse di quanto chiunque vorrebbe davvero considerare.

Ora, dato che investirai tutto quel tempo e quelle risorse nell’applicazione delle patch, vuoi assicurarti che tutto proceda senza intoppi. Nessuno vuole dedicare così tante energie alla gestione delle patch per poi ritrovarsi in un groviglio di confusione ed errori.

Assicuriamoci quindi di non incorrere in questi due problemi più comuni nell’applicazione mensile delle patch:

Le tue patch funzionano?
Hai testato le patch nel tuo ambiente?

Problema di patch n. 1: le tue patch funzionano?

Non è raro che le patch e gli aggiornamenti di sicurezza semplicemente non vadano a buon fine. A volte dipende da un problema specifico dell’ambiente. Altre volte, è la patch stessa a non essere valida.

Meno male che hai deciso di controllare quella patch prima di distribuirla alla cieca, vero? Ma ora che non funziona, cosa puoi fare? Dipende.

Soluzione 1: contatta il tuo fornitore di gestione delle patch di terze parti

Se utilizzi un fornitore di patching di terze parti per gestire gli aggiornamenti delle patch, sarà il primo interlocutore da contattare.

Sebbene le aziende che gestiscono il patching di terze parti testino accuratamente i contenuti che distribuiscono ai clienti, non possono verificare ogni scenario d’uso. Potresti avere una configurazione particolare, oppure il tuo endpoint potrebbe gestire la patch in modo diverso da quanto previsto dal fornitore di patch di terze parti.

Qualunque sia il motivo, il tuo fornitore dovrebbe sempre essere il primo punto di riferimento. Segnalare l’errore è importante non solo per poterlo correggere, ma anche perché è utile al fornitore di patching di terze parti.

Potresti aver individuato un problema sistemico. A quel punto diventi la persona che ha avvisato l’azienda di un problema più ampio, consentendole di intervenire rapidamente per risolverlo.

Forse non è sistemico, ma è comunque un problema abbastanza comune da aiutare l’azienda a prepararsi meglio alle future chiamate di altri clienti. Inoltre, hai fornito un potenziale nuovo scenario d’uso da aggiungere ai protocolli di test predefiniti.

Soluzione 2: consulta la community online più ampia per individuare possibili problemi delle patch

Ma se non utilizzi un fornitore di patching di terze parti? Supponiamo che la tua organizzazione esamini manualmente queste patch.

Esistono ottime risorse online per verificare se anche altre organizzazioni stanno riscontrando gli stessi problemi, tra cui:

PatchManagement.org, “la prima mailing list del settore dedicata alla discussione sulla gestione delle patch”.
Diverse community su Reddit e Mastodon, come r/sysadmin, infosec.exchange o qualsiasi community specifica di un fornitore.
Le risorse Patch Tuesday di Ivanti, pensate per discutere quali patch vengono rilasciate e cosa ci si può aspettare da esse.

Indipendentemente dal percorso che decidi di seguire, hai a disposizione molte opzioni per capire cosa sia andato storto con la patch non riuscita.

Problema di patch n. 2: hai testato le patch nel tuo ambiente?

Bene, hai deciso di testare ogni patch in arrivo: ottimo! Sei al sicuro, giusto?

Non proprio.

Non devi inoltre dimenticare di testare le patch che distribuirai su dispositivi pilota provenienti da tutta l’organizzazione.

Perché? In fondo è solo un semplice aggiornamento di Chrome. Ma è davvero così?

Introdurre una nuova patch nei sistemi non è diverso dall’accogliere un nuovo animale domestico in casa. Anche se ne hai già avuto uno e sei convinto di sapere come prendertene cura, ognuno avrà reazioni proprie a stanze o persone, diverse da quelle dell’animale precedente.

Allo stesso modo, ogni patch presenta sfumature specifiche in termini di modifiche e aggiornamenti. Queste possono spesso entrare in conflitto con ciò per cui i tuoi sistemi o programmi sono stati progettati, compromettendo l’ambiente o l’efficacia della patch, anche se la patch ha superato i test iniziali.

Dopotutto, le aziende software non applicano patch ai prodotti pensando ai tuoi sistemi. Si concentrano sull’aggiornamento e sull’applicazione di patch alle proprie applicazioni, e non possono considerare tutti gli scenari d’uso.

Risolvere l’effetto domino dei problemi delle patch

Disporre di un gruppo pilota dedicato di endpoint su cui testare questi aggiornamenti può aiutarti a evitare di compromettere sistemi, programmi o persino processi da cui dipende la tua azienda. L’effetto domino di un piccolo aggiornamento di patch può essere dannoso per le attività aziendali.

Ad esempio, all’inizio di aprile, Chrome ha distribuito una patch per risolvere alcuni bug. Ma ha anche introdotto nuovi bug, uno dei quali ha interessato la capacità di stampa da Chrome.

E se la tua organizzazione operasse in un ambiente in cui si stampa molto e la possibilità di stampare tramite Chrome fosse indispensabile per le tue attività?

In questo modo, testare tutte le patch, anche quelle piccole e apparentemente insignificanti, può aiutarti a evitare conseguenze gravi.

Ricorda: quando qualcosa va storto, gli errori si propagano oltre il reparto o l’utente inizialmente interessato. La maggior parte degli utenti e delle organizzazioni non considera gli impatti a valle che una piccola patch può generare se non viene testata a fondo. Dopotutto, spesso è l’IT a dover rimediare agli effetti di un errore o di un’interruzione.

Quindi, quando arriva il momento di applicare le patch, vogliamo creare le condizioni per il successo. Per farlo, individuiamo una varietà adeguata di endpoint su cui testare le patch, così da assicurarci di non generare un impatto a valle evitabile, e ci prepariamo anche con le risorse della community nel caso in cui le patch non vadano a buon fine.

Puoi anche consultare:

La guida definitiva alla gestione delle patch basata sul rischio per maggiori informazioni sulla creazione di gruppi pilota, sulla gestione prioritaria delle patch e su altri principi fondamentali del patching.
Il podcast Security Insights, che tratta l’importanza della visibilità degli asset prima di distribuire semplicemente una nuova patch.
La serie Patch Tuesday, che raccoglie tutte le nostre precedenti raccomandazioni e avvertenze sul patching. Non perdere il prossimo appuntamento, che si tiene ogni mese il mercoledì immediatamente successivo al Patch Tuesday.

A volte, la migliore strategia di gestione delle patch è semplicemente una buona preparazione. Buona fortuna.

Come creare una knowledge base: un approccio semplice ma efficace

Tue, 13 Jun 2023 18:36:14 Z

All’inizio della mia carriera, sono passato da contractor nel settore della difesa ad agente del supporto clienti per un provider emergente di soluzioni di IT Service Management. Essendo nuovo nel team e nel settore, mi sentivo completamente fuori posto. Dopo la formazione iniziale sul prodotto, mi è stato indicato un computer di laboratorio e mi è stato detto di iniziare a diagnosticare una serie di problemi dei clienti. Mi sentivo completamente spaesato.

Con il tempo, studiando molto e facendo affidamento sui colleghi, ho iniziato a orientarmi e alla fine sono diventato uno degli analisti di riferimento. Il problema di questo metodo era che questa vasta conoscenza empirica era racchiusa nella mente di ciascun analista. Quando perdevamo un dipendente, perdevamo anche la sua notevole esperienza. Alla fine, è stata avviata un’iniziativa per creare una knowledge base.

Perché investire tempo e impegno nella creazione di una knowledge base è una buona idea

Sebbene ci siano alcuni motivi evidenti per disporre di una knowledge base, ad esempio:

Ridurre i tempi di risoluzione dei problemi dei clienti.
Mantenere la produttività e la soddisfazione dei dipendenti sul lavoro.
Accelerare il tempo necessario agli analisti per diventare operativi.
Fornire soluzioni coerenti.

Ci sono anche alcuni motivi meno evidenti per mantenerla, tra cui:

Eliminare la conoscenza informale non documentata

Si tratta di conoscenze detenute privatamente da singoli individui con l’intento di aumentare il proprio valore, ma che rendono l’organizzazione vulnerabile.

Migliorare la percezione dell’organizzazione e dei prodotti

Fornire risoluzioni tempestive e accurate può contribuire nel tempo alla soddisfazione per il prodotto e alla fidelizzazione dei clienti.

Ridurre i costi del supporto IT

Se la knowledge base è configurata correttamente e resa disponibile agli utenti in modalità self-service, tramite un portale web o un assistente virtuale (chatbot), i problemi possono essere risolti senza nemmeno richiedere una chiamata al service desk.

Questo viene talvolta definito supporto di livello 0. Inoltre, quando gli analisti chiudono i problemi più rapidamente, la loro produttività aumenta, spesso eliminando la necessità di aggiungere personale.

Da dove iniziare per configurare una knowledge base

La maggior parte delle soluzioni moderne di service management include un repository di knowledge base integrato, anche se non ancora popolato, pronto a ricevere il tuo prezioso contributo.

Sebbene esistano molti ottimi fornitori di knowledge base, potrebbero non essere in grado di integrarsi con il tuo ambiente di service management. Inoltre, pur non essendo una soluzione di knowledge base, SharePoint offre un modello di conoscenza che può aiutarti a iniziare.

Oltre alle soluzioni di knowledge base autonome, potresti valutare la possibilità di popolare i tuoi database di conoscenza con contenuti preconfezionati. Questi pacchetti di conoscenza, offerti da diverse aziende, si concentrano su argomenti come Windows, Office 365, Adobe, macOS e altri. Questi pacchetti di conoscenza concentrati e pronti all’uso sono molto preziosi e aiutano le organizzazioni di supporto IT più giovani ad assistere i clienti e a risolvere rapidamente i problemi.

Sebbene molte organizzazioni possano utilizzare conoscenze preconfezionate, la maggior parte supporta anche soluzioni specifiche che richiedono conoscenze specializzate. Un’organizzazione consolidata, che fornisce supporto da diverso tempo, disporrà già di informazioni preziose sotto forma di ticket di supporto passati, che possono essere rapidamente inseriti in una knowledge base.

Se l’organizzazione è nuova o è stata rilasciata di recente una nuova soluzione, i team di engineering saranno una fonte essenziale per le conoscenze iniziali di supporto.

Quasi tutte le soluzioni moderne di IT Service Management dispongono della funzionalità per avviare nuovi articoli della knowledge base direttamente dagli incident risolti e chiusi. Ad esempio, Ivanti Neurons for Service Management dispone di un “pulsante” di collegamento all’azione che trasferisce senza interruzioni i dati chiave dell’incident in un nuovo modello di knowledge base.

Include inoltre workflow per valutare, testare e perfezionare gli articoli prima della pubblicazione. La difficoltà è che i dati di risoluzione dei ticket spesso non sono scritti in un formato ripetibile, passo per passo e facile da comprendere.

Motivare team di supporto già molto impegnati a convertire e documentare gli incident passati in articoli validi e ad archiviare dati non documentati in un repository consultabile è la vera sfida.

Come motivare i tuoi team

L’organizzazione citata all’inizio di questo blog aveva un metodo estremamente efficace per estrarre informazioni dalla mente degli analisti. Utilizzava l’approccio del bastone e della carota.

Prima, il bastone. Nell’ambito degli obiettivi annuali di ciascuno, ogni analista del supporto doveva produrre un numero prestabilito di articoli originali della knowledge base al mese. L’obiettivo era in genere di 5–10 al mese, un numero ragionevole in base al nostro volume di chiamate. Il mancato raggiungimento dell’obiettivo incideva sulla valutazione annuale. Per garantire l’invio di articoli di qualità superiore, questi venivano innanzitutto verificati per evitare duplicazioni.

Successivamente, gli articoli venivano revisionati in termini di accuratezza distribuendoli ad altri membri del team per una revisione tecnica. Infine, ricevevano una revisione finale prima di essere resi disponibili al pubblico di destinazione, che fossero solo gli analisti oppure sia gli analisti sia i clienti.

Poi, la carota. L’utilizzo degli articoli veniva monitorato e gli analisti venivano premiati in base al numero di volte in cui un articolo era stato usato per risolvere con successo un problema. Una valida soluzione di IT service management con knowledge base integrata dovrebbe supportare questo livello di reportistica.

In base all’utilizzo mensile, gli analisti i cui articoli erano stati usati più spesso durante il mese per risolvere incident ricevevano un premio sostanzioso alla fine dell’anno: alcuni riconoscimenti valevano diverse migliaia di dollari.

Nel corso dell’anno venivano create campagne per motivare i team e ricordare loro requisiti e premi. Il risultato è stato la creazione, in breve tempo, di un repository ampio, in crescita e di grande valore, composto da articoli specifici per prodotto.

Qualunque sia il modo in cui decidi di motivare i tuoi team a creare contenuti di conoscenza, serviranno uno sforzo coordinato e un rafforzamento costante. I risultati ripagheranno l’impegno.

Se desideri scoprire tutti i vantaggi che un moderno provider di service management può offrire, guarda la demo completa.

Come bilanciare sicurezza e DEX per ottenere un vantaggio decisivo

Mon, 31 Oct 2022 13:35:41 Z

Alzi la mano chi apprezza essere espulso dall’applicazione su cui stava lavorando a causa di una patch di sicurezza imprevista!

Nessuno? Possiamo aspettare …

Davvero, nessuno?

D’accordo, lo immaginavamo. E non ci sorprende. Jamie Whalen, conduttore dell’Everywhere Workplace Podcast, ha recentemente incontrato Steve Brasen, Research Director di Enterprise Management Associates, per parlare del conflitto percepito tra Digital Employee Experience (DEX) e sicurezza.

Troppo spesso DEX e sicurezza vengono collocate su fronti opposti, come in un proverbiale ring. È comprensibile, ma è anche un approccio ormai superato che fa perdere un’opportunità significativa. Integrare sicurezza e DEX può offrire un importante vantaggio competitivo. Sono entrambe fondamentali e funzionano ancora meglio insieme.

DEX

I lavoratori da remoto hanno espresso chiaramente le proprie preferenze: vogliono lavorare dal luogo che preferiscono. Addio perimetri. Addio cubicoli. Molti rinuncerebbero persino a una promozione pur di avere la possibilità di lavorare da qualsiasi luogo. Vogliono accesso senza interruzioni, connettività stabile e gli strumenti giusti per svolgere bene il proprio lavoro.

Rispondere a queste esigenze è una parte importante per garantire una DEX solida, e sappiamo che la DEX è essenziale per assicurare fidelizzazione, produttività, coinvolgimento e soddisfazione dei dipendenti.

Sicurezza

Pensate che la sicurezza sia in diretta contrapposizione con questa lista di desideri dei lavoratori da remoto? Ripensateci. La sicurezza vuole la stessa cosa che vogliono gli altri lavoratori da remoto: che tutti possano svolgere il proprio lavoro in modo semplice e sicuro.

Il problema: alcune misure per raggiungere una sicurezza di livello superiore possono ostacolare l’accesso senza interruzioni, se non viene adottato l’approccio corretto.

Perché? Le misure di sicurezza più efficaci sono, ad esempio, quelle di “gestione delle password ad alto attrito”, che per definizione sono il più possibile difficili da aggirare. Ottimo per la sicurezza. Meno per i lavoratori da remoto che cercano di portare a termine il proprio lavoro.

Questa percezione di incompatibilità tra sicurezza ed esperienza dei dipendenti si è rafforzata durante la pandemia, quando moltissime aziende sono passate improvvisamente, e spesso senza una pianificazione adeguata, al lavoro da remoto. I team di sicurezza hanno dovuto recuperare terreno.

Questi team sono sotto organico e sovraccarichi: fanno del loro meglio per definire le priorità e gestire le vulnerabilità, ma a volte questo avviene a scapito dell’accesso, lasciando frustrati i lavoratori da remoto.

Controllo remoto

Ecco un segreto che non dovrebbe essere affatto un segreto: DEX e sicurezza non sono in contrasto. Anzi, una buona DEX migliora la sicurezza.

Perché? Perché una DEX positiva favorisce la conformità, e la conformità nasce in modo naturale quando i protocolli di sicurezza sono integrati in modo intelligente e fluido nell’esperienza digitale.

La chiave, quindi, è integrare questi elementi nel modo giusto.

Quando i protocolli di sicurezza vengono sviluppati e implementati al di fuori di una DEX positiva, i lavoratori da remoto si ritrovano a dover gestire continuamente controlli di sicurezza essenziali per l’azienda, ma che per loro, in quanto utenti, possono risultare estremamente onerosi.

Quando gli ostacoli da superare sono molti, i dipendenti nel migliore dei casi sono meno produttivi e tendono a cercare soluzioni alternative per lavorare senza interruzioni continue o lunghi tempi di attesa per le risposte ai ticket.

“Quando abbiamo condotto dei sondaggi, abbiamo riscontrato che la sfida più grande per gli utenti è, in realtà, riuscire a lavorare con i controlli di sicurezza senza compromettere i prodotti utilizzati dalla forza lavoro”, afferma Brasen.

Questa mancanza di conformità interna di solito non nasce da intenti malevoli; viene percepita come una scelta pratica. Purtroppo, i rischi sono elevati.

La mancanza di conformità è l’ultima cosa di cui la sicurezza ha bisogno. Quando i dipendenti sono fuori da un perimetro, lavorano su vari dispositivi e diversi sistemi operativi in tutto il mondo, i team di sicurezza si trovano di fronte a un compito di Sisifo.

“Prendiamo uno scenario in cui un dipendente da casa accede alle risorse aziendali utilizzando una VPN (virtual private network). Potrebbe anche utilizzare servizi ospitati nel cloud, separati dall’azienda”, spiega Brasen.

“E apre un ticket all’assistenza dicendo che sta riscontrando un rallentamento delle prestazioni applicative. Da dove dovrebbe iniziare l’amministratore IT? Il problema riguarda il dispositivo del dipendente? Oppure deriva dal Wi-Fi domestico del dipendente? O ancora dalla VPN o dall’ambiente ospitato nel cloud?”

Il prezzo del disallineamento

Il disallineamento tra sicurezza e DEX causa molti problemi.

La mancanza di conformità porta chiaramente a vulnerabilità enormi per l’azienda. Se la frustrazione dei dipendenti è un altro fattore importante, c’è anche altro da considerare. Steve Brasen osserva che si registra una significativa perdita di produttività associata alle barriere di sicurezza e ai riavvii di sistema. Il lavoro perso è un problema importante, e anche l’interruzione dello slancio operativo ha un costo.

Queste interruzioni si sommano: con team di sicurezza già sotto pressione e impegnati a reagire a un aumento vertiginoso delle minacce, in particolare del ransomware, patch, rallentamenti e riavvii invasivi possono sembrare costanti.

Come procedere nella stessa direzione

La buona notizia: il disallineamento tra sicurezza e DEX non è inevitabile. Ecco come procedere nella stessa direzione:

Monitorare e gestire la DEX: non si può migliorare ciò che non è stato misurato. La tecnologia può svolgere un ruolo fondamentale nel ridurre l’impatto dei protocolli di sicurezza sui dipendenti.

Per iniziare, è essenziale monitorare e gestire la DEX comprendendo davvero come gli utenti vivono i prodotti digitali e i protocolli di sicurezza, e quale impatto questi elementi hanno su di loro.

Concentrarsi sull’esperienza: avrete sentito parlare di SLA (Service-Level Agreement), ma che dire degli XLA? XLA significa Experience-Level Agreement. Il servizio si concentra su un processo, mentre gli XLA tengono conto di risultati ed esperienze.

Per quanto solidi siano i vostri SLA, se risultati e valore non sono all’altezza, il processo dovrebbe essere riconsiderato.

Adottare l’automazione: automatizzare, automatizzare, automatizzare. “La remediation automatizzata dovrebbe essere implementata ovunque possibile per risolvere rapidamente i problemi prima che impattino sulla produttività degli utenti”, afferma Brasen.

La remediation automatizzata consente una gestione proattiva delle esperienze digitali, molto meno invasiva per gli utenti rispetto alla tradizionale gestione reattiva.

Utilizzare controlli di sicurezza intelligenti: invece di cercare di controllare ogni minaccia in ogni momento, utilizzate l’intelligence basata sul rischio per concentrarvi sulle minacce più rilevanti e critiche. Questo non solo indirizza le risorse di sicurezza nel posto giusto, ma significa anche che la sicurezza non causa interruzioni non necessarie agli utenti per minacce non critiche.

Ancora una volta, i team di sicurezza e i lavoratori da remoto vogliono la stessa cosa: che tutti possano svolgere il proprio lavoro in modo sicuro e semplice. Automazione, intelligence basata sul rischio e attenzione alla DEX possono alleggerire il carico su sicurezza, IT e sul resto della forza lavoro da remoto.

Volete saperne di più sull’importanza di investire nella DEX? Consultate il report completo e ascoltate l’intero episodio del podcast.

7 esperti spiegano cosa significa lo shift left per i reparti IT

Fri, 18 Aug 2017 16:51:09 Z

Questo post è stato pubblicato originariamente sul blog di Cherwell, prima dell’acquisizione da parte di Ivanti.

Nella nostra recente serie di articoli, abbiamo esplorato il concetto di shift left in relazione alla gestione dei servizi. Avvicinare il più possibile la risoluzione dei problemi e altre attività all’utente finale consente all’IT service management (ITSM) di ridurre i costi ed è un buon esempio di gestione dei servizi che adotta lo shift left.

Poiché il concetto di shift left può essere usato per descrivere attività diverse in una varietà di contesti, abbiamo chiesto a esperti IT di condividere le loro riflessioni su cosa significhi adottare lo shift left e se questo approccio apporti valore alle organizzazioni. Ecco cosa hanno detto sette esperti di tecnologia sull’argomento:

Ollie O'Donoghue, Senior Research Analyst presso HfS Research

Da ex professionista del service desk, per me shift left significa abbattere i silos all’interno dell’IT per garantire che il service desk disponga delle risorse, degli accessi e degli strumenti necessari per gestire il maggior numero possibile di problemi dei clienti già al primo punto di contatto. E, ove possibile, estendere queste risorse ai clienti per offrire loro opportunità di assistenza autonoma e self-service.

L’obiettivo finale, naturalmente, è migliorare la customer experience e creare relazioni più collaborative tra l’IT e l’azienda.

Per me, l’asset più richiesto nella catena del valore dell’ITSM è la conoscenza. I clienti si rivolgono al service desk perché hanno bisogno di aiuto per risolvere qualcosa che richiede preziose competenze IT. Ed è proprio questa domanda che si estende lungo tutta la struttura di supporto IT, poiché per risolvere le sfide IT servono esperienza e competenze maggiori. È quindi qui che ho visto ottenere i risultati più significativi.

John Custy, formatore e consulente ITSM

Shift left significa avvicinare persone, processi o tecnologie al cliente, ottenendo una risoluzione più rapida, efficiente ed efficace.

Shift left dovrebbe significare molto più del semplice self-service o dell’invio di richieste via web (automazione). Shift left riguarda un servizio migliore e il raggiungimento di risultati aziendali migliori.

Lo shift left non riguarda solo la riduzione dei costi IT (in realtà, spesso trasferisce i costi al cliente), ma un impegno consapevole e coordinato per capire quale lavoro sia opportuno spostare verso un’altra area (persone o tecnologia). Spesso, lo shift left porta a una maggiore automazione laddove il valore delle persone che svolgono il lavoro è basso. Lo shift left riguarda anche la garanzia che vengano utilizzati i canali di comunicazione corretti.

Steve Buchanan, Regional Solutions Director presso Concurrency e Tech Blogger

Shift left significa soprattutto dare più autonomia al cliente.

Un vero self-service aiuta il cliente a ottenere ciò di cui ha bisogno, quando ne ha bisogno, senza ritardi né impatti sui risultati economici dell’organizzazione.

I maggiori vantaggi ottenuti nell’ITSM attraverso lo shift left riguardano il catalogo dei servizi e l’automazione. Individuate quali servizi IT possono e devono essere presenti in un portale self-service e automatizzate il più possibile i servizi offerti nel catalogo dei servizi. Il risultato sono utenti finali più soddisfatti e più tempo per l’IT da dedicare a progetti ancora più strategici per il business.

Doug Tedder, Principal Consultant, Tedder Consulting

Troppe organizzazioni utilizzano procedure di Change Management inutilmente sovraingegnerizzate e fortemente burocratiche. Per queste organizzazioni, adottare lo shift left nel Change Management rappresenta un cambiamento radicale rispetto alle pratiche centralizzate di “comando e controllo” attualmente in uso. Sebbene alla fine possa portare a una riduzione dei costi di supporto, i “costi ridotti” non possono essere il principale fattore trainante di un’iniziativa di shift left.

Al contrario, lo shift left deve riguardare obiettivi come una customer experience migliore, una maggiore capacità di risposta alle esigenze del business o l’empowerment degli utenti finali.

Ma per ottenere questi vantaggi serve un investimento iniziale nel cambiamento culturale, nel Knowledge Management e nella progettazione dei processi, oltre a manutenzione continua e miglioramento continuo per mantenere e potenziare le nuove capacità implementate.

Troy DuMoulin, VP of Research & Development, Pink Elephant

In sostanza, shift left significa sviluppare una cultura della proprietà e della responsabilità sui risultati, non solo sui compiti o sulle attività personali. Altrimenti, ogni individuo agirà secondo il principio: il mio compito è concluso e il risultato finale è un problema di qualcun altro.

Riprendendo il detto “Se lo realizzi, te ne assumi la responsabilità”, ritengo che l’ambito più importante su cui concentrare i principi dello shift left sia quello delle attività di sviluppo e build dei gruppi software e infrastrutturali.

Oggi misuriamo il nostro personale in base a singole attività legate al loro ruolo o alla loro funzione specifica. Ispirandoci alle metriche Lean e Agile, dobbiamo spostare l’attenzione su misurazioni che si concentrino sulla realizzazione del valore per il cliente in relazione a qualità, tempo e costi. Metriche come Lead Time, Cycle Time e percentuale di difetti sfuggiti sono molto più significative e innalzano la nostra prospettiva dalle attività individuali o di reparto all’esperienza del cliente end-to-end.

Claire Agutter, Director, Scopism

Per me, shift left fa parte della trasformazione continua del modo di concepire l’IT service management.

Shift left riduce i tempi di attesa e gli sprechi, quindi è un approccio molto lean. Accelera le attività, perciò può migliorare l’esperienza dei dipendenti e quella dei consumatori. Si basa sull’analisi e sull’osservazione del nostro ambiente per generare miglioramenti continui.

Ho visto i maggiori vantaggi nell’area del supporto IT. I consumatori di oggi vogliono poter cercare assistenza attraverso nuovi canali, ad esempio tramite i social media, oppure facendo ricerche online in autonomia. Le aziende che rendono disponibili le informazioni tramite questi canali riducono la necessità di chiamate all’help desk. Questo offre al consumatore un’esperienza migliore e, al tempo stesso, libera tempo del personale IT, consentendogli di concentrarsi su altre attività in grado di creare più valore.

Jonah Kowall, VP Market Development and Insights, AppDynamics

In realtà non amo particolarmente questo termine quando viene applicato al testing del software, perché non corrisponde a ciò che vediamo negli ampi cambiamenti di oggi. Più che uno spostamento, vedo nuovi progetti guidati da nuove metodologie e tecnologie.

La tendenza più importante per l’IT è essere agile e creare team multidisciplinari di product engineering.

Entrambe queste tendenze consentono di produrre software più rapidamente, migliorare in modo incrementale e dare ai membri del team la possibilità di prendere decisioni e assumersi rischi. Tutti questi elementi favoriscono risultati di business migliori, allineando l’IT e l’azienda in modo più efficace.

Come evidenziano questi esperti IT, la riduzione dei costi è solo uno dei numerosi vantaggi di un’iniziativa di shift left. Dal dare più autonomia ai clienti all’incoraggiare la responsabilità, fino al miglioramento dell’esperienza di utenti e personale IT, lo shift left rappresenta un’enorme opportunità per i reparti IT.