Software Engineering RAD: Case Study Human ResourceSystem RAD: Case Study Human Resource System L’esperienza dell’Università di Trento 3 novembre 2003.

Presentazione sul tema: "Software Engineering RAD: Case Study Human ResourceSystem RAD: Case Study Human Resource System L’esperienza dell’Università di Trento 3 novembre 2003."— Transcript della presentazione:

1 Software Engineering RAD: Case Study Human ResourceSystem RAD: Case Study Human Resource System L’esperienza dell’Università di Trento 3 novembre 2003

2 Software Engineering 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) Il progetto: le motivazioni 1

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

4 Software Engineering 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 Il progetto: gli obiettivi 3

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

6 Software Engineering 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 Software Engineering 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 Software Engineering 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 Software Engineering Il progetto: la scelta del prodotto Applicazioni custom 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. SistemaInformativo GestioneAmministrativa del Personale Gestione della valutazione e dello sviluppo delle risorse umane Gestionedellaformazione Gestione rilevazione presenze Applicazioni interfacciate SistemaInformativo GestioneAmministrativa del Personale Gestionerilevazionepresenze Gestione della valutazione e dello sviluppo delle risorse umane Gestione della formazione 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 Sistemi ERP 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 SistemaInformativo Gestione della formazione Gestione della valutazione e dello sviluppo delle risorse umane Gestione rilevazione presenze Gestione amministrativa del Personale t L’evoluzione storica dei sistemi informativi  1980  1990 dal 1990 in poi 8

10 Software Engineering 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 Software Engineering 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 Software Engineering11 Il progetto: la scelta del prodotto Definizione titoli per il dipendente

13 Software Engineering12 Il progetto: la scelta del prodotto Inserimento titolo per il dipendente

14 Software Engineering13 Il progetto: la scelta del prodotto Elaborazione gruppi contrattuali e livelli retributivi

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

16 Software Engineering 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 Software Engineering Il progetto: la scelta del prodotto La struttura applicativa di SAP HR Client / Server Sistema di Base Personnel Administration Recruitment Organizational Management Time Employ Self Service Additional Functionality Benefits Payroll 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 Software Engineering Il progetto: la metodologia adottata 17

19 Software Engineering Il progetto: la metodologia adottata Project Preparation & Business Blueprint 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 Software Engineering 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 Software Engineering 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 Software Engineering 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 Software Engineering 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 progetto: il piano del progetto Supporto Tecnico MGLASONDGFMA 20032004 FASE 1 : Gestione Anagrafica e Giuridico-Amministrativa dei Dipendenti FASE 2 : Rilevazione Presenze & Sviluppo del Personale Project Management Realization Final Preparation and Go Live &Support Business Blueprint Realization Final Preparation and Go Live &Support Business Blueprint Il piano iniziale 22

24 Software Engineering 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. Il progetto: il piano della qualità 23

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

26 Software Engineering 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à: 3sponsorship del progetto 3gestione del cambiamento (promuovere, facilitare, motivare, guidare) 3definizione degli obiettivi di medio e lungo termine 3controllo ed approvazione dell’avanzamento lavori e verifica del conseguimento degli obiettivi di progetto 3verifica e validazione delle scelte effettuate che hanno impatto significativo su organizzazione e processi dell’Ateneo 3assegnazione di risorse e priorità, rimozione/soluzione dei problemi che possono impattare su obiettivi, risultati e tempistiche di progetto (gestione del rischio) 25

27 Software Engineering 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 Software Engineering 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: 3pianificazione e coordinamento del progetto 3stesura, verifica e controllo degli stati avanzamento lavori 3integrazione con eventuali altri progetti dell’Ateneo 3verifica e validazione delle soluzioni progettuali 3coinvolgimento dei responsabili di funzione per le diverse aree 3soluzione dei problemi di assegnazione e disponibilità di risorse 3comunicazione, attivazione e coinvolgimento del Comitato Guida (preparazione documenti da presentare) 3comunicazione verso i Team operativi 3verifica ed approvazione eventuali richieste di modifica Il progetto: la struttura e i ruoli del team di progetto 27

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

30 Software Engineering 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: 3la condivisione dei requisiti funzionali 3la condivisione delle soluzione applicative 3la 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. Il progetto: la struttura e i ruoli del team di progetto 29

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

32 Software Engineering 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% LASONDGFMA 20032004 Final Preparation and Go live & Supporto Business Blueprint Realization Project Management 31

33 Software Engineering 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. Il progetto: le criticità 32