Rendere visibile l’impresa attraverso il software: una etnografia delle

pratiche di modellazione d’impresa

Gian Marco Campagnolo

1. Introduzione

Quest’articolo affronta e descrive pratiche di modellazione visuale d’impresa. Il

materiale su cui si basa l’articolo è tratto da un’etnografia condotta all’interno di un
progetto europeo di durata triennale riguardante l’innovazione nei processi
produttivi nel contesto manifatturiero automobilistico ed elettronico. L’articolo
presenta un’analisi etnografica dell’introduzione da parte di un gruppo di ingegneri
del software, presso tre diversi casi industriali, di una tecnologia da loro sviluppata
per la modellazione d’impresa. Il materiale empirico è stato raccolto durante gli
incontri che gli ingegneri hanno avuto con i rappresentati delle imprese
manifatturiere nei primi sei mesi del progetto, quando si trattava di selezionare gli
aspetti del processo produttivo che i rappresentanti delle imprese avrebbero voluto
modellare attraverso il software di modellazione fornito dagli ingegneri del
software. L’osservazione sul campo ha riguardato gli ingegneri del software al
lavoro, nel contesto della loro partecipazione al progetto in qualità di fornitori del
software per la modellazione d’impresa, e l’applicazione in questo contesto di un
particolare approccio alla modellazione d’impresa: le ‘scene visuali d’impresa’. Il
presente studio si inserisce all’interno della tradizione degli studi sui modi in cui la
tecnologia fornisce gli strumenti per rendere visibili l’organizzazione sociale, il
lavoro e la produzione di massa (Latour, 1986; Lynch, 1990; Suchman 1993, 1995).
La ricerca vuole fare vedere come le nuove tecnologie di visualizzazione dei
processi di lavoro collaborativo tendano a ridefinire le pratiche lavorative.
L’approccio adottato nella presente ricerca è basato sull’osservazione del ruolo che
tali tecnologie - tecnologie che Ueno ha definito tecnologie di “mutua visibilità”
(Ueno, 2000) - rivestono nelle interazioni fra ingegneri e utenti orientate a
progettare un software che renda visibili i processi produttivi. Il presupposto che
questa ricerca condivide con la tradizione degli studi sociali sulla scienza, e in
particolare con gli studi sui suoi strumenti di visualizzazione (Lynch, 1990), è che
l’organizzazione sociale del lavoro non è pre-esistente né indipendente dagli
strumenti che permettono di visualizzarla, condividerla e modificarla. Sotto forma

1
di queste tecnologie di mutua visibilità – come le ‘scene visuali d’impresa’ - gli
ingegneri del software propongono agli utenti delle forme organizzative in parte
diverse e in parte trasformate rispetto a come venivano precedentemente
rappresentate dagli utenti stessi.
Le tecnologie di “mutua visibilità” studiate nel progetto (le ‘scene visuali d’impresa’)
possono essere considerate ‘boundary objects’ (Star, 1989; Star and Griesemer,
1989) nel senso che servono come media di negoziazione e di traduzione (i) fra
diversi approcci alla modellazione, (ii) fra le aspettative e i requisiti di una
molteplicità di attori e di organizzazioni e (iii) fra diverse tipologie di sistemi di
classificazione.
Per quanto riguarda gli approcci alla modellazione, gli elementi oggetto della
negoziazione sono i diversi approcci ‘regionali’ alla modellazione, usati nei diversi
contesti industriali considerati.
Le aspettative a partire dalle quali le ‘scene visuali d’impresa’ acquistano significato
per l’organizzazione sono quelle del management da una parte (controllo e
imposizione d’ordine) e quelle dei lavoratori operativi dall’altra (supporto al lavoro
collaborativo).
Gli elementi in gioco per quanto rigarda le tipologie di classificazione verranno
invece discussi alla luce dei diversi contesti materiali in cui i sistemi di
classificazione vengono inscritti: pratiche discorsive, artefatti fisici pubblicamente
disponibili e software.
Lo studio dettaglierà alcune caratteristiche della configurazione assunta da approcci,
aspettative e tipologie di classificazione nel corso dell’elaborazione pratica in situ
dalle scene visuali d’impresa.

2. Gli studi sociali sulle tecnologie di visualizzazione degli ingegneri del software

Lo studio di come gli individui costruiscono, vedono e classificano i fenomeni che

definiscono il loro mondo sociale è stato un tema lungamente trattato nell’analisi
dell’azione umana, della cognizione e dell’organizzazione sociale. Latour (1990) ha
sostenuto che le convenzioni rappresentazionali nell’ingegneria hanno avuto lo
scopo di mantenere una “consistenza ottica” fra gli oggetti tridimensionali e i
renderings bidimensionali che comprendono sketches, piani e similari (pp. 52-54).
Nel contesto dell’ingegneria meccanica, Henderson (1991, p.459) ha osservato che
le pratiche discorsive permettono alle rappresentazioni schematiche di rimanere

