• Non ci sono risultati.

Capitolo 4: Lavoro di stage

4.5. Improve

4.5.2. Individuazione dei requirements informativi

Per individuare i requirements informativi necessari per strutturare il nuovo Sistema Informativo, il Team ha condotto un’analisi critica della struttura informativa dei principali tool usati oggi all’interno del reparto per gestire le richieste di modifica IT (Project Charter, IT Request Form e RichIT/ITAMS) e, infine, ha elaborato un documento (Requirements List) dove sono riportati i requirements necessari per il nuovo processo. Per ogni tool, il Team ha individuato pro e contro.

54 4.5.2.1. Analisi documentazione interna di gestione delle richieste

Project Charter

Figura 15: IT Project Charter

Project Title

Project Description

Goals of the project

Ring (Scope of the project) Business case Modifiche Sistemi IT Modifiche di Processo Ruolo Reponsabile interno Responsabile esterno Responsabile IT Team member Team member Process Owner Champion Macro attività IT Project Charter

Insert here the TITLE of the project

Insert here the goals you want to achieve with this project Insert here an explanation of the project

Define what is included in the project

Team

Stato di avanzamento

0%

Nome Telefono e-mail

Data inizio prevista Data chiusura prevista

0% 0% 0% 0%

Describe the benefits

55 Il Project Charter è un documento che viene utilizzato per sancire l’avvio di grandi progetti IT. Esso risponde ad un’esigenza di maggior formalizzazione nel caso di progetti che coinvolgono più persone (per esempio progetti multi-company e/o cross - funzionali).

È strutturato in due sezioni. La prima ha l’obiettivo di inquadrare l’ambito di riferimento, lo scope del progetto, gli obiettivi che si intende raggiungere e fornisce anche delle indicazioni sul business case. La seconda è operativa e supporta l’attività di pianificazione: essa contiene informazioni sui membri del team che lavoreranno sul progetto e una check – list delle macro-attività previste, con una stima delle date di inizio e fine e uno spazio dedicato all’aggiornamento dello stato di avanzamento.

Pro:

- Chiara definizione di ruoli e responsabilità dei soggetti partecipanti; - Chiara definizione delle attività;

- Tentativo di utilizzare un unico supporto per gestire fasi diverse del ciclo vita della richiesta (la sezione dedicata alle attività, infatti, prevede anche un campo dedicato allo “Stato di Avanzamento”);

- Chiara definizione dello scope del progetto.

Contro:

- Manca il legame fra le attività e i relativi responsabili;

- Mancano le informazioni necessarie per valutare la richiesta in base all’impatto sul business.

56 Request Form

Figura 16: IT Request Form

IT REQUEST FORM

Date

Rough effort estimation (LC*) Responsibilities

* LC = local currency

Department (Days/LC) Company

Internal IT (Days/LC)

External Consulting (LC) Department

External Service (LC) CapEx (LC) IT Hub Other costs (LC) Total (LC) Contact (Department) Contact (IT Hub)

1. Initial situation & Need for action

Description of current situation and systems. What is the issue, what is the reason for request?

2. Objective & Intended results

What should be reached by this project? What are the expected benefits? Expected results and their measurement

3. Scope, processes and affected departments

Scope: What must be done? Affected units, processes, systems, modules and programs, dependencies

4. Alternatives & Impact of project rejection

Possible alternatives and their objectives. What is going to happen, if the order is not beeing implemented.

5. Requested schedule Start End 6. Costs & Benefit

Compare project efforts and additional permanent costs in the future with future benefits, e.g. cost savings.

7. Priority Strategic significance Economic significance "Avoid risk"

Value Explanation

Title

Risk in case of project postponement or cancellation Project addresses strategic

company targets and focusses on value adding processes with customers

57 IT Request Form è un altro Foglio Excel che è stato proposto in passato dalla Germania per gestire le richieste di modifica non pianificate.

Il punto di forza di questo strumento è subito evidente e si tratta della procedura prevista di attribuzione della priorità.

Nel dettaglio, è riportato il modello di riferimento per l’attribuzione della priorità alle richieste previsto da questo modulo:

58 Dettaglio del foglio Excel che consente di calcolare la priorità:

Pro:

- Chiara definizione dei costi associati ad ogni richiesta (sezione Rough Effort Estimation); - Presenza di una sezione dedicata alla valutazione della priorità della richiesta, basato su

un modello ben strutturato che tiene conto delle tre connotazioni della priorità: significatività economica, significatività strategica e rischio tecnico;

- È previsto un processo di escalation per revisionare e armonizzare le priorità; - È prevista la collaborazione fra IT e Utenti per la compilazione del modulo. Contro:

- È totalmente assente una sezione dedicata alla pianificazione della richiesta (impegni, attività, risorse coinvolte);

Risk of doing nothing Strategic significance

Economic

significance Indice Priority Authorization

