Gestione delle Imprese Informatiche Lezione 13 Padova, 1 ...amonti/GII 2007 - Lezione 13.pdf ·...

Gestione delle Imprese Informatiche - Lezione 131

Gestione delle Imprese Informatiche

Lezione 13

Padova, 1 Marzo 2006

Andrea Monti


Approcci al Job design

Implementazione e aspetti organizzativi

Impatto dell’IT sulle scelte organizzative

Classificazione dei sistemi informativi (SI)

Project management e sistemi informativi

Pianificazione strategica e progettazione dei SI

Selezione dei progetti informatici

Controllo dei progetti informatici

Ricerca empirica su alcune aziende IT italiane


� Adam Smith: specialization

� gains from trade, efficiency

� economizes on human capital investments

� Frederick Taylor: industrial engineering

� figure out the single most efficient process & replicate

� squeeze out variations & uncertainty

� replicate, get economies of scale

� Effects

� assembly lines, long runs, narrow product lines

� centralized quality control

� job design: specialization, low skills, few decision rights

Job Design: l’approccio tradizionale

La Ford “T”: potete

averla di qualunque

colore, purchè nera!


Job Design: Trend più recenti

� Recently there has been a trend away from the classical

approach

� consider these survey data on org. changes in Britain

� Where

� emphasis on continuous improvement, quality

� modern mfg. & flexible production

� white collar work

� R&D

� With “Modern” design, more emphasis on

� teams

� careful recruitment, job rotation, cross training

� pay for knowledge, team incentives

More Less

Tasks 63% 6%

Responsibility 46% 3%

Required skills 50% 4%

% of Employees With

Effects of Org. Change

Fonte: Michael Gibbs, 2005


La leve più utilizzate: 1) Intrinsic Motivation

Autonomy

Responsibility for

outcomes of work

Knowledge of actual

results of workFeedback

Skill Variety

Task Identity

Task Significance

Meaningfulness of workIntrinsic motivation

Quality

Low absenteeism &

turnover

Psychological statesCore job

characteristics

Work outcomes


La leve più utilizzate: 2) Skill (& Task) Variety

� To provide “involvement & stretch”

� i.e., learning makes the job more intrinsically motivating

� implication: job enrichment, not specialization

� multitasking & multiskilling

� In addition to a psychological effect, job enrichment also

helps develop specific knowledge

� doing multiple interdependent tasks improves learning

� workers see how tasks affect each other, improving

productivity on each task

� learning how to improve quality, speed up work, reduce

costs, etc.

� this effect is more likely when work is complex &

unpredictable


I due approcci dominanti al Job & Organizational Design

� Classical: ex ante optimization (Taylorism) of methods

� has substantial advantages if you can figure out best

practices ex ante

� effective use of central knowledge (e.g., talented

engineers)

� all workers use best practices

� strong coordination & control (e.g., consistent output)

� Modern: continuous improvement

� more evolutionary approach

� effective use of knowledge at lower levels

� requires “knowledge management” to share best

practices

� creates coordination & control problems


Quando utilizzare l’approccio “classico”?

� Consider the Classical approach as an investment

� up-front cost of optimization, amortized over future productivity gains

� What does the return of ex ante optimization depend on?

� costs: how difficult is the optimization?

� how complex is the process? the product? the product line?

� how stable was our history? have we already figured out best methods because we’ve done the same thing for a long time?

� how predictable is the environment? do things change constantly? can we foresee all contingencies & plan for them?

� benefits:

� how stable & predictable is our future expected to be? is our

technology changing rapidly? is competition dynamic? will we have to re-optimize soon?

� Emphasize ex ante optimization if environment is simple, stable &

predictable; otherwise emphasize continuous improvement


� Why the trend toward “empowerment,” etc.?

� Taylorism less effective now ⇒ more scope for continuous improvement

� time based competition

� complex product lines; frequent changes

� rapid technological advances

� emphasis on quality & service rather than cost

� ⇒ job enrichment-type approaches are more effective

� cultural change?

� Illustrates importance of “External Fit” of org. design w/

product, technology, & industry conditions

Quando utilizzare l’approccio “moderno”?


Alcune considerazioni

� Not all jobs should be enriched

� what can be routinized, usually should be

� or even automated, computerized

� Specialization & job enrichment are often balanced through

job rotation

� Use a mix of both approaches

� centralized tends to work better for major, one time

disruptions (e.g., technology changes)

� & improves knowledge management / transfer

� decentralized tends to work better for incremental changes

� & for implementation / tactics: decision management v.

control

� both are needed for different types of adaptation


Implementazione dell’approccio “moderno” (1/3)

1. Focus on multi-tasking more than multi-skilling

� what kind of learning? new skills v. process & product improvements �

2. Bundle complementary jobs

� doing

� skills, information & equipment

� proximity (physical or temporal)

� results: parts or processes that work closely together

� focus on providing learning opportunities

� examples

� repeat work for same client

� direct relationships with client

� vertical loading (“doing” v. “controlling” or reducing decision control)

3. Modularize the process (Task Identity)



4. Decentralize (Autonomy + Feedback)

� b/c workers have more specific knowledge in enriched jobs

� have employees collect performance metrics & monitor

themselves

� teach employees to identify problems, suggest solutions,

experiment

� e.g., Juran on TQM (1989)

� analyze symptoms

� theorize causes

� test theories

� establish causes

� simulate a remedy

� test remedy under operating conditions

� establish controls to hold the gain



5. Choose other policies for “Internal Fit”

� teams

� to achieve modularity / Task Identity

� for collaborative problem solving

� cross training & job rotation

� career policies

� careful recruitment to achieve proper “Growth Need

Strength”

� cross training & job rotation

� training – in particular, in problem solving

� culture

� overall goal / mission & teamwork

� incentives

� may not be needed & avoid punishment to encourage airing

of problems & ideas

Domanda: lavoratori

felici sono sempre più

produttivi?


The Non-Wisdom of Teams

� Team = “committee”: group decision making

� appoint a team leader, supervisor, or other dispute resolution

mechanism

� separate out decision management from decision control

� teams are more for ideas & implementation; clearly

separate ultimate authority

� Free rider effects

� Barolo v. Chianti at a group dinner

� a problem of performance evaluation (next class)

� what to do?

� reward the group, & accept free riding

� reward the individual & get less teamwork

� encourage establishment of productive group norms


When to Use Teams

� When the optimal task bundle (module) is too much for one worker

� look for strong complementarity across workers’ jobs

� For integration across function

� Benefits

� specialization combined with continuous improvement

� individuals focus at a point in time, but become generalists over time

� use job rotation & cross training w/in the team

� knowledge transfer

Tor’s tasks

Kate’s tasks

Tor’s tasks

K

T

Kate’s tasks

Mechanic’s tasks

Accountant’s

