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

Transkript

1 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

2 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.

3 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

4 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 5 Obsah 1 Úvod a cíl práce Úvod Cíl práce Přehled literatury Podnikové procesy Potřeba zlepšování procesů Průběžné zlepšování procesů Business Process Reengineering (BPR) Srovnání CPI a BPR Objektový přístup Objekt Třída Specifikace požadavků UML - Unified Modeling Language Historie UML UML Diagram případů užití (Use Case diagram) Diagram tříd (Class diagram) Sekvenční diagram (Sequence diagram) Stavový diagram (State diagram) Diagram aktivit (Activity diagram) Modelování podnikových procesů CASE nástroje Druhy CASE Enterprise Architect Česká pošta, s. p Charakteristika podniku Organizační struktura Vlastní řešení Analýza současného řešení BPM Diagram aktivit Zhodnocení současného řešení Navrhované řešení Požadavky Use Case diagram Sekvenční diagramy Diagramy aktivit

6 OBSAH Stavový diagram Diagram tříd Zhodnocení funkčnosti navržené inovace Zhodnocení nákladů a přínosů navržené inovace Náklady Přínosy Navržená aplikace 55 6 Závěr 58 7 Literatura 60

7 1 ÚVOD A CÍL PRÁCE 7 1 Úvod a cíl práce 1.1 Ú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

8 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.

9 2 PŘEHLED LITERATURY 9 2 Přehled literatury 2.1 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 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í 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.

10 2.1 Podnikové procesy 10 Obr. 1: Průběžné zlepšování procesů 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.

11 2.2 Objektový přístup 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 Zlepšení Inovace Úroveň změny postupná radikální Počáteční bod existující proces zelená louka Frekvence změn jednorázová/průběžná jednorázová Potřebný čas krátký dlouhý Participace zespoda nahoru shora dolů Typický rozsah omezený široký Rizikovost střední vysoká Primární nástroj klasické - statické řízení informační technologie Typ změny kulturní kulturní/strukturní 2.2 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 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í

12 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) 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í

13 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 UML - Unified Modeling Language 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ů 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

14 2.4 UML - Unified Modeling Language 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 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ů.

15 2.4 UML - Unified Modeling Language 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 č 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í

16 2.4 UML - Unified Modeling Language 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 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ý.

17 2.4 UML - Unified Modeling Language 17 Obr. 6: Diagram tříd příklad 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 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)

18 2.4 UML - Unified Modeling Language 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 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é,

19 2.4 UML - Unified Modeling Language 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í.

20 2.5 Modelování podnikových procesů Modelování podnikových procesů 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.

21 2.5 Modelování podnikových procesů 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.

22 2.6 CASE nástroje 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 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í,

23 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 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.

24 3 ČESKÁ POŠTA, S. P Česká pošta, s. p. 3.1 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 poboček a je se 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 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

25 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

26 4 VLASTNÍ ŘEŠENÍ 26 4 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 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-

27 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

28 4.1 Analýza současného řešení 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 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.

29 4.1 Analýza současného řešení 29 Obr. 14: Diagram aktivit ČP 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ž-

30 4.1 Analýza současného řešení 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.