0 0 0 000 na NA 0 0 1 001 na NA 0 0 2 002 105 A 0 0 3 003 106 A 0 1 0 010 na NA 0 1 1 011 na NA 0 1 2 012 107 A 0 1 3 013 108 A 0 2 0 020 109 A 0 2 1 021 110 A 0 2 2 022 111 A 0 2 3 023 112 A 0 3 0 030 113 A 0 3 1 031 114 A 0 3 2 032 115 A 0 3 3 033 116 A 3 0 0 300 301 A 3 0 1 301 302 A 3 0 2 302 303 A 3 0 3 303 304 A 3 1 0 310 305 A 3 1 1 311 306 A 3 1 2 312 307 A 3 1 3 313 308 A 3 2 0 320 309 A 3 2 1 321 310 A 3 2 2 322 311 A 3 2 3 323 312 A 3 3 0 330 313 A 3 3 1 331 314 A 3 3 2 332 315 A 3 3 3 333 316 A

59 - Il documento è nato per gestire solamente la fase di raccolta e di valutazione delle

richieste

Analisi del work-flow del sistema RichIT/ITAMS

Il terzo e ultimo strumento di gestione preso in analisi è il sistema RichIT - ITAMS. Esso è stato sviluppato ad hoc dalle risorse IT su Microsoft Access per gestire le richieste durante la fase di esecuzione. È uno strumento interno al reparto IT e accessibile solo ai consulenti.

Il sistema consente di scomporre ogni progetto in una serie di attività, le quali vengono create ed inviate ai colleghi che devono eseguirle, per questo motivo ogni attività viene definita “chiamata”. Ad ogni richiesta, quindi, corrisponde un flusso di “chiamate”, cioè di oggetti informativi a cui sono associati un responsabile, una descrizione dell’attività svolta, un monte ore speso e altre informazioni. Il risultato è una base dati molto ricca che rappresenta la totalità di attività gestite all’interno del reparto IT.

La schermata iniziale dell’applicazione presenta una serie di pulsanti, uno per ogni funzione diversa.

Ai fini dell’analisi, è stato rilevante soffermarsi sulle seguenti funzioni: - Creazione chiamata;

- Lista chiamate; - Seleziona chiamate; - Lista consuntivi.

60 1. CREAZIONE CHIAMATA

Figura 18: Maschera Gestione chiamata, “Base”

Per inserire a sistema una richiesta, il consulente IT deve riempire la sezione “Dati del Cliente” inserendo le informazioni identificative dell’utente da cui proviene la richiesta, l’oggetto e una descrizione generale.

Nella sezione “Classificazione” deve essere selezionato il tipo di chiamata. Le chiamate possono essere:

- “Job”: attività elementari legate a richieste con IT effort stimato inferiore a 2 giorni,

gestibili direttamente dai consulenti IT senza l’intervento di IT Manager;

- “Project”: questa tipologia di attività può essere aperta solo da IT Manager e si riferisce

ad attività collegate a grandi progetti di sviluppo multi-company e/o multi-function; - “Mainteinance & Operation”: attività legate a chiamate generiche. Il sistema prevede,

infatti, la possibilità di aprire una lista di attività per le consociate; accade spesso che il reparto IT debba spendere del tempo per esse anche se non vengono inviate delle vere e proprie richieste utente. Queste attività devono comunque essere tracciate perché devono essere fatturate.

61 La sezione “Dati generali” riporta informazioni generiche sullo stato della richiesta (“AP” o “CH”), sulla persona che ha in carico la richiesta in un determinato momento, sul ticket assegnato, sulla priorità attribuita e sulle date di inizio e fine.

I campi appena descritti devono essere modificati durante l’esecuzione della richiesta, aggiornando la data prevista di fine attività, lo stato di avanzamento e inserendo regolarmente i consuntivi cliccando sul pulsante “Inserisci consuntivo”.

In ogni momento, inoltre, è possibile ottenere un report collegato alla richiesta di tutte le attività ad essa collegate sia ad uso interno, sia da inviare al cliente.

62

Figura 20: Esempio di report cliente

Figura 21: Maschera Gestione chiamata - "Azioni"

Entrando in una richiesta qualsiasi e cliccando sulla linguetta “Azioni” dalla maschera di “Gestione chiamata” è possibile visualizzare l’elenco delle azioni che sono state fatte nel tempo su quella richiesta ed inserirne di nuove cliccando sull’apposito pulsante.

Le tipologie di azioni previste dal sistema sono le seguenti: - Inlog: registrazione chiamata iniziale;

63 - Update: aggiornamento chiamata;

- Route: inoltro della chiamata ad un’altra persona;

- Close: chiusura chiamata;

- Reopen: riapertura di una chiamata precedentemente chiusa.

2. LISTA CHIAMATE

Ogni utente che accede al sistema può visualizzare la lista completa delle chiamate a proprio carico con informazioni su tipologia della richiesta, ticket, priorità, società committente, utente di riferimento, descrizione, IT Effort stimato e stato.

Figura 22: Lista Chiamate per utente

Cliccando su una riga della lista l’utente entra nella richiesta e viene rimandato alla schermata “Gestione Chiamata”.

64 3. SELEZIONE CHIAMATE

Il sistema prevede la possibilità di eseguire delle query e ricercare particolari richieste compilando degli appositi campi di ricerca.

Figura 23: Query di ricerca delle chiamate

