Projekty reimplementace ERP systémů

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií

Projekty reimplementace ERP systémů Diplomová práce

Autor:

Bc. František Bezvoda Informační technologie a management

Vedoucí práce:

Praha

doc. Ing. Vlasta Svatá, CSc.

červen, 2014

Prohlášení Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

…………………………. V Praze, dne 22. 4. 2014

Bc. František Bezvoda

Poděkování „Děkuji paní doc. Ing. Vlastě Svaté, CSc. za poskytnutí cenných rad a vedení mé práce. Dále bych chtěl také poděkovat Ing. Janu Vajgantovi, za poskytnutí informací k praktické části této práce.“

Bc. František Bezvoda

Anotace V této práci se zabývám problematikou reimplementace ERP systémů. Cílem je analyzovat příčiny, které vedly k zavedení nového informačního systému do podniku. Porovnat odlišnost od klasické implementace a identifikovat rizika, která jsou spojena s reimplementací. Práce je rozdělena do 6 kapitol. V prvních částech se věnuji popisu projektu. Dále se zabývám ERP systémy, jejich implementací a reimplementací. V závěru práce se věnuji reimplementaci IS ve velké společnosti a navrţení analýzy rizik tohoto projektu. Čtenář by měl být na jejím základě schopen pochopit základy projektového řízení a problematiku zavádění ERP systému. Také by měl dle jednoduché metody pochopit, jak zvládnout projekt efektivněji díky analýze rizik. Klíčová slova: reimplementace, projekt, analýza rizik, ERP

Annotation In this dissertation I deal with re-implementation of ERP systems. The aim of the work is to analyze causes which led to the information of the new informational system in the company. To compose the difference from the classical implementation and identify risks which are connected with reimplementation. The thesis is devided into six chapters. In the first part I deal with description of the project. Then I also deal with ERP systems, their implementation and reimplementation. Finally I push ahead reimplementation IS in a big company and proposing of a risk analysis of this project. The reader of the work should be able to understand the basis of the fundamentals of project management and implementation issues of ERP system. It should also by simple methods to understand how to manage the project more efficiently because of the risk analysis. Key words: reimplementation, project, risk analysis, ERP

Obsah Úvod ........................................................................................................................................... 8 Zvolené metody zpracování........................................................................................................ 9 1 Popis problematiky řízení projektů ...................................................................................... 10 1.1 Projekt ........................................................................................................................... 10 1.2 Ţivotní cyklus projektu ................................................................................................. 10 1.2.1 Předprojektová fáze ............................................................................................. 11 1.2.2 Projektová fáze .................................................................................................... 13 1.2.3 Poprojektová fáze ................................................................................................ 15 1.3 Ţivotní cyklus projektu v podmínkách IS a modely ..................................................... 16 1.3.1 Vodopádový model ............................................................................................. 17 1.3.2 Spirálový model .................................................................................................. 18 1.3.3 Síťový model ....................................................................................................... 19 1.3.4 Další modely ....................................................................................................... 20 1.4 Projektové řízení ........................................................................................................... 21 1.5 Metodika projektového řízení ....................................................................................... 22 1.5.1 Metodika PMBOK® ............................................................................................ 22 1.5.2 Metodika PRINCE2 ............................................................................................ 23 1.5.3 Krátké srovnání metodik ..................................................................................... 24 1.6 Vznik projektu ve firemních podmínkách .................................................................... 25 2 ERP systémy ........................................................................................................................ 27 2.1 Stručná historie ERP ..................................................................................................... 27 2.2 ERP neboli Enterprise Resource Planning ................................................................... 28 2.3 Trendy ve vývoji ERP .................................................................................................. 28 2.3.1 Cloud Computing ................................................................................................ 28 2.3.2 BPO (Business process outsourcing) .................................................................. 29 2.3.3 BPR (Business Process Reengineering) .............................................................. 30 2.3.4 SOA ..................................................................................................................... 31 3 Implementace ERP systému ................................................................................................ 33 3.1 Předimplementační projekt ........................................................................................... 33 3.1.1 Definování potřeb řízení...................................................................................... 33 3.1.2 Definice metody/modelu řízení ........................................................................... 34 5

3.1.3 Definice datové/informační základny ................................................................. 35 3.1.4 Optimalizace hlavních podnikových procesů (etapa 1) ...................................... 35 3.1.5 Definice poţadavků na ERP systém a jeho výběr ............................................... 36 3.1.6 Uzavření smlouvy, implementace a údrţba ERP ................................................ 36 3.2 BPR v rámci implementace .......................................................................................... 38 4 Reimplementace ERP systému ............................................................................................ 40 4.1 Znaky reimplementačních projektů .............................................................................. 40 4.2 Důvody vedoucí ke změně............................................................................................ 40 4.3 Reiplementační fáze...................................................................................................... 41 4.3.1 Popis výchozího stavu ......................................................................................... 41 4.3.2 Popis cíle ............................................................................................................. 42 4.3.3 Rozdílová analýza a roadmapa ............................................................................ 42 4.3.4 Implementace ...................................................................................................... 43 4.3.5 Testovací fáze ...................................................................................................... 43 5 Rizika ................................................................................................................................... 45 5.1 Analýza rizik ................................................................................................................. 45 5.2 Metody řízení rizik ....................................................................................................... 46 5.2.1 PMI ...................................................................................................................... 46 5.2.2 SWOT.................................................................................................................. 47 5.2.3 RIPRAN .............................................................................................................. 48 5.2.4 SLEPT ................................................................................................................. 51 6 Teorie v praxi ....................................................................................................................... 54 6.1 Zákazník ....................................................................................................................... 54 6.2 Dodavatel ...................................................................................................................... 54 6.3 Představení projektu ..................................................................................................... 54 6.4 Rozhovor....................................................................................................................... 55 6.5 Rizika projektu.............................................................................................................. 60 6.6 Očekávání zákazníka .................................................................................................... 62 6.7 Postup pro analýzu rizik ............................................................................................... 63 6.7.1 Příprava analýzy rizik.......................................................................................... 63 6.7.2 Identifikace rizika ................................................................................................ 64 6.7.3 Kvantifikace projektových rizik .......................................................................... 65 6.7.4 Sníţení rizika ....................................................................................................... 67 Závěr ......................................................................................................................................... 69 6

Seznam pouţitých zdrojů ......................................................................................................... 70 Seznam obrázků........................................................................................................................ 73 Seznam tabulek ......................................................................................................................... 73 Seznam grafů ............................................................................................................................ 73 Seznam příloh ........................................................................................................................... 73 Přílohy

7

Úvod Komunikační a informační technologie jsou neoddělitelnou součástí dnešního ţivota a tím pádem jsou součástí i ţivota kaţdého z nás. Nástup těchto technologií se výrazně zasadil do fungování celé společnosti. Dalo by se říct, ţe by svou měrou měli usnadňovat všem ţivot, avšak v nemálo případech tomu tak není. Ve sféře podnikatelské tomu tak však je určitě. Začali mnohé zjednodušovat a zrychlovat. Je jasné, ţe s tímto jevem však přicházejí nová úskalí. Kaţdý podnik, který chce dobře konkurovat a být prosperující, musí udrţovat své informační systémy na vysoké úrovni. Je totiţ dost moţné, ţe pokud by tuto část zanedbal, můţe to vést k samotnému krachu podniku. Naopak s dobrou znalostí informační technologie můţe přímo ovlivnit zvýšení produktivity nejen sebe, ale i celé ekonomiky. Na začátku devadesátých let nastal „boom“ na poli ERP systémů a většiny středních a velkých podniků začalo uvaţovat, jestli podnikový systém zavedou či nikoliv. Šlo totiţ o to, ţe v této neprobádané vodě si nebyli jisti, zdali jim tento krok poskytne dostatečně velkou konkurenceschopnost na úkor velkých nákladů, spojených se zaváděním nového IS. Jelikoţ se však všechny systémy stále zlepšují a přicházejí další nové nápady a vylepšení, otázkou kterou se podniky zabývají dnes, je reimplementace. Ne vţdy je totiţ moţné, tak jak je tomu u všeho nového, stávající situaci vyřešit nějakým rozšířením, nástavbou nebo upgradem. Pokud totiţ podnik v první implementaci špatně zvolil IS, je moţné, ţe jej jiţ nebude moţné „zachránit“. Pokud si zvolil špatného implementátora či neodpovídající produkt, který jiţ na zvětšování podniku, modifikaci směrnic atd. nestačí, bude muset přejít na IS zcela nový. Reimplementace s sebou paradoxně přináší mnohem větší riziko, neţ prvotní implementace. Jak jsem jiţ zmínil, při nezavedení IS můţe dojít k nekonkurenceschopnosti a zániku podniku. Tento osud můţe snadno postihnout i podnik, který zvolí špatný typ systému při implementaci druhého řádu. Nechci vše svalovat na špatně zvolený SW, protoţe faktorů, které provázejí úspěšnou implementaci, je mnohem více.

8

Zvolené metody zpracování Diplomová práce se bude zabývat reimplementací ERP systému. Proto bude nejprve v teoretické části práce popisovat oblasti jako je projektové řízení, druhy projektového řízení, ERP systémy atd. V další části se budu věnovat popsání příslušných analýz rizik, které by mohly projektové řízení ne usnadnit, ale pomoci mu, aby byl průběh projektu méně problémový. Jedním z cílů je případová studie reimplementace, ke které budu potřebovat projít nějakým projektem, kdy firma přechází na nový systém, nebo jej upgraduje. Budu proto muset kontaktovat systémového integrátora, abych s ním mohl nějaký projekt absolvovat. Shromaţďování informací tedy bude probíhat prostřednictvím rozhovorů se zaměstnanci integrátora. Pro zvolení analýzy rizik si vyberu metodu z několika dostupných, kterou aplikuji na zvolený projekt.

9

1 Popis problematiky řízení projektů 1.1 Projekt Kaţdý projekt je jedinečný, jelikoţ se jen v ojedinělých případech setkáme s moţností, ţe je moţné pouţít projektovou dokumentaci či pouţitý postup na projekt jiný. Kaţdý projekt realizujeme pomocí lidských a materiálních zdrojů v dané organizaci, se kterou musí být projekt v součinnosti. Cílem kaţdého projektu je splnit poţadavky ve 3 směrech, neboli „trojimperativ“. „Trojimperativ“ si klade za cíl splnit specifické provedení projektu, dle časového plánu, při dodrţení rozpočtovaných nákladů (ať finanční částky, či odpracované hodiny). Je samozřejmé, ţe mezi těmito třemi aspekty existuje spojitost. Pokud je jeden tento změněn, ovlivní v přímé souvislosti většinou oba zbývající. Proto se klíčovým poţadavkem „trojimperativu“ stává potřeba současného dosaţení tří nezávislých cílů. Projekt je definován mnoha způsoby, přesto, ţe se jednotlivé formulace definic různí, v závěru vystihují stejnou podstatu. Definice dle PMBOK: „Projekt je dočasně vynaložené úsilí k vytvoření unikátního produktu, služby nebo výsledku“1 Podobnou definici uvádí také norma ISO 10006 ED.2: „Projekt je jedinečný proces sestávající z řady koordinovaných a řízených činností s daty zahájení a ukončení, prováděný pro dosažení předem stanoveného cíle, který vyhovuje specifickým požadavkům, včetně omezení daných časem, náklady a zdroji.“2

1.2 Životní cyklus projektu V následující části se pokusím o tvorbu a částečný popis obecně pouţitelného modelu projektu, který bude mít širší pole vyuţitelnosti. Samotné rozdělení projektů bývá většinou třífázové.

1

A guide to the project management body of knowledge: PMBOK®guide – 4th ed. Newtown Squere, PA, USA: PM Institute, 2008. s. 5 PA 19073-3299 USA 2 [22] ČSN ISO 10006 ED.2, Management jakosti – Směrnice pro management jakosti projektů, Praha: Český normalizační institut, 2004. s. 18, Třídící znak 01 0333.

10

1.2.1 Předprojektová fáze Tato fáze má účelově prozkoumat případné příleţitosti pro projekt a posoudit jednotlivé proveditelnosti daného záměru. Někdy je v této fázi zahrnuta i základní myšlenka moţné realizace budoucího projektu. V této fázi se zpracovávají dva hlavní dokumenty a to studie příleţitosti (Opportunity Study) a studie proveditelnosti (Feasibility Study). a) Studie příleţitosti (Opportunity Study) hlavním cílem této studie je zhodnotit moţnosti realizace zamýšleného projektu. Je-li vůbec vhodná doba pro realizaci zamýšleného projektu. Studie se musí zaměřit na situaci v organizaci, na trhu, předpokládaný trţní vývoj, konkurenci atd. Výstupem tohoto dokumentu je doporučení či nedoporučení realizace zamýšleného projektu. Moţný případ této studie by mohl být následovný: Cíl: zpracovat informace o podnětech, zahrneme moţné příleţitosti či nutné reakce na hrozby trhu, případně nezbytnou restrukturalizaci firmy, Vstup: popsání záměru na projekt a podněty, které k tomu vedly, Obsah: bude obsahovat analýzu podnětů, příleţitostí, hrozeb a nutných reakcí na ně, analýzu problémů, které je příleţitost řešit. Dále základní koncepce a obsah záměru, odhad nadějnosti záměru, základní předpoklady, upozornění na významná rizika, závěrečná doporučení a závěr, zda z hledisek času, financí, zdrojů a dalších skutečností je vhodné zabývat se myšlenkou realizace projektu, Výstup: dokument s textem studie. Součástí této fáze bývá provedena také SWOT analýza, neboli analýza silných a slabých stránek, příleţitostí a hrozeb (viz kapitola 5.1.2). b) Studie proveditelnosti (Feasibility Study) k rozhodnutí, zdali má opravdu dojít k realizaci projektu, dojde organizace na základě předchozí studie. Studie proveditelnosti by měla ukázat nejvhodnější cestu

11

k realizaci daného projektu a zpřesnit obsahovou stránku. Dále stanovit termín zahájení a ukončení projektu a v neposlední řadě také odhadnout náklady a zdroje.

Moţný případ této studie: Cíl - stanovení a rozhodnutí o moţných cestách k dosaţení cíle ze současné situace. Ohodnocení cesty z hlediska potřebných nákladů a potřebného času se započtením disponibilních zdrojů. Upřesnění cílů a stanovení nejvýhodnější varianty cesty k nim, Vstup - pouţijeme závěr studie příleţitosti a jiné podkladové materiály o moţných omezeních (zdroje, finance, čas,…), Obsah - v obsahu se objeví rekapitulace závěrů studie příleţitostí a výchozí předpoklady. Popis základní myšlenky zamýšleného projektu a obsah. Dále musí obsahovat specifikace cílů, analýzu současného stavu, současných podmínek, lokalizace prostředí, organizaci a řízení, popis základního technického řešení, odhad délky, odhad celkových nákladů a rámcový průběh, odhad kritických zdrojů, návrh milníků, odhad přínosů, finanční a ekonomické analýzy (návratnost investic- ROI3, návratnost vlastního kapitálu - ROE4), sociální a jiné dopady projektu, návaznosti na jiné projekty, rozbor základních rizik, analýzu kritických faktorů úspěchu, explicitní podmínky a předpoklady pro průběh projektu, doporučení pro projektové fáze, Výstup - dokument s textem studie. V případě jednodušších projektů bývá zpracován pouze jeden dokument, který je nazýván předprojektovou úvahou, který kombinuje výše zmíněné dokumenty. Obecně bychom v této fázi měli dostat odpověď na strategické otázky projektu – odkud jdeme, kam chceme dojít, jakou cestu zvolíme a zda má vůbec smysl projekt

3 4

Vzorec pro výpočet je: ROI = (Zisk / investice * 100) Vzorec pro výpočet je: ROE = (Čistý zisk / Vlastní kapitál)

12

realizovat. Nejdůleţitější rozhodnutí, zda má být projekt spuštěn je obvykle v rukou liniového managementu organizace.5

