DIJELJENJE PODATAKA O PROIZVODU KROZ RAČUNALNE …Tablica 3.1: Ljestvica najvećih dobavljača...

SVEUČILIŠTE JOSIPA JURJA STROSSMAYERA U OSIJEKU

STROJARSKI FAKULTET U SLAVONSKOM BRODU

DIJELJENJE PODATAKA O PROIZVODU KROZ RAČUNALNE SUSTAVE

ZA UPRAVLJANJE RESURSIMA PODUZEĆA

Doktorska disertacija

Voditelj rada: Prof. dr. sc. Milan Kljajin

Mr. sc. Tomislav Galeta, dipl. ing. stroj.

Slavonski Brod, 2005.

II

PODACI ZA BIBLIOGRAFSKU KARTICU

UDK: 004.896:658.512.2

Ključne riječi: upravljanje podacima o proizvodu, upravljanje resursima poduzeća, računalom

podržano konstruiranje, dijeljenje podataka

Znanstveno područje: Tehničke znanosti

Znanstveno polje: Strojarstvo

Institucija u kojoj je rad izrađen: Strojarski fakultet u Slavonskom Brodu

Voditelj rada: Prof. dr. sc. Milan Kljajin

Broj stranica: 123

Broj slika: 66

Broj tablica: 9

Broj korištenih bibliografskih jedinica: 93

Datum obrane: 18. studenoga 2005.

Povjerenstvo: Prof. dr. sc. Niko Majdandžić – predsjednik povjerenstva

Prof. dr. sc. Milan Kljajin – voditelj rada

Prof. dr. sc. Zvonimir Kolumbić – član povjerenstva

Prof. dr. sc. Dorian Marjanović – član povjerenstva

Prof. dr. sc. Zdravko Vnučec – član povjerenstva

Institucije u kojima je rad pohranjen:

Gradska i sveučilišna knjižnica u Osijeku

Knjižnica Strojarskog fakulteta u Slavonskom Brodu

Nacionalna i sveučilišna knjižnica u Zagrebu

Sveučilište Josipa Jurja Strossmayera u Osijeku

III

SADRŽAJ

Podaci za bibliografsku karticu ...................................................................................................... II

Sadržaj........................................................................................................................................... III

Popis slika .....................................................................................................................................VI

Popis tablica ...............................................................................................................................VIII

Popis kratica ..................................................................................................................................IX

Popis oznaka................................................................................................................................... X

Predgovor ......................................................................................................................................XI

Sažetak ........................................................................................................................................ XII

Summary ....................................................................................................................................XIII

1 Uvod ........................................................................................................................................1

1.1 Razvoj teme.....................................................................................................................2

1.2 Doprinos disertacije.........................................................................................................3

1.3 Metodologija istraživanja................................................................................................4

1.4 Struktura disertacije.........................................................................................................5

2 Teoretske osnove.....................................................................................................................7

2.1 Tehnički sustavi...............................................................................................................7

2.2 Proces konstruiranja ........................................................................................................9

2.3 Informacijski modeli .....................................................................................................12

2.3.1 Model entitet – relacija (E-R model).....................................................................14

2.3.2 Standard za razmjenu podataka o proizvodu: STEP .............................................16

2.4 Objektno orijentirano modeliranje ................................................................................22

2.4.1 Ključni pojmovi.....................................................................................................23

2.4.2 UML prikaz objektno orijentiranih modela ..........................................................24

3 Pregled stanja ........................................................................................................................27

3.1 PDM sustavi ..................................................................................................................28

3.2 ERP sustavi ...................................................................................................................30

3.2.1 ININ ERPINS........................................................................................................31

4 Analiza PDM koncepta .........................................................................................................34

4.1 Proizvod ........................................................................................................................34

4.2 Podaci o proizvodu........................................................................................................34

4.3 Načini prikazivanja proizvoda ......................................................................................35

4.4 PDM pojam ...................................................................................................................37

IV

4.5 Osnovne PDM funkcije.................................................................................................39

4.5.1 Trezor podataka.....................................................................................................40

4.5.2 Upravljanje razvojnim procesom ..........................................................................40

4.5.3 Upravljanje strukturom proizvoda ........................................................................41

4.5.4 Klasifikacija komponenti ......................................................................................43

4.5.5 Skup korisnih funkcija ..........................................................................................43

4.6 Arhitektura PDM sustava ..............................................................................................44

4.7 Odnos prema CAD sustavima .......................................................................................45

4.7.1 Začahuren ..............................................................................................................46

4.7.2 Sučeljen .................................................................................................................46

4.7.3 Integriran ...............................................................................................................46

4.7.4 Hibrid ....................................................................................................................46

4.8 Odnosi prema drugim poslovnim sustavima.................................................................46

4.9 STEP PDM Shema ........................................................................................................47

4.9.1 Identifikacija komponenti .....................................................................................49

4.9.2 Svojstva komponenti .............................................................................................49

4.9.3 Struktura i odnosi komponenti ..............................................................................51

4.9.4 Identifikacija dokumenata .....................................................................................52

4.9.5 Vanjske datoteke ...................................................................................................53

4.9.6 Odnosi dokumenata i sastavnih datoteka ..............................................................53

4.9.7 Svojstva dokumenata i datoteka............................................................................53

4.9.8 Veza dokumenata i datoteka s podacima o proizvodu ..........................................55

4.9.9 Autorizacija ...........................................................................................................56

5 Izvedba informacijskog modela ............................................................................................57

5.1 Model proizvoda ...........................................................................................................58

5.2 Model trezora ................................................................................................................60

5.2.1 Model baratanja dokumentima..............................................................................63

5.2.2 Modeli pohrane dokumenata.................................................................................67

5.3 Model upravljanja strukturom proizvoda......................................................................69

5.3.1 Model strukture proizvoda ....................................................................................69

5.3.2 Podrška razvoju strukture proizvoda.....................................................................71

5.4 Model autorizacije.........................................................................................................75

5.5 Model vanjskog pristupa ...............................................................................................76

6 Prototipna implementacija modela........................................................................................78

6.1 ERPINS-M Implementacija ..........................................................................................80

V

6.2 CAD Implementacija.....................................................................................................86

6.3 Implementacija vanjskog pristupa.................................................................................90

7 Procjena modela i prototipne implementacije.......................................................................96

7.1 Smjernice procjene........................................................................................................97

7.1.1 Razina implementacije osnovne funkcionalnosti – LCF ........................................98

7.1.2 Razina implementacije proširene funkcionalnosti – LEF .......................................98

7.1.3 Razina integracije unutar ERP sustava – LII..........................................................99

7.1.4 Razina postignutog integriteta podataka o proizvodu – LPDI ................................99

7.1.5 Razina postignute sigurnosti podataka o proizvodu – LPDS...................................99

7.2 Izvedba procjene prema smjernicama ...........................................................................99

8 Zaključak.............................................................................................................................102

9 Literatura .............................................................................................................................104

Životopis......................................................................................................................................108

Biography ....................................................................................................................................109

PRILOG: digitalna inačica disertacije.........................................................................................110

VI

POPIS SLIKA

Slika 1.1: Osnovni okvir DRM metodologije [11] 4

Slika 1.2: Metodologija primijenjenih istraživanja [12] 5

Slika 2.1: Međuodnosi tehničkog sustava u interakciji s ljudima [15] 8

Slika 2.2: Faze i koraci procesa konstruiranja, prilagođeno prema [15] 11

Slika 2.3: Prikaz relacija među entitetima 14

Slika 2.4: Relacija jedan-prema-jedan 15

Slika 2.5: Relacija jedan-prema-mnogi 15

Slika 2.6: Relacija mnogi-prema-mnogi 16

Slika 2.7: STEP struktura, prilagođeno prema [31] 17

Slika 2.8: EXPRESS-G osnovni elementi 21

Slika 2.9: EXPRESS-G model podataka i odgovarajući EXPRESS zapis 22

Slika 2.10: UML dijagram klasa [34] 26

Slika 3.1: Prethodna i očekivana ulaganja u PDM sustave 29

Slika 3.2: Prihodi od PDM sustava vodećih dobavljača 2003. godine 29

Slika 3.3: Arhitektura sustava ERPINS 31

Slika 3.4: Grafički prikaz plana u modulu UPROB podsustava PLATE 32

Slika 4.1: CAD datoteke sklopljenog proizvoda 36

Slika 4.2: PDM područja [53] 38

Slika 4.3: PLM u odnosu na druga rješenja poduzeća [56] 39

Slika 4.4: Rezultati ankete o korištenim PDM funkcijama 39

Slika 4.5: Status i tok dokumenta, prilagođeno prema [51] 41

Slika 4.6: Prikaz strukture proizvoda 42

Slika 4.7: Popis dijelova 42

Slika 4.8: Klasifikacija standardnih dijelova 43

Slika 4.9: Proširena arhitektura PDM sustava 44

Slika 4.10: PDM shema kao presjek aplikacijskih protokola [47] 48

Slika 4.11: Skup funkcionalnih jedinica STEP PDM sheme 48

Slika 4.12: Objekti za identifikaciju komponenti 50

Slika 4.13: Objekti za definiranje općih svojstava 51

Slika 4.14: Objekti strukture i odnosa komponenti 52

Slika 4.15: Objekti vanjskih datoteka 53

Slika 4.16: Objekti odnosa dokumenata i sastavnih datoteka 54

VII

Slika 4.17: Objekti povezivanja dokumenata s podacima o proizvodu 55

Slika 4.18: Objekti povezivanja osoba i organizacija s podacima o proizvodu 56

Slika 5.1: Odnosi proizvodnih elemenata 58

Slika 5.2: Primjer instanciranja proizvoda 59

Slika 5.3: Odnos proizvodnih elemenata i dokumenata 61

Slika 5.4: Dokumenti sklopa potpornja 62

Slika 5.5: Slijed aktivnosti prilikom izmjene dokumenta 64

Slika 5.6: Struktura elemenata umjesto dokumenata 65

Slika 5.7: Zapisivanje sadržaja dokumenta u binarno polje 68

Slika 5.8: Pohrana referencirane datoteke 68

Slika 5.9: Struktura proizvodnih elemenata 70

Slika 5.10: Objekti strukture potpornja 71

Slika 5.11: Slijed prilikom dodavanja elementa u strukturu 72

Slika 5.12: Novi proizvod iz postojećeg 73

Slika 5.13: Troslojna arhitektura vanjskog pristupa 77

Slika 6.1: Prošireni ( ) i pridodani ( ) DEPTO moduli 81

Slika 6.2: Sučelje modula DEPTO nakon implementacije modela 82

Slika 6.3: Izbornik radnji nad dokumentima 83

Slika 6.4: Izvođenje prethodnih verzija dokumenata 83

Slika 6.5: Prikaz modela u zasebnom prozoru 84

Slika 6.6: Dijalog za odabir dokumenta 85

Slika 6.7: Osnovna klasa izvedenog vanjskog modula 86

Slika 6.8: Izbornik vanjskog modula u CAD sustavu 87

Slika 6.9: Dijalozi izvođenja dokumenata 88

Slika 6.10: Provjera nadređenih povezanih dokumenata unutar odabranog elementa 88

Slika 6.11: Provjera po strukturi odabranog elementa 89

Slika 6.12: Prijava korisnika web aplikacije 90

Slika 6.13: Programski kod za prijavu korisnika 91

Slika 6.14: Pretraživanje i prikaz proizvodnih elemenata 92

Slika 6.15: Prikaz strukture 93

Slika 6.16: XML prikaz strukture proizvoda 94

Slika 6.17: Prikazi povezanih dokumenata za različite korisnike 94

Slika 6.18: Povlačenje i zaključani dokumenti 94

Slika 7.1: Rezultati ankete o mjerama praćenja napretka uslijed primjene PLM rješenja 96

VIII

POPIS TABLICA

Tablica 3.1: Ljestvica najvećih dobavljača poslovnog softvera u 2003. [35] 27

Tablica 3.2: Položaj dobavljača PDM softvera među 100 najvećih dobavljača softvera [35] 28

Tablica 3.3: Položaj dobavljača ERP softvera među 100 najvećih dobavljača softvera [35] 30

Tablica 5.1: Prava pristupa korisnika prema podsustavima 75

Tablica 6.1: SQL zapis nadograđenih i korištenih tablica 78

Tablica 7.1: Razdioba udjela po razinama 98

Tablica 7.2: Razdioba udjela osnovnih funkcija 98

Tablica 7.3: Razdioba udjela proširenih funkcija 98

Tablica 7.4: Procjena razine PDM funkcionalnosti ERP sustava 100

IX

POPIS KRATICA

API - Application Programming Interface BLOB - Binary Large Object CAD - Computer Aided Design CADME - Computer Aided Design, Manufacturing and Engineering CAM - Computer-Aided Manufacturing CAE - Computer-Aided Engineering COM - Component Object Model CORBA - Common Object Request Broker Architecture CRM - Customer Relationship Management DRM - Standard for the Exchange of Product Model Data EAI - Enterprise Application Integration ERP - Enterprise Resource Planning HTML - Hyper Text Markup Language HTTP - HyperText Transfer Protocol IDC - International Data Center IEEE - Institute of Electrical & Electronics Engineers ISBN - International Standard Book Number ISO - International Organization for Standardization MRP - Materials Resource Planning OIA - Oracle's Information Architecture OMT - Object Modeling Technique OO - Object-oriented OOSE - Object-Oriented Software Engineering PBS - Product Breakdown Structure PDM - Product Data Management PDS - Product Development System PLM - Product Lifecycle Management RDBMS - Relational Database Management System RMI - Remote Method Interface SCM - Supply Chain Management SQL - Structured Query Language STEP - Standard for the Exchange of Product Model Data STEP - Standard for the Exchange of Product Data TCP/IP - Transfer Control Protocol/Internet Protocol UML - Unified Modelling Language UoF - Unit of Functionality URL - Uniform Resource Locator WWW - World Wide Web XML - Extensible Markup Language

X

POPIS OZNAKA

L - Razina PDM funkcionalnosti LCF - Razina implementacije osnovne funkcionalnosti LEF - Razina implementacije proširene funkcionalnosti LII - Razina integracije unutar ERP sustava LPDI - Razina postignutog integriteta podataka o proizvodu LPDS - Razina postignute sigurnosti podataka o proizvodu

XI

PREDGOVOR

Istraživanja prikazana u ovoj disertaciji izvedena su u sklopu nekoliko projekata pod pokroviteljstvom Ministarstva znanosti i tehnologije Republike Hrvatske. Projekti su izvedeni u razdoblju između 1998. i 2004. godine.

Nositelj projekata je bio prof. dr. sc. Niko Majdandžić. Pozivom za sudjelovanje u svojim projektima, prof. dr. sc. Majdandžić mi je izravno omogućio izradu disertacije i na tome mu od srca zahvaljujem.

Kao voditelj najprije magistarskog rada, a potom i ove disertacije, prof. dr. sc. Milan Kljajin mi je svojim mudrim vodstvom izuzetno pomogao da uspješno dovedem radove na disertaciji do kraja. Zahvaljujem mu na uloženom vremenu, savjetima i poticaju koji mi je neprestano davao.

Od velike pomoći su mi bile primjedbe i savjeti članova Povjerenstva.

Prototipna implementacija je izvedena u suradnji s tvrtkom Inin u okviru ERPINS-M računalnog sustava za upravljanje resursima poduzeća. Zahvaljujem direktoru Igoru Majdandžiću, što mi je u tom dijelu spremno izašao u susret, Tomislavu Luketiću na pomoći u dijelu implementacije modela unutar sustava i Tomislavu Tipuriću u dijelu izvedbe vanjskog pristupa.

Bez podrške supruge, ove disertacije najvjerojatnije ne bi bilo. Nadam se da ću joj u godinama koje dolaze, moći nadoknaditi barem dio uskraćenog vremena i ljubavi.

XII

SAŽETAK

Dijeljenje podataka o proizvodu u distribuiranom procesu razvoja proizvoda kao i samom procesu proizvodnje, bitna je pretpostavka za uspjeh proizvodnog poduzeća. Osnovni koncept dijeljenja podataka o proizvodu u distribuiranom procesu razvoja proizvoda opisan je u ISO STEP PDM shemi i sadržan u računalnim sustavima za upravljanje podacima o proizvodu (PDM/PLM sustavi). Podršku dijeljenju podataka o proizvodu u procesu proizvodnje u većem dijelu pružaju sustavi za upravljanje resursima poduzeća (ERP sustavi).

U disertaciji su razmotrene mogućnosti implementacije prilagođenog PDM modela u ERP sustav proizvodnog poduzeća radi smanjenja broja raznovrsnih računalnih sustava i smanjenja ponavljajućeg posla. Pretpostavka je da se dijeljenjem podataka o proizvodu kroz ERP sustav u svim proizvodnim fazama, uz primjenu modernih dostignuća računalne komunikacije, u prvom redu Internet tehnologija, postiže učinkovitije upravljanje proizvodnjom i olakšava proces razvoja novog proizvoda.

U prilog pretpostavkama disertacije razmotrene su teorijske osnove istraživanja. Potom je učinjen pregled stanja na tržištu PDM i ERP sustava. Analizirani su glavni koncepti upravljanja podacima o proizvodu i postojeći PDM standardi s posebnim osvrtom na osnovne PDM funkcije i njihovu primjenjivost u ERP sustavima malih i srednjih proizvodnih poduzeća zemalja u razvoju ili tranzicijskih zemalja, kakva su razmatrana u disertaciji. Izveden je i predstavljen prijedlog informacijskog modela dijeljenja podataka o proizvodu kroz ERP sustav. Osnovne značajke modela su prototipno implementirane u promatrani ERP sustav. Na osnovu prototipne implementacije i predloženih smjernica ocjenjivanja, učinjena je procjena predloženog modela.

Ključne riječi: dijeljenje podataka, podaci o proizvodu, upravljanje resursima poduzeća,

računalom podržano konstruiranje, upravljanje podacima o proizvodu

XIII

SUMMARY

SHARING PRODUCT DATA THROUGH ERP SYSTEMS

Sharing product data in a distributed process of product development, as also in a production process, is an essential premise for success of a production enterprise. Base concept of a product data sharing in distributed process of product development is described in ISO STEP PDM schema and it is included in computer applications for product data management (PDM/PLM solutions). Enterprise resource planning computer systems (ERP systems) mainly provide support for product data sharing in production process.

In dissertation are considered implementation possibilities of adapted PDM model in ERP system for production companies, all in purpose to reduce number of miscellaneous computer systems and to reduce double work. Premise is that product data sharing through ERP system in all production phases, together with application of modern computer communication achievement – mainly Internet technologies, accomplishes a more efficient production management and makes easier a process of a new product development.

Theoretical basis of a research are considered in a contribution to dissertation's premises. Afterward is performed a state review of PDM and ERP systems market. Main concept of a product data management and existing PDM standards are analyzed with special retrospection on base PDM functions and their applicability in ERP systems of small and middle sized production companies of developing or transition countries, such as considered in dissertation. Derived and presented is a proposition of information model for sharing product data through ERP system. Main features of the model are probationary implemented in considered ERP system. Based on the prototype implementation and proposed evaluation guidelines, an evaluation of proposed model is performed.

Keywords: Data sharing; Product data; Enterprise resource planning; Computer-aided design;

Product data management

1

1 UVOD

"There was no limit to what one man might do, if he gave all, and held back nothing."

Lois McMaster Bujold

Od samih početaka proizvodnje vještina pojedinca donosila je poseban položaj u društvu i uglavnom donosila dobar život vještom znalcu. Srednji vijek i industrijska revolucija s pravom eksplozijom novih spoznaja u području tehničkih znanosti i primjenom znanstvenih dostignuća u proizvodnji jasno su odredili smjernice razvoja novih proizvoda koje su se do danas zadržale. Složenost proizvoda i načina proizvodnje – tehnologija, postala je tolika da se s njima sam pojedinac teško mogao nositi. Zbog toga je važno obilježje u smislu proizvodnje proizašlo iz ovog doba, potreba za timom stručnjaka, a time i nužnu međusobnu razmjenu podataka o proizvodu unutar tima.

Prošlo stoljeće donijelo je gotovo nevjerojatan broj novih dostignuća u znanosti koja su se u velikoj mjeri oslikala u novim proizvodnim tehnologijama i samim proizvodima [1]. Broj dostignuća je uvelike premašio zbrojena znanstvena dostignuća svih prethodnih stoljeća. Papir je doslovno postao pretijesan za čuvanje novih spoznaja i opisa novih proizvoda. Stoga je razvoj računala i digitalne pohrane podataka koji je započeo sredinom stoljeća bio više nužan iako i ne toliko očekivan. Razmjena proizvodnih podataka na globalnom planu u isto vrijeme ipak nije poprimila toliki zamah zbog velikih političkih razlika među državama [2].

Posljednja dva desetljeća u obradi podataka obilježena su povećanom potrebom za digitalnom obradom podataka kroz raznovrsne informacijske sustave, ali i potrebom za dijeljenjem digitalnih podataka o proizvodu [3]. I velike promjene političke slike svijeta bitno su utjecale na značajno povećanje distribuirane proizvodnje. Globalno distribuirana proizvodnja uz razvoj informacijskih i komunikacijskih tehnologija pogodovali su brzom širenju virtualnih poduzeća [4] te nešto sporijem, ali također značajnom razvoju virtualnih tvornica [5].

Prema dostupnim analizama, tržište sustava za upravljanje resursima poduzeća (ERP1 sustavi) je vrlo razvijeno uz značajno kretanje sredstava. Više od 20.000 tvrtki u svijetu je 1997. godine uložilo 10 milijardi USD u instalaciju ERP sustava [6]. Rast ulaganja je nastavljen pa je u 2001. u preko 30.000 tvrtki u svijetu uloženo gotovo 180 milijardi američkih dolara u ERP sustave [7]. U 2003. godini oko 39% velikih poduzeća i 60% manjih koristilo je ERP sustave, dok je od 1000 slučajno odabranih u njih 70% uvedena neka od osnovnih ERP aplikacija za proizvodnju, financije, ljudske resurse ili drugo područje primjene. Studija uglednog IDC2-ovog Europskog centra za softverske ekspertize pokazala je kako na ERP softver otpada više od pola prihoda prodaje softverskih licenci i prihoda održavanja u Zapadnoj Europe, premašujući pri tome dvostruko ukupnu vrijednost tržišta aplikativnog softvera. Iz toga se može zaključiti kako će ERP područje biti i dalje jedno od najvećih, najbrže rastućih i najutjecajnijih u industriji aplikativnog softvera. Logičan zemljopisni smjer širenja je od razvijenih prema zemljama u razvoju ili tranzicijskim zemljama.

Stoga ova disertacija analizira najvažnije koncepte informacijskih sustava (IS3) odnosno posebice ERP sustava s jedne strane, dok s druge strane analizira osnovne koncepte sustava

1 Kratica od engleskog izraza "Enterprise Resource Planning". 2 Kratica od engl. International Data Center 3 I u engleskom govornom području je rasprostranjena kratica IS, od "Information System".

Uvod 2

namijenjenih baratanju podacima o proizvodu (PDM4 sustavi). Cilj analize je pokušati odrediti područja funkcionalnosti PDM sustava koje je moguće, ali i poželjno implementirati u ERP sustave korištene u malim i srednje velikim proizvodnim poduzećima i time pojednostaviti dijeljenje podataka o proizvodu u procesu razvoja proizvoda.

Svaka razmjena i dijeljenje digitalnih podataka je u novije vrijeme neizostavno povezana s globalnom računalnom mrežom – Internetom te se kroz nju nastoji izvesti radi malih zahtjeva za dodatnom mrežnom opremom. Internet zasnovan na paketnom prijenosu podataka odnosno TCP/IP protokolu nudi niz zasebnih protokola, više ili manje prikladnih za dijeljenje podataka o proizvodu. Dio rada je stoga posvećen primjeni aktualnih Internet protokola i tehnologija u smislu teme disertacije.

Radi boljeg razumijevanja specifičnih stručnih izraza korištenih u disertaciji, vjerojatno je prikladno već na početku razlučiti između izraza "dijeljenje podataka" od izraza "razmjena podataka" u smislu u kojemu se koriste u informatičkim tehnologijama. Pod dijeljenjem podataka (eng. Data Sharing) u disertaciji je razmatran dinamičan proces u kojemu više korisnika može istovremeno pristupiti aktualnim podacima. Podatak promijenjen od nekog korisnika ili programa dostupan je u stvarnom vremenu svim drugim korisnicima. Obično je za dijeljenje podataka nužna povezanost s dijeljenom bazom podataka kroz lokalnu ili globalnu mrežu. Za razliku od dijeljenja podataka, u razmjeni podataka (eng. Data Exchange) korisnik čita podatke koji su aktualni samo u trenutku čitanja. Nakon razmjene podataka, već narednog trena korisnik ne može biti siguran jesu li razmijenjeni podaci još uvijek aktualni, jer je moguće da je došlo do njihove promjene na izvoru, što korisnik ne može znati dok ponovo ne pročita podatke s izvora.

1.1 RAZVOJ TEME

Tema disertacije je u dobrom dijelu zasnovana na autorovom radu u sklopu nekoliko projekata u razdoblju 1997. godine i proteže se sve do danas. Riječ je o projektima pod pokroviteljstvom Ministarstva znanosti i tehnologije Republike Hrvatske: "Razvoj upravljačko – informacijskih sustava proizvodnih poduzeća", "Sustav planiranje pojedinačne proizvodnje" i "Ekspertni sustav izrade tehnologije pojedinačne proizvodnje". Projekti su razvijani pod vodstvom prof. dr. sc. Nike Majdandžića na Strojarskom fakultetu u Slavonskom Brodu većinom u suradnji s tvrtkom Inin d. o. o. također iz Slavonskog Broda. Uz njih, u radu na navedenim projektima sudjelovale su mnoge tvrtke u kojima su razvijani sustavi testirani i uglavnom i implementirani. Neke od tih tvrtki su Aluminij iz Mostara u Bosni i Hercegovini, Samoborka iz Samobora, Chromos – Svjetlost iz Lužana, Obnova iz Splita, Trokut iz Novske, Kutjevo d.d. iz Kutjeva, Centra – Elektro iz Začretja, Vibrobeton iz Vinkovaca, Hespo iz Preloga, Limont, Đuro Đaković Termoenergetska postrojenja, ĐĐ Tvornica prijenosnika i uređaja, ĐĐ Zavarene posude, ĐĐ Robni terminal, Optima Commerce i ITAS iz Ivanca.

Prvi korak ka jasnijem određenju teme disertacije učinjen je zapravo prilikom odabira teme magistarskog rada [8]. Naslov magistarskog rada obranjenog u svibnju 2001. godine glasio je "Doprinos modelu razmjene podataka između informacijskih i CAD sustava". Već tada je, prilikom razmatranja prikladnih metoda povezivanja sustava, uočeno preklapanje funkcionalnosti ERP i PDM sustava iako je sam rad bio više usmjeren ka funkcionalnim rješenjima razmjene podataka.

Usmjerenje ka temi znatno je odredio rad profesora Rezayata objavljen u časopisu CAD [9], naročito dio u kojem profesor veli, u slobodnom prijevodu: "Najzad, predlažemo da objektni web mora biti kombiniran sa sustavima za autorizaciju i upravljanje informacijama

4 Od engl. "Product Data Management".

Uvod 3

poduzeća (primjerice CAD, PDM, ERP) pri stvaranju web portala poduzeća, sa zadatkom dostavljanja prave informacije pravoj osobi u pravo vrijeme i u pravom obliku posvuda unutar poduzeća u širem smislu."

Radni naslov teme prijavljene Povjerenstvu u siječnju 2004. glasio je: "Doprinos modelu dijeljenja podataka o proizvodu kroz računalne sustave za upravljanje resursima poduzeća". Međutim nakon javnog izlaganja teme na kojoj je od članova Povjerenstva i prisutnih izneseno nekoliko konstruktivnih prijedloga, naslov odnosno sama tema disertacije je dotjerana sukladno iznesenim prijedlozima.

1.2 DOPRINOS DISERTACIJE

Disertacija nastoji ostvariti doprinos u nekoliko područja: u području ERP sustava proizvodnih poduzeća, u području PDM funkcionalnosti te u području poslovne primjene Internet protokola. Doprinos disertacije se također, zbog dvojne naravi provedenih istraživanja, može promatrati u dva smisla: u teorijskom smislu i u praktičnom smislu o čemu je više napisano u poglavlju o metodologiji istraživanja. Radi lakše analize i oblikovanja kriterija za određivanje doprinosa postavljena je početna teza:

Implementacija strukturiranog informacijskog PDM modela u ERP sustav omogućava dijeljenje podataka o proizvodu kroz ERP sustav; olakšava proces razvoja novog proizvoda; smanjuje ponavljanje poslova i smanjuje broj raznovrsnih računalnih sustava uključenih u procese razvoja i proizvodnje proizvoda.

Prvi očekivani doprinos je u području razvoja i primjene ERP sustava, pri čemu je ciljana skupina ERP sustava malih i srednjih proizvodnih poduzeća karakterističnih za zemlje u razvoju odnosno tranzicijske zemlje. Prema profesoru Majdandžiću [10], navedenim poduzećima u pravilu nisu dostupni veliki, skupi i računalnom opremom zahtjevni ERP sustavi, naročito kada imaju posebnosti kojima je potrebno prilagoditi ERP sustav. Većina dostupnih ERP sustava na neki način pokušava riješiti i rješava dijeljenje podataka o proizvodu. Vlastita rješenja su manje ili više u skladu s postojećim standardima. Analizom i ocjenom prisutnih rješenja za dijeljenje ili češće razmjenu proizvodnih podataka prema kriterijima predloženim u radu nastojalo se razlučiti bitne od manje važnih zahtjeva. Na osnovu takve analize istaknuti su osnovni zahtjevi i predložene vlastite odrednice za razvoj prikladnih metoda dijeljenja podataka o proizvodu kroz ERP sustave prisutne u navedenom okruženju.

Doprinos u području PDM funkcionalnosti je u učinjenom obuhvatnom pregledu postojećih PDM pristupa i industrijskih standarda. Pregled uključuje i sažetak relevantnih ISO5 standarda za opisivanje modela proizvoda, takozvanih STEP6 standarda, zavedenih pod serijskim brojem 10303. Uz pregled je učinjena i analiza pojedinih područja pristupa i standarda u smislu primjenjivosti ali i potrebe primjene u promatranom okruženju kroz ERP sustave.

Većina moderne računalne komunikacije utemeljena na Internet protokolima. U tome ne zaostaju niti ERP sustavi. Međutim, svi protokoli nisu podjednako upotrebljivi, a pojedini niti uopće potrebni u razmjeni podataka o proizvodu. Stoga je učinjen dodatni napor u analizi primjenjivosti postojećih Internet protokola.

5 Eng. International Organization for Standardization 6 Eng. Standard for the Exchange of Product Model Data

Uvod 4

1.3 METODOLOGIJA ISTRAŽIVANJA

U disertaciji je korištena tezi prilagođena metodologija istraživanja u dizajnu (DRM)7. DRM je detaljno osmišljen na Tehničkom sveučilištu u Berlinu od profesorice Blessing i suradnika [11]. Iako je metodologija posebno prilagođena istraživanjima u dizajnu, zbog detaljne dorađenosti uz male prilagodbe lako ju je primijeniti i u srodnim ili pak povezanim područjima.

REZULTATIOSNOVNE METODE ŽARIŠTE

KRITERIJI

OPISNA STUDIJA I

STUDIJA PREPORUKA

OPISNA STUDIJA II

Promatranjei

Analiza

Pretpostavljanjei

Iskustvo

Promatranjei

Analiza

Mjerenje

Utjecaji

Metode

Primjena

Slika 1.1: Osnovni okvir DRM metodologije [11]

Osnovni okvir metodologije čine četiri osnovne cjeline (Slika 1.1): određivanje kriterija istraživanja, prva opisna studija, studija preporuka i druga opisna studija. U svakoj cjelini primjenjuju se osnovne znanstvene metode promatranja, analize, pretpostavljanja i iskustvenog razmatranja.

Međutim, u prethodnom poglavlju je također naznačeno da se zbog dvojne naravi provedenih istraživanja doprinos disertacije može promatrati u dva smisla: u teorijskom i u praktičnom. Po tome se može zaključiti kako disertacija nastoji ući u skupinu primijenjenih istraživanja. Kod istraživanja od kojih se očekuju praktično primjenjivi rezultati u pravilu se kombinirano koriste i dvije temeljne znanstvene metode: kritički racionalizam i induktivizam. Slijed aktivnosti pri provođenju navedenih metoda detaljno je opisao Jorgensen [12], a u nastavku je prikazan i grafički radi lakšeg razumijevanja pristupa korištenog u disertaciji (Slika 1.2). Lijeva grana tijeka istraživanja prikazuje korake koje valja prijeći kod primjene induktivnog pristupa, dok je u desnoj grani istraživanja prikazan racionalni pristup. Tako su u disertaciji kombinirana spomenute dvije metodologije. Uz osnovne znanstvene metode,

7 Izvorno eng. Design Research Methodology - DRM

Uvod 5

primijenjene su i očekivane popratne znanstvene metode: proučavanje relevantne literature, logičko strukturiranje te praktično razmatranje.

RAZVOJ

ISTRAŽI

VANJE

Temeljni problem

Temeljnateorija

Analiza Sinteza

Dijagnoza Model

Sinteza Analiza

Novoznanje

Novoznanje

Prijenos znanjaRazvoj metoda

Primjena

Praktičnirezultati

Slika 1.2: Metodologija primijenjenih istraživanja [12]

1.4 STRUKTURA DISERTACIJE

Nakon uvodnog poglavlja u kojemu je pobliže predstavljena tema disertacije, razvoj teme i metodologija istraživanja, u nastavku je disertacija podijeljena u nekoliko logičkih cjelina po poglavljima.

U drugom poglavlju izveden je pregled teorijskih osnova istraživanja bitnih za naredna razmatranja učinjena u disertaciji.

Treće poglavlje daje pregled stanja na tržištu PDM i ERP sustava.

U četvrtom poglavlju je izložen pregled glavnih koncepata upravljanja podacima o proizvodu s posebnim osvrtom na osnovne PDM funkcije i njihovu analizu primjenjivosti u ERP sustavima malih i srednjih proizvodnih poduzeća zemalja u razvoju ili tranzicijskih zemalja, kakvi su razmatrani u disertaciji. Uz to je učinjena i analiza postojećih PDM standarda s jednakim ciljem.

Prijedlog informacijskog modela dijeljenja podataka o proizvodu kroz ERP sustav predstavljen je u petom poglavlju.

Naredno, šesto poglavlje prikazuje prototipnu implementaciju osnovnih značajki modela predstavljenih u prethodnom poglavlju.

Na osnovu prototipne implementacije i predloženih smjernica ocjenjivanja PDM funkcionalnosti, u sedmom poglavlju je učinjena procjena predloženog modela.

Uvod 6

U posljednjem poglavlju je dana rasprava o provedenim istraživanjima i dobivenim rezultatima. Iz rasprave je izvedeno nekoliko osnovnih zaključaka i smjernice za sljedeća istraživanja u promatranom području.

7

2 TEORETSKE OSNOVE

Proizvod i podatke o proizvodu prikladno je promatrati u pripadnom okruženju. U ovom slučaju možda ne bi bilo prikladno napisati "u prirodnom okruženju", jer je okruženje u kojemu se razvija i nastaje proizvod pretežno označeno tehničkim obilježjima. Stoga se u razmatranju valja okrenuti tehničkom okruženju, odnosno pobliže, tehničkim sustavima i u domeni njihovih znanstvenih dostignuća uočiti pravila i metode prikladne za opisivanje strukture proizvoda i ponašanja proizvoda. Poglavlje o teoriji tehničkih sustava daje osvrt na općeprihvaćene osnovne zajedničke pojmove i uređeni skup zaključaka važnih u razumijevanju i opisivanju proizvoda.

PDM sustavi su u početku bili zamišljeni uglavnom kao pomoć konstruktorima u organiziranju inačica i revizija proizvodnih dokumenata. Širenjem područja funkcionalnosti i povezivanjem s drugim sustavima u proizvodnji olakšan je unos zahtjeva za izmjenama nad proizvodom. Tako su i drugi sudionici u proizvodnji dobili mogućnost izravnijeg utjecaja na razvoj novih inačica proizvoda, od djelatnika u odjelu prodaje, u održavanju odnosno servisu preko tehnologa pa sve do samog kupca. Radi razumijevanja moguće razine utjecaja pojedinih sudionika u proizvodnji na razvoj novog proizvoda, nužno je sagledati sam proces konstruiranja. Na temelju postojećih opisa procesa konstruiranja moguće je razvrstati osnovne i ostale elemente u širem procesu proizvodnje. Stoga je u zasebnom poglavlju prikazan proces konstruiranja.

2.1 TEHNIČKI SUSTAVI

Danas prihvaćene postavke teorije tehničkih sustava detaljno su razradili Hubka i Eder u svojoj poznatoj knjizi "Teorija tehničkih sustava" [13]. U konceptu disertacije, zanimljivo je od istih autora kasnije u zasebnoj knjizi izvedeno razmatranje teorije tehničkih sustava kao sastavnog područja znanosti o inženjerskom dizajnu [14], što će biti dotaknuto u dijelu o procesu konstruiranja. No, u ovom poglavlju je donekle racionalnije osvrnuti se na jezgroviti prikaz Pahla i Beitza o istoj temi [15]. Prema Pahlu i Beitzu, osnove tehničkih sustava čine:

• Sustav, postrojenje, oprema, stroj, sklop i komponenta;

• Pretvorba energije, materijala i signala;

• Funkcionalni međuodnos;

• Radni međuodnos;

• Konstrukcijski međuodnos;

• Sustavni međuodnos;

• Sustav obrade podataka;

• Ciljevi, ograničenja i smjernice.

Postrojenje, oprema, stroj, sklop i komponenta predstavljaju tehničke artefakte, a ovdje su navedeni približno prema stupnju složenosti. Ovi izrazi ne moraju imati jednaku primjenu u različitim područjima tako da dio opreme poput reaktora ili isparivača može biti složeniji od postrojenja, dok artefakti imenovani kao postrojenja u nekim područjima mogu biti opisani kao strojevi u drugima. Stroj se sastoji od sklopova i komponenti. Upravljačka oprema se slično koristi u postrojenjima i u strojevima i može biti sastavljena od sklopova i komponenti te možda čak i od manjih strojeva. Različita primjena ovih izraza odražava zapravo povijesni razvoj i područja primjene.

Teoretske osnove 8

