Gli accordi sulle nuove tecnologie. Casi e problemi di applicazioni in Norvegia

Claudio Ciborra

GLI ACCORDI SULLE

NUOVE TECNOLOGIE

Il caso norvegese

Claudio Ciborra professore di sistemi infor­ mativi all’Università di Trento e al Politec­

La serie dei Quaderni relativi ai temi del Progetto di ricerca Informa­

Claudio ab o rra

Gli accordi sulle nuove tecnologie

© 1985, Fondazione Adriano Olivetti, Roma LITOSPES - Roma — Via Prenestina 697 Tel. 221831

INDICE

INTRODUZIONE 1

PARTE PRIMA: RIFLESSIONE TEORICA E SINTESI

DEI RISULTATI 3

Capitolo primo

Tre strategie di ricerca sulla

progettazione 5

1.1. Lo sviluppo dei sistemi informativi

come project management 10

1.2. La visione politica: la progettazione

come processo contrattuale 15 1.3. La prospettiva dell'intervento 19 1.4. Alcune riflessioni di confronto 26

Capitolo sfecondo

La progettazione come processo di indagine

e contrattazione 30

2.1. Uno schema di analisi 30

2.2. Alcuni dilemmi 38

2.3. Meccanismi per far fronte ai dilemmi 40

Capitolo terzo

Sintesi dei principali risultati degli

PARTE SECONDA: GLI STUDI DI CASO 53

CASO I. L 'informatizzazione delle Poste: il caso dell'automazione delle operazioni

di sportello 55

Appendice 77

CASO I I . Le Casse di Risparmio 83

Appendice ’ 105

CASO III. Un'impresa Chimica 113

Appendice 133

PREMESSA

Nella discussione sui modelli e le strategie di relazioni industriali che si accompagnano alla

diffusione dell'innovazione tecnologica, il rife­

rimento al caso scandinavo (spesso assunto

unitariamente, nonostante le difformità pur

facilmente riscontrabili tra le esperienze svedese e norvegese) è ormai divenuto quasi d 'obbligo.' Ed

è probabilmente bene che sia così, se questo può

servire, oltre che ad ampliare le nostre

conoscenze su significative situazioni empiriche, a sollecitare 1 ’attenzione verso forme di azione sindacale e di regolazione dei rapporti di lavoro

che si discostano nettamente dalle più note

esperienze europee. Da uno studio dei casi

scandinavi, soprattutto, possono venire molti

spunti di riflessione sulle relazioni tra

contrattazione collettiva e legislazione di

sostegno, così come sui rapporti centro-periferia

nei processi di intervento sindacale sui nuovi assetti tecnologici e sui processi di cambiamento organizzativo.'

Più ancora, ci sembra che, al di là di ogni

richiamo di valore a sperimentazioni di relazioni industriali come quelle che sono state condotte negli ultimi dieci anni nella realtà svedese e

norvegese, i tempi consentano ormai una analisi

più di merito sui risultati concreti che sono

stati prodotti dalle strategie sindacali di

intervento attivo nella progettazione e

nell 'implementazione dei nuovi contesti

tecnologici. Ci pare necessario, infatti, passare

dal dibattito sugli approcci contrattuali possi­ bili in sistemi di relazioni industriali in cui è divenuta condizionante la presenza delle nuove

tecnologie, a una valutazione precisa di quanto

hanno conseguito gli approcci che sono stati finora effettivamente seguiti.'

In qìiesto senso, abbiamo creduto che una

ricerca fondata sulla ricostruzione di alcuni

rilevanti case studies estratti dall’esperienza

norvegese (quella in cui è più stringente il

legame tra legislazione e azione sindacale sulla

realizzazione dei sistemi informativi) potesse

costituire il miglior punto di partenza per tale riflessione.'

Il Centro Studi della Fondazione Adriano

Olivetti ha così chiesto a Claudio Ciborra, che

già nel passato ha riservato una attenzione

particolare alla situazione scandinava, di veri­

ficare se e in che modo l'intervento sindacale abbia influenzato e modificato 1 'implementazione dei sistemi informativi, le regole dì funzio­

namento a base della loro ideazione, il lavoro

stesso dei tecnici progettisti.' Inoltre, abbiamo

pensato che dovesse essere uno studioso di teoria dell'organizzazione a compiere questa ricerca dal momento che 1 'intervento di nuovi attori diviene

cruciale per la configurazione del gioco

organizzativo.-I risultati che Ciborra ha acquisito nel corso della sua analisi sul campo vengono ora

esposti in questo "Quaderno": li presentiamo,

nella loro complessità e anche in una lóro certa

ambiguità che li rende poco adatti alle

schematizzazioni, nella convinzione che

contribuiscano non poco alla comprensione delle

dinamiche di conflitto e di cooperazione sottese

alle nuove relazioni industriali e ai nuovi

sistemi di lavoro con cui interagiscono.

INTRODUZIONE

Scopo di questo lavoro è quello di verifica-re l'impatto degli accordi sulle nuove tecnologie nei processi di progettazione dei sistemi informativi, e in particolare di valutare in quale misura certe caratteristiche tecniche e funzionali dei sistemi realizzati siano ricon­ ducibili all'applicazione degli accordi. A tal fine è stata condotta una serie di studi di caso in Norvegia, paese che ha più lunga tradizione in questo campo, e tre fra i casi più significativi, le Poste, le Casse di Risparmio ed un'azienda chimica, vengono analizzati in questa sede.

Come sempre accade, l'indagine empirica diventa l'occasione per una riflessione teorica: in questa sede la riflessione riprende e sviluppa quanto fino ad ora acquisito sui temi della progettazione come attività di cooperazione e conflitto (Ciborra, Lanzara, 1984; Ciborra,

1984a), analizzando i limiti di questo approccio

rispetto ai problemi dell'intervento degli attori e precisando le interdipendenze esistenti fra processi di problem solving e processi di con­

