6 Fluxul documentaiei tehnice depre produs n ntreprinderea virtual lecia 6 6.1 Generaliti, definiii 6.

.2 Stabilirea proceselor ce definesc fluxul de date ntr-o companie 6.3 Iniierea i urmrirea unui workflow 6.4 Managementul fluxului documentaiei tehnice Activitate Scop Este acela de a nva ce reprezint fluxul documentaiei (denumit i workflow) n ntreprinderea virtual. Cum se atribuie, se realizeaz i se urmresc sarcinile (denumite i taskuri) n circuitul informaiilor despre produs. Obiective Dup parcurgerea acestei lecii vei fi capabili s: * definii un flux al documentaiei * iniiai un workflow * revizuii sarcinile dintr-un workflow * s atribuii echipa de validare digital * urmrii stadiul n care se afl un workflow * tergei sarcinile care nu sunt atribuite corect

6.1

Generaliti, definiii

n cadrul unei societi tipice, cu un numr mare de persoane implicate n ciclul de via al produsului, exist multe probleme la nivel inferior, n special n ceea ce privete datele tehnice (despre produs). Frecvent se pierde mult timp cu cutarea acestora. Uneori, informaiile necesare nu pot fi gsite atunci cnd este nevoie de ele. Dac sunt gsite, este posibil ca acestea s nu corespund strii actuale a produsului. De exemplu, schia unei instalaii poate s nu corespund amplasrii ei. Dezvoltatorii nu pot accesa un anumit proiect din mulimea de proiecte existente. Pentru a gsi informaiile necesare, acetia trebuie s caute prin mai multe documente i fiiere electronice, pierznd timp valoros. Studiile indic faptul c 80% din timpul inginerilor proiectani se consum cu activitile de cutare a informaiilor i cele administrative. Acetia elaboreaz noi proiecte ce pot fi aproape identice cu cele existente, dar rezultatul este c, pe msur ce noile proiecte sunt supuse diverselor activiti necesare fabricaiei, sunt generate costuri suplimentare inutile ce sunt suportate apoi pe parcursul utilizrii. Pentru depirea acestor probleme, unii manageri din cadrul companiilor implementeaz sisteme de management al cunotinelor. Dar, pn nu se reuete controlarea datelor tehnice despre produs, este puin probabil ca un sistem de management al cunotinelor s dea rezultatele dorite. Deoarece sistemele informatice genereaz un numr tot mai mare de date, urmrirea locaiei datelor, prevenirea accesului neautorizat i meninerea unor configuraii la zi devin tot mai dificile, dei procedurile de control i gestiune au fost introduse cnd volumele de date erau de mii de ori mai mici. Organizaiile pot avea terabytes, petabytes, exabytes sau chiar zettabytes (1021 bytes) de date. Societile dein sute, chiar milioane de desene. Modelele 3D CAD pot ocupa un spaiu de civa gigabytes. O societate a calculat c avea nevoie de 250.000 de pagini de hrtie pentru descrierea unui produs nou, i c, n medie, fiecare dintre acestea trebuia reprodus de 30 Page1of19Lecia6

de ori. Imprimat pe suport de hrtie, documentaia tehnic pentru un elicopter cntrete mai mult dect elicopterul n sine. Cea pentru un submarin depete 100.000 de desene, de 10 dimensiuni diferite, cntrind peste 5 tone. n 2001, un contract major de externalizare pentru serviciile de documentaie tehnic a fost semnat de Rolls-Royce Pic, o societate internaional productoare de motoare pentru mijloacele terestre, maritime i aeriene. Anual, Rolls-Royce producea 96 de milioane de copii, 20 de milioane de desene tiprite, microfilme i proiecte geometrice, i arhiva peste 30 de milioane de desene. n 2004, UGS PLM Solutions a anunat c soluia sa PLM la MTU Aero Engines ar acoperi managementul a peste 10 milioane de documente, elemente i obiecte accesate de peste 5.000 de utilizatori.

