Aplikace pro podporu řízení projektů Oracle EBS

České vysoké učení technické v Praze Fakulta elektrotechnická

Bakalářská práce

Aplikace pro podporu řízení projektů Oracle EBS Pavel Raboch

Vedoucí práce: Ing. Michal Voráček

Studijní program: Elektrotechnika a informatika Obor: Výpočetní technika červen 2008

4

Prohlášení Prohlašuji, že jsem svou bakalářskou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 8.1.2008

.....................................................................

5

6

Poděkování Rád bych zde poděkoval vedoucímu práce Ing. Michalu Voráčkovy za věcné připomínky a především za ochotu a trpělivost. Dále kolegům ze zaměstnání za odbornou konsultaci a poskytnutí materiálů. V neposlední řadě svým přátelům a rodině za podporu.

7

8

Abstrakt Cílem této práce je prozkoumat teorii projektového řízení, metodiku AIM a posléze navrhnout a implementovat aplikaci pro podporu řízení implementace informačního systému Oracle EBS. Aplikace je vyvinuta pomocí technologie ADF (Java EE 5.0), obsahuje databázovou, aplikační a klientskou vrstvu.

Abstract The aim of this work is to explore the theory of project management methodology AIM and then design and implement application to support the implementation of management information system Oracle EBS. The application is developed using ADF (Java EE 5.0), contains a database, application and client layer.

9

10

Obsah Seznam obrázků ...................................................................................................................13 Seznam tabulek ....................................................................................................................15 Úvod ....................................................................................................................................17 1 Úvod do problematiky řízení projektů ...........................................................................18 1.1 Projektové řízení ....................................................................................................18 1.1.1 Projekty.............................................................................................................19 1.2 Plánování a organizování projektu ..........................................................................20 1.2.1 Plánování projektu ............................................................................................20 1.2.2 Organizace projektu ..........................................................................................21 2 Oracle E-business Suite ................................................................................................23 2.1 Oracle EBS řešení ..................................................................................................23 2.1.1 Řízení financí ....................................................................................................24 2.1.2 Řízení lidských zdrojů .......................................................................................25 2.1.3 Řízení vztahů se zákazníky (CRM)....................................................................25 2.1.4 Řízení dodavatelských řetězců (SCM) ...............................................................25 2.1.5 Řízení projektů ..................................................................................................26 2.2 Technické požadavky pro Oracle EBS ....................................................................26 3 Analýza činností na projektech implementace EBS .......................................................31 3.1 Organizační struktura firmy, pracovní týmy v rámci projektu .................................31 3.2 Fáze projektu, posloupnost činností ........................................................................33 3.2.1 Definice podnikových požadavků ......................................................................36 3.2.2 Analýza operací.................................................................................................37 3.2.3 Návrh řešení ......................................................................................................37 3.2.4 Tvorba prototypu...............................................................................................38 3.2.5 Přechod .............................................................................................................39 3.2.6 Podpora náběhu .................................................................................................40 4 Návrh aplikace pro podporu řízení projektů Oracle EBS ...............................................41 4.1 Úvodní studie .........................................................................................................41 4.1.1 Deklarace záměru ..............................................................................................41 4.1.2 Odborný článek .................................................................................................41 4.1.3 Model jednání ...................................................................................................42 4.1.4 Požadavky na HW a SW ...................................................................................47 4.1.5 Datový model ....................................................................................................47 4.1.6 Seznamy typů uživatelů, dokumentů a úkolů .....................................................49 4.2 Scénáře použití a diagram aktivit ............................................................................51 4.2.1 Zadání a akceptace úkolu ..................................................................................52 4.2.2 Zadání a schválení požadavku ...........................................................................54 4.2.3 Manipulace s dokumentem ................................................................................56 4.2.4 Zadání a smazání vzkazu na nástěnce ................................................................56

11

4.3 Technologická specifikace......................................................................................57 4.3.1 Struktura View modulu .....................................................................................60 5 Testování aplikace ........................................................................................................61 5.1 Testovací scénáře a výsledky testů..........................................................................61 6 Diskuse nad výsledky ...................................................................................................63 7 Závěry a doporučení .....................................................................................................63 8 Literatura a reference ....................................................................................................65 A. Seznam zkratek .............................................................................................................67 B. Obsah přiloženého CD ..................................................................................................69

12

Seznam obrázků Obr. 1.1.: Parametry projektového řízení ..............................................................................19 Obr. 2.1.: Struktura Oracle Applications ...............................................................................24 Obr. 2.3.: Architektura Oracle aplikací .................................................................................27 Obr. 3.1.: Metodika AIM ......................................................................................................31 Obr. 4.1.: Diagram případů použití sysadmin ........................................................................43 Obr. 4.2.: Diagram případů použití manager .........................................................................44 Obr. 4.3.: Diagram případů použití consultant.......................................................................45 Obr. 4.4.: Diagram případů použití user ................................................................................46 Obr. 4.5.: Datový model systému ..........................................................................................48 Obr. 4.6.: Typy dokumentů ...................................................................................................51 Obr. 4.7.: Diagram aktivit pro úkol .......................................................................................53 Obr. 4.8.: Diagram aktivit - požadavek .................................................................................55 Obr. 4.9.: Diagram aktivit - dokumenty ................................................................................56 Obr. 4.10.: Diagram aktivit - nástěnka ..................................................................................57 Obr. 4.17.: Java koncept M-V-C ...........................................................................................58 Obr. 4.18.: Diagram nasazení................................................................................................59 Obr. 4.19 : Mapa JSP stránek................................................................................................60

13

14

Seznam tabulek Tab. 2.1.: Požadavky operačního systému.............................................................................27 Tab. 5.1: Výsledky testů 1 ....................................................................................................61 Tab. 5.2: Výsledky testů 2 ....................................................................................................61

15

16

Úvod Téma Aplikace pro podporu řízení projektů Oracle EBS, respektive podpora řízení projektů obecně, je v oblasti IT a mnoha dalších hojně diskutované. O problematice projektového řízení bylo již napsáno nepřeberně příruček a studií. Existuje množství metodik, které nám říkají, jak projekt spravovat a přesto si troufám tvrdit, že není mnoho dalších oblastí lidské činnosti, kde se teorie tolik míjí s praxí. Jelikož pracuji na projektech implementace Oracle EBS jako technický konzultant, tak veškeré problémy týkající se organizace a řízení projektů vnímám stejně jako ostatní členové projektového týmu. Jako jeden z největších problémů se mi vždy jevila komunikace v rámci projektu a ne vždy zřejmá zodpovědnost jednotlivých účastníku za dílčí činnosti na něm. Když jsem si měl zvolit téma bakalářské práce, zvolil jsem proto takové, kde mohu alespoň částečně pomoci projektovému řízení na projektech, kterých se bude naše společnost účastnit. Úkolem mé práce je proto prozkoumat problematiku řízení projektů, popsat informační systém Oracle EBS a metodiky jeho implementace, posléze navrhnout a realizovat aplikaci pro podporu této implementace dle příslušných metodik. Samotný dokument se skládá ze čtyř obsahově odlišných částí. Obsahem první kapitoly je úvod do problematiky řízení projektů. Případný, věci neznalý čtenář je tu seznámen se základními termíny v této oblasti, jako je projekt, jeho plánování, organizování a řízení. Druhá část je obsahově menším exkurzem do aplikačního řešení Oracle E-business suite. Je zde popsán smysl a fungování aplikace, její modulárnost doplněná charakteristikou nejpoužívanějších modulů a její technické nároky. Třetí kapitola se věnuje analýze činností na projektech implementace Oracle EBS. Porovnává skutečný stav činností s doporučenou metodikou pro implementace Oracle produktů. V poslední části práce je zpracován návrh samotné aplikace pro podporu řízení projektů Oracle EBS, dle kterého je aplikace vyvíjena.Nezbytnou součástí této sekce je i testování aplikace. Mým hlavním cílem je proto aplikovat v průběhu studia nabyté znalosti a dovednosti na návrh aplikace a její tvorbu, doplnit ji potřebným teoretickým základem, aby výsledek odpovídal požadavkům na bakalářskou práci. Postřehy a glosy v textu jsou vyznačeny kurzívou (převážně v třetí kapitole – Analýza činností na projektech implementace Oracle EBS). Přeji čtenáři, aby ho moje práce alespoň trochu zaujala a nezasvěcené poučila v oboru, který čím dál více zasahuje do profesního života každého člověka a třeba u něj dokonce podnítila hlubší zájem o tuto problematiku.

17

