RAD: Case Study Human Resource System

1. RAD: Case StudyHuman ResourceSystem L’esperienza dell’Università di Trento 3 novembre 2003

2. Il progetto: le motivazioni • La rilevanza del dominio, sia in termini gestionali che strategici (voce di bilancio a maggior peso) • La frammentarietà e l’assenza di integrazione degli strumenti informatici utilizzati (alta manualità, duplicazione dati, disallineamenti, mancanza di una “vista” multi- dimensionale del dipendente..) • L’obsolescenza degli applicativi esistenti e la loro inadeguatezza funzionale (elevata presenza di file “personali” gestiti con strumenti Office) • La nascita di nuovi aspetti funzionali non supportati da strumenti informatici quali formazione, valutazione e sviluppo (massiccio utilizzo di strumenti Office) 1

3. File Excel File Excel Stop & Go ? File Excel ? File Excel ? Inaz Web Inaz Presenze TermTalk LDAP ? ? ? GePTA Elezione Docenti CINECA Sistema Segreteria Studenti GePDoc Sistema Contabilità ? ? ? Il progetto: le motivazioni 2

4. Il progetto: gli obiettivi • Dotare l’Ateneo di un Sistema di Gestione del personale, integrato con i macro business process dell’Università • Realizzare un Sistema aperto, integrato, affidabile, in grado di supportare tutti gli aspetti gestionali e operativi della Direzione • Perseguire l’accentramento e la definizione di fonti uniche di informazioni e generazione dei dati • Ottimizzare i processi operativi, ridurre la manualità e migliorare la qualità del lavoro e delle attività svolte • Fornire uno strumento che consenta una “vista” multidimensionale del dipendente 3

5. Il progetto: le fasi Operate Requirements definition Solution delivery Analizzare i fabbisogni informativi Individuare le opportunità di miglioramento Definire il Modello dei nuovo Sistema Informativo Gestire e manutenere il nuovo sistema Individuare il prodotto più adeguato Progettare e realizzare il nuovo sistema Definire gli obiettivi Individuare e analizzare i processi operativi Rilevare le criticità e le inefficienze 4

6. Il progetto: le fasi • Requirements definition • disegnare il nuovo modello funzionale del dominio e i processi operativi che lo supportano • definire i macro requisiti funzionali e non del nuovo sistema • individuare le integrazioni necessarie • stabilire vincoli e condizionamenti. 5

7. Il progetto: le fasi • Solution delivery • individuare il prodotto più adeguato • definire le specifiche (tecniche e funzionali) del nuovo sistema • disegnarne l’architettura (dati, funzioni, interfacce, conversioni) coerentemente con le specifiche individuate • realizzare il sistema attraverso la customizzazione del prodotto scelto e le eventuali personalizzazioni • verificarne il corretto funzionamento attraverso cicli successivi di test • formare gli utenti • supportare il passaggio in produzione del sistema. 6

8. Il progetto: le fasi • Operate • fornire il supporto tecnico per la gestione del sistema, con particolare riferimento alla risoluzione dei problemi di gestione ed alla evoluzione delle esigenze degli utenti • definire e monitorare gli obiettivi di servizio (es. performance del sistema) verificando quali sono stati raggiunti e quali invece mancati e indagando i motivi di tali scostamenti • progettare e realizzare gli interventi necessari per riportare il servizio al livello qualitativo previsto. 7

