Návrh systému internetového katalogu podnikatelských subjektů

Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta

Návrh systému internetového katalogu podnikatelských subjektů Diplomová práce

Vedoucí práce: doc. Ing. Ivana Rábová, Ph.D.

Bc. Viktor Šuman

Brno 2009

1

2

Je mojí příjemnou povinností zde poděkovat vedoucí mojí diplomové práce doc. Ing. Ivaně Rábové, Ph.D. za její ochotnou pomoc, cenné rady a podněty při psaní této práce, stejně jako při absolvování předmětů pod jejím vedením, které mi rovněž poskytly mnoho inspirace pro samotnou práci.

3

Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatně a s použitím literatury, která je uvedena v seznamu na konci stati. V Brně, dne 20. května 2009

…..…………………………

4

Abstract Šuman, V. Modelling the concept of the web based company catalog. Diploma thesis. Brno, 2009. My diploma thesis concerns about the issue of web based company catalog, describes the main basis of the system itself and analyses activities related to the system of company catalog. Work proposes the basic functionality and extensional alternatives and describes them via basic analytical models including the data model suitable for the mapping to the relational database. Furthermore there are compared the economical aspects and the general suitability of the particular alternative. Diploma thesis uses the Business Process Modeling Notation and the Unified Modeling language (UML).

Abstrakt Šuman, V. Návrh systému internetového katalogu podnikatelských subjektů. Diplomová práce. Brno, 2009. Práce se zabývá tématem internetového katalogu, popisuje základní východiska systému takového katalogu a provádí analýzu činností s provozováním katalogu. Dále navrhuje základní funkcionalitu a rozšiřující varianty a znázorňuje je pomocí základních analytických modelů včetně datového modelu vhodného pro namapování do relační databáze. V práci jsou následně porovnány ekonomické aspekty a celková vhodnost konkrétních variant. Diplomová práce využívá notace Business Process modelování a jazyka UML.

5

Obsah 1

Úvod do problematiky......................................................................................... 8

2

Cíl práce ............................................................................................................... 10

3

Teoretická východiska ....................................................................................... 11 3.1 Informace a systém...............................................................................11 3.2 Proces a podnikový proces..................................................................11 3.3 Model......................................................................................................12 3.4 Projektování...........................................................................................13 3.5 Metodiky UML a BPM ........................................................................13 3.6 Modelování podle Erikssona...............................................................15 3.7 CASE nástroje.......................................................................................17 3.8 Internetový katalog...............................................................................18 3.9 SEO ........................................................................................................19

4

Východiska základního metamodelu ............................................................... 22 4.1 Podnikové zdroje ..................................................................................22 4.2 Podnikové cíle .......................................................................................24 4.3 Podniková pravidla ...............................................................................26 4.4 Podnikové procesy ...............................................................................28

5

Metamodel podnikových konceptů ................................................................. 33

6

Metodika .............................................................................................................. 34

7

Požadavky na systém ......................................................................................... 35

8

Základní model ................................................................................................... 37 8.1 BPM základního modelu .....................................................................37 8.2 Základní use case model ......................................................................38 8.3 Ekonomický přístup .............................................................................40

9

Alternativní model bez zpoplatněných služeb ............................................... 41 9.1 BPM ........................................................................................................41 9.2 Use case..................................................................................................44 9.3 Ekonomický přístup .............................................................................45

10 Alternativní model s garancí zobrazení........................................................... 48 10.1 BPM ........................................................................................................48 10.2 Podniková pravidla ...............................................................................51 10.3 Use case model......................................................................................52 10.4 Class model............................................................................................54 10.5 Activity diagram ....................................................................................56 10.6 State diagram .........................................................................................58 10.7 Datový model........................................................................................60 10.8 Ekonomický přístup .............................................................................64 11 Diskuse................................................................................................................. 67 12 Závěr .................................................................................................................... 68 13 Použitá literatura................................................................................................. 69

6

Přílohy.......................................................................................................................... 70 A Diagramy UML pro základní model.................................................................. 71 B Diagramy UML pro variantu bez zpoplatnění ................................................. 74 C Diagramy UML pro variantu s garancí .............................................................. 77

7

1 Úvod do problematiky V současné době jsme svědky dramatického růstu významu informačních technologií pro celou společnost. Proto není překvapením, že se prostředky vynaložené na zviditelnění jednotlivých společností na internetu neustále zvyšují a způsoby, jak se na internetu dobře zaindexovat, se dostávají do popředí zájmu nejen manažerů všech společností, ale i malých živnostníků. Jedním ze způsobů, jak zvýšit návštěvnost webové prezentace konkrétní společnosti, je registrace do internetových katalogů. Jde o databáze odkazů na webové stránky tříděné podle oborů podnikatelské činnosti, zaměření jejich činnosti a obvykle také dle geografických atributů (umístění v rámci regionálního vyhledávání). Přidání odkazu do takového katalogů bývá zdarma, pouze případné nadstandardní služby související s daným záznamem jsou zpoplatňovány. Umístění v takových katalozích přináší jednak větší šanci na získání zákazníka, který si v katalogu firmu vyhledá, ale také (a mnohdy především) z důvodu zvyšování tzv. ranku (hodnocení) konkrétní webové stránky. Toto hodnocení používají jednotlivé fulltextové vyhledavače pro rozlišení kvality stránek relevantních ke konkrétnímu vyhledávanému řetězci. Umístění stránek v rámci výsledků vyhledávání (pořadí) je pak závislé právě na tomto ohodnocení konkrétního záznamu. Naprostá většina uživatelů navštíví odkaz z první strany výsledků vyhledávání a významná část uživatelů dokonce vyhledává jiný řetězec, pokud si nevyberou z prvních pěti odkazů v rámci výsledků vyhledávání. Odhaduje se, že pokud je odkaz na nějakou společnost například až na dvacáté straně výsledků vyhledávání a poté dojde k přesunu na první stranu výsledků, zvýší se počet návštěv takové stránky až desetinásobně. Podíl vyhledavačů na českém trhu je charakteristický dominantním postavením vyhledavače Seznam, které je dlouhodobě oslabováno mezinárodním vyhledavačem Google. Dle průzkumu na konci roku 2008 je i přes stabilní pokles stále nejvýznamnějším vyhledavačem Seznam (61 %), následuje Google (33 %) a další již méně významné vyhledavače Centrum (3 %) a Atlas (1 %). Pozice Googlu posílila meziročně o téměř čtyři procentní body (jako jediný vyhledavač tak posiluje svoji

8

pozici, ostatní dlouhodobě oslabují) a dosahuje tak prakticky třetinového podílu na našem trhu. Jedinečnost postavení Seznamu dokládá také to, že Česká republika je jednou z pěti zemí, kde Google nemá většinový podíl na trhu vyhledavačů. Přesné podíly jednotlivých vyhledavačů v České republice jsou následující (údaje platné k říjnu 2008) [Louda, 2008]: •

Seznam – 60,85 %,

•

Google – 32,61 %,

•

Centrum – 2,61 %,

•

Atlas – 0,97 %,

•

Jyxo – 0,14 %. Zlepšení tohoto umístění v rámci výsledků vyhledávání lze dosáhnout

optimalizací prezentovaných stránek pro fulltextové vyhledavače. Optimalizaci lze provádět na vlastních stránkách společnosti (respektování doporučení pro tvorbu WWW stránek) a především umístěním odkazů na svoje stránky na co největším počtu dalších webů. Dle hodnocení webu s odkazem na danou prezentaci je započítán tento odkaz s různou váhou, přičemž toto hodnocení je závislé jak na vlastnostech daného webu, tak i na množství návštěvníků. Pro kvalitní umístění v rámci vyhledávání ve fulltextových je tedy dobré, když na danou stránku vede velké množství odkazů z jiných (dobře hodnocených) stránek. Takovými stránkami jsou například internetové katalogy, které obsahují odkazy na firmy utříděné do sekcí s vhodnými klíčovými slovy a jejich návštěvnost je také nesrovnatelně vyšší oproti běžné firemní prezentaci.

9

2 Cíl práce Jako student druhého ročníku navazujícího magisterského studia na Provozně ekonomické fakultě Mendelovy zemědělské a lesnické univerzity v Brně oboru Ekonomická informatika jsem hledal pro svoji diplomovou práci takové téma, kde bych mohl využít spojení ekonomických věd s informatikou a respektovat tak zvolený studijní obor. Domnívám se, že zvolená problematika návrhu a zhodnocení ekonomických přínosů jednotlivých variant pojetí sysétmu internetového katalogu tyto požadavky splňuje. V této diplomové práci se snažím navrhnout pomocí nástrojů objektového modelování potřebnou funkcionalitu systému internetového katalogu, který získává, uchovává a prezentuje informace o podnikatelských subjektech. Takový katalog zpravidla řeší: •

vstup dat do systému (více možností),

•

uchování dat v systému a jejich administrace,

•

prezentace dat systémem (uživatelská rozhraní a samotné vyhledávání),

•

související funkce – vystavování faktur, souhrnné výpisy, exporty pro účetnictví a další. Cílem práce je navrhnout, popsat a namodelovat základní funkcionalitu

internetového katalogu a zamyslet se nad možnostmi pojetí takového systému. Dálším cílem je detailněji popsat jednu z variant a na základě objektového přístupu navrhnout namapování tohoto systému do relační databáze. K tvorbě diagramů diplomové práce využívám programového CASE nástroje Enterprise Architect společnosti Sparx Systems a na základě jazyka UML využívám doporučenou notaci business modelování.

10

3 Teoretická východiska 3.1 Informace a systém Informace jako základní element pro další úvahy je obvykle definována jako objekt s těmito vlastnostmi: •

snižuje entropii, neurčitost (doplňuje poznatky),

•

je obsažena v signálech i vzájemném uspořádání signálů v rámci zpráv,

•

tyto signály poskytují informaci pouze tomu, kdo je schopen rozpoznat jejich syntaxi a pochopit sémantiku (tj. rozumí konkrétní zprávě),

•

je nehmotná [Konečný, 2006].

Dále je třeba definovat pojem systém (česky můžeme vyjádřit jako soustava) – pro naše účely postačí neformální (kvalitativní) definice, zde uvádím některé z nich. •

Systém je komplex prvků nacházejících se ve vzájemné interakci (Bertalanffy, 1956).

•

Systém je množina objektů spolu se vztahy mezi nimi a mezi jejich atributy (Hall, 1956).

•

Systém je soubor prvků ve vzájemné interakci (řada dalších autorů).

Pokud bychom požadovali také formální definici, lze pohodlně použít definici Prof. M. Vlčka: „Systém S je konečná množina prvků Q a množina vazeb A mezi nimi, s dynamickým, účelovým chováním S=(Q,A).“

3.2 Proces a podnikový proces Slovo processus, v latině znamenající „postupovat“ či „vyjíjet se,“ je obecným označením pro postupné změny – posloupnosti stavů daného systému. V kontextu této práce obvykle pod pojmem proces ruzumíme podnikové procesy.

11

Podnikový proces můžeme definovat jako „souhrn činností, transformujících souhrn vstupů do souhrnu výstupů (zboží nebo služeb) pro jiné lidi nebo procesy, používajíce k tomu lidi a nástroje“ [Řepa, 2006].

Obr. 1: Základní schéma podnikového procesu

3.3 Model Model je grafickým vyjádřením reality, tedy obvykle nějakého objektu či systému, může být abstraktní či hmotný a popisovat nějakou komplexní entitu nebo proces. V kontextu této práce tedy jde o tvůrčí činnost popisu vlastností a chování podnikových procesů. Modelováním nazýváme systematickou činnost vedoucí k vytvoření modelu. Při modelování podnikových procesů bychom se měli zaměřit na následující otázky [Eriksson, Penker, 2000]: •

jakým způsobem probíhá interakce mezi jednotlivými aktory,

•

jaké dílčí aktivity vykonávají,

•

jaké jsou konkrétní cíle jejich aktivit,

•

jaké další osoby, systémy nebo zdroje se podílejí na daném systému a nevystupují jako aktoři,

•

jaká jsou pravidla řídící jejich činnost a strukturu,

•

jakým způsobem by mohli aktoři pracovat efektivněji? Vytváření modelů umožňujících odhadnout efekty plánovaných změn

v systému bez nutnosti do tohoto systému zasahovat se rozšířilo nejen do oblasti softwarového inženýrství, ale také v oblasti strategického rozhodování a dalších odvětví podnikové sféry.

12

