Česká pošta, podnikové procesy a jejich modelování

Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta

Česká pošta, podnikové procesy a jejich modelování Diplomová práce

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

Bc. Petr Frič

Brno 2008

Mé poděkování patří vedoucí mé práce doc. Ing. Ivaně Rábové, Ph.D za to, že se mě ujala a za její drahocenné připomínky a rady při tvorbě této práce. Dále bych rád poděkoval kolegům z České pošty za cenné rady a své rodině a přítelkyni za podporu po celou dobu studia.

Prohlašuji, že jsem diplomovou práci na téma „Česká pošta, podnikové procesy a jejich modelováníÿ vypracoval samostatně a v seznamu literatury jsem uvedl veškeré použíté literární a odborné zdroje.

Brno 2008

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

4

Abstract Frič, P. Česká pošta, business processes and their modelling. Diploma thesis. Brno, 2008 The topic of diploma thesis is analysis of current company’s processes solution in state enterprise Česká Pošta. The analysed solution is carefully considered and the set of requirements, optimal inovation is suggested. This inovation is considered by two points of view, functional and economical. For modeling is used UML and it’s expansion by H. Eriksson. As a result of this work is funcional application.

Abstrakt Frič, P. Česká pošta, podnikové procesy a jejich modelování. Diplomová práce. Brno, 2008 Tématem diplomové práce je analýza stávajícího řešení podnikových procesů ve státním podniku Česká pošta. Analyzované řešení je důkladně zhodnoceno a podle stanovených požadavků je navržena inovace, která je zhodnocena ze dvou hledisek. Z funkčního a ekonomického. K modelování je využito UML a jeho rozšíření podle H. Erikssona. Výsledkem práce je fungující aplikace.

5

OBSAH

Obsah 1 Úvod a cíl práce 1.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Přehled literatury 2.1 Podnikové procesy . . . . . . . . . . . . . . . . . . 2.1.1 Potřeba zlepšování procesů . . . . . . . . . 2.1.2 Průběžné zlepšování procesů . . . . . . . . 2.1.3 Business Process Reengineering (BPR) . . . 2.1.4 Srovnání CPI a BPR . . . . . . . . . . . . . 2.2 Objektový přístup . . . . . . . . . . . . . . . . . . 2.2.1 Objekt . . . . . . . . . . . . . . . . . . . . . 2.2.2 Třída . . . . . . . . . . . . . . . . . . . . . 2.3 Specifikace požadavků . . . . . . . . . . . . . . . . 2.4 UML - Unified Modeling Language . . . . . . . . . 2.4.1 Historie UML . . . . . . . . . . . . . . . . . 2.4.2 UML 2.0 . . . . . . . . . . . . . . . . . . . 2.4.3 Diagram případů užití (Use Case diagram) 2.4.4 Diagram tříd (Class diagram) . . . . . . . . 2.4.5 Sekvenční diagram (Sequence diagram) . . 2.4.6 Stavový diagram (State diagram) . . . . . . 2.4.7 Diagram aktivit (Activity diagram) . . . . . 2.5 Modelování podnikových procesů . . . . . . . . . . 2.6 CASE nástroje . . . . . . . . . . . . . . . . . . . . 2.6.1 Druhy CASE . . . . . . . . . . . . . . . . . 2.6.2 Enterprise Architect . . . . . . . . . . . . .

7 7 7

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

9 9 9 9 10 11 11 11 12 12 13 13 14 15 16 17 17 18 20 22 22 23

3 Česká pošta, s. p. 3.1 Charakteristika podniku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Organizační struktura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24 24 24

4 Vlastní řešení 4.1 Analýza současného řešení . . . . . . 4.1.1 BPM . . . . . . . . . . . . . . 4.1.2 Diagram aktivit . . . . . . . . 4.1.3 Zhodnocení současného řešení 4.2 Navrhované řešení . . . . . . . . . . 4.2.1 Požadavky . . . . . . . . . . 4.2.2 Use Case diagram . . . . . . 4.2.3 Sekvenční diagramy . . . . . 4.2.4 Diagramy aktivit . . . . . . .

26 26 26 28 29 31 31 34 35 46

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

. . . . . . . . .

6

OBSAH

4.3 4.4

4.2.5 Stavový diagram . . . . . . . . . . . . . 4.2.6 Diagram tříd . . . . . . . . . . . . . . . Zhodnocení funkčnosti navržené inovace . . . . Zhodnocení nákladů a přínosů navržené inovace 4.4.1 Náklady . . . . . . . . . . . . . . . . . . 4.4.2 Přínosy . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

49 51 52 52 53 53

5 Navržená aplikace

55

6 Závěr

58

7 Literatura

60

1

ÚVOD A CÍL PRÁCE

1 1.1

7

Úvod a cíl práce Úvod

Informační technologie v posledních desetiletích zaznamenala prudký rozmach. Již v 15. století vynález knihtisku znamenal prudký rozvoj společnosti. Při srovnání dnešní informační technologie s knihtiskem lze vypozorovat určitou podobnost. Vynález knihtisku zrychlil přenos informací a umožnil ukládání a prezentaci dat. Na rozdíl od informačních technologií neuměl data pořizovat a zpracovávat. Význam knihtisku byl obrovský a ihned se začal masivně rozšiřovat. Možná proto se o době vynálezu knihtisku hovoří jako o době počátku informační revoluce. Jedním z nejpodstatnějších rysů informační technologie je její integrace do různých podnikových, ale i běžných lidských aktivit. Informační technologie a informační systémy se staly součástí nejrůznějších podnikových analýz, marketingu, výrobního procesu, konzultačních nebo projekčních služeb. Tento masivní rozvoj rozšířil okruh uživatelů informačních technologií a klade stále větší potřeby na znalosti těchto technologií uživatelem. V dnešní době si lze jen těžko představit podnik, který nepoužívá nějakou podobu informačních technologií. Ať se jedná například o evidenci zákazníků, zakázek či zaměstnanců nebo o komplexní informační systém. Podnik by měl klást důraz na kvalitní informační systém, aby uspěl na konkurenčním trhu, ve kterém může kvalitní informační systém představovat určitou konkurenční výhodu. Kvalitní informační systém podle Poura (1999, str. 20) musí: • Poskytovat uživatelům potřebnou funkcionalitu jak při zajišťování běžných evidenčních či transakčních operací, tak analytických, plánovacích, rozhodovacích a kontrolních činností. • Přispívat k racionalizaci podnikových procesů, tj. ke zkracování jejich doby, zjednodušování, snižovaní jejich pracovní či technické náročnosti. • Zajistit odpovídající úroveň disponibility informací, technických a dalších prostředků, tj. jejich dostupnost uživateli v pravém čase a na pravém místě. • Realizovat provoz informačního systému a technologií na požadovaném stupni bezpečnosti, spolehlivosti, výkonu a doby odezvy. • Přinést očekávané ekonomické, případně mimoekonomické efekty. • Přispívat ke zvyšování kvalifikace pracovníků firmy. • Provozovat a rozvíjet prostředky a zdroje informatiky při přiměřených nákladech. Uvedené požadavky na kvalitní informační systém ovlivňuje také velikost podniku. Je zřejmé, že čím větší podnik, tím větší bude mohutnost informačního systému. Naopak u malého podniku s pár zaměstnanci asi těžko můžeme očekávat komplexní informační systém.

1.2

Cíl práce

Jsem studentem druhého ročníku navazujícího magisterského studia oboru Ekonomická informatika. Při výběru tématu diplomové práce mě ovlivnila čtyřletá praxe ve státním podniku Česká pošta. Cílem této diplomové práce je provést analýzu vybraných podnikových procesů ve společnosti Česká pošta, s. p. Na základě provedené analýzy provést zhodnocení stávajícího řešení a navrhnout

1.2

Cíl práce

8

inovaci, která by vedla ke zlepšení podnikových procesů, které jsou v této společnosti poněkud zastaralé. Jelikož některé činnosti nejsou ve společnosti podporovány informačním systémem, bude v rámci inovace navržena webová aplikace, která by měla zefektivnit práci zaměstnanců a zkrátit podnikové procesy a také především zkrátit dobu doručování zásilek, které trvá příliš dlouho. Právě dlouhá doba doručení standardních zásilek může znamenat problém. Česká pošta by měla být připravená na otevřený trh (po transformaci na akciovou společnost) ostré konkurence jak efektivní strukturou, tak kvalitním informačním systémem. Aplikace by měla být pro podnik přínosem, proto bude provedena ekonomická úvaha, která bude obsahovat kvantifikované a nekvantifikované přínosy a také zhodnocení nákladů. Analýza současného stavu bude provedena v modelovacím jazyce UML za použití CASE nástroje Enterprise Architect od firmy Sparx systems. Realizovaná aplikace bude napsána v jazyce PHP a bude spolupracovat s databází Oracle.

2

PŘEHLED LITERATURY

2 2.1

9

Přehled literatury Podnikové procesy

Podnikový proces je souhrn všech činností, transformujících souhrn vstupů do souhrnu výstupů pro jiné lidi nebo procesy, za podpory lidí a nástrojů. (Řepa, 2007, str. 15) S podnikovým procesem se setkal každý z nás. Příkladem může být nákup v prodejně. Celý proces začíná vstupem do prodejny a končí zaplacením a odchodem z prodejny. Jednotlivé kroky procesu jsou ty činnosti, které musíme vykonat jak my jako nakupující, tak zaměstnanci obchodu. Jednotlivé vzájemně navazující činnosti mohou, ale také nemusí být popsány jako samotný proces. Záleží pouze na potřebě srozumitelnosti, použitém nástroji, stylu autora apod., ale nikoli na obsahu procesu samotného. 2.1.1

Potřeba zlepšování procesů

Malé a středně velké podniky jsou pod neustálým tlakem konkurenčního boje. Jak praví přísloví „náš zákazník, náš pánÿ, tak se podniky snaží za každou cenu udržet si své zákazníky. Pokud totiž zákazník nedostane co žádá, obrátí se na konkurenční firmy. Podniky se pak snaží udržet si zákazníka snižováním cen a následný pokles zisků kompenzují někdy až nesmyslným snižováním nákladů, jako například snižováním rozpočtů nebo snižováním počtu zaměstnanců. To ovšem způsobí nižší kvalitu procesů. Obecně lze tedy říci, že podniky jsou nuceny zákazníky zlepšovat podnikové procesy a získat tak konkurenční výhodu na svoji stranu. Od počátku devadesátých let toto zlepšování podnikových procesů akceleruje. Hlavním faktorem této akcelerace je technologie a otevření světových trhů. Rozvoj technologie (především internetu) znamená pro podniky nové možnosti, které v konkurenčním prostředí působí jako zesílení konkurenční výhody. Otevření světových trhů znamená osvobození obchodu a další zesílení konkurenčního odvětví. 2.1.2

Průběžné zlepšování procesů

Základem tohoto přístupu je měření a hodnocení existujícího procesu a ze získaných údajů se identifikují nedostatky a na základě těchto nedostatků dochází k jeho zlepšování. Jedná se o tzv. „přirozený procesní přístupÿ. (Řepa, 2007, str. 16) Obrázek č. 1 znázorňuje základní kroky postupného zlepšování procesu (CPI – Continual Process Improvement). Výchozím bodem je popis současného stavu procesu, následuje stanovení soustavy ukazatelů, které plynou především z potřeb zákazníků. V další fázi probíhá sledování a měření procesu a na základě zjištěných výsledků se provádí identifikace možných příležitostí na jeho zlepšení. Příležitosti by měly odpovídat právě potřebám zákazníků a jako konzistentní celek se následně implementují. Provedením dokumentace implementovaného zlepšení se dostáváme opět do první fáze zlepšování, z čehož vyplývá, že tento přístup je v zásadě nekonečným cyklem a neustále se opakuje.

2.1

Podnikové procesy

10

Obr. 1: Průběžné zlepšování procesů

2.1.3

Business Process Reengineering (BPR)

BPR je přístupem naprosto odlišným od průběžného zlepšování. Vznikl jako reakce na akceleraci zlepšování procesů. Podniky začaly vyžadovat radikální a rychlé změny a přestal jim vyhovovat princip postupných změn. Reengineering podnikových procesů ve své extrémní podobě předpokládá, že stávající podnikový proces je zcela nevyhovující – nefunguje, je špatný, je třeba jej z podstaty změnit, od počátku. (Řepa, 2007, str. 15) BPR se zaměřuje především na procesy uvnitř podniku, které vytvářejí určitou přidanou hodnotu a jejich výstupy jsou dodávány na trh a uchází se o uspokojení potřeb zákazníků. V poslední době se do předmětu zájmu dostávají také procesy, které přímo nevytvářejí přidanou hodnotu, ale pouze tyto procesy podporují. Zlepšení těchto procesů může vést ke snížení celkových nákladů a tím i snížení cen výsledných výrobků. Obrázek č. 2 znázorňuje reengineeringový přístup. Celý přístup začíná definicí rozsahu projektu a s tím spojenou definici cílů, následuje analýza potřeb a možností. Tato analýza je klíčová pro celý projekt. Vychází se především z potřeb a zkušeností zákazníků, zaměstnanců, konkurentů i jiných podniků a z možností nových technologií. Tato analýza vede k vytvoření nových procesů. Dále se musí vytvořit plán akcí, vedoucích k zavedení nových procesů. Posledním krokem je implementace celé vize.

Obr. 2: Reengineering

