Risultati della ricerca

 L’adozione dei sistemi di controllo manageriale nello sviluppo del nuovo prodotto

La tabella 25, Pannello A, fornisce le statistiche descrittive sulla percentuale di aziende che adottano ogni sistema, nello sviluppo del prodotto, identificato per questa ricerca e il tempo di adozione dalla fondazione dell’azienda

Tabella 25

PANNELLO A

Time to adoption è la media del numero di anni dalla fondazione all’adozione del particolare sistema da

Il Pannello B nella tabella 25 riporta le distribuzione di frequenza dei tipi di misure usate per tracciare lo sviluppo del prodotto e quanto spesso esse sono aggiornate. Tali informazioni sono state ottenute tramite il questionario e le misure erano codificate, indipendentemente, da due ricercatori.

PANNELLO B

La tabella riporta il numero di rispondenti che hanno elencato ogni misura tra le tre ritenute più importanti perla gestione dello sviluppo del prodotto e la frequenza (espressa in mesi) con la quale tale misure sono aggiornate.

L’analisi iterativa dei dati dell’intervista ha identificato sei differenti driver di adozione dei MCS, oltre alle uniche esperienze non significative da una prospettiva statistica, ma rilevanti per capire come i MCS possono essere usati e per comprendere la ricchezza del fenomeno esaminato. La tabella 26 fornisce le statistiche descrittive e le quote illustrative per ognuno dei driver. Questi driver non sono esclusivi l’un l’altro, in più uno può essere presente a differenti fasi o per differenti sistemi all’interno di un azienda. Per ogni driver, è stato riportato il numero di osservazioni dove egli era il principale driver e il numero di osservazioni dove era un driver secondario.

In alcune osservazioni, i sistemi sono adottati per legittimare l’azienda rispetto ai partner esterni. (Carruthers, 1995). Essi non sono richiesti da una prospettiva manageriale, ma sono adottati come un simbolo (Macintosh 1994) per accrescere la credibilità dell’azienda nei confronti delle parti esterne (generalmente i clienti, i partner e gli investitori). Questo ruolo è coerente con il ruolo teorico sintetizzato nel paragrafo 6.4, al punto 7. Stabilire una struttura per l’interazione con le parti esterne è un altro driver esterno dei MCS. Le parti esterne, infatti, richiedono visibilità dei processi organizzativi per monitorarli, coordinarli e controllarli (Pfeffer 1978). Gli accordi all’interno delle organizzazioni mancano di una costante interazione, richiesta per istruire il management informale e per formalizzare il bisogno; l’interfaccia è migliorata in queste situazioni.

L’evidenza in tabella è espressa in modo coerente con i driver interni dell’adozione dei MCS. I manager possono essere pro attivi per quel che riguarda i sistemi, che sono implementati più avanti nell’azienda che li richiede. Vengono distinti, in tale lavoro, 2 driver differenti: Background e Focus. Il Background evidenzia il fatto che spesso determinati sistemi vengono utilizzati in azienda nel momento in cui viene assunto un manager, quindi a causa della precedente esperienze di questa persona. Questi manager, generalmente, per la loro significativa precedente esperienza, percepiscono i MCS come infrastrutture manageriali necessarie per facilitare la crescita. Il loro comportamento può essere interpretato come mimetico (Powell e latri, 1991); essi emulano le pratiche da altre organizzazioni per ridurre l’incertezza cognitiva. Il secondo driver, focus, riflette il fatto che i manager, spesso, vogliono implementare i sistemi perché essi verificano l’esistenza di un bisogno emergente. In contrasto con il background, i focus drivers rispondono a particolari bisogni, come quello di coordinare una forza lavoro dispersa geograficamente, incrementare l’efficienza organizzativa o migliorare la comunicazione.

I MCS possono essere adottati come una reazione a eventi inaspettati, a sbagli o ricorrenti problemi (Simons 1995); si parla in tal caso di driver reattivo: reazione al

caos. La mancanza di abilità o la mancanza di risorse può ritardare l’adozione dei

sistemi fino a costanti fallimenti nei processi informali imposti. (Flamholtz, 2000). In molte circostanze, il caos era non voluto e i manager mal preparati nella gestione dello stesso.