Fig_6_01.tif Circuitul datelor ntr-o companie Introducerea datelor este de cele mai multe ori slab controlat. Este foarte uor de introdus un caracter greit sau de copiat un alt fiier. Datele se pierd uor, putnd fi imposibil de recuperat. Apoi, acestea sunt create din nou, introducndu-se mai multe erori. Produsul greit ajunge la client. Datele de configurare a produsului nu sunt actualizate. Cnd pe teren se descoper o pies defect, trebuie retrase mult mai multe produse dect este necesar. Istoricul proiectului nu este pstrat, prin urmare este imposibil utilizarea experienei anterioare. Din cauza diferenelor dintre programele de aplicaii incompatibile, datele sunt transferate manual ntre sisteme, aprnd erorile. Acestea trebuie corectate, iar corectarea lor trebuie administrat. Aceasta necesit timp i bani. O eroare se strecoar i nu este descoperit dect dup mai multe sptmni sau chiar ani. Corectarea acesteia provoac luni de ntrziere. Descrierile pieselor i listele de materiale elaborate ntr-un sistem CAD pot fi transferate manual ntr-un sistem ERP ntr-un computer ce nu este conectat la computerul CAD. Devizele de fabricaie pot fi diferite de devizele tehnice. Cele dou sisteme pot fi responsabilitatea a dou departamente, organizaii sau societi diferite. Procesele schimbrii n cadrul celor dou organizaii pot fi diferite i nesincronizate. La un moment dat, o anumit schimbare se poate efectua ntr-un sistem, dar nu i n cellalt. Drept urmare, nu toi utilizatorii vor avea acces imediat la cele mai recente informaii. Dac se utilizeaz versiunea incorect a unui design pentru fabricaie timp de cteva sptmni, se pierd mii de dolari. Pot fi pstrate mai multe copii ale informaiilor ce descriu aceeai pies. De multe ori, nimeni nu tie care este copia original. Cnd este necesar efectuarea unei schimbri, este posibil ca anumite copii s nu fie modificate, unii utilizatori s nu fie informai i unele funcii de la nivel ierarhic inferior s nu fie alertate. Sunt produse reviziile vechi, nedorite ale pieselor, n timp ce versiunile noi necesare sunt ignorate. Dac nu exist o versiune principal stabilit a unei anumite informaii i nu exist un proprietar stabilit, toi utilizatorii informaiei respective se vor comporta ca i cum ar fi proprietarii acelei informaii. Fiecare utilizator va defini articolul respectiv pentru a corespunde Page2of19Lecia6

cerinelor lui. Toate definiiile pot fi diferite. Aceste eforturi inutile vor crea confuzie n momentul transferului informaiei ntre utilizatori. ncercrile de a colabora cu un furnizor n faza de proiectare sunt mpiedicate din cauz c transferul unui desen pe suport de hrtie ntre societi dureaz cteva zile (o lun n cazul unui constructor de aeronave). Societile se ateapt tot mai mult ca furnizorii s proiecteze i s produc ansambluri complete alctuite dintr-un numr mare de piese. Dac inginerii departamentului post-vnzri al societii nu au acces la informaiile privind piesele individuale ce formeaz ansamblul furnizorului, pot aprea probleme. Este posibil ca instrumentele de management al resurselor i proiectului s nu fie corelate cu informaiile descriptive. Rezult o suprapunere nedorit a datelor i fluxurilor de lucru, pierznduse timp i bani. n acelai timp, orice ncercare de economisire a timpului, prin rularea diverselor faze ale unui proiect n paralel, duce la haos. Prin urmare, fazele sunt rulate n serie, prelungindu-se ciclurile proiectului. Regulile i procedurile sunt dificil de aplicat. Regulile de proiectare pot fi ignorate deoarece aplicarea lor este imposibil. Exerciiile de planificare a proiectului nu se pot baza pe datele reale obinute anterior, ci se bazeaz pe estimri prea optimiste. Este dificil ca managerii de proiect s fie la curent cu evoluia exact a lucrrilor. Prin urmare, acetia nu pot soluiona problemele de decalare i de alt natur de ndat ce acestea apar. Costurile componentelor pot fi dificil de estimat. Adesea nu exist date relevante disponibile pentru asigurarea unei baze de calcul. Dac totui sunt gsite unele date, se constat c sunt incorecte. Dac se unesc datele din diverse surse, acestea nu au sens. Modificrile tehnice sunt slab coordonate, aprnd posibilitatea introducerii unor modificri nenecesare. Ciclurile de proiectare sunt mai lungi dect este necesar, iar versiunile de date neautorizate sunt obinute din fabricaie, vnzri i suport, provocnd confuzie i pierderi. Timpul pentru elaborarea, aprobarea i implementarea modificrilor devine mai lung dect este necesar. Procesul de modificare poate dura zile, sptmni sau chiar luni, pe cnd timpul de execuie poate fi de cteva minute sau ore. n societile mari, efectuarea unei modificri tehnice cost mii de dolari. Sistemele de control al modificrilor tehnice au adesea un caracter birocratic, complex i lent, necesitnd mult documentaie. Un grup de servicii tehnice central poate avea responsabilitatea, nu i instrumentele, pentru efectuarea modificrii ct mai rapid posibil. Pot fi implicate multe departamente (un productor a constatat c, n funcie de natura modificrii, au fost implicate pn la 16 departamente). Prin urmare, pot fi necesare cteva luni i un numr de cincizeci sau peste cincizeci de documente diferite pentru ca o modificare propus s fie aprobat i inclus n designul produsului. n acest timp, produsul va fi fabricat n continuare cu designul nedorit. Chiar i atunci cnd modificarea a fost aprobat i anunat, pot trece multe luni pn cnd documentaia aferent ajunge pe teren. Deoarece procesul schimbrii i managementului pare s fie ineficient i necesit timp, unele persoane vor ncerca s-l evite. Pentru unele informaii este posibil s nu existe un proces formal de control al schimbrii. Unele societi au chiar un proces al modificrii formal ce respect standardul ISO 9000 -, dar conducerea nu se ateapt ca cineva s l utilizeze. De aceea, modificrile minore aduse produselor i desenelor nu pot fi semnalate. Componentele vor fi nlocuite n produsele finale fr ca schimbrile aferente s fie efectuate n programele de testare. Page3of19Lecia6

