Individuare il vero collo di bottiglia
Non il problema di cui si parla di più, ma quello che assorbe più ore e produce più errori. Spesso non coincidono: il primo è visibile in riunione, il secondo si scopre osservando chi lavora.
Sviluppo software per PMI: da dove iniziare.
Le piccole e medie imprese non falliscono i progetti software per mancanza di budget, ma per eccesso di ambizione iniziale. Questa guida propone un percorso realistico, che parte da un perimetro piccolo e costruisce il resto sui risultati verificati.
Perché i progetti troppo grandi si fermano
Il copione è ricorrente. Si parte con l’idea di digitalizzare l’azienda, si raccolgono i desiderata di tutti i reparti, il perimetro cresce, il preventivo diventa importante e il progetto viene rimandato a quando ci sarà più tempo o più budget. Quel momento non arriva mai, e nel frattempo il problema iniziale resta.
Quando invece il progetto parte, un perimetro troppo ampio produce un altro rischio: mesi di sviluppo prima che qualcuno possa provare qualcosa. Se in quel periodo i requisiti sono stati fraintesi, ci si accorge solo alla consegna, quando correggere costa moltissimo.
La contromisura non è ridurre le ambizioni, ma cambiare l’ordine: iniziare da un modulo che risolve completamente un problema, metterlo in uso, misurare cosa cambia, e decidere il passo successivo con dati veri invece che con previsioni.
Un percorso in cinque passi
Misurare la situazione di partenza
Quante ore, quanti errori, quanto tempo di attesa. Se non si misura prima, non si potrà dimostrare il beneficio dopo e ogni valutazione resterà un’opinione.
Definire un primo perimetro piccolo
Un modulo che risolve un problema completo, non un pezzo di tutti i problemi. Deve poter entrare in uso da solo e produrre un beneficio verificabile.
Rilasciare e osservare l’uso reale
Il modo in cui le persone usano davvero lo strumento rivela sempre qualcosa che l’analisi non aveva colto. Le correzioni fatte in questa fase costano poco.
Estendere solo se il primo passo ha funzionato
Se il primo modulo non ha prodotto il beneficio atteso, aggiungerne altri non risolve: conviene capire perché prima di investire ancora.
Le priorità corrette per una PMI
Con risorse limitate l’ordine degli interventi conta più della qualità del singolo intervento. Questa è la sequenza che nella nostra esperienza produce i risultati più solidi.
- Prima eliminare il doppio inserimento. È il guadagno più immediato e quello che le persone percepiscono subito come un miglioramento della propria giornata.
- Poi rendere visibile lo stato di avanzamento. Sapere a che punto è una pratica senza dover chiedere a qualcuno elimina una quantità sorprendente di interruzioni.
- Poi automatizzare i documenti ricorrenti. Rapporti, conferme, documenti di trasporto: attività ad alto volume e bassa variabilità, dove l’automazione rende molto.
- Infine i cruscotti direzionali. Hanno senso solo quando i dati sottostanti sono affidabili: costruirli prima significa dare una veste autorevole a numeri sbagliati.
Errori che vediamo più spesso
- Coinvolgere solo la direzione nell’analisi. Chi decide e chi esegue hanno visioni diverse del processo, ed è la seconda quella che il software deve supportare.
- Non misurare la situazione di partenza. Senza un riferimento iniziale, a fine progetto non è possibile dire se è andata bene.
- Tagliare la formazione per contenere il preventivo. È la voce che più spesso determina se il software verrà adottato o aggirato.
- Trattare la manutenzione come un imprevisto. È una voce ricorrente e prevedibile, va messa a budget dal primo anno.
- Sviluppare processi in via di cambiamento. Se un’attività sta per essere riorganizzata, conviene aspettare che si stabilizzi.
Domande frequenti sui progetti software per PMI
Una PMI di dieci persone può permettersi un software su misura?
Dipende dal perimetro, non dalla dimensione dell’azienda. Un modulo verticale che risolve un problema specifico è alla portata di realtà molto piccole, e spesso ha un ritorno più rapido che nelle grandi organizzazioni perché il beneficio si distribuisce su meno persone e si vede subito. L’errore è impostare il progetto come se si dovesse sostituire tutto.
Da quale processo conviene partire?
Da quello che genera più lavoro manuale ripetitivo e più errori visibili al cliente. Non dal più strategico sulla carta, ma dal più doloroso nella pratica quotidiana: è quello su cui il beneficio sarà evidente a tutti e costruirà il consenso necessario per i passi successivi.
Non abbiamo un reparto IT. È un problema?
No, è la situazione normale nelle PMI e il progetto va impostato di conseguenza: scelte tecnologiche che non richiedano presidio interno, infrastruttura gestita, aggiornamenti a nostro carico. Quello che serve dall’azienda non è competenza tecnica, ma una persona che conosca il processo e possa decidere.
Quanto tempo devono dedicarci le nostre persone?
Concentrato nelle fasi di analisi e di collaudo. Alcune sessioni iniziali con chi conosce il processo, poi una verifica a ogni rilascio intermedio. È l’impegno che determina più di ogni altro la qualità del risultato: un progetto senza interlocutore interno disponibile produce software che nessuno vuole usare.
E se l’azienda cresce o cambia modo di lavorare?
È il motivo per cui l’architettura viene disegnata a moduli. Le evoluzioni successive si innestano su quanto esiste senza riscritture. È anche il motivo per cui consigliamo di non sviluppare processi che si prevede cambieranno a breve: meglio aspettare che si stabilizzino.