Un’ultima categoria che è stata classificata come reattiva alla cultura, è il risultato di un processo messo in atto (Weick, 1995). Mentre nel caso precedente il risultato era una più efficiente organizzazione, questa categoria è differente dalla prospettiva della categoria focus: i sistemi formali emergono come il risultato del processo di apprendimento. In questo caso non sono i manager che decidono d’implementare i sistemi per un particolare bisogno, ma i sistemi nascono per codificare le esistenti pratiche. In alcuni casi, la codifica era innescata da certi eventi. Per esempio, in una delle aziende la crescita, associata con il boom economico degli ultimi anni 90, innescava la codifica dei processi.

La tabella 26, inoltre, identifica i casi dove era usato un approccio manageriale informale. Il conteggio è limitato alle aziende che esplicitamente menzionano questo approccio.

Le ragioni per mantenere un approccio informale includono: (1) il team ha lavorato insieme per un lungo tempo e le sue informali interazioni sono ben precise ma non codificate, (2) i team manageriali credevano che i sistemi formali potessero uccidere la creatività, (3) l’organizzazione non era considerata abbastanza grande da ammettere MCS, (4) il team manageriale non doveva avere la conoscenza per implementare questi sistemi.

Una volta adottati, i MCS rimangono come parte dell’infrastruttura manageriale ed evolvono. Frequentemente, le interviste descrivono i sistemi come molto appropriati e molto sofisticati. In poche impostazioni, i MCS possono essere una soluzione vincolante nel tempo per ottenere un certo obiettivo. Per esempio, un nuovo CEO nel campione formalizzava il processo di selezione del prodotto per focalizzare l’organizzazione su tale aspetto. I manager, inoltre, hanno evidenziato esempi di MCS che soffocavano l’innovazione e il bisogno di adottare i MCS, all’interno del contesto di un’azienda e della loro dimensione, il minimo di cui essi avevano bisogno, per facilitare la realizzazione del prodotto senza mettere riferimenti artificiali, barriere o blocchi che avrebbero rallentato i risulati.

L’analisi ha consentito di ottenere ulteriori informazioni, relative a coloro che hanno progettato i MCS. I manager interni hanno progettato i MCS nella maggior parte dei

casi (61 casi). Tipicamente, il progetto è un processo di creazione della conoscenza che è tacito in quasi tutti i casi; la conoscenza è assunta insieme a una persona. Una delle aziende nel campione ha assunto un manager dello sviluppo del prodotto da una delle più grandi aziende di semiconduttori nel mondo, il quale ha progettato i sistemi basandosi sulle scelte dell’azienda più grande. I progettisti esterni sono più rari (3 casi) e spesso riflettono il processo di acquisizione di partners o l’acquisto di tecnologie esterne (software) per gestire i processi.

 Tempo di adozione dei MCS e impatto sulle performance

Questa sezione esamina se la tipologia di sistema è rilevante nello spiegare i processi manageriali nello sviluppo del nuovo prodotto. Vengono affrontate due questioni.

Prima, è stato testato se i vari driver identificati, collegati con l’adozione dei MCS nello sviluppo di un prodotto, sono associati a differenti tempi di adozione. I sei driver descritti nella tabella 26 sono avvenimenti-guida: se un gruppo esterno domanda di vedere un processo; è cominciata una nuova partnership; un nuovo manager è assunto; emergono bisogni; si presentano problemi o le pratiche informali sono formalizzate. Perciò, l’adozione dipende dal fatto che capiti un evento e non c’è una chiara aspettativa direzionale. Comunque, si ritiene che le aziende che si basano su un approccio informale riporteranno l’adozione dei sistemi in ritardo rispetto alle altre aziende nel campione. È anche plausibile che le aziende, adottando tali sistemi per il learning-by- doing, li implementeranno più tardi che il resto delle aziende.

In tale progetto di ricerca, vengono esaminati i potenziali effetti dei vari driver sul tempo di adozione dei MCS nello sviluppo del prodotto usando uno specifico modello (Davila 2005; Hellmann & Puri 2002). Queste specifiche collegano il tempo a un evento. In questo particolare caso, viene riportato il tempo di raggiungimento delle milestones (obiettivi, importanti traguardi) dello sviluppo del prodotto e qual è il sistema adottato più spesso nel nostro esempio. È stata domandata, sia al CEO, sia alla persona che si occupa dello sviluppo del business, la data di raggiungimento. La tabella