Svi tehnički sustavi uključuju pretvorbu energije, materijala i/ili signala koja mora biti određena kvantitativnim, kvalitativnim i ekonomskim izrazima. Međutim, područje pretvorbe nije od većeg značaja za temu disertacije i stoga u ovom dijelu nije izveden značajni osvrt na njega.

U cilju rješavanja tehničkog problema potreban je sustav s jasnim i jednostavno načinjenim odnosima između ulaza i izlaza. Dakle, potrebno je razlučiti funkcionalne međuodnose te odrediti opću funkciju sustava. Opća funkcija tehničkog sustava u pravilu može biti podijeljena u pod-funkcije i razvrstana u funkcionalno stablo radi lakšeg prikaza strukture funkcija. Spomenuti pristup se vrlo često primjenjuje i na proizvod.

Fizikalni proces ostvaren odabranim fizikalnim efektima i određen geometrijskim i materijalnim značajkama rezultira radnim međuodnosima koji ispunjavanju određenu funkciju tehničkog sustava. Fizikalni efekti mogu biti opisani kvalitativno u smislu fizikalnih zakona upravljajući uključenim fizikalnim vrijednostima, poput zakona poluge ili efekta trenja.

Radni međuodnos uspostavljen radnom strukturom predstavlja početnu točku ostvarenja sustava koja vodi prema konstrukcijskoj strukturi. Konstrukcijska struktura razmatra potrebe proizvodnje, sklapanja, transporta itd. Iz ovog međuodnosa moduli, sklopovi i strojevi prelaze iz idejnog svijeta u konkretne tehničke artefakte ili sustave. Konkretni elementi konstrukcijske strukture moraju zadovoljiti zahtjeve odabrane radne strukture, ali također i druge zahtjeve nužne za zahtijevano funkcioniranje tehničkog sustava. Kako bi zahtjevi bili zadovoljeni, često je potrebno razmotriti i međuodnose sustava.

Želje

no

djel

ovan

je

Nus

poja

ve n

a lju

de i

okol

iš

Tehnički sustav

Energija

Materija

Signali

Ulazne smetnje

Ulazne smetnje

Tehnički artefakt

Ljudi

Ula

zno

djel

ovan

je

Povratno djelovanje i nuspojave

Energija'

Signali'

Materija'

Slika 2.1: Međuodnosi tehničkog sustava u interakciji s ljudima [15]

Tehnički artefakti ili sustavi ne djeluju izdvojeno i uglavnom su dijelovi većeg sustava. Radi ispunjenja svoje funkcije sustav često uključuje ljude kroz njihovo ulazno djelovanje. Sustav odgovara povratnim djelovanjem ili signalima koji potiču na dalju akciju. Prema tome ljudi podupiru ili omogućuju željeno djelovanje tehničkog sustava. Osim željenih unosa, na tehničkih sustav mogu djelovati i neželjeni iz okruženja ili iz susjednih sustava. Takva uznemiravajuća djelovanja mogu izazvati nuspojave poput odstupanja oblika ili položaja.

Teoretske osnove 9

Nadalje je moguće da se uz željeno radno djelovanje pojavi i neželjeno poput vibracija iz pojedine komponente ili cjelokupnog sustava. Stoga je korisno razlučiti između željenog djelovanja, ulaznog djelovanja, povratnog djelovanja, ulaznih smetnji i nuspojava (Slika 2.1). Kako bi željena djelovanja bila pravovremeno uočena i iskorištena te neželjena izbjegnuta, korisno je zabilježiti glavne ciljeve i ograničenja.

Tehničke zadaće se danas uglavnom izvršavaju uz pomoć računala i odgovarajućih programskih rješenja – softvera. Softver se koristi ne samo za nadzor i upravljanje proizvodnih sustava, procesnih postrojenja i alatnih strojeva, već i za podršku konstruktorima. Ovakvi sustavi za obradu podataka su podijeljeni u podsustave koji moraju imati međusobno kompatibilna sučelja. Podsustavi se često nazivaju i programi, potprogrami ili moduli.

Rješenje određene tehničke zadaće određeno je glavnim ciljevima i ograničenjima. Kao glavne ciljeve moguće je razmotriti ispunjenje tehničke funkcije, postignuće ekonomične izvedivosti i pridržavanje sigurnosnih zahtjeva za ljude i okoliš. Dodatno, rješenje podliježe određenim ograničenjima i zahtjevima proizašlim iz ergonomije, proizvodnih metoda, načina transporta, namjeravane operacije i drugih. Stoga rješenje mora zadovoljiti određena opća ili ciljem određena ograničenja koja je moguće klasificirati po sljedećim stavkama:

• Sigurnost, u širem smislu pouzdanosti i dostupnosti,

• Ergonomija, u smislu čovjek – stroj, ali i u smislu estetike,

• Proizvodnja, proizvodne vještine i vrsta proizvodnje,

• Kontrola kvalitete, kroz proizvodni proces,

• Sklapanje, u proizvodnom procesu, ali i poslije,

• Prijevoz, unutar i izvan tvornice,

• Operacija, namjeravana primjena i rukovanje,

• Održavanje, nadzor i popravak,

• Recikliranje, ponovna upotreba, obrada, odlaganje i konačno pohranjivanje,

• Rashodi, troškovi, planovi i rokovi.

Iz navedenih ograničenja moguće je izvesti značajke koje se općenito prikazuju kao zahtjevi, koji utječu na funkciju te na radnu i konstrukcijsku strukturu. Stoga ih se treba tumačiti kao vodilice kroz čitav proces konstruiranja i ugraditi u svaku razinu ostvarenja sustava.

2.2 PROCES KONSTRUIRANJA

Nerijetko se korisnici zbune pred izrazom "proces konstruiranja" ili pobliže samom riječi "konstruiranje". Naime, površnim razmatranjem bi riječ "konstruiranje" lako mogla biti sužena na smisao konstrukcija. Međutim, u našem jeziku je navedena riječ poprimila šire značenje i u tehničkim krugovima se koristi kao naš prijevod engleske riječi design, dok se strana riječ "dizajn" koristi u širem smislu oblikovanja i stiliziranja proizvoda. Zapravo pojam konstruiranja u nas vrlo sažeto i jasno odražava uvriježen engleski izraz Engineering Design.

U nizu definicija izraza konstruiranja8 možda se od drugih po svojoj konciznosti ističe Taylorova [16], koja u slobodnom prijevodu veli: "Konstruiranje je proces primjene raznih tehnika i znanstvenih načela u svrhu definiranja uređaja, procesa ili sustava, do dovoljne razine detaljnosti koja omogućuje njihovo tjelesno ostvarenje."

8 Odnosno izvorno eng. Engineering Design.

Teoretske osnove 10

Do sada je razvijeno više teorija o procesu konstruiranja i uglavnom ih je moguće razvrstati prema mjestima nastanaka kao europsku teoriju, američku i japansku. Europska odnosno točnije njemačka teorija proceduralnog procesa konstruiranja plod je više autora i objedinjena je u obliku VDI smjernica [17], a detaljno je razrađena i u knjigama iz područja inženjerskog dizajna [14, 15].

Prema Suhu [18], sve aktivnosti konstruiranja moraju učiniti sljedeće:

1. Znati potrebe korisnika.

2. Odrediti osnovni problem koji moraju riješiti kako bi zadovoljili potrebe.

3. Zamisliti rješenje kroz sintezu koja uključuje zadaću zadovoljavanja nekoliko različitih funkcionalnih zahtjeva. Pri tome valja koristiti skup ulaza poput konstrukcijskih parametara proizvoda unutar zadanih ograničenja.

4. Analizirati ponuđeno rješenje radi postavljanja njegovih optimalnih uvjeta i postavki parametara.

5. Provjeriti da li izvedeno konstrukcijsko rješenje ispunjava izvorne korisnikove potrebe.

Iako nije uvijek moguće povući jasnu crtu koja određuje granicu između glavnih faza procesa konstruiranja, Pahl i Beitz [15] navode sljedeće glavne faze:

• Planiranje i pojašnjenje zadaće za određivanje podataka.

• Konceptualno konstruiranje kao određenje načela.

• Ostvarenje konstrukcije za određivanje izgleda.

• Konstruiranje detalja za određivanje proizvodnje.

Do iznalaženja konačnog rješenja često je potrebno vraćati se natrag po pojedinim fazama ili pak raditi paralelno dvije ili više faza. Pojedine faze sadrže niz koraka koje je potrebno proći. Iza svakog niza koraka proizlazi određeni rezultat upotrijebljen u pravilu u narednom nizu ili u narednoj fazi, što je prikladno slikovito prikazati klasičnim blok dijagramom toka (Slika 2.2).

Pokretač razvoja proizvoda je ideja o proizvodu s razumnim izgledima za tržišni uspjeh. Ideja može doći iz procesa planiranja proizvoda ili iz kupčeve narudžbe. Ideja se potom u fazi planiranja i pojašnjenja zadaće pretvara u prijedlog i razrađuje kroz nekoliko koraka. Kao rezultat ove faze proizlazi popis zahtjeva koji u služi kao vodilica u narednim koracima procesa. Popis mora biti u svim preostalim fazama podvrgnut nadogradnji i poboljšavanju, što je na dijagramu označeno povratnom vezom.

U fazi konceptualnog konstruiranja provodi se razvoj načelnog, ali i odabir načela na kojima će se zasnivati rješenje. Pri tome se pod odabirom načela razmatraju fizikalne zakonitosti na kojima će se temeljiti rješenje, poput zakona poluge, trenja itd. Načelno rješenje se često može pojaviti u više oblika pa tako primjerice za već postojeće građevne blokove može bi dovoljan shematski prikaz u obliku funkcionalne strukture ili dijagrama toka. Ponekad je pak prikladnije skicirati rješenje ili varijante rješenja koje se u ovoj fazi mogu javiti i tako ih crtežom predstaviti. Radi smanjenja značajnog potrebnog vremena u ovoj fazi, skupina autora je predložila grafičko-matričnu shemu prikaza funkcionalne konstrukcije [19], a čine se i mnogi napori u razvoju programskih sustava za podršku procesu poput baza znanja [20], ekspertnih sustava [21] uz nastojanje primjene pretraživanja temeljenog na posrednicima (eng. Agent-Based Approach) [22].

Teoretske osnove 11

U fazi ostvarivanja konstrukcije nastoji se iz konceptualnog rješenja izvesti nekoliko prethodnih izgleda koji se potom podvrgavaju ocjenjivanju iz kojeg proizlazi uglavnom samo jedan kandidat prethodnog izgleda. Usvojeni izgled se potom u nastavku analizira u cilju uočavanja slabih točaka te provjere grešaka, neželjenih utjecaja i minimalnih troškova. Kako je prikazano povratnom petljom u dijagramu, često se i u ovoj fazi dolazi do novih podataka koji dodaju nove zahtjeve na popis i tako uzrokuju ponovno vraćanje u jednu od prethodnih faza radi dorade. Po provjeri se pristupa pripremi prethodnih popisa dijelova i ostale dokumentacije čime rješenje dobiva svoj konačni izgled. Najkasnije do ove faze potrebno je procijeniti financijsku isplativost čitavog projekta.

Slika 2.2: Faze i koraci procesa konstruiranja, prilagođeno prema [15]

Istom kada se odredi konačni izgled rješenja, moguće je kročiti u fazu konstruiranja dijela. Nakon što se razrade detaljni crteži i popisi dijelova, dovrši proizvodna, montažna,

Teoretske osnove 12

transportna i radna dokumentacija te provjere svi dokumenti, kao rezultat će izniknuti potpuna dokumentacija proizvoda čime je i rješenje zadaće dovršeno. Nerijetko u ovoj fazi nastupi kod konstruktora pad budnosti i usredotočenosti, jer se pojavi osjećaj kako je rješenje gotovo. Zbog toga se događaju propusti u prikazu detalja proizvoda koje je potrebno ispravljati i često u tu svrhu ponavljati prethodne korake.

Osnovne aktivnosti kroz proces konstruiranja su optimizacija načela, optimizacija izgleda, oblika i materija te optimizacija proizvodnje. Pri tome se navedene aktivnosti međusobno preklapaju do određenih koraka, kako je prikazano u dijagramu. Uz ovaj, prisutna su i drugačija tumačenja osnovnih aktivnosti, poput ontološkog razmatranja osnovnih aktivnosti Sima i Duffyja [23].

Radi narednih razmatranja u disertaciji potrebno je osvrnuti se na položaj razmatranih računalnih sustava (ERP i PDM) u procesu konstruiranja.

PDM sustavi sa svojom ulogom u pomoći konstruktorima pri baratanju podacima o proizvodu, uglavnom se koriste u kasnijim fazama procesa konstruiranja. Usmjereni su pretežno prema razmjeni podataka vezanih za geometriju proizvoda i pružaju slabu potporu konceptu razvijanja ideje svrha nadolje (eng. Top-down concept). Kao i CAD sustavi, uglavnom implicitno podržavaju pristup konstruiranja "Sa dna naviše" (eng. Bottom-up) i zahtijevaju detaljne geometrijske opise komponenti prije no što bi promatrane komponente mogle biti uključene u sustav. Ovakve značajke alata ugrađenih u PDM sustave pružaju plodno tlo za nesporazume i nerazumijevanja između sudionika uključenih u zajednički napor ostvarenja proizvoda.

ERP sustavi se u procesu konstruiranja pretežno pojavljuju na samom početku u prijemu i određivanju proizvodnih zadaća te iz procesa konstruiranja u zadnjoj fazi preuzimaju rješenja odnosno dokumentaciju proizvoda. Pri tome ne treba zamijeniti proces konstruiranja s procesom proizvodnje. U potonjem, naime ERP sustavi nastoje biti prisutni u što je moguće većem opsegu.

Kao što podaci nastali u pojedinim fazama procesa konstruiranja nerijetko uzrokuju vraćanje natrag u neku od prethodnih faza, jednako mogu djelovati i spoznaje uočene u procesu tehnološke pripreme proizvodnje koje su uglavnom izvan dometa konstruktora kao i one uočene u samoj proizvodnji. Proizvodne spoznaje i novi zahtjevi na konstrukciju proizvoda iz ovog dijela uglavnom se unose u ERP sustav čime se povećava potreba za razradu protokola za komunikaciju sa CAD/PDM sustavima ili za uključivanje određenih PDM funkcionalnosti u ERP sustave. U tom smislu je vrlo bitno razlučiti tok podataka u procesu konstruiranja ili u širem smislu tok podataka u razvoju proizvoda kao što su to učinili Shooter i dr. u radu u kojemu su predstavili model toka podataka u procesu konstruiranja za koji tvrde da je dovoljno formalan za podršku semantičkom pristupu razvoja standarda za razmjenu podataka [24].

2.3 INFORMACIJSKI MODELI

ERP sustavi su po svojoj naravi informacijski sustavi ili promatrano na nižoj i općenitijoj razini, računalni sustavi za baratanje podacima. Prilikom planiranja ovakvih sustava se u pravilu prethodno pripremaju informacijski modeli ili modeli podataka. Radi pripreme podloge za predlaganje implementacije PDM funkcionalnosti, prikladno je razmotriti temelje informacijskih modela. Uz to se valja osvrnuti na postojeće vrste modela koji se pretežno koriste u pojedinim promatranim područjima.

Prema IEEE9 standardu, model je aproksimacija, predočenje ili idealizacija odabranog pogleda na strukturne, značajke ponašanja, radne ili druge značajke procesa, koncepcije ili sustava iz stvarnog svijeta. Dakle, model je samo predočenje nečega. Jezici koji se koriste

9 Kratica od eng. Institute of Electrical & Electronics Engineers

Teoretske osnove 13

prilikom modeliranja imaju svoj rječnik i gramatiku. Pri tome su riječi dijelovi modela, a gramatika određuje kako riječi mogu biti povezane. Osim toga, jezici modeliranja moraju imati načine tumačenja, a sastavljeni modeli moraju imati određeno značenje unutar određenog područja. Primjerice, kod metode blok dijagrama, riječi su vrste blokova i linija dok gramatiku čine pravila na koja oni mogu biti povezani. Metoda također mora definirati odnose između blokova, linija i vezu sa stvarima iz stvarnog svijeta.

Informacijski modeli promatraju sustave na višoj razini sadržanih podataka i pokušavaju odgovoriti na pitanja poput: Koje podatke sustav sadrži? Koje odnose među podacima sustav razvija i održava? Mnogi informacijski sustavi poput onih u velikim poduzećima ili u državnim upravama imaju najveću složenost u podacima i odnosima među podacima. Uobičajeni informacijski modeli imaju svoje ishodište u razvoju softvera, naročito u razvoju velikih baza podataka. Metode za modeliranje složenih odnosa među podacima su razvijane kao odgovor na potrebu za automatizacijom intenzivnih sustava temeljenih na kolanju dokumentacije. I dok se sustavi opterećeni podacima najčešće promišljaju kao veliki automatizirani sustavi baza podataka, mnogi stvarni primjeri su još uvijek zasnovani na papirnoj dokumentaciji [25].

Informacijski modeli se dakle bave informacijama i podacima. U računalnom smislu, informacija je viši odnosno nadređeni pojam podatku i može se odrediti kao sistematično organiziran i prikazan skup podataka sa svrhom pojašnjenja određenog značenja [26] ili pojednostavljeno kao značenje podataka, kako ih razumijevaju ljudi [27]. Primjerice, informacija je: "Proizvodnja osobnih vozila u proteklih 6 mjeseci dostigla je vrijednost od 100000 vozila." Podatak se u istom, računalnom smislu može odrediti kao vrijednost predstavljena u prikladnom brojčanom obliku koja može biti digitalno prenošena ili obrađivana. Podatak je, dakle, jedinica informacije. Promatrajući prethodni primjer informacije, kao podaci u njoj se mogu izravno promatrati vrijednosti 6 i 100000. Međutim uz standardno kodiranje znakova10 se i nizovi znakova poput "osobna vozila" prevode u brojčane vrijednosti prikladnije za računalnu obradu podataka.

Sve veću važnost informacijski modeli poprimaju zbog sve veće razine inteligencije ugrađene u gotovo sve sustave uz neprestanu automatizaciju naslijeđenih sustava. U sustavima opterećenim podacima, ugrađivanje inteligentnog ponašanja se prvenstveno svodi na iznalaženje odnosa i postavljanje postojane strukture zapisa. Ovo upućuje kako će potreba za pronalaženjem strukture i odnosa među velikim skupinama podataka zapravo određivati građu samog sustava. Primjerice, računalni programski sustavi u proizvodnji više nisu odgovorni samo za nadzor radnih ćelija, nego su dio integrirane informacijske mreže poduzeća, u kojoj se pohranjuju i u stvarnom vremenu obrađuju podaci iz proizvodnih pogona, odjela prodaje, održavanja i drugih dijelova poduzeća. Oni koji uspiju iz ovog velikog skupa podataka iznjedriti razborite prosudbe, stječu osnovnu prednost u tržišnoj utakmici.

Osnovu modernih informacijskih modela čine dijagrami entitet-relacija (E-R) razvijeni za relacijske baze podataka i stoga su obrađeni u zasebnom potpoglavlju. Ovi dijagrami su poopćeni u obitelj objektno orijentiranih tehnika modeliranja o kojima će zbog značaja za temu nešto više biti navedeno u zasebnoj cjelini.

U odnosu na određenu namjenu, moguće je informacijske modele razdijeliti na one specifične i na one općenite namjene. Modeli specifične namjene određuju konceptualni model koji je usmjeren na određeno područje primjene. Prema Bojčetiću [28], u modele specifične namjene se može svrstati TAXIS, SDM, SAM i O2. S druge strane, pristup općenito primjenjivih modela realizira se preko skupa specifičnih konceptualnih modela. Prvi općeniti model bio je

10 Neki od danas uobičajenih standarda kodiranja u računalnoj obradi su primjerice ASCII i njegovo međunarodno proširenje Unicode. Prihvaćeni su i ugrađeni u seriju ISO standarda 8859.

Teoretske osnove 14

hijerarhijski i mrežni model, a nakon njega slijedili su relacijski modeli NIAM i familija IDEF modela. Predstavnici modela koji dijele karakteristike obiju koncepcija su EDM i EXPRESS.

2.3.1 Model entitet – relacija (E-R model)

U povijesnom računalnom smislu je model entitet-relacija prilično star i zbog toga dobro razrađen i široko usvojen [29]. Dijagrami E-R modela su prvi put predloženi u cilju brzog dobivanja smislene strukture baze podataka uz što manje napora. Koriste se za planiranje i dizajn baze podataka kao i za modeliranje podataka sustava.

Ukoliko se upotrijebe u sprezi s normalizacijom podataka, E-R dijagrami su odličan alat za planiranje i dizajn baze podataka. Model entitet-relacija započinje s entitetima, dok normalizacija podataka započinje s atributima pa ova dva alata imaju sklonost provjeravati jedan drugog. Građevni elementi modela entitet-relacija: entiteti, atributi i relacije ili odnosi glatko se prevode u stvarnu bazu podataka.

U fazi analize sustava, dijagram entitet-relacija daje analitičaru jasan, obuhvatan pogled na podatke. U sprezi s dijagramima toka podataka, E-R model pruža analitičaru i alternativne logične poglede na sustav. Ukoliko se puno zna o podacima, ali malo o procesima sustava, dijagram pruža sjajnu polaznu točku za modeliranje sustava.

Model entitet-relacija je vođen podacima. Iako daje naslutiti procese, ne pojašnjava ih. Ljudi bez tehničkog obrazovanja teško razumiju modele i prirodu odnosa (jedan, mnogi), a brojne mogućnosti označavanja čine ponekad poteškoće i iskusnijim osobama u brzom shvaćanju pojedinog dijagrama.

Prije stvaranja dijagrama entitet-relacija, analitičar mora imati barem prethodni osjećaj o logičnim entitetima sustava, atributima i strukturama podataka. Nužne informacije se dobivaju u fazi prikupljanja informacija i određivanja problema.

Prodajnetransakcije Proizvodisu sačinjene od

Proizvodi Prodajnetransakcije

čine

Kupci Proizvodinaručuju

Proizvodi Kupcisu naručeni od

Dobavljači Proizvodidobavljaju

Proizvodi Dobavljačisu dobavljeni od

Slika 2.3: Prikaz relacija među entitetima

Teoretske osnove 15

Za razumijevanje modela, nužno je odrediti osnovne elemente. Osnovni element, entitet je objekt (osoba, grupa, mjesto, stvar ili aktivnost) o kojemu se pohranjuju podaci. Relacija ili odnos povezuje dva entiteta i u dijagramu se prikazuje crtom koja ih povezuje (Slika 2.3). Logično, relacije je moguće izraziti u obliku rečenica s glagolom koji povezuje dva entiteta. Primjerice:

"Prodajne transakcije su sačinjene od proizvoda."

ili

"Proizvodi čine prodajne transakcije."

Sam postupak sastavljanja ovakvih rečenica može dobro poslužiti za provjeru ispravnosti relacija. U slučaju da relacija nije jasna, rečenica može biti napisana duž relacijske linije kao što je prikazano na slici (Slika 2.3). Zadana relacija može biti obavezna odnosno mandatorna i kao takva prikazana u dijagramu punom linijom, ali može biti i opcionalna te takva prikazana isprekidanom linijom.

Važan pojam modela entitet-relacija je kardinalnost. Zbog mnogih razloga neke relacije mogu biti stabilnije i lakše za održavanje od drugih. Kardinalnost, kao mjera relativnog broja pojavljivanja promatranog entiteta, je važna za predviđanje snage relacije. Prema kardinalnosti, relacije se svrstavaju u relacije jedan-prema-jedan (1:1), jedan-prema-mnogi (1:n) i mnogi-prema-mnogi (m:n).

A B

Student Rezultatispita

Slika 2.4: Relacija jedan-prema-jedan

U relaciji jedan-prema-jedan, svako pojavljivanje entiteta A je povezano s jednim i jedinim pojavljivanjem entiteta B te vrijedi i obratno da je svako pojavljivanje entiteta B povezano sa samo jednim i jedinim pojavljivanjem. Primjerice, ako se zamisli da predavač čuva rezultate ispita svakog studenta, tada su u primjeru dva entiteta: student i rezultat ispita. Za svakog studenta postoji samo jedan rezultat i uz svaki rezultat je samo jedan jedini student. Grafički se relacija jedan-prema-jedan prikazuje povlačenjem kratkih poprečnih linija na oba kraja linije koja povezuje dva entiteta (Slika 2.4). Ipak, mnogi jednostavno prikazuju liniju relacije bez posebnih oznaka, a poneki koriste i druge oznake.

A B

Student Faktorocjenjivanja

Slika 2.5: Relacija jedan-prema-mnogi

U relaciji jedan-prema-mnogi, svako pojavljivanje entiteta A je povezano s jednim ili više pojavljivanja entiteta B, ali je svako pojavljivanje entiteta B povezano sa samo jednim pojavljivanjem entiteta A. Primjerice, ocjena studenta je često utemeljena na brojnim faktorima

Teoretske osnove 16

ocjenjivanja (ispiti, seminarski radovi, vježbe). Promatrani student može imati više faktora ocjenjivanja, ali je dani faktor ocjenjivanja povezan sa samo jednim studentom. Grafički se relacija jedan-prema-mnogi prikazuje kratkom poprečnom linijom (ili često bez ikakve oznake) na kraju "jednog" entiteta i s malim trokutićem ili sličnom oznakom na kraju "više" entiteta (Slika 2.5).

U relaciji mnogi-prema-mnogi, svako pojavljivanje entiteta A je povezano s jednim ili više pojavljivanja entiteta B, a i svako pojavljivanje entiteta B je povezano s jednim ili više pojavljivanja entiteta B. Primjerice, studentova svjedodžba može sadržavati popis s više predmeta, a pojedini predmet se može pojaviti na mnogo studentskih svjedodžbi. Grafički se relacija prikazuje s trokutićem ili sličnim znakom na oba kraja linije.

Slika 2.6: Relacija mnogi-prema-mnogi

Iz više razloga relacija jedan-prema-mnogi pokazuje se kao najstabilnija [30]. Zbog toga je osnovna težnja u postupku modeliranja entitet-relacija, prevesti relacije jedan-prema-jedan i mnogi-prema-mnogi u relacije jedan-prema-mnogi.

2.3.2 Standard za razmjenu podataka o proizvodu: STEP

Značajan napor u normizaciji razmjene podataka predstavlja međunarodni standard za razmjenu podataka o proizvodu, službeno poznat kao ISO 10303 i općenito označen kao STEP11 standard [31]. Područje standarda je vrlo široko, jer je cilj razviti standard za prikaz svih podataka o proizvodu.

Prvi dijelovi standarda su prihvaćeni 1994., dok se novi dijelovi neprestano razvijaju i prihvaćaju. Unatoč mnogim godinama teškog rada utrošenog na razvoj STEP-a, njegov učinak na PDM područje je još uvijek prilično marginalan. Vrijeme će pokazati da li će STEP ikada uspjeti doseći visoka očekivanja u širokoj industrijskoj primjeni.

U ovom dijelu je ukratko izložena struktura STEP standarda, napose prikaz strukture proizvoda. STEP se sastoji od mnogo dijelova pa je tako do 1997. godine bilo odobreno 14 dijelova i još je preko 40 dodatnih dijelova u razvoju. Dijelovi su podijeljeni u nekoliko klasa od kojih su najvažnije opisane u nastavku (Slika 2.7).

Veliki dio STEP standarda je dodijeljen prikazu geometrijskih podataka i to je u ovom trenutku vjerojatno najuspješniji dio standarda. Međutim, za razmatranja u disertaciji su važniji dijelovi standarda iz PDM područja i strukture proizvoda. Ukoliko STEP treba služiti kao opći temelj za buduće alate za modeliranje proizvoda, tada jasno mora podržavati i izvornu strukturu proizvoda. Međutim, u nastavku će biti pojašnjeno zašto je teško ugraditi izvornu strukturu proizvoda u opći STEP okvir.

11 Kratica od eng. Standard for the Exchange of Product Data

Teoretske osnove 17

Jezik EXPRESS

STEP definira brojne modele podataka za različite poglede na podatke o proizvodu. Svi modeli podataka su određeni u smislu jezika za definiranje shema nazvanog EXPRESS. EXPRESS se može promatrati kao semantički jezik za modeliranje baze podataka, što znači da se može upotrijebiti za definiranje shema baze koja sadrži tipove objekata, njihove atribute, relacije između objekata i ograničenja ispravnosti.

Slika 2.7: STEP struktura, prilagođeno prema [31]

Teoretske osnove 18

Važno je shvatiti kako EXPRESS opisuje samo strukturu podataka, ali ne i ponašanje. Za promatranu skupinu objekata (primjerice instancu baze podataka) i EXPRESS shemu se može utvrditi da je skupina objekata valjana u odnosu na pripadnu shemu. EXPRESS nije programski jezik i ne uključuje mehanizme za određivanje operacija ili metoda objekata opisanih shemama. Površni pogled na EXPRESS može zavesti u tom smjeru, jer jezik uključuje procedure i funkcije koje mogu sadržavati uobičajene programske elemente poput varijabli, uvjetnih naredbi i petlji. Ipak, ovi elementi mogu biti upotrijebljeni samo za ograničenja ispravnosti i definiciju izvedenih atributa. Ograničenja ispravnosti stoga mogu biti proizvoljno složeni algoritmi pisani u programskom jeziku, ali isti algoritmi samo definiraju provjeru koja određuje da li je pojedini objekt ili skupina objekta ispravna.

EXPRESS shema u osnovi definira broj klasa objekata, koji se u EXPRESS-u nazivaju entiteti. Deklaracija entiteta može određivati atribute, pravila jedinstvenosti i područje pravila. U slučaju modeliranja baze podataka uz objektno orijentirano modeliranje aplikacije, riječ entitet se može koristiti za riječ objekt. No ipak, u jeziku EXPRESS riječ entitet odgovara tipu objekta odnosno klasi objekta, dok je pojedini objekt zapravo instanca entiteta.

U usporedbi s mehanizmima klasifikacije pomoću zapisa u UML12 jeziku o kojemu će biti više riječi kasnije u ovom poglavlju, moguće je uočiti izuzetno moćan koncept izgradnje hijerarhije klasa u EXPRESS-u. Ono po čemu se EXPRESS razlikuje od većine objektno orijentiranih programskih jezika jest mogućnost određivanja jesu li podtipovi entiteta uzajamno isključivi ili uključivi. Razmotrimo prvo uzajamno isključive podtipove. Pretpostavimo li kako entitet "računalo" treba biti apstraktni tip s podtipovima "prijenosno računalo" i "stolno računalo". Svako računalo je prema tome ili prijenosno računalo ili stolno računalo. U EXPRESS-u se ovo može zapisati na sljedeći način:

ENTITY racunalo ABSTRACT SUPERTYPE OF (ONEOF(prijenosno_racunalo, stolno_racunalo));

… END_ENTITY; ENTITY prijenosno_racunalo

SUBTYPE OF (racunalo); …

END_ENTITY; ENTITY stolno_racunalo


END_ENTITY;

Ograničenje podtipa ONEOF() određuje kako je entitet računalo uvijek jedan od navedenih entiteta. Računalo je apstraktni tip pa stoga niti jedan entitet ne može biti samo računalo.

Isključivi ONEOF podtipovi su uobičajeni kao jedini izbor u objektno-orijentiranim sustavima, dok upravo EXPRESS omogućuje zadavanje uzajamno isključivih podtipova. Ovo se može prikazati primjerom, ako se pretpostavi kako su sva računala predstavljena s konkretnim entitetom tipa "računalo", a prijenosna računala su poseban slučaj predstavljen s njihovim vlastitim podtipom. Štoviše, osobno računalo (PC) je drugi poseban slučaj računala. U tom slučaju su dva podtipa računala međusobno uključiva, jer računalo može biti prijenosno osobno računalo. U EXPRESS jeziku je navedeni primjer moguće izraziti na sljedeći način:

ENTITY racunalo SUPERTYPE OF (prijenosno_racunalo ANDOR osobno_racunalo));

… END_ENTITY; ENTITY prijenosno_racunalo


12 Od eng. Unified Modelling Language.

Teoretske osnove 19

END_ENTITY; ENTITY osobno_racunalo


END_ENTITY;

U proširenju prethodnih primjera radi prikaza snage jezika, moguće je pretpostaviti kako računalo može biti prijenosno ili stolno, a u isto vrijeme kućno ili poslovno računalo. Razvrstavanje u dvije okomite dimenzije je tada moguće predstaviti u EXPRESSU na način:

ENTITY racunalo SUPERTYPE OF (ONEOF(prijenosno_racunalo, stolno_racunalo)

AND ONEOF(kucno_racunalo, poslovno_racunalo));

… END_ENTITY;

Unutar deklaracije entiteta moguće je deklarirati atribute navođenjem imena i tipa atributa. Mogući tipovi atributa uključuju cijele brojeve, brojeve s pomičnim zarezom, nizove znakova, logičke vrijednosti (istina, laž i nepoznato) i reference na entitete. Kao tipovi atributa također se mogu pojaviti popis, skupovi ili vreće (skupovi s višestrukim jednakim vrijednostima). Atribut može biti deklariran izborno, što znači da entitet ne mora imat vrijednost u zadanom atributu. Deklaracija izvedenog atributa uključuje izraz koji govori kako izračunati vrijednost atributa iz vrijednosti drugih atributa. Atribut može biti deklariran tako da bilježi referencu na entitet pojedinog tipa. Ukoliko se entitet poziva na drugi entitet preko atributa, drugi entitet tada može imati deklariran inverzni atribut koji se poziva natrag na prvi entitet. U narednom primjeru entitet "osoba" sadrži atribut "prebivaliste" koje se poziva na entitet "mjesto". Entitet "mjesto" s druge strane deklarira inverzni atribut "mjestanin" koji bilježi stanovnike mjesta:

ENTITY osoba prebivaliste : mjesto; … END_ENTITY; ENTITY mjesto mjestanin : SET OF osoba FOR prebivaliste; … END_ENTITY;

Kardinalnost odnosa uspostavljena s referentnim atributima određena je kroz kardinalnosti atributa koji tvore relacije. U prethodnom primjeru, svaka osoba je povezana s točno jednim mjestom i svako mjesto je povezano s bilo kojim brojem ljudi. Ukoliko, primjerice, svako mjesto mora imati barem jednog mještanina, odgovarajući atribut bi mogao biti deklariran na sljedeći način:

INVERSE mjestanin : SET [1..?] OF osoba FOR prebivaliste;

Entiteti nasljeđuju atribute na uobičajeni način od njihovih supertipova. Entitet također može ponovno deklarirati naslijeđeni atribut. Novi tip iznova deklariranog atributa mora biti određenje (specijalizacija i podtip) izvornog tipa atributa. Primjerice, ukoliko entitet "korisnik" deklarira atribut tipa "računalo", tada podtip korisnika poput entiteta "poslovni korisnik", može iznova deklarirati tip atribut kao podtip "računala", kao što je "poslovno računalo".

U prethodnom primjeru moguće je uočiti kako EXPRESS u osnovi prikazuje relacije između entiteta pomoću referentnih atributa, opcionalno nadopunjenih s inverznim atributima radi zapisa referenci u drugom smjeru. Prikaz relacija kao atributa znači kako su relacije "građani nižeg reda" i ne mogu stoga imati atribute. Zbog toga mnogi STEP dijelovi prikazuju relacije u smislu odnosa entiteta koji sadrži reference na aktualne entitete sudionike pojedinih relacija. U tom smislu se može razmotriti relacija između ljudi i mjesta iz prethodnog primjera. Činjenica kako određena osoba živi u određenom mjestu može biti prikazana pomoću entiteta "prebivanje" koji ima referentne atribute na osobe i mjesta. Entitet "prebivanje" tada može definirati dodatne atribute i deklarirati nove entitete kao podtipove:

Teoretske osnove 20

ENTITY prebivanje; mjestanin : osoba; prebivaliste : mjesto; … END_ENTITY;

Entitet može odrediti pravila domene kao uvjete koje mora zadovoljiti svaka pojedina instanca entiteta. Pravilo domene je logički izraz koji se odnosi na atribute entiteta i koji uvijek daje vrijednost "istina" ili "nepoznato" u instanci entiteta. Vrijednost logičkih izraza može biti "nepoznato" ukoliko se izraz odnosi na opcionalni atribut koji nema vrijednosti u promatranoj instanci.

Dok su pravila domene uvjeti za pojedine instance entiteta, ograničenja jedinstvenosti i opća pravila su uvjeti za populaciju objekata kao cjeline. Deklaracija entiteta može uključiti ograničenja jedinstvenosti koja određuju da sve instance entiteta moraju imati različite vrijednosti za pojedini atribut ili kombinaciju atributa (unutar pojedine populacije objekta). Primjerice, entitet "komponenta" s atributom "id" može određivati da sve insance entiteta moraju imati različite vrijednosti za ovaj atribut i entitet "inačica komponente" s atributima "id komponente" i "id inačice" može određivati da vrijednost kao kombinacija dviju vrijednosti mora biti jedinstvena po instancama entiteta u populaciji objekta.

Pravila domene i ograničenja jedinstvenosti deklarirana u entitetu se nasljeđuju po podtipovima entiteta. Instanca entiteta tako također mora zadovoljiti sva pravila domene i ograničenja jedinstvenosti svojih nadređenih odnosno supertipova.

EXPRESS shema može uključivati globalna pravila koja, za razliku od pravila domene i ograničenja jedinstvenosti, nisu definirana unutar pojedinih deklaracija entiteta. Globalna pravila mogu sačinjavati upite na populacije objekta i tako primjerice uvjetovati da postoji barem jedna instanca pojedinog entiteta koja zadovoljava pojedini uvjet. Globalna pravila mogu koristiti sve konstrukcije "programskog jezika" EXPRESS i stoga je moguće napisati bilo koji oblik algoritamskog pravila. Ukoliko se razmotri sljedeći EXPRESS entitet koji definira cjelobrojni atribut i pravilo domene koje veli da je vrijednost atributa pozitivna:

ENTITY E; i : INTEGER; WHERE i > 0;

END_ENTITY;

Čini se prirodnim zamisliti populaciju objekta koja sadrži instance entiteta "E" kod kojih je vrijednost atributa i negativna i tako navesti da su to nevaljale instance entiteta "E". Ipak, strogo govoreći, EXPRESS nema pojam nevaljale instance kao entiteta. EXPRESS je jezik za modeliranje podataka. Shema opisuje samo koja vrsta objekata se može naći u populaciji objekta. U načelu je besmisleno govoriti o instanci "E" u koje je vrijednost "i" niz znakova umjesto cijelog broja ili koja ima vrijednost nekog atributa "x" umjesto atributa "i".

