La Raccolta dei Requisiti

Overview dello Sprint “Scenario di Emergenza”

Come si riscontra nella maggioranza delle progettualità riguardanti implementazioni di soluzioni software informative, a monte della loro attuazione si ritrova un’esigenza di Business, appositamente formalizzata sotto forma di requisito.

Nel caso in esame, l’esigenza espressa a livello di Sede Centrale da parte dell’Agenzia si configurava nella volontà di riuscire ad intraprendere e gestire situazioni di emergenza attraverso il Budget Planning Tool.

Un contesto di emergenza per l’Agenzia è definibile come un nuovo scenario al quale far fronte attraverso la conduzione di opportune attività di Budgeting e Pianificazione che possono parzialmente differire, per tempistiche e modalità di erogazione, rispetto a quelle condotte abitudinariamente.

I nuovi scenari, per poter essere affrontati e gestiti attraverso il Budget Planning Tool, richiedevano un’opportuna declinazione, nonché un appropriato settaggio, all’interno dell’ambiente software e impattante il meno possibile sulla struttura informativa esistente, sia a livello di Processo che di Data Model.

Un contesto di emergenza, per UNC si delinea attraverso le due seguenti istanze:

• Nuova Attività: istanza per la quale è richiesto lo svolgimento di un’attività finanziaria mai intrapresa all’interno di un Ufficio Nazionale dell’Agenzia.

• Nuova Unità di Budget e Programmazione: istanza per la quale è prevista la definizione di un nuovo portfolio di attività finanziarie da condurre all’interno di un Ufficio Nazionale di un determinato Paese.

Sprint Meeting

Il processo che ha guidato nella raccolta e conseguente formalizzazione dei nuovi requisiti caratterizzanti lo sprint progettuale, si è basato principalmente su riunioni che vedevano coinvolti entrambi i Team di progetto e classificabili nelle tre sottostanti categorie:

• Opening Meeting: meeting introduttivo avviato durante la fase embrionale di progetto, quando le attività di implementazione risultavano non ancora avviate. Lo scopo era quello di delineare il profilo della nuova istanza progettuale. La conduzione è stata presidiata dai referenti IT della Agenzia - IT e Business - i quali avvalendosi del supporto di presentazioni grafiche, hanno esposto al Team di KPMG S.p.A lo scope dello sprint.

• Business Meeting: meeting interattivi tra i Consulenti Implementatori e lo Staff di Progetto di UNC, quest’ultimo comprendente sia i membri appartenenti alla divisione IT che i ruoli direzionali sottostanti la Sede Centrale. Contestualmente allo svolgimento di tali riunioni, condotte periodicamente a seguito del raggiungimento di ogni milestone stabilita nello Scope di progetto, le linee guida di conduzione delle attività venivano confermate o riaggiornate ed eventualmente nuove richieste di natura business, da convertire in linguaggio funzionale, venivano definite. Inoltre, durante gli incontri, i Consulenti, supportati dallo staff IT dell’Agenzia, presentavano ai ruoli di Business le soluzioni tecniche apportate sul sistema, consentendo a quest’ultimi di condurre tempestivamente test di validazione supportati con il rilascio di un feedback.

• Status Update Meeting: incontri di natura operativa, condotti con frequenza settimanale, presidiati dai Consulenti Implementatori e dai soli membri IT del team progettuale dell’Agenzia nei quali quest’ultimi schedulavano dettagliatamente le richieste di carattere tecnico e le rispettive scadenze di implementazione. In certe casistiche, durante tali incontri, veniva incentivata un’attività di riallineamento tra i due team in merito la fattibilità dei requisiti business, in termini di trasposizione di quest’ultimi in ambiente software.

Laddove infatti, il rispetto di un particolare requisito richiedeva un’implementazione eccessivamente dispendiosa in termini temporali, o addirittura incompatibile con quella di altri, i ruoli direzionali del team di UNC, una volta aggiornati dai rispettivi membri IT, conducevano un’analisi, sia sul potenziale impatto che sulla tempistica di realizzazione, della funzionalità richiesta. A seguito, veniva presa la decisione se proseguire o meno con l’attuazione del requisito ed il responso veniva tempestivamente comunicato al team di Consulenti dai portavoce IT dell’Agenzia tramite comunicazione mail o nel successivo incontro programmato. Infine, proprio come per la precedente tipologia, anche in questi incontri il team di Consulenti presentava ai responsabili IT dell’Agenzia le nuove introduzioni di natura tecnica apportate sul sistema per sottoporle ad una verifica, ricevendo dei feedback in merito al lavoro condotto.

Nonostante la loro diversa natura, le tipologie di riunioni appena descritte, in particolare per quanto concerne i Business e gli Status Update Meeting, presentavano una modalità di conduzione molto interattiva, contrassegnata dallo scambio tempestivo e reciproco di

feedback da parte dei due Team. In particolare, laddove l’Agenzia definiva una nuova esigenza, che si concretizzava nell’attuazione di una nuova funzionalità o nella modifica di una preesistente, la squadra di Consulenti KPMG S.p.A forniva immediatamente una prima stima, sia di natura temporale che di impatto sull’architettura del sistema, nel merito della sua attuazione.

In questo modo l’Agenzia, decideva efficientemente se perseguire con la richiesta o riallineare il tiro a seconda delle proprie esigenze.

L’utilizzo delle Riunioni è stato anche distintivo delle attività di test che periodicamente richiedevano di essere attuate e che sono descritte nei successivi paragrafi.

I Requisiti Funzionali

Dal punto di vista funzionale i requisiti inerenti lo sprint progettuale stabiliti durante l’Opening Meeting e formalizzati all’interno del documento di Scope progettuale sono stati i seguenti:

Requisiti Business

Generali Requisito Funzionale di Sistema

Abilitare la conduzione di Attività finanziarie

di Emergenza, attraverso le funzionalità del Budget

Planning Tool.

Dal punto di vista funzionale al sistema si richiedeva un aggiornamento da apportare attraverso la definizione, all’interno dell’architettura, dei due possibili scenari che definiscono una situazione di emergenza.

Allineare il Modello di

Budgeting e Pianificazione, al sistema informativo aziendale.

Il preesistente Workflow caratteristico dei diversi processi di Pianificazione e Budgeting doveva essere integrato al proprio interno con un nuovo Step di Processo che identificasse le attività da condurre di fronte ad uno scenario di emergenza.

Redigere reportistica di dettaglio.

In ottica funzionale, il requisito ha richiesto la progettazione di nuovi formati documentali attraverso le funzionalità di Excel.

Garantire integrazione con i sistemi informativi

attualmente presenti

Lo strumento deve permettere lo scambio dei dati tra i diversi sistemi informativi presenti all’interno dell’organizzazione senza che questi vengano modificati, persi o danneggiati.