Digitalizzare le richieste interne: approvazioni, spese e ferie senza carta

TL;DR (Quick Summary)

Per una PMI, digitalizzare le richieste interne significa far passare apertura, controllo, approvazione, esito e tracciabilità dentro un unico flusso. Serve per processi ricorrenti come ferie, note spese e richieste di acquisto, così responsabilità, tempi ed esiti restano visibili. Il modulo online funziona solo se il perimetro è chiaro e carta, email e chat parallele vengono chiuse davvero.

• Partire da un perimetro ristretto, con processi frequenti e semplici
• Disegnare il flusso prima dello strumento, con ruoli, dati e scadenze
• Gestire eccezioni e deleghe senza scorciatoie fuori controllo
• Configurare regole, evidenze e conservazione per una traccia reperibile
• Implementare per fasi, con taglio netto ai canali paralleli
• Bloccare le approvazioni fuori banda, con validità solo nel sistema
• Verificare la stabilità del processo prima di estenderlo.

Takeaway: Una richiesta interna è davvero digitale quando approvazione, esito, allegati e responsabilità restano visibili nello stesso flusso. Se i vecchi canali restano validi, tracciabilità e responsabilità si disperdono.

Il rischio operativo è quasi sempre lo stesso: la richiesta parte con un modulo, un’email o un messaggio, poi l’approvazione passa altrove, qualcuno dimentica un allegato, un responsabile è assente e alla fine nessuno sa quale esito valga davvero. Conviene partire con pochi flussi, disegnarli bene prima dello strumento e chiudere i canali paralleli fin dal pilota.

Per “richieste interne” si intendono processi ricorrenti come ferie, permessi, note spese, richieste di acquisto o piccole approvazioni amministrative. In Bitrix24, per esempio, un flusso di lavoro può riunire apertura, controllo, approvazione, esito e registro delle attività in un punto accessibile anche da smartphone.

Partire da un perimetro ristretto: scegliere quali richieste digitalizzare per prime

Un primo rilascio che include ferie, spese, acquisti, straordinari, beni aziendali e trasferte tende ad accumulare troppe eccezioni. Le decisioni rallentano e ricompaiono richieste come “intanto mandamelo via email”.

È preferibile partire da una mappatura rapida dell’esistente. Si elencano le richieste oggi gestite su carta, PDF, email o chat e, per ciascuna, si annotano quattro elementi: volume, frequenza, rischio e facilità di standardizzazione. In questo modo emergono i flussi più frequenti, quelli che creano più rincorse e quelli che si prestano a regole chiare.

Per una PMI, l’ordine pratico è spesso questo:

• Ferie e permessi: alto volume, dati abbastanza standard, beneficio immediato
• Note spese: più variabili, ma con forte bisogno di allegati e tracciabilità
• Richieste di acquisto o approvazioni interne a basso rischio: utili se si definiscono bene soglie e responsabili.

I casi con una forte componente contrattuale, eccezioni molto frequenti o passaggi approvativi diversi tra i reparti vanno rimandati. Se entrano nel primo blocco, il pilota si trasforma in una trattativa continua sulle regole.

Il primo rilascio deve avere un obiettivo operativo preciso e risultati verificabili:

• meno scambi fuori processo
• tempi di approvazione più brevi
• tracciabilità completa di invio, approvazione e stato finale
• uso semplice da mobile per chi richiede e per chi approva.

Kit operativo: moduli, ruoli e flussi approvativi digitali

Inserisci il tuo indirizzo e-mail per ricevere una guida completa e dettagliata passo dopo passo

Dichiaro di aver letto e compreso l'Informativa sulla privacy di Bitrix24

Disegnare il flusso prima di scegliere lo strumento

Il flusso va definito prima della piattaforma. In caso contrario, le impostazioni dello strumento finiscono per determinare ruoli e passaggi che l’organizzazione non ha ancora deciso.

Per ogni processo vanno documentati almeno questi elementi:

• Chi apre la richiesta: dipendente, responsabile, amministrazione, HR
• Quali dati sono obbligatori: date, importo, causale, centro di costo, tipo di spesa, allegati
• Chi approva: responsabile diretto, secondo livello, funzione amministrativa o HR
• Entro quando: senza introdurre livelli di servizio complessi, ma con tempi attesi chiari
• Quale esito finale viene registrato: approvata, rifiutata, annullata, restituita per correzione.

La scelta del flusso dipende dal percorso decisionale: in Bitrix24, per esempio, si può distinguere tra processi sequenziali e processi basati sugli stati. I blocchi emergono soprattutto nelle condizioni che cambiano il percorso: soglie di importo, centri di costo, allegati obbligatori, urgenze, rifiuti motivati, modifiche dopo l’invio e annullamenti. Per esempio, una richiesta di acquisto può seguire tre soglie: fino a 500 euro compresi, approva il responsabile diretto; oltre 500 e fino a 2.000 euro, interviene anche l’amministrazione; oltre 2.000 euro, servono un secondo livello e la direzione finanziaria. Se questi punti restano vaghi, il team inizierà a gestirli a voce o via chat.

Un accorgimento utile è rappresentare il processo con una tabella semplice:

Il requisito mobile va previsto qui, non come aggiunta finale. L’invio della richiesta, il caricamento dei giustificativi, le notifiche e l’approvazione devono funzionare bene da smartphone. Se approvare o caricare uno scontrino richiede troppi passaggi, le persone torneranno ai canali informali.

Gestire eccezioni e deleghe senza rompere la governance

Le eccezioni reali vanno censite e gestite nel flusso. Se restano fuori dalle regole, rientrano come scorciatoie informali.

Conviene raccogliere le eccezioni reali che capitano già oggi: spese fuori dalle regole interne ma necessarie, ferie sovrapposte nello stesso team, approvazioni urgenti quando il responsabile non è disponibile, richieste retroattive come una spesa caricata in ritardo o un permesso comunicato dopo.

Per ciascuna eccezione serve una scelta netta: il sistema deve aprire un percorso alternativo approvato, bloccare la richiesta o restituirla al richiedente per correzione. Le eccezioni ammesse dovrebbero richiedere una motivazione obbligatoria e, quando serve, un allegato giustificativo.

• Percorso alternativo se l’eccezione è ammessa, ma richiede un livello diverso di controllo
• Blocco se la richiesta non può proseguire per vincoli chiari delle regole interne o dati mancanti non sanabili
• Ritorno al richiedente se basta correggere informazioni, allegati o date.

Le deleghe richiedono la stessa attenzione. Nelle PMI il responsabile assente o non disponibile può diventare un collo di bottiglia. Per evitare approvazioni informali, si configurano deleghe temporanee e sostituti con tre regole:

• Periodo di validità: data di inizio e fine della delega
• Ambito: processi o soglie coperti dalla delega
• Tracciamento: il sistema deve mostrare che l’azione è stata eseguita da un delegato per conto del titolare.

Una delega non deve valere per ogni decisione. Un sostituto può approvare ferie e permessi, ma non una spesa sopra una certa soglia; oppure può sbloccare richieste urgenti, ma non autorizzare richieste retroattive. Una regola operativa possibile è questa: dopo due giorni lavorativi senza risposta, il flusso invia un promemoria e riassegna o inoltra la richiesta secondo un percorso approvato in anticipo. I tempi di esecuzione del flusso vanno configurati tenendo conto anche di orari e fusi orari.

"La possibilità di avere statistiche in tempo reale sull'andamento delle vendite, sulle performance individuali e la disponibilità di una vasta gamma di altri dati ci ha permesso di ottimizzare le risorse e orientarci verso processi di successo, scartando altre opzioni meno adatte."

Proprietario, Emiliano Vicaretti

SunPark Srl

Registrati gratuitamente

