Cap.1 Definire PDM. Scop.

Obiective

1.1. Definitie.

Product Data Management – PDM. Concept de baza care include managementul

documentelor si care asigura si managementul de produse.
Aplicațiile PDM au dezvoltat o nouă metodă de a organiza informațiile în formate
diferite, CAD și EDM, într-o singură bază de date. PDM a propus un mod nou de a organiza
diferitele tipuri de formate CAD pe care o organizație le produce într-un timp destul de mic.
PDM încorporează anumite procese sub forma unor workflowuri (fluxuri de informații). Pe
măsura dezvoltării sistemelor PDM, a fost necesară posibilitatea de configurare a acestor
sisteme, astfel încât să permită implementarea în companii cu diferite domenii de activitate, dar
și de a permite implementarea proceselor și practicilor din cadrul companiei.

1.2. Arhitectura.
1.3. Avantaje/Dezavantaje.

Există în prezent sisteme informatice de pe piata care contribuie la îmbunătăţirea

fluxului, calitatea şi utilizarea informaţiilor în întreaga companie de inginerie. Aceste sisteme
oferă îmbunătăţirea gestionarii a procesului de inginerie printr-un control mai bun al datelor, a
activităţilor ingineresti şi schimbări de configuraţii de produs. Acestea oferă suport pentru
activităţile echipelor de produs şi pentru tehnici de inginerie.Sistemele PDM pot ajuta la:

 reducerea costurilor de inginerie de cel puţin 10%

 reducerea ciclului de dezvoltare a produsului cu cel puţin 20%
 reducerea schimbărilor de inginerie de manipulare timp de cel puţin 30%
 reducerea numărului de modificări de inginerie de cel puţin 40%
 reducerea timpului necesar pentru a introduce noi produse
 reducerea costurilor de dezvoltare de noi produse
 reducerea costurilor de produse noi
 îmbunătăţirea calităţii produselor şi serviciilor

Dezavantajele au doar caracter funcţional şi se evidenţiază în cazul în care sistemul

suferă o pană de curent, ceea ce inseamnă că nu se pot accesa şi nu se pot introduce date pe acest
interval de timp. Pentru a contracala aceste situaţii neprevăzute şi creşte siguranţa proprie se
recomandă utilizarea unui acumulator la care este legat serverul central, sau generator de curent
pe bază de conbustibil. Prin aceste două variante în caz de întreruperea furnizării de curent se pot
rezolva totuşi situaţiile de urgenţă.

1.4. Scopuri.
 Intr-o perioada in care succesul fabricarii depinde din ce in ce mai mult de viteza cu care
o companie creaza noi produse, sistemul PDM are un rol important.

Sistemul PDM tratează aceste informaţii de inginerie ca o resursă importantă, care este
utilizat de mai multe funcţii într-o societate. Pe termen lung, sistemul PDM va permite
companiilor pentru a obţine controlul asupra tuturor informaţiilor de inginerie şi de a gestiona
procesul de inginerie global.Aceste caracteristici se setaza în afară sistemelor de CAD, cum ar fi
scopul de a îmbunătăţi productivitatea sarcinilor individuale într-o zonă funcţională. Privit ca
sistem de prelucrare a datelor, PDM merge dincolo de programele individuale de aplicare, cum
ar fi CAD şi NC şi a sistemelor de management de proiect.

Sistemul PDM este nucleul ce controleaza informatia in inginerie pe toata durata de viata
a produsului.Alte sisteme care folosesc date de inginerie, precum CAD,NC, planificarea
procesului, MRP si serviciul de teren vor fi integrate in acest nucleu.

Acest sistem abordează aspecte cum ar fi controlul, calitatea, reutilizarea, securitatea şi

disponibilitatea datelor de inginerie.Aceasta va ajuta la rezolvarea multor probleme, iar pentru
cei care-l stapanesc, va oferi noi oportunităţi strategice. Introducerea unui PDM va dezvălui
multe probleme asociate cu utilizarea de informaţii de inginerie.Cu toate acestea, scopul
primordial al unui sistem PDM este de a gestiona datele şi fluxul de lucru asociate pentru a
rezolva toate problemele care apar în Departamentul de Inginerie, precum şi altele care ar putea
contribui inutil la cicluri lungi de dezvoltare a produsului. Alte acţiuni vor trebui luate pentru a
reduce aceste probleme, cum ar fi introducerea de inginerie simultană. Sistemul poate sprijini
aceste acţiuni, dar nu poate rezolva automat problemele.

Pentru cei ce isi doresc sa puna in aplicare sistemul PDM, beneficiile sunt evidente.In
companiile lor, îşi dau seama că ingineria de date,procesul de proiectare sunt scăpate de sub
control şi atunci sunt necesare acţiuni corective.

Cap.2. Functionalitati de baza.

In cazul desfasurarii activitatii de proiectare in cadrul unei echipe, nu mai este posibil
managementul de proiecte (exclusiv) prin mecanisme Windows. Asigurarea acestei
functionalitati impune o anumita organizare a acestor informatii, diferita de cea asigurata implicit
de aplicatiile CAD. Pentru aceasta este necesara o aplicatie specializata, din clasa PDM (Project
Data Management), din care face parte si SmartDoc.

Managementul proiectelor/documentelor are doua niveluri de lucru:

 Nivel I – control versiune (fara flux de lucru):

 Mapare proprietati documente;
 Control versiune (check out; check out editie; check in).
 Incarcare/descarcare proiecte in BDF;
  Nivel II – control trasabilitate (flux de lucru):
 Stabilirea de roluri;
 Alocarea de fluxuri;
 Alocare de sarcini catre utilizatori;
 Management proprietati documente.

Management PDM - nivel I

Un proiect Solid Works este organizat pe statia de lucru. Pentru a putea face
managementul proiectului este necesar ca acest proiect sa fie depus (incarcat) in BDF. Simultan
are loc si un transfer bidirectional intre proprietatile fiecarui document din proiectul Solid Works
si proprietatile entitatii “Document” din SmartDoc (stabilite la definirea claselor in
SmartPlm/Administrare). Aceste proprietati vor fi utilizate ulterior in procesul de management
(cautare dupa o anumita prop., filtrare etc.). Acest transfer de proprietati are loc pe baza unei
mapari de proprietati si a unui sens prioritar de completare.

Ca urmare, in managementul de nivel I sunt disponibile urmatoarele functionalitati:

 Setare cale de lucru;

 Mapare de proprietati;
 Incarcare/descarcare proiect/documente;
 Control versiune proiect/document.

Setare cale de lucru

Setarea caii de lucru este o functie de baza in managementul documentelor. Setarea caii
de lucru se face indicand directorul radacina al proiectului sau al (sub)ansamblului care contine
documentul. Setarea caii de lucru se face de catre fiecare utilizator de pe fiecare statie de lucru.
Calea de lucru setata la incarcare de o statie se pastreaza si ramane valabila si la descarcare, in
orice alta situatie este necesara si la descarcare.Pe baza setarii caii de lucru SmartDoc poate
prezenta status/ul fiecarui document de pe statia de lucru in raport cu documentele din BDF.

Setarea caii de lucru se face invocand functia SmartDoc/Setare cale de lucru.

Note.

1. SmartDoc permite setarea unei cai de lucru pentru oricate proiecte definite in spatiul de
lucru.

Mapare proprietati documente

Maparea proprietatilor apare la orice incarcare de proiect (incarcare proiect/assy/prt), sau la
incarcarea de structurii de produs. Maparea presupune un tabel cu trei coloane:

 Proprietati aplicatie;
 Stabilire sens de scriere a valorii de proprietate;
  Proprietati document BDF;