Činjenica da EXPRESS ne prepoznaje "različite vrste nevaljalosti" je prirodna ukoliko se općenito razmotri izvorni cilj jezika EXPRESS i standarda STEP. EXPRESS je alat za opisivanje podataka o proizvodu koji se razmjenjuju i sve više dijele među računalnim sustavima. Nema smisla određivati kako će se sustav ponašati ukoliko primi podatke koji se ne pokoravaju u potpunosti shemi kojoj bi se po pretpostavci trebali pokoravati. Međutim, ovo svojstvo jezika uzrokuje probleme ukoliko se EXPRESS pokuša koristiti izvan svoje originalne domene razmjene podataka, što može biti značajan nedostatak u okviru teme disertacije.

EXPRESS-G

EXPRESS-G je grafički način prikazivanja shema definiranih u EXPRESSU radi olakšane komunikacije ljudi [31]. Definiran je u normativnom dodatku dijela 11 STEP

Teoretske osnove 21

standarda. Zbog malog broja elemenata i relativno jednostavnih pravila primjene, vrlo je prikladan za primjenu (Slika 2.8).

Atr

ibut

i - O

dnos

i

Izborni atribut

Obavezni atribut

Odnos nadtip-podtip

Tipo

vi p

odat

aka

Tip objekta – stvarni nositelj informacijaNpr. ENTITY dio

Mogućnost odabira tipa podatkaNpr. TYPE izbor = SELECT (...)

Osnovni EXPRESS tip podatka:BINARY, BOOLEAN, INTEGER,

LOGICAL, NUMBER, REAL, STRING

izbor

dio

STRING

Korisnički definiran tip podatkaNpr. TYPE oznakaoznaka

Ref

eren

ce s

tran

ica

Referenca na ovu stranicu sa druge stranice

Referenca na drugu stranicu#stranica, #referenca, naziv

#stranica, #referenca (#,#,#)

Slika 2.8: EXPRESS-G osnovni elementi

EXPRESS-G dijagram može prikazati samo entitete i njihove atribute uključujući reference na druge entitete, ali ne i bilo kakva pravila (Slika 2.9). Zbog toga daje nepotpun, ali razumljiv pregled pripadne sheme koja dodatno mora biti detaljno opisana pomoću tekstualnog EXPRESS jezika.

Teoretske osnove 22

EXPRESS-G

stavkaid

naziv

opis

verzija_stavke

vezana_stavka

id

opis

dizajnerska_disciplina_definicije_stavke

verzija_vezane_stavke

id

naziv

definicija_sklopa

EXPRESS

ENTITY stavka;id: identifier;naziv: label;opis: OPTIONAL text;

END_ENTITY;

ENTITY verzija_stavke;id: identifier;opis: OPTIONAL text;vezana_stavka: item;

END_ENTITY;

ENTITY dizajnerska_disciplina_definicije_stavke;id: identifier;naziv: OPTIONAL label;verzija_vezane_stavke: verzija_stavke;

END_ENTITY;

ENTITY definicija_sklopa;SUBTYPE OF(dizajnerska_disciplina_definicije_stavke);

END_ENTITY;

Slika 2.9: EXPRESS-G model podataka i odgovarajući EXPRESS zapis

2.4 OBJEKTNO ORIJENTIRANO MODELIRANJE

Većina modernih informacijskih sustava pa tako i ERP sustava je objektno orijentirana13. Stoga se i modeli podataka pripadnih informacijskih sustava nastoje prikazati u objektnom smislu. Paradigma objektne orijentiranosti dozvoljava aplikacijama da budu rađene u smislu objekata, nasuprot procesa [32]. Jednom zamišljeni i stvoreni objekti mogu biti djelomično ili potpuno iznova upotrijebljeni za stvaranje drugih objekata. Tako u savršenom svijetu novi objekt ne bi trebalo nikad zamišljati i stvarati ispočetka, budući da vjerojatno već negdje postoji objekt iz kojega bi ga bilo moguće izvesti. Prednosti koje nudi objektna tehnologija uključuju bolju kvalitetu softvera, ekonomske dobitke zbog ponovne upotrebe istih objekata, kraće razvojno vrijeme projekata i stvaranje istinski distribuiranih programa po raznovrsnim okruženjima. Osim u razvoju softvera, prednosti načela objektno orijentiranog modeliranja se također očituju i u razvoju sustava općenito i stoga se danas sve šire primjenjuju [30].

Objektno orijentirani softver i sustavi su intuitivni. Objekti su stvari koje uistinu postoje, događaji su stvari koje se uistinu zbivaju, a i objekti iz stvarnog svijeta odgovaraju na nešto poput signala. Međutim, objektno orijentiran softver uz sve svoje prednosti ima i poneku manu. Često je manje učinkovit od strukturalnog softvera na tradicionalnim jednoprocesorskim računalima. No, vrijedi istaknuti kako je objektno orijentiran softver učinkovitiji na paralelnim sustavima koji se sve više primjenjuju, naročito za zahtjevne zadaće.

13 eng. Object-oriented, uobičajena kratica OO

Teoretske osnove 23

2.4.1 Ključni pojmovi

Radi razumijevanja objektno orijentiranog koncepta koji će se u dobrom dijelu koristiti i u razradi disertacije, u nastavku su ukratko pojašnjeni osnovni elementi odnosno ključni pojmovi ovog vrlo važnog koncepta u razvoju informacijskih sustava, ali i aplikacija opće namjene.

Objekti i tipovi objekata

Objekt je stvar o kojoj se podaci pohranjuju i obrađuju. Može biti fizička stvar, poput osobe, korisnika, knjige ili stavke u inventaru. Može biti i apstraktna stvar poput modela, koncepta ili procesa. Za razliku od mnogih tehničkih izraza, riječ objekt znači što ljudi intuitivno i misle da znači.

Radi izbjegavanja bujice brojnih objekata, slični objekti se grupiraju u klase ili tipove objekata. O tipovima objekata je bilo riječi i u poglavlju o STEP standardu, jer se pojam STEP entitet u može tumačiti kao objekt, a tip entiteta stoga kao tip objekta ili klasa. Klasifikacija ili grupiranje objekata olakšava njihovo praćenje.

Pojedini objekt je jedna instanca (ili pojava) klase objekta (ili tipa objekta). Primjerice, dano računalo (sam objekt) ima jedinstven serijski broj. To pojedino računalo je upravo jedna instanca danog modela. Uspinjući se u po klasifikacijskom stablu, trgovina može razlikovati između stolnih, prijenosnih i ručnih računala. Konačno, računala, pisači, kartice, softver, potrepštine, knjige i usluge jasno predstavljaju različite kategorije.

Enkapsulacija ili učahurivanje

I podaci (atributi) i metode (procesi) su povezani s objektima. Primjerice, stavka inventara može biti opisana navođenjem atributa poput koda proizvoda, kratkog opisa, prodajne cijene i drugih. Metoda je proces koji pristupa objektu. Primjerice, s pojedinim proizvodom iz inventara su povezane metode za njegovo odlaganje među ostalim inventarom, za izmjene jednog od mnogih atributa, uklanjanje iz inventara i druge. Metode određuju kako se barata s podacima objekta.

U objektno orijentiranom programu, podaci i metode objekta su povezani tako da se podacima objekta može pristupiti jedino kroz vlastite metode objekta. Sakrivanje izvedbenih detalja na ovaj način je nazvano učahurivanje ili enkapsulacija.

Signali

Kako su objekti u dobro oblikovanim objektno orijentiranim sustavima učahureni, međusobno su izolirani jedni od drugih i promjene na jednom objektu ne mogu slučajno djelovati na druge objekte. Međutim, objekti ne postoje u vakuumu nego su u međusobnoj interakciji s drugim objektima šaljući i odgovarajući na signale.

Signali se stvaraju događajima. Događaj se zbiva kada se promijeni stanje objekta. Promjena stanja obično upućuje na promjenu vrijednosti jednog od atributa objekta. Jedini način za promjenu atributa je kroz jednu od vlastitih metoda objekta pa tako događaji upućuju na metode.

Operacija je vanjski pogled na objekt kojemu je moguće pristupiti preko drugog objekta. Operacija je izvedena kao jedna ili više metoda. Zapravo je operacija jedna ili više metoda koje odgovaraju na vanjski signal ili ga same stvaraju.

Teoretske osnove 24

Vrijedi napomenuti određeni događaj ne usmjerava svoj signal prema određenom ciljanom objektu. Umjesto toga, potaknuti događaj jednostavno odašilje signal, slično načelu prijenosa TCP/IP14 protokola. Drugi objekti mogu odgovoriti na signal ili ga zanemariti, ali izvorni objekt niti zna niti mari za to. U tom slučaju, ravnodušnost znači neovisnost.

Nasljeđivanje

Mazda Miata može biti opisana kao mali sportski osobni automobil s dva sjedala. Kako je ona tip odnosno podklasa automobila, može se pretpostaviti da dijeli atribute drugih automobila, poput četiri kotača, motora, rashladnog, kočionog i upravljačkog sustava. Spuštajući se na drugu razinu, određena Miata (objekt) može biti opisana u okviru atirbuta koji ju čine jedinstvenom (crvena, pomični krov, serijski broj) i moguće je pretpostaviti atribute koje dijeli s drugim Miatama (mala, dva sjedala, sportska). Zapravo, svaka podklasa posuđuje ili nasljeđuje atribute i metode od svoje superklase ili nadređene klase. Ovaj koncept se naziva nasljeđivanje.

Polimorfizam

Određena operacija ili metoda se tumači polimorfnom ukoliko ima slični učinak na različite objekte u različitim razinama. Primjerice, kupčeva kupovina, kupčev povrat robe, pristignuće pošiljke i upotpunjavanje inventara su sve redom događaji koji mogu promijeniti vrijednost stanja zaliha inventara za zadani tip objekta. Opća struktura metode osvježavanja inventara može biti naslijeđena od klase više razine i potom prilagođena za svaki od ovih posebnih slučajeva.

2.4.2 UML prikaz objektno orijentiranih modela

Objedinjeni jezik za modeliranje je daleko poznatiji po svojoj kratici UML koja dolazi od izvornog engleskog naziva The Unified Modeling Language. Razvijen je kao odgovor na potrebu za nekom vrstom zajedničkog razumijevanja najvažnijih ideja objektno orijentiranog koncepta. U širem smislu, UML je grafički jezik za vizualizaciju, određivanje, konstruiranje i dokumentaciju artefakata softverski zahtjevnih sustava [33]. Oblikovan je za laku nadogradnju kako bi zadovoljio raznolike potrebe. U razvoju jezika namjera je bila sačuvati neovisnost od pojedinih programskih jezika i razvojnih metoda. UML je u osnovi integracija triju modela, Booch, OMT15 i OOSE16 iako u sebi uključuje i ideje iz drugih modela [34].

UML je u dobrom dijelu ostvario svoju osnovnu nakanu, postati izražajan vizualni jezik za modeliranje uz zadovoljenje zacrtanih ciljeva:

1. Dobro je formalno definiran.

2. Potiče dobavljače alata na ulaganja u stvaranje objektno orijentiranih alata.

3. Dopušta razmjenu modela.

4. Ima mogućnost nadogradnje.

5. Neovisan je od određenih programskih jezika i razvojnih procesa.

6. Integrira najbolja dostignuća zajednice objektno orijentiranog modeliranja.

14 Internet protokol, inače kratica od eng. Transfer Control Protocol/Internet Protocol 15 Od engl. Object Modeling Technique 16 Od eng. Object-Oriented Software Engineering

Teoretske osnove 25

Semantika jezika je definirana na zajedničkom metamodelu. Pojam metamodela je definiran kao model modela, odnosno ovdje kao UML opis samog UML jezika. Zajednički metamodel je koristan za postizanje prva tri prethodno navedena parcijalna cilja. Uz dovoljno formalni model UML-a, dobavljači alata mogu isporučiti potpuno UML kompatibilne alate čiji dokumenti mogu biti razmjenjivani, jer podliježu zajedničkoj strukturi. Osim što omogućavaju razmjenu modela, formalni metamodeli također unapređuju mogućnost provjere pojedine instance modela u smislu zadovoljavanja pravila jezika UML, što nije jednostavan zadatak. Također poboljšava razumijevanje među metodolozima koji rade na unapređenju samog UML-a i metodologija zasnovanih na njemu.

UML metamodel je moguće podijeliti u tri glavne kategorije: struktura, ponašanje, primjena. Svaki od ova tri segmenta moguće je promatrati kao podređene metamodele koji pružaju formalnu definiciju svojih komponenti.

Cjeline grafičkog zapisivanja su odvojene od semantike UML metamodela. Grafičko zapisivanje podrazumijeva predočavanje koncepata opisanih u metamodelu pa stoga predstavlja "pogled" na metamodel. Slično kao što EXPRESS-G grafički jezik standarda STEP služi za predočavanje shema definiranih u jeziku EXPRESS. Uz UML je pridruženo deset standardnih tipova grafičkih dijagrama koji predstavljaju takav način predočavanja pogleda pripadajućih UML metamodela. Ovih deset dijagrama ne dijele metamodel i zapravo je prisutan stvarni prijeklop metamodela u njima. Za nove korisnike UML-a prijeklop može biti izvor zabune dok se ne shvati kako u mnogo slučajeva dijagrami jednostavno prikazuju preklopljene poglede iste informacije. Budući da dijagrami određuju UML sintaksu za krajnjeg korisnika, a također će biti korišteni u disertaciji za slikoviti prikaz shema i modela, naročito objektno orijentiranih, u nastavku su ukratko predstavljene pojedine vrste dijagrama prema podređenim metamodelima koje pokrivaju.

Strukturalni UML dijagrami

Strukturalni dijagrami obuhvaćaju dijagrame klasa, objekata i paketa. Dijagrami klasa pružaju podršku u opisivanju klasa objekata i njihovih veza s drugim klasama (Slika 2.10). Dijagrami objekata služe za prikaz određenih instanci klasa (objekta) i veza. Paket je organizacijska konstrukcija sa svrhom grupiranja i organiziranja drugih dijagrama u sustav ili podsustav. Svi UML strukturalni dijagrami su usko povezani, jer su sva tri izgrađena oko zajedničkog metamodela. I dijagram objekata i dijagram paketa su posebni slučajevi dijagrama klasa.

UML dijagrami ponašanja

Dijagrami ponašanja u sebi uključuju dijagrame slučaja primjene, suradnje, tijeka, stanja i aktivnosti. U dijagramima ponašanja moguće je uočiti najviše konceptualnih preklapanja u UML-u. Primjerice, dijagrami suradnje i tijeka iskazuju gotovo iste UML koncepte metamodela, ističući dva različita pogleda na ove koncepte. Također i dijagrami aktivnosti su posebni slučajevi dijagrama stanja, koji se ponovno primjenjuju radi isticanja različitih gledišta. Dijagrame ponašanja moguće je podijeliti u dvije široke kategorije: određivanje međudjelovanja i mehanizmi stanja.

Prva kategorija (dijagrami slučaja primjene, suradnje i tijeka) opisuju međudjelovanje entiteta u sustavu. Najopćenitije određivanje međudjelovanja se prikazuje dijagramom slučaja primjene, kojime se opisuju procesi i aktivnosti koje vanjski korisnik može izvršiti koristeći sustav. Dijagrami suradnje i tijeka daju više detalja o tome kako objekti igraju različite uloge dok međusobno djeluju jedni na druge (komuniciraju, sinkroniziraju, aktiviraju) unutar sustava.

Teoretske osnove 26

Dijagram suradnje ističe veze među objektima, dok dijagram tijeka naglašava vremenske veze jedne poruke s drugom.

Poduzeće

+ime : ImeOdjel

+adresa : String+telefon : Broj

Ured

1

1..*

1

1..*

0..1

*

* *

Lokacija4

+dohvatiSliku() : Slika+dohvatiZvuk()+dohvatiKontaktnePodatke()+dohvatiOsobneZapise()

+ime : Ime+IDzaposlenika : Integer+titula : Integer

Osoba

*

+član1..*

*

+voditelj1

+adresa : StringKontaktniPodaci

+porezniBroj+povijestRada+primanja

OsobniZapisi

{podskup}

OsiguranIzvorPodataka

Uprava

klasa

agregacijamnožina

ime

atributi

veza

uloga

ograničenje

operacije

ovisnost

sučelje

generalizacija

Slika 2.10: UML dijagram klasa [34]

Druga kategorija uključuje dijagrame stanja i aktivnosti, koji oba opisuju tok procesa koristeći stanje stroja. Dijagram aktivnosti koristi ograničene oblike mehanizama stanja kako bi odredio ponašanje povezano sa slučajem primjene ili operacijom.

UML pokazuje široku mogućnost ponašanja po tome što pruža dijagrame koji nisu strogo objektno orijentirani. Zbog toga što je podložni UML metamodel objektno orijentiran, svi UML sustavi su također objektno orijentirani, ali to ne upućuje nužno da su svi pogledi potpuno objektno orijentirani. Primjerice, slučaj primjene opisuje procese koji uključuju ponašanje potencijalno povezano s mnogim drugim objektima. Također, dijagram aktivnosti je detaljna specifikacija procesa, bilo da je slučaj primjene ili operacija. Ponašanje opisano dijagramom aktivnosti može biti ograničeno u ponašanju unutar pojedinačnog objekta, ali često to nije slučaj. I dok to može iznenaditi neke objektno orijentirane "čistunce", zapravo je vrlo korisno povremeno imati procesno orijentirane opise koji mogu presjeći granice objekata.

UML dijagrami primjene

Dvije vrste dijagrama se koriste u svrhu prikaza primjene: dijagrami komponenti i dijagrami korištenja. Dijagrami komponenti opisuju strukturu softverskih komponenti kako su primijenjene u izvornom kodu. Koriste se za prikaz ovisnosti između izvornog koda, binarnog koda i izvršnih komponenti softvera. Dijagrami korištenja ukazuju koja se komponenta softvera zapravo izvršava u kojem procesorskom čvoru ili kako komponente softvera mogu prelaziti s procesora na procesor za vrijeme izvršavanja.

27

3 PREGLED STANJA

U zadnjih par desetljeća ERP i PDM sustavi su se razvijali uglavnom međusobno odvojeni jedni od drugih, ali je zanimljivo uočiti kako su razvijani uz primjenu jednakih računalnih tehnologija i na sličnim informacijskim modelima opisanim u prethodnim zasebnim poglavljima o računalnim tehnologijama i informacijskim modelima. Stoga je i u prikazu sustava dan poseban osvrt na korištene računalne tehnologije i informacijske modele. Osvrt je potom u radu upotrijebljen kao temelj za analizu pojedinih elemenata PDM modela u smislu implementacije u ERP sustav.

Obje promatrane skupine sustava dosegle su naročito tijekom zadnjeg desetljeća određenu razinu zrelosti i funkcionalnosti. U ovom dijelu su opisani vodeći sustavi iz svake skupine s osvrtom na spoznaje o posebnostima implementacije pojedinog sustava u pojedinom poduzeću u regiji. Osvrt je učinjen i na sustave koji se primjenjuju u razvijenim zemljama, naročito u Europskoj uniji kao važnom privrednom partneru promatrane regije. Pri tome su naročito promatrani sustavi koji se primjenjuju u malim i srednjim poduzećima sličnim onima u zemljama u razvoju. Istaknuto je i što koriste konstruktori u svom "svijetu" za baratanje podacima o proizvodu, a što drugi korisnici uključeni u proizvodnju. Također je uočeno i upozoreno na raznovrsnost i nekompatibilnost prisutnih programskih sustava te na kakve probleme nailaze pri dijeljenju podataka.

Prije razmatranja pojedinih sustava, zanimljivo je promotriti tablično prikazan tržišni položaj i prihode dobavljača ERP i PDM sustava u odnosu na druge dobavljače (Tablica 3.1). Radi razumijevanja valja navesti kako je ljestvica utemeljena na ukupnim prihodima u 2003. godini s izuzećem društava koja su imala temeljne hardverske ili proizvodne linije neposlovnog softvera u prihodima. Ipak, pojedina društva su uključena u ljestvicu zbog razmjerno visokog udjela prihoda ostvarenog u dijelu poslovnog softvera, poput Siemens Energy & Automation, pri čemu je za redoslijed promatran samo prihod u promatranoj grani a ne ukupan prihod naveden u tablici.

Tablica 3.1: Ljestvica najvećih dobavljača poslovnog softvera u 2003. [35]

BR. TVRTKA PRIHOD [106 USD] BR. TVRTKA PRIHOD

[106 USD]

1 SAP 8.361,5 11 Rockwell Automation 4.104

2 Oracle Corp. 9.475 12 Emerson Process Management 3.471

3 PeopleSoft 2.267 13 Cognos 683

4 Siebel Systems 1.354 14 PTC 657

5 SAS 1.340 15 Invensys Process Systems 6.791

6 Siemens Energy & Automation 84.000 16 SSA Global 646

7 BEA 1.012 17 Microsoft Business Solutions 644

8 Autodesk 952 18 Hyperion 544

9 Dassault Systemes 948 19 Software AG 527

10 UGS 897 20 Mercury Interactive Corp. 506,5

Prva tri na ljestvici su vodeći dobavljači ERP sustava: SAP, Oracle Corp. i PeopleSoft . Među vodećima je i nekoliko dobavljača PDM sustava sa zavidnim prihodima: Autodesk,

Pregled stanja 28

Dassault Systemes, UGS i PTC. Valja ipak istaknuti da su prikazani ukupni prihodi dobavljača, što može dati krivu sliku o visini prihoda dobavljača PDM sustava. Naime, svi vodeći dobavljači PDM sustava ne rade isključivo na tome već im značajne pa i većinske izvore prihoda čine CADME sustavi17, što je naročito izraženo kod Autodeska.

Radi lakšeg sagledavanja složenosti teme, u početku ovog dijela, u prvom je poglavlju prikazano aktualno stanje u svijetu PDM sustava te potom u narednom poglavlju dan je prikaz aktualnih dosega ERP sustava s kratkim prikazom mogućnosti vodećih sustava. U prikazu ERP sustava posebna pažnja je poklonjena modulima koji imaju dodirnih točaka s PDM konceptom.

3.1 PDM SUSTAVI

Na tržištu je prisutan veliki broj dobavljača PDM sustava. Uz to, gotovo svakodnevno se pojavljuju, ali i nestaju manji dobavljači inovativnih sustava. Manji dobavljači se pojavljuju s novim konceptima temeljenim na novim računalnim tehnologijama, a nerijetko ih osnivaju nekadašnji djelatnici velikih dobavljača. Nestaju uglavnom zbog spajanja ili kupovine od većih dobavljača koji kupovinom gotovih sustava i ugradnjom kupljene funkcionalnosti u svoje sustave nastoje sačuvati svoju konkurentnost. Zbog toga nije lako održavati popis dobavljača aktualnim. Ipak tvrtka PDM Information Company na svojim stranicama već nekoliko godina održava vrlo opsežan pregled dobavljača [36].

Radi uvida u stanje tržišta PDM sustava iz godišnjeg pregleda vodećih 100 dobavljača softvera probrani su i tablično prikazani samo dobavljači PDM sustava (Tablica 3.2). Važno je još jednom istaknuti, svim vodećim dobavljačima PDM sustava to u pravilu nije jedini niti većinski izvor prihoda.

Tablica 3.2: Položaj dobavljača PDM softvera među 100 najvećih dobavljača softvera [35]

BR. TVRTKA PRIHOD [106 USD]

8 Autodesk 952

9 Dassault Systemes 948

10 UGS 897

14 PTC 657

34 MSC Software 253

64 MatrixOne 100,4

68 Agile Software Corp. 88,3

74 CoCreate Software 76

Vrijednost tržišta PDM sustava dosegla je u 2003. godini iznos od 4,54 milijardi dolara, što je povećanje od 4% u odnosu na prethodnu godinu [37]. Ulaganja u sam PDM softver uključujući plaćanje licenci, pretplate, obnavljanje prava korištenja i održavanje porasla su sa 1,64 milijardi dolara u 2002. na 1,94 milijardi u 2003. čineći pri tome 42% ukupnih ulaganja u PDM tržištu. Veći dio od 58% tržišta ponijela su ulaganja u PDM usluge koja su dosegla 2,6 milijardi dolara u odnosu na 2,5 milijardi iz 2002. (Slika 3.1). Prethodne godine bile su vrlo

17 Skraćeno pisanje za tri srodne kratice s istim "CA-" korijenom: CAD/CAM/CAE. Čita se na engleskom Computer-Aided Design, Manufacturing and Engineering.

Pregled stanja 29

plodne za PLM18 industriju i obilježene su otvaranjem investicijskih fondova namijenjenih PLM sustavima u tvrtkama koje koriste PLM rješenja, što je potaklo njihov industrijski rast. Ovaj trend porasta ulaganja predviđa se i u narednim godinama uz zaoštravanje tržišne utakmice i uže fokusiranje dobavljača na pojedine industrijske grane.

0

1

2

3

4

5

6

7

8

9

10

1999. 2000. 2001. 2002. 2003. 2004. 2005. 2006. 2007. 2008.

Mili

jard

e $

UslugeSoftver

Očekivano

Slika 3.1: Prethodna i očekivana ulaganja u PDM sustave

Prema [37], vodeći dobavljači PDM sustava u 2003. bili su Agile, EDS Corporation, IBM i Dassault Systèmes (IBM+DS), MatrixOne, PTC i SAP. Početkom 2004. EDS je prodao svoju PDM grupaciju privatnim ulagačima, utemeljivši Unigraphics Solutions (UGS) kao neovisni entitet. Međutim, u 2003. je UGS još uvijek bio dio EDS-a pa su stoga razmatrani prihodi EDS Corporation. Prema tome su EDS i IBM+DS bili dobavljači s najvećim ostvarenim prihodom u 2003. (Slika 3.2).

0200400600800

10001200140016001800

EDS (UGS)

IBM+D

SPTC

SAP

MatrixO

ne

Agile+

Eigner

Mili

juni

$

UslugeSoftver

Slika 3.2: Prihodi od PDM sustava vodećih dobavljača 2003. godine

Kako bi i kratak opis svih dostupnih PDM sustava zahtijevao više stranica, u ovom odlomku su samo navedeni neki od sustava koji se pretežno koriste u ovom dijelu Europe:

• PTC: Windchill PDMLink i PRO/Intralink – PDM sustav Windchill PDMLink tvrtke Parametric Technology Corporation (PTC) osmišljen je i izveden u sklopu integralnog sustava za razvoj proizvoda19 u kojemu su još uključeni i široko

18 Od eng. Product Lifecycle Management – Upravljanje životnim ciklusom proizvoda, izraz pobliže pojašnjen u poglavlju o PDM konceptu. 19 Izvorno na engleskom jeziku "Product Development System (PDS)".

Pregled stanja 30

poznati CAD/CAM/CAE sustav visoke opsežnosti Pro/ENGINEER Wildfire te sustav za upravljanje i suradnju na projektima Windchill ProjectLink. I dok je Windchill potpun PDM sustav, Pro/INTRALINK je donekle pojednostavljen PDM sustav čija je osnovna namjena upravljanje podacima u radnoj grupi inženjera koji rade primarno u Pro/ENGINEERu [38].

• Dassault Systemes: Enovia Solutions i SmarTeam – Tvrtka Dassault Systemes u većinskom je vlasništvu informatičkog diva IBM-a. Krenuvši iz Francuske s razvojem CAD/CAM/CAE/PDM aplikacija ispočetka uglavnom za avionsku industriju proširila se u mnoge zemlje. Najpoznatiji proizvod tvrtke Dassault Systemes svakako je računalni sustav za konstruiranje Catia, ali ni PDM rješenja nisu manje poznata. U ponudi su dva sustava: Enovia i SmarTeam. Korisnike može zbuniti što na tržištu ove sustave nude dvije naizgled odvojene tvrtke: Enovia Corporation i SmarTeam Corporation Ltd. No čim se istakne kako su obje u potpunom vlasništvu Dassault Systemes odnosi su jasniji.

• Autodesk: Vault i Streamline – Iako Autodesk ne zauzima veliki udio na svjetskom tržištu PDM sustava, izrazito su prisutni na tržištu dizajnerskih aplikacija široke namjene. Aplikacije poput AutoCADa, Mechanical Desktopa, Mapa, Inventora i 3DStudia poznate su i u znatnoj mjeri prisutne i na hrvatskom tržištu. Kako bi zadovoljili korisnike, u Autodesku su razvili aplikacije Vault i Streamline [39].

3.2 ERP SUSTAVI

Tržište ERP sustava je izuzetno razvijeno i s velikim prihodima pa tri vodeća dobavljača ERP sustava zauzimaju i vodeća mjesta na ljestvici dobavljača poslovnog softvera (Tablica 3.1). Iako je Oracle Corp. u 2003. ostvario najveći ukupni prihod, zbog vrednovanja samo prihoda poslovnog softvera prilikom razvrstavanja, nalazi se iza SAP-a.

Tablica 3.3: Položaj dobavljača ERP softvera među 100 najvećih dobavljača softvera [35]

BR. TVRTKA PRIHOD [106 USD]

UDIO PRIHODA IZVAN SAD

1 SAP 8.361,5 69%

2 Oracle Corp. 9.475 49%

3 PeopleSoft 2.267 nepoznat

16 SSA Global 646 62%

17 Microsoft Business Solutions 644 nepoznat

23 Best Software 424 nepoznat

24 GEAC Enterprise Solutions 405 47,4%

27 Intentia 358 nepoznat

28 IFS 323 33%

38 QAD 231 53%

Međutim, u 2004. godini Oracle je pokušao ojačati svoj položaj preuzimanjem tvrtke Peoplesoft. Uz poteškoće i suprotstavljanje [40], preuzimanje je uspješno dovršeno početkom

Pregled stanja 31

2005. godine [41], čime je Oracle zacijelo postao prihodovno najjača tvrtka među dobavljačima Nedavno završenim preuzimanjem ERP sustava na našem tržištu.

Dva vodeća proizvođača ERP sustava, SAP i Oracle su uz samostalno razvijene sustave također znatno zastupljena i u Hrvatskoj.

Neka od poznatijih društava – korisnika sustava SAP R/3 sustava u Hrvatskoj su Industrija nafte i plina - INA, Lura, Ministarstvo financija RH, Pliva, Podravka, Siemens, Hrvatski telekom, Kaufland, Zagrebačka pivovara, Tvornica duhana Rovinj i GETRO [42].

Korisnici Oracle rješenja u Hrvatskoj povezani su međusobno kroz udrugu korisnika [43], a neki od poznatijih su: Badel 1862, Croatia osiguranje, Dalekovod, Franck, Industrija nafte – INA, Kraš, Narodna banka Hrvatske i Zagrebački velesajam.

3.2.1 ININ ERPINS

Razvijen na Oracle informacijskoj arhitekturi, ERPINS sustav je nastao kao rezultat dvadesetogodišnjeg razvoja eksperata za proizvodne znanosti, stručnjaka s bogatim iskustvom u razvoju proizvoda, projektiranju proizvodnih tehnologija i upravljanju proizvodnjom te informatičara sa znanjem u primjeni novih informatičkih tehnologija [10]. Razvijen je u tvrtki Informatički inženjering – ININ d.o.o. u Slavonskom Brodu i namijenjen je malim i srednjim poduzećima, naročito kada imaju posebnosti kojima je potrebno prilagoditi ERP sustav.

Prema posebnim zahtjevima različitih grana industrije razvijene su i zasebne inačice sustava ERPINS: ERPINS-M za metaloprerađivačku industriju, ERPINS-G za građevinsku proizvodnju i izgradnju objekata, ERPINS-D za drvoprerađivačku industriju i ERPINS-P za prehrambenu i procesnu industriju.

ERPINS

BAZAPBaza zajedničkih

podataka

PROKAProdaja i kalkulacija

DEPTODefinicija

proizvoda i tehnologije

NAZALNabava i zalihe

OSKVEPraćenje kvalitete

PLATEPlaniranje i terminiranje

proizvodnje

PRAPEPraćenje proizvodnje

ODKAPOdržavanje kapaciteta

LANRALansiranje radnih naloga

MEKONMenadžment i kontroling

RINISRačunovodstvo

Slika 3.3: Arhitektura sustava ERPINS

Poput većine ERP sustava i ERPINS je izveden modularno sa središnjom bazom podataka, u ovom slučaju Oracle bazom (Slika 3.3). Modularnost sustava očituje se kroz arhitekturu izvedenu kroz podsustave koji su nadalje sastavljeni od pripadnih modula [10]:

Pregled stanja 32

• U podsustavu BAZAP, baze zajedničkih podataka, pohranjuju se zajednički podaci i šifre potrebne drugim podsustavima. Uz to sadrži i module: Podaci o poduzeću, Organizacijska struktura, Podaci o partnerima, Podaci o kapacitetima, Podaci o kadrovima, Valute i tečajevi, Radni kalendar, Rječnik podataka, Jedinice mjere, Klasifikacija i Generator izvještaja.

• Podsustav definicije proizvoda, materijala i tehnologije DEPTO sadrži module: Proizvodni elementi, Sastavnice proizvoda, Revizije, Popis crteža, Sheme krojenja, Tehnološke operacije, Zahvati i Alati.

• Podsustav prodaje i kalkulacije PROKA sadrži module: Upiti, Ponude, Ugovori, Kalkulacija, Radni nalozi, Plan proizvodnje, Proizvod – Cijene, Skladište, Nalog za otpremu, Fakture i Knjižne obavijesti. Uz ove uobičajene module pridodaje se i modul automatiziranog visokoregalnog skladišta.

• Podsustav upravljanja nabavom i zalihama NAZAL sastavljen je od modula: Elementi, Mogući izbor dobavljača, Nalozi, Upiti, Ponude, Narudžbe, Skladišta, Promet i Inventura.

• Podsustav planiranja i terminiranja proizvodnje PLATE (Slika 3.4) sastavljen je od modula: Planiranje, Plan priljeva, Rebalans, Varijante plana i Višerazinsko planiranje.

Slika 3.4: Grafički prikaz plana u modulu UPROB podsustava PLATE

Pregled stanja 33

• Podsustav praćenja proizvodnje PRAPE sastoji se od modula: Praćenje radnih naloga, Praćenje operacija, Dnevni učinak, Priprema materijala, Pakiranje i Otprema.

• Podsustav lansiranje radnih naloga LANRA omogućuje provjeru pripremljenosti materijala, alata, gotovih poluproizvoda i programa za lansiranje radnog naloga te rezerviranje materijala i poluproizvoda za potrebe realizacije poslova na radnom nalogu.

• Podsustav praćenja kvalitete OSKVE sadrži module: ISO Manager, Praćenje kvalitete, Praćenje materijala, Praćenje reklamacija, Umjeravanje instrumenata i Laboratorij.

• Podsustav održavanja opreme i kapaciteta ODKAP sastoji se od modula: Podaci o opremi, Preventivno održavanje, Korektivno održavanje i Planski popravci.

• Podsustav računovodstva i financija RINIS sastoji se od modula: Plaće, Osnovna sredstva, Robno materijalno knjigovodstvo, Financijsko knjigovodstvo, Pogonsko knjigovodstvo, Blagajna, PDV i Virmani.

• Podsustav menadžmenta i kontrolinga MEKON sadrži module: Troškovi poslovanja, Nedovršena proizvodnja, Stanje ugovora, Obračun izvršenja, Procjena dobiti i gubitaka te Grafički prikazi.

Uz prikazana osnovna rješenja, razvijena su i rješenja za vezu poduzeća s okruženjem i za posebne potrebe poduzeća poput: upravljanje dokumentacijom, Internet, SMS, WAP, ISO Manager i Telebanking.

34

4 ANALIZA PDM KONCEPTA

Svrha analize PDM koncepta je pokušati odrediti područja funkcionalnosti PDM sustava koje je moguće, ali i poželjno ugraditi u promatrane ERP sustave proizvodnih poduzeća te time omogućiti i pojednostaviti dijeljenje podataka o proizvodu.

U središtu PDM koncepta nalazi se proizvod i proizvodni podaci pa je za uvod u analizu samog koncepta nužno definirati pojam proizvoda i proizvodnih podataka.

4.1 PROIZVOD

Prije navođenja definicija pojmova treba istaknuti višeznačnost pojma proizvoda koju je dobro uočio i istaknuo Martio u svom izvještaju [44]. Višeznačnost ili razmatranje proizvoda u više oblika može se uočiti i samim razmatranjem prisutnih definicija.

Primjerice, prema standardu ISO 13584-1 (biblioteka dijelova), proizvod je proizvodiv, proizveden ili prirodan objekt, sustav objekata ili tvar. Proizvod se može sastojati od bilo koje kombinacije tjelesnih i konceptualnih objekata poput softvera ili algoritama [45].

U standardu ISO 10303 Part 41 (STEP), proizvod je definiran kao tjelesno ostvariv objekt proizveden prirodnim procesom ili proizvodnim postupkom [46].

U smislu konstruiranja, Hubka [14] određuje proizvod kroz zahtjeve i navodi kako proizvod mora biti sposoban izvršiti željenu zadaću (provesti transformaciju, postići rezultat procesa, uopće funkcionirati). Proizvodi to moraju činiti sa zahtijevanim performansama, operativnošću, vijekom trajanja, sigurnošću, pouzdanošću, prilagodljivošću, održivosti i drugim zahtjevima. Prethodna grupa svojstava je ponekad objedinjena pod zajedničkim izrazom funkcionalnost.

4.2 PODACI O PROIZVODU

Umjesto izraza "podaci o proizvodu" moguće je koristiti i kraći izraz "proizvodni podaci". Međutim potonji izraz u uobičajenoj primjeni sužava željeni opseg, jer pridjev "proizvodni" uglavnom češće označava podatke povezane s proizvodnjom nego s proizvodom odnosno tumači se kao "podaci o proizvodnji" umjesto "podaci o proizvodu". Unatoč tomu što su proizvodnja i proizvod usko povezani pojmovi, nemaju jednaka značenja. Ukoliko se koristi izraz "proizvodni podaci" nužno je stoga naznačiti da li se misli na podatke o proizvodu ili na podatke o proizvodnji. U nastavku disertacije, radi izbjegavanja zabune, pretežno će se koristiti jednoznačni izraz "podaci o proizvodu", a tamo gdje bude upotrijebljen dvosmislen izraz biti će posebno protumačen sadržaj i opseg izraza.20

Podatke o proizvodu moguće je odrediti kao prikaz informacija o proizvodu u određenom stilu prikladnom za komunikaciju, tumačenje ili obradu pomoću računala ili od strane čovjeka [47].

U razmatranju raznolikih podataka o proizvodu dobro polazište je odredio Peltonen u svojim radovima [48, 49]. Pri tome je razmatrano poduzeće u proizvodnoj industriji. U takvom poduzeću poslovi se dijele po brojnim funkcijama koje su uobičajeno organizirane po zasebnim 20 Izrazi korišteni u stručnoj literaturi na engleskom jeziku su jednoznačni, jer se za podatke o proizvodu koristi izraz "Product Data", a za podatke o proizvodnji izraz "Production Data".

