Nel corso della mia carriera professionale, ho notato che il rigore delle mie analisi funzionali si è costantemente rafforzato, indipendentemente dai framework metodologici utilizzati, sia che si trattasse del ciclo a V tradizionale o di un approccio Agile iterativo.
Questa evoluzione non è casuale: la raccolta dei requisiti costituisce, fin dalle prime fasi di un progetto ERP, la base essenziale che definisce chiaramente il perimetro funzionale e garantisce la coerenza di tutti i prodotti intermedi (deliverable).
Al di là del suo ruolo funzionale, l'analisi rappresenta una vera e propria competenza. Essa impone una comprensione comune, precisa e senza ambiguità delle aspettative del cliente, al fine di evitare interpretazioni divergenti che potrebbero compromettere il successo dell'implementazione.
Pertanto, questo articolo non si limita a migliorare la qualità del prodotto intermedio (deliverable), ma vuole essere anche un invito alla trasparenza nei confronti dei nostri clienti e un'occasione per mettere in risalto la padronanza della nostra professione.
Esponendo chiaramente la metodologia e gli strumenti che utilizziamo, cerchiamo non solo di rendere sicura ogni fase del progetto, ma anche di stabilire un rapporto di fiducia duraturo, basato sulla chiarezza, la responsabilità e la condivisione di una visione comune.
L'utilità del documento
L'analisi funzionale è il documento di riferimento che traduce le esigenze aziendali (o business) in soluzioni concrete nell'ERP.
- Per le funzioni aziendali (Business): convalida che le loro esigenze siano comprese e trascritte senza ambiguità.
- Per i consulenti funzionali: fornisce la base per configurare correttamente il sistema.
- Per gli sviluppatori: distingue ciò che rientra nello standard, in un componente aggiuntivo (add
- on) o in uno sviluppo specifico.
- Per la direzione di progetto: mette in sicurezza il perimetro, limita le derive (scope creep) e funge da filo conduttore per tutta la durata del progetto.
Questo documento deve essere condiviso con il cliente, che ne è il primo lettore critico e il validatore. Tale validazione è essenziale: essa conferma che l'integratore ha compreso correttamente il funzionamento attuale dell'azienda o di un flusso specifico e che propone una soluzione di miglioramento appropriata e realistica.
Non si tratta, quindi, solo di un deliverable formale, anche se la natura, la quantità e la qualità delle informazioni che contiene lo rendono un'espressione di competenza (expertise). È uno strumento di comunicazione, di gestione e di validazione congiunta tra le funzioni aziendali e l'integratore.
La relazione
La relazione è la combinazione di una conoscenza approfondita, un'esperienza pratica e una capacità di analizzare con discernimento un ambito specifico.
Quando si materializza in un documento ufficiale, essa diventa il riflesso dell'azienda che ci impiega: questo documento ne veicola gli standard, la metodologia e l'identità professionale. Ma incarna anche la "firma intellettuale" del suo autore: il modo in cui i requisiti sono formulati, gli argomenti scelti e le raccomandazioni proposte rivelano le competenze, lo stile e la visione della persona che lo ha redatto.
Pertanto, ogni documento di analisi è allo stesso tempo un ambasciatore dell'organizzazione e la testimonianza personale del suo creatore.
La struttura dell'analisi
L'analisi funzionale segue una struttura logica e chiara. Inizia con un'introduzione che definisce il contesto, poi descrive le procedure attuali e le procedure target (o desiderate). Successivamente, dettaglia la risposta alle esigenze aziendali nell'ERP, distinguendo tra funzionalità standard, funzionalità fornite da add-on e sviluppi specifici.
Specifica la configurazione (paramétrage), le regole di gestione, le schermate, i report (o stati), e conclude sul valore aggiunto per l'azienda.
Infine, formalizza i requisiti che garantiscono la qualità complessiva del sistema.
L'introduzione
L'analisi inizia con la presentazione dell'azienda: il suo settore di attività, le sue specificità e l'argomento trattato dallo studio.
Si descrivono poi i problemi attuali che rallentano la produttività: duplicazioni, lentezze, errori, mancanza di reporting.
Questa sezione spiega perché un'evoluzione è necessaria e quali miglioramenti concreti sono attesi.
Procedure
Si descrive il processo esistente utilizzando il presente indicativo: fasi completate, attori coinvolti, punti di blocco. L'obiettivo è fornire una visione fattuale e obiettiva del funzionamento attuale dell'azienda.
Si proietta come sarà il processo nel futuro ERP, utilizzando il futuro indicativo: più integrato, automatizzato e controllato. Questa formulazione evidenzia la trasformazione e il miglioramento attesi.
Regola di scrittura: in un'analisi funzionale, non si usa mai il condizionale. Si descrivono unicamente l'esistente (presente) e l'obiettivo/la target (futuro), per eliminare ogni ambiguità.
Affinché il cliente possa immedesimarsi facilmente nella soluzione proposta, non bisogna esitare a integrare schizzi o immagini delle future pagine o finestre del sistema. Questi elementi visivi, anche se semplici, permettono di:
- Al cliente di rappresentarsi concretamente il suo futuro ambiente di lavoro, aiutandolo così a convalidare la soluzione proposta molto prima di qualsiasi sviluppo.
- Agli sviluppatori di avere un riferimento visivo di ciò che devono sviluppare.
- Di risparmiare tempo durante la preparazione dei supporti per i mockup (modelli) nella fase successiva alla convalida dell'analisi.
Gli schemi illustrano questi flussi e rendono chiare le problematiche/poste in gioco per tutti.
Funzionalità nel nuovo ERP
Ogni esigenza è tradotta in una risposta nel futuro sistema.
Setups
Questa sezione descrive le regolazioni necessarie: regole di gestione, workflow (flussi di lavoro), profili utente, nomenclature.
La configurazione (paramétrage) adatta lo standard alle pratiche aziendali e costituisce il primo passo della personalizzazione.
Descrizione dettagliata delle funzionalità
- Regole di gestione: calcoli, controlli, convalide.
- Schermate e moduli (Form): campi obbligatori, ergonomia, facilità di inserimento dati.
- Report e reporting: indicatori, dashboard (cruscotti), documenti normativi (o regolamentari).
Queste descrizioni garantiscono che gli utenti sappiano come lavorare domani e che i team dispongano di tutti gli elementi per configurare e sviluppare.
Conclusione funzionale
La fine di ogni sottoprocesso esplicita il valore aggiunto atteso per l'azienda. Questa sezione evidenzia i benefici tangibili che trasformeranno la quotidianità degli utenti e contribuiranno agli obiettivi strategici:
- Aumento della produttività
- Maggiore affidabilità dei dati
- Migliore processo decisionale (o Migliore decision making)
- Miglioramento della soddisfazione del cliente.
Requisiti non funzionali
Oltre ai processi aziendali, l'analisi formalizza i requisiti di qualità del sistema, garantendone la robustezza e la sostenibilità (pérennité). Questi punti hanno un impatto diretto sulla soddisfazione degli utenti e sulle prestazioni aziendali:
- Performance: Misura la reattività (tempo di risposta) e la disponibilità del sistema, ma anche la sua capacità di gestire i picchi di carico.
- Sicurezza: Definisce le regole di autenticazione e autorizzazione degli utenti. Copre anche la protezione dei dati (crittografia, backup) e la conformità normativa (GDPR).
- Volumi: Analizza i dati attuali e integra le previsioni di crescita per dimensionare correttamente l'infrastruttura e anticipare le esigenze future.
- Ergonomia: Assicura che il sistema sia intuitivo e facile da usare. Una buona ergonomia riduce gli errori e favorisce l'adozione da parte degli utenti.
Formalizzare questi requisiti fin dall'inizio permette di integrarli nel capitolato d'oneri tecnico (o nelle specifiche tecniche) e di evitare sorprese alla fine del progetto. Essi costituiscono la spina dorsale tecnica che supporta le funzionalità aziendali (funzionalità business).
Il valore della distinzione standard / add-on / specifico
Questa distinzione è essenziale.
- Lo standard assicura stabilità, scalabilità e costi inferiori.
- L'add
- on fornisce una risposta collaudata per esigenze già riscontrate altrove.
- Lo specifico offre una forte differenziazione, ma crea un debito tecnico che deve essere monitorato.
Esplicitando questa ripartizione, l'analisi funzionale permette alla direzione di progetto di prendere decisioni in totale trasparenza.
La funzione del documento secondo il metodo di progetto (o La funzione del documento in base alla metodologia di progetto)
- Ciclo a V: l'analisi funzionale è congelata (figée) prima della progettazione tecnica e funge da riferimento contrattuale per la configurazione (paramétrage), gli sviluppi, i test e l'accettazione (recette). Ogni fase di validazione si basa su di essa.
- Agile: l'analisi definisce il perimetro "a grandi linee" (grosse maille), espresso in linguaggio aziendale (métier) e quindi funzionale. Costituisce il punto di partenza per identificare e redigere le user stories. Il documento non è congelato, ma si evolve e si arricchisce sprint dopo sprint, in coerenza con le priorità definite dal product owner.
L'analisi funzionale è la pietra angolare di un progetto ERP. Descrive il contesto, formalizza i processi target, distingue tra standard, add-on e sviluppi specifici, dettaglia le regole di gestione e stabilisce i requisiti non funzionali.
È utile a tutti: funzioni aziendali (métier), consulenti, sviluppatori e direzione di progetto.
In un ciclo a V, costituisce il riferimento stabile e contrattuale. In un progetto Agile, definisce il perimetro aziendale di partenza e funge da base per la creazione delle user stories.
In entrambi i casi, mette in sicurezza la comprensione, struttura il dialogo e garantisce che l'ERP implementato apporti un valore tangibile all'azienda.