Nelle PMI il workflow di approvazione degli acquisti diventa fragile quando nasce come somma di email, chat, eccezioni verbali e autorizzazioni date fuori sistema. Il problema non è solo la lentezza: è l’impossibilità di ricostruire perché una spesa è stata approvata, chi aveva gli elementi per decidere e quale regola è stata applicata. Un flusso digitale utile deve quindi partire dal processo, non dalla schermata.
Un buon modello non serve a irrigidire ogni acquisto. Serve a distinguere il caso standard dal caso fuori soglia, a dare responsabilità chiare e a lasciare una traccia leggibile. Per una PMI questo significa ridurre solleciti, rilavorazioni e decisioni prese per consuetudine, senza trasformare ogni richiesta in un percorso burocratico.
Da dove parte davvero il processo
Il processo dovrebbe aprirsi quando una persona formula una richiesta di acquisto con informazioni sufficienti per una prima valutazione. Non basta indicare cosa comprare: servono motivo, importo previsto, centro di costo o commessa, urgenza, fornitore se già noto e conseguenza operativa se l’acquisto non viene approvato. Questi dati non devono essere raccolti per completezza astratta, ma perché qualcuno li userà per decidere.
La richiesta deve avere uno stato corrente e un responsabile del prossimo avanzamento. Se il richiedente non sa se manca un dato, se il responsabile non vede le richieste in attesa o se l’amministrazione riceve informazioni incomplete solo alla fine, il workflow sta solo spostando il disordine da un canale all’altro.
Ruoli: chi propone, chi decide, chi controlla
Nel workflow di approvazione acquisti PMI conviene separare quattro ruoli. Il richiedente descrive bisogno e contesto. Il responsabile di budget valuta coerenza, priorità e capienza. L’ufficio acquisti o chi presidia i fornitori verifica condizioni, alternative e dati contrattuali. L’amministrazione controlla gli elementi necessari per ordine, fattura e pagamento.
Questi ruoli possono stare nella stessa persona nelle aziende più piccole, ma non devono essere confusi nel processo. La regola deve indicare quale responsabilità viene esercitata in ogni passaggio. Un’approvazione senza responsabilità esplicita produce solo un clic in più, non un controllo migliore.
Soglie e autorizzazioni
Le soglie servono a graduare il livello di attenzione. Un acquisto ricorrente e sotto importo può seguire un percorso breve; una spesa fuori budget, urgente o legata a un nuovo fornitore richiede controlli ulteriori. La soglia non deve essere soltanto economica. Categoria merceologica, criticità operativa, vincoli contrattuali e impatto sul cliente possono giustificare passaggi diversi.
Una regola pratica è definire poche fasce, comprensibili e verificabili. Troppe soglie generano interpretazioni, aggiramenti e richieste bloccate. Ogni fascia dovrebbe indicare chi approva, quali dati sono obbligatori, quali documenti servono e quando scatta l’escalation.
Eccezioni: urgenze, deroghe e casi incompleti
Un processo maturo non nasconde le eccezioni. Le rende visibili. Un acquisto urgente può saltare un passaggio solo se la deroga viene motivata e assegnata a un responsabile. Una richiesta incompleta può restare aperta, ma deve tornare al richiedente con un motivo preciso. Un acquisto fuori budget deve essere distinto da un acquisto semplicemente sopra soglia.
La ripetizione delle eccezioni è un segnale importante. Se molte richieste risultano urgenti, forse il processo di pianificazione è debole. Se mancano sempre gli stessi dati, il modulo iniziale non guida abbastanza. Se le deroghe vengono approvate sempre dalle stesse persone, il modello di responsabilità va rivisto.
Tracciabilità utile
La traccia deve permettere di ricostruire la decisione senza interrogare le persone. Per ogni passaggio servono autore, data, stato precedente e successivo, motivazione quando richiesta, documenti collegati e regola applicata. Non è necessario registrare rumore operativo: serve conservare il nesso tra informazione, decisione e azione.
Questa distinzione è importante anche per evitare burocrazia digitale. Una nota libera può essere utile, ma non può sostituire campi strutturati per importo, soglia, categoria, urgenza e motivazione della deroga. Se tutto finisce in testo libero, il processo resta difficile da analizzare.
Indicatori da monitorare
Gli indicatori iniziali possono essere pochi: tempo medio di approvazione, richieste oltre soglia, richieste respinte, richieste rientrate per dati incompleti, eccezioni ricorrenti e passaggi in attesa oltre una soglia definita. La metrica deve aiutare a prendere decisioni, non solo a produrre un report.
Prima di giudicare il miglioramento, conviene osservare una baseline. Se i dati storici non sono affidabili, è meglio dichiararlo e avviare una prima finestra di misurazione. Promettere precisione dove il processo non ha mai tracciato bene produce letture fuorvianti.
Un percorso di adozione concreto
- Raccogliere dieci richieste recenti: includere casi approvati, respinti, urgenti e incompleti.
- Disegnare il flusso reale: non quello desiderato, ma quello effettivamente seguito.
- Definire stati e soglie: pochi stati, pochi criteri, responsabilità chiare.
- Configurare un pilota: una categoria di spesa, un gruppo limitato e un periodo osservabile.
- Rivedere le evidenze: correggere regole, campi e responsabilità prima di estendere il processo.
Errori da evitare
- Digitalizzare le email senza chiarire chi decide.
- Aggiungere approvatori per compensare regole deboli.
- Usare una sola soglia economica per tutti i tipi di acquisto.
- Nascondere urgenze e deroghe in note non analizzabili.
- Coinvolgere l’amministrazione solo quando il problema è già diventato fattura.
- Estendere il workflow a tutte le spese prima di validare un caso pilota.
Quando valutare Alkemist
Se le richieste di acquisto attraversano funzioni diverse, cambiano priorità durante il percorso e richiedono evidenze per giustificare le decisioni, il punto di partenza è una mappa operativa. Alkemist può aiutare a rendere espliciti ruoli, permessi e passaggi autorizzativi, collegando stati, documenti e responsabilità senza dipendere da solleciti informali.
Per approfondire il tema del rapporto tra processo reale e sistema, è utile leggere anche come ripensare il flusso di lavoro quando il gestionale non riflette l’operatività reale e perché automatizzare un processo non compreso può amplificare il disordine.
Prossimo passo: scegliere una categoria di acquisto frequente, ricostruire dieci casi e verificare quali decisioni oggi avvengono fuori processo. Da lì si capisce quali regole meritano di essere automatizzate.