3.4 Projektování V případě projektování hovoříme o tzv. projektu systému, který definuje norma ČSN 36 9001/20-1987 jako popis systému, jeho funkcí, údajových obsahů, ručních i automatických postupů a jeho vztahu k jiným systémům. Projektování je tvůrčí proces se specifickými vlastnostmi, který pomocí systémových modelů zabezpečuje konkrétní technické, ale i ekonomické cíle organizace. Na projektování tedy lze pohlížet jako na „posloupnost činností, které vedou od úvodního nápadu až k realizaci projektu.“ Pokud hovoříme o systémovém projektování, jde o projektování systému při dodržení všech pravidel systémového přístupu [Konečný, 2006]. Samotný proces projektování lze rozdělit do tří fází: •

identifikace systému (vytvoření základní verze modelu),

•

návrh fyzické realizace funkcí jednotlivých částí objektů odpovídajících funkcím jednotlivých prvků v systému,

•

optimalizace a ověření systému. Cílem projektování většiny systémů je navrhnout objekt s optimálními

systémovými vlastnostmi, tedy se zabývá „návrhem a optimalizací na úrovni systémového modelu a interpretací dosažených výsledků při návrhu fyzické realizace objektu“ [Konečný, 2006].

3.5 Metodiky UML a BPM Jak již bylo řečeno, model je grafickým znázorněním skutečného systému. Pro potřeby modelování v rámci softwarového inženýrství bylo vyvinuto mnoho metodik, jak ke konkrétnímu modelování přistupovat a využívají různé formy zápisu (nejčastěji grafické prvky) – modelovací jazyky. UML – Unified Modeling Language je jazyk pro vývoj programových (aplikačních) systémů, pro který poskytuje potřebné nástroje. Od jeho uvedení v roce 1997 se UML stalo standardním modelovacím jazykem pro vývoj softwaru. Základní UML sestává z devíti odlišných typů diagramů, kde každý zobrazuje specifický statický nebo dynamický aspekt systému [Eriksson, Penker, 2000].

13

UML standardizuje zápis pro popis procesů, ale nedefinuje tyto jednotlivé procesy. UML tedy může být použito pro mnoho odlišných podnikových procesů a výrobních postupů a výsledný model, respektive jeho kvalita a přínosnost, závisí proto vždy na zkušenostech vývojáře či pracovního týmu a neexistuje žádný obecný způsob či popis tvorby takového modelu, který by vedl vždy k požadovaným výsledkům. Pro použití notace jazyka UML ve sféře podnikového modelování je důležité si uvědomit, že podnikové modelování je možné považovat za pouhé rozšíření modelování softwarového a že UML může díky svojí nezávislosti a použitelnosti pro projekty různých velikostí i cílů dobře použitelné i v této oblasti. Navíc taková jednotná notace v celém vývojovém životním cyklu projektů prináší nesporné výhody, jako jsou například jednodušší komunikace a celková vyšší efektivnost týmu pracovníků na projektu. Základním pohledem systémů založených na UML je use case, vyjádřený use case modelem poskytujícím vnější pohled na chování systému, a to tak, jak jej vidí uživatelé. Životní cyklus se pak po celou dobu řídí tímto modelem. Z pohledu softwarového modelování každý případ užití (use case) specifikuje sekvenci akcí a variant, které vykonává, zatímco pro potřeby podnikového modelování je využito rozšíření UML pomocí tzv. stereotypů a možnosti definovat aktory v podniku a podnikový use case. Use case v kontextu podnikového modelování tak vlastně signalizuje následné použití diagramu aktivit pro podnikový proces nebo workflow [Rábová, 2008]. Použití

UML

v podnikovém

modelování

má

však

také

mnoho

problematických aspektů, jako například definování uživatelů a hranic systému z důvodu vzájemného působení procesů různých podniků nebo například popis interakcí mezi uživatelem a systémem. Transformace podnikové analýzy vnáší do systému požadavky, které i při velmi pěčlivém a kvalitním postupu mohou vést k nejednoznačnosti a někdy i ke špatnému pochopení. Mnoho podnikových analytiků zastává názor, že UML pro modelování podniku není příliš vhodné a use case jsou dle jejich slov specifické pro softwarový vývoj a jsou tak příliš těžkopádné pro seriózně pojatou analýzu podnikových procesů [Rábová, 2008].

14

Díky nepříliš zažíté problematice, vysoké obecnosti a nepříliš přehledné standardizaci došlo k několika pokusům o ustanovení standardu pro tvorbu modelů podnikových procesů. Jedním z takovýchto standardů je metodika BPMN (Business Process Modeling Notation). BPMN je standardizovaná grafická notace pro znázornění podnikových procesů v rámci workflow. Tato notace byla vyvinuta iniciativou BPMI (Business Process Modeling Initiative) a od sloučení s konsorciem OMG (Object Management Group) v roce 2005 je pod její správou. Současnou verzí je 1.1 a v návrhu je verze 2.0. Cílem této notace je dosáhnout srozumitelnosti popisu procesů pro člověka, aniž by bylo nutné slevit z požadavků na flexibilitu a rozšiřitelnost. Základním diagramem je Diagram podnikového procesu (BPD – Business Process Diagram) sestávající z jednotlivých elementů, pro něž jsou definovány základní grafické symboly [Řepa, 2006]. Metodika Business Modeling Architecture (BMA) je metodika sloužící pro podnikové modelování založená na UML, která z modelování podnikových procesů a celého podniku poměrně striktně odděluje analýzu pomocí use case. Use case je v případě BMA použita pouze pro popis požadavků na software. Pro architekturu BMA je podnikový proces základním konceptem a pro popis těchto konceptů využívá metamodel. Procesy jsou chápány jako abstrakce aktivních částí podniku [Rábová,

2008].

Metamodelům

podnikových

procesů

vzniklým

spojením

podnikových konceptů zdroj, cíl, proces a pravidlo představujícím tak základní a poměrně komplexní šablonu pro modelování podniků, se budu věnovat v dalším textu.

3.6 Modelování podle Erikssona Poslední dobou je stále více zřejmá využitelnost notace UML pro prakticky všechny oblasti modelování libovolných systémů. Podniková architektura podle Erikssona je přístupem k modelování celopodnikové architektury vyznačující se komplexním přístupem a systémovostí. Erikssonova architektura pečlivě popisuje a umožňuje pochopit podnik jako systém, popisuje jednotlivé části podniku, jejich spolupráci a strukturu. Její součástí jsou statické (v čase neměnné) i dynamické (proměnlivé) modely popisující jednotlivé

15

části podniku. V kombinaci s vhodným CASE nástrojem je toto modelování velmi výkonným nástrojem pro návrh i restrukturalizaci podnikových procesů. Podnikovou architekturu definuje Eriksson jako „organizovanou sadu prvků s jasnými vztahy mezi sebou, které společně tvoří celek definovaný svou funkcionalitou. Prvky představují organizační strukturu a strukturu chování podnikového systému a ukazují abstrakce klíčových procesů a struktur v podniku“ [Rábová, 2008]. Každý podnikový model by měl co nejlépe podporovat jednotlivé operace v podniku, přičemž Erikssonova architektura splňuje tyto požadavky na informační systém velmi dobře a umožňuje abstrahovat podnikový systém do různých pohledů a zaměřit se vždy na jeden konkrétní aspekt systému pří současné schopnosti potlačit nevýznamné detaily a irelevantní informace, což je vždy nezbytné pro možnost pochopit tak komplexní systém a vztahy v něm, jakým podnik nepochybně je. Aplikace podnikové architektury podle Erikssona by měla splňovat následující vlastnosti a kritéria: •

Popisuje konkrétní podnik s nejvyšší možnou mírou dosažené věrnosti a pravdivosti – snahou je definovat takovou architekturu, která bude realistická a proveditelná nejen pro různé implementace softwarového systému, ale také splňuje strategické cíle podniku a poskytuje prostor pro provádění budoucích úprav a změn.

•

S přiměřenou mírou abstrakce sleduje jednotlivé struktury podniku a klíčové procesy, přičemž tato přiměřenost je vždy závislá na konkrétním případu aplikace.

•

Respektuje shodný pohled zainteresovaných osob operujících v podniku a vyžaduje souhlas pracovníků i managementu podniku s popisovanými skutečnostmi.

•

Řešení je snadno modifikovatelné a rozšiřitelné.

•

Architektura by měla být snadno pochopitelná a podporovat komunikaci mezi jednotlivými relevantními osobami v podniku – architektura, která není pro svoje uživatele pochopitelná, není použitelnou architekturou [Rábová, 2008].

16

Na podnikový systém nelze pohlížet jako na černou skříňku a jelikož zákazníci, dodavatelé a různá pravidla daná okolím jsou nezbytnými (externími) prvky podniku a přitom nejsou v samotném podniku definovány, je třeba na celek nahlížet jako na otevřený systém všech relevantních objektů a částí, které jsou mnohdy zároveň i částmi jiných podnikových systémů. Pro dosažení výše uvedeného výčtu vlastností podnikové architektury vyžaduje: •

Modelera s vysokou znalostí podniku a jeho struktury a zároveň dostatečnými znalostmi modelovacího jazyka pro navržení takového systému.

•

Modelovací jazyk zahrnující všechny důležité koncepty v podniku včetně vztahů mezi nimi, schopný popsat různě statické i dynamické struktury a zároveň pochopitelný pro zainteresované osoby na projektu.

•

Schopnost organizovat vizuální diagramy do jednotlivých pohledů na podnik, přičemž každý pohled popisuje konkrétní aspekt podniku.

•

Dostatečné zkušenosti s navrhováním, pokud možno použít již osvědčené a dobře definované modelovací vzory.

•

Vývojový proces zajišťující kvalitu a přesnost vytvořených modelů [Rábová, 2008].

3.7 CASE nástroje Jazyk UML byl navržen jako most spojující nejefektivnější postupy modelovacích technik a softwarového inženýrství a je proto navržen tak, aby bylo možné jej implementovat v nástrojích pro softwarové inženýrství. Tyto nástroje se nazývají CASE (z anglického Computer-aided software engineering), tj. počítačem podporované softwarové inženýrství, a nabízejí příjemné vývojové prostředí pro podporu vývoje a údržby software. Diagramy modelovacího jazyka UML jsou dobře srozumitelné pro lidi a také jsou snadno interpretovatelné pomocí nástrojů CASE [Arlow, Neustadt, 2007]. Plnohodnotné CASE nástroje umožňují propojení jednotlivých technik UML a týmovou práci pomocí sdílení modelů mezi členy týmu. Pro návrh informačních systémů jsou CASE nástroje ideálním prostředkem [Kanisová, Müller, 2006].

17

Jedním z těchto CASE nástrojů je produkt společnosti Sparx Systems Enterprise Architect. Enterprise Architect je nástroj pro modelování pomocí jazyka UML, který podporuje následující modely: •

Business Process Model,

•

Class model,

•

Use Case model,

•

Activity model,

•

Sequence model

•

a Component model. Nástroj umožňuje tvorbu dokumentace a její export ve formátech RTF a XMI.

Vyšší verze produktu umožňují přímý import struktury dat do databází MySQL nebo na SQL Servery. Dále je podporována práce v týmu a metodická podpora technologie EFEM (Extrémně Efektivního Modelování), napomáhající efektivní tvorbě software s tímto nástrojem [HTK Pro s.r.o., webová prezentace].

3.8 Internetový katalog Internetový katalog je obecně libovolná webová stránka obsahující seznam odkazů na jiné webové stránky uspořádaný do stromové struktury, v případě katalogu firem seřazených obvykle dle oborů činnosti či navíc dle geografických preferencí. Tyto katalogy bývají obvykle ručně spravovány a poskytují tak z pohledu zákazníka vyhledávajícího vhodného obchodního partnera kvalitnější informace než fulltextové vyhledavače. Vhodné setřídění do kategorií a kontrola relevantnosti obsažených odkazů jsou velmi důležitými vlastnostmi katalogů v porovnání s vyhledavači, které fungují automatizovaně [Wikipedia, 2009]. Zařazení do takového katalogu bývá obvykle zdarma, pouze nadstandardní služby jsou zpoplatněny. Takovými službami jsou obvykle zvýhodněné umístění v rámci výpisu konkrétní kategorie, zvýrazněná prezentace či případně další doplňkové funkce jako možnost umístit do katalogu ceníky, podrobnosti o provozovnách nebo kontaktní informace na jednotlivé pracovníky. Umístění v katalogu přináší užitek jednak přímým zprostředkováním informace o subjektu

18

uživatelům katalogu, tak rovněž při tzv. SEO optimalizaci, kdy je prezentovaný subjekt sekundárně lépe zobrazován (s vyšší relevancí) také na vyhledavačích třetích stran. Jako příklady těchto katalogů můžeme uvést například Firmy.cz společnosti Seznam.cz, a. s. (dříve pouze jako subdoména katalog.seznam.cz) nebo katalog Najisto.cz vzniklý spojením katalogů firem Centrum.cz (Centrum Holdings s. r. o.) a Atlas.cz (dříve Atlas CZ, a. s., nyní Centrum Holdings s. r. o.).