trattazione durante la progettazione (quest'ultimo aspetto è servito anche per la lettura dei casi aziendali).

Ringrazio Roberto Olivetti per aver voluto . questa ricerca; Giovan Francesco Lanzara con cui ho condiviso la discussione teorica; Leslie Schneider con la quale ho condotto la ricerca sul campo, ed Einar St0re e Grazia Critelli che, in Norvegia e in Italia mi hanno aiutato nelle traduzioni e nella redazione del testo.

PARTE PRIMA

Capitolo primo

TRE STRATEGIE DI RICERCA SULLA PROGETTAZIONE

Si vive oggi nel campo delle discipline dell'organizzazione, all'interno del quale questo contributo si colloca, in una fase di pluralismo, di coesistenza e competizione di più voci ed approcci. Lo studio dei processi di progettazione e cambiamento attorno all'innovazione tecnologica non sfugge a questa molteplicità di punti di vista.

Ne consegue che prima di fornire l'inter­ pretazione adottata per leggere i processi di automazione o informatizzazione nei tre casi aziendali studiati occorre, anche se in modo schematico, collocare il punto di vista qui utilizzato per l'interpretazione rispetto ad altri rilevanti, anche al fine di capire fin dall'inizio il limite degli stessi studi di caso. I punti di vista o gli approcci, che prenderemo in consi­ derazione per questo confronto preliminare, sono quelli discussi o elaborati negli ultimi anni da un gruppo di ricercatori, di cui l'autore fa parte

(Ciborra, Romano, 1979; Ciborra, 1981; Lanzara,

1984; Lanzara, Mathiassen, 1983; Ciborra, 1983;

Briefs, Ciborra, Schneider, 1984; Lanzara 1983;

Ciborra, Lanzara, 1983).

Dal confronto dovrebbe emergere che quella presentata è una delle possibili chiavi inter­ pretative che consente introspezioni interessanti nella fenomenologia dei processi di automazione e ha buone capacità predittive, almeno per le aziende studiate, ma presenta dei limiti

soprat-tutto se si vuole porre come strumento di comprensione di una realtà finalizzata all'in­ tervento .

In questo- contributo non si vuole in effetti presentare una teoria completa del processo di automazione^ ma solo descriverne le dinamiche collegate ai risultati nei contesti, come quello norvegese, regolato da accordi sulle nuove tecnologie: il problema dell'intervento non può che rimanere fuori degli scopi di questo lavoro. Ciò tuttavia non toglie che le situazioni di cooperazione e conflitto, i dilemmi, i problemi e

le impasses, in cui si sono trovati i delegati

sindacali, i tecnici e i managers intervistati nel corso dell'indagine sul campo sottolineano, anche per un contesto per certi versi avanzato come quello norvegese, l'interrogativo su quali siano le modalità e gli strumenti di cui si dovrebbero dotare gli attori per intervenire più effica-cernente nelle situazioni di cambiamento tecnico-organizzativo.

In altri termini, è stato verificato che la presenza di accordi sulle nuove tecnologie ha sì "scongelato" molte prerogative che attribuivano in modo unilaterale la ■proprietà esclusiva della progettazione al management (Ciborra, 1984), ma ciò non è stato sufficiente a scongelare quei circoli ,viziosi organizzativi, in cui tutti gli attori potenziali del cambiamento sono spesso imprigionati e che impediscono l'espressione ed il dispiegamento di potenzialità progettuali più ampie. Si pone allora, e viene percepito nettamente, il problema del che fare, "del cosa fareste voi" (noi studiosi) "se...". Le parti, ridotte le barriere, le recinzioni che separano la

non sanno progettazione dagli utenti dei sistemi,

come intervenire progettualmente.

E' questa una delle conclusioni dello studio empirico: il livello a volte modesto di incidenza degli accordi sulle soluzioni progettuali rea­ lizzate nei sistemi informativi studiati in Norvegia dipende dalla compresenza dei fattori seguenti (che si possono leggere anche come bisogni per una progettazione più partecipata): - mancanza di un sufficiente livello di

formazione e conoscenze specialistiche sul problema (tecnologia EDP ; metodologia di analisi dei sistemi e gestione di progetti ; conoscenza di gestione aziendale; teoria dei sistemi informativi, etc.);

- mancanza di una strumentazione efficace e fa­ cilmente utilizzabile, adatta alle nuove domande poste dagli attori vecchi e nuovi che si affacciano sul terreno della partecipazione e della progettazione (un esempio è dato dall'esigenza di un metodo efficace di analisi e previsione delle conseguenze organizzative dei sistemi, senza il quale non si possono fare quegli studi preliminari che soli conducono alla elaborazione ex ante di un contratto

realistico sul sistema da realizzare);

- risucchio dei processi di progettazione, parte­ cipata o contrattata, nelle dinamiche organiz­ zative pre-esistenti, nei giochi burocratici e nei circoli viziosi che paralizzano/impediscono lo sviluppo organizzativo, l'apprendimento e presa di coscienza dei membri. Capita con il nuovo modo di progettare, ciò che spesso accade con il nuovo strumento, il calcolatore: 1'in-capsulamento dell'innovazione nella routine

ordinaria dell'organizzazione.

Rispetto ai primi due tipi di problemi va osservato che nella situazione norvegese si stanno ottenendo risultati significativi, che giustifi­ cano il considerare quel paese come un laboratorio avanzato - «ijj progettazione dei sistemi EDP : programmi di formazione estesi e mirati agli utenti-lavoratori; continua elaborazione di stru­ menti di analisi e presa di coscienza della loro importanza: i singoli consigli di fabbrica, consu­ lenti ed alcuni enti governativi stanno investendo notevoli risorse per mettere a punto strumenti e metodi di analisi delle conseguenze dei sistemi EDP. Non si deve scordare, inoltre, e i casi analizzati lo mostrano, lo sforzo continuo di miglioramento dello strumento "accordo sulle nuove tecnologie", con la definizione di testi sempre più avanzati nello specificare come si dovrebbero svolgere i processi di automazione.

Rispetto al terzo problema, non è raro anche in Norvegia trovarsi di fronte a "situazioni bloccate", non tanto per la pervicace volontà conservatrice di singoli o gruppi, ma per l'inca­ pacità di tutti gli attori coinvolti di fare un salto di qualità nella progettazione: è per certi versi il caso esaminato delle Poste; lo è senz'altro il caso, qui non riportato, del Comune di Bergen, in cui, dopo un avvio molto rapido ed incisivo di processi di partecipazione-contrattazione (cfr. Ciborra, Schneider, 1984),

lo sviluppo partecipato dei sistemi si è arenato nelle tradizionali vischiosità che caratterizzano l'introduzione dell'EDP nella pubblica ammini­ strazione; oppure, il caso di un'azienda che opera nel settore elettronico, anch'essa molto avanzata

(cfr. Ciborra, Schneider, 1984), in cui una volta

terminata l'elaborazione partecipata di un piano strategico per l'automazione di ufficio, ci si accorge che i meccanismi tradizionali di cui ci si avvale per affrontare la gestione dei progetti (i diversi comitati di controllo, di progetto, etc.) non sono adeguati a "reggere" e porre in atto un piano molto innovativo rispetto alle pratiche aziendali correnti: gli stessi attori coinvolti in un processo ancora in fase di lancio riconoscono la mancanza di programmi adeguati d'intervento.

Tutte queste riflessioni giustificano, insieme al fatto che la metodologia qui utilizzata per analizzare i casi potrebbe venire utilizzata per intervenire in situazioni reali, una breve rivisitazione del campo della progettazione (dopo quella di Lanzara, 1984), per approfondire i diversi modi di guardare all'attività progettuale.

Questo excursus riprende la tripartizione

identificata da Lanzara fra progettazione funzio­ nale, euristica e dialogico-discorsiva, ma si colloca su un piano diverso e complementare: invece di confrontare tre dimensioni presenti nei processi di progettazione, si considerano tre modi di fare ricerca rispetto a tale attività (come analizzarla, come intervenirvi).

1.1. Lo sviluppo dei sistemi informativi come

project management

Nel campo dei sistemi informativi, e più specificamente dell'ingegneria del software

(software engineering), l'introduzione dell'in­

novazione tecnologica avviene secondo procedure di tipo funzionale ed euristico, riassumibili nel concetto di project management. Si assume che l'intervento dei progettisti, analisti, program­ matori e utenti, intesi in senso lato (ma non includendo i delegati sindacali!), abbia luogo in un contesto in cui gli attori si comportano in maniera razionale e trasparente, condividendo il fine comune di realizzare il sistema. Lo sfondo organizzativo in cui avviene lo sviluppo del sistema è perciò quello della cooperazione fra attori razionali, supposti "candidi". Lo sforzo tuttavia richiede molte persone, con competenze diverse, che si devono avvicendare secondo le poste dalla tecnologia. Inoltre, sono da ;$i|R'é're sott1 occhio le dimensioni economiche del progetto. Il problema della gestione dello sviluppo del sistema -:-diventa il problema di come coordinare molteplici risorse umane e tecniche.

A questo fine la good practice e le diverse

metodologie proposte suggeriscono innanzitutto di classificare i progetti in corso o programmati in base a un indice di complessità e rischio. Si tratta di distinguere progetti di piccola dimensione, che interessano localmente una funzione o un ufficio, da quelli di grandi dimensioni che richiedono livelli di coordinamento intraorganizzativo più articolati. Inoltre la complessità del sistema che si deve realizzare (si

automatizzano decisioni "programmabili" o "non programmabili", di livello operativo o stra­ tegico?) caratterizza con un certo fattore di rischio il progetto e quindi suggerisce livelli più o meno elevati di cautela progettuale. Per far fronte a tali diversi ordini di complessità ci si deve avvalere di meccanismi organizzativi più o meno sofisticati da mettere in atto per prendere le decisioni di sviluppo con il numero maggiore possibile di informazioni (per ridurre il rischio) ed il massimo consenso (per non far sì che manchi tutto il supporto necessario al progetto nei punti critici della sua evoluzione) (Noland, McFarland, 1 97 4).

Il secondo ingrediente è dato dalla scomposizione funzionale delle varie attività e fasi che costellano la progettazione. Tipicamente, si distinguono le fasi seguenti:

- studio di fattibilità (analisi dei requisiti; alternative tecniche; analisi costi-benefici) - decisione di investimento

- piano di progetto - specifiche funzionali - analisi di sistema

- progettazione del sistema - programmazione

- installazione - prove

- gestione/manutenzione

- auditing.

In ogni fase sono previste attività da attribuire, funzioni specializzate (analisi, programmazione, installazione, etc.), e un'adegua­ ta documentazione (sul processo di automazione.e sul sistema prodotto) deve essere generata in un

progetto impostato secondo criteri di razionalità.

L'organizzazione di progetto viene poi strutturata nel modo seguènte (per progetti di una certa dimensione):

- un ente di livello superiore che coordina ed ha 1'autorità sull'intero progetto (Comitato di Controllo o Steering Committee);

- un gruppo di (rappresentanti di) utenti, di solito a livello manageriale, o, nelle esperienze a carattere partecipativo, anche a livello operaio o impiegatizio. 11 gruppo è più interessato allo svolgimento del progetto per tutte quelle attività non esclusivamente tecniche (analisi delle proce­ dure esistenti; gestione dell'introduzione del nuovo sistema, etc.);

- la squadra di progetto vera e propria, di solito diretta da uno specialista EDP, che include anali­ sti e programmatori, e, sempre nelle esperienze partecipative, anche degli utenti operativi;

- una funzione di auditing per la valutazione, da un punto di vista teorico-economico, del sistema realizzato (Ciborra, Bracchi, 1983).

Ci si può accostare a tutte queste fasi e attività sia con un approccio funzionale che con uno euristico, orientato al problem solving,

questo a seconda degli autori che propongono metodologie ispirate a modelli tayloristici del lavoro piuttosto che modelli cibernetici à la Simon (Ciborra, 1983; Lanzara, 1984).

Tuttavia, questa modalità di gestione dei progetti è troppo semplificata, e perciò inadeguata ad affrontare una serie di dinamiche organizzative connesse con i processi di cambiamento. Ne deriva che la sua applicazione in

contesti organizzativi turbolenti non può che generare tutta una serie di conseguenze disfun­ zionali inattese, che di solito stupiscono gli at­ tori coinvolti, in particolare gli specialisti EDP, perché nelle metodologie stesse non sono presenti frames, o schemi di riferimento, per comprenderle, interpretarle ed affrontarle.

L'inadeguatezza delle metodologie correnti

di project management tradizionale si può

riassumere nell'"errore meccanicistico" e nell’er­ rore dell'"a-conflittualità".

L'errore meccanicistico

Benché si adatti bene alla razionalità dello specialista di calcolatori, la visione della progettazione come un processo produttivo o proce­ dura scomponibile funzionalmente è inadeguata. Ci si riferisce qui ad alcune tecniche della software engineering che vedono il processo di automazione

come un processo di lavorazione in serie, a cui si possono applicare i metodi di analisi e progettazione del lavoro tipici della produzione standardizzata di massa. Questo trasferimento di metodi organizzativi e gestionali dal campo del

production management a quello del project

management è però problematico, se non errato, per

almeno tre ragioni:

- la situazione progettuale è lungi dal presentare caratteristiche di stabilità, prevedibilità e programmatilità, come quella - della produzione standardizzata (ci si riferisce alle fasi di

problem setting e problem solving - Lanzara, 1984);

- non si tratta di realizzare un prodotto come assemblaggio di componenti inerti, ma di cambiare

il modo di operare di un'organizzazione fatta di persone, che sono componenti quanto meno poco inerti e motivazionalmente complessi;

- infine, lo stesso grado di rischio o incertezza, di cui pur si parla nell'ambito del project management, suggerisce proprio nel campo da cui di

solito queste analogie partono, quello della produzione di beni, la creazione di forme organiz­ zative flèssibili, parzialmente autonome nella gestione ed organizzazione del lavoro.

In altri termini, nello stesso mondo della produzione di beni materiali, caratterizzato da livelli crescenti di turbolenza, si tende ad abbandonare quelle forme organizzative taylori- s'tiche, che vengono oggi proposte per un processo di lavoro, come quello di progettazione, intrin­ secamente incerto e complesso.

L'errore dell'a-conflittualità

Come si vedrà meglio più avanti, la progettazione dei sistemi non sempre può venire concepita come svolta da un gruppo di progettisti in perfetta cooperazione. Si tratta di un processo di cambiamento organizzativo, la progettazione, che altera equilibri esistenti, la distribuzione del potere in azienda (Crozier, 1973).

In questa prospettiva socio-politica, gli stessi specialisti EDP divengono degli "agenti del cambiamento" (Keen, Gerson, 1977) dotati di un

forte potere di expertise (Perrone, 1973). Nel­ l'organizzazione intesa come "ordine negoziato", lo sviluppo dei sistemi informativi non fa eccezione: esso avviene tramite processi di negoziazione fra le parti. E ’ naturale che l'ignorare questa dimensione (parzialmente)

flittuale dello sviluppo dei sistemi faccia emergere quelle "conseguenze inattese" che spesso costellano l'itinerario della progettazione.

1.2. La visione politica: la progettazione come processo contrattuale

La visione meccanicistica del project

management ignora il pluralismo dei processi

decisionali nelle organizzazioni ed il legame esistente fra informazione e potere.

Negli stessi ambienti tecnici, oramai, viene riconosciuto che "lo sviluppo dei sistemi infor­ mativi è un processo fortemente politico oltre che tecnico e che sono necessari opportuni meccanismi organizzativi che diano ai MIS [Management Information Systems] managers autorità e risorse

negoziali" (Keen, 1981).

In particolare, dato che i sistemi informativi diffondendosi sempre più nell'orga­ nizzazione, alterano le modalità e i circuiti della comunicazione, l'accessibilità e la tra­ sparenza delle conoscenze dei membri dell'or­ ganizzazione e il loro potere, qualsiasi strategia di realizzazione di un sistema informativo deve far fronte alle possibili resistenze, razionali e legittime dal punto di vista dei giochi politici, da parte di singoli o gruppi.

Questa visione si ricollega alla dimensione dialogico-discorsiva della progettazione (Lanzara,

1984), in cui il sistema è il risultato delle attività di inquiry, o indagine, condotte non più in un ambiente supposto perfettamente cooperativo, ma mediante t»pnsazioni e conversazioni fra

progettisti (intesi in senso lato), che possono anche ricorrere all'uso di comunicazioni oppor­ tunistiche, poco candide, delle informaziQni e conoscerne il loro possesso.

Lasciando ad altra sede il necessario approfondimento del legame fra informazione, potere e strutture organizzative di coordinamento

(Ciborra, 1984b), esploriamo nel seguito come sono

stati analizzati i processi tipici della

implementation game relativa ai sistemi infor­

mativi, seguendo l'analisi Keen (1981).

L inerzia, le resistenze organizzative create dalla rete di equilibri preesistenti e minacciati dall'informatizzazione possono essere affrontate con la gestione politica del processo di cambiamento. Il percorso da seguire è ancora quello indicato dagli psicologi sociali: "scongelare" la Situazione organizzativa, attivare il cambiamento, "ricongelare" la nuova situazione. Nel caso specifico dei sistemi informativi si tratta di :

- creare una motivazione e un clima di fiducia come premessa all'azione di cambiamento, che può iniziare solo se viene stipulato un contratto chiaro ed esplicito che traduca 1'impegno alla realizzazione, nonché gli obiettivi etc., fra utenti e progettisti ("unfreeze")

- attuare il cambiamento attraverso i relativi processi di analisi e progettazione ("change")

- passare alla fase di istituzionalizzazione

( refreeze"), la più delicata: i progettisti

devono lasciare in mano agli utenti un sistema assicurandosi che esso entri a far parte della loro-realtà lavorativa.

tattiche: una pianificazione top down (sistemi

calati dall'alto, con forte legittimazione del

top), piuttosto che tattiche di infiltrazione dal

basso, bottoni up, con un processo di progettazione

decentrato in piccoli gruppi con intensa parte­ cipazione degli utenti. In entrambi i casi, ma soprattutto nel primo, il successo della realiz­ zazione è però legato alla capacità dei progettisti di saper intessere una serie di processi negoziali (su grande scala e dall'alto nel primo caso, diffusi e locali nel secondo) per superare 1'"inerzia organizzativa". Qui non contano solo le competenze tecniche, ma le abilità persuasive, la capacità di creare e mobilitare coalizioni con singoli e gruppi, l'attenzione ai vincoli posti da certe strutture organizzative e 1'astuzia nel saperli aggirare, la capacità di formulare e stipulare accordi ad hoc per f ar passare 1' innovazione.

Nel l 'implementation game non ci si può attendere che la controparte faccia ricorso passivo solo all'inerzia organizzativa.

Esistono delle precise tattiche di counter

implementation, volte a far naufragare ogni sforzo innovativo.

Bardach (1977) le classifica in tre classi

principali :

- diversione di risorse (prenditela con calma; i soldi non sono un problema; cominciamo a prenderli poi vediamo);

- diversione di obiettivi (se non sanno quello che vogliono, è meglio che ce ne occupiamo noi; il progetto? O.K., però facciamolo bene tenendo conto anche delle nostre esigenze);

volta, questa funzione del sistema non ci soddi­ sfa; in realtà, questo non ci compete; siamo d'accordo e pronti a collaborare, ma...; quello che vogliamo è un sistema informativo-on-line-in-real-time-distribuito-con-un-data-base-totale Il sistema dovrà...).

A queste tattiche, i progettisti, gli inno­ vatori possono rispondere a loro volta con mosse

di "counter-counter implementation", ad esempio

quella di "bloccare", dopo averle identificate, le possibili fonti di resistenza attiva all'inno­ vazione, attraverso dei contratti che rendano impraticabili fin dall'inizio almeno alcune delle modalità sopra viste per far fallire il progetto. Ad esempio, si possono fissare obiettivi precisi al progetto, riducendo le chances di successo

delle tattiche di "diversione delle risorse".

In fondo, sono di questo tipo le funzioni che gli accordi sulle nuove tecnologie svolgono nelle aziende norvegesi. Anche se i "giochi dell'implementazione" non vengono eliminati del tutto (cfr. il caso STK riportato in Ciborra, Schneider, 1984).

Questa visione dei processi di automazione si avvale dei contributi delle scienze socio­ logiche e politiche ed è senz'altro più ricca, più vicina alla realtà organizzativa quotidiana che non quella "meccanicistica".

Essa però soffre di un lìmite: quello di non 0ffr ire agganci validi per un intervento nella situazione progettuale, cioè per una modifica del corso degli eventi. Si limita cioè ad osservare con attenzione le regole del gioco della pro­ gettazione, implicitamente accettandole. Keen

mentation basate sull'analisi politica della realtà organizzativa: tuttavia queste strategie se potranno far prevalere in qualche occasione uno degli attori, di certo contribuiranno a confermare e rafforzare la realtà organizzativa, diventando esse stesse delle pratiche che supportano quei processi sulla cui analisi esse si fondano.

Un circolo vizioso che induce gli attori a interpretare un ruolo già scritto sul copione dell'analisi politica della progettazione.

1.3. La prospettiva dell'intervento

In alcuni recenti scritti (Lanzara, 1983;

Lanzara, Matthiassen, 1983; Ciborra, Lanzara,

1983) viene esplorata un'ulteriore prospettiva da cui guardare alla progettazione. Non potendo riportare in questa sede i risultati e i dettagli di un'elaborazione ancora in progress, è ciò nonostante utile riprenderne le tesi essenziali, per illustrare la natura del problema dell'in­ tervento nel processo di progettazione.

Il punto di partenza di tale prospettiva è analogo a quello della visione politica: la progettazione viene considerata come un processo di cambiamento tecnico-organizzativo che incide tramite le tecnologie dell'informazione sui circuiti informativi, decisionali, sulla distri­ buzione delle conoscenze e del potere etc.; tuttavia il più delle volte questo disegno fal­ lisce perché è difficile cambiare comportamenti, modi cognitivi, abilità, valori, etc.

L'inerzia sociale, affermerebbe Keen (1981)

istanze di cambiamento. E l'innovazione viene incapsulata nell'organizzazione senza apprezzabili cambiamenti.

A . quésto punto però le due prospettive prendono due strade diverse: quella politica, come visto, analizza le cause dell'inerzia sociale, andando a'vedere le tattiche degli attori che coi loro comportamenti là attuano, analizzando le ragioni e le dinamiche del conflitto fra gli agenti del cambiamento e quanti nell'organiz­ zazione vi si oppongono.

L'altra-prospettiva interpreta le difficoltà incontrate dai progettisti alla stregua di quegli ostacoli, che qualsiasi iniziativa di sviluppo organizzativo incontra se volta a mutare compor­ tamenti, pratiche e mentalità.

Tali ostacoli, trascendono le volontà degli attori di opporsi, o favorire l'innovazione, a seconda dei loro interessi in gioco.

Essi sono piuttosto connaturati all'agire organizzativo e condizionano le modalità e 1 efficacia di qualsiasi strategia che un attore voglia attuare rispetto al cambiamento.

Fra i problemi più importanti al riguardo occorre sottolineare i seguenti (cfr. Lanzara, 1983) :

— lo iato fra l'organizzazione così come descritta esplicitamente dalle persone (ad esempio nelle descrizioni fatte dagli analisti di sistemi) e l'organizzazione così come viene interpretata, vissuta e creata tacitamente dai membri. La discrepanza riguarda, fra l'altro, la distin­ zione fra ciò che le persone dicono/comunicano (teoria adottata) e ciò che fanno e sanno "in pratica" (teoria-in uso); fra conoscenze

espli-cite e conoscenze taespli-cite; fra ciò che le persone danno per scontato nel lavoro quotidiano (lo sfondo) e ciò i cui contorni riescono a distinguere con nettezza e distacco dallo sfondo ;

i comportamenti delle persone debordano oltre la descrizione formale che loro stessi o un analista ne possono dare, perché sono guidati in parte da teorie e conoscenze inespresse;

- il conseguente iato che qualsiasi intervento o innovazione tecnico-organizzativa, introdotti e gestiti a partire da una concezione dei com­ portamenti organizzativi come analizzabili e descrivibili, sono destinati a creare. (Le note "conseguenze inattese" di tanti progetti di automazione sarebbero da ricondurre essen­ zialmente a tali tentativi di interpretazione guidati da teorie e razionalità parziali);

- in altri termini, gli attuali progetti di automazione il più delle volte non sono gestiti con la consapevolezza di essere un processo di intervento, ed in ogni caso sono governati da regole e strategie di almeno un ordine di complessità inferiore a quello dell'orga­ nizzazione in cui si sta operando.

Anche la più precisa delle analisi volta, in buona fede, a rendere trasparente l'organizzazione potrebbe in realtà toccare quelle conoscenze e pratiche tacite: lo svelarle non necessariamente fa funzionare meglio l'organizzazione.

Ogni processo organizzativo vive nella tensione fra ciò che gli attori sanno, ciò che fanno e ciò di cui riferiscono conversando. Piuttosto che di sistemi, procedure o "giochi", il lavorare sembra consistere n e l l 'incorrere in

situazioni da parte di attori muniti di certe teorie, o mappe, che pongono in relazione ih modo implicito, certe azioni, la situazione e i risultati. Tali teorie vengono continuamente create, applicate, trasformate e abbandonate dagli attori mentre lavorano, mentre passano in modo intermittente da una situazione alla successiva.

Lo sviluppo dei sistemi informativi come processo di intervento è finalizzato a ® r sì che i membri dell'organizzazione possano creare un processo autonomo e autogestito, il cui risultato sia il cambiamento tecnico ed organizzativo, che si esprima attraverso nuovi comportamenti e azioni.

E' un processo volto a "favorire un esperimento di apprendimento dove tutti gli attori coinvolti migliorano la loro competenza nell'agire Organizzativo e assumono responsabilità e impegno rispetto a ciò che fanno, dicono e pensano"

(Lanzara, 1983).

Secondo Argyris e Schon (1978), ogni pro­ cesso di intervento è un processo di inquiry nei

conflitti e dilemmi che tengono bloccate le organizzazioni. Scopo di un intervento è quello di aumentare la capacità dei singoli e della organizzazione per ricercare, nei dilemmi, quelle teorie di azione e comportamenti che impediscono la corretta identificazione e risoluzione dei problemi.

Ciò può essere raggiunto individuando le strategie conflittuali degli attori, i loro valori, facendoli emergere alla superficie, rendendoli oggetto di una riflessione distaccata e favorendo un processo di apprendimento che dovrebbe portare le persone a ri-inquadrare

(reframe) le situazioni bloccate.

Se 1 1analista/progettista non è certamente paragonabile allo scienziato che nel laboratorio attua il cambiamento, non è nemmeno uno stratega­ politico come lo descrive Keen (1981): egli, nella

prospettiva dell'intervento, è uno sperimentatore "calato" nelle situazioni, in cui interviene con i propri valori, obiettivi e teorie, ma da cui non si può distaccare per analizzarle e controllarle dall'esterno.

Rispetto a tali situazioni egli è piuttosto interessato a far emergere le contraddizioni, a delucidare le prospettive molteplici che contribuiscono a definire la realtà lavorativa su cui si interviene con l'automazione (Lanzara,

1983). Le descrizioni che l'analista fa sono

destinate ad entrare nella modifica della situazione. Il cambiamento si attua anche perché l ’analista s'immerge nella situazione e diventa una delle componenti del cambiamento. Dall'intervento nascono quelle nuove conoscenze della situazione, che contribuiscono a sviluppare i processi collettivi di apprendimento e cambiamento. Processi che sono di natura evolutiva, e che non possono essere analizzati ingabbiandoli in schemi cibernetici (Ciborra, Migliarese, Romano, 1984). Non volendo entrare nei

dettagli delle tecniche con cui è possibile condurre l ’intervento (cfr. Lanzara, 1982, e Lanzara, Mathiassen, 1983), riportiamo una tabella

riassuntiva di confronto fra l'approccio orientato all'intervento rispetto agli approcci analitici e strumentali (Tabella 1).

Concludendo si può osservare che uno degli interessi principali della teoria dell'intervento

è di comprendere e modificare le teorie di azione (adottate e in uso) degli attori coinvolti nei processi di sviluppo organizzativo.

Un intervento efficace dovrebbe modificare il modo con cui .le persone nelle organizzazioni pensano se stesse e gli altri, e il modo con cui si comportano, al fine di far emergere i dilemmi e di sviluppare comportamenti interpersonali più efficaci (Lanzara, 1983). L 'introduzione di nuove

tecnologie, tramite un processo d'intervento, dovrebbe far diventare l'organizzazione un sistema più efficace 'e "trasparente", nel senso che i membri sono passati attraverso un processo di apprendimento vissuto sulla propria pelle, che li ha rési più cosciènti e maturi, in grado di affrontare e rompere quei circoli viziosi che sono soliti bloccare il funzionamento dell'orga­ nizzazione. In questo senso il processo di automazione è parte integrante del processo di sviluppo organizzativo.

Tabella 1 - Confronto fra gli approcci analitico-

strumentale e interpretativo volti all'intervento

(da Lanzara, 1983)

Sistemi, problemi e

realtà, come "oggetti" esterni da analizzare

Sistemi, problemi e realtà come "mondi di vita" di cui si fa esperienza

Progettista come Progettista come

spettatore, manipolatore agente/sperimentatore

(analista) (attore)

Logica del sistema Significato della

situazione

’

Analizzare un sistema Comprendere una

o un processo situazione

Metodo scientifico Intervento

Descrizione e Inquadramento, valuta

progettazione di un _{zione, riconoscimento}

sistema _{di una situazione}

(modello di sistema) _{(quadro di una situa­}

1.4. -Alcune riflessioni di confronto

Nella prospettiva politico-contrattuale l'analisi dei giochi organizzativi è finalizzata a suggerire al progettista una strategia suffi­ cientemente astuta per riuscire a far prevalere le proprie soluzioni, nel quadro di una realtà organizzativa assunta come data; alla counter­ implementation si deve rispondere con tattiche di

counter-counter implementation, in una escalation

di mosse che, se non garantiscono a priori il prevalere di una delle parti, in ogni caso finiranno per rafforzare il funzionamento dell'or­ ganizzazione così come è, e quindi, paradossal­ mente, rappresentano comportamenti che si oppongono al cambiamento organizzativo, obiettivo dell'innovazione tecnologica. Per superare l'inerzia organizzativa, Keen (1981) raccomanda

infatti "più autorità al capo progetto", "creazione di coalizioni e alleanze", gestione della "politics of data", stipulazione di accordi per "incastrare" le parti ai rispettivi impegni ed evitare comportamenti opportunistici. Nell'approc­ cio politico-contrattuale si ritiene che la soluzione di problemi o la connessione di errori provenga da una errata analisi del problema. Dal punto di vista della teoria dell'intervento,

Argyris (1976) tuttavia sottolinea che risulta

difficile cambiare lo stato delle cose (migliorare l'efficacia delle organizzazioni), se si propongono comportamenti e strategie, in cui non si prevede come ridurre i conflitti, la sfiducia, i circoli viziosi: la visione eccessivamente realistica dell'approccio politico rischia di presentare come immutabile ciò che dovrebbe

essere oggetto di cambiamento.

Inoltre, vi è la difficoltà data dalla discrepanza, sottolineata dalla prospettiva dell'intervento, fra la teoria adottata e quella che poi effettivamente guida l'azione pratica: se non si riduce tale discrepanza è difficile apprendere veramente nuovi comportamenti orga­ nizzativi. Al di là della condivisione di certe soluzioni o nuove politiche (maggiore parteci­ pazione, decisioni collegiali, contrattazione esplicita, etc.), spesso le "teorie in uso" dei membri dell'organizzazione li "condannano" a comportarsi seguendo pratiche che ostacolano la circolazione di informazioni affidabili. Se non si tocca il livello delle "teorie in uso" ogni speranza di un effettivo cambiamento è vana.

A questo modello 1 di comportamento, o di apprendimento semplice (solo a livello di teoria adottata), Argyris (1976, 1982) contrappone il

modello I I ,. quello in cui i comportamenti delle persone permettono una gestione aperta del potere, un impegno aperto all'azione, un approccio aperto all'apprendimento che superino le barriere e i blocchi della vita organizzativa. Si tratta di un approccio rivolto all'indagine e all'esplorazione, invece che al controllo unilaterale, a tattiche di difesa o di "salvar la faccia" nei processi contrattuali o alla distorsione sistematica delle informazioni per salvaguardare o guadagnare posizioni di potere. Ciò comporta che le persone sappiano riconoscere e cambiare non solo le teorie adottate ma anche quelle in uso. Il piano dell intervento è quello del comportamento quotidiano effettivo e non quello delle idee che uno ha circa i propri comportamenti (e che possono

essere cambiate facilmente).

Nel caso dell'introduzione dei sistemi informativi, la maggiore trasparenza e circo­ lazione delle informazioni consentite dalla presenza di accordi sulle nuove tecnologie dovrebbe, sulla carta, rendere possibile una progettazione diversa dei sistemi informativi: il rendere più esplicito il processo contrattuale non migliora però automaticamente l'organizzazione, proprio perché contrattare può voler dire tenere segrete certe informazioni, non rivelare le proprie preferenze, effettuare certe minacce, etc. Tutte queste pratiche annullano le istanze di cambiamento, avanzate soprattutto da parte sindacale.

Che tutto ciò accada nella realtà lo si è verificato in alcuni casi pubblicati e non, là dove le strutture preesistenti prendono il Sopravvento ed incapsulano il cambiamento, quasi ai di là del volere delle parti.

La

prospettiva

-suo,

..ri mondo è così corni:" è, affrontando di petto il problema del cambiamento, non offre indicazioni chiare sul come vadano eliminati quegli ostacoli al cambiamento insiti nei meccanismi di apprendimento organizzativo, se non, come è stato osservato (cfr. Cohen, 1976), eliminando a priori

l'importanza del conflitto sulle risorse scarse dalla scena dell'intervento organizzativo. Se conflitto e scarsità sono tratti caratteristici della vita organizzativa, non si vede perché le persone dovrebbero essere portate a comunicare in modo candido, a non salvaguardare i propri interessi, a offrire fiducia in modo gratuito,

solo per uscire dai circoli viziosi che pur esistono nelle organizzazioni.

La felice distinzione fra teorie adottate e in uso, se può spiegare il fatto che non è sufficiente far apprendere una nuova teoria alle persone, perché queste la attuino nei loro comportamenti, non elimina però il sospetto che le "teorie in uso" che si esprimono nei comportamenti concreti dei membri dell'organizzazione siano dettate dai problemi, tipicamente politici, del conflitto sulla ripartizione di risorse scarse.

Dopo questo confronto, che dovrebbe aver messo in luce i limiti rispettivi della visione politica e quella volta all'intervento, concentriamo l'attenzione sull'analisi dei processi di progettazione osservati nelle aziende norvegesi, approfondendo dapprima le modalità di descrizione dei processi di cooperazione e conflitto.

Capitolo secondo

LA PROGETTAZIONE COME PROCESSO DI INDAGINE E CONTRATTAZIONE

2.1. Uno schema di analisi

L'analisi politica di Keen (1981), anche se integrata dall'analisi delle forze economiche che spiegano la contrattazione attorno all'innovazione tecnologica per la riallocazione dei costi e benefici sociali (Ciborra, 1984), non contiene una

tematizzazione sufficientemente dettagliata dei processi di cooperazione e conflitto, della natura di gioco misto della progettazione (Lanzara, 1984).

Occorre invece avere una chiave di lettura delle dinamiche comportamentali degli attori per essere in grado di illustrare e confrontare quanto accaduto nelle organizzazioni studiate in Nor­ vegia. In altri termini, collocandoci all'interno di una visione politico-contrattuale dello sviluppo dei sistemi informativi, abbiamo bisogno di un metodo sistematico per porre in relazione certi processi di cooperazìone e conflitto durante la progettazione con il risultato finale, cioè le caratteristiche del sistema realizzato.

In ciascuno dei tre casi studiati si sono riscontrati processi di (cfr. Mathiassen et al., 1983; Ciborra, 1984a):

- scambio di informazioni fra azienda e sindacato sulla pianificazione dell'introduzione dei nuovi sistemi ;

- partecipazione degli utenti e dei delegati alla progettazione per la risoluzione collaborativa dei problemi ;

- contrattazione fra le parti per decidere sulla allocazione dei costi e benefici generati dal nuovo sistema.

Tali processi avvengono in un ambiente organizzativo e sociale regolato da accordi generali fra industria e sindacato, da accordi aziendali e dalla legge sull'Ambiente di Lavoro che contiene alcuni paragrafi sul diritto dei lavoratori alla partecipazione nella progettazione dei sistemi. [i testi degli accordi e leggi più rilevanti sono riportati in Ciborra, Lanzara,

1984|.

A priori si possono presentare diverse situazioni di contrattazione, o di mantenimento dello status quo, o di cambiamento consensuale e partecipato: i tre casi mostrano esempi concreti di alcune di queste possibilità. Vi sono diversi fattori extra-tecnologici (Schneider, Ciborra,

1983) che possono condizionare l'andamento del processo di progettazione (nei casi si nota l'azione delle strutture burocratiche pree­ sistenti, del tipo di cultura organizzativa; dell'andamento economico dell'organizzazione): tuttavia, nella visione politica, l'effettivo risultato della progettazione dipende, oltre che dal particolare insieme di vincoli posti, dalla situazione, dai comportamenti negoziali, dalle strategie degli attori principali, dai dilemmi e interdipendenze nelle decisioni tipici dei giochi misti di cooperazione e conflitto (Schelling,

1960). Un'analisi d i 'questi comportamenti ed una casistica delle possibili situazioni ed effetti è

stata svolta da Walton e McKersie (1963, 1966),

anche in relazione a problemi di relazioni industriali.

Una prima situazione progettuale da prendere in considerazione è estremamente semplice: due attori-progettisti si trovano a dipendere l'uno dall'altro‘per la risoluzione di un problema.

Se entrambi cooperano, cioè mettono a mutua disposizione conoscenze e idee per un problem

solving di tipo pienamente cooperativo, ottengono

un guadagno della risoluzione del,-problema. Vi è tuttavia il -problema della ripartizione del guadagno ottenuto: questo è il terreno del conflitto puro, del gioco a somma zero, che tuttavia non può non influenzare anche la fase precedente di risoluzione del problema; ogni attore sa che le informazioni rivelate candi­ damente nella fase di risoluzione del problema lo "scoprono" agli occhi dell'altro giocatore, il quale può usare tali informazioni sia per risolvere il problema che per contrattare l'allocazione dei benefici da una posizione di forza, poiché conosce preferenze, capacità e risorse dell'altro.

Se però entrambi gli attori, pensando a quanto può accadere nella fase di contrattazione, non comunicano, o comunicano in modo distorto, durante la fase di problem solving, si trovano di fronte al classico "dilemma del prigioniero": per evitare di cooperare, o comunque alla ricerca del massimo vantaggio individuale, finiscono per conseguire un risultato sub-ottimo.

Walton e McKersie modellizzano le diverse

alternative disponibili ad ogni giocatore in un gioco misto con quattro strategie principali.

Dapprima i due processi, problem solving e

contrattazione, vengono trattati separatamente. In una situazione di cooperazione, il guadagno ottenibile da una attività congiunta di

problem solving dipende dalla capacità delle parti

di scoprire e riconoscere i mutui interessi e la loro complementarietà, nonché i meccanismi da mettere in opera per sfruttare le potenzialità di integrazione degli sforzi nella risoluzione del problema.

Un esempio è dato dalla situazione di gioco della matrice della Figura 1 (i numeri in questa e nelle altre matrici sono puramente indicativi).

Figura 1 - Gioco di cooperazione

a

SQ PS

SQ 12 16

b

PS 16 20

SQ = mossa di status quo

Se a e b perseguono strategie conservatrici

di mantenimento dello status quo ottengono un

guadagno della collaborazione di 12. Se però fossero disposti ad assumere una strategia più orientata al problem solving potrebbero ottenere

guadagni superiori (16 o 20). Una strategia volta

al problem solving comprende le attività

decisionali seguenti:

® ? identificazione dell'agenda di lavoro, delle possibili aree di reciproco interesse (chiarire gli assunti, le motivazioni, gli obiettivi, i bisogni, le preferenze e fare un'analisi della situazione attuale);

- ricerca di alternative possibili;

■= valutazione congiunta delle conseguenze di ogni alternativa;

- scelta dell'alternativa migliore.

E' chiaro che l'efficacia delle fasi deci­ sionali e di ricerca o indagine dipendono dalle competenze progettuali e relazionali dei progettisti e dalla disponibilità/capacità di scambiare in modo ampio tutte le informazioni e conoscenze in loro possesso circa le alternative, le loro conseguenze, i bisogni rispettivi, nonché le disponibilità ad impiegare risorse per esplorare nuove alternative.

La situazione di contrattazione riguarda invece l'allocazione fra le parti del guadagno ottenuto col problem solving cooperativo. La Figura 2 riporta la matrice che descrive un gioco di contrattazione per la suddivisione fra a e b

del guadagno di 12.

La matrice prevede due tipi di atteggiamenti/mosse contrattuali: soft (S) e hard

contratta-Figura 2 - Matrice di contrattazione a

S H

6 ,6 2 , 1 0

1 0 ,2 0 , 0

S = strategia di contrattazione soft

H = strategia di contrattazione hard

re in modo soft, si dividono a metà (6) il guadagno; se uno dei due riesce ad imporre un comportamento contrattuale più "duro" dell'altro può ottenere un guadagno maggiore (10), ma nel caso in cui si trovi di fronte un avversario altrettanto deciso ottiene un guadagno nullo (o negativo, se si conteggiano anche i costi di una strategia dura, come uno sciopero ad oltranza).

L'adozione di una strategia contrattuale rispetto ad un'altra dipende da un complesso insieme di decisioni, comunicazioni e infor­ mazioni. Ad esempio, b dovrebbe riuscire a indurre

e ad adottare una strategia S per essere sicuro di

guadagnare almeno 6 o, nel caso migliore, 10. Ciò può avvenire se b è capace di far percepire ad a

in modo distinto i guadagni della matrice di Figura 2; oppure se riesce a comunicare un impegno fermo (minaccia) di adottare comunque una strategia H: nel tal caso ad a non

rimane che scegliere S per ottenere almeno un guadagno minimo diverso da zero.

Le due strategie H ed S corrispondono

essenzialmente ai due comportamenti di base, rispettivamente quello che cerca il guadagno massimo possibile correndo il rischio di incorrere nella situazione peggiore per entrambi; oppure quello prudente che rinuncia al massimo guadagno, riducendo il rischio di capitare nella situazione peggiore.

Le due matrici viste possono essere integrate nella matrice a quattro entrate di Figura 3 che combina fra loro le strategie di

problem solving e di contrattazione.

Figura 3 — La matrice di cooperazione e conflitto

/ X

!

6,6

Su tale nuova matrice si possono individuare quattro strategie complesse, due pure e due miste. Quelle pure sono:

PS-S: questa strategia contempla un atteggiamento di cooperazione volto alla risoluzione del problema e, successivamente, un comporta­ mento contrattuale soft nella fase di ripartizione dei guadagni. Il rischio è che l'avversario potrebbe avvantaggiarsi in quella fase scegliendo una strategia SQ—H o PS-H.

SQ-H: qui si rinuncia ad esplorare nuove al­ ternative e si contratta duramente per mantenere lo status quo. Il rischio è dato dal costo opportunità dei guadagni a cui si rinuncia.

Quelle miste sono:

SQ-S: a priori non vi sarebbe alcuna convenienza ad impiegare una strategia di questo tipo: si rinuncia ad esplorare le alternative e non si contratta duramente (*). E' una strategia che dà, ad esempio a b , il minimo risultato diverso da zero. Si tratta di una strategia razionale se b sa per certo che a

perseguirà un comportamento SQ-H.

(*) Qui non si prendono in considerazione i costi di attuazione delle diverse strategie: ad esempio la strategia PS potrebbe essere notevolmente più costosa della SQ. La considerazione di tali costi potrebbe alterare i valori della matrice e la convenienza relativa delle diverse strategie.

PS-H: questa è la strategia più "spericolata", che cerca di ottenere il massimo guadagno da entrambe le fasi di cooperazione e contrattazione; ma è quella più rischiosa, che può condurre cioè a risultati del tipo

(0,0) .

2.2. Alcuni dilemmi

Walton e McKersie effettuano un'analisi

sistematica dèlie situazioni problematiche a cui gli attori, che operano come nel caso della progettazione contrattata, in situazioni miste descritte dalla matrice di Figura 3, si trovano di fronte :

- la compresenza della fase di con­ trattazione con quella di problem solving, fa sì che le preoccupazioni di ordine strategico (non svelarsi, bluffare) ostacolano la fase esplo­ rativa, più aperta dal punto di vista comunicativo

del problem solving. In generale la presenza della

contrattazione spinge verso l'adozione di strategie SQ rispetto a quelle PS;

- mentre il problem solving richiede di

essere più aperto e disponibile a tentare e sperimentare, la contrattazione richiede di essere fermamente intenzionata ad affermare/mantenere certe posizioni; ogni scostamento od oscillazione che nel primo caso è salutare, può essere fatale dal punto di vista dell'indebolimento della posizione contrattuale;

- d'altro canto solo un processo di ricerca può allargare lo spettro delle alternative, può far trovare nuove soluzioni al problema, ampliando

il campo stesso della contrattazione. Tale processo è ostacolato dalle tattiche contrattuali

SQ ben note: ripetizione ossessiva delle argo­

mentazioni; attaccamento pregiudiziale ad una

certa soluzione; interruzione improvvisa delle

discussioni etc.;

- se un attore suggerisce un'alternativa,

questa, nel contesto contrattuale, viene imme­

diatamente percepita come l'alternativa minima per quell'attore rispetto a cui l'altro decide di

guadagnare il massimo. Ciò impedisce processi di

ricerca congiunti e favorisce i bluff o la

presentazione di false esigenze, solo per ottenere

vantaggi nella contrattazione: si ha cioè un

depistamento degli sforzi di ricerca;

un'altra conseguenza che si viene a

determinare è relativa alle scadenze che si

pongono ai processi di ricerca: questi vengono

interrotti bruscamente sotto la minaccia della

urgenza, per "stanare" e costringere l'avversario

a prendere nella fretta certe risoluzioni invece che altre;

— manipolazione della propria posizione

contrattuale: una delle parti può di nuovo

interrompere o condizionare i processi di ricerca comunicando di "avere le mani legate" rispetto alla scelta di certe alternative o scadenze;

— manipolazione dei canali di comunicazione: l'incanalamento delle comunicazioni dettate dalle

esigenze contrattuali ostacola l'apertura e

1'evolutività delle comunicazioni volte all'in­

dagine, alla scoperta, all'apprendimento;

— in generale, sono stati osservati nei

processi contrattuali effetti psicologici di

fatti, nella creatività, nella capacità di mantenimento di certi obiettivi iniziali; inoltre, sono stati notati in numerosi studi di laboratorio atteggiamenti eccessivamente difensivi che ostacolano un'attività efficace di problem

solving. „

2.3. Meccanismi per far fronte ai dilemmi

Nelle situazioni miste si può ricorrere a meccanismi organizzativi disposti ad hoc per

ridurre gli effetti negativi della commistione, inevitabile, fra processi contrattuali e di riso­ luzione dei problemi, i meccanismi più frequen­ temente usati sono:

- differenziare le due fasi, isolando i processi

di' problem solving dalla contrattazione vera e

propria. Vengono a tale scopo creati gruppi di lavoro distinti. Oppure la progettazione viene affidata ad una squadra di tecnici, utenti etc., mentre la contrattazione, qualora necessaria, è rinviata al tavolo delle trattative azienda- sindacato, svolte da persone diverse dalle precedenti. Si ottiene così a livello di pro­ gettazione un'atmosfera atta ad eliminare quegli ostacoli psicologici che si frappongono alla esplorazione e alla ricerca di soluzioni progettuali. La separazione dei due processi consente inoltre di coinvolgere molte più persone (utenti) soprattutto nella fase di indagine a

problem solving, mentre la contrattazione viene

istituzionalizzata ed affidata ad un numero ristretto di rappresentanti istituzionali;

solving, le norme di allocazione dei bene-

fici/costi ottenuti all'interno di un certo

orizzonte temporale;

- stabilire delle regole generali di ripartizione

dei benefici/costi ispirate a norme sociali

generali (egualitarismo, livello dei bisogni,

potere di mercato, etc.);

- rispetto di certe regole da seguire nella

contrattazione (ad esempio, l'impegno a non

utilizzare certe informazioni rivelate in fase di

problem solving, che possono assumere rilevanza

strategica a fini contrattuali). Il rispetto può

venire imposto o tramite la minaccia di ritorsioni

(che deve essere credibile ed efficace), oppure

l'instaurazione di una relazione di fiducia fra le parti in entrambe le fasi di problem solving e

contrattazione. Questo meccanismo è particolar­

mente utile quando le situazioni di gioco misto si ripetono nel tempo '(tanti sistemi da progettare),

per cui le parti hanno la possibilità di

verificare l'affidabilità reciproca.

L'instaurazione di più elevati livelli di fiducia fra le parti per far fronte a situazioni di sempre maggiore ambiguità e incertezza nella gestione dello sviluppo tecnologico sono stati recentemente ripresi dallo stesso Walton (1984) e da Ouchi (1981).

Capitolo terzo

SINTESI DEI PRINCIPALI RISULTATI DEGLI STUDI DI CASO

Per valutare se e come la contrattazione e la cooperazione, consentite dagli accordi e leggi vigenti fra azienda e sindacato, abbiano avuto un impatto sulla progettazione, in particolare la configurazione finale del sistema risultato dell'attività progettuale, sono stati studiati i processi di sviluppo dei sistemi in tre organizzazioni norvegesi ( *) .

Il percorso. concettuale seguito per raccogliere e sistemare i dati empirici è illustrato nella Figura 4.

Le caratteristiche tecniche dei sistemi automatizzati sono state viste come risultato .dell'azione combinata delle dinamiche contrattuali yè di cooperazione fra i partecipanti al progetto

(*) L'indagine sul campo si è svolta nel dicembre 1983 ed ha interessato oltre alle tre organizzazioni analizzate nel seguito, anche il comune di Bergen e la Standard Telefon og Kabel di Oslo (studi di caso non riportati). In ogni azienda sono state effettuate una decina di interviste a managers, tecnici, responsabili E D P , responsabili della Direzione Personale, delegati sindacali e lavoratori.

Figura 4 - Schema concettuale per la rilevazione e sistemazione