Digitalizzare un processo aziendale: analisi, requisiti e scelta degli strumenti

Per digitalizzare un processo aziendale bisogna prima comprenderne il funzionamento attuale, definire il risultato atteso, progettare il nuovo flusso e tradurre le esigenze operative in requisiti verificabili. La scelta dello strumento viene dopo: un software può sostenere un processo ben progettato, ma difficilmente può correggere da solo attività, responsabilità e regole che non sono state chiarite.

Questo metodo permette di affrontare la digitalizzazione come un progetto organizzativo e tecnologico, non come la semplice sostituzione di documenti cartacei o fogli di calcolo.

Che cosa significa digitalizzare un processo aziendale

Un processo aziendale è un insieme coordinato di attività che, partendo da un evento o da una richiesta, produce un risultato. Può riguardare, per esempio, l’approvazione di un acquisto, la gestione di una richiesta interna, l’inserimento di un nuovo cliente o la preparazione di un’offerta.

Digitalizzare un processo significa riprogettarne almeno una parte utilizzando dati, strumenti e flussi digitali. L’intervento può rendere le informazioni più accessibili, ridurre passaggi manuali, aumentare la tracciabilità oppure facilitare il coordinamento tra persone e sistemi.

È utile distinguere tre livelli:

• dematerializzare significa trasformare un supporto fisico in un documento digitale;
• digitalizzare significa modificare il modo in cui attività, dati e responsabilità vengono gestiti;
• automatizzare significa affidare a una regola o a un sistema l’esecuzione di determinate attività, entro condizioni e limiti definiti.

La scansione di un modulo cartaceo, quindi, non modifica necessariamente il processo. Allo stesso modo, trasferire in un software gli stessi passaggi ridondanti può rendere digitale un’inefficienza senza eliminarla.

Da quale processo iniziare

La digitalizzazione dei processi aziendali dovrebbe partire da un problema osservabile, non dalla disponibilità di una piattaforma. Prima di avviare il progetto occorre chiarire che cosa non funziona e quale risultato si vuole ottenere.

Individuare il problema concreto

I segnali più frequenti sono:

• tempi di attraversamento eccessivi;
• attività o inserimenti duplicati;
• errori e rilavorazioni ricorrenti;
• dati distribuiti tra email, documenti e applicazioni diverse;
• passaggi approvativi difficili da ricostruire;
• assenza di uno stato aggiornato della pratica;
• dipendenza da informazioni conosciute solo da alcune persone;
• difficoltà nel misurare carichi di lavoro e risultati.

Un disagio generico, come “il processo è troppo lento”, non è ancora un obiettivo progettuale. Bisogna capire quali passaggi generano attese, quali casi vengono coinvolti e come viene misurata la situazione iniziale.

Definire obiettivo e perimetro

Il perimetro stabilisce dove inizia e dove termina l’analisi. Deve identificare:

• l’evento che avvia il processo;
• il risultato che ne determina la conclusione;
• le unità e le persone coinvolte;
• i processi collegati;
• i dati e i documenti scambiati;
• i vincoli organizzativi, tecnici o normativi conosciuti.

Quando l’azienda non ha ancora individuato i processi prioritari o deve valutare in modo più ampio organizzazione, strumenti e maturità digitale, può essere opportuno partire da un digital assessment. L’analisi descritta in questo articolo riguarda invece un processo già selezionato.

Mappare il processo attuale AS-IS

Il processo AS-IS rappresenta il modo in cui il lavoro viene svolto oggi. La mappatura non deve descrivere soltanto la procedura teorica: deve ricostruire il comportamento reale, comprese attività informali, attese, eccezioni e strumenti utilizzati.

Ricostruire attività, ruoli e passaggi

Per ogni fase è utile rilevare:

• chi avvia l’attività;
• chi la esegue e chi la approva;
• quali informazioni riceve;
• quali dati produce o modifica;
• quali strumenti utilizza;
• quanto tempo richiede l’attività e quanto rimane in attesa;
• quali condizioni determinano il passaggio successivo.

La rappresentazione può iniziare con uno schema semplice. Per processi complessi si può utilizzare anche BPMN, acronimo di Business Process Model and Notation. L’Object Management Group pubblica la specifica BPMN 2.0.2, pensata per rappresentare attività, eventi, decisioni e scambi tra soggetti. La notazione può aiutare a rendere il modello uniforme, ma non è obbligatoria per analizzare un processo: il livello di formalizzazione deve essere proporzionato alla complessità del progetto.

Rilevare eccezioni e attività informali

