1. A partire dall'inizio degli Anni Settanta si è verificato un profondo cambiamento nelle modalità di analisi, progettazione e realizzazione dei sistemi informativi automatizzati nelle organiz-zazioni. In primo luogo, le crescenti possibilità applicative, in rapporto all'evoluzione tecnologica, e il consolidamento delle esperienze aziendali precedenti hanno via via ampliato l'oggetto degli interventi: si è quindi passati da un'attività consistente essenzialmente nella codifica delle procedure altamente standardizzate, tipiche dell'area amministrativa, ad un insieme di attività comprenden-ti l'analisi di processi decisionali complessi di carattere interfuzionale, l'analisi e ridefinizio-ne di flussi informativi e archivi, la riprogettazio-ne dell'organizzazioriprogettazio-ne del lavoro. Come dimostra l'ampio rilievo dato alle .nuove applicazioni nel lavoro di ufficio (la cosiddetta office auto-mation), la tecnologia si propone come strumento per realizzare cambiamenti sempre più ampi e profondi nella struttura organizzativa, nelle modalità di funzionamento dell'organizzazione, nel lavoro non solo a livello esecutivo ma anche dei tecnici (knowledge workers) e dei dirigenti. In secondo luogo, le crescenti complessità dei progetti unitamente a quelle della tecnologia, sia in termini di hardware che di software, hanno portato all'aumento del numero dei tecnici addetti all'analisi e programmazione e all'aumento della
loro specializzazione, con una profonda modifica dell'organizzazione del lavoro del servizio di elaborazione dati. In particolare, si è assistito ad una crescente applicazione a questo campo delle tecniche manageriali per la conduzione e l'organizzazione di progetti complessi (project management). In terzo luogo, la . riflessione sulle esperienze di insuccesso, in gran parte non dovute a motivi tecnici, delle realizzazioni precedenti ha messo in discussione il ruolo degli specialisti della progettazione; sono state proposte e applicate modalità diverse di organizzazione del processo di progettazione, metodologie e tecniche provenienti dall'analisi organizzativa e nuove tecniche di lavoro per l'analisi e la progettazione più specifi-camente informatica.
L'insieme di questi fattori ha fatto sì c h e , a fianco dell'approccio tradizionale nel quale l'analisi e la progettazione delle applicazio-ni è compito esclusivo degli specialisti che operano su mandato dell'alta direzione (expert design), si vadano diffondendo modalità di progetta-zione nelle quali il ruolo degli utenti è sempre più r i l e v a n t e .
Prima di approfondire questo aspetto è opportu-no premettere alcune considerazioni di carattere d e f i n i t o r i o .
Il processo complessivo d'introduzione e applicazione dell'informatica in un'organizzazione comprende la definizione della strategia dell'auto-mazione (definizione degli o b i e t t i v i , scelta delle aree da a u t o m a t i z z a r e , priorità e sequenze d ' i n t e r v e n t o , piano delle a p p l i c a z i o n i , risorse d e d i c a t e , sistemi e macchine da a c q u i s i r e , responsa-bilità e collocazione o r g a n i z z a t i v a dell'unità
che gestisce la tecnologia) e la progettazione e realizzazione delle specifiche applicazioni. Il primo aspetto è definito processo di pianificazio-ne dello sviluppo dell'informatica aziendale, il secondo processo di progettazione delle applica-zioni. Entrambi possono presentare un maggiore o minore livello di formalizzazione nelle singole organizzazioni, in termini di esplicitazione dei ruoli dei diversi attori, delle modalità di conduzione del processo e della sua suddivisione in fasi, delle modalità di documentazione e delle metodologie e tecniche di analisi e progettazione.
La scomposizione in fasi di un processo di pianificazione o di un progetto complesso ha l'obiettivo di definire contenuti, tempi,
supporti necessari alle varie fasi al fine di poter meglio condurre il progetto stesso. Nel caso della progettazione delle applicazioni, una distinzione generale individua l'analisi delle procedure esistenti, la progettazione del nuovo sistema, la realizzazione, la diffusione e formazione; una suddivisione più analitica distingue l'analisi dei fabbisogni informativi, la definizione dei requisiti funzionali, la progetta-zione di insieme e di dettaglio, la messa in f u n z i o n e , la gestione e la manutenzione.
Per la gestione e organizzazione dei progetti sono state proposte numerose metodologie di condu-zione dei progetti, il cui obiettivo è quello di fornire le linee guida e gli strumenti gestionali per il project management: tali metodologie defini-scono l'articolazione in fasi, l'output di ogni fase del processo, le tecniche e gli strumenti di lavoro, il ruolo dei diversi attori in ogni f a s e , le modalità di documentazione.
Lo sviluppo di un progetto richiede la costitu-zione, più o meno formalizzata, di una organizzazione temporanea ad h o c , in cui entrano i membri dell'or-ganizzazione con ruoli d i v e r s i . Le metodologie di conduzione di progetti danno indicazioni sulle caratteristiche e la composizione di tale organizza-zione provvisoria, su chi interviene, sui ruoli che vengono svolti.
In termini generali, si individuano ruoli decisionali a cui spettano le decisioni ultime sulle scelte fondamentali del progetto (committente, gruppo di riferimento) e ruoli professionali a cui spetta la formulazione delle soluzioni tecniche (specialisti della tecnologia, utilizzatori esperti delle procedura che si sta a n a l i z z a n d o ) . Vi può essere anche l'intervento di attori esterni all'organizzazione come specialisti del fornitore dell'hardware e/o del s o f t w a r e , consulenti di informatica e di organizzazione, rappresentanti sindacali.
Sempre maggiore enfasi viene posta sulla partecipazione degli u t e n t i , anche se tale definizio-ne si presta a differenti interpretazioni e presenta molti margini di a m b i g u i t à . In primo l u o g o , il termine partecipazione viene u t i l i z z a t o , come si vedrà in s e g u i t o , per indicare processi molto diversi: dal mero -coinvolgimento informativo sui cambiamenti tecnici e organizzativi che si stanno r e a l i z z a n d o , ad un effettivo intervento decisionale, che può essere a sua volta ristretto ad alcuni aspetti della p r o g e t t a z i o n e e realizzazio-ne (o comunque limitato n e l l ' a m b i t o delle scelte progettuali e organizzative fatte a monte) oppure può riguardare le prime fasi della progettazione e quindi rappresentare un effettivo condizionamento
degli sviluppi progettuali.
In secondo luogo, la definizione di utente è spesso restrittiva, incompleta o non precisata e si basa in genere su funzioni e mansioni formali, trascurando il ruolo effettivamente scolto dalle varie persone. In senso lato, gli utenti di un'appli-cazione automatizzata sono tutti coloro il cui lavoro viene modificato in modo significativo dalla realizzazione della stessa. Vi sono tuttavia diversi tipi di persone toccate dal cambiamento; più precisamente si possono individuare diversi ruoli nei confronti della realizzazione di un'appli-cazione; ogni persona (o gruppo) può essere analizza-to in relazione al ruolo (o ai ruoli) nel quale si colloca:
- committenti o sponsors del sistema sono
alti dirigenti, dirigenti di linea o chiunque abbia il potere di farlo che decidono di avviare la realizzazione e finanziano il progetto, indipen-dentemente dal fatto che essi si serviranno diretta-mente del sistema;
- responsabili di unità organizzative, maggiormente coinvolte nel cambiamento tecnico-organizzativo; responsabili di altre unità nel caso che le modalità di interazione con le prime vengano modificate; - fornitori delle informazioni;
- operatori del sistema, tra cui gli addetti ai terminali ;
- altri impiegati il cui lavoro è condizionato dall'applicazione, come n e l caso di lavoratori la cui attività è scadenzata dal sistema;
altre persone, al di fuori dell'organizzazione che possiede e ha sviluppato 1 ' applicazione,, come ad esempio i cittadini utenti di un servizio p u b b l i c o .
Vi sono quindi utenti indiretti (che utilizzano le informazioni generali dal sistema) e utenti diretti (end-user) che usano il sistema nel proprio lavoro; utenti discrezionali, che possono utilizzare o meno il sistema in relazione agli obiettivi di svolgimento del lavoro e utenti non discreziona-li , il cui lavoro è strettamente connesso all'uso del sistema. Frequentemente, soprattutto in relazio-ne alle applicazioni di office automation, si distinguono gli utenti in base al ruolo professiona-le svolto nell'organizzazione e cioè utenti manager e tecnici (professional) da una parte e i utenti esecutivi (clerical) o segretariali dall'altra (1).
Ai fini della presente t r a t t a z i o n e , la distin-zione tra uso discrezionale e non discrezionale assume una rilevanza f o n d a m e n t a l e . Si ha uso discrezionale quando il controllo del processo di lavoro e della procedura e la scelta degli strumenti e supporti da utilizzare sono lasciati all'utente, che ha la capacità e la possibilità di decidere le modalità di uso del sistema nelle diverse situazioni di l a v o r o . In tal caso è ricono-sciuta all'utente o agli utenti una notevole influenza sulla definizione degli obiettivi e delle caratteristiche di un'applicazione e quindi sulla sua p r o g e t t a z i o n e , e inoltre sugli sviluppi e cambiamenti successivi dell'applicazione s t e s s a .
Il senso di tale distinzione risulta più chiaro se si considerano le differenze tra le applicazioni a u t o m a t i z z a t e . Esistono applicazioni che meccanizzano o automatizzano il l a v o r o , sia con riferimento a specifiche attività di ufficio (word-processing, riproduzione di d o c u m e n t i , trasmissione d ' i n f o r m a z i o n i , e t c . ) , sia con riferi-m e n t o a procedure coriferi-mplete (ad e s . , accettazione
ordini e fatturazione, contabilità); esistono, d'altra parte, applicazioni che costituiscono un supporto allo svolgimento del lavoro, siano essi strumenti per la comunicazione e il lavoro professionale (posta elettronica, stazioni multifun-zionali di lavoro, strumenti grafici e di calcolo) o sistemi di supporto alle decisioni (Butera e Bartezzaghi, 1983). Nel caso di applicazioni di supporto, gli utenti sono in generale discrezio-nali e, in termini di ruolo professionale, tecnici e m a n a g e r . Nel caso di sistemi di word processing, gli operatori di tali sistemi sono utenti non discrezionali. Nelle applicazioni consistenti nell'automazione di procedure per il trattamento di grandi volumi d'informazioni, gli impiegati addetti sono utenti diretti non discrezionali; nella maggior parte dei c a s i , solo ai responsabili delle unità organizzative preposte a tali procedure è lasciata la decisione sulle modalità di utilizzo e sull'innovazione delle procedure stesse.
2 . Un esame della letteratura specializzata mostra che tra i diversi fattori la motivazione principale che ha portato specialisti e imprese a porsi il problema della partecipazione degli utenti al processo di progettazione è stata l'esigen-za di far fronte alle difficoltà e ai problemi, se non addirittura ad insuccessi di natura non specificamente tecnica, che si sono verificati frequentemente nella realizzazione delle applicazio-ni informatiche (2). Per insuccesso s'intende il mancato raggiungimento degli obiettivi iniziali dell'applicazione automatizzata, sia in termini di risultati (misurati in base a qualche indicatore chiave delle prestazioni) lontani dalle aspettative,
sia in termini di un rapporto costi/benefici molto peggiore di quanto previsto. Anche quando gli obiettivi posti sono stati focalizzati sul migli oramento dell'efficacia e efficienza dell'unità organizzativa considerata, indipendentemente dagli effetti sulla qualità della vita di lavoro (ed è la maggior parte dei c a s i ) , si sono verificati frequentemente insuccessi, portando in alcuni casi all'abbandono dell'applicazione stessa o all'interruzione del p r o g e t t o . Un insuccesso può consistere infatti in (Gibson e Schnidman,
1981):
- sistemi completamente sviluppati e implemen-tati senza aumento dell'efficacia e dell'efficienza;
- sistemi utilizzati molto al di sotto delle loro potenzialità;
- sistemi parzialmente o completamente sviluppa-ti ma mai effetsviluppa-tivamente implementasviluppa-ti e u t i l i z z a t i .
Altri autori analizzano i risultati in termini di accettazione da parte degli utenti delle applica-zioni a u t o m a t i z z a t e . Eason (1982) delinea il quadro delle forme di non accettazione riportato nella Tavola 1. La Tavola mostra come la natura discrezionale o meno dell'uso del sistema porti a forme diverse di non accettazione del sistema s t e s s o .
Le ragioni della non accettazione sono relative a:
- progetto non adeguato: il sistema non risponde ai fabbisogni connessi allo svolgimento del processo di lavoro; oppure la rigidità dell'automazione non consente l'adattamento organizzativo a fronte di variazioni e incertezze generate dall'ambiente esterno o all'interno del processo di lavoro stesso;
* interfaccia utente/sistema non adeguata: i modi con cui gli utenti accedono al sistema (es. terminali con i relativi linguaggi di input) sono complessi e onerosi;
- disegno dell'organizzazione del lavoro che non considera obiettivi di qualità della vita di lavoro;
- gestione del processo di progettazione e realizza-zione che non tiene conto dei problemi connessi al cambiamento organizzativo che 1'introduzione di un nuovo sistema comunque implica.
A tali aspetti vanno aggiunti quelli relativi all'operatività del sistema (rispetto delle scaden-z e , tempi di risposta, frequenscaden-za e gravità di eventuali interruzioni nei collegamenti, sicurezza, etc.) (Lucas, 1978).
Molte sono le diagnosi degli insuccessi che sono state proposte dalla letteratura. Tale dibattito ha portato all'allargamento dell'ambito disciplinare della progettazione dei sistemi; teorie e tecniche delle discipline organizzative hanno trovato sempre più ampia applicazione sia nell'interpretazione delle cause, sia nella messa a punto di strumenti d'intervento.
Nella letteratura è possibile individuare alcune linee interpretative di fondo (3).
Un primo filone è relativo alla critica del ruolo e del sistema di valori degli specialisti.
Tra i diversi attori che intervengono nel processo di progettazione delle applicazioni informatiche, un ruolo centrale hanno i progettisti dei sistemi, cioè i tecnici dei calcolatori, gli a n a l i s t i , i programmatori, gli specialisti di ricerca operativa e delle metodologie quantitati-ve della gestione a z i e n d a l e . Una prima approfondita
TflV. 1 - Forme di non accettazione degli utenti e analisi delle cause
( E a s o n , 1982)
TIPO DI UTENTE FORBE DI NON RAGIONI ACCETTAZIONE UTENTI DISCREZIONALI esempio: manager professional 1) Non uso 2) Uso parziale 3) Uso distante (un
esperto opera il sistema per conto del m a n a g e r ) 4 ) D i s t o r s i o n e nel
compito (il sistema è in grado di far fronte solo ad alcu-ni aspetti del compi t o )
D i s p o n i b i l i t à di metodi più facili o più signi-ficativi
Difficoltà di uso o mancanza di conoscenza
"Task Batch" (non corri-spondenza del sistema al t a s k )
UTENTI NON D I S C R E Z I O N A L I
e s e m p i o : segretarie 5) Uso distorto impiegati 6) S t r e s s , n o i a , a l i e n a z i o n e 7) R e s i s t e n z a al c a m b i a m e n t o "Task Batch" i n a d e g u a t o o p r o c e d u r e non f l e s s i b i l i C o m p i t i p o v e r i , c a r a t t e -r i s t i c h e d e l l a m a n s i o n e e del posto di lavoro
P e r i c o l o p e r c e p i t o per la p r o f e s s i o n a l i t à , le m a n s i o n i e la c a r r i e r a
analisi critica è quella svolta negli Anni Sessanta da Boguslaw. Egli definisce gli specialisti utopisti di tipo n u o v o , in quanto portatori di utopie
(i sistemi basati su calcolatore) che "mancano dell'orientamento utopistico delle utopie classiche"; le nuove utopie si basano esclusivamente su variabi-li tecniche ed economiche e trascurano gvariabi-li aspetti organizzativi e sociali, che peraltro hanno un influsso determinante sul risultato e quindi sull'efficacia ed efficienza di un'applicazione. Boguslaw ritiene necessario un profondo cambiamento per cui "dovrebbe essere possibile che i capi sindacali, i sociologi, gli accademici, i dirigen-ti privadirigen-ti e statali e tutte le persone non specia-lizzate, partecipino, insieme con gli ingegneri elettronici specialisti, al progetto dei sistemi; con una partecipazione che avvenga fin dalle prime formulazioni dei progetti...". "Reciprocamen-t e , fisici e ingegneri devono... allargare la base culturale della loro preparazione professionale, in modo da tener conto, nei loro progetti, davvero di tutte le variabili significative..." (Boguslaw,
1965).
Bostrom e Heinen (1977) individuano la causa
primaria dei problemi e degli insuccessi dei sistemi informativi automatizzati nelle carenze dello schema di riferimento concettuale degli analisti e progettisti di sistemi informativi. Essi sottolineano in particolare la non adeguatezza delle teorie organizzative assunte esplicitamente o implicitamente dai p r o g e t t i s t i , l'approccio non "sistemico", in quanto vengono trascurate le variabili non afferenti al sottosistema tecnico-economico, la scarsa attenzione dedicata alla composizione del gruppo di p r o g e t t o , alla
definizio-ne delle responsabilità, la visiodefinizio-ne razionale-statica del sistema e la limitatezza del bagaglio conoscitivo posseduto. Determinante a tale proposi-to è il contesproposi-to culturale e disciplinare in cui si realizza la formazione degli analisti. Keen e Scott Morton (1978) analizzano la situazione americana evidenziando come la formazione degli specialisti si basi quasi esclusivamente sulle discipline tecniche, mentre i contributi di altre discipline hanno scarsa influenza. Altri contributi pongono l'accento sul sistema di valori che sta alla base della progettazione, nell'ipotesi che i "valori giochino un ruolo importante nella scelta tra progetti alternativi da parte dei progettisti dei sistemi" (Hedberg e M u m f o r d , 1975). Sono assai rari i casi di sistemi progettati in modo esplicito al fine di aumentare la qualità della vita di lavoro dei rispettivi utenti: "questo perché i sistemi di remunerazione e i valori che influiscono sui progettisti dei sistemi non li motivano in tal senso" (Hedberg e M u m f o r d , 1975). D'altra p a r t e , obiettivi di efficienza e di soddisfazione del lavoro non sono completamente indipendenti (Mumford e H e n s h a l l , 1 9 7 9 ) . In sintesi, secondo questo primo f i l o n e , il ruolo degli speciali-sti deve subire un cambiamento profondo: da "eroi dei s i s t e m i " , come sono stati definiti da alcuni a u t o r i , ad agenti d e l l ' i n n o v a z i o n e . Dal ruolo di portatori di soluzioni e concetti che consentono di rispondere a quelli che essi vedono come bisogni degli utenti e per cui lottano contro ostacoli tecnici e s o c i a l i , essi diventano partecipanti di un processo complessivo di p r o g e t t a z i o n e e cambiamento in cui agiscono con altri come portatori di competenze specialistiche e di possibili
tive tecnologiche.
Un secondo filone interpretativo consiste nell'applicazione allo sviluppo dei sistemi informa-tivi automatizzati delle teorie e tecniche del cambiamento pianificato delle organizzazioni. In tal caso l'enfasi è posta sui caratteri del processo di progettazione e realizzazione visto come processo più generale di cambiamento organizza-t i v o . In un'oorganizza-torganizza-tica molorganizza-to risorganizza-treorganizza-torganizza-ta, diversi auorganizza-tori, soprattutto nella letteratura tecnica sui sistemi informativi, hanno evidenziato la resistenza al cambiamento da parte degli utenti come causa principale degli insuccessi. Secondo tali interpreta-zioni, la progettazione incontra ostacoli dovuti all'attaccamento alle abitudini e alla paura del cambiamento, oppure al desiderio di mantenere aree di discrezionalità e al timore di effetti negativi sulla propria posizione di potere, profes-sionalità, carriera; questi fattori impediscono il completo realizzarsi della razionalità del p r o g e t t o . Per far fronte a tali ostacoli viene richiesto un maggior impegno (committenza) da parte dell'alta direzione nella realizzazione del c a m b i a m e n t o . Si lamenta inoltre la mancanza di interventi per adeguare la struttura formale alla nuova applicazione automatizzata. L'accettazio-ne da parte degli utenti è facilitata dal coinvolgi-mento degli stessi nelle varie fasi del processo di p r o g e t t a z i o n e , l'assegnazione ad essi di responsa-bilità decisionali ben d e f i n i t e .
In analisi di più ampio respiro vengono recuperati pienamente i contributi della sociologia dell'organizzazione e delle teorie del comportamento o r g a n i z z a t i v o . La resistenza al cambiamento diventa una delle variabili all'interno di uno schema
interpretativo del processo di cambiamento, che comprende un insieme di variabili come durata temporale del cambiamento, potere, r u o l i , spinte al cambiamento, atteggiamenti, cultura organizza-tiva. Nella letteratura riferita allo sviluppo dei sistemi informativi si ricordano le analisi di Argyris sui processi di apprendimento organizzati-vo (Argyris, 1977), gli studi di Whisler (1970),
Alter e Ginzberg (1978), Keen e Scott Morton (1978). Crozier evidenzia che l'applicazione
del sistema razionale dell'informatica al sistema sociale costituito da un'impresa incontra difficoltà dovute non tanto alla ostilità sistematica del personale o alla vischiosità dello spirito u m a n o , ma a "tutto un insieme di pratiche e di accomodamen-ti che cosaccomodamen-tituiscono in realtà il sistema di potere dell'azienda o , se si v u o l e , le regole implicite dei rapporti tra gli u o m i n i , i gruppi e le categorie" (Crozier, 1973). Da questo punto di vista, il problema rilevante è che l'informatica richiede agli utenti di rendere i loro processi di lavoro trasparenti. Questo proibisce gli usuali generi di aggiustamenti ad hoc che rendono possibile anche per le grandi burocrazie conciliare le esigenze d'integrazione complessiva e quelle di adattamento (Crozier, 1983).
Le analisi precedenti comportano una concezione diversa della progettazione dei s i s t e m i . Lucas sottolinea che il processo complessivo di progetta-zione e realizzaprogetta-zione di un sistema (che definisce implementation) parte dalla nascita dell'idea del sistema e del cambiamento ad esso associato e termina quando il sistema è stato integrato con successo nell'attività del1'organizzazione (Lucas, 1 9 7 8 ) . Per il suo svolgimento sono
rie metodologie e tecniche che recuperano metodolo-gie e strumenti proposte dalle discipline organizza-tive: dalle tecniche proprie dello sviluppo organiz-zativo all'analisi clinica delle organizzazioni e alla ricerca-intervento.
Come si vedrà in seguito, motivazioni, con-tenuti e modalità della partecipazione degli utenti variano in relazione al tipo di metodolo-gia adottata (4).
Un terzo filone è relativo alla validità dei modelli di analisi dell'organizzazione e del sistema informativo e agli strumenti di analisi e ai criteri di progettazione utilizzati nello sviluppo delle applicazioni. Si focalizza cioè il merito, l'oggetto della progettazione oltre che il p r o c e s s o . Diversi autori hanno evidenziato l'insufficienza delle metodologie di progettazione che pongono 1'enfasi solo sulla gestione del processo e n o n indicano adeguati strumenti di analisi: dopo numerosi anni di lavoro centrato sul coinvolgimento degli u t e n t i , gli specialisti cominciano a diventare scettici sulla validità di tale pratica (Taylor, 1981). Sono stati indicati due ordini di r a g i o n i . Da una p a r t e , vi sono problemi di comunicazione tra utenti e specialisti; gli specialisti tendono a utilizzare un linguaggio formalizzato e le specificazioni degli utenti dovrebbero essere formulate in tale linguaggio. Questo porta facilmente a incomprensioni da parte degli utenti (Langefors, 1978). Sono stati proposti strumenti di analisi basati su linguaggi formaliz-zati di facile comprensione, che hanno l'obiettivo di consentire la comunicazione tra utenti e specia-l i s t i , aspecia-lspecia-lo scopo di evitare ogni ambiguità nespecia-lspecia-la
definizione dei requisiti del sistema. Un altro ordine di ragioni è costituito dalle carenze nell'analisi e progettazione degli aspetti organiz-zativi . All'utente viene chiesto di formulare i suoi fabbisogni informativi senza alcun supporto tecnico e professionale; la definizione dei fabbiso-gni richiede invece una diagnosi del funzionamento organizzativo e per questo sono necessarie adeguate