Mogucnosti poboljsanja ERP sistema koriscenjem uzora-Zavrsni rad-Softverski zahtevi-Informatika (1), Maturalni radovi od Softverski procesi

Preuzmite Mogucnosti poboljsanja ERP sistema koriscenjem uzora-Zavrsni rad-Softverski zahtevi-Informatika (1) i više Maturalni radovi u PDF od Softverski procesi samo na Docsity! UNIVERZITET U BEOGRADU FAKULTET ORGANIZACIONIH NAUKA Bojan Jovičić Mogućnosti poboljšanja ERP sistema korišćenjem uzora Magistarska teza Beograd, 2007 docsity.com  ~ 1 ~ 1 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Mogućnosti poboljšanja ERP sistema korišćenjem uzora Sadržaj: Predmet istraživanja ovog rada je ispitivanje odnosa između postojećih ERP sistema, životnog ciklusa softvera i uzora. U radu je prvo data definicija pojma ERP i objašnjena evolucija ERP sistema. Nakon toga su prikazani neki od postojećih ERP sistema, i postojeće analize njihovih funkcionalnosti. Zatim je prikazana komparativna analiza lakoće održavanja i korišćenja uzora u ERP sistemima. U nastavku rada prikazan je Dynamics AX ERP sistem, sa poslovnog i tehničko tehnološkog aspekta. Nakon toga je razmatran životni ciklus softvera, njegovi modeli i metoda, sa fokusom na Larmanovu metodu životnog ciklusa softvera. Zatim su prikazani uzori njihovi oblici predstavljanja, sa detaljnim prikazom uzora analize, i primerima implementacije uzora projektovanja. Na kraju su prikazane mogućnosti primene uzora u poboljšanju ERP sistema, uz analizu postojanja uzora u konkretnom ERP sistemu, identifikaciju mesta gde bi se ERP sistem mogao poboljšati uvođenjem uzora, uz merenje poboljšanja korišćenjem softverskih metrika. Na kraju su date smernice za dalja poboljšanja ERP-a. Ključne reči: ERP sistemi, Komparativna analiza ERP sistema, Dynamics AX, Životni ciklus softvera, Larmanova metoda, Uzori, Uzori analize, Uzori projektovanja, Poboljšanje ERP sistema korišćenjem uzora ~ 2 ~ 2 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Possibilities of patterns application in the ERP systems improvements Abstract: This work examines relationship between the existing ERP systems, software life cycle and patterns. Firstly, the definition of the ERP is given, and the ERP systems evolution is explained. Afterwards, some of the existing ERP systems are described with the analysis of their functionalities. After that, the comparative analysis of ease of maintainance and patterns usage in the ERP systems is shown. Afterwards, the Dynamics AX ERP system is examined from business and tehnical aspect. The work proceeds with a software life cycle, it’s models and methods, with the focus on Larman’s software life cycle method. After that, patterns, their represenation forms, classifications with detailed examination of analysis patterns, and design patterns sample implementation are shown. Finally, the possibilities of applying patterns in ERP systems improvements, with the analysis of patterns existance in specific ERP system, identification of places where ERP system can be improved by introducing patterns, with improvement measuring using software metrics. Finally, guidelines for further improvements of ERP are given. Keywords: ERP systems, Comparative analysis of ERP systems, Dynamics AX, Software life cycle, Larman’s method, Patterns, Analysis patterns, Design patterns, Patterns Application in the ERP systems improvements ~ 3 ~ 3 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Sadržaj 1 Uvod .................................................................................................................................. 7 2 ERP ................................................................................................................................... 11 2.1. ERP sistemi i njihov nastanak ................................................................................. 12 2.2 Dalji razvoj ERP sistema .......................................................................................... 17 3 Komparativna analiza ERP sistema ................................................................................ 19 3.1 Opšta analiza ............................................................................................................. 21 3.2 Analiza lakoće održavanja i korišćenja uzora ......................................................... 33 3.2.1 Direktno ispitivanje ........................................................................................... 34 3.2.2 Anonimno ispitivanje ........................................................................................35 3.2.3 Analiza odstupanja ........................................................................................... 37 3.2.3.1 Ocena lakoće kreiranja/izmene izveštaja .................................................. 38 3.2.3.2 Ocena lakoće kreiranja/izmene ekranskih formi ..................................... 39 3.2.3.3 Ocena lakoće izmene poslovnih procesa .................................................. 40 3.2.3.4 Izbor modela rada sa bazom podataka (Direct / Meta-Model) ................ 41 3.2.3.5 Ocena lakoće integracije sa drugim aplikacijama ..................................... 42 3.2.3.6 Ocena nivoa podrške za XML .................................................................... 43 3.2.3.7 Ocena nivoa podrške za Web servise ........................................................ 44 3.2.3.8 Ocena lakoće Web razvoja ........................................................................ 45 3.2.3.9 Ocena nivoa podrške za automatsko testiranje ........................................ 46 3.2.3.10 Provera da li je ispitanik upoznat sa uzorima (Design Patterns) ........... 47 3.2.4 Analiza vrednosti za 5 ERP sistema sa najvećim brojem odgovora ................ 48 3.3 Mogući kombinatorni pristupi ................................................................................ 50 4 Dynamics AX................................................................................................................... 51 4.1 Istorija Dynamics AX ............................................................................................... 52 4.2 Poslovni opis ........................................................................................................... 55 4.2.1 Prodaja ............................................................................................................... 59 4.2.2 Marketing........................................................................................................... 61 4.2.3 Upravljanje finansijama .................................................................................... 63 4.2.4 Poslovne analize ............................................................................................... 65 4.3 Tehničko/tehnološki opis ....................................................................................... 68 4.3.1 MorphX razvojno okruženje ............................................................................. 75 4.3.2 Aplikativni slojevi Dynamics AX ...................................................................... 82 4.3.3 IntelliMorph ...................................................................................................... 84 4.3.4 X++ .................................................................................................................... 86 ~ 6 ~ 6 Mogućnosti poboljšanja ERP sistema korišćenjem uzora PREDGOVOR Ova teza je rađena u periodu od decembra 2006 do oktobra 2007 na Fakultetu organizacionih nauka u Beogradu. Mentor teze je bio prof. dr Siniša Vlajić, kome se ovom prilikom zahvaljujem na stručnoj i moralnoj pomoći koju mi je pružio za svo vreme izrade teze. Tokom izrade teze, pored redovnih konsultacija gde smo imali preko 30 viđenja, profesor i ja smo razmenili preko 150 e-mail poruka. Želeo bih da se zahvalim svima onima koji su učestvovali u anketi koja je rađena za potrebe komparativne analize ERP sistema. ~ 7 ~ 7 Mogućnosti poboljšanja ERP sistema korišćenjem uzora 1 Uvod Svaki poslovni sistem se može opisati preko određene strukture i skupa poslovnih procesa koji se izvršavaju u okviru te strukture. Za većinu poslovnih sistema je definisan zajednički skup poslovnih procesa koji se izvršavaju u tim sistemima. Međutim svaki poslovni sistem ima neke svoje specifičnosti koje dovode do pojave domensko specifičnih poslovnih procesa. Ukoliko se ovi procesi žele automatizovati potrebno je da se naprave odgovarajući informacioni sistemi koji će obezbediti da svaki poslovni proces, odnosno njegova aktivnost bude što je moguće više automatizovana. Izbor odgovarajućeg poslovnog informacionog sistema predstavlja jedno od strateških pitanja na koje treba dati odgovor. Pored toga, postavlja se i sledeće pitanje: Da li treba razvijati novi informacioni sistem koji će biti u potpunosti orijentisan ka domenu nekog poslovnog sistema ili treba izabrati neki od postojećih ERP (Enterprise Resource Planning) informacionih sistema koje treba prilagoditi nekom poslovnom sistemu? Prednost novog sistema se ogleda u tome što će biti podržani svi poslovni procesi sistema, kako generalni tako i specifični. Ključni nedostatak novog sistema se ogleda u velikom vremenu koje je potrebno da se jedan takav sistem razvije, testira i uvede u operativno korišćenje. Sa druge strane uvođenje postojećih ERP rešenja traži manje vremena za njihovo uvođenje i operativno korišćenje u odnosu na nova rešenja. To se posebno odnosi na automatizaciju procesa koji su podržani postojećim ERP sistemom. Za specifične procese poslovnog sistema koji nisu podržani postojećim ERP rešenjem je potrebno više vremena i resursa kako bi se oni realizovali. Razvoj specifičnih procesa, odnosno njihova automatizacija, predstavlja jedan od ključnih problema koji se javljaju u uvođenju postojećih ERP rešenja. Postavljaju se sledeća pitanja: 1. Da li i u kojoj meri postojeća ERP rešenja obezbeđuju mehanizme koji omogućavaju da se specifični procesi lako i brzo razviju, odnosno uvedu u poslovni sistem? 2. Da li se razvoj i uvođenje, specifičnih procesa pomoću ERP rešenja, može poboljšati korišćenjem savremenih metoda razvoja softvera i uzora (paterna)? Odgovor na ova pitanje će predstavljati suštinu ovoga rada. ~ 8 ~ 8 Mogućnosti poboljšanja ERP sistema korišćenjem uzora U uvodnom delu, odnosno u prvoj glavi teze, dat je pregled, koji obuhvata: predmet istraživanja, ciljeve istraživanja, naučne hipoteze i modele i sredstva koja su korišćena u istraživanju kao i kratak opis preostalih 6 glava, u kojima je izložena kompletna magistarska teza. Predmet istraživanja ove teze se odnosi na: 1. Komparativnu analiza postojećih ERP rešenja. Analiza postojećih istraživanja poput [1] [2] [3] [4] [5] [6], i posebno istraživanje koje su autori sproveli gde se ispituje lakoća održavanja ERP rešenja. 2. Analizu postojećih metoda razvoja softvera. Razmatranje životnog ciklusa softvera iz [7] [8] [9] [10] [11] [12], sa fokusom na metodu životnog ciklusa softvera iz [13]. 3. Pregled poslovnih i softverskih uzora (paterna) i analizu Dynamics AX ERP rešenja, kako bi se utvrdilo koje uzore Dynamics AX ERP rešenje koristi u procesu uvođenja postojećih poslovnih procesa. Predlog uzora koji se trebaju koristiti u procesu i uvođenja novih domensko specifičnih procesa pomoću Dynamics AX ERP rešenja. Pregled poslovnih uzora iz [14] i softverskih uzora iz [15]. Ciljevi istraživanja ove magistarske teze se odnose na: 1. Komparativnu analizu postojećih ERP rešenja. 2. Analizu Dynamics AX ERP rešenja i njegovog MorphX razvojnog okruženja, X++ programskog jezika i IntelliMorph prezentacione tehnologije. Utvrđivanje načina uvođenja novih domensko specifičnih poslovnih procesa (uvođenje vertikalne funkcionalnosti) pomoću Dynamics AX ERP rešenja. 3. Analizu Larmanove metode razvoja softvera u odnosu na druge metode razvoja softvera (spiralna metoda, ..., jedinstveni proces razvoja softvera). 4. Pregled poslovnih i softverskih uzora i predlog uzora koji se trebaju koristiti u procesu uvođenja novih domensko specifičnih procesa pomoću Dynamics AX ERP rešenja. 5. Ispitivanje mogućnosti poboljšanja procesa razvoja Dynamics AX ERP rešenja korišćenjem Larmanove metode i uzora. Hipoteze ove magistarske teze su sledeće: 1. Dynamics AX ERP rešenje pruža razvojno okruženje koje olakšava proces razvoja domensko specifičnih procesa. 2. Dynamics AX ERP rešenje sadrži poslovne i softverske uzore koji se koriste prilikom uvođenje postojećih poslovnih procesa u poslovni sistem. 3. Proces razvoja i uvođenja domensko specifičnih procesa može biti poboljšan korišćenjem Larmanove metode razvoja softvera i korišćenjem poslovnih i softverskih uzora. ~ 11 ~ 11 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Kao što su nevešti fizički radnici bili dominantna socijalna i politička sila u 20. veku, tehničari će postati dominantna socijalna, a možda i politička sila, u sledećim decenijama. - Peter Drucker 2 ERP U ovom poglavlju će prvo biti opisani ERP sistemi. Potom će biti objašnjen proces njihovog nastanka, i na kraju će biti dati dalji tokovi razvoja ERP sistema. Na osnovu ovog poglavlja autori su objavili rad [16]. Na slici 2 je dat konceptualni dijagram ove glave. Na slici se vidi evolucija ERP sistema, od MRP, preko MRP zatvorene petlje i MRP II, pa do ERP sistema. MRP II (Manufacturing Resource Planning) ERP (Enterprise Resource Planning) MRP (Material Requirements Planning) Closed-loop MRP ES (Enterprise Software) Sadrži elemente Sastavnice (BOM, Bill Of Material) Glavni plan (Master Schedule) Podatke iz magacina Koristi Koristi Budući zahtevi za nabavkom Daje odgovor šta su Koristi Planiranje rada pogona Planiranje nabavke Planiranje prodaje Analiza resursa Simulacija Finansijski interfejs Planiranje operativne prodaje Potpuni lanac snabdevanja Rad sa više poslovnih jedinica Pojačana finansijska integracija Koordinacija svih delova poslovnog sistema Jedinstven skup alata Integracija u realnom vremenu Slika 2: Konceptualni dijagram ERP-a ~ 12 ~ 12 Mogućnosti poboljšanja ERP sistema korišćenjem uzora ERP (Enterprise Resource Planning) sistemi su takvi gotovi informacioni sistemi koji su orijentisani na informaciono podržavanje većine najčešćih poslovnih procesa. Kao skraćenica ERP se takođe koristi da označi ERP procese, ERP sisteme, ili ERP softver. ERP procesi su procesi poput nabavke, prodaje, upravljanja skladištem, finansija, ali i njihovog planiranja. ERP sistemi su takvi sistemi koji realizuju većinu ERP procesa, a ERP softverski paketi su takvi paketi koji pružaju informacionu podršku ERP sistemima. 2.1. ERP sistemi i njihov nastanak Pojam ERP je originalno označavao sisteme koji su projektovani da koriste resurse celog preduzeća. Iako je skraćenica potekla iz proizvodnog okruženja, danas se ona koristi u mnogo širem smislu: neprofitne, nevladine i vladine organizacije i veliki poslovni sistemi, često koriste ERP sisteme. Istorija razvoja ERP sistema je prikazana na slici 3 [17 str. 7] Slika 3: Evolucija ERP-a ERP je počeo svoj život 60-ih godina kao planiranje materijalnih zahteva (Material Requirements Planning, MRP). Nastao je kao rezultat ranih napora u procesiranju sastavnica (Bill Of Materials, BOM). Pronalazači MRP-a su tražili bolji metod naručivanja materijala i komponeneti, i našli su ga u ovoj tehnici. ~ 13 ~ 13 Mogućnosti poboljšanja ERP sistema korišćenjem uzora MRP simulira univerzalnu proizvodnu jednačinu. On koristi glavni plan (master schedule), sastavnice (bill of material) i podatke iz skladišta da bi kroz pitanja: Šta ćemo da pravimo? (glavni plan) Šta nam treba da bi to napravili? (sastavnice) Šta trenutno imamo? (podaci iz skladišta) odredio buduće zahteve i dao odgovor na pitanje „Šta moramo da nabavimo?“. U MRP su dodate tehnike za pomoć pri planiranju zahteva kapaciteta. Razvijeni su dodatni alati da se bi podržalo planiranje agregatnih prodaja i produkcionih nivoa; razvoj specifičnih proizvodnih planova; predviđanje, planiranje prodaje, ponude kupcima; i analize resursa visokog nivoa. Uključeni su sistemi za podršku izvršenja plana: razne tehnike planiranja rada pogona za planiranje rada unutar fabrike i planiranje odnosa sa dobavljačima za planiranje rada van fabrike. Ovaj razvoj je rezultirao drugim korakom evolucije ERP-a, tj. MRP-om zatvorene petlje (closed-loop MRP) [17 str. 8], čija je shema data na slici 4 [17 str. 9]. Slika 4: MRP zatvorene petlje Sledeći korak ove evolucije je planiranje proizvodnih resursa (Manufacturing Resource Planning, MRP II). Direktni nastavak i proširenje closed-loop MRP-a, uključuje tri dodatna elementa [17 str. 10]: 1. Planiranje prodaje i operacija – moćan proces za balansiranje ponude i tražnje na nivou obima, omogućuje upravi mnogo veću kontrolu nad operativnim aspektima poslovanja. 2. Finansijski interfejs – mogućnost da se operativni plan (u parčićima, kilogramima, galonima ili drugim jedinicama mere) prevede u finansijske termine (novčane jedinice). 3. Simulacija – mogućnost da se postave “šta-ako” pitanja i dobiju odgovori na osnovu kojih može da se reaguje – i u jedinicama mere i u novčanim. U početku ovo je bilo moguće samo na agregatnoj, gruboj bazi, ali današnji sistemi za napredno planiranje (APS, Advanced Planning Systems) omogućuju veoma efektivno izvođenje simulacije, do nivoa detalja. ~ 16 ~ 16 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Nisu sve poslovne funkcije ERP-a sadržane u tipičnom Enterprise Software (ES) paketu. Takođe, tipični ES sadrži podršku za poslovne procese koji nisu deo ERP-a. Slika 6: ERP Procesi Na slici 6 [17 str. 4] ova razlika je prikazana grafički. Desna zona predstavlja one funkcije koje sadrži tipičan ES, a nisu deo ERP-a; leva zona sadrži one funkcije ERP-a koje normalno nisu deo ES-a; zona preklapanja u centru sadrži one funkcije ERP-a koje tipično podržava Enterprise Software. Definicija ERP-a po Thomas Wallace i Michael Kremzar je [17 str. 5]: „Skup alata za upravljanje koji balansira potražnju i ponudu na nivou preduzeća, sa mogućnošću povezivanja kupaca i dobavljača u potpuni lanac snabdevanja, primenom dokazanih poslovnih procesa za donošenje odluka. Oni omogućavaju visoki stepen među- funkcijske integracije između prodaje, marketinga, proizvodnje, operacija, logistike, nabavke, finansija, razvoja novih proizvoda, i ljudskih resursa. Na taj način je omogućeno ljudima da upravljaju svojim poslovanjem sa visokim nivoom produktivnosti i usluge korisniku, i simultano smanjujući troškove i nivo zaliha. Time je omogućena osnova za efektivni e-commerce.“ Kao skup veoma integrisanih podsistema, ERP sistemi mogu da se opišu kao usko povezani (tightly coupled). Uska povezanost olakšava koordinaciju između podsistema i rešava fragmetaciju informacija [20]. ~ 17 ~ 17 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Veoma formalna definicija ERP sistema je data u [21]: „ERP je uređena trojka (P, PL, g) gde je P ne-prazan skup tipova procesnih lanaca (process chain type)2;PL je skup veza procesnih lanaca (PCLINK)3;g je skup funkcija koji povezuje svaku vezu procesnih lanaca pl sa uređenim parom veza procesnih lanaca (p1, p2) gde je p1 prethodni tip procesnog lanca a p2 naredni tip procesnog lanca veze procesnih lanaca pl “. ERP može da se definiše i kao: “automatizacija i integracija informacija, procesa i funkcija u proizvodnim (ili drugim) okruženjima, koja rezultuje zatvorenom petljom, koja je funkcionalno integrisana, sa planiranjem i izvršenjem u realnom vremenu, i kontrolnim sistemima koji su lokacijski i jezički nezavisni i koji sve više uključuju kupce, dobavljače i partnere” [22]. Većina definicija konstatuje da ERP sistemi integrišu (ili pokušavaju da integrišu) sve podatke i procese organizacije u jedinstveni sistem. Naša definicija bi bila: “ERP sistemi su takvi sistemi koji mogu bez ikakve dorade da pokriju većinu informacionih potreba bilo koje vrste preduzeća, automatizacijom i integracijom informacija, procesa i funkcija u zatvorenu petlju odnosa sa kupcima, dobavljačima i partnerima. Time se stvara potpuni lanac snabdevanja, sa visokim stepenom među- funkcijske integracije i uske povezanosti podsistema preduzeća koji mogu da budu geografski i jezički nezavisni, i na taj način omogućava planiranje i izvršavanje aktivnosti poslovnog procesa u realnom vremenu, što omogućava visok nivo produktivnosti rada i smanjenje utrošenog vremena i resursa.” 2.2 Dalji razvoj ERP sistema ERP softverska rešenja su priznata kao najznačajniji deo infrastrukture informacionih tehnologija modernih preduzeća [23]. ERP softverska rešenja moraju da istovremeno poseduju makar tri navedene karakteristike [24]: efikasno upravljanje raznim aktivnostima preduzeća postojanje zajedničke baze podataka sposobnost za brzo reagovanje na operativna pravila Pojava tehnologija poput elektronske trgovine (e-commerce), sistema za upravljanje odnosima sa kupcima 4 (CRM, Customer Relationship Management) i sistema za upravljanje lancem snabdevanja (SCM, Supply Chain Management) pruža mogućnosti za poboljšanje ERP rešenja [25]. 2 Tačna definicija tipova procesnih lanaca prevazilazi granice ovog rada, ali može se reći da je to uređena trojka funkcija koje preslikavaju ulazne vrednosti na transakcione tipove podataka, funkcionalnih veza i asocijativnih funkcija koje povezuju prethodna dva pojma. 3 Tačna definicija veza procesnih lanaca prevazilazi granice ovog rada, ali može se reći da je to unarna relacija nad P, i da povezuje dva tipa procesnih lanaca. 4 CRM je deo nekih ERP softverskih rešenja, iako se na slici 4 ne tretira kao osnovni deo ERP sistema. ~ 18 ~ 18 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Proširenje trendova u elektronskom poslovanju zahteva da proizvodne kompanije upravljaju internim procesima digitalno i sarađuju sa svojim partnerima koristeći standardizovane interfejse [26; 27; 28]. Neki autori ova proširenja i zahteve koriste da definišu i ERP II, kao proširenje ERP-a sistemima za upravljanje odnosima sa kupcima i sistemima za upravljanje lancem snabdevanja [29]. Na slici 7 [29] je prikazan prošireni lanac nabavke u ERP II sistemu. Web servisi su identifikovani kao jedan od faktora razvoja ERP II sistema [29]. Slika 7: Integrisani prošireni lanac nabavke ERP II Glavna uloga implementacije ERP sistema je mnogo uspešnije vođenje preduzeća, u promenjivom i konkurentnom okruženju. Često prilikom implementacije zaposleni u preduzeću kažu “Mi smo različiti, ovo neće raditi kod nas”. Isto tako se veoma često ispostavi, da ERP softver može veoma lako da podrži većinu tih specifičnosti, uz manja podešavanja i dorade. Nabavka ERP softvera, sama po sebi neće od preduzeća učiniti ERP sistem, niti će ga učiniti iskusnim u njegovoj primeni, i preduzeće neće ostvariti konkurentsku prednost. Da bi preduzeće bilo konkurentno ono mora da bude orijentisano ka ERP-u, ono mora da posveti svoje najbolje ljude njegovoj implementaciji, ali mora i da poseduje dobar i kvalitetan skup alata, koji čine ERP softver. ~ 21 ~ 21 Mogućnosti poboljšanja ERP sistema korišćenjem uzora 3.1 Opšta analiza Prilikom vršenja poređenja ERP sistema, veoma često se vrši kategorizacija na osnovu dostupnih funkcionalnosti, ili cene (vrednosti licenci), ili nekih drugih kriterijuma. ERP sistemi se na ovaj način grupišu u redove (tier). Ovo je pogodan, ali nije savršen način diferencijacije. Jedan od prvih paralelnih prikaza više ERP sistema je dat u [1]. Dati su prikazi sledećih kompanija: SAP, Oracle, PeopleSoft i Baan i ERP sistema koje oni proizvode. Za svaki od navedenih ERP sistema su navedeni glavni elementi zbog kojih se smatra da se dati ERP sistem nalazi na vodećoj poziciji. Takođe su opisani glavni rizici za implementaciju ovih ERP sistema. Finansijski podaci koji su prikazani, su bazirani na izveštajima iz 1998. i 1997. godine. Za svaki od ERP sistema dato je predviđanje budućih akcija do 2002. godine. Za Oracle je data prognoza da će biti na gubitku ukoliko se nastavi konsolidacija industrije. Promene i akvizicije kod proizvođača ERP sistema su veoma česte, pa je teško ispratiti različita istraživanja iz prošlosti. Centralna evidencija integracija ERP sistema je data na [37]. I ovde su ERP sistemi svrstani u redove (tier), i to: Tier 1: Oracle, SAP Tier 2: Infor Global, Epicor, ... Tier 3: Microsoft Business Solutions, Sage, ... Neki od ERP sistema koje proizvode kompanije sa najvećim učešćem na tržištu [30; 31] su tokom svog razvoja uključili i sledeće ERP sisteme i proizvođače ERP sistema [37] (ovde su navedeni i proizvodi/proizvođači koji su pridodati kao deo prethodnih akvizicija): Oracle: Hyperion, Siebel, Retek, Demantra, PeopleSoft, JDEdwards, YouCentric, Numetrix, Vantive, RedPepper, Datalogix, G-Log. SAP: OutlookSoft, Triversity, TopTier, Lighthammer. Microsoft Business Solutions: Great Plains, Real World, FRX, Navision, Damgaard/Axapta, Solomon. Sage: Abra, ACCPAC, SBT, ACT!, Adonix, Best, BusinessVision, BusinessWorks, FAS, MAS90/200, Peachtree, PFW, SalesLogix, SimplyAccounting, Tetra, Timberline. Infor: SSA, Interbiz, MK, PRMS, Acacia, Ask, Baan, Marcam, MXP, Infinium, E- piphany, Boniva, Arzoon, EXE, Ironside Technologies, BPCS, Mapics, Frontstep, Maincore, Pivotpoint, Thru-Put, Mercia, Varial, Swan, SCT Adage, Fygir, Lilly, Aperum, FACTS, TakeStock, DMAS, Brain, NxTrend, Dimasys, daly.commerce, Formation, IncoDev, Geac, JBA, DBS, Runtime, RatioPlan, Streamline, Management Data, Extensity, SystemsUnion, Comshare, Datastream. ~ 22 ~ 22 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Jedno od istraživanja koje pokušava da uporedi ERP sisteme je [2]. U ovom istraživanju poređenje je vršeno po tri ključne oblasti: Osnovne funkcionalnosti: Ova kategorija poredi softverski proizvod nasuprot osnovnim standardima za glavnu knjigu, odnose sa dobavljačima, naloge za nabavku, odnose sa kupcima, zarade, ljudske resurse, kontrolu magacina, prodajne naloge, troškove poslovanja i mogućnosti budžetiranja. Ukupne funkcionalnosti: U ovoj kategoriji merene su funkcionalnosti vezane za proizvodnju i više valutni sistem, kao i sistemske funkcionalnosti koje nisu povezane sa individualnim modulima. Implementirane (out of the box) funkcionalnosti: Ova kategorija meri funkcionalnosti sa kojima se proizvod isporučuje, i ne računa funkcionalnosti koje mogu da se postignu izmenom ili korišćenjem dodatnih komponenti. Pored ovih poređenje, vršeno je poređenje i po dva industrijska segmenta: Distribucija: Za ovu kategoriju je podrazumevano da je u pitanju distrubutivna organizacija sa zahtevima prema kontroli magacina i unosu naloga. Nisu definisani zahtevi za više valutnim sistemom. Proizvodnja: Za ovu kategoriju je podrazumevano da je u pitanju proizvodna organizacija usmerena prema kontroli magacina i proizvodnji. Definisani su zahtevi za više valutnim sistemom, pošto proizvođači često naručuju iz stranih zemalja, ili prodaju robu u stranim zemljama. ~ 23 ~ 23 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Na slici 9 [2] je dat prikaz rezultata za funkcionalnosti iz kategorije osnovih funkcionalnosti. Slika 9: Poređenje osnovnih funkcionalnosti Na slici 10 [2] je dat prikaz rezultata za funkcionalnosti iz kategorije ukupnih funkcionalnosti. Slika 10: Poređenje ukupnih funkcionalnosti ~ 26 ~ 26 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Na slici 15 [3] prikazan je prvi deo rezultata, koji sadrži opšte i finansijske podatke o svakom ERP sistemu. Slika 15: Opšte i finansijski podaci o ERP sistemima Na slici 16 [3] prikazan je drugi deo rezultata, koji sadrži podatke o dostupnim funkcionalnostima po modulima. Slika 16: Podaci o dostupnim funkcionalnostima ERP sisteima ~ 27 ~ 27 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Na slici 17 [3] prikazan je treći deo rezultata, koji sadrži podatke o broju korisnika, prihodima, i podatke po oblastima poslovanja. Slika 17: Podaci o broju korisnika, prihodima i oblastima poslovanja Na slici 18 [3] prikazan je četvrti deo rezultata, koji sadrži tehničko tehnološke o svakom ERP sistemu. Slika 18: Tehničko tehnološki podaci o ERP sistemima ~ 28 ~ 28 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Na slici 19 [3] prikazan je peti deo rezultata, koji prikazuje podatke ograničenjima i opštim osobinama. Slika 19: Podacio o ograničenjima i opštim osobinama Na slici 20 [3] prikazan je šesti deo rezultata, koji sadrži podatke o više valutnom sistemu, finansijama i radnim tokovima. Slika 20: Podaci o više valutnom sistemu, finansijama i radnim tokovima ~ 31 ~ 31 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Na slici 25 [3] prikazan je poslednji deo rezultata, koji sadrži podatke o posebnim funkcionalnostima svakog ERP sistema. Slika 25: Posebne funkcionalnosti ERP sistema Pored prikazanih ERP sistema, u trećem redu (tier 3) se nalaze još i DEACOM, Enterprise 21, Epicor Enterprise, Exact Macola ERP, Made2Manage Enterprise Business System, Mar-Kov CMS, Microsoft Dynamics GP, Microsoft Dynamics NAV, Microsoft Dynamics SL, Navigator, PSI.erp, Q360, Sage Accpac 500 ERP, SAP Business One, Scoopsoft, Syspro. Pored navedenih ovo istraživanje obuhvata još 15 ERP sistema četvrtog reda (tier 4) i jedan ERP sistem petog reda (tier 5). Na osnovu prikazanih poređenja može se zaključiti da većina ERP sistema prvog i drugo reda kvalitetno podržava većinu osnovnih poslovnih procesa. Svakako da sa već tri godine ispitivanja, i veoma velikim brojem pitanja i podataka o ERP sistemima, ovo istraživanje predstavlja jedno od najsveobuhvatnijih istraživanja do danas. Istraživanje koje je sproveo Dr. Marco Iansiti [6] na veoma detaljan način poredi ERP sisteme sa aspekta produktivnosti korisnika. Međutim, ovo istraživanje je fokusirano samo na poređenje Microsoft Dynamics i SAP. U nastavku ovog dela će biti prikazan opis ovog istraživanja i rezultati koji su dobijeni. U ovom istraživanju, razvijena je platforma za merenje poslovne produktivnosti korisnika. Ova platforma je razvijena kombinovanjem standardnih industrijskih testova korisnosti i rezultatima opsežnih istraživanja sprovedenim kod krajnjih korisnika iz odeljenja za prodaju i marketning, finansije i operativno poslovanje. Testovi poput SUMI (Software Usability Measurement Inventory), su korišćeni da bi se identifikovali tipični faktori koji utiču na stepen korisnosti aplikacija i produktivnost krajnjeg korisnika. SUMI je široko poznat, kao metodologija standarda industrije, i koristi se i unapređuje već 15 godina, u grupi za istraživanje ljudskih faktora na Cork univerzitetu u Irskoj. Neke od oblasti koje su pokrivene ovom platformom za merenje poslovne produktivnosti korisnika su prikazane na slici 26 [6]. ~ 32 ~ 32 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Slika 26: Platforma za merenje poslovne produktivnosti Istraživanje se sastojalo od 85 iskaza o poslovnoj produktivnosti softvera, grupisanim u šest kategorija. Istraživanje je sprovedeno putem telefona. Intervjuisani su krajnji korisnici Microsoft Dynamics NAV i Microsoft Dynamics GP (66 ispitanika) i SAP All-in-One i SAP R/3 (33 ispitanika) u prodaji i marketingu, finansijama i operativnom odeljenju. Svaki od ispitanika je bio iz različite kompanije, koje su slučajno izabrane. Na svaki od iskaza, ispitanici su trebali da daju ocenu od 1 do 7, gde je 1 značilo da se veoma ne slažu, a 7 da se veoma slažu sa iskazom. Broj 4 je odznačavao neutralan stav prema iskazu. Bilo je moguće da ispitanici kažu da ne znaju, ili da dati iskaz ne može da se primeni na njihovu situaciju. Prosečna produktivnost je prikazana na slici 27 [6]. Slika 27: Prosečna poslovna produktivnost ~ 33 ~ 33 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Procentualna razlika u poslovnoj produktivnosti po kategorijama je prikazana na slici 28 [6]. Slika 28: Procentualna razlika u poslovnoj produktivnosti po kategorijama 3.2 Analiza lakoće održavanja i korišćenja uzora Za potrebe ovog rada izvršeno je istraživanje, čiji je fokus bio ispitavanje lakoće održavanja različitih ERP sistema, a pogotovo ispitivanje korišćenja uzora u različitim ERP sistemima. Ovo istraživanje svakako predstavlja pionirski pokušaj u oblasti ERP sistema. Ovo istraživanja predstavlja doprinos veće važnosti (DOP-KOMPANALIZA) ove magistarske teze. Istraživanje je sprovedeno u dve faze. U prvoj fazi su odgovori skupljani direktnim kontaktom, i prikupljeni su odgovori od 28 ispitanika. U drugoj fazi odgovori su skupljani putem anonimne „online“ ankete6, i prikupljeni su odgovori iz 96 sesija7. U istraživanju se od svakog ispitanika tražilo da unese odgovore za svaki od ERP sistema u kome ima iskustva. 6 Anketa je dostupna na sajtu autora [29]. Direktna adresa je http://www.bojanjovicic.com/ERPQuestionnaire. 7 Zbog anonimnosti ankete, nije moguće poistovetiti broj sesija sa brojem ispitanika. ~ 36 ~ 36 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Iz napred navedenog možemo zaključiti da je kao i u direktnom ispitivanju, i ovde pokazano da je u ERP sistemima, najmanja podrška za automatsko testiranje, što svakako može da bude veliki nedostatak, pogotovo u razvoju orijentisanom ka testiranju (TDD, Test Driven Development). Kao najlakšu ili najbolje podržanu aktivnost, ispitanici su kao u direktnom ispitivanju, naveli kreiranje i modifikaciju formi. U tabeli 2 je prikazan broj odgovora po ERP sistemima za direktno ispitivanje9: Naziv Frekvencija Procentualno ASW 1 1.0 Baan 1 1.0 DataLab PANTHEON 7 7.3 Dynamics AX 14 14.6 Dynamics GP 3 3.1 Dynamics NAV 15 15.6 Dynamics SL 3 3.1 Glovia 2 2.1 IPIS+ 1 1.0 J D Edwards 1 1.0 Laser ERP 1 1.0 Microsoft C5 1 1.0 Microsoft XAL 1 1.0 MIS 3 3.1 OfBiz 1 1.0 Oracle EBS 10 10.4 People Soft 1 1.0 Sage 1 1.0 SAP 18 18.8 Unknown 10 10.4 UPIS 1 1.0 Ukupno 96 100.0 Tabela 2: Broj odgovora po ERP sistemima za anonimno ispitivanje 9 U kategoriju Unknown su svrstani ERP sistemi za koje autori nemaju informacije o postojanju. ~ 37 ~ 37 Mogućnosti poboljšanja ERP sistema korišćenjem uzora 3.2.3 Analiza odstupanja U ovom delu ćemo razmatrati spojene odgovore za oba ispitivanja, i prikazati odstupanja direktnog ili anonimnog ispitivanja. Za sva pitanja je radjen T test i utvrđeno je da nema statističkih značajnih razlika između anoniminih i direktnih odgovora. Broj odgovora po ERP sistemima za celo istraživanje je dat u tabeli 3: Naziv Frekvencija Procentualno Dynamics AX 28 20.3 SAP 25 18.1 Dynamics NAV 24 17.4 Oracle EBS 11 8.0 Unknown 10 7.2 Dynamics GP 8 5.8 DataLab PANTHEON 7 5.1 Dynamics SL 3 2.2 MIS 3 2.2 Glovia 2 1.4 JD Edwards 2 1.4 Perftech.Largo 2 1.4 ASW 1 0.7 Baan 1 0.7 Epicor 1 0.7 IPIS+ 1 0.7 IT-Enterprise 1 0.7 Laser ERP 1 0.7 Microsoft C5 1 0.7 Microsoft XAL 1 0.7 OfBiz 1 0.7 People Soft 1 0.7 Sage 1 0.7 Siebel 1 0.7 UPIS 1 0.7 Ukupno 138 100.0 Tabela 3: Broj odgovora po ERP sistemima za celo istraživanje Kao što se iz tabele 3 vidi, ERP sistemi za koje je prikupljeno najviše odgovora su: Dynamics AX, SAP, Dynamics NAV, Oracle EBS i Dynamics GP. U nastavku ovog dela će za svako pitanje biti prikazan broj dobijenih odgovora po ponudjenim kategorijama i procentualno učešće, za ukupne odgovore, anonimne i direktne, sa pratećim graficima. ~ 38 ~ 38 Mogućnosti poboljšanja ERP sistema korišćenjem uzora 3.2.3.1 Ocena lakoće kreiranja/izmene izveštaja U tabeli 4 je prikazana analiza dobijenih odgovora za pitanje ocena lakoće kreiranja/izmene izveštaja, sa brojem odgovora po ponuđenim kategorijama i procentualno učešće, za ukupne odgovore, i posebno za anonimne i direktne. Lakoća kreiranja/izmene izveštaja Ukupno Anonimni Direktni Frekvencija Procentualno Frekvencija Procentualno Frekvencija Procentualno Veoma lako 10 7.2 8 8.3 2 4.8 2 21 15.2 16 16.7 5 11.9 3 42 30.4 34 35.4 8 19 4 39 28.3 20 20.8 19 45.2 Veoma teško 26 18.8 18 18.8 8 19 Ukupno 138 100 96 100 42 100 Tabela 4: Analiza odgovora za ocenu lakoće kreiranja/izmene izveštaja Na slici 29 je dat grafički prikaz procentualnog učešća po odgovorima za združene odgovore iz oba ispitivanja. Slika 29: Analiza združenih odgovora za ocenu lakoće kreiranja/izmene izveštaja Na slici 30 je dat grafički prikaz procentualnog učešća po odgovorima za odgovore iz anonimnog i direktnog ispitivanja. Slika 30: Analiza odgovora za ocenu lakoće kreiranja/izmene izveštaja po istraživanjima 7.2 15.2 30.4 28.3 18.8 0.0 5.0 10.0 15.0 20.0 25.0 30.0 35.0 Veoma lako 2 3 4 Veoma teško 8 .3 16 .7 35 .4 20 .8 18 .8 4 .8 11 .9 19 .0 4 5. 2 19 .0 0.0 10.0 20.0 30.0 40.0 50.0 Veoma lako 2 3 4 Veoma teško Anonimni Direktni ~ 41 ~ 41 Mogućnosti poboljšanja ERP sistema korišćenjem uzora 3.2.3.4 Izbor modela rada sa bazom podataka (Direct / Meta-Model) U tabeli 7 je prikazana analiza dobijenih odgovora za pitanje modela rada sa bazom podataka, sa brojem odgovora po ponuđenim kategorijama i procentualno učešće, za ukupne odgovore, i posebno za anonimne i direktne. Model rada sa bazom podataka (Direct / Meta-Model) Ukupno Anonimni Direktni Frekvencija Procentualno Frekvencija Procentualno Frekvencija Procentualno Direktno 84 60.9 72 75 12 28.6 Meta-model 51 37 24 25 27 35.7 Bez odgovora 3 2.2 3 7.1 Ukupno 138 100 96 100 42 100 Tabela 7: Analiza odgovora za model rada sa bazom podataka Na slici 35 je dat grafički prikaz procentualnog učešća po odgovorima za združene odgovore iz oba ispitivanja. Slika 35: Analiza združenih odgovora za model rada sa bazom podataka Na slici 36 je dat grafički prikaz procentualnog učešća po odgovorima za odgovore iz anonimnog i direktnog ispitivanja. Slika 36: Analiza odgovora za model rada sa bazom podataka po istraživanjima 2.2 60.9 37.0 0.0 20.0 40.0 60.0 80.0 Bez odgovora Direktno Meta-model 75 .0 25 .0 7. 1 28 .6 35 .7 0 20 40 60 80 Bez odgovora Direktno Meta-model Anonimni Direktni ~ 42 ~ 42 Mogućnosti poboljšanja ERP sistema korišćenjem uzora 3.2.3.5 Ocena lakoće integracije sa drugim aplikacijama U tabeli 8 je prikazana analiza dobijenih odgovora za pitanje ocena lakoće integracije sa drugim aplikacijama, sa brojem odgovora po ponuđenim kategorijama i procentualno učešće, za ukupne odgovore, i posebno za anonimne i direktne. Lakoća integracije sa drugim aplikacijama Ukupno Anonimni Direktni Frekvencija Procentualno Frekvencija Procentualno Frekvencija Procentualno Veoma lako 7 5.1 6 6.3 2 2.4 2 20 14.5 13 13.5 17 16.7 3 51 37 41 42.7 24 23.8 4 37 26.8 25 26 29 28.6 Veoma teško 23 16.7 11 11.5 29 28.6 Ukupno 138 100 96 100 100 100 Tabela 8: Analiza odgovora za ocenu lakoće integracije sa drugim aplikacijama Na slici 37 je dat grafički prikaz procentualnog učešća po odgovorima za združene odgovore iz oba ispitivanja. Slika 37: Analiza združenih odgovora za ocenu lakoće integracije sa drugim aplikacijama Na slici 38 je dat grafički prikaz procentualnog učešća po odgovorima za odgovore iz anonimnog i direktnog ispitivanja. Slika 38: Analiza odgovora za ocenu lakoće integracije sa drugim aplikacijama po istraživanjima 5.1 14.5 37.0 26.8 16.7 0.0 5.0 10.0 15.0 20.0 25.0 30.0 35.0 40.0 Veoma lako 2 3 4 Veoma teško 6 .3 13 .5 4 2. 7 26 .0 11 .5 2. 4 16 .7 23 .8 28 .6 28 .6 0.0 5.0 10.0 15.0 20.0 25.0 30.0 35.0 40.0 45.0 Veoma lako 2 3 4 Veoma teško Anonimni Direktni ~ 43 ~ 43 Mogućnosti poboljšanja ERP sistema korišćenjem uzora 3.2.3.6 Ocena nivoa podrške za XML U tabeli 9 je prikazana analiza dobijenih odgovora za pitanje ocene nivoa podrške za XML, sa brojem odgovora po ponuđenim kategorijama i procentualno učešće, za ukupne odgovore, i posebno za anonimne i direktne. Podrška za XML Ukupno Anonimni Direktni Frekvencija Procentualno Frekvencija Procentualno Frekvencija Procentualno Veoma loša 15 10.9 11 11.5 4 9.5 2 29 21 18 18.8 11 26.2 3 42 30.4 38 39.6 4 9.5 4 29 21 20 20.8 9 21.4 Odlična 22 15.9 9 9.4 13 31 Bez odgovora 1 0.7 1 2.4 Ukupno 138 100 96 100 42 100 Tabela 9: Analiza odgovora za ocenu nivoa podrške za XML Na slici 39 je dat grafički prikaz procentualnog učešća po odgovorima za združene odgovore iz oba ispitivanja. Slika 39: Analiza združenih odgovora za ocenu nivoa podrške za XML Na slici 40 je dat grafički prikaz procentualnog učešća po odgovorima za odgovore iz anonimnog i direktnog ispitivanja. Slika 40: Analiza odgovora za ocenu nivoa podrške za XML po istraživanjima 10.9 21.0 30.4 21.0 15.9 0.7 0.0 5.0 10.0 15.0 20.0 25.0 30.0 35.0 Veoma loša 2 3 4 Odlična Bez odgovora 11 .5 18 .8 39 .6 20 .8 9 .4 9 .5 26 .2 9 .5 2 1. 4 3 1. 0 2. 4 0.0 5.0 10.0 15.0 20.0 25.0 30.0 35.0 40.0 45.0 Veoma loša 2 3 4 Odlična Bez odgovora Anonimni Direktni ~ 46 ~ 46 Mogućnosti poboljšanja ERP sistema korišćenjem uzora 3.2.3.9 Ocena nivoa podrške za automatsko testiranje U tabeli 12 je prikazana analiza dobijenih odgovora za pitanje ocena nivoa podrške za automatsko testiranje, sa brojem odgovora po ponuđenim kategorijama i procentualno učešće, za ukupne odgovore, i posebno za anonimne i direktne. Podrška za automatsko testiranje Ukupno Anonimni Direktni Frekvencija Procentualno Frekvencija Procentualno Frekvencija Procentualno Veoma loša 26 18.8 18 18.8 8 19 2 25 18.1 21 21.9 4 9.5 3 52 37.7 38 39.6 14 33.3 4 18 13 13 13.5 5 11.9 Odlična 12 8.7 6 6.3 6 14.3 Bez odgovora 5 3.6 5 11.9 Ukupno 138 100 96 100 42 100 Tabela 12: Analiza odgovora za ocenu nivoa podrške za automatsko testiranje Na slici 45 je dat grafički prikaz procentualnog učešća po odgovorima za združene odgovore iz oba ispitivanja. Slika 45: Analiza združenih odgovora za ocenu nivoa podrške za automatsko testiranje Na slici 46 je dat grafički prikaz procentualnog učešća po odgovorima za odgovore iz anonimnog i direktnog ispitivanja. Slika 46: Analiza odgovora za ocenu nivoa podrške za automatsko testiranje po istraživanjima 18.8 18.1 37.7 13.0 8.7 3.6 0.0 5.0 10.0 15.0 20.0 25.0 30.0 35.0 40.0 Veoma loša 2 3 4 Odlična Bez odgovora 18 .8 21 .9 39 .6 13 .5 6 .319 .0 9 .5 33 .3 11 .9 14 .3 11 .9 0.0 5.0 10.0 15.0 20.0 25.0 30.0 35.0 40.0 45.0 Veoma loša 2 3 4 Odlična Bez odgovora Anonimni Direktni ~ 47 ~ 47 Mogućnosti poboljšanja ERP sistema korišćenjem uzora 3.2.3.10 Provera da li je ispitanik upoznat sa uzorima (Design Patterns) U tabeli 13 je prikazana analiza dobijenih odgovora za pitanje poznavanja uzora, sa brojem odgovora po ponuđenim kategorijama i procentualno učešće, za ukupne odgovore, i posebno za anonimne i direktne. Da li je ispitanik upoznat sa uzorima (Design Patterns) Ukupno Anonimni Direktni Frekvencija Procentualno Frekvencija Procentualno Frekvencija Procentualno Ne 81 58.7 64 66.7 17 40.5 Da 57 41.3 32 33.3 25 59.5 Ukupno 138 100 96 100 42 100 Tabela 13: Analiza odgovora za poznavanje uzora (Design Patterns) Na slici 47 je dat grafički prikaz procentualnog učešća po odgovorima za združene odgovore iz oba ispitivanja. Slika 47: Analiza združenih odgovora za poznavanje uzora (Design Patterns) Na slici 48 je dat grafički prikaz procentualnog učešća po odgovorima za odgovore iz anonimnog i direktnog ispitivanja. Slika 48: Analiza odgovora za poznavanje uzora (Design Patterns) po istraživanjima 58.7 41.3 0.0 20.0 40.0 60.0 80.0 Ne Da 66.7 40.533.3 59.5 0.0 20.0 40.0 60.0 80.0 Anonimni Direktni Ne Da ~ 48 ~ 48 Mogućnosti poboljšanja ERP sistema korišćenjem uzora 3.2.4 Analiza vrednosti za 5 ERP sistema sa najvećim brojem odgovora U tabeli 14 je prikazana analiza prosečnih vrednosti za 5 ERP sistema sa najvećim brojem odgovora. Dynamics AX (28 odgovora) SAP (25 odgovora) Dynamics NAV (24 odgovora) Oracle EBS (11 odgovora) Dynamics GP (8 odgovora) Godina iskustva 2.96 6.94 4.21 5.18 2.28 Ocena lakoće kreiranja/izmene izveštaja 3.11 3.52 3.71 3.09 3.50 Ocena lakoće kreiranja/izmene ekranskih formi 4.29 3.44 4.25 3.09 3.75 Ocena lakoće izmene poslovnih procesa 3.86 3.28 3.67 3.18 2.88 Ocena lakoće integracije sa drugim aplikacijama 3.75 3.56 3.29 3.18 2.88 Ocena nivoa podrške za XML 3.56 3.44 3.08 3.27 2.63 Ocena nivoa podrške za Web servise 3.46 3.58 2.54 3.45 2.88 Ocena lakoće Web razvoja 3.41 3.38 2.42 3.73 2.75 Ocena nivoa podrške za automatsko testiranje 3.00 3.48 2.50 2.82 2.00 Tabela 14: Analiza vrednosti za 5 ERP sistema sa najvećim brojem odgovora Iz tabele 14 se vidi da u proseku najviše iskustva imaju ispitanici koji rade u SAP ERP sistemu, a najmanje ispitanici koji rade u Dynamics GP ERP sistemu. Ispitanici su ocenili da je kreiranje/menjanje izveštaja najlakše u Dynamics NAV, a najteže u Oracle EBS. Ekranske forme je najlakše kreirati/menjati u Dynamics AX, a najteže u Oracle EBS. Poslovne procese je najlakše menjati u Dynamics AX, a najteže u Dynamics GP. Integracija sa drugim aplikacijama je najlakša u Dynamics AX, a najteža u Dynamics GP. XML je najbolje podržan u Dynamics AX, a najlošije u Dynamics GP. Web servisi na najbolje podržani u SAP ERP sistemu, a najlošije u Dynamics NAV. Web razvoj je najlakši u Oracle EBS, a najteži u Dynamics NAV. Automatsko testiranje je najbolje podržano u SAP ERP sistemu, a najlošije u Dynamics GP. ~ 51 ~ 51 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Dynamics AX pomaže kompanijama da povećaju brzinu poslovanja, nudeći im ključ za konkurentsku prednost na današnjem složenom tržištu koje se brzo menja. On omogućava rukovodiocima da manje brinu o svakodnevnim finansijskim transakcijama, da bi mogli da se fokusiraju na informacije kako bi doneli odluke, koje su važne za ispunjavanje potreba korisnika. -Bill Gates 4 Dynamics AX 10 U ovom poglavlju će prvo biti prikazana istorija nastanka Dynamics AX ERP sistema. Potom će biti dat opis nekih poslovnih funkcionalnosti. Na kraju će biti prikazan tehničko/tehnološki opis razvojnog okruženja i programskog jezika. Kao pregled dela ovog poglavlja autor je objavio rad [41]. Rad je objavljen kao tema broja, tj. dvobroja. Na slici 51 je dat konceptualni dijagram ove glave. Za svaki od delova je dat posebni konceptualni dijagram koji detaljno prikazuje taj deo. Dynamics AX Istorija Tehničko tehnološki opis Poslovni opis Slika 51: Konceptualni dijagram Dynamics AX ERP sistema Šta je Dynamics AX? Odgovor na ovo pitanje su u jednoj rečenici dali Luis Mourao i David Weiner u svojoj knjizi “Dynamics AX” [42 str. xxi]: “Axapta11 je admiralski brod među Microsoftovim ERP sistemima, i najuzbudljiviji ERP proizvod trenutno na tržištu.” 10 Ovo poglavlje prikazuje analizu Dynamics AX ERP rešenja i njegovog razvojnog okruženja MorphX, kao i X++ programski jezik i IntelliMorph prezentacionu tehnologiju, što predstavlja drugi cilj ove magistarske teze, a deo dokaza prve hipoteze ove magistarske teze. Ovo poglavlje predstavlja doprinos manje važnosti (DOP-DAX) ove magistarske teze. 11 Axapta je jedan od ranijih naziva Dynamics AX. ~ 52 ~ 52 Mogućnosti poboljšanja ERP sistema korišćenjem uzora 4.1 Istorija Dynamics AX Na slici 52 je dat konceptualni dijagram ovog dela, na kome je opisana gruba istorija nastanaka Dynamics AX ERP sistema. Damgaard Data Damgaard Data International AS (1994) Axapta (1998) Danmax (1983) Pravi Pravi Pravi Concorde Finance / C4 (1986) Concorde XAL (1991) Pravi IBM Zajedno sa Navision (2000) Otkupljen od Microsoft (2002) Otkupljen od MBS Axapta (2002) Menja ime Dynamics AX (2005) Menja ime Slika 52: Konceptualni dijagram istorije Dynamics AX Istorijski, Dynamics AX obuhvata više od 20 godina iskustva u inovacijama poslovnih aplikacija i povećanju produktivnosti programera poslovnih aplikacija. Poslovno znanje predstavljeno u ovom proizvodu dolazi iz njegovih prethodnika XAL i C4. Ove proizvode je razvila kompanija Damgaard Data, koju je posle spajanja sa kompanijom Navision, otkupio Microsoft u 2002. godini. Najznačajniji događaji razvoja Dynamics AX (ali i samog računarstva) su opisani u[43][42][44][45]: 1983: Braća Erik i Preben Damgaard su u Kopenhagenu osnovali svoju firmu Damgaard Data. Počeli su sa knjigovodstvenim programom za PC računare, DANMAX. To je bilo samo dve godine nakon što su prvi personalni računari oglasili dolazak digitalnog doba. 1986: Tri godine kasnije, Damgaard je lansirao CONCORDE Finance (danas poznat kao CONCORDE 4, ili C4) na Danskom tržištu. CONCORDE Finance je bilo jedno od prvih integrisanih rešenja za upravljanje poslovanjem koje je nudilo podršku za LAN tehnologiju. Paradigma “LAN promene” je omogućila malim i srednjim preduzećima da u potpunosti iskoriste prednosti personalih računara. CONCORDE Finance je omogućila kompanijama i individualnim korisnicima da prilagode rešenje pojedinačnim zahtevima. CONCORDE 4 se kontinuirano održava, i još uvek je dostupan na Danskom tržištu. ~ 53 ~ 53 Mogućnosti poboljšanja ERP sistema korišćenjem uzora 1991: Damgaard je lansirano potpuno novu proizvodnu liniju - CONCORDE XAL. CONCORDE XAL je sadržao moćni 4GL12 razvojni alat, i ceo izvorni kod aplikacije, da bi kompanijama i individulanim korisnicima omogućili maksimalnu fleksibilnost prilikom podešavanja. Ovo je omogućilo poslovnim partnerima da razvijaju rešenja specijalizovana za vertikalne segmente. Sa CONCORDE XAL, Damgaard je ušao i na UNIX tržište, i ponudio dvonivojsko client/server rešenje u kombinaciji sa Oracle bazom podataka. CONCORDE XAL je bio naročita prekretnica za Damgaard, koja je omogućila većim kompanijama srednjeg obima da iskoriste veoma fleksibilno rešenje, ali i pružajući kompletno i integrisano rešenje za proizvodnju. 1994: Zajedno sa IBM-om, Preben i Erik Damgaard su postavili Damgaard International A/S kao softversku kompaniju sa 50% učešća IBM-a u akcijama. Ovo je bio početak internacionalizacije kompanije. Zajedno sa IBM- om razvijena je distribucija u Evropskim zemljama. 1995: Windows je počeo da osvaja svet ranih 90-ih godina. 1995. Windows tehnologija je počela da se primenjuje u razvoju aplikativnog softvera. Damgaard je lansirao CONCORDE XAL proizvodnu liniju za Windows. Te godine je u Danskoj lansiran i CONCORDE C5, koji je pružao integrisano Windows poslovno rešenje, bazirano na CONCORDE XAL tehnologiji, a posebno orijentisano ka potrebama malih preduzeća. 1997: Damgaard je otvorio kancelariju u Atlanti (Georgia), da bi se pripremio za ulazak na Američko tržište sa Axaptom. U isto vreme cela organizacija razvoja je prilagođenja Microsoft Solutions Framework-u, organizacionom konceptu baziranom na Microsoft-ovim sopstvenim iskustvima u razvoju velikih softverskih rešenja. 1998: U martu ove godine, Damgard je lansira0 potpuno novi integrisani ES nazvan Axapta. Axapta je podržavala objektno orijentisano razvojno okruženje, potpuno usvajanje Microsoftovih tehnologija, i tronivojsku klijent/server arhitekturu. Želja braće Damgaard je od početka bila da Dynamics AX bude međunarodni proizvod koji je integrabilan, skalabilan i fleksibilan, tako da mogu da ga isporuče na jednom CDu, za sva tržišta i platforme. Vizija Erik Damgaarda je bila da se napravi platforma koja može da evoluira sa tehnologijom i zahtevima tržišta. Axapta je osigurala moćnu platformu sa fleksibilnim mogućnostima skaliranja, koje nikada ranije nisu viđene na tržištu. Iste godine, Damgaard je preuzeo distribucione kanale od IBM-a, i kupio IBM-ov deo softverske kompanije. Postavljen je smer za ulazak na nova tržišta sa potpunom kontrolom. Damgaard je postavio kompanije u Španiji i Australiji, a potom u Engleskoj, Americi, Norveškoj i Švedskoj. 12 Programski jezik 4. generacije, skraćeno od 4. Generation Language. ~ 56 ~ 56 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Preduzeće odlučuje kada želi da proširi neophodne funkcionalnosti u zavisnosti od svojih potreba. Ono može da počne sa osnovnim modulima, kao što su finansije i trgovina, i da proširi sa proizvodnjom i odnosima sa kupcima, u zavisnosti od rasta potreba. Dynamics AX je specifična i po tome što nema čekanja za skupim unapređenjem na novu verziju (upgrade). Kada se doda novi modul, on se automatski integriše u Dynamics AX i svi podaci se sinhronizuju kroz sistem, omogućavajući korišćenje u novim i starim funkcionalnostima. Microsoft Dynamics AX je tako projektovan da se lako skalira, da bi mogao da podrži rast preduzeća. Ovo znači da preduzeće može da dodaje korisnike, lokacije i dodatne funkcionalnosti, kada mu zatrebaju. Dynamics AX koristi Axapta objektne servere (Axapta Object Server, AOS), koji mogu da se postave u takozvani klaster13 (cluster), što će im omogućiti balansiranje opterećenja i povećanje skalabilnosti. Kada preduzeću zatrebaju veće mogućnosti, samo se doda još servera u klaster. Microsoft Dynamics AX je uspešno testiran sa 1000 konkurentnih korisnika[46]. Pošto svi korisnici, lokacije, i procesi koriste jedinstvenu bazu podatka, održavanje i unapređenje su mnogo jednostavniji i jeftiniji u poređenju sa distribuiranim sistemima. Pošto Microsoft Dynamics AX podržava klasterovanje servera, omogućene su visoke performanse, čak i sa više preduzeća u različitim zemljama. Ovome doprinosi i mogućnost klasterovanja servera baze podataka. Microsoft Dynamics AX može da proširi poslovne procese preko Interneta, tako da preduzeće može da poveže svoj posao sa kupcima, dobavljačima i udaljenim zaposlenima, bez obzira na lokaciju. Ovo pomaže u povećanju brzine i vrednosti komunikacije, a smanjuje transakcione troškove i za preduzeće a i za njegove poslovne partnere. Dynamics AX omogućava kreiranje personalizovanih Web portala, zasnovanih na ulogama, koji pružaju informacije i pristup aplikacija preko Interneta. Web portali olakšavaju komunikaciju između pojedinaca i preduzeća, i smanjuju vreme utrošeno na neefektivne ručne procese, kao i šansu za pojavljivanje ljudskih grešaka tokom procesa. Microsoft Dynamics AX doprinosi povećanju efektivnosti kroz mogućnost korišćenja XML14-a (eXtensible Markup Language) za elektronsku razmenu informacija i obavljanje transakcija sa poslovnim partnerima, bez obzira na sistem koji se koristi. Microsoft Dynamics AX koristi .NET konektor i COM (Component Object Model) da bi se povezala sa drugim aplikacijama, tako da može da koristi informacije i funkcionalnosti drugih .NET i COM orijentisanih aplikacija, poput Microsoft Office. Dynamics AX svojom višejezičkom podrškom omogućava komunikaciju sa kupcima i poslovnim partnerima u njihovom maternjem jeziku (Dynamics AX podržava preko 45 jezika). Ovo znači da preduzeće može da šalje fakture kupcima na njihovom maternjem jeziku, bez obzira koji jezik se koristi. Tu je i podrška za različite valute za dobavljače i kupce u različitim zemljama, kao i automatsko poravnjanje fluktuacija u različitim valutama. Ovo svrstava Axaptu u jedno pravo internacionalno rešenje. 13 označava grupisanje više servera, radi boljeg deljenja opterećenja. 14 standard za elektronsku razmenu dokumenta. ~ 57 ~ 57 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Dynamics AX omogućava velikim preduzećima koja se sastoje od većeg broja preduzeća efikasno poslovanje u realnom vremenu, preko različitih lokacija. Preduzeće može da kreira, ažurira i deli svoje podatke o prodaji i nabavci, kao i finansijske podatke i druge informacije kroz razne lokacije, bez obzira da li su to lokacije preko puta ulice, ili na drugom kraju sveta, i sve to u realnom vremenu. Microsoft Dynamics AX je rešenje koje centralizuje logiku, podatke i alate: Dynamics AX koristi jednu poslovnu logiku, jednu bazu podataka i jedan skup alata. Dynamics AX povezuje preduzeće interno i eksterno, i omogućuje mu da prepozna i iskoristi nove poslovne šanse. Na slici 54 je prikazano kako izgleda Dynamics AX Windows klijent. Na levoj strani je prikazan navigacioni deo, koji u donjem delu sadrži deo za izbor oblasti rada, u srednjem delu prikaz menija sa opcijama u toj oblasti, i u gornjem delu deo za omiljene stavke menija (favorites). Sa desne strane se nalazi radna površina, u kojoj je na slici prikazana forma za pregled prodajnih dokumenata (Sales Order). U gornjem delu forme su zaglavlja svih dokumenata, a u donjem delu su prikazane stavke. Slika 54: Dynamics AX Windows klijent ~ 58 ~ 58 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Dynamics AX poseduje i način za pristup preko Web-a, kroz poslovni portal. Na slici 55 je dat prikaz jednog od mogućih podešavanja poslovnog portala. Slika 55: Enterprise Portal U nastavku ovog rada, će biti prezentovane neke od poslovnih funkcija koje Dynamics AX pokriva. ~ 61 ~ 61 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Preduzeće može da dodeli različiti status svakoj ponudi, što mu omogućava kompletan pregled. Takođe može da analizira celu prodaju u odnosu na budžet, ili specifičnu aktivnost u okviru prihoda koje generiše taj kupac. Primer ovih analiza je dat na slici 57. Slika 57: Prodajna analiza preduzeća 4.2.2 Marketing Dynamics AX, kroz svoje module za marketing, pruža uvid u procese neophodne da bi korisnici kreirali ciljane, personalizovane kampanje, koristeći sve komunikacione kanale. Glavne marketing prednosti Dynamics AX u oblasti marketinga su[50; 51]: Povećanje efektivnosti marketing aktivnosti Lako sakupljanje i korišćenje povratnih informacija od kupaca Merenje profitabilnosti kampanje Dynamics AX čini planiranje, izvršenje i analizu kampanje veoma lakim, tako što stavlja na raspolaganje sve relevatne marketing informacije. Marketing kampanje mogu da se lako organizuju i sprovedu, ali i da se lako prate i analiziraju. ~ 62 ~ 62 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Ključ uspešnog marketinga je davanje informacija koje su potrebne kupcima. Informacije bi trebalo davati na način i u vreme kada su kupcima najpotrebnije. Sa Dynamics AX, utvrđivanje pravih informacija za pravog kupca je jednostavno – Dynamics AX vodi preduzeće kroz svaki korak. Preduzeće može da brzo isplanira i izvrši personalizovanu marketing kampanju, koristeći sve informacije i funkcionalnosti neophodne da bi komuniciralo putem direktne prodaje, call centara, e-maila, faksa, Interneta i mobilnih uređaja. Definisanje i izbor ciljne grupe za kampanju je ujedno najteži i najbitniji korak planiranja marketing kampanje. Dynamics AX omogućava preduzeću segmentaciju ciljne publike u profile, da bi olakšala personalizovanu kampanju usmerenu ka specifičnim potrebama kupaca. Kampanje su hijerarhijski organizovane, ukazujući na odnose između različitih aktivnosti marketinga. Da bi proces učinili što jednostavnijim, jedan zaposleni ima ukupnu odgovornost za svaku kampanju, ali brojni zaposleni mogu da budu raspoređeni na razne zadatke unutar marketing kampanje. Korišćenjem upitnika preduzeće može da uči od mušterija. Kroz Web, moguće je brzo i lako dizajniranje, objavljivanje i obrada upitnika. Internet takođe omogućava bržo i lako davanje odgovora na upitnik. Dynamics AX odgovore sa Interneta snima direktno u bazu podataka, odakle je ta informacija direktno dostupna preduzeću. Kada informacije počnu da pristižu, preduzeće ima kompletan uvid o ciljnoj grupi, i lako može da vidi ko su ispitanici koji su dali odgovore, i koje odgovore su dali. Registracija odgovora je tako dizajnirana da omogućava lako praćenje. Odgovori kupaca mogu da se koriste da bi se dobio uvid u tržište i kreirao rani start u planiranju budućih zahteva tržišta. ~ 63 ~ 63 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Primer pregleda kampanje dat je na slici 58. Slika 58: Pregled marketing kampanje 4.2.3 Upravljanje finansijama Dynamics AX kroz svoje module za upravljanje finansijama pomaže preduzeću da efektivno poveća svoje poslovanje dok održava kontrolu na svojim finansijskim procesima. Glavne prednosti Dynamics AX u upravljanju finansijama su [52]: Pomaže u povećanju poslovanja, bez uvođenja granica Poboljšava efikasnost finansijskih operacija omogućavajući aktivnosti strateškog planiranja Efektivno upravljanje novčanim tokovima Pomaže u osiguravanju pravne ispravnosti poslovanja Omogućava bolji uvid u finansije, a samim tim povećava mogućnost donošenja prave odluke Dynamics AX omogućava brze, pouzdane i sveobuhvatne izveštaje i analize o finansijama i knjigovodstvu. Ona širi odgovarajuće informacije kroz preduzeće, tako da povećava efikasnost knjigovodstvenih procesa preduzeća. ~ 66 ~ 66 Mogućnosti poboljšanja ERP sistema korišćenjem uzora tehnologiji, i dopuštaju višedimenzionalne analize korišćenjem Microsoft SQL Analysis Services. Multidimenzione analize se mogu posmatrati kao višestrana kocka. Svaka strana kocke predstavlja dimenziju koju analizira OLAP server. Dimenzije su različite kategorije poslovnih podataka kao što su vreme, proizvodi, geografske regije i prodajni kanali. Unutar svake kategorije postoji hijerarhija podataka. Na primer, za dimenziju vremena, hijerarhija kategorija bi mogla da uključuje godinu, kvartal, mesec i dan. Na ovaj način Dynamics AX, smanjuje troškove i vreme potrebno za prenos podataka, a smanjuje i mogućnost grešaka, prostim centralizovanjem podataka iz višestrukih izvora u jedan izvor poslovnih informacija i analiza. Preduzeće samo izabere koji izvor podataka želi da koristi kada kreira upit u Axapti, i pokrene analizu. Analize u Dynamics AX podržavaju više jezika i valuta. Kada je analiza gotova, može da se snimi u potrebnom jeziku i valuti. Ove analize su dostupne kada su potrebne. Preduzeće ne mora da čeka IT odeljenje ili sistem administratora da bi napravili specijalne izveštaje. Analiziranje i “kopanje po podacima” (datamining) imaju velike prednosti nad statičnim izveštajima. Dynamics AX omogućuje transformaciju podatka u više dimenzione analize koje podršavaju velike obime i brojne hijerarhije za manipulaciju i izvođenje zaključaka i poslovniih informacija primenom proporcija, kumulativnih zbirova, trendova i alokacije kroz dimenzije i preko hijerarhijskih nivoa podataka. Dynamics AX omogućava dobijanje pouzdanih rezultata, bez obzira na složenost upita. Poslovni podaci koji se koriste tokom analize se konstanto ažuriraju, pošto uključuju promene dok se dešavaju u Dynamics AX i drugim izvorima podatka. Moguće je podesiti ažuriranje podataka svakog dana, nedelje, ili meseca. Nema potrebe za dupliranjem izvora informacija. Na podatke iz analize može da se gleda sa bilo kog nivoa, od visokog pregleda do mikroskopskih detalja. Kada se na primer analizira šablon kupovine, mogu da se vide informacije po grupi kupaca, po specifičnom kupcu, specifičnoj fakturi, ili po bilo kom nivou po izboru korisnika. Stalnim merenjem performansi, moguće je precizno praćenje da li su postignuti poslovni ciljevi i da li poslovne strategije rade efikasno. Dynamics AX pruža transaparentnost kada traži odnose između aktivnosti u različitim odeljenjima, lokacijama i preduzećima. Jedna od glavnih barijera tradicionalne OLAP analize je vreme i analiza neophodni za kreiranje i održavanje aplikacija i podataka. Dynamics AX ima manju ukupnu cenu vlasništva od bilo koje druge analičke aplikacije, zbog toga što koristi ugrađeni menadžer definicija kocki (Cube Definition Manager) koji pojednostavljuje proces kreiranja i održavanja kocki. ~ 67 ~ 67 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Sa tradicionalnim OLAP proizvodima, proces preslikavanja informacija između ERP poslovnih podataka i OLAP kocke je bio često mukotrpan i dug, zato što su informacije morale da se preslikavaju između dva različita sistema. Ali sa Dynamics AX, funkcionalnost OLAP-a i ERP podaci, su deo istog sistema. Preduzeće više ne mora da troši puno resursa integrisanjem neki trećih softverskih inteligentnih sistema, koje mora da se reintegriše svaki put kada unapredi svoje ERP rešenje. Dynamics AX poslovne analize zahtevaju samo Dynamics AX i Microsoft SQL Analysis Services, ali ne nijedan treći analitički alat. Sva preslikavanja se dešavaju direktno unutar Dynamics AX, omogućavajući maksimum vrednosti poslovnih informacije i donošenje najbolje odluke na pravi način i u pravo vreme. Pored toga, podaci iz poslovnih analiza Dynamics AX, se mogu lako preneti u Microsoft Excel. Primer poslovnih analiza je dat na slici 60. Slika 60: Poslovne analize ~ 68 ~ 68 Mogućnosti poboljšanja ERP sistema korišćenjem uzora 4.3 Tehničko/tehnološki opis Na slici 61 je prikazan konceptualni dijagram ovog dela, gde su dati neki od elemenata koji odlikuju tehničko tehnološki aspekt Dynamics AX ERP sistema. Dynamics AX Velika produktivnost programera Razvoj modela aplikacije Kroz Elemenata modela Prezentacije Poslovne logike Podataka Definisanjem/Izmenom X++ (programski jezik) Objektno orijentisani MorphX (razvojno okruţenje) AOT (Application Object Tree) Predstavlja katalog svih Sistem za upravljanje bazom podataka Microsoft SQL Server Oracle Komunikacione tehnologije RPC (Remote Procedure Call) Microsoft ASP.NET Web Services Tronivojska aplikacija Klijentski nivo Objektni server i aplikativne datoteke Sistem za upravljanje bazom podataka Windows klijent Web klijent “Tanki” “Debeli” Funkcionalne celine Kernel Poslovna aplikacija 1.2 miliona linija Meta model baze podataka Aplikativne slojeve Slika 61: Konceptualni dijagram tehničko tehnološkog opisa Dynamics AX Dynamics AX je napravljena tako da se lako podešava, i da su moguća velika podešavanja i proširenja. Razvojno okruženje i tehnologija slojeva koja će biti objašnjena u nastavku, daju Axapti mnogo prednosti u domenu podešavanja i lake izrade dodatnih funkcionalnosti. Iako slojevita arhitektura Dynamics AX omogućuje veoma lake dorade, ovo može da bude veoma dugotrajan proces. Kao i sa ostalim ERP rešenjima, Axapta se najbolje pokazuje u organizacijama koje imaju relativno uniformne procese i ne koriste opsežne dorade [42 str. 4]. Dynamics AX omogućava veliku produktivnost programera tako što svoju metodologiju razvoja softvera bazira na razvoju modela aplikacije , umesto na programiranju specifičnosti aplikacije. Da su programeri bili u fokusu za Dynamics AX proizvodni tim, navedeno je i u [43 str. xvii]: “Mi smo pre svega uvideli kako programeri vole da rade sa Microsoft Dynamics AX 4.0. Mi volimo Dynamics AX, i naši partneri vole njegov moćan skup razvojnih alata, koji omogućuju adaptibilan tok implementacije ERP sistema, koji je najbolji. Neki od primera koje ćete videti u ovoj knjizi mogu da se završe za manje od 10 minuta (kao što je kreiranje i izlaganje skupova podataka, spoljnoj aplikaciji kroz Web servis). Za iste primere u drugim ERP sistemima bi trebalo najmanje nedelju dana.” ~ 71 ~ 71 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Na slici 63 [54] je prikazan jedan scenario postavke Dynamics AX ERP rešenja sa fokusom na tehnologije povezivanja i serversku infrastrukturu. Slika 63: Scenario postavke Dynamics AX Dynamics AX koristi RPC (Remote Procedure Call) i Microsoft ASP.NET Web Services kao komunikacione tehnologije. Puni Dynamics AX klijenti komuniciraju sa AOS-om preko Microsoft RPC tehnologije. Microsoft SQL Server klijent za izveštavanje komunicira direktno sa Microsoft SQL Server servisima za izveštavanje preko Web servisa. Aplikativni serveri baze podataka ažuriraju baze podataka za SQL Server analitičke servise (SQL Server Analysis Services). SQL Server servisi za izveštavanje (SQL Server Reporting Services) čitaju podatke iz baze podataka aplikacije. Dynamics AX Enterprise Portal omogućava pristup klijentima pomoću Web browsera, i tipično koristi jedan ili više skaliranih servera koji uslužuju Microsoft Internet Information Services (IIS), Microsoft Office SharePoint Portal Server, i Microsoft SharePoint Services. Portal komunicira sa Dynamics AX putem Web servisa i preko Dynamics AX Business konektora koji komunicira sa aplikativnim serverima korišćenjem Microsoft RPC tehnologije. Dynamics AX koristi Application Integration Framework (AIF) da bi razmenjivao informacije sa Microsoft BizTalk serverom, MSMQ (MicroSoft Message Queuing) i datotečnim sistemom. AIF takođe uslužuje Web servise koji odgovaraju na zahteve za podacima iz spoljnih aplikacija. Dynamics AX može da razmenjuje podatke sa Microsoft Component Object Model (COM) komponentama i Microsoft.NET komponentama preko COM i CLR (Common Language Runtime) tehnologija razmene podataka. ~ 72 ~ 72 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Microsoft Office klijenti mogu da razmenjuju podatke direktno sa AOS-om preko Dynamics AX Business konektora, a Dynamics AX aplikativni serveri imaju ugrađenu podršku za razmenu podataka sa Microsoft Exchange serverom. Slika 64: Arhitektura Dynamics AX sistema Na slici 64 [55] je dat drugačiji prikaz arhitekture Dynamics AX sistema. Dynamics AX je tronivojski proizvod koji implementira dobro poznatu MVC (Model-View -Controller) arhitekturu. Zajedno se ova tri nivoa sastoje od [42 str. 5]: Relacione baze podataka za perzistenciju podataka. Podržani su Microsoft SQL Server i Oracle sistem za upravljanje relacionim bazama podataka, jedan server ili klaster. Ovo je deo sloja za pristup podacima. Axapta aplikativne datoteke se čuvaju kroz X++ programski kod i među- binarni kod, kao i metapodatke. Ovo čini aplikaciju ili aplikativni server, i deo je sloja za pristup podacima ili sloja poslovne logike. Objektni server gde se poslovna logika izvršava. Ovo zahteva instalaciju jednog AOS-a ili klastera AOS-a. Ovaj sloj u većini slučajeva učitava i izvršava aplikaciju iz prethodne stavke. Klijentski nivo gde se nalazi i izvršava korisnički interfejs. Ovo može da bude standardni Dynamics AX Windows klijent, Web browser klijent, ili bilo koji posebno razvijeni klijent koji koristi neke od tehnologija razmene podataka koje su opisane u nastavku. Prilikom programiranja u X++, moguće je odrediti da li se kod izvršava na serveru ili klijentu. Ovo je moguće na nivou cele klase, ili na nivou metoda (moguće samo ~ 73 ~ 73 Mogućnosti poboljšanja ERP sistema korišćenjem uzora za statičke metode). Kada klasa ima puno interakcije sa nekim drugim klijentskim aplikacijama (npr. Microsoft Office) moguće je postići bolje performanse izvršavanjem na klijentu. Kada za klasu/metodu mesto izvršenja nije definisano, izvršava se na mestu odakle je pozvana. Dvonivojski klijent je režim gde su klijent i slojevi aplikativnog servera spojeni, eliminišući AOS. To je lakša varijanta za postavku, i obično se koristi za početnu instalaciju i konfiguraciju. Slika 65: Arhitektura kernela Axapta sadrži dve različite funkcionalne celine: kernel (tehnološke osnove), i aplikaciju (poslovna logika i prezentacija). Kernel je napisan u C++ (iako sadrži delove napisane u X++ programskom jeziku) i isporučuje se kao kolekcija Intel x86 mašinskih binarnih datoteka. Aplikacija je napisana u X++ programskom jeziku i isporučuje se u izvornom obliku i formi među-binarnog koda (intermediate binary code form). Pošto korisnici dobijaju sav X++ izvorni kod, Dynamics AX im omogućuje da promene bilo šta u aplikaciji. Ovo im stavlja oko 1.2 miliona linija izvornog koda na dohvat prstiju, tako da lako mogu da to koriste i uče. Aplikacija sadrži definicije svih tipova objekata, poput formi i izveštaja (metapodaci). Metapodaci se ne kompajliraju u mašinske binarne datoteke, već se umesto toga čuvaju u izvornom obliku i formi među-binarnog koda i koriste u vreme izvršenja za sastavljanje i izvođenje odgovarajućih instanci objekata [42 str. 4]. Arhitektura kernela je prikazana na slici 65 [55]. ~ 76 ~ 76 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Elementi AOT koji predstavljaju metode, sadrže X++ izvorni kod. Ovaj kod može da se ispita i modifikuje korišćenjem X++ editora. Pomoću ovih alata, moguće je videti strukturu elemenata modela (npr. forme) u AOT, atribute svakog njegovog dela (kontrole20 u slučaju forme), i implementaciju obrade događaja (pomoću X++ editora). MorphX okruženje može da bude povezano sa sistemom za kontrolu verzija, kao što su Visual SourceSafe ili Source Depot. Moguće je definisati polise za proces upisivanja izmena u sistem za kontrolu verzija, tako da se kod koji ne zadovoljava odgovarajuće standarde kvaliteta, ne prihvati u projekat. Ovi alati prikazuju detalje implementacije samo na nivou elementa. Dodatni alati kao što je alat za prikaz referenci (Cross-Reference), alat za pretraživanje (Find) i alat za reverzibilni inžinjering (Reverse Engineering) mogu da prikažu odnose između elemenata. Alat za prikaz referenci prikazuje gde se neki specifični element koristi, kao i koje elemente dati element koristi. Moguće je videti gde se prikazuju polja iz tabele, gde se incijalizuju, učitavaju, menjaju itd. Pomoću alata za pretraživanje moguće je pretraživati ceo AOT, ili samo određene delove. Moguće je pretraživati na osnovu naziva, dela teksta, vremena i drugih atributa, ali je moguće i povezivanje sa složenijim upitima korišćenjem X++ koda. Pomoću alata za reverzibilni inžinjering moguće je podići nivo apstrakcije. Ovaj alat generiše Microsoft Visio UML modele (moguće je generisati UML model podataka ili UML model objekata). Pored toga MorphX podržava automatsko testiranje sa mogućnošću ispitivanja pokrivenosti koda testom (Code Coverage). 20 Kontrole predstavljaju elemente korisničkog interfejsa sa kojima korisnik ima interakciju, poput polja za tekst, dugmića, itd. Slika 68: Dizajner atributa ~ 77 ~ 77 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Prilikom razvoja moguće je koristiti projekte, kao način za grupisanje povezanih elemenata. Ovo je posebno korisno zbog velikog broja elemenata u AOT. Projekat predstavlja suženi pogled u AOT, i omogućava korisnicima da se fokusiraju na elemente sa kojima rade. Moguće je elemente ručno dodavati u projekat, prostim prevlačenjem, ili definisati filtere i dodati elemente na osnovu tipa i/ili naziva. Unutar projekta moguće je definisati grupe elemenata na osnovu predefinisanih tipova, ili definisati svoje grupe. Projekti mogu da budu privatni (vidi ih samo njihov stvaralac) ili zajednički (vide ih svi programeri). MorphX sadrži i editor formi i editor izveštaja. Ovi editori omogućavaju projektovanje formi i izveštaja u stilu „kako vidiš, tako će i izgledati“ (WYSIWYG, What You See Is What You Get). Za razvoj višejezičkih funkcionalnosti koristi se editor labela. Labele predstavljaju lokalizovane tekstualne elemente. Za skoro svaki element modela je moguće direktno ukucati opis, ili ga povezati sa odgovarajućom labelom. Ukoliko se prilikom izvršenja koristi jezik za koji postoji vrednost labele za prikaz datog elementa, onda će se ta vrednost koristi za opis. Kao i većina razvojnih okruženja današnjice, i MorphX sadrži debuger. Debuger je poseban program koji sa klijentom komunicira korišćenjem socketa i sopstvenog protokola [56]. Operativni elementi modela se koriste za modeliranje ponašanja aplikacije u skladu sa bezbednošću, konfiguracijom i licencama u operativnom okruženju. Neke funkcionalnosti su dostupne, samo ako su uključene na nivou celog sistema, i ako je korisnik autorizovan za njihovo korišćenje. Operativni elementi modela su: bezbednosni ključevi, konfiguracioni ključevi, i licencni kodovi. MorphX razvojno okruženje sinhronizuje tabele i elemente pogleda (view) sa šemom baze podataka samo ako ovi elementi nemaju konfiguracione ključeve, ili su povezani sa aktivnim konfiguracionim ključevima. Dynamics AX uključuje sve aplikativne module koje je razvio Microsoft. Ovi modulu su zaključani odgovarajućim licencnim kodovima, i moraju da se otključaju odgovarajućim licencama. Kada je neki modul otključan, onda je moguće finije podesiti dostupnost funkcionalnosti pomoću konfiguracionih ključeva. Bezbednosni ključevi su deo Dynamics AX bezbedonosnog okruženja zasnovanog na ulogama. Kada se korisnik prijavljuje u Dynamics AX, prvo ga Microsoft Windows platforma autentikuje, pa se nakon uspešne autentikacije on povezuje sa odgovarajućom korisničkom grupom, koja predstavlja njegovu ulogu u okviru aplikacije. Uloga takođe utiče na skup dostupnih akcija korisnika. Bezbednosne ključeve je moguće povezati sa svim elementima modela, tako da slični elementi čine bezbedonosnu grupu. Bezbednosni ključevi se povezuju sa korisničkim grupama (user groups), tako da je za svaku grupu moguće definisati skup akcija nad određenim ključem. Moguće akcije su: bez pristupa, pregled, izmena, kreiranje, i puna kontrola. ~ 78 ~ 78 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Pored ovih elemenata, AOT sadrži elemente za: Tabele (Tables) – koje sadrže objekte koji se preslikavaju u tabele u shemi baze podataka. Tabele sadrže polja, a mogu da sadrže i ključeve, indekse, relacije, grupe polja21, akcije za brisanje, kao i metode. Prilikom programiranja u X++, tabela se ponaša kao klasa. Jedno pojavljivanje tabele se tretira kao objekat koji predstavlja jedan red te tabele. Vrednostima kolona moguće je pristupiti kao atributima, i moguće je pozvati metode tabele. MorphX sinhronizuje meta-model podataka sa definicijama u shemi baze podataka, i na taj način omogućava Dynamics AX da radi i sa Microsoft SQL serverom i sa Oracle-om kao bazama podataka. Polja tabele mogu da budu nekog od osnovnih tipova podataka, a mogu da koriste i proširene tipove podataka koji se takođe definišu unutar AOT. MorphX vrši automatsku konverziju između odgovarajućih vrednosti X++ tipova podataka i odgovarajućih tipova podataka u bazi podataka (npr. ukoliko je string u X++ kodu definisan sa dužinom 20 znakova, ova vrednost može da se sačuva u polju tipa VARCHAR dužine 20 znakova). X++ koristi pod-elemente tabela da bi pružio IntelliSense22 podršku dok se programiraju iskazi koji operišu nad tabelama. Dynamics AX u verziji 4.0 ima preko 1800 tabela. Upite (Queries) – definišu strukturu upita nad bazom podataka i mogu da se izvrše iz X++ iskaza. Moguće je dodavati tabele u upite i definisati kako se spajaju. Takođe je omogućena podrška za sortiranje, grupisanje i ograničenja. Poglede (Views) – ovi elementi sadrže poglede nad bazom podataka, i oni se sinhronizuju sa bazom podataka. Pogledi uključuju upit koji filtrira podatke u tabeli, ili podatke iz više spojenih tabela . Pogledi mogu da uključuju preslikavanje za polja tabele, kao i sopstvene grupe polja i metode. Mape (Maps) – ovi elementi ne definišu elemente baze podataka, tako da se ne sihronizuju sa aplikativnom bazom podataka. Oni definišu X++ programske elemente koji obmotavaju objekte tabela za vreme izvršavanja. Mape povezuju polja i metode koje se često koriste za tabele koje nisu u trećoj normalnoj formi. Kolekcije tabela (Table Collections) – definišu grupe tabela koje mogu da se dele između dve ili više kompanija u Dynamics AX, kada se dele virtuelni kompanijski nalozi23. Perspektive (Perspectives) – definišu kolekcije tabela koje se koriste za projektovanje i generisanje izveštaja korišćenjem Microsoft SQL Server Reporting servisa. 21 Grupe polja omogućavaju grupisanje koje se koristi za kreiranje vizuelne grupe podataka na formama, ali i kreiranje automatskih izveštaja. 22 Podrška prilikom programiranja, koja omogućava automatsko prikazivanje članova objekta, tabele i sličnih elemenata, čime umnogome olakšava programiranje. 23 Ovo je situacija ukoliko neke tabele želimo da delimo između više preduzeća koja koriste iste instalaciju Dynamics AX. Tipičan primer su razni šifarnici koji su zajednički za sva preduzeća. ~ 81 ~ 81 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Analiza korišćenja elemenata Dynamics AX ERP sistema po tipu je data u tabeli 1524: Broj objekata Tip Broj objekata Tip 5089 Klasa 2236 Tabela 66702 Metoda instance klase 10096 Metoda instance tabele 8128 Statičkih metoda klase 6085 Statičkih metoda tabele 1515 Enumeratora 24348 Polja tabele 5442 Proširenih tipova podataka 10275 Grupa polja tabele 82 Licencnih kodova 3106 Indeksa tabele 201 Konfiguracionih ključeva 306 Mapa tabela 273 Bezbedosnih ključeva 2524 Relacija tabele 2089 Formi 4 Kolekcija tabela 4 Help datoteka 388 Web stavki menija 146 Macroa 224 Web formi 30 Menija 19 Weblet-a 3748 Stavki menija 157 Web menija 2 Perspektiva 5 Web izveštaja 62 Projekata 825 Izveštaja 369 Upita 253 Resursa 4 Referenci 20 Pogleda Tabela 15: Analiza korišćenja elemenata Dynamics AX ERP sistema po tipu Prilikom rada sa AOT, često redosled elemenata unutar nekog hijerahijski višeg elementa može da ima značaja (npr. redosled tekstualnih polja u tabeli na formi), tako da AOT omogućava i veoma lako podešavanje redosleda. Svaki od elemenata iz AOT u zavisnosti od svog tipa prikazuje odgovarajući kontekstualni meni (aktivira se pritiskom na desni taster miša nad datim elementom). Dynamics AX omogućava programerima da ovaj meni izmene i prošire modifikacijom i implementiranjem odgovarajućih metoda klase koja obrađuje događaje kontekstualnog menija AOT. MorphX sadrži i alat za pregled podataka u tabeli (Table browser) koji omogućava pregled i izmenu podataka u tabeli. Moguće je raditi nad svim podacima u tabeli, ili filtrirati podatke nad kojima se radi. Ovaj alat je takođe implementiran kao klasa u Dynamics AX, tako da je i njegova izmena moguća. 24 Analiza korišćenja elemenata Dynamics AX ERP sistema po tipu, predstalja doprinos manjeg važnosti (DOP-AOT) ove magistarske teze. ~ 82 ~ 82 Mogućnosti poboljšanja ERP sistema korišćenjem uzora 4.3.2 Aplikativni slojevi Dynamics AX Slojevitost aplikacije Dynamics AX je arhitekturalni princip koji omogućava podešavanje i proširenje definicija elemenata modela na veoma finom nivou. Iz definicija elemenata modela, ovo se prenosi na strukturu i ponašanje . Kada se objavi verzija aplikacije koja nije specifična za određenu zemlju ili regiju, svi elementi modela koji definišu aplikaciju se nalaze na najnižim slojevima. Izvršno okruženje ne koristi samo ove elemente kada instancira objekte aplikacije. Tačnije, izvršno okruženje sastavlja definiciju elementa iz elemenata na svim slojevima. Elementi definisani na višim nivoima, nadjačavaju elemente definisani na nižim slojevima. Objekat koji izvršno okruženje instancira je prema tome, pojavljivanje dinamičke definicije tipa sastavljene od elemenata modela sa više slojeva. Elementi modela se čuvaju u posebnim datotekama na svakom sloju. Definicije elemenata se čitaju iz ovih datoteka i dinamički sastavljaju od strane Dynamics AX izvršnog okruženja. Instance objekata se kreiraju na serveru ili klijentu u zavisnosti od definicije elementa. Sloj Opis Opseg identifikatora USR – User Individualna kompanija, ili kompanije unutar preduzeća mogu da koriste ovaj sloj za izmene specifične za korisničku instalaciju. 50001 – 60000 CUS – Customer Kompanije i poslovni partneri mogu da modifikuju svoje instalacije i dodaju generičke kompanijski specifične modifikacije u ovom sloju. Ovaj sloj je uključen zbog podrške potreba za razvojem unutar same kompanije kao krajnjeg korisnika, bez izlaganja opasnosti modifikacija koje je učinio poslovni partner. 40001 – 50000 VAR – Value-added reseller Poslovni partneri koriste ovaj sloj, koji nema poslovna ograničenja, da bi distribuirali sve što su razvili za svoje kupce. 30001 – 40000 BUS – Business solution Poslovni partneri razvijaju i distribuiraju vertikalna i horizontalna rešenja za druge partnere i kupce. Rešenja u ovom sloju mogu da se zaštite licencnim ključevima sa potpisanim ugovorom za Dynamics AX Add-On Solutions program. 20001 – 30000 LOS – Local solution Dynamics AX kancelarije sertifikuju i distribuiraju strateška lokalna rešenja kroz ovaj sloj. 18001 – 20000 DIS – Distributor Dynamics AX inženjerski tim za podršku isporučuje kritične ispravke koristeći ovaj sloj. 16001 – 18000 GLS – Global solution Dynamics AX tim za globalni razvoj i lokalizaciju pruža razne GLS slojeve koji sadrže funkcionalnosti specifične za određene zemlje za regije u kojima je Dynamics AX pušten u promet. 8001 – 16000 SYS – System Ovo je najniži sloj elemenata modela i lokacija standardne Dynamics AX aplikacije. Samo Microsoft ima pristup definicijama elemenata na ovom sloju. 1 – 8000 Tabela 16: Opisi slojeva ~ 83 ~ 83 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Na tabeli 16 [43 str. 15] je prikazano da je najniži sloj sistemski sloj (SYS), a najviši sloj, korisnički sloj (USR). Za Dynamics AX korisnik može da podesi u sloj u kome želi da radi. Ukoliko izabere neki od slojeva koji mu nisu dostupni, radni sloj će biti podešen na najniži dostupni sloj. Kada se izmeni element modela na sloju koji je niži od radnog sloja, njegova definicija se kopira na radni sloj, i ona se koristi prilikom izvršavanja. Ovaj princip se zove zaklanjanje (overlayering). Ukoliko se obriše element modela iz radnog sloja, koristiće se njegova definicija sa nižeg sloja. Svaki od slojeva, sadrži i dodatni sloj zakrpa (patch). Ovaj sloj služi za zakrpe, manja ažuriranja, servisne pakete25 (service pack), i hitne ispravke (hotfix). Logički, sloj zakrpe se nalazi iznad sloja čija je zakrpa (svaki od osnovnih slojeva može da ima sloj zakrpe). Većina elemenata modela poseduje jedinstveni identifikator koji je predstavljen brojem od 16 bitova bez predznaka. Da bi se izbegli konflikti, svaki sloj ima opseg dostupnih identifikatora. U poslovnim podacima, ovi identifikatori se uglavnom koriste za modeliranje polimorfnih odnosa. U definicijama elemenata, oni se koriste kao reference između elemenata i za relacije između klasa i članova tabela preko slojeva. Ukoliko neki element AOT postoji u više slojeva, moguće je pogledati njegovu definiciju u svim slojevima gde se pojavljuje, ili koristiti alat za poređenje (Compare) koji omogućava poređenje različitih verzija elemenata (sa različitih slojeva, ali i različitih verzija ukoliko se koristi sistem za kontrolu verzija). Alat za poređenje automatski označava razlike između različitih varijanti elementa. Ovaj alat može da se iskoristi i da se uporede dva različita elementa, npr. dve različite klase. Moguće je ovaj alat aktivirati iz X++ koda i izvršiti poređenje dva proizvoljna tekstualna niza. 25 Servisni paketi su dopuna na trenutnu glavnu verziju aplikacije. Obično označavaju drugi broj u verziji aplikacije (npr. Dynamics AX 4, SP 1). ~ 86 ~ 86 Mogućnosti poboljšanja ERP sistema korišćenjem uzora 4.3.4 X++ X++ je objektno orijentisani programski jezik koji se koristi unutar Microsoft Dynamics AX. X++ podržava polimorfizam i učaurenje (encapsulation). Za X++ može da se kaže da je svestan aplikacije (application-aware), zato što podržava određivanje mesta izvršenja (klijent/server) na nivou klase ili metode, podržava izmenu kompanije u kojoj se kod izvršava (korisno kod preduzeća koje imaju više kompanija), kao i metode koje vraćaju podatke iz koda a koriste se za zamenu vrednosti polja u tabeli. Ovo su funkcionalnosti koje su korisne za pisanje klijent/server ERP aplikacija. Pored toga moguće je reći da je X++ jezik svestan podataka (data-aware) zato što sadrži dodatne načine upravljanja izvršenjem upita, kao i sintaksu za pisanje upita. Ovo su funkcionalnosti koje su korisne za programiranje aplikacija koje rade sa bazom podataka. [43 str. 91] Programski jezik X++ sadrži osnovne vrednosne tipove podatka poput: boolean, int, int64, real, date, timeofday, str i guid. Pored toga, tu su enumeratori i prošireni tipovi podataka. X++ referentni tipovi uključuju slogove (record), klase i interfejse. Slogovni tipovi su tabele, mape i pogledi. Dynamics AX vrši automatsku dealokaciju memorije (garbage collection) za objekte referentnog tipa, kada izađu izvan opsega i nema više referenci na njih. Za referentne tipove slogova nije potrebno explicitno instanciranje, pošto to radi izvršno okruženje. X++ sistem tipova je poznat kao slabo tipizirani, zato što X++ programski jezik dozvoljava neke operacije dodeljivanja tipova koje su očigledno pogrešne i izazvaće greške prilikom izvršenja [43 str. 94]. Programski jezik X++ koristi vitičaste zagrade („{“ i „}“) za označavanje sintaksnih blokova (poput C, C++, C# i Jave). Za razliku od ovih jezika, X++ nije osetljiv na velika i mala slova (case-sensitive). Definicije promenjivih moraju da se smeste na početak metoda za razliku od C# i Jave. X++ kompajler je jedno prolazni (one pass) LALR(1) kompajler i parsira na gore (bottom up). On generiše P kod u obrnutoj Poljskoj notaciji26. [56] X++ sadrži iskaze koji omogućavaju interoperabilnost (interoperability) sa Microsoft .NET CLR sklopovima i Microsoft COM komponentama. Interoperabilnost sa obe tehnologije se postiže obmotavanjem (wrapping) spoljnih objekata u Dynamics AX objekte i preusmeravanje poziva metoda iz Dynamics AX objekata u obmotane objekte. Programski jezik X++ ne podržava preklapanje metoda, ali podržava podrazumevane vrednosti parametara metoda. Moguće je deklarisati da podrazumevana vrednost određenog parametra uzima vrednost neke druge promenjive dostupne na nivou klase. 26 Obrnuta Poljska notacija je analogija prefiksne Poljske notacije. Poznata je i kao postfixna notacija. ~ 87 ~ 87 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Klase se u Dynamics AX kreiraju kroz AOT, kreiranjem metoda. Postoji specijalna metoda koja označava definiciju klase. Sav X++ programski kod se piše pomoću X++ editora. Editor sadrži dva dela. Levi prikazuje dostupne metode, a desni prikazuje X++ programski kod izabrane metode. Slika 71: X++ editor X++ editor je tekstualni editor koji podržava automatsko bojenje ključnih reči i IntelliSense. X++ editor je prikazan na slici 71, u trenutku kada se aktivirala IntelliSense podrška. X++ editor sadrži skup šablona za generisanje/izmenu koda. Ovo su šabloni poput: slanja na email, snimanja u datoteku, automatskog pretvaranja u komentare, automatskog uklanjanja komentara, generisanje predefinisanih komentara, generisanje koda za česte programske konstrukcije (ciklične strukture, metode za podršku enkapsulacije, itd.). Šablone koje podržava X++ editor, programer može da promeni/proširi izmenom odgovarajuće klase koja obrađuje događaje aktiviranja ove opcije. Nakon kreiranja ili izmene nekog koda u X++ programskom jeziku, potrebno je taj kod kompajlirati. Kompajler generiše bajtkod iz izvornog koda i prikazuje sintaksne greške ukoliko postoje. Kada se neki X++ kod izmeni u Dynamics AX, kompajler kompajlira samo onaj deo koda koji je izmenjen. Ovo iz razloga što se među-binarni kod koji generiše kompajler, čuva zajedno sa X++ kodom i metapodacima. ~ 88 ~ 88 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Prilikom kompajliranja kompajler pokreće i alat za proveru najboljih programerskih praksi (Best Practices) , koji proverava da li je data implementacija u X++ programskom jeziku i definicije elemenata u skladu sa Microsoftovim smernicama za razvoj unutar Dynamics AX. Na ovaj način je moguće odmah otkriti neke od grešaka u programiranju. Samo pridržavanje ovih smernica ne garantuje uspeh projekta, ali smanjuje mogućnost neuspeha. Alat za proveru najboljih programerskih praksi proverava oko 300 pravila [43 str. 59], a programeri mogu da izmene/prošire ovaj skup pravila izmenom odgovarajuće klase u Dynamics AX. Jedna od klasa koja se najviše koristi kao osnova u svakodnevnom radu je RunBase. Nasleđivanjem ove klase programer može lako da implementira dodatne poslovne operacije. Ova klasa omogućava: korišćenje dijaloga za unos vrednosti prikaz prozora za filtriranje podataka iz tabela (query window) validaciju unetih vrednosti prikaz trenutnog statusa izvršenja (progress bar) određivanje mesta izvršenja u klijent/server kontekstu perzistenciju poslednjih vrednosti objekata koje je korisnik koristio prilikom pokretanja i njihovo automatsko ponovno kreiranje i dodeljivanje poslednjih vrednosti, prilikom ponovnog pokretanja klase (pack/unpack) Pored toga, proširena verzija ove klase, RunBaseBatch, omogućava odloženo i izvršavanje po zadatoj dinamici. ~ 91 ~ 91 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Različite metode životnog ciklusa softvera koriste različite modele životnog ciklusa softvera. Model životnog ciklusa iterativno/inkrementalnog razvoja (IID, Iterative and Incremental Development) se koristi u jedinstvenom procesu razvoja softvera (Unified Software Development Process), Scrum-u, ekstremnom programiranju (XP, eXtreme Programming), evolucionarnom upravljanju projektima (EVO, EVOlutionary Project Management) i u metodi životnog ciklusa softvera koju je Craig Larman opisao u [13]. Za metode životnog ciklusa softvera može da se kaže da opisuju proces razvoja softvera, kroz njegove pojedinačne aktivnosti, ili procese (npr. prikupljanje zahteva, analiza, projektovanje, itd.). Pored modela, veliki uticaj na životni ciklus softvera imaju strateški pristupi ovom procesu, tj. strategije životnog ciklusa softvera. Neke od strategija životnog ciklusa softvera su: upravljanje prema slučajevima-korišćenja (use-case driven) i orijentacija ka arhitekturi (architecture centric). a) use-case driven Slučaj korišćenja (SK) je deo funkcionalnosti sistema koji korisniku daje neki rezultat (vrednost). To znači da SK opisuju funkcionalne zahteve. Svi SK zajedno čine model SK koji opisuje kompletnu funkcionalnost sistema. Model SK odgovara kod specifikacije sistema na sledeće pitanje: Šta sistem treba da radi za svakog korisnika. za razliku od tradicionalne funkcionalne specifikacije koja je odgovarala na pitanje: Šta sistem treba da radi? To znači da su potrebe korisnika u osnovi specifikacije sistema. SK istovremeno iniciraju i povezuju kompletan proces razvoja softverskog sistema. To znači da se pomoću SK upravlja analizom, projektovanjem, implementacijom i testiranjem softevrskog proizvoda. Slučajevi korišćenja (SK) se razvijaju zajedno sa sistemskom arhitekturom. SK upravljaju sistemskom arhitekturom dok sistemska arhitektura utiče na selekciju SK. b) architecture-centric 27 Arhitektura softverskog sistema(ASS) obuhvata najvažnije statičke i dinamičke aspekte sistema. ASS pored toga obuhvata: platformu na kojoj se izvršava softver (kompjuterska arhitektura, operativni sistem, DBMS, protokoli za mrežnu komunikaciju), raspoložive komponente koje se mogu ponovo koristiti(npr: okvir za grafički korisnički interfejs), sistem nasleđa (legacy system), nefunkcionalne zahteve (performanse, prenosivost,...). 27 U kontekstu životnog ciklusa softvera, znači da se sistemska arhitektura u toku razvoja softvera koristi kao glavni artifakt za konceptualizaciju, konstrukciju, upravljanje i razrađivanje sistema. ~ 92 ~ 92 Mogućnosti poboljšanja ERP sistema korišćenjem uzora Veza između SK i arhitekture se može objasniti na sledeći način: Svaki proizvod ima funkciju i oblik(form) koji moraju biti između sebe povezani. Funkcija korespondira sa SK, dok oblik korespondira sa arhitekturom. SK moraju, kada se realizuju, da se ugrade u arhitekturu. Arhitektura mora da obezbedi prostor da se u nju ugrade svi sadašnji a po mogućnosti i budući SK. Arhitektura i SK moraju da se razvijaju paralelno. Kod razvoja arhitekture prvo se kreira onaj deo arhitekture (platforma) koji je nezavisan od SK. Zatim se arhitektura razvija zajedno sa SK koji predstavljaju ključne funkcije razmatranog sistema. 5.1 Aktivnosti procesa životnog ciklusa softvera Proces razvoja softvera obuhvata 5 faza [8]: specifikacija zahteva, analiza, projektovanje, implementacija, testiranje. 5.1.1 Prikupljanje korisničkih zahteva Pod specifikacijom zahteva se podrazumeva opis potreba ili želja koje softverski proizvod treba da omogući. Radi razumevanja tih zahteva neophodno je [8]: verbalno opisati zahtev navesti korisnike postavljenih zahteva definisati ciljeve koje mora da zadovolji softverski proizvod (brza identifikacija kupca, automatsko praćenje skladišta, brza i tačna obrada računa,…) identifikovati (u smislu šta one rade ) i kategorizovati (očigledne, sakrivene i opcione) sistemske funkcije identifikovati i kategorizovati sistemske atribute i povezati ih sa navedenim sistemskim funkcijama Na bazi korisničkih zahteva prave se slučajevi korišćenja u tekstualnom obliku, a zatim se na osnovu toga crtaju dijagrami slučajeva korišćenja. 5.1.2 Analiza Na osnovu specifikacije korisničkih zahteva pravi se model analize na sledeći način [8]: 1. Iz tekstualnih slučajeva korišćenja se uočavaju koncepti, koji se zatim međusobno povezuju formirajući konceptualni model. 2. Na osnovu konceptualnog modela pravi se rečnik podataka. 3. Za svaki slučaj korišćenja pravi se sekvencni dijagram sistema. 4. Sekvencni dijagrami sastoje se iz sistemskih operacija za koje se prave ugovori (obaveze ili odgovornosti objekata da obezbede neko ponašanje). U definisanju ugovora koristi se i konceptulani model. 5. Prema potrebi, prave se dijagrami prelaza stanja na osnovu slučajeva korišćenja, konceptualnog modela i sekvencnih dijagrama. Ovim se završava faza analize ~ 93 ~ 93 Mogućnosti poboljšanja ERP sistema korišćenjem uzora 5.1.3 Projektovanje Projektovanje je u [59] definisano kao „proces definisanja arhitekture, komponeneti, interfejsa, i ostalih karakteristika sistema ili komponente“ i „kao rezultat tog procesa“. Gledano kao proces, projektovanje softvera (software design) je aktivnost inžinjerskog životnog ciklusa softvera, u kojoj se analiziraju korisničkih zahtevi da bi se dobio opis interne strukture softvera koja će služiti kao osnova za njegovu konstrukciju. Preciznije rečeno, rezultat projektovanja softvera mora da opiše softversku arhitekturu – tj. kako je softver rastavljen i organizovan u komponenete – i da opiše interfejse između ovih komponenti. On mora da opiše i komponenete na nivou detalja koji omogućava njihovu kontruksciju. [7 str. 3-1] U [9] je definisano da se projektovanje softvera sastoji iz dve aktivnosti koje se nalaze između analize korisničkih zahteva i konstrukcije softvera: Arhitekturalno projektovanje softvera (poznato i kao “projektovanje na vrhu” (toplevel design) ili makro arhitektura): opisuje najvišu strukturu i organizaciju i identifikuje različite komponente Detaljno projektovanje softvera (poznato i kao mikro arhitektura): dovoljno opisuje svaku komponentu da bi bilo moguće da se ona konstruiše Prilikom projektovanja za beleženje glavne projektantske odluke koje su donešene koriste se različite notacije i jezici [7 str. 3-4]. Jedna od podela notacija je na one koje opisuju strukturni, tj. statični pogled, nasuprot onima koje opisuju ponašanje, tj. dinamični pogled [7 str. 3-4]. UML je često korišćen u obe vrste notacije. Za projektovanje softvera koriste se metode projektovanja softvera koje predstavljaju specifične strategije, i koje predlažu i pružaju skup notacija koje se koriste sa metodom (kao opis procesa koji bi trebalo koristi prilikom praćenja metode, i skup smernica za korišćenje metode) [60]. Neke od metoda projektovanja softvera su [7 str. 3-5]: funkcionalno-orijentisano projektovanje, objektno-orijentisano projektovanje, projektovanje orijentisano ka strukturama podataka (Data-Structure-Centered Design), projektovanje bazirano na komponentama. Jedan od pristupa projektovanju softvera dat je u [8]: 1. U fazi projektovanja prave se stvarni (realni) slučajevi korišćenja u tekstualnom i grafičkom obliku (ekranske forme sa kontrolama za poziv operacija) 2. Zatim se za svaki ugovor o operaciji iz faze analize prave interakcioni dijagrami u kojima učestvuju objekti konceptualnog modela koji obezbeđuju ponašanje definisano u ugovorima o operacijama. Takođe se prave interakcioni dijagrami za operacije stvarnih slučajeva korišćenja. Pri tome se mogu koristiti dijagrami stanja dobijeni u fazi analize. 3. Na osnovu interakcionih dijagrama (u kojima se čuva ponašanje sistema) i konceptualnog modela (u kome se čuva struktura sistema) pravi se dijagram klasa, za svaki slučaj korišćenja, koji se čuva u odgovarajućem paketu, čime se dobijaju dijagrami paketa arhitekture sistema. 4. Na osnovu dijagrama klasa pravi se šema baze podataka (relaciona,objektna…)