Diplomová práce Projekt konverze měny SKK na EUR v ERP SAP · 2014-11-27 · Vysoká škola...

Vysoká škola ekonomická v Praze

Fakulta podnikohospodářská

Vedlejší specializace: Management

Diplomová práce

Projekt konverze měny SKK na EUR v ERP SAP

Rok vydání: 2009

Autor: Kuročkin Michal

Vedoucí práce: Ing. Lenka Švecová, Ph.D.

Prohlášení

Prohlašují, že jsem diplomovou práci zpracoval samostatně a že jsem uvedl všechny použité

prameny a literaturu, ze kterých jsem čerpal.

V Praze, 20. prosince 2008.

_____________________________

podpis

Poděkování

Tímto bych chtěl poděkovat paní Ing. Lence Švecové, Ph.D. za velmi cenné

připomínky, rady, čas a hlavně trpělivost při zpracování této diplomové práce.

Také bych chtěl poděkovat společnosti Kaufland a osobně panu Ing. Jiřímu Krátkému

za poskytnutí příležitostí účastnit se zajímavých projektů a poskytnutí cenných podkladu

které mi pomohly se zpracováním této diplomové práce.

Abstrakt

Tato diplomová práce se zabývá problematikou přechodu na měnu euro a dopad na

informační systém ERP SAP ve velké mezinárodní společnosti.

V teoretické části jsou podrobně popsány obecné scénáře zavedení eura a vývoj

zavedení eura v Slovenské republice. V další kapitole jsou popsány metodiky řízení projektu,

základní pojmy, subjekty a zájmové skupiny, organizační struktury a fáze projektu. Na konci

teoretické části je rozebrána funkcionalita ERP, hlavní funkční moduly a základní informace

o ERP SAP.

Druhá, praktická část je věnována samotnému projektu konverze euro v ERP SAP.

V úvodní části je uvedená stručná informace o společnosti, organizační struktura a

architektura IS. Další kapitoly se věnují rozboru a odůvodnění jednotlivých podprojektů

v rámci hlavního projektu konverze, jejích popis, harmonogram a posloupnost.

Abstract

This diploma work is concerned about of euro conversion and its impact on

information system ERP SAP in large multinational company.

Theoretical part is focused on general scenarios of euro adoption and progress of

adoption of euro in Slovakia. Next chapter is describing methods of project management,

definitions, subjects and stakeholders, organizational structures and phases of the project.

Theoretical parts ends with description of ERP functionality, basic functional modules and

general information about ERP SAP.

Second, practical part is dedicated to project of conversion of euro in ERP SAP itself.

Practical part begins with describing of company, organizational structure and IS

architecture. Next chapters are focused on analysis of particular subprojects defined on scope

of general euro conversion project, their schedule and reasoning of the sequence of each

subproject.

Klíčová slova / Keywords:

Euro, Euro Conversion, Konverze euro, EUR, Slovakia, ERP SAP, Project, Kaufland,

currency changeover, konverze měny.


Kuročkin Michal Str. 1

Obsah

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

1.1 Výběr tématu .......................................................................................................................... 2

1.2 Cíle a přínos práce ................................................................................................................. 3

2 Měna euro ...................................................................................................................................... 4

2.1 Scénáře zavedení eura [čerpáno z pramenu EU1]............................................................................... 4

2.2 Vývoj zavedení Euro v Slovenské republice[čerpáno z pramenu NB1]................................................ 8

3 Řízení projektů ............................................................................................................................. 12

3.1 Základní pojmy ..................................................................................................................... 12

3.2 Zájmové skupiny a subjekty projektu ................................................................................... 19

3.3 Organizační struktury ........................................................................................................... 23

3.4 Fáze projektu ........................................................................................................................ 28

4 Funkcionalita ERP ....................................................................................................................... 40

4.1 Definice ERP (Enterprise resource planning) ....................................................................... 40

4.2 Funkční moduly ERP ............................................................................................................ 41

4.3 Základní informace o společnosti SAP AG ........................................................................... 46

4.4 Základní moduly ERP SAP ................................................................................................... 47

4.5 Vývojové procesy ERP SAP ................................................................................................. 49

4.6 Použité SAP pojmy ............................................................................................................... 50

5 Projekt konverze měny na euro ................................................................................................... 51

5.1 Základní informace o firmě Kaufland .................................................................................... 51

5.2 Organizační struktura společnosti ........................................................................................ 52

5.3 Architektura IS firmy Kaufland .............................................................................................. 53

5.4 Cíle projektu ......................................................................................................................... 54

5.5 Organizační struktura projektu ............................................................................................. 57

5.6 Specifické subjekty projekčního týmu .................................................................................. 58

5.7 Plánování projektu ................................................................................................................ 58

5.8 Realizace projektu ................................................................................................................ 62

5.9 Kontrolní mechanizmy a risk management .......................................................................... 76

6 Závěr ............................................................................................................................................ 78

7 Příloha .......................................................................................................................................... 79

7.1 Seznam zkratek .................................................................................................................... 79

7.2 Seznam obrázků a tabulek ................................................................................................... 79

7.3 Seznam použité literatury a zdrojů ....................................................................................... 81



1 ÚVOD

1.1 Výběr tématu

Ve svojí práci se věnuji aktuálnímu tématu, které je diskutováno a analyzováno

v různých odborných oblastech – ekonomické, politické a v oblasti informační technologií.

Jedná se o projekt konverze měny SKK na euro v systému ERP SAP. V moderní době, kdy

jsou tendence k sjednocování ekonomik do jednotného ekonomického prostoru v rámci

zjednodušení podnikání a ekonomické činnosti objektů a kdy každý ekonomický subjekt

funguje pomocí informačních systémů, je jedním z aktuálních a unikátních témat přechod

z národní měny na Evropskou společnou měnu – Euro. Není vyloučeno, že i jiné geografické

celky, jako Asie, Amerika a Afrika budou také, v rámci získaní ekonomických výhod,

implementovat jednotné měny. Je velice pravděpodobné, že problematika přechodu na jinou

měnu zůstane aktuální ještě po dobu následujících desetiletí a proto se mi toto téma jeví jako

velice zajímavé. Důležitým aspektem přechodu na jinou měnu je dopad na informační

systémy. Otázkou je, jak projekt pro konverzi měny byl strukturován, jaké byly hlavní fáze

projektu a jaká byla jeho časová náročnost. Na tyto otázky se pokusím v mojí práci

odpovědět.

Společnost Kaufland, o které budu v této práci psát, patří v době psaní této diplomové

práce mezi největší a nejziskovější obchodní řetězce v České republice. Za deset let

působnosti na Českém a Slovenském trhu se dokázala dostat na špičku z hlediska obratu,

ziskovosti a spokojenosti zákazníků. V České republice se nachází centrála pro podporu SAP

a IS pro země střední a východní Evropy.



1.2 Cíle a přínos práce

Cílem diplomové práce je sdílení zkušeností z projektu Konverze měny euro v systému

SAP v mezinárodní společnosti. Během přípravné fáze projektu byl brán zřetel na to, že

společnost bude používat nabyté zkušenosti v dalších projektech konverze měny v jiných

zemích. V současné době se již rýsuje perspektiva konverze v Polsku, které plánuje přejít na

euro v roce 2012. Další zemí může být v budoucnu i Česká republika. Proto jako jeden z

výsledku projektu je vzniknutí tzv. implementační šablony, která by měla pomoci

s implementací a ušetřit náklady v budoucnu.

Při psaní této práce byl brán zřetel na to, aby tato práce mohla sloužit jako inspirační

podklad pro budoucí projekty konverze měny i v jiných společnostech, a budoucí členové

projekčních týmů měli alespoň hrubou představu, co s sebou obnáší projekt konverze měny

v systému SAP – jaké jsou hlavní etapy, kritické milníky a časová náročnost.



2 MĚNA EURO

Jak uvádí na svých stránkách Ministerstvo financí ČR, euro bylo zavedeno v letech

1999 – 2001. Proces zavedení byl dvoustupňový – v bezhotovostní formě v roce 1999

(v Řecku v roce 2001), pevné oběživo (bankovky a mince) bylo uvedeno do oběhu k

1.1.2002. Paralelní oběh bankovek a mincí v dosavadních národních měnách a v euru se v

jednotlivých zemích eurozóny lišil, skončil však na konci února 2002. Technické zvládnutí

tohoto komplexního procesu bylo hodnoceno jako úspěšné. V řadě zemí se ale vyskytly dílčí

problémy, zejména v oblasti logistiky oběživa. „V rámci dnes již historického hodnocení je

rovněž často poukazováno na fakt, že výše uvedené tříleté přechodné období mezi zavedením

bezhotovostního eura a bankovek a mincí bylo neúměrně dlouhé.

Současná situace nových členských států EU je odlišná:

� nové členské země si nemohly sjednat tzv. opt-out, tj. trvalou výjimku na zavedení

eura, kterou mají v současnosti Velká Británie a Dánsko; závazek zavést jednotnou

měnu byl součástí jejich vstupních podmínek do EU (v rámci tzv. kodaňských kritérií),

� země budou vstupovat již do existující měnové oblasti, tj. za podmínek, kdy euro

existuje a je možné ho užívat i v nových členských státech EU (dobrovolně - na

základě smluvní volnosti),

� do eurozóny nevstoupí všech deset nových členských zemí najednou, jednotlivé země

vzhledem k různé úrovni připravenosti přijímají vlastní strategie ohledně vstupu včetně

časování,

� řada zemí absolvovala výměnu národní měny v nedávné minulosti (např. v ČR to byla

měnová odluka v roce 1993) a disponují tudíž v této oblasti cennými zkušenostmi.

Postupy zavedení eura současnými členy eurozóny lze tedy v případě nových

členských zemí aplikovat pouze v omezené míře“1.

2.1 Scénáře zavedení eura [čerpáno z pramenu EU1]

Existují tři varianty, jakým způsobem lze v konkrétní zemi zavést společnou měnu

euro, jsou nazývány:

� Madridský scénář,

� velký třesk,

� phasing-out.

1 Zdroj [EU1]



2.1.1 Madridský scénář

Madrický scénář je scénářem s využitím přechodného období, to znamená, že:

� „euro je zavedeno nejdříve v bezhotovostní podobě, národní měna se stává

podjednotkou eura (tzv. nesetinnou denominací podle přepočítacího koeficientu),

� v přechodném období si bankovky a mince znějící na národní měnové jednotky

zachovávají platnost, bankovky a mince v euru nejsou oficiálním platidlem,

� mezi bezhotovostním a hotovostním zavedením eura existuje přechodné období v

maximální délce tří let,

� v bezhotovostním styku lze používat jak národní měnové jednotky, tak i euro (pravidlo

dobrovolnosti, není možné žádné přinucení),

� dlužné částky na účet věřitele lze hradit jak v eurech, tak v národní měně, částka je

připsána v měně, ve které je veden účet věřitele, případný přepočet se provede na

základě přepočítacích koeficientů (z tohoto ustanovení vyplývá pro úvěrové instituce

povinnost vést paralelně účty ve dvou měnách, za přepočet nelze vybírat kurzové

poplatky),

� členské státy mohou v přechodném období přepočíst nesplacené vládní dluhopisy na

euro a rovněž převést své vypořádací systémy pro cenné papíry a pro vypořádání

plateb.“

V době vzniku eurozóny se jednalo o jediný platný existující scénář, další scénáře

vznikly později.

Obr. 2-1 "Madridcký" scénář zavedení eura, zdroj [EU1]

Předpřípravná fáze

Přípravná fáze Přechodné období

Duální cirkulace

Rozhodnutí o zrušení výjimky

Vstup do eurozóny bezhotov.

€

Zavedení bankovek a

mincí €

€ je jediným

zákonným platidlem

€



2.1.2 Big Bang

Jednorázový přechod na euro je nazýván „velký třesk“. Je založen na následujících

pravidlech:

� „jedná se o současné zavedení bezhotovostního a hotovostního eura v jeden časový

moment,

� nařízení č. 974/98, ve znění pozdějších změn, „velký třesk“ přímo nedefinuje – zmiňuje

se pouze o možnosti zavést bezhotovostní i hotovostní euro ke stejnému datu, z toho

lze dovodit konstrukci, že se jedná o zavedení eura s přechodným obdobím v délce 0

časových jednotek,

� od zavedení hotovostního eura nové právní nástroje mohou znít pouze na euro,

dosavadní nástroje znějící na národní měnové jednotky se přepočtou pomocí

přepočítacího koeficientu“

Obr. 2-2 Scénář "Big Bang", zdroj [EU1]

Výše popsaný scénář „Big Bang“ bude využit právě pro přechod na euro ve Slovenské

republice.

2.1.3 Phasing-Out

Scénář „Phasing-Out“ je scénářem s obdobím postupného zrušení a lze jej využít pouze

při volbě scénáře velkého třesku:

� „po určitou dobu po zavedení eura (max. však po dobu jednoho roku) je možné

používat vybrané právní nástroje1 znějící na národní měnu (jde tedy o dílčí výjimku z


Přípravná fáze

Big bang

Duální cirkulace


€ je jediným


€

Vstup do eurozóny,

zavedení bezhot. €, bankovek a

mincí



obecné zásady, že po zavedení hotovostního eura nelze používat národní měnové

jednotky v nových právních nástrojích),

� použití této zásady by mělo být časově i věcně omezeno na určité oblasti (např.

fakturace malých podnikatelů, živnostníků),

� placení a účtování je však nutné provést vždy v eurech,

� za přepočet z fakturované národní měny na eura by podle dosavadního výkladu EK

odpovídal variantně buď příjemce faktury, nebo ten, kdo pro něj technicky zajistí

platbu (banka, pošta …).“