1.2.2 Projektová fáze Tato fáze se zabývá především sestavením projektového týmu. Tým vytvoří plán, následně realizuje a na závěr předá výsledek. Předání vede k ukončení této fáze. Podrobněji se tato fáze člení následovně: Zahájení (start-up) zahájit se můţe např. na základě zakládací listině projektu, který se následně stává základním projektovým dokumentem, který definuje základní technickoorganizační parametry, Plánování vytvořen projektový tým s konkrétním zadáním úkolů. Tento tým vytvoří plán projektu, který pokud je schválen, je stanoven výchozím plánem a nazýván baseline. Základní pohled na projekt zajišťuje Ganttův diagram. Kromě základního pohledu se pouţívají další podpůrné nástroje, které vyuţívají metody PERT a CPM. o Ganttův diagram - je to druh pruhového diagramu, který je vyuţíván při řízení projektů. Jde o grafické znázornění naplánovaných posloupností v čase, o CPM (Critical Path Method) – je to metoda, při níţ hledáme nejkratší moţnou dobu trvání projektu, tedy nejmenší časový úsek, který je potřebný ke splnění všech úkolů, které projekt obsahuje. „ Řečí praxe projektového řízení je popis mnohem stručnější, zato výstižnější: kritická cesta je to nejdůležitější, co je třeba sledovat z hlediska

5

DOLEŢAL, Jan, MÁCHAL, Pavel, LACKO, Branislav a kol. Projektový management podle IPMA.1. vyd. Praha: Grada Publishing, 2009. s. 158-159. ISBN 978-80-247-2848-3.

13

dodržení

časového

rámce

projektu“.6

Tato

metoda

pouţívá

jednobodové odhady doby trvání úkolů. Předpokládá totiţ, ţe součtem trvání kaţdé jedné úlohy leţící na kritické cestě, dojde k celkové době trvání projektu, o PERT (Project Evaluation and Review Technique) – metoda PERT vychází z metody CPM, je zobecněním metody, ale na rozdíl od metody CPM pouţívá logika PERT pravděpodobnostní odhady doby trvání jednotlivých úloh. Počítá s pesimistickou, realistickou a optimistickou verzí odhadu doby.

„Ve skutečných projektech jsou závislosti mezi vyžadovanými činnostmi často složité a šipkový diagram projektu může pokrýt celou stěnu kanceláře“,7 o V obou případech, jak u CPM tak u PERT se jedná o metody síťové analýzy, které tvoří základy současného řízení projektů, z časového pohledu. o Vlastní realizace (fyzická) vlastní realizace je vhodné doprovodit tzv. kick-off meetingem. Coţ je zvláštní druh setkání zainteresovaných stran, kterým je zrekapitulován plán řízení a předán harmonogram projektu. Zástupci stran jsou navzájem seznámeni a je jim oznámeno, ţe začíná fyzická realizace. Je jasné, ţe v průběhu realizace je nutné projekt sledovat a porovnávat s původním plánem. Pokud by byly zjištěny odchylky, je nutné provádět korekční opatření a projekt přeplánovat. V případě potřeby se můţe přistoupit k předělání a vytvoření nového, upraveného základního plánu (baseline), Předání výstupů projektu a ukončení projektu (close-out) – V této fázi dojde k předání vytvořených dokumentů a především k předání fyzického výstupu. Je tak učiněno na základě podpisu akceptačních protokolů, předávacích dokumentů, či fakturaci. 6

DVOŘÁK, Drahoslav. Vyuţití CPM v plánování a řízení projektů. [on-line] 7/2004. [cit. 2014-02-03]. Dostupné z WWW: . 7 PERT a CPM. [on-line]. 25. 7. 2001 [cit. 2014-02-03]. Dostupné z WWW< http://www.kip.zcu.cz/kursy/svt/svt_www/6_soubory/6_6_2.html>.

14

1.2.3 Poprojektová fáze Během absolvování nového projektu, jsme obohaceni o mnoho nových poznatků a zkušeností, které můţeme vyuţít v projektech dalších. Proto je nutné analyzovat celý průběh projektu a určit jak dobré tak špatné zkušenosti. Toto vyhodnocení není nutně nástrojem pro označení někoho chyb, ale slouţí k tomu, aby byly nalezeny slabé stránky a chyby se mohly odstranit. Lze vyhodnotit jakost subdodavatelů a rozhodnout se případně pro jiné. Je nutné si uvědomit, ţe některé projekty jsou koncipovány tak, ţe k přínosům dojde aţ po nějaké době. V takovém případě je namístě, naplánovat si způsob přínosů i s termínem, kdy tyto přínosy vyhodnotíme. Obrázek č. 1: Schéma životního cyklu projektu

Zdroj: DOLEŽAL, Jan, MÁCHAL, Pavel, LACKO, Branislav a kol. Projektový management podle IPMA. s. 160.8

8

DOLEŽAL, Jan, MÁCHAL, Pavel, LACKO, Branislav a kol. Projektový management podle IPMA.1. vyd. Praha: Grada Publishing, 2009. 507 s. ISBN 978-80-247-2848-3.

15

1.3 Životní cyklus projektu v podmínkách IS a modely „Pro možnost řešení problémů, které mají dobře strukturovaný charakter, se v průběhu doby, kdy se člověk jejich řešením zabývá, ukázalo, že nejrozumnějším, nejlevnějším a nejefektivnějším způsobem je průběh takového jevu nebo skupin jevů nejprve popsat, na základě popisu sestavit jejich model a potom veškeré snahy o jejich změnu na takovém modelu nejprve vyzkoušet.“9 Jedním ze základních přístupů k řešení jak vědeckých tak praktických problémů v reálném světě, se stal modelový přístup, na jehoţ principech staví vědy jak technické, tak společenské. Takového modelování se pouţívá i při tvorbě informačního systému, k řešení nejdůleţitějších otázek. Potřeba takového modelování je o to větší, jelikoţ jde o kompletaci nehmotného produktu. Rozumějme tedy modelem ţivotního cyklu formalizovaný popis činností a aktivit, ve kterém jsou definovány vazby mezi činnostmi a dána časová posloupnost jejich plnění. Model tohoto cyklu má svůj začátek, nadefinované části a jejich hierarchickou strukturu a konec. Modelový přístup umoţňuje lépe se připravit na řešení problémů, které projekty IS přináší. Hlavní částí je příprava, která spočívá v tom, ţe pouţijeme znalosti z řešení projektů stejného druhu, které jsou ukládány do modifikací typových modelů. Nejčastěji pouţívaný bývá postup síťové formy zápisu. V poslední době se modely ţivotního cyklu projektu mění v závislosti na různých podmínkách na trhu informačních systémů a pouţívané informační technologie. Modely, vyvinuté v klasickém období se vyznačují obecným konceptuálním charakterem s globálním popisem ideového přístupu, zatímco modely posledních období odráţejí snahu o perfekcionismus v detailním zpracování. Dřívější modely se pouţívají dodnes, avšak ne pro operativní řízení projekčních prací, ale pro taktické a strategické řízení. Pro demonstraci hlavních přístupů jsem si vybral reprezentanty tří odlišných konceptuálních přístupů: vodopádový model, spirálový model, síťový model. 9

DOUCEK, Petr. Řízení projektů informačních systémů. 1. vyd. Praha: Professional publishing, 2004. s. 12. ISBN 80-86419-71-1.

16

1.3.1 Vodopádový model Tento model ţivotního cyklu projektu patří mezi nejstarší modely. Pojetí tohoto modelu vychází z trţní situace, kdy poptávka projekčních prací převyšuje nabídku a kaţdý projekt IS je jedinečným dílem na zakázku. Pouţití vodopádového modelu se dá uvaţovat v případech, ţe: jednotlivé etapy na sebe navazují, jsou tedy vykonávány po ukončení etapy předchozí. Výsledky předchozí etapy se verifikují a poslouţí jako vstup pro etapy další, při uvedeném pořadí etap se dosáhne nejlepšího výsledku, nedosáhne se lepšího výsledku při jiném pořadí vykonávání etap.

Obrázek č. 2: Vodopádový model životního cyklu projektu

Zdroj: Internet (http://www.fi.muni.cz/~smid/mis-zivcyk.htm) Do následujících pár bodů stručně shrnu ekonomické vztahy mezi dodavatelem projektu IS a objednatelem: veškeré finanční náklady na tvorbu projektu IS hradí objednatel od etapy předprojektové analýzy aţ po provoz a údrţbu, dodavatel má rámcovou metodiku, tuto naplňují konkrétní pracovníci na daném projektu,

17

na bedrech objednatele leţí míra riziky úspěšnosti projektu i podíl na krytí nákladů na projekt, dodavatel kryje náklady pouze na základní vyškolení vlastních zaměstnanců a získání základní informační technologie.

1.3.2 Spirálový model Spirálový model je z období renesance řízení projektů IS. Oproti vodopádovému modelu je na trhu vývojových prací vyrovnanost mezi nabídkou a poptávkou, nebo dokonce mírná převaha nabídky. Tato metoda si zakládá na schopnosti řešitele vytipovat vhodnou oblast pro podporu IS a najít existující latentní poptávku pro IS. Na vlastní náklady dodavatel provede analýzu příslušné problematiky a sestaví prototyp IS nebo jeho částí. S tímto prototypem přijde na trh a v návaznosti na reakce trhu tento IS buď prodává a implementuje, nebo jej dále vyvíjí a přichází s novými verzemi. Nejčastější však je kombinace obou moţností. Obrázek č. 3: Spirálový model životního cyklu projektu

Zdroj: DOUCEK, Petr. Řízení projektů informačních systémů. s.72.10 Dle spirálového modelu, se podíl rozdělení nákladů mezi dodavatelem a objednatelem mění, protoţe první verze vyvíjeného systému si provede dodavatel sám na vlastní náklady. Objednatel tedy zaplatí za odzkoušený prototyp jen část jeho skutečné vývojové ceny. Dodavatel počítá s tím, ţe daný prototyp prodá víckrát. Na základě předešlých zkušeností 10

DOUCEK, Petr. Řízení projektů informačních systémů. 1. vyd. Praha: Professional publishing, 2004. 209 s. ISBN 80-86419-71-1.

18

s prototypem se prototyp neustále zlepšuje a obsahuje stále více funkcí. Ty komplexněji pokrývají poţadavky objednatele a řešenou problematiku. Ve srovnání s poskytnutou uţitnou hodnotou systému, je jeho cena relativně niţší.

1.3.3 Síťový model Tento model je ukázkou industriálního přístupu k tvorbě projektů IS. Takovýmto IS se většinou věnují větší firmy zabývající se tvorbou IS. Tyto pouţijí nasbírané zkušenosti z projektů předešlých a postupně si vytváření síť navazujících činností a výsledků. Výsledkem jsou vazby mezi činnostmi a jejich chování, které potom představují síťový model. Síťový model je v praxi pouţívám ve více stupních. První stupeň soustavy je model typový, který popíše obecné chování firmy při práci na projektu IS. Tato úroveň slouţí jako obecně platný návod, který popisuje chování při realizaci. Typový síťový model představuje schéma, jak pracovat s dalšími modely, které jsou na niţší úrovni z pohledu hierarchie. Tudíţ tento model můţeme povaţovat za metamodel. Obrázek č. 4: Metamodel nasazení síťového modelu

Zdroj: DOUCEK, Petr. Řízení projektů informačních systémů. s. 7511. Podle potřeb konkrétního projektu A je tento TSM model upraven na typový model A(TMSA). Přičemţ součástí modelu TMS musí být všechny činnosti a výsledky, které zahrnuje model A(TMSA). Pokud tato podmínka nebude splněna, musí se modifikovat nový 11

DOUCEK, Petr. Řízení projektů informačních systémů. 1. vyd. Praha: Professional publishing, 2004. 209 s. ISBN 80-86419-71-1.

19

obecný model TSM pomocí zpětné vazby. Tímto se do řízení projektů zahrnuje proces učení se. V podstatě se jedná o postupné zdokonalování obecně platného TMS. Tím samozřejmě roste i „know-how“ uloţené v tomto TMS. V závislosti na změně proměnných externích podmínek jako je změna pouţívané technologie či metodik a postupně se rozšiřující znalosti, se musí modifikovat i vlastní typový model A(TSMA). V praxi se tomuto děje velice často. Rychlým postupem a rozvojem nejen informačních technologií jsou pohledy na první iteraci konkrétního rozpracování síťového modelu zkreslené a neodráţejí přesný čas zamýšleného projektu. Takovýmto přístupem můţeme dojít k velice kvalitnímu řízení tvorby projektu v závislosti na interních a externích faktorech. Z ekonomického pohledu je rozdělení nákladů a rizik ještě více nakloněno objednateli. Tento se vlastně stává odběratelem hotového IS a dodavatel obstarává jen nastavení parametrů vzhledem k poţadavkům konkrétního zákazníka.

1.3.4 Další modely Vlivem různých podmínek ve firmách vznikají další modely ţivotních cyklů projektů např.: fontánový – má za úkol zdůraznit specifika pouţití, vzhledem k pouţitým technologiím, optimální životní cyklus projektu – tento hledá optimální řešení jak pro objednatele, tak pro dodavatele, inkrementální model – v současnosti velmi pouţívaný model ţivotního cyklu. Jindy bývá nazýván také přírůstkový. model sestavený praxí poslední model, kterému bych se chtěl věnovat, je model, který přinesla samotná praxe při tvorbě a řízení projektů IS. Projekt IS s sebou přináší velké naděje, k dosaţení dobrých výsledků a zlepšení v dimenzích projektu odlišných a to obchodních, technologických, procesních,… Stejně tak je to se zájmy zúčastněných osob: 

bezmezné nadšení,



rozčarování,



hluboká beznaděj,



hledání viníků, 20



potrestání nevinných,



odměnění nezúčastněných.

Jedním ze základních nástrojů projektového řízení jsou právě tyto modely ţivotního cyklu projektu. Jsou definovány modely vlastní v metodikách dle potřeby nasazení daného modelu ţivotního cyklu pro řízení projektu. Jak to s projektem a projektovým řízením můţe občas vypadat, se můţete přesvědčit na zobrazení v následujícím obrázku, který s nadsázkou ukazuje nešťastná řešení projektu. Obrázek č. 5: Jak projekt skutečně funguje

Zdroj: Internet (http://www.projectcartoon.com/cartoon/2)

1.4 Projektové řízení „Vedení projektu v sobě zahrnuje mnohem víc než používání softwaru k řízení projektů.“12 12

ROSENAU, Milton D. Řízení projektů. 1. vyd. Praha: Computer Press, 2000. s. 5. ISBN 80-7226-218-1.

21

Projektové řízení je v podstatě manaţerská technika, pouţitá pro včasné a úspěšné dokončení časově omezené práce, za pomoci řízení cesty navazujících stavů v projektu. Pokud tedy řídíme projekt, znamená to řídit mnoho odlišných činností, které vykonávají jiní lidé. Jednou z klíčových rolí pro absolvování úspěšného projektu je schopnost manaţera správně motivovat a vést lidi. Manaţer se totiţ setkává s pestrou rozmanitostí nejen povah, ale i osobních ambicí a odlišných zájmů lidí, kteří na projektu pracují. Dále s lidmi musí umět jednat a vyznat se v mezilidských vztazích, aby lidem lépe rozuměl. Toto je jeden z hlavních důvodů, proč projektové řízení není ţádnou rutinní záleţitostí, ale vyţaduje mnoho tvůrčího přístupu k řešení úkolů. Nejčastější kolizí na projektu bývá disproporce mezi zdroji a jejich potřebami. U lidských zdrojů je tím myšleno nevytíţení či naopak přetíţení lidí. Projekt totiţ často nutně sdílí zdroje s ostatními projekty a podnikovými útvary. „Zásady projektového řízení jsou shrnuty do tzv. oblastí znalostí. Projektové řízení rozlišuje devět oblastí znalostí: řízení integrace, rozsahu, času, nákladů, kvality, lidských zdrojů, komunikace, rizika a nákupu“.13

1.5 Metodika projektového řízení Jak bylo zmíněno, kaţdý obor, či odvětví, bude muset k řízení projektu přistupovat trochu odlišným způsobem. „Metodikou budeme rozumět formálně zpracovaný souhrn standardů, modelů, nástrojů, postupů, doporučení a jednotlivých pracovních kroků, které jsou k dispozici před zahájením projektu“.14 Řízení projektů by jiţ nemělo být zaloţeno na zkušenostech jedince, ale mělo by postupovat podle ověřených a odzkoušených pravidel a norem. V celosvětovém měřítku jsou dvě nejuznávanější techniky způsobu řízení projektů.

1.5.1 Metodika PMBOK® Tato metodika byla navrţena Pensylvánskou společností Project Management Institute (PMI) v roce 1987. V dnešní době evidujeme její 5té vydání. PMBOK® je zřejmě nejstarší 13

FIALA, Petr. Projektové řízení – modely, metody, analýzy. 1. vyd. Praha: Professional Publishing, 2004. s. 7. ISBN 80-86419-24-X. 14 DOUCEK, Petr. Řízení projektů informačních systémů. 1. vyd. Praha: Professional publishing, 2004. s. 12. ISBN 80-86419-71-1

22

standard zabývající se projektovým řízením. Tento standart se dostal do podoby uceleného pohledu na problematiku projektového řízení a snaţí se obsáhnout a obecně popsat všechny aspekty projektového řízení. Základ je tvořen procesními skupinami a znalostními obory. Jako zajímavost bych rád uvedl, ţe v rámci metodiky PMBOK® je kladen velmi silný důraz na etiku a profesionální zodpovědnost. Není sice obsahem manuálu samotného, ale podstatná část testu a celé metodiky se řídí jasně definovaným kodexem.

1.5.2 Metodika PRINCE2 Je to ve své podstatě strukturovaná metodika pro efektivní řízení projektů. První vydání bylo v roce 1989 společností CCTA ve Velké Británii. Tato metodika byla zaloţena na základě metodiky PROMPTII, vytvořenou firmou odlišnou. CCTA pokračovala na vývoji a v roce 1996 vydala standard PRINCE2. Tento standart odpovídal na nové otázky projektového řízení nejen v oblasti informačních a telekomunikačních technologií.

Mezi nejdůleţitější principy PRINCE2 patří: - průběţné zdůvodnění projektu, - poučení se ze zkušeností, - definované role a zodpovědnosti, - řízení pomocí etap, - dohled nad projektem na základě výjimek, - důraz na produkty, - nutnost upravit metodiku podle aktuálního prostředí.15

15

Systemonline[on-line]. 10. 02. 2014 [cit. 2014-02-10]. http://www.systemonline.cz/sprava-it/prince2-nebo-pmi.htm>.

23

Dostupné

z

WWW:

<

1.5.3 Krátké srovnání metodik Jelikoţ srovnání na širší úrovni by vydalo na samostatnou diplomovou práci, provedu srovnání metodik PMBOK® a PRINCE2 ve stručnosti a alespoň v základních kamenech projektu: Obecné shrnutí a odlišnosti uvádím v následující tabulce: Tabulka č. 1: Srovnání Prince2 a PMBOK

PRINCE2

PMBOK®

Metoda řízení projektů

Souhrn nejlepších praxí pro řízení projektů

Normativní

Není normativní

Ucelený souhrn procesů a témat (z jednotlivých oblastí není moţné čerpat nezávisle na ostatních

Z kaţdého tématu se dá čerpat nezávisle od druhých

Pokrývá všechny role řízení projektů

Je zaměřen na projektové manaţery

Neobsahuje mezilidské vztahy a jemné dovednosti

Popisuje jemné dovednosti (soft skills)

Odvolává se na techniky

Popisuje techniky řízení projektů

Podíváme-li se na pár základních oblastí, také zde najdeme odlišnosti, za všechny uvádím alespoň tyto 3 oblasti: a) Oblast ţivotního cyklu projektu PMBOK – na ţivotní cyklus není v této metodice brán moc velký zřetel. Ve srovnání s ostatními metodikami je definován velmi obecně. Spíše ho definuje pomocí rozšíření tzv. Demingovým cyklem „PDCA“ – Plan (dokumentace), Do (automatizace), Check (výpočet indikátorů), Act (návrh opatření ke zlepšení), PRINCE2 – výborně popisuje realizační fázi cyklu projektu, popisem hierarchie organizační struktury.

b) Oblast dokumentace: 24

PMBOK – nejsou zde definovány ţádné šablony dokumentů, které by byly výstupem procesních znalostí v dané oblasti, PRINCE2 - V šablonách navrhuje a ukotvuje struktury poţadovaných dokumentů, které během projektu vznikají. PRINCE2 nezapře svojí genezi. Vzhledem k většímu objemu poţadované dokumentace je poznat, ţe původní orientace byla na projekty z oblasti ICT. c) Oblast náhledu na roli projektového manaţera: PMBOK – Je chápán jako: „Osoba přiřazena k projektu aby dosáhla projektových cílů, přičemţ je za toto zodpovědná“. Projektový manaţer rozhoduje o hloubkách a vhodnostech aplikace určené procesní skupiny. Podle definice integrálního vyuţití procesních skupin v průběhu projektu je jasné, ţe dle PMBOK je role manaţera plánovací, produkční a monitorovací. Navíc zahajuje dané fáze a také fáze ukončuje akceptací výstupu, PRINCE2 – chápe roli manaţera projektu jako zakotvení povinností do čtyřvrstvé organizační struktury. Je zodpovědný za řízení projektu na kaţdodenní bázi, kdy rozhoduje o řešení v nestandardních situacích v gesci projektové rady. Povinností projektového manaţera je reportovat radě průběh projektu.