In general, exista exemple de mapari predefinite in faza de implementare, dar utilizatorul

are posibilitatea de a crea o mapare noua sau de a actualiza o mapare existenta.

Maparea apare automat la import proiect/produs. Prin SmartDoc/Functionalitati/Mapare

proprietati se pot vizualiza/edita mapele de proprietati existente sau se poate crea una noua.

Incarcare/descarcare documente
Incarcarea (upload) de documente reprezinta operatia de baza in managementul
documentelor si presupune crearea unei copii a documentelor si a structurilor de
directoare&documente de pe statia curenta, in BDF. Asa cum s/a precizat, incarcarea are loc
simultan cu actualizarea unor proprietati de documente conform maparii prestabilite. Incarcarea
poate avea loc din SmartDoc plugin sau din SmartDoc si poate fi la nivel de fisier ansamblu sau
la nivel de fisier/document. Se precizeaza ca numai din SmartDoc plugin incarcarea se face
pentru documentul curent deschis, impreuna cu toate referintele sale, numai strict documentele
compatibile cu aplicatia din care se invoca (MS Office, Solid Works etc.). In consecinta, la
terminarea incarcarii se poate face si incarcarea celorlate tipuri de documente aflate in spatiul de
lucru. SmartDoc incarca documentele bazat pe structura de directoare mapata fara a putea tine
seama de referintele existente intre diversele fisiere.

Incarcarea unui proiect se invoca din SmartDoc/Incarcare fisiere pentru a incarca toate
fisierele unui proiect. Pentru incarcarea unui document de tip ansamblu sau componenta se face
mai intai navigare in structura de directoare a proeictului selectare document si se da meniu
contextual de incarcare. La limita un fisier poate fi incarcat si prin mecanismul Windows de
drag&drop in directorul specificat. Descarcarea (download) este operatia inversa incarcarii.
Meniurile si modul de lucru sunt absolut asemanatoare.

Control versiune
Din momentul in care un document sau documentele unui proiect sunt incarcate se poate
asigura trasabilitatea si controlul versiunii acestora prin urmatoarele mecanisme:

 Check out – are drept efect descarcarea documentului si referintelor acestuia pe statia de
lucru a utilizatorului in spatiul de lucru setat anterior. Descarcarea poate fi invalidata daca
nu este necesara. Automat are loc incrementarea cu o unitate a reviziei documentelor si
aplicarea maparii setate asupra valorilor de proprietati. Totodata ceilalalti utilizatori le
este schimbat status/ul documentelor. Functia este utilizata atunci cand se doreste
realizarea unei modificari minore pentru unul sau mai multe documente;
 Check out editie - are drept efect descarcarea documentului si referintelor acestuia pe
statia de lucru a utilizatorului in spatiul de lucru setat anterior. Descarcarea poate fi
invalidata daca nu este necesara. Automat are loc incrementarea cu o unitate a versiunii
documentelor si aplicarea maparii setate asupra valorilor de proprietati. Totodata
 ceilalalti utilizatori le este schimbat status/ul documentelor. Functia este utilizata atunci
cand se doreste realizarea unei modificari majore pentru unul sau mai multe documente;
 Preluare in Check out este o functie care permite preluarea starii de modificare permisa
a unui document de la alt utilizator. Presupune descarcarea documentului din BDF si
continuarea modificarilor pe statia curenta. Modificarile de pe statia utilizatorului anterior
vor fi pierdute, daca acesta nu a facut anterior o incarcare a acestora.
 Check in - are drept efect incarcarea documentului si trecerea acestuia in starea de
interzis la modificari si si aplicarea maparii setate asupra valorilor de proprietati. Orice
modificare necesita o noua actiune de Check out sau Check out editie.
Note.

1. Valoarea editiei/reviziei este transmisa prin mecanismul de mapare si la proprietatile

omoloage ale fisierelor si de aici in campurile specifice din document.
2. Pe durata de validare, inclusiv pe perioada de executie a prototipului se recomanda ca
documentele sa ramana in starea Check out.

Management PDM – nivel II

Fluxurile de lucru sunt fluxurile definite in SmartFlow si la care se ataseaza un document
oarecare. Cel mai simplu flux de lucru este fluxul prin care un fisier deschis spre editare si care
este implicit in Check out, trece prin faza de verificare si apoi de aprobare, dupa care este pusin
starea check in sau Check in Editie. In cadrul acestui nivel de management sunt disponibile
urmatoarele functionalitati principale:

 Stabilirea de roluri/drepturi;
 Alocarea de fluxuri;
 Alocare de sarcini catre utilizatori;
 Management automat proprietati documente.

Stabilire roluri/drepturi
Pentru stabilirea de roluri si drepturi se utilizeaza aplicatia SmartPlm/Administrare.
Stabilirea initiala a rolurilor/drepturilor se face la implementare. Crearea/actualizarea de
roluri/drepturi este sarcina Administratorului de aplicatie.

Alocare de fluxuri de lucru

Crearea fluxurilor de lucru se realizeaza de catre aplicatia SmartPlm/Fluxuri. Fluxurile de
baza sunt generate la implementare, Administratorul de aplicatie sau directorul de
proiecte/proiect avand dreptul sa creeze/actualizeze fluxurile de lucru. Alocarea unui flux de
lucru la un document sau mai exact atasarea unui document la un flux se face din SmartDoc, si
are ca efect preluarea documentului si impunerea parcurgerii unor etape de procesare conform
designului din flux.

Ca urmare, daca o entitate (document etc.) este atasata unui flux si transmisa catre un
utilizator pentru a realiza o anumita activitate, atunci aceasta entitate si activitatea respectiva
apare ca fiind de procesat la utlizatorul respectiv. Utilizatorul este anuntat prin mesaj de
atentionare si printr/un proces de clipire al barei aplicatiei SmartPlm. Odata deschisa aplicatia,
utilizatorul poate gasi in zona “Entitati in Check out“ , tab “Activitati“ lista activitatilor care/i
sunt alocate, care este sarcina alocata si eventual alte informatii auxiliare.

Prin localizare, se poate ajunge la entitatea respectiva, in paralel cu deschiderea

modulului din aplicatie, care este potrivit pentru sustinerea activitatii respective. Dupa
solutionare, utilizatorul are libertatea sa transmita entitatea conform designului de flux, catre un
alt utilizator abilitat. Prin aceasta, activitatea respectiva se considera finalizata si utilizatorul
curent este degrevat. Se poate spune ca sarcina curenta a utilizatorului este de aface ca lista de
activitati alocate sa fie cat mai mica, daca se poate zero.

Management automat sarcini/date

Sarcinile de lucru ale unui utilizator pe care trebuie sa le execute asupra unei entitati
(document, proiect etc.) se aloca prin atasarea unui flux de lucru specific la documentul
respectiv.

Deoarece fluxul de lucru sarcinile acestuia pot fi diverse. Totusi se pot astepta
urmatoarele activitati:

 Creare/editare – prin care un document se aloca unui rol pentru a putea fi creat/editat.
Documentul este in starea R/W si in Check out la utilizatorul curent;
 Verificare – prin care documentul in R/O si Check out la utilizatorul curent in vederea
verificarii calitatii. La terminarea verificarii, documentul este acceptat ca valid si transmis
catre rolul de aprobare. Ca urmare campurile Checked by si Checked data sunt
completate automat. Daca documentul nu este acceptat se retrimite spre editare, iar
campurile de mai sus nu se completeaza.
 Aprobare – prin care prin care documentul in R/O si Check out la utilizatorul curent in