tasks

Tasks

A’s

informa-

tion set

B’s

informa-

tion set

Informazioni parzialmentesovrapposte

Informazioni sostanzialmentedisgiunte

Informazioni completamentesovrapposte


Le strutture organizzative più utilizzate: la struttura funzionale

ProduzioneLogistica e

distribuzioneMarketing e

Vendite

Customer service e

postvendita

AD/DG

Amministrazione,

Finanza e Controllo

Personale e Affari

Legali

Acquisti

Sistemi informativi

Funzioni di

staff

Business lines


Le strutture organizzative più utilizzate: la struttura divisionale

Business unit 1

AD

Amministrazione,

Finanza e Controllo

Personale e Affari

Legali

Acquisti

Sistemi informativi

Funzioni di

staff corporate

Business units

Al crescere della

complessità: geographies,

mercati, business lines …

ProduzioneLogistica e

distribuzioneMarketing e

Vendite

Customer service e

postvendita

Business unit 1Business Unit

Manager

Funzioni di staff a

livello divisionale

Stabilimento 1 Country 1

Country NStabilimento N


Le strutture organizzative più utilizzate: la struttura matriciale

Mercato 1

AD

Amministrazione,

Finanza e Controllo

Personale e Affari

Legali

Acquisti

Sistemi informativi

Funzioni di

staff corporate

Business units

Al crescere della

complessità: geographies,

mercati, business lines …

… Mercato N

Servizio/Prodotto A

Servizio/Prodotto B

Servizio/Prodotto Z

Direttore

commerciale

Responsabile

sviluppo offerta

Cliente

Account team



� De-layering hierarchies?

� Faster decision making?

� Larger or smaller firms?


Impatto dell’IT suli processi decisionali

� Decentralizing?

� facilitates product complexity, time-based competition, etc.

� facilitates better collection & use of specific knowledge in real-

time

� lower-level employees have access to more info. & better

analysis tools

� facilitates ad hoc communication & groups

� Centralizing?

� fewer layers, geography less important

� central monitoring & direction become easier

� much knowledge becomes general, not specific (e.g., expert

systems)

� Often end up with more decentralized “ends,” centralized core

support, less middle mgt.

� e.g., re-engineering


Impatto dell’IT sul Job Design

� Computers are the perfect employees …

� what can be automated should be

� What tasks do computers (or machines) have comparative

advantage at? Humans?

� computers & machines

� repetitive, simple, predictable tasks

� rules-based logic

� imperfectly: fuzzy logic & expert systems (Mrs. Fields,

chicken soup)

� humans

� pattern recognition

� abstraction

� creativity


Organizzazioni ad elevata affidabilità

� How can you simultaneously

1. make use of specific knowledge of time & place

2. act quickly

3. achieve high levels of coordination

4. have very low error rates

� Theoretical ideal: “execution matrix”

� in practice: general instructions for 8 units in 13 events

� SOPs, policy manuals, extensive training, etc. are a form of

centralization

� work best in simple, stable, predictable environments

� logical limit: automation; computerization; expert systems

� Next step: train employees in mission, how to think

� if all think the same way, better predictability, coordination &

speed


Alcuni suggerimenti pratici

� Use parallel organizations for different contexts

� low-stress periods

� more centralized, focused on planning

� more hierarchy/decision control, testing

� extensive training, war games, debriefs

� invest in organizational memory

� tendency toward specialized jobs; mastery improves quality

� high-stress periods

� more decentralized, focused on execution

� continuous 2-way communication to coordinate, reduce mis-information & ambiguity

� more egalitarian culture

� Redundancy

� Culture

� encourage devotion to group through recruitment, peer pressure, etc., & constant ferreting out of problems & trying to fix them


Definizione di sistema informativo

“un insieme ordinato di elementi, anche molto

diversi tra loro, che raccolgono, elaborano,

scambiano ed archiviano dati con lo scopo di

produrre e distribuire le informazioni alle persone

che ne hanno bisogno, nel momento e nel luogo

adatto”

- un patrimonio dati;

- un insieme di procedure per acquisire e trattare i

dati e per produrre informazioni;

- un insieme di persone che, in modo diretto o

indiretto, definiscono, gestiscono e controllano tali

procedure;

- un insieme di mezzi e strumenti per il rilevamento,

l’elaborazione ed il trasferimento di dati ed

informazioni;

- un sistema di principi, valori ed idee che

caratterizzano il sistema e che ne determinano il

comportamento.

Definizione Elementi caratteristici


Componenti di un sistema informativo

Assicurare che il contenuto delle informazioni

prodotte:

- sia effettivamente quello desiderato;

- sia messo a disposizione dei soggetti che vi

sono realmente interessati, nel luogo, nel

momento e nel luogo opportuno;

- giunga al soggetto che lo deve utilizzare. Se le

informazioni vengono prodotte in tempo reale, il

decisore potrà avere un’esatta rappresentazione

della situazione, trovandosi quindi nelle migliori

condizioni per operare una scelta consapevole;

- garantisca un giusto equilibrio fra sintesi e

dettaglio, eliminando i dati ridondanti, senza

tuttavia perdere in significatività

Responsabilità del project manager

nell’ambito dei sistemi informativi


Possibili classificazioni dei sistemi informativi (1/4)

- strategiche, di pertinenza della direzione e

correlate alla definizione degli obiettivi e delle

politiche aziendali ed alla scelta delle risorse per

il loro conseguimento;

- tattiche, di pertinenza delle direzioni funzionali

o di divisione, finalizzate ad assicurare un

efficace impiego delle risorse disponibili ed il

controllo sul conseguimento degli obiettivi

programmati;

- operative, che dovrebbero assicurare la

conduzione a regime delle attività aziendali

Anthony (sulla base delle attività aziendali)

- processi decisionali non programmati per il

controllo, la riprogettazione e la modifica dei

processi fisici;

- processi decisionali programmati per la

gestione delle attività di routine del sistema

fisico;

- processi fisici di produzione e distribuzione.

Simon (sulla base dei processi aziendali)



E’ caratterizzato dalla massima

flessibilità

Tende ad essere costante e

coerente

E’ caratterizzato da costanza e

coerenza (nel tempo e nello

spazio)

Presuppone la costruzione di un

modello su richiesta

Prevede un reporting

standardizzato con segnalazione

di situazioni fuori norma

Fa largo uso di modelli

precostituiti (procedure standard)

Accetta l’approssimazione purché

attendibile e giustificata

Pone l’enfasi su tempestività ed

affidabilità

Pone l’enfasi su validità,

precisione, ed accuratezza dei

risultati

E’ prevalentemente rivolto al

futuro o alla “spiegazione di

situazioni trascorse

Consuntiva attività passateE’ orientato verso le attività

correnti

E’ orientato all’efficacia Ricerca tanto l’efficacia quanto