Reengineering v podstatě znamená zásadní přehodnocení a radikální rekonstrukci podnikových procesů tak, aby mohlo být dosaženo dramatického zdokonalení z hlediska kritických měřítek výkonnosti, jako jsou náklady, kvalita, služby a rychlost. Podle rozsahu změn rozlišujeme 3 druhy BPR: – mírná forma – výkonní pracovníci pracují zhruba stejně, ale mají lepší podporu, – střední forma – doplňují se některé další činnosti na operativní úrovni, – těžká forma – úplná reorganizace.

2.2

11

Objektový přístup

2.1.4

Srovnání CPI a BPR

Hlavní rozdíl mezi průběžným zlepšováním procesů a reengineeringem leží na samém jejich počátku. První vychází z existujícího podnikového procesu a druhý staví „na zelené louceÿ. BPR je zpravidla časově náročnější, jelikož se jedná o jednorázovou změnu na rozdíl od, jak už je z názvu patrné, průběžného zlepšování procesů. Nelze ovšem přesně říci, který z přístupů je lepší. Záleží na mnoha faktorech, jako např. povaha a potřeby firmy, odvaha vedení, zkušenosti a další. Je nemožné vybrat přístup, který je vhodný pro každého a do každé situace. V tabulce č. 1 jsou uvedeny charakteristiky rozdílu mezi oběma přístupy podle Davenporta. (1993, str. 11)

Tab. 1: Zlepšení versus inovace procesu podle Davenporta

Úroveň změny Počáteční bod Frekvence změn Potřebný čas Participace Typický rozsah Rizikovost Primární nástroj Typ změny

2.2

Zlepšení postupná existující proces jednorázová/průběžná krátký zespoda nahoru omezený střední klasické - statické řízení kulturní

Inovace radikální zelená louka jednorázová dlouhý shora dolů široký vysoká informační technologie kulturní/strukturní

Objektový přístup

Objektový přístup umožňuje vytvářet systémy, které jsou ze stabilnějších celků – objektů, nežli jsou klasické funkce ve strukturovaných jazycích. (Kanisová, Müller, 2004, str. 50) V objektovém systému se řeší mnohem lépe případné problémy nebo změny, protože každý objekt nese svou odpovědnost za určitou problematiku. Doc. Konečný (2006, str. 66) definuje důvody vzniku objektového přístupu ve spojitosti s řešením následujících problému: • tvorba nového software je neustále složitější, • růst požadavků na kvalitu software, • rychlá inovace výpočetní techniky, • vysoký podíl údržby software, • potřeba jednoduché obsluhy, • selhávání tradičních přístupů tvorby a údržby software, • existence sémantické mezery. 2.2.1

Objekt

Objekt je seskupením dat a funkcionality, které jsou spolu spojeny za účelem plnění soudržné množiny zodpovědností. (Kanisová, Müller, 2004, str. 50) Objektem v širším slova smyslu se rozumí

2.3

Specifikace požadavků

12

jakýkoliv předmět, osoba, činnost, která je předmětem našeho zájmu v problémové doméně. Některé objekty mohou být abstraktní, jiné naopak zcela konkrétní věci. Každý objekt má následující tři charakteristiky: • Stav objektu – je definován hodnotami všech atributů v daný časový moment. (Konečný, 2006, str. 69) • Chování objektu – charakterizuje všechny schopnosti objektu něco dělat, popisuje jeho akce i reakce. Každá komponenta chování objektu se nazývá funkce objektu. (Konečný, 2006, str. 70) • Identita objektu – je vlastnost, podle které lze každý objekt identifikovat a tím určit jednoznačnou existenci v čase a prostoru. Objekty mezi sebou komunikují předáváním zpráv. Zprávy umožňují, aby funkce softwarové aplikace byla výsledkem spolupráce více objektů. Objekty mezi sebou komunikují jen v případě, kdy volající zná identitu volaného objektu. Každý objekt má 3 základní vlastnosti: • Zapouzdření – data a funkce s nimi pracující jsou spojeny do jednoho objektu a lze k nim přistupovat pouze pomocí metod objektu. • Polymorfismus – mnohotvárnost, která je dána tím, že stejnou funkci může vykonávat každý objekt svým způsobem. (Konečný, 2006, str. 71) • Dědění – je vztah mezi nadřízenou třídou a podřízenou třídou. Podřízená třída dědí z nadřízené třídy všechny vlastnosti (atributy a funkce). 2.2.2

Třída

Reálný svět obsahuje spoustu objektů. Abychom usnadnili studium komplexu objektů, slučujeme podobné objekty do tříd a odlišné objekty separujeme. Třídy lze považovat za abstrakce, které charakterizují vymezenou množinu objektů se společnými podstatnými vlastnostmi, což nám dává možnost zařadit každý objekt do nějaké třídy předmětné oblasti. (Konečný, 2006, str. 74) Třída tedy pouze vymezuje podstatné vlastnosti a zvláštní vlastnosti jsou dány objektem samotným.

2.3

Specifikace požadavků

Specifikace požadavků je proces stanovení funkcí a služeb, které by měl vyvíjený systém poskytovat. Požadavky by měly říkat, co má systém dělat, nikoli jak to zařídit. Přitom nejsou přímo součástí jazyka UML. V tomto jazyce jsou požadavky zachyceny v případech užití (případy užití budou vysvětleny později). Každý případ užití popisuje způsob použití systému uživatelem. Soubor všech případů užití představuje všechny uživatelské funkce, které bude systém vykonávat. Tímto způsobem lze tedy v UML nepřímo specifikovat požadavky. Rozlišují se dva typy požadavků: • funkční – popisují požadovanou službu systému, • nefunkční – specifikují vlastnosti systému jako celku, případně specifikují omezení kladená na systém. Definice požadavků je klíčovým aspektem pro úspěch nebo neúspěch projektu. Špatně definované požadavky ve většině případů znamenají neúspěch celého projektu. Od požadavků se odvíjí

2.4

UML - Unified Modeling Language

13

další postup prací. Špatně definované požadavky mohou způsobit množství zbytečně provedené práce a tím i finanční ztráty. Všeobecně se doporučuje zapojit do fáze definice požadavků koncové uživatele, jelikož mají představu o fungování budoucího systému. Zapojením uživatelů předejdeme situaci, kdy systém nebude splňovat uživatelem kladené nároky. Zdrojem funkčních požadavků mohou tedy být: • požadavky zákazníků, • legislativa, • pracovní procesy, • vlastní know-how k problémové oblasti, • prostředí zákazníka aj. Příkladem nefunkčních požadavků podle Kanisové a Müllera (2004, str. 18) může být: • dodržení určitých standardů a protokolů, • využití určených komponent, • rychlost odezev systému na specifické operace, • nároky na výkonnost systému, • zabezpečení systému, • použitá architektura atd.

2.4


Modelovací jazyk UML je souhrnem především grafických notací k vyjádření analytických a návrhových modelů. (Kanisová, Müller, 2004, str. 13) Jazyk UML umožňuje modelovat jednoduché i složité aplikace pomocí stejné formální syntaxe. Stejná syntaxe zaručuje situaci, kdy potřebujeme sdílet s ostatními návrháři výsledky své práce. UML je také jazyk pro vizualizaci, specifikaci, stavbu a dokumentaci softwarových systémů. (Kanisová, Müller, 2004, str. 13) Jak již vyplývá ze zkratky, UML je unifikovaný (sjednocený) modelovací jazyk. Sjednocuje předchozí metody a notace a podporuje celý vývojový cyklus. Je nezávislý na cílovém programovacím jazyku a je založen na zkušenostech a potřebách komunity uživatelů. 2.4.1

Historie UML

První objektově orientované modelovací jazyky se začaly objevovat již kolem 70. let 20. století. O několik let později už existovalo podobných jazyků několik desítek, což působilo na rozvoj některého z nich spíše záporně. Kolem roku 1990 vznikaly nové a nové verze jazyků, které si přebíraly některé vlastnosti. Grady Booch a Jim Rumbaugh z Rational Corp., která je dnes jednou ze společností v konsorciu IBM, začínají v roce 1994 pracovat na sjednocení metod Booch a OMT (Object Modeling Technique). O rok později se připojuje Ivar Jacobson se svoji metodou Objectory, čímž se začala rýsovat metodika splývající s OOSE (Object-Oriented Software Engineering). Tyto práce na sjednocení byly důsledkem dřívějšího vývoje metod nezávislých na ostatních, čímž vznikaly nekompatibility. Dalším důvodem bylo sjednocení sémantiky a notace (zápisu), jelikož byla potřeba

2.4


14

vnést pořádek na objektově orientovaný trh, aby se výrobci mohli soustředit na jiné problémy, než je podpora mnoha různých jazyků. V roce 1996 Booch, Rumbaugh a Jacobson vypouští UML 0.9 a v témže roce zakládají konsorcium UML Partners, které sdružuje společnosti odhodlané vynaložit prostředky ve snaze o tvorbu verze 1.0. Spolupráce nakonec přináší své ovoce a UML 1.0 se stalo jazykem dobře definovaným a silným. 2.4.2

UML 2.0

Hlavním přínosem UML 2.0 jsou přesnější modelovací možnosti stejně jako formální a komplexněji definovaná sémantika. Jazyk je oproti předchozím verzím zjednodušen od nadbytečných konstruktů, které byly zřídka používané. Mezi množstvím vylepšení je např. i pomoc při včasném odhalení chyb aplikací, výrazné zlepšení sekvenčních diagramů, v oblasti behaviorálního modelování byla zlepšena podpora pro zapouzdření.

Obr. 3: Diagramy UML 2.0

UML 2.0 je formálně rozdělen podle charakteru jednotlivých návrhů do čtyř „balíkůÿ specifikací: – Intrastructure – ošetřuje jádro architektury, profily a stereotypy v UML. – Superstructure – se zaměřuje na statické a dynamické elementy modelů.

2.4


15

– Object Constrain Language (OCL) – jazyk pro popis vstupních a výstupních podmínek, invariantů a navigace uvnitř UML modelu. – Interchange – standardizace jednotných a úplných výměnných formátů pro UML diagramy na bázi standardu XMI (XML Data Interchange). Jazyk UML popisuje v aktuální verzi (2.1) 13 různých typů diagramů. Situaci znázorňuje obrázek č. 3. 2.4.3

Diagram případů užití (Use Case diagram)

Případ užití je sada scénářů, které spojuje dohromady společný cíl. (Kanisová, Müller, 2004, str. 36) Scénář je sekvence kroků popisujících interakci mezi aktérem a systémem. (Kanisová, Müller, 2004, str. 35) V praxi bývá pravidlem, že případ užití má jeden hlavní scénář a řadu alternativních scénářů. Alternativní scénáře představují popis situací při zjištění různých chyb narozdíl od hlavního scénáře, který představuje postup typu „vše proběhlo bez chybÿ. Základními stavebními bloky diagramu užití jsou: • aktér – uživatel či jiný systém, který bude vstupovat do interakce s vyvíjeným softwarovým systémem. Grafickým znázorněním aktéra v diagramu užití je symbol postavičky. • případ užití – sada scénářů, jak již bylo dříve uvedeno. Případ užití je představován elipsou. • hranice systému – vymezuje okolí od modelovaného systému. V diagramu je zachycen rámečkem. • relace – vztah mezi prvky diagramu užití. Nejčastější použití je mezi případem užití a aktérem. Kromě těchto vztahů můžeme také rozlišovat několik druhů vztahů mezi případy užití samotnými. Jedná se o tyto vztahy: – include – relace include se objevuje tam, kde existuje podobná nebo stejná část sekvence scénáře, opakující se ve více případech užití. (Kanisová, Müller, 2004, str. 42) – extend – jedná se o typ relace, v němž je základní případ užití rozšířen o rozšiřující případ užití, což znamená, že je základní případ rozšířen o nové doplňkové chování. Všechny prvky diagramu užití jsou představeny na obrázku č. 4.

Obr. 4: Základní prvky diagramu užití

2.4


16

Diagram případů užití tedy slouží k popisu funkcionality systému z hlediska aktérů a případů užití. Význam Use case diagramu: – specifikace požadavků na systém, – komunikace se zákazníkem, – podklad pro řízení projektu, – tvorba testovacích případů pro fázi testování systému. 2.4.4

Diagram tříd (Class diagram)

Diagram tříd je základní strukturální diagram. Zobrazuje třídy a jejich vztahy. Diagram tříd zobrazuje statický pohled na systém, především vztahy mezi třídami. Vztahy, které jednotlivé třídy navzájem pojí jsou asociace, agregace, kompozice, generalizace/specializace. (Kanisová, Müller, 2004, str. 51)

Obr. 5: Vazby v diagramu tříd

• Agregace – jedná se o vztah mezi třídami, ve kterém je jedna třída částí druhé třídy. Jedna třída v rámci této vazby hraje důležitější roli než druhá. Jelikož je tento vztah asymetrický, v rámci důležitější třídy se může vyskytovat pouze jedna z asociovaných tříd. Obecně lze říci, že agregace modeluje vztah celek–část, resp. nadmnožina–podmnožina, nadřízený–podřízený. (Konečný, 2006, str. 80) V UML se relace agregace znázorňuje prázdným kosočtvercem u nadřízené třídy. • Kompozice – je speciálním typem agregace, při níž víme, že podřízený objekt nemůže existovat samostatně bez nadřízeného objektu. Symbolem kompozice je plný kosočtverec. • Asociace – je obecný sémantický vztah mezi třídami, který specifikuje spojení mezi jednotlivými instancemi. Množina všech asociací mezi třídami je dána množinou všech vazeb mezi objekty těchto tříd. (Konečný, 2006, str. 75) Důležitými vlastnostmi asociací je název asociace, název rolí na obou koncích, násobnost a řiditelnost (jednosměrná či obousměrná relace). • Generalizace/specializace – bývá často považována za klíčový koncept objektově orientovaného přístupu. Jedná se o hierarchický vztah mezi potomkem a předkem. Třída potomek dědí atributy a operace třídy předek a rozšiřuje nadřízenou objektovou třídu o nové vlastnosti a operace. Specializace je vztah opačný.