9. Il progetto: la scelta del prodotto t  1980  1990 dal 1990 in poi L’evoluzione storica dei sistemi informativi Applicazioni custom Applicazioni interfacciate Sistemi ERP • Differenti sistemi informativi che supportano diversi processi gestionali • Interfacce limitate e costose tra i diversi sistemi • Ritardi significativi nella definizione dei dati effettivi, dovuti a esigenze di riconciliazione e consolidamento. • Un unico sistema informativo • Le informazioni sono parzialmente isolate, nel senso che esistono strutture dati diverse per informazioni chiave, che devono essere integrate con uno sforzo significativo • Presenza di un numero significativo di processi di elaborazione batch e off-line • Focalizzazione sulla gestione delle informazioni • Un unico sistema informativo • Strutture dati condivise tra tutte le applicazioni chiave con conseguente facilità d’accesso da parte di tutti gli utenti • Tutte le informazioni sono aggiornate in tempo reale, con la virtuale eliminazione delle elaborazioni batch Gestione rilevazione presenze Gestione Amministrativa del Personale Gestione rilevazione presenze Gestione amministrativa del Personale Gestione Amministrativa del Personale Sistema Informativo Gestione rilevazione presenze Sistema Informativo Sistema Informativo Gestione della valutazione e dello sviluppo delle risorse umane Gestione della formazione Gestione della formazione Gestione della valutazione e dello sviluppo delle risorse umane Gestione della formazione Gestione della valutazione e dello sviluppo delle risorse umane 8

10. Il progetto: la scelta del prodotto • I benefici offerti dall’adozione di una soluzione ERP • FORTE INTEGRAZIONE • Le applicazioni sono collegate tra loro in un insieme coordinato. Tutti i moduli lavorano insieme invece di funzionare come applicazioni separate eliminando attività doppie di controllo e verifica • RICCHEZZA DI FUNZIONALITA’ • Le applicazioni sono state sviluppate con riferimento a pratiche e comportamenti operativi consolidati • VISIONE UNITARIA DELLE ATTIVITA’ OPERATIVE • Tutte le applicazioni operano con la stessa base dati eliminando la possibilità di duplicazioni fornendo reporting e analisi coerenti per tutte le attività operative • ORIENTAMENTO AL PROCESSO • Un software ERP è un software progettato con focalizzazione non sulle sole singole funzioni tradizionali, ma sull’intero processo (somma di singole funzioni) che deve svolgersi in modo coordinato ed integrato 9

11. Il progetto: la scelta del prodotto • ELEVATA CONFIGURABILITA’ • La ricchezza di funzionalità e di infotype (gruppi di informazioni omogenee) contenuti in ciascun modulo ERP è tale da consentire la realizzazione del sistema voluto attraverso semplici operazioni di configurazione “guidata” (customizing). • Tanto più il modello funzionale del nuovo sistema coincide con lo standard ERP, tanto più il customizing consente di fornire risposte adeguate, eliminando la necessità di ricorrere ad attività di implementazione. • Rimarranno da sviluppare solo le eventuali interfacce verso i sistemi esterni. 10

12. Il progetto: la scelta del prodotto Definizione titoli per il dipendente 11

13. Il progetto: la scelta del prodotto Inserimento titolo per il dipendente 12

14. Il progetto: la scelta del prodotto Elaborazione gruppi contrattuali e livelli retributivi 13

15. Il progetto: la scelta del prodotto Definizione categoria, livello e voci retributive contrattuali 14

16. Il progetto: la scelta del prodotto I criteri di valutazione adottati nella scelta del prodotto sono • costo della soluzione • affidabilità del fornitore • copertura funzionale • architettura, configurabilità e integrabilità con gli altri sistemi di Ateneo con i pesi indicati nella griglia seguente Il prodotto che ha ottenuto il maggior peso è stato SAP HR 15

17. Recruitment Personnel Administration Payroll Client / Server Sistema di Base Organizational Management Benefits Employ Self Service Additional Functionality Time Il progetto: la scelta del prodotto La struttura applicativa di SAP HR La modularità del prodotto ha consentito di progettare una soluzione che consente di mantenere l’elaborazione delle retribuzioni sull’attuale sistema di Cineca (Consorzio Interuniversitario) 16

18. Il progetto: la metodologia adottata 17

