Použitie Workflow V ERP Systémoch

MASARYKOVA UNIVERZITA

FAKULTA INFORMATIKY

Použitie workﬂow v ERP systémoch

DIPLOMOVÁ PRÁCA

Bc. Lenka Krúpová

Brno, jar 2014 Prehlásenie

Prehlasujem, že táto diplomová práca je mojím pôvodným autorským die- lom, ktoré som vypracovala samostatne. Všetky zdroje, pramene a litera- túru, ktoré som pri vypracovaní používala alebo z nich cerpala,ˇ v práci riadne citujem s uvedením úplného odkazu na príslušný zdroj.

Bc. Lenka Krúpová

Vedúci práce: Ing. Leonard Walletzký, Ph.D.

ii Pod’akovanie

Rada by som pod’akovala Ing. Leonardovi Walletzkému, Ph.D. za to, že som mohla písat’ túto prácu pod jeho vedením. Dalejˇ by som rada pod’a- kovala pánovi Norbertovi Bedemu zo spolocnostiˇ MULTIMAGE s.r.o. za poskytnutie návrhu na modelový príklad workﬂow z praxe. Za pripomienky a návrhy technického aj štylistického charakteru by som rada pod’akovala mojej mamke Ing. Márii Krúpovej. V neposlednom rade by som rada po- d’akovala svojej rodine a priatel’ovi za psychickú podporu pri písaní tejto diplomovej práce.

iii Zhrnutie

Táto diplomová práca sa zaoberá použitím workflow v ERP systémoch. V texte sa najprv definujú základné pojmy z oblasti ERP systémov a ich väzby ku workflow. V práci je možné nájst’ porovnanie prístupu ku workflow v rôznych open source ERP systémoch. Dalejˇ popisuje význam a postup tvorby workflow v ERP systéme iDempiere. V práci je navrhnutý mo- delový príklad workflow pre riešenie najcastejšieˇ vyskytujúcich sa situácií s prihliadnutím k inštalácii a poskytovaniu softvéru ako služby v cloude.

iv Kl’úcovéˇ slová

ERP systém, cloud, iDempiere, OpenERP, workﬂow, Softvér ako služba, podnikové procesy

v Obsah

1 Úvod ...... 3 2 Definícia základných pojmov ...... 5 2.1 ERP - Enterprise Resource Planning...... 5 2.1.1 Definícia ERP systému...... 5 2.1.2 História ERP...... 5 2.1.3 Použitie ERP systémov...... 7 2.1.4 Výhody použitia ERP...... 8 2.1.5 Nevýhody použitia ERP...... 9 2.2 Workflow...... 10 2.2.1 Podnikový proces...... 10 2.2.2 Definícia workflow...... 10 2.2.3 História WfMS...... 12 2.2.4 Použitie workflow v ERP systémoch...... 12 2.2.5 Typy workflow...... 13 2.2.6 Základné vlastnosti workflow...... 16 2.2.7 Výhody použitia workflow...... 16 2.2.8 Nevýhody použitia workflow...... 17 2.3 Cloud...... 18 2.3.1 Definícia cloudu...... 18 2.3.2 Základné vlastnosti Cloudu...... 18 2.3.3 Nasadzovacie modely...... 19 2.3.4 Distribucnéˇ modely...... 19 2.4 Softvér ako služba (SaaS) v cloude...... 20 2.4.1 Definícia pojmu softvér ako služba...... 20 2.4.2 Výhody použitia SaaS...... 21 2.4.3 Nevýhody použitia SaaS...... 22 3 ERP systém iDempiere ...... 24 3.1 O iDempiere...... 24 3.2 Moduly v iDempiere...... 24 3.3 Typy užívatel’ov v iDempiere...... 27 3.4 Workflow v iDempiere...... 29 3.4.1 General workflow...... 30 3.4.2 Document Process workflow...... 31 3.4.3 Document Value workflow...... 35 3.4.4 Nevýhody iDempiere workflow...... 36

1 3.4.5 Výhody iDempiere workflow...... 36 3.5 Prehl’ad workflow v konkurencnýchˇ ERP systémoch.... 37 3.5.1 OpenERP...... 37 3.5.2 ERP5...... 38 3.5.3 Apache OFBix/opentaps...... 39 3.5.4 Neogia...... 39 3.6 Systém iDempiere v cloude...... 40 4 Modelové príklady workflow ...... 43 4.1 Modelový príklad I – Nastavenie produktu typu náklad (Ge- neral workflow)...... 43 4.1.1 Zaradenie a zhodnotenie modelového príkladu I.. 45 4.2 Modelový príklad II – Schval’ovanie faktúr (Document Pro- cess)...... 46 4.2.1 Zaradenie a zhodnotenie modelového príkladu II.. 50 4.3 Modelový príklad III – Zaslanie e-mailoveho potvrdenia (Do- cument Value workflow)...... 51 4.3.1 Zaradenie a zhodnotenie modelového príkladu III. 55 5 Záver ...... 56 A Elektronické prílohy ...... 60 B Zdrojové kódy z aplikácie ...... 61 C Identifikácia bežných procesov v rámci firmy ...... 62 D Snímky z aplikácie iDempiere ...... 66

2 1 Úvod

Rýchly rast informacnýchˇ a komunikacnýchˇ technológií (ICT) v oblasti mikroelektroniky a pocítaˇ covéhoˇ hardvéru a softvéru ovplyvnil takmer vše- tky oblasti v rámci spolocnosti.ˇ Prostredie rôznych spolocnostíˇ sa corazˇ viac stáva komplexnejším, a preto je možné rozlíšit’ rôzne funkcnéˇ jednotky v rámci infraštruktúry organizácie. Tieto funkcnéˇ jednotky majú ur- citéˇ vzt’ahy a vyžadujú inteligentný a rýchly spôsob komunikácie slúžiaci pre rozhodovanie, vcasnéˇ a efektívne zadávanie zákaziek na výrobu, riadenie skladov, úctovníctva,ˇ l’udských zdrojov, rozdelenie tovaru a služieb a prípadne d’alších oblastí špeciﬁckých pre konkrétnu spolocnost’.ˇ V tejto súvislosti manažment spolocnostiˇ musí identiﬁkovat’ efektívne informacnéˇ systémy, ktoré dopomôžu k zlepšeniu konkurencieschopnosti na trhu pri pa- ralelnom znižovaní nákladov. V momentálnej dobe si už všetky typy spo- locností,ˇ od najväcšíchˇ nadnárodných spolocnostíˇ až po podniky strednej a malej vel’kosti tzv. SME (z anglického Small and Medium Enterprises), zacínajúˇ uvedomovat’, že schopnost’ poskytovat’ správne informácie v správ- nom caseˇ prináša výhodu a výnimocnéˇ konkurencnéˇ postavenie na trhu. Systémy pre plánovanie podnikových zdrojov a podporu zamestnancov spo- locnostíˇ v ich každodennej práci sa stávajú každým dnomˇ viac dôležité a dalo by sa povedat’, že sú až nevyhnutné. Vel’mi castýmˇ riešením sa stáva použite ERP softvéru (softvér pre plá- novanie podnikových zdrojov z anglického Enterprise Resource Planning). ERP systémy vznikli koncom 80-tych a zaciatkomˇ 90-tych rokov. Hlavným užívatel’om ERP softvéru boli zo zaciatkuˇ hlavne rozsiahle a komplexné or- ganizácie. Prvé ERP systémy boli zložité, drahé a proprietárne, pricomˇ vy- žadovali konzultantov pre implementáciu softvéru podl’a požiadaviek kon- krétnej spolocnosti.ˇ V mnohých prípadoch boli spolocnostiˇ nútené zmenit’ svoje podnikové procesy, aby sa takto prispôsobili logike softvéru. Rýchly rast ICT prináša corazˇ viac výziev pre dodávatel’ov, ale aj zákazníkov ERP softvéru a núti ich takto spolupracovat’. Zavedenie a používanie ERP sys- témov je nikdy nekonciacimˇ procesom, a preto dopyt po ERP s otvoreným zdrojovým kódom (z anglického open source) rastie zo strany zákazníkov aj dodávatel’ov. Ideálny ERP softvér by mal poskytovat’ rýchlu výmenu modulov, umožnovat’ˇ jednoduché zmeny a zárovenˇ by mal byt’ užívatel’sky prívetivý. Z tohoto dôvodu je dnes na trhu možné nájst’ mnoho kvalitných ERP softvérov s otvoreným zdrojovým kódom, akými sú napríklad iDem-

3 1. ÚVOD

piere, Adempiere, OpenERP, Neogia a d’alšie. V tejto dobe sa už takmer žiadna spolocnost’ˇ nezaobíde bez podpory kritických podnikových procesov v rámci svojej infraštruktúry. Podnikové procesy sú základnými stavebnými prvkami pre budovanie úspechu a zvy- šovanie efektivity v rámci spolocnosti.ˇ Správne definovanie podnikových procesov napomáha pri plnení vízie a misie spolocnostiˇ a týmto zlepšuje konkurencnéˇ postavenie spolocnostiˇ vo svojom odvetví. Mnoho ERP sys- témov už umožnujeˇ modelovanie jednotlivých castíˇ procesov pomocou tzv. workflow (tok práce). Vo všeobecnosti sa jedná o logický a opakovatel’ný proces (alebo cast’ˇ procesu), pocasˇ ktorého sú dokumenty, informácie alebo úlohy odovzdávané od jedného úcastníkaˇ ku druhému (na základe súboru procedurálnych pravidiel). Ciel’om tejto diplomovej práce je nacrtnút’ˇ použitie workflow v najzná- mejších ERP s otvoreným zdrojovým kódom akými sú iDempiere, Open- ERP a d’alšie. Dalejˇ popísat’ význam a postup tvorby workflow v rámci jed- ného z ERP systémov a v konecnomˇ dôsledku navrhnút’ modelový príklad riešenia najcastejšieˇ sa vyskytujúcich situácií s prihliadnutím na inštaláciu a poskytovania SaaS v cloude. Pre konkrétne vysvetlenie postupu tvorby workflow a samotný modelový príklad bol vybraný ERP systém iDempiere verzia 2.0. V kapitole2 je možné nájst’ teoretickú cast’ˇ tejto diplomovej práce, ktorá sa venuje definovaniu základných pojmov pre potreby tejto práce. Ka- pitola3 sa zaoberá popisom workflow v iDempiere a porovnáva ho s workflow v iných ERP systémoch s otvoreným zdrojovým kódom, ktoré sa na- chádzajú momentálne trhu. Modelové príklady workflow pre ERP systém iDempiere je možné nájst’ v kapitole4. Táto cast’ˇ vychádza z nasledujúcich zdrojov: [1][2][3][4].

4 2 Deﬁnícia základných pojmov

Táto kapitola sa zaoberá deﬁníciou pojmov – ERP softvér, workﬂow, cloud a softvér ako služba.

2.1 ERP - Enterprise Resource Planning

Táto podkapitola sa zaoberá základnou deﬁníciou, históriou a použitím ERP systémov.

2.1.1 Deﬁnícia ERP systému ERP (Enterprise Resource Planning) je informacnýmˇ systémom pre riadenie podniku založený na podnikovom manažmente. ERP systém pozostáva z in- tegrovaných sád komplexného softvéru tzv. modulov. Správne implemento- vaný ERP systém je možné využit’ na riadenie a integráciu všetkých podni- kových procesov v rámci spolocnosti.ˇ Moduly ERP softvéru spravidla zahr- nujúˇ pokrokové podnikové aplikácie a nástroje pre podporu ﬁnancnéhoˇ a ná- kladového úctovníctva,ˇ predaja a distribúcie, materiálového manažmentu, riadenie l’udských zdrojov, plánovanie výroby, dodávatel’ského ret’azca a in- formáciách o zákazníkoch [5][6].

2.1.2 História ERP Prvé ERP systémy (podobné ERP systémom, ktoré sa používajú dnes) sa objavili koncom 80-tych rokov a zaciatkomˇ 90-tych rokov. No ich zárodok môžeme nájst’ už o pár desat’rocíˇ skôr, pretože vtedy vznikol jeden z ich pr- vých predchodcov tzv. IC softvér. IC softvér (z anglického Inventory Con- trol Packages) vznikol približne v 60-tych rokoch, ked’ väcšinaˇ organizácii navrhovala, vyvíjala a zavádzala centralizovaný pocítaˇ covýˇ systém. Tento softvér bol urcenýˇ prevažne pre kontrolovanie stavu skladov spolocnosti.ˇ Dalšímˇ z predchodcov ERP systémov bol tzv. MRP systém (z anglického Material Requirements Planning), ktorý bol vyvinutý v 70-tych rokoch. Do týchto systémov bolo pridané už okrem spomínaného kontrolovania skladov aj plánovanie produkcie, ktoré už umožnilo navrhovanie výrobných procesov v rámci spolocnosti.ˇ Zaciatkomˇ 80-tych rokov prišli na trh tzv. MRP II (z anglického Manufacturing Resources Planning) systémy. MRP II sa

5 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

zameriavali hlavne na optimalizáciu výrobných procesov so simultánnym synchronizovaním materiálov s požiadavkami výroby. MRP II už obsaho- vali moduly ako distribucnýˇ manažment, projektový manažment, ﬁnancie, l’udské zdroje a výroba. Po MRP II sa objavili ERP systémy, ktoré na rozdiel od svojich predchodcov disponovali komplexnost’ou, koordináciou a integ- ráciou, ktorá sa dala využit’ medzi jednotlivými cast’amiˇ spolocnostiˇ ako aj v celej spolocnosti.ˇ Z tohto je možné vidiet’, že MRP, MRP II a ERP integrovali podnikové procesy vrátane výroby, distribúcie, úctovníctva,ˇ ﬁ- nancií, l’udských zdrojov, projektového manažmentu, manažmentu skladov, dopravy, služieb a údržby, pricomˇ poskytovali dostupnost’, transparentnost’ a konzistenciu v rámci celého podniku. Momentálne už môžeme hovorit’ o tzv. „rozšírených ERP“ (extended ERP) systémoch. Pocasˇ 90-tych sa do ERP systémov pridali d’alšie moduly a funkcie ako APS (z anglického Ad- vanced Planning and Scheduling)1, e-business 2, CRM (z anglického Custo- mer Relationship Management) 3 a SCM (z anglického Supply Chain Ma- nagement) 4 [6][7][8]. Na obrázku 2.1 je možné vidiet’ históriu vývoja podnikových systémov, ktorá viedla ku vzniku ERP systémov.

1960 Inventory Control Packages

1970 Material Requirements Planning (MRP)

1980 Manufacturing Resources Planning (MRP II)

1990 Enterprise Resource Planning (ERP)

2000 Rozšírené ERP

Obr. 2.1: História vývoja ERP systémov od 60-tych rokov 20. storociaˇ až po súcasnost’ˇ pocnúcˇ vznikom IC softvéru až po vznik rozšíreného ERP systému (prekreslené z [6]).

1. APS - Pokrociléˇ plánovanie výroby - súbor nástrojov alebo metodológia plánovania do obmedzených kapacít. 2. E-business - elektronické podnikanie. Je hlavným predstavitel’om tzv. „novej ekonomiky“, ktorá súvisí s rozvojom internetu a telekomunikácií. 3. CRM je systém pre riadenie vzt’ahov so zákazníkmi. Umožnujeˇ zhromažd’ovat’ triedit’ a spracovávat’ údaje o zákazníkoch. 4. SCM - súbor nástrojov alebo metodológia plánovania dodávatel’ských ret’azcov.

6 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

Na obrázku 2.2 je možné vidiet’ model rozšíreného ERP systému aj s jeho najcastejšieˇ vyskytujúcimi sa modulmi.

Výroba Predaj a SCM distribúcia

ERP Materiálový CRM Systém manažment

Manažment Ľudské skladov zdroje

Účtovníctvo

Obr. 2.2: Model rozšíreného ERP systému a jeho typické moduly – výroba, predaj a distribúcia, materiálový manažment, l’udské zdroje, úctovníctvo,ˇ manažment skladov, CRM, SCM.

2.1.3 Použitie ERP systémov Podporné moduly ERP systému majú schopnost’ ul’ahcit’ˇ tok informácií medzi internými aj externými procesmi v organizácii. ERP systém môže výrazne dopomôct’ pri zlepšení výkonnosti v každodennej rutine zamestnancov organizácie. Pracovné cinnosti,ˇ ktoré v minulosti zaberali zbytocneˇ mnoho casuˇ sa pomocou ERP zautomatizovali a urýchlili. Spociatkuˇ sa ERP zavádzali hlavne v spolocnostiach,ˇ ktoré sa vyznacovaliˇ nárocnost’ouˇ na ka- pitál – výrobné a konštrukcnéˇ spolocnosti,ˇ letecký priemysel a obrana. Ne- skôr sa oblast’ pôsobenia rozšírila smerom ku ﬁnanciám, spolocnostiamˇ za- oberajúcim sa distribúciou spotrebného tovaru, zdravotníctvu, hotelierstvu, školstvu, poist’ovníctvu a telekomunikáciam.