l’efficienza

E’ orientato verso l’efficienza

Richiede il coinvolgimento e

l’uso “attivo” del supporto

Comporta un uso “attento” delle

informazioni

Prevede un uso “passivo”

Supporta attività manageriali o di

staff poco strutturate

Produce informazioni per il

processo di programmazione e

controllo

Copre (integra/sostituisce) attività

impiegatizie

SISTEMA DI SUPPORTO PER

LE DECISIONI NON

RIPETITIVE E POCO

STRUTTURATE

SISTEMA DI REPORTING

DIREZIONALE

SISTEMA DI

ELABORAZIONE DATI



- Sistemi informativi ufficiali gestionali: sono sviluppati, totalmente o parzialmente, dalla funzione sistemi informativi

dell’impresa, su iniziativa della direzione aziendale

- Sistemi informativi privati o individuali, sono creati dalle singole persone, in base ad una propria iniziativa.

- Sistemi informativi esterni sono invece sviluppati da terzi al di fuori dell’impresa

- Sistemi informativi di tipo tecnico sono di solito realizzati internamente da chi possiede competenze in un determinato

ambito tecnologico.

Storicamente, i primi sistemi informativi sviluppati sono stati quelli ufficiali dedicati all’automazione delle attività

operative ed esecutive. Solo successivamente, per estensione da questi, hanno visto la luce i primi sistemi informativi

ufficiali direzionali, studiati cioè per supportare le attività direzionali e di controllo.

Infine, grazie alla crescente diffusione dei personal computer ed alla diminuzione dei costi dell’hardware, è stato

possibile realizzare i primi sistemi informativi individuali direzionali, di reporting e di supporto alle decisioni.

Solitamente il collegamento fra sistemi privati e sistemi ufficiali è unidirezionale: i primi possono prelevare dati dai

secondi utilizzando determinate procedure e chiavi d’accesso, ma non possono in alcun modo apportare delle modifiche

non autorizzate o involontarie alle basi di dati ufficiali, che devono essere mantenute integre e coerenti.

Fra i sistemi informativi di ambiente esterno hanno recentemente assunto un’importanza del tutto particolare i sistemi

interorganizzativi che permettono di stabilire dei collegamenti fra enti e/o aziende diverse attraverso dei flussi

d’informazioni (“network” d’imprese es. tramite scambio elettronico dei dati (EDI)): es. collegamento continuo ed in

tempo reale con i magazzini dei suoi fornitori-> benefici: ridurre sensibilmente gli stock in giacenza con conseguenti

risparmi in termini di capitale circolante, mentre dall’altro si ottiene la certezza di forniture rapide e più sicure.

Sempre fra i sistemi di ambiente esterno è il caso di ricordare come in questi ultimi anni siano nati molti “information

providers”, ossia delle imprese che hanno costituito delle banche dati, solitamente specializzate per settori e/o per

argomenti, alle quali le aziende possono accedere, pagando per il servizio di cui usufruiscono.


Project management: quali differenze?

Avvio della fase realizzativaAvvio della fase realizzativa

Rappresentazione dettagliata del modello si sistema

informativo nelle sue singole componenti

Descrizione delle parti e delle componenti della soluzione

Definizione dell’architettura informatica più appropriata

ed identificazione dei vincoli tecnologici esistenti

Definizione dei piani e delle mappe operative di progetto,

nonché dei vincoli tecnologici esistenti

Descrizione del modello del sistema informativo dal

punto di vista del progettista

Definizione dell’architettura dal punto di vista del

costruttore

Analisi del “business system” dal punto di vista

dell’utente

Definizione dell’architettura dal punto di vista dell’utente

Definizione degli obiettivi che si desidera raggiungereDefinizione degli obiettivi da raggiungere in termini di

cubatura, metratura, forma e dimensioni del progetto

PROGETTO INFORMATICOPROGETTO EDILIZIO

Rilascio e consegnaRilascio e consegna

TestTest

Realizzazione Realizzazione

ProgettazioneProgettazione di basso livello

Analisi funzionaleIngegnerizzazione della soluzione

PianificazionePianificazione

Studio di fattibilitàStudio di fattibilità

Analisi preliminare e “requirement”Analisi preliminare e “requirement”

PROGETTO INFORMATICOPROGETTO EDILIZIO

Caratteri

stiche

salienti

Ciclo di

vita del

progetto


Responsabilità del project manager e cause di fallimento dei progettiinformatici

- seguire ogni fase del ciclo di vita del

progetto;

- mantenere i contatti con il

committente;

- contribuire alla definizione degli

obiettivi e dei vincoli del progetto;

- concorrere alla definizione di

un’ipotesi di soluzione;

- garantire il rispetto dei preventivi di

spesa, delle date di consegna e degli

standard qualitativi concordati con il

committente;

- Sovrintendere alla fase realizzativa e

seguire costantemente tanto il

controllo di qualità del prodotto,

quanto quello dello stato di

avanzamento dei lavori.

Responsabilità del PM

- scarsa preparazione informatica dell’utente;

- insufficiente responsabilizzazione e coinvolgimento del

management funzionale;

- mancanza di rigorose procedure formali nell’accettazione delle

specifiche, nell’analisi costi/benefici e nella programmazione e

controllo di progetto;

- continue ridefinizioni delle esigenze dell’utente rispetto alle

specifiche concordate;

- resistenza al cambiamento e all’innovazione da parte dell’utente

Cause di fallimento (viste dal progettista)

Carenze:

- dovute all’insufficiente preparazione manageriale degli specialisti

dell’area sistemi informativi;

- attribuibili alla scarsa conoscenza ed alla bassa padronanza della

tecnologia informatica da parte degli utenti stessi;

- imputabili ad un eccessiva rigidità e non rispondenza del sistema

informativo alle reali esigenze aziendali;

- riconducibili ad un approccio troppo tecnicistico da parte degli

analisti e dei programmatori;

- attribuibili ad altre cause di varia natura

Cause di fallimento (viste dall’utente)


Principali problematiche progettuali emerse

- Mancanza di fiducia da parte della

direzione aziendale nei confronti delle

tecnologie informatiche, legata

probabilmente ad una visione ancora

troppo tecnicistica e poco manageriale

dei sistemi informativi;

- Accentuata dipendenza delle

probabilità di successo del progetto

dalla personalità e dalla leadership del

capoprogetto.

Leadership del project team

- Carenze dovute a definizioni di requisiti e specifiche funzionali

non sufficientemente chiare e dettagliate (tempi di consegna

eccessivamente ristretti costringono ad affrettare il lavoro di analisi);

- Documentazione di progetto trascura di descrivere con attenzione i

passi che la metodologia deve seguire per garantire il successo della

fase realizzativa;

- Disallineamento di piani strategici e priorità individuate dalla