2.4


17

Obr. 6: Diagram tříd – příklad

2.4.5

Sekvenční diagram (Sequence diagram)

Sekvenční diagram popisuje vzájemné působení mezi jednotlivými objekty systému v závislosti na čase. Čas je v diagramu znázorňován vertikální osou a plyne shora dolů. Na horizontální ose jsou různé objekty, které vysílají a přijímají zprávy. Zpráva mezi objekty je znázorněna šipkou mezi čárami života. Čára života představuje svislou čáru každého objektu, která reprezentuje život objektu v průběhu času. V diagramu se také může vyskytovat znázornění návratů, které se vyjadřuje přerušovanou čarou. Podle Ing. Kanisové a Ing. Müllera (2004, str. 65) se však použití nedoporučuje pro značné znepřehlednění diagramů (ukázka znepřehlednění sekvenčního diagramu návraty viz obr. č. 17). Tento popis je znázorněn na obr. 7.

Obr. 7: Základní prvky sekvenčního diagramu

2.4.6

Stavový diagram (State diagram)

Stavový diagram znázorňuje chování systému. Používá se pro popis dynamiky objektu, popis metody, či pro popis protokolu. Stavový diagram popisuje všechny možné stavy, které může nabývat konkrétní objekt systému, jinými slovy modelují chování objektu napříč všemi případy užití. (Kanisová, Müller, 2004, str. 81)

2.4


18

Obr. 8: Stavový diagram – příklad

Na obrázku č. 8 jsou znázorněny základní symboly stavového diagramu. Základem těchto diagramů jsou stavy objektů. Grafickým znázorněním stavu objektů je obdélník se zaoblenými rohy. Stav objektu můžeme charakterizovat tak, že se jedná o konkrétní situaci, která nastala za doby života objektu. (Kanisová, Müller, 2004, str. 82) Objekt v konkrétním stavu čeká na příchod události nebo na požadavek na provedení operace a na základě této události objekt změní svůj stav. Ten je dán hodnotami atributů objektu, aktuálním spojením s jinými objekty a právě prováděnou operací. Každý stavový diagram musí obsahovat dva základní symboly: bod zahájení a bod ukončení. Bod zahájení reprezentuje počáteční bod pro kreslení diagramu. První přechod musí vycházet právě z tohoto bodu do jiného stavu. Bod ukončení slouží jako ukončovací stav diagramu a musí do tohoto bodu vést alespoň jeden přechod. Přechod je určité spojení mezi dvěma stavy, které je uskutečněno při splnění určitých podmínek. Přechody se znázorňují šipkami, přičemž mohou vést jak z nějakého stavu do toho stavu samotného, tak i do stavu jiného. Stavové diagramy jsou užitečné pro znázornění chování objektů napříč případy užití. (Kanisová, Müller, 2004, str. 89) Používají se především pro třídy se složitým chováním. Stavový diagram v takovém případě umožní odhalit nedostatky v sekvenčních diagramech. 2.4.7

Diagram aktivit (Activity diagram)

Speciálním případem stavového diagramu, ve kterém jsou stavy nahrazeny aktivitami a přechody jsou iniciovány dokončením aktivity, je diagram aktivit. Chování je zachyceno v sekvenci aktivit, které mohou být jak sekvenční, tak i paralelní. Diagramy aktivit by měli být dostatečně přehledné,

2.4


19

protože se používají zejména pro komunikaci s lidmi se znalostí struktury obchodních procesů. (Kanisová, Müller, 2004, str. 91)

Obr. 9: Diagram aktivit – příklad

•

• •

•

•

Základní prvky diagramu: Akce (aktivita) – stav nějaké činnosti nebo krok určitého algoritmu. Aktivity nelze přerušit, probíhají rychle a mají jeden vstupní a jeden výstupní přechod. (Kanisová, Müller, 2004, str. 92) Tok – znázorňuje přechod mezi jednotlivými aktivitami. Přechod od jedné aktivity k druhé nastává po dokončení předchozí aktivity a to automaticky. Rozhodnutí (Decision) – se v diagramu aktivit používá pro logické větvení. Značí se kosočtvercem (stejně jako ve vývojových diagramech) a využívá se hned dvakrát. Poprvé se používá pro vyjádření logické podmínky (větvení) a poté pro sloučení větví oddělených při větvení. Rozcestí (Fork) – velice důležitý prvek diagramu aktivit. Rozcestí umožňuje modelovat paralelní chování. Aktivity po rozcestí probíhají nezávisle na sobě. Mohou probíhat paralelně, či může proběhnout nejdříve jedna z nich a pak druhá nebo naopak. Konec paralelního chování znázorňuje prvek spojení, v němž dochází k synchronizaci všech souběžných vláken. Plavecké dráhy (Swimlane) – rozdělení diagramu do vertikálních pruhů pro znázornění odpovědnosti za různé aktivity. Nejčastěji se používají pro znázornění odpovědnosti konkrétních oddělení.

2.5

2.5

Modelování podnikových procesů

20


K modelování procesů existuje řada různých přístupů a norem. Některé z nich jsou ovlivněny informačními systémy a technologiemi, jiné se snaží zdůrazňovat lidskou stránku procesů, jiné spíše technologickou apod. Ovšem většina přístupů vychází ze stejné základny. Mezi společné znaky všech přístupů patří: • proces, • činnost, • podnět, • vazba. Proces je modelován jako struktura vzájemně navazujících činností. Činnosti neprobíhají náhodně, ale na základě definovaných podnětů. Podnět může být vnější nebo vnitřní. Vnějším podnětům se zpravidla říká události a ty přicházejí z okolí procesu. Vnitřním podnětům se obvykle říká stav procesu. Jedná se o situace, v níž se daná činnost nachází. Jednotlivé činnosti jsou popsány pomocí vazeb. Model podnikových procesů (Business Process Model – BPM) představuje základní vyjadřovací prostředek pro znázornění komplexních jevů, které jsou součástí každodenního chování podniku. Pochopení chování podniku je důležité pro tvorbu dlouhodobé strategie a může pomoci při tvorbě informačního systému podniku. BPM umožňuje včas rozpoznat chybné podnikové procesy, takže se stává jistým podkladem pro provádění reengineeringu podnikových procesů. Jazyk UML obsahuje sadu standardních rozšíření pro podporu modelování podnikových procesů, ale v praxi se spíše používá rozšíření UML pro modelování podnikových procesů podle H. Erikssona. Toto rozšíření, jak uvádí doc. Řepa (2007, str. 149), je založeno na čtyřech základních pohledech na organizaci: • Strategický pohled (vize organizace) – zahrnuje klíčové hodnoty firmy a její strategické cíle. Zaměřuje se na hlavní problémy a úmysly, které mají být procesní změnou řešeny. • Procesní pohled – zahrnuje podnikové procesy, činnosti v organizaci a hodnoty, které tyto aktivity vytvářejí. Popisuje vzájemnou spolupráci procesů a využívání zdrojů za účelem dosažení strategických cílů definovaných ve vizi organizace. • Strukturní pohled – zahrnuje zdroje organizace, jako jsou organizační jednotky, produkty, dokumenty, informace, znalosti atd. • Chování organizace – zahrnuje jak vnitřní chování, tak interakci jednotlivých prvků organizace (zdroje a procesy). Jedním z nejdůležitějších cílů analýzy interakcí je přiřazení odpovědnosti za jednotlivé zdroje. V rámci těchto čtyř pohledů na organizaci definuje Eriksson řadu stereotypů, rozdělených do čtyř základních kategorií: (Řepa, 2007, str. 149) • procesy, podnikové procesy, činnosti, procesní toky, rozhodovací body atd., • zdroje procesů, událostí, cílů atd., • pravidla pro řízení procesů, • cíle procesů, jejich vzájemné závislosti cílu, problémy atd.

2.5


21

Jádrem Erikssonova rozšíření UML je právě BPM. Ten vychází z diagramu aktivit, ve kterém je pojem aktivita nahrazen pojmem proces. Společně s procesem Eriksson a Penker definovali sadu základních objektů které s procesem souvisí: (Řepa, 2007, str. 151) • Cíle (goal) – objekty, představující cíle, jichž má být pomocí procesu dosaženo. Např. spokojenost zákazníka nebo kvalitní produkce. • Vstupy (input) – objekty, které jsou procesem spotřebovávány nebo přetvářeny. Např. suroviny, lidská práce či informace. • Výstupy (output) – objekty, které jsou výsledkem nebo produktem procesu. • Podpůrné objekty (supply) – suroviny či informace, které jsou procesem užívány, ale nejsou spotřebovávány ani přetvářeny. • Řídící objekty (např. control) – objekty, které řídí běh procesu. Zmíněné objekty jsou znázorněny na obrázku č. 10.

Obr. 10: Business Process Model – příklad

Erikssonův přístup neposkytuje ucelené návody na tvorbu BPM. Vymezuje pouze určité nástroje, kterými lze namodelovat podnikové procesy. To může vést až k typicky „funkčnímuÿ pojetí procesů, tedy k situaci, kdy jednotlivé procesy odpovídají přesně stanoveným funkcím informačního systému, což bývá všeobecně kritizováno.

2.6

CASE nástroje

2.6

22

CASE nástroje

CASE (Computer Aided Software Engineering) jsou nástroje, které slouží k vývoji, modernizaci a údržbě software. Umožňují automatizovat některé fáze vývojového cyklu programového díla. Význam CASE nástrojů je podobný jako význam CAD nástrojů konstruktéra, kterému pomáhají navrhovat určité budovy, domy, apod. Jedním z prvních CASE nástrojů byl jednoduchý textový editor, který byl výborný pro psaní zdrojového kódu a tvorbu dokumentace. Koncem 60. a začátkem 70. let se začaly prosazovat grafické diagramy (Data Flow Diagramy), ale modifikace byly obtížné. Dalším vývojem došlo k tvorbě datového slovníku, který obsahuje dokument s popisem všech použitých datových typů. Datový slovník je vytvářen automaticky z průběžně tvořené databáze. Spojení grafického prostředí a datového slovníku vedlo ke vzniku velmi silných vývojových nástrojů, obsahujících dokumentaci kompletního životního cyklu projektu počínaje specifikací až po vytvoření programů. (Konečný, 2006, str. 62) Využívání CASE nástrojů má bezesporu mnoho výhod. Kvalitní CASE by měl umožnit: – rychlejší proces vývoje, – snadnou modifikaci, – zvýšit kvalitu software, – využít vhodné objektové nebo strukturované techniky, – práci v interaktivním prostředí. Z uvedených výhod je patrné, že CASE nástroje mohou snížit pracnost tvorby software a snížit celkové náklady na vývoj, což může způsobit snížení prodejních cen programového systému. 2.6.1

Druhy CASE

V současné době existuje velké množství CASE nástrojů. Liší se v závislosti na fázi vývoje, ve kterých je používán, ale také podle podporované metodiky. Nástroje použité ve fázích specifikace požadavků, analýzy, návrhu, kódování a údržby se liší a je obvyklé, že pokrývají jen určité činnosti. Podle životního cyklu vývoje software můžeme CASE nástroje rozdělit do následujících skupin: (Procházka, 2004) • Pre CASE – podporují tvorbu globální strategie. • Upper CASE – podporují plánování, specifikaci požadavků, modelování organizace podniku a globální analýzu informačního systému. Hlavním úkolem nástroje je analýza organizace, zachycení procesů v organizaci, definice klíčových informačních toků a dokumentace. Základními nástroji této skupiny jsou DFD (Data Flow Diagram), ERD (Entity Relationship Diagram) a v objektovém přístupu popis základních vlastností systému. • Middle CASE – podporují podrobnou specifikaci požadavků, vlastní návrh systému, dokumentaci a vizualizaci systému. Použité metody a nástroje jsou DFD včetně podrobného popisu procesů, podrobné ERD a u objektového přístupu diagramy tříd, instancí a přechodové diagramy. • Lower CASE – obsahují nástroje pro podporu kódování, testování, údržby a reverzního inženýrství (reengineering). Integrovány jsou generátory kódu, prostředky pro reverzní inženýrství,

2.6

CASE nástroje

23

prostředky pro sledování a vyhodnocení metrik, prostředky plánování a další. Funkce CASE nástrojů této kategorie se často překrývají s funkcemi obecných vývojových prostředí. • Post CASE – podporují organizační činnosti (zavedení, údržbu a rozvoj informačního systému).

Obr. 11: Pokrytí fází životního cyklu druhy CASE

2.6.2

Enterprise Architect

Enterprise Architect (EA) je nástroj pro modelování pomocí jazyka UML od firmy Sparx Systems. V současné verzi 7 podporuje UML 2.1 pomocí 13 diagramů, z nichž nejznámější jsou diagramy: tříd, způsobu užití, sekvenční, aktivit a BPM. EA disponuje grafickým prostředím s flexibilními nástroji pro modelování, vývoj a testování softwarového díla. Umožňuje generovat dokumentaci a reporty do různých formátů (JPG, GIF, PNG, RTF, HTML). V Enterprise Architectu můžeme dále nalézt prostředky pro tvorbu zdrojového kódu a tzv. reverse engineering do kódu C++, JAVA, Delphi, PHP, C#, VB.net a Visual Basic.

3

ČESKÁ POŠTA, S. P.

3 3.1

24

Česká pošta, s. p. Charakteristika podniku