7 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

Mnoho nadnárodných spolocnostíˇ obchoduje len so spolocnost’ami,ˇ kto- ré používajú ERP systém. ERP systém je momentálne považovaný za cenu vstupu na podnikatel’ský trh z dôvodu prepojenia k iným organizáciám pô- sobiacim na trhu pre vytvorenie vzt’ahu B2B 5. ERP systémy spociatkuˇ využívali hlavne väcšieˇ a komplexné podniky, ale pri modernom rozvoji ekonomiky menšie a stredné podniky (SME) zacaliˇ pocit’ovat’ konkurenciu a hrozbu od väcšíchˇ podnikov, a preto boli taktiež donútené ku používaniu ERP systémov. Vzhl’adom k tomu, že SME nemajú robustnost’ a komplexnost’ spájanú s väcšímiˇ podnikmi, SME musia cerpat’ˇ silu a výhody z IT a integrovaných informacnýchˇ systémov, aby zostali konkurencieschopné a zákaznícky orientované. ERP je castoˇ považované za odpoved’ pre ich prežitie na trhu. ERP systémy sú preto nútené prispôsobovat’ svoj obchodný model a prístup ku vel’kým, stredným aj menším ﬁrmám [5][6].

2.1.4 Výhody použitia ERP Úlohou tejto kapitoly je zosumarizovat’ výhody zavedenia ERP softvéru v spolocnosti.ˇ Medzi výhody použitia ERP systémov môžeme zaradit’ [1][3] [6]: • Spolocnost’ˇ získa kompletný prehl’ad o všetkých dôležitých cinnos-ˇ tiach v jej rôznych oddeleniach. • Spolocnost’ˇ získa jednotný reportovací systém s dôrazom na analýzu štatistík v reálnom case.ˇ • Dochádza k zjednoteniu spolocnosti,ˇ pretože rovnaký softvér sa pou- žíva vo všetkých oddeleniach. Jednotlivé oddelenia nekupujú vlastný softvér – týmto sa šetrí cas/peniazeˇ a zvyšuje sa transparentnost’. • ERP systém je modiﬁkovatel’ný, aby sa prispôsobil požiadavkám konkrétnej spolocnostiˇ a taktiež môže poskytovat’ zavedenie d’alších modulov, ktoré spolocnost’ˇ potrebuje – napríklad SCM, CRM. . . • ERP softvér je komplexný a obsahuje mnoho modulov – spolocnost’ˇ má všetky funkcie v jednom softvéri. Zárovenˇ je to modulárny soft- vér, a preto je možné implementovat’ tol’ko modulov, kol’ko kon- krétna spolocnost’ˇ potrebuje a využije.

5. B2B – business to business popisuje obchodné transakcie medzi podnikmi, napríklad medzi výrobcom a vel’koobchodníkom, alebo medzi vel’koobchodom a predajcami.

8 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

• ERP systémy umožnujúˇ integráciu s inými systémami. • Pre skladovanie dát sa implementuje jedna databáza, ktorá umož- nujeˇ skladovanie všetkých informácií, ktoré ERP systém potrebuje centralizovane. Zálohovanie databázy je preto jednoduché. • ERP systémy umožnujúˇ zavedenie centralizovanej bezpecnostnejˇ po- litiky, preto sa dajú pokladat’ za bezpecné.ˇ Všetky transakcie sa dejú v rámci ERP systému, a preto systém umožnujeˇ sledovat’ kto, kedy a ako vykonal konkrétnu transakciu. • ERP systémy poskytujú transparentnost’ a tým umožnujúˇ rýchlej- šiu a lepšiu spoluprácu napriecˇ spolocnost’ou.ˇ ERP systémy ul’ah- cujúˇ sledovanie podnikových procesov (napríklad stavu objednávky, skladu, príjmov a výdajov...)

2.1.5 Nevýhody použitia ERP Úlohou tejto kapitoly je zosumarizovat’ nevýhody zavedenia ERP softvéru. Medzi nevýhody použitia ERP systémov môžeme zaradit’ [1][3][6]: • Cena zavedenia, plánovania, modifikovania, konfigurovania, testo- vania a implementovania ERP systému je vysoká a spolocnost’ˇ si ju musí premysliet’ a zvážit’. Je dôležité nájst’ ERP systém, ktorý bude vyhovovat’ danej spolocnosti,ˇ aby spolocnost’ˇ netratila financnéˇ pros- triedky na nasledujúcich modifikáciách systému. • Casováˇ nárocnost’ˇ zavedenia ERP systému (plne funkcnéhoˇ a využi- tel’ného) sa pohybuje medzi 1–3 rokmi. Ak sa ERP systém zacneˇ používat’ skôr ako bol správne nastavený a modifikovaný môže to priniest’ problémy rôzneho druhu (krátke zaškolenie zamestnancov, nevyladený systém. . . ). • Návratnost’ nákladov sa nemusí ukázat’ ihned’ po zavedení ERP sys- tému. • Ak ERP systém obsahuje mnoho modifikácií môže to zavedenie a po- užívanie spomal’ovat’ a robit’ ich nárocnejšími.ˇ Ak ERP systém obsahuje málo modifikácií je možné, že nebude využitel’ný pri niekto- rom z podnikových procesov a bude sa treba rozhodnút’, ciˇ investo- vat’ d’alšie financie do jeho modifikácie.

9 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

• Zamestnanci môžu považovat’ použitie ERP systému za zložité. Za- školenie užívatel’ov je nevyhnutné a dôraz je na jednoduchom užíva- tel’skom rozhraní ERP systému. Okrem toho zamestnanci môžu byt’ rezistentní vociˇ zmenám a nemusia byt’ naklonení zmene softvéru. • Spolocnost’ˇ musí rátat’ s d’alšími nákladmi na podporu ERP sys- tému, modernizáciu IT infraštruktúry a podobne. • Migrácia existujúcich dát do nového ERP systému môže byt’ zlo- žitá, prípadne nerealizovatel’ná vzhl’adom na rozdielnost’ štruktúr v starom a novom systéme. V tomto prípade je nutné dáta zadat’ ma- nuálne. • Implementáciu ERP systému je t’ažké dosiahnut’ v organizáciach, ktoré nie sú centralizované a teda obsahujú mnoho rôznorodých pod- nikových procesov a systémov. • Ak spolocnost’ˇ potrebuje d’alšie modiﬁkácie alebo podporu spravidla musí spolupracovat’ s jediným predajcom ERP systému. Táto nevýhoda nie je taká zjavná pri použití ERP systému s otvoreným zdrojovým kódom.

2.2 Workﬂow

Táto podkapitola sa zaoberá základnou definíciou, typmi, použitím, základ- nými vlastnost’ami workflow a rozdielom workflow vociˇ podnikovému procesu.

2.2.1 Podnikový proces Podnikový proces je sériou logicky nasledujúcich aktivít a úloh. Tieto úlohy sú vykonané spolu na dosiahnutie zadeﬁnovaných výsledkov spolocnosti.ˇ Spravidla sa jedná o komplexný a mohutný sled úloh. Podnikové procesy sa týkajú jednotlivých castíˇ spolocnosti.ˇ Pre automatizáciu podnikového procesu alebo castejšieˇ castiˇ podnikového procesu slúži workﬂow.

2.2.2 Definícia workflow Workflow (tok práce) vyjadruje takú funkcionalitu systému, ktorá umožnujeˇ popísanie a realizáciu podnikových procesov alebo castiˇ podnikových pro-

10 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

cesov pri spracovaní dokumentov a informácií. Ciel’om tejto funkcionality je podl’a predom stanovených pravidiel pridel’ovat’ úlohy jednotlivým uží- vatel’om tak, aby bol splnený sled aktivít a úloh v spracovaní konkrétneho dokumentu a informácie. Procesom v tomto kontexte rozumieme zachyte- nie všetkých variant spracovania urcitéhoˇ dokumentu/informácie. Proces je definovaný pre dokumenty jednej triedy a popisuje cinnostiˇ a podmienky, za ktorých majú byt’ tieto cinnostiˇ vykonané a kým majú byt’ vykonané. Úlohy sú rozdel’ované jednotlivým užívatel’om tak, aby bol splnený proces spra- covávania urcitéhoˇ dokumentu a informácie. Workflow je možné vyjadrit’ pomocou siet’ového diagramu [9][4][10]. Na obrázku 2.3 je možné vidiet’ základný koncept workflow.

Workflow

Podmienka Prechod

Štart Aktivita/ Podproces Koniec Uzol

Akcia

Obr. 2.3: Všeobecný model typického workﬂow s pociatoˇ cnýmˇ a koncovým stavom; aktivitou, akciou, podprocesom; a prechodmi.

11 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

2.2.3 História WfMS

WfMSs (z anglického Workﬂow management systems) sú systémy, ktoré monitorujú proces odovzdávania informácií, dokumentov a úloh od jed- ného zamestnanca/stroja ku druhému v rámci konkrétneho podniku. WfMSs sa objavili v 80-tych rokoch minulého storocia.ˇ Ich predchodcami boli tzv. OIS systémy (z anglického Ofﬁce Information Systems) v 70-tych rokoch minulého storocia.ˇ Z dôvodu niekol’kých neúspechov implementovania OIS systémov sa od týchto systémov zacaloˇ upúšt’at’ a zacaliˇ sa hl’adat’ nové rie- šenia. V tomto období boli WfMSs predstavené verejnosti. Vel’mi populár- nymi sa stali v 90-tych rokoch vd’aka pokrokom v transakcnomˇ spracovaní procesov, ale WfMSs sa nevyvinuli hned’ do zrelej a stabilnej technológie (na rozdiel od ERP systémov). V momentálnej dobe, ale mnoho ERP systé- mov obsahuje asponˇ castiˇ funkcionality WfMSs, prípadne sa ich tvorcovia snažia túto funkcionalitu do systému zaviest’ [1][9][4].

2.2.4 Použitie workﬂow v ERP systémoch

ERP tvorcovia slovo workflow vnímajú iným spôsobom než vývojári workflow systémov. ERP tvorcovia sú viac zameraní na konkrétne úlohy/dáta než na procesy ako je tomu u workflow systémov. Zlúcenieˇ workflow s ERP systémami v plnom rozsahu teda mení základnú myšlienku ERP systémov, a preto tento pohl’ad nemusí byt’ vhodný pre každú spolocnost’.ˇ Z tohoto dôvodu neexistuje vel’a ERP systémov, ktoré by implementovali funkcionalitu workflow v plnom rozsahu do svojho riešenia. Hoci základné prin- cípy workflow (modelovanie, kreslenie grafov a následné implementovanie) sú jednoduché na zavedenie, technológia, ktorá je potrebná na dosiahnutie komplexného workflow, je zložitá. Na zaciatokˇ je dôležité použitie gra- fického nástroja pre modelovanie workflow. Castoˇ je toto použitie kontro- lované špecialistom alebo analytikom, ktorý rozumie zamestnancom, ktorí budú vykonávat’ úlohy v rámci workflow alebo sa vyzná do cinnostíˇ pracov- níkov, ktorí budú pomocou workflow nahradení. Takto navrhnuté workflow obsahujú nielen tok jednotlivých úloh ciˇ dokumentov, ale hlavne detaily ku každému kroku v tomto procese. Automatické a manuálne úlohy sú zazna- menávané spolu s ich vykonávatel’om s dôrazom na to ako, kedy a kde majú byt’ vykonané s prihliadnutím na to, coˇ sa stane po tom ako je workflow do- koncený.ˇ Jednoduchá úloha môže mat’ mnoho nasledujúcich akcií, podpro- cesov, paralelných a sériových ciest k iným aplikáciám a/alebo l’ud’om. Pri

12 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

spustení workflow sa vykonajú všetky castiˇ procedúry v reálnom case.ˇ Úlo- hou tzv. „Workflow engine“ je riadenie workflow. Workflow engine spúšt’a jednotlivé programy a upozornujeˇ úcastníkovˇ (aplikácie a zamestnancov) na to, že nastal ich casˇ vykonat’ konkrétnu úlohu v procese. Týmto workflow engine kontroluje vykonanie procesov a uist’uje sa o tom, že potrebná práca je vykonaná v správnom caseˇ [11][9].

2.2.5 Typy workflow Táto podkapitola sa venuje deleniam workflow podl’a rôznych kritérií. Workflow sa dá rozdelit’ na 4 typy podl’a kritéria charakter procesu [9]:

1. Produkcnýˇ – tento typ podporuje hlavné podnikové procesy. Me- dzi hlavné podnikové procesy zarad’ujeme také, ktoré tvoria pri- danú hodnotu ku výslednému produktu/službe a zárovenˇ na nich zá- visí spokojnost’ zákazníka spolocnosti.ˇ Tieto procesy sú spravidla dobre štruktúrované, ale zárovenˇ zložité. Príkladom takéhoto procesu môže byt’ továren,ˇ kde každý pracovník disponuje svojím popisom práce, ktorú by mal vykonávat’ a túto cinnost’ˇ považujeme za hlavnú (zamestnanci, ale vykonávajú aj mnoho iných cinností).ˇ Príkladom môže byt’ prijímanie tovaru do skladu skladníkom.

2. Kolaboratívny – tento typ workflow podporuje tímovú spoluprácu. Typickým prvkom tohoto workflow je dokument, cez ktorý sa vy- mienajúˇ informácie. Tento proces predstavuje iteráciu toho istého kroku až po súhlas kompetentnou osobou. Príkladom kolaboratív- neho workflow môže byt’ napríklad návrh novej funkcionality do softvéru alebo tvorba dokumentácie.

3. Administratívny – tento typ workﬂow nájdeme pri vykonávaní zvy- cajnýchˇ každodenných úloh v spolocnosti.ˇ Základne vlastnosti týchto workﬂow sú jednoduchost’, opakovatel’nost’ a štruktúrovanost’. Za- rad’ujú sa tu napríklad obvyklé administratívne úkony ako je zadanie objednávky do systému alebo vystavenie faktúry.

4. Ad hoc – tento typ workflow je založený na náhodnosti jeho vzniku. Spravidla sem patria procesy, ktoré predom neboli zadefinované a pre- to sú neštandardizované a unikátne. Tieto procesy sú definované pri

13 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

vzniku. Tento workﬂow je podobný administratívnemu, ale naviac obsahuje výnimky, odchýlky a jedinecnéˇ situácie.

Na obrázku 2.4 je možné vidiet’ vzt’ah medzi vyššie uvedenými typmi work- ﬂow podl’a charakteru procesu.

rozhodujúci proces produkčný

kolaboratívny

a t o n d o h

á v o k i n d o p

ad hoc

administratívny podporný proces

opakovaný proces unikátny proces

Obr. 2.4: Typy workﬂow procesov podl’a charakteru procesu (prebraté z [9]).

Podl’a hl’adiska orientácie procesov sa workﬂow delí na tieto dve skupiny [9]:

1. Procesy orientované na l’udí (people-centric) – tento typ procesov sa vyznacujeˇ absenciou štruktúrovanosti, dlhou dobou spracovania, zdiel’aním informácií a orientáciou na projekty. Príkladom tohoto typu workﬂow môže byt’ zákaznícky servis.

14 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

2. Procesy orientované na seba (process-centric) – tento typ workflow na rozdiel od predošlého je štruktúrovaný s pevným pracovným postupom s orientáciou na transakcnéˇ spracovanie a krátke procesné cykly. Príkladom tohoto workflow môže byt’ zablokovanie objed- návky zákazníka pri predošlom nezaplatení faktúr. Podl’a hl’adiska technologickej architektúry je možné workflow rozdelit’ na tieto štyri skupiny [9]: 1. Workflow založené na procesoch (process-based) – tento typ workflow je navrhnutý pre analýzu, automatizáciu a riadenie podnikového procesu. Typickým predstavitel’om tejto kategórie je produkcnýˇ workflow systém. 2. Workflow založené na dokumentoch (document-based) – tento typ workflow je riadený predstavou o smerovaní dokumentov a schopnosti externej komunikácie. Do tejto kategórie je možné zaradit’ ad- ministratívny workflow. 3. Workflow založený na elektronickej pošte (mail-based) – tento typ workflow používa emailové servery. Typickým predstavitel’om tejto kategórie sú ad-hoc a kolaboratívne workflow systémy. 4. Produkty založené na webe (web-based) – tento typ workflow vy- užíva internetové aplikácie, prípadne unifikované internetové rozhranie. Podl’a hl’adiska použitia v podnikovej praxi je možné workflow rozdelit’ na tieto dve skupiny [12]: 1. Monitorovací workflow – tieto procesy slúžia ku sledovaniu/monitorovaniu stavu záznamov/úloh/dokumentov v systéme. V stanove- nom caseˇ kontrolujú zadané podmienky. Ak je niektorá z podmienok splnená, proces na nuˇ upozorní (napr. zaslaním emailu). 2. Schval’ovací workflow – tieto procesy riadia kompletné spracovanie konkrétneho dokumentu a jeho tok v spolocnosti.ˇ Väcšinaˇ dokumentov musí behom svojho životného cyklu prejst’ cez ruky mnohým zamestnancom. Tieto procesy znižujú nutnost’ papierovej admini- stratívy a znižujú riziko stratenia dokumentu pri odovzdávaní medzi rôznymi zamestnancami a týmto eliminujú casovéˇ straty.