Pregled stanja 35

odjelima poduzeća. Razmatrajući funkcije proizvodnog poduzeća moguće je razlučiti podatke o proizvodu.

Razvoj proizvoda je osnovni izvor novih podataka o proizvodu. Za svaki novi proizvod rade se analize tržišta, popis zahtjeva, prostorni modeli, tehnički crteži, izvještaji ispitivanja i drugi.

Marketing ili oglašavanje priprema brošure, prospekte, kataloge proizvoda i druge dodatne materijale u cilju bolje prodaje proizvoda.

Prodaja koristi podatke o proizvodu prilikom pripremanja ponuda, ali uz to često treba i informacije o stanju zaliha i terminima proizvodnje. U slučaju prilagodljivih ili konfigurabilnih proizvoda koje se prilagođava zahtjevima pojedinog kupca, potrebno je sačiniti zasebni opis proizvoda za svaku narudžbu. Uobičajeni dokumenti koji se pojavljuju prilikom prodaje su cjenici, računi, narudžbe i ponude, ali i upute za instalaciju, priručnik za korištenje, priručnik održavanja, upute za rastavljanje.

Planiranje proizvodnje povezuje uz proizvod način njegove proizvodnje, odnosno tehnologiju opisanu operacijama i zahvatima. U opisu tehnologije su obično uključeni i detaljniji crteži, NC programi, postupak kontrole kvalitete, postupak sklapanja, postupak pakiranja i drugi.

Proizvodnja stvara proizvod na temelju podataka pridruženih proizvodu u postupku planiranja proizvodnje. Pri tome se nerijetko dodaju novi podaci u opisima rađenih proizvoda. Primjerice, ukoliko se svaka instanca proizvoda provjerava zasebno, izvještaji provjere se pridružuju uz proizvode.

Naplata koristi podatke o prodanim proizvodima, njihovim cijenama, kupcima, uvjetima plaćanja, posebnim računima itd.

Naknadne usluge, poput održavanja i nadogradnje su sve značajnije u mnogim industrijama. Sve je češće potrebno zasebno pratiti životni vijek svake instance proizvoda, što je naročito izraženo kod složenijih proizvoda poput aviona, lokomotiva, brodova itd. Zbog toga sve više proizvođača prati sve zahvate održavanja i nadogradnje svojih proizvoda.

Naveden popis podataka nikako ne treba uzeti za konačni već kao slikoviti prikaz raznovrsnosti podataka vezanih uz proizvod.

4.3 NAČINI PRIKAZIVANJA PROIZVODA

Za bolje razumijevanje u nastavku pojašnjenih PDM funkcija te izvedbu odgovarajućih modela trezora podataka i upravljanja strukturom proizvoda unutar ERP sustava, nužno je ukratko razmotriti generacijske modele prikazivanja proizvoda. Promatrano vremenski moguće je uočiti tri generacije prikazivanja.

I. generacija: papirnati crteži

Koristi na papiru zapisane prostoručne skice i tehničke crteže. Iako je u mnogim aktualnim inačicama ERP sustava podržano referenciranje na papirnate crteže kroz praćenje oznaka crteža i njihovih formata, preporuka je izbjegavati u budućnosti papirnate crteže. Postojeće crteže za koje se pretpostavlja da će biti potrebni u proizvodnji potrebno je skeniranjem digitalizirati. Crteže koji će se naknadno koristiti u razvoju novih proizvoda još je prikladnije pretvoriti u vektorski zapis radi lakšeg korištenja.

Pregled stanja 36

II. generacija: digitalni crteži

Digitalno zapisane datoteke tehničkih (2D21) crteža rađenih u programima za računalom podržano crtanje22. Pretežno su to vektorski formati zapisa nastali u popularnim programima za tehničko crtanje AutoCAD (DWG23), MicroStation (DNG), MS Visio (VSD)…

Slika 4.1: CAD datoteke sklopljenog proizvoda

III. generacija: digitalni modeli

Velika većina24 modernih CAD sustava koristi više datoteka, ali i više vrsta datoteka za zapisivanje modela proizvoda (Slika 4.1). Primjerice, potporni sklop upotrebljen kasnije u poglavlju (Slika 4.6) hijerarhijski je izveden od jednog podsklopa (stezni vijak) sastavljenog od tri dijela te od još 6 dijelova. Samo za opis modela potpornog sklopa u prvoj razini su upotrijebljene 3 datoteke međusobno različitog formata:

21 U dvije dimenzije, projekcije u ravnini. 22 Stoga je u počecima primjene računala u dizajnu, popularna kratica CAD značila "Computer-Aided Drafting", odnosno računalom podržano crtanje. 23 Oznaka u nastavku imena datoteke – ekstenzija. 24 Izuzetak je Autodesk Mechanical Desktop kod kojega je moguće sve zapisati u istu datoteku.

Pregled stanja 37

1. Datoteka za model sklopa u kojoj su referencirane vanjske datoteke upotrijebljenih komponenti. Ujedno sadrži opis postavljenih geometrijskih odnosa među komponentama. U pravilu jedan sklopljeni proizvod sadrži samo jednu ovakvu datoteku.

2. Datoteka prikaza rastavljenog sklopa s prikazom razdvojenih komponenti i vodilica za sastavljanje. Također se za ove datoteke koriste izrazi poput datoteka prezentacije, scene ili montaže sklopa. Jedan sklopljeni proizvod može, ovisno o zahtjevima korisnika imati višestruke prikaze rastavljenog sklopa. U pravilu se sve prikaze zapisuje u istu datoteku tako da je odnos datoteka modela sklopa i datoteka prikaza 1:1. Iako je moguće svaki prikaz zapisati u vlastitu datoteku ta se mogućnost rijetko koristi pa su stoga na slici 4.1 simboli višestrukih datoteka prikaza istaknuti isprekidanim rubom i u blijedoj nijansi.

3. Datoteka tehničkih crteža sklopa sadrži tehničke crteže promatranog sklopa. Tehnički crteži sklopa izvode se iz prikaza rastavljenog sklopa ili izravno iz modela sklopa. Jedan sklopljeni proizvod može, ovisno o zahtjevima korisnika imati višestruke tehničke crteže sklopa. Kao i kod prethodnog tipa datoteke i kod ovog se u pravilu sve crteže zapisuje u istu datoteku tako da je odnos datoteka modela sklopa i datoteka crteža 1:1. Također je moguće svaki prikaz zapisati u vlastitu datoteku, premda se ta mogućnost rijetko koristi.

Navedeni načini raspoređivanja po datotekama koriste se i za sve podsklopove proizvoda. U promatranom slučaju, proizvod ima jedan podsklop za koji je razvijen jedan prikaz zapisan u jednoj datoteci te jedan crtež također u jednoj datoteci.

Modeli dijelova se pojedinačno zapisuju svaki u zasebnu datoteku posebnog formata zapisa. Za pojedini dio može biti pripremljen tehnički crtež također zapisan u zasebnoj datoteci. Osim izrade i zapisivanja modela dijela u zasebnu datoteku, većina CAD sustava nudi i mogućnost izrade modela dijela unutar datoteke sklopa, što je naročito prikladno kod oblikovanja novih komponenti na osnovu već postojećih u sklopu25. Međutim, takav "lokalni" model dijela izveden i zapisan u datoteci sklopa nije dostupan za primjenu u nekom drugom sklopu. Zbog toga se lokalne dijelove nakon izrade izlučuje izvan datoteke sklopa i zapisuje u zasebnu datoteku. Time postaju "vanjski" dijelovi koje je potom moguće umetati i u druge sklopove.

U razmatranju vrsta CAD datoteka, posebnu skupinu predstavljaju modeli standardnih i kataloških dijelova i sklopova. Modeli standardnih dijelova i sklopova se uglavnom isporučuju uz CAD sustav i mogu biti zapisani u istim formatima koje sustav koristi za korisničke modele ili pak u zasebnom formatu. Kataloški modeli vanjskih dobavljača pretežno su zapisani u posebnim ili neutralnim formatima. Više o formatima zapisivanja datoteka prostornih modela moguće je pronaći u literaturi [8, 31, 50]. Zajedničko objema skupinama modela jest da se za njih uglavnom ne rade tehnički crteži.

4.4 PDM POJAM

Prema izdavačkoj kući CIMdata, jednom od vodećih izdavača radova o PDM sustavima, upravljanje podacima o proizvodu (PDM) je alat koji pomaže inženjerima i drugima uključenim u razvoj proizvoda, u upravljanju podacima o proizvodu te u upravljanju razvojnim procesom proizvoda. PDM sustavi nastoje pratiti gomile podataka i informacija potrebnih za dizajn, proizvodnju ili izgradnju, potom i podržati i održavati proizvode [51].

25 Poznat kao pristup razvoja iz sredine prema van (eng. Middle-Out Assembly Design Approach).

Pregled stanja 38

Ungerer i Buchanan određuju PDM sustav u smislu STEP standarda kao nešto što upravlja podacima o proizvodu [52]. U središtu PDM informacija je identifikacija proizvoda dok sam proizvod u STEP-u predstavlja glavnu upravljanu stavku unutar PDM sustava. U STEP PDM shemi, o kojoj će u nastavku biti više riječi, opći koncept proizvoda se može tumačiti kao "dio" ili kao "dokument". Zbog takvog pristupa moguće je baratati dijelovima i dokumentima na dosljedan i paralelan način.

Opseg PDM pojma u pravilu obuhvaća nekoliko usko ciljanih područja vezanih uz razvoj proizvoda (Slika 4.2) pri čemu su određena područja usko povezana i često koriste iste podatke uz različito tumačenje i prikazivanje [53].

Slika 4.2: PDM područja [53]

Osim izraza PDM, moguće je u stručnoj literaturi naći i druge istoznačne izraze za promatrani pojam [44]. Iako PDM prevladava, još se koriste i: Product Information Management (PIM), Product Asset Management (PAM), Colaborative PDM (cPDm), Electronic Document Management (EDM), Technical Information Management (TIM), Technical Data Management (TDM)… Uz njih je moguće pronaći i druge kombinacije od riječi korištenih u njima. Prema Carrollu [54], svi spomenuti izrazi su tek sjene PDM-a za koje bi pojašnjavanje njihovih posebnosti oduzelo više vremena nego što je to vrijedno.

Međutim, izraz Product Lifecycle Management (PLM) koji se pojavljuje u novije vrijeme, odnosno unatrag par godina, zaslužuje poseban osvrt. U hrvatskom jeziku se uglavnom prevodi sa "upravljanje životnim ciklusom proizvoda" [55]. Povijesno gledano izraz je iskovan nakon gotovo dvadeset godina tržišnog i tehnološkog razvoja [56]. Prema opsegu, PLM je širi pojam koji u sebi obuhvaća i PDM kao osnovnu komponentu. Moguće ga je odrediti kao izraz koji opisuje poslovni pristup u stvaranju, upravljanju i korištenju intelektualnog kapitala i informacija povezanih s proizvodom kroz čitav životni vijek. Ipak, razvojno gledano, PLM je još uvijek više na razini poslovne inicijative koja pokušava obuhvatiti sve što je unutar dizajna i razvoja proizvoda uz dodano upravljanje projektima i proširenje na održavanje i podršku.

Slika 4.3 prikazuje položaj PLM koncepta prema prisutnim poslovnim rješenjima u poduzeću. Prema prikazu, izravne dodire i razmjenu podataka ostvaruje sa sustavima za odnose s kupcima (CRM26) i ERP sustavima, dok se sa sustavima za upravljanje dobavljačima (SCM27) podaci razmjenjuju posredno.

26 Od eng. Customer Relationship Management. 27 Od eng. Supply Chain Management.

Pregled stanja 39

Slika 4.3: PLM u odnosu na druga rješenja poduzeća [56]

4.5 OSNOVNE PDM FUNKCIJE

Funkcije PDM sustava moguće je razdijeliti na elektronički trezor podataka, korisnički skup funkcija i skup pomoćnih funkcija. Iako se razina i način primjene pojedinih PDM funkcija razlikuje od sustava do sustava, proteklih godina postignuta je suglasnost među brojnim autorima i dobavljačima o osnovnim funkcijama [44, 51, 57, 58].

74%

16%

3%3% 3%1%

Struktura i sastavnica proizvoda: 74%

Trezor podataka: 16%

Pregledavanje i odobravanje: 3%

Upravljanje konfiguracijom i promjenama: 3%

Upravljanje projektima: 3%

Ostale: 1% n = 115

Slika 4.4: Rezultati ankete o korištenim PDM funkcijama

Značaj pojedine implementirane funkcije za njegove korisnike može se uočiti analizirajući anketu koju je među svojim čitateljima provela tvrtka CIMdata [59]. Pitanje mrežne ankete je bilo: "Koje PLM funkcije vaši korisnici najviše upotrebljavaju?" Prema rezultatima ankete (Slika 4.4), anketirani su u najvećem udjelu (85/115) naveli funkcije upravljanja strukturom i sastavnicama proizvoda, potom je na drugom mjestu funkcionalnost trezora podataka (18/115), dok su sve druge funkcije dobile znatno manje glasova, svega zajedno 10 od ukupno 115 glasova. Iako anketa nije provedena na velikom broju ispitanika, u prilog njezinoj

Pregled stanja 40

vjerodostojnosti govori ugled tvrtke CIMdata među stručnjacima iz navedenog područja, objavljeni radovi28, te posjećenost njihovih stranica na Internetu.

U proširenju mogućnosti svojih sustava, dobavljači su u mnogim slučajevima dodavali i poneke funkcije koje se ne mogu jasno odrediti kao PDM funkcije. Među njima su i funkcije planiranja i terminiranja. U većini ERP sustava se podsustavi za planiranje i terminiranje razmatraju kao osnovni podsustavi pa se proizvođači i analitičari informacijskih sustava teško mogu složiti o njihovu razvrstavanju u PDM funkcije [10]. Stoga su izostavljene u narednoj analizi funkcija.

4.5.1 Trezor podataka

Osnovna funkcija PDM sustava je služiti kao elektronički trezor podataka o proizvodu. Pri tome riječ trezor vrlo dobro označava pohranu uz kontrolirani pristup podacima kao i mogućnost pohrane velike količine različitih tipova podataka o proizvodu. Promatrano na razini trezora, pohranjuju se dva tipa podataka [51]:

• Podaci o proizvodu stvoreni u različitim programima poput zahtjeva, prostornih ili plošnih računalnih modela, analitičkih podataka, zapisa održavanja i korisničkih uputa.

• Meta-podaci29 odnosno podaci o podacima [60], koji nose informacije o podacima upravljanim u PDM sustavu. Pohranjuju dodatne informacije o samim podacima o proizvodu, tako da je moguće pratiti i nadgledati promjene, izdanja, odobrenja i druge događaje nad podacima. Ujedno se meta-podaci koriste i za stvaranje odnosa između podataka o proizvodu, kako bi se informacije mogle grupirati i povezati po zajedničkoj primjeni i između proizvoda. Njihovom primjenom korisniku se olakšava pronalaženje potrebnih podataka.

U razmatranju implementacije funkcije trezora unutar ERP sustava, trezor podataka je funkcija koja se ne razlikuje uvelike od načina pohranjivanja podataka samog ERP sustava. Razlika je u tipovima podataka i njihovom korištenju. Podaci kojima barata ERP sustav u pravilu su relativno jednostavni strukturirani zapisi u bazi podataka ERP sustava koji većinom nastaju i dalje se obrađuju u samom sustavu. S druge strane, podaci o proizvodu koje pohranjuje trezor podataka PDM sustava rijetko nastaju unutar samog sustava, samo djelomice se obrađuju u sustavu i tada uglavnom na razini meta-podataka nego se uglavnom obrađuju u zasebnim aplikacijama poput CADME sustava, tabličnih kalkulatora, tekst-procesora i drugih.

4.5.2 Upravljanje razvojnim procesom

Funkcija upravljanja razvojnim procesom pomaže u kontroli procedura za upravljanje podacima o proizvodu i pruža mehanizme za poslovanje u interakciji s ljudima. U tom smislu se određuju i nadziru promjene u konfiguraciji proizvoda, definicijama dijelova, odnosima među podacima te u inačicama i varijacijama. Unutar sustava su određeni pojedinci ovlašteni za odobrenje promjena i sustav u sklopu ove funkcije mora omogućiti praćenje postupka odobrenja.

28 Primjerice, pretraživanje baze znanstvenih radova "Current Contents (razdoblje 1993 – 2004) po pojmu cimdata.af. (sva polja) daje 17 radova. 29 Izvorno na engleskom "Meta-data" – podaci o podacima, su određujući podaci koji pružaju informacije ili dokumentaciju o drugim podacima upravljanim nekom aplikacijom ili okruženjem.

Pregled stanja 41

Slika 4.5: Status i tok dokumenta, prilagođeno prema [51]

Funkcija upravljanja razvojnim procesom također treba omogućiti određivanje i upravljanje postupkom revidiranja i odobrenja promjena izvedenih na podacima o proizvodu. Postupak je određen kao niz događaja kroz koje se mora proći do odobrenja izmjena na podacima u proizvodu i objavljivanja odgovarajućeg izmijenjenog dokumenta (Slika 4.5).

4.5.3 Upravljanje strukturom proizvoda

Struktura proizvoda se uglavnom generira u CAD sustavima s podrškom za parametarsko modeliranje temeljeno na značajkama. Takvi sustavi redom podržavaju i hijerarhijski prikaz značajki, konstrukcijske geometrije i komponenti proizvoda. U razmatranju hijerarhije proizvoda u većini sustava komponente mogu biti pojedinačni dijelovi, poput dijelova "Držač potpornja:1", "Vijak rascjepa" u prikazanoj strukturi potpornja na slici 4.6. Brojčana oznaka uz komponentu upućuje pri tome da je riječ o komponenti definiranoj na drugom mjestu, u pravilu u drugoj datoteci, i pozvanoj odnosno instanciranoj u promatranom proizvodu. Svaka nova pojava iste komponente označava se s novim brojem uz ime komponente. Komponente mogu biti i sklopovi sastavljeni iz nekoliko dijelova, poput komponente "Stezni vijak" u promatranom proizvodu.

Nije rijedak ni pristup u kojemu se generiranja početne konceptualne strukture proizvoda vrši u samom PDM sustavu pa da se potom komponente "ostvaruju" odnosno razvijaju u određenom CAD sustavu.

Hijerarhijsko stablo proizvoda – strukturna sastavnica

Prihvaćen način prikazivanja strukture proizvoda je pomoću razvijenog hijerarhijskog stabla proizvoda koji se često zorno dočarava i razvijenim prikazom sklopa proizvoda. Strukturna sastavnica je izraz koji se često koristi u našem području za hijerarhijski prikaz strukture proizvoda.

Pregled stanja 42

Slika 4.6: Prikaz strukture proizvoda

Popis dijelova

Osim hijerarhijskog stabla, primjenjuje se i tablični prikaz strukture proizvoda – popis dijelova30. U pojednostavljenom prikazu strukture komponente su redom pobrojane u prikladnoj tablici kao što je prikazano u tablici na slici 4.7. Primjenjuje se pretežno na sklopnim crtežima proizvoda pri čemu se pojedine komponente označavaju brojevima iz popisa dijelova. Pri tome se u izrazu popis dijelova, riječju dio zapravo označava komponenta proizvoda, bilo da je riječ o podsklopu ili o pojedinačnom dijelu.

Slika 4.7: Popis dijelova

U proizvodnim poduzećima u kojima se paralelno koriste PDM i ERP sustavi, redovno se javlja potreba prijenosa popisa dijelova iz PDM u ERP sustav. Na ovu potrebu vodeći proizvođači u obje vrste sustava odgovorili su ponudom programskih rutina ili modula za prijenos popisa dijelova proizvoda. Uglavnom je riječ o rutinama za prijenos popisa iz jednog u drugi sustav ili je, u rjeđem slučaju, riječ o razmjeni popisa u oba smjera. Međutim, dijeljenje popisa dijelova između sustava nije jednostavno izvesti, naročito stoga što je nužno omogućiti praćenje promjena strukture proizvoda generirane na izvoru, najčešće u CAD sustavu.

30 Eng. "Parts List" i "Bill of Material"

Pregled stanja 43

4.5.4 Klasifikacija komponenti

Klasifikacija komponenti je jedna od funkcija koju uz PDM sustave u pravilu nude i ERP i CAD sustavi. Svi CAD sustavi srednje i visoke opsežnosti se u novije vrijeme isporučuju s već katalogiziranim bazama standardnih dijelova spremnih za primjenu u modelima proizvoda (Slika 4.8).

PDM i ERP sustavi uglavnom nude pripremljene rutine za razvrstavanje vlastitih i standardnih komponenti po strukturiranim katalozima. Katalozi su u početku uglavnom prazni i od korisnika u poduzeću se očekuje da u razdoblju uvođenja sustava ispune katalog razvrstavanjem komponenti.

Osim navedenih sustava, na tržištu su prisutni i otvoreni katalozi poput PowerParts kataloga [61], s gotovim modelima komponenti brojnih proizvođača. Iako im je osnovna svrha promidžba i unapređenje prodaje komponenti proizvođača, neupitna je njihova korist i za konstruktore koji komponente mogu jednostavno koristiti u svojim proizvodima.

Zbog mogućnosti klasifikacije komponenti u više sustava, kod korisnika se može pojaviti nedoumica koji od dostupnih kataloga koristiti. I u ovom slučaju, nedoumica vodi ka nastojanju reduciranja broja korištenih sustava. Međutim, neovisne kataloge poput PowerPartsa, nije praktično integrirati u vlastita rješenja već se pretežno koriste kakvi jesu. Ipak, takva primjena ostavlja otvoren problem dijeljenja podataka u više razina poduzeća.

Slika 4.8: Klasifikacija standardnih dijelova

4.5.5 Skup korisnih funkcija

Uz osnovne korisničke funkcije, PDM sustavi moraju ponuditi i niz dodatnih korisnih funkcija. Uobičajeno su u tom skupu uključene funkcije za komunikaciju i obavještavanje, prijenos i prijevod podataka, prikaz slika i administraciju sustava.

Komunikacijske mogućnosti pružaju mogućnost prijenosa poruka među korisnicima sustava i obavještavanja o bitnim događajima. Funkcije prijenosa podataka prate promjene mjesta podataka s jednog položaja na drugi ili od jedne aplikacije do druge. Prijevod podataka nastoji pružiti informacije u obliku prihvatljivom određenom korisniku. Administrativne funkcije pomažu u upravljanju te nadgledanjem rada i sigurnosti sustava [57].

Pregled stanja 44

4.6 ARHITEKTURA PDM SUSTAVA

PDM sustavi su uglavnom izvedeni na klasičnoj dvoslojnoj arhitekturi klijent-poslužitelj, ali se u novije vrijeme sustavi sve više raslojavaju i izvode u više slojeva31. Slika 4.9 prikazuje proširenu arhitekturu sustava. Prikaz je izveden pragmatičnom sintezom iz prikaza arhitekture Peltonena [49] i Dyle [62] uz razmatranje suvremenih pristupa u razvoju poslovnih sustava.

U osnovi se smješta upravljački sustav relacijske baze podataka (RDBMS32). Neki od poznatih komercijalnih upravljačkih sustava su Oracle, Microsoft SQL Server, Sybase SQL Server, IBM DB2 i Microsoft Access. Međutim, mnogi programeri se sve češće okreću stabilnim i besplatnim upravljačkim sustavima od kojih su vrlo popularni MySQL, PostgreSQL i Firebird [63].

Pod upravljačkim sustavom baze podataka može biti smještena baza dokumenata u koju se tada binarno pohranjuju dokumenti stvoreni u CADME ili uredskim aplikacijama. Pri tome se RDBMS ponaša kao datotečni sustav čiju ulogu preuzima. Međutim, prisutna su i brojna rješenja kod koji se dokumenti čuvaju izvan upravljačkog sustava baze podataka, uglavnom na računalima na kojima su izvorno nastali: umreženim CADME radnim stanicama ili uredskom osobnim računalima. U bazi meta-podataka čuvaju se apsolutne putanje do upravljanih dokumenata uz osiguranje odgovarajuće razine pristupa. Baza dokumenata pod RDBMS-om i upravljani dokumenti prikazani su na slici 4.9 isprekidanom rubnom linijom koja označava prethodne mogućnosti pohrane dokumenata. Razlog zbog koje su prikazane istovremeno je u tome što se koristi i hibridna izvedba u kojoj PDM sustavi u svojoj bazi dokumenata pohranjuju dokumente od primarnog tipa interesa, uglavnom CADME dokumente, dok se sekundarni tipovi dokumenata ostavljaju na računalima na kojima su stvarani. Ovakvi se PDM sustavi uglavnom izvode ili integriraju unutar CADME sustava i namijenjeni su pretežno za pomoć u razvoju proizvoda.

Slika 4.9: Proširena arhitektura PDM sustava

Ukoliko PDM sustav nije izveden na klijent – poslužitelj arhitekturi, tada se PDM poslužitelj izvodi u zasebnoj programskoj razini sastavljenoj od niza programskih modula. U takvoj izvedbi PDM poslužitelj kroz korisničko sučelje prima i odgovara na zahtjeve korisnika te izvodi operacije pristupanja prema RDBMS bazama, odnosno meta-podacima i upravljanim dokumentima.

31 Eng. Multi Tier Architecture, n-Tier Architecture 32 Eng. Relational Database Management System

Pregled stanja 45

Sve veća dostupnost i primjena Interneta, potakla je dobavljače da omoguće pristup sustavu kroz sveprisutne HTTP preglednike33. Time se korisnicima omogućava pristup iz gotovo svakog dijela svijeta u kojemu je moguć pristup Internetu, što je danas, uz pomoć komercijalne satelitske komunikacije, gotovo svaki dio planeta. Primjena HTTP protokola nadmašila je sva očekivanja pa su razvijeni posebni standardi u sklopu protokola za poslovne potrebe. Neki od standarda mogu biti dobar temelj za razmjenu podataka o proizvodu kroz ERP sustave i stoga su obrađeni u zasebnom poglavlju.

Pojedini dobavljači PDM sustava, spomenuti u poglavlju o pregledu stanja idu tako daleko da potpuno izbacuju klasičan pristup razvoja aplikacija i svoje sustave temelje u cijelosti na HTTP protokolu.

Razmatranjem arhitekture ERP sustava, lako je uočiti sličnosti s arhitekturom PDM sustava. Sličnost se očituje primarno u primjeni klijent – poslužitelj pristupa ili višeslojnog pristupa razvoja aplikacija. Kako je u oba slučaja riječ o poslovnim aplikacijama, primjena sličnih pristupa ne bi trebala biti iznenađenje. Sličnosti se mogu iskoristiti za reduciranje broja sustava i implementaciju određene funkcionalnosti iz jednog sustava u drugi, što je ujedno i jedan od ciljeva disertacije. Određene specifičnosti PDM sustava mogu otežati implementaciju njihovih funkcija u druge sustave. U tom kontekstu, naročito složeno može izgledati odnos prema CAD, ali i CAM34 i CAE35 sustavima. Zbog svojih specifičnosti, ovaj odnos je pobliže razmotren u nastavku.

4.7 ODNOS PREMA CAD SUSTAVIMA

Oh i drugi su u svojem radu analizirali moguće odnose PDM i CAD sustava [64], dok je Wehlitzova u disertaciji praktično razmotrila odnose PDM sustava prema relevantnim aplikacijama, primarno CADME sustavima [65]. Iz oba rada i iz pregleda PDM sustava vodećih dobavljača, spomenutih u poglavlju o pregledu stanja, može se zaključiti o nekoliko osnovnih odnosa prema CAD sustavima kroz integraciju podataka i korisničkog sučelja.

Integracija podataka ostvaruje se u nekoliko razina:

• ručni unos podataka;

• razmjena podataka kroz datoteku;

• samostalne baze podataka uz automatsko osvježavanje;

• dijeljena baza podataka.

Integracija korisničkog sučelja izvodi se također na nekoliko načina:

• PDM sustav povezuje CAD datoteke i pokreće CAD sustav;

• neke od PDM funkcija su dostupne na izbornicima CAD sustava;

• zasebno sučelje neovisno od CAD i PDM sustava;

• potpuno integrirano korisničko sučelje.

Navedene razine se mogu promotriti kroz tri pristupa u integraciji pojašnjena u nastavku.

33 Često se koristi i izraz "Web ili WWW preglednik", odnosno eng. Web-browser. 34 Od engl. Computer-Aided Manufacturing – računalom podržana proizvodnja. 35 Od engl. Computer-Aided Engineering – računalom podržano inženjerstvo.

Pregled stanja 46

4.7.1 Začahuren

Začahuren PDM sustav izvodi se kao samostalna aplikacija i ostvaruje vrlo nisku razinu integracije s drugim aplikacijama. U začahurenoj izvedbi se ne odvija prijenos meta-podataka između PDM baze podataka i aplikacija [66]. Izvodi se mogućnost pretraživanja dokumenata, pokretanje CAD aplikacija i zaključavanje dokumenata u slučaju otvaranja.

U smislu baratanja dizajnerskim datotekama, začahurivanje je proces obuhvaćanja više datoteka u jednu datoteku, direktorij ili mapu pod jednim zajedničkim imenom [67]. Često se umjesto izraza začahurivanje koriste i pakiranje, arhiviranje ili "zipanje"36, jer se u procesu obuhvaćanja datoteka ujedno i sažimaju radi zauzimanja manje prostora. Po sažimanju, arhiva se smješta u PDM bazu podataka uz korisničko dodavanje meta-podataka.

4.7.2 Sučeljen

U sučeljenom odnosu PDM i CAD sustav kao zasebne aplikacije razmjenjuju podatke bez potrebe za posredovanjem od strane korisnika uz izvođenje PDM sučelja unutar CAD aplikacije. Pri tome se ostvaruje jednosmjerna komunikacija od jednog sustava prema drugom. Pojedine PDM funkcije se dosižu pozivanjem stavki s izbornika unošenjem naredbi unutar CAD sustava, a izvode se i naredbe unutar PDM sustava koje pokreću odgovarajući CAD sustav.

4.7.3 Integriran

U integriranoj izvedbi PDM sustav se izvodi odnosno integrira svojim sučeljem unutar CAD sustava. Sve funkcije PDM sustava su dostupne unutar CAD sustava. Prisutna je automatska razmjena podataka o proizvodu između baza podataka dva sustava.

4.7.4 Hibrid

Osim prikazana tri osnovna pristupa u integraciji sustava, dobavljači izvode i hibridna rješenja u kojima međusobno kombiniraju dva ili sva tri pristupa. U slučaju kada isti dobavljač razvija i CAD i PDM sustav (npr. PTC Pro/ENGINEER i Pro/INTRALINK) obično je dostupna puna integracija u vlastiti CAD sustav. Prema CAD sustavima drugih dobavljača primjenjuje se tada jedan od preostala dva pristupa ili se međusobno kombiniraju.

Izvedbeni odnosi PDM sustava prema CAD sustavima su naročito zanimljivi u smislu disertacije, jer je jedna od namjera u razvoju modela dijeljenja podataka o proizvodu, reducirati broj računalnih poslovnih sustava uključenih u razvoj proizvoda. U tu svrhu se namjerava izostaviti PDM sustav i nadoknaditi odgovarajućom funkcionalnošću. Stoga je bilo nužno uočiti bitne funkcije specifične za aktualne PDM sustave kako bi se moglo predložiti model s analognom funkcionalnošću, ali izveden u sklopu ERP sustava sa svim posebnostima novog radnog okruženja.

4.8 ODNOSI PREMA DRUGIM POSLOVNIM SUSTAVIMA

Većina dobavljača nastoji u svojim PDM sustavima omogućiti razmjenu podataka s drugim poslovnim sustavima s konačnim ciljem integracije poslovnih aplikacija37. U poglavlju o pojašnjenju PDM pojma (4.4) prikazana je ilustracija odnosa PLM inicijative prema drugim

36 Po poznatom algoritmu i programu za sažimanje te na taj način sažetoj ZIP datoteci. 37 Odnedavno se u velikoj mjeri koristi engleski izraz "Enterprise Application Integration" i kratica EAI.

Pregled stanja 47

poslovnim sustavima (Slika 4.3). Ilustracija daje uvid u položaj, ali ne i u pristupe koji se koriste u razmjeni podataka.

Nekoliko pristupa prevladava u nastojanjima povezivanja i integracije poslovnih sustava općenito, a što također vrijedi i u odnosima PDM sustava prema drugim poslovnim sustavima:

• povezivanje na razini baze podataka,

• povezivanje na razini korisničkog sučelja,

• povezivanje kroz sabirnicu poruka38.

Kod povezivanja na razini baze podataka, PDM sustav se izvodi tako da u što većoj mjeri koristi zajedničku bazu podataka s drugim poslovnim sustavima. Primjerice, ukoliko poduzeće koristi ERP sustav razvijen nad Oracle bazom podataka, dobavljač PDM sustava izvodi zapisivanje podataka u istu bazu i pri tome nastoji koristiti strukturu zapisa kompatibilnu s korištenim ERP sustavom. Osim povezivanja na razini baze podataka, većina dobavljača PDM sustava nudi i zasebne module namijenjene povezivanju njihovog proizvoda s vodećim ERP sustavima. Primjerice u poglavlju o pregledu stanja naveden je proizvod SmarTeam – Gateway s modulima za povezivanje sa sustavima SAP R/3, (SmarTeam-SA Adapter) i Oracle Applications 11i (SmarTeam-OA Adapter).

Povezivanje na razini korisničkog sučelja se izvodi na jednak način kao i kod odnosa s CAD sustavima s mogućnošću pozivanja naredbi jednog sustava kroz sučelje drugog.

Aktualna razmatranja daju prednost integraciji poslovnih sustava kroz sabirnicu poruka [63]. Sabirnica poruka omogućava povezivanje brojnih odvojenih sustava pri čemu pojedini sustav može odašiljati poruke u sabirnicu, ali se također može predbilježiti za primanje pojedinih poruka iz sabirnice. Ovakvim načinom povezivanja, svaka aplikacija treba samo jednu vezu – prema sabirnici, umjesto povezivanja sa svakim pojedinim poslovnim sustavom u poduzeću. Kako je riječ o novom pristupu koji je još u fazi razvoja i usvajanja, dobavljači PDM sustava intenzivno rade na razvoju i implementaciji pristupa preko sabirnice poruka. Implementaciju sabirnice poruka dodatno otežava veliki broj dostupnih raznovrsnih tehnologija orijentiranih na slanje poruka, kao i tehnologija za prikaz podataka.

4.9 STEP PDM SHEMA

STEP PDM shema je referentni informacijski model za razmjenu središnjeg, zajedničkog skupa podataka upravljanih PDM sustavom nastala kao rezultat zajedničkog razvoja tvrtki ProSTEP i PDES. Shema predstavlja presjek zahtjeva i strukture podataka iz područja STEP aplikacijskih protokola (Slika 4.10), pri čemu su svi unutar domena dizajna i razvoja diskretnih strojarskih ili elektrotehničkih dijelova i sklopova [52]. Shema je izvedena kao skupna jezgra STEP entiteta tako da podržava preslikavanje PDM koncepta.

PDM shema podataka se može razmatrati kao skup funkcionalnih jedinica39, koje se slikovito mogu prikazati i pomoću UML paketnog dijagrama (Slika 4.11). U dijagramu su prikazane glavne međuovisnosti paketa pri čemu se ne isključuju i sporedne ovisnosti koje postoje između objekata među paketima. Svi objekti odnosno entiteti i njihove međusobne ovisnosti prikazane su u potpunom dijagramu objektnog modela sheme [68] u dokumentu zapisanom na mediju priloženom uz disertaciju. Osim funkcionalnih jedinica, u shemi se koristi i paket, odnosno skup entiteta za mjere i mjerne jedinice koje koriste gotovo svi drugi paketi, ali se ne promatra kao samostalna funkcionalna jedinica. U shemi se opći koncept proizvoda tumači

38 Izvorno engleski: "Message Bus". 39 Izvorno eng. Unit of Functionality (UoF).

Pregled stanja 48

bilo kao dio bilo kao dokument, čime se postiže dosljedno i paralelno upravljanje dijelovima i dokumentima.

Slika 4.10: PDM shema kao presjek aplikacijskih protokola [47]

Premda je izvedena u cilju promicanja među-operativnosti između pojedinih STEP aplikacijskih protokola, sama shema nije izdvojena kao zaseban standard. Štoviše, još ne postoji aplikacijski protokol koji implementira čitav PDM sustav pa STEP ne pruža potpun prikaz proizvoda na način kakav pružaju PDM sustavi [69]. Svjesni ograničenja STEP PDM sheme, skupina poduzeća predložila je vlastitu inačicu pod nazivom Joint Product Data Management (JPDM) shema podataka [70].

Slika 4.11: Skup funkcionalnih jedinica STEP PDM sheme

Pregled stanja 49

Iako je sama shema nepotpuna, primjena STEP modela podataka radi organizacije podataka primijenjena je u više PDM sustava. U pojedinim slučajevima primjene se nastojalo implementacijom sheme omogućiti prijenos podataka poput sastavnice materijala, opisa komponenti i dokumenata između poduzeća [71].

Samo kratak prikaz i opis svih entiteta sheme prostirao bi se na povećem broju stranica, jer se primjerice sam EXPRESS-G prikaz entiteta proteže na 40 A4 stranica [72], dok je puni opis sheme u izvornom priručniku prikazan na 277 stranica [52]. Predloženi model dijeljenja podataka o proizvodu kroz ERP sustave nastojat će biti izveden tako da u što većoj mjeri opisuje proizvod koristeći odgovarajuće entitete STEP PDM sheme ili njima analogne entitete odnosno objekte. Zbog toga su u nastavku prikazani odabrani entiteti uz kratak opis značenja i primjene.

4.9.1 Identifikacija komponenti

Identifikacija proizvoda u shemi je sastavljena od tri različita pojma koji u sebi objedinjuju entitete potrebne za identifikaciju (Slika 4.12):

• Glavna identifikacija komponenti – Omogućava jedinstveno označavanje komponenti i u sebi sadrži entitete koji sadrže: osnovni broj komponente (eng. Base Identification); oznaku inačice ili verzije komponente (Version Identification,); informaciju koja određuje definiciju pogleda na komponentu u smislu područja primjene ili faze životnog ciklusa (View Definition). Pri tome označena komponenta može biti dio ili sklop proizvoljne složenosti.