Obr. 2-3 Scénář „Phasing out“, zdroj [EU1[

2.1.4 Hlavní rozdíly mezi jednotlivými scénáři

Hlavní rozdíly mezi jednotlivými scénáři uvádí následující tabulka, která zobrazuje

jednotlivé operace, nebo užití právního nástroje po vstupu země do eurozóny. Tuto tabulku

sestavila Česká národní banka a je uvedena v příloze č. 1 dokumentu „Volba scénáře

zavedení eura v České republice“ publikovaného na stránkách Ministerstva financí ČR, blíže

viz [EU1].

Tabulka 2-1 Operace / užití právního nástroje po vstupu země do eurozóny, zdroj [EU1]

Operace / užité právního nástroje PO vstupu země do eurozóny

Madridský scénář

Big Bang Phasing

Out

Vedení účtů v národní měně ANO NE NE

Provádění bezhotovostních transakcí v národní měně ANO NE NE

Provádění hotovostních plateb v národní měně ANO NE* NE*

Provádění hotovostních plateb v € NE** ANO ANO

Vydávání faktur aj. instrumentů v národní měně (časově omezeno)

ANO NE ANO

* s výjimkou období duální cirkulace ** euro je možné užívat pro hotovostní platby, pokud se na tom dohodnou obě strany kontraktu


Přípravná fáze Duální

cirkulace


€ je jediným


€ Big bang

Vstup do eurozóny,

zavedení bezhot. €, bankovek a

mincí



2.2 Vývoj zavedení Euro v Slovenské republice[čerpáno z pramenu NB1]

Podpisem Přístupové smlouvy k Evropské unii (16. dubna 2003 v Aténách) se

Slovenská republika zavázala ke vstupu do Hospodářské a měnové unie a k zavedení

společné měny – eura. Přípravy na zavedení eura na Slovensku se započaly ještě před

vstupem Slovenské republiky do Evropské unie. Následuje přehled klíčových milníků pro

zavedení eura:

� 16. června 2003 – vláda SR schválila Strategii přijetí eura v SR a společný postup

vlády SR a Národní banky Slovenska při vstupu Slovenské republiky do eurozóny.

� 8. září 2004 – vláda SR schválila Konkretizaci strategie přijetí eura v SR.

� 6. června 2005 – vláda SR schválila Národní plán zavedení eura ve Slovenské

republice. Na to navázaly aktualizace tohoto materiálu ze dne 21. března 2007 a 16.

dubna 2008.

� 28. října 2005 – slovenská koruna (SKK) vstoupila do mechanizmu výměnných kurzů

ERM II. Centrální parita slovenské koruny vůči euru byla stanovená na úrovni tržního

kurzu 38,4550 EUR/SKK. Slovenská koruna od té doby využívala v ERM II standardní

fluktuační pásmo ±15 procent okolo centrální parity. To znamená, že výměnný kurz se

mohl pohybovat pouze v rozpětí 32,6868 SKK/EUR až 44,2233 SKK/EUR.

� 14. prosince 2005 – vláda SR schválila návrh na výměnu zplnomocněnce vlády SR pro

zavedení eura. 1. ledna 2006 do této funkce vyjmenovala p. Ivana Štefance. Funkční

období p. Ivana Štefance bylo ukončeno 9. srpna 2006.

� 8. března 2006 – vláda SR schválila Zprávu o plnění Národního plánu zavedení eura v

SR k 31. lednu 2006.

� 31. ledna 2007 – vláda SR jmenovala do funkce zplnomocněnce vlády SR pro

zavedení eura p. Igora Baráta, který se ujal funkce 15. února 2007.

� 19. března 2007 – na žádost Slovenska a po dohodě ministrů financí zemí eurozóny,

prezidenta ECB a ministrů financí a guvernérů centrálních bank Kypru, Dánska,

Estonska, Litvy, Lotyšska, Malty a Slovenska centrální parita slovenské koruny v ERM

II revalvovala. Nová centrální parita koruny vůči euru byla stanovená na úrovni

1 euro = 35,4424 SKK. Rozpětí pro povinné intervence bylo stanoveno na 30,1260

SKK/EUR až 40,7588 SKK/EUR.



� 8. srpna 2007 – vláda SR schválila Zprávu o plnění Národního plánu zavedení eura v

SR k 30. červnu 2007.

� 26. září 2007 – vláda SR schválila zákon o zavedení eura ve Slovenské republice a o

změně a doplnění některých zákonů, tzv. generální zákon.

� 29. května 2008 – po dohodě ministrů financí zemí eurozóny, prezidenta ECB a

ministrů financí a guvernérů centrálních bank Dánska, Estonska, Litvy, Lotyšska a

Slovenska centrální parita slovenské koruny v ERM II opět revalvovala o 17,6472 %.

Nová centrální parita koruny vůči euru byla stanovená na úrovni 1 euro = 30,1260

SKK. Spodní hranice pro povinné intervence je 25,6071 SKK/EUR a horní hranice je

34,6449 SKK/EUR.

� 3. června 2008 – ministři financí členských zemí Evropské unie na zasedání Rady EU

pro ekonomické a finanční otázky (ECOFIN) v Lucemburku doporučili vstup

Slovenska do eurozóny k 1. lednu 2009.

� 20. červen 2008 – Rada Evropské unie ve složení hlav států definitivně potvrdila přijetí

Slovenska do eurozóny.

� 8. července 2008 – Rada Evropské unie na úrovni ministrů financí členských zemí

Evropské unie (ECOFIN) stanovila neodvolatelný přepočítávací koeficient mezi eurem

a slovenskou korunou (tzv. konverzní kurz) na úrovni 1 € = 30,1260 SKK.

� Slovenská republika se dne 1. ledna 2009 stává v pořadí 16. zemí eurozóny.

Národní plán zavedení eura představuje plán jednotlivých kroků, které jsou potřebné

pro bezproblémové a úspěšné zavedení eura v celém hospodářství Slovenska. Ve smyslu

Národního plánu zavedení eura byl zřízen Národní koordinační výbor, který je nejvyšším

řídícím a koordinačním orgánem při přípravě zavedení eura na Slovensku.

2.2.1 Plnění maastrichtských kritérií [čerpáno z pramenu NB1]

Obecnou podmínkou pro vstup do eurozóny je splnění čtyř konvergenčních kritérií, tzv.

maastrichtských kritérií:

1. Veřejné finance: Kritérium pro hospodaření veřejných financí zahrnuje v sobě 2 oblasti.

Veřejný deficit za poslední rok před hodnocením nesmí přesáhnout 3 % HDP a veřejný

dluh nesmí přesáhnout 60 % HDP.



2. Inflační kritérium: Průměrná inflace za posledních 12 měsíců, měřená podle

harmonizovaného indexu spotřebitelských cen, nesmí přesáhnout průměr třech zemí

EU s nejlepšími výsledky v oblasti cenové stability o víc než 1,5 procentuálního bodu.

3. Stabilita dlouhodobých úrokových sazeb: Průměrná dlouhodobá úroková sazba za

posledních 12 měsíců nesmí přesáhnout průměr dlouhodobých úrokových sazeb třech

zemí EU s nejlepšími výsledky v oblasti cenové stability o víc než 2 procentní body.

4. Stabilita směnného kurzu: Dva roky před hodnocením musí být národní měna zapojená

do mechanizmu směnných kurzů (ERM II). Během tohoto období nesmí stát měnu

jednostranně devalvovat, měna nesmí vybočit z dohodnutého fluktuačního pásma, musí

se pohybovat blízko centrální parity a při vývoji kurzu se nesmí vyskytnout vážné

napětí.

Tabulka 2-2 Splnění mastrichtských kriterií, zdroj [HB1]

Kritérium Referenční hodnota Stav k březnu

2008 Status plnění

Veřejný deficit (% z HDP) 3,0 2,2 � Veřejný dluh (% z HDP) 60,0 29,4 � Míra inflace (%) 3,2 2,2 � Stabilita dlouhodobých úrokových sazeb (%)

6,5 4,5 �

Stabilita směnného kurzu Dva roky před hodnocením

musí být národní měna zapojena

Členství v ERM II od listopadu 2005 �



2.2.2 Proces zavedení eura na Slovensku [převzato z NB1]

Obr. 2-4 Proces zavedení eura na Slovensku, zdroj [HB1]

Tabulka 2-3 Proces zavedení eura na Slovensku, zdroj [HB1]

1. etapa – po vstup do ERM II

2005 Absolvovaní přístupových procedur na vstup do mechanizmu směnných kurzů ERM II

2. etapa – od vstupu do ERM II až do rozhodnutí o vstupu SR do eurozóny

28.11.2005 Vstup do ERM II

do května 2008 Konvergenční zprávy Evropské komise a ECB

květen – červen 2008 Hodnotící procedura v evropských institucích

červenec 2008 Rozhodnutí Rady EU o zrušení výjimky

červenec 2008 Stanovení konverzního kurzu SKK/EUR Radou EU

3. etapa – od rozhodnutí o vstupu SR do eurozóny až do vstupu do eurozóny

červenec – prosinec 2008 Zabezpečení potřebného množství euro bankovek a ražba mincí pro hotovostní oběh v SR

září – prosinec 2008 Předzásobení komerčních bank euro bankovkami a mincemi

Prosinec 2008 Zásobení maloobchodního sektoru euro bankovkami a mincemi

spren 2008 – prosinec 2009 Povinné duální zobrazení cen – veškeré maloobchodní ceny, výplatní pásky, důchodové šeky apod. budou povinně uváděné ve slovenských korunách i v eurech

do 31. prosince 2008 Konverze bankomatů, automatů a jiných zařízení fungujících na mince nebo bankovky

4. etapa – po vstupu do eurozóny

1. leden 2009

Euro se na Slovensku zavede k 1.1.2009 současně do hotovostního a bezhotovostního oběhu bez přechodního období způsobem, tzv. Velkého třesku („Big-Bang Scenario“) a stane se zákonným platidlem na území Slovenské republiky. Koruna se stane částkovou jednotkou eura v konverzním kurzu stanoveném Radou EU.

do 16. ledna 2009

Duální oběh – po dobu krátkého období duálního oběhu se na území Slovenské republiky bude platit eurem, ale i korunovými bankovkami a mincemi. Ty se však už nebudou vydávat zpět do peněžního oběhu, ale budou se postupně stahovat, zpracovávat a ničit v prostorech Národní banky Slovenska.

od 17. ledna 2009

Pokračovaní výměny korunového oběživa za euro bankovky a mince v komerčních bankách a NBS. Slovenské oběhové euro mince budou platné ve všech zemích eurozóny a oběhové mince ostatních zemí eurozóny budou platným oběživem i na Slovensku. Bankovky jsou v celé eurozóně stejné.

do 31. prosince 2009 Povinné duální zobrazovaní cen

do června 2010 Konec duálního zobrazování cen

Duální oběh měn

Listopad 2005

Vstup SR do ERM II

Červenec 2008

Vyhlášení

konverzního kurzu

Srpen 2008

Zobrazení duálních cen

16. ledna 2009

1. leden 2009

Zavedení eura

Leden 2010

Euro je lokální měnou



3 ŘÍZENÍ PROJEKTŮ

Projektové řízení nabylo největšího růstu po druhé světové válce. Mezi hlavními

důvody byl nárůst komplexnosti a nákladů na nové technologie, zintenzívnění konkurenčního

prostředí a rostoucí nároky pro kvalitu.

3.1 Základní pojmy

3.1.1 Projekt

Projekt je nejdůležitějším prvkem projektového řízení. Existuje několik definic pojmu

„projekt“, jeden z nich je následující:

„Projekt (project) - specifický způsob dosažení změny; dočasná aktivita, která

sjednocuje a organizuje úsilí různých odborností, vynaložené na vytvoření jedinečného

záměru (zpravidla produktu nebo služby). Jde o nerutinní, neopakovatelný, jednorázový úkol

se specifickými časovými a nákladovými cíli.“ [VE1]

Podle [FI1] „projekt je výsledek materiální nebo nemateriální povahy, založený na

strategickém plánu, navržený, organizovaný a realizovaný pod řízením někoho v zájmu

vlastníka nebo zadavatele“.

Projekt je jednorázová činnost, která prochází řadou etap a fází, má určitý časový limit

pro dosažení stanoveného cíle a obsahuje značné množství charakteristických rysů, ke

kterým podle [FI1] patří:

� výsledek musí sloužit užívání po celou dobu předně určenou zadavatelem projektu,

� úspěch projektu při jeho zahájení není zřejmý,

� trvání projektu je časově omezeno,

� projekt je uskutečňován mimo běžnou podnikatelskou rutinu,

� zdroje pro realizaci projektu jsou limitovány,

� projekt má jen jeden výsledek.

Jak již bylo zmíněno, projekt má určitý časový limit – má začátek a konec formou,

kterou uvádí [VE1] takto:

� data zahájení a data ukončení,

� data zahájení a stavem naplnění cílů projektu,



� data zahájení a konstatováním, že z nějakých důvodů cílu nelze dosáhnout, neboť došlo

ke změně podmínek nebo potřeb realizace projektu.

Podle [SV1] projekt je charakterizován pojmy jedinečný, unikátní a neopakovatelný:

� kvůli specifickým potřebám a cílům, jejichž naplnění je účelem projektu,

� pro přechodnost vlastní potřeby realizace projektu,

� z důvodu dočasné existence projektového týmu v té podobě, v jaké je při obsazení

projektu vytvořena,

� pro specifické vlastnosti a rozsah aplikovaných zdrojů,

� pro neopakovatelnost souhry a dopadů působících projektových rizik,

� pro existenci jedinečného projektového okolí uplatňujícího vlivy na vlastní projekt.

3.1.2 Řízení projektu

Dalším pojmem je „řízení projektu“, který má také několik obecných definic, jednou

z nich je:

„Řízení projektu (project management) – uplatnění specifických nástrojů, technik,

znalostí a dovedností v projektových činnostech s cílem splnit (popř. překročit) očekávání,

jež jsou s projektem spojena.“ [VE1]

Řízení projektu má podle [FI1] následující specifické rysy:

� Projekt má definován začátek i konec.

� Existuje vysoká míra nejistoty.

� Používají se pružné organizační struktury.

� Složení řešitelského týmu projektu je proměnlivé.

Mezi hlavní charakteristiky řízení projektu podle [FI1] patří:

� „Časová analýza projektu určuje možné termíny začátku a konce projektu a

jednotlivých činností.

� Analýza zdrojů porovnává časový průběh nároků na čerpání zdrojů s disponibilním

množstvím zdrojů. Rozlišují se jednorázové použité zdroje, jako jsou materiály,

energie, finance, a opakovaně používané, jako jsou lidské zdroje, provozní prostředky a

vybavení.“



Cílem analýzy zdrojů může být:

� minimalizace potřeby zdrojů,

� dodržení limitů zdrojů,

� rovnoměrné čerpání zdrojů.

� Hákladová analýza se zabývá optimalizací vztahu času a nákladů na realizaci a

projektu. Zahrnuje určení druhů nákladů, a přiřazením druhů nákladů k balíkům práce.

� Rozsah projektu je dán objemem práce potřebné pro jeho realizaci.

� Kvalita projektu je měřítkem plnění požadovaných cílů projektu. Zahrnuje jak řízení

kvality projektu, tak i kvality produktu, který je projektem poskytován.

� Rizika projektu vyplývají z faktu, že každý projekt je jednorázovou záležitostí. Riziko

je možné měřit pravděpodobností, že se projekt nepodaří realizovat podle určitých

parametrů.

Na Obr. 3-1 je uveden základní rámec celého řízení projektů, na kterém je tuto

problematiku lépe pochopit. Podle [SC1] „klíčovými prvky tohoto obecného rámce jsou

účastníci projektu, nástroje a techniky pro řízení projektu a konečně přínosy úspěšných

projektů pro podnik jako celek“.

Obr. 3-1 Základní rámec řízení projektů, zdroj [SC1], str. 42.

Oblasti poznatků pro řízení projektu podle [SC1] popisují „nejdůležitější schopnost či

kvalifikace, které si každý projektový manažer musí vypěstovat.

� Řízení rozsahu projektu znamená definování a řízení veškerých prací, nezbytných

k úspěšnému dokončení projektu.

Řízenírozsahu

Řízeníčasu

Řízenínákladů

Řízeníkvality

Řízení int. projektů

Řízeníkomunik.

Řízenírizik

Řízeníobstaráv.

Základní funkce

Podpůrné fuknce

Řízení lidských zdrojů

9 oblastí poznatků

Nástrojea techniky

Projekt 1Projekt 2Projekt 3Projekt 4Projekt 5Projekt 6

Projekt 1Projekt 2Projekt 3Projekt 4Projekt 5Projekt 6

Portfolio projektů

Úspěchprojektu

Úspěchprojektu

Potřeby a očekáváníúčastníků



� Řízení času projektu představuje odhad doby potřebné k dokončení prací, návrh

přijatelného časového plánu projektu a zajištění včasného dokončení projektu.

� Řízení nákladů v projektu se skládá z přípravy rozpočtu na projekt a jeho řízení.

� Řízení kvality projektu zajišťuje, že projekt naplní stanovené nebo předpokládané

potřeby, pro jejichž splnění byl původně řešen“.

Čtyři další oblasti poznatků při řízení se označují v [SC1] jako podpůrné:

� Řízení lidských zdrojů v projektu se zabývá efektivním nasazením lidí (pracovních sil)

do řešeného projektu.

� Řízení komunikací znamená generování, shromažďování, distribuci a ukládání

informací o projektu.

� Řízení rizik se skládá z identifikace rizik, jejich analýzy a reakce na rizika související

s projektem.

� Řízení obstarávání znamená akvizici, pořizování neboli obstarávání zboží a služeb

potřebných pro řešení projektu, jež pocházejí z vnějších organizací.

� Devátou oblastí poznatků je řízení integrace projektu, která se vzájemně ovlivňuje se

všemi ostatními oblastmi poznatků.

3.1.3 Projektový trojúhelník

Projektové manažeři často hovoří o tzv. projektovém trojúhelníku. Při řízení projektu a

pro dosažení kvalitního produktu projektu je třeba brat zřetel na následující limitující faktory

a jejích optimální kombinaci:

� čas,

� cena (náklady),

� rozsah projektu.



Obr. 3-2 Projektový trojúhelník, zdroj [WI1]

Podle [PM1], „tyto tři základní charakteristiky jsou navzájem propojeny a je nutné

hledat optimální řešení z hlediska preferencí zájmových subjektů. Kvalita projektu je

ovlivňována vyvážením těchto tří faktorů. Vysoce kvalitní projekty jsou projekty, dokončené

v rozsahu, v čas, a v rozmezích rozpočtu. Vztah je mezi těmito faktory takový, že pokud

dojde ke změně jednoho, alespoň jeden z dalších faktorů bude ovlivněn“.

3.1.4 Projektové procesy

Podle [FI1] každý projekt je realizován v postupných, sebe navazujících krocích.

Projekt, z procesního pohledu, není jediným probíhajícím procesem. Jedná se o soustavu pěti

skupin procesů:

� iniciační procesy - vedoucí ke vzniku či zahájení procesu nebo fáze,

� plánovací procesy – definují a upřesňují cíle a vybírají nejlepší variantu způsobu

dosažení těchto cílů,

� realizační procesy – koordinují lidské a další zdroje pro uskutečnění plánu,

� kontrolní procesy – zajišťují dosahování cílů monitorováním a měřením postupu pro

určení odchylek od plánu, aby v případě nutnosti mohla být provedena nápravná

opatření,

� závěrečné procesy – formují převzetí projektu.

Tyto skupiny se vzájemně doplňují a existují v souběhu, a netvoří jediný procesní

sousledný tok. Následující diagram (Obr. 3-3) znázorňuje vztahy mezi procesy řízení

projektů.

rozsah

cena čas

kvalita



Obr. 3-3 Diagram projektových procesů, zdroj [FI1]

3.1.5 Projektové řízení

Podle [FI1] „projektové řízení je způsob řízení pomocí projektů. Jedna se o účinný

nástroj řízení změn, který umožňuje manažerům dosáhnout odpovídající kvality výstupu

s minimálními nároky na čas a ostatní zdroje. Projektové řízení zahrnuje řízení jednotlivých

projektů a vytvoření organizační struktury a koordinaci projektů z hlediska termínů a

disponibilních zdrojů“.

Projektový management se liší podle [SV1] od „běžné formy operativního řízení v

liniově řízené společnosti zejména svou dočasností a v přidělení zdrojů pro jeho realizaci

podle potřeb projektu. Pokud je dosaženo cílů u projektu, projekt končí, pokud je dosaženo

cílů u operativního řízení, jsou nastaveny nové cíle a práce jednotky pokračuje. Pro projekt

jsou plánovány a přiděleny pracovní, finanční nebo technologické zdroje podle jeho

plánovaných potřeb a po jeho skončení jsou tyto zdroje spotřebovány nebo převedeny do

jiných projektů. Zdroje pracovních jednotek podléhajících operativnímu řízení jsou

kontinuálně plánovány a doplňovány, po ukončení potřeby jejich užívání mohou být

uvolněny pro skladování, likvidaci nebo převod mimo společnost jiným způsobem, který

však vždy nemusí znamenat jejich efektivní využití, neboť tyto zdroje nemusí patřit k

primárním prvkům řízení a náklady na jejich nečinnost nejsou průběžně sledovány“.

Dále, jak uvádí [SV1], „úspěšný projektový management může být definován jako

dosažení plánovaného cíle projektu, a to při dodržení časového limitu, předpokládaných

Inicializační procesy

Plánovací procesy

Realizační procesy

Kontrolní procesy

Závěrečné procesy



nákladů nebo jiných čerpaných zdrojů (např. u interních projektů to může být časový limit

přidělených pracovníků), s dosažením požadovaného cílového výkonu nebo úrovně

technologie a s akceptací zákazníka projektu. Za další - měkčí - kritéria úspěchu můžeme

dále považovat možnost užití zákazníkova jména v referencích, minimum změn v původním

projektovém záměru, realizaci dalších návazných projektů a minimální zatížení běžného

pracovního života zákazníka projektu“.

Potenciální výhody projektového managementu je možné vymezit následujícím

výčtem:

� Ke všem aktivitám, které jsou součástí projektu, je přiřazena odpovědnost bez ohledu

na případné změny realizačního personálu.

� Je jasně identifikován časový a nákladový rámec realizace.

� Realizační zdroje projektu jsou přiděleny na dobu trvání projektu a poté jsou uvolněny

pro jiné projekty nebo spotřebovány, což umožňuje větší flexibilitu a efektivitu ve

využívání těchto zdrojů.

� Jsou vytvořeny podmínky pro sledování skutečného průběhu oproti plánu, v průběhu

realizace je možno definovat odchylky oproti plánu a efektivně směřovat korektivní

akce.

� Systém rozdělení odpovědností za řízení projektu a pravidla eskalace problémů

umožňují plynulé řízení bez nutnosti nadměrného dohledu ze strany

zákazníka/sponzora projektu.

� Principy řízení přispívají k získání souhlasu o naplnění nebo překročení plánovaného

cíle projektu.

� Systémový přístup k řízení projektu generuje celou řadu informací s výhodou

použitelných pro realizaci dalších projektů.

Samozřejmě, že projektové řízení má i své problematické stránky, které vytvářejí celou

řadu situací, často obtížně předvídatelných, které jsou pro každého projektového manažera

výzvou. Jejich úspěšné řešení pak záleží na jeho zkušenosti, připravenosti a talentu. Za

mnohé zmiňme alespoň:

� komplexní rozsah projektů a zařazení projektu do hierarchie projektů, které jsou

součástí komplexního programu,



� specifické požadavky zákazníka projektu, často se objevující až v průběhu realizace,

� organizační změny ve společnosti, které nastávají v průběhu projektu.

� rizika projektu a obtížně předvídatelné vnější vlivy,

� změny v technologii,

� plánování a oceňování v předstihu před vlastní realizací.

3.2 Zájmové skupiny a subjekty projektu

Podle [PM1] „zájmové skupiny projektu (stakeholders) jsou jednotlivce nebo

organizace které se aktivně podílejí na projektu. Tyto skupiny mohou ovlivňovat průběh

projektu a jeho výsledek. Před zahájením projektu projektový tým musí identifikovat

zájmové skupiny, vymezit jejich odpovědnosti a očekávání, organizovat jejích vliv na průběh

projektu v zájmu úspěšného dokončení svěřených úkolů“.

Obr. 3-4 znázorňuje vztahy mezi jednotlivými zájmovými subjekty a projektovým

týmem.

Obr. 3-4 Vztah mezi zájmovými subjekty a projektem, zdroj [PM1]

Podle [SV1] „mezi nejdůležitější zájmové skupiny patří:

� Zákazník projektu – každý projekt má svého zákazníka, který má zájem na realizaci

projektu a je jeho investorem nebo zadavatelem - jedná se zpravidla o budoucího

Projektový manažer

Sponzor projektu

Project management tým

Projektový tým

Zájmové skupiny projektu

Projekt



uživatele výstupů produktu projektu nebo o investora, pro nějž znamená realizace

projektu zvýšení potenciální úspěšnosti na trhu prostřednictvím nového produktu nebo

služby, která je předmětem projektu. Klíčovou osobou ve skupině zákazníka projektuje

sponzor projektu, který je formálním nositelem zpravidla nejvyšší rozhodovací autority

v projektu.

� Sponzor projektu je manažer zákazníka projektu, který má autoritu dostatečnou k

rozhodování o fundamentálních aspektech projektu - předmětu projektu, rozpočtu a

časovém rámci projektu. Sponzor projektu je zpravidla funkčním manažerem

Zákazníka projektu - organizační jednotky, která bude výsledek projektu používat.

Obecně to však může být jakýkoliv osoba s pověřením k výkonu potřebných

rozhodnutí.

� Dodavatel/realizátor projektu - je společnost nebo její část, která je přímým

účastníkem kontraktu a z něho plynoucí odpovědnosti za vlastní realizaci projektu.

Zájmem dodavatele projektu je naplnění podmínek kontraktu a získání s ním spojené

odměny. Dodavatel/realizátor projektu je společnost nebo její část, která na základě

kontraktu se zadavatelem projektu poskytuje realizační zdroje a know-how potřebné k

dosažení požadovaného výsledky projektu“.

Dodavatelem projektu může být:

� externí společnost (zpravidla agregované projekty).

� jiná organizační jednotka zadavatele projektu (speciální projekty),

� organizační jednotka, která je zároveň zadavatelem projektu (individuální a týmové

projekty).

Do jednotlivých skupin projektu patří zájmové subjekty, [FI1] zmiňuje následující

„nejdůležitější zájmové subjekty, které se podílejí na řízení a realizaci projektu:

� Projektová organizace – její zaměstnanci jsou přímo zapojení do práce na projektu.

� Ředitel projektů – odpovědný na strategické úrovni za plánování a realizaci všech

projektů v organizaci.

� Projektový manažer – plně odpovědný za plánování a realizaci projektu na taktické a

operativní úrovní.

� Členové projektového týmu – pracovníci podílející se na jednotlivých pracích.



� Zákazník – subjekt, jedinec či organizace, kterému jsou určeny výstupy projektu. Může

existovat i několik úrovní zákazníků.

� Investor – osoba nebo skupina, ve firmě nebo mimo, které poskytuje finanční zdroje

pro projekt“.

Podle [FI1] jsou i další subjekty uvnitř a vně organizace, kteří mají zájem o průběh a

produkt projektu. „Mohou to být vlastníci, prodejci, vládní instituce, média, jednotliví

občané i celá společnost. Tyto subjekty mohou mít zcela rozdílné zájmy a sladění těchto

různých zájmů bývá největším problémem při řízení projektu“.

3.2.1 Projektový manažer

Klíčovým subjektem projektu je projektový manažer, protože odpovídá za celý projekt.

Pod jeho přímým vlivem jsou podle [SV1] takové projektové aktivity jako tvorba

projektového plánu, obsažení jednotlivých odborných pozic projektu, koordinace úkolu,

finalizace a předání výstupu projektu zákazníkova a administrativní uzavření projektu.

„Manažer projektu je osoba odpovědná za splnění cílů projektu při dodržení všech

stanovených charakteristik projektu“, [SV1] str. 29.

[FI1] zmiňuje následující aktivity, které má na starosti projektový manažer:

� má odpovědnost za projekt jako celek,

� plánuje, organizuje a koordinuje práce,

� vede, monitoruje a kontroluje projekt,

� odpovídá za výběr pracovní skupiny a její transformaci do týmu,

� jedná s vyšším a středním managementem o uvolnění potřebných osob do týmu,

� podává zprávy o postupu vzhledem k plánu,

� analyzuje a řeší problémy s projektovým týmem,

� udržuje spojení se všemi úrovněmi.

Manažer projektu je dle [SV1] v „centru veškerého dění a spojuje se u něj výkon řízení

činností i vztahů uvnitř projektu, odborný výkon prací na projektu, dennodenní řízení

procesů, schopnost motivovat a vést členy projektového týmu, analytické a syntetické

schopnosti porovnání skutečného stavu projektu proti plánu a tvorba závěrů s ohledem na

potenciální' účinek rizikových faktorů“. Ve správné volbě manažera projektu proto může hrát

důležitou roli:



� vhodnost pro konkrétní práci - ne každý projektový manažer je vhodný pro jakýkoliv

projekt a obsazení role by nemělo podléhat okamžité dostupnosti jedince bez ohledu na

jeho dosavadní zkušenosti a schopnosti,

� zkušenost - vhodní adepti pro řízení kritických projektů nebo rozsáhlých programů jsou

zpravidla jedinci s osvědčenou schopností prioritizace a s vyspělými manažerskými

taktikami a postupy ověřenými v předchozích projektech,

� technická zdatnost v oblasti předmětu projektu - u některých typů projektuje nevhodné,

je-li projekt pouze „administrován"; manažer projektu zpravidla nebývá technickým

expertem, určitá znalost technologie je však u některých projektů nezastupitelná,

� vztah k zákazníkům - některý zákazník vyžaduje více pozornosti a sdílení informací v

detailu, jiný má pragmatickou orientaci na výsledek, další klade velký důraz na

formální stránku řídících postupů; pokud je osobnost a styl manažera projektu ve

větším rozporu s očekáváním a potřebami zákazníka, může to rovněž přinést zdroj

konfliktu.

Rozdíly mezi projektovým manažerem a organizačním vedoucím podle [SE1] „tkví

převážně v tom, že projektový vedoucí se stará o otázky jako – co se má udělat, jak to bude

uděláno, jak dobře to bude uděláno, kdy to bude hotovo, kolik peněz je k dispozici a proč se

to dělá. Organizační vedoucí převážně zajišťuje vyřešení otázek jako – kdo to udělá, kde to

bude uděláno a kdy to bude prováděno“.

3.2.2 Projektový tým

Jak uvádí [SV1], „projektový tým je hlavním výkonným článkem projektu. Jedním z

prvních úkolů plánovací fáze projektu je ustanovení organizační struktury projektu a

nastavení jejích vztahů k mateřské organizaci. Projektový tým je skupina osob, které se

realizačně podílejí na splnění cílů projektu a po dobu projektu podléhají řízení projektového

manažera, a to v rozsahu přiděleného času nebo určité pracovní kapacity a v rámci

přidělených oprávnění a odpovědností. Projektový tým se skládá z osob s pověřením

realizovat určitou jednotku/y práce s přesně definovaným zadáním, požadovaným

výsledkem, v definovaném časovém období a s určeným předpokladem pracnosti“.

Podle [FI1] „pro fungování skupiny pracovníků jako úspěšného projektového týmu je

nutné dodržovat určité zásady:



� zajistit, aby projektový tým rozuměl cíli projektu,

� poskytnout příležitost pro realizaci názorů všech členů týmu,

� vytvořit atmosféru důvěry a odhodlání,

� nejprve identifikovat kvalifikační požadavky, pak hledat vhodné osoby,

� určit efektivní úvazky členů týmu,

� zajistit informovanost všech členů týmu,

� plánovat, koordinovat, monitorovat a kontrolovat práce všech členů týmu,

� rozptýlit jejich obavy, plynoucí z nejistoty co bude po dokončení projektu,

� vysvětlit vztahy mezi týmem a ostatními částmi organizace,

� zajistit, aby všichni věděli, co se musí udělat,

� týmově analyzovat a řešit všechny problémy“.

Efektivita týmu je proporcionálně úměrná velikosti – čím je menší tým, tím je

efektivnější díky dosažení vyššího synergického efektu.

Člen projektového týmu podle [SE1] „má být seznámen se všemi dokumenty projektu,

definující ho jako celek, má být srozuměn s výstupy projektu a zohledňovat je ve své práci,

má vykonávat projektové činnosti, identifikovat potenciální rizika a oznamovat je

projektovému manažerovi, oznamovat manažerovi konflikty, odchylky od plánu a případně

navrhovat jejích řešení a nakonec člen projektového tým má sledovat průběh projektu“.

3.3 Organizační struktury

Pro úspěšné řízení a ukončení projektu musí projektový manažer vždy pohlížet na

projekt vždy v kontextu větší organizace jako celku. Velice často neúspěch projektu je spojen

s nedostatkem identifikace všech účastníku zapojených do řešení projektu, zejména jeho

odpůrců, politický kontext projektu nebo kultury organizace. Měl by tedy podle [SC1]

rozlišit čtyři důležité rámce: strukturální, lidských zdrojů, politický a symbolicky:

� Strukturální rámec se podle [SC1] „týká způsobu strukturování organizace, který je

obvykle znázorněn v organizačním diagramu a je zaměřen na role a povinnosti různých

skupin, které tak naplňují cíle a politiky stanovené vrcholovým vedením firmy. Tento

rámec se zaměřuje na koordinaci a řízení“.

� Rámec lidských zdrojů, jak uvádí [SC1], „se zaměřuje na dosažení harmonie mezi

potřebami organizace jako celku a potřebami jednotlivých osob. Mezi potřebami



organizace a potřebami jednotlivců či skupin je často zjevný nesoulad a je třeba se

pokoušet i řešení veškerých potenciálních problémů. Důležitou otázkou rámce lidských

zdrojů je nedostatek kvalifikovaných pracovníků z IT v organizaci a nerealistické

časové plány“.

� Politický rámec je souhrnné označení organizační a osobní politiky. [SC1] píše, že

výrazem „politika“ v organizaci se rozumí konkurence mezi skupinami nebo

jednotlivci, kteří spolu soupeří o moc a vedoucí pozici. Při řízení projektů se od

projektových manažerů očekávají důležitá rozhodnutí ohledně přidělení

nedostatkových zdrojů a právě soutěžení o tyto zdroje je hlavním zdrojem konfliktů

v organizacích.

� Symbolický rámec se podle [SC1] zaměřuje na „symboly v organizaci a jejich

význam. Pokud dojde k nějaké události v organizaci, není důležité, co se přesně stalo,

ale co to znamená. Symbolický rámec úzce souvisí s firemní a organizační kulturou“.

Jak již bylo zmíněno, průběh a výsledek projektu je úzce závislý na lidech, kteří jsou

zapojení do projektu. Pro efektivní řízení projektu je nutné vytvořit strukturu jednotlivých

rolí, definovat vztahy mezi rolemi, vymezit rozsah zodpovědností a přidělit rozhodovací

autority tak, aby bylo jasné rozdělení odpovědností za splnění dílčích úkolů. Organizační

struktury usnadňují komunikaci a zachycují vztahy mezi účastníky projektu. Podle toho, jak

je projekt strukturován, jak je komplexní, se určuje i samotná struktura projektu. Tato

struktura se může během vývoje projektu i měnit. Dle [FI1] pro výběr nejvhodnější

organizační struktury je možno uvažovat podle následující řady kriterií:

� struktura a rozsah projektu,

� způsob zapojení organizační struktury účastníků projektů,

� míra ochoty a schopnosti spolupráce účastníků projektu,

� úroveň informačního systému účastníků projektu,

� míra instituonalizace subjektu projektového řízení,

� právní, ekonomické a další omezení.

Projektová organizace podle [FI1] by měla zachycovat některé podstatné vlastnosti, měla by

být:

� plochá – malý počet hierarchických úrovní,

� otevřená – její složení se mění během životního cyklu projektu,

� neautoritativní – je založena na týmové spolupráci,



� dočasná – působí po dobu životního cyklu projektu.

Každá struktura má svoje předurčené vlastnosti a omezení z hlediska dostupnosti

zdrojů a rozdělení zodpovědnosti. Tabulka zobrazuje klíčové charakteristiky základních typu

organizačních struktur.

Tabulka 3-1 Vliv organizační struktury na projekty, zdroj [PM1], str. 28.

Organizační struktura Charakteristika projektu

Funkční

Maticová

Projektová Slabá

maticová Vyvážená maticová

Silně maticová

Autorita manažera projektu malá / žádná omezená nízká až střední

střední až vysoká

vysoká až úplná

Dostupnost zdrojů malá / žádná omezená nízká až střední

střední až vysoká

vysoká až úplná

Kdo kontroluje rozpočet projektu funkční ředitel funkční ředitel sdílená kontrola

projektový manažer

projektový manažer

Role manažera projektu zkrácený úvazek

zkrácený úvazek

plný úvazek plný úvazek plný úvazek

Zařazení administrativních pracovníku do projektu

zkrácený úvazek

zkrácený úvazek

zkrácený úvazek

plný úvazek plný úvazek

3.3.1 Funkční organizační struktura

Klasickou funkční organizační strukturu zobrazuje Obr. 3-5, tato struktura je

charakteristická tím, že každý zaměstnanec má jasně definovaného jednoho vedoucího.

Obr. 3-5 Funkční organizační struktura, zdroj [FI1], str. 22.

Týmy jsou seskupovány podle specializace, např. výroba, marketing, finance na

vrcholu hierarchie. Na nižších stupních se hierarchie může dále rozvětvovat. Dle [FI1] mezi

Generální ředitel

Výrobní ředitel

Finanční ředitel

Marketingový ředitel



předností dané struktury patří její jednoduchost. Pokud se jedná o menší projekty v rámci

jednotlivých útvarů, mohou být na projekt dočasně nasazeni lidé z těchto útvarů, kteří se

znají a je možná dobrá tymová spolupráce. V případě větších projektů, pro které je potřebné

zařazení více útvarů, vznikají koordinační a komunikační problémy, protože neexistuje

jediný odpovědný koordinátor. U rozsáhlejších projektů by to znamenalo koordinaci od

nejvyššího managementu, který má však na starosti problémy na strategické úrovni.

3.3.2 Projektová organizační struktura

Na opačné straně je projektová organizační struktura, která je zobrazena na Obr. 3-5.

Obr. 3-6 Projektová organizační struktura, zdroj [FI1], str. 23.

Většina zdrojů organizace je podle [PM1] „určena pro projekční práci, projektoví

manažeři mají rozsáhlou pravomoc a nezávislost. Projektové organizace často mají

organizační jednotky pojmenované „oddělení“ (department), tato oddělení reportují přímo

projektovému manažerovi nebo prování podpůrné služby pro rozličné projekty“.

Za projekty na strategické úrovni dle [FI1] odpovídá ředitel projektů. Pracovníci jsou

uvolnění po celou dobu projektu a vytvářejí projektové týmy pod vedením projektových

manažerů.

Jak uvádí [FI1] „projektová organizační struktura je vhodná pro rozsáhlé a časově

náročné projekty. Jedna se o organizaci, která je vytvořená pouze pro plánování a realizaci

projektů. Předpokladem pro fungování je existence integrovaného systému plánování a

kontroly projektu. Ředitel projektů má veškeré kompetence“.

Dle [FI1] výhody projektové organizace jsou následující:

� plná koncentrace na projekt,

� silné ztotožnění pracovníků s cíli projektu.

Ředitel projektů

Projektový manažer 1





Jako nevýhody [FI1] uvádí následující:

� problémy při přeřazení pracovníků a obavy ze ztráty pozice,

� muže docházet k přetížení nebo naopak, nevyužití lidí při práci na projektech.

3.3.3 Maticová organizační struktura

Maticová struktura, která je znázorněná na Obr. 3-7 je kombinuje v sobě funkční a

projektovou organizační strukturu.

Obr. 3-7 Maticová organizační struktura, zdroj [FI1], str. 24.

Dle [PM1] „existují tři základní druhy maticových struktur – slabá, vyvážená a silná

maticová struktura. Slabá maticová struktura obsahuje hlavně prvky funkčních organizačních

struktur, kde projektový manažer hraje převážně roli koordinátora, než manažera. Na druhé

straně, silné maticové struktury obsahují mnoho prvků projektových organizačních struktur,

kde projektový manažer je zařazen na plný úvazek do projektu, má rozsáhlé pravomoci a má

k dispozici na plný úvazek administrativní aparát“.

Jak uvádí [FI1], „maticová organizační struktura je vhodná pro projektové firmy

s vysokou četností nových projektů. Výhodou je efektivní využití lidí, pružnost a vysoká

Generální ředitel

Marketing. ředitel

Výrobní ředitel

Finanční ředitel

Ředitel projektů



Projektový manažer n



kreativita. Pracovníci nemají obavy ze ztráty pozic. Nevýhodou však je dvojí podřízenost a

vyšší náklady na komunikaci“.

3.4 Fáze projektu

Projektové řízení se skládá z různých vzájemně propojených aktivit. Projektové

aktivity jsou důležité pro organizaci, a proto je třeba mít definované kontrolní body pro

zjištění, jak se vyvíjí projekt. Projekt podle [SC1] musí vždy nejprve projít úspěšnou

kontrolou určité etapy hlavního projektu, a až po kontrole může pokračovat další etapou. Po

každé etapě by měla následovat manažerská kontrola, která vyhodnotí ukončovanou etapu a

jestli je i nadále ve shodě s cíli organizace. Každý projekt by měl mít určen začátek a konec,

a v rámci životního cyklu by měl procházet jednotlivými fázemi projektu. Podle [FI1] se

většinou uvádí čtyři základní fáze projektu:

� koncepční,

� plánovací,

� realizační,

� předávací.

Jak uvádí [SV1], „přechod z jedné fáze do druhé je uskutečněn při dosažení určitého

dříve definovaného stavu projektu, případně souboru plánovaných dílčích výsledků. Přechod

mezi fázemi je zpravidla uskutečněn na základě dílčího schvalovacího procesu, který

konstatuje připravenost pro přechod do další fáze. U větších a zásadních rozdílů mezi

plánovaným a dosaženým stavem nebo při zvýšeném výskytu a působení rizikových faktorů

se může stát, že je rozhodnuto o přerušení nebo o předčasném ukončení projektu. V případě

některých projektů s velkou mírou neurčitosti bývá volen přístup postupného startování

jednotlivých fází životního cyklu projektu - projekt není vyvíjen a řízen podle plánu

pokrývajícího celý cyklus od samého počátku - například o realizaci dalších fází je

rozhodnuto až po vypracování studie proveditelnosti, a to v přímé návaznosti, nebo s

odkladem po splnění dalších podmínek“.

Každá fáze se liší jednotlivými nástroji a technikami projektového řízení. Jednotlivé

činnosti a využití zdrojů podle [FI1] je třeba posuzovat postupně od globálních cílů

k detailním činnostem. Lidské zdroje jsou podstatným typem zdrojů, jelikož v celém průběhu

projektu se jedná o práci s lidmi a měly by se používat odpovídající techniky.



Pro každou fázi je podle [FI1] vhodné stanovit:

� vstupy,

� procesy,

� klíčové činnosti,

� zlomové okamžiky,

� výstupy.

Typické rozložení fází životnosti projektu jsou znázorněny na Obr. 3-8.

Obr. 3-8 Typické rozložení fází životního cyklu projektu, zdroj [SV1]

Každá fáze je charakteristická mírou úsilí pro dokončení konkrétní fáze, která se dá

měřit celkovým počtem pracovních hodin. Na Obr. 3-9 je znázorněn typický průběh nasazení

lidských zdrojů jednotlivých fází projektu.

Myšlenka Projektový tým

Plné zapojení zdrojů projektu

Vyřazení realizačních zdrojů projektu

Zahájení Střední fáze realizace

Ukončení Fáze

Vstupy

Výstupy řízení

Výstupy projektu

Základní listina

Definice předmětu

Plán Postup Akceptace

Schválení

Předání do užití

Mezivýstupy dílčích etap Výsledný produkt



Obr. 3-9 Typický průběh nasazení lidských zdrojů životního cyklu projektu, zdroj [SV1]

Nasazení lidských zdrojů odráží i vynaložené náklady. Realizační fáze vyžaduje podle

[FI1] největší úsilí a největší náklady. Ale z hlediska vlivu nejdůležitější je koncepční fáze,

ve které je největší příležitost pro vytvoření přidané hodnoty, kdy jsou analyzovány potřeby

zákazníků a vytvářená koncepce produktu a jeho realizace. S narůstající dobou narůstají i

náklady na případné změny v projektu, které byly způsobeny chybami v koncepční fázi.

Zahájení

Realizace

Ukončení

Nasa

zení

lidsk

ých z

dro

jů

Čas

Plán



Obr. 3-10 Vliv zájmových skupin v průběhu životního cyklu projektu, zdroj [SV1]

3.4.1 Koncepční fáze

Koncepční fáze je charakteristická analytickou činností týmu, který jako výstup

generuje seznam možných řešení projektu. Podle [FI1] během této fáze se identifikují

potřeby, cíle, týmové složení, sestavuje se strategie, určují se rizika a požadavky na zdroje.

Jednotlivé varianty řešení jsou hodnoceny a z nich je vybrána nejvhodnější varianta.

Hodnocení a výběr projektu je vícekriteriální analýzou, kdy se projekty hodnotí podle:

� finančních ukazatelů,

� míry rizika,

� časových ukazatelů,

� nákladových ukazatelů,

� nároků na zdroje,

� ukazatelů kvality.

Tato fáze by měla vyústit ve studii proveditelnosti, která stanoví cíl, navrhne zásadní

postup řešení a zhodnotí požadované zdroje pro dosažení cíle. Studie proveditelnosti by měla

být formulována s požadavky, omezeními a očekávanými výstupy:

� kdo je odpovědný,

Koncept

Realizace

Předání

Čas

Náklady změn

Vliv zájmových skupin

Vys

oký

N

ízký

Plán



� kdo bude zapojen,

� analyzovaný návrh,

� úroveň detailu,

� způsob a termíny hlášení zpráv,

� rozpočet.

3.4.2 Plánovací fáze

Hlavním úkolem projektových plánů je podle [SC1] vést tzv. vlastní provedení

projektu. Navržené plány musí být realistické a smysluplné, proto je nutné do plánování

investovat odpovídající množství času i práce a plán musí sestavovat lidé, kteří rozumí

samotné plánované činnosti.

Pro sestavení kvalitního plánu je třeba umět odpovědět na tři základní otázky:

� jaký je aktuální stav,

� jaký je požadovaný cílový stav,

� jakým způsobem se dosáhne požadovaného stavu.

Plánovací fáze podle [FI1] „spočívá v detailním vyhotovení plánu projektu pro

navrhovaný výstup. Jedná se o dekompozici problému až na jednotlivé činnosti s vyjádřením

vzájemných vazeb, odhadem času realizace a požadavků na jednotlivé zdroje.

Při detailním vyjádření projektu se používá hierarchická struktura činností. Je navržen

rozpočet a odhadované peněžní toky. Je nutno odhadnout míru rizika a potenciální zdroje

risku. Pro jednodušší orientaci v průběhu projektu se používají různé zobrazovací nástroje.

Mezi nejběžněji používané patří model ve formě síťového grafu nebo Ganttova diagramu.

V této fázi se uplatní standardní techniky síťové analýzy projektu s využitím

standardních metod pro časovou analýzu, (jako critical path method), nákladovou analýzu

(např. CPM/COST) a analýzu zdrojů (heuristické procedury). Je nutné navrhnout a připravit

vhodnou organizační strukturu. Součástí fáze je i výběr vhodných dodavatelů a příprava

smluv s nimi“.

Obsahem plánu by podle [RO1] „měly být taková témata jako souhrn projektu,

požadavky, milníky, struktura projektu, síťový graf činností s plánovanými termíny, rozpočet,

způsoby kontroly projektu atd“.



Níže uvedené Tabulka 3-2 z [SC1] uvádí oblasti poznatků z řízení projektů, které jsou

dotčené plánováním, a k nim odpovídající procesy a výstupy v souladu s publikací PMBOK

® Guide 2004.

Tabulka 3-2 Procesy plánování projektu a jejích výstupy, zdroj [SC1], str. 119-120.

Oblast poznatku Procesy plánování Výstupy

Řízení integrace projektu Vytvoření plánu řízení projektu � Plán řízení projektu

Řízení rozsahu projektu Plánování rozsahu � Plán řízení rozsahu projektu Definice rozsahu � Stanovení rozsahu projektu

� Požadované změny � Plán řízení rozsahu projektu

(aktualizovaný) Vytvoření struktury rozpisu prací (WBS)

� Stanovení rozsahu projektu (aktualizované)

� Struktura rozpisu prací (WBS) a slovník WBS

� Základní (směrný) rozsah projektu

� Plán řízení rozsahu projektu (aktualizovaný)

� Požadované změny

Řízení času v projektu Definice aktivit � Seznam aktivit a atributů � Seznam milníků � Požadované změny

Seřazení aktivit � Síťový diagram časového plánu projektu

� Seznam aktivit a atributů (aktualizovaný)

� Požadované změny

Odhad zdrojů pro aktivity � Požadavky aktivit na zdroje � Atributy aktivit (aktualizace) � Struktura rozdělení zdrojů � Kalendář zdrojů

(aktualizovaný¨ � Požadované změny

Odhad doby trvání aktivit � Odhady dob trvání aktivit � Atributy aktivit (aktualizace)

Vytvoření časového plánu � Časový plán projektu � Plánování modelových dat � Směrný časový plán � Aktualizace požadavků na

zdroje, atributů aktivit, kalendáře projektu a plánu řízení projektu

� Požadované změny Řízení nákladů v projektu Odhady nákladů � Odhad nákladů na aktivity a

podpůrné detaily � Požadované změny � Plán řízení nákladů

(aktualizovaný)

Rozpočet nákladů � Směrné náklady � Požadavky na financování

projektu � Plán řízení nákladů




(aktualizovaný) � Požadované změny

Řízení kvalty projektu Plánování kvality � Plán řízení kvality � Metriky kvality � Seznam požadavků na kvalitu � Plán zlepšování procesů! � Směrná kvalita � Plán řízení projektu

(aktualizovaný) Řízení lidských zdrojů v projektu

Plánování lidských zdrojů � Role a povinnosti � Organizační diagramy

projektu � Plán řízení zaměstnanců

Řízení komunikací v projektu Plánování komunikace � Plán řízení komunikací

Řízení rizik v projektu Plánování řízení rizik � Plán řízení rizik Identifikace rizik � Registr rizik

Kvalitativní analýza rizik � Registr rizik (aktualizace) Kvantitativní analýza rizik � Registr rizik (aktualizace)

Plánování reakci na rizika � Registr rizik (aktualizace) � Plán řízení projektu

(aktualizovaný) � Smluvní ujednání související

s riziky

Řízení obstarávání v projektu Plánování nákupu a akvizicí � Plán řízení obstarávání � Smluvní pracovní příkazy � Rozhodování typu „make-or-

buy“ � Požadované změny

Plánování smluv � Dokumenty k obstarávání � Hodnoticí kritéria � Smluvní pracovní příkazy

(aktualizované)

3.4.3 Realizační fáze

V průběhu realizační fáze projektu se musí provést a průběžně kontrolovat veškeré

aktivity, které zajistí dokončení celého plánu projektu. Během realizační fáze se obvykle

spotřebovává největší množství zdrojů projektu. Tabulka 3-3 z [SC1] zobrazuje oblasti

poznatků z řízení projektů, dotčené provedením projektu, a k nim odpovídající výkonné

procesy a jejích výstupy, jak jsou popsány v publikaci PMBOK ® Guide 2004.

Tabulka 3-3Výkonné procesy v projektu a jejich výstupy, zdroj [SC1], str. 130.

Oblast poznatku Výkonné procesy Výstupy

Řízení integrace projektu Řízení a vedení vlastního provedení projektu

� Ucelené části díla (projektu) � Požadované změny � Implementované řešení



Oblast poznatku Výkonné procesy Výstupy

problémů (např. požadavky změn, nápravná opatření, preventivní opatření a oprava závad)

� Informace o výkonu

Řízení kvality projektu Provádění úkonů zajištění kvality

� Požadované změny � Doporučená nápravná

opatření � Procesní aktiva v organizaci

(aktualizace) � Plán řízení projektu

(aktualizovaný)

Řízení lidských zdrojů v projektu

Sestavení projektového týmu � Přiřazení úkolů zaměstnancům

� Dostupnost zdrojů � Plán řízení zaměstnanců

(aktualizace) Vybudování projektového týmu � Hodnocení výkonnosti týmu

Řízení komunikací v projektu Distribuce informací � Procesní aktivita v organizaci (aktualizace)

� Požadované změny Řízení obstarávání v projektu Vyžádání nabídek od

dodavatelů � Seznam kvalifikovaných

dodavatelů � Soubor dokumentů

k obstarávání � Návrhy a nabídky

Výběr dodavatele � Množina vybraných dodavatelů

� Smlouvy � Plán řízení smluv � Dostupnost zdrojů � Plán řízení obstarávání

(aktualizace) � Požadované změny

V průběhu realizace projektu se musí provádět kontrolní činnosti, zda nedochází

k odchylkám od plánu a v případě nalezení odchylek provádět nápravná opatření, pro

dosažení stavu podle plánu. Kontrolní aktivity mají vliv na všechny fáze životního cyklu

projektu. Podle [SC1] jednotlivé oblasti poznatků, procesy sledování a kontroly i

odpovídající výstupy shrnuje následující Tabulka 3-4 podle publikace PNBOK ®

Guide 2004.

Tabulka 3-4 Procesy sledování a kontroly projektu a jejich výstupy, zdroj [SC1], str. 133-135.

Oblast poznatku Procesy sledování a kontroly Výstupy

Řízení integrace projektu Sledování a kontrola prací na projektu

� Doporučená nápravná opatření, preventivní opatření a oprava závad




� Předpovídání � Požadované změny

Integrované řízení změn � Schválené požadavky na změny, nápravná opatření, preventivní opatření a oprava závad

� Zamítnuté požadavky na změny

� Plán řízení projektu (aktualizovaný)

� Stanovení rozsahu projektu (aktualizované)

� Validace opravy závad � Ucelené části projektu

Řízení rozsahu projektu Verifikace rozsahu projektu � Přijaté ucelené části projektu � Požadované změny � Doporučená nápravná

opatření Řízení změn v rozsahu � Stanovení rozsahu projektu

(aktualizované) � Rozpis prací WBS a slovník

(aktualizace) � Směrný rozsah projektu

(aktualizace) � Požadované změny � Doporučená nápravná



(aktualizovaný)

Řízení času v projektu Kontrola časového plánu � Plánování modelových dat (aktualizace)

� Směrný časový plán (aktualizovaný)

� Měření výkonnosti � Požadované změny � Doporučená nápravná


(aktualizace) � Seznam aktivit a atributů

(aktualizovaný) � Plán řízení projektu

(aktualizovaný)

Řízení nákladů v projektu Kontrola nákladů � Odhad nákladů (aktualizovaný)

� Směrné náklady (aktualizované)

� Měření výkonnosti � Předpověď dokončení � Požadované změny � Doporučená nápravná


(aktualizace)





Řízení kvality projektu Kontrola kvality � Měření kontroly kvality � Validace opravy závad a

ucelených částí projektu � Směrná kvalita (aktualizace) � Doporučená nápravná

opatření, preventivní opatření a oprava závad

� Požadované změny � Procesní aktiva v organizaci


(aktualizovaný) Řízení lidských zdrojů v projektu

Řízení projektového týmu � Požadované změny � Doporučená nápravná

opatření a preventivní opatření

� Procesní aktiva v organizaci (aktualizace)


Řízení komunikací v projektu Zprávy o výkonu � Zprávy o výkonu � Předpovědi � Požadované změny � Doporučená nápravná


(aktualizace) Řízení účastníků � Vyřešené problémy

� Schválené požadavky na změny a nápravná opatření



Řízení rizik v projektu Sledování a kontrola rizik � Registr rizik (aktualizovaný) � Požadované změny � Doporučená nápravná

opatření a preventivní opatření



Řízení obstarávání v projektu Administrativní zajištění smluv � Smluvní dokumentace � Požadované změny � Doporučená nápravná



(aktualizovaný)



Je dost pravděpodobné, že se v průběhu projektu nastanou nějaké změny (cíle, rozsah,

zdroje atd.), a proto je důležité vytvořit vhodný proces pro sledování a kontrolu změn. Podle

[SC1] sledování, neboli monitorování prací na projektu znamená shromažďování, měření a

rozšiřování informací o výkonu práce. Jeho součástí je také hodnocení změřených údajů a

analýza trendů, na základě které je možné stanovit další zlepšování procesů. Důležitými

vstupy do procesů sledování a kontroly prací na projektu jsou plán řízení projektu, informace

o pracovním výkonu, zprávy o výkonu a požadované změny. Mezi klíčové nástroje a

techniky používané v rámci tohoto procesu patří využívání vhodné metodologie řízení

projektu, informační systém pro řízení projektů, expertní či odborné posouzení a řízení

vytvořené hodnoty. Dvěma důležitými typy výstupu z procesů sledování a kontroly prací na

projektu jsou doporučená nápravná opatření a preventivní opatření.

3.4.4 Předávací fáze

Poslední fází, která završuje životní cyklus projektu, je přijetí, akceptace realizovaného

výstupu (produktu) ze strany účastníku projektu a zákazníka. V rámci ukončení projektu je

výstup spouštěn do provozu a je ověřováno, zda jsou všechny cíle projektu splněné. Průběh

projektu je zhodnocen a jsou získávány zkušenosti pro další projektu, a to i v případě

neúspěšného dokončení nebo zastavení projektu. Je navrženo využití zbývajících zdrojů a

členové týmu jsou přeřazení na jiné pozice. V rámci ukončení projektu je důležité ověřit, zda

jsou všechny ucelené části projekt kompletní. Podle [SC1] „při uzavírání projektu by členové

projektu měli mít definované určité zakončovací procedury, zajistit dodání finálního

produktu, služby nebo jiného výsledku projektu a aktualizovat procesní aktiva v organizaci,

jako jsou soubory projektu a zpráva s poučením“.

Rozbor jednotlivých oblastí poznatků spolu se závěrečnými procesy a jejich výstupy

shrnuje Tabulka 3-5, která vychází z publikace PMBOK ® Guide 2004, a kterou ve své

publikaci uvádí [SC1].



Tabulka 3-5 Výkonné procesy v projektu a jejich výstupy, zdroj [SC1], str. 138.


Řízení integrace projektu Ukončení projektu � Administrativní a smluvní postupy pro ukončení

� Finální produkt, služba nebo jiný výsledek projektu


Řízení obstarávání v projektu Ukončení smluv � Ukončená smlouva � Procesní aktiva v organizaci

(aktualizace)

[SC1] popisuje podrobně, co konkrétně znamenají výstupy v předávací, resp.

ukončovací fázi projektu:

� Administrativní a smluvní postupy pro ukončení. Pro projektový tým je důležité

vytvoření a dodržování přesného, po jednotlivých krocích popsaného postupu pro

ukončení projektu. Tyto postupy musí především definovat proces schvalování

veškerých ucelených částí projektu.

� Smluvní postupy pro ukončení. Často součástí projektu jsou různé smlouvy, což jsou

právně závazné dokumenty. Smluvní postupy pro ukončení popisují metodologii, podle

níž se zajistí regulérní dokončení projektu a naplnění smlouvy, včetně vlastní dodávky

zboží nebo služeb a provedení platby za ně.

� Finální produkt, služba nebo jiný výsledek projektu. Zadavatelé projektu mají

obvykle sami největší zájem na tom, aby dostali konečný produkt, službu nebo jiný

výsledek, který očekávali v okamžiku schválení projektu.

� Procesní aktiva v organizaci (aktualizována). Projektový tým by měl sestavit seznam

projektové dokumentace, dokumentů k ukončení projektu a historických informací

vzniklých za doby řešení projektu, a to v použitelném a srozumitelném formátu. Tyto

informace se považují za procesní aktivum.



4 FUNKCIONALITA ERP

4.1 Definice ERP (Enterprise resource planning)

Podle [GA1] „zkrátka ERP vyjadřuje v překladu plánování podnikových zdrojů. Hlavní

ideou je sjednocení podnikových funkcí na úrovní celé organizace, což vyjadřuje slovo

Enterprise. Úkolem ERP je vytvořit takovou informační podporu podnikovým procesům,

která bude realizována efektivně jednou konzistentní aplikací“.

Jak uvádí [GA1], „ERP (enterprise ressource planning) je charakterizován jako typ

aplikačního software, který umožňuje řízení a koordinaci všech disponibilních podnikových

zdrojů a aktivit. Mezi hlavní přednosti ERP patří schopnost automatizovat a integrovat

klíčové podnikové procesy, funkce a data v rámci celé firmy“.

ERP podle [GA1] umožňuje uživatelům:

� vytvářet rozsáhlé datové báze – zboží, dodavatelů, zákazníků, pracovníků, majetku,

účtů apod.

� realizovat procesy operačního charakteru, tj. zpracování obchodních případů – nákup

materiálů, prodej zboží a s tím souvisejících obchodních dokumentů (objednávek,

kontraktů, faktur, celních deklarací atd.)

� vytvářet a prezentovat požadované přehledy, statistiky a základní analýzy (přehledy

zákazníků, zboží, prodejů, stavu zásob na skladě apod.).

[BA1] uvádí, že „za ERP jsou považovány jednak aplikace, které představují

softwarová řešení užívaná k řízení podnikových dat a pomáhající plánovat celý logistický

řetězec od nákupu přes sklady po výdej materiálu, řízení obchodních zakázek od jejich přijetí

až po expedici, včetně plánování vlastní výroby a s tím spojené finanční a nákladové

účetnictví i řízení lidských zdrojů. ERP ovlivňuje podnikové procesy, které podporuje a v

mnoha případech automatizuje a je také úzce spjat s reengineringem podnikových procesů

(Business Procese Reengineering - BPR) a s projekty kvality ISO. Systém ERP ale může být

chápán i jako parametrizovatelný, tj. hotový software, který podniku umožňuje

automatizovat a integrovat jeho hlavní podnikové procesy, sdílet společná podniková data a

umožnit jejich dostupnost v reálném čase (real-time enviroment)“.



V neposlední řadě pak ERP představuje jádro podnikového informačního systému,

které spolu s aplikacemi SCM (Supply chain management), CRM (Customer relationship

management) a BI (Business Intelligence) tvoří rozšířené ERP, resp. ERP II.

4.2 Funkční moduly ERP

Jak uvádí [GA1], „modulární struktura ERP je důležitá pro udržení rovnováhy mezi

integrací a nezávislostí jednotlivých modulů. Modulární struktura umožňuje organizacím

implementovat jen ty moduly, které jsou relevantní pro její aktivity. ERP architektura

zahrnuje celou řadu modulů, jak aplikační (např. finance, prodej, výroba) tak i moduly, které

nemají provozní nebo podpůrný charakter“. Obecné schéma ERP architektury je znázorněno

na Obr. 4-1.

Obr. 4-1 Obecné schéma architektury ERP, zdroj [GA1], str. 66.

Aplikační moduly zajišťují dle [GA1] „funkcionalitu v jednotlivých oblastech řízení

podniku, tedy v řízení prodeje, nákupu, výroby, personalistiky. Dokumentační moduly

obsahují uživatelskou on-line dokumentaci k jednotlivým aplikačním modulům, funkcím a

jednotlivým zobrazovaným polím na obrazovce. Technologické a správní moduly jsou

Implementace

MetodikaMetodika

Procesy,funkce, Y

Procesy,funkce, Y

VývojVývoj

Aplikační moduly

Správa aplikace

Moduly rozhraní na databázové systémy, operační systémy, ostatní aplikace

Účetnictví,Hlavní knihaÚčetnictví,

Hlavní knihaPlánování

výroby

Plánovánívýroby

Plánovánívýroby

Plánovánívýroby

Lidskézdroje

Lidskézdroje

PohledávkyPohledávky Dílenskéřízení

Dílenskéřízení ProdejProdej Řízení

majetku

Řízenímajetku

ZávazkyZávazky Řízenívýrobků

Řízenívýrobků

Řízení zásob,sklady


MarketingMarketing Řízeníprojektů

Řízeníprojektů

KastomizaceKastomizace

Dokumentace,help

Dokumentace,help

Provoz-nastavení,přehledy


Přístupovápráva

Přístupovápráva

Implementace

MetodikaMetodika

Procesy,funkce, Y

Procesy,funkce, Y

VývojVývoj

Aplikační moduly

Správa aplikace




výroby

Plánovánívýroby

Plánovánívýroby

Plánovánívýroby

Lidskézdroje

Lidskézdroje



majetku

Řízenímajetku


Řízenívýrobků




Řízeníprojektů


Dokumentace,help

Dokumentace,help



Přístupovápráva

Přístupovápráva

Implementace

MetodikaMetodika

Procesy,funkce, Y

Procesy,funkce, Y

VývojVývoj

Aplikační moduly

Správa aplikace




výroby

Plánovánívýroby

Plánovánívýroby

Plánovánívýroby

Lidskézdroje

Lidskézdroje



majetku

Řízenímajetku


Řízenívýrobků




Řízeníprojektů


Dokumentace,help

Dokumentace,help



Přístupovápráva

Přístupovápráva



určeny pro nastavení přístupových práv uživatelů k datům a funkcím ERP, moduly pro

evidenci a analýzy operací provedených funkcemi ERP, moduly pro prvotní nastavení

provozních pravidel, strukturu komunikace. Implementační moduly jsou využívané

k přípravě a nasazení ERP v daném podnikovém prostředí. Tyto moduly obvykle slouží

k definování a optimalizaci podnikových procesů, k definování funkcionality, k určování

typů uživatelů a jejích role. V rámci této skupiny modulů jsou obvykle začleněny celé

implementační příručky, doporučené metodiky, jak daný ERP systém připravit a nasadit

v konkrétních podmínkách podniku. Customizační moduly slouží k úpravám software podle

konkrétních potřeb organizace. Některé ERP systémy mají integrované vlastní vývojové

prostředí, které umožňuje použití vlastních programovacích prostředků nebo jazyku

k úpravě funkcionalit systému. Tzv. interface moduly neboli moduly rozhrání, umožňují

komunikaci se základním software, tedy s databázovým a operačním systémem, případně

s dalšími typy aplikací a technologií“.

Podle [BA1], „ERP v podniku zahrnují zejména následující hlavní činnosti, které

souvisejí:

� se správou kmenových dat (především všech položek, kusovníků, technologických

postupů, pracovišť, ale rovněž dodavatelů, zákazníků, skladových míst, používaných

druhů dani, finančních kursů, kont apod.);

� s dlouhodobým, střednědobým i krátkodobým plánováním zdrojů potřebných pro

realizace obchodních zakázek;

� s řízením realizace těchto zakázek z hlediska dodržování terminů;

� s plánováním a sledováním nákladů realizace, zejména výroby a

� se zapracováním výsledků všech aktivit do finančního účetnictví a controllingu.“

ERP tak pokrývají zejména dvě hlavní funkční oblasti:

� logistiku - v kontextu ERP zahrnují celou podnikovou logistiku, tj. výše uvedený

nákup, skladováni, výrobu, prodej (distribuci) a zejména plánováni zdrojů;

� finance - zahrnuji finanční, nákladové a investiční účetnictví a dále podnikový

controlling.



4.2.1 Primární proces podniku - logistika (prodej, nákup, skladování a výroba)[čerpáno z pramenu BA1]

Schéma na Obr. 4-2 zachycuje komplexnost ERP z hlediska primárního procesu

logistiky každého podniku, za nímž se skrývá ucelené zajištění požadavku zákazníka.

Vyznačená oblast plánování v pravé části schématu zvýrazňuje jádro ERP, které je založeno

nejčastěji na principech MRPII (Manufacturing Resource Planning).

Obr. 4-2 Zpracování obchodního případu v ERP, zdroj [BA1], str. 68.

Cyklus logistiky obchodního řetězce tedy obvykle zahrnuje zpracování posloupnosti

následujících úloh:

� přijetí obchodního případu,

� vytvoření objednávky, její obsahová, termínová a cenová specifikace, a to na základě

kmenových dat, případné konfigurátorů produktů,

� plánování potřebných materiálových požadavků včetně zpracováni návrhů na nákup,

výrobu a kooperace,

� objednání a nákup zboží a služeb od dodavatelů.



� zajištění skladového hospodářství a řízení zásob včetně správy obalů, kontejnerů a

nebezpečných odpadů,

� plánování výrobních i předvýrobních kapacit,

� řízení realizace výrobní zakázky včetně sběru zpětnovazebních dat z výroby,

� přichystáni a expedice hotových výrobků,

� archivace zakázek a souvisejících dalších dat.

Z hlediska výrobních a distribučních podniků je zásadní schopnost ERP podporovat

procesy logistického řetězce od odbytu přes nákup až po výrobu. Logistické procesy se

spojují do komplexního jednotného organizačního celku, který zjednodušuje a urychluje

provádění operativních činnosti, zlepšuje tok informaci a na základě konzistentních dat

usnadňuje tržní rozhodování v oblasti plánování a dispozic. V případě distribučních podniků

je situace jednodušší, protože není zahrnuta část výroby.

Z hlediska plánování zdrojů pak ERP dále integrují systémy pro plánování a řízení

údržby, které zajišťují rovněž správu objektů údržby, řízení a plánování údržby.

Další důležitou a stále více žádanou funkční součástí ERP se stává podpora

projektového řízení. Důvodem je tendence k individualizaci zakázek pro jednotlivé

zákazníky; zakázky tak stále více získávají charakter projektu.

4.2.2 Finance podniku[čerpáno z pramenu BA1]

Základem finančního účetnictví je vedení všech finančních operací podniku, které

zahrnuje zejména vedení hlavní účetní knihy, saldokonta dodavatelů a odběratelů, správu

investičního majetku a finanční konsolidaci. Celkový rozsah obvykle zahrnuje:

� Finanční účetnictví - hlavní kniha, pohledávky, závazky, konsolidace, pokladna,

elektronický bankovní styk.

� Nákladové účetnictví - účetnictví nákladových středisek, účetnictví ziskových

středisek, nákladové účetnictví zakázek a projektů, zúčtování výkonů, procesní řízení,

podpora ABC (Activity Based Costing).

� Controlling - kontinuální a aktuální řízení nákladů, výnosů, zdrojů a termínů. Zapojení

obchodního případu do všech oblasti controllingu je předpokladem podrobných analýz

plánu a skutečnosti. Jedná se o klíčový nástroj pro strategické plánování s

respektováním specifičností jednotlivých zemí a podporující možnosti reportingu.

� Správa a účtování investičního majetku, plánování a sledování nedokončených investic

a investičních akcí hospodaření s investicemi provází celý životní cyklus investičního



majetku. Integrace pomocí aplikací účetnictví a logistiky podporuje nejrůznější

přístupy pro kontrolní a řídicí zásahy a pro optimální využíváni podnikových investic.

� Řízení hotovosti, předpověď likvidity, předpovědi cash-flow. finanční plánování a

rozpočty, řízení rizik, peněžní obchody, měnové transakce a transakce s cennými

papíry.

� Výpočet a účtování mezd.

� Výkaznictví dle jiných účetních norem (např. IAS, IFRS, GAAP).

� Účtování v cizích měnách a kurzové rozdíly.

Podkladem operací v účetnictví jsou data z jednotlivých účetních dokladů. Po jejich

zaúčtování je možno prohlédnout si údaje příslušných účtů (obraty na účtech a stavy na

účtech) a též provést vyhodnocení rozvahy a výkazu zisků a ztrát. V IS bývá aplikován

princip integrovaného zpracování všech dat z dokladů, čímž je dosahováno synchronní

aktualizace informací ve finančním účetnictví, ale i v ostatních modulech IS.

Nedílnou součástí finanční funkcionality podnikových IS se stala na počátku tohoto

desetiletí i integrace a harmonizace ve vztahu k legislativě EU a integrace eura. Účetnictví by

dále mělo splňovat obecně uznávané účetní postupy Souboru obecně přijatých účetních

zásad - například GAAP (Generally Accepted Accounting Principles) a mělo by být

aplikováno na lokální podmínky i v době měnících se legislativních opatřeni.

U ekonomických IS pro malé a střední podniky se obvykle ještě v nabídce vedle

funkcionality týkající se logistiky objevují moduly, jako jsou knihy jízd, propojení na

MS Office, propojení na internetový obchod, homebanking apod.

V souvislosti s ekonomickou částí podnikových IS ještě připomeňme, že to byla právě

počítačová podpora účetnictví, kterou chtěly české podniky prostřednictvím ERP v rámci

změn na počátku devadesátých let zpracovat jako první, protože byly vedeny snahou vyhovět

požadavkům legislativy. Teprve následně v mnoha případech při hledání účinnějších nástrojů

docházelo i na odpovídající podporu řízení výroby, a tím na komplexní řešení typu ERP.

4.2.3 Personalistika - lidské zdroje[čerpáno z pramenu BA1]

Personalistika (resp. lidské zdroje - Human Resources) je v ERP třetí důležitou oblastí.

Jedná se o zpracování informaci použitelných pro získání, optimální naplánování a využívání

pracovníků, Tato oblast zahrnuje předpovědi budoucích požadavků na množství a kvalifikaci

pracovníků, identifikaci profilu zaměstnance, analýzu práce a podporu nalézání a najímání

nových pracovníků.



Základ funkčnosti představuje správa kmenových dat o zaměstnancích, plánování

personálního rozvoje, kam patří i správa uchazečů,

Systémy tohoto typu slouží ke zpracování plánů kvalifikaci a k plánování personálních

nákladů, například formou ročních výhledů mezd zpracovaných cestou extrapolace.

Obsaženy mohou být plány akcí a jejich vyhodnocení, plány vzdělávání a kvalifikace, funkce

časového managementu, plánování pracovní doby a nasazení personálu, zpracování a

vyhodnocování mezd a pracovních cest.

Specifikum této oblasti je zároveň skutečnost, že vyžaduje přísně definovaný přístup k

důvěrným personálním informacím. Ty musejí být navíc uchovávány mnohdy dlouhodobě,

přičemž doba archivace můze dosahovat až desítky let, například z důvodů poskytnuti

informací o odpracovaných rocích pro účely stanovení dávek sociálního zabezpečení,

například důchodů.

4.3 Základní informace o společnosti SAP AG

Společnost SAP byla založena v roce 1972 ve městě Walldorf, Něměcko. Název je

zkratkou od „Systeme, Anwendungen, Produkte in der Datenvarenbeitung“, což znamená

„Systémy, aplikace a produkty v zpracování dat“. SAP se postupně vyvinul ve společnost

s více než 9000 vývojovými a výzkumnými pracovníky kteří se přizpůsobují tržním

podmínkám a požadavkům a snaží se nabízet stále lepší business řešení. Společnost je

předním světovým poskytovatelem software ERP (plánování podnikových zdrojů).

S více než 30 let zkušeností jsou využívány ve více než 25 průmyslových odvětvích a

cca 34.600 podnicích, odhaduje se, že SAP má přibližně 120 milionů uživatelů ve více než

120 zemích po celém světě. S takovou impozantní historií není překvapující, že dnes SAP

nabízí širokou škálu řešení, produktů a aplikací. mySAP ERP je jednou z aplikací v rámci

mySAP Business Suite, který zahrnuje:

� mySAP ERP

� mySAP Supply Chain Management (SCM)

� mySAP Customer Relationship Management (CRM)

� mySAP Supplier Relationship Management (SRM)

� mySAP Product Lifestyle Management (PLM)

V době psaní této diplomové práce nejnovější verze systému mySAP ERP je SAP ERP

Central Components (ECC6).



4.4 Základní moduly ERP SAP

ERP SAP je modulový systém, to znamená, že se skládá ze samostatných, do určité

míry na sebe nezávislých částí. Toto přináší určité výhody z hlediska vývojáře a z hlediska

uživatele systému. Z hlediska vývoje je tímto možné rozdělit systém na jednotlivé menší

prvky, ve kterých je možné provádět vývoj nezávisle na sobě, čímž se snižuje komplexnost

systému, potencionální chybovost a čas na implementace řešení. Na druhou stranu je třeba

brat zřetel na rozhraní mezi ostatními moduly tak, aby nedocházelo k nekonzistenci dat.

Výhody pro uživatele, resp. zákazníka jsou především finanční úspory. Zákazník si muže

vybrat, jaký modul a v jakém rozsahu chce používat.

SAP ERP je rozdělen na tři základní funkční oblasti: Logistická, Finanční a Řízení

lidských zdrojů (Human Resources). Každá z těchto oblasti je rozdělena na specifické

moduly. Navíc existují specifická řešení pro odvětví (IS), například:

� IS-OIL pro společnosti zpracovávající naftu

� IS-T pro telekomunikační sektor

� IS-B pro banky

� IS-Retail pro retailové společnosti (obchodní domy a řetězce)

Jak již bylo řečeno, tři hlavní funkční oblasti obsahují v sobě jednotlivé moduly.

� Výroba a Logistika

Logistika je největší z funkčních oblastí. Zahrnuje tyto hlavní moduly:

� SD – Sales and Distribution

� MM – Materials Management

� PP – Production planning and Control

� LE – Logistics Execution

� QM – Quality Management

� CS – Customer Service

� F&R – Forecasting and replenishment

� Finance

� FI – Financial Accounting (Finanční účetnictví)

� CO – Controlling (Nákladové účetnictví)

� EC – Enterprise Controlling

� IM – Investment Management



� PS – Project system

� Řízení lidských zdrojů (Human Resources)

Personalistika obsahuje podporu mzdového účetnictví, administraci výplat a plánování

lidských zdrojů modul obsahuje podporu pro mzdy a mzdové účetnictví, i oblasti, jako je

pracovní rozvrh modelů.

Tato funkční oblast obsahuje mimo jiné i následující moduly

� PA – Personnel Administration

� PT – Personnel Time Management

� PY – Payroll

Obr. 4-3 SAP R/3 Systém, zdroj [BA2]

Kuročkin Michal

4.5 Vývojové procesy ERP SAP

V každé organizace neustále dochází ke změn

legislativní změny) tak i z důvodů interních (change management aktivity, projekty, opravy

chyb). Tyto změny se musí odrážet na informačním systému. Otázkou však zůstává, jak

provádět vývoj a testování změn tak, aby aktuální procesy společnosti nebyly ovlivněny

předimplementační fází. Z toho

budou od sebe izolovány, a vývojové a testovací aktivity neovlivní

Obvykle jsou v organizacích využívané tři vrstvy:

� vývojové prostředí,

� testovací, resp. zabezpečení jakosti,

� produktivní prostředí.

Na Obr. 4-4 je znázorněn klasický vývojový model.

Obr. 4-4 Vývojové procesy a prostředí

V některých organizacích se

systémy zajištění kvality, nebo speciální

systému (dvouvrstvé prostředí).

4.5.1 Vývojové prostředí (Development environment)

V tomto prostředí se provádí veškerá customizace a vývoj. Daný systém neobsahuje

kmenové ani transakční záznamy z

v rámci testování v průběhu vývoje. Každá customizace nebo vývoj vytváří tzv. transportn

požadavek, který v sobě obsahuje obsah tabulek nebo program, který byl vyvinut. Tento

transport se následně uvolňuje do testovacích systémů.

4.5.2 Prostředí zabezpečení jakosti (Quality assurance environment)

Testovací systém, neboli prostředí zabezpečení jakosti, je obvykle kopií produktivního

systému, tzv. refresh. Refresh se provádí podle předpisu jednotlivých firem, obvykle jednou

Development env.

Vývojové prostředí

transport


Vývojové procesy ERP SAP

organizace neustále dochází ke změnám, a to jak z důvodů externích (např.

důvodů interních (change management aktivity, projekty, opravy

odrážet na informačním systému. Otázkou však zůstává, jak

t vývoj a testování změn tak, aby aktuální procesy společnosti nebyly ovlivněny

toho důvodu je v ERP SAP možnost vytvořit tzv. prostředí, které

vývojové a testovací aktivity neovlivní produktivní chod fi

organizacích využívané tři vrstvy:

testovací, resp. zabezpečení jakosti,

je znázorněn klasický vývojový model.

a prostředí ERP SAP

některých organizacích se využívají i jiné modely – čtyřvrstvé prostředí se dvěma

, nebo speciální virtuální testovací režim v rámci

(dvouvrstvé prostředí).

Vývojové prostředí (Development environment)

tomto prostředí se provádí veškerá customizace a vývoj. Daný systém neobsahuje

kmenové ani transakční záznamy z produktivních systémů, ale pouze záznamy, vytvořené

průběhu vývoje. Každá customizace nebo vývoj vytváří tzv. transportn

sobě obsahuje obsah tabulek nebo program, který byl vyvinut. Tento

následně uvolňuje do testovacích systémů.

edí zabezpečení jakosti (Quality assurance environment)

neboli prostředí zabezpečení jakosti, je obvykle kopií produktivního


transport

Quality assurance

Testovácí prostř.

Production env.

Produktivní prostř.

transport

refresh


Str. 49

důvodů externích (např.

důvodů interních (change management aktivity, projekty, opravy

odrážet na informačním systému. Otázkou však zůstává, jak

t vývoj a testování změn tak, aby aktuální procesy společnosti nebyly ovlivněny

vytvořit tzv. prostředí, které

produktivní chod firmy.

čtyřvrstvé prostředí se dvěma

rámci produktivního

tomto prostředí se provádí veškerá customizace a vývoj. Daný systém neobsahuje

záznamy, vytvořené

průběhu vývoje. Každá customizace nebo vývoj vytváří tzv. transportní

sobě obsahuje obsah tabulek nebo program, který byl vyvinut. Tento

edí zabezpečení jakosti (Quality assurance environment)

neboli prostředí zabezpečení jakosti, je obvykle kopií produktivního


Production env.

Produktivní prostř.



nebo dvakrát za rok. Tento systém poskytuje prostředí, které nejvíce odpovídá

produktivnímu. Transportní požadavky z vývojového systému se importují do tohoto

testovacího systému, kde provádí testy jak samotní konzultanti a vývojáři, tak i vlastníci

systému. Po dokončení testovacích aktivit se transportní požadavky importují do

produktivních systémů.

4.5.3 Produktivní prostředí (Production environment)

Na produktivních systémech běží procesy firmy. V průběhu tzv. release se prování

import balíčku změn, uskutečněných za určité období. Periodicky, podle zvyklosti firmy, se

provádí kopie produktivního systému do testovacího, aby testovací prostředí bylo co nejvíce

odpovídající produktivnímu.

4.6 Použité SAP pojmy

V této části bych chtěl vysvětlit několik klíčových SAP pojmů, které budou použité

v praktické části, a bez jejích vysvětlení by bylo problematické pochopení smyslu textu.

Transakční měna – je měnou dokladu. Transakční měnou může být jakákoliv

existující měna.

Lokální měna – je firemní měnou, ve které organizace vyhotovuje roční uzávěrky pro

státní orgány a tato měna je použitá jako domácí měna v zemi, kde se nachází sídlo

organizace.

� Při účtování dokladu, ve kterém měna dokladu (transakční) se rovná firemní měně

(lokální), je použito pouze jedno pole pro lokální částku, protože transakční měna se

rovná se lokální.

� V případě, že účtování dokladu v cizí měně, systém používá navíc dodatečná pole, kde

uvádí částku v cizí měně, měnu dokladu a přepočítací kurz.

Organizační data – jedna se o první úroveň dat, kde se provádí nastavení,

charakteristická pro konkrétní organizaci, jako název společnosti, firemní měna, organizační

jednotky, sklady, pracovní úseky atd.

Kmenová data – kmenová data jsou, takové záznamy jako kusovníky, artikly,

zaměstnance, dodavatelé, odběratelé, účty hlavní knihy, majetkové karty atp. Tento druh dat

se přiřazuje k organizační jednotce (např. dodavatel CCC je přiřazen k nákupní jednotce A).

Jednotlivý kmenový záznam může být přiřazen k více organizačním jednotkám.

Transakční data – jsou doklady a položky dokladu, historii pohybu artiklu a

materiálů.



5 PROJEKT KONVERZE MĚNY NA EURO

5.1 Základní informace o firmě Kaufland

Skupina Kaufland patří k vedoucím maloobchodním řetězcům Německa. Provozuje

přes 700 obchodů v Německu, České republice, Slovenské republice a také v Polsku,

Chorvatsku, Rumunsku a Bulharsku. Společnost provozuje obchody pod názvem

„Kaufland“, „KaufMarkt“ a „Handelshof". Samoobslužné obchodní domy a spotřebitelské

obchody disponují plochou od 2 500 do 12 000 m2. V obchodech jsou bohaté nabídky jak

vlastních značek, které nabízejí kvalitní produkty za diskontní ceny, přes produkty od

regionálních výrobců, až k značkovým výrobkům. Důležitým bodem obchodních domů

Kaufland jsou oddělení s čerstvým zbožím. Ať už jde o maso, uzeniny, sýry a mléčné

výrobky nebo ovoce a zeleninu, Kaufland zaručuje svým zákazníkům denně absolutně

čerstvé zboží a kvalitu za skvělé ceny. Vedle potravin nabízí obchodní dům Kaufland i

aktuální, velmi atraktivní a cenově výhodné zboží v oddělení domácích potřeb, skla,

porcelánu, textilu, elektra, papírnictví či hraček. V prodejnách se prodávají i výrobky pro

volný čas, sezonní nabídky a mnoho dalších věcí, stejně jako týdně se měnící akční zboží.

Nabídku obchodního domu Kaufland doplňují ještě menší služby a maloobchodní firmy1.

Z pramenu [KA3] „společnost Kaufland ČR, která v Česku provozuje síť

hypermarketů, v hospodářském roce 2007/2008 vzrostl zisk na 1,077 miliardy korun z 978

milionů Kč v roce předchozím. Kaufland tak patří mezi nejziskovější maloobchodní řetězce v

České republice“.

5.1.1 Historie společnosti Kaufland [čerpáno z pramenu KA2]

V roce 1930 Josef Schwarz vstupuje jako společník do velkoobchodu s jižním ovocem

Lidl & Co. v Heilbronnu. Společnost je přejmenována na Lidl & Schwarz KG a je

přeměněna v potravinářský velkoobchod. Výstavbu firmy přerušila druhá světová válka. Po

jejím ukončení následovala obnova válečnými událostmi zničené společnosti. V roce 1998

došlo k prvního obchodního domu Kaufland v Ostravě v České republice, následně v roce

2000 na Slovensku se otevírá první OD Kaufland v Popradu. V roce 2001 v Chorvatsku se

otevírá první Kaufland v Karlovaci. Polsko následuje s prvním Kauflandem ve Stargardu

Szczecinski. Rok 2005 je významný tím, že společnost nadále expanduje doma i v zahraničí.

V tomto roce slaví 75. výročí založení společnosti v Evropě a 7. výročí v České republice. V

1 Zdroj [KA1]



Rumunsku se otevírá první OD Kaufland v Bukurešti. V Bulharsku v roce 2006 se otvírá

první OD Kaufland v Plovdivu.

5.2 Organizační struktura společnosti

Organizační struktura firmy Kaufland je maticová s tím, že každé oddělení má

projektovou kancelář, kde se koordinují a plánují projekty. Retail, neboli organizační

jednotka prodeje a nákupu zboží, se zabývá tzv. „core“ byznysem – nákupem a prodejem

zboží, logistikou a reklamou. V rámci retailingového byznysu je také vlastní výroba –

„masozávod“. Organizační jednotka pod německou zkratkou „BEWV“ má na starosti

organizaci pronájmu prostor v obchodech, technický nákup – znamená to nákup regálů,

nábytku a kancelářských potřeb a nakonec expanze – hledání nových lokalit pro expanzi.

Administrativní oddělení se stará o finanční řízení organizace, controlling, a personalistiku.

Oddělení IS se stará o správu informačních systémů, SAP, rozhrání mezi systémy a

projektové řízení. Na Obr. 5-1 je zobrazena obecná organizační struktura podniku.

Obr. 5-1 Organizační struktura společnosti Kaufland

Vedení společnostiVedení společnosti

Zboží / RetailZboží / Retail BEWVBEWV AdministraceAdministrace ISIS

Nákupzboží

Nákupzboží

Prodejzboží

Prodejzboží

LogistikaLogistika

Reklama / Časopis

Reklama / Časopis

MasozávodMasozávod

PronájemPronájem

Technickýnákup

Technickýnákup

FinanceFinance

ControllingControlling

ÚčetnictvíÚčetnictví

HRHR

Nákup / Prodej zboží

Nákup / Prodej zboží

Administrace / správa

Administrace / správa

InfrastrukturaInfrastruktura

Service deskService desk

IT Qualitymanagement

IT Qualitymanagement

ExpanzeExpanze

Kuročkin Michal

5.3 Architektura IS firmy

Politika firmy pro architekturu IS ve firmě KAUFLAND je taková, že každá země má

mít vlastní systém, což sice zvyšuje TCO (total cost of ownership), ale na druhou stranu

zvyšuje flexibilitu při odstávkách

odstavek ve všech zemích. Dalším důvodem je provádění pravidelných tzv. „refresh“ aktivit,

to znamená kopírování produktivního systému do testovacího prostředí.

rozhrání a nastavení, nutných pro uvedení systému do testovacího

technický náročná.

Česká republika a následně i Slovenská republika byly první země, kam společnost

expandovala. V té době se ještě nevědělo o rozsahu expanze, a proto

země byla provedena v jednom systému.

tuto zemi již byl použit oddělený systém.

Před zahájením projektu Euro konverze, v

společný systém, Česká republika a Slovensko. S

Centrální

vývojový systém


Architektura IS firmy Kaufland



zvyšuje flexibilitu při odstávkách a údržbě systému – není nutno harmonizovat

Dalším důvodem je provádění pravidelných tzv. „refresh“ aktivit,

to znamená kopírování produktivního systému do testovacího prostředí. Změna jednotlivých

rozhrání a nastavení, nutných pro uvedení systému do testovacího režimu, by byla časově a


té době se ještě nevědělo o rozsahu expanze, a proto implementace pro tyto

jednom systému. Následující expanze byla provedena v

tuto zemi již byl použit oddělený systém.

Před zahájením projektu Euro konverze, v koncernu zůstaly dvě země, které měly

společný systém, Česká republika a Slovensko. S novým projektem se vyskytla příležitost

Lokální test. systém

1


2


Y


n






Str. 53



není nutno harmonizovat plánování

Dalším důvodem je provádění pravidelných tzv. „refresh“ aktivit,

Změna jednotlivých

režimu, by byla časově a


implementace pro tyto

ledující expanze byla provedena v Polsku, a pro

koncernu zůstaly dvě země, které měly

novým projektem se vyskytla příležitost


1


2


Y


n

Kuročkin Michal

dokončit strategii „jedna země

systém, na kterém běží česká a slovenská data.

Každá země navíc má SAP systémy zvlášť rozdělené na

Finance (Backend), Personalistiku (Human resources) a Skladové hospodářství (Stock

management).

Níže na Obr. 5-2 je uvedená procesní mapa společnosti.

Obr. 5-2 Procesní mapa společnosti Kaufland

5.4 Cíle projektu

Hlavním cílem projektu je zajistit přechod k

po provedení účetních uzávěrek a auditu uskutečnit lokální konverzi měny, tj. konverzi

veškerých hodnot v lokální měně SKK na lokál

Dalším cílem je tvorba mezinárodní šablony pro

budou shromážděné veškeré technické a business dokumentace, zdokumentovány rizika a

„know-how“ k projektu.

Třetím cílem je finalizac

systém“. Jak již bylo uvedeno, v

slovenských společností. Díky projektu Konverze měny se vyskytla příležitost rozdělit tyto

systémy.

Obchody

Pokladny (POS)

Pohyby zboží

Human Resources

HR Mzdy


dokončit strategii „jedna země – jeden systém“ tím, že bude v rámci projektu rozdělen

tém, na kterém běží česká a slovenská data.

Každá země navíc má SAP systémy zvlášť rozdělené na čtyři - Logistický (Frontend),

ersonalistiku (Human resources) a Skladové hospodářství (Stock

je uvedená procesní mapa společnosti.

Procesní mapa společnosti Kaufland

ílem projektu je zajistit přechod k použití měny EUR k 1.1.2009 a následně


lokální měně SKK na lokální měnu EUR.

Dalším cílem je tvorba mezinárodní šablony pro budoucí konverze lokálních


finalizace strategie architektury IS společnosti – „jedna země, jeden

Jak již bylo uvedeno, v jednom systému se nachází produktivní data českých a


Frontend

SD / MM

Backend

AM / FI / CO / PS

Pohyby zboží

Účetn

í d

ata

Analytika

Mzdy

Objedn. zboží


Str. 54

rámci projektu rozdělen

Logistický (Frontend),

ersonalistiku (Human resources) a Skladové hospodářství (Stock

1.1.2009 a následně


budoucí konverze lokálních měn, kde


„jedna země, jeden

chází produktivní data českých a


Data warehouse

DWH

Stock management

LE



Posledním z cílů je optimalizace archivačních procesů. Systémy v nejlepším případě

mají být vyčištěny od starých dat a mělo by se nastavit co nejvíce automatických

archivačních úloh jak v českém a slovenském systému, tak i provést implementaci těchto

řešení na ostatní země, kde funguje organizace.

5.4.1 Základní fáze přechodu na euro a dopad na ERP systém

Ke každé fázi přípravy přechodu na euro systém musí být připraven, aby odpovídal

legislativním požadavkům státu. Proto struktura projektu by měla také odpovídat těmto

fázím.

Obr. 5-3 Dopad legislativních požadavků na harmonogram projektu, Převzato z SAP AG a upraveno dle plánu projektu

2007 2008 2009

Vyhlášení měnové reformy

Konec duálního ocenění

Povinné duální ocenění

Platnost nové měny

Výkazy v nové měně

Legislativnípohled

Projektový pohled

Customizace měny

Duální ceny

Reporting

Nastaveníexpirované

měny

Konverze lokálníměny

TC: EURLC: SKK

TC: EURLC: EUR

Transakční měna (TC): SKKLokální měna (LC): SKK



Tabulka 5-1 Rozpis dopadu legislativních požadavků na systém

Fáze dle legislativy Legislativní požadavky Změny v systému

První fáze:

ERM II (Listopad 2005 –

Prosinec 2008)

� Nastavení fluktuačního

pásma (± 15%).

� Tato etapa nemá vliv na chod

systému SAP.

Druhá fáze:

Duální ocenění a příprava ke

konverzi

� V období od července 2008

do prosince 2009 je povinné

zobrazení duálních cen. Po

dobu dalších šesti měsíců je

volitelné

� Duální ocenění produktů,

služeb, účtenek a faktur,

zbožových katalogů, mezd

atd.

� Měna v kmenových datech

(Odběratelé, dodavatelé,

cenové podmínky atd.) musí

být změněna na euro.

Všechny tiskové výstupy

musí být překontrolovány, a

v případě nutnosti změny

musí být změněny pro tisk ve

správném formátu (duální

zobrazení EUR a SKK) a ve

správném konverzním kurzu.

Třetí fáze:

Hotovostní oběh euro a placení

ve měně euro

� Od 1.1.2009 Euro se používá

v oběhu, pro placení a

transakce.

� V hotovostním oběhu SKK je

akceptována do 16.1.2009

(duální oběh měny)

� Pokračování zobrazení duální

měny

� Po provedení roční uzávěrky

se musí provést customizace

systému, relevantní pro

změnu měny, provede se

náhrada měny SKK na EUR

přímo v databázi

s vyrovnáním a přeúčtováním

zaokrouhlovacích rozdílů.

Příprava k této fáze musí být

zahájena minimálně 6 měsíců

dopředu. Doporučuje se

nastavit zvláštní systém

(hardware) pro tuto fázi,

s tím, že může být využíván

jako archivní se „starou“

měnou.



5.5 Organizační struktura projektu

Na Obr. 5-4 je zobrazena struktura projektu, která zahrnuje sedm dílčích podprojektů:

Obr. 5-4 Organizační struktura projektu, zdroj [KA0]

1. Rozdělení systému - rozdělení jednoho systému na dva – Český a Slovenský a výmaz

redundantních dat ze systémů (výmaz českých dat ze slovenského systému a naopak,

výmaz slovenských dat z českého systému).

2. Konverze transakční měny - příprava k transakční konverzi měny, která bude

prováděna v průběhu roku s vyvrcholením aktivit 1.1.2009, kdy se pro všechny

procesu nastaví výchozí transakční měna EUR. Tato fáze je z podstatné části důležitá

pro logistické procesy (objednávání, cenovky, akceptace euro měny v pokladnách).

3. Konverze lokální měny - bude spuštěna bezprostředně po účetní uzávěrce a účetním

auditu. Musí být vygenerováno co nejvíce výkazů a reportů, jelikož se provede

nenávratná operace přepočítávání částek v lokální měně SKK na EUR, a od tohoto

momentu se lokální firemní měnou stane EUR. Plánované zahájení je ve druhé

polovině měsíce března.

4. Příprava mezinárodní šablony - příprava na budoucí případné konverze měn

v dalších zemích. Provede se analýza projektu, aktualizace business a technické

dokumentace, dokumentace know-how.

5. Zabezpečení architektury IS - podpora v průběhu trvání projektu ze strany IS,

zajištění odstávek, autorizací instalací testovacích a produktivních systémů.

Manažer kvalityManažer kvalityŘídící výborŘídící výbor

AsistenceAsistence

System split

Rozdělenísystému

System split

Rozdělenísystému

Transact. currency

conversion

Konverze transakční

měny

Transact. currency

conversion

Konverze transakční

měny

Localcurrency

conversion

Konverze lokální měny

Localcurrency

conversion

Konverze lokální měny

Internationaltemplate

Mezinárodníšablona

Internationaltemplate

Mezinárodníšablona

Systemarchitecture

Architektura IS

Systemarchitecture

Architektura IS

Testing

Testování

Testing

Testování

Archiving

Archivace

Archiving

Archivace

Projektovýmanažer

Projektovýmanažer

11 22 33 44 55 66 77



6. Testování - testování systémů a funkčnosti procesů před produktivním startem

systémů.

7. Archivace - příprava systému pro nejrychlejší rozdělení a konverzi měny na EUR,

cílem je, aby co nejmenší objem dat zůstal v produktivním systému.

5.6 Specifické subjekty projekčního týmu

V rámci projekčního týmu jsou kromě standardních subjektů, jako projekt manažer,

podprojekt manažer atd. jsou definovány subjekty specifické pro prostředí SAP:

� Super uživatel národní (Superuser National, SUN) – odpovídají za business procesy

v rámci jednoho státu. Navrhují změny nebo optimalizaci procesů dle firemních

podmínek nebo legislativních požadavků. Další odpovědnosti je kontrola správnosti

navrženého řešení konzultanty, testování funkčnosti a schválení pro uvolnění do

produkčního prostředí. Poskytují také podporu pro klíčové a koncové uživatele.

� Super uživatel mezinárodní (Superuser International, SUI) – odpovídají za

harmonizaci firemních procesů na mezinárodní úrovni. Každý návrh ze strany SUN se

musí analyzovat, zda to nejde aplikovat i v ostatních zemích a následně a schválit pro

zahájení přípravy technického řešení ze strany konzultantů a vývojářů.

� SAP konzultant - podle business konceptu a požadavků od SUN navrhují technické

řešení. Řešení je obvykle implementováno přes customizing nebo vývoj.

5.7 Plánování projektu

5.7.1 Harmonogram projektu

Projekt oficiálně začal 3.3.2008 a má být oficiálně ukončen 29.5.2009. Před samotným

tzv. „Kick-off“ meetingem byla předběžná organizační příprava – plánování projektu,

sestavení projektových týmu, výběr řešení pro způsob konverze měny a rozdělení systému

atd.

Mezi hlavními milníky projektu patří:

� Rozdělení systému (červen)

� Spuštění duálního ocenění (srpen)

� Výmaz redundantních dat ze systémů (listopad pro slovenský systém, prosinec pro

český systém)

� Konverze transakční měny (1.1.2009)

� Konverze lokální měny (konec března 2009).



Na Obr. 5-5 je zobracen harmonogram projektu. Jednotlivým podprojektům a

milníkům budou věnovány následující kapitoly.

Obr. 5-5 Harmonogram projektu

5.7.2 Využití zdrojů projektu

Projekt Konverze měny je považován v organizaci k časově a investičně náročným

projektům z důvodu časového tlaku, nemožnosti zpoždění kvůli legislativním požadavkům a

nakonec účelu dosáhnou více cílů v rámci projektu. Celková kapacita projektu z hlediska

využití zdrojů je přibližně 6100 člověkodní. Největší vytížení připadá na květen-červen a

říjen roku 2008. Je to dáno tím, že jednak probíhají přípravné práce, v rámci kterých se

připravují technické a business dokumentace, kde se mapuje aktuální stav systému a

požadavky, jak systém má vypadat, a na druhou stranu v této době probíhá produktivní fáze

archivace dat, rozdělení systému, a implementace duálních cen. V září se začíná intenzivně

testovat a školit na připravených testovacích systémech, kde již proběhly první testy

konverze transakční a lokální měny – testuje se „virtuální“ první leden roku 2009.

20092008VIVIIIIIIXIIXIXIXVIIIVIIVIVIVIIIII

20092008VIVIIIIIIXIIXIXIXVIIIVIIVIVIVIIIII

3.3 Kick Off Konec projektu 29.5

7: Archivace7: Archivace

3: LCC3: LCC

4: Mezinárodníšablona

4: Mezinárodníšablona

6: Testování

2: TCC2: TCC

Duální oceněníDuální ocenění

TCCTCC

1: Rozdělení + Výmaz dat (DCC)1: Rozdělení + Výmaz dat (DCC)

RozděleníRozdělení

Výmaz dat (DCC)Výmaz dat (DCC)

1: Rozdělení + Výmaz dat (DCC)1: Rozdělení + Výmaz dat (DCC)

RozděleníRozdělení

Výmaz dat (DCC)Výmaz dat (DCC)

Split

Duál.ocen.

Výmaz dat

TCC

LCC

Výmaz dat

TCC

LCC

4: System Architecture4: System Architecture



Na Obr. 5-6 a Obr. 5-7 jsou znázorněny grafy s přehledem využití zdrojů v jednotlivých

měsících podle projektů.

Obr. 5-6 Celkový přehled využití zdrojů projektu

Jednotlivé podprojekty mají naplánované následné zdroje:

� Podprojekt rozdělení systému a výmaz dat – 1900 MD (člověkodní),

� Konverze transakční měny (TCC) – 2500 MD,

� Konverze lokální měny (LCC) – 450 MD,

� Mezinárodní šablona (Temmplate) – 60 MD,

� Systémová architektura – 350 MD,

� Testování – 120 MD,

� Archivace – 190 MD.

Obr. 5-7 3D přehled využití zdrojů projektu

0

100

200

300

400

500

600

700

Jan-

08

Feb-0

8

Mar

-08

Apr-0

8

May

-08

Jun-

08

Jul-0

8

Aug-0

8

Sep-0

8

Oct-0

8

Nov-0

8

Dec-0

8

Jan-

09

Feb-0

9

Mar

-09

Apr-0

9

May

-09

Člo

věko

dn

y

SP-7 (Archiving)

SP-6 (Testing)

SP-3 (LCC)

Series4

Series3

SP-2 (TCC)

SP-1 (System Split)Kick off

Platnost

nové měny

Duální ocenění

Jan-0

8

Feb-0

8

Mar

-08

Apr-0

8

May

-08

Jun-0

8

Jul-0

8

Aug-08

Sep-0

8

Oct

-08

Nov-08

Dec-0

8

Jan-0

9

Feb-0

9

Mar-

09

Apr-0

9

May

-09

SP-4 (Int. Template)

SP-6 (Testing)

SP-3 (LCC)

SP-7 (Archiving)

SP-5 (System Architecture)

SP-1 (System Spl it)

SP-2 (TCC)

0

50

100

150

200

250

300

350

Člo

věko

dn

y



Následující koláčový graf (Obr. 5-8) přehledně ukazuje, jak jsou jednotlivé podprojekty

časově náročné.

Obr. 5-8 Podíl člověhkohodin na jednotlivých podprojektech

5.7.3 Rozpočet projektu

Jako závěrečnou část k přípravě projektu udávím rozložení podílu finančních nákladů

podle druhu zdrojů. Interní zdroje tvoří zhruba 50% celkového rozpočtu projektu. Organizace

hojně využívá externích zdrojů, mezi nimi jsou hlavně externí konzultanti a SAP konzultanti.

Výhodou využití externích zdrojů je hlubší znalosti problematiky a větší zkušenosti z široké

škály projektů. Jelikož se jedná o projekt, který musí být dokončen včas, riziko kritických

chyb může nést větší náklady organizací, než náklady na využití externích zdrojů. Tabulka

5-2 a graf na Obr. 5-9 zobrazují podíly jednotlivých druhů zdrojů na rozpočtu projektu.

Obr. 5-9 Graf podílů jednotlivých druhů zdrojů nerozpočtu projektu

Podíl člověhohodin na jednotlivých podprojektech

SP-1 (System Split)

34%

SP-2 (TCC)

46%

SP-4 (Int. Template)

1%

SP-5 (System Architecture)

6%

SP-6 (Testing)

2%

SP-7 (Archiving)

3%

SP-3 (LCC)

8%

Hardware10%

Ostatní3%

Interní zdroje49%

Externí zdroje30%

Rezerva8%



Tabulka 5-2 Podíl jednotlivých druhů zdrojů na rozpočtu projektu

Položky rozpočtu MD Podíl nákladů

Interní zdroje 50%

IS* ~ 3000 38%

Business** ~ 2500 12%

Externí zdroje 30%

Ext. Konzultanti ~ 600 15,5%

SAP 12%

Ext. Integrace systému 2,5%

Hardware 10%

Ostatní náklady 2,5%

Rezerva 7,5%

Celkem ~ 6100 100% * IS – Interní konzultanti a vývojáři

** Business – uživatele, superusers a management.

5.8 Realizace projektu

5.8.1 I: Rozdělení systému a výmaz dat

Obr. 5-10 Využití zdrojů v podprojektu „Rozdělení systému a výmaz dat“

Rozdělení systému

První etapou je rozdělení systému na dva – Český a Slovenský a výmaz redundantních

dat ze systémů (výmaz českých dat ze slovenského systému a naopak, výmaz slovenských

dat z českého systému).

Pro rozdělení systémů byly 2 hlavní důvody. Prvním z důvodů je, že velikost databáze

je poměrně velká (cca 10TB), a je riziko, že konverze systému (selekce dat a přepočítávání

částek z SKK na EUR) bude trvat déle, než to umožňuje provoz. Jak již bylo řečeno, procesy

0

50

100

150

200

250

300

Jan-

08

Feb-0

8

Mar

-08

Apr-0

8

May

-08

Jun-

08

Jul-0

8

Aug-0

8

Sep-0

8

Oct-0

8

Nov-0

8

Dec-0

8

Jan-

09

Feb-0

9

Mar

-09

Apr-0

9

May-

09

Člo

věko

dn

y



běží ve dne a v noci, a případné zpoždění procesu muže ohrozit plynulost provozu na

pobočkách (objednávání a dovoz zboží).

Druhým důvodem je celková strategie IS firmy – každá země má mít svůj vlastní

systém. Tímto projektem by se dovršila daná strategie.

Rozdělení systému přináší změny v nastavení připojení k externím systémům (pokladní

systémy, logistické systémy, business intelligence atd.), autorizací, údržby kmenových

záznamů a technické změny v procesech.

Systém se rozděluje takovým způsobem, že se vytvoří další kopie z původního

systému, původní systém se prohlásí za Český a nově vytvořený systém bude definován jako

Slovenský systém. Pak, po odpojení slovenských externích systémů, zablokování

slovenských uživatelů, odstranění slovenských autorizací atd., český systém může být dán do

provozního stavu.

K novému, slovenskému systému se musí nastavit připojení z externích systémů,

provést zablokování českých uživatelů, odstranit autorizací zastavení českých procesů atd.

Dále nový systém musí být přejmenován, to znamená, že veškera informace v databázi, která

se odkazuje na původní systém, musí být nahrazená názvem nového systému.

Harmonogram projektu Rozdělení systému je zobrazen na Obr. 5-11.

Obr. 5-11 Jednotlivé etapy rozdělení systémů

Výmaz dat

Po úspěšném rozdělení systémů další etapou v rámci podprojektu je výmaz

redundantních dat - výmaz slovenských dat z českého systému a českých dat ze slovenského

systému. Jedna se o poměrně náročnou operaci, která zasahuje přímo do databáze systému a

během výmazu dat musí být naplánována odstávka. Výmaz dat na jednom systému trvá

zhruba 24 hodiny. Organizace si nemůže dovolit tak dlouhou odstávku, proto výmaz dat je

rozdělen na dvě části – během víkendu je dáno 12 hodin na výmaz dat plus čas na test

kritických funkcionalit, přípravu systému pro odstávku včetně přípravy nouzových stavu

15 16 17 18 19 20 21 22 23 24 25 26 27

Rozdělení systémuSpecial Analysis P18Introduction for SUTesting SU/FBGo Live P18

2008

PhaseApr May Jun



v případě nepovedeného výmazu dat a čas pro znovunastartování systému a aktivaci

funkcionalit. Na Obr. 5-12 je zobrazen harmonogram výmazu dat z obou systémů.

Obr. 5-12 Harmonogram výmazu dat

Jako první testovací prostředí bylo rozhodnuto použití takzvaných Sandbox systémů

(pytel s pískem) – jedna se o kopii produktivních systémů, ale v případě nepovedených

operací by se tyto systémy daly rychle obnovit, protože se nemusí provádět časově náročné

aktivity spojené s nastavováním rozhraní, uživatelských profilů atd., které se obvyklé

provádějí na testovacích systémech. Během iniciačních testů se zjišťovala časová náročnost

výmazu dat, celková proveditelnost a tzv. IT testy, tj. testy, kterých se účastní pouze SAP

konzultanti a IT personál – bez zapojení zdrojů z organizačních jednotek. Je to dáno z jak

z časového důvodu, tak i z toho, že se testují pouze základní funkcionality systému a obsah

tabulek.

Proces výmazu dat je sám o sobě velice zajímavý. SAP nabízí službu SLO (System

Landscape Optimization), v rámci které nabízí i podporu s výmazem dat. Pro výmaz dat je

vyvinut speciální nástroj, který funguje ve tříkrokové posloupnosti:

� nejdříve se provede selekce organizačních struktur, určených k odstranění ze systému,

� v následujícím kroku nástroj provede výběr kmenových dat, přiřazených

k selektovaným organizačním strukturám. V tomto kroku konzultant musí odsouhlasit,

zda je výběr správný a případně provést změny ve výběru,

� posledním krokem je spuštění úloh pro selekci transakčních dat pro odstranění ze

systému. Selekce dat běží zhruba 24 hodiny. Po selekci dat je vytvořena fronta úloh,

kde každá úloha je přiřazená ke konkrétní tabulce.

Po provedení výmazu dat je nutné provést test kritických funkcionalit a účetní audit

jednotlivých výkazů externí auditorskou společností. Pro podprojekt Rozdělení systému a

výmaz dat bylo naplánováno 1900 člověkodní (cca 33,7% času z celkového projektu).

2009

Dec

DDC Data deletionSK Sandbox - IT výmaz, testySK Test syst - Výmaz datSK Test syst.- Business Testy, AuditSK Prod.syst.- Výmaz dat, test krit.funcionalit, auditCZ Sandbox - IT výmaz, testyCZ Test syst. - Výmaz datCZ Test syst. - Business Testy, AuditCZ Sandbox - IT výmaz, testy (v případě nutnosti)CZ Prod.syst - Výmaz dat, test krit.funkcionalit, audit

Nov DecSept OctPhase

2008

Jun Jul Aug



5.8.2 II: Konverze transakční měny

V rozsahu podprojektu Konverze transakční měny jsou následující milníky:

� 8.8.2008 - Duální zobrazení měny.

� 1.1.2009 – Konverze transakční měny (přechod na euro).

Duální zobrazení měny

Obr. 5-13 Harmonogram k podprojektu Duální zobrazení měny

Povinné duální zobrazení cen je relevantní pro zboží a služby, které jsou oceněny

v domácí měně a prodávané fyzickým osobám podle zákona č. 659/2007. Povinnost

zobrazovat duální ceny nastává 8.8.2008, měsíc po vyhlášení konverzního kurzu, který byl

stanoven na 30,126 SKK/EUR. Duálním zobrazením cen jsou ovlivněny výstupní dokumenty

z hlavní části cenovky, pak upomínky, smlouvy, faktury, výplatní pásky, bankovní výpisy

atd.. V zájmu konečného spotřebitele ceny se nesmějí zaokrouhlovat nahoru. Na správnost

zobrazení a zaokrouhlování cen dohlíží státní orgány. Při porušení pravidel se mohou

uvalovat vysoké sankce.

0

50

100

150

200

250

300

350

Jan-

08

Feb-0

8

Mar

-08

Apr-0

8

May

-08

Jun-

08

Jul-0

8

Aug-0

8

Sep-0

8

Oct-0

8

Nov-0

8

Dec-0

8

Jan-

09

Feb-0

9

Mar

-09

Apr-0

9

May-

09

Člo

věko

dn

y

12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

TCC a IT realizaceDuální ocenění (01.07.08)

Business KonceptyRealizaceTestováníGo-Live

Simulace Euro cen (01.07.08)Business KonceptyRealizaceTestováníGo-Live ◊

2008

PhaseMar Apr May Jun Jul Aug



Konverze transakční měny

V rámci přípravy ke konverzi transakční měny se pro všechny procesy nastaví výchozí

transakční měna EUR. Tato fáze je z podstatné části důležitá pro logistické procesy

(objednávání, cenovky, akceptace euro měny v pokladnách). Ve finančním modulu se

provede nastavení pro automatickou konverzi výkazové měny – reporty, jako bilance

odběratelů a dodavatelů, účtů hlavní knihy atd., budou automaticky on-line přepočítávány a

zobrazovány ve měně EUR.

Obr. 5-14 Harmonogram konverze transakční měny

Podprojekt Konverze transakční měny je nejrozsáhlejší v rámci projektu – 2600

člověkodní (cca 45,7% celkového času).

5.8.3 III: Konverze lokální měny

Konverze lokální měny bude spuštěna po účetní uzávěrce a účetním auditu. Musí být

vygenerováno co nejvíce výkazů a reportů, protože se provede nenávratná operace

přepočítávání částek v lokální měně SKK na EUR, a od tohoto momentu se lokální firemní

měnou stane EUR. Plánované zahájení je ve druhé polovině měsíce března.

19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 1 2 3 4 5

TCC a IT realizaceTCC (01.01.09)

Business KonceptyRealizace - ITRealizace - OrganizačníIT testyTCC Migrace do test syst.Business TestyIT Testy (výkon)Go-Live

2008 2009

DecNov JanSept OctPhase

May Jun Jul Aug

0

10

20

30

40

50

60

Jan-0

8

Feb-0

8

Mar

-08

Apr-0

8

May

-08

Jun-0

8

Jul-0

8

Aug-0

8

Sep-0

8

Oct

-08

Nov-0

8

Dec-0

8

Jan-0

9

Feb-0

9

Mar

-09

Apr-0

9

May

-09

Člo

věko

dn

y



Fáze Lokální konverze měny patří podle mne mezi nejzajímavější a nejsložitější část,

ve které se konvertují veškeré částky v lokální měně SKK na částky ve měně EUR. Tato

operace se prování standardním nástrojem SAP, který obsahuje programy pro konverzi měny,

programy pro vyrovnávání a zaúčtování zaokrouhlovacích rozdílů a programy pro konverzí

uživatelských tabulek (tzv. z-tables), a uživatelského vývoje, které nejsou součástí

standardního balíku SAP.

Obr. 5-15 Harmonogram podprojektu konverze lokální měny

Proces přípravy ke konverzi a samotné konverze vypadá následovně. Před vlastní

konverzí systém provádí analýzu – analýza kontroluje v testovacím systému (a následně i ve

vývojovém a produktivním systému), zda je systém připraven pro konverzi a především se

kontroluje konzistence dat v systému. Chyby, které jsou ve fázi analýzy odhaleny, je třeba

opravit a analýzu provést znovu. Opravy, které byly úspěšné, je třeba neprodleně aplikovat i

v produktivním systému. Jen tak je možné zajistit hladký průběh budoucí produktivní

konverze. Na Obr. 5-16 je zobrazená procesní mapa přípravy ke konverzi lokální měny.

LCC

Realizace + Test

Sandbox - Testy

1. test LCC

Business testy

Účetní audit

2. test LCC

Účetní audit

Business testy

Účetní audit ◊

Go-Live

Účetní audit

Mar Apr May Jun Jul AugPhase Nov Jan FebDec MarSept Oct2008 2009



Obr. 5-16 Příprava konverze lokální měny, Zdroj SAP AG

V rámci příprav v modulu Finance, je nutné především provést tyto kroky [převzato

z KR1]:

� Vyrovnat co nejvíce otevřených položek, zejména pak položky s měnou dokladu EUR.

U otevřených položek v měně EUR systém nekonvertuje částku ve firemní měně do

EUR, ale převezme částku v měně dokladu. Toto samozřejmě může způsobit významné

zaokrouhlovací rozdíly.

� Je nutné provést, dokumentovat a auditovat účetní závěrku roku 2008. Po provedení

konverze již nebude možné získat konzistentní data za minulé roky.

� Všechny platební a upomínkové běhy musí být dokončené nebo vymazané.

� Uchované (archivované) doklady nejsou konvertovány

Proces konverze by měl trvat zhruba 24 hodin. Pro provedení konverze se projeví

následující změny:

� Částky v lokální měně ve všech dokladech

� Kmenové data účtů hlavní knihu

� Skladové ceny a měna v materiálových kmenových záznamech

Testovacísystém(kopie produkt. dat)

Produktivnísystém

PřípravaPříprava

AnalýzaAnalýza

OpravaOprava

Implementaceoprav

Implementaceoprav AnalýzaAnalýza

KonverzeKonverze

Konverze

Vyrovnání účtů ve staré lok. měně

Vyrovnání účtů ve staré lok. měně

Konverze tabulekKonverze tabulek

Vyrovnání účtů v nové lokální měněVyrovnání účtů v

nové lokální měně

Optimalizace času odstavky

Optimalizace času odstavky

Testovací cyklusTestovací cyklus

3 – 6 měsíců 1 – n dnů



� Historie nákupních objednávek

� Customizační tabulky s částkami v lokální měně (např. tolerance)

� Z-tabulky (uživatelské tabulky a vývoj)

� Všechny částky v lokální měně SKK (struktury, controllingová data, logistické faktury

atd.

Důležitou poznámkou je působení konverze na jednotlivé typy dokladů: konverze

dokladu ve měně SKK, dokladu v cizí měně a dokladu ve měně EUR.

a. V každém dokladu jsou evidovány dvě částky – částka v měně dokladu a částka ve

firemní měně. V případě dokladu ve firemní měně je kurz pro přepočet 1:1 a

částka v měně dokladu je tedy stejná jako částka ve firemní měně. Systém ukazuje

pouze částku v měně dokladu. Doklady v měně SKK zůstanou v SKK i po

konverzi. Změní se pouze firemní měna a částka ve firemní měně se zkonvertuje z

SKK na EUR. Po konverzi je doklad v SKK, který byl původně zaúčtován jako

doklad v domácí měně, chápán jako doklad v cizí měně.

b. V dokladu, který byl zaúčtován v cizí měně, se pouze změní částka ve firemní

měně. Je třeba si uvědomit, že po konverzi původní doklady v SKK vypadají v

podstatě stejně jako ostatní doklady v cizí měně.

c. Doklady, které byly při konverzí zaúčtovány v EUR, mohou být konvertovány

dvěma způsoby. Vyrovnané položky nebo položky, které nemají povahu závazků

nebo pohledávek, jsou konvertovány stejně jako ostatní doklady v cizí měně.

Částka ve firemní měně se může lišit od částky v měně dokladu, přestože obě

částky jsou v EUR!

Zajímavá je logika konverze otevřených položek. Otevřené položky jsou konvertovány

způsobem nazvaným jako „move logic“, tj. částka v měně dokladu je převzata jako částka ve

firemní měně. To ovšem způsobí významný zůstatek dokladu, který je nutné dorovnat

vytvořením nové položky na účet zaokrouhlovacích rozdílů. Pokud by systém nepoužil

„move logic“ došlo by např. při platbě takové položky k účtování kurzových rozdílů i když je

doklad ve firemní měně. Viz tento příklad:



Dejme tomu, že konverzní kurz je 33,000 SKK/EUR.

1. Závazek účtovaný před konverzí v EUR:

2. Doklad po konverzi:

3. Platba:

Při vyrovnání závazku a platby musí dojít k účtování kurzového rozdílu 10 EUR:

Pro všechny roky předcházející aktuálnímu roku systém konvertuje samostatně

položky a obraty na účtech. Po konverzi nebude zůstatek účtu souhlasit se součtem položek –

tento rozdíl není analyzován a dorovnán. Systém konvertuje nezávisle položky v modulech

Finance a Controlling – tím dojde k rozdílům, které mohou vést k zůstatkům na

Controllingových objektech, které byly před konverzí nulové. Dorovnání zůstatků systém

provádí pouze v aktuálním roce:

� Zůstatek každého jednotlivého dokladu musí být nula.

� Doklady o vyrovnání musí mít nulový zůstatek.

� Součet všech hodnot převedených z minulého roku musí být 0, tj. jsou vyrovnané

strany má dáti a dal.

� Zůstatek účtu souhlasí se součtem položek.

� Zakázky, které byly 100% zúčtovány, mají po konverzi zůstatek 0.

Zaokrouhlovací rozdíly nebo rozdíly z použití „move logic“ jsou účtovány na jeden z

pěti účtů hlavní knihy. Celkem je v systému 8 různých typů zaokrouhlovacích rozdílů,

prakticky se ale použije jen 5.

100 EUR (3300 SKK)

Dodavatel

100 EUR (110 EUR)

Dodavatel

100 EUR (100 EUR) 100 EUR (110 EUR)

0 EUR (10 EUR)

Dodavatel



Kategorie Popis

001 Zaokrouhlování na úrovni dokladu

002 Zaokrouhlování na úrovní párování dokladů

003 Zaokrouhlovací rozdílu počátečních stavů

004 Zaokrouhlovací rozdíly mezi moduly Finance (FI) a Material management (MM) (po položkách)

005 Zaokrouhlovací rozdíly v historii nákupních objednávek

� Typ 001 zahrnuje dva typy rozdílů:

� Po konverzi položek v dokladu má doklad malý zůstatek, tento zůstatek je dorovnán

vytvořením nové položky v dokladu.

� Při použití „move logic“ vznikne v dokladu zůstatek, který může být poměrně

významný. Tento zůstatek je dorovnán vytvořením nové položky.

� Typ 002:

� Pokud po konverzi součet vzájemně vyrovnaných dokladů není 0, musí systém do

dokladu o vyrovnání doplnit položku, která dorovná zůstatek na 0.

� Typ 003:

� Pro aktuální fiskální rok systém nezávisle konvertuje zůstatky, které byly do tohoto

roku přeneseny z minulého roku. Součet takto zkonvertovaných hodnot není 0 a

musí být tedy dorovnán doplněním hodnoty na tento účet.

V rámci konverze jsou konvertovány i částky, které jsou součástí customizingu. Po

konverzi je nutné customizing projít a zkonvertované hodnoty zkontrolovat a případně

změnit. Konverzí totiž mohou vzniknout hodnoty, které budou pro uživatele nesrozumitelné a

v některých případech mohou být i nesprávné, např.:

� Částky za upomínky a limity v upomínkovém řízení

� Částky ve způsobech platby

� Toleranční skupiny

� Limit pro drobný majetek hmotný nebo nehmotný – tato částka bude stanované

zákonem a je třeba tuto částku přesně dodržet.

Na podprojekt Konverze lokální měny je naplánováno 452 člověkodní (cca 7,94%

celkového času).



5.8.4 Mezinárodní šablona (International Template)

Obr. 5-17 Kumulovaný harmonogram podprojektů: Mez. šablona, Systémová architektura, testování a archivace.

Podprojekt „Mezinárodní šablona“ bude zahájen jako poslední, kdy již bude dokončena

konverze transakční měny, a začnou se přípravy k produktivnímu startu konverze lokální

měny. V rámci aktivit bude aktualizace konceptů, dokumentace „know-how“, analýza chyb.

To vše by mělo ušetřit čas a náklady během příštích projektů konverze měny v ostatních

zemích. Na podprojekt je naplánováno 60 člověkodní (cca 1% celkového času).

5.8.5 Systémová architektura

Pro úspěšný a včasný průběh projektu je nutné mít připravené prostředí a znát limity

jak hardwarové, tak i časové – za jak dlouho systém může být obnoven, zálohován, odstaven

atp. Za tyto aktivity odpovídá tým podprojektu Systémová architektura.

Projekt Konverze měny je poměrně náročný na infrastrukturu: musí se připravit nové

hardware pro rozdělený slovenský systém, pro každou testovací etapu se musí nastavit

systém z kopií produktivního systému. Nakonec, při produktivním startu, hodně závisí na

tom, jestli tým připravil systém tak, aby nedošlo k zdržení následných aktivit. Jak již bylo

řečeno, na odstavku produktivního systému firma si muže dovolit pouze 24 hodiny o

víkendu. Pro podprojekt Systémová architektura je naplánováno 330 člověkodní (cca 5,85%

celkového času).

5.8.6 Testování

Testovací podprojekt ověří funkcionalitu všech existujících programů a procesů ve

všech fázích projektu. Cílem testování v podprojektu „Rozdělení a výmaz“ je kontrola

správnosti integrace SAP a ne-SAP systémů a kontrola správnosti reportingu. V podprojektu

„Konverze transakční měny“ cílem testování je ověření splnění podmínek legislativních

0

20

40

60

80

100

120

140

160

Jan-0

8

Feb-0

8

Mar-0

8

Apr-0

8

May

-08

Jun-0

8

Jul-0

8

Aug-0

8

Sep-0

8

Oct-0

8

Nov-0

8

Dec-0

8

Jan-

09

Feb-0

9

Mar

-09

Apr-0

9

May

-09

Člo

věko

dn

y

SP-4 (Int. Template) SP-5 (System Architecture) SP-6 (Testing) SP-7 (Archiving)



požadavků. V průběhu „Konverze lokální měny“ je cílem otestovat správnost reportingu

finančním a státním institucím, že se používá měna EUR. Nakonec posledním cílem je

objevit a napravit potenciální chyby v již zaběhnutých procesech, nespojených s konverzí

měny, a které se mohou náhodně objevit v průběhu testovacích etap. Na Obr. 5-18 je

zobrazen harmonogram testovacích fází.

Obr. 5-18 Harmonogram testovací etapy

V průběhu testovacích fází se simuluje produktivní start, analyzuje se čas, potřebný pro

jednotlivé aktivity a připravuje se tzv. „Cut-over“ plán, tj. plán aktivit, kde se uvádí

posloupnost jednotlivých aktivit, čas, kdy má začít, čas trvání aktivity a odpovědné osoby.

Pro testování je naplánováno 120 člověkodní (cca 2,46% celkového času).

Obsah a odpovědnosti v jednotlivých testovacích fázích jsou zobrazeny v následující

tabulce.

Tabulka 5-3 Popis testovacích etap

Etapa Oblast Popis

Test 1 – Rozdělení systému

Rozsah testů � Rozhrání nového systému � Změny procesů � Autorizace � Test kritických funkcionalit (fakturace,

konektivita s pokladnami, banking atp.)

Počet testovacích případů � cca 1000

Testovací tým � SUN

Ukončovací podmínky � Všechny kritické funkcionality musí byt dokončeny bez chyb.

� Veškerá rozhrání musí fungovat v obou směrech.

� Všechny testovací případy byly alespoň jednou spuštěny a s prioritou 1 a 2 musí být vyřešeny.

1-1 Rozdělení systémů

1-2 Výmaz dat

2-1 Duální ocenění

2-2 TCC

3 LCC

Jan Feb Mar

2009

Aug

2008

Sep Oct Nov DecFáze projektu

May Jun Jul



Etapa Oblast Popis

Test 2 – TCC Duální ocenění

Rozsah testů � Veškerý technický vývoj spojený s interakcí se zákazníkem

� Funkčnost hardware a software spojený s tiskem duálních cen

� Zajištění korektní funkčností výplatních pásek


Testovací tým � SUN, Nákup, Prodej, Reklama, HR

Ukončovací podmínky � Duální ceny se zobrazují ve všech relevantních výstupech podle legislativních požadavků.

� Všechny testovací případy byly alespoň jednou spuštěny a s prioritou 1 a 2 musí být vyřešeny.

Test 0 – TCC Simulační nástroj Euro cen

Rozsah testů � Testování Euro simulačního nástroje

Testovací tým � SUI nákup

Test 3 – TCC Konverze transakční měny

Rozsah testů � Veškerý technický vývoj spojený s konverzí transakční měny

� Kontrola změn kmenových dat � Simulace procesů „zbožových toků“ � Chování objektů v různých etapách konverze � Testování scenária produktivního startu (Go-

Live) – příprava „Cut over“ plánu.


Testovací tým � všichni SUN � provozní oddělení

Kritérium úspěšnosti � Potvrzení všech oddělení o správnosti funkcionality

Ukončovací podmínky � Všechny testovací případy byly alespoň jednou spuštěny a s prioritou 1 a 2 musí být vyřešeny.

Test 4 – LCC (Konverze lokální měny)

Rozsah testů � Kontrola standardních a uživatelských tabulek pro správnost konverze částek a měny

� LCC se provedla na systému po TCC � Test funkcionality procesů


Testovací tým � SUN, FI, CO, Účetní oddělení, HR

Kritérium úspěšnosti � Všechny částky v lokální měně jsou zkonvertovány na euro.

� Simulace roční uzávěrky

Ukončovací podmínky � Všechny relevantní tabulky byly zkonvertovány � Všechny testovací případy byly alespoň jednou

spuštěny a s prioritou 1 a 2 musí být vyřešeny.



Etapa Oblast Popis

Test 5 – TCC Druhý test konverze transakční měny

Rozsah testů � Veškerý technický vývoj spojený s konverzí transakční měny

� Chování objektů v různých etapách konverze � Ověření scenária „Go-live“ – testování „Cut-

over“ plánu


Testovací tým � Všichni SUN � Provozní oddělení

Kritérium úspěšnosti � Potvrzení všech oddělení o správnosti funkcionality

� Splnění scenária „Go-Live“

Ukončovací podmínky � Všechny testovací případy byly alespoň jednou spuštěny a s prioritou 1 a 2 musí být vyřešeny.

Test 6 – LCC Druhý test konverze lokální měny

Rozsah testů � Kontrola standardních a uživatelských tabulek pro správnost konverze částek a měny

� LCC se provedla na systému po TCC � Test funkcionality procesů


Testovací tým � SUN, FI, CO, Účetní oddělení, HR

Kritérium úspěšnosti � Všechny částky v lokální měně jsou zkonvertovány na euro.

� Simulace roční uzávěrky

Ukončovací podmínky � Všechny relevantní tabulky byly zkonvertovány � Všechny testovací případy byly alespoň jednou

spuštěny a s prioritou 1 a 2 musí být vyřešeny.

V průběhu přípravy testovacích případů a během testovacích běhů se uživatelé budou

zaškolovat do nových procesů, tzv. metoda „training on the job“, tj. zaškolování během

práce.

Veškeré testovací případy jsou nahrány do DMS (Document management system) a

v tomto systému se sleduje celkový průběh a progres testování, stav testovacích případů a

případné popisy návrhů konzultantů pro řešení chybných testovacích případů. Testovací

případy jsou převážně vytvářeny na základě business konceptů, další testovací případy

navrhují jednotlivá provozní oddělení.



5.8.7 Archivace

V rámci projektu Konverze měny se vyskytla příležitost implementovat archivační

procesy a provést „čistku“ systému od relativně starých dat. Objem dat ovlivňuje výkon

systému, čas, nutný pro vytváření záloh, odstavek, a negativně se odráží na nákladech na

diskové kapacity. Na Obr. 5-17 (viz str 72) je zobrazen harmonogram archivace, který je

naplánován od března do září roku 2008.

Cílem a rozsahem tohoto projektu je tedy:

� zmapovat aktuální situaci s archivací dat,

� provést analýzu možností snížení objemu dat v databázi,

� provést dokumentaci nastavení archivace,

� zahájit archivační procesy,

� vytvořit šablonu pro ostatní země, kde působí společnost,

� zajistit rychlý přístup k archivovaným datům.

Pro podprojekt Archivace je naplánováno 190 člověkodní (cca 3,27 procenta celkového

času).

5.9 Kontrolní mechanizmy a risk management

5.9.1 Kontrolní schůzky (Status meeting)

Každé 2 týdny se svolávají status meetingy, kterých se účastní vedoucí jednotlivých

podprojektů a projednávají události od poslední schůzky, další kroky, potenciální rizika atp.

V případě problematických situací nebo odchylek od plánu se na těchto schůzkách řeší

nápravná opatření, případně přerozdělení zdrojů. Na Obr. 5-19 je vzor prezentace ze status

meetingu.

12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

ArchivaceTechnický koncept + fuknční testRealizaceTestováníGo-Live

2008

PhaseMar Apr May Jun



Obr. 5-19 Vzor prezentace ze status meetingu

5.9.2 Nouzový plán (Emergency scenario)

V průběhu produktivních startů (Go-Live) se může vyskytnout situace, že nějaká

aktivita z jakýchkoliv důvodů nebude moci dokončit včas, proto je třeba definovat tak zvané

„Knock out“, aktivity, u kterých je důležité, aby byly dokončeny podle plánu. To znamená, že

v případě nemožnosti dokončená určité klíčové aktivity včas, bude zahájen alternativní,

nouzový plán.

Jeden příklad nouzového plánu muže být varianta, že se systém vrátí do původního

stavu před provedením odstávky. Během projektu jednou nastala nouzová situace při druhé

etapě výmazu českých dat ze Slovenského systému. Během výmazu dat se narušila

konzistence dat, a při testování kritických funkcionalit po oživení systému se zjistilo, že

systém nefunguje korektně. Proto se rozhodlo, že systém bude obnoven z odpojeného

diskového pole a dojde k návratu stavu před odstávkou. Druhá etapa výmazu dat byla

odložena do zajištění a odstranění zdroje nekonzistence dat.



6 ZÁVĚR

Tato diplomová práce se zabývala problematikou přechodu na měnu euro a dopad na

informační systém ERP SAP ve velké mezinárodní společnosti.

Toto téma jsem si vybral za prvé z důvodu aktuálnosti – projekt je v době psaní této

diplomové práce v produktivní fázi. Za druhé, zkušenosti, získané z tohoto projektu a

uvedené v této práci se budou ještě několikrát opakovat v jiných zemích.

K 1. 1. 2009 Slovenská republika přešla na měnu Euro. S přechodem na jinou měnu

jsou spojené různé aktivity - legislativní, změny v informačních systémech, bankomatech až

po vozíky v supermarketech, vše se musí adaptovat na nové podmínky. Projekt, ve

společnosti Kaufland byl zahájen v březnu roku 2008, a ukončení je plánováno v květnu roku

2009. Z toho vyplývá, že i po přechodu na Euro jsou spojené aktivity, které trvají dalších pět

měsíců. Celková časová náročnost projektu byla víc než 6000 man-days (tzv. člověkodní).

V teoretické části jsem se snažil podrobně popsat obecné scénáře zavedení eura. Ke dni

zpracování této diplomové práci existuje tři základní scénáře – Madridský scénář, Big-Bang

a scénář Phasing-Out. Dále jsou rozebrány rozdíly mezi scénáři. Další kapitola je věnována

průběhu zavedení eura v Slovenské republice od vstupu do systému ERMII, až do konce

roku 2009, kdy dojde ke zrušení povinného duálního zobracení cen. Slovenská republika

zvolila nejrychlejší scénář zavedení eura, tzv. Big-Bang. Třetí kapitola se věnuje metodikám

řízení projektu, základním pojmům, subjektům a zájmovým skupinám projektů,

organizačním strukturám a fázím projektů. V této části je definována významnost role

projektového manažera na úspěchu projektu, důležitost pochopení organizace jako celku -

organizační kultury, politiky a personál. Tyto faktory mohou ovlivnit průběh projektu zvlášť

v kritických okamžicích. Na konci teoretické části, čtvrtá kapitola popisuje funkcionalitu

ERP, hlavní funkční moduly a základní informace o ERP SAP a společnosti SAP AG.

Druhá, praktická část je věnována samotnému projektu konverze SKK na EUR v ERP

SAP. V této části jsem se snažil ukázat, co obnáší projekt, jaké procesy ovlivňuje, jaké jsou

etapy a milníky jednotlivých podprojektů a jaká je časová náročnost pro dosažení cíle.

Úvodní kapitola uvádí informace o společnosti, organizační strukturu a architekturu IS. Další

kapitoly se věnují rozboru jednotlivých podprojektů v rámci hlavního projektu konverze,

jejích popis, harmonogram, využití zdrojů a vzájemná závislost.

Doufám, že tato diplomová práce bude pro čtenáře přínosem a zejména dalším

orientačním bodem pro členy projekčních týmů při budoucích konverzích měny v různých

zemích.



7 PŘÍLOHA

7.1 Seznam zkratek

Zkratka Anglický text Český text

BI Business intelligence Business inteligence

CO Controlling controlling

CRM Customer relationship management Řízení vztahů se zákazníky

ERP Enterprise resource planning Enterprise resource planning

FI Finance Finance

HR Human resources Personalistika

LCC Local currency conversion Konverze lokální (firemni) měny

MD Man-days Člověkodny

MM Material management Material management

SCM Supplier chain management Řízení dodavatelských řetězců

SUN Superuser National Super uživatel lokální, národní

SUI Superuser International Super uživatel mezinárodní

TCC Transactional currency conversion Konverze transakční měny

7.2 Seznam obrázků a tabulek

7.2.1 Obrázky

Obr. 2-1 "Madridcký" scénář zavedení eura, zdroj [EU1] ....................................................................... 5

Obr. 2-2 Scénář "Big Bang", zdroj [EU1] ................................................................................................ 6

Obr. 2-3 Scénář „Phasing out“, zdroj [EU1[ ............................................................................................ 7

Obr. 2-4 Proces zavedení eura na Slovensku, zdroj [NB1] .................................................................. 11

Obr. 3-1 Základní rámec řízení projektů, zdroj [SC1], str. 42. .............................................................. 14

Obr. 3-2 Projektový trojúhelník, zdroj [WI1] .......................................................................................... 16

Obr. 3-3 Diagram projektových procesů, zdroj [FI1] ............................................................................. 17

Obr. 3-4 Vztah mezi zájmovými subjekty a projektem, zdroj [PM1] ..................................................... 19

Obr. 3-5 Funkční organizační struktura, zdroj [FI1], str. 22. ................................................................. 25

Obr. 3-6 Projektová organizační struktura, zdroj [FI1], str. 23. ............................................................. 26

Obr. 3-7 Maticová organizační struktura, zdroj [FI1], str. 24. ............................................................... 27

Obr. 3-8 Typické rozložení fází životního cyklu projektu, zdroj [SV1] .................................................. 29

Obr. 3-9 Typický průběh nasazení lidských zdrojů životního cyklu projektu, zdroj [SV1] .................... 30

Obr. 3-10 Vliv zájmových skupin v průběhu životního cyklu projektu, zdroj [SV1] ............................... 31

Obr. 4-1 Obecné schéma architektury ERP, zdroj [GA1], str. 66.......................................................... 41



Obr. 4-2 Zpracování obchodního případu v ERP, zdroj [BA1], str. 68. ................................................. 43

Obr. 4-3 SAP R/3 Systém, zdroj [BA2] ................................................................................................. 48

Obr. 4-4 Vývojové procesy a prostředí ERP SAP ................................................................................ 49

Obr. 5-1 Organizační struktura společnosti Kaufland ........................................................................... 52

Obr. 5-2 Procesní mapa společnosti Kaufland ..................................................................................... 54

Obr. 5-3 Dopad legislativních požadavků na harmonogram projektu, Převzato z SAP AG a upraveno

dle plánu projektu ................................................................................................................................. 55

Obr. 5-4 Organizační struktura projektu, zdroj [KA0] ........................................................................... 57

Obr. 5-5 Harmonogram projektu ........................................................................................................... 59

Obr. 5-6 Celkový přehled využití zdrojů projektu .................................................................................. 60

Obr. 5-7 3D přehled využití zdrojů projektu .......................................................................................... 60

Obr. 5-8 Podíl člověhkohodin na jednotlivých podprojektech............................................................... 61

Obr. 5-9 Graf podílů jednotlivých druhů zdrojů nerozpočtu projektu .................................................... 61

Obr. 5-10 Využití zdrojů v podprojektu „Rozdělení systému a výmaz dat“........................................... 62

Obr. 5-11 Jednotlivé etapy rozdělení systémů ..................................................................................... 63

Obr. 5-12 Harmonogram výmazu dat ................................................................................................... 64

Obr. 5-13 Harmonogram k podprojektu Duální zobrazení měny.......................................................... 65

Obr. 5-14 Harmonogram konverze transakční měny ........................................................................... 66

Obr. 5-15 Harmonogram podprojektu konverze lokální měny.............................................................. 67

Obr. 5-16 Příprava konverze lokální měny, Zdroj SAP AG ................................................................... 68

Obr. 5-17 Kumulovaný harmonogram podprojektů: Mez. šablona, Systémová architektura, testování a

archivace. ............................................................................................................................................. 72

Obr. 5-18 Harmonogram testovací etapy ............................................................................................. 73

Obr. 5-19 Vzor prezentace ze status meetingu .................................................................................... 77

7.2.2 Tabulky

Tabulka 2-1 Operace / užití právního nástroje po vstupu země do eurozóny, zdroj [EU1] .................... 7

Tabulka 2-2 Splnění mastrichtských kriterií, zdroj [NB1] ...................................................................... 10

Tabulka 2-3 Proces zavedení eura na Slovensku, zdroj [NB1] ............................................................ 11

Tabulka 3-1 Vliv organizační struktury na projekty, zdroj [PM1], str. 28. .............................................. 25

Tabulka 3-2 Procesy plánování projektu a jejích výstupy, zdroj [SC1], str. 119-120. ........................... 33

Tabulka 3-3Výkonné procesy v projektu a jejich výstupy, zdroj [SC1], str. 130. .................................. 34

Tabulka 3-4 Procesy sledování a kontroly projektu a jejich výstupy, zdroj [SC1], str. 133-135. .......... 35

Tabulka 3-5 Výkonné procesy v projektu a jejich výstupy, zdroj [SC1], str. 138. ................................. 39

Tabulka 5-1 Rozpis dopadu legislativních požadavků na systém ........................................................ 56

Tabulka 5-2 Podíl jednotlivých druhů zdrojů na rozpočtu projektu ....................................................... 62

Tabulka 5-3 Popis testovacích etap ...................................................................................................... 73



7.3 Seznam použité literatury a zdrojů

7.3.1 Literatura

[BA1] Basl, J., Blažíček, R.: Podnikové informační systémy: Podnik v informační společnosti.

Grada Publishing, a.s., 2. vydání, Praha 2008, 288 stran, ISBN 978-80-247-2279-5.

[BE1] Bébr, R., Doucek, P.: Informační systémy pro podporu manažerské práce. Professional

Publishing, 1. vydání, 2005, 224 stran, ISBN 80-86419-79-7.

[BR1] Brůžek, A.: Evropská měnová integrace, VŠE Praha 2001, ISBN 80-245-0158-9.

[GA1] Gála, L., Pour, J., Toman, P.: Podniková informatika. Grada Publishing, a.s., 1. vydání,

Praha 2006, 484 stran, ISBN 80-247-1278-4.

[FI1] Fiala, P.: Projektové řízení – modely, metody, analýzy. Professional publishing, 2004, ISBN

80-86419-24-X

[DO1] Doucek, P.: Řízení projektů informačních systémů, Professional Publishing, 2004, ISBN 80-

86419-71-1

[PM1] A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Third Edition,

2004, Project Management Institute, ISBN 1-930699-45-X

[RO1] Rosenau, M. D. Jr.: Řízení projektů, Computer Press, 2000, ISBN 80-7226-218-1

[SC1] Schwalbe, K.: Řízení projektů v IT, Computer press, a.s. 2007, ISBN 978-80-251-1526-8

[SV1] Svozilová A.: Projektový management, Grada publishing, a.s., 2006, ISBN 80-247-1501-5

[SV2] Svatá V.: Skripta „Projektové řízení v podmínkách ERP systémů“, Nakladatelství

Oeconomica, 2004, ISBN 80-245-0803-6

[VE1] Veber. J. a kol.: Management, Management Press, 2004, ISBN 80-7261-029-5

7.3.2 Elektronické zdroje

[HO1] Článek „Projektové řízení implementace ERP systému“, Daniel Holec.

http://www.systemonline.cz/clanky/projektove-rizeni-implementace-erp-systemu.htm

[KA1] Domovská stránka společnosti KAUFLAND – Dnes

http://www.kaufland.cz/Site/Spolecnost/Kaufland_dnes/index.htm

[KA2] Domovská stránka společnosti KAUFLAND – Historie

http://www.kaufland.cz/Site/Spolecnost/Kronika/index.htm

[NB1] Národna Banka Slovenská: stránky věnované přechodu na euro.

http://www.nbs.sk/EURINT/EURO/EUR_SR.HTM

[SL1] SAP System Landscape Optimization

https://service.sap.com/slo

[WI1] Definice projektového trojúhelníku. Wikipedia.

http://en.wikipedia.org/wiki/Project_triangle



7.3.3 Ostatní zdroje

[BA2] Prof. Ing. Josef Basl, CSc., Přednášky z kurzu „Podnikové Informační systémy“,

http://www.kpv.zcu.cz/pis/prenasky.html

[EU1] Studie „Volba scénáře zavedení eura v České republice“, Národní koordinační skupina pro

zavedení eura v ČR, 2006

[KA0] Interní dokumentace firmy Kaufland

[KA3] Článek o hospodářských výsledcích firmy Kaufland v České republice

http://mam.ihned.cz/c4-10000125-31399980-101000_d-hypermarketum-kaufland-vzrostl-

rocni-zisk

[KR1] Kroutil M. Prezentační materiál ke konverzi lokální měny, 2008.

[SE1] Školicí prezentace Projektového managementu, Ing. V. Šebek, CSc.

Diplomová práce Projekt konverze měny SKK na EUR v ERP SAP · 2014-11-27 · Vysoká škola...

Documents

Transcript of Diplomová práce Projekt konverze měny SKK na EUR v ERP SAP · 2014-11-27 · Vysoká škola...