Mendelova univerzita v Brně Provozně ekonomická fakulta
Modelování podnikové architektury a návrh struktury komponent informačního systému v oblasti služeb Diplomová práce
Vedoucí práce: doc. Ing. Ivana Rábová, Ph.D.
Vypracoval: Bc. Martin Tomášů Brno 2012
Poděkování Rád bych na tomto místě poděkoval vedoucí mé práce doc. Ing. Ivaně Rábové, Ph.D. za odborné vedení, cenné připomínky poskytnuté při zpracování diplomové práce a v neposlední řadě za její ochotu a čas.
Prohlášení Prohlašuji, že jsem tuto práci vyřešil samostatně s použitím literatury, kterou uvádím v seznamu použité literatury.
V Brně dne 20. května 2012
Martin Tomášů
Abstrakt Tomášů, M. Modelování podnikové architektury a návrh struktury komponent informačního systému v oblasti služeb. Diplomová práce, Brno, 2012. Diplomová práce se zabývá modelováním podnikových procesů. Jejím hlavním cílem je vytvoření procesního modelu s využitím čtyř konceptů – proces, zdroj, cíl, pravidlo. Pro modelování je využito objektového přístupu, diagramů notace UML a zvoleného CASE nástroje. Na základě procesního modelu je zvolen proces z oblasti řízení vztahů se zákazníky a ten je podroben inovaci ve formě softwarové aplikace využívající technologie PHP a MySQL. Implementaci předchází podrobná analýza požadavků na software a tvorba modelů popisující vytvářenou aplikaci. Klíčová slova: inovace procesů, modelování podnikových procesů, informační systém, notace UML, CASE.
Abstract Tomášů, M. Enterprise architecture modeling and design of components structure of the information system in the field of services. Diploma thesis, Brno, 2012 The diploma thesis focuses on business process modeling. Main objective is to create a process model using four concepts - process, source, destination, rule. For modeling is used object-oriented approach, diagrams of UML notation and the selected CASE tool. Based on the process model is chosen the process of customer relationship management and it is subject to innovation in the form of software applications using PHP and MySQL technologies. Prior to implementation was carried out detailed requirements analysis and to create models that describe the application. Keywords: processes innovation, business process modeling, information system, UML notation, CASE.
OBSAH 1 ÚVOD A CÍL PRÁCE ............................................................................................................... 8 1.1 ÚVOD ................................................................................................................................................... 8 1.2 CÍL ....................................................................................................................................................... 8
2 TEORETICKÁ ČÁST PRÁCE ............................................................................................... 10 2.1 PODNIKOVÉ PROCESY ........................................................................................................................ 10 2.2 ZLEPŠOVÁNÍ PROCESŮ ...................................................................................................................... 11 2.2.1
Continual process improvement (CPI) .......................................................................... 11
2.2.2
Business process reengineering (BPR) ........................................................................... 12
2.3 MODELOVÁNÍ PROCESŮ .................................................................................................................... 12 2.4 OBJEKTOVĚ ORIENTOVANÝ PŘÍSTUP (OOP) ..................................................................................... 13 2.4.1
Objekt ................................................................................................................................. 14
2.4.2
Třída ................................................................................................................................... 15
2.5 JAZYK UML ....................................................................................................................................... 15 2.5.1
Historie jazyka UML ........................................................................................................ 16
2.6 UNIFIED PROCESS .............................................................................................................................. 16 2.7 DIAGRAMY V UML ........................................................................................................................... 18 2.7.1
Business Process Model (BPM) ....................................................................................... 18
2.7.2
Diagram případů užití (Use case diagram) ................................................................... 21
2.7.3
Diagram tříd (Class diagram) ......................................................................................... 23
2.7.4
Diagram aktivit (Activity diagram) ................................................................................ 25
2.7.5
Stavový diagram (State diagram) ................................................................................... 26
2.7.6
Sekvenční diagram (Sequence diagram) ....................................................................... 27
2.7.7
Diagram komponent (Component diagram) ................................................................ 27
2.7.8
Entitně-relační diagram (Entity-relationship diagram) ............................................... 28
2.8 CASE NÁSTROJE................................................................................................................................ 29 2.8.1
Druhy CASE nástrojů ....................................................................................................... 29
2.8.2
Enterprise Architect .......................................................................................................... 30
2.8.3
Visual Paradigm for UML ............................................................................................... 31
2.9 IMPLEMENTAČNÍ TECHNOLOGIE ...................................................................................................... 31 2.9.1
Jazyk PHP .......................................................................................................................... 31
2.9.2
MySQL ............................................................................................................................... 32
2.9.3
XHTML .............................................................................................................................. 32
2.9.4
CSS ...................................................................................................................................... 32
2.9.5
Nette framework ............................................................................................................... 32
3 METODIKA ............................................................................................................................. 34 4 VLASTNÍ PRÁCE ................................................................................................................... 36 4.1 ZÁKLADNÍ INFORMACE O SLEDOVANÉM PODNIKU ......................................................................... 36 4.2 SOUČASNÝ STAV A MOTIVACE PODNIKU .......................................................................................... 37 4.3 ANALÝZA PODNIKOVÝCH PROCESŮ ................................................................................................. 37 4.3.1
Základní pohled na podnikové procesy ........................................................................ 37
4.3.2
Správa objednávek............................................................................................................ 41
4.3.3
Aktivace služeb ................................................................................................................. 42
4.3.4
Technická podpora ........................................................................................................... 44
4.3.5
Dotazníkový výzkum ....................................................................................................... 46
4.3.6
Cílená nabídka služeb ...................................................................................................... 47
4.4 SOUČASNÁ SOFTWAROVÁ PODPORA PROCESŮ V PODNIKU ............................................................. 49 4.5 INOVACE PROCESU DOTAZNÍKOVÉHO VÝZKUMU ............................................................................ 51 4.5.1
Use Case diagram ............................................................................................................. 52
4.5.2
Diagram tříd ...................................................................................................................... 62
4.5.3
Diagram aktivit ................................................................................................................. 63
4.5.4
Sekvenční diagram ........................................................................................................... 66
4.5.5
ERD diagram ..................................................................................................................... 68
4.5.6
Uživatelské rozhraní ........................................................................................................ 71
5 DISKUZE .................................................................................................................................. 73 6 ZÁVĚR ...................................................................................................................................... 75 7 LITERATURA .......................................................................................................................... 77 SEZNAM OBRÁZKŮ .................................................................................................................. 79
1 ÚVOD A CÍL PRÁCE 1.1 Úvod Efektivita je zdrojem, který nás posouvá kupředu, díky ní šetříme čas i peníze. V dnešní době je efektivita často skloňovaným pojmem, jelikož na trh denně vstoupí plno nových firem, které se snaží být lepší než jejich konkurence. Společnosti se tedy snaží v efektivitě spatřovat především konkurenční výhodu. S tímto slovem je nejčastěji spojována výpočetní technika a informační systémy. Informační systémy jsou moderním způsobem jak docílit zefektivnění činností podniku, jelikož dokážou automatizovat a zjednodušovat každodenní procesy probíhající v podniku. Informační systém může být důležitým zdrojem, ovšem musí být sestaven vhodným způsobem a musí vyhovovat procesům, které podnik vykonává. Před sestavením informačního systému si podnik musí být jistý, že procesy, které vykonává, nejsou zbytečné a jsou optimální vzhledem k jeho rozsahu a činnosti podnikání. K tomu, aby mohl být vytvořen efektivní informační systém, je tedy zapotřebí identifikovat veškeré procesy v podniku a optimalizovat je. Jelikož bude-li se podnik snažit vytvářet informační systém bez řádné znalosti a optimalizace svých procesů bude riskovat, že výsledek taktéž nebude optimální. Jakmile podnik dokáže odhalit skutečně všechny procesy, které vykonává, teprve tehdy může uvažovat o jejich optimalizaci a následně o efektivním informačním systému. Analýza procesů je činností analytika, který musí umět najít veškeré skryté procesy, vzít v potaz potřeby podniku, jeho zaměstnanců a zrovna tak zákazníků a zjištěné poznatky aplikovat při sestavení procesního modelu, který tvoří vzácný podklad pro vznik informačního systému. Podnik, který nemá dobře zmapovány své procesy, by se dal přirovnat k hráči baseballu, který má zavřené oči a snaží se odpalovat nahazované míče. Plno míčků mine a časem se možná i trochu naučí takto trefovat do některých míčků, ovšem těžko by mohl konkurovat hráči, který má obě oči otevřené.
1.2 Cíl Hlavním cílem této práce bude vytvoření procesního modelu zvoleného podniku, který působí v oblasti služeb. Modelování procesní architektury v podniku bude
8
provedeno na základě čtyř konceptů – proces, zdroj, cíl, pravidlo. Při analýze bude použito objektového přístupu, diagramů notace UML a zvoleného CASE nástroje. Analýza povede k identifikaci vybraného procesu z oblasti podpory řízení vztahů se zákazníky na základě konzultace procesního modelu s managementem podniku a dále k optimalizaci tohoto procesu prostřednictvím výpočetní techniky. Dílčími cíly bude vytvoření webové aplikace na bázi PHP a MySQL, která bude tvořit podporu zvoleného procesu a následná implementace a integrace navržené aplikace do prostředí zvoleného podniku.
9
2 TEORETICKÁ ČÁST PRÁCE 2.1 Podnikové procesy Pohledů a definic na podnikové procesy je mnoho, například Eriksson chápe podnikový proces jako „jednoduše strukturovanou sadu aktivit seřazenou v čase a navrženou pro tvorbu specifického výstupu pro jednotlivého zákazníka nebo trh, během níž se mění stav podnikových zdrojů. Zahrnuje silný důraz na to, jak je práce prováděna v organizaci, nikoliv na to, co je vyráběno. Proces je specifické seřazení pracovních aktivit v čase a místě se začátkem a koncem a jasně identifikovatelnými vstupy a výstupy strukturovanými na akce“ (Rábová, 2008). Ovšem Řepa třeba definuje podnikový proces jako „souhrn činností, transformujících souhrn vstupů do souhrnů výstupů (zboží nebo služeb) pro jiné lidi nebo procesy, používajíce k tomu lidi a nástroje“ (Řepa, 2006) Jiná formální definice procesu říká: „proces je po částech uspořádaná množina aktivit, které přinášejí přidanou hodnotu“. (Rábová, 2008) Příkladem procesu může být například přijímání nového zaměstnance do podniku. Proces začíná vypsáním výběrového řízení na konkrétní pozici zaměstnavatelem. Vstupem procesu jsou zájemci o danou pracovní pozici. Dále dochází k osobnímu pohovoru s každým zájemcem. Po skončení pohovorů zaměstnavatel vyhodnotí jednotlivé zájemce a zvolí si zaměstnance, který nejvíce vyhovuje jeho předpokladům. Proces končí v okamžiku podpisu smlouvy mezi zaměstnancem a zaměstnavatelem. Podnikové procesy se dají rozdělit do tří kategorií: Řídící procesy (strategické plánování, řízení kvality) – cílem je zajišťování rozvoje a výkonnosti společnosti a vytváření vhodného prostředí pro ostatní procesy. Hlavní procesy (výroba, logistika, řízení vztahů se zákazníkem) – tvoří hodnoty v podobně výrobků a služeb pro zákazníky, jsou nedílnou součástí hodnotového řetězce celé organizace. Podpůrné procesy (ekonomika, personalistika, IT) – jejich úkolem je zajišťovat podmínky pro správné fungování ostatních procesů v podniku dodáním hmotných, či nehmotných výstupů, tyto procesy však nejsou součástí hodnotového řetězce. (Sodomka, 2006)
10
Procesy můžeme dále charakterizovat následujícími prvky: Každý standardizovaný proces je opakovatelný, výstupy procesů tvoří produkty nebo služby s přidanou hodnotou, musí být měřitelný, z každého procesu lze po analýze zjistit jeho kvalitu, náklady, dobu trvání apod., je mu přiřazen vlastník, což může být osoba nebo pracovní tým, který se stará o jeho správnou funkčnost, provoz a zlepšování, má svého zákazníka (interní či externí), je exaktně vymezeno, kde proces začíná a kde končí, kde se váže na další procesy, využívá podnikové zdroje (finanční, hmotné, lidské). (Sodomka, 2006)
2.2 Zlepšování procesů Konkurenční boj na současných trzích je značný, podniky jsou nuceny čelit dravému prostředí, v kterém není jednoduché se udržet. Pro udržení musí podniky neustále přemýšlet nad tím jak zefektivňovat svoji činnost. Snažit se využít svůj potenciál na maximum a získat konkurenční výhodu. Z těchto důvodů je nutné, se zamýšlet nad efektivností podnikových procesů. Od počátku devadesátých let je možné si všimnout zrychlujícího se tempa pečování o efektivnost podnikových procesů. Tento fakt způsobuje především technologický vývoj a otevřenost světových trhů. Mezi nejpoužívanější techniky zlepšování procesů patří Průběžné zlepšování procesů (Continual process improvement – CPI) a Business process reengineering (BPR)
2.2.1 Continual process improvement (CPI) Neboli postupné zlepšování procesů. Jedná se o techniku průběžné úpravy procesu. V prvé řadě je třeba proces řádně popsat, dále se stanoví potřebné metriky k následnému měření. Dále je proces sledován za chodu. Během sledování se provádí měření na základě určených metrik. Na základě zjištěných dat jsou navržena opatření, která vedou k optimalizaci procesu. Implementací změn ovšem
11
tato technika nekončí, důležité je dále stejným způsobem dohlížet na nově upravený proces a stále průběžně opakovat předchozí kroky. (Řepa, 2007) Techniku průběžné zlepšování procesů je vhodné využít tehdy, pokud dané procesy plní svůj účel relativně dobře a hodí se pro dolaďování relativně funkčních procesů. Nehodí se pro procesy, kterým je třeba změnit strukturu v co nejkratší možné době, jelikož neplní svůj účel efektivně tak, jak by mohli a je třeba jejich okamžitá restrukturalizace.
2.2.2 Business process reengineering (BPR) Tato technika vznikla jako reakce na zrychlující se tempo zlepšování procesů. Technika je co se změny procesu týče značně radikální a zanechává za sebou techniku postupného zlepšování. Spočívá v negativním pohledu na současný proces, považuje ho za nevyhovující, nefunkční, špatně navrhnutý a je třeba změnit úplně podstatu procesu. (Řepa, 2007) Při BPR nejprve dochází k definici rozsahu projektu a jeho cílů, dále je třeba analyzovat potřeby a možnosti, což je nejdůležitější část BPR. Jedná se o analýzu požadavků na nový proces, do kterých se promítá celé okolí podniku a především zkušenosti zaměstnanců a možnosti nových technologií. Na základě této předběžné analýzy jsou navrženy nové procesy. Jakmile jsou návrhy kompletní, je možné přejít do fáze plánování jednotlivých akcí, které umožní zavedení nových procesů a následnou implementaci. Poslední fází je tedy samotná implementace nového procesu.
2.3 Modelování procesů Podnikové procesy jsou jakousi sítí činností a aktivit, které se navzájem prolínají. Každou činnost, kterou je možné v podniku zaznamenat lze zapsat jako proces, strukturovat jej a zařadit do komplexní hierarchie ostatních podnikových procesů. Po zobecnění všech modelů podnikových procesů, lze identifikovat jejich společné prvky, jimiž jsou: proces, činnost, podnět, vazba
12
Aktivity jednotlivých procesů jsou řazeny do návazností, jež vytváří určitou strukturu. Takovéto návaznosti jsou dále popsány pomocí vazeb, které definují uspořádání aktivit v procesu. Procesní modelování lze rozdělit na: Procesní či funkční modelování procesů – zaměřuje se na nejvyšší úroveň pohledu na jednotlivé činnosti v podniku, na elementy řídící tyto činnosti a na výsledky činností. Modelování procesních toků – nebol-li workflow modelování, či modelování aktivit. Soustředí se na jednotlivé procedury a na rozhodování, které je obsaženo ve výkonu jednotlivých aktivit a dále také na tok informací mezi procesy. Modelování datových toků – zaměřuje se na aktivity, které zpracovávají data. (Rábová, 2008) Využití výše zmíněných typů, je v plné rozhodovací kompetenci podniku, který vykonává procesní modelování. Díky technikám modelování procesů je možné nalézt procesy, které nejsou produktivní, nevytvářejí žádné žádoucí výstupy. Lze objevit také duplicitu v jednotlivých procesech. Cílem datového modelování je tedy poskytnutí obrazu abstraktních aktivit, který usnadní orientaci ve složité spleti podnikových procesů a umožní jejich efektivnější a rychlejší inovace. Během vývoje procesního modelování vznikly dva hlavní přístupy pro modelování procesů. Prvně používaný byl strukturovaný přístup, ovšem v dnešní době se již od něj upouští a je preferován schematičtější objektový přístup neboli objektové modelování.
2.4 Objektově orientovaný přístup (OOP) Jedná se o alternativu ke strukturovanému přístupu, který nedokázal pokrývat potřeby všech projektů. Cílem objektově orientovaného přístupu je především znovu použitelnost, komponentový přístup a snadnější tvorba software. Je to sice novější způsob, ovšem strukturovaný přístup stále nachází své uplatnění. Nelze tvrdit, že je OOP jediným správným nástrojem, mnohdy je třeba totiž tyto přístupy kombinovat. (Merunka, 2005) Snahou OOP je využití principů fungování reálného světa, snažit se přiblížit co nejvěrnějším způsobem realitě a jejím objektům.
13
Základní rysy OOP: abstrakce, tvorba objektů, třídy objektů, zapouzdření, ukrývání implementace, komunikace objektů, dědičnost, polymorfizmus.
2.4.1 Objekt Reálný svět je složen z objektů, které jsou různě kombinované a mají svoji funkčnost, seskupení různých objektů dává vzniknout objektům novým s novou funkcionalitou. V reálném světě většinou není důležité, jak daný objekt funguje, ale k čemu slouží, k čemu se dá použít a co se z něj dá vytvořit. Takových principů využívá právě OOP a umožňuje vznik modulárního systému. Objekt je tedy uzavřená struktura, která má následující charakteristiky: Stav objektu – je určen hodnotami atributů v daný čas. Chování objektu – je určen množinou funkcí, které objekt může vykonávat. Identita objektu – jednoznačný způsob identifikace daného objektu v čase a prostoru. Důležité pro komunikace mezi objekty. Spolupráce objektů tvoří výslednou aplikaci. Objekty spolu můžou komunikovat pouze tehdy, pokud volající objekt zná identitu volaného objektu. Každý objekt má tři základní vlastnosti: Zapouzdření – je rozlišováno vnitřní prostředí objektu a vnější prostředí, vnitřní prostředí je před vnějším ukryto, je možné s ním manipulovat pouze prostřednictvím metod objektu.
14
Polymorfizmus – neboli mnohotvárnost, umožňuje vykonávat více objektům stejnou funkci, přičemž každý takový objekt danou funkci implementuje jiným způsobem. Dědičnost – vznikají vztahy mezi nadřízeným objektem a podřízeným objektem, dědičná třída přebírá všechny vlastnosti (atributy, metody) mateřského objektu. (Kraval, 2008)
2.4.2 Třída Třídy lze chápat jako abstrakce, které představují určitou množinu objektů, jež mají společné vlastnosti. Je šablonou, vzorem pro objekty podobného charakteru. Objekt je třeba chápat jako instanci třídy. Máme například třídu Automobil a vytvoříme konkrétní reálný objekt této třídy, například Škoda Fabia, která převezme obecné vlastnosti třídy Automobil a dosadí za ně specifické hodnoty pro vytvořený objekt Škoda Fabia. (Kraval, 2008)
2.5 Jazyk UML UML je unifikovaný modelovací jazyk (Unified Modelling Language), který má sloužit jako univerzální jazyk pro modelování informačních systémů. Byl vyvinut společností OMG (Object Management Group). Původně měl sloužit k tomu, aby poskytnul nástroje pro vývoj programových systémů, které podporují takzvaný objektově orientovaný návrh. Je navržen obecně, aby jej mohl implementovat kterýkoliv CASE (Computer-Aided Software Engineering) nástroj. Má vlastní grafickou sémantiku a syntaxi. Jazyk UML neobsahuje přímo metodiku, metodika tvorby modelů je popsána pomocí Unified Process. UML v dnešní době již slouží jako nástroj, pomocí, kterého lze popsat téměř cokoliv. (Řepa, 2007) Nejnovější standard UML 2.0 zavádí také novou sadu diagramu, vhodných především pro procesní modelování. Struktura jazyka UML se skládá z následujících částí: stavební bloky, společné mechanismy, architektura. Stavební bloky jsou tvořeny předměty, vztahy a diagramy. Stavební bloky spolu úzce souvisí. UML nabízí čtyři rozličné způsoby jak modelovat objekty –
15
specifikace (grafické, textové), ornamenty (zobrazují detaily o diagramu), podskupiny (třídy a instance, rozhraní, implementace), mechanizmy rozšířitelnosti (omezení, stereotypy, označené hodnoty). (Arlow, Neustadt, 2007) UML tvoří čtyřvrstvou architekturu pohledů na systém: logický pohled – funkce systému, slovník, pohled procesů – výkon systému, škálovatelnost, propustnost, pohled implementace – montáž systému, konfigurace pohled nasazení – topologie systému, distribuce, doporučení a instalace Tyto pohledy jsou sjednoceny v pohledu případu užití, který je obrazem požadavků koncového uživatele. (Arlow, Neustadt, 2007)
2.5.1 Historie jazyka UML První zmínky o objektově orientovaných modelovacích jazycích jsou kolem 70. let 20. Století. Do pár let však již bylo takových jazyků desítky, to ovšem mělo spíš negativní následek pro vývoj těchto jazyků. V roce 1994 vzniká sjednocená metoda Booch a OMT (Object Modeling Technique) pracovníky Grady Boocha a Jima Rumbaugha z Rational Corp. V roce 1995 Ivar Jacobson prezentuje svoji metodu Objectory. Tyto práce se snažili sjednotit předchozí bouřlivý vývoj modelovacích jazyků, které měli za následek vzájemnou nekompatibilitu mezi mnohými modelovacími jazyky. V roce 1996 je výše zmíněnou trojící vytvořen jazyk UML 0.9 a založeno konsorcium UML Partners, které sdružovalo podniky, které měli zájem na vývoji UML 1.0. Tím se položily základy ke vzniku kvalitního a sjednoceného jazyka UML 1.0. (Fowler, 2009) V dnešní době již je k dispozici UML 2.0, které umožňuje přesnější modelování a má komplexněji definovanou sémantiku. Jazyk je částečně zjednodušen od přebytečných definic, pro které bylo minimální použití. Jazyk je dále například doplněn o podporu procesního modelování, o vylepšení sekvenčních diagramů, byla zlepšena podpora zapouzdření u behaviorálního modelování.
2.6 Unified Process Jedná se o standard vytvořený organizací, která podnítila vznik jazyka UML. Projekt UML vznikl z potřeby vytvořit jak vizuální jazyk, tak proces tvorby
16
software. UML lze chápat jako jazykovou složku projektu, kdežto procesní část je tvořena metodikou Unified Process. Na rozdíl od UML Unified Process není standardem organizace OMG. (Arlow, Neustadt, 2007) Unified Process je metodika iterativní a přírůstková. Projekt je rozdělen na menší části, které je jednoduší spravovat a tím je lépe podchycena výsledná správná funkčnost projektu. Každá část projektu je považována za iteraci. Pro každou iteraci jsou definovány následující postupy: požadavky - zachycují potřeby a funkce systému, ve fázi zahájení a rozpracování, analýza - strukturování požadavků, ve fázi zahájení, rozpracování, konstrukci, návrh - realizace požadavků v architektuře systému, ve fázi rozpracování a konstrukci, implementace - tvorba software, ve fázi rozpoznávání a konstrukci, testování - ověření správnosti implementace, ve všech fázích. Pro každou fázi jsou stanoveny milníky v podobně cílů, aby byl milník uskutečněn je třeba dosáhnout stanoveného výsledku např. modelu, dokumentu, prototypu atd. (Arlow, Neustadt, 2007)
Obr. 1: Metodika Unified Process (R – Requirements, A – Analysis, D – Design, I – Implementation, T – Test), zdroj: (Arlow, Neustadt, 2007)
Unified Process stanovuje několik fází vývoje software. Mezi tyto fáze patří: zahájení (prvotní představy o funkčnosti systému a jeho požadavcích),
17
rozpracování (vytváření modelů), konstrukce (fyzická realizace software), zavedení (testování, tvorba dokumentace).
2.7 Diagramy v UML Diagramy slouží jako vizuální ztvárnění obsahu modelu, které schematicky zachycuje prvky a vztahy mezi nimi. Diagramy samotné netvoří model, jsou ovšem jeho součástí. Lze je rozdělat na diagramy modelující statickou strukturu a diagramy modelující dynamickou strukturu systému. Statický model slouží k popisu předmětů a struktury asociací mezi předměty. Dynamický model popisuje interakce mezi jednotlivými předměty a jejich chování. Je možné se také setkat s rozdělením na diagramy struktury a diagramy chování. Výběr vhodných diagramů je plně v kompetenci analytika, záleží na možnostech a rozsahu projektu. UML nabízí širokou škálu diagramu, ovšem pro účely této práce budou popsány pouze ty nejčastěji využívané.
Obr. 2: Schéma rozdělení diagramu, zdroj: Arlow, Neustadt, 2007
2.7.1 Business Process Model (BPM) Mezi nejrozšířenější profily pro modelování podnikových procesů patří profil H. Erikssona vycházející ze čtyř pohledů na organizaci:
18
Pohled strategický – reflektuje vize organizace, strategické cíle, hodnoty, silné a slabé stránky, příležitosti a hrozby. Obsahuje hlavní problémy a úmysly, které bude procesní změna řešit. Procesní
pohled
–
pozornost
věnuje
podnikovým
procesům,
činnostem a hodnotám, které zahrnují tyto aktivity. Popisuje též vzájemnou interakci těchto procesů, využívá zdrojů v organizaci. Strukturní pohled – přibližuje strukturu celé organizace, zahrnuje zdroje organizace, jako organizační jednotky, produkty, informace, dokumenty a znalosti atd. Chování organizace – zahrnuje vnitřní chování a interakci zdrojů a procesů. Kladen je důraz na přiřazování odpovědnosti za jednotlivé zdroje. (Řepa, 2007) Pohledy jsou doplňovány o textový dokument, kde jsou využity rozšiřující mechanizmy podnikového modelování. Na základě výše zmíněných čtyř pohledů dochází k definici čtyř základních podnikových konceptů, jimiž jsou proces, zdroj, cíl a pravidlo. (Rábová, 2008) a) Zdroj - Eriksson definuje zdroj jako „entitu, která může hrát roli při realizaci určité třídy v systému, je to koncept použitý v podniku a představuje cokoliv, co vybereme pro zhodnocení podniku jako celku“. (Rábová, 2008) Jedná se o objekty, které podnikové procesy spotřebovávají, vytváří, transformují či pouze používají. Lze je rozdělit na zdroje fyzické (materiálního charakteru – výrobky), zdroje abstraktní (myšlenky, nápady, energie) a informační (jsou nositeli informací o jiných zdrojích). Zdroje jsou modelovány jako třídy. b) Cíl - koncept obsahující hlavní a vedlejší cíle podniku, jejich stanovení a kontrola plnění stanovených cílu. K modelování struktury cílu je možné využít diagram tříd. c) Pravidlo – jsou různá nařízení, která mají vliv na chod podnikových procesů a stavy jednotlivých entit. Pravidla lze rozdělit na strukturální (mající vztah k organizačním strukturám), behaviorální (chování podniku) a funkční (vztah na průběh procesů). (Rábová, 2008)
19
d) Proces – definice procesu dle Erikssonova modelu již byla představena v úvodu literárního přehledu, dále tedy bude spíše kladen důraz na grafické
znázornění
diagramu
vycházejícího
z Erikssonova
pojetí
procesního modelování. Hlavními prvky diagramu BPM jsou procesy. Mezi další faktory ovlivňující procesy dle notace Erikssona a Penkera jsou: Vstupy (input) – objekty, které proces spotřebovává, či transformuje, patří zde lidské zdroje, suroviny, informace atd. Výstupy (output) – objekty, jež představují výsledky daného procesu. Podpůrné objekty (supply) – objekty, jež proces používá ke svému průběhu,
ovšem
nejsou
během
procesu
spotřebovány
či
transformovány, může se jednat o informace, suroviny, ale také lidské zdroje. Řídící objekty – objekty, které vstupují do procesu a řídí jeho běh. Cíle (goal) – objekty, které znázorňují cíle modelovaného procesu. Cíl je velice důležité stanovit, jelikož má značný vliv na průběh procesu a kontrolu jeho výstupu. Cíl může být například rychlost a kvalita uskutečněného procesu, spokojenost aktéru s procesem aj. Události (event) – za událost lze považovat třeba dosažení určitého data, přijetí nového objektu. Událost může být spotřebována i transformována, či může podmínit vznik nového procesu. (Eriksson, Penker, 2000)
20
Obr. 3: Notace BPM dle Erikssona a Penkera
2.7.2 Diagram případů užití (Use case diagram) Řepa popisuje diagram případů užití jako „diagram, původně v UML určený ke specifikaci funkčních požadavků a uživatelského rozhraní informačního systému, je chápán jako model, popisující podnikové procesy a jejich interakce s aktéry. Tento model je označován jako tzv. Externí model, sloužící popisu vztahů organizace s okolím.“ (Řepa, 2007, str. 147) Modelování případů užití je jednou z forem inženýrství požadavků (Arlow, Neustadt, 2007). Diagram případů užití reflektuje funkční požadavky systému. Cílem je zaznamenat tyto požadavky z pohledu uživatele systému. Kromě identifikace funkčních požadavků, tento diagram napomáhá k analýze okolí systému a zjištění, jaké subsystémy budou ve výsledném produktu figurovat a kde jsou jejich hranice. Podstatnou částí je také identifikace všech rolí, které budou s jednotlivými případy užití manipulovat. Jak uvádí Arlow, správné určení hranic systému má velký dopad na funkční požadavky, potažmo také na nefunkční. Dobře stanovené požadavky jsou stavebním kamenem celého projektu.
21
Špatně specifikované požadavky mohou způsobit neúspěch a nefunkčnost výsledného produktu. (Arlow, Neustadt, 2007) Hlavním cílem jsou tedy požadavky na systém, tyto požadavky jsou reprezentovány modelem, který obsahuje: a) Hranice systému (system boundary) – ohraničení kolem případů užití, které znázorňuje, které případy užití souvisí s vnitřním prostředí systému a které s jeho vnějším. Tím dochází k oddělení systému od okolí a je možné tedy řešit problémy systému separátně od okolních systému. Systém je v diagramu případů užití znázorněn jako rámec s popisem
a
názvem
systému,
akteři
se
nacházejí
vždy
vně
ohraničeného systému. b) Případy užití – jsou modelovány z pohledu aktéra, představují jeho očekávání od systému, jeho konkrétní funkce a možnosti. V UML je vyznačen elipsou s názvem dané očekávané funkce. c) Vztahy – neboli asociace mezi případy užití a aktéry. Znázorňují relaci, která je symbolem komunikace mezi prvky diagramu případu užití. Tato relace bývá doplněna o slovo, které vyjadřuje danou činnost systému. Je možné vytvořit relaci i mezi aktéry na základě generalizace či specializace. Existují také vazby mezi případy užití: -
Include – pevný vztah, kdy jeden případ užití zahrnuje ještě jiný případ užití, všechny takto spojené případy užití se musí provést jako by se jednalo o jeden.
-
Extends – volnější typ vazby, s možností volby, jeden případ užití může být za určitých podmínek rozšířen o další případ užití, vazba je tedy podmíněna rozhodnutím aktéra.
-
Generalizace – zobecnění chování několika případů užití
d) Slovník pojmů – cílem slovníku pojmů je sjednocení terminologie mezi zhotovitelem projektu a uživatelem. Jedná se o podchycení specifického názvosloví pro dané odvětví. Snaží se eliminovat nejasnosti při komunikaci, kdy každá strana chápe jeden pojem různými způsoby.
22
e) Scénář případu užití - k zapisování případů užití se využívá doporučené vizuální notace, která je může být rozšířena o detailnější textový popis případu užití. „Scénář je posloupnost kroků popisujících interakce mezi uživateli a systémem“ (Flowler, 2009). Základem je hlavní scénář, který popisuje hlavní dějovou líni daného případu užití, tedy cílem je popsat sled aktivit, které daný případ užití vyvolává. Na základě hlavního scénáře jsou odvozeny alternativní scénáře. Alternativní scénář nastává v případě, že dochází k větvení aktivit, vyvolané nějakou odchylkou od hlavního scénáře. Lze je dokumentovat samostatně či připojit pod hlavní scénář. (Arlow, Neustadt, 2007)
2.7.3 Diagram tříd (Class diagram) Diagram tříd je základním diagramem jazyka UML. Představuje strukturální pohled na systém. Znázorňuje především statickou stránku systému, která odráží vztahy mezi třídami. Slouží k znázornění tříd objektů a popisuje jejich vzájemné vztahy. (Řepa, 2007) Diagram tříd využívá principů objektově orientovaného principu, kde není funkční a datová složka systému modelována zvlášť, ale je spojena v jednom objektovém modelu. Jak již bylo řečeno výše, třída je zobecněný, abstrahovaný objekt. Třídy mají společné atributy, metody a chování. Objekt získáme tak, že vytvoříme konkrétní instanci dané třídy, tedy vytvoříme její strukturální kopii a dosadíme do ní konkrétní reálné hodnoty. (Řepa, 2007) Mezi základní prvky diagramu tříd patří: a) Atributy – jsou nositelem informace v objektu, který má své jméno, formát a viditelnost. Každý atribut má určen datový typ (např.: integer, float, string, boolean, array atd.). Rozlišujeme tři druhy viditelnosti a to „public“ (úplná viditelnost), „priváte“ (viditelný pouze pro metody dané třídy) a „protected“ (viditelnost pro metody dané třídy a potomky dané třídy). b) Metody – charakterizují možnosti chování dané třídy, jedná se o množinu funkcí příslušející dané třídě. Názvy metod by měli vyznačovat reálnou funkci třídy, měl by být unikátní.
23
c) Vztahy – popisují jak vzájemné relace mezi třídami tak jejich hierarchii. Mezi základní vztahy patří: asociace – přímý vztah mezi třídami, jednosměrný či obousměrný, asociace třídy na sebe se nazývá reflexivní asociace, agregace – znázorňuje vztah, kdy jedna třída tvoří část druhé třídy (př: součástí auta je motor), kompozice – speciální případ agregace, kdy agregovaný objekt, je napevno spojen s jiným objektem, nemůže existovat samostatně bez nadřazeného objektu, generalizace/specializace – vyjadřují vztah dědičnosti, kdy jedna třída je zobecněním či specializací třídy jiné, využití má pro znovu použitelnost atributů a metod nadřazených objektů, společné části jsou zobecněny. (Arlow, Neustadt, 2007) Rozeznáváme tři úrovně modelu tříd – konceptuální, návrhová, implementační.
Konceptuální model Neboli také doménový či analytický model, je vytvořen za účelem analýzy požadavků na software. Je tvořen pouze tzv. business classes, které jsou součástí slovníku pojmů. Uvádí se pouze názvy klíčových atributů a klíčových metod. Pokud je vytvořen za účelem znázornění relací mezi třídami, je možné atributy i metody vynechat. (Arlow, Neustad, 2008)
Návrhový model Vychází z konceptuálního modelu, který rozšiřuje a zpřesňuje. K původnímu modelu jsou dodány viditelnosti atributů a metod, datové typy atd. Dále je model doplněn o třídy uživatelského rozhraní a třídy obsahující systémové události. (Buchelcevová, Pavlíčková, Pavlíček, 2007) Z jedné třídy analytického modelu se tedy může stát více tříd v návrhovém modelu.
24
Obr. 4: Porovnání vztahu analytického a návrhového modelu tříd
Implementační model Cílem implementačního modelu je věrné znázornění implementovaného kód, který se dle tohoto modelu implementuje na konkrétní platformě. (Buchelcevová, Pavlíčková, Pavlíček, 2007)
2.7.4 Diagram aktivit (Activity diagram) Je diagramem interakcí, který najde své uplatnění při popisu procedurální logiky, při popisu pracovních postupů a detailním popisu business procesů. Umožňuje graficky popsat use case diagram jako posloupnost jednotlivých aktivit. (Arlow, Neustadt, 2007) Diagram se svou funkcí podobá stavovému diagramu, ovšem je rozšířen o rozhodovací bloky, stavy jsou tvořeny aktivitami a přechody jsou iniciovány dokončením aktivit. Tento typ diagramu lze používat pří různých etapách vývoje software a to jak ve fázi analýzy tak ve fázi návrhu. Diagram aktivit modeluje procesy jako aktivity, složené s uzlů a hran. Rozlišujeme následující symboly diagramu aktivit: akční uzel – reprezentuje samostatné a nedělitelné jednotky řídící uzel – mají na starosti cestu uvnitř aktivity objektový uzel – slouží jako zástupce objektů inicializační uzel – počáteční uzel, který značí počátek posloupnosti aktivit
25
koncový uzel – značí konec posloupnosti aktivit rozhodovací uzly – umožňují větvení toku aktivit uzly sloučení – umožňuje sjednocení větví toku aktivit, které byly rozděleny rozhodovacím uzlem plavecké dráhy – neboli zóny odpovědnosti zpřehledňují toky aktivit tak, že dávají informaci o tom, jaký aktér či odpovědná osoba je spjata s danými aktivitami (Flowler, 2009);(Arlow, Neustadt, 2007)
Obr. 5: Symboly diagramu aktivit
2.7.5 Stavový diagram (State diagram) Stavový diagram zachycuje stavy objektů a Používá se pro popis chování daného objektu. jaké stavy může daný objekt nabývat, případně stavu A do stavu B. Popisuje chování jednoho (Flowler, 2009)
jednotlivé přechody mezi nimi. Ze stavového diagramu zjistíme, za jakých okolností se přesune ze objektu napříč více případy užití
Základem stavového diagramu jsou stavy, přechody a události. Je možné diagramy ohraničit rámem, který bude značit příslušnost k objektu. Diagram by měl obsahovat počáteční a koncový stav. (Arlow, Neustadt, 2007) Stav – je „situace v životě objektu, během níž objekt splňuje nějakou podmínku, provádí nějakou operaci nebo čeká na událost.“ (Rumbaugh, Jacobson, Booch, 2005)
26
Přechody – jsou podmínky, které jsou nutné pro přechod objektu z původního stavu do stavu nového. Jsou označeny linií, jež vede od jednoho objektu ke druhému. Přechod se skládá ze tří základních složek a to podmínky, události či akce. K přechodu a akci může dojít pouze tehdy, pokud je splněna definovaná podmínka přechodu. (Arlow, Neustadt, 2007) Událost – je dle Arlowa specifikací určitého výskytu něčeho v čase a prostoru. (Arlow, Neustadt, 2007) Není-li událost specifikována, dochází k automatickému přechodu do dalšího stavu.
2.7.6 Sekvenční diagram (Sequence diagram) Patří do skupiny diagramů interakcí. Sekvenční diagram zachycuje průběh zpracování v systému v podobně zasílání zpráv. (Buchelcevová, Pavlíčková, Pavlíček, 2007) Znázorňuje chování a spolupráci objektů v rámci jednoho případu užití. Struktura diagramu znázorňuje také závislost jednotlivých akcí na čase a iniciátorovi. S pomocí tohoto diagramu je možné jednoduše určit, kdo říká co a komu. Arlow tvrdí, že pro uživatele se jeví sekvenční diagram mnohem přehlednější než diagramy komunikační a lépe a dříve z něj pochopí dané komunikační vazby. Sekvenční diagram znázorňuje interakce mezi čárami života, jako posloupnost jednotlivých událostí. (Arlow, Neustadt, 2007) Diagram sekvenci se skládá z objektů, zakreslených dle zvyklostí pro zápis objektů, ze zpráv, které jsou znázorněny šipkami a času, který je určen vertikálním uspořádáním diagramu. V horní části diagramu jsou umístěny objekty, jež se zapisují z leva doprava. Od každého směrem dolů směřuje přerušovaná čára – čára života. Aktivace dané události je znázorněna podlouhlým vertikálním obdélníkem, jehož délka značí délku dané aktivace. (Schmuller, 2001) Zprávy mohou být v sekvenčním diagramu posílány jak mezi objekty tak i třídami i aktéry. Prvky, které mezi sebou komunikují, se nazývají klasifikátory (Buchelcevová, Pavlíčková, Pavlíček, 2007) Názvy zpráv by měli odpovídat názvům metod daného klasifikátor. Není třeba v tomto diagramu modelovat návratové zprávy. (Kanisová, Muller, 2006)
2.7.7 Diagram komponent (Component diagram) Znázorňuje architekturu aplikace či jiného systému pomocí komponent. Komponenty reprezentují jednotlivé moduly systému, jež mají zapouzdřený obsah a je možné je samostatně prodávat a aktualizovat. (Flowler, 2009). Komponenty mohou obsahovat atributy a metody.
27
Jednotlivé komponenty jsou zapisovány v UML 2.0 jako obdélníky se stereotypem <
> či zástupným symbolem v pravém horním rohu. (Flowler, 2009)
2.7.8 Entitně-relační diagram (Entity-relationship diagram) Entitně-relační diagram neboli ERD diagram se používá pro abstraktní a konceptuální znázornění dat. Jedná se o diagram, který slouží k podpoře datového modelování. ERD diagram je pomůcka pro zaznamenání schéma datového modelu, většinou relační databáze. Datový model se dle metodik rozděluje na logický a fyzický model.
Logický datový model Je charakterizován svou nezávislostí na implementaci, důraz je tedy kladen především na logiku datového modelu a záležitosti spjaté s konkrétním typem databáze jsou odloženy do druhé fáze datového modelování – fyzický model. U logického modelu se můžeme setkat s následujícími symboly: Entita – reprezentuje objekt určitého typu, který má své atributy (charakteristické údaje), stejné typy entit se shlukují do společných entitních tříd. Atribut – charakterizuje entitu. Představuje jednotlivé vlastnosti dané entity. Vazba – představuje vztah mezi entitami, je vyjádřena slovesem. Dalším parametrem vazby je kardinalita. Kardinalita popisuje vztah mezi výskyty záznamů svázaných entit. Kardinalita může být: 1:1, 1:N, M:N. Klíče – jedná se o významný atribut entity. Rozlišujeme primární klíče, alternativní klíče a cizí klíče. Klíče slouží k jednoznačné identifikaci záznamu či jako zástupný symbol pro propojení více entit. (Kanisová, Muller, 2006)
Fyzický model Fyzický model již zohledňuje daný typ zvolené relační databáze. Zde se můžeme setkat s následujícími symboly:
28
Databáze – organizovaná struktura dat, je uspořádaná do tabulek. Tabulka – datová struktura organizovaná do řádků a sloupců. Z matematického
hlediska
se
jedná
o
dvourozměrnou
matici
s pojmenovanými sloupci a řádky, kde jsou uložena data. Řádek – informace o jednom výskytu entity v databázi. Sloupec – představuje druh atomické informace. (Kanisová, Muller, 2006)
2.8 CASE nástroje CASE (Computer Aided Software Engineering) nástroje jsou nástroje pro podporu vývoje softwarových aplikací. Cílem CASE nástrojů je tedy ulehčit tvorbu softwarových produktů pomocí komplexních nástrojů pro správu vývojového projektu. CASE nástroj umožňuje tvorbu diagramů a jejich textových popisů. Jednou z nejdůležitějších vlastností CASE nástroje je zajištění souvislostí, které člověk není schopen mentálně pojmout. Použití těchto nástrojů nám ovšem nezajistí bezchybný a rychlý vývoj. Jedná se pouze o podpůrný nástroj, jehož využití je dáno stanovenou metodikou vývojového projektu, využitím odborníků na jednotlivé oblasti vývoje, správným použitím a vyhodnocení metrik atd. (Procházka, 2004)
2.8.1 Druhy CASE nástrojů Existuje mnoho CASE nástrojů. Je to dáno nejen existencí mnoha metodik, ale také fází vývoje, ve které je nástroj používán. Je možné jej využít ve fázích specifikace požadavků, analýzy, návrhu, kódování a údržby. (Procházka, 2004) Podle životního cyklu vývoje software dělíme tyto nástroje na: Pre CASE – podpůrný nástroj pro tvorbu globální strategie. Upper CASE – podpora plánování, specifikace požadavků, model organizace. Hlavním cílem tohoto typu je analýza organizace, jejich procesů, informačních toků a tvorba dokumentace. Middle CASE – obsahují podrobnou správu požadavků a nástroje pro návrh systému. Zajišťují specifikaci požadavků, návrh systému, dokumentaci, znázornění procesů a modelování databázových
29
systému. Jedná se o nejčastější typ CASE nástroje, který obsahuje komplexní návrhové pomůcky a je součástí většiny komerčních CASE produktů. Lower CASE – podporují principy reverzního obsahují
nástroje
pro
generování
kódu,
inženýrství, tedy
testování
či
správu
konfigurace atd. Post CASE – podporuje zavádění, údržbu a rozvoj IS. (Procházka, 2004)
Obr. 6: Rozčlenění CASE nástrojů dle životního cyklu vývoje software, zdroj: (Procházka, 2004)
2.8.2 Enterprise Architect CASE nástroj vyvinutý firmou Sparx Systems. Jedná se o komplexní nástroj umožňující plnou správu softwarového projektu. Podporuje nejnovější standardy UML, tvorbu dokumentace v různých formátech i nástroje reverzního inženýrství. Nabízí také prostředky k procesnímu modelování dle přístupu ErikssonPenkerovi metody. Produkt je vyvinut jak pro Windows tak Linux platformy. Je
30
možné využít moduly pro integraci CASE nástroje do různých IDE ve formě pluginů. Dále nabízí krom možností modelovat business procesy také modelování datové základny. Obsahuje nástroje pro podporu týmové práce prostřednictvím různých možností sdílení projektů.
2.8.3 Visual Paradigm for UML Komplexní a silný CASE nástroj, vyvíjen firmou Visual Paradigm se sídlem v Hon-kongu. Nástroj je možné spustit na všech předních operačních systémech (Windows, Linux, Mac OS). Obsahuje nástroje pro modelování v jazyce UML, podporuje procesní modelování, diagramy pro tvorbu požadavků, databázové modelování či také nástroje pro návrh uživatelského rozhraní. Dále je jeho součástí nástroj pro analýzu textu při hledání požadavků. Ovládání tohoto CASE nástroje je na rozdíl od Enterprise Architect velice intuitivní a uživatelsky přívětivější. Při modelování nabízí užitečné pomůcky, jako jsou pomocné linky, které usnadňují zarovnání prvků diagramů. Rychlá volba akce při kliknutí na prvek diagramu. Nevýhodou je absence ucelenější podpory modelování dle Eriksson-penkerovi notace.
2.9 Implementační technologie 2.9.1 Jazyk PHP PHP je skriptovací programovací jazyk určený pro programování dynamických webových stránek. PHP je vykonáván na straně serveru a vkládán do běžného HTML kódu. Každou stránku s PHP skripty server nejprve přečte, pak vykoná všechny příkazy v PHP, které se na dané stránce nachází, následně odešle ke klientovi čistý HTML kód, jež je vytvořen na základě instrukcí v PHP kódu. Jazyk PHP se stal oblíbený hlavně skrz svoji jednoduchost použití. Kombinuje vlastnosti několika programovacích jazyků. Vývojář má jistou volnost během programování, jelikož je jazyk v syntaxi značně benevolentní. Tento jazyk je často využit pro tvorbu webových aplikací v kombinaci s operačním systémem Linux, databázovým systémem (MySQL či PostgreSQL) a serverem Apache. Pro tuto kombinaci vznikla zkratka LAMP – spojení Linux, Apache, MySQL a PHP či Perl. Poslední verze PHP 5.3.x již podporuje objektově orientované programování. Tuto verzi dnes již poskytuje téměř každý poskytovatel webhostingu.
31
2.9.2 MySQL MySQL (My Structured Query Language) je relační databáze typu DBMS (database managment systém) a vychází z dotazovacího jazyka SQL (Structured Query Language). Databáze je šířena jako Open Source. Jedná se o nejrozšířenější databázový systém, který podporuje téměř každý hostingový poskytovatel. Pro správu tohoto databázového systému se nejčastěji používá webové rozhraní na bázi PHP a to PhpMyAdmin.
2.9.3 XHTML XHTML (Extensible Hypertext Markup Language) je druh značkovacího jazyka pro tvorbu hypertextových dokumentů v prostředí WWW, jež byl vyvinutý organizací W3C. Mělo jít o náhradu jazyka HTML, který dospěl do finální verze 4.01 a již se dál nevyvíjel. Ovšem nyní jsou veškeré snahy ve vývoji značkovacích jazyků pro web směřovány k technologii HTML 5 a její XML variantě. (Wikipedia HTML, 2012)
2.9.4 CSS CSS (Cascading Style Sheets) je jazyk pro formátování dokumentů napsaných v jazycích HTML, XHTML či XML. Byl vyvinut organizací W3C. V současné době existují specifikace CSS1, CSS2 a již se pracuje na nové verzi CSS3. Cílem CSS je oddělit při návrhu i implementaci vzhled dokumentu od struktury a obsahu. (Wikipedie – CSS, 2012)
2.9.5 Nette framework Jedná se o open source framework pro programovací jazyk PHP, který značně usnadňuje vývoj webových aplikací prostřednictvím předpřipraveného vývojového prostředí a mnoha knihoven. Zaměřuje se na minimalizování bezpečnostních rizik. Poslední verze využívá předností PHP 5.3.x. Je založen na modelu MVC. MVC (model-view-controller) je softwarová architektura využívající objektového mpřístupu. Rozděluje datový model, uživatelské rozhraní a aplikační logiku. Každá tato část je zpracovávána odděleně, každá část tvoří samostatnou komponentu, jejíž změna má minimální vliv na komponenty ostatní. Obecný princip činnosti aplikace v architektuře MVC je následující: 1. Uživatel provede akci v uživatelském rozhraní.
32
2. Controller obdrží oznámení o této akci z objektu uživatelského rozhraní. 3. Controller přistoupí dle potřeby k vrstvě model a zaktualizuje jeho obsah prostřednictvím konkrétní funkce pro danou akci. 4. Model zpracuje změněná data na základě podnětu od controlleru. 5. View přímo přistupuje k vrstvě model a žádá si konkrétní data. Model je ovšem na vrstvě view nezávislý. Controller může poslat příkaz vrstvě view, aby zaktualizovala svůj obsah pomocí vrstvy model. Nette umožňuje rychlou tvorbu webových aplikací, díky tomu, že má již plno akcí předpřipravených. Dbá zejména na bezpečnost vytvářené aplikace. Využívá technologie, které eliminují výskyt bezpečnostních děr. Chrání aplikaci před útoky jako XSS (cross side scripting), cross-site request forgery (CSRF), URL attack, invalid UTF-8, session hijacking, session stealing, session fixation atd. Většina ochrany před těmito útoky probíhá automaticky. Pro vrstvu pohledu nabízí vlastní šablonovací systém Latte.
33
3 METODIKA Cílům, které byly stanoveny na počátku práce, bude věnována část s názvem Vlastní práce. Hlavním cílem byla stanovena analýza procesů v daném podniku a návrh na její optimalizaci. Dílčím cílem byla implementace daného návrhu pro prostředí sledovaného podniku. Podnik, který bude v této práci zmiňován pouze jako „sledovaný podnik“ si nepřál, aby byl v této práci uveden jeho název. Podnik poskytnul pro tuto práci veškerý potřebný materiál. V první části bude tedy popsán zkoumaný podnik. Bude naznačena jeho vnitřní struktura, popsán jeho cíl podnikání a zaměření poskytovaných služeb. Tyto údaje budou sloužit jako vstup pro navazující části této práce. Ze zjištěných informací o sledovaném podniku bude provedena analýza procesů v tomto podniku. Budou identifikovány základní procesy, které budou dekomponovány a určeny jejich vstupy a výstupy. Z identifikovaných procesů bude vytvořen Business Process Model jenž bude pro názornost zapsán pomocí UML konkrétně pomocí Eriksson-Penkerovi notace, která pracuje s koncepty – proces, zdroj, cíl a pravidlo. Pro vytváření diagramů Business Process Modelu bude využito CASE nástroje Enterprise Architect. Ostatní diagramy budou modelovány v CASE nástroji Visual Paradigm for UML. Provedená procesní analýza bude představena managementu firmy. Na základě společného dialogu bude nalezen vhodný proces k inovaci. Inovace bude směřována na oblast řízení vztahů se zákazníky. Po určení vhodného procesu k inovaci bude vytvořen návrh na optimalizaci tohoto procesu prostřednictvím vhodné webové aplikace na bázi PHP a MySQL. Vytvoření návrhu aplikace započne stanovením funkčních a nefunkčních požadavků na nový systém. Bude vytvořen Use Case model, který bude specifikovat požadovanou funkčnost systému a identifikuje aktéry daného systému. Pro popis statické části systému a identifikování jednotlivých objektů bude použit diagram tříd. Pro popis dynamické části systému bude využito i jiných diagramů jazyka UML jako diagramu aktivit, či sekvenčního diagramu. Z důvodů použití relačního databázového systému MySQL bude z modelu tříd vytvořen entitně-relační diagram.
34
V další a poslední části práce bude zvolená inovace implementována prostřednictvím technologií PHP, HTML, CSS, AJAX a Nette framework, databázová část aplikace bude založena na databázovém systému MySQL.
35
4 VLASTNÍ PRÁCE 4.1 Základní informace o sledovaném podniku Podnik vznikl 19. 5. 2006. Jedná se o malý podnik, který zaměstnává 7 zaměstnanců na hlavní pracovní poměr. Pro potřeby některých procesů najímá brigádníky. Má zatím pouze jednu pobočku. Hlavním cílem podniku je zprostředkování skupinových slev pro služby a poradenství v oblasti optimalizace nákladů za různé služby pro domácnosti. Mezi zprostředkovávané služby patří zejména služby mobilních operátorů, pojištění automobilů a energie. V oblasti pojištění automobilů se věnuje jak zprostředkování havarijního pojištění, tak povinného ručení a všech souvisejících produktů. V současné době má nejvíce zákazníků v oblasti služeb mobilních operátorů, nabízí výhodné tarify mobilních operátorů na základě skupinových slev na tarify. V poslední době se začíná také více věnovat zprostředkování výhodných tarifů pro energie do domácnosti, konkrétně se jedná o plyn a elektřinu, kde deklaruje, že je schopný nabízet dané zvýhodnění až 50% oproti průměrným cenám. Podnik vyjednává skupinové zvýhodnění u daných poskytovatelů, kteří prostřednictvím něho získávají nové zákazníky. Jedná se o ojedinělé nabídky poskytovatelů přímo na míru pro tento podnik. Sledovaný podnik se snaží shánět slevy ve všech možných oblastech služeb, snaží se zákazníkům garantovat, že za ně vybere toho nejvhodnějšího a nejspolehlivějšího poskytovatele v dané oblasti služeb. Pro své zákazníky nabízí věrnostní program, který jim za předpokladu, že zákazník bude využívat některých dlouhodobějších služeb, umožní sbírat zelené body, které se dají zpětně využít na další získání slev u smluvních partnerů sledovaného podniku. V oblasti marketingu podnik preferuje přímý marketing a využívá metod telemarketingu. Snaží se vytvořit komunitu, před poskytovatelem vystupuje jako velká skupina zákazníků. Své vyjednané slevy nešíří prostřednictvím veřejných médií, ale dává přednost šíření informací o sobě a svých službách prostřednictvím referencí spokojených zákazníků, na doporučení. Tento systém prodeje je odrazem smluv s poskytovateli zprostředkovaných služeb. Ve svém podnikání se snaží částečně využívat principů multilevel marketingu, ovšem nestaví zcela na tomto systému. Tento systém se týká především motivace u věrnostního programu.
36
4.2 Současný stav a motivace podniku Sledovaný podnik v současné době nevyužívá příliš možností moderních softwarových řešení pro zefektivnění činností svého podnikání. V podniku není integrovaný informační systém. Část podnikových činností je prováděna prostřednictvím webových aplikací. Do doby, před nasazením webových aplikací, veškerá činnost podniku stála na kancelářském software. Dnes se již podnik snaží více investovat do rozvoje své softwarové infrastruktury a management si uvědomuje nutnost integrace jednotlivých softwarových komponent do jednoho funkčního a efektivně spolupracujícího celku. V současné době je autor práce zaměstnáván touto společností a jeho současným úkolem je vylepšit současnou informační strategie podniku, která by měla vést k integraci procesů.
4.3 Analýza podnikových procesů K tomu, aby bylo možné navrhnout a realizovat jakoukoliv procesní inovaci, v kterémkoliv systému, je třeba nejdříve daný systém dokonale poznat. Pro poznání souvislostí v podniku bude provedena procesní analýza, na základě které vzniknou konkrétní modely, jež budou popisovat procesy ve sledovaném podniku. Je potřeba určit hlavní a podpůrné procesy, které budou dále dekomponovány na jednotlivé subprocesy. Výsledkem analýzy podnikových procesů bude abstraktní model podnikové architektury z procesního pohledu.
4.3.1 Základní pohled na podnikové procesy Ve sledovaném podniku bylo identifikováno pět základních procesů, které tvoří kostru činností podniku týkajících se hlavního cíle podnikání, kterým je zisk. Jsou jimi: -
správa objednávek,
-
aktivace služeb
-
technická podpora
-
dotazníkový výzkum
-
cílená nabídka služeb
37
Výše uvedené procesy jsou hlavními složkami struktury podnikových procesů s ohledem na strategii řízení sledovaného podniku. Podnik vykonává především těchto pět procesů, ke kterým by bylo možné ještě přidat proces vedení účetnictví, který je ovšem zajištěn externím dodavatelem a proces personální agendy, tedy správy zaměstnanců, jejíž průběh je vzhledem k počtu stálých zaměstnanců spíše ojedinělý. Mezi pilíře identifikovaných procesů patří správa objednávek. Tento proces jako jediný přináší zisk. Proces je spuštěn objednáním služeb, objednaná služba je evidována jako přijatá objednávka, která se dále zpracovává. Objedná-li si potencionální zákazník služby je zároveň zaregistrován do systému. Cílem tohoto procesů je uspokojení potřeb zákazníka. Proces je ukončen aktivací objednávky a následným čerpáním služeb. Slouží k vytvoření, správě a evidenci stavů objednávek. Podpůrným procesem správy objednávek je proces aktivace služeb. Má na starosti vyjednání výhodných produktů a podmínek od poskytovatelů a následné zprostředkovávání těchto služeb, s kterým souvisí pomoc při přerušení stávajících služeb zákazníka, pokud již takové odebírá od jiného poskytovatele. Cílem tohoto procesu je vyjednání co nejvýhodnějších podmínek pro poskytovatelem nabízené služby, případně získání speciálních služeb od poskytovatelů pro zákazníky sledovaného podniku. Dalším důležitým cílem je minimalizace doby aktivace služby zákazníkovi a případně tedy i minimalizace doby přenosu služeb mezi poskytovateli. Na objednané služby potažmo registrované zákazníky je navázán proces technické podpory neboli také proces správy požadavků. Proces má na starosti sběr a řešení požadavků registrovaných zákazníků. Cílem je uspokojení požadavků zákazníků v adekvátním časovém úseku. Jedná se o podpůrný proces, ovšem určitě ne zanedbatelný, jelikož souvisí se spokojeností stávajících zákazníků se službami a se schopností podniku vyhovět jejich požadavkům. Hlavní proces správy objednávek je přímo podpořen cílenou nabídkou služeb ze strany podniku. Jedná se o telefonní nabídku služeb na základě zvolených kritérii. Proces má za cíl přilákání nových zákazníků a vytvoření nových objednávek. Proces je v současné době směřován pouze na nové kontakty, tedy je směřován pouze na získávání nových zákazníků. Nepracuje se zákazníky stávajícími. Výstupem procesu je v nejlepším případě požadavek na objednání služby, ve většině případů se ovšem počítá s domluvením osobní schůzky a s následnou přímou osobní nabídkou služeb.
38
Proces cílené nabídky služeb pracuje na základě dat získaných v jeho podpůrném procesu dotazníkového výzkumu. Cílem dotazníkového výzkumu je získání relevantních informací o stávajících službách zkoumaných kontaktů. Kontakty jsou většinou, ale ne jen, náhodná telefonní čísla získaná na základě dodávky externí firmy. Proces shromažďuje data odpovědí na dané otázky daného výzkumu, které slouží jako vstup do procesu cílené nabídky služeb. Stejně tak jako proces cílené nabídky i proces dotazníkového výzkumu není ještě zaměřen na stávající zákazníky.
39
Obr. 7: Procesní model - základní pohled na procesy v podniku
40
4.3.2 Správa objednávek Je hlavním procesem, který vytváří zisk a uspokojuje potřeby zákazníků. Proces začíná událostí objednání služby, kterou vyvolává zákazník. Objednat služby je možné osobně, prostřednictvím e-mailu, či telefonu. Na základě objednávky proběhne proces přijetí objednávky. Cílem procesu je přijetí objednávky a její co nejrychlejší zavedení do systému. Výstupem tohoto procesu jsou zdroje údaje o zákazníkovi a přijatá objednávka. Vlastníkem tohoto procesu je obchodník. Po procesu přijetí objednávky následuje proces registrace zákazníka. Tento proces zaeviduje všechny dostupné informace o zákazníkovi, který vytvořil objednávku. Vstupem jsou tedy údaje o zákazníkovi a na základě těchto údajů vzniká objekt registrovaný zákazník a paralelně s ním je také pro daného zákazníka založen účet věrnostního programu pro registrované zákazníky podniku. Tím je proces registrace ukončen. O průběh procesu registrace se stará obchodník. Následuje proces zpracování objednávky. Do tohoto procesu zasahují dva aktéři a to obchodník a fakturant. Vstupem procesu je přijatá objednávka, na základě které je formulován požadavek na objednání služby u poskytovatele, který je předán do procesu aktivace služby (viz níže) prostřednictvím zpracované objednávky. Podnik nabízí určité balíčky služeb svým jménem, ovšem v dialogu s poskytovateli používá jiný slovník a jiné nastavení služeb než prezentuje marketing sledovaného podniku. Jedná se o interní reformulaci objednávky do tvaru, který vychází ze smluv s poskytovateli. Současně je také vystavena zákazníkovi faktura fakturantem. Posledním procesem je proces aktivace objednávky. Vlastníkem objednávky je opět obchodník. Vstupem je objednaná služba a řádně vytvořená smlouva. Než nastane tento proces je možné od smlouvy odstoupit. Proces aktivace se sestává z kontroly všech vstupujících náležitostí nutných pro aktivaci služby a tou je potvrzení objednání služby v daném rozsahu u poskytovatele (interní zpráva) a sepsaná smlouva se zákazníkem. Pokud jsou tyto náležitosti splněny, je objednávka aktivní a zákazník může využívat služby. Výstupem je tedy vyřízená objednávka.
41
Obr. 8: Procesní model - správa objednávky
4.3.3 Aktivace služeb Proces aktivace služeb má na starosti dialog s poskytovateli služeb a zajištění služby v objednaném rozsahu u poskytovatele. Pokud je předmětem zpracované objednávky služba, která navazuje na již existující službu a je nutné pro aktivaci služby ji vypovědět u stávajícího poskytovatele, je prvním krokem proces výpovědi stávajících služeb. Cílem tohoto procesu je především rychlost, jelikož čím rychleji je předchozí služba vypovězena, tím dříve může být odebírána služba u nového poskytovatele. Vlastníky tohoto procesu jsou správce aktivací služeb a stávající poskytovatel, kteří během tohoto procesu vedou dialog. Vstupem procesu jsou aktivní služby u stávajícího poskytovatele a plná moc, týkající se přenosu práv se zákazníka na správce aktivací služeb pro možnost správce zastupovat zákazníka při výpovědi smlouvy. Dalším důležitým vstupem je výpovědní lhůta. Výsledkem tohoto
42
procesu je nakonec vypovězená smlouva s dosavadním poskytovatelem. Současně je výstupem datum, kdy služby budou u stávajícího poskytovatel přerušeny. V době, kdy již je známo datum výpovědi služeb u stávajícího poskytovatele, je spuštěn proces přenosu nových služeb. Cílem procesu je dialog s novým poskytovatelem služby a správcem aktivací služeb. Tyto subjekty jsou vlastníky procesu. Vstupem jsou zpracovaná objednávka z procesu zpracování objednávky a datum vypovězení služeb z procesu výpovědi stávajících služeb. V procesu je domluven s novým poskytovatelem datum spuštění služby. U některých služeb je nutné minimalizovat dobu přerušení služeb v době přenosu od jednoho poskytovatele k druhému, synchronizaci těchto činností má na starosti právě tento proces. Procesu se zúčastní balík vyjednaných služeb u poskytovatelů, z kterého je objednána služba na základě zpracované objednávky. Výsledkem tohoto procesu je objednaná služba u nového poskytovatele. Proces přenosu nových služeb je ovlivněn procesem vyjednání služeb, který může probíhat i paralelně s ním a také sám ovlivňuje svým výstupem proces základního nastavení služeb. Proces vyjednání služeb je procesem, který zasahuje do obchodních možností podniku. Jelikož schopnost podniku vyjednat výhodné podmínky pro své zákazníky je stěžejní. Vyjednané výhodné podmínky služeb jsou konkurenční výhodou, na které může dále stavět marketing podniku. Cílem tohoto procesu je tedy vyjednání co nejvýhodnějších cenových i jiných podmínek pro zprostředkované služby. Vstupem procesu je tedy portfolio nabízených služeb od různých poskytovatelů a podmínky jednotlivých poskytovatelů. Portfolio služeb je transformováno v procesu vyjednávání do tvaru vyjednaných služeb, které tvoří výstup tohoto procesu. Vyjednané služby jsou už dále předmětem procesu přenosu nových služeb. Důležitým výstupem procesu je smlouva s poskytovatelem na zprostředkovávání jím nabízených služeb za stanovených podmínek. Vlastníky tohoto procesu je poskytovatel a správce aktivací služeb. Po procesu přenosu nových služeb dochází k procesu základního nastavení služeb. Vstupem procesu je objednaná služba procesem přenosu nových služeb, požadavky zákazníka na prvotní nastavení služeb a také informace v podobě omezení hranic nastavení. Výstupem tohoto procesu je nastavená služba. Proces nastavení má na starosti obchodník, který využívá informací ze zpracované objednávky.
43
Obr. 9: Procesní model - aktivace služby
4.3.4 Technická podpora Technická podpora je proces pro registrované zákazníky, tedy pro zákazníky, kteří využívají, některou z nabízených služeb. Cílem technické podpory je plnění požadavků týkajících se přenosu služeb, jejich průběhu či jejich ukončování. Technická podpora zajišťuje vyřizování také vnitřních provozních požadavků podniku. Slouží jako fórum požadavků, kde na jedné straně do fóra vstupuje registrovaný zákazník a na straně druhé technické požadavky podniku. Prvním procesem je tedy vytvoření požadavku. Vstupem je požadavek, každý požadavek je přiřazen, některé oblasti služeb. Dalším informačním faktorem, který bere proces v potaz, jsou okolnosti vytvoření požadavku, může se jednat například o různé dočasné okolnosti v podniku, které můžou mít vliv na proces vytvoření požadavku či o různé směrnice podniku, při vyřizování požadavků určitých typů. Cílem je také co nejpřesnější formulace zpracovávaného požadavku, tak aby byl srozumitelný a vystihoval daný problém. Vstupem procesu se zúčastní registrovaný zákazník a vlastníkem procesu je pracovník
44
technické podpory. Výstupem je evidovaný a řádně formulovaný požadavek, který je postoupen k dalšímu zpracování. Následuje proces klasifikace požadavku. Proces je zaměřen na zatřídění požadavku do určité kategorie, ohodnocení požadavku prioritou a určení maximální doby pro řešení požadavku. Procesu se účastní způsob klasifikace, který vychází z vnitropodnikových směrnic. Výstupem je zatříděný požadavek. Vlastníkem procesu je pracovník technické podpory. Následuje hlavní proces řešení požadavků, který naplňuje hlavní smysl technické podpory. Jeho cílem je uspokojení požadavku neboli nalezení adekvátní odpovědi, či provedení adekvátní činnosti, která vyhoví danému požadavku. Hlavním vstupem procesu je zatříděný požadavek, který vychází z procesu klasifikace požadavků. Procesu se účastní informační zdroj okolnosti požadavku (viz výše) a registrovaný zákazník. Výstupy procesu jsou dva a to v prvé řadě průběžný výstup stav řešení požadavku, který odráží všechny stavy, které nastanou během řešení požadavku. Druhým výstupem je vyřízený požadavek. Vlastníkem tohoto procesu je pracovník technické podpory.
Obr. 10: Procesní model - technická podpora
45
4.3.5 Dotazníkový výzkum Je proces, který umožňuje podniku zjistit podstatné informace přímo od uživatelů daných služeb. Dotazníkový výzkum probíhá prostřednictvím telefonního rozhovoru, kde se telefonista ptá zkoumaného na otázky z předem sestaveného dotazníku. Podnik tento proces v současné době využívá k získávání informací, aby mohl následně tyto informace využít v procesu cílené nabídky (viz níže). Tento proces vytváří podklady pro zefektivnění nabídky služeb. V první fázi dochází k procesu vytvoření výzkumu. Na základě marketingové strategie je zvolen druh výzkumu a jsou vytvořeny pro daný výzkum relevantní dotazníkové otázky, na které budou respondenti odpovídat. Dále je vybrán soubor objektů, které budou zkoumány. Cílem procesu je vytvoření relevantního výzkumu, na jehož konci budou získána data, která umožní podniku lépe zmapovat cílovou skupinu potencionálních zákazníků a efektivněji jim pak nabízet svoje služby. Vstupem procesu jsou surové telefonní kontakty, získané z větší části od externího dodavatele. Výzkumy jsou vždy prováděny pro nějakou konkrétní oblast služeb. Informačním zdrojem je marketingová strategie, které ovlivňuje průběh procesu. Vlastníci procesu jsou dva a to telefonista, který je určen druhým vlastníkem procesu a to správcem výzkumu. Každému výzkumu je přiřazen telefonista, který bude zkoumat příslušnou oblast služeb. Správce výzkumu je zodpovědný za koordinaci vytváření výzkumu. Výstupem procesu je soubor kontaktů, které se stanou vstupem následujícího procesu a dotazníkové otázky, které jsou sestaveny pro daný výzkum. Jakmile je znám druh výzkumu, způsob výzkumu, dotazníkové otázky a je vybrán zkoumaný soubor kontaktů dochází k procesu telefonátu vybranému kontaktu. V tomto procesu telefonista kontaktuje zkoumaný kontakt, který společně s dotazníkovými otázkami tvoří hlavní vstupy procesu. Cílem procesu je navázání spojení se zkoumaným kontaktem a získání relevantních informací pro výzkum. Hovor je veden dle vnitřních pravidel pro hovor vedený při výzkumu. Vlastníkem procesu je telefonista, který řídí průběh hovoru. Výstupem tohoto procesu je pokus o volání. Pokud během hovoru telefonista získá požadované informace na základě dotazníkových otázek, jsou výstupem právě tyto nové informace, pokud požadované informace nezíská je výstupem vyřazený kontakt z daného výzkumu. S procesem telefonátu vybranému kontaktu je úzce spjat proces vyplňování dotazníku. Cílem tohoto procesu je využít získané informace k vyplnění připraveného dotazníkového formuláře. Vstupem tohoto procesu jsou tedy získané informace během hovoru, zkoumaný kontakt a dotazníkový formulář.
46
Výstup tvoří vyplněný dotazník. Úspěšnost vyplňování dotazníků je směrodatná pro ohodnocení telefonisty, jsou tedy vedeny statistky vyplněných dotazníků, které tvoří další výstup. Vlastníkem procesu je opět telefonista. Cílem procesu je bezchybnost při vyplňování údajů a dodržení pravidel při vyplňování formuláře. V dalším procesu je zpracován vyplněný dotazník, který tvoří jeho vstup. Jedná se o proces vyhodnocení výsledků výzkumu. Vyhodnocení výzkumu má na starosti správce výzkumu, který je jeho jediným vlastníkem. Cílem vyhodnocení výsledků výzkumu je kategorizace výsledků a využití výsledků při tvorbě marketingové strategie. Výstupy jsou tedy dva a to marketingová strategie a podklady pro cílenou nabídku služeb.
Obr. 11: Procesní model - dotazníkový výzkum
4.3.6 Cílená nabídka služeb Proces cílené nabídky služeb je stěžejní prostředek podniku, kterým je uplatňován přímý marketing a to konkrétně formou telemarketingu. Kdy daný obchodník volá předem určenému segmentu kontaktů s cílem mu nabídnout výhodnější služby. Ve sledovaném podniku tento proces diferencuje skupiny zákazníků dle
47
dat získaných v dotazníkovém výzkumu. Kontaktuje dříve zkoumané kontakty, u kterých byla zaznamenána pozitivní spolupráce na výzkumu a již připraven jim nabízí adekvátní služby. Hlavním procesem této oblasti je cílená telefonní nabídka služeb. Jedná se o činnost, která v sobě skrývá telefonát s vybraným kontaktem. Hlavním zúčastněným vstupem tohoto procesu je tedy telefonní kontakt a hned poté vyplněný dotazník, který slouží jako odrazový můstek vedeného hovoru. Cílem procesu je podnícení vzniku nové objednávky, k čemuž přispívá také vhodně zvolená nabídka služeb. Dalším zúčastněným vstupem jsou optimalizované služby, tedy služby vyjednané u poskytovatelů. Důležitým katalyzátorem tohoto procesu jsou také stejně jako v dotazníkovém výzkumu vnitřní pravidla pro vedení hovoru s potencionálním zákazníkem. Vlastníkem procesu je obchodník. Výstup každého provedení tohoto procesu je pokus o volání. Další výstupy jsou závislé na výsledku vedeného hovoru a nabídky. Pokud má daný kontakt zájem o nabízené služby, je celý proces směřován k dalšímu procesu a to procesu osobní schůzky (viz níže). K tomu, aby mohlo dojít k přesměrování k tomuto procesu, je nutné se shodnout s potencionálním zákazníkem na datu a místu osobní schůzky, což je tedy onen výstup procesu cílené telefonní nabídky služeb v případě, že má kontakt zájem o nabízené služby a chce vědět více, případně osobně provést objednávku. V případě, že kontakt chce přímo po telefonu objednat nabízenou službu je výstupem procesu požadavek na objednání služby. A nakonec je tu třetí možnost výsledku hovoru a to, že daný kontakt nemá zájem o služby. Tím pádem je výstupem procesu vyřazený kontakt pro danou oblast služeb. Celý proces je ovlivněn marketingovou strategii podniku. S předchozím procesem souvisí další proces a to proces úpravy dotazníkových údajů. Cílem tohoto procesu je aktualizovat odpovědi na dotazníkové otázky volaného kontaktu. Během hovoru je využito pozornosti a předchozí pozitivní spolupráce daného kontaktu pro doplnění údajů, které se mohli od doby výzkumu změnit. Vstupem procesu je tedy telefonní kontakt a vyplněný dotazník, který bude transformován, upraven. Dalším vstupem jsou aktualizované odpovědi na dané dotazníkové otázky. Výstupem procesu je aktualizované dotazník. Vlastníkem procesu je opět obchodník. Na pozitivní výstup procesu cílené telefonní nabídky služeb navazuje proces osobní schůzka. Jedná se o osobní setkání obchodníka a potencionálního zákazníka. Cílem procesu je osobní prezentace nabízených služeb a vytvoření nové objednávky. Vstupem je telefonní kontakt a datum a místo schůzky. Vlastníky
48
procesu jsou obchodník a potencionální zákazník. Výstup je určen zájmem o služby potenciálního zákazníka. Pokud má potencionální zákazník zájem o služby je výstupem požadavek na objednání služby. Pokud ovšem nabízené služby nechce je výstupem vyřazený kontakt pro nabízenou oblast služeb.
Obr. 12: Procesní model - cílená nabídka služeb
4.4 Současná softwarová podpora procesů v podniku Sledovaný podnik má v současné době pro podporu svých procesů pouze základní softwarovou výbavu především na bázi kancelářského software. Nedisponuje žádným integrovaným informačním systémem, který by jeho procesy řídil centrálně. Některé procesy jsou podporovány rozhraním na bázi souborů v programu MS Excel. Hlavní podnikový proces správa objednávek nemá softwarovou podporu. Veškeré objednávky a vyřizování objednávek probíhá papírovou formou. Veškerý průběh tohoto procesu je tedy pouze na bázi základních dokumentů a převážně osobního kontaktu se zákazníkem, s kterým se přímo v případě zájmu o službu
49
osobně vyplňují. Podnik tedy eviduje novou objednávku prostřednictvím podpisu smlouvy o využívání dané služby a vyplněním registračního formuláře pro danou službu. V procesu aktivace služby u poskytovatele již probíhá první evidence zákazníků. Evidence základních dat o zákazníkovi, objednané službě a náležitostí pro aktivaci služby probíhá prostřednictvím programu MS Excel. Dokud probíhá tento proces zákazník je evidován v souboru mající na starosti aktivaci služby. Jakmile je proces aktivace služby dokončen a služba je aktivní, je zákazník zaevidován do hlavního programového souboru, v kterém jsou kompletní údaje o všech zákaznících, jejich službách a nastavení jejich služeb. Proces technické podpory byl původně na bázi společné emailové schránky, na kterou se posílaly emaily s dotazy od zákazníků. Podnik již ovšem dva roky používá pro správu požadavků webovou aplikaci, která je vytvořena přímo na míru. Aplikace je ve stylu diskusního fóra, které bere v potaz specifika daných služeb. Aplikace víceméně zatím dostačuje podnikovým požadavkům, ovšem její nevýhodou je, že se jedná o samostatný systém, který komunikuje s ostatními komponenty podnikového systému těžkopádně. Proces dotazníkových výzkumů je částečně zajištěn webovou aplikací. Aplikace se sestává s online dotazníku, který je pevně stanoven a pouze sbírá data pro jeden typ dotazníku. Tyto data jsou dále opět zpracována v programu MS Excel. Systém je zaměřen pouze na jednu oblast služeb. Webová aplikace neobsahuje správu uživatelů. Část výzkumu je stále prováděna pomocí dotazníkového souboru v MS Excel. V době, kdy podnik rozšířil portfolio nabízených služeb a žádá sofistikovanější správu tohoto procesu, již přestala její funkčnost dostačovat. S dotazníkovým výzkumem souvisí také proces cílené nabídky služeb. Stejně jako u dotazníkového výzkumu podnik využívá webové aplikace. Vstupy pro tuto aplikaci jsou upravené CSV s daty exportovanými z dotazníkového výzkumu. Aplikace pro podporu cílené nabídky služeb nabízí obchodníkům základní filtrování dle kritérií dotazníkového výzkumu a možnost tak pracovat pouze s vybranými typy kontaktů. Systém eviduje domluvené schůzky a odmítnuté kontakty. Exportuje data do CSV. Opět je systém zaměřený pouze na konkrétní oblast služeb a nevyhovuje mimo jiné i rozšířenému portfoliu služeb podniku.
50
4.5 Inovace procesu dotazníkového výzkumu Jak již bylo naznačeno v předchozí kapitole, podnik nemá implementován žádný jednotný informační systém, využívá kancelářského software a částečně si své procesy ulehčuje prostřednictvím webových aplikací. Přestože se jedná o drobný podnik, vhodně sestavený software by ulehčil znatelně práci administrativě podniku, zrychlil procesy v podniku a eliminoval by chyby způsobené nesourodostí jednotlivých komponent současného systému. Současný způsob práce a využití software je neefektivní a mnoho procesů je prováděno s chybami, jejichž opravování souvisí se ztrátou cenného času. Nepřesnosti v evidovaných datech vedou k nepřehlednosti systému. Cílem podniku by tedy měla být podpora jednotlivých procesů za pomoci výpočetní techniky prostřednictvím vhodně sestaveného informačního systému. Sestavení informačního systému je ovšem otázkou financí a ochoty podniku investovat. Jak již bylo zmíněno výše cílem práce je, krom analýzy podnikových procesů, právě inovace vybraných procesů, které budou mít vzhledem k situaci v podniku největší přínos pro zefektivnění chodu podniku jako celku. Výběr daných procesů k inovaci byl konzultován s managementem firmy na základě vytvořené procesní analýzy, která byla součástí této práce. Dle úsudků managementu a potřeb podniku byl vybrán k inovaci tedy právě proces dotazníkového výzkumu, který bude rozšířen o nové možnosti dle potřeb podniku. Na základě konzultace s managementem podniku bude tedy vytvořeno modulární prostředí s možností rozšíření podpory dalších procesů a především bude implementován návrh pro aplikaci dotazníkového výzkumu, který bude vyhovovat potřebám podniku. Proces dotazníkového výzkumu podnik chápe jako kontinuální činnost, která průběžně zpracovává přijímané kontakty, jež vyhovují zadaným kritériím, a výsledky přímo poskytuje dalším procesům především procesu cílené nabídky služeb. V dialogu s vedením podniku byly usneseny následující nefunkční požadavky na nový systém: -
modulární webová aplikace,
-
aplikace na bázi PHP a MySQL,
-
zabezpečení protokolem HTTPS, zabezpečení formulářů
51
-
dostupnost dotazníkového výzkumu online,
-
pevně stanovené dotazníkové otázky pro každou oblast služeb s možností pozdějšího rozšíření.
4.5.1 Use Case diagram Pro přehlednost zápisu funkčních požadavků na nový systém dotazníkového výzkumu z pohledu uživatelů bude využit diagram případů užití. Při sestavování funkčních požadavků se bude vycházet z procesního modelu, který již nastínil některé funkcionality a základní požadavky na systém. V první fázi je třeba určit aktéry, kteří budou docházet do styku se systémem. Aktéři systému jsou zaměstnanci podniku, kteří mají určeny své role a tím také omezeny své pravomoci při vykonávání příslušných procesů. Sledovaný podnik nemá vzhledem k počtu stálých zaměstnanců složitou hierarchii. Byli identifikováni následující aktéři: -
administrátor,
-
správce dotazníkového výzkumu,
-
telefonista,
-
čas.
První jmenovaný aktér administrátor má plný přístup ke všem funkcím systému. Je nejvyšším stupněm v hierarchii pravomocí pro tento systém. Jako jediný má právo spravovat databázi uživatelů systému a to přidávat, editovat a mazat uživatele, kteří budou pracovat se systémem dotazníkového výzkumu. Krom těchto funkcí může vykonávat i všechny činnosti ostatních aktérů. Administrátor je ve skutečnosti hlavní manažer podniku. Správce dotazníkového výzkumu je aktér, který má na starosti celou správu výzkumu. Jeho činností je správa výzkumu, dohled nad průběhem výzkumu, export dat z výzkumu. Vytváří a nahrává do systému seznamy kontaktů na respondenty, tedy má na starosti také správu kontaktů, které jsou předmětem výzkumu. Telefonisté jsou aktéři, kteří mají na starosti samotný průběh výzkumu. Jejich činností je volba kontaktu, vedení hovoru a především vyplňování dotazníkových formulářů příslušného výzkumu, které mohou ukládat a editovat. Mají přístup ke
52
statistikám úspěšnosti odpovědí na dotazníkové výzkumy a to jak ke svým tak i ke statistikám ostatních telefonistů. Aktér čas je zaveden především z důvodů tvorby statistiky a exportů dat. Jelikož data jsou sbírána v určitém časovém úseku, je právě čas důležitým prvkem pro jejich získání. Exportu dat se týkají především statistiky dotazníkového výzkumu a výsledků výzkumu. Dalším bodem analýzy případů užití je nalezení subsystémů a identifikace jejich hranic. V tomto kroku byly identifikovány následující subsystémy náležející do systému dotazníkového výzkumu: -
správa uživatelů,
-
správa výzkumu,
-
dotazníkový výzkum,
-
správa kontaktů.
Na jednotlivé subsystémy systému dotazníkového výzkumu lze nahlížet také jako na základní případy užití, které budou dále dekomponovány.
Obr. 13: Use Case Diagram - globální pohled na systém
53
V následující části budou jednotlivé funkcionality subsystémů dotazníkového výzkumu slovně popsány.
Správa uživatelů Jelikož k aplikaci budou přistupovat uživatelé s různými rolemi, je nutné vytvořit rozhraní, které bude umožňovat správu těchto přístupů. Hlavním smyslem tohoto subsystému bude autentizace a autorizace uživatele v aplikaci a přidělení funkcionalit uživateli dle role v systému. Tento subsystém bude nabízet následující funkcionality: -
Přidání nového uživatele – vytvoření záznamu o novém uživateli v databázi a zanesení do databáze základní údaje o uživateli, především jeho přihlašovací a identifikační údaje v systému, určení role a pravomocí v systému. Systém kontroluje zadávané údaje, jejich nepřesnost, či špatný formát neumožní přidání nového uživatele. Případ užití provádí aktér administrátor.
-
Editace uživatele – umožní změnu všech údajů uživatele, který je evidován v databázi. Aktérem je administrátor.
-
Odebrání uživatele – uživatel a všechny jeho údaje budou smazány z aktivní databáze. Uživatel se již nebude moct přihlásit do systému a jakkoliv s ním pracovat.
-
Změna osobních údajů uživatele – uživatel evidovaný v databázi má možnost editovat své osobní údaje. Jedná se především o editaci uživatelského hesla a jména a kontaktních informací jako email či telefonní číslo. Ostatní údaje lze měnit pouze se souhlasem administrátora. Aktéři tohoto případu užití jsou všichni evidovaní uživatelé systému vytvoření administrátorem a to konkrétně telefonisté a správci výzkumu.
-
Přihlášení uživatele do systému – uživatel v přihlašovacím formuláři vyplní své přihlašovací údaje, tedy uživatelské jméno a heslo. Pokud údaje zadané do formuláře budou souhlasit s údaji v databázi, je uživatel úspěšně přihlášen do systému. Po přihlášení do systému může uživatel začít se systémem pracovat. V případě nesouhlasících údajů je přihlašovanému
54
zobrazeno chybové hlášení. Aktéry jsou všichni evidovaní uživatelé v systému. -
Odhlášení uživatele ze systému – provede odhlášení uživatele a tím ukončí jeho činnost se systémem. Pokud bude chtít uživatel po této akci znovu přistoupit k aplikaci, musí se opět přihlásit. Aktéry jsou všichni evidovaní uživatelé systému.
Obr. 14: Use Case Diagram - správa uživatelů
Správa výzkumu Subsystém pro správu dotazníkových výzkumů tvoří rozhraní, které umožňuje řídit dotazníkový výzkum. Na základě dotazníkových formulářů nastavuje výzkum pro určitý účel. K tomuto rozhraní přistupuje aktér správce výzkumu. Tvoří backend celé aplikace dotazníkového výzkumu, umožňuje nastavení chování frontendu, jímž je zde průběh samotného dotazníkový výzkum. Součástí tohoto subsystému je také správa kontaktů, které tvoří hlavní vstup aplikace.
55
Mezi identifikované funkcionality tohoto správcovského subsystému patří tyto případy užití: -
Nastavení výzkumu – se sestává z evidence základních údajů nutných k nastavení výzkumu a uložení daných informací do databáze. Mezi tyto údaje patří především druh výzkumu, předmět výzkumu, zvolení oblasti služeb výzkumu, přiřazení dotazníkového formuláře. Každému výzkumu je přiřazen tým telefonistů, kteří budou získávat informace od respondentů pro stanovený druh výzkumu. Součástí je také volba zaměření výzkumu na určitý typ respondentů. Aplikace bude rozeznávat dvě základní skupiny respondentů a to anonymní kontakty a stávající zákazníky. Před vytvořením je provedena kontrola správnosti zadaných údajů, případně zobrazena žádost o napravení.
-
Spuštění výzkumu – jedná se o aktivaci výzkumu, po které se zobrazí výzkum všem přihlášeným telefonistům jako aktivní. Aktivovat lze pouze předem vytvořené a neaktivní výzkumy.
-
Pozastavení výzkumu – funkce umožní deaktivovat výzkum, což se projeví znemožněním telefonistům přistupovat k danému výzkumu. Výzkum se přihlášeným telefonistům jeví jako pozastavený a nemůžou s ním tedy pracovat. Zároveň je zobrazena zpráva o neaktivitě výzkumu, který informuje telefonisty o důvodech pozastavení výzkumu.
-
Archivace dat výzkumu – data získaná během výzkumu jsou uložena do archivu databáze, jelikož je nutné, aby v systému bylo evidováno kdy, komu a za jakým účelem bylo telefonováno. Nutná je tedy kontrola duplicity vkládaných kontaktů a prováděných výzkumů na daném kontaktu. Archivace je prováděna průběžně během výzkumu.
-
Správa kontaktů – bude dekomponována, viz níže.
-
Výpis výzkumů – vytvoření vizuálního přehledu o probíhajících výzkumech a stavu vyplněnosti dotazníků u sledovaného souboru kontaktů
(procento
již
obvolaných
zkoumaných)
56
kontaktů
z celkového
počtu
-
Prohlížení výsledků výzkumu – během výzkumu i po skončení je možné zobrazit statistiku s průběžnými či konečnými výsledky konkrétního výzkumu.
-
Export dat výzkumu – rozhraní umožňující exportovat obsah databáze se statistikami výzkumu do souboru v určité struktuře. Aktéry jsou správce výzkumu a čas.
Obr. 15: Use Case Diagram - správa výzkumu
Správa kontaktů Správa kontaktů umožňuje přijetí souboru kontaktů. Nad těmito kontakty je pak prováděn samotný dotazníkový výzkum. Umožňuje správci výzkumu importovat jednotlivé kontakty i hromadné soubory kontaktů. Hlavním smyslem je vkládání
57
anonymních kontaktů, získaných z doporučení stávajících zákazníků. Kontakty pro výzkum jsou rozděleny do dvou kategorií a to anonymní kontakty a kontakty na stávající zákazníky. Pro správu kontaktů byly identifikovány následující požadavky na funkcionalitu: -
Vložení kontaktu – vložení kontaktu z externího zdroje, případně přímo prostřednictvím
formuláře
aplikace.
Kontrola
formátu
vkládaného
souboru. Hromadné vložení kontaktů se týká pouze kategorie anonymních kontaktů z doporučení. Aktérem je správce výzkumu. -
Smazání kontaktu – odstranění kontaktu, není možné s kontaktem dále pracovat. Opět se tato možnost týká pouze anonymních kontaktů. Aktérem je správce výzkumu.
-
Vyhledání kontaktu – po zadání telefonního čísla systém vyhledá výzkumy, které souvisí s daným kontaktem. Aktéry funkcionality jsou telefonista i správce výzkumu.
-
Přiřazení kontaktu výzkumu - pro výzkum není důležité pořadí, v kterém budou kontakty telefonistům nabízeny. Všechny kontakty vyhovující podmínkám mají u výzkumu stejnou prioritu. Systém bude automaticky nabízet vhodné kontakty a to takové, s kterými žádny telefonista momentálně nepracuje a které nebyly pro danou oblast služeb ještě zkoumány vůbec či u nich vypršela interní ochranná lhůta pro opětovné zkoumání v dané oblasti služeb. Systém identifikuje všechny dosavadní výzkumy nad daným kontaktem a dle výsledku nabídne kontakt k dalšímu výzkumu, či dá přednost jinému kontaktu. Aktérem, který tuto funkcionalitu využívá, je telefonista.
58
Obr. 16: Use Case Diagram - správa kontaktů
Dotazníkový výzkum Subsystém dotazníkový výzkum tvoří hlavní aktivitu celého systému, jelikož zde jsou evidovány požadované informace. Sestává se z rozhraní, které umožňuje telefonistům zvolit druh výzkumu, na kterém se budou podílet, dále nabízí telefonistovi kontakty, kterým může telefonovat a to dle pravidel zmíněných v předchozí kapitole o správě kontaktů. Součástí systému je také základní statistika pro telefonisty, kteří zde budou moci porovnávat svoji úspěšnost v získávání informací od kontaktů s ostatními telefonisty. Při zvolení kontaktu a zahájení výzkumu se ke každému kontaktu zobrazí formulář s dotazníkovými otázkami, které telefonista dle informací získaných od respondenta vyplňuje a ukládá. V tomto subsystému byly určeny následující funkcionality: -
Volba dostupných výzkumů – telefonista si zvolí z právě aktivních výzkumů, které mu byly přiděleny, a začne provádět dotazníkové šetření zvolením kontaktu a navázáním spojení respondentem.
-
Spojení s telefonním kontaktem – probíhá prostřednictvím telefonu mimo tento systém a nad předem zvoleným kontaktem. Je evidován pokus o spojení s kontaktem a všechny stavy, které jsou výsledkem tohoto spojení, musí telefonista zaznamenat. Při pokusu o spojení s kontaktem může telefonista zaznamenat stav, kdy volaný hovor nepřijímá, dále může hovor přijímat, ale nechce se zúčastnit výzkumu, může hovor přijímat, ale zrovna
59
nemá čas, tedy chce zavolat někdy jindy, ovšem očekávanou reakcí je, že hovor přijímá a zúčastní se výzkumu. Existuje ještě jeden stav a to stav, kdy je daný kontakt odmítnut samotným telefonistou, jelikož se nejedná o požadovaný typ respondenta. Jedná se o stanovu, která může vycházet z předmětu výzkumu a specifikace dané oblasti služeb. Krom pokusu o volání a jeho následného stavu je k pokusu evidován ještě telefonista, který hovor uskutečnil a čas hovoru, který je totožný s časem, kdy byl otevřen daný dotazníkový formulář. Aktérem je telefonista. -
Vyplňování dotazníku – v tomto případu užití telefonista postupně vyplňuje dotazníkový formulář z vrchu dolů. Dotazníkový formulář je sestaven tak, aby telefonistovi co nejvíce ulehčoval práci při vyplňování. Jeho skladba otázek je dle všeobecných zásad pro dotazníkové šetření. V horní části dotazníkového formuláře se nachází stav pokusu o volání a pod ním následují samotné otázky. Při zadávání dat do formuláře je kontrolován správný formát dat pro danou otázku. V případě nesouhlasu formátu je zobrazena chyba a dotazník pak nebude možné uložit, dokud nedojde k nápravě. Během práce s dotazníkovým formulářem je kontakt blokován pro ostatní telefonisty. Aktérem je telefonista.
-
Kontrola vyplněnosti dotazníku – před uložením je provedena celková kontrola, zdali má dotazníkový formulář vyplněn všechny náležitosti.
-
Uložení vyplněného formuláře - pro úspěšné uložení dotazníku do databáze je třeba vypsat minimálně stav pokusu o volání. A v případě stavu spolupráce respondenta také vyplnit požadované minimum otázek, aby mohl být respondent označen jako spolupracující a dotazník mohl být v tomto stavu uložen do databáze. V případě, že je dotazník uložen ve stavu, kdy se telefonista respondentovi nedovolal, není daný kontakt z výzkumu ještě vyloučen, ale je znovu zahrnut mezi nevyplněné dotazníky, ovšem teď již s příznakem neúspěšného pokusu o volání. V systému bude stanoven maximální počet pokusů o spojení s kontaktem, po překročení tohoto množství neúspěšných pokusů bude kontakt označen za nespolupracující. Pokud je výzkum uložen a je řádně vyplněn se všemi
60
náležitosti jsou jeho výsledky zpřístupněny ostatním podnikovým procesům (viz proces cílené nabídky služeb). -
Editace vyplněného formuláře – tomuto případu užití předchází vyhledání požadovaného formuláře na základě kontaktu a názvu výzkumu. Editace formuláře umožní změnit předchozí uložená data ve formuláři.
-
Výpis statistik – vytváří rozhrání pro vizuální interpretaci statistických údajů pro telefonistu. Telefonista má možnost zvolit si období, za které se mu vypíší statistiky. Statistiky se týkají úspěšnosti telefonisty při získávání informací od respondentů. Telefonisté mají možnost vidět žebříček úspěšnosti všech telefonistů a svoje pořadí v něm za zvolené období. Nerozlišuje se zde typ výzkumu, funkcionalita má spíše informativní a motivační charakter pro telefonistu. Případ užití je možné rozšířit o export statistiky do souboru. Statistika je tvořena průběžně, vždy za konkrétní časové období.
Obr. 17: Use Case Diagram - dotazníkový výzkum
61
4.5.2 Diagram tříd Během analýzy případů užití byl získán přehled o očekávaných funkcích nového systému, byli identifikováni aktéři, kteří se systémem budou pracovat, určeny hranice systému a došlo k dekomponování systému na subsystémy. Ovšem stále není stanovena struktura dané aplikace. Tento problém by měl řešit právě diagram tříd. Z výše zjištěných údajů v předchozí analýze je třeba navrhnout strukturu aplikace. Struktura bude navržena prostřednictvím identifikovaných tříd a jejich vzájemných vztahů. Mezi nejdůležitější třídy systému patří třídy Contact (kontakt), User (uživatel), ResearchCall (hovor za účel výzkumu), Form (dotazníkový formulář) a QuestionAnswer (odpověd na otázku). Při nahrávání nových vstupů pro výzkum bude využita třída Contact, která tvoří rozhraní mezi anonymním uživatelem a registrovaným zákazníkem. Z návrhu je zřejmé, že kontakt může existovat i nezávisle na třídě Customer. S tímto případem kontaktu se v aplikaci bude pracovat jako s anonymním kontaktem. Anonymní kontakty budou nahrávány do aplikace především hromadně. V případě, že si anonymní kontakt objedná nějakou službu, stane se zákazníkem (bude mu přiřazena třída Customer) a dále bude podléhat už jen výzkumu pro stávající zákazníky. Třída TelephonistAssing (přiřazení telefonisty) přímo řeší přiřazení daných uživatelů ke konkrétním výzkumům a bude tím tak delegovat práci telefonistů. Při návrhu tříd byl kladen důraz na rozšíření aplikace o možnost editovat z uživatelského rozhraní dotazníkové otázky. Jelikož v původním požadavku tato funkcionalita zahrnuta nebyla. Pro tento účel vznikla třída QuestionTagType (typ zobrazení daného formulářového prvku) a bylo počítáno s možností volby z nabízených odpovědí pro otázku u třídy QuestionSelect (volba pro otázku).
62
Obr. 18: Diagram tříd
4.5.3 Diagram aktivit V této kapitole bude naznačen průběh jednotlivých aktivit případu užití dotazníkový výzkum ze systému dotazníkového výzkumu. Jelikož s případem užití souvisí především telefonista, jsou následující aktivity popisovány z jeho pohledu. Diagram aktivit zde bude popisovat základní činnosti, které bude
63
uživatel v roli telefonisty vykonávat ve stanoveném systému. Následující aktivitě předchází aktivita přihlášení uživatele do systému, která zde pro svoji obecnost nebude popisována. Tedy po přihlášení do systému dotazníkového výzkumu má uživatel dvě základní linie volby aktivit. První linie souvisí se zobrazením statistiky úspěšnosti telefonistů ve výzkumu a druhá se samotným průběhem dotazníkového výzkumu. Dotazníkový výzkum začíná volbou výzkumu. Telefonista si zvolí z výzkumů, které mu byly přiřazeny správcem výzkumu. V případě, že má telefonista přístupných více výzkumů, je volba v jeho kompetenci. Další akce jsou závislé na aktivitě zvoleného výzkumu. Není-li zvolený výzkum aktivní a není-li aktivní ani žádný další výzkum pro daného telefonistu tato linie aktivit končí. Pokud ovšem je zvolený výzkum, či jiný dostupný výzkum aktivní může telefonista začít s výzkumem. Jako první bod po zahájení výzkumu je vykonána aktivita Přiřazení výzkumu, jejímž cílem je nalezení vhodného kontaktu k danému výzkumu. Aktivita Přiřazení kontaktu bude vykonávána automatizovaně. Její kostrou je hledání kontaktu. Je hledán kontakt, který nemá víc jak 3 negativní pokusy o volání. Negativní pokus znamená, že se telefonista nedovolal danému kontaktu. Pokud daný kontakt nevyhovuje podmínce, dochází k novému hledání. Pokud je nalezen kontakt, který vyhovuje této podmínce, je podroben další podmínce a tou je informace, zdali někdo už s kontaktem nepracuje. S jedním kontaktem může v systému pracovat vždy jen jeden telefonista, není žádoucí, aby se jednomu kontaktu snažili volat naráz dva telefonisté případně, aby jednomu kontaktu volali v krátkém časovém rozestupu. V případě, že kontakt je zrovna v režii jiného telefonisty, dochází k novému hledání kontaktu. Pokud nelze nalézt kontakt, který by vyhovoval jakékoliv podmínce nelze vykonávat další činnost související s touto linií.
64
Obr. 19: Diagram aktivit - případ užití dotazníkový výzkum
Po fázi, kdy je kontakt úspěšně vybrán a přiřazen následuje otevření dotazníku telefonistou a zablokování přiřazeného kontaktu tak, aby s ním nemohl v daný okamžik pracovat jiný telefonista. Následuje pokus o spojení s kontaktem. Není-li spojení úspěšné, je zaevidován u daného kontaktu negativní pokus o spojení a nabídnut telefonistovi další kontakt. Je-li spojení úspěšné, dochází k dalšímu větvení aktivit. V případě, že po spojení s kontaktem daný kontakt nespolupracuje a nechce se zúčastnit výzkumu, je vyřazen z dalšího zkoumání v daném výzkumu
65
na předem stanovenou minimální ochranou dobu. Pokud telefonista neukončí výzkum, je mu přiřazen další kontakt. Je-li ovšem spolupráce s kontaktem pozitivní následuje získání informací od kontaktu a postupné vyplňování daného dotazníkového formuláře. Nad formulářem je při uložení provedena kontrola, zdali jsou vyplněny minimální stanovené údaje pro uložení formuláře. Pokud tomu tak je, je formulář uložen, v jiném případě dochází k neuložení formuláře. Po akcích, které završí práci s kontaktem, následuje vždy odblokování, uvolnění kontaktu pro další zpracování. Pokud telefonista výzkum neskončí, je mu přiřazen další kontakt. Druhou možnou linií aktivit je volba statistky a následné prohlížení statistických údajů o úspěších telefonistů při výzkumech.
4.5.4 Sekvenční diagram V této fázi analýzy bude znázorněn pohled na komunikaci mezi třídami a případy užití. Z analýzy by mělo plynout, kdy a jaká aktivita je v interakci s kterým objektem. Znázorňuje, jakým způsobem mezi sebou komunikují objekty vzhledem k dané funkcionalitě. V diagramu je znázorněn systém dotazníkového výzkumu, tedy samotný proces získávání dat od respondentů, který vykonávají telefonisté. Diagram představuje základní komunikaci telefonisty a systému, která se odráží od klíčových prvků nutných k pochopení vztahů mezi nejdůležitějšími třídami. Cílem diagramu je tedy především pochopení vztahů tříd. V diagramu je proto pro přehlednost vynecháno znázornění uživatelského rozhraní, uživatelské rozhraní je zde abstrahováno do pozice aktéra. Jak již bylo naznačeno v kapitole o diagramu tříd, stěžejními třídami systému dotazníkového výzkumu jsou třídy Research, Contact, AccessBlock, Form, ResearchCall, Question, QuestionAnswer. Tyto třídy zajišťují kostru struktury navrhovaného systému. Co se tedy týče časové návaznosti jednotlivých interakcí uživatele a systému veškerá další akce je závislá na první fázi, jímž je volba výzkumu. Zde telefonista volí z nabízených výzkumů a jedná se o jeho první interakci s třídou Research. V další fázi komunikaci telefonista zahajuje zvolený výzkum, požadavkem na zahájení výzkumu. K samotnému výzkumu se váže soubor kontaktů ze třídy Contact, z nichž je vždy jednomu telefonistovi jeden přiřazen. U přiřazovaného kontaktu je ověřováno, zdali není zablokován v třídě AccessBlock. Dále dochází k přiřazení vhodného dotazníkového formuláře prostřednictvím třídy Form.
66
Každý formulář obsahuje otázky, a proto komunikace dále pokračuje požadavkem na získání otázek k formuláři z třídy Question. Pomyslnou třetí fází komunikace je samotný pokus o získání dat od respondenta. Zde komunikace začíná pokusem o spojení, a to v prvé řadě interakcí s třídou Contact a třídou AccessBlock, kde se provede zablokování daného kontaktu pro ostatní uživatele. Další komunikací je zapsání stavu pokusu o spojení s kontaktem do třídy ResearchCall a zanesení případných získaných dat do třídy QuestionAnswer. Po těchto akcích je většinou volána třída AccessBlock, kde je vyžadováno odblokování kontaktu pro ostatní uživatele. Odblokování tedy souvisí s ukončením práce s kontaktem. Mezi poslední či paralelní komunikaci telefonisty se systémem lze považovat získávání statistik. Statistiky čerpají data z třídy ResearchCall, která v sobě skrývá veškeré údaje a cesty k údajům o vedeném spojení s kontaktem.
Obr. 20: Sekvenční diagram - případ užití dotazníkový výzkum
67
4.5.5 ERD diagram Na základě výsledků předchozích analýz mohl vzniknout fyzický datový model. Tento model vychází zejména z diagramu tříd a je rozšířen o implementační třídy. V tomto případě se jedná pouze o entitu user_role, která slouží jako rozhraní pro vyjádření vazby mezi rolemi a uživateli. Implementované entity a jejich vztahy znázorňuje níže uvedený ERD diagram. Použité entity mají následující význam: Respondent_type – obsahuje výčet typů možných druhů respondentů, v praxi bude tabulka rozlišovat například typ stávající zákazník a typ anonymní kontakt. U tabulek obsahující nějaký výčet typů je vždy uveden atribut „view“, který je zaveden z důvodů dvojí jazykové interpretace daného typu. V aplikační vrstvě bude použit anglický jazyk, kdežto v uživatelském rozhraní může být použit jazyk jiný. Jedná se tedy o alias pro prezentační vrstvu. Question_select – je tabulka, jejíž struktura je propojena s tabulkou question. Zahrnuje případy, kdy dané otázky nebudou otevřeného typu, a bude nutné zvolit odpověď z nabízených voleb. Tabulka bude nést záznamy o těchto nabízených odpovědí na danou otázku. TelephonistAssign – v případě, kdy je třeba rozčlenit práci telefonistů tak, aby každý telefonista pracovat jen na určeném výzkumu a v rámci tohoto výzkumu, se věnoval pouze určitým oblastem služeb, je zapotřebí této tabulky. Jedná se o asociační tabulku, jejímž cílem je nasměrování práce telefonistů. Research – shrnuje základní údaje o výzkumu, jeho názvu, stavu a zahrnuje přiřazení respondentů. Form – navazuje na tabulku research. Základem každého výzkumu jsou dotazníkového formuláře, které implementuje tato tabulka. Formulář patří vždy pod určitý výzkum a je zaměřen na určitou oblast služeb. Question – každý formulář je složen z určitých otázek. Tyto otázky jsou implementovány v této tabulce. Pro výpis dotazníkového formuláře bude třeba rozlišit, kdy se vypíše, která otázka. Je tedy evidována pozice dané otázky. Dále je třeba evidovat, zdali bude otázku nutné vyplnit, či nikoliv. Tento fakt bude zajišťovat atribut check. Jelikož v dotazníkovém formuláři můžou být otázky zobrazeny různým způsobem, je třeba evidovat, jakým způsobem budou zobrazeny. Pro tento účel bude sloužit identifikátor daného typu zobrazení. Question_tag – tabulka s výčtem typů různých formulářových html tagů.
68
Service_section – tabulka s výčtem typů oblastí služeb, kterým se věnuje sledovaný podnik. Research_call – hlavní entita pro vedení evidence každého pokusu o spojení s respondentem. Zde je evidován výsledek pokusu o volání telefonisty konkrétnímu kontaktu, v daný čas, během daného výzkumu. Question_answere – během pokusu o spojení jsou respondentovi kladeny otázky, odpovědi na tyto otázky jsou vedeny v této tabulce. Každá odpověď je vázána k otázce, která spadá pod daný formulář, daného výzkumu. Odpovědi jsou dále svázány s daným pokusem o spojení s respondentem. Call_result – tabulka s výčtem typů možných výsledků hovoru. User – zde jsou evidovány údaje o daném uživateli systému. User_role – je asociační tabulka, kde je každému uživateli přiřazena jedna či více rolí. Role – tabulka s výčtem typů rolí uživatelů systému. Contact – stěžejní evidence o vstupech výzkumu je vedena v této tabulce. Základním atributem je telefonní číslo, na které během výzkumu telefonista volá. Dále je možné daný kontakt kontaktovat emailem, pokud je znám. Pro přehled o délce zavedení kontaktu v systému je evidován datum vložení kontaktu do systému. Acces_block – při práci s kontaktem je nutné dbát na to, aby s kontaktem pracoval vždy jen jeden telefonista, tedy pro případy, kdy se pokusí kdokoliv zahájit práci s kontaktem je vyžadována kontrola stavu daného kontaktu v této tabulce. Blokování kontaktu je dáno dvěma atributy. První atribut block nabývá pouze stavu true a false. Druhý atribut block_time hlídá dobu, po kterou je kontakt zablokován. Pro práci s kontaktem bude stanovena ochranná lhůta, po jejímž překročení bude kontakt opět odblokován. K bloku kontaktu je vázán uživatel, pouze ten má po dobu blokování možnost pracovat s jím zablokovaným kontaktem. Customer – eviduje registrované zákazníky sledovaného podniku, spadá již pod část datového modelu, který se týká evidence stávajících zákazníků. Tato část zde více rozebírána nebude, cílem je naznačení vztahu mezi anonymním kontaktem a
69
stávajícím zákazníkem. Anonymní kontakt je de facto kontakt, který nemá záznam v této tabulce.
Obr. 21: ERD diagram - fyzický model
70
4.5.6 Uživatelské rozhraní Aplikace bude dostupná online z webových stránek podniku pod doménou třetího řádu. Aplikace je zcela oddělena od oficiálního webu sledovaného podniku a je u ní zakázáno indexování vyhledávači. Veškerá komunikace mezi klientem a serverem bude šifrovaná s využitím protokolu HTTPS (Hypertext Transfer Protocol Secure). Pro opravdu bezpečnou komunikaci by bylo vhodné také zvážit možnosti přihlašování pomocí certifikačních autorit a digitálních certifikátů. Pro navrženou aplikaci bylo vytvořeno uživatelské rozhraní dle grafického návrhu, který měl být sladěn s podnikovými barvami. Jelikož půjde o pracovní aplikaci, bylo využito celé šíře obrazovky pomocí relativního formátu se stanovenou minimální délkou. Množství grafických prvků je minimální, důraz byl kladen na přehlednost a účelnost designu a rozmístění ovládacích prvků. Díky architektuře MVC (model-view-controller), kterou použitý Nette framework podporuje, je vrstva pohledu, oddělena od aplikační logiky. Vrstva pohledu je navíc založena na šablonovacím systému Latte, který zpřehledňuje pohledovou vrstvu a umožňuje tvorbu šablon, díky které je možné efektivně měnit vzhled aplikace. V uživatelském rozhraní je využito technologie AJAX (Asynchronous JavaScript and XML), která zjednodušuje uživateli práci s uživatelským rozhraním. Po přesměrování na danou doménu bude jako první každý uživatel vyzván k přihlášení do systému prostřednictvím přihlašovacího dialogu, zadáním uživatelského jména a hesla. Po přihlášení se stránka přesměruje na úvodní stranu, která slouží jako rozcestník. Zde budou přehledně uvedeny všechny moduly, které jsou v systému nainstalovány. Po zvolení modulu dotazníkového výzkumu je uživatel přesměrován na danou stránku, která obsahuje již jen volby zvoleného modulu. Množství dostupných a tudíž i zobrazených voleb je závislé na roli přihlášeného uživatele. Telefonisté mají k dispozici pouze volby vycházející z jejich stanovených činností v systému. Mezi tyto volby patří přístup ke statistikám telefonistů a volby související s výběrem a zahájením dotazníkového výzkumu. Správce výzkumu a administrátor již mají dostupných voleb více, především se jedná o volby související se správou daného modulu. Společnou volbou pro všechny uživatele je uživatelské nastavení, kde si každý přihlášený uživatel může změnit své uživatelské údaje, včetně údajů pro přihlášení do systému.
71
Obr. 22: Ukázka uživatelského rozhraní – dotazník pro telefonistu
Obr. 23: Ukázka uživatelského rozhraní - statistiky telefonistů
72
5 DISKUZE Výše popisované diagramy slouží jako podklad pro tvorbu výsledné aplikace. Aplikace byla vytvořena prostřednictvím frameworku Nette, který využívá programovacího jazyka PHP. Byla vytvořena databáze v dotazovacím jazyku MySQL z výše uvedeného datového modelu (viz ERD diagram), struktura byla vygenerována programem Visual Paradigm, v kterém byla část aplikace modelována. Aplikace bude nasazena na ostrý provoz, až v době, kdy bude její funkčnost doladěna a bude testovací provoz prohlášen za bezproblémový. Sledovaný podnik nedisponuje žádným informačním systémem a vzhledem k tomu, že byl od managementu zadán také požadavek na vytvoření modulárního prostředí, bylo vytvořeno základní uživatelské rozhraní, které umožní jednoduché přidání nového modulu podporující další podnikový proces. Požadavek na modularitu a rozšiřitelnost byly jedním z mnoha důvodů, proč byl zvolen pro tvorbu aplikace právě Nette framework. Při tvorbě byly dodrženy zásady popisované v manuálu frameworku, tudíž pochopit princip struktury aplikace by neměl být problém pro případ budoucích úprav či rozšiřování systému. Nasazení nové aplikace umožní podniku efektivnější využití svých pracovních sil. Vzhledem k tomu, že nové prostředí bude přístupné online, není nutné, aby telefonisté docházeli pracovat do kanceláře podniku, a můžou tedy pracovat odkudkoliv, kde bude připojení k internetu. Telefonisté jsou placeni pouze za plně vyplněné dotazníky, vzhled k vedeným statistikám je export statistik výzkumů vhodným podkladem pro výpočet finančního ohodnocení telefonistů. Zhotovená aplikace má naznačit nový směr uvažování podniku nad průběhem svých procesů. Nový systém dotazníkového výzkumu je prvním pokusem o integraci procesů. Během analýzy procesů bylo zjištěno plno dalších míst v procesním modelu, kde by bylo vhodné inovovat. Sledovaný podnik počítá se sjednocením svých procesů do jednoho spolupracujícího systému a chce dále pokračovat v těchto inovacích. Dalším bodem inovace by měl určitě být proces cílené nabídky služeb, který v současném modelu čerpá výstupní data z procesu dotazníkového výzkumu. Podnik počítá s tímto rozšířením a stejně tak s autorem této práce, který bude mít další rozšíření na starosti. Procesy podporující řízení vztahů se zákazníky by měly být v nejbližší době dále rozšířeny o ucelenou databázi stávajících zákazníků a jejich služeb, jelikož
73
současná evidence v programu MS Excel není vyhovující a není integrovaná s novým modulárním prostředím, ačkoliv nové prostředí již s jeho zavedením počítá a je na něj připraveno.
74
6 ZÁVĚR Hlavním cílem této diplomové práce bylo za pomoci objektového přístupu, diagramů notace UML a vybraného CASE nástroje vytvořit procesní model architektury vybraného podniku z oblasti služeb, vytvořený procesní model konzultovat s managementem podniku a na základě potřeb podniku navrhnout inovaci vybraného procesu z oblasti řízení vztahů se zákazníkem za pomoci výpočetní techniky. Dílčím cílem práce bylo implementovat navrženou aplikaci prostřednictvím daných webových technologií a integrovat ji do prostředí zvoleného podniku. Pro účel práce byl zvolen menší podnik zprostředkovávající skupinové slevy na různé oblasti služeb. Jedná se především o služby z oblasti mobilní komunikace, pojištění automobilů a energií. Podnik nedisponoval žádným informačním systémem a informace zpracovával pouze prostřednictvím kancelářského software a několika nevyhovujících webových aplikací. První část vlastní práce si kladla za cíl identifikaci stěžejních podnikových procesů a vytvoření Business Process Modelu. Pro modelování procesů byl použit CASE nástroj Enterprise Architect. Během procesní analýzy bylo identifikováno 5 základních procesů – dotazníkový výzkum, cílená nabídka služeb, technická podpora, správa objednávek, aktivace a přenos služeb. Identifikované procesy byly zakresleny pomocí Eriksson-Penkerovi notace a postupně dekomponovány. Zhotovený procesní model byl konzultován s managementem sledovaného podniku a na základě potřeb podniku byl k inovaci zvolen proces dotazníkového výzkumu. Tento proces doposud částečně zajišťovala webová aplikace, která již nevyhovovala změnám v podniku. Bylo požadováno vytvořit rozšiřitelné modulární prostředí a aplikaci, která s ním bude kompatibilní a bude již efektivně podporovat proces dotazníkového výzkumu. Byl stanoven požadavek na webovou aplikaci na bázi PHP a MySQL, která bude modulární, rozšiřitelná a dostupná bezpečně online. V části zabývající se inovací je tedy dále analyzován systém dotazníkového výzkumu. Diagramy v této části jsou vytvářeny za pomoci CASE nástroje Visual Paradigm. Prvním krokem byla analýza požadavků na funkcionality nového systému prostřednictvím Use Case modelu. Pro popis statické stránky systému byl sestaven diagram tříd. Interakce složek systému byly vyjádřeny za pomoci diagramu aktivit a sekvenčního diagramu. Jelikož se při realizaci počítalo
75
s nasazením entitně-relačního databázového systému, byl na základě diagramu tříd odvozen ERD diagram, z kterého byl vygenerován kód pro vytvoření databáze. Aplikace byla vytvořena na základě technologií Nette framework, PHP, HTML, CSS, AJAX a MySQL. Bylo vytvořeno adekvátní uživatelské rozhraní a komunikace zabezpečena protokolem HTTPS. Vytvořená aplikace bude testována a následně nasazena na ostrý provoz. Navržené a implementované inovace procesu dotazníkového výzkumu podniku značně ulehčí získávání vstupních dat pro další procesy, které ve výsledku podniku ušetří čas a tím i peněžní prostředky. Aplikace sice uspokojí potřeby podniku, ovšem bez integrace ostatních procesů nebude její potenciál využit na maximum. Proto by cílem podniku měly být i na dále snahy inovovat a integrovat důležité procesy do jednoho funkčního a spolupracujícího celku.
76
7 LITERATURA [1]
ARLOW, Jim a Ila NEUSTADT. UML 2 a unifikovaný proces vývoje aplikací: objektově orientovaná analýza a návrh prakticky. Vyd. 1. Překlad Bogdan Kiszka. Brno: Computer Press, 2007, 567 s. ISBN 978-80-251-1503-9
[2]
BUCHALCEVOVÁ, Alena, Jarmila PAVLÍČKOVÁ a Luboš PAVLÍČEK. Základy softwarového inženýrství:materiály ke cvičení. Vyd. 1. Praha: Oeconomica, 2007, 221 s. Knihovna programátora (Grada). ISBN 978-80-2451270-9.
[3]
ERIKSSON, Hans-Erik a Magnus PENKER. Business modeling with UML: business patterns at work. Vyd. 1. New York: John Wiley, 2000, xix, 459 p. ISBN 04-712-9551-5.
[4]
FOWLER, Martin. Destilované UML. 1. vyd. Praha: Grada, 2009, 173 s. Knihovna programátora (Grada). ISBN 978-80-247-2062-3.
[5]
KANISOVÁ, Hana a Miroslav MÜLLER. UML srozumitelně. 2. aktualiz. vyd. Brno: Computer Press, 2006, 176 s. ISBN 80-251-1083-4.
[6]
KRAVAL, Ilja. Základy objektově orientovaného programování. Vyd. 1. Praha: Computer Press, 1998, xi, 251 s. ISBN 80-722-6047-2.
[7]
MERUNKA, Vojtěch, Robert PERGL a Marek PÍCKA. Objektově orientovaný přístup v projektování informačních systémů: procesní řízení a modelování. Vyd. 1. V Praze: Česká zemědělská univerzita, Provozně ekonomická fakulta, 2005, 237 s. Knihovnicka.cz. ISBN 80-213-1352-8.
[8]
PROCHÁZKA, Jaroslav. Nástroje CASE? Co? Proč? Jak?. [online]. 2004 [cit. 2012-05-22]. Dostupné z: http://www.dbsvet.cz/view.php?cisloclanku=2004052702
[9]
RÁBOVÁ, Ivana. Informační systémy, informační technologie: procesní řízení a modelování. 1. vyd. Brno: Konvoj, 2003, 26 s. ISBN 80-730-2060-2.
[10] RÁBOVÁ, Ivana. Podniková architektura - strategický nástroj v rukou manažera: procesní řízení a modelování. V Tribunu EU vyd. 1. Brno: Tribun EU, 2008, 131 s. Knihovnicka.cz. ISBN 978-80-7399-568-3.
77
[11] RUMBAUGH, James, Ivar JACOBSON a Grady BOOCH. The unified modeling language reference manual:materiály ke cvičení. 2nd ed. Boston: Addison-Wesley, c2005, xx, 721 p. Knihovna programátora (Grada). ISBN 03-212-4562-8. [12] ŘEPA, Václav. Podnikové procesy: procesní řízení a modelování. 2., aktualiz. a rozš. vyd. Praha: Grada, 2007, 281 s. ISBN 978-80-247-2252-8. [13] SODOMKA, Petr. Informační systémy v podnikové praxi: procesní řízení a modelování. Vyd. 1. Brno: Computer Press, 2006, 351 s. ISBN 80-251-1200-4. [14] SCHMULLER, Joseph. Myslíme v jazyku UML: procesní řízení a modelování. Vyd. 1. Praha: Grada, 2001, 360 s. ISBN 80-247-0029-8.
78
SEZNAM OBRÁZKŮ Obr. 1: Metodika Unified Process (R – Requirements, A – Analysis, D – Design, I – Implementation, T – Test), zdroj: (Arlow, Neustadt, 2007) ........................................ 17 Obr. 2: Schéma rozdělení diagramu, zdroj: Arlow, Neustadt, 2007 .......................... 18 Obr. 3: Notace BPM dle Erikssona a Penkera ............................................................... 21 Obr. 4: Porovnání vztahu analytického a návrhového modelu tříd .......................... 25 Obr. 5: Symboly diagramu aktivit .................................................................................. 26 Obr. 6: Rozčlenění CASE nástrojů dle životního cyklu vývoje software, zdroj: (Procházka, 2004) .............................................................................................................. 30 Obr. 7: Procesní model - základní pohled na procesy v podniku.............................. 40 Obr. 8: Procesní model - správa objednávky ................................................................ 42 Obr. 9: Procesní model - aktivace služby....................................................................... 44 Obr. 10: Procesní model - technická podpora ............................................................... 45 Obr. 11: Procesní model - dotazníkový výzkum .......................................................... 47 Obr. 12: Procesní model - cílená nabídka služeb .......................................................... 49 Obr. 13: Use Case Diagram - globální pohled na systém ............................................ 53 Obr. 14: Use Case Diagram - správa uživatelů ............................................................. 55 Obr. 15: Use Case Diagram - správa výzkumu ............................................................ 57 Obr. 16: Use Case Diagram - správa kontaktů ............................................................. 59 Obr. 17: Use Case Diagram - dotazníkový výzkum .................................................... 61 Obr. 18: Diagram tříd ....................................................................................................... 63 Obr. 19: Diagram aktivit - případ užití dotazníkový výzkum ................................... 65 Obr. 20: Sekvenční diagram - případ užití dotazníkový výzkum ............................. 67 Obr. 21: ERD diagram - fyzický model .......................................................................... 70 Obr. 22: Ukázka uživatelského rozhraní – dotazník pro telefonistu ......................... 72 Obr. 23: Ukázka uživatelského rozhraní - statistiky telefonistů ................................ 72
79
