competenze, modularità ed integrazione delle

Open Innovation nel settore auto:
competenze, modularità, ed integrazione delle
performance
Francesco Zirpoli
Università di Salerno, Facoltà di Ingegneria, Dipartimento di Ingegneria Meccanica
I-84084 Fisciano (SA), Italy, Tel. 0039-089964042, Fax 0039-089964037,
[email protected]
1. Introduzione
L’innovazione è sempre più il risultato congiunto dell’attività di ricerca e sviluppo
realizzata da imprese che appartengono a business ecosystem (Iansiti e Levien, 2004).
L’idea di fondo che sta emergendo con forza negli studi di management è che le
imprese non possano perseguire strategie di sviluppo dell’innovazione facendo
affidamento esclusivamente sulle proprie risorse e competenze ma devono aprirsi alla
possibilità di utilizzare a proprio vantaggio il contributo di soggetti sui quali l’azienda
non ha un controllo di tipo gerarchico (equity). Da qui la proposizione di nuovi modelli
di business che si fondano sull’idea di “open innovation” (Chesbrough, 2003).
In realtà il dibattito sulla definizione dei confini dell’impresa e sul ruolo dei soggetti
esterni nei processi di innovazione non è nuovo (si veda ad esempio von Hippel, 1988 e
Womack et. al., 1990). Tuttavia, gli elementi di novità attengono alla circostanza che le
imprese hanno iniziato a metabolizzare il cambio di scenario e sono impegnate in un
processo di ristrutturazione complessa sia dell’organizzazione interna del processo di
sviluppo prodotto sia della architettura della propria value chain (Jacobides et al.,
2006).
Tale processo si rispecchia anche nella letteratura che è passata da una rappresentazione
entusiastica ed, a volte, edulcorata delle prerogative positive dei processi di outsourcing
di alcune delle attività di ricerca e sviluppo, ad una loro analisi critica. Questo lavoro si
inquadra nella necessità di analizzare con maggiore profondità il tema dell’outsourcing
di innovazione e si pone due finalità. In primo luogo si cercherà di rappresentare in
modo dettagliato le implicazioni che l’outsourcing di attività di progettazione di sistemi
e componenti ha sulla capacità dell’impresa di realizzare con efficacia l’integrazione di
sistemi (Prencipe et al., 2003). In secondo luogo si offrirà un’analisi critica delle
variabili più rilevanti ai fini del successo nell’integrazione di sistema.
Il lavoro si pone nel solco della letteratura che si è occupata dell’innovazione nel
contesto di prodotti complessi (Hobday e Rush, 2000). Di conseguenza si è scelto di
condurre l’analisi empirica su cui si basa il lavoro, nel settore dell’auto e di
circoscriverla al coinvolgimento nei processi di innovazione dei fornitori di primo
livello di componenti e sistemi complessi. Il taglio del lavoro è volto a mettere in luce
le modalità organizzative con le quali le imprese implementano nella pratica le strategie
di integrazione di sistema ed i problemi che gli OEM
(Original Equipment
Manufacturer) si trovano ad affrontare nel perseguire una strategia di outsourcing di
progettazione.
In quanto segue si presenta l’analisi della letteratura e le domande di ricerca. Ad una
breve descrizione della metodologia seguirà la presentazione del caso e la discussione.
2
2. Analisi della letteratura
2.1 Il concetto di system integration
L’attenzione accademica al fenomeno della network innovation in un’ottica connessa ai
processi di apprendimento organizzativo nasce intorno alla metà degli anni Novanta.
L’articolo di Powell et al. (1996) ed il libro di Chesbrough (2003) sulla “Open
innovation”1 sono risultati particolarmente influenti e catalizzatori di diverse comunità
di ricercatori interessate all’innovazione. In questo lavoro si focalizza l’attenzione sulla
prospettiva teorica che ha avuto ad oggetto la comprensione, in ottica manageriale, di
come le imprese gestiscano l’innovazione in network. In questo filone di ricerca i
concetti di modularità e integrazione di sistema giocano un ruolo centrale.
Il concetto di modularità2 applicato all’innovazione di prodotto introduce un diverso
principio di divisione del lavoro che sottende il coordinamento tra OEM e fornitori: non
è né l’impresa a condurre tutte le fasi di progettazione, e quindi a controllarle, né il
mercato. Piuttosto una volta standardizzate le interfacce tra componente e sottosistema,
la loro progettazione e industrializzazione può essere condotta in modo relativamente
indipendente dalle diverse unità organizzative. L’OEM gestisce i fornitori
principalmente attraverso il controllo delle interfacce standard. Questo accade anche
all’interno dell’impresa (Sanchez e Mahoney, 1996) dove il coordinamento dei diversi
attori (R&D dell’OEM, fornitori, e servizi d’ingegneria) può essere ottenuto attraverso
la progettazione delle interfacce e la specifica delle performance, e non più
esclusivamente attraverso la gerarchia. La principale implicazione del concetto di
modularità è legata al fatto che i fornitori possono lavorare con più clienti utilizzando le
stesse tecnologie di prodotto e di processo; inoltre, la definizione di interfacce standard
e delle caratteristiche prezzo/performance introducono un processo di selezione dei
fornitori sostanzialmente basato sul mercato (Sturgeon, 2002).
1
2
Nel corso del paper i termini network innovation ed open innovation saranno utilizzati come sinonimi.
Ulrich 1995; Sanchez & Mahoney, 1996; Baldwin & Clark, 1997; Sanchez, 1995, Schilling, 2000.
3
Il concetto di system integrator ed i contributi scientifici sul tema nascono dalla
estensione della letteratura sulla network innovation e sulla modularità.
L’integrazione di sistema può essere considerata come il paradigma emergente per la
gestione della network innovation (Brusoni e Prencipe, 2001, Mikkola, 2006).
I systems integrator sono imprese che “fondono componenti ad alto contenuto
tecnologico, sottosistemi e software, competenze e capacità, manager e ingeneri per
realizzare un prodotto competitivo” (Hobday et al., 2005). Questo richiede la
progettazione e l’integrazione dei sistemi oltre alla gestione di network di fornitori di
componenti o sottosistemi (Hobday et al., 2005). In quanto competenza specifica,
l’integrazione di sistema permette all’OEM leader della supply chain lo sviluppo di
nuovi prodotti, il coordinamento del network di fornitura, e la continua ottimizzazione
del suo posizionamento nell’ambito della catena del valore del settore (Hobday et al.,
2005). Resta ancora da approfondire quali siano le competenze necessarie e come le
imprese possano acquisire tali competenze per potersi definire integratori di sistema.
Una possibile risposta a tale interrogativo è stata data da Brusoni et al. (2001) i quali
suggeriscono una prospettiva strategica per cui le imprese devono sviluppare una base
di conoscenza più ampia di quella strettamente legata alla realizzazione dei beni o
servizi che producono (per esempio estesa alla conoscenza delle tecnologie che ne sono
alla base). Gli autori segnalano, ad esempio, come le imprese che realizzano sistemi di
controllo per aerei, sono attivamente coinvolte non solo nello sviluppo dei sistemi ma
anche nella R&D e brevettazione delle tecnologie di base di tali sistemi (Brusoni et al.,
2002; per casi analoghi si veda anche Nesta e Dibiaggio, 2003). Disporre di una base di
conoscenza più ampia di quella strettamente necessaria consente di far fronte ad
eventuali asincronie nell’evoluzione delle tecnologie che sono alla base del prodotto e
ad imprevedibili interdipendenze tra i sistemi che compongono il prodotto stesso; il
verificarsi di tali circostanze porta nella direzione di soluzioni organizzative che sono
4
praticabili solo se le aziende avranno sviluppato opportunamente la loro base di
conoscenza (Brusoni et al., 2001)3.
Anche nel lavoro di Takeishi (2001; 2002) si trovano indicazioni su come i system
integrator riescono ad ottimizzare la capacità d’integrazione in presenza di una
strategia di outsourcing. L’autore evidenzia la differenza tra conoscenza specifica
relativa ai componenti e conoscenza architetturale (Takeishi, 2002). La novità
tecnologica del progetto di sviluppo del componente costituisce il criterio chiave di
valutazione del livello di conoscenza necessario: per progetti di media o bassa
innovazione tecnologica è sufficiente che il costruttore di autoveicoli abbia elevati
livelli di conoscenza architetturale (come coordinare i diversi componenti nel veicolo)
rispetto alla conoscenza specifica dei componenti, propria dei fornitori. Al contrario,
quando il progetto è caratterizzato dall’esigenza di integrare componenti la cui
tecnologia è nuova, è opportuno che il costruttore di autoveicoli abbia elevati livelli di
conoscenza specifica dei componenti per supportare il fornitore nella soluzione di
problemi di ingegnerizzazione. Nei progetti innovativi, quindi, la scomposizione delle
conoscenze richiede in ogni caso alcune sovrapposizioni tra OEM e fornitori piuttosto
che una chiara e delineata individuazione dei confini (Takeishi, 2002).
In entrambi i casi l’idea è che la capacità di integrazione di sistema (per la quale la
conoscenza architetturale gioca un ruolo importante) è una delle priorità per una
gestione dell’innovazione in network che possa dirsi di successo. Di conseguenza per
gestire la network innovation è necessario coltivare e accrescere la capacità di integrare
i sistemi.
2.2 I problemi connessi con la system integration: il ruolo della conoscenza
La letteratura, tuttavia, ha messo in evidenza anche i rischi connessi ad una strategia
che faccia leva sulla system integration, ovvero che si manifesti con una rilevante
esternalizzazione delle attività di progettazione nel processo d’innovazione.
3
Questo sembra rispondere ai problemi sollevati da Fine and Whitney (1996) e Fine (1998) che
sottolineano la differenza tra dipendenza dalla capacità (produttiva) e dipendenza dalle conoscenze del
fornitore.
5
Come Prencipe spiega, all’origine dell’idea di system integrator, c’è il concetto di
singola impresa come punto nevralgico e centro strategico della catena del valore
(2003): il system integrator è inquadrato come un’impresa la cui finalità prioritaria è
quella di integrare conoscenza (Grant, 1996). In questa ottica, il concetto suggerito da
Henderson e Cockburn (1994) di “capacità di integrazione” è da considerarsi un punto
chiave dell’attività dell’OEM/system integrator4. Prencipe (2004: 1) sottolinea anche
come da un punto di vista competitivo l’integrazione di sistema è più appropriatamente
compresa come integrazione della conoscenza.
Non è casuale, quindi, che il ruolo della conoscenza e dell’integrazione di conoscenza
rappresenti il filo conduttore che attraversa la letteratura che mette in luce gli aspetti
critici legati alla forte esternalizzazione delle attività di progettazione.
In quanto segue si passano in rassegna i principali problemi connessi all’integrazione di
sistema (conoscenza), così come evidenziati nella letteratura.
Rischio di svuotamento delle conoscenze (“hollowing out”). La letteratura mostra come
nel caso estremo di imprese che abbiano puntato esclusivamente sulla conoscenza
architetturale ed esternalizzato completamente la conoscenza specifica dei componenti5,
queste siano incorse in problemi notevoli. Tra questi i più evidenti sono: difficoltà a
fornire le specifiche e conseguentemente valutare i componenti, ad identificare le
offerte più qualificate, a valutarle, a supportare i fornitori dal punto di vista tecnico ed
operativo, a migliorare il componente offerto o, infine, ad essere in grado di produrlo
in-house (Fine e Whitney 1996). In definitiva tutto questo comporta un aggravio delle
attività di coordinamento e gestione dei fornitori. Questa considerazione è un segnale
per l’OEM dell’importanza di detenere un certo livello di conoscenza specifica sui
4
La capacità di integrazione è intesa come la capacità di accedere a nuova conoscenza dall’esterno dei
confini aziendali e la capacità di integrare la conoscenza in modo flessibile entro l’organizzazione
(Henderson e Cockburn, 1994).
5
Un caso di questo tipo è tuttavia raro nella realtà. Lo studio condotto da Takeishi (2001) riporta i
risultati di una survey di 45 progetti di sviluppo in 9 imprese giapponesi di fornitura. Egli ha investigato
il loro livello di conoscenza architetturale e specifica dei componenti rispetto a quello all’OEM. I risultati
suggeriscono che i costruttori di autoveicoli si erano concentrati sulla conoscenza architetturale mentre i
fornitori sulla conoscenza specifica dei componenti.
6
componenti allorquando si desidera mantenere e sviluppare competenze in termini di
integrazione di sistema.
La trappola della modularità (“modularity trap”). Accanto al problema dello
svuotamento delle conoscenze si verifica anche un problema di tipo dinamico.
Chesbrough e Kusunoki (2001) descrivono come possa nascere un potenziale
disallineamento tra l’insieme delle core competence di un’impresa e quelle richieste
dalle dinamiche evolutive del settore.
Se è vero che, al fine di sfruttarne in pieno i benefici, le architetture modulari portano
ad organizzazioni decentrate (Sanchez e Mahoney, 1996), Chesbrough e Kusunoki
(2001) suggeriscono che l’implementazione di questa seconda possibilità comporta il
rischio di cadere nella trappola della modularità: le imprese che hanno avuto successo
attraverso un’organizzazione decentralizzata (ossia basata sulla modularità), continuano
ad aver fiducia in questo approccio anche quando si trovano di fronte a problemi
connessi con tecnologie integrali (Chesbrough e Kusunoki, 2001). In altre parole, nel
caso di modifiche sostanziali nell’architettura dominante del prodotto, le imprese si
trovano nella condizione di non disporre delle competenze per comprendere e gestire le
interdipendenze necessarie allo sviluppo della tecnologia: non sono in grado di
specificare ai fornitori necessità e richieste in modo adeguato (Chesbrough e Kusunoki,
2001). La conseguenza sembra essere che l’architettura integrale di prodotto possa
essere più utilmente associata ad un’organizzazione di tipo centralizzato (che controlla
l’intero range di competenze legate alle specifiche del prodotto e alla sua architettura).
Data la natura dinamica delle industrie e delle architetture dominanti, la valutazione di
quali competenze siano da ritenersi core va costantemente valutata.
Limiti legati ad una focalizzazione spinta sulla conoscenza architetturale. L’idea di
focalizzarsi su un numero ridotto di core competence, e di massimizzare i benefici di
esternalizzazione di quelle attività che non minano le core competence stesse, è
sicuramente allettante, soprattutto in un ottica di riduzione dei costi ed aumento della
7
flessibilità strategica. Con riferimento all’innovazione in network, un esempio di questo
approccio è rappresentato dal tentativo di esternalizzare lo sviluppo di tutti i moduli e
componenti nonché la produzione, mantenendo solo competenze in termini di
integrazione di sistema (la Smart è un esempio di tale strategia). Tuttavia, ci sono dei
limiti relativamente a quanto spinta possa essere la focalizzazione sulle competenze
architetturali: per essere in grado di integrare componenti e sottosistemi, è necessaria
una conoscenza specifica del componente (Lincoln et al. 1998).
Altre ricerche, nello stesso filone, hanno evidenziato che le imprese dovrebbero
mantenere un margine di sicurezza acquisendo e mantenendo conoscenza specifica sui
componenti (Takeishi, 2001; 2002; Brusoni et al., 2001). Resta da approfondire quale
tipo di conoscenza sia necessaria e il livello di approfondimento.
3. Metodologia
Alla luce della letteratura citata appare evidente che se il quadro strategico entro cui gli
OEM si muovono (Iansiti e Levien, 2004, Chesborough, 2003) è abbastanza ben
delineato, il complesso delle competenze che essi devono sviluppare ed il set di
strumenti organizzativi ad esse connesse è ancora poco chiaro. Il lavoro contribuisce a
colmare questo gap. Benché la presentazione dei risultati empirici della ricerca parte
dalla descrizione dei trend strategici che l’OEM sotto osservazione ha seguito nei
processi di outsourcing di progettazione, il focus sarà sui problemi che l’OEM ha
incontrato nell’implementazione di tale strategia.
Oggetto della ricerca è il settore automotive. Esso costituisce un caso interessante per
studiare l’organizzazione dell’integrazione di sistemi, l’evoluzione della divisione del
lavoro innovativo ed il ruolo della conoscenza in questi processi. L’OEM sul quale ci si
è focalizzato, infatti, costituisce un esempio di impresa integrata verticalmente che, ad
un certo punto della sua evoluzione spinge verso una strategia di esternalizzazione per
8
ritornare in seguito ad una strategia di in-sourcing6. Questi cambiamenti hanno coperto
un arco temporale di 10-15 anni.
Indipendentemente dalle specificità del caso, il settore auto risulta un interessante
oggetto di studio data la sua complessità in termini di tecnologie ed attori coinvolti nel
processo di innovazione. I dati resi noti da Maxton e Wormald (2004), ad esempio,
segnalano che nel 2010 ben il 40% del valore di un nuovo veicolo sarà costituito da
componenti elettronici o ad essi interconnessi, a dispetto di un 22% nel 2000 e di un
10% nel 1999.
Da una iniziale focalizzazione sulla meccanica, quindi, il settore automotive è oggi
caratterizzato dalla convergenza di tutte le moderne tecnologie: dall’ICT,
all’elettronica, ai nuovi materiali fino alla sperimentazione delle nano-tecnologie.
L’oggetto e la natura della ricerca hanno spinto verso la scelta di un’analisi
longitudinale condotta attraverso lo studio di un case study (Eisenhardt, 1989,
Pettigrew, 1990, Yin, 1994). La ricerca approfondisce sia dal punto di vista dell’OEM
che da quello dei fornitori, la strategia connessa alla network innovation di un
produttore di auto europeo su un periodo di 10 anni. Le interviste, cui si riferisce questo
lavoro, sono state condotte da Gennaio a Luglio del 2006. Nel complesso sono stati
intervistati 32 manager appartenenti a 10 imprese, per un totale di più di 76 ore di
interviste, tutte registrate e trascritte.
Dato il metodo scelto, la definizione del campione è stata “teorica”, ovvero i fornitori
sono non sono stati estratti casualmente dalla popolazione bensì sono stati scelti sulla
base di:
1. rilevanza del supporto alle attività di sviluppo dell’OEM,
2. eterogeneità del loro business (settore), delle tecnologie utilizzate, delle
dimensioni, della proprietà e della nazionalità,
6
In questo paper si analizza lo sviluppo della strategia di outsourcing delle attività di progettazione
(trascurando l’outsourcing delle attività di produzione).
9
3. non OEM captive.
La raccolta dei dati è avvenuta utilizzando in primo luogo fonti d’archivio per definire
le caratteristiche del settore e la storia delle imprese selezionate. Il secondo passo è
stato costituito da interviste semi-strutturate con i manager dell’OEM e di 8 dei suoi
fornitori di primo livello (tra i componenti oggetto di sviluppo dei fornitori coinvolti
nella ricerca figurano: guarnizioni e sistema di tenuta, freni, stile ed ingegneria, sistemi
elettronici (ABS, ESP, etc.), sistemi di climatizzazione, interni e sedili, sistemi di
sicurezza) .
Le persone intervistate presso l’OEM nel luglio 2006, sono il Chief Technology Officer,
il manager responsabile per l’integrazione di sistema, e 4 dei 5 vehicle line executives
(cioè gli ingegneri responsabili per lo sviluppo delle vetture piccole (segmento A-B),
medie (segmento C) e grandi (D-E) e per il segmento dei veicoli commerciali). Le
interviste forniscono un quadro abbastanza chiaro e completo della situazione; in
particolare si è avuta anche la possibilità di intervistare le funzioni di staff per la
divisione progettazione ed ingegnerizzazione (risorse umane e controllo) ed i
responsabili per la gestione del portafoglio prodotto (interfaccia con il marketing). In
altre parole le interviste riguardano la maggior parte dei manager che intervengono nel
processo di sviluppo prodotto.
Quanto agli otto fornitori, sono stati coinvolti generalmente l’”account manager”
ovvero il soggetto che partecipa all’offerta di fornitura e gestisce le relazioni
commerciali con l’OEM ed il “project manager”, ossia la persona responsabile per lo
sviluppo tecnico del progetto.
Come è prassi nelle ricerche basate su casi studio, per evitare di perdere l’imparzialità
si è deciso di esplicitare le ipotesi di partenza del lavoro cercando di prescinderne
durante il processo induttivo di analisi (McClosky, 1985). In accordo con Eisenhardt
(1989) sono state adottate tre strategie. La prima prevede la selezione di categorie e
dimensioni al fine di valutare similitudini o differenze tra i gruppi. Il secondo prevede
l’analisi di similitudini e differenze per coppie di casi. In fine i dati sono stati divisi in
10
relazione alle fonti per capire se ognuna di esse supportasse l’evidenza empirica frutto
di una diversa fonte. L’ultimo passo riguarda il confronto tra i risultati trovati e la
letteratura esistente.
Oltre alle limitazioni intrinseche legate alla scelta dei case study (Miles e Huberman,
1994), il campione potrebbe essere parzialmente influenzato dal fatto che sono state
intervistate imprese tutte collocate nello stesso paese. Questo potrebbe costituire un
limite alla generalizzabilità dei risultati su scala globale. In ogni caso la maggior parte
delle imprese del campione sono divisioni locali di imprese multinazionali.
4. I risultati dell’indagine empirica
In questa sezione vengono descritte le scelte connesse alla gestione del processo
d’innovazione dell’OEM, un produttore di autoveicoli europeo. In linea del tutto
generale è possibile rilevare una sostanziale inversione nella strategia adottata: nel
periodo in esame (1987-2006), infatti, seguendo una tendenza del settore, l’OEM da
impresa verticalmente integrata è pervenuta ad una forte esternalizzazione delle attività
di sviluppo in seguito a considerazioni di carattere economico ed organizzativo. La
presa di coscienza della perdita di controllo del processo d’innovazione a seguito di un
critico svuotamento delle conoscenze ha comportato un cambiamento di rotta e ha
spinto un nuovo processo di insourcing. Di seguito verranno descritte nel dettaglio le
principali tappe dell’evoluzione della strategia dell’OEM oggetto del caso ed i
principali inconvenienti in cui è incorso.
4.1 Fase 1: razionalizzazione della base di fornitura (1987-1993)
Intorno agli inizi degli anni Novanta, la base di fornitura era essenzialmente limitata ai
componentisti locali. Per completare la progettazione di veicolo occorrevano circa 3500
disegni tecnici dei quali oltre 3450 venivano realizzati dall’OEM7 che gestiva
direttamente più di 3000 fornitori di primo livello, la maggior parte dei quali molto
7
Si ringrazia il Prof. Giuseppe Volpato per questi dati.
11
piccoli. In questi anni la necessità di razionalizzazione rappresentava una priorità e
molti sforzi vennero profusi nella costituzione di una base di fornitura che fosse
competitiva in termini di qualità e costi di produzione (alla fine degli anni Ottanta e
all’inizio degli anni Novanta)8. Dopo questo processo di razionalizzazione nel 1995,
l’OEM non poteva certamente definirsi impresa integrata: per lo sviluppo di uno dei
suoi modelli di punta era, ad esempio, arrivata ad esternalizzare circa il 72% dello
sviluppo (in termini di costi della produzione dei componenti).
4.2 Fase 2: verso una spinta esternalizzazione della progettazione (1993-2001)
Fino alla metà degli anni Novanta il coinvolgimento dei fornitori nel processo di
sviluppo prodotto dell’OEM era ancora limitato alla sola fase di industrializzazione e
produzione di componenti e sistemi. Con la re-ingegnerizzazione del processo di
sviluppo prodotto, nel 1996, la strategia di outsourcing dell’OEM divenne significativa.
L’OEM decise di spostarsi da una esternalizzazione delle sole attività di produzione
(una pratica già consolidata a quel tempo) a quella della progettazione e
dell’engineering di componenti e sistemi. Allo stesso tempo l’OEM iniziò ad
organizzare il contributo dei fornitori in termini di partnership strategiche per lo
sviluppo di capacità complementari. L’obbiettivo dell’OEM alla fine degli anni
Novanta era di esternalizzare prima interi sistemi di componenti per poi passare ai
moduli pre-assemblati. Questa strategia comportò l’identificazione di due tipi di
fornitori: i sistemisti ed i componentisti9, e condusse ad eccezionali livelli di
outsourcing: all’inizio degli anni Novanta più dell’85% del valore totale dei veicolo
veniva ingegnerizzato dai fornitori. Si può senz’altro affermare che, tra il 1996 e il
8
In particolare negli anni 1990-1992, l’OEM intraprese programmi di crescita guidata per i fornitori che
mostravano potenzialità di miglioramento in termini di qualità e costi del prodotto nonché capacità di
conformarsi agli standard dell’OEM stesso. Inoltre, un supporto gestionale e particolari accordi
contrattuali si resero necessari in cambio di questo piano di miglioramento (Enrietti et al., 2002).
9
In questo contesto un sistema viene definito come l’insieme dei componenti che interagiscono tra loro e
che condividono la stessa funzione (per esempio centralina, strumentazione e computer di bordo). Un
modulo viene definito come l’insieme dei componenti che condividono una prossimità fisica ma diverse
tecnologie (l’OEM ha definito sette moduli come il modulo frontale che include le luci, il paraurti e il
radiatore.
12
2001 l’OEM divenne una delle imprese con il più alto grado di esternalizzazione della
progettazione del settore automotive.
4.3 Fase 3: un nuovo modello verso l’insourcing
Il livello di outsourcing appena descritto aveva comportato la progressiva perdita di
competenze su alcune aree del veicolo tra cui, ad esempio, cruscotto, sospensioni e
sistema di sicurezza. Il management dell’OEM comprese, con un certo ritardo, che
l’outsourcing era stato spinto troppo e che erano necessarie iniziative volte a ristabilire
queste competenze.
Le interviste condotte nel 2006 mostrano come questa strategia sia stata effettivamente
implementata. Essa si è sviluppata in due fasi successive.
Una prima fase ha riguardato l’acquisizione delle competenze dai fornitori: il loro
coinvolgimento nel processo di sviluppo prodotto viene inquadrato nell’obiettivo
esplicito di apprendere know-how e strumenti tecnologici. Questa motivazione, risulta
palesemente diversa dalla mera finalità di essere supportati nel processo di
progettazione di un particolare componente o sistema.
In secondo luogo, l’OEM ha intrapreso una strategia per l’internalizzazione delle
competenze di progettazione che erano state perse assumendo personale altamente
qualificato sulle aree di conoscenza “scoperte”.
4.4 Problemi riscontrati dall’OEM nell’integrazione di sistema
“Quando sono arrivato nel 2005 la situazione era critica sia dal punto di vista delle
competenze tecniche, sia dal punto di vista organizzativo. Le business unit erano fuori
controllo. Attraverso una discutibile strategia di outsourcing, l’impresa aveva
sistematicamente indebolito le sue competenze tecniche. La divisione enginnering
rappresentava un fornitore come gli altri che accidentalmente apparteneva all’impresa.”
(Chief Technology Officer, Luglio 2006)
13
Una delle principali conseguenze della forte esternalizzazione di progettazione fu che
l’OEM aveva perso le competenze tecniche di progettazione di molti sottosistemi del
veicolo. Oltre alla mancanza di risorse umane con competenze tecniche significative
c’era anche un problema di qualità delle competenze delle risorse ancora a disposizione
dell’OEM: non superiori a quelle di ogni altro fornitore di servizi d’ingegneria10.
Negli anni 1993-2001 molti degli ingegneri dell’OEM si ritrovarono prevalentemente
impegnati a coordinare i fornitori e gestire i progetti di sviluppo.
“Gli ingegneri dell’impresa avevano il compito di delegare la progettazione e
l’ingegnerizzazione a qualcun altro, generalmente fuori dall’impresa. Questa situazione
non era accettabile per un’impresa tecnologica” (Chief Technology Officer, 14 Luglio
2006)
Queste attività consistevano principalmente nell’assegnare le performance dei
componenti o sistemi attribuiti ai fornitori e monitorare che tali obbiettivi venissero
raggiunti in termini di costi e tempi. In molti casi il livello di specificazione delle
attività affidate al fornitore non andava molto oltre l’assegnazione di target di prezzo e
di performance. Tuttavia,
“…nel fare questo l’OEM stava perdendo la capacità di fissare gli obbiettivi in termini di
performance e di monitorare le attività. E ancor più grave stava perdendo la capacità di
gestire i trade off di performance. Gestire le performance di ogni singolo sistema non
comporta, infatti la gestione efficace dell’integrazione di sistema.” (Responsabile
Integrazione di Sistema, Luglio 2006)
I manager intervistati spiegano la mancanza di competenze nella gestione del trade off
tra performance dei singoli componenti e performance del sistema nel suo complesso
come conseguenza del fatto che non venivano più svolte in house attività di
10
Come affermato dal manager delle risorse umane della divisione progettazione e ingegnerizzazione,
c’era una particolare lacuna in termini di capacità di utilizzo di sistemi di simulazione virtuale e questo
costituiva un notevole vincolo alla progettazione dell’organizzazione.
14
progettazione relative a quei specifici componenti o sistemi. In particolare essi hanno
confermato che risultava difficile (se non impossibile) integrare sistemi senza
padroneggiare a pieno la tecnologia del sistema stesso.
Accanto allo svuotamento delle conoscenze e alla incapacità di gestire il trade off delle
performance nel periodo oggetto di analisi si verificarono anche problemi di diversa
natura. Infatti, durante la fase di sviluppo nuovo prodotto c’erano anche notevoli
problemi riguardanti la struttura organizzativa, l’allocazione delle responsabilità e la
descrizione delle mansioni11. Questo venne alla luce quando i manager della
piattaforma di prodotto si sentirono schiacciati dai doveri legati alla gestione del
progetto, dai problemi di integrazione tecnica e dal coordinamento e gestione dei
fornitori. I manager di piattaforma erano responsabili dell’aspetto economico e di
gestione del progetto, e allo stesso tempo gestivano il coordinamento tecnico avendo la
responsabilità delle soluzioni tecniche. Tutto ciò complicato dall’esigenza di coordinare
soggetti prevalentemente esterni all’impresa (fornitori).
“prima (si riferisce ad un periodo anteriore al 2005) occorreva essere un “mago”. Ogni
cosa era sotto il controllo del manager responsabile del veicolo. Era impossibile far
fronte a tutti gli aspetti dello sviluppo del prodotto, dagli aspetti tecnici a quelli
economici” (Vehicle Line Executive, Luglio 2006)
La spinta esternalizzazione era causa, quindi, non solo dello svuotamento delle
conoscenze e della conseguente incapacità di gestire il trade off delle performance di
prodotto ma anche di problemi specifici della struttura organizzativa. La perdita di
controllo da parte dell’OEM della importante fase di pre-sviluppo (vedi Figura 1) e la
11
Come evidenziato in altri studi la strategia di outsourcing dell’OEM era stata accompagnata da
un’organizzazione per progetti in cui le unità organizzative incaricate per lo sviluppo dei nuovi prodotti
(“piattaforme”) avevano assunto una rilevanza centrale nell’organizzazione comportando un sostanziale
ridimensionamento delle competenze e delle capacità della struttura organizzativa che in una logica
funzionale gestiva lo sviluppo della tecnologia di componenti, sistemi e processi.
15
reale interpretazione del co-design12 rappresentavano ancora conseguenze del massiccio
outsourcing delle attività di progettazione.
A causa della perdita di know-how in alcune aree tecniche e delle carenti competenze
degli ingegneri nella progettazione di particolari sistemi, l’OEM scelse di coinvolgere
i fornitori nella fase di pre-sviluppo al fine di lasciar loro realizzare una gran parte di
essa. Il coinvolgimento e la gestione di tali fornitori era un’operazione tutt’altro che
banale: a causa della mancanza di competenze, infatti, c’erano problemi nel definire le
specifiche dei componenti. I fornitori avevano la responsabilità (nonché la gestione e
la conduzione) dell’integrazione dei sottosistemi (definendo gli obbiettivi e le
specifiche dei principali componenti). Questo processo non era del tutto “esplicito” nel
senso che l’OEM riteneva di poter definire le specifiche del componente. Il punto era,
infatti, che la progettazione delle soluzioni e le performance del sistema nel suo
complesso non erano sotto il pieno controllo dell’OEM. Questo era dovuto al fatto che
gradualmente i fornitori avevano aumentato le loro responsabilità nella fase di presviluppo. In più la fase di pre-sviluppo non era organizzata nel migliore dei modi
possibili a causa di colli di bottiglia nel processo decisionale. Quando, l’integrazione
di sistema veniva fatta dall’OEM principalmente nella fase di sviluppo, le performance
a livello veicolo erano testate alla fine del processo: i tempi per l’affinamento delle
performance arano molto limitati e modifiche a questo stadio della progettazione
risultavano estremamente costose e con alta probabilità di comportare problemi di
qualità del prodotto. Questo è il risultato di un approvvigionamento di tipo black box: i
fornitori incaricati della progettazione del concept del componente (fase di presviluppo) consegnano il componente o il sistema quando necessario al processo
d’integrazione, ossia nella fase terminale dell’intero processo (sviluppo).
12
Il co-design nel caso dell’OEM in oggetto assomiglia molto ad un black box sourcing (Lamming,
1993) piuttosto che ad una progettazione congiunta OEM-fornitore.
16
Tempo (circa 5 anni)
Pre –sviluppo
Sviluppo
OEM:
OEM:
Definisce le caratteristiche dei componenti e i
trade-off tra le performance (progettazione
degli archetipi e delle performance attese)
Progetta ed industrializza il prodotto per la
produzione di massa
Fornitori:
Fornitori:
Contribuiscono alla definizione del concept del
veicolo attraverso la proposizione di nuove
tecnologie e soluzioni tecniche con riferimento
ad i loro componenti
Progettano ed industrializzano i componenti
ed i sistemi in dettaglio
Congelamento del concept e dello
stile di massima
Nello sviluppo di un prodotto complesso, è possibile distinguere due fasi
principali: la fase di pre-sviluppo nella quale il veicolo viene “concepito” che
comprende anche la definizione delle caratteristiche di componenti e sistemi
(definizione archetipi e performance attese) e la fase di sviluppo nella quale la
progettazione e l’engineering del veicolo è specificata in dettaglio. Tra queste
due fasi si colloca il congelamento dello stile e l’avvio della fase di
industrializzione del veicolo con i parametri stabiliti.
Figura 1 – Differenza tra le fasi di pre-sviluppo e di sviluppo
È da notare come le conseguenze della perdita di controllo della fase di pre-sviluppo
siano significative: essa infatti, decide l’ammontare e la difficoltà del trade off che si
presenterà nella fase di sviluppo. Questi sono infatti programmati nella fase di presviluppo. Non controllando questa fase e lasciando che i fornitori prendano le decisioni
di maggiore rilievo (con un focus sui loro sottosistemi) si producono una serie di
problemi nella successiva fase di sviluppo (questo punto sarà ripreso sotto e nella figura
2).
5. Discussione
In questa sezione si cerca di discutere i principali problemi cui l’OEM ha dovuto far
fronte a seguito della scelta di esternalizzare le attività di progettazione.
17
5.1 L’integrazione di sistema comporta l’integrazione di performance
Come già detto gli ingegneri dell’OEM ritenevano che le loro principali attività fossero
connesse all’integrazione di sistema e alla gestione del coinvolgimento dei fornitori nel
processo di progettazione piuttosto che alla progettazione vera e propria. Di
conseguenza l’integrazione di sistema veniva erroneamente interpretata come
integrazione fisica dei sottosistemi. Occorre sottolineare che esiste una significativa
differenza tra integrazione fisica dei sistemi e gestione delle performance:
“le performance sono l’obbiettivo ultimo, non i sistemi” (Responsabile Integrazione di
Sistema, Luglio 2006)
È
opportuno
approfondire
questo
punto
per
comprenderne
l’importanza.
Semplicisticamente un’automobile è progettata per fornire determinate performance
(manovrabilità, consumi, determinati parametri ai crash test ecc..). Queste performance
sono generate dai componenti fisici e dai sistemi (il sistema di sicurezza passeggeri è
composto da freni, airbag, sedili, cinture di sicurezza ecc..). Alcune performance sono
generate da più di un sistema. Evidentemente freni, cinture di sicurezza, ecc. sono
importanti per definire le caratteristiche di sicurezza di un veicolo. Nei crash test,
comunque, la posizione, il peso e la struttura del motore così come le caratteristiche
dello chassis influenzano l’impatto percepito dal conducente. Il motore non fa parte del
sistema di sicurezza nello schema di scomposizione di un veicolo (perché la sua
funzione primaria è fornire la forza motrice). L’importante conclusione cui si perviene
è che le performance non possono essere completamente scomposte e risultano
strettamente legate ai particolari sistemi. In altre parole: per progettare un veicolo ad
elevate performance con riferimento al sistema di sicurezza non è sufficiente soltanto
un buon sistema di sicurezza in senso stretto; la sicurezza degli occupanti è una
performance a livello veicolo, una caratteristica di performance del prodotto nel suo
complesso e non solo del sistema di sicurezza stesso. Questo è un caso di performance
di prodotto e non di performance del singolo sistema. In conclusione, sebbene la
progettazione dei singoli sistemi e componenti sia una parte necessaria del processo,
18
sarebbe un errore limitarsi ad essa, sottovalutando la circostanza che la buona
progettazione dei singoli sistemi non necessariamente implica un prodotto dalle ottime
performance complessive. Ne consegue che la sola integrazione fisica non basta.
5.2
La
focalizzazione
sull’integrazione
fisica
dei
componenti
distoglie
dall’integrazione delle performance
Interpretare l’integrazione di sistema come integrazione fisica dei componenti vuol dire
assumere implicitamente che le caratteristiche di performance di un veicolo possono
essere scomposte in “sotto-performance” assegnate ai principali sistemi responsabili di
generare quella performance stessa. Il problema nasce allorquando le performance a
livello veicolo non sono la semplice “somma” delle performance delle singole parti ma
il risultato dell’interazione delle stesse.
Considerare l’integrazione fisica dei sistemi come il principale obbiettivo distoglie
l’attività di integrazione rispetto al reale focus: integrare le performance di componenti
e sistemi a livello di prodotto (nel caso del veicolo). Ovviamente le performance sono
frutto di componenti e sistemi nel loro insieme, la loro progettazione rappresenta quindi
una fase importantissima del processo. La focalizzazione esclusiva sulla progettazione
fisica dei prodotti e sulla gestione dei fornitori distoglie dalla progettazione delle
performance.
5.3 La modularità può supportare l’integrazione fisica di componenti ma non
l’integrazione delle performance
Il principale interesse di un ingegnere impegnato nello sviluppo di un nuovo veicolo
non riguarda la funzione svolta dal componente/sistema, ma piuttosto il livello di
performance e le caratteristiche di performance che tale funzione può generare. Il
problema pratico che gli ingegneri si trovano a risolvere riguarda la progettazione di un
veicolo che deve raggiungere, in quanto sistema interconnesso, un determinato livello
di performance complessive. Tali performance devono essere ripetibili e stabili.
19
In tale ottica si comprende come la progettazione modulare di prodotto non possa
risultare una soluzione per il problema dell’integrazione delle performance. La ragione
è legata al fatto che i benefici attribuiti alla modularità (Sanchez, 1995) non riescono a
risolvere i problemi connessi all’integrazione delle performance13. La progettazione
modulare presenta alcuni benefici nel risolvere il problema di coordinamento dei
fornitori lasciando che essi sviluppino in maniera indipendente i componenti e i sistemi
che occorre integrare (grazie alla presenza di interfacce standard). Per questa attività la
progettazione modulare risulta estremamente efficace perché riduce gli sforzi di
coordinamento necessari affinché componenti e sistemi sviluppati dai diversi fornitori
portino ad un prodotto integro e coerente. Come osservato nel caso, quando la
definizione ex ante delle interfacce tra i componenti del prodotto è realizzabile, una
volta assegnati i singoli compiti di sviluppo ai fornitori, il coordinamento seguirà come
naturale conseguenza. L’interfaccia incorporerà tutte le informazioni necessarie.
Tuttavia, il caso mostra anche che non è sempre possibile definire le interfacce. In tal
senso i nostri risultati supportano la letteratura (Takaeshi e Fujimoto, 2003, Sako, 2003)
in cui si rappresenta l’auto come un prodotto che vede affiancati sistemi di componenti
modulari e sistemi integrali. Nel complesso, tuttavia, le nostre interviste mettono in
evidenza che la maggior parte delle performance complessive di veicolo sono il frutto
di una stretta interazione tra molti componenti e sistemi (si pensi ai crah test o
all’handling). Ciò richiede da parte dell’OEM un impegno nel coordinamento dei
fornitori che va ben al di la della mera definizione delle interfacce tra componenti.
Questo è fondamentalmente il motivo per cui in questo lavoro si enfatizza la differenza
tra “funzione” e “performance”. L’integrazione delle performance risulta, infatti, in
13
Si tiene a precisare che la modularità può essere interpretata diversamente in funzione del livello di
analisi. Per l’ingegnere progettista, realizzare un componente modulare significa progettare con un
numero di vincoli superiore rispetto al caso si progettazione integrale, ovverosia nel caso in cui le
interdipendenze tra i componenti e le interfacce non siano definite a priori. Se si sposta l’analisi sul
piano del coordinamento organizzativo, è evidente che la modularità diventa uno strumento per
minimizzare lo scambio informativo e la necessità di coordinamento inter unità. L’informazione
contenuta nella definizione delle interfacce standard rappresenta uno strumento per coordinare senza
necessità di altri strumenti organizzativi (per esempio team congiunti) lo sviluppo dei componenti che
ruotano intorno all’interfaccia. In questo lavoro, essendo il livello di analisi quello dell’integrazione di
sistema, si considererà la modularità come strumento di coordinamento.
20
ogni caso un problema molto diverso che coinvolge il comportamento in esercizio del
prodotto e che attiene all’interazione delle parti allorquando queste si trovano ad
operare nel prodotto finito.
5.4 L’integrazione di sistema implica la gestione del trade off delle performance
Fare integrazione di sistema vuol dire progettare le performance complessive del
veicolo (Manager responsabile dell’integrazione di sistema, 14 Luglio 2006).
Esse sono proprietà sistemiche e nascono dall’integrazione di vari sottosistemi. La
progettazione delle performance a livello veicolo richiede la gestione dei trade off di
performance tra i diversi sistemi. Questo, in definitiva, richiede una profonda
conoscenza e comprensione dell’interazione tra i singoli sottosistemi. Per poter
identificare le conseguenze legate ai diversi trade off e per poter sfruttare le situazioni
migliori è richiesta una approfondita conoscenza dei sistemi sottostanti. Come è stato
argomentato in precedenza tale conoscenza risulta essere la motivazione per la quale le
imprese “devono conoscere più di quello che fanno” (Brusoni et al., 2001) al fine di
raggiungere elevate performance a livello di veicolo.
5.5 Il learning by doing costituisce la chiave per gestire il trade off delle
performance.
Le principali difficoltà incontrate dall’OEM erano principalmente legate all’incapacità
di definire le specifiche funzionali inter-sistema. La causa del problema era
un’insufficiente conoscenza dei sottosistemi14. Durante la fase di pre-sviluppo i
fornitori (in particolare i fornitori di sistemi importanti) erano collocati presso la
divisione progettazione e ingegnerizzazione dell’OEM: questo costituiva l’occasione
14
Ciò portava inevitabilmente ad elevare gli standard richiesti ai fornitori senza necessariamente una
giustificazione. Tale atteggiamento era frutto dell’insicurezza dell’OEM sulle esatte prestazioni che il
componente acquistato doveva offrire. Tale circostanza portava spesso ad un aumento dei costi spesso
ingiustificato.
21
per intensi scambi informativi e per il trasferimento di conoscenza tacita e competenze.
Tuttavia, l’erosione delle competenze e la completa esternalizzazione delle attività
aveva portato comunque all’esclusione degli ingegneri dell’OEM, a causa della totale
assenza di absorptive capacity (Cohen e Levintahl, 1990), dalla fase di pre-sviluppo e
quindi dal processo di learning by doing. Poiché essi non svolgevano più le fasi di
progettazione di alcuni sistemi, iniziavano a disinteressarsi alle tecnologie specifiche
dei componenti fino al punto di perdere le capacità di integrazione.
E’ interessante notare a tale proposito che nei primi anni in cui la strategia di
outsourcing si era manifestata, l’OEM aveva mantenuto la capacità di indirizzo e
coordinamento grazie al personale che per anni aveva sviluppato in house le tecnologie
poi esternalizzate. Dopo alcuni anni, tuttavia, sia per l’allontanamento del personale
dall’azienda sia per l’evoluzione tecnologica che ha caratterizzato molti dei componenti
oggetto dell’outsourcing, questa capacità di sovrintendere ai processi di sviluppo si è
persa e con essa l’absorptive capacity. L’OEM quindi si è trovato ad osservare i
sintomi della “malattia” (perdita di controllo sull’integrazione delle tecnologie), quando
ormai questa era già in fase terminale.
In Figura 2 viene mostrato un caso di allontanamento dell’OEM dal processo di
learning by doing della progettazione di componenti ed il suo impatto sulla capacità di
progettare le performance del veicolo in fase di pre-sviluppo: la chiave sta proprio nel
learning by doing. Esso sembra, infatti, il principale meccanismo in grado di assicurare
il mantenimento nel tempo di specifiche competenze di progettazione.
22
Tempo (circa 5 anni)
Pre –sviluppo
Sviluppo
OEM:
OEM:
Definisce le caratteristiche dei componenti e i
trade-off tra le performance (progettazione
degli archetipi e delle performance attese)
Progetta ed industrializza il prodotto per la
produzione di massa
Fornitori:
Fornitori:
Contribuiscono alla definizione del concept del
veicolo attraverso la proposizione di nuove
tecnologie e soluzioni tecniche con riferimento
ad i loro componenti
Progettano ed industrializzano i componenti
ed i sistemi in dettaglio
Rischi: difficoltà
nell’integrazione dei sistemi nel
lungo periodo a causa
dell’assenza di learning by doing
nella fase di sviluppo
Rischi: mancanza di integrità di
prodotto e performace scarse che
causano re-design tardivi e costosi
durante lo sviluppo del singolo
progetto
Congelamento del concept e dello
stile di massima
Figura 2 – Rischi nelle fasi di pre-sviluppo e sviluppo
6. Conclusioni
Questo paper ha analizzato il modo in cui un OEM nel settore automotive ha gestito
l’innovazione in network e quale sia stato l’approccio utilizzato per la gestione
dell’open innovation.
Il contributo del lavoro consiste in primo luogo nell’approccio della ricerca che utilizza
come unità di analisi la value chain sia osservandone le traiettorie strategiche sia quelle
micro-organizzative (Jacobides e Cacciatori, 2005; Fine, 1998).
I principali risultati cui si è pervenuti sono sostanzialmente legati all’analisi
dell’insuccesso della strategia di esternalizzazione dell’OEM. La prima considerazione
23
riguarda il ripensamento del problema dell’integrazione di sistema in termini di
integrazione della conoscenza. Il caso supporta questa affermazione perché mostra
come le recenti decisioni prese dall’OEM in termini di strategia di insourcing di alcune
attività di progettazione siano legate a problemi di integrazione della conoscenza.
Ritenendo che l’integrazione di conoscenza sia la chiave per l’integrazione di sistema,
il caso consente di comprendere quanto sia importante il modo in cui l’OEM interpreta
il proprio ruolo di integratore di sistema.
Quando opera come integratore di sistema, l’OEM deve non solo considerare che esiste
una differenza tra le competenze architetturali e le competenze sulle singole tecnologie,
ma deve tenere in conto anche che la progettazione delle performance di prodotto è la
progettazione delle funzioni del prodotto stesso sono due attività concettualmente
diverse. Se è vero che per alcuni componenti è possibile procedere in una logica
modulare e quindi mantenere competenze architetturali tralasciando le competenze
specifiche, nella maggior parte dei casi, nei prodotti complessi, le performance
complessive non possono essere facilmente scomposte in particolari funzioni/moduli.
Esse, infatti, sono strettamente connesse. Ne consegue che progettare le performance
complessive vuol dire integrare le singole performance e non sommare le singole
funzioni (per questo tema è stato di recente introdotto il termine “pliotropia”, Padget,
2001; Brusoni e Prencipe, 2006).
Si può ricavare dal caso che per l’OEM oggetto dell’analisi la gestione
dell’integrazione della conoscenza per prodotti complessi abbia significato essere in
controllo delle reciproche interdipendenze tra sistemi e componenti ad esso sotteso. I
meccanismi proposti dalla letteratura per ottenere tale integrazione - modularità15, uso
di resident engineers, risorse IT, ecc. - non sembrano essere in grado di far fronte alle
necessità di integrazione di conoscenza specialistica dispersa. Questo sostanzialmente
accade perché i meccanismi citati supportano in maniera efficace l’integrazione fisica
dei componenti e non l’integrazione delle performance. In realtà, spostarsi dalla mera
integrazione fisica di sistema all’integrazione delle performance significa avere un
15
Si veda la nota 13 per inquadrare la modularità tra gli strumenti di coordinamento.
24
approfondita conoscenza e competenza dei sistemi di base coinvolti nel prodotto. In tal
ottica le strategie di apprendimento poste in essere dall’OEM, ed in particolare il
meccanismo del learning by doing, costituiscono la chiave
per l’integrazione di
sistema e la gestione del trade off delle performance.
Resta tuttavia aperto il dibattito circa l’organizzazione dell’integrazione di sistema per
la gestione dell’innovazione in network ed in particolare occorre approfondire quale sia
la struttura organizzativa e di governance che meglio supporta tale capacità. Una
possibile soluzione riguarda l’integrazione verticale: in questo caso i processi di
apprendimento ed integrazione della conoscenza risulterebbero quanto meno ridotte dal
fatto che tutte le attività di progettazione sono internalizzate16. Lo studio condotto,
tuttavia, non porta alla conclusione che l’OEM debba ridurre l’esternalizzazione dei
processi d’innovazione sviluppando una strategia completamente integrata di
progettazione. L’integrazione verticale, infatti, rappresenta, comunque, una soluzione
estrema, costosa e vincolante.
Il caso, viceversa, supporta i vantaggi del modello della open innovation e suggerisce,
piuttosto, che i problemi legati alla integrazione di sistemi non attengono tanto ai
confini dell’impresa quanto alla progettazione e funzionamento delle strutture e dei
processi
organizzativi. Nell’esempio
mostrato,
una possibilità
di
intervento
organizzativo riguarda la strutturazione del processo di sviluppo prodotto, e la necessità
che l’OEM gestisca diversamente la fase di pre-sviluppo.
Più in generale, quindi, la ricerca conferma che sebbene la strada tracciata nei recenti
contributi (Iansiti e Levien, 2004, Jacobides et al., 2006, Chesbrough, 2003) sia foriera
di soluzioni strategiche particolarmente attraenti per le imprese moderne, molto rimane
ancora da comprendere sui temi (1) del passaggio dall’implementazione di strategie di
open innovation alla costruzione di nuove competenze strategiche per le imprese; (2) e
del come realizzare il sourcing di tecnologie esogene o sviluppate da fornitori terzi,
16
Rimarrebbero, comunque, da gestire i problemi generali legati all’integrazione della conoscenza
(Becker, 2001).
25
ovverosia delle implicazioni dell’open innovation sulle strutture organizzative, la
cultura d’impresa, le routine.
Bibliografia
BALDWIN C.Y., CLARK K.B. (1997), Managing in an Age of Modularity, Harvard
Business Review, 75, 84-93.
BECKER M.C. (2001), Managing dispersed knowledge: Organizational problems,
managerial strategies, and their effectiveness, Journal of Management Studies,
38 (7), 1037-1051.
BRUSONI S., PRENCIPE A. (2001), Unpacking the Black Box of Modularity:
Technologies, Products and Organizations, Industrial & Corporate Change, 10
(1), 179-205.
BRUSONI S., PRENCIPE A. (2006) Making Design Rules: A multi-domain perspective,
Organization Science, 17 (2), 179-189.
BRUSONI S., PRENCIPE A., PAVITT K. (2001), Knowledge Specialisation, Organizational
Coupling and the Boundaries of the Firm: Why Firms Know More Than They
Make?, Administrative Science Quarterly, 46 (4), 597-621.
BRUSONI S., PRENCIPE A., PAVITT K. (2002), Knowledge specialization, organization
coupling, and the boundaries of the firm: Why do firms know more than they
make? Administrative Science Quarterly, 46 (4), 597-625.
CHESBROUGH H. (2003), Open innovation. Free Press, New York, NJ.
CHESBROUGH H., KUSUNOKI K. (2001), The modularity trap: innovation, Technology
Phases Shifts and the Resulting Limits of Virtual Organisations, in NONAKA, I.,
TEECE D., (eds.), Managing Industrial Knowledge, Sage Press, London, 202-30.
COHEN W., LEVINTAHL, D. (1990), Absorptive Capacity: A New Perspective on
Learning and innovation, Administrative Science Quarterly, 35, 128-152.
EISENHARDT K. (1989), Building Theories from Case Study Research, Academy of
Management Review, 14 (4), 532-550.
26
ENRIETTI A., FOLLIS M., WHITFORD J. (2002), Improving performance at the second
tier of the automotive supply chain, Supply Chain Governance and Regional
Development in the Global Economy, University of Wisconsin, September 10.
FINE C.H. (1998), Clockspeed: Winning Industry Control in the Age of Temporary
Advantage, Reading, MA, Perseus Books, Cambridge, MA.
FINE C.H., WHITNEY D.E. (1996), Is the make-buy decision process a core
competence?, MIT unpublished manuscript.
GRANT R. M. (1996), Toward a Knowledge-Based Theory of the Firm, Strategic
Management Journal, 17(Winter Special Issue), 109-122.
HENDERSON R., COCKBURN I. (1994), Measuring Competence? Exploring Firm Effects
in Pharmaceutical Research, Strategic Management Journal, 15, 63-84.
HOBDAY M., RUSH H. (2000), innovation in complex products and system, Research
Policy, 29 (7/8), 793-807.
HOBDAY M., DAVIES A., PRENCIPE A. (2005), Systems integration: a core capability of
the modern corporation, Industrial and Corporate Change, 14 (6), 1109-1143.
IANSITI M., LEVIEN, R. (2004), The Keystone Advantage, Harvard Business School
Press, Boston, MA.
JACOBIDES M., CACCIATORI E. (2005), The Dynamic Limits of Specialization: Vertical
Integration Reconsidered, Organization Studies, 26, 1851-1883.
JACOBIDES M., KNUDSEN T., AUGIER M. (2006), Benefiting from innovation: value
creation, value appropriation and the role of industry architectures, Research
Policy, in press.
LAMMING R. (1993), Beyond Partnership: Strategies for innovation and Lean Supply,
Prentice-Hall, Harlow, UK.
LINCOLN J.R., AHMADJIAN C.L., MASON E. (1998), Organizational Learning and
Purchase-Supply Relations in Japan: Hitachi, Matsushita and Toyota
Compared, California Management Review, 40, 241-264.
MAXTON G., WORMALD J. (2004), Time for a Model Change: Re-engineering the
Global Automotive Industry, Cambridge University Press, Cambridge, UK.
27
MCCLOSKEY N. D. (1985), The Rhetoric of Economics, The Noard of Regents of the
University of Wisconsin System (trad. it. (1988), La retorica dell’Economia,
Einaudi, Torino, IT).
MIKKOLA J. (2006), Capturing the Degree of Modularity Embedded in Product
Architectures, Journal of Product innovation Management, 23 (2), 128-146.
MILES M.B., HUBERMAN A.M. (1994), Qualitative Data Analysis: An Expanded
Sourcebook, 2nd edition, Sage Publications, Thousand Oaks, CA.
NESTA L., DIBIAGGIO L. (2003), Technology strategy and knowledge dynamics: the
case of biotech, Industry & innovation, 10 (3), 329-347.
PADGETT J. F. (2001), Organizational genesis, identity and control: The transformation
of banking in Renaissance Florence, in RAUCH J. E., CASELLA A., eds. Networks
and Markets, Russell Sage, New York, NJ, 211–257.
PETTIGREW A. M. (1990), Longitudinal Field Research on Change: Theory and
Practice, Organization Science, 1 (3), 267-292.
POWELL W., KOPUT K.W., SMITH-DOER L. (1996), Interorganizational collaboration
and the locus of innovation: Networks of Learning in Biotechnology,
Administrative Science Quarterly, 41, 116-145.
PRENCIPE A. (2003), Corporate Strategy and Systems Integration Capabilities –
Managing Networks in Complex Systems Industries, in PRENCIPE A., DAVIES A.,
HOBDAY M. (eds.): The Business of Systems Integration, Oxford University
Press, Oxford, UK, 114-132.
PRENCIPE A. (2004), Change, Coordination, and Capabilities, SPRU Electronic
Working Paper Series, Paper 120.
PRENCIPE A., DAVIES A., HOBDAY M. (2003), The Business of Systems Integration,
Oxford University Press, Oxford, UK.
SAKO M. (2003), Modularity and outsourcing: the nature of co-evolution of product
architecture and organization architecture in the global automotive industry, in
PRENCIPE A., DAVIES A., HOBDAY M. (2003), The Business of Systems
Integration, Oxford University Press, Oxford, UK, 229-253.
28
SANCHEZ R. (1995), Strategic flexibility in Product Competition, Strategic Management
Journal, 166, 135-139.
SANCHEZ R., MAHONEY J.T. (1996), Modularity, Flexibility, and Knowledge
Management in Product and Organization Design, Strategic Management
Journal, 17, 63-76.
SCHILLING M. (2000), Toward a General Modular Systems Theory and Its Application
to Interfirm Product Modularity, Academy of Management Review, 25 (2), 312335.
STURGEON T.J. (2002), Modular production networks: a new American model of
industrial organization, Industrial and Corporate Change,11 (3), 451-496.
TAKEISHI A. (2001), Bridging inter- and intra-firm boundaries: management of
supplier involvement in automobile product development, Strategic Management
Journal, 22, 403-433.
TAKEISHI A. (2002), Knowledge Partitioning in the Inter-Firm Division of Labour: The
Case of Automotive Product Development, Organization Science, 13, 321-338.
TAKEISHI A., FUJIMOTO T. (2003), Modularization in the car industry: interlinked
multiple hierarchies of product, production and supplier systems, in PRENCIPE
A., DAVIES A., HOBDAY M., (eds.), The Business of Systems Integration, Oxford
University Press, Oxford, UK, 254-278.
ULRICH K.T., EPPINGER S.D. (2004), Product Design and Development, McGraw-Hill,
New York, NJ.
VON HIPPEL E. (1988),
The Sources of innovation, Oxford University Press, Oxford.
WOMACK J.P., DANIEL T.J., ROOS D. (1990), The Machine That Changed the World :
The Story of Lean Production, Rawson Associates, New York, NJ.
YIN, R. K. (1994), Case study research: design and methods, Sage, Thousand Oaks,
CA
29