Implementace řešení SFA a EDI

Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod

Implementace řešení SFA a EDI Diplomová práce

Autor:

Bc. Jakub Zárybnický Informační technologie a management

Vedoucí práce:

Praha

Ing. Vladimír Beneš, Ph.D.

Duben, 2015

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

V Praze dne 4. května 2015

……………………… Bc. Jakub Zárybnický

Poděkování Tímto

bych

chtěl

poděkovat

vedoucímu

této

diplomové

práce,

Ing.

Lubomíru

Jankových, CSc. a Ing. Vladimíru Benešovi, Ph.D., za pomoc, věnovaný čas, za hodnotné rady a odborné vedení během jejího zpracování. Dále děkuji zástupci společnosti BOC, Ing. Milanu Slavíkovi, za zapůjčení licence na nástroj pro modelování procesů ADONIS a hodnotné rady při jeho pouţití.

Anotace Diplomová práce se zabývá implementacemi řešení EDI (Electronic Data Interchange) a SFA (Sales Force Automation) do podnikového prostředí a jejími vlivy na ekonomiku a obchodní procesy. Detailně jsou rozebrány principy fungování obou řešení a jejich vazba na centrální informační systém. Dále jsou v práci popisovány zkušenosti, praktické problémy a rizika z reálných implementačních projektů i správy obou řešení. Formou případové studie je provedena kvalifikovaná kalkulace investice do implementací včetně její návratnosti a na konkrétním případu jsou vypočteny provozní náklady obou řešení ve srovnání s provozními náklady bez těchto řešení. V práci je graficky znázorněna struktura ceny na odeslání jednoho dokladu přes EDI v porovnání s papírovou formou. Důraz je kladen na případy, v jakých se implementace řešení vyplatí a na co je třeba zaměřit pozornost před, po i během implementace. Závěrečná část diplomové práce se zabývá modelováním a simulací procesů, ze které jsou vyvozeny závěry. Klíčová slova: Electronic Data Interchange, Sales Force Automation, implementace, obchodní procesy, případová studie, přínosy a náklady, modely procesů, simulace procesů

Annotation This thesis deals with implementations of EDI (Electronic Data Interchange) and SFA (Sales Force Automation) solutions into the business environment and theirs impact to the economy and business processes of company. In this thesis are discussed in detail the principles of operation both solutions and thein relation to the central informatik system. The work describes experiences, practical problems and risks from real implementation projects and management of both solutions. The work includes a case study to calculate investment costs of implementation, including its return. On the specific case are calculated operating costs of the two solutions compared to operating costs without these solutions. In the work is graphically elaborated structure of prices to send a document via EDI in comparison with the paper form. Accent is placed on cases in which implementations of solutions can be justified and chat must be considered before, during and after implementation. The final part of thesis deals with the proces models, which emphasize process chase after implementations and at the same time the simulation of processes is created, again compared before and after implementations, from which conclusions are drawn. Keywords: Electronic Data Interchange, Sales Force Automation, implementation, business processes, case study, costs and benefits, process models, process simulation

Obsah ÚVOD .............................................................................................................................................. 8 1

ZVOLENÉ METODY ZPRACOVÁNÍ ................................................................................ 10

2

CHARAKTERISTIKA ŘEŠENÍ EDI A SFA ....................................................................... 11 2.1 2.1.1

Organizace GS1 a její význam pro EDI komunikaci................................................. 13

2.1.2

Význam EDI komunikace ......................................................................................... 14

2.1.3

Moţná řešení EDI komunikace ................................................................................. 17

2.1.4

Zabezpečení ............................................................................................................... 22

2.1.5

Archivace ................................................................................................................... 23

2.1.6

Alternativní řešení ..................................................................................................... 24

2.1.7

Vliv na firemní procesy ............................................................................................. 24

2.2

3

SFA (Sales Force Automation) ...................................................................................... 25

2.2.1

Význam řešení SFA ................................................................................................... 25

2.2.2

Výčet a uspořádání modulů ....................................................................................... 27

2.2.3

Podpora pro management .......................................................................................... 28

2.2.4

Zabezpečení ............................................................................................................... 28

2.2.5

Vliv na firemní procesy ............................................................................................. 28

NÁVRH POSTUPU PŘI IMPLEMENTACI ........................................................................ 29 3.1

EDI (Electronic Data Interchange) ............................................................................... 29

3.1.1

Studie proveditelnosti ................................................................................................ 29

3.1.2

Postup implementace v bodech ................................................................................. 30

3.1.3

Integrace s podnikovým informačním systémem ...................................................... 33

3.2

4



3.2.1

Definice poţadavků a cílů ......................................................................................... 36

3.2.2

Postup implementace v bodech ................................................................................. 36

3.2.3

Integrace s podnikovým informačním systémem ...................................................... 39

PŘÍNOSY A NÁKLADY REALIZOVANÝCH ŘEŠENÍ .................................................... 41 4.1


4.1.1

Mzdové náklady na interní projektový tým ............................................................... 41

4.1.2

Náklady na externí dodavatele .................................................................................. 44

4.1.3

Měsíční provozní náklady ......................................................................................... 45

4.1.4

Přínosy implementace................................................................................................ 49

4.1.5

Návratnost investice do EDI ...................................................................................... 51

6

4.2

5

6

7

4.2.1

Mzdové náklady na interní projektový tým ............................................................... 52

4.2.2

Náklady na externí dodavatele .................................................................................. 54

4.2.3

Měsíční provozní náklady ......................................................................................... 55

4.2.4

Přínosy implementace................................................................................................ 56

4.2.5

Shrnutí a návratnost investice .................................................................................... 59

DOPORUČENÍ PRO IMPLEMENTACI A PROVOZ ......................................................... 60 5.1

Specifikace business poţadavků .................................................................................... 60

5.2

Zpracování implementační studie .................................................................................. 60

5.3

Vliv řešení na procesy a informační systém .................................................................. 61

5.4

Archivace faktur a změna operátora .............................................................................. 62

5.5

Zapojování nových partnerů .......................................................................................... 62

5.6

Správa řešení .................................................................................................................. 63

ADONIS – NÁSTROJ PRO MODELOVÁNÍ PROCESŮ ................................................... 64 6.1

Význam a smysl modelování procesů ........................................................................... 64

6.2

Základní charakteristiky ................................................................................................ 64

6.3

Komponenty .................................................................................................................. 66

6.4

Licence ........................................................................................................................... 68

6.5

Přednosti ........................................................................................................................ 69

DIAGRAMY PROCESŮ A SIMULACE ............................................................................. 71 7.1


7.1.1

Modelování procesu zpracování objednávky od odběratele ...................................... 71

7.1.2

Simulace procesu zpracování objednávky od odběratele .......................................... 76

7.1.3

Výsledky simulace procesu zpracování objednávky od odběratele .......................... 80

7.2

8



7.2.1

Modelování procesu zpracování objednávky od obchodního zástupce ..................... 81

7.2.2

Simulace procesu zpracování objednávky od obchodního zástupce ......................... 87

7.2.3

Výsledky simulace procesu zpracování objednávky od obchodního zástupce.......... 91

SHRNUTÍ PRAKTICKÉ ČÁSTI .......................................................................................... 92

ZÁVĚR ........................................................................................................................................... 95 SEZNAM POUŢITÉ LITERATURY ............................................................................................ 97 SEZNAM TABULEK .................................................................................................................... 98 SEZNAM OBRÁZKŮ ................................................................................................................... 99 SEZNAM GRAFŮ ....................................................................................................................... 100 SEZNAM PŘÍLOH ...................................................................................................................... 101

7

ÚVOD Tato diplomová práce je věnována implementaci dvou významných řešení podporujících obchodní procesy v podnikovém prostředí. Jde o elektronickou výměnu dokladů mezi dvěma samostatnými

obchodními

subjekty,

tzv.

EDI

(Electronic

Data

Interchange)

a o nástroj podporující a akcelerující obchodní proces, tzv. SFA (Sales Force Automation). Hlavním cílem této práce je navrhnout, realizovat a zhodnotit implementaci řešení EDI a SFA v prostředí vybraného podniku, namodelovat procesy a provést jejich simulaci pomocí nástroje ADONIS. Řešení EDI má klíčový vliv na rychlost výměny obchodních dokumentů mezi dvěma obchodními společnostmi a současně pozitivně ovlivňuje sloţku provozních nákladů. Při vyuţití mezinárodně spravovaného standardu, řešení EDI zajišťuje výměnu různých strukturovaných zpráv, jejichţ význam se liší podle typu zprávy a jejího obsahu. Řešení EDI obecněji zajišťuje přenos datových zpráv mezi informačními systémy dvou samostatných a nezávislých podnikatelských subjektů. Řešení SFA naopak podporuje obchodní aktivity přímo u zákazníka. Jinými slovy slouţí jako pracovní nástroj obchodním zástupcům, kteří mají za úkol sbírat objednávky od zákazníků při osobních schůzkách a současně monitorovat trh a konkurenční prostředí. Řešení SFA má klíčový vliv na správné rozhodování vedení firmy a správnou volbu obchodní strategie. Obchodní zástupci sbírají online data z podnikového okolí a vedení na základě těchto dat činí rozhodnutí, která mají přímý dopad na konkurenceschopnost společnosti. Obě řešení jsou zvolena pro tuto diplomovou práci z toho důvodu, ţe je v současné době vnímána určitá absence podobného zdroje informací, týkajících se řešení pro podporu obchodu. Proto je vedlejším cílem této práce přispět k publikaci informací, praktických rad, zkušeností a zjednodušeně vytvořit jakéhosi průvodce v oblasti, který pomůţe svým uţivatelům zorientovat se v problematice řešení pro podporu obchodu. Dalším důvodem pro volbu tohoto tématu diplomové práce je dosaţená úroveň znalosti a zkušenosti s předmětným řešením a to jak z provozu, tak také z implementačních projektů. Následující text by mohl být uţitečný zejména pro ty, kteří podnikání chápou jako neustálý koloběh inovací a změn vedoucích k dosaţení cíle, maximalizace zisku.

8

Nevědomost a neznalost problematiky způsobuje zbytečný odpor. Proto dalším vedlejším cílem této diplomové práce je odbourat v následujícím textu odpor a pokusit se informovat srozumitelně o přínosech obou řešení, ať uţ jde o přínosy na straně ekonomické nebo procesní efektivity. Teoretická část (kapitola 2, 3, 6) diplomové práce je teoretickým úvodem do problematiky. Je zde vymezen význam, přínosy a cíle obou řešení v organizaci. Jsou zde rozebrány moţné varianty řešení provozu obou řešení a popsány principy fungování jednotlivých variant. Teoretická část je dále věnována zabezpečení, modulové struktuře a vazbě na podnikový informační systém. Jsou v ní shrnuty a vymezeny klíčové vlivy obou řešení a definovány základní předpoklady a důvody, které by měly organizaci vést k rozhodnutí řešení implementovat. Součástí teoretické části diplomové práce je samostatně také kapitola 6, která je věnovaná nástroji na modelování procesů ADONIS. V rámci této kapitoly jsou vymezeny klíčové vlastnosti nástroje, jeho význam a moţnosti vyuţití. V celé praktické části (kapitoly 4, 5, 7, 8) jsou formou případové studie popsány implementace obou řešení do podnikového prostředí včetně vlastních zkušeností z implementací nebo se samotným provozem. Dále jsou zde rozebrány investiční náklady na implementaci obou řešení a následné provozní náklady. V této souvislosti je dále vypočtena návratnost investice vycházející z reálné statistiky provozu v podnikovém prostředí. V závěru praktické části jsou namodelovány procesy a uvedeny výsledky procesních simulací. Z nich jsou vyvozeny konkrétní závěry, čímţ je dokončeno zhodnocení implementací.

9

1 ZVOLENÉ METODY ZPRACOVÁNÍ Zvolenou metodou zpracování této diplomové práce je metodický návrh a jeho ověření případovou studií provedenou ve vybraném podniku. V rámci případové studie jsou pouţita data, statistické údaje, smluvní partnersko-dodavatelské podmínky z firemního prostředí. Tato vybraná data vzešla z kontinuálního monitoringu provozu vybraných informačních systémů, z obchodních a partnerských jednání či z podnikového účetnictví. V těchto předmětných oblastech byla provedena vnitropodniková rešerše a analýza dostupných dat z úvodních implementačních studií či provedených komparací jednotlivých moţností řešení. Na základě těchto dat, zkušeností a praxe autora bylo moţné provést detailní rozbor průběhu implementace a rozbor souvisejících investičních i provozních nákladů. Současně tato data umoţnila provést rozklad ceny na odeslání jednoho papírového dokladu v porovnání s cenou jednoho odeslaného dokladu formou EDI. Další metodou, jeţ byla v této práci pouţita, je procesní analýza, následná simulace a s tím související modelování procesů. Byl pouţit nástroj ADONIS pro modelování procesů, v rámci kterého byly pouţity dostupné funkce, jeţ na základě vstupních parametrů modelů poskytly poţadovaný výstup v podobě měřitelných a porovnatelných procesních atributů. Na základě tohoto výstupu z funkcí nástroje byla provedena komparace výstupních hodnot před a po implementaci řešení, proto bylo moţné vyvodit relevantní závěry a zhodnotit vliv implementace na firemní procesy. Při zpracování této diplomové práce byla vyuţita autorova dosavadní praxe, nabyté zkušenosti a přístup k informacím. Tato data byla kontinuálně srovnávána s dostupnými názory a zkušenostmi širší skupiny odborníků i uţivatelů dostupných na internetu nebo na různých veřejných konferencích či jiných schůzkách a setkáních.

10

2 CHARAKTERISTIKA ŘEŠENÍ EDI A SFA V této kapitole jsou popsány vlastnosti řešení EDI (Electronic Data Interchange) a SFA (Sales Force Automation), jejich význam pro organizaci a jejich klíčové parametry. Touto kapitolou jsou popsána obě řešení, jejichţ implementace proběhne v rámci kapitoly 3.

2.1 EDI (Electronic Data Interchange) EDI (Electronic Data Interchange – Elektronická výměna dat) je elektronická forma komunikace

obchodních

dokumentů

mezi

dvěma

podnikatelskými

subjekty,

při které si oba subjekty vyměňují standardizované a strukturované zprávy, jejichţ struktura vychází z mezinárodních standardů. Elektronická

výměna

dat

se

chápe

jako

způsob

výměny

strukturovaných

dat

(např. objednávek, faktur, dobropisů, apod.) na základě dohodnutých standardů zpráv mezi informačními systémy jednotlivých obchodních partnerů pomocí elektronických prostředků. Je to elektronická výměna strukturovaných standardních zpráv mezi dvěma aplikacemi dvou nezávislých subjektů.1 Během EDI komunikace dochází k přenosu například objednávky z informačního systému odběratele do informačního systému dodavatele. Informační systém představuje konzistentní uspořádanou množinu komponent spolupracující za účelem tvorby, shromažďování, zpracování, přenášení a rozšiřování informací. Prvky informačního systému tvoří lidé, respektive uživatelé informací, a informační zdroje.2 EDI je technologie, která není v oblasti obchodu ţádnou novinkou. První projekty s cílem implementovat EDI vznikaly v 60. letech v oblasti automobilového průmyslu3. První úspěšná praktická aplikace se však objevila na londýnském letišti Heathrow na počátku 70. let v podobě systému LACES pro celní odbavování leteckých nákladů.4 Princip EDI komunikace je postaven na nadnárodních standardech, nejde proto o ţádnou krátkodobou novinku, ale roky ověřovanou technologii v rámci celého světa. Internet je dnes

1

(11 str. 429) GÁLA, Libor (2009). Podniková informatika. Příbram: Grada Publishing, a.s. (11 str. 25) GÁLA, Libor (2009). Podniková informatika. Příbram: Grada Publishing, a.s. 3 (9 str. 5) REICHEL, David. Jak na elektronickou výměnu dat? [Online] 2 2015. 4 (11 str. 430) GÁLA, Libor (2009). Podniková informatika. Příbram: Grada Publishing, a.s. 2

11

jiţ dostupný téměř po celém světě a díky tomu dnes mohou EDI komunikaci vyuţívat v libovolném oboru či odvětví. Čitelnost a kompatibilita dokumentů na obou stranách je zajištěna jediným mezinárodním multioborovým standardem UN/EDIFACT (United Nations / Electronic Data Interchange for Administration, Commerce and Transport), který byl ratifikován, vyvinut a je spravován Organizací Spojených národů (OSN), konkrétně institucí United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) v rámci hospodářské komise OSN pro Evropu5. Standard se pouţívá na celém světě s výjimkou Severní Ameriky, kde se pouţívají standardy ANSI ASC X12 (American National Standard Institute Accredited Standards Committee X12) a UCS (Uniform Communication Standard). EDI standard se definuje jako dohodnutá reprezentace informace (jaké položky, jak strukturovány a kompletovány), která se má přenášet z jedné počítačové aplikace do jiné. Standardy EDI tak definují způsob vyjádření jednotlivých částí obchodních dokumentů, tj. jednotlivých položek (identifikace zboží, název zboží, cena, datum dodání, …) a jejich seskupování do obchodních dokumentů nebo zpráv (objednávka, faktura, …).6 Během dosavadního vývoje EDI komunikace vznikla celá řada národních a oborových standardů výměny dat, jakými jsou například SWIFT v bankovnictví, ODETTE (The Organisation for Data Exchange by Tele Transmission in Europe) v automobilovém průmyslu, zmíněné ANSI X12 je americkou národní normou, SEDAS je německou národní normou, HIPAA (The Health Insurance Portability and Accountability Act) normou ve zdravotnictví. Tyto standardy jsou však vzájemně nekompatibilní, proto je řešením této situace mezinárodní a „multioborově“ uznávaný standard UN/EDIFACT, který postupně nahrazuje národní a oborové standardy. Tato diplomová práce se zabývá standardem běţným v Evropské Unii, UN/EDIFACT. Nadnárodní organizace GS1, resp. sdruţení GS1 Czech Republic7, o kterém pojednává další kapitola, dále vymezuje standard UN/EDIFACT pro oblast obchodu zejména se spotřebním zboţím a zpracovává tzv. implementační příručky (sub sety) pro aplikační normu GS1 EANCOM. Jiným obdobným vymezením standardu UN/EDIFACT je například v oblasti automobilového průmyslu standardizační sdruţení VDA (Verband der Automobilindustrie) a ODDETE, které zpracovává podobné sub sety ve svém oboru. Sub sety lze chápat jako 5

(4) GXS. EDIFACT. EDI Basics: Your resource for learning about EDI. [Online] 2015. (11 str. 430) GÁLA, Libor (2009). Podniková informatika. Příbram: Grada Publishing, a.s. 7 Název subjektu: GS1 Czech Republic; Identifikační číslo: 604 33 591; Spisová značka: L 58574 vedená u Městského soudu v Praze; Sídlo: Na Pankráci 1618/30, Nusle, 140 00 Praha 6

12

podrobnou specifikaci a doporučený platný vzor formátu jednotlivých druhů zpráv pouţívaných v národním prostředí a běţné praxi. Sub sety vymezují tzv. inhouse formát (výstup z informačního systému) a EDI formát (výstup z konvertoru), který je následně přenášen po VAN (Value Added Network) sítích. Inhouse formát je posléze konvertován do EDI formátu, který je dále členěn do8: 1) Datových prvků (Data Elements) Všechny jednotlivé údaje obsaţené v dokumentu. 2) Datových segmentů (Data Segments) Logické seskupení datových prvků (údajů) do vyššího celku. Datový prvek je součástí mnoţiny prvků nazvané datový segment. Z těchto částí je následně sestavena: 1) Zpráva (Message) Sestavována ze segmentů a musí být dodrţena syntaktická pravidla definována standardy UN/EDIFACT, resp. GS1 EANCOM. Zpráva plní některou z obchodních funkcí, například objednávka. 2) Funkční skupina (Functional Groups) Skupina několika zpráv stejného typu (např. „balík“ objednávek za daný den). 3) Výměna (Interchange) Jednotka komunikace mezi partnery (identifikátor výměny). Můţe obsahovat jednu zprávu nebo celou funkční skupinu.

2.1.1 Organizace GS1 a její význam pro EDI komunikaci Mezinárodní standard UN/EDIFACT zajišťuje čitelnost zpráv na obou stranách komunikace a pro jednotlivé obory je blíţe specifikován jednotlivými standardizačními pracovními skupinami ve svých oborech. Zmínil jsem, ţe pro oblast obchodu se spotřebním zboţím je to standard GS1 EANCOM, který celosvětově spravuje organizace GS1 a lokálně v České republice sdruţení GS1 Czech Republic. Různé národy mohou mít i vzhledem k různé legislativě, měně, měrným jednotkám atp., také různé potřeby nebo poţadavky na jednotlivé zprávy. Proto jsou vydávány tzv. národní sub sety, coţ jsou implementační příručky, které standard vymezují pro potřeby konkrétního státu a na míru specifikují strukturu a formát jednotlivých zpráv. 8

Ilustrativní vzor datové zprávy je součástí přílohy k diplomové práci na kompaktním disku.

13

GS1 je nadnárodní organizace zaměřená na navrhování a praktické zavádění globálních standardů v celosvětovém měřítku a napříč odvětvími. GS1 byla založena sjednocením Uniform Code Council (UCC), Electronic Code Council of Canada (ECCC) a EAN International. Sídlí v Bruselu, New Jersey a Ohiu.9 V České republice roli GS1 zastupuje neziskové zájmové sdruţení právnických osob GS1 Czech Republic, jehoţ činností je koordinace, metodika a poradenství. Je organizací zabývající se tvorbou globálních standardů a jejich implementací, s cílem zvýšit efektivitu a transparentnost logistických a dodavatelsko-odběratelských řetězců na globální i lokální, ale zároveň také mezioborové úrovni.10 Systém GS1 je ucelený soubor mezinárodně platných standardů pro automatickou identifikaci a elektronickou komunikaci informací o identifikovaných položkách, službách, objektech nebo subjektech. Jde o systém, který je v současné době nejrozšířenějším standardem v rámci globálního logistického řetězce na světě.11 V rámci aktivit GS1 Czech Republic probíhá dlouhodobý vývoj národních implementačních příruček, tzv. sub setů GS1 EANCOM. Před několika lety byla připravena kompletní sada zpráv podle GS1 EANCOM 2002, spíše známá jako sub set EDIFACT D.01B, který navazuje na předchozí GS1 EANCOM 1997 známý jako sub set EDIFACT D.96B. Z pohledu odběratele (řetězce) či dodavatele (distributora nebo výrobce) můţe být sdruţení GS1 chápáno také jako registrátor. U GS1 je totiţ moţné registrovat například novou prodejnu, v tom případě je třeba registrovat tzv. GLN (Global Location Number) nebo nový výrobek GTIN (Global Trade Item Number). Po registraci získáte jednoznačný identifikátor obchodního místa nebo obchodní poloţky. Obě tyto hodnoty jsou posléze klíčové v komunikovaných zprávách.