Configurare regole, evidenze e conservazione per avere una traccia di controllo affidabile

Se un processo di approvazione non lascia prove ordinate, prima o poi qualcuno dovrà ricostruire tutto da email, schermate e allegati sparsi. È lo scenario da evitare, soprattutto per spese, dati personali dei lavoratori e richieste che possono essere oggetto di verifica interna o esterna.

Una traccia di controllo, o audit trail, è la registrazione completa degli eventi del processo. Il sistema dovrebbe conservare almeno:

• chi ha inviato, approvato o rifiutato la richiesta
• data e ora di ogni azione
• commenti inseriti nei passaggi decisionali
• allegati caricati
• versioni della richiesta se modificata
• passaggi di stato, ad esempio da aperta a in approvazione, poi approvata o restituita.

La traccia facilita anche la gestione quotidiana. Per una nota spese ferma mostra il punto del blocco; per una richiesta di ferie contestata indica chi l’ha autorizzata e quando; dopo una modifica permette di ricostruire che cosa sia cambiato.

L’archiviazione operativa e la conservazione a norma rispondono a esigenze diverse. Un repository con ricerca e storico facilita il lavoro quotidiano, ma per documenti fiscali, amministrativi o HR può essere necessario un processo che garantisca integrità, reperibilità, ruoli, responsabilità ed eventuale firma digitale o marcatura temporale.

Le Linee Guida AgID sulla formazione, gestione e conservazione dei documenti informatici sono il riferimento da considerare quando il documento deve mantenere valore probatorio nel tempo, oltre a restare reperibile. La verifica deve chiarire quali documenti conservare, in quale forma e per quanto tempo, secondo le regole applicabili al caso.

I controlli minimi di governance dovrebbero essere presenti fin dal pilota:

• Permessi per ruolo: chi presenta la richiesta non deve poterla approvare, salvo casi esplicitamente previsti
• Storico non modificabile: i log devono restare intatti anche se la richiesta evolve
• Esportazione dei log: utile per verifiche, audit interni o passaggi ad altri sistemi
• Repository unico: niente prove distribuite tra email, cartelle locali e chat.

Implementare per fasi con un pilota che elimini davvero carta ed email parallele

Un pilota è utile quando mette in produzione un processo reale e verifica se regge senza appoggiarsi ai vecchi canali.

La sequenza del pilota è:

1. scegliere un solo processo
2. coinvolgere un reparto pilota
3. limitare il numero di approvatori
4. correggere colli di bottiglia e casi non coperti
5. estendere gradualmente a reparti o processi successivi.

Partire con troppi reparti e troppe regole rende difficile capire se il blocco dipenda dal disegno del flusso, dai dati mancanti, dalle notifiche o dagli approvatori che non usano il sistema.

La migrazione dal vecchio al nuovo va gestita senza ambiguità. Un possibile messaggio di avvio è: “Dal [data di avvio], le richieste di ferie del reparto vendite si aprono solo nel nuovo flusso di lavoro; email e chat non saranno considerate valide.” Servono tre decisioni operative:

• Data di avvio: da quel giorno il nuovo canale è l’unico valido
• Canale ufficiale unico: richieste accettate solo nel sistema, non via modulo cartaceo o email
• Chiusura dei vecchi ingressi: moduli disattivati e caselle presidiate con una risposta automatica. Testo possibile: “Questa casella non riceve più richieste ferie. Apri la richiesta nel nuovo sistema; per le urgenze, seleziona Urgente.”

Se restano attivi il modulo PDF, la casella condivisa e l’approvazione eccezionale in chat, non è possibile valutare il nuovo processo: una parte delle richieste continua a sfuggire alla misurazione.

Per il pilota bastano poche integrazioni essenziali, ben fatte:

• anagrafiche utenti
• organigramma o relazione responsabile-collaboratore
• centri di costo se influenzano il percorso di approvazione
• notifiche affidabili per invio, approvazione, rifiuto e richieste da correggere.