15 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

2.2.6 Základné vlastnosti workflow Medzi základné vlastnosti workflow môžeme zaradit’ [10]: • Pridel’uje užívatel’ovi prácu nad dokumentom/informáciou. • Jednotlivé úlohy je možné presmerovat’ na iného užívatel’a alebo vytvorit’ kópiu úlohy a priradit’ ju kompetentnejšiemu pracovníkovi. • Umožnujeˇ presmerovat’ úlohy na iného úcastníka.ˇ Dôvody presme- rovania, vytvorenia kópie úlohy môžu byt’ neprítomnost’ užívatel’a, ktorému bola úloha pridelená alebo nedostatok podkladov pre vyrie- šenie tejto úlohy. • Workflow je využívaný ku monitorovaniu (napríklad prekrocenieˇ ur- citejˇ ciastkyˇ objednávky u konkrétneho zákazníka s väzbou na pla- tenie predošlých faktúr za predošlé objednávky). • Simulácia konkrétneho, vopred zadefinovaného procesu. • Poskytuje rôznorodé štatistiky, ktoré môžu byt’ nápomocné manaž- mentu spolocnostiˇ pri riadení procesov a urcovaníˇ úzkeho hrdla tých- to procesov.

2.2.7 Výhody použitia workflow Medzi výhody použitia workflow môžeme zaradit’ [10]: • Workflow núti spolocnost’ˇ popísat’ a formalizovat’ procesy v rámci nej. Týmto máme istotu, že všetky kroky boli postupne prevedené tak ako boli zadefinované. Zamestnanci nemôžu žiaden krok pre- skocit’,ˇ prípadne zabudnút’. Takto je možne kontrolovat’ nepotrebnú prácu a teda prácu, ktorá nebola predom definovaná. • Automatizácia elektronických schval’ovacích procesov prináša ich jednoduchú reprodukovatel’nost’ a zabezpecujeˇ intenzitu využitia zamestnancov. Rastie produktivita zamestnancov, ked’že môžu praco- vat’ na dôležitejších úlohách. • Ak v danom bode zamestnanec nie je k dispozícii, je možná zastu- pitel’nost’ zamestnanca iným zamestnancom s rovnakými právomo- cami.

16 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

• Workflow vedie ku zjednodušeniu toku dokumentov a informácií. Eliminuje sa práca s papierovou administratívou. • Ak spolocnost’ˇ rozširuje svoje pôsobenie, nie je nutné naberat’ d’alší personál, pretože vd’aka použitiu workflow je jednoduché prerozde- lit’ pracovnú silu podl’a aktuálnych potrieb spolocnosti.ˇ • Workflow vedie k lepšej transparentnosti firemných procesov. Zlep- šuje sa sledovanie konkrétnej úlohy. Zamestnanec vie ihned’ status konkrétnej úlohy. Otázky kto, kedy a kde sú ihned’ zodpovedané pomocou workflow. • Rozhranie k externým databázam umožnujeˇ kontrolu platnosti a interakcie externých procesov, ktoré majú byt’ automatizované a zjed- nodušené. • Rozhodnutia, ktoré boli vykonané zamestnancami, môžu byt’ vyko- nané pomocou workflow presne podl’a pravidiel, ktorými sa riadil personál, ale automaticky. • Výkonnost’ je l’ahko a presnejšie meratel’ná, pretože je jednoduché zhodnotit’ kol’ko práce bolo vykonanej za konkrétny cas.ˇ Ked’že je workflow napojený k databáze, je vidno kto, coho,ˇ kol’ko a za kol’ko vykonal. • Workflow zabezpecujeˇ bezpecnost’ˇ v ohl’ade preddefinovaných uží- vatel’ských práv, ktoré umožnujúˇ prístup len tomu, kto to naozaj potrebuje na vykonanie svojej úlohy.

2.2.8 Nevýhody použitia workflow Medzi nevýhody použitia workflow môžeme zaradit’6 [10]: • Prehodnotenie, zdokumentovanie a navrhnutie podnikových procesov môže zabrat’ dlhšiu dobu s címˇ súvisia l’udské a financnéˇ zdroje spolocnosti.ˇ • Procesy vo firme musia byt’ správne navrhnuté a implementované do workflow. Je nutné vystihnút’ všetky možné situácie, aby nedošlo ku zablokovaniu procesu.

6. V tejto castiˇ práce sa vychádza zo spomenutých výhod.

17 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

• Zadeﬁnované podnikové procesy urcujúˇ hranice danej úlohy vo ﬁrme a teda môžu byt’ obmedzujúce. • Pri reorganizácii podnikových procesov môže dôjst’ k prepúšt’aniu zamestnancov.

2.3 Cloud

Táto sekcia sa zaoberá vysvetlením pojmu cloud.

2.3.1 Deﬁnícia cloudu Podl’a NIST (National Institute of Standards and Technology) 7 v špeciálnej publikácii císloˇ SP 800-145 zo septembra 2011, „Cloud computing“ je model, ktorý umožnujeˇ pohodlné a všadeprítomné zdiel’ané a konﬁgurovatel’né pocítaˇ covéˇ zdroje (napr. siete, servery, aplikácie a služby) so siet’ovým prí- stupom na vyžiadanie. Tieto zdroje majú byt’ poskytnuté rýchlo s minimál- nym úsilím a s minimálnou interakciou poskytovatel’a služby. Tento model sa skladá z piatich základných vlastností, troch modelov služieb a štyroch nasadzovacích modelov.

2.3.2 Základné vlastnosti Cloudu Medzi základné vlastnosti cloudu patrí: 1. Služba na vyžiadanie (On-demand self-service) – spotrebitel’ môže jednostranne využit’ výpoctovéˇ zdroje (server, siet’ové úložisko) pod- l’a potreby bez nutnosti interakcie so svojim poskytovatel’om služby. 2. Prístup cez siet’ (Broad network access) – k zdrojom je možné pri- stupovat’ cez siet’ a štandardné mechanizmy, ktoré podporujú použi- tie rôznych klientských platforiem (napr. mobilné telefóny, tablety, notebooky a osobné pocítaˇ ce).ˇ 3. Združovanie zdrojov (Resource pooling) – výpoctovéˇ zdroje poskytovatel’a sú zlúcené,ˇ aby mohli slúžit’ pre viac spotrebitel’ov s rôz- nymi fyzickými a virtuálnymi zdrojmi. Výpoctovéˇ zdroje sú dyna- micky pridelené podl’a požiadaviek spotrebitel’ov.

7. Uverejnené na stránke http://csrc.nist.gov/publications/ nistpubs/800-145/SP800-145.pdf 18 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

4. Pružnost’ (Rapid elasticity) – zdroje môžu byt’ elasticky poskyto- vané a uvol’novanéˇ (v niektorých prípadoch aj automaticky) s pri- hliadnutím na dopyt spotrebitel’a. Z pohl’adu spotrebitel’a sa zdajú zdroje nelimitované.

5. Meraná služba (Measured service) – cloud systémy automaticky kontrolujú a optimalizujú využívanie zdrojov s využitím schopnosti merania na urcitejˇ úrovni abstrakcie zodpovedajúcej typu ponúkanej služby.

2.3.3 Nasadzovacie modely Cloud môže byt’ nasadený rôznymi spôsobmi. Rozlišujeme nasledujúce štyri spôsoby:

1. Privátny cloud (Private cloud) – tento typ cloudu je poskytovaný výhradne jednej spolocnosti,ˇ ktorá sa skladá z viacerých spotrebite- l’ov (napr. viacerých obchodných jednotiek). Môže byt’ vlastnený, poskytovaný a riadený organizáciou alebo tret’ou stranou (prípadne ich kombináciou).

2. Komunitný cloud (Community cloud) – tento typ cloudu sa poskytuje pre exkluzívne využitie špeciálnou komunitou spotrebitel’ov z organizácii, ktoré zdiel’ajú rovnaké záujmy (napríklad poslanie, bezpecnostnéˇ požiadavky, politiku. . . ). Môže byt’ vlastnený, posky- tovaný a riadený jednou alebo viacerými organizáciami z komunity alebo tret’ou stranou (prípadne ich kombináciou).

3. Verejný cloud (Public cloud) – tento typ cloudu je poskytovaný pre otvorené používanie verejnost’ou. Môže byt’ vlastnený, poskytovaný a riadený podnikatel’skou, akademickou alebo vládnou organizáciou (prípadne ich kombináciou).

4. Hybridný cloud (Hybrid cloud) – tento cloud je kombináciou dvoch alebo troch z cloudov typu privátny, komunitný a verejný.

2.3.4 Distribucnéˇ modely Služby cloudu je možné rozclenit’ˇ do troch rôznych kategórií:

19 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

1. Softvér ako služba (Software as a Service) – vid’. 2.4.

2. Platforma ako služba (Platform as a Service) – tento model poskytuje platformu a prostredie umožnujúceˇ vývojárom vytvárat’ apliká- cie a služby cez internet.

3. Infraštruktúra ako služba (Infrastructure as a Service) – tento model poskytuje výpoctovúˇ infraštruktúru (virtuálne serverové úložisko, siet’ové spojenia, IP adresy).

2.4 Softvér ako služba (SaaS) v cloude

Táto kapitola sa zaoberá vysvetlením pojmu Softvér ako služba (Software as a Service) v cloude.

2.4.1 Definícia pojmu softvér ako služba SaaS je distribucnýˇ model softvéru, v ktorom predajcovia alebo poskyto- vatelia služby host’ujú svoje aplikácie zákazníkom cez siet’, typicky cez Internet. V tomto modeli sa zákazníkovi poskytuje aplikácia v infraštruktúre cloudu. Aplikácie sú prístupné z rôznych klientskych zariadení a to bud’ pro- stredníctvom tenkého klienta rozhrania, ako je napríklad webový prehliadacˇ (napr. email na webe) alebo programového rozhrania. Zákazník neriadi in- fraštruktúru cloudu – siete, servery, operacnéˇ systémy, úložisko alebo indivi- duálne funkcionality aplikácie. Výnimkou môže byt’ limitované nastavenie konfigurácie špecifické pre užívatel’a aplikácie [13]. Na obrázku 2.5 je možné vidiet’ demonštráciu SaaS modelu, kde poskytovatel’ služby poskytuje softvér svojím zákazníkom cez internet a zákazníci k tomuto softvéru môžu pristúpit’ cez rôzne zariadenia.

20 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

zákazník

s lu žb zákazník a

služba Internet

a žb u sl

zákazník Poskytovateľ SaaS softvéru

Obr. 2.5: Model softvéru ako služby – Poskytovatel’ SaaS poskytuje softvér cez internet svojim zákazníkom.

2.4.2 Výhody použitia SaaS Medzi výhody použitia SaaS modelu patria [13]: • Jednoduchšia administrácia, automatické aktualizácie a opravy. Ked’- že poskytovatel’ služby riadi inštanciu aplikácie, ktorú práve používa zákazník, hl’adanie chýb a ich reprodukovanie je ovel’a jednoduch- šie a testovacie scenáre sú vel’mi aktuálne pretože berú do úvahy najnovšie dáta v aplikácii. • Kompatibilita – všetci užívatelia majú rovnakú verziu softvéru, ktorá je implementovaná na rovnakej platforme. V on-line prostredí je aplikácia inštalovaná len v jednom nastavení, preto sa SaaS vyvíja ovel’a jednoduchšie než krabicový softvér. • Jednoduchšia spolupráca a globálny prístup – všetci užívatelia majú rovnakú verziu softvéru. • Nízke pociatoˇ cnéˇ náklady – zákazníci platia iba za to, coˇ naozaj používajú a náklady môžu byt’ celkovo eliminované zrušením tejto služby. Dochádza ku zníženiu ﬁnancnýchˇ nákladov pri kúpe hard- véru a ušetreniu l’udských zdrojov pri správe, inštalácii a prevádzke softvéru.

21 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

• Dôležitým bodom pre on-line služby je to, že vertikálne integrujú vý- voj aplikácií aj s vývojom ich infraštruktúry (súborové systémy, da- tabázy, aplikacnéˇ servery a nástroje pre správu). Komponenty tejto infraštruktúry teda môžu byt’ ušité na mieru, aby vyhovovali kon- krétnej aplikácii, ale aj všeobecnému on-line modelu.

• Špecializácia aplikacnéhoˇ riadenia môže výrazne redukovat’ potrebu IT zamestnancov v spolocnosti,ˇ ktorí predstavujú vel’kú cast’ˇ nákla- dov spolocnosti.ˇ

• Pre vel’ké spolocnosti,ˇ ktoré majú vlastné dátové centrá, SaaS môže spojit’ užívatel’ov. Pre SME spolocnostiˇ SaaS môže poskytnút’ zá- kladnú automatizáciu podnikových procesov.

2.4.3 Nevýhody použitia SaaS Medzi nevýhody použitia SaaS patria [13]:

• Zdiel’anie softvéru znižuje možnost’ konfigurácie systému rôznymi spôsobmi pre konkrétne organizácie. Ak existuje len jedno združenie aplikacnýchˇ serverov tak potom tieto servery nemôžu byt’ nakonfi- gurované tak, aby splnili rôzne požiadavky konkrétnych spolocností.ˇ Taktiež je problematické ak si chce zákazník modifikovat’ softvér pomocou vlastných, interných zdrojov.

• Poskytovatel’ musí zarucit’,ˇ aby sa jedna spolocnost’ˇ nedostala k dá- tam druhej spolocnosti.ˇ Zdiel’anie zvyšuje túto hrozbu. Napríklad ak aplikacnéˇ servery udržiavajú dáta medzi požiadavkami (cache, stav), potom pri útoku na server alebo pretecenímˇ zásobníka môže dôjst’ k odhaleniu dát jednej spolocnostiˇ druhej spolocnosti.ˇ

• Aplikácia musí zabránit’ jednotlivým užívatel’om využívat’ príliš mnoho zdrojov ciˇ už ich využívajú úmyselne alebo neúmyselne. Zdie- l’anie tento problém prehlbuje, pretože takýmto spôsobom môže jedna organizácia ovplyvnovat’ˇ druhú organizáciu. Bežnou technikou zabránenia tohoto problému je opozdenie požiadaviek v rámci casu,ˇ aby využívanie zdrojov bolo rovnomerné. Táto technika nie je vel’mi atraktívna pri nastavovaní on-line, kde sa služba poskytuje ako fun- kcionalita, ktorá by mala splnit’ všetky zákaznícke požiadavky. Po-

22 2. DEFINÍCIA ZÁKLADNÝCH POJMOV

skytovatel’ SaaS musí nájst’ správnu hranicu medzi primeraným a vy- sokým využitím zdrojov zákazníkmi.

• Vel’mi zložité a komplexné modiﬁkácie softvéru môžu spôsobovat’ problémy pri aktualizácii služby na novšiu verziu.

23 3 ERP systém iDempiere

Táto kapitola zoznamuje s ERP iDempiere, vysvetl’uje tvorbu workﬂow v iDempiere a porovnáva jeho prístup s inými ERP systémami s otvoreným zdrojovým kódom na trhu. Pre úcelyˇ tejto diplomovej práce bola použitá najnovšia dostupná verzia iDemiere v2.0 (alpha), v ktorej sú realizované aj modelové príklady vid’.4. Táto kapitola vychádza z nasledujúcich zdrojov: [14][15][16][17].

3.1 O iDempiere