1 Úvod do problematiky řízení projektů Informační systémy a informační technologie vůbec se staly v posledních dekádách významným nástrojem pro zvýšení efektivity a konkurenceschopnosti podniků. Dobře integrovaný podnikový informační systém má za úkol podporovat a optimalizovat vybrané podnikové procesy, zvyšovat efektivitu práce, pomáhat managementu při rozhodování pomocí on-line dotazů do systému, kde se data uchovávají a systém je umožňuje analyticky zpracovávat. Podnikové informační systémy umožňují podnikům elektronicky komunikovat s okolím (dodavatelé, zákazníci, úřady), řídit výrobu, sklady, nákup i prodej. Ve světě globálního obchodu, trhů a společností získala na důležitosti informace, jakožto cenný podnikový zdroj. Rostoucí význam informace jde ruku v ruce s potřebou podniků reagovat na rychle měnící se podmínky na trhu. Např. P.F. Drucker v této souvislostí tvrdí: „Znalosti a informace jsou dnes jediným smysluplným zdrojem. Tradiční výrobní faktory – půda, práce, kapitál nezmizely, ale staly se druhořadými. Hlavním producentem bohatství jsou informace a znalosti.“1 Podnikový informační systém Zjednodušeně řečeno, je systém, jak už název napovídá, který umožňuje informace získávat, uchovávat, analyzovat a interpretovat. V dnešní době působí na trhu celá řada společností, které nabízejí různé typy informačních systémů. Od malých podnikových aplikací typu Pohoda, přes robustní manažerské informační systémy (např. SAP) až po řešení na míru. Teorie pro řízení projektů, která nám říká jak projekt spravovat, jakou posloupnost činností zvolit, jak plánovat, jak projekt fázovat atd., se vyskytuje nejčastěji ve formě metodik. Pro implementace Oracle applications EBS, což je produkt, pro který aplikaci stavím, se vyžívá metodika AIM (Application Implementation Methodology) vytvořená a doporučená přímo vývojářem EBS aplikací, tedy společností Oracle. Na druhé straně ovšem na úspěšnost projektu působí celá řada negativních vlivů, které mohou projekt prodloužit, zvýšit jeho náklady anebo způsobit ve výsledku odlišnou funkcionalitu implementovaného IS než byla požadována zadavatelem. statistika projektů IS – ze 100procent projektů je 25% projektů zrušeno díky nerealizovatelnosti, 25% projektů je provedena v pořádku a 50% projektů je realizováno o víc než 6 měsíců déle, cena je o 60-190 procent vyšší a funkcionalita je horší o 70 procent oproti požadavkům daných smlouvou.2

1.1 Projektové řízení Projektové řízení si lze představit jako soubor technik a instrumentů sloužící projektovým manažerům k úspěšnému plnění cílů projektu. V tomto kontextu je zřejmě nejdůležitější si pro začátek definovat projekt. 1

. Kapitola 1.A. Význam IS/IT pro moderní hospodářský subjekt, Informační systémy a jejich řízení, Jiří VOŘÍŠEK. 2 Řízení projektů a podnikových procesů – studijní materiály, Vladimír ŠEBEK

18

Projekt v oblasti řízení projektů můžeme definovat jako časově omezené úsilí, jehož cílem je vytvoření unikátního produktu 3. Časově omezené úsilí znamená, že projekt má jednoznačně definovaný začátek a konec. Standardně konec projektu nastává tehdy, když jsou splněny a akceptovány definované cíle projektu. Projekt samozřejmě může být zakončen i nestandardně např. zrušením projektu. Cílem projektového řízení je sladit často protichůdná hlediska času, nákladů a kvality. Pro úspěch projektu je nezbytné soustředit se na všechna hlediska a držet je v mezích projektového plánu.

Obr. 1.1.: Parametry projektového řízení