Od vzniku samostatného státu v roce 1918 bylo organizování poštovních služeb řízeno Ministerstvem pošt a telegrafů, jehož hlavním úkolem bylo propojení poštovní, telegrafní a telefonní sítě s územím Slovenska. V roce 1992 došlo k rozdělení resortu pošty a telekomunikací. Od vzniku samostatné České republiky je Česká pošta (ČP) státním samostatně hospodařícím podnikem, jelikož dotace do tohoto státního podniku skončily oddělením výdělečného telekomunikačního resortu od poštovního. ČP se tedy chová jako normální podnikatelský subjekt, který odvádí do státního rozpočtu všechny příslušné odvody. Nutno ovšem podotknout, že ČP již dávno není monopol a poskytování poštovních služeb je volná živnost. Základní normou je zákon o poštovních službách č. 29/2000 Sb. Možnost podnikání je ovšem omezena tím, že některé (především listovní) služby jsou výhradně provozovány ČP, jelikož poskytuje dostupnost nejdůležitějších poštovních služeb po celém území České republiky. Tento přirozený monopol se vztahuje jen na poštovních zásilky obsahující písemnosti s hmotností nižší než 50 g a současně musí být cena zásilky nižší než 18 Kč (nařízení vlády č. 512/2005 Sb.). Z výše uvedeného vyplývá, že ČP se v oblasti přepravy balíkových zásilek, letákových zásilek, velké části listovních zásilek, peněžních a dalších službách pohybuje v plně konkurenčním prostředí a musí bojovat o zákazníka. Specifické postavení ČP není jen výsadou České republiky, ale funguje téměř v celé Evropě (s výjimkou Švédska a Finska). V současné době ČP provozuje kolem 3 400 poboček a je se 37 500 pracovníky jedním z největších zaměstnavatelů v zemi. V roce 2006 vykazovala zisk před zdaněním 331 milionů korun, což oproti předchozím letem znamená pokles o téměř dvě třetiny. Hlavním důvodem nižšího zisku je provedení operací související s přechodem na akciovou společnost, které činily téměř 700 milionů korun. V témže roce ČP doručila 900 miliónů listovních zásilek a 26 milionů balíků.

3.2

Organizační struktura

Česká pošta je moderní obchodní společnost. Svědčí o tom nedávno provedená změna organizační struktury. K 29. 2. 2008 skončily odštěpné závody (OZ) a začaly působit obchodně-provozní regiony. OZ byl téměř soběstačnou jednotkou včetně zápisu v obchodním rejstříku a na svém území působil někdy skoro jako samostatná pošta. Tento systém měl ve své době opodstatnění, ale v současné době není tento systém schopen konkurovat firmám, které působí jednotně na území nejen jednotlivých zemí, ale i v evropském měřítku. Proto se ČP mění z provozně orientované struktury na strukturu liniového řízení jednotlivých funkcí. Hlavní změna se týká pošt, které jsou nyní řízeny z regionu (dříve ze čtyř ředitelství). Základem systému jsou větší pošty tzv. „řídícíÿ, které přímo podporují činnosti pošt menších tzv. „satelitníchÿ. Ty vystupují stále jako plnohodnotné pošty, vnitřně působí spíše jako „vysunuté přepážkyÿ řídících pošt. Některé pošty, kromě svých vlastních činností a činností řídící pošty, plní funkci „obvodníÿ pošty, které podporují provozní a obchodní činnost. V praxi to vypadá tak, že satelitní pošta již nemá svého vedoucího, ale je řízena šéfem pošty řídící, který kromě toho, že řídí svůj provoz, musí manažersky řídit napojené satelity. Jako by je

3.2

Organizační struktura

25

měl například někde v další hale. Počet připojených satelitů je ve většině případů ovšem omezen na jeden až dva, což sice klade větší nároky na manažerské schopnosti šéfa řídící pošty, ale nikterak drasticky. Na druhou stranu existuje skupinka pošt, které pod sebou mají až jedenáct satelitů (ve větších městech), což už vyžaduje velké manažerské schopnosti. Poněkud specifické postavení mají samostatné pošty. Jsou to pošty, které mají více než tři přepážky, ale neřídí pod sebou žádný satelit. V prvním návrhu organizační struktury měly být pošty přímo napojeny na ředitele regionů, jenže takových pošt je přes tisíc. Na jednoho regionálního ředitele by vycházely téměř dvě stovky takových pošt. Proto vznikla ještě pošta obvodní, jako řídící nástroj obchodního ředitele. Jeden region jich má třináct, ostatní pak dvanáct. Výše popsaná organizační struktura je znázorněna na obrázku č. 12.

Obr. 12: Organizační struktura České pošty

4

VLASTNÍ ŘEŠENÍ

4

26

Vlastní řešení

Úvodem kapitoly je výchozí Business Process Model, pomocí kterého je popsán současný stav řešení. Analýza a hodnocení současného řešení je východiskem pro návrh inovace, která je namodelována konkrétními diagramy UML.

4.1 4.1.1

Analýza současného řešení BPM

Pro modelování podnikových procesů bývá asi nejčastěji používáno rozšíření UML podle H. Erikssona. Jak bylo uvedeno již dříve, toto rozšíření poskytuje spíše nástroje k návrhu, než aby dávalo přesné metodické návody. Celý souhrn procesů začíná v okamžiku, kdy přijde zákazník (odesílatel ) na přepážku s vyplněným podacím lístkem, který obsahuje všechny potřebné informace o odesílané zásilce. Podle údajů z podacího lístku Zaměstnanec na přepážce (bližší popis aktorů bude uveden v dalším textu) pořizuje údaje o zásilce do informačního systému. Na základě informací z podacího listu je po pořízení zásilky tištěn štítek, který je nalepen na zásilku pro jednoznačnou identifikaci. Štítek obsahuje unikátní kód, údaje o adresátovi, odesílateli, dobírkové částce, udané ceně a další potřebné údaje. Unikátní kód zásilky je tvořen písmeny a číslicemi. Písmena specifikují typ zásilky, který byl uveden odesílatelem na podacím lístku a číslice jsou generovány informačním systémem automaticky. Podací lístek a Zásilka jsou svým způsobem procesem zpracovávány, proto jsou označeny stereotypem input. Cílem procesu je naplnění třídy Zásilky, ale také spokojenost zákazníka s obsluhou. Podaná zásilka se poté přenáší do skladu na tzv. „hromaduÿ, odkud si ji po skončení pracovní doby pobočky přebírá Kartista (u obvodových pošt s delší provozní dobou bývá proces Třídění zásilky vykonáván ihned po pořízení zásilky). Důležitým prvkem procesu Třídění je třída Doručovací okrsky. Doručovací okrsky vytvářejí určitou doručovací síť a jsou tvořeny výčtem ulic. Například město Brno je rozděleno do 44 okrsků s označením BM01–BM44, přičemž každý okrsek musí splňovat dvě zásady. Ulice v doručovacím okrsku musí být v těsné blízkosti, aby bylo dosaženo efektivní dopravy. Druhou a neméně důležitou zásadou je přibližně stejná průměrná zátěž (počet zásilek) jednotlivých okrsků. V poslední době s nárůstem počtu zásilek dochází ke zvyšování počtu doručovacích okrsků, což způsobuje potřebu více doručovatelů a větší vozový park. Třídění zásilek, jak již bylo uvedeno, provádí Kartista. Sejmutím čárového kódu zásilky se zobrazí informace o zásilce a na základě porovnání města a ulice ze zásilky s městem a ulicí z doručovacích okrsků je zásilka jednoznačně přiřazena určitému okrsku. Po zatřídění všech pořízených zásilek Kartista provádí tisk Přepravního listu podle doručovacích okrsků. Tzn. pro každý doručovací okrsek je vytvořen jeden přepravní list s informacemi o všech zásilkách daného okrsku. Slouží především jako podklad pro převzetí zásilek k přepravě, ale také jako velice důležitý dokument při pozdějším dohledávání ztracených zásilek. Přepravce, který převezme zásilky k přepravě a podepíše přepravní list, na sebe přebírá odpovědnost za případnou ztrátu zásilky a zbavuje tak odpovědnost podací poštu. Pokud přepravce nepřevezme nějakou zásilku z důvodu jejího nenalezení, je za případnou ztrátu odpovědná právě podací pošta. Nutno podotknout, že pro přepravu zásilek z podací pošty na poštu dodací je vytvořena skupina doručova-

4.1

Analýza současného řešení

27

cích okrsků, které spadají právě pod danou doručovací poštu. Přepravce pak nepřebírá k přepravě jeden doručovací okrsek, ale právě celou skupinu doručovacích okrsků. Pro identifikaci těchto skupin jsou vyčleněny první dva znaky z označení doručovacího okrsku (BM pro Brno). Přepravní list tedy slouží pro převzetí zásilky a jsou v něm vyplněny údaje o přepravovaných zásilkách.

Obr. 13: Business Process Model ČP

4.1


28

Po přepravě zásilek na dodací poštu přepravce na základě přepravního listu vykazuje přepravené zásilky. Cílem procesů Převzetí zásilky na dodací poště a Převzetí k přepravě je zjištění chybějících zásilek. Jedná se o docela složitý mechanismus dohledávání zásilek v papírových dokumentech uložených jak na podací, tak na dodací poště. Po dokončení všech svozů, což je vlastně přeprava zásilek ze všech větších pošt na dodací poštu (svozy tvoří „mapuÿ přepravy na celém území České republiky), probíhá na všech dodacích poštách tisk dvou druhů dokladů: Doručovací karty a Dokladu o převzetí. Doručovací karta, vytištěná pro konkrétní doručovací okrsek, obsahuje informace důležité především pro doručení zásilky, tzn. údaje o odesílatelovi, adresátovi, místu dodání, dobírkovou částku a kód zásilky. Doklad o převzetí má podobný význam jako již zmiňovaný přepravní list. Doručovací karta slouží jako podklad pro doručení zásilky. Procesem Doručení zásilky je doručovací karta zpracovávána, tzn. je označena stereotypem input. Doručovatel v doručovací kartě zaznamenává údaje o doručení, které jsou důležité pro proces Vypořádání zásilky. Oba procesy budou vysvětleny později. Popsaná situace je znázorněna na obr. 13. 4.1.2

Diagram aktivit

Diagram aktivit zobrazuje sekvenci aktivit od pořízení zásilky až po doručení a následnou kontrolu doručených zásilek. Využití swimlane jasně ukazuje, které oddělení je za aktivity odpovědné, a které je vykonává. V průběhu doručení zásilky se na ČP rozlišují 4 oddělení. Pokud by rozlišení odpovědnosti nestačilo, mohou se jednotlivá oddělení zdrobnit na jednotlivé osoby (funkce), které za konkrétní aktivity odpovídají. Podací pošta je místem, kde mezi zákazníkem a ČP vzniká smluvní vztah. Na podací poště odesílatel podá zásilku, kterou někomu odesílá a úkolem podací pošty je vykonat všechny aktivity, aby byla zásilka co nejdříve zpracována a připravena k přepravě. Dopravce provádí přepravení mezi podací a dodací poštou, přičemž ne každá zásilka musí přepravou projít. V případě, že pro pořízenou zásilku je podací pošta současně dodací poštou, následují po třídění zásilky ihned aktivity na dodací poště a přeprava je zcela vynechána. ČP pro přepravu zásilek využívá jak automobilovou dopravu, tak dopravu vlakovou. Vlaková doprava je smluvně zajištěna s akciovou společností České dráhy. Dodací pošta zastává aktivity spojené s konečným doručením zásilky. Pod dodací poštu spadá i doručovatel, ale v tomto případě je oddělen jako samostatné oddělení (zóna) z důvodu ukázky odpovědnosti dodací pošty a doručovatele.

4.1


29

Obr. 14: Diagram aktivit ČP

4.1.3

Zhodnocení současného řešení

Současné řešení podnikových procesů úspěšně funguje v ČP už pěknou řádku let. Podnik se sice snaží postupně podnikové procesy zlepšovat a zefektivňovat, ale stále nedošlo k odstranění závaž-

4.1


30