2.1.2 Význam EDI komunikace Význam EDI komunikace spočívá především v tom, ţe umoţňuje propojení různých informačních systémů dvou nezávislých obchodních partnerů. Základním cílem EDI komunikace je postupné nahrazování papírových dokumentů elektronickými. Odvozeným cílem pak je sníţení nákladů spojených s výměnou papírových dokladů a také zvýšení efektivity a kvality prováděných podnikových procesů. 9

(5) GS1. GS1 around the world. GS1 - The global language of business. [Online] 2015. (6) GS1 Czech Republic. O nás. [Online] 2015. 11 (7) GS1. Overview. GS1 - The global language of business. [Online] 2015. 10

14

Proces je definován jako soubor vzájemně souvisejících nebo vzájemně působících činností, který přeměňuje vstupy na výstupy. Činnosti využívají zdrojů (lidí, nástrojů, materiálu, apod.). Proces může mít více vstupů a také více výstupů.12 EDI způsob komunikace samozřejmě vychází z předpokladu, ţe doklady přenesené touto formou mají stejnou právní váhu jako běţné „papírové“ dokumenty. V České republice upravují elektronickou komunikaci (fakturaci) tyto právní předpisy: zákon č. 235/2004 Sb., o DPH, zákon č. 563/1991 Sb., o účetnictví, zákon č. 227/2000 Sb., o elektronickém podpisu. Tyto zákony vymezují vzhledem k elektronické fakturaci velmi zjednodušeně zejména tyto podmínky: 1) Kaţdá elektronická faktura musí být opatřena elektronickým podpisem. Podmínkou je zřízení certifikátu u některé z certifikačních autorit v České republice. 2) Taková elektronická faktura musí být následně archivována nejméně po dobu 10 let. V obchodní praxi však lze tyto podmínky „obejít“ a v rámci obchodního partnerství si smluvně specifikovat vlastní a uznávat si tak například i faktury neopatřené elektronickým podpisem. Na obrázcích níţe je znázorněn význam řešení EDI pro proces odeslání a přijmutí objednávky. Je zde patrné ono zkvalitnění a zefektivnění firemních procesů na obou stranách komunikace. V prvním případě je uţivatel na straně odběratele nucen objednávku vytisknout a odeslat poštou. Uţivatel na straně dodavatele je nucen poštu přijmout a objednávku zadat ručně do informačního systému. Samozřejmě je moţné poštu nahradit například faxem nebo emailem, stále ale neodpadá ruční zadávání do informačních systémů. V druhém případě uţivatel na straně odběratele pouze vytvoří objednávku v informačním systému, všechno ostatní, aţ do přijetí objednávky do informačního systému dodavatele, je plně automatické. Hlavními výhodami EDI komunikace obchodních dokumentů jsou: Automatizovaný proces. Eliminována chybovost způsobená lidským faktorem. Ţádné zbytečné „papírování“ a „obálkování“. Objednávka je u dodavatele v řádu minut, nikoliv dní jako v případě pošty. Vytvoření pevných vazeb k obchodním partnerům a obrana proti nové konkurenci. Sníţení dodacích lhůt. 12

(11 str. 25) GÁLA, Libor (2009). Podniková informatika. Příbram: Grada Publishing, a.s.

15

Sníţení nákladů na administrativu. Urychlení platebního styku a lepší moţnost sledování cashflow.

Obrázek č. 2.1: EDI - zjednodušený proces výměny objednávky papírovou formou (zdroj: autor)

Obrázek č. 2.2: EDI - zjednodušený proces výměny objednávky el. formou (zdroj: autor)

16

2.1.3 Moţná řešení EDI komunikace Existují dva základní způsoby provozu EDI komunikace: 1. Výměna zpráv přímo mezi koncovými subjekty (end-to-end) o Jde o přímé spojení mezi dvěma obchodními partnery, zpravidla mezi velkými obchodními řetězci a velkými dodavateli. o Správa a vývoj takových řešení je realizována samotnými účastníky komunikace. o Komunikace bývá v těchto případech realizována pomocí X. 400 / AS2 (Applicability Statement 2) internetového komunikačního protokolu. 2. Výměna zpráv prostřednictvím VAN sítě a. Výměna zpráv po VAN síti a při vyuţití sluţeb VAN operátora 

Jde o komunikaci po soukromých sítích, kde VAN operátor zřizuje schránky a zajišťuje přenos strukturovaných zpráv mezi nimi.



Komunikace bývá v těchto případech realizována pomocí sady protokolů TCP/IP, ale často také opět pomocí X. 400 / AS2 (Applicability Statement 2) internetového komunikačního protokolu.



Specializovaný software pro konverzi a šifrování či podepisování zůstává na straně klienta.

b. Výměna zpráv po VAN síti, při vyuţití sluţeb VAN operátora a poskytovatele sluţeb EDI 

Jde o komunikaci po soukromých sítích, kde VAN operátor zřizuje schránky, zajišťuje komunikaci mezi nimi a zároveň jako poskytovatel sluţeb EDI provádí analýzu inhouse formátu, jeho konverzi do UN/EDIFACT, šifrování či podepisování.



Komunikace je v těchto případech realizována pomocí sady protokolů TCP/IP.



Specializovaný software pro konverzi a šifrování či podepisování je na straně poskytovatele sluţeb EDI, u klienta zůstává pouze jednoduchý komunikátor pro přenos zpráv v inhouse formátu do schránky.

17

c. WebEDI 

Jde o komunikaci po soukromých sítích, kde VAN operátor zřizuje schránky a zajišťuje přenos strukturovaných zpráv mezi nimi.



Operátor klientovi zřídí přístup na webové rozhraní, kde klient manuálně vytváří různé typy zpráv a manuálně je odesílá svým obchodním partnerům.



Řešení je vhodné pro ty situace, kdy existuje vůle splnit poţadavky řetězců na zavedení EDI komunikace a zároveň ale vycházíme z malého mnoţství komunikovaných dokladů.



U klienta není ţádný software, celé řešení se nachází u poskytovatele sluţeb EDI a neexistuje ţádná vazba na podnikový informační systém.

Způsoby 1, 2a, 2b jsou podrobněji popsány v následujících podkapitolách. Pro celý proces výměny zpráv mezi subjekty je ve všech uvedených případech klíčový EDI konvertor. Jde o aplikaci, která konvertuje data z informačních systémů (z inhouse formátu) do formátu UN/EDIFACT, EANCOM (dále formát EDI) a opačně. Konvertor tak na straně odesílatele konvertuje odchozí data z informačního systému do formátu EDI a pošle je prostřednictvím VAN sítě příjemci. Konvertor na straně příjemce konvertuje příchozí data z formátu EDI do formátu informačního systému příjemce. Formát, který je na straně odesílatele vstupem pro konvertor a na straně příjemce výstupem z konvertoru je obecně nazýván inhouse formát, který je specifikován stejným standardem UN/EDIFACT, EANCOM. 2.1.3.1 Výměna zpráv přímo mezi koncovými subjekty Oba subjekty musí vlastnit konvertor a komunikační software pro připojení do datové sítě. Celá komunikace je realizována pouze obchodními stranami bez vyuţití poskytovatele. Konvertory a komunikační nástroje jsou vysoce specializovaným softwarem, z čehoţ vyplývá i jejich cena. S tímto řešením souvisí vysoké pořizovací náklady a náklady na provoz, správu a aktualizaci dle národní legislativy a poţadavků svých obchodních partnerů.

18

Obrázek č. 2.3: EDI - schéma komunikace end-to-end bez využití dodatečných služeb (zdroj: autor)

2.1.3.2 Výměna zpráv prostřednictvím VAN operátora VAN je síť, v rámci které probíhá přenos datových zpráv. VAN operátor dále zaručuje nezkreslenou informaci při přenosu k adresátovi. Část starostí s provozem tak přebírá VAN operátor, který je zároveň provozovatelem sítě. Operátor je také zpravidla dodavatelem specializovaného softwaru, konvertoru, zabezpečovacího modulu (šifrování a podepisování) a komunikačního nástroje pro připojení do VAN. Důleţité je, ţe konvertor i komunikační software zůstává stále u klienta a tím vznikají i pořizovací náklady a dále náklady spojené s jejich provozem a správou.

19

Obrázek č. 2.4: EDI - schéma komunikace při využití služeb VAN operátora (zdroj: autor)

2.1.3.3 Zpracování a výměna zpráv prostřednictvím VAN operátora a poskytovatele sluţeb EDI Tento způsob komunikace vychází z předchozího modelu, poskytovatel a zároveň VAN operátor však navíc provádí také analýzu inhouse formátu, jeho konverzi, připojení podpisu a případné šifrování. Znamená to v důsledku, ţe klient s vyuţitím internetu na své straně potřebuje pouze jednoduchý komunikátor, který přenese zprávu v inhouse formátu k poskytovateli a operátorovi VAN. Důleţité je, ţe k provozu takto zvoleného způsobu komunikace stačí běţný počítač s připojením na internet. Poskytovatel přebírá všechny činnosti spojené s konverzí a doručením. Odpadají tak veškeré náklady spojené s pořízením specializovaného softwaru, s jeho provozem a následnou správou.

20

Obrázek č. 2.5: EDI - schéma komunikace při využití služeb poskytovatele (zdroj: autor)

Obrázek č. 2.6: EDI - zjednodušené schéma sítě VAN (zdroj: autor)

21

2.1.4 Zabezpečení V případě úvah o implementaci EDI, je třeba se zamyslet a věnovat zvláštní pozornost bezpečnosti, a to zejména přenášených dat. Z toho důvodu je třeba při analýze a projektování řešení zvolit vhodnou bezpečnostní politiku, která následně bude uplatňována při provozu řešení. Před samotnou volbou bezpečnostní politiky je nutná definice moţných ohroţení, ze kterých je následně moţné vyjít a zvolit správné bezpečnostní mechanismy. Moţná ohroţení bezpečnosti v rámci přenosu EDI zpráv jsou tato: Modifikace zprávy – během přenosu je zpráva změněna ať uţ úmyslně nebo v důsledku chyby. o Integrita zprávy – modifikace zprávy během přenosu bude zásluhou této funkce odhalena. o Integritu zprávy zajišťuje digitální podpis. Vydávání se za někoho jiného – jedna ze stran v procesu komunikace se vydává za jiného účastníka. o Autentizace zprávy umoţňuje určit odesílatele. o Autenticitu zprávy zajišťuje digitální podpis. Zneuţití důvěrné informace – důvěrné zprávy jsou získány neoprávněnou osobou nebo jinak zneuţity. o Řízení přístupu umoţňuje omezit přístup oprávněným osobám. o Šifrování obsahu zprávy zajišťuje důvěrnost dat během přenosu. Přístup neoprávněné osoby o Řízení přístupu bývá zajištěno politikou hesel, kdy kaţdý oprávněný uţivatel je povinný si nastavit dostatečně silné heslo a uchovat ho v tajnosti. Změna v pořadí zpráv – zprávy jsou zpravidla odesílány v balících a obvykle je také důleţité, v jakém pořadí jsou adresátovi doručeny. o

Integrita sekvence zpráv – funkce zajišťuje, ţe ţádná zpráva nebyla zkopírována a odeslána znovu, stejně tak umoţní zjistit ztrátu zprávy a změnu v pořadí.

o

Sekvenční integrita bývá zajištěna referenčním číslem zprávy a dále pomocí časové značky.

22

Odmítnutí původu zprávy – odesílatel později odmítne odeslání zprávy. o Neodmítnutí původu zprávy zajišťuje, ţe odesílatel nemůţe později popřít odeslání zprávy. o Neodmítnutí původu zprávy je zajištěno digitálním podpisem. Odmítnutí příjmu zprávy – příjemce později odmítne příjem zprávy. o Neodmítnutí příjmu zprávy zajišťuje, ţe příjemce nemůţe později popřít příjem zprávy. o Neodmítnutí příjmu zprávy je zajištěno zprávou AUTACK, která potvrzuje příjem zprávy a digitálního podpisu. 2.1.4.1 Bezpečnostní řešení v UN/EDIFACT Bezpečnostní funkce dostupné v rámci standardu UN/EDIFACT poskytují bezpečnost způsobem end-to-end, tzn. od jednoho subjektu k druhému nezávisle na způsobu přenosu zpráv (i v nezabezpečených veřejných komunikačních sítích). V rámci standardu jsou definovány struktury, které umoţňují pouţít digitální podpis přímo ve zprávách. Kaţdá zpráva, opatřená digitálním podpisem, obsahuje úvodní bezpečnostní segmenty (Security Header), které obsahují údaje o pouţitých algoritmech, způsob vytvoření podpisu a certifikát odesílatele. Zprávy také obsahují závěrečné bezpečnostní segmenty (Security Trailer), kde jsou výsledky autentizace zprávy. Při tvorbě digitálního podpisu je ke zprávě nejprve vytvořen, pomocí hash funkce, kontrolní blok bitů. Tento blok je následně zašifrován tajným klíčem odesílatele zprávy a připojen ke zprávě. Pokud je celý přenos zpráv navíc realizován po zabezpečených sítích nebo komunikačních kanálech, lze komunikaci povaţovat za bezpečnou.

2.1.5 Archivace Dalším problematickým aspektem EDI komunikace je správné archivování. Pod správným archivováním je třeba si představit dlouhodobou, důvěryhodnou a digitální archivaci. Jde o takovou archivaci, která v budoucnu vţdy zabezpečí pravost, nezměnitelnost, průkaznost, čitelnost a chronologii dokumentů. Legislativa České republiky (zákon č. 227/2000 Sb., o elektronickém podpisu, zákon č. 235/2004 Sb., o DPH) v tomto smyslu hovoří o věrohodnosti původu (autenticitě), nezměnitelnosti obsahu (integritě) a stále převoditelnosti do čitelné podoby, to vše minimálně po dobu 10 let. Archivace se v tomto smyslu nejčastěji řeší s vyuţitím elektronického časového razítka a přiloţeným digitálním podpisem. Dokument

23

je tak ukotven v čase a je prokazatelné, ţe byl v tomto období podepsán sadou platných klíčů souvisejících s podpisovým certifikátem.

2.1.6 Alternativní řešení Alternativou k EDI je v současné době formát ISDOC (Information System Document). Je to formát elektronické fakturace, pro který se rozhodla pracovní skupina zástupců největších výrobců informačních systémů na území České republiky. Jedná se pouze o český národní standard, který nemá světový význam a není moţné ho aplikovat v rámci obchodní komunikace se zahraničím. Další alternativou běţnou spíše u malých společností je výměna elektronicky podepsaných dokumentů ve formátu PDF (Portable Document Format). V takovém případě vzniká problém s archivací těchto dokladů a je nadále nutné řešit problém s manuální prací uţivatele a to zejména při přenosu dat z dokumentu do informačního systému.

2.1.7 Vliv na firemní procesy Mezi základní vlivy řešení EDI na firemní procesy patří: Pravidelná a důsledná příprava dokladů k odeslání v informačním systému. Pravidelná a důsledná kontrola schránky společnosti vzhledem k reakcím příjemců. Okamţité hlášení chyb a problémů v komunikaci. Spolupráce obchodního oddělení s osobou zodpovědnou za provoz řešení na smluvních obchodních podmínkách. Důsledné vyplňování všech povinných údajů na jednotlivých dokladech v informačním systému. Aktivní rozvoj řešení ve společnosti vzhledem k nepřetrţité snaze komunikovat formou EDI s co nejvyšším mnoţstvím obchodních partnerů. Spolupráce útvarů ICT, obchod a logistika na dlouhodobém rozvoji EDI. Zákaznický servis pracuje výhradně s elektronickými daty a dokumenty, odpadá přepisování dat, tisk, balení a odesílání poštou.

24

2.2 SFA (Sales Force Automation) Řešení SFA (Sales Force Automation – automatizace prodeje) patří do skupiny řešení, jeţ podporují business a je proto přímým nástrojem obchodu a marketingu ke sběru dat od zákazníků a z dalšího podnikového okolí. SFA spadá do skupiny CRM (Customer Relationship Management) řešení a ve struktuře informačních systémů společnosti jde o jednu samostatnou aplikační větev, jejímţ datovým zdrojem i cílem bývá často řešení typu ERP (Enterprise Resource Planning). Mnohdy tak bývá realizováno rozhraní mezi oběma systémy, jeţ má za úkol přenos kmenových dat z centrálního ERP do SFA a zpět. Řízení vztahů se zákazníky (CRM – Customer Relationship Management) představuje komplex aplikačního a základního software, technických prostředků, podnikových procesů a personálních zdrojů, určených pro řízení a průběžné zajišťování vztahů se zákazníky firmy, a to v oblastech podpory obchodních činností, zejména prodeje, marketingu a zákaznických služeb.13 SFA řešení nabízejí nástroje pro přímou podporu obchodních aktivit společnosti. Rozvojem konceptu mobilního přenosu databází informačního systému plní tato řešení úlohu, díky které jsou uţivatelům v čase a v terénu přístupné informace na mobilních zařízeních (tablety, chytré telefony, notebooky). SFA řešení zkracují čas potřebný na přípravu jednání, zpřístupňují historické i aktuální informace o pohledávkách zákazníků, disponibility, skladových zásobách atp., a tím napomáhají cíleně řešit určené úlohy i s dohledem nad jejich splněním. Řešení tohoto typu jsou modulární, přizpůsobitelné potřebám uţivatelů a zahrnují přehledy aktivit, mobilní sběr objednávek, monitoring cen, formuláře, evidenci marketingových nástrojů, evidence nákladů, knihu jízd, podporu přímého prodeje, plnění obchodního plánu a další funkce. Toto řešení je vhodným nástrojem pro všechny obchodní společnosti s aktivními obchodními zástupci, pro které je následně SFA primárním pracovním nástrojem s měřitelnými přínosy v oblasti efektivity práce, informovanosti, pruţnosti, přesnosti, rychlosti a jednoduchosti.

2.2.1 Význam řešení SFA SFA pokrývá převáţnou většinu procesů obchodního zástupce. Jedná se o pracovní nástroj obchodního zástupce zejména pro plánování a realizaci svých aktivit se zákazníky. Umoţňuje centrálně řídit činnost obchodních zástupců, definovat jim jednotlivé kroky u zákazníka 13

(11 str. 165) GÁLA, Libor (2009). Podniková informatika. Příbram: Grada Publishing, a.s.

25

včetně povinnosti vykonání. Je nástrojem pro elektronickou komunikaci se zákaznickým servisem společnosti, čímţ plně nahrazuje telefon nebo fax. Umoţňuje pravidelný monitoring trhu nejen vzhledem ke konkurenci, ale také například ke kvalitě vlastních výrobků, jejich umístění a mnoţství. Aplikace také umoţňuje přímo fotografování a ukládání fotografií do centrální databáze. Spolupracuje s navigačním softwarem, jemuţ předává GPS (Global Positioning System) souřadnice a je tak moţné navigování k zákazníkovi. Nedílnou součástí je evidence akcí a různých marketingových kampaní, o kterých má díky aplikaci obchodní zástupce neustálý přehled. Informován je také o čerpání alokovaného budgetu pro podporu svého prodeje a dokáţe se zákazníkem velmi dobře komunikovat zásluhou dostupných informací o ceně, skladové dostupnosti, čárovému kódu nebo zákaznickému číslu produktu. Aplikace má také nástavbu pro stvrzení objednávky podpisem nebo pro automatickou tvorbu knihy jízd. Jedná se o nástroj k nezaplacení pro libovolnou firmu, jeţ by ráda centrálně řídila své obchodní procesy. Mezi základní funkcionality řešení SFA patří plánování návštěv obchodního zástupce u zákazníka a následný sběr informací od zákazníků. Nejčastěji to bývají ceny konkurenčních výrobků, jejich umístění a počet. Řešení kromě toho umoţňuje zejména sběr objednávek, kontaktů a fotografií. Je moţné definovat obchodnímu zástupci produkty zalistované u daného zákazníka na koncentrovaném trhu, vázat k nim probíhající akci ať uţ cenovou nebo marketingovou, přiřazovat obchodnímu zástupci úkoly a cíle, jichţ má za určité období dosáhnout. Na mobilním zařízení je moţné aplikaci pouţívat on-line i off-line. Pouţití v mobilní síti operátora umoţňuje dávkovou synchronizaci dat. Klient nemusí být připojený k serveru po dobu celého času provozu, stačí se v určeném období připojit k serveru a přenést aktuální změny v datech, provést tzv. synchronizaci. Klíčový význam a přínosy řešení SFA je moţné shrnout do následujících bodů: Okamţité zvýšení produktivity zaměstnanců obchodního útvaru způsobené optimalizovaným procesem výměny dokladů mezi společnostmi. Urychlení výměny dokumentů mezi společnostmi, pozitivní vliv na rychlost plateb, zprostředkovaný pozitivní vliv na cashflow. Jednodušší archivace obchodních dokumentů přímo v daném řešení bez nutnosti archivovat v šanonech. Pozitivní vliv na chybovost (lidský faktor) při ručním vkládání dat. Zvýšení bezpečnosti předávaných dokumentů. 26

Pozitivní vliv na vztahy mezi obchodními partnery pro niţší chybovost, rychlost a plynulost komunikace. Efektivnější vyuţití informací transformovaných do datových skladů. Kvalitní zdroj informací pro operativní, taktické a strategické rozhodování. Obchodní a marketingové informace dostupné všem na jednom místě. Zrychlení toku informací a zvýšení informovanosti. Sniţování nákladů a zvýšení výkonu obchodního týmu. Sníţení nároků na administrativu. Zautomatizování činností.

2.2.2 Výčet a uspořádání modulů Řešení SFA je nutné rozdělit na serverovou část, tzv. backend a klientskou část, tzv. frontend neboli mobilní zařízení. Backend je rozdělen do těchto modulů: Kmenové údaje – zákazníci, kontaktní osoby, produkty, teritoria, skupiny, cíle, sklady, sledování změn. Obchodní údaje – ceníky, slevy, kroky aktivit, listingy, doporučené produkty, POS materiály, POS audit, příleţitosti, kampaně, obchodní sloţka, rozpočty, pozice. Průzkum trhu – formuláře, monitoringy, plánogramy. Transakční data – aktivity, dokumenty, úkoly, zprávy, platby. Uţivatelská data – obchodní týmy, uţivatelé, denní přehled, log, zařízení, auta, náklady, pokladny. Konfigurace – číselníky, zákaznická/distributorská ID produktů, popisky polí, nastavení aplikace, uţivatelské role, pravidla pro zpracování dokumentů, naplánované úlohy, sazby DPH, správa tiskových šablon, automatické plánování aktivit, distribuční seznamy, nastavení frontendu. Frontend je rozdělen do těchto modulů: Hlavní menu – zákazníci, produkty, trasy, úkoly, formuláře, zprávy, rozpočty, akce. Menu aktivity – detail zákazníka, akce, zprávy, úkoly, formuláře, monitoringy, náklady, kroky aktivity, kontaktní osoby, sběr fotografií.

27

2.2.3 Podpora pro management Řešení SFA podporuje střední a vrcholový management v obchodním oddělení společnosti. Obchodní ředitel, v roli vrcholového manaţera, řešení pouţívá jako klíčový nástroj analýzy a podklad pro svá rozhodnutí. Střední management, v podobě obchodních manaţerů, řešení pouţívá jako nástroj pro řízení svých podřízených v terénu a monitoring jejich činnosti.