3.9 SEO SEO, neboli optimalizace pro vyhledavače (Search engine optimization), je proces směřující k vylepšení dohledatelnosti (kvality umístění v rámci vyhledávání) konkrétní webové stránky na internetových vyhledavačích jako je Google, Yahoo, Seznam či Centrum. Možnosti této optimalizace jsou již všeobecně poměrně dobře známy a na našem trhu působí mnoho společností, které se SEO zabývají. Jelikož internetové vyhledavače pracují z velké části automatizovaně, je třeba jednotlivé stránky nějak odlišit a uspořádat dle jejich významu. K tomu vyhledavače využívají tzv. rating, tj. ohodnocení jednotlivých webových stránek – například Google PageRank nebo S-Rank společnosti Seznam.cz, a. s. Velké množství dotazů na vyhledavače a požadavky na relevantní výsledky vyhledávání vyžadují záznamy jak indexovat, tak tyto indexy vystavět tak, aby na prvních místech byly stránky s co nejvyšší relevancí. Pro určení této relevance (ohodnocení) existuje mnoho speciálních algoritmů založených na rozpoznání různých znaků (vlastností) webových stránek a nutné analýzy jejich obsahu.

Toto ohodnocení se zaměřuje zejména na tyto

vlastnosti: •

váha slov (zohledňuje umístění slova na stránce a počet jeho výskytů),

•

atraktivita stránky (stránka má tím vyšší ohodnocení, čím více jiných stránek na ni odkazuje),

•

serióznost webu (seznamy kvalitních prověřených webů zvýhodňují obsažené stránky),

•

technická kvalita (vyšší váha pro weby splňující webové standardy),

19

•

sponzorované

odkazy

(zvýhodnění

stránky

po

zaplacení

poplatku

provozovateli vyhledavače – jelikož tato praxe narušuje objektivitu prezentovaných výsledků vyhledávání, je běžné, že seriózní vyhledavače takovéto výsledky viditelně odliší od ostatních) [Wikipedia, 2009]. Skutečnosti, že lidé nejvíce navštěvují odkazy uvedené mezi výsledky vyhledávání na prvních místech, využívá právě SEO a to jej řadí mezi významné Internetové marketingové strategie. Optimalizace webové stránky vyžaduje v první řadě úpravu obsahu konkrétní stránky a jejího HTML kódu pro zvýšení relevance ke specifickým (často vyhledávaným) slovům a také odstraňující překážky pro automatické vyhledavače (tzv. bot či crawler), jakými jsou typicky obrázky obsahující textové informace (většina vyhledavačů nemá dosud nasazenu technologii rozpoznávání znaků OCR z obrazových dat) a podobné nestandardní prvky. Vlastnosti automatického indexování stránek zneužívá tzv. neetické SEO (black hat SEO, Spamdexing), pokoušející se zvýhodnit webové stránky i za cenu ohrožení relevance výsledků vyhledávání. Internetové vyhledavače takovouto činnost v případě odhalení penalizují a rank takovým stránkám naopak snižují. Etické metody SEO se pokoušejí vylepšit svoje umístění v rámci vyhledávání především zkvalitněním vlastního obsahu těchto stránek a tím i zvýšením užitné hodnoty pro uživatele, kteří stránku snáze najdou na vyhledavačích a také se v ní následně pohodlněji orientují. Mezi tyto metody zařazujeme [Wikipedia, 2009]: •

kvalitní a unikátní obsah (pravidelná aktualizace, původní texty, …),

•

používání HTML a XHTML značek dle specifikace (dodržování značek pro nadpisy různých úrovní, značky pro zdůraznění slov a další),

•

používání nadpisů, titulků a popisů (správné užívání značek, užití alternativních popisků obrázků, tabulek a další),

•

používání popisů a klíčových slov (klíčová slova se však musí na dané stránce také vyskytovat, pokud tomu tak není, může být stránka z pohledu vyhledavače penalizována),

20

•

krátké a neměnné URL (klíčové slovo v URL je z hlediska vyhledavačů významné, také je z důvodů zpětných odkazů důležité neměnit URL na konkrétní stránky),

•

zpětné odkazy (hodnocení stránky se zvyšuje, vede-li na ni několik dalších odkazů z jiných stránek),

•

používání souboru robots.txt (soubor umístěný v kořenovém adresáři webu, umožňuje povolit, úplně zakázat či ovlivňovat chování vyhledávacího bota na dané webové stránce).

21

4 Východiska základního metamodelu Již zmíněný metamodel využívaný v metodice BMA jako komplexní šablona pro modelování využívá podnikových konceptů zdroj, cíl, proces a pravidlo. Abychom mohli tuto základní šablonu správně pochopit a popsat, je třeba představit jednotlivé koncepty, ze kterých vychází.

4.1 Podnikové zdroje Podnikové zdroje jsou entity, které hrají při provozu podniku důležitou roli – jde o zdroje (objekty), které jsou použity v podniku či se nějak podílí na popisovaných procesech. Tedy jsou například spotřebovávány, vyráběny, transformovány nebo používány v podnikových procesech (lidé, materiál, produkty, informace a služby, energie a další). V objektově orientovaném modelování se obvykle tyto objekty objevují jako třídy, zatímco v podnikovém modelování vystupují jako zdroje. Tyto zdroje mohou být dle formy a vlastností děleny na: •

fyzické – mají materiální podstatu, je možné je vidět a dotknout se jich, například různé materiály, výrobky či jejich části,

•

abstraktní – myšlenky a koncepty,

•

informační – obsahují informace o jiných zdrojích. Zdroje jsou v UML modelovány jako třídy s danými atributy a instancemi,

jednotlivé typy zdrojů jsou odlišeny pomocí stereotypů. Instance reprezentují objekty a mezi zdroji a jejich typy existují vazby popsané pravidly. V každém podniku je třeba definovat jednotlivé struktury a vztahy mezi zdroji, produkt vzniká souhrnem různých částí a za asistence prvků systému (zdroj produkt sestává z jiných zdrojů), jednotlivé osoby v podniku jsou tříděny do oddělení (zdroj lidé je součástí zdroje organizační jednotka) a existují vztahy mezi zákazníkem a abstraktními objekty dotýkající se podniku (například dodavatelé a objednávky) [Rábová, 2008]. Eriksson definuje podnikové zdroje jako „entitu, která může hrát roli při realizaci určité třídy v systému, je to koncept použitý v podniku a představuje cokoliv, co vybereme pro zhodnocení podniku jako celku“ [Rábová, 2008].

22

Dále Eriksson uvádí Vernadatovu definici podnikového zdroje jako „entity, která hraje roli v realizaci nějaké třídy činností.“ Eriksson uvádí také mírně odlišné rozdělení zdrojů podniku dle jejich vlastností na čtyři následující skupiny. Fyzické – entita s materiální podstatou zabírající určitý objem v prostoru. Je to něco, čeho se můžeme dotknout a co může být viděno. Komodity, materiály v surovém stavu, součásti nebo produkty použité v podnikových procesech jsou příkladem fyzických zdrojů. Fyzický objekt je často vytvořen z ostatních fyzických objektů. Abstraktní – do této kategorie náleží např. nápad, myšlenka či koncept, často jako součásti jiných objektů, zahrnuje věci a koncepty bez fyzické podstaty mající vztah k podniku. Kontrakty, role, účty a energie jsou příklady abstraktních zdrojů. Informace a informační objekty – představují koncepty, předměty a informační objekty, tj. předměty uchovávající informace o ostatních zdrojích a zastupující úlohu nějakého zdroje. Je důležité odlišovat tyto informační objekty od konceptů a předmětů. Informační objekt uchovává skutečnosti a vědomosti o ostatních objektech v systému, jako například informace o bankovních účtech nebo smlouvách. To znamená, že v informačním systému tyto objekty uchovávají ínformace zastupující bankovní účty či smlouvy, nicméně například fyzické výpisy z účtu nebo skutečné podepsané smlouvy jsou jinými objekty. Lidé – osoby vystupující v podnikových procesech. Lidé jsou neradi označováni za fyzický objekt, a proto byli vyňati do speciální skupiny a jsou tak jedním ze zdrojů zmíněného základního metamodelu. Lidé také bývají často méně předvídatelní než stroje a zařízení (a to jak pozitivně, tak negativně) a proto by měli být v jednotlivých procesech zvýrazněni. Na lidské jedince lze pohlížet jako na zvláštní případ fyzických zdrojů a na následujícím diagramu jsou uvedeni jako podtyp fyzických zdrojů podniku.

23

Obr. 2: Metamodel zobrazující hierarchii různých typů podnikových zdrojů Tyto čtyři typy podnikových zdrojů jsou také stereotypy užité pro rozdělení tříd zdrojů. Stejně tak bychom mohli navrhnout další stereotypy, jako například Stroj pro strojní zařízení nebo Dokument pro podnikové dokumenty (oba jako podtypy k typu Fyzické zdroje v metamodelu). Je vhodné udržet nízký počet užitých typů, takže takovéto stereotypy nejsou používány, nicméně v ojedinělých oprávněných případech mohou být takovéto subtypy být použity [Eriksson, Penker, 2000].

4.2 Podnikové cíle Podnikový cíl popisuje požadovaný stav jednoho nebo více zdrojů, cíl, kterého chceme dosáhnout daným procesem. Cíle jsou připojeny k jednotlivým procesům napříč celým podnikovým modelem a jsou důvodem vykonávání aktivit vedoucích k těmto cílům. Cíl by měl být měřitelný s ohledem na hodnocení jednotlivých postupů a to v nějakých kvantifikovatelných jednotkách jako zisk, obem, čas či kvalita, nebo v kvalitativním vyjádření jako například „podnik se umístí mezi vyznamenanými podniky v kraji za příští rok“ a podobně. Vytyčení cílů a specifikace jejich měřitelnosti přispívají ke schopnosti rozpoznat, zda daný cíl byl splněn či nikoliv. Cílů by mělo být dosahováno společným užitím podnikových procesů,

24

zdrojů a pravidel. Zatímco vize jsou z pohledu podnikových cílů poměrně obecně určeny, čím hlouběji se v rámci podnikových cílů dostáváme, tím specifičtější a měřitelnější cíle jsou. Čím je cíl přesněji specifikován a přesněji měřitelný, tím snadněji můžeme později určit, zda byl tento cíl splněn či nikoliv. Cíle se mohou rozpadat na dílčí cíle, přičemž splnění cíle hlavního vyžaduje splnění cílů dílčích – toto dělení cílů na dílčí subcíle se nazývá modelování cílů. Dílčí cíle mohou také zastupovat nebo kompenzovat cíle jiné, které se nepodařilo dosáhnout či zcela uspokojivě naplnit. Problematika podnikových cílů úzce souvisí s problémy (obtížemi), které jsou překážkami v plnění cílů. V takových případech je možné modelovat spolu s cílem také tyto problémy, pokud to přispěje ke zjednodušení vyjádření těchto cílů. Definice cílů vyvolává otázky, které problémy bude třeba k naplnění těchto cílů vyřešit. Naopak při definici problémů lze dosáhnout odpovědi na otázku, které cíle budou dosaženy vyřešením těchto problémů. Definováním těchto problémů mohou být identifikovány dílčí cíle, které je pomohou vyřešit a mohou být užity v podnikových procesech. Vyjádření cílů a problémů pomocí jazyka UML není snadné a Eriksson uvádí řešení v podobě reprezentace cílů jako objektů a jejich užití v diagramu k vyjádření závislostí mezi cíli a dílčími cíli a definuje dvě kategorie cílů – kvalitativní a kvantitativní. Kvantitativní cíle jsou definovány cílovou hodnotou konkrétní měřitelné jednotky, zatímco cíle kvalitativní jsou definovány vágněji, bez nějaké měřitelné jednotky a pomocí slovních hodnocení. Vyhodnocení dosažení cíle je vždy na procesu a v případě kvalitativních cílů obvykle vyžadují lidské hodnocení splnění cíle [Eriksson, Penker, 2000]. Vhodným prostředkem pro určení plnění cílů je informační systém podniku, jelikož obvykle obsahuje veškeré potřebné informace o výsledcích podniku. V případě kvalitativního cíle se proces obvykle musí spolehnout na lidskou obsluhu – tento lidský faktor vede k použití fuzzy množin při popisu takového cíle. Díky podnikovým cílům je možné nejen hodnotit jejich dosažení, ale také určovat

chování

podniku

v budoucím

období.

Existence

cílů

vede

k transparentnějšímu řízení podniku a celkově toto řízení zkvalitňuje. V návaznosti

25