27 riporta i risultati. La variabile dipendente è il tempo di raggiungimento delle

milestones dello sviluppo del prodotto, come riportato dal manager dello sviluppo del prodotto. Le variabili indipendenti sono variabili fittizie che hanno valore 1 per quelle aziende dove un particolare driver per l’adozione era identificato (durante la codifica delle interviste), senza badare se questo è un driver principale o secondario. I coefficienti riportati sono tassi di rischio. Un coefficiente sulle variabili indipendenti più

grande (o minore) di uno vuol dire che più elevati valori per le variabili indipendenti sono associati con un più corto (o più lungo) tempo di raggiungimento degli obiettivi. Eccetto per la cultura e la contrattazione, gli altri 4 driver sono associati a un più rapido e significativo raggiungimento delle milestones, che si riferiscono allo sviluppo del prodotto.

Tabella 27: la formalizzazione nello sviluppo del prodotto

Significativamente differenti rispettivamente al 10%, 5% e 1% dalla categoria di riferimento. Significativamente differente al 10% da legitimize. La tabella riporta un COX modello di rischio proporzionale del tempo di adozione delle milestones dello sviluppo del prodotto. Le variabili indipendenti sono i drivers di adozione dei MCS; la categoria non inclusa sono i sistemi informali.

Comunque, noi troviamo differenze non significative tra i vari gruppi. Questo risultato suggerisce che la descrizione nelle interviste è coerente con gli approcci informali, che comportano un più lungo tempo per l’adozione di un particolare sistema, e che nessun particolare driver è associato a una più rapida adozione (coerentemente con questi driver essendo associati a eventi casuali).

Il secondo test esamina l’associazione tra le performance dello sviluppo del prodotto e i 6 driver descritti nella tabella 26. Se i MCS sono rilevanti per la performance (assumendo che questi sono adottati in relazione a specifici bisogni dell’azienda) allora è probabile che siano associati differenti driver alla performance. In particolare, ci aspettiamo che i driver proattivi (background e focus) e il learning by doing comportino una migliore performance. Le aziende in questi gruppi adottano i MCS come una strada per facilitare la gestione dello sviluppo del prodotto, in contrapposizione con le aziende in altri gruppi (driver esterni, caos e informali), le quali sono forzate nell’adottare i

MCS. Le variabili indipendenti hanno un valore pari a 0 per le aziende dove i progetti di sviluppo del prodotto sono tardivi (43 osservazioni) e 1 se sono in tempo limite o prematuri (21 osservazioni). Sono state perse 5 osservazioni relative ad aziende che hanno deciso di non svelare le loro performance nello sviluppo del prodotto. È stata scelta una variabile fittizia perché le aziende hanno tipi di progetti molto differenti, i quali vengono attivati nello stesso tempo, (grandi progetti per sviluppare una nuova piattaforma, progetti medi per sviluppare particolari funzioni e progetti più corti per adattare il prodotto a un particolare cliente ) e i rispondenti spesso lasciavano in bianco il punto del questionario su quanto in ritardo erano i progetti perché, come essi avevano precisato durante le interviste, esso variava in relazione alle tipologie e alla particolarità dei progetti. Le variabili dipendenti sono come in tabella 26. La tabella 28 riporta i risultati. Background guida le aziende verso performance significativamente migliori che contract e chaos. Anche il learning by doing comportata performance migliori rispetto agli ultimi due drivers. Contrariamente alle aspettative, il driver focus comporta prestazioni peggiori che la gestione informale delle aziende (la quale comporta performance migliori che contract, focus, e chaos), che non consente performance significativamente migliori che qualsiasi della altre categorie.

Tabella 28: la formalizzazione dello sviluppo del prodotto e le performance

** Significativamente differente al 5% dalla categoria di riferimento; +++ significativamente differente all’1% da chaos, ++ 5% da contract e focus; significativamente differente al 10% da learning, significativamente differente al 5% da legitimize, significativamente differente al 10% da contract.