Le eccezioni sono particolarmente importanti perché spesso determinano una parte rilevante del lavoro. Una richiesta incompleta, un’approvazione urgente, un dato incoerente o l’indisponibilità temporanea di un sistema possono attivare percorsi diversi da quello standard.

Ignorare questi casi produce un workflow digitale apparentemente lineare, ma incapace di gestire il lavoro reale. Per ogni eccezione occorre capire:

• quanto frequentemente si verifica;
• chi decide come trattarla;
• quali informazioni sono necessarie;
• se può essere standardizzata;
• quando deve intervenire una persona.

Coinvolgere gli stakeholder

La ricostruzione non dovrebbe essere affidata a una sola prospettiva. La direzione conosce obiettivi e vincoli; il responsabile presidia il processo; gli utenti operativi conoscono passaggi, difficoltà ed eccezioni; l’IT valuta sistemi, dati e integrazioni.

Interviste, osservazione delle attività e analisi delle evidenze disponibili aiutano a distinguere il processo dichiarato da quello effettivamente utilizzato. Anche il Service Manual del Government Digital Service raccomanda di comprendere come gli utenti svolgono oggi le attività, quali problemi incontrano e di che cosa hanno bisogno prima di progettare una soluzione.

Progettare il processo futuro TO-BE

Il processo TO-BE descrive come dovrebbe funzionare il flusso dopo l’intervento. Non consiste nella semplice copia digitale dell’AS-IS: serve a decidere quali attività conservare, modificare, eliminare o controllare in modo diverso.

Definire che cosa deve cambiare

La progettazione deve chiarire:

• quali passaggi non producono valore o duplicano informazioni;
• quali attività possono essere semplificate o accorpate;
• quali decisioni richiedono un’approvazione;
• quali informazioni devono essere disponibili in ogni fase;
• quali responsabilità devono essere assegnate;
• quali eventi devono essere registrati per garantire la tracciabilità;
• quali collegamenti sono necessari con altri processi e sistemi.

L’obiettivo non è rendere automaticamente digitale ogni attività. Alcuni passaggi possono richiedere giudizio professionale, confronto o responsabilità decisionale. In questi casi lo strumento dovrebbe fornire informazioni e controlli, lasciando esplicita la supervisione umana.

Distinguere digitalizzazione e automazione

Un workflow può essere digitalizzato anche se alcune decisioni rimangono manuali. L’automazione diventa appropriata quando input, regole, condizioni ed eccezioni sono sufficientemente chiari.

Prima di automatizzare un’attività occorre verificare:

• se le regole sono stabili e condivise;
• se i dati necessari sono disponibili e affidabili;
• se gli errori possono essere individuati;
• se sono previste escalation e correzioni;
• chi conserva la responsabilità del risultato.

L’eventuale impiego dell’Intelligenza Artificiale richiede una valutazione ulteriore e specifica. Non tutti i processi digitalizzabili sono automaticamente adatti all’AI.

Raccogliere i requisiti per la digitalizzazione

I requisiti traducono il processo futuro in condizioni che la soluzione dovrà rispettare. Devono essere comprensibili sia per chi svolge il lavoro sia per chi dovrà configurare, integrare o fornire gli strumenti.

Lo standard ISO/IEC/IEEE 29148:2018 riguarda i processi e gli elementi informativi dell’ingegneria dei requisiti per sistemi, software e servizi. La versione 2018 risulta ancora pubblicata e confermata nel 2024, ma ISO segnala che è in revisione e destinata a essere sostituita. Per un progetto aziendale può costituire un riferimento metodologico, senza rendere necessario applicarne integralmente la struttura.

Requisiti funzionali

I requisiti funzionali descrivono che cosa deve permettere di fare il nuovo workflow. Per esempio:

• registrare una richiesta con campi obbligatori;
• assegnarla automaticamente al responsabile corretto;
• richiedere un’approvazione oltre una determinata soglia;
• inviare una notifica quando la pratica cambia stato;
• conservare la cronologia delle modifiche;
• generare un riepilogo per il controllo periodico.

Requisiti relativi a dati e integrazioni

Per ciascun dato è necessario stabilire:

• da quale fonte proviene;
• chi può inserirlo o modificarlo;
• quale sistema ne rappresenta la fonte principale;
• quando deve essere aggiornato;
• con quali altre applicazioni deve essere condiviso;
• come gestire dati mancanti, duplicati o incoerenti.

Questa analisi evita che applicazioni diverse producano versioni contrastanti della stessa informazione. Le integrazioni devono essere definite attraverso dati, frequenze, responsabilità e gestione degli errori, non soltanto indicando i nomi dei software coinvolti.

