meeting, workplace, team, office, group, business, teamwork, conference, company, colleagues, coworkers, brainstorming, discussion, cooperation, seminar, meeting, meeting, meeting, meeting, meeting, team, team, teamwork, discussion
Foto di WebTechExperts su Pixabay

Introduzione

Introduzione del software: fasi, ruoli e formazione in azienda

L'introduzione di un nuovo software è molto più di una semplice installazione tecnica.

Perché un'introduzione strutturata del software è decisiva

L'introduzione di un nuovo software non si limita a una mera installazione tecnica. Comprende tutti i processi legati all'utilizzo di una nuova applicazione: l'implementazione tecnica, la messa in servizio e l'accettazione da parte dei collaboratori. Rientra pertanto tra i compiti più impegnativi del change management.

L'impegno richiesto da un progetto dipende dall'ampiezza dell'applicazione e dalle dimensioni dell'azienda. Chi ha pochi utenti e un ambito di applicazione ben definito può cavarsela con una pianificazione snella. Se invece sono coinvolti più reparti, sedi o partner di progetto esterni, le esigenze di coordinamento, concertazione e formazione aumentano notevolmente.

Nelle PMI svizzere e nelle imprese di costruzione si aggiungono condizioni quadro particolari: l'ufficio e il cantiere devono lavorare con gli stessi dati e vanno rispettate le prescrizioni specifiche del settore e quelle legali, come ad esempio le norme sull'imposta sul valore aggiunto nel settore edile. L'esperienza insegna che il successo non dipende solo dal software, ma anche da un'attenta preparazione, da ruoli chiaramente assegnati e dalla formazione del personale.

Fasi dell'introduzione del software: dall'analisi dello stato attuale all'ottimizzazione

Nella prassi si sono affermate fasi ricorrenti, come descritto nelle guide per le PMI svizzere: preparazione e sviluppo della strategia, analisi dello stato attuale e rilevamento dei fabbisogni, analisi dei requisiti con capitolato, ricerca di mercato e selezione del sistema, introduzione con go-live, nonché stabilizzazione e ottimizzazione continua. Non sempre si svolgono in rigorosa successione, ma offrono una struttura affidabile per pianificazione, budget e competenze.

Per i primi passi, queste guide indicano valori orientativi: circa due-quattro settimane per l'analisi dello stato attuale e il rilevamento dei fabbisogni, tre-sei settimane per l'analisi dei requisiti e quattro-otto settimane per la ricerca di mercato e la selezione del sistema. Si tratta di valori indicativi, non di scadenze rigide; a seconda delle dimensioni dell'azienda, del numero di reparti coinvolti e dell'entità della migrazione dei dati, possono subire variazioni.

L'importanza di una pianificazione accurata è dimostrata dai rischi: le guide sull'introduzione di sistemi ERP riportano, citando studi, che fino al 75% di tutti i progetti ERP supera i costi previsti o sfora i tempi. Una pianificazione realistica delle risorse e delle scadenze, unita a tempi cuscinetto calcolati consapevolmente, deve pertanto accompagnare ogni fase.

Definire con precisione obiettivi e requisiti

All'inizio ci si chiede quali risultati l'azienda intenda raggiungere con il nuovo software. Si è rivelata efficace la formulazione di obiettivi misurabili secondo il metodo SMART. Una checklist per le imprese di costruzione svizzere cita ad esempio l'obiettivo di ridurre i tempi amministrativi del 20% entro sei mesi. Tipici orientamenti per le imprese edili sono l'ottimizzazione dei processi, un miglior controllo dei costi e una comunicazione più efficiente tra ufficio e cantiere. Gli obiettivi vengono prioritizzati in base a importanza e urgenza e fissati in un catalogo di criteri per la successiva valutazione del sistema.

Alla base della definizione degli obiettivi vi è un'analisi dello stato attuale: tutti i processi aziendali esistenti vengono documentati, si individuano punti deboli e potenziali di ottimizzazione e, attraverso colloqui con i collaboratori di tutti i reparti, si ottiene un quadro completo delle procedure odierne. Chi salta questo passo, in seguito valuta i sistemi senza una base di confronto affidabile.

Dall'analisi dello stato attuale scaturisce il capitolato. Esso distingue tra requisiti funzionali (cosa deve saper fare il sistema?), requisiti tecnici (ad es. hardware, interfacce e prestazioni) e requisiti organizzativi (ad es. supporto, formazione e manutenzione). All'interno di questi gruppi si distingue tra requisiti obbligatori, auspicabili e facoltativi. Bisogna inoltre tenere in considerazione i requisiti futuri, il potenziale di crescita, le particolarità specifiche del settore e le prescrizioni normative.