2
sufficientemente flessibili affiché gli ingegneri ne leggano le funzioni codificate e
comprendano le loro interrelazioni con i vari componenti funzionali dell’intero
progetto. Alder (1998) ha descritto i modelli tridimensionali usati dagli ingegneri
(cosiddetti ‘piani liberi’) come un tentativo di correggere le distorsioni di scala su cui
si basava il disegno prospettico. Tali correzioni, osserva l’autore, hanno richiesto lo
slittamento della posizione dell’osservatore dal fronte della scena o dell’oggetto ad
una visione a volo d’uccello o view from nowhere (pp.513-514). Queste realizzazioni
grafiche rimandano a ciò che Goodwin (1994) ha definito “visione professionale”:
la capacità di leggere lo schermo del computer come surrogato del luogo fisico a cui
l’ingegnere è interessato (nel nostro caso, l’impresa). Ma le rappresentazioni non
sono la cosa reale: nella rappresentazione c’è sempre un’operazione di selezione
rispetto a quello che viene rappresentato (Suchman, 1987); le rappresentazioni sono
costrutti locali e temporanei (Gerson and Star, 1986). C’è inoltre una differenza
fondamentale, dovuta al contesto materiale, fra categorizzazione pratica inerente le
attività ordinarie e sistemi di classificazione coerenti e sistematici, basati su
notazioni codificate (Schmidt & Wagner, 2004). Le pratiche di discriminazione
coinvolte nelle rappresentazioni sono differenti se si tratta di vedere qualcosa come
diverso rispetto a qualcosa d’altro; di separare fisicamente qualcosa da qualcos’altro;
di categorizzare un evento x come C; oppure di classificare x come C all’interno di
un sistema di classificazione inscritto in un artefatto e pubblicamente disponibile
(Schmidt & Wagner, 2004: p.392). In questo studio propongo una ulteriore
dimensione: la materialità del software si può considerare caratterizzata da una
profonda riconfigurabilità (“deep remixability”, Manovich, 2008), e cioè da una
profonda fusione di contenuti di diversa provenienza (testo, foto, video), ma anche
di tecniche costruttive proprie di ognuno di questi media, di metodi di produzione e
di convenzioni rappresentazionali ed espressive loro proprie. Facendo riferimento
al caso di studio, illustrerò questa ulteriore caratteristica rispetto alla fusione, nello
stesso artefatto software (le scene visuali d’impresa), di diversi approcci alla
modellazione, aspettative di gruppi sociali differenti, e caratteristiche afferenti a
diverse tipologie di artefatto.

3. L’approccio situato alle tecnologie e la prospettiva della contingenza

L’approccio che considera le tecnologie di “mutua visibilità” (Ueno, 2000) come

necessariamente situate si colloca all’interno di una prospettiva che sottolinea la

3
 natura contingente dell’organizzazione delle attività collaborative. Tale prospettiva
nasce in opposizione alle grand theories sul controllo, secondo le quali gli artefatti
incorporano irreversibilmente fome di oppressione (Winner, 1980). L’approccio
situato può definirsi dunque ‘contingentista’ per il fatto che nel descrivere il nesso
causale fra le intenzioni del progettista e le forme di discriminazione incorporate
nell’artefatto viene assunto un alto grado di contingenza (Jorges, 1999)1.
All’interno di questo approccio esistono comunque posizioni diverse circa il ruolo
della contingenza nel rapporto fra intenzioni, progetto e interpretazioni. La
contingenza può infatti essere attribuita alla variabilità del contesto concreto oppure
alla varietà delle interpretazioni. Mentre secondo alcuni il potere delle cose dipende
dal contesto materiale, da come esse sono sintagmaticamente relazionate con altre e
dall’esito della competizione paradigmatica con contro-programmi d’azione
(Latour, 1988), secondo altri le rappresentazioni progettuali sono inseparabili dalle
pratiche discorsive ad esse associate (Suchman et al., 2002). Infine, per alcuni autori
la contingenza dipenderebbe dall’interpretazione testuale del lettore (Grint &
Woolgar, 1997; Neyland & Woolgar 2002) invece che dalla competizione fra
programmi di azione.
Il presente studio sottoscrive la tesi che le tecnologie software di “mutua visibilità”
siano boundary objects (Star, 1989; Star and Griesemer, 1989), oggetti di frontiera
fra controllo e contingenza che servono come media di negoziazione e traduzione
fra reciproche aspettative di di attori e organizzazioni diverse. Inoltre si ritiene che
quella specifica tecnologia di “mutua visibilità” nota come “scene visuali d’impresa”
sia costitutivamente ambigua. Essa si colloca infatti, da un lato, fra diversi approcci
regionali alla modellazione d’impresa, dall’altro, fra artefatto rappresentazionale e
artefatto coordinativo. Tale ambiguità si trova inoltre riflessa nei diversi livelli
composizionali del software.

4. L’architettura d’impresa

Nell’ingegneria informatica la modellazione è una pratica che guida la scrittura del

codice di un programma software. Il modello viene usato come protocollo per lo
scambio di specificazioni fra ingegneri.

1
Per una discussione più approfondita sul tema vedi G.M. Campagnolo, La prospettiva actor-network, in: T.M. Fabbri, L. Solari
(a cura di) Organizzare: concetti e metodi, Carocci, Roma (in corso di edizione 2009).
4
Per gli architetti d’impresa, invece, la modellazione costituisce soprttutto una guida
per la visualizzazione dell’attività organizzativa nella sua totalità (Zachman, 1987).
Prima dell’avvento degli architetti d’impresa, nelle imprese co-esistevano diversi
modelli, ognuno dei quali attrezzato con un proprio software. Perciò si utilizzava un
modello per lo sviluppo dei programmi software (come può essere, ad esempio, un
modello in Microsoft Visio); un secondo modello veniva disegnato con programmi
CAD (Computer Aided Design) e usato per lo sviluppo del prodotto; un terzo
modello (spesso semplicemente disegnato su carta) veniva usato per descrivere la
struttura organizzativa; un quarto modello per tenere traccia dei processi produttivi
veniva sviluppato con le tecnologie di Business Process Modelling. Gli architetti
d’impresa hanno criticato l’esistenza di una moltitudine di queste ‘isole
tecnologiche’ perché non sono ritenute efficienti. In questo modo infatti ogni
sistema di modellazione viene predeterminato dai programmatori dei diversi
software, persino nell’elenco di regole utilizzabili. Inoltre l’interfaccia del sistema è
orientata ad un utente con competenze ingegneristiche e non consente stili di
modellazione non previsti a priori (Lillehagen et al., 2003). Per questo motivo gli
architetti d’impresa sostengono l’utilizzo di una singola piattaforma informatica
(l’architettura d’impresa, appunto) in cui tutti i modelli dei diversi eventi
organizzativi siano connessi: prodotti, processi, sistemi e risorse umane.
L’obiettivo è dunque quello di rendere esplicita e condivisibile fra i diversi
programmi software e fra i diversi dipartimenti dell’azienda la conoscenza
d’impresa. La tecnologia di “mutua visualizzazione” oggetto di studio della presente
ricerca mira precisamente ad estendere le capacità dei sistemi di Business Process
Modelling attraverso un approccio che gli architetti d’impresa definiscono “Scene
Visuali d’Impresa”.

