Disruptive projects /

Progettazione aumentata

Progettazione aumentata

13 Dicembre 2011 Paola De Vecchi Galbiati
Paola De Vecchi Galbiati
Paola De Vecchi Galbiati
share
Tablet, APP e Cloud Computing: gli strumenti di condivisione e di comunicazione influenzano la ricerca e lo sviluppo di nuovi prodotti e favoriscono nuove forme di collaborazione tra persone, trasformando anche il modo di progettare processi e organizzazioni.

Ieri sera ho terminato la lettura di un saggio sull'impatto della fisica quantistica sul nostro modo di ragionare, sul nostro modo di interpretare la realtà e di relazionarci con gli altri: Come Uno è Uno di Emanuele Angeleri.

Stamattina ho guardato il video di Roberto Carraro, che descrive con estrema chiarezza l'evoluzione dalla multimedialità alla multisensorialità, attraverso una dimostrazione di Bubble Viewer, un brevetto italiano su cui si basano molte APPlicazioni per smart phone e tablet.

Questi due "oggetti", apparentemente distanti,  mi hanno spinto ad alcune considerazioni sul processo di Ricerca e Sviluppo di Nuovi Prodotti... Come sono descritti oggi i processi di sviluppo prodotto? Nella maggior parte dei casi sono ancora rappresentati attraverso modelli deterministici, in cui il processo è scomposto in processi più piccoli, facilmente controllabili e misurabili.

Per descrivere tale processo, si posso identificare i seguenti passaggi:

  1. Si definisce un linguaggio formale di descrizione dei processi (per esempio, la notazione a flow chart)  e tramite esso si descrive il "processo di sviluppo prodotto ideale".
  2. Si analizza il "processo reale" intervistando le persone coinvolte, osservando come lavorano, partecipando alle riunioni e alle attività operative.
  3. Si descrive la realtà osservata usando lo stesso linguaggio formale usato per descrivere il "processo ideale".
  4. Si fornisce una lista dei <gap> tra la 'realtà-modellata' e quello che <a tendere> vorremmo che la realtà diventasse.

 

In questo modo però è difficile poter descrivere eventi che non siano definibili attraverso il modello prescelto e i suoi formalismi.

Infatti, nell'applicazione di ogni modello c'è sempre un margine d'errore, che le aziende decidono scientemente di tollerare: meglio avere un modello della realtà 'abbastanza realistico' ma che mi consente di controllare e misurare nel breve/medio termine, piuttosto che spendere tempo e denaro per ridurre il margine d'errore del mio modello a 'lungo' termine, senza avere la possibilità oggi di comprendere oggi i supposti benefici di domani.

Infondo è così che procediamo normalmente: per piccoli passi, per raffinamenti successivi ... e questo accade anche per i linguaggi formali, che altro non sono che strumenti concettuali, che ci aiutano a condividere con altre persone possibili rappresentazioni della realtà e del futuro.

 

Di seguito è illustrato il processo di Ricerca e Sviluppo Nuovi Prodotti di una grande azienda manifatturiera.

Per descrivere il processo, ancora tutto da 'informatizzare', vennero costruiti i flow chart che seguivano l'evoluzione di tre grandezze osservabili, corrispondenti a tre categorie di oggetti reali:

NPD process (1)

      • lo Stato del prodotto, che identifica i vari stadi della trasformazione: dal brief, al primo mock up, dal prototipo al lancio in produzione. Ad ogni "Stato" corrisponde un oggetto ben preciso: il draft del designer, il mock up, il prototipo, il sample;
      • la Documentazione di Prodotto, che ne descrive caratteristiche tecnico-funzionali e costruttive, i materiali e le tecnologie;
      • i Dati di Prodotto che viaggiano attraverso i sistemi informativi aziendali, attivando altri processi (codici prodotto, distinte base, ecc.).

Accanto a queste grandezze principali vennero innestati altri processi, fortemente connessi con il processo di sviluppo prodotto: il costing, la ricerca e la selezione dei materiali, le analisi di mercato e la valutazione del marketing.


NPD process (2)

Tale modello permise di evidenziare alcuni aspetti che influivano pesantemente sui costi di prototipazione e sul time to market:

    • tutte le proposte, le idee, le intuizioni e le azioni concepite nelle varie fasi delle attività creative non venivano registrate;
    • l'allineamento dei dati con altri processi ed eventi aziendali era poco affidabile;
    • le fasi di processo venivano realizzate in 3 diversi continenti (Europa, Asia, America), con evidenti difficoltà di linguaggio e di comunicazione.

La frammentazione e l'incompatibilità tra piattaforme distribuite rendeva ancora più complessa e costosa la questione.

 

Attraverso l'uso di questo modello fu possibile raccogliere e registrare informazioni utili per misurare economicamente il processo e di conseguenza per ottenere una riduzione di tempi e costi di progettazione, ma si rischiava però di perdere informazioni utili dal punto di vista della Conoscenza sul Prodotto.