1.6 Vznik projektu ve firemních podmínkách Pokud přehlédneme, ţe vznik projektu ve firmě by mohl být způsobený přímou potřebou nového IS a zaměříme se na pohled ekonomický, zjistíme, ţe téměř kaţdá firma existuje za účelem zisku a prosperity. V takovýchto firmách většinou nutnost vzniku projektu a potaţmo často nutnost reimplementace podnikového IS vyvolávají následující tři faktory: 1. Sníţení nákladů. V současné hektické době a honbě za zvětšováním materiálního i nemateriálního bohatství, vzniká více neţ kdy, velké konkurenční prostředí a je tedy nutné přemýšlet, jak v této konkurenční společnosti vydrţet. Je tím pádem nutné, co nejvíce sniţovat náklady a to z hlediska ekonomického, především reţijní. Toto vyvolává potřebu změn v kvalitách a kvantitách zdrojů

25

2. Sníţení ceny produktu. Pro perspektivní prosperování firmy, musíme dobře pokrýt poptávku zákazníků. Je tedy nutné míti k dispozici ověřené informace a na trh dodávat za konkurence schopné, potaţmo co nejniţší ceny. 3. Vznik nové myšlenky a produktu. I intelektuální kapitál podniku jistě vyvolává změny, tím ţe vznikají nové myšlenky, které jsou následně realizovány a doplňují mezery na trhu, či dokonce zakládají trh nový.

26

2 ERP systémy 2.1 Stručná historie ERP V 60. letech 20. století se jiţ naplno ukázala potřeba podniků automatizovat a zlepšovat důleţité procesy. První vlaštovkou byl automatizovaný systém, který vznikl ze spolupráce Case Corporation s firmou IBM. Významný výrobce traktorů a stavebních strojů spolu navrhli a zavedli prvního předchůdce ERP systému a to MRP (Material Requirements Planning). Byl to software pro plánování materiálových potřeb a následné rozvrhování materiálu pro výrobu. Rozvoj pokračoval dále a začali vznikat první sw společnosti jako SAP (r. 1972), Lawson Software (r. 1975), či Oracle Corporation (r. 1977). Tyto jiţ zapracovali na nových platformách a jiţ pomalu na trhu začaly nabízet klasické podnikové aplikace, které byly schopné integrovat klíčové podnikové procesy. Trvalo ještě 10ti letí, neţ se objevily na půdě podniků komplexní ERP systémy. První ERP systémy, které zahrnuly všechny pro podnik důleţité procesy, z nichţ mnohé vykonávány dříve lidmi, se automatizovali aţ od 90. let 20. století. ERPII. Tyto jiţ dokázaly překročit hranice podniku a to především v oblasti logistiky. Bylo to díky koncepci vzájemné spolupráce mezi podniky a rozšířily tuto spolupráci na úrovni dodavatelsko-odběratelské. Dodavatelé mají např. přehled o stavových zásobách a mohou sami předejít zásobě nedostatečné v rámci funkce JIT (Just In Time). ERPIII. Třetí generace pokračuje v překračování vnitropodnikového back office. Nyní se vydává směrem blíţ k zákazníkům. Dominantní role se ujímají systémy CRM (Customer Relationship Management) a sociální sítě. Vývoj sociálního CRM (sCRM) tento trend jen potvrzuje. Ţhavým trendem dnešní doby je zapojení zákazníků do podnikového dění a díky tomu nové moţnosti inovací, které zákazníci přinesou. Pomáhají s návrhem a designem produktů a sluţeb a podílejí se na nových obchodních modelech.

27

2.2 ERP neboli Enterprise Resource Planning Je mnoho definic, které ERP definují. Z mnoha z nich bych si pro příklad vybral tuto: „ERP systém je obecně komplexní systém, který pokrývá všechny oblasti fungování podniku a současně je vybudovaný na jediné platformě“16. ERP systémy zastřešují firemní činnosti, které se týkají výroby, financí, účetnictví, dodavatelů, řízení lidských zdrojů, CRM, BI atd. Tyto systémy sbírají a integrují všechna data a procesy dané organizace do unifikovaných celků. Systém k dosaţení integrace vyuţívá mnoţství softwarových komponent (modulů) a hardwarové sloţky.

2.3 Trendy ve vývoji ERP Podnikový IS je jednou z nejdůleţitějších komponent podniku. V ideálním případě zjednodušuje lidem práci. Je zde moţné uchovávat mnoho dat, od finančních plánů po seznamy šroubů ve skladu. Správně volený podnikový IS zcela jistě pomůţe ke zvýšení efektivity práce a tudíţ i k většímu zisku.

2.3.1 Cloud Computing V poslední době se v hojném počtu začal vyuţívat IS pouţívání v tzv. cloudu neboli Cloud Computing. Toto řešení totiţ umoţnuje pohodlný síťový přístup do sdílené paměti konfigurovatelných výpočetních zdrojů. Čili zákazník se pomocí svého webového prohlíţeče dostane na servery, kde jsou uloţená jeho data, aplikace a sluţby. Cloud computing představuje model poskytování aplikací v podobě sluţby. Posouvá moţnosti opět dále o grid computing a clusterové řešení. Cloudová řešení v oblasti ERP, nejsou nejlepší volbou všude. Mají uplatnění při řízení nekritických procesů, tedy tam, kde zajišťují pouze provoz agend, které neovlivňují generování přidané hodnoty (nákup, výroba, prodej, logistika,…). Velkým trendem je dosazování mnohých sociálních funkcí a jak se ukazuje, ERP zaloţený na technologiích minulého tisíciletí na toto není připraven a snahy o veškeré záplatování zdá se budou znamenat nutnost nového řešení. Je jasné, ţe původní návrháři a tvůrci s takovýmto vývojem mohli těţko počítat a proto co nevidět začne rozvoj ERP systémů naráţet na nejrůznější limity. Co nevidět se ukáţe, zda právě nejrůznější

16

SVATÁ, Vlasta. Projektové řízení v podmínkách ERP systémů. 3. vyd. Praha: Oeconomica, 2007. s. 6. ISBN 978-80-245-1183-2.

28

sociální funkce, které jsou přidávané do ERP s velkými ovacemi, budou mít nějaký reálný přínos pro pracovníky péče o zákazníky či obchodní analytiky. Ukáţe se, nešlo-li jen o módní vábničku. Hlavním cílem měla být orientace na zákazníka, porozumění jeho potřebám a více interakcí. Výrazným trendem je také mobilita. Firemní zaměstnanci jsou dostatečně vybaveni mobilními telefony na platformách iOS, Android či Win a chtějí více vyuţívat funkcí a potenciálu těchto zařízení. Tato zařízení chtějí také více vyuţívat ve firemních procesech, které jim umoţní přístup k informacím v reálném čase. Toto nejlépe v interaktivní formě a v odpovídajícím grafickém provedení. Nové trendy jako jsou smarthphony a displeje s vysokým rozlišením, proměňují také způsoby ovládání podnikových aplikací. Do popředí se dostávají pojmy jako např. uţivatelské rozhraní či uţivatelská přívětivost. Co se týče EPR systémů, půjde o podobně výrazný předěl, jako přechod z DOS na Windows. Distribuční modely cloudu jsou: SaaS (Software as a Service) – jde o přes internet nabízenou sluţbu zákazníkům, kdy dochází k hostování aplikace provozovatelem sluţby. Zákazník se přes internet připojuje k softwaru, který má dodavatel nainstalovaný na svých serverech, za stanovenou pevnou cenu, PaaS (Platform as a Service) – v tomto modelu poskytovatel nabízí kompletní prostředky pro podporu úplného ţivotního cyklu tvorby webových aplikací a sluţeb. Není zde moţnost staţení software, IaaS (Infrastructure as a Service) – zde si zákazník pronajímá volitelně dimenzovanou infrastrukturu, ve které platí za vyuţívání informačních technologií. Většinou je cena odvozena od velikosti uloţených dat, či doby procesoru.

2.3.2 BPO (Business process outsourcing) BPO (outsourcing obchodního procesu), je další logická úroveň, která mění provozní model dalším způsobem a dostává se za rozsah sluţeb cloud computingu. BPaaS (Business Process as a Service) zastřešuje integraci podnikových procesů a SaaS. Spoustě zákazníkům jiţ nestačí sada funkcionalit prostřednictvím software, tak začínají poţadovat outsourcing celého obchodního procesu. Tato sluţba v sobě integruje vyváţené riziko, vnímatelné přidanou hodnotou pro zákazníka na jedné straně a na straně druhé u poskytovatele dobrou obchodní příleţitost. 29

Předpokládaný vývoj na trhu BPO, tak jak jej predikuje společnost Gartner, můţete vidět na grafu č. 1. Graf č. 1: Vývoj na trhu BPO

Zdroj: https://www.gartner.com/ - Forecast Overview: Public Cloud Services, Worldwide, 2011-2016, 2Q117

2.3.3 BPR (Business Process Reengineering) BPR (Business Process Reengineering) znamená změnit procesy v podniku a orientovat se na vztah k okolí. Při BPR analyzujeme, co máme udělat, s čím, kdo to má udělat, s jakými daty, na základě jakých událostí, případně jaký software se při tom pouţívá. V podstatě jde opět o zvýšení konkurenceschopnosti podniku. Pro všechny podniky je toto pro jejich přeţití nezbytné, jelikoţ neustále musí bojovat s měnícím se podnikatelským prostředím, ve kterém neustále roste konkurence. V podstatě jde o postup, který má za úkol optimalizovat podnikové procesy tak, aby přinesly maximální efekt při optimální spotřebě zdrojů. Při zavádění daných ERP systémů, které měly BPR podporovat, se však začalo naráţet na nedostatky a to hlavně z důvodu, ţe se dnes na procesech podílí více účastníků. 17

Forecast overview: Public cloud services Worldwide[on-line]. 26. 12. 2013 [cit. 2014-01-10]. Dostupné z WWW: < https://www.gartner.com/ >.

30

„Přes nedostatky lze říci, že ERP systémy postupně přiměly podniky myslet procesně a vytvořily tak předpoklady pro další rozvoj v této oblasti“.18

2.3.4 SOA Trendem na poli ERP systémů se objevil výraz SOA (Service Oriented Architecture) a stává se fenoménem poslední doby. SOA je poměrně nová koncepce architektury IS. V podstatě daná aplikace sestaví do sluţby nasbíraná data z různých programů a prezentuje např. pomocí webové sluţby svému okolí. „SOA není technologie nebo produkt, jde o holistický koncept pro navrhování IT architektur a realizaci business procesů s cílem synchronizovat business v IT. Vedle historické architektury založené na naingramech a současné architektury založené na koncepci klient/server tak představuje další stupeň ve vývoji IT architektur“.19 O ERP implementovaný pomocí SOA je veliký zájem a mohou za to zejména tyto vlastnosti: Volná vázanost a „zapouzdřenost“ služeb – na sobě nezávislé sluţby, bez propojení zdrojového kódu. Moţnost změn bez dopadu na klienta, Znovupoužitelné služby – víc aplikací pouţívá jednu sluţbu, Asynchronní komunikace mezi službami – sluţba po odeslání zprávy nečeká na odpověď jiné sluţby a pokračuje v procesu, proto se neblokují kanály zasílání zpráv, Metadata všech služeb jsou uložena v úložišti, SOA umožňuje propojit konkurenční sw, Využívá “coarse grained“ aplikační programovací prostředí – menší mnoţství sloţitějších komponent, coţ má za následek širší úroveň funkcionality. Dodržuje otevřené standardy – vyuţívají se HTML, XML, HTTP apod.

18