• Informacije o kontekstu – Pružaju nužne pretpostavke za pravilnu interpretaciju informacije o identifikaciji proizvoda. Izvedene su iz dva razdvojena ali međusobno povezana područja. Oznaka protokola primjene (Application Protocol Identification) sadržana je u entitetu application_protocol_definition i pruža podatke o STEP specifikaciji koja uključuje ili koristi PDM shemu te na taj način definira općeniti kontekst razmjene podataka. Informacije o području primjene (Application Context Information) određuju primjenu informacija unutar područja PDM sheme

• Klasifikacija tipa – Omogućava razlikovanje komponenti proizvoda između fizičkih dijelova i strukturiranih dokumenata, ali također i razlikovanje između vrsta komponenti poput detalja, sklopa ili standardnih dijelova.

4.9.2 Svojstva komponenti

U shemi je omogućeno određivanje svojstava proizvoda i komponenti. Svojstvo je određeno kao posebna odlika i može odražavati fizikalnu ili proizvoljnu, korisnički određenu značajku. Svojstva određena u shemi podijeljena su po grupama:

• Opća svojstva – S objektima i članovima prikazanim na slici 4.13. sadrži svojstva vezana uz nositelje informacija o proizvodu, neovisna svojstva ili predefinirana svojstva kao što su masa, kvaliteta površine, cijena, trajnost, materijal. Osnovni objekt property_definition predstavlja svojstvo koje obilježava komponentu. Vezu između tako definiranog svojstva i prikaza tog svojstva opisuje objekt property_definition_representation. Objekti representation, representation_context i measure_representation_item definiraju način prikaza svojstva i njegovu brojnost.

Pregled stanja 50

Slika 4.12: Objekti za identifikaciju komponenti

• Vanjski oblik komponente – Svojstva vezana uz oblik komponente i datoteke koje čuvaju geometriju.

• Vanjska struktura geometrijskih modela – Svojstva koja opisuju razmještaj komponenti u proizvodu, odnosno orijentaciju i pozicioniranje komponenti u sklopu.

Pregled stanja 51

Slika 4.13: Objekti za definiranje općih svojstava

4.9.3 Struktura i odnosi komponenti

STEP PDM shema podržava prikaz sklopova i elemenata sklopova kroz eksplicitnu hijerarhijsko stablo komponenti koje čine proizvod. Time se ostvaruje prikaz strukture koji odgovara prikazu u tradicionalnim sastavnicama.

Odnosi između komponenti mogu biti višeznačni. Jednostruko pojavljivanje sastavne komponente u definiciji nadređene komponente opisuje entitet next_assembly_component_usage (Slika 4.14).

Ukoliko se pojedina komponenta pojavljuje više puta u sastavu druge komponente dostupna su dva načina opisivanja: ponavljanjem entiteta next_assembly_component_usage ili primjenom entiteta quantified_assembly_component_usage. Mogućnost pristupanja pojedinoj komponenti određuje izbor jednog od navedena dva entiteta.

Pojava komponente unutar sklopa više razine koji nije izravno roditelj komponente, u slučaju kada nije razvijena detaljna struktura sklopa između komponente i sklopa više razine, predstavlja se pomoću entiteta promissory_usage_occurrence. Navedeni entitet u tom slučaju određuje namjeru korištenja elementa u sklopu. Također se može upotrijebiti ukoliko struktura proizvoda nije potpuno određena.

U cilju razlikovanja višestruke pojave pojedine komponente u sklopu s više od dvije hijerarhijske razine, koristi se entitet specified_higher_usage_occurrence. Entitet osigurava zasebnu oznaku svakoj instanci komponente uz dodatne atribute za detaljnije određenje posebnosti instance.

Shema omogućuje razlikovanje između alternativnih i zamjenskih komponenti. Alternativne komponente su zamjenjive u svim pojavama komponente dok zamjenske mogu biti zamijenjene samo pod određenim okolnostima. Alternativne komponente se predstavljaju kroz entitet alternate_product_relationship, dok se okolnosti u kojima se može upotrijebiti zamjenska komponenta određuju kroz entitet assembly_component_usage_substitute.

Dvije vrste odnosa između inačica proizvoda su predviđene za prikaz razvoja inačica: slijedni odnos i hijerarhijski odnos. U slijednom odnosu aktualna inačica ima prethodnu inačicu, a mora vrijediti i obrnuti odnos tako da prethodna ima narednu slijednu inačicu. U hijerarhijskom odnosu promatrana inačica komponente je podređena inačica njoj nadređenoj inačici, a obje

Pregled stanja 52

moraju biti povezane s glavnom bazom komponente. Obje vrste odnosa se izvode kroz entitet product_definition_formation_relationship.

Slika 4.14: Objekti strukture i odnosa komponenti

4.9.4 Identifikacija dokumenata

Shema barata s dokumentima kao s proizvodima, što je analogno prethodno prikazanom pristupu dijelovima odnosno komponentama kao proizvodima. Stoga se i za identifikaciju dokumenata koriste ista tri pojma kao kod identifikacije komponenti opisanih u poglavlju 4.9.1: glavna identifikacija dokumenata, informacije o kontekstu i klasifikacija tipa. Pri tome se u klasifikaciji tipa navodi strukturirani dokument umjesto komponente.

Pregled stanja 53

4.9.5 Vanjske datoteke

Vanjske datoteke u PDM shemi predstavljaju jednostavne vanjske reference na imenovane datoteke. Međutim, vanjska datoteka može označavati i digitalnu datoteku, ali i fizički odnosno papirnati dokument. Za razliku od strukturiranih dokumenata kojima se upravlja kao s proizvodima, vanjskim datotekama se ne upravlja kroz STEP PDM sustav.

Vanjska datoteka je jednostavno vanjska referenca koja može biti povezana s drugim podacima o proizvodu. Dokument ili upravljana datoteka može biti povezana s vanjskom datotekom kao s označenim upravljanim dokumentom.

Identifikacija vanjske datoteke izvodi se kroz entitet document_file, koji je podtip entiteta document i entiteta characterized_object (Slika 4.15). Potonji dopušta pridruživanje svojstava uz identifikaciju vanjske datoteke.

4.9.6 Odnosi dokumenata i sastavnih datoteka

U pristupu dokumentu kao prema proizvodu, definicija pogleda se koristi radi predstavljanja definicije prikaza pojedinog dokumenta. Podrška zahtjevu za dokumentom kao proizvodom s povezanom vanjskom datotekom u sastavu izvedena je kroz entitet product_definition_with_associated_documents (Slika 4.16) zajedno s entitetima za identifikaciju vanjskih datoteka navedenih u prethodnom poglavlju. Time je omogućeno upravljanje i praćenje promjena te izravno odražavanje promjene sastavne datoteke u definiciji nove inačice dokumenta.

Slika 4.15: Objekti vanjskih datoteka

4.9.7 Svojstva dokumenata i datoteka

U shemi svojstva dokumenata mogu biti povezana s prikazom i dokumenata i pojedinačnih datoteka. Ukoliko je svojstvo dokumenta pridruženo prikazu dokumenta, značajke

Pregled stanja 54

se u većini slučajeva pridružuju i na sastavne datoteke. Međutim, neka svojstva s brojčanim vrijednostima, poput veličine datoteke ili broja stranica, primijenjena na prikaz dokumenta neće odgovarati pojedinačnoj datoteci u prikazu dokumenta sastavljenog iz više datoteka već će odgovarati zbroju svih datoteka koje sačinjavaju definiciju prikaza pojedinog dokumenta. Kako bi se izbjeglo ponavljanje preporučeno je izravno povezivanje svojstava dijeljenih u svim sastavnim datotekama danog prikaza dokumenta s prikazom dokumenta umjesto s pojedinačnom datotekom.

Općenita shema pridruživanja svojstava prikazu dokumenata ili datotekama odgovara shemi za definiranje svojstava fizičkih komponenti (Slika 4.13). Izvodi se instanciranjem stabla definicije svojstava s entitetima property_definition, property_definition_representation, representation te eventualno višestrukim instanciranjem entiteta descriptive_representation_item ili measure_representation_item. Neka od svojstava karakterističnih za vanjske datoteke su:

• Sadržaj dokumenta – Poziva se kroz entitet representation izrazom representation.name = 'document content'. Opisuje razinu prikaza prostornih detalja, tipove sadržanih geometrijskih objekata, jezik i stvarno mjerilo.

• Nastanak dokumenta – Analogno prethodnom svojstvu, poziva se izrazom representation.name = 'document creation'. Opisuje sučelje u kojemu je zapisan dokument (npr. PostScript), aplikaciju u kojoj je stvoren (npr. MS Word) i operativni sustav u kojemu je nastao (nrp. MS Windows XP).

• Format dokumenta – Opisuje format zapisa (npr. DXF, IGES, TIFF…), kodiranje znakova i veličinu formata.

Slika 4.16: Objekti odnosa dokumenata i sastavnih datoteka

• Veličina dokumenta – Veličina digitalno pohranjenog dokumenta ili broj stranica dokumenta.

Pregled stanja 55

• Izvor dokumenta – Puno ime datoteke s putanjom, URL40 adresa ili ISBN41 oznaka fizičkog dokumenta.

4.9.8 Veza dokumenata i datoteka s podacima o proizvodu

U pristupu "dokument kao proizvod" koji se primjenjuje u shemi, dokumenti i vanjske datoteke moguće je povezati s podacima o proizvodu odnosno sa fizičkim komponentama. Veza se ostvaruje na dosljedan način uz upotrebu reference primjene s određenom ulogom. Referenca primjene je strukturalno izvedena pomoću entiteta sheme document i applied_document_reference (Slika 4.17).

Slika 4.17: Objekti povezivanja dokumenata s podacima o proizvodu

Prilikom povezivanja upravljanog dokumenta s podacima o proizvodu, temeljni dokument se povezuje fizičkom komponentom koristeći dodatni entitet document_product_equivalence. Pri tome je inačica dokumenta razina koja se preporučuje za povezivanje temeljnog dokumenta s drugim podacima o proizvodu.

Vanjske datoteke također mogu biti povezane s podacima o proizvodu na način koji je jednostavniji, ali strukturalno dosljedan onom korištenom za dokumente, uz primjenu entiteta applied_document_reference.

40 Od eng. Uniform Resource Locator – standardizirana adresa resursa na Internetu. 41 Od eng. International Standard Book Number – jedinstvena međunarodna oznaka knjige.

Pregled stanja 56

4.9.9 Autorizacija

U sklopu PDM sheme organizacija razvojnog tima i ljudi u organizaciji prikazani su prema zadaćama koje provode nad proizvodnim podacima i nad odnosima među podacima. Osoba u shemi mora biti zavedena u određenoj organizaciji što se izvodi kroz entitet person_and_organization (Slika 4.18). Entitet applied_person_and_organization_assignment omogućava postavljanje obaveznog odnosa između osoba ili organizacija s podacima o proizvodu. Određivanje uloge pridružene osobe ili organizacije prema podacima o proizvodu prikazuje se entitetom person_and_organization_role. Uz svaku osobu i organizaciju proizvoljno se kroz odgovarajuće entitete personal_address i organizational_address može nadovezati adresa.

Slika 4.18: Objekti povezivanja osoba i organizacija s podacima o proizvodu

Osim povezivanja osoba i organizacija s podacima o proizvodu, u ovom dijelu sheme,

odnosno u funkcionalnoj jedinici autorizacije izvedeni su i entiteti za vremensko praćenje događaja, status i tok dokumenata ili ciklus odobrenja (Slika 4.5), određivanje razine sigurnosti i certificiranje komponenti.

Ciklus odobrenja se ostvaruje postavljanjem entiteta approval i njegovim povezivanjem s određenim elementom kroz entitet applied_approval_assignment. Potonji može imati pridruženu ulogu kroz entitete role_association i object_role kako bi se pojasnio razlog ili uloga odobrenja u odnosu na pojedini element podataka o proizvodu. Odobrenje može biti izvedeno kao jednostavno ili kamo složeni ciklus odobrenja koji uključuje više osoba u različitim datumima i s različitim statusima.

57

5 IZVEDBA INFORMACIJSKOG MODELA

Model proširenja funkcionalnosti ERP sustava u cilju dijeljenja podataka o proizvodu zahtijeva promišljanje i kritički odabir prilagođenih varijanti PDM funkcija analiziranih u poglavlju o PDM konceptu uz promišljanje o modernim računalnim i naročito mrežnim tehnologijama. Konformistički i nekritički pristup bi mogao dovesti do implementacije u sustav funkcija koje zahtijevaju značajan napor za njihov razvoj, da bi potom po implementaciji i instalaciji sustava iste bile rijetko ili možda čak nikad upotrijebljene. Analogno bi se moglo dogoditi i pri brzopletim nastojanjima u primjeni novih računalnih tehnologija.

Neki od kriterija odabira funkcionalnosti za izvedbu modela uključivali su: analizu ciljanih korisnika sustava, značaj pojedine funkcije za korisnika, značaj pojedine funkcije za sustav i mogućnost usklađivanja s ISO STEP PDM shemom.

Ciljani korisnici funkcija za podršku razvoju proizvoda unutar ERP sustava jesu razvojni inženjeri ili kako se obično nazivaju - konstruktori malih i srednjih proizvodnih poduzeća. U takvim poduzećima u razvoju novog ili pri unapređenju postojećeg proizvoda u pravilu ne sudjeluje veliki broj konstruktora niti razmješteni razvojni timovi, već nekoliko konstruktora smještenih u istom konstrukcijskom odjelu. Nije rijetko da u malim proizvodnim poduzećima bude zaposleno svega par konstruktora, a pri tome poduzeće ima dobru proizvodnju i prihode. Osim toga, manja proizvodna poduzeća u zemljama u razvoju nerijetko rade proizvode po narudžbi za druga poduzeća dajući pri tome samo uslugu proizvodnje, dok je proizvod razvijen u poduzeću naručitelja. Iako u tom slučaju nema potrebe za samostalnim razvojem proizvoda, ostaje jasna potreba za dijeljenjem podataka o proizvodu (struktura, datoteke modela, crteži) radi pripreme i planiranja proizvodnje. Slična potreba se pojavljuje i u slučajevima kada poduzeće uz vlastiti konstrukcijski odjel koristi i usluge drugih poduzeća u cilju razvoja proizvoda. Primjerice, nerijetko se konstruktori iz poduzeća obraćaju fakultetima za pomoć u razvoju proizvoda, bilo da im je potreban stručni savjet ili analiza i dizajn u nekom od CADME paketa kojeg nemaju u svojem poduzeću. U svakom slučaju, trag suradnje odnosno rezultat usluge trebao bi biti zapisan uz proizvod unutar ERP sustava.

Prikazani model treba promatrati kao moguće prijelazno rješenje za promatrane ERP sustave na putu prema usklađenosti s ISO STEP PDM shemom. Svrha pak usklađenosti sa shemom je postizanje modela potpunog informacijskog povezivanja procesa, odnosno prema [71] do Modela V. U navedenom modelu integracije podataka, podaci o proizvodu se kroz čitav životni ciklus proizvoda pohranjuju u istom formatu, primjerice STEP formatu. Takvim pristupom bi se u budućnosti omogućio prijenos svih tipova podataka o proizvodu između različitih poduzeća uključenih u proizvodnju pojedinog proizvoda. U prijelaznom razdoblju, u kojemu brojna poduzeća u okruženju tek uvode poslovne informacijske sustave, implementirana rješenja nužno moraju podržavati te olakšati organizaciju poslovanja i u poduzećima u kojima su još u primjeni prethodni modeli. Počevši od prvog modela u kojemu papirnati dokumenti kruže poduzećem i nose sve informacije o proizvodu pa sve do četvrtog modela u kojemu se papirnati dokumenti više ne koriste kao referentni zapis, nego eventualno kao pomoćni prikaz.

Međutim, put prema usklađenosti sa shemom ne povlači potrebu za punom implementacijom svih entiteta odnosno objekata sheme. Razlog je jednostavan: punom implementacijom entiteta sheme ne postiže se model potpunog informacijskog povezivanja. Pojednostavljeno napisano, promatramo li dva informacijska sustava za upravljanje podacima o proizvodu, oba oblikovana uz punu implementaciju entiteta sheme, ipak će u svakome od njih biti toliko međusobnih razlika da će nužno biti potrebno pisati dodatni programski kod kako bi se

Izvedba informacijskog modela 58

omogućila razmjena podataka o proizvodu među njima. Unatoč navedenom, za očekivati je da će se napor uložen u što dosljedniju primjenu sheme u pojedini informacijskih sustav, isplatiti u narednom desetljeću. U tom razdoblju se može očekivati da će se primjena STEP standarda proširiti s uskog CADME područja primjene i na druge informacijske sustave koji se pojavljuju u proizvodnji.

Značaj pojedine implementirane funkcije za korisnike moguće je uočiti analizirajući anketu prikazanu u poglavlju o analizi PDM koncepta. Značaj za ERP sustav se mora oslikati kroz korist povezanu uz unapređenje razvoja proizvoda u smislu smanjenih troškova razvoja, skraćenja vremena do prodaje proizvoda, boljeg zadovoljenja kupčevih zahtjeva i drugih.

5.1 MODEL PROIZVODA

U prethodnom poglavlju je prikazano poimanje proizvoda u sklopu PDM koncepta, odnosno pobliže, u sklopu ISO STEP PDM sheme. Poimanje proizvoda unutar promatranih ERP sustava je slično navedenom konceptu, ali ipak uz znatne razlike. Razlike su proizašle iz višegodišnjeg samostalnog razvoja ERP sustava za specifična poduzeća, ali i potrebe za upravljanjem svim resursima poduzeća kroz sustav. Stoga je u nastavku postavljen model proizvoda promatranih ERP sustava na temeljima koje je postavio profesor Majdandžić [10], uz smjernice za postepeno usklađivanje s PDM shemom što bi u konačnici trebalo omogućiti dijeljenje podataka o proizvodu i u širem poslovnom okruženju poduzeća. Prikazani model ne uključuje doslovce sve entitete koji se pojavljuju, jer se konkretno primijenjeni modeli međusobno razlikuju u pojedinim slučajevima implementacije sustava. Osim toga, pojedini entiteti će biti prikazani u drugim prikazima kasnijih modela. Stoga je ovdje izložena zajednička osnovica modelima proizvoda za proizvodna poduzeća.

Slika 5.1: Odnosi proizvodnih elemenata

U promatranim ERP sustavima proizvodnih poduzeća, prilikom definicije proizvoda u osnovi sustava je postavljen opći pojam "proizvodni element". Proizvodni element je pri tome osnovni element u definiciji proizvoda koji se pojavljuje u proizvodnji i prema kojemu se raspoređuju resursi poduzeća. To je ujedno i osnovni element kojime se barata u podsustavu za definiciju proizvoda i tehnologije DEPTO. U objektnom orijentiranom pristupu, proizvodni element se može promatrati kao apstraktna klasa od koje izvedene klase nasljeđuju osnovne atribute i metode. Pristup se može pojednostavljeno prikazati pomoću UML zapisa (Slika 5.1).

Osim kroz atribut Vrsta koji služi s određenje pojedinog proizvodnog elementa, drugi način određenja elementa moguć je u objektnom smislu kroz programsku strukturu, instanciranjem objekta odgovarajuće klase, kao što je prikazano za proizvod na primjeru izvedenom u programskom jeziku C++ (Slika 5.2).


class ProizvodniElement { public: String IB; String Naziv; char UlogauProizvodu; virtual int UpisiUBazu() = 0; //…ostali podaci i funkcije klase } class Proizvod : public ProizvodniElement { //konstruktor Proizvod(String ib, String ime); int UpisiUBazu() { //kod funkcije za upisivanje u bazu } //…ostali podaci i funkcije klase } //aplikacija int main() {

//instanciranje novog proizvoda u aplikaciji: Proizvod Pr("152-27", "Reduktor"); Pr.UpisiUBazu();

}

Slika 5.2: Primjer instanciranja proizvoda

Osnovna značajka ili osnovni atribut proizvodnog elementa unutar sustava je njegova jedinstvena oznaka unutar ERP sustava. Izrazi koji se koriste za jedinstvenu oznaku unutar sustava ovise o pojedinom naručitelju sustava, a među uobičajenima su identifikacijska šifra, identifikacijski broj (IB) ili šifra elementa. Logika zapisivanja u bazu podataka i izvedba modula koji koriste jedinstvenu oznaku mora voditi računa da se ne naruši jedinstvenost oznake. Iako mnogi korisnici teže takozvanim "govorećim šiframa", u preporukama ISO STEP PDM sheme navedeno je kako jedinstvena oznaka ne bi trebala biti predmet bilo kakvog kodiranja informacija u obliku složenog niza znakova [52].

Naziv proizvodnog elementa je nakon jedinstvene IB oznake, drugi temeljni atribut koji bitno pomaže korisnicima u razlikovanju elemenata iako u smislu razvoja aplikacije nema veliku ulogu. U mnogim sustavima će tako biti omogućeno imati proizvode s istim nazivom, ali različitim IB oznakama.

Atribut Porijeklo određuje da li je riječ o vlastitom proizvodnom elementu ili se dobavlja od vanjskih dobavljača. Ukoliko se element dobavlja izvana uglavnom se tumači i koristi kao standardni element te se za njega uglavnom ne izvodi posebna dokumentacija, ali se datoteka modela elementa može zapisati uz element radi primjene u modelu proizvoda u kojemu se upotrebljava.

Atribut UlogauProizvodu pomaže u određivanju uloge koju pojedini proizvodni element može imati u proizvodu prilikom isporuke. Tako je moguće da proizvodni element bude dio ili sklop izravno ugrađen u proizvod, što je redovna ili normalna uloga.

Međutim, element može biti zamjenski odnosno rezervni ili alternativni koji se isporučuje uz proizvod. Iako ne sudjeluje izravno u strukturi proizvoda, zamjenski element se pojavljuje u popisu sastavnih elemenata proizvoda i isporučuje s proizvodom. Primjerice, uz mobilni telefon proizvođač može kupcu u paketu ponuditi i nekoliko zamjenskih prednjih maski u različitim bojama i oblicima, kako bi ga privukao na kupnju njegovog uređaja. Drugi primjer je dodavanje kompleta rezervnih ispisnih glava uz robusne pisače, za koje je proizvođač ustanovio


da ih je potrebno mijenjati unutar jamstvenog roka. Time se izlazi kupcu u susret i čuva njegovo povjerenje u proizvod, jer ne mora u jamstvenom roku čekati na isporuku ispisnih glava.

Najzad, i samo pakiranje odnosno ambalaža u kojoj se proizvod isporučuje pripada proizvodu kao proizvodni element. Pakiranje se zbog složenosti proizvoda ili samog pakiranja može unutar sustava promatrati kao podređeni element s vlastitom strukturom u sklopu proizvoda. Ukoliko je riječ o uobičajenom odnosno standardnom pakiranju (palete i sl.) za koje nije potrebno posebno razvijati modele kao za proizvodne elemente tada nije nužno da se pojavljuje u strukturi proizvoda već ju je moguće navesti u normativima proizvoda odnosno u popisu elemenata slično rezervnim dijelovima.

Osim entiteta koji se pojavljuju u opsegu definicije i razvoja proizvoda, zbog svoje primjene u proizvodnim poduzećima, ERP sustavi također sadrže i entitete potrebne za određivanje tehnologije proizvoda. Iako značajni u smislu proizvodnje, ove entiteti premašuju opseg teme disertacije te stoga njihov model neće biti razvijan niti pojašnjen. Iscrpan prikaz aktualnog modela definiranja tehnologije unutar ERP sustava dostupan je u literaturi [10].

5.2 MODEL TREZORA

Pojam trezora razvojnih podataka označava model pohranjivanja podataka o proizvodu unutar ERP sustava uz kontrolirani pristup i praćenje izmjena. Pri tome su okviru teme disertacije zbog svojeg značaja u razvoju proizvoda i određivanju njegove strukture, u prvom redu zanimljivi dokumenti odnosno datoteke CAD sustava, a potom i dokumenti iz drugih izvora42 uz pridruživanje odgovarajućih atributa (meta-podataka) uz svaku zapisanu datoteku dokumenta. Kako je datoteka formatirani zapis dokumenta na disku ili u bazi podataka, a većina dokumenata kojima se barata u modernoj proizvodnji pa tako i u ERP sustavima je digitalno zapisana, u nastavku razmatranja će se pojam datoteka koristiti ravnopravno kao sinonim za dokument.

Osnovna pretpostavka u implementaciji trezora podataka ERP sustava u proizvodnom poduzeću jest da se sve datoteke povezane uz proizvod i proizvodnju zapisuju i prate kroz trezor sustava. U takvom pristupu, valjana datoteka koja se može koristiti u razvoju proizvoda, ali i kasnije u proizvodnji, je samo ona koja je zavedena u trezoru. Datoteke pohranjene lokalno na računalima djelatnika smatraju se privremenima. Ukoliko prije upotrebe nisu povučene iz trezora odgovarajućim rutinama ili nisu nakon stvaranja povezane s proizvodnim elementom i pohranjene u trezoru, ne mogu se smatrati valjanim, jer zaobilaze protokolom određene putove kolanja dokumentacije. Uplitanje i primjena nepovezanih odnosno dokumenata bez referenci bitno otežava dijeljenje podataka o proizvodu.

Osnovni odnos koji mora zadovoljiti izvedba trezora podataka u odnosu na postojeće izvedbe ERP sustava jest da se uz svaki proizvodni element osnovne vrste (proizvod, sklop, dio) može pridružiti više datoteka (5.3). Pri tome pojedini proizvodni element ne mora imati niti jednu pridruženu datoteku ili može imati više njih, tako da među njima vrijedi odnos 1:{0..N}.

Promatrano u obrnutom smjeru, od dokumenta prema proizvodnim elementima, pojedini dokument može pripadati odnosno biti povezan s jednim ili više proizvodnih elemenata, ali ne mora niti s jednim pri čemu je riječ o neovisnom dokumentu. Dakle, neovisan dokument u smislu trezora podataka ERP sustava je dokument zaveden u trezoru, ali nije referenciran niti od jednog proizvodnog elementa. U slučaju da se proizvod razvija kroz CAD sustave i uz korištenje trezora podataka, ne bi se trebali pojavljivati neovisni CAD dokumenti, dakle svaki CAD

42 Drugi dokumenti mogu biti korisničke upute, montažne upute, tehničke specifikacije, jamstva, ilustracije, jednostavni tablični proračuni i sl. Uglavnom nastaju u uobičajenim uredskim aplikacijama.


dokument bi trebao biti pridružen jednom proizvodnom elementu ERP sustava u odnosu 1:1. Međutim, općenite upute i slični dokumenti koji nisu vezani uz razvoj proizvoda mogu se pojaviti kao neovisni dokumenti u trezoru ERP sustava.

Slika 5.3: Odnos proizvodnih elemenata i dokumenata

Jedinstvena oznaka (IB) dokumenta zapisanog u trezor osnovni je atribut za raspoznavanje dokumenta unutar ERP sustava. U svojoj strukturi ne mora sadržavati kodirani dio koji upućuje dokument na određeni proizvodni element. Primjerice, iako se u logici sustava može ugraditi pravilo da se oznaka dokumenta izvodi iz oznake proizvodnog elementa koji referencira dokument, zbog mogućnosti povezivanja istog dokumenta s dva ili više proizvodna elementa kao i preporuke STEP PDM sheme, ovu mogućnost bi valjalo izbjegavati u razvoju trezora. Dakako, ukoliko naručitelj zahtijeva očitovanje veze kroz jedinstvene oznake, potrebno je istu izvesti u sustavu.

Naziv dokumenta nikako ne mora biti jedinstven unutar sustava, a prilikom unosa datoteke dokumenta u trezor naziv se određuje na dva načina:

1) Od punog imena datoteke se odbacuje oznaka tipa datoteke, odnosno nastavak i upisuje se za naziv.

2) Aktualno ime datoteke se u potpunosti zanemaruje, a naziv dokumenta zapisanog u trezor određuje korisnik ili ga sustav dodjeljuje automatski prema ugrađenim pravilima.

U slučaju razvoja proizvoda pomoću CAD sustava u promatranom okruženju proizvodnih poduzeća, osnovna imena datoteka pojedinih digitalnih modela proizvodnih elemenata često su jednaka imenu samog proizvodnog elementa. Tako u prethodno prikazanom primjeru sklopa potpornja (Slika 4.1), sklop nosi naziv "Potporanj", kao i sve datoteke modela sklopa potpornja (Slika 5.4).

Nastavak dokumenta čuva izvornu ekstenziju punog imena datoteke dokumenta. Zapisivanje nastavka u trezor se izvodi programski, a korisniku se eventualno daje samo na uvid odnosno samo za čitanje. Prema potrebama i zahtjevima korisnika, atribut nastavka se može izostaviti i sam nastavak integrirati u naziv dokumenta. U tom slučaju naziv sadrži puno ime datoteke.

Opis dokumenta je atribut koji nosi osnovne podatke o aplikaciji u kojoj je dokument napravljen. Radi dosljednog čuvanja podataka, vrijednost atributa poželjno je odrediti programski čitanjem zaglavlja ili nastavka imena dokumenta prilikom upisivanja dokumenta u sustav. Korisnicima sustava opis dokumenta dostupan je samo za čitanje. U modelu odnosa


proizvodnih elemenata i dokumenata (Slika 5.3), atribut Opis prikazan je kao javni43 član klase Dokument, što bi moglo izgledati u suprotnosti s prethodnim zahtjevom. Međutim, pri tome treba razlikovati dostupnost za korisnika sustava od dostupnosti unutar samog programskog koda sustava u smislu objektno orijentiranog modeliranja.

Slika 5.4: Dokumenti sklopa potpornja

Atribut Verzija dokumenta prati uzastopne promjene dokumenta kroz sustav. Osim izraza verzija, mogu se ravnopravno upotrijebiti i izrazi revizija ili inačica. Međutim, izraz varijanta ne bi trebalo koristiti u tom smislu44. Podrobnu analizu primjene izraza verzija, revizija i varijanta moguće je pročitati u Peltonenovom radu [48], a pristup verzijama u modelu trezora biti će prikazan u dijelu o baratanju dokumentima (5.2.1).

Sadržaj : Verzija dokumenta predstavlja fizički binarni zapis dokumenta trezoru ili referencu na zapis. U prikazanom primjeru navedena je oznaka BLOB45 koja označava skup binarnih podataka zapisanih u pojedinom entitetu baze podataka. Fizičko zapisivanje u trezor podataka biti će razmotreno u zasebnom dijelu o modelu pohrane podataka (5.2.2).

Stanje dokumenta i atribut Koristi su nužni atributi u višekorisničkom okruženju kao što je trezor podataka ERP sustava i biti će detaljnije pojašnjeni u dijelu o baratanju dokumentima (5.2.1).

Popis Povezani dokumenti : Verzija dokumenta sadrži popis dokumenata u trezoru koji su na neki način povezani s promatranim dokumentom u razini pripadnog proizvodnog elementa. U

43 U objektno orijentiranom pristupu se uglavnom koristi engleski izraz "public" koji označava javno dostupnog člana klase – onog kojemu slobodno svi mogu pristupati, za razliku od privatnog koji je dostupan samo pripadajućoj klasi ili kroz metode vlastite klase. 44 Za razliku od revizija ili verzija koje idu slijedno za promatrani dokument i u pravilu je valjana samo aktualna odnosno posljednja revizija, dokument može imati paralelne varijante pri čemu su sve istovremeno valjane i u upotrebi. 45 Kratica od eng. Binary Large Object.


prikazanom primjeru dokumenata sklopa potpornja (Slika 5.4) crtež je na razini sklopa ovisan o dokumentima modela sklopa i prikaza sklopa. Promjena učinjena u bilo kojem od njih mora se odraziti i u crtežu sklopa, što se treba odraziti i kroz verzije dokumenata. O tome treba voditi računa pri izvođenju modela baratanja dokumentima opisanom u dijelu 5.2.1. Međutim, ne treba zaboraviti i da osim što dokumenti mogu biti povezani u razini istog proizvodnog elementa, za CAD modele sklopa je uobičajena povezanost s dokumentima modela podsklopova i dijelova koji pripadaju drugim proizvodnim elementima. Upravo takav je i promatrani model sklopa potpornja (Slika 4.1), sastavljen od više podsklopova i dijelova pa je prilikom otvaranja njegovog dokumenta potrebno pročitati i povezane dokumente. U tom slučaju treba razmatrati odnos strukture proizvoda i povezanih dokumenata, što će biti učinjeno u zasebnom dijelu (5.3).

Metoda Prikaži() služi za prikaz dokumenata. Prikaz se nastoji izvesti unutar pojedinog modula ERP sustava, neovisno o programu u kojemu je nastao, kako bi bio dostupan i korisnicima koji nemaju instaliran program, ali imaju potrebu za vizualnim prikazom elementa. Pri tome je preporučljivo koristiti dostupne klase ili kontrole za prikaz, a tek ukoliko nema dostupnih razmotriti potrebu za prikazom unutar ERP sustava i eventualno pristupiti izradi vlastitih rutina prikazivanja.

5.2.1 Model baratanja dokumentima

Prikazani model baratanja dokumentima u trezoru izveden je dijelom u skladu s prihvaćenim konceptima PDM pristupa kao i ISO STEP PDM sheme, ali uz posebnosti nužne za implementaciju unutar ERP sustava. U nastavku su pojašnjene temeljne metode baratanja dokumentima koje trezor mora pružati korisnicima.

Unos dokumenta

Unos dokumenata u trezor podataka izvodi se isključivo pozivanjem odgovarajućih metoda trezora, bez obzira na kasnije razmotren model pohrane dokumenata u kojem bi u posebnom slučaju možda bilo moguće izravno kopirati dokumente u datotečni sustav trezora. Osim osnovne zadaće zapisivanja dokumenata u trezor, metode unosa dokumenata moraju odrediti i zapisati meta-podatke, odnosno pripadajuće atribute dokumenta.

Obzirom na odnos dokumenta prema proizvodnom elementu, postupak prvog unosa dokumenta u trezor se može pokrenuti na dva načina:

1. Prilikom unosa neovisnog dokumenta odnosno dokumenta koji nije povezan s proizvodnim elementom, poziva se metoda Dodaj koja zapisuje dokument i pripadne atribute u trezor.

2. Prilikom unosa dokumenta povezanog uz proizvodni elementi, poziva se metoda PovežiDokument koja dodaje dokument na popis PovezaniDokumenti i poziva metodu za dodavanje dokumenta u trezor Dokument : Dodaj.

Uklanjanje dokumenta

Prilikom pozivanja metode Ukloni za uklanjanje dokumenta iz trezora, nije dovoljno samo obrisati zapis promatranog dokumenta u trezoru. Prije fizičkog uklanjanja dokumenta potrebno je provjeriti popis povezanih dokumenata i pripadnost proizvodnim elementima. Korisniku treba ponuditi mogućnosti izbora uklanjanja povezanih dokumenata.

Metoda UkloniDokument proizvodnog elementa izvodi uklanjanje pojedinog dokumenta iz popisa dokumenata povezanih s proizvodnim elementom. Međutim, ako se promatra u smjeru


od CAD dokumenta prema proizvodnom elementu, jedan dokument uglavnom pripada odnosno povezan je sa samo jednim proizvodnim elementom kojega predstavlja. Stoga se korisniku može ponuditi uklanjanje dokumenta iz trezora prilikom uklanjanja dokumenta s popisa povezanih uz proizvodni element, kroz pozivanje metode Dokument : Ukloni.

Izmjena dokumenta

Postupak izmjene dokumenta zapisanog u trezoru podataka mora poštivati značajke višekorisničkog okruženja ERP sustava. Slijed aktivnosti koje se odvijaju nad promatranim dokumentom prilikom postupka izmjene dokumenta može se prikazati UML dijagramom aktivnosti (Slika 5.5).

Slika 5.5: Slijed aktivnosti prilikom izmjene dokumenta

Slijed aktivnosti inicira korisnik sustava zahtjevom za preuzimanjem dokumenta iz trezora. Prije no što se iz trezora korisniku izvede dokument46, potrebno je provjeriti dostupnost dokumenta čitanjem atributa Stanje. Atribut Stanje sadrži vrijednosti koje označavaju dostupnost dokumenta.

Ukoliko je dokument izveden iz trezora za pojedinog korisnika, atribut Stanje poprima vrijednost koja označava da je dokument nedostupan odnosno zaključan za druge korisnike. 46 U sustavima za baratanje dokumentima, za postupak povlačenja dokumenta iz trezora uobičajen je eng. izraz "Check-Out". U našoj literaturi se može susresti i izraz "odjava dokumenta" koji može pogrešno zavesti na pomisao da je riječ o uklanjanju dokumenta iz trezora.


Ujedno se u atribut Koristi zapisuje ime korisnika koji je povukao dokument kako bi se drugim korisnicima mogla pružiti informacija tko je zauzeo dokument odnosno tko trenutno radi na dokumentu.

Izraz "izveden iz trezora" označava da je na korisnikovom računalu zapisan aktualni sadržaj odnosno datoteka dokumenta iz trezora. Pri tome i u trezoru ostaje izvorni sadržaj dokumenta. Dakle, nakon izvođenja dokumenta iz trezora, a prije no što korisnik napravi i pohrani promjene u dokumentu, postoje dva dokumenta istog naziva i sadržaja: jedan dokument kod korisnika, drugi u trezoru.

Metoda izvođenja dokumenta također treba provjeriti popis povezanih dokumenata i prema potrebi rekurzivno se pozvati nad povezanim dokumentima. Primjerice, u prikazu dokumenata sklopa potpornja (Slika 5.4), prilikom izvođenja dokumenta "Prikaz", na popisu povezanih dokumenata je naveden IB 235. IB povezanog dokumenta upućuje na dokument modela sklopa instanciranog u primjeru kao objekt nazvan "Sklop". Veza govori da dokument "Prikaz" u svom sadržaju koristi dokument "Sklop" pa je stoga prilikom izvođenja dokumenta "Prikaz" potrebno izvesti i dokument "Sklop".

Analogno bi se moglo izvesti i povezivanje dokumenta drugih komponenata sklopa ili proizvoda. Međutim, posljedice ovakvog pristupa mogu biti nejasan prikaz ili čak gubitak višerazinske hijerarhije proizvoda. Sličnog razmišljanja su Erens i Peltonen [48], koji su u svojim radovima preporučili da se odnosi postavljaju među komponentama umjesto među dokumentima, što su prikazali jednostavnim UML dijagramom. Zbog značaja prikazana je varijanta dijagrama prilagođena kontekstu disertacije radi boljeg razumijevanja (Slika 5.6). Zbog toga će veze na dokumente drugih komponenti biti predložene kroz model upravljanja strukturom proizvoda u dijelu 5.3.

Slika 5.6: Struktura elemenata umjesto dokumenata