vederea aprobarii/validarii. Ca urmare campurile Aproved by si Aproved data sunt
completate automat. Un document valid trece in starea Check in. Daca documentul nu
este acceptat se retrimite spre editare, iar campurile de mai sus nu se completeaza.

Cap.3. Integrarea cu alte aplicatii de tip ERP/MRP

Integrarea în curs de gestionare a datelor de produs (PDM) cu planificarea resurselor

întreprinderii (ERP) va îmbunătăţi dramatic comunicarea între inginerie, productie, achizitii,
vanzari, etc. Istoric, PDM şi ERP au dezvoltat ca sisteme separate sub controlul diferitelor părţi
ale organizaţiei. Multe domenii în care informaţiile controlate de aceste sisteme se suprapun,
cum ar fi gestionarea facturilor de material, au fost, în general, o zonă de conflict care necesită
intervenţie manuală considerabila în scopul de a evita erorile costisitoare. În general, exploatarea
ERP şi PDM de la un singur obiect orientat ar trebui să aibă efect de îmbunătăţire a coordonării
între diferite funcţii, reducând nevoia de intervenţie manuală şi prevenirea erorilor.
 Ideea de bază a PDM este gestionarea informaţiilor asociate cu un produs de la concepţie
la uzura. Astăzi, sistemele high-end sunt considerabil mai flexibile şi pot sprijini practic orice tip
de proces de proiectare. În timp ce funcţionalitatea variază între multe sisteme PDM pe piaţă,
următoarele capacităţi sunt cele mai comune:

1) eliberarea de management de proiectare, inclusiv capacitatea de check-in şi check-out

datele de proiectare, stabilirea de relaţii de date, securitate şi control acces.

2) gestionarea de liste de piese şi liste de materiale, precum şi asocierea relaţie produs

3) definirea fluxului de proces, cum ar fi (inginerie), de management pentru schimbare,

canalizeaza instantaneu o modificare a părţilor corespunzătoare pentru aprobare şi progresele
înregistrate de urmărire a ciclului de aprobare.

4) găsirea şi regăsirea modelor existente, folosind o gamă largă de criterii de căutare.

PDM proliferarea

PDM a devenit o problemă extrem de dificila în ultimii ani, în principal pentru că acesta
oferă instrumentele cele mai promiţătoare să se ocupe de creşterea explozivă a datelor de produs,
care a dus la un număr de tendinţe convergente.Firmele de producţie adopta o abordare mai
orientată spre client prin dezvoltarea de sortimente mult mai largă de produse concepute pentru
diferite nişe de piaţă. În acelaşi timp, produsele devin tot mai complexe, datorită evoluţiei
tehnologice, cererile din partea clienţilor pentru o mai bună calitate, miniaturizare a
componentelor şi integrare a funcţiilor. Creşterea fluxurilor de informaţii de asemenea, trebuie să
se ocupe cu alte probleme, cum ar fi personalizarea geografica şi necesitatea de a respecta
standardele de control ale calităţii (ISO-9000).

Din punct de vedere istoric, sistemele PDM au fost promovate şi controlate de către
departamentele de inginerie în timp ce sistemele ERP au fost considerate, în general, o producţie
sau chiar o pondere globală de responsabilitate a operaţiunilor de afaceri.Ambele tipuri de
sisteme au proliferat şi creşterea domeniului lor de aplicare, problemele au apărut, în special în
zonele în care acestea se suprapun. De departe cea mai mare zona de suprapunere este în dreptul
de proprietate asupra elementului şi datele despre facturi de materiale conexe. Când două sisteme
separate menţin fiecare propria versiune de informaţii vitale, potenţialul de conflict este
întotdeauna prezent. Orice efort pentru integrare în primul rând trebuie să se confrunte cu
problema: care sistem va fi primar şi care va fi secundar? Această problemă poate deveni precum
şi unul din punctele nevralgice în eforturile pentru integrarea proceselor de business cu sistemele
de flux de lucru.
Primi pasi ai integrarii.

În ultimii ani, unii dintre dezvoltatorii de software ERP au început să abordeze aceste
probleme prin integrarea sistemelor de PDM în mediu de fabricaţie. Aceste implementări
timpurii au axat, în general pe automatizarea schimbului de date între PDM şi sisteme ERP. Cele
mai avansate sisteme de astăzi ERP transfera perfect informaţii despre produs şi a documentelor
conexe înainte şi înapoi cu sistemul de PDM. În plus, atunci când produsele noi sunt concepute
datele sunt transferate şi automat fuzionat în sistemul ERP.

O interfaţă de utilizator, între sistemele ERP şi PDM permite controlul şi distribuirea de

informaţii la zonele de proiectare a produsului şi utilizatorilor atât în interior cât şi în afara
organizaţiei.Sesiunile de ERP menţin toate mesajele de eroare şi fişierele jurnal cu privire la
sincronizarea datelor de produs între cele două sisteme.

Conceptul de integrare PDM şi a sistemelor ERP, prin transfer de fişiere este puternic,
dar încă mai încalcă principiul conform căruia datele ar trebui să fie situate într-un singur loc
pentru a păstra dreptul de proprietate şi pentru a evita posibilitatea unor neconcordanţe apărute.
De exemplu, exista posibilitatea ca numerele de serie ar putea fi tratate diferit în diferite sisteme.
Din aceste motive, furnizorii de software ar trebui să se îndrepte spre o situaţie în care toate
datele PDM vor fi stocate în baza de date ERP. Această tendinţă este în legătura cu o mişcare
generală a componentei în rândul furnizorilor ERP. În acest fel PDM va deveni o componentă pe
deplin integrată a sistemului ERP. În practica, mulţi ingineri care au nevoie de acces la informaţii
legate de dezvoltare în sistemele PDM utilizeaza staţii de lucru UNIX în timp ce utilizatorii ERP,
cum ar fi agenţii de cumpărare, oamenii de vanzari, controlorii de atelier.etc, au tendinţa de a
utiliza computerele personale.Pentru abordarea acestor informaţii diferite este nevoie de
platformă pentru a oferi utilizatorilor accesul complet la baza de date ERP/PDM.

Acest concept oferă următoarele avantaje:

1) integrarea deplină a PDM în toate componentele ERP

2) schimbul de concepte PDM între toate componentele ERP

3) utilizarea modelului PDM cu aceleaşi date şi pentru toate conceptele PDM.

 Diagrama de mai sus ilustrează planurile modului in BAAN, de a muta de la nivelul său
actual industria-lider de ERP-PDM pentru o abordare complet modulara, care va oferi PDM pur
si simplu ca un alt serviciu de sistem integrat ERP. Această foaie de parcurs pentru PDM,
sistemul ERP a permis sa ofere o cale de upgrade complet fără sudură din versiunea curentă prin
intermediul sistemului complet modular din generaţia următoare. Piata de desfacere curenta
implica interfata BAAN IVc cu BAAN PDM 5.1. Produsul BAAN IVc are doar existentul modul
Engineering Data Management (EDM), ca parte a PDM. Nici o alta functionalitate PDM nu se
gaseste in BAAN IVc. Pe de alta parte, BAAN PDM 5.1 are mai multe functionalitati PDM,
dintre care multe parti dintre ele, in general, sunt axate pe inginerie, iar altele sunt specifice ERP.
BAAN IVc şi BAAN PDM 5.1 sunt interfaţate prin mijloace BAAN Exchange. Datele
transferate sunt legate strict de EDM.

Urmatoarea imbunatatire va fi o noua versiune a BAAN PDM, oferind funcţionalitate