funzione sistemi informativi

Fase realizzativa

- Incompleta definizione dei ruoli e delle figure professionali che

andranno coperte in futuro;

- Difficoltà nel valutare i ritorni attesi e superare la griglia di

valutazione economico finanziaria con cui la funzione finanza valuta

il progetto (i costi legati sono individuabili con immediatezza,

mentre i benefici sono spesso differiti nel tempo e difficilmente

quantificabili, se non in termini qualitativi)

Disponibilità e impiego delle risorse.


La lesson learned

- Sottovalutazione degli aspetti organizzativi legati al ciclo di vita dei sistemi informativi.

- L’adozione di una nuova soluzione informatica dovrebbe essere anticipata da un’attenta progettazione del

cambiamento organizzativo che essa comporta.

- Non è pensabile modificare radicalmente il sistema informativo in uso senza aver prima stimato l’impatto e le

rilevanze che esso comporta sulla struttura e sul modo di lavorare dell’azienda.

- Il cambiamento è per sua natura sempre conflittuale poiché tende a produrre incertezze ed a modificare una

situazione ormai nota ed usuale ai dipendenti dell’azienda.

- Una particolarità che caratterizza i mutamenti legati alla struttura del sistema informativo aziendale è la

valutazione del peso “politico” che l’informazione ha. L’accesso ed il controllo di fonti ed informazioni conferisce

infatti potere e discrezionalità a chi ne può disporre, mettendolo di fatto in una situazione privilegiata.

- La modifica dei processi organizzativi ed informativi potrebbe pertanto essere ostacolata da chi sente di perdere

influenza ed importanza a causa del minor controllo che può esercitare sulle fonti e sui sistemi d’informazione e di

comunicazione.


Ruolo della funzione sistemi informativi in azienda

Completamente coinvolta;

responsabilità diretta gestione applicativa;

partecipazione nel design;

valutazione costi benefici;

partecipazione alle scelte strategiche

Struttura a più livelli

complessi;

molti specialisti DB

“administrator”;

Infocenter;

staff per la pianificazione;

comitati di guida

interfunzionali

Piani a 3/5 anni;

auditing e check-up del

SI;

scelta collegiale delle

priorità con tutti gli

utenti

Orientato al

coinvolgimento

dell’utenza;

orientato alla

pianificazione ;

sviluppo visto a medio

termine;

gestione ormai

completamente sotto

controllo

L’azienda, ed in

particolare il top

management,

comprende

l’importanza del

sistema in termini di

strategia e ne tiene

conto nella

pianificazione

AVANZATO

In posizione di critica costruttiva;

sensibilità ai costi (addebitati direttamente);

gestione applicativa delegata all’utente

Struttura differenziata:

gestione/sviluppo SI

creano specialisti;

nasce l’interfaccia con gli

utenti;

EDP diventa un’area

separata;

riporto ad alto livello

Budget analitico:

gestione;

sviluppo;

analisi costi e project

management

formalizzato;

priorità realizzative

contratte con l’utente

Orientato alla gestione;

preoccupato della

manutenzione;

attenzione al controllo

progetti e ai costi;

inizio interesse per

indirizzi e strategia DP

Il SI “computer based”

è percepito dalla

direzione aziendale

come uno strumento di

gestione di rilevante

importanza

EVOLUTO

In posizione subordinata o di conflitto;

scarsa consapevolezza sui costi

Si forma una struttura;

EDP gravita attorno al

centro;

riporto non ad alto livello

Primi tentativi di budget

sintetici; scarso utilizzo

di standard;

controllo progetti

informale

Orientato allo sviluppo

applicativo;

primi problemi con

l’utenza manutenuta a

distanza;

comincia a preoccuparsi

anche della gestione

Si riferisce alla fase di

un vero SI “computer

based”, anche se rivolto

prevalentemente al

supporto di attività di

livello operativo

BASICO

Poco coinvoltaDP inserito presso un

cliente;

solo specialisti;

struttura informale

Assente (priorità

realizzative assegnate in

base alle esigenze

momentanee)

Permissivo ed

incoraggiante;

completamente orientato

allo sviluppo applicativo

Caratterizza il

momento

d’introduzione

dell’informatica in

un’azienda e delle sue

prime applicazioni

INIZIALE

RAPPORTI CON L’UTENZASTRUTTURA

ORGANIZZAT.

PIANIFICAZ. E

CONTROLLO

APPROCCIO

MANAGERIALE

DESCRIZIONE

STADIO


Approcci alla pianificazione dei sistemi informativi (evidenze da unaricerca di Earl - London Business School)

- SI visti come un utile strumento di

supporto ai piani strategici/ business

- Il limite è che spesso gli stessi piani

strategici della società vengono

definiti in modo incompleto, causando

disallineamenti fra strategia aziendale

e strategia IT

- Basso grado di coinvolgimento di

utenti e manager di linea dell’area

sistemi informativi.

Orientato al business

- Utilizzo di una ben definita

metodologia per la gestione dei

sistemi informativi aziendali

- Anche se risultati non del tutto

soddisfacenti, ha permesso di

evidenziare le aree di miglioramento.

- Ci si avvale di consulenti esterni,

con rischio di lasciare in secondo

piano il contributo di utenti e manager

di linea

Orientato alla metodologia

- Attribuisce molta importanza a

strumenti formali di pianificazione ed

allocazione delle risorse (es. comitato

per l’informatica, da direzione a-

ziendale e fuzione sistemi informativi)

- Si ottiene un ragionevole

allineamento fra startegia aziendale ed

politiche IT

- Maggiore facilità di coordinamento

dei vari progetti IT

Amministrativo

- Informatica considerata come

possibile fonte di vantaggi competitivi

- Definizione di un’architettura di

sistema informativo funzionale alle

esigenze operative dell’azienda per

tutte le attività che possono avere un

considerevole impatto sul suo

successo competitivo.

- Svantaggio principale: complessità e

ampiezza dei tempi necessari

Tecnologico

- Particolare attenzione alle modalità

di gestione dello di sviluppo di nuove

applicazioni informatiche (progetto).

- Centralità del project manager per

ciò che riguarda gestione/motivazione

del gruppo di lavoro, pianificazione

delle attività da svolgere, controllo del

rispetto degli obiettivi di costi, tempi e

qualità definiti in fase di

pianificazione.

Organizzativo


Approccio tradizionale (waterfall model)

- Individuazione del problema informativo e

analisi delle cause

- Definizione delle esigenze dell’utente e le

caratteristiche funzionali dell’applicazione

da sviluppare

- Studio di fattibilità finalizzato

all’individuazione di una soluzione

- Analisi dei prodotti informatici con

caratteristiche simili presenti sul mercato

(“stato dell’arte”)

- Giudizio di convenienza in relazione

