P.D.M. Product Data Management

Transcript

1 P.D.M. Product Data Management Fonte: PDM...1 Che cosa è... 2 Caratteristiche e moduli funzionali di un sistema PDM... 2 Archiviazione:... 3 Classificazione... 3 Ricerca... 3 Strutturazione... 3 Interdipendenza tra le informazioni... 3 Utenti e ruoli... 4 Filtri e visibilità delle informazioni... 4 Comunicazioni... 4 Supply chain, extended enterprise... 4 Workflow e process management... 4 Storico Configurazioni... 4 Filtri, visualizzazioni Interfaccia con ERP... 5 Interfaccia web... 5 Alcuni aspetti generali da non trascurare:... 5 Funzionalità di amministrazione del sistema... 5 Sicurezza... 5 Program & project management... 5 Supply chain, extended enterprise... 5 BRAIN SYSTEM Srl Sede legale e operativa: Via Provinciale, Dalmine (BG) - Tel Fax info@brainsystem.org CF e PIVA n Reg. Impr. BG /1997

2 Che cosa è L'argomento di questa sezione è il PDM; per prima cosa cercheremo di definire il termine. All acronimo corrispondono vari significati che dipendono dalla chiave di lettura, che cambia con l evoluzione dei concetti su cui si basano i sistemi di PDM. Si va dal semplice archivio di documenti tecnici; a infrastruttura di supporto all'introduzione nel processo di sviluppo prodotto di nuovi paradigmi, quali es. concurrent engineering. Un primo modo di vedere le cose è: PDM = Product Data Management, cioè strumenti e metodi per gestire tutti i dati necessari alla definizione di un prodotto industriale. Una seconda definizione, presa in prestito da CIMDATA ( una società di consulenza statunitense specializzata nelle problematiche dello sviluppo prodotto, è: "an enabling technology for implementing many of the broad corporate re-engineering initiatives that manufacturers are currently instituting such as concurrent engineering and process re-engineering" traducibile in: "una tecnologia che consente l implementazione di molte delle iniziative di livello aziendale che le imprese stanno correntemente affrontando, quali concurrent engineering e re-ingegnerizzazione di processi". Un ulteriore sviluppo del modo di vedere la questione, sempre secondo CIMDATA, considera PDM come parte della strategia cpdm (collaborative Product Definition Management; discusso nell'articolo "10 Trends nel cpdm" di ED Miller). In tutti i casi (e nelle molteplici variazioni sul tema), ci si focalizza principalmente su un concetto: come condurre e con quali strumenti gestire il processo di sviluppo prodotto; cioè come organizzare le informazioni necessarie a definire, produrre e manutenere un prodotto industriale, e come portarle al personale interessato. L'obiettivo a cui tendere, è la possibilità di gestire in maniera organica le informazioni relative all intero ciclo di vita del prodotto. Nel seguito di questa sezione, si parlerà quindi di PDM inteso come strumento informatico, ma anche più in generale dell insieme di strategie e metodi a supporto dello sviluppo prodotto che fanno uso di tale strumento (e delle tecnologie e degli acronimi che nasceranno). Da questa breve introduzione, si può inquadrare la complessità del problema. In particolare il fatto che, sia per la complessità dei nuovi paradigmi in via di introduzione nel mondo dello sviluppo prodotto, che per le disponibilità offerte dalle tecnologie, i cambiamenti connessi con l introduzione di un supporto informatico di tipo PDM non riguardano singole attività e gli strumenti con i quali queste vengono svolte, ma interi processi ed il modo secondo cui questi vengono portati avanti. Cambia quindi anche il problema dell introduzione ed implementazione di nuove soluzioni informatiche, in quanto non si tratta di acquistare lo strumento giusto ed imparare ad usarlo, ma di capire come migliorare un intero processo, e definire poi un supporto. Non si comperano prodotti finiti, ma ambienti nei quali implementare il proprio processo, cioè si acquista un progetto complesso, e intimamente legato alla realtà aziendale corrente. Da quanto detto sopra quindi emerge che porsi il problema di implementare un PDM significa porsi problematiche tecniche (quali e quanti strumenti), ma soprattutto organizzative e strategiche (cosa fare, come, chi fa cosa...). Caratteristiche e moduli funzionali di un sistema PDM Quello che tipicamente si richiede ad un sistema PDM sta più o meno tutto nella frase: "The right information available for the right person at the right time and in the right form". Cioè la giusta informazione deve essere disponibile alla persona giusta, al momento giusto e nel formato opportuno. Per il momento tralasciamo le pesanti Pag. 2

3 implicazioni organizzative del concetto, per fare qualche considerazione sugli strumenti che servono. Archiviazione: Poter archiviare informazioni eterogenee (es. file CAD, fogli elettronici, risultati di analisi, documenti di specifica o procedure, ecc.), in maniera controllata. Molti sistemi fanno uso di un Vault, cioè un archivio protetto, all interno del quale i file vengono criptati. Questo per garantire che il salvataggio e l accesso possa essere effettuato esclusivamente usando l interfaccia PDM, che quindi fa da guida evitando errori, per assicurare la coerenza delle informazioni e l integrità dell archivio. Classificazione Poter classificare e catalogare documenti in modo da renderne facile la ricerca in seguito. Questo si ottiene assegnando alle informazioni degli attributi, gestiti con metadati. Chiariamo il significato di metadati (che vorrebbe dire "dati sui dati"): un file contiene delle informazioni (es. un file CAD contiene una geometria, ecc.) e quelli sono dati. Per le funzioni di archivio e di riutilizzo delle informazioni a valle di chi le ha create, è però necessario avere delle indicazioni sul generico file come entità a se stante (Continuando con l esempio del CAD: Versione, responsabile, n disegno, a quale gruppo funzionale appartiene la parte, ecc.). Questi sono i cosiddetti metadati; cioè tutte le informazioni che servono al sistema per recuperare il file giusto al momento giusto. Essendo i metadati degli attributi da associare ai singoli file per contestualizzarli, va da se che la loro definizione è unica caso per caso (salvo le ovvie comunanze in ambiti simili). Ogni azienda ha un proprio modo di classificare i suoi dati, che è funzione della realtà aziendale specifica e dipende da come è gestito il processo di sviluppo che produce/utilizza questi dati. Tipicamente quindi, due sistemi PDM per due aziende diverse, necessitano di implementazione diversa. Ricerca Poter facilmente recuperare le informazioni che si stanno cercando, attraverso un meccanismo di "Query" facilitata. Con questo si intende la possibilità di effettuare ricerche complesse sul database con l aiuto di una interfaccia "amichevole". Questo serve per dare agli utenti la possibilità di scegliere in mezzo a tutte le informazioni presenti nel database, quella che interessa loro avere. La selezione del file giusto è fatta usando come chiavi i metadati, cioè gli attributi che lo contraddistinguono dagli altri file. Un esempio potrebbe essere la ricerca di tutti i disegni CAD delle parti appartenenti ad un determinato gruppo funzionale. E importante che l utente abbia a disposizione strumenti per la definizione dei criteri di ricerca, che siano facili da usare e di veloce apprendimento. Strutturazione Avere la possibilità di raggruppare e contestualizzare le informazioni all interno di una struttura di prodotto. Le aziende sono abituate a vedere il proprio prodotto con il sistema della distinta base, che gestisce i componenti di un sistema raggruppandoli logicamente, e rappresentandoli tipicamente con grafi ad albero, o comunque con strutture gerarchiche. E importante che l utente possa usare lo stesso criterio e la stessa rappresentazione per muoversi tra i file contenenti le informazioni relative ai diversi componenti. E altresì importante che tali informazioni possano essere ristrutturare a seconda del contesto (es. per le esigenze di progettazione può risultare comodo un raggruppamento ed una strutturazione dei componenti, che non è detto sia altrettanto comoda per le esigenze del montaggio, piuttosto che degli acquisti). Interdipendenza tra le informazioni Avere supporto nel gestire l'interdipendenza tra file diversi. Con l'evolvere della progettazione capita sempre più spesso che un file utilizzi informazioni che risiedono in un altro file (es. verifiche che fanno uso di geometrie tridimensionali). Occorre che il Pag. 3

4 sistema supporti l'utente nella gestione di queste interdipendenze, altrimenti si rischia che qualcuno faccia del lavoro basandosi su informazioni non più valide Utenti e ruoli Chi ha accesso a quali informazioni e con quali diritti (sola lettura, modifica, creazione di nuovi dati, ecc.). E' un aspetto importante per poter effettuare concurrent engineering, cioè rendere parallele alcune fasi dello sviluppo che tradizionalmente erano sequenziali. Questo implica che diversi enti e ruoli debbano vedere le informazioni prodotte gli uni dagli altri, prima ancora che queste siano definitive, conoscendone ovviamente lo stato. Per evitare errori è bene che ogni utente sia "guidato", o meglio, "vincolato" in qualche modo nell'esplorazione e nell'utilizzo delle informazioni, avendo la certezza di non andare per sbaglio a modificare progetti di altri, oppure a basarsi su informazioni non aggiornate nel fare il proprio lavoro. Filtri e visibilità delle informazioni Gestione della visibilità dei dati e delle aree di lavoro private per i progettisti. Questo aspetto ha implicazioni di processo (es. tenere mascherato un disegno fino a che non raggiunge un certo livello di definizione può servire ad evitare che altri lavorino basandosi su informazioni non attendibili), ma anche per questioni organizzative e di sicurezza; basti pensare al fatto che sempre più spesso le aziende lavorano con codesigner, ai quali devono essere forniti gli accessi ai dati rilevanti per il loro lavoro, pur salvaguardando la sicurezza/riservatezza delle informazioni di progetto. Comunicazioni Comunicazione: utilizzo di un sistema di posta elettronica per trasferire informazioni, notificare eventi, ecc. Questo è un altro aspetto legato all'esigenza di lavorare in contemporanea. Per un progettista è importante vedere le parti o i componenti progettati da altri che interagiscono con gli oggetti che sta sviluppando; ma è anche fondamentale sapere quando una di queste viene modificata in un modo che potrebbe invalidare le verifiche da lui fatte fino ad ora. Per poter passare queste informazioni si va da un semplice sistema di posta interna al PDM (in modo che anche le comunicazioni possano venire organizzate dal database), con il quale ogni progettista può notificare agli interessati le modifiche rilevanti, alle funzionalità di "subscribe" vero e proprio, dove è lo stesso interessato a ricevere le informazioni che si "abbona" ad una parte, chiedendo al PDM di notificargli in automatico quando avvengono dei cambiamenti. Supply chain, extended enterprise Poter lavorare nello stesso ambiente indipendentemente dalla locazione fisica. Sempre di più lo sviluppo prodotto si avvale di progettisti esterni, co-designers e fornitori; quindi non è detto che "The right person" stia necessariamente all'interno della nostra azienda. Workflow e process management Le informazioni tecniche subiscono un processo di approvazione, più o meno formale, prima di essere ufficializzate. Una possibilità che viene offerta da molti PDM è la automazione di tale processo. Ad esempio fare in modo che quando un progettista salva un disegno come "rilasciato", il sistema automaticamente lo porti in visione al suo capo, e non appena questo ha salvato la sua approvazione il file venga smistato automaticamente ad archivi, servizi di plottaggio, ecc. Storico. Perché il database non sia un semplice archivio di disegni, ma un vero ausilio alla progettazione, è importante che possa salvare le informazioni relative ai diversi stadi di maturità di un progetto, in modo da tenere traccia delle scelte effettuate nei vari momenti dello sviluppo. Configurazioni. E' spesso necessario dover gestire diverse versioni di prodotto fin dalle prime fasi di sviluppo; per questo occorre poter disporre di una gestione delle diverse configurazioni Pag. 4

5 della distinta base tecnica di un prodotto. Anche se non sono richieste le complesse funzioni di un configuratore commerciale, è importante avere sott'occhio le implicazioni di una scelta ingegneristica su tutti gli ambiti di influenza (es. modifica su un sottosistema che è comune ad una gamma prodotti). Filtri, visualizzazioni. Si intende la possibilità di accedere in maniera differenziata e aggiornata ai dati. Ad es. un responsabile può avere necessità di visualizzare tutti e soli i "disegni" realizzati da membri del suo team, e che siano rilasciati e in attesa della sua approvazione. Interfaccia con ERP. E' importante che i dati dell'ingegneria siano coerenti e interconessi con quelli di tutta l'azienda, in modo da garantire la maggiore continuità e integrazione possibile nell'intero processo aziendale. Questo per rendere possibile una gestione integrata delle informazioni relative all'intero ciclo di vita del prodotto. Interfaccia web. Visto l'uso esteso delle intranet aziendali, che stanno sempre più spesso diventando extranet, estese in alcune parti anche a fornitori e clienti; è importante che il sistema sia in grado anche di presentare le informazioni in un formato compatibile con l'architettura Web; in modo da rendere le informazioni fruibili ad utenti supportati da sistemi diversi e in ambiti differenti. Alcuni aspetti generali da non trascurare: Funzionalità di amministrazione del sistema. Una volta avviato il sistema necessita le ovvie manutenzioni. Deve essere altresì facile gestire il suo evolversi con l'evoluzione dell'azienda (es. nascono nuovi progetti, cambiano le persone, entrano nuovi co-designers, ecc.) Sicurezza Un sistema del genere, una volta a regime si trova ad essere il depositario dei dati, e l'arbitro dei processi; va da sé quanto sia delicata la questione, sia in termini di affidabilità del sistema che di salvaguardia della riservatezza delle informazioni. Program & project management Poter utilizzare le informazioni sugli oggetti in via di sviluppo anche per la gestione dei progetti; ad esempio correlando livelli di completamento degli oggetti in via di sviluppo (da gestire con attributi opportuni) a milestones. Più in generale comunque poter avere una vista del livello di completamento di un progetto complesso per poterla confrontare con quelli che erano programmi, previsioni, obiettivi. Supply chain, extended enterprise Al di là del poter/dover garantire accesso e visibilità ai dati anche a personale esterno all'azienda, lavorare in remoto può spesso implicare complicazioni nell'architettura del sistema (es. necessità di gestire replicazioni in loco dei database, ecc). Fonte: Pag. 5