5
Fig. 1 Le scene visuali d’impresa

La maggior parte dei metodi di modellazione sono costituiti da quattro ‘viste’. Tale
scelta sembra corrispondere alla necessità di poter ricreare lo spazio organizzativo
secondo la metafora delle pareti di una ‘stanza’, in cui poter ‘entrare’ per prendere
decisioni sulla base di uno ‘sguardo’ d’insieme dei processi. Ecco ad esempio la
descrizione riportata in un articolo scientifico di un architetto d’impresa della
‘stanza delle decisioni’ usata dal management di un’industria automobilistica:

Ora immagina di guidare il modello 740 nella stanza. Vogliamo soluzioni che ci
permettono di vedere come queste strutture e questi ruoli rappresentati sulle pareti
prendono vita e vengono adattati ed estesi per descrivere esattamente i componenti
costruttivi del modello 740. (Lillehagen et al., 2003, p. 2)

Questa “stanza” viene a volte chiamata war room industriale. Sulle quattro pareti
vengono affissi documenti concernenti le diverse dimensioni organizzative.
L’utilizzo del termine war room allude alla complessità dell’utilizzo di questi sistemi:
sebbene gli architetti d’impresa ritengano che le loro interfacce grafiche siano adatte
anche a un utente generico, ogni modello rispecchia marcatamente il punto di vista
del suo creatore sull’oggetto in quesitone (Curtis et al., 1992). Di conseguenza, esso
è spesso contestato dagli utilizzatori.

6
5. I casi osservati: l’innovazione di processo nel contesto manifatturiero
automobilistico ed elettronico

Come detto, abbiamo osservato in particolare l’“innovazione di processo” nel

contesto manifatturiero. L’obiettivo generale del progetto mirava a sviluppare
un’infrastruttura e dei servizi di ingegneria partecipativa. Nella sperimentazione
erano coinvolte tre imprese di diversi Paesi europei: due dell’industria
manifatturiera automobilistica e una dell’industria manifatturiera elettronica. La fase
del progetto in cui si è svolta l’etnografia è stata la fase di modellazione dei
“requisiti di processo” delle tre aziende. I dati sono stati raccolti utilizzando
registrazioni audio-video durante le prime sedute presso le imprese manifatturiere,
svolte in un periodo di quattro mesi fra dicembre 2005 e marzo 2006. In totale si
sono filmate circa 20 ore di riunione. Le sedute di modellazione si sono svolte
separatamente presso le rispettive sedi aziendali. A tali riunioni partecipano vari
membri del progetto: in primo luogo, i manager delle imprese coinvolte insieme ad
alcuni esperti del dominio specifico di volta in volta in questione; in secondo luogo
gli architetti d’impresa, in rappresentanza della componente tecnologica del
progetto. Nella fase di modellazione dei requisiti di processo l’obiettivo è di far sì
che esperti di dominio e architetti d’impresa, utilizzando il software di modellazione
proposto dagli architetti, riescano a rappresentare l’intero processo produttivo del
‘caso d’uso’ selezionato. L’infrastruttura e i servizi sviluppati nel corso del progetto
verranno poi sperimentati su questo caso d’uso. I dati qui di seguito presentati
riguardano tali sedute di modellazione.

6. La frammentazione delle pratiche di modellazione d’impresa

Il primo contesto sperimentale del progetto coinvolge un centro di ricerca sulla

manifattura automobilistica. In esso, il diverso grado e le diverse competenze fra i
partecipanti alla seduta di modellazione genera schemi e rappresentazioni divergenti
riguardo alla modellazione dei processi produttivi. Nel corso della seduta di
modellazione si svolge una negoziazione fra differenti convenzioni di
visualizzazione dei processi, che evidenzia nel contesto locale una più generale
tendenza alla frammentazione delle pratiche di modellazione d’impresa. Pur
utilizzando il medesimo strumento informatico con la guida di un architetto

7
 d’impresa, i partecipanti alla riunione (anche gli esperti di dominio) finiscono col
‘vedere’ i processi produttivi della propria impresa in modo diverso. Ciò è
determinato dall’utilizzo di profili preconfezionati di oggetti e di relazioni
(cosiddetti ‘templates’) che sono disomogenei tra loro. Qui di seguito cerchiamo di
ricostruire la genesi locale di tali disomogeneità.
La selezione del processo che deve essere modellata nell’odierna seduta di
modellazione consiste nella fase di definizione dei parametri di un nuovo modello
automobilitico. Questa fase è nota come Target Setting. Come in ogni altra fase del
processo manifatturiero automobilistico, si parte da documenti procedurali che
contengono le modalità di svolgimento dei compiti e un aggiornamento sullo stato
della loro realizzazione. Il flusso dei documenti procedurali è attualmente
rappresentato da un modello del tipo ‘flusso di attività’. Esso è progettato secondo
un approccio noto come ‘Merise’, diffuso soprattutto in Francia2. Abbiamo un
diagramma di attività composto da figure geometriche disposte all’interno di una
tabella, in cui le colonne rappresentano i diversi attori coinvolti in quel momento
nella attività rappresentata.

Fig. 2 Il diagramma di attività nella notazione Merise