2.2.4 Zabezpečení Zabezpečení je zde zajištěno ve dvou úrovních, kterými je zabezpečený komunikační protokol a šifrování přenášené databáze vlastním šifrovacím algoritmem aplikačního softwaru. K tomu lze přičíst standardní způsob autentizace uţivatelským jménem a heslem. V případě ztráty nebo krádeţe mobilního zařízení je moţné velmi rychle zablokovat synchronizaci, lokalizovat nebo smazat zařízení pokud je připojeno k internetu.

2.2.5 Vliv na firemní procesy Mezi základní vlivy řešení SFA na firemní procesy patří: Důsledná správa a aktualizace dat o zákaznících a výrobcích v informačním systému. Změna komunikačního nástroje z faxu, mailu, pošty, telefonu na informační systém v kombinaci s tabletem nebo kapesním počítačem. Strukturovaná a řízená práce obchodního týmu. Nahrazení sběru kancelářských dokumentů strukturovanými a centrálně řízenými systémovými formuláři. Enormní zrychlení toku informací ve firmě díky vyuţití datového připojení obchodního týmu k centrální databázi a informačním systémům. Obchodní ředitel má vyšší kontrolu nad celým týmem a dostává k dispozici strukturované a automatizované obchodní analýzy, jeţ mají vliv na strategická i operativní rozhodnutí managementu firmy. Aktivní rozvoj řešení ve společnosti vzhledem k nepřetrţité snaze monitorovat trh optimálním způsobem a s ideálním výstupem. Spolupráce útvarů ICT, obchod a logistika na dlouhodobém rozvoji SFA. Zákaznický servis pracuje výhradně s elektronickými daty a dokumenty, odpadá přepisování dat.

28

3 NÁVRH POSTUPU PŘI IMPLEMENTACI V této kapitole je popsána implementace obou řešení charakterizovaných v kapitole 2. Postup implementace je popsán tak, aby z něho vyplýval význam kaţdého dílčího kroku a činnosti v celkovém procesu implementace.

3.1 EDI (Electronic Data Interchange) 3.1.1 Studie proveditelnosti Před samotnou implementací je třeba si poloţit klíčovou otázku: Proč zavádět EDI? Na tuto otázku existuje hned několik obecných odpovědí. EDI komunikaci podporují a mnohdy i vyţadují velké obchodní řetězce. EDI je standard, který je moţné vyuţít pro komunikaci se zahraničními partnery. EDI optimalizuje firemní procesy a šetří náklady. EDI je dnes jiţ cenově dostupné i pro menší nebo malé organizace. EDI zrychluje tok dokladů mezi obchodními partnery a má tak zřejmý vliv na logistiku, skladové hospodářství a cashflow. EDI sniţuje chybovost a minimalizuje vliv lidského faktoru. EDI usnadňuje archivaci dokladů. EDI má pozitivní vliv na vztah mezi obchodními partnery. Tyto odpovědi bývají zároveň velmi často i poţadavkem a cílem implementace (investice). Primárním cílem však bývá úspora nákladů a tak první fází před samotným zahájením implementace bývá studie, pomocí které se zpravidla ICT a obchodní oddělení společnosti snaţí prosadit schválení investice představenstvem. Studie zpravidla obsahuje tyto části: Formulace poţadavků a cílů. Charakteristika zamýšlené implementace – co umoţňuje, řeší, čemu napomáhá. Realizační tým (kdo rozhoduje, kontroluje, řídí a vykonává). Popis implementovaného nástroje. Popis aktuálního stavu – součástí také procesní analýza. Popis předpokládaného stavu po zavedení. 29

Pořizovací náklady. Harmonogram implementace. Ziskovost (vztah mezi výnosy a náklady za předpokládanou dobu uţívání), Rizikovost (například spojená s dodavatelem, selháním projektového řízení a jiné vlivy) a Stupeň likvidity (rychlost, s jakou lze vynaloţené prostředky převést zpět na Kč). Jiné provozní úspory – čas zaměstnanců, náklady např. na pohonné hmoty, poplatky řetězců při nezavedení EDI, spotřební materiál a jiné související sluţby. Vliv na ostatní firemní informační systémy. Doporučení představenstvu. Základní business poţadavky mohou být vzhledem k EDI tyto: Cena implementace a výše provozních nákladů do určité hranice. Sníţení mzdových nákladů o určitou výši (sníţení počtu zaměstnanců). Expanze do zahraničí – komunikace s partnery v EU i mimo ni, nebo mezinárodní tým obchodních zástupců. Sníţení reţijních nákladů obchodního a ICT oddělení v určité výši. Návratnost investice do určitého termínu. Zvýšení ITR (Inventory Turnover Ratio, obrátky zásob - kolikrát za rok dokáže společnost přeměnit své zásoby na tržby) o určitou hodnotu. Pokud představenstvo rozhodne kladně, následuje sestavení projektového týmu v čele s projektovým manaţerem a kontrolním orgánem. A zároveň jsou určeni klíčoví uţivatelé za jednotlivé útvary společnosti, kteří se budou významně podílet na splnění očekávaného výsledku.

3.1.2 Postup implementace v bodech 1. Zmapování výchozího stavu, analýza potřeb a zdrojů, sběr poţadavků. Tímto krokem implementace začíná, v rámci něho se s klíčovými uţivateli revidují stávající procesy, revidují se data v informačním systému a výsledkem těchto revizí je dokument, který detailně popisuje současný stav. Dále se v této fázi definují potřeby, poţadavky a cíle, kterých má být dosaţeno implementací. Business poţadavky jsou jiţ definované v prvotní studii předkládané představenstvu. V této fázi se ale definují poţadavky s klíčovými uţivateli na budoucí práci a obsluhu řešení, jde o tzv. sběr 30

poţadavků. Výsledkem je dokument, který detailně popisuje cílový stav. Nedílnou součástí této fáze je analýza zdrojů na základě popisu cílového stavu. Výsledkem je předpoklad, zda současné personální, technické a logistické zajištění bude odpovídat cílovému stavu. 2. Procesní modelování, analýza a simulace. Součástí implementace nového systému nebo systémové změny musí být vţdy zpracovaná procesní analýza, jejíţ součástí by měly být namodelované procesy spolu s jejich popisem, jeţ reflektuje současný stav. Implementace nového řešení má zásadní vliv na procesy ve firmě a představuje významnou procesní změnu. Tuto změnu je třeba v procesní analýze predikovat a kontinuálně diskutovat se všemi účastníky procesu. Pokud dojde k akceptaci této změny, je vhodné provést procesní simulaci, díky které lze získat informace o vlivu této procesní změny na různé sledované atributy. 3. Výběr vhodného řešení. V České republice na trhu působí tito VAN operátoři a poskytovatelé sluţeb EDI14: CCV, EDITEL CZ, T-Systems Czech Republic, Teledin, EDISS. Projektový manaţer sestavuje moţnosti řešení, jeţ jsou nabízena od jednotlivých dodavatelů. Součástí této aktivity je seznámení s dodavatelem a jeho referencemi, historií a zkušenostmi, stručný technický popis řešení, cena řešení včetně poţadavků na nákup nového hardwaru a softwaru. Projektový manaţer tak v rámci této fáze sestavuje nabídky jednotlivých dodavatelů, předkládá je managementu k posouzení a sám vysloví doporučení. Tuto fázi je moţné definovat jako výběrové řízení, během kterého bývají jednotlivá řešení prezentována přímo jednotlivými dodavateli na osobních schůzkách s projektovým manaţerem. 4. Podpis smlouvy s poskytovatelem řešení. Po výběru dodavatele následují jednání o smlouvě, poskytované podpoře a dalších podmínkách spolupráce. V této fázi zpravidla přichází na scénu firemní právníci, kteří následně ovlivňují smluvní podmínky spolupráce a dalších specifických oblastí. Zejména je třeba klást důraz na správnou archivaci faktur odpovídající národní legislativě. 5. Příprava „inhouse“ formátů pro vstup a výstup z podnikového informačního systému. Po podpisu smlouvy je třeba začít řešit přípravu procedur pro obsluhu exportu a importu do podnikového informačního systému. Je třeba připravit obsluţný mechanizmus, pomocí

14

(2) GS1 Czech Republic. Dodavatelé pro Systém. [Online] 2015.

31

kterého

budou

exportovány

odchozí

zprávy

a

importovány

příchozí

zprávy

do podnikového informačního systému. Tvorba takových mechanizmů uvnitř podniku můţe být realizována buď interními zdroji, pokud společnost má vlastní ICT oddělení, nebo je moţné zadat vývoj dodavateli. V roli dodavatele je třeba připravit proceduru pro import objednávek (zprávy ORDERS), proceduru pro export dodacích listů (zprávy DESADV), proceduru pro export faktur a opravných daňových dokladů (zprávy INVOIC) a aktuálně také proceduru pro export kmenových dat (zprávy PRICAT). V roli odběratele je naopak třeba připravit proceduru pro export objednávek, proceduru pro import dodacích listů a export příjemek (zprávy RECADV) a proceduru pro import faktur a opravných daňových dokladů. 6. Příprava hardwaru a softwaru (komunikátoru). Jediné, co musíme jako zákazník zajistit vzhledem k hardwaru při realizaci metody popsané v kapitole „2.1.3.3 Zpracování a výměna zpráv prostřednictvím VAN operátora a poskytovatele sluţeb EDI“ je počítač s trvalým připojením k internetu. Na tento počítač bude podnikový informační systém exportovat odchozí zprávy a z tohoto počítače bude podnikový informační systém importovat příchozí zprávy. Příjem a odesílání zpráv zajišťuje tzv. komunikátor, který stahuje zprávy ze schránky a odesílá zprávy do schránky společnosti u poskytovatele. Dnes jiţ bývá nejčastěji konvertor zpráv aţ na straně poskytovatele sluţeb EDI, tudíţ zprávy jsou vţdy konvertovány po příchodu do schránky u poskytovatele. Dříve bylo častější, ţe se na počítači u zákazníka nacházel komunikátor i konvertor. Komunikátor je software, který vyvíjí, spravuje a u zákazníků nasazuje poskytovatel a smluvní partner. 7. Zřízení identifikačního čísla společnosti (GLN a GTIN). Společně s předchozími kroky jde zřízení GLN (Global Location Number) pro společnost. Jedná se o unikátní identifikátor společnosti a k tomuto identifikátoru je následně přiřazena schránka u poskytovatele. Dále je třeba zřídit svým výrobkům tzv. GTIN (Global Trade Item Number). Stejně jako v případě GLN jde o unikátní identifikátor, nyní však výrobku. Známějším označením je EAN čárový kód výrobku, coţ ovšem není přesný termín. Bez zřízeného GLN a GTIN výrobků není moţné EDI komunikaci provozovat. 8. Validace a verifikace inhouse formátu. V této fázi je třeba nejprve validovat inhouse formát, tedy výstup z informačního systému. Dále je třeba ověřit, zda jsou data (zprávy) úplná, obsahují všechny povinné segmenty v předepsaném rozsahu. Dále je nutné ověřit správnost dat a výstup porovnat se 32

skutečností v podnikovém informačním systému. Je skutečně nutné mít jistotu, ţe je z podnikového informačního systému exportováno opravdu to, co v něm skutečně je a během exportu nedochází ke zkreslení či záměně informací. 9. Testování komunikace. V rámci tohoto kroku je kontinuálně ověřováno správné fungování komunikátoru a konvertoru. Komunikátor odchozí zprávu předá poskytovateli, ten se ji pokusí zkonvertovat. Pokud uspěje, předá ji do schránky příjemce, ve které dojde opět k ověření a předání do informačního systému. Toto ověření se provádí opakovaně a obousměrně aţ do vzájemné dohody, ţe obě strany mohou přejít do pilotního testovacího provozu „ostrých“ dokladů. 10. Pilotní testovací provoz a jeho vyhodnocení. V této fázi jsou jiţ formou EDI komunikovány „ostré“ doklady. Souběţně jsou však ke kontrole a ověření doklady zasílány faxem, emailem nebo poštou. Fáze trvá zpravidla jeden měsíc s kaţdým obchodním partnerem. Po uplynutí lhůty je fáze vyhodnocena a po vzájemné dohodě dochází k utlumení komunikace ostatních forem dokladů, podpisu smlouvy nebo dodatku o bezpapírové komunikaci a následně se komunikuje pouze formou EDI. 11. Ostrý provoz. Ostrým provozem končí implementace, kontrolní orgán vyhodnocuje průběh projektu a výsledky prezentuje managementu. Posléze je určena osoba zodpovědná za provoz a rozvoj EDI komunikace, je rozpuštěn projektový tým a projekt ukončen. Ostrý provoz a ukončení projektu nastává v momentě, kdy je se všemi moţnými obchodními partnery ukončen pilotní testovací provoz EDI komunikace a zahájena bezpapírová komunikace.

3.1.3 Integrace s podnikovým informačním systémem V procesu implementace je zcela klíčový podnikový informační systém a jeho moţnosti pro integraci EDI komunikace. Dnes jiţ existuje mnoho tzv. EDI ready informačních systémů, které lze chápat jako informační systémy připravené k implementaci EDI komunikace. Níţe uvádím jejich seznam15: ABRA Gx, ACONTO, AltusVario, Benefit 2000 Plus, BYZNYS Win, CAIS – Bakery, Cézar, ComSTAR, DataGo4, EKONOM, ESO 9, Globus IS, Helios Green, Helios Orange, Helios Red, IFS Aplikace, INFOS, iScala, IS ModulSoft, IS VENTUS, KelWin, Kostka, KOSYS, 15

(3) CCV, s.r.o.. EDI–ready informační systémy (ERP systémy). EDI Zone: informační portál. [Online] CCV, s.r.o., 2008-2015.

33

K2, MBS, Microsoft Dynamics NAV (Navision), Microsoft Dynamics AX (Axapta), Money S3, ORSOFT, OR-SYSTEM, Piti_Soft, Pohoda, Premier, QI, SAP, SB Komplet, Stereo, TAVIS, Timeline ERP, Trilex, Trisoft, Twist Inspire, VYRAEX, WINSTROM IS, XENON EIS, ZEIS. Kromě podnikového informačního systému je třeba věnovat pozornost i datům, které obsahuje.

Často

velkým

problémem

při

implementaci

bývá

nekonzistence,

nesystematičnost a neúplnost v datech informačního systému. Zpravidla to bývají data o výrobcích, zákaznících, ale mnohdy také v samotných dokladech. Z toho důvodu jsou v rámci implementace revidovány procesy a data v podnikovém informačním systému a mnohdy tato fáze představuje významnou část harmonogramu celého projektu. Na integraci existují různé pohledy a přístupy. Setkal jsem se s prvním přístupem, kdy je cílem přenést veškerou kontrolu a správu EDI komunikace na informační systém a centralizovat tak správu na jedno místo. A také jsem se setkal s druhým přístupem, kdy je informační systém vzhledem k EDI komunikaci vyuţíván výhradně k importu a exportu dokladů, kontrola a správa je ponechána ve schránce poskytovatele sluţeb EDI a zároveň operátora VAN. Pokud je zvaţován první přístup, tedy spravovat a kontrolovat vše v informačním systému a centralizovat do něj správu EDI, je třeba zajistit kromě běţných zpráv také přenos systémových zpráv i logů do informačního systému a také logů komunikátoru či konvertoru. Je třeba zajistit správné vazby mezi zprávami a definovat správně akce, které se vykonají při zpracování té či oné zprávy, zejména pak ve vztahu ke změně stavu dokladu. Je třeba také zajistit správnou prezentaci dat obsluze, nicméně v podstatě je tak duplikována hotová funkcionalita schránky do informačního systému. Samozřejmě je třeba ještě zajistit správu a rozvoj takového řešení. Druhým přístupem je cesta, kdy v informačním systému uţivatel pouze exportuje či importuje doklad a na úrovni schránky, coţ je webová aplikace poskytovatele, kontroluje jeho zpracování druhou stranou včetně veškerých logů a všech souvisejících systémových zpráv. Velice častý bývá názor, ţe je zdaleka vhodnější druhý způsob, zejména protoţe v informačním systému není moţné, vzhledem k EDI komunikaci, zajistit takový uţivatelský komfort, jako v aplikaci, která je k tomu primárně určena a vyvinuta. Lze jednoduše vyvodit, ţe i pokud panuje snaha ve společnosti prosadit první přístup, uţivatelé časem začnou inklinovat k druhému, a to zejména z toho důvodu, ţe ona webová aplikace EDI schránky je neustále vyvíjena, zdokonalována, aktualizována 34

a upravována vzhledem k měnící se legislativě. Naopak integrované řešení v rámci informačního systému je většinou implementováno a dále mu není věnována taková pozornost, jako v případě schránky EDI poskytovatele. Je proto důleţité rozhodnutí o míře vzájemné integrace.

35

3.2 SFA (Sales Force Automation) 3.2.1 Definice poţadavků a cílů Také v případě implementace SFA je třeba si zodpovědět otázku: Proč SFA implementovat? SFA poskytuje nástroje, jimiţ lze zvýšit výkonnost obchodního týmu. SFA poskytuje nástroje, jimiţ lze efektivněji řídit obchodní tým. SFA umoţňuje detailní monitoring trhu a poskytuje data pro analytické vyhodnocení. SFA optimalizuje firemní procesy a šetří provozní náklady. SFA je dnes jiţ cenově dostupné i pro menší nebo malé organizace. SFA zrychluje tok dokladů mezi obchodními partnery a má tak zřejmý vliv na logistiku, skladové hospodářství a cashflow. SFA sniţuje chybovost a minimalizuje vliv lidského faktoru. Také v tomto případě spuštění projektu předchází zpracování úvodní studie, která je podkladem pro rozhodování managementu. Obsah studie je popsán v kapitole 3.1.1.

3.2.2 Postup implementace v bodech 1. Zmapování stavu, analýza potřeb a zdrojů, sběr poţadavků. Shodně popsáno v kapitole 3.1.2 odstavec 1. 2. Procesní modelování, analýza a simulace. Shodně popsáno v kapitole 3.1.2 odstavec 2. 3. Výběr vhodného řešení. Shodně popsáno v kapitole 3.1.2 odstavec 3. 4. Sestavování a podpis smlouvy. V této fázi přichází na řadu zpravidla aplikování dohod vzniklých při schůzkách projektové manaţera se zástupcem dodavatele. Tyto dohody se týkají zejména licencování, respektive finální ceny frontendové a backendové licence. Backendová licence, respektive jejich nutný počet, je vázán na počet administrátorů s unikátním přístupem do administrátorské konzole. Počet nutných frontendových licencí je vázán na počet mobilních zařízení neboli počet obchodních zástupců. Další dohody se týkají sluţeb od dodavatele, tedy implementace, následné podpory a softwarové maintenance, neboli nároku na poslední vydanou verzi výrobcem. Tyto

36

důleţité smluvní dohody spolu se SLA (Service Level Agreement) bývají většinou přílohami, zejména protoţe bývají velmi často v ročním intervalu modifikovány. 5. Příprava hardwaru a softwaru. Za předpokladu, ţe má jiţ společnost databázový server pro zajištění svých informačních systémů, je vzhledem k hardwaru a softwaru nutné připravit pouze aplikační server, který by, podle doporučení výrobců, měl být dedikovaný pouze pro dané řešení. Aplikační server musí mít samozřejmě přímou konektivitu na databázový server a musí splňovat minimální hardwarové poţadavky dané výrobcem. Většina výrobců SFA řešení staví celou funkcionalitu na webových sluţbách Microsoft Windows IIS (Internet Information Services), coţ znamená, v doporučené variantě, serverovou licenci pro Windows Server 2008 Standard. Funkcionalita

backendu

bývá

následně

přístupná

jako

webová

aplikace

skrze zabezpečený protokol a internetový prohlíţeč odkudkoliv. Totéţ platí pro sluţbu synchronizace mobilních zařízení, která bývá zpravidla právě pomocí webového serveru IIS publikována zabezpečeným protokolem do internetu a můţe tak být dostupná mobilním zařízením připojených do veřejné sítě mobilního operátora. V souvislosti s hardwarem nelze opomenout významnou poloţku z celkového projektového budgetu, mobilní zařízení. Můţe jít o různé chytré telefony, tablety nebo dokonce notebooky. Doporučená je platforma Android, frontendová aplikace je nicméně dostupná také pro platformu Windows. 6. Příprava interface. Pro realizaci přenosů dat mezi podnikovými informačními systémy je nutný tzv. interface neboli aplikační rozhraní mezi řešením ERP a řešením SFA. V rámci tohoto rozhraní dochází k přenosům kmenových dat. Nejčastěji jde o: Produkty a jejich skladová zásoba. Zákazníci a jejich stav pohledávek. Marketingové a jiné akce na podporu prodeje. Zákaznický listing a ceny. Katalogová a odběratelská čísla produktů. Naopak ze SFA do ERP dochází k přenosu vystavených objednávek na mobilním zařízení u zákazníka.

37

Takový přenos můţe být realizován několika způsoby, buď přímým zápisem do databáze nebo pomocí protokolu SOAP (Simple Object Access Protocol), tedy výměnou XML zpráv dvou API (Application Programming Interface) a nakonec můţe být realizována pomocí výměny standardizovaných strukturovaných textových souborů definovaných standardem UN/EDIFACT, o kterém pojednává kapitola 2.1. 7. Centralizovaná správa mobilních zařízení. V rámci implementace je moţné, nikoliv nutné, realizovat centralizovaný management mobilních zařízení. Na trhu existuje několik variant, jak takovou potřebu řešit. Nejjednodušší a nejlevnější variantou je instalace některých z volně dostupných antivirových programů, které umoţňují po registraci zařízení lokalizovat, vzdáleně uzamknout nebo vymazat veškerý obsah. Kromě toho je moţné si zobrazit instalované aplikace, vyuţití systémových prostředků nebo například pořídit snímek obrazovky. Další moţností je pronájem samostatné sluţby pro tuto potřebu, jedna z moţných je například AirWatch. Tato sluţba, kromě jiţ uvedeného, umoţňuje blokovat uţivateli instalaci nepovoleného softwaru podle definovaných pravidel. Například pokud se na zařízení vyskytne software, který není v povoleném seznamu, uţivatel je vyzván k jeho odstranění. Pokud uţivatel na tuto výzvu nereaguje do určité doby, dojde k uzamčení zařízení nebo úplnému smazání. Pomocí takového softwaru je také moţné zařízení vzdáleně ovládat a nabízí spoustu různých funkcionalit, jeţ nejsou předmětem této práce. 8. Příprava analytických výstupů. Pro management podniku je klíčový výstup a informace, které jim řešení bude poskytovat. V rámci projektu je nutné se s členy vedení dohodnout na formě, struktuře a obsahu analýz, jeţ jim bude řešení pravidelně poskytovat. Moţné je vyuţít standardní výstupy definované výrobcem. Tato moţnost je vhodná zejména tam, kde se vedení spokojí s málem a není k dispozici vlastní tým odborníků, který dokáţe vytvářet datové sklady a nad nimi datovou analýzu podle definovaných poţadavků. Nebo je moţné vyuţít sluţeb externí firmy, která dokáţe takové analytické výstupy připravit. Ideální je však vyuţít interní IT, které bude průběţně podle připomínek výstupy optimalizovat a upravovat ke spokojenosti vedení. Výstup si lze zpravidla představit jako datovou krychli neboli tzv. OLAP (Online Analytical Processing) kostku.