V rámci projektového řízení je nutné rozhodnout, které činnosti lze zahrnout do projektového řízení a které nikoliv. Jednoduše řečeno se určuje, co budeme považovat za projekt a vztahovat na něj projektové řízení a co již projektem nebude a tím pádem se to bude řídit jinak, většinou méně formálně. Činnosti, na které se aplikuje projektové řízení jsou obvykle v podniku vymezovány několika parametry: časové vymezení (pokud by plánovaná délka činnosti překročila určitou hranici, stává se činnost projektem náklady (projektem se stává činnost jejíž náklady překročí předem stanovenou hranici). Rozsah (Projektem se může stát činnost, která se svou existencí týká např. přes 20% zaměstnanců nebo např. více jak dvou organizačních jednotek včetně.

1.1.1 Projekty Jak je již napsáno výše, projekt je časově omezené úsilí, jehož cílem je vytvoření unikátního produktu, služby nebo jen požadovaného výsledku. Projekty jsou nástrojem realizace změny od současného stavu k požadovanému. Projekty zahrnují aktivity vedoucí ke: • 3

Strukturálním změnám, změnám procesu

Kapitola 3. Projektové řízení Projektové řízení – Příručka manažera, , Daniel MANDULA.

19

•

zvýšení výkonnosti

•

zavedení nových procesů

•

vytvoření nových produktů/služeb včetně relevantních procesů

Projekt musí definovat konkrétní cíle a tyto cíle musí být měřitelné (např. pomocí tvrdých nebo měkkých metrik) přesně v duchu známého rčení: „Co nelze změřit, nelze ani řídit.“, aby se vůbec daly změřit přínosy projektu. Projekty bývají limitovány z mnoha stran, logicky asi největší omezení skýtá projektový plán, v němž jsou zakotveny požadavky na projekt, jako je např. termín ukončení projektu, zdroje finanční, lidské, technické…, které podléhají projektovému řízení, jež se je bude snažit dodržet. Hlavní podmínky pro úspěch projektu se rodí pochopitelně na samém začátku. Jde především o realistická očekávání výsledků projektu, podporu v podniku od vrcholového managementu až po jednotlivé uživatele, jasnou specifikaci požadavků a účinné plánování. Součástí projektového řízení je i řízení úspěšnosti projektu. Je nutno brát na vědomí, že splnění definovaných a zdokumentovaných požadavků ještě neznamená splnění očekávání zákazníka a akceptace projektu není úplným ekvivalentem úspěchu projektu.

1.2 Plánování a organizování projektu 1.2.1 Plánování projektu Plánování je klíčovou aktivitou projektu. Je to stálá aktivita v průběhu projektu. Jde o strukturovaný proces, při kterém se hledají odpovědi na základní otázky: • •

kde jsme nyní (situační analýza) kam bychom měli jít (formulace cílů)

•

jak se tam dostaneme (definice postupu, určení zdrojů)

•

směřujeme tam? (při realizaci) – kontrola postupu

Schéma projektového plánu obsahuje jednotlivé prvky (k realizaci) sloužící k přechodu z momentálního stavu do stavu požadovaného a cestu, jak toho dosáhnout: vytvoření seznamu úkolů (WBS) – jde o vytvoření seznamu, kde bude znázorněn hierarchický rozpad projektu na etapy, kroky a úkoly odhad pracnosti – provádí se v rámci plánovacích seminářů (projektový manažer, klíčoví členové týmů…). Skládá se z přípravy, provedení odhadů, finální konsolidace a revize. sestavení plánu – vytvoření síťového diagramu, převedení pracnosti na dobu trvání, časový plán, alokace zdrojů, vyladění časového plánu.

20

Při plánování projektu nesmí být opomenuto ošetření rizik (princip řešení), protože rizika, v případě, že nastanou, znamenají omezení projektu. Rizikem rozumíme vyjádření pravděpodobnosti výskytu škody určitého rozsahu.4 Nesprávné plánování může v průběhu projektu ohrozit jeho samotnou existenci a proto je třeba tvorbě plánu věnovat mimořádnou důležitost.

1.2.2 Organizace projektu Stejně jako je existenčně časově omezený projekt, stejně tak dočasný je i řešitelský tým projektu. Tento tým je skladbou osob a organizací, kteří jsou do projektu aktivně zapojeni a tvoří „Organizaci projektu“. V rámci organizace projektu existují určité role, které sebou nesou jisté pravomoci a zodpovědnosti a vyskytují se pravidelně v rámci každého projektu: řídící výbor projektu - je nejvyšší orgán projektu, který rozhoduje o záležitostech týkajících se projektu s výjimkou pravomocí, jež náleží v souladu se stanovami a organizačním řádem statutárním orgánům podniku. Rozhoduje zejména o (a schvaluje jejich případné změny) obsahu projektu, harmonogramu, rozpočtu, řeší spory vzniklé v průběhu projektových prací. sponzor (gestor) projektu - je to většinou předseda řídícího výboru, osoba z nejvyššího vedení podniku, celkově zodpovědná za projekt. • zadává základní cíle a termíny projektu •

stanovuje přínosy realizace projektu, provádí jejich kontrolu

•

uvolňuje finanční prostředky

samostatně řeší problémy vzniklé v průběhu projektu v období mezi zasedáními řídícího výboru projektu projektový manažer - zodpovědný za řízení projektových aktivit zajišťuje dodání požadovaných výstupů projektu se získanými zdroji v rámci dohodnutého času, nákladů a kvality (specifikuje výstupy, dodávky, omezení a rizika projektu, koordinuje návrh řešení a dodávku jeho komponent) •

•

je klíčovým článkem pro komunikaci se všemi rolemi na projektu s vrcholovým managementem, liniovými vedoucími, externími dodavateli řídí projektové zdroje

•

předvídá a odstraňuje problémy

•

řeší neodkladně konflikty a výjimky, vztahující se k projektu (činí preventivní opatření k zamezení problémů, eskaluje problémy k řešení zákazník, uživatel – osoba nebo organizace, která má přímý užitek z výstupů projektu člen týmu – osoba, která provádí dílčí projektové činnosti pod vedením (přímým či nepřímým) projektového manažera •

4

Kapitola 7. Plánování projektu, Projektové řízení – Příručka manažera, Daniel MANDULA.

21

Výše uvedené role jsou zásadní pro každý projekt. U rozsahově velkých projektů se mohou vyskytovat další role nezbytné pro dobrou organizaci projektu.

22

2 Oracle E-business Suite Společnost Oracle, kterou před zhruba 30 lety založil Lawrence J. Ellison společně s Bobem Minerem a Edem Oatesem jako dodavatele řešení v oblasti relačních databází, je dnes největší světový dodavatel podnikových informačních systémů. Mottem společnosti jsou informace správa, využití, sdílení a ochrana. Česká pobočka společnosti Oracle byla založena v roce 1994. Oracle jako jediná společnost nabízí kompletní řešení podnikové informační infrastruktury – databáze, middleware, business intelligence, podnikové aplikace a nástroje pro podnikovou spolupráci – umožňuje společnostem dosahovat lepších výsledků na základě kvalitních informací. Oracle je dnes světovou jedničkou na trhu ERP, CRM, HRM a SCM systémů a bankovních aplikací. Společnost dnes kromě svých původních řešení, nabízí také aplikační řešení vyvinuté společnostmi, se kterými se strategicky spojila např. Siebel, JD Edwards nebo PeopleSoft.

2.1 Oracle EBS řešení Oracle E-Business Suite je plně integrovaný podnikový informační systém. Jeho výhodou je modularita a vzájemná provázanost nejen v rámci aplikací, ale i vůči okolnímu světu. Aplikace Oracle jsou snadno rozšiřitelné (škálovatelné) tzn. rostou společně s požadavky společností na funkcionalitu, výkon a bezpečnost. Aplikace Oracle integrují podpůrné funkce společnosti (např. Finance, Lidské zdroje atp.) s funkcemi, které podporují klíčové procesy (např. Řízení projektů, Plánování a řízení diskrétní nebo procesní výroby, Logistika, Údržba, Řízení kvality, atp.). Díky modularitě a otevřenosti řešení lze Oracle E-Busines Suite implementovat po jednotlivých modulech, celou sadu najednou či jako výběr specifických modulů pro určité odvětvové řešení. Společnost Oracle nabízí v rámci EBS následující aplikační okruhy: Řízení financí Řízení lidských zdrojů (HRM) Řízení vztahů se zákazníky (CRM) Řízení dodavatelských řetězců (SCM) Řízení projektů

23

Obr. 2.1.: Struktura Oracle Applications Zdroj: Oracle Financials – řízení financí [online], www.oracle.com

Velmi významnou funkcionalitou aplikací Oracle EBS je princip Multiorgu, který ve své podstatě znamená možnost provozu např. nadnárodní firmy s mnoha pobočkami na jedné instalaci aplikací.

2.1.1 Řízení financí Oracle Financials jsou základem podnikového informačního systému Oracle E-Business Suite poskytující nástroje běžné operativy správy ekonomických agend, manažerského řízení a rozhodování. Oracle Financials je řešením s lokalizovanými úpravami vyplývajících z legislativních požadavků a zvyklostí ČR.5 Parametrizovatelnost systému zajistí komplexní přizpůsobení podmínkám každé společnosti a to dokonce i v době plnohodnotného rutinního používání vlastního systému.6 Páteřními oblastmi této části EBS jsou moduly Hlavní Kniha, Majetek, Závazky a Pohledávky. Dalšími, v ČR často implementovanými moduly jsou Řízení hotovosti – česká banka a Pokladna. To jsou ovšem lokalizované moduly Cash management a Treasury.

5

Např. lokalizace DPH

6

Oracle Financials – řízení financí [online], ORACLE

24

2.1.2 Řízení lidských zdrojů Modul Personalistika7 pomáhá udržovat, automatizovat a optimalizovat veškeré vztahy podniku se zaměstnancem. Důsledkem optimalizace této oblasti skrze informační systém je zvýšení produktivity a redukce nákladů. Pro všechny činnosti spojené s personalistikou je k dispozici datový sklad, jehož výstupy jsou pak používány pro hloubkovou analýzu lidských zdrojů firmy. V aplikaci je možné realizovat všechny formy peněžního i nepeněžního odměňování v kterékoliv měně. Jsou zde obsaženy i funkce pro plánování mezd a platů v závislosti na produktivitě jednotlivců či skupin a jejich obsazování do tarifních tříd. Zaměstnance lze hodnotit v celé řadě aspektů, což přispívá ke komplexnímu řízení kvalifikace a znalostí pracovníků organizace. Modul v sobě samozřejmě obsahuje postupy a instrumenty pro tvorbu či modifikaci organizačních a pracovních struktur. Definují se zde jednotlivé organizační jednotky firmy a příslušné funkce a pozice k nim. To umožňuje sestavit hierarchii subordinace na jejímž základě je často postaveno schvalovací workflow pro různé události. Modul Personalistika je plně integrován s dalšími moduly systému EBS, jako jsou např. Oracle Learning Management, Oracle iRecruitment, Oracle Time and Labour, Oracle Advanced Benefits, Oracle Sesf Service HR, Oracle Internet Expenses, Oracle HR Intelligence…

2.1.3 Řízení vztahů se zákazníky (CRM) Řešení Oracle Relationship Management je primárně určeno pro velké firmy, výrobce však uvádí, že vhodné i pro menší a střední podniky díky předdefinovaným procesům pro řízení CRM, efektivně řízené komunikaci se zákazníky, podpoře plánování a řízení obchodních aktivit a jednoduchém systému reportingu. Mezi produkty Oracle CRM patří: •

Řízení prodejních a servisních kanálů

•

Marketing

•

Správa objednávek

•

Servis – péče o zákazníky

2.1.4 Řízení dodavatelských řetězců (SCM) Pokud chce podnik lépe uspokojovat zákaznické potřeby a požadavky, je k tomu nezbytně nutné, aby měl pod kontrolou i řízení dodavatelských řetězců. Bez naprostého přehledu o dodavatelských plněních není možné efektivně řídit skladové hospodářství, plánovat expedice a transporty a hlavně kvalitně provádět péči o zákazníka. Dokonce se dá říci, že CRM systém nemůže stoprocentě fungovat u společností, které nemají kvalitně integrovaný SCM systém.

7

Oracle Human Resources

25

To platí hlavně pro společnosti, u kterých je uspokojení zákazníka z větší části závislé na dodávkách zboží a služeb třetí stranou. Mezi hlavní efekty integrace Oracle SCM řešení patří zlepšení podkladů pro řízení i ve strukturálně složitých organizacích, reingeneering plánovacích procesů, které vede k dlouhodobému trendu zvyšování efektivity celé společnosti, vylepšení zákaznického servisu, snižování nákladů zlepšením průchodnosti dodavatelského řetězce a zkrácením průběžné doby realizace. Hlavními produkty v oblasti Oracle SCM jsou: •

Sklady

• •

Výroba Údržba

•

Prodej

•

Nákup

2.1.5 Řízení projektů Oracle řešení pro řízení a správu projektů8 obsahuje několik produktů, které umožňují řízení projektů v mnoha různých aspektech. Jde především o plánování prací, přidělování úkolů zodpovědným osobám, řízení zdrojů a kontrola plnění plánu z hlediska čerpání jednotlivých zdrojů. Aplikace Oracle Projects jsou aplikovány na všechny související aplikace Oracle E-Business Suite, zejména na finanční a logistické moduly, správu lidských zdrojů apod. Oracle Projects obsahují obousměrné integrační rozhraní s plánovacím nástrojem Microsoft Project.9 Základem Oracle Projektového řízení je několik následujících produktů: • Project Costing • Project Billing •

Project Resource Management

•

Project Collaboration

•

Project Contracts

2.2 Technické požadavky pro Oracle EBS Jedná se o třívrstvý systém, pracující na různých platformách a otevřený pro podporu ostatních, konkurenčních produktů.

8 9

Oracle Project Management Oracle Projects – Projektové řízení [online], ORACLE

26

Obr. 2.3.: Architektura Oracle aplikací Zdroj: ORACLE Application: Oracle E-Business Suite

Komponenty pro aplikační vrstvu Oracle Applications • Oracle Internet Application Server, obsahuje Oracle http Server •

RDBMS

• •

Oracle Developer Discoverer

•

Jinitiator

Požadavky operačního systému Solaris (SPARC) Linux Windows

Ar ,ld ,make Ar ,gcc ,g++ ,ld ,ksh ,make MSC++ , MKS Toolkit , GNU make Ar ,cc ,ld , make Ar ,cc ,acc ,make Ar ,ld, linkx1C, make

HP-Tru64 HP-UX IBM AIX

Tab. 2.1.: Požadavky operačního systému

27

CPU požadavky CPU požadavky pro běh Oracle Applications záleží na: •

Počtu součastných uživatelů a jejich profilech

•

Počtu součastně běžících interních procesů aplikace a jejich typu

•

Počtu aktivit systému mimo Oracle Applications

•

Velikosti databáze

•

Celkové CPU nároky se vypočítají dle předchozích údajů a nedají se určit pomocí tabulkové metody.

28

Požadavky na paměť Pro výpočet požadavku na paměť na uzlu, kde je RDBMS nainstalována, zahrneme následující: •

Velikost databáze v paměti

• •

Velikost SGA10 Počet součastných uživatelů

• Ostatní software běžící nad databází Požadavky na diskový prostor Kompletní instalace bez uživatelských

10

dat

System Global Area

29

v databázi

vyžaduje

57GB

volného

30

3 Analýza činností na projektech implementace EBS Následující část této práce bude věnována analýze stavu činností, řízení zdrojů a komunikaci v rámci pracovních týmů na projektu. Analýza je strukturována v kontextu metodiky AIM, kterou se v průběhu fází projektu ve firmě řídíme a která je vytvořena společností Oracle právě pro podporu implementací aplikací EBS. Je tudíž logické, že ji využíváme, i když osobně sdílím názor, že všechny dnes používané úspěšné metodiky mají v podstatě totožnou kostru. Struktura programu který vyvíjím, bude postavena právě na vlastnostech této metodiky. Na následujícím obrázku jsou zobrazeny a fáze a procesy vývoje projektu v AIM.

Strukturovaný systém • Fáze pro řízení kvality • Procesy koordinující a zajišťující kontinuitu úloh Definice

P R O C E S Y

FÁZE

Analýza operací

Návrh řešení

Tvorba Přechod prototypu

Podpora náběhu

Business Process Architecture (BP) Business Requirements Definition (BR) Business Requirements Mapping (RD) Application and Technical Architecture (TA) Module Design and Build (MD) Data Conversion (CV) Documentation (DO) Business System Testing (TE) Performance Testing (PT) Adoption and Learning (AP) Production Migration (PM)

ÚLOHY

Obr. 3.1.: Metodika AIM Zdroj: Metodika implementace AIM, Michal ČADEK.

3.1 Organizační struktura firmy, pracovní týmy v rámci projektu Účastníci projektů iplementace IS působí v rámci projektu na následujících pozicích: 31

Za dodavatele: Prodejce: Obvyklá činnost prodejce, jako je vyhledávání kontaktů, cenové nabídky, jednání o projektu a smlouvě atd. Jeho úloha na projektu končí uzavřením smlouvy s klientem a další případné aktivity (jako jsou další jednání např. o rozšíření funkcionality stávajícího systému, přikoupení licencí a další implementace…) už nespadají do rámce původního projektu, ale vytvářejí projekt nový. Funkční konzultant: Mapování business procesů u klienta, zjišťování informací nutných k nastavení systému, analýza současného stavu, návrh řešení, nastavení aplikací, příprava datových migrací, školení uživatelů, podpora při náběhu,tvorba uživatelských příruček, tvorba dokumentace ve fázi analýzy – BR30, tvorba dokumentace vyplývající z nastavení systému BR100, funkční specifikace pro programové úpravy - MD50. Technický kunzultant/programátor: návrh systémů, řešení technologie pro projekty, návrh použitého software a hardware, programové úpravy, customizace, lokalizace, datové migrace, podpora při náběhu. Projektový mažer: je zodpovědný za projekt jako celek, zajišťuje dodání požadovaných výstupů projektu se získanými zdroji v rámci dohodnutého času, nákladů a kvality (specifikuje výstupy, dodávky, omezení a rizika projektu, koordinuje návrh řešení a dodávku jeho komponent), je klíčovým článkem pro komunikaci se všemi rolemi na projektu, s vrcholovým managementem, externími dodavateli, řídí projektové zdroje. Za každou smluvní stranu projektu bývá zpravidla ustanoven jeden projektový manažer. Vedoucí jednotlivých implementačních oblastí: Zpravidla bývají určeni vedoucí jednotlivých implementačních oblastí. Pokud se např. implementují finance, logistika a výroba, tak se určí tři funkční konzultanti zodpovědní za implementace příslušných modulů, kteří řídí práce v jednotlivých oblastech. Dále bývá určen vedoucí technických konzultantů a programátorů, který koordinuje technické práce na projektu. Za zákazníka: Projektový manažer: plní výše popsané úkoly a vede projektový tým za stranu objednatele. Organizační vedoucí: je vedoucí organizačního útvaru, který se podílí na projektu, podílí se na kapacitních odhadech práce pracovníků svého útvaru a schvaluje je, je podrobně informován o průběhu a stavu projektu (dostává zápisy z projektových týmů, měsíční zprávy o projektu zodpovídá za realizaci dohodnutých výstupů a činností svých podřízených pracovníků pracujících v projektovém týmu (nejsou-li uvolněni na 100% projekt), zpravidla bývá finančně nebo jinak motivován na projektových výstupech a jejich kvalitě. Klíčový uživatel: Každý budoucí uživatel implementovaného IS, jeho úloha spočívá ve spolupráci s projektovým týmem dodavatele, školením a testováním systému. Obvzláště na 32

řadové pracovníky klienta je v průběhu projektu vytvářen velký tlak, protože kromě svých obvyklých povinností musí pracovníci vykonávat navíc projektové úkoly. Nejvyšším orgánem projektu je Řídící výbor, který rozhoduje o záležitostech týkajících se projektu s výjimkou pravomocí, jež náleží v souladu se stanovami a organizačním řádem statutárním orgánům podniku. Komunikace v oblasti rozdělování úkolů a odevzdávání výstupů by ideálně měla vypadat jako na obrázku č. 3.2., nicméně právě v této oblasti jsou největší rezervy. Komunikuje se bez ohledu na strukturu, přičemž vyšší články v hierarchii často nejsou informovány o průběhu jednotlivých činností, termíny se neplní, nejsou jasné kompetence a zodpovědnosti účastníků projektu, plány se mění ze dne na den, neexistuje centrální sklad dokumentace atd… Někdo by mohl namítnout, že je to o lidech a měl by samozřejmě pravdu, pokud by ale existoval modul do kterého by měli přístup všechny projektové týmy a skrze který by se veškerá komunikace vedla, dala by se řada věcí značně zlepšit.

Řídící výbor Úkoly pro PM, výstupy pro ŘV

Projektový manažer

Úkoly pro PM, výstupy pro ŘV

Výstupy a požadavky od klienta nebo dodavatele se druhé straně zasílají prostřednictvím PM

Úkoly a výstupy v rámci projektu

Projektový manažer

Úkoly pro VIO, požadavky a výstupy pro PM

Úkoly pro VTT, požadavky a výstupy pro PM

Organizační vedoucí

Vedoucí implementační oblasti

Vedoucí technického týmu

Úkoly a výstupy v rámci projektu

Úkoly a výstupy v rámci projektu

Úkoly a výstupy v rámci projektu

Klíčový uživatel

Funkční konzultant

Technický konzultant/ Programátor

Obr. 3.2.: Projektová komunikace

3.2 Fáze projektu, posloupnost činností Každý projekt má své fáze, záleží na použité metodice. Podle metodiky AIM se projekt implementace Oracle EBS člení na následující fáze:

33

Definice (definice podnikových požadavků, základní návrh aplikační a technické architektury, vytvoření vzdělavácí strategie a plánu školení) Analýza operací (vytvoření modelu pro každý podnikový proces, namapování modelů na aplikace a identifikace mezer, vytvoření základních harwarových, softwarových a komunikačních doporučení, příprava základních dokumentů pro vývoj customizací, vytvoření modelu výkonostních testů, vytvoření strategie přechodu) Návrh řešení (vytvoření detailních popisů budoucích podnikových procesů, výběr nejlepšího řešení mezi alternativami, návrh technické architektury, návrh programů a prostředí pro výkonostní testy, začátek tvorby dokumentace) Tvorba prototypu (Naprogramování a otestování všech zákaznických rozšíření, dodávka pracujícího a otestovaného řešení podnikových potřeb, vývoj a testy konverzních programů, update dokumentace, provedení výkonostních testů) Přechod (školení koncových uživatelů, provedení akceptačních testů, nastavení produkčního prostředí, konverze dat, náběh do provozu) Podpora náběhu (stabilizace systému, začátek standardní podpory, vyhodnocení projektu, vyřazení původního systému nebo jeho záloha, plánování dalšího rozvoje) Fáze na sebe mohou navazovat nebo se prolínat, ale v rámci každého projektu je možno nalézt body, bez jejichž dokončení ostatní činnosti neobejdou, proto je dobré si úkoly v rámci jednotlivých fází projektu označovat vzájemnými závislostmi. Na základě předchozích zkušeností z implementací si v naší společností dělíme činnosti na projektu do na sebe navazujících segmentů. (viz obrázek č. 3.3.) stejně tak, jak běží v reálném životě. Každá tato činnost koresponduje s někteou z fází podle metodiky AIM a někdy i s vícero. Např. o customizacích aplikace můžeme uvažovat ve fázi Definice (pokud máme dostatečné zkušenosti) a také v návrhu řešení, ovšem je zřejmé, že ve fázi Návrhu řešení půjdeme oproti fázi Definice do detailu.

34

Fáze projektu z hlediska participace

Zadání výběrového Řízení na informační systém a jeho dodavatele

Tato činnost obsahuje nastavení kritérií a přiřazení bodování za kritéria. Následuje selekce firem až do nalezení vítěze.

Smlouva a její

podmínky

Časový plán projektu, vybrané moduly k implementaci, účastníci projektu, cena…

Tvorba projektového Plánu

Projektový manažer připraví vymezenými činnostmi.

analýza business procesů ve společnosti, Shromažďování požadavků

Interwiew, prostřednictvím uzavřených otázek.

Tvorba dokumentace BR30

Popsání požadavků na systém a jeho nastavení, zejména v případě programových úprav

Návrh řešení customizací, lokalizací

Technické řešení programových úprav.

proj.

kombinací

Plán

s

časově

otevřených

a

Programové úpravy Nastavení systému na čistém prostředí ve firmě + testování

Nastavení systému a tvorba dokumentace k nastavení BR100 Instalace nastaveného prostředí u klienta + testování

Po instalaci prostředí se provádějí testy nastavení podle testovacích scénářů

Migrace dat Školení uživatelů + přidělení uživatelských práv jednotlivým uživatelům

Zaškolení všech budoucích uživatelů systému a přidělení práv v rámci systému

Konec projektu, následný support je otázkou smlouvy.

Předání programového díla zákazníkovi

Obr. 3.3.: Fáze projektu z hlediska participace členů týmu

Co se týká teoretického rozvržení projektu a skutečné praxe, musím konstatovat, že činnosti na projektu jsou opravdu odvozeny od použité metodiky AIM, nicméně posloupnost činností není zdaleka dodržena. To je dáno právě problémy s komunikací a plánováním. 35

Často je zanedbána část svým významem zásadní – analýza operací. Opomenutí ve fázi analýzy znamená stoprocentní jistotu návratu k ní v pozdějších fázích, čím později se na chyby přijde, tím nákladnější jsou důsledky.

3.2.1 Definice podnikových požadavků V této fázi projektu dochází k definici podnikových požadavků, základnímu návrhu aplikační a technické architektury a plánu vzdělávání a školení. Podnikové požadavky – definuje Klient na základě zkušeností se stávajícím podnikovým informačním systémem a s firemními procesy, které se v podniku odehrávají. Zde většinou žádný problém nevzniká, zákazník korektně nadefinuje svoje požadavky na budoucí IS a předá je dodavateli řešení. Použitá dokumentace: •

BP070 – Vytvoření (grafického) modelu stávajících procesů. Tyto modely často dodává zákazník a slouží jako podklad při analýze podnikových procesů a pro dokumentaci BR030.

•

BP080 – Vytvoření (grafického) modelu budoucích procesů

Základní návrh aplikační a technické architektury – v případě Oracle EBS jde defacto o zvážení jaké moduly budou dostačující pro pokrytí požadavků zadavatele a jestli jde tyto požadavky promítnout do standardu aplikace nebo je nutná programová úprava. Použitá dokumentace: •

MD010 – Strategie aplikačních rozšíření. Obsahuje Modifikace (změny základního kódu Oracle aplikací), Rozšíření (nové formuláře, reporty, tabulky, rozhranní, tabulky ...obecně věci, které nemění originální kód aplikací), Konfigurovatelné rozšíření (Použití popisných polí, alertů a jiných konfigurovatelných nástrojů aplikace)

Plán vzdělávání a školení – stanovuje se plán školení a vzdělávání prostřednictvím osobní účasti konzultantů a e-learningových metod (testovací scénaře, uživatelské příručky atd…) Plán školení sestavuje Projektový manažer dodavatele ve spolupráci s funkčním týmem a Projektovým manažerem na straně zákazníka. Nová aplikace pro podporu řízení projektů Oracle EBS by měla změnit jak tvorbu plánu (plán se bude generovat na základě fází a termínovaných úkolů přímo v aplikaci), tak jeho distribuci. Plán bude sdílen v samotné aplikaci, kam budou mít přístup určení uživatelé pod příslušným uživatelským účtem.

36

3.2.2 Analýza operací Vytvoření modelu pro každý podnikový proces – pro vytvoření modelů podnikových procesů a namapování těchto modelů na aplikace se využívá dokumentace BR030 podle metodiky AIM, kterou vytváří funkční konzultant. Tato dokumentace obsahuje následující části: Modely podnikových procesů – vytváří funkční tým na základě procesní analýzy přímo u klienta. Model je vytvořen jako standardní diagram procesu s rolemi a nástroji v rámci procesu. Namapování modelů na aplikace (Hrubý návrh řešení) – zanalyzované modely procesů se mapují na standardní řešení v aplikacích EBS. Pokud není proces namapovatelný na aplikace, konzultuje se s klientem buď změna procesu, aby se přiblížil ke standardu anebo se zvolí řešení pomocí programové úpravy. Toto řešení musí být v dokumentaci rámcově popsáno. Detailní návrh řešení – jde o srovnání detailních činností ve stávajícím systému a popis řešení těchto činností v Oracle EBS. Použitá dokumentace: BR030 - Vývoj a detailní popis procesních schémat Hardwarová, softwarová a komunikační doporučení – vytváří většinou technický konzultant za strany dodavatele. Jedná se o technickou specifikaci HW (konfigurace databázového a aplikačního serveru, terminálů, firemní LAN atd…) a SW (operační systém, verze Oracle databáze, plugin internetového browseru atd…) nástrojů tak, aby byl zajištěn bezproblémový chod budoucího IS. Všechny tyto návrhy jsou součástí dokumentace TA030 – koncepce technické architektury. Příprava základních dokumentů pro vývoj customizací - jde především o vytvoření dokumentace, která bude sloužit jako výchozí podklad pro vytvoření funkčních a technických specifikací a také rámcové ocenění těchto rozšíření. Použitá dokumentace: •

CR060 – změnové požadavky (popis a seznam) na aplikaci nebo na procesy

•

CV020 – strategie konverze

•

RD050 - seznam požadavků zákazníka

•

MD020 - definice a ocenění aplikačních rozšíření

3.2.3 Návrh řešení Vytvoření detailních popisů budoucích podnikových procesů – Tvorbu návrhů budoucích podnikových procesů vytváří funkční tým na základě předchozí analýzy procesů. Po

37

konzultacích všech smluvních stran se vybere ze všech návrhů nejvhodnější alternativa, která se bude posléze implementovat. S tím souvisí návrh Aplikační architektury, která musí respektovat multiorganizační, územní a procesní požadavky klienta. Použitá dokumentace: •

TA040 - definice aplikační architektury

•

BR100 - popis nastavení systému (a jeho skutečné nastavení)

•

RD060 - řízení přístupu

•

CV040 - Mapování konverzních entit

Funkční a technické specifikace - vytvářejí funkční a techničtí konzultanti pro programátory a aplikační vývojáře. Většinou se pro tvorbu funkčních a technických specifikací používá jazyk UML skrze některé CASE nástroje (Oracle Designer, Enterprise achitect, ARIS), ve kterých se dá provádět procesní modelování, datové modelování (tj. ER-diagramy), dataflow diagramy a funkční diagramy. Dále se pro modelování používá produkt MS Visio. Není to sice CASE nástroj, nicméně je snadno použitelný a má intuitivní ovládání, což je dobré zejména pro zaměstnance zákazníka, kteří ho při spolupráci s funkčním týmem velice často využívají. U funkčních a technických specifikací v naší firmě naražíme na stále stejný problém. V důsledku nedostatečné analýzy nejsou kvalitně ohodnoceny nároky na tvorbu customizací nebo případné customizace vůbec nejsou naplánovány a řeší se až za běhu projektu. To vede při spěchu ke špatným specifikacím a v důsledku ke stížené práci pro vývojáře. Často se stává, že customizace musí být několikrát přepracována a dochází k dalším nežádoucím časovým prodlevám. Použitá dokumentace: • MD050 - Funkční specifikace •

MD070 - Technické specifikace

3.2.4 Tvorba prototypu Nastavení systému – Aplikace nastavuje Funkční tým podle dokumentace BR100. Před nastavováním aplikací by měly být nainstalovány veškeré lokalizace a customizace popsané v návrhu řešení. Pokud se nastavení systému z jakýchkoliv důvodů změní oproti dokumentaci, je třeba cílovou BR100 aktualizovat. Vývoj customizací dle technických specifikací - Provádí tým technických konzultantů a vývojářů podle technických specifikací MD070. K vývoji customizací se využívají standardní různé nástroje (Jdeveloper, Report Builder, Forms Builder…). 38

Otestování a akceptace procesů – Nastavené aplikace a zejména customizované části je třeba otestovat. Tyto práce obstarává Funkční tým. Testuje se funkčnost přesně podle dříve popsaných podnikových procesů. Zjištěné chyby se opravují buď přenastavením aplikace, aplikováním patchů atd… Otestované procesy je třeba za účasti zákazníka zakceptovat. Pro testování procesů se vytvářejí tzv. Testovací scénáře, což jsou detailní postupy pro práci z aplikací, kde jsou jednotlivé kroky očíslované, popsané, případně i obrazově zdokumentované a jsou zde vypsány i očekávané výsledky jednotlivých operací. V případě chyb, či jinných výsledků tester zapíše skutečný stav do opovídajícího pole i s ostatními náležitostmi (datum, jméno, typ…) Testování bývá jedna z nejpodceňovanějších částí projektu klientem. V kombinaci s nedostatečným školením vzniká potom ve fázi podpory při náběhu obrovský problém, kdy uživatelé, kteří neprovedli simulaci reálného provozu na testovacím prostředí, jsou v reálném provozu často dezorientovaní a co hůř, může se přijít na chybu (aplikační nebo nastavení), která se musí odstraňovat za ostrého provozu. Použitá dokumentace: • TE040 - Testovací scénáře •

TE130 - Záznam o akceptačních testech

3.2.5 Přechod Školení koncových uživatelů – Mělo by probíhat v termínu daným plánem definovaným na začátku projektu a podle strategie školení navržené pro daného zákazníka. Obecně se průběhu projektu a po něm odehrávají následující školení: Úvodní školení pro klíčové uživatele Školení administrace aplikací Školení koncových uživatelů dle definovaných uživatelských postupů Průběžné doškolování stávajících uživatelů Zaškolování a rekvalifikace v běžném provozu systému Školení probíhá uceleně v termínu zhruba měsíc před náběhem produkčního prostředí. Uživatelé si musí zažít nově nabyté zkušenosti a v průběhu posledního měsíce je procvičovat na testovacím prostředí. Výhodou uživatelského testování je i odhalení chyb či chybného nastavení, pokud bylo při předchozím testovaní a akceptaci opomenuto. V těchto případech musí pochopitelně dojít k opětovné aktualizaci příslušné dokumentace. Nastavení produkčního prostředí a implementace otestovaných customizací – Provádí funkční a technický tým. Pokud je dokumentace BR100 řádně vedena a aktualizována, tak je nastavení produkčního prostředí poměrně nesložitou náležitostí. Stejně tak implementace

39

customizací. Všechny tyto činnosti už by měly být v průběhu projektu několikrát odzkoušeny. Přesto je pravidlem, že se najdou chyby na prostředí už v ostrém provozu. To je dáno složitostí a mohutností systému jako je Oracle EBS, ale také prostým lidským selháním. Proto je většinou dodavatelem v rámci smlouvy garantována podpora po náběhu do produkce, kde se poslední chyby odladí za provozu. Migrace dat - Strategie konverze (rozsah konverze) Způsob konverze pro jednotlivé datové entity, množství dat Časová souslednost konverze z hlediska datového modelu

3.2.6 Podpora náběhu Podpora při náběhu bývá poslední částí projektu. Z hlediska funkčního týmu jde především o doškolování klíčových uživatelů při průběžném odstraňování jejich chyb a jejich podporu při nezvratných krocích v systému (účetní úzávěrka, uzavírání období, konsolidace…) Technický tým se zabývá sledováním výkonosti systému a udržbou systému v rozsahu nasmlouvané podpory, vyřazováním starého systému (pokud je to možné a systém se např. neponechává jako záloha), vyčištěním systému o nadbytečná data, která se přenesla do nového systému datovými migracemi a nejsou využitelná pro budoucí provoz (neaktualizované číselníky dodavatelů, odběratelů, skladových položek, ceníky…). V této fázi projektu se sestavuje strategie dalšího rozvoje v oblasti funkční i technické pokud má zákazník o další formy spolupráce zájem. Další rozvoj znamená další projekt ve smyslu struktury projektů u jednoho klienta.

40

4 Návrh aplikace pro podporu řízení projektů Oracle EBS V této části dokumentu bude popsán samotný návrh aplikace dle praktik softwarového inženýrství. Aplikace bude navržena pro již popsanou technologii Oracle EBS, jež vývoj by měla spravovat.

4.1 Úvodní studie 4.1.1 Deklarace záměru Aplikace slouží jako podpůrný informační systém při vývoji a zavádění mohutné technologie Oracle EBS, založený na metodice AIM. Jedná se o správu jednotlivých projektů, jejich fází, dokumentace, úkolů, zodpovědností a zdrojů. Systém by měl monitorovat průběh vývoje, ovládat logiku podávání úkolů, požadavků a zodpovědností, a celkově zprůhlednit dění v pracovních týmech, jako komunikační medium využívá počítačovou síť. Aplikace bude určena pro menší ale i středně velké firmy.

4.1.2 Odborný článek Aplikace je navržena tak, aby pokryla vývoj již popsaného systému Oracle EBS. Hiearchie struktury aplikace, je založena na výběru projektu, jež je dále rozdělen do projektových fází: Definice, Analýza operací, Návrh řešení, Tvorba prototypu, Přechod, Podpora náběhu a následně do jejich podfází: Definice – Podnikové požadavky, Základní návrh aplikační a technické architektury, Analýza operací – Vytvoření modelu pro podnikové procesy, HW a SW komunikační doporučení, Příprava dokumentů pro vývoj customizací, Návrh řešení – Detailní popisy jednotlivých podnikových procesů, Funkční a technické specifikace, Tvorba prototypu – Nastavení systému, Vývoj customizací, Otestování a akceptace, Přechod – 0, Podpora náběhu – 0. Součástí aplikace je propracovaná logika komunikace v týmu, zejména tvorba úkolů, požadavků a sdílené informační nástěnky. Úkoly vytváří privilegovaní zadavatelé, přičemž může vycházet s předešlého požadavku, nebo je zadán dle šablony vývoje, a nebo může jít o neiniciovaný, nově vytvořený úkol. Každý úkol obsahuje svého řešitele a zadavatele, specifikaci zadání, časový požadavek, typ úkolu, stav úkolu - Nový, Akceptovaný, Neakceptovaný, Dokončený, Zrušený, zařazení do fáze či podfáze projektu. Po zadání nové úlohy, systém vygeneruje a přiřadí nový úkol na akceptaci k danému řešiteli ve stavu Nový. Jednotlivé úkoly lze spravovat na kartě Úkoly, kde je přehled všech úloh daného uživatele, který mění stav, či jiné data dle reality. Požadavky slouží k vytvoření podnětu pro úkol, mohou je vytvářet všichni uživatelé vývojového týmu. Každý požadavek má název, projekt, popis a pole pro další poznámky. Zadavatel požadavku může při tvorbě navrhnout řešitele požadavku a určí schvalovatele (projektového manažera). Požadavky, stejně jako úkoly mají v každém momentu příslušný některý z následujících stavů: Nový, Schválený, Zamítnutý. Jestliže je požadavek schválen, 41

bude v aplikaci možnost z něj rovnou vytvořit úkol, který ponese informaci, z jakého požadavku vznikl a požadavek naopak ponese informaci o vzniklém úkolu. Systém zasílá notifikace o požadavcích vybraným schvalovatelům prostřednictvím e-mailu a ohlášení při přihlášení schvalovatele do systému. Na kartě Požadavky je možno spravovat a vyhledávat jednotlivé požadavky na základě následujících parametrů: datum, zadavatel, název požadavku a stav požadavku. V rámci aplikace bude umístěna také nástěnka pro nekategorizované vzkazy a poznámky s možností přílohy. Každý uživatel bude moci zadat vzkaz a případně vzkaz smazat. Uživatelé mohou mazat pouze vzkazy, které sami vytvořili. Vzkazy bude možno vyhledávat standardně podle data, zadavatele a názvu. Účastníci projektu mohou pracovat s úkoly a požadavky, zadávat nové informace o projektu, pracovat s dokumentací. Jednotliví účastníci projektu jsou vedeni na kartě tým. Osoby mají atributy: křestní jméno a příjmení, datum narození, dovednosti, vzdělání, popisné informace a pozici. Jsou dány následující pozice: projektový manažer, vedoucí implementační oblasti, vedoucí technického týmu, organizační vedoucí, funkční konzultant, technický konzultant/vývojář, uživatel. Každý uživatel má po přihlášení do systému možnost podívat se na svoji osobní kartu, kde je seznam akceptovaných úkolů, u kterých je řešitelem. U těchto úkolů může měnit stav na dokončený. Dále se na kartě zobrazují notifikace o zadaných úkolech a požadavcích na uživatele. Uživatel může s notifikacemi pracovat ve smyslu akceptace či zamítnutí požadavku nebo úkolu. Součástí systému je i sklad dokumentace, kde se strukturovaně, dle jednotlivých fází a jejich částí, ukládají dokumenty (dokumenty dané metodikou jako výstupy jednotlivých fází a ostatní dokumenty) a odkud se budou moci stáhnout šablony pro jednotlivé druhy dokumentace. Dokumenty nesou následující atributy: podfáze, cestu k souboru, název souboru, poznámky a typ dokumentu (pokud je dokument jedním z převolených typů pro určitou fázi). Uživatelé mohou také odstraňovat dokumenty, které vytvořili nebo požádat o odstranění SYSADMINA. V zobrazení aplikace bude existovat časová osa, pod níž budou vyznačeny doby trvání: projektu, jejich fází a jednotlivých úkolů. Úkoly budou vyznačeny barvou řešitelů, aby bylo zřejmá vytíženost osob. To by mělo napomáhat při časové orientaci prací na projektu.

4.1.3 Model jednání

4.1.3.1 Seznam rolí systému Systémový administrátor Sysadmin: Uživatel s touto rolí může: 1. Start/Stop systému 2. Spravovat entity systému – fáze,podfáze,typy úloh 3. Dále může využívat veškeré funkce, které využívá role Manager.

42

Manažer/Vedoucí na projektu Manager: Uživatel s touto rolí může: 1. Uzavírat a vytvářet projekty 2. Schvalovat nebo zamítat požadavky 3. Spravovat zdroje projektu 4. Zadávat a aktualizovat úkoly pro uživatele 5. Dále může využívat veškeré funkce, které využívá role Consultant.

Technický/Funkční konzultant/vývojář Consultant: Uživatel s touto rolí může: 1. Přijímat a spravovat vlastní úlohy 2. Spravovat sklad dokumentace 3. Dále může využívat veškeré funkce, které využívá role User

Uživatel User: Uživatel s touto rolí může: 1. Přihlašovat se do systému 2. Zadávat požadavky pro vytvoření úkolu 3. Využívat sklad dokumentace 4. Vkládat vzkazy na nástěnku

4.1.3.2 Sysadmin Use-case diagram Start/Stop systému *

«extends»

**

Správa fází

«extends» Spravovat entity systému

Správa typů

* Sysadmin

Obr. 4.1.: Diagram případů použití sysadmin

4.1.3.3 Manager Use-case diagram

43

«extends»

Vytvoření projektu

Správa projektů «extends» Uzavření projektu

Správa požadavků

«extends» Zamítnutí

«extends» Manager

Akceptování

«uses»

«extends» Vytváření

Přiřazení role «uses»

Správa zdrojů «uses» «extends»

Zadání atributů

«extends» Editace

Změna role «extends»

Vytvoření úkolu Změna atributů «uses»

Přiřazení řešitele

User

Obr. 4.2.: Diagram případů použití manager

4.1.3.4 Consultant Use-case diagram

44

Obr. 4.3.: Diagram případů použití consultant

45

4.1.3.5 User Use-case diagram

Obr. 4.4.: Diagram případů použití user

46

4.1.4 Požadavky na HW a SW

4.1.4.1 Hardware Fujitsu Siemens PRIMERGY RX200S2 RAID • • • • • • • •

procesor Intel. Xeon. 3,00 GHz 1 GB DDR-RAM PC2-3200 ECC (podpora Hot Spare, Mirroring) CD RW/DVD-ROM RAID 0, 1 2x 73 GB HDD 1" 10k U320 SCSI Hot Plug provedení rack (1U), dual Gb LAN Rack-mount kit, management SW ServerView doživotní záruka

4.1.4.2 Software • •

OS Unix(Linux, Solaris) Oracle Database 10g Express Edition

•

Oracle Application Server 10g Release 3

•

Oracle Containers for J2EE (OC4J) 10g Release 3

4.1.5 Datový model

47

4.1.5.1 DBS E-R Diagram

Stage_parts PK

Stage_part_id

FK1

Stage_id Stage_part_name Description Created_by Creation_date

PK

pl_id

FK3 FK4 FK1

Stage_ID project_id stage_part_id pl_type status att_id att_char description

Projects PK

Project_ID Project_name Creation_date Crated_by Description

PK PK,FK6

FK2 FK1

FK3 FK4 FK5 FK7

Task_id Request_id Task_name Description Creation_date Created_by Project_id Stage_id Date_from Date_to Deadline Notes Stage_part_id Status_id Task_type_id Solver_id

PK

Stage_ID Stage_name Creation_date Created_by

Documents PK

Doc_id

FK2

Stage_part_id Path File_name Notes Created_by Creation_date Doc_type_id

Requests PK

Request_id

FK2

Stage_id Description Notes Created_by Creation_date Project_ID S_person_id A_Person_id Status_id Task_id

FK5

Tasks

Stages

Project_lookup

FK1 FK3 FK4 FK6 FK7

FK1 FK3

Doc_types PK

Doc_type_id Type_name Description Created_by Creation_date

People PK

FK1

Statuses

Person_id First_Name Last_Name Birth_date Created_by Creation_date Description Function_id Skills Education

PK

Status_id Status_name Description Creation_date Created_by Status_type

Notes Work_Functions task_type PK

PK

Note_id

FK1

Text Header Created_by Creation_date Attachments

Function_id

Task_type_id Description Created_by Creation_date

PK

Function_name Description Created_by Creation_date

Obr. 4.5.: Datový model systému

48

4.1.6 Seznamy typů uživatelů, dokumentů a úkolů

4.1.6.1 Seznam typů uživatelů a jejich oprávnění: Projektový manažer (dodavatel) Role: Manager Přihlašuje se do systému. Ukončuje projekt. Zadává a updatuje úkoly pro vedoucí implemetačních oblastí, vedoucího technického týmu, funkční a technické konzultanty/vývojáře. Zadává požadavky pro projektového manažera (zákazník) a organizační vedoucí. Schvaluje nebo zamítá požadavky. Umísťuje dokumenty do skladu dokumentace, odstraňuje je a může stahovat šablony. Umísťuje vzkazy na nástěnku. Projektový manažer (zákazník) Role: Manager Přihlašuje se do systému. Zadává a updatuje úkoly pro organizační vedoucí a uživatele.. Zadává požadavky pro projektového manažera (dodavatel), vedoucí implemetačních oblastí a vedoucího technického týmu. Schvaluje nebo zamítá požadavky. Umísťuje dokumenty do skladu dokumentace, odstraňuje je a může stahovat šablony. Umísťuje vzkazy na nástěnku. Vedoucí implementační oblasti Role: Manager Přihlašuje se do systému. Zadává a updatuje úkoly pro funkční konzultanty. Zadává požadavky pro projektového manažera (dodavatel, zákazník), vedoucího technického týmu a organizační vedoucí. Schvaluje nebo zamítá požadavky. Umísťuje dokumenty do skladu dokumentace, odstraňuje je a může stahovat šablony. Umísťuje vzkazy na nástěnku. Vedoucí technického týmu Role: Manager Přihlašuje se do systému. Zadává a updatuje úkoly pro technické konzultanty/vývojáře. Zadává požadavky pro projektového manažera (dodavatel, zákazník), vedoucí implementačních oblastí a organizační vedoucí. Schvaluje nebo zamítá požadavky. Umísťuje dokumenty do skladu dokumentace, odstraňuje je a může stahovat šablony. Umísťuje vzkazy na nástěnku.

Organizační vedoucí Role: Manager Přihlašuje se do systému. Zadává a updatuje úkoly pro uživatele. Zadává požadavky pro projektového manažera (dodavatel, zákazník), vedoucí implementačních oblastí a vedoucího technického týmu. Schvaluje nebo zamítá požadavky. Umísťuje dokumenty do skladu dokumentace, odstraňuje je a může stahovat šablony. Umísťuje vzkazy na nástěnku. Funkční konzultant Role: Consultant

49

Přihlašuje se do systému. Zadává požadavky pro projektového manažera (dodavatel, zákazník), vedoucí implementačních oblastí, vedoucího technického týmu a organizačního vedoucího. Umísťuje dokumenty do skladu dokumentace, odstraňuje je a může stahovat šablony. Umísťuje vzkazy na nástěnku. Technický konzultant/vývojář Role: Consultant Přihlašuje se do systému. Zadává a updatuje úkoly pro uživatele. Zadává požadavky pro projektového manažera (dodavatel, zákazník), vedoucí implementačních oblastí, vedoucího technického týmu a organizačního vedoucího. Umísťuje dokumenty do skladu dokumentace, odstraňuje je a může stahovat šablony. Umísťuje vzkazy na nástěnku. Uživatel Role: User Přihlašuje se do systému. Zadává požadavky pro projektového manažera (zákazník) a organizačního vedoucího. Stahuje dokumenty a šablony ze skladu dokumentace. Umísťuje vzkazy na nástěnku.

4.1.6.2 Seznam typů dokumentů Na obrázku 4.6. jsou zobrazeny veškeré typy dokumentů, které jsou na projektech využívány ve vztahu k jednotlivým fázím projektu. Fáze jsou barevně odlišeny. Dokumenty nevyhovující typovému rozřazení se umísťují do sekce ostatní.

50

Obr. 4.6.: Typy dokumentů

4.1.6.3 Seznam typů úkolů dle jednotlivých fází Definice podnikových požadavků: • Vytvoření (grafického) modelu stávajících procesů (BP070) •

Vytvoření (grafického) modelu budoucích procesů (BP080)

•

Vytvoření strategie aplikačních rozšíření (MD010)

• Vytvoření plánu vzdělávání a školení Analýza operací: • Vytvoření modelu pro každý podnikový proces namapování těchto modelů na aplikace (BR030) •

Hardwarová, softwarová a komunikační doporučení (TA030)

•

Změnové požadavky (popis a seznam) na aplikaci nebo na procesy (CR060)

•

Popis strategie konverze (CV020)

•

Seznam požadavků zákazníka (RD050)

• Definice a ocenění aplikačních rozšíření (MD020) Návrh řešení: • Definice aplikační architektury (TA040) •

Popis nastavení systému (BR100)

•

Řízení přístupu (RD060)

• Mapování konverzních entit (CV040) Tvorba prototypu: • Nastavení systému •

Vytvoření testovacích scénářů (TE040)

• Záznam o akceptačních testech (TE130) Přechod: • Úvodní školení pro klíčové uživatele •

Školení administrace aplikací

•

Školení koncových uživatelů dle definovaných uživatelských postupů

•

Nastavení produkčního prostředí

•

Migrace dat

Pro naprostou většinu těchto úkolů existuje dělení úkolů ještě podle implementovaných modulů. Proto bude např. úkol Popis nastavení systému (BR100) vytvořen v několika variantách BR100 pro modul závazky, pohledávky, hlavní knihu, majetek….

4.2 Scénáře použití a diagram aktivit Pro další popis aplikace jsem vybral následující scénáře a k nim příslušný diagram aktivit: 51

•

zadání a akceptace úkolu

•

zadání a schválení požadavku

•

manipulace s dokumentem

•

zadání a smazání vzkazu na nástěnce

4.2.1 Zadání a akceptace úkolu Pro diagram aktivit pro úkol vezměme v úvahu konkrétní případ, kdy chce projektový manažer zadat úkol funkčnímu konzultantovi např. vytvoření funkční specifikace prostřednictvím dokumentu MD050. Kroky scénáře: •

Zadavatel se přihlásí do aplikace

•

je-li přihlášen, načte se hlavní stránka aplikace

•

výběr projektu

•

zvolí kartu tým nebo úkoly

•

pokud kartu tým, vybere řešitele a stiskne vytvořit úkol, poté přejde na kartu úkoly do formuláře pro nový úkol s doplněným řešitelem

•

pokud kartu úkoly, stiskne vytvořit úkol, přejde do formuláře pro nový úkol, řešitele vybírá s LOV

• •

doplní data pro nový úkol, tj typ, časové mantinely, fáze projektu, podfáze, popis a poznámky. Stiskne dokončit vytvoří se úkol ve stavu nový, zadavatel může opustit aplikaci

•

systém odešle notifikace řešiteli

•

řešitel se přihlásí do aplikace

•

je-li přihlášen, načte se hlavní stránka aplikace

•

přejde na osobní kartu

•

v seznamu notifikací vybere příslušný nový úkol, přečte si informace, akceptuje či odmítne danou položku, nastaví se příslušný stav na akceptovaný resp neakceptovaný

•

v případě akceptace, přidá se úkol pod řešitelovu správu.

•

Řešitel může opustit aplikaci

52

Obr. 4.7.: Diagram aktivit pro úkol

53

4.2.2 Zadání a schválení požadavku Pro diagram aktivit pro požadavek vezměme opět v úvahu konkrétní případ, kdy chce funkční konzultant zadat požadavek na vývoj customizace vedoucímu technického týmu s tím, že rovnou doporučí k řešení určitého technického konzultanta. Kroky scénáře: •

Zadavatel se přihlásí do aplikace

•

je-li přihlášen, načte se hlavní stránka aplikace

•

výběr projektu

•

zvolí kartu TÝM nebo požadavky

•

pokud zvolí kartu TÝM , vybere konkrétní osobu, stiskne tlačítko požadavky, dostane se na kartu nový požadavek pokud zvolí kartu POŽADAVKY, stiskne tlačítko nový požadavek, volitelně vybere možného řešitele

• •

vyplní detail požadavku, fázi, případně změní schvalovatele

•

stiskne tlačítko dokončit

•

může se odhlásit z aplikace nebo pokračovat v další práci

•

požadavek se zadal do systému ve stavu nový, systém odešle notifikaci k schvalovateli

•

schvalovatel se přihlásí do systému

• •

na osobní kartě nalezne notifikaci na schválení požadavku, kliknutím na zprávu, přejde na seznam požadavků zde může prozkoumat detail požadavku, schválit ho či zamítnout.

•

v případě schválení, je potřeba zadat nový úkol nebo vytvořit úkol z požadavku

•

vytvoření nového úkolu je popsáno ve scénáři pro úkol

•

při vytváření úkolu z požadavku, systém převede požadavek na úkol

•

může se odhlásit z aplikace nebo pokračovat v další práci

54

Obr. 4.8.: Diagram aktivit - požadavek

55

4.2.3 Manipulace s dokumentem Diagram aktivit pro manipulaci s dokumentem v sobě zahrnuje všechny uživatelské možnosti práce s dokumentem. Kroky scénáře: •

uživatel se přihlásí do aplikace

•

je-li přihlášen, načte se hlavní stránka aplikace

•

výběr projektu

•

navigace do skladu dokumentace

•

vybere fázi projektu, podfázi projektu

•

vybere typ a označí konkrétní dokument

•

vybere typ úkonu, nahrát, stáhnout, smazat

•

po výběru se může odhlásit z aplikace nebo pokračovat v další práci [Nesprávné jméno/heslo] Dokumet spadá buď do kategorie předvolené pro danou část nebo do kategorie "ostatní".

Přihlášení uživatele

[bez oprávnění]

Výběr projektu

Přechod na sklad dokumentace

Výběr fáze

Výběr podfáze

Odstranění dokumentu

Download šablony/dokumentu

Výběr typu dokumentu

Odhlášení

Upload dokumentu

Obr. 4.9.: Diagram aktivit - dokumenty

4.2.4 Zadání a smazání vzkazu na nástěnce Diagram aktivit pro nástěnku v sobě zahrnuje veškeré uživatelské možnosti práce s nástěnkou. Kroky scénáře: •

uživatel se přihlásí do aplikace

56

•

je-li přihlášen, načte se hlavní stránka aplikace

•

výběr projektu

•

otevře stránku s nástěnkou, pomocí menu

•

zobrazí se posledních 10 příspěvků, další jsou stránkovány

•

pomocí filtru může vyhledávat v přízpěvcích

•

pokud je vybraný vzkaz přihlášeného uživatele, může ho měnit či smazat

• •

pokud chce vložit nový, stiskne tlačítko nový , vyplní nadpis, text, nepovinně přílohu stisknutím Dokončit vloží příspěvek na nástěnku

•

může se odhlásit z aplikace nebo pokračovat v další práci

Obr. 4.10.: Diagram aktivit - nástěnka

4.3 Technologická specifikace Realizace aplikace bude probíhat pomocí technologie Oracle Application Development Framework, což je end-to-end aplikační rámec, který staví na J2EE standardech a open-source technologiích pro snadné a rychle implementace. Oracle JDeveloper je vývojové prostředí, ve kterém se bude program psát, pomocí výše uvedených technologií. Oracle ADF rozhraní je vhodné a určené pro budování webových aplikací nad databází Oracle, použitím JSP a JSF standardů, což jsou technologie obsahující kontejnery pro vývoj právě takových aplikací.

57

Systém bude složen ze tří vrstev. Aplikace bude postavena nad Oracle databází, kde bude mít kde bude mít vlastní schéma, toto bude nejnižší, databázová vrstva. Aplikační vrstva bude obsahovat daný program nahraný na aplikačním serveru, který bude komunikovat jednak s databází a jednak s klientskou vrstvou, což bude třetí vrstva. Klientská vrstva používá webový prohlížeč, přes který bude uživatel komunikovat s aplikací. Aplikace tudíž bude přístupná jak z lokálního serveru tak s klientských PC přes síť. Aplikace bude postavena na Java konceptu MODEL-VIEW-CONTROLLER, na standartu JSP – JavaServer Pages. View vrstva bude obsahovat grafické rozhraní programu. Controller vrstva bude ovládat chování aplikace a v Model vrstvě budou veškeré deklarace objektů a kompletní business logika.

Obr. 4.17.: Java koncept M-V-C

Zdroj: Oracle Applications Framework: Developer´s Guide, ORACLE CORPORATION.

58

Pro běh aplikace je potřeba nainstalovat Oracle databázi, Oracle application server a ADF runtime knihovny. Aplikaci je možné testovat přímo na lokálním vyvojovém počítači, bez nutnosti nahrávání na aplikační server, což ulehčuje ladění aplikace. Jelikož je používání Java technoligií dnes velice na vzestupu, můžeme očekávat bezproblémovou údržbu systému, či další úpravy vycházející z praktického používání.

Obr. 4.18.: Diagram nasazení

Všechny použité technologie jsou pro testovaní a nekomerční použití volně k dispozici.

59

4.3.1 Struktura View modulu

Obr. 4.19 : Mapa JSP stránek

60

5 Testování aplikace Testování proběhlo na dvou úrovních: •

Při kódování aplikace

•

Post implementační testy dle testovacích scénářů

5.1 Testovací scénáře a výsledky testů Scénáře vycházejí z kapitoly 4.2 Scénáře použití: Název scénáře Zadání a akceptace úkolu

Výsledek Úspěch

Zadání a schválení požadavku

Úspěch

Manipulace s dokumentem

Úspěch

Zadání a smazání vzkazu na nástěnce

Úspěch Tab. 5.1: Výsledky testů 1

Doplňující testy: Popis scénáře Vytvoření a úprava nového projektu

Výsledek Úspěch

Vytvoření a úprava zdrojů

Úspěch

Vytvoření a úprava funkcí

Úspěch Tab. 5.2: Výsledky testů 2

61

62

6 Diskuse nad výsledky Bakalářská práce se lehce odklonila od mích původních představ když jsem formuloval zadání, které jsem si sám navrhl. V průběhu studování problematiky řízení projektů, specielně pak řízení implementace EBS, jsem usoudil, že bez seriozního teoretického rozboru této problematiky, bude práce pozbývat smyslu. Proto jsem kladl důraz na teoretický základ a návrh, implementace s toho vyšla finálně trochu nevýrazně, nesložitě. Přidání nových funkcionalit do aplikace je v podstatě rutinní záležitost a nepřinesla by nic nového do této práce. Otázkou zůstává využití aplikace v praxi. Jak jsem již avizoval, pro komerční využití by bylo třeba zdetailnit jednotlivé entity a přidat další funkce, npř. statistiky, jednalo by se o jednoduchou implementaci, aplikace je připravena. Použitá technologie J2EE se osvědčila jako velice vhodná právě pro tento typ aplikace. Umístění na aplikačním serveru umožňuje vzdálený přístup více uživatelů přes webové rozhraní, data v databázi mohou využívat jiné aplikace, jiné technologie. Snad jediný negativní element při této práci byl nástroj Oracle Jdeveloper, ve kterém jsem aplikaci vyvíjel. Problém byl v jeho náročnosti na operační paměť při používání Desing módu pro vytváření JSP stránek. V kombinaci se spuštěným oc4j standalone serverem pro testování stránek, byla práce s 1GB RAM opravdu složitá.

7 Závěry a doporučení Závěrem bych rád uvedl, že práce dopadla úspěšně s uspokojujícím výsledkem. Mohutnost teorie sice přesáhla mou původní představu, ve výsledku ji ale považuji za optimální vůči smyslu práce. Testování potvrdilo požadovanou funkcionalitu aplikace. Aplikace může být přínosem pro menší týmy, pracující na implementaci Oracle EBS, zejména v týmové komunikaci, správě úkolů a dokumentace. Rád bych poděkoval svému vedoucímu práce ing. Michalu Voráčkovy za trpělivost a kolegům z mého pracovního týmu za materiály a hodnotnou konsultaci.

63

64

8 Literatura a reference [1] Jiří Voříšek , Informační systémy a jejich řízení Olimpia, 2004 [2] Vladimír Šebek, Řízení projektů a podnikových procesů Studijní materiál [3] Michal Čadek, Metodika implementace AIM Zonner Press, 2003 [4] Oracle 11i EBS Documentation Library Profesionální dokumentace k EBS, Oracle 2004 [5] Oracle technology network http://www.oracle.com/technology/ [6] Tomáš Černý, UML Naruby Studijní materiál

65

PŘÍLOHY

66

PŘÍLOHY

A. Seznam zkratek ADF

(Application Development Framework) J2EE Oracle aplikační rámec

AIM

(Application Implementation Methodology) Metodika pro implementaci Oracle EBS

CRM

(Customer relationship management) IS pro řízení vztahů se zákazníky

EBS

(E-Business Suite) Plně integrovaný podnikový informační systém od Oracle

ERP

(Enterprise Resource Planning) IS který integruje a automatizuje velké množství procesů souvisejicich s produkčními činnostmi podniku

HRM

(Human resource management) IS pro řízení lidských zdrojů

IS

(Information System) Informační systém

J2EE

(Java 2 Enterprise edition) Rozšířená edice Javy pro více vrstvé aplikace

JSF

(Java Server Faces) Java-based rámec pro webové aplikace

JSP

(Java Server Pages) Technologie generování HTML a XML kódu pomocí Javy

LAN

(Local Area Network) Lokální síť

SCM

(Supply chain management) IS pro řízení dodavatelských řetězců

WBS

(work breakdown structure) Hierarchický rozpad projektu na etapy, kroky a úkoly

67

PŘÍLOHY

68

PŘÍLOHY

B. Obsah přiloženého CD /readme.txt – popis stěžejních složek a souborů na CD /dbs – složka obsahující instalaci databázové vrstvy /app – složka obsahující zdrojové soubory aplikace /doc – složka s dokumentací

69