VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE Fakulta informatiky a statistiky Katedra informačních technologií

VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE Fakulta informatiky a statistiky Katedra informaˇcních technologií

Studijní program: Aplikovaná informatika Obor: Kognitivní informatika

DIPLOMOVÁ PRÁCE

Analýza požadavku˚ na IS pro podporu organizací pusobících ˚ v neziskovém sektoru The Requirements Analysis for IS Supporting the Nonprofit sector organizations

Diplomant: Bc. Martin Kružík Vedoucí diplomové práce: Ing. Oleg Svatoš ˇ Oponent diplomové práce: prof. Ing. Václav Repa, CSc.

Školní rok 2011/2012

Prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatnˇe a že jsem uvedl všechny použité prameny a literaturu, ze kterých jsem cˇ erpal.

V Praze, dne 1. kvˇetna 2012

Martin Kružík

ˇ Podekování Rád bych tímto podˇekoval pˇredevším Ing. Olegu Svatošovi za konzultace, nedocenitelné rady a odborné vedení mé práce.Dˇekuji též mé snoubence za projevenou trpˇelivost a všestrannou pomoc.

Abstrakt ˇ se rozvíjí pouze pozvolna a v mnoha klíˇcových bodech výraznˇe Neziskový sektor v CR zaostává za západními zemˇemi. Najít schudnou ˚ cestu k rustu ˚ pˇritom není snadný úkol. Neziskové organizace mají potíže se sebeprezentací a komunikací s podporovateli, jsou cˇ asto netransparentní a nemají proto duvˇ ˚ eru veˇrejnosti. S tím souvisí také velmi nízký objem finanˇcních daru˚ putujících na podporu neziskových projektu˚ a nízký zájem veˇrejnosti o dobrovolnictví. Cílem této práce je provést analýzu problémové domény a navrhnout rˇ ešení spoˇcívající ve vytvoˇrení platformní organizace, která bude s podporou informaˇcních technologií neziskovým organizacím schopna poskytnout služby umožnující ˇ jim pˇrekonat zmínˇené nesnáze.

Klíˇcová slova: analýza neziskového sektoru, dárcovství, procesní analýza, MMABP, WebML

Abstract The nonprofit sector in Czech Republic grows slowly and in many key aspects significantly lags behind western countries. In fact, to find a feasible way to growth is actually far from being easy. Nonprofits, frequently encountering problems with self-presentation and communication with supporters, fail to establish transparency and credibility among public, which is connected to considerably low sum of financial donations supporting nonprofit causes and low public interest in volunteering as well. An aim of this thesis is to proceed with an analysis of a problem domain and to design a solution which lies in founding a platform organization, which would be able to offer IT supported services allowing the nonprofits to overcome aforementioned difficulties.

Keywords: nonprofit sector analysis, donating, process analysis, MMABP, WebML

Obsah Úvod

11

1. Definice problému

13

1.1. Vymezení pojmu „neziskový sektor“, „nezisková organizace“ . . . . . . . . .

13

1.2. Popis souˇcasného stavu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

1.3. Strategický cíl a cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

1.4. Známá rˇ ešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

1.5. Pˇrínos nového rˇ ešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

ˇ analytické metody 2. Specifikace cílu˚ a výber

31

2.1. Detailní specifikace cílu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

2.2. Výbˇer analytické metody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

2.3. Použité nástroje a postup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

3. Analýza

45

3.1. Okolí systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

3.2. Analýza klíˇcových procesu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

3.3. Analýza agentu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

3.4. Alokace firemní filantropie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

3.5. Hledání firemního podporovatele . . . . . . . . . . . . . . . . . . . . . . . . . .

52

3.6. Obecný model základních business entit . . . . . . . . . . . . . . . . . . . . . .

54

3.7. Nabídnutí neziskového pˇrípadu veˇrejnosti . . . . . . . . . . . . . . . . . . . .

57

3.8. Zprostˇredkování podpory pˇrípadu . . . . . . . . . . . . . . . . . . . . . . . . .

65

3.9. Registraˇcní procedury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

3.10. Objednávky a platby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

3.11. Ostatní procesy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

93

3.12. Analýza požadavku˚ na IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 3.13. Diskuze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 ˇ metodiky návrhu webových aplikací 4. Výber

111

4.1. WSDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 4.2. OOHDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 4.3. UWE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 4.4. WebML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 4.5. Výbˇer metodiky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 5. Úvod do návrhu webové aplikace

123

5.1. Užité prvky notace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 5.2. Specifikace požadavku˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 9

5.3. Pˇríklad užití WebML - Neziskový projekt . . . . . . . . . . . . . . . . . . . . . 126 ˇ 6. Zhodnocení a záver

129

Terminologický slovník

131

Literatura

134

Seznam obrázku˚

137

Seznam pˇríloh

141

ˇ tabulky Pˇríloha 1 - Konzistencní

143

10

Obsah

Úvod Cílem této práce je navrhnout systém, který bude podporovat urˇcité typy procesu˚ ve vybraných neziskových organizacích. Protože neziskové organizace jsou považovány za nedílnou souˇcást obˇcanské spoleˇcnosti, smysl této práce v zásadˇe stojí a padá s pˇredpokladem, že obcˇ anskou spoleˇcnost je tˇreba rozvíjet, že jde tedy o ideál, o nˇejž je v zásadˇe tˇreba usilovat. Toto tvrzení pˇrirozenˇe není zˇrejmé samo od sebe a k jeho držení je tˇreba jistých skrytých pˇredpokladu˚ vycházejících z tradiˇcních pˇredstav evropské civilizace o tom, co je obˇcanství, spoleˇcnost a cˇ lovˇek. Vajdová ve [Vajdová, 2005, s. 22] popisuje chápání pojmu „obˇcanská spoleˇcnost“ v tuzemsku následovnˇe: „V cˇ eském veˇrejném i odborném diskurzu obˇcanská spoleˇcnost obvykle znamená pozitivní sdružování obˇcanu, ˚ které je nezávislé na státu, pˇrispívá k rozvoji obˇcanských hodnot a sociálního kapitálu a je vuˇ ˚ ci demokracii jako spoleˇcenskému režimu v podstatˇe konstruktivní.“ Nejde pˇrirozenˇe o definici, která by vyˇcerpávajícím zpusobem ˚ pˇredstavovala smysl obˇcanské spoleˇcnosti a odpovídala tak na otázku, zda je obˇcanská spoleˇcnost vhodným cílem lidského usilování, cˇ i nikoliv, aˇckoli i o odpovˇed’ na tuto otázku je tˇreba usilovat. Podání takové rigorózní definice, pokud je vubec ˚ možné, by vyžadovalo solidní a jemnou multidisciplinární práci, která však výrazným zpusobem ˚ pˇrekraˇcuje skromné meze této stati. Výše uvedená citace však obsahuje cenné pˇredporozumˇení tomu, o co v obˇcanské spoleˇcnosti jde - její úˇcastníci vˇedomˇe a cílenˇe peˇcují o jisté hodnoty, které jsou považovány za hodnotné z hlediska obce, tj. spoleˇcnosti jako celku. Neziskový sektor pˇritom není pˇrímo závislý na politických mechanismech státu, ale funguje na bázi služby obˇcanu˚ obˇcanum. ˚ 1 Problémem s definicí však nesnáze nekonˇcí. I kdyby totiž bylo jasnˇe ukázáno, že obˇcanská spoleˇcnost je vpravdˇe cosi cenného, nelze se vyhnout empirii, která cˇ lovˇeka pouˇcuje, že v reálném svˇetˇe lze vytyˇcených ideálu˚ jen sotva dosáhnout. Jistˇe totiž existuje mnoho podivných neziskových organizací, jejichž cílem je prosazovat hodnoty, s nimiž se lze jen obtížnˇe ztotožnit, nebo takových, které jsou založeny na výluˇcnˇe sobeckých zámˇerech. Pokud však má mít tato diplomová práce nˇejaký smysl, je tˇreba vˇerˇ it, že naznaˇcené ideální principy jsou neziskovými organizacemi do urˇcité míry skuteˇcnˇe reprezentovány, tj. že neziskový sektor jako takový pˇrináší v zásadˇe více dobrého, než zlého. V praktické rovinˇe pak musí nezisková organizace, aby dosáhla svých cílu, ˚ rˇ ešit celou rˇ adu otázek, které obvykle pˇrímo nesouvisí s její hlavní cˇ inností (nebo, chcete-li, s jejími klíˇcovými procesy). Mezi nejpalˇcivˇejší z nich pˇrirozenˇe patˇrí otázka získávání zdroju˚ - pˇredevším finanˇcních, avšak nikoliv výhradnˇe. Neziskové organizace totiž obvykle nejsou schopny pokrýt své náklady pouze prostˇrednictvím výnosu˚ z cˇ inností, za jejichž úˇcelem byly zˇrízeny a jsou tak v ruzné ˚ míˇre odkázány na dobrovolné dary jednotlivcu, ˚ nadací a firem - klient organizace a její plátce jsou tudíž obvykle dva ruzní ˚ lidé. Získávání zdroju˚ od tˇretích stran je cˇ inností, kterou musejí vykonávat všechny - nebo témˇerˇ všechny - neziskové organizace, aˇckoliv nejde o cˇ innost, za jejímž úˇcelem jsou zˇrizovány. 1V

reálném svˇetˇe pˇrirozenˇe nelze závislost na politických strukturách vylouˇcit. Mnoho organizací má kupˇríkladu status tzv. pˇríspˇevkové organizace, což jim umožnuje ˇ cˇ erpat prostˇredky ze stáního rozpoˇctu. To však nic nemˇení na faktu, že ideálem je nezávislost neziskového sektoru na politických strukturách.

11

V úvahu tedy pˇripadá vznik zprostˇredkovatelské platformy cˇ i organizace, která se specializuje právˇe na hledání zdroju˚ pro neziskové organizace. Analýza procesu˚ probíhajících v této organizaci a informaˇcního systému pro jejich podporu je tedy podstatnou složkou rˇ ešení. Postup práce bude následný: vycházeje z dostupných statistických údaju˚ a) provedu nejprve ˇ (viz zejm. 1.2), na jejímž základˇe poté b) obecnou analýzu stavu neziskového sektoru v CR detailnˇeji stanovím nenaplnˇené potˇreby neziskového sektoru (viz zejm. 2.1), c) položím si otázku, jak by mˇela fungovat organizace zamˇerˇ ená na rˇ ešení problému˚ neziskového sektoru a provedu analýzu procesu˚ této organizace (viz kap. 2) a koneˇcnˇe d) stanovím požadavky na informaˇcní systém, jenž by tyto procesy podporoval (viz 3.12).

12

1. Definice problému V této kapitole se zamˇerˇ ím na popis souˇcasného stavu v problémové oblasti, definici cíle, jehož je tˇreba v rámci diplomového projektu dosáhnout, dále analýzu podobných, již existujících rˇ ešení a koneˇcnˇe oˇcekávané pˇrínosy práce.

1.1. Vymezení pojmu „neziskový sektor“, „nezisková organizace“ V ekonomice lze podle [Skovajsa, 2010, s. 32] rozlišit cˇ tyˇri sektory: a) sektor soukromý, b) sektor veˇrejný, c) sektor soukromý neziskový a d) sektor domácností. Neziskový sektor se od ostatních liší pˇredevším tím, že pˇredstavuje oblast soukromých subjektu, ˚ jejichž primárním cílem není dosažení zisku. Boukal v [2009, s. 10] vyslovuje názor, že podstatným rysem neziskových organizací je to, že se primárnˇe snaží dosáhnout pˇrímého užitku (tj. pozitivního dopadu na své okolí a nikoliv zisku), který má vˇetšinou charakter veˇrejné služby. Oznaˇcení sektoru je nejednotné a v pˇrívlastku názvu se tak lze setkat s adjektivy jako „obˇcanský“, „tˇretí“, „nevládní“, „nezávislý“. Tyto vzájemnˇe odlišné pojmy pˇredstavují totožný pˇredmˇet, avšak z ruzných ˚ úhlu˚ pohledu. Název „nezisková organizace“ navíc není zcela pˇresný, aˇckoliv jej lze považovat za patrnˇe nejrozšíˇrenˇejší v obecném povˇedomí.1 Název totiž muže ˚ evokovat mylnou pˇredstavu, že tyto organizace obecnˇe nemohou, nesmˇejí cˇ i nechtˇejí generovat zisk. Ve skuteˇcnosti však jde pouze o organizace, u nichž zisk není primárním cílem, aˇckoliv jej generovat mohou a obvykle též chtˇejí.2 Pojem neziskový sektor je dále nepˇresný z toho duvodu, ˚ že se zdá zahrnovat všechny neziskové struktury, tj. celý veˇrejný sektor vˇcetnˇe státních institucí, což je ovšem v rozporu se zpusobem, ˚ jímž je bˇežnˇe užíván. Proto se nˇekdy používá pˇresnˇejšího pojmu „nestátní neziskový sektor“. Není-li snadné urˇcit intenzi pojmu, tj. jeho smysl, nebývá jednoduché vymezit ani jeho extenzi, aˇckoliv postupu, ˚ kterých je k tomu možno využít, je celá rˇ ada.3 Relativnˇe jednoduchou metodou, jak urˇcit organizace spadající pod tento koncept, nabízí právo. Tuzemské právní normy sice neznají pojem „nezisková organizace“ jako právní formu, ale podle [Vajdová, 2005] je možné podat jakýsi výˇcet právních forem, jejichž nabytím se organizace podle tuzemského odborného úzu stává neziskovou.4 Jedná se o:5 • Nadace a nadaˇcní fondy upravené podle zákona cˇ . 227/1997 Sb., o nadacích a nadaˇcních fondech, ve znˇení zákona cˇ . 210/2002 Sb., cˇ . 257/2004 Sb., 296/2007 Sb., cˇ . 126/2008 Sb., cˇ . 160/2010 Sb., cˇ . 227/2009 Sb., cˇ . 158/2010 Sb. a cˇ . 188/2011 Sb. 1 To

je také duvod, ˚ proˇc jej (ovšem s níže uvedenou výhradou) budu používat i v rámci této práce. [Skovajsa, 2010, s. 32] 3 Zájemce o tuto problematiku odkazuji na titul [Skovajsa, 2010, s. 31 nn.]. 4 Viz ibid. 5 Následující informace cˇ erpám též z [Skovajsa, 2010, s. 170] a z [Esipa, 2011]. 2 Viz

13

• Obecnˇe prospˇešné spoleˇcnosti upravené podle zákona cˇ . 248/1995 Sb., o obecnˇe prospˇešných spoleˇcnostech, ve znˇení zákona cˇ . 208/2002 Sb., cˇ . 320/2002 Sb., cˇ . 437/2003 Sb., cˇ . 296/2007 Sb., cˇ . 126/2008 Sb, cˇ . 227/2009 Sb. a cˇ . 231/2010 Sb.. • Obˇcanská sdružení upravené podle zákona cˇ . 83/1990 Sb., o sdružování obˇcanu, ˚ ve znˇení zákona cˇ . 300/1990 Sb., cˇ . 513/1991 Sb., cˇ . 68/1993 Sb., cˇ . 151/2002Sb., cˇ . 230/2006 Sb., cˇ . 342/2006 Sb., cˇ . 33/2008 Sb, cˇ . 227/2009 Sb. a cˇ . 424/2010 Sb.. • Církve a náboženské spoleˇcnosti upravené podle zákona cˇ . 3/2002 Sb., o svobodˇe náboženského vyznání a postavení církví a náboženských spoleˇcností, ve znˇení nálezu Ústavního soudu cˇ . 4/2003 Sb., zákona cˇ . 562/2004 Sb., cˇ . 495/2005 Sb., cˇ . 296/2007 Sb., cˇ . 129/2008 Sb., cˇ . 41/2009 Sb. a cˇ . 227/2009 Sb. • Rozpoˇctové a pˇríspˇevkové organizace upravené podle zákona cˇ . 576/1990 Sb., o pravidlech ˇ ˇ hospodaˇrení s rozpoˇctovými prostˇredky Ceské republiky a obcí v Ceské republice, ve znˇení zákona cˇ . 160/1997 Sb. a cˇ . 360/1999 Sb. Problémem je, že ani tento úzus není zcela jednoznaˇcný, nebot’ je sice pˇrevažující, ale není ˇ pˇrijímán všeobecnˇe.6 Autoˇri nˇekterých studií (mj, též Ceský statistický úˇrad) totiž, v souladu s tzv. strukturálnˇe-operacionální definicí, která je užívána pˇredevším v zahraniˇcí, pracují se širší extenzí pojmu a mezi neziskové organizace proto zahrnují též odbory, divadla, školy, politické strany, profesní komory, vybrané obchodní spoleˇcnosti, atd. Takto nejednotné chápání bohužel znaˇcnˇe komplikuje vzájemné porovnávání získaných dat, která jsou pˇrístupná pouze na agregované úrovni a neumožnují ˇ proto ošetˇrit statistiku vyjmutím, resp. pˇridáním organizací majících jisté právní formy. Tristním, ale nutným dusledkem ˚ je snížená vypovídací schopnost závˇeru˚ jakýchkoliv komparativních úvah. V rámci této práce se pˇridržím definice užší, kterou podává Vajdová, a to z toho duvodu, ˚ že a) jde o definici, která podle mého názoru nejlépe odpovídá obecnému povˇedomí o neziskových organizacích a b) pˇríliš široké definice obvykle ztrácejí svuj ˚ význam, nebot’ mají tendenci zahrnout vše a nikoliv vydˇelit mínˇené z celku.

ˇ 1.2. Popis soucasného stavu Celkový (byt’ kvuli ˚ metodické roztˇríštˇenosti jednotlivých zdroju˚ pouze ponˇekud nepˇresný) ˇ se pokusím sestavit na základˇe pruobraz stavu neziskového sektoru a filantropie v CR ˚ zkumu˚ veˇrejného mínˇení a statistických šetˇrení. Pro úˇcely této práce se zamˇerˇ ím pˇredevším na data související s dárcovstvím, dobrovolnictvím, strukturou financování organizací, fundraisingem a vztahem veˇrejnosti k neziskovému sektoru jako takovému. V následující cˇ ásti uvedu relevantní data pocházející z nejvýznamnˇejších studií zkoumajících tuzemský neziskový sektor, pokusím se o mezinárodní srovnání nˇekterých ukazatelu˚ a provedu interpretaci výsledku. ˚

ˇ 1.2.1. Neziskový sektor v CR Tuzemská obˇcanská spoleˇcnost má za sebou dlouhou - a nutno též rˇ íci pohnutou - historii. Její zárodky lze datovat již do období národního obrození v 19. století. Svobodný rozvoj 6 Viz

kap. 1.2.1.1.

14


zažívá neziskový sektor za první republiky. Jeho aktivity jsou však takˇrka ochromeny za druhé svˇetové války a v navazujícím období totalitní diktatury jedné strany. Jeho resuscitace zaˇcíná po revoluci v roce 1989.7 ˇ ˇ ˇ V dnešních dnech je v Ceské republice podle údaju˚ Ceského statistického úˇradu (dále též CSÚ) ˇ [CSÚ, 2011] registrováno celkem 113 213 neziskových organizací.8 Tato statistika však operuje se širokou definicí pojmu a zahrnuje proto nejen nadace a nadaˇcní fondy, sdružení, církevní organizace, ale i odbory cˇ i honební spoleˇcenstva. V roce 2008 pˇrijaly neziskové ˇ organizace celkem 4,21 miliard Kˇc v darech (k nimž však CSÚ pˇripoˇcítává též pˇríspˇevky zúˇctované mezi organizaˇcními složkami). Jejich cˇ innosti se úˇcastnilo celkem 1 236 530 dobrovolníku, ˚ kteˇrí dohromady odpracovali 47 426 293 hodin. ˇ Aˇckoliv se neziskový sektor v Ceské republice neustále rozvíjí, úrovenˇ znalostí o nˇem stále není pˇríliš vysoká a nesnese srovnání s ostatními státy Evropské unie, a to jak z hlediska kvantitativního, tak kvalitativního. Pospíšil ve svém cˇ lánku [Pospíšil, 2005] napˇríklad tvrdí, že zde bylo doposud vykonáno tak malé množství empirických a teoretických výzkumu˚ týkajících se neziskového sektoru, že obˇcanský sektor je stále jakási terra incognita. Je tˇreba s politováním konstatovat, že aktuální a dostateˇcnˇe kvalitní informace nejsou k dispozici doposud.

ˇ k neziskovému sektoru ˇ u˚ CR 1.2.1.1. Vztah obcan Tuto neutˇešenou situaci se pokouší již nˇekolik let svou publikaˇcní cˇ inností zmˇenit Centrum pro výzkum neziskového sektoru, které v souˇcasné dobˇe pracuje na systematickém výzkumu ekonomických údaju˚ o filantropii jednotlivcu. ˚ Prozatím však (v roce 2009) spatˇrila svˇetlo svˇeta pouze pˇrípravná publikace nazvaná Dárcovství v oˇcích veˇrejnosti [Hladká et al., 2009] obsahující výsledky dotazníkového šetˇrení zjišt’ujícího postoje obˇcanu˚ k filantropii, (resp. neziskovému sektoru). Dotazníky sice vyplnilo celkem 359 respondentu, ˚ avšak autorky samotné zpochybnují ˇ kvalitu výstupu, ˚ nebot’ výbˇer respondentu˚ nepovažují za zcela reprezentativní.9 Pˇresto, jak vˇerˇ ím, mohou zveˇrejnˇené výsledky hrát alesponˇ roli urˇcitého vodítka umožnujícího ˇ cˇ ásteˇcnˇe osvˇetlit postoje obˇcanu. ˚ Cílem výzkumu bylo mimo jiné zjistit, nakolik jsou neziskové organizace pro obˇcany duvˇ ˚ eryhodné, dále zda je veˇrejností cˇ innost neziskovými organizacemi provádˇená vnímána jako duležitá, ˚ nakolik je pro dárce podstatná transparentnost neziskových organizací a kontrola nad tím, za jakým úˇcelem jsou darované finanˇcní prostˇredky využity. Výsledky odpovídající na tyto otázky jsou následující (graficky jsou prezentovány na Obrázku 1.1):10 ˇ • S tvrzením cˇ . 1: „Cinnost neziskových organizací je pro spoleˇcnost potˇrebná, proto je správné je finanˇcnˇe podporovat“ souhlasilo 88,6 % dotázaných, nesouhlasilo 5,9 %.11 ˇ viz [Dohnalová et al., 2003]. dalším informacím o historii neziskového sektoru v CR byla tato publikace vydána v roce 2011, data pocházejí z roku 2009. 9 O tom svˇ edˇcí napˇríklad i fakt, že témˇerˇ 35 % respondentu˚ bylo ve vˇeku 18-24 let, což zˇrejmˇe neodpovídá demografické struktuˇre obyvatelstva. Respondenty vybírali vysokoškolští studenti na základˇe pomˇernˇe benevolentnˇe stanovených kritérií. 10 Podrobné výsledky jsou uvedeny v [Hladká et al., 2009, s. 7-10]. 11 S tezí zcela nesouhlasilo 1,4 %, spíše nesouhlasilo 4,5 %, spíše souhlasilo 49,6 %, zcela souhlasilo 39,0 %, 5,6 % nevˇedˇelo. 7K

8 Aˇ ckoliv

15

Obrázek 1.1.: Názory respondentu˚ na tvrzení související s jejich pˇredstavami o neziskovém sektoru. Zdroj: [Hladká et al., 2009]. • S tvrzením cˇ . 2: „Neziskové organizaci bych rád/a poskytl/a dar, kdybych mohl/a použití penˇez zkontrolovat“ souhlasilo 84,1 % respondentu, ˚ nesouhlasilo 8,4%.12 • S tvrzením cˇ . 3: „Nevˇerˇím neziskových organizacím, proto jim žádný dar neposkytnu“ souhlasilo 10,9 % dotázaných, nesouhlasilo 81,6 %.13 Výsledek napovídá, že u veliké vˇetšiny respondentu˚ není neduvˇ ˚ era k neziskovým organizacím pˇrekážkou pro poskytnutí finanˇcního daru. Pˇresto nelze na základˇe tohoto výsledku zjednodušenˇe tvrdit, že duvˇ ˚ era v neziskový sektor je v tuzemsku vysoká, jak se zdá potvrzovat i šetˇrení STEM [STEM, 2008]. Podle nˇej institucím neziskového sektoru duvˇ ˚ erˇ uje „pouze“ 65 % obˇcanu˚ (z toho ovšem jen 9 % duvˇ ˚ erˇ uje plnˇe). Na druhou stranu je tˇreba poznamenat, že z vyšší duvˇ ˚ ery se podle výzkumu tˇeší již pouze místní úˇrady (tj. obecní, mˇestské cˇ ásti) se 74 %, kdežto krajské úˇrady (63 %), církve (34 %) a politické strany (22 %) v tomto ohledu zaostávají. Rozdíl mezi výsledky obou výzkumu˚ je dán pravdˇepodobnˇe ruznˇ ˚ e položenými otázkami a též nereprezentativností výbˇeru respondentu˚ v pˇrípadˇe publikace [Hladká et al., 2009]. • S tvrzením cˇ . 4: „O lidi, kteˇrí potˇrebují pomoc, se má postarat stát, na to pˇrece platíme danˇe“ souhlasilo 39,8 % respondentu, ˚ nesouhlasilo 47,1 % (viz Obrázek 1.1).14 Z tohoto výsledku vyplývá, že zhruba polovina obˇcanu˚ i nadále oˇcekává, že rozhodující roli pˇri pomoci potˇrebným bude hrát i nadále stát. Z jiné perspektivy zkoumala vztah veˇrejnosti k neziskovým organizacím v roce 2004 agenˇ tura STEM [STEM, 2004]. Výsledky napovídají, že obˇcanská spoleˇcnost v Ceské republice není tak letargická, jak se obecnˇe míní: 47 % dotázaných uvedlo, že je cˇ lenem alesponˇ jedné neziskové organizace. Je však tˇreba mít na pamˇeti, že i zde je použito široké strukturálnˇe12 S

tezí zcela nesouhlasilo 2,2 %, spíše nesouhlasilo 6,1 %, spíše souhlasilo 40,1 %, zcela souhlasilo 44,0 %, 7,5% nevˇedˇelo. 13 S tezí zcela nesouhlasilo 42,3 %, spíše nesouhlasilo 39,3 %, spíše souhlasilo 7,0 %, zcela souhlasilo 3,9 %, 7,5% nevˇedˇelo. 14 S tezí zcela nesouhlasilo 12,8 %, spíše nesouhlasilo 34,3 %, spíše souhlasilo 27,0 %, zcela souhlasilo 12,8 %, 12,8% nevˇedˇelo, jeden respondent neodpovˇedˇel.

16


Obrázek 1.2.: Poˇcet cˇ lenství obˇcanu˚ v ruzných ˚ neziskových organizacích v roce 2004. Zdroj: [STEM, 2004]. operacionální definice neziskového sektoru, takže jde z velké cˇ ásti o organizace sportovní (23 %) a odbory (20 %) a ostatní druhy organizací jsou zastoupeny v menší míˇre. Vývoj cˇ lenství v NNO (nestátních neziskových organizacích) mˇelo pˇritom spíše stagnující charakter: 62 % respondentu˚ zustalo ˚ cˇ leny stejného poˇctu organizací jako pˇred pˇeti lety, 22 % uvedlo, že je cˇ lenem ménˇe organizací, než v pˇredchozím období a pouze 16 % je cˇ lenem více organizací (viz Obrázek 1.2). Ještˇe ménˇe lidí ochotno pro neziskové organizace dobrovolnˇe pracovat, aˇckoliv výzkum zachytil dvojnásobný nárust ˚ dobrovolnické aktivity v porovnání s rokem 2000: 68 % respondentu˚ nebylo nikdy aktivním dobrovolníkem, 16 % odvádˇelo dobrovolnou práci pro jednu NO, 10 % pro dvˇe, 6 % pro tˇri a více organizací. ˇ Pomˇer dárcu˚ na populaci Ceské republiky pak zkoumala prostˇrednictvím dotazníkového šetˇrení v roce 2006 agentura Factum Invenio [Factum Invenio, 2006] a došla ke zjištˇení, že pomˇer jednotlivých dárcu˚ v populaci pozvolna stoupá. Z jejích výsledku˚ je patrné, že v roce 2004 by se za dárce oznaˇcilo 56% respondentu˚ , v roce 2005 dokonce celých 81 % respondentu, ˚ v roce 2006 se pak stav opˇet snížil, avšak na hodnotu vyšší, než byla vykázána v roce 2004: dárcovství pˇriznalo 66 % dotázaných (viz Obrázek 1.3). Výraznˇe pozitivní výkyv ˇ na pˇrírodní z roku 2006 lze podle autoru˚ studie vysvˇetlit jako solidární reakci obˇcanu˚ CR neštˇestí v jihovýchodní Asii, kde vlna tsunami zpusobila ˚ humanitární katastrofu.

1.2.1.2. Financování neziskových organizací Duležitým ˚ ukazatelem stavu neziskového sektoru je dále struktura jeho financování. Vzhledem k tématu relevantní, ale nepˇríliš aktuální studii vydala Nadace Partnerství ˇ [Kepáková et al., 2004]. Tato studie zachycuje stav v roce 2003, tj. ještˇe pˇred vstupem Ceské republiky do Evropské unie. Pruzkum ˚ byl proveden na vzorku 72 neziskových organizací, jejichž oblastí zájmu je životní prostˇredí, a které Nadace Partnerství v minulých letech finanˇcnˇe podpoˇrila. Autoˇri studie nemˇeli k dispozici celkové statistiky finanˇcních pˇríjmu˚ neziskových spoleˇcností, což je pravdˇepodobnˇe duvodem ˚ toho, že elaborát neobsahuje žádné 17

Obrázek 1.3.: Ochota obˇcanu˚ pˇrispˇet finanˇcním darem na charitu v roce 2006. Zdroj:[Factum Invenio, 2006]. konkrétní sumy, ale pouze procentuální vyjádˇrení pomˇeru˚ jednotlivých druhu˚ pˇríjmu. ˚ Podle dokumentu byly v roce 2003 pˇríjmy neziskových organizací relativnˇe diverzifikované, nejvyšší mˇerou se na financování podílely cˇ eské nadace spolu se zahraniˇcními fondy (celkem 38%), jednotliví dárci (pouze 9 %) a firmy (2 %) pak o poznání ménˇe (viz Obrázek 1.4). Mírná vˇetšina organizací (62 %) v roce 2003 disponovala individuálními dárci, vˇetšinou však byl jejich poˇcet nízký - pouze cˇ tvrtina z nich mˇela více než 20 dárcu. ˚ Lze konstatovat, že neziskové organizace (pˇrinejmenším v oblasti péˇce o životní prostˇredí) jsou z velké cˇ ásti závislé na financování z nadací a fondu, ˚ významnou roli zde hraje stát a politické organizace vubec ˚ (30 %). Toto zjištˇení muže ˚ být znepokojující vzhledem k pˇredstavˇe, že neziskový sektor by mˇel být v ideálním pˇrípadˇe na politických strukturách zcela nezávislý. Z uvedené statistiky lze usuzovat na to, jaký podíl mají na financování neziskových spoleˇcností vliv nepolitické subjekty, tj. nadace, individuální dárci a firmy. V pˇrepoˇctu z celého objemu nepolitických pˇríjmu˚ poskytly 78 % financí nadace, 12 % individuální dárci, 6 % tvoˇrily cˇ lenské pˇríspˇevky a pouhá 4 % firmy (viz Obrázek 1.5).

1.2.1.3. Fundraisingové metody Další z hlediska diplomové práce relevantní otázkou je otázka spojená se zpusobem, ˚ jakým tuzemské neziskové organizace využívají fundraisingových metod. Jistou pˇredstavu o této obˇ roce lasti si lze uˇcinit na základˇe dotazníkového šetˇrení, které s 83 úˇcastníky provedla v CR 2008 D. Edward [2008]. Šetˇrení se zúˇcastnili zejména programoví rˇ editelé, cˇ lenové správních rad, pracovníci marketingu a dobrovolníci neziskových organizací. Zveˇrejnˇený dokument je pouze pˇredbˇežnou zprávou, takže u uvedených dat chybí náležitý komentáˇr, proˇcež jejich interpretace bohužel zustává ˚ nejistou. Je navíc faktem, že u každého fundraisingového nástroje je uveden ruzný ˚ poˇcet koneˇcných odpovˇedí, pˇriˇcemž není uveden duvod, ˚ proˇc tomu tak je. Data tedy interpretuji tak, že nˇekteˇrí lidé nemuseli u nˇekterých metod odpovˇedˇet, a to zejména z toho duvodu, ˚ že s pˇríslušnou metodou nemají dostateˇcné zkušenosti. V grafu jsou 18


ˇ v roce 2003 podle cˇ lenu˚ neObrázek 1.4.: Struktura pˇríjmu˚ neziskových organizací v CR ziskových organizací. Zdroj: [Kepáková et al., 2004].

ˇ v roce 2003 od nepolitických subjektu˚ Obrázek 1.5.: Pˇríjmy neziskových organizací v CR (pˇrepoˇcet). Zdroj: [Kepáková et al., 2004].

19

ˇ v roce 2008. Zdroj: [Edward, 2008]. Obrázek 1.6.: Efektivita fundraisingových metod v CR metody seˇrazeny od nejvˇetšího poˇctu odpovˇedí „Efektivní“ po nejnižší. Více vlevo tedy patrnˇe budou umístˇeny metody, které jsou úˇcinné a zárovenˇ efektivní, napravo pak snad ménˇe efektivní, ale pˇredevším ménˇe známé a provˇerˇ ené. Z šetˇrení vyplývá, že za nejefektivnˇejší nástroj pro fundraising je cˇ leny neziskových organizací považován vládní grant (90,36 %), dále projekty cˇ eských nadací (67,47 %) a návštˇevy firemních dárcu˚ (61,45 %). Metody spojené s moderními technologiemi, jako textové zprávy a on-line dárcovství, je možné nalézt na opaˇcné stranˇe spektra. Odpovˇedí bylo v tomto pˇrípadˇe sebráno pˇríliš málo na to, aby výsledek vypovídal nˇeco urˇcitého o skuteˇcné efektivitˇe metody; spíše se ukazuje, že metody jsou neznámé. Z pruzkumu ˚ se proto zdá vyplývat, že v oblasti fundraisingu se neziskové organizace orientují spíše na vˇetší hráˇce, tj. pˇredevším stát, v druhé rˇ adˇe na nadace a firmy (aˇckoliv dopisy zasílané firmám mnozí považují též za neefektivní).

ˇ 1.2.2. Neziskový sektor v zahranicí Pˇri hodnocení neziskového sektoru v zahraniˇcí je tˇreba mít na pamˇeti, že tamní nevládní ˇ organizace mají za sebou obvykle dlouhou a (na rozdíl od CR) kontinuální historii. To se pˇrirozenˇe odráží jak ve velikosti a vyspˇelosti sektoru, tak také v postojích obˇcanu˚ vuˇ ˚ ci filantropii. Podle organizace Charities Aid Foundation, která v roce 2006 vydala studii [CAF, 2006], v níž porovnává podíly celkového objemu daru˚ na HDP v ruzných ˚ vyspˇelých zemích svˇeta, žijí nejštˇedˇrejší dárci na svˇetˇe ve Spojených státech amerických (viz Obrázek 1.7); jejich donace souhrnnˇe dosahují 1, 67 % HDP, což podle podle uznávaných statistických údaju˚ Giving USA Foundation cˇ iní 290,89 miliard dolaru˚ [Giving USA, 2011]. Pozoruhodná je i tamní struktura daru˚ (viz Obrázek 1.8). Témˇerˇ tˇri cˇ tvrtiny všech daru˚ (73%) totiž pochází od individuálních dárcu, ˚ nadace se podílejí pouze 14 %, odkázaný majetek tvoˇrí 8 % a firmy poskytují pouhých 5 % celkového objemu daru˚ (Srovnej s obrázkem 1.5). Další vyspˇelé zemˇe oproti USA již ponˇekud zaostávají: v Británii je pomˇer daru˚ k HDP pouze 0,73 %, v Nizozemí o 0,45%, v Nˇemecku o 0,22 %, ve Francii dokonce jen o 0,14 %. ˇ Ceská republika sice ve srovnání chybí, ale tento nedostatek je možno napravit jednoduˇ ˇ ˇ chým výpoˇctem za užití údaju˚ CSÚ [CSÚ, 2009, CSÚ, 2010], z nˇejž vyplývá, že tuzemští obcˇ ané v roce 2006 poskytli neziskovému sektoru dary ve výši 0,21 % HDP. Rozdíl mezi USA 20


Obrázek 1.7.: Podíl daru˚ neziskovým organizacím na HDP ve vybraných zemích v roce 2006 ˇ ˇ (v procentech HDP). Zdroj: [CAF, 2006, CSÚ, 2009, CSÚ, 2010].

Obrázek 1.8.: Struktura dárcu˚ v USA v roce 2010 (ˇcástky jsou zaokrouhleny a uvádˇeny v miliardách dolaru). ˚ Zdroj: [Giving USA, 2011]. a zbytkem svˇeta je na první pohled zarážející. Autoˇri studie se domnívají,15 že uvedené rozdíly jsou zpusobené ˚ mnoha faktory, mezi nˇež zapoˇcítávají metodologické odlišnosti mˇerˇ ení v jednotlivých zemích, danovou ˇ politiku vlád, religiozitou, ruzným ˚ objemem daru˚ neoficiální povahy, dále národním bohatstvím a kulturními rozdíly. Dalším duležitým ˚ sledovaným ukazatelem je pomˇer dobrovolníku˚ v populaci jednotlivých zemí (viz Obrázek 1.10). Data cˇ erpám z materiálu Evropské komise [EC, 2010] pro zemˇe EU, pro USA vycházím ze studie [Wing, 2010]. Také informace z tˇechto studií je však tˇreba brát s rezervou, protože data z jednotlivých zemí nejsou sbírána za použití stejné metody, ˇ ale zpusob ˚ sbˇeru se (nˇekdy i výraznˇe) liší. V každém pˇrípadˇe nevychází Ceská republika ze srovnání s vyspˇelými státy pˇríliš dobˇre ani v tomto pˇrípadˇe. Dobrovolnictví se zde totiž vˇenuje asi 11 % - 14 % populace.16 Tato hodnota je však pomˇernˇe výraznˇe pod prumˇ ˚ erem EU 15 Viz

[CAF, 2006, s. 7nn.].

16 V pˇríslušném grafu uvádím nižší hodnotu vycházející z poˇ ˇ ctu dobrovolníku˚ uvedeného v [CSÚ,

2010]. Pokud srovnáváme toto cˇ íslo s daty z roku 2004 uvedenými v [STEM, 2004], musíme mít na pamˇeti, že agentura

21

Obrázek 1.9.: Podíl aktuálních dobrovolníku˚ na populaci ve vybraných zemích svˇeta v letech 2004 - 2007. Zdroj:[EC, 2010, Wing, 2010]. (22 % - 23 %). Mnohem lepší než u nás je situace v Anglii (44 %)17 cˇ i sousedním Rakousku (43,8 %), naopak horší v Bulharsku (8 %).

1.2.3. Expertní odhad V situaci jako je tato, kdy pˇreci jen není k dispozici dostatek spolehlivých „tvrdých“ dat, je vhodné provést šetˇrení prostˇrednictvím expertního odhadu, které muže ˚ pˇrinést hluboký vhled do zkoumané problematiky. Takové expertní šetˇrení je k dispozici v [Dohnalová et al., 2003, s. 67-73]. Zmínˇeného expertního šetˇrení vedeného v rámci projektu Civicus Civil Society Index se v roce 2004 zúˇcastnilo témˇerˇ 50 osob z organizací obˇcanské spoleˇcnosti, akademických institucí a státní správy. Úˇcastníci šetˇrení pˇritom pracovali ve cˇ tyˇrech skupinách, pˇriˇcemž každá ze skupin diskutovala jiné otázky. Cílem bylo urˇcit silné ˇ Mezi silné stránky jsou rˇ azeny lidské zdroje, roza slabé stránky neziskového sektoru v CR. manitost organizací s ohledem na cílovou oblast (doménu), v níž jednotlivé organizace pu˚ sobí, cˇ i dobrá schopnost zahajovat veˇrejné diskuze o spoleˇcenských problémech. Z hlediska této práce jsou však zajímavˇejší slabé stránky: • Klientelismus - mnohé organizace cˇ i jejich cˇ lenové zneužívají své postavení k osobnímu zvýhodnˇení • Nepruhlednost ˚ a s ní spjatá nižší duvˇ ˚ era veˇrejnosti - organizace nejsou transparentní s ohledem na zpusob, ˚ jakým používají svˇerˇ ené finanˇcní prostˇredky. • Neschopnost sebe-propagace. • Malé finanˇcní zdroje - neziskové organizace mají obtíže se získáváním finanˇcních zdroju˚ pro svuj ˚ chod. • Neschopnost vzájemnˇe komunikovat a oslovit a mobilizovat veˇrejnost STEM nezjišt’ovala podíl aktuálních dobrovolníku, ˚ ale všech, kdo se kdy dobrovolnické práci vˇenovali. [EC, 2010] neposkytuje data pro celou Británii, ale pouze pro její jednotlivé zemˇe. Pro srovnání používám Anglii.

17 Studie

22


1.2.4. Shrnutí ˇ není dodnes uspokojivˇe zmapován, pˇriˇcemž zjištˇené nedoStav neziskového sektoru v CR statky v této oblasti jsou rázu jak kvantitativního (nízký poˇcet výzkumu), ˚ tak kvalitativního (absence jednoznaˇcné definice a metodiky zkoumání zhoršuje porovnatelnost výsledku, ˚ serióznost a výpovˇední hodnota nˇekterých šetˇrení je povážlivá). Pˇresto mohou získaná data sloužit jako jisté vodítko vypovídající o celkové situaci v oblasti a zejména pak o slabých stránkách, které je možné posílit. Získaná data naznaˇcují, že duvˇ ˚ era veˇrejnosti v neziskový sektor, která pˇrirozenˇe úzce souvisí s transparentností organizací, sice není vyloženˇe nízká, ale je zde stále znaˇcný prostor pro její posilování. Neduvˇ ˚ era se zraˇcí i v hojnˇe zastávaném názoru, že služby poskytované neziskovým sektorem by mˇel spíše poskytovat stát. Relativnˇe vysoká cˇ ást veˇrejnosti pˇrispívá alesponˇ jednou roˇcnˇe na charitativní úˇcely, ale podíl daru˚ neziskovým organizacím na HDP je v porovnání s jinými zahraniˇcními státy relativnˇe nízký. S tím souvisí i struktura financování neziskových organizací u nás - významnou roli hraje stát; jednotlivci v tomto ohledu v mezinárodním srovnání zaostávají. Jako nízký se jeví také podíl cˇ eských dobrovolníku˚ na celkové populaci, v nˇemž výraznˇe zaostáváme též za evropským prumˇ ˚ erem. Velkou neznámou jsou pro neziskové organizace moderní technologie, které je možno využívat pro fundraising, sebeprezentaci a komunikaci s dárci a pˇríznivci. Organizace mají dále nedostatky v sebe-propagaci a musí také zapracovat na schopnosti mobilizovat veˇrejnost.

1.3. Strategický cíl a cíl práce Jsou-li výsledky analýzy souˇcasného stavu neziskového sektoru správné, je na jejich základˇe možno definovat stav požadovaný, tj. cíl, a to na strategické úrovni. Vše nasvˇedˇcuje tomu, že neziskové organizace stojí pˇred následujícími úkoly: • Zlepšit svou transparentnost • Zlepšit duvˇ ˚ eryhodnost • Zvýšit podíl daru˚ jednotlivcu˚ • Získávat dobrovolníky • Zlepšit sebeprezentaci a komunikaci • Mobilizovat veˇrejnost Pozornˇejší pohled na tyto cíle napovídá, že ani v jednom pˇrípadˇe nejde o jádro cˇ innosti neziskových organizací. Lze tedy rˇ íci, že chod neziskových organizací obvykle není optimalizován na rˇ ešení problému˚ tohoto druhu, což otevírá prostor pro úvahy o outsourcingu tˇechto služeb. Cílem práce proto bude s využitím metod procesní analýzy a ve spolupráci s projektem Darujme.cz navrhnout zpusob ˚ fungování platformní organizace, která by mohla organizacím neziskového sektoru zprostˇredkovávat služby, jejichž využíváním mohou neziskové organizace snáze dosahovat zlepšení v oblastech transparentnosti, komunikace s veˇrejností (PR), získávání daru˚ a dobrovolníku˚ a zapojování veˇrejnosti do vlastní cˇ innosti. Analýza organizace tedy odpovídá na otázku, jak by mˇela vypadat organizace, která pˇrispívá k rˇ ešení problému˚ neziskového sektoru poskytováním služeb souvisejících s alokací potˇreb neziskových organizací na stranˇe jedné a jednotlivcu˚ a firem na stranˇe druhé. Analýza bude provedena za úˇcelem pozdˇejšího 23

návrhu pˇríslušného informaˇcního systému a bude tedy definovat základní požadavky na tento systém.

1.4. Známá rˇešení Organizací, které jsou zamˇerˇ eny na usnadnˇení dosahování zmínˇených (ˇci podobných) cílu, ˚ existuje ve svˇetˇe již nˇekolik. Základní pˇrehled tˇech nejzajímavˇejších zahraniˇcních a tuzemských projektu˚ následuje.

ˇ 1.4.1. Zahranicí 1.4.1.1. Kiva (http://www.kiva.com) Aplikace Kiva umožnuje ˇ prostˇrednictvím internetu bezúroˇcnˇe zapujˇ ˚ cit relativnˇe nízkou cˇ ástku (25 dolaru) ˚ vybraným sociálnˇe slabým jedincum ˚ žijícím v rozvojovém svˇetˇe na podporu jejich podnikání a zvýšení jejich konkurenceschopnosti.18 Pujˇ ˚ cka má umožnit tˇemto lidem, aby vzali svuj ˚ život do vlastních rukou a nebyli tolik závislí napˇr. na humanitární pomoci ze zahraniˇcí. Kiva neorganizuje celou transakci samostatnˇe, ale spolupracuje s mikrofinanˇcními institucemi (microfinance institutions), které v daných lokalitách suplují neexistující bankovní sektor. Dárci, resp. vˇerˇ itelé19 se mohou sdružovat do ruzných ˚ skupin, které odpovídají jejich svˇetonázoru, nebo vyjadˇrují jiný duležitý ˚ spoleˇcný rys.20 Pˇríslušnost k té cˇ i oné komunitˇe pusobí ˚ motivaˇcnˇe, nebot’ vˇerˇ itelé svou charitativní akcí posilují svou identitu se skupinou. Mohlo by se zdát, že podobné pujˇ ˚ cky mají jen nízkou návratnost v rˇ ádu procent. Kiva ale uvádí,21 že návratnost je 98,87% a celkový objem pujˇ ˚ cek za dobu její existence pˇresáhl 249 milionu˚ dolaru. ˚

Obrázek 1.10.: Logo služby Kiva. Zdroj: [Kiva, 2011].

1.4.1.2. GiveMeaning (http://www.givemeaning.com/) Give Meaning je online služba na podporu fundraisingu.22 Neziskové organizace i jednotlivci mohou jeho prostˇrednictvím získávat peníze na své projekty. V prvním kroku vloží subjekt (vkladatel) do systému informace o svém projektu, relevantní fotografie a požadovanou cílovou cˇ ástku. Portálová komunita dále podle dostupných informací vložená data ohodnotí ve cˇ tyˇrech kategoriích: a) duležitost ˚ projektu, b) informativnost dat, c), duvˇ ˚ eryhodnost, d) kvalita. Vkladatel zárovenˇ musí bˇehem následujícího mˇesíce od komunity získat alesponˇ 18 Vycházím

z informací uveˇrejnˇených na stránkách Kivy, viz [Kiva, 2011]. oznaˇcení jsou vhodná, nebot’ vˇerˇ itelé se vzdávají nároku na úrok, což lze vnímat jako jistý druh charitativního daru. 20 Na Kivˇ e existují nejen napˇr. Atheisté, Kˇrest’ané, ale též Pˇrátelé Boba Harrise, apod. Viz ibid. 21 Viz ibid. 22 Viz [Give Meaning, 2011]. 19 Obˇ e

24


Obrázek 1.11.: Stránka neziskového projektu na stránce Give Meaning (upraveno). Zdroj: [Give Meaning, 2011]. 100 hlasu, ˚ cˇ ímž jsou obvykle vylouˇceny nesmyslné cˇ i podivné projekty. Pokud je tato podmínka splnˇena, mohou uživatelé portálu na projekt zaˇcít pˇrispívat finanˇcními dary. Duraz ˚ je kladen na spolupráci s pˇrirozenými sociálními sítˇemi, které již kolem projektu˚ existují v reálném svˇetˇe. Úˇcelem je, aby lidé s projektem spojení zapojili své známé, nebot’ u nich je nejvˇetší pravdˇepodobnost, že se budou chtít na projektu finanˇcnˇe podílet, nebo jej doporuˇcí dál. Podmínkou takovéto „virální kampanˇe“ je samozˇrejmˇe existence místa, na nˇemž jsou pro zájemce shromáždˇeny všechny relevantní informace; tím je právˇe web GiveMeaning.com, jehož prostˇrednictvím je pak možné provést i samotnou mikroplatbu. Jakousi obdobou tohoto systému, která je však zamˇerˇ ena na podporu umˇeleckých projektu, ˚ je projekt Kickstarter. V jeho rámci je navíc možno definovat ruzné ˚ odmˇeny, které jsou dárcum ˚ slíbeny, pokud bude projekt realizován. Odmˇenou muže ˚ být takˇrka cokoliv, napˇr. podíl na výstupu projektu (pokud umˇelec natáˇcí hudební CD, dárce obdrží kopii zdarma), nebo vecˇ eˇre s umˇelcem, apod.

1.4.1.3. Network for Good (http://www.networkforgood.org/) Relativnˇe komplexním systémem zamˇerˇ eným na fundraising je i služba nazvaná Network for Good. Svým uživatelum ˚ umožnuje ˇ nejen zaslat jednorázový dar na úˇcet jedné z úˇcastnických organizací, ale zˇrídit též automatické mˇesíˇcní dary. Neziskovým organizacím nabízí tento provozovatel další služby, napˇr. správu kontaktu˚ a emailingový nástroj, správu dárcu˚ s prvky CRM (customer relationship management, tj. péˇce o vztahy s dárci), správu událostí (event management) umožnující ˇ neziskovým organizacím zveˇrejnovat ˇ informace o poˇrádaných akcích a prodávat vstupenky pˇres internet. Network for Good umožnuje ˇ též vedení facebookových kampaní a tzv. friend-to-friend kampaní, u nichž je zvláštní duraz ˚ kladen na komunitní aspekt dárcovství. Efektivita tˇechto kampaní stojí na pˇredpokladu, že skupina lidí, pokud mezi nimi existují jistá pouta (pˇrátelství, známosti, ale napˇr. též cˇ lenství v 25

Obrázek 1.12.: Widget umístitelný na osobní blog dárce (badge) v systému Network for Good Zdroj: [Network for good, 2011].

církvích, apod.), bojují za spoleˇcnou vˇec se silnˇejší motivací, než pouzí jednotlivci. Blízké lidi je též vždy snazší pˇresvˇedˇcit k participaci na neziskových projektech. Dalším prvkem snažícím se využít k fundraisingu vztahy mezi lidmi je jakýsi dárcovský widget (badge), který si dárci mohou umístit na svuj ˚ osobní blog cˇ i stránky. Smyslem widgetu je informovat pˇrátele dárce o jeho filantropické aktivitˇe a pˇresvˇedˇcit je, aby se do ní též zapojili. Na widgetu je uvedeno, kolik se již na vybraný neziskový projekt vybralo, dále je zde zobrazena fotografie dárce a text vysvˇetlující, proˇc se k dané iniciativˇe rozhodl pˇripojit. Widget dále obsahuje tlaˇcítko umožnující ˇ pˇrímo elektronicky darovat a volitelnˇe též uživatelské video, na nˇemž muže ˚ dárce své motivy vysvˇetlit v zcela názornˇe.

1.4.1.4. Swipe Good (http://www.swipegood.com/) Inovativní projekt je provozován i na webu Swipe Good.23 Dárci zde zaregistrují svou kreditní kartu, z níž je jim od té chvíle pˇri každé karetní transakci odeˇctena urˇcitá cˇ ástka putující na charitativní úˇcely.24 Dárce si muže ˚ vybrat, na jaký dobroˇcinný projekt chce svými penˇezi pˇrispˇet a muže ˚ též stanovit horní limit pro mˇesíˇcní objem daru. ˚ Nutno poznamenat, že pˇríˇ padné nasazení obdobné služby v CR se alesponˇ v souˇcasné dobˇe zdá zhola nemožné, a to ze dvou duvod ˚ u: ˚ a) hodnota jednoho dolaru je nˇekolikanásobnˇe vyšší, než hodnota jedné koruny, což znamená, že i výtˇežek z transakce by byl v prumˇ ˚ eru nˇekolikanásobnˇe nižší a b) obˇcané jsou znaˇcnˇe opatrní na údaje uvedené na kreditní kartˇe a pˇresvˇedˇcit je k zadání tˇechto údaju˚ do internetového formuláˇre a umožnit tak portálu takˇrka libovolný pˇrístup k osobnímu úˇctu je témˇerˇ nemožné. 23 Viz

[Swipegood, 2011]. cˇ ástka je rovna rozdílu mezi skuteˇcnou cenou zakoupeného produktu a zaokrouhlením této cˇ ástky nahoru. Vlastníkovi karty se tedy každý jeho dar jeví jako zaokrouhlení jeho nákupu na nejbližší vyšší celé cˇ íslo.

24 Tato

26


Obrázek 1.13.: Schéma vysvˇetlující zpusob ˚ fungování portálu Swipe Good. Zdroj: [Swipegood, 2011]. 1.4.1.5. Ten In Three (http://www.teninthree.com/) Zajímavou alternativou k pˇredchozím webum ˚ je též chystaný projekt Ten in Three.25 Jeho uživatelé totiž nebudou pouze dárci, ale stanou se zárovenˇ propagátory a fakticky též vudci ˚ projektu, jehož cílem je postavit školu v nˇekteré z rozvojových zemí. Pokud se nˇekdo rozhodne zapojit, vybere si nejprve, kde chce školu nechat postavit. Pak obešle 32 svých pˇrátel s personalizovaným videem, které sám natoˇcí a v jehož rámci ze jich zeptá, zda se chtˇejí k jeho snaze pˇripojit pravidelným každodenním darem 3,33 dolaru˚ po dobu 3 mˇesícu. ˚ Takto vzniklá skupina bude mít na stránkách svuj ˚ profil s fotkami zúˇcastnˇených. Služba se pokouší využít principu, ˚ které jsou podle jejího vlastníka (Taylor Conroy) z hlediska fundraisingu klíˇcové - využívá znalostí o zpusobu ˚ chování lidí ve skupinˇe, technologie mikroplateb, blízkého spojení pˇrátel v týmu, hmatatelnosti výsledku a toho, že lidé touží po tom, ˇ aby si ostatní všimli toho, co dˇelají. Aˇckoliv jde o projekt, který je snad v podmínkách CR (alesponˇ v souˇcasné dobˇe) jen obtížnˇe pˇredstavitelný, využívá ve vysoké míˇre principu˚ podminujících ˇ úspˇešný fundraising a je proto duležitým ˚ pˇríkladem, z nˇejž je možné se pouˇcit.

1.4.1.6. Easiest Give (http://www.easiestgive.com/) Projekt Easiest Give26 je patrnˇe urˇcen lidem, kteˇrí sice chtˇejí darovat cˇ ást svých finanˇcních prostˇredku˚ na dobroˇcinnost v sociální oblasti (péˇce o bezdomovce, domovy pro seniory, apod.), ale chtˇejí též zcela konkrétnˇe vˇedˇet, na jaké vˇeci budou peníze urˇceny. Služba totiž neziskovým organizacím umožnuje ˇ vytvoˇrit e-shop a definovat vˇeci bˇežné potˇreby, které potˇrebují pro svuj ˚ chod (napˇr. hygienické potˇreby, obleˇcení, apod.). Dárci poté mohou v takto definovaném e-shopu potˇrebné vˇeci pro organizaci nakoupit. Souˇcástí služby je i dovážka zboží, takže neziskové organizace penˇežními cˇ ástkami vubec ˚ nemohou disponovat, ale využívají pouze získané pˇredmˇety, které odpovídají jejich potˇrebˇe, což znemožnuje ˇ zneužití daru˚ a zvyšuje tak transparentnost celého procesu darování. Provoz podobného systému je evidentnˇe pomˇernˇe nároˇcný na logistiku a muže ˚ též zatˇežovat organizace do projektu zapojené, nebot’ pˇrísun zakoupeného zboží muže ˚ být nárazový a nemusí odpovídat aktuální potˇrebˇe subjektu, ˚ cˇ ímž vznikají dodateˇcné náklady na uskladnˇení, apod. 25 Tato

služba ještˇe nebyla spuštˇena. Proto též cˇ erpám z náhradního zdroje [Springwise, 2011]. psaní této práce byl server bohužel nedostupný. Proto informace cˇ erpám z náhradního zdroje [Springwise, 2011].

26 Bˇ ehem

27

1.4.1.7. Giftcards for Causes (http://www.causes.com/giftcard) K fundraisingu je využíváno též dárkových karet. Ty fungují na jednoduchém principu: tištˇené karty jsou k dispozici v distribuˇcní síti (obchody s potravinami, novinové stánky, apod.) a mohou sloužit jako dárek zvláštního druhu. Obdarovaný totiž nedostane nic jiného, než možnost darovat jistou finanˇcní cˇ ástku na neziskový projekt, který si sám zvolí. Na každé kartˇe je umístˇeno unikátní identifikaˇcní cˇ íslo, které obdarovaný vloží do systému, proˇcež je mu umožnˇeno zakoupenou cˇ ástku darovat. Takto postavený systém patrnˇe vzhledem ke své povaze nezpusobí ˚ veliký prulom ˚ na fundraisingovém poli, nebot’ dobrovolný dar na charitativní úˇcely má, jak se zdá, smysl pouze pro toho, kdo na nˇej finanˇcní prostˇredky skuteˇcnˇe reálnˇe vynaloží a obdarovaný se navíc muže ˚ cítit o cosi podstatného ochuzen, nebot’ jediná jeho aktivita spoˇcívá de facto v zacílení urˇcitého penˇežního objemu. At’ už je tomu s tˇemito dary jakkoliv, v každém pˇrípadˇe jde pˇrinejmenším o doklad toho, že zahraniˇcní subjekty poskytující služby neziskovým organizacím jsou cˇ asto velmi vynalézavé. 1.4.1.8. Projekt „Cena Grahama Mahera“ Dalším relativnˇe cˇ asto používaným zpusobem ˚ redistribuce finanˇcních prostˇredku˚ ve prospˇech neziskových subjektu˚ za použití informaˇcních technologií je internetové hlasování o grantech. Princip je jednoduchý: nadace cˇ i firma (dále též vypisovatel) vypíše grantové rˇ ízení, do nˇejž mohou neziskové organizace pˇrihlašovat své projekty. Ty jsou posléze prezentovány na internetu a sociálních sítích, kde je umožnˇeno všem uživatelum ˚ pro jednotlivé projekty hlasovat. Projekt, který získá nejvíce uživatelských hlasu, ˚ získá též grant. Vypisovatel grantu tˇeží z tohoto postupu nemalé výhody: grantové rˇ ízení je totiž ve své podstatˇe urˇcitou formou virální kampanˇe, nebot’ samotní uživatelé se snaží povˇedomí o grantovém rˇ ízení (a tím též o vypisovateli) sami co nejvíce rozšíˇrit. Z hlediska celkových nákladu˚ tak muže ˚ v dusledku ˚ jít o velmi výhodnou reklamní kampanˇ sloužící k propagaci vypisovatele a zlepšující jeho celospoleˇcenský obraz, nebot’ u konzumentu˚ dochází k propojení znaˇcky firmy (resp. nadace) s konkrétním vítˇezným dobroˇcinným projektem. Princip hlasování též vzbuzuje u uživatelu˚ dojem „demokratiˇcnosti“ a podporuje tak pˇredstavu, že hlasování je „spravedlivˇejší“. Faktem však zustává, ˚ že pˇri této metodˇe výbˇeru jsou zvýhodnˇeny organizace s vˇetší sociální sítí pˇríznivcu. ˚ Kritériem, podle nˇejž se rozhoduje, je tak kvantita jednotlivcu˚ navázaných na strukturu té které organizace. Je zˇrejmé, že takové kritérium muže ˚ být znaˇcnˇe problematické s ohledem na kvalitu vítˇezného projektu a ne vždy je proto koneˇcné rozhodnutí efektivní. Pˇríkladem grantového rˇ ízení muže ˚ být napˇr. mezinárodní Cena Grahama Mahera (Grahame Maher Award), v jejímž rámci o vítˇezství soutˇeží neziskové organizace z celého svˇeta.27 Všechny pˇrihlášené projekty nejprve projdou prvním kolem, jehož obsahem je zodpovˇezení nˇekolika jednoduchých otázek týkajících se základních informací o projektu. Z každé zemˇe jsou poté porotou vybrány tˇri vyhovující projekty, které podstoupí veˇrejné hlasování, a to nejprve na národní, posléze na mezinárodní úrovni. Tˇri projekty s celosvˇetovˇe nejvyšším poˇctem hlasu˚ nakonec postoupí do finále, kde mezinárodní porota vybere vítˇeze, který získá 100 000 liber a k tomu navíc roˇcní stipendium pro zamˇestnance z praxe, aby pomohl projekt realizovat. Systém použitý v rámci tohoto grantového rˇ ízení zjevnˇe vykazuje urˇcitou snahu 27 V

této sekci podávám pouze základní náˇcrt grantového rˇ ízení. Pro více informací viz [GMA, 2011].

28


organizátoru˚ omezit hlasování s jeho negativními rysy a kombinovat jej s rozhodováním poroty, což snad muže ˚ zvýšit šance menších organizací na postup.

1.4.2. Tuzemsko ˇ I v Ceské republice existují snahy využít informaˇcních technologií pro podporu dárcovství, aˇckoliv tuzemsko v této oblasti oproti zahraniˇcním službám ponˇekud zaostává. V souˇcasné dobˇe jsou v provozu dvˇe služby: Darujme.cz a Darujspravne.cz. 1.4.2.1. Darujme.cz Projekt Darujme je provozován nadací Via a budu se mu detailnˇeji vˇenovat i v následující kapitole, nebot’ jde o projekt, k jehož významnému rozšíˇrení by mˇela pˇrispˇet i tato diplomová práce. Portál poskytuje neziskovým organizacím pˇrístup k softwaru prostˇrednictvím projektu TechSoup,28 konzultace v oblasti CRM (customer relations management) a v neposlední rˇ adˇe též službu elektronického fundraisingu. Tato služba umožnuje ˇ uživatelským organizacím umístit na své stránky widget, tj. malou webovou aplikaci, prostˇrednictvím níž mohou dárci provést elektronickou platbu ve zvolené výši na úˇcet neziskové organizace, a to za použití moderních platebních metod.29

Obrázek 1.14.: Widget služby Darujme.cz, pˇríklad pochází ze stránek nadace Via. Zdroj: [Via, 2011].

1.4.2.2. Darujspravne.cz V jistém smyslu konkurenˇcní službou je Darujspravne.cz,30 která je provozována Fórem dárcu. ˚ Ten oproti Darujme.cz nabízí navíc katalog zapojených neziskových organizací a užiteˇcné informace o nich, dále jakousi burzu nabídek dobrovolné práce. Implementuje dále platbu pomocí internetové penˇeženky PaySec, kterou Darujme.cz nenabízí. Na stránkách tohoto portálu je možné najít též rubriku obsahující novinky z oblasti neziskového sektoru. Co více, projekt do své cˇ innosti v jistém smyslu zapojuje též celebrity: na hlavní stránce služby se totiž zobrazují jejich tváˇre, vedle nichž se nacházejí odpovˇedi na ruzné ˚ otázky, které se však neváží nutnˇe k filantropii,31 ale pˇresto patrnˇe pˇritahují (nebo alesponˇ mají pˇritahovat) 28 TechSoup

je mezinárodní neziskový projekt, jehož prostˇrednictvím mohou neziskové organizace poˇrizovat software až s 90% slevou. Strategickými partnery tohoto projektu jsou spoleˇcnosti GiftWorks, Microsoft a SAP. Viz [Darujme.cz, 2011]. 29 V dobˇ e psaní této práce je funkˇcní pouze platba platební kartou a pˇrevod na úˇcet. Viz [Darujme.cz, 2011] 30 Viz [Darujspravne.cz, 2011]. 31 Jednou z otázek je napˇr.: „Pijete cˇ eské pivo? A pokud ano, jak cˇ asto?“

29

Obrázek 1.15.: Vrchní cˇ ást úvodní stránky projektu Darujspravne.cz (výˇrez). Zdroj: [Darujspravne.cz, 2011]. pozornost potenciálních dárcu. ˚ Celkovˇe jde o projekt relativnˇe vyzrálý, s vysokou pˇridanou hodnotou pro neziskový sektor a je do nˇej zapojeno pˇres 170 organizací.

1.5. Pˇrínos nového rˇešení Tato diplomová práce byla vytvoˇrena ve spolupráci s projektem Darujme.cz a jejím pˇrínosem bude pˇredevším v reálném svˇetˇe aplikovatelná analýza podstatného rozšíˇrení této služby. Práce muže ˚ sloužit nejen jako jakýsi manuál pro návrháˇre a vývojáˇre, ale též jako informaˇcní materiál pro grantové komise rozhodující o udílení finanˇcních prostˇredku. ˚ Cílem je navrhnout systém tak, aby poskytoval pˇrínosnou funkcionalitu zamˇerˇ enou na podporu ˇ dárcovství, která muže ˚ najít uplatnˇení u neziskových organizací nejen v Ceské republice, ale též v regionu stˇrední a východní Evropy. Projekt, dojde-li k jeho realizaci, bude klást duraz ˚ na sjednocení a integraci ruzných ˚ fundraisingových metod v jeden funkˇcní celek, zohlední sociální aspekt dárcovství a nutnost motivace dárcu. ˚ Nabídne navíc další služby zamˇerˇ ené na podporu neziskového sektoru.

30

ˇ analytické metody 2. Specifikace cílu˚ a výber V této kapitole provedu nejprve detailnˇejší analýzu výše uvedených (viz 1.3) strategických cílu, ˚ pˇriˇcemž naˇcrtnu pˇredevším prostˇredky vedoucí k jejich dosažení. Nalezené prostˇredky se stanou základním materiálem pro detailnˇejší procesní analýzu organizace zamˇerˇ ené na rˇ ešení nˇekterých problému˚ neziskového sektoru, zejména na optimalizaci vzájemné alokace filantropických potˇreb firem a veˇrejnosti na stranˇe jedné a nabídky neziskových projektu˚ na stranˇe druhé. Má-li být provedena procesní analýza, je v první rˇ adˇe nutné zvolit z dostupných pˇrístupu˚ ten nejvhodnˇejší pro daný úkol. Bezprostˇrednˇe následovat proto bude struˇcné pojednání o nejznámˇejších souˇcasných metodikách procesní analýzy, mezi nˇež patˇrí ARIS, BSP, ISAC, DEMO a (pˇrinejmenším v tuzemských podmínkách též) MMABP a provedu výbˇer té nejvhodnˇejší pro následnou práci.

2.1. Detailní specifikace cílu˚ Detailní specifikace cílu˚ spoˇcívá pˇredevším v nalezení prostˇredku˚ k jejich dosažení. Prostˇredky urˇcené k dosažení strategických cílu˚ uvedených v sekci 1.3 jsou specifikovány v následující tabulce (viz Tabulka 2.1):

Tabulka 2.1.: Detailní specifikace cílu. ˚ Strategický cíl

Prostˇredky dosažení cíle

Zlepšení transparentnosti

- Umožnit dárcum ˚ darovat finanˇcní obnos nikoliv pouze neziskové organizaci jako celku, ale též pˇrímo na podporu jejích konkrétní projektu. ˚ - Posílit zpˇetnou vazbu, (napˇr. prostˇrednictvím novinek o prubˇ ˚ ehu projektu zasílaných všem dárcum). ˚

Zlepšení duvˇ ˚ ery veˇrejnosti

- Podat dostateˇcné informace o zúˇcastnˇených organizacích a jejích cˇ lenech, pˇríznivcích, dobrovolnících, cˇ lenech, projektech, akcích, atd. - Provádˇet peˇclivý výbˇer organizací pˇri registraci. - Vázat dary na konkrétní události (projekty, akce, vstupné) a pˇredmˇety (upomínkové a reklamní pˇredmˇety, jež které mohou dárci za dar získat).

31

Zvýšení podílu daru˚ jednotlivcu˚ a motivace k pravidelnému dárcovství

- Maximálnˇe zjednodušit proces darování. - Umožnit neziskovým organizacím snadno odmˇenovat ˇ dárce za jejich filantropii. - Podporovat friend-to-friend kampanˇe, tj. umožnit uživatelum, ˚ aby se podíleli nejen na samotném dárcovství, ale též na propagaci projektu. - Vytvoˇrit v dárcích pocit zapojení v projektu. - Motivovat dárce skrze dosahování ruzných ˚ odmˇen za jejich dary. - Umožnit dárcum ˚ sdružovat se do komunit podle jejich zájmu˚ a uˇcinit tak z dárcovství „spoleˇcnou vˇec“.

Získávání dobrovolníku˚

- Umožnit neziskovým organizacím snadno získávat dobrovolníky (napˇr. pˇres standardizovaný elektronický formuláˇr). - Vytvoˇrit z nabídek práce neziskových organizací souborný katalog dobrovolníku. ˚ - Podporovat firemní dobrovolnictví.

Zlepšení sebeprezentace a

- Umožnit organizacím budovat „sociální sít’“ pˇríznivcu. ˚

komunikace

- Integrovat do systému používané komunitní sítˇe (zejm. sít’ Facebook).

Mobilizování veˇrejnosti

- Umožnit vznik elektronických petic.

ˇ analytické metody 2.2. Výber 2.2.1. Motivy užití procesní analýzy Analýza organizace, jakožto pokus o diskurzivní pochopení jejích jednotlivých cˇ ástí, z nˇehož posléze vychází také pochopení systému jako celku, je vždy zásadním zpusobem ˚ ovlivnˇeno prismatem, jímž na organizaci nahlížíme. Toto prizma se však v prubˇ ˚ ehu let promˇenuje, ˇ a to v silné vzájemné korelaci se zmˇenami ve zpusobu ˚ rˇ ízení organizace.1 Tato promˇena paradigmatu rˇ ízení je pˇritom dána pˇredevším zmˇenami tržního prostˇredí, v nˇemž se organizace ˇ pohybují. Repa v [2007, s. 18-23] shrnuje tento kontinuální proces do nˇekolika zásadních bodu. ˚ 2 Zásadním rozdílem mezi osmnáctým stoletím a dneškem je podle nˇej nasycenost poptávky. Zatímco v období vzniku kapitalismu a v jeho industriální éˇre firmy snadno nacházely odbyt pro své produkty a jednotlivý zákazník tak byl relativnˇe snadno nahraditelný, což firmám umožnovalo ˇ vyrábˇet unifikovaný produkt, dnes je situace pˇresnˇe opaˇcná: trh je nasycený, zákazník není tak snadno nahraditelný, pˇrevládá orientace na služby a produkt je tak tˇreba diverzifikovat mnoha jinými zpusoby, ˚ než je pouhá cena. Organizace jsou proto nuceny vyrábˇet produkty (resp. poskytovat služby) v mnoha odlišných variantách, aby uspokojily co nejširší spektrum zákazníku˚ a odlišily se od konkurence, což celý proces podnikání znaˇcnˇe komplikuje. Dalším duvodem ˚ neudržitelnosti tradiˇcního industriálního paradigmatu je jeho rigidita, tj. malá schopnost zmˇeny. Doba vývoje výrobku˚ je totiž v dnešní dobˇe neustále zkracována, produkty jsou inovovány, turbulentnost prostˇredí roste, což vytváˇrí silný tlak na neustálé pˇrizpusobování ˚ se mˇenícím se podmínkám. Zatímco tradiˇcní rˇ ízení industriálního období si (zjednodušenˇe rˇ eˇceno) vystaˇcilo s dˇelbou práce na jed1

Je nepochybné, že osmnácté století nahlíželo na podnik a jeho dynamiku zásadnˇe jiným zpusobem, ˚ než jakým jsou chápány dnes. 2 Tento nástin považuji pro úˇ cely této práce za dostateˇcný. Detailnˇejší analýzu duvod ˚ u˚ zmˇeny paradigmatu podává napˇr. [Šmída, 2007, s. 18-39].

32

2. Specifikace cílu˚ a výbˇer analytické metody

noduché opakovatelné operace a pevnou organizaˇcní strukturou, dnešek vyžaduje pˇrístup mnohem komplexnˇejší, který však zohlední nutnost diverzifikace a kontinuální zmˇeny. Odpovˇedí na popsaný vývoj je procesní rˇízení, resp. procesní zpusob ˚ pohlížení na organizaci. To pohlíží na organizaci pˇredevším jako na prostˇredí, v jehož rámci probíhají jisté standardizované procesy, které je tˇreba rˇ ídit první rˇ adˇe. Podle [Šmída, 2007, s. 30] procesní rˇ ízení pˇredstavuje: „[..] systémy, postupy, metody a nástroje trvalého zajištˇení maximální výkonnosti a neustálého zlepšování podnikových i mezipodnikových procesu, ˚ které vycházejí z jasnˇe definované ˇ strategie organizace a jejichž cílem je naplnit stanovené strategické cíle.“ Repa pak v [2007, s. 21] výše uvedené doplnuje ˇ poukazem na nutnou orientaci procesu˚ na potˇreby zákazníka. Procesní paradigma mj. pˇredpokládá, že organizace se vzdá tradiˇcního hierarchického schématu a pˇristoupí k delegování pravomocí z vedoucích pracovníku˚ na všechny zamˇestnance, kteˇrí hrají v rámci procesu˚ role tyto pravomoci vyžadující. Zákazníkova potˇreba tak urˇcuje proces, potˇreba procesu urˇcuje organizaci. S jistou dávkou opatrnosti tak lze rˇ íci, že je-li procesní rˇ ízení adekvátní odpovˇedí na soucˇ asné potˇreby trhu, zdá se také, že procesní analýza je zpusobem ˚ vedoucím k adekvátnímu porozumˇení souˇcasné organizaci, která se pohybuje na trzích 21. století.3 Bylo by však mylné domnívat se, že adekvátnost procesní analýzy je omezena na organizace korporátní, tj. zˇrizované primárnˇe za úˇcelem zisku, protože na trzích se pohybují také organizace neziskového sektoru a v neposlední rˇ adˇe též státní. Metod urˇcených pro procesní analýzu pak existuje celá rˇ ada, pˇriˇcemž každá z nich je obvykle urˇcena k urˇcitému úˇcelu. Na následujících rˇ ádcích provedu zcela elementární charakteristiku tˇech nejznámˇejších metodik procesního modelování (resp. procesní analýzy) a vyberu tu, která bude nejlépe vyhovovat potˇrebám tohoto projektu. V celém zbytku této ˇ kapitoly budu vycházet pˇredevším z údaju˚ uvedených v [Repa, 2007].4

2.2.2. ARIS Metodika ARIS (Architecture of Integrated Information Systems) prof. Scheera pohlíží na organizaci skrze pˇet pohledu, ˚ pˇriˇcemž pohled lze obecnˇe chápat jako soubor modelu˚ zobrazujících urˇcitý podstatný aspekt organizace: • Pohled organizace (Organization View) - obsahuje modely týkající se organizaˇcní struktury zkoumané organizace. • Pohled funkˇcní (Function View) - modeluje funkce systému. • Pohled datový (Data View) - modeluje datovou strukturu systému. • Pohled na zdroje (Resource View) - zohlednuje ˇ pˇredevším dostupné zdroje IT v širokém slova smyslu. • Pohled kontrolní (Control View) - obsahuje model rˇ etˇezu procesu˚ (process chain model), model datových toku˚ (data flow diagram), model kontroly událostí (event control). Pˇredstavu o základním schématu pohledu˚ si cˇ tenáˇr muže ˚ uˇcinit z následujícího diagramu (viz Obrázek 2.1): 3 To

je také duvodem, ˚ proˇc k analýze organizace použiji analýzu jejích procesu. ˚

4 Jde o pouze o základní nástin jednotlivých metod. Ctenáˇ ˇ re, jenž je s touto problematikou detailnˇeji seznámen,

nemuže ˚ proto následující sekce pˇríliš informaˇcnˇe obohatit, proˇcež jej odkazuji na již zmínˇenou publikaci ˇ [Repa, 2007], nebo na podobnˇe zamˇerˇ enou knihu [Kunstová et al., 2003].

33

Obrázek 2.1.: ARIS architektura. Zdroj: [Pera, 2012]. Každý z pohledu˚ se dále dˇelí na tˇri úrovnˇe v souladu s principem tˇrí úrovní abstrakce, tj. na úrovenˇ konceptuální, technologickou a fyzickou. Je zˇrejmé, že duležitou ˚ úlohou analytika je pokusit se o harmonizaci všech zmínˇených pohledu, ˚ což jedinˇe muže ˚ zajistit kvalitu z analýzy vycházejícího návrhu informaˇcního systému. Jde o metodiku velmi robustní, nebot’ se skládá ze 105 ruzných ˚ druhu˚ modelu. ˚ Ty lze vytvoˇrit v nˇekterém z poskytovaných poˇcítaˇcových nástroju, ˚ které jsou zaˇrazeny do jedné ze tˇrí platforem (platformy jsou jakýmsi souborem nástroju˚ pro ruzné ˚ fáze vývojového cyklu aplikace): • Platforma návrhu (ARIS Design Platform) - umožnuje ˇ modelování procesu. ˚ Jde o platformu, která je ve fázi analýzy systému obzvláštˇe relevantní. • Platforma pro implementaci (ARIS Implementation Platform) obsahuje nástroje usnadnující ˇ realizaci návrhu. • Platforma pro controlling (ARIS Controlling Platform) - zajišt’uje rˇ ízení a optimalizaci podnikových procesu. ˚

2.2.2.1. Modely Metodiky mívají rozliˇcná cˇ lenˇení, ale v jádru jsou vždy pˇredevším odpovˇedí na otázku, jaký model má být v té které fázi analýzy využit. Základem metodiky ARIS jsou modely procesní, které lze rozdˇelit do nˇekolika kategorií podle úrovnˇe abstrakce; konkrétnˇe jde o modely a) úrovnˇe pˇrehledové, b) úrovnˇe procesu, c) úrovnˇe podprocesu˚ a d) úrovnˇe cˇ inností. Výsek cˇ ásti procesního modelu ARIS je možné vidˇet na obrázku (viz Obrázek 2.2): Za detailnˇejší zmínku ovšem stojí též následující diagramy: • Diagram rˇetˇezu pˇridané hodnoty (Value Added Chain) - tento diagram slouží k obecnému popisu funkcí, které se podílejí na tvorbˇe pˇridané hodnoty. Jde o základ analýzy, nebot’ proces tvoˇrení pˇridané hodnoty je považován za esenciální pro existenci celého podniku. 34


ˇ Obrázek 2.2.: Cást procesního modelu ARIS. Zdroj: [ARIS, 2012]. • ERM - jde fakticky o rozšíˇrení klasického ER diagramu o jisté prvky modelu tˇríd, konkrétnˇe o agregaci, generalizaci, atd. • eEPC - pomocí tohoto diagramu je možné na detailní úrovni modelovat procesy. Mezi další významné diagramy patˇrí diagram znalostí, dokumentace, produktu˚ a služeb, podnikových cílu, ˚ atd. Z tohoto nástinu je patrné, že metodika pokrývá relativnˇe široké pole pusobnosti ˚ a pˇredstavuje skuteˇcnˇe komplexní rˇ ešení analytického problému.

2.2.2.2. Zhodnocení Metodika ARIS patˇrí k nejvýznamnˇejším metodikám zamˇerˇ eným na procesní modelování (aˇckoliv se na nˇej zdaleka neomezuje). Uznání zasluhuje zejména komplexní pojetí všech aspektu˚ procesního modelování, podpora modelování poˇcítaˇcovými nástroji a detailní propracovanost všech metod. Díky své komplexnosti je patrnˇe urˇcena pˇredevším pro analýzu organizací vˇetších rozmˇeru. ˚ Jisté problémy však muže ˚ pˇrinést pojetí dostateˇcnˇe nerozlišující mezi událostmi a stavy procesu (obé spadá pod jediný meta-objekt), což se stalo též oprávnˇeným terˇcem kritiky. Jako urˇcitá nevýhoda metodiky muže ˚ být nahlížen též fakt, že vˇetšina jejích modelu˚ nepˇredpokládá tvorbu diagramu˚ za použití standartu UML (aˇckoliv existují též výjimky), takže užitá notace nemá status prumyslového ˚ standartu.

2.2.3. BSP Další velmi rigorózní a obsáhlou metodou je Business System Planning (BSP). Ta vznikla v roce 1981 ve firmˇe IBM a možnosti jejího použití jsou rozsáhlé, nebot’ se snaží poskytnout totální pohled na informaˇcní potˇreby organizace a poskytuje nástroje, jak tyto potˇreby op35

timálnˇe naplnit. Postupuje celkem ve 14 krocích, avšak nejcennˇejší jsou z pohledu analýzy procesu˚ pˇredevším kroky 4-7 souhrnnˇe nazvané jako Analýza organizace.5 Ve cˇ tvrtém kroku jde o explikaci podnikových strategií. Výstupem tohoto kroku je seznam strategických cílu˚ podniku a strategií, jak tˇechto cílu˚ dosáhnout. Strategie je pˇritom vhodné definovat tak, aby bylo možno definovat procesy s nimi spojené. Výstupem pátého kroku je seznam všech zásadních procesu˚ ve firmˇe, v první rˇ adˇe tˇech, které jsou pro její chod nejduležitˇ ˚ ejší. Duraz ˚ se pˇritom klade na procesy produkující výrobky a služby, které jsou jedineˇcné, tj. které odlišují podnik od konkurence. Za každý proces by pˇritom mˇelo odpovídat právˇe jedno funkˇcní místo (resp. organizaˇcní jednotka). V šestém kroku dochází k definování tˇríd dat. Data, s nimiž podnik pracuje, se sdružují do logických celku˚ (tˇríd) a dochází též k mapování vazeb mezi tˇemito celky. Podstatný je fakt, že kritériem tohoto tˇrídˇení je jejich pˇríslušnost k jednotlivým procesum. ˚ Sedmý krok znamená provedení analýzy souˇcasného stavu informaˇcního systému a obecnˇe všech aplikací IT v organizaci používaných k podpoˇre podnikových procesu. ˚ Dalším (devátým) krokem je projednání dosavadních výsledku˚ s vedením, na což navazuje koneˇcná formulace závˇeru˚ analýzy (desátý krok). 2.2.3.1. Zhodnocení Metoda BSP je velmi obsáhlá a snaží se pokrýt co nejvíce aspektu˚ analýzy organizace, z cˇ ehož plynou též její silné a slabé stránky. Výhodou je její obecná použitelnost, nevýhoˇ dou vysoké náklady na osvojení metody a nutnost generovat obsáhlou dokumentaci. Repa upozornuje ˇ též na fakt, že BSP v souladu s dobou, kdy vznikla, pˇríliš smˇešuje procesní modelování a procesní rˇ ízení.6

2.2.4. ISAC Metoda Information System Work and Analysis of Change (ISAC) byla vyvinuta ve Švédsku, a to již v roce 1971, používá se pˇredevším ve Skandinávii a Severní Americe a zamˇerˇ uje se na vývoj informaˇcního systému v jeho poˇcáteˇcních fázích, pˇredevším s ohledem na hledání pˇríˇcin problému˚ a jejich následné rˇ ešení.7 Vývoj informaˇcního systému pˇritom nemusí být vyhodnocen jako optimální rˇ ešení daného problému, ale pˇristupuje se k nˇemu pouze v pˇrípadˇe, že pˇredstavuje nejlepší z možných variant a znamenal by signifikantní efektivizaci lidské organizace. Metoda poˇcítá se širokým zapojením uživatelu˚ do procesu zlepšování její autoˇri se totiž domnívají, že právˇe uživatelé vˇedí nejlépe, jak daný proces zmˇenit. Metoda má pˇet fází: 1) analýza požadavku˚ na zmˇeny, 2) studie cˇ inností, 3) informaˇcní analýza, 4) návrh systému, 5) úprava prostˇredí, avšak analytické (a tím pádem též relevantní) jsou pˇritom pouze první tˇri. V první fázi je vytvoˇren seznam problému, ˚ jsou analyzovány se na rˇ ešení problému zainteresované skupiny a jsou popsány podnikem provádˇené cˇ innosti. Následuje vytvoˇrení hie5 Ostatní

kroky se zabývají spíše procesním rˇ ízením, což je však v rozporu se souˇcasným paradigmatem, v jehož rámci bývá k obˇema sférám pˇristupováno oddˇelenˇe. 6 Viz [Repa, ˇ 2007, s. 84]. Zárovenˇ však tvrdí, že nejde o zásadní pˇrekážku jejího používání, nebot’ tyto dvˇe dimenze je možné od sebe relativnˇe jednoduše oddˇelit. 7 Viz [Lundeberg et al., 1981].

36


rarchicky uspoˇrádaného souboru tzv. A-grafu˚ (grafu˚ cˇ inností), které jsou jakousi obdobou diagramu datových toku, ˚ ale navíc kromˇe dat obsahují též fyzické objekty (suroviny, zásoby, zboží, atd.) a neobsahují místa uložení dat (data store) a prvky okolí systému. Následuje popis cílu˚ jednotlivých zainteresovaných skupin, posouzení souˇcasného stavu systému a analýza požadavku˚ na zmˇeny. Ve druhém kroku dochází k detailnímu rozpracování A-grafu˚ a oddˇelení informaˇcního systému od zbytku systému organizace a rozdˇelení celku na subsystémy. Ty je možné chápat jako jakési podmnožiny procesu, ˚ které jsou vˇecnˇe pˇríbuzné. U každého subsystému je provedena analýza jeho nákladu˚ a pˇrínosu. ˚ Tˇretí krok pˇredstavuje informaˇcní analýzu spoˇcívající ve formalizaci nˇejakého informaˇcního subsystému. Na procesy v subsystému se nahlíží nejprve jako na cˇ erné skˇrínky, ˇ které jsou opatˇreny vstupy a výstupy. Cílem analýzy je postupnˇe nalézt všechny transformace vstupu˚ (tj. cˇ innosti), které jsou nutné ke generování výstupu˚ a dále všechny informace, které jsou k té které transformaci potˇrebné. Výsledek analýzy je posléze zanesen do hierarchicky uspoˇrádaného souboru tzv. I-grafu˚ (informaˇcních grafu). ˚ K porozumˇení zpusobu, ˚ jakým organizace funguje, je zárovenˇ potˇrebné provést tzv. analýzu informaˇcních množin spoˇcívající v nalezení optimální struktury dat tak, jak jsou v rámci organizace reálnˇe využívány. Dále je analyzována logika procesu˚ (nebot’ doposud byly známy jen cˇ innosti a jejich informaˇcní vstupy, ale ne jejich logická následnost a podmínky pro provedení jednotlivých akcí). Posledním krokem analýzy je zjištˇení technologicky orientovaných požadavku˚ (rozsah dat, doba odezvy, apod.). 2.2.4.1. Zhodnocení ˇ ˇ V souˇcasné dobˇe jsou podle Repy[ Repa, 2007, s. 103] užívány zejména první tˇri fáze metody. Jejím cenným pˇrínosem je pˇredevším rozlišení „hmoty“ a „informace“, tj. produkˇcních aktu˚ od aktu˚ rˇ ízení. Aˇckoliv jde o metodu bezesporu zajímavou, jejím neopominutelným aspektem je specializace metody primárnˇe na rˇ ešení problému v již existujícím systému. Vzniká-li zcela nová organizace, je možná tˇreba užít jinak zamˇerˇ ených metodik.

2.2.5. DEMO Metoda Dynamic Essential Modeling of Organizations (DEMO) prof. Dietze z university v Delftu je metodou modelování a reengineeringu podnikových procesu. ˚ 8 Metoda je netradiˇcní tím, že podnikový proces nahlíží nikoliv jako sít’ cˇ inností, ale jako sít’ komunikace. Nepracuje totiž s pˇredstavou systému „ˇcerné skˇrínky“, ˇ k nˇemuž náleží vstupy a výstupy, ale s tzv. „skˇrínkou ˇ bílou“. Systém je nahlížen nikoliv primárnˇe z pohledu funkˇcnosti a chování, ale je pojímán prizmatem jakési intersubjektivní ontologie. Ta umožnuje ˇ systém nahlédnout jako urˇcitou jednotu lidí, kteˇrí pˇri vzájemné komunikaci vcházejí do sociálních interakcí. Pˇredmˇetem modelu je tedy primárnˇe reálné chování jedincu˚ a dynamika intersubjektivních vztahu. ˚ Dietz pˇritom pˇredpokládá, že subjekty provádˇejí v podstatˇe dva druhy akcí: • Produkˇcní akty (P-akt) - subjekty konajíce produkˇcní akt naplnují ˇ poslání organizace, pˇriˇcemž muže ˚ jít o akt materiální i nemateriální.9 Výsledkem produkˇcního aktu je pro8 Vycházím 9 Tj.

též ze shrnujícího cˇ lánku profesora Dietze, viz [Dietz, 1999]. o práci na produktu i na službˇe.

37

dukˇcní fakt (P-fakt). • Koordinaˇcní akty (C-akt) - v rámci tˇechto aktu˚ subjekty vcházejí do vzájemných vztahu˚ a podrobují se závazkum. ˚ Dochází tak ke koordinaci produkˇcních aktu. ˚ Výsledkem koordinaˇcního aktu je koordinaˇcní fakt (C-fakt). Typicky jsou koordinaˇcní akty pˇrísliby, že bude uˇcinˇen nˇejaký P-fakt prostˇrednictvím P-aktu (tj. pˇríslib, že nˇekdo nˇeco udˇelá), C-fakty lze chápat jako splnˇené pˇrísliby. C-akty jsou v ideálním pˇrípadˇe následovány P-aktem, jenž je završen P-faktem, cˇ ímž vzniká C-fakt, tj. pˇríslib je následován akcí vedoucí k urˇcitému výsledku, jímž je pˇríslib splnˇen.10 Celá tato posloupnost aktu˚ a faktu˚ je v rámci metody nazývána transakce, na níž se v atomárním pˇrípadˇe podílejí dva aktéˇri (aktérem muže ˚ být v rámci tohoto pojetí kdokoli oprávnˇený, a to jak jedinec, tak celá skupina lidí, resp. organizaˇcní jednotka). Akty a aktéˇri jsou dále rozdˇeleni do tˇrí úrovní abstrakce: • Esenciální pohled - rozlišuje základní business aktéry provádˇející produkˇcní akty, které naplnují ˇ základní funkˇcnosti organizace. • Informaˇcní pohled - zamˇerˇ uje se na informaˇcní aktéry shromažd’ující a zpracovávající znalosti o business aktech a jejich výsledcích. • Dokumentový pohled - nahlíží dokumentaˇcní aktéry provádˇející operace s dokumenty obsahující znalosti. Metoda klade nejvˇetší duraz ˚ na sféru business aktéru, ˚ nejpodstatnˇejší je tedy esenciální pohled, ostatní dvˇe dimenze jsou více cˇ i ménˇe odrazem cˇ i podporou dimenze první. Model business systému (esenciální pohled) je rozdˇelen do cˇ tyˇr modelu: ˚ • Konstrukˇcní model - zobrazuje a spojuje aktéry (resp. role aktéru) ˚ a typy transakcí, v nichž hrají svou úlohu. • Procesní model - zobrazuje rˇ etˇezení jednotlivých akcí. Pˇríklad modelu je uveden na obrázku níže (viz Obrázek ) • Stavový model - popisuje typy faktu˚ používaných v transakcích. Jde fakticky o stavové konceptuální schéma business objektu, ˚ resp. objektovou ontologii. • Operaˇcní model - popisuje pravidla, podle kterých se aktéˇri chovají pˇri svých cˇ innostech.

2.2.5.1. Zhodnocení Metoda DEMO je zajímavá pˇredevším svým zamˇerˇ ením na podstatu fungování podniku, nikoliv na pouhý popis jeho chování. Dodržuje princip tˇrí úrovní abstrakce a rozlišuje mezi popisem systémové dynamiky (procesní pohled) a ontologie (statický pohled). Otázkou však zustává, ˚ zda není její novátorství též limitujícím faktorem. Používá-li totiž nezvyklé paradigma, její modely mohou snadno být bez studia jejích principu˚ nesrozumitelné cˇ tenáˇri, jenž není s netradiˇcní notací blíže seznámen. 10 Dynamika

se tedy rˇ ídí schematem C-akt - P-akt - P-fakt - C fakt.

38


Obrázek 2.3.: Pˇríklad notace metodiky DEMO - procesní model. Zdroj: [Dietz, 1999].

2.2.6. MMABP Methodology for Modeling and Analysis of Business Process (MMABP) je metodikou vzniklou na Katedˇre informaˇcních technologií Vysoké školy ekonomické v Praze. Metodika staví na ˇ principu, který Repa vyjadˇruje následovnˇe:11 „[..] cˇ innost organizace, coby soustavy jednotlivých procesu, ˚ je modelem cílu˚ organizace, skuteˇcností, ovlivnujících ˇ splnˇení tˇechto cílu˚ a jejich vzájemných souvislostí.“ Smyslem procesu˚ je tedy v první rˇ adˇe naplnovat ˇ cíle organizace. Základem této metodiky je technika analýzy událostí. Nalezení podstatných událostí totiž zjednodušuje urˇcení základních procesu, ˚ na jejichž poˇcátku události stojí. Metodika se rˇ ídí pˇredpokladem, že a) model mj. reprezentuje reálné skuteˇcnosti existující vnˇe a nezávisle na organizaci, b) je vhodné oddˇelit úrovenˇ konceptuální od úrovnˇe implementaˇcní a c) vˇetší úrovnˇe podrobnosti lze dosáhnout skrze princip abstrakce. Samotná analýza probíhá ve tˇrech paralelnˇe probíhajících fázích (viz Obrázek 2.4): 1. Analýza elementárních procesu˚ - tato fáze se zabývá zjištˇením elementárních procesu˚ a jejich struktury na základˇe analýzy událostí a reakcí (viz níže). 2. Specifikace klíˇcových procesu˚ - v této fázi dochází k nalezení klíˇcových procesu, ˚ a to na základˇe výsledku˚ první fáze a objektové analýzy produktu˚ procesu. ˚ 3. Specifikace podpurných ˚ procesu˚ - poslední fáze nalézá podpurné ˚ procesy na základˇe pˇredchozích výsledku˚ a objektové analýzy organizace. Tˇemto tˇrem fázím však pˇredchází „nultý krok“ - analýza událostí a vnˇejších reakcí, jíž celá práce zaˇcíná. Cílem tohoto kroku je urˇcit a) pokud možno všechny události relevantní pro chod organizace a b) zpusoby, ˚ jimiž na nˇe reaguje (reakce). Podmínkou obého je pˇritom externalita; události musí pocházet z okolí podniku a reakce musí též smˇerˇ ovat vnˇe. Události, tj. spouštˇecˇ e aktivit organizace, je pˇritom možno rozdˇelit na: • Události vˇecné - týkají se nˇejaké entity, at’ už uvnitˇr cˇ i vnˇe podniku • Události cˇ asované - jejich nastání je urˇceno cˇ asem (napˇr. konec úˇcetního období, apod.) Obvykle je výhodné události dále seskupovat podle nˇejaké vlastnosti, kterou sdílejí (napˇr. podle cílu˚ cˇ i produktu), ˚ nebot’ tato uskupení se v dalších fázích stanou základem pro konˇ [Repa, 2007, s. 198]. V originále je citace uvedena pˇrevážnˇe tuˇcným písmem, zde pro pˇrehlednost uvádím v netuˇcném duktu.

11 Viz

39

ˇ Obrázek 2.4.: Schéma prubˇ ˚ ehu prací v rámci metodiky MMABP. Zdroj: [Repa, 2007]. strukci jednotlivých procesu. ˚ Dále je potˇreba analyzovat logickou návaznost zjištˇených událostí, tj. zpusob, ˚ jakým se rˇ adí za sebou a to, zda jsou nˇekteré události vzájemnˇe alternativní (muže ˚ nastat pouze jediná z alternativ), cˇ i iterativní (výskyt jedné události odpovídá více výskytum ˚ jiné události).

ˇ 2.2.6.1. Detailnejší popis fází Ve fázi první dochází k urˇcení všech elementárních procesu. ˚ Jak již bylo rˇ eˇceno, analytik pˇritom vychází ze souboru zˇretˇezených reakcí na události z „nultého kroku“, ale reakce jsou od nynˇejška chápány jako cˇ innosti procesu. ˚ Nejdˇríve je vyhotoven seznam všech identifikovaných elementárních procesu˚ s informacemi o základních událostech a cˇ innostech procesu, ˚ je též tˇreba sestavit hierarchii procesu˚ a urˇcit jejich pˇrirozené vzájemné vazby.12 Jako symptom vazby jiného druhu lze též chápat spoleˇcné vstupy a výstupy a spoleˇcné aktéry. Tˇretí krok prví fáze pˇredstavuje detailní analýzu ˇ elementárních procesu. ˚ Repa zde však není pˇríliš konkrétní a nestanovuje pˇresný návod ani žádoucí úrovenˇ podrobnosti a nechává tak zcela volnou ruku analytikovi. Volená úrovenˇ detailu má být zkrátka taková, „[..] která je vzhledem k okolnostem vhodná [..]“13 Posledním krokem je analýza konzistence elementárních procesu, ˚ v jejímž rámci je tˇreba zkontrolovat, 12 Klade se duraz ˚ pˇredevším na spoleˇcné vazby mezi procesy a událostmi. Je rˇ ešena otázka, které procesy sdílejí

které události. ibid., s. 203.

13 Viz

40


zda navržený model neobsahuje logické rozpory a vylouˇcit jisté nežádoucí jevy (napˇr. události, na nˇež není definována žádná reakce, proces bez výstupu, ˚ vstupu˚ cˇ i aktéru, ˚ apod.). Zámˇerem fáze druhé je pˇresnˇejší urˇcení klíˇcových procesu. ˚ Priorita klíˇcových procesu˚ totiž vychází z faktu, že jde o procesy produkující pˇridanou hodnotu pro zákazníka - jsou vždy reakcí na zákazníkovu potˇrebu a konˇcí vždy jejím uspokojením. Nejprve je tedy provedena objektová analýza podnikových produktu, ˚ jejímž výsledkem je objektový model produktu. ˚ 14 Poté je potˇreba provést duslednou ˚ analýzu životních cyklu˚ objektu, ˚ nebot’ zmˇeny jejich stavu˚ jsou v úzkém vztahu k cˇ innostem procesu˚ - cˇ innosti jsou totiž pˇríˇcinou pˇrechodu objektu z jednoho stavu do druhého. Posledním krokem této fáze je opˇet kontrola konzisˇ tence modelu. Repa zde upozornuje ˇ pˇredevším na nebezpeˇcí nekonzistence objektového a procesního modelu, procesnˇe nepokrytých produktu˚ cˇ i cˇ ástí života produktu, ˚ atd. Ve fázi tˇretí, tj. pˇri specifikaci podpurných ˚ procesu˚ je prvním krokem dokonˇcení objektové analýzy podniku, v jejímž rámci jsou k již namodelovaným produktum ˚ pˇridány všechny ostatní relevantní entity a je dokonˇcena analýza vzájemných asociací objektu. ˚ Dále je provedena analýza podpurných ˚ procesu, ˚ tj. tˇech, které sice pˇrímo nereagují na potˇreby zákazníka, ale jsou podstatné pro výkon procesu˚ klíˇcových. Podpurné ˚ procesy lze dˇelit bud’ (podle specifiˇcnosti služby) na lokální, resp. universální podle toho, zda je využíván jedním, resp. mnoha jinými procesy. Dále je též možné rozlišit mezi podpurnými ˚ procesy (podle zpusobu ˚ podpory) následovnˇe: • Procesy jednorázové (servisní) - specializují se na jedinou službu a mají charakter podprocesu cˇ i koprocesu. Pˇríkladem je napˇr. pˇrijímací rˇ ízení studentu˚ v procesu vzdˇelávání. • Procesy paralelní (pruˇ ˚ rezové) - slouží mnoha okolním procesum ˚ a jsou na nich relativnˇe nezávislé. Poskytují všem procesum ˚ služby dle jejich potˇreby. Pˇríkladem pruˇ ˚ rezového procesu je napˇr. personalistická cˇ i právní podpora. I v této fázi nakonec následuje závˇereˇcná kontrola konzistence všech modelu˚ procesu˚ a objektu. ˚

2.2.7. Vybraná metoda Po zhodnocení silných a slabých stránek uvedených metod konstatuji, že za nejvhodnˇejší metodu pro procesní analýzu v rámci této práce považuji metodu MMABP. Její výhody oproti ostatním metodám jsou následující: • Relativní jednoduchost a intuitivnost použití metodiky (strmá kˇrivka uˇcení). • Zacílenost výhradnˇe na doménu analýzy procesu˚ (napˇr. oproti ARIS, BSP) a nevmˇešování do slabˇeji souvisejících domén (napˇr. rˇ ízení). Metodika rˇ eší právˇe to, co od ní analytik oˇcekává. • Dusledné ˚ rozlišování mezi událostmi a stavy procesu˚ (napˇr. oproti ARIS). • Existence a snadná dostupnost dostateˇcného množství pˇrípadových studií. • Zužitkování pˇrínosu˚ ostatních metod analýzy procesu. ˚ 14 Množinu

produktu˚ je možné chápat jako urˇcitou podmnožinu množiny všech podnikových objektu. ˚ Objektový model produktu˚ je tudíž jednou z cˇ ástí celkového modelu objektu. ˚

41

• Duraz ˚ na konzistenci statického a dynamického modelu, který vede k redukci analytických chyb. • Využití standardních nástroju˚ a modelovacích technik (napˇr. oproti DEMO, na mysli mám zejména symbolické jazyky UML a BPML, resp. BPMN) a s tím spojená snadná srozumitelnost. ˇ • Ceská lokalizace.

2.3. Použité nástroje a postup Každý proces nejprve popíši prostˇrednictvím procesního modelu zachyceného procesním diagramem za použití analytického programu PowerDesigner v. 12.5. Pro co nejjednodušší ˇ postup pˇri analýze Repa navrhuje použít techniky modelování procesu˚ PDT (Process Diagram Technique) pˇredstavené v [2007, s. 219nn.]. Tato technika není závislá na žádném konkrétním procesním jazyce.15 Duležité ˚ však je, aby mˇel vybraný jazyk dostateˇcnou expresivitu a disponoval všemi konstrukty nezbytnými k zachycení podstatných rysu˚ procesu. ˚ ˇ Repa sám v pˇriložené pˇrípadové studii používá notace BPMN - duvodem ˚ je patrnˇe fakt, že tato notace se stala jakýmsi prumyslovým ˚ standardem. I v následující analýze se z tohoto duvodu ˚ k BPMN pˇrikloním. Konstrukty vyžadované technikou PDT a jejich grafické znázornˇení v rámci BPMN lze nalézt v následující tabulce 2.2. Z tabulky je zˇrejmé, že expresivita PDT není pˇríliš vysoká, což má své znaˇcné výhody v relativní jednoduchosti návrhu, ale též nevýhody spoˇcívající v obtížích spojených s vyjadˇrováním komplexní reality. PDT si ˇ vystaˇcí s následujícími konstrukty: Událost, Stav procesu, Cinnost, Rozhodovací cˇ innost, Primitivní rozhodnutí, Množina dat, Množina materiálu, Smíšená množina, Aktér, Organizaˇcní jednotka a Problém. Kromˇe tabulek procesu˚ a samotných procesních modelu˚ využiji dále standardnˇe využívanou notaci UML, a to pro zachycení a) statického pohledu na systém prostˇrednictvím diagramu tˇríd (class diagram) a b) dynamického pohledu na zmˇeny stavu˚ objektu˚ prostˇrednictvím stavového diagramu (state chart diagram). Vytvoˇril jsem také pˇríslušné konzistenˇcní tabulky, které cˇ tenáˇr najde v Pˇríloze cˇ . 1 tohoto dokumentu.

2.3.1. Použitá rozšíˇrení a úpravy V prubˇ ˚ ehu analýzy jsem zjistil, že v jistých pˇrípadech dochází v rámci jednoho procesu k požadavku na simultánní spuštˇení mnoha instancí jiného procesu (koprocesu) najednou, pˇriˇcemž pro další pokraˇcování procesu je nutné poˇckat na dobˇehnutí všech volaných instancí. Tuto skuteˇcnost považuji za údaj z hlediska dynamiky procesu podstatný a hodný zachycení. Proto u takovýchto koprocesu˚ zpravidla používám stereotypu <<Multiple>>. Entitu Note z BPMN dále užívám také v puvodním ˚ významu - jako prostou poznámku, nikoliv pouze jako problém. Rozdíl mezi primitivním rozhodnutím a rozhodovací cˇ inností spoˇcívá v rámci této práce v tom, že pro vykonání rozhodovací cˇ innosti je tˇreba lidské intervence, avšak primitivní rozhodnutí muže ˚ probíhat automaticky, na základˇe již známých 15 Viz

[2007, s. 222]. Jde o jazyky používané pro formalizaci, resp. symbolickou reprezentaci procesu. ˚ Tˇechto jazyku˚ je celá rˇ ada a jejich zápis je založen na XML. Nejrozšíˇrenˇejším jazykem je v souˇcasnosti patrnˇe jazyk BPML a jeho grafická notace BPMN.

42


U DÁLOST

S TAV PROCESU

ˇ INNOST C

Jde o vnˇejší podnˇet k cˇ innosti.

Jedná se o vnitˇrní podnˇet cˇ innosti. Výsledek

ˇ Cinnost zpracovává vstupy na výstupy.

cˇ innosti logicky pˇredcházející.

ˇ R OZHODOVACÍ CINNOST

P RIMITIVNÍ ROZHODNUTÍ

M NOŽINA DAT

Výstupem této cˇ innosti není nic jiného, než

Jde o tak jednoduchou rozhodovací cˇ innost, že k

ˇ Jde o množinu rˇ ídících dat. Rídící data jsou

rozhodnutí o další cˇ innosti.

jejímu provedení nejsou potˇreba žádné dodateˇcné

taková data, která jsou nezbytná pro rˇ ízení

vstupy.

procesu.

M NOŽINA MATERIÁLU

S MÍŠENÁ MNOŽINA

A KTÉR

Množina materiálu vstupujícího do

Množina obsahující prvky z obou pˇredchozích

Jakýkoliv abstraktní úˇcastník: osoba cˇ i její role,

cˇ innosti/procesu. Materiál je pˇritom tˇreba chápat

množin.

útvar, systém, orgán, apod.

velmi obecnˇe - pod tento pojem totiž fakticky spadají jak hmotné vˇeci, tak informace. Informaci jakožto „materiál“ je však tˇreba oddˇelit od informace rˇ ídící.

ˇ O RGANIZA CNÍ JEDNOTKA

P ROBLÉM

Organizaˇcní cˇ ást dané organizace.

Problém spojený s procesem v jistém místˇe. Je zobrazován jako poznámka.

Tabulka 2.2.: Užité konstrukty BPMN.

43

Obrázek 2.5.: Užití stereotypu Multiple. událostí. Symbol Data-XOR, aˇckoli reprezentuje primitivní rozhodovací cˇ innost, neomezuje se svým rozsahem pouze na ni. Je-li oznaˇcen názvem R1, R2,.., Rn, pak znaˇcí spojovací, resp. rozpojovací prvek dvou a více vˇetví procesu. Vzhledem k tomu, že procesní analýza bude sloužit jako podklad k návrhu webové aplikace, do relativních detailu˚ modeluji také samotnou komunikaci mezi organizací a zákazníky (agenty) - obvykle lze v diagramu nalézt cˇ innost spojenou odesláním informace agentovi, události zpusobované ˚ zvnˇejšku jsou obvykle požadavky agentu. ˚

44

3. Analýza Jak již bylo avizováno výše (viz 1.3), pˇredmˇetem této analýzy jsou v první rˇ adˇe procesy probíhající v organizaci (ozn. jako zprostˇredkovatelskou organizaci), jejímž cílem je podporovat a usnadnovat ˇ stˇretávání nabídky a poptávky na trhu s neziskovými pˇríležitostmi. Jedinci a firmy na tomto trhu poptávají neziskovými organizacemi nabízené pˇrípady (projekty, dobrovolnické pozice, petice, apod.), do nichž chtˇejí z urˇcitých duvod ˚ u˚ alokovat své zdroje, tj. zejména finance, ale též lidskou práci, politickou sílu, apod. Zprostˇredkovatelská organizace se tedy pohybuje ve svém okolí tvoˇreném pˇredevším neziskovými organizacemi, firmami a veˇrejností a optimalizuje alokaci zdroju˚ a cˇ iní snazší naplnování ˇ potˇreb všech zúˇcastnˇených. Analýza bude provedena v souladu s definicí pˇrínosu této diplomové práce (viz 1.5). Duleži˚ tou skuteˇcností, jíž se budu pˇri analýze rˇ ídit, je pˇredpoklad jejího pozdˇejšího užití pro úˇcely návrhu informaˇcního systému. Má-li být procesní analýza v této úloze skuteˇcným pomocníkem, je nezbytné, aby byla provedena ve znaˇcném detailu a v odpovídající komplexnosti. Vzhledem k povaze problému považuji za vhodné užít k analýze tzv. top-down strategie, nebot’ ta umožnuje ˇ cˇ tenáˇri i analytikovi snadnou povšechnou orientaci v problematice, a to již na samém poˇcátku analýzy. To pˇredpokládá vytvoˇrení nejobecnˇejšího modelu, jenž je v pozdˇejších fázích stále konkrétnˇeji cizelován. Tímto modelem je model okolí analyzované organizace, na jehož základˇe budou posléze vytvoˇreny modely klíˇcových procesu˚ v organizaci probíhajících.1

3.1. Okolí systému Pro úˇcely této práce postaˇcí analýza pouze takového výseku okolí, který je urˇcující pro charakter klíˇcových procesu. ˚ Stranou je tedy možné nechat jeho ekologické, kulturnˇe-historické, politické cˇ i geografické aspekty. Zcela stranou naopak nemohou zustat ˚ aspekty etické, sociální, právní a ekonomické. Aˇckoliv se v této práci nebudu soustˇredit na analýzu tˇechto dimenzí, nebot’ to výraznˇe pˇresahuje její rámec, pˇresto budou jistým latentním zpusobem ˚ do analýzy vstupovat. Níže uvádím diagram zobrazující okolí podniku (viz Obrázek 3.1) zachycující pouze vztahy, v nichž figuruje zprostˇredkovatelská organizace.2 Jedná se o schématické zobrazení, kde symbol postaviˇcky pˇredstavuje organizaci (napˇr. Firmy) cˇ i (obecnˇeji) množinu jednotlivcu˚ (napˇr. Veˇrejnost). Šipky s uvedeným stereotypem oznaˇcují libovolný binární vztah dvou organizací. Oválné plochy jsou zde užity k vyjádˇrení objektu˚ (v nejširším možném slova smyslu), resp. reifikovaných vztahu˚ o vyšší než binární komplexitˇe. Zprostˇredkovatelská organizace v první rˇ adˇe zveˇrejnuje ˇ informace o jednotlivých pˇrípadech a nabízí je široké 1 Klíˇ cový

proces je procesem sloužícím výhradnˇe k naplnˇení potˇreb zákazníku. ˚ Jde o nejduležitˇ ˚ ejší proces v organizaci, jímž je urˇcen též úˇcel organizace jako takové a má úzkou vazbu na strategické cíle. 2 Ne tedy vztahy mezi prvky okolí, které se pˇrímo netýkají zkoumané organizace.

45

Obrázek 3.1.: Diagram zobrazující Okolí systému. veˇrejnosti k podpoˇre. Zájemci z rˇ ad veˇrejnosti následnˇe na tyto nabídky reagují a deklarují svuj ˚ zámˇer pˇrípad podpoˇrit. Zprostˇredkovatelská organizace v takovém pˇrípadˇe tuto podporu zprostˇredkovává - pˇrijímá nabídky pomoci a technicky zajišt’uje jejich cestu za neziskovými organizacemi, vede evidenci o podpoˇre a snaží se podpoˇrit šíˇrení informace o pˇrípadu prostˇrednictvím moderních komunikaˇcních kanálu˚ (email, sociální sítˇe, apod.). Dalším významným prvkem okolí je banka, která zprostˇredkovatelské organizaci vede úˇcet a provádí zadané platby. Duležitou ˚ roli hraje díky své legislativní roli také stát urˇcující právní prostˇredí, v jehož rámci se všechny výše zmínˇené subjekty pohybují. V neposlední rˇ adˇe se v okolí sledované organizace pohybují též firmy. Zejména ty tzv. „spoleˇcensky odpovˇedné“ z nich se v rámci své PR (public relations) strategie zabývají firemní filantropií, tj. cˇ inností spocˇ ívající obvykle v investici financí, lidské práce a dalších hodnot do neziskových projektu. ˚ Role zprostˇredkovatelské organizace je v tomto pˇrípadˇe pˇredevším poradenská. Na požádání vyhledá relevantní neziskové pˇrípady, a to pˇredevším s využitím nástroju˚ BI (business intelligence). Jistou inverzí tohoto procesu je pak pomoc neziskovým organizacím pˇri hledání firemních dárcu, ˚ tj. zejména provádˇení fundraisingu a dalších cˇ inností spojených s hledáním zdroju. ˚

ˇ 3.2. Analýza klícových procesu˚ Informace získané pˇri analýze okolí systému nyní využiji pro podrobnˇejší analýzu klíˇcových procesu˚ ve zprostˇredkovatelské organizaci probíhajících, mezi nˇež lze zaˇradit následující: 46

3. Analýza

• Alokace firemní filantropie - zprostˇredkovatelská organizace v rámci tohoto procesu hledá pro zákaznickou firmu optimální pˇríjemce podpory (finanˇcního daru, ale též napˇr. dobrovolnictví, apod.), kterou firma chce pˇridˇelit nˇekterému neziskovému projektu. Tento proces je rˇ ízen primárnˇe potˇrebou firmy, nikoliv neziskové organizace, takže roli ve výbˇeru hraje nejen transparentnost, efektivita a duvˇ ˚ eryhodnost, ale též napˇr. pˇredpokládaný dopad na firemní PR, apod. Poté, co je pˇríjemce vybrán, dojde k zprostˇredkování podpory (viz 3.4, viz Obrázek 3.2). Tento proces bude analyzován pouze na obecné úrovni a dále se mu nebudu vˇenovat podrobnˇeji, nebot’ to by pˇresáhlo stanovený rámec práce. • Hledání firemního podporovatele - cílem tohoto procesu je poskytnout neziskovým organizacím služby spojené s hledáním a pˇresvˇedˇcováním primárnˇe (avšak nikoliv výluˇcnˇe) korporátních investoru. ˚ Jde o službu, jejíž cˇ ástí je i fundraising, tedy získávání zdroju˚ finanˇcních. V žádném pˇrípadˇe se však na fundraising neomezuje, ale je otevˇren také vuˇ ˚ ci alternativním druhum ˚ podpory (viz 3.5, viz Obrázek 3.3). Ani tomuto procesu se nebudu vˇenovat podrobnˇeji. • Nabídnutí neziskového pˇrípadu veˇrejnosti - tento proces spoˇcívá ve zveˇrejnˇení informací v rámci katalogu neziskových pˇrípadu˚ (viz 3.7, viz Obrázek 3.4). Tento katalog je pˇrístupný široké veˇrejnosti. • Zprostˇredkování podpory pˇrípadu - v jistém smyslu navazuje na pˇredchozí proces a zprostˇredkovává veˇrejností nabízenou podporu (viz 3.8, viz Obrázek 3.5). Všechny ostatní procesy probíhající ve zprostˇredkovatelské organizaci slouží k podpoˇre zmínˇených klíˇcových procesu. ˚ Lze je rozdˇelit do tˇechto základních kategorií: • Procesy spojené s platbami a objednávkami popisují nejduležitˇ ˚ ejší zpusoby, ˚ jakými v rámci zprostˇredkovatelské organizace probíhají platby. • Procesy spojené s registracemi uživatelu˚ a organizací. • Ostatní procesy, které nepˇrináležejí ani k jedné z výše jmenovaných skupin. Aˇckoliv jsem identifikoval celkem cˇ tyˇri klíˇcové procesy, podrobnˇe se budu vˇenovat pouze dvˇema, a to Nabídnutí neziskového pˇrípadu veˇrejnosti a Zprostˇredkování podpory pˇrípadu, nebot’ tyto jsou úzce spjaty s cílem práce. U druhých dvou vytvoˇrím pouze obecný model jejich prubˇ ˚ ehu, ale nebudu již blíže zkoumat jejich pomocné koprocesy.

3.2.1. Key performance indicators S pouhým stanovením pˇredmˇetu cˇ innosti zprostˇredkovatelské organizace se nelze spokojit. Pˇrinejmenším stejnˇe duležité ˚ je též urˇcit, jakým zpusobem ˚ bude mˇerˇ eno dosahování jejích cílu. ˚ K tomu slouží urˇcení tzv. KPI (key performance indicators), tj. klíˇcových indikátoru˚ výkonnosti. Jde o metriky sloužící k mˇerˇ ení míry, s jakou byly v daném období naplnˇeny cíle organizace; podávají tedy základní informaci o efektivitˇe sledované organizace. Struˇcný pˇrehled indikátoru˚ vztažených k cílum ˚ zprostˇredkovatelské organizace lze nalézt v tabulce (viz Tabulka 3.1). 47

Obrázek 3.2.: Diagram zobrazující klíˇcový proces Alokace firemní filantropie v kontextu ostatních procesu. ˚

Obrázek 3.3.: Diagram zobrazující klíˇcový proces Hledání firemního podporovatele v kontextu ostatních procesu. ˚

48

3. Analýza

Obrázek 3.4.: Diagram zobrazující klíˇcový proces Nabídnutí neziskového pˇrípadu veˇrejnosti v kontextu ostatních procesu. ˚

Obrázek 3.5.: Diagram zobrazující klíˇcový proces Zprostˇredkování podpory pˇrípadu v kontextu ostatních procesu. ˚

49

Metrika

Popis

Poˇcet zprostˇredkovaných

Celkový poˇcet zprostˇredkovaných transakcí. Jde v zásadˇe o soubor metrik - pro každý

podpor za období

druh podpory je vhodné užít samostatnou metriku.

Objem zprostˇredkovaných

Celkový objem podpor. Jde v zásadˇe o soubor metrik - pro každý druh podpory je

podpor za období

vhodné užít samostatnou metriku.

Poˇcet realizovaných pˇrípadu˚

Poˇcet pˇrípadu˚ neziskových organizací, které byly realizovány s pˇrispˇením zprostˇredkovatelské organizace.

Prumˇ ˚ erné zpoždˇení zakázky

Organizace by mˇela plnit zakázky vˇcas, cílem je tedy tuto metriku minimalizovat. Jde o prumˇ ˚ er mˇer zpoždˇení jednotlivých zakázek, do prumˇ ˚ eru jsou však zahrnuty pouze ty zakázky, které byly zpoždˇeny.

Pomˇer zpoždˇených zakázek

Organizace by mˇela plnit zakázky vˇcas. Jde o podíl poˇctu zpoždˇených zakázek vuˇ ˚ ci celkovému poˇctu zakázek.

Prumˇ ˚ erné pˇrekroˇcení

Organizace by nemˇela pˇrekraˇcovat stanovené rozpoˇcty, jejím cílem je tedy tuto metriku

rozpoˇctu zakázky

minimalizovat. Jde o prumˇ ˚ er mˇer pˇrekroˇcení jednotlivých rozpoˇctu, ˚ do prumˇ ˚ eru jsou však zahrnuty pouze ty zakázky, které mˇely pˇrekroˇcený rozpoˇcet.

Pomˇer pˇrekroˇcených rozpoˇctu˚

I v pˇrípadˇe této metriky organizace usiluje o její minimalizaci. Jde o podíl poˇctu

zakázek

zakázek s pˇrekroˇcenými rozpoˇcty vuˇ ˚ ci celkovému poˇctu zakázek.

Tabulka 3.1.: Tabulka Klíˇcových indikátoru˚ výkonnosti zprostˇredkovatelské organizace.

3.3. Analýza agentu˚ V rámci každého procesu probíhajícího v libovolné organizaci hrají podstatnou roli lidé (agenti) a jimi zastávané role. Na poˇcátku této kapitoly je proto nejprve nutné provést jejich základní typologii. Mezi rolemi platí z hlediska funkcionality vztah dˇediˇcnosti tak, jak je patrné z diagramu (viz Obrázek 3.6) - uživatel s více oprávnˇeními obvykle dˇedí práva uživatele hierarchicky níže postaveného. Rozdˇelení uživatelu˚ lze schematizovat následovnˇe: • Host (Agent) - jde o neznámého agenta, o nˇemž zprostˇredkovatelská organizace nemá žádné údaje. Agent má v rámci systému nejménˇe pravomocí. • Registrovaný uživatel - jednotlivec oprávnˇený provádˇet oproti hostu rozšíˇrenou množinu akcí. • Zamˇestnanec je registrovaný uživatel nacházející se v zamˇestnaneckém pomˇeru k nˇejaké organizaci. • Správce dostává oproti registrovaném uživateli navíc práva potˇrebná ke spravování tˇech záležitostí, kterých je správcem. – Správce komunity zakládá a spravuje uživatelskou komunitu. – Správce petice spravuje petici. Správcem petice muže ˚ být i uživatel, který není cˇ lenem žádné organizace. – Správce události spravuje událost jemu svˇerˇ enou do správy zpravidla správcem neziskové organizace. – Správce projektu spravuje projekt, jenž mu byl svˇerˇ en do správy zpravidla správcem neziskové organizace. 50

3. Analýza

– Správce neziskové organizace je ten, kdo rozhoduje o všech záležitostech týkajících se konkrétní neziskové organizace. Dˇedí všechny pravomoci správce petice, správce události a správce projektu. – Správce firmy je ten, kdo za firmu komunikuje se zprostˇredkovatelskou organizací a spravuje její profil.3 • Administrátor muže ˚ provádˇet všechny dostupné akce. Lze oˇcekávat, že bude zamˇestnancem zprostˇredkovatelské organizace.

Obrázek 3.6.: Diagram zobrazující dˇediˇcnost uživatelských rolí v UML.

3.4. Alokace firemní filantropie Jak již bylo rˇ eˇceno výše, obsahem klíˇcového procesu Alokace firemní filantropie (viz Tabulka 3.2, viz Obrázek 3.7) je hledání optimálního pˇríjemce podpory nabízené firemním klientem. Prvním krokem je detailní analýza potˇreb firmy, v jejímž rámci je zkoumáno, a) na jaký typ neziskové cˇ innosti chce pˇrispˇet, b) jakým objemem podpory a c) jaké má požadavky na pˇríjemce podpory. V dalším kroku je provedena BI analýza, která pro zákazníka vytváˇrí nejvˇetší pˇridanou hodnotu. Na základˇe zákazníkových požadavku˚ jsou zkoumány vhodné neziskové pˇrípady, dále je zjištˇeno, zda není možné spojit více nabídek od ruzných ˚ firem do podpory jediné rozsáhlé neziskové aktivity, ovšem za pˇredpokladu, že je vubec ˚ spolupráce mezi dotyˇcnými firmami myslitelná (pˇrekážkou muže ˚ být napˇr. konkurenˇcní boj, apod.). Dále muže ˚ být zkoumána transparentnost (zveˇrejnování ˇ úˇcetních dat, roˇcenky, apod.) a finanˇcní stav neziskových organizací, jejich efektivita, schopnost neziskových projektu˚ zviditelnit firemní PR, pˇrípadné zprávy z tisku, reference na pˇredešlé úspˇešné projekty, vyjádˇrení zamˇestnancu˚ k situaci v organizaci, apod. 3 Profil

zde ve smyslu souboru dostupných informací o firmˇe, jimiž zprostˇredkovatelská organizace disponuje, a které poskytuje dál.

51

Startovací událost

Potˇreba alokace filantropické potˇreby.

Produkty/služby

Filantropická potˇreba firmy je alokována do neziskového pˇrípadu.

Zákazník

Firma.

Metriky

- Efektivita využití alokovaných zdroju˚ ze strany NNO. - Poˇcet zakázek v daném období. - Spokojenost zákazníka se službami (dotazníkové šetˇrení). - Spokojenost zákazníka se službami.

Podmínky

Firma musí být tzv. „spoleˇcensky odpovˇedná“, tj. být ochotná investovat do neziskových projektu. ˚

Dokumenty

- BI analýza. - Detailní analýza potˇreb. - Závˇereˇcný dokument. - Reporty stavu využití podpory.

Tabulka 3.2.: Tabulka klíˇcového procesu Alokace firemní filantropie. Další fází procesu je zprostˇredkování podpory. Výsledky BI analýzy jsou nejprve zaslány zákazníkovi. Ten v pˇrípadˇe, že souˇcástí zakázky je též zprostˇredkování podpory, vybere z BI analýzou nabízeného portfolia vhodných neziskových pˇrípadu˚ optimálního kandidáta (resp. kandidáty) a následnˇe povˇerˇ í organizaci zprostˇredkováním celé transakce. Organizace poté jedná jménem firemního zákazníka s pˇríslušnými neziskovými organizacemi o podmínkách pˇrijetí podpory. Je-li pˇríjemce úspˇešnˇe nalezen, dojde k samotnému zprostˇredkování podpory, v opaˇcném pˇrípadˇe je alokace ukonˇcena nezdarem. Úspˇešnou alokací však proces ještˇe nekonˇcí - zprostˇredkovatelská organizace poté dále provádí dohled nad podporovaným projektem a nad efektivitou využití vynaložených prostˇredku. ˚ Po zkonzumování celé pomoci je kontrola uzavˇrena a nadchází fáze uzavˇrení klíˇcového procesu, bˇehem níž dojde k zaslání závˇereˇcné zprávy zákazníkovi, zjištˇení jeho spokojenosti s probˇehnuvším procesem a k platbˇe za poskytnuté služby.

3.5. Hledání firemního podporovatele Startovací událost

Potˇreba nalézt firemního podporovatele.

Produkty/služby

Nezisková organizace nalezne organizaci ochotnou investovat do jejích projektu. ˚

Zákazník

Nezisková organizace.

Metriky

- Objem podpory za období. - Spokojenost neziskových organizací se službou. - Poˇcet zakázek za období.

Podmínky

Nezisková organizace musí být duvˇ ˚ eryhodná a mít pˇrípad, který je životaschopný.

Dokumenty

- Analýza pˇrípadu. - Strategie získání podpory.

Tabulka 3.3.: Tabulka klíˇcového procesu Hledání firemního podporovatele. 52

3. Analýza

Obrázek 3.7.: Diagram klíˇcového procesu Alokace firemní filantropie.

53

Obrázek 3.8.: Diagram klíˇcového procesu Hledání firemního podporovatele. Klíˇcový proces Hledání firemního podporovatele je procesem, jehož smyslem je najít organizaci ochotnou investovat do pˇrípadu neziskové organizace své zdroje. Projekt je na obecné úrovni zobrazen na pˇriloženém diagramu (viz Tabulka 3.3, viz Obrázek 3.8). Nejprve je zprostˇredkovatelskou organizací provedena analýza neziskového pˇrípadu vedoucí ke získání základních informací o pˇrípadu, o jeho zamˇerˇ ení, rozpoˇctu, cˇ asovém rozpˇetí, apod. Na základˇe tˇechto informací je proveden návrh strategie pro získání podpory. Strategie se muže ˚ skládat z rozesílání emailu, ˚ schuzek ˚ s povˇerˇ enými zamˇestnanci firem, z návrhu fundraisingové kampanˇe, zpracování žádosti o grant, atd. Je-li návrh neziskovou organizací odmítnut, postupuje do zmˇenového rˇ ízení, v jehož rámci jsou vypoˇrádány pˇripomínky ze strany zákazníka. Je-li návrh neziskovou organizací schválen, muže ˚ zprostˇredkovatelská organizace pokraˇcovat implementací definované strategie, pokud je to ovšem souˇcástí zakázky. Posledním krokem je vždy ukonˇcení zakázky, v jejímž rámci jsou provedeny platby za poskytnuté služby a vyhodnocení spokojenosti zákazníka.

3.6. Obecný model základních business entit Základní model business entit je zobrazen na diagramu (viz Obrázek 3.9). Nejduležitˇ ˚ ejšími prvky diagramu tˇríd jsou pravdˇepodobnˇe tˇrídy Agent a Pˇredmˇet. Jde o potomky tˇrídy Základní entita a dˇedí od ní základní prvky životního cyklu a atributy. Agentem je každý v 54

3. Analýza

systému se pohybující a systém využívající jednotlivec. Uživatel je pak agent prošedší procesem registrace a vlastnící uživatelský úˇcet. Zatímco k agentu se rˇ adí pouze jedna role (host), uživateli muže ˚ náležet celá rˇ ada rolí (napˇr. správce, administrátor, zamˇestnanec). Tˇrída Požadavek modeluje výhradnˇe požadavky agentu˚ smˇerˇ ující na zprostˇredkovatelskou organizaci a požadavky zprostˇredkovatelské organizace smˇerˇ ující na agenta. Pˇredmˇety jsou relativnˇe trvalé pojmenovatelné objekty (tj. entity, které nejsou agenty, subjekty) vyvstávající pˇred subjektem a lze je rozdˇelit na Organizace,4 a Pˇrípady. Organizací je mínˇeno jakékoliv sdružení jednotlivcu˚ nabývající formy Neziskové organizace, Firmy, nebo Uživatelské komunity. Entita Pˇrípad modeluje jakoukoliv snahu organizace (tj. neziskové organizace, komunity cˇ i firmy)5 dosáhnout svých cílu, ˚ 6 u níž organizace oˇcekává podporu verˇ ejnosti (resp. agentu). ˚ Tˇrída Podpora (viz též Obrázek 3.12) zachycuje právˇe podporu, kterou jednotlivým pˇrípadum ˚ agenti poskytují - muže ˚ jít o podporu finanˇcní, dobrovolnickou, mediální, politickou, apod. Uživatelská komunita na dobrovolné bázi sdružuje agenty vykazující v reálném životˇe spoleˇcné rysy (profese, náboženství, apod.) cˇ i zájmy. Tˇrída Administrace reprezentuje fakt týkající se administrátorské, resp. správcovské role. Uživatel se muže ˚ stát administrátorem mnoha ruzných ˚ pˇredmˇetu, ˚ pˇredmˇet muže ˚ být spravován mnoha ruznými ˚ uživateli. Není-li instance tˇrídy Administrace vztažena k žádnému pˇrípadu a drží-li náležitý atribut oprávnˇení, muže ˚ též reprezentovat skuteˇcnost, že dotyˇcnému uživateli náleží role administrátora celé organizace. Asociace Pˇredmˇetu a Administrace není obligatorní, nebot’ nelze zaruˇcit, že již zrušené pˇrípady, o nichž organizace stále vede záznam, budou mít nˇejakého administrátora. Z diagramu (viz Obrázek 3.9) je patrné, že Agent a pˇredmˇet je pˇrímým potomkem Základní entity, zatímco Organizace a Pˇrípad jsou potomky Pˇredmˇetu a Komunita, Nezisková organizace a Firma jsou potomky Organizace. Základní entitu, Podporu, Pˇredmˇet, Pˇrípad a Organizaci lze považovat za abstraktní tˇrídy. Základní entita má sice pomˇernˇe triviální životní cyklus (viz Obrázek 3.10), ale vzhledem k tomu, že jej dˇedí mnoho entit, je vhodné jej pro úplnost uvést. Od zcela triviálního životního cyklu pˇrecházejícího pouze mezi stavy Vytvoˇrena/Smazána ji odlišuje mezistav Ukonˇcena. O již v realitˇe neexistující entitˇe se prostˇrednictvím tohoto stavu uchovává historický záznam. Níže je zobrazen stavový diagram tˇrídy Pˇrípad (viz Obrázek 3.11), který dˇedí základní stavy a pˇrechody od Základní entity, ale rozšiˇruje je o další stav (Zveˇrejnˇen). Pˇrípad ve stavu Pˇripraven muže ˚ být svým vlastníkem upravován, ale nelze jej v tomto režimu podporovat, nebot’ není ani publikován. Pˇrechody mezi stavy jsou z podstatné cˇ ásti pokryty procesem Provoz pˇrípadu (viz 3.7.2).

3.6.1. Typologie pˇrípadu˚ Další velmi duležitou ˚ souˇcástí konceptuálního modelu tˇríd tvoˇrí jednotlivé druhy neziskových pˇrípadu. ˚ Vzájemné vazby entit vztahujících se k pˇrípravˇe pˇrípadu lze nalézt na pˇriloženém diagramu (viz Obrázek 3.12). Do analýzy zahrnuji následující pˇrípady: 4 Dopouštím

se zde zpˇredmˇetnˇení organizace, což však s ohledem na rˇ ešený problém negeneruje žádné závažné problémy. 5 Komunitˇ e však v rámci analýzy nenáleží ani jeden specifický pˇrípad. 6 Jde o „projekt“ v naprosto obecném slova smyslu, jehož vlastníkem je právˇ e nezisková organizace.

55

Obrázek 3.9.: Nejobecnˇejší model tˇríd zobrazující pouze základní entity.

Obrázek 3.10.: Stavový diagram tˇrídy Základní entita.

56

3. Analýza

Obrázek 3.11.: Stavový diagram tˇrídy Pˇrípad.

• Jako Projekt je v kontextu analýzy oznaˇcena cˇ innost smˇerˇ ující k vytvoˇrení jedineˇcného produktu cˇ i služby. Projekt jako koncept podˇrízený pˇrípadu se od ostatních pˇrípadu˚ odlišuje pˇredevším tím, že je možné žádat od agentu˚ finanˇcní dary na jeho podporu. • Událost je událostí kulturní cˇ i spoleˇcenskou, nikoliv událostí v generickém slova smyslu. Agenti se mohou události zúˇcastnit, neziskové organizace jim mohou prodávat prostˇrednictvím zprostˇredkovatelské organizace vstupenky. • Dobrovolnická pozice umožnuje ˇ agentum ˚ zastávat dobrovolnickou cˇ innost v rámci neziskové organizace. • Petice umožnuje ˇ agentum ˚ vyjadˇrovat podporu cˇ i nesouhlas s veˇrejnými záležitostmi.

3.7. Nabídnutí neziskového pˇrípadu veˇrejnosti Dalším klíˇcovým procesem, jímž se zprostˇredkovatelská organizace zabývá, je Nabídnutí neziskového pˇrípadu veˇrejnosti (viz Tabulka 3.4, viz Obrázek 3.13). Neziskové organizace chtˇejí veˇrejnost seznámit se svými projekty, nabídkami dobrovolnictví a peticemi, za úˇcelem získání veˇrejné podpory pro jejich snahy (pˇrípady, causes). Klientská organizace nejprve definuje pˇrípad, který chce nabídnout veˇrejnosti k podpoˇre. Zprostˇredkovatelská organizace poté definici zpracuje a na pokyn neziskové organizace jej zveˇrejní. Tím zaˇcíná fáze podpory pˇrípadu, v jejímž rámci obvykle jednotlivci zprostˇredkovatelské organizaci deklarují svuj ˚ zájem o podporu toho kterého pˇrípadu. Zájem o podporu je zpracován, vyhodnocen a výsledek pˇredán neziskové organizaci. 57

Obrázek 3.12.: Výˇrez diagramu tˇríd - Typologie pˇrípadu. ˚


Požadavek na vytvoˇrení pˇrípadu.

Produkty/služby

Pˇrípad je nabídnut k podpoˇre uživatelum. ˚

Zákazník


Metriky

- Poˇcet provozovaných pˇrípadu˚ za období. - Poˇcet vzniklých podpor za období.

- Poˇcet zapojených uživatelu. ˚ Podmínky

Proces je spuštˇen tehdy, když organizace pocítí potˇrebu využít služeb zprostˇredkovatelské organizace a povˇerˇ í ji, aby nabídla veˇrejnosti její pˇrípad. Podmínkou je to, že organizace je registrována a nemá pozastavený úˇcet.

Dokumenty

- Smluvní podmínky pro neziskové organizace.

Tabulka 3.4.: Tabulka klíˇcového procesu Nabídnutí neziskového pˇrípadu veˇrejnosti.


Požadavek na vytvoˇrení pˇrípadu.

Produkty/služby

Zpracovaný pˇrípad pˇripravený k publikování.

Zákazník


Metriky

- Poˇcet publikovaných pˇrípadu˚ za období.

Podmínky

Proces je spuštˇen tehdy, když organizace požádá o zveˇrejnˇení svého pˇrípadu. Podmínkou je to, že organizace je registrována a nemá pozastavený úˇcet.

Dokumenty

- Smluvní podmínky pro neziskové organizace.

Tabulka 3.5.: Tabulka procesu Zpracování pˇrípadu.

58

3. Analýza

Obrázek 3.13.: Diagram klíˇcového procesu Nabídnutí pˇrípadu veˇrejnosti.

3.7.1. Zpracování pˇrípadu Pˇredtím, než je pˇrípad zprostˇredkovatelskou organizací nabídnut cílovému publiku, je potˇreba jej nejprve zpracovat, k cˇ emuž slouží proces Zpracování pˇrípadu (viz Obrázek 3.14, viz Tabulka 3.5). Jde o obecný proces nabývající v závislosti na konkrétní zpracovávané entitˇe nˇekolika speciálních podob - specializovanou proceduru vyžaduje konkrétnˇe Projekt a Událost. K modelování této specializace jsem se po dlouhém váhání nakonec rozhodl použít subprocesu, ˚ což, jak vˇerˇ ím, neˇciní žádné podstatné obtíže. Všechny instance tohoto procesu však i pˇres tuto specializaci nˇekteré základní cˇ innosti sdílejí. Konkrétnˇe jde o Urˇcení lokace umožnující ˇ zˇrizovateli pˇrípadu upˇresnit místo, kde se pˇrípad nachází, resp. odehraje.

3.7.1.1. Zpracování projektu V rámci zpracování projektu (viz Obrázek 3.15, viz Tabulka 3.6) nezisková organizace nejprve urˇcí, zda vyžaduje, aby se zprostˇredkovatelská organizace a) pokusila získat dostatek finanˇcních prostˇredku˚ na samotnou realizaci projektu, nebo zda b) pouze hledá další finanˇcní prostˇredky na chod projektu již bˇežícího. Projekty prvního druhu (a) jsou po jistou dobu provozovány ve speciálním fundraisingovém režimu a do stádia realizace se dostanou pouze tehdy, pokud se podaˇrí získat neziskovou organizací požadovaný objem penˇez. Ve fázi úvodního zpracování projektu však entita tˇrídy Projekt setrvává stále ve stavu Vytvoˇrena, je do ní pouze zaznamenán uživatelem vybraný režim. Do zvoleného stavu (bˇežný provoz / fundraisingový režim) se projekt dostává až pˇri svém zveˇrejnˇení (viz 3.7.2.1). 59

Obrázek 3.14.: Proces Zpracování pˇrípadu.


Potˇreba zpracovat projekt.

Produkty/služby

Zpracovaný projekt pˇripravený k publikování.

Zákazník


Metriky

- Poˇcet publikovaných projektu˚ za období. - Poˇcet projektu˚ užívajících systému odmˇen. - Poˇcet úspˇešných a neúspˇešných projektu˚ prošlých fundraisingovým režimem.

Podmínky

Proces je spuštˇen tehdy, když chce organizace zveˇrejnit svuj ˚ projekt. K tomu ji muže ˚ vést bud’ finanˇcní motivace, nebo potˇreba projekt zviditelnit. Podmínkou je to, že organizace je registrována a nemá pozastavený úˇcet.

Dokumenty

- Smluvní podmínky pro neziskové organizace. - Uživatelská pˇríruˇcka pro neziskové organizace.

Tabulka 3.6.: Tabulka procesu Zpracování projektu.

60

3. Analýza

Nezisková organizace dále muže ˚ nastavit systém benefitu˚ vztahujících se k finanˇcním darum ˚ od agentu. ˚ Je-li systém benefitu˚ nastaven, uživatel s každým darem od jisté výše celkové cˇ ástky získává nárok na urˇcitou (neziskovou organizací stanovenou) odmˇenu, pˇriˇcemž možné odmˇeny jsou odstupnovány ˇ podle hodnoty daru.7

Obrázek 3.15.: Diagram procesu Zpracování projektu.

Obrázek 3.16.: Diagram stavu˚ entity Projekt. 7 Souˇ casný

návrh poˇcítá s tím, že jednotlivé dary nelze s ohledem na zjištˇení nároku na odmˇenu sˇcítat.

61

Na tomto místˇe také pˇredkládám pˇríslušný diagram stavu˚ entity Projekt. Projekt je nejprve vytvoˇren, pak v rámci procesu Zpracování projektu se mˇení jeho stav na Pˇripraven. Poté je zveˇrejnˇen a pˇrechází v závislosti na pˇredchozím nastavení do stavu Provoz, nebo Fundraisingový režim. Pˇri ukonˇcování tohoto režimu je v rámci procesu Ukonˇcení fundraisingového režimu (viz Obrázek 3.22) rozhodne, zda bude pokraˇcovat v bˇežném provozu, cˇ i zda skonˇcí jako neúspˇešný. 3.7.1.2. Zpracování události Startovací událost

Potˇreba zpracovat událost.

Produkty/služby

Zpracovaná událost pˇripravená k publikování.

Zákazník


Metriky

- Pomˇer jednotlivých typu˚ události. - Pomˇer událostí využívajících možnost nákupu lístku˚ k tˇem, které ji nevyužívají.

Podmínky

Proces je spuštˇen tehdy, když organizace požádá o zpracování události. Podmínkou je to, že organizace je registrována a nemá pozastavený úˇcet.

Dokumenty


Tabulka 3.7.: Tabulka procesu Zpracování události. Netriviální prubˇ ˚ eh má proces Zpracování události (viz Obrázek 3.17, viz Tabulka 3.7). Tvurce ˚ události (ˇclen neziskové organizace) je nejprve dotázán na charakter jím vkládané události. K dispozici jsou následující možnosti: • Bˇežná událost se sice muže ˚ konat opakovanˇe, ale tyto její výskyty jsou v zásadˇe neperiodické, takže je nezbytné vložit vždy všechny konkrétní cˇ asy a data kdy se událost koná. • Periodická událost se koná s jistou periodicitou (týdnˇe, mˇesíˇcnˇe, apod.). Je tedy tˇreba vložit data o periodiˇcnosti události. • Stálá událost je druhem události s výskytem tak cˇ astým, že nemá smysl modelovat její periodicitu (dˇeje se napˇr. každodennˇe). V rámci procesu Nastavení nákupu lístku˚ má tvurce ˚ události dále možnost urˇcit, zda si pˇreje, aby zprostˇredkovatelská organizace též prodávala vstupenky (viz Obrázek 3.18). Pokud ano, správce události musí definovat cenové kategorie, v jejichž rámci budou lístky na konkrétní událost prodávány.8 Charakter nˇekterých událostí dále vyžaduje, aby vstupenky byly prodávány formou místenek, tj. aby bylo možné pˇriˇradit k nim konkrétní sedadlo. V takovém pˇrípadˇe je správce události nejprve požádán, aby zprostˇredkovatelské organizaci zaslal informace o místu konání události a seznam dostupných sedadel, následnˇe je vyzván k pˇrirˇ azení jednotlivých sedadel k dˇríve definovaným cenovým kategoriím.9 Definované informace o místu konání a o všech dostupných sedadlech umožnují ˇ sestavit jakýsi plánek prostor, v nichž se událost odehraje. Tento plánek muže ˚ být posléze zasílán 8 Každá

událost muže ˚ mít svou sadu cenových kategorií. událost muže ˚ mít nejvýše jedno místo konání. Událost opakovaná (resp. mající více svých „konání“) se musí vždy konat na stejném místˇe, je-li místo definováno.

9 Každá

62

3. Analýza

Obrázek 3.17.: Proces Zpracování události. zájemcum ˚ o vstupenky, aby se pˇri nákupu mohli snáze orientovat v nabídce. Jako místo konání jednotlivé události muže ˚ být vybráno bud’ již v minulosti vytvoˇrené místo konání, nebo muže ˚ být vytvoˇreno zcela nové (viz Obrázek 3.19).

3.7.1.3. Zpracování dobrovolnické pozice Zpracování dobrovolnické pozice probíhá bˇežnou formou a popisuje jej tedy proces Zpracování pˇrípadu. Považuji však za vhodné upozornit na jednu duležitou ˚ vˇec, a to distinkci mezi dobrovolnickou pozicí trvalou a jednorázovou. Aˇckoliv je dlouhodobé dobrovolnictví bˇežnˇejší formou, protože i dobrovolníky je k výkonu jejich práce obvykle nutné zaškolit, což s sebou nese jisté náklady jdoucí na vrub neziskové organizace, zejména firmy mohou pˇresto v jistých pˇrípadech preferovat jednorázovou nabídku pro firemní dobrovolníky.

3.7.1.4. Zpracování petice Podobnˇe jednoduchý je též proces zpracování petice. Uživatel založiv petici je zárovenˇ považován za kontaktní osobu pro styk s úˇrady ve smyslu zákona 85/1990 Sb, o právu petiˇc63

Obrázek 3.18.: Proces Nastavení nákupu lístku. ˚

Obrázek 3.19.: Proces Urˇcení místa konání.

64

3. Analýza

ním.10 Pˇri pˇrijetí petice je tˇreba dbát na to, aby byly vyplnˇeny všechny zákonem požadované údaje, zejména adresát petice. Pro diagram tˇríd zachycující všechny podstatné elementy související s peticí viz Obrázek 3.37.

3.7.2. Provoz pˇrípadu Startovací událost

Potˇreba provozovat pˇrípad.

Produkty/služby

Provoz pˇrípadu. Proces konˇcí ukonˇcením provozu pˇrípadu.

Zákazník


Metriky

- Poˇcet provozovaných/pozastavených/ukonˇcených pˇrípadu˚ za období. - Pomˇer projektu˚ užívajících systému odmˇen. - Poˇcet úspˇešných a neúspˇešných projektu˚ prošlých fundraisingovým režimem. - Poˇcet podpor pˇrípadu za období.

Podmínky

Zprostˇredkovatelská organizace musí obdržet pokyn k provozování pˇrípadu. Organizace musí být registrována a nesmí mít pozastavený úˇcet.

Dokumenty


Tabulka 3.8.: Tabulka procesu Provoz pˇrípadu. Byl-li pˇrípad v pˇredchozí fázi zpracován, muže ˚ být nyní provozován (viz Obrázek 3.20, viz Tabulka 3.8). Všechny pˇrípady vykazují spoleˇcné rysy životního cyklu. Jejich provoz muže ˚ být napˇr. neziskovou organizací kdykoliv pozastaven cˇ i uzavˇren. Bˇehem provozu agenti zasílají zprostˇredkovatelské organizaci nabídky podpory, na které je tˇreba adekvátnˇe zareagovat, aby bylo možné nabízenou podporu snadno zprostˇredkovat. ˇ a ukoncení ˇ 3.7.2.1. Zprovoznení provozu projektu Zvláštní pozornost pak zasluhuje speciálnˇe proces Zprovoznˇení projektu (viz Obrázek 3.21). Ve chvíli, kdy je podán vlastníkem pokyn k publikování pˇrípadu, je tˇreba projekt pˇrevést bud’ do stavu Bˇežný provoz cˇ i Fudraisingový režim. Proces Ukonˇcení fundraisingového režimu (viz Obrázek 3.22) je spuštˇen cˇ asovou události právˇe ve chvíli, kdy je ukonˇcen fundraisingový režim projektu. Pokud bylo dosaženo požadovaného finanˇcního limitu, jsou finanˇcní podpory uvolnˇeny, takže je možné provést jejich výplatu neziskové organizaci. Dojde též k pˇrevodu projektu do bˇežného režimu. V opaˇcném pˇrípadˇe peníze putují zpˇet dárcum ˚ (jedná se o proces Navrácení finanˇcních podpor - viz 3.10.6) a projekt ukonˇcí.

3.8. Zprostˇredkování podpory pˇrípadu Dalším klíˇcovým procesem probíhajícím v organizaci je provádˇení cˇ inností, kterými je široké veˇrejnosti usnadnována ˇ podpora zveˇrejnˇených neziskových pˇrípadu. ˚ 10 Viz

ˇ napˇr. Sbírku zákonu˚ [CESKO, 1990]

65

Obrázek 3.20.: Proces zachycující Provoz pˇrípadu.

Obrázek 3.21.: Diagram procesu s názvem Zprovoznˇení projektu.

66

3. Analýza

Obrázek 3.22.: Diagram procesu s názvem Ukonˇcení fundraisingového režimu. Startovací událost

Potˇreba podporovat pˇrípad.

Produkty/služby

Zprostˇredkování podpory pˇrípadu.

Zákazník

Nezisková organizace, Agent, HR manažer (Správce firemního dobrovolnictví), Zamˇestnanec.

Metriky

- Poˇcet finanˇcních / dlouhodobých / ostatních podpor za období.

Podmínky

Pˇrípad musí být publikován a v provozu a podporovatelé musí splnovat ˇ pˇríslušné požadavky na vytvoˇrení podpory.

Tabulka 3.9.: Tabulka procesu Zprostˇredkování podpory pˇrípadu. Pˇrípady je možno podporovat nˇekolika zpusoby. ˚ Spoleˇcné všem zpusob ˚ um ˚ podpory je však to, že zmínˇený klíˇcový proces je vždy zahájen na pˇrání nˇekterého agenta, a že je podpora vždy vázána na urˇcitý typ pˇrípadu. Základní nástin dostupných zpusob ˚ u˚ podpory a pˇríslušné vazby mezi agenty, událostmi a podprocesy jsou zobrazeny na jednoduchém souhrnném procesním diagramu zachycujícím Zprostˇredkování podpory pˇrípadu (viz Obrázek 3.23, viz Tabulka 3.9). I k modelování tohoto procesu jsem použil podprocesu, ˚ jejichž užití je zde oduvodnˇ ˚ eno vztahem specializace - procesy modelované jako podprocesy jsou v zásadˇe specializovanými obdobami obecného procesu, podobnˇe jako v pˇrípadˇe procesu Zpracování pˇrípadu(viz3.7.1). Po probˇehnutí pˇríslušných podprocesu˚ je navíc podpora pˇriˇrazena té komunitˇe, jejímž je podporovatel cˇ lenem (není-li cˇ lenem žádné organizace, není podpora pˇrirozenˇe pˇripsána žádné komunitˇe) a je mu zaslána zpráva o výsledku jeho snahy. Tˇrída Zpráva má zjednodušený životní cyklus patrný z diagramu (viz Obrázek 3.24).

3.8.1. Business entity spojené s podporou Podporu provádí vždy agent a v modelu jsou definovány celkem tˇri její základní tˇrídy: 67

Obrázek 3.23.: Diagram procesu Zprostˇredkování podpory pˇrípadu.

Obrázek 3.24.: Stavový diagram tˇrídy Zpráva. • Podpora je tˇrídou, jejímiž potomky jsou jednak tˇrídy konkrétní (Podpis petice), jednak abstraktní (Finanˇcní podpora a Dlouhodobá podpora). • Dlouhodobá podpora je potomkem tˇrídy Podpora a její specifickou diferencí je trvání v cˇ ase (doba ukonˇcení dlouhodobé podpory se neshoduje s jejím vznikem). Duvodem ˚ je to, že obvykle modeluje nˇejaký vztah trvalého charakteru. Mezi dlouhodobou podporu rˇ adím Dobrovolniˇcení, Firemní dobrovolnictví a Pˇríznivectví. • Finanˇcní podpora je potomkem tˇrídy Podpora a její specifickou diferencí je to, že k její realizaci je tˇreba provést jistý druh platby, cˇ emuž odpovídá též její životní cyklus (viz Obrázek 3.26). Potomkem Finanˇcní podpory jsou Dar a Lístek. Podpora samotná má triviální životní cyklus, tj. cyklus tvoˇrený pouze dvˇema stavy: vytvoˇrení a zánik. Komplexnˇejší jsou však životní cykly potomku, ˚ tj. finanˇcní a dlouhodobé podpory. 68

3. Analýza

Obrázek 3.25.: Model tˇríd zobrazující základní entity spojené s podporou pˇrípadu˚ (zjednodušený orientaˇcní výˇrez).

Obrázek 3.26.: Diagram zachycující životní cyklus tˇrídy Finanˇcní podpora (vlevo) a Dlouhodobá podpora (vpravo).

69

Podporu finanˇcní lze fakticky chápat jako prodávaný produkt - zprostˇredkovatelská organizace s ní zachází v podstatˇe jako s obchodovatelným artiklem zprostˇredkovávaným od neziskových organizací k agentum. ˚ V pˇrípadˇe zájmu agenta o finanˇcní podporu je nejprve vytvoˇrena, pak rezervována (objednána), následnˇe bud’ zaplacena cˇ i zrušena; zaplacením dochází k samotné její realizaci. Za jistých podmínek je dále možno již realizovanou podporu navrátit, tj. poslat peníze zpˇet tˇem, kdo ji realizovali. Pokud vše dobˇre dopadne, získané peníze jsou nakonec odeslány neziskové organizaci. Podpora dlouhodobá je více zavazující, než nˇekteré jiné druhy podpory a jejím vznikem vzniká též reálný dlouhodobý vztah - je proto ve vˇetšinˇe pˇrípadu˚ nezbytné, aby pˇred vznikem nejdˇríve prošla procesem schválení, cˇ emuž odpovídá i sít’ stavu, ˚ jimiž muže ˚ procházet. Z diagramu je patrné, že podpora je nejprve pˇredbˇežnˇe registrována. V tomto stavu ještˇe entita nereprezentuje reálnˇe existující vztah k nˇekterému pˇrípadu, ale znaˇcí pouze jakousi možnost jeho vzniku, tj. cˇ istou potencialitu. Dojde-li k realizaci podpory, muže ˚ být tato na požádání kdykoli ukonˇcena.

ˇ dar projektu 3.8.2. Financní Startovací událost

Potˇreba darovat.

Produkty/služby

Pˇríprava na pˇrevod daru.

Zákazník

Nezisková organizace, Uživatel, Agent.

Metriky

- Objem daru˚ jednotlivým projektum ˚ za období. - Poˇcet odmˇen za období.

Podmínky

Aby byla podpora realizována, musí dojít k platbˇe. Požaduje-li uživatel odmˇenu, musí na ní mít právo.

Dokumenty

- Uživatelská pˇríruˇcka pro koncové uživatele.

Tabulka 3.10.: Tabulka procesu Finanˇcní dar projektu. Podpora projektu darem (viz Obrázek 3.27, viz Tabulka 3.10) muže ˚ být dvojího druhu: projekt muže ˚ být provozován bud’ rovnou v a) bˇežném, nebo b) nejprve ve zvláštním fundraisingovém režimu (z nˇejž poté muže ˚ do bˇežného pˇrejít) - z tˇechto variant volí vlastník, tj. nezisková organizace. Ve zvláštním fundraisingovém režimu (b) mohou být pouze projekty doposud v reálném svˇetˇe nezapoˇcaté, které ke svému spuštˇení potˇrebují nejprve získat urˇcitý obnos finanˇcních prostˇredku. ˚ Pˇríznivcum ˚ projektu bude v rámci tohoto režimu dán pouze jistý omezený cˇ as na to, aby nashromáždili dostateˇcný finanˇcní obnos, pˇriˇcemž minimální finanˇcní limit, jehož je tˇreba dosáhnout, urˇcuje nezisková organizace sama. Pokud se cíle dosáhnout nepodaˇrí, peníze jsou vráceny podporovatelum ˚ a projekt nebude realizován. V pˇrípadˇe, že projekt v realitˇe již probíhá, nebo pokud k jeho zprovoznˇení není tˇreba fundraisingové kampanˇe, pˇrechází rovnou do režimu bˇežného provozu (a). Agenti na nˇej mohou i nadále pˇrispívat, ale nyní již bez cˇ asového cˇ i finanˇcního limitu. Pokud se agent rozhodne darovat finanˇcní obnos, je do jeho nákupního košíku pˇridán dar a agent se muže ˚ kdykoliv rozhodnout provést platbu.11 Proces je ukonˇcen v okamžiku, v nˇemž je doruˇcena žádost o ukonˇcení jeho podpory. Po vložení daru do objednávky je agent v 11 Více

viz 3.10.

70

3. Analýza

Obrázek 3.27.: Diagram procesu s názvem Finanˇcní dar projektu.

pˇrípadˇe, že mu vznikl nárok na odmˇenu, dotázán, zda chce tento nárok uplatnit. Má-li agent o odmˇenu zájem, ale doposud nevyplnil své údaje a není tedy o nˇem nic známo, je vyzván k jejich zaslání. Zprostˇredkovatelská organizace zasílání odmˇen agentum ˚ neprovádí, pouze neziskovým organizacím sdˇeluje, komu odmˇena náleží. Souˇcástí popisovaného procesu je také koproces Vložení finanˇcní podpory do košíku (viz Obrázek 3.28). Jde o drobný proces využívaný také v pˇrípadˇe nákupu lístku˚ na událost. V jeho rámci je nejprve na základˇe informací o konkrétním pˇrípadu pˇredbˇežnˇe registrována ˇ finanˇcní podpora a dále, v pˇrípadˇe, že ještˇe neexistuje, též instance tˇrídy Objednávka. Cerstvˇ e vytvoˇrená objednávka je vždy ve stavu Nákupní košík, z cˇ ehož je zˇrejmé, že prozatím není závazná.12 Tˇrídy spojené s finanˇcním darováním a s odmˇenami jsou znázornˇeny na následujícím diagramu (viz Obrázek 3.29). Z diagramu je patrné, že dar muže ˚ být pˇripsán také pˇrímo neziskové organizaci, aniž by byl specifikován projekt, na nˇejž mají peníze putovat. Z procesního hlediska je postup zaslání daru urˇceného pˇrímo neziskové organizaci neodlišitelný od daru na konkrétní projekt a rˇ ídí se tedy totožným schematem. Jediným podstatným rozdílem je fakt, že není-li pˇri darování specifikován konkrétní projekt, nevzniká agentovi ani nárok na žádnou odmˇenu, nebot’ odmˇeny lze vázat pouze na projekty. Tato skuteˇcnost souvisí se snahou zprostˇredkovatelské organizace motivovat dárce, aby své finanˇcní dary vázali na 12 Ke

stavum ˚ tˇrídy Objednávka viz Obrázek 3.48.

71

Obrázek 3.28.: Diagram procesu s názvem Vložení finanˇcní podpory do košíku.

Obrázek 3.29.: Tˇrídy vážící se k procesum ˚ spojeným s darováním. konkrétní projekty a pˇrispívali tak k transparentnˇejšímu využívání finanˇcních prostˇredku˚ neziskovými organizacemi.

3.8.3. Podpora události nákupem lístku Obdobným procesem, jako je Podpora projektu darem, je i proces Podpora události nákupem lístku (viz Obrázek 3.30, viz Tabulka 3.11). Nákup vstupenky na událost poˇrádanou nezisko72

3. Analýza


Požadavek na nákup lístku˚ na událost.

Produkty/služby

Zprostˇredkování nákupu lístku˚ na událost.

Zákazník

Nezisková organizace, Uživatel.

Metriky

- Poˇcet zakoupených lístku˚ za období. - Pomˇer lístku˚ rezervovaných na místo a volných. - Poˇcet odmˇen za období.

Podmínky

Aby byl nákup dokonˇcen, musí dojít k platbˇe. Lístky muže ˚ zakoupit pouze registrovaný uživatel.

Dokumenty

- Podmínky prodeje vstupenek. - Obchodní podmínky. - Uživatelská pˇríruˇcka pro koncové uživatele.

Tabulka 3.11.: Tabulka procesu Podpora události nákupem lístku. vou organizací je totiž formou finanˇcní pomoci a lze jí chápat jako urˇcitou formu daru, za nˇejž je ovšem poskytována protislužba. Nejprve je potˇreba zodpovˇedˇet otázku, zda jsou na agentem požadovanou událost (resp. konání události) dostupné lístky. V kladném pˇrípadˇe je agentovi, který má o lístky zájem, bud’ a) zaslán seznam volných sedadel, je-li nákup lístku spojen též s rezervací sedadla, resp. pouze b) požadavek na specifikaci poˇctu vstupenek v opaˇcném pˇrípadˇe. Agent posléze v závislosti na zmínˇeném kritériu bud’ (a) vybere sedadla, nebo (b) pouze zvolí poˇcet vstupenek. Je-li souˇcástí rezervace též lístek spojený s urˇcitým sedadlem, toto sedadlo je od této chvíle a po dobu trvání rezervace považováno za rezervované. Možnost nakoupit lístek muže ˚ být kdykoliv ukonˇcena, a to na základˇe žádosti neziskové organizace, zásahem administrátora nebo prostým uplynutím konání události. K nákupu lístku se váží také tˇrídy, které výše nebyly uvedeny, zejména pak tˇrídy Místo konání, Konání události, Lístek, Cenová kategorie, Sedadlo a Adresa. Pro názornost je uvádím na diagramu na obrázku 3.31.

ˇ 3.8.4. Vyjednání dobrovolnicení Startovací událost

Požadavek na vznik dobrovolniˇcení.

Produkty/služby

Dojednání dobrovolniˇcení.

Zákazník

Nezisková organizace, Uživatel, Firma.

Metriky

- Poˇcet zprostˇredkovaných dobrovolnictví za období. - Pomˇer dlouhodobých a krátkodobých dobrovolniˇcení.

Podmínky

- Aby bylo dobrovolniˇcení sjednáno, musí být schváleno a dobrovolnická pozice musí být aktivní. - Žadatel musí být registrovaný uživatel.

Dokumenty

- Uživatelská pˇríruˇcka pro koncové uživatele.

Tabulka 3.12.: Tabulka procesu Vyjednání dobrovolniˇcení. Jak bylo naznaˇceno výše, zprostˇredkovatelská organizace by mˇela jednoduchým zpuso˚ bem zprostˇredkovávat také dobrovolnickou práci (viz Obrázek 3.32, viz Tabulka 3.12), tj. 73

Obrázek 3.30.: Diagram procesu s názvem Podpora události nákupem lístku.

Obrázek 3.31.: Tˇrídy vztahující se k nákupu lístku. ˚ 74

3. Analýza

Obrázek 3.32.: Diagram procesu s názvem Vyjednání dobrovolniˇcení. umožnit neziskovým organizacím nabízet dobrovolnické pozice veˇrejnosti a agentum ˚ na tuto poptávku odpovídat. Je zˇrejmé, že oblast dobrovolnické práce není tržním prostˇredím, pˇrinejmenším ne v bˇežném slova smyslu, nebot’ dobrovolníkum ˚ není vyplácena finanˇcní odmˇena - pˇresto zde lze hovoˇrit o odmˇenˇe nepenˇežního charakteru (spoleˇcenské uznání, dobrý pocit z vykonané práce, apod.). Neziskové organizace zasílají zprostˇredkovatelské organizaci informace o volných dobrovolnických pozicích (viz 3.7.1.3), ty jsou posléze nabídnuty uživatelum. ˚ Proces je spuštˇen ve chvíli, kdy žadatel (tj. nˇekterý z pˇrihlášených uživatelu) ˚ zašle žádost o urˇcitou dobrovolnickou pozici. Tato žádost je poté organizací vyˇrízena v nˇekolika krocích. Dobrovolnicˇ ení je nejprve pˇredbˇežnˇe registrováno a pˇripojeno k žádosti o dobrovolnickou pozici. Stav pˇredbˇežné registrace znamená, že dobrovolniˇcení ještˇe není realizováno, ale je vedeno jako pouhá potencialita. Adresát žádosti pak provede výbˇer vhodného kandidáta a vybrané žádosti schválí, cˇ ímž dobrovolniˇcení pˇrechází do stavu schváleno.

3.8.5. Firemní dobrovolnictví Dobrovolníci se však nerekrutují pouze z rˇ ad široké veˇrejnosti, ale významným dodavatelem jejich práce jsou v rostoucí míˇre též firmy. Firemní dobrovolnictví je formou naplnování ˇ 75

public relations strategie mnoha spoleˇcností, protože pˇrispívá k dobrému jménu organizace. Zprostˇredkovatelská organizace tedy musí HR managerum ˚ firem usnadnit jejich práci a umožnit jim a) snadný výbˇer z dostupných dobrovolnických pozic a b) oslovit zamˇestnance s vybranou nabídkou neziskových organizací. Samotné vyjednávání firemního dobrovolnictví (viz Tabulka 3.13) je strukturálnˇe velmi podobné pˇredchozímu procesu vyjednávání dobrovolniˇcení (viz 3.8.4). Pro každou dobrovolnickou pozici, na níž mohou firemní zamˇestnanci participovat, je zˇrízena zvláštní entita firemního dobrovolnictví - firemní dobrovolnictví je tak chápáno jako vztah firmy ke konkrétním dobrovolnickým pozicím, na jehož základˇe vznikají nová dobrovolniˇcení zamˇestnancu. ˚ Zprostˇredkovatelská organizace reaguje na zájem firmy tím, že pˇredbˇežnˇe firemní dobrovolnictví registruje a odešle žádost neziskové organizaci, která ji vyˇrídí (viz Obrázek 3.33). Startovací událost

Požadavek na vznik firemního dobrovolnictví.

Produkty/služby

Dojednání firemního dobrovolnictví.

Zákazník

Nezisková organizace, Firma.

Metriky

- Poˇcet zprostˇredkovaných firemních dobrovolnictví za období. - Poˇcet odpracovaných hodin firmou. - Pomˇer dlouhodobých a krátkodobých dobrovolniˇcení.

Podmínky

Aby bylo firemní dobrovolnictví sjednáno, musí být schváleno neziskovou organizací a požadovaná dobrovolnická pozice musí být aktivní.

Dokumenty

- Uživatelská pˇríruˇcka pro firmy.

Tabulka 3.13.: Tabulka procesu Vyjednání firemního dobrovolnictví. Uzavˇrení dohody o firemním dobrovolnictví je však pouze prvním nutným krokem otevírajícím dveˇre ke konkrétnímu vyjednávání o dobrovolnické pomoci. Získávání dobrovolníku˚ je provádˇeno to dvˇema základními zpusoby: ˚ a) zamˇestnanec se sám iniciativnˇe pˇrihlásí na nˇekterou firmou schválenou dobrovolnickou pozici, nebo b) správce firmy (jímž je obvykle HR manažer) oslovuje zamˇestnance a vyzve je k podpoˇre firemního dobrovolnictví. V obou pˇrípadech pˇritom platí, že zamˇestnanci se mohou stát firemními dobrovolníky pouze na pozicích, na nˇež je firmou firemní dobrovolnictví sjednáno.13 Firemní dobrovolnictví muže ˚ být kdykoliv ukonˇceno jednostranným aktem bud’ na pˇrání správce firmy cˇ i neziskové organizace - v takovém pˇrípadˇe je ukonˇceno též pusobení ˚ všech firemních dobrovolníku˚ na dané pozici. Má-li nˇekterý ze zamˇestnancu˚ zájem o nˇekterou z pozic v rámci firemního dobrovolnictví, je mu zprostˇredkovatelskou organizací zaslán požadavek na výbˇer z dostupných pozic, které jsou firemním dobrovolnictvím zprostˇredkovány. Poté je vytvoˇrena žádost a k ní náležející instance tˇrídy Dobrovolniˇcení vztahující se k této pozici, ovšem opˇet ve stavu pˇredbˇežné registrace. Pravomoc schvalování dobrovolníku˚ a zodpovˇednost za ni je v tomto pˇrípadˇe od správce neziskové organizace delegována na správce firmy. Pokud je žádost schválena, zamˇestnanec se stává dobrovolníkem, v opaˇcném pˇrípadˇe je instance tˇrídy Dobrovolniˇcení zneplatnˇena. Tato alternativa je modelována procesem pod názvem Kandidatura zamˇestnance na dobrovolnickou pozici (viz Obrázek 3.34). 13 Jako

soukromá osoba muže ˚ naproti tomu zamˇestnanec žádat o jakoukoli dostupnou pozici.

76

3. Analýza

Obrázek 3.33.: Diagram procesu s názvem Vyjednání firemního dobrovolnictví.

Chce-li naopak HR manažer firmy oslovit své zamˇestnance s nabídkou dobrovolnické pozice a nabídnout jim možnost altruistické práce (b), nejprve vybere ze seznamu registrovaných zamˇestnancu˚ ty, o jejichž oslovení má zájem (viz proces Oslovení zamˇestnancu˚ a tentýž Obrázek). Pro každého vybraného zamˇestnance je pak spuštˇena instance procesu Vyjednání dobrovolniˇcení, v jehož rámci je za žadatele považován HR manažer a za adresáta žádosti zamˇestnanec. V závislosti na konkrétních rozhodnutích zamˇestnancu˚ jsou dobrovolnické pozice rovnou obsazovány. Z toho je patrné, že nezisková organizace deleguje v pˇrípadˇe firemního dobrovolnictví rozhodnutí o pˇrijetí konkrétního dobrovolníka na firmu. Následnˇe uvádím též relevantní výsek diagramu tˇríd spojených s firemním dobrovolnictvím, na nˇemž jsou pˇríslušné patrné relace, do nichž entity vstupují (viz Obrázek 3.35). Tˇrída zamˇestnání modeluje vztah zamˇestnance k firmˇe a je potomkem tˇrídy dlouhodobá podpora.

3.8.6. Podpis petice Petici lze podporovat pˇredevším prostˇrednictvím podpisu (viz Obrázek 3.36, viz Tabulka 3.14). Proces Podepsání petice je velmi jednoduchý, v jeho prubˇ ˚ ehu je však nezbytné rozlišit mezi známými a neznámými uživateli. Od tˇech již známých nebudou požadovány žádné osobní informace. Od neznámých je tˇreba tyto informace teprve získat, protože na petici není možné participovat anonymnˇe. Jak uvádí zákon cˇ . 85/1990 Sb.,14 podepsaný obˇcan musí uvést své jméno, pˇríjmení a bydlištˇe. Podepisování petice muže ˚ být kdykoliv ukonˇceno na základˇe žádosti neziskové organizace cˇ i zásahem administrátora. 14 Viz

ˇ [CESKO, 1990].

77

Obrázek 3.34.: Diagram procesu˚ s názvem Kandidatura zamˇestnance na dobrovolnickou pozici (vlevo) a Oslovení zamˇestnancu˚ (vpravo).

Obrázek 3.35.: Diagram tˇríd spojených s procesy firemního dobrovolnictví.

78

3. Analýza

Obrázek 3.36.: Diagram procesu s názvem Podepsání petice. Startovací událost

Požadavek na podpis petice.

Produkty/služby

Zprostˇredkování podpisu petice.

Zákazník

Nezisková organizace, Agent.

Metriky

- Poˇcet podpisu˚ petice za období.

Podmínky

Petice musí být publikována.

Dokumenty

- Uživatelská pˇríruˇcka pro firmy. - Zákon cˇ . 85/1990 Sb. o právu petiˇcním.

Tabulka 3.14.: Tabulka procesu Podepsání petice. Pro vˇetší názornost uvádím též diagram tˇríd souvisejících s peticí a jejím podpisem (viz Obrázek 3.37). Z nˇej je patrné, že Petice je potomkem Pˇrípadu, zatímco tˇrída Podpis petice je potomkem Podpory. Petice samotná má jeden jediný vlastní atribut, kterým je text, nebot’ všechny ostatní potˇrebné atributy dˇedí od pˇredku. ˚ Podpis petice je dokonce zcela bez atributu˚ - duvodem ˚ existence této tˇrídy je pˇredevším fakt, že tˇrídu Podpora považuji za abstraktní entitu.

ˇ procedury 3.9. Registracní Aby uživatelé a organizace mohli využívat služeb zprostˇredkovatelské organizace v plné výši, musejí se nejprve registrovat. Projdou-li procesem registrace úspˇešnˇe, stávají se klienty zprostˇredkovatelské organizace. Každý druh klienta pˇritom prochází odlišným procesem registrace v závislosti na tom, jak silný závazek registrací vzniká. Nejsložitˇejším procesem 79

Obrázek 3.37.: Diagram tˇríd souvisejících s podpisem petice.

prochází nezisková organizace, velmi jednoduchou proceduru musí absolvovat bˇežný uživatel.

3.9.1. Registrace uživatele


Požadavek na registraci pˇrijat.

Produkty/služby

Registrace uživatele, aby mohl plnˇe využívat nabízené služby.

Zákazník

Agent.

Metriky

- Poˇcet registrovaných uživatelu˚ za období.

Podmínky

Uživatel musí náležitˇe vyplnit všechny údaje o sobˇe.

Dokumenty

- Podmínky užívání služeb. - Zákon cˇ . 101/2000 Sb., o ochranˇe osobních údaju˚ a o zmˇenˇe dalších zákonu. ˚

Tabulka 3.15.: Tabulka procesu Registrace uživatele.

Podpurný ˚ proces Registrace uživatele (viz Obrázek 3.38, viz Obrázek 3.15) popisuje zpusob, ˚ jakým probíhá založení uživatelského úˇctu. Agent v prvním kroku zašle své osobní údaje (a zejména svou e-mailovou adresu). Je provedena kontrola jeho požadavku a je požádán o udˇelení souhlasu s podmínkami užívání služeb. Posléze je zasláním kontrolní zprávy do jeho poštovní schránky zkontrolován též jeho email, jenž uživatel vyplnil v pˇrihlášce. Pokud agent ve stanoveném cˇ ase z e-mailu odpoví, je jeho úˇcet aktivován.15 Pro úplnost uvádím také stavový diagram tˇrídy Uživatel, aby byla snadno dohledatelná vazba tohoto procesu na životní cyklus entity. Uživatel je nejprve vytvoˇren, jeho úˇcet je pak aktivován a muže ˚ být kdykoli ukonˇcen. 15 Tˇrída

Uživatel zde reprezentuje uživatelský úˇcet.

80

3. Analýza

Obrázek 3.38.: Diagram procesu s názvem Registrace uživatele.

Obrázek 3.39.: Stavový diagram tˇrídy Uživatel.

81

3.9.2. Registrace neziskové organizace


Pˇríchod vstupního dotazníku.

Produkty/služby

Registrace neziskové organizace, aby mohla plnˇe využívat nabízené služby.

Zákazník


Metriky

- Poˇcet registrovaných neziskových organizací za období.

Podmínky

- Organizace musí projít kontrolou. - Žadatelem musí být registrovaný uživatel.

Dokumenty

- Podmínky užívání služeb. - Smlouva o poskytování služeb.

Tabulka 3.16.: Tabulka procesu Registrace neziskové organizace.

O nˇeco složitˇejším procesem je Registrace organizace (viz Tabulka 3.16). V jeho prubˇ ˚ ehu je totiž nezbytné podepsat smlouvu, nebot’ vztah mezi zprostˇredkovatelskou organizací a organizací neziskovou je vztahem obchodním. Lze totiž oˇcekávat, že zprostˇredkovatelská organizace bude od neziskových organizací vybírat urˇcité poplatky za poskytované služby. Organizace je registrována tehdy, pokud není zjištˇen žádný duvod, ˚ který by tomu bránil (napˇr. špatná povˇest neziskové organizace, nesrovnalosti v úˇcetnictví, negativní zprávy v tisku, apod.) a pokud je náležitˇe podepsána smlouva. Poté, co žadatel obdrží smlouvu, má možnost ji bud’ podepsat nebo odmítnout a celý registraˇcní proces tak zrušit. Žadatel se v prubˇ ˚ ehu registrace neziskové organizace stává jejím administrátorem. S procesem Registrace neziskové organizace se pojí tˇrída Smlouva, jejíž zasazení do celku procesu je zˇrejmé z diagramu tˇríd (viz Obrázek 3.40). Smlouva, aby vešla v platnost, musí být podepsána dvˇema a více agenty. Výše uvedený proces je vhodné porovnat také se stavovým diagramem tˇrídy Organizace (viz obrázek 3.42) a pˇredevším Smlouva (viz obrázek 3.43). Smlouva je nejprve podepsána zprostˇredkovatelskou organizací, poté neziskovou organizací, cˇ ímž vchází v platnost (jedná se o stav Podepsána NNO). Pˇred podepsáním obˇema stranami muže ˚ být smlouva zrušena, cˇ ímž dochází k odstoupení od smlouvy.

Obrázek 3.40.: Diagram tˇríd souvisejících s procesem Registrace neziskové organizace.

82

3. Analýza

Obrázek 3.41.: Diagram procesu s názvem Registrace neziskové organizace.

83

Obrázek 3.42.: Stavový diagram tˇrídy Organizace.

Obrázek 3.43.: Stavový diagram tˇrídy Smlouva.

84

3. Analýza

3.9.3. Registrace firmy Startovací událost

Pˇríchod vstupního dotazníku firmy.

Produkty/služby

Registrace firmy, aby mohla plnˇe využívat nabízené služby.

Zákazník

Firma.

Metriky

- Poˇcet registrovaných firem organizací za období.

Podmínky

- Firma musí projít kontrolou. - Žadatelem musí být registrovaný uživatel.

Dokumenty

- Podmínky užívání služeb.

Tabulka 3.17.: Tabulka procesu Registrace firmy. Obdobným procesem registrace jako nezisková organizace prochází také firma (viz Tabulka 3.17). Její proces je však zjednodušený, nebot’ k pˇrijetí firmy není potˇreba podepisovat smlouvu - staˇcí její souhlas s podmínkami využívání služeb organizace. Žadatel se v pru˚ bˇehu registrace neziskové organizace stává jejím administrátorem. Po pˇrijetí vstupního dotazníku musí pracovník zprostˇredkovatelské organizace osobnˇe pˇrekontrolovat vstupní dotazník a dodané údaje o firmˇe, a to pokud možno z nezávislých zdroju. ˚ Z digitální databáze tiskovin muže ˚ také zjistit, zda nemá firma špatnou povˇest. Poté vydá rozhodnutí o registraci cˇ i odmítnutí registrace firmy. Jakkoliv proces dopadne, žadateli je vždy zaslána zpráva o výsledku registrace.

3.9.4. Registrace komunity Startovací událost

Požadavek na vytvoˇrení komunity.

Produkty/služby

Registrace uživatelské komunity.

Zákazník

Uživatel.

Metriky

- Poˇcet registrovaných komunit za období.

Podmínky

- Žadatelem musí být registrovaný uživatel.

Tabulka 3.18.: Tabulka procesu Registrace komunity. Mnohem jednodušším procesem vzhledem k pˇredchozím je Registrace komunity (viz Tabulka 3.18). Ta není vázána na žádnou kontrolu cˇ i souhlas, ale je vytvoˇrena na požádání libovolného registrovaného uživatele, který doposud není cˇ lenem žádné jiné komunity.

ˇ 3.9.5. Clenství v komuniteˇ ˇ Clenem komunity muže ˚ být pouze registrovaný uživatel, pˇriˇcemž platí, že každý muže ˚ být cˇ lenem nejvýše jedné komunity. Komunity sdružují agenty na základˇe urˇcitých sdílených vlastností, napˇr. zájmu, ˚ koníˇcku, ˚ apod. Stane-li se agent souˇcástí komunity, všechny jeho podpory jdou od této chvíle spojeny také s jeho komunitou. (viz proces Vytvoˇrení podpory pˇrípadu v 3.8). Komunity tak lze hodnotit podle jejich úspˇešnosti v získávání podpor pro neziskové organizace. 85

Obrázek 3.44.: Diagram procesu Registrace firmy.

Obrázek 3.45.: Diagram procesu Registrace komunity.

86

3. Analýza

ˇ Obrázek 3.46.: Diagram procesu Clenství v komunitˇe. Agent se stává cˇ lenem komunity na vlastní žádost, není potˇreba souhlasu správce komunity, ˇ stejnˇe jednoduše muže ˚ z komunity také odejít, jak je patrno z diagramu procesu Clenství v komunitˇe (viz Obrázek 3.46).

3.10. Objednávky a platby Patrnˇe nejzajímavˇejším druhem podpory neziskových pˇrípadu˚ je podpora finanˇcní. Je to pˇredevším ona, z níž plynou zprostˇredkující organizaci výnosy. Aby mohla být finanˇcní podpora realizována, je potˇreba provést finanˇcní transakci, ovšem nikoliv pˇrímo, tj. od agenta k neziskové organizace, ale skrze sbˇerný úˇcet zprostˇredkující organizace, která si z celkového objemu transakce strhne jistou provizi.

ˇ 3.10.1. Dokoncení objednávky Startovací událost

Požadavek na dokonˇcení objednávky.

Produkty/služby

Zprostˇredkování finanˇcní podpory.

Zákazník


Metriky

- Poˇcet a celkový objem objednaných finanˇcních podpor za období.

Podmínky

Musí již existovat objednávka.

Dokumenty


Tabulka 3.19.: Tabulka procesu Dokonˇcení objednávky. Výše (viz napˇr. Obrázek 3.27) bylo naznaˇceno, jakým zpusobem ˚ dochází k pˇridávání položek do objednávky, resp. nákupního košíku. Ve chvíli, kdy agent uzná, že jeho košík je již uspokojivˇe naplnˇen, muže ˚ se rozhodnout nákup podpory dokonˇcit. V tu chvíli se spustí 87

proces Dokonˇcení objednávky (viz Obrázek 3.47, viz Tabulka 3.19), jehož prvním krokem je rezervování objednávky; pokud je pˇredmˇetem objednávky omezený zdroj (typicky sedadlo vázané na vstupenku na událost), nikdo si ji od této chvíle nemuže ˚ objednat. Tato rezervace je zrušena automaticky po urˇcité dobˇe, pokud nedošlo k platbˇe, nebo na žádost agenta cˇ i neziskové organizace; vˇcasné provedení platby je tak pro agenta jediným možným zpuso˚ bem, jak zrušení pˇredejít. Dojde-li ke zrušení objednávky, jsou pˇrirozenˇe zrušeny i všechny rezervované finanˇcní podpory. Není-li objednavatel registrovaným uživatelem, je bezprostˇrednˇe po rezervaci vyzván k vyplnˇení osobních údaju˚ (jméno, adresa, e-mail). Tyto údaje jsou uloženy do novˇe vzniklé instance tˇrídy Agent. Pokud agent vznese požadavek na provedení platby, je platba podle objednávky vytvorˇ ena a provedena podle schématu procesu Platba (viz Obrázek 3.50). Platba nemusí být provedena ihned, avšak pokud dojde k okamžitému uhrazení požadované cˇ ástky, je finanˇcní podpora též okamžitˇe potvrzena a agentovi je nabídnuta možnost zviditelnˇení právˇe realizované podpory (viz Obrázek 3.56). V pˇrípadˇe asynchronní platby pˇrevodem, jejíž provedení muže ˚ v závislosti na okolnostech trvat i nˇekolik dní, jsou tyto závˇereˇcné procedury provedeny až ex post. Na diagramu (viz Obrázek 3.48) jsou zobrazeny všechny pˇrípustné stavy tˇrídy Objednávka. Pˇri vzniku se stává nákupním košíkem, Poté muže ˚ být rezervována, potvrzena cˇ i zrušena.

3.10.2. Platba Startovací událost

Potˇreba provést platbu.

Produkty/služby

Umožnˇení provedení platby.

Zákazník

Agent.

Metriky

- Poˇcet a celkový objem plateb za období. - Pomˇer mezi jednotlivými platebními metodami.

Podmínky

- Platba již musí být vytvoˇrena a ve stavu pˇredbˇežné registrace.

Dokumenty

- Podmínky užívání služeb. - Smlouva s bankovním ústavem.

Tabulka 3.20.: Tabulka procesu Platba. Proces Platba (viz Tabulka 3.20) zachycuje na konceptuální úrovni pˇrevod finanˇcních prostˇredku˚ od jednoho držitele ke druhému. Postup samotné platby se liší podle toho, zda agent-plátce volí a) platbu platební kartou, resp. b) pˇrevodem z úˇctu.16 Pˇri využití možnosti (a) nic nebrání tomu, aby byla platba ihned realizována. Údaje o platbˇe jsou zaslány bance (resp. platební bránˇe), skrze níž má být transakce provedena. Banka se poté pokusí transakci realizovat; v závislosti na výsledku této operace je vytvoˇrená instance platby bud’ potvrzena, nebo zrušena. V pˇrípadˇe platbou pˇrevodem z úˇctu (b) je situace jednodušší pouze zdánlivˇe. Plátci jsou zaslány informace o bankovním spojení (ˇcíslo úˇctu, cˇ ástka, vygenerovaný variabilní symbol) a vzniká pˇredpoklad, že v nˇekolika dalších dnech bude platba realizována. 16 Analýza

v rámci této práce poˇcítá prozatím pouze s tˇemito dvˇema metodami. Snadno však lze návrh rozšíˇrit napˇríklad o platby skrze elektronické platební penˇeženky, jejichž prubˇ ˚ eh se nebude pˇríliš lišit od platby kartou.

88

3. Analýza

Obrázek 3.47.: Diagram procesu s názvem Dokonˇcení objednávky.

Obrázek 3.48.: Stavový diagram tˇrídy Objednávka. 89

Obrázek 3.49.: Stavový diagram pro tˇrídu Platba.

Obrázek 3.50.: Diagram procesu s názvem Platba. Procesu odpovídá také životní cyklus tˇrídy Platba - nejdˇríve je pˇredbˇežnˇe registrována (opˇet jako pouhá potencialita, nikoliv jako reálný stav), poté je bud’ zaplacena, nebo zrušena (viz Obrázek 3.49). Do zvláštního stavu probíhá se platba dostane pouze tehdy, jedná-li se o asyn90

3. Analýza

chronní platbu, tj. napˇr. platbu pˇrevodem. Její prubˇ ˚ eh není okamžitý, ale muže ˚ trvat i nˇekolik dní.

3.10.3. Spárování plateb Proces, který je zodpovˇedný doˇrešení asynchronních plateb, pˇredevším pˇrevodu˚ z úˇctu, nese název Spárování plateb (viz Obrázek 3.51). Mezi procesem Platba a Spárování plateb neexistuje žádná pˇrímá událostní vazba, aˇc jsou oba pomˇernˇe silnˇe svázány vˇecnˇe. Spárování plateb je totiž spouštˇeno výhradnˇe na základˇe události pˇrijetí výpisu transakcí na bankovním úˇctu. Variabilní symboly novˇe došlých plateb zmínˇených na výpisu transakcí jsou v rámci cˇ innosti Potvrzení došlých plateb porovnány s doposud nepotvrzenými platbami (o nichž zprostˇredkovatelská organizace vede zápisy) a došlé platby jsou potvrzeny. Objednávky pˇríslušející k potvrzeným platbám jsou posléze považovány za uhrazené a dojde tím k aktualizaci pˇríslušných finanˇcních podpor (viz 3.10.4). Nakonec je agentovi nabídnuto zviditelnˇení novˇe realizovaných podpor.

Obrázek 3.51.: Diagram procesu s názvem Spárování plateb.

3.10.4. Uzavˇrení objednávky Je-li objednávka uhrazena, objednané finanˇcní podpory zmˇení svuj ˚ stav, a to bud’ na stav a) zadržovaná, nebo b) realizovaná (viz Obrázek 3.52). Realizované platby mohou být zaslány na úˇcet neziskové organizace pˇri nejbližší vhodné pˇríležitosti. Zadrženy jsou naproti tomu platby za finanˇcní podporu na projekty, které jsou ve fundraisingovém režimu. Zprostˇredkovatelská organizace o tˇechto finanˇcních podporách drží informaci, že agentempodporovatelem již byla provedena pˇríslušná platba, ale nemuže ˚ být prozatím zaslána neziskové organizaci, nebot’ není jisté, zda bude pˇrípad, na nˇejž byly finanˇcní prostˇredky zaslány, vubec ˚ realizován. Pokud fundraisingový režim skonˇcí úspˇešnˇe, je platba odeslána 91

Obrázek 3.52.: Diagram procesu s názvem Uzavˇrení objednávky.

neziskové organizaci, v opaˇcném pˇrípadˇe putuje zpˇet jednotlivým podporovatelum ˚ (viz 3.10.6).

ˇ neziskovým organizacím 3.10.5. Pˇrevod penez


ˇ provést platby vuˇ Cas ˚ ci NNO.

Produkty/služby

Zaslání obnosu, který neziskovým organizacím náleží.

Zákazník


Metriky

- Poˇcet a celkový objem plateb NNO za období. - Celková výše provize za období.

Podmínky

- Smlouva s bankovním ústavem.

Dokumenty

- Smlouva s neziskovou organizací. - Podmínky užívání služeb.

Tabulka 3.21.: Tabulka procesu Pˇrevod penˇez neziskovým organizacím.

Poslední duležitou ˚ finanˇcní operací je pˇrevedení získaných finanˇcních prostˇredku˚ neziskovým organizacím (viz Obrázek 3.53, viz Tabulka 3.21). Ten je provádˇen na periodické bázi (mˇesíˇcní), takže celková cˇ ástka zaslaná organizaci je rovna rozdílu mezi sumou finanˇcních podpor zaslaných organizaci a provizí, náležející zprostˇredkovatelské organizaci za 92

3. Analýza

její služby:17 Snt = (∑ dnti ) × (1 − p) i

Samotný prubˇ ˚ eh procesu je následovný: nejprve jsou spoˇcítány závazky zprostˇredkovatelské organizace vuˇ ˚ ci organizacím neziskovým, následnˇe dojde k vytvoˇrení a odeslání plateb bance. Je-li provedení plateb bankou potvrzeno, jsou potvrzeny i finanˇcní podpory a nezisková organizace je informována o provedeném penˇežním pˇrevodu. V opaˇcném pˇrípadˇe je nastalý problém rˇ ešen pˇrímo s pracovníky banky.

ˇ 3.10.6. Navrácení financních podpor


Potˇreba navrátit platbu.

Produkty/služby

Navrácení plateb, které byly poslány na nerealizovaný projekt.

Zákazník

Agent.

Metriky

- Podíl navrácených a nenavrácených plateb.

Tabulka 3.22.: Tabulka procesu Navrácení finanˇcních podpor.

V jistých pˇrípadech je nezbytné navrátit již realizované finanˇcní podpory agentum. ˚ Typickým duvodem ˚ pro spuštˇení procesu Navrácení finanˇcních podpor (viz Tabulka 3.22) je zrušení projektu, který neuspˇel ve fundraisingovém režimu. Nejdˇríve dojde k vytvoˇrení nových plateb smˇerˇ ujících k puvodním ˚ dárcum, ˚ ty jsou následnˇe zaslány bance. Banka posléze potvrdí to, že platby probˇehly zasláním výpisu transakcí. Platby jsou poté potvrzeny jako probˇehlé a finanˇcní podpory jsou od této chvíle vedeny jako navrácené. Uvádím taktéž model základních vztahu˚ tˇríd v oblasti objednávek a plateb (viz Obrázek 3.54). Platby mohou být asociované s výpisem transakcí z banky, mohou se vztahovat k objednávce. Objednávka musí obsahovat alesponˇ jednu finanˇcní podporu, kdežto finanˇcní podpora k objednávce náležet nemusí.

3.11. Ostatní procesy ˇ podpory 3.11.1. Zviditelnení Pokud agent právˇe nˇekterým z dostupných zpusob ˚ u˚ podpoˇril nˇekterou organizaci cˇ i její pˇrípad, je mu nabídnuta možnost zviditelnˇení jeho podpory (viz Tabulka 3.23). Zviditelnˇení totiž muže ˚ pˇrispˇet nejen k naplnˇení potˇreb agenta, ale též k naplnˇení cílu˚ neziskové organizace tím, že její cˇ innost se dostává do povˇedomí širší veˇrejnosti. 17 Zde

snt znaˇcí sumu zaslanou n-té neziskové organizaci za období t, dnti znaˇcí cˇ ástku í-té finanˇcní podpory n-té organizaci za období t, p znaˇcí procentuální podíl provize.

93

Obrázek 3.53.: Diagram procesu s názvem Pˇrevod penˇez neziskovým organizacím.

Obrázek 3.54.: Diagram tˇríd souvisejících s objednávkami a platbami.

94

3. Analýza

Obrázek 3.55.: Diagram procesu s názvem Navrácení finanˇcních podpor.


Potˇreba zviditelnit podporu.

Produkty/služby

Umožnˇení zviditelnˇení podpory s cílem pˇrilákat další podporu.

Zákazník


Metriky

- Poˇcet zpráv odeslaných na sociální sít’. - Poˇcet podpor motivovaných pˇríznivectvími a jejich pomˇer vuˇ ˚ ci ostatním podporám.

Podmínky

Podpora musí být realizována a agent musí se zviditelnˇením souhlasit.

Dokumenty

Uživatelská pˇríruˇcka.

Tabulka 3.23.: Tabulka procesu Zviditelnˇení podpory.

Nejprve je vytvoˇrena novinka o podpoˇre, která je uložena do novinek náležejících pˇríslušnému agentovi. Nˇekteˇrí agenti se mohou pro podporu rozhodnout na základˇe toho, že jiný agent je pˇríznivcem urˇcitého neziskového pˇrípadu (viz 3.11.2). Pokud je tomu tak, jsou obˇe entity asociovány. Nyní je agentovi nabídnuto samotné zviditelnˇení jeho podpory formou a) stání se pˇríznivcem nebo b) zaslání zprávy jeho známým cˇ i pˇrátelum, ˚ a to formou emailu cˇ i prostˇrednictvím sociální sítˇe. 95

Obrázek 3.56.: Diagram procesu s názvem Zviditelnˇení podpory.

3.11.2. Stání se pˇríznivcem Startovací událost

Požadavek na vytvoˇrení pˇríznivectví.

Produkty/služby

Poskytnout veˇrejnosti možnost stát se pˇríznivci jednotlivých pˇredmˇetu. ˚

Zákazník

Nezisková organizace, Uživatel.

Metriky

- Poˇcet vygenerovaných a používaných widgetu˚ za období. - Poˇcet pˇríznivectví vzniklých za období.

Podmínky

- Pˇredmˇet, k nˇemuž se pˇríznivectví vztahuje, musí být aktivní. - Uživatel muže ˚ podporovat pouze neziskovou organizaci a její pˇrípady, nikoliv tedy další typy organizací. - Nelze podporovat pˇríznivectví prostˇrednictvím jiného pˇríznivectví. - Žadatel musí být registrovaným uživatelem.

Dokumenty

Uživatelská pˇríruˇcka.

Tabulka 3.24.: Tabulka procesu Stání se pˇríznivcem.

Dalším duležitým ˚ zpusobem ˚ podpory je stání se pˇríznivcem, fanouškem a pˇrípadnˇe též propagátorem pˇredmˇetu, což popisuje proces Stání se pˇríznivcem (viz Obrázek 3.58, viz Tabulka 3.24). Tento zpusob ˚ podpory se na rozdíl od ostatních typu˚ neomezuje pouze na podporu 96

3. Analýza

Obrázek 3.57.: Diagram tˇrídy Widget ve vztahu s tˇrídou Pˇríznivectví. nˇekterého konkrétního typu pˇrípadu, ale muže ˚ podporovat zcela libovolný pˇrípad (pˇríznivectví ovšem nemuže ˚ podporovat jiné pˇríznivectví), nebo dokonce neziskovou organizaci jako celek. Stane-li se registrovaný uživatel pˇríznivcem pˇrípadu, veˇrejnˇe deklaruje svuj ˚ zájem o nˇej a informuje o nˇem své okolí. Funkce pˇríznivectví však není pouze takto pasivní, ale je též prostˇredkem k šíˇrení „nákazy“ pˇríznivectví v agentovˇe okolí. Pˇríznivci je totiž na základˇe vzniklého pˇríznivectví nabídnut widget umístitelný na jeho osobní stránky nebo blog, jehož prostˇrednictvím je každému návštˇevníkovi umožnˇeno pˇrímo podpoˇrit agentem podporovaný pˇrípad, a to nejen finanˇcnˇe, ale všemi relevantními zpusoby. ˚ Takto skrze pˇríznivectví získaná podpora je sumarizována a pˇríznivec i návštˇevníci jeho stránek mají možnost zjistit, kolik podpory již bylo jeho prostˇrednictvím poskytnuto. Není-li tedy agent registrován, musí být proveden proces Registrace uživatele (viz 3.9.1). S pˇríznivectvím se pojí také výše dosud neuvedená tˇrída Widget. Každá podpora muže ˚ mít bud’ jeden, nebo žádný widget, pˇriˇcemž widget lze chápat jako pˇrevedení vztahu pˇríznivectví do formy zobrazitelné ve webovém prohlížeˇci.

ˇ 3.11.3. Pˇridání zamestnance Startovací událost

Požadavek na pˇridání zamˇestnance.

Produkty/služby

Pˇridání zamˇestnance do firemní databáze zamˇestnancu. ˚

Zákazník

Firma.

Metriky

-

Podmínky

- Firma je registrována a její úˇcet je aktivní. - Iniciátorem je výhradnˇe správce organizace.

Dokumenty


Tabulka 3.25.: Tabulka procesu Pˇridání zamˇestnance. Posledním duležitým ˚ procesem týkajícím se zamˇestnancu˚ je proces umožnující ˇ vznik zamˇestnaneckých vztahu˚ zachycený procesem Pˇridání zamˇestnance (viz Tabulka 3.25). Z jeho diagramu (viz Obrázek 3.59) je patrné, že vznik záznamu o zamˇestnaneckém vztahu je vždy podmínˇen akcí povˇerˇ ené osoby zamˇestnavatelské organizace, tj. správce organizace. Ten má k dispozici dva zpusoby, ˚ jak záznam o zamˇestnanci vložit. Je to: a) vytvoˇrení záznamu˚ o agentovi bez uživatelského úˇctu a b) registrace uživatelu˚ s reálnými uživatelskými úˇcty. 97

Obrázek 3.58.: Diagram procesu s názvem Stání se pˇríznivcem.

98

3. Analýza

Obrázek 3.59.: Diagram procesu s názvem Pˇridání zamˇestnance. Druhý zpusob ˚ (b) vyžaduje, aby byl vybraný uživatel kontaktován, a aby svuj ˚ zamˇestnanecký vztah osobnˇe potvrdil. Vše je realizováno obvyklým zpusobem ˚ prostˇrednictvím koprocesu Vyˇrízení žádosti. Jak napovídá objektový model, zamˇestnanci mohou být zamˇestnáni nejen u firem, ale též u neziskových organizací (viz Obrázek 3.35), nebot’ tˇrída Zamˇestnání je vázána na tˇrídu Organizace a nikoliv na tˇrídu Firma. Jedinou organizací, která skuteˇcnˇe nemá zamˇestnance, je komunita. Model tˇríd neumožnuje ˇ explicitní zachycení tohoto faktu.

3.11.4. Vyˇrízení žádosti Startovací událost

Požadavek na vyˇrízení žádosti o potvrzení.

Produkty/služby

Žádost je vyˇrízena.

Zákazník

Kdokoli.

Podmínky

- Žádost již musí existovat ve stavu „Vytvoˇrena“. - Žádost nemusí být adresována pˇrímo uživateli, ale napˇr. organizaci cˇ i pˇrípadu. O žádosti adresované organizaci rozhodne uživatel pouze tehdy, je-li správcem organizace cˇ i pˇrípadu.

Tabulka 3.26.: Tabulka procesu Vyˇrízení žádosti.

Jednoduchým podpurným ˚ procesem je Vyˇrízení žádosti (viz Obrázek 3.60, viz Tabulka 3.26). Žadatelem i subjektem žádosti muže ˚ být bud’ uživatel nebo organizace. Konkrétní žádost 99

Obrázek 3.60.: Diagram procesu Vyˇrízení žádosti.

Obrázek 3.61.: Tˇrídy týkající se žádosti.

se obvykle týká nˇekteré instance tˇrídy Pˇredmˇet a umožnuje ˇ též schválení podpory. Tomuto procesu odpovídá také diagram stavu˚ entity Žádost (viz Obrázek 3.62). Tˇrída Žádost (viz Obrázek 3.61) je sama potomkem tˇrídy Zpráva, což znamená, že má nutnˇe adresáta a nepovinnˇe je evidován též odesilatel zprávy. 100

3. Analýza

Obrázek 3.62.: Stavový diagram entity Žádost.

Obrázek 3.63.: Diagram cˇ innosti Vymazání entity.

3.11.5. Vymazání entity Ve všech dosud uvedených stavových diagramech je možné nalézt pˇrechod Smazání. Ten vždy ukonˇcuje životní cyklus entity. Pˇríslušný proces lze však nejsnáze postihnout jako atomickou cˇ innost, nebot’ ke smazání entity muže ˚ dojít v mnoha rozdílných pˇrípadech, nˇekdy zcela bez událostní vazby na výše uvedené procesy (viz Obrázek 3.63). Entity s netriviálním životním cyklem18 mají pˇresnˇe definované stavy, pˇri nichž muže ˚ ke smazání dojít.

ˇ 3.11.6. Ukoncení spolupráce s organizací K ukonˇcení spolupráce s organizací (viz Obrázek 3.64) dojde na základˇe žádosti dotyˇcné organizace nebo úkonem povˇerˇ eného pracovníka zprostˇredkovatelské organizace. Jedná-li se o ukonˇcení spolupráce s neziskovou organizací, je jí s okamžitou platností vypovˇezena smlouva. V závˇeru je organizace o ukonˇcení spolupráce informována zprávou. 18 Tj.

cyklem o nejménˇe tˇrí stavech.

101

Obrázek 3.64.: Diagram procesu Ukonˇcení spolupráce s organizací.

Obrázek 3.65.: Diagram procesu Ukonˇcení dlouhodobé podpory.

ˇ 3.11.7. Ukoncení dlouhodobé podpory

O ukonˇcení dlouhodobé podpory (viz Obrázek 3.65) nˇejakého pˇrípadu muže ˚ kdykoliv rozhodnout bud’ organizace, jejíž pˇrípad je podporován, podporovatel nebo povˇerˇ ený pracovník zprostˇredkovatelské organizace (administrátor). 102

3. Analýza

Obrázek 3.66.: Diagram procesu Zrušení uživatelského úˇctu.

ˇ 3.11.8. Zrušení uživatelského úctu Strukturálnˇe obdobný pˇredchozímu procesu je též proces Zrušení uživatelského úˇctu (viz Obrázek 3.66).

3.12. Analýza požadavku˚ na IS Dalším logickým krokem následujícím po analýze procesu˚ ve zprostˇredkovatelské organizaci je analýza požadavku˚ na informaˇcní systém pro podporu zmínˇených procesu. ˚ Je tˇreba zodpovˇedˇet otázku, jaké funkcionality musí informaˇcní systém poskytovat a kterým uživatelum ˚ mají být pˇrístupné. Procesní analýza pˇri tomto poˇcínání sehraje zásadní roli - je sice faktem, že ne všechny cˇ innosti všech procesu˚ budou podporovány funkcionalitou informaˇcního systému, naopak též platí, že ne všechny funkcionality informaˇcního systému jsou zachyceny v nˇekterém z procesu˚ (viz Obrázek 3.67), podstatné však je, že oblast pokrytá procesní analýzou se shoduje s oblastí analýzy funkˇcní ve všech podstatných aspektech navrhovaného systému. Proto lze pˇri definování postupovat v maximální struˇcnosti, nebot’ mnohé funkˇcnosti se odráží v dˇríve analyzovaných procesech.

Obrázek 3.67.: Náˇcrt pokrytí procesu˚ funkcionalitami. Celý postup spoˇcívá ve vytvoˇrení modelu pˇrípadu˚ užití pro jednotlivé uživatelské role. Jak vyplynulo z analýzy agentu˚ (viz 3.3), uživatele lze zaˇradit do cˇ tyˇr základních skupin: hosté, registrovaní uživatelé, správci, administrátoˇri. Tímto cˇ lenˇením se bude rˇ ídit také postup de103

finice pˇrípadu˚ užití - cˇ tenáˇr na následujících stránkách nalezne seznamy funkcionalit rozdˇelených podle pˇríslušnosti k jednotlivým rolím. Je též vhodné pˇripomenout, že mezi jednotlivými uživatelskými rolemi platí vztahy dˇediˇcnosti, což se projevuje také na funkcionalitách - potomek role vždy pˇrejímá všechny funkcionality pˇredka. Rolí s nejnižšími pravomocemi, která je zárovenˇ pˇredkem všech ostatních rolí, je role hosta. Všichni hosté mohou užívat následující funkcionality (viz Tabulka 3.27, viz Obrázek 3.68): Funkcionalita

Popis

Proces

Prohlížet veˇrejné

Pˇristupovat na všechny veˇrejné webové stránky

Není pokryto.

informace

aplikace urˇcené k prezentaci informací.

Registrovat se

Umožnuje ˇ stát se registrovaným uživatelem s vˇetšími

Odkaz -

Registrace uživatele

3.9.1

Finanˇcní dar projektu

3.8.2

Podpis petice

3.8.6

Zviditelnˇení podpory

3.11.1

Dokonˇcení objednávky

3.10.1

Platba

3.10.2

pravomocemi. Darovat peníze

Darovat peníze na neziskové projekty a neziskovým organizacím.

Podepisovat petice

Neregistrovaný uživatel musí uvést své základní identifikaˇcní informace, aby mohl petici podepsat.

Zviditelnovat ˇ

Zviditelnovat ˇ projevenou podporu neziskovým

projevenou podporu

pˇrípadum ˚ prostˇrednictvím sociálních sítí a dalších komunikaˇcních prostˇredku. ˚

Dokonˇcit objednávku

Finanˇcní podporou je myšlen bud’ dar nebo vstupenka

finanˇcní podpory

na událost. Peníze následnˇe putují na úˇcet neziskové organizace.

Provést platbu

Zaplatit za poskytnutou finanˇcní podporu.

Tabulka 3.27: Funkcionality náležející hostu. Mnohem více pravomocí má registrovaný uživatel, tj. potomek hosta. Registrovaným uživatelum ˚ podstoupení procesu registrace umožnuje ˇ pˇristupovat k následujícím funkcionalitám (viz Tabulka 3.28): Funkcionalita

Popis

Proces

Odkaz

Komentovat

Uživatel muže ˚ komentovat libovolný pˇredmˇet, tj.

Není pokryto.

-

Není pokryto.

-

libovolnou organizaci cˇ i pˇrípad. Spravovat cˇ tení

Možnost nastavit, které novinky ze kterých zdroju˚ bude

novinek

uživatel odebírat.

Registrovat organizaci

Registrovat svou firmu, komunitu nebo neziskovou organizaci.

Registrovat neziskovou organizaci Registrovat firmu

3.9.2

Registrovat komunitu Administrovat

Upravovat všechny informace vztahující k uživateli,

uživatelský profil

smazat profil, apod.

104

Není pokryto.

-

3. Analýza

Vyˇrídit žádost

Žádost je uživateli zaslána druhou stranou. Muže ˚ být

Vyˇrízení žádosti

3.11.4

ˇ Clenství v komunitˇe

3.9.5

bud’ pˇrijata, nebo odmítnuta. Tento akt je obvykle konstitutivní a znamená navázaní, resp. odmítnutí nˇejakého reálného vztahu Stát se cˇ lenem

Pˇridat se ke skupinˇe uživatelu, ˚ s níž uživatel sdílí zájmy.

komunity

Uživatel se muže ˚ pˇripojit v jednom cˇ ase nejvýše k jedné komunitˇe.

Vytvoˇrit petici

Vytvoˇrit petici.

Zpracování petice

3.7.1.4

Stát se dobrovolníkem

Dobrovolník poskytuje zdarma práci neziskové

Vyjednání

organizaci.

dobrovolniˇcení

Stát se pˇríznivcem

Stát se pˇríznivcem nˇekteré organizace cˇ i pˇrípadu.

Stání se pˇríznivcem

3.11.2

Nakupovat vstupenky

Podporovat neziskové události tak, že si uživatel koupí

Podpora události

3.8.3

vstupenku na pˇríslušnou událost.

nákupem lístku

3.8.4

Tabulka 3.28: Funkcionality náležející uživateli. Zvláštní skupinou agentu˚ jsou zamˇestnanci, tj. uživatelé zamˇestnaní v nˇekteré firmˇe. K jejich roli se rˇ adí následující funkcionality (viz Tabulka 3.29): Funkcionalita

Popis

Proces

Stát se firemním

Zamˇestnanec se stane dobrovolníkem neziskové

Kandidatura

dobrovolníkem

organizace na základˇe dohody o firemním

zamˇestnance na

dobrovolnictví.

dobrovolnickou pozici

Zobrazovat nabídky

Zamˇestnanec prochází nabídky dobrovolnických pozic

Není pokryto.

firemního

nabízených firmou.

Odkaz 3.8.5

-

dobrovolnictví

Tabulka 3.29: Funkcionality náležející zamˇestnanci. Za pˇredmˇety, tj. organizace a pˇrípady jsou zodpovˇední správci pˇredmˇetu. ˚ K jejich roli jsou proto pˇriˇrazeny pravomoci týkající se správy jim svˇerˇ ených entit (viz Tabulka 3.30): Funkcionalita

Popis

Proces

Odkaz

Spravovat pˇríznivce

Spravovat pˇríznivce, kteˇrí se k pˇredmˇetu hlásí. Lze též

Není pokryto.

-

Není pokryto.

-

Není pokryto.

-

Není pokryto.

-

jednostrannˇe rozhodnout o ukonˇcení pˇríznivectví libovolného uživatele. Spravovat komentáˇre

Pˇridávat, upravovat a mazat komentáˇre k pˇrípadu, jehož je uživatel správcem.

Spravovat novinky

Pˇridávat, upravovat a mazat novinky o pˇredmˇetu, jehož je uživatel správcem.

Udˇelovat správcovství

Pˇridˇelovat správcovská privilegia ostatním uživatelum ˚

105

Spravovat komunitu a

Upravovat informace o komunitˇe, vyluˇcovat její cˇ leny,

její cˇ leny

atd.

Spravovat organizaci

Mˇenit základní údaje o organizaci, ukonˇcovat její

Není pokryto.

-

Není pokryto.

-

pusobení, ˚ atd. Další možnosti jsou udány rozšiˇrujícími pˇrípady užití (správa zamˇestnancu˚ a správa administrátorských práv). Spravovat

Tento pˇrípad užití je rozšíˇrením pˇrípadu užití Spravovat

zamˇestnance

organizaci. Umožnuje ˇ správci organizace pˇridávat

Pˇridání zamˇestnance

3.11.3

Vyjednání firemního dobrovolnictví

3.8.5

zamˇestnance a odebírat je. Spravovat firemní

Tento pˇrípad užití je rozšíˇrením pˇrípadu užití Spravovat

dobrovolnictví

organizaci. Umožnuje ˇ správci firmy vyjednat s neziskovou organizací firemní dobrovolnictví, dále jej

Oslovení zamˇestnancu˚

spravovat a ukonˇcovat, oslovovat zamˇestnance s nabídkou dobrovolnictví, schvalovat zamˇestnanecké žádosti o dobrovolnictví, apod. Spravovat projekt a

Pˇridávat projekty, upravovat údaje projektu a mˇenit

jeho odmˇeny

odmˇeny, pozastavovat a ukonˇcovat projekty.

Spravovat NNO

Spravovat neziskovou organizaci. Tento pˇrípad užití je

Zpracování projektu

Není pokryto.

3.7.1.1

-

rozšíˇrením pˇrípadu užití Spravovat organizaci a je pˇrístupný pouze správci neziskové organizace. Jeho funkcionalita je dána zejména pˇrípady užití, které tento pˇrípad užití rozšiˇrují. Spravovat

Vytváˇret nové dobrovolnické pozice, upravovat,

Zpracování

dobrovolnické pozice

pozastavovat a ukonˇcovat již existující, ukonˇcovat

dobrovolnické pozice

3.7.1.3

spolupráci s aktivními dobrovolníky a schvalovat žádosti nových. Spravovat události a

Pˇridávat události a místa konání, upravovat je a mazat.

Zpracování události

3.7.1.2

Pˇredevším ukonˇcovat petici, kterou uživatel v minulosti

Není pokryto.

-

Není pokryto.

-

místa konání Spravovat petici

vytvoˇril. Petici není možné upravovat pozdˇeji. Spravovat organizaci

Upravovat základní údaje o organizaci, ukonˇcovat pusobení ˚ organizace, apod.

Tabulka 3.30: Funkcionality náležející správci. Administrátoˇri aplikace jsou z hlediska pravomocí zdaleka nejmocnˇejšími hráˇci v systému. Kromˇe pˇredchozích mohou využívat následující funkcionality (viz Tabulka 3.30): Funkcionalita

Popis

Proces

Spravovat pˇrípady

Vyhledávat, upravovat, pozastavovat, ukonˇcovat a

Není pokryto.

mazat libovolný pˇrípad v systému.

106

Odkaz -

3. Analýza

Vyhledávat, upravovat, ukonˇcovat a mazat libovolnou

Spravovat organizace

Není pokryto.

-

Není pokryto.

-

Není pokryto.

-

organizaci v systému. Vyhledávat, upravovat, ukonˇcovat a mazat libovolného

Spravovat uživatele

uživatele. Vyhledávat platby, zobrazovat údaje o platbách,

Spravovat platby

odsouhlasit libovolnou platbu a získávat pˇríslušné reporty.

Tabulka 3.31: Funkcionality náležející administrátorovi. Závˇerem je též potˇreba vyjmenovat funkcionality, které nejsou pˇrímo dostupné uživateli, ale jejich spouštˇecˇ em je událost nezapˇríˇcinˇená pˇrímo uživatelskou akcí, ale napˇr. cˇ asovou událostí, apod. (viz Tabulka 3.32). Funkcionalita

Popis

Proces

Odkaz

Spárování plateb

Spárování plateb pˇrišlých na úˇcet se záznamy o

Spárování plateb

3.10.3

3.10.6

platbách v informaˇcním systému. Navrácení finanˇcních

Navrácení finanˇcních podpor, které nemohly být

Navrácení finanˇcních

podpor

zrealizovány.

podpor

Tabulka 3.32: Funkcionality neovládané pˇrímo uživatelem.

3.13. Diskuze V této kapitole jsem pomocí metodiky MMABP a s využitím techniky PDT provedl analýzu zprostˇredkovatelské organizace poskytující neziskovým organizacím služby usnadnuˇ jící rˇ ešení nˇekterých problému˚ neziskového sektoru, zejména alokaci poptávky po realizaci filantropie a nabídky pˇrípadu˚ neziskových pˇrípadu. ˚ Zvolené nástroje hodnotím v zásadˇe jako vyhovující, bylo tˇreba uˇcinit jen drobné zmˇeny expresivity popisovacího jazyka BPML. Jako na otevˇrený problém pohlížím na jistou vyjadˇrovací neúspornost tohoto jazyka, nebot’ ke zobrazení byt’ jen jednoduchých prvku˚ reality je tˇreba relativnˇe veliké množství prvku˚ BPML. Vzhledem k dalšímu neuspokojivému smˇerˇ ování BPML v dalších verzích (zejm. BPML 2.0) se nabízí otázka, zda pro budoucí analýzu nepoužít bud’ jinou standardní notaci, nebo notaci proprietární. Síla metodiky spoˇcívá pˇredevším v jejím durazu ˚ na jednoduchost a na konzistenci procesu, ˚ tˇríd a stavu˚ objektu. ˚ Práci však ponˇekud znesnadnuje ˇ absence CASE aplikace, která by proces analýzy podpoˇrila a významným zpusobem ˚ urychlila. Opakovaná manuální kontrola konzistence všech modelu˚ nejenom že nedosahuje spolehlivosti kontroly automatizované, ale je velmi nároˇcnou cˇ inností, a to jak z hlediska omezených lidských sil, tak z hlediska cˇ asového. Vývoj CASE nástroje pro tuto perspektivní metodiku by mohl usnadnit její užití a tím též rozšíˇrení v prumyslových ˚ podmínkách. Procesní analýza byla provedena v souladu s oˇcekávaným pˇrínosem práce (viz 1.5), což pˇrispˇelo k její pomˇernˇe úzké profilaci. Model je proveden natolik detailnˇe, že poskytuje po107

Obrázek 3.68.: Diagram pˇrípadu˚ užití pro neregistrované hosty a registrované uživatele.

Obrázek 3.69.: Diagram pˇrípadu˚ užití pro uživatele, kteˇrí jsou správci a administrátoˇri.

108

3. Analýza

mˇernˇe podrobné znalosti pro fázi návrhu. S odstupem je však nutné pˇriznat, že takto úzká profilace je v jistém napˇetí se samotnou myšlenkou procesního rˇ ízení organizace, jejímž cílem je na základˇe komplexní analýzy potˇreb a souvisejících klíˇcových procesu˚ provést komplexní zmˇenu rˇ ízení organizace.19 Provedl jsem sice velmi obecnou analýzu všech klíˇcových procesu, ˚ poté jsem však zvolil cestu detailní analýzy pouze omezené množiny procesu, ˚ které adresují pouze omezenou množinu potˇreb trhu. Zamˇerˇ il jsem se totiž na vztah zprostˇredkovatelské organizace a jednotlivcu, ˚ stranou jsem do znaˇcné míry nechal korporátní prostˇredí. Duvodem ˚ pro toto rozhodnutí byly pˇredevším požadavky projektu Darujme.cz na zmínˇenou analýzu. Je zˇrejmé, že omezená výpovˇední hodnota analýzy znamená zárovenˇ pouze omezený pˇrínos diplomové práce, aˇckoliv vytyˇcených cílu˚ bylo dosaženo. Tento nedostatek je však zárovenˇ pˇríležitostí pro další práci a precizaci modelu. Práce též vedla k položení nˇekolika metodických otázek spojených s problematikou adekvátní konceptuální reprezentace reality. V pˇrípadech, kdy je v rámci procesu voláno mnoho instancí jednoho koprocesu najednou, jsem k vyznaˇcení této skuteˇcnosti navrhl užití stereotypu <<Multiple>>. Specializaci jsem se rozhodl modelovat prostˇrednictvím podprocesu, ˚ ovšem tento postup je výrazovˇe pomˇernˇe neúsporný. Obˇe zvolená rˇ ešení jsou pˇrirozenˇe otevˇrená další diskuzi.

19 [Repa, ˇ

2007, s. 25]

109

ˇ metodiky návrhu webových aplikací 4. Výber V pˇredešlé kapitole byly získány dostateˇcné znalosti k tomu, aby bylo možné pˇrejít k samotnému návrhu informaˇcního systému, který by podporoval výše uvedené procesy. Vzhledem k vysokým požadavkum ˚ na interaktivitu aplikace a pˇredpokládané nároky na uživatelskou komunikaci se jako nejvhodnˇejší rˇ ešení jeví návrh informaˇcního systému ve formˇe webové aplikace. Cílem této kapitoly je pojednat o tom, jaké pˇrístupy jsou v souˇcasnosti pro návrh webových aplikací používány, dále pˇredstavit vybrané konkrétní metodiky a vybrat tu nejvhodnˇejší pro rˇ ešení analyzovaného problému. Samotná problematika návrhu webových aplikací není nijak triviální, jde navíc o relativnˇe novou oblast, která dodnes není akademicky zcela uspokojivˇe zmapována. To souvisí pˇredevším s postupnou zmˇenou vˇetšinového pohledu vývojáˇru˚ a uživatelu˚ na funkce internetu jako takového: v minulosti totiž existoval mezi webem a desktopovými aplikacemi jasnˇe definovaný rozdíl. Zjednodušenˇe lze rˇ íci,1 že internetové stránky byly urˇceny pˇredevším k prezentaci informací, byly v zásadˇe bezstavové (stateless),2 pˇriˇcemž každý stav webové prezentaˇcní vrstvy mˇel unikátní identifikátor,3 každá uživatelská akce obvykle vyžadovala nové naˇctení stránky (page refresh) a návštˇevník stránek byl pˇri komunikaci s aplikací odkázán pouze na nˇekolik základních formuláˇrových komponent definovaných jazykem HTML. Oproti tomu komplexní uživatelské rozhraní, vysoká míra uživatelské interakce a stavovost (statefullness) uživatelského rozhraní byly výhradními vlastnostmi desktopových aplikací. Tato až scholasticky jednoznaˇcná distinkce však zaˇcala s rapidním vývojem webu rychle ztrácet na ostrosti, aby se posléze témˇerˇ zcela zhroutila do obtížnˇe rozlišené fúze, která je dnes známa jako fenomén bohatých internetových aplikací (RIA, Rich Internet Applications).4 Též samotná definice tohoto pojmu je, jak je tomu u podobných pojmu˚ zvykem, znaˇcnˇe neostrá a není proto snadné rˇ íci, kterou aplikaci lze ještˇe zaˇradit pod RIA a kterou již nikoliv. Obecnˇe však lze tvrdit, že bohaté internetové aplikace jsou provozovány prostˇrednictvím webových technologií a pˇrebírají charakteristiky tradiˇcnˇe náležející aplikacím desktopovým, pˇriˇcemž ztrácejí nˇekteré vlastnosti tradiˇcnˇe náležející aplikacím webovým. Motivací pro vznik RIA je pˇrirozenˇe vidina snadné údržby a provozu aplikace a relativnˇe nízké nároky kladené na vybavenost uživatele (odpadá nutnost instalace, starost o kompatibilitu aplikace s operaˇcním systémem uživatele, atd.), dále snaha o zvýšení interaktivity webu˚ (widgety, drag & drop), rostoucí nároky na multimediální obsah, animace, atd. 1 Viz

[Fraternali et al., 2010b]. zde znamená, že server, s nímž uživatel komunikoval, a z nˇejž byly stránky zaslány, neukládal žádné informace o pˇredchozí interakci s uživatelem. Jde o základní vlastnost protokolu HTTP, která má duležité ˚ implikace pro návrh internetových aplikací. Vzhledem k tomu, že pro vývoj komplexních aplikací není bezstavovost ze zˇrejmých duvod ˚ u˚ pˇríliš výhodná, vznikají rozliˇcné techniky k jejímu pˇrekonání. 3 V praxi má tento princip uživatelsky výhodné implikace, nebot’ je-li naplnˇ en, je možné zachytit libovolný stav webové aplikace pomocí rˇ etˇezce obsahujícího URL a pomocí tohoto URL jej také kdykoli v budoucnosti znovu vyvolat, ovšem za pˇredpokladu, že nedojde ke zmˇenˇe v aplikaci samotné. Ani tento princip však není v dnešních webových aplikacích vždy striktnˇe dodržován. 4 K tomu viz napˇr. [Fraternali et al., 2010a]. 2 Bezstavovost

111

Obrázek 4.1.: Fáze metodiky WSDM. Zdroj: [WISE, 2012]. Metodiky zabývající se návrhem webových sídel nejsou v informatice žádnou novinkou a existuje jich dnes celá rˇ ada, pˇriˇcemž mnoho z nich se snaží reagovat na rychlý nástup RIA a obohatit svou expresivitu také tímto smˇerem.5 V rámci této práce se budu vˇenovat pouze tˇem nejvýznamnˇejším metodikám, které jsou aktuálnˇe stále vyvíjené a jsou relativnˇe cˇ asto používány v praxi.

4.1. WSDM WSDM je metodika vycházející z analýzy potˇreb uživatelu, ˚ která byla vyvinuta v rámci skupiny WISE Research Group pod vedením profesorky Olgy De Troyer, a jejíž historie sahá do roku 1997.6 Její cyklus cˇ ítá celkem pˇet fází (viz Obrázek 4.1): 1. Specifikace cílu˚ (Mission Statement Specification) je úvodní fází metodického postupu a jedná se o prvotní popis navrhovaného systému zahrnující základní informace o problémové doménˇe a požadované cíle, kterých má realizace aplikace dosáhnout. 2. Modelování uživatelu˚ (Audience Modeling) je fází analýzy uživatelu˚ a jejich cílu˚ a potˇreb. Dojde ke klasifikaci uživatelu˚ pomocí tzv. uživatelských tˇríd (audience classes), ustanovení vztahu˚ dˇediˇcnosti a k následné charakterizaci skupin. Jedná se o jakousi obdobu známého modelu pˇrípadu˚ užití. 3. Konceptuální návrh (Conceptual Design) se skládá ze dvou cˇ ástí: a) z modelování cˇ inností a informací (Tasks and Information Modeling) a b) z návrhu navigace (Navigational 5V

roce 2005 o stavu implementace RIA do metodik vývoje webových aplikací vyˇcerpávajícím zpusobem ˚ informoval [Precidado et al., 2005]. 6 Viz [WISE, 2012, Plessers et al., 2005].

112

4. Výbˇer metodiky návrhu webových aplikací

Design). V podfázi a) dochází k jakési analýze uživatelsky rˇ ízených procesu˚ pomocí techniky CTT (Concurrent Task Trees), v jejímž rámci jsou získány rˇ etˇezce navazujících cˇ inností a jsou definovány informace, které jsou potˇrebné k dokonˇcení toho kterého úkolu. V podfázi b) jsou definovány tzv. navigaˇcní uzly webu a jeho hypertextová struktura umožnující ˇ uživatelum ˚ pohyb mezi uzly. 4. Návrh implementace (Implementation Design) má za cíl doplnit detailnˇejší informace do konceptuálních modelu˚ a skládá se ze tˇrí podfází: a) návrhu struktury webu (Site Structure Design), v jehož rámci je konceptuální model struktury pˇreveden do modelu stránek (page model), tj. je rozhodnuto, které uzly budou souˇcástí které stránky, b) návrhu prezentace, jehož výstupem je definice vizuálního vzhledu stránek a c) mapování dat, bˇehem nˇejž je urˇceno, které datové struktury budou vystupovat na kterých stránkách. 5. Implementace (Implementation). Metodika celkové pusobí ˚ ponˇekud akademickým dojmem. Používá ponˇekud nezvyklých technik, které nejsou široce rozšíˇreny a nedisponuje dokonce ani žádným vyspˇelým CASE nástrojem, což v porovnání s ostatními metodikami pusobí ˚ jako znaˇcný deficit.

4.2. OOHDM Spíše historickou hodnotu má dnes metodika OOHDM publikovaná v roce 1998 Danielem Schwabe v [Schwabe et al., 1998]. Pozoruhodné je, nakolik se životní cyklus této metodiky podobá metodice WSDM a nakolik se jím nechali inspirovat autoˇri metodik nástupnických. Fáze jsou následující: 1. Sbˇer požadavku˚ (Requirements Gathering) je zamˇerˇ en na analýzu požadavku˚ vlastníka projektu a všech zainteresovaných stran. 2. Konceptuální návrh (Conceptual Design) je zkrátka návrhem datové struktury aplikace, autoˇri k tomu úˇcelu doporuˇcují použít modelu tˇríd. Metodika používá notaci podobnou notaci UML, ovšem s tím, že atribut tˇrídy muže ˚ mít zárovenˇ více datových typu, ˚ aby mohl reprezentovat ruzné ˚ aspekty entity . 3. Návrh navigace (Navigational Design) spoˇcívá v sestavení navigaˇcního modelu webu. Tento model sestává z uzlu, ˚ odkazu˚ a dalších prvku˚ a pro jedno konceptuální schéma je obvykle navrženo více navigaˇcních modelu, ˚ nebot’ navigaˇcní model vždy reprezentuje jen jeden z možných pohledu˚ na data, jehož podoba je urˇcena pˇredevším tím, pro jaký druh uživatele je ten který navigaˇcní pohled urˇcen. 4. Návrh abstraktního rozhraní (Abstract Interface Design) je fází, v jejímž rámci dochází k modelování vizuálního návrhu stránek, a to na abstraktní úrovni. Jde v zásadˇe o vizuální návrh stránek, který je však odstínˇen od pˇrílišných detailu˚ - rˇ eší umístˇení jednotlivých elementu, ˚ apod. 5. Implementace (Implementation). Více pozornosti si zaslouží pˇredevším tˇretí fáze návrhu, tj. návrh navigace. Ten se skládá z návrhu schématu navigaˇcních tˇríd a schématu navigaˇcních kontextu. ˚ Schéma navigaˇcních tˇríd je vizuálnˇe podobné diagramu tˇríd, ale liší se od nˇej svou sémantikou - skládá se totiž z uzlu, ˚ odkazu˚ a pˇrístupových struktur (pˇríkladem pˇrístupové struktury je 113

Obrázek 4.2.: Výˇrez ze schématu navigaˇcních tˇríd [Schwabe et al., 1998] (Obrázek byl oˇríznut).

metodiky

OOHDM.

Zdroj:

pruvodce, ˚ který uživatele postupnˇe provádí ruznými ˚ stránkami webu). Relace mezi tˇrídami tedy reprezentují vždy vztah uzel X odkazuje na uzel Y. S ohledem na relace je tedy sémantika ponˇekud zúžena, ovšem s ohledem na atributy tˇríd naopak výraznˇe rozšíˇrena. Navigaˇcní tˇrída totiž nereprezentuje konkrétní tˇrídu z konceptuálního modelu tˇríd v pomˇeru 1:1, ale jedna navigaˇcní tˇrída muže ˚ reprezentovat ruzné ˚ atributy pocházející více konceptuálních tˇríd naráz, je tedy urˇcitým souhrnným pohledem na data urˇceným konkrétní potˇrebou uživatele. Kromˇe definice datového typu lze ke každému atributu pˇriˇradit i SQL dotaz upˇresnující, ˇ které atributy kterých tˇríd k uzlu náleží. Jde-li napˇr. o uzel zobrazující v první rˇ adˇe cˇ lánek a sekundárnˇe též jména všech autoru˚ cˇ lánku, u pˇríslušného atributu jméno autora muže ˚ být pˇridružen SQL kód odkazující na jména všech osob, které jsou vuˇ ˚ ci cˇ lánku ve vztahu být autorem. 7 Notace je nezvyklá a zejména zkušeným analytikum, ˚ kteˇrí jsou zvyklí na zabˇehlé postupy, muže ˚ její osvojení cˇ init urˇcité potíže (viz Obrázek 4.2). Schéma navigaˇcních kontextu˚ v zásadˇe modeluje zpusob, ˚ jakým jsou v rámci aplikace jednotlivé uzly shlukovány a tˇrídˇeny do seznamu. ˚ Pˇríkladem takového seznamu mohou být napˇr. všechny cˇ lánky od jednoho autora, nebo náležející do definovaných sekcí, apod. Na pˇriloženém obrázku (viz Obrázek 4.3) jsou definovány možnosti tvorby seznamu cˇ lánku˚ (Story) podle ruzných ˚ kritérií. Navigaˇcní kontext je množina uzlu, ˚ odkazu, ˚ kontextových tˇríd a podˇrazených kontextu. ˚ Duležitým ˚ prvkem návrhu navigace je dále specifikace navigaˇcních transformací (navigational transformations specification), která urˇcuje, za jakých podmínek je možné pˇristoupit ke kterému uzlu. Ani pro tuto metodiku se mi nepodaˇrilo najít žádný vyspˇelý CASE nástroj, což lze považovat za silný hendikep bránící jejímu masovému rozšíˇrení. 7 Kód

muže ˚ vypadat napˇr. takto: Author: string [SELECT Name] [FROM Person WHERE Person Is Author of Article]. Viz [Schwabe et al., 1998, s. 11].

114


Obrázek 4.3.: Výˇrez ze schématu navigaˇcních kontextu˚ metodiky OOHDM. Zdroj: [Schwabe et al., 1998].

4.3. UWE Metodika UWE (UML-based Web Engineering) byla vytvoˇrena na Ludwig-MaxmilliansUniversität v Mnichovˇe v roce 2000 a navazuje na metodiky OOHDM a WSDM.8 Metodika pokrývá všechny fáze produkce softwaru od puvodního ˚ sbˇeru požadavku˚ až po detailní návrh implementace. Metodika se vyznaˇcuje tím, že pro modelování využívá výhradnˇe jazyka UML, což silnˇe profiluje její celkový charakter. Výhodou této volby je fakt, že UML je v zásadˇe prumyslovým ˚ standardem a je tedy snadno srozumitelné širokému publiku odborníku˚ a existují pro nˇej navíc pokroˇcilé CASE nástroje. Jazyk UML je však nutné pro úˇcely návrhu webových aplikací rozšíˇrit o specifické prvky, cˇ ehož autoˇri UWE dosáhli s pomocí stereotypu. ˚ 9 Otázkou zustává, ˚ zda UWE neˇciní na jazyku UML pˇrílišné násilí, a zda není vhodnˇejší užít specializovaného jazyka. Metodika pˇredepisuje cˇ tyˇri fáze: 1. Analýza požadavku˚ (Requirements Analysis), jejímž výstupem je model pˇrípadu˚ užití (use case model). 2. Konceptuání návrh (Conceptual Design) zabývající se vytvoˇrením konceptuálního modelu (conceptual model), resp. modelu tˇríd (class model). 3. Návrh navigace (Navigation Design) zabývající se zachycením základní struktury webu a vztahu˚ mezi jednotlivými stránkami. 4. Návrh prezentace (Presentation Design), bˇehem níž je vytvoˇren prezentaˇcní modelu (presentational model). Vzhledem k tomu, že use case model a model tˇríd jsou notoricky známými prvky témˇerˇ každého návrhu, nepovažuji za nutné dále popisovat zpusob, ˚ jímž jsou vytváˇreny. Za vskutku originální pˇrínos metodiky je možné považovat až tˇretí fázi, tj. návrh navigace, bˇehem níž dojde k vytvoˇrení dvou modelu: ˚ a) modelu navigaˇcního prostoru (navigation space model) a b) modelu navigaˇcní struktury (navigation structure model). První z obou modelu˚ mapuje množinu stránek navrhovaného webu a jejich vzájemnou provázanost prostˇrednictvím odkazu. ˚ Stránka je pˇritom modelována tˇrídou (jedná se o tzv. navigaˇcní tˇrídu, navigation 8 Viz 9 Viz

[Molhanec, 2005]. ibid.

115

Obrázek 4.4.: Pˇríklad modelu navigaˇcní struktury metodiky UWE. Zdroj: [UWE, 2012]. class), odkaz, resp. pˇrechod mezi dvˇema stránkami pak šipkou (arrow). Model navigaˇcní struktury (viz Obrázek 4.4) lze chápat jako jakési rozpracování modelu konceptuálního, pˇricˇ emž duraz ˚ se klade na podrobnˇejší specifikaci navigace mezi jednotlivými stránkami. Metodika sémanticky rozlišuje nˇekolik druhu˚ odkazu˚ (muže ˚ jít napˇr. o odkazy z menu, odkazy urˇcené identifikátorem té které entity, dotazem, atd.), k cˇ emuž používá tzv. pˇrístupové elementy (access elements; jedná se o prvky, které jsou graficky znázornˇeny uprostˇred každého odkazu). Poslední fází metodiky je návrh prezentace. Model prezentace (viz Obrázek 4.5) se skládá z jednotlivých pohledu˚ (views), pˇriˇcemž každý z pohledu˚ náleží právˇe jedné navigaˇcní tˇrídˇe (resp. její instanci) a blíže specifikuje, jakým zpusobem ˚ jsou urˇcené entity na stránce prezentovány a jaké akce muže ˚ uživatel na konkrétní stránce provádˇet. Pohled je graficky znázornˇen pomocí tzv. náˇcrtku (sketch), pro jehož vytvoˇrení je netradiˇcním zpusobem ˚ použito UML notace puvodnˇ ˚ e urˇcené pro vytváˇrení diagramu tˇríd. Každý pohled je reprezentován jednou tˇrídou se stereotypem <> a skládá se z tˇríd oznaˇcených stereotypem <>. K vizualizaci vnoˇrených elementu˚ je použito vnitˇrních tˇríd. Vzájemné vztahy jednotlivých pohledu˚ jsou nakonec zobrazeny pomocí tzv. prezentaˇcní tabule (Storyboard), která souhrnnˇe zobrazuje všechny pohledy. Mezi nesporné pˇrínosy metodiky patˇrí to, že její autoˇri se pokoušejí o maximální automatizaci následné fáze implementace, a prostˇrednictvím nástroje umožnujícího ˇ generování zdrojového kódu aplikace z výše uvedených modelu. ˚ Vývojáˇr pˇritom muže ˚ zvolit jeden z dostupných programovacích (resp. skriptovacích) jazyku˚ (PHP, ASP, JSP, atd.). Silné i slabé stránky metodiky jsou dány pˇredevším užitím jazyka UML. Snaha o standardizaci je bezesporu zˇcásti pˇrínosná, ale snad až pˇríliš netradiˇcní užití jazyka UML v nˇekterých 116


Obrázek 4.5.: Výˇrez diagramu modelu prezentace metodiky UWE. Zdroj: [UWE, 2012] (obrázek byl oˇríznut). UWE diagramech muže ˚ budit u nˇekterých analytiku˚ mírné rozpaky.

4.4. WebML Patrnˇe nejznámˇejší a též nejprosazovanˇejší metodikou vývoje webových sídel je WebML (Web Modeling Language; jde o souhrnný název jak pro metodiku, tak pro metodikou užívaný jazyk). Ta puvodnˇ ˚ e vznikla na polytechnice v Milánˇe, ale dnes je vyvíjena pˇredevším na komerˇcní bázi firmou Web Ratio.10 Na rozdíl od metodiky UWE nepoužívá standardu UML, takže se nespoléhá na CASE nástroje tˇretích stran, ale nabízí vlastní analytické prostˇredí nesoucí název WebRatio postavené nad populárním IDE Eclipse. Jde o nástroj vyzrálý, nabízející mimo jiné automatickou validaci modelu a velmi pokroˇcilé automatizované generování zdrojového kódu. Vývojový cyklus se v rámci WebML dˇelí na následující fáze: 1. Specifikace požadavku˚ (Requirements Specification), v jejímž rámci analytik získává potˇrebné informace o problémové doménˇe a o pˇredpokládaných funkcích aplikace. Její souˇcástí je též pˇríprava modelu pˇrípadu˚ užití. 2. Datový návrh (Data Design), jehož výstupem je ER model (Rntity-Relation Model), tedy konceptuální model problémové domény. 3. Hypertextový návrh (Hypertext Design) tvoˇrící hlavní originální pˇrínos metodiky. Jeho vstupem jsou výstupy obou pˇredchozích kroku˚ a výstupem je hypertextový model mapující webové stránky a jejich vztahy. 4. Návrh architektury (Architecture Design) zahrnuje specifikaci požadavku˚ na hardware, sít’ové a softwarové komponenty, dále definici výkonnostních testu˚ a technických a ekonomických limitu˚ projektu. Jde o fázi, která již není striktnˇe analytická, ale tvoˇrí samotné pˇredpolí implementace. 10 Na

následujících rˇ ádcích budu vycházet pˇredevším z [Ceri et al., 2003]. Jde o publikaci pocházející pˇrímo od autoru˚ metodiky WebML, která se detailnˇe zaobírá všemi jejími aspekty.

117

Obrázek 4.6.: Výˇrez datového ER diagramu notace WebML. Zdroj: pˇríklad pˇrikládaný k aplikaci WebRatio, viz [WebRatio, 2012]. V rámci první fáze je nejprve potˇreba stanovit obecné cíle, jichž má být realizací projektu dosaženo (business requirements). Dále je tˇreba provést analýzu uživatelu˚ (resp. uživatelských skupin) a pˇrípadu˚ užití. Autoˇri metodiky doporuˇcují také vytvoˇrení datového slovníku (data dictionary) obsahujícího základní informace potˇrebné pro sestavení datového modelu a jakési mapy webu definující základní pohledy (views - viz výše) a oblasti aplikace. Dále je vhodné sestavit základní instrukce pro grafický design stránek a umístˇení základních prvku˚ obsahu. V neposlední rˇ adˇe je tˇreba stanovit základní požadavky na výkon, dostupnost, škálovatelnost, bezpeˇcnost a rozšiˇritelnost aplikace. Krátkou zmínku si též zaslouží druhá fáze spoˇcívající ve vytvoˇrení ER modelu (viz Obrázek 4.6). Každá entita v jeho rámci má povinnˇe definovaný jedineˇcný identifikátor obvykle tvoˇrený celým cˇ íslem (integer). Diagram umožnuje ˇ modelovat dˇediˇcnost, existuje zde též zajímavá možnost vytvoˇrení tzv. derivovaných atributu. ˚ Ty jsou znaˇceny kurzívou a k jejich získání je užit algoritmus, jehož vstupem jsou jiné atributy též entity. Mezi základní podporované datové typy patˇrí blob, boolean, date, decimal, float, integer, password, string, text, time, timestamp a url, analytik však muže ˚ tuto sadu libovolnˇe rozšíˇrit. Zvláštností je, s ohledem na kardinalitu lze definovat pouze maximální, nikoliv minimální kardinalitu relace. Vhodné je dˇelit entity do tˇrí základních skupin: • Základní entity (core objects) pˇredstavující entity spojené se základními procesy probíhajícími v systému, resp. v organizaci. • Pomocné entity nejsou sice pˇrímým pˇredmˇetem základních procesu, ˚ ale bez nich by nebyly informace o základních entitách úplné. Muže ˚ jít napˇríklad o cenovou kategorii lístku, tj. o pomocnou klasifikaˇcní entitu. • Personalizaˇcní entity jsou urˇceny pro správu údaju˚ o uživatelích, uživatelských rolích, apod. Opravdovým jádrem metodiky je pak hypertextový model. Ten se skládá z tzv. pohledu˚ (views) umožnujících ˇ rozˇclenˇení aplikace na základní cˇ ásti (napˇr. veˇrejnˇe pˇrístupný obsah x admi118


nistraˇcní rozhraní). Pohledy se dále funkˇcnˇe cˇ lení na oblasti (areas) - každá z oblastí muže ˚ napˇr. pˇredstavovat jednu funkcionalitu aplikace. Oblasti se již skládají z jednotlivých stránek (pages). Stránky je možné dˇelit do následujících skupin: • Domovská stránka (Home Page) je vstupní stránkou celé aplikace. Aplikace muže ˚ mít pouze jednu takovou stránku. • Základní stránka (Default Page) je vstupní stránkou oblasti. Oblast muže ˚ mít pouze jednu takovou stránku. • Mezníková stránka (Landmark Page) je v zásadˇe stránkou dobˇre viditelnou z ostatních stránek stejné cˇ i nadˇrízené oblasti. Ze všech tˇechto stránek lze pˇrejít pˇrímo na stránku mezníkovou. • Obyˇcejná stránka. Každá ze stran je pak tvoˇrena tzv. jednotkami obsahu (content units). Úkolem jednotek obsahu je zobrazovat urˇcené entity v definované formˇe (viz Obrázek 4.7). V základní verzi metodika zahrnuje nˇekolik druhu˚ jednotek obsahu, pˇriˇcemž mezi ty nejvýznamnˇejší patˇrí napˇr. jednotka detailnˇe zobrazující vybrané atributy entity, jednotka zobrazující seznam entit cˇ i formuláˇrová jednotka umožnující ˇ vkládání dat o entitách. S pouhým zobrazováním obsahu by však žádná reálná webová aplikace nevystaˇcila. Proto WebML obsahuje také další druhy jednotek urˇcených pro operace s daty, tzv. operaˇcní jednotky (operation units) umožnující ˇ mj. odebírat, pˇridávat a upravovat entity. Dále jsou dispozici jednotky pro práci s daty sezení (session data), mezi nˇež se rˇ adí jednotka pro pˇrihlášení a odhlášení uživatele, jednotky pro nastavování promˇenných sezení, atp. Metodika zahrnuje také mnohé další jednotky urˇcené pro práci s webovými službami, rˇ ídícími další prubˇ ˚ eh algoritmu, jednotky umožnující ˇ práci se soubory Excelu, odesílání emailu, ˚ atd. U mnoha druhu˚ jednotek se lze oprávnˇenˇe ptát, zda je jejich existence na takto vysoké úrovni ˇ abstrakce opodstatnˇená. Casto je tomu totiž tak, že jednotka reprezentuje pouhý jeden rˇ ádek zdrojového kódu,11 takže jde v zásadˇe o jakýsi symbolický zápis pseudo-kódu. Symbolické zapisování pseudokódu do hypertextového modelu je sice pochopitelné, nebot’ je motivováno snahou autoru˚ zautomatizovat implementaci v co nejvˇetší možné míˇre prostˇrednictvím automatického generování zdrojového kódu, avšak pusobí ˚ pˇresto ponˇekud pˇretˇežujícím dojmem. Analytik si naštˇestí muže ˚ svobodnˇe vybrat, do jakých detailu˚ chce návrh provést. Posledním, avšak zdaleka ne nejménˇe duležitým ˚ prvkem hypertextového návrhu jsou odkazy (links) vzájemnˇe propojující bud’ dvˇe jednotky nebo dvˇe stránky. Jejich základní rozdˇelení je následující: • Nekontextové odkazy (Non-Contextual Links) provedou pouze pˇresmˇerování na jinou stránku, aniž by pˇrenášely jakékoliv parametry. • Kontextové odkazy (Contextual Links) provedou pˇresmˇerování na jednotku na jiné stránce, pˇriˇcemž cílové jednotce pˇredají jisté datové parametry. Ne všechny parametry musí být vždy explicitnˇe uvedeny, a to v pˇrípadˇe, kdy je zpusob ˚ pˇrenášení parametru˚ zˇrejmý sám o sobˇe. Pˇríkladem muže ˚ být seznam objednávek, z nˇehož je možné pˇrejít na stránku zobrazující detail jedné objednávky. 11 Napˇr.

jednotka umožnující ˇ zaslání emailu reprezentuje pˇríkaz, který je v PHP možné vmˇestnat do jediného rˇ ádku.

119

Obrázek 4.7.: Výˇrez hypertextového diagramu notace WebML zobrazující stránku nazvanou Leave a comment.

Obrázek 4.8.: Odkazy ve WebML. Kontextový odkaz (nahoˇre), Nekontextový odkaz (uprostˇred), Transportní odkaz (dole). • Transportní odkazy (Transport Links) pˇrenášejí parametry mezi dvˇema jednotkami na jedné stránce, nemají tedy navigaˇcní funkci. Aˇckoliv návrh prezentaˇcní vrstvy není v pˇrípadˇe WebML samostatnou fází návrhu tak, jak je tomu u konkurenˇcních pˇrístupu, ˚ metodika pˇresto poskytuje jednoduchý nástroj, pomocí nˇejž je možné rozložit jednotlivé vizuální prvky na stránce. Jednotky mající vizuální reprezentaci lze umist’ovat do tzv. mˇrížky stránky (page grid), jak je patrné z obrázku (viz Obrázek 4.9). V jeho levé cˇ ásti je umístˇen výˇcet všech jednotek na stránce, v cˇ ásti pravé pak mˇrížka, do níž lze vizualizovatelné jednotky umist’ovat. Hlavní cˇ ást webové stránky má šedé pozadí, vedlejší cˇ ásti (sloupce) pak bílé. Metodika umožnuje ˇ také modelovat znovupoužitelné moduly (modules) a naplánované úlohy (jobs).12 Užití znovupoužitelných modulu˚ snižuje algoritmickou redundanci aplikace a umožnuje ˇ dokonce pˇrenášet funkˇcní cˇ ásti z jedné aplikace do druhé. Na moduly je možné jednoduše odkazovat z bˇežných stránek a opˇet se na nˇe po probˇehnutí modulu navracet. Možnost modelovat naplánované úlohy je vhodná pro zachycování tˇech procesu, ˚ jejichž spouštˇecˇ em není uživatelská akce, ale jiný druh události (typicky událost cˇ asová). Typickým pˇríkladem naplánované úlohy je napˇr. pravidelná každodenní záloha dat. 12 Viz

[Molhanec, 2009].

120


Obrázek 4.9.: Mˇrížka stránky zobrazující detaily o knize - metodika WebML.

ˇ metodiky 4.5. Výber Výše jsem struˇcnˇe pojednal o nejznámˇejších souˇcasných metodikách pro vývoj webových aplikací. Za duležité ˚ kritérium pˇri výbˇeru optimální metodiky pro zadaný úkol považuji existenci CASE nástroje. Vzhledem k tomu, že u metodiky WSDM ani OOHDM jsem se pˇri hledání pˇríslušného nástroje nesetkal s úspˇechem, v úvahu jsem nadále bral pouze metodiky UWE a WebML. Oba zbylí kandidáti mají své nesporné výhody: na stranˇe UWE je to užití prumyslového ˚ standardu UML, v pˇrípadˇe WebML proprietární, ale jednoduchá a promyšlená notace. Po nesnadné úvaze jsem z obou nakonec vybral metodiku WebML, a to z následujících du˚ vodu: ˚ • Vývojové prostˇredí WebRatio je robustní natolik, že pˇrekonává mnoho UML CASE nástroju. ˚ • Hypertextový diagram WebML obsahuje více relevantních informací a je pˇrehlednˇejší než jeho protˇejšek užívaný v rámci UWE. • Užití notace UML pro úˇcely, pro nˇež nebyla puvodnˇ ˚ e navržena, se nevyrovná proprietární notaci WebML, jež je šitá pˇrímo na míru rˇ ešenému problému.

121

5. Úvod do návrhu webové aplikace V minulé kapitole jsem provedl výbˇer metodiky pro návrh aplikace - nyní koneˇcnˇe pˇrejdu k pojednání o samotnému návrhu. Vzhledem k pˇredpokládanému rozsahu této práce není mým cílem podat vyˇcerpávající detailní návrh aplikace, spíše na nˇekolika málo pˇríkladech demonstrovat, jakým zpusobem ˚ by mˇel analytik využít znalosti získané pˇri fázi analýzy pro samotný návrh s použitím metodiky WebML. Nebudu se pˇritom vˇenovat její cˇ tvrté fázi,tj. návrhu technické architektury, nebot’ v této fázi již nejsou rˇ ešeny problémy informaˇcní analýzy a návrhu softwaru a pˇrekraˇcují proto rámec této práce.

5.1. Užité prvky notace Jak již bylo rˇ eˇceno výše (viz 4.4), metodika WebML užívá pro zachycení struktury webového sídla jakési základní stavební kameny - jednotky. Nˇekteré jednotky jsou pˇritom navrženy tak, že reprezentují fakta v pˇrílišném detailu, což není pro konceptuální návrh žádoucí. Jako nejsnazší rˇ ešení této nesnáze se nabízí prostá redukce poˇctu jednotek na co nejmenší poˇcet. Zejména jednotky reprezentující operace s daty jsou nadbyteˇcné a je vhodné je substituovat souhrnnou jednotkou Script. V rámci následujících stránek užiji pouze ty jednotky, které jsou zobrazeny v Tabulce 5.1. Obecnˇe lze rˇ íci, že z dalších jednotek jsou prakticky použitelné ještˇe následující: Module unit, Multi Data Unit, Multi Choice Index Unit, Hierarchical Index Unit, Jump Unit a Parameter Collector Unit. Existenci všech ostatních jednotek lze podle mého názoru jen velmi obtížnˇe ospravedlnit, nebot’ na konceptuální úrovni si analytik bohatˇe vystaˇcí s výše uvedenými.

5.2. Specifikace požadavku˚ Vzhledem k tomu, že a) obecné cíle již byly stanoveny (viz 2.1), b) datový slovník není tˇreba vytváˇret, nebot’ je k dispozici detailní model problémové domény, c) došlo též k analýze uživatelu˚ (resp. agentu, ˚ viz 3.3) a d) k analýze pˇrípadu˚ užití (viz 3.12), mohu rovnou pˇrejít k modelování mapy webu.

5.2.1. Mapa webu Z modelu pˇrípadu˚ užití (viz 3.12) lze odvodit také mapu webu, která definuje základní pohledy a jim podˇrízené oblasti aplikace: • Uživatelská cˇ ást je pˇrístupná registrovaným i neregistrovaným uživatelum, ˚ avšak ti registrovaní mohou provádˇet více operací. Uživatelská cˇ ást má následující oblasti: – Registrace uživatele. 123

D ATA U NIT

E NTRY U NIT

A REA

Zobrazí detailní informace o jedné instanci

Vstupní formuláˇr.

Oblast obsahující stránky patˇrící k sobˇe na

urˇcené entity.

základˇe urˇcitého kritéria..

PAGE

I NDEX U NIT

P OWER I NDEX U NIT

Stránka, základní prvek modelu. Na stránku se

Reprezentuje více instancí jedné entity jako list.

Rozšíˇrená verze základní Index Unit, dokáže

umist’ují jednotky.

Uživatel muže ˚ nˇekterou instanci vybrat.

tˇrídit vstupní informace a implementuje stránkování.

S CRIPT U NIT

S WITCH U NIT

M ULTI M ESSAGE U NIT

Jednotka reprezentující libovolný kód mající

Kontroluje tok aplikace a na základˇe vstupu

Zobrazí uživateli zprávu, tj. libovolný rˇ etˇezec.

vstupy a výstupy. Této definici tedy odpovídá

vyhodnotí, kam bude navigace pokraˇcovat.

veškerá logika webové aplikace (controller).

Tabulka 5.1.: Užité jednotky WebML. – Darování. – Petice. – Zviditelnˇení podpory. – Uživatelský profil. – Komentování. – Novinky. – Projekt. – Dobrovolnická pozice. – Komunita. – Petice. – Událost. • Administrace pˇredmˇetu˚ je pˇrístupná registrovaným uživatelu, ˚ kteˇrí jsou ve funkci správce cˇ i administrátora nˇekterého pˇredmˇetu. Její oblasti odpovídají pˇrípadum ˚ užití pro všechny druhy správcu. ˚ Administrace pˇredmˇetu˚ má následující oblasti: – Administrace organizací bude mít podsekce a) Nezisková organizace, b) Komunita a c) Firma. – Administrace pˇrípadu˚ bude mít podsekce a) Projekt, b) Petice, c) Dobrovolnická pozice, d) Událost. 124

5. Úvod do návrhu webové aplikace

Obrázek 5.1.: Základní rozložení prvku˚ na stránce.

• Administrace aplikace je vrstvou aplikace, která je pˇrístupná pouze agentum ˚ s nejvyššími oprávnˇeními, tj. administrátorum ˚ aplikace. Její oblasti proto odpovídají pˇrípadum ˚ užití pro administrátory aplikace.

5.2.2. Návrh stylu Základní barvou pozadí bude bílá, barva textu cˇ erná, doplnující ˇ barvou bude oranžová. Stránka bude v nejtypiˇctˇejším pˇrípadˇe rozdˇelena do pˇeti základních oblastí (viz Obrázek 5.1): 1. Záhlaví, v nˇemž bude zobrazeno logo aplikace, hlavní horizontální menu a základní navigaˇcní prostˇredky. 2. Levý sloupec, kde bude zobrazena ilustrace vážící se k entitˇe a menu odkazující na stránky, které jsou s aktuální stránkou bezprostˇrednˇe spjaty, pˇrípadnˇe též widgety s doplnujícími ˇ informacemi o hlavním obsahu stránky. 3. Prostˇrední sloupec obsahující hlavní obsah stránky. 4. Pravý sloupec, kde budou zobrazeny widgety s doplnujícími ˇ informacemi o hlavním obsahu stránky (typicky odkazy na entity, s nimiž je zobrazovaná entita ve vztahu), ovšem pouze ty, které mají nižší prioritu, než widgety v levém sloupci. 5. Zápatí obsahující copyright a kontakt na technickou správu aplikace. Nˇekteré stránky webu, zejména pokud plní zvláštní úlohu, mohou mít i jinou strukturu, která je však na obecné úrovni nepostižitelná a bude na ní upozornˇeno ad hoc. 125

ˇ 5.2.3. Požadavky na výkon, dostupnost, škálovatelnost, bezpecnost a rozšiˇrovatelnost aplikace Je tˇreba, aby aplikace byla v provozu nepˇretržitˇe s výjimkou plánovaných odstávek, pˇriˇcemž maximální pˇrijatelná doba odezvy na uživatelský požadavek je stanovena na 5 sekund. Dále je požadováno, aby poskytovatel konektivity zaruˇcil dostupnost serveru, na nˇemž aplikace bˇeží, a to v pomˇeru 99,98%. Vzhledem k tomu, že souˇcástí nˇekterých procesu˚ jsou též finanˇcní platby, je tˇreba dbát zvýšené bezpeˇcnosti a zajistit šifrovaný pˇrenos dat skrze protokol HTTPS. Uživatelská data musejí být držena v databázi a všechny neveˇrejné funkce musejí být chránˇeny heslem, které bude drženo v databázi v šifrované podobˇe. Lze oˇcekávat, že aplikace bude v budoucnu rozšíˇrena o další typy pˇrípadu˚ cˇ i další zpusoby ˚ podpory, rozšíˇrena možnost spolupráce s firmami, dojde k rozšíˇrení portfolia platebních metod, dojde k zapojení dalších druhu˚ organizace cˇ i uživatelu˚ do cˇ innosti zprostˇredkovatelské organizace, atd.

5.3. Pˇríklad užití WebML - Neziskový projekt Závˇerem uvedu struˇcný pˇríklad užití procesní analýzy pˇri návrhu cˇ ásti konceptuálního a hypertextového modelu webové aplikace. Konkrétnˇe využiji procesu Finanˇcní dar projektu (viz 3.8.2).

5.3.1. Konceptuální návrh Ve fázi konceptuálního návrhu je vhodné vycházet z modelu tˇríd, který vznikl ve fázi analýzy. Na obecné úrovni platí, že mezi analytickým modelem a modelem užívaným pˇri návrhu být jisté rozdíly. Nˇekteré tˇrídy souvisejí s procesy nepodporovanými informaˇcním systémem, jiné je naopak tˇreba analyzovat detailnˇeji. V nˇekolika pˇrípadech muže ˚ dojít také k doplnˇení dalších atributu˚ (napˇr. obrázku, ˚ apod). Pro konceptuální návrh bude dále namísto modelu tˇríd použit metodikou WebML pˇredepsaný ER diagram. Ve sledovaném pˇrípadˇe však žádný výrazný odklon od analytického modelu nenastává. Konceptuální model entit obsahuje entity Agent, Uživatel, Základní entita, Pˇredmˇet, Pˇrípad, Projekt, Organizace, Nezisková organizace, Podpora, Finanˇcní podpora, Dar a Odmˇena a je zobrazen na konceptuálním diagramu (viz Obrázek 5.2).

5.3.2. Hypertextový návrh V hypertextovém návrhu je možné užít diagram procesu Finanˇcní dar projektu (viz 3.8.2). Obecnˇe lze o pˇrenášení znalostí z modelu procesního do modelu hypertextového tvrdit následující: • Vˇetšina procesních událostí bude zhruba odpovídat navigaˇcnímu odkazu. • Vˇetšina atomických cˇ inností procesu bude zhruba odpovídat logice programu v script unit. • Stavy procesu budou zhruba odpovídat konkrétní webové stránce, na níž se uživatel právˇe nachází. 126

5. Úvod do návrhu webové aplikace

Obrázek 5.2.: Ukázka hypertextového modelu v notaci WebML - Výˇrez oblasti Projekt.

Jde však pouze o pˇribližná pravidla nenárokující si absolutní platnost. Vztahy v žádné pˇrípadˇe neplatí v pomˇeru 1:1; napˇr. cˇ innost procesu muže ˚ odpovídat hned nˇekolika script units. Na hypertextovém diagramu (viz Obrázek 5.3) se nachází hypertextový model implementující znalosti procesu Finanˇcní dar projektu. Uživatel vstupuje na stránku Detail projektu. Zde se zobrazí detailní informace o instanci tˇrídy Projekt, poslední dary vážící se k projektu a nˇekteré vybrané odmˇeny k projektu se vážící. Odtud muže ˚ pˇrejít bud’ na stránku zobrazující všechny dary darované v projektu (stránka Dary - všechny), všechny odmˇeny slíbené za pˇrípadný dar (stránka Odmˇeny - všechny), nebo na stránku umožnující ˇ agentovi darovat finanˇcní obnos (stránka Darovat), na níž muže ˚ bud’ vyplnit sumu zamýšleného daru, nebo se vrátit na pˇredchozí stránku. Vyplní-li a odešle finanˇcní sumu, je proveden kód Vložení daru do košíku. Je-li vložení neúspˇešné, dojde k návratu na pˇredchozí stránku a zobrazení informace o chybˇe (ˇcervená šipka), v opaˇcném pˇrípadˇe (zelená šipka) je pˇresmˇerován na stránku Výbˇer odmˇeny. Zde si muže ˚ vybrat jednu z odmˇen. Je-li pˇrihlášen, je odmˇena ihned asociována s jeho darem, v opaˇcném pˇrípadˇe bude muset nejprve na stránce Vyplnˇení osobních údaju˚ vložit své personálie. 127

Výˇrez hypertextového modelu jistˇe není kompletní, v dalších verzích bude navíc obsahovat mnoho dalších odkazu˚ na jiné cˇ ásti webu. Pro základní orientaci však plnˇe postaˇcuje.

Obrázek 5.3.: Ukázka hypertextového modelu v notaci WebML - Výˇrez oblasti Projekt.

128

ˇ 6. Zhodnocení a záver V této práci jsem nejprve provedl analýzu stavu neziskového sektoru se zamˇerˇ ením na jeho schopnost získávat zdroje na pokrytí nákladu˚ své cˇ innosti. Na základˇe dostupných údaju˚ jsem urˇcil nejzávažnˇejší problémy, pˇred nimiž neziskové organizace v této oblasti stojí. Mezi ty nejpalˇcivˇejší se rˇ adí pouze omezená duvˇ ˚ era veˇrejnosti ve schopnost neziskového sektoru efektivnˇe poskytovat služby, dále slabá sebepropagace a malá intenzita informování o neziskové cˇ innosti a jejím smyslu, dále též finanˇcní netransparentnost, nízký objem individuálních daru˚ a podílu dobrovolníku˚ na celkové aktivní populaci a v neposlední rˇ adˇe též omezená schopnost využívat informaˇcní technologie. Jako rˇ ešení tohoto problému jsem navrhl vznik zprostˇredkovatelské organizace specializující se pˇredevším na usnadnování ˇ alokace finanˇcních i mimofinanˇcních zdroju˚ nabízených neziskovým organizacím na podporu jejich projektu˚ ze strany veˇrejnosti a firem. Následnˇe jsem provedl procesní analýzu této organizace a tím též odpovˇedˇel na otázku, jakým zpuso˚ bem by mˇela organizace fungovat. Podaˇrilo se mi identifikovat celkem cˇ tyˇri klíˇcové procesy v organizaci probíhající, pˇriˇcemž první dva z nich podporují styk neziskových organizací a firem, druhé dva pak styk neziskových organizací a jednotlivcu. ˚ Vzhledem k tomu, že provedená analýza má sloužit jako podklad pro návrh informaˇcního systému zamˇerˇ eného právˇe na individuální dárce, rozhodl jsem se vˇenovat se nadále pouze druhým dvˇema klíˇcovým procesum ˚ a provést jejich detailní rozbor. Dále jsem stanovil funkcionální požadavky na informaˇcní systém pro podporu analyzovaných procesu. ˚ Klíˇcové funkcionality a jejich vztah k uživatelským rolím jsem namodeloval prostˇrednictvím diagramu pˇrípadu˚ užití. V posledním kroku jsem provedl výbˇer metodiky pro návrh tohoto systému. Aˇckoli se mi podaˇrilo dosáhnout stanoveného cíle práce, tj. a) navrhnout zpusob ˚ fungování platformní organizace, která by organizacím neziskového sektoru zprostˇredkovávala služby, jejichž využíváním mohou neziskové organizace snáze dosahovat zlepšení v problematických oblastech a b) provést analýzu požadavku˚ na informaˇcní systém pro podporu procesu˚ ve zprostˇredkovací organizaci probíhajících, je tˇreba pˇriznat, že její pˇrínos je pouze omezený. Muže ˚ sice sloužit jako jakýsi manuál pro návrháˇre a vývojáˇre a informaˇcní materiál pro grantové komise rozhodující o udílení finanˇcních prostˇredku, ˚ ale nenaplnuje ˇ zcela ambice procesního rˇ ízení, modelování a reenineeringu, nebot’ neobsahuje detailnˇejší pohled na všechny klíˇcové procesy, ale pouze na dva z nich, takže není kompletním dokumentem, na jehož základˇe by mohla probˇehnout zmˇena pˇrinášející celostní rˇ ešení problému. Tato problematika tak do urˇcité míry zustává ˚ otevˇrena další analytické práci. Analýzou byla též provˇerˇ ena schopnost metodiky MMABP zachycovat struktury a dynamiku reality, pˇriˇcemž bylo konstatováno, že dalšímu jejímu rozvoji by prospˇela existence nástroje na kontrolu konzistence jednotlivých modelu. ˚ Byla též otevˇrena otázka vhodnosti užití jazyka BPML k formalizaci procesního modelu - pro pˇrípadné navazující analytické práce proto doporuˇcují zvážit návrh proprietární notace namísto notace BPMN, jakkoli se tato stala jakýmsi standardem. Bˇehem procesní analýzy jsem byl též nucen rˇ ešit drobné pro129

blémy týkající se otázky specializace a mnohoinstanˇcních koprocesu. ˚ Otázku specializace jsem se rozhodl rˇ ešit užitím podprocesu, ˚ druhý z uvedených problému˚ spoˇcívající v adekvátní reprezentaci koprocesu˚ v pˇrípadˇe, že dojde ke spuštˇení mnoha jeho instancí naráz, jsem vyˇrešil užitím pˇríznaku <<Multiple>>.

130

Terminologický slovník

Heslo

Zkratka

Vysvˇetlivka

Active Server Pages

ASP

Technologie urˇcená pro vývoj dynamických webu. ˚

Architecture of Integrated

ARIS

Jedna z aktuálních metodik zamˇerˇ ených na procesní analýzu.

Information Systems Web menších rozmˇeru˚ obsahující obvykle pˇríspˇevky jednoho autora,

Blog

webový zápisník. Business Intelligence

BI

ˇ Cinnost, pˇri níž dochází k analýze chování na trhu, analýze obchodních vztahu˚ a získávání znalostí sloužících k optimalizaci obchodních rozhodnutí probíhajících v organizaci.

Business Process Model

BPML

Jazyk urˇcený pro formalizované vyjádˇrení procesu˚ v organizaci.

BPMN

Notace jazyka BPML urˇceného pro analýzu procesu. ˚

BSP

Metodika analýzy byznys procesu˚ používaná ve spoleˇcnosti IBM.

Language Business Process Model Notation Business System Planning CASE nástroj

Jde o speciální aplikace podporující softwarové inženýrství (viz CASE).

Class diagram

Viz diagram tˇríd.

Computer-aided Software

CASE

Poˇcítaˇcem podporované softwarové inženýrství. K jeho provádˇení je užíváno CASE nástroju˚ (viz CASE nástroj).

Engineering Concurrent Task Trees

CTT

Technika zamˇerˇ ená na modelování cˇ inností a vztahu˚ mezi nimi.

Customer Relationship

CRM

Obor cˇ innosti firmy zamˇerˇ ující se na rˇ ízení vztahu˚ se zákazníky.

DFD

Diagram datových toku, ˚ jeden z analytických nástroju. ˚

Management Data Flow Diagram

Diagram zachycující všechny stavy, jichž muže ˚ entita nabýt a pˇrechody

Diagram stavu˚ objektu

mezi nimi. Zobrazení statické struktury systému prostˇrednictvím tˇríd a vztahu˚

Diagram tˇríd

mezi nimi. Šetˇrení s využitím dotazníku, ˚ jehož cílem je získání reprezentativních

Dotazníkové šetˇrení

dat pro další statistické zpracování. Zpusob ˚ nakládání s vizuálními objekty uživatelského rozhraní v

Drag & drop

aplikaci. Objekt je možné myší zachytit, táhnout jej a poté pustit na jiném místˇe, cˇ ímž obvykle dojde ke spuštˇení uživatelské akce. Dynamic Essential Modeling of Organizations

DEMO

Souˇcasná metodika zamˇerˇ ená na procesní analýzu.

Entity-relationship diagram

ER diagram

Diagram zachycující entity a jejich vztahy v rámci problémové domény. Zde fundraisingová kampanˇ (viz fundraising), jejíž úspˇech je založen na

Friend-to-friend kampanˇ

pˇredpokladu, že nejvyšší dopad na jedince má jeho nejbližší okolí. Sdˇelení kampanˇe se šíˇrí primárnˇe prostˇrednictvím pˇrátel, nebot’ tˇem jedinec nejspíše naslouchá. Soustavná cˇ innost, jejímž výsledkem je získání finanˇcních cˇ i jiných

Fundraising

prostˇredku˚ na obecnˇe prospˇešnou cˇ innost organizací nebo jednotlivcu. ˚ Jde o nejkonkrétnˇejší, úrovenˇ modelování, která popisuje fyzické

Fyzická úrovenˇ modelování

uložení dat a stroje, na nichž systém pobˇeží. Hrubý domácí produkt

HDP

Celkové penˇežní vyjádˇrení hodnoty statku˚ a služeb vytvoˇrených za urˇcité období v ekonomice.

Hypertext Preprocessor

PHP


Hypertext Transfer Protocol

HTTP

Internetový protokol puvodnˇ ˚ e urˇcený pro získávání hypertextových dokumentu˚ ve formátu HTML, v dnešní dobˇe je jeho uplatnˇení mnohem širší.

Informaˇcní technologie

IT

Technologie používané ke zpracování informací.

Integrated Developement

IDE

Zkratka pro softwarovou aplikaci podporující proces vývoje software.

Environment Užití informaˇcních technologií (viz IT) pro podporu reálných procesu, ˚

IT aplikace

resp. rˇ ešení reálných problému. ˚ JavaServer Pages

JSP


Key Performance Indicators

KPI

Klíˇcové indikátory výkonu organizace. Mˇerˇ í, nakolik organizace dosahuje svých cílu. ˚

Konceptuální úrovenˇ

Fáze modelování, jejímž cílem je zachycení základních vztahu˚ ve

modelování

sledovaném systému. Pˇri konceptuálním modelování se zámˇernˇe abstrahuje od pˇríliš technických detailu. ˚

Methodology for Modelling

MMABP

Metodika pro modelování a analýzu byznys procesu, ˚ která vznikla na ˇ VŠE v Praze. Jejím autorem je prof. Repa.

and Analysis of Business Processes

Jde o specifický druh finanˇcních služeb obvykle poskytovaných

Mikrofinance

jedincum ˚ žijícím v rozvojových zemích, v jejichž rámci nefunguje efektivnˇe bankovní sektor. Mezi mikrofinance lze rˇ adit mikroúvˇery, mikroúspory cˇ i mikropojištˇení. Nestátní nezisková organizace

NNO

Viz nezisková organizace.

Nezisková organizace

NO

Na státu relativnˇe nezávislá organizace, jejímž cílem není primárnˇe generování zisku. Jejím cílem je obecnˇe prospˇešná cˇ innost. Sektor ekonomiky, v jehož rámci se pohybují neziskové organizace.

Neziskový sektor Object Oriented Hypermedia Design Method

OOHDM

Metodika zamˇerˇ ená na návrh webových sídel s užitím konceptu˚ objektového modelování.

132

6. Zhodnocení a závˇer

Zde ve smyslu opakované netriviální (má obvykle více dílˇcích, na sebe

Proces

navazujících cˇ inností) cˇ innosti probíhající v organizaci. Process Diagram Technique

PDT

Technika zamˇerˇ ená na co nejjednodušší procesní analýzu, která užívá pouze s nˇekolik základních konstruktu. ˚ Technický formální jazyk zamˇerˇ ený na modelování procesu˚ v

Procesní jazyk

organizaci. Konceptualizace procesu˚ a vazeb mezi procesy v organizaci. Procesní

Procesní modelování

modely jsou obvykle reprezentovány prostˇrednictvím diagramu. ˚ Manažerská disciplína pˇredpokládající využití informaˇcních technologií

Procesní rˇízení

a uchopující organizaci a její rˇ ízení prizmatem modelu podnikových procesu˚ smˇerˇ ujících k naplnˇení cílu˚ organizace. Rich Internet Application

RIA

Jedná se o aplikace IT provozované prostˇrednictvím internetových technologií (HTTP, webového prohlížeˇce, aj.). S cílem dosažení vyššího uživatelského komfortu pˇrebírají prvky aplikací desktopových.

State chart diagram

STD

Viz diagram stavu˚ objektu.

Structured query language

SQL

Jazyk urˇcený pro práci z relaˇcními strukturami

Systém

Souhrn souvisejících prvku˚ sdružených do smysluplného celku.

Trigger

Anglický výraz pro spoušt’, resp. spouštˇecˇ nˇejakého procesu.

Unified Modelling Language

UML

Zkratka pro jazyk urˇcený k zachycení široké škály konceptu˚ softwarového inženýrství. Jedná se o prumyslový ˚ standard.

UML-Based Web Engineering

UWE

Metoda urˇcená pro návrh webových sídel postavená na standardu UML. Fundraisingová kampan, ˇ jejíž podstatou je lavinové šíˇrení jistého

Virální kampanˇ

sdˇelení využívající sociální sítˇe a další zpusoby ˚ elektronické komunikace. Uživatel není k šíˇrení zprávy obvykle motivován zprávou samotnou, ale jistou pˇridanou hodnotou (hrou, pohlednicí, apod.), která je ke zprávˇe pˇridána. Web

WWW

Zkrácený tvar pro World Wide Web, celosvˇetovou sít’ aplikací, dokumentu˚ a stránek fungující na základˇe HTTP (viz HTTP).

Web Modeling Language

WebML

Nejznámˇejší a též nejprosazovanˇejší metodika vývoje webových sídel, která puvodnˇ ˚ e vznikla na polytechnice v Milánˇe, ale dnes je vyvíjena pˇredevším na komerˇcní bázi firmou Web Ratio.

Web Semantic Design Method Widget

WSDM

Metodika zamˇerˇ ená na návrh webových aplikací. Základní element pro interakci programu s uživatelem, obvykle zobrazuje urˇcité informace a umožnuje ˇ uživateli spouštˇet v aplikaci se zobrazovanými informacemi spojené akce.

133

Literatura [ARIS, 2012] ARIS Community [online]. 2012 [cit. 2012-03-20]. Business process. Dostupné z WWW: . [Boukal, 2009] BOUKAL, P. Nestátní neziskové organizace: teorie a praxe. Praha: Oeconomica, 2009. ISBN 978-80-245-1650-9. [CAF, 2006] CHARITIES ritable

giving

WWW:

AIR

FOUNDATION.

International

dokument].

[cit.

[PDF

2006

comparisons

2011-09-22].

of

cha-

Dostupné

z

giving.aspx>. [Causes Gift Cards, 2011] Causes Gift Cards [online]. 2011 [cit. 2011-10-10]. Dostupné z WWW: . [Ceri et al., 2003] CERI, S. - P. FRATERNALI - A. BONGIO. Designing Data-Intensive Web Applications. San Francisco, Calif.: Morgan Kaufmann Publishers, 2003. ISBN 1-55860-843-5. ˇ ˇ [CESKO, 1990] CESKO. „Zákon cˇ . 85 ze dne 27. bˇrezna 1990 o právu petiˇcním.“ In: ˇ Sbírka zákonu˚ CSFR. 1990, cˇ ástka 19, s. 374 - 375. Dostupný také z: http://aplikace.mvcr.cz/sbirka-zakonu/ViewFile.aspx?type=c&id=2330. ˇ ˇ [CSÚ, 2011] Ceský statistický úˇrad [online]. 2011 [cit. 2011-09-22]. Ekonomické výsledky

neziskových

institucí

2005

až

2009.

Dostupné

z

WWW:

. ˇ ˇ [CSÚ, 2010] Ceský statistický úˇrad [online]. 2011 [cit. 2011-09-22]. Ekonomické výsledky

neziskových

institucí

2004

až

2008.

Dostupné

z

WWW:

. ˇ ˇ [CSÚ, 2009] Ceský statistický úˇrad [online]. 2009 [cit. 2011-09-22]. Staˇ tistická roˇcenka Ceské republiky. Dostupné z WWW: . [Darujme.cz, 2011] Darujme.cz [online]. 20011 [cit. 2011-10-16]. Dostupné z WWW: . [Darujspravne.cz, 2011] Darujspravne.cz [online]. 2011 [cit. 2011-10-16]. Dostupné z WWW: . [Dietz, 1999] DIETZ, J., L., G. „Understanding and Modeling Business Processes with DEMO.“ In: AKOKA, Jacky; Bouzeghoub, M.; Comyn-Wattiau, I.; Elisabeth Métais, E. (Eds.) Conceptual modeling - ER’99: 18th International Conference on Conceptual Modeling, Paris, France, November 15-18, 1999 : proceedings. New York: Springer, 1999. ISBN 35-406-6686-9. [Dohnalová et al., 2003] DOHNALOVÁ, M. - MALINA, J. - MÜLLER, K. Obˇcanská spoleˇcnost: Minulost – souˇcasnost – budoucnost. Brno: Masarykova univerzita, 2003. ISBN 80-210-3180-8. 134

Literatura

[EC, 2010]

EUROPEAN

COMISSION.

Citizenship

[PDF

dokument].

2010

[cit.

2011-09-22]. Volunteering in the European Union. Dostupné z WWW: . [Edward, 2008] EDWARD, 2008.

[PDF

D.

Metody

dokument].

fundraisingu

2008

[cit.

v

ˇ Ceské

2011-09-22].

republice

Dostupné

z

-

léto

WWW:

. [Esipa, 2011] Esipa [online]. 2011 [cit. 2011-09-22]. Sbírka právních pˇredpisu. ˚ Dostupné z WWW: . ˇ [Factum Invenio, 2006] Factum invenio [online]. 2006 [cit. 2011-09-23]. Ceši a dobroˇcinnost. Dostupné z WWW: . [Fraternali et al., 2010a] FRATERNALI, P. - S. COMAI - A. BOZZON and G. T. CARUGHI. „Engineering Rich Internet with a Model-Driven Approach“. ACM Transactions on the Web. 2010, roˇc. 4, cˇ . 2, s. 1-47. [Fraternali et al., 2010b] FRATERNALI, P - G. ROSSI - F. SANCHÉZ-FIGUEROA. „Rich Internet Applications“. IEEE Internet Computing. 2010, roˇc. 14, cˇ . 3, s. 9-12. [Give Meaning, 2011] Give meaning. s. d. [cit. 2011-09-23]. About GiveMeaning.com. Dostupné z WWW: . [Giving USA, 2011] GIVING USA FOUNDATION [PDF dokument]. The Annual Report on Philantropy for the Year 2010: Free executive summary. 2011 [cit. 2011-09-21]. Dostupné z WWW: . [GMA, 2011] The Grahame Maher Award [online]. 2011 [cit. 2011-09-23]. Dostupné z WWW: . ˇ [Hladká et al., 2009] HLADKÁ, M. - ŠINKYRÍKOVÁ, T. Dárcovství v oˇcích veˇrejnosti. Brno: Spoleˇcnost pro studium neziskového sektoru, 2009. ISBN 978-80-904150-4-1. ˇ do [Kepáková et al., 2004] KEPÁKOVÁ, K. - HUDÁK, L. Neziskový sektor pˇred vstupem CR Evropské unie. Brno: Nadace Partnerství, 2004. ISBN 80-239-3130-X. [Kiva, 2011] Kiva [online]. 2011 [cit. 2011-09-23]. Kiva: About Us. Dostupné z WWW: . [Kunstová et al., 2003] KUNSTOVÁ, R. - CARDA, A. Workflow : nástroj manažera pro rˇízení podnikových procesu. ˚ 2. vyd. Praha: Grada, 2003. ISBN 80-247-0666-0. [Lundeberg et al., 1981] LUNDEBERG, M. - G. GOLDKUHL and A. G NILSSON. Information systems development: a systematic approach. Prentice Hall, 1981. ISBN 01346-4677-0. [Molhanec, 2005] MOLHANEC, M. „Metodika UWE (UML based Web Engineering)“. In: Tvorba softwaru 2005. Ostrava: VŠB, 2005, s. 143-152. ISBN 80-86840-14X. [Molhanec, 2009] MOLHANEC, M. „Novinky ve webových metodikách: Metodika WebML a nástroj WebRatio“. In: Tvorba softwaru 2009. Ostrava: VŠB, 2009, s. 121-128. ISBN 978-80-248-2012-5. [Via, 2011] Nadace

Via

[online].

2011

[cit.

2011-09-23].

Dostupné

z

WWW:

. [Network for good, 2011] Network for good [online]. 2011 [cit. 2011-10-13]. Dostupné z WWW: . 135

[Pera, 2012] PERA Enterprise Integration Web Site [online]. 2012 [cit. 2012-03-20]. ARIS. Dostupné z WWW: . [Plessers et al., 2005] PLESSERS, P. - S. CASTELEYN - O. DE TROYER. „Semantic Web Developement with WSDM“. 5th International Workshop on Knowledge Markup and Semantic Annotation, Galway, Ireland, 2005. [Pospíšil, 2005] POSPÍŠIL, M. „Mapping the Czech Nonprofit Sector“. Civil Review, 2006, roˇc. 3, cˇ . 3-4, s. 233–244. [Precidado et al., 2005] PRECIADO, J., C. - M. LINAJE - F. SANCHEZ - S. COMAI. „Necessity of methodologies to model Rich Internet Applications.“ In: DISTANTE, Damiano. Seventh IEEE International Symposium on Web Site Evolution: proceedings. Los Alamitos, Calif.: IEEE Computer Society, c2005, s. 7-13. ISBN 07-695-2470-2. ˇ ˇ [Repa, 2007] REPA, V. Podnikové procesy. 2. vyd. Praha: Grada, 2007. ISBN 978-80-247-2252-8. [Schwabe et al., 1998] SCHWABE, D. - G. ROSSI. "An Object Oriented Approach to WebBased Application Design". Theory and Practice of Object Systems, 1998, roˇc. 4, cˇ . 4, s. 1-35. ˇ [Skovajsa, 2010] SKOVAJSA, M. Obˇcanský sektor: Organizovaná obˇcanská spoleˇcnost v Ceské republice. Praha: Portál, 2010. ISBN 978-80-7367-681-0. [Springwise, 2011] Springwise [online]. 2011 [cit. 2011-09-23]. Dostupné z WWW: . ˇ ˚ V jakém stavu se nachází naše ob[STEM, 2004] STREDISKO EMPIRICKÝCH VÝZKUMU. cˇ anská spoleˇcnost? [PDF dokument]. 2004 [cit. 2011-09-22]. Dostupné z WWW: . ˇ ˚ Informace z výzkumu trendy [STEM, 2008] STREDISKO EMPIRICKÝCH VÝZKUMU. 2/2008 [PDF dokument]. 2008 [cit. 2011-09-23]. Dostupné z WWW: . [Swipegood, 2011] Swipegood [online]. 2011 [cit. 2011-09-23]. Frequently Asked Questions. Dostupné z WWW: . [Šmída, 2007] ŠMÍDA, F.: Zavádˇení a rozvoj procesního rˇízení ve firmˇe. Praha: Grada, 2007. ISBN 978-80-247-1679-4. [UWE, 2012] UWE – UML-based Web Engineering [online]. 2012 [cit. 2012-03-24]. Dostupné z WWW: . ˇ [Vajdová, 2005] VAJDOVÁ, T.: Ceská obˇcanská spoleˇcnost 2004: Po patnácti letech rozvoje. Brno: CERM, 2005. ISBN 80-7204-379-X. [WebRatio, 2012] WebRatio.com [online]. 2012 [cit. 2012-3-3]. Dostupné z WWW: . [Wing, 2010] WING, K. - ROEGER, K., L. - POLLAK, T., H. The Nonprofit Sector in Brief: Public Charities, Giving and Volunteering [PDF dokument]. 2010 [cit. 2011-09-22]. Dostupné z WWW: . [WISE, 2012] WISE Research Group [online]. 2012 [cit. 2012-03-23]. WSDM - Web Semantic Design Method. Dostupné z WWW: .

136

Seznam obrázku˚ 1.1. Názory respondentu˚ na tvrzení související s jejich pˇredstavami o neziskovém sektoru. Zdroj: [Hladká et al., 2009]. . . . . . . . . . . . . . . . . . . . . . . . .

16

1.2. Poˇcet cˇ lenství obˇcanu˚ v ruzných ˚ neziskových organizacích v roce 2004. Zdroj: [STEM, 2004]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

1.3. Ochota obˇcanu˚ pˇrispˇet finanˇcním darem na charitu v roce 2006. Zdroj:[Factum Invenio, 2006]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . ˇ v roce 2003 podle cˇ lenu˚ ne1.4. Struktura pˇríjmu˚ neziskových organizací v CR

18

ziskových organizací. Zdroj: [Kepáková et al., 2004]. . . . . . . . . . . . . . . . ˇ v roce 2003 od nepolitických subjektu˚ 1.5. Pˇríjmy neziskových organizací v CR

19

(pˇrepoˇcet). Zdroj: [Kepáková et al., 2004]. . . . . . . . . . . . . . . . . . . . . . ˇ v roce 2008. Zdroj: [Edward, 2008]. . 1.6. Efektivita fundraisingových metod v CR

19 20

1.7. Podíl daru˚ neziskovým organizacím na HDP ve vybraných zemích v roce ˇ ˇ 2006 (v procentech HDP). Zdroj: [CAF, 2006, CSÚ, 2009, CSÚ, 2010]. . . . . . .

21

1.8. Struktura dárcu˚ v USA v roce 2010 (ˇcástky jsou zaokrouhleny a uvádˇeny v miliardách dolaru). ˚ Zdroj: [Giving USA, 2011]. . . . . . . . . . . . . . . . . . .

21

1.9. Podíl aktuálních dobrovolníku˚ na populaci ve vybraných zemích svˇeta v letech 2004 - 2007. Zdroj:[EC, 2010, Wing, 2010]. . . . . . . . . . . . . . . . . . .

22

1.10. Logo služby Kiva. Zdroj: [Kiva, 2011]. . . . . . . . . . . . . . . . . . . . . . . .

24

1.11. Stránka neziskového projektu na stránce Give Meaning (upraveno). Zdroj: [Give Meaning, 2011].

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

25

1.12. Widget umístitelný na osobní blog dárce (badge) v systému Network for Good Zdroj: [Network for good, 2011]. . . . . . . . . . . . . . . . . . . . . . . .

26

1.13. Schéma vysvˇetlující zpusob ˚ fungování portálu Swipe Good. Zdroj: [Swipegood, 2011]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

1.14. Widget služby Darujme.cz, pˇríklad pochází ze stránek nadace Via. Zdroj: [Via, 2011]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

1.15. Vrchní cˇ ást úvodní stránky projektu Darujspravne.cz (výˇrez). Zdroj: [Darujspravne.cz, 2011]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

2.1. ARIS architektura. Zdroj: [Pera, 2012]. . . . . . . . . . . . . . . . . . . . . . . . . ˇ 2.2. Cást procesního modelu ARIS. Zdroj: [ARIS, 2012]. . . . . . . . . . . . . . . . .

34 35

2.3. Pˇríklad notace metodiky DEMO - procesní model. Zdroj: [Dietz, 1999]. . . . . ˇ 2.4. Schéma prubˇ ˚ ehu prací v rámci metodiky MMABP. Zdroj: [Repa, 2007]. . . . .

39 40

2.5. Užití stereotypu Multiple. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

3.1. Diagram zobrazující Okolí systému. . . . . . . . . . . . . . . . . . . . . . . . .

46

3.2. Diagram zobrazující klíˇcový proces Alokace firemní filantropie v kontextu ostatních procesu. ˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

48

3.3. Diagram zobrazující klíˇcový proces Hledání firemního podporovatele v kontextu ostatních procesu. ˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

3.4. Diagram zobrazující klíˇcový proces Nabídnutí neziskového pˇrípadu veˇrejnosti v kontextu ostatních procesu. ˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

3.5. Diagram zobrazující klíˇcový proces Zprostˇredkování podpory pˇrípadu v kontextu ostatních procesu. ˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

3.6. Diagram zobrazující dˇediˇcnost uživatelských rolí v UML. . . . . . . . . . . . .

51

3.7. Diagram klíˇcového procesu Alokace firemní filantropie. . . . . . . . . . . . . . .

53

3.8. Diagram klíˇcového procesu Hledání firemního podporovatele. . . . . . . . . . . .

54

3.9. Nejobecnˇejší model tˇríd zobrazující pouze základní entity. . . . . . . . . . . .

56

3.10. Stavový diagram tˇrídy Základní entita. . . . . . . . . . . . . . . . . . . . . . . .

56

3.11. Stavový diagram tˇrídy Pˇrípad. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

3.12. Výˇrez diagramu tˇríd - Typologie pˇrípadu. ˚ . . . . . . . . . . . . . . . . . . . . .

58

3.13. Diagram klíˇcového procesu Nabídnutí pˇrípadu veˇrejnosti. . . . . . . . . . . . . .

59

3.14. Proces Zpracování pˇrípadu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

3.15. Diagram procesu Zpracování projektu. . . . . . . . . . . . . . . . . . . . . . . . .

61

3.16. Diagram stavu˚ entity Projekt. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

3.17. Proces Zpracování události. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

3.18. Proces Nastavení nákupu lístku. ˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

3.19. Proces Urˇcení místa konání. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

3.20. Proces zachycující Provoz pˇrípadu. . . . . . . . . . . . . . . . . . . . . . . . . . .

66

3.21. Diagram procesu s názvem Zprovoznˇení projektu. . . . . . . . . . . . . . . . . .

66

3.22. Diagram procesu s názvem Ukonˇcení fundraisingového režimu. . . . . . . . . . .

67

3.23. Diagram procesu Zprostˇredkování podpory pˇrípadu. . . . . . . . . . . . . . . . .

68

3.24. Stavový diagram tˇrídy Zpráva. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

3.25. Model tˇríd zobrazující základní entity spojené s podporou pˇrípadu˚ (zjednodušený orientaˇcní výˇrez). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

3.26. Diagram zachycující životní cyklus tˇrídy Finanˇcní podpora (vlevo) a Dlouhodobá podpora (vpravo). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

3.27. Diagram procesu s názvem Finanˇcní dar projektu. . . . . . . . . . . . . . . . . .

71

3.28. Diagram procesu s názvem Vložení finanˇcní podpory do košíku. . . . . . . . . . .

72

3.29. Tˇrídy vážící se k procesum ˚ spojeným s darováním. . . . . . . . . . . . . . . . .

72

3.30. Diagram procesu s názvem Podpora události nákupem lístku. . . . . . . . . . . .

74

3.31. Tˇrídy vztahující se k nákupu lístku. ˚ . . . . . . . . . . . . . . . . . . . . . . . . .

74

3.32. Diagram procesu s názvem Vyjednání dobrovolniˇcení. . . . . . . . . . . . . . . .

75

3.33. Diagram procesu s názvem Vyjednání firemního dobrovolnictví. . . . . . . . . . .

77

3.34. Diagram procesu˚ s názvem Kandidatura zamˇestnance na dobrovolnickou pozici (vlevo) a Oslovení zamˇestnancu˚ (vpravo). . . . . . . . . . . . . . . . . . . . . . .

78

3.35. Diagram tˇríd spojených s procesy firemního dobrovolnictví. . . . . . . . . . .

78

3.36. Diagram procesu s názvem Podepsání petice. . . . . . . . . . . . . . . . . . . . .

79

3.37. Diagram tˇríd souvisejících s podpisem petice. . . . . . . . . . . . . . . . . . . .

80

3.38. Diagram procesu s názvem Registrace uživatele. . . . . . . . . . . . . . . . . . .

81

3.39. Stavový diagram tˇrídy Uživatel. . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

3.40. Diagram tˇríd souvisejících s procesem Registrace neziskové organizace. . . . . .

82

138

Seznam obrázku˚

3.41. Diagram procesu s názvem Registrace neziskové organizace. . . . . . . . . . . . .

83

3.42. Stavový diagram tˇrídy Organizace. . . . . . . . . . . . . . . . . . . . . . . . . .

84

3.43. Stavový diagram tˇrídy Smlouva. . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

3.44. Diagram procesu Registrace firmy. . . . . . . . . . . . . . . . . . . . . . . . . . .

86

3.45. Diagram procesu Registrace komunity. . . . . . . . . . . . . . . . . . . . . . . . . ˇ 3.46. Diagram procesu Clenství v komunitˇe. . . . . . . . . . . . . . . . . . . . . . . . .

86 87

3.47. Diagram procesu s názvem Dokonˇcení objednávky. . . . . . . . . . . . . . . . . .

89

3.48. Stavový diagram tˇrídy Objednávka. . . . . . . . . . . . . . . . . . . . . . . . . .

89

3.49. Stavový diagram pro tˇrídu Platba. . . . . . . . . . . . . . . . . . . . . . . . . . .

90

3.50. Diagram procesu s názvem Platba. . . . . . . . . . . . . . . . . . . . . . . . . .

90

3.51. Diagram procesu s názvem Spárování plateb. . . . . . . . . . . . . . . . . . . . .

91

3.52. Diagram procesu s názvem Uzavˇrení objednávky. . . . . . . . . . . . . . . . . .

92

3.53. Diagram procesu s názvem Pˇrevod penˇez neziskovým organizacím. . . . . . . . .

94

3.54. Diagram tˇríd souvisejících s objednávkami a platbami. . . . . . . . . . . . . .

94

3.55. Diagram procesu s názvem Navrácení finanˇcních podpor. . . . . . . . . . . . . .

95

3.56. Diagram procesu s názvem Zviditelnˇení podpory. . . . . . . . . . . . . . . . . .

96

3.57. Diagram tˇrídy Widget ve vztahu s tˇrídou Pˇríznivectví. . . . . . . . . . . . . . .

97

3.58. Diagram procesu s názvem Stání se pˇríznivcem. . . . . . . . . . . . . . . . . . .

98

3.59. Diagram procesu s názvem Pˇridání zamˇestnance. . . . . . . . . . . . . . . . . .

99

3.60. Diagram procesu Vyˇrízení žádosti. . . . . . . . . . . . . . . . . . . . . . . . . . . 100 3.61. Tˇrídy týkající se žádosti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 3.62. Stavový diagram entity Žádost. . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 3.63. Diagram cˇ innosti Vymazání entity. . . . . . . . . . . . . . . . . . . . . . . . . . . 101 3.64. Diagram procesu Ukonˇcení spolupráce s organizací. . . . . . . . . . . . . . . . . . 102 3.65. Diagram procesu Ukonˇcení dlouhodobé podpory. . . . . . . . . . . . . . . . . . . 102 3.66. Diagram procesu Zrušení uživatelského úˇctu. . . . . . . . . . . . . . . . . . . . . 103 3.67. Náˇcrt pokrytí procesu˚ funkcionalitami. . . . . . . . . . . . . . . . . . . . . . . 103 3.68. Diagram pˇrípadu˚ užití pro neregistrované hosty a registrované uživatele. . . 108 3.69. Diagram pˇrípadu˚ užití pro uživatele, kteˇrí jsou správci a administrátoˇri. . . . 108 4.1. Fáze metodiky WSDM. Zdroj: [WISE, 2012]. . . . . . . . . . . . . . . . . . . . . 112 4.2. Výˇrez

ze

schématu

navigaˇcních

tˇríd

metodiky

OOHDM.

Zdroj:

[Schwabe et al., 1998] (Obrázek byl oˇríznut). . . . . . . . . . . . . . . . . . . . 114 4.3. Výˇrez ze schématu navigaˇcních kontextu˚ metodiky OOHDM. Zdroj: [Schwabe et al., 1998]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 4.4. Pˇríklad modelu navigaˇcní struktury metodiky UWE. Zdroj: [UWE, 2012]. . . 116 4.5. Výˇrez diagramu modelu prezentace metodiky UWE. Zdroj: [UWE, 2012] (obrázek byl oˇríznut). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 4.6. Výˇrez datového ER diagramu notace WebML. Zdroj: pˇríklad pˇrikládaný k aplikaci WebRatio, viz [WebRatio, 2012]. . . . . . . . . . . . . . . . . . . . . . . 118 4.7. Výˇrez hypertextového diagramu notace WebML zobrazující stránku nazvanou Leave a comment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 4.8. Odkazy ve WebML. Kontextový odkaz (nahoˇre), Nekontextový odkaz (uprostˇred), Transportní odkaz (dole). . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 4.9. Mˇrížka stránky zobrazující detaily o knize - metodika WebML. . . . . . . . . . 121 139

5.1. Základní rozložení prvku˚ na stránce. . . . . . . . . . . . . . . . . . . . . . . . . 125 5.2. Ukázka hypertextového modelu v notaci WebML - Výˇrez oblasti Projekt. . . . . 127 5.3. Ukázka hypertextového modelu v notaci WebML - Výˇrez oblasti Projekt. . . . . 128

140

Seznam pˇríloh Pˇríloha 1 – Konzistenˇcní tabulky

ˇ tabulky Pˇríloha 1 - Konzistencní

-

Čekání na určení lokace

Dokončení zpracování případu

Čekání na specifikaci


Požadavek na odměny zaslán

Zaslání požadavku na určení odměn

Uložení odměn

1

Čekání na určení typu

Požadavek

-

Požadavek na určení typu události

Potřeba zpracovat událost

Entita

Předchozí stav

Akce

Následný stav

Stavový diagram Událost

Odměna

Požadavek

-

ZPRACOVÁNÍ UDÁLOSTI

Projekt zpracován



Procesní diagram

Požadované odměny

Zvolený režim projektu

Zvolený režim projektu

Požadavek

Uložení režimu projektu


-

Požadavek na specifikaci režimu projektu

Potřeba zpracovat projekt

Entita

Předchozí stav

Akce

Následný stav


Případ

Administrace

ZPRACOVÁNÍ PROJEKTU

Případ zpracován


Procesní diagram

Požadavek na zpracování případu

Potřeba zpracovat případ

Případ

Jmenování žadatele administrátorem


-

Vytvoření záznamu o případu

Potřeba zpracovat případ

Entita

Následný stav

Předchozí stav

Akce

Událost

Stavový diagram

Procesní diagram

ZPRACOVÁNÍ PŘÍPADU

-

Předchozí stav

-

-

-

-

Předchozí stav

Vytvořen

-

-

Předchozí stav

Vytvoření

Přechod

Vytvoření

Vytvoření

-

Vytvoření

Přechod

Připravení

Vytvoření

Vytvoření

Přechod

Vytvořen

Následný stav

Vytvořena

Vytvořen

-

Vytvořen

Následný stav

Připraven

Vytvořena

Vytvořen

Následný stav

Dotaz na kategorie zaslán


Požadavek na kategorizaci sedadel zaslán

Čekání na určení míst konání

Uložení kategorií

Zaslání dotazu na rezervaci sedadel

Uložení sedadel

Zaslání požadavku na určení cen sedadel

Čekání na odpověď


Přiřazení místa konání k

Místo konání

Místo konání

2

Určení místa konání

Určení místa konání ukončeno

-

-

Sedadlo -

-

-

Předchozí stav

-

-

-

-

-

-

Předchozí stav

-

-

-

Místo konání

Požadavek

Vytvoření místa konání a sedadel


-

Požadavek na specifikaci místa konání

Potřeba určit místo konání

Entita

Předchozí stav

Akce

Následný stav


Požadavek

Sedadlo

Požadavek

Cenová kategorie

Požadavek

URČENÍ MÍSTA KONÁNÍ

Požadavek na kategorizaci sedadel zaslán

Nákup lístků vyřešen

Dotaz na rezervaci odeslán

Dotaz na rezervaci odeslán


Procesní diagram

Místo konání určeno

Návrh cen sedadel

Zaslání návrhu kategorií

Zaslání návrhu kategorií

Odpověď k nákupu

Požadavek

Dotaz na lístky zaslán

Dotaz na lístky zaslán

Zaslání požadavku na def. cenových kategorií

Potřeba vyřešit nákup lístků

-

Zaslání dotazu na nákup lístků

Následný stav

Entita

Událost

Konání události

NASTAVENÍ NÁKUPU LÍSTKŮ

Událost zpracována

Požadavek

Předchozí stav

Periodicita, Specifikace konání

Dotaz na periodicitu zaslán

Požadavek

Akce

Dotaz na konání zaslán, Dotaz na periodicitu zaslán

Vytvoření konání události

Určený typ

Dotaz na konání zaslán

Stavový diagram


Dotaz na periodicitu

Určený typ

Procesní diagram


Požadavek na specifikaci všech konání události

-

Vytvoření

Vytvoření

Vytvoření

Přechod

Vytvoření

Vytvoření

Vytvoření

Vytvoření

Vytvoření

Vytvoření

Přechod

Vytvoření

Vytvoření

Vytvoření

-

Vytvořeno

Vytvořeno

Vytvořen

Následný stav

Vytvořen

Vytvořeno

Vytvořen

Vytvořena

Vytvořen

Vytvořen

Následný stav

Vytvořeno

Vytvořen

Vytvořen

-

Projekt

-

Konec fundraisingového režimu

3

Projekt je provozován v běžném režimu

Finanční podpora

Projekt

Uvolnění finančních podpor

Projekt neuspěl

Čekání na navrácení

Uložení neúspěchu projektu

Platby navráceny

Entita

Předchozí stav

Akce

Následný stav

Stavový diagram

Procesní diagram Událost


UKONČENÍ FUNDRAISINGOVÉHO REŽIMU

Požadavek na publikování případu

Projekt

Převedení projektu do běžného provozu

Projekt provozován ne fund. rež.

-

Převedení projektu do fundraisingového režimu

Požadavek na publikování případu

Entita

Následný stav

Předchozí stav

Akce

Událost

Případ

Zadržena

Fundraisingový režim

Předchozí stav

Připraven

Připraven

Předchozí stav

Připraven

Zveřejněno

Příznivectví

ZPROVOZNĚNÍ PROJEKTU

Případ provozován

Zveřejněn

Připraven

Zveřejněn

Předchozí stav

Případ

Případ

Stavový diagram

Požadavek na zprovoznění

Případ uzavřen

Případ uzavřen

Procesní diagram

Případ pozastaven

Požadavek na uzavření

Případ zveřejněn

Zveřejnění případu

Požadavek na uzavření

Případ pozastaven

Případ

Uzavření případu a příznivectví

Případ pozastaven

Případ provozován

Pozastavení případu

Požadavek na pozastavení

Entita

Následný stav

Předchozí stav

Akce

Událost

Stavový diagram

PROVOZ PŘÍPADU

ukončeno

Procesní diagram

události

Uvolnění

Neúspěch

Přechod

Uvedení do běžného provozu

Spuštění získávání financí

Přechod

Zveřejnění

Ukončení

Ukončení

Ukončení

Pozastavení

Přechod

Realizována

Neuspěl

Následný stav

Běžný provoz


Následný stav

Zveřejněn

Ukončeno

Ukončen

Ukončen

Připraven

Následný stav

Čekání na vložení

Čekání na odpověď / Čekání na údaje


Čekání na údaje

Uložení odměny za dar

Požadavek na vyplnění osobních údajů

Uložení osobních údajů

Vloženo

4

Finanční podpora

-

Vytvoření záznamu o finanční

Potřeba vložit fin. podporu do

Entita

Předchozí stav

Akce

Následný stav


Agent

Požadavek

-

Požadavek

VLOŽENÍ FINANČNÍ PODPORY DO KOŠÍKU

Darování připraveno

Čekání na údaje

Darování připraveno


Procesní diagram

Osobní údaje

Zájem o odměnu

Zájem o odměnu / Osobní údaje

Vloženo

-

Zjištění zájmu o odměnu


Čekání na vložení

Přepočítání objednávky

Vloženo

Entita

Následný stav

Předchozí stav

Akce

-

Předchozí stav

-

-

-

-

-

Předchozí stav

Vytvořena

Zpráva


-

-

Předchozí stav


Zpráva

FINANČNÍ DAR PROJEKTU

Podpora započata

Procesní diagram

Nabídka podpory

-

-

Podpora započata

Zaslání zprávy o výsledku

Nabídka podpory

-

Přiřazení podpory komunitě

Následný stav

Entita

Událost

Projekt

Předchozí stav

PODPORA PŘÍPADU


Akce

Konec fundraisingového režimu

Stavový diagram

-

Procesní diagram

Převedení do běžného provozu

Vytvoření

Přechod

Vytvoření

Vytvoření

-

Vytvoření

-

Přechod

Odeslání

Vytvoření

-

Přechod

Uvedení do běžného provozu

Vytvořena

Následný stav

Vytvořen

Vytvořen

-

Vytvořen

-

Následný stav

Odeslána

Vytvořena

-

Následný stav

Běžný provoz

Potřeba vložit fin. podporu do košíku

-

-

Vytvoření objednávky

Přidání finanční podpory

-

Objednávka




Zaslání požadavku na počet lístků

Požadavek na výběr sedadla

-

Čekání na vyřízení


Potvrzení dobrovolničení

Zamítnutí dobrovolničení

Žádost zamítnuta

Žádost potvrzena

Potřeba stát se dobrovolníkem

5

Dobrovolničení odmítnuto

Dobrovolničení ustanoveno


Dobrovolničení

Dobrovolničení

Žádost

Dobrovolničení

Vytvoření žádosti


-

Předběžná registrace dobrovolničení

Potřeba stát se dobrovolníkem

Entita

Předchozí stav

Akce

Následný stav


Požadavek

Předběžně registrováno


-

-

Předchozí stav

-

-

Vytvořena

Zpráva Požadavek

-

-

Předchozí stav

-

-

Zpráva

VYJEDNÁNÍ DOBROVOLNIČENÍ

Volná sedadla zaslána

Dotaz na počet zaslán

Nákup zrušen

Procesní diagram

Vybrané konání

Vybrané konání

Vybrané konání

Požadavek

Zaslání zprávy o neúspěchu


-

Zaslání všech konání události

Potřeba nakoupit lístek

Entita

Předchozí stav

Akce

Následný stav

Stavový diagram


Vloženo

Vloženo

PODPORA UDÁLOSTI NÁKUPEM LÍSTKU

Potřeba vložit fin. podporu do košíku

košíku

podpoře

Odmítnuto

Schválení

Vytvoření

Předběžná registrace

Přechod

Vytvoření

Vytvoření

Odeslání

Vytvoření

Vytvoření

Přechod

-

Vytvoření

Odmítnuto

Realizováno

Vytvořena


Následný stav

Vytvořen

Vytvořen

Odeslána

Vytvořena

Vytvořen

Následný stav

-

Vytvořena

-



Schválení firemního dobrovolnictví

Ukončení zpracování fir. dob.

Firemní dobrovolnictví zrušeno

Firemní dobrovolnictví zpracováno


Firemní dobrovolnictví


Žádost



-

-

Předchozí stav

6

Požadavek zaslán

Požadavek

-

Zaslání požadavku na výběr zaměstnanců

Požadavek na oslovení zaměstnanců

Entita

Předchozí stav

Akce

Následný stav

Stavový diagram


Požadavek

OSLOVENÍ ZAMĚSTNANCŮ

Požadavek zaslán

-

Zaslání požadavku na výběr pozice

Potřeba stát se firemním dobrovolníkem

Entita

Následný stav

Předchozí stav

Akce

Událost

Stavový diagram

Procesní diagram

-

Předchozí stav

-

Předchozí stav

KANDIDATURA ZAMĚSTNANCE NA DOBROVOLNICKOU POZICI

Žádost zamítnuta

Žádost potvrzena

Potřeba firemního dobrovolnictví


Vytvoření žádosti


-

Vytvoření firemního dobrovolnictví

Potřeba firemního dobrovolnictví

Entita

Následný stav

Předchozí stav

Akce

Událost

Stavový diagram

Procesní diagram

VYJEDNÁNÍ FIREMNÍHO DOBROVOLNICTVÍ

Vytvoření

Přechod

Vytvoření

Přechod

Odmítnuto

Schválení

Vytvoření


Přechod

Vytvořen

Následný stav

Vytvořen

Následný stav

Odmítnuto

Realizováno

Vytvořena


Následný stav

Čekání na údaje

Čekání na údaje

Podpis petice

-

-

-

Kontrolní e-mail zaslán


Vytvoření uživatele

Zaslání kontrolního e-mailu

Aktivace účtu

Smazání účtu

Timeout

E-mail potvrzen

Požadavek na registraci přijat


-

7

Registrace selhala

Uživatel registrován



-

Uživatel

Vytvořen

Vytvořen

Vytvořena

Zpráva Uživatel

-

Zpráva

-

Vytvořena

Zpráva Uživatel

-

-

Předchozí stav

-

-

-

Předchozí stav

Zpráva

-

Zaslání zprávy o zamítnutí


-

Kontrola požadavku


Entita

Předchozí stav

Akce

Následný stav


Podpis petice

Agent

REGISTRACE UŽIVATELE

Petice podepsána

Čekání na zviditelnění

Procesní diagram

Potřeba podepsat petici / Osobní údaje

Osobní údaje

Požadavek

Uložení údajů o agentovi

Čekání na údaje

-

Zaslání požadavku na vyplnění osobních údajů

Potřeba podepsat petici

Entita

Následný stav

Předchozí stav

Akce

Událost

Stavový diagram

Procesní diagram

PODPIS PETICE

Smazání

Aktivace

Odeslání

Vytvoření

Vytvoření

Odeslání

Vytvoření

-

Přechod

Vytvoření

Vytvoření

Vytvoření

Přechod

Smazán

Aktivní

Odeslána

Vytvořena

Vytvořen

Odeslána

Vytvořena

-

Následný stav

Vytvořen

Vytvořen

Vytvořen

Následný stav

-

-

-, Smlouva odeslána

Smlouva odmítnuta

-

-

-

Smlouva odeslána

Smlouva odeslána

Kontrola žádosti

Zamítnutí registrace

Uvědomění NNO

Příprava smlouvy

Podepsání smlouvy

Zaslání smlouvy k podpisu

Zrušení smlouvy

Přijetí organizace

Příchod žádosti o registraci

8

Podmínky zaslány, Žádost zamítnuta

Firma

Administrace

-


Předběžná registrace firmy


-


Následný stav

Entita

Událost

Předchozí stav

-

-

Předchozí stav

Předběžně registrována


Akce

Zaslána k podpisu

Smlouva odmítnuta

Podepsána ZO

Vytvořena

Smlouva

Smlouva

Smlouva

Smlouva

-

Vytvořena

Zpráva Smlouva

-

Vytvořena

-

-

-

Předchozí stav

Zpráva


-


Stavový diagram

REGISTRACE FIRMY

Registrace dokončena

Žádost zamítnuta

Smlouva odeslána

Smlouva odeslána

Smlouva odeslána

Viz proces.

Žádost zamítnuta

Smlouva odeslána, Žádost zamítnuta


Procesní diagram

Vyplněná smlouva navrácena

Smlouva odmítnuta

Příchod žádosti

Příchod žádosti

Příchod žádosti

Smlouva odmítnuta

Smlouva odmítnuta, Příchod žádosti

Příchod žádosti

Příchod žádosti

Administrace

Předběžná registrace NNO


-


Příchod žádosti

Entita

Následný stav

Předchozí stav

Akce

Událost

Stavový diagram

Procesní diagram

REGISTRACE NEZISKOVÉ ORGANIZACE


Vytvoření

Přechod

Aktivace

Podepsání NNO

Zrušení

Zaslání k podpisu

Podepsání ZO

Vytvoření

Odeslání

Vytvoření

Zamítnutí

-


Vytvoření

Přechod


Vytvořena

Následný stav

Aktivní

Podepsána NNO

Zrušena

Zaslána k podpisu

Podepsána ZO

Vytvořena

Odeslána

Vytvořena

Zamítnuta

-


Vytvořena

Následný stav

-


Uživatel je členem komunity

Požadavek na odchod z komunity

9

Členství ukončeno

-

-

Zaznamenání odchodu z komunity

Uživatel je členem komunity

-

Přidání se ke komunitě

Požadavek na přidání se ke komunitě

Entita

Předchozí stav

Akce

Následný stav


Administrace

Komunita

ČLENSTVÍ V KOMUNITĚ

Komunita vytvořena,

Komunita vytvořena

Procesní diagram

Požadavek na vytvoření komunity


-

-

Předchozí stav

-

-

Vytvořena

Zpráva

-

-

Zpráva

Vytvoření komunity

Registrace selhala

-

Zaslání zprávy o zamítnutí


Entita

Následný stav

Předchozí stav

Předchozí stav


Firma

Akce

Událost

Zaslána k podpisu

Vytvořena

Zpráva Smlouva

-

Vytvořena

-

Zpráva

Firma

-

REGISTRACE KOMUNITY

Registrace dokončena

Viz proces.

Žádost zamítnuta


Stavový diagram

Podmínky odsouhlaseny

Viz proces.



Procesní diagram

Přijetí firmy

Viz proces.

Smlouva odeslána

-

Zamítnutí registrace

Uvědomění žadatele

-

Kontrola žádosti

-

-

Přechod

Vytvoření

Vytvoření

Odeslání

Vytvoření

Přechod

Aktivace

Podepsání NNO

Odeslání

Vytvoření

Zamítnutí

-

-

-

Následný stav

Vytvořena

Vytvořena

Odeslána

Vytvořena

Následný stav

Aktivní

Podepsána NNO

Odeslána

Vytvořena

Zamítnuta

-

-

Čekání na údaje

Čekání na údaje

Objednávka rezervována



Uložení osobních údajů

Výzva k platbě

Vytvoření platby

Zrušení nerealizovaných podpor

Zrušení objednávky

Informace zaslány

Informace zaslány

Potvrzení platby

Zaslání potvrzení plátci

Zpráva o úspěchu transakce

Zpráva o úspěchu transakce

Vybraný způsob

10

Platba potvrzena

Platba potvrzena

Informace zaslány

. Vytvořena

Zpráva

Probíhá


-

Předchozí stav

Objednávka

Rezervována

-

-

-

Nákupní košík

Předchozí stav

Zpráva

Platba

Platba

Požadavek

Dotaz na způsob zaslán


Zaslání informací o platbě

Potřeba provést platbu

-

Zaslání dotazu na způsob platby

Následný stav

Entita

Událost

Předchozí stav

Akce

Objednávka

Finanční podpora

Platba

Agent

Požadavek

Stavový diagram

PLATBA

Objednávka zrušena

Objednávka zrušena

Čekání na platbu



Čekání na údaje

Procesní diagram

Požadavek na zrušení rezervace, Vypršení rezervace objednávky

Požadavek na zrušení rezervace, Vypršení rezervace objednávky

Požadavek na provedení platby

Osobní údaje / Požadavek na dokončení objednávky

Osobní údaje

Požadavek na dokončení objednávky

Objednávka

Požadavek na vyplnění osobních údajů

Objednávka rezervována / Čekání na údaje

-

Rezervace objednávky

Požadavek na dokončení objednávky

Entita

Následný stav

Předchozí stav

Akce

Událost

Stavový diagram

Procesní diagram

DOKONČENÍ OBJEDNÁVKY

Zaslání

Vytvoření

Zaplacení

Předání bance

Vytvoření

Přechod

Zrušení

Zrušení

Vytvoření

Vytvoření

Vytvoření

Rezervování

Přechod

Zaslána

Vytvořena

Zaplacena

Probíhá

Vytvořen

Následný stav

Zrušena

Zrušena


Vytvořen

Vytvořen

Rezervována

Následný stav

.

-

-

.

Odeslání všech lístků

Zaslání potvrzení

Uložení uzavření objednávky

Potřeba uzavřít objednávku




11

Objednávka uzavřena




Objednávka

Zpráva

-

Finanční podpora

Finanční podpora

Zadržení fin. podpor na projekty ve FR


.

Potvrzení běžných finančních podpor


Entita

Předchozí stav

Akce

Následný stav

Stavový diagram


Platba

UZAVŘENÍ OBJEDNÁVKY

Platby provedeny

-

Potvrzení došlých plateb

Výpis transakcí na účtu

Entita

Následný stav

Předchozí stav

Událost

Požadavek

SPÁROVÁNÍ DOŠLÝCH PLATEB

Platba vyřízena převodem

Platba

Akce

Vybraný způsob

Platba zrušena

Stavový diagram


Zaslání informací o bankovním spojení

Zpráva o selhání transakce, Timeout

Procesní diagram

Informace zaslány

Zrušení platby

Rezervována

-

-

Rezervována

Rezervována

Předchozí stav


Předchozí stav

-

Probíhá

Zaplacení

Vytvoření

-

Zadržení

Potvrzení platby

Přechod

Zaplacení

Přechod

Vytvoření

Zrušení

Potvrzena

Vytvořena

-

Zadržena

Realizována

Následný stav

Zaplacena

Následný stav

Vytvořen

Zrušena

Čekání na kalkulaci

Platby vytvořeny

Platby odeslány / Čekání na vyřešení problému

Platby odeslány / Čekání na vyřešení problému

Odeslání plateb bance

Potvrzení finančních podpor a platby

Zaslání zprávy o transakci Vytvořena

Zpráva

-

-

Čekání na potvrzení

Čekání na potvrzení / Čekání na vyřešení problému

Čekání na potvrzení / Čekání na vyřešení

Zaslání plateb bance

Řešení problému s bankou

Potvrzení plateb

Uložení navrácení finanční podpory

Potvrzení plateb / Problém vyřešen

Potvrzení plateb / Problém vyřešen

Vypršel čas

Potřeba navrátit platby agentům


12

Platby navráceny

Platby navráceny

Čekání na vyřešení problému



Finanční podpora

Platba

-

Platba

Platba

-

Vytvoření plateb


-

Výběr finančních podpor k navrácení


Entita

Předchozí stav

Akce

Následný stav

Stavový diagram

Realizována

Probíhá

-


-

-

Předchozí stav

-

Probíhá

Platba Zpráva

Zaplacena


-

Předchozí stav

Finanční podpora

Platba


Převod peněz NNO dokončen

Převod peněz NNO dokončen

Platba odeslána

Platby odeslány

NAVRÁCENÍ FINANČNÍCH PODPOR

Potvrzení provedení plateb / Problém vyřešen

Potvrzení provedení plateb / Problém vyřešen

Pokyn k provedení plateb

Závazky spočteny

Platba

Vytvoření plateb

Čekání na kalkulaci

-

Spočtení výše závazků vůči NNO

Čas provést platby vůči NNO

Entita

Následný stav

Předchozí stav

Akce

Událost

Stavový diagram

Procesní diagram

PŘEVOD PENĚZ NEZISKOVÝM ORGANIZACÍM

Navrácení

Zaplacení

-

Předání bance

Vytvoření

-

Přechod

Odeslání

Vytvoření

Zaplacení

Odeslání

Předání bance

Vytvoření

Přechod

Navrácena

Zaplacena

-

Probíhá


-

Následný stav

Odeslána

Vytvořena

Zaplacena

Odeslána

Probíhá


Následný stav

-

Čekání na výsledek

Čekání na odpověď_2

Nabídnout šíření zprávy

Šířit zprávu

-

Návrh zaslán

Generování a zaslání widgetu

13

Zaměstnanec přidán

Agent

-

Vytvoření zápisu o zaměstnanci

Potřeba registrovat

Entita

Následný stav

Předchozí stav

Akce

-

Předchozí stav

-

Zpráva


-

-

-

Předchozí stav

.

-

-

-

Předchozí stav

Widget

Požadavek

PŘIDÁNÍ ZAMĚSTNANCE

Příznivectví vytvořeno

Návrh zaslán

Procesní diagram

Potvrzení

Potřeba vytvořit příznivectví

Příznivectví

Nabídnout možnost generování widgetu

Návrh zaslán, Příznivectví vytvořeno

-

Uložení příznivectví

Potřeba vytvořit příznivectví

Entita

Předchozí stav

Akce

Následný stav


Zpráva

Požadavek

Požadavek

STÁNÍ SE PŘÍZNIVCEM

Probíhá šíření

Čekání na odpověď_2


Procesní diagram

Odpověď na šíření

Jakýkoli konec

Potřeba zviditelnit podporu

-

Nabídnout příznivectví


-

Uložit spojení podpory s příznivectvím

Potřeba zviditelnit podporu

Entita

Následný stav

Předchozí stav

Akce

Událost

Stavový diagram

ZVIDITELNĚNÍ PODPORY

Procesní diagram

problému

Vytvoření

Přechod

Vytvoření

Vytvoření

Vytvoření

Vytvoření

Přechod

Vytvoření

-

-

-

Přechod

Vytvořen

Následný stav

Vytvořena

Vytvořen

Vytvořen

Vytvořeno

Následný stav

Vytvořena

-

-

-

Následný stav

Žádost čeká na vyřízení


Potvrdit žádost

Zamítnout žádost

Požadavek na vymazání entity

14

Entita vymazána

Libovolná entita

-

Vymazání entity

Následný stav

Entita

Událost

Předchozí stav

Akce

Žádost

Žádost

Žádost

Stavový diagram

VYMAZÁNÍ ENTITY

Žádost zamítnuta

Žádost potvrzena


Procesní diagram

Odmítnutí

Potvrzení

Přečteno

Žádost

Žádost čeká na přečtení

Žádost čeká na přečtení

Zaznamenat přečtení

Požadavek na vyřízení žádosti o potvrzení

-

Zaměstnání

Zaslání žádosti druhé straně

Následný stav

VYŘÍZENÍ ŽÁDOSTI

Zaměstnanec přidán

Zaměstnání

Entita

Událost

Žádost přijata

Přidání zaměstnance selhalo

Žádost

Předchozí stav


Potvrzení zaměstnání

Žádost zamítnuta


Zaměstnání

Akce


Zamítnutí zaměstnání

Potřeba registrovat zaměstnance


Stavový diagram

-

Vytvoření žádosti o schválení

Potřeba registrovat zaměstnance

Zaměstnání

Procesní diagram

-

Předběžná registrace zaměstnání

zaměstnance

?

Předchozí stav

Přečtena

Přečtena

Odeslána

Vytvořena

Předchozí stav



-

-

-

Smazání

Přechod

Odmítnutí

Schválení

Přečtení

Odeslání

Přechod

Schválení

Odmítnutí

Vytvoření


Vytvoření

Smazána

Následný stav

Odmítnuta

Schválena

Přečtena

Odeslána

Následný stav

Realizováno

Odmítnuto

Vytvořena


Vytvořeno

-

-

Uvědomění organizace Vytvořena

Zpráva

-

-

Požadavek na ukončení uživatelského účtu

15

Spolupráce ukončena

Vytvořena

Zpráva

Aktivní/Pozastaven Zpráva

Uživatel

Uvědomění uživatele


-

Ukončení uživatele

Požadavek na ukončení uživatelského účtu

Entita

Následný stav

Předchozí stav

Akce

Předchozí stav

Vytvořena

Zpráva


-

Realizována

Zpráva

ZRUŠENÍ UŽIVATELSKÉHO ÚČTU


Procesní diagram

Požadavek na ukončení dlouhodobé podpory

Dlouhodobá podpora

Uvědomění podporovatele i podporovaného


-

Ukončení dlouhodobé podpory

Požadavek na ukončení dlouhodobé podpory

Entita

Předchozí stav

Akce

Následný stav

Stavový diagram Předchozí stav

-

Podepsána NNO

Aktivní

Předchozí stav

Zpráva

Smlouva




UKONČENÍ DLOUHODOBÉ PODPORY

Požadavek na ukončení spolupráce s organizací


Organizace

Odstoupení od smlouvy


-

Ukončení organizace


Entita

Následný stav

Předchozí stav

Akce

Událost

Stavový diagram

Procesní diagram

UKONČENÍ SPOLUPRÁCE S ORGANIZACÍ

Odeslání

Vytvoření

Zrušení

Přechod

Odeslání

Vytvoření

Ukončení

Přechod

Odeslání

Vytvoření

Odstoupení

Ukončení

Přechod

Odeslána

Vytvořena

Zrušen

Následný stav

Odeslána

Vytvořena

Ukončena

Následný stav

Odeslána

Vytvořena

Odstoupena

Ukončena

Následný stav

VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE Fakulta informatiky a statistiky Katedra informačních technologií

Recommend Documents