2
Nel contesto anglosassone si utilizzano invece soprattutto i metodi SDM/S e Axial.
8
I partecipanti alla seduta di modellazione sono: il manager del pilota industriale (J3)
e due esperti di dominio (G1 e M2) da parte del centro di ricerca sulla manifattura
automobilistica; un faciliatore proveniente da una istituzione accademica
partecipante al progetto (H4) e un architetto d’impresa (S5), per quanto riguarda la
componente tecnologica. A dimostrazione che la pratica di rendere visibile
l’organizzazione del lavoro non è un privilegio dell’ingegneria dei sistemi o della
progettazione, nel presente caso, che chiameremo caso Alfa, ogni partecipante alla
seduta sembra avere una diversa competenza nella modellazione: l’architetto
d’impresa utilizza l’approccio delle ‘scene visuali d’impresa’; i due esperti del
dominio utilizzano invece, rispettivamente, l’approccio ‘Merise’ e il metodo IDEF
(Integrated Definition Method); il facilitatore utilizza altre notazioni ( UML o
Universal Modeling Language e la sua evoluzione XML). Non c’è però una
convenzione rappresentazionale conosciuta da tutti allo stesso livello. L’architetto
d’impresa non conosce la notazione ‘Merise’: ad esempio, scambia i
parallelogrammi per processi, quando invece essi stanno a indicare dei documenti.
Inoltre non sa che per cominciare a modellare un flusso di attività è necessario un
evento iniziale vuoto. Gli esperti a loro volta non conoscono le ‘scene visuali
d’impresa’. Per poter portare tutti i partecipanti a un livello di conoscenza
omogeneo, l’architetto d’impresa effettua nella mattinata una seduta di formazione.
Durante la seduta, i partecipanti lavorano su diversi terminali con un software
distribuito dall’architetto d’impresa.
L’interfaccia del software distribuito é composta, a sinistra, da una libreria di
oggetti, contenitori e relazioni e, a destra, da un’area per la modellazione visuale
(Fig. 3).

9
Fig. 3 In software distribuito dall’architetto d’impresa

Sebbene l’architetto d’impresa abbia distribuito la licenza d’uso del programma

qualche giorno prima della seduta di modellazione, si scopre sul momento che due
partecipanti su tre non l’hanno attivata. L’architetto è perciò costretto a distribuire
una copia sostitutiva, che però risulta diversa dalla versione circolata in precedenza.
In particolare, la libreria di oggetti per la modellazione è differente. La seduta di
formazione comincia quindi con alcuni partecipanti che hanno una disponibilità di
schemi rappresentazionali diversa da altri.
Per cercare di rendere omogenei i diversi livelli di esperienza e di competenza
dimostrati dai partecipanti alla seduta, l’architetto dimostra diversi template, cioé
profili preconfezionati di oggetti e relazioni. Si va dal profilo generico al template
specifico per la gestione di un singolo aspetto d’impresa, ad esempio l’IT
(Information Technology). Inoltre alcuni template sono brevettati, altri invece sono
solo convenzioni rappresentazionali consolidate, come il Business Process
Modelling. Nella dimostrazione, l’architetto introduce i diversi profili
preconfezionati, utilizzando anche esempi di modelli già sviluppati in altri progetti o
in altri casi; quindi invita ogni utente a sperimentare i diversi profili, valutandone il
gradimento. Nel software possono essere caricati diversi profili
contemporaneamente, ampliando la libreria di oggetti e relazioni (fig. 3). Inoltre,
ogni volta che viene caricato un modello sviluppato con un determinato profilo, è
necessario che l’utente aggiorni il proprio profilo per poterlo visualizzare
correttamente. I partecipanti alla seduta utilizzano gli oggetti e le relazioni presenti
nella libreria degli strumenti condivisi.
Il risultato è che in questa fase della seduta di modellazione si sono potuti
riscontrare diversi modelli del processo in oggetto nel caso Alfa. M2, uno dei due
esperti di dominio, ha disegnato un modello del Target Setting utilizzando il profilo
IDEF; il facilitatore ha disegnato un modello dello stesso processo utilizzando il
profilo ITM (Information Technology Management).

10
Fig.4 I diversi modelli dello stesso processo sviluppati su ogni terminale

M2 presenta la notazione IDEF (Integrated Definition Method), basata su riquadri

che rappresentano l’attività. Fra le diverse attività vi sono delle frecce che
rappresentano visualmente le relazioni di ingresso, uscita, i vincoli e la logica
dell’attività.

Fig.5 M2 disegna la notazione IDEF alla lavagna

11
H4, il facilitatore, chiede allora ai rappresentanti dell’azienda industriale G1 e M2
come tradurrebbero nella notazione da loro usata una relazione di ingresso di dati
di questo tipo: da un processo (‘revisione generale del prodotto’) a un documento
(Pre-SoR, Statement of Requirement – vedi fig. 6 a sinistra ):
Target Setting
OEM (MKT, AD, TD) OEM (PU)

Product Briefing PRP information Lean SOR Sourcing

Revision of general product Pre-SOR

objectives information: CCP definition and
Brand Values,
Customer Mission,
Vehicle Areas
of execellence
Supplier (1st Tier)
Product Mission, Market,
Competitors analysis,
Economical Analysis Feedback
Areas of excellence and VOC, SK PRP Definition of VTS
On new vehicle: objectives
Overall dimensions,
Motorization,
product innovation, VOC…
Offers
Negative

Legenda: Simulation
MKT= Marketing results
AD= Advanced Development
TD = Technical Department
PU= Purchasing
PD vehicle
PRP= Plan Range Product Positive
Objectives 1st SOR
SOR= Statement of definition
Requirements
VTS= Vehicle Technical
Specifications Suppliers
CCP= Customer Car Profile feedback 2nd SOR
VOC= Voice of Customer Integration

Fig.6 Il modello MERISE usato come punto di partenza

H4: [riferendosi al primo elemento della lista degli ingressi] ‘brand value’ è un
input?
M2: No. I meccanismi sono ad esempio i sistemi IT. ‘Brand value’ è più…
G1: [interviene] ‘Brand value’ è informazione dal marketing
M2: [riferendosi al secondo elemento della lista degli ingressi] ‘Customer mission’ è
sicuramente un input.
G1: Io penso che ogni elemento della lista venga da diversi dipartimenti…
H4: ‘Market analysis’ è un input o un vincolo?
M2: E’ più un input… Tutti sono input… Certo, i regolamenti sono input ma sono
anche vincoli. Anche il prezzo è un input ma è anche un vincolo…

G1 a questo punto suggerisce di cominciare a modellare da un altro elemento di

processo (il documento pre-SOR) poiché modellare la lista degli ingressi
provenienti da ‘revisione generale del prodotto’ (vedi fig.6 colonna di sinistra)
richiederebbe troppo tempo.

