CRM AISM - e-Lite

Business Analysis
Emiliano Castellina
Senior Consultant
Presentazione
Reply è una società di Consulenza, System Integration e Application
Management.
Reply unisce competenze verticali di mercato, con il dominio di tecnologie innovative,
quali ad esempio, Social Networking, Cloud Computing e Internet degli Oggetti, per
ottimizzare ed integrare processi, applicazioni e dispositivi.
2
Business Analyst
• Competenze del business analyst
– Informatico o Gestionale?
• Competenza nelle basi dati
– Uno strumento importante per l’analista è l’estrazione ed elaborazione
di dati significativi per poter prendere le decisioni corrette.
– Se è autonomo del farlo non deve affidarsi all’aiuto dell’amico
informatico.
• Conoscenza dei processi oggetto dell’analisi
– Processi aziendali relativi a
•
•
•
•
gestione del customer care
processo vendite
campagne di marketing
gestione delle risorse umane
• Essere aggiornati sulle «nuove» tecnologie
3
Analisi nel ciclo di vita di un Progetto
Commerciali
Manager Sviluppatori
Advisory
Relazione
Tecnica
(Prototipo)
Go Live
User Acceptance
Test
Assistenza
4
Analisti
Cliente
(dirigente)
Cliente
(Utente)
Change
Manager
Analisi
Kick Off
Test Funzionali
• Raccolta Requisiti
• Stesura Analisi
Funzionale
• Definizione Test Case
Sviluppo
Analisi come servizio
Analisti
Manager Sviluppatori
Cliente
(dirigente)
Cliente
(Utente)
Change
Manager
Analisi
Nuovi requisiti
Go Live
5
• Raccolta Requisiti
• Stesura Analisi
Funzionale
• Definizione Test Case
User Acceptance
Test
Sviluppo
Test Funzionali
Niente Analisi!?!
Commerciali
Advisory
Analisti
Manager Sviluppatori
Cliente
(dirigente)
Relazione
Tecnica
Cliente
(Utente)
Change
Manager
Sviluppo
Go Live
6
Niente Sviluppo!?!
Commerciali
Advisory
7
Analisti
Manager Sviluppatori
Cliente
(dirigente)
Cliente
(Utente)
Change
Manager
Relazione
Tecnica
Analisi
(Configurazione)
(Go Live)
(User
Acceptance Test)
(Test funzionali)
Raccolta dei requisiti
• Modalità
– Email: i requisti vengono definiti con uno scambio di email con gli utenti.
(Frequente nella modalità di analisi a servizio, raro negli altri casi)
– Meeting con gli utenti.
– Normativa: talvolta il requisito è costituito da gestire o modificare un processo
per rispettare una normativa specifica (ad esempio manovra Monti, legge
antiriciclaggio).
• Strumenti Utilizzati
– Carta e Penna, o PC, o tablet (per essere più cool)
– Pazienza
8
Analisi Funzionale e Analisi Tecnica
• Analisi Funzionale
– Formalizza i requisiti di business ed i vincoli progettuali
– Elabora soluzioni di alto livello comprensibili all’utente finale
– Fornire indicazione agli sviluppatori per poter redigere analisi tecnica
• Analisi Tecnica
– Progetto vero e proprio del software/funzionalità che sarà sviluppata
– Dipendente dalla tecnologia utilizzata
– Tipicamente non comprensibile all’utente finale
• Analisi Funzionale Ibrida
– Formalizza i requisiti di business ed i vincoli progettuali
– Elabora soluzioni di alto livello comprensibili all’utente finale
– Progetto del software/funzionalità che sarà sviluppata
– Comprensibile all’utente
– Sufficiente agli sviluppatori per poter implementare il software
9
Analisi Funzionale Strumenti Utilizzati
• Dipende dalle scelte del cliente
• Tipicamente non utilizzati diagrammi UML
• Si preferisce allo «standard» una rappresentazione
– più semplice
– graficamente accattivante
10
Analisi Tecnica – Strumenti Utilizzati
• Concordato con gli sviluppatori
• Standard UML (o quasi)
• Utilizzo di tool che permettano una trasformazione automatica da diagrammi
UML a codice
– Esempio tipico: trasformazione da Modelli ER a codice SQL.
11
Analisi Funzionale Ibrida– Strumenti Utilizzati
• Dipende dalle scelte del cliente
• Utilizza solo in parte diagrammi UML
• Si preferisce allo «standard» una rappresentazione
– più semplice
– graficamente accattivante
• Talvolta vengono utilizzati tool che permettano una trasformazione
automatica da diagrammi UML a codice
12
Use Case e Test Case
• Use Case
– Definiti all’interno del documento di analisi funzionale
– Raramente definiti con diagrammi UML
– Utilizzati per elaborare la lista di test case
• Test Case
– Non sono Unit Test di sviluppo
– Devono essere comprensibili all’utente
– Devono considerare tutti gli Use Case definiti nell’analisi
– In caso di progetto di nuove funzionalità, devono verificare che il software nel
suo complesso continui a funzionere come prima (Not regression test)
13
Tips & Tricks
• Durante la raccolta dei requisiti evitare di
– Proporre soluzioni immediate spinti dall’euforia del momento
• Il requisito emerso dalla discussione deve essere analizzato adeguatamente
– Confermare effort/tempi senza aver analizzato il problema
<<Allora secondo te in una settimana ce la si fa?>>
– Assecondare a priori le soluzioni già trovate dal cliente
<<Avremmo pensato che non ci serve aggiungere un campo per il codice
fiscale, tanto abbiamo il campo note disciplinari che è sempre vuoto!!!>>
<<Noo, non ci serve l’inserimento facilitato delle date con il calendario. Ai nostri
utenti va benissmo il sistema vecchio in cui devono scrivere
2014-01-16T09:52:00+00:01 >>
14
Tips and Tricks
• Non fidarsi degli utenti
– Progettere applicazioni «blindate», a prova di utenti «creativi»
• Il sistema deve previre l’uso errato da parte degli utenti.
– Errato ordine di esecuzione di comandi/funzionalità
– Errato o mancato input
• Richiesta conferma per operazioni critiche
– Documentarsi e Verificare le verità assolute emerse durante la raccolta dei
requisiti
• Non vi preoccupate, non si verificherà mai che ...
• La legge 80/2020 prevede che ....
• No, questa cosa non ci serve proprio, noi facciamo così ...
– Progettare sistemi di log efficaci
• Per prevenire richieste di assistenza del tipo <<Ho cliccato lì come al solito e il sistema
oggi non funziana>>.
• Per evitare il paradosso del tecnico informatico: quando l’utente cerca di replicare il
problema davanti ad un tecnico (o persona che potrebbe risolverlo) il problema non si
verifica.
15
Tips and Tricks
• Progettare Soluzioni Generali
Esempio (ispirato ad un progetto reale).
Requisito: Enanchement del sistema per visualizzare l’etichetta (TAX FREE) in tutti i report
affianco ai clienti tedeschi e francesi.
Anagrafiche presenti nel sistema:
- Cliente (Nome, Cognome, ...., Nazione)
- Nazioni (Nome Nazione, Nazionalità, Codice ISO)
16
Tips and Tricks
Progetto 1:
- hard coding della generazione delle etichette a livello di codice.
if(user.Nazione.Nome=='Germania' or
user.Nazione.Nome=='Francia'){
Stampa("TAX FREE "+user.NomeCognome());
} else {
Stampa(user.NomeCognome());
Germania
}
e Francia!?!
No, avevo detto
Germania e Finlandia
17
Pro
Contro
• Minor costo
• Risponde
esattamente ai
requisiti
• Non permette di
gestire facilmente
cambi di specifica
• Non permette di
evolvere il sistema in
futuro
Da domani,
l’etichetta dovrà essere
stampata solo se il
cliente è francese
Tips and Tricks
Progetto 2:
- aggiungere un parametro di configurazione che indica per quali nazioni si debba stampare
l’etichetta FREE TAX.
if(parametroConfigurazione.Contiene(user.Nazione.
Nome)){
Stampa("TAX FREE "+user.NomeCognome());
} else {
Stampa(user.NomeCognome());
}
Pro
Contro
• Permette ai
• L’utente non è in
configuratori di
grado di apportare le
sistema di modificare
modifiche da solo
facilmente il
comportamento del
sistema
18
Da domani,
l’etichetta dovrà essere
stampata solo se il
cliente è francese,
come posso fare?
Tips and Tricks
Progetto 3:
• arricchire l’anagrafica delle nazione con un campo che indichi se stampare o no l’etichetta
FREE TAX
• Rendere possibile la modifica del nuovo campo dell’anagrafica nazioni agli utenti
if(user.Nazione.StampaTaxFree){
Stampa("TAX FREE "+user.NomeCognome());
} else {
Stampa(user.NomeCognome());
}
19
Pro
Contro
• Permette agli
utenti di
modificare in
autonomia il
sistema
• Richiede un
effort di test e
sviluppo
maggiore
Bene, ora vorremmo
una funzionalità
che stampasse
l’etichetta DISCOUNT
per i clienti italiani.
Tips and Tricks
Progetto 4:
• progettare una nuova funzionalità, che permetta all’utente di definire per ogni report, le
etichette da stampare in base alla nazionalità del cliente.
– Nuova tabella ReportNazioneEtichetta
– Nuova funzionalità di front-end per l’editing
Pro
Contro
• Massima • Costo
flessibilità
elevato
Fantastico, ma.......
COSTA TROPPO.
20
Tips & Tricks
• Eseguire User Acceptance test specifici
Ipotiziamo che nell’esempio precedente si sia scelta la soluzione 2, 3 o 4.
Conversazione con un utente durante gli user acceptance test.
Analista: come hai potuto leggere dall’analisi funzionale, il nostro sistema permetterà in oltre di
configurare per quali nazionialità stampare l’etichetta FREE TAX.
Per esempio, ora configuro Giappone e Tunisia e stampo.. Vedi tutti i giapponesi e tunisini
hanno la scritta FREE TAX.
Utente: Ma non funziona, avevamo chiesto i tedeschi e i francesi così non va bene!!!
Analista: era solo un esempio per far vedere che il sistema era configurabile. Guarda ad
esempio posso selezionare facilmente tutte le nazioni.
Utente: ma no, non deve funzionare per tutte le nazioni.
Analista: ehm.... Ok, ho capito, guarda configuro Francia e Germania...
Utente: ora sì che funziona!!
21
Tips & Tricks
• Considerare sempre i dati
Quando si ha la fortuna di poter accedere ai dati del sistema informativo,
essi vanno sfruttati il più possibile per:
- Decidere di non sviluppare nessuna nuova funzionalità.
- Nell’esempio procedente dall’analisi dei dati è emerso che l’azienda ha
solo 5 clienti Francesi ed 1 Tedesco.
- L’ufficio vendite stima che il portafoglio clienti non crescerà nei
prossimi anni in maniera rilevante.
- Risulta più conveniente non apportare alcuna modifica al software, e
far dedurre le tasse manualmente agli operatori prima di emeterre la
fattura.
- Fare test mirati che coprono una percentuale elevata di casi
- E’ raramente possibile effettuare test esaustivi
22
Tirocinio,Tesi, Lavoro?
• Analisi integrazione canali social nel Crm Microsoft
Dynamics 2013.
• Twitter come canale efficace di customer care.
• Analisi comparativa di strumenti di sentiment analysis,
come misura della reputazione dell’azienda.
23
Contatti
www.reply.eu
[email protected]
Emiliano Castellina
[email protected]
24