Requisiti non funzionali e organizzativi

Un processo può soddisfare le funzioni previste e risultare comunque difficile da utilizzare o gestire. Occorre quindi considerare anche:

• ruoli e livelli di accesso;
• usabilità e accessibilità;
• tempi di risposta attesi;
• sicurezza e protezione dei dati;
• continuità operativa;
• tracciabilità e conservazione delle informazioni;
• formazione degli utenti;
• assistenza e gestione delle anomalie.

Privacy, sicurezza, obblighi di conservazione e requisiti normativi devono essere verificati con competenze adeguate al settore e ai dati trattati.

Rendere i requisiti verificabili

Un requisito come “il sistema deve essere semplice e veloce” non indica come valutarne il rispetto. È preferibile definire soggetto, azione, condizione e risultato atteso.

Per esempio, invece di richiedere genericamente una migliore tracciabilità, si può stabilire che ogni cambiamento di stato debba registrare data, utente e motivazione. La formulazione definitiva dipenderà dal contesto, ma il requisito deve consentire una verifica durante il test.

Quando valutare gli strumenti digitali

La valutazione degli strumenti può iniziare quando sono disponibili almeno:

• perimetro e obiettivo del processo;
• mappa AS-IS;
• proposta TO-BE;
• utenti, ruoli e responsabilità;
• requisiti prioritari;
• dati e integrazioni necessarie;
• vincoli tecnici, economici e organizzativi;
• criteri con cui verificare il risultato.

Questi elementi permettono di confrontare le soluzioni sulla base del processo reale. Senza requisiti, una dimostrazione commerciale rischia di concentrare l’attenzione sulle funzioni più visibili della piattaforma e non sulla sua capacità di gestire attività, eccezioni e integrazioni necessarie.

In questa fase non si tratta ancora di stabilire quale sia il miglior software in assoluto. Occorre verificare quale soluzione sia coerente con il processo, con le risorse disponibili e con l’architettura digitale dell’organizzazione. La valutazione comparativa dei software richiede un approfondimento dedicato.

Sperimentare prima di estendere il nuovo processo

Quando il progetto lo consente, un perimetro pilota permette di verificare le ipotesi prima di estendere il nuovo workflow a tutta l’organizzazione.

Definire il pilota

Il test dovrebbe specificare:

• utenti e unità coinvolti;
• tipologie di casi trattati;
• durata della sperimentazione;
• responsabile della raccolta dei problemi;
• criteri per decidere se procedere, modificare o interrompere.

La logica è coerente con l’approccio descritto dal Government Digital Service per la fase alpha: costruire quanto basta per testare le ipotesi più rischiose, verificare vincoli e integrazioni e decidere quali soluzioni meritino di essere sviluppate ulteriormente.

Testare anche le eccezioni

Un test limitato al percorso ideale fornisce un quadro incompleto. È necessario includere richieste incomplete, dati errati, assenze, rifiuti, autorizzazioni, indisponibilità dei sistemi e modifiche successive all’avvio.

Il test dovrebbe inoltre verificare se ruoli e istruzioni risultano comprensibili agli utenti senza dipendere costantemente dal gruppo di progetto.

Preparare l’adozione

La gestione del cambiamento comprende almeno:

• comunicazione delle ragioni del progetto;
• formazione proporzionata ai ruoli;
• assistenza durante la fase iniziale;
• raccolta strutturata dei feedback;
• aggiornamento di procedure e responsabilità;
• monitoraggio dell’utilizzo effettivo.

Un workflow tecnicamente corretto può non produrre il risultato atteso se gli utenti continuano a utilizzare canali paralleli o non comprendono le nuove responsabilità.

Come misurare il risultato

Gli indicatori devono essere scelti prima dell’implementazione, insieme alla situazione iniziale da utilizzare come termine di confronto. Senza una baseline non è possibile stabilire con sufficiente attendibilità se la variazione osservata dipenda dal nuovo processo.

Il Service Standard del Government Digital Service collega la definizione del successo alla scelta di metriche capaci di mostrare se il servizio sta risolvendo il problema e di sostenere le decisioni di miglioramento.

I KPI devono essere pochi, pertinenti e collegati all’obiettivo. Un aumento degli accessi al sistema, per esempio, non dimostra da solo che il processo sia diventato più efficace.

Gli errori da evitare