all’onerosità dell’applicazione e ai benefici

attesi, sia tangibili che “soft” (formazione ed

all’addestramento dell’utenza, grado di

“cultura informatica” raggiunto)

- Analisi dei requisiti informativi dell’utente

per definire le funzionalità che

l’applicazione deve soddisfare (“il cosa

fare”), prescindendo, almeno

momentaneamente, dalle modalità attuative

(“il come fare”). Documento di specifica dei

requisiti e definizione del piano progettuale

vero e proprio.

- Progettazione concettuale dell’applicazione

informatica (rappresentazione, in termini di

dati, procedure di elaborazione e i flussi

informativi).

Definizione



- Progettazione fisica del sistema e della

base dati (flussi di lavoro, programmi,

procedure di controllo, funzioni utenti,

supporto hardware necessario, struttura

generale dei programmi richiesti

dall’applicazione, procedure di sicurezza,

verifica periodica e manutenzione.

- Solitamente si scompone l’applicazione in

una serie di moduli (o sottoprogrammi)

attraverso delle tecniche di tipo “top/down”.

Per scomposizioni progressive è cosi

possibile semplificare notevolmente il lavoro

dei programmatori.

- Terminata la fase di progettazione, il

programma viene sviluppato, cioè scritto

secondo determinati linguaggi che originano

il codice. In questa fase sono previsti anche

dei “system test” che dovrebbero accertare,

utilizzando un campione esaustivo di dati, il

buon funzionamento del sistema, ossia che a

fronte di determinati input in entrata,

l’applicazione fornisca le risposte attese in

uscita.

- Progettate, realizzate e documentate le

procedure ed i manuali che utenti finali,

personale operativo ed addetti al “data

entry” dovranno seguire.

Sviluppo



-Test d’accettazione” o collaudo per verificare la sua effettiva rispondenza alle specifiche e consentirne l’avviamento. - Corsi di addestramento e di formazione per il personale utente che deve essere istruito all’utilizzo del nuovo sistema informativo. - Fase transitoria in cui le due applicazioni coesistono, sinché il nuovo sistema non èstato consolidato ed a pieno regime.- Inizia a questo punto la fase di esercizio e di manutenzione del nuovo sistema. Attivitàquali l’immissione dati e la produzione d’informazioni, e manutenzione (correttiva, costituita dagli interventi di correzione ed eliminazione degli errori sfuggiti al controllo di qualità in sede di rilascio; adattiva, ossia le modifiche a cui l’applicazione deve essere sottoposta per poterla rendere adattabile ai cambiamenti dell’ambiente in cui opera; perfettiva, finalizzata all’aggiunta di nuove funzionalità, all’eliminazione di quelle obsolete ed al miglioramento di alcune caratteristiche di qualità del sistema)- Verifica post-realizzativa (innescata da:malfunzionamenti del sistema; attività di controllo precedentemente programmate; verifica del livello di prestazioni del sistema; accertamento dell’aderenza dello stesso agli standard comportamentali previsti; accertata onerosità del sistema a causa della crescita nel tempo dei costi imputabili alle attività di esercizio e manutenzione).

Installazione ed esercizio


Approccio manageriale

- Pianificazione delle risorse: processo decisionale strutturato, formalizzato e documentato tendente a definire i fabbisogni informativi e tecnologici dell’azienda sul medio/lungo termine, a identificare i progetti informatici da sviluppare e a stabilire un piano temporale di allocazione di risorse- L’ambiente che la funzione sistemi informativi si trova a dover gestire èmultiprogettuale- Per i progetti prioritari si procede allo studio di fattibilità (obiettivi da raggiungere; contenuti, rilevanza e priorità dei problemi evidenziati; specifiche funzionali che l’applicazione dovrà soddisfare; individuazione di un’ipotesi di soluzione. - Documento di sintesi sottoposto all’attenzione della direzione aziendale o del “comitato per l’informatica” per una decisione finale- Gli output della fase di selezione e di tempificazione dovrebbero essere: definizione o la revisione del piano informatico pluriennale; definizione di un piano operativo annuale; reperimento e allocazione delle risorse - Aggiornamenti del piano anche con cadenza inferiore all’anno (mensilmente o trimestralmente)

Pianificazione



- Progettare, realizzare ed avviare l’applicazione informatica considerata.- Analisi di dettaglio dei requisiti e delle specifiche funzionali dell’applicazione;- Progettazione concettuale dell’applicazione (modello formale di flussi informativi, procedure e basi di dati)- Progettazione logica dell’applicazione (grado di accentramento o di decentramento)- Progettazione fisica dell’applicazione, definendone le specifiche tecniche in termini di linguaggi di programmazione, struttura e collocazione della base dati, configurazione hardware necessaria, modalità di elaborazione (“batch” o “on-line/real time”) - Per definire con precisione la distribuzione logico/temporale e la durata delle relative attività implementative, ed allocare in modo efficiente le risorse, il project manager èsolito utilizzare strumenti come il Gantt o il PERT- Accorpare all’interno di questa fase: “testing” a livello di singolo programma (“unit test”), di modulo funzionale (“functional test”) e di sistema complessivo (“system test”). - Fase di avvio dell’applicazione con predisposizione di corsi di formazione e d’addestramento dell’utenza, completamento delle procedure per la conversione ed il trasferimento dei vecchi archivi di dati al nuovo sistema informativo; emissione del relativo manuale utente.

Sviluppo



- Attività che rendono possibile l’esercizio, la manutenzione e la verifica delle prestazioni del sistema stesso. - L’importanza che nel modello manageriale viene attribuita alla fase di check-up del sistema informativo. - Attività di controllo che periodicamente vengono condotte sul sistema al fine di verificarne “lo stato di salute”. (“messa in discussione” del sistema stesso). - Il “check-up” mira a stabilire se il sistema informativo è coerente con la strategia e la struttura organizzativa dell’impresa

Gestione


Input per la stima dei costi di sviluppo (Boehm)

- La constatazione che il costo di

un’applicazione informatica aumenta

proporzionalmente al crescere delle sue

dimensioni, ha stimolato le ricerche in tema di

riusabilità del software che hanno poi portato

allo sviluppo dei linguaggi di quarta

generazione. I risultati di questi sforzi hanno

prodotto dei “tools” che permettono di

progettare e di sviluppare nuove applicazioni a

partire da librerie (“repository”) di programmi

precompilati e facilmente integrabili

Numero di istruzioni da codificare

- Persone fortemente motivate, dotate di elevate

capacità professionali e ben coordinate possono

consentire forti aumenti della produttività

individuale e considerevoli riduzioni di costi

Fattore umano

- Tre tipi di software caratterizzati da un grado

di complessità crescente: si tratta di programmi

applicativi, dei programmi di utilità e delle

applicazioni di sistema.

Complessità del programma

- Un’alta variabilità dei requisiti inizialmente

definiti, può provocare un sensibile aumento dei

costi necessari per l’implementazione dei

necessari interventi correttivi. L’importanza di

questo fattore tende a crescere man mano che

l’instabilità viene scoperta o fa sentire i suoi

effetti solo in una fase molto avanzata del

progetto

Stabilità dei requisiti


Elementi per la stima di costi e ritorni di progetti informatici (Cash & McFarlan)

Riduzione del capitale circolante:

-Scorte di materie prime

-Prodotti finiti e ricambi

-Crediti clienti

-Debiti fornitori

Miglioramento del “cash management”

Benefici fiscali

RIDUZIONE ONERI

FINANZIARI

Riduzione di personale

Eliminazione di operazioni o fasi:

-Tempi di risposta

-Throughput

Riduzione di altri costi operativi:

-Ricerca & Sviluppo

-Marketing e commerciale

-Acquisti

-Progettazione

-Produzione

-Controllo di qualità

-Gestione del personale

Maggiore efficacia nel controllo:

- Riduzione di errori

- Limitazione dell’assenteismo

Maggiore coinvolgimento:

-Soddisfazione degli utenti

-Morale complessivo

Mezzi:

-Hardware

-Software di base

Riduzione del personale

operativo

Eliminazione di operazioni

Gestione dei dati:

-Tempi di risposta

-Throughput

RIDUZIONE COSTI

OPERATIVI

Migliore immagine

Maggiore competitività

Aumento del volume d’affari

(al netto dei costi indiretti incrementali)

Prodotti/servizi tradizionali

Nuovi prodotti/servizi

MAGGIORI RICAVI

ESTERNIINTERNI NON EDPINTERNI EDP


Criteri per la selezione dei progetti informatici (Camussone)


I meccanismi di controllo dei progetti informatici

- “Insieme di strutture di responsabilità, processi e strumenti che permettono di verificare il raggiungimento degli

obiettivi del progetto nel rispetto dei tempi, dei costi e della qualità previsti”.

- Definire le strutture di responsabilità per il controllo di un progetto significa di fatto selezionare quali tipologie di

competenze e di professionalità sono necessarie e, di conseguenza, scegliere le risorse che più rispondono ai requisiti

individuati. Se l’impresa è solita lavorare per progetti o qualora il progetto considerato sia di rilevanti dimensioni, la

responsabilità di definire ed impostare il sistema di controllo e di garantirne nel tempo l’efficacia è solitamente

demandata ad un controller di progetto. Se invece il progetto è di dimensioni limitate o se l’azienda lavora solo

saltuariamente per progetti, solitamente è il project manager che definisce il sistema di controllo, seleziona gli

strumenti più opportuni e ne garantisce l’efficacia lungo le diverse fasi del ciclo di vita del progetto.

- Per ciò che riguarda il secondo aspetto del sistema di controllo di progetto, il processo, può essere opportuno

rivedere inizialmente, e poi anche periodicamente, gli obiettivi del progetto, in modo tale da verificarne la

rispondenza alle esigenze dell’utente ed alle caratteristiche dell’ambiente. Già in sede di pianificazione, devono

essere definiti con precisione i “pacchetti di attività” ed i risultati da conseguire in termini di costi, tempi e qualità.

Occorre utilizzare un piano operativo sufficientemente dettagliato che costituisca la base delle attività di controllo di

progetto. In particolare, in relazione al tipo ed alla sequenza di attività previste da questo documento, è necessario

aver definito una serie di “milestones” e di “checkpoint” per i quali risulti utile e significativo: verificare lo stato

d’avanzamento dei lavori, calcolare indici rappresentativi dell’avanzamento del progetto, effettuare stime a finire. E’

opportuno vitare di definire “checkpoint” al termine di attività troppo estese. Verifiche troppo distanziate nel tempo

rischierebbero infatti, da un lato, di perdere parte della loro significatività e della loro affidabilità, e, dall’altro,

d’influenzare negativamente la tempestività degli eventuali interventi correttivi, mettendo in serio pericolo la riuscita

del progetto stesso. Particolare attenzione va dedicata per evitare la “sindrome del 90%”: all’avvicinarsi della

conclusione del progetto, sembra che la produttività del gruppo di lavoro tenda a scendere notevolmente.


Il rischio nei progetti informatici

- Controllare significa anche gestire il rischio progettuale. E’ necessario collegare la pianificazione del sistema di

controllo alle specificità del progetto di volta in volta considerato. Cash e McFarlan hanno definito tre dimensioni

rilevanti: grado di difficoltà complessiva, quello d’innovazione e dimensioni dello specifico progetto considerato.

- Il primo fattore risulta essere strettamente dipendente: dal grado di comprensione di ciò che si vuole ottenere dal

progetto in termini di obiettivi e di risultati; dal grado di strutturazione del progetto stesso, inteso come “il grado di

libertà che il progettista ha nel definire il risultato e le modalità di realizzazione del progetto stesso” . Grado di

strutturazione del progetto e grado di libertà di cui può disporre il progettista risultano essere inversamente

proporzionali: tanto più è elevato il primo, tanto più basso è il secondo.

- In relazione al grado d’innovazione tecnologica del progetto rispetto alle conoscenze di cui l’impresa può disporre

ed all’esperienza che ha maturato su altri progetti analoghi: tanto più un progetto è innovativo, tanto più difficile può

essere prevederne l’evoluzione. Risulta quindi fondamentale l’attività di pianificazione dei “checkpoint” e di

controllo dello stato dei lavori in corrispondenza dei punti individuati.

- Anche le dimensioni del progetto, essendo solitamente correlate positivamente alla sua complessità, implicano un

aumento del grado di rischio del progetto stesso.

- Dall’analisi congiunta di queste tre variabili Cash e McFarlan suggeriscono, in base alle specifiche esigenze del

progetto, l’adozione di alcuni strumenti di due tipi di strumenti: sia meccanismi d’integrazione organizzativa che

meccanismi formalizzati di rilevazione amministrativa.


I meccanismi d’integrazione organizzativa e amministrativa

- l’“integrazione esterna”. Si tratta di varare soluzioni organizzative che permettano di coinvolgere attivamente il

committente nella gestione delle problematiche che possono emergere nel corso delle varie fasi del progetto. Una via

percorribile sarebbe quella di nominare un responsabile che segua, per conto dell’utenza, tutto il ciclo di vita del

progetto. Alternativamente sarebbe ipotizzabile l’istituzione di un comitato di coordinamento utenti che, riunendosi

frequentemente sia in grado di tenere efficacemente i contatti fra l’azienda ed il cliente;

- l’“integrazione interna” come strumento di gestione del rischio. Si tratta di specifiche soluzioni organizzative

interne all’azienda. Ad esempio, nel caso in cui l’impresa lavori abitualmente per progetti o debba gestirne di

particolarmente complessi e rilevanti, potrebbe essere una scelta efficace quella di adottare una struttura

organizzativa di tipo matriciale o “project-oriented”. E’ consigliabile adottare un basso turnover di gruppo ed un’alta

frequenza di riunioni e revisioni progettuali. E’ necessario inoltre garantire un’adeguata assistenza tecnica esterna,

perseguendo al contempo la massima flessibilità organizzativa interna, un’efficace gestione per obiettivi ed un’attiva

partecipazione del gruppo alla definizione di obiettivi e scadenze.

- programmazione formale. Rientrano in questa classe gli strumenti di controllo dei tempi, detti anche di analisi

reticolare (rete di relazioni tra le attività che compongono il progetto). Fra gli strumenti più noti è il caso di ricordare

il PERT ed il Gantt. A questi è possibile inoltre aggiungere il budget che permette di conoscere costantemente i costi

preventivati in relazione ad una determinata fase o attività. Poter disporre di stime previsionali rispetto al livello di

costi ipotizzato si rende poi estremamente utile nelle successive fasi di controllo;

- controllo formale. Si tratta di strumenti che permettono di gestire in modo più efficace tanto le problematiche legate

ai costi che quelle legate alla qualità. Fra i primi si segnala innanzi tutto il sistema di reporting (costo dello sforzo

preventivato con quello effettivamente sostenuto, evidenziando così gli scostamenti più significativi)

Integrazione organizzativa

Integrazione amministrativa


Criteri di scelta per la gestione del rischio

UUMUMUAAAAA

SUSUMUMUABAA

MUMUUMUAABA

MUUSUMUBBBA

UUMUSUAAAB

SUUMUSUBBAB

MUMUUSUBABB

MUUSUSUBBBBB

Controllo

formale

Programmazion

e formale

Integra

zione

interna

Integra

zione

esterna

RischioDimen

sione

Innovazione

tecnologica

Difficoltà

generale

SCELTE GESTIONALI SUGGERITECLASSI DI RISCHIO

MU molto utile U utile SU scarsamente utile BB molto basso B basso A alto AA moltoalto

Per situazioni caratterizzate da un grado di rischio basso o relativamente basso e da innovazione tecnologica contenuta,

sembrano suggeribili soluzioni gestionali come il controllo e la programmazione formale (righe 1 e 2). Nei casi in cui

l’innovazione tecnologica assume invece un peso considerevole (righe 3 e 4) l’“integrazione interna” ed una struttura

organizzativa aziendale appropriata sembrano la risposta migliore.


Profilo del campione analizzato

8507001100350200300N° occupati

20.65%8.01%16.59%30.42%21.86%ROI

+18%+240%+14%+7%+35%+21.5%Var. % su

Fatturato ’94

2251251406058130 Fatturato ’95

(in mld di £)

Progettaz. di

impianti indus. e

produz. di caldaie

a vapore e sist.

per protez.

ambiente

“Outsourcing”,

servizi,

consulenze

Manutenzioni,

consulenze,

servizi di

“outsorcing” e

sviluppi

personalizzati su

commessa

Manutenzioni,

consulenze e

sviluppo per

utenti interni ed

esterni

“Outsourcing” e

manutenzione del

sist. inform.

gruppo Comit

Sistema Informat.

Integrato

Bancario,

“outsourcing”

globale,

consulenze

Prodotti e

servizi forniti

Foster Wheeler

Corporation

IBM SemeaManagement,

IBM, Paribas,

Italcementi

Credit, Finsiel e

Bull

Comit e FinselConsorzio di 12

istituti di credito

(soprattutto Casse

di Risparmio)

Azionisti di

riferimento

195719931980197019891976Anno di

nascita

FOSTER

WHEELER

ISSCENGINEER.DATA

MANAGEM.

COMITSIELCEDACR.Aspetto

osservato



Non dispon.Non disponib.Non disponib.32 anni circa 31 anni circa80% al di sotto

dei 35 anni

Età media

del personale

SìSìSìSìSìSìEvent. corsi

formaz./add.

Molti laureati,

prevalentemen.

con indirizzi

“tecnici”

Molti laureati,

prevalentemen.

con indirizzi

“tecnici”. Molti

anche in econ. e

commercio

Molti laureati,

prevalentemen.

con indirizzi


anche in econ. e

commercio

Molti laureati,

prevalentemen.

con indirizzi


anche in econ.

e commercio

Molti laureati,

prevalentemen.

con indirizzi

“tecnici”

35% di

laurerati,

esclusivamente

con indirizzi di

tipo “tecnico”

Altre

informazioni

rilevanti sul

personale

effettivo

Tecnica,

capacità di

analisi e di

“problem

solving”. Non è

necessario saper

program.

Tecnica,

capacità di

analisi e di

“problem

solving”. Non è

necessario saper

program.

Tecnica,

capacità di

analisi e di

“problem

solving”. Non è

necessario saper

program.

Tecnica,

capacità di

analisi e di

“problem

solving”. Non è

necessario

saper program.

Tecnica,

capacità di

analisi e di

“problem

solving”. Non è

necessario saper

programmare

Tecnica,

capacità di

analisi e di

“problem

solving”. Non è

necessario saper

program.

Profilo dei

potenziali

collaboratori

FOSTER

WHEELER

ISSCENGINEER.DATA

MANAGEM.

COMITSIELCEDACR.Aspetto

osservato



•“Pay-back period”•Non disponib.•Non disponib.•Nessuno•Nessuno•No•Indicatori

redd. e finan.

più utilizzati

•Differenziale•Differenziale•Differenziale•Differenziale•Differenzi

ale

•Differenziale•Analisi costi-

benefici

•Nessuno•Checklist•Checklist•Nessuno•Nessuno•Nessuno•Strumen. per

gest. rischio

•Nessuna•Tre fatt. di risc.•Probabilistica•Nessuna•Nessuna•Nessuna•Anal. rischio

•Checkpoint, scostamenti e report•Checkpoint,

scostamenti,

report e indici

•Checkpoint,

scostamenti,

report e indici

•Checkpoint,

scostamenti, report

e indici

•Checkpoi

nt,

scostament

i e report

•Checkpoint,

scostamenti e report

•Strum. contr.

avanz. prog.

•Nessuna•DIEBOLD,

COCOMO,

Metodo Cond.

Progetti (MCP) e

Punti Funz.

•Metodo Punti

Funzione (solo

occasionalm.)

•Nessuna•Metodo

Punti

Funzione

in fase

sperimenta

le

•Nessuna•Tecniche e

modelli

previsionali

utilizzati

•Gantt•Gantt e PERT •Gantt (PERT e

WBS solo per

progetti molto

complessi)

•Gantt e PERT•Gantt

(molto più

del PERT)

•Gantt e PERT•Strumenti di

pianificaz. più

utilizzati

•No•Sì•Sì•No•No•No•Approccio

prototipale

•Informatico tradizionale (“a cascata”)•Informatico

tradizionale (“a

cascata”)

•Approccio

manageriale (“a

cascata”)

•Informatico

tradizionale (“a

cascata”)

•Informatic

o

tradizional

e (“a

cascata”)

•Inform. tradiz. (“a

cascata”) con utenti

pilota

•Modello ciclo

vita del

software

•FOSTER WHEELER•ISSC•ENGINEER.•DATA

MANAGEM.

•COMITS

IEL

•CEDACRINORD•Aspetto

osservato



•Sfruttare

esperienza

•Sfruttare

esperienza

•Sfruttare esperienza•Sfruttare esperienza•Rotazione•Sfruttare

esperienza

•Criterio gest.

personale

•No•No•Sì•No•No•No•Sist. incent.

monetari per

project man.

•Globale•Globale•Globale•Globale•Globale•Globale•Responsab.

capoprogetto

•Gerarchica

funzionale

•Gerarchica

funzionale

•Gerarchica

funzionale

•Gerarchica

funzionale

•Gerarchica

funzionale

•Gerarchica

funzionale

•Asset. organ.

adottato

•Sì•Sì•Sì•Sì•Sì•No•Funz. Assic.

Qualità

•Nessuna•Per prodotto e per

processo

•Sist. di qualità;

•per prodotto e per

processo

•Per progetto•Per “Ordine di

Lavoro” e per

cliente

•Nessuna•Rilevazione

metriche del

software

•Test e collaudo•Test, collaudo,

Matrice fattori/

criteri valut.

•Test, collaudo,

Matrice fattori/

criteri valut.

•Test e collaudo•Test, collaudo,

Matrice fattori/

criteri valut.

•Test e collaudo•Controllo

qualità

•Non prevista•Propria•Methis•Personalizzaz. di

DAFNE

•Personalizzaz. di

DAFNE

•Per utenti pilota•Metodologie

svilup. soft.

•No•Ottobre ’94•Gennaio ’94•Dicembre ’95•Dicembre ’94•No•Data conseg.

certificaz.

•Sì per la parte

che si occupa

d’impiantistica No

per funz. sist.

inform.

•Sì•Sì•Sì•Sì•Prevista entro fine

’96

•Certificaz. ISO

9000 per

sviluppo di

software

•FOSTER

WHEELER

•ISSC•ENGINEER.•DATA

MANAGEM.

•COMITSIEL•CEDACRINORD•Aspetto

osservato


Evidenze emerse

La tendenza che sembra diffondersi sempre più è di attribuire alla funzione sistemi informativi la responsabilità di:

- gestire i rapporti con i fornitori esterni;

- concorrere alla definizione dei requisiti del sistema, curandone lo studio di fattibilità;

- garantire il rispetto degli accordi stipulati con i fornitori, verificando lo stato d’avanzamento del progetto;

- seguire l’installazione, la personalizzazione e, successivamente, l’esercizio dell’applicazione;

- garantire l’integrazione dell’applicazione con il software aziendale già installato;

- eseguire periodicamente dei controlli per verificare il corretto funzionamento dell’applicazione stessa;

- assicurare un supporto continuo agli utenti del sistema (si tratta di una sorta di servizio di “help-desk”);

- garantire la formazione e l’addestramento dell’utenza.

In generale, è possibile dire che tutte le aziende considerate seguono un modello di ciclo di vita dei sistemi informativi

“a cascata”. Le uniche deroghe a tale modello sono state riscontrate in Engineering e in Cedacrinord. Nel primo caso

l’approccio utilizzato sembra essere molto più vicino a quello manageriale proposto da Camussone , dal momento

l’attenzione viene spostata dalla singola applicazione alla gestione di un portafoglio progetti ed alla valutazione

dell’impatto che il sistema informativo può avere sull’assetto organizzativo dell’utente.

La considerazione dell’impatto organizzativo è un aspetto comune anche al modello utilizzato in Cedacrinord.

Quest’azienda ha infatti sviluppato un sistema informativo integrato che serve attualmente un certo numero di banche,

oltre ai dodici istituti di credito che controllano l’impresa. Questo sistema informativo prevede una serie di “poli

gestionali”, localizzati in prossimità degli istituti forniti, nei quali questi ultimi hanno pensato di concentrare i loro centri

di elaborazione dati.

Solo in due casi (Engineering e ISSC), oltre all’approccio “a cascata”, è stata riscontrata anche la presenza di un

modello di tipo prototipale, che si rifà allo schema “ a spirale”. L’obiettivo dell’approccio prototipale è infatti quello di

ridurre l’incertezza sui contenuti funzionali e sui requisiti che il nuovo sistema deve aver. Soprattutto nel caso in cui

l’utente abbia un’esatta cognizione delle proprie esigenze informative, la realizzazione di un modello prototipale

migliorativo o “throw away” può costituire un valido strumento di supporto operativo.


Evidenze emerse

Estremamente importante risulta inoltre, durante la fase di pianificazione, la complessiva definizione dei punti di

controllo e delle “milestones” in corrispondenza dei quali deve essere valutato lo stato d’avanzamento del progetto.

Per ottenere un’esatta collocazione temporale delle attività di progetto ed un’efficace rappresentazione visiva delle

stesse, le aziende utilizzano abitualmente un insieme di strumenti di programmazione reticolare, fra i quali si possono

ricordare: il diagramma di Gantt, il Critical Path Method (CPM), la Program Evaluation and Review Technique (PERT),

il Metra Potential Method (MPM), la Graphic Evaluation and Review Technique (GERT), l’Earned Value Method

(EVM o “S curve”) ed il Metodo Montecarlo.

Per attuare una complessiva scomposizione delle attività di progetto sino ad ottenere la complessiva definizione dei

pacchetti di lavoro da realizzare e la struttura delle responsabilità previste a tale scopo, si può pensare di integrare gli

strumenti appena visti con la Work Breakdown Structure (WBS) o la Resource Breakdown Structure (RBS).

Dall’analisi del campione considerato sembra emergere una correlazione positiva non tanto fra le dimensioni del

progetto e l’utilizzo di questi modelli previsionali, bensì fra questi ultimi e le dimensioni aziendali da un lato (ISSC ed

Engineering), ed il grado di standardizzazione del processo produttivo del software dall’altro (Comitsiel).

Gestione delle Imprese Informatiche Lezione 13 Padova, 1 ...amonti/GII 2007 - Lezione 13.pdf ·...

Documents

Transcript of Gestione delle Imprese Informatiche Lezione 13 Padova, 1 ...amonti/GII 2007 - Lezione 13.pdf ·...