12
G1: Possiamo anche cominciare a modellare dieci anni fa! Possiamo anche
estendere la complessità di questa attività ma non abbiamo abbastanza spazio nel
disco per farlo…
M2: Siamo sicuri che questi [la lista dei dati in ingresso da ‘revisione generale del
prodotto’] non siano risultati?
G1: Sì, sono risultati di altri processi…

Il dialogo riportato fra i due esperti dei processi di produzione automobilistica (M2
e G1) e il facilitatore di progetto (H4) dimostra che il formato di rappresentazione
modifica la percezione dell’oggetto rappresentato, e che le sue sue traduzioni in
diversi formati rappresentazionali rendono di nuovo negoziabili pratiche altrimenti
date per scontate. Mentre il flusso dei documenti procedurali rappresentato
attraverso il metodo Merise costituisce nel caso Alfa un artefatto per coordinare la
produzione, rintracciando la posizione di importanti documenti che contengono le
modalità di svolgimento dei compiti e gli aggiornamenti sullo stato della loro
realizzazione, la sua rappresentazione attraverso una diversa notazione costituisce
un momento di contesa fra diverse convenzioni rappresentazionali all’interno della
comunità stessa dei membri che quotidianamente mettono in atto tali processi.
Quando, come in questo caso, si trattano gli albori della carriera interazionale di un
artefatto e delle negoziazioni fra i suoi attori, emerge l’evidenza che la pratica di
rendere visibile l’organizzazione del lavoro non è un privilegio dell’ingegneria dei
sistemi o della progettazione professionale, ma è un’attività che coinvolge coloro
che con le proprie competenze organizzano le attività collaborative e mettono in
atto la propria organizzazione sociale. Più in generale, il caso Alfa dimostra la
frammentazione delle pratiche locali di visualizzazione d’impresa.

7. La ambiguità costitutiva delle ‘scene visuali d’impresa’ fra artefatto

rappresentazionale e artefatto coordinativo

Facendo riferimento alla definizione garfinkeliana di ‘vaghezza specifica’ di ogni

fomulazione al di fuori della sua elaborazione pratica in situ (Garfinkel, 1996 cit. in
Suchman et al., 2002), abbiamo discusso l’ambiguità costitutiva delle ‘scene visuali
d’impresa’. Esse sono simultaneamente: (i) strumenti di supporto alla decisione in
contesti organizzativi complessi attraverso la produzione di mappe dinamiche e (ii)
modelli d’impresa che possono generare un’infinità di programmi per gestire tanto

13
il lavoro cooperativo quanto l’automazione dei processi. Le ‘scene visuali d’impresa’
sono boundary object (Star, 1989; Star and Griesemer, 1989) che si situano fra
controllo e contingenza e servono come media di negoziazione e traduzione fra le
reciproche aspettative e i requisiti non solo di architetti d’impresa da una parte ed
esperti di dominio dall’altra, ma anche tra funzioni di management (controllo e
imposizione di un ordine) e funzioni operative (supporto al lavoro cooperativo).
Abbiamo inoltre argomentato che, per poter meglio descrivere la “vaghezza
specifica” dei sistemi di modellazione, è importante distinguere tra artefatto
rappresentazionale e artefatto coordinativo (Schmidt & Wagner, 2004), tra
espressività e monotonia, tra funzione pittorico-rappresentazionale e imposizione di
ordine, tra visualizzazione ed eseguibilità. Nel caso del progetto che costituisce il
contesto dell’etnografia da noi svolta, ciò è particolarmente evidente in uno dei tre
casi industriali: il caso di una piccola impresa manifatturiera dell’Europa orientale
che opera nel campo dell’elettronica, producendo micro-circuiti integrati (caso
Beta). Trattandosi di una piccola impresa, i rappresentanti di Beta non sono tanto
interessati alla possibilità di visualizzare mappe dinamiche di organizzazioni
complesse, quanto piuttosto a usare il modello come artefatto coordinativo: che il
modello ‘faccia delle cose’ a livello del supporto al lavoro cooperativo e
dell’automazione dei processi. Inoltre, in questo caso, la differenza di competenze
rispetto alla modellazione fra architetti d’impresa che rappresentano la componente
tecnologica del progetto ed esperti del dominio che rappresentano l’azienda,
soprattutto all’inizio del progetto, è molto più ampia che nel caso di Alfa. I membri
dell’azienda Beta sono esperti ingegneri elettronici ma non hanno mai sentito
parlare prima di modellazione d’impresa. Fra i partecipanti alla seduta, Ad1 è il
manager di Beta e Jo3 è l’architetto che rappresenta la componente tecnologica.
Ecco uno stralcio del loro dialogo durante la seduta di modellazione:

Ad1: Se mi permetti, ho una domanda… Sono assolutamente convinto della

ricchezza di Metis [il software usato] per quanto riguarda la creazione di vari
oggetti… con tutti questi template possiamo creare cose veramente complesse…
ma la domanda immediata è: quali operazioni possiamo fare con questi oggetti? […]
C’è la possibilità di fare verifiche di coerenza? Il sistema è capace di dirmi che
qualcosa sembra non essere corretto nel mio modello? È una domanda sugli aspetti
dinamici… se puoi tornare un po’ su questo punto…

14
Jo3: In generale noi non abbiamo nessuna funzione di simulazione per questo tipo
di dinamiche… Ciò che abbiamo è che ci sono queste regole… Ogni compito
rappresentato nel modello può avere un singolo responsabile delle verifiche…
Questi sono vincoli imposti… Questo tipo di oggetti [i ‘compiti’, rappresentati nel
modello come oggetti] non ti permettono di tracciare più di una relazione di questo
tipo… Questa è una parte della risposta. Ma questo è abbastanza statico… E ha a
che fare con quelli che sono i tipi di oggetti consentiti in un modello… Le parti che
ogni oggetto deve avere… e le tipologie di relazioni che possono essere associate ad
un oggetto. Per questo tipo di regole possiamo usare il validatore… E il validatore
finisce per presentare una lista di errori… E poi ciò che puoi fare
fondamentalmente è correggere gli errori.

