L’approvazione avviene tramite gruppi WeChat: come trasformare i flussi di approvazione, la gestione dei documenti ufficiali e i permessi organizzativi in un sistema

Introduzione: l’approvazione delle trasferte avviene tramite messaggi di gruppo, e per trovare il responsabile dell’approvazione bisogna chiedere a qualcuno

In un’azienda manifatturiera di circa 200 dipendenti, la prima richiesta di trasferta dopo l’anno nuovo è stata gestita così: il dipendente ha menzionato il responsabile nel gruppo; una volta visto il messaggio, il responsabile ha risposto “OK”, e il dipendente ha salvato lo screenshot; alla fine del mese, quando il reparto finanziario doveva elaborare i rimborsi spese, ha confrontato uno per uno gli screenshot con il budget; infine, il reparto risorse umane, nel conteggio annuale dei “giorni di trasferta dei dipendenti”, si è accorto che alcuni screenshot erano incompleti e che i dati tra i vari reparti non erano allineati.

Questo non è un caso isolato. In molte aziende in Cina, le procedure di approvazione seguono questo iter:

• Per trovare chi deve approvare, ci si affida alle domande: nella prima settimana dall’assunzione, la domanda più frequente dei nuovi dipendenti è: “Chi deve approvare la mia richiesta di permesso? Chi deve esaminare il mio rimborso spese?”
• I messaggi di gruppo come prova: su WeChat o DingTalk, un semplice “@capo approvato” viene considerato come conferma dell’approvazione, senza possibilità di audit successivo.
• Dati tra reparti non corrispondenti: il reparto vendite ritiene che la visita al cliente sia già stata approvata, mentre il reparto marketing sostiene che non lo sia; il reparto finanze, basandosi sugli screenshot del reparto vendite, procede al pagamento.
• Autorizzazioni affidate al verbale: quando un manager lascia l’azienda, le autorizzazioni non vengono revocate; il nuovo arrivato non sa a chi spetti il contratto precedentemente approvato dal vecchio manager.

La causa di questi problemi non sta nella complessità della procedura di approvazione, ma nel fatto che il flusso di approvazione non è stato integrato in un sistema informatizzato. I messaggi di gruppo, le comunicazioni orali e gli screenshot sono solo mezzi temporanei; ciò che manca è un supporto strutturato, tracciabile e rintracciabile. Il sistema OA (sistema di automazione d’ufficio) serve proprio a strutturare questa attività: racchiude in un’unica procedura tutte le informazioni relative a “chi, quale questione, quando, a chi è stato sottoposto, secondo quali regole è stato approvato e come vengono poi archiviati i dati”.

01 Come suddividere le attività: la struttura a tre livelli del flusso di approvazione

Suddividere l’attività di approvazione significa in realtà organizzarla in tre livelli:

1. Livello delle questioni: i dipendenti presentano specifiche richieste come “trasferta, permesso, rimborso spese, contratti, uso del sigillo, acquisti”, ciascuna accompagnata da importi, durata, allegati e oggetti correlati (ad esempio, la richiesta di trasferta è collegata all’ordine di vendita, il rimborso alle fatture).
2. Livello del processo: le questioni passano da un nodo all’altro, e i responsabili di ogni nodo vengono determinati dinamicamente (in base al reparto, al livello, all’importo e alla categoria), non sono fissi.
3. Livello dei dati: dopo l’approvazione o il rifiuto, i dati devono essere riportati nei sistemi operativi (HR, finanza, vendite, archivio contratti), senza restare confinati nel flusso di approvazione.

La relazione tra i tre livelli è la seguente: Le questioni costituiscono l’ingresso, il processo rappresenta la struttura portante e i dati ne sono l’uscita. Se, nell’implementazione di un sistema OA, si sviluppa solo il processo senza prevedere l’uscita dei dati, il flusso di approvazione diventa un’isola; se invece si realizza solo il livello delle questioni senza il processo, si riduce a un semplice “sistema di compilazione moduli”.

02 Come progettare: il trio composto da nodi dinamici, matrice delle autorizzazioni e registrazione delle tracce

Progettazione dei nodi: i responsabili dell’approvazione non sono fissi

Molti sistemi OA stabiliscono subito i responsabili dell’approvazione: “Richiesta di trasferta → Responsabile di reparto → HR → Direttore generale”. Di conseguenza, quando il responsabile di reparto cambia incarico, l’HR viene incorporato nell’amministrazione o il direttore generale è in viaggio, tutto il sistema va in tilt.

La soluzione corretta: i responsabili vengono calcolati dinamicamente sulla base di regole. Le dimensioni delle regole sono generalmente quattro:

• Dimensione del reparto: il reparto di appartenenza del richiedente viene associato al responsabile attuale di quel reparto (verificato in tempo reale attraverso l’organigramma).
• Dimensione del livello: importi, giorni e importi contrattuali corrispondono a diverse fasce, ognuna con un diverso livello di approvazione.
• Dimensione del ruolo: se l’importo del contratto supera i 500.000, l’ufficio legale deve intervenire; se un dipendente parte per un viaggio all’estero, la sicurezza e la conformità richiedono la firma congiunta.
• Dimensione dell’agente: quando il responsabile è in malattia o in trasferta, l’incarico viene automaticamente assegnato a un agente, stabilito in base ai rapporti organizzativi o dalle risorse umane.

Combinando queste quattro dimensioni in un “espressione regolamentare”, il motore di processo calcola in tempo reale i nodi secondo le regole, senza fissare in modo permanente i nomi dei responsabili. Così, cambi di incarico o modifiche organizzative non richiedono alcuna modifica del modello di processo.

Progettazione delle autorizzazioni: tre livelli — menu, dati e campi

Le autorizzazioni non riguardano solo “se si può entrare nel sistema”, ma sono articolate in tre livelli:

• Livello del menu: se si può visualizzare quel modulo (ad esempio, i dipendenti comuni non possono vedere “Gestione dell’organigramma”).
• Livello dei dati: se si può consultare quel dato (ad esempio, il reparto vendite può vedere solo i rimborsi dei propri dipendenti, non quelli del reparto vendite II).
• Livello dei campi: se si possono visualizzare determinati campi di quel dato (ad esempio, i normali approvatori non vedono il campo stipendio del richiedente, mentre l’HR può vederlo).

Una volta scissi i tre livelli di autorizzazione, il sistema OA riesce a gestire strutture organizzative complesse: gruppo–filiale–reparto–team; i dati tra i vari livelli vengono controllati simultaneamente secondo due regole: “posso vedere solo i dati relativi alla mia linea + sono responsabile di quella linea”.

Progettazione della registrazione delle tracce: i sette elementi del registro di approvazione

Ogni operazione di approvazione deve registrare sette elementi:

1. Operatore: chi ha effettuato l’operazione.
2. Orario dell’operazione: preciso fino al secondo.
3. Azione dell’operazione: approvazione, rifiuto, trasferimento, aggiunta di firme, ritiro.
4. Opinione sull’operazione: l’opinione di rifiuto è obbligatoria, mentre quella di approvazione può essere lasciata vuota.
5. Posizione del nodo: in quale fase del processo ci si trova.
6. Fotocopia dei dati correlati: i valori dei campi degli oggetti coinvolti nell’approvazione (importi, allegati) vengono conservati così come sono, senza consentire modifiche posteriori agli oggetti mentre il registro di approvazione resta immutato.
7. Tracce del dispositivo e dell’IP: da quale dispositivo e quale IP proviene l’operazione (utili per l’audit di conformità).

Se manca anche uno solo di questi sette elementi, durante l’audit nascono continue controversie. Un errore comune è lasciare vuota l’opinione sull’operazione: così, il rifiuto resta privo di motivazione, il dipendente ripete la richiesta e il flusso di approvazione si allunga.

03 Come sviluppare: il trio composto da motore di processo, motore di moduli e bus di messaggi

Il cuore dello sviluppo di un sistema OA sono tre motori, non N pagine:

Motore di processo

Il motore di processo non richiede programmazione: basta configurarlo per far funzionare il flusso. Tra le caratteristiche da supportare:

• Flussi seriali, paralleli, firme congiunte e firme separate: quattro tipologie fondamentali di flussi; la richiesta di assunzione segue un flusso seriale (HR → Responsabile → CEO), mentre gli acquisti con firma congiunta seguono un flusso parallelo (finanza e responsabile degli acquisti esaminano contemporaneamente).
• Ramificazioni condizionali: in base all’importo, alla categoria e al livello del richiedente, i flussi vengono differenziati: sotto i 5.000 yuan si segue un percorso semplificato, tra 5.000 e 50.000 si applica la doppia revisione di reparto e finanza, oltre i 50.000 si aggiunge anche il CEO.
• Ripristino e rifiuto: sono supportati tre tipi di rifiuto: rifiuto all’originatore, rifiuto a un nodo qualsiasi e rifiuto al nodo precedente.
• Firma aggiuntiva e trasferimento della firma: l’approvatore può trasferire l’incarico a un collega (trasferimento della firma) oppure coinvolgere un altro collega nell’approvazione (firma aggiuntiva).
• Ritiro e annullamento: l’originatore può ritirare le pratiche non ancora approvate; l’amministratore può annullare le pratiche anomale.

Una volta realizzato il motore dei processi,è possibile aggiungere una nuova categoria di approvazione senza scrivere codice: basta disegnare uno schema e configurare un modulo per renderlo operativo. Questo è il punto chiave che distingue l’OA dal “sviluppo esterno dell’approvazione”.

Motore dei moduli

