A sei mesi dall'inizio dello sviluppo di un ERP, il team finanziario scopre che il nuovo sistema non è in grado di gestire un'approvazione a due fasi per le fatture intercompany. Non era mai stato inserito nei requisiti. Quando il team di progetto verifica, scopre che il requisito era stato menzionato durante un workshop, ma nessuno lo aveva annotato e la persona che ne aveva parlato nel frattempo ha lasciato l'azienda. Il lavoro di sviluppo deve essere rifatto, la data di go-live slitta e nessuno riesce a dimostrare da dove sia nato il gap.

La maggior parte dei fallimenti nei progetti ERP inizia allo stesso modo: nella raccolta dei requisiti. I workshop tralasciano dettagli, gli appunti sono incompleti e i requisiti perdono il legame con il processo da cui hanno avuto origine. Questa guida illustra un approccio migliore alla raccolta dei requisiti ERP: acquisire i requisiti dalle registrazioni di processi reali e sessioni con le PMI (Subject Matter Expert), in modo che ogni requisito sia riconducibile alla sua fonte, facile da convalidare e difficile da perdere.

Che cos'è la raccolta dei requisiti ERP?

La raccolta dei requisiti ERP è il processo di identificazione, documentazione e approvazione condivisa di ciò che un nuovo sistema ERP deve fare per supportare il business. Riguarda il funzionamento attuale dei processi, cosa deve cambiare, quali dati e report sono necessari, quali controlli devono essere integrati e come l'ERP deve integrarsi con gli altri sistemi. Il risultato è solitamente un catalogo dei requisiti o un documento dei requisiti di business (BRD) che guida la progettazione, l'analisi fit-gap, lo sviluppo e i test.

Una buona raccolta dei requisiti ERP parte da come il lavoro viene svolto nella realtà, non da come le persone se lo ricordano durante una riunione. Ecco perché inizia con il processo as-is; consulta il confronto tra processo as-is e to-be.

Perché i tradizionali workshop di raccolta requisiti ERP tralasciano alcuni requisiti?

• Le persone descrivono i processi a memoria. Dimenticano eccezioni, soluzioni alternative e attività di chiusura mensile che eseguono solo occasionalmente.

• Gli appunti sono incompleti. Un business analyst non può cogliere ogni singolo dettaglio mentre facilita un workshop.

• La conoscenza tacita rimane nascosta. I controlli e le valutazioni discrezionali che gli utenti esperti compiono abitualmente non vengono mai menzionati.

• I requisiti perdono il loro contesto. Un requisito di una sola riga in un foglio di calcolo non mostra il processo, la schermata o l'esempio pratico sottostante.

• Manca una traccia delle evidenze. Quando un requisito viene contestato in un secondo momento, nessuno è in grado di mostrare da dove sia scaturito.

Quali tipi di requisiti ERP dovresti acquisire?

Quando avviene la raccolta dei requisiti ERP?

La raccolta dei requisiti si svolge solitamente durante le fasi di discovery e progettazione, dopo l'approvazione del business case e prima dell'inizio della configurazione. In pratica continua in cicli più piccoli: i workshop di progettazione perfezionano i requisiti, l'analisi fit-gap aggiunge decisioni e i test li confermano. Registrare i processi in anticipo, prima che inizino i workshop di progettazione, fornisce a ogni fase successiva un punto di partenza affidabile. Per capire come questo si inserisce nel quadro generale del progetto, consulta i passaggi per l'implementazione del software.

Chi dovrebbe essere coinvolto nella raccolta dei requisiti ERP?

• I process owner, che sono responsabili del risultato e approvano i requisiti.

• I subject matter expert (SME), che svolgono il lavoro ogni giorno e conoscono le eccezioni.

• I business analyst, che gestiscono le sessioni, redigono i requisiti e mantengono aggiornato il catalogo.

• Il solution architect, che verifica i requisiti rispetto a ciò che l'ERP è in grado di fare.

• I responsabili IT e di integrazione, per dati, interfacce e sicurezza.

• Finanza, conformità o audit, per i requisiti relativi a controlli e reporting.

