}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Využití ERP Systému ADempiere D IPLOMOVÁ PRÁCE
Bc. Silvie Petrová
Brno, Jaro 2012
Prohlášení Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracovala samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používala nebo z nich cˇ erpala, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Bc. Silvie Petrová
Vedoucí práce: Ing. Leonard Walletzký, Ph.D. Konzultant: doc. RNDr. Tomáš Pitner, Ph.D. ii
Podˇekování Dˇekuji pánum ˚ doktorum ˚ Leonardu Walletzkému a Tomáši Pitnerovi za pomoc, ochotu a trpˇelivost pˇri tvorbˇe zadání i samotné diplomové práce a pˇri práci se systémem ADempiere. Dále bych ráda podˇekovala Bc. Igoru Krnáˇcovi za pomoc s koneˇcnou fází projektu a nastavením systému ADempiere. V neposlední rˇ adˇe patˇrí podˇekování také mé rodinˇe za všudypˇrítomnou podporu.
iii
Shrnutí Práce se zabývá volnˇe šiˇritelným ERP systémem ADempiere, popisem jeho rozhraní, funkcionality a možnostmi jeho využití pˇredevším v IT firmách v souvislosti s jejich specifickými potˇrebami. V navazující cˇ ásti se pak podrobnˇeji zamˇerˇ uje na projektové rˇ ízení v IT, požadavky na nástroje pro projektové rˇ ízení a vývoj nového modulu pro projektové rˇ ízení v systému ADempiere.
iv
Klíˇcová slova ADempiere, ERP, potˇreby IT firmy, nasazení podnikového systému, projektové rˇ ízení, SaaS, Ganttuv ˚ diagram
v
Obsah 1 2
3
4
5
6
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . ERP systémy . . . . . . . . . . . . . . . . . . . . . . . 2.1 Nasazení ERP systému . . . . . . . . . . . . . . 2.1.1 Dusledky ˚ nasazení ERP systému . . . . 2.2 Varianty ERP systému˚ . . . . . . . . . . . . . . Analýza potˇreb IT firmy vzhledem k IS . . . . . . . 3.1 Vymezení pojmu „IT firma“ . . . . . . . . . . . 3.2 Potˇreby IT firmy obecnˇe . . . . . . . . . . . . . 3.3 Procesy v IT firmˇe . . . . . . . . . . . . . . . . . 3.4 Zaˇcínající firma . . . . . . . . . . . . . . . . . . 3.4.1 Porovnání požadavku˚ a možností . . . 3.4.2 Potˇreba vs. nadbyteˇcnost . . . . . . . . Systém ADempiere . . . . . . . . . . . . . . . . . . . 4.1 Práce se systémem ADempiere . . . . . . . . . 4.2 Uživatelské rozhraní . . . . . . . . . . . . . . . 4.2.1 Práce s webovým rozhraním . . . . . . 4.2.2 Práce s java klientem . . . . . . . . . . . 4.3 Nastavení a používání systému . . . . . . . . . 4.3.1 Detaily nastavení systému ADempiere 4.4 Úpravy systému . . . . . . . . . . . . . . . . . . 4.5 Nedostatky systému ADempiere . . . . . . . . 4.6 ADempiere jako služba . . . . . . . . . . . . . . 4.7 Využití systému ADempiere v rámci výuky . . Nástroje pro projektové rˇízení . . . . . . . . . . . . 5.1 Pˇrehled nástroju˚ pro projektové rˇ ízení . . . . . 5.1.1 Redmine . . . . . . . . . . . . . . . . . . 5.1.2 Trac . . . . . . . . . . . . . . . . . . . . . 5.1.3 Project Open . . . . . . . . . . . . . . . . 5.1.4 Collabtive . . . . . . . . . . . . . . . . . 5.1.5 Basecamp . . . . . . . . . . . . . . . . . 5.1.6 Gantt Project . . . . . . . . . . . . . . . 5.2 Požadavky na nástroje pro projektové rˇ ízení . 5.3 Projektové rˇ ízení v ADempiere . . . . . . . . . ˇ 5.4 Rešení pro ADempiere . . . . . . . . . . . . . . Modul rˇízení softwarových projektu˚ . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 3 3 5 5 7 7 7 8 9 10 10 12 12 13 13 15 15 15 19 20 21 22 24 24 24 25 25 26 26 26 26 27 29 30 vi
6.1
Návrh . . . . . . . . . . . . . . . . . . . 6.1.1 Typ projektu . . . . . . . . . . . Analýza požadavku˚ . . . . . . Návrh . . . . . . . . . . . . . . Implementace . . . . . . . . . 6.1.2 Nastavení jednotek práce . . . Analýza požadavku˚ . . . . . . Návrh . . . . . . . . . . . . . . Implementace . . . . . . . . . Testování . . . . . . . . . . . . 6.1.3 Správa softwarového projektu Analýza požadavku˚ . . . . . . Návrh . . . . . . . . . . . . . . Implementace . . . . . . . . . Testování . . . . . . . . . . . . 6.1.4 Seznam úkolu˚ . . . . . . . . . . 6.1.5 Výkaz . . . . . . . . . . . . . . Analýza požadavku˚ . . . . . . Návrh . . . . . . . . . . . . . . Implementace . . . . . . . . . Testování . . . . . . . . . . . . 7 Závˇer . . . . . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . . . . . A Snímky obrazovek . . . . . . . . . . . . . . B Databázové tabulky . . . . . . . . . . . . . C Elektronické pˇrílohy . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
30 31 32 32 32 35 35 35 36 37 37 37 37 41 42 42 42 43 43 44 44 45 46 48 53 54
vii
1 Úvod Efektivní fungování firmy a rˇ ízení zdroju, ˚ at’ už finanˇcních, lidských cˇ i jiných, je velmi duležitou ˚ oblastí pro každý podnik. Nastavením tˇech správných procesu, ˚ vhodným rozdˇelení odpovˇednosti, sbˇerem dat o fungování firmy a jejich následným vyhodnocováním a mimo jiné také volbou vhodných podpurných ˚ prostˇredku˚ lze dosáhnout konkurenˇcní výhody, úspory nákladu˚ a zvýšení výnosu˚ podnikání. Firemní informaˇcní systémy se rˇ adí právˇe mezi takové podpurné ˚ prostˇredky, které mohou, jsou-li správnˇe zvoleny a nastaveny, být firmˇe nejen oporou, ale v mnohých pˇrípadech i klíˇcovou aplikací, na níž je chod celé firmy závislý. Využití informaˇcních technologií v tomto smˇeru se v dnešní dobˇe zdá být pˇrirozené, muže ˚ s sebou však pˇrinášet podstatné komplikace a finanˇcní náklady. Místo podpurného ˚ prostˇredku se tak nˇekdy z firemního informaˇcního systému stává spíše zátˇež. Používání systému, který nefunguje správnˇe, vede uživatele k chybám nebo nemá pˇrívˇetivé uživatelské rozhraní muže ˚ znamenat více problému˚ než pˇrínosu. ˚ To je nˇeco, co si malé a menší stˇrední firmy, pˇrípadnˇe zacˇ ínající podniky, nemohou cˇ asto dovolit. Tato práce se zamˇerˇ uje na open source ERP1 systém ADempiere a zabývá se možnostmi jeho využití v IT firmách. V mnohém vychází z bakaláˇrské práce Bc. Igora Krnáˇce [1]. Cílem této práce je navrhnout reálné možnosti využití systému ADempiere v IT firmách a pˇripravit samotný systém na takové použití. Práce poukazuje na nedostatky i na silné stránky systému a ukazuje oblasti, které je nutné opravit cˇ i vylepšit, aby bylo systém možné opravdu použít v praxi. Bezprostˇrednˇe po první kapitole, kterou tvoˇrí tento úvod, následuje kapitola druhá pojednávající o ERP systémech obecnˇe, o jejich pˇrínosech, úskalích a dusledcích ˚ nasazení ERP systému˚ v praxi. Kapitola tˇretí se zabývá podrobnˇeji fungováním IT firem, jejich potˇrebami a bˇežnými procesy. Samostatná cˇ ást je zde vˇenována zaˇcínajícím IT firmám, které jsou potenciálnˇe jednou z hlavních cílových skupin systému ADempiere. ˇ Ctvrtá kapitola je vˇenována systému ADempiere. Obsahuje po1.
Enterprise Resource Planning - viz další text
1
1. Ú VOD pis práce se systémem, pruvodce ˚ úvodním nastavením, zhodnocení systému z pohledu funkcionality, vzhledu i uživatelské pˇrívˇetivosti, vyhodnocení možností pro poskytování systému jako služby a jeho možné využití nejen v IT firmách. Pˇrehled nástroju˚ pro projektové rˇ ízení lze nalézt v další, páté, kapitole. Kromˇe struˇcného pˇredstavení nejpoužívanˇejších aplikací pro projektové rˇ ízení se zamˇerˇ uji také na obecné požadavky na software nástroje pro projektové rˇ ízení a popis stávajícího modulu Project Management sytému ADempiere. Poslední dvˇe kapitoly, kapitola šestá a závˇer, podrobnˇe popisují tvorbu nového modulu pro projektové rˇ ízení softwarových projektu. ˚ Kromˇe prezentace vytvoˇreného rˇ ešení také uvádím množství tipu˚ pro další vylepšení tohoto modulu. Databázové schéma nového modulu, snímky obrazovek i zdrojové kódy jsou umístˇeny v pˇrílohách práce.
2
2 ERP systémy ERP - Enterprise Resource Planning, volnˇe pˇreloženo jako plánování firemních zdroju, ˚ je pojem oznaˇcující typ podnikového informaˇcního systému. Puvodnˇ ˚ e vznikly ERP systémy jako systémy pro kontrolu a sledování zásob a postupnˇe se vyvinuly až do dnešní komplexní podoby. Dle [1] mohou ERP systémy pokrývat nˇekteré nebo všechny z tˇechto cˇ tyˇr hlavních oblastí firemní aktivity: •
Finance - úˇcetnictví, rozpoˇcty, fakturace atd.
•
Výroba - plánování a rˇ ízení výroby, informace o výrobcích
•
Logistika - nákup, prodej, sledování skladových zásob a plánování zdroju˚
•
Lidské zdroje - personalistika
2.1
Nasazení ERP systému
Z pohledu nasazení ERP systému se nabízejí firmám dvˇe základní možnosti. Jedná se bud’to o tradiˇcní licenˇcní model (on premise model), kdy firma vlastní hardware a software si zakoupí formou licencí platných na urˇcitou dobu, nebo využití odbˇeru softwarových služeb (model on demand ). [2] V takovém pˇrípadˇe je celý systém využíván jako služba (SaaS - Software as a Service) formou outsourcingu. Toto rˇ ešení, které je stále více populární, pˇrináší urˇcitou úsporu nákladu, ˚ protože zákazník platí pouze za to, co skuteˇcnˇe používá. Na druhou stranu nemá firma témˇerˇ žádnou kontrolu nad svými daty a musí se v tomto ohledu spolehnout na profesionalitu dodavatele. Duležité ˚ je také zajištˇení bezpeˇcnosti pˇrenosu dat, protože k veškerým datum ˚ a aplikacím je pˇristupováno vzdálenˇe pˇres internet. Výše popsané modely poˇrízení softwaru však rˇ eší pouze cˇ ást procesu nasazení systému jako takového. Obecnˇe, at’ už si podnik zvolí jakýkoliv zpusob ˚ poˇrízení, nejnároˇcnˇejší cˇ ástí nasazení systému je samotné pˇrizpusobení ˚ (customizace) systému a jeho souˇcástí podle požadavku˚ zákazníka - tedy konkrétní firmy. Dále nelze opomenout ani školení všech bˇežných zamˇestnancu, ˚ managementu a pˇrípadnˇe i 3
2. ERP SYSTÉMY IT pracovníku, ˚ kteˇrí budou systém s podporou dodavatelské firmy spravovat. Výhodnou možností pro provoz ERP systém je využití cloud computingu, cˇ ili vzdáleného užívání sdílených zdroju. ˚ V cloudu platí firma pouze za to, co skuteˇcnˇe využívá (systém Pay as you go). Cloud computing je v souˇcasném svˇetˇe velmi oblíbeným termínem. Na jeho popularitˇe má zajisté podíl rostoucí význam mobility, která je charakteristickým rysem cloud computingu, stejnˇe jako lepší distribuce výkonu mezi jednotlivé uživatele. Výrazným pˇrínosem cloud computingu je ve vˇetšinˇe pˇrípadu˚ úspora nákladu˚ na provoz IT. Konkrétní cˇ ísla je však vždy tˇreba vyvozovat individuálnˇe, nebot’ výjimky potvrzují pravidlo. V tomto smˇeru je vždy potˇreba uvážit, zda daná spoleˇcnost již vlastní hardware potˇrebný pro nasazení takového systému, cˇ i nikoliv, zda má vlastní IT oddˇelení a mnoho dalších faktoru˚ cˇ i požadavku, ˚ které ovlivnují ˇ výhodnost toho cˇ i onoho rˇ ešení pro daný podnik. Zásadní je také skuteˇcnost, že náklady na zavedení a provoz systému nejsou a nemˇely by být hlavním mˇerˇ ítkem pro porovnání ERP rˇ ešení. Tím skuteˇcnˇe duležitým ˚ mˇerˇ ítkem by mˇel být dlouhodobý pˇrínos pro firmu. Cena je zde údaj nutný, nikoliv však postaˇcující. Pro výpoˇcet celkových nákladu˚ lze využít napˇr. metody TCO (Total Cost of Ownership). TCO se vypoˇcítává vždy na urˇcitou dobu (obvykle nˇekolik let) pro urˇcitý systém cˇ i zaˇrízení. U ERP systému˚ zahrnuje náklady na zakoupení licencí, náklady na implementaci, její dobu (vˇcetnˇe zapoˇctení práce analytiku˚ a konzultantu˚ dodavatele, vytížení vlastního IT týmu i prostoje zamˇestnancu˚ podílejících se na nasazení systému), zákaznické úpravy, školení zamˇestnancu˚ i pˇrípadné výpadky chodu firmy bˇehem nasazování systému do ostrého provozu. Do TCO se také dále zapoˇcítávají poplatky na údržbu a podporu v následujících letech. [4] Chceme-li hovoˇrit o konkrétních cˇ íslech, pak dle výsledku˚ pru˚ zkumu spoleˇcnosti Panorama Consulting Solutions z roku 2010 [3] mezi spoleˇcnostmi s roˇcními pˇríjmy v rozmezí desítek milionu˚ USD až pˇeti miliardami USD byla prumˇ ˚ erná celková cena poˇrízení ERP systému globálnˇe 5.5 milionu USD, nebo 4,1% roˇcního pˇríjmu spoleˇcnosti. Údaj o celkové délce implementace však také není bez zajímavosti. Podle zmínˇeného pruzkumu ˚ byla prumˇ ˚ erná délka implementace 15,63 mˇesícu. ˚ 4
2. ERP SYSTÉMY 2.1.1 Dusledky ˚ nasazení ERP systému Nasazení ERP systému v organizaci pˇrináší v podstatˇe vždy zmˇeny ve firemních procesech, a tím pádem i zmˇeny v celé organizaci. Podstatný je rozsah tˇechto zmˇen. Rozhodnutí o tom, které postupy a procesy zustanou ˚ ve firmˇe zachovány (systém bude upraven na míru tak, aby tyto postupy podporoval) a které budou pˇrizpusobeny ˚ ERP systému, cˇ iní firma sama. Každá úprava systému pro konkrétního zákazníka je nejen výdaj navíc ve fázi implementace, ale také výdaj do budoucna v podobˇe nutnosti úprav pˇri každém pˇrechodu na novou verzi systému. Avšak právˇe v rozdílnosti procesu˚ oproti standardním se muže ˚ také skrývat konkurenˇcní výhoda spoleˇcnosti. ˇ Castým rˇ ešením je proto jen cˇ ásteˇcná úprava systému na míru. "Zahraniˇcní studie vypovídají o tom, že 25% firem dost podstatnˇe pˇrizpusobuje ˚ ERP software svým potˇrebám. Naproti tomu pˇreš 28% necustomizuje zakoupený software vubec ˚ a zcela se ztotožni s procesy obsaženými v ERP rˇ ešení."[2] Z finanˇcní stránky je opˇet údržba systému nezanedbatelná. Dle údaju˚ z citovaného cˇ lánku [2] se udržovací poplatky pohybují na úrovni 22% z celkové ceny licencí.
2.2
Varianty ERP systému˚
Nejvýznamnˇejším rozdˇelením ERP je jistˇe cˇ lenˇení na open source a komerˇcní aplikace. Mezi základní rozhodnutí, která je tˇreba uˇcinit pˇri výbˇeru ERP systému, je zda investovat do hotového komerˇcního rˇ ešení, jehož úpravy na míru i implementaci zajistí dodavatelská firma, nebo se vydat cestou open source rˇ ešení, pˇrípadnˇe si vytvoˇrit úplnˇe nový vlastní systém. Mezi hlavní výhody open source systému˚ patˇrí nulová cena licencí, možnost spravovat systém dle vlastních potˇreb, nezávislost na jednom dodavateli, možnost mít veškerá data pod kontrolou a pˇristupovat k nim libovolnˇe (napˇr. pro úˇcely controllingu 1 ). Oproti tomu nevýhodou je nutnost investovat cˇ as vlastních zamˇestnancu˚ do vývoje a úprav systému, nejistota výsledku a nedostateˇcná nebo žádná podpora. U komerˇcních rˇ ešení existuje nutnost investice cˇ asu vlastních zamˇestnancu˚ také, ale v podstatnˇe menší 1.
http://cs.wikipedia.org/wiki/Controlling
5
2. ERP SYSTÉMY míˇre. Totéž platí o nejistotˇe výsledku. Poˇrizovací náklady jsou naopak u komerˇcních rˇ ešení nezanedbatelné. Z hlediska funkˇcnosti systému mužeme ˚ také hovoˇrit o ruzných ˚ variantách ERP. Nˇekteré systémy se zamˇerˇ ují specificky na urˇcitou oblast trhu (napˇr. na distribuˇcní spoleˇcnosti, stavební spoleˇcnosti, výrobní podniky atd.). Kromˇe zamˇerˇ ení celého systému mužeme ˚ najít i rozdíly v rozsahu pokrytí ruzných ˚ oblastí firemní aktivity nebo v podpoˇre rozhodovacích procesu˚ managementu. Nˇekteré systémy napˇr. disponují modulem BI (Business Inteligence) nebo EIS (Executive Information System). Podle zpusobu ˚ použití bychom mohli rozdˇelit ERP systémy na klientské aplikace a webové aplikace, pˇrípadnˇe pak ještˇe na skupinu tˇech, které disponují obˇema možnostmi.
6
3 Analýza potˇreb IT firmy vzhledem k IS 3.1
Vymezení pojmu „IT firma“
Pojem „IT firma“ je velmi široký, muže ˚ zahrnovat firmy pracující pouze s hardwarem, jako napˇr. PC servisy, firmy zabývající se vývojem jedné nebo urˇcitého typu aplikací i výzkumné spoleˇcnosti se snahou prosadit na trhu nové technologie. V rámci této práce budeme pod pojmem IT firma rozumˇet spoleˇcnosti zabývající se alesponˇ cˇ ásteˇcnˇe vývojem nˇejakého softwarového rˇ ešení jakéhokoliv zamˇerˇ ení.
3.2
Potˇreby IT firmy obecnˇe
Potˇrebami budeme rozumˇet množinu cˇ inností, které jsou nezbytné pro bezproblémový chod firmy nyní i v budoucnu a pro každodenní rozhodování s krátkodobým i dlouhodobým horizontem dopadu. Vycházet budeme ze cˇ tyˇr oblastí uvedených v úvodu kapitoly 2. První duležitou ˚ oblastí, bez které se žádná firma neobejde, jsou finance. Úˇcetní záznamy, ale i další finanˇcní údaje, napˇr. o pˇríjmech, výdajích, nákladech a rozpoˇctech, jsou pro firmu podstatné. Tvoˇrí základ pro rozhodování managementu a plánování, pro tzv. BI - Business Intelligence. Nástroje BI jsou cˇ asto souˇcástí nejruznˇ ˚ ejších ERP rˇ ešení v podobˇe modulu EIS (Executive Information System) a pro mnoho firem jsou nepostradatelné. Hovoˇríme-li o IT firmách, mužeme ˚ s urˇcitostí vylouˇcit potˇrebu plánovat a rˇ ídit výrobu v klasickém slova smyslu. Namísto toho by však jistˇe byla užiteˇcná podpora pro oblast projektového rˇ ízení, kdy také do jisté míry hovoˇríme o výrobˇe produktu, i když výsledkem je aplikace cˇ i nˇejaký jiný software. Tuto oblast nejvíce využijí podniky zabývající se výrobou software na míru. V takových pˇrípadech nejsou žádné dva projekty stejné a každý je potˇreba detailnˇe plánovat pˇredem. Projektové rˇ ízení mohou využít i podniky vˇenující se pˇrevážnˇe neustálému vývoji jediné aplikace, protože i zde lze jednotlivé cykly vývoje vidˇet jako na sebe navazující projekty. Oblast logistiky vˇetšina IT firem pˇríliš nevyužije, pˇrihlédneme-li k tomu, že software produkty nejsou hmatatelné (byly by pouze v 7
ˇ 3. A NALÝZA POT REB IT
FIRMY VZHLEDEM K
IS
pˇrípadˇe, že by spoleˇcnost prodávala tzv. krabicový software). Logistika proto bude ve vˇetšinˇe pˇrípadu˚ redukována na samotný prodej a jeho sledování. Poslední položkou dle uvedeného rozdˇelení jsou lidské zdroje. Tato oblast je naopak pro IT firmy velmi duležitá. ˚ Plánování lidských zdroju˚ a jejich využití je klíˇcové pro úsporu nákladu˚ a efektivní chod firmy.
3.3
Procesy v IT firmˇe
Proces bývá definovaný jakou posloupnost stavu˚ nˇejakého systému. Nejedná se o nahodilé nebo náhlé jevy, nýbrž o plánované a promyšlené dˇeje. Základní procesy na nejobecnˇejší úrovni, které musí dobˇre fungovat v každé (nejen) zaˇcínající IT firmˇe podle Cayenne Consulting, jsou[5]: •
ˇ Rízení finanˇcních zdroju˚ a správa majetku
•
Business plán
•
Proces vývoje produktu
•
Proces financování
•
ˇ Rízení lidských zdroju˚
•
Využití informaˇcních technologií
•
Fakturace a tok pˇríjmu˚
•
Zákaznický servis a podpora
Z tohoto výˇctu jsou pro úˇcely této práce významné pˇredevším ty ˇ body, jež lze podpoˇrit cˇ i zefektivnit pomocí ERP systému. Jsou to Ríˇ zení finanˇcních zdroju˚ a správa majetku, Rízení lidských zdroju, ˚ Využití informaˇcních technologií, Fakturace a tok pˇríjmu˚ a cˇ ásteˇcnˇe také Zákaznický servis a podpora. Tyto procesy použijeme dále v této práci pro vyhodnocení funkˇcnosti systému ADempiere. 8
ˇ 3. A NALÝZA POT REB IT
3.4
FIRMY VZHLEDEM K
IS
Zaˇcínající firma
V rámci využití systému ADempiere na Fakultˇe informatiky existuje pˇredpoklad, že by mohl být systém poskytován v rámci podpory novˇe vznikajících IT firem. V pˇrípadˇe mladé firmy jsou však požadavky na nasazení a využití takového systému ponˇekud specifické, je nutné vzít v potaz podstatný rozdíl mezi jejím fungováním a fungováním již zavedené firmy. První markantní rozdíl je v poˇctu zamˇestnancu. ˚ Kdežto zavedené firmy mají již kromˇe zakladatele firmy také nˇekolik (pˇríp. i nˇekolik desítek) zamˇestnancu, ˚ zaˇcínající firma je závislá obvykle na jedné cˇ i dvou osobách. Další zamˇestnance bud’to vubec ˚ nemá, nebo pracují pro firmu externˇe, popˇr. formou brigády. První omezení pro zacˇ ínající firmu tak tkví v množství cˇ asu, které mají její zamˇestnanci/vlastníci na správu a nasazení systému, protože jejich primárním úkolem je zajistit životaschopnost firmy, shánˇet zakázky, investory, dohlížet na vývoj produktu, marketing firmy atd. První požadavek na ERP systém pro takovouto zaˇcínající firmu je tedy maximální jednoduchost systému, nenároˇcná instalace, konfigurace a snadná správa. Další zásadní otázkou jsou finanˇcní zdroje. Zavedené firmy obvykle poˇcítají s reinvesticí cˇ ásti svých zisku˚ zpˇet do podnikání a znají své výsledky za minulé roky, takže dokáží odhadnout své možnosti. Kromˇe toho již mají vybudovanou pozici na trhu, z níž mohou dále tˇežit. Zaˇcínající firmy cˇ asto žádné zisky navíc nemají, nebo když mají, je pro nˇe tˇežké odhadnout situaci do budoucna. Jejich pozice na trhu je zatím slabá, nebo dokonce žádná, pokud firma ještˇe neidentifikovala pˇresnˇe svuj ˚ business plán a nezaˇcala jej systematicky realizovat. Druhý požadavek na ERP systém je (v ideálním pˇrípadˇe) nulová cena ze poˇrízení systému a licencování. Jistˇe nelze ani pˇredpokládat, že by zaˇcínající firma vlastnila server pro nasazení ERP systému. Zavedená firma pravdˇepodobnˇe již nˇejaký hardware vlastní, nebo si muže ˚ dovolit umístit ERP do cloudu, kde bude platit mˇesíˇcní poplatky za to, co bude opravdu využívat. Je-li to tedy možné, je potˇreba maximálnˇe snížit náklady na hardware, jeho provoz a údržbu. Naopak výhodou zaˇcínající firmy v IT je, že se s velkou pravdˇepodobností alesponˇ jeden ze zakladatelu˚ firmy v IT problematice 9
ˇ 3. A NALÝZA POT REB IT
FIRMY VZHLEDEM K
IS
orientuje a je tak schopen cˇ ásteˇcnˇe cˇ i úplnˇe pˇrevzít úlohu IT odborníka zavedené firmy. Kromˇe toho nová firma pravdˇepodobnˇe zatím nemá své procesy nastaveny, takže je muže ˚ bud’to pˇrizpusobit ˚ procesum ˚ v ERP systému, nebo si vytvoˇrit vlastní procesy na míru dle možností ERP systému. Není tak tˇreba žádné existující procesy firmy upravovat nebo mˇenit a pˇreuˇcovat zamˇestnance již jednou nauˇcené postupy. Dále malé množství existujících dat hraje ve prospˇech zaˇcínající firmy, cˇ ímž se snižuje doba potˇrebná pro zavedení a nastavení systému. 3.4.1 Porovnání požadavku˚ a možností Z výše uvedeného pomˇernˇe jasnˇe vyplývá, že zaˇcínající IT firma si nemuže ˚ dovolit poˇrídit si komerˇcní ERP systém tradiˇcní cestou. Jednou z možností by však mohlo být využití ERP v cloudu. Další možností, která se v takovémto pˇrípadˇe doslova nabízí, je využití open source systému za pˇredpokladu, že bude již pˇrichystán pro takovéto použití, tím pádem firma nebude muset trávit cˇ as výraznˇejšími úpraˇ vami systému. Cásteˇ cné naplnˇení tohoto požadavku je cílem právˇe této práce. Open source software je již z principu zdarma, nemusí být proto vynaloženy žádné finanˇcní prostˇredky na licencování. Soucˇ asná podpora vznikajících IT spoleˇcností ze strany mnoha institucí nahrává také požadavku na minimální náklady na hardware. Zde by mohl být systém fyzicky nasazen na hardwaru partnerské instituce, cˇ ímž by odpadly veškeré náklady na jeho provoz a údržbu. 3.4.2 Potˇreba vs. nadbyteˇcnost Vyjdeme-li z toho, že jakýkoliv poˇcítaˇcový systém vlastnˇe zaznamenává data, která by jinak byla zaznamenána napˇr. na papíˇre, má smysl takový systém mít, pokud: •
je jeho používání jednodušší než by bylo zaznamenávání dat na papír
•
umožnuje ˇ provádˇet automaticky výpoˇcty, pˇrehledy nebo má jiné funkce, jež jsou potˇrebné a jinak by musely být provádˇeny ruˇcnˇe 10
ˇ 3. A NALÝZA POT REB IT
•
FIRMY VZHLEDEM K
IS
usnadnuje ˇ sdílení dat mezi uživateli
Z toho lze vyvodit, že nejspíše nemá smysl zavádˇet ERP systém, pokud firma nemá žádné zamˇestnance a má pouze jediného vlastníka. V pˇrípadˇe, že vlastníci jsou dva a zamˇestnanci žádní, muže ˚ již mít takový systém nˇejaký smysl, ale stále je zde nejspíš vhodnˇejší použít pro záznamy nˇejaký jednodušší elektronický nástroj (napˇr. tabulkový procesor, pˇrípadnˇe jednotlivé nástroje). Duvodem ˚ je rozdíl mezi velikostí investice cˇ asu a zdroju˚ a objemem skuteˇcných pˇrínosu. ˚ Skuteˇcný pˇrínos zaˇcíná mít systém ve chvíli, kdy firma najme alesponˇ jednoho zamˇestnance. Zde zaˇcíná sdílení dat a uchovávání záznamu˚ nabírat nový rozmˇer a ERP systém muže ˚ mnoho práce usnadnit, obzvláštˇe pokud firma plánuje nabírat další zamˇestnance. Ve skuteˇcnosti by nejspíš firma s jediným zamˇestnancem nemˇela na poˇrízení ERP prostˇredky, pokud by však byl ERP systém zprostˇredkováván nˇejakou podpurnou ˚ institucí a byl dobˇre pˇripraven, lze si i takový scénáˇr pˇredstavit.
11
4 Systém ADempiere ADempiere je open source ERP systém, který vzniknul odtržením od systému Compiere. Modularita tohoto systému zajišt’uje jeho snadné rozšíˇrení. Mnoho potˇrebných úprav lze také provést konfigurací pomocí uživatelského rozhraní bez nutnosti zasahovat do kódu. Tato kapitola uvádí postupy a popisy procesu, ˚ které jsou nutné pro nastavení systému pro jeho další užívání. Souˇcástí je také srovnání pˇrístupu pˇres webové rozhraní a java klienta. Pro úˇcely této práce pˇrepokládáme, že systém máme již nainstalovaný a pˇripravený k použití. Instalace systému, aˇckoliv není zdaleka bezproblémová, je pomˇernˇe dobˇre zdokumentovaná1 . O ostatních cˇ ástech systému a jejich používání to již zdaleka rˇ íci nelze. Dokumentace existuje pouze cˇ ásteˇcná, od ruzných ˚ autoru, ˚ neexistuje v cˇ eštinˇe a je navíc roztroušená po ADempiere wiki.
4.1
Práce se systémem ADempiere
Pro práci se systémem je k dispozici hned nˇekolik ruzných ˚ možností. Lze se pˇrihlásit vzdálenˇe pomocí webového prohlížeˇce nebo pomocí JRE (Java Runtime Environment 2 ) klienta bez nutnosti instalace. Práce se systémem „v pozadí“ je ponˇekud složitˇejší a v mém pˇrípadˇe byla ještˇe ztížena pˇredevším pˇrístupem pˇres vzdálenou plochu. Projekt ADempiere je vyvíjen v prostˇredí open-source nástroje Eclipse3 a vˇetšina návodu˚ poˇcítá s jeho použitím. V pˇrípadˇe, že Eclipse není k dispozici, probíhá vše pomocí pˇríkazové rˇ ádky. Zdlouhavým a nejménˇe pˇrívˇetivým procesem v pˇrípadˇe úprav zdrojových kódu˚ je build celé aplikace a spuštˇení nastavení systému, po nˇemž je tˇreba ještˇe restartovat aplikaˇcní server.
1. 2. 3.
Pokyny k instalaci lze najít napˇr. na http://www.adempiere.com/Installation http://searchsoa.techtarget.com/definition/Java-Runtime-Environment http://www.eclipse.org
12
4. S YSTÉM AD EMPIERE
4.2
Uživatelské rozhraní
Struktura uživatelského rozhraní je podobná, at’ už probíhá pˇrístup pomocí kteréhokoliv výše zmínˇeného kanálu. Rozhraní je pomˇernˇe jasné a pˇrehlednˇe rozdˇelené, je zde však výrazná absence jakékoliv nápovˇedy cˇ i dokumentace, která by popisovala strukturu systému obecnˇe. První kontakt tak není zcela jednoduchý, což je však obvyklé pˇri seznamování se se zcela novým systémem. Po chvíli používání systému je pomˇernˇe snadné zvyknout si na jeho uspoˇrádání. Jakmile je ale nutné nˇeco nastavit a upravit, narazí cˇ lovˇek obvykle dˇríve nebo pozdˇeji na nˇejaké pole, u nˇejž je složité urˇcit, k cˇ emu slouží nebo jak funguje. V tomto smyslu nemuže ˚ být nápovˇeda snad nikdy dosti propracovaná. Pˇrínosem pro práci se systémem jsou tzv. workflows, tedy diagramy popisující krok za krokem nˇejaký proces (viz obrázek 4.1). Lze z nich alesponˇ cˇ ásteˇcnˇe vyˇcíst, co je tˇreba pro dosažení kýženého cíle. Bohužel jich v aplikaci je jen nˇekolik, takže nepostihují zdaleka všechny procesy. Pˇreklad rozhraní do cˇ eštiny není úplný a cˇ asto ani pˇresný. Pˇresnost a jednoznaˇcnost pˇrekladu je pˇritom pro bˇežné používání systému duležitá. ˚ Pˇreklady lze tvoˇrit pˇrímo pomocí uživatelského rozhraní ADempiere a jejich lepší zpracování by jistˇe bylo velkým pˇrínosem.
4.2.1 Práce s webovým rozhraním Webové rozhraní systému je pˇrehledné, rˇ ešené pomocí navigaˇcního menu a záložek (viz pˇríloha A). Rozhraní pracuje svižnˇe, avšak nˇekterá políˇcka se nezobrazují správnˇe - není napˇr. vidˇet konec pole (nelze kliknout na vyhledávací tlaˇcítko na jeho konci). To muže ˚ nˇekdy práci s rozhraním ztížit. Nˇekteré procesy a okna nelze z webového rozhraní spustit (pokud se nejedná o chybu místní instalace), napˇr. nelze z webového rozhraní vytvoˇrit nového klienta. Celkovˇe je vidˇet, že webové rozhraní je spíše urˇceno koncovým uživatelum ˚ než správcum ˚ systému. 13
4. S YSTÉM AD EMPIERE
Obrázek 4.1: Screenshot - workflow projektu
14
4. S YSTÉM AD EMPIERE 4.2.2 Práce s java klientem Práce s java klientem je o poznání pomalejší. Otevírání jednotlivých oken i zobrazení výsledku˚ z databáze déle trvá. Tato verze rozhraní funguje na bázi jednotlivých oken, pˇriˇcemž hlavní okno slouží jako hlavní navigaˇcní menu (viz pˇríloha A). Vzhled a rozvržení jednotlivých oken je témˇerˇ totožné s webovým rozhraním, pˇrechod mezi rozhraními tedy není žádným problémem a orientace je jednoduchá. Pozitivním faktem je, že java klienta není tˇreba lokálnˇe instalovat, pouze je nutné stáhnout a rozbalit si spouštˇecí soubory.
4.3
Nastavení a používání systému
V této cˇ ásti práce se pokusím více pˇriblížit postup, jak správnˇe systém nastavit. Vycházím pˇritom z cˇ ásti dokumentace nazvané ADempiere Implementation Details[6]. Z osnovy v citovaném zdroji byla vypuštˇena položka „Import poˇcáteˇcního stavu zásob“, jelikož není pro nás relevantní. 4.3.1 Detaily nastavení systému ADempiere 1.
Sbˇer potˇrebných dat
2.
Vytvoˇrení tabulky úˇctu˚
3.
Vytvoˇrení klienta
4.
Vytvoˇrení organizací, rolí a klíˇcových uživatelu˚
5.
Import nebo vytvoˇrení klíˇcových dat (a) Obchodní partneˇri (b) Produkty a ceníky (c)
Import poˇcáteˇcní rozvahy
(d) Import otevˇrených faktur a nepˇriˇrazených plateb 6.
Vytvoˇrení dokumentu, ˚ reportu˚ a formuláˇru˚ (a) Finanˇcní výkazy 15
4. S YSTÉM AD EMPIERE (b) Objednávky, faktury a platby (c) Reporty pro management 7.
Definice ukazatelu˚ výkonu
Než zaˇcneme nastavovat systém jako takový, je tˇreba shromáždit požadavky konkrétní firmy a další materiály, jako jsou otevˇrené objednávky, faktury, ceníky a také úˇcetní standardy. Aby bylo možné zaˇcít systém používat, je tˇreba nejdˇríve nastavit "klienta"(Client ), tedy spoleˇcnost - samostatnou úˇcetní jednotku - z role systémového administrátora. Pro vytvoˇrení nového klienta je nutné mít pˇripravenou tabulku úˇctu˚ ve formátu CSV (Comma Separated Values 1 ) - tzv. COA (Chart of Accounts) obsahující definice úˇctu˚ dle úˇcetních standardu˚ firmy s ohledem na potˇreby managementu. V cˇ eském prostˇredí musí definice úˇctu˚ vyhovovat také cˇ eským úˇcetním standardum ˚ 2 . Vzorové soubory COA mužeme ˚ najít pˇrímo v domovském adresáˇri ADempiere v adresáˇri data/import/ ˇ nebo pˇrímo cˇ eské úˇctovací osnovy na webu Ceské aliance pro podporu ADempiere http://www.adempiere.cz/. V tomto dialogu viz obrázek 4.2 také nastavíme jméno pro administrátora klienta a bˇežného uživatele klienta i nˇekolik dalších parametru. ˚ Jejich struˇcný popis lze najít na wiki ADempiere[7], aˇckoliv vzhled okna se v ruzných ˚ verzích systému drobnˇe liší. Po úspˇešném nahrání dat (trvá nˇekolik minut) se již lze pˇrihlásit jako administrátor klienta. Výchozím nastavením pˇri vytvoˇrení klienta je heslo pro každého uživatele stejné jako jeho uživatelské jméno. Dalším krokem je vytvoˇrení organizací. Pokud je tˇreba, lze definovat jednotlivé organizaˇcní složky a vnitropodnikovou strukturu. V našem pˇrípadˇe to nejspíš potˇreba nebude, proto tento krok mu˚ žeme vynechat. Spravovat jednotlivé uživatele je možné pomocí okna „Uživatel“ (cesta Menu -> Systémová administrace -> Obecná pravidla -> Bezpeˇcnost), pˇrihlásíme-li se jako administrátor klienta. V oknˇe „Uživatel“ lze zmˇenit heslo, pˇriˇradit uživatele k organizaˇcní složce, upravit role uživatele, zadat kontaktní informace a mnoho dalšího. Pod stejnou cestou najdeme také okno „Role“, v nˇemž je možnost nastavit 1. 2.
http://en.wikipedia.org/wiki/Comma-separated_values http://www.mfcr.cz
16
4. S YSTÉM AD EMPIERE
Obrázek 4.2: Logika nastavení systému ADempiere
17
4. S YSTÉM AD EMPIERE dosti podrobnˇe práva v rámci celého systému, pˇrístupy k oknum ˚ i procesum, ˚ úkolum, ˚ akcím apod. pro jednotlivé uživatelské role. Nastavení rolí pomocí webového klienta je pomˇernˇe hodnˇe zdlouhavý proces, protože na každou položku je nutné kliknout zvlášt’, tudíž doporuˇcuji tuto akci provést pomocí java klienta. Aplikace by v tomto procesu mˇela poskytovat možnost oznaˇcit všechna pole soucˇ asnˇe a naopak zrušit oznaˇcení všech polí. Tuto funkcionalitu nemá, pomoci nám však muže ˚ alesponˇ funkce kopírování rolí. Pro lepší pˇrehled o významu jednotlivých polí a jejich správném nastavení je zde opˇet ADempiere wiki[8]. Po dokonˇcení nastavení uživatelu˚ a rolí je tˇreba zkontrolovat, že je vše nastaveno, jak má být. Proto doporuˇcuji se pˇrihlásit postupnˇe jako jednotliví uživatelé a ovˇerˇ it si, že mají pˇrístup jen k tˇem cˇ ástem systému, které budou potˇrebovat ke své práci. Nadbyteˇcná nepotˇrebná funkcionalita muže ˚ daného uživatele bˇehem práce rozptylovat a cˇ iní uživatelské prostˇredí ménˇe pˇrehledným, nemluvˇe o potížích, jež muže ˚ zvˇedavý uživatel zpusobit, ˚ pokud se rozhodne prozkoumat nepoužívané cˇ ásti systému. Je tedy potˇreba urˇcit pˇresnou množinu funkcí a oken nutných a souˇcasnˇe postaˇcujících pro práci každého uživatele. Zde následuje nˇekolik tipu˚ pro nastavení uživatelu˚ a rolí: •
Pro aktivaci uživatele musí být aktivní nejen uživatel jako takový (pole „Active“), ale také alesponˇ jedna jemu pˇriˇrazená role, jinak nebude možné se pod jménem a heslem uživatele pˇrihlásit.
•
Pro nastavení pˇrístupových práv k jednotlivým procesum ˚ je užiteˇcné znát jejich funkci. Pˇrehled všech procesu˚ (a také všech ostatních prvku˚ aplikace v jiných oknech ve stejném umístˇení) je dostupný v úˇctu systémového administrátora (výchozí úˇcet System) v Menu -> Aplikaˇcní slovník (Application Dictionary) -> Sestavy & procesy (Report & Process).
•
V úˇctu administrátora je k dispozici proces pojmenovaný Role Access Update. Toto pojmenování je dle mého názoru nesprávné, protože dusledkem ˚ spuštˇení tohoto procesu není aktualizace pˇrístupových práv, kdežto smazání všech nastavení a nastavení na puvodní ˚ hodnoty u vybraného úˇctu. Pˇríhodnˇejší 18
4. S YSTÉM AD EMPIERE by proto zde bylo pojmenování Role Access Reset. Tomuto smazání lze zabránit, pokud v oknˇe Role oznaˇcíme položku Manual. V takovém pˇrípadˇe se spuštˇením procesu práva nezmˇení. V pátém bodˇe je tˇreba zamˇerˇ it se na data firmy. Jak již bylo rˇ eˇceno výše, výhodou zaˇcínající firmy je, že dat existuje málo nebo žádná. Proces nastavení nového obchodního partnera, tedy zákazníka cˇ i dodavatele, je ponˇekud zdlouhavý, ale nijak složitý. Pomocí workflow „Nastavení obchodního partnera“ (Business Partner Setup) se v nˇem lze pomˇernˇe snadno zorientovat. Vytvoˇrení produktu˚ a ceníku˚ bude nejspíš naopak rychlé, protože firma pravdˇepodobnˇe žádné produkty nemá. Pokud ano, opˇet je zde na pomoc workflow „Nastavení produktu“ (Product Setup). Ponˇekud více pracné bude nastavení úˇcetnictví, tedy import pocˇ áteˇcní rozvahy, otevˇrených faktur a nepˇriˇrazených plateb. Naštˇestí je tato cˇ ást nastavení systému dobˇre zdokumentovaná, viz [adempiere3]. Zbývající pod-body bodu 6 a bod 7 by taktéž již mˇely být pomˇernˇe snadné, navíc je velmi pravdˇepodobné, že malá nebo zaˇcínající firma bude tato nastavení postupnˇe pˇrizpusobovat ˚ potˇrebám až bˇehem dalšího používání systému, nebo je zatím nebude potˇrebovat vubec ˚ (napˇr. reporty cˇ i pˇrehledy pro management nebo ukazatele výkonu). Opˇet se bˇehem tˇechto kroku˚ mužeme ˚ setkat s nepˇresnostmi v názvech a dalšími drobnými nepˇríjemnostmi, jež by ale nemˇely být vˇetší pˇrekážkou. Tímto by tedy mˇel být systém pˇripraven k používání. Pro zaˇcínající firmu muže ˚ být samotné nastavení systému otázkou nˇekolika dní, což není pˇríliš velká investice, za podmínky že firma bude systém pozdˇeji naplno využívat. Další procesy v systému, potˇrebné pro bˇežné fungování podniku, jsou již provˇerˇ ené množstvím firem, které se pro nasazení systému ADempiere rozhodly. Velkou výhodou je zcela jednoduchý postup úprav systému, cˇ emuž bych se ráda vˇenovala v následující cˇ ásti práce.
4.4
Úpravy systému
Pokud lze nˇekterý rys systému ADempiere považovat za opravdu velkou výhodu, pak je to jednoznaˇcnˇe jeho schopnost upravit jaké19
4. S YSTÉM AD EMPIERE koliv okno, proces, pole atd. pˇresnˇe na míru potˇrebám. Ne každá úprava je pˇritom zcela triviální, ale oproti jiným systémum ˚ je zpusob ˚ úprav ADempiere skuteˇcnˇe nadˇcasový. Nedostatkem tohoto, jinak skvˇelého, pˇrístupu, je opˇet nedostateˇcné zpracování dokumentace, které zpusobuje ˚ nˇekdy zbyteˇcné prostoje pˇri hledání toho správného zpusobu ˚ cˇ i rˇ ešení. Dusledkem ˚ výše uvedeného je fakt, že mnoho úprav si firmy dokáží jednoduše implementovat samy (pˇrípadnˇe prostˇrednictvím dodavatelské firmy) a systém jako takový není zasažen neustálým rozšiˇrováním funkcionality, kterou využije jen nepatrné množství firem. Z mé osobní zkušenosti je totiž právˇe takové neustálé pˇridávání neduležité ˚ funkcionality jedním z nejhorších neduhu˚ velkých podnikových systému. ˚ Na puvodní ˚ procesy se v takových pˇrípadech nabalují další a další funkce, možnosti a volby, takže nakonec ani spoleˇcnost, která systém vyvíjí, není schopna poskytnout rychlou podporu svým zákazníkum, ˚ protože sami zamˇestnanci dodavatele nevˇedí, k cˇ emu nˇekteré cˇ ásti systému slouží, a v mnoha pˇrípadech není ani schopna zjistit pˇríˇcinu nestandardního chování systému.
4.5
Nedostatky systému ADempiere
Nedostatku˚ systému existuje více, nˇekteré pramení pˇrímo z povahy open-source, jiné jsou specifické pro ADempiere a nˇekteré vlastnosti systému jsou na pomezí, protože mají i své výhody (více viz [1]). Ráda bych se nyní zamˇerˇ ila pˇredevším na nedostatky uživatelského rozhraní a funkcí systému. Jako u každého systému, i u ADempiere je tˇreba zvyknout si na urˇcité názvosloví a porozumˇet tomu, jak byly nˇekteré názvy cˇ i popisky myšleny. ADempiere je puvodem ˚ francouzský systém a domnívám se, že i proto se názvosloví dosti liší od jiných ERP systému, ˚ puvodem ˚ napˇr. z USA, což muže ˚ být matoucí. Nicménˇe navíc, z du˚ vodu neúplného nebo nepˇresného pˇrekladu webového rozhraní do cˇ eštiny, se cˇ asto stává, že není jasné, k cˇ emu má dané pole nebo okno sloužit. V takovém pˇrípadˇe je tˇreba pˇrejít do anglického jazyka, což ale lze pouze pomocí odhlášení a opˇetovného pˇrihlášení. Jako nejschudnˇ ˚ ejší rˇ ešení této nepˇríjemnosti se zdá být vylepšení cˇ eského pˇrekladu do té míry, aby bylo možné systém plnohodnotnˇe použí20
4. S YSTÉM AD EMPIERE vat v cˇ eském jazyce. Tento nedostatek by mˇel být vyˇrešen pˇred tím, než bude systém nasazen do reálného provozu. Za jeden z hlavních nedostatku˚ uživatelského rozhraní ADempiere považuji to, že informace se zobrazují ve formuláˇrových polích, jako bychom je chtˇeli upravovat. V mnoha pˇrípadech však uživatel nebude moci informace upravovat, nebo je zkrátka nebude chtít upravovat. Zobrazení v polích je vcelku nepˇrehledné a velmi obtížnˇe se v nˇem orientuje. Na druhou stranu má toto zobrazení i své výhody, protože omezuje poˇcet nutných kliknutí, která musí uživatel provést, aby mohl záznam editovat nebo s ním jinak dále pracovat. Výrazným nedostatkem ADempiere je také nedostateˇcnˇe zpracovaná uživatelská dokumentace. Pokud má systém efektivnˇe sloužit zaˇcínajícím firmám, musí být jednoduše dohledatelné co a jak funguje, kde nastavit potˇrebné funkce, k cˇ emu které pole slouží atd. Existující nápovˇeda je dostupná z témˇerˇ každého okna pomocí ikony s otazníkem a je taktéž pˇrístupná online na ADempiere wiki, což je obojí rozhodnˇe pozitivní. Co se týˇce funkˇcní stránky, bohužel v ADempiere zatím chybí sledování a záznamy o docházce a vytížení zamˇestnancu. ˚ Protože právˇe lidé jsou jedním z nejduležitˇ ˚ ejších pilíˇru˚ v IT firmách, mohl by tento nedostatek být znaˇcný. Mnoho vylepšení potˇrebuje i modul projektového rˇ ízení (z pohledu vývoje softwarových produktu), ˚ který dle mého názoru v ADempiere mnoho firem nepotˇrebuje nebo nepoužívá. Nástroju˚ pro projektové rˇ ízení nakonec existuje mnoho (i open-source), takže možná neexistuje žádná velká potˇreba tento nedostatek akutnˇe rˇ ešit. Jelikož se však domnívám, že by vylepšení této cˇ ásti systému bylo užiteˇcné pro mnoho IT firem a napomohlo vˇetšímu rozšíˇrení systému ADempiere, vybrala jsem si právˇe tuto cˇ ást jako stˇežejní pro zbytek této práce. Již pˇredem je však tˇreba rˇ íci, že vytvoˇrit kvalitní modul pro rˇ ízení softwarových projektu˚ je jistˇe úkol na více než jednu diplomovou práci.
4.6
ADempiere jako služba
Využívání ERP systému˚ jako služeb (SaaS ) je již pomˇernˇe bˇežnou praxí pˇredevším pro malé a stˇrední podniky. Jde pˇritom v první rˇ adˇe o úsporu nákladu˚ na provoz takového systému. Prvním pˇredpokla21
4. S YSTÉM AD EMPIERE dem pro nasazení software pomocí tohoto modelu je dostupnost webového rozhraní. Tuto podmínku ADempiere splnuje. ˇ Druhým pˇredpokladem, který vychází již z definice SaaS, je možnost rychlého nasazení. Uvažováno v obecné rovinˇe, tento pˇredpoklad by nebyl pro ADempiere splnitelný, aˇckoliv, jak již bylo zmínˇeno, v urˇcitých smˇerech je ADempiere velmi lehce upravitelný. Protože nutnost a rozsah úprav systému prodlužuje dobu jeho nasazení, je však teoreticky možné dosáhnout podstatného zkrácení této doby poskytováním systému v takové podobˇe, v níž jej nebude nutné pˇríliš upravovat. Z opaˇcného pohledu lze tento požadavek na rychlost nasazení také splnit omezením množiny potenciálních zákazníku˚ na spoleˇcnosti s podobným profilem a potˇrebami. Závˇerem lze rˇ íci, že systém ADempiere je vhodný pro poskytování formou služby za pˇredpokladu, že bude pˇredem uzpusoben ˚ pro urˇcitý typ podniku a dále bude nabízen pouze spoleˇcnostem spadajícím do této vybrané kategorie.
4.7
Využití systému ADempiere v rámci výuky
Kromˇe již zminovaného ˇ využití systému ADempiere v IT firmách se nabízí jeho další uplatnˇení také na akademické pudˇ ˚ e univerzity. K tomu pˇrispívá také fakt, že se jedná o open-source systém. Podnikových ERP systému˚ na trhu pˇribývá a tím také pˇribývá firem nabízejících jejich nasazení s správu, pˇrípadnˇe tˇech, které vyvíjejí systém vlastní. Pro studenty Fakulty informatiky (a domnívám se, že napˇr. i pro absolventy Ekonomicko-správní fakulty) by bylo jen výhodou mít možnost se s takovým systémem seznámit ještˇe bˇehem studia, protože pravdˇepodobnost, že se s podobným systémem setkají pozdˇeji v praxi, je cˇ ím dál tím vyšší. Kromˇe toho by mˇeli studenti díky flexibilitˇe systému ADempiere také možnost vyzkoušet si návrh a tvorbu vlastního okna, modulu cˇ i procesu, což jsou jedineˇcné praktické zkušenosti, které mnohým studentum ˚ v souˇcasnosti schází. Pˇrínos ADempriere je v tomto smˇeru ještˇe vyšší díky skuteˇcnosti, že se jedná o systém opravdu používaný v praxi, ne o fiktivní aplikaci nebo nˇejaký smyšlený pˇríklad. Kromˇe informatických znalostí mohou studenti získat také pˇrehled o základních byznys procesech, 22
4. S YSTÉM AD EMPIERE jako jsou zpracování objednávek, fakturace, úˇcetní procesy, výrobní procesy, logistika a další. Domnívám se, že tyto znalosti jsou pro studenty rovnˇež duležité ˚ z duvodu ˚ rozšiˇrování jejich obzoru˚ a poznávání souvislostí. Vˇerˇ ím, že by bylo možné využít systém ADempiere v nˇekterých již existujících pˇredmˇetech na Fakultˇe informatiky, nebo dokonce v novém samostatném pˇredmˇetu. Nabízí se také možnost spojit jej s fungováním nˇekteré laboratoˇre, napˇr. laboratoˇre systému˚ služeb.
23
5 Nástroje pro projektové rˇízení Jedna z definic projektového rˇ ízení (nebo také rˇ ízení projektu), ˚ anglicky Project management, rˇ íká, že jde o „zpusob ˚ rozplánování a realizaci složitých, zpravidla jednorázových akcí, které je potˇreba uskuteˇcnit v požadovaném termínu s plánovanými náklady tak, aby se dosáhlo stanovených cílu“ ˚ 1 . Pˇreklad „projektové rˇ ízení“ z anglického názvu není pˇresný a nevystihuje pˇresnˇe význam tˇechto slov, ale jedná se o zavedený termín používaný mj. Spoleˇcností pro proˇ jektové rˇ ízení2 , která je certifikaˇcním orgánem IPMA3 v Ceské republice, a proto jej budu používat také v rámci své práce. Tato kapitola podává pˇrehled nástroju˚ pro projektové rˇ ízení a jejím cílem je zjistit, jakým zpusobem ˚ by bylo nejvýhodnˇejší dále rozvíjet modul pro projektové rˇ ízení v ADempiere. Podpora plánování a rˇ ízení projektu˚ integrované pˇrímo do ERP systému pˇrináší firmám zabývajícím se zakázkovou cˇ inností mnoho výhod. Mezi nˇe patˇrí pˇredevším provázanost s kompletními informacemi a procesy ve firmˇe, pˇrístup zamˇestnancu˚ na jediné místo a jednoduchá zmˇena metodiky vývoje.
5.1
Pˇrehled nástroju˚ pro projektové rˇízení
Nástroju˚ pro projektové rˇ ízení, at’ už se jedná o webové nebo klasické aplikace, existuje mnoho. Zamˇerˇ uji se zde pouze na nˇekolik nejvýznamnˇejších a nejrozšíˇrenˇejších open-source nástroju˚ a pak na zˇrejmˇe nejpoužívanˇejší komerˇcní webovou aplikaci Basecamp. 5.1.1 Redmine Redmine4 je webová aplikace založená na frameworku „Ruby on Rails“5 urˇcená pro projektové rˇ ízení. Tato aplikace je multiplatformní ˇ 1. http://cs.wikipedia.org/wiki/Rízení_projekt u˚ 2. http://www.ipma.cz/ 3. http://www.ipma.ch/ 4. http://www.redmine.org 5. http://rubyonrails.cz/
24
ˇ 5. N ÁSTROJE PRO PROJEKTOVÉ RÍZENÍ
a databázovˇe nezávislá. Podporuje rˇ ízení projektu˚ i programu, ˚ pˇrístup uživatelu˚ je kontrolován na základˇe nastavitelných rolí, souˇcástí je verzovací systém, umožnuje ˇ zobrazení projektu pomocí Ganttova diagramu a kalendáˇre a nechybí zde ani úložištˇe souboru, ˚ správa úkolu˚ a wiki. Redmine je velmi oblíbenou a hojnˇe využívanou aplikací pro nejruznˇ ˚ ejší, pˇredevším IT, projekty. 5.1.2 Trac Trac1 je minimalistická webová aplikace pro projektové rˇ ízení softwarových projektu. ˚ Poskytuje rozhraní pro verzovací systém Sub2 version , integrovanou wiki a umožnuje ˇ vedení záznamu˚ o projektu. Trac je napsán v jazyce Python a je urˇcen pˇredevším programátorum. ˚ Oproti Redmine je o nˇeco málo ménˇe uživatelsky pˇrívˇetivý, ale hlavnˇe neposkytuje možnost zobrazit Ganttuv ˚ diagram projektu a neoplývá ani žádnými jinými „vymoženostmi“ - podle tvurc ˚ u˚ zámˇernˇe, aby zbyteˇcnˇe aplikace neodvádˇela pozornost uživatele od práce. 5.1.3 Project Open Project open3 je aplikace fungující na AOLServeru4 vybudovaná na platformˇe OpenACS5 a napsaná v jazyce TCL6 . Jedná se o komplexní nástroj pro projektové rˇ ízení a týmovou spolupráci, pokrývající mnoho ruzných ˚ oblastí projektu od pˇrehledu˚ využití jednotlivých zdroju, ˚ pˇres sledování nepˇrítomnosti uživatelu, ˚ zaznamenávání chyb, urˇcování a sledování milníku˚ až po finance. K dispozici je také kalendáˇr, zjednodušená verze Ganttova diagramu i možnost exportu projektu do open source aplikace GanttProject7 (a importu z ní), kde lze zobrazit plnohodnotný Ganttuv ˚ diagram a upravovat jej, i mj. pracovat s analýzou PERT 8 . 1. 2. 3. 4. 5. 6. 7. 8.
http://trac.edgewall.org http://subversion.tigris.org/ http://www.project-open.com/ http://www.aolserver.com/ http://openacs.org/ http://www.tcl.tk/ http://www.ganttproject.biz/ http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique
25
ˇ 5. N ÁSTROJE PRO PROJEKTOVÉ RÍZENÍ
5.1.4 Collabtive Collabtive1 je jednoduchá a uživatelsky velmi pˇrívˇetivá webová aplikace fungující na cloudu urˇcená pˇredevším pro týmovou spolupráci na projektech. Umožnuje ˇ nastavení milníku, ˚ tvorbu seznamu˚ úkolu, ˚ posílání zpráv, zobrazení v kalendáˇri, správu uživatelu˚ a sleduje cˇ as strávený na projektu a souˇcástí je také úložištˇe souboru. ˚ Ve verzi zdarma opˇet chybí Ganttuv ˚ diagram a nenajdeme zde ani verzovací systém. Ganttuv ˚ diagram a další nástroje jako napˇr. podporu prioritizace projektu˚ a úkolu˚ lze k aplikaci dokoupit ve formˇe doplnk ˇ u. ˚ 5.1.5 Basecamp Basecamp2 je úspˇešná, neuvˇerˇ itelnˇe jednoduchá a intuitivní webová aplikace založená na cloudu pro projektové rˇ ízení a týmovou spolupráci. Jedná se o komerˇcní aplikaci, je však zdarma k vyzkoušení na 15 dní. Vše potˇrebné lze v této aplikaci najít na nˇekolika málo stránkách, pˇrehlednˇe uspoˇrádané, s mnoha možnostmi, které ale zárovenˇ nijak nepˇrekážejí. Pro zobrazení práce na projektu, at’ už vlastní, nebo všech spolupracovníku, ˚ používá aplikace vlastní zobrazení pomocí cˇ asové osy smˇerˇ ující zdola nahoru, na níž jsou zaznaˇceny akce uživatele cˇ i uživatelu. ˚ 5.1.6 Gantt Project Aplikace Gantt Project3 dokáže zobrazit projekt pomocí Ganttova diagramu, vypoˇcíst PERT, pˇriˇrazovat lidské zdroje k jednotlivým úkolum, ˚ importovat projekty v Microsoft Project a také je do tohoto formátu exportovat. Jedná se o open-source software.
5.2
Požadavky na nástroje pro projektové rˇízení
Aby bylo možné vyhodnotit aktuální stav projektového rˇ ízení v systému ADempiere a dále pracovat s touto oblastí, je tˇreba stanovit 1. 2. 3.
http://collabtive.o-dyn.de/ http://www.basecamp.com http://www.ganttproject.biz/
26
ˇ 5. N ÁSTROJE PRO PROJEKTOVÉ RÍZENÍ
požadavky, které jsou na ni kladeny. Vyjdeme-li ze studie[9] NASA1 , která byla zpracována jako výchozí dokument pro výbˇer nástroju˚ pro projektové rˇ ízení, jsou v jednotlivých oblastech hlavními požadovanými vlastnostmi tyto: •
Architektura, správa dat - pˇrístup pro mnoho uživatelu˚ soucˇ asnˇe, správa a spolupráce mnoha projektu˚ souˇcasnˇe, spolupráce s klientskými aplikacemi vˇc. importu a exportu, schopnost integrace uživatelem zadaných parametru˚
•
Pˇrehledy - standardní a upravené pˇrehledy a nástroje pro shrnutí
•
Funkce pro projektové rˇízení (rozvrhy, náklady, zdroje, výkon, rˇízení rizik) –
– –
WBS (Work Breakdown Structure) a OBS (Organization Breakdown Structure), Ganttuv ˚ diagram a PERT analýza, definice mnoha zdroju˚ a kalendáˇru˚ ˇ Rízení rizik a analýza pˇridané hodnoty Sledování nákladu, ˚ rozdíly nákladu, ˚ finanˇcní zdroje, závazky a úpisy
•
Spolupráce, webový pˇrístup - schopnost zobrazení v HTML, pˇrístupnost funkcí, možnost a metody pro zveˇrejnování, ˇ upozornˇení emailem
•
Jednoduché používání - intuitivní, jednoduchý vzhled pˇripomínající jiné bˇežné klientské aplikace
•
Pˇrístup uživatelu˚ a bezpeˇcnost - pˇrístup a správa na úrovni uživatele i projektu
5.3
Projektové rˇízení v ADempiere
V souˇcasné instalované verzi ADempiere (verze 3.5.4a) je modul projektového rˇ ízení zamˇerˇ en spíše na výrobní projekty. Samotný fakt, 1.
http://www.nasa.gov/
27
ˇ 5. N ÁSTROJE PRO PROJEKTOVÉ RÍZENÍ
že zde projektové rˇ ízení není pˇrímo zamˇerˇ eno na softwarové projekty, by u jiných cˇ ástí systému nemusel být pˇrekážkou (pokud by s danou komponentou bylo možné pracovat potˇrebným zpusobem). ˚ U projektového rˇ ízení je však duležité, ˚ aby byla aplikace pˇrehledná, neobsahovala irelevantní informace a poskytovala dobré prostˇredí pro projektového manažera i vývojový tým. Z tohoto pohledu je prostˇredí ADempiere zcela nevyhovující, protože díky složitosti výrobních projektu˚ obsahuje rozmˇery, které jsou pro softwarové projekty nepodstatné, ani je nelze naplnit smysluplnými daty. Dále celkové rˇ ešení hlášení (rozdˇelení na cykly a kroky) a rozdˇelení projektu˚ na fáze a úkoly je v dusledku ˚ konkrétního rˇ ešení ponˇekud matoucí a nedává pˇríliš smysl. Nastavení sekvence (Sequence, zpusob ˚ rˇ azení položek) a celkové fungování aplikace je zde tak trochu „ˇcernou skˇrínˇ kou“, pˇredevším z duvodu ˚ absence uživatelské dokumentace. Ráda bych se nyní zamˇerˇ ila na základy existujícího projektového rˇ ízení v aplikaci, z nˇehož vyjdu dále pˇri tvorbˇe nového modulu. Pˇred vytvoˇrením samotného projektu je tˇreba definovat typ projektu a nastavit hlášení (Reporting). Vytvoˇrit typ projektu v podstatˇe znamená jen vytvoˇrit nový typ pro danou organizaci a dát mu název, vyplnit popis a oznaˇcit nový typ projektu jako aktivní. Nastavení hlášení je provádˇeno na dvou úrovních, v první na úrovni cyklu projektu (Project cycle) a dále na úrovni kroku (Step). Cyklus i krok je tˇreba pojmenovat a u kroku nastavit sekvenci. V dalším kroku lze definovat standardní fáze a úkoly v daném typu projektu. Fáze se vztahuje k typu projektu a opˇet je tˇreba vyplnit název a popis, dále sekvenci, produkt a jeho množství. Produkt je tˇreba vybrat z produktu˚ zavedených v systému, tedy ze „zboží“. Pro softwarové projekty by bylo vhodnˇejší, kdyby produkt byl pouze popis výstupu, množství pak bude zˇrejmˇe vždy 1. Standardní úkol je, co se zadávaných informací týˇce, zcela shodný s fází, pouze se nevztahuje k typu projektu, ale ke standardní fázi. Pˇri vytváˇrení samotného projektu je již údaju˚ a voleb podstatnˇe více. V první cˇ ásti je tˇreba opˇet vyplnit název a obecná data o projektu vˇcetnˇe data podpisu smlouvy a data ukonˇcení projektu. V této cˇ ásti také musíme zvolit Line Level, kde je na výbˇer fáze, projekt a úkol. Mužeme ˚ se domnívat, že se jedná o volbu detailu, tedy jak podrobnˇe chceme projekt sledovat. Ve druhé cˇ ásti okna nazvané Reference jsou umístˇeny údaje o obchodním partnerovi, tedy zákaz28
ˇ 5. N ÁSTROJE PRO PROJEKTOVÉ RÍZENÍ
níkovi, ve tˇretí cˇ ásti s názvem Amounts lze nastavit cenu projektu, plánovaný zisk, množství (zˇrejmˇe produktu) a pravidla pro fakturaci. V poslední cˇ ásti vidíme historii projektu - fakturovanou cˇ ástku a fakturované množství produktu. Pomocí dvou tlaˇcítek Copy Details a Close Project mužeme ˚ projekt zkopírovat nebo oznaˇcit jako ukonˇcený.
5.4
ˇ Rešení pro ADempiere
Po dukladném ˚ pruzkumu ˚ se mi nepodaˇrilo nalézt žádný software pro projektové rˇ ízení, který by bylo možné nˇejakým zpusobem ˚ se systémem ADempiere pˇrímo propojit, a pravdˇepodobnˇe je to z toho duvodu, ˚ že žádný neexistuje. Jedinou možností se zdá být využití aplikace Gantt Project pro zobrazení Ganttova diagramu a PERT. Pro tuto aplikaci by v ADempiere musel existovat export a import projektu ve formátu .gan. Vše ostatní bude pravdˇepodobnˇe muset být implementováno pˇrímo do ADempiere. Vzhledem k tomu, že nástroju˚ pro projektové rˇ ízení existuje opravdu mnoho, jeví se jako nejlepší cesta následovat jejich ovˇerˇ ené postupy a inspirovat se již hotovými rˇ ešeními. Tento zpusob ˚ návrhu a implementace by mˇel být nejen jednodušší než zacˇ ínat zcela od zaˇcátku, ale také je zde urˇcitá jistota úspˇechu, protože vycházíme z toho, co již funguje a co mnoho lidí na celém svˇetˇe opravdu používá.
29
6 Modul rˇízení softwarových projektu˚ Implementace celého rˇ ízení softwarových projektu˚ není záležitostí na jednu diplomovou práci. Jedná se o komplexní projekt, který bude muset být postupnˇe realizován v nˇekolika fázích. Tato práce se zamˇerˇ uje pˇredevším na specifikaci toho, jak by takový modul mˇel vypadat, vytvoˇrení základu pro jeho implementaci a zapoˇcetím samotné implementace. Za duležitý ˚ faktor pˇri realizaci tohoto projektu považuji vytvoˇrení kvalitní dokumentace. I v tomto ohledu tato práce tvoˇrí urˇcitý základ pro další cˇ innost na projektu. Jelikož základ pro projektové rˇ ízení v ADempiere již existuje, bylo by neefektivní jej nevyužít. Schéma databázových tabulek využívaných tímto modulem lze najít na ADempiere wiki 1 . Jedná se o jádro systému, takže tabulky mají prefix „C_“ (z anglického Core). Pu˚ vodní zpracování projektového rˇ ízení v systému není špatné, pouze je tˇreba jej pro softwarové produkty zjednodušit a pˇridat novou funkcionalitu. Puvodní ˚ funkcionalita by mˇela zustat ˚ v systému zachována tak, aby bylo možné ji kdykoliv využít soubˇežnˇe s novými cˇ ástmi systému. Aby bylo tohoto dosaženo, bude vytvoˇren zcela nový modul s nᡠzvem „Rízení SW projektu“. ˚
6.1
Návrh
Cílem projektu je nový funkˇcní modul pro rˇ ízení softwarových projektu, ˚ který bude poskytovat prostˇredí použitelné pro reálné projekty. Tento modul by mˇel poskytovat základ pro další budoucí rozšiˇrování tak, aby v rámci nˇeho mohla být pozdˇeji implementována tato okna a funkce: •
Projekt - vytvoˇrení nového projektu, vytvoˇrení podprojektu˚ (ˇrízení programu˚ a portfolií), pˇrehled údaju˚ o projektu, pˇrehled všech projektu, ˚ urˇcení fází, milníku˚ a pˇredem známých úkolu˚ projektu
•
WBS, PBS, OBS - vytvoˇrení a úpravy WBS, PBS a OBS pro-
1.
http://www.adempiere.com/How_Projects_Work
30
ˇ ˚ 6. M ODUL RÍZENÍ SOFTWAROVÝCH PROJEKT U
jektu •
Zdroje - pˇriˇrazení lidských zdroju˚ k projektu, sledování jejich vytížení, absencí, sledování cˇ asu stráveném na projektu
•
Úkoly - zaznamenávání úkolu˚ formou ticketovacího systému, tzn. vytvoˇrení úkolu, zobrazení seznamu úkolu˚ s možností filtrování výsledku˚ dle ruzných ˚ kritérií a možností pˇriˇradit úkol (z role nadˇrízeného jinému zamˇestnanci nebo každý uživatel sám sobˇe)
•
Upozornování ˇ emailem - upozornˇení na vytvoˇrení nového úkolu, na pˇriˇrazení úkolu, na blížící se termín dokonˇcení úkolu a další události
•
Zobrazení v cˇ ase - zobrazení cˇ asového sledu úkolu˚ formou zjednodušeného Ganttova diagramu a pomocí kalendáˇre
•
Sledování financí - nastavení typu fakturace, sledování faktur a množství vyfakturované práce, vytvoˇrení a sledování rozpoˇctu projektu
•
Export a import projektu do Gantt project, pˇrípadnˇe do MS Project
Co se vzhledu a uživatelské pˇrívˇetivosti týˇce, je pro mne osobnˇe inspirací pˇredevším výše zmínˇená aplikace Basecamp. Aˇckoliv projekty mohou být složité, aplikace by je mˇela zobrazovat jasnˇe a pˇrehlednˇe, cˇ ímž skuteˇcnˇe usnadní práci všem spolupracovníkum ˚ na projektu. Systém ADempiere však má v tomto smˇeru svá omezení, protože se jedná o komplexní aplikaci. Zmˇena vzhledu je možná, ale nejspíše by nebyla velkým pˇrínosem, protože v rámci jedné aplikace by ruzný ˚ vzhled jednotlivých cˇ ástí mohl být pro uživatele matoucí. Z tohoto duvod ˚ u˚ zustaneme ˚ u výchozího vzhledu systému. 6.1.1 Typ projektu Každý projekt lze rozdˇelit na menší cˇ i vˇetší cˇ ásti, což pomáhá manažerovi udržet si pˇrehled o všech aspektech projektu. V této práci nazývám tyto cˇ ásti fáze (Phases) projektu. Fáze mužeme ˚ dále dˇelit na jednotlivé úkoly (Tasks). 31
ˇ ˚ 6. M ODUL RÍZENÍ SOFTWAROVÝCH PROJEKT U
Analýza požadavku˚ Uvažujeme-li firmu, zabývající se vývojem na zakázku, je velmi pravdˇepodobné, že se zabývá vývojem urˇcitého typu aplikací, at’ už jde o mobilní aplikace, webové aplikace, úpravy software na míru aj. Projektoví manažeˇri v takových pˇrípadech používají podobné postupy pro ruzné ˚ projekty stejného typu a i jednotlivé cˇ ásti projektu˚ mají spoleˇcné rysy. Proto se jeví jako vhodné zohlednit tyto spoleˇcné rysy i v návrhu tohoto projektového modulu. Hlavní motivací k vytvorˇ ení typu projektu je možnost využívat jednu hrubou šablonu projektu pro mnoho ruzných ˚ jednotlivých projektu˚ bez nutnosti nastavovat vše znovu, což povede k zefektivnˇení plánování projektu. Typ projektu, vˇcetnˇe fází a úkolu, ˚ by mˇel být jednoduše srozumitelný a použitelný, což podle mého názoru tento nový koncept splnuje. ˇ Návrh ˇ Celková logika modulu Rízení SW projektu˚ navazuje na logiku moˇ dulu Rízení projektu a je znázornˇena na obrázku 6.1. Nejdˇríve bude tˇreba nastavit obecný typ projektu a jeho standardní fáze a úkoly. K tomu bude sloužit okno nazvané Typ projektu (Project Type). Návrh polí v tomto oknˇe mužeme ˚ vidˇet na obrázku 6.2. Všechna pole jsou textová. Záložkami tohoto hlavního okna by mˇela být okna Standardní fáze (Standard Phases) a Standardní úkoly (Standard Tasks) (viz obrázek 6.3 a 6.4). Standardní fáze a úkoly budou definovány bez pˇredem daného poˇradí (v pˇrípadˇe potˇreby lze obvyklé poˇradí pro referenci vepsat do poznámky fáze/úkolu), konkrétní poˇradí bude urˇceno až v rámci konkrétního projektu. Tento pˇrístup umožní mj. prubˇ ˚ eh nˇekolika fází/úkolu˚ souˇcasnˇe. Implementace Pro vytvoˇrení okna a záložek bylo tˇreba v databázi adempiere vytvorˇ it nové tabulky c_sw_project_type, c_std_phase a c_std_task. Detail tabulek je znázornˇen na obrázku ERD databázových tabulek v pˇríloze B této práce nebo jej lze též najít v elektronických pˇrílohách. Hlavní okno Typ projektu je v hierarchii záložek na úrovni nula, 32
ˇ ˚ 6. M ODUL RÍZENÍ SOFTWAROVÝCH PROJEKT U
ˇ Obrázek 6.1: Znázornˇení logiky modulu Rízení SW projektu. ˚ Pˇrerušované cˇ áry naznaˇcují nepovinný vztah.
Obrázek 6.2: Návrh okna Typ projektu 33
ˇ ˚ 6. M ODUL RÍZENÍ SOFTWAROVÝCH PROJEKT U
Obrázek 6.3: Návrh okna Typ projektu, záložka Fáze
Obrázek 6.4: Návrh okna Typ projektu, záložka Úkoly
34
ˇ ˚ 6. M ODUL RÍZENÍ SOFTWAROVÝCH PROJEKT U
záložka Standardní fáze má pˇriˇrazenou úrovenˇ 1 a odkazuje se na primární klíˇc c_sw_project_type_ID tabulky c_sw_project_type a záložka Standardní úkoly má pˇriˇrazenou úrovenˇ 2 a odkazuje se na primární klíˇc c_std_phase_ID tabulky c_std_phase. Pomocí odkazu˚ na primární klíˇc (nebo obecnˇe jakýkoliv sloupec) pˇredchozí tabulky se automaticky v oknˇe vyplní odpovídající pole, která jsou nyní pouze ke cˇ tení, a systém tak zajistí správnou provázanost jednotlivých záznamu. ˚ 6.1.2 Nastavení jednotek práce Okno Nastavení jednotek práce (Work Units Setup) je umístˇeno samostatnˇe v menu SW Project Management. Analýza požadavku˚ Pˇri plánování projektu je cˇ asto potˇreba zjistit, kolik cˇ asu bude zapotˇrebí ke splnˇení daného úkolu. Tento odhad bývá obvykle vyjádrˇ en v hodinách. Poˇcet hodin nám však nestaˇcí k odhadu toho, kdy bude úkol dokonˇcen, protože je známo, že žádný cˇ lovˇek nepracuje 60 minut v hodinˇe, 8 hodin osmihodinové pracovní doby dennˇe. Kromˇe vyrušujících faktoru˚ (emaily, online chaty, ostatní spolupracovníci, schuzky ˚ atd.), nutnosti zjišt’ovat informace pro splnˇení daného úkolu a lidských potˇreb (potˇreba jíst, pít atd.) je tˇreba poˇcítat také s absencemi na pracovišti (nemoci, dovolené, státní svátky, pˇríp. pracovní cesty). Všechny tyto vlivy se odrážejí ve skuteˇcném objemu odvedené práce za cˇ asovou jednotku. Pro vyjádˇrení tohoto objemu používáme Jednotky práce (Work Units), tj. cˇ lovˇeko-hodiny, cˇ lovˇeko-dny 1 a další vyšší jednotky, které se bˇežnˇe v projektovém rˇ ízení používají. Návrh Protože výpoˇcet hodnoty cˇ lovˇeko-hodiny a dalších jednotek je velmi závislý na konkrétní firmˇe, odvˇetví, vykonávané práci, typu projektu a dalších faktorech a protože tyto hodnoty se mohou lišit pˇri 1.
Man-Days, Man-Hours http://en.wikipedia.org/wiki/Man-hour
35
ˇ ˚ 6. M ODUL RÍZENÍ SOFTWAROVÝCH PROJEKT U
Obrázek 6.5: Návrh okna Nastavení jednotky práce rˇ ešení ruznˇ ˚ e složitých projektu, ˚ vzahuje se toto nastavení k typu projektu a bude dále použito pro automatické pˇrepoˇcítávání mezi tˇemito jednotkami. Rozvržení okna Nastavení jednotky práce (Work Units Setup) lze vidˇet na obrázku 6.5. Typ projektu by nemˇel umožnovat ˇ zadání jiné než existující hodnoty (typu projektu) a pole pro pomˇer jednotek nesmí umožnovat ˇ zadání hodnoty menší než jedna, vzhledem k tomu, že pomˇer vztahujeme vždy k menším jednotkám. Implementace Pole výbˇeru typu projektu je realizováno pomocí seznamu existujících typu˚ projektu a neumožnuje ˇ tím pádem zadání jiné hodnoty. Po vytvoˇrení záznamu navíc již není možné pole upravit, lze pouze smazat celý záznam. V polích pro pomˇer jednotek pak lze zadat cˇ íslo vˇetší než jedna s nejvýše dvˇema desetinnými místy. V této fázi bylo tˇreba se vyrovnat se skuteˇcností, že pole pro zadání nejmenší a nejvˇetší možné hodnoty pˇrímo v ADempiere nefungují tak, jak by mˇela, a upravit tedy pˇrímo tabulku v databázi pˇridáním omezení (constraint ) CHECK(column_name>1). Jednotky práce by mˇely být nastaveny pˇred vytvoˇrením konkrétního projektu. V pˇrípadˇe, že však nastaveny nebudou, použije systém výchozí hodnoty, tj. 1 cˇ lovˇeko-hodina = 60 minut, 1 cˇ lovˇeko-den = 8 hodin, 1 cˇ lovˇeko-týden = 5 cˇ lovˇeko-dní a 1 cˇ lovˇeko-mˇesíc = 20 cˇ lovˇeko-dní. Tyto výchozí hodnoty jsou také pˇrednastaveny v jednotlivých polích pˇri vytváˇrení nového záznamu. 36
ˇ ˚ 6. M ODUL RÍZENÍ SOFTWAROVÝCH PROJEKT U
Testování Bˇehem testování bylo ovˇerˇ eno, že do polí pro pˇrepoˇcet jednotek nelze zadat hodnoty menší než 1. Kromˇe toho bylo také tˇreba provˇerˇ it, zda nelze vytvoˇrit dva záznamy pro jeden typ projektu, protože takový stav by mohl vést k nesprávným výpoˇctum. ˚ 6.1.3 Správa softwarového projektu Okno Správa softwarového projektu (Software Project Maintanance) je hlavní cˇ ástí celého modulu. Mˇelo by sloužit pro pˇrehled a nastavení všech duležitých ˚ informací o projektu. Analýza požadavku˚ Koncept dˇelení projektu na fáze a úkoly byl již pˇredstaven v kapitole 6.2 a tato cˇ ást systému je poTypu projektu další, která jej aplikuje v praxi. Nejduležitˇ ˚ ejším požadavkem zustává ˚ pˇrehlednost a logická návaznost jednotlivých cˇ ástí projektu (pˇredevším typu projektu a projektu, standardních fází a úkolu˚ na konkrétní fáze a úkoly), zárovenˇ však musí být možné zaznamenat o projektu veškerá potˇrebná data a souvislosti. Návrh Okno projektu bude velmi podobné puvodnímu ˚ oknu. Novému projektu bude pˇriˇrazen typ projektu, který po vytvoˇrení projektu nebude již možné zmˇenit. Nový projekt tak zdˇedí od typu projektu standardní fáze a úkoly, které bude možné, avšak ne povinné, použít. Opˇet bude tˇreba zadat název projektu, popis, poznámky a výstup projektu. Novˇe se zde objevují pole Projektový manažer (Project Manager), Datum zahájení (Start Date), Datum ukonˇcení (End Date) projektu, celkový Rozpoˇcet projektu (Project Budget ) a pole pro zobrazení souˇctu cˇ lovˇeko-mˇesícu˚ a cˇ lovˇeko-dní jednotlivých fází, které by nemˇelo být editovatelné - systém by mˇel ideálnˇe tyto hodnoty vypoˇcítat z exitujících fází a úkolu. ˚ V této první verzi modulu však zustaneme ˚ u editovatelné verze. Projektový manažer je vybírán z aktuálního seznamu zamˇestnancu˚ v systému, takže je zde rovnou na37
ˇ ˚ 6. M ODUL RÍZENÍ SOFTWAROVÝCH PROJEKT U
Obrázek 6.6: Návrh okna Projekt
stavena i jeho emailová adresa, na niž budou zasílána upozornˇení. Návrh okna Projekt (Project ) je zobrazen na obrázku 6.6. I zde bude mít okno Projekt nˇekolik záložek, tj. podoken. Kromˇe záložek Fáze (Phases) a Úkoly (Tasks) zde bude umístˇena také záložka Zdroje (Resources). V podoknˇe Fáze bude možné spravovat již konkrétní fáze daného projektu. Nová fáze muže ˚ vzniknout vybráním standardní fáze, cˇ ímž zdˇedí její atributy a také její úkoly, nebo vytvoˇrením zcela nové fáze projektu. Fáze musí mít zadané Datum zahájení a Datum ukonˇcení, pˇriˇcemž tato data nesmí pˇresáhnout data zahájení a ukonˇcení projektu. Aby bylo jednodušší sledovat rozpoˇcet projektu a jeho plnˇení, najdeme i zde pole Rozpoˇcet fáze (Phase Budget ), a pro sledování práce na projektu pole Poˇcet cˇ lovˇeko-hodin (Man-hours) a Poˇcet cˇ lovˇeko-dní (Man-days). Tato pole by mˇela být automaticky pˇrepoˇcítávána, takže by mˇelo postaˇcovat uvedení pouze jednoho z tˇechto dvou údaju. ˚ Ukonˇcení fáze je indikováno vybráním políˇcka Dokoncˇ eno (Completed ). Podokno Úkoly (Tasks) (viz obrázek 6.8) slouží ke správˇe úkolu˚ pˇriˇrazených k urˇcité fázi projektu. Každý úkol má nastavenou délku v cˇ lovˇeko-hodinách a cˇ lovˇeko-dnech, mˇel by být pˇriˇrazen alesponˇ 38
ˇ ˚ 6. M ODUL RÍZENÍ SOFTWAROVÝCH PROJEKT U
Obrázek 6.7: Návrh okna Projekt, záložka Fáze
Obrázek 6.8: Návrh okna Projekt, záložka Úkol
39
ˇ ˚ 6. M ODUL RÍZENÍ SOFTWAROVÝCH PROJEKT U
Obrázek 6.9: Návrh okna Projekt, záložka Zdroje jedné osobˇe ze seznamu zdroju˚ a jako takový muže ˚ být pˇriˇrazen nejvýše k jedné fázi projektu. Dokonˇcení úkolu je opˇet indikováno vybráním políˇcka Dokonˇceno (Completed ), což by mˇela udˇelat osoba, nebo jedna z osob, jíž nebo jimž byl úkol pˇriˇrazen. Zárovenˇ by mˇel systém automaticky emailem upozornit projektového manažera na tuto událost. Pole Pˇredchozí úkol (Previous Task) slouží pro urˇcení sekvence úkolu˚ a stejnˇe jako Datum dokonˇcení není povinné. Pˇri zadání hodnot do polí Poˇcet cˇ lovˇeko-hodin (nebo Poˇcet cˇ lovˇeko-dní ) a Náklady na cˇ lovˇeko-hodinu (Man-Hour Costs) by se mˇel automaticky spoˇcítat údaj v poli Náklady na úkol (Task Costs). Dalším podokem okna Projekt je okno Zdroje (Resources, viz obrázek 6.9). Jedná se zde o lidské zdroje a smyslem okna je pˇriˇradit k projektu zamˇestnance, kteˇrí na nˇem pracují, nebo budou pracovat a urˇcit jejich role v projektu. Okno obsahuje pouze nˇekolik jednoduchých polí - Projekt (Project ), Zamˇestnanec (Employee), Úrovenˇ (Level ), Role (Role) a Nadˇrízený (Supervisor). Nejvýše postavený pracovník na projektu nebude mít nadˇrízeného a úrovenˇ bude rovna nule. Pomocí úrovní a nadˇrízených bude pozdˇeji možné sestavit OBS (Organizational Breakdown Structure) projektu. Pˇriˇrazením k projektu by každý zamˇestnanec mˇel získat pˇrístup k úkolum ˚ a rozvrhu projektu, který dosud mˇel pouze tvurce ˚ projektu a pˇriˇrazený projektový manažer (pokud se nejedná o tu samou osobu). Pro každého pˇriˇrazeného zamˇestnance by taktéž momentem pˇriˇrazení mˇel vzknout pˇrístup k oknu Výkaz (Timesheet ), kam bude zaznamenávána veškerá jeho/její práce na projektu s možností propojit záznamy s 40
ˇ ˚ 6. M ODUL RÍZENÍ SOFTWAROVÝCH PROJEKT U
konkrétním úkolem. Tato funkcionalita je však zatím jen návrhem do budoucna.
Implementace Nejprve bylo nutné opˇet vytvoˇrit pˇríslušné tabulky v databázi, poté je definovat v ADempiere a vytvoˇrit pro nˇe okno a záložky. Oproti puvodnímu ˚ plánu vytvoˇrit záložky ve tˇrech ruzných ˚ úrovních (úrovenˇ 0 - projekt, úrovenˇ 1 - fáze, úrovenˇ 2 - úkol ) jsem nakonec zvolila pouze dvouúrovnovou ˇ strukturu okna, kdy je nejvyšší záložkou SW Projekt a ostatní tˇri záložky leží na úrovni 1. Duvodem ˚ bylo lepší logické provázání záložek; místo toho, aby navazovaly každá na záložku o jednu úrovenˇ výše, se všechny vztahují k hlavní záložce SW Projekt. Pˇri pˇrístupu do záložek první úrovnˇe je automaticky oznacˇ en jeden z existujících projektu˚ na úvodní záložce. Zobrazují se tak pouze fáze, úkoly a zdroje, které patˇrí ke zvolenému projektu (v pˇrípadˇe, že nˇejaké existují). Pro jednodušší práci se systémem bylo implementováno nˇekolik prvotních pomocných prvku. ˚ Prvním pˇríkladem je výbˇer projektového manažera v záložce SW Projekt, kde se kliknutím na vyhledávací tlaˇcítko dostaneme do vyhledávacího okna, z nˇehož mužeme ˚ již pohodlnˇe vybrat uživatele - projektového manažera. Stejný princip výbˇeru je aplikován také na nepovinné pole pˇriˇrazení uživatele k úkolu nebo na výbˇer uživatelu˚ v záložce Zdroje SW Projektu. Dalšími podobnými prvky, které však již umí ADempiere vytvoˇrit zcela sám, jsou kalendáˇr u zobrazení data a kalkulaˇcka u zobrazení cˇ íselných hodnot. Podstatnou cˇ ástí implementaˇcní fáze bylo opˇetovné vyhodnocení všech polí a rozhodnutí, zda mají být urˇcena pouze pro cˇ tení, zda má být povolena jejich editace po uložení záznamu, jaká má být jejich výchozí hodnota atd. U nˇekterých polí bylo tˇreba puvodní ˚ rozhodnutí zmˇenit, pˇrípadnˇe opravit ta pole, kde došlo k chybˇe pˇri vytváˇrení tabulek v databázi. Pˇríkladem muže ˚ být pole Datum dokonˇcení (End Date) v záložce Úkol SW Projektu, kde puvodnˇ ˚ e bylo omylem nastaveno v databázi omezení DEFAULT (now) NOT NULL. Protože by ale v rámci logiky modulu mˇelo být možné vytvoˇrit i úkoly bez pˇresného cˇ asového omezení, bylo toto omezení chybné. 41
ˇ ˚ 6. M ODUL RÍZENÍ SOFTWAROVÝCH PROJEKT U
Testování Bˇehem testování tohoto okna byly zadávány hodnoty menší než nula do cˇ íselných polí a data ukonˇcení dˇrívˇejší než data zahájení. U nˇekolika položek bylo odhaleno chybˇející omezení, což bylo následnˇe napraveno. Dále byly pro úˇcely testování vytvoˇreny projekty na základˇe dˇríve vytvoˇrených typu˚ projektu, fáze i úkoly, z nichž nˇekteré implementovaly standardní fáze a úkoly a jiné nikoliv. Poslední cˇ ástí testování tohoto okna bylo pˇriˇrazení nˇekolika zdroju˚ k projektu, kde byl zjištˇen nedostatek v možnosti pˇriˇradit stejnou osobu k jednomu projektu vícekrát. Tento nedostatek nebyl zatím ošetˇren.
6.1.4 Seznam úkolu˚ Okno Seznam úkolu˚ (To-Do-List ) je v podstatˇe pouze zjednodušenou verzí okna Úkoly SW Projektu urˇcenou v aktuální verzi jen pro cˇ tení, nebudu tedy dˇelit tuto sekci na další cˇ ásti jako u ostatních oken. Zobrazují se zde pole Softwarový projekt, Fáze SW Projektu, Název, Popis, Pˇriˇrazeno uživateli a Datum dokonˇcení. Seznam úkolu˚ je opravdu pouze seznamem, pˇrehledem všech úkolu, ˚ které jsou oznacˇ eny v systému jako aktivní (povinná hodnota isActive) a nejsou oznaˇceny pˇríznakem Dokonˇceno (Completed ). Úkoly se v oknˇe s jedinou, hlavní, záložkou rˇ adí podle pˇríslušnosti k projektu. Aˇckoliv okno je skuteˇcnˇe jednoduché a staví pouze na již existující tabulce c_sw_project_task, je to podle mého názoru cenná komponenta modulu, a to díky své pˇrehlednosti. Pro další rozšíˇrení modulu pomocí stavu˚ úkolu˚ (napˇr. nepˇriˇrazený, otevˇrený, rozpracovaný, cˇ ekající atd.) je toto okno vhodným kandidátem pro takové zobrazení. Kromˇe toho jej lze pomocí jediného tlaˇcítka zmˇenit opˇet na zapisovatelné.
6.1.5 Výkaz Protože v ADempiere zatím možnost nˇejakým zpusobem ˚ zaznamenávat odvedenou práci schází a záznamy tohoto typu jsou pˇri rˇ ešení sotwarových projektu˚ klíˇcové, zaˇradila jsem do nového modulu také jednoduché okno s názvem Výkaz (Timesheet ). 42
ˇ ˚ 6. M ODUL RÍZENÍ SOFTWAROVÝCH PROJEKT U
Obrázek 6.10: Návrh okna Výkaz
Analýza požadavku˚ Vytváˇret výkazy by mˇel mít možnost každý kromˇe správce pouze sám pro sebe. Zárovenˇ by nemˇel nikdo, opˇet kromˇe správce, mít možnost vidˇet záznamy ostatních uživatelu. ˚ Pˇredstavíme-li si, že každý uživatel zadá nˇekolikrát dennˇe do této tabulky záznam, bude v ní jistˇe brzy velmi mnoho záznamu. ˚ Bylo by tedy vhodné ošetˇrit pozdˇeji data tak, aby se staré záznamy napˇr. archivovaly a nezpusobo˚ valy zbyteˇcnou zátˇež a tím také zpomalení systému.
Návrh Záznam výkazu je možné pˇriˇradit ke konkrétnímu úkolu pomocí výbˇeru projektu v poli Úkol (Task ). Pole Uživatel (User) by mˇelo být nastaveno na výchozí hodnotu právˇe pˇrihlášeného uživatele a nemˇelo by být možné jej mˇenit. Stejnˇe tak pole datum by mˇelo být pˇrednastaveno na aktuální datum, ale s možností jej mˇenit. V tomto oknˇe viz obrázek A.10 dále najdeme pole Poˇcet hodin (Hours Spent ), Popis práce (Work Description) a Poznámky (Comment ). 43
ˇ ˚ 6. M ODUL RÍZENÍ SOFTWAROVÝCH PROJEKT U
Implementace Po vytvoˇrení odpovídající tabulky v databázi bylo dle návrhu vytvoˇreno samotné okno. Jméno uživatele je pˇredvyplnˇeno pomocí tzv. kontextové promˇenné (context variable) @\#AD\_User\_ID@. Kontextové promˇenné mají v ADempiere formu globální promˇenné pˇrístupné pˇrímo z aplikace. Dˇelí se na dva typy podle toho, jak je nastavena jejich hodnota. Stálé systémové promˇenné jsou nastaveny pˇri pˇrihlášení uživatele do systému a jsou oznaˇceny kˇrížkem pˇred názvem promˇenné (#AD\_User\_ID je pˇríklad tohoto typu promˇenné). Kontextové promˇenné vztahující se k aktuálnímu oknu jsou druhým typem dostupných promˇenných. Jednotlivé záznamy v oknˇe Výkaz jsou rˇ azeny dle zadaného data provedené práce. Do pole Poˇcet hodin (Hours Spent ) nelze zadat hodnotu menší než nula, avšak pole muže ˚ obsahovat až dvˇe desetinná místa. Testování Testování probˇehlo v poˇrádku pomocí vytvoˇrení nˇekolika záznamu, ˚ zadání záporné hodnoty do pole Poˇcet hodin, zmˇeny data záznamu po jeho uložení a obnovení dat z databáze pro ovˇerˇ ení správného rˇ azení položek.
44
7 Závˇer Práce seznamuje cˇ tenáˇre s ERP systémy a s open-source systémem ADempiere, jemuž je vˇenována nejvˇetší pozornost. Stˇežejní cˇ ást práce tvoˇrí rozbor existující funkcionality systému a dále analýza požadavku, ˚ návrh a implementace nového modulu urˇceného pro rˇ ízení softwarových projektu. ˚ První cˇ ást práce obsahuje úvod do problematiky ERP systému˚ s durazem ˚ na možnosti, úskalí a dusledky ˚ jejich nasazení a využití v praxi. Na tomto základu staví kapitola s poˇradovým cˇ íslem tˇri, jež analyzuje potˇreby a procesy v IT firmˇe obecnˇe, vˇcetnˇe cˇ ásti vˇenované zaˇcínajícím IT firmám. Poznatky zjištˇené v kapitole tˇretí jsou dále využity v kapitole cˇ tvrté, která kromˇe analýzy instalovaného systému poskytuje také odpovˇed’ na otázku kladenou v zadání práce, zda je ADempiere vhodný pro poskytování systému jako služby. Na základˇe seznámení se se systémem je také v závˇeru této kapitoly vybrána oblast projektového rˇ ízení pro závˇereˇcnou implementaˇcní cˇ ást práce. Rozborem požadavku˚ na softwarové nástroje pro projektové rˇ ízení se zabývá samostatná kapitola. Výsledky práce v podobˇe implementace modulu pro rˇ ízení softwarových projektu˚ jsou obsahem kapitoly šesté. Byl implementován funkˇcní modul s pˇeti okny, jež jsou dále strukturována pomocí záložek. Struktura modulu vychází z existujících nástroju˚ pro projektové rˇ ízení, cˇ ímž je cˇ ásteˇcnˇe ovˇerˇ ena jeho použitelnost v praxi. Oblast projektového rˇ ízení je však pomˇernˇe rozsáhlá a vytvoˇrený modul pokrývá pouze její základy, takže jej lze dále rozšiˇrovat o kontroly polí a pˇrednastavení jednotlivých hodnot dle jiných dat v databázi, zlepšit logiku a návaznost jednotlivých oken, pˇridat kontrolu pˇrístupu dle pˇriˇrazení na projektu atd. Systém ADempiere je velmi zajímavý z pohledu vývoje i využití, bˇehem práce jsem mˇela možnost se s ním pomˇernˇe podrobnˇe seznámit a vˇerˇ ím, že najde své pˇríznivce nejen v akademických kruzích, ale i v praxi. Jako každý systém, ani ADempiere není dokonalý, ale je nutné rˇ íci, že skýtá mnoho výhod, které zcela vyvažují jeho nevýhody, a mˇel by být v oblasti ERP systému˚ brán jako plnohodnotná konkurence komerˇcním aplikacím. 45
Literatura [1] Krnáˇc, Igor. Adaptácia ERP systému ADempiere. Brno: Bakaláˇrská práce FI MU, 2011. [2] Alfa samec ERP [online]. Vyšlo jako cˇ lánek pro Hospodáˇrské noviny. Praha: Economia, 2011. Dostupné na http://www.erpy.cz/2010/05/alfa-samec-erp/#more-1575. [3] Kimberling, Eric. Preview of Panorama’s 2011 ERP Report: ERP Implementation Costs Continue to Decline [online]. 2011 [cit. 29. 3. 2012]. Dostupné na http://panoramaconsulting.com/preview-of-panoramas-2011-erp-report-erpimplementation-costs-continue-to-decline/. [4] Velecký, Petr; Zajíc, David. TCO: Strašák CIO a IT manažeru, ˚ kterému neuteˇcete. ICT Revue - pˇríloha Hospodáˇrských novin, prosinec 2011 [str. 18 - 21]. Praha: Economia, 2011. [5] Zwilling, Marty. Eight Business Processes Every Startup Must Have [online]. 2010 [cit. 1. 4. 2012]. Hot Sauce!. Dostupné na http://www.caycon.com/blog/2010/08/eightbusiness-processes-every-startup-must-have/. [6] ADempiere Implementation Details [online]. ADempiere ERP Wiki. 2006, naposledy editováno 26. prosince 2010. Dostupné na http://www.adempiere.com/ADempiere_Implementation_Details. [7] Initial Client Setup Process [online]. ADempiere ERP Wiki. 2006, naposledy editováno 28. prosince 2010. Dostupné na http://www.adempiere.com/Initial_Client_Setup_Process. [8] ManPageW Role [online]. ADempiere ERP Wiki. 2006, naposledy editováno 14. prosince 2006. Dostupné na http://www.adempiere.com/ManPageW_Role. [9] Project Management Tool Analysis and Recommendations White Paper [online]. USA, Ohio: NASA, 2004. Dostupné 46
ˇ 7. Z ÁV ER
na http://www.techrepublic.com/whitepapers/projectmanagement-tool-analysis-and-recommendations-whitepaper/158437. [10] Establish Opening Balances [online]. ADempiere ERP Wiki. 2012, naposledy editováno 22. dubna 2012. Dostupné na http://www.adempiere.com/Establish_Opening_Balances.
47
A Snímky obrazovek V této kapitole jsou umístˇeny snímky nˇekterých obrazovek systému pro lepší ilustraci.
Obrázek A.1: Nastavení nového klienta
Obrázek A.2: Vzhled webového rozhraní
48
A. S NÍMKY OBRAZOVEK
Obrázek A.3: Nový modul v prostˇredí java klientské aplikace
Obrázek A.4: Vyhledání uživatele v systému
49
A. S NÍMKY OBRAZOVEK
Obrázek A.5: Okno Work Units Setup
Obrázek A.6: Okno Timesheet
50
A. S NÍMKY OBRAZOVEK
Obrázek A.7: Hlavní záložka okna Software Project Maintenance
Obrázek A.8: Záložka SW Project Phase okna Software Project Maintenance 51
A. S NÍMKY OBRAZOVEK
Obrázek A.9: Záložka SW Project Task okna Software Project Maintenance
Obrázek A.10: Záložka SW Project Resources okna Software Project Maintenance
52
B Databázové tabulky Obrázek lze také nalézt v pˇrílohách v elektronické podobˇe.
Obrázek B.1: ERD databázových tabulek 53
C Elektronické pˇrílohy Souˇcástí práce jsou také elekrtonické pˇrílohy s následující strukturou nahrané do Informaˇcního systému MU: •
diplomova_prace.pdf – Elektronická verze diplomové práce ve formátu pdf
•
diplomova_prace.tex – Zdrojový kód diplomové práce
•
database_scripts – Databázové skripty –
•
adempiere_db_scripts.psql
images – Obrázky v plné velikosti –
sw_project_tables.png
54