19. Il progetto: la metodologia adottata • Project Preparation & BusinessBlueprint • Le prime due fasi rappresentano il momento di comprensione di dettaglio del contesto e di pianificazione delle attività di implementazione. • Le principali attività sono: • Definizione della struttura del team di progetto • Definizione degli standard di documentazione • Comprensione del contesto tecnico-applicativo • Installazione dell’ambiente di sviluppo e di test del sistema SAP HR • Realizzazione delle interviste di analisi dei processi funzionali • Condivisione delle criticità gestionali dei processi funzionali • Definizione del nuovo modello di funzionamento dei processi funzionali su SAP HR 18

20. Il progetto: la metodologia adottata • Realization • La terza fase è il momento della costruzione del prototipo del nuovo Modello di Funzionamento definito nelle fasi precedenti e dell’analisi degli interventi necessari per adattare ed integrare il sistema standard SAP HR nel contesto tecnico-applicativo di UNITN. Le principali attività sono: • Configurazione di base delle strutture organizzative dei dati e dei processi funzionali di base • Configurazione definitiva dei processi funzionali e verifica della loro coerenza con la realtà di UNITN. Tale attività prevede il raggiungimento della configurazione definitiva tramite l’esecuzione di cicli iterativi di test. • Analisi delle conversioni • Analisi delle interfacce • Analisi degli sviluppi 19

21. Il progetto: la metodologia adottata • Final Preparation • In questa fase si completa la realizzazione del prototipo e si realizzano tutte le attività complementari necessarie all’avvio produttivo del sistema secondo il Modello di Funzionamento definito ed approvato nella fase precedente. Le principali attività sono: • Realizzazione e test dei programmi di conversione • Realizzazione e test dei programmi e delle procedure di interfaccia • Realizzazione e test degli sviluppi e dei report • Preparazione dei manuali utente • Erogazione del training agli utenti finali • Setup del sistema di produzione • Realizzazione delle conversioni sul sistema di produzione 20

22. Il progetto: la metodologia adottata • Go Live & Support • Nell’ultima fase si attiva il nuovo sistema informativo e si assistono gli utenti finali nella realizzazione dei processi gestionali, controllando al contempo il corretto funzionamento tecnico del sistema. Le principali attività sono: • Attivazione del sistema di produzione • Attivazione del servizio di help desk per gli utenti finali • Risoluzione degli eventuali problemi • Controllo sulle performance del sistema e sul volume delle registrazioni effettuate 21

23. Project Management 2003 2004 M G L A S O N D G F M A FASE 1: Gestione Anagrafica e Giuridico-Amministrativa dei Dipendenti  • Business Blueprint • Realization • Final Preparation and Go Live &Support  FASE 2: Rilevazione Presenze & Sviluppo del Personale Supporto Tecnico • Business Blueprint • Realization • Final Preparation and Go Live &Support Il progetto: il piano del progetto La realizzazione del sistema è stata suddivisa in due fasi, la prima a copertura di quanto oggi esistente, la seconda a copertura delle nuove esigenze Il piano iniziale 22

24. Il progetto: il piano della qualità Il Piano della Qualità è un documento che, per singola fase della metodologia adottata, definisce: • il contenuto della fase • gli elementi in input alla fase • gli output della fase • le caratteristiche qualitative degli output • i criteri, i parametri e le modalità di accettazione degli output. 23

25. Gruppo di Lavoro 1 Gruppo di Lavoro 2 Gruppo di Lavoro 3 Il progetto: la struttura e i ruoli del team di progetto Comitato Guida Controllo Qualità Controllo Progetto Supporto Tecnico Team Operativi 24

26. Il progetto: la struttura e i ruoli del team di progetto Il Comitato Guida viene istituito per garantire la massima attenzione e partecipazione al progetto. E’ composto da responsabili di UNITN e da responsabili del fornitore e cura le seguenti attività: • sponsorship del progetto • gestione del cambiamento (promuovere, facilitare, motivare, guidare) • definizione degli obiettivi di medio e lungo termine • controllo ed approvazione dell’avanzamento lavori e verifica del conseguimento degli obiettivi di progetto • verifica e validazione delle scelte effettuate che hanno impatto significativo su organizzazione e processi dell’Ateneo • assegnazione di risorse e priorità, rimozione/soluzione dei problemi che possono impattare su obiettivi, risultati e tempistiche di progetto (gestione del rischio) 25