ných nedostatků. Především absencí komplexního informačního systému se řada činností provádí velice složitě a časově náročně, což se odráží v počtu zaměstnanců, v délce doručovací doby, nebo třeba v délce čekání na přepážce. ČP sice disponuje informačním systémem, který ovšem nepodporuje všechny potřebné podnikové procesy. Zásadním problémem současného řešení je zbytečné papírování. Každé převzetí zásilky probíhá prostřednictvím tištěného dokumentu, který obsahuje seznam zásilek. Přebírající osoba vyznačí převzaté zásilky do dokumentu pro následnou kontrolu při dalším předávání. V praxi to znamená, že když přebírající osoba přebírá např. 500 zásilek, musí zkontrolovat 500 čárových kódů zásilek a dohledat každý kód v např. 20stránkovém přepravním listu a odškrtnout. Což je ovšem velice pracné a zdlouhavé. Naprosto stejná situace vzniká během cesty zásilky od odesílatele k adresátovi třikrát. Nicméně při stávajícím řešení je tato kontrola důležitá, především z důvodu dohledávání zásilek. Není ani možné ji vykonat jiným způsobem, než při každém převzetí zkontrolovat, zda se daná zásilka neztratila. Z výše uvedeného vyplývá, že zásilka je do informačního systému vložena pouze v procesu pořízení a to výhradně jen z důvodů zatřídění zásilky, tisku štítku a tisku všech dokladů (přepravní list, doručovací karta, doklad o převzetí). Ostatní činnosti jsou většinou prováděny ručně. Při pořizování zásilky zaměstnanec na přepážce vkládá do systému všechny potřebné údaje z podacího lístku. Při vkládání údajů o odesílateli musí údaje pro každou zásilku zvlášť napsat. Pokud tedy jeden odesílatel podává na poště třeba deset zásilek, zaměstnanec na přepážce pro každou zásilku zvlášť vypisuje stejného odesílatele, což je časově daleko náročnější, než kdyby existovala databáze odesílatelů. Alespoň tedy smluvně domluvených odesílatelů posílajíc větší množství zásilek (eshopy, reklamační servisy, ap.). Zavedením takové databáze by značně urychlilo čekání ve frontách, které jsou s růstem počtu posílaných zásilek větší a větší. Databáze odesílatelů by umožnila také zavést pro subjekty, které posílají větší množství zásilek výhodnější ceny. Ty by se počítaly podle počtu odeslaných zásilek za určité období a mohlo by dojít k nárůstu počtu těchto firem. Tuto službu využívá společnost PPL a po zavedení evidovala nárůst poslaných zásilek podnikatelskými subjekty. Jak již bylo uvedeno na začátku, je téměř nemožné dohledat místo, kde se konkrétní zásilka nachází nebo kde se ztratila. ČP sice poskytuje službu Track & Trace, která slouží pro sledování zásilek odesílatelem, ale málokdo ví, jak skutečně funguje. Jelikož v průběhu cesty zásilky se žádná data do informačního systému nezadávají, Track & Trace rozlišuje pouze čtyři stavy: pořízena (na cestě), doručena, oznámena a ztracena. První stav vzniká hned při pořízení zásilky na podací poště a je naprosto zřejmý. Jedná se o úplně první stav zásilky, který odesílatel dokáže sám odhadnout. V průběhu cesty je zásilka uvedena stále jako pořízená a stav se mění až v procesu vypořádání zásilky. V tomto procesu se stav zásilky mění podle doručovací karty na jeden ze zbylých tří stavů, což znamená, že zásilka má mezi prvním a posledním procesem pouze jeden stav. Služba Track & Trace tedy může sloužit pro informaci odesílateli, jestli již byla zásilka doručena či nikoli, ale nepodává informace o průběhu cesty zásilky.

4.2

Navrhované řešení

4.2

31


4.2.1

Požadavky

Pojmem požadavek rozumíme popis funkce nebo vlastnosti systému, která by měla být implementována. Jinými slovy, požadavek je vyjádřením přání uživatele. Zdrojem požadavků pro návrh nového systému byl především vlastní know-how dané problematiky. Pokud by vlastní know-how byl jediným zdrojem požadavků, mohlo by dojít k neúspěchu celého projektu, proto byli do tvorby požadavků zapojeni i samotní zaměstnanci ČP (kartista, doručovatel). Na nový systém byli stanoveny následující požadavky: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Pořízení zásilky na podací poště Monitoring stavu zásilky Správa číselníků Evidence odesílatelů Evidence ulic Aktualizace doručovacích okrsků Doručení zásilky Vypořádání zásilky Přeprava zásilek na dodací poštu Tiskové sestavy

Pořízení zásilky na podací poště Zákazník (odesílatel) přichází na poštu a chce odeslat zásilku. Vyplněným podacím lístkem specifikuje požadované služby, jako např. typ zásilky, udaná cena zásilky, prodloužení úložní doby aj. Zaměstnanec na přepážce převezme zásilku a podle dodacího listu pořídí údaje do systému. Při zadávání údajů o odesílateli ověří, zda se jedná o existujícího zákazníka. Při vkládání ulice ověří existence ulice a případně vloží novou ulici. Pořizované údaje o zásilce: – – – – – – – –

kód zásilky, typ zásilky (z číselníku typů, např. obchodní balík, profi balík, obchodní balík s dobírkou, . . . ), údaje o adresátovi (jméno, město, směrovací číslo, ulice, číslo popisné), údaje o odesílateli (jméno, město, směrovací číslo, ulice, číslo popisné), hmotnost zásilky, udaná cena zásilky, dobírková částka (v případě zásilky s dobírkou), doplňkové služby.

Systém zajistí výpočet ceny zásilky (podle zadaných údajů) a tisk potvrzení o dodání. Monitoring stavu zásilky Sledování stavu zásilky tak, aby mohl adresát nebo odesílatel zjistit, kde se zásilka nachází. Pomocí internetového přístupu bude možnost zjistit aktuální stav zásilky z množiny hodnot: – pořízená, – zatříděná,

4.2


32

– přepravovaná, – připravena k doručení, – převzata k doručení, – doručena, – nedoručena, – vyzvednuta, – uložena, – na cestě zpět, – ztracena. Monitoring stavu je důležitý také z hlediska dohledání ztracených zásilek, proto bude sloužit i kartistům k dohledání těch zásilek, které se během cesty zásilky někde ztratily. Správa číselníků Požadavek správy řeší následující číselníky: – typ zásilky, – stav zásilky, – ulice, – města, – doručovací okrsky. Evidence odesílatelů ČP by si měla udržovat přehled o svých zákaznících (odesílatelích). Evidence by obsahovala počet odeslaných zásilek a celkovou cenu odeslaných zásilek za určité období, což by umožnilo uskutečňovat cenové slevy nebo jiné akce. Odesílatelé by byli informovaní o právě probíhajících akcích či nabídkách služeb např. formou e-mailu nebo letáku. Předmětem evidence bude: – jméno (u právnické osoby název firmy), – adresa (u právnické osoby sídlo firmy), – telefon, – mobil, – email, – počet odeslaných zásilek, – celková zaplacená částka za poštovní služby. Evidence ulic Pro doručení zásilky je nezbytné, aby existovala evidence ulic. Ulice přesně specifikuje místo dodání zásilky a tím i doručovací okrsek. Zatřídění ulic do doručovacích okrsků se často mění, jelikož přibývají nové ulice nebo vznikají na stávajících ulicích nové podniky a ulice se stávají více zatížené. V tomto řešení ulice eviduje pouze zaměstnanec na přepážce v případě, že zadaná ulice neexistuje. Zatřídění dané ulice provádí kartista.

4.2


33

Aktualizace doručovacích okrsků Požadavek aktualizace doručovacích okrsků se od požadavku evidence ulic značně liší. Evidence ulic slouží především pro případ vzniku nové ulice nebo v případě, že odesílatelem stanovená ulice nebude existovat nebo nebude napsána přesně tak, jak je uvedena v databázi. Aktualizace doručovacích okrsků by měla být schopna zatřídit neexistující nebo novou ulici. Aktualizaci by měl provádět kartista, který disponuje „uličníkemÿ, což je tisková podoba doručovacích okrsků a k nim přiřazených ulic. Veškeré nové ulice musejí být předem ohlášeny ve věstníku. Od požadavku evidence ulic se liší zejména tím, že pro novou ulici aktualizuje doručovací okrsek, na rozdíl od evidence ulic, která řeší především vznik nových ulic. Doručení zásilky Doručovatel doručuje zásilky a oproti stávajícímu řešení provádí doručení výhradně na základě tohoto požadavku. Doručovatel zvolí okrsek, který mu byl přidělen k doručení a ze seznamu zásilek vybírá postupně zásilky, které zrovna doručuje. Podle výsledku doručení mění stav zásilky na jeden z následujících: – doručena, – nedoručena. Vypořádání zásilky Požadavek vypořádání zásilky souvisí z činností prováděnou po doručení zásilky. Doručovatel, který při doručení adresáta nezastihne, vhodí pouze oznámení a zásilku ukládá na dodací poště. Kartista musí ukládané zásilky zpracovat. Vypořádání spočívá v nastavení ukládací doby (v závislosti na doplňkových službách) a především v kontrole správnosti skutečně uložených zásilek a zásilek, jejichž stav je nastaven na uložena. Součástí vypořádání zásilek by měla být kontrola pořízených zásilek na podací poště a zásilek skutečně doručených a oznámených. V případě, že některá z pořízených zásilek na určitém okrsku někde uvízla (např. v podací poště, v přepravě), bude nastavena jako ztracena. Nastavené zásilky na stav ztracena budou zásilky, u kterých bude stav: – pořízená, – zatřízená, – přepravovaná. Za tyto ztracené zásilky bude odpovědná příslušná osoba na místě jejího posledního výskytu. Zásilky, které zůstanou se stavem nedoručena a nenaleznou se, budou nastaveny na stav ztracena a odpovědnost ponese doručovatel daného okrsku. Přeprava zásilek na dodací poštu Přepravce přijíždí na podací poštu za účelem přepravy zásilek z podací pošty na konkrétní dodací poštu (podle rozpisu). Podle doručovacích okrsků vybírá zásilky, které musí přepravit. Každou zásilku pořídí snímačem čárových kódu do systému a systém nastavuje stav zásilky na přepravovaná. Požadavek přepravy zásilky ošetřuje situaci, kdy v systému zůstávají na nějakém okrsku zásilky, které přepravce nepřevzal, protože je nenalezl. Součástí požadavku musí být informace o zásilkách, které zůstaly na okrsku „visetÿ.

4.2


34

Tiskové sestavy Požadavek tiskových sestav není příliš důležitý. Tiskové sestavy (doručovací karta, přepravní list a doklad o převzetí) mají své využití v případě, kdyby informační systém přestal fungovat. Všechny tiskové doklady musí obsahovat všechny potřebné údaje, aby se zamezilo zastavení provozu při výpadku systému. Při důkladném otestování systému v provozu by požadavek tiskových sestav mohl být odstraněn. 4.2.2

Use Case diagram

Diagram případů užití popisuje všechny uživatelské funkce, které by měl informační systém poskytovat a názorně zobrazuje, který aktor se zapojuje do jakých procesů. ČP důsledně vymezuje funkce jednotlivých zaměstnanců, především z důvodu přesného vyškolení na danou problematiku, proto se většinou nestává, že by zaměstnanci o dvou různých funkcích prováděli stejnou činnost. Tuto situaci lze vypozorovat z obrázku č. 15. Každý aktor provádí přesně stanovené funkce a nestává se, že by i jiný aktor mohl tyto funkce provádět.

Obr. 15: Diagram případů užití

4.2


35

Popis aktorů Odesílatel je fyzická nebo právnická osoba, která využívá služeb České pošty za účelem odeslání zásilky někomu jinému. Přitom se rozhodně nemusí jednat pouze o služby v rámci státu. Vzdálenost, na kterou lze odeslat zásilku je libovolná, tudíž odesílatel může zásilku adresovat prakticky do každého státu po celém světě. Odesílatel je povinen při odesílání zásilky složit jednorázovou platbu ve výši dle ceníku, která se určuje podle několika kritérií. Především velikost, váha, udaná cena zásilky, adresovaný stát a typ posílané zásilky určuje, jak vysoká platba bude. Zaměstnance na přepážce není potřeba nikterak dlouze představovat. Mimo dalších činností týkajících se ostatních služeb ČP, vykonává především pořízení zásilek. Zaměstnanec musí pracovat rychle a myslet obchodně. Znát poštovní podmínky a produkty jak ČP, tak i aliančních partnerů. Kartista je označení pro specifickou funkci v ČP, která zastává dvě specifické skupiny aktivit. Na podací poště provádí především třídění zásilek a tisk přepravního listu a na dodací poště provádí především činnosti spojené s přípravou zásilky k předání doručovateli a po ukončení doručení především činnosti spojené s kontrolou doručených a nedoručených zásilek. Název kartista vznikl před několika lety, když hlavní náplní této funkce byla ruční tvorba doručovacích karet. Přepravce provádí přepravu mezi podací a dodací poštou. V praxi se může jednat o externího (např. České dráhy, a. s.) nebo interního přepravce. Přepravce je řízen samostatným odborem (Odbor přepravy). Doručovatel přebírá zásilky v dodací poště a jeho úkolem je provést pokus o doručení. Pokud je adresát zastižen, doručovatel doručí zásilku a zaznamená doručení v informačním systému. Pokud adresáta nezastihne při pokusu o doručení, pouze oznámí pokus o doručení a zaznamená v informačním systému. 4.2.3

Sekvenční diagramy

Sekvenční diagramy znázorňují časovou posloupnost mezi statickými objekty. Někdy se nazývají též diagramy posloupností. Popisují scénář průběhu činnosti v systému. Výchozím bodem k tvorbě sekvenčních diagramů jsou případy užití. V následujícím výkladu se zaměřím především na případy užití, u kterých sestrojení sekvenčního diagramu má určitý význam a u každého uvedu hlavní scénář. U případů užití, kde může dojít k zjištění různých chyb nebo mimořádných stavů uvedu i scénář alternativní. Při tvorbě sekvenčních diagramů jsem vycházel z doporučení ing. Kanisové a ing. Müllera, kteří nedoporučují zobrazení návratů, které sekvenční diagram znepřehlední. Situace je znázorněna na obrázku č. 17. Z tohoto důvodu budou ostatní diagramy znázorněny bez návratových zpráv a komunikace bude vycházet z rozhraní systému, nikoli přímo od uživatele. Pořízení zásilky Odesílatel přichází na přepážku s vyplněným podacím lístkem, který předává zaměstnanci na přepážce. Ten se přihlašuje do systému (v praxi bývá přihlášen po celou pracovní dobu) a dává pokyn k pořízení zásilky. Systém zobrazí formulář pro zadání potřebných údajů. Po vyplnění údajů in-

4.2


36