Nu se va mai putea pstra evidena componentelor exacte chiar i n loturi mai mici de produse. Nimeni nu va observa pn n momentul n care ceva se va defecta sau pn cnd va fi necesar efectuarea altei schimbri. Atunci va fi necesar depunerea de eforturi inutile pentru descoperirea cauzei problemei. Se va angaja personal tehnic suplimentar pentru a se ncerca prevenirea apariiei altor probleme. ntre departamente sunt dezvoltate comunicri informale pentru a compensa lipsa de comunicri formale adecvate. Se vor pstra unele nregistrri ale acestui tip de transfer i, n cazul absenei unei anumite persoane, gsirea informaiilor importante va fi imposibil.

Fig_6_02.tif Transfer date ntre departamente Obinerea unei anumite informaii poate dura ore, chiar sptmni. Persoana care trebuie s semneze un design este reinut n alt parte cteva ore, iar activitatea este ntrerupt pentru c nimeni nu tie cine altcineva are autoritatea de a semna. Cnd se primesc informaiile, persoanele care le-au primit nu sunt sigure dac au primit versiunea corect. Uneori, la o simpl solicitare de informaii dintr-un sistem, din cadrul aceleiai societi, dar care aparine altui departament, sunt necesare cteva zile pentru obinerea acestora.

Page4of19Lecia6

Controlul configuraiei cedeaz. Documentaia de configuraie nu mai corespunde produsului actual. Apar diferene nejustificate ntre devizele ntocmite n baza proiectrii, planificrii i execuiei. Rezult o cantitate mrit de rebuturi, revizuiri i stocuri. Produsele incomplete sunt asamblate i livrate. Problemele din teren sunt dificil de rezolvat, aprnd ineficiene n managementul pieselor de schimb. Noile versiuni ale programelor informatice sunt introduse fr a se asigura suficient faptul c, de exemplu, datele create cu versiunile anterioare sunt nc utilizabile. Programele sunt insuficient documentate. Modificrile programelor se efectueaz fr un control adecvat al schimbrii. Manualele de utilizare pot fi dificil de neles, fiind elaborate aparent de persoane care nu au utilizat sau vzut produsul. Traduse n alte limbi de persoane avnd cunotine puine despre produs, sau neavnd vocabularul aferent, acestea sunt i mai dificil de neles. Manualele tehnice devin perimate i totui nu sunt actualizate. Datele de suport logistic devin incontrolabile. Configuraiile neadecvat documentate devin dificil de ntreinut. Reaprovizionarea cu piese de schimb devine inadecvat, clienii fiind nevoii s imobilizeze produsele n timp ce se depun eforturi pentru identificarea pieselor de schimb adecvate. La sosirea piesei de schimb necesare, echipamentul de transport i instrumentele de ntreinere nu sunt la faa locului. Informaiile privind problemele ntmpinate cu utilizarea produsului nu sunt transmise dezvoltatorilor, cauznd proiectarea urmtoarei generaii de produse cu aceleai probleme. Dezvoltarea i suportul produsului ntr-o serie ntreag de domenii de fabricaie este ntrziat dintr-o mulime de motive aparent ntmpltoare i minore, dar semnificative din punct de vedere global. Calitatea serviciului i produsului este inconstant, n ciuda vastelor investiii n tehnologie i programe de management al calitii i a perioadei semnificative de timp dedicate managementului.

6.2

Stabilirea proceselor ce definesc fluxul de date ntr-o companie

Majoritatea problemelor prezentate mai sus au legtur ntr-o oarecare msur cu datele tehnice i/sau fluxul tehnologic. Deoarece acestea sunt subiecte care nu apar pe prima pagin a presei de afaceri, este posibil s fie necesar o introducere. Termenul date tehnice include toate datele referitoare att la produs, ct i la procesele utilizate pentru proiectarea, producerea, utilizarea i suportul acestuia. Datele tehnice sunt create i utilizate pe parcursul ciclului de via al produsului. Unele date tehnice (cum ar fi geometria piesei i programele NC) sunt create n cadrul funciei tehnice, unele sunt create n alt parte (de exemplu feedback-ul obinut de la clieni n ncercrile pe teren). Unele dintre aceste date (precum rezultatele analizei circuitului sau efortului) sunt utilizate n cadrul studiului de concepie, altele (precum instruciunile de sudare) n producie, altele (precum instruciunile de instalare) la locaia clientului, altele (precum instruciunile de demontare) la finalul ciclului de via al produsului. Datele tehnice sunt disponibile n multe locaii i pe numeroase medii. Acestea sunt n numr foarte mare (unele societi au milioane de documente pe suport de hrtie i mult mai multe fiiere electronice). Ele sunt transmise sub diverse forme (de exemplu numerice, grafice, alfanumerice). Unii utilizatori ai datelor vor fi din cadrul unei societi, alii din cadrul altor organizaii (de exemplu furnizori, parteneri, clieni i organismele de reglementare). Page5of19Lecia6