I moduli devono essere progettati “senza alcun codice”: tipi di campo (testo, numero, data, allegato, oggetto aziendale correlato), regole di convalida, campi obbligatori o facoltativi, condizioni di visibilità e nascondibilità, tutto configurabile tramite trascinamento visivo. In questo modo, quando l’HR modifica i campi delle spese di rimborso o la vendita aggiunge nuovi campi contrattuali,non è necessario pianificare interventi da parte del reparto IT.

Il motore dei moduli deve supportare:

• Autorizzazioni a livello di campo: nella stessa scheda, diversi approvatori vedranno campi differenti (ad esempio, l’approvatore ordinario non potrà vedere il numero di telefono dell’originatore).
• Collegamento tra campi: selezionando “Tipo di contratto = Contratto di servizio”, vengono automaticamente visualizzati i campi specifici per i contratti di servizio.
• Scrittura retroattiva dei dati: dopo l’approvazione, i dati vengono automaticamente riportati nei sistemi aziendali (stato del contratto, presenze HR, documenti contabili).

Bus dei messaggi

In caso di approvazione o rifiuto, sia il richiedente sia i relativi sistemi aziendali (HR, finanza, vendite) ricevono immediatamente una notifica. Il bus dei messaggi invia in modo unificato:

• Notifiche interne al sistema: messaggi interni più attività da svolgere.
• Notifiche IM: webhook su WeChat aziendale, DingTalk e Feishu, che vengono inviati ai gruppi corrispondenti o ai singoli utenti.
• Email e SMS: notifiche di backup per i momenti chiave (approvazione contratti, viaggi all’estero).
• Messaggi ai sistemi aziendali: dopo l’approvazione, viene generato un messaggio nell’area delle attività da svolgere del sistema aziendale (ad esempio, la finanza riceve un’attività di rimborso, l’HR un’attività di assunzione).

Il bus dei messaggi non è un semplice “ornamento”, ma rappresenta il “circuito chiuso” del flusso di approvazione: senza notifiche, il richiedente non sa a chi rivolgersi per il passaggio successivo, e l’intero processo si blocca.

Conclusione: sequenza di attuazione, rischi e indicatori

L’implementazione del sistema OA avviene in tre fasi:

1. Prima fase (1 mese): inserimento delle tre operazioni più frequenti – richiesta di permesso, viaggio di lavoro e rimborso spese – coprendo l’intero personale. Innanzitutto trasferire le approvazioni dai gruppi WeChat nel sistema, anche solo per queste tre funzioni; così i dati tra i vari reparti si allineano immediatamente.
2. Seconda fase (2-3 mesi): introduzione di quattro attività di frequenza media – contratti, timbri, acquisti e pagamenti – collegandole al sistema finanziario. In questa fase è necessario garantire la scrittura retroattiva dei dati (ad esempio, l’approvazione di un contratto viene automaticamente archiviata nella banca contratti).
3. Terza fase (su richiesta): integrazione di tutte le procedure HR, come valutazione delle prestazioni, promozioni, assunzione definitiva, reclutamento e dimissioni. Questa fase è guidata dall’HR e prevede l’integrazione dei dati anagrafici HR.

Rischi comuni:

• Regole troppo flessibili: la configurazione del flusso di approvazione è troppo libera, con il risultato che nessuno sa chi sarà il responsabile del passaggio successivo. Principio: i modelli di processo non dovrebbero superare i 30 elementi, altrimenti si perde il controllo.
• Mancanza di un sostituto: se l’approvatore è in viaggio e non ha designato un sostituto, il processo resta bloccato per 3 giorni senza alcuna approvazione. Il sistema rileva automaticamente quando un processo rimane “bloccato” per oltre 24 ore e genera un’allerta.
• Mancanza di scrittura retroattiva dei dati: l’approvazione è stata concessa, ma nelle registrazioni delle presenze HR non sono stati aggiornati i dati, né sono stati creati i documenti contabili nel sistema finanziario. La scrittura retroattiva deve prevedere una “doppia verifica”: dopo aver completato l’operazione nell’OA, il sistema deve attivare l’interfaccia del sistema aziendale per confermare la ricezione.

Indicatori per valutare l’efficacia del progetto:

• Durata media dell’approvazione: prima dell’implementazione, i processi venivano gestiti tramite gruppi WeChat in 3 giorni; dopo l’implementazione, il ciclo si chiude entro 1 giorno nel sistema.
• Coerenza dei dati tra i reparti: il tasso di errore nella riconciliazione tra i tre sistemi — HR, finanza e vendite — è diminuito di oltre l’80%.
• Tasso di tracciabilità delle verifiche: scegliendo casualmente 20 approvazioni storiche, il tasso di completezza dei sette elementi fondamentali raggiunge il 100%.

Trasferire le approvazioni dai gruppi WeChat al sistema non serve solo a “mettere tutto online”, ma piuttosto a trasformare il compito di “trovare la persona” da una dipendenza dall’individuo a una dipendenza dalle regole. Una volta fissate le regole, anche in caso di dimissioni o cambiamenti organizzativi, il flusso di approvazione resterà sempre ordinato.