SVATÁ, Vlasta. Projektové řízení v podmínkách ERP systémů. 3. vyd. Praha: Oeconomica, 2007. s. 7. ISBN 978-80-245-1183-2. 19 SVATÁ, Vlasta. Projektové řízení v podmínkách ERP systémů. 3. vyd. Praha: Oeconomica, 2007. s. 8. ISBN 978-80-245-1183-2.

31

Tuhle architekturu můţeme znázornit pomocí obecného modelu, viz obrázek:

Obrázek č. 6: Referenční model architektury SOA

Zdroj: Internet (http://www.systemonline.cz/sprava-it/proc-soa-nema-alternativu.htm)20

20

Proč SOA nemá alternativu [on-line]. 19. 1. 2014 [cit. 2014-01-19]. Dostupné z WWW: < http://www.systemonline.cz/sprava-it/proc-soa-nema-alternativu.htm >. 32

3 Implementace ERP systému V předchozích kapitolách o projektu jsme se dozvěděli, ţe kaţdý projekt má obecně podobná řešení. Jinak tomu není ani u projektu implementace ERP. V následujících bodech popíši fáze implementace projektu ERP, které jsou vlastně také tzv. ţivotním cyklem projektu.

3.1 Předimplementační projekt Přechod podniku na pouţívání ERP systému je obrovský skok pro firmu jak z pohledu ulehčené práce, tak zavedení nových postupů, či novému učení se zaměstnanců. V dnešní době velké konkurence mnoho poskytovatelů ERP systémů nabízejí přípravné projekty předcházející projektům implementace v podobě cíle, který má vybrat vhodný ERP systém, který bude nejlépe odpovídat svojí funkčností a splní nejlépe očekávání zákazníka. Tento projekt není klasickou odpovědí na poptávku. Musí zahrnout spoustu kroků, které předcházejí výběru. V podstatě by se mělo jednat o kroky následovné: definování potřeb řízení, definování systému řízení, definování datové/informační základny, optimalizace hlavních podnikových procesů (etapa 1), definování poţadavků na aplikační software a výběr ERP systému, uzavření smluv, nákup licencí, implementace a údrţba zvoleného ERP systému.

3.1.1 Definování potřeb řízení V posledních letech došlo k několika zásadním změnám, které vedly k ovlivnění charakteru podnikání. Tyto změny by se daly shrnout v následujících bodech: podporuje-li informační systém řízení, není moţné zvyšovat jeho účinnost neustálým rozšiřováním velikosti disponibilních dat. Je potřeba tento systém informací účelově orientovat na prvotní studií rozpoznané potřeby řízení, propojíme-li systémově dílčí funkce systému, dojdeme ke zvýšení jeho účinnosti, je vhodné integrovat koordinaci funkcí systému řízení v informačním systému. Na vrcholu této koordinace je účetní zobrazení podnikatelského procesu. Tímto postupem bude zaručena průkaznost, věcná správnost a úplnost dat, 33

tento účetní systém pak musíme primárně chápat jako nástroj řízení podnikatelského procesu, nepomáhá totiţ splnění poţadavkům externích uţivatelů např. daňovým úřadům. Výstup této etapy musí dát odpovědi na to, jaké modely řízení jsou pro danou společnost vhodné. Kaţdý model popisovaný teoreticky a vyzkoušený v praxi, má své nevýhody, se kterými je nutné počítat. Kaţdý model má vliv jak na architekturu informačního systému, tak zvolený softwarový produkt. Zvolený software se stává jádrem informačního systému, ve kterém se zobrazí modelové řízení. Výstupem této etapy by mělo být: na jakém stupni řízení budou určité části procesů realizovány, způsob rozkladu společnosti za účelem optimalizace jejího řízení. Moţné klasickým funkčním rozkladem s uváţením jednotlivých úseků a středisek, návrh jakým způsobem zvýšit hospodárnost společnosti tj. jak sníţit náklady a zvýšit objem výkonů, definovat časové intervaly a časové sledy.

3.1.2 Definice metody/modelu řízení Modelů v dnešní době existuje velké mnoţství. Rozdílnost modelů spočívá v tom, ţe kladou větší důraz na jiný aspekt řízení. Přiblíţím popisem třech druhů ve finančním modelu a jejich rozdílném pohledu: 1. Nákladové účetnictví - ţádoucí stav je porovnán se zjištěnou skutečností a koncipováno jako: a. Výkonové účetnictví – to je zaloţeno na kalkulaci výkonu a vychází ze skutečných nákladů, zisku atd. na dílčí a finální výrobek, sluţbu, b. Odpovědnostní účetnictví – zaměřeno na to, jakým způsobem jednotlivé vnitropodnikové útvary přispívají k celopodnikovým výsledkům, c. ABC (Aktivity Based Costing) – podklad pro řízení procesů. Cílem této metody je vytvoření transparentnosti ve výkonech a nákladech zejména v oblasti nepřímých nákladů. Díky tomu je moţné alokovat nákladové objekty podle principu příčinnosti, a proto je moţné zredukovat neefektivní aktivity.

34

2. Manažerské účetnictví – toto účetnictví se opírá o hodnotové/peněţní informace. Znázorňuje moţné scénáře budoucího vývoje společnosti pomocí simulací, změnou vymezení aktiv a pasiv, oceňovacích principů a přemýšlení o faktorech, které ovlivňují zisk. 3. Controlling – ten se opírá o nepeněţní i hodnotové informace a řeší nákladovou stránku procesů, finanční (cash-flow) i naturální.

3.1.3 Definice datové/informační základny Definování datových/informačních entit dle popsaného modelu řízení, je dalším krokem k optimalizaci systému řízení. Nutné definovat také způsob ukládání a přenosu datových entit. Je tedy pro optimalizaci nutné určit které všechny informační entity budeme pro implementaci ERP systému potřebovat (popisy odpovědností, skladové listy, normohodiny,…) a neexistují-li, tak je popsat, kdo bude odpovědný za aktualizaci entit, přidělení práv k přístupu a úpravám těchto entit, zodpovězení otázky bezpečnosti (zálohování dat, šifrování dat,…), definici poţadavků ve vazbě ţivotního cyklu dat. Kdy jaká data komu budou přístupná.

3.1.4 Optimalizace hlavních podnikových procesů (etapa 1) Tato fáze optimalizace podnikových procesů by měla probíhat paralelně s etapou předchozí, tedy definicí datové/informační základny. Chceme-li míti správně definovaný model řízení, musíme do něj zahrnout správně interpretované informace, které produkují stávající podnikové procesy. Proto je nutné veškeré probíhající procesy účelně popsat a formalizovaným způsobem optimalizovat. Musejí se dodrţovat stanovená pravidla týkající se událostí, funkcí, vstupů i výstupů. K vytváření procesního modelu můţeme vyuţít BPMS (Business Process Management Suites) coţ je nástroj z oblasti BPM (Business Process Management).

35

3.1.5 Definice požadavků na ERP systém a jeho výběr Tato fáze je poslední etapou v optimalizaci systému řízení. Výstupem této etapy je poptávka, která by měla obsahovat: informace o společnosti, popis řízení systému a nedostatky, popis stávajícího hardware a software vybavení, popis poţadavků na plánovaný systém řízení, popis procesů z etapy 1 a datové základny.

3.1.6 Uzavření smlouvy, implementace a údržba ERP Na správné uzavření smlouvy musí být také kladen důraz, neboť můţe dosavadní snahu o optimalizaci také degradovat. Je nutné, aby na uzavření smlouvy participoval jak specialista IT, který vychází z týmové spolupráce, tak právní zástupce. Právní zástupce zkontroluje a dá rámec formální stránce. Kdeţto IT specialista dohodne stránku věcnou. Hlavními oblastmi, na které se ve smlouvě zaměřit jsou: smlouva musí jasně a zřejmě definovat cíle a jejich měřítka: o zda cílem je sníţení nákladů stávajících procesů a zároveň ponechání zavedené integrity, o či zvýšení produktivity procesů, nebo o celková transformace procesů. ve smlouvě musí být dohodnuté ceny za sluţby. Kvalita implementace bude také odpovídat do velké míry ceně, která bude dohodnuta, musí být uvedeny a definovány milníky implementace, jakoţto také akceptační procedury a kontroly kvality, kdy se za pomoci externích školitelů realizuje 2. etapa optimalizace procesů, ta se jiţ bude řídit moţnostmi aplikačního software, pokud bude dohodnuto zádrţné, zvolit výši a vyplacení po úspěšném uvedení do provozu, vymezení odpovědností ve všech sférách. Odpovědnost za vytvoření dokumentace, převod dat, školení, systémové zabezpečení atd.

36

Dlouhotrvající projekty zlepšování ERP nepřináší očekávané výsledky, neboť často dochází ke ztrátě podpory ze strany koncových uţivatelů a managementu. Tito by do projektu měli být také vtaţeni, jelikoţ oni nejlépe vědí, co je třeba kde zlepšit a nezřídka vědí jakých způsobem. Implementace Samotná implementace začíná převodem původních dat systému, do nového ERP. Dále pokračuje instalací vlastního ERP systému včetně všech následujících úprav. Dále probíhá nastavení, zprovoznění a úpravy systému. Pokračuje se zaškolením jednotlivých pracovníků. Pracovníci bývají zaškolování v několika etapách. Důleţité je pracovníky správně motivovat, aby pracovníci pochopili správné fungování systému a nebáli se jej. Jistě systém nebude od začátku fungovat optimálně a tak za pomoci pracovníků bude postupně vylepšován. Došlo-li by k odporu z pohledu dobré spolupráce s koncovými uţivateli, řešení by bylo zdrţováno. Kaţdému koncovému uţivateli nového ERP přibude práce, neţ se vše podaří správně synchronizovat a budou doplněna všechna potřebná data. Nesmí docházet k tomu, aby si zaměstnanci „ohli“ nový ERP, ale aby místo toho změnili myšlení a pracovní postupy. Mají tendence tohle dělat, aby mohli pokračovat v zaběhlých, ale často neefektivních postupech. Ostrý provoz Po vlastní implementaci ERP a zaškolení pracovníků je spuštěn ostrý provoz za dohledu implementátora. Během tohoto provozu konzultační tým dodavatele dohlíţí na zpracování běţné denní agendy v novém ERP systému. Podpora konzultačního týmu je nezbytná, jelikoţ se ještě stále řeší věci, které je nutno dodělat, či předělat a přichází se na nové potřeby. Tato doba se různí dle velikosti podniku, či stupně sloţitosti zavedeného ERP. Tímto způsobem se přejde do rutinního provozu. Údrţba Součástí dodaného ERP systému, by měly být také záruka, servis, či další modularita software, čemuţ nadále můţeme říkat údrţba. V rámci záruky většinou dodavatelé systémů garantují běţný dohled a servis software, či aktualizaci verze. Velikost poskytovaných sluţeb bývá adekvátně ohodnocena, čili je 37

podmíněna zaplacením servisního poplatku. Po skončení záručního servisu, je moţné dohodnout servis pozáruční.

3.2 BPR v rámci implementace BPR je dalším typem projektů, které předcházejí, nebo často i doprovázejí implementaci ERP. Vysvětlení BPR (viz kapitola 2.3.3). Existují 3 vazby na BPR v rámci projektu implementace ERP: 1. První způsob – spočívá v tom, ţe se nejprve provede kompletní BPR a poté se přistupuje k implementaci. Toto zajišťuje, ţe se nový systém zavede na jiţ upravené procesy. Bohuţel je tento způsob velmi náročný na spotřebu času i peněz. Hlavní nevýhodou je, ţe proces BPR a implementace můţe trvat velice dlouho (klidně 2 roky). V této době se skrývá riziko, ţe mezi provedením BPR a dokončení implementace ERP můţe dojít k další změně procesů, coţ znehodnotí restrukturalizaci procesů. 2. Druhý způsob – druhý způsob spočívá v souběţném provádění implementace a BPR v rámci jednoho podniku. Tento postup znamená úsporu času a pruţnější řešení, avšak naráţí pro změnu na tyto problémy: Zákazník většinou spoléhá za zkušenosti implementátorů, kteří jim doporučí vhodné změny, tudíţ o restrukturalizaci procesů nehovoří, Je ţádána co největší angaţovanost vedení podniku, jelikoţ to má pravomoc pro provedení navrhovaných změn, Po přechodu do produktivního provozu a zhodnocení efektivnosti se projeví absence odpovědnosti za restrukturalizaci. Je totiţ z hodnocení poznat, ţe projekt byl zdrţován. 3. Třetí způsob – jeho základnou je vyuţití metainformačních systémů. Princip této metody spočívá v tom, ţe se vytvoří podnikový procesní model, ten způsobí rychlou konfiguraci parametrů systému. Pak je moţné provádět pruţnou operativní inovaci konfigurace systému, dle popsaných změn v modelu procesů, díky tomu, ţe součástí ERP balíku je metainformační systém. V České republice není tato metoda

38

běţná, jelikoţ vyţaduje veliké zkušenosti dodavatelů i uţivatelů systému procesového modelování. Projekty BPR vychází z rozkladu procesů, který definuje hlavní i vedlejší procesy. Tento rozklad můţe být v několika úrovních. definování datové/informační základny, optimalizace hlavních podnikových procesů (etapa 1), definování poţadavků na aplikační software a výběr ERP systému, uzavření smluv, nákup licencí, implementace a údrţba zvoleného ERP systému.

39

4 Reimplementace ERP systému 4.1 Znaky reimplementačních projektů Reimplementaci můţeme také nazvat „implementace druhého řádu“. Klient se z nějakého důvodu rozhodl, ţe aktuálně pouţívaný ERP systém, jiţ nadále nechce pouţívat. Takovýchto důvodů můţe být celá škála. Nutnost změny mohou vyvolat změny organizační, technologické, nutnost upgradu, změna platformy atd. Nicméně, i přes to, ţe jde o projekt téměř podobný, najdeme zde několik odlišností od tradičního zavádění ERP systému. Jelikoţ firma jiţ prošla jednou implementačním procesem je jasné, ţe jiţ disponuje zkušenostmi a stává se tedy zkušenějším a náročnějším zákazníkem. Na reimplementaci se tudíţ podílí „zkušené“ týmy ze strany zákazníka, coţ můţe bohuţel přinést více problémů, neţ kdyby se projektu zúčastnily týmy, které toto podstupují poprvé. Bez námitek by totiţ odsouhlasily navrţený postup dodavatele a jistě měli méně poţadavků. Některé poţadavky mohou být naddimenzované a takřka nesplnitelné. Je pak na obou stranách, aby našly společnou cestu shody, ke zdárnému zavedení ERP. Poţadavky, které bychom mohli poţadovat za obecné, protoţe se objevují v největším počtu, by mohly být následovné: Zákazník poţaduje funkcionalitu ERP šitou na míru podnikových procesů, které hodlá do reimplementace zahrnout, případně rozšířit, Chce otevřený ERP systém z důvodu moţnosti přidání dalších modulů typu BI, SCM, CRM atd., Zlepšit integraci sw i hw, Vysokou úroveň presenční vrstvy, Rád by zvýšil výkon při zpracování informací a dat, V neposlední řadě vyţaduje bezpečnost v oblasti správy datové základny.

4.2 Důvody vedoucí ke změně Na důvody vedoucí ke změně IS můţeme pohlíţet z několika rovin a nepřeberného mnoţství důvodů. Tyto důvody by se daly rozdělit do dvou skupin, a to z pohledu dodavatele na straně jedné a zákazníka na straně druhé. 40

Dodavatel či jinak poskytovatel, přichází s upgrady systému, nebo transformací platformy. Vydá-li dodavatel upgrade systému, přichází s novou funkcionalitou a snaţí se odstranit předchozí chyby, které systém obsahoval. Někdy upgrade není dostačující, protoţe nové procesí potřebuje jiné modulové sloţení apod. Přijde-li výrobce s novou verzí IS, nepodněcuje tím nutnou reimplementaci a přechod na novou verzi. Je na samotném uţivateli, aby si spočítal cenu projektu reimplementace v souvislosti s novou funkcionalitou a celkovým budoucím prospěchem. Z pohledu zákazníka by se dala potřeba reimplementace rozdělit ještě do dvou podskupin. Potřeba - ROLL-OUT – této moţnosti vyţívají velké, často nadnárodní firmy a často bývá pouţito při akvizicích, fúzích či rozšiřování firmy formou zřízení nové pobočky. Jde vlastně o to, ţe při tomto projektu se vytvoří obecná šablona, která odpovídá nasazení v mateřské společnosti. Tato šablona je následně „rolována“ na dceřiné společnosti. Cílem tohoto řešení je minimalizace nákladů na implementaci a správu následného stavu. Nevýhodou tohoto řešení bývá přílišná obecnost řešení, při kterém nemusí šablona odpovídat procesům v dceřiné společnosti. Mívají odlišnosti v legislativě, hloubce procesů atd. Pokud je tato odlišnost veliká, především z globálního hlediska, bývá lepší zvolit variantu tradičního přístupu a implementovat systém individuálního řešení. Potřeby další – tyto vznikají z důvodů ostatních, mezi které uvedu například nedostatečná funkcionalita systému, zastarání HW a SW, ukončení podpory provozovaného IS, či změna nejen business procesů.

4.3 Reiplementační fáze Projekty implementace a reimplementace, jak jiţ bylo řečeno, mají aţ na některé odlišnosti stejný koncept. Zcela logicky musí i projektu reimplementace předcházet vize a plánování. Zrovna tak samotná fáze implementace nového či upgradovaného ERP bývají obdobné. Na rozdíl od implementace však po plánovací fázi přichází studie „odkud kam se chceme dostat“:

4.3.1 Popis výchozího stavu Abychom věděli, jak se dostaneme k cíli, musíme zjistit, odkud půjdeme. K tomu je zapotřebí popsat stávající stav. Popis stávajícího stavu můţe být proveden několika způsoby, 41

za pomoci několika odlišných nástrojů. Po prostudování několika případů pouţití např. UML či BPMN, bych se přiklonil k popisu stavu pomocí jazyka ArchiMate, který dokáţe odlišně nasimulovat rozsah podnikového modelu. Je to nezávislý a otevřený modelovací jazyk. Grafický výstup spojuje v modelu zástupce byznysu, projektového vedoucího, architekta, klíčového uţivatele i specialistu u jednoho stolu řešící společné téma.

4.3.2 Popis cíle Na cílový stav se podíváme z pohledu společnosti. Ta si stanovuje vize a cíle na různých úrovních, takţe výsledný stav bude jejich zohledněním. Popis cíle vyhodnotíme a zmodelujeme ve stejném provedení jako je popis výchozího stavu.

4.3.3 Rozdílová analýza a roadmapa Po úvodních popisech máme představu o tom, kde jsme a kam se chceme dostat. Je tedy nutné nějakým způsobem přijít na to, jak to uděláme, respektive, jakým způsobem jsou celky od sebe odlišné. Je tedy nutné provést rozdílovou analýzu GAP. Čím větší firma, tím sloţitější řešení a více výstupů. Srovnávané činnosti můţeme rozdělit do kategorií, dle obsáhlosti. Dále pokračujeme v tom, ţe si představíme prvky z kategorií a rozhodneme se, co zůstane zachováno, co změníme, co bude úplně nové a co bude eliminováno. Po rozdílové analýze přijdeme s návrhem projektů, které potřebujeme pro přechod ze stávajícího stavu, do stavu nového tzv. roadmapou. V ní definujeme trasy, kterými za dosaţením cílů půjdeme, časové horizonty, překáţky atd.

42

Obrázek č. 7: Plánování s využitím podnikové architektury

Zdroj: http://www.systemonline.cz/clanky/podnikova-architektura.htm21

4.3.4 Implementace Zavedení a nastavení systému dle odsouhlasených dokumentů, které tvoří výstupy analýzy GAP. Nastavení je rozšířeno o případné změny, vyvstalé z poţadavků.

4.3.5 Testovací fáze Po zavedení systému je nutné systém otestovat. Rozsah testů závisí na velikosti obsaţených procesů a na poţadavcích zákazníka. Testování probíhá v různých hladinách, abychom mohli otestovat jednotlivé kroky implementace a jejich zdárné provedení. Začíná se testováním na úrovni modulů čili softwarových komponent. Toto testování provádějí vývojáři, kteří ověří správné fungování komponent, a říká se jim Unit testy.

21

Podniková architektura je cestou, jak obstát v situaci permanentní změny[on-line]. 15. 02. 2014 2014-02-15]. Dostupné z WWW: < http://www.systemonline.cz/clanky/podnikovaarchitektura.htm >. [cit.