Fluxul tehnologic este fluxul de activitate, format din activitile ce creeaz sau utilizeaz datele tehnice. Acesta se intersecteaz cu ciclul de via al produsului. Fluxul tehnologic poate porni din departamentul de marketing definit n mod tradiional i poate continua cu departamentele tehnic, producie i service. Exist de asemenea un flux prin alte organizaii care utilizeaz datele tehnice. Unele dintre aceste activiti se desfoar n cadrul societii, altele n afara ei. Utilizarea instruciunilor de sudare n atelier este o etap din fluxul tehnologic global, la fel ca i utilizarea instruciunilor de ntreinere la locaia clientului. Teoretic, fluxul tehnologic ncepe cu specificaiile produsului iniiale, include utilizarea produsului de ctre client i se ncheie cu retragerea i reciclarea produsului. Practic, nu este att de simplu. Fluxul tehnologic este rareori linear, ncepnd cu o activitate bine determinat i continund n serie cu alte activiti bine determinate, pn la o activitate final bine determinat. Este mult mai complex. n general, unele activiti se desfoar n serie, iar altele n paralel. Uneori, urmtoarea activitate poate fi selectat numai dup ce o activitate a fost finalizat, cunoscndu-se rezultatul ei. n unele cazuri, rezultatul unei activiti va nsemna c activitile anterioare trebuie repetate. Fluxul tehnologic depinde de o varietate de parametri precum caracteristicile produsului / pieei, costurile, timpul, resursele, numrul i frecvena repetiiilor, numrul i frecvena modificrilor i amploarea activitilor paralele. Activitile desfurate de o anumit societate vor depinde n mare msur de tipul de produs i poziia societii n lanul de valori. n producie, fluxul tehnologic al unui productor de produse chimice fine va fi diferit de cel al unui productor de produse chimice n vrac. n mod similar, n domeniul fabricrii componentelor discrete, fluxul tehnologic va fi diferit la productorii de aeronave, maini unelte i bunuri de consum durabile. Chiar i n societile din acelai sector, fluxul tehnologic va fi diferit. Diferenele sunt determinate de clientel, ciclurile de via ale produselor, loturile de fabricaie, ratele de lansare a noilor produse i reglementrile speciale diferite, precum i de dimensiunea societii i structura organizatoric. Fluxul tehnologic este caracteristic societii. Nu exist o soluie uoar disponibil care s permit unei societi s-i amelioreze fluxul tehnologic fr s neleag mai nti toate detaliile fluxului su tehnologic. Abordarea modificrilor, att ale specificaiilor procesului ct i ale produsului, difer de la o societate la alta. Modificrile cost bani, timp, necesit repetiii n fluxul tehnologic i un efort suplimentar de management. Dac modificrile de proiectare se produc ntr-o etap avansat n fluxul tehnologic, acestea pot fi extrem de costisitoare, avnd impact asupra produsului, echipamentului de producie i datei de lansare. n cel mai ru caz, clientul va primi un produs viciat. Este important s nelegem unde o societate i definete costurile n fluxul tehnologic i unde sunt create de fapt costurile. n acelai mod, este necesar s nelegem unde se definesc calitatea i ciclurile de fabricaie i unde acestea sunt transformate n realitate. Au fost efectuate diverse studii ale distribuiei costurilor n ciclul de via tradiional al produsului. n mod specific, acestea indic 60-75% din costurile definite (i 1-5% din costurile suportate) n cursul proiectrii conceptuale, i 85-95% din costurile definite (i 10-15% costurile suportate) nainte de punerea n fabricaie. Costul suportat al modificrilor tehnice n cursul proiectrii conceptuale este neglijabil n comparaie cu cel al modificrilor dup lansare. Soluionarea unei probleme de proiectare dup lansarea unui produs este adesea de mii de ori mai costisitoare dect prevenirea acesteia pe parcursul proiectrii iniiale. Cifrele de mai sus pentru costurile de producie nu iau n considerare utilizarea produsului de ctre client. n mod normal, aceasta este faza cea mai lung din viaa unui produs. Unele produse necesit foarte mult suport i ntreinere. Costul de ntreinere i al pieselor de schimb Page6of19Lecia6