ERP systém iDempiere je rozšírený ERP systém s otvoreným zdrojovým kódom (vid’. 2.1.1), ktorý vznikol spojením ERP systému ADempiere a OSGi Service Platform 1. Systém iDempiere sa vyvinul zo systému ADempiere, ktorý vznikol oddelením od systému Compiere. Compiere vznikol z ERP systému Jorg Janke, ktorý pôvodne pochádza z Oracle. Vd’aka tomuto faktu má iDempiere vel’a spolocnéhoˇ s Oracle, hlavne castiˇ týkajúce sa ﬁnanc-ˇ ných cˇrt´ softvéru. Systém iDempiere je založený na pôvodnej architektúre ERP systému ADempiere a novej architektúre pre použitie tzv. „state-of- the-art“ 2 technológie. Tento ERP systém používa objektovo-relacnýˇ data- bázový systém s otvoreným zdrojovým kódom postgreSQL.

3.2 Moduly v iDempiere

Táto cast’ˇ obsahuje popis základných modulov, ktoré sa nachádzajú v iDem- piere. V iDempiere sa nachádzajú nasledujúce moduly:

• System Admin – tento modul kontroluje dáta a tabul’ky, ktoré sú používané vo viacerých moduloch. V tomto module je možné nastavit’ všeobecné pravidlá (systémové pravidlá, zabezpecenieˇ sys- tému, server, workﬂow, tlacenie,ˇ spoluprácu), pravidlá pre klienta, pravidlá pre spolocnost’ˇ (typ, banku, proces platieb, výpis z ban-

1. OSGi Service Platform je špeciﬁkácia dynamického modulárneho systému pre prog- ramovací jazyk Java. 2. Termín „state of the art“ znamená najvyššiu úrovenˇ všeobecného vývoja zariadenia, technológie prípadne oblasti dosiahnutej v konkrétnom case.ˇ

24 3. ERP SYSTÉMIDEMPIERE

kového úctu.ˇ . . ), dáta (typ vzt’ahov, reportovanie problémov v sys- téme. . . )

• Application Dictionary – tento modul je jeden z najsilnejších as- pektov celej aplikácie. Celá aplikácia môže byt’ riadená cez zmeny v tomto module, tým pádom vývoj (písanie kódu) je obmedzené. Mnoho funkcií môže byt’ nakonﬁgurovaných priamo z tohoto modulu bez nutnosti skompilovat’ kód. Tento modul umožnujeˇ konﬁ- guráciu databázových tabuliek a položiek v nich; vytvorenie obrazovky, záložiek a polí; vytvorenie vlastných reportov.

• Partner Relations – tento modul slúži pre deﬁníciu vzt’ahov s partnermi (zákazníkmi, predajcami, partnermi). V iDempiere sa ukladá jediný zoznam partnerov, ktorí môžu byt’ typu zákazník, dodávatel’, zamestnanec prípadne podskupina týchto typov. Jediný zoznam partnerov v iDempiere vytvára lepšiu transparentnost’ v systéme a po- núka nadhl’ad v podnikaní spolocnosti.ˇ Tento jediný zoznam tiež po- máha zjednodušit’ záväzky (AP) a pohl’adávky (AR), pre mnoho ﬁ- riem. Väcšinaˇ spolocnostíˇ má asponˇ jedného obchodného partnera, ktorý je zárovenˇ odberatel’om a dodávatel’om. Systém zarucujeˇ jednoduchost’ vytvorenia odberatel’skej faktúry oproti dodávatel’skej faktúre (prípadne platby od odberatel’a oproti platbe dodávatel’ovi).

• Quote-to-Invoice – tento modul umožnujeˇ spravovanie marketingu a predaja, objednávok (od zákazníkov smerom ku spolocnosti),ˇ dopravy a faktúr. IDempiere dáva možnost’ vytvárat’, potvrdzovat’ a mo- nitorovat’ objednávky v systéme. Workﬂow sa stará o to, aby tí správ- ni zamestnanci vcasˇ schval’ovali potrebné požiadavky (napr. objed- návky). Akonáhle je objednávka schválená a dokoncená,ˇ iDempiere dáva nahliadnut’ do správy objednávok, vrátane reportovania nespra- covaných objednávok a naplnenie dorucovatel’skýchˇ služieb. Tento modul umožnujeˇ automatickú alebo manuálnu tvorbu a evidenciu vyšlých faktúr.

• Requisition-to-Invoice – tento modul sa venuje objednávkam spo- locnostiˇ smerom ku dodávatel’ovi a evidencii dodávatel’ských faktúr.

• Returns – tento modul sa venuje vráteniu tovaru od zákazníka, prí- padne vráteniu tovaru dodávatel’ovi.

25 3. ERP SYSTÉMIDEMPIERE

• Open Items – tento modul sa venuje daniam, otvoreným položkám, vekovej štruktúre pohl’adávok a záväzkov, platbám, párovaniu faktúr s platbami, výpisu z bankového úctu,ˇ plánovaniu financií, presunu financií. • Material Management – tento model sa venuje materiálovému ma- nažmentu (materiálové transakcie, detaily transakcií, presuny tovaru). IDempiere poskytuje globálne riadenie materiálov v spolocnosti.ˇ V i- Dempiere je možné manipulovat’ s materiálmi napriecˇ rôznymi spolocnost’amiˇ po celom svete. Z hl’adiska plánovania je možné spra- vovat’ tranzit materiálov. Z úctovníckehoˇ pohl’adu je možné poznat’ presné množstvo materiálu, aby sa zabezpecilaˇ rovnováha. • Project Management – tento modul sa venuje projektovému ma- nažmentu. Projekt je proces, ktorý môže zahrńat’ˇ niekol’ko fáz a krokov. Projekty môžu potrebovat’ zdroje z rôznych oblastí. Použitím tohoto modulu je možné sledovat’ stavy a pokrok rôznych projektov. • Performance Analysis – tento modul sa venuje analýze výkonnosti a nastaveniu pravidiel pre jej meranie. Je možné vidiet’ KPI(z an- glického Key Performance Indicator)3 podl’a roly prihláseného uží- vatel’a. Každé KPI je založené na meraní podl’a rovnice, ktorú si užívatel’ môže nastavit’. • Assets – tento modul sa venuje majetku spolocnostiˇ 4, nastavova- niu zhodnocovania a prehodnocovania aktív spolocnostiˇ (ocenovacieˇ metódy, kalkulácie), presuny, prírastky a úbytky aktív. • Manufacturing – tento modul sa venuje výrobe, používa jednodu- chý výrobný modul tzv. Manufacturing Light (pôvodne od spoloc-ˇ nosti Adaxa z Nového Zélandu/Austrálie). Ciel’om použitia tohoto modulu je zjednodušenie implementovania a riadenia za cenu obme- dzenej funkcionality. Manufacturing Light riadi vyúctovanieˇ mate- riálu tzv. BOM (z anglického Bill of Material) 5. V iDempiere sa

3. KPI – Kl’úcovéˇ ukazovatele výkonnosti sú základným prvkom systémov pre meranie výkonnosti a pomáhajú spolocnostiamˇ dosahovat’ stanovených ciel’ov. 4. Aktíva v úctovníctveˇ predstavujú všetko coˇ spolocnost’ˇ vlastní a môže jej to priniest’ ekonomický prospech. 5. BOM je dokument, ktorý zachycuje všetky komponenty (súcasti,ˇ materiál) použité pre výrobu urcitéhoˇ materiálu.

26 3. ERP SYSTÉMIDEMPIERE

nenachádza modul postavený na MRPII.

3.3 Typy užívatel’ov v iDempiere

V iDempiere sa nachádzajú dve základné skupiny užívatel’ov: • užívatel’ typu systém (System user) – v základnej inštalácii sa na- chádzajú 2 užívatelia tohoto typu (užívatel’ske meno/heslo: Syste- m/System; SuperUser/System)

• užívatel’ typu klient (Client user) – podskupina tohoto typu je užíva- tel’ s prístupom ku konkrétnym organizáciám. V základnej inštalá- cii sa nachádzajú 2 užívatelia tohoto typu (užívatel’ske meno/heslo: GardenAdmin/GardenAdmin; GardenUser/GardenUser) Typ užívatel’a je definovaný druhom priradenej role pri prihlasovaní do sys- tému. Užívatel’ typu systém má právo na prístup ku systémovým nastave- niam a konfigurácii modulu Application Dictionary. Užívatel’ typu systém spravuje systémové konfigurácie a zdiel’ané nastavenia pre všetkých klien- tov. Užívatel’ typu klient má práva prístupu ku klientským informáciám. V rámci jednotlivých klientských užívatel’ov je možné definovat’ niekol’ko organizácií, pre ktoré klient zdiel’a nastavenia systému. V rámci organizácií prebiehajú rôzne transakcie v systéme viazané na tieto organizácie. V iDempiere sa užívatelia dajú vytvárat’ v obrazovke User (Menu > System Administration > Security). Títo užívatelia sú potom prirad’ovaní ku konkrétnym rolám v obrazovke Role (Menu > System Administration > Security). V obrazovke Role je možné zvolit’ z viacerých užívatel’ských úrovní: • Klient (Client) – užívatel’ s rolou tohoto typu má prístup ku klientskym dátam.

• Organizácia (Organization) – užívatel’ s rolou tohoto typu má prístup ku deﬁnovanej/-ým organizácii/-ám v rámci klientskych dát.

• Klient + Organizácia (Client + Organization) – užívatel’ s touto rolou má prístup ku klientským dátam a konkrétnym organizáciám.

• Systém (System) – užívatel’ s rolou tohoto typu má prístup ku systé- movým dátam.

27 3. ERP SYSTÉMIDEMPIERE

Dáta (obrazovky, tabul’ky, formuláre, procesy, úlohy a pravidlá) v softvéri môžu byt’ prístupné na rôznych úrovniach: • Celkový prístup (All) • Klient (Client) • Klient a Organizácia (Client + Organization) • Systém (System) • Systém a Klient (System + Client) V rámci obrazovky Role je možné nastavit’ prístup ku konkrétnym or- ganizáciám, obrazovkám, procesom, formulárom, workﬂow, úlohám a dokumentom. Na obrázkoch D.1a D.2 v príloheD je možné vidiet’ obrazovky Role a User z ERP iDempiere. Základnými rolami v štandardnej inštalá- cii sú GardenWorld Admin (užívatelia: SuperUser, GardenAdmin), Gar- denWorld User (užívatelia: SuperUser, GardenAdmin, GardenUser), Sys- tem Administrator (užívatelia: System, SuperUser) a Web Service Execu- tion (užívatelia: SuperUser, WebService). Na obrázku 3.1 je možné vidiet’ hierarchiu typov užívatel’ov v iDempiere.

Systém

Klient A Klient B Klient N * * * Organizácia 1 Organizácia 1 Organizácia 1 Organizácia 2 Organizácia 2 Organizácia 2 Organizácia 3 Organizácia 3 Organizácia 3 ...... Organizácia M1 Organizácia M2 Organizácia M3

Obr. 3.1: Hierarchia užívatel’ských typov v ERP systéme iDempiere. Hviez- dickaˇ znázornujeˇ všetky organizácie v rámci jedného klienta.

28 3. ERP SYSTÉMIDEMPIERE 3.4 Workﬂow v iDempiere

Všetky dokumenty v iDempiere je možné použit’ vo workflow a sú l’ahko modifikovatel’né a rozšíritel’né (napr. požiadavka na nákup, objednávka. . . ). V iDempiere nájdeme 3 druhy workflow: 1. General – jedná sa o nastavovací workflow.

2. Document Process – jedná sa schval’ovací workﬂow (vid’. 2.2.5).

3. Document Value – jedná sa o monitorovací workflow (vid’. 2.2.5). Proces tvorby workflow je kvalitne vysvetlený v knihe [14]. Pre tvorbu workflow existuje v iDempiere obrazovka Workflow (Menu > System Ad- min > General Rules > Workflow). Táto obrazovka sa skladá z niekol’kých záložiek (Workflow, Node, Parameter, Transition, Condition, Access) zo- brazených na obrázku 3.2.

Obr. 3.2: Obrazovka „Workﬂow“ zo systému iDempiere so záložkami Workﬂow, Node, Parameter, Transition, Condition a Access.

1. Záložka Workﬂow – Na tejto záložke je možné vybrat’ typ work- ﬂow (Document Process, Document Value, General ). Dalejˇ je tu možné vybrat’ úrovenˇ prístupu k dátam (Data Access Level), ktorá

29 3. ERP SYSTÉMIDEMPIERE

definuje úrovenˇ potrebnú k tomu, aby bol tento workflow viditel’ný užívatel’ovi. Taktiež sa tu nastavuje prepojenie workflow s databá- zovou tabul’kou, ktorá súvisí, s konkrétnym dokumentom.

2. Záložka Access (prístup) – táto záložka deﬁnuje role, ktoré majú prístup ku workﬂow.

3. Záložka Node (uzol) – na tejto záložke sa deﬁnuje každý uzol vo workﬂow. Každému uzlu je možné priradit’ konkrétnu akciu (napr. zaslanie emailu).

4. Záložka Parameter (parameter) – na tejto záložke sa deﬁnujú para- metre pre vykonanie workﬂow.

5. Záložka Transition (prechod) – na tejto záložke sa definujú prechody, teda definuje sa poradie uzlov vo workflow.

6. Záložka Condition (podmienka) – na tejto záložke sa môžu deﬁno- vat’ volitel’né obmedzenia prechodov z jedného kroku do druhého kroku.

3.4.1 General workflow Tvorba General workflow je vel’mi jednoduchá a užívatel’sky prívetivá. Ge- neral workflow sa zameriava na poskytovanie jednotlivých inštrukcií (krok za krokom), ktoré vedú k vykonaniu úlohy. Táto postupnost’ cinnostíˇ obsahuje niekol’ko okien a/alebo formulárov a procesov, ktoré v každej z akti- vít/krokov zahrńajúˇ užívatel’a. V iDempiere sa typicky jedná o nastavenia rôznych modulov. Tento typ workflow je nápomocný pri nastavovaní apliká- cie, užívatel’ si tak nemusí pamätat’ jednotlivé obrazovky, ktoré sú potrebné pre nastavenie. Samotná tvorba workflow zacínaˇ vytvorením procesu v obrazovke Workflow pod systémovým užívatel’om (použitie systémového uží- vatel’a je výhodné pre dodatocnéˇ umiestnenie workflow do Menu). Po jeho vytvorení je potrebné pripojit’ tento workflow do menu aplikácie v obrazovke Menu (Menu > System Admin > General Rules > System Rules). Na to, aby bolo toto menu viditel’né, je treba nastavit’ prístupové práva a priradit’ role. Role a úrovenˇ prístupu k dátam je možné priradit’ v obrazovke Role Access Update (Menu > System Admin > General Rules > Security) pod klientským užívatel’om.

30 3. ERP SYSTÉMIDEMPIERE

3.4.2 Document Process workflow Základným spôsobom tvorby Document Process workflow je jeho konfigu- rovanie podl’a databázovej tabul’ky a pol’a v tabul’ke. Všetky dokumenty v rámci iDempiere možno modifikovat’ a rozširovat’. V obrazovke Table and Column6 (Menu > Application Dictionary) je možné priradit’ proces (podl’a mena a vyhl’adávacieho kl’úcaˇ procesu) ku konkrétnemu pol’u v da- tabázovej tabul’ke (napríklad pol’u reprezentujúcemu tlacidloˇ v niektorej z obrazoviek iDempiere – pole DocAction v tabul’ke C_Invoice) na záložke Column v poli Process. Tento proces musí byt’ definovaný v obrazovke Re- port & Process. V obrazovke Report & Process sa tento proces musí spojit’ s konkrétnym workflow, ktorý sa vytvorí v obrazovke Workflow. Pri stlaceníˇ tlacidlaˇ v dokumente [napr. tlacidloˇ Complete v obrazovke Invoice (Ven- dor) (Menu > Requisition-to-Invoice)], ktoré ma zadefinovaný proces, ku ktorému je priradený workflow sa tento workflow zacneˇ vykonávat’. Výber správnej databázovej tabul’ky pre tvorbu workflow je možné zistit’ v danej obrazovke dvojklikom na „Record Info“ v pravom dolnom rohu obrazovky na aktívnej záložke. Na obrázku 3.3 je možné vidiet’ obrazovku Invoice (Vendor) a jej Record Info (databázovú informáciu o aktuálnom zá- zname). Na obrázku je vidno, že informácia pre obrazovku Invoice (Vendor) sa ukladá do tabul’ky C_Invoice.

Obr. 3.3: Obrazovka „Invoice (Vendor)“ zo systému iDempiere. Po kliknutí na zvýraznenú cast’ˇ v pravom dolnom rohu sa objaví databázová informácia tzv. Record Info.

6. Obrazovka Table and Column je prístupná užívatel’om typu systém. Túto obrazovku je možné vidiet’ v príloheD, obrázok D.4

31 3. ERP SYSTÉMIDEMPIERE