43

Následné testy, které jsou také většinou na vývojářích, jsou testy Assembly. Tyto ověřují moţnost integrace jednotlivých komponent z předchozího kroku. Třetím krokem se testuje rozhraní mezi komponentami a jejich interakce s různými částmi systému. Také se zde testuje chování systému jako celku. Těmto říkáme systémové a integrační testy. Čtvrtý krok je z pohledu zákazníka nejdůleţitější. Zde se provádí akceptační testy a testuje se zde, zda zavedený systém splňuje všechny zákazníkovi poţadavky. Při testování musí být zachovány tyto čtyři kroky. Postupuje se od malých částí směrem k celku. Přičemţ postup na úroveň vyšší je podmíněn správným zvládnutím úrovně niţší.

44

5 Rizika 5.1 Analýza rizik Analýza rizik je nedílnou součástí všech částí projektu. Aby projekt zdárně proběhl, je nutno uvaţovat a počítat s rizikem jiţ při první úvaze o projektu. Dále se takto můţeme vyhnout spoustě nepříjemnostem a komplikacím. Řízení rizik je neustálý proces, který doprovází všechny fáze projektu. Úkolem projektového manaţera je drţet sebe i všechny zúčastněné na projektu v bdělosti a angaţovat je v procesu řízení rizik. K procesu řízení rizik nezřídka kdy bývají přizváni odborníci, kteří řízení rizik projektu podpoří. Pouţívané metody, které sniţují neurčitost provázející kaţdé riziko, jsou zaloţeny na principu posloupnosti (successive principle), tj. odhad neurčitosti se sníţí tím, ţe rozloţíme odhadovanou poloţku na menší části. Menším částem budeme říkat podřízené poloţky. Podíváme-li se na to z matematického pohledu, tak součet odchylek odhadů podřízených poloţek bude menší neţ odchylka poloţky celkové. Kvalitativní posudek rizika – kvalitativně se posuzují rizika dle důleţitosti z hlediska dopadu na projekt a pravděpodobnosti výskytu rizika. Kvalitativní posudek rozhoduje o tom, jakou strategii je vhodné pouţít ke zvládnutí jednotlivých rizik. Chování respektive strategie k postavení se k riziku mohou být zmírnění, vyloučení, přesunutí, sdílení či přijmutí rizika. Po zvolení strategie si musíme zhotovit vhodný plán odezvy. Tento plán ovlivní mnoho projektových procesů. Realizaci plánu odezvy je nutno řídit i kontrolovat, jestli v průběhu realizace není třeba plán aktualizovat, kdyţ se objeví rizika nová. Kvantitativní posudek rizika- poskytuje číselné hodnoty, které znázorňují, pomocí čísel vyjádřený dopad od těchto rizik. Účinné metody k vyhodnocení rizik z kvantitativního pohledu jsou metody Monte Carlo, pouţití rozhodovacích stromů a plánování scénářů (scenario planning). „Jestliže zjistíte mnohem více rizik, než jste očekávali, může to být potěšující zpráva. Nemůžete přece reagovat na rizika, o nichž nic nevíte. Jestliže máte příliš mnoho rizik, může to znamenat, že jste si dali důkladnou práce s identifikováním rizik“22. 22

TATE, Karen. Memory Jogger pro pokročilý management projektu. 1. vyd. Praha: Česká společnost pro jakost, 2008. s. 85. ISBN 978-80-02-02023-3.

45

Z pohledu rizikového inţenýrství, zahrnuje obecně risk management následující procesy: Analýza rizik, která se skládá z: -

Identifikace rizik (nalezení všech hrozících nebezpečí),

-

Posouzení rizik (určení předpokládaných škod a pravděpodobností),

-

Odezvy na rizika (nalezení vhodného chování, vzhledem ke zjištěnému riziku).

Sledování rizik – neustále zjišťujeme, nezměnila-li se hodnota rizika, zda nevzniklo riziko nové, či nepominulo-li nebezpečí dříve identifikované. Sledujeme, není-li nutné zavést nějaká opatření nová, jako odezvu na nově zjištěné riziko,

5.2 Metody řízení rizik Na kaţdý projekt se hodí pouţít jinou strategii risk managementu. U nás je zavedena norma ČSN IEC 62198: Management rizika, která je zaměřena na formální pravidla procesu, jeho systematičnost a úplnost provedení. Norma navrhuje a definuje pět dílčích oddílů, dle kterých postupovat. Jsou to: určování souvislostí, zjišťování rizik, posuzování rizika: o analýza rizik, o vyhodnocení rizik, o přijetí rizika, ošetření rizik, monitorování a přezkoumání rizika.

5.2.1 PMI Metodika pro risk management podle PMI je sestavena v podobě postupu analýzy rizik a shrnuta do následujících pěti bodů: plánovat management rizik, identifikovat rizika, 46

provést analýzu rizik: o kvalitativní, o kvantitativní, plánovat odezvy na riziko, monitorovat a řídit rizika.

5.2.2 SWOT Analýza SWOT se při sledování rizik můţe vyuţít kdykoliv a na téměř vše. Jedná se o silný nástroj nejen managementu, který bývá doplňován dalšími analýzami případně výpočty. Název SWOT je sloţeno z: Strenghts (silné stránky – přednosti) Weaknesses (slabé stránky – slabosti) Opportunities (příleţitosti) Treats (hrozby) Základní myšlenkou SWOT analýzy, neboli analýzy silných a slabých stránek, hrozeb a příleţitostí, je klasifikace jednotlivých faktorů, které jsou rozděleny do 4 částí. Díky tomuto lze získat nové kvalitní informace charakterizující a hodnotící úroveň jejich vzájemného střetu. Objektem zájmu této analýzy mohou být různé předměty, časové úseky, situace, atd. Pokud se zaměříme např. na implementační tým, musíme si pak poloţit následující otázky: jaké má silné stránky implementační tým, jaké má slabé stránky implementační tým, jaké příleţitosti má implementační tým, jaké hrozby čekají na implementační tým. Odpověďmi na předešle otázky následně naplníme tabulku respektive matici 2x2 prvky, nebo můţeme zpracovat jako seznam se samostatným bodovým výčtem.

47

Obrázek č. 8: SWOT analýza

Zdroj: http://cs.wikipedia.org/wiki/SWOT

23

Zásady pro provádění analýzy SWOT: analýza se musí provádět ve skupině (projektový tým) a o jednotlivých poloţkách se musí diskutovat. Tímto se zajistí komplexnost sestavení analýzy z pohledu různých stanovisek a faktů. Je-li vypracována jednotlivcem, lze ji povaţovat za individuální hodnocení předmětu analýzy, správnost vypracování vyţaduje nejedno setkání hodnotícího týmu.

5.2.3 RIPRAN RIPRAN (Risk Project Analysis), je jednoduchá empirická metoda pro analýzu rizik projektů. První verzi metody vyvinul Doc. Ing. Branislav Lacko, CSc. v ústavu automatizace a informatiky na VUT v Brně. Tato metoda chápe analýzu jako proces, coţ znamená, ţe existují vstupy do procesu, transformace vstupů na výstupy a výstupy. Metoda odpovídá poţadavkům normy ISO 10006 a respektuje zásady pro RPM dle PMI. Postupy metody jsou ve 3. verzi popsané následovně: 1) prvním krokem je připravit analýzu rizik – je stanoven projektový tým, který následně shromáţdí potřebné dokumenty pro provedení analýzy, 2) druhým krokem je identifikovat nebezpečí projektu – 23

SWOT [on-line]. 19. 02. 2014 [cit. 2014-02-21]. Dostupné z WWW: < http://cs.wikipedia.org/wiki/SWOT >.

48

projektový tým identifikuje nebezpečí a sestaví seznam. Autor doporučuje sestavovat v tabulce, kvůli přehlednosti a identifikaci provádět v týmu, za účelem zvýšení kvality dat, Tabulka č. 2: Identifikace rizik

Číslo rizika 1

2

Hrozí

Průběh

Pozn.

Mrazivé počasí březen,

Moţnost mrazivých

zpoţdění betonování.

dní 3 = 10%.

Vycházejme z podmínek jako minulý rok. Vycházejme

Období nemocí únor –

Nemocnost 20%.

březen.

z podmínek jako minulý rok.

Zdroj: vlastní tvorba. 3) třetím krokem je kvantifikovat rizika projektu – v této fázi rozšíříme tabulku z předchozího kroku o pravděpodobný výskyt scénáře a finanční hodnotu rizika, která se spočítá jako – hodnota rizika = pravděpodobnost scénáře * hodnota dopadu, Tabulka č. 3: Kvantifikace rizik dle RIPRAN

Číslo

Hrozí

Průběh

Pst

Dopad na projekt

rizika 1

Hodnota rizika

Mrazivé počasí

Moţnost

březen, zpoţdění

mrazivých dní

betonování.

9 = 30%.

Zdrţení etapy – 40%

penále 10tis./den

36 tis. Kč

= 90.000 tis. Kč.

2

Změna kapacity, Období nemocí,

Nemocnost

únor a březen.

20%.

60%

zpoţdění 1 měsíc – penále 300 tis.

180 tis. Kč

Kč.

Zdroj: vlastní tvorba. Metoda umoţňuje i verbální kvantifikaci, coţ znamená, ţe jednotlivým stavům přisoudí odpovědnou slovní váhu. Pro příklad uvádím tabulku č. 4:

49

Tabulka č. 4: Pravděpodobnost verbálně RIPRAN

Vysoká pst – VP

67 - 100%

Střední pst – SP

33 – 66%

Nízká pst – NP

0 – 32%

Zdroj: vlastní tvorba. Projektový tým si zvolí jedno z uvedených vyjádření (finanční či verbální), jelikoţ pouţití současné z praktického hlediska nebývá běţné, Tabulka č. 5: Dopad na projekt verbálně RIPRAN

Velký nepříznivý dopad na projekt – VD

Střední nepříznivý dopad na projekt – SD

Malý nepříznivý dopad na projekt – MD

- ohroţení cíle projektu - ohroţení koncového termínu - moţnost překročení celkového rozpočtu projektu - škoda více neţ 20% hodnoty projektu - škoda 0,51-19,5% z hodnoty projektu - ohroţení termínu, nákladů nebo zdrojů některé dílčí činnosti, coţ bude vyţadovat mimořádné akční zásahy do plánu projektu - škody do 0,5% z celkové hodnoty projektu - dopady vyţadující určité zásahy do plánu projektu

Zdroj: vlastní tvorba. Tabulka č. 6: Hodnocení rizikovosti RIPRAN

VD

SD

MD

VP

Vysoká hodnota Vysoká hodnota Střední hodnota rizika VHR rizika VHR rizika VHR

SP

Vysoká hodnota Střední hodnota Nízká hodnota rizika rizika VHR rizika VHR VHR

NP

Střední hodnota Nízká hodnota rizika Nízká hodnota rizika rizika VHR VHR VHR

Zdroj: vlastní tvorba. 4) Čtvrtým krokem je reagovat na rizika projektu – v tomto kroku se navrhnou a sestaví opatření, která by měli sníţit hodnotu rizika na hodnotu přijatelnou. Příklad v následující tabulce.

50

Tabulka č. 7: Návrh snížení rizika

Číslo rizika

Návrh opatření

- Předpokládané náklady

Nová hodnota rizika

- Termín realizace - Odpovědnost 1

Nákup

nemrznoucí - 50 000 Kč směs

sloţky.

- aplikace v březnu

Směsi

nakoupeno

větší

mnoţství.

- dohodnuto s technologem – Hodnota 2

Nákup vitamínů.

rizika

=

odsouhlaseno vedením

10%.

- 5 000 Kč vitamíny

Nemocnění

- nákup v prosinci

nahrazeni externisty.

- odsouhlaseno odbory

Hodnota rizika = 0.

budou

Zdroj: vlastní tvorba. Metoda RIPRAN neříká, ţe stavové hodnoty musí být zpracovávány do tabulek. Metoda doporučuje zachycení i v jiných formách v podobě psaného textu a označení body, 5) pátým krokem je posoudit rizika projektu – v tomto kroku se jiţ posuzuje celková hodnota rizika (dle zvoleného přístupu – u mě v Kč). Vyhodnocuje se rizikovost projektu a způsoby jeho realizace.

