SVEUILITE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAUNARSTVA

Frane Urem

MODELIRANJE POUZDANOSTI PROGRAMSKE PODRKE ZA UPRAVLJANJE RESURSIMA PODUZEA

DOKTORSKI RAD

Zagreb, 2012

UNIVERSITY OF ZAGREB FACULTY OF ELECTRICAL ENGINEERING AND COMPUTING

Frane Urem

RELIABILITY MODELLING OF ENTERPRISE RESOURCE PLANNING SOFTWARE

DOCTORAL THESIS

Zagreb, 2012

Doktorski rad je izraen na Sveuilitu u Zagrebu, Fakultetu elektrotehnike i raunarstva, Zavodu za primijenjeno raunarstvo.

Mentor: Prof.dr.sc. Kreimir Fertalj

Doktorski rad ima: 126 stranica Doktorski rad br.:

Ponajprije zahvaljujem svome mentoru profesoru Kreimiru Fertalju na savjetima i smjernicama tijekom izrade doktorskog rada. Takoer elim zahvaliti i kolegama sa Veleuilita u ibeniku posebno elimiru Mikuliu na pomoi u istraivanju i profesoru Marku Radaiu na ukazanom povjerenju. I na kraju, veliko i posebno hvala mojoj supruzi i roditeljima na podrci tijekom svih ovih godina.

Kratki saetak
Posljednjih dva desetljea istraivanje pouzdanosti programske podrke postaje sve pristupanije i popularnije. Znaajno mjesto u takvim istraivanjima zauzimaju i sustavi za upravljanje resursima poduzea (engl. Enterprise Resource Planning-ERP) kao vrlo bitni sustavi programske potpore svim poslovnim procesima u modernom poslovanju. Opisan je i formaliziran vlastiti postupak primjene modela pouzdanosti programske podrke na ERP sustave. Postupak ukljuuje optimalno prikupljanje, analizu i obradu podataka o prijavljenim pojavama neispravnosti u ERP sustavu i naknadno vrednovanje utvrenog modela pouzdanosti. Opisani su i primijeneni numeriki postupci utvrivanja prikladnih modela pouzdanosti prema izmjerenim razdiobama neispravnosti na stvarnom sustavu. Takoer su prikazani primjeri uporabe poznatih postupaka statistike provjere i vrednovanja na pretpostavljene modele pouzdanosti ERP sustava. Predstavljeni su i primijenjeni popratni algoritmi potrebni za uspjeno odvijanje postupka predvianja pouzdanosti ERP sustava. U okviru rada je istraena i primijenjena tehnika operacijskog profila kao zanimljiv i nedovoljno koriten postupak za efikasniju provjeru i poveanje pouzdanosti ERP sustava. Posebno je istraen utjecaj izvoenja nadogradnji na pouzdanost ERP sustava. Obavljena je validacija primjene vlastitog modela utjecaja nadogradnji kroz predvianje broja prijava i vremenske razdiobe defekata u periodima izmeu obavljenih nadogradnji

Kljune rijei
ERP sustav, pouzdanost ERP sustava, modeliranje pouzdanosti, operacijski profil, utjecaj nadogradnje na pouzdanost, predvianje pouzdanosti

Extended abstract
In the last two decades the software reliability research is becoming more accessible and popular. Important place for such research is taken up for enterprise resource planning (ERP) systems as the most important software systems for different businesses. The complexity of their architecture and supported business processes is resulting with complex and demanding reliability analysis. Existing studies generally examine the impact of operational risk in the field of hardware, information security, communications and business processes but less in the field of software errors, training, configuration and customizations. Customers need a simple and easily understood procedures in assessing the reliability of the ERP system to act before the system becomes unusable or at worst undermine their business. In the introduction of this dissertation are presented the basic concepts and terms related to ERP systems with the concept of defect tracking in their implementation and production. The ERP system life cycle processes are particularly described with emphasizing of adjustments and adaptations as sources of potential defects. The basic definitions and software reliability models are presented with particularly description of later used exponential and Weibull model of software reliability. Later on, the process of making an appropriate reliability model from the available measurements of the real ERP system is described. The procedures of processing and analyzing the collected data for easier later identification of the appropriate statistical distributions are highlighted. Briefly, presentation of software package used for later statistical fitting of empirical data is made with an example from performed case study. Mathematical algorithms that can be used for Weibull and exponential software reliability models in assessing the best-fit statistical distribution of empirical data are specifically mentioned and explained. The statistical tests that were used and the way of their application in evaluating the confidence of the chosen ERP reliability model are presented. The operational profile technique is described as an interesting method for efficiently ERP system testing and reliability growth. Theoretical concepts are systematically processed on a specific case study of specific ERP software modules and in an understandable manner presented with illustrations how the operating profile should be developed and applied. Constant upgrading of ERP systems is necessary, but can cause new defects. This dissertation attempts to model the likelihood of defects after completed upgrades with Weibull defect probability density function. A case study is presented analyzing data of recorded defects ii

obtained for one ERP subsystem. The trends are observed for the value of the parameters relevant to the proposed statistical Weibull distribution for a given one year period. As a result, the ability to predict the appearance of defects after the next upgrade is described. The result of the applied modelling is in modelling the reliability of the ERP system from a user perspective with estimated parameters like expected maximum number of defects in one day or predicted minimum of defects between two upgrades. The results of this thesis will be useful to manufacturers of ERP systems in the modeling of the quality of implementation of their ERP products, but also for ERP users in assessing the reliability of the applied ERP system.

Keywords
ERP system, ERP reliability, reliability modelling, operational profile, impact of upgrades on reliability, reliability prediction

iii

Sadraj
Kratki saetak .............................................................................................................................. i Kljune rijei ............................................................................................................................... i Extended abstract ....................................................................................................................... ii Keywords .................................................................................................................................. iii 1. Uvod .................................................................................................................................... 1 1.1. 1.2. 1.3. 2. 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 3. 3.1. 3.2. 3.3. 3.4. 3.5. Motivacija .................................................................................................................... 1 Znanstveni doprinosi ................................................................................................... 2 Struktura rada .............................................................................................................. 2 Povijesni razvoj ERP sustava ...................................................................................... 5 Arhitektura ERP sustava .............................................................................................. 6 Proizvoai ERP sustava na svjetskom tritu ............................................................ 9 ivotni ciklus ERP sustava ........................................................................................ 12 Podeavanje i prilagodba ERP sustava poslovanju korisnika ................................... 13 Glavne prednosti i nedostaci ERP sustava ................................................................ 17 Praenje defekata u ERP sustavima........................................................................... 18 Osnovne definicije ..................................................................................................... 22 Opi model pouzdanosti ............................................................................................ 23 Pregled modela pouzdanosti programske podrke .................................................... 24 Eksponencijalni model pouzdanosti programske podrke ......................................... 26 Weibull model pouzdanosti programske podrke ..................................................... 29

ERP sustavi ......................................................................................................................... 4

Modeliranje pouzdanosti programske podrke ................................................................. 22

4. Optimiranje izbora parametara ulaznih veliina za oblikovanje modela pouzdanosti ERP sustava ...................................................................................................................................... 32 4.1. 4.2. 4.3. 4.4. 4.4.1 4.4.1.1 4.4.2 Obrada podataka o zabiljeenim defektima ............................................................... 33 Razliiti pristupi u analizi podataka .......................................................................... 37 Statistika analiza podataka ....................................................................................... 38 Postupci za procjenu parametara statistikih razdioba .............................................. 40 Metoda momenata .................................................................................................. 40 Primjena metode momenata na odreivanje parametara Weibull razdiobe ....... 40 Metoda maksimalne vjerodostojnosti .................................................................... 41

4.4.2.1 Primjena metode maksimalne vjerodostojnosti na odreivanje parametara Weibull razdiobe .................................................................................................................. 41 4.4.2.2 Primjena metode maksimalne vjerodostojnosti na odreivanje parametara eksponencijalne razdiobe ..................................................................................................... 42 4.4.3 Metoda najmanjih kvadrata .................................................................................... 43 iv

4.4.3.1 razdiobe 4.5. 4.5.1 4.5.2 4.5.3 4.6. 4.6.1 4.6.2

Primjena metode najmanjih kvadrata na odreivanje parametara Weibull ............................................................................................................................ 44 Primjena Kolmogorov-Smirnov testa .................................................................... 47 Primjena Anderson-Darling testa ........................................................................... 49 Identifikacija prikladnog modela koritenjem programa EasyFit .......................... 51

Identifikacija prikladnog modela pouzdanosti ERP sustava ..................................... 45

Primjena statistikih modela pouzdanosti na ERP sustave ....................................... 54 Primjena eksponencijalnog modela pouzdanosti na ERP sustave ......................... 55 Primjena Weibull modela pouzdanosti na ERP sustave ........................................ 60

4.6.3 Primjena postupka linearne regresije u predvianju buduih vrijednosti Weibull statistike razdiobe ............................................................................................................... 61 4.6.4 Primjena KNN algoritma u predvianju buduih vrijednosti Weibull statistike razdiobe ................................................................................................................................ 63 5. Unaprjeenje scenarija provjere ERP sustava na temelju izraenog operacijskog profila65 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 5.8. 5.9. 5.10. 5.11. 6. 6.1. 6.2. Postupci izrade operacijskog profila s primjenom u ERP sustavima ........................ 69 Kratki opis ERP modula za kojeg je izraen operacijski profil ................................ 70 Odreivanje grupe kupaca ......................................................................................... 71 Odreivanje vrsta korisnika ....................................................................................... 72 Naini rada sustava .................................................................................................... 72 Izrada operacijskog profila ........................................................................................ 73 Opis koritenja alata Microsoft SQL Profiler u izradi operacijskog profila .............. 74 Primjer identifikacije i biljeenja operacija na promatranom ERP modulu .............. 77 Rezultati istraivanja u izradi korisnikog profila ..................................................... 78 Rezultati istraivanja u izradi operacijskog profila................................................ 82 Primjer koritenja operacijskog profila u izradi scenarija provjere ERP modula .. 85 Uzroci nadogradnje ERP sustava .............................................................................. 89 Uporaba prikladnih matematikih modela ................................................................ 91

Modeliranje utjecaja nadogradnje na pouzdanost ERP sustava ........................................ 88

6.3. Modeliranje vremenske razdiobe pojave defekata nakon provedene nadogradnje ERP sustava .................................................................................................................................. 94 6.4. Modeliranje oekivanog broja pojava defekata nakon provedene nadogradnje ERP sustava ................................................................................................................................ 109 7. Zakljuak ......................................................................................................................... 118 Literatura ................................................................................................................................ 120 Popis kratica ........................................................................................................................... 124 ivotopis................................................................................................................................. 125 Biography ............................................................................................................................... 126

1. Uvod
Posljednjih dva desetljea istraivanje pouzdanosti programske podrke postaje sve pristupanije i popularnije zahvaljujui razvoju tehnologija koje omoguavaju jednostavno prikupljanje i pohranu podatka o nepravilnostima u izradi i koritenju sustava programske podrke, izvoenje sloenih algoritama u modeliranju dostupnih podataka i naknadnu usporedbu s poznatim modelima pouzdanosti. Znaajno mjesto u takvim istraivanjima zauzimaju i sustavi programske podrke za upravljanje resursima poduzea kao vrlo bitni sustavi programske potpore svim poslovnim procesima u modernom poslovanju. Podruje istraivanja pouzdanosti ERP sustava obuhvaa razliita podruja: umjetnu inteligenciju, statistiku, voenje poslovanja i baze podataka.

1.1.

Motivacija

Predmet prouavanja podruja pouzdanosti programske podrke je uglavnom modeliranje pojava razliitih pogreaka u izradi i radu raznih sustava programske podrke koje naknadno slue za procjenu kvalitete programske podrke, ali i procjenu sigurnosti uporabe odreene programske podrke tamo gdje je to posebno bitno (npr. u medicini, prometu, svemirskim istraivanjima i sl.). Posebno se istrauju primjene razliitih metoda koje dovode do izrade pouzdanijeg programskog koda, boljih naina provjere sloenih sustava programske podrke i brzog prepoznavanja uzroka defekata koji nastaju prilikom izrade i koritenja programske podrke. Posebnu grupu sustava programske podrke ine ERP sustavi koji se danas koriste u razliitim podrujima poslovanja i tamo gdje su implementirani vre bitan utjecaj na ukupno poslovanje. Pouzdanost takvih sustava je vrlo bitna jer svaki zastoj u njihovom radu predstavlja veliku tetu u poslovanju. Odreivanje stanja pouzdanosti ERP sustava je vrlo kompleksno podruje zbog njihove sloenosti i uvjetovano je raznim vanjskim i unutarnjim imbenicima. Postoji niz preporuka za najbolju implementaciju takvih sustava koji mogu povezati prijavljene probleme i njihove uzroke. Postojei sustavi prijave problema prilikom implementacije i koritenja takvih sustava su visoko automatizirani i omoguavaju prijavu neispravnosti direktno iz programskih modula kao i naknadno praenje svih bitnih informacija u rjeavanju defekata koji ih uzrokuju. Postojea istraivanja uglavnom prouavaju utjecaj operativnih rizika iz podruja strojne opreme, informacijske sigurnosti, komunikacijske 1

infrastrukture i poslovnih procesa koji mogu direktno ugroziti implementaciju i produkciju ERP sustava, ali najee ne obraaju dovoljnu pozornost na programske pogreke, obuku djelatnika, razliite pogreke u dokumentaciji i prilagodbi sustava. Nedostaju dodatne funkcionalnosti na postojeim sustavima za praenje neispravnosti koje bi po potrebi modelirale trenutno stanje pouzdanosti ERP sustava na temelju svih uoenih defekata bez obzira na njihove uzroke i u konanici ostvarile odreena predvianja za budue koritenje. Korisnicima su potrebni jednostavni i lako razumljivi postupci u procjeni pouzdanosti ERP sustava kako bi djelovali prije nego sustav postane neupotrebljiv ili u najgorem sluaju ugrozi njihovo poslovanje.

1.2.

Znanstveni doprinosi

Cilj istraivanja je odabir i provjera prikladnih matematikih postupaka s primjenom u modeliranju i predvianju pouzdanosti ERP sustava. Rezultati istraivanja su vidljivi u ostvarenim modelima i njihovom potvrdom na stvarnim sustavima. U okviru ovog rada predstavljeni su sljedei znanstveni doprinosi: Optimiranje izbora parametara ulaznih veliina za oblikovanje modela pouzdanosti ERP sustava. Vrednovanje modela predvianja pouzdanosti prilagoenih za analizu ERP sustava. Unaprjeenje scenarija provjere ERP sustava na temelju izraenog operacijskog profila. Modeliranje utjecaja nadogradnje na pouzdanost ERP sustava.

1.3.

Struktura rada

Drugo i tree poglavlje ine uvodni dio ovog rada. U drugom poglavlju rada su predstavljeni osnovni koncepti i pojmovi vezani za ERP sustave i praenje neispravnosti u njihovom uvoenju i koritenju. Predstavljena su osnovna svojstva ERP sustava s opisom arhitekture i bitnih proizvoaa s trinim udjelima. Posebno je opisan ivotni ciklus ERP sustava i istaknuti procesi podeavanja i prilagodbe kao izvori potencijalnih defekata. U treem poglavlju su prikazane osnovne definicije i modeli pouzdanosti programske podrke. Posebno su opisani naknadno koriteni eksponencijalni model pouzdanosti i Weibull model pouzdanosti. 2

U etvrtom poglavlju je opisan postupak izrade odgovarajueg modela pouzdanosti temeljem dostupnih mjerenja na stvarnom sustavu. Posebno su istaknuti postupci obrade i analize prikupljenih podataka kako bi se jednostavno utvrdile statistike razdiobe koje ih dobro opisuju. Kratko je prikazan programski paket s kojim je obavljena naknadna statistika analiza empirijskih podataka i odabir najbolje pristajue statistike razdiobe. Matematiki algoritmi koji se koriste u procjeni prikladnih statistikih razdioba unutar unutar koritenog programskog paketa su posebno izdvojeni kako bi se dala podloga za neovisnu primjenu takvih algoritama u analizi pouzdanosti ERP sustava i programske podrke openito. Prikazan je posebno istraena primjena eksponencijalnog modela pouzdanosti tijekom prilagodbe ERP sustava. Takoer su opisani koriteni statistiki testovi i nain njihove primjene u vrednovanju odabranog modela pouzdanosti. U petom poglavlju je predstavljena tehnika primjene operacijskog profila kao zanimljiv i nedovoljno koriten postupak za efikasnije testiranje i poveanje pouzdanosti ERP sustava. Teorijski koncepti su sustavno obradjeni na studijskom primjeru konkretnog ERP programskog modula te su na razumljiv nain tablino prezentirane ilustracije kako se operacijski profil razvija i primjenjuje. U estom poglavlju je prikazano modeliranje utjecaja nadogradnji na pouzdanost ERP sustava. Prethodno navedeni teorijski koncepti su detaljno obraeni s dvije mogue primjene. U prvoj je prikazano modeliranje vremenskih razdioba pojava defekata izmeu provedenih nadogradnji. U drugoj su pojave defekekata analizirane u mjerenim rasponima vrijednosti to je u konanici omoguilo predvianje zanimljivih pokazatelja pouzdanosti za korisnike ERP sustava kao to su predvianja broja pojava defekata u periodu izmeu provedenih nadogradnji. U oba sluaja su koriteni i usporeeni KNN algoritam i metoda linearne regresije kao postupci predvianja buduih vrijednosti parametara Weibull razdiobe. Na kraju je dan kritiki osvrt na rezultate doktorskog rada, prijedlog buduih aktivnosti te zavrni pregled rada.

2. ERP sustavi
ERP sustavi su integrirani informacijski sustavi za podrku poslovanju koji se koriste u razliitim dijelovima organizacije nekog poduzea [5]. Integracija je posebno vidljiva u podatkovnom sloju jer svi dijelovi sustava koriste jednu bazu podataka. U naelu se isporuuju kao zavreni programski paketi, ali se mogu i prilagoditi potrebama odreene poslovne organizacije i njezinom informacijskom sustavu. Najee se sastoje od vie programskih modula koji pokrivaju odreena podruja poslovanja pa poslovna organizacija odabire dijelove sustava koji su joj doista potrebni ili ih po potrebi povezuje sa dijelovima vlastitog informacijskog sustava koji su izvedeni od drugih proizvoaa. Krajem 90-tih godina je prodaja takvih sustava biljeila nagli rast u prodaji kod velikih poduzea, a u zadnjem desetljeu su posebno rasle instalacije u manjem i srednjem poduzetnitvu. Prema nedavno objavljenoj studiji analitike kue IDC Adriatics [1], ukupan je prihod od licenci i odravanja ERP rjeenja na hrvatskom tritu za 2010. godinu iznosio 37.53 mil USD. Od 2009. godine veina proizvoaa ERP sustava u RH biljei zasienje ili blagi pad prodaje to se moe tumaiti kao posljedica velike financijske krize koja je u istom periodu pogodila potencijalne kupce, ali i odreenog zasienja trita. U budunosti e veina kupaca troiti vie na odravanju ve instaliranih ERP sustava, ali pri tome mora prepoznati budue trokove i utjecaj odravanja postojeih ERP sustava na poslovanje. Openito, za ERP paket vrijedi sljedee [6]: predstavljaju integrirano rjeenje koje prati poslovne procese u realnom vremenu svi podaci su pohranjeni u jedinstvenoj bazi podataka sastoji se od vie specijaliziranih modula za pojedine dijelove poslovanja

ERP sustav se definira kao programska podrka za najmanje tri od sljedea etiri segmenta poslovanja [7]: financijsko poslovanje (engl. accounting) proizvodnja (engl. manufacturing) robno-materijalno poslovanje (engl. material management/distribution) upravljanje ljudskim resursima i plae (engl. HR management, payroll) 4

2.1.

Povijesni razvoj ERP sustava

Povijest ERP sustava poinje 1960-tih godina kada se na tritu pojavljuju prvi centralizirani sustavi za upravljanje zalihama (engl. inventory control). Tradicionalni sustav voenja zaliha se tada uglavnom oslanjao na rune evidencije koje nisu bile aurirane sa stvarnim stanjem pa su nastajali veliki gubici u poslovanju uslijed kraa, prevelikih zaliha i sl. Tijekom 1970-tih godina se pojavljuju informacijski sustavi za upravljanje zalihama materijala (engl. material requirements planning - MRP). Glavna svrha MRP sustava je bila podrka prevoenju glavnih planova proizvodnje u manje dijelove iz kojih su se definirale potrebe za materijalom i zalihama u buduoj proizvodnji. U 1980-tim godinama se javlja potreba za efikasnijim planiranjem svih resursa proizvodnje. Pojavljuju se novi MRP II sustavi koji poetno uvode nove funkcionalnosti u podrci prodajnim i distribucijskim aktivnostima. Ubrzo nakon toga se uvodi i financijsko praenje proizvodnje, voenje projekata, upravljanje ljudskim potencijalima itd. U konanici MRP II sustavi donose tri kljune novosti u odnosu na prethodne MRP sustave: optimalno voenje zaliha usklaivanjem prodaje i potranje financijsko praenje svih dijelova materijalnog poslovanja u proizvodnji i prodaji mogunost razliitih poslovnih simulacija i predvianja

ERP sustavi su naslijedili MRP II sustave tijekom 1990-tih godina paralelno s naglim razvojem novih informacijskih tehnologija. Takvi sustavi su razvijeni s naprednijim razvojnim alatima to je rezultiralo velikim skupovima podranih poslovnih funkcija. Uvode slijedea proirenja funkcionalnosti u odnosu na MRP II sustave: omoguavaju povezivanje kupaca i dobavljaa koristi ih vei broj zaposlenika uvode koncept poslovne inteligencije povezuju sve dijelove poslovanja u jednu cjelinu

Koncept E-poslovanja (engl. e-business) dovodi do pojave ERP II ili proirenih ERP sustava (engl. Extended ERP) koji su na tritu prisutni zadnjih deset godina. Bitna novina je uvoenje novog web aplikacijskog sloja koji omoguava jo jau vezu s kupcima (narudbe, kupnja, plaanje), ali i integracija sustava potpore poslovanju koji su se u prolosti isporuivali posebno, kao to su primjerice:

sustavi za upravljanje odnosa s kupcima (engl. Customer Relations Management-CRM) automatizirana prodaja (engl. Sales Force AutomationSFA) napredno poslovno planiranje (engl. Advanced Planning and Scheduling-APS) sustavi za upravljanje lancem nabave (engl. Supply Chain Management-SCM) rudarenje podataka (engl. Data Mining-DM) prekopavanje podataka (engl. Data Warehousing-DW)

2.2.

Arhitektura ERP sustava

Arhitektura ERP sustava se zasniva na modelu klijent-posluitelj (engl. client/server) sa slike 2.1. Ovakva arhitektura omoguava jednostavnu distribuciju sustava na vie raunala i jednostavno dodavanje novih ili izmjene postojeih posluitelja. Kod ERP sustava su posluitelji obino smjeteni na jednoj centralnoj lokaciji, a klijenti su raireni na vie poslovnih lokacija. Ovakva arhitektura se moe uvoditi dvoslojno (engl. two tier) i troslojno (engl. three tier). Kod dvoslojne arhitekture posluitelj upravlja podatkovnim i aplikacijskim slojem, a klijent upravlja korisnikim sueljem i slanjem podataka prema posluitelju (npr. Microsoft tako isporuuje svoj Dynamics ERP u tzv. AX verziji). U troslojnoj arhitekturi se izvode podatkovni, aplikacijski i prezentacijski sloj. Klijent alje upit ili podatke aplikativnom posluitelju koji ih obrauje i prosljeuje podatkovnom posluitelju. Ovakve izvedbe su tipine kod velikih ERP instalacija iako nisu rijetke kombinacije dvoslojne (npr. za sve korisnike koji obavljaju vei unos podataka) i troslojne arhitekture (kupci, zaposlenici koji pristupaju poslovnim izvjetajima i sl.). Primjer izvoenja troslojne arhitekture u ERP sustavu je prikazan na slici 2.2.

Spremite podataka se kod ERP sustava uvijek izvodi na jednoj bazi podataka bez obzira na stvarni broj posluitelja.

KLIJENT 1

KLIJENT 2 MREA

KLIJENT 3

POSLUITELJ 1 POSLUITELJ 2

Slika 2.1 Arhitektura klijent-posluitelj

Klijenti 1. sloj

Aplikacijski posluitelj 2. sloj

Baza podataka 3. sloj

LAN / WAN

Slika 2.1 Troslojna arhitektura

Prilikom uvoenja odabranog ERP sustava tvrtke odabiru podruja poslovanja koja ele podrati. Svako podruje poslovanja je pokriveno odgovarajuim programskim modulima. Najei moduli s podranim poslovnim procesima kod ERP sustava (u nastavku su kao primjer navedeni i nazivi odgovarajuih SAP/R3 modula na engleskom jeziku) su: Financijsko raunovodstvo (engl. Financial Accounting, Fixed Asset management) upravljanje glavnom knjigom financijski izvjetaji (bilanca, raun dobiti i gubitka, statisitki izvjetaji...) analitika kupaca analitika dobavljaa raunovodstvo dugotrajne imovine raunovodstvo zaliha porezno raunovodstvo obraun kamata blagajniko poslovanje raunovodstvo trokovnih centara raunovodstvo profitnih centara raunovodstvo internih naloga raunovodstvo profitabilnosti maloprodaja veleprodaja ugovorna praenja (limiti, krediti, popusti...) izdavanja rauna, otpremnica prodajne aktivnosti (ponude, predrauni...) meuskladinice obrada narudbenica primke robe i materijala ovjera rauna (likvidacija) upravljanje ugovorima 8

Upravljako raunovodstvo (engl. Controlling)

Prodaja i distribucija (engl. Sales and Distribution)

Nabava, skladitenje i logistika (engl. Material Management)

upravljanje zalihama i skladitem, ukljuujui inventuru i fiziki promet robe.

Upravljanje ljudskim potencijalima (engl. Human Resources) kadrovska evidencija obraun plaa planiranje proizvodnje izvrenje proizvodnje proizvodnja po narudbi procesna proizvodnja ispitivanje kvalitete odravanje

Proizvodnja (engl. Production Planning, Workflow, Industry Solutions)

Upravljanje kvalitetom (engl. Quality Management, Plant Maintance)

2.3.

Proizvoai ERP sustava na svjetskom tritu

Prema istraivanju provedenom za 2010. godinu [30], svjetsko trite ERP sustava se moe podijeliti prema ERP proizvoaima koji dre veinske trine udjele po odreenim grupama korisnika iz tablice 2.1. Tablica 2.1 Kategorizacija ERP proizvoaa prema ciljanim grupama korisnika Ukupni prihod korisnika 5-100 mil. USD 100 mil.-1 mlrd. USD >1 mlrd. USD Broj Broj djelatnika zaposlenih koji koriste kod ERP kod korisnika korisnika <100 100-500 >500 <30 30-250 >250

Grupa Ciljana grupa korisnika proizvoaa Mala poduzea (engl. Small and Medium Bussineses SMB) Srednja poduzea Velika poduzea

Grupa3 Grupa2 Grupa1

Vaniji svjetski proizvoai su navedeni u tablici 2.2 uz kategorizaciju iz tablice 2.1 prema. Podjela iz tablice 2.1 moda nije dovoljno detaljna za Grupu3 sukladno preporukama Europske unije [56], tj. nisu ukljuena tzv. mikropoduzea (engl. microenterprises) s ukupnim

prihodom manjim od 5 mil. USD, ali prema [31] je udjel ERP instalacija kod takvih korisnika jo uvijek zanemariv na globalnoj razini. Tablica 2.2 Vaniji svjetski proizvoai prema kategorizaciji iz tablice 2.1 Grupa1 SAP Oracle Oracle eBusiness Suite Oracle JD Edwards Oracle Peoplesoft Microsoft Dynamics Grupa2 Epicor Sage Infor IFS QAD Lawson CDC Software Grupa3 ABAS Activant Solutions Inc. Bowen and Groves Compiere Exact NetsSuite Visibility CGS Exact HansaWorld Consona Syspro

Tvrtka SAP AG (njem. Systeme, Anwendungen und Produkte in Datenverabeitung, engl. Systems, Applications and Products in Data Processing) je osnovana 1972.godine u Njemakoj. Prvi MRP sustav pod nazivom SAP R/2 tvrtka je predstavila 1972. Sustav je pristupao jednoj bazi podataka i upravljao je proizvodnjom. ERP sustav SAP R/3 s klijent/server tehnologijom je predstavljen 1992. godine kada poinje njegovo naglo irenje na svjetskom tritu. SAP 1999. godine predstavlja koncept proirenog ERP sustava s prije spomenutim CRM, SCM, SFA i DW dijelovima. Tvrtka Oracle je osnovana 1977. godine u SAD-u i bavi se proizvodnjom razliitih sustava programske podrke. Tvrtka je svoj prvi ERP sustav isporuila 1987. godine pod nazivom Oracle Applications koji je do danas doivio razliita proirenja. Glavna znaajka Oracle ERP rjeenja je sustav za upravljanje bazom podataka (engl. Database Management System DBMS) kojeg esto koriste i ostali proizvoai ERP sustava. Oracle je svoj trini udjel znatno poveao preuzimanjem velikih proizvoaa ERP sustava PeopleSoft, J.D.Edwards&CO i Siebel Systems 2005. godine. Ovo preuzimanje je jedno od najskupljih u podruju informacijskih tehnologija (25 mlrd. USD), ali je i dva puta zaustavljano od strane regulatornih tijela u SAD-u i EU zbog velikog utjecaja na trite. Tvrtka planira isporuku jedinstvenog rjeenja (razvoj je zavren 2010. godine) pod nazivom Oracle Fusion 10

Applications koja bi dodatno integrirala sva preuzeta ERP rjeenja (PeopleSoft, OneWorld, Siebel) s Oracle Applications na jednoj platformi. Microsoft ulazi na trite ERP sustava 2002. godine nakon kupovine tvrtki Navision A/S i Great Plains. Postojeim ERP rjeenjima dodaje svoj CRM sustav i 2005. godine zapoinje s isporukom Dynamics ERP rjeenja. Iako je Dynamics ERP poetno zamiljen kao rjeenje za SMB dio trita, Microsoft danas biljei rast udjela u instalacijama kod velikih korisnika. Jedan od razloga velike popularnosti ovog sustava je jednostavna prilagodba razliitim kupcima koritenjem ugraenog C/AL programskog jezika (engl. Client/server Application Language). U [30] je napravljena neto detaljnija podjela trinih udjela pojedinih proizvoaa prema ukupnom prihodu korisnika koja je prikazana na slici 2.1. Vidljivo je kako kod velikih tvrtki prevladavaju dva proizvoaa iz Grupe1 (SAP, Oracle). Veliki proizvoai iz Grupe1 danas pokuavaju osvojiti dio trita malih tvrtki ponudom svojih ERP proizvoda koji su se dokazali u najveim poslovnim sustavima, ali u bitno jeftinijoj verziji i oienoj od funkcionalnosti koje nisu potrebne manjim poslovnim sustavima. Kupovina takvih proizvoda je povoljna i za male tvrtke jer lako mogu nadograditi takav sustav u sluaju veeg poslovnog rasta. Prema razdiobi sa slike 2.3 takvu strategiju vrlo uspjeno provode tri proizvoaa iz Grupe1 (SAP, Oracle, Microsoft).

