Procesní modelování a inovace informačního systému v podniku

Mendelova univerzita v Brně Provozně ekonomická fakulta

Procesní modelování a inovace informačního systému v podniku Diplomová práce

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

Bc. Jiří Adolf

Brno 2013

Na tomto místě bych rád poděkoval vedoucí diplomové práce, paní doc. Ing. Ivaně Rábové, Ph.D. za obětavý přístup, cenné rady a připomínky, které mi poskytla během řešení této práce.

Prohlašuji, že jsem tuto diplomovou práci vyřešil samostatně a s použitím literatury uvedené v závěrečné části práce.

V Brně dne 20. května 2013

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

4

Abstract Adolf, J. Process modeling and innovation in the enterprise information system. Diploma thesis. Brno, 2013 This thesis is dedicated to the analysis of real processes in a company that sells photographic equipment, consumer electronics and providing services in the ecommerce field. The processes are modeled using UML 2.0 and BPMN 2.0 notation using selected CASE tool. Effectiveness of the process is evaluated and some innovations were proposed. Outcome of this work is the design and implementation of the IT ticketing system to manage requirements for the internal IT department. The discussion compares different approaches to process modeling as well as discussion of the economic evaluation of innovation.

Abstrakt Adolf, J. Procesní modelování a inovace informačního systému v podniku. Diplomová práce. Brno, 2013 Tato diplomová práce je věnována problematice analýzy reálných procesů ve společnosti, která se zabývá prodejem fototechniky, spotřební elektroniky a poskytováním služeb v oblasti e-commerce. Procesy jsou namodelovány pomocí notací UML 2.0 a BPMN 2.0 ve vybraném CASE nástroji. Efektivnost procesů je zhodnocena a proveden návrh jejich inovací. Výstupem práce je návrh a implementace systému pro správu požadavku na interní IT oddělení. V rámci diskuze jsou porovnány jednotlivé přístupy k procesnímu modelování a diskuze nad ekonomickým zhodnocením inovací.

5

OBSAH

Obsah 1 Úvod a cíl práce 1.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 6 6

2 Procesní modelování a podniková architektura 2.1 Procesní řízení organizace . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Informační modelování organizací . . . . . . . . . . . . . . . . . . . . Globální a detailní pohled . . . . . . . . . . . . . . . . . . . . . . . .

7 8 8 9

3 Možnosti modelování systémů 3.1 UML . . . . . . . . . . . . . . . . . . Erikson-Penker . . . . . . . . . . . . 3.2 BPMN 2.0 . . . . . . . . . . . . . . . 3.3 CASE nástroje . . . . . . . . . . . . Sparx Systems - Enterprise Architect 4 Další teoretická východiska 4.1 E-commerce . . . . . . . . . . . . . 4.2 Středisko sdílených služeb . . . . . 4.3 SEO - Search Engine Optimization 4.4 Použité technologie . . . . . . . . . PHP: Hypertext Preprocessor . . . Databázový systém MySQL . . . . 5 Představení společnosti 5.1 DIXONS RETAIL, PLC. 5.2 PIXMANIA, s.r.o., Brno Platforma E-merchant . Struktura společnosti . . 5.3 Analýza procesů . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6 Návrh inovací 6.1 Návrh inovace procesu Inventarizace ICT majetku . . . . . . . . . Návrh fyzického zařízení . . . . . . . . . . . . . . . . . . . . . . . Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cena řešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Návrh inovace pro systém pro správu požadavků pro IT oddělení Současný stav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Návrh inovace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Přínos systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ekonomické zhodnocení inovace . . . . . . . . . . . . . . . . . . .

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

. . . . .

11 11 15 16 18 19

. . . . . .

21 21 22 23 23 23 24

. . . . .

25 25 25 28 31 32

. . . . . . . . . .

48 49 50 51 52 53 53 54 55 57 57

OBSAH

6

7 Diskuze

58

8 Závěr

60

9 Reference

61

Přílohy

64

A Představení aplikace

65

1

ÚVOD A CÍL PRÁCE

1 1.1

7

Úvod a cíl práce Úvod

Každá moderní společnost v dnešní době hojně využívá prostředky informačních technologií. Složitost procesů, které ve firemním prostředí probíhají, je velmi velká a komplexní. V dnešní době existují efektivní metodologie a nástroje, usnadňující popis těchto procesů. Mezi nejrozšířenější patří právě UML 2.0, což je grafický jazyk pro vizualizaci a specifikaci programových systémů, jenž nabízí i konceptuální prvky pro modelování podnikových procesů. Specializovanější je metodologie BPMN 2.0, jedná se o soubor principů a pravidel, které slouží pro grafické znázornění podnikových procesů pomocí diagramů. Právě tyto dva zmíněné přístupy jsou v této diplomové práci využity a diskutovány pro analýzu a vizualizaci reálných podnikových procesů ve společnosti, která se zabývá prodejem fototechniky, spotřební elektroniky a příslušenství prostřednictvím elektronického obchodu. Pro tvorbu diagramů je využit softwarový CASE nástroj Enterprise Architect, který má obě metodologie implementovány. Procesy jsou popsány slovním popisem, doplněné o diagramy. Na základě analýzy procesů je proveden návrh inovace, přičemž jedna inovace je navržena a implementována do fáze funkční webové aplikace. Správný chod každé firmy je zajisté docílen efektivním a přesným dodržováním všech nastavených podnikových procesů, proto je důležité mít všechny aktivity zadokumentovány a jejich vykonatelé (pracovníci) s nimi musí být důkladně seznámeni.

1.2

Cíl práce

Cílem této práce je namodelovat pomocí obou zmíněných přístupů reálné procesy v představené společnosti, tyto procesy popsat a provést hodnocení jejich efektivity. Dalším bodem je návrh inovace, včetně její implementace. Konkrétně se bude jednat o informační systém pro správu požadavků na interní IT oddělení ve společnosti. Pro modelování bude využito CASE nástroje Enterprise Architect verze 9.0, který byl vyvinut společností Sparx Systems. V diskuzní části budou porovnány oba přístupy k procesnímu modelování a bude provedeno ekonomické zhodnocení inovací.

2

2

PROCESNÍ MODELOVÁNÍ A PODNIKOVÁ ARCHITEKTURA

8

Procesní modelování a podniková architektura

Jak uvádí Lankhorst, pojem podniková architektura lze chápat z několika možných pojetí. Pokud se na ni podíváme z hlediska managementu, je možné na architekturu nahlížet jako na pyramidu, kde na vrcholu pyramidy je poslání podniku, vize stanovuje, kam podnik chce směřovat do budoucna, strategie formuluje, jak dosáhnout poslání a vizí podniku. Strategie je rozložena do dílčích konkrétních cílů kde se do hry dostává podniková architektura. (Lankhorst, 2005) Na tomto místě je vhodné uvést definici pojmu architektura dle IEEE standardu 1471-2000 (IEEE, 2000): Architektura je základní organizace systému zahrnující komponenty, jejich vzájemné vztahy, vztahy k okolí a je základem vedoucím k jejímu návrhu a evoluci. Podle [Tog2002] podnik definujeme jako organizovanou kolekci struktur, které mají společnou sadu cílů a/nebo jedinou základní linii. Spojením obou definicí lze specifikovat podnikovou architekturu jako koherentní celek principů, metod a modelů, které jsou použity v návrhu a realizaci podnikové organizační struktury, podnikových procesů, informačních systémů a infrastruktury. (Rábová, 2008)

Obrázek 1: Podniková architektura a řízení podniku (Lankhorst, 2005) (zdroj: Rábová, 2008)

Podniková architektura je typicky používaná jako nástroj při řízení každodenních operací a při vývoji společnosti do budoucna. Jedním ze způsobů efektivního řízení podniků je procesní řízení, kterým se zabývá následující kapitola.

2.1

2.1

Procesní řízení organizace

9

Procesní řízení organizace

S procesy se setkáváme v každodenním chodu firem a institucí. Z definice dle Řepy podnikovým procesem zpravidla rozumíme objektivně přirozenou posloupnost činností, konaných s úmyslem dosažení daného cíle v objektivně daných podmínkách. Podstatným faktorem u procesů je čas. Z definice dále k procesu neodmyslitelně patří čas, úmysl, se kterým je proces vykonáván, objektivní přirozenost postupu a objektivně dané podmínky. V této návaznosti se pod pojmem procesní řízení rozumí řízení firmy takovým způsobem, v němž podnikové procesy hrají klíčovou roli. Nezbytným základem pro procesní řízení je především pochopení základní logiky byznysu ve vazbě na strategické hodnoty organizace. Na základě takto poznaných řetězců činnosti je možné určit základ pro fungování celé firmy. (Řepa, 2012) Každá organizace funguje v jistém prostředí, které určuje smysl existence organizace. U tržních firem se pro toto prostředí používá pojem trh. Primární funkcí každé organizace je dosahování cílů, jež leží v prostředí, jinými slovy, co poskytuje svému okolí. Aby organizace mohla naplňovat svou primární funkci, musí vykonávat podnikové procesy, které tvoří základní obsahovou strukturu fungování organizace. U normálně fungujících podniků jakákoliv změna strategických hodnot nebo podmínek okolí má za následek změnu v obsahu nebo struktuře podnikových procesů. Informační systém v podniku a organizační struktura slouží jako prostředek k podpoře podnikových procesů. Existuje řada nejrůznějších klasifikací podnikových procesů. Jedna z možných klasifikací podle Řepy je rozdělení procesů na: • procesy klíčové – přímo naplňují primární funkci organizace, probíhají napříč celou organizací. Význam klíčového procesu je odvozen přímo od primární funkce organizace; • procesy podpůrné – jsou odvozeny od klíčových procesů, mají obecnější charakter. Měly by být co nejobyčejnější a nejefektivnější, které lze případně nakoupit jako služba a bylo by možné je vyčlenit outsourcingem;

2.2

Informační modelování organizací

Základním úkolem v budování procesně řízené organizace je potřeba zmapovat procesy v organizaci, klasifikovat je a vytvořit model dané společnosti. K tomu složí informační modelování organizací jako základní způsob systematického poznávání klíčových aspektů organizace. Tyto modely lze použít pro analýzu efektivity podnikových procesů či jako prostředek k navržení změn ve fungování organizace jako celku – tzv. reengineering. V dnešní době lze využít prostředků informačních technologií k podpoře modelování, které jsou nejčastěji označeny zkratkou CASE (Computer Aided Systems Engineering). Základními principy informačního modelování

2.2

Informační modelování organizací

10

organizací jsou Modelování a Abstrakce. Model znamená: • formální vyjádření zkoumaného jevu (systému) sloužící jako vyjádření skutečnosti. • Zjednodušené zobrazení určitého jevu (systému) pomocí vhodných zobrazovacích prostředků znázorňujících pouze ty rysy, jež jsou podstatné z hlediska cíle, který při konstrukci modelu sledujeme. • Reprodukce charakteristik určitého objektu na objektu jiném, zvláště vytvořeném pro jejich studium. Abstrakce znamená: • Myšlenkový proces odlučující odlišnosti a zvláštnosti a zjišťující obecné a podstatné vlastnosti předmětů a jevů okolní skutečnosti a vztahy mezi nimi. • Nepřihlížení k něčemu (záměrná, vědomá nekonkrétnost). (Řepa, 2012) Předměty zkoumání jsou v podniku dva: objekty (z čeho se systém skládá) a procesy (co se v systému děje). Základní způsoby pohledu na zkoumaný systém jsou také dva: globální (pohled na systém jako celek) a detailní (pohled na detaily části systému). Model objektů sleduje základní stavební kameny, z nichž realita sestává, tj. objekty a jejich atributy. K těmto popisům existuje specifický diagram tříd z jazyka UML. Model věcných procesů sleduje specifické řazení akcí v realitě do věcných procesů. K tomuto popisu je zapotřebí procesní diagram. Cílem modelu podnikových procesů je postihnout chování reality v termínech akcí a jejich vzájemných časových návazností v závislosti na událostech a stavech procesů. (Řepa, 2012)

Globální a detailní pohled Globální a detailní model tvoří sice na sebe navazující, ale zcela odlišné pohledy na zkoumanou problematiku. Hlavním důvodem k tomuto rozdělení je rozdělení zkoumané problematiky na méně složité části. Cílem globálního pohledu je především úplnost. Tento pohled bývá nadčasový, zaměřený na existenci prvků a jejich vztahů, zatímco detailní je časový a zaměřený na postup dění v systému. Kombinací obou modelů dostáváme celkem čtyři různé modely: • Globální model systému procesů se popisuje v Erikson-Penkerově notaci, což je specializace, tzv. doménové rozšíření objektového modelu (Erikson, 2000)

2.2

Informační modelování organizací

11

