Modelování podnikové architektury a návrh struktury komponent informačního systému v oblasti služeb

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: 2.4.1 Objekt abstrakce, tvorba objektů, třídy objektů, zapouzdření, ukrývání implementace, komunikace objektů, dědičnost, polymorfizmus. 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

2.4.2 Třída 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) 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 jednotlivé přechody mezi nimi. Používá se pro popis chování daného objektu. Ze stavového diagramu zjistíme, jaké stavy může daný objekt nabývat, případně za jakých okolností se přesune ze stavu A do stavu B. Popisuje chování jednoho objektu napříč více případy užití (Flowler, 2009) 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 <<component>> č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. Fyzický model 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 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 inženýrství, tedy obsahují nástroje pro generování kódu, 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 Eriksson- Penkerovi 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