îmbunătăţită PDM-ului şi care încă este conectat la BAAN IVc. În acelaşi timp, Baan lucrează la
prima sa lansare Baan Series, care va fi un pas important în direcţia unei soluţii ERP complet
modular. Imediat după prima lansare Baan Series,funtionalitatea PDM va fi încorporata pentru
utilizatorii ERP. Această funcţionalitate se va implica în principal in management al schimbarii,
managementul documentelor, managementul dosarelor şi gestionarea fluxului de lucru.In
 curând,dupa aceea, pe deplin funcţionalitatea PDM va fi oferita precum componente PDM care
furnizează servicii pentru toţi utilizatorii ERP.

În plus fata de functionalitatea PDM, componentele vor fi introduse pentru un sprijin total
al inginerilor în mod eficient pentru îndeplinirea lor la locurile de muncă.

Componentele funcţionale pot fi de aşteptat ca:

• proiectarea de elemente de inginerie, facturile de materiale şi rute

• crearea de familii de produse şi posibilităţile legate de configuraţia produsului;

• se leagă de sisteme CAD / CAM, furnizor de componente de management (CSM) a

sistemelor si inginerie de proces asistată de calculator, etc.

Cele mai de sus trei seturi de componente, ERP, PDM şi Engeneering, va funcţiona într-
un mediu integrat pe o bază de date pentru a atinge scopul final de a integra Baan PDM în ERP .

Cap.4. Descrierea functionala pentru Solid Vault

Lista simbolurilor de stare (status) fisiere in SmartDoc

Din momentul in care se face maparea spatiului de lucru cu un director radacina de proiect,
SmartDoc afiseaza status/ul fiecarui document si director sub forma unui icon si al unui text
explicativ.

Acest status permite utilizatorului sa stie exact care este starea fiecarui document si actioneze in
acord cu acest status. Status/ul este extrem de util mai ales in cazul lucrului in echipa.

Icon Descriere Interpretare

Fisierul exista numai local si nu aSe utilizeaza comanda Creare document pentru a
fost incarcat in SmartDoc. adauga documentul in SmartDoc.

Fisierul este in starea de Check in,Se va face “Descarcare ultima versiune” pentru
insa nu a fost descarcat in Workingdirectorul parinte sau “Descarcare” strict pentru
folder (nu exista copie locala aacest fisier pentru a descarca fisierul in working
fisierului). folderul local.

Fisierul este in starea de Check out,Se ajunge in aceasta stare atunci cand fisierul a fost
insa nu a fost descarcat in Workingsters din calea de lucru locala sau cand aceasta a
folder (nu exista copie locala afost modificata.
fisierului).
Se va face “Descarcare ultima versiune” pentru
 directorul parinte sau “Descarcare” strict pentru
acest fisier pentru a descarca fisierul in working
folderul local.

Se ajunge in aceasta stare atunci cand fisierul a fost

sters din calea de lucru locala sau cand aceasta a
Fisierul este in check out la altfost modificata.
utilizator si nu a fost descarcat in
Working folder (nu exista copieSe va face “Descarcare ultima versiune” pentru
locala a fisierului). directorul parinte sau “Descarcare” strict pentru
acest fisier pentru a descarca fisierul in working
folderul local.

Fisierul este in starea Check in, adica

Aceasta este si ultima versiune valida. Fisierul din
versiunea din Working Folder este
Working Folder este Read/only.
identica cu cea din SmartDoc.

Se ajunge la aceasta situatie atunci cand fisierul din

Fisierul este in SmartDoc in stareaWorking Folder a fost modificat, fara a fi facut
check in, insa versiunea de lucru din anterior Check out.
Working Folder este mai noua decatDaca se doreste salvarea acestor modificari se face
aceasta. mai intai Check out fara a suprascrie modificarile
locale.

Se ajunge la aceasta situatie cand un alt utilizator a

Fisierul este in SmartDoc in starea
modificat fisierul de la ultima updatare a userului
Check in, insa versiunea de lucru din
curent. Prin “Descarcare ultima versiune” se va
Working Folder este mai veche decat
face updatarea in Working Folder la ultima
aceasta.
versiune valida disponibila.

Fisierul este in starea Check out laAceasta este si ultima versiune valida, disponibila
utilizatorul curent iar versiunea dinla utilizatorul curent pentru editare.
Working Folder este aceeasi cu cea
din SmartDoc.

Fisierul este in Check out la

Se ajunge la aceasta situatie atunci cand
utilizatorul curent, insa versiunea din
utilizatorul curent a modificat fisierul de la ultimul
Working Folder este mai noua decat
Check out, dar inca nu a facut Check in.
ultima versiune din SmartDoc.

Fisierul este in check out laSe ajunge la aceasta situatie daca utilizatorul a
utilizatorul curent, insa versiunea dininceput activitatea cu o versiune mai veche decat
Working Folder este mai veche decat
 ultima, si a dat Check out pentru a avea ultima.
ultima versiune din SmartDoc. Prin “Descarcare ultima versiune” se aduce ultima
versiune, iar simbolul se va schimba in .

Aceasta este si ultima versiune valida. Se ajunge la

Fisierul este in Check out la altaceasta situatie daca un alt utilizator nu a dat
utilizator iar versiunea de lucru este Check in pentru a actualiza ultimile modificari.
aceiasi cu cea din SmartDoc. Utilizatorul curent poate utiliza fara probleme
ultima versiune valida (in Check in).

Se ajunge in aceasta situatie daca utilizatorul

Fisierul este in Check out la alt
curent modifica local fisierul fara a face in
utilizator, insa versiunea din
prealabil Check Out. Prin utilizarea functiei
Working Folder este mai noua decat
“Descarcare ultima versiune” se ajunge la ultima
ultima versiune din SmartDoc.
versiune valida.

Fisierul este in Check out la alt

utilizator, iar versiunea utilizatoruluiSe utilizeaza “Descarcare ultima versiune” pentru a
curent este mai veche decat ultima updata la ultima versiune valida.
versiune din SmartDoc.

Principii in organizarea proiectelor tehnice

Proiect in sens Solid Works

Un proiect tehnic (design) este format din mai multe fisiere de diferite tipuri, organizate intr/o
structura ierarhica de directoare dupa nevoile specifice legate de natura proiectului si de
conceptia organizatorica a managerului de proiect.

Deci, in cazul cel mai general un proiect tehnic, este definit de un document/fisier general de
tip .assy care “asambleaza” celelate documente/fisiere distribuite de tip .prt, .assy etc. in unul sau
mai multe. Pentru a intelege mai exact conceptul de proiect, trebuie avut in vedere notiunea de
referentiere. Un fisier ansamblu proiect (.assy) utilizeaza informatiile din piesele componente
(.prt) nu prin copiere in interiorul acestuia, ci prin referentiere la calea in care s/a salvat anterior
aceste fisiere. Exista doua tipuri de referentiere:

 Referentiere absoluta, cand fisierul .assy pastreaza calea absoluta in format UNC (C:/My
Documents/). Aceasta referentiere trebuie evitata cat mai mult posibil. Fac exceptie
Contect Center Files si bibliotecile, care pentru tipul „Vault” de fisier .ipj, trebuie
referentiate absolut in mod obligatoriu;
 Referentiere relativa, cand fisierul .assy „stie” ca fisierele cautate se gasesc numai in
directoarele copil ale unui anumit director care formeaza spatiul de lucru (Workspace) –
 implicit directorul in care este situat ansamblul parinte - evitand astfel cautarea in toate
locatiile sistemului.

In cadrul unei companii exista mai multe proiecte tehnice. Managementul optim al activitatii de
proiectare se bazeaza pe reutilizarea documentelor si implicit al produselor. In acest avem
urmatoarele situatii de reutilizare:

 Componente/subansambluri etc. achizitionate de la terti, organizate in biblioteci de