5.2.4 SLEPT Tuto analýzu se hodí provést před samotnou implementací respektive reimplementací ERP. Tato analýza je prostředek k analýze změn okolí, a proto dokáţe vyhodnotit případné změny, které mají dopad na projekt a pocházejí z určitých oblastí dle následujících faktorů: Social – sociální hledisko, Legal – právní a legislativní hledisko, Economic – ekonomické hledisko, Policy – politické hledisko, Technology – technické hledisko. Zhodnocení těchto oblastí představuje komplexní pohled na prostředí státu, kraje či obce, ve kterém hodláme projekt provést. Jde o to, ţe prostředí není stabilní a stále se mění. 51

Analýza není zaloţena na přesných výsledcích, ale zaznamenává současný stav a věnuje se stavům budoucím. Domýšlí změny a sleduje trendy, které projekt a jeho úspěch, ovlivní. Dle jednotlivých faktorů se analýza zaměřuje na následné skutečnosti: Sociální faktory: demografické charakteristiky – poukazuje například na velikost populace, geografickou polohu, věkovou strukturu obyvatel, sloţení etnické, gramotnost populace, hustotu osídlení, pracovní preference, sociálně-kulturní charakteristiky – ţivotní úroveň, rovnoprávnost pohlaví, populační politiky, dostupnost pracovních sil – dostupnost kvalifikovaných zaměstnanců, vzdělávací instituce, diverzita pracovní síly. Legislativní faktory: existence a funkčnosti zákonných norem, které mají podstatný vliv na projekt jako např.: obchodní právo, daňové zákony či legislativní opatření, rozjednaná či nehotová legislativa, kterou lze v budoucnu předpokládat, další aspekty jako – vymahatelná práva, autorská práva. Ekonomické faktory: zhodnocení makroekonomické situace – inflace, úrokové míry, obchodní bilanci, rozpočtovou bilance, směnný kurs, možnost finančních zdrojů – náklady na půjčky, bankovní systém, dostupnost úvěrů, daňové hledisko – výše daňových sazeb a jejich vývoj. Politické faktory: politická stabilita – stabilita a forma vlády, sestavení orgánů a úřadů, vliv politických osobností, vládnoucí politická strana, politicko-ekonomické faktory – postoj politiků vůči investicím, vztah ke státním firmám, postoj k privátnímu sektoru, zhodnocení externích vztahů – zahraniční angaţovanost, regionální nestabilita, politický vliv skupin. 52

Technologické faktory: nové objevy a vynálezy, výdaje na výzkum a rozvoj, rychlost morálního stárnutí, nové technologické aktivity a trendy, technologická úroveň.24

24

LACKO, B: Metody a techniky projektového řízení. Nový Jičín, 2006. s. 18. (v rámci projektu EUROMANAGER financovaného ESF).

53

6 Teorie v praxi V dnešní dynamicky se vyvíjející společnosti, která si chrání a schovává všechny důleţité informace, které vedou k zisku a jsou součástí nekonečného boje o něj, je těţké dostat se ke všem částem, které bych v případové studii potřeboval uvést. Spoustu věcí si firmy chrání a je to jejich „know-how“, proto jsem byl rád, ţe jsem částečně mohl pouţít projekt slušného rozměru. Nemohu však uvádět subjekty obou zúčastněných stran, proto je v textu uvedu jako zákazníka a dodavatele. Projektem mě provedl Ing. Jan Vajgant, který působí jako EPM manager ve společnosti, která se zabývá implementací produktů SAP. Také mi věnoval rozhovor, který je praktickým odrazem zmiňovaných pravidel.

6.1 Zákazník Zákazník je jeden z velkých masozpracujích podniků v ČR. Patří do celorepublikového řetězce několika provozoven, spojených jedním názvem a pod záštitou a.s. Zaměstnává zhruba 350 lidí a jeho roční obraty dosahují bezmála miliardy korun.

6.2 Dodavatel Jeden z největších systémových integrátorů v České republice. Jde o mezinárodní, dynamicky se rozvíjející společnost, která působí v oblasti sluţeb v oboru informačních technologií.

6.3 Představení projektu Nasazení nového ERP systému SAP. Respektive řešení S2P for Food postavené na řešení SAP Catch Weight Management pro potravinářský průmysl. Znázornění v příloze č. 1. Projekt počítal s nasazením funkcionalit jednotlivých částí informačního systému, ale kladl důraz i na celkovou architekturu řešení tak, aby nešlo pouze k nahrazení stávajícího informačního systému novým, ale aby implementace nového systému přinesla maximální moţnou míru přidané hodnoty. Toho se dosáhlo návrhem řešení pro řízení, plánování výroby, 54

odbytu a nákupu ve společnosti, ale i dodáním moderních technologií pro podporu sledování materiálového toku. Protoţe řešení poskytuje podporu všech úrovní procesů, tedy i podporu procesů vrcholového řízení, bylo nutné pro takové vrcholové a komplexní procesy zajistit kvalitní vstupní data ze všech oblastí objednatele. Evidence toku materiálu ve výrobě, skladovém hospodářství a expedici byla zajištěna prostřednictvím čárových kódů a označených obalů. Způsob evidence toku materiálu ve výrobě nemá vliv na informační systém, ale pouze na vybavení pracovišť průmyslovým HW. Informační systém byl navrţen tak, aby nebyl závislí na konkrétním nosiči informací a je tedy moţné kdykoliv změnit nosiče informací a to i na pouţití RFID čipů, bez nutnosti implementačních změn.

6.4 Rozhovor

1) Proč podnik přistoupil k reimplementaci IS? Stávající systém společnosti byl zastaralý a jiţ nevyhovoval potřebám společnosti, která se za poslední roky značně rozrostla. Původní ERP systém nepostihoval veškeré potřebné procesy a jeho další rozvoj by byl nákladný a brzy by se jiţ dostal na svoje hranice. 2) Co bylo cílem reimplementace? Cílem bylo nasadit robustní ERP systém světového formátu, který umoţní kompletní řízení a zahrnutí všech procesů společnosti. Součástí projektu také byla optimalizace a standardizace všech podnikových procesů. Bylo identifikováno cca 200 změn a přibylo asi 30 nových procesů, které si týkaly plánování i změn kompetencí v logických tocích. Z toho upřesnění 15 procesů v průběhu projektu, z nichţ bylo 8 kritických, probíhalo na nejvyšší manaţerské úrovni. Nově nasazený ERP systém SAP umoţní vše výše uvedené. Navíc tento systém nebude limitovat společnost v dalším růstu. Do budoucna lze implementovat další systémy od společnosti SAP, jako např. datový sklad a reportingový systém SAP BW. Základní 55

architektura systému byla následující. Pro pokrytí procesu v nákupu jsme pouţili technologii a prostředí informačního systému SAP a z něho vyvinuté oborové řešení pro masný průmysl S2AP pro masný průmysl. K tomuto řešení jsme dodali moduly váţní server, BIF Aplikace a Monitor pro sběr dat (viz příloha č. 2) ve výrobě a k tomu aplikaci FOM2SAP pro komunikaci s klasifikačním zařízením FOM. Architektura je zaloţena na on-line připojení vah a všech částí sběru dat do informačního systému SAP, vyjma aplikace FOM2SAP, která pracuje asynchronně. 3) Jaké byly požadavky a cíle zákazníka?

Zákazník měl poţadavků spoustu, proto za ty nejvýznamnější uvedu bodově ty nejdůleţitější: centralizace ukládání dat do jednoho systému, integrovaný systém poskytující souhrnné informace ze všech oddělení podniku, sníţení administrativní náročnosti, pořizování dat v místě jejich vzniku, ho informačního systému.

4) Jaká byla rizika projektu a jak byla ošetřena?

Implementační projekty přinášejí typická rizika. Dále jsou zmíněna rizika a jejich ošetření, která vyvstala v tomto projektu. Zákazník neměl stanoveny globální cíle projektu a jejich vyjádření ve finančních ukazatelích. Chybělo tak měřítko pro hodnocení priorit a rizik. Hrozilo tak, ţe systém bude implementován s ohledem na lokální optima a nikoliv s ohledem na výkonnost firmy jako celku. Řešení: Poskytli jsme podporu v součinnosti při stanovení cílů projektů. Za pomoci klíčových uţivatelů jsme podrobně popsaly procesy a přidali naše zkušenosti v podobě konzultací.

56

Nebyl jasně a správně popsán cílový stav a nebyli stanoveni všichni odpovědní klíčoví uţivatelé. Řešení: Provedli jsme rozpad předmětu dodání podle projektové metodologie a příručky kvality do úrovně jednotlivých business procesů tak, aby byla zcela jasná odpovědnost za proces na obou stranách. Během projektu mohly vyvstat velké změny cílového stavu, čímţ by se i protáhla doba samotné implementace. Řešení: Pro kaţdý jednotlivý business proces jsme pouţili procesní šablony, které máme ověřené provozem v jiných firmách, i přesto však mohlo dojít k neshodám a doba implementace se mohla prodlouţit. Tomuto riziku se nedá dobře předcházet, avšak ukázalo se, ţe díky pouţití správných šablon bylo prodlouţení implementace minimální. V tomto případě mohlo být obtíţnější sledování aktuálního stavu projektu a z toho plynoucí pomalá reakce na neočekávaná rizika. Řešení: Sledování stavu jednotlivých business procesů a ostatních částí předmětu dodávky bylo podpořeno naším interním informačním systémem pro řízení projektů, který je součástí ISO certifikace. Report „Stav projektu“ je generován on-line z tohoto informačního systému. Pouţitý způsob sledování a řízení projektu umoţňuje pruţně reagovat na zdrţení části projektu z vnějších příčin (např. nedostupnost klíčového uţivatele) bez ohroţení zbývajících částí. Musí být kladen důraz na dodrţování kvality a termínu vývoje. Řešení: Pouţíváme systém řízení kapacit a kvality vývoje, který pochází z metodologie „Extreme programming“ – moderní metody štíhlého programování. Veškeré procesy řízení vývoje jsou certifikovány podle ISO a dostatečně tak pokrývají riziko nedodrţení kvality. Museli jsme předcházet nedostatečné kvalitě dat pro migraci v původním stavu. Řešení: Na toto jsme pouţili tzv. časového bufferu. Zkušební migraci jsme prováděli s dostatečným předstihem a řádnou důleţitostí. Vlastní fáze projektu je pak řízena a koordinována zkušeným Senior konzultantem.

57

Metodologie řízení projektů a způsob řízení kvality jsou navrţeny tak, aby k identifikaci náhodných rizik docházelo co nejdříve a byla včas řešena. Metodologie definuje pravomoci a způsob eskalace při řešení kvalitativních neshod a rizik.

5) Jaké bylo hlavní úskalí reimplementace?

Největším úskalím bylo, ţe zákazník měl snahu o nastavení procesů a fungování nového ERP co nejpodobněji tak, jako tomu bylo u stávajícího systému, snaţil se o tzv. „ohnutí“. Konkrétně v případě SAP ERP existují tzv. best practices a standardizované procesy, kterých je doporučeno se drţet v maximální moţné míře. Nicméně kaţdá společnost je samozřejmě specifická a tak se nelze v průběhu implementace určitým úpravám a změnám standardu vyhnout. Nicméně by se nemělo jednat o pouhou kopii stávajícího systému. Všechny provedené nestandartní kroky komplikují budoucí upgrady systému. Bylo převáděno mnoho rozhraní včetně nových rozhraní pro nákup, bourárnu, výrobnu, veškeré majetkové aplikace i controlling. Nejnebezpečnější oblastí byla samotná výroba. Nemohlo se dopustit, aby z nějakého důvodu byla přerušena např. nedostatkem zásob. Byl proto zajištěn další kanál pro dostatečné předzásobení, k čemuţ pomohla i spolupráce s dodavateli, kteří nastalou situaci akceptovali a byli nápomocni. Dále jsme se obávali, ţe v takovémto prostředí, bude málo odborníků a setkáme se s obtíţnou spoluprací ze strany zákazníkových zaměstnanců, jak při popisu procesů a nových poţadavků, tak při samotné implementaci. Nakonec se ukázalo, ţe obavy byly předčasné. Zákazník sice neměl moc silných klíčových uţivatelů, ale to se nakonec nestalo překáţkou. Ukázalo se, ţe kvalita předčila kvantitu.

6) Jaké byly přínosy pro zákazníka? Jelikoţ zákazník přecházel z menšího, pro něj jiţ absolutně nedostačujícího systému, bylo těchto přínosů velice. Rázem se pro něj stala dostupná okamţitá a aktuální data pro manaţerské plánování a rozhodování. Všechny klíčové podnikové oblasti začali sdílet informaci. Zajistil se prostor pro další růst firmy díky novému způsobu řízení. Zlepšila se také komunikace a spolupráce se zákazníky, díky schopnosti přijímat a zpracovávat odvolávky pomocí webEDI. Dosáhlo se i zdokonalení řízení skladů a optimalizace obrátkovosti zásob. 58

Za přínosy vyplívajícími přímo z integrace jednotlivých procesních oblastí bych mohl jmenovat následující. Začalo být moţné analyzovat skutečné náklady a výnosy produktů a tím efektivně řídit portfolio produktů s maximalizací realizované marţe. Skutečné náklady a plánované náklady začaly být zřejmé i ve výrobě a na základě těchto vyhodnocení se začali přijímat opatření ke sníţení nákladů na výrobu. Provedli jsme také automatizaci administrativní práce a tím sníţili náklady.

7) Provádí se při reimplementaci nějaké analýzy rizik jako je tomu při zavádění nového IS. Mám na mysli např. analýzu SWOT? Já jsem se s tím v rámci firmy setkal pouze jednou a to se jednalo o specifický projekt. Zákazník chtěl pomoci se specifikací matice od nás, ale vzhledem k neznalosti prostředí jsme nebyli moc uţiteční. Jelikoţ uţ existuje mnoho oborových řešení a šablon pro nasazování IS, je mnohé usnadněno. Také zákazníci jiţ mají v hlavě jasněji a řídí se většinou analýzami, které vznikli před prvotní instalací a v průběhu je vylepšovali.

8) Jaké byli fáze projektu a jak probíhal? Pominu-li samotnou poptávku zákazníka, coţ se do projektových fází počítat nedá, projekt probíhal na úrovni klasického modelu ASAP Roadmap (její popis přikládám do přílohy č. 3). Myslím si, ţe o průběhu a jeho úskalích se rozpovídat nemusím, jelikoţ by to bylo na dlouhou dobu. Vţdy jsou nějaké překáţky a vţdy jsou nějaké bortící se hranice. Pro představu ideálního časového průběhu projektu poskytuji zjednodušený Ganttův diagram (Příloha č. 4).

59

6.5 Rizika projektu Během projektu můţeme narazit na dalších mnoho základních rizik a přitom jejich ošetření nebývá sloţité. Podívám se na tyto rizika dle jednotlivých skupin. Jejich neúplný výčet můţe být následovný: Finančně obchodní Jelikoţ tyto projekty bývají časově dosti náročné, je třeba počítat s oboustrannou solventností. Je nutné dodrţovat platbu záloh a částečných faktur, aby se ani jeden z účastníků nedostal do problémů a bylo tak znemoţněno pokračovat. Často bývá uzavřena nereálně optimistická smlouva, která můţe být dokonce vzhledem k cíli špatně definovaná. Je zřejmé, ţe projekt můţe být na základě špatných smluv předčasně ukončen i ze strany zákazníka. Proto je nutné ke smlouvě přistupovat se vší opatrností a obezřetností. Nechat schválit na několika úrovních vedení a nebát se poradit se se všemi budoucími zúčastněnými. Problémy tohoto typu často vyvstanou, pokud je obchodník velmi horlivý a chce smlouvu uzavřít za kaţdých okolností. Lze to takto někdy udělat např. kvůli referencím, ale to jiţ firma musí počítat s proklamovanou ztrátou. Řízení projektu a s ním spojená rizika Problémy začínají s tím, ţe jsou nedostatečně popsané a určené zdroje pro projekt. Ty se pak přenáší na účastníky a mohou pokračovat v chybách v řízení. Manaţeři se začínají obávat špatnému provedení tak u nich můţe propukat přenášení viny na někoho jiného. Tím vzniká nedůvěra mezi řešiteli, ale i mezi zákazníkem a řešitelem. Vliv na to má i špatně sloţený tým, který následně zpoţďuje termíny a začíná se protahovat celý projekt. Vzhledem k tomu, ţe v dnešní době je tlačeno na to, aby práce byla hotova co nejdříve, začínají tomuto posléze propadat i nejen řešitelé. Je nutné si vymezit správné mnoţství času na to, aby byly dobře popsány a určeny zdroje. V ideálním případě by bylo vhodné dvojí kontroly, za kterou se dá povaţovat to, ţe by na řešení participoval ve všech případech a celém rozsahu i specialista na procesy ze strany zákazníka. Pokud by se narazilo na rozpor, je nutné jej včas opravit a prezentovat dál. Nesmí docházet k rozporům mezi implementátorem, řešitelským týmem a zákazníkem. Při zjištění rozporu, by bylo vhodné zváţit výměnu účastníků ať na jakékoliv straně, ku prospěchu oběma. 60