38

9. Testování s klíčovými uţivateli. Významnou fází implementace je testovací provoz klíčových uţivatelů, ze kterého vzejdou uţivatelské poţadavky na softwarovou úpravu. Testovací provoz předpokládá samostatnou testovací instanci nebo dokonce samostatné testovací prostředí, v rámci kterého bude testovací provoz probíhat. Podle velikosti a struktury podniku je zde vhodné aplikovat základní změnový management, kde se veškeré uţivatelské poţadavky scházejí na jednom místě a vybraná komise pak rozhoduje o realizaci změn. Tato fáze projektu má spolu s fází sběru poţadavků významný vliv na jeho pozdější úspěšnost. Výstupem z této fáze je protokol, kde klíčový uţivatelé hodnotí testovací provoz a písemně souhlasí nebo nesouhlasí s přechodem do rutinního provozu. 10. Pilotní testovací provoz. V rámci této fáze probíhá příprava a předání mobilních zařízení celému obchodnímu týmu. Jiţ v ostrém prostředí probíhá úvodní oţivení řešení a detailní monitoring provozu. Všichni obchodní zástupci v této fázi jiţ vyuţívají nové řešení a jsou zodpovědní za hlášení veškerých neočekávaných událostí nebo chyb. Tato fáze bývá obvykle dvou aţ tříměsíční a jiţ by neměla produkovat nové poţadavky na změnu. Zpravidla bývá v této fázi soustředěna veškerá pozornost na optimalizaci provozu, konfiguraci, sledování vytíţení hardwaru, sledování rychlosti odezvy, dobu trvání synchronizace mobilních zařízení nebo odstraňování chyb, které nebylo moţné odhalit testovacím provozem. 11. Rutinní provoz. V této fázi dochází k akceptaci díla, projektový manaţer zpracovává písemnou zprávu o projektu pro management. Komunikace s dodavatelem přechází do reţimu servisní smlouvy a standardního hlášení chyb smluvně určeným způsobem. Uţivatelé jiţ nemají zásadní chybová hlášení, provoz je stabilní a poskytuje vše, co bylo předmětem studie.

3.2.3 Integrace s podnikovým informačním systémem Také v případě SFA je nutné se rozhodnout, do jaké míry a jakým způsobem integrovat obsluhu do ERP. Výhodou při takovém rozhodování bývá, kdyţ obě řešení pracují na stejném databázovém serveru. V takovém případě je moţné přímo zapisovat z jedné databáze do druhé, vytvářet si, do určité míry, vlastní aplikační logiku podloţenou potřebami vlastního 39

podniku. Někdy ovšem bývá nevhodné převádět obsluhu jednoho řešení do druhého a to zejména v situacích, kdy je vhodné vyuţít manuální práci člověka pro zkvalitnění cílového stavu. Jako osvědčenou zkušenost lze uvést, ţe bývá vhodné integrovat řešení pouze do oblasti přenosu informací nutných ke správnému zajištění chodu. Nikoliv ale duplikovat funkcionalitu jednoho řešení do druhého, například voláním funkcí nebo procedur jednoho řešení z druhého či přesunu části funkcionality jednoho řešení do druhého. Je zde správné chápat obě řešení jako autonomní celky, do jejichţ provozu není vhodné příliš zasahovat zápisovými operacemi tam, kde to situace skutečně nevyţaduje a kde pro to není opodstatnění, ať uţ vycházející z podstaty provozu nebo z klíčového poţadavku.

40

4 PŘÍNOSY A NÁKLADY REALIZOVANÝCH ŘEŠENÍ V této kapitole je zhodnocena implementace obou řešení po stránce ekonomické a vymezeny jsou zásadní ekonomické vlivy na provoz organizace. Jasně jsou vymezeny investiční i provozní náklady týkající se obou řešení a to s akcentem na stav před a po implementaci. Cena implementace můţe být u různých dodavatelů a různých moţností řešení rozdílná. V celé této kapitole je pouţit případ konkrétní společnosti s počtem 250 – 500 zaměstnanců, zabývající se výrobou, distribucí, prodejem kosmetiky a minerální vody.

4.1 EDI (Electronic Data Interchange) Tato kapitola je věnována ceně implementace EDI a následným provozním nákladům. Díky dosavadní praxi bylo dosaţeno vysoké míry poznání a to konkrétně u třech různých poskytovatelů a dodavatelů sluţeb EDI, kterými jsou Teledin, Editel a aktuálně CCV. Součástí této kapitoly a diplomové práce je poslední realizovaná implementace řešení CCV, jejíţ náklady popíši v následujících kapitolách. Tvorba obsluţných mechanizmů pro export a import do informačního systému byla realizována

při

prvotní

implementaci

řešení

EDI

od

společnosti

Teledin.

U těchto nákladů lze vyjít z předpokladu, ţe jsou v čase neměnné a liší se pouze vzhledem k typu informačního systému. V této práci je pouţita zkušenost s informačním systémem Helios Green běţícím ve třívrstvé architektuře nad databází MSSQL (Microsoft Structured Query Language). Obsluţné mechanizmy lze chápat v tomto případě jako sadu SQL procedur a funkcí, které jsou volány na MSSQL databázovém serveru prostřednictvím klienta aplikačního serveru v momentě, kdy jsou spuštěny uţivatelem. Tyto náklady do kalkulace budou zahrnuty.

4.1.1 Mzdové náklady na interní projektový tým V této části diplomové práce je čerpáno z kapitoly „3.1.2 Postup implementace v bodech“ a ke kaţdé etapě implementace jsou přiřazeny časové a finanční náklady interního projektového týmu vycházející z vlastních zkušeností. Kalkulováno je s předpokládanou průměrnou hrubou mzdou 50 000 Kč (super hrubá mzda je skutečný mzdový náklad 41

zaměstnavatele ve výši 67 000 Kč) jednotlivých členů projektového týmu zaměstnaných na plný úvazek definovaný jako 170 odpracovaných hodin za měsíc. Zjednodušeně proto lze vycházet z jednotného hodinového nákladu na jednoho zaměstnance ve výši 394 Kč. 1. Zmapování stavu, analýza potřeb a zdrojů. Jedná se o časově nejnáročnější fázi implementace, během které je nutná součinnost několika různých útvarů společnosti. Zpravidla jde o útvary ICT, obchodní, ekonomický a logistický. Časovou náročnost je nutné definovat pro kaţdý útvar zastoupený klíčovým zaměstnancem. Časová náročnost bude vyjádřena v jednotce MD (Men Day, jeden den práce jednoho člověka ve výši 8 hodin). ICT 10 MD 31 520,00 Kč

Obchodní 2 MD 6 304,00 Kč

Ekonomický 2 MD 6 304,00 Kč

Logistický 2 MD 6 304,00 Kč

Tabulka č. 4.1: EDI - struktura mzdových nákladů na analýzu (zdroj: autor)

Celkové náklady na projektový tým jsou 16 MD respektive 50 432 Kč. 2. Výběr vhodného řešení. ICT 5 MD 15 760,00 Kč Tabulka č. 4.2: EDI - struktura mzdových nákladů na výběr řešení (zdroj: autor)

3. Registrace a podpis smlouvy s poskytovatelem. ICT 3 MD 9 456,00 Kč

Právní kancelář 1 MD 16 000,00 Kč

Tabulka č. 4.3: EDI - struktura mzdových nákladů na smluvní zajištění (zdroj: autor)

Celkové náklady na registraci a podpis smlouvy jsou 4 MD respektive 25 456 Kč. 4. Příprava „inhouse“ formátů pro vstup a výstup z informačního systému. ICT 5 MD 15 760,00 Kč Tabulka č. 4.4: EDI - struktura mzdových nákladů na tvorbu inhouse (zdroj: autor)

42

5. Příprava hardwaru a softwaru (komunikátoru). ICT 0,25 MD 788,00 Kč Tabulka č. 4.5: EDI - struktura mzdových nákladů na přípravu HW a SW (zdroj: autor)

6. Zřízení identifikačního čísla společnosti (GLN a GTIN). ICT 0,5 MD 1576,00 Kč Tabulka č. 4.6: EDI - struktura mzdových nákladů na zřízení GLN (zdroj: autor)

7. Validace a verifikace inhouse formátu. ICT 1 MD 3152,00 Kč Tabulka č. 4.7: EDI - struktura mzdových nákladů na validaci inhouse (zdroj: autor)

8. Testování komunikace. ICT 2 MD 6304,00 Kč Tabulka č. 4.8: EDI - struktura mzdových nákladů na ověření komunikace (zdroj: autor)

9. Pilotní testovací provoz a jeho vyhodnocení. ICT 1 MD 3152,00 Kč Tabulka č. 4.9: EDI - struktura mzdových nákladů na testování (zdroj: autor)

10. Ostrý provoz. ICT 1 MD 3152,00 Kč

Kontrolní orgán 1 MD 3152,00 Kč

Tabulka č. 4.10: EDI - struktura mzdových nákladů na ostrý provoz (zdroj: autor)

Celkové náklady na spuštění ostrého provozu jsou 2 MD respektive 6 304 Kč. 43

Celkové náklady na interní projektový tým jsou 36,75 MD respektive 115 836 Kč.

4.1.2 Náklady na externí dodavatele V této kapitole jsou popsány a jasně vymezeny náklady, které jsou spojené se sluţbami dodavatelů v rámci realizace implementace řešení EDI. 4.1.2.1 Náklady na pořízení hardwaru a softwaru Pro běh komunikátoru je nutné vyhradit jeden počítač s trvalým připojením k internetu. Častější bývá platforma Windows, nicméně lze pouţít i jiné. Náklady na pořízení hardwaru odpovídají aktuální ceně běţné počítačové sestavy u firemního dodavatele. Součástí takové sestavy je zpravidla i OEM (Original Equipment Manufacturer) verze operačního systému Windows, na kterém bude provozován zmíněný komunikátor. Průměrná cena takové sestavy se pro firemní prostředí pohybuje okolo 20 000 Kč s LCD panelem a ostatními periferiemi. Před instalací komunikátoru je třeba zaregistrovat u GS1 GLN společnosti. Jednorázové náklady na registraci GLN jsou 5 000 Kč. Lze vyjít z předpokladu, ţe společnost má jiţ své výrobky opatřeny EAN čárovými kódy. Pokud nikoliv, činí náklady na registrace jednoho GTIN 400 Kč. Vynásobením této hodnoty počtem svých obchodovaných výrobků lze vyčíslit náklady na přidělení GTIN čárového kódu výrobkům.16 Jednorázové náklady na instalaci komunikátoru činí 10 000 Kč a pořízení schránky u poskytovatele činí 3 000 Kč.17 4.1.2.2 Náklady na tvorbu obsluţných mechanizmů v informačním systému Tyto náklady vznikají při implementaci prvotního řešení EDI. V případě změny poskytovatele jiţ nikoliv, protoţe formáty exportu i importu zůstávají stejné. V případě, kdy má společnost vlastní ICT oddělení, které dokáţe, podle specifikace formátů, obsluţné mechanizmy vytvořit interně, lze náklady definovat mzdou zaměstnance, který se věnoval tvorbě těchto mechanizmů. Pokud nikoliv, pracnost je průměrně 2 MD na jeden typ zprávy. Při implementaci běţně komunikovaných zpráv ORDERS, INVOIC, DESADV, PRICAT se pracnost vyšplhá na 8 MD vývoje a zpravidla také 2 MD analýzy. Celkem jde o 10 MD dodavatele, coţ při předpokládané průměrné hodinové sazbě dodavatele 1 500 Kč činí celkem 120 000 Kč.

16

(10) GS1 Czech Republic. OSO2015. [Online] 2015. Zdroj: neveřejná smlouva spolu s jejími dodatky.

17

44

1) Celkové mzdové náklady na interní projektový tým jsou

116 000 Kč.

2) Celkové náklady na externí dodavatele18 jsou

158 000 Kč.

Celkové náklady na implementaci EDI činí přibliţně 274 000 Kč.

4.1.3 Měsíční provozní náklady Měsíční provozní náklady se skládají v případě řešení EDI z: Fixní sloţky (krátkodobě) a) Poplatek GS1 za sluţby. b) Poplatek poskytovateli za podporu. c) Poplatek za sluţby poskytovatele internetu. d) Mzdové náklady na personál. Variabilní sloţky e) Poplatek poskytovateli za vyuţívání VAN sítě a schránky. a) Poplatek GS1 za sluţby. Provozní poplatek se platí ročně a odvíjí se od dosaţených trţeb za uplynulý rok. Kategorie A B C D E F G H I J K L M N O

Roční trţby v mil. Kč

Roční provozní poplatek v Kč

do 1 000 000 do 5 000 000 do 10 000 000 do 25 000 000 do 50 000 000 do 100 000 000 do 200 000 000 do 500 000 000 do 1 000 000 000 do 2 000 000 000 do 5 000 000 000 do 10 000 000 000 do 20 000 000 000 do 35 000 000 000 nad 35 000 000 000

1 000 2 000 3 000 4 000 5 000 9 000 13 000 15 000 20 000 30 000 40 000 60 000 90 000 120 000 150 000

Tabulka č. 4.11: EDI - kategorie nákladů na služby GS1 dle ročních tržeb19

V této diplomové práci je předpokládána společnost s roční trţbou spadající do kategorie H a ročním poplatkem 15 000 Kč (1 250 Kč za měsíc). 18

Součástí nákladů na externí dodavatele je také pořízení HW a SW, neboť je v tomto případě nákup řešen formou služby dodavatele. 19 (10)GS1 Czech Republic. OSO2015. [Online] 2015.)

45

b) Poplatek poskytovateli za hot-line a podporu. Poplatek za podporu se odvíjí od typu podpory, smluvně dohodnutých podmínek a SLA (Service Level Agreement). Pokud je moţné si vystačit se standardní podporou a neexistují speciální poţadavky na odezvu nebo non-stop dostupnost, částka je ve výši do 500 Kč.20 Jiným případem pak samozřejmě je, kdyţ je poţadována po poskytovateli kompletní správa schránky, myšleno včetně kontroly dokladů, komunikace s protistranou o jednotlivých obchodních případech, správa a distribuce podpisových certifikátů, veškeré zařizování kolem zapojení komunikace s novými obchodními partnery a jiné specifické poţadavky. Tato varianta podpory není v této diplomové práci kalkulována. Dalším specifickým případem podpory je situace, kdy je ve společnosti provozován nejen komunikátor, ale také konvertor. Jde o případ, kdy ke konverzi dochází uvnitř firmy. Pokud je komunikace a celý proces řešen tímto zastaralým způsobem, je nutné platit servisní podporu také na tento konvertor. Tato podpora zbytečně kaţdý rok navyšuje provozní náklady aţ o třetinu. Výše těchto nákladů se pohybuje od 3 000 do 4 000 Kč měsíčně.21 V této diplomové práci je předpokládán ideální případ, kdy se výše poplatku za podporu rovná 500 Kč měsíčně. c) Poplatek za připojení společnosti k internetu. Společnost má zpravidla smlouvu s některým z poskytovatelů datových sluţeb, na základě které měsíčně platí faktury za připojení k internetu nebo za připojení jednotlivých poboček, skladů, obchodních míst, kamerových systémů atp. mezi sebou. Vzhledem k tomu, ţe moţných způsobů připojení je nepřeberné mnoţství a kaţdý je specifický jak svými parametry, tak také cenou, předpokládána bude v této diplomové práci tato poloţka jako fixní ve výši 1 000 Kč měsíčně. d) Mzda personálu zajišťující provoz řešení. K provozu řešení je také nutné alespoň základní obsazení personálem. V této práci půjde o jednu osobu, která přijímá a odesílá doklady, dohlíţí na provoz řešení a kontroluje zpracování dokladů protistranou. Technické problémy tato osoba hlásí, buď přímo poskytovateli, nebo správci, který zajišťuje správu a vývoj obsluţných mechanizmů, komunikaci a řešení technických problémů s poskytovatelem. V této práci bude kalkulována průměrná hrubá mzda v ČR v roce 2014. Fixně je v rámci této práce definována hrubá měsíční mzda fakturantky, nákupčí nebo správce zaměstnaného 20 21

Zdroj: neveřejná smlouva spolu s jejími dodatky a interní přijaté faktury. Zdroj: neveřejná smlouva spolu s jejími dodatky a interní přijaté faktury.

46

na plný úvazek definovaný jako 170 hodin měsíčně, coţ odpovídá částce 24 806 Kč (super hrubá mzda je skutečným mzdovým nákladem zaměstnavatele a je rovna 33 240 Kč). Dále je předpokládáno, ţe oba zaměstnanci věnují řešení EDI jednu třetinu své měsíční pracovní doby. Vychází tak hodinový mzdový náklad ve výši přibliţně 196 Kč. Jedna třetina pracovní doby je přibliţně 57 hodin měsíčně, proto měsíční náklady na jednoho zaměstnance věnujícího se EDI jsou přibliţně 11 172 Kč. Celkové měsíční náklady na oba zaměstnance jsou 22 344 Kč měsíčně. e) Poplatek poskytovateli za vyuţívání VAN sítě a provoz schránky. Výše měsíčního poplatku se liší podle poskytovatele. Někteří výši odvíjí od počtu přenesených kilobajtů prostřednictvím VAN sítě, jiní naopak pracují podobně jako telefonní operátoři s tarify a měsíční poplatek je tak fixní. Níţe jsou uvedeny tabulky pro jednotlivé typy zpráv vycházející ze statistik komunikace společnosti. Z následujících tabulek je zřejmý počet přenesených zpráv, počet poloţek ve zprávě a průměrný počet poloţek ve zprávě. Objednávky Měsíc 1 2 3 4 5 6 7 8 9 10 11 12 Průměr Celkem

Počet Počet položek Průměrný počet položek 1 174 14 154 12,06 1 001 14 549 14,53 1 800 24 079 13,38 1 570 16 325 10,40 1 724 18 259 10,59 1 521 17 584 11,56 1 392 15 690 11,27 1 567 19 541 12,47 1 346 13 662 10,15 1 784 58 679 32,89 1 883 20 543 10,91 1 638 19 029 11,62 1 533 21 007 13,49 18 400

252 094

Tabulka č. 4.12: EDI - statistika komunikovaných objednávek (zdroj: autor)

47

Dodací listy Měsíc 1 2 3 4 5 6 7 8 9 10 11 12 Průměr Celkem

Počet

Počet položek Průměrný počet položek

1 105 987 1 772 1 530 1 642 1 492 1 373 1 531 1 335 1 711 1 848 1 506 1 486

12 065 12 782 20 884 14 126 16 298 15 814 14 533 17 184 11 014 50 360 16 936 15 549 18 128

17 832

217 545

10,92 12,95 11,79 9,23 9,93 10,60 10,58 11,22 8,25 29,43 9,16 10,32 12,03

Tabulka č. 4.13: EDI - statistika komunikovaných dodacích listů (zdroj: autor)

Faktury Měsíc 1 2 3 4 5 6 7 8 9 10 11 12 Průměr

Počet

Počet položek Průměrný počet položek

1 097 977 1 812 1 650 1 718 1 504 1 534 1 542 1 410 1 700 1 848 1 495 1 523

12 194 12 873 21 201 14 679 16 837 16 138 17 369 17 600 12 018 50 420 17 058 15 633 18 668

Celkem

18 287

224 020

11,12 13,18 11,70 8,90 9,80 10,73 11,32 11,41 8,52 29,66 9,23 10,46 12,17

Tabulka č. 4.14: EDI - statistika komunikovaných faktur (zdroj: autor)

Měsíční poplatek se z těchto hodnot pohybuje mezi 3 500 – 8 000 Kč.22 Spočtením průměru z těchto extrémů lze získat přibliţně hodnotu měsíčního poplatku ve výši 5 750 Kč. 22

Zdroj: neveřejná smlouva spolu s jejími dodatky a interní přijaté faktury.

48

Celkové měsíční provozní náklady tak z předchozích definic činí přibliţně 30 000 Kč.

4.1.4 Přínosy implementace V rámci této kapitoly je vymezen rozdíl v provozních nákladech v případě EDI komunikace a „papírové“ komunikace. Na následujících grafech je znázorněno, z jakých částí se skládá cena za jeden odeslaný doklad v obou formách.

Struktura ceny jednoho odeslaného papírového dokladu [27,1 Kč] 1.35 5%

0.81 3%

2.7 10% 15.39 57%

6.85 25%

Poštovné

Mzda zaměstnanců

Tisk

Obálka

Papír

Graf č. 4.1: EDI - struktura ceny jednoho odeslaného dokladu v papírové formě (zdroj: autor a neveřejná podniková kalkulace).

49

Struktura ceny jednoho odeslaného EDI dokladu [10,8 Kč] 0.498 4%

0.199 2%

0.398 4%

2.292 21%

7.447 69%

Mzda zaměstnanců

Komunikace po VAN síti

Služby GS1

Podpora

Internetové připojení

Graf č. 4.2: EDI - struktura ceny jednoho odeslaného el. dokladu (zdroj: autor a neveřejná podniková kalkulace).

V grafech 4.1 a 4.2 znázorňujících strukturu ceny bez a s implementovaným EDI je patrné, ţe se po implementaci EDI poměrově zvýšily mzdové náklady na jeden odeslaný doklad. Je to proto, ţe EDI vyţaduje, kromě fakturantky nebo nákupčí, také administrátora, který provádí údrţbu, řeší technické problémy a zajišťuje rozvoj obsluţných mechanizmů. Po implementaci je proto třeba určit zodpovědného pracovníka ICT, který bude část své pracovní doby věnovat správě a rozvoji EDI komunikace. Klesly sice mzdové náklady související s tiskem, „obálkováním“ a odesíláním dokladů, naopak se ale zvýšily mzdové náklady související s provozem řešení. Výsledkem je zvýšení mzdových nákladů přibliţně o 60 haléřů na jeden odeslaný doklad. Ze statistiky EDI komunikace vyplývá celkový počet odeslaných dokladů, který činí v tomto případě 36 119 kusů za rok. Ze srovnání stejného statistického vzorku za provozu EDI komunikace a bez ní vyplývají následující hodnoty:

50

a) S implementovaným EDI Celkové měsíční provozní náklady Fixní 22 344 + 2 750 = 25 094 Kč Variabilní 5 750 Kč Celkem 30 844 Kč

Celkové roční provozní náklady (22 344 x 12) + (2 750 x 12) = 301 128 Kč 5 750 x 12 = 69 000 Kč 370 128 Kč

Tabulka č. 4.15: EDI - kalkulace provozních nákladů po implementaci (zdroj: autor)

b) Bez implementovaného EDI Celkové měsíční provozní náklady Fixní 22 344 Kč 23 Variabilní 20,25 * 36 119 / 12 = 60 951 Kč Celkem 83 295 Kč

Celkové roční provozní náklady 22344 x 12 = 268 128 Kč 60 951 x 12 = 731 412 Kč 999 540 Kč