na cíle jsou definovány úkoly zajišťující dosažení daných úkolů, ukazatele měřící efekt a další akce na jejich podporu. Správně definovaná soustava cílů je pro řízení podniku zásadní – je nutné správně strukturovat hlavní cíl podniku do cílů dílčích a to dle funkčních oblastí a podle procesů. Následující obrázek demonstruje jednoduchou hierarchii podnikových cílů pomocí diagramu tříd v UML [Rábová, 2008]:

Obr. 3: Struktura podnikových cílů

4.3 Podniková pravidla Podnikový model obsahuje podniková pravidla definující omezení podmínky a politiky pro jednotlivé vykonávané procesy, které jsou těmito pravidly ovlivňovány a mohou jimi být omezeny a působit na dosažení konkrétního cíle. Eriksson definuje pravidlo jako „sadu ustanovení, která mohou řídit nebo ovlivnit jak chod podnikového procesu, tak strukturu zdrojů v podniku. Stanovení specifikuje podmínku, která musí být splněna, nebo podmínku, která řídí časovou sekvenci aktivit. Pravidlo může vyjadřovat podnikový cíl, specifikovat způsob, jak by měl být vykonáván proces, detailizuje podmínky vzahu nebo omezení chování zdroje“ [Rábová, 2008]. Pravidla řídí podnik a můžeme definovat jak externí pravidla popisující požadavky z vnějšku systému (nařízení a zákony, omezení vyplývající ze vztahů s jinými podniky) tak pravidla interní popisující požadavky plynoucí z požadavků

26

uvnitř podniku (plnění cílů a strategických plánů podniku). Eriksson uvádí tři typy podnikových pravidel: Odvození – pravidlo popisující jak je znalost v nějaké formě transformována na znalost jinou (tedy z nějaké informace je vyvozena informace další). Odvození může být jak matematické (početní), vyjádřené nějakým vzorcem, případně může jít o implikaci znamenající, že pokud je nějaká událost pravdivá, musí být pravdivá (resp. nepravdivá) i jiná událost). Omezení – pravidlo omezující možnou strukturu nebo chování objektů nebo procesů (např. vazby mezi objekty). Omezení napomáhají udržet integritu objektů a jejich změn a předchozí podmínky (jsou ověřovány před provedením operace) a následné podmínky (jsou ověřovány po provedení operace). Existence – pravidla definující podmínky, kdy může daný objekt vzniknout, existovat a kdy je jeho existence ukončena. Pravidla mohou být formálně zapsána pomocí definovaného jazyka srozumitelného počítači nebo pomocí lidského jazyka. Někdy je vhodné použít obou forem zápisu, užitím formálního zápisu pro informační systém a neformálním zápisem vhodným pro uživatele. Společně s diagramy poskytují pravidla veškeré informace o podniku, mohou se vyskytovat ve všech pohledech na systém, nicméně je třeba dbát na to, aby jednotlivá pravidla neodporovala pravidlům jiným. Jednotlivé diagramy UML mají vestavěnu podporu pro zápis pravidel, například diagram tříd má pravidla obsažena v definici vztahů mezi třídami (multiplicity a povinnosti) [Eriksson, Penker, 2000]. Pravidla představující podnikové znalosti ovládající strukturu zvnějšku systému i uvnitř něj je možné rozdělit na tyto tři skupiny: •

strukturální pravidla týkající se organizačních struktur v podniku,

•

behaviorální pravidla týkající se chování podniku a

•

funkční pravidla definující způsob spouštění a posloupnosti jednotlivých aktivit v podnikových procesech. V informačním systému jsou pak tato pravidla definována, kontrolována

a vyhodnocována. Pří modelování podnikových pravidel postupujeme obvykle od neformální

specifikace, poté

formalizací

27

této

specifikace

vzníká pravidlo

v informačním systému. Formální zápis má podstatné výhody a pro definici v informačním systému je velmi důležitý a to zejména z těchto důvodů: •

formální zápis je vhodnější pro převod do strojového jazyka,

•

omezuje se nebezpečí špatného pochopení pravidla,

•

při navrhování softwarových aplikací je nutná jednoznačnost. UML pro popis pravidel nabízí jak grafickou notaci k prvkům znázorněným

v modelu tak i následující prostředky: •

multiplicita uvedená mezi jednotlivými třídami v diagramu tříd udáva, kolik objektů jedné třídy může nebo musí být asociováno s objekty třídy druhé.

•

Stavový diagram definuje podmínku přechodů mezi jednotlivými stavy (kdy dojde k přechodu ze stavu S1 do stavu S2).

•

Chování objektu v konkrétním stavu určují pravidla chování objektu popsaná u tohoto stavu.

•

Atributy v diagramu tříd mohou být určeny vzorcem pro výpočet z jiných atributů dané třídy nebo atributů jiných tříd

•

Diagram aktivit definuje podmínky pro spuštění jednotlivých procesů nebo posloupnost těchto aktivit.

•

Možné omezení asociací libovolným pravidlem v diagramu tříd. Ke každému prvku v UML diagramu lze přidat definici pravidla pomocí

poznámky se stereotypem [Rábová, 2008].

4.4 Podnikové procesy Podnikový proces je aktivní částí podniku popisující funkce podniku a zahrnující použité, transformované či vytvořené zdroje. Jde o abstrakci zobrazující vztah mezi zdroji a transformací těchto zdrojů v podniku. Zaměřuje se více na to, jak je činnost vykonávána spíše než na popis produktů nebo služeb, které jsou výsledkem takovéto činnosti. Formální definici podnikového procesu specifikují Hammer a Champy jako: „podnikový proces je souhrnem aktivit užívajících jeden nebo více vstupních zdrojů

28

a vytvářejících výstup (zdroj) užitečný pro zákazníka. Podnikový proces má cíl a je ovlivněn událostmi vnějšího světa nebo ostatními procesy.“ Dále Eriksson uvádí upřesňující definici, kdy je podnikový proces považován za: „strukturovanou množinu aktivit navržených k vytvoření specifického výstupu pro konkrétního zákazníka na trhu. Klade silný důraz na to, jak je práce v podniku vykonávána v kontrastu k zaměření produktu jako takového. Proces tak lze definovat jako specifické uspořádání činností napříč časem i místem, s definovaným začátkem a koncem a jasně identifikovanými vstupy a výstupy“ [Davenport, 1993]. Porter uvádí jako podstatu každého podniku proces užívající nějaký vstupní zdroj (materiál) a přidáním nějaké přidané hodnoty směřující k vytvoření požadovaného výstupu. Proces je posloupností menších kroků přidávajících hodnotu (tzv. hodnotový řetěz), hodnotu produktu ovlivňuje skutečnost, komu je výstup určen – zda bude využit v dalším podnikovém procesu nebo bude směněn za peníze na trhu. Porter tak považuje každý podnik za souhrn podnikových procesů, každý vytvářející nějakou přidanou hodnotu [Eriksson, 2000]. Vlastnosti podnikového procesu tedy můžeme shrnout následovně: •

podnikový proces má cíl,

•

podnikový proces má konkrétní vstup (vstupy),

•

podnikový proces má konkrétní výstup (výstupy),

•

podnikový proces využívá zdrojů podniku,

•

sestává z mnoha aktivit vykonávaných v daném pořadí, zavisejících na podmínkách a událostech, které se dějí v průběhu života procesu,

•

aktivity vykonávané v rámci procesu jsou označovány jako subprocesy (dílčí procesy),

•

ovlivňují více jak jednu organizační jednotku podniku a v kontextu tradičního chápání podniku je spíše horizontální než vertikální,

•

vytváří určité hodnoty pro zákazníka, ten může být jak uvnitř podniku (meziprodukt) tak i vně podniku.

29

Podnikový proces má jasně definovaný cíl, soubor zdrojových objektů (vstupy a výstupy) a podstatné objekty jiné než vstup a výstup. Vstupní objekty jsou zdroje, které jsou v průběhu procesu spotřebovávány nebo transformovány (například materiál). Vstupní objekty mohou být v průběhu procesu vylepšeny (proces jim dodal přidanou hodnotu), takže hodnota výstupu je vyšší než hodnota vstupu. Výstupní objekty přestavují dosažení definovaných cílů a jsou hlavním výsledkem provedeného procesu (například hotový výrobek), výstup ale může být také zdrojem. Výstupem může být úplně nový objekt vytvořený v průběhu výrobního procesu nebo může jít o transformovaný vstupní objekt. Transformace prováděné procesem mohou být fyzické, logické, transkační nebo informační. Pro reprezentaci podnikového procesu Eriksson užívá modelu tříd v UML se symbolem procesu uvedeném na následujícím obrázku, který je standardním vyjádřením procesu v mnoha modelovacích technikách a nekryje se s žádným jiným symbolem jazyka UML [Eriksson, 2000].

Obr. 4: Symbolika podnikového procesu podle Erikssona Ke každému procesu je možné připojit označkované hodnoty poskytující doplňující informace o daném procesu. Tyto označkované struktury nejsou v diagramu nijak zobrazovány a neovlivňují tak jeho přehlednost, ale jsou dostupné jak v modelovacím softwaru, tak i ve vygenerované dokumentaci a jsou využívány

30

dále v procesu implementace projektu. Eriksson hovoří o těchto rozšířeních [Eriksson, 2000]: •

cíl – textové vyjádření cílů jednotlivých procesů pro případ, kdy není k procesu v diagramu připojen cíl,

•

účel – neformální popis účelu, kterému proces slouží (např. co proces dělá a v případě nového procesu předpokládané výsledky a dopady),

•

dokumentace – neformální vyjádření popisu činností procesu (např. soupis vykonávaných aktivit a použitých zdrojů),

•

vlastník – definice vlastníka procesu, osoby v podniku mající odpovědnost za daný proces, realizující a plánující změny,

•

aktoři procesu – definuje aktory zapojené do konkrétního procesu,

•

priorita – popisuje prioritu daného procesu, například zda se jedná o hlavní proces, podpůrný či administrativní proces a další,

•

rizika – popisuje rizika popisovaného procesu, například co lze očekávat za problémy při implementaci těchto procesu nebo při jejich vykonávání,

•

příležitosti – popisují potenciální úpravy procesu, možná vylepšení a případné alternativní použití procesů pro jiné cíle,

•

čas – číselná hodnota udávájící přibližný čas potřebný pro vykonání procesu,

•

cena – numerická hodnota udávající přibližnou cenu (náklady) na proces. Již jsem uvedl, že podnikový proces má definovaný cíl, vstup, výstup,

je strukturován na akce a je spojen s jednou nebo více organizačními jednotkami podniku. Proces má účel, vlastníka, aktora, priority, rizika, příležitosti, čas a cenu a je popsán dokumentací. Jde o aktivní (funkční) část podniku tvořící přidanou hodnotu a plnící podnikové cíle. Podnikový proces můžeme znázornit prakticky libovolnou částí UML jazyka, nejčastějí se však používají diagramy aktivit. Proces může být napojen na objekty jako cíl, účel, dokumentaci, vlastníka, aktory, priority, rizika, příležitosti, čas a náklady (cenu) [Rábová, 2008]. Následující obrázek

31

dokumentuje základní pohled na proces v podniku se znázorněnou strukturou procesu včetně aktivit a subprocesu.

Obr. 5: Procesní diagram se strukturou a základními zdroji Procesní diagramy slouží pro vysoce abstraktní popis obvykle na počátku procesní analýzy. Každý proces v podniku má svůj procesní diagram, který je obvykle dále detailizován pomocí ostatních prostředků vizualizace (tj. v kontextu procesního modelování dle Erikssona pomocí diagramů UML). Na dalším obrázku je detailně znázorněno rozložení podpůrných zdrojů [Rábová, 2008]:

Obr. 6: Základní diagram aktivit se strukturou zdrojů

32

5 Metamodel podnikových konceptů Jak již bylo uvedeno v předchozím textu, metodika BMA využívá tzv. metamodelu – komplexní šablony pro modelování vzniklé spojením podnikových konceptů zdroj, cíl, proces a pravidlo. Tato šablona je dostatečně komplexní a obecná pro různé typy podniků v mnoha odvětvích průmyslu a představuje tak model podnikových konceptů a jejich interakci (základní metamodel). Tento základní metamodel je uveden na následujícím obrázku:

Obr. 7: Základní šablona (metamodel) podnikové architektury Tento model tříd využívá jazyka UML, popisuje vztahy mezi těmito třídami a to včetně multiplicity a připojených poznámek se stereotypem s definicemi jednotlivých konceptů. Tato velice jednoduchá struktura je již v tomto vysoce abstraktním pojetí zcela komplexní a umožňuje snadné pochopení, správu a řízení jednotlivých pohledů na podnik [Rábová, 2008].

33