50,0% 45,0% 40,0% 35,0% 30,0% 25,0% 20,0% 15,0% 10,0% 5,0% 0,0% <25 mil.USD 25 mil.-50 mil.USD 50 mil.-100 mil.USD 100 mil.-500 mil.USD 500 mil.-1 mlrd.USD
4,2% 23,0% 22,3% 16,3% 11,9% 17,6% 15,7% 13,7% 28,4% 26,6% 24,5% 23,1% 16,8% 19,8% 16,7% 16,7% 11,5% 15,3% 16,8% 16,7% 14,6% 32,1% 31,3% 33,3% 31,3%

47,0%

31,8%

SAP ORACLE Microsoft Rang2

8,6% 8,6% 4,0%

Rang3 i ostali

>1 mlrd.USD

Slika 2.3 Podjela svjetskog trita po proizvoaima, prema prihodima korisnika

11

2.4.

ivotni ciklus ERP sustava

ERP sustavi predstavljaju standardne programske proizvode koji se prilagoavaju potrebama odreenog kupca. Budui kupovina takvih sustava najee predstavlja vrlo znaajan troak za poduzea koja ih planiraju uvesti, preporua se procjena isplativosti ponuenih rjeenja. Zbog sloenosti i veliine ERP sustava, njihova procjena je vrlo sloen zadatak i u zadnjem desetljeu su provedena odreena istraivanja u svijetu i RH [2] koja bi kupcu trebala olakati poetni odabir sustava. Pri tome se najee primjenjuju razliitih obrasci za formiranje zahtjeva za ponudu (engl. Request For Proposal RFP) koji se onda naknadno boduju prema ponuenim rjeenjima. Dovrenost ERP sustava i velik broj primjena su glavni motiv tvrtkama koje se odluuju za njihovo uvoenje. Zato je njihov ivotni ciklus specifian i moe se najjednostavnije opisati sa est glavnih dijelova: implementacija faza 1 implementacija faza 2 proirenje vrijednosti (engl. extended value) odravanje vrijednosti (engl. maintainig value) slabljenje vrijednosti (engl. declining value)

U prvoj fazi implementacije kupac odabire partnera za konzultacije po pitanju uvoenja odabranog ERP rjeenja. Nakon toga se pristupa detaljnijoj implementaciji koja je naee standardizirana od strane proizvoaa sustava. Primjerice, SAP primjenjuje tzv. ASAP metodologiju (engl. Accelerated SAP) koja se sastoji od: planiranje projekta (engl. Project Planning) odreuje se to nedostaje od funkcionalnosti i kako to rijeiti poslovni projekt (engl. Business Blueprint) odreuju se poslovni procesi koji e biti podrani izvedba (engl. Realization) izrada prilagodbi na razvojnom sustavu, u skladu sa specifikacijom, konzultanti provjeravaju prilagodbe i rjeavaju nejasnoe u poslovnoj domeni zavrna priprema (engl. Final Preparation) provjera rada s pravim podacima, obuka bitnih korisnika po modulima putanje u rad (engl. Going Live) i podrka izrada dokumentacije, po odobrenju kupca sustav se puta u rad 12

U drugoj fazi implementacije sustav se stabilizira. Kupac sustava u ovoj fazi moe odustati od odabranog rjeenja ili promijeniti konzultantsku tvrtku ukoliko nije zadovoljan stanjem implementacije. Faza proirenja vrijednosti ima najdulje trajanje i podrazumijeva uvoenje novih funkcionalnosti u stabilizirani sustav. Poetno se uvode funkcionalnosti od kojih se privremeno odustalo tijekom implementacije. Tijekom vremena korisnici sustava poveavaju fond svog znanja o implementiranom sustavu, poinju samostalno rjeavati probleme konfiguriranja i postavljaju specifikacije za nove funkcionalnosti ili optimiranje postojeih. Skup uvoenja svih novih funkcionalnosti se u ovoj fazi najee dodatno ugovara kroz perfektivno odravanje. U konanici se sustav potpuno stabilizira sa svim proirenjima i poinje faza odravanja vrijednosti u kojoj se sustav odrava uglavnom adaptivno (prilagodbe na nove tehnologije npr. mobilne platforme) i korektivno (najee su to prilagodbe novim zakonskim propisima). Kupci se najee odluuju na prelazak u ovu fazu zbog smanjenja ukupnih trokova poslovanja. U narednom periodu sustav ulazi u fazu opadanja vrijednosti. Tvrtke najee ne ele vie ulagati u bitne izmjene postojeeg sustava koje su nune zbog novih tehnologija i izmjena u poslovanju jer procjenjuju da je to neisplativo. Ulau se samo minimalna sredstva kroz korektivno odravanje. U konanici sustav postaje neupotrebljiv i tvrtka poinje razmiljati o zamjeni postojeeg sustava.

2.5.

Podeavanje i prilagodba ERP sustava poslovanju korisnika

Pretpostavlja se kako je dobar ERP sustav izraen u skladu s najboljim postojeim postupcima upravljanja resursima poduzea koje ga eli primijeniti [3], tj. da proizvoa sustava ulae odreeni napor kako bi te postupke primijenio na najefikasniji nain u isporuenim funkcionalnostima sustava. Uvoenje najboljih poslovnih procesa je esto i dodatna motivacija kupcima kako bi primijenili neki ERP sustav u namjeri unaprjeenja i poboljanja svoga poslovanja. Uobiajeno je praenje meunarodnog raunovodstvenog standarda (engl. International Financial Reporting StandardsIFRS, o emu je vie mogue pronai na [32]), a u SAD su takve norme ak propisane zakonom (SarbanesOxley act iz 2002. godine, detaljnije opisan na [33]). Na ERP sustave u bankarstvu se primjenjuju odredbe iz tzv. Basel II norme dostupne na [34]. Osim toga u izradi ERP sustava se, ovisno o podruju 13

primjene, uvaavaju i razliite ISO preporuke [40], [41] za oblikovanje poslovnih procesa. Takoer se moe rei kako u ERP sustavu ugraene funkcionalnosti ne moraju biti do kraja definirane, odnosno podrazumijeva se da ih potencijalni kupac moe na razliite naine prilagoavati svojim poslovnim procesima. Postoje razliiti naini prilagodbe ERP rjeenja nekom poslovanju koji esto obuhvaaju vie slojeva unutar postojeeg informacijskog sustava. U veini sluajeva to rade tvrtke specijalizirane za vie tehnologija koje su nune u uvoenju ERP rjeenja i obino se takve tvrtke bave sistemskom integracijom (engl. system integration) koja podrazumijeva vei broj specijalista u razliitim podrujima informatike tehnologije (mrene tehnologije, baze podataka, operacijski sustavi), ali i eksperte za razliita podruja poslovanja (raunovodstvo, ljudski resursi, proizvodnja itd.). Uvoenje nekog ERP rjeenja u jednostavnijim sluajevima znai samo parametrizaciju postojeeg ERP sustava (npr. izmjena kontnog plana, izgleda dokumenata, naina obrauna utroka robe i materijala, parametara za povezivanje s perifernim ureajima itd.), a u sloenijim sluajevima moe znaiti i direktnu integraciju s proizvodnim postrojenjima korisnika, integraciju s bazama podataka i informacijskim sustavima drugih proizvoaa, izradu posebnih komunikacijskih modula za spajanje s opremom i sustavima drugih proizvoaa. U najsloenijim uvoenjima ERP sustava je potrebno izraditi programske module koji se rade samo za odreenog korisnika i za njegove posebne poslovne procese. Vrlo esto uvoenje ERP rjeenja predstavlja znaajne izmjene poslovnih procesa i navika kod poslovne organizacije koja to rjeenje uvodi [35]. Kljuan korak u pripremi uvoenja bilo kojeg ERP sustava je detaljna analiza svih postojeih poslovnih procesa [19]. Korisnik tada moe popisati i analizirati svoje poslovne procese, modernizirati ih i pokuati ih prilagoditi ERP sustavu gdje je to mogue. Korisnici su ponekad uvjereni kako je njihovo poslovanje najbolje mogue i ukoliko se ne moe primijeniti oni u ponuenom ERP rjeenju trae bitne izmjene u nekom od postojeih ERP modula. Ponekad je ovakav stav korisnika razuman, naroito ako je postojee poslovanje uspjeno i korisnik doista posjeduje poslovno znanje koje ga bitno izdvaja na tritu te mu na odreeni nain donosi prednost u odnosu na konkurenciju. Ukoliko se nain poslovanja ipak eli promijeniti zbog lake prilagodbe odabranom ERP sustavu, korisnik mora biti svjestan rizika i moguih poslovnih gubitaka iako se podrazumijeva usklaenost odabranog ERP sustava s priznatim normama kvalitetnog poslovanja. U tom procesu je nuno korisniku pruiti usluge poslovnog savjetovanja, prilagodbu ERP rjeenja poslovnim procesima i korisniku podrku prilikom uvoenja i 14

naknadnog odravanja. Uvoenje ERP rjeenja moe kod velikih poslovnih sustava potrajati prosjeno vie od godine dana uz angairanje vie od 100 konzultanata, a kod instalacija za srednje i male korisnike koje moe trajati bitno krae [35]. Prilagodba postojeih modula za novog korisnika najee znai dodavanje novih funkcionalnosti i najvie utjee na konano vrijeme implementacije. Bitno je razlikovati konfiguriranje i parametrizaciju nekog ERP sustava u odnosu na njegovu prilagodbu odreenom korisniku. Konfiguriranje znai postavljanje parametara prema postojeim funkcionalnostima koje se ve ugraene u sustav (npr. postavke automatskih knjienja, razliite grupne obrade itd.). Prilagodba korisniku u pravilu podrazumijeva izmjene prema zahtjevu korisnika sa svrhom podrke poslovnim procesima koji ne postoje u aktualnoj verziji sustava. Primjerice, najvei svjetski proizvoa ERP sustava SAP raspolae vlastitim programskim jezikom ABAP (Advanced Business Application Programming) za razvoj i prilagodbu sustava. Konfiguriranje ERP sustava se podrazumijeva, a prilagodba ERP sustava je mogunost za koju se kupac moe i ne mora odluiti. Izmjene konfiguracije ne bi trebale utjecati na pouzdanost itavog sustava, tj. smatra se da sustav mora pouzdano raditi ako je ispravno konfiguriran.Izmjena konfiguracije bi morala rezultirati predvidljivim ponaanjem sustava, a svi defekti koji nastaju kao posljedica takvog dogaaja su odgovornost proizvoaa sustava. Kod prilagodbe ERP sustava odreenom kupcu to ne mora biti sluaj i u veini sluajeva veim dijelom predstavlja rizik kupca. Za proizvoaa to predstavlja dodatan rizik u razvoju i nuno uvodi dodatne provjere jer ako se sustav mijenja za druge kupce, tada se mora uloiti dodatni napor prilikom provjere kako prilagodba za odreenog kupca ne bi bila ugroena. Postojee konfiguracije sustava moraju biti sauvane u sluaju bilo kakve nadogradnje ERP sustava. Prilagodba sustava odreenom korisniku ima svoje prednosti, ali i nedostatke. Najvee prednosti su lake pridobivanje novih i zadravanje postojeih korisnika te openito prednost u odnosu na konkurenciju koja svoje ERP sustave nudi sa standardnim funkcionalnostima. Glavni nedostatak je dodatni napor u razvoju prilikom bilo kakvih redovnih nadogradnji sustava jer se tada takve prilagodbe moraju dodatno provjeravati. Ukoliko je takvih prilagodbi puno tada se vrijeme testiranja sustava naglo poveava [20]. Na slici 2.4 je prikazano koliko se kupaca prema studiji [30] odluilo prilagoavati ERP produkte svom poslovanju i u kojem obujmu. Iz slike je vidljivo da se manji broj kupaca odluio za veu ili potpunu prilagodbu. Gotovo polovica kupaca se odluila na manje prilagodbe, a manji broj kupaca uope nije traio prilagodbe. Ovakav rezultat se moe 15

objasniti injenicom kako prilagodba nuno produljuje vrijeme isporuke i donosi nove trokove pa se korisnici teko odluuju na takav rizik. Prilagodbe ERP sustava su oito potrebne u nekom manjem obimu jer je veina tvrtki mijenjala ili dodavala funkcionalnosti, ali oito samo ono to je doista nuno i u konanici isplativo. Na slici 2.5 su prikazani rezultati iz [30] s prikazom izvrenih prilagodbi prema razliitim proizvoaima ERP sustava. Oito je kako se tvrtke male i srednje veliine koje uglavnom kupuju ERP produkte iz kategorije Grupa2 i Grupa3 (prema podjeli iz tablice 2.2) u sluaju izmjena odluuju uglavnom na manje prilagodbe. Takoer je oekivan rezultat kod malih tvrtki koje uglavnom kupuju ERP proizvode iz grupe Grupa3, odnosno prema slici 2.6 velik broj takvih kupaca ne mijenja nita ili obavlja samo male izmjene.

Nema prilagodbi

28,3%
47,8% 19,4% 4,4%
0% 10% 20% 30% 40% 50% 60%

Prilagoen u manjem dijelu

Prilagoavan veim dijelom

Potpuna prilagoba poslovanju kupca

Slika 2.4 Udjeli razliitih prilagodbi za nove instalacije ERP sustava

80% 70% 60% 50% 40% 30% 20% 10% 0%

5% 3% 6% 3% 29% 21% 25% 25% 45% 47% 42% 37% 43% 38% 69%

Potpuna prilagoba poslovanju kupca Prilagoavan veim dijelom Prilagoen u manjem dijelu

21%

22% 12% 7%

0%

SAP

ORACLE

Microsoft

Rang2

Rang3

Slika 2.5 Udjeli razliitih prilagodbi po proizvoaima za nove instalacije ERP sustava 16

2.6.

Glavne prednosti i nedostaci ERP sustava

Glavne prednosti ERP sustava su: iroko podruje primjene zbog velikog broja instalacija u razliitim poslovnim domenama pokriven je veliki broj poslovnih procesa i podruja poslovanja razliiti naini uvoenja mogu se uvesti brzim postupcima (engl. bing-bang implementation), ali i neto sporije s poetno manjim brojem podruja poslovanja (npr. samo financije i upravljanje ljudskim potencijalima) nakon ega se sustav postupno nadograuje gotovi predloci za instalaciju proizvoai unaprijed predefiniraju sustav za odreeni tip poslovanja to omoguava jednostavan i brz poetak rada jednostavno povezivanje s drugim sustavima realizirani su na najnovijim tehnologijama za izradu programske podrke, imaju predefinirana suelja za povezivanje s programskom podrkom drugih proizvoaa jedna baza podataka nema sinkronizacija i pozadinskih obrada koje su tipine za starije sustave, podacima se pristupa u realnom vremenu s vie razliitih lokacija, tonije i bre izvjetavanje velika koliina poslovnih izvjetaja ERP sustavi u osnovnoj verziji raspolau velikom koliinom izvjetaja koje je mogue jednostavno podesiti i iz njih podatke izvoziti u druge standardne uredske formate (MS Excel, MS Word itd.) korisnika podrka uporaba razliitih baza znanja, modernih komunikacijskih alata za povezivanje na korisniko raunalo Glavni nedostaci ERP sustava su: poetno ulaganje predstavlja samo manji dio ukupnih trokova slijede visoki trokovi kasnijih prilagodbi i odravanja sloeno koritenje i krutost u radu zbog velikog broja gotovih funkcionalnosti postaju nepregledni sloeno odravanje vrlo sloeni informacijski sustavi koji trae specijaliste u razliitim podrujima (administratori baza podataka, poslovni eksperti, specijalisti za informacijsku sigurnost i mrene tehnologije itd.)

17

veliko optereenje centralne baze podataka dodatni trokovi na sustavima poslovne inteligencije (engl. business intelligenceBI) zbog realizacije naprednih izvjetaja i poslovnih analiza kako bi se izbjeglo dodatno optereenje i usporavanje unosa podataka

visoki operativni rizik veliki poslovni gubici zbog pogreaka i prekida u radu

2.7.

Praenje defekata u ERP sustavima

Iako ne postoji ope prihvaena definicija za programski kvar, pogreku ili neispra vnost, mogu se koristiti definicije [60]: programska pogreka (engl. software error) je posljedica propusta razvijatelja programske podrke (engl. software developer) uinjenog tijekom programiranja (engl. programming process) neispravnost programske podrke (engl. software fault) je posljedica programske pogreke programski zastoj (engl. software failure) se dogaa kada neispravnost programske podrke ometa rad programa unutar zadanih granica U ovom doktorskom radu se koristi proirena definicija neispravnosti programske podrke pod nazivom defekt (engl. defect) koja je bolje prilagoena modeliranju pouzdanosti ERP sustava. Pojmovi poput programske pogreke, neispravnosti i zastoja (kvara) su prikladni za opisivanje pouzdanosti veine programskih proizvoda, ali se u stvarnom ivotu problemi u koritenju nekog ERP sustava dogaaju i van takvih definicija. Tipian primjer je kada korisnik prijavljuje problem uvjeren da je rije o neispravnosti programskog modula, a naknadnom analizom se utvruje da je uzrok krivo koritenje od strane korisnika uslijed razliitih razloga (npr. nedostatak obuke, detaljnijih uputa za rad i sl.). Stoga se u nastavku ovog rada koristi iskljuivo pojam defekt jer obuhvaa sve pojave kod kojih je nuno mijenjati bilo to u vezi izrade ili koritenja instaliranog programskog proizvoda. Ovakva definicija je na tragu ODC metode (engl. Ortogonal Defect Classification) koju je razvio IBM [9]. Uzroci defekata (npr. SAP [57] i IBM [9] koriste engl. pojam root cause) mogu biti razliiti i nastajati u razliitim fazama razvoja programske podrke. U kontekstu ERP sustava prikladno je razmotriti razliite faze ivotnog ciklusa koje su detaljnije opisane u poglavlju

18

2.4. Primjerice, uzrok pojave defekata u ERP sustavu e sigurno biti razliit u prvoj implementacijskoj fazi u odnosu na fazu odravanja vrijednosti. Postoje razliiti sustavi koji slue za biljeenje defekata i obino su izvedeni kao web aplikacije. U takvim sustavima je mogue pratiti itav ivotni ciklus d efekta od trenutka prijave problema do uklanjanja iz sustava. Obino se takav proces naziva engl. issue tracking, a tehniki sustav koji ga podrava engl. issue tracking system. Razliiti proizvoai razliito nazivaju vlastite sustave s ovakvom namjenom (nrp. SAP koristi naziv Service Desk [58]). Pojednostavljeni radni slijed (engl. workflow) u takvim sustavima je prikazan na slici 2.5.

Problem

Provjera

Nije defekt ili je defekt koji uzrokuje problem ve prijavljen

Defekt

Tip

Dokumentacija

Konfiguracija

Poslovni proces

Programska podrka

....

Ispravak, dostava dokumentacije

Promjena konfiguracije

Izmjena poslovnog procesa

Ispravak, provjera, nova verzija

....

Zatvaranje problema

Slika 2.4 Pojednostavljeni prikaz procesa rjeavanja prijavljenih problema u ERP sustavu

19

Unutar takvog sustava korisnik u prvom koraku poetno unosi podatke o uoenom pogrenom radu sustava, najee s atributima detaljnije opisanima u [58]: kratki opis problema hitnost (engl. priority) utjecaj na poslovanje (engl. severity) verzija ERP sustava verzija ERP modula puni opis problema prilozi (engl. attachment) dokumenti koji detaljnije opisuju problem

Sustav automatski biljei vrijeme, tvrtku korisnika i kontakt osobu koja je prijavila problem. U slijedeem koraku se vri analiza prijavljenog p roblema (engl. root cause analysis) i on dobiva atribute: osoba unutar tvrtke isporuitelja koja rjeava prijavljeni problem razlog problema

Razlog prijavljenog problema moe biti neispravnost programske podrke ili neto drugo npr. neispravna konfiguracija, loa dokumentacija, pogreno koritenje, neispravno suelje na drugim sustavima, neispravna struktura podataka itd. Moe se rei da je u t renutku otkrivanja razloga problema utvren defekt u sustavu i da je potrebno poduzeti mjere koje e ga ukloniti. U sustavu ne moe biti vie istih defekata, odnosno moe biti vie prijavljenih problema koji nastaju uslijed istog defekta (npr. ako se radi o neispravnosti programske podrke). Defekt ne mora kao posljedicu imati izmjenu programske podrke (npr. ERP modul je pogreno konfiguriran). Odluku o tome da li je neto defekt donosi osoba kojoj je prijavljeni problem dodijeljen na rjeavanje. U takvom postupku je mogue provjeriti odreene baze znanja koje su dostupne unutar sustava za upravljanje problemima na korisnikovoj lokaciji (npr. SAP Solution Manager), na bazi dostupnoj svim korisnicima (npr. SAP Market Place) ili kod proizvoaa sustava. Ako je defekt utvren kao neispravnost programske podrke, prosljeuje se razvojnom timu na rjeavanje. U ovom sluaju je oito potrebno mijenjati programsku podrku i kupcu isporuiti ispravnu verziju (engl. software release). Sukladno prijavljenoj hitnosti moe se odmah isporuiti nova verzija sustava ili se ispravak isporuuje u slijedeoj redovnoj verziji. Praenje ispravka pogreke programske podrke (engl. bug tracking) se najee obavlja unutar sustava za prijavu problema koji preuzima podatke o prijavljenom defektu, biljei 20

komunikaciju unutar razvojnog tima i alje obavijest korisniku kada je nova verzija spremna za isporuku. U sluaju kada se sadraj programske podrke ne mijenja, poduzimaju se korektivne akcije koje uklanjaju defekt izmjenama naina koritenja sustava, o emu se pravodobno obavjetava korisnika (ispravno konfiguriranje, ispravak dokumentacije itd.).

21

3. Modeliranje pouzdanosti programske podrke

Modeliranje pouzdanosti (engl. reliability modelling) je vrlo znaajno inenjersko podruje koje nalazi primjenu u razliitim tehnikim sustavima. U podruju programskog inenjerstva (engl. software engineering) pojam pouzdanosti programske podrke (engl. software reliability) se uvodi poetkom 60-tih godina prolog stoljea s namjerom projektiranja sustava programske podrke otpornog na pogreke. Nakon toga se razvijaju razliiti matematiki modeli prilagoeni modeliranju pouzdanosti programske podrke (engl. software reliability modeling). Danas se pouzdanost programske podrke, uz efikasnost (engl. software efficiency), sigurnost (engl. software security) i odrivost (engl. software maintainability) smatra najbitnijim dijelom kvalitete programske podrke (engl. software quality) podrane od razliitih neovisnih organizacija kao to su Consortium for IT Software Quality (CISQ) [37], Software Engineering Institute (SEI) [38] i Object Management Group (OMG) [39]. Pouzdanost programske podrke je opisana i unutar dijelova standarda ISO 9126-3 [40] i ISO 25000:2005 [41]. Klasifikacija nepravilnosti u programskoj podrci (engl. software anomalies) je opisana unutar IEEE standarda 1044-2009 [59]. Neto starije definicije i podjela nepravilnosti u programskoj podrci su razvijene od strane velikih proizvoaa programske podrke kao to su HP [58] i IBM [9].

3.1.

Osnovne definicije

Pouzdanost programske podrke se definira kao vjerojatnost rada sustava programske podrke bez pogreke u odreenom vremenskom periodu i odreenim radnim uvjetima [21]. Od samih poetaka modeliranja pouzdanosti programske podrke, utvreno je [8]: programska podrka se ne troi ili unitava prilikom koritenja programska podrka doivljava vie nadogradnji na istoj opremi popravci otkrivenih greaka na programskoj podrci mogu uzrokovati nove, neplanirane pogreke testiranje e biti nepotpunije to je kompleksnost programske podrke vea programska podrka trai drugaije tehnike u postizanju otpornosti na pogreke od onih koje se primjenjuju kod strojne podrke Uzroci defekata u izradi programske podrke su najee [8]: nepotpuna ili neodgovarajua specifikacija zahtjeva (engl. requirement specification) 22

nepotpuna ili neodgovarajua projektna specifikacija (engl. design document) pogreke u pisanju programskog koda (engl. errors in program coding) nepotpuna provjera neodgovarajui popravci otkrivenih pogreaka

U izradi visoko pouzdanog programskog proizvoda se podrazumijevaju etiri aktivnosti [9]: prevencija defekata (engl. defect prevention) u procesima dizajna , izrade i implementacije sustava programske podrke uklanjanje neispravnosti (engl. defect removal) u svim fazama razvoja s naglaskom na postupcima provjere predvianje pojave defekata (engl. defect forecasting) opcionalno- za najzahtjevnije sustave: zalihost (engl. fault tolerance)

3.2.

Opi model pouzdanosti

Ocjena pouzdanosti se moe utvrditi za neku komponentu sustava ili za neki ureaj na temelju prikupljenih podataka o velikom broju istovrsnih komponenata, odnosno ureaja. Pouzdanost (engl. reliability) vremenskom intervalu [ nekog dijela sustava je vjerojatnost da se on u zadanom

] nalazi u ispravnom stanju [8]. nekog dijela sustava je vjerojatnost da se on u ] nalazi u stanju kvara [8]. Zbroj pouzdanosti i

Nepouzdanost (engl. unreliability) zadanom vremenskom intervalu [

nepouzdanosti nekog sustava u svakom trenutku je 1, kao na slici 3.1. (3-1) Kljune funkcije koje opisuju stanje kvara su: - funkcija gustoe vjerojatnosti kvarenja (engl. probability density of failure) - ukupna vjerojatnost kvarenja (engl. cumulative failure probability) brzina kvarenja (engl. failure rate) se rauna kao: (3-2) Funkcija gustoe vjerojatnosti kvarenja [42] se definira kao: 23

Vjerojatnost da e se kvar dogoditi u intervalu

(3-3) Brzina kvarenja (t) se prikazuje [42] kao:

(3-4)

Povezivanjem formula (3.2) i (3.3) moe se pisati opa formula pouzdanosti [42] kao: (3-5)
1 0,8 0,6 0,4 0,2 0 1 t R(t) Q(t)

Slika 3.1 Odnos pouzdanosti i nepouzdanosti sustava

Prosjeno vrijeme do pojave kvara (mean time to failure) se definira kao [42]: MTTF = (3-6)

Sukladno formulama (3-3) i (3-4) funkcija gustoe vjerojatnosti kvarenja je kljuna za konani oblik funkcija brzine kvarenja i ukupne vjerojatnosti kvarenja nekog tehnikog sustava. U najjednostavnijem sluaju moe se oekivati stalna vrijednost i jednostavna rjeenja za (3-4) i (3-5). U sloenijim sluajevima funkcija opisuje za promatrani period. moe imati razliite oblike i tada se odabire prikladan model pouzdanosti, ovisno o statistikoj razdiobi koja najbolje

3.3.

Pregled modela pouzdanosti programske podrke

Postoji vie razliitih modela pouzdanosti koji su prikladni za opisivanje pouzdanosti programske podrke, a obino se dijele prema klasifikacijskoj shemi koja je opisana s pet atributa [9]: vremenska domena stvarno vrijeme, vrijeme izvravanja programa 24

kategorija konaan ili neogranien (prema broju neispravnosti u beskonanom vremenu) tip podrazumijeva tip statistike razdiobe koja najbolje opisuje pojavu neispravnosti u stvarnom sustavu (prevladavaju dvije vane razdiobe: Poissonova i binomna)

razred (samo za konane modele) uestalost pojave defekata je opisana kao vremenska funkcija porodica (samo za beskonane modele) uestalost pojave defekata se opisuje kroz oekivani broj defekata u budunosti

Kod modeliranja pouzdanosti strojne opreme, brzina kvarenja (t) se obino aproksimira konstantnom veliinom i proizvoa opreme je moe iskazati za najgori mogui sluaj temeljem testiranja ispravnosti dijelova prilikom proizvodnje. Na taj nain je mogue raunati pouzdanost velikog sustava raunanjem doprinosa pouzdanosti pojedinih dijelova, na temelju iskazane brzine kvarenja pojedinih dijelova. Meutim, u stvarnosti se pokazalo da ovakav pristup nije idealan u modeliranju pouzdanosti programske podrke, tj. brzina pojave neispravnosti u koritenju pojedinog programskog modula nema uvijek stalnu vrijednost [10]. Krajem osamdesetih godina J.D. Musa predlae tri osnovna tipa modela, ovisno o uoenoj funkciji brzine pojave defekata: nepromjenljiv (engl. static) brzina pojave defekata je stalna osnovni (engl. basic) brzina pojave defekata je eksponencijalno padajua funkcija: (3-7) logaritamski Poisson (engl. logarithmic Poisson) brzina pojave defekata je padajua funkcija: (3-8) Niz autora je razvio vlastite modele pouzdanosti programske podrke koji polaze od pretpostavke da je brzina pojave defekata eksponencijalna funkcija, a najpoznatiji su: Jelinski-Moranda, De-eutrophication Model, Nonhomogeneous Poisson Process (NHPP) Model, Schneidewinds Model, Musas Basic Execution Time Model, Hyperexponential Model. Najpoznatiji model zasnovan na logaritamskom Poisson modelu je Musa-Okumoto Logarithmic Poisson. 25

Drugi autori su istovremeno predloili uporabu binomnih statistikih modela za modeliranje brzine pojave defekata, od kojih su najpoznatiji Weibull Model i S-Shaped Reliability Growth Model. Kao poseban pristup moe se izdvojiti grupa modela koji je u modeliranju pouzdanosti programske podrke polaze od Bayesova teorema od kojih je najpoznatiji Littlewood-Verrall Reliability Growth Model. Bitno je napomenuti da eksponencijalni modeli spadaju u kategoriju konanih (broj defekata je konaan u beskonanom vremenu), a logaritamski Poisson, binomni i Bayesovi modeli u kategoriju neogranienih (broj defekata nije konaan) [8]. U ovom doktorskom radu su uoene neke pogodnosti primjene eksponencijalnog modela (Musa Basic Execution Time Model) u sluaju predvianja ukupnog broja defekata koji su ugraeni u ERP sustav tijekom prilagodbe, a kao primjer je naveden sluaj povezivanja postojeeg ERP rjeenja s drugim informacijskim sustavima [14]. Eksponencijalni model moe posluiti i u ocjeni da li je izmjena sustava sigurna za isporuku, tj. moe li provjera zavriti i uz koji rizik, odnosno moe dati procjenu koliko je jo neotkrivenih defekata u sustavu. Kao prikladan model za praenje i predvianje pouzdanosti kod isporuenih ERP sustava koji se redovno nadograuju i odravaju u ovom doktorskom radu je prikazan Weibull model, a primjeri koritenja su preuzeti iz [12], [13]. Opisani pristup je pogodan u procjeni kako se postojei ERP sustav odrava i kakav je trend pojave defekata u bliskoj budunosti.

3.4.

Eksponencijalni model pouzdanosti programske podrke

Eksponencijalni modeli pouzdanosti programske podrke polaze od pretpostavke stalnog pojavljivanja pogreaka ija se statistika raspodjela opisuje kao sluajan nehomogen (vremenski promjenljiv) Poissonov proces (engl. random nonhomogeneous Poisson process NHPP). Ako se s oznai broj defekata u trenutku t, uz pretpostavke: u trenutku t=0 broj postojeih defekata u sustavu je 0 vremenski intervali u kojima se defekti dogaaju su promjenljivi

ne postoji istovremeno pojavljivanje vie defekata brzina pojave defekata je funkcija ovisna o proteklom vremenu 26

tada sukladno definiciji Poissonovog procesa vrijedi: (3-9)

(3-10)

(3-11) Broj oekivanih greaka unutar vremenskog intervala [0,t] se moe se raunati kao: (3-12) Ukoliko je poznat ukupan broj oekivanih greaka broj greaka kao: = (3-13) i poetna brzina kvarenja , moe

se postaviti openiti izraz za raunanje brzine kvarenja, u toki u kojoj je dosegnut ukupan

Deriviranjem

prethodne :

formule

se

moe

raunati

brzina

promjene

funkcije

(3.14)

Sreivanjem (3-14) uz: (3-15) dobiva se: = Ukoliko se veliine iz (3-16) prikau kao funkcije vremena, moe se pisati: = Budui je (t) vremenski integral funkcije , slijedi: (3-18) Rjeavanjem diferencijalne jednadbe (3.18) dobiva se: 27 (3-17) (3-16)

) odnosno: =