Tabulka č. 4.16: EDI - kalkulace provozních nákladů před implementací (zdroj: autor)

Celkové roční úspory při implementovaném EDI jsou přibliţně 630 000 Kč. S implementovaným EDI bylo dosaţeno ročních úspor přibliţně ve výši 63 % oproti papírové formě komunikace.

4.1.5 Návratnost investice do EDI Z ceny implementace 274 000 Kč, statistického vzorku komunikace a celkových měsíčních úspor, které činí přibliţně 52 500 Kč, vyplývá návratnost investice do 6 měsíců. Z tohoto příkladu lze odvodit, ţe se investice do EDI vrátí nejrychleji tam, kde společnost komunikuje ročně velké nebo větší mnoţství dokladů. Nemá velký smysl implementovat tam, kde se roční objem komunikovaných zpráv pohybuje řádově v jednotkách, desítkách či stovkách. Pokud jde o větší dodavatele či odběratele a je komunikováno velké mnoţství dokladů zejména s velkými řetězci, návratnost investice je téměř okamţitá. Dnes jiţ kaţdý větší řetězec tento způsob komunikace podporuje a spuštění komunikace je moţné realizovat řádově v týdnech, proto není třeba se obávat z dlouhodobého jednání s řetězci, zpravidla obě protistrany mají zájem komunikaci spustit co nejdříve.

23

Součet ceny poštovného, papíru, obálky a tisku vycházející z grafu 4.1

51

4.2 SFA (Sales Force Automation) Tato kapitola je věnována ceně implementace SFA a následným provozním nákladům. Výběrového řízení na řešení SFA se zúčastnily společnosti PointX s produktem Mobix, SmartData s produktem Mobilní OZ, Sunnysoft s produktem mAgent a vítězná Minerva Česká republika s produktem HamiltonSFA. Ihned po předloţení nabídky byla z výběrového řízení vyřazena společnost Sunnysoft kvůli několikanásobně vyšší ceně licencí i maintenance neţ u ostatních řešení. Jako další byla vyřazena společnost SmartData se svým produktem Mobilní OZ a to kvůli absenci některých funkcionalit a nepřehlednosti i sloţitosti rozhraní. Cenově vyšel nejlevněji produkt Mobix od společnosti PointX, ovšem zástupci společnosti nepůsobili důvěryhodně, reference nebyly dostatečné a uţivatelské prostředí celého řešení nebylo příjemné. Vítězem se tak stal i přes svou druhou nejvyšší cenu produkt HamiltonSFA, jeţ je ve své nejnovější verzi předmětem této diplomové práce. V následujících kapitolách popíši náklady spojené s realizací implementace vítězného řešení.

4.2.1 Mzdové náklady na interní projektový tým Tato část práce čerpá z kapitoly „3.2.2 Postup implementace v bodech“ a ke kaţdé etapě implementace jsou přiřazeny časové a finanční náklady interního projektového týmu vycházející z vlastní zkušenosti. Kalkulována je průměrná hrubá mzda 50 000 Kč (super hrubá mzda je skutečný mzdový náklad zaměstnavatele ve výši 67 000 Kč) jednotlivých členů projektového týmu zaměstnaných na plný úvazek definovaný jako 170 odpracovaných hodin za měsíc. Zjednodušeně je kalkulována jednotná hodinová sazba na jednoho zaměstnance ve výši 394 Kč. 1. Zmapování stavu, analýza potřeb a zdrojů. 2. Výběr vhodného řešení. 3. Sestavování a podpis smlouvy: První tři kroky implementace jsou shodné s implementací EDI. Participují zde opět útvary ICT, ekonomický, logistický a obchodní. Celkové náklady na tyto tři kroky jsou 25 MD respektive 78 800 Kč.

52

4. Příprava hardwaru a softwaru. ICT 2 MD 6 304,00 Kč Tabulka č. 4.17: SFA - struktura mzdových nákladů na přípravu HW a SW (zdroj: autor)

5. Příprava interface. ICT 5 MD 15 760,00 Kč Tabulka č. 4.18: SFA - struktura mzdových nákladů na tvorbu interface (zdroj: autor)

6. Centralizovaná správa mobilních zařízení. ICT 5 MD 15 760,00 Kč Tabulka č. 4.19: SFA - struktura mzdových nákladů na správu mob. zařízení (zdroj: autor)

7. Příprava analytických výstupů. ICT 10 MD 31 520,00 Kč Tabulka č. 4.20: SFA - struktura mzdových nákladů na analytický výstup (zdroj: autor)

8. Pilotní testovací provoz a jeho vyhodnocení. ICT 2 MD 6 304,00 Kč Tabulka č. 4.21: SFA - struktura mzdových nákladů na testování (zdroj: autor)

9. Ostrý provoz. ICT 2 MD 6 304,00 Kč

Kontrolní orgán 1 MD 3152,00 Kč

Tabulka č. 4.22: SFA - struktura mzdových nákladů ostrý provoz (zdroj: autor)

53

Celkové náklady na interní projektový tým jsou 52 MD respektive 163 904 Kč.

4.2.2 Náklady na externí dodavatele V této kapitole jsou popsány a jasně vymezeny náklady, které jsou spojené se sluţbami dodavatelů v rámci realizace implementace řešení SFA. 4.2.2.1 Náklady na pořízení hardwaru a softwaru V této diplomové práci je předpokládáno pořízení nového dedikovaného aplikačního serveru, určeného pro provoz SFA řešení. Přestoţe to není doporučováno výrobcem, lze vyuţít aplikační server, na kterém je jiţ provozováno jiné řešení a také lze provoz postavit na samostatném virtuálním serveru. Protoţe je databáze uloţena na jiţ existujícím centrálním SQL serveru, není třeba na novém aplikačním serveru nijak vysoká disková kapacita ani výkon. Plně postačí disk pro serverový operační Microsoft ve verzi 2008 Standard, pro server standardních 8 aţ 16 GB paměti RAM spolu s běţným serverovým procesorem Intel Xeon. Budu v této práci kalkulovat cenu včetně serverového operačního systému ve výši 120 000 Kč. S tím souvisí také nákup tzv. CAL (Client Access License) licencí pro přístup uţivatelů k serveru. Počet těchto licencí je roven počtu uţivatelů, kteří k serveru přistupují. V této diplomové práci je kalkulován 30 takových uţivatelů a cena 3 000 Kč za jednu CAL licenci. Znamená to, ţe náklady na CAL licence činí dohromady 90 000 Kč. Důleţitý je výběr koncových zařízení, kterými mohou být tablety, chytré telefony nebo méně časté notebooky. V této diplomové práci jsou kalkulovány tablety v počtu 30 ks a v ceně 8 000 Kč. Celková částka za koncová zařízení včetně příslušenství dosahuje výše 240 000 Kč. Další poloţkou jsou licence na implementovanou aplikaci, v našem případě HamiltonSFA. Licence se dělí na serverovou, administrátorskou a uţivatelskou část. Serverová licence přijde na 20 000 Kč, administrátorská při počtu dvou administrátorů přijde na 30 000 Kč a uţivatelská při počtu třiceti koncových uţivatelů na 570 000 Kč. Celkem jde o částku 620 000 Kč za licencování aplikace.

54

Dohromady jde o následující částku za pořízení hardwaru a softwaru: Aplikační server Serverové licence Koncová zařízení Licence na aplikační software

120 000 Kč 90 000 Kč 240 000 Kč 620 000 Kč

Tabulka č. 4.23: SFA - struktura nákladů na pořízení HW a SW (zdroj: autor)

Celkové náklady na pořízení hardwaru a softwaru tak činí 1 070 000 Kč. 4.2.2.2 Náklady na externí projektový tým a tvorbu interface Součástí projektového týmu jsou také zástupci dodavatele, jejichţ práci je třeba kalkulovat do nákladů na implementaci. Jejich činnost spočívá v tvorbě implementační studie, následují sluţby spojené s instalací, konfigurací, testováním, školením a programováním. Níţe jsou uvedeny kalkulace těchto poloţek. Analýza a tvorba studie 40 000 Kč Instalace, konfigurace, převod dat, interface 70 000 Kč Školení 40 000 Kč Programové úpravy 150 000 Kč Tabulka č. 4.24: SFA - struktura nákladů na externí projektový tým (zdroj: autor)

Celkové náklady na externí projektový tým činí 300 000 Kč. 1) Celkové mzdové náklady na interní projektový tým jsou 24

2) Celkové náklady na externí dodavatele jsou

163 904 Kč. 1 370 000 Kč.

Celkové náklady na implementaci SFA činí přibliţně 1 550 000 Kč.

4.2.3 Měsíční provozní náklady Měsíční provozní náklady se skládají v případě řešení SFA z: Fixní sloţky (krátkodobě) a) Poplatek poskytovateli za podporu. b) Poplatek za sluţby poskytovatele internetu. c) Mzdové náklady na personál.

24

Součástí nákladů na externí dodavatele je také pořízení HW a SW, neboť je v tomto případě nákup řešen formou služby dodavatele.

55

a) Poplatek poskytovateli za podporu. Spolu s licencemi na aplikační software je v ceně zahrnuta i maintenance, tzv. nárok na nejnovější verzi a s tím spojenou podporu od výrobce. Ten je ale z pozice koncového zákazníka mnohdy sloţité uplatňovat, a proto je vhodné si u dodavatele platit servisní podporu, se kterou souvisí dohoda o SLA (Service Level Agreement). SLA je dohoda o úrovni poskytovaných sluţeb, jinými slovy jde o ujednání, ve kterém jsou stanoveny podmínky hlášení problému, reakční doby, garantovaný čas vyřešení a to zpravidla podle kategorie hlášeného problému. Od těchto ustanovení se následně odvíjí cena takové sluţby. V této práci je kalkulován poplatek za podporu ve výši 6 500 Kč měsíčně. b) Poplatek za připojení společnosti k internetu. Shodně s kapitolou 4.1.3 odstavec c. c) Mzda personálu zajišťující provoz řešení. K provozu řešení je také nutné alespoň základní obsazení personálem. Za to je v rámci této diplomové práce povaţována jedna osoba v roli administrátora, která dohlíţí na provoz řešení, je zodpovědná za data, spravuje jednotlivé číselníky a moduly řešení, zabývá se netechnickými problémy s evidencí jednotlivých oblastí. Technické problémy hlásí přímo dodavateli nebo internímu technickému pracovníkovi, který je zodpovědný za rozvoj, provoz a dostupnost řešení a také komunikaci s dodavatelem. V této diplomové práci je kalkulována průměrná hrubá mzda v ČR v roce 2014. Je tak fixně definována hrubá měsíční mzda administrátora a technického pracovníka zaměstnaného na plný úvazek definovaný jako 170 hodin měsíčně na 24 806 Kč (super hrubá mzda je skutečný mzdový náklad zaměstnavatele ve výši 33 240 Kč). Dále je v této diplomové práci předpokládáno, ţe jeden zaměstnanec věnuje řešení SFA celou pracovní dobu a druhý třetinu své měsíční pracovní doby. Vychází tak hodinový mzdový náklad ve výši přibliţně 196 Kč. Jedna třetina pracovní doby je přibliţně 57 hodin měsíčně, měsíční náklady na administrátora jsou proto přibliţně 33 240 Kč a měsíční náklady na práci technického pracovníka jsou přibliţně 11 172 Kč. Celkové měsíční náklady na oba zaměstnance jsou 44 412 Kč měsíčně. Celkové měsíční provozní náklady tak z předchozích definic činí přibliţně 52 000 Kč.

4.2.4 Přínosy implementace Přínosy implementace SFA nejsou, stejně jako v případě EDI, vţdy přímo měřitelné. V této kapitole jsou objasněny zřejmé přínosy, které společnost získá po implementaci 56

SFA. Přínosy SFA jsou nesmírně důleţité pro celkový výkon a efektivitu obchodního týmu i celé organizace. a) Zrychlení toku objednávek do firmy. Řešení SFA zajišťuje okamţitý přenos pořízené objednávky na koncovém zařízení do firemního ERP. Odpadá zdlouhavé telefonování, faxování a mailování obchodního zástupce

se

zákaznickým

servisem.

Obchodní

zástupce

má

tak

více

času

na práci se zákazníkem a dokáţe během jednoho dne navštívit o 1,5 aţ 225 zákazníky více neţ bez pouţití řešení SFA. Kromě toho má zrychlení přenosu objednávek pozitivní vliv na logistiku a cashflow společnosti. V této práci je kalkulován průměrný počet objednávek realizovaných prostřednictvím SFA na 1300 ks26 za měsíc a průměrná výše objednávky jako 2 000 Kč s průměrnou hrubou marţí ve výši 40 %. Pro správné chápání těchto hodnot je třeba si uvědomit, ţe se jedná o objednávky menších kosmetických salónů a drogerií na nezávislém trhu. Objednávky velkých řetězců na koncentrovaném trhu jsou realizovány prostřednictvím EDI, jeţ je také předmětem této diplomové práce. Z uvedených hodnot vyplývá, ţe se zásluhou implementace SFA podařilo navýšit průměrný počet objednávek na 2 000 za měsíc. Coţ při průměrně výši objednávky na úrovni 2 000 Kč znamená rozdíl v obratu ve výši 1,4 mil. Kč. Při 40% marţi jde o téměř 600 000 Kč hrubého zisku za měsíc při zachování stejného počtu obchodních zástupců. b) Automatizované zpracování objednávek. Po pořízení objednávky na koncovém zařízení dochází k šifrovanému přenosu objednávky po datové síti mobilního operátora na aplikační server SFA řešení. Po přijetí objednávky dochází podle definovaných pravidel k automatizovanému zpracování a přenosu do ERP. Celý proces je realizován bez jakéhokoliv vstupu uţivatele, zákaznický servis tak nemusí ručně přepisovat data z papírů nebo jiných zdrojů. Díky tomu je moţné sníţit počet pracovníků zákaznického servisu nebo případně alokovat jejich aktivitu pro jinou činnost. Z hodnot uvedených v předchozím odstavci lze získat hodnotu 100 nových objednávek za jeden den. Při osmihodinové pracovní době jde přibliţně o 13 objednávek za hodinu, coţ lze pohodlně zvládnout při jednom pracovníkovi alokovaném plně pro tuto činnost za předpokladu automatizovaného importu do ERP. Při telefonickém, faxovém a emailovém zpracování byli nutní tři pracovníci zákaznického servisu, coţ představuje po implementaci řešení SFA úsporu na mzdových nákladech ve výši 66 500 Kč za měsíc. 25 26

Zdroj: nezveřejnitelné podnikové analýzy a statistiky. Zdroj: nezveřejnitelné podnikové analýzy a statistiky.

57

c) Sníţení chybovosti a omezení vlivu lidského faktoru. Chybovost při telefonování, faxování nebo mailování objednávek zákaznickému servisu byla před implementací SFA řešení natolik vysoká, ţe způsobovala významné náklady na vyřizování reklamací. SFA řešení tuto chybovost omezilo na minimum, díky čemuţ došlo ke sníţení počtu zaměstnanců na reklamacích ze dvou na jednoho. Sníţení počtu reklamací má současně pozitivní vliv na vztahy se zákazníkem. Původně

jeden

alokovaný

zaměstnanec

pro

vyřizování

reklamací

vztaţených

k objednávkám od obchodních zástupců mohl být zrušen a zůstal jeden zaměstnanec, který vyřizuje reklamace vyplývající z prodeje zboţí obecně v rámci celé organizace. Měsíční úspora na mzdových nákladech činí 33 240 Kč za měsíc. d) Online informace z trhu. Díky řešení SFA proudí neustále do firmy z trhu velké mnoţství informací, na které je management schopen velmi rychle reagovat a volit taková rozhodnutí, která povedou ke strategickým cílům organizace. Obchodní tým je neustále pod kontrolou a řešení SFA umoţňuje jeho efektivní a centralizované řízení. Bez řešení SFA byla tato moţnost značně komplikovaná a zdlouhavá. SFA řešení má tak velmi rychlý a zřejmý vliv na výkonnost kaţdého jednotlivce, jeţ je součástí týmu. e) Analytické nástroje pro vyhodnocování výkonnosti týmu a dat o konkurenci. Analytické nástroje nad daty řešení SFA umoţňují vyhodnocovat trend na trhu a díky tomu cílit své produktové portfolio na správný segment trhu. Řešení SFA má tak význam nejen pro obchodní tým, ale také marketing a vývoj. Analytické nástroje umoţňují reportovat rozličné informace od konkurenčních výrobků, přes výkonnost jednotlivých obchodních zástupců v čase, aţ po srovnání různých klíčových atributů v letech. Řešení SFA a jeho analytické nástroje se tak okamţitě stávají klíčovými pro provoz a řízení celého obchodu. f) Informace v jednotné strukturované formě. Řešení SFA umoţňuje dát přenášeným informacím jednotnou a strukturovanou formu. Jako příklad lze uvést například přenos fotografií. Bez řešení SFA je přenos realizován zpravidla emailem spolu s popisem fotografie. Kaţdý obchodní zástupce pak kreativně většinou volí různou formu předávání této informace. Prostřednictvím řešení SFA je centrálně definovaný formulář, v rámci kterého je na koncovém zařízení automaticky vyvolán fotoaparát a po vyfocení je fotografie uloţena do databáze a spolu s ní i popis. Taková informace je následně přenesena na aplikační server, uloţena do centrální

58

databáze a zpřístupněna všem trvale na jednom místě. Toto vede k centralizaci všech informací na jedno místo a je zásadně sníţena pravděpodobnost ztráty dat. g) Zrychlený přenos informací a pokynů obchodním zástupcům. Řešení SFA nabízí široké moţnosti v řízení celého týmu a umoţňuje distribuovat okamţité pokyny a změny v obchodním procesu bez nutnosti svolávaní porad nebo telefonování. Obchodní zástupce je nucen s řešením vykonat určitý úkol nebo změnu, bez které není umoţněno opustit zákazníka nebo uzavřít pracovní den. Obchodní zástupce má neustálý přístup k informacím, jeţ jsou nutné pro úspěšnou obchodní aktivitu bez nutnosti přenášet velké mnoţství různých papírů a dalších zdrojů. Typickým příkladem jsou stavy skladů, akční ceny výrobků, neuhrazené pohledávky atp.

4.2.5 Shrnutí a návratnost investice Cena implementace řešení SFA byla v kapitole 4.2.2 spočtena na 1 550 000 Kč. Měsíční úspory po implementaci řešení SFA byly v kapitole 4.2.4 spočteny celkově přibliţně na 700 000 Kč. Při měsíčních provozních nákladech 52 000 Kč, spočtených v kapitole 4.2.3, je návratnost investice přibliţně 2 - 3 měsíce od chvíle, kdy dojde k úplnému oţivení řešení a přijetí celým obchodním týmem, coţ je přibliţně 6 - 12 měsíců od implementace a spuštění rutinního provozu. Z uvedeného příkladu vyplývá, ţe se investice vrátí tím rychleji, čím je více obchodních zástupců a čím je větší počet objednávek. Řešení SFA totiţ akceleruje výkonnost obchodních zástupců, s tím i mnoţství objednávek, obrat a zisk obchodního týmu. Řešení SFA je vhodné implementovat tam, kde se potýkáte s významným konkurenčním bojem a potřebujete nepřetrţitě informace z řetězců. Řešení SFA totiţ přináší strukturované vstupy i výstupy, které umoţňují analytický pohled na vývoj daného odvětví na trhu.

59

5 DOPORUČENÍ PRO IMPLEMENTACI A PROVOZ V této kapitole jsou rozvedeny dosavadní zkušenosti s implementacemi a správou řešení EDI a SFA. Je zde zaměřeno na problémy, s kterými je moţné se v praxi setkat a kterých je vhodné se vyvarovat.

5.1 Specifikace business požadavků Business poţadavky jsou nejvyšší cíle definované vedením společnosti. Častým problémem před samotnou implementací bývá, ţe tyto poţadavky, zejména v případě EDI, nejsou specifikovány a jediným business poţadavkem je tak splnit poţadavek řetězce nebo jiného obchodního partnera, který EDI v obchodním styku vyţaduje. Pro projektové řízení jsou tyto poţadavky důleţité zejména vzhledem k výběru správného dodavatele a volby správného řešení. Pokud tyto poţadavky nejsou známy předem, zpravidla je dodavatel vybírán pouze podle ceny případně referencí, coţ není v pořádku. Častou chybou tak bývá pouze zadání od vedení na ICT oddělení v podobě: „Potřebujeme nasadit EDI nebo SFA“ bez bliţšího seznámení s problematikou, moţnostmi řešení, vlivy na související procesy či informační systém. ICT pak realizuje projekt bez kontinuální spolupráce s vedením a výsledkem pak je buď nasazené řešení, které nepokrývá poţadavky vedení vzešlé aţ po implementaci nebo definice těchto a návazných poţadavků v průběhu realizace projektu, coţ má většinou znamená celkový „restart“ implementace. Projektový manaţer by se měl nejprve důkladně seznámit s problematikou a následně svolat schůzku za účasti vedení a společně tyto business poţadavky sestavit a definovat. Často se projektový manaţer s problematikou sice seznámí, ale dále pracuje bez jasně určených business poţadavků a tím tak bere na sebe dobrovolně odpovědnost za případný neúspěch.

5.2 Zpracování implementační studie Často bývá, v případě implementací obou řešení, podceňována implementační studie, v rámci které jsou popsány zejména vazby na informační systém, podrobně specifikovány jednotlivé úpravy, dodatečné vývoje a jiné konfigurace, na které nesmí být zapomenuto. Je zde specifikován harmonogram prací spolu s termíny a klíčovými milníky projektu. Tato studie 60

celý projekt dělí do fází a přiřazuje odpovědnost za jejich realizaci v rámci projektového týmu. Studie je sestavována a vychází z business poţadavků definovaných vedením. Absence implementační studie nebo definovaných business poţadavků zásadně zvyšuje riziko neúspěchu a lze tak doporučit oba tyto kroky nepodceňovat a sestavovat je ve spolupráci se všemi klíčovými útvary společnosti i vedením.

5.3 Vliv řešení na procesy a informační systém Řešení EDI i SFA má zásadní vliv na firemní procesy, je proto nutná spolupráce i s koncovými uţivateli a je nutné konzultovat s nimi předpokládanou procesní změnu, která přímo ovlivní jejich budoucí práci. Je tak moţné předejít tomu, ţe si nespokojený uţivatel bude stěţovat na změny, o kterých nebyl informován, které s ním nebyly konzultovány a které mu případně znesnadňují práci. Této fázi se běţně říká procesní analýza a simulace, se kterou přímo souvisí sběr poţadavků (blíţe je popsáno v kapitolách 3.1.2 a 3.2.2). Poţadavky mohou být funkční či nefunkční. Funkční jsou charakteristické tím, ţe jistým způsobem ovlivňují průběh a výsledek akce, kterou uţivatel vyvolá. Naopak nefunkční poţadavky průběh ani výsledek uţivatelské akce neovlivňují, ale ovlivňují vlastnost prvku, který uţivatel k vyvolání akce bude pouţívat. Komunikace s koncovými uţivateli bývá také velmi často podceňována a důsledkem jsou pak vysoké náklady na realizaci tzv. změnových poţadavků. Základem kvalitního a bezproblémového provozu SFA a EDI jsou zejména: Konsolidovaná a kompletní data. Správně nastavená integritní omezení v informačním systému vzhledem k povinně pořizovaným datům o výrobcích, zákaznících a dokladech. Kvalitní, kontinuální komunikace a spolupráce logistiky, obchodního a ICT oddělení. Správně vybrané řešení, jeho dodavatel i hardware. Důsledně definovaná smlouva a sankce vyplývající pro dodavatele z porušení jejích podmínek. Kvalitní a průběţně rozšiřované výstupy a manaţerské analýzy z dat daného řešení. Kvalita personálu a kontinuální rozvoj řešení.