6 Metodika Při určování použité metodiky je třeba brát v úvahu řešenou problematiku a vybrat jednotlivé modely s ohledem na jejich praktický přínos. Pro analýzu současného stavu jsem se rozhodl využít metodiky Business Process Modeling Notation (BPMN), umožňující přehledným způsobem znázornit aktuální procesy ve firmě. Návrh pojetí procesů modeluji jednak pomocí BPMN (základní diagramy), tak i s použitím UML notace (Use-Case, Class model a další). Pro tvorbu jednotlivých modelů jsem zvolil nástroj společnosti Sparx Systems Enterprise Architect, který lze ve zkušební verzi volně stáhnout ze stránek výrobce. Při práci jsem se snažil shrnout základní teoretické předpoklady, využít dostatečné množství literárních i elektronických zdrojů a s jejich pomocí navrhnout základní model systému internetového katalogu pomocí BPMN a dalších UML diagramů, ke kterému jsem následně detailněji zpracoval modely alternativních řešení problému. Tyto modely jsem následně analyzoval, zhodnotil jejich přínosy a nevýhody a také jsem se pokusil nastínit ekonomické náklady pro tato řešení.

34

7 Požadavky na systém Systém slouží k prezentaci informací o vložených společnostech na veřejném portálu dle daných kategorií a dalších pravidel pro zobrazení. Vstup dat zajišťuje webové rozhraní pro registraci či editaci údajů přímo uživatelem a dále také přímo import do databáze (možnost hromadného vložení mnoha záznamů najednou). Správu dat zajišťuje uživatelské rozhraní pro administrátory systému, kde je možné přistupovat k jednotlivým položkám databáze dle oprávnění konkrétního uživatele a také nastavovat příslušná pravidla pro zobrazení záznamu (zařazení do kategorií, prioritní zobrazování a další možnosti). Data jsou prezentována nepřihlášeným uživatelům na webových stránkách katalogu, kde jsou záznamy zobrazeny v relevantních sekcích a tříděny dle geografických parametrů. Dle relevance k vyhledávaným klíčovým slovům jsou záznamy zobrazovány jako výsledky vyhledávání. Zde je možné ke zobrazení výsledků přistupovat dvěma způsoby. První možnost počítá s tím, že záznamy jsou si rovnocenné a žádný záznam není upřednostňován před jiným. Výsledky vyhledávání

odpovídají

pouze

relevanci

k vyhledávaným

klíčovým slovům

a geografickým preferencím. Druhá možnost uvažuje variantu možnosti zvýhodnění některých záznamů vůči ostatním nezvýhodněným záznamům. Pořadí a způsob, jak jsou

záznamy

zobrazeny,

závisí

k vyhledávaným

řetězcům,

ale

v takovém

také

na

případě

nastavení

nejen

na

relevanci

konkrétního

záznamu

administrátorem. Takovéto zvýhodnění je standardně zpoplatněno a je významným zdrojem příjmů společnosti provozující katalog. Nedílnou součástí systému s možností upřednostnění záznamu (garance zobrazení záznamu ve výsledcích vyhledávání) je také objednávkový / fakturační modul, ve kterém lze zadat objednávku určité formy prezentace a v závislosti na ní případně vystavit fakturu, a také modul kontroly plateb, který je napojen na bankovní instituci, starající se o vystavování daňových dokladů a upomínání faktur po splatnosti. Jakým způsobem bude výsledný systém koncipován a v konečné fázi i implementován, záleží na rozhodnutí, jaké funkcionality do systému vložit. Systém je možné pojmout jako katalog podnikatelských subjektů s bezplatnými záznamy,

35

které jsou si zcela rovnocenné a zobrazují se pouze dle relevance při vyhledávání, vytvářející zisk pouze z reklamy třetích stran umístěné na webových stránkách katalogu. Takové řešení je vysoce závislé na počtu uživatelů (návštěvnosti) a je nutné investovat nemalé prostředky do snah o zvýšení této návštevnosti. Další možností je výše zmíněná možnost zpoplatnění určitých služeb katalogu, jako například garance umístění konkrétních záznamů ve výsledcích vyhledávání na lepších pozicích než u ostatních záznamů bez této garance.

36

8 Základní model Daný systém má svoje specifické požadavky, které jsou v základní funkčnosti identické pro všechny varianty řešení. Systém musí umožnit vstup dat do systému (uživatelem nebo při hromadném importu), zpracování těchto dat (především kontrola smysluplnosti vloženého záznamu a ověření relevantnosti zařazení takového záznamu do konkrétní kategorie katalogu) a následnou prezentaci těchto dat systémem (vyhledávání v rámci kategorií či dle relevance ke hledanému řetězci). Tento výchozí model je stručně popsán pomocí následujícího diagramu BPM a základního use case modelu.

8.1 BPM základního modelu Základní model splňující ty požadavky na systém, které jsou stejné pro každou variantu řešení a obsahují výše uvedené funkce, lze reprezentovat následujícím diagramem:

Obr. 8: Business process model základních požadavků na systém

37

Model popisuje vznik záznamu uživatelem, který při registraci nové společnosti obdrží vygenerovaný login a zároveň zadá svoje přihlašovací heslo, čímž je považován za přihlášeného. Proces Vytvoření záznamu používá jako vstup Registrační formulář, obsahující potřebné údaje. Cílem tohoto procesu je vznik záznamu, který je dále zpracován. Proces Zpracování záznamu provádí zaměstnanec, uplatňuje pravidla platná pro daný záznam (smysluplnost zveřejňovaných informací a jejich relevatní zařazení do daných kategorií katalogu), čímž vzniká aktuální záznam, který je možné dále zveřejnit. Proces Vyhledávání a prezentace záznamů načítá data z vyhledávacího formuláře a vyhledává k nim relevantní záznamy v katalogu, které následně prezentuje. Pořadí prezentovaných záznamů závisí výhradně na relevanci s vyhledávaným řetězcem a geografickým umístěním záznamu. Výstupem tohoto procesu je webová stránka s výsledky vyhledávání (resp. výpisem detailních informací o daném záznamu) obsahující reklamní prvky, jejichž prostřednictvím katalog realizuje finanční příjmy.

8.2 Základní use case model Pro popis základního systému je vhodné použít ještě diagram Use case popisující zapojení jednotlivých aktorů do konkrétních procesů. Požadavky na Základní model splňuje následující use case diagram:

38

Obr. 9: Use case model základních požadavků na systém Aktor Přihlášený uživatel vytváří a případně edituje záznam svojí společnosti. Aktor Zaměstnanec tyto záznamy dále zpracovává (aktualizuje) a kontroluje. Z obrázku je vidět, že případ užití Vyhledání záznamu (jednoznačné, například pomocí IČ) je zároveň použit případem užití Editace záznamu, Kontrola záznamu a Zpracování záznamu. Došlo tedy k opakovanému použití vytknuté funkčnosti. Nepřihlášený uživatel záznamy pouze vyhledává. Relace <> objevující se v případě podobné či stejné části scénáře, která se opakuje ve více případech užití. Jedná se o vyčlenění společného chování ze scénářů základních případů užití. Tato relace vyčleňuje chování ze dvou či více případů užití do samostatného případu užití, základní případ užití není soběstačný [Kanisová, Müller, 2006].

39

8.3 Ekonomický přístup Tento model znázorňuje pouze základní požadavky na funkčnost systému, které budou rozvinuty v následujících kapitolách. Základní model je možné posuzovat jak z hlediska nákladů, tak možností realizace zisku. Náklady sestávají z nákladů na realizaci (vývoj) systému katalogu a z nákladů na provoz. Realizace závisí na zvoleném řešení, zde předpokládáme pouze základní funkcionalitu spočívající v možnosti vložení a editace záznamů, přihlášení s danými právy a vyhledávání v rámci katalogu. Takovýto systém je možné vyvinout s poměrně malými náklady (řádově desítky tisíc korun). Provozní náklady spočívají v určité fixní částce za provoz dedikovaného serveru (řádově tisíce korun měsíčně) a mzdě osob zajišťujících provoz katalogu. Tyto osoby vykonávají základní technickou údržbu systému (většina činností může být realizována automatizovaně a administrátor pouze dohlíží), kontrolu relevance vkládaných dat a technickou podporu uživatelům. Náklady na tyto pracovníky závisí na vytížení katalogu, v případě menšího rozsahu katalogu odhaduji měsíční náklady na řádově desítky tisíc korun a v případě velkého množství zpracovávaných dat na řádově statisíce korun měsíčně. Příjmy v této základní variantě lze získat pouze z reklamních prvků zobrazovaných na stránkách katalogu při vyhledávání. Příjmy z takovýchto reklam samozřejmě závisí na počtu zobrazených stránek (množství uživatelů katalogu) a lze je odhadovat na řádově tisíce až desetitisíce korun měsíčně, pouze při skutečně vysokém rozšíření katalogu mezi uživateli lze počítat s vyššími příjmy, tyto by však pravděpodobně byly převýšeny provozními náklady na administraci. Z výše uvedených skutečností vyplývá, že v základní variantě systému katalogu firem není příliš vysoká šance na návrat investovaných prostředků a tvorbu zisku. Pro dosažení výsledku přinášejícího zisk a umožnění dalšího růstu je vhodné přidat do systému dodatečné funkcionality. Varianty takového systému rozeberu v následujících kapitolách.

40

9 Alternativní model bez zpoplatněných služeb K výchozí funkčnosti systému lze doplnit velké množství dodatečných funkcí. Tato alternativa počítá s řešením, kdy jednotlivé záznamy jsou zobrazovány dle relevance vyhledávacích kritérií, nelze žádný upřednostnit a taková prezentace je pro klienty zdarma. Oproti základní funkčnosti je přidána možnost doplnění hodnocení k jednotlivým záznamům (firmám) jednotlivými uživateli systému (návštěvníci se zkušenostmi s daným podnikatelským subjektem). Hodnocení je možné zadat pomocí číselného vyjádření v definované stupnici (počet udělených hvězdiček) a ke každému záznamu je možné také připojit textový komentář. Společnosti také mají možnost ke svému záznamu vložit aktualizovaný ceník služeb a produktů ve formátu XML, ve kterých lze fulltextově vyhledávat a porovnávat tak jednotlivé záznamy také podle ceny konkrétního produktu či služby. Formát takového ceníku je vhodné jednoznačně definovat například pomocí DTD (Document Type Definition) jazyka pro popis XML struktury. Dále je přidána možnost vložit přímo na stránkách katalogu poptávku po nějakém produktu či službě v daném regionu nebo městě, kdy mohou firmy samy zaslat svoji nabídku konkrétnímu zákazníkovi. Uživatel také může u každého záznamu (firmy) vložit konkrétní dotaz či poptat nějaký produkt nebo službu (předběžně učinit objednávku) a tato informace je pak odeslána na zadanou e-mailovou adresu společnosti.

9.1 BPM Následující diagram popisuje systém jako celek s jednotlivými procesy diskutované varianty katalogu podnikatelských subjektů a doplňuje tak základní model o rozšiřující funkce. K základním funkcím předchozí varianty přidává doplňující funkcionality jako vložení hodnocení a komentářů k záznamům nebo vložení poptávky.

41

Obr. 10: Business Process Model rozšířené varianty bez zpoplatněných služeb Diagram znázorňuje vznik záznamu (proces Vytvoření záznamu) využívájící dat z registračního formuláře, jehož pomocí lze po zadání identifikačních údajů jednotlivé záznamy i měnit (záznam má svého vlastníka, který jej do systému vložil a disponuje přihlašovacím jménem a heslem). Proces Vyhledání poptávky umožňuje těmto vlastníkům záznamů vyhledat do systému vložené poptávky po produktech či službách (tyto vkládají nepřihlášení uživatelé procesem Vložení poptávky, kterým

42

se budu zabývat v následujích odstavcích). Poptávky se zobrazují vlastníkům relevantních záznamů, tj. pokud zákazník vložil poptávku například po spotřební elektronice, zobrazí se tato pouze u záznamů, které jsou zařazeny do sekcí souvisejících se spotřební elektronikou (byly označeny jako relevantní při tvorbě této poptávky). Vložením záznamu do systému vzniká neověřený záznam, který je nutné dále zpracovat (především jej zkontrolovat, zda obsahuje smysluplné údaje a je zařazen do odpovídajících sekcí), toto zpracování v diagramu představuje proces Zpracování záznamu, dodržující pravidla pro toto zpracování. Aktor Zaměstnanec vykonává proces Zpracování záznamu, jehož výstupem je Aktuální záznam, jehož vznik je zároveň i cílem tohoto procesu. Aktuální záznam je možné v systému zveřejnit v rámci vyhledávání i výpisu záznamů v jednotlivých sekcích katalogu. Nepřihlášený uživatel může v systému vyhledávat, vkládat hodnocení k záznamům a také je komentovat, vložit do systému poptávku po nějakém produktu či službě a případně využít kontaktního formuláře u jednotlivých záznamů pro přímé kontaktování zobrazované firmy (tyto zprávy jsou odesílány elektronickou poštou na adresu zadanou při registraci záznamu a také jsou dostupné v rámci administrace záznamu jeho vlastníkem). Proces Vyhledávání a prezentace záznamů využívá databázi aktuálních záznamů a zobrazuje uživateli výpis záznamů, které jsou relevantní k prohlíženým kategoriím nebo vyhledávaným klíčovým slovům. Výstupem tohoto procesu je WWW stránka s prezentací nalezených výsledků nebo přímo (po kliknutí uživatelem na konkrétní záznam záznam ve výsledcích vyhledávání) detaily záznamu. Proces Vložení hodnocení umožňuje nepřihlášenému uživateli ke každému záznamu vložit hodnocení v rámci bodové škály a připojit také textový komentář se zkušenostmi s daným podnikatelským subjektem. Proces Vložení poptávky umožnuje nepřihlášeným uživatelům vkládat do systému poptávku po nějakém produktu či službě, kromě kontaktních údajů a samotné poptávky označí uživatel také relevantní kategorie, ke kterým se poptávka vztahuje. Pomocí kontaktního formuláře zobrazeného při výpisu detailů jednotlivých záznamů může nepřihlášený uživatel procházející výsledky svého vyhledávání kontaktovat přímo společnost vlastnící tento záznam (zpráva je zaslána na e-mail

43

konkrétní firmy), toto představuje v diagramu proces Kontaktování firmy. Předchozí uvedené procesy Vložení hodnocení, Vložení poptávky a Kontaktování firmy mají za cíl zkvalitnění služeb katalogu a přispívají tak k vyšší návštěvnosti katalogu.