formační systém vypočítá cenu pořizované zásilky, která závisí na několika faktorech. Jelikož ceník ČP je velice rozsáhlý, důležité parametry pro výpočet ceny zásilky jsou: • udaný typ zásilky, • hmotnost zásilky, • udaná cena zásilky, • dobírka, • doplňkové služby (pilné, křehké, prodloužit úložní dobu aj.). Nutno podotknout, že pro pořízení hmotnosti zásilky by byla použita elektronická váha připojená k počítači, který si zjištěnou váhu vyplní sám. Po výpočtu ceny se zásilka uloží do databáze zásilek se stavem pořízeno a systém provede tisk potvrzení o podání pro odesílatele pro případnou reklamaci. Stav zásilky je vkládán automaticky, aby se předešlo situacím s podvodem zásilek. Zaměstnanec na přepážce by mohl vložit jiný stav než pořízeno a tím by zodpovědnost za zásilku předal na další zaměstnance.

Obr. 16: Sekvenční diagram – Pořízení zásilky

Při pořizování zásilky může dojít k dvěma mimořádným stavům. Ulice z podacího lístku v systému neexistuje, čili není možné zásilce přiřadit ulici, která slouží později pro zatřídění zásilky. Ke druhému stavu dojde v případě, kdy odesílatel v evidenci ČP neexistuje. Ke zmíněným situacím je nutno rozšířit hlavní scénář o dva alternativní scénáře, které se provedou při zjištění neexistence ulice či odesílatele.

4.2


37

Tab. 2: Hlavní scénář – Pořízení zásilky

Případ užití: Pořízení zásilky Hlavní scénář Krok Role Akce 1 Odesílatel předá zaměstnanci na přepážce vyplněný podací lístek, který obsahuje údaje o odesílateli, adresátovi, informace o dobírce, udané částce, typu zásilky a doplňkových službách 2 Zaměstnanec se přihlásí do systému – viz případ užití Přihlášení do systému 3 Systém přihlásí zaměstnance do systému a založí novou zásilku 4 Zaměstnanec pořídí údaje z podacího lístku do informačního systému 5 Zaměstnanec vloží z číselníků, které jsou typu „typÿ a „městoÿ 6 Zaměstnanec vloží existující ulici z číselníku ulic a odesílatele 7 Systém uloží zadané položky 8 Zaměstnanec spustí funkci na výpočet ceny 9 Systém vypočte cenu zásilky a vytiskne potvrzení o podání 10 Zaměstnanec se odhlašuje ze systému

Tab. 3: Alternativní scénář

Případ užití: Založení nové ulice Alternativní scénář 6a. Ulice neexistuje v seznamu ulic, bude založena nová ulice Krok Role Akce 6a1 Zaměstnanec zvolí nabídku Nová ulice 6a2 Systém založí prázdný formulář pro novou ulici 6a3 Zaměstnanec vloží údaje o ulici 6a4 Systém založí novou ulici a převezme ji do pořízení zásilky

Tab. 4: Alternativní scénář

Případ užití: Založení nového odesílatele Alternativní scénář 6b. Odesílatel neexistuje v seznamu odesílatelů, bude založen nový odesílatel Krok Role Akce 6b1 Zaměstnanec zvolí nabídku Nový odesílatel 6b2 Systém založí prázdný formulář pro nového odesílatele 6b3 Zaměstnanec vloží údaje o odesílateli 6b4 Systém založí nového odesílatele a převezme jeho identifikaci do pořízení zásilky Uvedené hlavní scénáře lze také popsat sekvencí SQL příkazů. Symbol „$ÿ značí proměnnou pořizovanou přímo uživatelem systému (např. do formuláře), symbol „$nazevÿ značí proměnnou získanou z předchozích operací. Symboly byly zvoleny náhodně a záměrně nejsou uvedeny přesné názvy ze systému, aby nedocházelo ke zbytečnému znepřehlednění operací.

4.2

38


Tab. 5: SQL zprávy – Pořízení zásilky

Zpráva Vlož typ Vlož město Vlož ulici Vlož odesílatele

Operace select Typ.id from Typ where Typ.nazev=$ select Mesta.id from Mesta where Mesta.nazev=$ select Ulice.id from Ulice,Mesta where Mesta.id=Ulice.mesto and Mesta.nazev=$ and Ulice.nazev=$ select id,jmeno,adresa from Odesilatel where jmeno=$

Třídění zásilky Pořízenou zásilku je potřeba zatřídit na konkrétní doručovací okrsek. Zatřídění provádí kartista, který by měl mít znalosti doručovacích okrsků. Důležitým prvkem třídění je existence databáze doručovacích okrsků, měst a ulic. Kartista při volbě třídění zásilky zjistí nezatříděné zásilky a jednotlivě je zatříďuje. Třídění probíhá na základě ověření existence ulice v evidenci, přičemž se pro ulici testuje, zda se jedná o ulici uvedeného města z podacího lístku. Z toho je patrné, že číselník měst není pro operaci zatřídění vůbec důležitý. Třídění zásilek je jednou z nejdůležitějších činností. Špatné zatřídění většinou znamená prodloužení doby doručení zásilky, což ČP rozhodně nepřispívá na dobrém jménu. Přiřazení jednotlivých ulic pod doručovací okrsky (včetně provedení změn z důvodu nevyváženosti zatížení jednotlivých okrsků) je starostí systémového administrátora, jehož činnost není pro analýzu a vývoj systému příliš důležitý, proto doručovací okrsky beru jako pevně dané. Pouze v případě vzniku nové ulice zatřízení provádí kartista. Po zatřídění zásilky se mění stav z pořízená na zatříděná.

Obr. 17: Sekvenční diagram – Třídění zásilky

4.2

39


Tab. 6: Hlavní scénář – Třídění zásilky

Případ užití: Třídění zásilky Hlavní scénář Krok Role Akce 1 Kartista se přihlásí do systému – viz případ užití Přihlášení do systému 2 Systém přihlásí kartisty do systému 3 Kartista dá pokyn k zobrazení seznamu pořízených zásilek 4 Systém zobrazí seznam pořízených zásilek 5 Kartista provádí výběr zásilky 6 Kartista dává příkaz k výběru doručovacího okrsku podle adresy zásilky 7 Systém provede ověření doručovacího okrsku 8 Kartista dá pokyn k vložení ověřeného doručovacího okrsku 9 Systém provede zápis doručovacího okrsku zásilce 10 Systém provede aktualizaci stavu zásilky 11 Kartista se odhlašuje ze systému

Při kontrole existence ulice může dojít k situaci, že ulici nebude přiřazen žádný doručovací okrsek, k čemuž dojde v případě, že do evidence ulic přibyla nová ulice při pořízení zásilky. V tomto případě musí kartista provést aktualizaci doručovacích okrsků. Tab. 7: Alternativní scénář

Případ užití: Aktualizace doručovacího okrsku Alternativní scénář 6a. Nenalezen doručovací okrsek pro ulici, bude provedena aktualizace Krok Role Akce 6a1 Kartista zvolí nabídku Aktualizace doručovacího okrsku 6a2 Systém zobrazí seznam doručovacích okrsků 6a3 Kartista provádí výběr doručovacího okrsku k dané ulici 6a4 Systém provede zápis doručovacího okrsku

Tab. 8: SQL zprávy – Třídění zásilky

Zpráva Zobraz seznam zásilek Vyber zásilku Ověř ulici Aktualizuj okrsek Aktualizuj stav

Operace select Zasilky.kod from Zasilky where Zasilky.stav=1 select Zasilky.kod, Zasilky.okrsek from Zasilky where Zasilky.kod=$ select Ulice.okrsek from Ulice, Zasilky where Zasilky.kod=$ and Ulice.id=Zasilky.ulice and Zasilky.mesto=Ulice.mesto update Zasilky set okrsek=$ulice.okrsek where kod=$kod update Zasilky set stav=2 where kod=$kod

Přepravení zásilky Úkolem přepravce je přeprava zásilek z podací pošty na dodací a to v nejkratším možném termínu, proto by mělo být převzetí zásilky rychlé. Přepravce se přihlásí do systému, zvolí postupně doru-

4.2


40

čovací okrsky, které musí přepravit a systém zobrazí seznam zásilek. Nutno dodat, že přepravení zásilek je možné pouze pro pořízené a následně zatříděné zásilky. Zásilky, které nebyly zatříděné, se musejí nejprve zatřídit na příslušný doručovací okrsek. Přepravce zadáním kódu prostřednictvím snímače čárových kódu mění stav zásilky na přepravovaná. Po převzetí všech nalezených zásilek zůstanou zobrazené zásilky, které nebyly převzaty, avšak byly zatříděny.

Obr. 18: Sekvenční diagram – Přepravení zásilky

Tab. 9: Hlavní scénář – Přepravení zásilky

Případ užití: Přepravení zásilky Hlavní scénář Krok Role Akce 1 Přepravce se přihlásí do systému – viz případ užití Přihlášení do systému 2 Systém přihlásí přepravce do systému 3 Přepravce dá pokyn k zobrazení doručovacích okrsků 4 Systém zobrazí seznam doručovacích okrsků 5 Přepravce dá pokyn k zobrazení seznamu zásilek podle doručovacího okrsku 6 Systém zobrazí seznam zásilek vybraného okrsku 7 Přepravce vybírá ze seznamu konkrétní zásilku 8 Systém zobrazí údaje o vybrané zásilce 9 Přepravce dá pokyn k aktualizaci stavu 10 Systém změní stav zásilky na „přepravovanáÿ 11 Přepravce se odhlašuje ze systému

4.2

41


Tab. 10: SQL zprávy – Přepravení zásilky

Zpráva Zobraz seznam dor. okrsků Zobraz seznam zásilek Aktualizuj stav

Operace select Okrsek.nazev from Okrsek select Zasilky.kod from Zasilky, Okrsek where Zasilky.stav=2 and Zasilky.okrsek=Okrsek.id and Zasilky.okrsek=$ update Zasilky set stav=3 where Zasilky.kod=$kod

Převzetí zásilky na dodací poště Převzetí zásilky na dodací poště je činnost, která je důležitá jak pro monitoring stavu zásilky, tak i pro kontrolu a dohledání ztracených zásilek. Převzetí provádí kartista a přebírá dopravené zásilky. Při převzetí zásilky na dodací poště nelze přesně určit, které zásilky měly být přepraveny na danou dodací poštu. Přepravce může přepravovat zásilky na více dodacích pošt, což znamená, že nelze zjistit, které zásilky byly přepraveny pro konkrétní dodací poštu. Ztráty zásilek lze zjistit až při vypořádání zásilek.

Obr. 19: Sekvenční diagram – Převzetí zásilky na dodací poště

Tab. 11: SQL zprávy – Převzetí zásilky na dodací poště



4.2

42


Tab. 12: Hlavní scénář – Převzetí zásilky na dodací poště

Případ užití: Převzetí zásilky na dodací poště Hlavní scénář Krok Role Akce 1 Kartista se přihlásí do systému – viz případ užití Přihlášení do systému 2 Systém přihlásí kartisty do systému 3 Kartista dá pokyn k zobrazení doručovacích okrsků 4 Systém zobrazí seznam doručovacích okrsků 5 Kartista dá pokyn k zobrazení seznamu zásilek vybraného doručovacího okrsku 6 Systém zobrazí seznam zásilek vybraného okrsku 7 Kartista provádí výběr zásilky, kterou přebírá 8 Kartista dá pokyn k aktualizaci stavu zásilky na „připravena k doručeníÿ 9 Systém provede změnu stavu zásilky 10 Kartista se odhlašuje ze systému Převzetí zásilky k doručení Před zahájením doručování je povinností doručovatele převzít zásilky. Jak již bylo zmíněno, převzetí je důležité pro monitoring stavu zásilky a pro zjištění ztracených zásilek. Při převzetí zásilky k doručení již lze sledovat ztracené zásilky na dodací poště. Jestliže zásilka byla převzata na dodací poštu a při převzetí doručovatelem již nebyla nalezena, je zřejmé, že se zásilka ztratila.

Obr. 20: Sekvenční diagram – Převzetí zásilky k doručení

Tab. 13: SQL zprávy – Převzetí zásilky k doručení



4.2


43

Tab. 14: Hlavní scénář – Převzetí zásilky k doručení

Případ užití: Převzetí zásilky k doručení Hlavní scénář Krok Role Akce 1 Doručovatel se přihlásí do systému – viz případ užití Přihlášení do systému 2 Systém přihlásí doručovatele do systému 3 Doručovatel dá pokyn k zobrazení doručovacích okrsků 4 Systém zobrazí seznam doručovacích okrsků 5 Doručovatel dá pokyn k zobrazení seznamu zásilek vybraného doručovacího okrsku 6 Systém zobrazí seznam zásilek vybraného okrsku 7 Doručovatel provádí výběr zásilky, kterou přebírá 8 Doručovatel dá pokyn k aktualizaci stavu zásilky na „převzata k doručeníÿ 9 Systém provede změnu stavu zásilky 10 Doručovatel se odhlašuje ze systému

Doručení zásilky Doručování zásilek probíhá každý všední den (u expresních zásilek i o víkendu). Úkolem doručovatele je provést pokus o doručení převzatých zásilek. Od doručení zásilky prostřednictvím doručovacích karet se značně liší. Doručovací karty papírové formy, v nichž doručovatel prováděl záznamy (včetně podpisu adresáta) a kartista prováděl následné zpracování všech zásilek, které spočívalo ve vybrání stavu zásilky podle pokusu o doručení, znamenaly zbytečné prodloužení pracovní doby obou aktérů.

Obr. 21: Sekvenční diagram – Doručení zásilky

Při doručení zásilky doručovatel ze seznamu zásilek vybírá zásilku, kterou právě doručuje a podle výsledku doručení (zastižen, nezastižen) mění stav zásilky. Problém nastane v případě, když

4.2

44


