Upravljanje sprememb z SOLIDWORKS Design

V poslovnih okoljih lahko nenadzorovane spremembe na delu ali sestavu povzročijo resne težave in skrite stroške. Ne glede na to, ali gre za revizijo zaradi nove ideje ali za »prvo izdajo« na koncu življenjskega cikla izdelka, morajo biti takšni procesi vodeni prek jasno določenega mehanizma odobravanja.

Mnoga podjetja te postopke upravljajo z aplikacijami SOLIDWORKS Design Change, ki so del storitev Cloud Services. V tem članku si bomo podrobneje ogledali, kako upravljati procese revizij in prve izdaje dela, zasnovanega v SOLIDWORKS, z uporabo aplikacije Change Execution.

Pogosta vprašanja

Ali je Change Execution na voljo v SOLIDWORKS Design?

Da. Aplikacija se imenuje ENOVIA Change Execution in je del vloge Collaborative Industry Innovator, ki je vključena v SOLIDWORKS Design with Cloud Services. Omogoča izvajanje osnovne oblike upravljanja sprememb. Če imate večjo ekipo in potrebujete kompleksnejše procese (npr. Change Orders), lahko razmislite o vlogi Change Management.

Kako se izvajata procesa prve izdaje in revizije?

Proces revizij je mogoče upravljati tudi brez aplikacij Change, vendar te omogočajo beleženje ključnih informacij, kot so:

izvor zahteve za spremembo,
koristi spremembe,
oseba, ki bo izvedla pregled,
oseba oziroma skupina, ki bo spremembo odobrila.

Na ta način je celoten postopek sledljiv, nadzorovan in dokumentiran.

Pred praktičnim prikazom je koristno razumeti delovanje vmesnikov Change Action in Collaborative Lifecycle.

Change Action (CA)

Change Action predstavlja glavni mehanizem za upravljanje zahtevkov za spremembe. Če želite zahtevati spremembo, ustvarite Change Action (CA) v aplikaciji Change Execution.

Members

Na zavihku Members lahko:

določite izvajalca naloge,
dodate odobravalca ali celotno pot odobritev,
obvestite osebe, ki morajo biti seznanjene s procesom.

Proposed Changes

To je osrednji del Change Action procesa. V to območje dodate komponente, ki jih želite spremeniti.

Aplikacija samodejno prepozna trenutno stanje komponente in predlaga ciljno stanje (Target State).

Scenarij prve izdaje

Če je komponenta v stanju In Work, bo ciljno stanje samodejno nastavljeno na Released, v stolpcu Change pa se prikaže ikona Lifecycle.

Scenarij revizije

Če je komponenta že v stanju Released, se v stolpcu Change prikaže ikona Revision.

Realized Changes

Ko se CA zažene, se komponente iz območja Proposed Changes pojavijo tudi v območju Realized Changes s svojimi novimi stanji.

Samodejno ustvarjanje revizije

Če je del v stanju Released in premaknete CA iz stanja Draft v In Work, sistem samodejno ustvari novo revizijo dela ter jo doda v zavihek Realized Changes.

Ročno ustvarjanje revizije ni potrebno.

Samodejna sprememba Maturity State-a

Podobna avtomatizacija obstaja tudi pri procesu prve izdaje.

Pred oddajo CA v odobritev (med stanjem In Work) lahko komponento v območju Proposed Changes prestavite v stanje Frozen. Sistem nato v območju Realized Changes prikaže zamrznjene komponente, ki bodo ob zaključku procesa samodejno postale Released.

Dodatna avtomatizacija

Možno je tudi samodejno izvajanje prehoda v stanje Frozen.

Ko izberete stanje In Approval, lahko sistem samodejno zamrzne vse komponente v območju Proposed Changes.

Pomembno je vedeti, da to velja samo za komponente, ki so bile dodane v Proposed Changes. Za operacije nad celotnimi sestavi je treba uporabiti funkcionalnosti Lifecycle.

Physical Product in CAD Representation

V seznamu komponent boste opazili dve vrsti zapisov:

-Physical Product, Predstavlja identiteto izdelka na platformi in vsebuje vse pomembne informacije o izdelku.

-CAD Representation, Predstavlja dejansko datoteko SOLIDWORKS.

To območje deluje usklajeno tudi s funkcijo Work Under. Spremembe, izvedene med aktivnim Work Under (npr. zamrznitev komponente ali revizija dela znotraj sestava), se samodejno beležijo in prikazujejo v Realized Changes.

Work Under

Work Under predstavlja povezavo med Change Action procesom in CAD podatki.

Ko je Work Under aktiven:

vse spremembe se beležijo v ozadju,
zagotavlja sledljivost vseh aktivnosti,
omogoča nadzorovano izvajanje sprememb znotraj posameznega Change Action procesa.

Kako uporabljati Work Under

Po kliku na ikono čelade se prikaže gumb Change Action.

Izberete ustrezen CA in ikona se spremeni v aktivno stanje. Ob ponovnem kliku lahko vidite informacije o povezanem Change Action procesu.

Funkcija Work Under je na voljo:

v 3DEXPERIENCE oknu znotraj SOLIDWORKS,
v gradniku Collaborative Lifecycle,
v drugih aplikacijah platforme.

Zakaj je Work Under pomemben?

Če komponento dodate v CA, vendar CA ne povežete z Work Under, sistem ne bo dovolil shranjevanja sprememb.

TST-002 pomeni, da je komponenta povezana s Change Action procesom Tst-002 in da morate za delo uporabiti Work Under.

Ko je povezava vzpostavljena, je gumb Save aktiven in prikazana je ikona aktivnega Work Under.

Maturity State

Ko prvič ustvarite Change Action (CA), je ta v stanju zrelosti Draft. To pomeni, da lahko ta CA vidite samo vi. Ko ga premaknete v naslednje stanje zrelosti, In Work, se osebam, ki ste jih dodali na zavihek Members, pošlje obvestilo in postopek CA se začne.

Ko član, ki je zadolžen za izvedbo CA, opravi vse potrebne naloge, CA prestavi v stanje In Approval, s čimer ga pošlje v odobritev svojemu nadrejenemu in ustrezni organizacijski enoti.

Ko odgovorna oseba oziroma vse osebe v odobritveni poti podajo svojo odobritev, CA preide v stanje Approved. Od tam se samodejno in neposredno prestavi v stanje Completed, s čimer je postopek Change Action uspešno zaključen.

Approvals

Na zavihku Approvals poteka postopek odobritve.

Možnosti:

odobritev ene osebe,
odobritvena pot (Approval Route) z več osebami.

Uporabnik za odobritev:

vnese komentar,
klikne zeleno ikono Approve.

S puščico ob gumbu Approve je na voljo tudi možnost Reject.

Collaborative Lifecycle

Collaborative Lifecycle je ena temeljnih aplikacij sistema PLM ENOVIA.

Omogoča:

upravljanje življenjskega cikla izdelka,
upravljanje stanj zrelosti,
ustvarjanje revizij,
izvajanje drugih operacij nad podatki.

Maturity State

Vsaka aplikacija na platformi ima lahko svoja stanja zrelosti. Stanja v Change Action procesu se razlikujejo od stanj v Lifecycle procesu. V Collaborative Lifecycle stanje neposredno predstavlja status objekta (npr. dela ali sestava).