• Partire dal software: le funzioni della piattaforma finiscono per determinare il processo prima che siano chiarite le esigenze.
• Digitalizzare un processo non compreso: passaggi inutili e responsabilità ambigue vengono trasferiti nel nuovo sistema.
• Ascoltare una sola prospettiva: direzione, responsabili, utenti e IT osservano aspetti diversi dello stesso flusso.
• Ignorare le eccezioni: il workflow funziona soltanto nei casi ideali.
• Usare requisiti generici: fornitori e utenti possono interpretarli in modo differente.
• Trascurare dati e integrazioni: il processo genera duplicazioni o informazioni non allineate.
• Automatizzare decisioni non formalizzate: il sistema applica regole incomplete o non condivise.
• Estendere la soluzione senza test: problemi limitati diventano difficili da correggere dopo il rilascio generale.
• Misurare senza una baseline: manca un riferimento attendibile per valutare il cambiamento.
• Trascurare formazione e adozione: gli utenti mantengono strumenti e procedure parallele.

Checklist prima di avviare la digitalizzazione

• Il problema è descritto attraverso evidenze osservabili?
• Il processo ha un inizio, una fine e un perimetro chiari?
• Sono stati coinvolti responsabili e utenti operativi?
• Il processo AS-IS comprende attività, attese ed eccezioni?
• Il processo TO-BE chiarisce che cosa deve cambiare?
• Ruoli, responsabilità e approvazioni sono definiti?
• I requisiti sono comprensibili e verificabili?
• Sono state individuate fonti, responsabilità e qualità dei dati?
• Le integrazioni necessarie sono state descritte?
• Sono previsti controlli, escalation e interventi umani?
• Esistono KPI e dati iniziali confrontabili?
• È possibile sperimentare la soluzione su un perimetro limitato?
• Sono previste formazione, assistenza e raccolta dei feedback?

Quando può essere utile un supporto esterno

Un affiancamento esterno può essere utile quando il processo attraversa più funzioni, i requisiti sono difficili da formalizzare, sono coinvolti diversi fornitori oppure manca una figura interna incaricata di coordinare analisi, decisioni e implementazione.

La consulenza Tech & Digital di DieSSe Ingegneria Digitale parte dall’analisi di processi, strumenti e organizzazione per definire requisiti, priorità e attività da coordinare. Le eventuali implementazioni specialistiche vengono definite o affidate in funzione del perimetro del progetto.

Digitalizzare un processo aziendale significa quindi collegare organizzazione e tecnologia. Lo strumento è una conseguenza delle decisioni prese su obiettivi, attività, dati e responsabilità: non dovrebbe esserne il punto di partenza.

Domande frequenti

Qual è il primo passo per digitalizzare un processo aziendale?

Il primo passo è definire il problema, l’obiettivo e il perimetro del processo. Successivamente bisogna ricostruire il flusso AS-IS, coinvolgendo responsabili e utenti operativi prima di progettare la soluzione futura.

Qual è la differenza tra digitalizzazione e automazione?

La digitalizzazione modifica il modo in cui attività, dati e responsabilità vengono gestiti mediante strumenti digitali. L’automazione affida invece al sistema l’esecuzione di attività o decisioni basate su regole definite. Un processo può essere digitalizzato senza essere completamente automatizzato.

Chi deve partecipare alla raccolta dei requisiti?

Devono essere coinvolti almeno il responsabile del processo, gli utenti che svolgono le attività, le figure che approvano o controllano il risultato e, quando necessario, il reparto IT. Altri stakeholder dipendono dai dati, dai sistemi e dai processi collegati.

Quando conviene scegliere il software?

La selezione dovrebbe iniziare dopo aver definito processo AS-IS, processo TO-BE, requisiti, dati, integrazioni, vincoli e criteri di successo. Questi elementi permettono di confrontare gli strumenti sulla base delle esigenze reali.

Come si misura il risultato della digitalizzazione?

Occorre definire una baseline e pochi KPI coerenti con l’obiettivo, come tempi di attraversamento, rilavorazioni, completezza dei dati, tracciabilità e utilizzo effettivo del workflow. I valori devono essere confrontati su periodi e casi omogenei.

Fonti

• Object Management Group – Business Process Model and Notation 2.0.2.
• ISO – ISO/IEC/IEEE 29148:2018, Requirements engineering.
• ISO – ISO 9000 family, Quality management.
• Government Digital Service – Learning about users and their needs.
• Government Digital Service – How the alpha phase works.
• Government Digital Service – Define what success looks like and publish performance data.

Analizziamo insieme esigenze e priorità. Richiedi un primo confronto per valutare processo, requisiti e percorso di digitalizzazione.