Le automazioni più complesse possono aspettare: prima vanno corretti i dati di base, i ruoli e le notifiche.

Bloccare le approvazioni fuori banda con regole operative e adozione mirata

Manager e dipendenti continueranno a usare email, chat, telefonate e messaggi vocali se il nuovo flusso è più complicato dei vecchi canali o se le scorciatoie vengono comunque accettate. In quel caso, il sistema perde rapidamente autorità.

La regola deve essere semplice e visibile: l’approvazione valida esiste solo nel sistema. Regola minima: le richieste via email, chat o voce non chiudono il processo; chi riceve una richiesta fuori canale la reindirizza al modulo ufficiale; le eccezioni devono essere motivate e registrate.

Questa regola va accompagnata da un rifiuto coerente delle richieste inviate su canali alternativi. Se arriva una richiesta ferie via email, la risposta deve reindirizzare al sistema. Se un responsabile scrive “approvato” in chat, qualcuno deve comunque chiedere la registrazione nel flusso ufficiale.

Nelle prime settimane servono quattro misure pratiche:

• istruzioni brevi per chi richiede e per chi approva
• formazione basata su casi reali, non su schermate generiche
• uno sponsor interno che sostenga la regola quando arrivano le prime resistenze
• supporto rapido nelle prime settimane per sbloccare problemi senza riaprire i vecchi canali.

L’uso coerente del sistema evita richieste perse, approvazioni contestabili e rincorse continue. Quando un responsabile decide fuori dal flusso ufficiale, il lavoro di ricostruzione ricade su chi gestisce le fasi successive.

Le leve operative per favorire l’adozione sono:

• promemoria automatici per le richieste in sospeso
• dashboard con code aperte e arretrati per approvatore
• esperienza mobile semplice per approvare o caricare allegati senza attrito
• tempi di risposta visibili per individuare i colli di bottiglia.

Verificare che il nuovo processo funzioni e preparare l’estensione ad altri flussi

Dopo il primo rilascio, il processo va valutato con indicatori stabili, evitando sia di dichiarare successo troppo presto sia di rimettere tutto in discussione a ogni commento.

Gli indicatori iniziali sono:

• riduzione delle email di approvazione o dei messaggi sostitutivi
• quota di richieste completate interamente nel sistema
• tempi medi di approvazione e chiusura
• eccezioni gestite nel percorso previsto, senza scorciatoie esterne
• meno errori documentali, allegati mancanti o richieste incomplete.

A titolo illustrativo, un pilota può fissare questi obiettivi: almeno il 90% delle richieste nel sistema entro quattro settimane, riduzione del 70% delle email di approvazione, arretrati sotto il 10% e nessuna richiesta chiusa senza un esito registrato. Le soglie vanno adattate ai volumi e al punto di partenza dell’organizzazione.

Anche i feedback vanno governati. Se ogni preferenza individuale diventa una modifica di processo, il rilascio non finisce più. Conviene distinguere tre categorie:

• errore tecnico: qualcosa non funziona come previsto e va corretto
• lacuna nelle regole o nel disegno: un caso reale non è coperto e richiede una decisione di processo
• abitudine residua: il sistema funziona, ma qualcuno preferisce ancora il vecchio modo di lavorare.

Solo le prime due categorie devono riaprire il tavolo di lavoro. La terza va gestita con supporto e applicazione coerente delle regole.

Prima di estendere il sistema ad altri flussi, bisogna verificare queste condizioni:

• il processo iniziale è stabile
• la traccia di controllo è completa e consultabile
• gli approvatori usano davvero il sistema
• l’uso da mobile è effettivo
• le richieste trattate fuori sistema sono poche e in diminuzione.

Quando queste condizioni sono soddisfatte, si può passare al processo successivo con meno fatica. L’organizzazione ottiene così un metodo affidabile per far circolare richieste, decisioni e prove senza dipendere da carta, email personali e memoria dei singoli.