pro potřebu modelování systému procesů. Vybrané koncepty UML jsou zde specializovány k tomu, abychom jimi popisovali systém procesů, tedy existenci jednotlivých procesů a jejich typových atributů a typové vztahy mezi nimi. • Detailní model průběhu procesu se popisuje v procesním diagramu, čili v diagramu určeném pro popis průběhu procesu. Je zde na výběr několik existujících notací. Významné místo zaujímá jazyk BPMN (Business Process Modelling Notation (BPMI, 2011)). BPMN je oborovým standardem pro modelování průběhu procesu. Tento jazyk je blíže popsán v této práci. • Globální model systému objektů se nejčastěji popisuje v diagramu tříd, jenž je základním diagramem jazyka UML [Uml2011] a je oborově plně respektovaným standardem pro konceptuální modelování. • Detailní model objektu se popisuje ve stavovém diagramu jazyka UML, který je určen k popisu stavů objektů a přechodů mezi nimi a v jazyce UML je propojen s diagramem tříd.

3

MOŽNOSTI MODELOVÁNÍ SYSTÉMŮ

3

12

Možnosti modelování systémů

Nyní se podíváme na možné technologie a metodologie, které slouží k modelování systémů.

3.1

UML

Jazyk UML (z ang. Unified Modeling Language) je unifikovaný univerzální modelovací jazyk pro vizuální modelování systémů. Nejčastěji je využíván pro modelování objektově orientovaných systémů, ale má i mnohem širší využití, což vyplývá z jeho zabudovaných rozšiřovacích mechanismů. Byl navržen, aby spojil nejlepší existující postupy modelovacích technik a softwarového inženýrství. Jako takový je explicitně navržen takovým způsobem, aby jej mohly implementovat nástroje CASE (z ang. Computer-aided software engineering). Jazyk UML nenabízí žádný druh metodiky modelování, nýbrž poskytuje pouze vizuální syntaxi, kterou můžeme využít při modelování. Naopak Unified Process již metodikou je. Sděluje, jaké pracovníky musíme využít, jaké činnosti vykonat a jaké produkty vyrobit, aby se podařilo vytvořit model funkčního softwarového systému. Jazyk UML není vázán na žádnou specifickou metodiku, nebo životní cyklus. Lze jej použít společně se všemi existujícími metodami. (Arlow, 2008) Mezi dva hlavní aspekty modelu UML patří: – Statická struktura – popisuje, jaké typy objektů jsou pro modelování daného systému důležité a jak tyto objekty spolu souvisejí a – dynamické chování – popisuje životní cyklus objektů a způsob jejich vzájemné spolupráce s cílem dosáhnout požadované funkce navrhovaného systému. Struktura jazyka obsahuje tyto tři hlavní součásti: – Stavební bloky. Jsou to základní prvky modelu, relace a diagramy. – Společné mechanismy. Obecné způsoby, jimiž se v jazyku UML dosahuje specifických cílů. – Architektura. Pohled v jazyku UML na architekturu navrhovaného systému. Pohledy jsou konkretizovány v následujících typech diagramů. 1. Diagram tříd – představuje statický pohled na modelovaný systém, jeho úkolem je znázornit typy objektů v systému a jejich vztahy. Tento diagram je jedním z prvních a základních kroků analýzy navrhovaného systému. Hlavními prvky používanými v diagramu tříd jsou třídy, asociace, rozhraní, případně balíčky. Třída je abstrakcí objektů se stejnými vlastnostmi,

3.1

UML

13 stejným chováním a stejnými vztahy k ostatním objektům. (Buchalcevová, 2007)

2. Objektový diagram – je snímkem objektů a jejich vztahů v systému v určitém časovém okamžiku. Z důvodu, že zobrazuje instance tříd, je také nazýván diagramem instancí. Používá se především pro znázornění určité konfigurace objektů či zobrazení vzájemně propojených objektů ve speciálních situacích. Svou notací se podobá diagramu tříd či komunikace a obvykle obsahuje pouze objekty a spojení mezi nimi. 3. Diagram balíčků – umožňuje sdružit elementy modelů UML do skupin a mezi těmito skupinami (balíčky) vytvořit závislosti. Diagram balíčků je tvořen balíčky a závislostmi mezi nimi. (Fowler, 2003) 4. Diagram komponent – zobrazuje komponenty, které tvoří aplikaci, systém nebo podnik. Komponentami se rozumí modulární součásti systému se zapouzdřeným obsahem. Diagram komponent znázorňuje komponenty a závislosti mezi nimi, popřípadě i rozhraní. Komponenty mohou obsahovat atributy a metody. 5. Diagram vnitřní struktury – umožňuje znázornit interní strukturu komplexního prvku a zobrazit spolupráci tohoto prvku neboli klasifikátoru s ostatními prvky v systému. Části reprezentují jednu nebo více instancí. Port vyjadřuje externě viditelnou součást klasifikátoru. Kolaborace vyjadřují určitou funkcionalitu systému a jsou s ostatními prvky diagramu propojeny pomocí konektorů a asociací. 6. Diagram nasazení – ukazuje rozložení jednotlivých softwarových komponent na hardwarových zdrojích (uzlech) a jejich spolupráci. Používá se pro specifikaci fyzické architektury systému. Základním prvkem tohoto diagramu jsou tzv. uzly, které jsou vzájemně propojeny komunikačními cestami. (Buchalcevová, 2007), (Arlow, 20008) 7. Diagram případů užití – z ang. Use Case Diagram, používá se k popisu chování systému z hlediska uživatele a zachycuje, které typy uživatelů a jak se systémem pracují a jaké vykonávají v rámci systému činnosti. V první etapě procesu tvorby softwaru je specifikace softwarových požadavků, které mohou být buď funkční anebo nefunkční. Případy užití zachycují pouze funkční požadavky, které určují, jaké chování by měl navrhovaný systém nabízet. Nefunkční požadavky nejsou tímto diagramem zachyceny, proto je nutné doplnit model případů užití i modelem požadavků, který není součástí standardu UML. Mezi prvky tohoto diagramu patří Aktér, který popisuje uživatele systému, který je s ním v interakci. Případ užití podle Buchalcevové specifikuje část funkcionality systému, kterou využívá aktér a která plní určitý cíl. Je charakterizován množinou scénářů a případů užití. Vztahy mezi aktéry a případy užití jsou nazvány relací. Existují tři

3.1

UML

14 typy vztahů: include (při opakování stejného případu užití na více místech), extend (nadstandardní případ užití při splnění dané podmínky) a generalizace či specializace, využití nachází při znázornění předků či potomků aktéra. Hranice systému lze ohraničit rámečkem kolem případů užití s názvem systému.

8. Diagram aktivit je dalším významným diagramem. Užívá se pro popis procedurální logiky, business procesů či pracovních postupů. Umožňuje také graficky modelovat jednotlivé případy užití jako posloupnost akcí. 9. Stavový diagram – podle definice zachycuje jednotlivé stavy objektu a přechody mezi nimi. (Buchalcevová, 2007). Stavové diagramy se používají pro popis chování určitého objektu napříč více případy užití. Základními prvky tohoto diagramy jsou stavy, přechody a události. 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, 2004) Přechody představují podmínky pro přechod objektu z jednoho stavu do druhého. Událost specifikuje určitý výskyt něčeho v čase a prostoru. (Arlow, 2008) 10. Sekvenční diagram – zachycuje grafický průběh zpracování v systému v podobě zasílání zpráv a spolupráci jednotlivých objektů v rámci jednoho případu užití. 11. Diagram komunikace – zachycuje instance tříd, jejich vzájemné vztahy a tok zpráv, které mezi nimi probíhají. 12. Diagram přehledu interakcí lze charakterizovat jako diagram, který zachycuje tok řízení uvnitř systému nebo procesu. Tento diagram dokáže srozumitelně a přehledně znázornit větvení i souběžnost. 13. Diagram časování – umožňuje modelovat systémy, pracující v reálném čase, ukazuje změny stavu, podmínky objektu nebo role ve vztahu k času. Může být zaměřen na jeden objekt nebo skupinu objektů.

3.1

UML

Obrázek 2: Ukázkový diagram případů užití (zdroj: vlastní práce)

Stavový diagram může vypadat například takto:

Obrázek 3: Ukázkový stavový diagram

15

3.1

UML

16

Erikson-Penker Celkový globální pohled na systém procesů lze použít tzv. Erikson-Penkerovu notaci, která vznikla jako specializace diagramu tříd jazyka UML. Pro svou obsahovou kvalitu, komplexnost a praktickou použitelnost se Erikson-Penkerův profil stal nejpoužívanějším. Tento profil UML je založen na čtyřech základních pohledech na organizaci: • Strategický pohled (vize organizace) – zahrnuje klíčové pojmy – hodnotu firmy a její strategické cíle. Zaměřuje se na hlavní problémy a úmysly, které mají být změnou procesu ovlivněny. • Procesní pohled – zahrnuje podnikové procesy, činnosti ve firmě a její hodnoty. Popisuje vzájemnou interakci procesů a využívání zdrojů za účelem naplnění strategických cílů definovaných ve vizi podniku. • Strukturní pohled – popisuje strukturu organizace a její zdroje jako jsou organizační jednotky, produkty, dokumenty, informace, znalosti atd. • Chování organizace – zahrnuje nejen vnitřní chování, ale i interakci mezi jednotlivými prvky organizace (zdroje a procesy). Jedním z nejdůležitějších cílů analýzy interakcí je přiřazení zodpovědnosti za jednotlivé zdroje. V rámci těchto pohledů je v Eriksonově notaci definováno několik stereotypů a omezení: • procesy – podnikové procesy, činnosti, procesní toky, rozhodovací body; • zdroje procesů, událostí, cílů; • pravidla pro řízení procesů; • cíle procesů, vzájemné souvislosti, problémy a jiné.

Obrázek 4: Elementy modelu podnikového procesu podle H.Eriksona

3.2

3.2

BPMN 2.0

17

BPMN 2.0

Diagram procesu modeluje průběh jednoho podnikového procesu. Průběhem procesu je kombinací logiky postupu dosažení příslušného cíle procesu a vlivu okolních procesů, s nimiž se musí synchronizovat. Jako základní notaci pro diagram procesu používá metodika standard BPMN. Business Process Modeling Notation, od verze 2.0 Business Process Model and Notation, je grafická notace (soubor objektů a pravidel, podle nichž mohou být spojovány mezi sebou), která je přibližně od roku 2005 všeobecně přijatým oborovým standardem pro modelování business procesů. Za vznikem stojí iniciativa BPMI (Business Process Management Initiative), jejímž primárním cílem bylo v tomto případě vytvořit notaci čitelnou pro všechny účastníky životního cyklu procesu a tím zmenšit komunikační mezeru mezi návrhem a implementací procesu. Cílem byla jednoduchá a pochopitelná notace, umožňující modelovat i komplexní business procesy. Zápis by měl poskytnout potřebné informace všem zainteresovaným osobám v organizaci (podnikový analytik, technický vývojář, podnikový manažer). Použití notace BPMN je omezeno pouze na podnikové procesy. Diagramy neprocesního charakteru jsou mimo možnosti jazyka BPMN, ale k tomu dobře poslouží výše popsaná metodika UML. Rozeznáváme čtyři základní kategorie elementů: Flow objects (tokové objekty) – jedná se o objekty, které souvisí s tokem informací v procesu. • Událost – reprezentována křížkem a vyjadřuje, že se něco odehrálo v průběhu podnikového procesu. Rozeznáváme počáteční, průběžnou a koncovou událost.

• Aktivita – je vyjádřena obdélníkem se zaoblenými rohy. Vyjadřuje dílčí pracovní aktivitu, kterou podnik vykonává.

• Gateway (brána) – značí se čtvercem, či kosočtvercem, označuje větvení či souběh toků procesu.

3.2

BPMN 2.0

18

Connecting objects (spojovací objekty) – jsou spojené dohromady v diagramu a tvoří základní kostru struktury podnikového procesu. Tyto konektory jsou: • Sekvenční tok – vyjádřen nepřerušovanou čárou s vyplněnou šipkou, určuje pořadí vykonávaných aktivit.

• Tok zpráv – přerušovaná čára s prázdnou šipkou, znázorňuje tok zpráv mezi dvěma účastníky procesu.

• Asociace – přerušovaná čára, umožňuje spojit objekt s nějakou dodatečnou informací.

Artefakty – jsou to prostředky pro vyjádření upřesňujících informací pro proces, které nemají vliv na jeho tok. • Datový objekt – značí se obdélníkem s přehnutým rohem a reprezentuje data, se kterými pracují aktivity.

• Seskupení – obdélník s přerušovanou čárou, vyjadřuje seskupení aktivit z analytických nebo dokumentačních důvodů, ale nemá vliv na sekvenční tok.

• Poznámka – text, spojený asociací s jiným grafickým objektem poskytující dodatečnou textovou informaci.

3.3

CASE nástroje

19

Plavecké dráhy – umožňují organizovat aktivity do oddělených vizuálních kategorií za účelem ilustrace různých funkcionalit či odpovědností. • Pool – ohraničuje proces a reprezentuje účastníka procesu, komunikace mezi jednotlivými pooly probíhá pomocí zpráv.