(3-19)

(3-20)

o (t)

Slika 3.2 Brzina pojave defekata u eksponecijalnim modelima Uvrtavanjem za , moe se raunati: (3-21) Svi eksponencijalni modeli pouzdanosti programske podrke se zasnivaju na pretpostavci da vrijedi (3-20), tj. brzina pojave defekata je eksponencijalno padajua funkcija kao na slici 3.2. Najpoznatiji eksponencijalni model je tzv. Musas basic execution time model. Uz pretpostavku kako je broj ugraenih defekata u izvrenoj izmjeni sustava konaan, u navedenom modelu vrijedi: =
n n 1- e p - (tn )

(3-22) =0 + x], gdje je (3-23) vrijeme u kojem je uoen predstavlja ukupan

Navedeni izrazi se raunaju za vrijeme [0,

zadnji defekt, a ukupan broj otkrivenih defekata za [0, ispravljeni prilikom validacije.

] je n. Oznaka

broj defekata u isporuenoj prilagodbi koji bi u idealnom sluaju trebali biti uoeni i

Rjeavanjem sustava jednadbi (3-22) i (3-23) se moe odgovoriti na dva pitanja koja su bitna proizvoau ERP sustava prilikom provjere prilagodbi postojeeg ERP sustava prije planirane isporuke korisnicima: 28

koliko se jo defekata moe oekivati u isporuenoj prilagodbi ERP sustava? moe li se planirana prilagodba isporuiti, tj. je li otkrivena veina moguih defekata u validaciji prije isporuke?

3.5.

Weibull model pouzdanosti programske podrke

U teoriji vjerojatnosti i statistici je Weibull razdioba prvi puta opisana 1929. godine [22], a iroku primjenu je dobila nakon 1951. godine [11] kada je Waloddi Weibull izloio detaljne mogunosti primjene u modeliranju pouzdanosti za tehnike sustave. Weibull model pouzdanosti programske podrke spada u tzv. binomne modele [9]. Brzina pojave defekata u sustavu se izvodi iz funkcije gustoe vjerojatnosti pojave defekata (3-24) gdje N predstavlja oekivan broj defekata u beskonanom vremenu Iz formule (3-24) je mogue kao i kod ostalih modela pouzdanosti raunati oekivani broj defekata u nekom ogranienom vremenu =N gdje je : (3-25) ) kao:

ukupna vjerojatnost pojave defekata. Sukladno definicijama Weibull razdiobe

[11] definiraju se: (3-26) (3-27) Weibull razdioba je definirana s dva parametra i . Parametar se naziva faktorom oblika (engl. shape parameter) i za neke karakteristine vrijednosti definira oblik krivulje gustoe vjerojatnosti prema formuli (3-26). Slike krivulja vrijednosti parametra uz isti parametar za karakteristine su vidljive na slikama 3.3 i 3.4. Weibull razdioba se obino naziva i parametrom raste.

prelazi u eksponencijalnu za svaki 1. Za vrijednosti >1, krivulja poprima oblik zvona (npr. poput lognormalne ili normalne razdiobe). Parametar mjere (engl. scale parameter) i definira irinu krivulje je kako uz istu vrijednost parametra , krivulja . Ako se pogleda slika 3.5 vidljivo

postaje ira ako parametar

29

0,16 0,14 0,12 0,1 0,08 0,06 0,04 0,02 0 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 =0,5 =1 =2 =5

Slika 3.3 Usporedba Weibull funkcije gustoe vjerojatnosti pojave defekata za razliite parametre oblika , uz isti parametar mjere =10

1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 =0,5 =1 =2 =5

Slika 3.4 Usporedba Weibull funkcije ukupne vjerojatnosti pojave defekata za razliite parametre oblika , uz isti parametar mjere =10

0,5 0,45 0,4 0,35 0,3 0,25 0,2 0,15 0,1 0,05 0 1 2 3 4 5 6 7 8 9 10 11 12

=4 =6 =8

Slika 3.5 Usporedba Weibull funkcije gustoe vjerojatnosti pojave defekata za razliite parametre oblika , uz isti parametar oblika =10 30

Ako se matematika svojstva Weibull razdiobe prikazana na slikama 3.3, 3.4 i 3.5 primjene na problem modeliranja pouzdanosti nekog ERP sustava, uz pretpostavku kako takva razdioba vjerno prikazuje gustou vjerojatnosti pojave defektata u tom ERP sustavu, moe se rei kako vrijede slijedee tvrdnje: ako je parametar oblika <1, tada se brzina pojave defekata u promatranom ERP sustavu s vremenom smanjuje i u konanici e svi defekti u sustavu nakon provedenih ispravaka biti uklonjeni (to je malo vjerojatan sluaj za ERP sustav jer bi to znailo sustav koji se ne mijenja, ve se u odravanju samo ispravljaju postojei defekti) ako je parametar oblika =1, Weibull razdioba prelazi u eksponencijalnu i brzina pojave defekata u promatranom ERP sustavu je stalna (vjerojatan sluaj za ERP sustav implementiran u stabilnom poslovnom i ekonomskom okruenju izmjene i prilagodbe se dogaaju, ali relativno rijetko te su dobro promiljene i ne uvode nove defekte u sustav) ako je parametar oblika >1, tada brzina pojave defekata u promatranom ERP sustavu s vremenom raste (ovo je vrlo est sluaj u dinaminom poslovnom i ekonomskom okruenju u kojem se stalno mijenja nain poslovanja, zakonodavstvo, porezne politike i sl.) za manje vrijednosti parametra mjere , tada je vremenski interval u kojem se biljei veina defekata manji (krivulja gustoe vjerojatnosti pojave defekata postaje ua)

31

4. Optimiranje izbora parametara ulaznih veliina za oblikovanje modela pouzdanosti ERP sustava
U odabiru prikladnog statistikog modela u modeliranju pouzdanosti ERP sustava nuno je raspolagati zapisima pojave defekata u sustavu. Defekte je mogue biljeiti za dio ERP sustava u fazi razvoja (engl. development phase) ili od trenutka kada ga kupac poinje koristi (engl. operational phase) u zadanim radnim uvjetima (engl. workload). Bilo kakav novi razvoj kod ERP sustava je posljedica zatraenih prilagodbi i sadri uobiajene razvojne procese kao to su: biljeenje zahtjeva (engl. requirement phase), dizajn (engl. design), izvoenje (engl. implementation), provjera (engl. verification and validation) i isporuka. Defekte je mogue biljeiti u bilo kojoj od navedenih faza i na taj nain proizvoa moe vrednovati kvalitetu vlastitog razvojnog procesa i ljudi koji u tome sudjeluju. Proizvoai obino biljee defekte prilikom provjere prilagodbe pa je postupak izrade prikladnog modela pouzdanosti iz takvih zapisa jednostavan i detaljnije opisan u [14]. Meutim, postavlja se pitanje u kojoj fazi provjere je potrebno zapoeti biljeiti defekte, tj. da li se to ini prilikom ispitivanja sastavnih dijelova prilagodbe (engl. unit test), ispitivanja povezanosti prilagodbe s ostalim dijelovima sustava (engl. integration test) ili kod provjere usklaenosti s zadanim zahtjevima (engl. system test). U literaturi [8], [9] standardima kvalitete razvoja programske podrke [41], slinim istraivanjima drugih autora [15] i razvojnim procesima nekih proizvoaa ERP sustava [43] vrijedi pravilo biljeenja defekata prilikom sistemske provjere nove verzije sustava koji je kandidat za isporuku. Danas je dostupan velik broj sustava otvorenog koda (engl. open source) namijenjenih biljeenju defekata uoenih u razvoju programske podrke koji se u literaturi esto opisuju skraenicom LBT (engl. local bug tracker). Sistemsku provjeru obino provodi neovisan tim strunjaka (engl. QA-quality assurance testers) koji nisu dio razvojnog tima pa LBT sustavi omoguavaju osim biljeenja defekta (vrijeme, vrsta, opis) i komunikaciju prema razvojnom timu (detaljan opis uvjeta u kojima defekt nastaje, dodjelu zadatka pojedinom lanu razvojnog tima i sl.). Proizvoai u pravilu prate prijavu svih defekata i nakon isporuke nove verzije sustava kroz poseban odjel korisnike podrke (engl. customer care). Najee se komunikacija s korisnikom odvija putem posebne web aplikacije (engl. help desk) u kojoj korisnik moe izvriti prijavu defekta ili pronai razliite upute i obavijesti. U izvanrednim okolnostima

32

(koje su najee ugovorno definirane) djelatnici korisnike podrke mogu izravno komunicirati s korisnikom i u njegovo ime zapisati uoeni defekt. Za bilo kakvo modeliranje pouzdanosti iz zabiljeenih defekata vrijedi proces sa slike 4.1 (engl. measurement based framework ) preuzet iz [8].
1. Obrada podataka o zabiljeenim defketima Grupirani podaci

2. Analiza prikupljenih podataka Empirijske razdiobe 3. Identifikacija prikladnog modela Model 5. Vrednovanje modela Rezultati usporedbom sa stvarnim mjerenjima

4. Primjena modela

Slika 4.1 Izbor prikladnog modela pouzdanosti ERP sustava iz prikupljenih podataka o zabiljeenim defektima

Detaljan opis prikazanog modela je naveden u slijedeim potpoglavljima.

4.1.

Obrada podataka o zabiljeenim defektima

U prvoj fazi modela sa slike 4.1 se obrauju prijavljeni problemi i ako je potrebno oznaavaju se kao defekti koji e se dalje obraivati. Odluka o tome to je doista defekt zahtjeva detaljno poznavanje rada ERP sustava i operacijskog sustava na kojem je ERP sustav instaliran pa se to obino preputa djelatnicima korisnike podrke koji su najee eksperti poslovne domene s odreenim iskustvima u poslovima razvoja i odravanja konkretnog ERP sustava. Pri tome je mogue grupirati defekte u odreene kategorije po kojima se eli vrednovati pouzdanost sustava. Podjela defekata po grupama ovisi o vrsti i primjeni instaliranog ERP sustava i ne postoji unaprijed zadano pravilo koje takvu podjelu definira. Konanu odluku moe donijeti sam proizvoa ili korisnik u ovisnosti o tome koja je grupa defekata posebno bitna za naknadnu analizu, odnosno koja grupa defekata ima vei ili manji utjecaj na pouzdanost pojedinog ERP modula ili itavog ERP sustava. 33

U studiji [12] je davatelj telekomunikacijskih usluga defekte na nekom ERP sustavu biljeio za svaki ERP modul posebno i grupirao ih u samo dvije kategorije: unutarnji defekt promatranog ERP modula izoliran u promatranom ERP modulu kao posljedica defekata u dizajnu ili neispravnog koritenja vanjski defekt promatranog ERP modula defekt iji je uzrok neki vanjski utjecaj (neispravnost komunikacijske infrastrukture i opreme, neispravan rad nekog drugog ERP modula) U drugoj studiji [13] je kategorizacija napravljena od strane proizvoaa ERP sustava po grupama: nedovoljno razumijevanje rada sustava od strane korisnika sigurnosni problemi ili problem s autorizacijom korisnika za rad nunost ispravka pogrenog programskog koda potrebna izmjena postojee funkcionalnosti potrebna nova funkcionalnost

Mogue je svesti sve defekte u istu kategoriju kao u studiji [12] u kojoj kategorija defekta nije posebno razmatrana jer se smatralo kako su svi defekti jednako bitni u predvianju pouzdanosti instaliranog ERP sustava. U obradi podataka o zabiljeenim defektima je vrlo bitno analizirati problematiku realnog vremena u kojem se defekti dogaaju. Postoje poslovna okruenja s uvedenim ERP sustavima gdje se defekti prijavljuju ee [12] zbog sloenosti sustava ili velikog broja korisnika, ali mogue su situacije u kojima se defekti prijavljuju i znatno rjee [13]. Konana odluka o tome u kojem e se vremenskom okviru defekti grupirati i brojati ovisi o konanoj statistikoj razdiobi uoenih defekata pa su npr. u studiji [12] defekti grupirani po danima, a u studiji [13] su defekti grupirani po tjednima. Problem realnog vremena unutar kojeg se biljee defekti za ERP sustav prisutan je i u naknadnoj statistikoj analizi grupiranih defekata. Postavlja se npr. pitanje to uiniti u sluaju ako se biljei razdioba defekata po danima unutar itavog mjeseca, a unutar tog perioda postoje dani kada se defekti ne biljee jer nitko ne koristi promatrani ERP sustav pa nema ni prijave defekata. U sklopu ovog rada je primijenjena preporuka iz koritene literature [9] u kojoj se navodi kako modeliranje prema slici 4.1 podrazumijeva radno stanje sustava i radno optereenje od strane korisnika. U provedenim istraivanjima [12], [13] je to znailo znai odbacivanje dana kada sustav nije u uporabi prilikom naknadne statistike analize. Kao 34

primjer takve obrade zabiljeenih podataka navedena je tablica 4.2 preuzeta iz [12] s razdiobom defekata za jedan radni dan. Tablica 4.2 je rezultat obrade izvornih zapisa o zabiljeenim defektima za jedan ERP modul koje je dostavila korisnika podrka poslovne organizacije iz [12] i koji su dijelom prikazani u tablici 4.1. Zbog preglednosti su u tablici 4.1 navedeni zapisi o zabiljeenim pojavama defekata za samo jedan dan. Tablica 4.1 Dio izvornog zapis o defektima za Modul1 u ERP sustavu [12] Kategorija Problem u radu Problem u radu Problem u radu Problem u radu Problem u radu Problem u radu Problem u radu Problem u radu Problem u radu Problem u radu Problem u radu Problem u radu Problem u radu Problem u radu Problem u radu Problem u radu Problem u radu ERP modul Sustav 1 Sustav 1 Sustav 1 Sustav 1 Sustav 1 Sustav 1 Sustav 1 Sustav 1 Sustav 1 Sustav 1 Sustav 1 Sustav 1 Sustav 1 Sustav 1 Sustav 1 Sustav 1 Sustav 1 Datum/Vrijeme prijave defekta 5.1.2010. 8:19:35 5.1.2010. 8:30:49 5.1.2010. 8:42:56 5.1.2010. 9:08:21 5.1.2010. 9:19:33 5.1.2010. 9:19:40 5.1.2010. 9:26:43 5.1.2010. 10:05:13 5.1.2010. 10:08:08 5.1.2010. 10:23:05 5.1.2010. 10:35:53 5.1.2010. 11:42:21 5.1.2010. 13:03:17 5.1.2010. 13:51:40 5.1.2010. 13:52:16 5.1.2010. 15:16:35 5.1.2010. 15:30:34

35

Rezultati grupiranja pojave defekata po radnim danima i za promatrani ERP modul su prikazani u tablici 4.2. Tablica 4.2 Obraeni zapisi o defektima za Modul1 u ERP sustavu [12] pripremljeni za analizu Dan 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Datum 4.1.2010. 5.1.2010. 7.1.2010. 8.1.2010. 11.1.2010. 12.1.2010. 13.1.2010. 14.1.2010. 15.1.2010. 18.1.2010. 19.1.2010. 20.1.2010. 21.1.2010. 22.1.2010. 25.1.2010. 26.1.2010. 27.1.2010. 28.1.2010. 29.1.2010. 30.1.2010. Broj defekata 15 28 28 9 39 18 5 12 10 14 3 25 10 15 31 26 15 16 16 3

Oito je kljuan trenutak odabir okvira u kojem e se brojati uzorci s pojavama defekata prema izvornom zapisu iz tablice 4.1. Odluku o odabiru okvira donosi u navedenom primjeru kupac sustava, sukladno mjerenjima i hipotezi koju eli naknadno dokazati statistikom analizom. U prikazanom primjeru je vidljivo da izvorni zapisi prema tablici 4.1 imaju atribut stvarnog vremena u kojem su defekti prijavljeni kao to su datum i tono vrijeme prijave. Moe se postaviti pitanje zato podaci nisu grupirani u manjoj jedinici vremena npr. u satima. U konkretnom primjeru preuzetom iz [12] je ispitana hipoteza da izmeu dvije nadogradnje sustava vrijedi Weibull razdioba defekata po radnim danima pa grupiranje po radnim satima ne bi imalo smisla. 36

4.2.

Razliiti pristupi u analizi podataka

Defekt je oito uzrok, a problem posljedica. U sluaju modeliranja pouzdanosti nekog tehnikog sustava uobiajeno je modelirati posljedicu koja predstavlja neispravno stanje nekog sustava (kvar). U takvom sluaju se modeliranje pouzdanosti svodi na praenje uestalosti pojave defekta koji ima ozbiljan utjecaj na rad korisnika. Ovakvo modeliranje je dodatno mogue svesti na odreeni tip defekta, npr. modeliranje pouzdanosti u kojem se u obzir uzima samo konfiguracija sustava. U ovom doktorskom radu se polazi od dva osnovna sluaja analize zabiljeenih defekata: defekt se biljei samo prilikom prvog pojavljivanja u sustavu i odmah se rjeava, zanemaruje se viestruko pojavljivanje defekt se biljei svaki puta kada je prijavljena njegova pojava u sustavu

Preporuljivo je za oba sluaja raunati s defektima koji imaju znatan utjecaj na rad korisnika. Prvi pristup je openito zanimljiv proizvoaima programske podrke jer jednostavno dovodi do modela pouzdanosti izrade neke programske komponente kao u [14]. Takoer je primjenjiv kada su svi problemi iz prve implementacijske faze rijeeni i korisnik ne planira vee nadogradnje sustava kao u [13]. U konanici takvo modeliranje daje informaciju o kvaliteti implementacije, ali ne opisuje precizno utjecaj na poslovanje. Primjerice, neka implementacija moe biti kvalitetna (svi defekti su rijeeni, s vremenom ih je sve manje i sustav je stabilan), ali u tijeku implementacije samo jedan defekt ozbiljno ugrozi itavo poslovanje. Meutim, postoje ERP sustavi koji se stalno nadograuju i u kojima se uslijed toga stalno unose novi defekti koji se mogu viestruko pojavljivati u sustavu. Takoer postoje ERP sustavi kod kojih neke defekte vie nije mogue rijeiti i ostaju u sustavu. U takvim situacijama je primjerenije koristiti drugi pristup u kojem se defekti biljee svaki puta kada se utvrdi da su uzrok prijavljenog problema. Takav model je primijenjen u [12] i detaljnije prikazan u 6. poglavlju ovog doktorskog rada. Ovakav pristup moe bolje opisati utjecaj defekata na poslovanje korisnika. Ako se dodatno napravi klasifikacija defekata kao na slici 2.4, tada je mogue obaviti modeliranje pouzdanosti prema uzroku defekata npr. model pouzdanosti prema pojavljivanju defekata koji su uzrokovani loom dokumentacijom, neispravnim konfiguriranjem i sl. 37

Sve mogue kombinacije za oba pristupa nije mogue ispitati unutar ovog rada, ali je oito za oba sluaja mogue primijeniti odreene statistike razdiobe koje definiraju prikladni model. Primjerice, neki automobil moe biti pouzdan (nikada nee ostaviti vozaa na cesti), ali ne mora biti kvalitetan. Ako se takav pristup primjeni na odreeni ERP sustav, on moe biti kvalitetan (npr. proizvoa toga ERP sustava vrlo rijetko pravi pogreke u programskom kodu), ali ne mora biti pouzdan jer su te vrlo rijetke pogreke izazvale velik broj problema, a time i veliku tetu za korisnika.

4.3.

Statistika analiza podataka

Na temelju obraenih podataka je mogue izvriti statistiku analizu podataka. Rezultat je funkcija gustoe vjerojatnosti pojave defekata koja opisuje uestalost pojave defekata na promatranom ERP sustavu. Takve statistike razdiobe se mogu prikazati pojedinano za promatrane ERP module ili se moe raunati ukupni doprinos svih modula na pouzdanosti itavog ERP sustava [13]. Empirijska funkcija gustoe vjerojatnosti pojave defekata se oznaava kao funkcija i povezana je s funkcijom brzine kvarenja sustava . Ukupna povrina ispod krivulje koja je opisuje iznosi 1, za beskonano vrijeme t. =1 Ukupna vjerojatnost pojave defekata za neki period , za taj period i oznaava se sa = Openito se funkcija . (4-2) za neki ERP sustav rauna po nekim vremenskim okvirima (4-1) odgovara povrini ispod krivulje

koji su zadani prilikom obrade podataka o zabiljeenim defektima i prema formuli: (4.3) U sluaju primjera iz tablice 4.2, to znai da se funkcija trei dan vrijedi: 28 / 338 = 0,08284 (4.4) rauna po danima, npr. za

38

Za itavu tablicu 4.1 je tako mogue raunati funkciju prikazati je histogramom kao na slici 4.2.
0,14

prema formuli (4-3) i

pe(ti)

0,12 0,1 0,08 0,06 0,04 0,02 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 radni dani

Slika 4.2 Grafiki prikaz izraunatih vrijednosti za funkciju

iz tablice 4.1

Sukladno formuli (4-2) mogue je raunati ukupnu vjerojatnost pojave defekata za neki ERP sustav i prikazati je grafiki na slici 4.3.
1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Slika 4.3 Grafiki prikaz izraunatih vrijednosti za funkciju

iz tablice 4.1

Na temelju izraunatih empirijskih vrijednosti za funkcije najbolje opisuju (engl. best fit) utvrene empirijske razdiobe.

, mogue je

uporabom numerikih postupaka na raunalu identificirati prikladne statistike razdiobe koje

39

4.4.

Postupci za procjenu parametara statistikih razdioba

U odreivanju parametara statistikih razdioba koje se najbolje poklapaju s empirijskim podacima primjenjuju se dvije osnovne grupe postupaka: grafike i analitike. Zbog svoje jednostavnosti i brzine grafike metode su u prolosti bile vrlo popularne u inenjerskim primjenama. Analitike metode su matematiki egzaktnije i pomou njih se u pravilu dobivaju kvalitetnije procjene nepoznatih parametara. Danas su analitiki postupci u irokoj primjeni jer ih je jednostavno primijeniti na raunalu. U ovom radu su koritene slijedee analitike metode: metoda momenata (engl. method of momentsMOM) metoda maksimalne vjerodostojnosti (engl. maximum likelihood estimates MLE) metoda najmanjih kvadrata (engl. least squares estimatesLSE)

4.4.1 Metoda momenata

Metoda momenata je esto koritena i najstarija statistika metoda za procjenu parametara nekog modela, a kao koncept ju je prvi uveo K. Pearson (1857.-1936.) [23]. Temelji se na pretpostavci da su vrijednosti statistikih momenata na empirijskim podacima bliske vrijednostima statistikih momenata na pretpostavljenoj teorijskoj razdiobi. Uz takvu pretpostavku je mogue formirati sustav jednadbi u kojima je na jednoj strani teorijski moment, a na drugoj strani vrijednost odgovarajueg empirijskog momenta. Vie o metodi momenata je mogue pronai u [24], [25], [26].

4.4.1.1

Primjena metode momenata na odreivanje parametara Weibull razdiobe

Postavlja se sustav od dvije jednadbe s dvije nepoznanice budui se za zadanu distribuciju odreuju dva nepoznata parametra i : , za k=1,2 (4-5)

Lijevu stranu postavljenog sustava predstavljaju empirijski momenti koji se za mjerene uzorke oznaavaju s i raunaju kao: (4-6)

40

Desnu stranu predstavljaju teorijski (ishodini) momenti koji se za pojedine statistike distribucije mogu pronai u razliitim udbenicima statistike npr. [24], [25], [26] koji se oznaavaju sa . Za Weibull razdiobu s dva parametra vrijedi prema [24], [25], [26]: (4-7) gdje predstavlja tzv. gama funkciju koja se rauna prema formuli: (u) = (4-8)

U prikazanom primjeru je najvei problem raunanje gama funkcije pa je potrebno upotrijebiti neku od numerikih metoda za njeno rjeavanje na raunalu.

4.4.2 Metoda maksimalne vjerodostojnosti

Metoda maksimalne vjerodostojnosti se smatra najboljom opom statistikom metodom za procjenu nepoznatih parametara statistike razdiobe [23]. Ova metoda se smatra posebno dobrom kod procjene parametara na velikom broju uzoraka. Metoda maksimalne vjerodostojnosti ne mora uvijek dati rezultate za bilo koju razdiobu npr. nije mogua primjena kod Weibull razdiobe s tri parametra [24], [27]. Definira se funkcija vjerodostojnosti: (4-9) gdje su empirijska opaanja neke sluajne varijable, funkcija gustoe vjerojatnosti, n