Il rischio venne risolto dalle tecnologie ICT a suo tempo disponibili: venne implementato una Data Base Management System WebBased,  in grado di gestire 'oggetti' di formati e natura differenti (video, foto, disegni e specifiche tecniche, ecc.): il Cloud Computing applicato alla Ricerca e Sviluppo.

Inizialmente  non fu possibile realizzare una sincronizzazione tra lo 'svolgimento delle attività nella realtà' e 'ciò che veniva registrato': in parte per problemi tecnici, ma soprattutto  per la 'resistenza naturale' ad utilizzare uno strumento nuovo, che imponeva logiche di lavoro diverse e presupponeva di rivedere anche il proprio modo di comunicare con i colleghi... un cambiamento non da poco.

Dopo un periodo di assestamento, fu interessante registrare un avvicinamento progressivo al sistema da parte dei singoli e dei gruppi di lavoro: alcuni designer cominciarono a caricare i loro bozzetti, fotografie di mock up, loro appunti e schizzi fatti a mano.

I developer cominciarono a caricare filmati che illustravano la costruzione di una maquette...

Altri cominciarono a registrare le riunioni in cui venivano discussi e sviscerati problemi di natura tecnica e costruttiva: delle vere e proprie 'lectio magistralis' di conoscenza sulla costruzione dei prototipi.

Altri ancora cominciarono a trovare bachi nel sistema, a chiedere nuovi sviluppi e funzionalità che rispecchiassero maggiormente il loro modus operandi.

Il Processo di Progettazione si andava via via allargando e con esso la visione che ciascuno di noi aveva del Processo di Progettazione.

 

Ripenso a Bubble Viewer di Carraro e immagino la possibilità per il designer, per il developer, per il product manager di disporre di telescopi che gli consentano di visualizzare l'evoluzione di un prodotto da differenti punti di vista, riducendo il divario tra i modelli per descrivere la realtà e la realtà stessa.

Nell'esempio qui descritto è l'oggetto dell'osservazione ad essere scomposto: il processo di sviluppo prodotto è una sequenza di sotto processi e attività asincrone. Anche se il processo è descritto nella sua totalità, esso è comunque costruito come 'assemblaggio di sottoprocessi' e quindi gli utenti sono destinati a muoversi entro certi limiti e ne vedono evolvere solo una parte.

Nel "Modello a Bolla" di Carraro il sistema-oggetto non viene scomposto dall'osservatore-soggetto prima di essere descritto. Il sistema in questo caso contiene oggetto e osservatore, il quale in qualità di elemento di quel sistema, può fornirne una o più osservazioni, da uno o più punti di vista.

La differenza non è per nulla sottile e ci è nota osservando per esempio come si sono modificati i modi che utilizziamo per descrivere processi e organizzazioni: sino ai primi anni '90 si usavano modelli lineari e organigrammi, ideonei a descrivere un organizzazione del lavoro strutturata e parcellizzata. Verso la fine degli anni '90 quasi tutte le organizzazioni di sviluppo prodotto avevano optato per una descrizione a matrice.

Ed oggi alcune aziende sono approdate a modelli reticolari o a bubble per descrivere i loro processi e la loro organizzazione attraverso i social network che hanno contribuito a modificare le relazioni tra colleghi e con l'azienda, tra azienda e clienti ....

Le community di sviluppatori, i servizi p2p, stanno favorendo l'introduzione di modelli di collaborazione flessibili ed informali, che ben si sposano con il reale approccio alla progettazione che ha un gruppo di creativi, un gruppo di progettisti, un gruppo di ingegneri, un gruppo di tecnici.

Il mondo delle APP si sta muovendo molto rapidamente, anche se  nell'ambito specifico del Processo di Sviluppo Prodotto e del ciclo di vita non si assiste a scelte organizzative e strumentali che vadano in questa direzione.

Provate a cercare contenuti relativi a "new product development process": il 90% dei risultati somiglierà a quello che avete trovato qui... anche cercando "new product development organization" il risultato non è molto diverso...

Se invece cercate "augmented reality" alla pagina US di Wikipedia  trovate una lista di applicazioni, molte delle quali riguardano il processo di design e sviluppo prodotti.

Per aumentare la percezione e la conoscenza di un processo abbiamo bisogno di nuovi modelli e di nuovi strumenti  e in questo campo ci sarebbero molte cose da fare perchè: "Progettare è facile quando si sa come si fa" (Bruno Munari)

 

 

Questo articolo è tutelato da licenza Creative Commons

Creative Commons

comments powered by Disqus

Sei alla ricerca di uno sviluppatore?

Cerca nel nostro database


SAYSOON S.r.l.

SAYSOON è la nuova Mobile Innovation Solution Factory, start-up del Gruppo GMDE...

Vai al profilo

D-One Software House

Sviluppo applicazioni personalizzate per iPad e iPhone

Vai al profilo

No Bla Bla Marketing

Marketing Outsourcing, Consulting & Projects per aziende alimentari, bevande e largo...

Vai al profilo

Move On

Film al cinema è un applicazione sviluppata da Move On (www.moveon.it) azienda...

Vai al profilo