Anche in questa seduta l’obiettivo è modellare, attraverso il software fornito

dall’architetto d’impresa, la selezione del processo di Beta che poi sarà oggetto della
sperimentazione dell’infrastruttura e dei servizi proposti dal progetto. In questo
caso il processo selezionato è la collaborazione di Beta con un partner che fornisce i
componenti del microprocessore. Alla fine del processo di modellazione, Ad1, il
manager, torna sulla questione:

Ad1: Ora abbiamo catturato il workflow, più o meno sì… Ma riguardo a questo…
Ancora la mia vecchia domanda… Non è per essere maleducato con te… Ma
siamo amici e fra amici possiamo chiedere… Ti aspetti che questo workflow nel
corso del progetto diventerà eseguibile?
Jo3: Bene, io penso che questo sia il prossimo passo. Per i tecnici questo modello è
una specificazione dei requisiti veramente chiara, nel senso che dettaglia molto
chiaramente il tipo di strumenti coinvolti, il tipo di scambi di informazioni fra
imprese, ma non dice niente di come questi scambi avvengano effettivamente…
Ad1: Ma io dicevo… Lo sai cosa intendo… La mia domanda standard al tuo team
di sviluppo. Un giorno noi ci aspetteremmo che sia eseguibile. Può avere il ruolo di
uno strumento di workflow?
Jo3: Sì. Quello che abbiamo sviluppato è una sorta di strumento di esecuzione dei
compiti, che è un pò più flessibile di un workflow nel senso che hai un maggior
controllo umano. E penso che questo sia necessario perchè ci sono molte
organizzazioni… può succedere di rifare uno compito e andare avanti e indietro e le
cose possono succedere in parallelo. Quindi non è la sorta di workflow tradizionale.

15
Ciò che possiamo fare è di rappresentare questi come compiti a cui si può accedere
attraverso un portale web e poi si può usare il portale per coordinare lo status del
lavoro… Così quando siamo nella situazione che un partner di Beta ha completato
ad esempio la modellazione del blocco fisico, lo selezioneranno come completato
nel portale e Beta saprà che è il momento di fare l’integrazione digitale, per
esempio. Così Beta e i fornitori avranno un luogo per la supervisione comune dello
stato del progetto.

Il portale web di cui parla Jo3 può essere generato dal modello disegnato attraverso
l’uso di ‘scene visuali d’impresa’ e corrisponde alla funzione ‘attiva’ del modello
d’impresa. Marcando sul portale web il completamento di un compito, l’utente
modifica il modello, senza necessariamente dovervi accedere. La modifica viene
registrata nel modello d’impresa e visualizzata attraverso una modifica del codice
cromatico dell’oggetto corrispondente al compito completato. Mentre la visione del
portale web è la visione coordinativa dell’artefatto, che ha delle implicazioni dirette
sullo stile del lavoro al terminale degli utenti – ed è la visione sulla quale Ad1 ha
cercato ripetutamente di porre l’attenzione attraverso le sue domande – la visione
ove vengono registrate le modifiche allo stato di esecuzione del compito attraverso
una modifica del codice cromatico dell’oggetto corrispondente è la visione
rappresentazionale, destinata al management.

8. Profonda riconfigurabilità delle ‘scene visuali d’impresa’

Sebbene sia la versione dell’artefatto rappresentazionale (utilizzabile per funzioni di

controllo e di imposizione d’ordine e destinata al management) a costituire la
maggiore ragione del successo commerciale della modellazione d’impresa, è
interessante notare come a livello teorico, nel caso del software, venga a cadere la
distinzione netta fra funzione espressiva e pittorica da una parte, caratteristica
dell’artefatto rappresentazionale, e la funzione di controllo e di imposizione
d’ordine dall’altra, caratteristica dell’artefatto coordinativo (Schmidt & Wagner,
2004, p. 395). Allo stesso modo, nel caso di Alfa, la possibilità di caricare
contemporaneamente diversi profili consente di ampliare la libreria di oggetti e
relazioni disponibili per la modellazione visuale, riconfigurando approcci, metodi e

16
notazioni con diverso grado di specificità che vanno dal generico profilo per la
modellazione d’impresa allo specifico template per la gestione delle tecnologie
dell’informazione, da metodi coperti da brevetto (come l’ Integrated Definition
Method) ad altri corrispondenti a convenzioni consolidate (come il Business
Process Modelling).
Ciò che si vuole sostenere è quindi che, nella traduzione da supporto fisico a
supporto elettronico, l’artefatto software sia una particolare tipologia di “tecnologia
dell’intelletto” in cui le barriere fra ciò che nel contesto fisico sarebbe una pratica
classificatoria discorsiva e ciò che sarebbe un sistema di classificazione inscritto in
artefatti e pubblicamente disponibile (ovvero la differenza tra artefatto
rappresentazionale e artefatto discorsivo) vengono continuamente e profondamente
riconfigurate (Manovich, 2008). La congiunzione è inclusiva. Una volta simulate nel
computer, tecniche rappresentazionali precedentemente non compatibili
cominciano ad essere combinate in modi sempre nuovi (come nel caso di Alfa). In
tal modo, aspettative e requisiti di gruppi sociali contrastanti – quelle del
management da un lato e quelle operative dall’altro – vengono conciliate (come nel
caso di Beta). Infine, la configurabilità dell’artefatto e la partecipazione ad essa da
parte dei diversi gruppi sociali può essere misurata non solo attraverso l’analisi
dell’esito finale (l’interfaccia del software), ma anche attraverso la scomposizione
dei diversi livelli costitutivi del software: il programma e la tipologia di accesso
(licenza) ad esso associata, il modello contenuto, i profili prestabiliti di oggetti e
relazioni per poter disegnare, modificare, leggere il modello (template) e infine il
meta-modello, livello in cui vengono stabilite le regole di utilizzo degli oggetti e
delle relazioni contenute nei profili prestabiliti. Nell’ultimo caso analizzato,
scendiamo di un livello nell’analisi del software: dai modelli passeremo allo studio
dei meta-modelli. Il caso in cui la struttura del software delle scene visuali d’impresa
diviene più evidente è quello della terza azienda, un’impresa manifatturiera
automobilistica multinazionale. In questo pilota industriale, sono state mobilitate un
insieme di risorse senza precedenti rispetto agli altri casi presentati. Gli architetti
d’impresa hanno partecipato alle sedute di modellazione in gruppo (tre
componenti), mentre nei casi Alfa e Beta ad ogni seduta era presente un singolo
architetto d’impresa. Inoltre, il coinvolgimento dell’azienda è stato più ampio che
nei casi precedenti per numero di esperti di dominio coinvolti (gli esperti
partecipanti al progetto erano una decina, contro i due o tre degli altri casi) e perché
come manager del caso d’uso partecipava il presidente di uno dei dipartimenti