broj uzoraka, a parametar statistike razdiobe. Kod metode maksimalne vjerodostojnosti analitiki se rjeava problem procjenitelja maksimalne vjerodostojnosti, tj. trai se vrijednost za koju funkcija ima najveu vrijednost (maksimizacija funkcije Parametar se naziva procjeniteljem maksimalne vjerodostojnosti (ili krae ML-procjeniteljem) [23].

4.4.2.1

Primjena metode maksimalne vjerodostojnosti na odreivanje parametara Weibull razdiobe

U koritenom programskom alatu [36] se pretpostavlja da je za standardnu Weibull razdiobu funkcija vjerodostojnosti zadana kao: (4-10) Zbog jednostavnijeg raunanja, mogue je prethodnu formulu logaritmirati (logaritamska funkcija je strogo rastua pa je problem maksimizacije funkcije ekvivalentan . 41

ln Postupkom maksimizacije parametrima i

ln

1)

(4-11)

tj. parcijalnim deriviranjem formule (4-11) po

i izjednaavanjem s 0, dobiva se prema [23]: (4-12) (4-13)

Supstitucijom (4-12) u (4-1) i sredivanjem izraza, jednadba koju treba zadovoljavati ML-procjenitelj glasi (4-14) Jednadba (4-14) se rjeava nekom od numerikih metoda na raunalu i odreuje vrijednost parametra . Izraunati se uvrtava u () i dobiva prema [23]: (4-15) U prikazanom primjeru najsloeniji dio odreivanja parametara distribucije je numeriko rjeavanje izraza (4-15).

4.4.2.2

Primjena metode maksimalne vjerodostojnosti na odreivanje parametara eksponencijalne razdiobe

U primijenjenom programskom alatu [36] se pretpostavlja kako je za standardnu Weibull razdiobu funkcija vjerodostojnosti zadana prema [24] kao: (4-16) gdje predstavlja srednju vrijednost zabiljeenih uzoraka: (4-17) Deriviranjem logaritma funkcije vjerodostojnosti kao u prethodnom poglavlju, prema [23] dobiva se: (4-18)

42

Rjeavanjem prethodne formule (4-18) se dobiva kako je ML-procjenitelj za eksponencijalnu razdiobu: (4-19)

4.4.3 Metoda najmanjih kvadrata

Kod metode najmanjih kvadrata se razlikuju metoda najmanjih obinih kvadrata (engl. ordinary least squares) ili OLS metoda i metoda najmanjih potpunih kvadrata (engl. total least squares) ili TLS metoda. U koritenom programskom paketu [36] primjenjuje se OLS metoda koja je detaljnije opisana u nastavku. OLS metoda najmanjih kvadrata se zasniva na raunanju sume kvadrata odstupanja izmeu teorijske i empirijske razdiobe [24]: (4-20) Varijabla se zove rezidual (engl. residual) i rauna prema [24] kao: (4-21) gdje predstavlja vrijednost iz empirijske razdiobe, a pretpostavljenu teoretsku suma kvadrata

razdiobu s nekim parametrom

koja bi trebala najbolje odogovarati utvrenoj empirijskoj

razdiobi. Prema [24] vrijedi pretpostavka da bi za najbolji parametar odstupanja S trebala biti najmanja ako vrijedi:

(4-22) Omjer (4-22) se zove gradijent (engl. gradient) Ako pretpostavljena teorijska razdioba ima vie parametara prema [23]: (4-23) Uz uvrtavanje (4-21), (4-23) prelazi prema [23] u: (4-24) Utvreni za kojeg vrijedi (4-24) se naziva i najbolji OLS procjenitelj. ( tada (4-22) prelazi u sustav jednadbi s gradijenata

43

4.4.3.1

Primjena metode najmanjih kvadrata na odreivanje parametara Weibull razdiobe

U koritenom programskom paketu [36] se primjenjuje rezultat postupka detaljnije opisanog u [23] kod kojeg se u odreivanju najboljeg OLS procjenitelja kree od dvostrukog logaritmiranja formule za Weibull razdiobu (3-26) nakon ega se dobiva linearizirani Weibull model. (4-25) Uz supstitucije [24]: (4-26) (4-27) (4-28) (4-29) dobiva se za (4-25): (4-30) Iz literature [24], [25], [26] je poznato kako odgovarajui najbolji OLS procjenitelji tada glase: (4-31) (4-32)

Sukladno prije navedenim supstitucijama, mogue je iz (4-31) i (4-32) odrediti najbolje OLS procjenitelje Weibull razdiobe: (4-33)

(4-34)

44

4.5.

Identifikacija prikladnog modela pouzdanosti ERP sustava

U identifikaciji prikladnog modela pouzdanosti nekog ERP sustava je potrebno utvrditi koja teorijska statistika razdioba najbolje opisuje prethodno izraunatu empirijsku razdiobu. U odreivanju prikladne teorijske razdiobe se mogu se primijeniti preporuke iz literature [8], [9] prema kojima se kod modeliranja pouzdanosti programske podrke razmatra mogunost primjene tri statistike razdiobe: eksponencijalne razdiobe, Weibull razdiobe i gama razdiobe. Utvrivanjem i provjerom teorijske razdiobe koja se najbolje poklapa s empirijskom se odabire odgovarajui model pouzdanosti. Identifikacija prikladnog modela se skraeno moe prikazati na slici 4.4.

Raunanje empirijske razdiobe defekata

Odreivanje teoretskih razdioba

Eksponencijalna

Weibull

Gama

KS test

KS test

KS test

AD test

AD test

AD test

Odabir najbolje teoretske razdiobe

Odabir modela prema najboljoj teoretskoj razdiobi

Slika 4.4 Algoritam

identifikacije prikladnog modela pouzdanosti ERP sustava

45

Podjela bitnih modela pouzdanosti programske podrke koji su zasnovani na statistikim razdiobama pojave defekata i prikladni u modeliranju pouzdanosti ERP sustava je prikazana na slici 4.5.
MODELI POUZDANOSTI PROGRAMSKE PODRKE ZASNOVANI NA STATISTIKIM RAZDIOBAMA

EKSPONENCIJALNA RAZDIOBA

WEIBULL RAZDIOBA

GAMA RAZDIOBA

JELINSKIMORANDA

NHPP

SCHNEIDEWIND

WEIBULL MODEL

MODEL S-KRIVULJE

HIPEREKSPONENCIJALNI

MUSA BASIC

Slika 4.5 Podjela bitnih modela pouzdanosti programske podrke, zasnovanih na statistikim razdiobama pojave defekata u sustavu programske podrke Primjena eksponencijalne razdiobe u analizi pouzdanosti programske podrke je najstarija pa je i broj poznatih modela koji tu razdiobu koriste najvei. Od dostupnih eksponencijalnih modela u ovom radu je posebno obraena i detaljno opisana samo primjena osnovnog Musa (engl. Musa Basic) eksponencijalnog modela u potpoglavlju 4.4.1. Weibul model je ocijenjen kao prikladan u studijama [12], [13] i detaljno je opisan u 6. poglavlju ovog doktorskog rada. Potvrda prikladnosti neke statistike razdiobe se utvruje uporabom statistikih testova od kojih su najpoznatiji: Kolmogorov-Smirnov, Anderson-Darling i Hi-kvadrat. Primijenjeni statistiki testovi dokazuju tzv. nul hipotezu (engl. null hypotesis) prema kojoj je pretpostavljena teorijska razdioba prikladna u opisivanju empirijske pojave defekata, tj. pretpostavlja se kako u sluaju potvrde nul hipoteze vrijedi: (4-35) gdje je ukupna empirijska vjerojatnost pojave defekata, a teorijska. Pri tome

se nul hipoteza potvruje uz odreeni faktor znaajnosti koji se u statistici obino oznaava s . U tehnikim sustavima je obino rauna uz faktor znaajnosti =0,05. U praktinoj primjeni se razgraniava podruje prihvaanja nul-hipoteze hipoteza ne vrijedi i podruje gdje nulprema slici 4.6. U odreen 46 , a kao kritina vrijednost se oznaava

veini udbenika statistike [24], [25], [55] se mogu pronai tablice u kojima je

kao funkcija broja uzoraka n za razliite teorijske razdiobe. Svaki statistiki test ima razliit nain raunanja razlike izmeu empirijskih i utvrenih teorijskih razdioba, a algoritam po kojem se ta razlika rauna se naziva testna statistika [55]. Dobivena razlika se za bilo koji statistiki test oznaava s .

Slika 4.6 Grafiki prikaz potvrde nul hipoteze za pretpostavljenu teoretsku statistiku razdiobu

Danas su postupci potvrde statistikih modela bitno pojednostavljeni primjenom raunala i razliitih statistikih programskih paketa [36]. U sluaju potvrde vie razliitih razdioba koje zadovoljavaju nul hipotezu, za najbolju se odabire ona teorijska razdioba prema kojoj je rezultat testne statistike za odabrani statistiki test najmanji. U ovoj radu i provedenim istraivanjima [12,] [13] su u postupku potvrde utvrene teorijske razdiobe koritena dva statistika testa: Kolmogorov-Smirnov i Anderson-Darling.

4.5.1 Primjena Kolmogorov-Smirnov testa

Kao testna statistika se kod Kolmogorov-Smirnov testa odreuje najvea razlika izmeu definirane empirijske (ponekad se u literaturi koristi i skraeni naziv ECDF [24], [25]) i teorijske razdiobe ukupne vjerojatnosti pojave defekata u nekom ERP sustavu i oznaava s . Empirijska razdioba se kod Kolmogorov-Smirnov testa oznaava kao kao Testna statistika se kod Kolmogorov-Smirnov testa rauna kao: (4-36) tj. rauna se apsolutna vrijednost maksimalne razlika teorijske i empirijske funkcije ukupne vjerojatnosti pojave defekata. a teorijska

47

U statistikim tablicama [24], [25], [55] je mogue prilikom provjere oitati kritinu vrijednost za bilo koju teoretsku razdiobu prema zadanom broju uzoraka i faktoru manje od oitane vrijednosti za , nul hipoteza vrijedi, tj. znaajnosti. Ako je

pretpostavljena teorijska razdioba odgovara empirijskoj razdiobi defakata u ERP sustavu. Kao primjer potvrde pretpostavljene razdiobe defekata u ERP sustavu koritenjem Kolmogorov-Smirnov testa, moe se analizirati razdioba defekata prikazana u tablici 4.2. Za prikazani sluaj preuzet iz studije [12], postavljene su slijedee hipoteze: : Razdioba defekata za neki ERP sustav, zabiljeena u tablici 4.2 odgovara Weibull razdiobi : ne vrijedi koritenjem Kolmogorov-Smirnov testa se moe opisati

itav postupak potvrde algoritmom:

Odredi parametre pretpostavljene razdiobe iz ovom primjeru Weibull razdioba =1,6595,=10,943) Sloi podatke po rastuem redoslijedu (u

(u

ovom

primjeru su to radni dani, stupac 1, tablica 4.3) Odredi teoretsku razdiobu Odredi empirijsku razdiobu Odredi razlike Odredi i (stupac 2, tablica 4.3) (stupac 3, tablica 4.3)

(stupac 4, tablica 4.3) testnu statistiku, prema

Kolmogorov-Smirnov (u

navedenom

primjeru,

tablici 4.3,

= 0,11348)

Iz statistikih tablica, za pretpostavljenu razdiobu iz i faktor znaajnosti odredi kritinu vrijednost (preporueni sustavima je odabir = 0,05, za a primjenu prema u tehnikim se za

tablicama

Weibull razdiobu i 20 uzoraka oitava Ako je < , vrijedi nul hipoteza

=0,29408) Ako je >

, odbacuje se nul hipoteza

48

Tablica 4.3 Kolmogorov-Smirnov test za pretpostavljenu Weibull razdiobu i podatke iz tablice 4.2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

0,0187 0,0578 0,1102 0,1716 0,2386 0,3085 0,3790 0,4482 0,5147 0,5773 0,6353 0,6882 0,7358 0,7780 0,8150 0,8472 0,8747 0,8981 0,9178 0,9341

0,0444 0,1272 0,2101 0,2367 0,3521 0,4053 0,4201 0,4556 0,4852 0,5266 0,5355 0,6095 0,6391 0,6834 0,7751 0,8521 0,8964 0,9438 0,9911 1

0,0257 0,0694 0,0998 0,0651 0,1135 0,0968 0,0411 0,0074 0,0295 0,0507 0,0998 0,0787 0,0967 0,0946 0,0399 0,0049 0,0217 0,0457 0,0733 0,0659 0,29408 0,11348

U opisanom primjeru dakle vrijedi

<

pa je nul hipoteza

potvrena prema

provedenom Kolmogorov-Smirnov testu iz tablice 4.3, tj. utvrena Weibull razdioba je prikladna u opisivanju empirijske razdiobe defekata po radnim danima iz tablice 4.2.

4.5.2 Primjena Anderson-Darling testa

Testna statistika kod Anderson-Darling testa se rauna po formuli: = + ln( )] (4-37)

49

Iz statistikih tablica [24], [25], [55] se za pretpostavljenu razdiobu i zadani faktor znaajnosti oitava kritina vrijednost ako vrijedi da je < . koja se usporeuje s . Nul hipoteza je potvrena

Kao primjer potvrde pretpostavljene razdiobe defekata u ERP sustavu koritenjem Anderson-Darling testa moe se opet analizirati razdioba defekata prikazana u tablici 4.2. Tablica 4.4 Anderson-Darling test za pretpostavljenu Weibull razdiobu i podatke iz tablice 4.2

i 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

n-i+1 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

P0(xi) 0,0187 0,0578 0,1102 0,1716 0,2386 0,3085 0,3790 0,4482 0,5147 0,5773 0,6353 0,6882 0,7358 0,7780 0,8150 0,8472 0,8747 0,8981 0,9178 0,9341

2i-1 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39

P0(xn-i+1) 0,9341 0,9178 0,8981 0,8747 0,8472 0,8150 0,7780 0,7358 0,6882 0,6353 0,5773 0,5147 0,4482 0,3790 0,3085 0,2386 0,1716 0,1102 0,0578 0,0187

lnP0(xi) -3,9801 -2,8501 -2,2054 -1,7628 -1,4330 -1,1760 -0,9702 -0,8025 -0,6642 -0,5494 -0,4537 -0,3737 -0,3069 -0,2510 -0,2045 -0,1659 -0,1338 -0,1075 -0,0858 -0,0681

ln(1-P0(xn-i+1)) -2,7203 -2,4983 -2,2839 -2,0772 -1,8784 -1,6876 -1,5051 -1,3309 -1,1653 -1,0087 -0,8611 -0,7230 -0,5946 -0,4764 -0,3689 -0,2726 -0,1882 -0,1168 -0,0596 -0,0189 2,501800 0,536927

Za navedeni primjer vrijedi da je promatranom ERP sustavu iz tablice 4.2.

<

iz ega slijedi potvrda nul hipoteze po

Anderson-Darling testu, tj. Weibull razdioba odgovara empirijskoj razdiobi defekata na

50

4.5.3 Identifikacija prikladnog modela koritenjem programa EasyFit

U ovom doktorskom radu je koriten programski paket EasyFit [36] u identifikaciji prikladnih statistikih modela (engl. distribution fitting) iz postojeih empirijskih razdioba za funkcije i . itav postupak je vrlo jednostavan jer je dovoljno unijeti podatke grupirane kao u tablici 4.2, a aplikacija nakon toga automatski rauna empirijsku funkciju gustoe vjerojatnosti pojave defekata za promatrani ERP sustav i parametre pretpostavljene teorijske razdiobe. Prilikom identifikacije prikladnog modela u programskom paketu se mogu razmatrati sve ponuene razdiobe (trenutno ih je dostupno vie od ezdeset), meutim nisu sve prikladne u analizi pouzdanosti programske podrke. Kao primjer se moe se identifikacija modela pouzdanosti iz empirijskih podataka u tablici 4.2. U prvom koraku se kao na slici 4.7 unosi mjerena razdioba koja je prethodno pripremljena prema tablici 4.2.

Slika 4.7 Unos defekata po radnim danima iz Tablice 4.2 u programu EasyFit

U drugom koraku se pokree analiza uzorka prema postavkama kao na slici 4.8. U prikazanoj analizi se posebno odabire stupac koji predstavlja os (u ovom primjeru su to radni dani) i stupac koji predstavlja sluajnu varijablu (u ovom primjeru je to broj zabiljeeni defekata po radnim danima). U sluaju kada se uzorci posebno ne indeksiraju (npr. u prikazanom primjeru se to ini po radnim danima), nije potrebno posebno oznaavati podatke koji predstavljaju os . Budui broj moguih defekata po radnom danu moe biti bilo koji 51

sluajan broj na intervalu [0, ] odabire se analiza za kontinuiranu sluajnu varijablu kao na slici 4.8.

Slika 4.8 Definiranje parametara obrade u programu EasyFit

Nakon pokretanja obrade aplikacija rauna parametre izmeu razmatranih razdioba (eksponencijalna, Weibull i gama) koje najbolje pristaju empirijskoj razdiobi koritenjem algoritama detaljnije opisanih u potpoglavlju 4.4. U konanici je mogue pregledati ocjenu i vrijednosti parametara za sve razmatrane radiobe kao na slici 4.9. Poredak modela (engl. rank) je naveden za dva primijenjena statistika testa (Kolmogorov-Smirnov i Andreson-Darling) i vidljiv je na slici 4.9. Rangiranje razdioba se vri na temelju rezultata testne statistike prema zadanom fakotru znaajnosti. Manji rezultat testne statistike znai bolji rezultat u ukupnom poretku. U navedenom primjeru je najbolje rangirana Weibull razdioba prema oba primijenjena testa.

52

# 1 2 3 4 5 6 7 8

Distribution Exponential Exponential (2P) Gamma Gamma (3P) Gen. Gamma Gen. Gamma (4P) Weibull Weibull (3P)

Kolmogorov Smirnov Statistic Rank

Anderson Darling Statistic Rank

0,1702 0,17756 0,17213 0,16916 0,17284 0,17185 0,15266 0,1579

4 8 6 3 7 5 1 2

1,7404 2,8171 0,81904 0,79334 0,77882 2,0017 0,53671 0,59988

6 8 5 4 3 7 1 2

Slika 4.9 Poredak razmatranih teorijskih razdioba, za podatke iz tablice 4.2, preuzet iz programa EasyFit Parametri razmatranih teorijskih razdioba su vidljivi na slici 4.10.

# 1 2 3 4 5 6 7 8

Distribution Exponential Exponential (2P) Gamma Gamma (3P) Gen. Gamma Gen. Gamma (4P) Weibull Weibull (3P)

Parameters =0,10193 =0,1135 =1,0 =2,8152 =3,4849 =1,7199 =5,4462 =0,44373 k=0,90383 =2,484 =3,4849 k=27,554 =0,02308 =19,347 =1,0 =1,6595 =10,943 =1,5438 =10,432 =0,37306

Slika 4.10 Parametri razmatranih teorijskih razdioba, za podatke iz tablice 4.2, preuzeti iz programa EasyFit

Parametri Weibull razdiobe koja je ostvarila najbolji rezultat su vidljivi na slici 4.10 ( = 1,6595 i =10,493). Utvrena teorijska razdioba je usporeena s empirijskom na slikama 4.11 i 4.12.

53

Funkcija gustoe vjerojatnosti pojave defekata

0,12 0,11 0,1 0,09 0,08 0,07

p(t)

0,06 0,05 0,04 0,03 0,02 0,01 0 2 4 6 8 10 12 14 16 18 20

t
Empirijski Weibull

Slika 4.11 Usporedba empirijske i teorijske Weibull razdiobe za funkciju gustoe pojave defekata, za podatke iz tablice 4.2
Ukupna vjerojatnost pojave defekata
1 0,9 0,8 0,7 0,6

P(t)

0,5 0,4 0,3 0,2 0,1 0 2 4 6 8 10 12 14 16 18 20

t
Empirijski Weibull

Slika 4.12 Usporedba empirijske i teorijske Weibull razdiobe za ukupnu vjerojatnost pojave defekata, prema podacima iz tablice 4.2

4.6.

Primjena statistikih modela pouzdanosti na ERP sustave

U primjeni prethodno navedenih statistikih modela pouzdanosti na ERP sustave je mogue odrediti trenutno stanje pouzdanosti promatranog ERP sustava na temelju dotad zabiljeenih podataka o prijavljenim defektima, ali i predvidjeti budue pojave defekata u sustavu. U studijama [12], [13], [14] su uoeni razliiti primjeri primjene modeliranja pouzdanosti iz perspektive proizvoaa i korisnika ERP sustava. 54

Tako je za proizvoae ERP sustava ispitana primjena modela pouzdanosti u nekoliko osnovnih sluajeva: implementacija postojee verzije ERP sustava uz prilagodbu i obuku kod veeg korisnika [14] prilagodba postojee verzije ERP sustava za odreenog (najee veeg) korisnika [12] isporuka prilagodbi za vei broj kupaca (npr. izmjene poreznih propisa) [13]

Proizvoaima ERP sustava moe biti posebno zanimljiva analiza defekata koji su posljedica prilagodbi. Uz pretpostavku kako je broj takvih defekata konaan za jednu verziju sustava tada se moe ocijentit da li je isporuka prilagodbe sigurna. Korisnici takoer mogu pratiti stanje pouzdanosti ERP sustava koji je puten u rad, procijeniti kakvi defekti najvie utjeu na njegovu pouzdanost te poduzeti potrebne korake kako bi se stanje poboljalo (bolje specifikacije traenih izmjena, vie obuke, izmjene poslovnih procesa itd.) Posebno se mogu modelirati utjecaji nadogradnji na pouzdanosti ERP sustava koji su detaljnije opisani u 6. poglavlju ovog doktorskog rada i studiji [12].

4.6.1 Primjena eksponencijalnog modela pouzdanosti na ERP sustave

U pripremi ovog doktorskog rada je istraena primjena prethodno opisanog Musa eksponencijalnog modela za sluaj vee prilagodbe dijela postojeeg ERP sustava prema sustavima drugih proizvoaa. Istraeni su zapisi provjere prilagodbe programskog modula FAIS [43] koji je dio ERP sustava G2, hrvatskog proizvoaa Swing Consulting d.o.o. [ 43]. Opisana prilagodba je nainjena za sve korisnike u Bosni i Hercegovini (BiH) prilikom uvoenja projekta tzv. fiskalizacije. U takvom poslovnom okruenju se izlazni rauni kupcima izdaju na tzv. fiskalnim ureajima koji su odobreni i zakljuani od strane nadlene porezne uprave te opremljeni posebnim fiskalnim modulom (EPROM modul instaliran u pisau s pripadajuom programskom podrkom za instalaciju kod poreznog obveznika) u kojem se uvaju bitni elementi svakog ispisanog rauna (broj, datum i vrijeme ispisa, osnovica, porez na dodanu vrijednost, ukupni iznos itd.). Prilikom porezne kontrole je vaei zapis u fiskalnom modulu koji mora biti usklaen s izvrenom prijavom poreza na dodanu vrijednost od strane poreznog obveznika. Ukoliko se radi o veem poreznom obvezniku, moe se realizirati GPRS veza prema nadlenoj poreznoj upravi i u realnom vremenu biljeiti zaduenje poreza na dodanu vrijednost i provjera za prethodna razdoblja. Vie o projektu 55

fiskalizacije u BiH je mogue pronai na [44]. Kada porezni obveznik iz svog ERP modula izdaje izlazni raun vri se upis podataka u fiskalni modul prema zadanom protokolu i izlaznom slogu. Skica prikazanog ERP G2 rjeenja je prikazana na slici 4.13.
G2 FINANCIALS AND CONTROLING

G2 SALES

Books-InputOutput invoices Cash desk General Ledger Accrued interest

G2 FAIS

FISCAL PRINTER

INVOICE DOCUMENT FOR CUSTOMER

C ON (OPT NECTION IONA L)

VAT REPORT

BiH Federal Ministry of Finance

Slika 4.13 Povezivanje G2 ERP rjeenja s fiskalnim modulom

Analizom podataka koji su zabiljeeni prilikom provjere prilagodbe FAIS modula prema fiskalnom modulu nainjena je tablica 4.5, u kojoj su podaci o zabiljeenim defektima prilagoeni analizi koritenjem prethodno opisanog Musa Basic eksponencijalnog modela pouzdanosti. Provjera je trajala ukupno trideset radnih sati, a zadnji je defekt uoen nakon 26 sati. itav postupak provjere je organiziran i proveden kod proizvoaa ERP sustava tako da su pozvani predstavnici pet kljunih (najveih) korisnika koji su obaviti validaciju prilagodbe prema unaprijed zadanom postupku s ispitivanjem na vlastitoj opremi.

GPRS

56

Zadatak prikazane studije [14] je bila naknadna procjena koja je trebala odgovoriti na pitanje da li je u promatranom sluaju validacija zavrena u pravom trenutku i to bi se dogodilo da je trajanje bilo drukije

Tablica 4.5 Podaci prikupljeni u validaciji prilagodbe Ukupan broj defekata [n] 1 2 3 4 5 6 7 8 9 10 10

Sati [ ] 1 3 4 6 9 12 13 15 20 26 30

Broj novih defekata 1 1 1 1 1 1 1 1 1 1 0

Sukladno formulama (3-22) i (3-23) Musa Basic model omoguava odreivanje parametara eksponencijalne razdiobe koja odgovara empirijskoj razdiobi iz tablice 4.4. Procjena teorijske razdiobe je izraunata koritenjem formule (4-9) koja je dobivena uvrtavanjem (n=10 ; x = 4 ;
10

) u formulu (3-23). (4-38)

300 p 30 -1

- 109=0

Numerikim rjeavanjem na raunalu jednadbe (4-38) za trenutak isporuke [0,

dobiveno je rjeenje za =0,09174. Eksponencijalnu razdiobu je naravno mogue utvrditi i uporabom nekog statistikog alata na raunalu [36] uz koritenje podataka iz tablice 4.5, ali Musa Basic model prema formuli (3-22) omoguava procjenu konanog broja defekata koji su ugraeni u sustav prilikom prilagodbe to je iz perspektive proizvoaa ERP sustava vrlo bitan podatak. Meutim, za potpunu potvrdu prethodno ustanovljene teorijske razdiobe, 57

potrebno je provjeriti njeno poklapanje s empirijskom uz koritenje nekog od prethodno opisanih statistikih testova. Provedenim Kolmogorov-Smirnov statistikim testom je potvrena prikladnost procijenjene eksponencijalne razdiobe za faktor znaajnosti =0,05. Rezultat provedenog testa je prikazan u tablici 4.6. Tablica 4.6 Kolmogorov-Smirnov test za potvrdu poklapanja empirijske razdiobe iz tablice 4.4 s eksponencijalnom, utvrenom preko Musa Basic modela Kolmogorov-Smirnov Veliina uzorka Kritina vrijednost Odbacivanje? 30 0,16743 0,05 0,2417 NE

Grafika usporedba empirijskih i teorijskih razdioba izraunatih koritenjem Musa Basic modela iz tablice 4.5 je prikazana na slikama 4.14 i 4.15.

Slika 4.14 Usporedba empirijske funkcije gustoe vjerojatnosti pojave defekata prema tablici 3.1 s najbliom eksponencijalnom razdiobom

58

Slika 4.15 Usporedba ukupne vjerojatnosti pojave defekata prema tablici 3.1 s najbliom eksponencijalnom razdiobom

Ukupan broj oekivanih defekata u sustavu se rauna uvrtavanjem izraunatog parametra iz formule (4-38) u formulu (3-22). =
10 1- e p -30 )

(4-39) =

Rjeavanjem jednadbe (4-39) se dobiva rjeenje za ukupan broj oekivanih defekata prema veoj vrijednosti, tj.

10,68. Na temelju dobivene vrijednosti se moe rei (za najgori sluaj se vri zaokruivanje 11) kako je u sustavu ostao jo jedan neotkriveni defekt, tj. ukupan broj defekata je u trenutku isporuke na temelju teoretskog eksponencijalnog modela bio priblino 11, a dotada ih je otkriveno ukupno 10. Taj preostali defekt bi se vjerojatno otkrio u sluaju due provjere, kada bi se krivulja ukupne teorijske vjerojatnosti pojave defekata sa slike 4.15 vie pribliila vrijednosti 1. Uz uvrtavanje izraunatog parametra i za sluaj u kojem su svi defekti otkriveni uz ukupnu vjerojatnost P(t) =99%, bilo je potrebno za prikazani sluaj izvriti jo 25 sati provjere. Ako se uvrsti vrijeme t, u kojem je provjera prikazanog dijela ERP podsustava doista zavrila, moe se rei kako je u tom trenutku ukupna vjerojatnost da su svi defekti otkriveni bila priblino 93%. Oito e u stvarnim uvjetima bilo koji dio nekog ERP sustava nakon prilagodbe biti isporuen s defektima koji nisu otkriveni prilikom provjere, ali je primjenom prikazanog eksponencijalnog modela mogue procijeniti rizik neotkrivenih defekata. Vidljivo je kako se taj rizik smanjuje duom provjerom, ali se koritenjem eksponencijalnog modela proizvoa ERP sustava moe na temelju zadane ili 59

oekivane vjerojatnosti (npr. 95%) odluiti kada je izvrena prilagodba sigurna za isporuku. Odluku o prekidu provjere proizvoa ERP sustava moe najjednostavnije donijeti usporedbom trokova naknadnih ispravaka neotkrivenih defekata s trokovima provjere. Takoer, proizvoa moe odluiti predati prilagoen ERP sustav kupcu uz manje vrijeme provjere od planiranog (npr. uslijed probijanja zadanih rokova isporuke), ali tada moe uz uporabu prikazanog modela pouzdanosti planirati trokove koje e vjerojatno imati u budunosti prilikom ispravaka neotkrivenih defekata.

4.6.2 Primjena Weibull modela pouzdanosti na ERP sustave

Weibull model se primjenjuje u modeliranju pouzdanosti ERP sustava slino kao i eksponencijalni model opisan u prethodnom potpoglavlju, odnosno na temelju empirijske razdiobe za koju je statistikim testovima utvreno da se najbolje poklapa s Weibull razdiobom se odreuju parametri razdiobe i pokuava se predvidjeti budue pojavljivanja defekata u promatranom ERP sustavu. Zbog matematikih svojstava Weibull razdiobe koji su detaljnije opisanih u 3. poglavlju ovog rada se moe rei kako je Weibull razdioba prikladnija u modeliranju pouzdanosti ERP sustava od eksponencijalne jer nema unaprijed zadan obliku, odnosno u odreenim uvjetima moe prei u druge razdiobe npr. eksponencijalnu. Ovakvu tvrdnju je najjednostavnije opisati krivuljom kade [23] prikazanoj na slici 4.14 na kojoj je vidljiva funkcija brzine pojave defekata (t) u nekom ERP sustavu kao funkcija vremena. Posebno su izdvojene tri osnovna podruja: podruje poetnih defekata (podruje poetka rada na uvedenom ERP sustavu) (engl. infant mortality region) brzina pojava defekta na poetku je vrlo visoka i brzo opada podruje rada (potpuno putanje u rad) (engl. constant defect rate region) brzina pojave defekata je stalna podruje zastarijevanja (podruje u kojem su potrebne izmjene) (engl. wear-out region) brzina pojave defekata poinje brzo rasti

60

(t)

poetak

rad

zastarijevanje

Slika 4.14 Prikaz funkcije brzine pojave defekata u ERP sustavu krivuljom kade Weibull razdioba se moe prilagoditi bilo kojoj od navedene tri faze, tj. mogue je modeliranje u kojem brzina pojave defekata u promatranom ERP sustavu pada, raste ili je stalna. Sukladno matematikim svojstvima Weibull razdiobe koji su detaljnije opisani u 3. poglavlju ovog rada, oblik krivulje je za sva tri sluaja definiran parametrom oblika , tj. u fazi kada je brzina pojave defekata u sustavu stalna, Weibull razdioba e prijei u eksponencijalnu. Eksponencijalna razdioba oito ima ue podruje primjene pa se moe rei da je specijalan sluaj Weibull razdiobe kod modeliranja pouzdanosti ERP sustava. Kod analize podataka u provedenim studijama [12] i [13] je Weibull razdioba prema primijenjenim statistikim testovima uvijek bila najbolje ocijenjena izmeu razmatranih teorijskih razdioba sa slike 4.5. Posebno je zanimljiva primjena Weibull razdiobe koja je uoena u analizi utjecaja nadogradnji na pouzdanost primijenjenog ERP sustava i detaljnije prikazana u provedenoj studiji [12].

4.6.3 Primjena postupka linearne regresije u predvianju buduih vrijednosti Weibull statistike razdiobe
U ovom radu je kao prvi izbor u procjeni buduih vrijednosti Weibull razdiobe odabran postupak linearne regresije. U statistici se linerana regresija definira kao postupak modeliranja veze izmeu jedne ili vie varijabli oznaenih s rezultat takvog modela je da se [55]: za dani i jednom ili vie varijabli oznaenih s , a izraava kao linearna funkcija od . Veina

mnogobrojnih primjena linearne regresije se u veini sluajeva svodi na dva podruja prema

fdgg
t1 t2

61

podeavanje modela predvianja prema promatranom skupu podataka vrijednosti i , a nakon toga i prognoza buduih vrijednosti i veeg broj varijabli ,..., parametra uz koje mogu prethodno podeenu vrijednost

ako su poznate vrijednosti varijable biti povezane sa relacije izmeu i

, moe se koritenjem linerane regresije utvrditi jaine , tj. koje su varijable uope povezane s

U ovom doktorskom radu je postupak linearne regresije koriten za predvianje buduih oblika Weibull razdiobe iz prethodno utvrenih vrijednosti parametara. U izradi modela linearne regresije je koriten programski paket Microsoft Excel [45]. Kao primjer su u tablici 4.6 prikazane prethodne vrijednosti parametara za Weibull razdiobe koje opisuju pojavu defekata u prvih est mjeseci promatranja jednog ERP podsustava iz [12]. Tablica 4.6 Vrijednosti parametara Weibull razdiobe za prvih est mjeseci Modul1 Mjesec 1 2 3 4 5 6 1,6595 2,1759 1,4631 2,201 2,0541 2,0276 10,943 12,31 12,838 12,393 14,194 10,567 je koritena funkcija ugraena u

Za predvianje slijedee vrijednosti parametra

programskom paketu Microsoft Excel. Vie o sintaksi primijenjene funkcije i openito o uporabi linearne regresije unutar Microsoft E cel tablinog kalkulatora je mogue pronai na [45]. U predvianju budue vrijednosti za parametar uzimaju sve prethodne vrijednosti za iz tablice 4.6. se kao skup poznatih vrijednosti za se os navode vrijednosti iz prvog stupca tablice 4.6, a kao skup poznatih vrijednosti za

62

2,5 2 1,5 1 0,5 0 0 2 4 6

y = 0,0632x + 1,7089 R = 0,1555

Slika 4.15 Odreivanje jednadbe pravca linearne regresije za podatke iz tablice 4.6

Rezultat su koeficijenti jednadbe pravca nain se rauna predviena vrijednost za parametar 12,535.

koja je prikazana na slici 4.15. iz pravca = 0,095 + 11,87 i iznosi

Predviena vrijednost za parametar je sukladno iskazanoj jednadbi pravca 2,149. Na isti

4.6.4 Primjena KNN algoritma u predvianju buduih vrijednosti Weibull statistike razdiobe
Za predvianje buduih vrijednosti teorijskih statistikih razdioba vjerojatnosti pojave defekata na ERP sustavima u ovojm doktorskom radu je koriten i KNN algoritam (engl. k-Nearest Neighbor) ili algoritam k-najbliih susjeda. KNN je algoritam kontroliranog uenja gdje je rezultat novog upita razvrstan na osnovu veine najbliih rezultata za pojedinu kategoriju [55]. Svrha algoritma je klasificiranje novog uzorka temeljem prethodnih vrijednosti. U trenutku predvianja se zadaje prostor u kojem se nalazi k prethodnih vrijednosti nekog uzorka. Novi uzorak se klasificira u grupu uzoraka koji su mu od k obuhvaenih najblie. Algoritam je najjednostavnije ilustrirati na slici 4.16, gdje je prikazana klasifikacija novog uzorka prikazanog punim krugom.

63

Slika 4.16 Primjer razvrstavanja uzoraka uporabom KNN algoritma

Prema slici 4.16 se u sluaju koritenja KNN algoritma za parametar =3 uzimaju uzorci obuhvaeni punim krugom. U takvom odabiru se novi uzorak klasificira kao trokut. Za =5 se uzimaju uzorci obuhvaeni isprekidanom krunicom. U tom sluaju se novi uzorak klasificira kao kvadrat. Odabir parametra k ovisi o prethodnim uzorcima, a u jednostavnijim praktinim primjenama se najee uzima vrijednost =3. Kao primjer koritenja u ovom istraivanju se moe prikazati predvianje vrijednosti parametra za teoretsku Weibull razdiobu temeljem prethodnih est vrijednosti po mjesecima kako je prikazano u tablici 4.7. Tablica 4.7 Prikaz raunanja budue vrijednosti parametara Weibull razdiobe uporabom KNN algoritma za podatke iz tablice 4.6 Distanca za t 1 2 3 4 5 6 7 1,5306 1,1038 1,6279 2,2743 1,5034 1,8509 ? 6 5 4 3 2 1 Najblii susjed za =3

2,2743 1,5034 1,8509

Na temelju izraunatih distanci za parametar t i odabranu vrijednost parametra rauna oekivana vrijednost parametra razdiobe kao: =(2,2743+1,5034+1,8509)/3 = 1,8762 (4-40)

se

64

5. Unaprjeenje scenarija provjere ERP sustava na temelju izraenog operacijskog profila

Operacijski profil u osnovi predstavlja vjerojatnost izvravanja skupa operacija na nekom programskom proizvodu [9]. U ovom doktorskom radu se razmatra primjena poznatih tehnika izrade operacijskih profila za pojedine module ERP sustava kako bi se unaprijedila njihova provjera nakon izvrenih prilagodbi. Operacijski profil se moe izraditi za itav ERP sustav ili za njegove pojedine dijelove (module). U postupku izrade operacijskog profila se istrauje nain koritenja ERP sustava kod stvarnih korisnika i utvruje uestalost koritenja pojedinih ugraenih funkcionalnosti. Na taj nain se jednostavno procjenjuje koliko je potrebno pojedine dijelove sustava provjeravati prije isporuke novih verzija sustava. Postupak izrade operacijskog profila se sastoji od dva osnovna dijela. U prvom se definiraju grupe (tipovi) kupaca prema djelatnostima i unutar njih pojedine grupe korisnika. U drugom dijelu se vri analiza funkcionalnosti koje su ugraene u promatrani ERP sustav kao i operacija koje unutar njih postoje. Naknadnim mjerenjima se utvruje uestalost pojedinih operacija na promatranom sustavu kod razliitih grupa kupaca. Kombinacijom prikupljenih podataka je mogue stvarati predloke provjere sustava koji su bliski stvarnim uvjetima. Kao primjer se moe navesti sluaj prilagodbe ERP sustava za odjel raunovodstva u jednoj graevinskoj tvrtki. Isti takav ERP sustav moe biti implementiran i kod drugih kupaca (npr. proizvodnja hrane ili trgovina) za istu grupe korisnika (raunovodstvo), ali oni vjerojatno ne koriste sustav na isti nain (npr. raunovodstvene politike su bitno razliite). Ukoliko je u navedenom primjeru izraen operacijski profil za promatranu grupu kupaca i pripadajue vrste korisnika mogue je prilikom provjere sustava obratiti panju na operacije koje drugi korisnici uope ne koriste (npr. obrauni situacija iz graevinske knjige) ili detaljnije testirati zajednike funkcionalnosti koje su za promatranu grupu korisnika ipak neto bitnije (npr. kod obrauna radnog vremena svi korisnici koriste isti modul, ali je kod graevinskih tvrtki to vrlo kritian dio sustava zbog voenja gradilita). Uobiajeno je provjeru ERP sustava vriti preko zadanih scenarija koritenja na temelju kojih su odreene prilagodbe dogovorene i naknadno izvedene. Meutim kod takve provjere ostaje otvoren problem odreenih posebnosti za neke grupe korisnika koje nisu nuno ugraene u scenarij koritenja, a mogu bitno utjecati na rezultat provjere (najee je ta posebnost vidljiva kao kombinacija odreenih ulaznih vrijednosti u aplikaciji). Kao primjer moe posluiti standardan izvjetaj iz jednog ERP modula koji je prikazan na slici 5.1. 65

Scenarij koritenja je kod poziva prikazanog izvjetaja za sve korisnike isti, tj. predvia odabir ponuenih parametara i ispis (pregled) izvjetaja. Potpuna provjera samo jednog dijela izvjetaja (npr. sa rekapitulacijom prometa) bi znaila provjeru svih kombinacija na koje se korisnik moe odluiti prilikom izrade izvjetaje. Analizom moguih odabira korisnika na ponuenoj ekranskoj formi (u grupi upita), uz odbacivanje kombinacija koje su posljedica korisnike konfiguracije (broj organizacijskih jedinica, lokacija ili robnih grupa artikala) se dobiva tablica 5.1. Mnoenjem ukupnog broja moguih vrijednosti za svaki parametar iz tablice 5.1 se dolazi do 8192 mogue kombinacije, tj. u najboljem sluaju neki korisnik moe formirati izvjetaj sa slike 5.1 na 8192 naina. Za cjelovitu provjeru opisanog izvjetaja je potrebno provesti testiranje koje bi obuhvatilo sve kombinacije ulaznih parametara za to bi trebalo, s obzirom na izraunati broj moguih kombinacija, predvidjeti znaajno vrijeme. U sluaju odreenog operacijskog profila, preko kojeg bi bilo sigurno utvreno kako korisnici vrlo rijetko vre odabir nekih parametara, broj kombinacija za provjeru opisanog dijela ERP sustava se bitno smanjuje. Operacijski profil bi trebao pomoi proizvoau ERP sustava u odluivanju na koje kombinacije ulaznih podataka e obratiti veu panju prilikom sistemske provjere (engl. system test), a koje e odbaciti jer se vrlo rijetko pojavljuju. Na taj nain e jednostavnije postaviti scenarije provjere koji e biti slini radu ERP sustava kod stvarnih korisnika. Operacijski profil takoer moe dati doprinos u pravilnijoj obuci korisnika, tj. moe ukazati na dijelove sustava koji se ee koriste u stvarnom radu pa ih korisnici moraju prilikom obuke i detaljnije upoznati, odnosno moe pomoi i u procjeni koje dijelove sustava je potrebno dodatno optimirati (suelje, ergonomija, brzina izvravanja i sl.) jer se esto koriste.

66

Slika 5.1 Skladini iskaz preuzet iz MPM modula (G2 ERP sustav)

Tablica 5.1 Mogue vrijednosti parametara za izvjetaj prema slici 5.1 Parametar Organizacijska jedinica Lokacija Robna grupa Prikaz internog prometa Pojedinaan promet artikala po lokacijama Artikli Stanje zaliha Poredak Jedinica mjere Koliinski/Vrijednosni Mogue vrijednosti Odabrana vrijednost Odabrana vrijednost Odabrana vrijednost Ukljueno Ukljueno Svi Pozitivna Oznaka Osnovna Koliinski Prazno Prazno Prazno Iskljueno Iskljueno Sa prometom Negativna Sva Naziv MPC VPC NC Ukupno 2 2 2 2 2 2 Nula 4 2 4

Kilogrami Metri Komadi 4

Definicija operacije se openito moe svesti na sliku 5.2 preuzetu iz [9]. Svako ulazno stanje podataka se preslikava na odreenu operaciju. Sva mogue ulazna stanja se 67

preslikavaju na domenu (engl. domain) koja je ustvari skup svih moguih operacija koje se mogu izvriti na promatranom dijelu ERP sustava.

Ulazno stanje

Operacija (Domena)

Slika 5.2 Operacija kao osnova operacijskog profila

Sukladno modelu sa slike 5.2 moe se rei kako svaka od moguih kombinacija ulaznih parametara koja je konstruirana iz tablice 5.1 predstavlja operaciju (engl. operation) na promatranoj funkcionalnosti ERP modula prikazanoj na slici 5.1. Nakon utvrivanja operacija na promatranom ERP sustavu je potrebno utvrditi vjerojatnost njihovog pojavljivanja na sustavu. U idealnom bi sluaju ERP sustav pratio svaku akciju korisnika, biljeio najee operacije nad podacima i o tome izvjetavao proizvoaa sustava koji bi naknadnom analizom mogao prilagoavati postojee postupke provjere sustava. Kod veih ERP sustava doista postoje aplikacijski servisi koji prikupljaju poruke s aplikacijskog posluitelja, ukljuujui i sve korisnike akcije unutar aplikacije (npr. kod SAPa je to tzv. System Log koji zapisuje podatke o izvrenim operacijama na lokalnom aplikacijskom posluitelju [46]). Meutim, kod manjih proizvoaa je to relativno rijetko, odnosno najee se posebno biljee samo bitni podaci koji utjeu na pouzdanost sustava kao to su razni sistemski zapisi o stanju baze podataka, rezervne pohrane podataka, neuspjenim prijavama na sustav i sl.. U studiji [52] je koriten alat MS SQL Profiler 2008 koji je dostupan na promatranom sustavu za upravljanje bazama podataka (Microsoft SQL Server [51]) pomou kojeg je bilo mogue pratiti i zapisivati sve SQL naredbe koje se iz aplikacije generiraju prema bazi podataka. Naknadnom analizom takvih zapisa su odreeni i prebrojani skupovi SQL naredbi koji odgovaraju promatranim operacijama na ERP sustavu.

68

5.1.

Postupci izrade operacijskog profila s primjenom u ERP sustavima

Izrada operacijskog profila se moe svesti na pet osnovnih koraka [9]: odreivanje grupa kupaca (engl. customer types) odreivanje vrsta korisnika (engl. user types) odreivanje naina rada sustava (engl. mode list) razvoj funkcijskog profila (engl. functional profile) pretvorba funkcijskog u operacijski profil (engl. operational profile)

Konaan rezultat je skup vjerojatnosti koritenja pojedinih funkcija i operacija na sustavu za razliite tipove korisnika [9]. Pri tome treba jasno rei to je to funkcija, a to operacija. Neki autori predlau da se pojam funkcije vee uz fazu specifikacije zahtjeva prilikom izrade bilo kakvog programskog proizvoda, tj. da se svaki implementirani korisniki zahtjev smatra funkcijom [17]. Popis svih funkcija ini podlogu za razvoj funkcijskog profila. Npr. prema opisanom primjeru sa slike 5.1 funkcije se mogu najjednostavnije vezati na parametre izvjetaja koji su popisani u tablici 5.1. Vie takvih funkcija ini jedan skup koji opisuje neku funkcionalnost ERP sustava [47], npr. u navedenom primjeru je to nekakav sloeni izvjetaj. Funkcijski profil se izrauje po pojedinim funkcionalnostima ERP sustava kao skup funkcija od kojih je neka funkcionalnost nainjena [9]. Bilo koja funkcija unutar nekog ERP sustava moe imati razliite vrijednosti ulaznih parametara, npr. u promatranom primjeru prema slici 5.1 korisnik ima ugraenu funkciju odabira skladinog iskaza s rekapitulacijom prometa, a u koritenju takve funkcije korisnik moe odabrati neku robnu grupu koju je prije definirao u svom ERP sustavu ili je jednostavno preskoiti prilikom poziva izvjetaja. Mogunost razliitih vrijednosti ulaznih parametara (u promatranom primjeru najmanje deset) nuno dovodi do velikog broja razliitih kombinacija, od kojih svaka predstavlja razliito koritenje sustava i naziva se operacijom. Moe se rei kako operacijski profil ine skupovi operacija i da se u pretvorbi funkcijskog u operacijski profil utvruje jedinstvena kombinacija ulaznih parametara za pojedine funkcije, tj. operacija je koritenje odreene funkcionalnosti pri emu ugraene funkcije imaju jedinstvene vrijednosti ulaznih parametara [9].

69

Primjerice, za prikazani primjer sa slike 5.1 je jedna operacija poziv izvjetaja s parametrima:
{

Organizacijska jedinica=Prazno Lokacija=Prazno Robna grupa=Prazno Prikaz internog prometa=Iskljueno Pojedinaan promet artikala po lokacijama=Iskljueno Artikli=Sa prometom Stanje zaliha=Negativna Poredak=Naziv Jedinica mjere=Kilogrami Koliinski/Vrijednosni=MPC
}

Na promatranom ERP sustavu se naknadno mogu mjeriti vjerojatnost pokretanja takvih malih dijelova sustava za odreena ulazna stanja koja onda ine skup vjerojatnosti iz kojih se izrauje operacijski profil.

5.2.

Kratki opis ERP modula za kojeg je izraen operacijski profil

Tijekom izrade ovog doktorskog rada je provedeno istraivanje u ijoj je studiji prezentiran postupak izrade operacijskog profila za jedan modul koji je dostupan u ERP sustavu pod nazivom SWING G2. Proizvoa sustava je tvrtka Swing Consulting d.o.o. sa sjeditem u Splitu. Vie o proizvoau ERP sustava je mogue pronai na [43]. Na slici 5.3 je prikazana struktura SWING G2 sustava s pojedinim modulima. Promatran je modul Knjiga Ulaznih/Izlaznih rauna (ili krae G2 URA/IRA) koji slui za biljeenje svih ulaznih i izlaznih rauna koji se unose u sustav preuzimanjem obrada drugih modula (npr. prijemi robe i materijala, veleprodajni i maloprodajni rauni) ili se unose unutar samog modula (npr. ulazni rauni za usluge, energiju i sl.). Na temelju generiranih dokumenata u promatranom modulu je mogue voditi propisane evidencije poreza na dodanu vrijednost (PDV) kao to su knjige ulaznih i izlaznih rauna, mjeseni i godinji obrauni poreza do dodanu vrijednost u skladu s pravilnicima Ministarstva financija RH (modul je takoer posebno prilagoen za trite Bosne i Hercegovine). Vie o porezu na dodanu vrijednost u RH je mogue pronai na [48]. Osim zakonom propisanih evidencija PDV-a, modul se koristi i kao protokol ulaznih rauna unutar kojeg je mogue dokument pripremiti za knjienja u glavnoj knjizi (koritenjem predloaka prema zadanim shemama knjienja odreenih vrsta rauna ili posebnim unosom korisnika), s 70

automatiziranim generiranjem naloga za plaanje i naknadnom autorizacijom u posebnom modulu za platni promet.

G2 PRODUCTION PLANNING G2 MATERIALS MANAGEMENT G2 HUMAN RESOURCES

G2 SALES AND DISTRIBUTION

G2 FINANCIALS AND CONTROLING

Books-InputOutput invoices Cash desk General Ledger Accrued interest

Slika 5.3 Struktura G2 ERP sustava

5.3.

Odreivanje grupe kupaca

Pod pojmom grupe kupaca se najee definira skup vie korisnika koji promatrani ERP sustav koriste na isti ili slian nain [9]. Najee se te grupe poklapaju s ciljanim grupama kupaca definiranim od strane proizvoaa ERP sustava (npr. maloprodaja, financijske institucije, proizvodnja itd.). U studiji [52] su grupe kupaca definirane prema postojeoj evidenciji iz CRM sustava instaliranog kod proizvoaa ERP sustava. Analizom dostupnih podataka napravljena je tablica 5.2 koja prikazuje zastupljenost G2 modula URA/IRA po pojedinim grupama kupaca. Udjeli grupa kupaca se naknadno mogu povezivati s udjelima pojedinih vrsta korisnika, a konani rezultat je izrada potpunog korisnikog profila koji je prikazan u tablici 5.5.

71

Tablica 5.2 Primjer odreivanja grupa kupaca prilikom izrade operacijskog profila Tip kupca Graevinarstvo Financijske ustanove Dravna i lokalna uprava Obrazovne ustanove Raunovodstvo, revizija i poslovno savjetovanje Trgovina Proizvodnja Ostalo Ukupno Broj kupaca 54 27 34 29 327 697 148 23 1339 Udjel [%] 4,03 2,02 2,54 2,17 24,42 52,05 11,05 1,72 100,00

5.4.

Odreivanje vrsta korisnika

Vrste korisnika predstavljaju grupe korisnika koje sustav koriste na isti nain [9]. Ta podjela kod ERP sustava moe biti izvedena prema razliitim kriterijima kao to su sloenost posla, radno iskustvo korisnika i sl. Za potrebe studije [52] je napravljena najjednostavnija podjela prema sloenosti posla na obine i napredne korisnike. Prema takvoj podjeli obini korisnici obavljaju unos rauna, definiranje kontnih oznaka za prijenos u glavnu knjigu i pripremu obrada za glavnu knjigu. Napredni korisnici mogu koristiti dodatne funkcionalnosti kao to su: prijenos podataka koji su rezultat obrada u drugim ERP modulima, podeavanje parametara modula, podeavanje automatskih knjienja, obraun poreza na dodanu vrijednost, zatvaranje poslovne godine, elektronski prijenos podataka prema modulima drugih proizvoaa i razliitim sustavima porezne uprave [49], slanje rauna na plaanje i odravanje modula. Udjel pojedinih vrsta korisnika se moe kombinirati s udjelima definiranih grupa korisnika kao u tablici 5.5.

5.5.

Naini rada sustava

U izradi operacijskog profila nekog ERP sustava se mogu definirati razliiti naini rada sustava. U definiranju razliitih naina rada ERP sustava se obino razmatraju neki od navedenih kriterija [9]: 72

koritenje odreenih funkcionalnosti (unos podataka, pregled izvjetaja, administriranje sustava) radni uvjeti (visoko optereenje sustava, normalno optereenje) transakcije (unos podataka u realnom vremenu, pozadinske obrade)

U sklopu studije [52] je zbog jednostavnijeg mjerenja primijenjen kriterij koritenja odreenih funkcionalnosti pa su tako izdvojena dva osnovna naina rada promatranog ERP modula, a to su redovna uporaba u kojoj se izvravaju prethodno navedene funkcionalnosti pridruene grupi obinih korisnika i napredna uporaba u kojoj se izvravaju dodatne funkcionalnosti dostupne naprednim korisnicima.

5.6.

Izrada operacijskog profila

Za promatrani ERP modul je napravljen operacijski profil prema uestalosti pojave pojedinih ulaznih klasa podataka [52]. Kako bi to bilo mogue potrebno je raspolagati mjernim sustavom koji biljei sve izvrene operacije na nekom ERP sustavu. Vei proizvoai ERP sustava uz instalirano ERP rjeenje esto isporuuju poseban modul koji nadzire ponaanje itavog ERP sustava u nekoliko slojeva (baza podataka, aplikacijski posluitelj, programski moduli) i biljee sve operacije koje se izvravaju na ERP sustavu (npr. kod SAP ERP rjeenja je to tzv. SAP Instance platforma). Naalost, kod promatranog ERP sustava [12] nije postojalo takvo praenje rada korisnika. Zato je u [ 52] uspostavljeno mjerenje u kojem su biljeene sve transakcije iz promatranog ERP modula prema koritenoj bazi podataka sa svrhom prepoznavanja izvrenih operacija. U prvom koraku je pregledana razvojna dokumentacija i korisnike upute za rad kako bi se odredile sve funkcije koje su u G2 modulu URA/IRA ugraene, npr. unos izvoda ulaznog ili izlaznog rauna, zadavanje raunovodstvenih konta za evidentirani raun, odreeni izvjetaji i sl. Zatim su za tako odreene funkcije izvedene mogue operacije, npr. u funkciji unosa stavke izvoda ulaznog rauna korisnik moe odabrati operacije unosa novog, izmjene ili brisanja postojeeg ulaznog rauna. Za svaku utvrenu operaciju je utvrena grupa naredbi koja se generirala prema bazi podataka u trenutku kada je korisnik izvravao takvu operaciju na modulu. Uoeno je jednostavno pravilo po kojem se kod pokretanja svih operacija izvravao karakteristian niz od nekoliko pohranjenih SQL procedura (engl. SQL stored procedure).

73

Praenje transakcija na svakoj lokaciji trajalo je pet radnih dana (ukupno 40 sati po lokaciji), a svi zapisi su pohranjeni u bazi podataka na promatranoj lokaciji. Namjerno je odabran period u kojem se promatrani modul inae koristi s veinom ugraenih funkcija, a to je kraj poreznog razdoblja za obraun PDV-a (zadnjih pet radnih dana u mjesecu). Svi zapisi su izvezeni u posebne zajednike tablice pridruene utvrenim grupama kupaca. Na takvim je tablicama naknadno izvreno grupiranje uestalosti koritenja pojedinih skupova transakcija koji su prethodno pridruene pojedinim operacijama na promatranom ERP modulu. Prilikom izrade operacijskog profila za G2 modul URA/IRA su analizirane instalacije prema grupama kupaca iz tablice 5.2 uz odreena pojednostavljenja detaljnije opisana u podtoki 5.9. U idealnom sluaju je to znailo praenje koritenja modula kod svih korisnika to u prikazanoj studiji nije bilo mogue iz niza tehnikih razloga. Zato je za svaku utvrenu grupu kupaca iz tablice 5.2 odabrano nekoliko reprezentativnih korisnika kod kojih je bilo mogue pratiti rad sustava.

5.7. Opis koritenja alata Microsoft SQL Profiler u izradi operacijskog profila
Microsoft SQL Profiler [50] je alat dostupan u svim punim verzijama Microsfot SQL posluitelja. U osnovi je rije o jednostavnom alatu koji prikuplja sve podatke o k omunikaciji izmeu klijentske aplikacije i Microsoft SQL posluitelja. Nain rada je prikazan na slici 5.4.

DOGAAJI NA POSLUITELJU (SQL EVENTS)

TRAG (SQL TRACE) FILTER

SKUP DOGAAJA

BAZA PODATAKA

DATOTEKA

SMO (SQL SERVER MANAGEMENT OBJECTS)

SQL SERVER PROFILER

KORISNIKA APLIKACIJA

Slika 5.4 Prikaz koritenja alata Microsoft SQL Profiler 74

Prikupljanje dogaaja na SQL posluitelju je mogue vriti uporabom gotovih predloaka ili podeavanjem vlastitih tragova (engl. trace). Prije pokretanja tragova je mogue zadati odreena ogranienja kao npr. biljeenje samo onih dogaaja koje je pokrenula odreena aplikacija na klijentskoj strani. Po zavretku praenja zadanog traga rezultati se mogu pohraniti u posebnoj datoteci ili se moe napraviti izvoz (engl. export) u posebnu tablicu na nadziranom ili nekom drugom SQL posluitelju. Prilikom mjerenja na promatranim instalacijama ERP sustava G2 je koriten postojei predloak SQLProfilerStandard koji je biljeio dogaaje prema atributima iz tablice 5.3. Zapisi su se odmah biljeili u SQL tablici TraceOP baze podataka UI_RA_OP na svakoj od lokacija gdje je provedeno mjerenje. Koncept arhitekture mjernog sustava koji je postavljen na svakoj od promatranih lokacija je prikazan na slici 5.

Microsoft SQL Server 200X DBMS - promatrana lokacija

Klijent - promatrana lokacija

G2K_SCHEMA BAZA PODATAKA

G2 UI-RA modul

MS SQL PROFILER

UI_RA_OP BAZA PODATAKA

Analiza prikupljenih zapisa sa svih promatranih lokacija i izrada operacijskog profila

Tablica TraceOP

Baza podataka

Slika 5.5 Postavljeni sustav za izradu operacijskog profila

Realizacija tablice TraceOP u kojoj su pohranjeni zabiljeeni dogaaji za svaku od promatranih lokacija se moe opisati slijedeom strukturom iz tablice 5.3.

75

Tablica 5.3 Opis atributa SQL tablice TraceOP u kojoj se biljee tragovi na promatranoj lokaciji Atribut (dogaaj) RowNumber EventClass TextData Opis Redni broj zapisa Klasa dogaaja Tip int int ntext nvarchar (128) int nvarchar (128) nvarchar (128) int bigint datetime bigint

Tekst naredbe koja se izvrava na SQL posluitelju NTUserName Windows ime korisnika ili servisa koji izvrava naredbu ClientProcessID ID procesa (aplikacije) na klijentskom raunalu koji pokree naredbu na SQL posluitelju ApplicationName Ime klijentske aplikacije koja pokree naredbu na SQL posluitelju LoginName Korisniko ime koje pokree naredbu na SQL posluitelju SPID ID procesa na SQL posluitelju koji pokree naredbu Duration Trajanje naredbe u mikrosekundama (u starijim verzijama SQL posluitelja u milisekundama) StartTime Vrijeme poetka izvravanja naredbe Reads Broj fizikih pristupa diskovima SQL posluitelja u itanju iz baze podataka, tijekom zadane naredbe Broj fizikih pristupa diskovima SQL posluitelja prilikom pisanja u bazu podataka, tijekom zadane naredbe Zauzee procesora u milisekundama tijekom izvrenja naredbe na SQL posluitelju

Writes

bigint

CPU

int

Prilikom biljeenja rezultata pokrenutih tragova je u tablici TraceOP izvreno filtriranje dogaaja kako bi se zapisivali samo oni koji su bitni za izradu operacijskog profila promatranog ERP modula. Tako je npr. koriten filter na atributu ApplicationName koji je postavljen na vrijednost 'UI-RA%' kako bi se biljeili samo oni dogaaji koji su rezultat izvrenih operacija iz promatranog modula. Takoer je postavljen filter 'EXECUTE%' na atributu TextData kako bi se pratilo samo izvravanje pohranjenih procedura na SQL posluitelju. Ovako reducirani podaci su po zavretku promatranja izvezeni u zajedniku bazu

76

podataka gdje su posebno obraeni sa svrhom izrade operacijskog profila promatranog ERP modula.

5.8. Primjer identifikacije i biljeenja operacija na promatranom ERP modulu

Kako bi se unutar dostupnog traga sa SQL posluitelja ustanovilo kada je neka operacija pozvana utvreno je koje se naredbe izvravaju na SQL posluitelju kada je korisnik izvravao tu operaciju unutar ERP modula. Kao primjer identifikacije operacija na G2 modulu URA/IRA je navedena operacija dodavanja novog izvoda ulaznih rauna, a izvoenje navedene operacije na promatranom ERP modulu je prikazano na slici 5.6.

Slika 5.6 Operacija dodavanje novog izvoda u knjizi ulaznih rauna G2 URA/IRA modulu

Rezultat pokretanja navedene operacije je na SQL posluitelju je vidljiv kao izvravanje pohranjene procedura kra_stavka_RH20100101 i zabiljeen je u tablici TraceOP unutar atributa TextData kao: EXECUTE kra_stavka_RH20100101_sel @kra_sys_oznaka='ura', @kra_izvod_id=0 Moe se rei kako je prethodni poziv pohranjene procedure kra_stavka_RH20100101_sel s parametrima @kra_sys_oznaka, @kra_izvod_id jedinstven za operaciju dodavanja novog

77

izvoda knjige ulaznih rauna. Na slian nain je npr. ustanovljeno da se prilikom brisanja stavke izvoda ulaznih rauna poziva pohranjena procedura kra_stavka_update kao: EXECUTE kra_stavka_update @action='DELETE', @kra_sys_oznaka='ura', @kra_izvod_id = 359

Takoer je prilikom spremanja izmjena u postojeem izvodu izdvojeno izvravanje pohranjene procedure kra_izvod_update kao: EXECUTE kra_izvod_update @action='POST_UPDATE', @kra_izvod_id=360, @kra_pravilnik = 'RH20100101'

Ako se utvrdi pravilo koje jednoznano definira neku operaciju iz ERP modula preko poziva pohranjenih procedura na SQL posluitelju (kao u prethodno prikazanim primjerima), tada je mogue utvrditi vjerojatnost poziva pojedinih operacija u promatranom ERP modulu, odnosno mogue je jednostavno izraditi operacijski profil. itav postupak se svodi na prebrojavanje zabiljeenih poziva pojedinih SQL naredbi spremljenih u tablici dogaaja koja je stvorene iz tragova pokrenutih na razliitim lokacijama. Nakon prebrojavanja skupova naredbi koje predstavljaju pojedine operacije mogue je utvrditi njihovu uestalost u ukupnom broju izvrenih operacija. Tako je u [52] utvreno kako se u promatranom periodu na lokacijama koje su predstavljale grupu korisnika Trgovina iz promatranog ERP modula izvrilo ukupno 30189 operacija, od ega je bilo 7157 operacija koje su predstavljale dodavanje, brisanje i izmjenu postojeih izvoda ulaznih rauna, odnosno 34,24%. od ukupnog broja izvrenih operacija. Ako bi se npr. ERP modul elio provjeriti nakon neke prilagodbe za navedenu grupu korisnika bilo bi potrebno izvriti priblino 34% operacija dodavanja, brisanja i izmjene izvoda ulaznih rauna od ukupnog broja izvrenih operacija prilikom provjere.

5.9.

Rezultati istraivanja u izradi korisnikog profila

Prilikom izrade korisnikog profila je ustanovljen trini udjel za pojedine grupe kupaca prema tablici 5.2. Pritom su napravljena odreena pojednostavljenja sukladno preporukama iz [17], tj. grupe korisnika koje predstavljaju manje od 5% ukupnog korisnikog udjela su

78

pridruene slinim grupama korisnika. Tako su napravljena pojednostavljenja za odreene grupe korisnika iz tablice 5.2. uz slijedee pretpostavke: grupa korisnika Graevinarstvo koristi G2 ERP sustav slino kao grupa Proizvodnja i svi korisnici iz te grupe se pribrajaju grupi Proizvodnja sve ostale grupe korisnika s udjelom manjim od 5% u ukupnom broju korisnika koriste ERP sustav slino kao grupa Raunovodstvo, revizija i poslovno savjetovanje i pribrajaju se navedenoj grupi Razmatrane grupe korisnika s pripadajuim udjelima su prikazane u tablici 5.5. Koritenjem postupaka i alata prikazanih u potpoglavlju 5.8 je ustanovljeno koliko utvrene grupe korisnika iz potpoglavlja 5.4 (obini i napredni korisnici) koriste promatrani modul. Kako bi to bilo mogue poetno je napravljena podjela operacija po grupama korisnika koja je prikazana u tablici 5.4.

79

Tablica 5.4. Podjela operacija po grupama korisnika Funkcija Unos, izmjena podataka knjiga ulaznih rauna Operacija Novo/Izmjena/Brisanje izvoda ulaznih rauna Novo/Izmjena/Brisanje stavki unutar izvoda ulaznih rauna Novo/Izmjena/Brisanje oznaka kontiranja ulaznih rauna za prijenos u glavnu knjigu Novo/Izmjena/Brisanje izvoda izlaznih rauna Novo/Izmjena/Brisanje stavki unutar izvoda izlaznih rauna Novo/Izmjena/Brisanje oznaka kontiranja izlaznih rauna za prijenos u glavnu knjigu Pregled, kontrolni obraun ili ispis knjige izlaznih rauna Pregled, kontrolni obraun ili ispis knjige ulaznih rauna Pregled, kontrolni obraun ili ispis obrauna PDV-a Otvaranje ili izmjena automatskih predloaka za knjienje ulaznih rauna Otvaranje ili izmjena automatskih predloaka za knjienje izlaznih rauna Zatvaranje obraunskog perioda (mjeseno ili godinje) Autorizacija i slanje na plaanje u modulu platnog prometa Prijenos obrada u glavu knjigu Grupa korisnika Obini korisnk Obini korisnk Obini korisnk Obini korisnk Obini korisnk Obini korisnk Obini korisnk Obini korisnk Obini korisnk Napredni korisnik Napredni korisnik Napredni korisnik Napredni korisnik Napredni korisnik

Unos, izmjena podataka knjiga izlaznih rauna

Izvjetaji izlazni rauni Izvjetaji ulazni rauni Izvjetaji PDV obraun Izmjena postavki knjienja

Priprema za plaanje. Autorizacija plaanja, Slanje na plaanje Prijenos podataka u glavnu knjigu

Kako bi se ustanovilo koliko esto sustav koriste napredni korisnici iz neke grupe kupaca prebrojane su sve operacije iz tablice 5.4 koje su pridruene takvim korisnicima, a zabiljeene su u tragovima kod pripadajue grupe kupaca prilikom mjerenja sa slike 5.5.

80

Tako je prema [52] za pet referentnih korisnika iz grupe kupaca Trgovina utvreno slijedee: od ukupnog broja operacija 93% je izvreno unutar grupe obian korisnik od ukupnog broja operacija 7% je izvreno unutar grupe napredan korisnik

Udjeli pojedinih grupa korisnika su utvreni za sve razmatrane grupe kupaca i prikazani su u tablici 5.5. Naknadno su ti udjeli preraunati prema udjelima pripadajuih grupa kupaca. Tako je doprinos grupe korisnika za neku grupu kupaca izraunat kao produkt dva prethodno izmjerena udjela iz tablice 5.5. Prvi lan produkta je utvreni udjel grupe kupaca, a drugi je udjel pripadajue korisnike grupe. Kao primjer je navedeno raunanje doprinosa po vrstama korisnika, za grupu kupaca Trgovina iz tablice 5.5. Doprinos (Obini korisnici) iz grupe kupaca (Trgovina) = 0,52 * 0,93 = 0,48 Doprinos (Napredni korisnici) iz iz grupe kupaca (Trgovina) = 0,52 * 0,07 = 0,04 (5-1) (5-2)

Na isti nain je mogue raunati doprinose ostalih grupa kupaca i prikazati ih u tablici 5.5 Zbrajanjem svih utvrenih doprinosa za odreenu vrstu korisnika po svim grupama kupaca iz tablice 5.5 je zakljueno kako promatrani G2 URA/IRA modul u 93% operacija koriste Obini korisnici, a u 7% operacija Napredni korisnici. Dobiveni se rezultat moe koristiti u izradi scenarija provjere itavog ERP modula nakon veih prilagodbi, tj. sustav e biti provjeren sukladno stvarnom koritenju ako prilikom provjere bude ukljueno 93% operacija koje koristi grupa Obini korisnici. Ako se razmotri podjela operacija iz tablice 5.4 tada je zastupljenost operacija iz grupe Obini korisnici u ukupnom broju moguih operacija bitno nia i iznosi priblino 64 %. Oito je kako se u stvarnom koritenju modula ne izvravaju sve operacije jednako esto, a korisniki profil jasno odreuje koliko teite na pojedine operacije treba staviti prilikom provjere promatranog ERP modula kako bi se oponaao stvarni rad sustava.

81

Konani korisniki profil za promatrani ERP modul je prikazan u tablici 5.5.

Tablica 5.5 Korisniki profil za G2 URA/IRA ERP modul Grupa kupaca Raunovodstvo, revizija i Trgovina poslovno savjetovanje 0,33 Ukupni doprinos grupe korisnika za grupu kupaca Udjel grupe korisnika u grupi kupaca 0,52 Ukupni doprinos grupe korisnika za grupu kupaca Udjel grupe korisnika u grupi kupaca Proizvodnja

Udjel u ukupnom broju kupaca 0,15 Ukupni doprinos grupe korisnika za grupu kupaca 0,14 0,01 Udjel grupe korisnika u grupi kupaca Ukupni udjel grupe korisnika 0,93 0,07

Napredni Obini korisnici korisnici

0,94

0,31

0,93

0,48

0,90

0,06

0,02

0,07

0,04

0,10

5.10. Rezultati istraivanja u izradi operacijskog profila

U konanici su prema [52] nainjeni operacijski profili za sve grupe kupaca. Kao primjer je naveden operacijski profil za grupu kupaca Proizvodnja i prikazan u tablici 5.6. Sve operacije su grupirane prema pripadajuim funkcijama. Izraunata je vjerojatnost koritenja pojedinih funkcija unutar modula, a za svaku operaciju je izraunata vjerojatnost izvravanja unutar odgovarajue funkcije. Kao primjer se moe navesti sluaj iz tablice 5.6 prema kojem je vjerojatnost koritenja funkcije unosa i izmjene ulaznih rauna iznosi 69,24%, a unutar te funkcije se operacija unosa i izmjene stavki izvoda pojavljuje s vjerojatnou od 54,67%. Iz tablice 5.6 je vidljivo kako nije nainjena detaljna podjela operacija npr. nisu odvojene operacije novi izvod i brisanje postojeeg. Razlog je nain brojanja pojedinih operacija na 82

ostvarenom mjernom sustavu sa slike 5.5, tj. pojava pojedine operacije je izjednaena s pozivom pripadajue pohranjene procedure na SQL posluitelju. U prikazanom istraivanju [52] nije uvijek bilo mogue odvojiti operacije koje su prilikom izvravanja pozivale istu pohranjenu proceduru npr. operaciju novi od operacije ureivanje postojeeg izvoda ulaznih rauna. Grupiranje operacija po pojedinim funkcijama unutar prikazanog ERP modula je nainjeno jer omoguava jednostavno definiranje scenarija provjere za svaku pojedinu funkciju, npr. ako se eli provjeriti samo funkcija Izmjena postavki automatskih knjienja, tada se u scenarij provjere uvrtavaju samo pripadajue operacije prema utvrenim vjerojatnostima poziva unutar te iste funkcije. Naravno, mogue je raunati i vjerojatnost pojave pojedinih operacije u sluaju provjere itavog modula, ali tada se mnoe vjerojatnosti iz oba stupca tablice 5.6 za sve operacije, npr. ako se vri provjera itavog modula, tada se operacija Novo/Izmjena/Brisanje izvoda ulaznih rauna (prema tablici 5.6) uzima s vjerojatnou: 0,6924*0,3424 = 23,71% (5-3) Mogue je nainiti i tablicu koja bi utvrdila skupni doprinos svih grupa kupaca na ukupni operacijski profil. Tako je npr. doprinos grupe kupaca Proizvodnja utvren mnoenjem svih vrijednosti iz tablice 5.6 s udjelom te grupe kupaca iz tablice 5.5. Izraunati doprinosi svih grupa kupaca su zbrojeni u konanu tablicu operacijskog profila za sve korisnike ERP modula. Dio takvog postupka je prikazan u tablici 5.7.

83

Tablica 5.6 Operacijski profil za grupu kupaca Proizvodnja Funkcija Unos, izmjena podataka knjiga ulaznih rauna Vjerojatnost Operacija 69,24% Unos/Izmjena/Brisanje izvoda ulaznih rauna Unos /Izmjena/Brisanje stavki unutar izvoda ulaznih rauna Unos /Izmjena/Brisanje oznaka kontiranja ulaznih rauna za prijenos u glavnu knjigu Unos /Izmjena/Brisanje izvoda izlaznih rauna Unos /Izmjena/Brisanje stavki unutar izvoda izlaznih rauna Unos /Izmjena/Brisanje oznaka kontiranja izlaznih rauna za prijenos u glavnu knjigu Pregled, kontrolni obraun ili ispis knjige izlaznih rauna Pregled, kontrolni obraun ili ispis knjige ulaznih rauna Pregled, kontrolni obraun ili ispis obrauna PDV-a Otvaranje ili izmjena automatskih predloaka za knjienje izlaznih rauna Otvaranje ili izmjena automatskih predloaka za knjienje ulaznih rauna Autorizacija i slanje na plaanje u modulu platnog prometa Prijenos obrada u glavu knjigu Vjerojatnost 34,24% 54,67%

11,09%

Unos, izmjena podataka knjiga izlaznih rauna

19,21%

19,87% 64,46%

15,67%

Izvjetaji izlazni rauni 0,43% Izvjetaji ulazni rauni 0,45% Izvjetaji PDV obraun Izmjena postavki automatskih knjienja 0,21% 0,10%

100%

100% 100% 43%

57%

Priprema za plaanje. Autorizacija plaanja, Slanje na plaanje Prijenos u glavnu knjigu

4,55% 5,81%

100% 100%

84

Tablica 5.7 Primjer izrade dijela ukupnog operacijskog profila za sve kupce G2 URA/IRA ERP modula Raunovodstvo, revizija i poslovno savjetovanje 52%

Grupa kupaca Udjel grupe kupaca Operacija Novo/Izmjena/Brisanje izvoda ulaznih rauna Novo/Izmjena/Brisanje stavki unutar izvoda ulaznih rauna Novo/Izmjena/Brisanje oznaka kontiranja ulaznih rauna za prijenos u glavnu knjigu

Proizvodnja 15% Vjerojatnost 34,24% 54,67%

Trgovina 33%

Ukupno 100% Vjerojatnost 39,33% 52,30%

Vjerojatnost Vjerojatnost 36,58% 57,64% 42,54% 48,23%

11,09%

5,78%

9,23%

8,37%

U tablici 5.7 je vidljivo kako se vjerojatnost pojave operacije Novo/Izmjena/Brisanje izvoda ulaznih rauna u konanom operacijskom profilu rauna kao zbroj doprinosa po svim grupama korisnika iz tablice 5.5: (5-4) 15%*34,24%+33%*36,58%+52%*42,54%=39,33% (5-5)

Postupak je potrebno ponoviti za sve operacije koje su prethodno odreene za pojedine grupe kupaca. Ukupni operacijski profil se moe koristiti kada se vri provjera za prilagodbu koja se isporuuje svim kupcima. Kada se vri prilagodba samo za jednu grupu korisnika tada se moe koristiti prethodno odreen operacijski profil samo za tu grupu.

5.11. Primjer koritenja operacijskog profila u izradi scenarija provjere ERP modula
Sukladno definiciji [9] i prikazanim tablicama 5.6 i 5.7 se moe zakljuiti kako operacijski profil koji je nainjen za neki ERP modul (ili itavi ERP sustav) predstavlja skup vjerojatnosti pojave odreenih operacija za neku grupu korisnika (ili vie njih) prilikom stvarnog koritenja ERP sustava, Primjena operacijskog profila se svodi na izradu takvog scenarija provjere u kojem su pojedine operacije zastupljene prema izraenom operacijskom profilu. Npr. u 85

sluaju provjere opisanog ERP modula iz [52], oito je prema tablici 5.6 potrebno posebnu panju posvetiti operacijama koje se odnose na obrade ulaznih rauna. Poznato je iz [54] da se prilikom provjere (testiranja) bilo kojeg programskog proizvoda provode: test dijela programskog koda (engl. unit test) integracijski test (engl. integration test) sistemski test (engl. system test)

Prvu provjeru sustava provode programeri koji testiraju svoj dio programskog koda (unit test). Primjena operacijskog profila u toj fazi nema smisla jer programer primjenjuje postupke koji rezultiraju test podacima optimiranima tako da otkriju prisustvo pogreke u dijelu novog programskog koda (provjera rubnih uvjeta, svih logikih puteva i sl.) i koji ne oponaaju stvarni rad sustava (npr. funkcionalno testiranje ili engl. black-box testing, strukturalno testiranje ili engl. white-box testing, testiranje po putevima ili engl. path-based testing [53]). Kod integracijskog testa se provjeravaju svi dijelovi na kojima su vrene prilagodbe i njihova suelja. Kod proizvoaa promatranog ERP modula ovaj test takoer provode programeri i operacijski profil nije nuan za dobru provjeru sustava jer se u integracijskom testu provjeravaju dijelovi sustava koji su kritini u povezivanju dijelova sustava. U primjeru ERP modula iz [52] se u integracijskom testu posebno provjerava integracija prilagoenog suelja ili komunikacija izmijenjenog suelja za unos podataka sa SQL posluiteljem, komunikacija modula s G3 komponentama za prikaz izvjetaja i sl. Sistemski test po definiciji [54] predstavlja formalnu potvrdu funkcionalne specifikacije itavog sustava (engl. Functional Requirement Specification), a kod ERP sustava moe predstavljati provjeru itavog ERP modula ili itavog ERP sustava. Kod proizvoaa ERP sustava iz [52] ovakvo testiranje provode djelatnici koji upravljaju kontrolom kvalitete (engl. QA - quality assurance tester) i koji nisu dio razvojnog tima, odnosno oni nakon izrade prilagodbe prije isporuke kupcu provjeravaju usklaenost prilagodbe prema funkcionalnoj specifikaciji. Budui je broj moguih operacija koje se pri tome provjeravaju vrlo velik, najee se koriste unaprijed zadani scenariji provjere s ulaznim podacima koji se automatski izvravaju na test sustavu proizvoaa. Operacijski profil moe posluiti u izradi takvih scenarija provjere, odnosno sigurno moe pomoi u odluci koji je dio sustava potrebno provjeravati vie ako je to utvreno kod stvarnih korisnika ili se mogu unaprijed odbaciti neke operacije koje se kod stvarnih korisnika vrlo rijetko koriste. U konanici je vrijeme provjere bitno skraeno jer se prilikom provjere oponaa stvarni rad sustava.

86

Kao primjer koritenja operacijskog profila moe posluiti tablica 5.7, odnosno moe se prikazati primjena operacijskog profila u provjeri prilagodbe postojee funkcionalnosti Unos, izmjena podataka knjiga ulaznih rauna. U prikazanom primjeru vrijedi pretpostavka kako se provjerava samo ta funkcija, a ne itav modul, tj. podrazumijeva se kako prilagodba ove funkcije ne utjee na ostale dijelove modula. Prilikom izrade plana provjere djelatnici koji vode kontrolu kvalitete mogu izvriti N puta navedene operacije iz tablice 5.7. Npr. prilikom provjere izvrit e X puta operaciju Novo/Izmjena/Brisanje izvoda ulaznih rauna, Y puta operaciju Novo/Izmjena/Brisanje stavki unutar izvoda ulaznih rauna i Z puta operaciju Novo/Izmjena/Brisanje oznaka kontiranja ulaznih rauna za prijenos u glavnu knjigu. Dakle, vrijedi: (5-6) Iz (5-6) i tablice 5.7 proizlazi trivijalno rjeenje koliko e puta biti izvrene pojedine operacije prilikom provjere sustava, tj. dovoljno je odrediti koliko e se puta izvriti najmanje zastupljena operacija (u prikazanom primjeru je to Z), a zastupljenost preostalih operacija se odreuje prema vjerojatnostima iz tablice 5.7. Do konanog rezultata se dolazi preko omjera vjerojatnosti, npr. ako je =5, odredi se omjer vrijedi da je = Z , tj. koji je jednak omjeru . Za prikazani primjer

je uz zaokruivanje na veu vrijednost jednak 32. Uz poetno

postavljeni Z se na isti nain se rauna da je X jednak 24. Ukupan broj operacija koje e se izvriti prilikom provjere , tada prema (5-6) iznosi 61.

87

6. Modeliranje utjecaja nadogradnje na pouzdanost ERP sustava

Svi ERP sustavi su izloeni stalnim promjenama i prilagodbama jer tvrtke koje ih koriste stalno mijenjaju poslovne procese s konanim ciljevima djelotvornijeg poslovanja i poveanja profita [26]. Rezulat takvih procesa su nova izdanja (engl. release) sustava koja su usklaena s traenim promjenama, a uobiajeni naziv skupa izmjena koje se uvode u postojei sustav kao posljedica traenih prilagodbi se naziva nadogradnja (engl. upgrade). Brzina pojave nadogradnji na nekom ERP sustavu ovisi uglavnom o poslovnom okruenju unutar kojeg je implementiran. Uvoenje nadogradnje kao posljedice prilagodbe ERP sustava je u opreci s potrebom za stabilnou i robusnosti ERP sustava pa se zato obino formira tim sastavljen od strunih osoba od strane izvoditelja i korisnika koji prepoznaju promjene i ispravno ih provode. Kako bi to bilo mogue, potrebno je jasno definirati procese i uloge pojedinih osoba u procesu promjena. Takoer je potrebno dobro definirati komunikacijske kanale prema projektnom timu isporuitelja i prema investitoru. Postoji posebno podruje unutar odravanja informacijskih sustava koje se bavi problemom uvoenja i upravljanja promjenama (engl. change management), a unutar ovog doktorskog rada je posebno istraen samo jedan dio koji se bavi utjecajem promjena na pouzdanost instaliranog ERP sustava. Vie o upravljanju promjenama u informacijskim sustavima je mogue pronai u [29]. U sklopu provedenog istraivanja je napravljena studija [12] u kojoj je izvreno modeliranje utjecaja promjena na pouzdanost ERP podsustava instaliranog kod jednog hrvatskog davatelja telekomunikacijskih usluga. Posebno je istraena i mogunost predvianja pojave defekata koji su posljedica redovnih mjesenih nadogradnji sustava. Telekomunikacijske usluge danas predstavljaju podruje poslovanja koje je vrlo dinamino i vjerojatno je ee izloeno razliitim poslovnim promjenama u odnosu na druga poslovna okruenja u kojima su instalirani isti ili slini ERP sustavi. Tako je i u studiji [12] vidljiva vrlo esta pojava nadogradnji kao i njihov utjecaj na pouzdanost promatranog ERP podsustava. Promatrani ERP podsustav je sastavljen od tri programska modula, a na zahtjev poslovne organizacije u kojoj je istraivanje provedeno navedena su samo openita imena Modul1, Modul2 i Modul3. Namjena podsustava je praenje svih aktivnosti na odravanju i naplati postojeih usluga kod krajnjih korisnika. Najei su razlozi promjena u promatranom ERP podsustavu stalna uvoenja novih tehnologija i povezanih usluga, ali i este promjena naina naplate koje su posljedica uvoenja novih naina obrauna, tarifa i sl. 88

Poslovna organizacija u kojoj je istraeni ERP podsustav uveden dosljedno se pridrava uvedenih i prihvaenih standarda upravljanja promjenama. Dostavljeni podaci su prikupljeni od strane interne slube korisnike podrke u razdoblju od godine dana i predstavljali su zabiljeene defekte kojima su uzrok bile provedene nadogradnje sustava. Sustav se redovno nadograuje svaki mjesec, a nadogradnja se primjenjuje nakon provjere na probnom sustavu. Utjecaj nadogradnji je analiziran kroz modeliranje funkcije gustoe vjerojatnosti pojave defekata za svaki mjesec nakon izdavanja nove verzije s ukljuenim nadogradnjama. U istraivanju je poetno pretpostavljeno slijedee: svaka nadogradnja uzrokuje nove defekte pojavu defekata koji su posljedica primijenjenih nadogradnji je mogue modelirati uporabom prikladnih statistikih razdioba Polazne pretpostavke su statistiki potvrene u kasnijoj analizi ustupljenih podataka uporabom opisanih statistikih testova iz 3. poglavlja (Kolmogorov-Smirnov, AndersonDarling), tj. uporabom razliitih alata i postupaka opisanih u 4. poglavlju ovog doktorskog rada je utvrena Weibull razdioba kao najprikladnija u modeliranju razdiobe defekata. Nakon potvrde poetnih pretpostavki je razmotrena mogunost predvianja buduih Weibull razdioba koje bi mogle opisati pojavu defekata u budunosti. Koriteni su i naknadno provjereni postupci predvianja kao to su linearna regresija i KNN algoritam.

6.1.

Uzroci nadogradnje ERP sustava

Najei uzroci nadogradnje i izmjena postojeeg ERP sustava su: korisniki zahtjevi, tehnologija i razvojni procesi [29]. Korisniki zahtjevi najee nastaju zbog slijedeih razloga: proputeni, pogreni ili nepotrebni zahtjevi izmjene arhitekture, dizajna i implementacije rastue potrebe poslovanja neoekivane potrebe korisnika trini zahtjevi izmjene kljunih osoba kod naruitelja i njihovih potreba sustizanje konkurencije izmjena prioriteta u poslovanju

Izmjene uzrokovane tehnologijom i razvojnim procesima obuhvaaju kao uzroke izmjena: 89

strojna oprema, operativni sustavi, internet preglednici suelja prema drugim sustavima izmjene u dijelovima sustava isporuenim od drugih proizvoaa programske podrke izmjene tehnologija i razvojnih procesa u izradi programske podrke uvoenje novih tehnologija povlaenje starih tehnologija nadogradnje postojeih tehnolokih rjeenja

Uzroci nadogradnje ERP sustava se mogu dobro opisati i Lehmanovim zakonima evolucije programske podrke[18]. Lehman openito polazi od definicije takozvanog Esustava (engl. E-type system) koji predstavlja bilo kakav programski proizvod s primjenom u stvarnosti. Takvi sustavi su izloeni stalnim promjenama jer inae postaju neupotrebljivi. Ovakva formulacija je poznata kao prvi Lehmanov zakon i u potpunosti je primjenjiva na ERP sustave. Nakon svake promjene ERP sustava njegova sloenost sigurno raste ukoliko se nita aktivno ne poduzima kako bi se to sprijeilo (slijedi iz drugog Lehmanovog zakona o rastu sloenosti programskog proizvoda nakon provedenih promjena). Proizvoa moe uloiti napor u izradi ERP modula smanjenjem defekata u novom programskom kodu koji nastaje kao posljedica prilagodbe, meutim to nije dovoljno. Vrlo est primjer se navodi u [26] prema kojem veina ERP sustava sadri velik broj pripremljenih poslovnih izvjea po razliitim modulima na koje su se korisnici s vremenom samostalno navikli i koriste ih u svakodnevnom radu Meutim, nisu svi korisnici jednako snalaljivi i obueni za rad pa uprava tvrtke najee zakljuuje da sustav ne raspolae s dovoljno dobrim izvjetajima. Kao odgovor na ovakvo stanje tvrtke esto pokreu nekontrolirane nadogradnje sustava s razliitim izvjetajima i sustavima poslovne inteligencije, a u konanici se dobiva vrlo nestrukturiran ERP sustav, tj. nitko tono ne zna to bi, kada i odakle trebao gledati, nego je sve preputeno snalaljivosti pojedinca. Zato se preporuaju aktivnosti koje proizlaze iz prije navedenog drugog Lehmanovog zakona i koje se sastoje od nekoliko osnovnih pravila: uvode se samo bitne prilagodbe u ERP sustav jer e previe informacija koje e nastati kao posljedica previe prilagodbi bitno smanjiti njihovu ukupnu vrijednost i oneistit e sustav uvedene prilagodbe moraju biti vidljive svim korisnicima, tj. posljedice uvoenja ne bi trebale biti ograniene samo na jedan odjel ili radno mjesto

90

(npr. odjel prodaje moda treba pristup nekim informacijama koje stvara prilagodba prvobitno nainjena za odjel financija ili logistike) potrebno je uvesti strogo upravljanje promjenama i ERP sustav treba mijenjati vrlo kontrolirano, to jest svaka promjena mora imati jasan motiv i korist Prvo pravilo se dijelom moe promatrati i kao posljedica treeg Lehmanova zakona koji govori o ogranienoj brzini unaprjeivanja sustava, tj. promatrani ERP sustav se jednoliko unaprijeuje i jednoliko kvari uslijed izvedenih prilagodbi. Ako se u jednom izdanju ERP sustava unese previe prilagodbi tada e unijeti i puno novih defekata, a sustav zbog toga moe postati nestabilan u odravanju.

6.2.

Uporaba prikladnih matematikih modela

U prethodnim poglavljima ovog doktorskog rada su opisani formalni matematiki modeli uz pomo kojih je mogue iz empirijskih razdioba pojave defekata utvrditi prikladne teorijske razdiobe i procijeniti budue pojave defekata u sustavu. Ako se takvi postupci koriste za modeliranje utjecaja nadogradnje na pouzdanost promatranog ERP sustava tada je naravno potrebno izdvojiti samo one defekte koji su se u pojavili kao posljedica njenog izvoenja. Za uspjenu primjenu postojeih matematikih modela u modeliranju utjecaja nadogradnji na pouzdanost ERP sustava potrebno je uvaiti slijedee pretpostavke: promatrani ERP sustav se redovno nadograuje u pravilnim vremenskim razmacima (npr. u studiji [12] se nadogradnje provode jednom mjeseno) nadogradnja ERP sustava je nova verzija sustava s uvedenim novim funkcionalnostima, a isporuka nove verzije sustava u smislu samo ispravaka uoenih greaka se ne smatra nadogradnjom nadogradnja bilo kojeg dijela promatranog ERP sustava u stvarnosti znai novi sustav pa je potrebno provoditi postupke modeliranja pouzdanosti za sve dijelove sustava koji su nadogradnji promijenjeni (npr. u [12] je to znailo mjeseno modeliranje pouzdanosti za itav ERP podsustav) ukupna pouzdanost dijela ili itavog ERP sustava ovisi o pouzdanosti s vih modula od kojih je nainjen i moe se raunati se kao skupni doprinos pouzdanosti svih modula

91

itav postupak modeliranja utjecaja nadogradnje na pouzdanost promatranog ERP sustava je prema [12] mogue saeti u slijedei algoritam:

Za svaki ERP modul prije nove nadogradnje { Mjeri empirijsku razdiobu gustoe vjerojatnosti pojave defekata za period nakon zadnje izvedene nadogradnje Utvrdi parametre najbolje pristajue teorijske razdiobe koritenjem prikladnih algoritama (maksimalna vjerodostojnost,najmanji kvadrati,statistiki momenti) Provjeri poklapanje utvrene teorijske razdiobe s empirijskom za zadani faktor znaajnosti, koritenjem statistikih testova (Kolmogorov-Smirnov, AndersonDarling) Predvidi budue vrijednosti parametara teorijske razdiobe iz prethodno utvrenih } Navedeni algoritam ne vrijedi ako je nemogue utvrditi prikladnu teoretsku razdiobu koja se poklapa s empirijskom uz zadani faktor znaajnosti za sve prethodno provedene nadogradnje na svim modulima koji ine promatrani ERP sustav. Ako je navedeni algoritam primjenjiv na sve module koji ine promatrani ERP sustav, tada je mogue procijeniti utjecaj nadogradnji na itav ERP sustav raunanjem skupnog doprinosa svih modula jednostavnim zbrajanjem razdioba. Takoer, ako je mogue utvrditi teoretsku razdiobu koja dobro opisuje empirijske za sve provedene nadogradnje, tada je mogue procijeniti budua stanja pouzdanosti ERP sustava. Pripremu empirijskih podataka preko utvrivanja gustoe vjerojatnosti pojave defekata je mogue provesti tako da se prikupljeni uzorci oznae u vremenskoj osi ili prema veliini. U ovom doktorskom radu su obraena oba modeliranja jer svako od njih moe donijeti odreene rezultate koji mogu biti zanimljivi u ukupnoj procjeni pouzdanosti.

92

Na slici 6.1 je prikazan takav proces u kojem se istovremeno provode oba modeliranja za prethodno navedeni algoritam.

* Grupiraj defekte u uzorke

Sloi uzorke u vremenskoj domeni

Sloi uzorke po veliiini

Utvrdi teoretsku razdiobu

Utvrdi teoretsku razdiobu

Provjeri teoretsku razdiobu

Provjeri teoretsku razdiobu

Predvidi slijedee razdiobe * -Slijedei modul ? * * * *

Skuoni doprinos modula na pouzdanost itavog ERP sustava

Slika 6.1 Algoritam modeliranja utjecaja nadogradnji

Ako je modeliranje mogue provesti u vremenskoj domeni, tada je prikladno izvriti procjenu najgoreg sluaja kroz vremenski interval u kojem e se pojaviti najvie defekata u sustavu. Ako se modeliranje vri iz empirijske razdiobe u kojoj su uzorci poredani po veliini (broju defekata), tada je mogue procijeniti koliko e defekata biti zabilje eno u najgorem sluaju. Takoer je kod modeliranja u vremenskoj domeni mogue ustanoviti i odreene pokazatelje koji proizlaze iz prethodno opisanih matematikih svojstava Weibull krivulje, tj. ako kod takvog modeliranja parametar parametar raste, tada sustav postaje nepouzdaniji ili ako raste uz nepromijenjeni parametar , tada se isti broj defekata dogaa u manjem

vremenskom periodu. Ovakvo razmatranje se moe ilustrirati na slici 6.2 iz [12] na kojoj su prikazane empirijske i teorijske razdiobe defekata po mjesecima za jedan ERP modul. Za cijeli promatrani period se parametar malo mijenjao jer se vremenska razdioba defekata izmeu nadogradnji malo mijenjala. Takoer je na slici 6.2 vidljivo kako su u nekim

93

periodima Weibull krivulje znatno ue jer je tada vrijednost parametra

zabiljeila nagli pad

pa se vei broj defekata se dogodio u malom vremenskom intervalu kao npr. u 6. mjesecu. Vano je napomenuti kako se potvrene teorijske razdiobe koje vrijede nakon provedenih nadogradnji meusobno ne zbrajaju. Za pojanjenje ovakve tvrdnje moe se opet koristiti slika 6.2 gdje je vidljivo kako se u trenutku izvrenja nadogradnje za oujak prekida teorijska razdioba za veljau i poinje vrijediti teorijska razdioba za oujak bez zbrajanja s prethodnom razdiobom. Ovakav pristup proizlazi iz prethodno navedene pretpostavke kako izvrena nadogradnja znai koritenje novog sustava i pojavu defekata koji su posljedica koritenja nove verzije sustava koja nije prije postojala.

0,3 0,25 0,2 0,15 0,1 0,05 0 January January May Estimated Weibull PDF Measured PDF

June

March

March

February

April

June

July

October

November

September

November

August

August

Slika 6.2 Vremenska razdioba defekata na ERP podsustavu iz [12] modelirana koritenjem Weibull razdiobe

6.3. Modeliranje vremenske razdiobe pojave defekata nakon provedene nadogradnje ERP sustava
Za opis modeliranja vremenske razdiobe defekata su koriteni podaci iz studije [12]. Iz dostupnih podataka su izdvojene pojave defekata koji su se u sustavu pojavili nakon provedenih nadogradnji i grupirani su po radnim danima kao u tablici 4.2. Iz tako poredanih podataka su poetno izraunate empirijske razdiobe gustoe vjerojatnosti pojave defekata i ukupne vjerojatnosti pojave defekata za sve module koji ine promatrani ERP podsustav. Kao primjer je posebno navedeno grupiranje defekata po radnim danima nakon izvrene nadogradnje u 7. mjesecu i prikazano je u tablici 6.1. 94

December

Tablica 6.1. Raunanje empirijskih razdioba za promatrani ERP podsustav u 7. mjesecu promatranja Broj pojava defekata po modulima Rad ni dan 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Ukupno Modul 1 15 2 3 20 17 14 10 8 9 4 18 22 17 8 17 8 12 26 14 7 5 0 256 Modul 2 5 0 0 6 0 5 3 15 1 9 5 3 2 1 8 0 3 6 3 5 1 1 82 Modul 3 9 4 9 9 6 7 1 4 5 9 6 10 13 3 5 4 5 15 3 5 6 4 142

Empirijski Modul 1 0,058 0,007 0,011 0,078 0,066 0,054 0,039 0,031 0,035 0,015 0,070 0,085 0,066 0,031 0,066 0,031 0,046 0,101 0,054 0,027 0,019 0,000 1 Modul 2 0,061 0,000 0,000 0,073 0,000 0,061 0,037 0,183 0,012 0,110 0,061 0,037 0,024 0,012 0,098 0,000 0,037 0,073 0,037 0,061 0,012 0,012 1 Modul 3 0,063 0,028 0,063 0,063 0,042 0,049 0,007 0,028 0,035 0,063 0,042 0,070 0,092 0,021 0,035 0,028 0,035 0,106 0,021 0,035 0,042 0,028 1

Empirijski Modul 1 0,059 0,066 0,078 0,156 0,223 0,277 0,316 0,348 0,383 0,398 0,469 0,555 0,621 0,652 0,719 0,750 0,797 0,898 0,953 0,980 1,000 1,000 Modul 2 0,061 0,061 0,061 0,134 0,134 0,195 0,232 0,415 0,427 0,537 0,598 0,634 0,659 0,671 0,768 0,768 0,805 0,878 0,915 0,976 0,988 1,000 Modul 3 0,063 0,092 0,155 0,218 0,261 0,310 0,317 0,345 0,380 0,444 0,486 0,556 0,648 0,669 0,704 0,732 0,768 0,873 0,894 0,930 0,972 1,000

Potrebno je napomenuti kako su defekti biljeeni samo u radnim danima kada se sustav stvarno koristio pa su defekti zato grupirani u 22 uzorka koji predstavljaju radne dane. Nainjeno je ukupno dvanaest takvih tablica za sve module i sve mjesece u godini promatranja. Empirijska funkcija se za jedan radni dan raunala kao omjer broja

95

prijavljenih defekata u tom danu i ukupnog broja defekata za itav period. Npr. vrijednost funkcije za Modul1 se u desetom danu promatranja se raunala iz tablice 6.1 kao: 4 / 256 = 0,078125 Openito se moe pisati za npr. Modul1: = broj uoenih defekata u danu / gdje je promatranja. Empirijska funkcija odnosno vrijednost funkcije se raunala kao zbroj vjerojatnosti za promatrani period, se u desetom danu promatranja raunala iz tablice 6.1 kao: (6-3) (6-2) (6-1)

ukupan broj prijavljenih defekata za Modul1 u sedmom mjesecu

0,0633803 Ukupna vjerojatnost vrijednosti za i

je za itav period promatranja uvijek jednaka 1. Izraunate iz tablice 6.1. se mogu prikazat grafiki za sve module u , a na slici 6.4. su za sve module.

promatranom periodu. Na slici 6.3 su prikazane empirijske funkcije vidljive empirijske funkcije
0,2 0,18 0,16 0,14 0,12 0,1 0,08 0,06 0,04 0,02 0 1 3 5 7 9 11 13 15 17 19 21

Modul1 Modul2 Modul3

Slika 6.3 Grafiki prikaz empirijskih funkcija

za sve module

96

1 0,8 0,6 0,4 0,2 0 1 3 5 7 9 11 13 15 17 19 21

Modul1 Modul2 Modul3

Slika 6.4 Grafiki prikaz empirijskih funkcija

za sve module

Sukladno utvrenom algoritmu iz potpoglavlja 6.2 je u sljedeem koraku odreena prikladna teorijska razdioba koja najbolje opisuje empirijske sa slika 6.3 i 6.4. Koritenjem programskog paketa EasyFit [36] za sve empirijske razdiobe i po svim modulima je primjenom metode maksimalne vjerodostojnosti odabrana Weibull razdioba kao teorijska razdioba koja najbolje odgovara empirijskim podacima iz tablice 6.1. Izraunate vrijednosti Weibull parametara su vidljive u tablici 6.2. Tako utvrene vrijednosti su provjerene koritenjem statistikih testova za faktor znaajnosti =0,05, a rezultati provjere su prikazani u tablici 6.2. Na temelju rezultata provjere iz tablice 6.2 je dokazano kako utvrene Weibull razdiobe odgovaraju empirijskima iz tablice 6.1 Tablica 6.2 Rezultati Kolmogorov-Smirnov i Anderson-Darling testa za odreene parametre teorijske Weibull razdiobe, za sve module, prema empirijskim razdiobama iz tablice 6.1 Naziv -ML modula Granina Gradnina Broj Faktor KS vrijednost vrijednost uzoraka znaajnosti test KS AD 22 22 22 0,05 0,05 0,05 0,28087 0,28087 0,28087 2,5018 2,5018 2,5018 OK OK OK AD test OK OK OK

-ML

Modul1 2,0442 12,666 Modul2 1,7035 9,5102 Modul3 1,7523 12,474

Prethodno opisani postupak odreivanja teorijske iz empirijske razdioba za period izmeu nadogradnji je u [12] primjenjen za sve module i sve mjesece izmeu nadogradnji, a vrijednosti utvrenih parametara teorijske Weibull razdiobe su po mjesecima prikazane u tablici 6.3. Koritenjem statistikih testova je potvreno da Weibull razdioba slijedi empirijsku za bilo koji period izmeu nadogradnji. 97

Tablica 6.3 Parametri teorijske Weibull razdiobe za sve module po mjesecima Modul1 Mjesec 1 2 3 4 5 6 7 8 9 10 11 12 1,6595 2,1759 1,4631 2,201 2,0541 2,0276 2,0442 1,7303 2,1154 2,4365 2,0338 2,0586 10,943 12,31 12,838 12,393 14,194 10,567 12,666 12,627 13,013 12,623 13,468 13,3 2,0332 2,2002 1,8156 1,7235 1,7159 1,4497 1,7035 1,8506 2,075 1,5375 2,3344 1,5526 Modul2 10,782 11,271 11,668 10,207 11,846 8,1064 9,5102 9,6252 9,6442 9,6027 12,969 6,9069 1,7206 2,0826 1,6122 1,8453 1,6778 2,249 1,7523 1,8393 2,0487 2,0607 1,3788 2,0595 Modul3 10,754 11,087 12,235 9,9421 8,8015 12,237 12,474 12,309 13,946 12,037 11,101 12,295

Uvrtavanjem utvrenih parametara teorijske Weibull razdiobe prema tablici 6.3, je mogue koritenjem formula (3-28) i (3-29) raunati funkcije i za sve promatrane iz tablice 6.4. su module. U tablici 6.4 su kao primjer izraunate teorijske razdiobe za sve module prema odreenim parametrima za 7. mjesec iz tablice 6.2. Izraunate razdiobe razdiobe po svim modulima. zatim prikazane grafiki na slici 6.4 za sve module, a na slici 6.5 je to isto uinjeno i za

U procjeni pouzdanosti itavog ERP sustava je koriteno pravilo iz teorije vjerojatnosti primjenjene na tehnike sustave koji su sastavljeni od vie razliitih dijelova s razliitim pouzdanosti [55]. Primjenom takvog pristupa, ukupna pouzdanost itavog ERP sustava se moe prikazati kao zbroj pojedninih funkcija prema formuli:
(6-4)

za sve module koji ine ERP sustav

U prikazanoj studiji, ERP podsustav se sastoji od tri modula pa se ukupna pouzdanost raunala kao skupni doprinos svih modula prema formuli:
(6-5)

Uvrtavanjem vrijednosti empirijskih razdioba iz tablice 6.1 u formulu (6-5) je poetno izraunata empirijska razdioba za itav ERP podsustav i prikazana u tablici 6.5. Zatim su 98

odreeni parametri najbolje odgovarajue Weibull razdiobe (=1,9291, =12,537) za tako izraunatu empirijsku razdiobu i provjereni prije opisanim statistikim testovima. Vrijednosti teorijske razdiobe koja opisuje pouzdanost itavog ERP podsustava za 7. mjesec promatranja su takoer prikazane u tablici 6.5. Grafike usporedbe empirijskih i teorijskih razdioba za itav ERP podsustav u 7. mjesecu promatranja su vidljive na slikama 6.7 i 6.8. Tablica 6.4. Raunanje teorijskih razdioba za promatrani ERP podsustav u 7. mjesecu promatranja, za sve module Teoretski Radni dan 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Teoretski

Modul1 Modul2 Modul3 Modul1 Modul2 Modul3 0,0113 0,0230 0,0340 0,0441 0,0527 0,0595 0,0645 0,0676 0,0687 0,0680 0,0658 0,0623 0,0578 0,0525 0,0469 0,0411 0,0354 0,0300 0,0249 0,0204 0,0165 0,0131 0,0359 0,0558 0,0692 0,0775 0,0816 0,0821 0,0798 0,0753 0,0693 0,0624 0,0551 0,0477 0,0406 0,0340 0,0281 0,0228 0,0183 0,0145 0,0113 0,0087 0,0066 0,0050 0,0208 0,0340 0,0443 0,0521 0,0577 0,0614 0,0632 0,0635 0,0625 0,0603 0,0573 0,0536 0,0495 0,0450 0,0405 0,0361 0,0317 0,0276 0,0238 0,0204 0,0172 0,0144 0,0056 0,0227 0,0513 0,0904 0,1389 0,1952 0,2574 0,3236 0,3918 0,4604 0,5274 0,5916 0,6517 0,7069 0,7566 0,8006 0,8388 0,8714 0,8988 0,9215 0,9399 0,9546 0,0213 0,0678 0,1307 0,2044 0,2843 0,3664 0,4475 0,5252 0,5976 0,6636 0,7223 0,7737 0,8179 0,8552 0,8862 0,9116 0,9321 0,9484 0,9613 0,9712 0,9788 0,9846 0,0119 0,0396 0,0790 0,1274 0,1825 0,2422 0,3047 0,3682 0,4313 0,4928 0,5517 0,6072 0,6587 0,7060 0,7488 0,7871 0,8210 0,8506 0,8764 0,8984 0,9172 0,9330

99

0,09 0,08 0,07 0,06 0,05 0,04 0,03 0,02 0,01 0,00 1 3 5 7 9 11 13 15 17 19 21 Modul1 Modul2 Modul3

Slika 6.5 Grafiki prikaz teorijskih funkcija

1 0,8 0,6 0,4 0,2 0 1 3 5 7 9 11 13 15 17 19

za sve module

Modul1 Modul2 Modul3

21

Slika 6.6 Grafiki prikaz teorijskih funkcija

za sve module, prema tablici 6.4

100

Tablica 6.5 Raunanje skupnog doprinosa svih modula na pouzdanost ERP podsustava u 7. mjesecu promatranja Empirijski skupni doprinos 0,0610 0,0120 0,0250 0,0716 0,0362 0,0550 0,0276 0,0808 0,0275 0,0629 0,0578 0,0643 0,0608 0,0215 0,0664 0,0198 0,0396 0,0935 0,0375 0,0412 0,0247 0,0135 Teoretski Empirijski Teoretski skupni doprinos skupni doprinos skupni doprinos 0,0146 0,0272 0,0382 0,0477 0,0553 0,0610 0,0647 0,0666 0,0667 0,0653 0,0627 0,0589 0,0545 0,0495 0,0442 0,0389 0,0338 0,0289 0,0243 0,0202 0,0166 0,0135 0,0610 0,0730 0,0980 0,1696 0,2058 0,2608 0,2883 0,3691 0,3966 0,4596 0,5174 0,5817 0,6425 0,6640 0,7304 0,7502 0,7898 0,8832 0,9207 0,9619 0,9865 1,0000 0,0076 0,0286 0,0614 0,1045 0,1561 0,2144 0,2774 0,3432 0,4100 0,4761 0,5402 0,6011 0,6578 0,7098 0,7567 0,7983 0,8346 0,8659 0,8925 0,9147 0,9331 0,9481

101

Funkcija gustoe vjerojatnosti pojave defekata

0,1 0,09 0,08 0,07 0,06

p(t)

0,05 0,04 0,03 0,02 0,01 0 2 4 6 8 10 12 14 16 18 20 22

t
Empirijski Weibull

Slika 6.7 Grafiki prikaz empirijske i teorijske funkcije module

skupnog doprinosa za sve

Ukupna vjerojatnost pojave defekata

1 0,9 0,8 0,7 0,6

P(t)

0,5 0,4 0,3 0,2 0,1 0 2 4 6 8 10 12 14 16 18 20 22

t
Empirijski Weibull

Slika 6.8 Grafiki prikaz empirijske i teorijske funkcije module

skupnog doprinosa za sve

Na temelju prikazanih postupaka u odreivanju prikladnih Weibull razdioba koje nabolje modeliraju vremensku razdiobu defekata nakon provedene nadogradnje ERP sustava je u [12] provjerena mogunost predvianja buduih Weibull razdioba na temelju prethodnih vrijednosti parametara. Kao prikladni postupci su odabrani prethodno opisani postupci linearne regresije i KNN algoritma.

102

U ovom doktorskom radu se zbog kraeg prikaza navodi samo jedan primjer usporedbe efikasnosti oba algoritma na istim ulaznim podacima iz tablice 6.1 koji su naknadno usporeeni s predvianjem iz prethodno utvrenih parametara iz tablice 6.3. U prikazanom primjeru se koritenjem KNN algoritma i linearne regresije predviaju parametri sljedee Weibull razdiobe iz vrijednosti za prethodnih est mjeseci prema tablici 6.3 Prikazani su pravci linearne regresije koji su utvreni utvreni za takav sluaj koritenjem LINEST MS Excel funkcije na slikama 6.8 i 6.9 na kojima su zbog kraeg prikaza navedeni samo regresijski pravci za Modul1. Na temelju jednadbe utvrenog regresijskog pravca za Modul1 prema slici 6.8 je se izraunat predvieni parametar za 7. mjesec kao: = 0,0632*7 + 1,7089 = 2,1513 Isti postupak je primijenjen i na ostale module pa je predvianje za 7. mjesec: = -0,1275*7 + 2,2693 = 1,3768 = 0,0474*7 + 1,6985 = 2,0303 (6-7) (6-8) (6-6)

Na temelju jednadbe utvrenog regresijskog pravca za Modul1 iz slike 6.8 je izraunat predvieni parametar za 7. mjesec kao:
(6-9) = 0,0951*7 + 11,875 = 12,5407

y = 0,0632x + 1,7089 R = 0,1555

2,5 2,0 1,5 1,0 0,5 0,0 1 2 3 4 5 6

- Modul1 Linear ( - Modul1)

Slika 6.8 Utvrivanje regresijskog pravca za parametar Weibull razdiobe u 7. Mjesecu, za Modul1

103

16 14 12 10 8 6 4 2 0 1 2 3 4 5 6

y = 0,0951x + 11,875 R = 0,0182

- Modul1 Linear ( Modul1)

Slika 6.9 Utvrivanje regresijskog pravca za parametar Weibull razdiobe u 7. Mjesecu, za Modul1, prema prethodnim vrijednostima iza tablice 6.3

Isti postupak je primijenjen i na ostale module pa je predvianje za 7. mjesec: = -0,3747*7 + 11,958 = 9,3351 = -0,0496*7 + 11,016 = 10,6688 (6-10) (6-11)

Istovremeno je izvreno predvianje parametara Weibull razdiobe koritenjem KNN algoritma kao u tablici 6.6 u kojoj je prikazan primjer predvianja za parametar i Modul1 u 7. mjesecu. Tablica 6.6 Prikaz raunanja budue vrijednosti parametra Weibull razdiobe za Modul1, u 7. mjesecu promatranja, uporabom KNN algoritma t 1 2 3 4 5 6 7 1,6595 2,1759 1,4631 2,201 2,0541 2,0276 ? Distanca za t 6 5 4 3 2 1 Najblii susjed za k=3

2,201 2,0541 2,0276

Temeljem izraunatih distanci za parametar oekivana vrijednost parametra razdiobe kao: =(2,201+2,0541+2,0276)/3 = 2,0942

i odabrani parametra

=3 je izraunata

(6-12)

104

Oekivane vrijednosti parametara za sve ERP module. dobivene uporabom KNN algoritma predvianja za 7. mjesec promatranja prikazane su u tablici 6.7. U konanici je provjereno odstupanje oekivanih Weibull razdioba iz tablice 6.7 od naknadno utvrenih empirijskih razdioba. Tablica 6.7 Oekivani parametri Weibull razdiobe za sve module, u 7. mjesecu Oekivane vrijednosti za 7. mjesec Linearna regresija KNN algoritam Modul1 Modul2 Modul3 1,3768 2,0303 9,5102 12,474 2,0942 1,6297 1,9240 12,3847 10,0531 10,3269 2,1513 12,5407

Zbog kraeg prikaza je kao primjer prikazana samo provjera KS testom oekivanih parametra za Modul1 iz tablice 6.7 koji su izraunati koritenjem KNN algoritma. Oekivani parametri oito daju dobro predvianje razdiobe jer je statistika testa ( manja od oitane iz statistikih tablica ( 0,1391)

0,2809) za faktor znaajnosti =0,05. U tablici

6.9 je kao primjer prikazana provjera oekivane razdiobe AD testom za iste parametre. Ovim testom je takoer dokazano dobro predvianje za zadani faktor znaajnosti 0,05 jer je statistika testa (A=0,860974) manja od oitane iz statistikih tablica ( 2,5018) uz faktor znaajnosti 0,05. Na temelju rezultata provjere koji su prikazani u tablicama 6.8 i 6.9 se moe rei kako je predvianje Weibull razdiobe defekata u 7. mjesecu za Modul1 dobivene koritenjem KNN algoritma dokazano KS i AD testom uz faktor znaajnosti 0,05. Rezultati provjere svih parametara iz tablice 6.7 koji su dobiveni linearnom regresijom su prikazani u tablici 6.10. U tablici 6.11 je prikazana takva provjera za parametre predviene uporabom KNN algoritma. Prema prikazanim rezultatima iz tablica 6.10 i 6.11 je vidljivo kako oba koritena algoritma predvianja buduih Weibull parametara prolaze dva statistika testa uz zadani faktor znaajnosti 0,05. U naknadnoj analizi dostupnih podataka je provjereno predvianje za sve module poevi od 4. mjesec promatranja jer se koristio KNN algoritam s tri prethodna uzorka kod kojeg predvianje za manje od tri prethodne vrijednosti parametara nije mogue. Uoeno je izvrsno predvianje unutar zadanog faktora znaajnosti i prema prethodno opisanom postupku za 105

nadogradnje sustava od 6. mjeseca i dalje. Ovakav rezultat se moe objasniti odreenim svojstvima koritenih algoritama za predvianje parametara, tj. oito je potreban odreen uzorak prethodnih vrijednosti (u prikazanom primjeru je to pet prethodnih vrijednosti parametara) kako bi koriteni algoritmi dali sigurno predvianje za odreeni faktor znaajnosti. Za ilustraciju usporedbe oekivane i empirijske razdiobe je prikazana usporedba za Modul1 na slici 6.10 gdje je usporeena oekivana razdioba za 7. mjesec prema KNN algoritmu s naknadno utvrenom empirijskom. Tablica 6.8 Primjer KS testa za oekivanu razdiobu defekata na Modulu1, uz parametre predviene KNN algoritmom (=2,0942, =12,3847) Dan 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Broj defekata 15 2 3 20 17 14 10 8 9 4 18 22 17 8 17 8 12 26 14 7 5 0 P0 0,0051 0,0217 0,0500 0,0895 0,1390 0,1969 0,2612 0,3300 0,4010 0,4722 0,5417 0,6078 0,6694 0,7255 0,7754 0,8191 0,8565 0,8879 0,9137 0,9347 0,9513 0,9642 Pn 0,0586 0,0664 0,0781 0,1563 0,2227 0,2773 0,3164 0,3477 0,3828 0,3984 0,4688 0,5547 0,6211 0,6523 0,7188 0,7500 0,7969 0,8984 0,9531 0,9805 1,0000 1,0000 Dn=|Pn-P0| 0,0535 0,0447 0,0281 0,0667 0,0837 0,0805 0,0552 0,0177 0,0182 0,0737 0,0729 0,0531 0,0483 0,0731 0,0567 0,0691 0,0596 0,0106 0,0394 0,0458 0,0487 0,0358 0,0837 0,2809

106

Tablica 6.9 Primjer AD testa za oekivanu razdiobu defekata na Modulu1, uz parametre predviene KNN algoritmom (=2,0942, =12,3847) i 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 n-i+1 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 P0(xi) 0,0051 0,0217 0,0500 0,0895 0,1390 0,1969 0,2612 0,3300 0,4010 0,4722 0,5417 0,6078 0,6694 0,7255 0,7754 0,8191 0,8565 0,8879 0,9137 0,9347 0,9513 0,9642 2i-1 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 P0(xn-i+1) 0,9642 0,9513 0,9347 0,9137 0,8879 0,8565 0,8191 0,7754 0,7255 0,6694 0,6078 0,5417 0,4722 0,4010 0,3300 0,2612 0,1969 0,1390 0,0895 0,0500 0,0217 0,0051 lnP0(xi) -5,2725 -3,8293 -2,9948 -2,4133 -1,9734 -1,6253 -1,3424 -1,1088 -0,9139 -0,7504 -0,6131 -0,4979 -0,4014 -0,3209 -0,2543 -0,1995 -0,1549 -0,1189 -0,0902 -0,0676 -0,0499 -0,0364 ln(1-P0(xn-i+1)) -3,3310 -3,0218 -2,7283 -2,4504 -2,1881 -1,9413 -1,7098 -1,4937 -1,2927 -1,1069 -0,9361 -0,7801 -0,6390 -0,5125 -0,4004 -0,3027 -0,2192 -0,1496 -0,0938 -0,0513 -0,0220 -0,0051 2,5018 0,8610

107

Tablica 6.10 Primjer ocjene predvianja razdioba za 7. mjesec kod koritenja linearne regresije Algoritam predvianja: Linearna regresija Oekivane KS test vrijednosti Modul Modul1 2,1513 12,5407 0,28087 Modul2 1,3768 Modul3 2,0303 9,5102 12,474 0,28087 0,28087 Predvianje: 7. mjesec AD test

0,0935 0,2591 0,0780

2,5018 2,5018 2,5018

0,8843 1,5950 0,7154

Tablica 6.11 Primjer ocjene predvianja razdioba za 7. mjesec kod koritenja KNN algoritma Algoritam predvianja: KNN algoritam Oekivane KS test vrijednosti Modul Modul1 2,0942 12,3847 0,28087 Modul2 1,6297 10,0531 0,28087 Modul3 1,924 10,3269 0,28087 Predvianje: 7. mjesec AD test

0,0837 0,2305 0,2109

2,5018 2,5018 2,5018

0,8610 2,4971 2,1196

1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0 1 3 5 7 9 11 13 15 17 19 21 Predvianje P(t)linearna regresija Empirijski P(t)

Slika 6.10 Primjer usporedbe oekivane i empirijske krivulje parametrima iz tablice 6.10

, za Modul1, prema

108

6.4. Modeliranje oekivanog broja pojava defekata nakon provedene nadogradnje ERP sustava
Na temelju rezultata iz prethodnog potpoglavlja, Weibull razdioba je oito dobar izbor u modeliranju i predvianju vremenske razdiobe pojave defekata za promatrani ERP sustav i njegove pojedine module. Meutim, korisnicima nekog ERP sustava je zanimljivo odrediti odreene pokazatelje koliine defekata koji e se zabiljeiti na sustavu kao posljedica nadogradnji. U ovom radu su analizirana dva problema odreivanja koliine defekata prema dostupnim obradama iz [12]. Prvi je primijenjen u predvianju najveeg oekivanog broja defekata u jednom danu nakon provedene nadogradnje i vrlo je zanimljiv u procjeni utjecaja nadogradnje ERP sustava na poslovanje. U drugom je prikazan postupak previanja ukupnog broja defekata izmeu provedenih nadogradnji za najbolji i najgori sluaj. Oba problema je mogue rijeiti analizom uestalosti pojave odreenog broja defekata u sustavu nakon provedenih nadogradnji. Za oba sluaja je modeliranje bitno drugaije od modeliranja iz prethodnog potpoglavlja u kojem se analizirala razdioba defekata u vremenskoj domeni jer su uzorci rasporeeni po veliini. Ukupna vjerojatnosti pojave odreenog broja defekata se tada za Weibull razdiobu rauna prema formuli: (6-14) gdje je parametar predstavlja gornju granicu defekata u intervalu pojave defekata u granicama

Iz formule (6-14) se rauna ukupna vjerojatnost

Sukladno algoritmu sa slike 6.1 potrebno je za takvo modeliranje formirati histogram empirijske razdiobe bez vremenske osi i grupirati uzorke prema tablici 6.12. Zbog kraeg prikaza je grupiranje provedeno za podatke iz tablice 6.1. U ovoj toki je kljuno odrediti grupe uzoraka (engl. bin). U literaturi je mogue pronai razliite preporuke kako to uiniti, a prema izvoru [55] je najjednostavnije primijeniti empirijsku formulu: (6-13) gdje je broj grupa uzoraka, a broj zabiljeenih uzoraka. = 22, a prema (6-13) je dobiveno da je

Za navedeni primjer iz tablice 6.12 vrijedi da je

. U [12] su formirane mjesene razdiobe defekata izmeu provedenih nadogradnji i za sve je broj uzoraka varirao u intervalu [20,22]. Nakon uvrtavanja u (6-13) je vidljivo kako uvijek vrijedi podjela na est grupa uzoraka za sve promatrane nadogradnje koja je prikazana u tablici 6.12. U konanici se broji koliko uzoraka sa zabiljeenim brojem defekata pripad a 109

odgovarajuem intervalu iz tablice 6.12. U prikazanom primjeru su pregledani uzorci iz tablice 6.1 i prebrojani po intervalima u tablici 6.12, npr. u tablici 6.1 su zabiljeena etiri uzorka u kojima je bilo manje od pet defekata itd. Tablica 6.12 Grupiranje prema broju defekata prema zapisu iz tablice 6.1 broj defekata broj uzoraka [0,5> 4 [5-10> 6 [10,15> [15,20> [20,25> [25, 4 5 2 1 >

U slijedem koraku je odreena prikladna statistika razdioba koja najbolje opisuje prikazanu empirijsku razdiobu iz tablice 6.12. Uporabom EasyFit programskog paketa je odreena Weibull razdioba s parametrima =1,9797, =13,752 kao najbolja od razmatranih (Weibull razdioba, gama razdioba i eksponencijalna razdioba). Dokaz podudarnosti teorijske i empirijske razdiobe je proveden prethodno opisanim statistikim testovima (KolmogorovSmirnov, Anderson-Darling). Podudarnost teorijske i empirijske razdiobe je mogue za navedeni primjer jednostavno provjeriti uvrtavanjem izraunatih Weibull parametara u formulu (6-14) po intervalima iz tablice 6.12. Npr. ukupna vjerojatnost da e se u sustavu dnevno zabiljeiti do 5 defekata je prema teoretskoj razdiobi za tablicu 6.12 uz uporabu formule (6-14) priblino 15%, a prema empirijskoj je 18%. Moe se ustanoviti i teorijska vjerojatnost odreenih intervala oduzimanjem ukupnih vjerojatnosti, npr. vjerojatnost pojave od 5 do 10 defekata po danu promatranja se rauna kao razlika vjerojatnosti da e se dnevno zabiljeiti manje od 10 defekata i vjerojatnosti da e se dnevno zabiljeiti manje od 5 defekata. Uvrtavanjem u (6-14) i naknadnim oduzimanjem se rauna da je teorijska vjerojatnost takvog dogaaja priblino 29%, a empirijska je prema tablici 6.12 priblino 27%. Usporedba empirijske razdiobe iz tablice 6.12 i pripadajue teorijske Weibull razdiobe je prikazana na slici 6.11.

110

Ukupna vjerojatnost pojave defekata

1

0,9

0,8

0,7

0,6

P(n)

0,5

0,4

0,3

0,2

0,1

0 0 2 4 6 8 10 12 14 16 18 20 22 24 26

broj defekata
Empirijski Weibull

Slika 6.11 Primjer usporedbe teorijske i empirijske razdiobe ukupne vjerojatnosti pojave odreenog broja defekata, prema razdiobi iz tablice 6.12

Prethodno opisanim postupkom su utvreni parametri Weibull razdioba koje najbolje odgovaraju empirijskim za sve module i sve nadogradnje iz [12] uz provjeru koritenjem statistikih testova. U tablici 6.13 su prikazane vrijednosti tako utvrenih parametara Weibull razdioba za itav ERP podsustav iz [12] i sve provedene nadogradnje u promatranom periodu.

Tablica 6.13 Parametri Weibull razdiobe broja defekata za sve module, utvreni iz empirijskih razdioba za sve provedene nadogradnje
Weibull Modul1 n 1 2 3 4 5 6 7 8 9 10 11 12 1,5306 1,1038 1,6279 2,2743 1,5034 1,8509 1,6279 1,4715 1,4106 2,2406 1,9030 2,4272 18,4100 15,1490 11,6760 14,8710 13,4030 15,1830 13,3640 12,2610 13,7230 12,1820 17,2430 14,9950 KS Modul1 Do 0,2941 0,2941 0,2749 0,2872 0,2586 0,3014 0,2872 0,2872 0,2803 0,2941 0,2872 0,2749 Dn 0,1342 0,1522 0,1760 0,1264 0,1432 0,1116 0,1361 0,1841 0,1999 0,1697 0,1384 0,1211 Weibull Modul2 1,5952 1,2053 1,4268 1,4109 1,2632 1,4411 1,3627 1,4022 1,2387 1,2584 1,2536 1,1948 5,0311 5,3387 4,6470 3,9772 6,0536 4,0926 4,7899 4,8347 6,4312 3,8029 8,7717 3,3562 KS Modul2 Do 0,2941 0,2941 0,2749 0,2872 0,2586 0,3014 0,2872 0,2872 0,2803 0,2941 0,2872 0,2749 Dn 0,1669 0,1626 0,1290 0,1329 0,1942 0,1821 0,1538 0,1655 0,1630 0,1699 0,1636 0,2097 Weibull Modul3 2,0106 1,4065 1,3656 1,6063 1,5091 1,2901 1,3779 1,3321 1,6296 2,3159 1,8076 1,1277 7,6040 4,6175 5,9486 4,1155 3,4971 4,1215 4,0220 4,5648 9,1218 14,0520 11,5610 7,2313 KS Modul3 Do 0,2941 0,2941 0,2749 0,2872 0,2586 0,3014 0,2872 0,2872 0,2803 0,2941 0,2872 0,2749 Dn 0,1486 0,1328 0,1365 0,1463 0,1727 0,1486 0,1542 0,1814 0,1444 0,1290 0,1381 0,1148

111

Odreeni parametri teorijske Weibull razdiobe su naknadno provjereni s KS testom u odnosu na empirisjku razdiobu, a rezultati provjere su takoer prikazani u tablici 6.13. Stupac predstavlja maksimalno dozvoljeno odstupanje Weibull razdiobe prema KS tablicama za faktor znaajnosti =0,05, a je izraunato maksimalno odstupanje Weibull razdiobe u odnosu na empirijsku razdiobu iz koje je odreena. Dakle, prema tablici 6.13 je dokazano kako utvrene Weibull razdiobe odgovaraju svim empirijskim razdiobama broja defekata iz [12], za sve promatrane module, uz faktor znaajnosti =0,05. Daljnjom analizom rezultata iz tablice 6.13 je provjereno predvianje Weibull parametara uz koritenje prethodno opisanih algoritama poevi od 4. mjeseca promatranja jer se koristio KNN algoritam s tri prethodna uzorka kod kojeg predvianje za manje od tri prethodne vrijednosti parametara nije mogue. Svako predvianje je provjereno KS testom u odnosu na empirijsku razdiobu i uz zadani faktor znaajnosti =0,05. Zbog kraeg prikaza su kao primjer navedena samo predvianja Weibull parametara za Modul1 iz [12] unutar perioda od etvrte nadogradnje do kraja promatranja i prikazani su u tablici 6.14. U takvom primjeru je vidljivo izvrsno predvianje koritenjem KNN algoritma prema kojem su dobro predvieni parametri razdioba za sve nadogradnje, a kod postupka linearne regresije je vidljivo kako predvianje za 11. mjesec ne daje teoretsku razdiobu koja se podudara s empirijskom uz faktor znaajnosti 0,05. Rezultati predvianja ne moraju uvijek biti tako dobri pa su tako analizom podataka iz [12] za Modul2 zabiljeena dva, a za Modul3 tri pogrena predvianja od ukupno devet. Ovakav rezultat nije posljedica loeg odabira modeliranja broja defekata jer je prema tablici 6.13 dokazano kako Weibull razdioba uvijek slijedi postojeu empirijsku, ve je posljedica nekih ogranienja kod koritenih algoritama predvianja Naime, uvijek je mogu dogaaj u kojem e se dogoditi znaajnija promjena razdiobe broja defekata. U sluaju veeg pogoranja pouzdanosti promatranog modula e se oblik empirijske razdiobe znatno promijeniti pa e se znaajno poveati broj uzoraka s velikim brojem defekata. Direktna je posljedica nagli skok vrijednosti Weibull parametara koji opisuju empirijski uzorak pa je i predvianje loije ili uope ne odgovara empirijskoj razdiobi. Takve situacije je lako prepoznati iz vrijednosti prikazanih u tablici 6.13 gdje je npr. faktor oblika za Modul2 promijenio gotovo dvostruko svoju vrijednost u 11. mjesecu u odnosu na prethodni 10. mjesec. Ako se pogledaju prethodne vrijednosti ovog parametra tada je vidljivo kako ne postoji niti jedna takva prethodna vrijednost, odnosno ovakvu je vrijednost teko predvidjeti iz prethodnih. Prema rezultatima prikazanima u tablici 6.13 je vidljivo kako kod Modula1 nema velikih promjena u Weibull 112

parametrima koji opisuju prethodne empirijske razdiobe pa je i predvianje uvijek dobro kao u navedenom primjeru. Naravno, openito uvijek vrijedi kako se kod dobro odravanih ERP modula ne oekuju velike promjene parametara oblika pa e i predvianje u takvim sluajevima biti dobro.

Tablica 6.14 Predvianje parametara Weibull razdiobe broja defekata iz tablice 6.13 koritenjem linearne regresije i KNN algoritma, za Modul1 Predvianje linearna regresija n 4 1,5183 8,344 KS za predvianje D0 Dn 0,2872 0,4832 Dobro Predvianje pred. KNN ? DA DA DA DA DA DA DA NE DA KS za predvianje D0 Dn DA DA DA DA DA DA DA DA DA Dobro pred. ?

1,4208 15,0783 0,2872 0,191 1,6687 13,8987 0,2586 0,1529 1,8019 13,3167 0,3014 0,1841 1,8762 14,4857 0,2872 0,1569 1,6607 13,9833 0,2872 0,2223 1,6501 13,6027 0,2803 0,2149 1,5033 13,116 0,2941 0,1855 1,7076 12,722 0,2872 0,221 1,8514 14,3827 0,2749 0,2124

5 2,3229 13,8269 0,2586 0,1537 6 1,9428 11,6138 0,3014 0,2805 7 1,9933 12,9642 0,2872 0,1645 8 1,8826 12,674 0,2872 0,1975 9 1,7369 11,9909 0,2803 0,2451 10 1,6165 12,25 0,2941 0,1705 11 1,8701 11,8269 0,2872 0,3647 12 1,9194 13,3982 0,2749 0,242

Primjena predvianja razdioba broja defekata po modulima je vidljiva iz formule (6-14) prema kojoj je teorijska vjerojatnost pojave za manje ili jednako defekata, odnosno vjerojatnost da e broj defekata u zabiljeenim uzorcima biti u rasponu [0, ]. U sluaju odreivanja maksimalnog broja defekata za neki uzorak bi se se rjeavanjem jednadbe (6-14) dobilo za eksponecijalne funkcije budui. izjednailo sa jedan, ali bi . Ovakvo rjeenje proizlazi iz svojstva

asimptotski tei ka jedan. Postavlja se pitanje koju

vrijednost odabrati u praktinoj primjeni, a da je to blie jedan, odnosno da li odabrati 0,95, 0,99 ili neku niu vrijednost? Ovdje nema nekog unaprijed odreenog pravila, ali je promatranjem utvrenih teorijskih razdioba s parametrima iz tablice 6.13 i usporedbom s odgovarajuim empirijskim razdiobama iz [12] odabrana vrijednost za jednadba (6-14) prelazi u izraz: (6-15) = 0.99. Tada

113

Ovakav izraz je mogue rijeiti numerikim postupcima na raunalu, a kao primjer se moe provjeriti sluaj predvianja za Modul1 u 7. mjesecu promatranja prema tablici 6.14. Uvrtavanjem predvienih parametara dobivenih koritenjem linearne regresije (= 1,9933, =12,9642) je dobiveno za 27. Uvrtavanjem parametara dobivenih koritenjem KNN 23 to je neto loiji rezultat jer je 26. Za potpuniju ocjenu se moe za sve algoritma (= 1,8762, =14,4857) je dobiveno za prema tablici 6.1 maksimalan broj defekata

vrijednosti iz tablice 6.14 odrediti predvianja maksimalnog broja defekata i usporediti ih sa stvarno zabiljeenima. U tablici 6.15 je prikazana takva usporedba za Modul1. Posebno su odreeni oekivani intervali broja defekata za oba koritena algoritma predvianja i ocjena uspjenosti za svaki od njih tako da je odreeno koliko uzoraka ulazi u oekivani interval. U konkretnom sluaju je KNN algoritam dao neto bolje rezultate, ali u primjeni je mogue odabrati najgori mogui sluaj, odnosno odabrati vei predvieni interval dobiven koritenjem oba algoritma (npr. iz tablice 6.15 se za 10. mjesec odabire vei interval [0,37] koji je dobiven koritenjem KNN algoritma). Tablica 6.15 Predvianje maksimalnog broja defekata za jedan dan Oekivani interval Mjesec 4 5 6 7 8 9 10 11 12 Linearna Uspjeh [%] regresija [0,23] [0,27] [0,23] [0,27] [0,21] [0,28] [0,21] [0,27] [0,30] 95,00% 95,00% 90,00% 100,00% 90,00% 95,00% 95,00% 100,00% 100,00% KNN [0,28] [0,23] [0,32] [0,32] [0,24] [0,35] [0,37] [0,32] [0,33] Uspjeh [%] 100,00% 90,00% 95,00% 100,00% 95,00% 100,00% 100,00% 100,00% 100,00%

Opisanim postupkom koji je prikazan u tablici 6.15 su napravljena predvianja za sve module iz [12] i prikazana u tablici 6.16.

114

Tablica 6.16 Predvianje broja defekata po danu Uspjeh [%] 100,00% 95,00% 95,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% Uspjeh [%] 100,00% 100,00% 95,00% 95,00% 100,00% 100,00% 95,00% 75,00% 95,00% Uspjeh [%] 100,00% 100,00% 100,00% 95,00% 100,00% 100,00% 80,00% 95,00% 95,00%

Mjesec Modul1 4 5 6 7 8 9 10 11 12 [0,28] [0,27] [0,32] [0,32] [0,36] [0,35] [0,37] [0,32] [0,33]

Modul2 [0,11] [0,10] [0,10] [0,9] [0,15] [0,23] [0,17] [0,17] [0,22]

Modul3 [0,22] [0,14] [0,13] [0,12] [0,12] [0,14] [0,18] [0,23] [0,23]

Iz tablice 6.16 je vidljivo loije predvianje za Modul2 u 11. mjesecu i Modul3 u 10. mjesecu to je i oekivano jer se predviena razdioba za te periode ne poklapa s empirijskom. Openito se moe rei kako je previanje prema tablici 6.16 dobro, odnosno u 93% predvianja je oekivani interval broja defekata pogoen s 95% i vie tonosti. Ovdje treba voditi rauna kako su kod formiranja tablice 6.16 napravljena dva bitna pojednostavljenja koja sigurno utjeu na konane rezultate. Prva je modeliranje parametara prethodnih Weibull razdioba uz faktor znaajnosti 0,05 i druga vrlo bitna je nainjena u formuli (6-15) iz koje je pretpostavljeno kako e gornja granica broja defekata po uzorku biti odreena uz vjerojatnost od 99%. Iz intervala odreenih prema tablici 6.16 je mogue konstruirati oekivanu razdiobu uz parametre iz tablice 6.14. Poetno je prema formuli 6.13 odreen broj grupa uzoraka preko kojih se analizira empirijska razdioba. Prema prethodno analiziranim podacima je izraunato kako e broj grupa uzoraka uvijek biti 6.

itav postupak je najjednostavnije ilustrirati na primjeru jednog predvianja za Modul1 u 6. mjesecu promatranja. Prema tablici 6.16 je oekivani interval za taj mjesec [0,32]. Veliina intervala za jednu grupu uzoraka koja je oznaena sa se tada moe odrediti kao rezultat cjelobrojnog dijeljenja gornje granice oekivanja i broja grupa uzoraka, odnosno vrijedi formula (6-16). (6-16)

115

Uvrtavanjem vrijednosti iz primjera ( odreenog intervala [ nula npr. oblika je [

6,

32) u (6-16) se dobiva da je

5. Na

temelju takvog rezultata se vri grupiranje uzoraka kao u tablici 6.17. Vjerojatnost pojave > se rauna prema formuli (6-14). Ako interval nema donju granicu , tada se rauna razlika vjerojatnosti , a pojedinane

vjerojatnosti se opet raunaju prema (6-14). Ako je u navedenom primjeru potrebno izraunati vjerojatnost pojave uzoraka u kojima e raspon zabiljeenih defekata biti u intervalu [5,10>, tada se rauna razlika i dobiva vjerojatnost pojave uzoraka iz intervala s empirijskom razdiobom. =26,57%. U tablici 6.17 je prikazana usporedba predviene bilo koju oekivanu razdiobu iz [12]. Tablica 6.17 Predvianje broj defekata empirijski broj uzoraka [empirijski] predvien broj uzoraka [0,5> 4 [5-10> 6 [10,15> [15,20> [20,25> [25, 4 5 2 9,09% 2 7,26% 1 4,55% 1 6,,18% >

. Modeliranje prikazano u tablici 6.17 je mogue primijeniti na bilo koji ERP modul i za

18,18% 27,27% 18,18% 22,73% 3 6 5 5

[predvianje] 12,70% 26,57% 26,34% 20,95%

Prema oekivanoj razdiobi iz tablice 6.17 je mogue odrediti predvianje za ukupan broj defekata, ali za dva granina sluaja, odnosno najbolji i najgori mogui sluaj. Najbolji sluaj se moe opisati kao dogaaj u kojem su se pojavili uzorci s donjom granicom defekata za sve ponuene intervale. Tako je kao najbolji mogui sluaj prema intervalima iz tablice 6.17 odreen dogaaj: =3*0+6*5+5*10+5*15+2*20+1*25=220 (6-17)

Najgori mogui sluaj je prema podjeli iz tablice 6.17 beskonaan broj defekata. To naravno nije tono i moe se pokuati predvidjeti oekivani najvei broj defekata. Kada se primjeni postupak slian odreivanju minimalnog broja defekata prema (6-17) rezultati predvianja najveeg broja defekata su loiji, odnosno predvianje je bilo dobro u samo 60 % sluajeva. Zato je primijenjena neto jednostavnija procjena koja uzima gornju granicu intervala iz tablice 6.16 i mnoi je s brojem radnih dana za pripadajui period izmeu nadogradnji.

116

(6-18) Dakle, moe se rei kako se prema navedenom primjeru, u 7. mjesecu, za Modul1 oekuje ukupno vie od 220, a manje od 704 defekata. Pregledom zapisa za Modul1 prema tablici 6.1 je zabiljeeno ukupno 256 defekata, to je u predvienim granicama. Kao primjer je navedena potpuna provjeru svih predvianja za Modul1 prema tablicama 6.14 i 6.16. Rezultat provjere je prikazan u tablici 6.17.

Tablica 6.17 Predvianje ukupnog broja pojave defekata za Modul1 Mjesec 4 5 6 7 8 9 10 11 12 Izmjereno 284 251 328 256 234 272 237 327 318 Predvianje minimum 205 179 170 220 191 170 156 156 170 Predvianje maksimum 560 540 672 672 756 735 740 640 660 Uspjenost 100% 100% 100% 100% 100% 100% 100% 100% 100%

117

7. Zakljuak
Rad iznosi pregled bitnih svojstava ERP sustava i alata za analizu i predvianje njihove pouzdanosti. Nedovoljno istraeno podruje pouzdanosti ERP sustava je stavljeno u kontekst analize pouzdanosti programske podrke, ali je naglaena potreba analize svih ostalih uzroka neispravnosti u radu ERP sustava koji nisu posljedica programskih pogreaka. Glavni rezultat ovog istraivanja je primijenjen postupak izrade modela pouzdanosti ERP sustava. Izbor parametara ulaznih veliina za oblikovanje modela pouzdanosti je optimiran kroz obradu i analizu podataka o zabiljeenim defektima u sustavu koji su naknadno grupirani prema vremenu nastanka ili broju pojavljivanja. Temeljem tako odreenih empirijskih razdioba utvrene su prikladne teorijske razdiobe i provjerene statistikim testovima. itav postupak je lako primjenjiv u odreivanju pouzdanosti ERP sustava iz podataka koji se ve biljee u programskim paketima za korisniku podrku kod postojeih implementacija sustava. Ostvarena su dva modela predvianja pouzdanosti prilagoena za analizu ERP sustava. Jedan je prilagoen eksponencijalni model koji se moe koristiti u procjeni sigurnosti isporuke prilagodbe tijekom sistemske provjere. Drugi je prilagoeni Weibull model u kojem se dodatno koriste linearna regresija i KNN algoritam u predvianju parametara buduih teorijskih razdioba defekata. Dobiveni modeli predvianja pouzdanosti su vrednovani usporedbom s empirijskim razdiobama defekata uz istovremeno koritenje dva standardna statistika testa (Kolomogorov-Smirnov i Anderson-Darling) za faktore znaajnosti uobiajene kod tehnikih sustava. Predstavljena je tehnika primjene operacijskog profila kao zanimljiv i nedovoljno koriten postupak za uinkovitiju provjeru i poveanje pouzdanosti ERP sustava. Teorijski koncepti su sustavno obraeni na studijskom primjeru konkretnog ERP programskog modula te su na razumljiv nain tablino prezentirane ilustracije kako se operacijski profil razvija i primjenjuje. Koritenjem razvijenog operacijskog profila je unaprijeen scenarij provjere analiziranog ERP modula jer je sustav mogue provjeravati u uvjetima slinima stvarnom koritenju kroz poveani broj operacija na funkcionalnostima koje se ee koriste kod odreenih grupa korisnika. Detaljno je istraen utjecaj nadogradnji na pouzdanost ERP sustava na studijskom primjeru ERP sustava koji se vrlo esto funkcionalno mijenja. Pretpostavljeni teorijski koncepti su potvreni u modeliranju vremenskih razdioba defekata na promatranom ERP 118

sustavu izmeu provedenih nadogradnji. Takoer je ostvareno uspjeno predvianje vremenskih razdioba defekata kao i oekivanog broja defekata na promatranom ERP sustavu. U buduem istraivanju je mogue ostvariti prototip jedinstvenog programskog paketa koji bi zabiljeene pojave defekata na ERP sustavu klasificirao prema uzrocima, odreivao model pouzdanosti, vrio predvianja i jasno upuivao na uzroke nepouzdanosti. Potrebno je detaljnije istraiti vezu pouzdanosti ERP sustava i utjecaja na poslovanje organizacije u kojoj je implementiran. Takoer je potrebno istraiti teinske udjele pojedinih defekata u utjecaju na pouzdanost ERP sustava prema fazi ivotnog ciklusa u kojoj su nastali. U buduem radu je mogue napraviti detaljno istraivanje na tritu ERP sustava u RH u kojem bi se ispitalo koliko domaih proizvoaa vrednuje kvalitetu svog razvojnog procesa i kojim postupcima, kako to ine tvrtke koje implementiraju ERP sustave stranih proizvoaa i kako korisnici procjenjuju rizike implementiranog ERP sustava na ukupno poslovanje.

119

Literatura
[1] [2] IDC, (2011) , Croatia Enterprise Application Software Market 20112015 Forecast and 2010 Vendor Shares, IDC East Central Europe, Praha Fertalj, dr.sc. K., Mornar, dr.sc. V., Kova, dr.sc. D., Haina, dr.sc. N., Pale, mr.sc. P., itnik, mr.sc., (2002), Komparativna analiza programske potpore informacijskim sustavima u Hrvatskoj, Fakultet elektrotehnike i raunarstva, Zagreb [3] Kraemmerand, P.; et al. (2003), ERP implementation: an integrated process of radical change and continuous learning, Production Planning & Control 14 (4): 228248 [4] Fryling, Meg , (2010), Total Cost of Ownership, System Acceptance and Perceived Success of Enterprise Resource Planning Software: Simulating a Dynamic Feedback Perspective of ERP in the Higher Education Environment, ProQuest Dissertations and Theses database. pp. 403. ISBN 9781109744286 [5] [6] [7 ] [8 ] [9] [10] [11] [12] L. Wylie, (1990), A Vision of Next Generation MRP II, Scenario S-300-339, Gartner Group, April 12, 1990. Sheilds, Mureell G.(2001), E-Business and ERP: Rapid Implementation and Project Planning, John Wiley and Sons, Inc. p. 9-10. IDC, (2000), The Integrated Enterprise Resource Management Software Application Market in Croatia, 1999-2004, IDC East Central Europe, Praha Musa, J.D. et.al., (1987) Software reliability, McGraw-Hill Book Co. Michael R. Lyu, (1996), Handbook of Software Reliability Engineering, Computer Society Press, ISBN: 0-07-039400-8 J. D. Musa, A. F. Ackerman, (1989), Quantifying software validation: when to stop testing?, IEEE Software Volume: 6, Issue: 3, Pages: 19-27 Weibull, W.,(1951), A statistical distribution function of wide applicability, J. Appl. Mech.-Trans. ASME 18 (3): 293297 F. Urem, K. Fertalj, I. Livaja, (2011), The impact of upgrades on ERP system reliability, World Academy of Science, Engineering and Technology, Issue 59. Venice, Italy: WASET, 2011. 1237-1241 [13] F. Urem, K. Fertalj, . Mikuli (2011) , Optimal parameter choice in modeling of ERP system reliability, 22nd Central European Conference on Information

120

and Intelligent Systems, Varadin: Faculty of Organization and Informatics, 2011. 365-371 [14] F. Urem, . Mikuli, (2010), Using NHPP model for ERP software module reliability growth, Proceedings of MIPRO 2010 International Convention on CTI Conference [15] Hribar L., Duka D., Software component quality prediction in the legacy product development environment using Weibull and other mathematical distributions , SoftCOM 2009. , Page(s): 254 259 [16] D. Ugrin-parac, (1975), Primijenjena teorija vjerojatnosti I., II., Sveuilina naklada - Liber, Zagreb, FER
[17] J. D. Musa, (1993), Operational profiles in software reliability engineering, IEEE Computer Society Press Los Alamitos, CA, USA

[18] [19]

Lehman, Meir M. , (1980), Programs, Life Cycles, and Laws of Software Evolution, Proc. IEEE 68 (9): 10601076. Turban et al., (2008), Information Technology for Management, Transforming Organizations in the Digital Economy., Massachusetts: John Wiley & Sons Inc., pp. 300343. ISBN 978-0-471-78712-9

[20] [21] [22] [23] [24] [25] [26] [27] [28] [29]

Brady, J., Monk, E., Wagner, B. (2001), Concepts in Enterprise Resource Planning, Course Technology, Chicago. ANSI/IEEE, (1991), Standard Glossary of Software Engineering Terminology, STD-729-1991, ANSI/IEEE, Frchet, Maurice (1927), Sur la loi de probabilit de l'cart maximum, Annales de la Socit Polonaise de Mathematique, Cracovie 6: 93116 D.Markovi, (2009), Problem procjene parametara u Weibullovom modelu, disertacija, PMF Zagreb, Sveuilite u Zagrebu Lawless, J.F., (1982), Statistical Models and Methods for Lifetime Data, Wiley, New York Nelson, W., (1982), Applied Life Data Analysis, Wiley, New York Paue,., (1993), Uvod u matematiku statistiku, kolska knjiga, Zagreb, 1993. Cheng, R. C. H., Iles, T. C.,(1990), Embedded models in three-parameter distributions and their estimation, J. R. Stat. Soc. Ser. B 52 Tandari, ., (2009), 'Sve' radi - to sada?, InfoTrend 174/10 Schiesser, Rick, (2002), IT Systems Management, New Jersey, Prentice Hall 121

[30] [31] [32] [33] [34]

Panorama Consulting Group (2010), 2010 ERP Vendor Analysis Report, Centennial, Colorado Panorama Consulting Group (2010), Clash of the Titans: SAP vs. Oracle vs. Microsoft Dynamics, Centennial, Colorado Rehg, J.A. (2004), Computer-Integrated Manufacturing, 3-rd edition, Prentice Hall Career&Technology, Englewood Cliffs, NJ. The Sarbanes-Oxley Act, (2002), dostupno na: http://www.soxlaw.com Bank for International Settlements (BIS), (2005), International Convergence of Capital Measurement and Capital Standards, Bank for International Settlements Press & Communications, CH-4002 Basel, Switzerland

[35] [36] [37] [38] [39] [40]

Tech-Faq, (2010), What is ERP?, dostupno na: http://www.tech-faq.com MathWave Co, (2010), EasyFit Distribution Fitting Software, uputstva za koritenje, dostupno na: www.mathwave.com Consortium for IT Software Quality, (2010,) CISQ Annual Report of Progress2010 , Software Engeneering Institute, Carnegie Mellon University Software Engineering Institute, (1987) , Software Safety, Carnegie Mellon University John P. Hopkinson, (2007), OMG Software Assurance Workshop, Object Management Group International Organization for Standardization, (2003), ISO/IEC TR 9126-3:2003, International Organization for Standardization, Geneva, Switzerland

[41] [42] [43] [44] [45] [46]

International Organization for Standardization, (2005), ISO/IEC 25000:2005, International Organization for Standardization, Geneva, Switzerland J. Pukite, P. Pukite, (1998), Modeling for Reliability Analysis, ISBN: 0780334825, Wiley-IEEE Press Swing Consulting d.o.o., (2012), SWING G2 upute za koritenje, dostupno na http://www.swing-consulting.hr Federacija BiH, (2009), Zakon o fiskalnim sistemima, Slubene novine Federacije BiH, br. 81/09 Microsoft, (2007), Microsoft Excel 2007, Funkcija LINEST, korisnika dokumentacija, dostupno na: http://office.microsoft.com/ SAP , (2011), SAP NetWeaver 7.0 - System Log, korisnika dokumentacija, dostupno na: http://help.sap.com/ 122

[47]

Schimitzek, P., (2002), Industry-Specific ERP Systems: Integrating Information and Business Processes in the Enterprise, CRC Press

[48]

Ministarstvo financija RH , (2012), Pravilnik o porezu na dodanu vrijednost, Narodne Novine , 02-2012

[49] [50] [51] [52]

Ministartstvo financija RH, (2011), ePorezna, dostupno na: http://www.porezna-uprava.hr/ Microsoft, (2008), SQL Profiler 2008,korisnika dokumentacija, dostupno na: http://msdn.microsoft.com Microsoft, (2008) Microsoft SQL Server 2008, korisnika dokumentacija, dostupno na: http://www.microsoft.com/ F. Urem, . Mikuli, Developing operational profile for ERP software module reliability prediction, Proceedings of MIPRO 2010 International Convention on CTI Conference

[53]

D. Ingram, (2009), Design Build Run: Applied Practices and Principles for Production-Ready Software Development, Wiley Publishing, Inc.,ISBN: 978-0-470-25763-0

[54] [55]

C. Jones, (2010), Software Engineering Best Practices, McGraw-Hill, ISBN: 978-0-07-162162-5 R. O. Duda, P. E. Hart, D. G. Stork, (2001), Pattern Classification (2nd Edition), Wiley Interscience publication, ISBN: 0471056693

[56]

The Commision of the European Coummunities, (2003), Commision recommendation concerning the definition of micro, small and medium-sized enterprises, Official Journal of the European Union (2003/361/EC)

[57] [58] [59]

SAP , (2011), SAP Solution manager, korisnika dokumentacija, dostupno na: http://help.sap.com/ Robert B. Grady, (1992), Practical Software Metrics for Project Management and Process Improvement, Prentice-Hall Institute of Electrical and Electronics Engineers, (2009), IEEE Standard Classification for Software Anomalies, IEEE Std 1044-2009

123

Popis kratica
ERP SMB CRM SCM SFA APS RFP IFRS BI ABAP ODC CISQ SEI OMG NHPP QA MOM MLE LSE KS AD KNN SAP DBMS C/AL LR CDF PDF IEEE ISO Enterprise Resource Planning Small and Medium Bussiness Customer Relations Management Supply Chain Management Sales Force Automation Advanced Planning and Scheduling Request For Proposal International Financial Reporting Standards Business Intelligence Advanced Business Application Programming Ortogonal Defect Classification Consortium for IT Software Quality Software Engineering Institute Object Management Group Nonhomogeneous Poisson Process Quality Assurance Method of Moments Maximum Likelihood Estimates Least Squares Estimates Kolmogorov-Smirnov Anderson-Darling k- Nearest Neighbor Systeme, Anwendungen und Produkte in Datenverabeitung AG Database Management System Client/server Application Language Linear Regression Cumulative Distribution Function Probability Density Function Institute of Electrical and Electronics Engineers International Organization for Standardization

124

ivotopis
Frane Urem je roen 05. svibnja 1972. godine u ibeniku. Nakon zavrene matematike gimnazije u ibeniku, 1990. godine upisuje studij na Elektrotehnikom fakultetu Sveuili ta u Zagrebu. U svibnju 1996. godine diplomira na profilu diplomirani inenjer elektrotehnike, smjer automatika s izvrsnim uspjehom. Od lipnja 1996. do danas je zaposlen u tvrtki Compco Systems d.o.o. u ibeniku na poslovima razvoja programske podrke, sistem integracije i informacijske sigurnosti. Od rujna 2001. do lipnja 2006. godine radi na tadanjoj Visokoj koli za turistiki menadment u ibeniku kao vanjski suradnik u nastavi na smjeru informatikog menadmenta. Nakon osnivanja Veleuilita u ibeniku u lipnju 2006. godine nastavlja s radom u nastavi kao predava do danas. U listopadu 2006. godine upisuje poslijediplomski studij raunarstva na Fakultetu elektrotehnike i raunarstva u Zagrebu. U okviru nastavnih djelatnosti na Visokoj koli za turistiki menadment sudjelovao je u nastavi iz predmeta Osnove programiranja, Objektno orijentirano programiranje. Na Veleuilitu u ibeniku je predava iz predmeta Objektno orijentirano programiranje, Uvod u baze podataka. Autor je vie znanstvenih i strunih radova te nastavnih materijala. Struni interesi ukljuuju uvoenje ERP sustava, razvoj programske podrke na Microsoft razvojnim alatima, voenje razliitih projekata na podruju mrenih tehnologija. Tijekom postdiplomskog studija objavio je sedam radova u zbornicima s meunarodnom recenzijom. Od navedenih, pet radova je vezano uz podruje disertacije. Sudjelovao je na brojnim meunarodnim konferencijama i strunim skupovima. Posjeduje niz industrijskih certifikata (Cisco, Microsoft, Brand-Rex). lan je IEEE organizacije od 2006. godine.

125

Biography
Frane Urem was born in May 5h, 1972 in ibenikt. After finishing high school in ibenik in the year of 1990, he enrolled graduate studies at the Faculty of Electrical Engineering, University of Zagreb. He received dipl. eng. of electrical engineering degree, in the field automation in May 1996 with honours. Since May 1996 he has been employed at the Compco Systems d.o.o. ibenik in different software development, system integration and information security projects. Since September 2001 by June 2006 he participated as an associate at High School for Management in Tourism in ibenik. Since September 2006 he participated as a lecturer at College in ibenik. In September 2006 he enrolled doctoral studies of Computer Science at the Faculty of Electrical Engineering and Computing. At the High School for Management in Tourism in ibenik he participated as teaching assistant in courses The Basics of Programming, Object Oriented Programming. At the College in ibenik he participates as lecturer in courses Object Oriented Programming, Introduction to Databases and Software Engineering. His scientific and professional interests include ERP implementation, software development and project management. During his doctoral studies, he has published seven full papers in proceedings with international review. Five of these papers are related to the dissertation research. He has participated several international conferences and workshops. He owns several industrial certifications (Microsoft, Cisco, Novel, Fortinet, Intel, Brand-Rex). He is a member of IEEE organisation since 2006.

126