Uz izvođenje dokumenta iz trezora, dokument je potrebno zaključati za druge korisnike, promjenom vrijednosti atributa Stanje i Koristi kako se ne bi dogodilo da dva korisnika istovremeno rade na istom dokumentu.

Nakon što je dokument izveden iz trezora, korisnik pristupa izmjenama dokumenata. Po dovršetku izmjena promijenjeni dokument prijavljuje se natrag u trezor ili se promjene odbacuju. Prijava dokumenta47 u trezor povlači za sobom premještanje prethodnog sadržaja dokumenta u popis prethodnih verzija, zapis promijenjenog sadržaja dokumenta u trezorski i uvećanje broja verzije za 1.

47 U sustavima za baratanje dokumentima, za postupak unosa izmijenjenog dokumenta u trezor uobičajen je eng. izraz "Check-In".


Ciklus izmjene dokumenta završava otključavanjem dokumenta za druge korisnike izmjenom atributa Status i brisanjem sadržaja atributa Koristi.

Korisniku se nevezano za trezor, može u implementaciji metode prijave dokumenta ponuditi da zadrži lokalnu kopiju dokumenta ili da ju obriše. Lokalna kopija može naknadno poslužiti za ubrzavanje pristupa istom dokumentu iz trezora48. Naime, ukoliko do narednog izvođenja dokumenta iz trezora u međuvremenu nitko drugi ne izvrši izmjene sadržaja, tada se prilikom pozivanja metode izvođenja provjerava postoji li lokalna kopija i odgovara li sadržajem aktualnoj kopiji u trezoru. Ukoliko odgovora, nije potrebno kopirati dokument iz baze, čime se može značajno ubrzati rad, naročito ukoliko je veza između trezora i korisnika slabije propusnosti.

Verzije dokumenta

U kontekstu praćenja dokumenata, verzija se može odrediti kao prolazna točka u kojoj se dokument nalazi pri prijelazu iz jednog stanja u drugo. Kako se na dokumentu u procesu razvoja najčešće vrše izmjene u smislu unapređivanja modela proizvodnog elementa, potrebno je kroz trezor podataka pratiti promjene dokumenta zapisivanjem verzija ili inačica49 dokumenta.

Sukladno potrebama proizvodnih poduzeća, u prikazanom modelu povezivanja dokumenata s proizvodnim elementima (Slika 5.3) postavljeno je označavanje verzije dokumenta brojem iz skupa prirodnih brojeva. Prema takvom načinu označavanja, prilikom prvog zapisivanja dokumenta u trezor, označavanje verzije kreće od broja 1. Prilikom svakog narednog zapisivanja promijenjenog dokumenta broj verzije se uvećava za 1, odnosno nastaje novi objekt Verzija dokumenta kroz koji se ostvaruje zapis u trezoru povezan uz promatrani dokument.

Međutim, u procesu razvoja nije rijetkost da se zbog novih okolnosti i zahtjeva u jednom trenutku mora odustati od dosegnute razine proizvodnog elementa te se vratiti nekoliko koraka, odnosno verzija unatrag i odatle nastaviti dalje s razvojem. Zbog toga se u trezoru podataka trebaju čuvati sve verzije dokumenta i korisniku omogućiti pozivanjem metode Dokument : IzvediVerziju da iz trezora izvuče neku od ranijih verzija i nastavi na njoj raditi.

Po dovršetku postupka izmjene, metoda prijave dokumenta u trezor dodaje zapis nove verzije koja se označava brojem prethodno aktivne verzije uvećane za 1. U istom bloku metoda prijave, a neposredno prije otključavanja dokumenta za druge korisnike treba odrediti vrijednosti nekoliko atributa:

• Vrijednost atributa Dokument : Koristi prije brisanja pohraniti u atribut Zapisao nove verzije dokumenta, čime se bilježi tko je zapisao verziju u trezor.

• Ispuniti vrijednosti atributa DatumVerzije čitanjem sistemskog vremena u trenutku zapisivanja.

• Osvježiti popis PovezaniDokumenti ukoliko je došlo do promjena.

• Ponuditi korisniku mogućnost unosa atributa Napomena predviđenog za opis promjena koje donosi promatrana verzija i zapisati uneseni tekst.

Odnos verzije dokumenta i verzije proizvodnog elementa se može postaviti obzirom na generacije načina prikazivanja proizvoda pojašnjenih u poglavlju 4.3 i obzirom na vrstu proizvodnog elementa. Verzija dokumenta može služiti kao verzija proizvodnog elementa u sljedećim slučajevima:

48 U tom slučaju se može govoriti o "keširanju" dokumenata (izvorno eng. Caching). 49 Sasvim ravnopravno se u tom kontekstu u praksi susreće i izraz "revizija".


• Proizvodni element je proizvod ili sklop, a dokument koji ga prikazuje je model sklopa. Verzija dokumenta modela sklopa tada je ujedno i verzija elementa.

• Proizvodni element je proizvod ili sklop, a dokument koji ga prikazuje je digitalni crtež bez postojanja povezanog dokumenta modela sklopa. Verzija dokumenta crteža tada je ujedno i verzija elementa.

• Proizvodni element je dio, a dokument koji ga prikazuje je model dijela. Verzija dokumenta modela sklopa tada je ujedno i verzija elementa.

• Proizvodni element je dio, a dokument koji ga prikazuje je digitalni crtež bez postojanja povezanog dokumenta modela dijela. Verzija dokumenta crteža tada je ujedno i verzija dijela.

Osim verzija proizvodnih elemenata i povezanih dokumenata, u razvoju proizvoda se mogu pojaviti i njihove varijante. Varijante u smislu proizvodnog elementa označavaju istovremeno prisutne različite izvedbe proizvodnih elemenata koje potječu od istog proizvodnog elementa. Kako prilikom stvaranja varijanti u trezoru ERP sustava nastaju novi proizvodni elementi, uz njih se moraju kopirati dokumenti povezani s izvornim elementom, ali uz dodjelu novih jedinstvenih oznaka budući je riječ o novim i samostalnim zapisima.

5.2.2 Modeli pohrane dokumenata

Pitanje modela pohrane dokumenata u trezor pripada u područje interne izvedbe modela trezora. Prosječni korisnik sustava ne treba znati kako se barata dokumentima unutar trezora. Međutim, zbog bitne razlike u ponuđenim modelima koje umnogome mijenjaju unutarnju strukturu trezora, a time i primijenjene metode trezora, potrebno je prije započinjanja razvoja metoda trezora dobro promisliti o modelima.

Razmatrano na nivou binarnog zapisa, dva su osnovna modela po kojima se može dokument pohraniti u trezor: izravno primjenom polja binarnih objekata ili posredno referenciranjem datoteke. Oba pristupa imaju svoje prednosti i nedostatke pa stoga prije odabira pojedinog modela treba razmotriti okolnosti u kojima će se sustav uvoditi. Posebno pri tome valja razmotriti zahtjeve proizvodnog poduzeća za baratanje dokumentima u procesu razvoja proizvoda. Kako bi eventualno poslužile kao smjernice za odabir odgovarajućeg modela, u nastavku su ukratko izložena oba modela pohrane sa svojim osnovnim prednostima i nedostacima.

Izravna pohrana u binarno polje

U modelu pohrane sadržaja dokumenta u binarno polje, sadržaj dokumenta se upisuje odnosno doslovce binarno kopira bit po bit u odgovarajuće polje zapisa dokumenta u bazi podataka trezora (Slika 5.7). Atribut Verzija dokumenta : Sadržaj koji u ovakvom modelu izravno preuzima sadržaj izvodi se u bazi podataka sustava kao polje tipa BLOB.

Neke od prednosti izravnog binarnog pohranjivanja sadržaja dokumenata u trezoru su:

• Brz pristup dokumentima.

• Čuvanje svih dokumenata izravno u trezoru.

• Jednostavno izvođenju sigurnosne pohrane čitavog trezora.

Nedostaci izravnog pohranjivanja mogu biti:


• Slaba podrška za polje tipa BLOB – iako je ovaj tip i službeno uveden prije par godina u SQL50 standard, njegova implementacija nije jednaka u svim dostupnim bazama podataka. Stoga se može pojaviti problem prijenosa ERP sustava iz jedne u drugu bazu podataka.

• Otežan pristup sadržaju pojedinog dokumenta iz sigurnosne pohrane – većinom je potrebno vratiti cijelu sigurnosnu sliku trezora prije pristupa pojedinom dokumentu.

Slika 5.7: Zapisivanje sadržaja dokumenta u binarno polje

Navedene prednosti i nedostaci ukazuju da je model izravne pohrane pogodan za primjenu u okruženjima koja u manjem opsegu koriste trezor dokumenata. Dosadašnja iskustva prilikom uvođenja ERP sustava u proizvodna poduzeća u okruženju pokazala su kako je većinu poduzeća zadovoljavala niža funkcionalnost trezora uz mogućnost da se uz jedan proizvodni element poveže samo jedna datoteka. Upravo stoga je uglavnom primjenjivan model izravne pohrane.

Pohrana referencirane datoteke

U modelu pohrane dokumenta u referenciranu datoteku trezora, datoteka dokumenta se doslovce kopira ili premješta u poseban direktorij na datotečnom poslužitelju trezora podataka (Slika 5.8). Atribut Verzija dokumenta : Sadržaj u tom slučaju čuva adresu datoteke zapisane na datotečnom poslužitelju. Područje u koje se zapisuju referencirane datoteke treba biti dostupno samo kroz metode trezora, odnosno zaštićeno od svih drugih korisnika.

Slika 5.8: Pohrana referencirane datoteke

50 Od eng. Structured Query Language – računalni jezik za baratanje podacima u sustavima za upravljanje relacijskim bazama podataka.


Prednosti korištenja datotečnog poslužitelja nasuprot pohrane u binarno polje, naročito dolaze do izražaja prilikom baratanja trezora s velikim brojem datoteka.

Nedostaci mogu biti:

• Ovisnost o funkcijama operativnog sustava – prilikom korištenja više datotečnih poslužitelja s mješovitim operativnim sustavima (Microsoft Windows, UNIX…) nije jednostavno pripremiti stabilne metode trezora.

• Korupcija podataka nekontroliranim pristupom – prostor u koji se zapisuju podaci štiti se uglavnom postavljanjem prava pristupa korisnicima i grupama korisnika. Korisnik s dovoljnim pravima pristupa može izravno zamijeniti ili ukloniti pojedinu datoteku i time oštetiti valjanost podataka.

5.3 MODEL UPRAVLJANJA STRUKTUROM PROIZVODA

Upravljanje strukturom proizvoda je uz trezor podataka temeljna funkcija PDM sustava. Kako pokazuju neovisna ispitivanja predočena u prethodnom poglavlju [59], većina razvojnih timova koristi upravljanje strukturom čak i više od trezora podataka. Zbog toga je podrška upravljanju strukturom proizvoda unutar ERP sustava od velikog značaja za učinkovito dijeljenje podataka o proizvodu u procesu razvoja proizvoda. Kako se u modernom razvoju proizvoda značajno koriste CAD sustavi i kod upravljanja strukturom je kao i u slučaju trezora podataka važno izvesti metode sinkronizacije strukture s CAD sustavima.

5.3.1 Model strukture proizvoda

Ako se struktura proizvoda odredi kao detaljan hijerarhijski ustroj komponenti koje čine proizvod51, tada je za izvođenje strukture proizvoda u ERP sustavu potrebno proširiti model proizvoda, prethodno predstavljen u dijelu 5.1 (Slika 5.1), s mehanizmima za dovođenje elemenata u međusobne strukturne odnose. U dosadašnjim izvedbama ERP sustava proizvodnih poduzeća za strukturirani prikaz proizvoda uglavnom je primjenjivan izraz "višerazinska sastavnica".

Model koji omogućava strukturiranje proizvodnih elemenata može se učinkovito prikazati dijagramom klasa (Slika 5.9). Radi bolje i preglednije organizacije klasa između apstraktne klase Proizvodni element te klasa Proizvod i Sklop, dodana je još jedna apstraktna klasa: Složen proizvodni element.

Osnovna zadaća apstraktne klase Složen proizvodni element jest određivanje nasljednih članica i metoda koje se s nje prenose na izvedene klase Proizvod i Sklop. Riječ je o proizvodnim elementima koji mogu sadržavati druge elemente, odnosno mogu imati strukturu koju sačinjavaju njima podređeni elementi. Pri tome, objekt iz klase Proizvod ili Sklop ne mora sadržavati niti jedan, ali može sadržavati više podređenih objekata iz klase sklopova, dakle proizvodnih elemenata sklopova u odnosu 1:0..*. Jednak odnos objekt iz klase Proizvod ili Sklop ima i prema dijelovima: proizvod ili sklop može sadržavati nijedan ili više dijelova.

Proizvodni elementi klase Dio ne mogu imati podređene elemente pa prema tome niti strukturu. Stoga se ne izvode iz klase složenih proizvodnih elemenata već izravno iz klase proizvodnih elemenata. Posljedica je da nemaju dostupne članove klase složenih proizvodnih elemenata pomoću kojih se ostvaruje struktura.

51 U engleskom govornom području prevladava izraz "Product Breakdown Structure" (PBS) za strukturu proizvoda.


Slika 5.9: Struktura proizvodnih elemenata

Popis PodređeniElementi sadrži jedinstvene IB oznake podređenih elemenata pojedinog složenog proizvodnog elementa – proizvoda ili sklopa. U popis promatranog složenog proizvodnog elementa uvrštavaju se samo izravno podređeni elementi odnosno elementi prve razine podređenosti. Ukoliko su i podređeni elementi izvedeni kao složeni, odnosno imaju svoje podređene, tada je za prikaz pune strukture krovnog elementa potrebno iterativno pročitati popise svih uključenih podređenih složenih elemenata.

U prikazu objekata strukture potpornja (Slika 5.10), prisutna su dva složena proizvodna elementa proizvod Potporanj i sklop Stezni vijak. Zbog toga je za određivanje pune strukture proizvoda Potporanj potrebno pročitati dva popisa: popis Potporanj.PodređeniElementi i popis Stezni vijak.Podređeni elementi.

Metoda DodajPodređeni izvodi dodavanje proizvodnih elemenata na popis podređenih elemenata u postupku razvijanja strukture složenog elementa. Suprotna metoda UkloniPodređeni predviđena je za uklanjanje elementa s popisa podređenih prilikom izmjene strukture složenog elementa. Metode nisu međusobno isključive, jer je moguća kombinirana primjena obje metode u slučaju zamjene elementa u strukturi s drugim elementom.

Prikazanom izvedbom modela strukture proizvoda izravno je izbjegnuta zamka da se strukturiranje proizvoda izvodi kroz postavljanje odnosa među dokumentima (Slika 5.6). Prednosti ovakvog modela stoga upravo proizlaze iz nedostataka strukturiranja proizvoda kroz dokumente, na što je upozoreno u poglavlju 5.2.1 o baratanju dokumentima.


Slika 5.10: Objekti strukture potpornja

5.3.2 Podrška razvoju strukture proizvoda

Kako bi se u pravom trenutku pružila sustavna podrška razvoju strukture proizvoda, potrebno je razmotriti u kojim se fazama procesa konstruiranja oblikuje struktura proizvoda te u kojim od tih faza se razvojni timovi oslanjaju na pomoć poslovnih računalnih sustava.

Osnovni kostur strukture novog proizvoda izvodi se ponekad već u prvoj fazi procesa konstruiranja, prilikom planiranja i pojašnjavanja zadaće. Naročito, ukoliko se novi proizvod izvodi na osnovu već postojećih rješenja. Primjerice, u razvoju pogona optičkih čitača digitalnih video diskova – DVD ROM pogona, iako je riječ o potpuno novom proizvodu struktura pogona je gotovo u cijelosti naslijeđena od prethodnih pogona optičkih čitača kompaktnih diskova – CD


ROM pogona. Primjena poslovnih računalnih sustava može kod takvih proizvoda značajno olakšati razvojnim timovima oblikovanje novog proizvoda.

Proizvodi pojedinačne ili maloserijske proizvodnje kakvi se uglavnom susreću u proizvodnim poduzećima u okruženju, rijetko imaju jasno određenu strukturu već u prvoj fazi. Njihova struktura se određuje dijelom u fazi konceptualnog konstruiranja i većinom u fazi ostvarenja konstrukcije uz ostvarenje izgleda. U okolnostima kada se s razvojem strukture kreće u konceptualnoj fazi, razvojni timovi mogu računati na pomoć poslovnih računalnih sustava u manjem opsegu, uglavnom kroz funkcije praćenja i sinkronizacije strukture novog proizvoda.

Razvoj strukture proizvoda se može pratiti i ostvarivati ravnopravno i u ERP sustavu i u CAD sustavu. Zbog toga je potrebno izvesti određenu razinu podrške razvojnim timovima uz pojednostavljenje naknadne sinkronizacije strukture među sustavima. U nastavku su razmotreni slučajevi razvoja strukture uz prijedlog podrške praćenja razvoja strukture kroz ERP sustave. Iako će u nastavku biti razmatrana struktura proizvoda, isti pristupi se preslikavaju i na druge složene proizvodne elemente odnosno na sklopove.

Razvoj nove strukture

Razvoj nove strukture novog proizvoda započinje kada razvojni tim dobije nalog za razvoj novog proizvoda. U ERP sustavu može se uz radni nalog dodijeliti odgovarajuća jedinstvena IB oznaka i naziv proizvoda. Ovakvo rano dodjeljivanje oznake i naziva u ERP sustavu može kasnije znatno pojednostaviti i olakšati praćenje aktivnosti oko proizvoda. Osim što može pojednostaviti sinkronizaciju strukture s vanjskim sustavima, može poslužiti i za upravljanje procesom razvojem proizvoda.

Slika 5.11: Slijed prilikom dodavanja elementa u strukturu

Prilikom razvoja nove strukture, razvojni tim se treba oslanjati na elemente zavedene u ERP sustavu. Za svaki novi element koji se dodaje u strukturu, potrebno je provjeriti da li možda već postoji odgovarajući u ERP sustavu kako bi se izbjeglo korištenje novih elemenata. Slijed aktivnosti prilikom dodavanja nove komponente strukture može se prikazati jednostavnim dijagramom aktivnosti (Slika 5.11). Ukoliko odgovarajući element postoji u sustavu, u strukturu proizvoda ga treba uvesti kao podređeni element. U protivnom, upisuje se novi element u ERP sustav i potom dodaje kao podređeni.


Razvoj varijante postojeće strukture

U slučaju razvoja novog proizvoda na osnovu postojećeg proizvoda, prilikom razvoja strukture novog proizvoda kao polazna točka se koristi struktura postojećeg proizvoda. Ako novi proizvod ne zahtjeva značajne strukturne izmjene, na ovaj način se vrlo brzo može doći do konačne strukture novog proizvoda. Slijed aktivnosti u tom slučaju započinje određivanjem postojećeg proizvoda s odgovarajućom početnom strukturom. Struktura odabranog polaznog proizvoda preslikava se u novi proizvod prebacivanjem sadržaj popisa PodređeniElementi polaznog proizvoda u popis podređenih elemenata novog proizvoda. U tom trenutku u sustavu su dva proizvoda s različitim oznakama i nazivima, ali jednakih popisa podređenih elemenata (Slika 5.12). Slijede izmjene strukture proizvoda uključivanjem novih elemenata te uklanjanjem ili izmjenama podređenih elemenata.

Slika 5.12: Novi proizvod iz postojećeg

Sinkronizacija strukture definirane u vanjskim sustavima

U modernom pristupu razvoju proizvoda, struktura proizvoda se pretežno razvija i nadograđuje kroz model proizvoda rađen u CAD sustavu. Po ulasku u fazu ostvarenja konstrukcije, članovi razvojnog tima dijele posao i rade na konstruiranja pojedinih detalja odnosno segmenata strukture proizvoda. Svaki segment, zapravo računalni model sastavnog sklopa ili sastavnog dijela proizvoda, zapisuje se u pojedinu datoteku. Ukoliko se datoteke pohranjuju u trezor ERP sustava uz povezivanje s proizvodnim elementima, može se značajno pojednostaviti sinkronizacija strukture. Kako bi služio i kao okruženje za dijeljenje podataka o proizvodu u razvojnom procesu, ERP sustav mora sudionicima razvojnog procesa ponuditi mehanizme sinkronizacije strukture složenih proizvodnih elemenata sa strukturom modela proizvoda rađenog u CAD sustavu.

Sinkronizacija strukture među sustavima povlači za sobom nekoliko koraka:

1. Povezivanje komponenti CAD modela s proizvodnim elementima ERP sustava.

2. Preslikavanje strukture CAD komponenti u popise podređenih elemenata ERP sustava.

3. Zapisivanje dokumenata CAD modela komponenti u trezor podataka.

4. Povezivanje dokumenata uz proizvodne elemente.

Povezivanje CAD komponenti s proizvodnim elementima je korak u kojemu treba provjeriti postoji li možda za pojedinu komponentu odgovarajući proizvodni element. Ukoliko je model proizvoda rađen samostalno u CAD sustavu, odnosno bez korištenja elemenata iz ERP sustava, tada je nužna provjera svih komponenti. Provjera se može raditi automatski po nazivu komponente i elementa ukoliko se potpuno podudaraju. Moguće je izvoditi provjeru podudarnosti i prema jedinstvenim oznakama, ali samo ako je prethodno kod korisnika odnosno članova razvojnog tima usvojen protokol označavanja komponenti prilikom rada u CAD sustavu. Za komponente za koje prilikom provjere nisu pronađeni odgovarajući proizvodni elementi, potrebno je kreirati nove elemente u ERP sustavu.


Preslikavanje strukture je moguće izvoditi kroz automatizacijske programske rutine bez potrebe za intervencijom korisnika, ako je u prethodnom koraku za svaku komponentu određena IB oznaka u ERP sustavu. Iterativnim prolaženjem kroz sve razine hijerarhijskog stabla komponenti određuju se podređene komponente i zapisuju u popise podređenih elemenata odgovarajućih složenih proizvodnih elemenata ERP sustava.

Zapisivanje CAD dokumenata se izvodi za nove komponente ili za modele kod kojih je došlo do sadržajnih promjena.

Povezivanje dokumenata uz proizvodne elemente je nužan završni korak sinkronizacije strukture, jer CAD dokumenti koji sadrže modele komponenti upotrijebljenih u sklopu ili proizvodu izravno sudjeluju u određenju strukture.

Koraci sinkronizacije su predstavljeni u općem obliku, jer su i uz detaljno poznatu izvedbu strukturiranja na shematskoj razini unutar ERP sustava ipak u znatnoj mjeri ovisni o specifičnom CAD sustavu za kojeg se implementiraju. Zbog toga će u prototipnoj realizaciji biti prikazana implementacija postupka sinkronizacije za odabrani CAD sustav. No, zbog jednakih metoda korištenih kod postavljanja strukture modela sklopa kod svih modernih CAD parametarskih sustava temeljenih na značajkama, prikazani koraci su jednako primjenjivi i mogu služiti kao model po kojemu se može izvesti sinkronizacija. Jedini uvjet pri tome je poznavanje i dostupnost programerskog sučelja konkretne CAD aplikacije52.

Iako je moguće do u detalje razviti programske metode za sinkronizaciju strukture, sam postupak sinkronizacije u pravilu nije moguće izvesti potpuno automatizirano odnosno bez potrebe za intervencijom korisnika. Intervencije korisnika – sastavljača strukture su neophodne u prvom koraku sinkronizacije, prilikom povezivanja CAD komponenti s elementima ERP sustava. Pri tome korisnik mora riješiti nedoumice da li za komponentu za koju u ERP sustavu postoji element s odgovarajućim nazivom (1) povezati s pronađenim elementom ili (2) stvoriti novi element. Bezbrižan pristup stvaranja novih elemenata za svaku komponentu strukture vodi ka neracionalnom upravljanju i upravo je suprotan osnovnom razlogu primjene ERP sustava. Takvom primjenom se u ERP sustavu gomilaju višestruki proizvodni elementi koji se razlikuju samo po oznaci i eventualno po nazivu, a zapravo označavaju isti predmet. Potom se u razvoju i proizvodnji progresivno umnažaju prividno različite stavke, dokumenti i nalozi elementa, što vodi ka neracionalnom poslovanju poduzeća.

U nekim graničnim slučajevima je ipak moguće ostvariti automatsku sinkronizaciju strukture:

• Ukoliko su u poduzeću CAD sustavi ušli u upotrebu prije ERP sustava, potom se kod uvođenja ERP sustava za mnoge proizvode može automatski sinkronizirati struktura.

• Ukoliko je izveden proizvod koji u strukturi ne koristi niti jedan od elemenata iz ERP sustava. Ovaj slučaj bi trebao biti rijedak u poduzećima koja su prošla period uvođenja ERP sustava i imaju razvijenu proizvodnu paletu. Dosljedna primjena načela racionalnog konstruiranja da se u izradi nove strukture upotrijebi što više poznatih i vlastitih komponenti trebala bi također smanjiti učestalost ovog slučaja.

52 U struci se za programersko sučelje aplikacije uglavnom koristi kratica API od eng. Application Programming Interface.


5.4 MODEL AUTORIZACIJE

Za svakog korisnika koji će se prijavljivati za rad u ERP sustavu, potrebno je prethodno odrediti razinu korisničkih prava u okviru kojih će moći obavljati svoje poslove unutar sustava. Primjerice, razvojni inženjer prilikom razvoja proizvoda treba imati mogućnost uvida u količinu standardnih komponenti na skladištu kako bi već prilikom razvoja proizvoda ubrzao pokretanje proizvodnje, ali ne bi bilo dobro ako bi mogao promijeniti količine ili rezervirati potrebne količine.

U manjim proizvodnim poduzećima, razvojni inženjeri često imaju ulogu i tehnologa i proizvodnog inženjera pa je stoga razinu korisničkih prava potrebno prilagoditi takvim zahtjevima. Dodjela prava pristupa pojedinačnom korisniku po pojedinim podsustavima prikladna je za primjenu u takvim manjim poduzećima u kojima jedan korisnik često obavlja poslove iz više područja. Tablično je prikazan model dodjele prava pristupa sličan onomu kakav se primjenjuje u proizvodnim poduzećima (Tablica 5.1). Prikazana prava pristupa su dodijeljena primjera radi, a pri tome bi prava Korisnika 1 odgovarala razvojnom ili tehnološkom inženjeru, prava Korisnika 2 proizvodnom inženjeru, Korisnika 3 nekom od članova uprave, dok se najveća prava kao za Korisnika 4 u pravilu dodjeljuju administratoru i dobavljaču sustava. Dakako, što je poduzeće veće to će biti i veći broj korisnika pa prikazanu tablicu treba tumačiti samo kao jednu od varijanti dodjele prava.

Tablica 5.1: Prava pristupa korisnika prema podsustavima

Korisnik

Modul Koris

nik

1

Koris

nik

2

Koris

nik

3

Koris

nik

4

Definicija proizvoda i tehnologije

Nabava i zalihe

Planiranje i terminiranje proizvodnje

Lansiranje radnih naloga

Praćenje proizvodnje

Praćenje kvalitete

Održavanje kapaciteta

Prodaja i kalkulacija

Računovodstvo

Menadžment i kontroling

Legenda prava:

puni pristup

pregled

nedostupno

Osim izložene jednostavne sheme prava pristupa po pojedinim podsustavima s pravima punog pristupa, preglednog pristupa i bez prava odnosno nedostupno, često je potrebno razinu prava još više razraditi i detaljizirati. U slučaju razvoja proizvoda ili proizvodnje u kooperaciji s drugim poduzećima, radi sigurnog dijeljenja podataka o proizvodu kooperantima se može dopustiti pristup samo u opsegu zajedničkih proizvodnih elemenata. Stoga se može javiti potreba za dodjelom prava pristupa na razini proizvodnog elementa ili na razini zapisa u bazi podataka ERP sustava. Na toj razini bi se prava pristupa mogla riješiti analogno poznatim rješenjima primijenjenim u datotečnim sustavima [73].

U većim poduzećima u pravilu se radi u timovima ili brigadama, pa se stoga u sustavu pojavljuje veći broj korisnika kojima je potrebno omogućiti sličnu razinu korisničkih prava.


Određivanje razine prava u takvim okruženjima je relativno jednostavno zadovoljiti uvođenjem imenovanih korisničkih grupa u sustav i razvrstavanjem korisnika po grupama. Korisnik tada nasljeđuje prava pristupa grupe, ali se u pravilu izvodi i mogućnost dodatnog određivanja razine prava pristupa po korisniku.

5.5 MODEL VANJSKOG PRISTUPA

Vanjski pristup ERP sustavu označava pristup koji dolazi izvan okvira računalne mreže poduzeća. U procesu razvoja proizvoda pa i u procesu proizvodnje u koji su uključeni vanjski suradnici ili kooperacija potrebno je uključenim sudionicima osigurati vanjski pristup aktualnim podacima, odnosno omogućiti dijeljenje potrebnih podataka o proizvodu.

Iako ima svojih prednosti, vanjski pristup ERP sustavu kroz klijentske aplikacije samog ERP sustava vrlo često nije prikladan. Klijentske aplikacije, odnosno programski moduli podsustava izvode se optimizirani za visoku propusnost lokalnih mreža prema poslužiteljima ERP sustava. Pri tome se računa na mrežnu propusnost s brzinama prijenosa podataka iznad od 10 Mb/s, u pravilu na 100 Mb/s, dok se među poslužiteljima ponekad traži propusnost od 1 Gb/s. Zahtjevi za brzinom izvršavanja i brzinom pristupanja podacima u suprotnosti su s brzinama veza koje vanjski korisnici mogu ostvariti. Samo u izuzetno rijetkim slučajevima i u pravilu uz nerazumno visoke investicije moguće je ostvariti dovoljnu brzu mrežnu vezu s vanjskim korisnicima koja bi na njihovim računalima omogućila prihvatljivo izvršavanje klijentskih aplikacija ERP sustava.

Uz pitanje brzine, otvoreno je i pitanje kompatibilnosti, jer se klijentske aplikacije zbog zahtjeva za što boljim performansama, programiraju i izvode za određene operativne sustave. I kada se nekako probije barijera dovoljne brzine i kompatibilnosti, ostaje otvoreno pitanje spremnosti vanjskih korisnika da licenciraju odnosno investiraju u potrebne aplikacije.

Nabrojane prepreke korištenju klijentskih aplikacija ERP sustava izvan računalne mreže poduzeća upućuju da rješenje vanjskog pristupa treba:

• u što manjoj mjeri ovisiti o operativnom sustavu korisnika,

• izvršavati se brzinom prihvatljivom korisniku i na relativno sporijim vezama s poslužiteljima ERP sustava,

• biti za vanjske korisnike jednostavno dostupno uz male troškove licenciranja.

Na prethodne zahtjeve se može prikladno odgovoriti izvedbom modela vanjskog pristupa preko HTTP protokola odnosno kroz Web preglednike korisničkih računala. Za vanjske korisnike se u tom slučaju pristup izvodi kroz web preglednike poput Microsoft Internet Explorera, Mozilla Firefoxa, Opere i drugih. Vanjski korisnici pristupaju ERP sustavu jednostavnim navođenjem adrese poslužitelja u web pregledniku.

Za izvedbu vanjskog pristupa ERP sustavu kroz HTTP protokol potrebno je razviti web aplikaciju koja će korisnicima dinamično stvarati i prikazivati web stranice u pregledniku koristeći pri tome podatke iz trezora podataka ERP sustava. Osnovne pretpostavke ovakve izvedbe vanjskog pristupa su podizanje web poslužitelja nad bazom podataka ERP sustava te razvoj i objavljivanje odgovarajuće web aplikacije. Web preglednik, web poslužitelj i baza podataka ERP sustava pri tome čine tri implementacijska sloja vanjskog pristupa pa se za ovakvu izvedbu može navesti da je izvedena kao troslojna aplikacija53 (Slika 5.13). U prototipnoj realizaciji vanjskog pristupa prema razvojnim podacima proizvoda pohranjenim u ERP sustavu upotrijebljen je upravo koncept troslojne web aplikacije.

53 Izvorno eng. Three-tiered application.


Slika 5.13: Troslojna arhitektura vanjskog pristupa

Zbog dosljednosti i potpunosti potrebno je razmotriti razloge odabira razvoja vanjskog pristupa kroz web aplikaciju umjesto izvedbe s web servisima. Naime, obje tehnologije nude pristupanje poslovnim sustavima kroz HTTP protokol. Međutim, web servisi su prema mišljenju autora prikladniji za sustave koji su u cijelosti okrenuti i izvedeni kroz HTTP protokol kao što je primjerice predstavio Štorga u svom radu [74]. Čak i tada treba računati na slabije performanse u odnosu na klasične klijent-poslužitelj sustave. Iako bi se moglo razviti web servise za vanjski pristup ERP sustavima proizvodnih poduzeća, aktualna arhitektura, spomenuta razlika u performansama te još uvijek visoka cijena i slabija dostupnost brzih veza prema Internetu prevagnula je za prototipnu implementaciju vanjskog pristupa kroz web aplikaciju.

78

6 PROTOTIPNA IMPLEMENTACIJA MODELA

Informacijski modeli prikazani u prethodnom poglavlju, prototipno su implementirani u ERP sustavu ERPINS-M razvijenom u tvrtki ININ Informatički Inženjering d. o. o. u Slavonskom Brodu. ERPINS-M je u prvom redu namijenjen upravljanju poslovanjem u metaloprerađivačkoj i elektrotehničkoj proizvodnji uz podršku za pojedinačnu, maloserijsku ili serijsku proizvodnju. Upravo stoga je model funkcionalno prilagođen postojećoj unutarnjoj strukturi ERPINS-M sustava.

Za potrebe fizičke pohrane zapisa objekata predloženih modelom učinjena je nadogradnja u strukturi tablica baze podataka sustava. Nadogradnjom su izbjegnute strukturne izmjene unutar postojećih tablica, a ujedno je postignuta jednostavnija prototipna implementacija. Nadograđene tablice su prikazane u obliku zapisa SQL54 jezika [75] koji je naročito prikladan za prikaz tablica baze podataka (Tablica 6.1). Zapisane naredbe za kreiranje tablica su izvedene unutar Oracle 9i RDBMS sustava [76, 77, 78] u bazi podataka ERPINS-M sustava. Ovako izvedene tablice su potom korištene za pohranjivanje odgovarajućih podataka prilikom testiranja prototipne ERP implementacije.

Tablica 6.1: SQL zapis nadograđenih i korištenih tablica

SQL zapis Opis

create table D80DOKU1 ( IB_ELEMENTA VARCHAR2(10) not null, RB_DOKUMENTA NUMBER not null, VERZIJA NUMBER not null, BIN_ZAPIS LONG RAW, EKSTENZIJA VARCHAR2(10), DATUM_VERZIJE DATE, NAPOMENA VARCHAR2(4000), VARIJANTA_SASTAVNICE NUMBER(3), NAZIV_DATOTEKE VARCHAR2(200), ZAPISAO VARCHAR2(10), KORISTI VARCHAR2(10), OPIS VARCHAR2(4000) ) tablespace USERS pctfree 10 initrans 1 maxtrans 255 storage ( initial 128K minextents 1 maxextents unlimited ); -- Add comments to the table comment on table D80DOKU1 is 'Tablica CAD dokumenata'; -- Create/Recreate primary, unique and foreign key constraints alter table D80DOKU1 add constraint D80_PK primary key (IB_ELEMENTA, RB_DOKUMENTA, VERZIJA) using index tablespace USERS pctfree 10 initrans 2

Tablica za pohranu strukturiranih CAD

dokumenata

54 Od engl. Structured Query Language – vrlo popularan računalni jezik za stvaranje, izmjenu i povlačenje podataka iz sustava za upravljanje relacijskom bazom podataka.

Prototipna implementacija modela 79

maxtrans 255 storage ( initial 128K minextents 1 maxextents unlimited ); alter table D80DOKU1 add constraint D80_D00_FK foreign key (IB_ELEMENTA) references D00ELEM1 (SIFRA);

create table D83DODATNI_DOK ( IB_ELEMENTA VARCHAR2(10) not null, RB NUMBER not null, BIN_ZAPIS LONG RAW, EKSTENZIJA VARCHAR2(10), NAZIV_DATOTEKE VARCHAR2(200), DATUM DATE, ZAPISAO VARCHAR2(10), KORISTI VARCHAR2(10), NAPOMENA VARCHAR2(4000), VERZIJA NUMBER, OPIS VARCHAR2(4000) ) tablespace USERS pctfree 10 initrans 1 maxtrans 255 storage ( initial 128K minextents 1 maxextents unlimited ); -- Create/Recreate primary, unique and foreign key constraints alter table D83DODATNI_DOK add constraint D83_PK primary key (IB_ELEMENTA, RB) using index tablespace USERS pctfree 10 initrans 2 maxtrans 255 storage ( initial 128K minextents 1 maxextents unlimited );

Tablica za pohranu nestrukturiranih

dokumenata

create table D06SASTAVNICAD1 ( IB_NADREDENOG VARCHAR2(10) not null, VARIJANTA NUMBER(3) not null, RB NUMBER(5) not null, IB_PODREDENOG VARCHAR2(10) not null, KOLICINA_U_NADREDENOM NUMBER not null, JM VARCHAR2(4), POZICIJA VARCHAR2(10) ) tablespace USERS pctfree 10 initrans 1 maxtrans 255 storage ( initial 128K minextents 1 maxextents unlimited ); -- Add comments to the table comment on table D06SASTAVNICAD1 is 'sastavnica stavke';

Tablica za pohranu odnosa elemenata


-- Create/Recreate primary, unique and foreign key constraints alter table D06SASTAVNICAD1 add constraint D06SASTAVNICA1 primary key (IB_NADREDENOG, VARIJANTA, RB) using index tablespace USERS pctfree 10 initrans 2 maxtrans 255 storage ( initial 128K minextents 1 maxextents unlimited ); alter table D06SASTAVNICAD1 add constraint D06B01_FK foreign key (JM) references B01JEMJ1 (JM); alter table D06SASTAVNICAD1 add constraint D06D00_FK foreign key (IB_PODREDENOG) references D00ELEM1 (SIFRA); alter table D06SASTAVNICAD1 add constraint D06D05_FK foreign key (IB_NADREDENOG, VARIJANTA) references D05SASTAVNICAM1 (IB_NADREDENOG, VARIJANTA); -- Create/Recreate indexes create unique index D06_UNIQUE on D06SASTAVNICAD1 (IB_NADREDENOG, VARIJANTA,

IB_PODREDENOG) tablespace USERS pctfree 10 initrans 2 maxtrans 255 storage ( initial 128K minextents 1 maxextents unlimited );

Osim prikazanih tablica, u izvedbi su korištene i postojeće tablice ERPINS-M sustava:

• Tablica osnovnih podataka korisnika ERPINS-M sustava – djelatnika poduzeća u kojemu je sustav implementiran,

• Tablica korisničkih imena i lozinki korisnika sustava, povezana s tablicom osnovnih podataka korisnika preko ključa,

• Tablica razine korisničkih prava, povezana s objema prethodnim tablicama,

• Osnovna tablica podataka o proizvodnim elementima.

Sve navedene tablice, kako izvorne tako i nadograđene tablice, korištene su u sve tri razine prototipne implementacije: u ERP sustavu, u CAD sustavu i u web-aplikaciji vanjskog pristupa.

U prikazivanju izvedene implementacije, napisani programski kod nije analiziran detaljno. Prikazivanje samog programskog koda i detaljna analiza primijenjenih algoritama bi se prostiralo na više stranica. Stoga je uz disertaciju priložen medij s digitalnim zapisom programskog koda prikazanih prototipnih implementacija kao i same disertacije, što bi trebalo znatno olakšati pristup i čitanje.

6.1 ERPINS-M IMPLEMENTACIJA

Kako je osnovna namjera izvedenih modela pružiti podršku razvoju proizvoda i dijeljenju podataka kroz ERP sustav, model je implementiran kao strukturalna i funkcionalna nadogradnja podsustava za definiciju proizvoda i tehnologije – DEPTO. U strukturi modula podsustava


DEPTO (Slika 6.1) implementacija se odražava u proširenju modula proizvodnih elemenata, sastavnice i uključenju funkcija baratanja strukturiranim CAD dokumentima kao i dokumentima druge vrste. Razvoj funkcija je radi kompatibilnosti izveden u jednakom razvojnom okruženju [79] u kojemu su rađeni i svi drugi moduli sustava ERPINS-M, uz intenzivnu primjenu programerskog sučelja prema odabranom CAD sustavu Autodesk Inventor Professional [80].

Slika 6.1: Prošireni ( ) i pridodani ( ) DEPTO moduli

Implementacija dijelova predloženog modela unutar DEPTO modula zahtijevala je prilagođavanje sučelja aplikacije koje je usklađeno potrebama implementacije (Slika 6.2).

Okvir za pretraživanje po dijelu naziva i tablični popis proizvodnih elemenata služe za odabir aktivnog proizvodnog elementa. U tabličnom popisu proizvodnih elemenata osjenčani reci označavaju element koji sadrži podređene elemente. Modul podržava i određivanje polaznih materijala za proizvodnju pojedinog elementa, a materijal se zapisuje i prikazuje kao podređeni element. Zbog toga je moguće da i jednostavni proizvodni elementi odnosno dijelovi budu prikazani osjenčano, ako im je određen i pridružen polazni materijal.

U okviru sučelja za prikaz strukture, u tablici je izveden hijerarhijski prikaz strukture prethodno odabranog aktivnog proizvodnog elementa. Zaokružene brojke na početku svakog retka tablice prikaza strukture označavaju razinu podređenosti pojedinog proizvodnog elementa. Primjerice, element 120 "Zatik" ima brojku 3 za oznaku razine, što znači da u hijerarhiji iznad sebe ima dva nadređena složena proizvodna elementa. Reci složenih proizvodnih elemenata na početku imaju uobičajene znakove za razgranavanje (+) ili sažimanje (-) hijerarhijskog prikaza promatranog složenog elementa.

Prije same jedinstvene oznake elementa u stupcu "Šifra" može se nalaziti ikona koja označava da promatrani proizvodni element ima uz sebe povezane strukturirane CAD dokumente. Ukoliko uz jedinstvenu oznaku nema ikone tada uz promatrani element nema povezanih CAD dokumenata, ali nije isključena mogućnost da ima dodatnih ili nestrukturiranih dokumenata.

Predviđene radnje nad odabranim elementom u prikazu strukture dostupne su preko plutajućeg izbornika. U prvoj skupini na izborniku su svrstane radnje za baratanje strukturom aktivnog elementa: dodavanje, izmjena i uklanjanje pojedinog podređenog elementa te potpuno


brisanje strukture. Druga skupina sadrži radnje za određivanje tehnologije. Treća skupina nudi radnje za izmjenu podataka pojedinog elementa poput jedinstvene oznake, naziva, vrste i drugih, kao i za dodavanje potpuno novog elementa koji se odmah uključuje u strukturu aktivnog složenog elementa.

Stavka "Dodaj dokument" služi za povezivanje strukturiranih CAD dokumenata i dodatnih dokumenata uz aktivni proizvodni element. Osim na izborniku aktivnog elementa dostupna je i na plutajućem izborniku u okviru za prikaz povezanih dokumenata (Slika 6.3).

Prijavljeni korisnik

Pretraživanje po nazivu

Prikaz strukture Radnje nad

elementom Popis

proizvodnih elemenata

Prikaz dokumenta

Povezani dokumenti

Slika 6.2: Sučelje modula DEPTO nakon implementacije modela

Okvir za prikaz povezanih dokumenata prikazuje sve dokumente povezane uz aktivni proizvodni element. Pri tome se CAD dokumenti prikazuju strukturirano pri čemu je na vrhu model sklopa ili dijela ovisno o vrsti proizvodnog elementa. Izvedba dopušta povezivanje samo jednog dokumenta modela sklopa ili dijela uz proizvodni element, što odgovara načinu razvoja sklopova i dijelova.


Slika 6.3: Izbornik radnji nad dokumentima

Ispod retka dokumenta modela u strukturi se mogu nalaziti podređeni dokumenti prikaza i crteža, ukoliko su zapisani u bazu. Radi lakšeg razlikovanja, ispred naziva dokumenata su prikazane odgovarajuće ikone usklađene s oznakama dokumenata CAD sustava podržanog u prototipnoj implementaciji. Nakon strukturiranih CAD dokumenata u okviru se prikazuju dokumenti drugih formata povezanih uz aktivni proizvodni element.

U okviru za prikaz povezanih dokumenata prikazuju se samo najnovije verzije dokumenata, ali se u sustavu čuvaju i sve prethodne verzije. Pristup prethodnoj verziji pojedinog dokumenta dostupan je kroz stavku za izvođenje verzija na plutajućem izborniku koja poziva odgovarajući dijalog (Slika 6.4).

Slika 6.4: Izvođenje prethodnih verzija dokumenata

Radi lakšeg snalaženja među dokumentima, dodan je okvir za brzi prikaz aktivnog CAD dokumenta. Prikaz CAD dokumenata se može otvoriti u zasebnom prozoru (Slika 6.5), ukoliko je na korisnikovom računalu dostupna i prijavljena odgovarajuća biblioteka za prikaz dokumenata.


Slika 6.5: Prikaz modela u zasebnom prozoru

Izborom stavke za dodavanje dokumenta s jednog od navedenih plutajućih izbornika pokreće se postupak povezivanja dokumenta uz aktivni proizvodni element i aktivira dijalog za odabir dokumenta koji će se povezati uz element i zapisati u bazu podataka (Slika 6.6). U dijalogu su dostupne tri osnovne radnje: traženja željenog dokumenta (dugme "Potraži"), povezivanja (dugme "Dodaj u bazu") i izlaska.

Ukoliko odabrani CAD dokument interno koristi druge dokumente, ugrađene rutine čitaju referencirane dokumente i prikazuju ih u okvirima za potrebne dokumente. U primjeru prikazanom na slici, odabran je dokument crteža modela "Držač potpornja.idw" koji za svoje prikazivanje koristi i dokument modela dijela "Držač potpornja.idw" prikazanog u dijelu za potrebne dokumente. Pozivanjem radnje dodavanja u bazu, uz aktivni proizvodni element se povezuju oba dokumenta uz poštivanje međusobnih odnosa među dokumentima. Prilikom pohranjivanja datoteke dokumenta, putanja prikazana u okviru Datoteka se zanemaruje. Neposredno prije zapisivanja dokumenta korisnik može unijeti napomenu uz dodani dokument. Napomene se obično upisuju uz naredne verzije jednom zapisanog dokumenta, kao kratki opisi razloga za izvođenjem nove verzije dokumenta.

Dodavanje CAD dokumenata izvedeno je obzirom na vrstu proizvodnog elementa pa tako nije moguće uz složen proizvodni element dodati dokument modela dijela niti je uz jednostavni proizvodni element moguće dodati dokument modela sklopa ili prikaza sklopa.

Ista stavka i dijalog su namijenjeni dodavanju dokumenata druge vrste. Razlučivanje u odnosu na strukturirane dokumente vrši se promjenom tipa traženog dokumenta u standardnom dijalogu za odabir datoteke koji se pojavljuje pozivanjem dugmeta za traženje dokumenta.

Nad zapisanim dokumentima moguće je izvršiti radnje predviđene modelom baratanja dokumentima. Radnje su dostupne na plutajućem izborniku u okviru za prikaz povezanih dokumenata (Slika 6.3).

Izvođenje strukturiranog dokumenta implementirano je tako da se na korisnikovo računalo uz odabrani dokument zapisuju i svi dokumenti potrebni za otvaranje odabranog dokumenta. Nakon izvođenja, sukladno razmatranom informacijskom modelu, dokument je u bazi zaključan za druge korisnike, što se prikazuje odgovarajućom ikonicom na početku retka zaključanog dokumenta u okviru za prikaz dokumenata. Zaključani dokument u aktualnoj implementaciji može otključati samo korisnik koji ga je zaključao, pozivanjem stavke za prijavu dokumenta s plutajućeg izbornika dokumenata (Slika 6.3) ili administrator sustava. Radnja prijave dokumenta upisuje novi sadržaj kao novi zapis istog dokumenta, ali s brojem verzije uvećanim za jedan, uz mogućnost dodavanja napomene uz novu verziju. Ukoliko korisnik odustane od upisa novog sadržaja na raspolaganju je opcija otključavanja dokumenta nakon čega je promatrani dokument ponovno dostupan svim korisnicima sustava.


Prikaz dokumenta

Podaci aktivnog elementa

Podaci odabranog dokumenta

Dostupne radnje

Potrebni dokumenti

Slika 6.6: Dijalog za odabir dokumenta

Nakon dodavanja nove verzije dokumenta, iz trezora se ne uklanjaju prethodne verzije. Prethodne verzije dokumenta ostaju dostupne kroz stavku izbornika "Izvedi verziju" čijim se pozivanjem može odabrati željena verzija dokumenta koja će se iz trezora izvesti lokalno na korisnikovo računalo.

Brisanje dokumenta za kojeg postoji više zapisanih verzija, iz sigurnosnih razloga iz trezora uklanja samo posljednju verziju, tako da je za potpuno uklanjanje dokumenta potrebno brisati unatrag verziju po verziju. Analogno vrijedi i za uklanjanje strukturno povezanih dokumenata: nije dopušteno ukloniti dokument modela sklopa ili dijela dok uz proizvodni


element ima dokumenata koji ga referenciraju u svojem sadržaju. Zbog toga je nužno prethodno ukloniti sve ovisne dokumente.

6.2 CAD IMPLEMENTACIJA

Kako se posao na razvoju modela proizvoda i sastavnih komponenata uglavnom odvija u zasebnim računalnim aplikacijama poput CAD/CAM/CAE aplikacija, za uspjeh primjene modela potrebno je izvesti funkcionalnost što bliže korisnicima u računalno okruženje u kojemu obavljaju većinu posla. Zbog toga je u prototipnoj implementaciji ogledno izvedena funkcionalnost baratanja strukturiranim dokumentima i povezivanje s proizvodnim elementima ERPINS-M sustava unutar odabranog CAD sustava.

Odabrani CAD sustav je Autodesk Inventor Professional 9 [80]. Inventor je sustav za prostorno parametarsko modeliranje tehničkih sklopova i dijelova temeljen na značajkama. Prema opsegu spada u red CAD sustava srednje opsežnosti. Odabran je uglavnom zbog svojeg otvorenog programerskog sučelja [81] i općenite zastupljenosti Autodeskovih rješenja u promatranom okruženju.

Slika 6.7: Osnovna klasa izvedenog vanjskog modula

Implementacija u CAD sustav izvedena je kao zasebno programsko proširenje integrirano kroz funkcionalnost vanjskih modula55 koje Inventor svojom otvorenom arhitekturom podržava. I većina drugih CAD sustava ima otvorenu arhitekturu i programersko sučelje, što donekle 55 Izvorno se u mnogih otvorenih sustava za integrirane vanjske module koristi engl. izraz Add-In.


olakšava prevođenje razvijenih proširenja. Ipak, i uz sve pogodnosti prevođenje programskih proširenja nije jednostavan posao. Programski kod modula pisan je u jeziku Microsoft C#56 [82], objektno orijentiranom jeziku koji je razvijen u sklopu projekta .NET Framework platforme. Osnove jezika su preuzete iz jezika C++ i Java u cilju što bolje podrške brzom razvoju aplikacija. Prilikom pisanja programskog koda također je korišten objektno orijentirani pristup programiranju pa je u samoj izvedbi modula kreirano i upotrijebljeno nekoliko klasa s pripadnim članicama i metodama (Slika 6.7).

Klasa ERPINS je izvedena kao sučelje prema drugim klasama, ali i prema korisniku CAD sustava kroz padajući izbornik. Kroz njene metode (OnoMnuLoginExecute, OnoMnuLogoffExecute, OnoMnuERPINSMExecute…) se pozivaju ostale klase koje izvršavaju konkretne zadaće između Inventora i ERPINS-M sustava.

Unutar Inventora, funkcionalnost implementiranog vanjskog modula korisnicima je dostupna preko padajućeg izbornika ERPINS-M (Slika 6.8). Puna funkcionalnost modula postaje dostupna tek nakon valjane prijave korisnika na sustav ERPINS-M unosom ispravne kombinacije korisničkog imena i lozinke. I druge stavke izbornika su izvedene osjetljivo na okruženje u kojemu se izvršavaju te su dostupne samo ukoliko su zadovoljeni određeni uvjeti.

Izbornik vanjskog modula

Slika 6.8: Izbornik vanjskog modula u CAD sustavu

Naredba za izvođenje dokumenta omogućava korisniku odabir i otvaranje željenog dokumenta iz ERPINS-M sustava i dostupna je odmah nakon uspješne prijave. Izvođenje dokumenata se odvija kroz dva dijaloga. U prvom dijalogu, unutar okvira hijerarhijskog prikaza proizvodnih elemenata dostupni su samo elementi koji uz sebe imaju povezane dokumente (Slika 6.9). Proizvodi i sklopovi se prikazuju u punoj strukturi sa svim podređenim elementima koji su također dostupni za odabir čime se nastoji olakšati pronalaženje željenog elementa. Dokumenti povezani uz odabrani proizvodni element prikazani su u popisu u najvišim odnosno aktualnim verzijama. Ukoliko je pojedini dokument zaključan od strane drugog korisnika, redak je prikazan zasivljeno, jer ga nije moguće odabrati za izvođenje.

Odabirom dokumenta i aktiviranjem dugmeta za izvođenje pokreće se provjera povezanih nadređenih dokumenata unutar istog elementa, ukoliko dokument po svojoj naravi može imati povezane dokumente. Dokumenti crteža modela dijelova ili sklopova te prikaza

56 Izvorno na engl. se pretežno izgovara "C sharp".


sklopova u pravilu imaju nadređene dokumente. Nadređene dokumente neophodno je izvesti prije otvaranja odabranog dokumenta, jer su referencirani unutar odabranog podređenog dokumenta.

Slika 6.9: Dijalozi izvođenja dokumenata

Provjera se vrši izvođenjem SQL upita nad tablicom dokumenata po stupcu atributa RB_DOKUMENTA i zadanoj jedinstvenoj oznaci odabranog elementa IB_ELEMENTA (Slika 6.10). Atribut RB_DOKUMENTA označava razinu dokumenta unutar promatranog elementa. Primjerice, ukoliko promatrani složeni proizvodni element – proizvod ili sklop ima povezana sve tri vrste dokumenata, tada je dokumentu modela pridružena razina 1, prikazu modela pridružena je razina 2 te konačno crtežu modela razina 3.

// Provjera ima li odabrani nadređenih dokumenata (sklopovi: IAM i IPN; dijelovi: IPT) // IPT nema izravno nadređenih po zapisu dokumenta if (redak["EKSTENZIJA"].ToString()!="ipt") { //provjera potrebnih nadređenih i podređenih dokumenata int zakljucanih = 0; // upit za nadređene dokumente string sql = "SELECT * FROM D80DOKU1, (SELECT NAZIV_DATOTEKE, MAX(VERZIJA) VERZIJA FROM D80DOKU1" + " WHERE IB_ELEMENTA='" + redak["IB_ELEMENTA"].ToString() + "' GROUP BY NAZIV_DATOTEKE) A" + " WHERE D80DOKU1.NAZIV_DATOTEKE=A.NAZIV_DATOTEKE AND D80DOKU1.VERZIJA=A.VERZIJA AND" + " D80DOKU1.RB_DOKUMENTA <='" + redak["RB_DOKUMENTA"].ToString() + "' AND D80DOKU1.IB_ELEMENTA = '" + redak["IB_ELEMENTA"].ToString() + "' ORDER BY RB_DOKUMENTA DESC"; OracleDataAdapter oa = new OracleDataAdapter(sql, oraCon); DataSet ds = new DataSet(); oa.Fill(ds, "Docs");

Slika 6.10: Provjera nadređenih povezanih dokumenata unutar odabranog elementa

Osim unutar elementa, za odabrani dokument potrebno je provjeriti i povezane podređene dokumente modela sastavnih podsklopova i dijelova po strukturi složenog elementa. U bazi podataka promatranog ERP sustava struktura proizvodnih elemenata fizički je zapisana po modelu popisa susjedstva57 po kojemu se u jednom retku zapisuje nadređene i podređeni 57 Engl. Adjacency list model.


element. Zbog toga je pronalaženje svih podređenih elemenata i njihovih dokumenata modela izvedeno kroz rekurzivni algoritam (Slika 6.11). Algoritam je izveden u funkciji podModeli koja prima jedinstvenu oznaku elementa čije se podređene dokumente modela želi pronaći, a vraća skup redaka koji sadrže podređene dokumente. SQL upit pronalazi podređene u prvoj razini. Potom se provjerava tip dokumenta svakog podređenog i ukoliko je tip dokumenta model sklopa, funkcija se poziva rekurzivno prosljeđivanjem jedinstvene oznake pripadnog elementa.

Nakon pronalaženja svih povezanih nadređenih i podređenih dokumenata, iz skupa redaka se uklanjaju nedostupni dokumenti zaključani od drugih korisnika i rezultat se prikazuje na popisu dokumenata u dijalogu za odabir i izvođenje povezanih dokumenata (Slika 6.9). Aktiviranjem izvođenja u potonjem dijalogu, odabrani dokumenti se zapisuju u odabranu mapu i zaključavaju za druge korisnike od strane prijavljenog korisnika. Prilikom zapisivanja u svojstva datoteka se dodaju osnovni atributi koji olakšavaju naknadna baratanja prema ERPINS-M sustavu.

Po dovršetku zapisivanja pokušava se otvoriti osnovni odabrani dokument unutar Inventora. Otvaranje ne mora biti uspješno ukoliko su neke datoteke bile nedostupne za izvođenje odnosno zaključane od drugih korisnika. // provjera potrebnih podređenih int kraj = ds.Tables["Docs"].Rows.Count; for (int i = 0; i < kraj; i++) { redak = ds.Tables["Docs"].Rows[i]; // Provjera podređenih modela uz model sklopa po sastavnici elemenata if (redak["EKSTENZIJA"].ToString() == "iam") ds.Merge(podModeli (redak["IB_ELEMENTA"].ToString())); } // Metoda pronalazi podređene dijelove i sklopove za zadani IBE public DataSet podModeli (string IBE) { string sql = @"SELECT * FROM D80DOKU1, (SELECT IB_ELEMENTA, MAX(VERZIJA) VERZIJA FROM D80DOKU1, (SELECT IB_PODREDENOG FROM D06SASTAVNICAD1 WHERE IB_NADREDENOG = '"