17
aziendali. Inoltre, per supportare l’adozione dell’approccio alla modellazione delle
scene visuali d’impresa, l’impresa automobilistica veniva sostenuta da un gruppo di
facilitatori provenienti dall’ambiente accademico.
La struttura del software utilizzato dagli architetti d’impresa nel terzo progetto è
costituita da una parte dalla versione dell’applicativo disponibile e dal tipo di licenza
predisposto, dall’altro da un file di set up, contenente i template e i metamodelli.

Fig. 7 La struttura del software

L’aspetto più rilevante del caso di questa terza azienda, Gamma, è che la selezione
di processo sulla quale si è poi svolta la sperimentazione dei servizi e
dell’infrastruttura del progetto non è stata modellata attraverso uno dei profili
preconfezionati già disponibili nell’applicativo software, ma attraverso lo sviluppo
di un nuovo meta-modello. I meta-modelli sono archivi di tipologie di oggetti e
tipologie di relazioni. Al livello del modello del metamodello, è possibile modificare
le proprietà degli oggetti e delle relazioni che poi costituiranno il ‘linguaggio’ di
modellazione, cioè il profilo preconfezionato di oggetti e relazioni. Ad esempio,
può essere modificato l’ “indicatore di performance di un oggetto”, valore attribuito
ad un oggetto che, assommato ai valori degli oggetti ad esso connessi, va a
costituire l’indice totale di performance di un processo.
Una volta modificato tale indicatore, e a seconda dell’importanza che si vuole dare
ad un determinato oggetto, i calcoli che verranno fatti sui processi all’interno
modello sortiranno risultati diversi. In Gamma il meta-modello creato dagli
18
architetti d’impresa su esigenza degli esperti di dominio, supportati dai facilitatori
accademici, è stato chiamato “Collaborative Product and Process Design”. Dato
che nel caso di Gamma la selezione del processo interessata dal progetto è quella
dell’intero processo di produzione di componenti, il modello ha sedici contenitori e
rappresenta la situazione corrente dei processi produttivi in Gamma. Questo
approccio corrisponde non alla proposta degli architetti d’impresa (che infatti
hanno commentato questa scelta dicendo: “Io non posso pensare in sedici
dimensioni”) ma alla volontà degli esperti di dominio e del loro manager. Il caso di
Gamma e della partecipazione dai parte dei membri di Gamma alla ri-progettazione
di un livello più profondo del software, quello del meta-modello, illustra il fatto che
la ri-configurabilità delle pratiche di classificazione necessita di essere specificata
non solo nella sua logica inclusiva, come nel caso di Alfa, in cui lo stesso software
dispone di notazioni corrispondenti a diversi approcci alla modellazione, che
possono essere usati congiuntamente. La ri-configurabilità che caratterizza le
pratiche di modellazione supportate da software è profonda non solo in senso
teorico, cioé perché riconcilia le funzioni che il letteratura vengono attribuita ad un
artefatto rappresentazionale con quelle che vengono attribuite ad un artefatto
coordinativo, come evidente nel dialogo fra l’architetto d’impresa e il manager di
Beta. Nel caso del software, la ri-configurabilità é profonda anche in senso fisico: il
software é fatto a strati. La pratica classificatoria inscritta nell’artefatto può essere
quindi più o meno intensa (in termini temporali – durevole - e in termini fisici –
rigida-) a seconda della profondità in cui essa ha luogo. Se si interviene al livello
dell’interfaccia d’uso (il portale web utilizzato dal lavoratore per portare a termine
un compito) la ri-configurazione può essere considerata un intervento ‘cosmetico’
senza nessuna conseguenza al livello del modello sottostante. Se una pratica
classificatoria si inscrive al livello del modello sottostante, essa può prendere la
forma della giustapposizione di profili di oggetti e relazioni pre-confezionati e
rimanere una soluzione locale ‘ad-hoc’. Se la ri-configurazione avviene al livello del
meta-modello, come in Gamma, essa genera invece un profilo che non esisteva
prima. Tale profilo entra a fare parte dei profili pre-confezionati che vengono
associati al software, può essere utilizzato al difuori del contesto in cui è nato e
avere delle implicazioni che si diffondono in altri contesti d’uso.

19
9. Conclusioni

Il caso di Gamma rappresenta la necessità di descrivere al meglio le presupposizioni

