Un progetto software comincia spesso con una lista di funzioni: una dashboard, alcune anagrafiche, la gestione degli ordini, notifiche automatiche e collegamenti con il gestionale. È comprensibile: le funzioni sono la parte più visibile e sembrano trasformare rapidamente un’idea in qualcosa di concreto.

Il rischio è iniziare dalla soluzione prima di aver compreso il problema. Una web application non deve soltanto mostrare schermate o memorizzare dati. Deve inserirsi nel modo in cui l’azienda lavora, rispettare responsabilità e sequenze, gestire eccezioni e comunicare con strumenti già utilizzati.

Per questo la prima domanda non dovrebbe essere “con quale tecnologia la realizziamo?”, ma “come avviene oggi questo processo?”. Soltanto dopo aver ricostruito il lavoro reale è possibile decidere che cosa digitalizzare, che cosa semplificare e quali funzioni abbiano davvero senso.

Jits non porta nei progetti soltanto esperienza informatica. Il nostro percorso comprende progettazione tecnica, CAD/CAM, programmazione di macchine CNC, processi produttivi e sviluppo di software gestionali. Questa esperienza pratica ci permette di comprendere meglio il lavoro che sta dietro ai dati e di trasformarlo in applicazioni realmente utilizzabili.

Per questo una web application efficace non nasce dal codice. Nasce dal confronto con chi utilizzerà lo strumento e dalla capacità di trasformare un processo reale in regole chiare, integrabili e modificabili nel tempo.

Prima si ricostruisce il processo reale

L’analisi parte da ciò che avviene oggi, non da ciò che dovrebbe teoricamente avvenire. Bisogna seguire il percorso di una richiesta dall’inizio alla fine: chi la riceve, dove la registra, quali controlli compie, quali documenti produce e a chi passa il risultato.

È utile individuare almeno cinque elementi:

• Persone e ruoli: chi esegue, controlla, approva o deve essere informato.
• Informazioni: quali dati entrano nel processo, da dove arrivano e quale sistema li considera ufficiali.
• Passaggi: in quale ordine si svolgono le attività e quali condizioni permettono di proseguire.
• Strumenti: gestionali, fogli di calcolo, email, documenti e applicazioni già utilizzati.
• Risultati: che cosa deve essere prodotto, registrato, inviato o misurato.

Questa ricostruzione fa emergere duplicazioni e attività nate per compensare i limiti degli strumenti esistenti. Un dato copiato tre volte non deve necessariamente essere riprodotto tre volte nella nuova applicazione. Spesso il valore del progetto consiste proprio nell’eliminare trasferimenti manuali e rendere chiara la responsabilità dell’informazione.

Le eccezioni descrivono il lavoro meglio del percorso ideale

Quando si racconta un processo, si tende a descrivere il caso più semplice: la richiesta è completa, il prodotto è disponibile, il cliente viene approvato e l’ordine procede senza interruzioni. Nella pratica, una parte importante del lavoro riguarda tutto ciò che esce da questo percorso.

Un preventivo può richiedere una verifica tecnica. Un ordine può contenere righe con tempi diversi. Un documento può arrivare incompleto. Un cliente può avere condizioni particolari. Un’integrazione può non rispondere oppure restituire un dato incoerente.

Le eccezioni non devono diventare una scusa per costruire un software ingestibile, ma non possono essere ignorate. Occorre distinguere:

• i casi frequenti che il sistema deve gestire automaticamente;
• i casi rari che richiedono una procedura controllata;
• le vecchie abitudini che possono essere eliminate;
• le particolarità che rappresentano davvero il modo di lavorare dell’azienda.

È qui che l’esperienza fa la differenza. Non basta trasformare ogni richiesta in una funzione. Bisogna capire quali regole rendano il processo affidabile senza irrigidirlo.

La tecnologia si sceglie dopo, ma non è secondaria

L’intelligenza artificiale può accelerare lo sviluppo, ma non sostituisce l’analisi. Anche un codice tecnicamente corretto può automatizzare male un processo che non è stato compreso. Abbiamo approfondito questo tema nell’articolo Software su misura: il codice si trova, l’esperienza no.

Partire dal processo non significa sottovalutare la tecnologia. Significa sceglierla sulla base di requisiti reali. Numero di utenti, quantità di dati, necessità di lavorare da dispositivi diversi, integrazioni, sicurezza, prestazioni e manutenzione influenzano l’architettura della soluzione.

In alcuni casi è sufficiente estendere uno strumento esistente. In altri serve una web application dedicata. Talvolta il passaggio decisivo è un’integrazione tra ecommerce, gestionale e area riservata; altre volte occorre sostituire fogli di calcolo e scambi di email con un unico flusso condiviso.

Il risultato migliore non è il software con il maggior numero di funzioni. È quello che rende più semplice compiere le attività corrette, impedisce gli errori prevedibili e lascia alle persone il controllo delle decisioni importanti.