Come progettare un gestionale aziendale partendo dai processi
Una guida per trasformare fogli, email e passaggi informali in requisiti verificabili, senza digitalizzare attività inutili.
In breve: un gestionale non dovrebbe replicare alla lettera fogli e passaggi esistenti. Prima si osserva il lavoro, poi si distingue ciò che crea valore da ciò che compensa limiti degli strumenti attuali. I requisiti nascono da utenti, eventi, regole, dati ed eccezioni.
1. Scegliere un processo, non “tutta l’azienda”
Iniziare da un perimetro leggibile permette di arrivare a una prima versione utilizzabile. Può essere il ciclo ordine-commessa, la preparazione dei preventivi, l’avanzamento della produzione o il portale clienti. Il processo deve avere un inizio, un risultato e un responsabile.
2. Osservare chi fa cosa
Per ogni ruolo vanno raccolti obiettivo, informazioni consultate, azioni, strumenti e decisioni. Le differenze tra ufficio, reparto produttivo e lavoro in mobilità incidono sull’interfaccia: la stessa schermata non serve necessariamente a tutti.
3. Rendere visibili stati ed eccezioni
Il percorso ideale copre soltanto una parte del lavoro. Mancano documenti, un cliente cambia richiesta, una macchina non è disponibile o l’approvazione supera una soglia. Le eccezioni devono avere una destinazione, una persona responsabile e una traccia; non possono essere affidate a note libere invisibili.
4. Definire la fonte di ogni dato
- Quale sistema crea il cliente o il prodotto?
- Chi può modificare prezzi e condizioni?
- Dove nasce lo stato della commessa?
- Quali dati devono tornare a e-commerce, ERP o macchina?
- Come si riconoscono duplicati ed errori di sincronizzazione?
5. Prototipare prima delle integrazioni costose
Un prototipo permette agli utenti di percorrere attività e correggere termini, sequenze e permessi. È più economico spostare un passaggio nel prototipo che cambiare database, API e migrazioni dopo lo sviluppo.
6. Definire un MVP e i criteri di successo
La prima release deve risolvere un flusso completo. Le metriche possono essere tempo per pratica, numero di copie manuali, errori intercettati, ritardi, percentuale di utilizzo e casi che richiedono assistenza. Senza una baseline, “funziona” resta un giudizio troppo vago.
7. Pianificare avvio ed evoluzione
Dati, formazione, supporto e responsabilità operative fanno parte del prodotto. Dopo il lancio il backlog deve essere guidato dall’uso reale: prima problemi e colli di bottiglia, poi funzioni desiderabili.
Dal gestionale alla fabbrica connessa
Nel progetto Alfonso Forni, amministrazione, ERP e produzione sono collegati: i progetti di piegatura delle lastre arrivano agli operatori e al software delle macchine utensili, mentre altri strumenti organizzano flussi e tempi delle fasi. Il caso mostra perché requisiti e integrazioni devono nascere dal processo reale.