při pokusu o doručení danou zásilku fyzicky nenalezne. V tomto případě neučiní pokus o doručení a ztrátu zásilky provede kartista při vypořádání zásilek. Tab. 15: Hlavní scénář – Doručení zásilky

Případ užití: Doručení zásilky Hlavní scénář Krok Role Akce 1 Doručovatel se přihlásí do systému – viz případ užití Přihlášení do systému 2 Systém přihlásí doručovatele do systému 3 Doručovatel dá pokyn k zobrazení doručovacích okrsků 4 Systém zobrazí seznam doručovacích okrsků 5 Doručovatel dá pokyn k zobrazení seznamu zásilek vybraného doručovacího okrsku 6 Systém zobrazí seznam zásilek vybraného okrsku 7 Doručovatel provádí výběr zásilky, kterou právě doručuje 8 Doručovatel vybírá stav zásilky podle výsledku doručení 9 Systém provede změnu stavu zásilky 10 Doručovatel se odhlašuje ze systému

Tab. 16: SQL zprávy – Doručení zásilky

Zpráva Zobraz seznam dor. okrsků Zobraz seznam zásilek Vyber zásilku Aktualizuj stav

Operace select Okrsek.nazev from Okrsek select Zasilky.kod from Zasilky, Okrsek where Zasilky.stav=5 and Zasilky.okrsek=Okrsek.id and Zasilky.okrsek=$ select Zasilky.kod, Zasilky.okrsek from Zasilky where kod=$ update Zasilky set stav=6 where Zasilky.kod=$kod

Vypořádání zásilky Vypořádání neboli vyúčtování zásilek je poslední činnost prováděná v rámci pracovní směny kartisty. Při vypořádání zásilek probíhá kontrola zásilek, které nebyly doručeny z důvodu nezastižení adresáta. Tedy kontrola zásilek se stavem oznámeno. Zásilkám se nastaví úložní doba (podle typu zásilky a doplňkových služeb) a uloží se na dodací poštu, odkud si je může adresát vyzvednout. Nevyzvedne-li si zásilku v termínu, je zásilka odeslána zpět odesílateli. U vypořádané zásilky dochází ke změně stavu na oznámeno, případně ztraceno, když doručovatel zásilku v průběhu doručení ztratí.

4.2

45


Obr. 22: Sekvenční diagram – Vypořádání zásilky

Tab. 17: Hlavní scénář – Vypořádání zásilky

Případ užití: Vypořádání zásilky Hlavní scénář Krok Role Akce 1 Kartista se přihlásí do systému – viz případ užití Přihlášení do systému 2 Systém přihlásí kartisty do systému 3 Kartista dá pokyn k zobrazení doručovacích okrsků 4 Systém zobrazí seznam doručovacích okrsků 5 Kartista dá pokyn k zobrazení seznamu zásilek vybraného doručovacího okrsku 6 Systém zobrazí seznam zásilek vybraného okrsku 7 Kartista provádí výběr zásilky 8 Systém zobrazí informace o zásilce 9 Kartista provádí výběr stavu zásilky „uloženoÿ 10 Systém provádí aktualizaci stavu zásilky 11 Kartista se odhlašuje ze systému

Tab. 18: SQL zprávy – Vypořádání zásilky

Zpráva Zobraz seznam dor. okrsků Zobraz seznam zásilek Vyber zásilku Aktualizuj stav

Operace select Okrsek.nazev from Okrsek select Zasilky.kod from Zasilky, Okrsek where Zasilky.okrsek=$ and (Zasilky.stav=6 or Zasilky.stav=7) and Zasilky.okrsek=Okrsek.id select Zasilky.kod, Zasilky.okrsek from Zasilky where kod=$ update Zasilky set stav=$ where Zasilky.kod=$kod

4.2


4.2.4

46

Diagramy aktivit

Diagramy aktivit, jak již bylo uvedeno v přehledu literatury, zobrazují sekvenci aktivit, které podporují sekvenční i paralelní chování a umožňují rozvětvení. Právě rozvětvení umožní zobrazit konkrétní případ užití do jednoho diagramu, který obsahuje všechny alternativní možnosti užití daného případu. Diagram aktivit je vhodný použít pro případy užití, kde existuje alespoň jeden alternativní scénář. V ostatních případech diagram zobrazuje pouze po sobě jdoucí aktivity. V následujícím textu uvedu pouze diagramy, které obsahují větvení, aby bylo patrné, které aktivity se provádějí při určitých podmínkách. Pořízení zásilky Use case pořízení zásilky již byl vysvětlen v předešlém výkladu. Důležitou změnou oproti současnému řešení je existence databáze odesílatelů a možnost přidání ulice v případě, že se ji nepodařilo nalézt v evidenci ulic, což znamená částečně otevřený systém pro zaměstnance na přepážce. Evidence odesílatelů umožní evidovat počty odeslaných zásilek jednotlivými subjekty a jejich cenové zvýhodnění při určitých počtech a také urychlení provozu na přepážkách.

Obr. 23: Diagram aktivit – Pořízení zásilky

4.2


47

Třídění zásilky Správné zatřídění je klíčem k rychlému a správnému doručení zásilky. Aby bylo zatřídění správné a přesné, je využita evidence měst, ulic a doručovacích okrsků. Pro nově přidané ulice z pořízení zásilky je při třídění nutná aktualizace doručovacího okrsku dané ulice. Zatřízení nové ulice probíhá na základě věstníku (při vzniku nové ulice je tato ulice oznámena ve věstníku, než dojde k zatřídění administrátorem) nebo se musí telefonovat na centrálu, která zjistí přesné zatřídění nové ulice.

Obr. 24: Diagram aktivit – Třídění zásilky

Doručení zásilky Provádění aktivit při doručení zásilky je závislé na tom, zda byl při pokusu o doručení adresát zastižen či nikoli. Při nezastižení doručovatel vyplňuje oznamovací lístek, kterým oznamuje adresátovi, že byl učiněn pokus o doručení a pokyny pro vyzvednutí zásilky. Jestliže byl adresát zastižen a zásilka byla doručena, provádí doručovatel změnu stavu zásilky na doručena. Oznámené zásilky jsou označeny stavem nedoručena a dále se zpracovávají v procesu vypořádání zásilky.

4.2


48

Obr. 25: Diagram aktivit – Doruční zásilky

Vypořádání zásilky Jak již bylo uvedeno v předchozím textu, oznámené zásilky se dále zpracovávají v procesu vypořádání zásilky. Aktivity jsou prováděny podle vybrané zásilky. Jedná-li se o oznámenou zásilku provádí se aktivity uložení zásilky, nastavení stavu na uložena a probíhá výpočet úložní doby zásilky v závislosti na typu a doplňkových službách zásilky. Ztracené zásilky se evidují ve speciální databázi z důvodu pozdějšího nalezení. Nenalezené zásilky se po určité době strhávají dotyčné osobě ze mzdy.

4.2


49

Obr. 26: Diagram aktivit – Vypořádání zásilky

4.2.5

Stavový diagram

Stavový diagram je jednou z technik, které znázorňují chování systému. Popisuje všechny možné stavy, které může nabývat objekt napříč všemi případy užití. Z požadavku monitorování stavu zásilky je patrné, že zásilka, aby mohla být sledována, musí obsahovat informaci o stavu. V každém případu užití objekt zásilka mění svůj stav a tím je jasně identifikovatelné, kde se zásilka nachází (jaký má stav). Diagram obsahuje tři speciální stavy. Stav Start je bodem zahájení diagramu a je reprezentován příchodem zákazníka na přepážku. Stav Splněno doručení je žádoucí stav, kterého je dosaženo v případě, že je zásilka doručena nebo vyzvednuta adresátem. Třetího stavu Nesplněno doručení je dosaženo v případě, kdy si adresát nevyzvedne uloženou zásilku v předepsaném termínu.

4.2


50

Obr. 27: Stavový diagram

Pořízená a následně zatříděná zásilka může být buď převzata k přepravě, nebo převzata na dodací poštu. Záleží na doručovacím okrsku, jestli zásilka potřebuje přepravit či nikoli. Po převzetí zásilky na podací poště je zásilka ve stavu připravena k doručení a v tomto stavu čeká na příchod doručovatele. Doručovatel převezme zásilky, čímž změní stav na převzata k doručení. Následuje pokus o doručení, které může dopadnout dvěma výsledky. Adresát nebyl zastižen a tím pádem zásilka nebyla doručena nebo zastižen byl a zásilka přechází do stavu doručena. Vypořádáním ne-

4.2


51

doručených zásilek dochází ke změně stavu na uložena, ve kterém zásilka čeká na další událost. Pokud uplyne úložní doba zásilky, přechází do stavu na cestě zpět a následuje koncový stav. Vyžádáním (zatelefonováním na dodací poštu) druhého doručení zásilka přechází do stavu připravena k doručení a situace se opakuje s tím rozdílem, že v případě nedoručení zásilky je zásilka uložena a již nemůže být vyžádáno další doručení. 4.2.6

Diagram tříd

Diagram tříd zobrazuje statický pohled na systém. Obsahuje jednu rozsáhlou třídu Zásilka. Ta vzniká pořízením zásilky na podací poště a uchovává informace o dalších objektech. Objekt Odesílatel definuje údaje o odesílateli dané zakázky a je zřejmé, že každá instance Zásilky má právě jednu instanci v Odesílateli. Třída zásilka je ve vazbě s třídou Zaměstnanec, která definuje zaměstnance, který provedl pořízení zásilky. Podobně platí, že každá instance Zásilky má právě jednu instanci v Zaměstnanci. Třídy Doručovací okrsky, Ulice a Město definují přesnou adresu a doručovací okrsek zásilky. Instance Zásilka má právě jednu instanci v třídách Doručovací okrsky, Ulice i Města.

Obr. 28: Diagram tříd

4.3

4.3

Zhodnocení funkčnosti navržené inovace

52

Zhodnocení funkčnosti navržené inovace

Funkčnost navržené inovace vychází z požadavků na její realizaci a oproti stávajícímu řešení znamená značné vylepšení. Zavedení komplexního informačního systému by značně urychlilo většinu podnikových procesů, což by znamenalo rychlejší doručení zásilky. Podstatný rozdíl oproti současnému řešení je již samotné pořízení zásilky na podací poště. Evidence odesílatelů může značně zkrátit čekání ve frontě na podání zásilky, jelikož činnost spojená s pořízením bude rychlejší právě načtením existujícího odesílatele. Současně by ČP mohla zavést cenové zvýhodnění stálým odesílatelům (e-shopy, reklamační servisy, dodavatelské firmy, . . . ), což by mohlo znamenat příliv zákazníků, kteří nyní posílají zásilky přes konkurenční firmy. Informační systém by také obsahoval funkci na výpočet ceny odesílané zásilky, která by zohledňovala právě počet odeslaných zásilek, typ zásilky, váhu, udanou cenu, dobírku aj. Dalším výrazným vylepšením je možnost sledování stavu zásilky, které může využít jak odesílatel, tak adresát zásilky. Odesílatel využije službu pro zjištění zda byla zásilka doručena a pokud ano, může v následujících pár dnech očekávat připsání dobírkové částky na účet, což může být pro menší podniky, které jsou závislé na každé platbě důležité. Adresát využije službu především pro zjištění, kdy mu bude zásilka doručena. Monitoring stavu zásilky umožní rychlé a pohodlné nalezení konkrétní zásilky v případě ztráty. Kartista stiskem jednoho tlačítka zobrazí chybějící zásilky, což znamená podstatný rozdíl oproti současnému řešení, kde dohledání zásilky je velice pracné a časově náročné. Systém zefektivňuje i předávání zásilek mezi poštami s mezikrokem přepravy, které v současném řešení je, dle mého soudu, zcela nevyhovující a trvá několikanásobně déle než pomocí navržené inovace. Přebírající by pouze snímačem čárových kódu sejmul kód zásilky a systém by již zásilku evidoval jako převzatou. V navržené inovaci je otázkou pár minut převzetí všech zásilek narozdíl od stávajícího řešení, které spočívá v hledání kódu zásilky v několika stránkovém dokumentu a následném označení převzaté zásilky. Samotné doručení zásilky probíhá přímo v systému takže doručovatel ihned zaznamená výsledek doručení. Oproti současnému řešení přináší komunikace doručitele se systémem řadu výhod. Stav zásilky je tedy ihned zaznamenán. Kartista nemusí vyplňovat žádnou doručovací kartu, kterou by pak musel zpracovat kartista při vypořádání doručených zásilek, čímž se přispěje k rychlejším odbavovaní doručovatelů na konci pracovní směny při vypořádání zásilek. Pouze nedoručené a ztracené zásilky během doručení jsou kontrolovány, čímž jde uvést proces vypořádání jako proces, ve kterém probíhá zpětné převzetí nedoručených zásilek na dodací poštu a případné zaznamenání ztracených zásilek. Na závěr zhodnocení funkčnosti je třeba podotknout, že navržená inovace vychází především z vlastního know-how této problematiky, což by v praxi mohlo vést ke tvorbě nevyhovujícího systému, jelikož zapojení zaměstnanců do definice požadavků bylo minimální.

4.4

Zhodnocení nákladů a přínosů navržené inovace

Vyčíslení nákladů a přínosů informačního systému je velice obtížná činnost. Při návrhu systému je potřeba zodpovědět otázku: „Kolik bude stát vývoj nového informačního systému?ÿ. Odhad ceny hraje důležitou roli při výběru alternativ, zjištění jejich efektivnosti a dobu návratnosti investice.

4.4


53

Uvést seznam všech nákladů je prakticky nemožné, i přesto se budu snažit uvést seznam nákladů při vývoji mnou navržené inovace. 4.4.1