ideologiche tacite e i valori messi in atto nelle pratiche di classificazione. A tal fine,
si sposta il livello dell’analisi situata delle tecnologie di “mutua visibilità” ad un
grado di dettaglio tale da poter discriminare le ‘regole’ che governano le varie
pratiche classificatorie distinguendo i contesti materiali in cui queste ultime
vengono inscritte: pratiche conversazionali, artefatti fisici o software. Ognuno dei
contesti materiali elencati ha regole particolari a cui le pratiche classificatorie
cercano di rispondere. Abbiamo riscontrato che le pratiche classificatorie inscritte
nel software hanno: una dinamica inclusiva, una molteplicità di livelli, un’ambiguità
costitutiva fra funzione rappresentazionale e funzione coordinativa. L’etnografia
delle pratiche di modellazione ha permesso di declinare queste considerazioni
all’interno del dominio di una specifica tecnologia di “mutua visibilità”, quella delle
‘scene visuali d’impresa’. Focalizzandosi sulla particolare condizione di svolgimento
del lavoro ingegneristico supportato da software all’interno di sedute di
modellazione con vari soggetti interessati, lo studio ha potuto descrivere, con
l’evidenza empirica proveniente dalla audio e video-registrazione delle riunioni che
gli architetti d’impresa hanno avuto con i rappresentanti di tre imprese
manifatturiere, la profonda ri-configurabilità (Manovich, 2008) di: (i) diversi
approcci regionali alla modellazione d’impresa, (ii) caratteristiche appartenenti alla
descrizione di un artefatto rappresentazionale e caratteristiche appartenenti a quella
di un artefatto coordinativo e (iii) dinamiche fra controllo e configurabilità secondo
i diversi livelli costitutivi del software per la modellazione d’impresa (licenze,
interfaccia, template, meta-modello). Ciò che è stato rilevato consituisce
un’evidenza della necessità di riarticolare l’approccio situato alle “tecnologie di
mutua visibilità” sui luoghi di lavoro, discriminando le condizioni di iscrivibilità
delle pratiche classificatorie (e delle forme di dominazione o di imposizione loro
proprie) secondo i diversi contesti materiali. In linea con il programma di ricerca di
una sociologia della tecnologia dell’informazione (Sassen, 2002), abbiamo voluto
rendere evidente, nel micro-contesto dell’osservazione delle pratiche di
modellazione, l’inadeguatezza dell’antagonismo fra alcune categorie analitiche
sviluppate per lo spazio non-digitale quando si cerca di utilizzarle per interpretare lo
spazio digitale.

20
Bibliografia

Alder, K. (1998). Making things the same: Representation, tolerance and the end of
the Ancient Regime in France. Social Studies of Science, 28, 499-545.
Curtis, B., Kellner, M.I., Over, J., (1992). Process Modelling, Communications of
the ACM, 1992, 35, 75-90.
Garfinkel H. (1996).Ethnomethodology’s Program, Social Psychology Quarterly,
vol. 59, n. 1, pp. 5-21.
Gerson, E. M. and Star S. L.(1986). Analyzing due process in the workplace. ACM
Transactions on Office Information Systems, vol. 4, no. 3, pp. 257–270.
Goodwin C. (1994). Professional Vision. American Anthropologist, 96, 606-633.
Grint, K. and S. Woolgar (1997) The Machine At Work. Cambridge: Polity.
Henderson, K. (1991). Flexible sketches and inflexible data bases: Visual
cummunication, conscription devices, and boundary objects in design engineering.
Science, Technology & Human Values, 16, 448-473.
Joerges B. (1999). Do Politics Have Artefacts? in Social Studies of Science 29: 411-
31.
Latour, B. (1990). Drawing things together. In M.Lynch & S.Woolgar (Eds.),
Representation in scientific practice (pp.19-68). Cambridge, MA: MIT Press.
Latour, B. (1988). Mixing Humans with Non-Humans: Sociology of a Door-Closer.
Social Problems. 35, pp.298-310.
Latour B. (1986). Visualization and Cognition: thinking with eyes and hands.
Knowledge and Society 6: 1-40.
Lynch, M. (1990). The externalized retina: Selection and mathematization in the
visual documentation of objects in the life sciences. In M.Lynch & S.Woolgar
(Eds.), Representation in scientific practice (pp.153-186). Cambridge, MA: MIT
Press.
Lillehagen F., (2003). The foundations of AKM technology in Jardim-Goncalves R.
et al. (eds), “CE: The Vision for the Future Generation in Research and
Applications”, Swets & Zeitlinger, Lisse.
Manovich, L. (2008) Software Takes Command. Creative Commons. Version
11/20/2008. Scaricabile dal sito web all’indirizzo:
http://lab.softwarestudies.com/2008/11/softbook.html

21
Neyland, D. and Woolgar S. (2002). Accountability in action? The case of a
database purchasing decision system. British Journal of Sociology. 53: 259-274.
Sassen, S. (2002). Towards a Sociology of Information Technology. Current
Sociology, 50(3). 365-388.
Schmidt K., Wagner I. (2004). Ordering Systems: Coordinative Practices and
Artifacts in Architectural Design and Planning. Computer Supported Cooperative
Work, 13: 349-408.
Star, S. L. (1989). The Structure of Ill-structured Solutions: Boundary Objects and
Heterogeneous Distributed Problem Solving. In L. Gasser and M. Huhns (eds):
Distributed
Artificial Intelligence, vol. 2. London: Pitman, pp. 37–54.
Star, S. L. and Griesemer J. R. (1989). Institutional Ecology, ‘‘translations’’ and
Boundary Objects: Amateurs and professionals in Berkeley’s Museum of Vertebrate
Zoology, 1907–39. Social Studies of Science, vol. 19, pp. 387–420.
Suchman, L., Trigg R., Blomberg J. (2002). Working artefacts: ethnomethods of the
prototype. British Journal of Sociology, 53 (2): 163-179.
Suchman, L. (1993). Technologies of accountability of lzards and aeroplanes. In G.
Button (Ed.), Technology in working order – studies of work, interaction, and
technology (pp.113-126). New York. Routledge.
Suchman, L. (1995). Making work visible. Communication of the ACM, 38(9), 56-
64.
Suchman, Lucy A. (1987). Plans and Situated Actions: The Problem of Human–
Machine
Communication. Cambridge: Cambridge University Press.
Ueno, N. (2000). Ecologies of Inscription: Technologies of Making the Social
Organization of Work and Mass Production of Machine Parts Visible in
Collaborative Activity. Mind, Culture and Activity, 7(1&2), 59-80.
Winner L. (1980). Do Artifact Have Politics? in Daedalus 109: 121-136.
Zachman, J.A. (1987). “A Framework for Information Systems Architecture,” IBM
Systems Journal, vol. 26, no. 3: 276-292.

22