Obiettivi e requisiti definiti con cura hanno un duplice effetto: rendono comprensibile la selezione del sistema e forniscono la base per la successiva formazione, poiché contenuti ed esercizi possono essere derivati direttamente dai processi prioritizzati.

Ruoli nel progetto: chi decide, chi testa, chi forma?

All'inizio si pianificano le risorse in modo realistico: tempo, personale e budget. A tal fine sono necessari un team di progetto con rappresentanti di tutti i reparti rilevanti e una direzione di progetto con sufficienti poteri decisionali. In mancanza di competenza decisionale, la direzione di progetto deve ricorrere a continue consultazioni e il progetto perde slancio.

I reparti specialistici contribuiscono con i loro requisiti concreti. In un'impresa di costruzione si tratta tipicamente della direzione di progetto per i requisiti relativi a pianificazione e calcolo, della conduzione del cantiere per l'utilizzo di applicazioni mobili in cantiere e il semplice controllo dei rapporti giornalieri, e della contabilità per i requisiti relativi a fatturazione e controlling.

All'IT spetta un ruolo di mediazione. Lo studio Swiss IT 2025 mostra che la sicurezza informatica e la compliance sono il compito più importante per il 67% delle aziende, seguite a ruota dal supporto ai reparti specialistici nelle attività quotidiane con il 47%. I dipartimenti IT non devono quindi limitarsi a fornire soluzioni tecniche, ma agire anche come mediatori e coinvolgere attivamente i reparti specialistici nelle iniziative.

Come anello di congiunzione tra progetto e personale fungono i key user o champion: collaboratori provenienti dalla routine operativa che conoscono il sistema in una fase precoce, supportano i colleghi e riportano al progetto i feedback dalla pratica. I percorsi decisionali, le responsabilità per i test e la questione di chi formerà gli altri in seguito dovrebbero essere chiariti e fissati per iscritto fin dall'inizio.

Big Bang o introduzione graduale: scegliere la strategia

Con la strategia del big bang, la conversione per l'intera azienda avviene in una data fissa. I dispositivi terminali – tablet, laptop, smartphone – vengono generalmente dotati del nuovo software in un fine settimana o in altri periodi di non lavoro; tutti i reparti e le sedi lavorano da quel momento in poi contemporaneamente con il nuovo programma. Il vantaggio è evidente: tutti utilizzano lo stesso sistema e non sorgono problemi nello scambio di dati tra la vecchia e la nuova soluzione. Inoltre, i costi sono di norma inferiori, poiché non è necessario pagare e mantenere due applicazioni. Il più grande svantaggio: tutti i dipendenti devono adattarsi in un colpo solo, il che può causare problemi di inserimento e accettazione.

Con il metodo iterativo, l'introduzione avviene passo dopo passo. Inizialmente solo determinati collaboratori o reparti lavorano con il nuovo programma; in caso di successo, la conversione viene estesa gradualmente all'intera azienda. Il vecchio e il nuovo software funzionano inizialmente in parallelo, finché l'applicazione utilizzata finora non viene disattivata. Nel settore edile può inoltre essere sensato estendere l'utilizzo ai partner di progetto, purché questi siano disposti a farlo.

La scelta dipende da diversi criteri: dalle dimensioni e dalla struttura dell'azienda, dalla criticità dei processi interessati, dalla disponibilità di risorse interne per test e formazione, nonché dalla capacità di migrare dati e interfacce. Un esercizio parallelo aumenta la sicurezza, ma richiede un doppio impegno in fase di inserimento e controllo durante il periodo di transizione. Chi valuta realisticamente il carico per il personale sceglie la strategia più adatta alla propria azienda, non quella che corrisponde a un modello ideale teorico.

Formazione e sviluppo delle competenze: dal key user a tutto il personale

La formazione non inizia solo al go-live. Per un'introduzione riuscita è decisiva l'accettazione da parte dei collaboratori, per questo le persone coinvolte vengono integrate fin dall'inizio. Workshop o sondaggi sono adatti a rilevare le aspettative di tutti i partecipanti e a dedurne un concetto formativo. Già nel capitolato, formazione, supporto e manutenzione vengono definiti come requisiti organizzativi.