Coinvolgi persone provenienti da ogni fase del processo end-to-end, non solo da un unico team. Ad esempio, per i requisiti del ciclo procure-to-pay è necessaria la presenza di acquisti, ricezione merci, contabilità fornitori e tesoreria; consulta il flusso del processo procure-to-pay.

Come si acquisiscono i requisiti ERP dalle registrazioni dei processi?

Il metodo basato sulle registrazioni sostituisce la memoria con le evidenze. Invece di affidarti solo agli appunti dei workshop, registri i processi reali e le sessioni con gli SME, e ogni requisito rimanda direttamente alla registrazione da cui è stato ricavato.

Passaggio 1: Pianificare i processi da acquisire

Elenca i processi end-to-end inclusi nell'ambito, come procure-to-pay, order-to-cash, record-to-report e hire-to-retire, insieme alle attività chiave all'interno di ciascuno. Individua gli SME per ogni processo. La checklist per il process discovery aiuta a strutturare le interviste.

Passaggio 2: Registrare gli SME mentre svolgono il lavoro reale

Chiedi agli SME di eseguire ogni attività nel sistema attuale registrando il loro schermo con l'AI screen recorder di Trupeer, commentando a voce cosa fanno e perché. Chiedi loro di mostrare eccezioni, soluzioni alternative e i fogli di calcolo che utilizzano al di fuori del sistema.

Passaggio 3: Registrare i workshop sui requisiti e le sessioni con gli SME

Registra anche i workshop di progettazione e le interviste con gli SME su MS Teams o Zoom. Le registrazioni esistenti possono essere trasformate in documentazione grazie a da registrazione Teams a SOP.

Passaggio 4: Trasformare le registrazioni in documenti di processo

Trupeer trasforma ogni registrazione in una procedura dettagliata passo-passo con screenshot e un video ricercabile. I business analyst lavorano su questi documenti invece che su appunti frammentari, e ogni passaggio può essere riesaminato in qualsiasi momento.

Passaggio 5: Redigere i requisiti indicando il riferimento alla fonte

Scrivi ogni requisito in modo chiaro e annota la fonte: la registrazione, il passaggio o il timestamp e lo SME di riferimento. È questo che rende ogni requisito ERP perfettamente tracciabile.

Passaggio 6: Convalidare con gli SME

Rivedi il frammento video pertinente e il requisito formulato insieme allo SME e al process owner, confermalo o correggilo e registra l'approvazione formale.

Passaggio 7: Assegnare le priorità ed eseguire l'analisi fit-gap