poate depi costul de achiziie al produsului. De exemplu, companiile aeriene cheltuiesc, n general, pe piesele de schimb pentru motor de dou sau trei ori preul de achiziie al motorului. Activitile de suport i ntreinere pot schimba n mod semnificativ distribuia costurilor ciclului de via, reducnd adeseori i mai mult procentajul costurilor suportate n cursul fazelor timpurii, de dezvoltare. Acestea ar trebui considerate ca fcnd parte din ciclul de via al produsului i avute n vedere la luarea deciziei de mbuntire a fluxului tehnologic i de alocare a resurselor. 6.3. Iniierea i urmrirea unui workflow (flux de date) n funcie de specificul companiei i de tipurile de produse proiectate, un flux al documentaiei tehnice poate fi iniiat de mai multe persoane, de la eful proiectrii, departamentul de marketing unde se stabilesc cerinele despre produs i pn la directorul tehnic al companiei. Aplicaiile PDM permit urmrirea fluxurilor datelor n ntreprinderea virtual, astfel nct n orice moment se poate identifica locul n care se afl un document, sau cine a fcut ultimele modificri.

Fig_6_03.tif Exemplu iniiere flux de date Managementul fluxului tehnologic este pentru societi la fel de important ca i managementul datelor de produs. Doar c este att de uor pentru societi s se cufunde n problemele numeroase i foarte vizibile de management al datelor tehnice, nct neglijeaz fluxul tehnologic. i dac neglijeaz acest flux tehnologic, probabil c nu vor realiza obiectivele lor PLM, cum ar fi reducerea termenelor de dezvoltare a produsului i a costurilor de management al modificrii tehnice. n societi care nc au un flux tehnologic tradiional, secvenial, ineficienele fluxului tehnologic pot reduce la zero beneficiile managementului datelor ameliorate. Produsul pe care clientul l va primi n final este proiectat i fabricat prin activitile fluxului tehnologic. Aceasta nseamn c att calitatea, ct i costul produsului sunt funcii ale fluxului Page7of19Lecia6

tehnologic. Perioada de timp cuprins ntre momentul apariiei primei idei pentru un produs i momentul primirii produsului de primul client depinde de eficiena fluxului tehnologic. Deoarece fluxul tehnologic afecteaz costul i calitatea produsului, precum i timpii de fabricaie i timpii globali de execuie, societile ce se confrunt cu competitori ce fabric produse de calitate superioar ntr-un timp mai scurt i la un pre mai mic trebuie s i mbunteasc fluxul tehnologic. nainte de a putea face acest lucru, societile trebuie s neleag mai nti fluxul tehnologic i s l controleze. Dac nu reuesc s l controleze, acestea nu vor putea spera s l mbunteasc i, prin urmare, s-i amelioreze controlul asupra produsului i s mbunteasc serviciul oferit clienilor. Pentru societile cu un flux tehnologic tradiional format din etape independente secveniale (de la cerina clientului la proiectare conceptual - la design preliminar - la analiz - la design detaliat - la planificarea proceselor - la achiziie - la planificarea produciei - la producie - la controlul calitii - la teste pe teren - la suport - la retragere) nu este dificil s neleag originea problemelor. Separrile, etapele superflue i activitile ineficiente din cadrul fluxului tehnologic contribuie la prelungirea inutil a termenelor de execuie, creterea costurilor i reducerea calitii. n cazul fluxului tehnologic tradiional, estimarea exact a costurilor i termenelor de execuie la nceputul procesului este imposibil deoarece nimeni nu tie ce se va ntmpla de fapt. n orice etap a fluxului tehnologic, persoanele implicate nu dein toate cunotinele i experiena necesare, i de aceea fac presupuneri, obinnd un rezultat eronat. Ulterior, undeva n cadrul secvenei este necesar o corectare. Procesul revine la etapa respectiv, pierzndu-se timp. n unele cazuri, procesul necesar modificrii dureaz la fel de mult ca dezvoltarea iniial. Procesul necesar modificrii este att de complex nct este necesar inserarea procedurilor de aprobri birocratice ntre etapele fluxului i administrarea schimbrilor. ntr-o societate, au fost necesari peste 20 de manageri pentru aprobarea modificrilor i etapelor individuale. Aceasta nu a nsemnat numai pierderea timpului, ci i prelungirea perioadei de dezvoltare. n multe industrii, timpul de lansare pe pia este un parametru cheie. O depire a acestuia cu ase luni va determina o reducere a vnzrilor i va avea un efect negativ asupra clienilor. n multe industrii, timpul de lansare pe pia este parametrul cheie, iar prelungirea ciclului de dezvoltare duce la scderea important a profiturilor. Majoritatea societilor sunt organizate astfel nct s asigure managementul etapelor individuale din fluxul tehnologic, dar fluxul tehnologic global nu este gestionat pe parcursul ciclului de via. Activitile individuale sunt gestionate cel mai bine la nivel departamental sau funcional, i este posibil s nu ia n considerare fluxul global sau necesitile detaliate ale altor grupuri. Deseori nu exist responsabil cu fluxul tehnologic global. Este posibil s existe proprietari de proces dar s nu existe niciun proprietar al ciclului de via al produsului. Problemele nu sunt nelese n detaliu i nu sunt abordate din punct de vedere global. Prin urmare, nu sunt soluionate. Fluxul tehnologic global rmne ineficient, neeconomic i incontrolabil. n aceast situaie, fluxul nu poate fi optimizat. Dac se obine controlul asupra fluxului tehnologic global, timpii de execuie se reduc, calitatea crete i costurile scad. Dac fluxul tehnologic este controlat, buna nelegere a costurilor produsului final se realizeaz la nceputul procesului de dezvoltare a produsului. Pot fi efectuate estimri corecte ale termenelor de execuie. 6.4 Managementul fluxului documentaiei tehnice (workflow)