• Dráha – podmnožina poolu, uspořádá a třídí aktivity, komunikace mezi dráhami probíhá sekvenčním tokem.

[Bpm2008] Následující obrázek znázorňuje nejčastěji používané elementy v diagramu.

Obrázek 5: Nejčastěji používané elementy (zdroj: http://bpm-sme.blogspot.fr/2008/03/3uvod-do-bpmn.html)

3.3

CASE nástroje

Zkratka CASE (z ang. Computer Aided Software Engineering, Computer Aided Systems Engineering) označuje souhrnně nástroje, které podporují vývoj softwarových aplikací. Těchto nástrojů je velmi mnoho a jsou klasifikovány do několika tříd. Existují nástroje, které podporují strukturované i objektově orientované metody vývoje. Nástroje CASE umí zajistit souvislosti, které člověk neumí pojmout. Jedná se o integrovanou sadu programů, které podporují úlohy prováděné při vývoji software automatizovaným způsobem a užívají centrální databázi s uloženými technickými,

3.3

CASE nástroje

20

organizačními a dalšími informacemi potřebnými pro výstavbu a údržbu projektu IS. V závislosti na životním cyklu vývoje aplikace je možné následující členění CASE nástrojů: • Pre CASE – podpora pro tvorbu globální strategie; • Upper CASE – podpora plánování, specifikace požadavků a modelování organizace podniku. Použité nástroje jsou DFD (Data Flow Diagram) a ERD (Entitně-Relační Diagram) v jednoduché formě; • Middle CASE – detailnější specifikace požadavků a vlastní návrh systému. Tyto nástroje se používají pro podrobnou specifikaci požadavků, návrh systému, dokumentaci a vizualizaci systému. Využívají podrobných DFD a ERD diagramů, pro objektové metodiky diagramy tříd, instance a přechodové diagramy. • Lower CASE – podporují fyzickou realizaci systému díky nástrojům pro podporu kódování, testování, údržby. Integruje generátory kódu, prostřední pro reverse engineering1 • Post CASE – prostředky této kategorie přímo podporují organizační činnosti (zavedení, údržba a rozvoj IS). (Procházka, 2004) Sparx Systems - Enterprise Architect Pro tvorbu modelů v této diplomové práci byl využit software SPARX Enterprise Architect verze 9.0. Enterprise Architect je CASE nástroj pro tvorbu modelů založený na syntaxi UML 2.3. Nabízí kvalitní a výkonné vizuální prostředí pro řízení požadavků, strategické modelování, modelování podnikových procesů, návrh podnikové architektury a systémovou analýzu. Další významnou funkcí je podpora vývoje – generování kódu, testování, nasazení a mnoho dalších, které usnadňují práci. Integrována je podpora správy požadavků a pomáhá sledovat jednotlivá konkrétní zadání k jejich analytickým, designovým a implementačním modelům. Umožňuje nativní využití UML, SysML, BPMN a dalších jazyků založených na otevřených standardech. 1

Reverse engineering – technologie pro rekonstrukci dokumentace a modelů z již existujícího softwaru.

3.3

CASE nástroje

21

Obrázek 6: Vývojové prostředí Enterprise Architect 9.0 (zdroj: http://enterprisearchitect.en.softonic.com/

4

DALŠÍ TEORETICKÁ VÝCHODISKA

4

22

Další teoretická východiska

Následující kapitola popisuje další pojmy, se kterými by měl být čtenář dále seznámen.

4.1

E-commerce

E-commerce z anglického „Electronic commerce“ je typ obchodování, kde prodej a nákup zboží a služeb je veden přes elektronické a komunikační systémy jako je internet a další počítačové sítě. Nosnými prvky e-commerce jsou: • mobilní obchodování, tj. doručení obchodních nabídek přímo do rukou zákazníka kdykoliv prostřednictvím bezdrátových technologií; • elektronické transakce; • řízení dodavatelských řetězců – SCM (z ang. Supply Chain Management). Označení pro činnost dodavatelského řetězce, ale i software pro podporu této činnosti. Obvykle celý balík programových prostředků, propojující jednotlivé články dodavatelského řetězce (dodavatel – výrobce – distributor – prodejce – zákazník) a tím zlepšení schopnosti reakce na požadavky zákazníka např. zkrácením časů dodání zboží a služeb. SCM je v současnosti jedním z modulů komplexních podnikových informačních systémů ERP; • Internetový marketing, také e-marketing, zahrnuje veškeré marketingové aktivity, které probíhají prostřednictvím elektronických zařízení (kromě TV a rádia). Patří zde internetový marketing, mobilní marketing (mobilní telefony, tablety, PDA), position marketing (GPS, auto-navigace), online TV. Marketing na internetu je kvalitativně nová forma marketingu, která může být charakterizována jako řízení procesu uspokojování lidských potřeb informacemi, službami nebo zbožím pomocí internetu. (Nondek, 2000) Alternativní definice je marketing, který se odehrává ve specifickém prostředí internetu a vychází ze všech praktik klasického marketingu. Nástroje, které využívá, jsou v užším pojetí pouze internetová reklama a vlastní webové stránky. V širším pojetí pak i další nástroje marketingových komunikací, které se na internetu také uplatňují: online public relations, online direct marketing a podpora prodeje na internetu [Mer2013]; • online zpracování transakcí – OLTP (z ang. Online Transaction Processing) je technologie uložení dat v databázi, která umožňuje do nejsnadnější a nejbezpečnější modifikaci ve víceuživatelském prostředí. V současné době se využívá v převážné většině databázových aplikací; • elektronická výměna dat – EDI (z ang. Electronic Data Interchange) je výměna strukturovaných zpráv mezi počítači, respektive mezi počítačovými aplikacemi.

4.2

Středisko sdílených služeb

23

Data jsou strukturována podle standardů a následně elektronicky a automaticky přenášena bez účasti člověka. Běžně se EDI rozumí specifické metody výměny zpráv, dohodnuté na úrovni národních nebo mezinárodních standardizačních společenství pro přenosy dat o obchodních transakcích. Vedle strukturovaného formátu XML, Internetu a protokolu WWW je EDI stále nejpoužívanější datový formát pro elektronické obchodní transakce na světě; • systémy pro elektronickou správu majetku; • systémy pro automatizovaný sběr dat. Moderní e-commerce systémy využívají World Wide Web minimálně v jednom bodě životního cyklu obchodování, avšak může zahrnovat i jiné komunikační kanály, jako je elektronická pošta, mobilní zařízení, telefony a v neposlední řadě také sociální sítě.

4.2

Středisko sdílených služeb

Zakládání středisek sdílených služeb (z ang. Shared Service Center) pod zkratkou SSC je v dnešní době cestou ke zvýšení výkonnosti společnosti. Využíváním tohoto modelu je jednou z cest k dosažení snížení nákladů u velké řady podnikových procesů a zvýšení efektivity společnosti. Důvodem vzniku jsou vysoké transakční náklady, nekonzistentní úroveň služeb, duplicita v organizaci a zvýšení hodnoty společnosti. Střediska sdílených služeb se začala rozvíjet v 80. letech, kdy převládal jeden velký centrální útvar, který se věnoval řízení podnikání stejně jako o podpůrné služby, přípravu a realizaci strategie. V průběhu 90. let se začaly jednotlivé oblasti podnikání vyčleňovat a byly zakládány tzv. Business Strategic Unit, které byly odpovědné za určitou část podnikání, docházelo tedy k duplikaci infrastruktury jednotlivých SBU. V posledním desetiletí převládá trend vyčleňovat infrastrukturu jednotlivých SBU a dochází k vytváření středisek sdílených služeb, jejichž úlohou je umožnit strategickým jednotkám soustředit se na klíčové aktivity podnikání a nestarat se o podpůrné aktivity. Aktivity vhodné pro střediska sdílených služeb jsou především transakčního charakteru, tzn. stále se opakující aktivity bez potřeby rozhodnutí, a které je možné zautomatizovat. Možné aktivity jsou znázorněny v následující tabulce. (Brabec, 2005)

4.3

SEO - Search Engine Optimization

24

Obrázek 7: Aktivity centra sdílených služeb (zdroj: Brabec, 2005)

4.3

SEO - Search Engine Optimization

Zkratka SEO pochází z anglického Search Engine Optimization, tedy optimalizace pro vyhledávače. Vyhledávače jako Google, či Seznam využívají postupů, které určují relevanci webu ve vztahu k vyhledávanému výrazu. Hledáte-li například sousloví „optimalizace pro vyhledávače”, vyhledávač najde ve své databázi všechny stránky, které tuto frázi obsahují a interně si je ohodnotí. Ty, které mají největší hodnotu, poté zobrazuje jako první a ty s menší hodnotou pod nimi. To je podstata optimalizace pro vyhledávače. Obecně je to řada úkonů a operací, jejichž cílem je především, zlepšení pozic ve fulltextových vyhledávačích = zásadní zlepšení návštěvnosti cílovou skupinou zákazníků. SEO optimalizace je dnes základem úspěchu webových stránek. [Seo2013]

4.4

Použité technologie

Výsledná aplikace bude vytvořena ve skriptovacím jazyce PHP a data jsou uložena v databázi MySQL. PHP: Hypertext Preprocessor PHP je skriptovací jazyk pro vytváření dynamického webu a jeho počátky se datují do roku 1994. Během vývoje došlo k uvedení několika verzí. V současné době je uveden ve verzi 5.4. Tento skriptovací programovací jazyk je určený zejména pro programování dynamických internetových stránek a webových aplikací například ve formátu HTML, XHTML či WML. Při využití PHP jsou vytvořené skripty prováděny na straně serveru a uživateli je poté přenášen výsledek. Interpret skriptů je možné

4.4

Použité technologie

25

volat pomocí příkazového řádku, dotazovacích metod technologie HTTP či prostřednictvím webových služeb. Výhodou tohoto jazyka je podpora mnoho knihoven pro různorodé účely jako např. pro práci se soubory, přístup k většině databázových systémů (MySQL, Oracle, PostgreSQL, MS SQL) i mnoha dalších internetových protokolů. Jedná se o velmi rozšířený jazyk díky jednoduchosti použití a dostatečným funkčním možnostem. V kombinaci se systémem Linux, databázovým serverem a webovým serverem Apache je využíván nejčastěji k tvorbě sofistikovaných aplikací. (Lacko, 2001) Databázový systém MySQL Pro účely uložení dat je využita technologie databázového serveru MySQL, který je dostupný pod licencí GPL, tedy svobodný systém. Existuje i komerční placená licence, která poskytuje větší možnosti podpory aj. Komunikace s databází probíhá pomocí standardizovaného dotazovacího jazyka SQL pro práci s daty v relačních databázích. V MySQL je použit jeden z dialektů tohoto jazyka s některými rozšířeními. Architektura MySQL serveru má široký záběr a je rozdělena do několika abstraktních vrstev. Vrstva nejvíce nahoře poskytuje služby, které jsou společné pro ostatní databázové systémy a obsluhují zejména nástroje potřebné pro architekturu klient/server. Ve druhé vrstvě se nachází funkce pro logiku parsování (rozbor), analýzu, optimalizaci a ostatní funkce. Třetí vrstva obsahuje úložné enginy, které mají za úkol ukládání a získávání všech dat uložených v MySQL. Server komunikuje s úložnými enginy prostřednictvím API úložných enginů. Úložné enginy nedělají rozbor SQL kódu, ale pouze odpovídají na požadavky serveru. (Lacko, 2001) Pro správu objektů v MySQL je využit programový systém phpMyAdmin prostřednictvím webového rozhraní, který umožňuje efektivní manipulaci s databází.

5

PŘEDSTAVENÍ SPOLEČNOSTI

5

26

Představení společnosti

Tato kapitola si klade za cíl seznámit blíže čtenáře s podnikem, ve kterém jsou diagramy modelovány. Nejprve je představen koncern, poté se zaměřuji na společnost Pixmania, s.r.o., která je jeho součástí.

5.1

DIXONS RETAIL, PLC.

Společnost Dixons Retail plc. je jednou z největších a nejsilnějších skupin pro velkoobchodní a maloobchodní prodej elektroniky. Zaměřuje se na prodej spotřební elektroniky, domácích spotřebičů, fotografického vybavení, komunikační techniky a s tímto spojených služeb. Vlastní více než 1200 obchodů a obchoduje taktéž pomocí elektronického obchodování. Obsluhuje trhy 28 zemí a zaměstnává celkem 36500 zaměstnanců. Dominuje na trzích Velké Británie, Irska, Skandinávie a Řecka. Na obrázku níže je vyobrazena struktura značek, které spadají do skupiny Dixons Retail. V České republice provozuje koncern Dixons Retail maloobchodní společnost Electroworld, která provozuje 23 obchodů na území České a Slovenské republiky. Dva obchody včetně centrálního skladu firmy se nacházejí právě v Brně. [Dsg2013]

Obrázek 8: Struktura obchodních společností koncernu DSG

5.2

PIXMANIA, s.r.o., Brno

Společnost Pixmania, s.r.o. byla zřízena v Centru sdílených služeb koncernu Dixons Retail, které zde svoji činnost provozuje od roku 2007 a poskytuje širokou škálu finančních služeb a služeb zákazníkům pro své maloobchody ve Velké Británii, Irsku, Skandinávii a rovněž internetovým obchodům v Evropě. Zápis společnosti do Krajského soudu v Brně proběhl dne 1. března 2011. Společnost sídlí na ulici Trnitá 491/5 v budově Triniti Office Centre. Předmětem činnosti dle zápisu v KS je výroba, obchod a služby neuvedené v přílohách 1 až 3 živnostenského zákona. Centrála

5.2

PIXMANIA, s.r.o., Brno

27

společnosti sídlí ve francouzském hlavním městě Paříž. Společnost zaměstnává okolo 1400 zaměstnanců, z toho okolo 200 pracovníků v centru sdílených služeb v Brně. Společnost je zastoupena generálním ředitelem Philem Birbeckem.

Obrázek 9: Budova Triniti Office Center, sídlo společnosti. Zdroj: http://www.triniti.cz

Počátky působení firmy se datují od roku 1970, kdy se skupina vyvíjela v činnosti online a offline prodeje výrobků a služeb spojených s digitální zábavou. V současné době má společnost okolo 9 milionů zákazníků, okolo 120 000 druhů výrobků a zákaznický servis v 17 světových jazycích. Spravuje 65 internetových portálů. Elektronický obchodu Pixmania.com nabízí následující portfolio produktů: • Fototechnika, videokamery a příslušenství – Digitální fotoaparáty – Fotografické příslušenství – Blesky – Foto rámečky – Tradiční fotoaparáty – Digitální videokamery • Televizní technika, zvuková a video zařízení – Televizory – DVD a Blu-Ray přehrávače

5.2

PIXMANIA, s.r.o., Brno

– Domácí kina – Videoprojektory – DVB-T a satelitní přijímače – MP3/MP4 přehrávače – Tablety, iPad – Hi-fi systémy – Sluchátka – Ozvučení – Diktafony • Výpočetní technika – Notebooky, netbooky – Stolní počítače, počítače Apple – Monitory – PC komponenty – Software – Periferní zařízení a kancelářské potřeby • GPS zařízení a autopříslušenství • Mobilní telefony • Videohry • Hry a hračky pro děti • Domácí potřeby, potřeby pro kutily a zahrádkáře • Elektrospotřebiče • Móda a zavazadla – galanterie – kosmetika • Sportovní potřeby

28

5.2

PIXMANIA, s.r.o., Brno

29

Platforma E-merchant

Platforma E-merchant spadá pod společnost Pixmania. Jedná se o komplexní systém procesů pro úspěšné obchodování. Toto uskupení pokrývá velký rozsah e-commerce procesů podle individuálních potřeb klientů, včetně vytváření a hostování elektronických obchodů a dalších služeb. Služby této platformy jsou nabízeny a využívány komerčními zákazníky. Platforma Platforma e-merchant je plně integrovaná, dávající klientům plnou kontrolu nad ecommerce aktivitami. Je vyvinuta na základě všech zkušeností společnosti Pixmania jakožto vůdčí online retailovou společností v Evropě a integruje pět hlavních oblastí aplikací: • Správa portfolia produktů – Výhodou možnost volby odpovědnosti dodavatele služeb za tvorbu nabídky produktů. – Maximalizace přidané hodnoty za účelem zlepšení prezentace vlastních produktů a služeb. – Komerční podpora během celého životního cyklu produktů, od nasazení až po konec životnosti. – Rozšíření působnosti obchodních aktivit díky mezinárodní, vícejazyčné podpory platformy a schopnosti rozlišit B2B a B2C aktivity. Tato oblast zahrnuje kompletní správu nabídky, kategorizaci produktů, kombinace produktů, nahrazování alternativními výrobky a správu pro produkty, které jsou na konci životnosti (čištění skladů, použitých výrobků). Rovněž zde lze jmenovat cenovou správu, konverzi měnových kurzů, předobjednávky a rezervování produktů. Rovněž podpora logistických procesů, využívání více skladů napříč různými zeměmi a v neposlední řadě daňovou správu a místní standardy. • Správa webových stránek – S touto platformou je možné vytvořit originální, atraktivní a dynamické webové stránky, které splňují kritéria klientských potřeb a mohou být snadno modifikovatelné uživateli. Administrátoři mohou využít modul Website Management pro přizpůsobení struktury webových stránek obsahu emailových sdělení v podporovaných jazycích. • Správa provozu webových stránek

5.2

PIXMANIA, s.r.o., Brno

30

– Dosažení velkého objemu zpracovaných požadavků ve velké rychlosti umožňuje uspokojení zákaznických potřeb a je důležité pro růst zisku obchodních společností. E-merchant poskytuje balík aplikací zaměřených pro optimalizaci provozu. • Správa objednávek – Uspokojení potřeb zákazníka a bezchybné zpracování přijatých objednávek je nezbytné pro naplnění jakéhokoliv obchodování v e-commerce sféře. Pomocí platformy lze soutěžit na mezinárodní scéně díky podpoře ve 26 zemích a podpoře 17 světovými jazyky. Existující rozhraní s více než 40 typy platebních metod a 27 místních a mezinárodních dopravců pomáhá úspěšnému a rychlému rozšíření obchodování. Díky modulu pro Správu objednávek dochází k optimalizaci při zpracování objednávek po celou dobu – od zadání objednávky až po její úspěšné zpracování. Tato služba je doplněna modulem Fraud Buster, který pomáhá striktní prevenci a detekci internetových podvodů díky systematické analýze (fraud). V součinnosti s Web Call modulem dociluje centralizované správě zákaznických požadavků přes web či telefonicky. • Reporting – Platforma nabízí přístup ke všem standardním ukazatelům výkonnosti v reálném čase. Toto je podpořeno neustálým monitoringem všech procesů, které probíhají v e-commerce operacích, sledováním prorůstových ukazatelů napříč všemi zeměmi, které pomáhají strategickým rozhodnutím. Mezi hlavní aspekty patří multidimenzionální analýza, tvorba reportů, modelů a sdílení mezi oprávněnými uživateli. Tato oblast je velmi významně podpořena nástroji BI (z ang. Business Intelligence). Služby Široký rozsah komplexních procesů je nezbytný pro úspěšné řízení jakéhokoliv obchodování přes e-commerce. Hlavními skupinami poskytovaných služeb je: • Strategie a podpora – E-merchant není pouze sprostředkovatel služeb, ale pracuje s klienty jako partner, s cílem uspět v e-commerce aktivitách. Klient dostává reporty a rady od zkušených konzultantů a má možnost delegovat část nebo celou agendu na E-merchant tým. Výhodou jsou zkušení účetní manažeři pro monitoring každodenních aktivit, poskytování analýz a doporučení pro zlepšení, studie kvality a systémové audity od konzultantů v oblasti účetnictví, obchodních aktivit, kvalitativních inženýrů, instruktorů, pracovníků BI a analytiků. • Merchandising2 2

Merchandising je forma marketingové podpory produktů v místě prodeje, jehož hlavní náplní

5.2

PIXMANIA, s.r.o., Brno

31

– Existuje několik výkladů slova merchandising. Lze jej definovat jako soubor činností směřovaných zejména k posledním článkům prodejního řetězce s cílem zajistit, že správně zboží se nachází na správném místě, ve správný čas a za správnou cenu. Merchandising lze rovněž chápat jako souhrn činností, jež jsou vykonávány v prostorách prodejen s cílem zlepšit všeobecnou vizualitu v místech vystavení produktů. Merchandising zahrnuje např. umístění zboží v regále, péče o místo prodeje (čistota, vyškolený personál), podpora prodeje (ochutnávky, akční stojany). – Merchandising tým je schopný pomoci se strukturou a propagací produktových katalogů pomocí organizace informací o produktech. Poskytuje pomoc s vytvářením obsahu webových stránek, specifikačních listů a překladů do formátu, kdy klient je schopný přidat produktové fotografie a videa. Rovněž poskytuje neustálý monitoring cen konkurence za účelem udržení strategické pozice na trhu. Tým transformuje informace z webových stránek přímo zákazníkům, tak aby nabízené výrobky byly atraktivní a za soutěživé ceny. Spolupracuje se s komerčními partnery, kteří dohlíží na kvalitu nabízených služeb. Výhodou této služby je zlepšení prodejních zkušeností s ohledem na zákazníky a snaha o neustálý růst nabídky za účelem tvorby zisku. Neustálá optimalizace obsahu stránek zvyšuje viditelnost a atraktivitu stránek a láká nové zákazníky a díky vícejazyčné podpoře zvýšení rozsahu pokrytých zemí. • Webová agenda – Interaktivní webová agenda umožňuje tvorbu e-commerce nabídky buď přímo klientem nebo ve spolupráci s agendou platformy E-merchant je možné zvládat každodenní administraci obsahu. Tato služba tvoří stránky podle nejlepších zkušeností v návaznosti na zákaznické specifikace. Agenda podporuje každý krok projektu, od vizuálního průvodce až po technologickou integraci. Cílem jsou dostatečně dynamické stránky atraktivní nejen pro stávající, ale i nové zákazníky. Nabízí spolupráci na akčních nabídkách a speciálních promo akcích. Výhodou této služby jsou webové stránky podle nejlepších zkušeností a trendů včetně nativní podpory optimalizace SEO, konstantně se vyvíjející stránky s dynamickým komerčním obsahem, poskytuje klientům více času se zaměřit na klíčovou strategii. • Online marketing – Zásadní oblast pro zvýšení obratu podnikání, možnost oslovit co nejvíce potenciálních zákazníků za přiměřené náklady a udržení stávajících zákazníků. Konzultanti pomáhají s rozdělením rozpočtu na marketingové aktivity, navrhují a spouštějí efektivní kampaně. je zajištění odpovídajícího stavu zásob, vystavení produktů a zvýšení atraktivity prodejního místa. [Mer2013]

5.2

PIXMANIA, s.r.o., Brno

32

• Řízení vztahů se zákazníky • Logistika • Hosting a podpora • Technická a technologická integrace Dále je integrován modul pro centralizovanou správu právních aspektů a rozhraní pro komunikaci s klientskými informačními systémy. [Eme2013] Struktura společnosti Organizační struktura společnosti je vyjádřena v nadcházejícím diagramu. Jednotlivé prvky jsou označeny stereotypem, který určuje o jaký prvek ve společnosti se jedná.

Obrázek 10: Organizační struktura společnosti

Brněnská pobočka v současné době zhruba 200 zaměstnanců na plný úvazek. V čele firmy je provozní ředitel, COO.3 3

COO – z ang. Chief Operating Officer, provozní ředitel společnosti. Obvykle mu přísluší odpovědnost za běžný denní chod ve společnosti.

5.3

5.3

Analýza procesů

33

Analýza procesů

Středisko Back office je částí společnosti, která je odstíněna od zákazníků. Obecně se zde provádí převážně procesy administrativní povahy jako je zpracování došlých objednávek, jejich zadávání do firemních informačních systémů a následné zpracování. Připravují se podklady pro fakturaci, dohledávají se špatně směrované platby, vyřizují se reklamace od klientů a zabezpečují se činnosti pro ostatní oddělení společnosti a evidence všech provedených operací. Proces je zachycen na následujícím diagramu.

Obrázek 11: Business Process Model: Back Office

Probíhá zde proces Transport, pracovníci vyšetřují poškozené, ztracené či zpožděné zásilky, zajišťují komunikaci mezi transportním týmem ve Francii a České

5.3

Analýza procesů

34

republice, zabývají se urgentními případy. Rovněž provádějí zaškolení a trénink nových zaměstnanců. Své činnosti shrnují ve formě měsíčních reportů svým koordinátorům. Dalším procesem je zde Price Benchmark. Pracovníci mají za úkol sběr a porovnávání cen zboží a služeb jako podklad pro budoucí finanční analýzy a určování cen vlastního zboží, prohledávání internetových stránek a katalogů konkurenčních společností v součinnosti s Benchmark týmem ve Francii. Poskytují denní report svému nadřízenému zaměstnanci. Proces Fraud prevention je zodpovědný za prevenci možného podvodného jednání, které by mohlo narušit bezpečnost obchodování mezi společností a zákazníky. Zaměstnanci vyžadují ke své práci znalost cizího jazyka, zejména francouzštiny a italštiny. Tato oblast je velmi komplexní a obecně se dá říci, že se jedná o detekci, odhalování a odstraňování následků podvodného jednání, které se objevuje v souvislosti s obchodováním přes internet. Analyzují a verifikují se zde objednávky, které byly vytvořeny prostřednictvím elektronického obchodu Pixmania.com, komunikuje se s přepravním týmem. Pracovníci kontaktují zákazníky objednávek velkého rozsahu telefonicky nebo emailem za účelem kontroly. Pokud zjistí podvodné aktivity, eskalují tyto případy nadřízenému a následně blokují objednávky podezřelé z podvodu. Činnosti procesu PixPro obsluhují nekoncové zákazníky společnosti PixmaniaPRO. Označení pro tento typ obchodů je B2B, business to business; jsou to obchodní vztahy mezi obchodními společnostmi, které neobsluhují konečné spotřebitele ve velkém měřítku. Klade se důraz na podporu logistických procesů a zajištění samotného obchodu, oproti důrazu na získání zákazníka, jak je tomu u typu B2C. Služby Pixmania-PRO jsou určeny především pro střední a malé firmy, velké společnosti, státní orgány, svobodné povolání, řemesníky, závodní výbory, asociace a kluby. Je zde možné obchodování ve velkém objemu, účtování v cenách bez DPH a rozšířené možnosti plateb. Pixplace – tento proces má na starost vývoj obchodů pro stávající obchodní partnery v závislosti na zemi, kde tato společnost působí. Typicky se soustředí na jednu či více zemí, převažuje B2B model. Zaměstnanci poskytují pravidelné výkazy práce svému nadřízenédmu na pravidelných jednáních a sestavují pravidelné reporty. Primární odpovědnost pracovníků spočívá v odpovídání a zpracování dotazů partnerů, získávání nových potenciálních prodejních případů a vyjednávání nových nabídek produktů, vyhledávání nových obchodních příležitostí, tvorba nových doporučení pro operativní strategii a navrhování možných zlepšení. Refund – proces zodpovědný za validaci zhruba 6000 požadavků/den na refundaci a návrat peněžních prostředků zpět směrem k zákazníkovi, který byl přímo či

5.3

Analýza procesů

35

nepřímo poškozen, zejména zneužitím jeho platební karty. Na tomto místě je dobré znázornit proces autorizace platební transakce při platbě kartou. Při autorizaci dochází k součinnosti obou stran platební transakce a po schválení k následné expedici zásilky, viz BPMN diagram.

Obrázek 12: Autorizace platby platební kartou a následná expedice zboží

Pracovníci jsou zodpovědní za ověřování takto neprávem nabytých finančních prostředků a posouzení závažnosti poškození. Klade se zde důraz na striktní dodržení kritérií dle interních podnikových směrnic. Specialisté poskytují školení nově příchozích pracovníků, asistenci a jejich kontrolu, popisují a udržují aktuální dokumentaci schvalovacího řízení. Je nutné taktéž brát v úvahu ukazatele výkonnosti (KPI4 , SLA5 ) a účast na pravidelných setkáváních týmu. Trading – středisko obchodních procesů, které zaměstnává firemní obchodníky. Jejich úkolem je nákup zboží od obchodních partnerů s ohledem na stavy zásob. Dále provádí prodej, cílem je zajištění dostatečné marže a provize. Obchodníci jsou ohodnoceni bonusem navíc, procentuálně vypočteným ze získané marže a jsou tak dostatečně motivování. Jejich počínání, množství nakoupeného a prodaného zboží musí být v souladu s firemní strategií. Další aktivitou je zařízení nadstandardního pojištění zásilky. Průběh procesu, který zajišťuje vyřízení zásilky zboží je zachycen v nadcházejícím BPMN diagramu. 4

KPI (z ang. Key Performance Indicator) – klíčové ukazatele výkonnosti. Základní prvek systému pro měření výkonnosti procesů v organizaci. Popisuje konkrétní měřitelnou hodnotu při vykonávání daného procesu. [Kpi2013] 5 SLA (z ang. Service-Level Agreement) – smlouva sjednaná mez poskytovatelem služby a jejím konzumentem. Obě strany obchodní transakce by měly znát práva a povinnosti při využívání dodávané služby (produktu).

5.3

Analýza procesů

36

Obrázek 13: BPMN Průběh zásilky zboží, vlastní práce

Procesy, které probíhají v části Back office jsou dle mého názoru efektivní a nevidím nutnost jejich inovace. Podrobnější analýzu procesů v obchodním oddělení poskytuje následující diagram.

5.3

Analýza procesů

37

Obrázek 14: Business Process Model obchodní činnosti

SEO/SEM – tento proces vykonávají specialisté, kteří mají spoluúčast na tvorbě plánů prodeje a zacílení marketingové kampaně na základě analýz, využívajících informace z SEO optimalizace pro vyhledávače. Jeden specialista může zodpovídat za jednu či více zemí a za oba způsoby vyhledávání (SEO i SEM). Zkratka SEM je označení pro marketing ve vyhledávačích (z angl. Search engine marketing). Jedná se o placenou formu propagace, účtování probíhá většinou modelem PPC (z ang. pay per click), tedy platba za kliknutí. Prakticky se jedná o umístění různých forem reklamních poutačů, bannerů umístěných v sítích serverů, které takovou možnost marketingu nabízejí. Pracovníci jsou přímo nadřízení vedoucímu střediska SEO/SEM a přímo se tak podílejí na obratu firmy, díky propagaci pro-

5.3

Analýza procesů

38

duktových řad společnosti, marketingovým operacím a možnosti vyhledávat firemní značky ve vyhledávačích podle zemí. Specialisté udržují oficiální vztahy se svým přímým nadřízeným (týdenní reporting), s obchodníky (zlepšení kvality webových stránek, koordinace marketingových kampaní), produktovými manažery (reklamní materiály a nové nabídky pro umístění na webu), se střediskem zákaznické podpory (reference a zpětné vazby od zákazníků) a s webdesignery (specifikace reklamních materiálů). Mezi základní odpovědnosti pracovníků patří vytváření, monitorování a vývoj nových kampaní pomocí sponzorovaných odkazů na základních vyhledávačích; optimalizace obsahu stránek společnosti za účelem zvýšení návštěvnosti a prodejů pro zákazníky, přicházejících z vyhledávačů; analyzování denních statistik za účelem tvorby plánů a kontroly jejich dodržování a kontrola čerpání rozpočtu, určeného pro marketingové aktivity. Následující procesy jsou sdruženy ve středisku Online Marketing: • Webmasters – pracovníci mají na starost obsah webových stránek různých zemí, jako jsou textové pole, obrázky, animace Flash, videa a další obsah, který se podílí na obohacení webů pod správou skupiny Pixmania. Mezi hlavní pracovní náplň patří správa, udržování a aktualizace webových stránek, aktualizace či odstraňování proběhlých marketingových kampaní pomocí Systému pro správu obsahu (CMS), příprava nových kampaní, upravování zdrojových obrazů a jejich přizpůsobení existující struktuře webu, implementace pravidel pro optimalizaci SEO, denní reporting a komunikace. Na zaměstnance jsou kladeny požadavky na ovládání zejména HTML, kaskádových stylů CSS, zkušenosti s grafickým editorem Adobe Photoshop, znalosti Systémů pro správu obsahu (CMS) a FTP klientů. • Graphic – správci webu jsou v kontaktu s grafiky, kteří vytvářejí různé grafické elementy (obrázky, animace Flash), které se stávají součástmi marketingových kampaní, umísťovaných na webové stránky. Grafici diskutují a navrhují jednotný vizuální vzhled značek, poskytují denní reporty a komunikují s nadřízenými. Konkrétními využitými nástroji jsou Adobe CS, Photoshop, Illustrator a Adobe After Effects. • Database/Content Operator – dalším procesem, který poskytuje data pro správce stránek je Database/Content proces. Tito zaměstnanci poskytují obsah webových stránek pro různé země, jako jsou zdrojové texty, obrázky, technické údaje, popis zboží, manuály, videa a další obsah, který se podílí na obohacení webových stránek. Pracovní náplní je vyhledávání specifických informací, či obsahu z důvěryhodných zdrojů, nejlépe přímo od výrobce, shromažďování požadovaných informací, jejich umisťování do příslušných sekcí webových stránek, získání technologických a produktových specifikací, které umožňují snadné pochopení zákazníky a denní reporting. • Translators – překladatelé mají za úkol překlad obsahu webových stránek, reklamních materiálů, popisu produktu a jiných materiálů, dle požadované země.

5.3

Analýza procesů

39

Zdrojovým jazykem je většině případů francouzština a z ní probíhá překlad do cílových jazyků. Procesy, probíhající ve středisku Online Marketing jsou dle mého názoru efektivní, není zde důvod k inovaci. Customer support – Proces péče o zákazníky. Agenti zákaznické podpory a call centra jsou zodpovědní za škálu úkonů, zejména vyřizování telefonních hovorů se zákazníky, odpovídání na e-maily, tematicky vztažené k objednávkám, dopravě, balíkům, dostupnosti zboží ve skladech, stornování objednávek, vratek a k dalším požadavkům a dotazům zákazníků. Počet emailů je průměrně více než 200 za den, hovory probíhají v českém, slovenském, polském, německém, anglickém, polském, maďarském, finském, norském, dánském, švédském jazyce. Proces zákaznické podpory je velmi specifický, liší se dle země působnosti a má často individuální průběh. Je zde důležité zajištění maximální kvality podpory pro zákazníky, neboť je nutné v co největší míře poskytnout kvalitní servis pro uživatele a zachovat konkurenceschopnost podniku. Musí být tedy maximálně vstřícný vůči zákazníkovi. Nevidím zde prostor k inovaci. IT / E-merchant – podnikové středisko, svou činností podporující klíčové procesy ve firmě. Celé středisko je rozděleno do několika týmů v závislosti na projektech, které zpracovávají. V čele týmu stojí IT projektový manažer, který zodpovídá za správu a dokončení IT projektů, jejich včasné dokončení s efektivním využitím zdrojů a v požadované kvalitě dle standardů. Základní běžnou pracovní náplň tvoří: • asistence klientům (externích i v rámci skupiny) během analytických procesů • definování vstupů (technické a lidské zdroje) • psaní technických specifikací • plánování projektových úkolů a vyhodnocování související pracovní zátěže • denní management projektového týmu • technická dokumentace souvisejících produktů • definice pracovních týmů a integračních testů pro komplexní aplikace • reporting podle klíčových indikátorů výkonnosti (KPI) • proaktivní přístup ke kritickým cestám v projektových rizicích • předávání protokolů pro zajištění kvality (Quality Assurance) jednotlivým týmům Rovněž se předpokládají odpovídající technické znalosti s objektově orientovaným návrhem v PHP, databází MySQL a Oracle v prostředí operačních systémů Linux, nástroje SVN nebo Git pro správu repositáře.

5.3

Analýza procesů

40

PHP Software Developers – tým vývojářů, kteří vyvíjejí sadu objektově orientovaných, škálovatelných, výkonově orientovaných a na základě frameworků implementovaných komponent pro e-commerce systémy. Dále se podílejí na tvorbě webových stránek pro zákazníky a rozhraní. PHP vývojáři jsou vedeni svým projektovým manažerem a na základě jeho pokynů sestavují kód podle předem stanovených kritérií a rozhraní. Na základě pokynů systémových a databázových administrátorů. Programátoři dostávají povědomí o e-commerce procesech, učí se agilnímu přístupu a standardům kvality. Database Administrator – proces správy produkční databáze. Pracovníci plánují a rozvrhují design databází v součinnosti s IT projektovým manažerem, prosazují metodologie, pravidla a směrnice pro softwarové vývojáře, hardwarové, softwarové a síťové administrátory. Dále provádějí dotazy nad databázovým strojem formou SQL dotazů a PL/SQL procedur, analyzují a vyhodnocují výkon, provádějí ladění, zabezpečení, upgrade, zálohy a obnovování. Řeší problémy (většinou vzdáleně) na produkčních databázích Oracle, instalují a upgradují DBMS (z ang. Database Management System - Systém řízení báze dat, zajišťuje práci s databází, tvoří tedy rozhraní mezi aplikačními programy a uloženými daty) a další operace podle zaměření a kvalifikace. IT Support – hlavním cílem je poskytnout klientům platformy E-merchant IT podporu frontoffice a backoffice aplikací ve vysoké kvalitě. Cílem je dobré pochopení uživatelských potřeb a očekávání. Následuje analýza incidentu na základě podnětu od klienta, založení nového tiketu v systému JIRA (systém pro správu a monitorování projektů), detailní analýza incidentu, vyhodnocení vlivu na ostatní zákazníky. Poté se pracuje na odstranění problému, pokud je to možné, provede se aktualizace vlákna v tiketu, popis řešení problému a informování zákazníka. V případě, že se jedná o komplexnější problém, provede se eskalace na druhou úroveň podpory. Model procesu IT podpory je vyobrazen v následujícím diagramu.

5.3

Analýza procesů

41

Obrázek 15: Business Process model: Technická IT podpora

IT Procesy probíhají ve společnosti podle dokumentace, dbá se na řízení kvality, využívá se zde profesionálního systému k podpoře a usnadnění procesů řízení projektů a požadavků. Nevidím zde nutnost inovace. Sled aktivit v procesu řešení incidentu je názorně vyjádřen v následujícím BPMN 2.0 diagramu. Popisuje interakci mezi zákazníkem, helpdeskem, úrovněmi IT podpory a vývojáři.

5.3

Analýza procesů

42

Obrázek 16: IT support Incident management

JIRA je softwarový nástroj vyvíjený společností Atlassian, podporuje a usnadňuje proces řízení projektů a požadavků, nabízí flexibilní a uživatelské nástroje pro řízení a sledování pracovníků při výkonu plnění úkolů. JIRA je orientován na podporu dosažení očekávaného výkonu na projektu. Je využíván ve společnosti. Proces zacházení s tiketem v tomto systému je vyobrazen v následujícím diagramu.

5.3

Analýza procesů

43

Obrázek 17: Proces zacházení s tiketem v systému JIRA

Testing – role testerů spočívá v ověření chování a funkčnosti interních programů společnosti a webových stránek podle testovacích scénářů a dokumentace. Pokud se zjistí defekt, provede se report odhalených problémů a jejich nahlášení pomocí tiketu v systému JIRA. Po implementaci záplaty se provádí opětovné testy a příslušný tiket se aktualizuje dle výsledku nového testu. Testeři taktéž vytvářejí testovací scénáře a zároveň tvoří a aktualizují dokumentaci veškerých procesů, které jsou využívány pro testovací účely. Scénáře musí přesně odpovídat zákazníkovým představám a požadavkům a musí být přesně vykonány. Vyšetřování vad probíhá v blízké spolupráci se střediskem vývoje. Business Intelligence – proces pro přípraavu komplexních Business Intelligence (dále jen „BI“) řešení pro zaměstnance společnosti, které slouží jako podklad pro strategické rozhodování. Členové tohoto týmu tedy musí zvládnout celý BI proces. To znamená úvodní definici projektu s vnitropodnikovou jednotkou (zadavatelem), získání příslušných dat z produkční databáze a jejich extrakce do datového skladu. Následuje zpracování reportů, multidimenzionální pohled na data pomocí datových kostek a další extrakce pomocí BI nástrojů. Využívá se zde systém IBM Cognos pro podporu BI procesů. Nedílnou součástí je testování, validace a udržení dokumentace BI aplikací. Pohled na BI proces je vyobrazen na následujícím diagramu.

5.3

Analýza procesů

44

Obrázek 18: Business Process Model: Business Intelligence

Internal office IT – proces, který poskytuje lokální podporu koncovým uživatelům ve společnosti. Má na starost veškeré informační a komunikační zařízení ve společnosti, tedy počítače, notebooky, LCD monitory, VOIP telefony a další příslušenství. Pracovníci zodpovídají za bezproblémový chod zařízení v serverovně, telefonní ústředny, síťových tiskáren, konektivity k síti Internet, udržují dokumentaci procesů. Oddělení dohlíží na bezproblémový chod docházkového systému, ERP systému Money S3 pro účely účetnictví, chod vnitropodnikového intranetu a dalších systémů, které běží v lokální síti. Zjednodušený pohled na podnikový proces nabízí následující BPM diagram.

5.3

Analýza procesů

45

Obrázek 19: Globální pohled na podnikový proces interní IT podpory, vlastní práce.

Podívejme se na nyní na činnost tohoto oddělení podrobněji. Tým přijímá požadavky na služby pomocí emailů, telefonicky a prostřednictvím systému pro správu požadavků. Jedná se o různorodé požadavky, které je potřeba nějakým způsobem organizovat. Využívá se zde jednoduchého „tiketovacího systému“, který běží ve francouzském intranetu (je možné jej dosáhnout z brněnské pobočky, díky propojení sítí). Systém má řadu nedostatků a jeho inovace je předmětem nového systému, který bude v této práci navržen, namodelován a popsán. Vedoucí zaměstnanci se obrací na lokální středisko IT podpory s požadavky na vybavení a prostředky pro nové zaměstnance. Jedná se o pracovní stanici, telefon a specifikace systémů, do kterých má mít nový pracovník přístup. Vše je specifikováno v interním dokumentu pro nové zaměstnance. Stejným způsobem se postupuje při ukončení pracovního úvazku, aby bylo co nejdříve možné deaktivovat všechny přidělené přístupové údaje do vnitropodnikových systémů, sítě VPN apod. z důvodu bezpečnostních. Pokud je v přístupovém formuláři specifikován požadavek na vybavení telefone, provede se přiřazení klapky danému uživateli na telefonní ústředně. (zkr. PBX) IP PBX (z ang. Private Branch Exchange) je výraz pro soukromou pobočkovou ústřednu, což je soukromá telefonní síť používaná v rámci podniku. Uživatelé tohoto systému sdílejí určitý počet externích linek, aby bylo možné připojení k veřejné komutované telefonní síti a uskutečňovat hovory mimo lokální systém (Call centrum, obchodníci). Výhodou tohoto systému je centralizovaná struktura celé organizace,

5.3

Analýza procesů

46

vysoká spolehlivost a v neposlední řadě taktéž úspora nákladů. [3CX2012] Mezi nejdůležitější přístupové údaje patří vytvoření doménového účtu v systému Microsoft Active Directory, na který se navazuje řada dalších přístupů a lze přes něj aplikovat hromadnou správu oprávnění a nastavení aplikovaných jak na celý počítač, tak na přihlášeného uživatele. V doménové hierarchii jsou vytvořené různé bezpečnostní skupiny, které garantují možnost přístupu do firemních systémů. Na základě specifikací ve formulářích, obdržených od vedoucích pracovníků pak členové interního IT střediska přidělují zaměstnancům oprávnění. Nástroj pro správu Skupiny zásad (v angličtině se využívá hojně termín Group Policy – GPO) se používá zejména pro: • aplikování firemních standardů (například skrytí Ovládacích panelů, vzdálenému mapování síťových tiskáren a síťových diskových jednotek, řízení aktualizací systému Windows, spouštění skriptů po přihlášení uživatele) • aplikování zabezpečení (změna oprávnění na určitých adresářích, charakteristiky hesel, možnost změnit si heslo) • hromadná instalace aplikací v tichém režimu (sada MS Office, Adobe Reader, Adobe Flash Player) • řízení aktualizací systému Windows a další. Oddělení má dále za úkol přípravu instalačních obrazů pro koncové stanice – systémů Windows a Linux pro všechny modely počítačů, které se ve firmě používají. Spravují licence pro software, po schválení ředitelem nakupují nové licence na základě požadavků uživatelů. Tým vytváří nové schránky elektronické pošty v systému Zimbra, spravuje distribuční listy a provádí rutinní monitoring naplnění kvót za účelem zabránění přeplnění schránek a následnému vytvoření front nedoručených emailů na poštovním serveru. Existuje zde formální proces, který se dodržuje a provádí se každý den. Je vyobrazen v následujícím diagramu aktivit.

5.3

Analýza procesů

47

Obrázek 20: Diagram aktivit manuálního monitorování kvót na poštovním serveru.

Na základě přijatého vstupního formuláře jsou členové týmu zodpovědní za instalaci počítače z předem připraveného instalačního obrazu, základní konfiguraci počítače, konfigurace poštovního klienta Outlook, příprava VPN klienta a konfigurace dalšího programového vybavení v závislosti na vykonávané pozici. Podrobně namodelovaný proces je zachycen v následujícím diagramu.

5.3

Analýza procesů

48

Obrázek 21: Business Process Model: Interní IT podpora

Dalším okruhem činnosti střediska je kompletní inventarizace hmotného ICT majetku. Procesy, které probíhají ve středisku lokální podpory jsou dle mého názoru neefektivní a je zde prostor k návrhu různých inovací.

6

6

NÁVRH INOVACÍ

49

Návrh inovací

V informačním systému neexistuje jakákoliv aplikace, která sloužila k účelům inventarizace majetku. Přitom inventarizace je důležitou součástí účetní uzávěrky. Povinnost inventarizovat majetek vyplývá ze Zákona o účetnictví, konkrétně § 6 a § 31. Účelem inventarizace je zajistit věcnou správnou účetnictví – cílem mít stejný skutečný stav aktiv a pasiv a v případě rozdílu tento účetní stav upravit, dalším aspektem je správné ocenění majetku a závazků. Dle termínů, ke kterým je inventura provedena, rozlišujeme inventarizaci periodickou, která připadá obvykle na rozvahový den a inventarizaci průběžnou, kdy termín si stanovuje sama účetní jednotka. Správnost inventury je taktéž důležitá pro účely auditu ve společnosti. V současné době probíhá tento proces ve zkoumané firmě formou sběru dat do sešitu v Excelu. Každý tým má určený jeden list. V něm se sdružují informace o sériových číslech pracovní stanice, monitorů a telefonního přístroje, údaje o názvu modelové řady majetku, odpovědné osoby a uživatele majetku.

Obrázek 22: Současný způsob vedení inventury ICT majetku

Každý list dle jednotlivých týmů je vytištěn a podepsán zástupcem interního IT

6.1

Návrh inovace procesu Inventarizace ICT majetku

50

oddělení (teamleader) a vedoucím pracovníkem střediska, ke kterému se soupis majetku vztahuje. Tento proces je velmi neefektivní a má řadu nedostatků. Mezi hlavní lze uvést nepohodlnost sběru dat (ruční opisování sériových čísel ze štítků majetku, které jsou často velmi špatně dostupné) a tím pádem možnost vzniku chyb, velmi pomalý průběh procesu inventarizace a nutnost opravovat manuálně údaje při každé změně.

6.1

Návrh inovace procesu Inventarizace ICT majetku

Tento proces lze zefektivnit využitím řešení pro automatizovanou inventarizaci s využitím čárového kódu. V dnešní době moderní a dynamické organizace využívají velké množství majetku. Účelem tohoto řešení je automatizovat, zrychlit a zpřesnit provádění fyzických inventur majetku. Pracovník, provádějící inventuru využije místo velkého množství potištěných papírů čtecí zařízení, umožňující čtení čárového kódu, ve kterém je formou datového souboru uložena příslušná část inventarizovaných položek. Podpůrný software nainstalovaný do čtecího zařízení umožní rychlý a přehledný způsob práce fyzické inventury. Je možné také přidávat textové poznámky ke každému majetku – například návrh na opravu, vyřazení a různá upozornění. Čtecí zařízení umožňuje i další využití např. při hromadných přesunech evidovaných položek při změnách oddělení či kontroly a změny odpovědnosti při odchodu či nástupu zaměstnanců. Navržené řešení má řadu předností, mezi které lze zařadit: • využití moderního prostředí Windows Mobile ve čtecím zařízení, snadné ovládání pomocí grafického dotykového displeje • multifunkční využití čtecího zařízení pro více odlišných procesů v organizaci • do čtecího zařízení lze importovat najednou až 50000 položek majetku • zásadní zkrácení času pro fyzické provádění inventury • možnosti vytvoření štítků • přímé propojení čtečky s tiskárnou čárových kódů • bezobslužná komunikace mezi čtecím zařízením a PC • rozsáhlá modifikovatelnost procesů inventury • přihlášení a odhlášení uživatele pomocí čárových kódů Principem řešení je použití etiket s čárovým kódem pro označení jak prostor provádění inventury (budova, oddělení…), tak i jednotlivých předmětů spadajících do povinnosti inventarizace. Čtecí zařízení po sejmutí kódu ověří přítomnost položky v seznamu a dále zkontroluje jeho správné umístění. Jakékoliv odchylky jsou akusticky signalizovány spolu s nabídnutím řešení vzniklé situace. Etiketa na majetku

6.1

Návrh inovace procesu Inventarizace ICT majetku

51

může vypadat například takto:

Obrázek 23: Inventarizační štítek pro polepení majetku

Komunikace – přenos inventurních dávek mezi podnikovým ERP systémem probíhá prostřednictvím datových souborů. Při provádění fyzické inventarizace majetku je pomocí čtecího zařízení nejprve přečten kód daného prostoru a následně potom kódy všech majetků umístěných v tomto prostoru. Na konci inventarizace se veškerá data přenesou zpět na pracovní stanici k finálnímu zpracování operátorem či ERP systémem. Přenosy dat jsou v podobě dávek ve strukturovaném formátu dat (nejčastěji formát .CSV).

Návrh fyzického zařízení MOTOROLA MC55A0

Velmi malé a lehké zařízení kategorie EDA (Enterprise Digital Assistant) se systémem Windows Mobile 6.5. Jedná se o velmi robustní přístroj, který plní náročné požadavky na výkon a funkční snímač. Pro čtení čárových kódů je určen 1D laserový nebo 2D digitální snímač a další jeho předností je výkonný, dostatečně velký a kontrastní displej. Termo – transferová tiskárna Zebra GX420

6.1

Návrh inovace procesu Inventarizace ICT majetku

52

Ve své třídě nejlépe vybavená stolní termální tiskárna se škálou funkcí pro tisk etiket majetku. Rychlost tisku etiket je až 152 mm/s. Tiskárna má několik možností připojení – včetně kabelového i bezdrátového a zajišťuje tak snadnou integraci do celkového systému. Tiskne etikety až do maximální šířky 104 mm. Následující tabulka poskytuje technické údaje čtečky. Tabulka 1: Technické údaje čtecího zařízení MOTOROLA MC55A0

Rozměry (d x š x h) Hmotnost Displej

147 x 77 x 26 mm 315 g (včetně akumulátoru 2400 mAh) barevný, 3,5”, 640 x 480 bodů (VGA), dotykový panel, LED podsvícení Napájení dobíjitelný lithium-iontový akumulátor 3,7 V, 2400 mAh Rozšiřující slot uživatelsky přístupný microSD; max. kapacita paměťové karty 32 GB Hardwarová klávesnice numerická nebo QWERTY nebo PIM Rozhraní USB 1.1 host i klient Paměť 256 MB RAM / 1 GB flash Operační teplota -10 °C až 50 °C Odolnost pád z výšky 1,8 m na beton; 1000 otáček v rotačním bubnu (pád z 0,5 m, 2000 nárazů) Krytí IP64 WLAN rádio Wi-Fi 802.11a/b/g WPAN rádio Bluetooth, třída II, v2.1 Enhanced Data Rate (EDR), integrovaná anténa Kamera rozlišení 3,2 megapixely; nastavitelný blesk, automatické ostření

Software Ve čtecím zařízení je instalováno vlastní programové vybavení „INVENTURA MAJETKU“, které zajišťuje podporu kompletního zpracování inventur včetně komunikace s pracovní stanicí výpočetního systému. Přenos dat a inventurních poznámek z a do aplikace evidence majetku je prováděn prostřednictvím standardního textového formátu dat s oddělovačem. Toto vysoce sofistikované řešení pro řádné inventury obsahuje i zvláštní funkce pro polepování štítků, které mají za úkol uživatele maximálně podpořit při tisku a aplikaci štítků na místě, srovnání dat, doplnění chybějících údajů a datových vazeb. Program pro inventarizaci majetku disponuje následujícími funkcionalitami: • fyzické ověření přítomnosti majetku a ověření umístění

6.1

53

Návrh inovace procesu Inventarizace ICT majetku

• řízení přesunů mezi jednotlivými útvary • vložení nového, dosud neevidovaného umístění do seznamu (místnost, hala…) • vložení dosud neevidovaného majetku • vložení textové poznámky k libovolnému majetku • přehledy – možnost velmi komfortního prohlížení inventurní dávky, zapínání různých kombinací filtrů, prohlížení detailů • přímý tisk etiket majetku a umístění. Terminál lze přímo připojit na tiskárnu čárových kódů. Obsah i vzhled etikety je uživatelsky modifikovatelný. • identifikace uživatele – uživatel se přihlašuje do programu vložením osobního PIN kódu • speciální režim pro úvodní lepení štítků – program umožní provádět speciální operace, které usnadní prvotní implikaci etiket v organizaci. Cena řešení Následující tabulka poskytuje cenový přehled jednotlivých položek navrženého řešení. Tabulka 2: Přehled cen řešení pro inventarizaci majetku s využitím čárového kódu

Popis Čtecí zařízení Motorola MC-55A0 Komunikační základna USB komunikační kabel Tiskárna ZEBRA GX42 Polyesterová etiketa, 1000 ks SSB – MC55X-30 – tříletý servis od instalace Aplikace programu „INVENTURY MAJETKU“ 1 licence pro terminál Aplikace pro datovou synchronizaci, instalace, správa uživatelů Konzultační den – instalace, zaškolení obsluhy, testy Cena CELKEM: Zdroj: [Tra2013]

Cena bez DPH 27.700,3.500,1.265,12.840,560,4.465,16.200,3.850,8.800,79.340,-

6.2

6.2

Návrh inovace pro systém pro správu požadavků pro IT oddělení

54

Návrh inovace pro systém pro správu požadavků pro IT oddělení

Čtenář by měl být nyní seznámen s principem procesu interního IT oddělení na základě popisu činností pracovníků na tomto oddělení. Jak již bylo uvedeno, sběr požadavků na interní IT oddělení ve společnosti probíhá přes vedoucí pracovníky s využitím jednoduchého systému, který běží v intranetu v Paříži. Taktéž by bylo vhodné využít tento systém pro interní komunikaci pracovníků v IT oddělení. Současný stav Současný systém je velmi pomalý a má velmi omezenou funkcionalitu. Počet uživatelů, které mají přístup do tohoto systému, je velmi malý a požadavky pro vytváření přístupových údajů do něj se vznáší emailem francouzským kolegům. Mezi další nevýhody tohoto systému je nepřehlednost, absence kategorizace požadavků, nemožnost přikládat přílohy, nelze definovat doporučené datum a čas splnění požadavku uživatelem, taktéž chybí informování uživatele prostřednictvím emailu. Celý systém není konzistentní, dochází k problémům s překladem do českého jazykového rozhraní a má řadu dalších nedostatků. Náhled současného systému je zachycen na následujícím snímku.

Obrázek 24: Současný systém pro správu požadavků

Následující kapitola pojednává o aspektech návrhu inovace stávajícího systému.

6.2

Návrh inovace pro systém pro správu požadavků pro IT oddělení

55

Návrh inovace Dílčím cílem této práce je návrh inovace systému pro správu požadavků pro interní IT oddělení, neboli „IT ticketing systém“. Jedná se o webovou aplikaci vytvořenou ve skriptovacím jazyce PHP a všechna data jsou uložena v databázi MySQL. Úvodem pro řešení tohoto problému je definice vhodných požadavků, které by měl systém poskytovat, dále analýza a tvorba modelů s využitím prostředků, které umožňují efektivně popsat systém až po implementaci modelovaného systému. Vhodným nástrojem pro popis funkcionality je diagram případů užití, taktéž „Use Case“ diagram. Využívá se k popisu chování systému z hlediska uživatele a zachycuje, které typy uživatelů a jak se systémem pracují a jaké vykonávají v rámci systému činnosti. Případy užití zachycují pouze funkční požadavky, které určují, jaké chování by měl navrhovaný systém nabízet.

Obrázek 25: Diagram případů užití navrženého systému

Hranice modelovaného systému je reprezentována obdélníkem uvnitř diagramu. Existují dva druhy aktérů, koncoví uživatelé, kteří mají možnost standardního při-

6.2

Návrh inovace pro systém pro správu požadavků pro IT oddělení

56

hlášení do systému s přidělenými údaji a hlavní funkcionalitou (případem užití) je vytvoření nového tiketu. Existuje zde možnost zadání kontaktních údajů, zejména emailu pro odpověď od podpůrného týmu, definice doporučeného data splnění tohoto požadavku, dále výběr hlavní kategorie problému a volbu podkategorie. Tato vlastnost je vhodná pro snadnější kategorizaci požadavků a následnou tvorbu reportů. Dále má uživatel k dispozici textové pole pro popis problému, ve kterém specifikuje problém. Velmi užitečná je možnost vložení a nahrání přílohy v libovolném formátu, která slouží k větší názornosti při identifikaci problému. Největší využití nalezne pro nahrávání snímků obrazovky s chybovým hlášením, či pro nahrání libovolné fotografie. Člen týmu pak může odpovědět na tiket prostřednictvím textového pole pro odpověď a následně proběhne odeslání odpovědi na emailovou adresu, kterou vyplnil autor tiketu při jeho vytváření. Administrátoři tohoto systému (členové interní IT podpory) dále mají možnost zavírat a otevírat tikety, například pokud se problém nepodařilo zcela vyřešit. Mají možnost spravovat adresář uživatelů, vytvářet a editovat uživatelské profily. Atributy nového uživatelského účtu jsou přihlašovací jméno (login) heslo, přiřazení oddělení, křestní jméno, příjmení, emailová adresa, telefonní spojení a volitelné textové pole pro další poznámky. Je také možné učinit vytvářený profil jako privilegovaný (administrátorský). Dále mají správci možnost libovolně editovat a přizpůsobovat systém – modifikovat oddělení, kategorie a podkategorie.

Implementace Nyní se dostáváme k návrhu aplikace. Na následujícím snímku je znázorněn diagram databázových tabulek, popisující datovou strukturu pro uložení dat v databázi.

6.2

Návrh inovace pro systém pro správu požadavků pro IT oddělení

57

Obrázek 26: Diagram tříd navrženého systému

Struktura sestává z celkem devíti tabulek. Hlavní tabulkou je tabulka Tickets, která obsahuje informace o tiketech, ukládají se do ní atributy, které nesou emailovou adresu autora, název tiketu, předmět, popis a další. Rovněž obsahuje cizí klíče do ostatních tabulek. Tabulka Topic obsahuje názvy možných témat tiketu, do tabulky Attachments se ukládají informace o přílohách. Dále v systému nalezneme tabulku Category která nese informace o možných kategoriích, tabulka Priority obsahuje seznam možných priorit, tabulka Department sdružuje informace o střediscích v podniku. Další významnou tabulkou je tabulka Users, která ukládá informace o uživatelích tohoto systému. Tabulka Forgotten passwords obsahuje informace o zapomenutých heslech. Tabulka Tokens slouží k zabezpečení přihlašovací obrazovky. Ideálně by měla být navázána na všechny formulářové prvky v systému. Přidává do webového formuláře náhodný řetězec, který se po odeslání kontroluje s obsahem této tabulky a zabraňuje útokům do internetové aplikace. K implementaci navrženého systému byl zvolen skriptovací jazyk PHP a pro databázi je využit databázový systém MySQL, příkazy jsou vsazeny do tabulkového layoutu HTML a byly využity kaskádové styly CSS. Náhledy z aplikace jsou součástí přílohy A. Snímky jsou zachyceny z webového prohlížeče a přizpůsobeny oříznutím na požadovanou velikost.

6.2

Návrh inovace pro systém pro správu požadavků pro IT oddělení

58

Přínos systému Navržený systém má řadu přínosů. Jedná se o systém navržený přímo na základě analýzy procesů, které ve sledovaném oddělení probíhají. Systém je navržený pomocí bezplatných prostředků a tak jeho vývoj má minimální náklady. Dalším usnadněním je přehlednost aplikace, umožňuje obsluhu i uživatelům s minimálními informatickými dovednosti, je velmi intuitivní a svižný díky běhu v prostředí lokální sítě podnikového intranetu, lze jej snadno spravovat a přináší i usnadnění práce zaměstnanců lokální IT podpory. Ekonomické zhodnocení inovace Při návrhu této inovace je také důležité se zamyslet nad ekonomickou stránkou věci. Vzhledem k nutnosti běhu této aplikace pouze v rámci podnikového intranetu, postačí pouze základní jednoprocesorová sestava. Potřebné charakteristiky jsou: • Operační systém Linux (Ubuntu server edition) • RAID pole • Apache server • MySQL server • Firewall pro filtrování paketů • Mail server • další požadavky dle potřeby společnosti Pro potřeby běhu této aplikace postačí jednoprocesorový server, který lze integrovat do jakéhokoliv 19”rack rozvaděče. Parametry jsou následující: Serverová sestava Fujitsu PRIMERGY RX100 S7P 1U • CPU 1x Intel Xeon E3-1220v2 s frekvencí 3,1 GHz, 8 MB L3 Cache, 4 jádra • Čipset Intel C202 • Operační paměť 2x 4 GB DDR3, 1600 MHz • HDD 2x 500 GB S-ATA III • Řadič RAID pro pevné disky s režimy 0, 1, 10 • 2x Ethernet 10/100/1000 MBit/s Instalace OS Linux a zprovoznění této webové aplikace není náročné a je možné svépomocí. Orientační cena sestavy je 23.000,- Kč bez DPH 21%.

7

7

DISKUZE

59

Diskuze

Pokud provedeme porovnání dvou použitých přístupů k procesnímu modelování, na úvod je zapotřebí říci, že metodologie UML je univerzálnější. Díky nabídce velkého množství různých typů diagramů máme možnost objektově orientovaným přístupem modelovat, provádět analýzu, navrhovat a popisovat programové systémy. Podpora pro podnikové procesy je v UML zanesena na základě konceptuálních prvků. UML umožňuje staticky i dynamicky popisovat systémy. Modelování pomocí BPMN je omezeno pouze na znázorňování podnikových procesů pomocí procesních diagramů. Diagramy neprocesního charakteru jsou mimo rozsah jazyka BPMN. Diagramy vytvořené pomocí notace BPMN jsou srozumitelné a nabízejí velmi velkou podrobnost a specifikaci daného procesu, díky velkému množství prvků. Z jazyka UML lze vybrat diagram aktivit a je možné jej srovnat s podnikovým procesem namodelovaným v BPMN: startovací bod procesu je definován v UML inicializačním uzlem, v BPMN se jedná o startovací událost, která vyvolává určitou aktivitu, která může být i nedefinovaná. V UML je základní jednotkou pro chování akční element s výběrem více druhů akcí, oproti tomu v BPMN je základním stavebním blokem aktivita a nabízí detailnější specifikaci úlohy pro spuštění modelované aktivity (manuální, skript, …). Kontrolní tok v UML je určený pro propojení elementů v diagramu aktivit. V BPMN k tomuto slouží sekvenční tok, odlišuje se od UML typem a vyjádřením podmínky pro omezení sekvenčního toku. Dalším významným rozdílem je chování elementů aktivit, v UML nelze rozdělit aktivitu a dále ji dekomponovat, oproti tomu v BPMN je možná dekompozice na podproces s odkazem na novou externí aktivitu. Obecně bych tedy doporučil jazyk BPMN pro modelování podnikových procesů, nabízí tvorbu přehledných a názornějších procesních diagramů. Pro popis architektury a chování systémů je naopak vhodnější využít jazyka UML. Podpora obou notací je většinou zakotvena v CASE nástrojích. [Spa2013] Pro proces lokální IT podpory podniku byly navrženy celkem dvě komplexní inovace. První inovace se týkala usnadnění dílčího procesu inventarizace ICT majetku, kterou periodicky provádějí zaměstnanci na tomto oddělení. Původní systém, který byl založen na manuálním opisování čárových kódů a následné evidenci v Microsoft Excelu byl nahrazen návrhem inovace přinášející zautomatizování celého procesu s využitím řešení pro inventarizaci majetku pomocí čárového kódu. Představil jsem fyzická zařízení – čtečku čárových kódů a termotiskárnu pro tisk inventárních štítků, podpořená na míru připraveným softwarem. Cena navrženého řešení je uvedená v ekonomickém rozboru a je přijatelná pro společnost takového rozsahu. Přinese zjednodušení, zrychlení a zefektivnění celého procesu inventarizace ICT majetku a úsporu mzdových nákladů pro zaměstnance vykonávající inventuru. Doba návratnosti této investice je velmi krátká. Hlavní inovace se týkala návrhu zcela nového systému pro správu požadavků pro interní IT oddělení. Na základě namodelovaných a popsaných procesů, které na

7

DISKUZE

60

tomto středisku probíhají, bylo provedeno zhodnocení současného stavu. Po výčtu nedostatků stávajícího systému, byl proveden návrh požadavků a funkcionalit pro nový systém, jejich znázornění v UML diagramu případů užití, návrh datové struktury nové aplikace včetně diagramu a provedena implementace tohoto systému. Práce je doplněna o snímky výsledné funkční aplikace. Ekonomický rozbor inovace pojednává o požadavcích a prostředcích potřebných pro nasazení navrženého systému v podniku. Výsledná částka je velmi příznivá, postačí pouze server s operačním systémem Linux a další volně dostupné programové prostředky. Konkrétní cenový rozbor je v kapitole taktéž uveden.

8

8

ZÁVĚR

61

Závěr

Dle mého názoru tato diplomová práce naplnila všechny body, které jsem si vytýčil v cíli práce. Úvodní část práce pojednává o procesech a procesním řízení společnosti, dále následuje popis jednotlivých metodik. Další kapitola pojednává o nástrojích CASE obecně, konkrétněji je představen produkt Enterprise Architect od společnosti Sparx Systems, který byl využit pro přípravu diagramů. Na tyto teoretická východiska navazuje kapitola, v níž je představena společnost, pro kterou jsou diagramy modelovány. Nejprve jsem představil celý koncern Dixons Retail, PLC., poté jsem se zaměřil na společnost Pixmania, s.r.o. Čtenář má možnost se seznámit s organizační strukturou brněnské pobočky, s rozsahem poskytovaných služeb, s portfoliem nabízených produktů a s detailním popisem platformy e-commerce pod názvem E-merchant. Stěžejní kapitolou je popis jednotlivých středisek a procesů, které uvnitř probíhají. U každé části je proveden rozbor efektivnosti procesů. Práce se podrobněji zaměřuje na středisko lokální IT podpory pobočky a navrhnul jsem zde kompletní inovace. Jedna inovace se týkala systému pro řešení inventarizace ICT majetku pomocí čárového kódu. Hlavní inovace se zaměřuje na systém pro správu požadavků, který slouží pracovníkům tohoto oddělení. Nejprve jsem popsal stávající systém, provedl výčet nedostatků. Na základě tohoto jsem provedl návrh nové webové aplikace, včetně diagramu užití a modelu datové struktury. Výsledkem je funkční webová aplikace v anglickém jazyce, kterou je možné spustit v prostředí podnikového intranetu. Ovládání aplikace je jednoduché a intuitivní, vhodné pro všechny pracovníky ve společnosti. Aplikace je přiložena na médiu k této práci. Poznatky a informace k vypracování této práce jsem čerpal mimo jiné i z vlastních zkušeností při výkonu zaměstnání v této společnosti. Při řešení této diplomové práce jsem se dozvěděl mnoho nových informací, získal nové zkušenosti, které pro mě byly velkým přínosem.

9

9

REFERENCE

62

Reference

ARLOW, 2008. UML 2 a unifikovaný proces vývoje aplikací : Objektově orientovaná analýza a návrh prakticky. Bogdan Kizska. 1.vyd. Brno: Computer Press, 2008. 567 s. ISBN 978-80-251- 1503-9.. BPMI, 2004. Business Process Modeling Notation, Version 1.0 – May 3, 2004. Business Process Management Initiative, Dostupné z: http://www.bpmi.org. BPMN, 2011. Business Process Model and Notation (BPMN), Standard document. Business Process Management Initiative, Dostupné z: http://www.omg.org/spec/BPMN/2.0. BRABEC, 2005 Střediska sdílených služeb – cesta k zvýšení výkonnosti společnosti. [online]. 2005 [cit. 2013-04-08]. Dostupné z: http://www.cfoclub.cz/data/1132667075/strediska-sdilenych-sluzeb.pdf. BUCHALCEVOVÁ, 2007. Základy softwarového inženýrství - materiály ke cvičení. 1.vyd. Praha : Vysoká škola ekonomická, 2007. 222 s. ISBN 987-80-2451270-9.. ERIKSON, 2000. Business Modelling with UML: Business Patterns at Work John Wiley Sons, 2000, ISBN: 0471295515.. FOWLER, 2003. UML Distilled: A Brief Guide to the Standard Object Modeling Language. 3. edition. Addison Wesley, 2003. 208 s. ISBN 0- 321-19368-7.. IEEE Computer Society, 2000. IEEE std 1471-2000: IEEE Recomended Practise for Architecture description of Software-Intensive Software. IEEE, New York. LACKO, 2000. Web a databáze: programujeme internetové aplikace. Vyd. 1. Praha: Computer Press, 2001, xii, 250 s. ISBN 80-722-6555-5.. LANKHORST, 2000. Enterprise Architekture at Work. Springer-Verlag, Berlin, Heidelberg, 2005, ISBN 3-540-24371-2.. NONDEK, 2000. Internet a jeho komerční využití. Praha : Grada Publishing, 2000. ISBN 80-7169-933-0.. PROCHÁZKA, 2000. Nástroje CASE? Co? Proč? Jak? Databázový svět - informační portál ze světa databázových technologií [online]. 2004 [cit. 2013-04-04]. Dostupné z: http://www.dbsvet.cz/view.php?cisloclanku=2004052702. RÁBOVÁ, 2008 Podniková architektura - strategický nástroj v rukou manažera. Brno: Tribun EU, 2008. 132 s. 1. ISBN 978-80-7399-568-3.. RUMBAUGH, 2004. The Unified Modeling Language Reference Manual. 2.vyd. Addison-Wesley, 2004. ISBN 032124562853..

9

REFERENCE

63

[3CX2012]. Co je telefonní systém PBX?. IP PBX 3CX IP PBX pro Windows [online]. 2012 [cit. 2013-04-23]. Dostupné z: http://www.3cx.cz/voip-sip/telefonnisystem-pbx.html. [Bpm2008]. BPM prakticky: 3. část: Úvod do BPMN. VAŠÍČEK, Petr.,[online]. 1. vyd. 2008 [cit. 2013-04-04]. Dostupné z: http://bpmsme.blogspot.fr/2008/03/3-uvod-do-bpmn.html. [Dsg2013]. DIXONS RETAIL, PLC. Webové stránky společnosti Dixons Retail, PLC. [online]. 2013 [cit. 2013-05-02]. Dostupné z: http://www.dixonsretail.com/dixons/en/home. [Eme2013]. Webové stránky, platforma E-merchant.[online]. 2013 [cit. 2013-05-11]. Dostupné z: http://e-merchant.com/. [Kpi2013]. Key performance indicator. INTER-INFORMATICS, spol. s.r.o. [online]. [cit. 2013-04-08]. Dostupné z: http://www.mereniprocesu.cz/KPI-Keyperformance-indicator.html. [Mer2013]. Mediální slovník: Merchandising. MEDIA GURU. [online]. [cit. 2013-05-02]. Dostupné z: http://www.mediaguru.cz/medialnislovnik/merchandising/. [Seo2013]. Co je to SEO.[online]. 2013 [cit. 2013-05-02]. Dostupné z: http://www.seo-optimalizace.info/co-je-to-seo.html. [Spa2013]. Comparing UML Activities to BPMN Processes. Webové stránky společnosti Sparx Systems [online]. 2013 [cit. 2013-05-11]. Dostupné z: http://www.sparxsystems.com/enterprise_architect_user_guide/9.3/model_simulation/. [Tog2002]. The Open Group: The Open Group Architecture Framework. The Open Group [online]. 2002. vyd. 2002 [cit. 2013-04-20]. Dostupné z: http://pubs.opengroup.org/architecture/togaf8-doc/arch/. [Tra2013]. Webové stránky společnosti T-Trading s.r.o. .[online]. 2013 [cit. 201305-02]. Dostupné z: http://www.ttrading.cz/index.html. [Uml2011]. Unified Modeling Language ™ (OMG, UML) Infrastructure Specification, version 2.4.1. Object Management Group (OMG) Dostupné z: http://www.omg.org.

SEZNAM TABULEK

64

Seznam tabulek Tabulka 1: Technické údaje čtecího zařízení MOTOROLA MC55A0

51

Tabulka 2: Přehled cen řešení pro inventarizaci majetku s využitím čárového kódu 52

Seznam obrázků Obrázek 1: Podniková architektura a řízení podniku (Lankhorst, 2005) (zdroj: Rábová, 2008) 7 Obrázek 2: Ukázkový diagram případů užití (zdroj: vlastní práce)

14

Obrázek 3: Ukázkový stavový diagram

14

Obrázek 4: Elementy modelu podnikového procesu podle H.Eriksona 15 Obrázek 5: Nejčastěji používané elementy (zdroj: http://bpmsme.blogspot.fr/2008/03/3-uvod-do-bpmn.html) 18 Obrázek 6: Vývojové prostředí Enterprise Architect 9.0 (zdroj: http://enterprise-architect.en.softonic.com/ 20 Obrázek 7: Aktivity centra sdílených služeb (zdroj: Brabec, 2005)

23

Obrázek 8: Struktura obchodních společností koncernu DSG

25

Obrázek 9: Budova Triniti Office Center, sídlo společnosti. Zdroj: http://www.triniti.cz 26 Obrázek 10: Organizační struktura společnosti

31

Obrázek 11: Business Process Model: Back Office

32

Obrázek 12: Autorizace platby platební kartou a následná expedice zboží 34 Obrázek 13: BPMN Průběh zásilky zboží, vlastní práce

35

Obrázek 14: Business Process Model obchodní činnosti

36

Obrázek 15: Business Process model: Technická IT podpora

40

SEZNAM OBRÁZKŮ

65

Obrázek 16: IT support Incident management

41

Obrázek 17: Proces zacházení s tiketem v systému JIRA

42

Obrázek 18: Business Process Model: Business Intelligence

43

Obrázek 19: Globální pohled na podnikový proces interní IT podpory, vlastní práce. 44 Obrázek 20: Diagram aktivit manuálního monitorování kvót na poštovním serveru. 46 Obrázek 21: Business Process Model: Interní IT podpora

47

Obrázek 22: Současný způsob vedení inventury ICT majetku

48

Obrázek 23: Inventarizační štítek pro polepení majetku

50

Obrázek 24: Současný systém pro správu požadavků

53

Obrázek 25: Diagram případů užití navrženého systému

54

Obrázek 26: Diagram tříd navrženého systému

56

Obrázek 27: Náhled aplikace - přehled otevřených tiketů

65

Obrázek 28: Vytvořený tiket v systému

66

Obrázek 29: Editace tiketu

67

Obrázek 30: Správa adresáře

67

Obrázek 31: Správa oddělení

68

Přílohy

A

A

PŘEDSTAVENÍ APLIKACE

Představení aplikace

Obrázek 27: Náhled aplikace - přehled otevřených tiketů

67

A

PŘEDSTAVENÍ APLIKACE

Obrázek 28: Vytvořený tiket v systému

68

A

PŘEDSTAVENÍ APLIKACE

Obrázek 29: Editace tiketu

Obrázek 30: Správa adresáře

69

A

PŘEDSTAVENÍ APLIKACE

Obrázek 31: Správa oddělení

Zkušební uživatelský účet do systému: login: user heslo: userH3sl0 Zkušební administrátorský účet do systému: login: admin heslo: adminH3sl0

70