Definisci le priorità dei requisiti (ad esempio con il metodo must-have, should-have, could-have e won't-have) e confrontali con le funzionalità standard dell'ERP per individuare i gap che richiedono configurazione, estensioni o una modifica del processo.

Passaggio 8: Mantenere la tracciabilità durante lo sviluppo e i test

Collega ciascun requisito alla relativa progettazione, all'elemento di sviluppo e al caso di test, in modo da poter dimostrare che ogni requisito sia stato implementato e collaudato. La checklist per la documentazione UAT illustra nel dettaglio la fase di collaudo.

Esempio: una matrice di tracciabilità dei requisiti ERP

Ecco come potrebbe presentarsi un catalogo di requisiti tracciabile. I dati inseriti sono a scopo illustrativo.

Poiché ogni requisito rimanda a una registrazione, chiunque può visualizzare la fonte in pochi secondi quando sorge un dubbio durante la progettazione, lo sviluppo o i test.

Quali sono i vantaggi della raccolta dei requisiti ERP basata su registrazioni?

• Meno requisiti tralasciati: le eccezioni e i workaround sono visibili sullo schermo, non affidati alla memoria.

• Tracciabilità fino alla fonte: ogni requisito si ricollega al processo e alla persona da cui ha avuto origine.

• Convalida più rapida: gli SME confermano i requisiti guardando il loro stesso processo, anziché leggendo lunghi documenti.

• Minore dipendenza dai singoli individui: la conoscenza viene acquisita e preservata anche se gli SME lasciano l'azienda durante il progetto.

• Riutilizzo: le stesse registrazioni diventano documentazione as-is, materiale per la formazione ed evidenze per i test.

Checklist per la raccolta dei requisiti ERP

• I processi e gli SME inclusi nell'ambito sono stati definiti e concordati.

• Ogni attività in ambito è stata registrata, incluse eccezioni e soluzioni alternative.

• I workshop e le interviste con gli SME sono stati registrati.

• Le registrazioni sono trasformate in documenti di processo archiviati in un unico spazio ricercabile.

• Ogni requisito presenta un ID, una formulazione chiara, un riferimento alla fonte, un referente e una priorità.

• I requisiti sono convalidati e approvati formalmente dagli SME e dai process owner.

• L'analisi fit-gap è completata, con le relative decisioni verbalizzate.

• I requisiti sono collegati alla progettazione, agli elementi di sviluppo e ai casi di test.

Errori comuni nella raccolta dei requisiti ERP

• Saltare l'analisi del processo as-is concentrandosi unicamente sullo stato futuro.

• Fare affidamento solo sugli appunti dei workshop, senza evidenze di come il lavoro venga svolto concretamente.

• Scrivere requisiti vaghi, ad esempio "il sistema deve essere facile da usare".

• Perdere il riferimento alla fonte, rendendo impossibile dirimere eventuali contestazioni sui requisiti.

• Ignorare le eccezioni e le attività di chiusura di fine periodo, momenti in cui si riscontra la maggior parte dei gap.

• Considerare i requisiti definitivi non appena il documento viene firmato, invece di tracciarli lungo l'intero ciclo fino al testing.

Per una visione più ampia sulla documentazione dei sistemi aziendali, scopri come documentare processi complessi di software enterprise.

Acquisisci i requisiti ERP con Trupeer

Trupeer trasforma le registrazioni degli SME e dei workshop in documenti di processo dettagliati e video ricercabili, fornendo alla tua raccolta dei requisiti ERP una fonte certa per ciascun requisito. Utilizza il nostro modello gratuito di documento dei requisiti di business per strutturare il tuo catalogo, oppure inizia gratis con Trupeer.

Domande frequenti

Che cos'è la raccolta dei requisiti ERP?

È il processo di identificazione, documentazione e approvazione condivisa di ciò che un nuovo sistema ERP deve fare, includendo processi, dati, reportistica, integrazioni, controlli ed esigenze non funzionali.

Come si raccolgono i requisiti per un'implementazione ERP?

Mappa i processi in ambito, registra gli SME mentre svolgono il lavoro effettivo e registra i workshop sui requisiti, trasforma le registrazioni in documenti di processo, scrivi i requisiti con un riferimento alla fonte, convalidali con gli SME, stabilisci le priorità ed esegui un'analisi fit-gap.

Che cos'è la tracciabilità dei requisiti nei progetti ERP?

È il collegamento diretto tra ciascun requisito e la sua fonte, la progettazione, l'elemento di sviluppo e il caso di test, per dimostrare l'origine di ogni requisito e attestare che sia stato correttamente implementato e verificato.

Perché registrare le sessioni sui requisiti ERP?

Le registrazioni catturano eccezioni, pratiche operative e contesti che gli appunti tralasciano, assegnano una fonte a ogni requisito, velocizzano la convalida e preservano il know-how aziendale anche in caso di turnover degli SME.

Cosa dovrebbe includere un documento dei requisiti ERP?

ID del requisito, formulazione chiara dello stesso, riferimenti alla fonte, area di processo, referente, priorità, stato di convalida e collegamenti alla progettazione e ai casi di test.

Quali tipologie di requisiti ERP esistono?

Requisiti funzionali, di dati, di reporting, di integrazione, di controlli e conformità, non funzionali e di transizione.

Chi dovrebbe partecipare alla raccolta dei requisiti ERP?

Process owner, subject matter expert, business analyst, l'architect della soluzione ERP, l'IT e, per i controlli, figure dell'area finanza o compliance.

Quanto tempo richiede la raccolta dei requisiti ERP?

Dipende dall'ambito del progetto, ma registrare i processi e le sessioni con gli SME riduce notevolmente i tempi, limitando i meeting di allineamento e accelerando le approvazioni.