Každá aktivita v rámci workflow bude definovaná ako uzol (node) na záložke Node. Štandardne definované Document Process workflow majú nasledujúcu štruktúru uzlov: • (Start) (Štart) – štatrovacia fáza, štartovací uzol. • (DocPrepare) (PrípravaDokumentu) – fáza spracovania c.ˇ 1. • (DocComplete) (DokoncenieDokumentu)ˇ – fáza spracovania c.ˇ 2. • (DocAuto) – automatický prechod s postupnost’ou uzlov Start → (DocPrepare) → (DocComplete), [prípadne (Start) → (DocAuto) s vyšším „Sequence“ císlom,ˇ ktoré urcujeˇ prioritu/poradie daného prechodu – nižšie císloˇ je viac prioritné], ktoré sa definujú na záložke Transition. Prechod sa definuje z uzla, ktorý je aktívne vybratý na záložke Node (rodicovskáˇ záložka ku záložke Transition) do uzla, ktorého si vyberieme zo zoznamu v poli Next Node. Ku každému uzlu sa dajú definovat’ nasledujúce akcie: • Wait (Sleep) (cakanie)ˇ – touto akciou je možné definovat’ periódu casuˇ (v minútach), predtým než systém vykoná nasledujúcu aktivitu. • User Choice (užívatel’ská vol’ba) – táto aktivita vyžaduje užívatel’- skú interakciu. Formát tejto akcie je bud’ Yes/No (Áno/Nie) alebo výber z možností zo zoznamu hodnôt, ktoré závisia na type pol’a. • User Action (užívatel’ská akcia) – táto aktivita vyžaduje užívatel’- skú interakciu. Pocasˇ spracovania tohto uzla je potrebné vykonat’ nasledujúce akcie: – Užívatel’ otvorí obrazovku (User Window) alebo formulár (User Form). – Užívatel’ vykoná nevyhnutné cinnostiˇ v tejto obrazovke alebo vo formulári. – Užívatel’ vypne okno alebo formulár, címˇ dokoncíˇ konkrétnu aktivitu. • Automatic processes (automatické procesy) – táto aktivita nevyža- duje užívatel’skú interakciu. Tento typ akcie vykoná akýkol’vek proces, report alebo akciu v dokumente (Schválenie, Odmietnutie, Ak- tivácia...), nastavenie premennej, poslanie emailu.

32 3. ERP SYSTÉMIDEMPIERE

Pri vytváraní uzla (Node) na záložke Node v obrazovke Workflow je možné nastavit’ políckoˇ „Workflow Responsible“. Nové položky je možné vytvorit’ v obrazovke Workflow Responsible (Menu > System Admin > Ge- neral Rules > Workflow). Workflow Responsible urcujeˇ zodpovednost’ za workflow. Urcujeˇ konkrétneho užívatel’a a umožnujeˇ definovat’ cesty pre vyhl’adanie aktuálneho užívatel’a. Existujú tri rôzne typy Workflow Res- ponsible:

• Human (clovek)ˇ – je možné deﬁnovat’ konkrétneho užívatel’a v poli User/Contact, ak tento užívatel’ nie je deﬁnovaný.

• Organization (organizácia) – osoba, ktorá je zaregistrovaná ako nad- riadený v obrazovke Organization (Menu > System > Admin > Or- ganization Rules) v poli Supervisor pre organizáciu.

• Role (rola) – všetci užívatelia s touto rolou sa stávajú zodpovední za túto aktivitu.

V iDempiere je možné nastavit’ dva a viac rôznych prechodov cez proces závisiac na podmienke na záložke Condition. Napríklad, (Štart) → (Príp- ravaDokumentu) → (DokoncenieDokumentu)ˇ pri podmienke, že daný dokument presahuje konkrétnu penažnúˇ hranicu musí íst’ na schválenie ku nadriadenému, by sa workﬂow zmenil na (Štart) → (PrípravaDokumentu) → (SchválenieDokumentu) → (DokoncenieDokumentu).ˇ

1. V tomto prípade by bolo potrebné vytvorit’ nový uzol (Schválenie- Dokumentu) na záložke Node s políckomˇ Action nastaveným na User Choice a políckomˇ Column nastaveným na IsApproved.

2. Na záložke Transition sa nastaví políckoˇ Next Node (nasledujúci uzol) na (DokoncenieDokumentu).ˇ Pre uzol (PrípravaDokumentu) sa nastaví nový d’alší prechod na Transition záložke s tým, že d’al- ším uzlom bude (SchválenieDokumentu). V poli Sequence je nutné nastavit’ nižšie císloˇ než je nastavené pre prechod (PrípravaDoku- mentu) → (DokoncenieDokumentu),ˇ aby tento prechod bol vyhod- notený ako prvý.

3. Pre tento nový prechod je nutné nastavit’ podmienku na záložke Condition. Na záložke Condition je nutné nastavit’ pole Sequence. Dalejˇ je nutné nastavit’ d’alšie polia podl’a konkrétneho workﬂow:

33 3. ERP SYSTÉMIDEMPIERE

logickú operáciu (And/Or – A/Alebo), spojenie s databázovým po- l’om v tabul’ke (Column), Operáciu (<, >, <=, >=, , !=, ||, =, sql) a hodnotu (Value) podl’a zákonov výrokovej logiky.

4. Týmto sa zabezpeciaˇ dva rôzne prechody cez proces s tým, že podmienka sa kontroluje v uzle (PrípravaDokumentu).

(a) Ak táto podmienka splnená nie je, pokracujeˇ sa uzlom (Dokon- cenieDokumentu).ˇ (b) Ak je táto podmienka splnená, pokracujeˇ sa uzlom (Schvále- nieDokumentu): i. V tomto bode je potrebné urcit’,ˇ kto v spolocnostiˇ má schval’ovacie práva. Na záložke Node bolo zvolené políckoˇ Action typu User Choice. V tomto prípade iDempiere hl’adá nadriadeného tohoto užívatel’a, ktorý je nastavený v obrazovke User (Menu > System Admin > General Rules > Security) na záložke Contact v poli Supervisor. ii. Ak nadriadený užívatel’a nie je nastavený, vyhl’adá sa nad- riadený pre celú organizáciu v obrazovke Organization na záložke Organization Info v poli Supervisor. iii. Ak neexistuje nadriadený pre túto organizáciu, vyhl’adá sa nadriadený rodicovskejˇ organizácie v obrazovke Organi- zation na záložke Organization Info v poli Supervisor. Po vyhl’adaní užívatel’a, ktorý má pravo schválit’ dokument, systém skontroluje role, ktoré sú s týmto užívatel’om asoci- ované v obrazovke User (Menu > System Admin > General Rules > Security) > záložka User Roles. Pre tieto role systém skontroluje hodnoty v obrazovke Role v zaškrtávacom políckuˇ Approve own Documents (ak je toto políckoˇ zaškrtnuté táto rola môže schval’ovat’ svoje dokumenty) a Approval Amount políckuˇ (toto pole predstavuje limit, pre ktorý daná rola môže schval’ovat’ dokument).

Workflow je možné sledovat’ v obrazovke Workflow Process (Menu > System Admin > General Rules > Workflow). V tejto obrazovke je taktiež možné zrušit’ už prebiehajúci workflow.

34 3. ERP SYSTÉMIDEMPIERE

3.4.3 Document Value workﬂow

Document Value workflow sa používa, ak existuje isté pravidlo alebo podmienka (napr. zrušenie objednávky), po ktorej sa prevedie urcitáˇ cinnost’ˇ (napr. poslanie upozornenia). Podobne ako Document Process workflow aj pre tento typ workflow je nutné jeho spojenie s konkrétnou databázovou tabul’kou. ERP iDempiere disponuje mechanizmom pre monitorovanie hodnoty, ktorá bola uložená alebo zmenená v databázovej tabul’ke. Táto aktivita môže byt’ vyvolaná bud’ užívatel’om (napr. užívatel’ klikne na tlacidloˇ uloženia) alebo interným systémom v iDempiere (napr. interný proces/kal- kulácia v iDempiere vloží alebo modifikuje nejakú hodnotu). Štandardne sa monitorujú obidve tieto podmienky. Tento typ procesu sa definuje rovna- kým spôsobom ako predošlý Document Process workflow. Pri zadefinovaní tohoto workflow v obrazovke Workflow sa vyberie typ Document Value a tabul’ka, s ktorou sa asociuje tento workflow. Dôležitou cast’ouˇ vytvorenia tohoto typu workflow je pole Document Value Logic (na záložke Workflow), kde sa definuje zaciatokˇ workflow vpísaním výrazu. Ak je táto hodnota pol’a pravdivá, spustí sa workflow proces pre konkrétny dokument. Pri vytváraní výrazu sa môže použit’ štandardná logika alebo logika vychádzajúca z dopytovacieho jazyka SQL (výrazom sa priradí prefix „SQL=“). SQL logika používa tvar napr. SQL=DOCSTATUS=’VO’ (tento výraz je pravdivý, ak databázové pole docstatus nadobudne hodnotu VO – voided (zrušená), pri- comˇ toto pole je z tabul’ky vpísanej v poli Table vo Workflow obrazovke). Príkladom rovnakého výrazu v štandardnej logike je @docstatus@= VO . Štandardná logika sa skladá z nasledujúcich prvkov:

1. Hodnoty dokumentu (Document Value) – môže sa použit’ konkrétne políckoˇ z tabul’ky(napr. docstatus), hodnota z kontextu iDempiere (napr. #AD_Org_Name) alebo konštantná hodnota (napr. VO). Kon- krétna hodnota sa obalí medzi 2 znaky @(napr. @#AD_Org_Name@). Konštantná hodnota sa neobal’uje do znakov @.

2. Operátora (Operator): ! (nerovná sa), = (rovná sa), ^ (nerovná sa), > (väcšieˇ než), < (menšie než), | (logická spojka alebo), & (logická spojka a).

3. Vyhodnocovacej hodnoty (Evaluation Value) – táto hodnota používa rovnaké typy tvarov ako hodnota dokumentu.

35 3. ERP SYSTÉMIDEMPIERE

Vel’mi castouˇ požiadavkou je odoslanie notiﬁkácie na email, ked nastane konkrétna situácia v systéme (napr. zrušenie objednávky). Email sa nastavuje v obrazovke Client (Menu > System Admin > Client Rules) na Client záložke. Nastavenie je závislé od konﬁgurácie použitého emailového servera. Emailovú šablónu je možné nastavit’ v obrazovke Mail Template (Menu > Partner Relations > Mail Template). Snímky týchto obrazoviek je možné nájst’ v príloheD, obrázky D.3a 4.6.

3.4.4 Nevýhody iDempiere workﬂow Medzi nevýhody iDempiere workﬂow by sa dali zaradit’:

• Workﬂow je asociovaný s jednou konkrétnou tabul’kou, nie je možné asociovat’ ho s viacerými databazovými tabul’kami.

• Neexistuje žiadne jednoduché grafické užívatel’ské rozhranie typu „potiahni a pusti“ (z anglického drag and drop) pre tvorbu workflow. Existuje tu obrazovka Workflow Editor, ale nie je vel’mi užívatel’ský prívetivá ani prepracovaný.

• Výber užívatel’a, ktorý schval’uje dokument je závislý na pravidlách pevne daných systémom. Nie je možná ﬂexibilita.

3.4.5 Výhody iDempiere workﬂow Medzi výhody iDempiere workﬂow sa dá zaradit’:

• Možnost’ vytvorenia workﬂow typu General, ktorý sa používa pre- važne na nastavenie systému zvyšuje užívatel’skú prívetivost’ sys- tému. Užívatel’ si nemusí pamätat’, coˇ všetko a kde je potrebné nastavit’, ale jednoducho môže použit’ workﬂow ako sprievodcu.

• Jednoduchost’, vytvorenie workﬂow je relatívne užívatel’sky príve- tivé. Netreba mat’ tol’ko technických zrucností,ˇ stacíˇ sa vediet’ orien- tovat’ v aplikácii. Nie je potrebné zasahovat’ do zdrojového kódu a nikde mimo užívatel’ského rozhrania aplikácie pri vytváraní work- ﬂow. Jediná technickejšia cast’ˇ je potreba vediet’ základy výroko- vej logiky prípadne tvorby dotazov prebratej z dopytovacieho jazyka SQL.

36 3. ERP SYSTÉMIDEMPIERE 3.5 Prehl’ad workﬂow v konkurencnýchˇ ERP systémoch

Táto cast’ˇ sa venuje všeobecnému prehl’adu, porovnaniu možností tvorby a využitia workflow v niektorých najznámejších konkurencnýchˇ ERP sys- témoch s otvoreným zdrojovým kódom. Použitie rôznych typov workflow engine sa líši v závislosti od jednotlivých ERP systémov. Táto podkapitola vyzdvihuje a porovnáva niektoré crtyˇ workflow z iných ERP systémov. In- formácie z tejto kapitoly pochádzajú z užívatel’ských a technických doku- mentácií ku týmto ERP systémom.

3.5.1 OpenERP V OpenERP existujú dve možnosti modelovania firemných procesov – workflow a užívatel’ské procesy. Workflow v OpenERP sa dá rôzne prispôsobovat’ podnikovej logike a toku úloh. Vd’aka workflow je OpenERP flexibilný a umožnujeˇ l’ahkú podporu a zmenu podl’a potrieb spolocnostiˇ bez toho, aby bolo nutné upra- vovat’ OpenERP programovo (podobne ako je tomu pri iDempiere). Work- flow je používaný pre urcenieˇ objektu, ktorý by mal vykonat’ konkrétnu akciu v danom momente. Jedná sa najmä o definovanie technických procesov, ktoré sú reprezentované dokumentom. Zmena workflow má priamy dopad na správanie softvéru vzhl’adom ku reakciám na akcie užívatel’a. Vo workflow je možné spracovat’ rôzne výnimky. V OpenERP je možné priradit’ signály, triggery 7 a podmienky ku jednotlivým prechodom. Takisto sa môže workflow definovat’ cez XML súbory. Oproti iDempiere workflow je tento spôsob menej užívatel’sky prívetivý, pretože operuje na nižšej úrovni (xml súbory vs. užívatel’ské rozhranie) [19]. Na oplátku však používatel’ iDempiere musí poznat’ asponˇ základy jazyka SQL (prípadne štandardnej výrokovej logiky) a ukladania dát v databáze, takže základné technické zna- losti sa používajú v oboch systémoch. Fakt, že v systéme OpenERP je nutné vytvárat’ externé XML súbory stavia iDempiere do pozície lepšej využitel’- nosti v cloudovom riešení. Okrem workflow sa v OpenERP nachádzajú aj takzvané užívatel’ské procesy (User Processes). Tieto užívatel’ské procesy reprezentujú workflow a dokumenty napriecˇ celou spolocnost’ou.ˇ Koncoví užívatelia pomocou týchto procesov vedia, kde bude konkrétna úloha realizovaná a tým pádom

7. Trigger deﬁnuje cinnosti,ˇ ktoré sa majú previest’ v prípade deﬁnovanej udalosti (napr. vloženie, zmazanie záznamu v databázovej tabul’ke) nad databázovou tabul’kou [18]. 37 3. ERP SYSTÉMIDEMPIERE

sa dosahuje komplexné spracovanie úlohy. Zmena v užívatel’skom procese nebude mat’ žiaden efekt na softvér, ale ukáže užívatel’ovi iný spôsob spracovania daného problému. Užívatel’ské procesy sú pripojené ku technickým workflow. Ak je workflow modifikovaný v softvéri, zmeny budu viditel’né priamo v užívatel’- ských procesoch, ktoré sú založené na modifikovaných dokumentoch. Ak sa modifikujú konkrétne prechody vo workflow, tak tieto prechody budú zo- brazené v procesoch, ktoré korešpondujú s modifikovaným dokumentom. OpenERP poskytuje integrovaný workflow editor a editor pre užívatel’- ské procesy. To znamená, že workflow a užívatel’ské procesy môžu byt’ modifikované priamo cez užívatel’ské rozhranie. Užívatel’ské procesy je možno používat’ priamo z obrazoviek v OpenERP. V každom dokumente môže byt’ zadefinovaných niekol’ko procesov, z ktorých si užívatel’ môže vybrat’. Užívatel’ské procesy zahrńajúˇ funkcionality, ktoré majú aj nemajú dopad na samotný softvér. Užívatel’ské procesy sú prepojené s workflow, ak sa urobí zmena vo workflow odrazí sa to v užívatel’ských procesoch, ktoré používajú rovnaký dokument ako daný workflow modifikoval. Na definovanie užívatel’ských procesov existuje grafické rozhranie, no používajú sa tam objekty a výrazy z programovacieho jazyka Python [19]. Príkladom tohoto typu je spracovanie predajnej objednávky, cez jej dorucenieˇ zákazníkovi až po jej fakturovanie. Užívatel’ské procesy ciastoˇ cneˇ pripomínajú workflow typu General v ERP iDempiere. OpenERP má túto funkcionalitu viac pre- pracovanú (na úkor toho, že práca s workflow je zložitejšia), ked’že uží- vatel’ské procesy sú spojené priamo s workflow. Na rozdiel od iDempiere, OpenERP taktiež ponúka kvalitný integrovaný grafický editor pre workflow aj pre užívatel’ské procesy.

3.5.2 ERP5 V ERP5 sa nachádzajú klasické workflow a interaktívne workflow. Klasické workflow v ERP5 sú založené na DCWorkflow 8. DCWorflow je urcenýˇ pre podnikové procesy, ktoré vyhovujú nasledujúcim podmienkam: 1. Existuje jeden objekt v systéme, ktorý predstavuje úlohu. 2. Každý takýto objekt rovnakého typu ide cez ten istý workflow.

8. Dokumentáciu k DCWorkﬂow je možné najst’ na http://old.zope.org/ Members/hathawsh/DCWorkflow_docs/default/DCWorkflow_doc.pdf.

38 3. ERP SYSTÉMIDEMPIERE

3. Úlohy sú prirad’ované rolám, nie konkrétnym zamestnancom.

Na rozdiel od ERP5 je prirad’ovanie úloh v iDempiere riadené pravidlami popísanými v 3.4.2. V iDempiere workflow schval’uje užívatel’, nadriadený používatel’a, nadriadený organizácie alebo rodicovskejˇ organizácie zaležiac na pravidlách a nastavení systému. Pre definíciu workflow sa používa uží- vatel’ské rozhranie ako je to aj v iDempiere. No pre zložitejšie akcie ako sú napríklad zaslanie emailu alebo vyvolanie iného workflow pri špecifických transakciách je nutné napísat’ skript, najcastejšieˇ v Pythone. Tento skript sa nachádza v priecinkuˇ s konkrétnym workflow. Tento prístup je menej užívatel’sky prívetivý vzhl’adom ku prístupu použitému v iDempiere (tento prístup môže byt’ limitujúci a pre niektoré workflow je tak ciˇ tak potrebné siahnut’ na kód aplikácie), ale ponúka väcšiuˇ flexibilitu.

3.5.3 Apache OFBix/opentaps V ERP Apache OFBix/opentaps sa tvorcovia párkrát snažili zaviest’ Work- ﬂow Engine, ale nakoniec to vzdali. Posledným pokusom bolo zavedenie Enhydra Shark, ktoré sa vôbec nepoužívalo. Ako bolo spomenuté v 2.2.4, niekedy nie je jednoduché implementovat’ funkcionalitu workﬂow do ERP a Apache OFBix/opentaps túto myšlienku potvrdzuje. Momentálne toto ERP používa tzv. udalost’ami riadenú architektúru (Event Driven Architecture). Udalost’ami riadená architektúra je prístup k architektúre softvérových sys- témov pomocou vytvárania, detekcie, spracovania reakcií na udalosti [20].

3.5.4 Neogia ERP systém Neogia má integrovaný workflow engine Enhydra Shark, ktorý sa pri predošlom ERP systéme Apache OFBix/opentaps neujal. Enhydra Shark pozostáva z XPLD (XML Process Definition Language) 9 a Java Workflow Server. Definície procesov sú založené na jazyku XPLD a môžu byt’ jednoducho vytvorené použítím grafického XPLD a BPMN (Business Process Model and Notation)10 editora. Jedná sa o relatívne robustný ná- stroj, ku ktorému existuje rozsiahla technická a užívatel’ská dokumentácia

9. XPLD je štandardizovaný formát pre výmenu deﬁnície podnikových procesov/workflow medzi rôznymi modelovacími nástrojmi. 10. Business Process Model and Notation je súbor princípov a pravidiel, ktorý slúži pre graﬁcké znázornovanieˇ podnikových procesov pomocou procesných diagramov.

39 3. ERP SYSTÉMIDEMPIERE

[21][22]. Oproti iDempiere tento nástroj obsahuje prepracovaný graﬁcký editor, zárovenˇ ale ako aj u OpenERP je nutná znalost’ XML.

3.6 Systém iDempiere v cloude

V súcasnostiˇ virtualizácia11 (VirtualBox, VMWare...) napomáha hostovaniu softvéru v cloude. Vd’aka virtualizácii iDempiere môže priniest’ nasledu- júce výhody [17]: • Možnost’ jednoduchej opravy pri inštalácii – pri chybe inštalácie je vel’mi jednoduché zacat’ˇ odznova.

• Možnost’ vytvárat’ kópie/snímky serveru za úcelomˇ zálohovania.

• Kópie/snímky systému je jednoduché zdiel’at’ s ostatnými.

• Možnost’ používat’ niekol’ko virtuálnych serverov na jednom fyzickom serveri, tým pádom je možné používat’ niekol’ko kópií iDem- piere.

• Možnost’ použitia virtualizacnýchˇ prostriedkov, ktoré sú zadarmo tak ako iDempiere (napr. VirtualBox) bez žiadnych d’alších ﬁnanc-ˇ ných nákladov pre spolocnost’.ˇ

• Virtualizácia pomáha administrácii viacerých prostredí iDempiere. Viac prostredí je dôležitých pre podporu auditu – ak spolocnost’ˇ disponuje testovacou verziou, zamestnanci si môžu skúšat’ firemné procesy v aplikácii na „necisto“.ˇ Audit pomáha eliminovat’ chyby zamestnancov v systéme. Systém iDempiere je možné virtualizovat’ a poskytovat’ siet’ovo cez internet. Systém iDempiere je postavený na štandardnej architektúre klient- server, používa štandardné siet’ové protokoly a naviac okrem inštalácie klienta poskytuje aj webové rozhranie . Ako už bolo spomenuté v kapitole 2.4, jednou z nevýhod poskytovania softvéru ako služby v cloude je jeho ob- tiažna modifikácia. V obore ERP systémov je tento bod obzvlášt’ dôležitý, pretože každá firma disponuje inými procesmi v rámci svojho podnikania,

11. Virtualizácia je proces, kedy je fyzický prostriedok v podniku nahrádzaný softvérovou vrstvou. [23]

40 3. ERP SYSTÉMIDEMPIERE

inou vel’kost’ou, atd’. ERP systém musí byt’ upravený na mieru konkrét- nej spolocnosti.ˇ Hlavne ak sa jedná o väcšieˇ spolocnostiˇ alebo spolocnosti,ˇ ktoré sú dlho na trhu, kde je takmer nemožné, aby sa spolocnost’ˇ prispô- sobovala systému (preto sa systém musí prispôsobit’ spolocnosti).ˇ Systém iDempiere však disponuje modulom Application Dictionary (vid’. 3.2), kde je možné softvér konfigurovat’ bez zásahu do kódu. Po konfigurácii apliká- cie v tomto module je možné vidiet’ zmeny ihned’ bez akejkol’vek kompilá- cie kódu [24][25]. Tvorba workflow je riadená priamo z aplikácie z modulov „System Admin“ a „Application Dictionary“. Nevyžaduje žiadnu úp- ravu kódu. Spolocnosti,ˇ ktoré potrebujú vytvárat’ svoje vlastné workflow, ich môžu vytvárat’ priamo v aplikácii cez klienta (na rozdiel od iných ERP systémov s otvoreným zdrojovým kódom, ktoré ponúkajú tvorbu workflow). Úprava kódu by bola potrebná len pri rozširovaní štandardne poskytovanej funkcionality workflow (napr. posielanie vytvoreného reportu cez workflow na e-mail okrem už štandardne podporovaných). Za d’alšiu nevýhodu SaaS sa považuje zdiel’anie softvéru, pretože zni- žuje možnost’ konfigurácie systému. Pri virtualizácii je možné používat’ niekol’ko virtuálnych serverov na jednom fyzickom serveri, coˇ by mohlo byt’ výhodné pre poskytovanie iDempiere ako SaaS v cloude aj pre viacero spolocností.ˇ Ak by každej spolocnostiˇ bola vyhradená inštancia iDempiere serveru, problematickost’ modifikácie systému by sa znížila na minimum. Naviac iDempiere poskytuje možnost’ správy a použitia systému viacerými oddelenými klientmi. Dalšouˇ nevýhodou SaaS je problematickost’ prechodu na novšiu verziu, ktorá sa zvyšuje vtedy, ak má systém mnoho modifikácií. Pri ERP systé- moch je táto nevýhoda rovnako vel’ká pri poskytovaní softvéru ako služby ako aj pri bežnom poskytovaní, preto nie je relevantnou. Ostatné spomenuté nevýhody nie sú relevantné, pretože k ním dochádza pri poskytovaní takmer akéhokol’vek druhu softvéru. Zárovenˇ ku týmto nevýhodám existujú štan- dardné riešenia, ktoré tieto nevýhody eliminujú a mohli by byt’ použité pri poskytovaní iDempiere ako SaaS v cloude. Za predpokladu, že každá spolocnost’ˇ bude používat’ svoju vlastnú in- štanciu serveru (z dôvodu potrebných modifikácií iDempiere pre každú spolocnost’ˇ individuálne) dá sa konštatovat’, že systém iDempiere je ideálny pre poskytovanie softvéru ako služby v privátnom cloude (vid’ 2.3.3). Tento cloud by musel sp´lnat’ˇ svoje základné vlastnosti (vid’. 2.3.2). Systém iDem- piere je ideálny pre poskytovanie softvéru ako služby z toho dôvodu, že zá- kazníci aj poskytovatel’ by mohli profitovat’ z väcšinyˇ výhod tohoto mo-

41 3. ERP SYSTÉMIDEMPIERE delu (vid’ 2.4.2). Zákazník by sa nemusel starat’ o administráciu tohoto softvéru ani o výpoctovéˇ zdroje a umiestnenie týchto zdrojov. Zákazník by nemusel platit’ za štandard tohoto softvéru, ked’že sa jedná o softvér s ot- voreným zdrojovým kódom. Z tohoto dôvodu by pociatoˇ cnéˇ náklady boli menšie ako pri proprietárnom softvéri. Poskytovatel’ by mohol plnit’ fun- kciu konzultanta a dopomáhat’ s modifikáciami softvéru, ktoré sa nenachá- dzajú v štandardnej verzii. Poskytovatel’ by taktiež disponoval výpoctovýmiˇ zdrojmi a bol by zodpovedný za administráciu. Za tieto vymenované služby by bol platený zákazníkom. Ak by chcel zákazník tieto náklady eliminovat’ staciloˇ by túto službu zrušit’ a preniest’ si tento softvér ku „sebe“. Prenos modifikácií kódu by pravdepodobne musel byt’ riešený zmluvne, teda by zá- ležal na dohode jednotlivých strán. Treba brat’ taktiež na vedomie, že cloud môže byt’ prevádzkovaný aj samotnou spolocnost’ou.ˇ V tejto variante by spolocnost’ˇ musela disponovat’ l’udskými zdrojmi a kapitálom pre nákup potrebných výpoctovýchˇ zdrojov. Virtualizácia systému iDempiere (použitie viacerých inštancií serveru pre rôznych zákazníkov) a vlastný systém iDempiere (modifikácia priamo cez klientské rozhranie) ponúka nástroje pre elimináciu nevýhod modelu SaaS. Tento prístup je vhodný hlavne pre podniky menšej až strednej vel’- kosti (SME) z dôvodu úprav softvéru pre spolocnostiˇ – väcšiaˇ spolocnost’ˇ potrebuje rozsiahlejšie riešenie a väcšiuˇ flexibilitu.

42 4 Modelové príklady workﬂow

Táto kapitola sa venuje modelovým príkladom workflow, ktoré boli zreali- zované v ERP iDempiere 2.0 (alpha). Ked’že sa v iDempiere nachádzajú tri základné druhy workflow (vid’. 3.4) v tejto castiˇ budu navrhnuté tri rôzne modelové príklady ako demonštrácia každého typu workflow. Tieto typy boli detailne popísané v kapitole3. Modelové príklady používajú anglické názvoslovie, teda sú v jazyku použitej aplikácie.

4.1 Modelový príklad I – Nastavenie produktu typu náklad (General workﬂow)

Pre workflow typu General bol zrealizovaný modelový príklad „nastavenie produktu typu náklad“ (Expense Product Type Setup). Typicky sa jedná o položky ako cestovné náklady, preprava tovaru, poistenie nákladu, skladovanie, režijné náklady a podobne, ktoré sa v systéme nastavia ako špeciálny produkt a môžu sa tým pádom spracovat’ a fakturovat’ ako bežná položka objednávky. Tento workflow bol vytvorený pod systémovým užívatel’om System a bol nazvaný „Expense Type Product Setup“. Na záložke Workflow bolo nasta- vené pole Data Access Level na hodnotu Client + Organization. Tento workflow sa skladá zo siedmych uzlov s prechodom (Tax Category) → (Product Category) → (Unit of Measure) → (Price List) → (Accounting Schema) → (Expense Type) → (Product). Každý uzol má na záložke Node nasta- vené pole Action na hodnotu User Window a pole Window na konkrétne meno danej obrazovky. Workflow je na záložke Access nastavený pre rolu SystemAdministrator. Tento workflow bol pridaný do cesty Menu > Partner Relations > Ser- vice pomocou obrazovky Menu pod systémovým užívatel’om System (vid’. obrázok 4.1). Po pridaní workflow do Menu je nutné použit’ obrazovku Role Access Update a upravit’ prístup k tomuto workflow pre role. Po kliknutí na tento workflow pod klientskym užívatel’om v Menu sa zobrazí tento workflow na Workflow záložke hlavného okna aplikácie tak ako je to možné vidiet’ na obrázku 4.2. Užívatel’ postupne musí prejst’ všetky odporúcanéˇ obrazovky a prezriet’ si konkrétne vytvorené záznamy, prípadne vytvorit’ nové záznamy, ktoré použije v konecnejˇ fáze nastavenia produktu.

43 4. MODELOVÉ PRÍKLADY WORKFLOW

Obr. 4.1: Pridanie workﬂow Expense Type Product Setup do Menu apliká- cie.

Vysvetlenie jednotlivých obrazoviek:

1. (Tax Category) – Obrazovka Tax Category (danováˇ kategória) slúži k vytvoreniu a spravovaniu danovejˇ kategórie. Každý produkt je aso- ciovaný s danovouˇ kategóriou, ktorá ul’ahcujeˇ reakciu na zmeny da- novejˇ sadzby.

2. (Product Category) – Obrazovka Product Category (kategória produktu) umožnujeˇ deﬁnovat’ rôzne skupiny výrobkov. Tieto skupiny môžu byt’ použité pri vytváraní cenníkov, ktoré služia na vytvorenie skupín produktov s podobnými úctovnýmiˇ parametrami.

3. (Unit of Measure) – Obrazovka Unit of Measure (merná jednotka) sa používa na deﬁnovanie nepenažnýchˇ merných jednotiek. Dalejˇ sa tu nastavuje možnost’ prevodu medzi jednotlivými jednotkami a spô- sob akým má byt’ tento prevod vykonaný.

4. (Price List) – Obrazovka Price List (cenník) slúži na vytvorenie zoznamu cien pre konkrétnych partnerov.

5. (Accounting Schema) – Obrazovka Accounting Schema (úctovnáˇ schéma) deﬁnuje úctovnéˇ metódy a prvky, ktoré vytvárajú štruktúru úctu.ˇ

44 4. MODELOVÉ PRÍKLADY WORKFLOW

6. (Expense Type) – V obrazovke Expense Type (typ nákladu) sa deﬁ- nuje nový typ nákladu, príslušný produkt, jeho cena a úctovnáˇ schéma. V podstate sa tu deﬁnujú všetky predošlé položky.

7. (Product) – Obrazovka Product (produkt) slúži na zadeﬁnovanie no- vého produktu. V tomto bode je už produkt typu náklad vytvorený. V tejto obrazovke ho musí uživatel’ nájst’ a doplnit’ potrebné infor- mácie.

Obr. 4.2: General workﬂow pre nastavenie produktu typu výdaj so svojimi uzlami a prechodmi. Po kliknutí na jednotlivé uzly sa zobrazí príslušná obrazovka aplikácie.

4.1.1 Zaradenie a zhodnotenie modelového príkladu I Tento workﬂow sa nedá 100 % zaradit’ ani do jednej kategórie podl’a charakteru procesu. Nejedná sa o produkcnýˇ workﬂow, pretože nepodporuje

45 4. MODELOVÉ PRÍKLADY WORKFLOW

hlavné podnikové procesy ani nie je zložitý. Nedá sa zaradit’ ani do kategó- rie kolaboratívneho workflow pretože nevyžaduje spoluprácu a stacíˇ aby ho použil jeden užívatel’. Nedá sa povedat’, že by tento workflow patril do ka- tegórie Ad-hoc pretože sa netýka neštandardizovanej situácie. Najbližšie by sa hodil do kategórie administratívny workflow pretože sp´lnaˇ požiadavky na jednoduchost’, opakovatel’nost’ a štruktúrovanost’, ale nejedná sa o workflow, ktorý by sa využíval v každodennej rutine. Skôr sa jedná o workflow, ktorý uživatel’ potrebuje použit’ raz za isté obdobie. Vd’aka tomuto workflow si môže pripomenút’ kroky, ktoré sú potrebné na nastavenie produktu typu náklad. Podl’a orientácie procesu, technologickej architektúry a použitia v podnikovej praxi sa nedá zaradit’ ani do jednej z kategórií. Z tohoto je možné konštatovat’, že workflow typu General nie je klasický workflow, ktorý by sa bežne vyskytoval v ERP alebo WfM systémoch. Jedná sa o ojedinelú a jed- noduchú myšlienku, ktorá môže byt’ vel’mi nápomocná v praxi z dôvodu toho, že bežný užívatel’ si nemusí pamätat’ jednotlivé kroky na nastavenie rôznych funkcionalít systému. Užívatel’ nemusí strácat’ casˇ hl’adaním do- kumentácie, prehl’adávaním obrazoviek v systéme aby nastavil jednoduchú crtu.ˇ Stacíˇ mu vyhl’adat’ odpovedajúci workflow, ktorý je bud’ zadefino- vaný v štandardnej verzii alebo si daná spolocnost’ˇ môže vytvorit’ vlastný General workflow podl’a svojich potrieb a tieto sa môžu potom globálne vy- užívat’. Týmto tento workflow nahrádza dokumentáciu systému a dovol’uje zadefinovat’ nastavenia tých castíˇ systému, ktoré konkrétna spolocnost’ˇ re- álne používa (ak berieme do úvahy, že spolocnost’ˇ nemusí využívat’ všetky castiˇ systému).

4.2 Modelový príklad II – Schval’ovanie faktúr (Document Process)

Modelovým príkladom II je schval’ovanie dodávatel’ských faktúr s hodnotou nad $200. Došlá alebo dodávatel’ská faktúra obsahuje císloˇ objednávky, aby bolo možné overit’ jej správnost’. Skontroluje sa vecná správnost’. Zis- t’uje sa ciˇ je fakturované to coˇ sa objednalo, ciˇ sa cena objednávky zhoduje s cenou na faktúre, overí sa množstvo objednaného materiálu. Faktúra prejde danovouˇ kontrolou a zist’uje sa, ciˇ obsahuje všetky náležitosti, ktoré má ob- sahovat’ z danovéhoˇ a úctovnéhoˇ hl’adiska. Ak sa pri kontrole správnosti zistí, že niecoˇ nie je v poriadku, tak chyba mohla nastat’ pri vložení faktúry

46 4. MODELOVÉ PRÍKLADY WORKFLOW

do systému a v tomto prípade je nutné faktúru vrátit’ zamestnancovi, ktorý ju zadal do systému, aby ju opravil. Druhou možnost’ou je, že chyba nastala na dodávatel’skej strane a je nutné faktúru vrátit’ dodávatel’ovi a táto faktúra sa v systéme stornuje. Tento workflow je typu Document Process. V najnovšej verzii iDem- piere sa nachádza mnoho workflow typu Document Process, ktoré sú spo- jené s väcšinouˇ základných tabuliek/dokumentov. Modelovým príkladom teda bude úprava už existujúceho workflow, ktorý sa nazýva Process_Invoice. Pôvodná verzia tohoto workflow disponuje klasickou štruktúrou uzlov a prechodov v iDempiere. Táto štruktúra bola popísaná v sekcii 3.4.2. Do štan- dardného priechodu uzlov Start → (DocPrepare) → (DocComplete) bol pri- daný uzol (DocApproval) medzi uzly (DocPrepare) a (DocComplete). Tento uzol má pole Action nastavené na User Choice a pole Column je nastavené na IsApproved_Approved. Tento workflow má teda 2 rôzne prechody od uzla (DocPrepare): 1. Štandardný prechod uzlami – (Start) → (DocPrepare) → (DocCom- plete) (pre prechod (DocPrepare) → (DocComplete) bolo císloˇ Se- quence prestavené na 100).

2. Upravený prechod uzlami – (Start) → (DocPrepare) → (DocAppro- val) → (DocComplete) (pre prechod (DocPrepare) → (DocAppro- val) bolo císloˇ Sequence nastavené na 10). Pre prechod (DocPrepare) → (DocApproval) bola nastavená podmienka na záložke Condition (postupnost’ polí Column Operation Value):

• TotalLines_TotalLines > 200, táto podmienka znamená, že ak suma na došlej faktúre presahuje hodnotu 200, workﬂow zvolí ako d’alší uzol (DocApproval), ak je táto hodnota nižšia pokra- cujeˇ sa uzlom (DocComplete). • IsSOTrx_Sales Transaction = N, táto podmienka znamená, že sa nebude jednat’ o vyšlú faktúru – kontrola správnosti nastane iba pri dodávatel’ských faktúrach (Obrazovka Invoice (Vendor)).

Predpokladajme, že užívatel’ zadal faktúru v obrazovke Invoice (Ven- dor) a táto faktúra prevyšuje hodnotu $200. V tomto momente sa work- ﬂow dostane do uzla (DocApproval) a bude sa snažit’ nájst’ osobu, ktorá má právo schválit’ tento workﬂow ako to bolo popísané v 3.4.2. Ak tento užívatel’ nemá právo na schval’ovanie alebo má právo len na schval’ovanie

47 4. MODELOVÉ PRÍKLADY WORKFLOW nižších súm systém zacneˇ hl’adat’ jeho „supervízora“. Po stlaceníˇ tlacidlaˇ Complete sa táto faktúra nedokoncí,ˇ ale pole Document Status sa zmení na hodnotu „In Progress“, ktorá znací,ˇ že túto faktúru je nutné schválit’. Užíva- tel’ s právami na schválenie tejto faktúry si v obrazovke Workflow Activities (Menu > System Admin > Workflow) nájde túto faktúru v zozname a môže ju bud’ schválit’ alebo zamietnut’. Pri schválení sa táto faktúra automaticky dokoncíˇ (bude v stave Completed). Na obrázku 4.3 je možné vidiet’ obrazovku Workflow Activities, v ktorej užívatel’ so schval’ovacími právami vie schválit’ faktúru tým, že vyplní pole Answer hodnotou Yes (prípadne túto faktúru zamietne hodnotou No). Ak je faktúra zamietnutá pole Document Status sa zmení na Not Approved a užívatel’ môže bud’ túto faktúru zrušit’ alebo opravit’ a poslat’ spät’ na prehodnotenie.

Obr. 4.3: Na obrázku je možné vidiet’ obrazovku Workﬂow Activities, kde užívatel’ s právami môže schválit’ faktúru.

Na obrázku 4.4 je možné vidiet’ obrazovku, ktorá sa zobrazí po kliknutí na tlacítkoˇ Complete v obrazovke Invoice (Vendor), ked’ sa tento dokument nachádza v statuse In Progress. Táto obrazovka ukazuje, že pre aktívny dokument existuje workﬂow záznam, ktorý musí byt’ schválený. Na obrázku 4.5 sa nachádza upravený workﬂow z tohoto modelového príkladu.

48 4. MODELOVÉ PRÍKLADY WORKFLOW

Obr. 4.4: Na obrázku je možné vidiet’ obrazovku, ktorá indikuje, že aktívny záznam v obrazovke Invoice (Vendor) má workﬂow záznam, ktorý musí byt’ schválený nadriadeným.

Obr. 4.5: Na obrázku je možné vidiet’ upravený workﬂow Process_Invoice v obrazovke Workﬂow Editor.

49 4. MODELOVÉ PRÍKLADY WORKFLOW

4.2.1 Zaradenie a zhodnotenie modelového príkladu II Z hl’adiska charakteru procesu sa jedná o administratívny workflow, pretože sa využíva pri vykonávaní každodenných úloh, zárovenˇ splnujeˇ jednoduchost’, opakovatel’nost’ a štruktúrovanost’. Z pohl’adu orientácie procesov sa jedná ciastoˇ cneˇ o proces orientovaný na seba, ale vyžaduje zásah užíva- tel’a. Z hl’adiska technologickej architektúry sa jedná o workflow založený na dokumentoch. Tento workflow je riadený predstavou o smerovaní dokumentov a schopnosti komunikácie. Podl’a použitia v podnikovej praxi ide o schval’ovací workflow, pretože slúži ku kompletnému spracovaniu kon- krétneho dokumentu a jeho toku v spolocnosti.ˇ

50 4. MODELOVÉ PRÍKLADY WORKFLOW 4.3 Modelový príklad III – Zaslanie e-mailoveho potvrdenia (Document Value workﬂow)

Modelovým príkladom III je zaslanie e-mailoveho potvrdenia a reportu po dokonceníˇ objednávky typu Standard Order 1. Jedná sa o workflow typu Document Value. Tento workflow bol nazvaný Send Order Confirmation. Workflow Send Order Confirmation bol vytvorený pod klientským užívate- l’om GardenAdmin. Nastavenia v obrazovke Workflow:

1. Záložka Workﬂow – na tejto záložke bolo nutné nastavit’:

• Pole Workﬂow Type na hodnotu Document Value. • Pole Table na hodnotu C_Order_Order. • Pole Document Value Logic na hodnotu @docstatus@=CO (@docstatus@=CO znamená, že workﬂow sa spustí ak sa status dokumentu rovná Completed, teda objednávka je dokon- cená).ˇ • Pole Data Access Level na hodnotu Client + Organization.

2. Záložka Node – na tejto záložke boli vytvorené nasledujúce uzly:

• (Start) – Pociatoˇ cnýˇ uzol s pol’om Action nastaveným na hodnotu Wait (Sleep). • (SendConﬁrmation) – uzol v ktorom sa vykoná zaslanie e-mailu s pol’om Action nastaveným na hodnotu Email, pol’om Email Recepient nastaveným na Document Business Partner (email sa pošle kontaktu partnera uvedeného na objednávke) a pol’om Mail Template nastaveným na emailový vzor Order Conﬁrma- tion.

1. Dalšímˇ nápadom do diplomovej práce bolo vytvorit’ workflow, ktorý by po dokonceníˇ objednávky vytvoril Open Orders Report a poslal ho e-mailom kontaktu na objendávke. Tvorba tohoto workflow by vyžadovala zasahovanie do kódu aplikácie. V caseˇ tvorby tejto diplomovej práce bola vo vývojarskej verzii iDempiere chyba v obrazovke Workflow na záložke Condition, kde nie je možné zapisovat’ do pol’a Node Transition, ktoré by malo byt’ automaticky generované a tak nebolo možné uložit’ žiadne podmienky. Tento problém bol reprodukovaný v rôznych OS (Windows 7, Ubuntu 14.04) pri použití manuálu zo stránky http://www.globalqss.com/wiki/index.php/IDempiere.

51 4. MODELOVÉ PRÍKLADY WORKFLOW

• (End) – Koncový uzol s pol’om Action nastaveným na Wait (Sleep).

3. Záložka Tranisition – postupnost’ uzlov tohoto workﬂow je nasledu- júca:

• (Start) → (SendConﬁrmation) → (End)

4. Záložka Condition – pre prechod (Start) → (SendConﬁrmation) boli nastavené podmienky (postupnost’ polí Column Operation Value)

• IsSOTrx_Sales Transaction = Y – predajná objednávka (Sales Order) a nákupná objednávka (Purchase Order) sa uchovávajú v tej istej tabul’ke C_Order. Pole IsSOTrx pomáha rozlíšit’ ciˇ sa jedná o objednávku alebo nákup. Pre predajnú objednávku je hodnota pol’a IsSOTrx = Y a pre nákupnú objednávku je hodnota pol’a IsSOTrx = N. • C_DocType_ID = 132 – císloˇ 132 je interné identiﬁkacnéˇ císloˇ pre predajné objednávky typu Standard Order v iDempiere in- štalácii.

5. Záložka Access – tento workﬂow je prístupný pre role GardenWorld Admin a GardenWorld User.

Systém iDempieri využíva na tvorbu reportov knižnicu JasperReports2. Vy- tvorenie e-mailu s reportom Order Confirmation, ktorý sa pošle cez workflow bolo napevno naprogramované v kóde aplikácie vid’. prílohaB, ob- rázok B.1. Toto generovanie reportu do pdf je naprogramované pre všetky štandardné formuláre MInOut (zásielka), MInvoice (faktúra), MOrder (ob- jednávka, nákup), MRfQResponse (žiadost’ pre cenovú ponuku). Na obrázku 4.6 je možné vidiet’ šablónu Order Confirmation použitú v tomto príklade. Na obrázku 4.7 je možné vidiet’ e-mail, ktorý sa odošle na email kontaktu uvedeného na objednávke. Na obrázku 4.8 je možné vidiet’ report, ktorý sa odošle na email kontaktu uvedeného na objednávke [Sales Order (Menu > Quote to Invoice > Sales Orders)]. Na obrázku 4.9 je možné vidiet’ workflow Send Order Confirmation v obrazovke Workflow Editor.

2. http://community.jaspersoft.com/project/ jasperreports-library

52 4. MODELOVÉ PRÍKLADY WORKFLOW

Obr. 4.6: Obrazovka „Mail Template“ zo systému iDempiere. Na obrázku je možné vidiet’ šablónu Order Conﬁrmation.

Obr. 4.7: E-mail, ktorý sa odošle kontaktu na objednávke. Tento email zahr´naˇ meno kontaktu, cenu celej objednávky a report v pdf formáte.

53 4. MODELOVÉ PRÍKLADY WORKFLOW

Mr Joe Block Joe Joe

Order Confirmation 50025 - 05/03/2014

Qty UoM Description List Price Discount % Unit Price Line Net 1 h Planting Service 45.00 5 42.75 42.75

Standard 42.75 0.00 Sum 42.75

USD 42.75 2%10 Net 30 Payment Term Note: Long Term Contracts are eligible for payment discounts.

Obr. 4.8: Report, ktorý sa vygeneruje a pošle na email kontaktu na objed- návke.

Obr. 4.9: Workflow Send Order Confirmation v obrazovke Workflow Editor.

54 4. MODELOVÉ PRÍKLADY WORKFLOW

4.3.1 Zaradenie a zhodnotenie modelového príkladu III Z hl’adiska charakteru procesu sa jedná o produkcnýˇ workflow. Tento workflow podporuje hlavné podnikové procesy, tvorí pridanú hodnotu ku výsled- nému produktu a závisí na nomˇ spokojnost’ zákazníka spolocnosti.ˇ Podl’a hl’adiska orientácie procesov sa jedná o proces orientovaný na seba, pretože sa jedná o štruktúrovaný workflow s orientáciou na transakcnéˇ spracovanie s krátkym procesným cyklom. Podl’a hl’adiska technologickej architektúry ide o workflow založený na procesoch, pretože sa jedná o automatizáciu podnikového procesu. Ciastoˇ cneˇ sa taktiež jedná o workflow založený na elektronickej pošte. Podl’a použitia v podnikovej praxi ide o monitorovací workflow pretože slúži ku sledovaniu stavu objednávky, ak tento stav objed- návky nadobudne urcenúˇ podmienku zašle sa e-mail.

55 5 Záver

Ciel’om tejto diplomovej práce bolo popísat’ význam a postup tvorby workflow v ERP systémoch. Práca sa zameriava na použitie ERP ako aj workflow v cloude s využitím distribucnéhoˇ modelu softvér ako služba. Praktickou cast’ouˇ tejto diplomovej práce bol návrh a realizácia modelových príkladov v ERP sytéme iDempiere verzia 2.0 (alpha). Teoretická cast’ˇ v úvode práce sa zameriava na definíciu pojmov ERP systém, workflow, cloud, SaaS a výhodami/nevýhodami ich praktického využitia (vid’. kapitolu2). ERP sys- tém iDempiere bol popísaný v kapitole3. Kapitola3 sa zameriavala na vše- obecný popis modulov tohoto ERP systému, typov užívatel’ov v aplikácii a dopodrobna rozoberala tvorbu a použitie workflow v tomto ERP systéme. Workflow v iDempiere bol strucneˇ porovnaný s workflow v konkurencnýchˇ ERP systémoch. Nakoniec sa táto kapitola zaoberala použitím tohoto ERP a jeho workflow v cloude s použitím distribucnéhoˇ modelu softvéru ako služby. Konecnouˇ fázou tejto diplomovej práce bola demonštrácia funkcionality workflow vo vybranom ERP systéme, ktorá bola prevedená na troch rôznych modelových príkladoch (vid’. kapitola4). Každý modelový príklad reprezentuje konkrétny typ workflow v systéme iDempiere (General, Do- cument Process, Document Value). Ku každému modelovému príkladu bol vygenerovaný databázový SQL skript, ktorý tento workflow vloží do data- bázy. Rozšírením tejto diplomovej práce by mohlo byt’ vytvorenie d’alších workflow do ERP systému iDempiere, ktoré by následne mohli byt’ použité v štandardnej verzii. Návrhy podnikových procesov na spracovanie sa na- chádzajú v príloheC. Tieto návrhy vznikli po casˇ štúdia a analýzy na túto diplomovú prácu. Dalšímˇ rozšírením tejto práce by mohlo byt’ vytvorenie práce, ktorá by podrobne porovnávala workflow v dostupných ERP systé- moch s otvoreným zdrojovým kódom.

56 Literatúra

[1] Jorge Cardoso, Robert P. Bostrom, Amit Sheth: Workﬂow Manage- ment Systems and ERP Systems: Differences, Commonalities, and Applications. Special issue on Workﬂow and E-Business, rocníkˇ 5, c.ˇ 3–4, 2004.

[2] Heiko Maus: Workﬂow Context as a Menas for Intelligent Information Support. Information Technology and Management, rocníkˇ 5, c.ˇ 3–4, 2004.

[3] Daniel E. O’Leary: Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Commerce, and Risk. Cambridge University Press, 2000, ISBN 9780521791526.

[4] Workﬂow [online]. URL http://docs.oracle.com/cd/ E19543-01/820-2964/workflow.html, 2008 [cit. 2014-02- 02].

[5] Essam Shehab, et al.: Enterprise resource planning: An integrative re- view. Business Process Management, rocníkˇ 10, c.ˇ 4, 2004.

[6] Mohammad A. Rashid, Liaquat Hossain, Jon David Patric: Enterprise Resource Planning: Global Opportunities & Challenges. Idea Group Publishing, 2002, ISBN 1-59140-025-2.

[7] Josef Basl, Jan Velkoborsky: Prehledˇ ceskéhoˇ trhu softwarových ná- stroj˚uAPS a CRM. Computerworld, rocníkˇ 32, 2000.

[8] Robert F. Jacobs: Enterprise resource planning (ERP) - A brief history. Journal of Operations Management, rocníkˇ 25, c.ˇ 2, 2007.

[9] Tomáš Vancura:ˇ Nástroje pro automatizaci workﬂow proces˚u. diplo- mová práce, Vysoké uceníˇ technické, 2008.

[10] Helios. URL http://www.helios.eu/, 2014 [cit. 2014-02-23].

[11] Alan Pelz-Sharpe: ERP and Third Party Workﬂow. Document World, rocníkˇ 5, c.ˇ 1, 2000.

57 5. ZÁVER

[12] Petr Sodomka: Rízeníˇ pracovních tok˚uv Helios Green. IT Systems,, c.ˇ 10, 2011.

[13] Dean Jacobs: Enterprise Software as Service: Online services are changing the nature of software. QUEUE, rocníkˇ 3, c.ˇ 6, 2005.

[14] Bayu Cahya Pamungkas: ADempiere 3.4 ERP Solutions :design con- ﬁgure, and implement a robust enterprise resource planning system in your organization by using ADempiere. Packt Publishing Ltd., 2009, ISBN 978-1-847197-26-9.

[15] Ajit Kumar: ADempiere 3.6 Cookbook. Packt Publishing Ltd., 2011, ISBN 978-1-84951-338-8.

[16] iDempiere: Open Source ERP Systen [online]. URL http://wiki. idempiere.org, 2014 [cit. 2014-02-26].

[17] Chuck Boecking: Chuck Boecking: Open Source ERP Training and Consulting [online]. URL http://www.chuckboecking.com, 2014 [cit. 2014-02-25].

[18] Jaromír Skrivan:ˇ SQL – Jak na triggery [online]. URL http:// interval.cz/clanky/sql-jak-na-triggery/, 2014 [cit. 2014-05-17].

[19] Open ERP Documentation v7.0 [online]. URL https://doc. openerp.com, 2014 [cit. 2014-02-25].

[20] David E. Jones: Apache OFBiz Project Overview [online]. URL http://ofbiz.apache.org/ apache-ofbiz-project-overview.html, 2014 [cit. 2014-05-17].

[21] Together - Professional Open Source: Open Source Java WfMC XPDL and OMG BPMN compliant Workﬂow [online]. URL http://www. together.at/prod/workflow/tws, 2014 [cit. 2014-02-25].

[22] Enhydra SHARK Open Source Workﬂow: Enhydra Shark Documenta- tion [online]. URL http://shark.ow2.org/doc/1.0/, 2014 [cit. 2014-02-25].

58 5. ZÁVER

[23] Kevin Roebuck: Virtualization: High-Impact Technology– What You Need to Know: Deﬁnitions, Adoptions, Impact, Beneﬁts, Maturity, Vendors. Emereo Pty Limited, 2011, ISBN 9781743043462.

[24] Igor Krnác:ˇ Príprava ERP ADempiere pro reálnou implementaci. dip- lomová práce, Masarykova Univerzita, 2013.

[25] Silvie Petrová: Využití ERP systému ADempiere. diplomová práce, Masarykova Univerzita, 2012.

[26] Hesham Ahmed: Bitbucket [online]. URL https://bitbucket. org/idempiere/idempiere/commits/3c96c46f00bf/, 2014 [cit. 2014-02-25].

59 A Elektronické prílohy

Súcast’ouˇ tejto diplomovej práce je elektronická príloha priloha.zip, ktorá obsahuje nasledujúce položky:

• latex_src – zdrojové kódy ku textovej castiˇ práce v LATEXu. • skripty – databázové skripty na vloženie modelových workﬂow do systému iDempiere.

60 B Zdrojové kódy z aplikácie

Kód na obrázku B.1 pochádza z modelovej triedy pre Objednávku a bolo do neho pridané generovanie pdf z Jasper reportu.

1 "public File createPDF(File file) 2 { 3 ReportEngine re= ReportEngine.get(getCtx(), 4 ReportEngine.ORDER, getC_Order_ID(), 5 get_TrxName()); 6 i f(re == null) 7 r e t u r n null; 8 MPrintFormat format= re. getPrintFormat(); 9 // We havea Jasper Print Format 10 // ======11 i f(format. getJasperProcess_ID()> 0) 12 { 13 ProcessInfo pi= new ProcessInfo("", 14 f o r m a t. getJasperProcess_ID()); 15 16 p i. setRecord_ID( getC_Order_ID()); 17 p i. setIsBatch(true); 18 19 ServerProcessCtl.process(null, pi, null); 20 21 r e t u r n pi. getPDFReport(); 22 } 23 // Standard Print Format(Non −J a s p e r) 24 // ======25 r e t u r n re. getPDF(file); 26 }// createPDF" 27

Obr. B.1: Kód na vygenerovanie pdf z Jasper Reportu org.adempiere.base/src/org/compiere/model/MOrder.java pre- braté z [26].

61 C Identiﬁkácia bežných procesov v rámci ﬁrmy

Pocasˇ štúdia na túto diplomovú prácu boli identifikované rôzne procesy, ktoré sa vyskytujú vo firmách. Táto kapitola obsahuje návrhy, ktoré neboli spracované vo forme workflow pre túto diplomovú prácu. Niektoré z týchto procesov sa už v nejakej forme v iDempiere nachádzajú alebo používajú ako príklady (napr. v publikácii [14]). Niektoré z týchto firemných procesov by mohli byt’ v budúcnosti implementované vo forme workflow do iDem- piere.1. Medzi najcastejšieˇ podnikové procesy, ktoré sa používajú v organi- záciách patria aj nasledujúce príklady:

1. Schval’ovanie požiadavky na objednávku na nákup služieb a ma- teriálu (Purchase Requisition, Purchase Order), tento proces môže vyzerat’ napríklad takto:

(a) Zamestnanec zadá požiadavku na nákup materiálu alebo služby, týmto v systéme vznikne požiadavka na nákup. (b) Požiadavka sa pošle na schválenie k jednému alebo viacerým nadriadeným tohoto zamestnanca (v závislosti od ceny tejto po- žiadavky). (c) Po schválení požiadavky nadriadeným sa zist’uje, ciˇ sa tento produkt náhodou nenachádza v sklade. Pri službe môžeme zis- t’ovat’, ciˇ je možné ju zaistit’ internými zdrojmi alebo je nutné objednat’ službu externe. i. Interné zdroje – ak sa produkt nachádza v sklade, v sys- téme sa vygeneruje výdajka s väzbou na požiadavku zamestnanca. Prípadne ak je možné službu vykonat’ interne zadá sa požiadavka na internú službu. Po vydaní materiálu zo skladu, môže v systéme existovat’ kontrola výšky zá- sob v sklade (hladinové riadenie skladu). Ak táto poklesne pod deﬁnované množstvo v systéme vygeneruje sa auto- matická objednávka na nákup materiálu, aby sa držal na urcitejˇ hladine. Ak sa jedná o spotrebný tzv. režijný mate- riál (papier, toner, hygienické potreby, písacie potreby...) je

1. Táto kapitola bola vytvorená z osobných skúseností z praxe a konzultáciami s l’ud’mi pracujúcimi v obore ERP systémov.

62 C.IDENTIFIKÁCIA BEŽNÝCH PROCESOV V RÁMCI FIRMY

možná kumulácia objednávok, aby sa objednalo naraz väc-ˇ šie množstvo za lepšiu cenu. Táto kumulovaná objednávka ide opät’ na schválenie podl’a svojej cenovej hodnoty. ii. Externé zdroje – ak sa produkt v sklade nenachádza vygeneruje sa objednávka na požadovaný materiál s väzbou na požiadavku zamestnanca. Prípadne ak je nutné službu vykonat’ externe, zadá sa požiadavka na externú službu. (d) Po schválení objednávky v systéme sa táto objednávka vygeneruje a zašle dodávatel’ovi. Pri viacerých dodávatel’och služby alebo materiálu sa môže urobit’ výberové konanie na najvhod- nejšieho dodávatel’a.

2. Schval’ovanie realizovaných služieb alebo výkonov, tento proces môže vyzerat’ napríklad takto:

(a) Dodávatel’ vytvorí odovzdávací protokol služby a dá ju pod- písat’ pracovníkovi, ktorý bol deﬁnovaný ako zodpovedný za prebratie služby na objednávke. Podpísaný protokol sa priloží ku faktúre ako príloha. Dalejˇ sa postupuje ako pri schval’ovaní dodávatel’ských faktúr.

3. Schval’ovanie príjmov materiálu na sklad, tento proces môže vyzerat’ napríklad takto:

(a) Pri nahrávaní príjmu materiálu na sklad musí dodací list ob- sahovat’ identiﬁkacnéˇ údaje (napr. císloˇ objednávky), aby sa v systéme dalo overit’, ciˇ dodaný tovar súhlasí s tým coˇ je na objednávke. Skladník overí objednávku v systéme a skontroluje ciˇ bolo dodané to coˇ sa nachádza v systéme.

4. Schval’ovanie došlých alebo dodávatel’ských faktúr s prílohami, tento proces môže vyzerat’ napríklad takto:

(a) Voväcšíchˇ spolocnostiachˇ môže existovat’ implementovaný sys- tém pre tvorbu odovzdávacích protokolov od dodávatel’ov (b) Dodávatel’ po skonceníˇ mesiaca nahrá do systému svojich jed- notlivých zamestnancov aj spolu s hodinami, objednávkou a cenou.

63 C.IDENTIFIKÁCIA BEŽNÝCH PROCESOV V RÁMCI FIRMY

(c) Uvedený denník sa pošle na schválenie zamestnancovi, ktorý je urcenýˇ na prebratie služby. (d) Po schválení denníka sa generuje odovzdávací protokol, ktorý ide na d’alšieho zamestnanca, ktorý je zodpovedný za náklady na danom pracovisku, ktorý ho bud’ schváli alebo zamietne. (e) Dodávatel’ pošle faktúru, ktorú treba v ERP systéme spojit’ s odovzdávacím protokolom a d’alej sa postupuje ako pri schval’ovaní dodávatel’ských faktúr.

5. Schval’ovanie platobných príkazov, tento proces môže vyzerat’ na- príklad takto:

(a) Faktúra je nahratá v systéme v module, ktorý pracuje so zá- väzkami. Faktúra prešla schválením ako v bode schval’ovanie dodávatel’ských faktúr. (b) Ak je hodnota úhrady vyššia ako deﬁnovaná hodnota je po- trebný súhlas zodpovedného zamestnanca za platby dodávate- l’om.

6. Schval’ovanie zákaziek alebo kúpnych zmlúv pre odberatel’ov (výrobná cinnost’)ˇ , tento proces môže vyzerat’ napríklad takto:

(a) Obchodník zadá objednávku zákazníka na nákup výrobkov ako kúpnu zmluvu/zákazku do systému. (b) Táto kúpna zmluva/zakázka ide na schválenie kreditnému od- deleniu, ktoré zistí a potvrdí kredibilitu partnera (je tento zá- kazník schopný zaplatit’ za produkty? – odvádza sa väcšinouˇ od otvorených objednávok a faktúr zákazníka v systéme). (c) Dalejˇ sa táto kúpna zmluva/zákazka sa posunie na schvále- nie výrobným oddelením (je spolocnost’ˇ schopná vyrobit’ produkt?). (d) Ak je spolocnost’ˇ schopná produkt vyrobit’ (technologicky a kvalitatívne), urobí sa plán výroby a potvrdí sa termín dodania výrobkov (vyžiadaný zákazníkom), prípadne sa urobí návrh na nový termín, v ktorom je spolocnost’ˇ schopná výrobky dodat’. Táto skutocnost’ˇ je diskutovaná so zákazníkom kým nedôjde ku dohode.

64 C.IDENTIFIKÁCIA BEŽNÝCH PROCESOV V RÁMCI FIRMY

(e) V prípade, že cena je nižšia ako cena v cenníku alebo základná deﬁnovaná cena je potrebné požiadat’ o cenovú výnimku (vid’. bod7) (f) Zakázka/kúpna zmluva sa v systéme schváli, vytlací,ˇ podpíše a pošle sa na podpis zákazníkovi.

7. Schval’ovanie cenových výnimiek, tento proces môže vyzerat’ na- príklad takto:

(a) Pri zadaní kúpnej zmluvy/zákazky do systému sa vygeneruje oznam, že cena je nižšia ako cenníková cena a je nutne schválit’ cenovú výnimku v systéme. (b) Cenová výnimka môže byt’ potvrdzovaná viacerými úrovnamiˇ závisiac od vel’kosti spolocnostiˇ (nadriadený zamestnanca, ktorý sa stará o zriad’ovanie zmlúv so zákazníkmi až generálny ma- nažér spolocnosti).ˇ

8. Proces pre prácu s dokumentami a potvrdzovanie oboznámenia s dokumentom, tento proces môže vyzerat’ napríklad takto:

(a) V spolocnostiˇ existuje množstvo dokumentov, ktoré definujú pravidlá práce (bezpecnost’ˇ práce, pracovné postupy, pravidlá pri vykonávaní rôznych cinností...).ˇ Zamestnanci musia byt’ s týmito pravidlami oboznámení a musia toto oboznámenie po- tvrdit’. (b) Ak sa zamestnanec neoboznámi s dôležitými dokumentami do urcenéhoˇ casu,ˇ jeho nadriadený dostane notifikáciu (napr. e- mail) o tejto skutocnostiˇ a musí zariadit’ nápravu tejto skutoc-ˇ nosti. Dokument sa môže preposlat’ ešte raz do workflow alebo sa zamestnanec oboznámi osobne a vyžiada sa potvrdenie pod- pisom.

65 D Snímky z aplikácie iDempiere

Obr. D.1: Obrazovka „Role“ zo systému iDempiere.

66 D.SNÍMKYZAPLIKÁCIEIDEMPIERE

Obr. D.2: Obrazovka „User“ zo systému iDempiere.

Obr. D.3: Obrazovka „Role Access Update“ zo systému iDempiere.

67 D.SNÍMKYZAPLIKÁCIEIDEMPIERE

Obr. D.4: Obrazovka „Table and Column“ zo systému iDempiere.

Obr. D.5: Obrazovka „Report & Process“ zo systému iDempiere.

68 D.SNÍMKYZAPLIKÁCIEIDEMPIERE

Obr. D.6: Obrazovka „Workﬂow Process“ zo systému iDempiere.