UNICORN COLLEGE
Katedra ekonomie a managementu
BAKALÁŘSKÁ PRÁCE Restrukturalizace obchodních procesů pomocí informačního systému v prostředí České pošty, s. p.
Autor práce: Dušan Ryban Vedoucí práce: Ing. Jakub Lodr 2013 Praha
Čestné prohlášení Čestně prohlašuji, že jsem bakalářskou práci na téma Restrukturalizace obchodních procesů pomocí informačního systému v prostředí České pošty, s. p. vypracoval samostatně pod vedením Ing. Jakuba Lodra a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb.
V Praze dne 27. dubna 2013 Dušan Ryban
Poděkování Děkuji vedoucímu bakalářské práce Ing. Jakubovi Lodrovi za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.
Restrukturalizace obchodních procesů pomocí informačního systému v prostředí České pošty, s. p. Restructuring of business processes with an information system in Czech post
5
Abstrakt: Předložená bakalářské práce se zabývá analýzou potřeby a zhodnocení možných přínosů informačního systému v obchodní divizi České pošty s. p. Teoretická část se věnuje způsobu analyzování a modelování procesů. Tyto postupy jsou následně použity v praktické části, kde je analyzován detailně administrativní proces vzniku a správy smluv. Navazuje návrh efektivnějšího řešení procesu pomocí informačního systému. V rámci návrhu se práce zaměřuje na vytvoření logiky systému, která by eliminovala slabé stránky analyzovaného procesu. Následující část práce se bude věnovat samotné implementaci navrženého řešení. Výsledek implementovaného řešení bude vyhodnocen po ekonomické stránce a po stránce dopadu do procesní a personální struktury obchodní divize České pošty s. p. Klíčová slova: Procesní analýza, Česká pošta, vznik a správa smluv, informační systém, návrh změny procesu.
Abstract: The present thesis deals with the needs analysis and evaluation of the potential benefits of an information system in a business division of Czech post. Theoretical part deals with ways of analyzing and modeling processes. These procedures are then used in the practical part, where is analyzed in detail the process of contract administration. Analysis is followed by draft of more effective process using the information system. Within the draft, the work focuses on a logic system that would eliminate the weaknesses of the analyzed process. The following part will focus on the actual implementation of the proposed solution. The result of the implemented solution will be evaluated in economic terms and in terms of impact on the process and personnel structure of Czech post business division. Keywords: Process analysis, Czech post, the creation and management of contracts, information system, process modeling.
6
Obsah 1
Úvod .................................................................................................................... 9
2
Procesní analýza ................................................................................................ 11 2.1
Výhody procesní analýzy ........................................................................... 11
2.2
Rizika procesní analýzy ............................................................................. 14
2.3
Charakteristika procesu .............................................................................. 15
2.4
Modelování procesů ................................................................................... 16 Analýza a implementace procesního zlepšení ................................................... 18
3 3.1
Charakteristika obchodního prostředí České pošty .................................... 18
3.1.1
Struktura obchodního regionu .............................................................. 19
3.1.2
Procesy obchodního oddělení regionu ................................................. 22
3.1.3
Systémová vybavenost obchodu ČP..................................................... 24
3.2
Analýza procesu vzniku a správy smluv .................................................... 26
3.2.1
Cíle procesu .......................................................................................... 26
3.2.2
Role v procesu ...................................................................................... 27
3.2.3
Objekty procesu .................................................................................... 27
3.2.4
Procesní mapa....................................................................................... 29
3.2.5
Průběh procesu ..................................................................................... 31
3.2.6
Výstupy procesu ................................................................................... 33
3.2.7
Obtíže a nedostatky procesu ................................................................. 33
3.2.8
Návrh metrik......................................................................................... 34
3.3
Návrh řešení s odhadem přínosu ................................................................ 36
3.3.1
Cíle navrhovaného řešení ..................................................................... 36
3.3.2
Návrh logiky systému ........................................................................... 37
3.3.3
Odhad přínosu ...................................................................................... 42
3.4 3.4.1
Implementace řešení................................................................................... 43 Charakteristika systému PPECKA ....................................................... 43 7
3.4.2
Pilotní provoz ....................................................................................... 44
3.4.3
Implementace ....................................................................................... 44
3.4.4
Migrace dat ........................................................................................... 44
3.4.5
Důsledek změny procesu ...................................................................... 45
3.5
Hodnocení implementace a řešení ............................................................. 46
3.5.1
Přínos v procesu ................................................................................... 46
3.5.2
Finanční hodnocení .............................................................................. 48
4
Závěr .................................................................................................................. 49
5
Conclusion ......................................................................................................... 50
6
Seznam použitých zdrojů .................................................................................. 51
7
Seznam obrázků................................................................................................. 52
8
Seznam tabulek .................................................................................................. 53
8
1 Úvod Česká pošta, s. p. (dále jen „Česká pošta“) je největším zaměstnavatelem na území České republiky s enormním množstvím zaměstnanců, které čítá okolo třicet tři tisíc lidí. Z tohoto množství se přibližně šest tisíc zaměstnanců vyskytuje na administrativních pozicích. Vzhledem k tomu, že je velmi náročné a finančně nákladné řídit efektivně procesy takového množství zaměstnanců, má Česká pošta v této oblasti značné rezervy. Administrativní práce tak zahrnuje výrazné množství manuálních úkonů, pouze s podporou základních tabulkových a textových softwarů. V posledních letech se ovšem Česká pošta začala zaměřovat na podporu těchto administrativních prací pomocí informačních systémů, které jsou schopny výraznou část práce automatizovat. Automatizace těchto činností v takovém množství, jaké zpracovává právě Česká pošta, dokáže přinést výrazné finanční úspory, zefektivnění práce, případně snížení personálních nákladů. Jedním z prvních takových systémů, který začala využívat obchodní divize České pošty k podpoře vzniku a správy smluv, byl systém PPECKA, kterému se bude věnovat tato bakalářská práce. Praktická část práce bude reflektovat skutečný projekt, realizovaný autorem v roce 2010. Předmětem praktické částí práce bude projekt implementace informačního systému do obchodního prostředí České pošty s cílem optimalizovat a automatizovat administrativu procesu vzniku a správy smluv. Přechod na informační systém s sebou nese nutnou rekonstrukci stávajícího procesu. Proto projekt vychází z analýzy současného stavu, která zahrnuje posloupnost jednotlivých aktivit, nastavení metrik procesu a identifikuje všechny důležité prvky, vyskytující se v procesu. Analýza si klade za cíl získat know-how procesu a nalézt jeho slabé a kritické body, aby mohly být implementací nového systému efektivně eliminovány. Na analýzu současného stavu navazuje návrh informačního systému, jehož účelem je navržení takových vlastností systému, aby jednak zapadly do obchodních procesů a zároveň nalezení konkrétních způsobů, jak zlepšit slabé stránky procesu. Návrh systému si ve výsledku pokládá za cíl přenést co největší množství práce z vykonavatelů procesu na nový systém. Jeho součástí je dále návrh samotné logiky systému, zaměřující se na jednotlivé klíčové body procesu. Navrhovaný systému bude následně implementován do provozu obchodního oddělení České pošty a s odstupem dvou let vyhodnocen jeho přínos po ekonomické a procesní stránce.
9
Vzhledem k tomu, že klíčovým bodem praktické části práce je procesní analýza a optimalizace, bude se teoretická část práce zabývat přímo tímto tématem. Tato často podceňovaná disciplína bude představena, společně s jejími možnými pozitivními a negativními přínosy. Dále budou charakterizovány náležitosti procesní analýzy a způsob jejího naplnění, který bude použit v praktické části.
10
2 Procesní analýza Procesní analýza je disciplína, která se zaměřuje na detailní zkoumání podnikových procesů a zkoumá jejich efektivitu. Tato disciplína v sobě zahrnuje „soubor činností, které se týkají plánování a sledování výkonnosti zejména realizačních firemních procesů. Velmi často využívá znalostí, zkušeností, dovedností, nástrojů, technik a systémů k definování, vizualizaci, měření, kontrole, informování a zlepšování procesů, aby mohly být úspěšně a důkladně splněny požadavky zákazníků za současné optimální rentability svých aktivit“.1 Účelem procesní analýzy je v prvé řadě detailní znalost sledovaného procesu. Jen díky takové znalosti je možné do procesů přinášet změny pomocí procesního modelování, které by vedly k jejich zefektivnění. Procesní analýzu lze aplikovat v různém měřítku, pomocí stejných metod lze často zkoumat procesy celého podniku, konkrétního oddělení, jednoho pracovníka, nebo i konkrétní činnosti, kterou jeden pracovník vykonává. V praktické části se bude práce věnovat právě analýze jedné konkrétní činnosti, kterou vykonávají pracovníci České pošty na jedné typové pozici.
2.1 Výhody procesní analýzy Předchozí kapitola se zmiňuje o cíli procesní analýzy, kterým je vedení k zefektivnění procesu. Zefektivnění procesu může být poměrně obecným cílem, který lze rozvést na množství konkrétnějších cílů a výhod procesní analýzy. Díky správnému provádění procesní analýzy podnikových procesů lze docílit: -
„Uložení know-how v procesu
-
Možnost optimalizace
-
Definování odpovědnosti za proces
-
Zprůhlednění organizace
-
Podpory informačních technologií
-
Získání certifikátu ISO“2 Uložení know-how v procesu je velmi významným přínosem. Téměř každá
začínající firma je rozhodnuta o tom, že její procesy nebudou nijak komplikované ani neohrabané. Tato vize většinou přetrvá až do okamžiku rozběhnutí její podnikatelské činnosti. V průběhu praxe se procesech objeví potřeba řešit i nestandardní postupy, nebo se procesy samy ukážou být daleko komplikovanějšími, než se na první pohled mohlo jevit. 1
ITIL: Procesní řízení. [online]. [cit. 2013-03-14]. Dostupné z: http://www.itil.cz/index.php?id=914 Procesní řízení. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001[cit. 2013-04-15]. Dostupné z: http://cs.wikipedia.org/wiki/Procesn%C3%AD_%C5%99%C3%ADzen%C3%AD 2
11
Vykonavatelé procesu pak znají způsob jak dosáhnout svého cíle, ačkoli se jejich postup nemusí na první pohled jevit neznalé osobě zcela logický. Komplikace přichází v okamžiku, kdy je do procesu zasvěcován nový zaměstnanec, který musí pojmout velké množství informací o mechanických krocích, které nejsou zachyceny v žádné z dokumentací. Z důvodu absence procesní analýzy nelze proces nastudovat bez pomoci jiného pracovníka, který již zná způsob, jak proces vykonat správně. V praxi se pak zaměstnanec často učí mechanické kroky, aniž by znal jejich význam. Jednou z výhodou udržení procesního know-how v dokumentacích je přesné zmapování procesu a i nový zaměstnanec, který se stane vykonavatelem procesu má možnost si ho detailně prostudovat a vykonat jej správně. Zachycení know-how představuje přínos i v případě, kdy dochází k přestavbě procesu. Designéři procesu jsou pak schopni navrhnout proces tak, aby splňoval veškeré své cíle a přitom plnil všechny současné náležitosti. Přestavba nezmapovaného procesu je proto rizikem, ačkoli se může někdy jevit na první pohled efektivně (například přechod z tabulkových editorů na informační systém). Pokud nový proces zapomene obsáhnout některou z jeho původních náležitostí, může se velmi snadno stát zbytečně náročnějším a komplikovanějším, než tomu bylo v původním stavu. Příkladem pro držení know-how mimo procesní analýzu je právě Česká pošta, jejímž procesem se bude práce zabývat v praktické části. V České poště neexistuje oddělení, které by se zaměřovalo na procesní mapování administrativních prací, nebo vyhodnocování jejich efektivity. V případě obchodních činností, jsou procesní cíle kladeny metodikou obchodu, která ovšem nezmiňuje způsob jejich dosažení. Procesy jsou tak proto často komplikované a obsahují řadu nelogických mezikroků, které nejsou zachyceny v žádné jiné dokumentaci a jediní, kdo si je vědom, že mezikrok je nezbytný, je zaměstnance vykonávající proces. Optimalizace procesu se zaměřuje na změnu způsobu vykonání procesu a tím snížení jeho náročnosti po stránce času nebo postupu vykonání. Optimalizace spočívá v definování slabého místa procesu, provedení měření procesu, vytvoření návrhu na jeho zlepšení, implementaci zlepšení a opětovného měření. Optimalizace se může povědět opětovně i na nově implementované řešení, aby se postupně dosahovalo větší efektivity. Nelze ji ovšem efektivně zvládnout, aniž by byla zpracována procesní analýza, neboť by proces mohl velmi snadno ztratit svůj původní účel. Definování odpovědnosti za proces přináší tu výhodu, že existuje kompetentní osoba, případně osoby, které zodpovídají za efektivní a úplné nastavení procesu. Zaměřují se na průběžné měření efektivnosti procesu, sledování jeho funkčnosti a jeho následné 12
vyhodnocování. V případě přemodelování procesu jsou i kompetentními osobami, hájící procesní cíle a náležitosti. Pokud
je
vypracována
procesní
analýza
podnikových
činností,
dochází
k výraznému zprůhlednění všech aktivit zaměstnanců, včetně jejich provázanosti a návaznosti. Na základě přesné znalosti všech aktivit, které zaměstnanci vykonávají lze efektivně řídit množství potřebných zaměstnanců, jejich obsah práce a v další řadě i jejich mzdové ohodnocení. Významným nedostatkem České pošty v této oblasti je velké množství zaměstnanců na různých typových pozicích a absence procesní analýzy jejich činností. Jak již bylo zmíněno, Česká pošta čítá přibližně šest tisíc administrativních pracovníků. Jejich plat je stanoven tabulkově a nikoli na základě agendy, kterou opravdu spravují. Procesní analýza je předpokladem pro podpoření procesu informačními technologiemi. Ty mají význam, protože dokážou řídit své uživatele a vést je ke správnému a bezchybnému naplnění procesu. Informační technologie mimo jiné přinášejí výhodu v možnosti automatizovat aktivit, což může představovat často nezanedbatelné časové a finanční úspory. V praktické části se bude práce v rámci analýzy věnovat aktuálnímu stavu podpory procesu informačními technologiemi a následně bude tuto podporu zefektivňovat. Další z výhod procesní analýzy může být snaha podniku o získání certifikátu ISO, jehož předpokladem je mít definované a zmapované podnikové procesy.
13
2.2 Rizika procesní analýzy Ačkoli přináší procesní analýza řadu výhod, může představovat i množství rizik a komplikací. Nejčastěji se při vykonávání procesní analýzy setkáme s problémy: -
„Náročností přechodu na nový způsob řešení procesu
-
Neochotou pracovníků vykonávat proces jinak“3 Navržení nového způsobu řešení procesu může představovat velkou náročnost jak
po finanční stránce, tak po realizační. Téměř každá procesní změna si vyžádá zdroje financování, aby mohla být uvedena do provozu. Finanční náklady zde představují už samotní analytici a designéři procesu, kteří mají nový proces navrhnout. Dalšími náklady jsou změny, které má proces pojmout. V případě podpory procesu pomocí informačních technologií se může jednat o investice ve stovkách tisíc až desítkách milionů korun, kterou si nemůže dovolit každá firma. Krom finanční náročnosti, mohou být překážkou již zaběhlé způsoby řešení procesů. Změna jednoho procesu, který je navázaný na další, by tak mohla znamenat, že by bylo nezbytné změnit více procesů najednou. To nemusí být vždy zcela žádoucí a může být výhodnější od takové radikální změny radši upustit, protože by se jejich přidaná hodnota mihla účinkem. V praxi se často setkáváme i s neochotou pracovníků vykonávat proces jiným způsobem, než tomu bylo doposud. Pro ně to znamená, že se musí učit nový postup, který bývá často předčasně podceňován. Pokud ovšem přichází procesní změna, mají zaměstnanci tendenci předpokládat, že může dojít k časovým úsporám, které budou mít za následek personální změny. Z toho důvodu jsou nejčastěji zaměstnanci odmítány a zavrhovány nové inovace, které přináší efektivnější zpracování procesu.
3
Procesní řízení. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2013-04-15]. Dostupné z: http://cs.wikipedia.org/wiki/Procesn%C3%AD_%C5%99%C3%ADzen%C3%AD
14
2.3 Charakteristika procesu Práce se bude v praktické části zaměřovat na optimalizaci procesu vzniku a správy smluv v prostředí obchodní divize České pošty. Aby toho mohlo být efektivně docíleno, je třeba provést analýzu procesu, která si klade za cíl identifikovat: -
„Cíl procesu
-
Měřitelné ukazatele výkonnosti
-
Vlastníka procesu
-
Zákazníka procesu
-
Vstup procesu
-
Výstup procesu
-
Regulátory řízení“4
-
Průběh procesu
-
Obtíže a nedostatky procesu Cíle specifikují konkrétní požadavky, které musí být procesem naplněny. Měřitelné ukazatele výkonnosti představují metriky, podle kterých proces sledovat
a vyhodnocovat. Metrikou efektivity procesu bývá nejčastěji čas vynaložený na provedení procesu, může to být ovšem i množství výstupů za určité časové období a podobně. Podle těchto metrik jsou hodnoceny i nově implementované postupy. Díky metrikám vzniká možnost přesného srovnání dřívějšího a modifikovaného postupu a tedy i vyhodnocení, zda byla změna přínosem. Vlastník procesu představuje osobu, nebo skupinu lidí, kteří jsou zodpovědní za dosahování cílů procesu. Vyhodnocují a řeší efektivní fungování procesu, správu a jeho případné systematické zlepšování. Zákazník procesu představuje subjekt, pro který jsou aktivity procesu určeny. Zákazníkem může být jak interní subjekt (pracovník dělá proces pro kolegu), tak externí subjekt (pracovník dělá proces pro klienta). Vstupem procesu jsou objekty, které jsou do procesu přineseny a jsou postupně pomocí jednotlivých kroků přeměňovány na výstupy procesu. Výstup procesu je transformovaný vstup. Výstupem může být například finální produkt, poskytnutá služba nebo informace. Odběratelem výstupů jsou zákazníci procesu. Regulátory řízení představují závazná pravidla, kterými se musí proces řídit a nelze je porušit. Pokud by byl proces modifikován, musí tyto regulátory zohlednit i jeho nové 4
GRASSEOVÁ, Monika, Radek DUBEC a Roman HORÁK. Procesní řízení ve veřejném sektoru: teoretická východiska a praktické příklady. Vyd. 1. Brno: Computer Press, 2008, v, 266 s. ISBN 978-80-251-1987-7.
15
řešení. Regulátory tak představují omezení návrhu změn. Příkladem mohou být normy, metodiky, platné zákony a podobné závazné zdroje. Průběh procesu je klíčovou oblastí, která zachycuje posloupnost jednotlivých naplňovaných kroků. Jsou zde využívány všechny dříve představené objekty, tedy vstupy, výstupy, regulátory a zákazníci procesu. K názornému zachycení průběhu procesu jsou často využívány procesní mapy, které graficky znázorňují postup naplnění procesu. Existuje řada metod, které se zabývají způsobem znázornění procesů v diagramech (příkladem můžou být metody SIPOC, BPMN, Diagram datových toků, Event-Driven Proces Chain a další). „Pomocí diagramu lze přehledně definovat, pomocí jakých aktivit bude proces realizován, v jakém sledu a jak budou jednotlivé aktivity koordinovány.“5 V rámci analýzy je vhodné informovat se o aktuálních obtížích a nedostatcích procesu, které jsou vnímány všemi rolemi v procesu. Tyto informace mohou být vhodným vstupem pro návrh nového řešení procesu. Vzhledem k tomu, že v procesu může figurovat více různých rolí, které představují různé pohledy na věc, je možné, že se jejich požadavky mohou navzájem vylučovat.
2.4 Modelování procesů Modelování procesů je specifickou součástí uvedené procesní analýzy. Může se jednat o návrhy zcela nových procesů, zachycení stávajících postupů, nebo redesign procesu, tzv. reengineering procesu. „Reengineering v podstatě znamená zásadní přehodnocení a radikální rekonstrukci (redesign) 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“.6 Je vhodné, aby bylo modelování vykonáváno kompetentním pracovníkem. Není ideální, aby proces modelovala osoba, která je sama vykonavatelem procesu, nebo je v něm nějak zapojena. Tyto osoby mají velmi často pouze omezený pohled na věc, protože znají aktivitu ze svého úhlu pohledu a velmi obtížně se na něj dokážou podívat z celkové perspektivy. Postup modelování lze shrnout do následujících čtyř kroků: 1. „Sběr dat 2. Uspořádání procesní mapy 5
Event-driven Process Chain. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2013-04-15]. Dostupné z: http://cs.wikipedia.org/wiki/Event-driven_Process_Chain 6 HAMMER, M., CHAMPY, J. Reengineering - radikální proměna firmy: manifest revoluce v podnikání. 3. vyd. Praha : Management Press, 2000. s. 38.
16
3. Zdokumentování mapy 4. Zpětná interakce“7 Sběr dat probíhá nejčastěji formou konzultací s lidmi, kteří proces vykonávají nebo v něm figurují. Je vhodné, aby analytik vedl rozhovor a zkoumal veškeré detaily, které mu jsou sděleny. Vykonavatelé procesu mohou totiž velmi snadno přikládat pozornost věcem, které nejsou procesně podstatné a naopak podceňovat kroky, mající na proces velký dopad. Sběr informací může být dále prováděn pozorováním a čerpáním z dalších zdrojů jako pracovních metodik, směrnic a norem. Dalším krokem modelování procesu je příprava procesní mapy, která má vizuálně znázornit posloupnost jednotlivých aktivit a všech objektů, které se v procesu budou vyskytovat. Tato aktivita obvykle probíhá v několika iteracích, kdy je postupně připomínkována dalšími znalci procesu a dopracována do finální podoby. Vytvořený diagram je následně nezbytné detailně popsat, aby byl jasný obsah každého kroku, používaný slovník pojmů a význam veškerých objektů. Vzniká tak kompletní dokumentace celého procesu. Výsledek procesní analýzy je vhodné komunikovat zpět se znalci procesu a zadavateli, aby mohlo dojít k finálnímu k odsouhlasení modelu.
7
PEKÁRKOVÁ. Techniky modelování a optimalizace podnikových procesů. Brno, 2007. Diplomová práce. Univerzita. Vedoucí práce RNDr. Jaroslav Ráček, Ph.D.
17
3 Analýza a implementace procesního zlepšení V rámci praktické procesní analýzy se práce bude věnovat oblasti obchodu České pošty, kde se zaměří na proces vzniku a správy smluv. Tento proces bude analyzován a následně bude navrženo jeho nové řešení, které si klade za cíl optimalizovat a automatizovat proces. Navržené řešení bude implementováno a následně vyhodnoceno. Úvodem praktické části bude charakterizováno obchodní prostředí České pošty, představena jeho struktura a hlavní procesy, které se zde odehrávají, aby modifikovaný proces zapadl do kontextu činností obchodního oddělení. Následná analýza procesu vzniku a správy smluv musí pojmout všechny figurující role v procesu, objekty, samotnou posloupnost procesu a relevantní metriky pro měření procesu, aby mohlo být efektivně navrženo nové řešení procesu pomocí informačního systému. Část implementace se bude věnovat spuštění nového informačního systému a následkům změny procesu. Výsledek samotné implementace bude následně vyhodnocen po stránce zefektivnění procesu a získaných finančních úspor. Toto hodnocení bude vytvořeno s časovým odstupem dvou let.
3.1 Charakteristika obchodního prostředí České pošty Česká pošta je provozovatelem poštovních služeb na území České republiky, kterému až do začátku roku 2013 náležel listovní monopol. Podnik je charakteristický tím, že je největším zaměstnavatelem v republice s počtem přibližně „třicet tři tisíc zaměstnanců a hustou sítí svých poboček po celém území republiky, jejichž počet se pohybuje okolo tří tisíc“8. Provozováním poštovních služeb Česká pošta konstantně dosahuje ročních výnosů v řádu 21 až 24 miliard Kč, přičemž zisku 2 až 3 miliardy Kč. Nejvýznamnější podíl na výnosech tvoří smluvní zákazníci pošty, kteří představují 70% veškerých výnosů. Z tohoto důvodu je jednou z klíčových oblastí podniku obchodní oddělení, které má za úkol pečovat o stávající smluvní klientelu a zároveň provádět akvizice nových klientů. Tuto obchodní činnost provádí obchodní oddělení, které jsou zastoupeny v osmi regionech republiky, fungující jako samostatné jednotky obchodu. Regionální obchodní oddělení jsou zastřešeny jedním vedením, které nad nimi vykonávají dozor, nastavují jejich výnosové plány, přidělují úkoly a metodicky je řídí.
8
Česká pošta, s.p. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2013-04-15]. Dostupné z: http://cs.wikipedia.org/wiki/%C4%8Cesk%C3%A1_po%C5%A1ta
18
Každé oddělení obchodního regionu funguje na stejném mechanismu, respektive je obsazeno stejnými typovými pozicemi, vykonávající stejné činnosti a stejným způsobem. Tato jednotnost přináší výraznou výhodu v tom, že nově modifikovaný proces lze bez komplikací implementovat ve všech obchodních regionech stejným způsobem, aniž by došlo narušení jiných činností. 3.1.1 Struktura obchodního regionu V regionálním obchodu figurují pozice: -
Ředitel obchodního regionu
-
Obchodní manažer – vedoucí týmu
-
Obchodní manažer
-
Referent obchodu – vedoucí týmu
-
Referent obchodu Ředitel obchodního regionu je na vrcholu struktury obchodního oddělení regionu,
zodpovídá za veškeré činnosti plněné v rámci regionu a jsou mu přímo i nepřímo podřízeni všichni ostatní členové obchodního oddělení daného regionu. Obchodní manažer je front office9 obchodu. Každý jednotlivý obchodní manažer má přidělené určité portfolio klientů, o které pečuje s cílem udržení spokojenosti zákazníků. To ruku v ruce nese i udržení výnosů, které opečovávání klienti představují. Na jednoho obchodníka připadá přibližně pět set až sedm set firem, za jejichž plnění obchodní manažer odpovídá a je podle něj i hodnocen variabilní složkou mzdy. Neméně podstatnou částí práce obchodního manažera je vyhledávání nových potenciálních klientů a snaha o jejich získání. Referent obchodu zastává funkci back office10. Každý obchodní referent spolupracuje s jedním až třemi obchodními manažery, pro které připravuje podklady a řeší administrativu jim přidělených klientů. Nejvýznamnější činností této pozice je příprava smluvních vztahů, která krom samotného vzniku smlouvy obnáší i zavedení nového klienta do stávajících systémů České pošty, aby klientovi mohly být poskytovány smluvní produkty v domluvených parametrech. Referent obchodu tedy rovněž zajišťuje, aby klientům jeho obchodních manažerů byly interně zpřístupněny smluvní produkty s dohodnutými parametry. Referent obchodu rovněž provádí akviziční činnost, a to telefonickým obvoláváním méně významných klientů (resp. klientů, představující malé
9
Front office = pracovníci, kteří přicházejí do přímého styku s klienty Back office = pracovníci zabezpečující administrativu pro front office. Česky také „Zázemí“
10
19
výnosy v řádu desítek tisíc korun), kterým nabízí využití nových produktů, případně nabízí jejich zvýhodnění. Obchodní manažer – vedoucí týmu je nadřízeným skupiny obchodních manažerů. Důvodem existence této pozice je efektivnější strukturované řízení. Krom činností klasického obchodního manažera vykonává i dohled nad podřízenými obchodními manažery, vypomáhá jim s významnými obchodními případy, sleduje jejich činnost a hodnotí je. Referent obchodu – vedoucí týmu je nadřízeným všech obchodních referentů daného regionu. Krom klasické náplně práce referenta obchodu má za úkol i dohlížet nad kvalitou výstupu práce jeho podřízených. Dále připravuje administrativní výkazy za region pro vedení obchodu (např. report všech vytvořených smluv, přidělených speciálních cen apod.). Obrázek 1 - Organizační struktura regionu Obchodní ředitel regionu
Obchodník vedoucí týmu
Obchodník1
Referent Vedoucí týmu
Obchodníki
Referenti 1
Zdroj: Vlastní zpracování
20
Referenti
Obchodní oddělení regionu čítají celkem 195 pracovníku, z čehož nejvýznamnější část tvoří obchodní manažeři, kteří jsou zastoupeni v počtu 106 lidí. Druhou největší skupinou jsou obchodní referenti, jejichž počet je 54 zaměstnanců. Rozložení typových pozic po regionech je obsaženo v níže přiložené tabulce. Tabulka 1 - Přehled obsazení definovaných typových pozic Obchodní region
Obchodní manažer
Referent obchodu
Praha Střední Čechy Severní Čechy Východní Čechy Jižní Čechy Západní Čechy Jižní Morava Severní Morava Celkem * VT = Vedoucí týmu
17 15 16 15 11 9 13 10 106
9 7 7 7 6 5 8 5 54
Obchodní Referent Obchodní manažer - VT* obchodu - VT* ředitel 3 2 2 2 2 2 3 3 19
Zdroj: Vlastní zpracování
21
1 1 1 1 1 1 1 1 8
1 1 1 1 1 1 1 1 8
3.1.2 Procesy obchodního oddělení regionu Regionální obchodní oddělení České pošty má za cíl pečovat o stávající smluvní klientelu a získávat nové klienty v dané lokalitě. V této návaznosti má každý region stanoven roční výnosový plán, na který jsou navázány motivační složky platů všech zaměstnanců daného regionálního obchodu. Pro splnění činností regionu se odehrávají nejvýznamnější aktivity: -
Vyhledávání obchodního potenciálu
-
Příprava a realizace schůzek
-
Správa obchodních příležitostí
-
Vznik a správa smluv
3.1.2.1 Vyhledávání obchodního potenciálu Tuto aktivitu zabezpečují obchodní manažeři a jejím cílem je nalezení nového potenciálního klienta, který doposud nevyužívá produktů České pošty. Potenciálem je i stávající klient, který již nějaké služby využívá, ale mohl uplatnit i další služby České pošty. Tato aktivita probíhá zcela nekoordinovaně a bez předepsaného postupu. Je tedy zcela na obchodním manažerovi, jak a kde bude nový potenciál hledat. Často dochází k oslovení přímo klientem, který má zájem využívat poštovní služby. V opačných případech je nejpoužívanějším postupem vyhledávání firem na internetu, případně nově vzniklých ekonomických subjektů v dané lokalitě. Nejvíce oslovovanou kategorií subjektů jsou e-shopy, pro které je poskytování poštovních služeb téměř nezbytnou službou. Ovšem mnohdy je vyhledávání potenciálu provozováno i stylem, kdy obchodní manažer prochází náhodně vybranou ulicí a oslovuje každý ekonomický subjekt, který zde sídlí. Poté co obchodní manažer identifikuje potenciálního klienta, který má zájem o využívání služeb České Pošty, následuje příprava a realizace schůzky. 3.1.2.2 Příprava a realizace schůzky V rámci přípravy se obchodní manažer snaží získat o potenciálním klientovi co nejvíce informací, aby mu mohl nabídnout odpovídající služby. Zdroji pro tuto přípravu jsou nejčastěji internetové stránky klienta. V případě absence zdrojů nezbývá obchodníkovi než improvizovat, případně udělat první schůzku s cílem sběru informací, kde klienta pouze obecně informuje o vlastnostech nabízených produktů a při druhé schůzce již předkládá odpovídající nabídku.
22
V rámci realizace schůzek rozlišuje obchod České pošty dva typy schůzek: -
Akviziční návštěva, jejímž cílem je uzavření obchodu na nový produkt, což zahrnuje identifikaci potřeb, sběr informací, následnou přípravu nabídky a smlouvy.
-
Pečovatelská návštěva slouží k upevnění obchodních vazeb u klienta, který již má podepsanou smlouvu na využívání služeb České pošty. Platná obchodní metodika stanovuje, aby každý obchodní manažer v průběhu
jednoho pracovního týdne provedl minimálně deset pečovatelských návštěv a šest akvizičních. Každá naplánovaná a realizovaná schůzka musí být zároveň evidována s veškerými detaily o průběhu a výsledku schůzky. Mnohdy bývají obchodní situace jednoduché natolik, že klient příliš neváhá s uzavřením smlouvy a přechází se z realizované schůzky rovnou k uzavření smlouvy. V případě uzavírání významnějších kontraktů, kde se bude vyskytovat nadstandardní využití poštovních služeb, nebo bude smlouva představovat enormní výnosy, může být klientovi sjednána speciální cena, případně zajištěna individualizace poštovních služeb. V těchto případech dochází k administrativně komplikovanějším obchodním událostem, které jsou sledovány jako obchodní příležitosti. 3.1.2.3 Správa obchodních příležitostí Obchodní příležitostí se rozumí obchodní událost s delším, nebo komplikovanějším průběhem. Ideálním příkladem obchodní příležitosti může být situace, kdy se obchodní manažer účastní výběrového řízení. Součástí příležitosti může v tomto případě být několik schůzek s cílem sběru informací, žádosti vedení obchodu o schválení speciální ceny pro klienta, příprava nabídky, série schůzek a uzavření smlouvy. Všechny tyto aktivity se sledují jako obchodní příležitost a jsou pravidelně reportovány příslušným nadřízeným. 3.1.2.4 Vznik a správa smluv V okamžiku, kdy obchodní manažer nalezne klienta se zájmem o využití smluvních produktů České pošty, dochází ke vzniku smlouvy. Obchodní manažer připraví na základě potřeb klienta podklady pro svého obchodního referenta. Podklady obsahují informace o samotném klientovi a dále i specifickou konfiguraci produktu, kterou klient žádá. Obchodní referent následně připraví personifikovanou smlouvu dle obdržených parametrů. Smlouva je v dalším kroku předána k podpisu klienta a příslušného regionálního ředitele obchodu. Po oboustranném podpisu může klient začít čerpat smluvených služeb. 23
Úkolem obchodního referenta je vedle vzniku smlouvy i její zaevidování a zažádání příslušných odborů České pošty o zpřístupnění služeb pro daného klienta, aby bylo zajištěno, že klient může využívat smluvené služby v plném rozsahu. Tohoto zavedení klienta je dosahováno emailovým rozesílám interních formulářů na dané odbory, které služby zajišťují. 3.1.3 Systémová vybavenost obchodu ČP Ačkoli Česká pošta využívá celou řadu různých informačních systémů, žádný z nich se přímo nezabývá vztahy se zákazníky. Systémově tedy není pokryta obchodní činnost prakticky vůbec. Veškeré informace jsou
v obchodním oddělení České pošty
zaznamenávány pomocí nástrojů kancelářské sady MS Office. Pomocí něj jsou udržovány výnosové plány, sledovány schůzky, evidovány smlouvy a další. Ačkoli je sada MS Office relativně uživatelsky přátelská, tak v případě jejího využití na tyto aktivity jsou procesy mnohdy zbytečně nepřehledné. Uživatel se musí neustále orientovat mezi desítkami až stovkami dokumentů a tabulek. Podstatnou nevýhodou a problémem, se kterým se obchod často setkává, je offline práce s dokumenty, při které vzniká více verzí stejného dokumentu s částečně odlišným obsahem, který je následně nepříjemné sjednocovat a udržovat aktuální. Každý region disponuje sdíleným úložištěm, které je fyzicky umístěno na daném pracovišti regionálního obchodního oddělení. Toto sdílené úložiště funguje pouze v rámci daného regionu a je přístupné všem pracovním na daném pracovišti. Jeho primárním využitím je sdílení výše zmíněných dokumentů a tabulek z nástrojů MS Office. V zájmu zlepšení kvality práce vznikla v roce 2008 provizorní aplikace nesoucí název Databáze firem. Jedná se o jednoduchou formulářovou aplikaci vytvořenou za pomoci MS Access, která je určená pro sledování a vyhodnocování schůzek obchodníků s klienty. Na úkor jednoduché konstrukce aplikace je ovšem její obsluha poměrně komplikovaná. Z důvodu náročné obsluhy byla upravena metodika práce, která nově stanovila, že namísto obchodní činnosti bude obchodníky jeden celý den zpracovávána pouze administrativu vykazování schůzek. Databáze firem pracuje výhradně offline, což přináší komplikace při aktualizacích aplikace a sběru dat k jejich vyhodnocení. Obchodníci jsou tak nuceni jednou týdně manuálně odesílat zdrojové databáze aplikace nadřízenému oddělení, které je sjednocuje a vyhodnocuje.
24
Důvodem proč nejsou dělány informační pokroky pro podporu obchodu je, že se Česká pošta připravuje na implementaci systému pro řízení vztahů se zákazníky - CRM. Na tento systém bylo od roku 2009 několikrát vypsáno výběrové řízení. To ovšem bylo vždy staženo nebo pozastaveno, a to především z důvodů změn na vysokých manažerských pozicích, které přinesly i jiné představy o poptávaném systému. V listopadu 2011 ovšem bylo výběrové řízení úspěšně uzavřeno s výhercem SAP a realizace systému začala v lednu 2012 s termínem produktivního startu k červnu 2013. Následkem toho, že byl systém CRM po několik let v neustálém očekávání, bylo zakázáno jakkoli modifikovat proces evidence schůzek – taková modifikace by se jevila jako velmi krátkodobá investice, která by nemusela spatřit svou návratnost. Proto byl v roce 2010 logickou volbou ke zlepšení proces vzniku a správy smluv, který je z majoritní části prováděn s podporou počítače. Ostatní významné procesy obchodního regionu jsou vykovávány fyzicky, tudíž není možné je systémově podchytit.
25
3.2 Analýza procesu vzniku a správy smluv Vybraným procesem pro zlepšení je vznik a správa smluv. Důvodem vybrání tohoto procesu je především to, že je administrativně velmi zdlouhavý, náročný a prakticky celý je prováděn manuálně, přestože se vykonává z velké části s podporou počítače. Velkým potenciálem pro změnu je řada logických událostí v procesu, které by bylo možné automatizovat. V současném stavu jsou uživatelé nuceni manuálně opakovat řadu kroků, které přináší časovou ztrátu – opakované zadávání stejných hodnot, evidování parametrů smluv na několika místech, manuální úprava textu smluv a řada dalších. Systém by na základě vytvořených algoritmů mohl přinést výrazné časové úspory. K provedení procesu jsou v současném stavu využívány pouze nástroje sady MS Office, lze ho tedy poměrně snadno modifikovat, a to bez dopadu na jiné provozní systémy. Aby mohlo být docíleno efektivního návrhu automatizace procesu, je třeba v rámci analýzy specifikovat veškeré cíle, kterých má proces dosahovat. Další nezbytnou částí analýzy je zjištění veškerých rolí a objektů, které v procesu figurují. Podle tohoto zjištění bude zřejmé, pro koho je systém určen a jaké toky informací musí zahrnovat. Klíčovou částí analýzy je detailní postup procesu vzniku a správy smluv, ze kterého vzejdou už velmi konkrétní požadavky na práci se systémem. V rámci analýzy procesní posloupnosti vyplynou i veškeré procesní výstupy, které bude muset navrhovaný systém poskytovat. Analýza se zaměří i na obtíže a nedostatky současného stavu, aby se jim pokusil nově navrhovaný systém vyhnout, případně je eliminovat. Závěrem analýzy budou navrženy metriky procesu, podle kterých bude následně hodnocena efektivita změny procesu. 3.2.1 Cíle procesu Cílem procesu je připravit (případně modifikovat) smlouvu na příslušný produkt České pošty pro zákazníka dle požadavků, které vydefinoval a které daný produkt umožňuje. Proces musí zajistit interní aktivaci smluvených služeb, aby je mohl klient odebírat od příslušných úseků České pošty. Je tedy nezbytné poskytnout informaci o sjednaných provozních parametrech dalším odborům pošty, pro nastavení klienta do provozu (například poštám, dispečinku pro nastavení případných svozů apod.), dále pak odboru účetnictví. Vzhledem k tomu, že příslušné systémy nejsou integrovány, je nutné poskytnout interní formuláře, sumarizující informace o klientovi a sjednaném produktu, případně scan smlouvy. Účelem procesu je rovněž vést evidenci veškerých smluv, uzavřených se zákazníky České pošty a tu v pravidelných intervalech reportovat vedení obchodu. 26
Proces často zahrnuje i doplňkové aktivity, které mají vypomoci klientovi s využíváním služeb, například objednání štítků klientovi na polepování zásilek. 3.2.2 Role v procesu Obchodní referent – je zpracovatelem celého procesu, který zodpovídá za přípravu smlouvy a rovněž i za provedení všech nezbytných kroků k tomu, aby byly klientovi aktivovány smluvené produkty a služby s danými parametry. Jeho úkolem je dále zaznamenávat veškeré jím vytvořené smlouvy do evidence smluv a udržovat je aktuálními. Obchodní manažer – v procesu funguje jako zadavatel vstupů pro zpracovatele procesu. Je v jeho zodpovědnosti, aby obchodnímu referentovi předal podklady se správným obsahem. Obchodní manažer může být také zákazníkem procesu, a to v případě kdy přebírá smlouvu a osobně ji předává klientovi. Klient – je zákazníkem procesu, který provedením procesu získá smlouvu a bude mu zpřístupněno využívat služby České pošty ve sjednané podobě. Regionální ředitel obchodu – je schvalovatelem procesu, který podepisuje výslednou podobu smlouvy. 3.2.3 Objekty procesu Zadání pro vytvoření smlouvy – je vytvářeno obchodním manažerem a jedná se o podklad pro obchodního referenta, podle kterého bude připravovat smlouvu. Zadání nemá stanovený formát, je předáváno nejčastěji pomocí emailové korespondence, případně ústně. Zadání specifikuje veškeré parametry smlouvy, které budou ovlivňovat znění smlouvy i to, jaké aktivace služeb mají být interně provedeny. Šablona typové smlouvy – obchod pracuje se šablonami typových smluv na jednotlivé smluvní produkty. Šablony obsahují všechny možnosti služeb, které je daný produkt schopen nabídnout. Šablona smlouvy je dostupná ve formátu MS Word a ve svém textu obsahuje poznámky pro zpracovatele smlouvy. Tyto poznámky doslova navádějí uživatele, jak má postupovat při personifikaci smlouvy (např. „Pokud je aktivní tato služba, smažte odstavec A a zanechte odstavec B“). Šablona dále obsahuje prázdná místa v textu, kam mají být dosazeny parametry klienta (adresa provozovny, bankovní spojení, kontakty a další). Šablona typové smlouvy je napojena na tabulku evidence smluv pro využití funkce hromadné korespondence, díky které můžou být přeneseny hodnoty z tabulky přímo do smlouvy (týká se to základních hodnot jako je název klienta, jména jednatele, adresa sídla klienta a dalších).
27
Obrázek 2 - Nápověda v šabloně typové smlouvy
Zdroj: Vlastní zpracování
Personifikovaná smlouva – upravená šablona typové smlouvy, která odpovídá svojí konfigurací a zněním zadání obchodního manažera. Tištěná smlouva – Personifikovaná smlouva, která byla vytištěna ve stanoveném množství kopií (nejčastěji se vytváří dvě kopie, výjimečně čtyři, v závislosti na druhu produktu). Je určena k podepsání smluvními stranami. V průběhu procesu je vstupem i výstupem. Závěrem je ovšem tištěná smlouva podepsána oběma smluvními stranami výstupem procesu. Scan smlouvy – jedná se o scan tištěné smlouvy v okamžiku, kdy je podepsány oběma smluvními stranami. Evidence smluv – je tabulka MS Excel, kde jsou evidovány veškeré vytvořené smlouvy v daném regionu. Do této jednotné struktury jsou zaznamenávané smlouvy na veškeré smluvní produkty. Protože téměř každý produkt má odlišné vlastnosti, nese toto řešení za následek nepříjemnou rozsáhlost tabulky, kdy je k jednomu záznamu smlouvy možné vyplnit až 218 parametrů. Uživatel tedy musí mít znalost toho, jaké parametry se k jakému smluvnímu produktu a vyplnit pouze je, jinak by vznikly nerelevantní údaje. Tato tabulka je uložena na sdíleném disku a je možné ji editovat více uživateli najednou. Evidence čísel smluv – každá vytvářená smlouva je opatřena unikátním identifikátorem – číslem smlouvy. Jeho podoba je čtrnácti místné číslo identifikující odbor uzavírající smlouvu, pořadové číslo uzavírané smlouvy daným odborem a rok, kdy je smlouva uzavírána. Evidence čísel smluv je tabulka ve formátu MS Excel, která eviduje všechny použitá čísla v daném regionu. Důvodem proč nejsou čísla smluv evidována rovnou v rámci evidence smluv je, že vznikají jménem obchodního regionu smlouvy, které sám nevytváří. Proto by využitá čísla smluv nemusela korespondovat se záznamy tabulky evidence smluv. Šablony interních formulářů – jedná se o formuláře, které slouží pouze pro interní účely. Pomocí nich je klient zaváděn do příslušných systémů a jsou mu zpřístupňovány služby, které jsou v gesci jiných odborů České pošty. Těchto interních formulářů existuje 28
celkem šest, přičemž při vytvoření smlouvy nemusí být využity všechny. Množství využitých formulářů závisí na množství služeb, které má smlouva zahrnovat. Tyto formuláře existují ve formátu MS Word a jsou opět navázány na evidenci smluv, aby pomocí funkce hromadné korespondence bylo možné přenášet základní hodnoty ze zadaného záznamu (jméno klienta, adresa sídla a další). 3.2.4 Procesní mapa Následující procesní mapa představuje „schematické znázornění průběhu procesu jako sledu činností“11. Obrázek 3 - Legenda procesní mapy
Zdroj: Vlastní zpracování
11
Procesní řízení: Procesní mapa. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001[cit. 2013-04-11]. Dostupné z: http://cs.wikipedia.org/wiki/Procesn%C3%AD_%C5%99%C3%ADzen%C3%AD#Procesn.C3.AD_mapa_.2 8model.29
29
Obrázek 4 - Procesní mapa
Zdroj: Vlastní zpracování
30
3.2.5 Průběh procesu Proces probíhá téměř v jednotné posloupnosti, bez závislosti na tom zda se jedná o vznik, změnu, či výpověď smlouvy. Jedinou výjimkou je přidělení čísla smlouvy, které se vztahuje pouze k nově vytvářeným smlouvám. Pokud dochází k modifikaci či výpovědi, využité číslo se nemění ani neuvolňuje. U všech ostatních kroků procesů nezáleží na tom, zda se jedná o vznik, změnu či zánik smlouvy. Proces probíhá v následující posloupnosti: 1) Zadání - Obchodní referent získává zadání pro vytvoření smlouvy od obchodního manažera, kde jsou specifikovány veškeré požadavky na smlouvu, která má být připravena pro klienta. Vstup: Zadání pro vznik smlouvy 2) Přidělení čísla smlouvy (pouze při vzniku nové smlouvy) - Obchodní referent vytváří záznam v evidenci čísel smluv, kde k volnému číslu smlouvy připisuje, k jakému produktu bude dané číslo využito, název klienta pro kterého bude využito, aktuální datum a obchodníka, který za daného klienta nově odpovídá. Po provedení změn ukládá a zavírá tabulku. Výstup: Záznam v evidenci čísel smluv 3) Záznam v evidenci smluv - Dalším krokem je otevření tabulky evidence smluv, kam na první volný řádek zadá získané číslo smlouvy, iniciály klienta, uzavíraný smluvní produkt a dále se do příslušných sloupců vyplní konkrétní vlastnosti produktu. Po provedení změn ukládá a zavírá tabulku. Výstup: Záznam v evidenci smluv 4) Volba šablony smlouvy a stažení údajů - Dochází k otevření šablony typové smlouvy a pomocí funkce hromadné korespondence, jsou dotaženy vlastnosti klienta z evidence smluv do šablony dokumentu. Vstup: Šablona typové smlouvy, evidence smluv 5) Personifikace smlouvy – V tomto kroku dělá obchodní referent textovou úpravu typové šablony smlouvy. Prochází celý dokument a odmazává nehodící se údaje, případně doplňuje hodnoty ze zadání. Poté co je dokument parametrizován, ukládá a zavírá. Výstup: Personifikovaná smlouva
31
6) Zaslání náhledu smlouvy klientovi (volitelný krok) - Na vyžádání klienta je smlouva zaslána emailem k jeho náhledu v elektronické podobě. Po zaslání se vyčkává na reakci klienta. V případě věcných připomínek se proces vrací zpět k bodu 3 nebo 4, podle druhu chyb. Vstup: Personifikovaná smlouva 7) Tisk a parafování smlouvy - Smlouva je vytištěna ve dvou zněních, přičemž obě jsou parafovány a podepsány obchodním referentem na důkaz správnosti jejího znění. Vstup: Personifikovaná smlouva Výstup: Tištěná podoba smlouvy 8) Vytvoření interních formulářů - Obchodní referent otvírá jednotlivé šablony interních dokumentů, kde opět využívá funkce hromadné korespondence pro vložení hodnot klienta. Formuláře neobsahují žádné body, které je třeba parametrizovat. Následně formuláře ukládá, a zasílá na příslušné útvary. Vstup: Šablona interních formulářů, evidence smluv Výstup: Interní formuláře 9) Předání smlouvy klientovi - Smlouva je předána klientovi, buď korespondenčně, nebo osobně obchodním manažerem. Vstup: Tištěná podoba smlouvy Proces je okamžikem předání smlouvy klientovi pozastaven a pokračuje až poté, co Česká pošta obdrží podepsané originály smluv. 10) Podpis smlouvy za ČP - Smlouva je předána k podpisu obchodnímu řediteli regionu. Vstup: Tištěná podoba smlouvy 11) Záznam o podpisu do evidence smluv - Do evidence smluv je zaznamenáno datum, kdy došlo k podpisu (za Českou poštu) a smlouva je od tohoto okamžiku aktivní. Výstup: Záznam v evidenci smluv 12) Předání originálu smlouvy klientovi - Jeden z originálů smlouvy je korespondenčně zaslán zpět klientovi. Vstup: Tištěná podoba smlouvy 13) Scan smlouvy - Dochází ke scanu podepsané smlouvy. Vstup: Tištěná podoba smlouvy Výstup: Scan smlouvy
32
14) Zaslání scanu smlouvy – Scan smlouvy je následně v elektronické podobě zaslán účetnímu oddělení a na podací poštu, kde má klient sjednané podání. Vstup: Scan smlouvy 15) Archivace scanu smlouvy - Elektronická smlouva je uložena dle metodiky na sdíleném disku. Vstup: Scan smlouvy 16) Archivace písemné smlouvy - Fyzická podoba je uložena do šanonů v obchodním oddělení. Vstup: Tištěná podoba smlouvy 3.2.6 Výstupy procesu Provedením procesu vznikají následující výstupy: -
Záznam v evidenci smluv
-
Záznam v evidenci čísel smluv
-
Parametrizovaná smlouva pro klienta
-
Scan smlouvy
-
Tištěná podoba smlouvy
-
Interní formuláře
3.2.7 Obtíže a nedostatky procesu Proces v současném stavu identifikuje následující obtíže a nedostatky:
V procesu jsou několikrát duplicitně zadávány stejné záznamy do různých evidencí a dokumentů.
Při manuálním zadávání údajů do evidencí vznikají překlepy a různorodá pojmenování stejných parametrů (např. uživatel zadává název produktu jako „Obchodní balík“ a příště jej nazve jako „Balík obchodní“ a podobně).
Krok parametrizace smlouvy vyžaduje vysokou pozornost uživatele, je zdlouhavý a velmi často se ve finální podobě smlouvy objevují chyby způsobené nepozorností zpracovatele. Smlouva pak obsahuje odstavce, které si mohou rozporovat nebo kosmetické chyby. V takových případech je samozřejmě nutné chyby zpětně opravit. Ovšem v případě, kdy je nalezena chyba v již podepsané smlouvě, je třeba chybnou smlouvu vypovědět a celý proces zopakovat (což je procesně jednodušší než připravit dodatek smlouvy).
33
Pokud je využívána funkce hromadné korespondence pro nahrání hodnot do šablony typové smlouvy nebo jiný formulářů, je zdrojový soubor evidence smluv uzavřen a nelze ho ostatními uživateli ukládat ani otevírat.
Informace o smlouvách jsou vedeny pouze lokálně v rámci regionu. Ostatní regiony tedy nemají přehled o klientech, kteří již mají uzavřenou smlouvu s Českou poštou. To působí značný problém s klienty, kteří jsou v péči více regionů najednou, protože mají provozovny po více částech republiky (např. společnost Baťa a. s.). V těchto případech může o klienta pečovat více obchodníků z různých regionů najednou, kteří ovšem vzájemně nevědí o aktuálních verzích smluv.
Neexistence přehledu smluvních klientů, ačkoli každý samostatný záznam smlouvy v evidenci smluv obsahuje vlastnosti klienta, neexistují žádné jiné úhly pohledu na evidované smlouvy. Například není možné zjistit všechny uzavřené smlouvy daného klienta, nebo uzavřené smlouvy konkrétním obchodníkem.
3.2.8 Návrh metrik Ideálním měřítkem procesu je vynaložený čas na tvorbu jedné smlouvy. Průměrně připadá na jednoho obchodního referenta devět smluv týdně, a to nezávisle na tom, jak rychle budou zpracovány. Pokud by se podařila snížit časová náročnost na tvorbu smlouvy, bylo by možné využít získaného času k jiné činnosti. Alternativou může být případné snížení personálních nákladů na obchodní referenty. Nelze ovšem předpokládat, že by se vyprodukovalo více smluv, protože poptávka po smlouvách není odvislá od rychlosti jejich zpracování. Pro budoucí zlepšení procesu pomocí informačním systémem je třeba odlišovat kroky probíhající bez podpory počítače a musí být nevyhnutelně provedeny fyzicky.
34
Následující tabulka zachycuje průměrný vynaložený čas na každý krok v procesu. Tabulka 2 - Časové rozložení procesu Vzniku smlouvy Krok procesu 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Název kroku Získání podkladů Získání čísla smlouvy* Záznam do evidence smluv Vybrání dokumentu a přenesení údajů z ES Parametrizace smlouvy Vytištění smlouvy a parafování Vytvoření interních formulářů Zaslání náhledu smlouvy klientovi* Předání smlouvy ve finálním znění Podepsání smlouvy obchodním ředitelem Záznam podpisu do evidence smluv Zaslání originálu smluv klientovi Scan podepsané smlouvy Odeslání scanu Účetnímu oddělení a poště Archivace scanu smlouvy Archivace písemné smlouvy
Čas vynaložený na krok 3 min 15 min 5 min 20 min 8 min 10 min 2 min 2 min 4 min 6 min 5 min 2 min 2 min 3 min
Je vykonáván krok na PC? Ano Ano Ano Ano Ne Ano Ano Ne Ne Ano Ne Ne Ano Ano Ne
Suma 82 min *kroky se neprovádí vždy, proto jejich časová náročnost nebude zohledněna ve výsledku
Zdroj: Vlastní zpracování Provedení procesu vzniku smlouvy trvá celkem 82 minut, přičemž z toho se 63 minut práce odehrává na počítači pracovníka. Nejvýznamnějším zpomalením je krok parametrizace smlouvy, která je zároveň i nedostatkem procesu, kde dochází k častému pochybení lidského faktoru.
35
3.3 Návrh řešení s odhadem přínosu Z analýzy vyplývá, že prakticky celý proces vzniku a správy smluv je prováděn manuálně – téměř každý zadaný údaj je proveden uživatelem, stejně jako správná volba šablony typové smlouvy, editace dokumentu a distribuce informací. To představuje velký potenciál pro řešení informačním systémem, který by tyto kroky dokázal automatizovat pouze na základě správně zadaných vstupních informací. Tato kapitola se bude zabývat nastavením cílů, o které bude usilovat nové řešení. Dále bude navržen způsob automatizace současných manuálních úkonů. V této oblasti budou specifikovány jednotlivé oblasti, kde může být informační systém přínosem a způsob, kterým lze automatizace, případně optimalizace, docílit. Na základě odhadu nových funkcí bude možné nastavit očekávání přínosů díky novému informačnímu systému a vyhodnotit, zda se vyplatí takové řešení implementovat do provozu. 3.3.1 Cíle navrhovaného řešení Řešení musí přinést přehlednou správu smluv klientů a musí podporovat samotnou aktivitu vzniku textové podoby smluv a interních formulářů, což jsou klíčové kroky procesy. Systém musí využít efektivnějšího způsobu skladování dat oproti současnému stavu. Tak aby bylo možné provádět komplikovanější vyhledávací dotazy, díky čemuž lze docílit přehlednějšího vedení obchodních vztahů. Uživatelé by získali možnost snadného informování o vlastnostech všech historicky uzavřených smluv, aniž by k jejich získání museli trávit desítky minut hledáním v tabulkách. Systém musí podporovat práci více uživatelů najednou, aniž by docházelo k jejich vzájemnému omezování. Nástroj musí být snadno obsluhovatelný, aby se v něm orientoval i nezkušený pracovník České pošty a přesto dokázal naplno využít jeho funkcí. Systém tedy měl být nositelem know-how procesu. Měl by uživatele v každém kroku vést, sdělovat mu následky jeho akcí a v případě rizikových operací ho upozorňovat na možné konsekvence. Systém musí evidovat záznamy a poskytovat výstupy podle platné metodiky obchodu a směrnic České pošty. Konstrukce systému nesmí přesáhnout dobu vývoje sedmi měsíců.
36
3.3.2 Návrh logiky systému Nezbytnou součástí návrhu řešení je způsob nastavení jeho interních systémových procesů, které budou zachyceny jak ve zdrojovém kódu, tak zároveň budou ovlivňovat i způsob uživatelské obsluhy. V prvé řadě je nutná volba správné platformy nového řešení, tak aby nevznikly výrazné náklady (ideálně žádné) a bylo snadné provádět případné aktualizace a modifikace softwaru. Dalším krokem návrhu logiky systému bude specifikace logiky generování smluv, která je hodnocena jako nejkomplikovanější oblast vývoje. Další klíčovou oblastí bude návrh nového a efektivnějšího způsobu evidence dat. Velký důraz bude dále kladen na nastavení způsobu uživatelské obsluhy systému, tak aby bylo docíleno jeho snadné obsluhy a visuální jednoduchosti. Závěrem bude sumarizována struktura systému, která bude reflektovat všechny požadavky předcházejících návrhů řešení jednotlivých oblastí. 3.3.2.1 Platforma systému Vstupním požadavkem je, aby systém vznikl pomocí dostupných nástrojů, na které má Česká pošta již zakoupené licence. Náklady na vývoj systému nesmí přesáhnout více, než personální náklady na jednoho programátora. Zároveň je požadavkem, aby nebylo nutné nic instalovat na počítačových stanicích budoucích uživatelů, a to ani nové softwarové ovladače. Systém má z politických důvodů zůstat inkognito až do okamžiku jeho plného provozu. S těmito vstupními parametry se jako ideální prostředí pro vybudování nového nástroje jeví sada MS Office, která je základním vybavením obchodu. Nelze ovšem postavit nástroj na pouhých základních funkcích, ale je nutné programová úprava. MS Office podporuje vývojové prostředí v jazyce Visual Basic forApplications. Díky programovým úpravám je možné vytvořit funkce jako v klasické aplikaci a lze pomoci jich teoreticky docílit všech stanovených cílů. 3.3.2.2 Generování smluv Nové řešení si zde klade za cíl, aby byl text smlouvy kompletně generován pomocí softwarového algoritmu, což by přineslo výrazné časové úspory a omezilo chybovost. Každý smluvní produkt České pošty má svou specifickou omezenou konfiguraci. Lze mluvit průměrně o dvaceti parametrech, podle kterých lze určit přesné znění smlouvy i ostatních vytvářených interních formulářů. Ideální by bylo, aby pro každý smluvní produkt vznikl formulář, obsahující všechny konfigurující položky (zapracované ve formuláři jako vyplňovací textová pole, vybírací seznamy a zaškrtávací pole), kde by uživatel provedl 37
kompletní nastavení smluvního produktu. Z tohoto bodu by mohl uživatel volat funkce pro uložení záznamu, vytvoření interních formulářů, nebo vygenerování smlouvy. Díky kompletní znalosti konfigurace by mohla aplikace pro vytvoření smlouvy a ostatních dokumentů posloupně skládat textové bloky. Při vytvoření některého z dokumentů by program v prvé řadě vytvořil nový prázdný dokument. Do něj by začal postupně vypisovat znění smlouvy a v okamžiku kdy by se dostal k odstavci, který se ve smlouvě vyskytuje pouze na základě specifické konfigurace produktu, byl by na základě podmínky buď vložen, nebo vynechán. Aby mohl být realizován tento způsob generování dokumentů, musí pro každý smluvní produkt v rámci systému vzniknout samostatný produktový formulář, kde bude uživatel nastavovat danou konfiguraci produktu. Produktové formuláře mohou vzniknout v nástroji MS Excel, kde lze snadno nadefinovat strukturu formuláře a s jeho výstupy pracovat ve zdrojovém kódu. Vzhledem k tomu, že aplikace ze sady MS Office dokážou na úrovni zdrojového kódu pracovat mezi sebou, měla by být realizace touto formou bez technických komplikací. MS Excel by tak v rámci funkce postupně skládal dokument MS Word, přičemž by veškerá logika strukturování smlouvy byla uložena v produktovém formuláři MS Excel. Tento způsob zpracování smluv podporuje volbu platformy MS Office. Řešení si klade za cíl systémově pokrýt dvacet dva druhů produktových formulářů, které představuje veškeré smluvní produkty, které běžně uzavírá obchodní oddělení regionu. 3.3.2.3 Evidence dat V rámci skladování dat je třeba nahradit evidenci smluv a evidenci čísel smluv, které jsou jednak velmi objemné a hlavně neuchovávají detailní parametrizaci smluv. Ideální platformou pro úložiště informací zcela jistě není platforma MS Excel, jako je tomu v současném stavu. Při použití sady MS Office pro vznik systému se nabízí možnost využití MS Access, která je určena ke spravování databází. Produktové formuláře pro vytváření smluv budou muset sledovat více informací, než bylo doposud evidováno v rámci evidence smluv. To vede k nutnému rozšíření současné sledované struktury informací, ale na druhou stranu to přináší možnost sledovat parametry každého produktu individuálně. V současném stavu jsou v evidenci smluv v rámci jednoho záznamu sledovány všechny klíčové parametry všech smluvních produktů, ale detailní parametry jednotlivých produktů evidovány nejsou. Vytvoření 38
jednotlivých tabulek v databázi, jednu pro každý produkt, by znamenalo, že budou evidovány pouze ty informace, které se daného produktu týkají a nutně v plném rozsahu. Pokud by nebyly zaznamenány veškeré informace, ale pouze ty, které se evidují již v současném stavu, nešlo by umožnit editaci smluv v plném rozsahu. Při vyvolání hodnot zpět z databáze do produktového formuláře by chyběla řada dříve zadaných informací. Externí databáze může být rovněž zdrojem pro přidělování čísel smluv, aby tak nahradila současnou tabulku MS Excel. V databázi by tak byl veden seznam dostupných čísel smluv, které by aplikace postupně přidělovala. Vzhledem k tomu, že čísla smluv v sobě nenesou příznak o produktu, lze udělat, aby jednotlivé produktové formuláře požívaly stejnou funkci pro jejich přidělení. Při využití této funkce by k prvnímu volnému číslu v databázi byly zapsány iniciály vytvářené smlouvy a do produktového formuláře vráceno unikátní číslo smlouvy. Je nezbytné, aby k databázi měl přístup každý z uživatelů regionu. Lze proto využít místní sdílený disk, kterým disponuje každý region. Tam by byla uložena databáze, do které by produktové formuláře systému zasílaly (případně čerpaly) pouze dávky informací. Informace bohužel nebudou i nadále sdílené mezi regiony, ale vzhledem k velmi omezeným zdrojům neexistuje alternativní cesta. 3.3.2.4 Uživatelská obsluha Z návrhu řešení způsobu generování smluv vyplývá, že budou uživatelé přistupovat k jednotlivým produktovým formulářům podle toho, na jaký produkt bude vytvářena smlouva. To znamená, že musí vzniknout množství samostatných produktových formulářů. Slabou stránkou návrhu řešení je v tuto chvíli způsob uživatelské orientace mezi správnými produktovými formuláři. Zároveň je nezbytné zajistit způsob přistupování k historickým záznamům uloženým v databázi, aby bylo možné existující smlouvy vyhledat a editovat. V další řadě bude nutné vytvářet exporty všech záznamů smluv, které je nutné využít v rámci jiných procesů. Pro vyřešení těchto funkcí, které nepřímo souvisí s vytvořením samotných smluv, je vhodné vytvořit menu systému. To by navádělo uživatele přímo k jednotlivým funkcím, včetně volby produktových formulářů při vzniku nových smluv.
39
Funkce, které má Menu systému za cíl poskytnout jsou: -
Vytvoření nové smlouvy – Na základě výběru produktu otevřít uživateli správný produktový formulář.
-
Vyhledání a editace existující smlouvy – Posílat dotazy do databáze a zobrazovat z ní informace. V případě editace pak získaná data převzít a vložit je do příslušného produktového formuláře.
-
Spravovat seznam čísel smluv – Možnost zadat nevyužitá čísla smluv, které mohou být pří vytváření nových smluv přidělovány.
-
Export záznamů smluv – Funkce, která zorganizuje data z databáze všech vytvořených smluv do exportu s předepsanou strukturou podle platné metodiky ve formátu MS Excel. Pro vznik uživatelského menu bude opět volena aplikace MS Excel, díky jeho
snadné možnosti vytvoření vyhledávacích formulářů a snadné práce s jeho strukturou v rámci zdrojového kódu. 3.3.2.5 Struktura systému V návrhu již vznikla řada samostatně existujících objektů, které jsou logiky provázány. V níže uvedené tabulce je přehled objektů, které zatím z návrhu vyplynuly a typ nástroje, který bude použit pro jejich realizaci. Tabulka 3 - Objekty návrhu řešení Objekt
Typ
Produktové formuláře MS Excel Menu MS Excel Databáze MS Access Vygenerované dokumenty smlouvy MS Word Vygenerované interní formuláře MS Word Exportované výstupy MS Excel Zdroj: Vlastní zpracování Největší množství zdrojového kódu bude věnováno samotné logice generování smluv. Proto bude volena cesta, že každý produktový formulář bude obsahovat svůj vlastní zdrojový kód s logikou pro jednu smlouvu, na kterou je zaměřen. Produktové formuláře mohou mít na druhou stranu řadu funkcionalit velmi podobnou, jako například způsob zálohování produktového formuláře, přidělování čísel smluv apod. Z toho důvodu vznikne externí soubor v MS Excel, který bude obsahovat pouze univerzální funkce pro všechny produktové formuláře. Ten bude na produktové formuláře navázán, pomocí funkcí externího obsahu, takže všechny produktové formuláře 40
budou čerpat funkce přímo z něj. Z hlediska budoucí administrace je tento způsob zcela jistě perspektivní řešení. Obrázek 5 - Tok dat systému
Zdroj: Vlastní zpracování Z pohledu toku dat bude menu směrovat uživatele k produktovému formuláři, kde uživatel vyplní údaje. Ty se uloží do databáze na sdíleném disku a bude vygenerováno znění smlouvy a dalších interních formulářů ve formátu MS Word. Menu dále bude plnit funkci editace starších záznamů. Uživatel nejdříve vyhledá v menu historickou smlouvu, menu se při této akci dotáže do databáze a vrátí výsledek odpovídající zadání. V případě editace je následně otevřen odpovídající produktový formulář, do kterého menu vloží informace editovaného záznamu. Při uložení dat uživatelem v produktovém formuláři jsou pak přepsány staré hodnoty v externí databázi. Menu dále bude zajišťovat exportování záznamů smluv za určité časové období. V tomto případě uživatel musí zadat vstupní časové parametry, menu provede dotaz do databáze a všechny záznamy odpovídající zadání přenese do nově vytvořené tabulky MS Excel, která bude odpovídat obchodní metodice.
41
3.3.3 Odhad přínosu Pokud aplikace dokáže splnit všechny stanovené cíle, lze předpokládat, že budou velmi výrazně upraveny následující procesní kroky: Tabulka 4 - Modifikované kroky procecsu Krok procesu
2 3 4 5 7 8 11
Čas vynaložený na krok Název kroku
Získání čísla smlouvy Záznam do evidence smluv Vybrání dokumentu a přenesení údajů z ES Parametrizace smlouvy Vytvoření interních formulářů Zaslání náhledu smlouvy klientovi Záznam podpisu do evidence smluv
Původní
Očekávání
3 min 15 min 5 min 20 min 10 min 2 min 4 min
0 min 15 min 0 min 0 min 0 min 2 min 2 min
59
19
Suma Zdroj: Vlastní zpracování
Protože řada kroků bude podchycena přímo systémem, je cílem, aby je uživatel nemusel provádět vůbec. Tyto kroky, které budou dle návrhu plně automatizovány, představují v současnou chvíli časovou náročnost 40 minu. Pokud nepočítáme krok přidělení čísla smlouvy, které není proveden vždy, pak by měla být časová úspora 37 minut. Návrh řešení tedy předpokládá, že dojde k významné úspoře a celkový proces (včetně ostatních kroků) bude zkrácen z 82 minut na 45 minut.
42
3.4 Implementace řešení Po vytvoření a odsouhlasení návrhu začal samotný vývoj systému, který obdržel název PPECKA, dvojsmysl vytvořený zkratkou z Post Program for Editing and Creating Contracts and Agreements (kde Contracts jsou úmyslně ve zkratce psány s k). Vývoj byl realizován pouze jedním programátorem a probíhal přesně podle navržené logiky po dobu šesti měsíců. Realizace se tedy stihla s měsíčním předstihem a proběhla bez jakýchkoli technických problémů. Po dokončení vývoje systému byl spuštěn pilotní provoz systému, do kterého bylo zapojeno pouze jedeno regionální obchodní oddělení. Pilotní provoz trval jeden měsíc a v jeho průběhu byly odladěny případné nedostatky a chyby. Spuštění systému nepředcházel klasický testovací proces. Po proběhnutí pilotního provozu bylo rozhodnuto o celoplošném zavedení nového řešení do všech oddělení obchodních regionů, což s sebou přineslo nutnost řešit migraci historických dat. 3.4.1 Charakteristika systému PPECKA Systém umožňuje vytvářet nové smluvní vztahy, editovat staré a další pomocné funkce umožňující přehled a kontrolu nad evidencí smluvních vztahů. Smlouvy jsou vytvářené a editované prostřednictvím „produktových formulářů“, které se váží k produktům České pošty. Formuláře obsahují vyplňovací textová pole pro zadání unikátních informací o klientovi a dále zaškrtávací pole pro nadefinování specifičtějších vlastností produktu. Tyto informace jsou zdrojem pro naprogramované funkce, které jednotlivé formuláře zahrnují. Funkce pak provádí na základě zaškrtaných informací uvnitř formuláře zautomatizované procesy vygenerování přesné písemné smlouvy včetně veškerých příloh. Další funkce umožňují vznik i dalších nezbytných vnitropodnikových formulářů v přesném znění. Všechny záznamy o vytvořených dohodách a smlouvách jsou evidovány v externí databázi a mohou z ní být kdykoli převedeny zpět do formuláře a dál používány. Jádro aplikace bylo záměrně naprogramováno v jazyce Visual Basic for Applications na platformě MS Office, aby program byl vyhovující vnitropodnikové politice IT a implementace mohla proběhnout bez komplikací v krátkém časovém horizontu.
43
3.4.2 Pilotní provoz Po vytvoření systému neprobíhal klasický proces testování, ale pro tento účel byl spuštěn rovnou pilotní provoz. Do pilotního procesu bylo zapojeno jedno regionální obchodní oddělení. Zde byl systém zpřístupněn nejdříve dvěma obchodním referentům, kteří v rámci práce s novým systémem vyhledávali případné nedostatky, které byly okamžitě opravovány. Na pilotní provoz byla vymezena doba jednoho měsíce. V jeho průběhu byli postupně zapojeni všichni obchodní referenti a systém byl dočištěn od posledních významných chyb. 3.4.3 Implementace Na základě schválení systému ředitelem divize obchodu a marketingu byl systém po úspěšném ukončení pilotního provozu určen k implementaci do ostatních oddělení obchodních regionů. Samotný proces nainstalování nového řešení není díky zvolené platformě nijak komplikovaný. Instalace spočívá v překopírování souborů aplikace na uživatelský a sdílený disk. Aplikace následně vyzve k zadání síťové cesty ke sdílenému disku a může plnohodnotně fungovat. Na uživatelských stanicích není třeba instalovat žádné doplňky, jak bylo přáním zadavatele. Instalace na uživatelské stanice byla zabezpečena příslušnými pracovníky IT podpory na daném oddělení. Po přípravě systému následovalo školení uživatelů k vysvětlení správného používání systému. Vzhledem k tomu, že byla aplikace konstruována tak, aby byla intuitivní, školení trvalo řádově desítky minut. 3.4.4 Migrace dat Nově implementovaný systém by nebyl použitelný, pokud by do něj nebyly přeneseny veškeré již existující záznamy o smlouvách. Bylo by nepřijatelné, aby uživatelé byli nuceni vykonávat jeden proces dvěma způsoby podle toho, je-li smlouva evidována v novém systému nebo ne. Z tohoto důvodu vznikl jednoúčelový skript, který není součástí samotného systému, jehož účelem byl přenos informací ze staré evidence smluv do nové databáze systému. Vzhledem k tomu, že stará evidence smluv neobsahovala část údajů o konfiguraci smluv, bylo nezbytné smířit se s tím, že tyto hodnoty budou v novém systému prázdné. Nejedná se tedy o ztrátovost dat, ale nepřenesení z důvodu jejich historické absence.
44
3.4.5 Důsledek změny procesu Aby se předešlo nepříznivým reakcím budoucích uživatelů, byla jednoduchost a použitelnost systému prezentována a demonstrována postupně všem příslušným autoritám, které by implementaci mohly ovlivnit. Postupně byl systém představen obchodním ředitelům regionů, vedení obchodu České pošty a ve finále i top managementu společnosti. V rámci prezentace byl představen původní průběh procesu a jeho rozdílná verze s podporou systému, která byla názorně demonstrována. Tato demonstrace systému se vždy setkala s pozitivním ohlasem. Poté co systém běžel prvních pár měsíců a nebyla provedena žádná personální změna, byly rozptýleny i obavy obchodních referentů, že by mohlo dojít ke snižování jejich stavů. Jejich nově získaný čas byl využit k tomu, aby sami vyhledávali nové potenciální klienty, kontaktovali je a případně s nimi rovnou sjednávali schůzky s obchodními manažery. Vedle toho se začali i více věnovat sledování platební morálky stávajících klientů. V důsledku úpravy obsahu práce obchodních referentů, se systém z jejich strany začal setkávat s pozitivními ohlasy a začaly vznikat často velmi přínosné návrhy na detailní modifikace systému.
45
3.5 Hodnocení implementace a řešení Implementované řešení bude hodnoceno po dvou stránkách. Lze hodnotit, jak moc efektivním způsobem byl proces pozměněn a jaké usnadnění přináší uživatelům oproti původnímu stavu. Výsledek lze podložit novým měřením kroků procesu a porovnáním s jeho původní délkou. V druhé řadě lze vyhodnotit výsledek implementace v ušetřených financích, kde bude klíčovým ukazatelem opět čas vynaložený na krok procesu předtím a potom, ovšem v kontextu s průměrnou mzdou vykonavatele procesu. Finanční hodnocení bude provedeno s odstupem dvou let od okamžiku plošné implementace systému. 3.5.1 Přínos v procesu Systém umožňuje uživatelům pohybovat se v uživatelském rozhraní, kde vždy ví, jaké funkce mají k dispozici a s čím mohou pracovat. V tomto rozhraní mají možnost vytvářet nové smluvní vztahy, editovat staré a další pomocné funkce umožňující elegantní přehled a kontrolu nad evidencí smluvních vztahů. Funkce pak provádí zautomatizované procesy, odpovídající platným postupům obchodního oddělení. Systém zcela automatizoval kroky přidělování čísel smluv z externí databáze (dříve byly čísla smluv evidovaná a editovaná pouze v tabulce souboru Microsoft Excel), stejně jako ukládání dat do nové evidence smluv, generování textové podoby smlouvy a dalších interních formulářů. Krok zadávání parametrů smlouvy byl také razantně ovlivněn, protože v rámci produktových formulářů je velmi elegantní přehled nad tím, jakou konfiguraci produkt umožňuje a je pohodlnější takové parametry zadat, oproti starému stavu. Veškeré informace jsou zadávány pouze jednou a následně efektivně využity pro všechny potřebné následné kroky.
46
V níže přiložené tabulce jsou zachyceny jednotlivé procesní kroky a jejich časová náročnost při původním a novém způsobu provedení. Kroky, které řeší nově implementovaný systém, jsou v tabulce podbarveny zeleně. Tabulka 5 - Metriky v novém procesu Krok procesu
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Čas vynaložený na krok
Název kroku
Získání podkladů Získání čísla smlouvy* Záznam do evidence smluv Vybrání dokumentu a přenesení údajů z ES Parametrizace smlouvy Vytištění smlouvy a parafování Vytvoření interních formulářů Zaslání náhledu smlouvy klientovi* Předání smlouvy ve finálním znění Podepsání smlouvy obchodním ředitelem Záznam podpisu do evidence smluv Zaslání originálu smluv klientovi Scan podepsané smlouvy Odeslání scanu Účetnímu oddělení a poště Archivace scanu smlouvy Archivace písemné smlouvy
Suma
Předtím 3 min 15 min 5 min 20 min 8 min 10 min 2 min 2 min 4 min 6 min 5 min 2 min 2 min 3 min
Nyní 0 min 8 min 0 min 0 min 8 min 0 min 2 min 2 min 2 min 6 min 5 min 2 min 2 min 3 min
82 min
38 min
Je vykonáván krok na PC? Ano Ano Ano Ano Ne Ano Ano Ne Ne Ano Ne Ne Ano Ano Ne
*kroky nejsou prováděny vždy, proto nebudou zohledněny ve výpočtu hodnocení Zdroj: Vlastní zpracování Celková doba zpracování smlouvy byla díky implementace zkrácena z 82 minut na 38 minut (včetně kroků probíhajících bez podpory počítače a systému), což představuje zefektivnění o 53,6%. Při hodnocení pouze těch kroků, které probíhají na počítači pracovníka, byla časová náročnost v původním stavu 58 minut. Při zpracováním v novém informačním systému je stejné množství práce vykonáno pouze za 14 minut. To přináší 44 minut ušetřeného času na jednu vytvořenou smlouvu, což předčilo původní očekávání, které odhadovalo výsledný čas na vytvoření jedné smlouvy o 7 minut delší. Po procesní stránce je přínos systému nezpochybnitelný, vzhledem k tomu, že přináší tak radikální časové úspory. Vedle těchto úspor je dále zajištěna menší chybovost ve znění smluv, protože jsou nově generovány softwarovým algoritmem, kde nehrozí pochybení nebo nepozornost jako u lidského vykonavatele.
47
3.5.2 Finanční hodnocení Díky výraznému zefektivnění činností, které systém řeší, mají nyní obchodní referenti více prostoru pro vykonávání ostatních činností dle platné metodiky a jiných činností dle operativních potřeb obchodního oddělení regionu. Přidanou hodnotu systému tedy lze vyjádřit v hodnotě ušetřeného času, který by za normálních okolností bylo nutné investovat do nyní zautomatizovaných činností, které systém řeší. Standardní doba pro kompletní vytvoření jedné dohody nebo smlouvy dle starých postupů je v průměru 82 minut. Díky zautomatizovaným a usnadňujícím procesům, které aplikace poskytuje, nyní taková činnost trvá 38 minut. Vyjádřeno mzdovými náklady zaměstnavatele, činí tarifní mzda 257,- Kč na hodinu práce obchodního referenta. Náklady na 44 minut, které jsou nyní ušetřeny, představují úsporu 188,5 Kč na vytvoření jedné smlouvy. S odstupem dvou let bylo v systému PPECKA vytvořeno 58 912 smluv (nejsou zahrnuty migrované smlouvy). Takové množství by bez podpory systému představovalo 80 513 hodin práce. Díky výrazně automatizovaným krokům, bylo na tuto práci vynaloženo pouze 37 311 hodin. Rozdíl ušetřeného času odpovídá úspoře ve výši 11 102 948,- Kč. Po této stránce implementace systému předčila veškeré očekávání zadavatele a její přínos je nezpochybnitelný.
48
4 Závěr Úspěšně implementovaný systém na podporu procesu vzniku a správy smluv funguje na České poště doposud a má být nahrazen až nově vytvářeným systémem pro vedení vztahů se zákazníky s termínem implementace k červnu 2013. Ačkoli systém PPECKA přinesl výrazné časové úspory, nebylo to důvodem k personálním změnám v obchodní divizi. Získaný čas obchodních referentů byl využit, pro vyhledávání nového obchodního potenciálu. Lze tvrdit, že v průběhu projektu bylo dosaženo všech stanovených cílů. Efektivně implementovaný systém implikuje, že návrh řešení odpovídal skutečným potřebám České pošty a zároveň eliminoval slabá místa procesu. To, že byl návrh efektivním, je důkazem, že byla správně zachycena i procesní analýza administrace smluv. Díky provozu implementovaného systému PPECKA vznikly po dvou letech používání časové úspory v hodnotě 43 202 hodin práce. Oceněno mzdovým tarifem obchodního referenta, který proces vykonává, lze úsporu času vyjádřit jako ušetření 11 102 948,- Kč, což je částka, která vynikne i v tak vysokém obratu, jaký má právě Česká pošta. Vzhledem k vzniklým úsporám, nelze realizaci projektu hodnotit jinak, než velmi pozitivně. Nikdo ze zadavatelů neočekával, že informační systém by mohl přinést tak rozsáhlé finanční a časové úspory. Ačkoli systém vznikl na velmi jednoduché platformě, která by na konkurenčním trhu jen sotva obstála, byl naprosto splněn cíl, který si projekt kladl. Zvláště při zohlednění nákladů na projekt, kterými byl pouze jeden pracovník, selektovaný na vytvoření systému, lze náklady hodnotit jako zcela zanedbatelné a investice se vrátila během prvních týdnů používání systému.
49
5 Conclusion Successfully implemented system to support the process of contract management works on Czech post so far and will be replaced by a newly established system for customer relationship management with the implementation deadline of June 2013. Although the system PPECKA brought significant time savings, it was not a reason to personnel changes in the business division. The resulting time business agent has been used to search for new business potential. It can be argued, that the project achieved at all its objectives. Effectively implemented system implies that the draft of solution is corresponding to the real needs of Czech post and at the same time it is eliminating the weak points of the process. The fact, that the draft was effective is proof, that it was properly captured process of contract administration. Thanks to the implemented system PPECKA arose after two years of use, time savings of 43 202 hours work. Priced by wage tariff business agent, who performs the process, saving time can be expressed as saving of 11 102 948,- CZK, which is the amount that will stand out in such a high turnover, which has Czech Post. Due to the resulting savings, the project cannot be evaluated differently than very positive. None of the authorities expected that an information system could generate as large financial and time savings. Although the system was a very simple platform that would in a competitive market just barely survived, project completely fulfilled his aim. Especially taking into account the cost of the project, which was only one person selected for creation of system, the cost can be assessed as negligible and the investment was returned during the first weeks of using the system.
50
6 Seznam použitých zdrojů ITIL: Procesní řízení. [online]. [cit. 2013-03-14]. Dostupné z: http://www.itil.cz/index.php?id=914 Procesní řízení. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2013-04-15]. Dostupné z: http://cs.wikipedia.org/wiki/Procesn%C3%AD_%C5%99%C3%ADzen%C3%AD GRASSEOVÁ, Monika, Radek DUBEC a Roman HORÁK. Procesní řízení ve veřejném sektoru: teoretická východiska a praktické příklady. Vyd. 1. Brno: Computer Press, 2008, v, 266 s. ISBN 978-80-251-1987-7. Event-driven Process Chain. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2013-04-15]. Dostupné z: http://cs.wikipedia.org/wiki/Event-driven_Process_Chain HAMMER, M., CHAMPY, J. Reengineering - radikální proměna firmy: manifest revoluce v podnikání. 3. vyd. Praha : Management Press, 2000. 212 s. ISBN 8072610287. PEKÁRKOVÁ. Techniky modelování a optimalizace podnikových procesů. Brno, 2007. Diplomová práce. Univerzita. Vedoucí práce RNDr. Jaroslav Ráček, Ph.D. Česká pošta, s.p. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2013-04-15]. Dostupné z: http://cs.wikipedia.org/wiki/%C4%8Cesk%C3%A1_po%C5%A1ta ŘEPA, Václav. Procesně řízená organizace. 1. vyd. Praha: Grada, 2012, 301 s. Management v informační společnosti. ISBN 978-80-247-4128-4. ŘEPA, Václav. Podnikové procesy: procesní řízení a modelování. 2., aktualiz. a rozš. vyd. Praha: Grada, 2007, 281 s. ISBN 978-80-247-2252-8. ROSENAU, Milton D. Řízení projektů: příprava a plánování, zahájení, výběr lidí a jejich řízení, kontrola a změny, vyhodnocení a ukončení. Vyd. 2. Brno: Computer Press, 2003, xii, 344 s. ISBN 80-722-6218-1. SVOZILOVÁ, Alena. Zlepšování podnikových procesů. 1. vyd. Praha: Grada, 2011, 223 s. Expert (Grada). ISBN 978-80-247-3938-0. VEBER, J. a kol. Management: základy, prosperita, globalizace. 1. vyd. Praha : Management Press, 2000. 700 s. ISBN 8072610295. JUROVÁ, M. Ekonomika a management podniku. Brno : Cerm, 2002. 217 s. ISBN 802142060X. DRDLA, M., RAIS, K. Řízení změn ve firmě - reengineering: jak vybudovat úspěšnou firmu. 1. vyd. Praha : Computer Press, 2001. 144 s. ISBN 8072264117. Business Process Model and Notation. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2013-04-15]. Dostupné z: http://cs.wikipedia.org/wiki/Business_Process_Model_and_Notation#N.C3.A1stroje_pro_t vorbu_BPMN
51
7
Seznam obrázků
Obrázek 1 - Organizační struktura regionu.......................................................................... 20 Obrázek 2 - Nápověda v šabloně typové smlouvy .............................................................. 28 Obrázek 3 - Legenda procesní mapy ................................................................................... 29 Obrázek 4 - Procesní mapa .................................................................................................. 30 Obrázek 5 - Tok dat systému ............................................................................................... 41
52
8 Seznam tabulek Tabulka 1 - Přehled obsazení definovaných typových pozic .............................................. 21 Tabulka 2 - Časové rozložení procesu Vzniku smlouvy ..................................................... 35 Tabulka 3 - Objekty návrhu řešení ...................................................................................... 40 Tabulka 4 - Modifikované kroky procecsu .......................................................................... 42 Tabulka 5 - Metriky v novém procesu ................................................................................. 47
53