Náklady

Kalkulace nákladů se většinou dělí na jednorázové a pravidelné. Jednorázové náklady se vyskytují pouze jednou v průběhu vývoje celého systému a mnou navržené inovaci by se jednalo o: • Náklady na vývoj systému – pořízení technologií pro vývoj systému, tzn. specifický hardware a software (například Enterprise Architect), který bude použit pouze pro etapu vývoje. Dalšími náklady na vývoj systému by mohly být mzdové náklady externích pracovníků, které by ČP najímala v případě potřeby, také výdaje za konzultace aj. • Náklady na investice – zahrnují veškeré technologie potřebné k implementaci nového systému. Jelikož ČP disponuje zastaralými technologiemi, tvořila by položka náklady na investice značnou část celkových nákladů. Jedná se především o náklady na kapesní počítače (PDA), které by musel mít každý doručovatel, aby mohl kdekoli na cestách pracovat se systémem a ihned měnit stav zásilky, dále náklady na pořízení snímačů čárových kódů ke každému PC, elektronické váhy na každou přepážku, terminály blízko nákladových ramp, aby bylo zajištěno rychlé převzetí zásilek, náklady na pořízení serverů a pracovních stanic. • Náklady na implementaci – zahrnují především náklady spojené s konverzí existujících dat do nově vytvořené databáze a náklady na školení zaměstnanců pro práci s novým informačním systémem. Pravidelné náklady se vyskytují opakovaně (např. každý měsíc) a představují především náklady spojené s údržbou informačního systému. Do pravidelných nákladů lze uvést náklady na energii, které by při navrženém řešení značně vzrostly (použití více počítačů, terminálů, snímačů čárových kódů, kapesních počítačů), mzdové náklady IT pracovníků pro údržbu hardware a software, náklady na pronájem prostor pro umístění serveru. 4.4.2

Přínosy

Druhou stránkou od nákladů na informační systém jsou jeho přínosy. Přínosy přispívají k tvorbě výnosů a společně s náklady lze odvodit návratnost vložených investic. Podle vypočtené návratnosti se hodnotí různé alternativní řešení a provede se výběr konečné varianty. Přínosy se dělí na kvantifikovatelné a nekvantifikovatelné. Kvantifikovatelné ovlivňují přímo důchod podniku a nekvantifikovatelné jsou spíše určité vlastnosti a charakteristiky daného systému, které nelze přímo vyčíslit. Kvantifikovatelné přínosy navržené inovace: • možnost zpracovat větší objem zásilek, čímž se předejde situaci z období Vánoc loňského roku, kdy ředitel ČP vyhlásil „stopÿ stav, jelikož nebylo možné uspokojit s danými kapacitami poptávku zákazníků, • snížení jak mzdových nákladů při snížení stavu zaměstnanců, tak snížení nákladů na papír a náplně do tiskáren, které při tisku všech dokumentů nebyly zanedbatelné, • zvýšení počtu zákazníků zavedením zvýhodněných cen na základě evidence odesílatelů a počtu odeslaných zásilek.

4.4


Nekvantifikovatelné přínosy: • kvalitnější a přesnější monitoring zásilek, • zlepšení jména firmy, • menší fronty na přepážkách, • zlepšení pracovního prostředí, • rychlejší doručení zásilek, • rychlejší přístup k informacím (ztracené zásilky), • zvýšení kvality poskytovaných služeb.

54

5

NAVRŽENÁ APLIKACE

5

55

Navržená aplikace

Analýzou stávajících podnikových procesů byly zjištěny určité nedostatky a podniku bylo doporučeno zavést komplexní informační systém, který by podporoval všechny (nebo alespoň všechny potřebné) podnikové procesy. Funkční požadavky již byly v předchozím textu uvedeny a zbývá stanovit nefunkční požadavky na informační systém. Jedná se o požadavky, které specifikují vlastnosti systému (nikoli funkce). Navržený informační systém by měl splňovat následující nefunkční požadavky: • • • •

rychá odezva, přehledné grafické uživatelské rozhraní, důsledné zabezpečení systému, snadné ovládání.

Rychlost odezvy je jedním z klíčových nefunkčních požadavků. Aby práce zaměstnanců byla rychlejší než dosud, je potřeba koncipovat informační systém z jednoduchým rozhraním bez zbytečných obrázků, které zbytečně zpomalují celý informační systém. Je nutno si uvědomit, kolik zaměstnanců by se systémem pracovalo a pak na tento počet informační systém připravit. Na efektivitu práce zaměstnanců také působí vliv pracovního prostředí. Grafické uživatelské rozhraní je v dnešní době nutný požadavek. V zásadě by měl být uzpůsoben podle uživatelů systému, ale názory na uživatelské rozhraní se mohou lišit, což způsobí tvorbu jednotného uživatelského rozhraní, na které si musí každý zvyknout. Uživatelské rozhraní musí být jednoduché a přehledné, aby byly požadované funkce rychle nalezeny. Bezpečnost informačního systému je zpravidla stejná pro většinu systémů. Jelikož cílem práce není bezpečnost informačního systému, nebudu dále bezpečnost rozebírat. Aplikace umožňuje provádět všechny činnosti od pořízení až po doručení zásilky. Pořízení zásilky je oproti současnému řešení rozděleno do několika formulářů, kterými se musí zaměstnanec proklikat. Důvodem pro změnu oproti současnému pořízení zásilky je především zobrazení seznamu ulic po zadání cílového města. Systém po výběru města zobrazí pouze ulice, které jsou skutečně v zadaném městě. Tím je docíleno přesné identifikace adresáta zásilky. Samozřejmostí je také funkce pro přidání nové ulice (v případě, že neexistuje v databázi) a nového odesílatele. Funkce na výpočet ceny za odesílanou zásilku není uvedena, jelikož ČP má značně rozsáhlý ceník. Stanovení cen a slev za určitý počet odeslaných zásilek by mělo být úkolem managementu. Třídění zásilky, jak již bylo uvedeno, musí být rychlé a především přesné. Aplikace řeší třídění zásilky jednoduše. Město a ulice přesně specifikují doručovací okrsek a nemůže dojít k chybnému zatřídění. Pouze chyba v přiřazení ulice do špatného okrsku by znamenala špatné zatřídění. V případě, že nelze specifikovat doručovací okrsek (jediným možným případem je přidání nové ulice), provádí zatřídění zásilky kartista ručně ze seznamu doručovacích okrsků. Ruční zatřídění určí jak doručovací okrsek zásilce, tak doručovací okrsek pro novou ulici a při příším třídění stejné ulice se zásílka zatřídí automaticky. Proto by měl kartista dbát na správné zatřídění. Přeprava, převzetí zásilky na dodací poštu a převzetí zásilky k doručení neobsahují žádné složité operace. Při těchto činnostech probíhá pouze změna stavu zásilky z důvodů, které již byly vysvětleny. Doručení zásilky by mělo především usnadnit práci doručovatelů. Ti se ve svém ka-

5

NAVRŽENÁ APLIKACE

56

pesním počítači zobrazí zásilky, které mají doručit a poté jednotlivě v průběhu doručení zadávají k právě doručené zásilce výsledek doručení. Výslednou aplikaci je možno nalézt na adrese http://akela.mendelu.cz/~xfric/DP/. Obsahuje jednoduché uživatelské rozhraní a podporuje všechny uvedené funkce. Ke každé funkci je v pravé části obrazovky zobrazena nápověda, aby bylo jasné, jak s aplikací pracovat. Aplikace je realizována v jazyce PHP a spolupracuje s databázovým systémem Oracle a je umístěna na školním serveru akela.

Obr. 29: Ukázka aplikace - pořízení zásilky

5

NAVRŽENÁ APLIKACE

Obr. 30: Ukázka aplikace - třídění zásilky

Obr. 31: Ukázka aplikace - doručení zásilky

57

6

6

ZÁVĚR

58

Závěr

Cílem této diplomové práce bylo provést analýzu současných podnikových procesů u společnosti Česká pošta, jelikož s přibývajícím počtem odesílaných zásilek se stává, že ČP nedokáže kapacitně pojmout takové obrovské množství zásilek a především v období Vánoc dochází ke zpoždění doručených zásilek až o několik dní, čímž podnik přichází o zákazníky, kteří radši pošlou zásilku přes jinou konkurenční firmu. Současné řešení bylo třeba namodelovat a bylo provedeno jeho důkladné zhodnocení, které se stalo východiskem pro návrh inovace. Před návrhem inovace jsem na základě svého know-how z dané problematiky a spolupráce se zaměstnanci ČP (kartista, doručovatel) stanovil požadavky na nový systém, který by umožnil zvýšit kapacity doručených zásilek, monitoring zásilek, evidenci odesílatelů a další výhody, které jsou v práci uvedeny. Při návrhu nového systému byla použita notace UML a stanovené případy užití systému byly zobrazeny prostřednictvím sekvenčních diagramů, hlavních scénářů a také prostřednictvím SQL zpráv, které vysvětlují komunikaci mezi objekty. Prostřednictvím stavového diagramu byl vysvětlen požadavek monitoringu stavu zásilky, který umožňuje rychlé a pohodlné zobrazení informace o stavu, ve kterém se zásilka právě nachází, což umožňuje dohledání ztracených zásilek, s nimiž má podnik stále větší problémy. Navržená inovace podnikových procesů byla v práci zhodnocena podle funkčnosti a také z ekonomického hlediska, které by bylo důležité při hodnocení a výběru správné alternativy. Dalším cílem této práce bylo zrealizovat část inovace v jazyce PHP s použití databáze Oracle. Aplikace je popsaná v samostatné kapitole a jsou uvedeny její výhody a další doporučení její tvorbě. Uvedený systém prezentuje pouze kostru řešení. Pokud by společnost chtěla ještě více minimalizovat náklady, mohla by optimalizovat doručení zásilky zavedením GPS navigace, která už je součástí téměř většiny nejnovějších kapesních počítačů. Doručovatel by v tomto případě doručoval na základě systémem vypočtené optimální trasy, která by znamenala ušetření nákladů na pohonné hmoty. Za zvážení stojí také další snížení mzdových nákladů zavedením dvojího třídění zásilky. První třídění by zahrnovalo pouze stanovení cílové dodací pošty, čímž by se snížily náklady na mzdy propuštěním části kartistů, kteří na podací poště provádějí přesné třídění na konkrétní doručovací okrsek. První třídění by probíhalo ihned při podání zásilky a to na základě poštovního směrovacího čísla a druhé třídění na konkrétní doručovací okrsek by bylo již v kompetenci cílové dodací pošty. Dalším možným vylepšením by byla existence každodenního doručovacího plánu, který by byl zaznamenán v systému a nedocházelo by k situacím, kdy jeden doručovatel omylem převezme zásilky jiného okrsku, který měl doručovat jiný doručovatel. Předešlo by se docela častému výskytu problému, který především zdržuje a následně vznikají prodlevy v doručení zásilky. Rozpis by znamenal nemožnost přebrat zásilky jiného okrsku než přiděleného. Navržený systém by bylo potřeba stále zdokonalovat a dále vyvíjet. Především zaměstnanci, kteří pracují se systémem každý den, by měli uvádět další podněty na nové funkce a vylepšení, aby podnikové procesy probíhaly efektivněji. Jen každodenní práce se systémem umožní odhalit jeho nedostatky. Jelikož zapojení zaměstnanců na stanovení požadavků na nový systém bylo pouze okrajové, může se stát, že systém bude zcela ignorovat určité funkce, které by urychlily činnost zaměstnanců. Hlavne z tohoto důvodu je zapojení zaměstnanců, ale i jiných osob, kteří budou využívat nový systém, velice důležité.

6

ZÁVĚR

59

Troufám si tvrdit, že bylo ve všech ohledem dosaženo stanovených cílů a ČP by zavedením takového systému mohla získat značnou konkurenční výhodu v boji o zákazníka. Na druhou stranu by zavedení takového komplexního systému znamenalo jisté problémy při implementaci, jelikož jak bylo uvedeno, ČP eviduje kolem 3 400 poboček a 37 500 zaměstnanců a jen školení takového počtu zaměstnanců by bylo dosti obtížné. Práce bude předložena poštmistrovi pobočky České pošty na ulici Opavská k posouzení vyvozených závěrů.

7

7

LITERATURA

60

Literatura

Davenport, T. H. Process Innovation: Reengineering Work through Information Technology. Boston: Harvard Business School Press, 1993, ISBN 0-87584-366-2. Eriksson, H. E. Penker, M. Business modeling with UML: business patterns at work. 2. vydání. New York: John Wiley & sons, INc., 2000, ISBN 0-471-29551-5. Kanisová, H. Müller, M. UML srozumitelně. 1.vyd. Brno: Computer Press, 2004. 158 s. ISBN 80-251-0231-9. Konečný V. Informační systémy. Skripta předmětu. Brno: MZLU, 2006. Kosek J. PHP : tvorba interaktivních internetových aplikací. 1. vyd. Praha: Grade Publishing, 1998. 492 s. ISBN 80-7169-373-1. Pour J. Informační systémy a technologie: úvod do studia. Praha: VŠE, 1999. Procházka J. Databázový svět: Informační portál. [online]. c2004 [cit. 2008-04-20]. Dostupný na WWW: http://www.dbsvet.cz/view.php?cisloclanku=2004052702. Řepa V. Podnikové procesy: procesní řízení a modelování. 2. vyd. Praha: Grade, 2007. 281 s. Management v informační společnosti. ISBN 978-80-247-2252-8.

Česká pošta, podnikové procesy a jejich modelování

Recommend Documents