articole standardizate;
 Componente/subansambluri etc. realizate in companie, organizate in biblioteci proprii;
 Componente/subansambluri etc. realizate in companie.

Conducerea optima a unui proiect se poate face printr/o conceptie inteligenta a structurii de
directoare si prin organizarea riguroasa a spatiului de lucru.

Proiecte in sens SmartPlm

Toate proiectele Solid Works se realizeaza pe statia de lucru cu sau fara utilizarea de fisiere din
alte directoare (Biblioteci Solid Works, proprii, Reutilizari etc,). Pentru a putea face
managementul documentelor, acestea trebuie depuse in BDF a aplicatiei SmartPlm, prin
mecanismele descrise in import proiecte/librarii.

Un document SmartPlm are o serie de proprietati definite la implementare. Exista oricand

posibilitatea de a defini proprietati noi in orice moment din timpul utilizarii.

Aceste proprietati pot fi setate manual, automat de catre diversele module ale aplicatiei sau prin
mapare la import din aplicatia externa (Solid Works, MS Office etc.).

In BDF exista doua categorii de documente in BDF, organizate in doua directoare radacina:

 BD Librarii – unde incarca toate documentele care fac parte din directoarele radacina \\...\
Biblioteci si \\...\Tool box Files, dar si din alte directoare, dupa caz. Structura de
subdirectoare este cea din directoarele respective.
 BD documente – unde se incarca proiectele validate. Structura de directoare reprezinta
directoarele radacina de proiecte iar sub fiecare radacina, structura de directoare din
spatiul de lucru Solid Works din momentul importului.
Note.

1. In BDF se creaza copii ale documentelor importate.

2. Aceste copii pastreaza toate informatiile din fisierele originale, dar si unele suplimentare
rezultate din maparea proprietatilor la import.
3. Dupa validarea proiectului, se recomanda ca acesta sa fie sters din spatiul de lucru,
deoarece BDF pastreaza intotdeauna o copie de referinta.
Principii de management proiecte/documente