9.2 Use case Diagram užití představuje zapojení jednotlivých aktorů do konkrétních procesů a rozšiřuje základní model o další funkcionality při zachování základních aktorů.

Obr. 11: Use case diagram rozšířené varianty bez zpoplatněných služeb

44

Aktor Přihlášený uživatel vykonává případ užití Vytvoření záznamu (vložení dat do systému), Vyhledání poptávky (zobrazení aktuálních poptávek pro související kategorie) a use case Aktualizace záznamu (možnost změny vložených údajů a procházení vložených zpráv zákazníky). Aktor Zaměstnanec provádí Zpracování a kontrolu záznamu nutnou pro zařazení záznamu mezi platné záznamy k zobrazení v rámci vyhledávání v katalogu. Případ užití Zpracování a kontrola záznamu stejně jako u přihlášeného uživatele případ

užití

Aktualizace

záznamu

představují

klientské

případy

užití

k dodavatelskému use case Vyhledání záznamu. Pro znázornění této skutečnosti slouží relace <>, další příklad této relace je možné vidět v následující kapitole zabývající se variantou se zpoplatněnými službami. Poslední použitý aktor Nepřihlášený uživatel vyhledává v katalogu pomocí klíčových slov nebo procházením kategorií (use case Vyhledávání a prezentace záznamů), vkládá hodnocení a komentáře (případ užití Vložení hodnocení), kontaktuje jednotlivé společnosti (případ užití Kontaktování firmy) a vkládá poptávku (use case Vložení poptávky). Případy užití Vložení hodnocení a Kontaktování firmy opět představují klientské případy užití k dodavatelskému use case Vyhledání záznamu.

9.3 Ekonomický přístup Tento model je opět rozebrán jak z hlediska nákladů, tak možností realizace zisku. Oproti základní variantě představuje rozšíření o funkce, které poměrně výrazně ovlivní složitost vývoje aplikace a zvýší tak náklady vynaložené na realizaci projektu. Na druhou stranu také pravděpodobně pozitivně ovlivní počet uživatelů takového katalogu a přinesou dodatečné příjmy plynoucí z reklamních prvků umístěných na stránkách katalogu. Náklady opět tvoří náklady na vývoj systému a náklady na jeho provoz. Vývoj (realizace) tohoto systému opět zahrnuje základní funkcionalitu spočívající v možnosti vložení a editace záznamů, přihlášení s danými právy a vyhledávání v rámci katalogu. Je přidána možnost vkládání ceníků k daným záznamům a hodnocení spolu s komentáři k záznamům. Dále je třeba také implementovat funkcionalitu nutnou pro vkládání výše popisované poptávky po produktu či službě

45

a možnost zaslat dotaz nebo předběžně objednat nějaký produkt. Vývoj takového systému je již výrazně náročnější než základní verze a cena za něj by se pohybovala řádově výše, tj. kolem jednoho sta tisíc korun a výše dle přesných požadavků na systém. Provozní náklady opět spočívají v určité fixní částce za provoz dedikovaného serveru (řádově tisíce korun měsíčně) a mzdě osob zajišťujících provoz katalogu. Tyto osoby stejně jako v základním modelu vykonávají základní technickou údržbu systému (většina činností může být realizována automatizovaně a administrátor pouze dohlíží), kontrolu relevance vkládaných dat a technickou podporu uživatelům. Dále je nutné zajišťovat komunikaci se společnostmi (především s nimi spolupracovat na vkládání a aktualizaci ceníků) a administrovat data vložená uživateli (poptávky a dotazy). Náklady na tyto pracovníky opět závisí na vytížení katalogu, v případě menšího rozsahu katalogu odhaduji měsíční náklady na řádově desítky tisíc korun a v případě velkého množství zpracovávaných dat na řádově statisíce korun měsíčně. V rámci těchto řádů však budou náklady jistě podstatně vyšší, než v případě základní varianty uvedené v předchozí kapitole. Pro úspěšnou penetraci na trhu katalogů firem je důležité klást důraz také na reklamu. Kvalitní systém obsahující velké množství aktuálních dat je sice podmínkou úspěchu tohoto obchodního modelu, ale bez velkého množství uživatelů není možné zajistit návratnost vložených prostředků. Široká reklamní kampaň nutná pro získání nových uživatelů je velice nákladná a alespoň zpočátku provozu je třeba počítat s náklady řádově desítek až stovek tisíc korun měsíčně. Příjmy v této variantě lze opět získat pouze z reklamních prvků zobrazovaných na stránkách katalogu. Protože příjmy z těchto reklam samozřejmě závisí na počtu zobrazených stránek (množství uživatelů katalogu), lze díky výrazně atraktivnějším službám (kvalitnější informace pro uživatele) očekávat podstatně vyšší návštěvnost oproti základní diskutované funkcionalitě systému. Příjmy z reklamy v tomto případě lze odhadovat na desítky až stovky tisíc korun měsíčně. Tento model již má podstatně lepší předpoklady pro relativně vysoké příjmy, bohužel však také náklady na realizaci takového systému jsou podstatně výše než v základním modelu. Návratnost investice do takového systému již lze očekávat v případě optimistického přístupu v rozumném časovém horizontu, nicméně je nutné

46

vynaložit poměrně velké finanční prostředky pro vybudování dobré pozice na trhu (především vývoj a reklama). Také riziko neúspěchu je v tomto případě nezanedbatelné a hrozí tak poměrně vysoké finanční ztráty.

47

10 Alternativní model s garancí zobrazení Tento model počítá s možností upřednostnit některé záznamy vůči jiným dle priority jejich zobrazení. Záznamy jsou opět vyhledávány dle relevance k hledaným klíčovým slovům, avšak v rámci jejich prezentace již není pořadí ovlivněno jen touto relevancí, ale také stupněm zvýhodnění takového záznamu. Rovněž při výpisu záznamů z dané kategorie na stránkách katalogu firem jsou firmy zobrazovány dle tohoto zvýhodnění. Takové zvýhodnění oproti ostatním záznamům již logicky nemůže být zdarma a stupeň tohoto zvýhodnění je závislý na ceně, kterou společnost zaplatí za takovou prezentaci. Zvýhodněný záznam je oproti ostatním pro zákazníky atraktivní také díky dodatečným službám souvisejícím s tímto umístěním. Tyto dodatečné služby zahrnují například vytvoření grafického designu pro prezentaci na stránkách katalogu, pravidelné zasílání statistik návštěvnosti daného záznamu, možnost vložení obrázků produktů takové společnosti a případně dalších souborů (tiskové zprávy, novinky a další).

10.1 BPM Následující diagram představuje komplexní pohled na celý systém katalogu varianty se zpoplatněnými službami. Takovýto systém zajištuje vložení záznamu do systému, jeho další zpracování (kontrola, nastavení kvality zobrazení, zpracování grafiky a další) a následnou fakturaci a ověření platby. Dále systém umožňuje vyhledávat a prezentovat uložené záznamy návštěvníkům katalogu.

48

Obr. 12: Business process model varianty se zpoplatněnými službami Každý proces diagramu obsahuje vstup (input), požadavek na dosažení cíle (achieve) a výstup (output), případně dodatek (supply). Proces Vyhledávání a prezentace záznamů je přístupný libovolnému nepřihlášenému uživateli, kterému

49

skrze Vyhledávací formulář nalezne relevantní záznamy a vypíše je v pořadí odpovídajícím jak vyhledávanému řetězci a geografickým preferencím, tak i administrátorem nastavené prioritě zobrazení. Cílem je dosáhnout kvalitního vyhledávání informací přínosných pro uživatele a zároveň zvýšení zájmu o produkty a služby společností, které si za tuto službu zaplatily. Proces Přihlášení do systému na základě informací v Přihlašovacím formuláři ověří oprávněnost přístupu nepřihlášeného uživatele a vytvoří session platnou pro daného uživatele a po dobu jeho práce v systému. Tímto se z uživatele nepřihlášeného stává přihlášený uživatel. Tento přihlášený uživatel provádí aktivity seskupené do skupiny Zpracování zakázky. Toto zpracování se dále dělí na procesy Založení nového záznamu, Kontrola záznamu, Založení zakázky, Nastavení pravidel zobrazení a Grafické zpracování. Proces Založení nového záznamu představuje vložení (registraci) nového podnikatelského subjektu do databáze katalogu. Další možností provedení Založení nového záznamu je hromadný import dat prováděný administrátorem systému. V případě vložení záznamu uživatelem je takto vzniklý záznam třeba před jeho zveřejněním ověřit (výše zmiňovaná kontrola smysluplnosti uváděných dat a relevantnost zařazení do kategorií), což zajišťuje proces Kontrola záznamu. V případě zájmu o zpoplatněné dodatečné služby (např. garance zobrazení, zpracování grafické prezentace a další) je využit proces Založení zakázky, klientem požadovanou míru upřednostnění konkrétního záznamu nastavuje proces Nastavení pravidel zobrazení. Nastavování zobrazení je závislé na definovaných pravidlech zobrazení, kterým se budu věnovat dále v samostatné kapitole. V případě požadováného grafického zpracování prezentace je využito procesu Grafické zpracování. Provedení potřebných procesů vytvoří výstup Zpracovaná zakázka, který je zároveň vstupem pro skupinu procesů Úhrada zakázky. Zajištění uhrazení zakázky sestává z následujících procesů: Vystavení zálohové faktury, Ověření platby, Upomenutí platby, Vystavení ostré faktury. Proces Vystavení zálohové faktury následuje po provedení předchozí skupiny procesů (zpracování zakázky) a zajišťuje vytvoření a odeslání zálohové faktury na adresu zákazníka (elektronickou či klasickou cestou v závislosti na dohodě se zákazníkem), faktura má definovanou dobu splatnosti v závislosti na stanovených pravidlech. Po uplynutí

50

doby splatnosti je proveden proces Ověření platby, kdy je zkontrolován výpis bankovních účtů a v případě nalezení související platby (faktura byla uhrazena) je vystavena ostrá faktura. Proces Vystavení ostré faktury představuje zaevidování platby v účetnictví a vytvoření daňového dokladu pro zákazníka, který je mu také odeslán. Pokud proces Ověření platby nenalezne záznam o úhradě zálohové faktury, je klientovi odeslána upomínka a je uvědoměn také obchodní zástupce (obchodník), aby případně urgoval platbu také telefonicky. Zaplacený záznam je připraven pro následnou prezentaci a představuje tak produkt tvořící příjmy provozovatelům katalogu.

