Fakulta informatiky a managementu - Theses · Univerzita Hradec Králové Fakulta informatiky a managementu Katedra Informatiky a kvantitativních metod Firemní procesy (správa,

Univerzita Hradec Králové

Fakulta informatiky a managementu

Katedra Informatiky a kvantitativních metod

Firemní procesy

(správa, údržba a inovace firemních procesů zaměřených na vývoj a

implementaci systému ERP)

Bakalářská práce

Autor: Jan Nisler

Studijní obor: Informační management

Vedoucí práce: doc. RNDr. Petra Poulová, Ph.D.

Hradec Králové Duben 2015

Prohlášení:

Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a s použitím

uvedené literatury.

V Hradci Králové dne 23.4.2015 Jan Nisler

Poděkování:

Děkuji vedoucímu bakalářské práce doc. RNDr. Petře Poulové, Ph.D. za

metodické vedení práce.

Anotace

Tato práce je zaměřena na firemní procesy, jejich inovaci a údržbu. V jedné

nejmenované IT firmě, která pracuje dle firemních procesů nadefinovaných již

řadu let, bylo rozhodnuto pokusit se provést jejich další optimalizaci podle

aktuálních obchodních a organizačních podmínek. Rozhodnuto bylo zaměřit

pozornost této práce na řešení procesů zpracování reklamace. Podstatnou součástí

cíle se stala také forma dokumentace k jednotlivým procesům. Zadavatel

požadavku se v řadě případů těžko rozhodoval mezi novým požadavkem na

systém a reklamací existující funkcionality. Tím docházelo k časovým prodlevám

před vlastním řešením. Základním krokem postupu bylo zvoleno vymodelování

procesních vláken v grafickém prostředí. Poté byla tato vlákna zanalyzována, a na

základě získaného rozboru a s ohledem na jejich potřebné zefektivnění bylo

navrženo řešení procesního vlákna nové, které by posunulo rozhodování

k relevantní roli v systému řízení vlastního vývoje. Řešení spočívá v tom, že

rozhodnutí o tom, jakého typu založený požadavek je, již nemá ve svých rukou

zadavatel, ale vedoucí pracovník vývoje. Tímto krokem také došlo ke zpřesnění

statistik právě v oblasti reklamací, což je důležitý aspekt pro firmy, jejichž vývoj

informačního systému je řízen normou ISO.

Annotation

Title: Business Processes

This work is focused on business processes, their innovation and

maintenance.In one unnamed IT company which works according to predefined

business processes for many years, a decision was made to run a further

optimization, based on current business and organizational issues. The focus was

directed to processes solution and the dealing with complaints. A substantial part

of the objective was the process specific documentation. Sponsor’s requirement

swayed in many cases between the new system requirements and the change of

existing functionality which delayed the actual solution. The solution was to split

the process in its entire complexity into individual process streams in a graphical

environment. Once these streams were analysed based on the analysis obtained

with regard to their needs to streamline, a new procedural streams have been

proposed. This shifted the decision-making to its relevant role in its own

development. The solution lies in the ownership of such decision making, where

the determination of requirement is no longer in the hands of the sponsor, but it is

owned by the development executive. This step improved the accuracy of statistics,

particularly in the area of complaints, which is an important aspect of a company,

who’s information system development is controlled by ISO.

1. Úvod ....................................................................................................... 1

2. Cíl práce ............................................................................................... 2

2.1. Teoretická část ............................................................................................... 2

2.2. Praktická část.................................................................................................. 2

3. Teoretická část .................................................................................. 3

3.1. Firemní procesy ................................................................................................................ 3

3.2. Agilní metodiky ................................................................................................................ 3

3.2.1. Scrum .................................................................................................................. 5

3.3. Modelovací nástroje...................................................................................................... 6

3.3.1. Enterprise Architect ...................................................................................... 6

3.3.2. Použité diagramy ............................................................................................ 6

3.3.3. Šablona na dokumentaci ........................................................................... 14

3.3.4. Word................................................................................................................. 14

3.4. Modelovací jazyk............................................................................................................15

3.4.1. Syntaxe UML a její metodika .................................................................... 15

3.4.2. Syntaxe BPMN a její metodika ................................................................ 16

4. Praktická část................................................................................... 17

4.1. Stávající procesy a vygenerovaná dokumentace ..........................................17

4.1.2. Požadavek zákazníka ................................................................................. 21

4.1.3. Reklamace ...................................................................................................... 23

4.1.4. Interní požadavek ....................................................................................... 24

4.1.5. Podřízený požadavek ................................................................................. 26

4.2. Statistické vyhodnocení procesů...........................................................................30

4.3. Analytické vyhodnocení procesů ..........................................................................33

4.4. Návrh na zlepšení ..........................................................................................................33

4.4.3. Požadavek zákazníka ................................................................................. 39

4.4.4. Řešení požadavku ....................................................................................... 41

4.4.5. Reklamace ...................................................................................................... 43

4.5. Implementace ..................................................................................................................44

4.6. Shrnutí a vyhodnocení ................................................................................................44

5. Závěr .................................................................................................... 45

6. Poděkování ....................................................................................... 45

7. Seznam použité literatury ........................................................... 46

8. Přílohy ................................................................................................. 47

8.1. Příloha A .............................................................................................................................47

8.2. Příloha B .............................................................................................................................49

8.3. Příloha C .............................................................................................................................54

8.4. Příloha D .............................................................................................................................57

Seznam obrázků

Všechny uvedené obrázky jsou vytvořeny v prostředí Enterprise Architect a

autorem všech obrázků je Jan Nisler.

Obrázek 1 procesní diagram ........................................................................................................... 7

Obrázek 2 Task ..................................................................................................................................... 8

Obrázek 3 Sub-proces ........................................................................................................................ 8

Obrázek 4 brána ................................................................................................................................... 8

Obrázek 5 Události .............................................................................................................................. 9

Obrázek 6 Bazén a dráha .................................................................................................................. 9

Obrázek 7 Datové objekty ..............................................................................................................10

Obrázek 8 Anotace.............................................................................................................................10

Obrázek 9 Datové uložiště ..............................................................................................................10

Obrázek 10 Zpráva ............................................................................................................................10

Obrázek 11 Spojovací objekty .......................................................................................................11

Obrázek 12 Aktér ...............................................................................................................................12

Obrázek 13 Typová úloha ...............................................................................................................12

Obrázek 14 Vztahy ............................................................................................................................13

Obrázek 15 Boundry .........................................................................................................................14

Obrázek 16 Požadavek zákazníka ...............................................................................................22

Obrázek 17 Reklamace ....................................................................................................................24

Obrázek 18 Interní požadavek .....................................................................................................26

Obrázek 19 Use Case Model ...........................................................................................................29

Obrázek 20 Graf přehledu použitých procesu ........................................................................30

Obrázek 21 Graf četnosti Procesů ...............................................................................................31

Obrázek 22 Zatíženost procesů 2010-2014 ............................................................................32

Obrázek 23 Požadavek od zákazníka .........................................................................................40

Obrázek 24 Řešení požadavku ......................................................................................................42

Obrázek 25 Reklamace2 ..................................................................................................................43

1

1. Úvod

Firemní procesy jsou jedna z nejdůležitějších procedur v každé firmě.

Napomáhají při řízení každodenních činností a přispívají k efektivnímu řízení a

fungování firmy a tím i jejím nejlepším hospodářským výsledkům. Při tvorbě

takovýchto procesních vláken se dnes používají různé metodiky s trendem

k metodikám agilním. Příkladem takové agilní metodiky jsou například metodiky

Scrum či XP. Agilní metodika je cílená k rychlému vývoji softwaru, který se

flexibilně upravuje, dle požadavků zákazníka. Co přesně znamená agilní metodika,

a jaké má základní principy, se lze dočíst v podkapitole 3.2.

Firemní procesy vytváří týmy manažerů, kteří jsou odpovědni za jednotlivé

skupiny pracovníků. Sami manažeři musí mít jasný přehled o lidech a jejich

schopnostech ve svém týmu, aby mohli vytvořit přesné procesy, lokalizované na

potřeby firmy. Dobře sestavené firemní procesy jsou nejen přínosem ve fungování

firmy, ale také dopomáhají k efektivnímu vztahu se zákazníkem. Aby mohli být

procesy využity v maximální míře, je důležitá dobrá komunikace. Komunikace na

pracovišti je zásadní v otázce: „Budou procesy fungovat dobře?“. Ano budou, ale

pouze tehdy, když lidé budou mezi sebou komunikovat a vytvářet dobré

profesionální vztahy. Když jeden člověk nebude dělat to co má, může se stát, že se

celý tým rozpadne. Proto je vedle firemních procesů důležité mít kvalitní firemní

kulturu, aby se vztahy mezi zaměstnanci utvářely efektivněji.

Vznik nových, či úprava starých procesů, ale vyžaduje čas a také prostředí,

ve kterém se mohou takové procesy vytvářet. Nejjednodušší prostředí je textové.

Tužka a papír postačí na skici prvotních plánů procesů. Problém, zde ale nastává

při jejich údržbě. Každý systém i procesy se vyvíjí a zdokonalují, takže tužka a

papír již nestačí. Vše se usnadnilo s příchodem modelovacích nástrojů. Zde si

člověk může namodelovat procesy graficky, upravovat je a inovovat. Grafické

prostředí dopomáhá k lepšímu porozumění procesu a k zamezení redundance.

Jedním z takových nástrojů, který je použit pro tuto práci, je case nástroj

Enterprise Architect (zkráceně jen EA) verze 11 od australské firmy Sparx.

(Nástroj a jeho diagramy jsou popsány v podkapitole 3.3.1.).

2

2. Cíl práce

V průběhu svého studia jsem spolupracoval v nejmenované firmě, která se

zabývá vývojem informačního systému pro řízení výrobních podniků třídy ERP. Jak

lze očekávat, firma pro tyto účely používá na úrovni intranetu vlastní systém pro

řízení vývoje tohoto informačního systému. Systém umožňuje dynamickou tvorbu

workflow a lze tedy velmi rychle reagovat na změny v organizaci či v postupech.

Systém ve firmě funguje již řadu let, co však chybělo, byla kvalitní názorná

dokumentace aktuálně používaných vláken. Cílem této mé práce je tedy

vymodelování firemních procesů IT firmy v oblasti vývoje informačního systému,

jejich analýza, a pokusit se navrhnout případná zefektivnění.

Práce je rozdělena na několik částí.

2.1. Teoretická část

První část je zaměřena na teoretické znalosti v oblasti procesů, agilní

metodiky, jazyka UML 2.0., jazyka procesního modelovaní BPMN 2.0. a

modelovacího nástroje EA.

2.2. Praktická část

Druhá část se zabývá praktickým využití teoretických znalostí v procesu

vývoje informačního systému. Sestavené a vymodelované procesy jsou následně

zanalyzovány a vyhodnoceny. Součástí vyhodnocení je také návrh na řešení

specifických kroků a jejich zefektivnění. Po schválení procesních vláken je

provedena implementace do aktuálního stavu řízení systému a po určité době

probíhá pravidelná kontrola a jejich vyhodnocení.

3

3. Teoretická část

3.1. Firemní procesy

Procesy můžeme nalézt všude kolem nás, v každé lidské činnosti. Pro firmy

se však vyčleňují a stávají se samostatnými procesy definovanými pouze pro

vnitřní know-how. Takové procesy lze definovat mnoha formami, jako příklad lze

uvést: Firemní proces je cyklicky opakující se seznam činností firmy, probíhající

v rámci konkrétního projekt.[1]

Tuto definici můžeme chápat, jako jednotlivé kroky jdoucí dle určitého

schématu, a které se opakují. Požadavky na vývoj systému jsou různého typu a

každý typ vyžaduje jiné procesní vlákno, tedy jinou posloupnost kroků.

3.2. Agilní metodiky

Tyto metodiky se zaměřují na rychlý vývoj systému, jeho udržování a

změnu podle požadavků zákazníka.[2] Agilní je v překladu čilý, hbitý. Nové funkce

jsou do systému přidávány zrychleným tempem pro co nejrychlejší otestování

zákazníkem.[3] Po testování dává zákazník co nejrychleji zpětnou vazbu

vývojovému týmu, který v následující iteraci reaguje na jeho připomínky.[2]

Agilní vývoj softwaru se zaměřuje na konkrétní cíle a principy:

Spokojený zákazník

Zákazníkovým cílem je jeho dobře fungující informační systém, který

napomáhá efektivnímu řízení firmy ve všech oblastech jeho potřeby.[3]

Nadstandardem jsou UML diagramy, či rozsáhlá dokumentace. Představy

zákazníka o vlastnostech informačního systému jsou pro vývoj velmi důležité.[2]

Dnes se každý požadavek, či návrh může měnit velmi rychle, proto i na takové

změny a tempo musí být vývojový tým připraven. [2]

Vítané změny

Jakákoliv změna funkcionality je zpracovávána pečlivě a efektivně a tím se

eliminují nechtěné dopadům. [2]

4

Iterativní vývoj

Software je dodáván zákazníkovi v několika opakujících se krocích,

iteracích.[3]

Definování požadavku

Základem dobře vypracovaného systému je přesné a úplné definování

obsahu požadavku zákazníkem.[3] Během vývoje je každý požadavek zpřesňován a

projednáván s vývojovým týmem. [2]

Lidský faktor

Veškeré technické dovednosti jsou důležité, ale je to lidský faktor, nejslabší

článek, který ovlivňuje výsledek. [2] Pro zvýšení šance na úspěch je dobré dosadit

na místo vedoucího projektu člověka, který rozumí a zná nejlépe danou

problematiku. [2]

Vzájemná konverzace

Snížené množství dokumentace je odůvodněno faktorem rychlého vývoje a

rychlých úprav v softwaru, proto nejlepší dokumentací je konverzace.[2]

Napomáhá k lepšímu porozumění, je rychlejší a méně náročná na údržbu. [2]

Primární míra úspěchu

Na každý systém je nutné mít dobře vypracovaný plán postupu. Definice

požadavků, návrh, programování, testování a implementace. [2] Pokud se podcení

čas libovolného z těchto kroků, může zhavarovat celé předání systému

zákazníkovi. Zákazník je nespokojen a ztrácí důvěru.[3]

Udržitelný vývoj

Každý systém se vyvíjí určitou dobu. Z pohledu vývojářů jsou velké nároky

na čas strávený v práci.[3] Takový nápor se musí regulovat určitým pracovním

tempem, který je nutno dodržovat, aby byl celý tým tzv. zdravý. Tím se eliminují

chyby z přepracování. [2]

5

Technické řešení a návrh

Kvalita softwaru je zásadní v celém průběhu požadavku. Návrhu je potřeba

věnovat velkou pozornost.[2] Návrh tvoří 70% času celého vývoje informačního

systému. [2]

Jednoduchost

Jednoduchost postupů dopomáhá k rychlejší změně. Je-li vývoj software

rozdělen na dílčí etapy, je tento vývoj efektivnější než kdyby probíhal celý vývoj

v jediné iteraci. [2]

Samoorganizující týmy

Kreativita lidí v týmu dopomáhá k lepším postupům vývoje softwaru. [2]

Vnitřní komunikace přispívá k vyladění všech nastalých problémů a k účinnější

práci celého týmu. [3]

3.2.1. Scrum

Scrum je jednou z agilních metodik vývoje softwaru. Někdy je nazývána

„jazykem vzorů, pro vývoj software“. [2]

Celý software se vyvíjí v určitých časových intervalech, které se nazývají

„Sprinty“. Takové období trvá zhruba 1 měsíc. Každá fáze životního cyklu je

mapována, ovšem v žádné z nich se nedefinují procesy. [2] Předpokladem jsou

časté schůzky, které by měly vést k lepšímu porozumění činnostem, které se budou

provádět. Změny požadavku se díky tomuto požadavku velice rychle zakomponují

do původního řešení. [2] Na každé schůzce jsou definovány kroky, které je potřeba

zpracovat, a které byly od posledního meetingu realizovány. Veškeré sprinty končí

konfrontací výsledků se zákazníkem. Vše se testuje, aby se zamezilo případným

chybám. [2]

6

3.3. Modelovací nástroje

Pro vytváření všech daných materiálů, se používají dva modelovací nástroje.

Pro modelování je použit case nástroj Enterprise Architect verze 11, s jehož

pomocí se modelují veškeré diagramy. Pro vytváření dokumentace a analýzy se

pracuje s textovým editorem Word 2010 a Word 2013.

3.3.1. Enterprise Architect

Tento nástroj byl vyvinut australskou společností Sparx a je dodnes

používán jako pomocník ve světě IT i mimo něj. Enterprise Architect je nástroj

kategorie case, určený pro analýzu systému, jeho realizaci a také údržbu celého

životního cyklu. Informační systém je vymodelován pomocí jednotlivých elementů,

podle funkčnosti a odbornosti. Toto grafické znázornění, napomáhá k lepšímu

porozumění celého systému a jednoduše tak lze dosáhnout co nejefektivnějšího

průběhu veškerých činností. Snadná použitelnost dopomáhá uživateli přednést

plány svému zákazníkovi, a tak je celá spolupráce snadnější a srozumitelnější. Díky

grafickému a přesně danému obsahu je zamezeno redundanci dat. Pro tyto účely a

pro práci na tomto materiálu je používána verze 11 tohoto nástroje. Je potřeba

zmínit, že takovýchto nástrojů, kategorie case, existuje ve světě celá řada, některé

z nich jsou i lepší a propracovanější, ale v porovnání cena versus možnosti je tento

nástroj zcela postačující a vyhovující, o čemž svědčí jeho široké uplatnění a

nasazení v portfoliu českých firem.

3.3.2. Použité diagramy

Pro zobrazení všech procesů, stávajících i nově vzniklých, se bude používat

Procesní diagram. Pomocí tohoto diagramu bude znázorněn procesní tok, všech

procesů, které se v dané firmě vyskytují.

Pro znázornění, které role zaměstnanců pracují s procesy, bude sloužit

model Use case diagram.

7

Obrázek 1 procesní diagram

3.3.2.1. Procesní diagram

Procesní diagram za použití notace BPMN (zkráceně proto BPD) je diagram

zachycující strukturu aktivit, jejich provázanost a postavení v celé hierarchii. Tyto

diagramy jsou používány pro jejich grafické znázornění a úpravu. BPD se snaží

nahradit známý digram aktivit v notaci UML. Procesní diagram zpracovává vnitřní

struktury firmy. Používají se nejenom jako grafické znázornění systémových

procesů, ale taktéž zachycují celý průběh jednotlivých zakázek či firemního

managementu. Pomocí těchto diagramů vznikají Procesní mapy systému a jejich

údržba je proto přehlednější a efektivnější.

V procesním diagramu jsou popsány veškeré firemní procesy, které v dané

firmě probíhají pro vývoj software. Zavedena jsou základní rozlišení podle typu

požadavku na systém. Každý diagram zde reprezentuje jeden typ požadavku. Jsou

to požadavky: Interní požadavek, Reklamace, Požadavek zákazníka na systém

Základními prvky tohoto diagramu jsou tyto elementy:

8

Obrázek 2 Task

Obrázek 3 Sub-proces

Obrázek 4 brána

Aktivita

Jedná se o činnost, kterou vytváří daný systém či člověk. Přechod mezi

aktivitami je znázorněn vazbou. Všechny propojené aktivity jsou takto

hierarchicky spouštěny. Ukončení aktivity vyvolá začátek další činnosti, která

následuje za právě ukončenou aktivitou.

Task

Činnost či běžný krok nějakého algoritmu nebo procesního postupu. Při

zapisování je důležité dbát na správné pojmenování, proto každá aktivita musí být

zapisována jako sloveso.

Každou aktivitu můžeme definovat těmito body:

Atomická – aktivitu nemůžeme dále dělit.

Nepřerušitelná – když je aktivita spuštěna vždy proběhne celá

Okamžitá – je to činnosti, které proběhne okamžitě

Aktivity jsou znázorněny obdélníky s oblými rohy (viz obrázek č. 2)

Sub-proces

tyto aktivity, se mohou dále dělit na další aktivity či

akce. Lze je zastavit či omezit pomocí některých podmínek.

Sub-proces obsahuje další digramy, ve kterých jsou

znázorněny další úrovně systému. Tyto typy aktivit se

používají při modelování složitějších systémů, kde je potřeba systém hierarchicky

rozčlenit na jednotlivé úrovně. Je označován obdélníkem s oblými rohy a v pravém

dolním rohu je znázorněn proces (viz obrázek č. 3)

Brána

Element, který rozděluje dosavadní tok aktivit. Může aktivity

spouštět paralelně, podle podmínek určit, kterým směrem

se povede tok aktivity a spojovat více toků do jednoho. Pro jednoduchost vizuální

stránky je brána znázorněna jako prázdný kosočtverec (viz obrázek č. 4)

9

Obrázek 6 Bazén a dráha

Obrázek 5 Události

Události

Elementy vyobrazené kolečkem (viz obrázek č. 5) slouží, jako události

zasahující do diagramu, jsou trojího typu:

StartEvent -

událost stojící na začátku celého procesu,

slouží jako počáteční událost.

Intermediate Event

Událost, která je v průběhu diagramu, je to například mezi-vstup do

diagramu či jeden z možných výsledků celého diagramu.

EndEvent

Událost, která je výstupem celého diagramu, stojí vždy na konci jako

poslední element.

Bazén (Pool)

Element, který rozděluje danou

oblast do určitých podskupin, je dále

rozčleněn do drah (Line).

Jednotlivé dráhy mohou

reprezentovat například případy užití,

provázanost s jinými elementy, provázanost s rolemi, které za danou aktivitu

zodpovídají, či v modelování obchodní domény u organizačních jednotek. Takto

vytvořené rozdělení oblasti nám pomáhá určit jaké postupy a aktivity jsou

potřebné v jakém procesu. Bazén je vyobrazen jako nedokončený obdélník

s dvěma čarami na vrchní straně s názvem uprostřed. (viz obrázek č. 6)

Existují dva druhy bazénu:

Zhroucený bazén – bazén, ve kterém nejsou žádné další procesy, neznáme je

a převážně slouží například ke komunikaci mezi bazény. Neví se, jak v nich funguje

proces, a co s čím souvisí, například bazén Dodavatel, či Odběratel.

Otevřený bazén – bazén, ve kterém jsou ukázány všechny jeho procesy

10

Obrázek 8 Anotace

Obrázek 9 Datové uložiště

Obrázek 10 Zpráva

Dráhy

Dráhy slouží jako vnitřní dělení bazénu do určitých kategorií, jež jsou

podmnožinou bazénu. Vzhledem připomínají bazén a liší se na vrchní straně u

názvu bazénu. (viz obrázek č. 6)

Artefakty

Objekty rozšiřující diagramy o další popisy, jsou spojeny s tokem či

ostatními elementy pomocí vazby asociace.

Datové objekty (data objects)

Jsou to vstupní nebo výstupní data aktivit,

znázorněny jsou jako list s ohnutým pravým horním

rohem, vstupní data jsou zastoupena prázdnou

šipkou, výstupní plnou šipkou. (viz obrázek č. 7)

Anotace

Slouží jako rozšiřující popis diagramu, tento

textový se používá k upřesnění cesty, či dalšímu popisu

jednotlivých elementů.

Je vyobrazena jako nedokončený obdélník, který ohraničuje text.

(viz obrázek č. 8)

Datové úložiště

Tento artefakt slouží k uchování nebo získání dat, která jsou pro průběh

celým systémem nezbytná.

Vzhled připomíná válec s několika víky na sobě (viz obrázek č. 9)

Zpráva

Slouží jako ukazatel odesílání dat, příkladem mohou být

data, která jsou zaslána na proces. Proces reaguje na zprávu

Obrázek 7 Datové objekty

11

Obrázek 11 Spojovací objekty

určitým sub-procesem, taktéž to může být podmínka pro pokračování toku

v procesu.

Je označena jako obálka (viz obrázek č. 10)

Spojovací objekty

Slouží ke spojení elementů v daném diagramu,

pro spojování elementu v BPD jsou tři základní typy

vazeb:

Sekvenční tok (sequence flow)

Vazba, která spojuje jednotlivé aktivity

s ostatními aktivitami.

Nesmí přesahovat vlastní sub-proces.

Označuje se plnou čarou s černou šipkou ve směru běhu procesu (viz

obrázek č. 11)

Tok zpráv (Message flow)

Vazba slouží ke komunikaci mezi bazény, jedná se tedy o zprávy, které jsou

zasílány od dodavatele či jiného systému.

Tyto zprávy mohou být spouštěčem pro chod dalšího průběhu procesu.

Tok zpráv je naznačen přerušovanou čárou, prázdným kolečkem na začátku

a prázdnou šipkou ve směru toku. (viz obrázek č. 11)

Asociace (Association)

Obecná vazba spojující artefakty k objektům. Je znázorněna přerušovanou

čárou s prostou šipkou ve směru, je také označována bez šipky, v tomto případě se

jedná pouze o prostou vazbu bez směru nejčastěji spojenou se sekvenčním tokem.

(viz obrázek č. 11)

12

Obrázek 12 Aktér

Obrázek 13 Typová úloha

3.3.2.2. Use case diagram

Tento model popisuje práci uživatele (taktéž i systému) se systémem. Je zde

zachycena komunikace mezi uživatelem a systémem. Je úzce spojen s předchozím

diagramem procesního modelu, rozšiřuje požadavky na systém z pohledu užití a

rozčleňuje hranice systému. Tento model vychází ze syntaxe UML, která je popsána

ve 4. kapitole. Diagram je tvořen 4-mi základními komponentami: Aktér, Typová

úloha (Use case), Vazby, Hranice systému (Boundry)[4].

Aktér

Jedná se o prvek (člověk, systém, čas), který komunikuje se

systémem a následně přijímá zprávy od systému, při některé z činnosti.

Může zastupovat až skupiny uživatelů, kteří mají

stejná přístupová práva, například administrátor, či zákazník. Vyobrazen bývá jako

panáček (viz obrázek č. 12).

Use case

Neboli typová úloha představuje činnost uživatele, kterou od systému

požaduje, jedna typová úloha = jedna činnost

Takto vytvořené typové úlohy mohou být propojeny i

s dalšími typovými úlohami, jako rozšiřující nebo rozšiřované

typové úlohy, z jiného úhlu pohledu mohou být děleny na vnější

a vnitřní. Vyobrazeny jsou jako elipsa (viz obrázek č. 13)

Vazby – (viz obrázek č. 14)

Use

Jednoduchá vazba spojující aktéra s typovou úlohou,

Je vyobrazena jako plná čára bez směru

13

Obrázek 14 Vztahy

Extend

Vazba, která spojuje typové úlohy mezi sebou, jedná se o

rozšíření původní typové úlohy o další, která se ovšem spouští

za určitých podmínek a nemusí nastat vždy.

Dnes už méně používaná pro svou omezenou funkčnost,

více používána místo extend je vazba generalizace[4]. Vazby je

znázorněna přerušovanou šipkou od rozšiřující typové úlohy

k rozšiřované.

Include

Vazba spojuje typové úlohy mezi sebou, taktéž jako u extend rozšiřuje

původní typovou úlohu o další, tato typová úloha je ovšem spouštěna vždy, může

se jednat o společnou typovou úlohu pro více úloh, vzniká tzv. vytknutím stejné

části scénáře původních typových úloh. Jako příklad lze uvést: Ověření

bezpečnostního klíče, registrování zákazníka.[4]

Vazba je znázorněna stejně jako extend ale směr vazby je určen od typové

úlohy rozšiřované k typové úloze rozšiřující.

Generalizace

Vazba, kterou lze použít jak mezi aktéry, tak typovými úlohou, vždy však

mezi stejným typem elementu.

Vazba spojuje předka s potomkem, tedy dva aktéry, kdy jeden vychází

z druhého, stejně tak typové úlohy, které mají stejný základ. Tito potomci přebírají

veškerý základ z předka, a sami mohou být rozšířeni o nové vlastnosti.[4]Vazba je

vedena od potomka k předkovi plnou čarou, na konci s plnou šipkou.

14

Obrázek 15 Boundry

Hranice systému

Uzavřený obdélník, který rozděluje jednotlivé

typové úlohy do rámce jednoho systému (viz obrázek č.

15). Slouží k lepšímu rozlišení typových úloh mezi

sebou.[4]

3.3.3. Šablona na dokumentaci

Šablona bude sloužit pro vygenerování dokumentace z prostředí Enteprise

Architect. Tato dokumentace bude obsahovat všechny diagramy a elementy. Ke

všem entitám jsou připojeny jejich popisky, aby si v něm mohl čtenář stručně

listovat a dokázal porozumět veškerým informacím. Je důležité, aby u každého

elementu existovaly popisky z důvodu zamezení redundance. Výstupem

dokumentace bude soubor s příponou docx. Možný je také výstup v podobě pdf a

rtf souboru. Celkový vzhled šablony se vytváří za pomoci editoru, který je součástí

Enterprise Architectu. Pro jednoduchost a čitelnost celého projektu, jsou zde

použity pouze informace o názvu elementu, typu elementu a o verzi elementu.

Součástí budou popisky ke všem entitám a diagramům.

3.3.3.1. Vzhled šablony

Na úvodní straně je vyobrazeno logo divize, pro níž jsou tyto zpracované

procesy modelovány. Na druhé straně je osnova celé dokumentace, tato osnova se

mění podle velikosti projektu. Na třetí straně jsou popsány jednotlivé informace,

jež mají být obsaženy ve vygenerované dokumentaci, Prostředí, do kterého jsou

tyto informace generovány, jsou žlutě zvýrazněna. Celou šablonu je možné si

prohlédnout v příloze A.

3.3.4. Word

Tento modelovací nástroj je využit jako textové doplnění grafického

znázornění všech procesů. V tomto prostředí jsou všechny diagramy vygenerované

z Enterprise Architectu. Jednotlivé typy procesů, které jsou namodelovány a

zdokumentovány jsou následně propojeny a ke každému procesu jsou přidány

15

další popisy, statistiky používání a časová náročnost každého procesu z pohledu

firmy a zákazníka. Celková dokumentace je vyhodnocena a zanalyzována. Veškerá

zpráva a analýza je vyhotovena do stejné dokumentace ke každému procesu a je

předávána manažerovi, který za daný průběh odpovídá a vlastní průběh řídí.

3.4. Modelovací jazyk

Pro modelování všech procesů byly zvoleny dva jazyky, ve kterých se

všechny procesy graficky vymodelují. Jak bylo zmíněno v předchozí kapitole, jedná

se o jazyk BPMN, který se zaměřuje na tvorbu business procesů a jazyk UML, ve

kterém se zde vymodelují typové úlohy. Samotné jazyky mají určitou metodologii a

metodiku, podle kterých se modely zpracovávají. Tyto metodiky byly pro účely

tohoto materiálu upraveny, aby byli co nejefektivnější. Pro teoretickou část práce

jsou uvedeny i malé útržky historie a vývoje jazyka.

3.4.1. Syntaxe UML a její metodika

UML (Unified Modeling Language neboli Unifikovaný modelovací jazyk),

slouží pro grafické znázornění celého systému z různého úhlu pohledu.

K vymodelování veškerých stránek systému nám slouží velká škála diagramu.

Každý diagram má za úkol nahlížet na systém z jiného směru, abychom obsáhli

veškerou funkčnost systému. Příklad takového diagramu je Use Case diagram,

který je v této práci použit. Tento model se zaměřuje na komunikaci mezi

uživatelem a systémem. Jednotlivé kroky a reakce systému na příkaz uživatele se

píší do scénářů každé typové úlohy. Pro účely této práce je ovšem metodika

pozměněna. Z důvodu vnitřní hierarchie, jsou zde jednotlivé role aktéra zaměněny

za jednotlivé profese. Tato změna je odůvodněna celkovým náhledem na to, jaké

profese se podílejí na průběhu firemních procesů vývoje informačního systému.

16

3.4.2. Syntaxe BPMN a její metodika

Business process modeling slouží pro grafické znázornění všech

podnikových procesů v dané firmě za pomoci procesních diagramů. Syntaxe BPMN

(Business Process Modeling Notation) byla vytvořena společností OMG (Object

Management Group) v roce 2007 jako verze 1.1 a nyní je na trhu verze 2.2, která

vyšla v roce 2014. Tato verze se od původní velice liší, jak svým přístupem, tak i

množstvím elementů, které poskytuje pro uživatele. BPMN je sama o sobě určitou

metodikou, ale až samostatné firmy si ji upravují podle svých představ. Proto

existuje na světě mnoho známých metodik, jak vytvářet zmiňované diagramy.

Příkladem takových to metodik jsou Togaf či Zachman. Nikde však nelze nalézt,

které postupy jsou naprosto bezchybné, a které se nejvíce hodí pro danou oblast.

Pro tuto práci tedy nebyla použita specifická metodika, ale vytvořené diagramy

byly konzultovány s odborníky, kteří se v touto oblastí zabývají.

17

4. Praktická část

4.1. Stávající procesy a vygenerovaná dokumentace

Prvním krokem této práce je vymodelování aktuálních procesů, které se

používaly ve firmě od začátku roku 2010. Procesy však nebyly dostatečně názorně

popsány a zdokumentovány. Firma pro vývoj používala 4 základní typy procesního

vlákna. Procesní vlákna byla realizována v interním informačním systému na

intranetu firmy. Ke každému elementu byly přidány alespoň základní popisky.

Zmiňovaná procesní vlákna jsou uvedena na obrázku č. 16 - 19.

V následující části jsou rozebírané procesy popsány do jednotlivých kroků,

které definují obecně stanovené činnosti určené pro řízení vývoje a vlastní vývoj

informačního systému. V každém kroku je definována možnost posunu vpřed

(krok následující) nebo vzad (krok předchozí), pokud byl zjištěn nedostatek

výsledku předchozího kroku. Každý model je vybaven textovým popisem tak, aby

veškeré procesy byly dobře, srozumitelně a kvalitně zdokumentovány, a tím bylo

možno v budoucnu je dále upravovat a optimalizovat dle aktuálních potřeb.

Protože firma pro vlastní vývoj svého produktu používá case nástroj Enterprise

Architect, tento nástroj byl zvolen i pro vlastní vymodelování a popis procesů.

V programu Enterprise Architect, bylo možné pomocí šablony pro

dokumentaci, vygenerovat z grafického modelu i textový popis. Jednotlivá

dokumentace pro každý proces je obsažena v přílohách B až E této práce.

Na začátku jsou popsány všechny již zmíněné činnosti, které se v procesních

vláknech vyskytují. U jednotlivých vláken jsou pak uvedeny pouze názvy kroků, jež

jsou nositeli daných činností. Toto zobecnění umožňuje také vyhodnotit jednotlivé

činnosti bez závislosti na příslušném vlákně.

18

4.1.1. Definované činnosti

Následující seznam všech činností je setříděn abecedně sestupně.

Zadaní požadavku

Zadavatel založí požadavek na doplnění funkcionality do aktuální verze

vyvíjeného informačního systému. Základní nejpodstatnější povinnou součástí je

podrobný a úplný popis požadovaného rozšíření. Přesnost a úplnost tohoto popisu

úměrně zvyšuje jistotu, že bude dosaženo požadovaného cíle. Jedná se o jednu

z nejkritičtějších činností celého procesu, neboť plně závisí na lidském faktoru a

komunikaci.

Vypracování řešení

Vedoucí vývoje zadává úkol na konkrétního programátora, s cílem

vypracovat zdrojový kód na základě dodaného návrhu řešení od designera. Pokud

se jedná o složitější projekt, zadává vedoucí vývoje dílčí úkoly na větším tým

programátorů (systémových, aplikačních). Každá naprogramovaná část je

programátorem ihned otestována a zdokumentována v tzv. programátorské

dokumentaci a popsána v žurnálu změn.

Testování zadavatelem

Zadavatel provede otestování vypracované řešení na základě svého zadání a

přiloženého testovacího předpisu. Pokud jsou potvrzeny předpokládané výsledky,

vypracovaný požadavek posunut do distribuce. Pokud je nalezen rozpor,

požadavek se vrací zpět do vývoje s popisem připomínek k řešení.

Testování testovacím oddělením

Testovací oddělení otestuje vypracované řešení podle zadaného testovacího

přepisu a poskytnutých dat. Pokud se v testování neobjeví žádná chyba, je nové

řešení předáno zadavateli k jeho vlastnímu otestování. Pokud se při testování

vyskytly chyby, je řešení vráceno k opětovnému vypracování.

19

Převzetí zákazníkem

Zákazník si požadavek převezme a ověří, zdali je vypracován v souladu

s jeho objednávkou. Pokud byl požadavek vypracován v souladu, potvrdí jej a

požadavek postupuje k fakturaci. Pokud zákazník nalezne rozpor popřípadě chybu,

vrací jej k otestování do testovacího oddělení.

Prověření zadavatelem

Tato činnost souvisí se vznikem a řešením reklamace. V této činnosti

zadavatel provede otestování reklamované funkčnosti a tím směřuje k potvrzení

oprávněnosti reklamace.

Prověření testovacím oddělení

Tato činnost je opět určena pro řešení reklamace. Testovací oddělení

otestuje označenou část systému, ve které je chyba nahlášena. Testování

požadavku je prováděno na základě tzv. testovacího předpisu za pomocí

připojených konkrétních dat. Pokud se chyba testováním nepotvrdí, požadavek je

s příslušnou informací vrácen do předcházejícího kroku zadavateli, opačném

přechází požadavek do dalšího kroku k řešení.

Posouzení zadavatelem

Zadavatel posoudí hrubý návrh řešení, který připravil vývoj, zkonzultuje ho

se zákazníkem a předkládá mu nabídku s časovou a cenovou kalkulací s termínem

platnosti dané nabídky. Zadavatel čeká na objednávku zákazníka.

Posouzení vývojem

Cílem této činnosti je zpracování hrubého návrhu řešení v dané konkrétní

technologii se stanovením kapacitní náročnosti požadovaného zákroku. Řešitelem

činnosti je role vedoucího vývoje, který zadává úkol na konkrétního designera,

který na základě zpracované analýzy odborného konzultanta vypracovává

příslušný hrubý návrh řešení. Zároveň stanovuje plán kapacitní náročnosti.

Vedoucí vývoje na základě těchto informací vkládá požadované kapacity do

kapacitního kalendáře oddělení, kapacity rezervuje, a tím navrhuje termín plnění a

předání požadavku. Zároveň zpracovává na základě kapacit náklady a minimální

20

prodejní cenu. Pokud však byly zjištěny nedostatky nebo nepřesnosti v analýze, je

požadavek vrácen zpět k odbornému konzultantovi k doplnění analýzy.

Posouzení odborným konzultantem

Odborný konzultant na oblast, do které obsahově požadavek spadá, provede

základní vyhodnocení, posoudí obsahovou dostatečnost a srozumitelnost. Pokud

zjistí závady čí nejasnosti v daném zadání, požadavek vrací zadavateli zpět

s informací o nutnosti doplnění a další specifikace. Základním úkolem odborného

konzultanta je vypracování analytického modelu požadavku a jeho začlenění do

celkové koncepce daného informačního systému. Tento analytický model je z velké

míry tvořen bez závislosti na konkrétní používané technologii, ale s důrazem na

obecnost a možnost parametrické konfigurace.

Odsouhlasení

Vedoucí realizace schválí celý požadavek a celý proces přechází do řešení.

Pokud vedoucí realizace neodsouhlasí požadavek, může jej stornovat, pozastavit,

nebo vrátit k zadavateli. Tyto kroky podpoří textem, s odůvodněním proč se takto

rozhodl.

Návrh řešení

Náplní této činnosti je na základě již zpracovaného hrubého návrhu řešení

vypracovat podrobný návrh a popis řešení pro programování. Tuto činnost opět na

základě úkolu vedoucího vývoje provádí vybrané designer. V této fázi je možno na

základě rozsáhlosti projektu rozvětvit vlastní vývoj do několika dílčích i

paralelních větví.

Konec požadavku

Požadavek je ukončen.

Fakturace požadavku

Po odsouhlasení a převzetí díla zákazníkem dává vedoucí divize pokyn do

ekonomického úseku k vystavení faktury a číslo této faktury je do požadavku také

vloženo.

21

Distribuce

Vypracovaný požadavek je distribučním oddělením zákazníkovi odeslán,

zároveň je toto předání zaprotokolováno.

4.1.2. Požadavek zákazníka

Každý požadavek zákazníka na úpravu informačního systému je zaevidován

do databáze všech požadavků a je odstartováno odpovídající procesní vlákno

(workflow). Vlákno je složeno z následujících kroků, kdy každý krok je nositelem

jedné činnosti, která je obsažena a popsána v seznamu všech činností

v předchozím bodě.

4.1.2.1. Textový popis procesního vlákna

Krok 1. Zadání požadavku

Krok 2. Posouzení odborným konzultantem

Krok 3. Posouzení vývojem

Krok 4. Posouzení zadavatelem

Krok 5. Odsouhlasení

Krok 6. Návrh řešení

Krok 7. Vypracování řešení

Krok 8. Testování tetovacím oddělením

Krok 9. Testování zadavatelem

Krok 10. Distribuce

Krok 11. Převzetí zákazníkem

Krok 12. Fakturace požadavku

Krok 13. Konec požadavku

22

4.1.2.2. Grafický model a dokumentace

Pro lepší názornost a srozumitelnost je vhodnější vizuální grafický model

daného procesního vlákna.

Obrázek 16 Požadavek zákazníka

23

Pro namodelovaný diagram nástroj Enterprise Architect umožňuje

vygenerovat i textovou dokumentaci v různých formátech. Tato dokumentace je

uložena v přílohách práce, viz příloha B

4.1.3. Reklamace

Zákazník či pracovník firmy, který zjistil chybu případně odlišnost od

dokumentace ve funkčnosti systému, nahlásí chybu na HelpDesku firmy. (Popis a

postup práce s HelpDeskem není součástí této práce.) Pověřený pracovník

prostuduje příslušný záznam a podle potřeby a oprávněnosti vytváří požadavek do

vývoje typu - reklamace. Jeho procesní vlákno se odlišuje od standardního

požadavku na vývoj. Cílem je popisovanou chybu prověřit, vyřešit a co nejdříve

předat zákazníkovi.

4.1.3.1. Textový popis:


Krok 2. Prověření zadavatelem

Krok 3. Prověření testovacím oddělení


Krok 5. Testování tetovacím oddělení


Krok 7. Distribuce


Jak je patrno, pro toto procesní vláno byly využity již existující činnosti

v rámci jeho vlastních kroků. Opět pro názornější způsob dokumentace, bylo

provedeno grafické vymodelování tohoto procesního vlákna. Zároveň byla opět

vygenerována dokumentace, jako v předchozím případě viz Příloha C.

24

4.1.3.2. Grafický model

4.1.4. Interní požadavek

Je logické a pochopitelné, že informační systém se nevyvíjí pouze na základě

konkrétních požadavků konkrétních uživatelů. Pracovníci vývojářské firmy

pozorně monitorují aktuální potřeby trhu, vyhodnocují postřehy z výběrových

řízení a sledují světové moderní trendy nejen v oblasti řízení podnikových procesů,

ale hlavně v oblasti informačních technologií. Rozvíjí se, a to velmi rychle, nejen

nové programové jazyky, frameworky a technologie, ale i nové prvky a principy

uživatelského rozhraní a ovládání. Kromě klasických klientských pracovišť se

dopředu derou mobilní zařízení, na kterých běží určitá varianta klienta, který

komunikuje s příslušným aplikačním serverem na různých bázích. Všechny tyto

Obrázek 17 Reklamace

25

aspekty samozřejmě velmi ovlivňují firemní procesy a je nutno na tyto trendy

rychle reagovat. Pro tyto účely bylo sestaveno speciální procesní vlákno, které

neobsahuje kroky pro komunikaci se zákazníkem.

4.1.4.1. Textový popis


Krok 2. Posouzení konzultantem




Krok 6. Tetování tetovacím oddělení

Krok 7. Tetování zadavatelem

Krok 8. Distribuce


Opět, jako v předchozím, byly pro toto procesní vlákno využity již existující

činnosti v rámci jeho vlastních kroků, byla vygenerována příslušná dokumentace. V

dokumentaci, bylo provedeno grafické vymodelování tohoto procesního vlákna.

Zároveň byla opět vygenerována dokumentace, jako v předchozím případě viz

Příloha D .

26

4.1.4.2. Grafický model

Obrázek 18 Interní požadavek

4.1.5. Podřízený požadavek

Jak již bylo zmíněno, tento typ požadavku je speciálním typem procesního

vlákna, je určeno pro interní potřeby vývojového oddělení a umožňuje rozdělit

rozsáhlejší projekt, definovaný jedním požadavkem zákazníka, na dílčí etapy

(představit si můžeme jako graf typu strom). Tedy jeden požadavek zákazníka se

skládá z n podřízených požadavků, každý takový podřízený požadavek se může

opět skládat z m dalších podřízených požadavků. Každá hladina těchto

podřízených požadavků se může vyvíjet samostatně a paralelně. Každý takovýto

podřízený požadavek se také samostatně testuje a je možno ho i samostatně

distribuovat zákazníkovi pro otestování a vlastní implementaci. Podřízený

požadavek je charakterizovaný následujícími kroky.

27







Krok 6. Testování testovacím oddělením


Krok 8. Distribuce


4.1.5.2. Grafický model a dokumentace

Obrázek 19 Podřízený požadavek

Opět je vygenerována příslušná dokumentace viz Příloha E

28

Use Case model není až tak podstatný pro účel této práce, přesto ho uvádím

z toho důvodu, aby bylo patrné, jaké role vystupují v jednotlivých procesech vývoje

informačního systému. Uvádím alespoň ty nejdůležitější.

Zadavatel požadavku

Jedná se o pracovníka vývojářské firmy, který na základě komunikace

s konkrétním zákazníkem zakládá požadavek do databáze požadavků, zpracovává

podrobný popis požadavku dle zmapované potřeby zákazníka. Úkolem zadavatele

je tedy komunikace se zákazníkem, zákazníkovi předkládá návrh řešení, termín a

cenu dodání, ve správném okamžiku testuje provedené úpravy a tyto úprav

předává zákazníkovi k implementaci.

Odborný konzultant

Informační systém třídy ERP pokrývá celou řadu odborných oblastí, každou

takovouto oblast má na starost minimálně jeden odborný konzultant. Ten se na

tuto oblast specializuje, sleduje trendy a potřeby trhu, analytický zpracovává každý

požadavek na rozvoj či doplnění do této oblasti a to obecně bez závislosti na

konkrétní technologii vyvíjeného informačního systému.

Vedoucí vývoje

Jedná se o manažera, který zodpovídá za celý vývoj informačního systému.

Zadává konkrétní úkoly designerům, kteří na základě zpracované analýzy

odborným konzultantem zpracovává návrh a popis řešení pro programování, a to

již v závislosti na konkrétní technologii. Dále řídí a zadává konkrétní úkoly

konkrétním aplikačním a vývojovým programátorům.

Pracovník distribuce

Je to pracovník, který řídí testování každé úpravy v testovacím oddělení a

dále zajišťuje distribuci všech úprav zákazníkům.

Na vývoji informačního systému pracuje celá řada dalších rolí, tyto však

nevystupují v příslušném procesu vývoje či workfkow přímo, ale dostávají úkoly

29

od manažera vývoje. Každý úkol je kromě přesného a úplného popisu obsahu

vybaven termínem plnění a předpokládanou kapacitní náročností. Ve chvíli, kdy

pracovník svůj dílčí úkol splní, tedy naplní jeho obsah, provede hlášení o

provedené práci a doplní skutečně použité své kapacity. Na základě těchto

výsledků je možno vyhodnocovat skutečné náklady na každý požadavek, porovnat

tyto skutečné náklady s náklady plánovanými a samozřejmě je také možno

zpřesňovat kapacitní odhady budoucí tak, aby docházelo k větší konvergenci a

přesnosti.

Obrázek 20 Use Case Model

30

Pro úplnost je potřeba uvést, že všechny zadávané úkoly jsou ukládány opět

v interní databázi na intranetu a je možno se k nim kdykoliv vrátit, vyhodnotit

nebo se seznámit s obsahem plnění.

V okamžiku, kdy byly procesy vývoje informačního systému graficky

vymodelovány a textově zdokumentovány, bylo možno přistoupit k jejich rozboru

z hlediska využití, správnosti, úplnosti a optimálnosti. Podle informací od

pracovníků firmy bylo potvrzeno, že v roce 2010 již proběhl jeden krok

optimalizace, kdy na základě zkušeností z let předchozích byla úprava procesu

provedena.

4.2. Statistické vyhodnocení procesů

Dříve, než přistoupíme k rozboru procesů z hlediska využití a další

optimalizace, proveďme několik statistických pohledů na jednotlivé procesy.

K tomuto rozboru byly využity informace od předchozího kroku optimalizace od

roku 2010 do roku 2014.

Obrázek 21 Graf přehledu použitých procesu

0

100

200

300

400

500

600

700

800

900

1000

2010 2011

2012 2013

2014

2010 2011 2012 2013 2014

Řady1 856 947 832 990 686

Procesy za jednotlivé roky

31

Obrázek č. 21 obsahuje graf, který zobrazuje celkový počet realizovaných

procesních vláken v jednotlivých rocích bez ohledu na typ vlákna. Z grafu lze

vyčíst, že průměrný počet procesů za rok je 862 procesů. Je patrné, že rok 2014

nevykazuje takový počet procesů, jako v minulých letech. Důvodem je to, že graf

vznikl dříve, než byl rok 2014 ukončen. Není tedy vhodné použít rok 2014 pro

stanovení průměru počtu vláken. Tedy z let 2010-2013 vychází průměrný počet

procesů 906. Jedná se tedy o poměrně vysoké číslo zaregistrovaných vláken, je

však potřeba si uvědomit, že řada vláken odstartovaných v daném roce, je

ukončena v roce následujícím. Graf zachycuje pohled pouze na procesy

odstartované. Dále graf neřeší to, že řada vláken byla přerušena, či pro špatné

zařazení nebo nedostatečný popis ukončena.

Obrázek 22 Graf četnosti Procesů

Obrázku č. 22 zachycuje graf počtu procesních vláken z hlediska typu za

dané období. V tomto grafu je ihned patrno příliš velké číslo počtu reklamací, což

je jistě zarážející. Jak je to možné? Pracuje vývojové oddělení nekvalitně nebo je

někde chyba v procesu?

Doplňujícím grafem na obrázku 23 je umožněn pohled na statistiku

procesních vláken jednotlivých typů v jednotlivých letech ve vybraném období

Reklamace; 2205; 51% Interní požadavek;

282; 6%

Podřízený požadavek; 628;

15%

Požadavek zákazníka; 1196;

28%

% rozvržení jednotlivých procesů v celkovém počtu procesů

Reklamace Interní požadavek Podřízený požadavek Požadavek zákazníka

32

Obrázek 23 Zatíženost procesů 2010-2014

0

100

200

300

400

500

600

Reklamace

Interní požadavek Podřízený požadavek Požadavek

zákazníka

Reklamace Interní požadavek Podřízený požadavek Požadavek zákazníka

2010 383 83 95 295

2011 477 107 79 284

2012 450 34 124 224

2013 524 44 185 237

2014 371 14 145 156

Zatížení procesů

33

4.3. Analytické vyhodnocení procesů

Při konzultacích s manažerem vývoje vyplynulo, že všechna uvedená

procesní vlákna jsou plně využívána a převážně pokrývají všechny potřebné

činnosti ve správné posloupnosti kroků. Tento názor potvrdily i provedené

statistiky využití vláken. Na druhé straně byly pojmenovány určité slabiny či

nedostatky, které byly v průběhu čtyř lety zaregistrovány, a bylo by potřeba je

řešit. Tyto nedostatky lze rozdělit do dvou částí:

1. Základní požadavek zákazníka je potřeba doplnit novými registrovanými

činnostmi, které byly dosud ponechány na vůli jednotlivých řešitelů bez

kontroly a zpětné vazby

2. Projevil se problém v oblasti řešení reklamací a to v souvislosti

s kategorizací, zda se jedná či nejedná o reklamaci. Bylo zjištěno, že vzniká

poměrně velký počet požadavků typu reklamace a přesto se potvrdilo, že

reklamace není oprávněná. Tyto chybné kategorizace velmi

znehodnocovaly statistiky požadavků a degradovaly pohled na kvalitu

práce vývojových pracovníků. Zde nacházíme odpověď na výše položenou

otázku, proč bylo evidováno tak velké množství reklamací.

Těmto zjištěným skutečnostem se tato práce věnuje v dalších kapitolách.

4.4. Návrh na zlepšení

Z konzultací s vedoucím pracovníkem vývoje informačního systému

vyplynulo, že i když používaná procesní vlákna zachycují všechny činnosti vývoje,

slabinou byla otázka tvorby uživatelské dokumentace a definice umístění nové

funkcionality do systému. Obě tyto činnosti byly prováděny v rámci činností jiných,

často se však stávalo, že byly opomenuty a neexistoval včasný mechanismus

kontroly. Proto bylo navrženo a provedeno osamostatnění těchto činností a jejich

umístění do vlastního procesního vlákna. Nositelem je vedoucí pracovník, který

stanovením úkolu na příslušnou osobu zajišťuje naplnění činností a kontrolou

plnění úkolu ověřuje a potvrzuje splnění této činnosti. Nemůže se tedy již stát, že

34

dojde k opomenutí. Druhou slabinou, jak již bylo zmíněno, byla otázka reklamací.

Stávající mechanismus vyžadoval již na začátku stanovit, zda požadavek ukládaný

do databáze všech požadavků vývoje, je požadavkem na doplnění nové

funkcionality nebo reklamace. Ze statistik, které byly v předchozí kapitole

uvedeny, vyplynulo velké množství reklamací, avšak rozborem reklamací bylo

zjištěno, že více jak polovina z nich reklamací nebylo, takovýto požadavek byl

ukončen a zadavatel dostal informaci, že reklamace je neoprávněná a musí založit

standardní požadavek na doplnění funkcionality nové. Je třeba říci, že rozhodnout,

zda se jedná nebo nejedná o reklamaci je někdy velmi složité, hlavně v případě, kdy

systém nehavaruje, avšak chová se jinak, než uživatel očekává. Pokud se jedná o

kategorii informačního systému ERP, který má vyhovovat různým implementacím

v různých firmách, tedy obecný, jako v našem případě, takový systém musí mít

poměrně širokou parametrizaci. Protože parametrizace je uživatelsky nastavitelná,

může často dojít k chybnému nastavení, a v tu chvíli je chování systému jiné než

očekávané. Dá se říci, že jedině pracovník vývoje, designer, aplikační nebo

systémový programátor může spolehlivě říct pohledem do zdrojového kódu, že se

opravdu jedná o reklamaci.

4.4.1. Základní princip řešení

Bylo rozhodnuto, že zadavatel bude vždy zakládat standardní požadavek do

vývoje, nebude tedy na začátku volit typ procesního vlákna. Pouze zaškrtne do

nového atributu návrh (podezření) na reklamaci. Následující krok bude směřován

na vedoucího vývoje, který bude mít možnost prostředky úkolů na libovolného

pracovníka prověřit, zda je nebo není reklamace oprávněná. Na základě prověření

se tento proces dělí na dva sub-procesy. Pokud se opravdu jedná o reklamaci,

vzniká podřízený požadavek na řešení vlastní reklamace s vlastním procesním

vláknem. Pokud reklamace nebyla oprávněná, požadavek pokračuje sub-procesem

pro řešení požadavku.

35

4.4.2. Použité činnosti

Níže uvedené činnosti jsou rozděleny na dvě skupiny. První skupinou jsou

stávající činnosti, které se nezměnili a jsou použity i v nové verzi firemních

procesů. Druhou skupinou jsou nové činnosti, které byly vytvořeny nově a plní

další funkcionalitu, která v procesech byla doplněna.

4.4.2.1. Stávající činnosti

Zadaní požadavku

Zadavatel založí požadavek na doplnění funkcionality do aktuální verze

vyvíjeného informačního systému. Základní nejpodstatnější povinnou součástí je

podrobný a úplný popis požadovaného rozšíření. Přesnost a úplnost tohoto popisu

úměrně zvyšuje jistotu, že bude dosaženo požadovaného cíle. Jedná se o jednu

z nejkritičtějších činností celého procesu, neboť plně závisí na lidském faktoru a

komunikaci.


Vedoucí vývoje zadává úkol na konkrétního programátora, s cílem

vypracovat zdrojový kód na základě dodaného návrhu řešení od designera. Pokud

se jedná o složitější projekt, zadává vedoucí vývoje dílčí úkoly na větším tým

programátorů (systémových, aplikačních). Každá naprogramovaná část je

programátorem ihned otestována a zdokumentována v tzv. programátorské

dokumentaci a popsána v žurnálu změn.


Zadavatel provede otestování vypracované řešení na základě svého zadání a

přiloženého testovacího předpisu. Pokud jsou potvrzeny předpokládané výsledky,

vypracovaný požadavek posunut do distribuce. Pokud je nalezen rozpor,

požadavek se vrací zpět do vývoje s popisem připomínek k řešení.

36


Testovací oddělení otestuje vypracované řešení podle zadaného testovacího

přepisu a poskytnutých dat. Pokud se v testování neobjeví žádná chyba, je nové

řešení předáno zadavateli k jeho vlastnímu otestování. Pokud se při testování

vyskytly chyby, je řešení vráceno k opětovnému vypracování.

Specifikace požadavku

Zadavatel vytvoří k nově založenému požadavku podrobný popis. Tento

popis vloží do poznámek k požadavku. K danému požadavku také přiloží soubor

dat, který bude sloužit pro otestování správnosti funkcionality. K přiloženým

datům také přiloží testovací předpis, podle, kterého se bude daná funkcionalita

testovat.

Při pokračování posouzení, kontroluje pracovník duplicitu požadavku.

Pokud se požadavek už řešil dříve a byl znovu vytvořen, je nově vzniklý požadavek

zrušen.





Posouzení vývojem

Cílem této činnosti je zpracování hrubého návrhu řešení v dané konkrétní

technologii se stanovením kapacitní náročnosti požadovaného zákroku. Řešitelem

činnosti je role vedoucího vývoje, který zadává úkol na konkrétního designera,

který na základě zpracované analýzy odborného konzultanta vypracovává

příslušný hrubý návrh řešení. Zároveň stanovuje plán kapacitní náročnosti.

Vedoucí vývoje na základě těchto informací vkládá požadované kapacity do

kapacitního kalendáře oddělení, kapacity rezervuje, a tím navrhuje termín plnění a

předání požadavku. Zároveň zpracovává na základě kapacit náklady a minimální

prodejní cenu. Pokud však byly zjištěny nedostatky nebo nepřesnosti v analýze, je

požadavek vrácen zpět k odbornému konzultantovi k doplnění analýzy.

37


Odborný konzultant na oblast, do které obsahově požadavek spadá, provede

základní vyhodnocení, posoudí obsahovou dostatečnost a srozumitelnost. Pokud

zjistí závady čí nejasnosti v daném zadání, požadavek vrací zadavateli zpět

s informací o nutnosti doplnění a další specifikace. Základním úkolem odborného

konzultanta je vypracování analytického modelu požadavku a jeho začlenění do

celkové koncepce daného informačního systému. Tento analytický model je z velké

míry tvořen bez závislosti na konkrétní používané technologii, ale s důrazem na

obecnost a možnost parametrické konfigurace.

Posouzení a schválení zadavatelem




Návrh řešení

Náplní této činnosti je na základě již zpracovaného hrubého návrhu řešení

vypracovat podrobný návrh a popis řešení pro programování. Tuto činnost opět na

základě úkolu vedoucího vývoje provádí vybrané designer. V této fázi je možno na

základě rozsáhlosti projektu rozvětvit vlastní vývoj do několika dílčích i

paralelních větví.

Konec požadavku

Požadavek je ukončen a veden jako vyhotoven.

Po odsouhlasení a převzetí díla zákazníkem dává vedoucí divize pokyn do

ekonomického úseku k vystavení faktury a číslo této faktury je do požadavku také

vloženo.

Distribuce

Vypracovaný požadavek je distribučním oddělením zákazníkovi odeslán,

zároveň je toto předání zaprotokolováno.

38

4.4.2.2. Nové činnosti

Vytvoření uživatelské dokumentace

Nová funkcionalita je dostatečně popsána a z ní je vytvořena uživatelská

příručka.

Kvalifikace

Pokud se jedná o zcela nový požadavek, daný pracovník kontroluje typ

požadavku. V tomto kroku také hraje roli Checkbox Reklamace. Pokud je

nevyplněn, je požadavek brán jako nový. Po tomto potvrzení se daný požadavek

řídí kroky procesu Řešení požadavku. Pokud se zadavatel domnívá, že se jedná o

reklamaci, funkcionalita je podrobena testování. Jestli se oprávněnost potvrdí, je

požadavek brán jako reklamace a následné kroky jsou podle procesu Reklamace.

Pokud se oprávněnost nepotvrdí, zadavatel kontaktuje zákazníka a vyhodnotí další

průběh. Při rozhodnutí zákazníka o vyhotovení nového požadavku, je současný

požadavek brán, jako nový požadavek se následující kroky řídí procesu Řešení

požadavku. Při záporném rozhodnutí je požadavek zrušen.

Posouzení Správnosti

Při posouzení požadavku se zprvu dívá vedoucí vývoje na dostatečný popis,

vhodná data a vhodný testovací předpis pro danou funkcionalitu. Pokud se zde

objeví chyba, je požadavek vrácen zadavateli k jeho přepracování.

Doplnění do menu

Nová funkcionalita je doplněna do Standardního menu systému a k ní

přiřazena cena funkcionality

39

4.4.3. Požadavek zákazníka

Proces Požadavek byl nově vytvořen, jako rozcestník, kde se rozhodne, zdali

daný požadavek je reklamace nebo nový požadavek. V tomto kroku také bude

provedena kontrola, zdali už stejný požadavek nebyl vytvořen v minulosti. Ovšem

ani zde nemá zakladatel omezeno vyjádřit se jaký požadavek to je. K požadavku je

vytvořený Checkbox, který může zaškrtnut, jestli si myslí, že tento požadavek je

reklamace. Pokud se zadavatel domnívá, že to je reklamace, musí také doplnit data

na kontrolu a požadovaný testovací předpis. Taktéž jsou v tomto diagramy

počáteční společné kroky pro oba procesy. Jsou to kroky, které prověřují správnost

požadavku prověření realizací, prověření vývojem a prověření zadavatelem.


Krok 1. Založení požadavku

Krok 2. Specifikace požadavku

Krok 3. Posouzení správnosti

Krok 4. Kvalifikace


40

4.4.3.2. Grafický popis

Obrázek 24 Požadavek od zákazníka

41

Dokumentace ke grafickému modelu „Požadavek“:

Viz Příloha F

4.4.4. Řešení požadavku

Tento sub-proces byl vytvořen ze stávajícího procesu Požadavek zákazníka.,

jedná se tedy o sub-proces, kdy je jednoznačně vyloučena případná reklamace a

jedná se o řešení požadavku doplnění nové funkcionality do systému. Navíc bylo

toto vlákno doplněno o nové kroky, které jsou nositeli nových činností, které

umožňuji řízenou tvorbu uživatelské dokumentace a stanovení umístění nové

funkcionality v rámci menu celého systému, na které se v minulosti často

zapomínalo.


Krok 1. Posouzení odborným konzultantem







Krok 8. Distribuce

Krok 9. Převzetí zákazníkem

Krok 10. Fakturace požadavku

Krok 11. Vytvoření uživatelské dokumentace

Krok 12. Doplnění do menu


42


Obrázek 25 Řešení požadavku

43

Dokumentace ke grafickému modelu „Řešení požadavku“:

Dokumentace k tomuto diagramu přiložena není, je podobného rázu jako u

předchozího procesu Požadavek Zákazníka

4.4.5. Reklamace

Tento sub-proces je odstartován ve chvíli, kdy je již zcela jasno, že se jedná o

reklamaci chybné funkcionality. Činnosti, které jsou obsaženy v jednotlivých

krocích, jsou již zaměřeny na vyřešení reklamovaného problému, jeho otestování a

distribuci.





Krok 4. Distribuce



Obrázek 26 Reklamace

44

Dokumentace ke grafickému modelu „Reklamace“:

K diagramu není přiložena dokumentace, dokumentace je podobného rázu, jako

předchozí dokumentace k diagramu Reklamace

4.5. Implementace

Implementace nových procesů byla provedena na konci ledna 2015. Pro

technické rozložení nových procesů, bylo nutné převést nové procesy do

předepsaných šablon. Protože tyto šablony obsahují interní data, nebudou zde

uvedeny. Pro doladění všech zbývajících interních detailů, proběhlo několik porad

s pracovníkem, který má na starost vnitřní systém. Po naimplementování všech

nových procesů byly po dobu dvou týdnů testovány. Při testování byla veškerá

funkčnost zkontrolována a vyhodnocena jako plně funkční. Nyní jsou procesy

nasazeny v ostrém provozu řízení vývoje vlastního informačního systému

kategorie ERP.

4.6. Shrnutí a vyhodnocení

Aktualizaci zpracovávaných procesních vláken byla věnována poměrně

velká pozornost, konzultováno bylo se všemi pracovníky, kteří svojí rolí vstupovali

do činností jednotlivých vláken. Pečlivě byly zvažovány všechny změny a doplnění.

Důležitým kritériem bylo to, aby všichni pracovníci byli srozuměni s úpravami a

chápali je jako posun vpřed.

Již brzy bylo patrno, že s nově nastartovanými procesními vlákny došlo

k eliminaci chybných kategorizací, čímž začalo docházet k úspoře času, a ten mohl

být věnován zvyšování kvality a dokumentaci.

45

5. Závěr

Na závěr celé práce je nutno říci, že firemní procesy jsou základním

stavebním kamenem každé firmy. Každý kdo pracuje s těmito procesy, si musí

uvědomit, že v jeho rukou není pouze chod těchto procesů, ale chod celé firmy.

Když jsou špatně položeny základy, jak na nich může být postaven celý projekt?

Také je nutno říci, že celkový průběh zlepšování procesů, proběhl velmi

dobře. Důležité slabiny procesů byly zrušeny a celková efektivnost byla zvýšena.

6. Poděkování

Tímto chci také vyjádřit své upřímné „Děkuji“, za možnost tvořit takovýto

projekt. Mé díky směřuji své vedoucí bakalářské práci doc. RNDr. Petře Poulové,

Ph.D., za vedení a poskytnutou pomoc při řešení všech částí této práce, doc. Ing.

Haně Tomáškové, Ph.D. děkuji za konzultace a pomoc. Upřímné „Děkuji“ také

dávám generálnímu řediteli a řediteli divize firmy, kteří mi dovolili vypracovávat

tuto práci a poskytli veškeré informace, a co nejdůležitější i důvěru.

46

7. Seznam použité literatury

[1]Václav Řepa, Podnikové procesy – Procesní řízení a modelování, vydání první,

Praha: Grada Publishing, a.s., rok 2006. Počet stran 268. ISBN 80-247-1281-4

[2]Buchalcevová Alena, Metodiky vývoje a údržby informačních systémů, vydání

první, Praha:Grada Publishing, a.s., rok 2005. Počet stran 164. ISBN 80-247-1075-7

[3]Česká zemědělská univerzita Praha, Objekty 2002, Praha: ČZU, Katedra

informačního inženýrství PEF 2002, ISBN 80-213-0947-4 [1]Arlow, Jim, Neustadt, Ila.

[4]UML a unifikovaný proces vývoje aplikací, vydání první, Brno: Copyright ©

Computer Press, rok 2003. počet stran 387. ISBN 80-7226-947-X

[5]Schmuller, Joseph, Myslíme v jazyku UML, knihovna programátora: vydání první,

Praha: Grada Publishing, spol. s.r.o., rok 2001. počet stran 360. ISBN 80-247-0029-8

47

8. Přílohy

8.1. Příloha A

Šablona pro generování dokumentace z Enterprise Architectu

Tato šablona slouží pro generování veškeré dokumentace z case nástroje

Enterprise Architect.

Model dokumentu

package >

{Pkg.Name}

Typ:

Package {Pkg.Stereotype}

popisek: {Pkg.Notes}

package element >

< package element

diagram >

{Diagram.Name}

Typ : {Diagram.Type}

Popisek:

{Diagram.Notes}

{Diagram.DiagramImg}

{Diagram.Figure}

< diagram

element >

{Element.Name}

Typ:

{Element.Type}

{Element.BaseClasses}

Popisek:

{Element.Notes}

diagram >

{Diagram.Type}

diagram:

{Diagram.Name}

{Diagram.DiagramImg}

{Diagram.Notes}

48

< diagram

linked document >

< linked document

child element >

< child element

< element

child package >

< child package

< package

49

Požadavek

zákazníka

Pozastaveno

Posouzení odborným

konzultantem

Pozastaveno

Pozastaveno

Posouzení vývojem

Pozastaveno

Pozastaveno


Pozastaveno

PozastavenoOdsouhlasení

Pozastaveno

Pozastaveno

Návrh řešení

Pozastaveno Pozastaveno


Pozastaveno

Pozastaveno

Testování testovacím

oddělením

Pozastaveno

Pozastaveno

Testování

zadavatelemPozastaveno

Pozastaveno


PozastavenoPozastaveno


Pozastaveno

konec

požadavku

Kladné

odsouhlasení

Bezchybné

testování

Bezchybné

testování

Kladné

posouzení

Pozastaveno

Zadání požadavku

Pozastaveno

Kladné

posouzení

Kladné

posouzení

Vypracování

řešení

Pozastaveno

Distribuce

Pozastaveno

Kontrola

zákazníka

Aktivity

Standartní tok procesu

Cesta vpřed

Cesta zpět

Legend

Ne

Ne

Ne

Ano

Ano

Ano

Ne

Ano

Ne

Ne

AnoAno

Ano

Ne

AnoNe

8.2. Příloha B

Vygenerovaná dokumentace k procesu Požadavek zákazníka

Model dokumentu

Požadavek zákazníka

Poznámky:

50

Distribuce

typ: Aktivita

Poznámky:

provádí se distribuce do potřebných verzí, popřípadě k zákazníkovi


typ: Aktivita

Poznámky:

pokud se jedná o samostatný požadavek nebo o požadavek souhrnný - úkol na

ekonomické oddělení

Návrh řešení

typ: Aktivita

Poznámky:

vedoucí vývoje zadává úkol na konkrétního designera, který prováděl posudek

Odsouhlasení

typ: Aktivita

Poznámky:

Pracovník péče o zákazníka kontroluje formálnost a úplnost požadavku a

pojednává cenu a termín se zákazníkem, pokud neprovedl sám zadavatel.


typ: Aktivita

Poznámky:

vedoucí realizace urči odborného pracovníka, který bude mít za úkol posoudit

daný požadavek.

Posouzení vývojem

typ: Aktivita

Poznámky:

51

Zadává úkol na konkrétního designera, designer v plnění svého úkoly stanoví

kapacitní náročnost v hodinách, navrhuje koncového řešitele. Vedoucí vývoje

vyhodnocuje náklady a stanovuje cenu za vývoj


typ: Aktivita

Poznámky:

zadavatel doplňuje hodiny vlastního testování + ostatní režie


typ: Aktivita

Poznámky:

zákazník si otestuje řešení do určité doby, zadavatel potvrdí výsledek testu.


typ: Aktivita

Poznámky:

zadává úkol na konkrétní testovač k otestování


typ: Aktivita

Poznámky:

testuje požadované řešení


typ: Aktivita

Poznámky:

vedoucí vývoje zadává úkol na konkrétního vývojáře/ programátora

Zadání požadavku

typ: Aktivita

Poznámky:

52

zadavatel zadává konkrétní požadavek

Bezchybné testování

typ: Gateway

Poznámky:

Zdali se v průběhu testování vyskytly problémy, vrací tok procesu na vypracování

řešení. Pokud se v průběhu testování nestala žádná chyba, požadavek přechází do

stavu testování zadavatelem.


typ: Gateway

Poznámky:



stavu distribuce.

Kladné odsouhlasení

typ: Gateway

Poznámky:

Zdali je požadavek odsouhlasen k vytvoření postoupí se do návrhu řešení, zdali je v

požadavku chyba, pošle se zpět na posouzení zadavatelem.

Kladné posouzení

typ: Gateway

Poznámky:

Zadavatel posoudí požadavek a rozhodne, zdali požadavek postoupí k vypracování

nebo pro nedostatek informací musí být poslat zpět

53

Kladné posouzení

typ: Gateway

Poznámky:

Odborný konzultant posuzuje daný požadavek. Zdali vše souhlasí a je v pořádku,

postupuje požadavek na posouzení vývojem

Kladné posouzení

typ: Gateway

Poznámky:

Odborný Analytik posoudí požadavek a rozhodne, zdali požadavek postoupí k

posouzení zadavatelem nebo pro nedostatek informací bude poslán zpět, či zrušen.

Kontrola zákazníka

typ: Gateway

Poznámky:

Zákazník zkontroluje požadavek, zdali je spokojen, požadavek je ukončen, Zdali je

nespokojen a podmíní své tvrzení pádným důvodem, je požadavek vrácen na

testování testovacím oddělením.


typ: Gateway

Poznámky:

Návrh řešení se vypracuje a zhodnotí, zdali je funkční postoupí do vypracování

řešení, zdali je požadavek špatný, pošle se zpět k odsouhlasení či změně.

54

8.3. Příloha C

Vygenerovaná dokumentace k procesu Reklamace

Model dokumentu

Reklamace

Reklamace - (Business Process diagram)

Poznámky:

Provádí se distribuce do potřebných verzí, popř. k zákazníkovi

Distribuce

typ: Aktivita

Poznámky:


Reklamace

Pozastavení

Zadání požadavku

Pozastavení Pozastavení


Pozastavení Pozastavení

Prověření testovacím oddělením

Pozastavení

Pozastavení

Prověřením vývojem

Pozastavení

Pozastavení


Pozastavení

Pozastavení


oddělením

Pozastavení

PozastaveníTestování

zadavatelemPozastavení

Pozastavení

Distribuce

Pozastavení

Uzavření požadavku

Ukončení

požadavku

Požadavek

schválen

Prověření

testovacím

oddělením

Prověření

úspěšné

Testování

úspěšné

Testování

zadavatelem

úspěšné

Aktivity

Statický tok procesu

Cesta vpřed

Cesta zpět

Legend

Ano

Ne

Ano

Ne

Ano

Ne

Ne

Ne Ano

Ano

55


typ: Aktivita

Poznámky:

Testovací oddělení ověření chybovost systému


typ: Aktivita

Poznámky:

Zadavatel prověřuje oprávněnost reklamace

Prověřením vývojem

typ: Aktivita

Poznámky:

zadává úkol na konkrétního designera k pověření, pokud je potřeba


typ: Aktivita

Poznámky:

Zadává úkol na konkrétní testovače k otestování


typ: Aktivita

Poznámky:

Testuje požadované řešení


typ: Aktivita

Poznámky:


typ: Aktivita

Poznámky:

Vedoucí vývoje zadává na konkrétního vývojáře/programátora

Zadání požadavku

typ: Aktivita

Poznámky:

Zadavatel zadává konkrétní požadavek

56

Reklamace

typ: StartEvent

Poznámky:

zahájení reklamace

Ukončení požadavku

typ: EndEvent

Poznámky:

ukončení požadavku z důvodu úspěšného dokončení požadavku, nebo z důvodu

nevyhovujícího požadavku.

Požadavek schválen

typ: Gateway

Poznámky:

Zadavatel rozhodne zda-li je reklamace oprávněna či nikoliv. Zdali se domnívá, že

se jedná o reklamaci, postupuje požadavek na testovací oddělení. Pokud zadavatel

nepovažuje požadavek za reklamaci, ukončuje požadavek.


typ: Gateway

Poznámky:

Testovací oddělení ověří danou chybu, zdali je chyba způsobena systémem,

postoupí požadavek do stavu Prověření vývojem. Zdali je zapříčiněna z jiného

důvodu, či se nejedná o reklamaci, vrací požadavek na zadavatele.

Prověření úspěšné

typ: Gateway

Poznámky:

Vývoj ověří danou chybu, zdali je chyba způsobena systémem, postoupí požadavek

do stavu vypracování řešení. Zdali je zapříčiněna z jiného důvodu, či se nejedná o

reklamaci, vrací požadavek na zadavatele.

Testování zadavatelem úspěšné

typ: Gateway

Poznámky: Zdali se v průběhu testování vyskytly problémy, vrací tok procesu na

vypracování řešení. Pokud se v průběhu testování nestala žádná chyba, požadavek

přechází do stavu distribuce.

57

Testování úspěšné

typ: Gateway

Poznámky:


řešení. Pokud se v průběhu testování nestala žádná chyba, požadavek testuje

zadavatel.

8.4. Příloha D

Vygenerovaná dokumentace k procesu Reklamace

Podřízený požadavek

Interní požadavek

Poznámky:

Distribuce

Interní

požadavek

Zadání požadavkuPosouzení odborným

konzultantem

Kladné

posouzení

Oprava zadání

požadavku

Posouzení vývojem

Kladné

posouzení

Posouzení

zadavatelem

Kladné

posouzení

vypracování řešení


oddělením

Bezproblémové

testování

Testování

zadavatelem

Bezproblémové

testování

DistribuceUzavření požadavku

Ukončení

požadavku

Aktivita

Cesta vpřed

Cesta zpět

Statický tok procesu

Legend

Ne

Ne

Ano

Ne

Ne

Ano

Ano

Ne

Ano

Ano

Ne

58

typ: Aktivita

Poznámky:



typ: Aktivita

Poznámky:

posuzuje příslušný odborný konzultant, popřípadě vedoucí realizace, který dává

úkol

Posouzení vývojem

typ: Aktivita

Poznámky:

Zadává úkol na konkrétního designera, designer v plnění svého úkolu stanoví

kapacitní náročnost v hodinách, navrhuje koncového řešitele. Vedoucí vývoje

vyhodnocuje náklady a stanovuje ceny za vývoj


typ: Aktivita

Poznámky:

Zadavatel doplňuje hodiny vlastního testování + ostatní režie


typ: Aktivita

Poznámky:

zadává úkol na konkrétní testovače, k otestování


typ: Aktivita

Poznámky:

testuje požadované řešení


typ: Aktivita

Poznámky:

Zadavatel uzavírá požadavek

Zadání požadavku

typ: Aktivita

59

Poznámky:

zadavatel zadá konkrétní požadavek

vypracování řešení

typ: Aktivita

Poznámky:

vedoucí vývoje zadává na konkrétního vývojáře/programátora

Bezproblémové testování

typ: Gateway

Poznámky:



stavu distribuce.

Bezproblémové testování

typ: Gateway

Poznámky:



stavu testování zadavatelem.

Kladné posouzení

typ: Gateway

Poznámky:

Zadavatel posoudí požadavek a rozhodne, zdali požadavek postoupí k vypracování

nebo pro nedostatek informací musí být poslat zpět, či zrušen.

Kladné posouzení

typ: Gateway

Poznámky:

Odborný Analytik posoudí požadavek a rozhodne, zdali požadavek postoupí k

posouzení zadavatelem nebo pro nedostatek informací bude poslán zpět, či zrušen.

Kladné posouzení

typ: Gateway

Poznámky:

60

Odborný konzultant posoudí požadavek a rozhodne, zdali požadavek postoupí k

posouzení vývojem nebo pro nedostatek informací musí být poslat zpět, či zrušen.

Oprava zadání požadavku

typ: Gateway

Poznámky:

Odborný konzultant může daný požadavek také zrušit z důvodu nevyhovujících

informací nebo poslat požadavek na překontrolování zadavateli, aby doplnil

potřebné data.

61

8.5. Příloha E

Dokumentace k podřízenému požadavku



Poznámky:

Diagram popisuje firemní proces "Podřízený požadavek", který je úzce spjat s

ostatními procesy. Je zpráva pro proces, který je podřízen těmito procesy. Sám o

sobě nemůže být vytvořen, ale musí mít vztah s jiným procesem.

Distribuce

typ: Aktivita

Poznámky:

Provádí se distribuce do potřebných verzí. popřípadě k zákazníkovi

Návrh řešení

typ: Aktivita

Poznámky:

Vedoucí vývoje zadává úkol na konkrétního designera, který prováděl posudek

Posouzení vývojem

Podřízený

požadavek

Zadání požadavku Posouzení vývojem Posouzení

zadavatelem

Kladné

posouzení

Návrh řešeníVypracování řešeníTestování testovacím

oddělením

Bezchybné

testování

Testování

zadavatelem

Bezchybné

testování

Distribuce

Konec

požadavku

Aktivity


Cesta vpřed

Cesta zpět

Legend

Ne

Ano

Ne

AnoNe

Ano

62

typ: Aktivita

Poznámky:

Vedoucí vývoje zadává úkol na konkrétního designera, designer v plnění svého

úkolu stanoví kapacitní náročnost v hodinách, navrhuje koncového řešitele.

Vedoucí vývoje vyhodnocuje náklady a stanoví cenu za vývoj


typ: Aktivita

Poznámky:

Zadavatel posuzuje návrh řešení navržený vývojem, doplňuje hodiny vlastního

testování+ ostatní režie.


typ: Aktivita

Poznámky:

Zadává úkol na konkrétní testovač k otestování


typ: Aktivita

Poznámky:

Testuje požadované řešení


typ: Aktivita

Poznámky:

Vedoucí vývoje zadává vypracování na konkrétního vývojáře/ programátora

Zadání požadavku

typ: Aktivita

Poznámky:

Zadavatel zadává konkrétní požadavek


typ: Gateway

Poznámky:



stavu distribuce.

63


typ: Gateway

Poznámky:


řešení. Pokud se v průběhu testování nestala žádná chyba, požadavek testuje

zadavatel.

Kladné posouzení

typ: Gateway

Poznámky:

zadavatel posoudí požadavek a rozhodne se zdali, je v požadavku vše potřebné, a

zdali souhlasí s posouzením od vývoje. Pokud je spokojen, požadavek postupuje na

vytvoření návrhu řešení. Pokud nesouhlasí s předešlým stanoviskem vývoje, vrací

požadavek na vývoj.

64

8.6. Příloha F

Dokumentace k novému procesu Požadavek

Požadavek

Zadav atel

PožadavekOdZákazníka

Založení požadavku

ZahajeniSpecifikace

UkončeníSpecifikaceSpecifikacePožadavku

ZahajeniSpecifikace

UkončeníSpecifikace

Reklamace

Řešení Požadavku

NabídkaŘešení

objednání

si

požadavku

ukončení

požadavku

KvalifikacePožadavku NedostatečnáSpecifikace

NovyPožadavek

ReklamaceNepotvrzenaReklamacePotvrzena

DuplicitníPožadavek

Kvalifikace

KvalifikacePožadavku NedostatečnáSpecifikace

NovyPožadavek

ReklamaceNepotvrzenaReklamacePotvrzena


Zprava o novem požadavku

Zpráva o vyhodnocení

Posouzení

Požadavku

SprávněSpecifikovánPožadavek

SignalizaceReklamace

PosouzeníFunkčnosti

KladnéPosouzení

PotvrzeníReklamace

Příprava Testovacího

předpisuPříprava datpodrobný popis

požadavku

Data k testování

Model Testovací předpis

Aktivity


Cesta vpřed

Cesta zpět

Legend


Ne

Ano

Ne

Ano

DotazováníZákazníka

ZrušeníPožadavku

Ne

Ano

Ne

Ano

Ne

65

Kvalifikace

typ: Aktivita

Poznámky:

V kvalifikace se určí zda-li se jedná o Reklamaci či nový požadavek na základě

vyhodnocení odborného analytika designera.

Posouzení Požadavku

typ: Aktivita

Poznámky:

vybraný Analytik zhodnotí, podle stavu požadavku, zdali se jedná o požadavek

správně specifikován, a zdali se jedná o reklamaci či nový požadavek

Posouzení Funkčnosti

typ: Aktivita

Poznámky:

zadán úkol na testovací oddělení, zdali je požadavek oprávněný

Potvrzení Reklamace

typ: Aktivita

Poznámky:

Zdali je v zadání požadavku zaškrtnuta reklamace a je potvrzena testováním,

vedoucí vývoje potvrdí reklamaci.

Reklamace

typ: Aktivita

Poznámky:

Reklamace se vytváří, zda-li se v současném požadavku vyskytnou chyby, které

byly vytvořeny pouze při vytváření tohoto požadavku. Pokud jsou nalezeny chyby,

které byly vytvořeny až uživatelem, není tento problém řešen jako reklamace, ale

jako nový požadavek.

Specifikace Požadavku

typ: Aktivita

Poznámky:

Zadavatel zpracuje úplný a přesný popis požadavku zákazníka. Zpracuje testovací

předpis a zajistí data pro přesné testování.

Podrobný popis požadavku

66

typ: Aktivita

Poznámky:

Zadavatel podrobně popíše požadavek a vytvoří na toto téma procesní model.

Příprava dat

typ: Aktivita

Poznámky:

Pro správné otestování funkcionality, je zapotřebí připravit příslušné data.

Příprava Testovacího předpisu

typ: Aktivita

Poznámky:

Zadavatel pro správný chod celého procesu musí připravit následující data.

Pro testování je zapotřebí vytvořit Testovací předpis, který má v sobě

zakomponované informace o vstupu. Zde jsou popsány, jaká událost zahajuje

činnost, jak se má tento úsek otestovat a jaké výstupní data budou na konci

procesu.

Založení požadavku

typ: Aktivita

Poznámky:

zadavatel vytváří požadavek, každý požadavek obdrží svoje osobní ID. Přiřadí

zákazníka. V případě existence konkrétního záznamu helpdesku, propojí

požadavek s tímto helpdeskem

Řešení Požadavku

typ: Aktivita

Poznámky:

Zprava o novém požadavku

typ: IntermediateEvent

Poznámky:

Odeslaná zpráva o chybovosti požadavku a dotazování na zaplacení nového

požadavku či nikoliv.

Zpráva o vyhodnocení

typ: IntermediateEvent

Poznámky:

67

Příslušná zpráva o dalším průběhu založeného požadavku.

Nabídka Řešení

typ: Gateway

Poznámky:

Odborný Analytik designer se podle testování a dalšího zpracování rozhodne, zdali

se jedná o reklamaci či o nový požadavek.

Potvrzení O Objednání

typ: Gateway

Poznámky:

Další průběh procesu závisí na zákazníkově rozhodnutí. Pokud už v počátku zadání

počítá zákazník, že se jedná o nový požadavek, je požadavek tvořen jako řešení

požadavku. Zda-li se zákazník domníval, že se jedná o reklamaci, musí být

informován o chybovosti zadání a je dotazován, zda-li si požadavek zaplatí či

nikoliv.

Dostačující informace o požadavku

typ: Gateway

Poznámky:

Odborný analytik designer prostuduje materiály, dodané od zadavatele a zhodnotí

zdali se jedná o úplný popis dostačující pro další zpracování. Pokud jsou informace

v pořádku, postupuje v další činnosti.

Objednání si požadavku

typ: Gateway

Poznámky:

Zákazník se rozhodne zda-li si požadavek koupí či nikoliv. Jestliže si zákazník chce

tento požadavek objednat, přejde požadavek do stavu řešení. Zda-li si zákazník

tento požadavek nechce zaplatit, je celý požadavek zrušen a uzavřen.

Zadavatel

typ: Pool

Poznámky:

Zadavatel, který vytvářel požadavek, musí komunikovat se zákazníkem a předat

mu všechny stanoviska, které byly v procesu vytvořeny. Podle rozhodnutí

zákazníka odešle zprávu na systém.

1

Oskenované zadání práce

Fakulta informatiky a managementu - Theses · Univerzita Hradec Králové Fakulta informatiky a managementu Katedra Informatiky a kvantitativních metod Firemní procesy (správa,

Documents