Proprietati
Managementul proiectelor/documentelor nu are in vedere continutul (nucleul) acestora, ci
aproape exclusiv informatii/date care se gasesc in zona proprietatilor (properties) ale fisierelor
care reprezinta forma electronica a documentelor. Totusi, anumite aplicatii permit incarcarea
valorilor unor proprietati in variabile definite in continutul documentului (ex. numele creatorului
unui document poate apare in anumite zone dintr/un document). Este posibil si invers, valori de
variabile sa seteze valori ale proprietatii (ex. valoarea masei piesei va completa valoarea unei
proprietati omoloage.

Proprietatile unui document pot fi incadrate in una din categoriile:

 Proprietati sistem – proprietati definite de fiecare aplicatie. Aceste proprietati pot avea si
subdiviziuni de la caz la caz, nu pot fi sterse sa redenumite, si de cele mai multe ori au un
mecanism propriu de setare/resetare a valorilor proprietatii. In conditii bine definite este
posibila setarea/resetarea manuala a valorilor acestor proprietati;
 Proprietati utilizator – proprietati definite de catre utilizator. Aceste proprietati pot fi de
tip sir, boolean, numeric sau data calendaristica.
Pentru unele proprietati pot fi scrise diverse ecuatii care sa permita generarea de valori calculate
functie de valorile altor valori. Sintaxa si operanzii disponibile sunt foarte variate de la aplicatie
la aplicatie.

Dat fiind aceasta situatie, nu este posibil un management corect al documentelor unui proiect
fara a stabili un set coerent de proprietati care sa aiba valori previzibile.

Trebuie precizat ca numele fisierului si extensia acestuia pot fi considerate ca proprietati ale
documentului. Prima sarcina de management documente este asigurarea unicitatii documentelor
la nivel proiect, dar si la nivel de BDF. Aceasta sarcina, este mai complicata decat pare, iar
numele fisierului si extensia sa nu sunt suficiente pentru a asigura aceasta unicitate.

O solutie des utilizata este cea a alocarii uneia sau mai multe proprietati intre care Denumirea
(Description) si codul documentului (Part Number).

De regula, codul unui document este definit de o procedura de codificare care garanteaza
unicitatea codului de document. Pentru siguranta, aceasta proprietate este combinata cu altele
astfel incat in BDF fiecare document sa primeasca un cod absolut unic.

Niveluri de informatie ale unui document

In cadrul SmartPlm legatura document/articol/produs este complet integrata. Dat fiind ca atat
articolele cat si produsele sunt entitati care sunt definite pe baza de proprietati, pe baza de mapari
de proprietati se pot stabili relatii precise intre acestea. Aceste mapari pot fi intr/un sens sau altul
dupa cum se poate vedea in tabelul urmator:
Nr. Nume strat Sursa date Observatii

1. Proprietati articol SmartMpr/Articole

2. Proprietati nod de baza SmartPlm/Produse

3. Proprietati comanda SmartPlm/Productie

4. Proprietati structura SmartPlm/Productie

5. Antet proiect SmartPlm/Documente

6. Proprietati proiect SmartPlm/Documente

7. Antet document SmartPlm/Documente

8. Proprietati document SmartPlm/Documente

9. Proprietati fisier Aplicatie

CAD/CAM/Office

10. Nucleu model Aplicatie

CAD/CAM/Office

Note.

1. Transferului de informatii conform tabelului de mai sus se face numai daca se face
managementul de documente&produse prin SmartDoc plug/in aplicatie (Solid Works,
MSOffice, SW Catia etc.).

Structura generala directoare

Pe fiecare statie de lucru va exista urmatoarea structura de directoare (de preferinta pe acelasi
hdd):

 Nume firma – director radacina proiecte;

 Proiect1 – Radacina proiect - nume proiect 1 in lucru;
 Proiect2 – Radacina proiect - nume proiect2 in lucru;
  Etc.;
 Reutilizari – director radacina unde se vor descarca proiectele/fisierele reutilizate
din alte proiecte.
 Teste – director de testare diverse solutii de lucru.

Note.

1. Structura propusa de directoare se bazeaza pe conceptul de spatiu de lucru recomandat

pentru lucrul in echipa;
2. Se recomanda ca lista proiectelor in lucru sa fie minim de preferinta unul singur;
3. In masura in care un proiect este validat (cu structura importata (BDA+BDP) si cu
documentele incarcate pe server (BDF), acesta se sterge din spatiul de lucru);
4. Crearea unui director radacina de proiect se face manual la startarea unui proeict nou sau
automat la descarcarea unui proiect validat, in vederea unor modificari.

Structura directoare proiect

Fiecare proiec trebuie sa aiba urmatoarea structura de directoare/fisiere:

 Radacina proiect. Va contine urmatoarele fisiere: .assy, .dw ansamblu, ..prt de nivel
1, .drw de nivel 1, .
o Documentatie. Orice tip document de format diferit Solid Works, dar necesare
proiectului;
o Subansamblu1. Va contine: .assy, ..prt, .drw la nivel 1.
 Subansamblu11;
 Subansamblul12;
 Etc.
 Documentatie.
 Componente.
o Subansamblu2. Va contine: .assy, prt, .drw la nivel 2.
 Subansamblul21;
 Subansamblul22;
 Etc.
o Componente.
Note.

1. Fiecare director copil poate avea o structura asemanatoare, cel mai adesea directorul
documentatie putand lipsi.
2. Se va avea in vedere managementul fisierelor (nume si structura) care sunt generate
automat de Solid Works (Piping, etc.)
3. Nu este recomandat sa se faca o arborescenta prea stufoasa de directoare (circa 5 nivele
de la directorul radacina, functie si de proiect).
4. Nu este recomandata introducerea unor directoare separate pentru fisierele .drw, .prt etc.
Structura directoare server
Pe serverul companiei este organizata urmatoarea structura de directoare:

 Solid Works share – radacina directoarelor utilizate in comun de catre toti utilizatorii:
o Biblioteci proprii – directorul radacina care contine fisierele reprezentand modelul
pentru componentele care se achizitioneaza sau care se constituie ca norme
interne;
o Biblioteci temporare – directorul radacina pentru depunerea de fisiere care nu sunt
validate. Acestea vor putea fi utilizate temporar, pana la validare. In nici un caz
nu se va face import structura proiect cu referinte din acest director.
o ToolBox Files – structura de directoare&fisiere create automat de catre Solid
Works la inserearea din CC;
o Profile speciale – Director radacina pentru profile definite de utilizatori;
o Templates – Director radacina cu fisierele sablon definite la nivel de companie;
Note

1. Directoarul Modele de referinta este utilizat numai de catre Administrator aplicatie sau
Director de proiecte.

Resurse modelare
In realizarea unui proiect/ansamblu se vor genera fisiere care se vor salva intotdeauna in spatiul
de lucru al proiectului: „Statie\hdd:\Director radacina proiecte\proiect curent”.

Pentru realizarea unui proiect/ansamblu se mai pot utiliza fisiere predefinite din urmatoarele
directoare:

 Director radacina proiecte\proiect curent – spatiul curent de lucru;

 Director radacina proiecte\proiecte reutilizate – directorul radacina unde se vor descarca
proiectul/fisierele definite anterior dar care se vor reutiliza in proiectul curent;
 \\Server\Solid Works Share\Biblioteci - directorul radacina care contine fisierele
reprezentand modelul pentru componentele care se achizitioneaza sau care se constituie
ca norme interne;
 \\Server\Solid Works Share\Biblioteci temporare - directorul radacina care contine
fisierele reprezentand modelul pentru componentele care se achizitioneaza sau care se
constituie ca norme interne, dar care nu sunt inca validate. Pana la sfarsitul proeictului,
toate componentele utilizate trebuie validate si transferate in directorul \\...\Biblioteci;
 \\Server\Solid Works Share\ToolBox Files - structura de directoare&fisiere create
automat de catre Solid Works la inserearea din TB;
 \\Server\Solid Works Share\ToolBox – Biblioteca integrata Solid Works. In fapt de aici
are loc instantierea de fisiere intr/un director din TBF, de unde se face inserarea propriu
zisa.
 \\Server\Solid Works Share\Profiles – Biblioteca integrata Solid Works pentru profile
semifabricate standard.
Controlul general al proiectului (stiluri, materiale, reguli etc.) se face pe baza setarilor Solid
Works, care isi ia informatiile din directorul radacina \\server\Solid Works Share\Templates, care
va contine un numar de directoare sistem si definite de utilizator, dupa caz.

Actualizarea unui proiect/document

Actualizarea unui proiect inseamna realizarea de modificari ale proiectului, ulterioare
validarii. In mod aproape inevitabil, in procesul de fabricatie apar situatii care necesita
modificarea acestei documentatii tehnice:

 erori de proiectare/desenare continute in documente;

 modificari cerute pentru rezolvarea unor probleme de productie (adaptare la dificultati de
aprovizionare, de prelucrare etc.);
 imbunatatiri de ultima ora cerute de reactiile din piata si de la utilizatori etc.;
 decizii interne de activare a unor imbunatatiri care sa se aplice inclusiv seriei curente de
produse;
 actiuni de recuperare a rebuturilor.

Aceste modificari se initiaza in baza unui ECP, generat de oricare departament, uzual Dep. QA,
Planificare/lansare si chiar de cel de Dezvoltare.

In solutionarea acestor cerinte de modificare trebuie avuta permanent in vedere strategia

adoptata de asigurare a interschimbabilitatii, deoarece numai in cadrul unei strategii se face un
management corect al versionarii si al gestiunii documentelor emise in sectiile de fabricatie sau
la tertii de servicii.

Actualizarea poate necesita modificari la nivel de model, de structura de produs sau de

continut desen. Functie de nivelul modificarii si de aprecierea utilizatorului asupra strategiei de
abordare a modificarii trebuie decis care este nivelul ansamblului care trebuie deschis pentru
modificare. Dat fiind ca se subintelege ca intreaga structura de documente proiect se gaseste in
BDF, in orice situatie este necesar ca mai intai sa se realizeze o descarcare a structurii de
documente necesare pentru a sustine modificarea.

Initierea modificarii unui document/proiect se poate face din oricare departament pe baza
unui ECP, dar decizia de modificare apartine directorului de proiect. Acesta transforma un ECP
in EO si il trimite catre un proiectant (director de proiect pentru executie.

Abordarea modificarilor intr/un proiect se face functie de momentul din „viata“ proiectului cand
apare necesitatea modificarii acestuia:

 modificari in faza de conceptie/proiectare;

 modificari faza de validare proiect (executie prototip/serie zero);
 modificari faza de lansare in fabricatie.
Inchiderea ciclului de modificare a unui document se face prin validare modificarilor si
transmiterea EO cu rezolutie catre cel care a initiat ECP.

Modificarea unui proiect in faza de conceptie/proiectare

In aceasta faza, un proiect se poate dezvolta exclusiv pe statia de lucru a proiectantului,
iar modificarile nu trebuie pastrate in istoric, decat ca instrument suplimentar de
conceptie/proiectare. Totusi, daca se doreste pastrarea rezultatelor intr/un singur loc sau/si daca
la proiect lucreaza mai multi utilizatori simultan care au nevoie reciproc de rezultatele celuilalt
este o buna practica sa se faca descarcarea periodica a proiectului in BDF.

Pentru aceasta fiecare utilizator, care are setata calea de lucru executa operatii de
incarcare periodica pentru (sub)proeictul propriu si de descarcare periodica pentru
(sub)proeictele celelalte. Toate documentele vor fi in Check out, pentru a permite modificari.
Modificarile neautorizate pe documentele altor utilizatori se previn prin setari de adecvate din
aplicatia CAD (de ex. prin declarare ca biblioteci pentru proiectul curent).

Pentru a efectua aceste activitati se procedeaza dupa cum urmeaza:

1. Se invoca modulul SmartDoc.

2. Se creaza in BDF (la initierea proiectului), de catre responsabilul de proiect, un director
de lucru si intreaga structura de subdirectoare prin invocarea functiei SmartDoc/Incarcare
structura directoare;
3. Utilizatorul (initial) face o descarcare structura de directoare in spatiul sau de lucru, prin
invocare functiei SmartDoc/Descarcare structura directoare.
4. Se identifica proiectul/ansamblul/piesa, care urmeaza a fi incarcat/descarcat.
5. Se seteaza, eventual, calea de lucru a proiectului sub directorul radacina proiecte. Se
invoca functia SmartDoc/Setare cale de lucru si se seteaza directorul radacina de
proiect/ansamblu care urmeaza a fi descarcat.
6. Se selecteaza proiectul (se navigheaza si se selecteaza ansamblul) care urmeaza a fi
incarcat, se invoca functia SmartDoc/Incarcare, si se creaza o copie a documentelor
proiectului/ansamblului in spatiul de lucru. Status/ul documentului ramane neschimbat.
Editia si revizia raman neschimbate;
7. Se selecteaza proiectul (se navigheaza si se selecteaza ansamblul) care urmeaza a fi
descarcat, se invoca functia SmartDoc/Descarcare, si se creaza o copie a documentelor
proiectului/ansamblului. Status/ul documentului ramane neschimbat. Editia si revizia
raman neschimbate;
8. Daca simultan cu proiectul constructiv se realizeaza si proiectul tehnologic, informarea
privind ultimile modificari se fac direct sau prin note chat.
In final, proiectul va fi pus in starea Check in (editie 1, revizie 0) prin invocarea functiei
SmartDoc/Check in sau prin atasarea documentului principal la un flux de aprobare, pentru a
marca terminarea activitatii de conceptie/ proiectare.
Modificarea unui proiect in faza de validare
In aceasta faza, proiectul a fost deja publicat, toate documentele avand o versiune initiala
valida (1/0) si proiectul este in faza de executia a prototipului/seriei zero. Elementele specifice
acestei faze sunt legate de faptul ca nu se pune problema interschimbabilitatii, deoarece acesta va
fi primul produs care urmeaza a fi realizat. In aceasta faza nu este necesar controlul modificarilor
la nivel de editie, ci numai la nivel de revizie. Pentru cazul in care este necesara introducerea de
documente (piese noi) acestea vor primi coduri noi, si vor fi tratate ca atare.

Pentru a realiza modificarea unui document in aceasta faza, se procedeaza dupa cum urmeaza:

1. Preluarea/analiza ECP (raportului de neconformitate) pentru documentul tehnic, conform

procedurii specifice QA;
2. Analiza modului de rezolvare a neconformitatii, stabilirea vecinatatii si dimensiunii
vecinatatii afectate de modificarile solicitate si stabilirea unei strategii optime de
modificare functie de tip modificare. Se identifica proiectul/ansamblul/piesa singulara,
care urmeaza a fi modificata.
3. Se invoca modulul SmartDoc.
4. Se seteaza, eventual, calea de lucru a proiectului sub directorul radacina proiecte. Se
invoca functia SmartDoc/Setare cale de lucru si se seteaza directorul radacina de
proiect/ansamblu care urmeaza a fi descarcat.
5. Daca se cunosc exact documentele care trebuie modificate, se invoca una din functiile din
SmartDoc/Versionare/Check out – pentru punerea proiectului/ansamblului/documentului
in starea Check out la utilizatorul curent si cresterea reviziei cu o unitate. De observat, ca
modificarea stricta a unui document de tip .drw, nu necesita neaparat scoaterea in check
out a fisierului .prt omolog, ci numai descarcarea in spatiul de lucru pentru a putea realiza
modificarea fisierului .drw.
6. Daca nu se cunosc exact documentele care trebuie modificate se descarca subansamblul
situat pe cel mai cuprinzator nivel al vecinatatii (eventul intregul proiect).
7. Se efectueaza toate modificarile solicitate in vecinatatea ansamblului, fara a scoate nici
un document in Check out. SmartDoc arata in permenanta care sunt diferentele intre
documentele din BDF si spatiul de lucru.
8. La terminarea modificarilor se va proceda in unul din modurile:
a. Check in/flux pe documentele scoase in check out, pentru validare modificari;
b. Incarcare ansamblu, prilej cu care se va afisa o lista a fisierelor care sunt in check
in, dar au modificari locale. Prin aceasta are loc scoaterea in Check out numai a
acelor documente care au suferit modificari.
c. Aplicarea functiei de Check in/flux, asupra acestor fisiere, pentru validare
modificari
9. Pentru documentele nou introduse se va aplica functia de Check in/flux ca la orice
document nou.
10. Importul structurii de produs conform procedurii de import proiecte care va avea drept
efect, actualizarea structurii de produs si (eventual) actualizarea documentelor
proiectului.
11. Transmiterea unui EO pentru generarea/modificarea de tehnologii determinate de
modificarile constructive.
 12. Finalizare EO prin actualizarea documentelor/structurii de lansare care a solicitat
modificarea.

Modificarea unui proiect in faza de lansare

In aceasta faza, proiectul a fost validat (are cel putin editia 1, si o anumita revizie). Modificarea
unui document poate avea ca efect pierderea interschimbabilitatii cu produsele realizate deja si
de aceea modificarile trebuie facute in contextul stabilit in strategia de modificare documente:

1. Preluarea/analiza ECP (raportului de neconformitate) pentru documentul tehnic, conform

procedurii specifice;
2. Analiza modului de rezolvare a neconformitatii, stabilirea vecinatati si dimensiunii
vecinatatii afectate de modificarile solicitate si stabilirea unei strategii optime de
modificare functie de tip modificare. Se identifica proiectul/ansamblul/piesa, care
urmeaza a fi modificat.
3. Se invoca modulul SmartDoc.
4. Se seteaza, eventual, calea de lucru a proiectului sub directorul radacina proiecte. Poate fi
o solutie setarea unor cai temporare de lucru pentru a descarca diverse versiuni
intermediare, necesare pentru a face comparatii intre acestea. Se invoca functia
SmartDoc/Setare cale de lucru si se seteaza directorul radacina de proiect/ansamblu care
urmeaza a fi descarcat.
5. Se selecteaza proiectul (se navigheaza si se selecteaza ansamblul) care urmeaza a fi
descarcat. Se descarca (sub)ansamblul selectat.
6. Se compara versiunea subansamblului de modificat din BDF cu cea pentru care se
solicita modificarea:
a. Versiunea pentru care se solicita modificarea este identica cu ultima versiune
valida (aceasta insemna ca toate documentele referentiate au o situatie similara.
Se invoca functia Check out urmata de descarcarea documentului impreuna cu
toate referintele sale.
b. Versiunea pentru care se solicita modificarea este mai mica decat ultima versiune
valida. Se analizeaza fiecare versiune superioara pentru a vedea daca una dintre
acestea reprezinta o solutie a problemei si se procedeaza dupa cum urmeaza:
i. se face descarcarea versiunii respective si se utilizeaza ca atare;
ii. crearea unei variante/configuratii noi de document prin:
1. copierea unei versiuni convenabile de document existent;
2. descarcarea unei versiuni convenabile de document existent;
3. orice alta metoda convenabila;
4. Generarea unui document complet nou.
7. Se efectueaza modificarile solicitate in vecinatatea ansamblului, fara a scoate nici un
document in Check out sau Check out editie. SmartDoc va arata in permenanta care sunt
diferentele intre documentele din BDF si spatiul de lucru, dar nu poate stabili automat
daca modificarea este de natura a creste editia sau revizia.
8. Pentru strategia „Interschimbabilitate limitata“ este necesara o analiza suplimentara
pentru a stabili daca modificarea va creste editia sau revizia. Folosind eventual functia
„Utilizari“ se poate vedea care este situatia de fabricatie (cate lansari exista in acest
moment pentru produsul din document).
 9. Dupa terminarea tuturor modificarilor, utilizatorul trebuie sa puna selectiv fiecare fisier
modificat in Check out sau Check out Editie, fara sa modifice datele din spatiul de lucru.
10. Se executa Check in direct sau documentele se ataseaza la un flux de aprobare. Aceasta
functie include si functia de incarcare fisiere.
11. Importul structurii de produs conform procedurii de import proiecte care va avea drept
efect, actualizarea structurii de produs si (eventual) actualizarea documentelor
proiectului.
12. Transmiterea unui EO pentru generarea/modificarea de tehnologii determinate de
modificarile constructive.
13. Finalizare EO prin actualizarea documentelor/structurii de lansare care a solicitat
modificarea.

Codificare proiecte
In conditii speciale nu este suficienta nici introducerea versiunii de produs, spre ex. in
aeronautica, anumite produse foarte importante se introduce un cod suplimentar, care se atribuie
tuturor pieselor din lotul de produse care se fabrica odata (cod de lot) sau chiar se introduce un
cod pentru fiecare componenta a unui lot de piese (seria de produs - Serial/Number).

Ca urmare, prin mecanismul de control al modificarilor unui document trebuie sa se rezolve

urmatoarele probleme:

 asigurarea unicitatii entitatilor (documente/produse);

 stabilirea de reguli/mecanisme de crestere automat/manuala a versiunii (editie/revizie);
 reducerea la max. a consumului de hartie prin limitarea numarului de tipariri;
 controlul actualizarii/retragerii documentelor emise in teritoriu care sunt din versiunea
anterioara.

Scop
1. Definirea conceptului de codificare a unui proiect/produs;
2. Stabilirea principiilor de codificarea a unui proiect/produs;
3. Influenta modificarilor unui proiect asupra codificarii.
Note:

1. Pentru organizarea informationala a unui proiect/produs se utilizeaza metoda codificarii

si controlul versiunii fiecarui produs in una din strategiile de asigurare a
interschimbabilitatii.
2. Un produs/varianta de produs/componenta/serviciu este definit unic de caracteristicile
sale functionale, in baza caruia va primi un cod unic (Reper, Part Number etc.), iar
functie de strategia adoptata o versiune unica.
1. Proiectul reprezinta documentele si structura de documente care definesc proiectul tehnic.
Acesta se pastreaza in BDF;
2. Fiecare subansamblu/componenta dintr/un proiect Solid Works, inclusiv ansamblul
principal corespunde unui articol in BDA.
 3. Structura unui produs (ansamblu) reprezinta legaturile functionale intre
subansambluri/componente. Structura produsului se pastreaza in BDP si reprezinta
aproximativ structura de produs din CAD (BOM structured in Solid Works).
4. Codul unui document din proiect poate reprezenta codul/reperul/Part Number-ul
articolului din BDA.

Principii codificare
Exista mai multe metode de codificare tehnica, principalul scop al codificarii este acela al
asigurarii unicitatii. De cele mai multe ori se cere ca un cod sa poata fi „citit” usor si interpretat
de catre operatorul uman, uneori dimpotriva sa nu poata fi interpretat de catre competitie in
scopuri neamicale.

Un cod de produs „citibil” se poate obtine prin organizarea structurala a produselor unei
companii sub forma unui portofoliu de produse. Aceasta organizare permite definirea unor
proprietati pentru clasele de produse, ale caror valori sa permita definirea unui cod de produs, in
conditiile in care setul de valori de proprietati este unic in cadrul portofoliului de produse.

Principiile de codificare structurata sunt prezentate in cele ce urmeaza:

1. Codul fiecarui produs/componenta trebuie sa fie unic la nivel companie;

2. Unicitatea functionanlitatilor produsului trebuie sa determine unicitatea codului alocat;
3. Odata alocat un cod unui produs acesta trebuie sa ramana neschimbat pe toate perioada
de viata a acestuia;
4. Codificarea produselor se face in baza portofoliului de produse ale unei companii,
existente si previzonate pe un termen cat mai lung;
5. Pentru codificarea produselor, metoda cea mai utilizata este metoda ierahiilor de clase de
produse, care mostenesc un set de proprietati;
6. Fiecare clasa este definita printr/un numar de proprietati care dau unicitatea produselor
care apartin clasei. Diferentierea fiecarui produs din clasa se va face prin valorile fiecarei
proprietati care il definiesc, conform schemei de mai jos:

 Clasa1 - P11, P12

o Clasa11 - P11, P12, P13
 Clasa112 – P11, P12,P13, P14, P15 etc.
 Etc.
 Clasa2 - P21
o Clasa21 - P21, P22
o Clasa22 - P21, P23
 Etc.
7. Fiecare clasa de produse contine unul sau mai multe produse (familii de produse);
8. Fiecare produs poate avea una sa mai multe variante de produs/configuratii de produs;
 9. Pentru a asigura unicitatea codificarii componentelor unui produs (ansamblu) se
utilizeaza metoda codificarii structural ierarhic (PTS - Product tree structure), ca in
schema de mai jos:
 Produs – Antet-0
o Piesa1 – Antet-0.1
o Subansamblul1 – Antet-1.0
 Piesa11 - Antet-1.1
 Etc.
10. Schema cea mai frecventa de codificare a oricarei componente dintr/un produs va avea
urmatoarea sintaxa:
antet/separator/varianta constructiva/separator/cod structural, unde antetul
(alfanumeric)

11. Antet/ul este obtinut din ierarhia de clase, separatorul este un caracter oarecare
nealfanumeric, iar codul structural este numeric, avand un separator oarecare pentru
fiecare nivel al structurii si o sintaxa prestabilita:

Antet Separat Varianta Separat Cod

or constructiva or structural

ABC123 . 1 - 1.12.1.13.0

ABC123

Familie
produs

ABC123.1

Varianta constructiva (Produs)

ABC123.1-1.12.1.13.0

Ansamblu/componenta

12. Orice alta schema de codificare poate fi utilizata cu conditia asigurarii unicitatii la nivel
de companie pentru toate produsele pe toata durata de viata a companiei.

Note:

1. O familie de produse este definita prin partea de antet a codificarii.

2. Un produs este definit din Antet+Separator+Varianta constructiva si reprezinta familia
variantelor de produs (configurartiilor de produs);
3. In cazul in care un ansamblu/componenta dintr/un produs, deja codificat devine un
produs, se poate pastra codul curent sau se poate decide recodificarea. Recodificarea
 presupune crearea unui cod nou numai pentru ansamblu (recomandat) sau si pentru
piesele componente (nerecomandat);
4. Cele mai utilizate caractere utilizate drept separatori sunt: ., -, :, /, dar utilizatorul este
liber sa utilizeze orice alt cod. Caracterul „/” trebuie utilizat cu atentie, in cazul in care
codul este utilizat pentru numele de fisier.
5. Adancimea de structurare a claselor poate avea orice dimensiune, dar experienta arata ca
un numar de max. 5 nivele este suficient pentru a acoperi orice situatie.
6. Codul de produs obtinut mai sus este denumit si cod tehnic. Acest cod poate fi utilizat
integral pentru codificarea comerciala (catalog produse etc.) sau se poate opta pentru un
sistem diferit de codificare.
7. In cazul in care exista un sistem de codificare comercial diferit de cel tehnic, Portofoliul
de produse reprezinta singura mapare intre aceste coduri.
8. Daca eventual exista si un sistem de codificare anterior, acesta poate fi mapat tot pe baza
portofoliului de produse.

Mod de lucru
1. Stabilire strategie de asigurare interschimbabilitate, din cele prezentate mai sus;
2. Stabilire portofoliu de produse pe companie;
3. Stabilire structura de clase de produse;
4. Stabilirea principalelor functionalitati ale caror valori ar putea defini in mod unic fiecare
produs din portofoliul de produse al companiei;
5. Utilizand SmartPlm/Administrare se creaza structura de clase si de proprietati de clase
pentru portofoliul de produse actual si previzibil;
6. Se genereaza ecuatii de calcul pentru codul produselor;
7. Utilizand SmartPlm/Articole se genereza fiecare produs din portofoliul de produse al
companiei, avand in vedere completarea corecta a valorilor pentru toate proprietatile care
definesc produsul, inclusiv codurile anterioare si codul comercial.
8. Se urmareste ca la punerea in starea Check in sa se valideze unicitatea codului de produs.
9. Se aloca codul de produs pentru fiecare nou produs/varianta de produs care se initiaza in
companie.
10. Opereaza codurile comerciale pentru asigurarea maparii corecte.

Cap.5. Analiza comparata.