61

5.4 Archivace faktur a změna operátora Častým problémem při změně EDI operátora bývá otázka: „Co provést s fakturami komunikovanými prostřednictvím starého operátora?“. Vzhledem k podmínce archivovat faktury po dobu nejméně deseti let je třeba toto důsledně promyslet. Obecně je vhodné trvat u nového poskytovatele na importu komunikace od původního operátora do nového řešení. Většinou to bývá problém a předmět sporu při sestavování smlouvy, nicméně pokud je problém postaven do roviny podmínky podpisu, většinou bývá prosazen. Bohuţel, takto importovaná historie není ukotvena v čase elektronickým časovým razítkem, které v době importu jiţ není moţné pouţit, a proto takto importované doklady nesplňují podmínky archivace a slouţí tak uţivateli jen k náhledu. Je proto nutné současně s tímto krokem provést plnou zálohu původního řešení a zároveň poţadovat po původním operátorovi zálohu dat staré schránky. Je moţné pro jistotu ještě uchovat spustitelný obraz stroje, na kterém bylo provozováno původní řešení například tak, aby šlo spustit v některém z virtuálních prostředí. Při změně operátora je vţdy nutné alespoň dva měsíce s předstihem informovat své komunikační partnery o této změně. Změna vyţaduje totiţ zpravidla i změnu konfigurace na jejich straně. Obecně lze doporučit zvýšenou pozornost této problematice, neboť povinnost vychází z většiny běţných smluv o EDI komunikaci a při nedodrţení můţe partner ţádat smluvní pokutu.

5.5 Zapojování nových partnerů Tuto problematiku je třeba rozdělit na dvě kategorie: 1. Zapojení velkého řetězce s roky ověřenou a fungující komunikací. 2. Zapojení menšího nebo zahraničního partnera. V prvním případě bývá zapojení zpravidla bez velkých problémů. Komunikaci mají roky ověřovanou a spravovanou širokou skupinou administrátorů. Mají tisíce různých dodavatelů a většinou i s nějakým specifikem není problém komunikaci nastartovat. Větší problém bývá přesvědčit nebo dohodnout jakoukoliv změnu v komunikovaných datech. Velmi často je malá nebo skoro ţádná vůle vyjít vstříc dodavateli a proto tyto řetězce většinou určují podmínky komunikace, kterým se dodavatel musí přizpůsobit. Naopak v druhém případě je zapojení a spuštění komunikace problematické. Menší nebo malý partner zpravidla mívá EDI nově implementované a nemá dostatečné zkušenosti se 62

správou, provozem a rozvojem a velmi často také nemá své ICT oddělení, které by se o EDI staralo. Je tak často nutné v roli dodavatele realizovat úpravy specifické pro konkrétního zákazníka tak, aby komunikace mohla být spuštěna. U zahraničních partnerů je kromě jejich velikosti důleţité také jiné národní prostředí, ať uţ se to týká měny, měrných jednotek, jazyků, znakových sad, zkrátka jiných národních sub setů. V těchto případech je většinou i pro zkušeného správce nutná spolupráce také na straně operátora či dodavatele. Pro efektivní zapojování nových partnerů je klíčová variabilita obsluţných mechanizmů pro import a zejména export dokladů z informačního systému. Pokud správce není schopen tyto mechanizmy upravovat dle aktuálních potřeb a vše má řešené externím dodavatelem, správa a rozvoj se prodraţí a bude neefektivní. Je proto velice vhodné zejména z počátku, kdy bude nutné zapojit desítky různých partnerů, zajistit zaměstnance, který dokáţe tyto mechanizmy upravovat interně.

5.6 Správa řešení V roli správce je třeba se zaměřit zejména na ovládání jazyka SQL, proniknout do světa SFA a EDI a porozumět všem souvislostem, nastavit si vztahy s jednotlivými interními i externími účastníky procesu a důsledně dbát na dodrţování pravidel, které většinou definuje samostatně správce jako osoba zodpovědná. Je na místě důsledně logovat veškerou činnost uţivatele a zabránit tím zbytečným diskusím o původu vzniklé chyby. Je důleţité věnovat zvýšenou pozornost notifikacím na určité akce uţivatele či řešení samotného. Lze tak podchytit problém v jeho zárodku. Je velice vhodné si s kaţdým účastníkem procesu naplánovat schůzku a osobně vysvětlit význam jednotlivých kroků, které provádí, zdůraznit jejich význam a informovat ho osobně o problémech, které můţe způsobit v případě chyby. Častou chybou správce bývá, ţe nechá řešení ţít vlastním „ţivotem“ a nemá nastavenou kontinuální a pravidelnou kontrolu. Souvislost práce správce s prací ostatních účastníků procesu je však vysoká. Pokud správce podcení správu a kontrolu řešení, stejným způsobem podcení také svou práci a kontrolu řešení ostatní, protoţe se tak necítí být kontrolováni a necítí tak potřebu sami něco kontrolovat. Lepší je a to zejména z počátku, důsledně kontrolovat veškerý provoz a v případě jakékoliv nejasnosti či nesrovnalosti ihned toto komunikovat s osobou, která má danou věc na starost. Pokud totiţ uţivatel uţ z počátku bude cítit, ţe se o řešení někdo stará, někdo ho pravidelně kontroluje a několikrát za sebou to osobně pozná, bude stejně fungovat sám a správci postupně začne odpadat velké mnoţství práce a starostí. 63

6 ADONIS – NÁSTROJ PRO MODELOVÁNÍ PROCESŮ 6.1 Význam a smysl modelování procesů Modelování procesů má významný vliv na úspěch celé implementace. Díky namodelovaným procesům lze získat přehled o procesní změně, která vyplyne z implementace nového řešení. Technika modelování procesů nám umoţňuje graficky znázornit strukturu firemních procesů a detailně popsat jednotlivé dílčí aktivity všech účastníků procesu. Účastník procesu, v podobě uţivatele, tak získá přehled především o tom, jak se ho implementace nového řešení bude týkat a dostane prostor se k procesní změně vyjádřit a přímo ji ovlivnit. Nástroje pro modelování procesů současně nabízejí dílčí funkcionalitu, jeţ umoţňuje provést procesní simulace či analýzy a detailně tak kalkulovat vliv procesní změny na klíčové sledované atributy procesu, kterými jsou typicky čas a náklady. Zdrojem informací pro následující kapitoly je uţivatelský manuál nástroje pro řízení podnikových procesů ADONIS 4.0.27, který byl pouţit při zpracování této diplomové práce.

6.2 Základní charakteristiky Dodavatelem modelovacího nástroje ADONIS je společnost BOC Information Technologies Consulting AG, která byla zaloţena v roce 1995 jako pobočka skupiny BPMS na Univerzitě ve Vídni. Tento nástroj patří do balíku softwaru BOC Management Office (ADOscore, ADONIS, ADOlog, ADOit). V současnosti má společnost BOC kolem 200 zaměstnanců. ADONIS je nástroj na procesní řízení, určený pro návrh, zjišťování, analýzu, simulaci, optimalizaci a dokumentaci podnikových procesů, zdrojů a organizační struktury podniku. Flexibilní metamodel umoţňuje jak definici podnikově specifických modelovacích metod, tak i pouţití standardních metod. ADONIS má intuitivní, jednoduché pouţívání při zároveň rozsáhlých funkcionalitách a decentralizovaný přístup spolu s centrální databází umoţňují tvorbu a údrţbu celopodnikového systému řízení procesů a kvality. Analýzy a simulace umoţňují zjišťování procesních nákladů a časů. K dispozici je také ABC analýza, plánování

27

(1) BOC AG. ADONIS 4.0 – Uživatelský manuál. Wien : BOC AG, 2012.

64

personálu a kapacit nebo zjišťování kritických míst. Součástí instalace je také flexibilní komponenta dokumentace pro automatické generování HTML, Word, PDF a dalších. ADONIS je komplexní nástroj pro řízení podnikových procesů, zejména pro vytváření modelů podnikových procesů, produktů, organizační struktury, dokumentů, rizik, kontrol a IT řešení. Vedle grafického a tabulkového modelování nabízí ADONIS celou řadu vyhodnocovacích funkcionalit, jako je například zjišťování kapacitních potřeb, procesních nákladů, průběhových časů jednotlivých procesů atp. Zároveň nabízí rozsáhlé moţnosti při podpoře vytváření a vývoji procesně orientovaných aplikací ve společnosti, na základě specifikací IT a v návaznosti na podnikové procesy. Z jednotlivých modelů mohou být plně automaticky generovány výstupy, ať jiţ ve formátu HTML, nebo i jako dokumenty v textovém formátu. Tím je zároveň umoţněno publikovat a distribuovat obsah modelů včetně grafického znázornění prostřednictvím intranetu. Nástroj ADONIS je moţné vyuţívat zejména v následujících oblastech: Optimalizace podnikových procesů: kontinuální zlepšování procesů (simulace procesů, porovnávání reálného a cílového stavu, benchmarking). Organizační řízení: organizační struktury, popisy pracovních míst. Controlling: analýza procesních nákladů, obchodních aktivit, řízení ukazatelů výkonnosti. Řízení kvality: ISO 9000:2000 - budování a implementace systému. Personální management: řízení kapacit, plánování zdrojů, call-center management. Rozhraní k workflow a webovým systémům. ADONIS má tři základní části: Toolkit BPM (řízení procesů): slouţí k modelování a práci s modely. Toolkit administrace: slouţí ke správě nástroje, obsahuje aplikační knihovnu. Správa databáze: slouţí k vytváření a správě databáze. ADONIS Toolkit pro řízení procesů obsahuje funkcionality a modelovací metodu, které je moţné vyuţít pro zjišťování, modelování, analýzu, simulaci, evaluaci a dokumentaci podnikových procesů. Jednotlivé komponenty nástroje ADONIS se nacházejí přesně v tomto pořadí, takţe uţivatel má zároveň i přiměřenou metodickou pomoc pro svoji činnost. Vzájemné propojení jednotlivých modelů umoţňuje vytvořit komplexní procesní model, jako 65

základ pro jeho další vyhodnocování, optimalizaci a představuje účinný nástroj pro efektivní řízení podniku. Modelovací nástroj ADONIS obsahuje následující typy modelů: Procesní mapa: přehledné znázornění procesních modelů. Business proces model: detailní znázornění průběhu procesů. Model produktů: znázornění souvislostí mezi produkty a procesy. Model pracovního prostředí: znázornění organizační struktury. Model dokumentů: znázornění dokumentů a informací pouţívaných v procesech. Model IT řešení: znázornění IT řešení navázaných na jednotlivé procesy. Aplikační diagram: znázornění interakcí mezi uţivatelem a IT řešením. Datový model: znázornění souhrnu dat. Katalog kontrol: znázornění kontrol, které jsou zaměřeny na ovládnutí rizik. Katalog rizik: znázornění rizik, která mohou negativně ovlivnit dosaţení cílů. Model zdrojů: znázornění modelu technických a know-how zdrojů. Modelovací nástroj ADONIS je ve své obsluze velice intuitivní. Právě u modelovacích nástrojů je toto pojímáno jako rozhodující faktor úspěchu. Koncept přizpůsobení umoţňuje aplikování téměř jakékoliv metody v modelovacím nástroji ADONIS a je moţné nástroj lehce přizpůsobit na změněné nebo nové oblasti pouţití, či upravit podle specifických poţadavků. Díky rozsáhlému konceptu oprávnění v modelovacím nástroji ADONIS je zabezpečeno, ţe například určitý okruh osob pracuje na přiřazeném konceptu modelů, s jednoznačně stanovenou konfigurací. Tím je zabezpečeno, ţe modely jsou jednotné a vzájemně srozumitelné.

6.3 Komponenty Modelovací nástroj ADONIS je nabízen ve dvou variantách, Professional Edition a Business Edition. Ve verzi „Business Edition“ jsou obsaţeny komponenty modelování, analýza, import a export a dokumentace. Uţivatelé edice Business jsou především pracovníci, kteří vytvářejí popis současného stavu procesů ve vazbě na organizační strukturu a dokumentaci, provádějí analýzy skutečného stavu, resp. vytvářejí procesní dokumentaci. Ve verzi „Professional Edition“ jsou kromě komponent obsaţených v Business Edition navíc komponenty zjišťování, simulace a evaluace. Uţivatelé edice Professional jsou především ti

66

pracovníci, kteří provádějí na základě analýzy a popisu současného stavu další hlubší analýzy a vyhodnocování skutečného stavu s cílem optimalizace procesního řízení. Zjišťování Komponenta „Zjišťování“ napomáhá při pořizování dat, která jsou důleţitá pro modelování procesů a pracovního prostředí. Komponentou pro zjišťování dat je nástroj HOMER, zaloţený na tabulkovém editoru Microsoft Excel. V HOMER – tabulkách je moţné ukládat potřebná data a tyto potom pomocí souboru ADL exportovat do nástroje pro řízení procesů ADONIS. Modelování Modelovací komponenta je jádrem celého nástroje pro řízení procesů ADONIS. Tato komponenta umoţňuje navrhovat, vytvářet a upravovat modely pomocí grafického editoru ve formě procesních modelů popřípadě jako strukturálně orientované modely. Navíc existuje také moţnost tabulkového modelování, které je velice výhodné zejména při zadávání hodnot atributů v rámci modelu. Analýza V rámci komponenty „Analýza“ je moţné provádět dotazy (vytvořené v AQL (ADONIS Query Language)) na modely ADONIS a vytvářet vztahové tabulky nebo předdefinované zprávy a grafy. Modelovací nástroj ADONIS nabízí standardizované dotazy, které jsou formulovány pomocí „doplňovacích textů“. Kromě toho je moţné vytvářet i uţivatelsky definované dotazy, které jsou uţivatelem modelovacího nástroje ADONIS tvořeny formou propojování standardizovaných dotazů. Výsledky dotazu mohou být zobrazeny buď jako tabulka nebo graficky. Výsledky mohou být exportovány do souboru. Tímto způsobem můţete zpracovávat výsledky dále v jiných aplikacích. Výpočetní analýza umoţňuje analytické hodnocení modelů podnikových procesů. Simulace Pomocí komponenty „Simulace“ se provádí simulace podnikových procesů a pracovního prostředí. K dispozici jsou čtyři simulační algoritmy, s jejichţ pomocí je moţné provádět analýzu cest podnikových procesů, jakoţ i kapacitní analýzu a analýzu vytíţení, pro které se spojují modely podnikových procesů a modely pracovního prostředí. Stejně jako v případě analýz je i zde moţné znázornění výsledků tabulkově nebo graficky, případně i s moţností animace. S pomocí ADONIS agentů je moţné zjišťovat i nestandardní výsledky během simulace. 67

Evaluace Komponenta „Evaluace“ nabízí mechanismy pro hodnocení tzv. ToBe modelů a reálně probíhajících procesů. Rovněţ je zde moţné provádět hodnocení indikátorů výkonnosti a výsledky zobrazovat jak tabulkově, tak i graficky. Evaluační komponenta nabízí porovnávání výsledků, hodnoceni v reálném čase i s pomocí předdefinovaných evaluačních dotazů. Import a export „Import a Export“ komponenta poskytuje moţnost exportu modelů ADONIS, modelových skupin a aplikačních modelů do ADL či XML souborů, stejně jako import těchto souborů do databáze ADONIS. ADL je zkratka pro ADONIS Definition Language. Pomocí této komponenty můţete přenášet modely, modelové skupiny a aplikace modelů do jiné databáze ADONIS. Kromě toho mohou exportované ADL nebo XML soubory slouţit jako záloha dat modelů ADONIS. Dokumentace Sloţka „Dokumentace“ je součástí komponenty „Import a Export“ a nabízí moţnost převádět modely ADONIS do elektronické modelové dokumentace (např. HTML, XML) nebo do papírové dokumentace (např. DOC, PDF). Tímto způsobem je moţné distribuovat obsah modelů buď ve formátu dokumentu nebo prostřednictvím intranetu v rámci podniku.

6.4 Licence Modelovací nástroj ADONIS je moţné instalovat v různých architekturách: Stand-alone instalace. Client / Server instalace. Instalace na Citrix-Server. ADONIS Stand-alone licence jsou poskytovány jako tzv. „named use“ licence. Instalace je provedena na jednom přístroji, v administrativní sloţce je však moţné zaloţit i více uţivatelů, kteří ale nemohou pracovat s nástrojem současně. Součástí licence je i databázový systém MSSQL. Pro práci více uţivatelů je moţné vytvořit potřebný počet databází a z nich pak exportovat modely do centrální databáze.

68

ADONIS Client / Server licence jsou poskytovány jako „named use“ (licence pro přesně definovaný počet uţivatelů), nebo „concurrent use“, tj. souběţně uţívané licence (software můţe být nainstalován na libovolný počet počítačů, resp. v administrativní sloţce lze zaloţit libovolný počet uţivatelů, který je ale zároveň ohraničen počtem zakoupených licencí). Databázový systém, instalovaný na server, není součástí licence, ale vzhledem k univerzálnosti je moţné vyuţít i stávající databázový systém společnosti. Modelovací nástroj ADONIS vyuţívá běţné standardní databáze jako je DB2, Oracle, MSSQL Server a další.

6.5 Přednosti Modelovací nástroj ADONIS obsahuje řadu funkcí, které jdou daleko za rámec kapacity čistého modelovací nástroje. Jednoduchá a intuitivní obsluha: ADONIS se vyznačuje jasnou a přehlednou stavbou i srozumitelností. Tím je také vhodný zvláště pro ta oddělení a pracovníky, kteří nedisponují hlubokými znalostmi oblasti IT. Jednotná modelovací metoda: ADONIS můţe být konfigurován přímo pro cíle projektu a odpovídajícím zvyklostem zavedené anotace, konečnému uţivateli jsou pak dostupné pouze ty modelovací objekty nebo informace, které jsou relevantní stanovenému cíli. Propojení externích dokumentů a médií na jednotlivé procesní kroky: ADONIS umoţňuje propojení externích dokumentů či médií jako např. textové nebo tabulkové soubory, obrázky, či videoklipy přímo v samotném nástroji, ale i ve vytvořených HTML publikacích. Rozsáhlé

vyhodnocovací

moţnosti:

ADONIS

obsahuje

významné,

model

vyhodnocující komponenty, jako je například komponenta analýzy a komponenta simulace. Tyto komponenty vytvářejí základnu pro další funkcionality k plánování kapacit nebo optimalizaci procesního řízení. Automatické přezkoušení konzistence během modelování: Existují různé mechanismy pro automatické přezkoušení konzistence. V komponentě analýzy je moţné například provádět dotazy na kontrolu konzistentnosti modelů. Správa a rozsáhlý koncept oprávnění: ADONIS obsahuje systém oprávnění k přístupu do databáze a obsahu uloţených modelů. Je moţné rovněţ nastavit 69

individuální práva jednotlivým uţivatelům a zároveň umoţnit i většímu počtu uţivatelů řádnou a strukturovanou práci na stejném modelu v jedné centrální databázi. Verzování a schvalování: Kaţdému modelu můţe být přiřazeno odpovídající číslo verze a následně provádět jejich porovnávání a hodnocení. Schvalování a uvolňování v modelovacím nástroji ADONIS můţe být řešeno přímo automaticky v samotném nástroji s vyuţitím strukturované správy procesů. Podpora databází: Modelovací nástroj ADONIS podporuje různé standardní databáze (DB2, Oracle, MSSQL). Tím je zvýšena efektivita při instalaci a administraci. Můţe tak být pouţito stávající podnikové databázové know-how. Cena: Při porovnání cena – výkon - uţitek zaujímá modelovací nástroj ADONIS přední místo mezi všemi ostatními obdobnými nástroji.

70

7 DIAGRAMY PROCESŮ A SIMULACE V této kapitole je popsán model procesu zpracování objednávky s akcentem na rozdíly před a po implementaci řešení EDI a SFA. V návaznosti na procesní diagramy je provedena simulace procesů, jsou vyhodnoceny výsledky simulace a vyvozeny patřičné závěry.

7.1 EDI (Electronic Data Interchange) 7.1.1 Modelování procesu zpracování objednávky od odběratele 7.1.1.1 Funkční model procesu zpracování objednávky od odběratele V této kapitole je graficky znázorněn funkční model procesu zpracování objednávky od odběratele.

Obrázek č. 7.1: EDI - funkční model účastníků procesu zpracování objednávky (zdroj: autor)

71

7.1.1.2 Popis funkčního modelu a účastníků procesu V této kapitole jsou popsáni jednotliví účastníci procesu zpracování objednávky od odběratele a definovány jsou jejich role a odpovědnost vzhledem k procesnímu výstupu. Odběratel Nákupčí: Vystavuje objednávku a zasílá ji dodavateli (poštou, mailem, faxem, EDI). Dodavatel Pracovník zákaznického servisu (PZS): Zpracovává objednávku, vystavuje fakturu. Recepční: Zprostředkovává sluţby pošty. Systémový administrátor: Spravuje řešení, řeší technické potíţe. Systém: Provádí automatizovanou činnost dle nastavené konfigurace. Skladník: Odesílá objednané zboţí. Vedoucí skladu: Systémově vychystává zboţí ze skladu a vystavuje dodací listy. 7.1.1.3 Popis diagramu procesu před implementací EDI V následujícím diagramu procesu je zachyceno zpracování objednávky na straně dodavatele bez implementovaného EDI. V následujícím textu je současně popsán v bodech celý procesní model. Odběratel (nákupčí): Vystaví a odešle objednávku. 28

Dodavatel (recepční): Přijme objednávku na poště a předá ji PZS.

29

Dodavatel (PZS): Přijme objednávku.

Dodavatel (PZS): Ručně přepíše objednávku do IS. Dodavatel (vedoucí skladu): Vystaví k přijaté objednávce v IS dodací list. Dodavatel (skladník): Připraví zboţí k odeslání a vytiskne dodací list. Dodavatel (PZS): Vystaví v IS fakturu. Dodavatel (skladník): Odešle zboţí odběrateli. 30

Dodavatel (PZS): Vytiskne fakturu a předá recepční.

31

Dodavatel (PZS): Odešle fakturu.

32

Dodavatel (recepční): Odešle fakturu na poště odběrateli.

28

Pokud je objednávka odeslána poštou. Pokud je objednávka odeslána emailem nebo faxem. 30 Pokud je faktura odeslána poštou. 31 Pokud je faktura odeslána emailem nebo faxem. 32 Pokud je objednávka odeslána poštou. 29

72