10.2 Podniková pravidla Každý model by měl co nejlépe vystihovat svoji reálnou předlohu ve skutečném světě. Pro lepší představu o pravidlech omezujících a blíže specifikujících procesy v podniku je vhodné se alespoň na některá tato pravidla blíže zaměřit. Podniková pravidla (business rules) ovlivňují provádění jednotlivých procesů a představují tak další specifikaci vlastnostní modelovaného systému. Pravidlo I. – vložené záznamy nesmí obsahovat nevhodné či nesmyslné texty a musí být zařazeny do relevantních kategorií. Toto kritérium je problematické vyhodnotit automatizovaně, a proto se vztahuje na spíše na činnost vykonávanou lidmi než na vlastnosti algoritmů vyhodnocujících vkládaná data. Automaticky lze vyřadit například záznamy obsahující zakázaná slova (neslušná) a například ty záznamy, kterým nebyl vyplněn nějaký důležitý údaj nebo nebyly zařazeny do žádné kategorie. Lidskou obsluhu ale nelze nahradit. Pravidlo II. – nastavené zvýhodnění v rámci zobrazení musí odpovídat platnému ceníku. V případě váhajícího zákazníka je možné nabídnout slevu do výše 10 procent ceny odpovídající požadovaným službám. Záznamy s vyšší úrovní zvýhodnění musí být vždy v rámci výsledků vyhledávání umístěny na lepších pozicích oproti záznamům s nižší úrovní zvýhodnění. Pravidlo III. – pokud není se zákazníkem dohodnuto jinak, je doba splatnosti u běžných faktur 30 kalendářních dní. Tato doba je standardní a odpovídá zvyklostem v daném oboru.

51

Pravidlo IV. – pokud není se zákazníkem dohodnuto jinak, je faktura vždy zasílána také poštou. Toto pravidlo zvyšuje proplacenost vystavených faktur a také přispívá k rychlejšímu výběru finančních prostředků (vyšší cash-flow), jelikož kontaktní údaje uvedené u záznamu nemusí být vždy aktuální. Pravidlo V. – pokud není se zákazníkem dohodnuto jinak, je daňový doklad vždy zasílán poštou. Z důvodu evidence v účetnictví je vhodné zákazníkovi vždy po úhradě faktury zaslat papírovou formu daňového dokladu. Pravidlo VI. – záznamy s placenou službou v předchozím období mohou mít prodlouženu dobu splatnosti faktury až na 60 kalendářních dní. Z důvodu již ověřené spolehlivosti zákazníka je možné poskytnout mu úlevu ve formě odsunutí platby faktury o měsíc navíc oproti standardní době splatnosti faktury. Pravidlo VII. – po uplynutí doby splatnosti u vystavených faktur je zaslána upomínka. Upomínky jsou zasílány elektronicky i poštou na adresu uvedenou jako korespondenční na vystavené faktuře. Pravidlo VIII. – upomínky jsou v případě neuhrazení faktury zasílány v intervalu 14 dní. Po uplynutí 14 dnů od zaslání první upomínky je zaslána upomínka druhá a v případě neuhrazení je po dalších 14 dnech zaslána třetí (poslední) důrazná upomínka platby faktury. Pravidlo IIX. – pokud nebyla faktura zaplacena do 14 dní od zaslání třetí upomínky, je třeba kontaktovat klienta telefonicky. Pro případ změny doručovací adresy je před vymáháním pohledávky vhodné ověřit osobně zaměstnancem (obchodníkem) důvody pro nezaplacení zaslané faktury.

10.3 Use case model Model Use case opět popisuje zapojení jednotlivých aktorů do konkrétních procesů. Oproti základnímu modelu přináší podstatně více funkcionalit i jednotlivých aktorů.

52

Obr. 13: Use case model varianty se zpoplatněnými službami Aktor Uživatel představuje zobecnění (generalizaci) aktorů Nepřihlášený uživatel a Přihlášený uživatel, kteří dědí od svého předka (Uživatel) případy užití Vyhledávání a prezentace záznamů a Přihlášení do systému. Přihlášený uživatel má navíc přidánu funkci Založení a editace záznamu. Zobecnění (generalizace) aktora lze s výhodou využít v případech, kdy dva aktoři komunikují se stejnou množinou případů užití úplně stejným způsobem. Potomci dědí od svých předků nejen role, ale i relace s případy užití. Potomek tedy

53

může být dosazen v případech, kde se může vyskytovat i jeho předek. Díky tomuto principu zaměnitelnosti můžeme otestovat správnost užití tohoto zobecnění (generalizace) [Arlow, Neustadt, 2007]. Aktor Kontrolor provádí kontrolu záznamu (Kontrola záznamu), Grafik zpracovává grafický návrh prezentace (Zpracování grafických prvků), aktor Obchodník zakládá novou zakázku (Založení zakázky) a nastavuje pravidla pro zobrazení záznamu při vyhledávání (Nastavení pravidel zobrazení). Následnou fakturu vystavuje aktor Obchodník (Vystavení zálohové faktury), který také ověřuje platbu (Ověření platby) a vystavuje ostrou fakturu (Vystavení ostré faktury). Případ užití Ověření platby je rozšířen o nové chování Upomenutí platby, stejně jako Vystavení ostré faktury je rozšířeno o chování Odeslání daňového dokladu pomocí relace <<extend>>. Relace <<extend>> poskytuje způsob, kterým je možné rozšířit již existující případ užití o nové chování. Případy užití Založení a editace záznamu, Kontrola záznamu, Zpracování grafických prvků, Založení zakázky, Nastavení pravidel zobrazení, Vystavení zálohové faktury, Ověření platby a Vystavení ostré faktury (stejně jako Upomenutí platby a Odeslání daňového dokladu) mají nastavenu relaci <> s případem užití Vyhledání záznamu. Relaci <> využijeme tam, kde se případy užití opakují. Klientským případem užití je zahrnující případ užití, zatímco zahrnovaným případem užití je označován dodavatelský případ užití. Zahrnovaný případ užití dodává chování klientskému případu užití. Klientský případ užití běží do okamžiku zahrnutí dodavatelského případu užití, kterému je přesunuto řízení běhu. V momentně, kdy je dokončeno zpracování scénáře dodavatelského případu užití, navrátí dodavatelský případ užití řízení běhu událostí zpět klientskému případu užití [Arlow, Neustadt, 2007].

10.4 Class model Diagram tříd vychází z Business process modelu a uplatňuje se v systémech modelovaných pomocí objektových jazyků a to především díky vlastnosti znovupoužitelnosti. Znovupoužitelnost (re-use) zavádí třídy, dědičnost, komponenty a další objekty zvyšující opakovatelnost použití v systému. Objekty jsou zapouzdřené

54

a proto je s nimi možné koumunikovat pouze zasíláním zpráv (definovaným rozhraním pro komunikaci s objektem). Mezi třídami jsou uvedeny relace (vazby) s uvedenou kardinalitou [Kanisová, Müller, 2006].

Obr. 14: Class model varianty se zpoplatněnými službami U jednotlivých tříd jsou uvedeny jejich atributy (vlastnosti) včetně datových typů nutných pro jejich uložení v databázi a také jednotlivé operace, které mohou objekty vykonávat.

55

Mezi třídou Záznam a třídou Pobočka je v diagramu naznačen vztah popisující skutečnost, kdy podřízený objekt nemůže existovat bez objektu nadřazeného. Tento vztah

nazýváme

kompozicí

a

znamená,

že

Pobočka

nemůže

existovat

bez nadřízeného Záznamu. Záznam bez Pobočky existovat může. Třída Zaměstnanec je abstraktní třídou pro třídy Obchodník, Kontrolor, Grafik a Účetní. Abstraktní třída obsahuje atributy a operace společné pro jiné třídy, které tyto vlastnosti od ní mohou dědit, a představuje tak zvláštní typ třídy, jejíž konkrétní instance v systému nikdy nevznikne. Stejně tak třída Uživatel je třídou abstraktní a dědí od ní atributy a operace třídy Příhlášený uživatel a Nepřihlášený uživatel.

10.5 Activity diagram Diagramy aktivit popisují chování systému, které má znaky sekvenčního i paralelního zpracování. Diagram aktivit lze považovat za variantu stavového diagramu představující kolekci aktivit a přechodů mezi nimi. Nedostatkem diagramů aktivit bylo nejasné vyjádření skutečnosti, kdo vykonává kterou aktivitu. Tento nedostatek řeší tzv. plavecké dráhy (swimlanes) upravující diagram do svislých pruhů vzájemně oddělených vertikálními čarami. Jednotlivé dráhy pak vyjadřují zodpovědnost konkrétní třídy, oddělení nebo osoby. [Kanisová, Müller, 2006].

56

Obr. 15: Diagram aktivit systému se zpoplatněnými službami Diagram popisuje životní cyklus záznamu (respektive zakázky) od jeho vložení do systému až po jeho prezentaci a případnou následnou fakturaci v případě placeného záznamu.

57

Uživatel vyplněním registračního formuláře s potřebnými informacemi včetně přihlašovacích údajů založí nový záznam v systému. Následně je tento záznam postoupen kontrole, zda jeho obsah představuje smysluplné informace a je správně zařazen do relevantních kategorií. V případě, že záznam této kontrole nevyhoví (obsahuje nesmyslné údaje), je zaslán zpět zadavateli na jeho e-mailovou adresu s žádostí o úpravu a opětovné vložení takového záznamu a jeho průchod systémem v danou chvíli končí. V případě, že záznam vyhoví a je možné jej v aktuální formě zobrazovat v rámci vyhledávání v katalogu, pokračuje dál diagramem k dalšímu rozcestí (fork). Pokud zadavatel záznamu nepožaduje žádné dodatečné služby, je takový záznam zveřejněn a prezentován ve výsledcích vyhledávání a při výpisu souvisejících kategorií. Pokud zadavatel požaduje dodatečné služby, vzniká v systému zakázka zpracovávaná obchodníkem. V případě, že je poptáváno zhotovení grafického návrhu zobrazované prezentace, dochází ke zpracování grafického návrhu grafikem, zatímco v opačném případě pokračuje zakázka dále k nastavení parametrů zobrazení. Po dokončení prací na grafickém ztvárnění prezentace pokračuje zakázka také k nastavení parametrů zobrazení a dochází tak ke spojení (join). Po nastavení parametrů (priorit) zobrazení záznamu obchodníkem vystaví účetní zálohovou fakturu a ta je následně odeslána obchodníkem klientovi. Účetní provede kontrolu platby této faktury dle výpisu z bankovního účtu a následně buď předá obchodníkovi k odeslání fakturu (daňový doklad) nebo jej vyzve k odeslání upomínky platby zákazníkovi. Po provedení těchto aktivit zakázka i celý záznam končí průchod systémem.

10.6 State diagram Stavový diagram znázorňuje chování systému pomocí popisu jednotlivých stavů, ve kterých se systém nachází. Lze říci, že modelují chování objektu napříč všemi případy užití, popisují totiž všechny možné stavy, kterých daný prvek systému může nabývat. Syntaxe těchto diagramů je jednoduchá, základem jsou počáteční a koncový stav a jednotlivé stavy mezi nimi, dále pak přechody mezi těmito stavy a události vyvolávající tyto přechody [Kanisová, Müller, 2006].

58

Stavový diagram popisující diskutovanou variantu systému internetového katalogu podnikatelských subjektů je uveden na následujícím obrázku.

Obr. 16: State diagram

59

Diagram popisuje jednotlivé stavy objektu záznam, počínaje vložením záznamu do systému a konče prezentováním tohoto záznamu nebo případně zamítnutím (chybou) záznamu. Vložení záznamu provede obvykle zákazník vyplněním registračního formuláře, následně záznam přechází do stavu Záznam kontrolován. Po provedení této kontroly (smysluplnost vložených dat a jejich správné zařazení) přechází záznam buď do stavu Záznam dále zpracováván, nebo do stavu Zamítnutí záznamu, kdy dochází k zaslání zprávy o zamítnutí uživateli, který jej do systému vložil, címž se objekt dostává do konečného stavu Chyba záznamu. V případě dalšího zpracování záznamu (záznam prošel kontrolou) mohou nastat dvě varianty. V případě, že zákazník nepožadoval při registraci žádné doplňkové služby, je záznam zařazen mezi platné záznamy a je společně s ostatními prezentován v rámci výsledků vyhledávání (Záznam prezentován). Tímto objekt přechází do konečného stavu Záznam hotov. Pokud si zákazník objednal doplňkové služby, které jsou zároveň zpoplatněny a vyžadují tak fakturaci, přechází objekt do stavu Nastavování priorit a stavu Zpracování grafického návrhu (tento v případě, že zákazník nepožadoval doplňkové grafické služby, pouze vloží do systému převzaté logo vkládané společnosti). Tyto činnosti jsou vykonávány souběžně, proto jsou i v diagramu tyto stavy znázorněny jako souběžné. Následně objekt záznam přechází do stavu Fakturování (zákazníkovi je zaslána faktura za provedené služby a čeká se na její úhradu) a následně v případě uhrazení do stavu Ukončení zakázky, naopak v případě, že faktura uhrazena nebyla, do stavu Vymáhání platby a zpět do stavu Fakturování (opět provádíme kontrolu, zda byla faktura uhrazena). Po následném uhrazení přechází opět do stavu Ukončení zakázky. Po ukončení zakázky je záznam opět zařazen do skupiny platných záznamů a společně s nimi je prezentován mezi výsledky vyhledávání (stav Záznam prezentován) a následně přechází objekt zakázka do konečného stavu Záznam hotov.