27. Il progetto: la struttura e i ruoli del team di progetto Il Controllo Qualità è responsabile della definizione del Piano della Qualità e, attraverso il costante collegamento tra il Comitato Guida ed il Controllo Progetto, assicura che il progetto venga condotto nel rispetto degli standard qualitativi previsti e secondo gli obiettivi prefissati. 26

28. Il progetto: la struttura e i ruoli del team di progetto Il Controllo Progetto è responsabile della conduzione del progetto. Ha il compito di presidiare le attività di progetto in termini di contenuti e soluzioni proposte, di stabilire priorità e assegnazione delle risorse: • pianificazione e coordinamento del progetto • stesura, verifica e controllo degli stati avanzamento lavori • integrazione con eventuali altri progetti dell’Ateneo • verifica e validazione delle soluzioni progettuali • coinvolgimento dei responsabili di funzione per le diverse aree • soluzione dei problemi di assegnazione e disponibilità di risorse • comunicazione, attivazione e coinvolgimento del Comitato Guida (preparazione documenti da presentare) • comunicazione verso i Team operativi • verifica ed approvazione eventuali richieste di modifica 27

29. Il progetto: la struttura e i ruoli del team di progetto Il Supporto Tecnico è responsabile della definizione, della creazione e del mantenimento di tutto l’ambiente tecnico di lavoro per il progetto, in termini di: • Hardware • Software • Reti e comunicazioni • Standard architetturali e metodologici • Gestione ambienti di sviluppo, test, produzione • Tuning e performance del sistema 28

30. Il progetto: la struttura e i ruoli del team di progetto I Team operativi hanno la responsabilità di realizzare quanto definito durante la fase di Business Blueprint. Il coinvolgimento dei Key User ha lo scopo di garantire: • la condivisione dei requisiti funzionali • la condivisione delle soluzione applicative • la condivisione della priorità di sviluppo. e di fare in modo che essi diventino gli Utenti di riferimento per l’Ateneo nella gestione giornaliera delle funzionalità e dei processi attivati. 29

31. Il progetto: la struttura e i ruoli del team di progetto Le principali attività che vedranno coinvolti Key User sono: • Verifica dei documenti prodotti nella fase di As-Is. • Validazione del modello di funzionamento SAP che emergerà al termine della fase di Assessment. • Impostazione dei cicli di test che dovranno essere provati sul nuovo sistema. • Raccolta di esempi per ciascun ciclo/fase di test (es.documenti cartacei, report, modulistica etc.etc.) • Partecipazione al training • Self Training utilizzando il sistema disponibile, l’help online ed il supporto che il team di progetto può offrire. • Erogazione del training agli utenti finali • Partecipazione all’analisi delle informazioni disponibili che dovranno essere convertite sul nuovo sistema. • Customizing del sistema SAP 30

32. 2003 2004 L A S O N D G F M A • Business Blueprint • Realization • Final Preparation and Go live & Supporto Project Management Il progetto: le criticità Il progetto a 4 mesi dall’avviamento evidenzia un ritardo di circa 2 mesi sulla pianificazione iniziale della Fase 1 e un incremento in termini di giornate lavorative del 40% 31

33. Il progetto: le criticità • Prima verticalizzazione in Italia • Mancanza di competenze contemporanee di HR SAP e delle peculiarità del contesto universitario • Sottovalutazione dei macrorequisiti funzionali • Durata non prevista della fase di Business Blueprint, dovuta all’esigenza di approfondimenti • Necessità di personalizzazioni specifiche e conseguente impatto sulla manutenibilità del sistema • Aumento sensibile dei costi del progetto. 32