Odběratel (nákupčí): přijme zboţí a fakturu.

Obrázek č. 7.2: EDI - procesní diagram zpracování objednávky před implementací (zdroj: autor)

Proměnné na obrázku č. 7.2: PostouOBJ? (hodnoty YES nebo NO): Je objednávka odeslána poštou? Kompletni? (hodnoty YES nebo NO): Je objednávka kompletní? PostouFV? (hodnoty YES nebo NO): Je faktura odeslána poštou?

73

7.1.1.4 Popis diagramu procesu po implementaci EDI V následujícím diagramu procesu je zachyceno zpracování objednávky na straně dodavatele s implementovaným EDI. V následujícím textu je současně popsán v bodech celý procesní model. Odběratel (nákupčí): Vystaví a odešle objednávku EDI. Dodavatel (systém, PZS): Automaticky přijme objednávku a neimportuje do IS. Dodavatel (PZS): Zkontroluje v IS objednávku a potvrdí v IS odběrateli přijetí. Dodavatel (vedoucí skladu): Vystaví k přijaté objednávce v IS dodací list. Dodavatel (skladník): Připraví zboţí k odeslání a odešle EDI dodací list. Dodavatel (PZS): Vystaví v IS fakturu. Dodavatel (skladník): Odešle zboţí odběrateli. Dodavatel (PZS): Odešle v IS fakturu EDI. Odběratel (nákupčí): Přijme zboţí a fakturu.

74

Obrázek č. 7.3: EDI - procesní diagram zpracování objednávky po implementaci (zdroj: autor)

Proměnné na obrázku č. 7.3: Kompletni? (hodnoty YES nebo NO): Je objednávka kompletní?

75

7.1.2 Simulace procesu zpracování objednávky od odběratele Path Execution time

Costs

Path Description

1

00:000:02:00:00 248,5

EDI Before 1 (Business process diagram (BPMN 2.0)) Start Event: Tvorba objednavky Task: Odeslani objednavky Exclusive Gateway: Zpusob odeslani --> PostouOBJ? = 'Yes' Task: Vyzvednuti objednavky na poste Task: Prijeti objednavky Exclusive Gateway: Overeni dat a dostupnosti zbozi --> Kompletni? = 'No' Task: Komunikace s odberatelem Task: Rucni prepsani objednavky do IS Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Tisk dodaciho listu Task: Vystaveni faktury Task: Odeslani zbozi odberateli Exclusive Gateway: Faktura postou --> PostouFV? = 'Yes' Task: Tisk faktury a predani recepcni Task: Odeslani faktury na poste End Event: Prijeti zbozi

2

00:000:01:55:00 238,5

EDI Before 1 (Business process diagram (BPMN 2.0)) Start Event: Tvorba objednavky Task: Odeslani objednavky Exclusive Gateway: Zpusob odeslani --> PostouOBJ? = 'Yes' Task: Vyzvednuti objednavky na poste Task: Prijeti objednavky Exclusive Gateway: Overeni dat a dostupnosti zbozi --> Kompletni?= 'Yes' Task: Rucni prepsani objednavky do IS Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Tisk dodaciho listu Task: Vystaveni faktury Task: Odeslani zbozi odberateli Exclusive Gateway: Faktura postou --> PostouFV? = 'Yes' Task: Tisk faktury a predani recepcni Task: Odeslani faktury na poste End Event: Prijeti zbozi

3

00:000:01:30:00 198,5

EDI Before 1 (Business process diagram (BPMN 2.0)) Start Event: Tvorba objednavky Task: Odeslani objednavky Exclusive Gateway: Zpusob odeslani --> PostouOBJ? = 'No' Task: Prijeti objednavky Exclusive Gateway: Overeni dat a dostupnosti zbozi --> Kompletni? = 'No' Task: Komunikace s odberatelem Task: Rucni prepsani objednavky do IS

76

Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Tisk dodaciho listu Task: Vystaveni faktury Task: Odeslani zbozi odberateli Exclusive Gateway: Faktura postou --> PostouFV? = 'Yes' Task: Tisk faktury a predani recepcni Task: Odeslani faktury na poste End Event: Prijeti zbozi 4

00:000:01:29:00 189,5

EDI Before 1 (Business process diagram (BPMN 2.0)) Start Event: Tvorba objednavky Task: Odeslani objednavky Exclusive Gateway: Zpusob odeslani --> PostouOBJ? = 'Yes' Task: Vyzvednuti objednavky na poste Task: Prijeti objednavky Exclusive Gateway: Overeni dat a dostupnosti zbozi --> Kompletni? = 'No' Task: Komunikace s odberatelem Task: Rucni prepsani objednavky do IS Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Tisk dodaciho listu Task: Vystaveni faktury Task: Odeslani zbozi odberateli Exclusive Gateway: Faktura postou --> PostouFV? = 'No' Task: Odeslani faktury faxem nebo emailem End Event: Prijeti zbozi

5

00:000:01:25:00 188,5

EDI Before 1 (Business process diagram (BPMN 2.0)) Start Event: Tvorba objednavky Task: Odeslani objednavky Exclusive Gateway: Zpusob odeslani --> PostouOBJ? = 'No' Task: Prijeti objednavky Exclusive Gateway: Overeni dat a dostupnosti zbozi --> Kompletni?= 'Yes' Task: Rucni prepsani objednavky do IS Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Tisk dodaciho listu Task: Vystaveni faktury Task: Odeslani zbozi odberateli Exclusive Gateway: Faktura postou --> PostouFV? = 'Yes' Task: Tisk faktury a predani recepcni Task: Odeslani faktury na poste End Event: Prijeti zbozi

6

00:000:01:24:00 179,5

EDI Before 1 (Business process diagram (BPMN 2.0)) Start Event: Tvorba objednavky Task: Odeslani objednavky Exclusive Gateway: Zpusob odeslani --> PostouOBJ? = 'Yes'

77

Task: Vyzvednuti objednavky na poste Task: Prijeti objednavky Exclusive Gateway: Overeni dat a dostupnosti zbozi --> Kompletni?= 'Yes' Task: Rucni prepsani objednavky do IS Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Tisk dodaciho listu Task: Vystaveni faktury Task: Odeslani zbozi odberateli Exclusive Gateway: Faktura postou --> PostouFV? = 'No' Task: Odeslani faktury faxem nebo emailem End Event: Prijeti zbozi 7

00:000:00:59:00 139,5

EDI Before 1 (Business process diagram (BPMN 2.0)) Start Event: Tvorba objednavky Task: Odeslani objednavky Exclusive Gateway: Zpusob odeslani --> PostouOBJ? = 'No' Task: Prijeti objednavky Exclusive Gateway: Overeni dat a dostupnosti zbozi --> Kompletni? = 'No' Task: Komunikace s odberatelem Task: Rucni prepsani objednavky do IS Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Tisk dodaciho listu Task: Vystaveni faktury Task: Odeslani zbozi odberateli Exclusive Gateway: Faktura postou --> PostouFV? = 'No' Task: Odeslani faktury faxem nebo emailem End Event: Prijeti zbozi

8

00:000:00:54:00 129,5

EDI Before 1 (Business process diagram (BPMN 2.0)) Start Event: Tvorba objednavky Task: Odeslani objednavky Exclusive Gateway: Zpusob odeslani --> PostouOBJ? = 'No' Task: Prijeti objednavky Exclusive Gateway: Overeni dat a dostupnosti zbozi --> Kompletni?= 'Yes' Task: Rucni prepsani objednavky do IS Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Tisk dodaciho listu Task: Vystaveni faktury Task: Odeslani zbozi odberateli Exclusive Gateway: Faktura postou --> PostouFV? = 'No' Task: Odeslani faktury faxem nebo emailem End Event: Prijeti zbozi

Tabulka č. 7.1: EDI - výstup ze simulace procesu před implementací (zdroj: autor)

78

Path Execution time

Costs

Path Description

1

00:000:00:42:00

102,0

EDI After 1 (Business process diagram (BPMN 2.0)) Start Event: Tvorba objednavky Task: Odeslani objednavky EDI Task: Prijeti objednavky EDI a automaticky import do IS Exclusive Gateway: Overeni dat a dostupnosti zbozi --> Kompletni?='No' Task: Komunikace s odberatelem Task: Potvrzeni objednavky Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Odeslani dodaciho listu EDI Task: Vystaveni faktury Task: Odeslani zbozi odberateli Task: Odeslani faktury EDI End Event: Prijeti zbozi

2

00:000:00:37:00

92,0

EDI After 1 (Business process diagram (BPMN 2.0)) Start Event: Tvorba objednavky Task: Odeslani objednavky EDI Task: Prijeti objednavky EDI a automaticky import do IS Exclusive Gateway: Overeni dat a dostupnosti zbozi-->Kompletni?='Yes' Task: Potvrzeni objednavky Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Odeslani dodaciho listu EDI Task: Vystaveni faktury Task: Odeslani zbozi odberateli Task: Odeslani faktury EDI End Event: Prijeti zbozi

Tabulka č. 7.2: EDI - výstup ze simulace procesu po implementaci (zdroj: autor)

79

7.1.3 Výsledky simulace procesu zpracování objednávky od odběratele Pro porovnání obou simulací procesu zpracování objednávky před a po implementaci řešení EDI je pouţita jednoduchá metoda, ve které je vypočtena průměrná hodnota ukazatele „doba trvání“ a „náklad“ za obě simulace a všechny průchody, tyto hodnoty jsou pak vzájemně porovnány a vyvozeny relevantní závěry. Průchod 1 2 3 4 5 6 7 8 Průměr

Doba trvání [min] 120 115 90 89 85 84 59 54 87

Náklady[Kč] 248,5 238,5 198,5 189,5 188,5 179,5 139,5 129,5 189

Tabulka č. 7.3: EDI - hodnoty klíčových ukazatelů před implementací (zdroj: autor)

Průchod 1 2 Průměr

Doba trvání [min] 42 37 40

Náklady[Kč] 102 92 97

Tabulka č. 7.4: EDI - hodnoty klíčových ukazatelů po implementaci (zdroj: autor)

Z uvedených hodnot vyplývá, ţe po implementaci EDI došlo ke sníţení doby trvání procesu zpracování objednávky o 55 % a sníţení nákladů na proces o 49 %.

80

7.2 SFA (Sales Force Automation) 7.2.1 Modelování procesu zpracování objednávky od obchodního zástupce 7.2.1.1 Funkční model procesu zpracování objednávky od obchodního zástupce V této kapitole je graficky znázorněn funkční model procesu zpracování objednávky od obchodního zástupce.

Obrázek č. 7.4: SFA - funkční model účastníků procesu (zdroj: autor)

81

7.2.1.2 Popis funkčního modelu a účastníků procesu V této kapitole jsou popsáni jednotliví účastníci procesu zpracování objednávky od obchodního zástupce a definovány jsou jejich role a odpovědnost vzhledem k procesnímu výstupu. Odběratel Nákupčí: Jedná s obchodním zástupcem dodavatele a objednává jeho prostřednictvím. Dodavatel Obchodní zástupce (OZ): Jedná se zákazníkem a motivuje ho k objednání, vystavuje objednávku. Pracovník zákaznického servisu (PZS): Zpracovává a přepisuje objednávku, vystavuje fakturu, spolupracuje s obchodním zástupcem. Recepční: Zprostředkovává sluţby pošty. Systémový administrátor: Spravuje řešení, řeší technické potíţe. Systém: Provádí automatizovanou činnost dle nastavené konfigurace. Skladník: Odesílá objednané zboţí, tiskne dodací list. Vedoucí skladu: Systémově vychystává zboţí ze skladu a vystavuje dodací listy. 7.2.1.3 Popis diagramu procesu před implementací SFA V následujícím diagramu procesu je zachyceno zpracování objednávky na straně dodavatele bez implementovaného SFA. V následujícím textu je současně popsán v bodech celý procesní model. Dodavatel (OZ): Navštíví nákupčí odběratele a jedná s ní o objednávce. Odběratel (nákupčí): Jedná s obchodním zástupcem dodavatele o objednávce. 33

Dodavatel (OZ): Zaznamená objednávku nákupčí na papírový formulář.

34

Dodavatel (OZ): Ukončí návštěvu.

35

Dodavatel (OZ): Pošle faxem objednávkový formulář na PZS.

Dodavatel (PZS): Přijme formulář a ověří ho. 36

Dodavatel (PZS): Komunikuje s OZ.

33

Pokud nákupčí odběratele objedná. Pokud nákupčí odběratele neobjedná. 35 Pokud nákupčí odběratele neobjedná. 36 Pokud není objednávkový formulář kompletní. 34

82

37

Dodavatel (PZS): Ručně přepíše objednávku do IS.

Dodavatel (vedoucí skladu): Vystaví k přijaté objednávce v IS dodací list. Dodavatel (skladník): Připraví zboţí k odeslání a vytiskne dodací list. Dodavatel (PZS): Vystaví v IS fakturu. Dodavatel (skladník): Odešle zboţí odběrateli. 38


39

Dodavatel (PZS): odešle fakturu.

40

Dodavatel (recepční): odešle fakturu na poště odběrateli.

Odběratel (nákupčí): přijme zboţí a fakturu.

37

Pokud je objednávkový formulář kompletní nebo pokud proběhla komunikace s OZ. Pokud je faktura odeslána poštou. 39 Pokud je faktura odeslána emailem nebo faxem. 40 Pokud je objednávka odeslána poštou. 38

83

Obrázek č. 7.5: SFA - procesní diagram zpracování objednávky před implementací (zdroj: autor)

Proměnné na obrázku č. 7.5: Kompletni? (hodnoty YES nebo NO): Je objednávka kompletní? PostouFV? (hodnoty YES nebo NO): Je faktura odeslána poštou? 84

7.2.1.4 Popis diagramu procesu po implementaci SFA V následujícím diagramu procesu je zachyceno zpracování objednávky na straně dodavatele s implementovaným SFA. V následujícím textu popíší v bodech celý procesní model. Dodavatel (OZ): Navštíví nákupčí odběratele a jedná s ní o objednávce. Odběratel (nákupčí): Jedná s obchodním zástupcem dodavatele o objednávce. 41

Dodavatel (OZ): Ukončí návštěvu.

42

Dodavatel (OZ): Zaznamená objednávku nákupčí na mobilní zařízení.

Dodavatel (OZ): Synchronizace mobilního zařízení. Dodavatel (systém, PZS): Automaticky přijme a naimportuje objednávku. 43

Dodavatel (PZS): Komunikuje s OZ.

44

Dodavatel (PZS): Potvrdí objednávku v IS.

Dodavatel (vedoucí skladu): Vystaví k přijaté objednávce v IS dodací list. Dodavatel (skladník): Připraví zboţí k odeslání a vytiskne dodací list. Dodavatel (PZS): Vystaví v IS fakturu. Dodavatel (skladník): Odešle zboţí odběrateli. 45


46

Dodavatel (PZS): Odešle fakturu.

47

Dodavatel (recepční): Odešle fakturu na poště odběrateli.

Odběratel (nákupčí): Přijme zboţí a fakturu.

41

Pokud nákupčí odběratele neobjedná. Pokud nákupčí odběratele objedná. 43 Pokud není objednávkový formulář kompletní. 44 Pokud je objednávkový formulář kompletní nebo pokud proběhla komunikace s OZ. 45 Pokud je faktura odeslána poštou. 46 Pokud je faktura odeslána emailem nebo faxem. 47 Pokud je objednávka odeslána poštou. 42

85

Obrázek č. 7.6: SFA - procesní diagram zpracování objednávky po implementaci (zdroj: autor)

Proměnné na obrázku č. 7.5: Kompletni? (hodnoty YES nebo NO): Je objednávka kompletní? PostouFV? (hodnoty YES nebo NO): Je faktura odeslána poštou? 86

7.2.2 Simulace procesu zpracování objednávky od obchodního zástupce Path Execution time

Costs

Path Description

1

00:000:02:02:00 277,5

SFA Before 1 (Business process diagram (BPMN 2.0)) Start Event: Navsteva zakaznika Task: Schuzka s nakupci Exclusive Gateway: Nakupci objednava --> Objednavka? = 'Yes' Task: Zaznamenani objednavky na papirovy formular Task: Faxovani formulare Task: Prijeti formulare Exclusive Gateway: Overeni dat a dostupnosti zbozi --> Kompletni? = 'No' Task: Komunikace s obchodnim zastupcem Task: Rucni prepsani objednavky do IS Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Tisk dodaciho listu Task: Vystaveni faktury Task: Odeslani zbozi odberateli Exclusive Gateway: Faktura postou --> PostouFV? = 'Yes' Task: Tisk faktury a predani recepcni Task: Odeslani faktury na poste End Event: Prijeti zbozi

2

00:000:01:57:00 267,5

SFA Before 1 (Business process diagram (BPMN 2.0)) Start Event: Navsteva zakaznika Task: Schuzka s nakupci Exclusive Gateway: Nakupci objednava --> Objednavka? = 'Yes' Task: Zaznamenani objednavky na papirovy formular Task: Faxovani formulare Task: Prijeti formulare Exclusive Gateway: Overeni dat a dostupnosti zbozi --> Kompletni? = 'Yes' Task: Rucni prepsani objednavky do IS Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Tisk dodaciho listu Task: Vystaveni faktury Task: Odeslani zbozi odberateli Exclusive Gateway: Faktura postou --> PostouFV? = 'Yes' Task: Tisk faktury a predani recepcni Task: Odeslani faktury na poste End Event: Prijeti zbozi

3

00:000:01:31:00 218,5

SFA Before 1 (Business process diagram (BPMN 2.0)) Start Event: Navsteva zakaznika Task: Schuzka s nakupci Exclusive Gateway: Nakupci objednava --> Objednavka? = 'Yes' Task: Zaznamenani objednavky na papirovy formular Task: Faxovani formulare

87

Task: Prijeti formulare Exclusive Gateway: Overeni dat a dostupnosti zbozi --> Kompletni? = 'No' Task: Komunikace s obchodnim zastupcem Task: Rucni prepsani objednavky do IS Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Tisk dodaciho listu Task: Vystaveni faktury Task: Odeslani zbozi odberateli Exclusive Gateway: Faktura postou --> PostouFV? = 'No' Task: Odeslani faktury faxem nebo emailem End Event: Prijeti zbozi 4

00:000:01:26:00 208,5

SFA Before 1 (Business process diagram (BPMN 2.0)) Start Event: Navsteva zakaznika Task: Schuzka s nakupci Exclusive Gateway: Nakupci objednava --> Objednavka? = 'Yes' Task: Zaznamenani objednavky na papirovy formular Task: Faxovani formulare Task: Prijeti formulare Exclusive Gateway: Overeni dat a dostupnosti zbozi --> Kompletni? = 'Yes' Task: Rucni prepsani objednavky do IS Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Tisk dodaciho listu Task: Vystaveni faktury Task: Odeslani zbozi odberateli Exclusive Gateway: Faktura postou --> PostouFV? = 'No' Task: Odeslani faktury faxem nebo emailem End Event: Prijeti zbozi

5

00:000:00:30:00 60,0

SFA Before 1 (Business process diagram (BPMN 2.0)) Start Event: Navsteva zakaznika Task: Schuzka s nakupci Exclusive Gateway: Nakupci objednava --> Objednavka? = 'No' End Event: Dokonceni navstevy

Tabulka č. 7.5: SFA - výstup ze simulace procesu před implementací (zdroj: autor)

88

Path Execution time

Costs

Path Description

1

00:000:01:39:00 234,0

SFA After 1 (Business process diagram (BPMN 2.0)) Start Event: Navsteva zakaznika Task: Schuzka s nakupci Exclusive Gateway: Nakupci objednava --> Objednavka? = 'Yes' Task: Zaznamenani objednavky na mobilni zarizeni Task: Synchronizace mobilniho zarizeni Task: Zpracovani a import dat do IS Exclusive Gateway: Overeni dat a dostupnosti zbozi --> Kompletni? = 'No' Task: Komunikace s obchodnim zastupcem Task: Potvrzeni objednavky Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Tisk dodaciho listu Task: Vystaveni faktury Task: Odeslani zbozi odberateli Exclusive Gateway: Faktura postou --> PostouFV? = 'Yes' Task: Tisk faktury a predani recepcni Task: Odeslani faktury na poste End Event: Prijeti zbozi

2

00:000:01:34:00 224,0

SFA After 1 (Business process diagram (BPMN 2.0)) Start Event: Navsteva zakaznika Task: Schuzka s nakupci Exclusive Gateway: Nakupci objednava --> Objednavka? = 'Yes' Task: Zaznamenani objednavky na mobilni zarizeni Task: Synchronizace mobilniho zarizeni Task: Zpracovani a import dat do IS Exclusive Gateway: Overeni dat a dostupnosti zbozi-->Kompletni?= 'Yes' Task: Potvrzeni objednavky Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Tisk dodaciho listu Task: Vystaveni faktury Task: Odeslani zbozi odberateli Exclusive Gateway: Faktura postou --> PostouFV? = 'Yes' Task: Tisk faktury a predani recepcni Task: Odeslani faktury na poste End Event: Prijeti zbozi

3

00:000:01:08:00 175,0

SFA After 1 (Business process diagram (BPMN 2.0)) Start Event: Navsteva zakaznika Task: Schuzka s nakupci Exclusive Gateway: Nakupci objednava --> Objednavka? = 'Yes' Task: Zaznamenani objednavky na mobilni zarizeni Task: Synchronizace mobilniho zarizeni Task: Zpracovani a import dat do IS Exclusive Gateway: Overeni dat a dostupnosti zbozi --> Kompletni? = 'No'

89

Task: Komunikace s obchodnim zastupcem Task: Potvrzeni objednavky Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Tisk dodaciho listu Task: Vystaveni faktury Task: Odeslani zbozi odberateli Exclusive Gateway: Faktura postou --> PostouFV? = 'No' Task: Odeslani faktury faxem nebo emailem End Event: Prijeti zbozi 4

00:000:01:03:00 165,0

SFA After 1 (Business process diagram (BPMN 2.0)) Start Event: Navsteva zakaznika Task: Schuzka s nakupci Exclusive Gateway: Nakupci objednava --> Objednavka? = 'Yes' Task: Zaznamenani objednavky na mobilni zarizeni Task: Synchronizace mobilniho zarizeni Task: Zpracovani a import dat do IS Exclusive Gateway: Overeni dat a dostupnosti zbozi-->Kompletni?= 'Yes' Task: Potvrzeni objednavky Task: Vystaveni dodaciho listu Task: Priprava zbozi k odeslani Task: Tisk dodaciho listu Task: Vystaveni faktury Task: Odeslani zbozi odberateli Exclusive Gateway: Faktura postou --> PostouFV? = 'No' Task: Odeslani faktury faxem nebo emailem End Event: Prijeti zbozi

5

00:000:00:30:00 60,0

SFA After 1 (Business process diagram (BPMN 2.0)) Start Event: Navsteva zakaznika Task: Schuzka s nakupci Exclusive Gateway: Nakupci objednava --> Objednavka? = 'No' End Event: Dokonceni navstevy

Tabulka č. 7.6: SFA - výstup ze simulace procesu po implementaci (zdroj: autor)

90

