implementacija procesa proizvodnje v informacijski reŠitvi · 2017. 11. 28. · - osnovna...
TRANSCRIPT
UNIVERZA V MARIBORU
FAKULTETA ZA ELEKTROTEHNIKO,
RAČUNALNIŠTVO IN INFORMATIKO
Kristijan Vogrinčič
IMPLEMENTACIJA PROCESA PROIZVODNJE
V INFORMACIJSKI REŠITVI
DATALAB PANTHEON
Diplomsko delo
Maribor, avgust 2016
UNIVERZA V MARIBORU
FAKULTETA ZA ELEKTROTEHNIKO,
RAČUNALNIŠTVO IN INFORMATIKO
Kristijan Vogrinčič
IMPLEMENTACIJA PROCESA PROIZVODNJE
V INFORMACIJSKI REŠITVI
DATALAB PANTHEON
Diplomsko delo
Maribor, avgust 2016
I
IMPLEMENTACIJA PROCESA PROIZVODNJE V
INFORMACIJSKI REŠITVI DATALAB PANTHEON
Diplomsko delo
Študent: Kristijan Vogrinčič
Študijski program: VS, Računalništvo in informatika
Smer: Informatika
Mentor: red. prof. dr. Marjan Heričko, univ. dipl. inž. rač. in inf.
II
III
Zahvala
Za vso pomoč in nasvete se zahvaljujem
mentorju, red. prof. dr. Marjanu Heričku.
Velika zahvala gre tudi mojim najbližjim,
predvsem Bernardi, ki mi je stala ob strani,
me spodbujala in motivirala.
Hvala.
IV
Implementacija procesa proizvodnje v
informacijski rešitvi Datalab Pantheon
Ključne besede: informacijski sistem, celovita informacijska rešitev, Pantheon, proizvodni
proces, prilagoditve
UDK: 004.65:004.451(043.2)
Povzetek
Diplomsko delo obravnava vidik implementacije proizvodnega procesa v informacijski
rešitvi Datalab Pantheon ter prikazuje možnosti različnih prilagoditev, ki jih dotična
informacijska rešitev omogoča. Predstavili bomo namen in razloge za implementacijo
proizvodnega procesa ter opisali informacijsko podporo procesu proizvodnje, od naročila
do izdelka. Praktični del obsega prikaz in uporabo razvitih prilagoditev in dodatnih rešitev
za podjetje, ki se ukvarja s proizvodnjo nizkoserijskih produktov. Prikazali bomo različne
tipe prilagoditev, ki jih Pantheon omogoča, ter samostojno razvito rešitev, ki je povezana s
podatkovno bazo sistema Pantheon.
V
Implementation of production process in
Datalab Pantheon information solution
Key words: information system, enterprise resource planning, Pantheon, production
process, customizations
UDK: 004.65:004.451(043.2)
Abstract
The graduation thesis discusses the aspect of production process implementation in
Datalab Pantheon information solution and displays various options of customizations
which the information solution in question enables. We will present the purpose and reasons
for implementing the production process and describe the information support provided for
it, from the order to the product. The practical part includes the presentation and the use of
developed customizations and additional solutions for a company, engaged in
manufacturing low-volume products. We will present different types of customizations that
Pantheon enables and an individually developed solution connected with Pantheon
database.
VI
KAZALO
1 UVOD ........................................................................................................................ 1
2 INFORMACIJSKI SISTEM PANTHEON .................................................................... 3
2.1 Funkcionalnosti ................................................................................................. 4
2.2 Sistem licenciranja ............................................................................................ 5
2.2.1 Licenca MF .................................................................................................... 6
2.2.2 Licenca MT .................................................................................................... 6
2.2.3 Licenca konektor ........................................................................................... 7
3 PROIZVODNJA V INFORMACIJSKEM SISTEMU PANTHEON ................................ 8
3.1 Razlogi za implementacijo proizvodnega procesa ............................................. 8
3.2 Opis informacijske podpore procesu proizvodnje ............................................. 11
3.2.1 Šifrant identov ............................................................................................. 11
3.2.2 Kosovnice .................................................................................................... 12
3.2.3 Naročila kupcev ........................................................................................... 14
3.2.4 Proizvodnja .................................................................................................. 14
4 UPORABLJENA ORODJA IN TEHNOLOGIJE ........................................................ 17
4.1 Razvojno orodje Ares ...................................................................................... 17
4.2 Orodje FastReport ........................................................................................... 18
4.3 Okolje Microsoft .NET ...................................................................................... 19
4.4 Strežnik Microsoft SQL Server ........................................................................ 20
5 ANALIZE PRILAGODITEV V INFORMACIJSKEM SISTEMU PANTHEON ............. 22
5.1 Analiza integracijske prilagoditve ..................................................................... 23
5.2 Analiza samostojne prilagoditve ...................................................................... 23
5.3 Analiza zunanje rešitve .................................................................................... 24
5.4 Nadgradnje ...................................................................................................... 25
6 PRILAGODITVE IN NADGRADNJE STANDARDNE REŠITVE ............................... 27
6.1 Integracijske prilagoditve ................................................................................. 29
6.1.1 Šifrant resursov ........................................................................................... 29
6.1.2 Šifrant Osnovna kosovnica .......................................................................... 32
6.2 Samostojne prilagoditve .................................................................................. 34
6.2.1 Planiranje delavcev ..................................................................................... 34
6.2.2 Dodatni planirni modul za mikroplaniranje ................................................... 37
6.2.3 Vodenje kod PIN .......................................................................................... 42
6.3 Zunanja aplikacija ............................................................................................ 44
VII
6.3.1 Nastavitve aplikacije .................................................................................... 44
6.3.2 Prijava v sistem na stroju ............................................................................. 45
6.3.3 Delo z aplikacijo na stroju ............................................................................ 46
6.3.4 Poročanje podatkov stroja ........................................................................... 48
6.4 Procedure, funkcije ter ostali bazni objekti ....................................................... 49
7 SKLEP ..................................................................................................................... 50
VIRI IN LITERATURA ..................................................................................................... 51
VIII
KAZALO SLIK
Slika 2.1: Primer namestitve sistema Pantheon [5] ........................................................... 3
Slika 2.2: Prikaz osnovnih funkcionalnosti sistema Pantheon [7] ...................................... 5
Slika 2.3: Prikaz uporabe licence konektor [10] ................................................................. 7
Slika 3.1: Procesi v podjetju .............................................................................................. 9
Slika 3.2: Časi izdelave ................................................................................................... 10
Slika 3.3: Primer strukture kosovnice [11] ....................................................................... 13
Slika 3.4: Primer trajanja enega cikla na štirih resursih ................................................... 15
Slika 4.1: Vgrajene funkcionalnosti in dodatne rešitve [7] ................................................ 17
Slika 4.2: Okolje Ares ...................................................................................................... 18
Slika 4.3: Okolje Fast Report, integrirano v sistemu Pantheon ........................................ 19
Slika 5.1: Prilagoditve rešitve ERP [13] [14] .................................................................... 22
Slika 6.1: Prikaz stroja za rotacijsko litje s tremi rokami [14] ............................................ 30
Slika 6.2: Dodatna polja v šifrantu resursov .................................................................... 32
Slika 6.3: Integracijska dodelava na osnovni kosovnici – možni resursi .......................... 32
Slika 6.4: Integracijska dodelava na osnovni kosovnici - dodatni podatki za planiranje ... 33
Slika 6.5: Dostop do programa "Razpored delavcev" ...................................................... 34
Slika 6.6: Maska za vnos v program "Razpored delavcev" - neizpolnjen ......................... 35
Slika 6.7: Vnos delavcev v program "Razpored delavcev" .............................................. 36
Slika 6.8: Izpis iz programa "Razpored delavcev" ........................................................... 37
Slika 6.9: Planirni modul za mikroplaniranje .................................................................... 38
Slika 6.10: Planirni modul - ročno planiranje ................................................................... 38
Slika 6.11: Kontrola podvajanje ciklov ............................................................................. 40
Slika 6.12: Možni resursi pri planiranju ............................................................................ 40
Slika 6.13: Vnos resursa pri planiranju ............................................................................ 41
Slika 6.14: Prikaz rund in zasedenosti cikla .................................................................... 41
Slika 6.15: Kontrole pri mikroplaniranju ........................................................................... 41
Slika 6.16: Filtriranje ciklov.............................................................................................. 42
Slika 6.17: Opomba delavcem s strani planerja .............................................................. 42
Slika 6.18: Vodenje prijavnih kod za RM delavce ............................................................ 43
Slika 6.19: Črtna koda za prijavo .................................................................................... 44
Slika 6.20: Primer datoteke XML "settings.xml" ............................................................... 45
Slika 6.21: Prijavna maska v aplikaciji na stroju .............................................................. 45
IX
Slika 6.22: Prijavna maska v aplikaciji na stroju - ročna prijava ...................................... 46
Slika 6.23: Shema povezav med sistemom Pantheon in dodatnimi rešitvami ................. 49
KAZALO TABEL
Tabela 4.1: Omejitve verzije Express strežnika Microsoft SQL [13] ................................. 20
Tabela 4.2: Prikaz poimenovanj naših objektov na podatkovni bazi SQL ........................ 21
X
UPORABLJENE KRATICE
DDV Davek na dodano vrednost
DN Delovni nalog
DPA Datalab Pantheon Applet
EAN Črtna koda (angl. International Article Number)
ERP Celovita informacijska rešitev (angl. Enterprise Resource Planning)
IS Informacijski sistem
IT Informacijska tehnologija
MRP Planiranje materialnih potreb (angl. Material Resource Planning)
PIN Osebna identifikacijska številka
RM Rotacijsko litje (angl. Rotational molding) – tip proizvodnje v podjetju
SME Mala in srednja podjetja (angl. Small and medium enterprises)
SQL Strukturirani povpraševalni jezik (angl. Structured Query Language)
TSQL Transakcijski SQL (razširitev jezika SQL podjetij Microsoft in Sybase)
XML Razširljiv označevalni jezik (angl. Extensible Markup Language)
1
1 UVOD
»Proizvodnja je zavestno dejanje proizvajanja nečesa koristnega. To 'koristno' je proizvod;
le-ta je lahko materialni (fizični) izdelek ali pa nematerialna storitev. [1] Proizvodni proces
pa definiramo kot »proces proizvajanja (izdelave) proizvodov; sistem, v katerem se odvija
proizvodni proces, je proizvodni sistem.« [1]
Dandanes so tudi v industrijski proizvodnji najpomembnejši dobri podatki. Ni namreč samo
pomembno kaj, kdo, kako, kako dolgo in na kakšen način se bo proizvajalo. Velika vrednost
dobrega proizvodnega sistema so tudi povratne informacije, na podlagi katerih lahko
podjetje sproti izboljšuje svoj proizvodni proces na vseh nivojih, vodstvo pa na podlagi njih
sprejema hitre in pravilne odločitve. Veliko vrednost v tem segmentu zagotavlja dober
informacijski sistem.
Informacijski sistem (v nadaljevanju IS) Pantheon je eden izmed najbolj razširjenih
informacijskih sistemov tako v Sloveniji kot tudi v jugovzhodni Evropi. Gre za celovito
informacijsko rešitev (v nadaljevanju ERP – Enterprise Resource Planning), ki pokriva vse
potrebe večine malih in srednjih podjetij (SME – Small and Medium Enterprises), tako ima
tudi zelo dobro podprte funkcionalnosti za proizvodnjo in planiranje le-te. Podjetje Datalab
Tehnologije d.d., ki je razvijalec informacijskega sistema, ima predstavništva v Sloveniji,
Hrvaški, Bosni in Hercegovini, Srbiji, Črni gori, Makedoniji, Bolgariji, Albaniji, na Kosovem
in v Švici. Poleg lastnih predstavništev ima tudi široko mrežo partnerskih podjetij, ki skrbijo
za implementacije in podporo za produkt. Skupaj so prodali in implementirali že blizu 50.000
licenc. [2]
Sistem ERP je integriran informacijski sistem, ki temelji na centralizirani podatkovni bazi in
ima skupno programsko platformo, ki pomaga pri učinkoviti rabi virov podjetja in olajšuje
pretok informacij med vsemi poslovnimi funkcijami v podjetju. [3] Skozi zgodovino so sistemi
ERP »presegli načrtovanje proizvodnih sredstev in tako postali celoviti poslovni
informacijski sistemi.« [4] V Sloveniji so mnogi »nastali kot računovodski programi, ki so
postopoma prevzemali vse več funkcij – od upravljanja človeških virov pa do podpore
ključnim procesom v podjetjih.« [4]
2
Diplomsko delo je razdeljeno na sedem poglavij. Prvo poglavje zajema uvod v problematiko,
v drugem pa smo opisali informacijski sistem Pantheon in funkcionalnosti, na katere se v
svojih prilagoditvah navezujemo.
V tretjem poglavju smo predstavili proizvodnjo v sistemu Pantheon, prilagojeno za naš
konkreten primer ter pojasnili razloge za implementacijo in izdelavo prilagoditev.
Četrto poglavje zajema opis razvojnih orodij in tehnologije, uporabljene v izdelanih
prilagoditvah in dodatnih rešitvah, peto poglavje pa analizo in primerjavo različnih tipov
prilagoditev.
V šestem poglavju smo se lotili opisa izdelanih prilagoditev in predstavili zunanjo rešitev, ki
smo jo razvili, v zadnjem poglavju pa podali nekaj zaključnih misli.
Podjetij, za katere je rešitev izdelana, nismo opisovali namenoma, saj je sistem Pantheon
splošna rešitev, ki je namenjena širokemu spektru podjetij. Na enak način smo se namreč
lotili tudi svojih prilagoditev, in sicer so prilagoditve narejene tako, da se lahko uporabijo v
različnih podjetjih, ki želijo uvesti opisan tip nizkoserijske proizvodnje. Prav tako nismo šli v
preveč podroben prikaz določenih procesov, saj so nekateri procesi lastni tem podjetjem in
so kot taki njihova konkurenčna prednost.
3
2 INFORMACIJSKI SISTEM PANTHEON
Informacijski sistem Pantheon je produkt slovenskega podjetja Datalab Tehnologije d.d..
Gre za sistem ERP, ki temelji na podatkovni bazi Microsoft SQL. Produkt je dobavljiv v
različnih izvedenkah, odvisno od tega, kaj potrebujemo. Več o tem je napisanega v
podpoglavju 2.2 (Sistem licenciranja). Ker vse izvedenke slonijo na isti podatkovni bazi, so
tudi preprosto nadgradljive med seboj. Možen je nakup programske rešitve in namestitev
na lastnem strežniku, lahko pa rešitev tudi najamemo in imamo podatkovno bazo na
gostovanju pri proizvajalcu. Pri večjih proizvodnih podjetjih, ki imajo svojo infrastrukturo in
lastne IT oddelke, je ponavadi namestitev izvedena na njihovem strežniku SQL.
Dobra infrastruktura je za sistem Pantheon zelo pomembna, saj gre za večuporabniški
informacijski sistem, ki temelji na eni podatkovni bazi, komunikacija pa poteka preko mreže.
Možni so tudi terminalski dostopi iz podjetja ali iz oddaljenih lokacij. Ker hitrost delovanja
programske rešitve psihološko vpliva tudi na zadovoljstvo uporabnikov, je smiselno
posebno skrb nameniti dobri infrastrukturi. Primer namestitve je razviden iz slike 2.1.
Slika 2.1: Primer namestitve sistema Pantheon [5]
4
2.1 Funkcionalnosti
Informacijski sistem Pantheon vsebuje širok nabor funkcionalnosti [6], in sicer:
- blagajniško poslovanje,
- izdajanje in prejem računov,
- maloprodajni modul,
- obračun DDV,
- naročila kupcev in naročila dobaviteljem,
- vodenje skladišč in zalog,
- elektronsko poslovanje,
- kadrovsko evidenco in obračun plač,
- potne naloge,
- poslovanje s tujino,
- carinska skladišča,
- trošarinska skladišča,
- računovodstvo,
- osnovna sredstva,
- servis,
- modul za proizvodnjo,
- modul poslovne inteligence,
- orodje za pisanje appletov.
To je samo nekaj glavnih modulov. Pantheon je informacijski sistem, ki se nenehno razvija,
tako nove funkcionalnosti in novi moduli izhajajo mesečno z novimi verzijami. Na nove
funkcionalnosti vplivajo tudi uporabniki, saj imajo na voljo vgrajen sistem, kjer lahko
predlagajo nove rešitve oziroma opozorijo na morebitne težave.
Osnovne funkcionalnosti sistema Pantheon so razvidne iz slike 2.2.
5
Slika 2.2: Prikaz osnovnih funkcionalnosti sistema Pantheon [7]
2.2 Sistem licenciranja
Informacijski sistem Pantheon ima več možnosti licenciranj. Nekatere se dopolnjujejo,
nekatere pa izključujejo.
Delijo se na:
- licence, namenjene manjšim podjetjem (Mala podjetja: LX, LT, LT3),
- licence, namenjene srednje-velikim podjetjem (Podjetje: SE, ME),
- licenca, namenjena računovodskim servisom oziroma večjim računovodskim
službam v podjetjih (Računovodstvo: ME),
- licence, namenjene trgovinam in maloprodaji (Maloprodaja: RE, RT, RA, RC, RF)1,
- licence, namenjene proizvodnim podjetjem (Proizvodnja: MF, MT),
- licence, namenjene javni upravi (Javna uprava: GE),
- licence konektor in licence nekaterih Datalabovih specifičnih rešitev (Specifične
rešitve),
1 RA,RC in RF so nove licence, namenjene uporabi na mobilnih blagajnah.
6
- licence za kmetijski program (Kmetijstvo) [6].
LX, LT, RE, SE, GE, ME, MF in FA so samostojne licence, RT in MT pa sta licenci, ki
razširjata oziroma dopolnjujeta in ju ne moremo uporabljati samostojno. Licenco RT lahko
kombiniramo z licencami RE, SE, ME in MF, MT pa z licenco MF. RE lahko kombiniramo z
licenco SE, licenc SE, ME in MF pa medsebojno ni mogoče kombinirati. [6]
2.2.1 Licenca MF
Za nas je zanimiva licenca MF, ki je najbolj obsežna licenca, saj vsebuje prav vse
funkcionalnosti, razen funkcionalnosti FA (kmetijstvo) in GE (javna uprava). Dodatne
funkcionalnosti glede na nižje licence so predvsem:
- Proizvodnja s planiranjem in terminiranjem – »Terminiranje v PANTHEON MF je
podrobna terminska razdelava in usklajevanje rokov izdelave ter obvladovanje
proizvodnih virov. Terminiranje izvajamo iz operativnih proizvodnih načrtov ob
upoštevanju podatkov kosovnic, predvsem iz tehnoloških postopkov izdelave
delovnih operacij.« [8]
- Predkalkulacije, pokalkulacije in analize v proizvodnji – »S predkalkulacijo okvirno
izračunamo ceno izdelkov, ki jih izdelujemo in sestavljamo v proizvodnem procesu,
po podatkih iz osnovnih kosovnic, kjer so določene količine predvidenih
(normativnih) neposrednih potroškov materiala in dela.« [8]
2.2.2 Licenca MT
Licenca MT (angl. Manufacture Terminal) je omejena licenca, ki jo lahko uporabimo le v
kombinaciji z licenco MF. Uporablja se za vodenje proizvodnih celic in tako lahko s
programom v taki proizvodni enoti popolnoma nadomestimo papirno dokumentacijo in
delovne naloge (v nadaljevanju DN), ki se ponavadi uporabljajo za dokumentiranje dela.
Vsebuje naslednje funkcionalnosti:
- »Izdaja materiala, vnos materiala, pregled materialnega dela proizvodne kosovnice
DN, pregled vnešene porabe materiala na DN.« [9]
- »Vnos opravljenega dela, vnos dela, pregled operacij proizvodne kosovnice DN,
pregled vnešenega dela na DN.« [9]
7
- »Vnos opravljenega dela po delavcih, prevzem izdelkov, pregled prevzema na DN.«
[9]
- »Forma za registracijo delavca na posamezno operacijo in avtomatski prenos na
DN.« [9]
2.2.3 Licenca konektor
Licenca konektor je novost, ki se uvaja v sistem. Do zdaj se je lahko zunanje rešitve brez
omejitev povezovalo s sistemom Pantheon, kar je prinašalo tudi določene slabe prakse. Z
uvedbo licenc konektor se bo takšno povezovanje in uporaba poslovne logike omejilo zgolj
na licenčne produkte. Gre namreč za to, da lahko naredimo zunanje rešitve, v njih pa
uporabimo že pripravljeno programsko logiko v obliki procedur in funkcij. S tem se bo
zagotovil tudi določen nivo nadzora nad zunanjimi rešitvami in dvig kvalitete le-teh.2 Slika
2.3 prikazuje uporabo licence konektor za različne tipe zunanjih rešitev, kot so spletne
trgovine, skladiščne aplikacije, mobilne aplikacije, in podobno.
Slika 2.3: Prikaz uporabe licence konektor [10]
2 Gre za novost, ki še ni v splošni uporabi, zato podrobnosti implementacije in pravila še niso znana.
8
3 PROIZVODNJA V INFORMACIJSKEM SISTEMU
PANTHEON
Programska rešitev Pantheon vsebuje več različnih modulov, ki so med seboj tesno
povezani. Osredotočili se bomo predvsem na module, ki so najbolj povezani s proizvodnjo,
in predstavili, kako smo jih vpeljali.
Osnovi, iz katerih izhajamo, sta šifrant identov in subjektov. Ta šifranta sta osnovi
informacijskega sistema, saj sta na nek način povezana s prav vsako entiteto v sistemu.
Šifrant subjektov tako zajema pojme, kot so kupec, dobavitelj, skladišče, banka, ustanova,
delavec, oddelek in občina, šifrant identov pa pojme, kot so izdelek, polizdelek, material,
storitev, blagovni paket, sestavljena storitev, in tako dalje.
Proces pri nizkoserijski naročniški proizvodnji je ponavadi postavljen tako, da komercialisti
vnašajo naročila kupcev, ki so predpogoj za delovne naloge. Za posamezne izdelke, ki jih
kupci naročajo, imamo definirane sestavnice oziroma kot so poimenovane v sistemu
Pantheon, kosovnice. Modul planiranja operira z naročili, delovnimi nalogi in s kosovnicami,
na podlagi katerih dobi potrebne informacije in na njihovi osnovi zgradi plan.
Plan je v informacijskem sistemu zelo širok pojem, saj lahko izdelamo letni plan, plan za
potrebe materiala, strateški plan, in podobno. Sledi modul proizvodnje, v katerem dejansko
obdelujemo planirane delovne naloge, na podlagi katerih nato poročamo o narejenih
izdelkih, porabljenem materialu ter izvedenih operacijah. Prav tako sporočamo tudi
informacije o stranskih produktih, kot je izmet, podatke o zastojih, in podobno.
3.1 Razlogi za implementacijo proizvodnega procesa
Podjetja želijo z informatizacijo svojih proizvodenj izboljšati ter optimizirati procese, ki se v
njih odvijajo. V konkretnem primeru ima podjetje proizvodnjo razdeljeno na več delov.
Pretežni del predstavlja proizvodni del, ki ga bomo v nadaljevanju imenovali RM (angl.
Rotational molding), kjer se z uporabo strojev, ki delujejo na podlagi težnosti3, formirajo
3 Sam proces za nas niti ni tako pomemben, gre pa za stroje, na katere se namestijo orodja (modli), kamor se nasuje granulat. Orodja se premaknejo v peč, ki je segreta na določeno temperaturo, nato pa se s procesom kontroliranega vrtenja (težnost) formirajo votli plastični izdelki.
9
izdelki, temu sledi montažni del, kjer tako izdelane izdelke sestavljajo, dodatno obdelajo in
izvedejo še druge procese, kot so končna kontrola, pakiranje, skladiščenje in odprema.
Osnovni procesi podjetja so razvidni iz slike 3.1.
Slika 3.1: Procesi v podjetju
Podjetje ima še nekaj manjših proizvodnih enot, kot so montaža na terenu, izdelava orodij,
mlin, ki pa jih dodatno ne bomo predstavljali, saj so implementirane enako kot montažni del
proizvodnje, le da imajo definirane svoje vrste oziroma tipe delovnih nalogov. Zastavili smo
si naslednje glavne cilje:
- zagotoviti točnejše predvidene roke izdelave izdelkov, kar je pomemben podatek za
komercialiste in kupce (slika 3.2),
- urediti odpiranje delovnih nalogov in združevanje delovnih nalogov z namenom, da
dobimo večje serije za proizvajanje, posledično pa s tem porabimo manj časa pri
montaži in demontaži strojev ter tako izboljšamo učinkovitost,
- zagotoviti beleženje zastojev v realnem času, na podlagi katerih bomo analizirali,
zakaj prihaja do zastojev in jih odpravili ter s tem dvignili učinkovitost.
10
Hkrati pa smo si zastavili številne stranske cilje, kot so:
- izboljšati kakovost izdelkov z boljšim nadzorom kakovosti in osebno odgovornostjo
delavca za dober izdelek, s čimer bomo odpravili napake, ki se zgodijo zaradi
malomarnosti,
- zagotoviti sledljivost izdelkov do posameznega porabljenega materiala, stroja,
orodja in nenazadnje delavca (ali ekipe delavcev), ki so delali na izdelku,
- zagotoviti sledenje in štetje ciklov posameznega resursa v proizvodni hali ter na ta
podatek vezati vzdrževanje strojev (glede na predpisano/nastavljeno periodiko
stroja),
- zagotoviti zadnji načrt izdelka delavcu na stroju in s tem zmanjšati napake, ki se
zgodijo zaradi napačnih načrtov,
- zagotoviti pravilne podatke za obračun plač (plačilo po produktivnosti posameznega
delavca oziroma ekipe delavcev),
- zagotoviti skladnost z mednarodno uveljavljenimi standardi ISO ter
- brezpapirna proizvodnja.
Večina zahtev je vezana na osnovni del proizvodnje, zagotoviti pa je bilo treba tudi podporo
za ostale oddelke v podjetju.
Slika 3.2: Časi izdelave
11
3.2 Opis informacijske podpore procesu proizvodnje
V nadaljevanju bomo opisali naslednje module: šifrant identov, osnovne kosovnice, naročila
kupcev in proizvodnja. Vsi našteti moduli so namreč tesno povezani s procesom
proizvodnje.
3.2.1 Šifrant identov
Blago, storitve, material, izdelki, paketi in podobni pojmi se v sistemu Pantheon imenujejo
identi. V ozadju na nivoju SQL so vsi zapisani v enaki tabeli, ločijo pa se po tipih oziroma
po vrsti materialnega sredstva. Za nas so zanimivi predvsem izdelki, polizdelki in material,
prav tako pa tudi storitve, saj s storitvami beležimo, koliko dela je bilo vloženega v
proizvodnjo, uporabimo pa jih tudi za porabo elektrike, plina in podobno.
Šifra identa je 16-mestna črkovno-številčna, vsak ident pa vsebuje še številčni ID. Med
implementacijo smo se odločili, da bomo uporabili t. i. polgovoreče šifre. Tako je že iz same
šifre razvidno, h kateri vrsti materialnega sredstva sodi.
Primer polgovoreče šifre:
5000000250000001
4000004680000017
30I0005120000001
Prvi trije znaki šifre (označeno z modro) pomenijo vrsto materialnega sredstva, pri tem 500
pomeni, da gre za material, 400, da gre za polizdelek in 30I, da gre za izdelek iz
industrijskega programa. Vrst materialnih sredstev je več, tako imamo na primer vrste
materialnega sredstva 30Z, 30M in tako naprej, pomenijo pa različne programe izdelkov.
Naslednjih šest znakov (označeno z zeleno) pomeni zaporedno številko subjekta, pri
materialu je to dobavitelj, pri izdelku pa kupec (če gre za splošen izdelek, ima ta del šifre
šest ničel).
Zadnjih sedem znakov (označeno s črno) pomeni zaporedno številko identa.
12
3.2.2 Kosovnice
V programu obstajajo trije različni pojmi kosovnic:
- Komercialne kosovnice – so namenjene komercialistom za hitri pregled šifrantov
identov in so v osnovi preprosta receptura, skozi katero komercialist ali kakšen drugi
tip uporabnika lahko na hitro pogleda, iz kakšnih materialov (in storitev) je določen
izdelek sestavljen.
- Razširjene oziroma osnovne kosovnice – so namenjene proizvodnji in vsebujejo vse
podatke, ki so potrebni za učinkovito planiranje proizvodnje. Vezane so na
komercialne kosovnice, vendar pa komercialne kosovnice precej razširijo, saj
uvedejo pojem operacije. S parametri posamezne operacije, predvsem časovnimi
(izdelovalni čas, pripravljalno-zaključni čas) določimo tudi dejanski čas izdelave
izdelka.
- Planske in proizvodne kosovnice – so kopije razširjenih kosovnic, ki se pri kreiranju
planov ali delovnih nalogov skopirajo iz osnovne kosovnice. Tako je proizvodna
kosovnica tista verzija razširjene kosovnice, ki je obstajala v trenutku kreiranja
delovnega naloga. V našem konkretnem primeru to niti ni tako pomembno, saj se
kosovnice ne spreminjajo tako zelo pogosto. Ko pa se to zgodi, pa se spremenijo
tudi na že razpisanih delovnih nalogih oziroma planih.
Osnovne kosovnice
Osnovne kosovnice imajo drevesno strukturo, tako da je že iz samega drevesa kosovnice
razvidno, kako je posamezni izdelek zgrajen.
Primer je viden na sliki 3.3.
13
Slika 3.3: Primer strukture kosovnice [11]
Osnovne kosovnice imajo še nekaj dodatnih orodij za pomoč pri urejanju podatkov.
Omogočeno je na primer masovno brisanje kosovnic. Brisanje vsakega zapisa posebej bi
nam namreč v velikem sistemu vzelo preveč časa, zato imamo na voljo namensko orodje,
kjer nastavimo filtre in izvedemo operacijo.
Še bolj uporabno orodje je kopiranje kosovnic. V praksi se namreč pojavi veliko variacij zelo
podobnih izdelkov, ki se razlikujejo samo v določenih elementih. Da si olajšamo delo, lahko
kosovnice kopiramo in spremenimo samo relevantne dele. Modul je uporaben tudi pri
kopiranju kosovnic med različnimi tipi, na primer iz osnovne kosovnice v komercialno.
Omogočena je tudi uporaba fantomskih kosovnic. Gre za navidezne sestave, s katerimi si
lahko poenostavimo zahtevnejše strukture kosovnic, tako da za skupine materialov, ki se
velikokrat ponovijo, ustvarimo fantomski polizdelek, ki ga nato vgradimo v kosovnice.
Zelo uporabno orodje je tudi spreminjanje vgrajencev. Večkrat se namreč zgodi, da se
kakšen material ali polizdelek zamenja na velikem številu izdelkov, v katerih nastopa kot
vgrajeni del. S tem orodjem si lahko pomagamo in masovno spremenimo kosovnice.
Četrto orodje se imenuje preverjanje strukture kosovnice. Z orodjem si lahko pomagamo in
preverjamo različne parametre kosovnic na večjem zbiru (filtru).
14
3.2.3 Naročila kupcev
V tem modulu spremljamo naročila kupcev. Ker gre v našem primeru večinoma za
naročniško proizvodnjo, smo nastavili dokumente naročil na več različnih tipov (vrst
dokumentov), ki smo jim nastavili različne tipe statusov. Tip statusa P (potrjeno naročilo)
pomeni, da lahko na podlagi naročila formiramo delovni nalog. V naročilo se vpisujejo
klasični podatki za naročila, za nas so pomembni predvsem ident oziroma šifra izdelka,
naročena količina ter želen rok dobave, ki je pri vnosu vnesen, pri planiranju pa se povratno
korigira s predvidenim rokom dobave. Na ta način komercialist dobi informacijo, kdaj bodo
izdelki dobavljivi in lahko povratno informacijo sporoči naročniku.
Modul vsebuje tudi funkcionalnost, imenovano Prenos v DN. Funkcionalnost je namenjena
sumarnemu prenašanju naročil v delovne naloge. Določimo lahko, ali naj se kosovnica
delovnega naloga kreira iz osnovnih kosovnic ali na podlagi kosovnic naročil, katere vrste
naročil upoštevamo, katere statuse naročil, katere vrste delovnih nalogov, datumski kriteriji
in drugo. Zaradi nekoliko posebnega načina razpisovanja naročil pri naročniku smo se
dogovorili, da delovne naloge kreirajo komercialisti, planer pa jih združuje oziroma
terminira, nadalje pa še mikroterminira v dodatnem namenskem modulu. Namen
terminiranja je pridobitev podatka o rokih dobave za posamezne izdelke.
Razpisani delovni nalogi so tudi osnova za naročila materiala dobaviteljem, kar dela
nabavna služba, ki deluje neodvisno od planske službe. Zadevo smo nabavni službi nadvse
poenostavili, tako imajo kontrolne izpise, s katerimi lahko pogledajo, kateri material je na
zalogi, koliko tega materiala je na delovnih nalogih ter koliko je že naročenega pri
dobaviteljih. Dodatno lahko vidijo, kdaj bo določenega materiala zmanjkalo, podatek pa je
prikazan tako, da vidijo, koliko materiala potrebujejo za en mesec, koliko za tri mesece in
koliko za šest mesecev. Prav tako imajo točno informacijo, kateri dan bi lahko zmanjkalo
posameznega materiala, kakšni so dobavni roki pri primarnem dobavitelju ter kakšna je
minimalna želena zaloga. Rešitev jih prav tako opozarja na manko materiala.
3.2.4 Proizvodnja
Proizvodnja se v sistemu Pantheon deli na enostavno in zahtevno. Enostavna proizvodnja
je zajeta v verziji SE in deluje na podlagi komercialnih kosovnic brez operacij. Proizvodnja
MF pa je bolj obsežna, saj je dejansko sistem za planiranje materialnih potreb (v
15
nadaljevanju MRP – Material Resource Planning), ki obsega tako razširjene kosovnice kot
tudi delovne naloge, plane in na koncu analize. Modul je izredno prilagodljiv, saj je možno
uporabiti različne pristope pri kreiranju kosovnic, različne pristope pri planiranju
(velikoserijsko, naročniško, procesno), združevanje delovnih nalogov, planov, in podobno.
Tudi tu smo izhajali iz dejstva, da gre v našem primeru večinoma za naročniško proizvodnjo,
imeli pa smo precej veliko težavo s tem, da dejanskih potrebnih časov nismo poznali, ampak
zgolj približne, kar je velika težava za učinkovito nastavitev sistema MRP. Odločili smo se,
da bomo zamike planiranih delovnih časov delali na podlagi mikroterminiranja, kjer bomo
uporabili podatke o številu ciklov na izdelek na izmeno, dodatno pa bomo zamike planiranih
delovnih časov korigirali s pomočjo aplikacije na stroju, kjer bomo upoštevali tudi vse
zastoje. Izdelavni časi so razvidni iz slike 3.4.
Slika 3.4: Primer trajanja enega cikla na štirih resursih
S tem dobimo dejanski povprečni čas izdelave dobrega izdelka, kar je pomemben podatek
za nadaljnja planiranja. Ker na aplikaciji beležimo tudi čas zastojev in izmet, lahko na
podlagi analiz dobimo bolj točne dejanske potrebne čase in jih povratno polnimo v
16
nastavitve aplikacije. S tem zagotovimo točnejše predvidene roke izdelave izdelkov, kar je
eden izmed glavnih ciljev pri uvedbi sistema.
Zadeve ni mogoče popolnoma avtomatizirati, saj na izdelavne čase vplivajo tudi drugi
faktorji, kot sta faktor izbire stroja in faktor letnega časa (poleti se izdelki počasneje hladijo).
Dogovorili smo se, da bomo korigiranje dejanskih potrebnih časov prepustili planski službi
in jim vgradili funkcionalnost za povečanje oziroma zmanjšanje faktorja.
Ker smo uporabili večino originalnih funkcionalnosti, hkrati pa tudi tam, kjer uporabimo
dodatno razvito funkcionalnost, polnimo originalne tabele sistema Pantheon (na primer,
poročanje izdelkov, roki izdelave, in podobno), lahko v celoti uporabimo originalne analize
za materialne potrebe, stanje delovnih nalogov po prevzemih, pregled zaprtih delovnih
nalogov, nedovršeno proizvodnjo, in drugo. Dodatno smo pri analizah proizvodnje naredili
nekaj izpisov, ki prikažejo predvsem dodatne podatke, ki smo jih uvedli. To so število ciklov
na resurs, kar je pomemben podatek pri vzdrževanju strojev ter podatki, kot so delavci, ki
so delali na posameznih delovnih nalogih.
17
4 UPORABLJENA ORODJA IN TEHNOLOGIJE
V tem poglavju bomo na kratko opisali razvojna orodja in okolja, ki smo jih uporabili pri
razvoju dodatnih funkcionalnosti.
4.1 Razvojno orodje Ares
Razvojno orodje Ares je podjetje Datalab razvilo kot samostojni modul za pisanje
prilagoditev v okviru sistema Pantheon. Uporablja se za programiranje najrazličnejših
dodatkov v obliki čarovnikov, integracij ali samostojnih programov, vendar izključno znotraj
sistema. Programski jezik, v katerem se kodira, je Delphi/Pascal. Slika 4.1 prikazuje
obstoječe funkcionalnosti in možnosti dodatnih rešitev.
Slika 4.1: Vgrajene funkcionalnosti in dodatne rešitve [7]
Orodje Ares vsebuje tudi različne možnosti uporabe skriptnih jezikov VB Script, JavaScript,
prav tako pa možnost korakov SQL, v katerih lahko pišemo kodo TSQL. Ker je modul razvilo
podjetje Datalab za svoj program, so sintakso še nekoliko razširili, tako da lahko
neposredno preko Pascal kode posegamo v kodo TSQL z različnimi rezerviranimi znaki. S
tem je programiranje Appletov v okolju Ares še hitrejše. Slika 4.2 prikazuje primer okolja
Ares.
18
Slika 4.2: Okolje Ares
Appleti ali programčki, napisani z razvojnim orodjem Ares, se s kratico imenujejo DPA
(Datalab Pantheon Applet). Ker obstajajo tudi sistemski DPA, je pravilo, da šifriramo svoje
DPA s črkami (začeti se morajo z znakom A-Z), originalni DPA pa so šifrirani s številkami
(začnejo se z znakom 0-9).4
4.2 Orodje FastReport
Orodje FastReport se uporablja za kreiranje izpisov in poročil v samem sistemu Pantheon.
Gre za kupljeno komponento, integrirano v informacijski sistem (slika 4.3). Razvijalec je
mednarodno podjetje Fast Reports s sedežem v ZDA, sam produkt pa je lokaliziran za več
kot štirideset jezikov. [12]
Podobno kot pri modulu Ares, je tudi tu pravilo, da so sistemski izpisi šifrirani s številkami
(pravilo je, da se začnejo z znakom od 0-9), lastne rešitve pa šifriramo s črkami. 5
4 Šifra je 7-mestna. Za ta projekt smo šifrirali vse DPA s šiframi RP00001, RP00002 ... 5 Šifra je 3-mestna. Za ta projekt smo šifrirali vsa poročila s šiframi R01, R02 ...
19
Slika 4.3: Okolje Fast Report, integrirano v sistemu Pantheon
Gre za zmogljivo objektno orodje, s katerim lahko oblikujemo napredne izpise oziroma
analize. V ozadju je tudi PascalScript, s katerim lahko izpis tudi sprogramiramo. Uporabimo
lahko tudi ostale skriptne jezike, kot so C++Script, BasicScript, JScript. Mogoče je oblikovati
izpise, tabele, grafe, črtne kode (v raznoraznih standardih). Rezultat oblikovanja so
ponavadi izpisi, ki so namenjeni računom, dobavnicam, ponudbam, ter raznorazna poročila
in analize za računovodstvo, upravo, proizvodnjo in ostale oddelke v podjetju. V sistemu
Pantheon je več kot 2.500 standardnih izpisov.
4.3 Okolje Microsoft .NET
Okolja Microsoft .NET ni potrebno posebej predstavljati. Gre za ogrodje za razvoj
programske opreme, ki se izvaja večinoma na okoljih Windows, za aplikacijo na stroju pa
smo ga uporabili zato, ker je v njem zelo enostavno programirati in ker ponuja enostavno
povezovanje s podatkovno bazo Microsoft SQL Server. Gre namreč za združljiva produkta,
ki imata enakega proizvajalca.
20
4.4 Strežnik Microsoft SQL Server
Pantheon uporablja relacijsko podatkovno bazo Microsoft SQL Server. Lahko se uporabi
verzija Express, ki pa vsebuje določene omejitve, ki so razvidne v tabeli 4.1.
Tabela 4.1: Omejitve verzije Express strežnika Microsoft SQL [13]
Omejitve:
Maksimalna prireditev pomnilnika SQL Server Database Enginu6 je 1GB
Maksimalna velikost posamezne relacijske podatkovne baze je 10GB
Nima SQL Profilerja7
Samo en CPU8
Maximalno 16 SQL instanc 9
Nima SQL Agenta10
Uporabili smo verzijo Standard strežnika Microsoft SQL, ki teh omejitev nima. Sistem
Pantheon ima veliko poslovne logike napisane v obliki procedur in funkcij TSQL, ki jih lahko
uporabimo v svojih rešitvah.11 Takih funkcij in procedur je več kot 5.000. Podobno kot pri
orodjih Ares in FastReport, obstajajo tudi pri procedurah in funkcijah posebna pravila
poimenovanja. Procedure, funkcije in ostale uporabniške objekte poimenujemo tako, da
damo pred ime znak »_« ali »u«.12
V tabeli 4.2 je prikazano, kako smo se odločili šifrirati svoje procedure in ostale objekte.
Sistemske objekte, na primer tabele, lahko razširjamo z dodajanjem novih kolon, vendar
tudi tu velja enako pravilo, in sicer, da pred nazivom polja uporabimo znak »_«.
6 SQL Server Database Engine je servis oziroma proces, ki teče na strežniku in skrbi za procese SQL serverja (shranjevanje, procesiranje, varnostna politika). 7 SQL Profiler je orodje, s katerim lahko logiramo vsako poizvedbo, ki se proži na SQL serverju. 8 Velja pred verzijo 2008 R2 Express 9 SQL instanca je kopija procesa sqlservr.exe. Vsaka instanca se obnaša kot samostojen SQL server. Uporabimo, če želimo imeti različne jezikovne nastavitve (angl. collation), primer uporabe bi bil tudi testno okolje. 10 SQL Agent je orodje, s katerim nastavljamo opravila, ki se ob določenem časovnem pogoju samodejno prožijo (kot vhod dobi SQL stavke). 11 Za uporabo procedur je priporočljivo imeti DataLab certifikat. 12 »_« je bila dogovorjena notacija pred verzijo 5.5, zaradi uporabe podatkovne baze Oracle je bilo to potem spremenjeno na »u«. Na Microsoft SQL strežniku še vedno lahko uporabljamo znak »_«, kar smo tudi naredili.
21
Posamezna polja v sistemskih Datalabovih tabelah so poimenovana z naslednjo notacijo:
- polja tipa CHAR se začnejo z nizom ac in
- polja tipa NUMERIC z nizom an.
Podoben sistem velja tudi za ostale podatkovne tipe.
Enakega sistema notacije smo se držali tudi mi, tako smo dodatno kreirana polja v
sistemskih tabelah poimenovali, na primer _acKey, polja v tabelah, ki smo jih kreirali
dodatno, pa na primer anCycleNumber in podobno.
Tabela 4.2: Prikaz poimenovanj naših objektov na podatkovni bazi SQL
Tip objekta Šifranje
TSQL tabela _utRP_naziv_tabele
TSQL procedura _upRP_naziv_procedure
TSQL funkcija _ufnRP_naziv_funkcije
TSQL trigger _utrRP_naziv_triggerja
TSQL index _uiRP_naziv_indexa
TSQL kolona _ime_kolone13
TSQL view _uvRP_naziv_viewa
Standardna verzija vsebuje tudi orodje za časovno avtomatizacijo, ki se imenuje SQL
Agent. Uporablja se za vzdrževalna opravila, tako lahko na primer avtomatiziramo
generiranje rezervnih kopij ali ponovno zgradimo indekse na tabelah in s tem pohitrimo
podatkovno bazo. Mi smo Agenta uporabili za vse našteto, prav tako pa tudi za opravila,
kot sta avtomatsko kreiranje delovnih nalogov za vzdrževanje strojev ter avtomatsko
pošiljanje poročil nabavni službi.
13 Gre za ime kolone na sistemski tabeli.
22
5 ANALIZE PRILAGODITEV V INFORMACIJSKEM
SISTEMU PANTHEON
Sistem Pantheon omogoča ogromno različnih funkcionalnosti in nastavitev, hkrati pa
vsebuje integrirana orodja, kot sta Ares in FastReport. Na ta način lahko funkcionalnosti
spremenimo ali napišemo kar nove. Kot je razvidno iz prejšnjih poglavij, je možnih več
pristopov, ki imajo različne prednosti in slabosti. Pri tem upoštevamo načelo, da so
prilagoditve smiselne le tam, kjer upravičijo vložek v izvedbo prilagoditev. Vsaka
prilagoditev namreč poveča skupne stroške uvedbe informacijskega sistema, hkrati pa
poveča tudi stopnjo obsega sistema, kar pomeni dodatne stroške vzdrževanja. Slika 5.1
prikazuje tako stroškovni vidik kot tudi stopnjo obsega sistema ERP, ki zaradi tovrstnih
prilagoditev naraščata.
Slika 5.1: Prilagoditve rešitve ERP [13] [14]
V tem poglavju bomo analizirali prednosti in slabosti tovrstnih prilagoditev v sistemu
Pantheon.
23
5.1 Analiza integracijske prilagoditve
Integracijske prilagoditve se vršijo skozi razvojno okolje Ares in so dosegljive kot
spremembe obstoječih Pantheon mask, zato jih relativno hitro sprogramiramo, saj se
sklicujemo na že predpripravljeno logiko, ki jo razširjamo tako, da dodajamo nova polja in
razvijamo dodatne funkcionalnosti.
Prednosti:
- uporaba razvojnega okolja Ares,
- ne potrebujemo licence konektor,
- uporabnik sploh ne opazi, da gre za dodelavo, saj lahko spreminjamo originalne
objekte in njihove dogodke,
- uporabimo lahko originalne predpripravljene procedure in funkcije TSQL in tako
kličemo standardne funkcionalnosti,
- z upoštevanjem pravil za programiranje v sistemu Pantheon lahko relativno
enostavno zagotovimo, da nadgradnja informacijskega sistema ne vpliva na naše
rešitve.
Slabosti:
- treba je paziti, da ne prekrijemo kakšnih originalnih polj,
- treba je paziti, da ne izločimo originalnih dogodkov. Če potrebujemo dogodek
kakšne originalne komponente, si moramo shraniti vsebino dogodka in originalno
kodo vsekakor izvesti, da ne porušimo originalnih funkcionalnosti,
- treba je paziti, da ne pokvarimo veljavnih zakonskih predpisov, ki so morebiti
upoštevani v standardnih funkcionalnostih.
5.2 Analiza samostojne prilagoditve
Samostojne dodelave v informacijskem sistemu so podobne integracijskim, razlika je v tem,
da vsebujejo samostojno formo in ponavadi lastno logiko, v obstoječo pa minimalno
posegajo. Največkrat se prožijo iz posebnega menija ali čarovnika14 forme. Za njih
14 Čarovnik je posebna funkcionalnost originalnih Pantheon form, v katere lahko dodajamo svoje napisane programčke DPA. Ti so dosegljivi iz čarovnika posamezne forme.
24
potrebujemo nekoliko več časa, saj moramo obliko maske zgraditi od začetka in tudi kreirati
vse potrebne tabele in ostale objekte na podatkovni bazi.
Prednosti:
- uporaba razvojnega okolja Ares,
- ne potrebujemo licence konektor,
- zelo velika združljivost s sistemom Pantheon, uporabimo lahko večino15 komponent,
ki so uporabljene na originalnih formah, tako uporabnik niti ne opazi, da ne uporablja
standardne funkcionalnosti,
- uporabimo lahko originalne predpripravljene procedure in funkcije za klicanje
standardnih funkcionalnosti,
- z upoštevanjem pravil za programiranje v sistemu Pantheon lahko relativno
enostavno zagotovimo, da nadgradnja informacijskega sistema ne vpliva na naše
rešitve.
Slabosti:
- nekoliko več dela kot z integracijsko prilagoditvijo,
- če spreminjamo originalne tabele, je treba paziti, kaj spreminjamo,
- treba je paziti, da ne pokvarimo veljavnih zakonskih predpisov, ki so morebiti
upoštevani v standardnih funkcionalnostih.
5.3 Analiza zunanje rešitve
Zunanje rešitve so dodelave, ki se prožijo izven sistema Pantheon. Napisane so lahko v
poljubnem jeziku, skupno pa jim je, da uporabljajo podatkovno bazo sistema Pantheon.
Smiselne so za funkcionalnosti, ki so bolj obsežne in so bolj v smislu vzporednega sistema,
ki pa uporablja enako podatkovno bazo in si tako deli podatke s sistemom Pantheon.
Prednosti:
- uporabimo lahko različne tehnologije, tako da nismo omejeni z naborom komponent,
- uporabimo lahko originalne procedure in funkcije na nivoju SQL,
- nadgradnja informacijskega sistema na takšno rešitev nima vpliva.
15 Vse komponente niso registrirane za uporabo v orodju Ares.
25
Slabosti:
- ne moremo uporabiti razvojnega okolja Ares, ampak potrebujemo posebna orodja,
- za uporabo podatkovne baze in metod potrebujemo licence konektor16,
- eventualno lahko pride do težav, če se spremeni struktura podatkovne baze.
5.4 Nadgradnje
Ko imamo poleg osnovnega informacijskega sistema narejene tudi prilagoditve in dodatne
rešitve, je treba nadgradnjam IS nameniti posebno skrb. Zagotoviti moramo, da s svojimi
prilagoditvami ne porušimo integritete podatkovne baze oziroma zaradi slabega poznavanja
sistema pokvarimo delovanje kakšnega pomembnega modula.
Podjetje Datalab svoje podatkovne baze ni zaklenilo, kot je to praksa pri konkurenčnih
ponudnikih, ampak je vpogled v podatkovno strukturo omogočilo svojim strankam z
nakupom licenc. Gre za veliko prednost, saj se s tem zmanjšajo stroški razvoja lastnih
rešitev, saj lahko dodatne rešitve razvijajo lastni programerski resursi podjetja ali pa Datalab
partnerji. Ta velika odprtost informacijskega sistema se pri nadgradnjah lahko izkaže tudi
kot slabost, saj je slabo napisan applet lahko vir težav pri nadgradnjah, s slabo izvedenimi
prilagoditvami pa se lahko pokvari tudi podatkovna referenčna integriteta.
V izogib težavam je Datalab pripravil več rešitev, med drugim ponujajo izobraževanja, kjer
lahko programerji spoznajo specifike izdelave dodatnih rešitev za informacijski sistem.
Predpisali so notacijo za šifriranje dodatnih rešitev in izpisov, omenjeno v poglavjih 4.1 in
4.2, prav tako pa je predpisano tudi poimenovanje objektov SQL, kar smo obravnavali v
poglavju 4.3. Z upoštevanjem teh pravil lahko relativno preprosto dosežemo, da nadgradnja
ne vpliva na naše prilagoditve in dodatne vertikalne rešitve.
Z uvedbo prilagoditev in dodatnih rešitev se povečajo tudi stroški vzdrževanja, saj je
potrebno tudi dodatne rešitve, tako kot osnovni informacijski sistem, nadgrajevati. Če je
vsebina dodatnih rešitev podvržena zakonskim spremembam, se dejavnik stroška
vzdrževanja še poveča. Če ni tako, je večinoma treba le zagotavljati združljivost dodatne
rešitve s sistemom Pantheon.
16 Število licenc je vezano na število hkratnih povezav na podatkovno bazo
26
Združljivost zagotavljamo s testi (najbolje avtomatskimi) v novih verzijah informacijskega
sistema. Ponavadi se za takšne teste ustvari paralelno testno okolje, kjer se tovrstne
prilagoditve testirajo in preverijo pred produkcijsko nadgradnjo sistema.
27
6 PRILAGODITVE IN NADGRADNJE STANDARDNE
REŠITVE
Za veliko večino potreb v podjetju smo uporabili originalne funkcionalnosti sistema
Pantheon brez dodatnih dodelav, saj smo z nastavitvami modulov dosegli zadostno
ujemanje z željami naročnika. Ponekod, kjer z nastavitvami željam naročnika nismo mogli
ugoditi, pa smo predlagali izboljšave v samem procesu proizvodnje podjetja, in so tako v
podjetju procese prilagodili rešitvi. Seveda je bilo to možno izključno tam, kjer se je proces
minimalno spremenil, vseeno pa se je izkazalo, da je takih procesov velika večina.
Nekatere želje, kot so poročanje dela za montažni del proizvodnje, smo dosegli z uvedbo
»proizvodnih otokov«17. V ta namen je podjetje kupilo šest dodatnih licenc MT, od katerih
smo štiri uporabili v montažni proizvodni hali na delovnih postajah. V montažni hali dela
približno 20-30 ljudi v dveh izmenah. Delujejo kot ekipa 2-6 ljudi v štirih skupinah. Delavce
smo v kadrovskem delu rešitve uvrstili v njim lastno skupino Montažni delavci. Tem
delavcem smo nato v modulu kreirali uporabnike in jih naučili uporabljati verzijo MT rešitve.
Glede na naravo dela v montažni hali, se je rešitev izkazala kot zadovoljiva, saj že štiri
delovne postaje popolnoma zadostijo potrebam. V primeru izrednega povečanja dela se ne
poveča število delavcev, ampak se uvede tretja izmena, zato so tudi v tem primeru štiri
delovne postaje dovolj.18 V primeru, da bi se število delavcev na izmeno povečalo, je
rešitev, da se dokupijo licence MT ter delovne postaje in postavijo novi delovni otoki.
Preostali dve licenci smo uporabili za ostale standardne vrste proizvodnje (izdelava orodij,
mlin).
Pri določenih zahtevah naročnik ni želel preveč prilagajati svojega proizvodnega procesa
proizvodnemu modulu rešitve. V teh primerih smo predlagali prilagoditve osnovne rešitve.
Pri prilagoditvah smo se držali principa, da ne podvajamo funkcionalnosti, ki jih informacijski
sistem že vsebuje. Če določena funkcionalnost v sklopu sistema Pantheon že obstaja, smo
17 Proizvodni otok je izraz, s katerim opišemo računalnik v proizvodnji, na katerem teče Pantheon z omejeno licenco MT in je namenjen izključno poročanju opravljenega dela, razknjiževanju porabljenega materiala in naknjiževanju izdelanih izdelkov. Izraz proizvodni otok se je prijel zaradi tega, ker so računalniki razpršeni po proizvodni hali tako, da lahko maksimalno uporabnikov uporablja minimalno računalnikov. 18 Licence niso vezane na število različnih uporabnikov, ampak na število hkratnih uporabnikov.
28
originalno funkcionalnost uporabili tudi v svoji prilagoditvi. S tem mislimo predvsem na
sistemske funkcije in procedure TSQL, ki jih lahko kličemo tudi iz svojih rešitev.
V osnovi lahko narejene prilagoditve razdelimo na tri sklope. V prvi sklop spadajo
integracije, ki minimalno spreminjajo originalno funkcionalnost sistema Pantheon. Tu smo
razvili rešitve, ki razširjajo kosovnice in jih bomo v nadaljevanju tudi podrobneje opisali.
Tovrstne prilagoditve se integrirajo na originalno formo določenega modula. Modul tako
postane starš (angl. parent) za naše objekte (angl. child objects). S takimi tipi prilagoditev
spremenimo ali dodamo posamezne objekte na že obstoječ modul oziroma, natančneje, na
glavno formo modula.
V drugem sklopu so prilagoditve, ki so sicer samostojne, ampak se izvajajo kot dodatni
modul v sistemu Pantheon. Razvili smo rešitev za planiranje urnika delavcev v enem delu
proizvodnje. Ta rešitev je popolnoma samostojna in razen tega, da zajema delavce, ki so
vpisani v kadrovski del programa (zajemamo samo en tip delavcev), drugih povezav nima.
V ta sklop lahko štejemo tudi dodatni planirni modul, s katerim razširjamo planiranje, ki je v
sistemu Pantheon že zajeto.
Planirni modul je specializiran za mikroplaniranje ene same vrste proizvodnje v podjetju, ki
pa je tudi največji del in ima nekoliko več posebnosti. Gre za proces RM, ki se od
montažnega dela proizvodnje precej razlikuje. Posebnost je v tem, da imamo en stroj, ki se
deli na več resursov, kar je odvisno od modela stroja (resurs je del stroja).
Na posameznem resursu pa tako lahko izdelujemo več izdelkov (resurs smatramo kot stroj),
vendar ni nujno, da je možno delati izdelek na posameznem resursu, niti ni nujno možno,
da lahko določene izdelke delamo skupaj v enem ciklu. Dodatna omejitev je še število
modlov za en izdelek. Zaradi tega smo izdelali omenjeni modul, ki nam pomaga
mikroplanirati izdelke na posamezne resurse. Ta modul je torej samostojen, vendar izrazito
povezan z ostalimi deli programa, saj kot vhod prejme delovne naloge in resurse, planer pa
na podlagi možnih resursov iz prilagoditve, s katero smo razširili kosovnice ter na podlagi
skladnosti izdelkov med sabo ter številom modlov, mikroplanira razpored proizvodnje.
Rezultat mikroplaniranja se zapiše v originalni planski modul z uporabo predpripravljenih
sistemskih procedur SQL. Na ta način se doseže popolna združljivost s sistemom
Pantheon.
29
V tretjem sklopu so prilagoditve, ki se samostojno zaganjajo izven sistema Pantheon,
uporabljajo pa enako podatkovno bazo kot Pantheon. Izdelali smo aplikacijo, napisano v
okolju .NET z uporabo programskega jezika C#, ki se izvaja na posamičnem stroju. Ker gre
za zunanjo aplikacijo, je potrebna že omenjena licenca konektor.19 Posebnost te dodelave
je prijavno okno, ki se izvaja s čitalcem črtnih kod20 in enostavnost vmesnika. Vmesnik je
zastavljen tako, da delavec dejansko vidi samo to, kar ima planirano na posameznem
resursu ter poroča, kaj je zaključeno (beleži tudi izmet).
6.1 Integracijske prilagoditve
6.1.1 Šifrant resursov
Šifrant resursov posebnih prilagoditev nima, je pa osnova za dodelave, opisane v
nadaljevanju. Resursi v osnovi vsebujejo seznam vseh strojev in njihovih nastavitev. Ker se
pri vrsti RM proizvodnje pravzaprav ne planira izdelkov na stroj, ampak na del stroja, kar je
vidno na sliki 6.1, smo definirali stroje kot seštevalni tip resursa, nadalje pa smo delili na
število delov stroja, ki smo jih definirali kot delovni tip resursa. Delovne naloge se lahko
mikroplanira samo na delovni tip resursa:
- delovni - na katerih se izvaja delovni proces,
- seštevalni - združuje posamezne delovne resurse v zaokroženo celoto.
19 V času pisanja diplomske naloge preverjanje in uporaba licence konektor v naši aplikaciji še ni implementirana, saj je omenjena licenca pri podjetju Datalab še v procesu uvajanja in končne specifikacije za implementacijo kontrole in uporabe licence konektor še niso izdane. 20 Uporabili smo običajen trgovski čitalec.
30
Slika 6.1: Prikaz stroja za rotacijsko litje s tremi rokami [14]
Podjetje ima veliko število strojev, zato smo stroje oštevilčili z naslednjim zaporedjem:
- RM01_ime_proizvajalca,
- RM02_ime_proizvajalca, in tako dalje.
Ker posamezni stroj vsebuje različno število delovnih resursov, ti pa so lahko različnih tipov,
smo oštevilčili še te. Številčenje je pomembno zaradi prikaza na zunanji aplikaciji in zaradi
lažjega mikroplaniranja v planirnem modulu, delovni resursi si namreč sledijo v točno
določenem zaporedju oziroma fazah, kar bo prikazano v nadaljevanju.
31
Šifrirali smo jih z naslednjim zaporedjem:
- RM01-1R1,
- RM01-2L1,
- RM01-2R2 in tako dalje.
V zgornjem zgledu RM01 pomeni stroj, število za znakom »-« pa zaporedno številko. Znak
L oziroma R pomeni, ali gre za ravno roko ali roko v obliki črke L. Zadnja številka je
zaporedna številka posamezne roke. Najpomembnejša je zaporedna številka, saj si roke
sledijo v tem zaporedju.
Za posamezni stroj (vrsta seštevalni) je potrebno vnesti še:
- datum nakupa,
- čas garancije v mesecih,
- ali gre za aktivni stroj (T - aktiven, F = neaktiven) – neaktivnih strojev namreč ne
prikazujemo v mikroplaniranju, neaktivni so lahko tudi stroji, ki so novi in še niso
aktivirani oziroma so v okvari,
- ime datoteke, ki vsebuje navodila za varno delo (stroji so kupljeni od različnih
proizvajalcev, zato so tudi navodila za varno delo različna),
- periodika servisiranja (pomeni število ciklov, ko je treba izvesti servis stroja, kar je
definirano s strani proizvajalca),
- podatki o izmenah (aktivne izmene, čas od-do ter čas malice) in
- telefonsko številko za alarmni SMS21.
Vse to se uredi v zavihku Dodatni podatki, kar je razvidno na sliki 6.2. Ker dodatnih
parametrov ni veliko, smo jih vpisali kar v originalna polja programa, ki so namenjena
splošni uporabi in se imenujejo poljubna22 polja.
21 Alarmnega SMS-a na koncu nismo implementirali, saj se je funkcionalnost izkazala za nepotrebno. Ideja je bila, da bi v primeru zastoja na stroju delovodja dobil SMS sporočilo na telefon. Nastavitev v programu smo pustili, vendar smo polje označili kot skrito. 22 Poljubna polja so funkcionalnost sistema Pantheon, ki ima na določenih šifrantih že definirana polja, ki jih lahko poljubno uporabimo. Definirana so kot acFieldSA, acFieldSB, in tako naprej za tekstovna polja ter anFieldNA, anFieldNB, in tako naprej za numerična. Obstajajo tudi datumska in boolean poljubna polja. Število poljubnih polj je končno omejeno.
32
Slika 6.2: Dodatna polja v šifrantu resursov
6.1.2 Šifrant Osnovna kosovnica
Na osnovno kosovnico smo integrirali postopek DPA RP00005 - Proizvodnja - Integracija
možnih resursov na kosovnice (slika 6.3).
Slika 6.3: Integracijska dodelava na osnovni kosovnici – možni resursi
V osnovi smo ohranili originalno delovanje kosovnice, dodali pa smo zavihek Možni resursi.
Podatki so shranjeni v ločeni tabeli, ki se veže na šifro kosovnice. V polje Resurs se polnijo
vsi možni resursi, na katerih lahko posamezna šifra nastopa. To velja tako za izdelke kot
za polizdelke. Lahko se napolnijo ročno skozi dodelavo, ali pa se polnijo avtomatsko iz
mikroplaniranja. Možni resursi niso vezani na alternative, saj velja, da imajo tudi alternative
enake možne resurse. Možni resursi so namreč vezani na možnost montaže modle na
posamezno roko stroja, kar pa v primeru alternativne kosovnice (drugi material) prav tako
drži.
Na osnovno kosovnico smo prav tako integrirali postopek DPA RP000007 - Proizvodnja -
Integracija dodatnih podatkov za planiranje na kosovnice. Gre za dodatni zavihek, na
katerega smo dodali dve polji, zasedenost resursa ter runde (slika 6.4).
33
Slika 6.4: Integracijska dodelava na osnovni kosovnici - dodatni podatki za planiranje
V polje zasedenost resursa se vnaša numerični podatek. Podatek je pomemben zaradi
kontrole cikla. Cikel na stroju naj bi v najbolj idealnem primeru imel zasedenost 1.
Možne so različne kombinacije:
1 = 1
1 =1
2+
1
2
1 =1
4+
1
4+
1
2
1 =1
3+
1
3+
1
3
Na primeru slike 6.4 je prikazana polovična (½) zasedenost resursa. Podatek pomeni, da
bo z izdelkom zasedenega pol resursa. V osnovi si želimo imeti zasedenost 1 oziroma 100-
odstotkov, saj to pomeni, da proizvajamo optimalno število izdelkov glede na porabljene
vire (elektriko, plin in delo delavcev). Zasedenost je lahko tudi manjša, vendar se s tem prav
tako zmanjšuje naša učinkovitost.
V praksi se zgodi, da je zasedenost tudi več kot 1, saj lahko delavci orodje pritrdijo tako, da
še dodajo kakšno majhno orodje. Runde so približni numerični podatek, ki pomeni, koliko
izdelkov (dobrih in slabih) se lahko izdela v eni izmeni (8 ur), če ni zastojev. Podatek ni čisto
točen, saj je pomemben faktor tudi hlajenje, ki variira glede na zunanje dejavnike
(temperatura okolice). Izkazalo se je, da bi bilo pri mikroplaniranju smotrno upoštevati faktor
letnega časa, saj je ta razlika izrazita predvsem pri primerjavi pozimi/poleti.23
23 V času pisanja diplomske naloge faktor letnega časa pri mikroplaniranju še ni bil implementiran.
34
6.2 Samostojne prilagoditve
6.2.1 Planiranje delavcev
Planiranje delavcev se je najprej pojavilo kot stranski projekt glavnega projekta, saj v osnovi
ni bil specificiran. Gre za razpored dela za delavce v proizvodnji RM, kar se je do zdaj delalo
v programu Excel. Ker smo za samo prijavo na stroje v kadrovskem modulu delavce uvrstili
v skupino proizvodnja RM, smo dobili seznam teh delavcev in pojavila se je ideja, da bi
lahko prikaz razporeda dela naredili tudi računalniško in bi tako lahko bil dosegljiv na
intranet strani podjetja.24 Kot vhodni podatek smo tako vzeli delavce, ki so uvrščeni v prej
omenjeno skupino, prav tako pa smo uporabili podatke iz šifranta resursov (seštevalne
elemente). Ker je applet precej samostojen, saj se njegovi rezultati nadalje v procesu nikjer
ne uporabijo, smo za dostop do njega naredili poseben meni, razviden iz slike 6.5.
Slika 6.5: Dostop do programa "Razpored delavcev"
Slika 6.6 prikazuje masko modula.
24 V času pisanja diplomske naloge še ni bilo prikaza na intranet strani
35
Slika 6.6: Maska za vnos v program "Razpored delavcev" - neizpolnjen
Ker se razpored delavcev planira tedensko, smo za primarno šifro izbrali teden v obliki
YYYY-MM, na primer 201309, kar pomeni leto 2013, 9. teden. Datum od/do avtomatsko
polnimo in služi kot dodatna informacija planerju.
Za kontrolo zapisov, pomik nazaj, naprej, nov zapis, smo uporabili komponento TNavigator,
ki je tudi sistemsko uporabljena v originalnih modulih sistema Pantheon. Uporabniki
poznajo delovanje komponente iz standardnih modulov in zato vedo, kaj posamezni gumb
na komponenti pomeni, saj je uporaba identična po vseh modulih. Podobno načelo smo
upoštevali pri vseh prilagoditvah, saj je za uporabnike preprostejše osvojiti uporabo rešitve,
če so si moduli med sabo podobni.
Izdelali smo funkcionalnost, ki naredi nov zapis za nov, naslednji teden, kjer so privzeto
prikazani vsi aktivni resursi. Bolj zanimiva je funkcionalnost, ki kreira nov zapis, podobno
kot prejšnja funkcionalnost, s tem, da rešitev v tem primeru prepiše podatke iz prejšnjega
36
tedna, tako da zamakne izmene. To pomeni, da delavci, ki so bili prvi teden v jutranji izmeni,
so v drugem tednu v popoldanski, popoldanski so v nočni, in nočni v jutranji. Planer lahko
podatke še dodatno spremeni. Podvajanje je namenjeno predvsem čim hitrejšemu vnosu
razporeda če se leta dosti ne spreminja, nima planer z njim skorajda nobenega dela.
V seznamu so prikazani seštevalni resursi (šifra in naziv) ter število delavcev (podatek
izhaja iz šifranta resursov), ki so predvideni za delo na stroju. S tem dobi planer tudi vizualno
informacijo, koliko delavcev je predvidenih za posamezni stroj. Sledi prikaz dnevov v tednu,
ki so razdeljeni v tri izmene (dopoldanska, popoldanska in nočna). Prikaz vnosa delavcev
je viden na sliki 6.7.
Slika 6.7: Vnos delavcev v program "Razpored delavcev"
V zbiru so možni vsi delavci, ki imajo nastavljene pravice v postopku za dodeljevanje
osebnih identifikacijskih številk (v nadaljevanju kod PIN). Moduli so na tak način med sabo
povezani. Zaradi lažjega planiranja smo izdelali funkcionalnost na način, da planer planira
privzeto za vse dni v tednu, ima pa tudi možnost, da planira samo za izbran dan. Ta
funkcionalnost je namenjena čim hitrejšemu vnosu, prav tako pa smo dodali še možnost
vpisa opombe, ki je vidna v izbranem tednu.
Ker planer občasno potrebuje natisnjen plan, smo dodali možnost izpisa, ki je oblikovan v
orodju FastReport. Delavci so prikazani za vse dni v tednu. Če pride do spremembe (da
delavec ne dela vse dni), se poleg delavca izpiše, katere dni dela. Primer je prikazan na
37
sliki 6.8. Desno na izpisu je prikazana opomba, prikazano pa je tudi, za kateri teden gre
(številka tedna).
Slika 6.8: Izpis iz programa "Razpored delavcev"
6.2.2 Dodatni planirni modul za mikroplaniranje
Planiranje potreb materiala in posledično naročil dobaviteljem se izvede preko originalnih
funkcionalnosti v sistemu Pantheon. Za samo mikroplaniranje posameznih delovnih
nalogov na posamezne stroje in posledično resurse pa smo zaradi specifičnih zahtev
napisali dodatni planirani modul, ki je dosegljiv v posebnem meniju sistema Pantheon (slika
6.5).
Modul je razdeljen na tri25 zavihke (slika 6.9).
25 V osnovi je bil modul planiran za pet zavihkov, kjer bi drugi zavihek bil Avtomatsko planiranje, kar pa zaradi omejitev podatkov o številu modlov in samih dimenzijah modlov še ni možno. Prav tako ni implementirano Vizualno planiranje zaradi omejene izbire grafičnih komponent.
38
Slika 6.9: Planirni modul za mikroplaniranje
V prvem zavihku ima planer pregled odprtih delovnih nalogov. Filtracija se lahko izvede
glede na rok dobave ter glede na status oziroma vrsto delovnega naloga. Prav tako se lahko
v tem zavihku napačno odprti delovni nalogi ročno zaprejo, tako da jim planer spremeni
status.
V naslednjem zavihku, ki smo ga poimenovali Ročno planiranje, pa lahko planer na
posamezni resurs (del) določenega stroja planira cikle, kar je vidno na sliki 6.10.
Slika 6.10: Planirni modul - ročno planiranje
39
Pregled je zastavljen tako, da so podatki čimbolj pregledni, delo pa čim lažje. Uporabniški
vmesnik smo razdelili na dva dela; na levi strani prikazujemo seznam odprtih delovnih
nalogov (za vsak kos en zapis ali sumarno), na desni pa planirane cikle. Planer lahko izbere
različne možnosti pogledov, tako lahko na primer izbere, za kateri resurs bo planiral, vidi
statuse za posamezni cikel, planiran predvideni čas, morebitne spremembe zasedenosti
cikla ter kontrolo rund. Prav tako vidi prikaz delovnih nalogov na izbranem ciklu. Sam
delovni nalog zanj niti ni tako zelo pomemben, saj se osredotočamo na izdelke. Podjetju je
namreč v interesu planirati čim daljši niz ciklov na posamezni resurs, saj to pomeni, da
delamo večjo serijo, s tem pa zmanjšamo pripravljalno-zaključne čase, saj odpade
premontaža orodij.
Upoštevali smo tudi nastavitve iz ostalih integracijskih dodelav, tako na primer v spustnem
meniju resurs/stroj planer izbere, za kateri stroj bo planiral, seznam pa je sortiran po
abecedi in, kot smo razložili v poglavju šifrant resursov, s točno tem namenom, da si stroji
in deli stroja sledijo v zaporedju, ki smo ga sami določili. Logika je zastavljena tako, da če
je razpisanih deset delovnih nalogov po trideset izdelkov, pri tem pa imajo vsi podoben
željen rok dobave, rešitev ponudi tristo ciklov za ta ident, planer pa lahko ponujeno vrednost
korigira. Treba je še poudariti, da se bo število ciklov povečalo še za število slabih izdelkov,
vendar se to zgodi v kasnejši fazi pri sami proizvodnji.
Funkcionalnost planiranja osnovnega cikla smo implementirali s premikanjem levih
vrednosti na desno stran, in obratno. Na ta način lahko planer hitro splanira osnovni cikel.
Ker pa bi bilo za naslednje cikle, ki so za serijo enaki, tako planiranje nesmiselno, smo
implementirali funkcionalnost podvajanja ciklov, da lahko planer vnese vrednost ciklov za
podvajanje in na ta način splanira celotno serijo. Kot smo omenili že prej, delovni nalog za
planerja ni tako pomemben, tako je lahko serija sestavljena iz različnih delovnih nalogov.
Implementirali smo različna pomagala, ki planerju olajšajo manipulacijo s cikli in resursi,
prav tako pa smo v uporabniški vmesnik vgradili različne dinamične labele, ki planerju s
prikazom dodatnih informacij o resursih, ciklih in identih pomagajo sprejemati pravilne
odločitve. Pomembna funkcionalnost je tudi vrivanje in preštevilčevanje ciklov, pri čemer
dodatno beležimo vrinjene cikle, saj je podatek pomemben za kasnejše analize. Vrinjenih
ciklov želimo čim manj, saj v večini primerov negativno vplivajo na serijo. Implementirali
smo tudi kontrolo na maksimalno število podvojitev (slika 6.11), s čimer planerja opozorimo,
40
da ni možno narediti želenega števila ciklov, saj ni razpisanih zadosti delovnih nalogov.
Slika 6.11: Kontrola podvajanje ciklov
Tudi planer ima možnost kreiranja delovnih nalogov, toda ne skozi naročila, ampak ročno.
V tem primeru planer uporabi originalno funkcionalnost sistema Pantheon. Omenjeno
funkcionalnost planer uporabi v primerih, ko se na podlagi izkušenj odloči, da bo naredil
večje število izdelkov, kot je razpisanih delovnih nalogov, saj je za pričakovati, da bodo
izdelki v bližnji prihodnosti naročeni, nesmiselno pa bi bilo delati zelo nizko serijo. V času
planiranja ciklov so le-ti v posebnem statusu, na ta način zagotavljamo, da delavci na stroju
teh ciklov ne vidijo. Ko planer zaključi z delom, mora te cikle potrditi in s tem cikli postanejo
vidni na ustreznem resursu.
Na sliki 6.12 je prikazan primer pomagala, s katerimi planer dobi informacijo, na katere
resurse lahko določeni DN razpiše.
Slika 6.12: Možni resursi pri planiranju
Zaradi nepopolnih nastavitev bi bilo tako rigorozno planiranje oteženo, zato smo pri vseh
tovrstnih funkcionalnostih upoštevali načelo, da modul planerja ne blokira, ampak ga
opozarja, kot je vidno na sliki 6.13. V tem primeru lahko planer določi resurs kot možen tudi
identu, ki resursa še nima definiranega. S takim pristopom hkrati tudi urejamo in
dopolnjujemo nastavitve in osnovne šifrante. S tem dosegamo, da so podatki v šifrantih
čedalje popolnejši.
41
Slika 6.13: Vnos resursa pri planiranju
Pri levi in desni tabeli je prikazan tudi podatek o rundah in zasedenosti cikla iz šifranta (slika
6.14). Podatek je prikazan le kot informacija planerju, da lahko vedno vidi dodatne podatke
o identih.
Slika 6.14: Prikaz rund in zasedenosti cikla
Funkcionalnost kontrola na zasedenost cikla (želena je 100-odstotna zasedenost) sporoči
planerju, koliko je obremenil posamezni del stroja. Tudi podatek o časih mora biti usklajen.
Na ta dva podatka sistem planerja opozori, vendar ga ne onemogoči. Planer se še vedno
lahko odloči in prekomerno obremeni zasedenost oziroma splanira manjšo zasedenost.
Vizualno se planerju prikaže tudi sprememba cikla. To pomeni, da če imamo na ciklih 1,2,3
planirana identa A in B, na ciklih 4, 5 identa B in C ter na ciklih 6, 7 ponovno identa A in B,
bo spremembo prikazalo na ciklih 4 in 6 (besedilo se obarva z zeleno – slika 6.15). Enak
podatek je dalje razviden na stroju in služi kot opozorilo delavcem, da bo potrebna
premontaža orodja ali kakšen drug poseg.
Slika 6.15: Kontrole pri mikroplaniranju
42
Prikaz ciklov lahko filtriramo glede na status, kar je vidno na sliki 6.16. S tem smo dosegli,
da se lahko planer osredotoči na relevantne cikle, lahko pa pogleda tudi, kaj je že v izdelavi
ter kaj je že bilo narejenega.
Slika 6.16: Filtriranje ciklov
Na maski je prikazan tudi podatek o tehnološkem postopku (iz šifranta materialnih sredstev)
in opomba iz delovnega naloga. Podatka sta informativne narave.
Planer lahko delavcem za posamezni planiran cikel napiše tudi dodatno »planersko«
opombo, ki jo potem delavci vidijo na stroju. Tovrstna opomba je razvidna iz slike 6.17.
Slika 6.17: Opomba delavcem s strani planerja
V zadnjem zavihku, ki smo ga poimenovali izpisi, so različni izpisi plana glede na izbrane
kriterije. Kriterij je teden, ob izbiri tedna program avtomatsko napolni datum od/do, lahko pa
izpisujemo tudi skozi daljše (ali krajše) obdobje. Ker je eden izmed naših ciljev brezpapirna
proizvodnja, smo implementirali le osnovne izpise, saj se načeloma plani ne tiskajo, ampak
so vidni na aplikaciji na stroju.
6.2.3 Vodenje kod PIN
DPA je namenjen vnosu kod PIN in določitvi črtnih kod za delavce na stroju. Dostop do
modula smo uredili preko menija (slika 6.5), kjer se uporabniku odpre okno s seznamom
delavcev RM (slika 6.18). V primeru, da so v kadrovski službi vnesli novega delavca RM in
mu določili pravilno skupino, se takšen delavec samodejno pojavi v seznamu. Koda PIN je
43
avtomatsko prazna, prav tako tip, koda EAN pa se generira sama. V takšnem primeru
delavec še vseeno nima dostopa do aplikacije na RM, saj nima določenega tipa. To pomeni,
da skozi to rešitev, ki je dosegljiva v sistemu Pantheon, nastavljamo uporabnike za zunanjo
rešitev. Ker v zunanji aplikaciji različni uporabniki uporabljajo drugačne vrste
funkcionalnosti, smo v tej dodelavi implementirali tudi možnost nastavljanja nivojev
avtorizacij. Nivoje avtorizacij smo si zastavili z določitvijo tipa uporabnika, kjer smo definirali
šest različnih tipov, hkrati pa smo dovolili tudi prazen tip, ki pomeni, da delavec do aplikacije
nima dostopa.
Možni tipi so:
- D – delavec RM,
- M – delavec Montaža,
- N – delavec Mlin,
- K – kontrolor,
- E – delovodja,
- V – vodja proizvodnje in
- prazen (pomeni, da gre za nekdanjega delavca, ali delavca, ki trenutno nima
nobenih pravic).
Slika 6.18: Vodenje prijavnih kod za RM delavce
V sklopu te dodelave smo implementirali tudi izpis delavčeve kode EAN, ki je unikatna
vsakemu delavcu in se lahko skozi dodelavo tudi natisne. Koda EAN se uporablja za hitro
prijavo na stroj preko čitalca. Primer kode je viden na sliki 6.19.
44
Slika 6.19: Črtna koda za prijavo
6.3 Zunanja aplikacija
Aplikacija na stroju je v osnovi namenjena beleženju opravljenega dela s strani delavcev in
beleženju dobrih in slabih izdelkov ter pregledu informacij. Zasnovana je tako, da je čim bolj
pregledna in preprosta.
6.3.1 Nastavitve aplikacije
Aplikacija se namesti v mapo: C:\panPROIZ na lokalnem računalniku in vsebuje datoteki,
poimenovani PANProiz.exe in settings.xml.
V datoteki settings.xml, ki je prikazana na sliki 6.20, se nastavi podatke za povezavo do
stroja. Vsebuje uporabniško ime in šifrirano geslo za dostop do podatkovne baze SQL in
ime strežnika ter podatkovne baze, informacijo o zadnjem prijavljenem uporabniku ter
podatek, v kateri mapi na lokalnem računalniku (stroju) naj prebira podatke. Prav tako je v
tej datoteki definirana šifra stroja iz šifranta resursov (seštevalna). Tako se skozi aplikacijo
vidijo samo planirani resursi, ki spadajo k temu seštevalnemu resursu.
45
Slika 6.20: Primer datoteke XML "settings.xml"
6.3.2 Prijava v sistem na stroju
Sistemu za prijavo in odjavo na stroju je bila posvečena posebna skrb, saj se na stroj prijavi
ekipa delavcev in je pomembno, da prijave (in odjave) delujejo brezhibno, predvsem pa
hitro. Do prijave in odjave pride preko črtne kode, ki je določena za vsakega delavca
posebej in jo ima vsak natisnjeno na svoji kartici za prijavo. Kot je razvidno iz slike 6.21, je
maska za prijavo popolnoma preprosta, in sicer deluje tako, da delavec približa svojo kartico
čitalcu, sistem pa ga nato avtomatsko prijavi oziroma odjavi (odvisno od situacije, kar zazna
program sam).
Slika 6.21: Prijavna maska v aplikaciji na stroju
Ker se lahko zgodi, da delavec pride brez kartice, se le-ta poškoduje ali pa se zgodi okvara
na čitalcu kartic, smo uvedli tudi možnost ročne prijave. Uporabi se gumb Razširi/skrči, kar
je razvidno na sliki 6.22.
Pri ročni prijavi delavec izbere uporabnika in vpiše kodo PIN.
46
Slika 6.22: Prijavna maska v aplikaciji na stroju - ročna prijava26 27
6.3.3 Delo z aplikacijo na stroju
Plan dela se sinhronizira glede na pripravljen plan dela v sistemu Pantheon (glede na šifro
resursa). Sinhronizacija se izvede po vsakem poročanju komada oziroma na zahtevo.
Prikaz realiziranega je v zavihku realizacija. Vidni so podatki v tekoči izmeni.
Prav tako je možno videti tehnološke podatke o izdelku. Ti podatki so zavedeni v šifrantu
identov ter v osnovni kosovnici. Opozorila in opombe vpisuje planer v postopku za
mikroplaniranje.
26 Gumb TEST je viden le v »debug« načinu. 27 Gumb PRIJAVA/ODJAVA je namenjen spremembi načina uporabe aplikacije, na primer, če se je uporabnik želel odjaviti in si je premislil, tapne na ta gumb.
47
Opisali bomo nekaj glavnih funkcionalnosti, ki smo jih implementirali:
1. Beleženje časa dela delavcev na stroju – v vsakem trenutku imamo informacijo, kdo
je bil v določenem trenutku prijavljen na stroju, saj beležimo tako prijavo kot odjavo
posameznega delavca. Ker se na stroj lahko prijavi več delavcev hkrati, in ne samo
en, imamo podatek o ekipi na stroju v določenem trenutku. Na podlagi tega podatka
dobimo informacijo, pri koliko posameznih izdelkih je vsak delavec sodeloval. Še
več, če se pri menjavi izmene izdelki še niso izdelali do konca, lahko celo
izračunamo odstotek izdelka, ki pripada posameznemu delavcu. S tem se uredi tudi
bolj pravičen izračun števila izdelkov, saj je prej tak izdelek 100-odstotno pripadal
delavcu iz naslednje izmene, zato delavcu iz prve izmene ni bilo v interesu delati
izdelka naprej. Na podlagi težavnosti izdelave izdelka (kar je podatek iz šifranta
identov), poročanih slabih izdelkov in še nekaterih drugih parametrov, se konec
meseca izračuna tudi uspešnost delavca, ki je med drugim dejavnik pri plačilu
delavca.
2. Poročanje dobrih in slabih izdelkov – delavec lahko s preprostim klikom na gumb
potrdi, ali gre za dober izdelek ali za izmet. Rezultat delavčeve izbire je nalepka, ki
spremlja izdelek pri nadaljnji obdelavi. Pri slabem izdelku je nalepka rdeče barve in
gre naprej v kontrolo, kjer se ugotovi, ali se izdelek še lahko popravi ali pa gre v
reciklažo. Pri slabem izdelku je treba izbrati tudi razlog za napako na izdelku.
Razloge smo standardizirali in so osnova za nadaljnje analize. Pri poročanih slabih
izdelkih se namreč lahko hitro najdejo kakšne zunanje težave, kot so na primer
napake na modlu, resursu, stroju ali v slabem materialu. Pri poročanju dobrega
izdelka (in tudi slabega) se po vsakem ciklu preračunajo predvideni končni termini
za vse naslednje cikle. Pri tej funkcionalnosti se kličejo enake metode iz podatkovne
baze SQL, ki smo jih klicali že pri planiranju ciklov. Funkcionalnost je pomembna za
komercialo, saj neposredno zamika predvidene roke izdelave (Slika 3.2). S tem
imajo komercialisti ažuriran podatek o predvidenih rokih dobave in se lahko v
primeru morebitnih zastojev uskladijo s kupci, podatek pa je pomemben tudi za
plansko službo, saj se lahko v primeru večje okvare, ki bi posledično prinesla
zamude pri dobavah, uvede dodatna izmena.
3. Opozorila planerja - Planer lahko pri mikroplaniranju na določen cikel pripne
določena opozorila. Opozorila so tipa, na primer, pozor, pri izdelku X imamo nov
48
material. Delavci se namreč na izdelke precej navadijo in ko pride do kakšne
spremembe, delajo naprej po stari recepturi. S tem jih planer lahko posebej opozori.
4. Opozorila tehnologa – Tako kot v prejšnji točki, je podobna funkcionalnost lahko tudi
s strani tehnologije. Delavci imajo namreč na aplikaciji možnost prikaza tehnološke
recepture izdelka in si tako lahko v vsakem trenutku pogledajo posebnosti izdelka.
To smo implementirali tako, da smo izdelke v podatkovni bazi SQL povezali z
datotekami na datotečnem strežniku, ki je dosegljiv iz notranjega omrežja podjetja.
Datoteke so v formatu PDF, vsak računalnik na stroju tako mora imeti nameščen
ustrezen bralnik. Dodatno smo še vgradili kontrolo, ki preverja, ali je tehnolog naredil
novo revizijo tehnološkega postopka, v tem primeru aplikacija delavce pri stroju na
to posebej opozori.
6.3.4 Poročanje podatkov stroja
Podatki iz stroja se poročajo avtomatsko pri poročanju komada.
Podatki se zapisujejo v *.rcb datoteke v naslednji obliki:
- “C:\STROJ\LLMMDD.rcb” (leto, mesec,dan).
To je tekstovna datoteka. Podatki se shranjujejo asinhrono. Vse vrednosti se vpišejo, ko se
katerikoli podatek spremeni. V eni vrstici so zajeti vsi podatki v danem trenutku. Oblika
zapisa je sledeča:
UraMinutaSekunda:R01:Smena:Temperatura:Plin:Elektrika:RezimRoka1:R
ezimRoka2:RezimRoka3:PozicijaRoka1:PozicijaRoka2:PozicijaRoka3
Primer:
- 183137:RM01:2:120:23:47:1:1:0:3:5:6
Pomeni: Ob 18 uri 31 minut in 37 sekund je stroj RM01 v izmeni 2, temperatura peči je
120°C, števec porabe plina je 23 in elektrike 47. Roka 1 in 2 sta v avtomatskem režimu,
roka 3 pa v ročnem. Roka 1 je na poziciji 3, roka 2 na poziciji 5 in roka 3 na poziciji 6.
49
6.4 Procedure, funkcije ter ostali bazni objekti
Ogromno poslovne logike sistema Pantheon je napisano v obliki procedur in funkcij SQL.
Tega principa smo se držali tudi sami in tako napisali večino logike v tej obliki in s tem
poskrbeli, da so dosegljive vsem tipom prilagoditev. Na ta način tudi ne podvajamo logike.
Vse dodatno kreirane objekte na SQL smo poimenovali s svojo notacijo (tabela 4.2). Tako
na primer proceduro za preračun predvidenih rokov dobave na posamezni resurs kličemo
iz stroja, ko se spremeni status cikla, prav tako pa jo kličemo iz mikroplanirnega modula iz
sistema Pantheon, ko se doda ali spremeni planiran cikel. To pomeni, da kličemo enako
proceduro iz dveh aplikacij. V primeru morebitne dodatne zahteve spremenimo eno
proceduro in tako zagotovimo, da dobimo iz dveh narejenih rešitev enak rezultat. Prikaz
sheme povezav med sistemom Pantheon, podatkovno bazo in dodatnimi rešitvami je
razviden iz slike 6.23.
Slika 6.23: Shema povezav med sistemom Pantheon in dodatnimi rešitvami
50
7 SKLEP
Prilagoditev procesa proizvodnje v sistemu ERP ali MRP je za proizvodno podjetje, ki gleda
na svojo proizvodnjo kot na konkurenčno prednost, ključnega pomena. Nakup takšnega
obsežnega informacijskega sistema je dolgoročna strateška usmeritev, zato je potrebno
najti standardizirane rešitve, ki so zasnovane po najboljših praksah iz tujine, hkrati pa
vsebujejo lastnosti, ki so specifične posameznim državam, v katerih podjetje posluje. Prav
tako je pomembno, da poiščemo programsko rešitev, ki dovoljuje razvoj lastnih rešitev in
prilagoditev lastnih procesov.
Uvedba takšnega sistema v podjetju z utečenimi procesi pomeni vsekakor svojevrsten izziv.
Največ težav pri informatizaciji procesov se pojavlja pri definiranju samih procesov, saj se
ne posveti zadosti časa ugotavljanju dejanskega stanja. Pri implementaciji sistema se
namreč velikokrat ugotovi, da proces na terenu ni v skladu s procesi, definiranimi v projektni
dokumentaciji. Še več, velikokrat se zgodi, da proces na terenu in definiran proces nimata
prav veliko skupnega. Do tovrstnih razhajanj prihaja zaradi različnih predstav, kako bi naj
sistem deloval in zaradi različnega dojemanja posameznih problemov. Vsekakor je
implementacija informacijskega sistema idealna priložnost za spreminjanje in izboljševanje
procesov v podjetju, saj vsaka taka sprememba za utečeno podjetje predstavlja določen
nivo stresa. Pri uvedbi takega projekta je zato izredno pomembno, da se projekt ustrezno
vodi s strani izvajalca in prav tako tudi s strani naročnika, da je takšnih situacij čim manj.
V našem konkretnem primeru se informacijski sistem Pantheon s svojo odprtostjo pokaže
kot prednost, saj smo z ustreznimi prilagoditvami in dodatnimi rešitvami precej pohitrili
proces vnosa, planiranja in ostalih opravil. Z našo konkretno rešitvijo lahko dosežemo
izboljšave v samem planiranju materiala, zmanjšajo se zastoji, poveča se produktivnost ter
izboljša sledljivost. Vse to pa ni samo odvisno od sistema, ampak predvsem od tega, ali
glavni procesi sledijo sistemu.
Vsekakor sistem omogoča še marsikatero izboljšavo, saj je proizvodni proces živ proces,
ki vedno stremi k optimizacijam in izboljšavam. Takšen mora biti tudi podporni informacijski
sistem.
51
VIRI IN LITERATURA
[1] T. Ljubič, Operativni management proizvodnje, Kranj: Moderna organizacija v
okviru FOV Kranj, 2006.
[2] Datalab Tehnologije d.d., „Pogosta vprašanja,“ [Elektronski]. Available:
http://www.datalab.si/vlagatelji/pogosta-vprasanja/. [Poskus dostopa 21 avgust
2016].
[3] R. Ray, Enterprise Resource Planning, New Delhi: McGraw Hill Education, 2010.
[4] MonitorPRO, „Poslovni informacijski sistemi,“ 2011. [Elektronski]. Available:
http://www.monitorpro.si/media/objave/dokumenti/2011/8/5/poslovni_informacijski_
sistemi.pdf. [Poskus dostopa 17 avgust 2016].
[5] Datalab Tehnologije d.d., „Vrste namestitve glede na konfiguracijo mreže,“
[Elektronski]. Available: https://usersite.datalab.eu/Wiki/tabid/178/language/sl-
SI/Default.aspx?tocid=4434. [Poskus dostopa 23 julij 2016].
[6] Datalab Tehnologije d.d., „Cene in funkcionalnosti Pantheon licenc,“ [Elektronski].
Available: http://www.datalab.si/cene-in-funkcije/. [Poskus dostopa 23 julij 2016].
[7] Datalab Tehnologije d.d., „Vse o poslovno-informacijskem sistemu Pantheon,“
[Elektronski]. Available:
ftp://ftp.datalab.hr/Marketing/Materiali/PPT/SI_Vse%20o%20pantheonu%20(tisk).p
df. [Poskus dostopa 24 julij 2016].
[8] Datalab Tehnologije d.d., „Zmogljivosti sistema Pantheon Manufacture za
proizvodnjo,“ [Elektronski]. Available:
http://www.datalab.si/pantheon/manufacture/zmogljivosti/. [Poskus dostopa 23 julij
2016].
[9] Datalab Tehnologije d.d., „Vodenje proizvodnih enot - Pantheon MT,“ [Elektronski].
Available: http://www.datalab.si/pantheon/manufacture/vodenje-proizvodnih-enot/.
[Poskus dostopa 23 julij 2016].
[10] Datalab Tehnologije d.d., „Pantheon konektor licence,“ [Elektronski]. Available:
http://www.datalab.si/pantheon/specific-solutions/konektor-licence/. [Poskus
dostopa 23 julij 2016].
52
[11] Datalab Tehnologije d.d., „Vodič po Datalab PANTHEON-u 5.5,“ [Elektronski].
Available: https://usersite.datalab.eu/Wiki/tabid/178/language/sl-SI/Default.aspx.
[Poskus dostopa 24 julij 2016].
[12] Fast Reports Inc.,, [Elektronski]. Available: https://www.fast-report.com. [Poskus
dostopa 26 julij 2016].
[13] S. Kumar, „What are the limitations of SQL Server Express edition?,“ Database
Zone, 30 marec 2013. [Elektronski]. Available: https://dzone.com/articles/what-are-
limitations-sql. [Poskus dostopa 23 julij 2016].
[14] Wikipedia, The Free Encyclopedia, „Rotational molding,“ 11 avgust 2016.
[Elektronski]. Available: https://en.wikipedia.org/wiki/Rotational_molding. [Poskus
dostopa 13 avgust 2016].
[15] M. Hesseler, „Customizing von ERP-Systemen. Rollenbasierte Konzepte bieten
neue Möglichkeiten für individuelle Anpassungen,“ Controlling & Management, Izv.
53, pp. 48-55, 2009.
[16] T. Gürth, Business model driven ERP customization, Dunaj: Faculty of informatics.
Vienna University of technology, magistrsko delo, 2014.
53