Rizika spojená s řešeným projektem Řešitelský tým musí být sestaven tak, aby byla dostatečná odbornost všech řešitelů, nebude-li tomu tak, je moţné, ţe někteří aktéři se stanou nezodpovědnými. Budou-li pouţity nové a neodzkoušené technologie a produkty, opět můţe dojít k selhání a v lepším případě k nedodrţení termínu ukončení projektu. Ostatně nedodrţení termínu je jedno z největších rizik na prováděném projektu. Posuny termínu mohou být způsobeny nejrůznějšími aspekty, takţe nejen kvůli technickým problémům. Myslím si, ţe komunikace mezi účastníky je tím pravým meritem pro úspěšné provedení projektu. Jak je z předchozích kapitol jasné, problémy v projektu mohou způsobit nejen interní záleţitosti. Problémy můţe způsobit i dodavatel SW a HW, který není vázám smluvními pokutami. Toto neusnadňuje ani zákazník svými poţadavky, které vznáší v průběhu provádění projektu. Poţadavky mohou být přehnané i nesplnitelné. Leckdy se stane, ţe řešitelský tým se snaţí zákazníkovi vyhovět a udělat či nastavit modul tak, aby odpovídal poţadavků a nakonec je toto stejně „shozeno ze stolu“. Rizika specifická pro reimplementaci Jedno z největších a typických rizik je, ţe zákazník s integrátorem musí udrţovat v běhu dva různé systému. Aţ do doby přepnutí nového systému do provozní fáze se tedy udrţují dvě různá řešení. Členové řešitelského týmu mohou rázem v podniku v rámci supportní smlouvy pracovat pro stávající systém. Coţ můţe vyvolat problémy s nedostatečnou kapacitou i rozpočtovým krytím. Je pro ně těţké zpracovávat změny do obou systémů současně a sdílet zdroje. Je to pro ně dvojí práce, musí udrţovat starý systém a pracovat také na řešení novém. Na straně zákazníka nesmí dojít k tomu, aby „usnul na vavřínech“ kvůli tomu, ţe si implementaci prvního řádu zvládl. V implementaci druhého řádu, se toto můţe lehce projevit v podobě neúplného dodrţování zásad a přehlíţení v postupech. Samozřejmě toto vede k neúspěchu celého projektu. Při tomto je také vhodné, opustit od vlastní metodologie, protoţe se mohou setkat s překryvem rozhodovacích pravomocí, coţ způsobuje problémy hlavně v operativním řízení projektu.

61

Oproti implementaci se na řešení podílí také lokální IT oddělení zákazníka. Na rozdíl od implementace, která je v rukou implementátora, musí zde spolupracovat a často mají pocit, ţe všemu rozumí. Tito zaměstnanci nemívají zkušenosti s velkými projekty, ale i přes to v projektech zastávají důleţitou roli. Často také mají zodpovědnost vůči kritickým aktivitám. Vlivem toho můţe člověk s omezenou kompetencí sestavit špatnou analýzu, která můţe způsobit návrat projektu k analýze.

6.6 Očekávání zákazníka Do kaţdé implementace přichází zákazník s nejednotným a neuceleným očekáváním. Je nutné si uvědomit, ţe přichází s poţadavky více zájmových skupin. Je tedy jasné, ţe kaţdá skupina má jiná očekávání a poţadavky. Můţu říci, ţe kaţdá skupina přináší specifické riziko, vzhledem k tomu co očekává, které můţe znemoţnit úspěšné provedení implementace systému. Můţeme je rozdělit do 4 skupin. 1) vedení podniku a vlastníci Tito neovlivňují samotnou implementaci, ale jsou jedním z nejvíce zainteresovaných objektů, co se týká kontroly výkonnosti systému po určitém časovém období. Očekávají zvýšení trţní hodnoty podniku a úspory ve vybraných provozních sférách. 2) vedení projektu Vedení projektu v čele s manaţerem projektu ze strany zákazníka, se zaměřuje na dodrţení stanoveného projektového plánu. Jak z hlediska časového období, tak dodrţení finančního rozpočtu. Hlídají, aby nedošlo k navýšení rozpočtu z důvodů např. tzv. víceprací. 3) Účastníci aktivně se podílející na projektu Mezi tyto účastníky patří klíčoví uţivatelé neboli lokální IT oddělení. Očekávání této skupiny je spíše motivační. Bývají motivování tím, ţe díky novému IS, jim do budoucna bude ulehčena práce. 4) Ostatní zaměstnanci V této skupině uţ je očekávání zcela rozdílné a záleţí na mentalitě kaţdého. Pokud jsou zaměstnanci vzdělaní, či „chytří“ lidé, kteří povaţují nový IS za nástroj k dosaţení lepších výsledků a větší prosperity, budou od nového systému očekávat, ţe jim usnadní práci a zlepší pracovní podmínky k dalšímu růstu.

62

Naopak, je-li firma tvořena zaměstnanci, kteří jsou rádi v zaběhnuté situaci a uţívají si klidu v „molochu“, se mohou začít obávat o svá místa, vzhledem k tomu, ţe jedním z cílů implementace bývá zvýšení efektivnosti práce.

6.7 Postup pro analýzu rizik V praxi jsem se dozvěděl, ţe na analýzy typu SWOT se příliš „nehraje“. U společnosti, u které jsem prošel projektem, jsou takovéto analýzy řešeny tzv. Blueprintem, coţ je ve skutečnosti podrobný popis stávajícího stavu procesů a návrh dle oborových šablon, do kterých jsou stávající procesy napasovány. Chování systémů mají jiţ odzkoušené a postupují dle ověřených standardů, směrnic a norem. Velmi mě zaujala vcelku jednoduše vypadající metoda RIPRAN. Myslím si ovšem, ţe tak jako všechno co vypadá lehce, takové není, i tato metoda má úskalí v podrobném popisu problému rizika, či vůbec samotná indikace problémů. Je jasné, ţe takovýto rejstřík nepůjde naplnit všemi problémy, které mohou během průběhu projektu vyvstat, protoţe je příliš mnoho proměnných. Vybral jsem si několik náhodných rizik napříč projektem a zhodnotil je zvolenou metodou RIPRAN.

6.7.1 Příprava analýzy rizik V první řadě se musí sestavit tým, který potřebnou analýzu provede. Určí a rozdělí si kompetence a pravomoci. V druhé řadě se musí připravit všechny potřebné dokumenty a poklady k provedení samotné analýzy. Řešitelský tým se domluví na hodnotících stupnicích, kontrolních seznamech a o prezentaci dosaţených výsledků kompetentním osobám. Vstupem pro analýzu rizik se stane popis konkrétní metody, dále nějaké vhodně koncipované formuláře a informace, které budou souviset s analýzou rizik.

63

Výstupem této fáze bude časový plán prováděné analýzy, sestavený tým a prezentace do budoucna pouţitých postupů.

6.7.2 Identifikace rizika Po synchronizaci řešitelského týmu a dokončení přípravy se můţe začít s realizací. Řešitelský tým zkontroluje popis a fáze projektu a na základě zkušeností z jiných projektů obdobného směru provede prognózy moţných scénářů. V podstatě se zaměří na vnější a vnitřní vlivy, které by mohly zasáhnout do realizace a oddálit ji, či dokonce znemoţnit. Vstupy pro tuto fázi budou popis projektu (v mém případě by to mohl být Blueprint), data z minulých projektů v podobě nějakých statistik chyb a nejčastějších příčin. Dále tomu budou prognózy tušených vnitřních a vnějších vlivů a v neposlední řadě, zkušenosti řešitelského týmu. Jen bych podotkl, ţe by bylo vhodné, aby řešitelský tým nestanovoval moţné vlivy jen v rámci skupiny, ale bylo by vhodné, aby konzultace prováděl napříč strukturou podniku. Výstupem tohoto bloku bude seznam dle RIPRAN – Hrozba – Scénář doplněný o poznatky případně připomínkami. Tabulka č. 8: Hrozba - Sčénář

Riziko č. 1 2

Hrozba

Scénář

Pozn.

Nedodrţení termínu vývoje. Nedodrţení termínů nastavování jednotlivých business procesů.

Vývoj nejde dle plánu z důvodu „vyšší moci“. Nastavování jednotlivých procesů nepůjde hladce. Můţe se stát, ţe data po migraci nebudou správně konfigurována. Pokud se sejde několik nemocí najednou, nebude dostatek kvalifikovaných pracovníků V případě, ţe nebude HW kompletní, nelze realizovat Během realizace dojde k poţadavkům na změnu cíle, coţ bude

Statistické problémy z min. projektů

3

Nedostatečná kvalita dat po migraci.

4

Během zimních měsíců zvýšená nemocnost.

5

Dodavatel nedodrţení termín dodání HW.

6

Změna cílového stavu některých procesů.

64

Historická data. Nový modul SAP.

Moţnost chřipkové epidemie. Občasný problém v dodávkách. Nemůţeme ovlivnit.

7

Špatná spolupráce s klíčovými uţivateli.

8

Časová indispozice realizačního týmu ze strany zákazníka.

9

Krátká doba potřebná k realizaci projektu.

10

Během letních měsíců je více poţadavků na čerpání dovolené ze strany zaměstnanců.

mít vliv na změnu procesů a následné nastavování komponent. Nebudou-li klíčoví uţivatele spolupracovat v dostatečné míře, či budou-li nedobře motivování, můţe dojít k prodlouţení trvání projektu. Během realizace implementace je jisté, ţe zákaznický tým bude pracovat také na jiných úkolech, neţ na samotné implementaci. Zákazníkem určená doba potřebná k implementaci. V případě komplikací můţe dojít k selhání a nedodrţení termínu. Pokud se sejde několik poţadavků na čerpání dovolené najednou, bude hrozit nedostatečný počet kvalifikovaných sil.

Nemůţeme ovlivnit.

Vytvoření motivačního plánu.

Zákazník určil hranice pro dokončení.

Nelze ovlivnit čerpání dovolené u zákazníka.

Zdroj: vlastní tvorba.

6.7.3 Kvantifikace projektových rizik V tomto kroku se pouţijí výstupy z minulého kroku a ohodnotí se jednotlivá rizika zvoleným způsobem. Ohodnotí se pravděpodobnosti scénářů, rozsahy moţných vzniklých škod, dále se vyhodnotí míra rizika a na základě procentuálního a peněţního ohodnocení se přiřadí kaţdému riziku ohodnocení dle matice RIPRAN (kapitola 5.2.3. str. 49). Já jsem si zvolil ohodnocení procentuální pravděpodobnosti a hodnotě rizika v tis. Kč. Toto bude zásadním krokem celé analýzy, protoţe výstupy z této etapy ovlivní rozdělení rizik dle hodnot rizik a pokud toto špatně zařadíme, můţeme způsobit škody i samotnému projektu. Můţe se totiţ stát, ţe některé riziko bude podhodnoceno a v důsledku napáchá nejvíce škod.

65

Tabulka č. 9: Ohodnocení scénářů

Rizi ko č.

Hrozba

Scénář

Pst

1

Nedodrţení termínu vývoje.

Vývoj nejde dle plánu z důvodu „vyšší moci“.

20 %

2

Nedodrţení termínů nastavování jednotlivých business procesů.

Nastavování jednotlivých procesů nepůjde hladce.

30 %

3

Nedostatečná kvalita dat po migraci.

4

Během zimních měsíců zvýšená nemocnost.

5

Dodavatel nedodrţení termín dodání HW.

6

Změna cílového stavu některých procesů.

7

Špatná spolupráce s klíčovými uţivateli.

V případě, ţe nebude HW kompletní, nelze realizovat

Časová indispozice realizačního týmu ze strany zákazníka.

8

Můţe se stát, ţe data po migraci nebudou správně konfigurována. Pokud se sejde několik nemocí najednou, nebude dostatek kvalifikovaných pracovníků

9

Krátká doba potřebná k realizaci projektu.

10

Během letních měsíců je více poţadavků na čerpání dovolené ze strany zaměstnanců.

Během realizace dojde k poţadavkům na změnu cíle, coţ bude mít vliv na změnu procesů a následné nastavování komponent. Nebudou-li klíčoví uţivatele spolupracovat v dostatečné míře, či budou-li nedobře motivování, můţe dojít k prodlouţení trvání projektu. Během realizace implementace je jisté, ţe zákaznický tým bude pracovat také na jiných úkolech neţ na samotné implementaci. Zákazníkem určená doba potřebná k implementaci. V případě komplikací můţe dojít k selhání a nedodrţení termínu. Pokud se sejde několik poţadavků na čerpání dovolené najednou, bude hrozit nedostatečný počet kvalifikovaných sil.

80 % 10 % 10 %

Dopad na projekt Zpoţdění 5 – 10 dnů. Penále 200 tis. Kč Zpoţdění 5 dnů. Penále 100 tis. Kč Zpoţdění 5 dny. Penále 100 tis. Kč Zpoţdění 1 den. Penále 20 tis. Kč Zpoţdění 1 den. Penále 20 tis. Kč

Hodnota rizika 40 tis. Kč

30 tis. Kč 80 tis. Kč 2 tis. Kč 2 tis. Kč

20 %

Zpoţdění 2 dny. Penále 50 tis. Kč

10 tis. Kč

10 %

Zpoţdění 2 dny. Penále 50 tis. Kč

5 tis. Kč

20 %

Zpoţdění 5 dnů. Penále 100 tis. Kč

20 tis. Kč

40 %

Zpoţdění 15 dnů. Penále 400 tis. Kč

160 tis. Kč

10 %

Zpoţdění 2 dny. Penále 50 tis. Kč

5 tis. Kč

Pouţijeme formulář ohodnocení scénářů a přiřadíme mu verbální ohodnocení dle tabulky RISK studie RIPRAN matice 3x3.

Tabulka č. 10: Verbální ohodnocení scénářů

Číslo

Hrozba

Scénář

Pst

66

Dopad na

Hodnota

rizika 1 2

Nedodrţení termínu vývoje. Nedodrţení termínů nastavování jednotlivých business procesů.

3

Nedostatečná kvalita dat po migraci.

4

Během zimních měsíců zvýšená nemocnost.

5

Dodavatel nedodrţení termín dodání HW.

6

Změna cílového stavu některých procesů.

7

Špatná spolupráce s klíčovými uţivateli.

8

Časová indispozice realizačního týmu ze strany zákazníka.

9

Krátká doba potřebná k realizaci projektu.

10

Během letních měsíců je více poţadavků na čerpání dovolené ze strany zaměstnanců.

Vývoj nejde dle plánu z důvodu „vyšší moci“. Nastavování jednotlivých procesů nepůjde hladce. Můţe se stát, ţe data po migraci nebudou správně konfigurována. Pokud se sejde několik nemocí najednou, nebude dostatek kvalifikovaných pracovníků V případě, ţe nebude HW kompletní, nelze realizovat Během realizace dojde k poţadavkům na změnu cíle, coţ bude mít vliv na změnu procesů a následné nastavování komponent. Nebudou-li klíčoví uţivatele spolupracovat v dostatečné míře, či budou-li nedobře motivování, můţe dojít k prodlouţení trvání projektu. Během realizace implementace je jisté, ţe zákaznický tým bude pracovat také na jiných úkolech neţ na samotné implementaci. Zákazníkem určená doba potřebná k implementaci. V případě komplikací můţe dojít k selhání a nedodrţení termínu. Pokud se sejde několik poţadavků na čerpání dovolené najednou, bude hrozit nedostatečný počet kvalifikovaných sil.

projekt

rizika

NP

MD