Si sono rivelate efficaci le formazioni vicine ai ruoli e ai processi: ogni gruppo apprende utilizzando le procedure che impiega effettivamente nella routine quotidiana – la conduzione del cantiere con l'inserimento mobile in cantiere, la contabilità con la fatturazione e le valutazioni, la direzione di progetto con la pianificazione e il calcolo. I key user o i champion fungono da moltiplicatori: vengono formati per primi e in modo approfondito, per poi accompagnare i colleghi nelle attività quotidiane.

Dopo il go-live è necessario un accompagnamento continuo: supporto raggiungibile, brevi sessioni di formazione supplementare, materiale didattico comprensibile e persone di contatto per le domande. L'introduzione non si conclude con la data della formazione, ma solo quando il nuovo software viene utilizzato in modo affidabile nella routine. Una checklist per le imprese di costruzione svizzere elenca pertanto la formazione del personale come punto a sé stante, accanto alla definizione degli obiettivi, al chiarimento dei requisiti e alla pianificazione del budget e dei tempi.

Checklist per l'introduzione riuscita del software nelle PMI svizzere

  • Definire obiettivi misurabili (metodo SMART)
  • Redigere il capitolato con requisiti obbligatori, auspicabili e facoltativi
  • Selezionare e integrare tempestivamente i key user o i champion
  • Pianificare una formazione vicina ai ruoli e ai processi
  • Garantire supporto e formazione supplementare dopo il go-live
  • Verificare regolarmente l'utilizzo e la qualità dei dati

Comunicazione, accettazione ed evitare la shadow IT

L'accettazione non nasce da un'imposizione, ma dal coinvolgimento. Chi informa tempestivamente i collaboratori interessati, confronta le aspettative e illustra apertamente l'utilità concreta per il proprio lavoro, riduce le resistenze. I feedback del personale vanno presi sul serio e fatti confluire nelle decisioni; le domande aperte sul "perché" vengono risposte, invece di essere ignorate.

L'IT assume in questo frangente un ruolo di mediatore tra i reparti specialistici e la tecnica. Che questo ruolo stia guadagnando importanza lo dimostra lo studio Swiss IT 2025: accanto alla sicurezza informatica e alla compliance, il supporto ai reparti specialistici nelle attività quotidiane è tra i compiti più importanti dei dipartimenti IT. Se l'IT interno non viene coinvolto nelle nuove iniziative, si crea rapidamente una shadow IT incontrollata, favorita dal fatto che oggi molte soluzioni possono essere ottenute direttamente come servizio SaaS e messe a disposizione dei dipendenti senza passare per l'IT.

Un'azienda contrasta questo fenomeno con regole chiare: una panoramica delle applicazioni autorizzate, punti di contatto definiti per le nuove esigenze e un canale semplice attraverso il quale suggerimenti di miglioramento e lamentele giungono al team di progetto. In questo modo i reparti specialistici e l'IT rimangono in dialogo e i requisiti della routine quotidiana emergono tempestivamente, invece di dover essere corretti a posteriori.

Dopo il go-live: verificare l'utilizzo, affinare i processi

Con il go-live inizia la vera prova del fuoco. Si è rivelato efficace il seguente approccio: raccogliere feedback nel team, chiarire i problemi con il fornitore, adattare i processi di lavoro e verificare gli obiettivi definiti all'inizio. Se emerge che un processo funziona in modo diverso nella pratica rispetto a quanto pianificato, non si piega il software, ma si mette in discussione e si affina il processo.

L'ottimizzazione continua non è un'appendice, ma parte integrante dell'introduzione del software. Nei modelli di procedura consolidati costituisce l'ultima fase dopo preparazione, selezione e introduzione. Ciò include verificare regolarmente l'utilizzo, consultare le valutazioni, seguire i punti aperti del supporto e attuare i miglioramenti in piccoli passi comprensibili.

Una checklist compatta per il periodo successivo al go-live: – Confrontare gli obiettivi della fase iniziale con l'utilità effettiva. – Raccogliere e prioritizzare i feedback di tutti i reparti coinvolti. – Chiarire con il fornitore i punti tecnici e organizzativi ancora aperti. – Adattare processi e responsabilità alle nuove modalità di lavoro. – Mantenere aggiornati key user e supporto, revisionare il materiale didattico. – Verificare a intervalli fissi l'utilizzo e la qualità dei dati. – Definire e fissare le scadenze per i prossimi passi di ottimizzazione.

Altro su Introduzione