+ IBE + "') P WHERE IB_ELEMENTA= P.IB_PODREDENOG GROUP BY IB_ELEMENTA) V WHERE D80DOKU1.IB_ELEMENTA=V.IB_ELEMENTA AND D80DOKU1.VERZIJA=V.VERZIJA AND D80DOKU1.RB_DOKUMENTA = '1' ORDER BY RB_DOKUMENTA ASC"; OracleDataAdapter oda = new OracleDataAdapter(sql, oraCon); DataSet dtst = new DataSet(); oda.Fill(dtst, "Docs"); int kraj = dtst.Tables["Docs"].Rows.Count; for (int i = 0; i < kraj ; i++) { DataRow redak = dtst.Tables["Docs"].Rows[i]; // rekurzija za dokument modela sklopa if (redak["EKSTENZIJA"].ToString() == "iam") dtst.Merge(podModeli ((string)redak["IB_ELEMENTA"])); } return dtst; }

Slika 6.11: Provjera po strukturi odabranog elementa

Osnovna naredba za povezivanje aktualnog dokumenta uz proizvodni element sustava ERPINS-M, dostupna je ako je unutar Inventora otvoren barem jedan dokument. Izvršava se za otvoreni i aktivni dokument u Inventoru, ali za njegove povezane dokumente bez obzira da li su


trenutno otvoreni ili ne. Ukoliko je aktivni dokument složen (model, prikaz ili crtež sklopa) vrši se rekurzivna sinkronizacija strukturne sastavnice odabranog proizvodnog elementa sa strukturom podređenih dokumenata dijelova i podsklopova na način predložen u prethodnom poglavlju.

Prijava dokumenta omogućena je ako je barem jedan dokument otvoren i ako aktivni otvoreni dokument ima svojstva datoteke koja označavaju da je prethodno izveden iz ERPINS-M sustava. Osim za aktivnog dokument, analiziraju se i povezani dokumenti bez obzira da li su trenutno otvoreni ili ne. Ukoliko je aktivni dokument složen, provjerava se eventualna promjena i sinkronizira strukturna sastavnica povezanog proizvodnog elementa s novom strukturom.

Naredba otključavanja dokumenata dostupna je ako je barem jedan dokument otvoren uz uvjet da aktivni otvoreni dokument ima svojstva datoteke koja označavaju da je prethodno izveden iz ERPINS-M sustava i najzad ako je aktivni otvoreni dokument još uvijek zaključan u ERPINS-M sustavu. Ukoliko dokument sadrži podređene i nadređene dokumente, otvara se zaseban dijalog u kojemu se pojedinačno mogu odabrati povezani zaključani dokumenti koje će se otključati. Izvršavanjem naredbe dokument se stavlja na raspolaganje drugim korisnicima čime se odbacuju sve eventualno učinjene promjene u dokumentu od trenutka izvođenja iz trezora.

6.3 IMPLEMENTACIJA VANJSKOG PRISTUPA

Implementacija web aplikacije vanjskog pristupa izvedena je na softverskoj razvojnoj platformi Microsoft .NET Framework [83]. Microsoft .NET Framework je razvojna platforma usmjerena ka brzom razvoju aplikacija koje su u dobrom dijelu neovisne o platformama na kojima se implementiraju. Platforma pruža podršku razvoju aplikacija za operativni sustav Windows, za web kao i za razvoj komponenti i web servisa. Ove značajke omogućavaju korištenje razvijenih rutina iz jednog okruženja u drugom. Kako je vanjski modul opisan u prethodnom poglavlju također izveden na Microsoft .NET Framework platformi, donekle je, iako ne u potpunosti, pojednostavljeno pisanje programskog koda za web-aplikaciju. Jednostavan prijenos programskog koda ipak nije moguć zbog znatnih razlika između dva okruženja u kojima se programski kod treba izvršavati. Programski kod web aplikacije je također pisan u jeziku Microsoft C# [82].

Slika 6.12: Prijava korisnika web aplikacije

Web aplikacija je podignuta na HTTP poslužitelj uz podršku Microsoft Internet Information Services (IIS) paketa za operativne sustave Windows serije [84]. U radu aplikacija


komunicira s bazom podataka ERPINS-M sustava koja je za potrebe testiranja postavljena na zasebnom Oracle poslužitelju [85, 86, 87].

Web aplikaciji se pristupa kroz Internet preglednik unosom pune adrese poslužitelja i same aplikacije. Brzina prvog učitavanja aplikacije izravno ovisi o kvaliteti veze kojom se korisnik spaja kao i o opterećenosti veze poslužitelja.

private void cmdPrijava_Click(object sender, EventArgs e) { DataSet ds = new DataSet(); try { string sql = "SELECT * FROM ERPINSM1.X05UM WHERE Korisnik ='" + txtKorIme.Text + "' AND Password ='" + txtLozinka.Text + "'"; OracleDataAdapter a = new OracleDataAdapter(sql, c); a.Fill(ds, "User"); } finally{} // Ako je autorizacija uspješna, kreira se autorizirana kartica if (ds.Tables["User"].Rows.Count == 1) { DataRow r = ds.Tables["User"].Rows[0]; string ovlasti = r["OvlastiW"].ToString();

FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(

1, // verzija txtKorIme.Text, // korisničko ime DateTime.Now, // vrijeme izdavanja DateTime.Now.AddMinutes(30),// vrijeme istjecanja false, // Postojanost ovlasti ); // Ovlasti

// Zaštita kartice string encryptedTicket = FormsAuthentication.Encrypt(authTicket); // Stvaranje kolačića i zapisivanje zaštićene kartice u njega HttpCookie authCookie = new HttpCookie (FormsAuthentication.FormsCookieName, encryptedTicket); // Dodavanje kolačića u kolekciju Response.Cookies.Add(authCookie); Response.Redirect("default.aspx"); } else { litGreska.Text = "Pogreška u korisničkom imenu ili lozinci."; }

} // Kraj postupka prijave

Slika 6.13: Programski kod za prijavu korisnika

Po učitavanju se od korisnika traži valjano korisničko ime i lozinka kako bi mogao pristupiti aplikaciji (Slika 6.12). Kako je riječ o vanjskom pristupu kroz Internet preglednik koji se može nalaziti na bilo kojem računalu u svijetu, radi povećanja sigurnosti se nakon uspješne autorizacije kreira autorizirana kartica koja vrijedi samo u zadanom razdoblju od pola sata. Kartica se dodatno štiti enkripcijom i zapisuje u HTTP kolačić58. Nakon isteka razdoblja valjanosti, kolačić se uklanja s korisnikovog računala (Slika 6.13).

Nakon uspješne prijave, u osnovnom dijelu prototipne web-aplikacije moguće je pretraživati i prikazivati proizvodne elemente prema osnovnoj podjeli na proizvod, sklop i dio (Slika 6.14). U okviru za pretraživanje moguće je unijeti dio naziva po kojemu se želi pretraživati. Ukoliko se okvir ostavi prazan, pozivanje rutine za pretraživanje vratiti će kao rezultat pretraživanja sve elemente odabrane vrste iz sustava. Prikaz elemenata je radi lakše preglednosti i bržeg rada ograničen na jednu stranicu. Ako je pronađeno više elemenata nego što

58 Uobičajen je engl. izraz cookie. Označava paket informacija koje HTTP poslužitelj šalje pregledniku, a potom HTTP preglednik šalje paket natrag kod svakog narednog pristupa poslužitelju.


ih stane na početnu stranicu, dodaje se onoliko stranica koliko je potrebno za prikaz svih elemenata. Na narednu stranicu se u tom slučaju prelazi odabirom brojčane veze u dnu stranice.

U prikazu rezultata pretraživanja, nazivi proizvodnih elemenata koji imaju strukturu zapisanu u ERPINS-M sustavu prikazani su naglašeno i izvedeni kao veza na prikaz strukture pojedinog elementa. Suprotno, odnosno bez naglašavanja naziva i veza prikazani su elementi bez strukture.

Element sa strukturom

Element bez strukture

Slika 6.14: Pretraživanje i prikaz proizvodnih elemenata

Prikaz strukture odabranog složenog proizvodnog elementa izveden je na hijerarhijski način (Slika 6.15). I u prikazu sastavnih elemenata u strukturi zadržana je dosljednost u označavanju pa su nazivi elemenata koji imaju povezane strukturirane dokumente prikazani kao veze koje vode do prikaza dokumenata, dok su nazivi elemenata bez povezanih dokumenata prikazani kao jednostavan tekst. U prototipnoj izvedbi vanjskog pristupa korisnicima nije dopušteno mijenjanje strukture složenog proizvodnog elementa, kao ni dodavanje strukturiranih dokumenata.


Slika 6.15: Prikaz strukture

Uz uobičajeni hijerarhijski način prikazivanja strukture složenog elementa, u prototipnoj implementaciji izveden je i prikaz strukture u XML59 formatu [88, 89]. XML se paralelno s eksplozijom primjene Interneta posljednjih godina nametnuo kao vodeći jezik označavanja opće namjene s osnovnom zadaćom olakšavanja dijeljenja podataka između raznovrsnih sustava naročito onih povezanih preko Interneta. Opseg, a time i značaj primjene XML-a doveo je do toga da se većina posebno razvijenih standarda ili jezika za razmjenu i dijeljenje podataka posljednjih godina nastoji prepisati ili dodatno izvesti i u XML formatu. Izuzetak od toga nisu niti ISO STEP ni EXPRESS za koje je također učinjen znatan napor prema prikazu u XML formatu [90].

XML zapis je prema pravilima jezika hijerarhijski strukturiran uz obavezan osnovni element u čiju se strukturu hijerarhijski gnijezde ostali pripadni elementi. Kao takav je vrlo pogodan i za prikaz strukture (Slika 6.16) složenih proizvodnih elemenata, jer je zapis relativno podjednako lako čitljiv i ljudima i računalima. Još je važnija značajka da je XML jezik sposoban opisati mnoge različite tipove podataka pa je prikaz strukture vrlo jednostavno proširiti dodatnim atributima prema potrebi korisnika. Nažalost, cijena dobre čitljivosti i prilagodljivosti plaćena je na strani fizičkog zapisa pa su dokumenti zapisani u XML formatu u pravilu znatno veći od onih zapisanih u specijaliziranim formatima. U izvedenoj web aplikaciji XML prikaz je zapisan na poslužitelju u odgovarajuću XML datoteku koju je moguće prikazati u pregledniku, ali i pohraniti lokalno na korisničko računalo radi eventualne zasebne obrade.

59 Od engl. Extensible Markup Language.


Slika 6.16: XML prikaz strukture proizvoda

U prikazu CAD dokumenata povezanih uz promatrani proizvodni element (Slika 6.17), pojedini dokument može biti prikazan na tri načina. Ukoliko je dokument dostupan za povlačenje iz baze prikazan je kao poveznica koja vodi do stranice za povlačenje povezanih dokumenata (Slika 6.17). Dokumenti koje je određeni korisnik zaključao mogu biti prikazani na dva načina ovisno o tome koji korisnik je prijavljen i promatra dokumente. U primjeru sa slike u lijevom dijelu je prikaz koji vidi korisnik "tgaleta" i njemu su dokumenti "Potporanj.iam" i ""Potporanj.ipn" prikazani kao zaključani, ali s mogućnošću otključavanja, jer ih je on prethodno zaključao. Međutim, dokument "Potporanj.idw" mu nije dostupan, jer ga je zaključao drugi korisnik "TT". Osnovne podatke drugog korisnika može pogledati ako slijedi poveznicu iza "Zaključao:", kako bi ga eventualno kontaktirao radi otključavanja. Obrnuti prikaz zaključanih dokumenata vidi drugi korisnik.

Za korisnika TT

Za korisnika tgaleta

Slika 6.17: Prikazi povezanih dokumenata za različite korisnike

Odluči li se korisnik na povlačenje određenog dokumenata aktiviranjem njegove poveznice, vrši se provjera neophodnih povezanih dokumenata unutar istog elementa i prikazuju se svi dokumenti koje je potrebno povući (Slika 6.18). Ukoliko je neki od neophodnih dokumenata zaključan od drugog korisnika, ispisuje se upozorenje i uputa o načinu rješavanja.

Slika 6.18: Povlačenje i zaključani dokumenti

96

7 PROCJENA MODELA I PROTOTIPNE IMPLEMENTACIJE

Informacijski modeli dijeljenja podataka o proizvodu u procesu razvoja proizvoda kroz ERP sustave i njihova prototipna implementacija prikazana u prethodnom poglavlju, izvedeni su na tragu početne teze disertacije. Odabrani segmenti PDM koncepta i ISO STEP sheme prilagođeni su specifičnom ERP sustavu za proizvodna poduzeća - sustavu ERPINS-M u cilju smanjivanja ponavljajućih poslova i broja raznovrsnih računalnih sustava uključenih u proces razvoja proizvoda.

Za bolju procjenu uspješnosti prilagodbe i implementacije, prikladno je predložiti kriterije odnosno smjernice vrednovanja specifične funkcionalnosti. Prva varijanta smjernica vrednovanja objavljena je za vrijeme razvoja disertacije u zborniku radova međunarodnog znanstvenog skupa Design 2004 [91]. Osnove predloženih smjernica vrednovanja biti će primijenjene u ovom poglavlju u ponešto dorađenoj varijanti. Dorade smjernica su potaknute novim spoznajama koje su se pojavile u razdoblju od pisanja rada za skup do pisanja ovog poglavlja.

U vrijeme pisanja rada pokušalo se kroz razgovore s korisnicima – članovima razvojnih timova proizvodnih poduzeća u okruženju, spoznati najčešće korištene PDM funkcije kao i druge specifičnosti primjene PDM sustava u okruženju, i tako pobliže odrediti postupak procjene PDM funkcionalnosti ERP sustava. Tada se pokazalo da su samo su rijetki sugovornici bili uopće upoznati s PDM konceptom tako da rezultati ispitivanja nisu mogli poslužiti prilikom pisanja rada za konferenciju.

Kontakti s predstavnicom tvrtke CIMdata urodili su kasnijim objavljivanjem niza jednostavnih anketa na njihovim web stranicama [59]. Ankete su izvedene jednostavno, jer sadrže samo jedno pitanje po anketi uz mogućnost izbora ponuđenih odgovora.

Nakon prve ankete objavljeno ih je još nekoliko, od kojih je za ovo poglavlje disertacije naročito zanimljiva anketa [92] u kojoj su ispitanici odgovarali na pitanje: "Imate li zadane kriterije kojima pratite unapređenje proizašlo primjenom PLM rješenja?" (Slika 7.1). Iz odgovora je vidljivo da uglavnom nema postavljenih jasnih kriterija koji bi poslužili za ocjenu koristi od primjene PDM/PLM koncepta u poduzeću.

27%

2%

15%

7%

49%

Nema postavljenih: 49%

Samo za razvoj: 27%

Samo za proizvodnju: 2%

Samo za neka funkcionalna područja(bez razvoja ili proizvodnje): 15%

Postavljene kroz poduzeće (preko višefunkcionalnih područja): 7%

n = 104

Slika 7.1: Rezultati ankete o mjerama praćenja napretka uslijed primjene PLM rješenja

Kako rezultati anketa nisu bili dostupni u vrijeme pisanja rada za znanstveni skup, nisu se mogli odraziti na kriterije izložene u objavljenom radu. Međutim, odgovori na anketno pitanje o korištenim funkcijama prikazani u poglavlju 4.5 bacaju novo svjetlo na značaj pojedine PDM funkcije. Prema mišljenju autora svakako bi se trebali odraziti na kriterije vrednovanja kroz

Procjena modela i prototipne implementacije 97

korekciju razdiobe bodova pojedinoj funkciji. Stoga su u nastavku, prije same procjene modela, ukratko izložene smjernice vrednovanja prikazane u radu uz određene dorade prema spoznajama iz rezultata anketa.

7.1 SMJERNICE PROCJENE

Radi pojednostavljenja postupka procjene, PDM funkcije (Poglavlje 4.5) su razvrstane u dvije skupine: (1) osnovne funkcije i (2) proširene funkcije, dok je posebno razmatrana razina integracije unutar ERP sustava.

Osnovne PDM funkcije su po logici računalnih aplikacija vrsna razlika po kojoj se PDM sustavi razlikuju u rodu računalnih aplikacija. Među osnovne funkcije su svrstane:

1. Trezor podataka o proizvodu s kontroliranim pristupom

2. Upravljanje strukturom proizvoda

3. Upravljanje razvojnim procesom

4. Upravljanje projektima

5. Klasifikacija komponenti

Sve druge funkcije su svrstane u skupinu proširenih funkcija, primarno stoga što se mogu naći i u mnogim drugim računalnim aplikacijama ili pak i kao jednostavnije samostalne aplikacije. Neke od proširenih funkcija mogu biti funkcije za komunikaciju i obavještavanje, prijenos i prijevod podataka, prikaz slika i administraciju sustava.

U idealnoj izvedbi ERP sustav bi uključivao punu PDM funkcionalnost. Takva izvedba se može vrednovati s određenim iznosom bodova ili postotnim udjelom, primjerice sa 100 bodova ili 100 % PDM funkcionalnosti. Radi dosljednosti s prethodnim radom i radi pojednostavljenja, idealna izvedba ERP sustava s obzirom na PDM funkcionalnost je označena sa 100 bodova, ali je riječ "bodovi" izostavljana radi lakšeg praćenja.

Smjernice vrednovanja mogu biti podijeljene u pet razina vrednovanja:

I. Razina implementacije osnovne funkcionalnosti – oznaka LCF

II. Razina implementacije proširene funkcionalnosti – oznaka LEF

III. Razina integracije unutar ERP sustava – oznaka LII

IV. Razina postignutog integriteta podataka o proizvodu – oznaka LPDI

V. Razina postignute sigurnosti podataka o proizvodu – oznaka LPDS

Zbroj svih razina vrednovanja tada izražava postignutu razinu PDM funkcionalnosti promatranog ERP sustava i može se zapisati izrazom:

5

1i CF EF II PDI PDS

iL L L L L L L

=

= = + + + +∑ (1)

Prilikom vrednovanja PDM funkcionalnosti sve razine ne bi trebale imati jednaku vrijednost, primjerice razina implementacije osnovne funkcionalnosti bi trebala značiti više u ukupnoj ocjeni od razine implementacije proširene funkcionalnosti. Stoga je predložena nerazmjerna razdioba vrijednosti razina prikazana tablično (Tablica 7.1).


Tablica 7.1: Razdioba udjela po razinama

Stupanj LCF LEF LII LPDI LPDS L

Udio 60 10 10 10 10 Σ = 100

Kako bi procjena bila točnija, nužno je detaljnije proanalizirati doprinos pojedine

funkcije unutar pojedine promatrane razine. Prikladna analiza provedena je u radu [91], dok je u narednim odlomcima predstavljen donekle pojednostavljen prikaz prilagođen disertaciji.

7.1.1 Razina implementacije osnovne funkcionalnosti – LCF

U prvoj inačici smjernica, razdioba udjela po osnovnim funkcijama izvršena je proporcionalno, jer još nisu bili poznati rezultati ankete o korištenim funkcijama prikazani u poglavlju 4.5. Kako je napomenuto, rezultati ankete bi se trebali odraziti kroz korekciju razdiobe bodova u razini implementacije osnovne funkcionalnosti. Stoga je ovdje razdioba izvedena nerazmjerno tako da se udio pojedine osnovne funkcije LCFi dobije množenjem ukupnog iznosa dodijeljenog razini (LCF = 60) s udjelom kojeg je ostvarila pojedina osnovna funkcija ki, što se može zapisati izrazom:

5

1CFi i CF

iL k

=

= ⋅∑ L (2)

Dobivene korigirane vrijednosti udjela pojedinih osnovnih funkcija su zaokružene i prikazane tablično (Tablica 7.2). Izvedena nerazmjerna razdioba vrijednosti značajno se razlikuje od prvobitne razmjerne inačice, ali pri tome i bolje odražava značaj funkcija za uspjeh implementacije kod korisnika.

Tablica 7.2: Razdioba udjela osnovnih funkcija

Funkcija Upravljanje strukturom proizvoda

Trezor podataka o proizvodu

Upravljanje razvojnim procesom

Upravljanje projektima

Klasifikacija komponenti LCF

Udio 45 10 2 2 1 Σ = 60

Prilikom procjene udjela pojedine razine implementacije treba biti što je moguće manje

stupnjeva slobode te se udjeli trebaju smanjivati ukoliko se uoče određeni nedostaci u implementaciji pojedine osnovne funkcije. Primjerice, ukoliko je implementirana podrška samo za popis komponenti bez hijerarhijske strukture proizvoda i bez podrške za strukturne dokumente, zbog svog značaja procijenjeni udio treba biti ispod 10 bodova.

7.1.2 Razina implementacije proširene funkcionalnosti – LEF

Tablica 7.3 prikazuje predloženu razdiobu u razini implementacije proširene funkcionalnosti.

Tablica 7.3: Razdioba udjela proširenih funkcija

Funkcija Komunikacija i obavijesti

Prijenos podataka

Prijevod podataka

Grafički servisi

Administracija sustava LEF

Udio 2 2 2 2 2 Σ = 10


Pri procjeni implementacije funkcija komunikacija i obavijesti razmatra se da li je omogućeno automatizirano obavještavanje korisnika o kritičnim događajima i da li su u izvedbi korišteni standardni protokoli poput elektronske pošte.

Prijenos podataka treba biti izveden tako da se pohranjenim podacima pristupa isključivo kroz module ERP sustava pri čemu korisnik ne mora znati gdje su zapravo u računalnoj mreži podaci pohranjeni.

Prijevod podataka iz jednog oblika u druge tražene oblike treba zadovoljiti potrebe korisnika sustava kako bi bio procijenjen 1 bodom, a ukoliko je funkcija izvedena automatizirano može se dodijeliti predviđeni maksimum u razdiobi.

Grafički servisi trebaju omogućiti prikaz potrebnih grafičkih tipova podataka i mogućnost dodavanja komentara, oznaka pregledavanja i odobravanja kako bi bili procijenjeni punim udjelom.

Ukoliko funkcije administracije sustava uz zadovljavanje osnovnih administracijskih zahtjeva omogućavaju i određeno prilagođavanje korisničkog sučelja, slanje sistemskih poruka, integraciju dodatnih aplikacija i nove funkcionalnosti, može se dodijeliti predviđeni najveći broj bodova.

7.1.3 Razina integracije unutar ERP sustava – LII

Predviđenim udjelom za razinu integracije PDM funkcionalnosti unutar ERP sustava se nastoje procijeniti dva vida integracije. Od toga 7 bodova služi za ocjenu način pozivanja većine osnovnih i dijela proširenih PDM funkcija unutar ERP sustava. Preostalih 3 boda se mogu dodijeliti prema načinu integracije na razini baze podataka prema razvrstavanju Ou-Yanga [93].

7.1.4 Razina postignutog integriteta podataka o proizvodu – LPDI

Osnovni podaci potrebni za opisivanje proizvodnje pojedinog proizvoda moraju biti neprestano dostupni kroz ERP sustav, bez obzira na postupke održavanja ili padove sustava. Primjerice, pad jednog poslužitelja baze podataka ne smije onemogućiti pristup strukturi proizvoda. Svaka uočena slaba točka u integritetu podataka treba se odraziti na smanjenje dodijeljene ocijene za postignutu razinu integriteta podataka.

7.1.5 Razina postignute sigurnosti podataka o proizvodu – LPDS

Određeni podaci o proizvodu trebaju biti dostupni samo određenim korisnicima ERP sustava, odnosno dobro zaštićeni od neovlaštenog pristupa bilo od korisnika s drugom razinom prava bilo od pokušaja zlonamjernih provala. Dobra izvedba sigurnosti donosi pola udjela predviđenog u ovoj razini. Drugi dio je predviđen za procjenu funkcija sigurnosne pohrane i arhiviranja.

7.2 IZVEDBA PROCJENE PREMA SMJERNICAMA

Radi lakšeg pregleda i usporedbe rezultati procjene su prikazani u tablici (Tablica 7.4). Procjena funkcionalnosti prema prethodno prikazanim smjernicama je izvedena u dva navrata. U prvom navratu je procijenjena PDM funkcionalnost ERP sustava ERPINS-M prije prototipne implementacije izvedenih modela. Rezultati procjene prije prototipne implementacije su prikazani u stupcu tablice nazvanom "Prije". Druga procjena je učinjena poslije implementacije i rezultati su u stupcu "Poslije". Posljednji stupac "Maksimum" prikazuje najveće moguće


vrijednosti koje može ostvariti pojedina razina funkcionalnosti. Sjenčano su istaknute razine funkcionalnosti ili skupine funkcija u kojima implementacija modela doprinosi ukupnoj razini PDM funkcionalnosti sustava ERPINS-M, a pripadne procijenjene vrijednosti udjela doprinosa implementacije su istaknute podebljano. U nastavku su pobliže razmotrene razine i procijenjene vrijednosti doprinosa implementacije.

Osnovne razine PDM funkcionalnosti koje podiže implementacija izloženog modela su funkcije upravljanja strukturom proizvoda (LCF1) i funkcije trezora podataka o proizvodu s kontroliranim pristupom (LCF2). To su upravo one koje prema anketi [59] korisnici PDM sustava najviše upotrebljavaju u svom svakodnevnom radu.

Prije implementacije modela upravljanja strukturom ERPINS-M sustav je imao podršku strukturiranju proizvoda na razini proizvodnih elemenata zatvorenu unutar sustava. Implementacija je donijela otvoreni model upravljanja strukturom uz podršku za strukturirane CAD dokumente i sinkronizaciju strukture proizvoda generiranu ili promijenjenu u CAD sustavu. Ipak, nije moguće dodijeliti najveći mogući broj bodova, jer je model u prototipnoj implementaciji ograničen na jedan CAD sustav. To je u proizvodnim poduzećima uglavnom dovoljno, ali se može pokazati ograničenjem kod dijeljenja podataka u distribuiranom razvoju proizvoda.

Tablica 7.4: Procjena razine PDM funkcionalnosti ERP sustava

Udjeli Razine funkcionalnosti

Poslije Prije Maksimum

L 73 28 100

LCF 51 20 60

Struktura 40 15 45

Trezor 8 2 10

Razvoj 1 1 2

Projekti 1 1 2

Klasifikacija 1 1 1

LEF 5 3 10

Komunikacija 1 1 2

Prijenos 2 1 2

Prijevod 0 0 2

Grafika 1 0 2

Administracija 1 1 2

LII 9 0 10

LPDI 4 2 10

LPDS 4 3 10

Od funkcija trezora podataka o proizvodu, sustav ERPINS-M je prije prototipne

implementacije imao vrlo razvijen model meta-podataka i mogućnost dodjeljivanja jednog dokumenta uz jedan proizvodni element. Implementacija modela donijela je proširenje odnosa na više strukturiranih i nestrukturiranih dokumenata uz jedan proizvodni element u cilju bolje podrške procesu razvoja proizvoda. Maksimum bodova nije dodijeljen, jer neke funkcije trezora podataka poput podrške upravljanju neovisnim dokumentima nisu predmet disertacije i stoga nisu dublje razmatrane niti implementirane.

Prijenos podataka (razina LEF) izveden je upravo tako da se pohranjenim podacima pristupa isključivo kroz module ERPINS-M sustava pri čemu korisnik ne mora znati gdje su zapravo u računalnoj mreži podaci pohranjeni. I prije implementacije modela sustav je imao


dobro riješen prijenos podataka, ali se posredno proširenjem razine osnovne funkcionalnosti zaokružuje funkcija prijenosa podataka, što omogućuje dodjelu maksimalno predviđenog broja bodova.

U prototipnoj implementaciji ugrađena je podrška za pregled sadržaja strukturnih i osnovnih tipova dokumenata unutar samog ERPINS-M sustava, ali bez mogućnosti dodavanja komentara i oznaka pregledavanja osim uz verzije dokumenata. Stoga je pridodan bod grafičkoj funkcionalnosti (razina LEF).

Za procjenu razine integracije unutar ERP sustava (LII) treba uočiti kako je prototipna implementacija modela u razini PDM funkcionalnosti izvedena u potpunosti u sklopu ERP sustava ERPINS-M pa je zbog toga moguće dodijeliti svih predviđenih 7 bodova za način izvođenja PDM funkcionalnosti. Uz to je za fizičko zapisivanje PDM podataka korištena i baza podataka ERPINS-M sustava, što daje i preostalih 3 boda predviđena za način integracije na razini baze podataka.

Iako razina postignutog integriteta podataka o proizvodu (LPDI) u većem dijelu ovisi o organizaciji poslužitelja i samoj bazi podataka ERP sustava, ipak je i ostvarena dostupnost svih potrebnih podataka o proizvodu kroz ERPINS-M sustav povećala integritet podataka za procijenjenih 2 boda u odnosu na stanje prije prototipne implementacije modela.

Sigurnost podataka o proizvodu od neovlaštenog pristupa bila je zadovoljavajuće izvedena kroz korisničku autorizaciju i prije prototipne implementacije modela. Stoga je razina sigurnosti nakon implementacije procijenjena za jedan bod više zbog uvođenja autoriziranog vanjskog pristupa. Sigurnost bi se mogla još povećati razradom prava pristupa nad pojedinim objektima i uvođenjem grupa, što bi zahtijevalo znatnu promjenu strukture svih objekata i zapisa ERP sustava. Međutim, vrlo je upitno da li bi se ovako zahtjevan posao uopće isplatio bilo korisnicima bilo izvođačima sustava.

U nekim razinama prototipna implementacija ne donosi pomake u smislu PDM funkcionalnosti. Razlozi su višeznačni i ovise o pojedinoj funkciji. U razini osnovne funkcionalnosti za funkcije upravljanja razvojnim procesom, upravljanja projektima i klasifikacije komponenti kao i u razini proširene funkcionalnosti za funkciju administracije sustava, autor smatra da je postojeća razina funkcionalnosti ERPINS-M sustava dovoljno razvijena i prikladna za izvršavanje traženih funkcija uz određeno prilagođavanje korisnika sustavu. Unapređenje specifične funkcionalnosti ne bi mnogo značilo korisnicima, a time niti samom sustavu te stoga nije posebno razmatrano u disertaciji. Funkcije komunikacije i obavijesti te prijevoda podataka su one za koje većina korisnika koristi već standardizirane protokole ili aplikacije. Vrijeme utrošeno na razvoj ili implementaciju ovih funkcija unutar sustava lako može postati nepovratno, jer je velika vjerojatnost da ih korisnici ne usvoje. Primjerice, iako je moguće uložiti trud i izvesti prijevod zapisa dokumenta prostornog modela iz specifičnog CAD formata u STEP format zapisa, vrlo je mala vjerojatnost da će korisnici pozivati prevođenje unutar ERP sustava umjesto iz CAD aplikacije u kojoj je model izrađen. U tom smislu predlažem oslanjanje na dostupne aplikacije i postojeće usvojene protokole.

Prototipna implementacija vanjskog pristupa nije pokrivena prethodnom procjenom, jer je riječ o cjelini koja po svojim obilježjima ne pripada u područje PDM funkcionalnosti. Međutim, mogućnost vanjskog pristupa je važna pretpostavka u distribuiranom procesu razvoja proizvoda. Stoga je izvedena prototipna implementacija izrađena kao primjer i eventualna okosnica budućem razvoju vanjskog pristupa ERPINS-M sustavu.

102

8 ZAKLJUČAK

Istraživanja i modeli predstavljeni u okviru disertacije postavljeni su u cilju provjere početne teze: implementacija prilagođenog PDM modela u ERP sustav omogućava dijeljenje podataka o proizvodu kroz ERP sustav; olakšava proces razvoja novog proizvoda; smanjuje ponavljanje poslova i smanjuje broj raznovrsnih računalnih sustava uključenih u procese razvoja i proizvodnje proizvoda.

Razmatranje teorije tehničkih sustava poslužilo je za postavljanje okvira i sagledavanje opsega osnovnih zajedničkih pojmova i uređenog skupa zaključaka važnih u razumijevanju i opisivanju proizvoda. Na njih je nadovezana analiza modernih poimanja procesa konstruiranja radi uočavanja razine utjecaja pojedinih sudionika u proizvodnji na razvoj novog proizvoda. Iz analize prihvaćenih teorija se može zaključiti da razvoj novog proizvoda ne završava postupcima pripreme proizvodnje i samom proizvodnjom već je u modernom pristupu riječ o iterativnom i korektivnom procesu koji se može promatrati kroz čitav životni vijek proizvoda.

Uz podržavanje početne teze, posredni cilj disertacije bio je razmotriti moguće odgovore na neka od temeljnih pitanja koja se postavljaju u razmatranjima koncepta upravljanja proizvodnim podacima. Jedno takvo pitanje je imaju li samostalni PDM sustavi budućnost ili će se njihova funkcionalnost uključivati unutar drugih općenitijih sustava poput ERP sustava. Učinjen pregled stanja i usporedba tržišta PDM i ERP sustava pokazuju kako je tržište ERP sustava prosječno financijski jače za red veličine od PDM sustava. Iz toga se može zaključiti o snazi ERP dobavljača da odvoje resurse i implementiraju PDM koncept i tako preuzmu značajan dio tržišta samostalnim PDM rješenjima, što daje uputiti o neizvjesnoj budućnosti dobavljača.

Analiza PDM koncepta upozorila je na moderan način prikazivanja proizvoda kroz digitalne prostorne modele sklopova i dijelova uz njihove odgovarajuće prikaze. Uvedeni su kroz CAD sustave za parametarsko modeliranje temeljeno na značajkama. Za razvoj proizvoda u smislu disertacije su značajni, jer se u njima u dobrom dijelu izvodi struktura novog proizvoda. Kako je nastava iz parametarskog modeliranja temeljenog na značajkama, unatrag nekoliko godina uvedena na većini tehničkih fakulteta, vrlo brzo treba očekivati značajnu primjenu ove tehnologije i u poduzećima u okruženju. U tu svrhu su prilikom analize koncepta istaknute temeljne PDM funkcije: upravljanje strukturom i trezor podataka, koje su u izvedbi informacijskog modela prilagođene promatranom ERPINS-M sustavu.

Razmotren je i učinak postojećih standarda u području dijeljenja proizvodnih podataka, prvenstveno ISO STEP PDM sheme te je razmotrena mogućnost prilagođavanja standardnih shema za potrebe implementacije unutar promatranog ERP sustava. Specifična izvedba sustava ERPINS-M ne dopušta punu implementaciju sheme, jer bi zahtijevala ponovno pisanje programskog koda mnogih podsustava. Međutim, vrlo je upitno da li bi puna implementacija sheme doprinijela dijeljenju podataka o proizvodu, jer sama shema nije u značajnoj mjeri zaživjela na tržištu. Osnove PDM sheme mogu ipak poslužiti kao dobra smjernica pa su u tom smislu i upotrijebljene prilikom postavljanja informacijskog modela izloženog u disertaciji.

Prilikom razmatranja primjene standarda u jednom se razdoblju pojavilo pitanje zapisivanja strukturiranih dokumenata u trezor u STEP formatu. Ideja je napuštena, jer iako većina CAD sustava podržava STEP format zapisivanja, niti jedan od testiranih sustava nije izveo dokument parametarskog modela temeljenog na značajkama u STEP format i natrag bez gubitka podataka. Uglavnom je podržan opis geometrije dok se parametri i značajke modela izgube prilikom izvoza. Otežavajuća okolnost standardnog formata je u tome što donošenje njegovih specifikacija kasni za aktualnim dostignućima CAD sustava.

Zaključak 103

Izvedeni model osmišljen je tako da proširuje mogućnosti autoriziranog dijeljenja podataka o proizvodu kroz ERPINS-M sustav. Model trezora podataka je postavljen tako da omogući baratanje i pohranu dokumenata na što je nadovezan model upravljanja strukturom uz povezivanje s proizvodnim elementima ERPINS-M sustava. Pri tome su poštivane posebnosti ERPINS-M sustava kao i posebnosti strukturiranih digitalnih dokumenata promatranog CAD sustava. Izvedeni model ide u prilog početnoj tezi te pokazuje da je moguće prilagoditi PDM model postojećoj arhitekturi ERP sustava proizvodnog poduzeća.

Prototipna implementacija modela trezora i upravljanja strukturom kroz strukturirane dokumente izvedena je u samom ERPINS-M sustavu. Sučelje prema funkcijama je također izvedeno i integrirano unutar odabranog CAD sustava, jer je autorovo mišljenje kako je za uspjeh primjene modela potrebno izvesti funkcionalnost što bliže korisnicima u računalno okruženje u kojemu obavljaju većinu posla. Pri tome unutar CAD sustava nije nužno preslikati sve mogućnosti ERPINS-M sustava, nego samo funkcije neophodne za razvoj proizvoda, što je učinjeno u implementaciji. Implementacija osnovne funkcionalnosti modela podržava početnu tezu disertacije, jer integriranim pristupom pojednostavljuje dijeljenje podataka o proizvodu.

Model vanjskog pristupa utemeljen na HTTP protokolu neophodan je za podršku dijeljena podataka o proizvodu u distribuiranom razvoju proizvoda. Implementacija osnovne funkcionalnosti baratanja strukturom proizvoda i upravljanja dokumentima u web aplikaciju za vanjski pristup pokazala je značajan potencijal višeslojnih web aplikacija, ali i još uvijek izražene nedostatke povezane uz propusnost podataka, sigurnost veza i brzine samih aplikacija.

Procjena modela i prototipne implementacije prema predloženim smjernicama upućuje na zaključak da se predloženim modelom može podići razina funkcionalnosti upravljanja podacima o proizvodu promatranog ERP sustava, što govori u prilog početnoj tezi disertacije. Nameće se pitanje da li u razvoju promatranih ERP sustava proizvodnih poduzeća treba težiti punoj PDM funkcionalnosti. Prema mišljenju autora odgovor nije jednoznačan, jer rezultati istraživanja upućuju kako se u većini slučajeva ne koriste sve funkcije pa je prije ulaganja vremena u implementaciju pojedine funkcije svakako potrebno ispitati ciljano tržište. Također pri tome treba razmotriti i da li su određene funkcije poput upravljanja razvojnim procesom ili upravljanja projektima već dovoljno razvijene i prikladne za izvršavanje traženih funkcija uz određeno prilagođavanje korisnika ERPINS-M sustavu. Primjerice, promatrani ERPINS-M sustav već ima vrlo razvijene module za planiranje i praćenje proizvodnje koje nije teško upotrijebiti za planiranje i praćenje razvoja proizvoda.

104

9 LITERATURA

1. Cantwell, J. i Vertova, G.: "Historical evolution of technological diversification". Research Policy, vol. 33, br. 3, str. 511-529, 2004.

2. Mowery, D. C.: "Technological Innovation in a Multipolar System: Analysis and Implications for U.S. Policy". Technological Forecasting and Social Change, vol. 67, str. 143–157, 2001.

3. Spanos, Y. E. i dr.: "The relationship between information and communication technologies adoption and management". Information & Management, vol. 39, str. 659-675, 2002.

4. Mo, J. P. T. i Zhou, M.: "Tools and methods for managing intangible assets of virtual enterprise". Computers in Industry, vol. 51, str. 197–210, 2003.

5. Hsieha, Y.-C. i dr.: "Virtual factory and relationship marketing - a case study of a Taiwan semiconductor manufacturing company". International Journal of Information Management, vol. 22, str. 109–126, 2002.

6. Yen, D. C. i dr.: "A synergic analysis for Web-based enterprise resources planning systems". Computer Standards & Interfaces, vol. 24, str. 337– 346, 2003.

7. Beard, J. W. i Sumner, M.: "Seeking strategic advantage in the post-net era: viewing ERP systems from the resource-based perspective". Journal of Strategic Information Systems, vol. 13, str. 129–150, 2004.

8. Galeta, T.: "Doprinos modelu razmjene podataka između informacijskih i CAD sustava". Magistarski rad, Strojarski fakultet, Sveučilište u Osijeku, Slavonski Brod, 2001.

9. Rezayat, M.: "The Enterprise-Web portal for life-cycle support". Computer-Aided Design, vol. 32, str. 85–96, 2000.

10. Majdandžić, N.: "Izgradnja informacijskih sustava proizvodnih poduzeća". Strojarski fakultet u Slavonskom Brodu, 2004.

11. Blessing, L. i Chakrabarti, A.: "DRM: A Design Research Methodology". Proceedings of Les Sciences de la Conception, INSA de Lyon, Lyon, 2002.

12. Jorgensen, K. A.: "Paradigms for research work". Department of Production, Alborg University, 1992.

13. Hubka, V. i Eder, W. E.: "Theory of Technical Systems". Springer-Verlag, New York, 1988.

14. Hubka, V. i Eder, W. E.: "Design Science". Springer-Verlag, Berlin, Heidelberg, New York, 1992.

15. Pahl, G. i Beitz, W.: "Engineering Design - A Systematic Approach". Springer - Verlag, London, 1996.

16. Taylor, E. S.: "M.I.T. Report". MIT Press, Cambridge, 1959. 17. "VDI Richtlinie 2221: Methodik zum Entwickeln und Konstruieren technischer Systeme

und Produkte". VDI-Verlag, Düsseldorf, 1993. 18. Suh, N. P.: "Elements of the Design Process," u Mechanical Engineering Handbook, ur.

Kreith, F., CRC Press LLC, Boca Raton, 1999. 19. Zhang, W. Y. i dr.: "A graph and matrix representation scheme for functional design of

mechanical products". The International Journal of Advanced Manufacturing Technology, 2004.

20. Herold, Z.: "Strukturiranje baze znanja u procesu konstruiranja". Disertacija, Fakultet strojarstva i brodogradnje, Sveučilište u Zagrebu, 1997.

Literatura 105

21. Zhang, W. Y. i dr.: "A Prototype Knowledge-Based System for Conceptual Synthesis of the Design Process". The International Journal of Advanced Manufacturing Technology, vol. 17, str. 549–557, 2001.

22. Campbell, M. I. i dr.: "A-Design: An Agent-Based Approach to Conceptual Design in a Dynamic Environment". Research in Engineering Design, vol. 11, str. 172–192, 1999.

23. Sim, S. K. i Duffy, A. H. B.: "Towards an ontology of generic engineering design activities". Research in Engineering Design, vol. 14, str. 200–223, 2003.

24. Shooter, S. B. i dr.: "A Model for the Flow of Design Information in Product Development". Engineering with Computers, vol. 16, str. 178–194, 2000.

25. Maier, M. W. i Rechtin, E.: "The Art of Systems Architecting". CRC Press, Boca Raton, London, New York, Washington, D.C., 2000.

26. "Encarta World English Dictionary". Microsoft Corporation, 2004. 27. Woodcock, J.: "Microsoft Press Informatički rječnik". Znak, Zagreb, 1995. 28. Bojčetić, N.: "Računalni model konstrukcijskog znanja". Doktorska disertacija, Fakultet

strojarstva i brodogradnje, Sveučilište u Zagrebu, Zagreb, 2001. 29. Chen, P.: "The entity-relationship model-towards a unified view of data". ACM

Transactions on Database Systems, vol. 1, br. 1, str. 9-36, 1976. 30. Davis, W. S. i Yen, D. C.: "The Information System Consultant’s Handbook: Systems

Analysis and Design". CRC Press, Boca Raton, 1999. 31. Owen, J.: "STEP An Introduction". Bookcraft Ltd, Midsomer Norton, 1993. 32. Zamir, S., ed. "Handbook of object technology". CRC Press LLC, Boca Raton, 1999. 33. "OMG Unified Modeling Language Specification". Object Management Group, Inc.,

Needham, 2003. 34. Booch, G. i dr.: "The Unified Modeling Language User Guide". Addison Wesley

Longman, Inc., Reading, 1999. 35. "The Top 100 Software Vendors". MSImag - IT for Manufacturing Executives, July,

2004. 36. "PDM / PLM Vendors, VARs and Service Providers".

http://www.pdmic.com/vendors/vendlist.html, PDM Information Company, 2004. 37. "Press Releases: A New Report from CIMdata Provides Detailed Analysis of the PLM

Market". CIMdata, Inc., Ann Arbor, 2004. 38. "Pro/INTRALINK Datasheet". 2003. 39. "Autodesk Data Management : Summary". Autodesk, Inc., San Rafael, 2004. 40. "Oracle kontrolira PeopleSoft". http://www.bug.hr/vijesti/index.asp?id=59249, Bug

d.o.o., 2004. 41. Kawamoto, D. i Gilbert, A.: "Oracle takeover: It's a wrap". http://news.zdnet.com/2100-

3513_22-5516752.html, 2005. 42. "Tvrtke korisnici SAP R/3". http://www.open.hr/hiz/hrusko/korisnici.html, HrUSKO -

Forum korisnika SAP-a Hrvatske, 2004. 43. "Pregled članica udruge". http://www.hiz.hr/HrOUG.html, HrOUG - Hrvatska udruga

ORACLE korisnika, 2004. 44. Martio, A.: "Product Data Technology Presented by HUT/SoberIT". Helsinki University

of Technology, Helsinki, 2001. 45. "ISO 13584-1 Industrial automation systems and integration -- Parts library -- Part 1:

Overview and fundamental principles". International Organization for Standardization TC 184/SC 4, Geneva, 2001.

46. "ISO 10303-41 Industrial automation systems and integration -- Product data representation and exchange -- Part 41: Integrated generic resources: Fundamentals of product description and support". International Organization for Standardization TC 184/SC 4, Geneve, 1994.

http://www.pdmic.com/vendors/vendlist.html

http://www.bug.hr/vijesti/index.asp?id=59249

http://news.zdnet.com/2100-3513_22-5516752.html

http://news.zdnet.com/2100-3513_22-5516752.html

http://www.open.hr/hiz/hrusko/korisnici.html

http://www.hiz.hr/HrOUG.html

Literatura 106

47. Kemmerer, S. J., ed. "STEP The Grand Experience". National Institute of Standards and Technology, Gaithersburg, 1999.

48. Peltonen, H.: "Concepts and an Implementation for Product Data Management". Disertacija, Department of Computer Science and Engineering, Helsinki University of Technology, Helsinki, 2000.

49. Peltonen, H.: "Enterprise Systems Integration / Document Management". Helsinki University of Technology, Helsinki, 2001.

50. Kreith, F., ed. "Mechanical Engineering Handbook". CRC Press LLC, Boca Raton, 1999. 51. "Product Data Management: The Definition, An Introduction to Concepts Benefits, and

Terminology". CIMdata, Inc., Ann Arbor, 1997. 52. Ungerer, M. i Buchanan, K.: "Usage Guide for the STEP PDM Schema Release 4.3".

PDM Implementor Forum, Darmstadt, 2002. 53. Niukkanen, N.: "PDM Practical View". Helsinki Universiti of Technology, Helsinki,

2001. 54. Carroll, B.: "PDMIC Help Desk - PDM and the Brazilian Market".

http://www.pdmic.com/help/help_BRA.html, PDM Information Company, 1996. 55. "IBM Product Lifecycle Management (PLM): Hrvatska". http://www-

306.ibm.com/solutions/plm/country/hr/index.html, IBM Hrvatska, 2004. 56. "Product Lifecycle Management - Empowering the Future of Business". CIMdata, Inc.,

Ann Arbor, 2002. 57. Liu, D. T. i Xu, X. W.: "A review of web-based product data management systems".

Computers in Industry, vol. 44, br. 3, str. 251-262, 2001. 58. Bourke, R. W.: "Product Data Management: More Than Just an ERP Module". Midrange

Enterprise Magazine, 2, 1997. 59. "CIMdata Online Polls: What PLM functions do your users utilize most?"

http://www.cimdata.com/images/polls/results_03.25.05.gif, CIMdata, Inc., 2005. 60. "HyperDictionary.com". http://www.hyperdictionary.com, WEBNOX CORP., 2003. 61. "web2CAD: PowerParts". http://www.web2cad.co.uk/, web2CAD TraceParts GmbH,

2004. 62. Dyla, A.: "Modell einer durchgängig rechnerbasierten Produktentwicklung". Doktorska

disertacija, Institut für Maschinen- und Fahrzeugtechnik - Lehrstuhl für Maschinenelemente, Technische Universität München, München, 2002.

63. "Wikipedia". http://wikipedia.org/, 2004. 64. Oha, Y. i dr.: "Mapping product structures between CAD and PDM systems using

UML". Computer-Aided Design, br. 33, str. 521-529, 2001. 65. Wehlitz, P.: "Nutzenorientierte Einführung eines Produktdatenmanagement-Systems".

Doktorska disertacija, Fakultät für Maschinenwesen, Technischen Universität München, München, 2000.

66. Sellgren, U. i Hakelius, C.: "A Survey of PDM Implementation Projects in Selected Swedish Industries". Proceedings of ASME Design Engineering Technical Conference, Irvine, California, 1996.

67. Lyon, D.: "PDMIC - Configuration Management Information Center Help Desk". http://www.pdmic.com/cmic/help/encapsulation.html, PDM Information Company, 1999.

68. "UML-Modell des STEP PDM Schema Version 1.2". http://www.plmportal.de/index.php?id=821, Forschungszentrum Informatik (FZI) an der Universität Karlsruhe, 2003.

69. Yeh, S.-C. i You, C.-F.: "STEP-based data schema for implementing product data management system". International Journal of Computer Integrated Manufacturing, vol. 15, br. 1, str. 1-17, 2002.

http://www.pdmic.com/help/help_BRA.html

http://www-306.ibm.com/solutions/plm/country/hr/index.html

http://www-306.ibm.com/solutions/plm/country/hr/index.html

http://www.cimdata.com/images/polls/results_03.25.05.gif

http://www.hyperdictionary.com/

http://www.web2cad.co.uk/

http://wikipedia.org/

http://www.pdmic.com/cmic/help/encapsulation.html

http://www.plmportal.de/index.php?id=821

Literatura 107

70. Gao, J. X. i dr.: "Application of product data management technologies for enterprise integration". International Journal of Computer Integrated Manufacturing, vol. 16, br. 7-8, str. 491–500, 2003.

71. Tavčar, J. i Duhovnik, J.: "Typical Models of Product Data Integration in Small and Medium Companies". The International Journal of Advanced Manufacturing Technology, br. 16, str. 748–758, 2000.

72. Ungerer, M.: "PDM Schema Version 1.2 EXPRESS-G". http://www.pdm-if.org/pdm_schema/pdm12-exg.pdf, PDM Implementor Forum, 2001.

73. Tudor, J. K.: "Information security architecture: an integrated approach to security in the organization". Auerbach CRC Press LLC, Boca Raton, 2001.

74. Štorga, M.: "Sustav za razmjenu i upravljanje informacijama o proizvodu". Magistarski rad, Fakultet strojarstva i brodogradnje, Sveučilište u Zagrebu, Zagreb, 2002.

75. "Oracle9i Lite SQL Reference, Release 5.0.2". Oracle Corporation, Redwood City, 2002. 76. "Oracle Products". http://www.oracle.com/products/index.html, Oracle Corporation,

2004. 77. Kelly, H. i dr.: "Oracle9i Database Administrator’s Guide, Release 1 (9.0.1) for

Windows". Oracle Corporation, Redwood City, 2001. 78. Watt, S.: "iSQL*Plus User’s Guide and Reference, Release 9.0.1". Oracle Corporation,

Redwood City, 2001. 79. "Borland Delphi 7 Developer's Guide". Borland Software Corporation, Scots Valley,

2002. 80. "Autodesk Inventor Professional 9 Home". http://www.autodesk.com/inventor/,

Autodesk Inc., 2004. 81. "Autodesk Inventor API Reference Guide". Autodesk, Inc., 2003. 82. "Visual Studio .NET 2003 Combined Help Collection". Microsoft Corporation, 2002. 83. "Microsoft .NET Framework SDK Documentation". Microsoft Corporation, 2002. 84. "Internet Information Services 5.1 (IIS) Documentation". Microsoft Corporation, 2001. 85. Brown, B. D.: "Oracle9i Web Development". Osborne Media/McGraw-Hill, Berkeley,

2001. 86. Chang, B. i dr.: "Oracle XML Handbook". Osborne Media/McGraw-Hill, Berkeley,

2000. 87. Greenberg, J. i dr.: "Oracle Provider for OLE DB Developer’s Guide, Release 9.0.1 for

Windows". Oracle Corporation, Redwood City, 2001. 88. Laurent, S. S.: "XML: A Primer". Wiley, John & Sons, Incorporated, 1997. 89. Harold, E. R. i Means, W. S.: "XML in a Nutshell". O'Reilly Media, Inc., Sebastopol,

2002. 90. Kimber, E.: "XML Representation Methods for EXPRESS-Driven Data". ISOGEN

International Corp., Gaithersburg, 1999. 91. Kljajin, M. i Galeta, T.: "Metrics For The PDM Functionality of ERP System".

Proceedings of International Design Conference - Design 2004, Faculty of Mechanical Engineering and Naval Architecture, Dubrovnik, 2004.

92. "CIMdata Online Polls: Have you established formal metrics that you use to track improvement resulting from use of your PLM solution?" http://www.cimdata.com/images/polls/results_05.20.05.gif, CIMdata, Inc., 2005.

93. Ou-Yang, C. i Jiang, T. A.: "Developing an Integration Framework to Support the Information Flow Between PDM and MRP". International Journal of Advanced Manufacturing Technology, vol. 19, str. 131–141, 2002.

http://www.pdm-if.org/pdm_schema/pdm12-exg.pdf

http://www.pdm-if.org/pdm_schema/pdm12-exg.pdf

http://www.oracle.com/products/index.html

http://www.autodesk.com/inventor/

http://www.cimdata.com/images/polls/results_05.20.05.gif

108

ŽIVOTOPIS

Tomislav Galeta rođen je 08. travnja 1971. godine u Osijeku. Osnovnu školu završio u Belišću. Maturirao u proljeće 1990. matematičko-informatički smjer u srednjoj školi u Valpovu. Diplomirao proizvodno strojarstvo, modul računalom integrirana proizvodnja, u prosincu 1995. godine na Strojarskom fakultetu u Slavonskom Brodu. Na trećoj godini studija dobio stipendiju zaklade "Dr. Cesare Kusan", a na četvrtoj nagradu dekana za uspješan studij.

Prvi posao radio u Računskom centru "Kombinata Belišće d. d.". Potom prešao u tvrtku "Magma d. d." u distributivni centar u Osijeku i radio do travnja 1997. Na poziv prof. dr. sc. Nike Majdandžića u svibnju 1997. prešao raditi kao znanstveni novak na Katedru za organizaciju i informatiku Strojarskog fakulteta u Slavonskom Brodu.

Magistrirao u svibnju 2001. na Strojarskom fakultetu u znanstvenom polju strojarstva na smjeru "Proizvodni sustavi".

U ljeto 2003. pohađao 5. ljetnu školu za istraživanja u inženjerskom dizajnu u organizaciji Svjetskog dizajnerskog društva.

Od jeseni 2002. predaje na Visokoj učiteljskoj školi u Slavonskom Brodu. Od jeseni 2003. predaje na Filozofskom fakultetu, a potom po odvajanju na sveučilišnom Odjelu za fiziku u Osijeku.

Ovlašteni je Autodeskov predavač u centru Pentium d.o.o. u Vinkovcima.

Kao autor ili koautor objavio 7 znanstvenih radova u zbornicima skupova s međunarodnom recenzijom, 1 stručni rad u zbornicima skupova s međunarodnom recenzijom, 1 pregledni rad u zbornicima skupova i 1 znanstveni rad u sažecima zbornika skupova.

109

BIOGRAPHY

Tomislav Galeta was born on April, 8th 1971 in Osijek, Republic of Croatia. Primary school finished in Belišće. He graduated in the spring of 1990 in mathematics and computer science at the Secondary School in Valpovo. BSc received in 1995 from Mechanical Engineering Faculty in Slavonski Brod. As one of the best students of the Faculty, he won the Dean's annual award as well as the scholarship from "Dr. Ceasare Kusan Foundation", dedicated to the best students.

First job as preparatory engineer was in Computer Center of "Kombinat Belišće". After that he have went over to the firm "Magma" in Osijek. In May 1997 on the invitation of PhD Niko Majdandžić have come to the Department of Organization and Information Technologies at Mechanical Engineering Faculty in Slavonski Brod.

MSc have received in May 2001 from Mechanical Engineering Faculty in Slavonski Brod in course "Production Systems".

In summer 2003 he have attended Summer School on Engineering Design Research organized by the Design Society. Since autumn 2002 he lectures at the Teacher's Faculty in Osijek, Department in Slavonski Brod. Since autumn 2003 lectures at the Faculty of Philosophy, the Department of Physics and Polytechnics with Information Technologies, and after separation at the University Department of Physics.

As an Autodesk certified instructor he continually lectures in the Autodesk's Training Center "Pentium" in Vinkovci.

As an author or co-author he has published 7 scientific papers in conference proceedings with international peer-review, 1 technical report in conference proceedings with international peer-review, 1 review in conference proceedings and 1 scientific paper in conference summaries proceedings.

110

PRILOG: DIGITALNA INAČICA DISERTACIJE

CD-R 8 cm

DIJELJENJE PODATAKA O PROIZVODU KROZ RAČUNALNE …Tablica 3.1: Ljestvica najvećih dobavljača...

Documents

Transcript of DIJELJENJE PODATAKA O PROIZVODU KROZ RAČUNALNE …Tablica 3.1: Ljestvica najvećih dobavljača...