NHR

NP

SD

NHR

VP

SD

SHR

NP

MD

NHR

NP

MD

NHR

NP

MD

NHR

NP

SD

NHR

NP

SD

NHR

SP

VD

VHR

NP

ND

NHR

Zdroj: vlastní tvorba. Z tohoto soupisu bych udělal tři seznamy, s tím, ţe bych seznamy rozdělil dle dosaţené hodnoty rizika od NHR po VHR a pokračoval dále.

6.7.4 Snížení rizika 67

Vstupem pro tento blok je verbální ohodnocení scénářů. Podle vzniklého rizika se můţeme rozhodnout, jestli malé riziko je akceptovatelné, či jej budeme chtít ještě sniţovat. U velkých rizik je samozřejmostí, ţe se vypracuje scénář na sníţení rizika, nebo dokonce jeho eliminaci.

Tabulka č. 11: Regist rizik

ID

Návrh opatření Pouţití časového bufferu. Pouţití více zdrojů.

3 9

Nová hodnota rizika

Náklad na opatření

Vlastník

Termín zavedení

Začátek termínu Rizika

Konec termínu rizika

NHR

5 tis. Kč

Vývoj

28.6.2014

30.6.2014

20.7.2014

NHR

40 tis. Kč

Realizace

28.6.2014

10.7.2014

13.1.2015

Zdroj: vlastní tvorba.

6.7.5 Celkové hodnocení rizika Toto je konečná fáze prováděné analýzy. V této fázi se ohodnotí celý projekt a zjistí se, zdali je z hlediska akceptovatelného rizika reálný. V celkovém hodnocení jsou porovnány všechny nasbírané hodnoty u všech rizik. Následně se hodnotí časové rozloţení rizik v průběhu projektu. Dále se zkontroluje Check list analýzy, coţ je kontrolní list pro kontrolu, zdali proběhly všechny kroky. Konečným výstupním dokumentem je zpráva o průběhu analýzy. Z pohledu rizikovosti je projekt, který jsem pouţil bez větších rizik a po eliminaci nejhlavnějších problémů bych tento projekt mohl doporučit k realizaci.

68

Závěr Projektový management nejen rizik, je v dnešní době stále jistě aktuálním tématem. Projektové řízení jako poměrně mladá disciplína se stále vyvíjí a roste. Je to nejen tím, ţe technologie a poţadavky se stále mění, ale i tím, ţe chceme dosahovat lepších a rychlejších výsledků. Na podniky působí spoustu okolních změn a v dnešní konkurenční době musí být stále ostraţití a obezřetní. Mít schopný projektový tým, který v těchto podmínkách dokáţe skvěle řídit rizika projektu, je jistě velikou konkurenční výhodou. Zrovna tak je nutné, aby se podnikový IS udrţoval v dobré kondici a byl prospěšný ve všech sférách. Dnes uţ si podniky dokáţí představit, co potřebují a dokáţí se odhodlat k novým krokům, coţ často bývá reimplementace. Podniky totiţ ví, ţe investice do tohoto projektu se vyplatí. Není uţ tomu totiţ jako v 90.tých letech, kdy podniky nevěděly, co mají očekávat a implementátoři zas neměli tolik zkušeností. Cílem práce bylo analyzovat příčiny vzniku reimplementace, porovnat implementaci s reimplementací a navrhnout postup pro analýzu rizik. Děkuji velice Ing. Vajgantovi, ţe mi ukázal jak teorie, kterou jsem popsal v kapitolách před, skutečně funguje v praxi. Díky němu jsem se i utvrdil v některých východiscích, potřebných k samotnému posouzení problematiky. Vyzdvihnu hlavně ta, která jsou spojena přímo se zákazníkem, ať se jedná o důleţitost podpory od top managementu, či pochopení rolí v projektu. Zjistil jsem, ţe velkým specifikem reimplementací je očekávání ze strany zákazníka, který mnohdy přichází s přehnanými a nesplnitelnými poţadavky. Je to i díky tomu, ţe to není jeho první projekt, takţe implementaci druhého řádu povaţuje za banalitu a trpí syndromem přehnané sebedůvěry. Dále jsem zjistil, ţe i zdánlivě jednoduše vypadající nástroj na řízení rizik jako je empirická RIPRAN metoda od Doc. Lacka, můţe velice pomoci, je-li správně aplikovaná a přistupuje-li se k ní s pečlivostí a obezřetností. Tato metoda je dle mého názoru vhodná na soft projekty, nicméně nelze v podniku uzavřít řízení rizik pouze dosazením této metody. Je nutné ji do svého modelu zakomponovat, seznámit s ní všechny zúčastněné a do budoucna ji doplňovat a zdokonalovat.

69

Seznam použitých zdrojů Monografie [1] SVATÁ, Vlasta. Projektové řízení v podmínkách ERP systémů. 3. vyd. Praha: Oeconomica, 2007. 142 s. ISBN 978-80-245-1183-2. [2] DOUCEK, Petr. Řízení projektů informačních systémů. 1. vyd. Praha: Professional Publishing, 2004. 162 s. ISBN 80-86419-71-1. [3] HAMMER, Michael, CHAMPY, James. Reengineering the Corporation: A Manifesto for Business Revolution. 1. vyd. New York: HarperCollins Publishers, 2003. 272 s. ISBN-13 9780060559533. [4] DOUCEK, Petr. Informační management. 1. vyd. Praha: Professional Publishing, 2010. 252 s. ISBN 978-80-743-1010-2. [5] SCHWALBE, Kathy. Řízení projektů v IT. 1. vyd. Brno: Computer press,a.s., 2011. 632 s. ISBN 978-80-251-2882-4. [6] SINEK, Miloslav a kol. Manažerská ekonomika. 5. vyd. Praha: Grada Publishing a.s., 2011. 471 s. ISBN 978-80-247-3494-1. [7] A guide to the project management body of knowledge: PMBOK®guide – 4th ed. Newtown Squere, PA, USA: PM Institute, 2008. 459 s. PA 19073-3299 USA. [8] DOLEŢAL, Jan, MÁCHAL, Pavel, LACKO, Branislav a kol. Projektový management podle IPMA.1. vyd. Praha: Grada Publishing, 2009. 507 s. ISBN 97880-247-2848-3. [9] ROSENAU, Milton D. Řízení projektů. 1. vyd. Praha: Computer Press, 2000. 360 s. ISBN 80-7226-218-1. [10] FIALA, Petr. Projektové řízení – modely, metody, analýzy. 1. vyd. Praha: Professional Publishing, 2004. 276 s. ISBN 80-86419-24-X. [11] TATE, Karen. Memory Jogger pro pokročilý management projektu. 1. vyd. Praha: Česká společnost pro jakost, 2008. 150 s. ISBN 978-80-02-02023-3. [12] SVOZILOVÁ, Alena. Projektový management. 2., aktualiz. a dopl. vyd. Praha: Grada, 2011, 380 s. Expert (Grada). ISBN 978-802-4736-112. [13] TICHÝ, Milík. Ovládání rizika: analýza a management. Vyd. 1. Praha: C. H. Beck, 2006, xxvi, 396 s. Beckova edice ekonomie. ISBN 80-717-9415-5. [14] SMEJKAL, Vladimír. Řízení rizik ve firmách a jiných organizacích. 2., aktualiz. a rozš. vyd. Praha: Grada, c2006, 296 s. Expert (Grada). ISBN 80-247-1667-4.

70

[15] TAYLOR, James. Začínáme řídit projekty. 1. vyd. Brno: Computer Press, 2007. 215 s. ISBN 978-80-251-1759-0. [16] BARKER, Stephen; COLE Rob. Projektový management pro praxi. 1. vyd. Praha: Grada Publishing, 2007. 155 s. ISBN 978-80-247-2838-4

Odborná periodika [17] LACKO, B: Metody a techniky projektového řízení. Nový Jičín, 2006. 51 s. (v rámci projektu EUROMANAGER financovaného ESF).

Elektronické zdroje [18] VLACH, Míra. Projektové řízení [on-line]. 29. 3. 2010. Dostupné z WWW: < http://www.mira-vlach.cz/projektove-rizeni-definice>. [19] KLUSOŇ, Martin. PRINCE2, nebo PMI [online]. 25. 3. 2012 [cit. 2013-02-18]. Dostupné z WWW: < http://www.systemonline.cz/sprava-it/prince2-nebo-pmi.htm>. [20] ERP and More! [on-line]. [cit. 2014-04-05]. Dostupné z WWW: < http://www.erpandmore.com/erp-reference/erp-history/>. [21] supplier relationship management (SRM) [online]. [cit. 2014-02-03]. Dostupné z WWW: < http://searchsap.techtarget.com/definition/supplier-relationshipmanagement>. [22] ČSN ISO 10006 ED.2, Management jakosti – Směrnice pro management jakosti projektů, Praha: Český normalizační institut, 2004. 35 s. Třídící znak 01 0333. [23] DVOŘÁK, Drahoslav. Využití CPM v plánování a řízení projektů. [on-line] 7/2004. [cit. 2014-02-03]. Dostupné z WWW: . [24] PERT a CPM. [on-line]. 25. 7. 2001 [cit. 2014-02-03]. Dostupné z WWW< http://www.kip.zcu.cz/kursy/svt/svt_www/6_soubory/6_6_2.html>. [25] Forecast overview: Public cloud services Worldwide[on-line]. 26. 12. 2013 [cit. 2014-01-10]. Dostupné z WWW: < https://www.gartner.com/ >. [26] Proč SOA nemá alternativu [on-line]. 19. 1. 2014 [cit. 2014-01-19]. Dostupné z WWW: < http://www.systemonline.cz/sprava-it/proc-soa-nema-alternativu.htm >. [27] Podniková architektura je cestou, jak obstát v situaci permanentní změny[on-line]. 15. 02. 2014 [cit. 2014-02-15]. Dostupné z WWW: < http://www.systemonline.cz/clanky/podnikova-architektura.htm >. [28] SWOT [on-line]. 19. 02. 2014 [cit. 2014-02-21]. Dostupné z WWW: < http://cs.wikipedia.org/wiki/SWOT >.

71

[29] PRÁZA, Kamil. Synergická symfonie ERP a BI [on-line]. Dostupné z WWW: < http://www.erpforum.cz/erp-trendy/synergicka-symfonie-erp-a-bi.html>. [30] KOŠŤÁL, Jiří, VYSLOUŢIL, Petr. Rizika při výběru a implementaci podnikových informačních systémů [on-line]. Dostupné z WWW: < http://www.odbornecasopisy.cz/index.php?id_document=32251.1210-9592>. [31] HRUBÝ, Přemysl. Jak správně realizovat přechod na nový ERP systém. [on-line]. Dostupné z WWW: . [32] NOVÁK, Jiří. Největší překážky při implementaci ERP systému [on-line]. Dostupné z WWW: < http://www.ictmanazer.cz/2012/03/nejvetsi-prekazky-pri-prvniimplementaci-erp-systemu/>. [33] FOUSEK, Vlastimil. Trendy ovlivňující vývoj ERP systémů na českém trhu [on-line]. Dostupné z WWW: < http://www.systemonline.cz/erp/trendy-ovlivnujici-vyvoj-erpsystemu-na-ceskem-trhu-1.htm>. [34] Plán projektu [on-line]. Dostupné z WWW: < https://managementmania.com/cs/planprojektu>.

72

Seznam obrázků Obrázek č. 1: Schéma ţivotního cyklu projektu ....................................................................... 15 Obrázek č. 2: Vodopádový model ţivotního cyklu projektu .................................................... 17 Obrázek č. 3: Spirálový model ţivotního cyklu projektu ......................................................... 18 Obrázek č. 4: Metamodel nasazení síťového modelu............................................................... 19 Obrázek č. 5: Jak projekt skutečně funguje .............................................................................. 21 Obrázek č. 6: Referenční model architektury SOA .................................................................. 32 Obrázek č. 7: Plánování s vyuţitím podnikové architektury .................................................... 43 Obrázek č. 8: SWOT analýza ................................................................................................... 48

Seznam tabulek Tabulka č. 1: Srovnání Prince2 a PMBOK .............................................................................. 24 Tabulka č. 2: Identifikace rizik ................................................................................................. 49 Tabulka č. 3: Kvantifikace rizik dle RIPRAN .......................................................................... 49 Tabulka č. 4: Pravděpodobnost verbálně RIPRAN .................................................................. 50 Tabulka č. 5: Dopad na projekt verbálně RIPRAN .................................................................. 50 Tabulka č. 6: Hodnocení rizikovosti RIPRAN ......................................................................... 50 Tabulka č. 7: Návrh sníţení rizika ............................................................................................ 51 Tabulka č. 8: Hrozba - Sčénář .................................................................................................. 64 Tabulka č. 9: Ohodnocení scénářů ........................................................................................... 66 Tabulka č. 10: Verbální ohodnocení scénářů ........................................................................... 66 Tabulka č. 11: Regist rizik........................................................................................................ 68

Seznam grafů Graf č. 1: Vývoj na trhu BPO ................................................................................................... 30

Seznam příloh Příloha č. 1: Vyuţití oborového řešení SAP CWM Příloha č. 2: BIF aplikace a BIF Monitor Příloha č. 3: ASAP Roadmap Příloha č. 4: Ganttův diagram případového projektu

73

Přílohy 1Příloha č. 1 Využití oborového řešení SAP CWM Řešení S2AP for Food je postaveno na oborovém řešení SAP Catch Weight Management pro potravinářský průmysl. SAP Catch Weight Management (SAP CWM) vychází z mySAP Suite.

mySAP Suite

Komplexní sada procesů pro řešení podnikových požadavků SAP CWM

Sada procesů a funkcí pro potravinářský průmysl S2AP for Food

Sada procesů a funkcí pro masný průmysl SAP for Z

Individualizované zákazníka

řešení

pro

SAP CWM poskytuje specifické funkce pro komplexní poţadavky pro zákazníky v spotřebitelském

průmyslu,

zejména

pro

potravinářství.

Specifické

poţadavky

v potravinářství jsou dány faktem, ţe materiály (poloţky/artikly) pouţívané skrz celý zásobovací řetězec si mohou nést dvě nezávislé měrné jednotky (kilogramy a kusy). Navíc v zásobovacím řetězci hraje důleţitou roli forma ocenění. Ocenění v potravinářství váţe pouze na jednu měrnou jednotku, v případě masných surovin měrnou jednotku váhy. Z tohoto důvodu SAP CWM poskytuje procesy a funkce k tomu aby umoţnil průchod materiálu s dvěma měrnými jednotkami celým zásobovacím řetězcem (prodej a distribuce, nákup, skladování, výroba a řízení kvality). SAP CWM také obsahuje funkce ocenění, skladového účetnictví a plně integruje další moduly systému SAP jako je finanční účetnictví a controlling. Oborové řešení pro masný průmysl S2AP for Food obsahuje nástroje pro podporu komplexního procesu od nákupu surovin aţ po dodání zákazníkovi.

1

Dodavatel skotu/ prasat

Dodavatel JUT

Dodavatel

Jatka

JUT

Zpracovatelský závod

Prodejna

Řetězec/ Velkoobchod

JUT

obaly/koření

2

Příloha č. 2 BIF aplikace a BIF Monitor BIF aplikace Soubor softwarových aplikací na platformě SAP, která umoţnuje zjednodušený a rychlý vstup dat z průmyslových PC nebo mobilních terminálů. Data jsou zpracována v BIF monitoru pomocí transakcí. Výhodou je moţnost zřetězení kroků v transakci.

BIF monitor zpráv Nástroj pro správu a monitorování zpráv, které vznikají vstupem dat v BIF aplikacích. Monitor zpráv pracuje asynchronně a zprávy, které nelze zpracovat z důvodu blokace kmenových dat, nebo zakázky jsou opakovaně spouštěny do doby, neţ se zpracují, nebo vyčerpají počet opakovaní a jsou označeny jako chybné. V monitoru je moţné tyto zprávy dohledávat a opravit.

1

2

Příloha č. 3 ASAP Roadmap Tato metodika rozděluje implementační fázi na pět částí a poskytuje implementační metodologii. Tento postup poskytuje i průběţnou optimalizaci. Dobrý základ pro projektové plány a výchozí diagramy. Přikládám klasickou ASAP Roadmapu s popisy průběhových částí resp. projektových fází.

1

2

3

4

Příloha č. 4 Ganttův diagram případového projektu

1