4. LISTA CONSUNTIVI

Ultima funzione analizzata è quella che permette di estrarre il report in formato pdf di tutti i consuntivi inseriti da ogni utente. Questa funzione è particolarmente importante in prossimità della scadenza del trimestre, in occasione della quale il reparto IT deve conteggiare il totale delle ore che deve fatturare ai clienti.

I consuntivi, visualizzati sia in ore che in giorni, si riferiscono a delle categorie di attività, le quali vengono selezionate dal consulente nel momento in cui inserisce il consuntivo.

Esse sono:

- Customizing;

- Gestione/Correzione anomalie; - Test delle modifiche;

- Carico/Aggiornamenti dati; - Project Management; - Help desk/Consulenza; - Formazione utenti.

65

Figura 24: Report Consuntivi

I vantaggi che il Team ha individuato nel sistema RichIT/ITAMS sono i seguenti:

- Presenza di un database centralizzato con tutte le informazioni necessarie per ricostruire la storia di ogni richiesta, risalendo a chi l’ha elaborata e a tutte le attività collegate, e per consultare tutta la documentazione collegata e ottenere dei report con le voci da fatturare alle consociate;

- Ottima alternativa alle e-mail per le comunicazioni interne fra le risorse IT; - Gestione per stati delle richieste;

- Gestisce molte fasi del ciclo vita di ogni richiesta, dall’esecuzione alla consuntivazione. Per contro, le mancanze individuate sono:

- Manca l’interazione con gli utenti, non viene gestita la fase preliminare di raccolta e analisi delle richieste;

- È un buono strumento di gestione a livello operativo, ma se manca un lavoro di raccolta, analisi e valutazione preliminare efficace, lo strumento perde di validità;

66 Requirements List

Partendo, quindi, da quanto di buono è stato trovato nell’attuale Sistema di Gestione e tenendo presenti gli obiettivi dell’intervento di miglioramento, ovvero risolvere i punti critici evidenziati dall’analisi as-is del processo, è stata prodotta la Requirements List, ovvero la lista di tutti i requisiti informativi che il nuovo Sistema dovrà avere.

67 Processo To-Be

Utilizzando come input la Requirements List e le considerazioni conclusive ottenute con il benchmarking, il Team si è riunito ed è giunto alla definizione del processo To-Be di gestione delle richieste.

A livello macro il processo è stato così strutturato:

Tabella 4: Processo To-Be

Scendendo più nel dettaglio, sono indicate di seguito fasi, i relativi responsabili e le informazioni che è necessario raccogliere ad ogni step :

68 Fasi: 1. Request Description; 2. Request Analysis; 3. Solution Description; 4. Request Evaluation; 5. Planning; 6. Execution; 7. Review. Responsabili: 1. Requester; 2. Demand Manager; 3. IT Request Manager; 4. IT Specialist.

70 Vincolo: il Team ha ritenuto valido il modello di prioritizzazione presente sul Request Form e ha deciso di mantenerlo inalterato anche nel nuovo Sistema.

Specifica del SI

Analisi costi-benefici e confronto fra diversi strumenti

Di seguito vengono illustrate brevemente le considerazioni che sono state fatte per i vari strumenti disponibili su cui strutturare il nuovo Sistema di Gestione.

Le soluzioni prese in esame sono state confrontate sulla base dei seguenti driver: 1) Completezza25;

2) Rapidità di installazione; 3) Costo di programmazione; 4) Scalabilità26;

5) Orientamento all’intero ciclo vita; 6) User-friendliness;

7) Grado di interattività con l’utente.

- RichIT/ITAMS: è sicuramente il sistema più completo a disposizione, tuttavia è

necessario estenderne l’utilizzo agli utenti. Questo comporta la necessità sia di richiedere l’aiuto di un programmatore esperto, sia di installare una versione

25 Per “completezza” si intende la capacità del sistema di racchiudere al suo interno tutte le variabili necessarie per spiegare un fenomeno.

26 In informatica e in altre discipline, la “scalabilità” denota la capacità di un sistema di aumentare o diminuire di scala in funzione delle necessità.

71 compatibile di Access sui pc di tutti gli utenti, cosa non banale considerando che il sistema deve essere accessibile agli utenti di tutte le aziende consociate sparse nel mondo.

- Ticketing System: è stata presa in considerazione anche l’ipotesi di acquistare un

sistema di ticketing già disponibile sul mercato. Questa soluzione è stata apprezzata per la rapidità di installazione e la velocità di utilizzo. I sistemi analizzati, tuttavia, sono risultati carenti e troppo lontani dalla specificità del processo da gestire.

- Microsost Excel: soluzione migliore in termini di rapidità di programmazione e di

facilità di utilizzo. Manca, tuttavia, la possibilità di garantire una relazione interattiva con l’utente.

- Microsoft SharePoint: sistema già presente e già conosciuto da tutti i dipendenti

Perini. È stato inoltre apprezzato per la facilità di programmazione, per la capacità di gestire l’intero ciclo vita delle richieste e per la possibilità di sviluppare applicazioni interattive con l’utente e scalabili.

Documenti correlati