Managementul trebuie s controleze datele tehnice despre produs. Datele tehnice stau la baza ciclului de via al produsului n mediul actual informatizat, bazat pe informaii, dar puine societi dein controlul strns al acestora. Datele tehnice sunt dispersate n multe locaii. Acestea se gsesc pe suport de hrtie, microfilm, cartele perforate i computere. Se pstreaz mai multe Page8of19Lecia6

copii ale datelor, cu versiuni diferite ale datelor ce ar trebui s fie identice. Deoarece societile investesc ntr-un numr tot mai mare de computere, pstrarea controlului datelor tehnice ale societii, o resurs valoroas a societii, va deveni mai dificil. Pstrarea unor piste de audit pentru identificarea sursei problemelor legate de produs devine i mai dificil pentru societi, ce au obligaia respectrii cerinelor legale privind trasabilitatea. Cerinele de trasabilitate sunt tot mai mari. De exemplu, Legislaia alimentar a Uniunii Europene prevede ca pn n luna ianuarie a anului 2005 toate produsele alimentare s poat fi urmrite. Societilor le este tot mai dificil s determine care este versiunea principal a datelor tehnice este un model sau un desen informatic, este imaginea scanat a unui document, sau este documentul n sine? Pe msur ce o cantitate mai mare de date este utilizat n comun cu furnizorii, apar ntrebri similare cu privire la care societate deine versiunea principal. Procedurile trebuie definite pentru a indica modalitatea n care att societatea care deine versiunea principal, ct i societatea care deine versiunea secundar pot face schimbri. Sistemele de trasabilitate ofer informaii n legtur cu calea unui anumit produs / ingredient sau lot de produse /ingrediente de la productor, prin toate etapele intermediare, pn la clienii finali. Managementul trebuie s se asigure c datele tehnice utilizate au o calitate superioar. Fr informaii fiabile, exacte, furnizate la timp, managerii i utilizatorii nu pot lucra eficient. Controlul calitii pe date ce se deplaseaz n mod invizibil n jurul reelelor este dificil, prin urmare calitatea trebuie ncorporat. Aceasta se poate efectua numai prin aplicarea procedurilor adecvate i o cultur a societii ce penalizeaz lucrrile de calitate inferioar. Crearea i propagarea erorilor trebuie prevenite. Un utilizator poate introduce cu foarte mare uurin o eroare n datele tehnice. Odat introdus, gsirea erorii poate fi dificil, iar eliminarea efectelor acesteia poate fi i mai dificil. Managementul trebuie s se asigure c datele tehnice sunt reutilizate i c acestea pot evolua. Este inutil s ncercm s reinventam roata la nesfrit, dar designurile trebuie revizuite pentru a ndeplini n continuare cerinele clienilor. S-a afirmat c reutilizarea informaiilor este unul dintre beneficiile majore ale utilizrii CAD, dar n practic acestea s-au reutilizat mai puin dect s-a preconizat. Motivul a fost dificultatea utilizatorilor n a gsi aceste date, chiar i atunci cnd sunt contieni c datele tehnice adecvate exist. Este posibil ca acestea s fie undeva n sistemul CAD, sau n sertarul cuiva, sau undeva n atelierul central de proiectare. Puini utilizatori sunt pregtii s petreac ore, chiar zile, n cutarea datelor vechi. n schimb, acetia iau o foaie curat sau un ecran gol i deseneaz o pies nou. Managementul trebuie s se asigure c abordarea datelor tehnice include att datele existente, ct i datele ce vor fi create pe viitor. Utilizarea i managementul datelor de produs nu sunt activiti noi i nu ar trebui tratate ca atare. Majoritatea societilor au o vast cantitate de informaii prinse n datele existente. Una dintre provocrile majore este combinarea abilitii de a ndeplini necesitile actuale i viitoare n mod eficient cu capacitatea de a reutiliza datele tehnice existente. Managementul trebuie s se asigure c datele tehnice sunt sigure. Utilizatorii individuali pot fi ngrijorai de faptul c un coleg le-ar putea terge munca neintenionat. Societile pot fi ngrijorate c drepturile de acces acordate furnizorilor de ncredere pot fi descoperite cumva de competitori lipsii de scrupule. Companiile multinaionale importante ce transmit informaii descriptive prin satelit ntre locaiile din diverse continente se ntreab ct sunt de sigure datele lor tehnice. Managementul trebuie s se asigure c informaiile confideniale sunt protejate mpotriva accesului neautorizat. Page9of19Lecia6