10.7 Datový model Namapování do relační databáze je defacto namapováním jednotlivých tříd z class modelu do tabulek relační databáze. Ačkoliv Enterprise architect neposkytuje nástroj přímo pro tvorbu ERD diagramů, lze pomocí jeho prostředků dostatečně názorně

60

vytvořit datový model diskutovaného systému. Uvedený datový model nemusí zcela odpovídat třídám z předchozího class modelu a to především z důvodů databázové integrity (vznikají vazební entity nemající svůj obraz v diagramu tříd) případně přehlednější interpretace v rámci relační databáze.

61

Obrázek 17: Datový model systému vytvořený nástrojem Enterprise Architect

62

Jednotlivé objekty diagramu představují tabulky relační databáze a vazby mezi nimi vyjadřují kardinalitu těchto vazeb. Z důvodů integrity relační databáze bylo nutné zavést vazební entity a číselníky. Vazební entita Zařazen uchovává informaci o zařazení daného záznamu do kategorií. Stejně tak tabulky Týkající se, Připojené, Administruje a Ohodnocen představují vazební entity spojující jiné tabulky vazbou n .. n. Tabulka Kategorie obsahuje ID a název kategorie zobrazovaný v rámci výpisu a také odkaz na nadřazenou kategorii (pro vytvoření stromové struktury kategorií). Tabulka Typ je číselníkem k tabulce Soubory a obsahuje typy souborů vložených k danému záznamu (například dokument PDF, XLS, GIF a další). Každá entita obsahuje atributy (sloupce tabulky) s uvedením datového typu kompatibilního s jazykem SQL relačních databází. Dále je u každé tabulky uveden primární klíč (Primary Key, unikátní identifikátor každé instance – řádku) a, pokud je v dané tabulce obsažen, také cizí klíč (Foreign Key) odkazující na primární klíč jiné tabulky. Vzhledem k poměrně velkému rozsahu datového modelu jsem zpracoval tento model také v abstraktnější rovině, kde jsou vynechány jednotlivé atributy i označení primárních a sekundárních klíčů všech tabulek v databázi.

63

Obrázek 18: Entitně relační model s vynechanými atributy

10.8 Ekonomický přístup Stejně jako předchozí případy, i tento model je předmětem úvah o nezbytných nákladech i možnostech tvorby zisku. Od předchozích variant se liší především rozšířením o potřebu fakturace (zpoplatnění služeb). Toto rozšíření znamená sice finančně náročnější vývoj systému i jeho provoz, ale také přináší významný zdroj finančních prostředků. Rovněž funkcionalita systému je v porovnání se základní variantou podstatně širší (nejde jen o fakturaci, ale i další funkce).

64

Náklady můžeme rozdělit na náklady na vývoj systému a na náklady na jeho provoz. Vývoj této varianty zahrnuje základní funkční požadavky a další přidané funkce. Standardně je třeba vytvořit prostředí pro vložení a následnou editaci záznamů, přihlašovací systém a prezentační část aplikace, kde jsou data zobrazována ostatním uživatelům (vyhledávání). Protože požadujeme možnost nastavení vlastností pro zobrazení každého záznamu, je nutné vytvořit také rozhraní pro zadání těchto vlastností a především do systému zakomponovat algoritmy zohledňující toto nastavení při prezentaci nalezených výsledků vyhledávání (pořadí zobrazovaných záznamů). V neposlední řadě je nezbytné vytvořit přinejmenším fakturační systém (případně vyvinout i subsystém pro účetní aplikace), aby bylo možné tyto zvýhodněné záznamy účtovat zákazníkovi. Provozní náklady v tomto případě opět obsahují fixní částku za provoz dedikovaného serveru (řádově tisíce korun měsíčně) a náklady na zaměstnávání osob zajišťujících provoz systému vykonávajících stejné činnosti jako v případě základní varianty rozšířené o dodatečné požadavky (fakturace a další). Mezi činnosti shodné se základní variantou patří dohled nad automaticky prováděnými činnostmi nutnými pro dlouhodobý provoz (zálohování, kontroly integrity a další), kontrola vkládaných dat (jejich smysluplnost a relevance zařazení do kategorií) a poskytování technické podpory. Kromě toho je nutné zajistit vykonávání činností vyplývajících z dodatečné funkcionality, představující především nastavení vlastností zobrazování daných záznamů, případné grafické zpracování a následnou fakturaci služeb. Tato fakturace zahrnuje jednak samotné vytvoření a zaslání faktury klientovi, tak i následnou kontrolu úhrady této faktury a případné upomínání zákazníka o platbu. Po obdržení platby na účet je zasílán daňový doklad na adresu zákazníka. Náklady na tyto zaměstnance závisí na vytížení systému (počet zákazníků) a pohybují se řádově v desítkách tisíc korun měsíčně (malé vytížení) až statisících korun měsíčně (střední až vysoké vytížení). Opět je vhodné především v počátečních fázích projektu investovat jisté prostředky do reklamy. Pro zajištění dostatečné návratnosti vložených investic je nutné získat relativně vysoké množství zákazníků a toho lze dosáhnout pouze pomocí marketingových nástrojů. Náklady na reklamu představují řádově desetitisíce

65

až statisíce korun měsíčně, po dosažení dostatečného podílu na trhu je možné tyto náklady na reklamu výrazně snížit, nicméně je vhodné do nějaké formy reklamy investovat alespoň nějaké prostředky po celou dobu provozu katalogu. Po dosažení významnějšího podílu na trhu je také možné získávat reklamní služby od ostatních subjektů výměnou za prostor v rámci katalogu a ušetřit tak významnou část prostředků vynaložených na reklamní kampaň. Z uvedených skutečností tedy vyplývá, že celkové náklady jsou v případě varianty s placenými službami nejvyšší z uvažovaných variant. Příjmy v tomto případě tvoří stejně jako v předchozích variantách zisky z poskytnutí reklamního prostoru na stránkách katalogu (především různé bannery a textové reklamní prvky) a především prostředky získané z uhrazených faktur za poskytnuté služby související se zařazením záznamu do katalogu (například zvýhodnění pozice při vyhledávání nebo zpracování grafického návrhu). Tyto příjmy závisí na počtu získaných zákazníků a pohybují se od desítek tisíc korun měsíčně až po řádově miliony korun měsíčně. Celkově lze u této varianty předpokládat relativně vysokou šanci na návrat vložených investic v poměrně krátkém čase a potenciál pro tvorbu zisku.

66

11 Diskuse Všechny navržené varianty řešení splňují základní požadavky kladené na řešený systém a poslední dvě je dále rozšiřují přidanými funkcionalitami. Pro výběr nejvhodnější varianty je třeba zvážit všechny uvedené aspekty v předcházejících kapitolách a to zejména ekonomickou stránku řešení. Jelikož v ekonomických hodnoceních jsou zahrnuty předpokládané příjmy i výdaje na projekt, je možné je považovat za nejvýznamnější stránku hodnocených projektů. První varianta představuje nejnižší náklady na pořízení systému i jeho provoz, ale také nejmenší příležitost k tvorbě zisku. Finanční prostředky jsou získávány pouze z reklamních prvků třetích stran umístěných na stránkách katalogu jsou tedy závislé na návštěvnosti uvažovaného katalogu. Tuto základní variantu je vhodné považovat pouze za výchozí model systému vhodný k dalšímu rozšiřování. Varianta popisovaná druhá v pořadí představuje model s předpokládanými vyššími náklady na pořízení i provoz takového systému, nicméně uváděná rozšíření funkcionality o přidané služby představují významný faktor ovlivňující množství subjektů registrovaných v systému a rozvněž

návštěvnost takového katalogu.

Očekávání vyšší návštěvnosti přináší výrazně vyšší predikce příjmů z reklamy i vyšší šance na dosažení rozumné doby návratnosti vložených prostředků do projektu. Třetí a poslední varianta se zabývá modelem systému, který umožňuje kromě standardního vložení a následné prezentace záznamu také využít doplňkových služeb, které jsou pro firmy výhodné a přinášejí jim větší obrat a zároveň také představují významnou příležitost pro získání finančních prostředků do rozpočtu katalogu. Tento systém přináší sice nejvyšší náklady na pořízení i provoz, díky řádově vyšším potenciálním příjmům je ale pravděpodobně nejvhodnějším modelem z uvedených pro úspěšné podnikání na trhu internetových katalogů. Případné modifikace ovšem mohou přinést ještě vyšší šance na získání nových zákazníků i uživatelů a především navržené dodatečné funkce druhého uváděného modelu lze považovat za výchozí funkcionality pro rozšíření třetího modelu. Tato rozšíření je možné provést i v průběhu provozu systému a rozložit tak pořizovací náklady do více období.

67

12 Závěr Ve svojí diplomové práci jsem se pokusil zužitkovat znalosti nabyté v průběhu studia na Provozně ekonomické fakultě Mendelovy zemědělské a lesnické univerzity v Brně. Mým úkolem bylo provést analýzu činností souvisejících s internetovým katalogem podnikatelských subjektů, navržení variant řešení a jejich znázornění základními analytickými

modely.

Dále

potom

porovnat

jejich

vzájemnou

vhodnost

a ekonomické aspekty a detailněji navrhnout pomocí nástrojů objektového modelování nejvhodnější variantu včetně navržení datového modelu (namapování do relační databáze). Práce stručně popisuje situaci na trhu internetových katalogů a vysvětluje princip jejich fungování, prezentuje vybraná teoretická východiska pro vytvoření práce a popisuje způsoby optimalizace webových stránek vedoucí k lepším tržbám společností prezentujících se na internetu. Na základě těchto východisek vzniká základní metamodel podnikových konceptů a dále byl s pomocí tohoto metamodelu vytvořen základní model systému internetového katalogu podnikatelských subjektů splňující základní požadavky na takový systém. Byl navržen základní model společný pro všechny další varianty řešení a také dva další modely pro dvě různé varianty řešení. Jedna z variant byla vybrána a podrobněji zpracována pomocí nástrojů objektového modelování. Bylo navrženo namapování do relační databáze pomocí datového

modelu.

Všechny

diskutované

varianty

jsou

zhodnoceny

také

z ekonomického hlediska, kde jsem se pokusil odhadnout příjmy a náklady konkrétní varianty. Práce splňuje vytyčené cíle a jejím přínosem je v neposlední řadě také významné rozšíření mých znalostí o diskutované problematice a jejich praktické uplatnění v pracovním životě.

68

13 Použitá literatura •

KANISOVÁ, Hana, MÜLLER, Miroslav. UML srozumitelně. 2. aktualiz. vyd. Praha: Computer Press a.s., 2006. 176 s. ISBN 80-251-1083-4.

•

ŘEPA, V. Podnikové procesy: procesní řízení a modelování. 1. vyd. Praha: Grada, 2006. 265 s. Management v informační společnosti. ISBN 80-247-1281-4.

•

RÁBOVÁ, Ivana, et al. Podniková architektura: strategický nástroj v rukou manažera. 1. vyd. Brno: Tribun EU, 2008. 134 s. ISBN 978-80-7399-568-3.

•

ERIKSSON, H. E. PENKER, M. Business Modeling with UML : Business Patterns at Work. New York: John Wiley & Sons, 2000. 19 s. ISBN 0-47129551-5.

•

ARLOW, J. NEUSTADT, I. UML 2 a unifikovaný proces vývoje aplikací: objektově orientovaná analýza a návrh prakticky. 2. vyd. Brno: Computer Press, 2007. 567 s. ISBN 978-80-251-1503-9.

•

HTK Pro s. r. o.. Enterprise Architect Akademická licence [online]. 2008 [cit. 2009-01-08]. Dostupný z WWW: .

•

LOUDA, Pavel. Vyhledávače v Česku: Google roste na úkor ostatních. Computerworld [online]. 2008 [cit. 2009-04-11]. Dostupný z WWW: .

•

Wikipedia. Internetový katalog [online]. 2009 [cit. 2009-02-23]. Dostupný z WWW: .

•

Wikipedia. Internetový vyhledávač [online]. 2009 [cit. 2009-02-23]. Dostupný z WWW: .

•

Wikipedia. Search Engine Optimization [online]. 2009 [cit. 2009-03-26]. Dostupný z WWW: .

69

Přílohy

70

A Diagramy UML pro základní model Zde uvádím následující modely: •

Business Process Model

•

Use Case Model

71

72

73

B Diagramy UML pro variantu bez zpoplatnění Zde uvádím následující modely: •

Business Process Model

•

Use Case Model

74

75

76

C Diagramy UML pro variantu s garancí Zde uvádím následující modely: •

Business Process Model

•

Use Case Model

•

Class Model

•

Activity Diagram

•

State Diagram

•

Datový model

77

78

79

80

81

82

83