7.2.3 Výsledky simulace procesu zpracování objednávky od obchodního zástupce Pro porovnání obou simulací procesu zpracování objednávky před a po implementaci řešení SFA je pouţita jednoduchá metoda, ve které je vypočtena průměrná hodnota ukazatele „doba trvání“ a „náklad“ za obě simulace a všechny průchody. Tyto hodnoty jsou pak vzájemně porovnány a vyvozeny relevantní závěry. Průchod 1 2 3 4 5 Průměr

Doba trvání [min] 122 117 91 86 30 89

Náklady [Kč] 277,5 267,5 218,5 208,5 60 206

Tabulka č. 7.7: SFA - hodnoty klíčových ukazatelů před implementací (zdroj: autor)

Průchod 1 2 3 4 5 Průměr

Doba trvání [min] 99 94 68 63 30 71

Náklady [Kč] 234 224 175 165 60 172

Tabulka č. 7.8: SFA - hodnoty klíčových ukazatelů po implementaci (zdroj: autor)

Z uvedených hodnot vyplývá, ţe po implementaci SFA došlo ke sníţení doby trvání procesu zpracování objednávky o 20 % a sníţení nákladů na proces o 17 %.

91

8 SHRNUTÍ PRAKTICKÉ ČÁSTI Součástí praktické částí této diplomové práci je případová studie, v rámci které jsou zkoumány skutečně realizované implementace obou řešení. Během těchto projektů bylo ve skutečnosti přistoupeno k modelování a související procesní analýze aţ po dokončení implementace. Jinými slovy, nebyly předem graficky rozebrány a modelovány změny procesního modelu, které implementace vyvolají. Kapitola 7 v této diplomové práci tuto skutečnost opisuje a provádí zpětně to, co by mělo provázet kaţdou implementaci v celém jejím průběhu. Přínosy modelování procesů Přínosy modelování procesů a jejich simulace přímo vyplývají z dosaţených závěrů, které přináší zejména kapitola 7 v kombinaci s kapitolou 4. Provedení modelování procesů a jejich simulace ukázala veškeré procesní změny, které z implementací vyplývají. Díky modelování procesů je moţné tyto změny diskutovat, prezentovat a objasňovat uţivatelům či přijmout před samotnou realizací implementace taková rozhodnutí, která mohou mít zásadní vliv na úspěch implementace a následnou spokojenost uţivatele. Díky modelování procesů a jejich simulaci je moţné včas predikovat veškeré dopady na ostatní systémy společnosti a je tak moţné optimálně připravit související systémové okolí na veškeré změny, které z implementace plynou. Simulace procesů nakonec umoţní vyčíslit vliv na klíčové sledované atributy, jimiţ bývají nejčastěji čas a náklady spojené s procesním průchodem. Stejně jako v této diplomové práci, je pak moţné přesně vyčíslit úspory, které plynou z implementace daného řešení. Je důleţité skutečně nepodcenit tento krok a vnímat tvorbu i analýzu procesů jako organickou část návrhu, kterou je velmi vhodné realizovat před i po zavedení nového řešení. Další vyuţití nástroje pro modelování procesů ADONIS Během zpracování praktické částí této diplomové práce byl pouţit nástroj pro modelování procesů ADONIS. Vzhledem k širokým moţnostem pouţití tohoto nástroje a omezenému rozsahu této diplomové práce nebyly zdaleka pouţity všechny funkcionality, které nástroj pro modelování procesů ADONIS nabízí. Lze uvést několik moţností, jak by bylo moţné ještě rozšířit vyuţití tohoto nástroje na případ modelování procesů v této diplomové práci.

92

Součástí nástroje pro modelování procesů ADONIS je komponenta, která je nazvaná „Analýza“. Tato komponenta byla vyuţita v této diplomové práce ve výchozím rozsahu, resp. s předdefinovanými dotazy. Komponenta však umoţňuje pouţít vlastní uţivatelské dotazy a „ptát se“ namodelovaných procesů, jak budou reagovat na určité okolnosti. Nabízí se proto vyuţít tuto komponentu spolu se simulací například v souvislosti s personálem a predikcí toho, jaký vliv by mělo případné najmutí nebo propuštění některého zaměstnance. V kombinaci se simulací je moţné znázornit výsledky tabulkově, graficky nebo případně i s moţností animace. Jinými slovy, v této práci byla provedena tzv. „analýza cest podnikových procesů“, nabízí se pokračovat kapacitní analýzou a analýzou vytíţení při vyuţití uţivatelsky definovaných dotazů. Nástroj pro modelování procesů ADONIS by dále bylo vhodné pouţít pro namodelování pracovního prostředí, jinými slovy znázornění organizační struktury předmětné společnosti. Dále se nabízí zpracování modelu dokumentů, ve kterém je moţné znázornit dokumenty a informace pouţívané v jednotlivých procesech. S tím souvisí také velmi vhodný aplikační diagram v kombinaci s modelem IT řešení, coţ umoţňuje znázornit veškerá IT řešení navázaná na jednotlivé procesy a graficky prezentovat interakci mezi uţivatelem a IT řešením. Velmi uţitečná je také komponenta nástroje pro modelování procesů ADONIS nazvaná „Dokumentace“, která umoţňuje modely procesů transformovat do jiných formátu kompatibilních například s firemním webovými stránkami nebo intranetovými portálem. Dosaţené poznání V případě implementace řešení EDI bylo dosaţeno vysokých úspor časových i nákladových díky optimalizaci procesu, čímţ se potvrzuje skutečnost, ţe motivací firem k realizaci takového projektu jsou především úspory a hned po té poţadavky odběratelů, logistika a vztah se zákazníky. Řešení EDI má dramatický vliv na provozní i mzdové náklady společnosti, je však třeba důsledně zváţit a spočítat před realizací implementace, zda je dosaţeno takového objemu komunikovaných dokladů, aby byla investice rentabilní podobně, jako v této diplomové práci. V případě implementace SFA nebylo dosaţeno tak vysokých úspor, neboť motivací pro realizaci takového projektu nejsou primárně úspory, ale zejména nedostatečná a neefektivní moţnost kontroly a řízení obchodního týmu. Řešení tohoto typu, kromě úspor, poskytuje sadu významných nástrojů, které umoţní obchodnímu týmu efektivně pokrýt větší

93

část trhu, kontinuálně ji monitorovat a přijímat taková rozhodnutí, která povedou k nastartování firmy na úroveň své potenciální výkonnosti a kapacity. Obě řešení společně poskytují do takové míry silné obchodní nástroje, ţe v současné době jiţ lze jejich absenci pojmenovat jako fatální konkurenční nevýhodu, která můţe být aţ eliminačního charakteru. Samozřejmě je třeba tento názor vymezit do segmentu společností kam patří, tedy významní výrobci, dodavatelé, obchodní řetězce, distributoři či velkoobchody.

94

ZÁVĚR Cílem této práce bylo navrhnout, realizovat a zhodnotit implementaci řešení EDI a SFA v prostředí vybraného podniku a zrealizovat modelování a simulaci procesů pomocí nástroje ADONIS. Cíle bylo dosaţeno rozdělením práce do dvou částí, teoretické a praktické. Teoretickou část tvoří kapitoly 2, 3, 5, 6. Kapitola 2 charakterizuje obě řešení a vymezuje význam, vliv, důvody a podněty, které by měly management podniku motivovat k implementaci řešení. Kapitola 3 navrhuje optimální postup implementace a zdůrazňuje dílčí kroky a aktivity, které vedou k úspěšné realizaci implementace. Kapitola 5 doporučuje a klade důraz na chyby během realizace, jichţ je vhodné se vyvarovat. Kapitola 6 definuje význam procesní analýzy a modelování procesů vůči implementacím rozličných řešení a změn. Současně tato kapitola charakterizuje pouţitý nástroj pro modelování procesů a jejich simulaci. Praktickou část tvoří kapitoly 4, 7, 8, které jsou současně případovou studií v české společnosti, která se věnuje výrobě a distribuci kosmetických výrobků a minerálních vod. Kapitola 4 obsahuje rozbor investičních nákladů na implementaci obou řešení a srovnání provozních nákladů týkajících se obou řešení. V této kapitole byla také spočtena návratnost investice a zhodnoceny implementace po stránce vlivu na provozní náklady a efektivitu podniku. Vyčísleny byly v této kapitole také úspory, které z implementací obou řešení vyplývají. Kapitola 7 je věnována popisu, modelování a simulaci procesu zpracování objednávky před a po implementaci obou řešení. Ze simulace procesů jsou vyvozeny závěry, které ukazují vliv realizovaných implementací na klíčové měřitelné atributy. Kapitola 8 uzavírá praktickou část a popisuje závěry, které z ní plynou autorovi. Snahou autora bylo srozumitelně sjednotit a ucelit informace o EDI a SFA, zprostředkovat zkušenosti a znalosti tak, aby byl zřejmý význam, principy a výhody plynoucí společnosti po implementaci řešení. Podle autorova názoru bylo tohoto cíle dosaţeno a tato práce by měla umoţnit snáze proniknout do problematiky EDI a SFA. Autor spatřuje přínos této práce v uceleném průvodci problematikou řešení, která zásadně podporují obchodní aktivitu a efektivitu firmy. Případovou studií je zdůrazněn význam obou řešení vzhledem k provozním nákladům a současně jsou vyčísleny úspory a s nimi spojená návratnost investice. Předány jsou zkušenosti a definovány jsou nejčastěji vyskytující se 95

chyby při implementacích a následné správě řešení. V práci jsou pouţity vlastnoručně tvořené, nepřevzaté obrázky a grafy, čímţ je zajištěna maximální názornost a kontinuita ve vztahu k této diplomové práci. Na závěr je provedeno modelování a simulace procesů v nástroji ADONIS, čímţ autor naplňuje cíl diplomové práce a podtrhuje významný vliv obou řešení na optimální procesní zajištění podniku.

96

SEZNAM POUŢITÉ LITERATURY 1. AG, BOC. ADONIS 4.0 - Uživatelský manuál. Wien : BOC AG, 2012. 2. GS1 Czech Republic. Dodavatelé pro Systém. [Online] 2015 [cit. 2015-02-20]. Dostupné z: http://www.gs1cz.org/podpora/dodavatele-pro-system-gs1/. 3. CCV, s.r.o. EDI – ready informační systémy (ERP systémy). EDI Zone: informační portál. [Online] CCV, s.r.o., 2008 [cit. 2015-02-20]. Dostupné z: http://www.edizone.cz/elektronicka-vymena-dat-edi/edi-ready-erp-systemy/. 4. GXS. EDIFACT. EDI Basics: Your resource for learning about EDI. [Online] 2015 [cit. 2015-02-20]. Dostupné z: http://www.edibasics.co.uk/edi-resources/document-standards/edifact/. 5. GS1. GS1 around the world. GS1 - The global language of business. [Online] 2015 [cit. 2015-02-20]. Dostupné z: http://gs1.com/about/our_offices/. 6. GS1 Czech Republic. O nás. [Online] 2015 [cit. 2015-02-20]. Dostupné z: http://www.gs1cz.org/o-nas/. 7. GS1. Overview. GS1 - The global language of business. [Online] 2015 [cit. 2015-02-20]. Dostupné z: http://gs1.com/about/overview/. 8. CCV, s.r.o. Typy EDI zpráv a jejich použití. EDI Zone: informační portál. [Online] 2008 [cit. 2015-02-20]. Dostupné z: http://www.edizone.cz/poradna/typy-edi-zprav/. 9. REICHEL, David. Jak na elektronickou výměnu dat? [Online] 2009 [cit. 2015-02-20]. Dostupné z: http://www.ccv.cz/elektronicka-komunikace-edi/jak-na-edi-elektronickouvymenu-dat/. 10. GS1, Czech Republic. OSO2015. GS1 Czech Republic. [Online] 2015 [cit. 2015-02-20]. Dostupné z: http://www.gs1cz.org/download/smlouvy/smlouva-oso-2015.pdf. 11. GÁLA, Libor, POUR, Jan a ŠEDIVÁ, Zuzana. Podniková informatika. 2., přeprac. a aktualiz. vyd. Praha : Grada Publishing, a.s., 2009. str. 496. ISBN 978-80-247-2615-1.

97

SEZNAM TABULEK Tabulka č. 4.1: EDI - struktura mzdových nákladů na analýzu ............................................... 42 Tabulka č. 4.2: EDI - struktura mzdových nákladů na výběr řešení ........................................ 42 Tabulka č. 4.3: EDI - struktura mzdových nákladů na smluvní zajištění ................................. 42 Tabulka č. 4.4: EDI - struktura mzdových nákladů na tvorbu inhouse .................................... 42 Tabulka č. 4.5: EDI - struktura mzdových nákladů na přípravu HW a SW ............................. 43 Tabulka č. 4.6: EDI - struktura mzdových nákladů na zřízení GLN ........................................ 43 Tabulka č. 4.7: EDI - struktura mzdových nákladů na validaci inhouse .................................. 43 Tabulka č. 4.8: EDI - struktura mzdových nákladů na ověření komunikace ........................... 43 Tabulka č. 4.9: EDI - struktura mzdových nákladů na testování ............................................. 43 Tabulka č. 4.10: EDI - struktura mzdových nákladů na ostrý provoz ...................................... 43 Tabulka č. 4.11: EDI - kategorie nákladů na sluţby GS1 dle ročních trţeb ............................ 45 Tabulka č. 4.12: EDI - statistika komunikovaných objednávek ............................................... 47 Tabulka č. 4.13: EDI - statistika komunikovaných dodacích listů ........................................... 48 Tabulka č. 4.14: EDI - statistika komunikovaných faktur ........................................................ 48 Tabulka č. 4.15: EDI - kalkulace provozních nákladů po implementaci ................................. 51 Tabulka č. 4.16: EDI - kalkulace provozních nákladů před implementací .............................. 51 Tabulka č. 4.17: SFA - struktura mzdových nákladů na přípravu HW a SW .......................... 53 Tabulka č. 4.18: SFA - struktura mzdových nákladů na tvorbu interface ................................ 53 Tabulka č. 4.19: SFA - struktura mzdových nákladů na správu mob. zařízení ........................ 53 Tabulka č. 4.20: SFA - struktura mzdových nákladů na analytický výstup ............................. 53 Tabulka č. 4.21: SFA - struktura mzdových nákladů na testování ........................................... 53 Tabulka č. 4.22: SFA - struktura mzdových nákladů ostrý provoz .......................................... 53 Tabulka č. 4.23: SFA - struktura nákladů na pořízení HW a SW ............................................ 55 Tabulka č. 4.24: SFA - struktura nákladů na externí projektový tým ...................................... 55 Tabulka č. 7.1: EDI - výstup ze simulace procesu před implementací .................................... 78 Tabulka č. 7.2: EDI - výstup ze simulace procesu po implementaci........................................ 79 Tabulka č. 7.3: EDI - hodnoty klíčových ukazatelů před implementací .................................. 80 Tabulka č. 7.4: EDI - hodnoty klíčových ukazatelů po implementaci ..................................... 80 Tabulka č. 7.5: SFA - výstup ze simulace procesu před implementací .................................... 88 Tabulka č. 7.6: SFA - výstup ze simulace procesu po implementaci ....................................... 90 Tabulka č. 7.7: SFA - hodnoty klíčových ukazatelů před implementací ................................. 91 Tabulka č. 7.8: SFA - hodnoty klíčových ukazatelů po implementaci..................................... 91

98

SEZNAM OBRÁZKŮ Obrázek č. 2.1: EDI - zjednodušený proces výměny objednávky papírovou formou .............. 16 Obrázek č. 2.2: EDI - zjednodušený proces výměny objednávky el. formou .......................... 16 Obrázek č. 2.3: EDI - schéma komunikace end-to-end bez vyuţití dodatečných sluţeb ......... 19 Obrázek č. 2.4: EDI - schéma komunikace při vyuţití sluţeb VAN operátora ........................ 20 Obrázek č. 2.5: EDI - schéma komunikace při vyuţití sluţeb poskytovatele .......................... 21 Obrázek č. 2.6: EDI - zjednodušené schéma sítě VAN ............................................................ 21 Obrázek č. 7.1: EDI - funkční model účastníků procesu zpracování objednávky.................... 71 Obrázek č. 7.2: EDI - procesní diagram zpracování objednávky před implementací .............. 73 Obrázek č. 7.3: EDI - procesní diagram zpracování objednávky po implementaci ................. 75 Obrázek č. 7.4: SFA - funkční model účastníků procesu ......................................................... 81 Obrázek č. 7.5: SFA - procesní diagram zpracování objednávky před implementací ............. 84 Obrázek č. 7.6: SFA - procesní diagram zpracování objednávky po implementaci ................ 86

99

SEZNAM GRAFŮ Graf č. 4.1: EDI - struktura ceny jednoho odeslaného dokladu v papírové formě ................... 49 Graf č. 4.2: EDI - struktura ceny jednoho odeslaného el. dokladu........................................... 50

100

SEZNAM PŘÍLOH Příloha č. 1 Typy EDI zpráv Příloha č. 2 Kompaktní disk

101

Příloha č.1 Typy EDI zpráv Typy EDI zpráv Standard UN/EDIFACT definuje více neţ sto různých zpráv, které si mezi sebou mohou subjekty vyměňovat v různých oblastech průmyslu a obchodu. Nejčastěji vyuţívané v obchodní praxi se spotřebním zboţím jsou tyto48: INVOIC (Invoice) – Faktura Jedná se o zprávu, kterou zasílá dodavatel svému odběrateli s cílem platby za zboţí nebo sluţby. Stejnou zprávu je moţné vyuţít v případě proforma faktury, zálohové faktury, dluhopisu nebo dobropisu. ORDERS (Purchase Order) – Objednávka Jedná se o zprávu, kterou zasílá odběratel svému dodavateli s cílem objednat zboţí nebo sluţby. DESADV (Despatch Advice) – Avízo o odeslání zboţí Jedná se o zprávu, kterou zasílá dodavatel svému odběrateli, v rámci které jsou specifikovány podrobnosti o dodávce zboţí. Můţeme také chápat jako dodací list, který by měl být zasílán příjemci vţdy před fyzickou dodávkou zboţí tak, aby bylo umoţněno získat s předstihem přesné informace o dodávaném zboţí a příjemce se tak měl moţnost připravit na fyzickou přejímku zboţí. RECADV (Receiving Advice) – Potvrzení příjmu zboţí Jedná se o zprávu, kterou zasílá odběratel svému dodavateli a tím potvrzuje příjem zboţí. Jde z pravidla o odpověď na zprávu DESADV. V rámci této zprávy lze řešit také nesrovnalosti v dodávce zboţí. RETANN (Announcement For Returns) – Oznámení o vrácení zboţí Jedná se o zprávu, kterou zasílá odběratel svému dodavateli s cílem vrátit mu z určitého specifikovaného důvodu zboţí. Zpráva je zpravidla zasílána s vazbou na předchozí zprávu RECADV.

48

(8)CCV, s.r.o. Typy EDI zpráv a jejich použití. EDI Zone: informační portál. [Online] CCV, s.r.o., 2008-2012.

1

REMADV (Remmitance Advice) – Avízo o platbě Jedná se o zprávu, kterou zasílá odběratel svému dodavateli s cílem informovat o odeslání platby. PRICAT (Price / Sales Catalogue) – Katalog zboţí a cen Jedná se o zprávu, kterou odesílá dodavatel svým odběratelům s cílem distribuce aktuálního katalogu nabízeného zboţí. Zpráva je také vyuţívána jako informace o změnách v nabízeném sortimentu. Takový katalog obsahuje kromě cenových informací také obchodní a logistické údaje. PARTIN (Party Information) – Informace o organizaci

49

Jedná se o první zprávu, kterou si obě komunikující strany vymění při zahájení komunikace. Zpráva poskytuje základní obchodní informace o partnerské organizaci. Taktéţ je zpráva zasílána při změně obchodních údajů. APERAK (Application error and acknowledgement message) – potvrzení o převzetí zprávy aplikací Jedná se o zprávu, kterou zasílá příjemce odesílateli jako informaci o úspěšném zpracování nebo chybách při zpracování. COMDIS (Commercial Dispute) – Obchodní námitka Jedná se o zprávu, kterou zasílá odběratel svému dodavateli s cílem informovat o nesrovnalosti v přijaté faktuře. Touto zprávou oznamuje odběratel zamítnutí faktury s chybami nebo její přijetí s výhradami. CONTRL (Syntax and Service Report) – Kontrolní zpráva Jedná se o zprávu, kterou zasílá příjemce odesílateli s cílem syntakticky přijmout či zamítnout přijatou zprávu. IFTMAN (Arrival Notice) – Avízo příchodu zásilky Jedná se o zprávu, kterou zasílá přepravní firma příjemci zásilky s její specifikací.

49

Dostupný seznam zpráv autorem rozšířen o známé kontrolní a bezpečnostní zprávy.

2

INVRPT (Inventory Report) – Přehled zásob Jedná se o zprávu, která umoţňuje oběma subjektům se vzájemně informovat o stavu současných nebo plánovaných zásob. Zpravidla jsou součástí zprávy informace o počátečním stavu, současném stavu a pohybu zásob. AUTACK – Ověření bezpečnostních funkcí zprávy příjemcem Jedná se o potvrzovací zprávu, která slouţí pro bezpečné potvrzení příjmu zprávy nebo pro informování o bezpečnostní chybě při kontrole zprávy. Zpráva obsahuje reference na přijaté zprávy a hash kód (otisk zprávy) přijatých zpráv. Hash kód slouţí pro kontrolu integrity. Zpráva AUTACK se jiţ nepotvrzuje zprávou AUTACK. CIPHER Jedná o zprávu, která slouţí pro šifrování přenášených zpráv. Zpráva můţe obsahovat zašifrovaný text libovolné zprávy a je umístěna v souboru výměny místo zprávy původní. Při příjmu je následně zpráva CIPHER opět dešifrována a nahrazena původní zprávou. KEYMAN Jedná se o zprávu, která umoţňuje přenášet klíče a certifikáty mezi různými subjekty.

3

Příloha č.2 Kompaktní disk Kompaktní disk Název

Umístění

Popis

01_inh_pricat_d01b.pdf

.\Prilohy\Specifikace\INH

Specifikace inhouse formátu zprávy Pricat

02_edi_pricat_d01b.pdf

.\Prilohy\Specifikace\EDI

Specifikace EDI formátu zprávy Pricat

03_edi_invoic_d96a.pdf

.\Prilohy\Specifikace\EDI

Specifikace EDI formátu zprávy Invoic

04_inh_all_d96a.xls

.\Prilohy\Specifikace\INH

Specifikace inhouse formátu všech zpráv

05_edi_invoic_vzor.edi

.\Prilohy\Vzory\EDI

Vzor zprávy Invoic v EDI formátu

06_edi_orders_vzor.edi

.\Prilohy\Vzory\EDI

Vzor zprávy Orders v EDI formátu

07_inh_orders_vzor.txt

.\Prilohy\Vzory\INH

Vzor zprávy Orders v inhouse formátu

08_inh_invoic_vzor.txt

.\Prilohy\Vzory\INH

Vzor zprávy Invoic v inhouse formátu

1

Implementace řešení SFA a EDI

Recommend Documents