Managementul va trebui s fac datele tehnice disponibile utilizatorilor cnd acestea sunt necesare, altfel se va pierde timp valoros. Dac managementul dorete ntr-adevr s reduc timpii de execuie, acesta va trebui s scoat pierderile din fluxul tehnologic. Rearanjarea documentelor administrative va trebui eliminat. Tehnici de tipul exact la momentul potrivit (Just In Time) (JIT), aplicate cu succes la nivelul atelierului, vor trebui aplicate n cadrul fluxului tehnologic. Datele tehnice trebuie transmise fr probleme n organizaie. Obiceiurile vechi de cutare a datelor ore sau zile n ir vor trebui s dispar. Datele tehnice puse la dispoziie vor fi, bineneles, datele corecte, n caz contrar, se va pierde i mai mult timp pn la gsirea versiunii corecte. n acest context, un utilizator poate s nu fie numai persoana care lucreaz la civa metri deprtare de locul n care sunt nmagazinate datele, acesta poate fi o persoan din alt organizaie, din cealalt parte a lumii, caz n care posibilitatea pierderii multor ore de munc sunt mari. Managementul trebuie s controleze fluxul tehnologic. Resursele (umane i sistemele) trebuie gestionate mai bine. n multe societi, puine persoane pot descrie ciclul de via al produsului, i mai puine tiu care este motivul pentru care acesta ia forma pe care o are. n majoritatea cazurilor, fluxul nu este rezultatul unui design elaborat, ci al unei lungi serii de reorganizri minore determinate de schimbri n cadrul structurilor departamentale, ale caracteristicilor produsului i resurselor umane. Managerii trebuie s efectueze o revizuire a fluxului tehnologic actual de la ideea iniial de produs pn la suportul i utilizarea de ctre client i eventuala retragere i evacuare a acestuia. Aceasta le va asigura o baz solid pentru mbuntiri. Activitile ce nu adaug valoare trebuie eliminate, iar activitile ce au fost desfurate anterior n serie trebuie, oriunde este posibil, desfurate n paralel. Managementul schimbrilor, modificrilor, versiunilor i variantelor va trebui optimizat. Dac managementul configuraiei nu este mbuntit, creterea continu a numrului de schimbri i de versiuni diferite de produse va cauza pierderea controlului configuraiei. Tehnicile de inginerie simultan, ce implic activiti paralele, nu vor funciona eficient dac fluxul tehnologic nu este sub control i nu sunt identificate proprietatea asupra datelor i drepturile de utilizare. Tehnicile de proiectare pentru fabricaie i tehnicile similare, ce au ca obiectiv implicarea din timp a personalului de producie n procesul de proiectare, pot beneficia numai de un flux tehnologic clar definit i de sigurana c toate prile utilizeaz cea mai recent versiune a datelor tehnice.

Page10of19Lecia6

Activitate Activitatea 6-1: Iniierea unui workflow Activitatea 6-2: Proiectarea Activitatea 6-2: Verificarea Activitatea 6-3: Aprobarea n aceast activitate de la lecia 6 ne propunem s automatizm unul dintre procesele dintr-o companie (cel mai simplu exemplu de proces), care se desfoar n cadrul departamentului de proiectare. Presupunem c avem urmtoarele persoane (fictive) n companie: Ion Popescu manager de proiect user ID: ion.popescu password: ion.popescu Andrei Georgescu - eful departamentului de proiectare User ID: andrei.georgescu Password: andrei.georgescu Vasile Ionescu inginer proiectant User ID: vasile.ionescu Password: vasile.ionescu n figura de mai jos este evideniat fluxul documentelor n departamentul de proiectare ntre persoanele enumerate mai sus.

Fig_6_04.tif Structur workflow

Page11of19Lecia6

Activitatea 6-1: Iniierea unui workflow

Ne conectm la aplicaia Teamcenter folosind utilizatorul Ion Popescu

Fig_6_30.tif Pasul din workflow * extindem folderul Newstuff i gsim obiectul 000128/A Produs * selectm revizia A * din meniul File New alegem Workflow Process * n fereastra care apare selectm Process Template: Proiectare * facem click pe butonul Process Template pentru a vizualiza circuitul documentelor

Fig_6_05.tif Structur circuit documente Atribuim sarcini persoanelor din departament folosind butonul Assign All Tasks * atribuirea sarcinilor de proiectare * click Proiectare Page12of19Lecia6

* se selecteaz persoana Vasile Ionescu din cadrul departamentului Engineering n fereastra Organization * click butonul Add

Fig_6_06.tif Atribuirea sarcinilor de proiectare * atribuirea sarcinilor de verificare * selectarea din cadrul cmpului Verificare a opiunii Engineering/Designer/1 * din fereastra Organization selectm din departamentul Engineering persoana Andrei Georgescu * click Add * atribuirea sarcinii de aprobare * selectarea din cadrul cmpului Aprobare a opiunii Project Administration/Project Administrator/1 * din fereastra Organization selectm din departamentul Project Administration persoana Ion Popescu * click Add

La final trebuie s avem urmtoarea fereastr

Page13of19Lecia6

Fig_6_07.tif Atribuirea sarcinilor Dup atribuirea sarcinilor se face click OK la fereastra New Process Dialog. Verificm nceperea workflow-ului fcnd click stnga pe butonul My Worklist

din fereastra stng a aplicaiei Teamcenter, n seciunea Quick Links

Fig_6_08.tif Urmrirea sarcinilor n fereastra de mai sus avem: * Task to Perform unde se regsesc sarcinile pe care trebuie s le ndeplinesc * Task to Track unde se regsesc sarcinile pe care trebuie s le urmresc nchidem aplicaia Teamcenter.

Page14of19Lecia6

Activitatea 6-2:

Proiectarea

Ne conectm la aplicaia Teamcenter folosind utilizatorul Vasile Ionescu

Fig_6_31.tif Pasun din workflow * deschidem din seciunea Quick Links fereastra My Worklist

Fig_6_09.tif Task to Perform * extindem Task to Perform i observm c avem de proiectat produsul 000128 * facem click pe butonul Viewer din fereastra principal pentru a vizualiza sarcina de ndeplinit * dup ndeplinirea sarcinii facem bifm butonul Complete * click butonul Apply * observm c dispare sarcina din Task to Perform, aceasta se transmite mai departe la verificare

Fig_6_11.tif Sarcina de ndeplinit dispare din Task to Perform nchidem aplicaia Teamcenter Page15of19Lecia6

Activitatea 6-3 Verificarea Ne conectm la aplicaia Teamcenter folosind utilizatorul Andrei Georgescu

Fig_6_32.tif Pasul din workflow * deschidem din seciunea Quick Links fereastra My Worklist * verificm din Task to Perform sarcinile de ndeplinit * observm c avem de verificat proiectul 000128

Fig_6_12.tif Seectarea sarcinii de ndeplinit * selectm sarcina de verificat * facem click pe butonul Viewer * n fereastra principal avem posibilitatea de a lua o decizie n ceea ce privete proiectul verificat. Exist 3 posibiliti: nici o decizie, respingerea proiectului sau aprobarea proiectului. * facem click pe linkul No Decision, apare fereastra Signoff Decision

Fig_6_13.tif Luarea deciziei n urma verificrii Page16of19Lecia6

* click Approve * click OK * sarcina dispare din Task to Perform i se transmite automat spre aprobare Dac selectm Reject, sarcina se ntoarce npoi de unde a venit (de la proiectare) pentru realizarea modificrilor nchidem aplicaia Teamcenter

Activitatea 6-4 Aprobarea

Ne conectm la aplicaia Teamcenter folosind utilizatorul Ion Popescu

Fig_6_33.tif Pasul din workflow * deschidem din seciunea Quick Links fereastra My Worklist * verificm din Task to Perform sarcinile de ndeplinit * observm c avem de aprobat proiectul 000128

Fig_6_14.tif Aprobarea proiectului * selectm sarcina de ndeplinit, aprobarea proiectului 000128 * click butonul Viewer Page17of19Lecia6

* click No Decision * n fereastra Signoff Decision selectm Approve pentru a aproba proiectul * click OK

Fig_6_15.tif Decizia de aprobare Dac selectm Reject, sarcina se ntoarce npoi de unde a venit (de la verificare) pentru realizarea modificrilor nchidem aplicaia Teamcenter

Page18of19Lecia6

Rezumat n aceast lecie am nvat ce sunt fluxurile de date (workflow), cum se creaz un circuit al documentaiei tehnice despre produs n ntreprinderea virtual. De asemenea am nvat: * cum se iniiaz un workflow n departamentul de proiectare, de ctre managerul de proiect * cum se atribuie sarcinile ctre persoanele din departament * cum se trimite proiectul de la proiectare spre verificare * cum se verific un workflow de ctre persoana care este responsabil (eful proiectrii) * cum se aprob un proiect

Page19of19Lecia6