Implementace podnikového informačního systému

Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta

Implementace podnikového informačního systému Diplomová práce

Vedoucí práce: Ing. Roman Malo, Ph.D.

Bc. Jan Mészáros

Brno 2009

Děkuji Ing. Romanu Malovi, Ph.D., za vedení, podporu a cenné připomínky při tvorbě této práce. Dále děkuji všem mým spolupracovníkům za obětavou pomoc v průběhu realizace projektu podnikového informačního systému.

Prohlašuji, že jsem tuto diplomovou práci vytvořil samostatně podle pokynů vedoucího diplomové práce s využitím odborné a jiné literatury, kterou uvádím v závěru práce.

V Brně dne 25. května 2009

....................................................

4

Abstract Mészáros, J. Enterprise information system implementation. Diploma thesis. Brno, 2009. This work compiles design and implementation of an enterprise IS for production and trading company. Current situation of ERP systems in Czech republic and made-to-measure IS implementation benefits are analysed. There are summarized an enterprise IS implementation methodics and theoretical principles of business process computerisation through the Petri nets as the theoretical basis. This work takes the Petri nets as the basis for workflow processes implementation and desribes the existing workflow process standards. Key words IS, ERP, enterprise, workflow, implementation, standardization, information system, business process, analysis

Abstrakt Mészáros, J. Implementace podnikového informačního systému. Diplomová práce. Brno, 2009. Tato práce zpracovává konkrétní projekt IS a dokumentuje vlastní implementaci podnikového IS pro výrobně-obchodní společnost. Práce se věnuje teké analýze současné situace na poli ERP systémů v ČR a analýze možností vývoje IS na míru. Jako teoretický základ práce jsou popsány metodiky implementace podnikových IS a teoretický základ komputerizace podnikových procesů pomocí Petriho sítí. Práce pojímá Petriho sítě jako základ pro implementaci workflow procesů, analyzuje a popisuje existující standardy pro definice workflow procesů. Klíčová slova IS, ERP, podnik, workflow, implementace, standardizace, informační systém, podnikové procesy, analýza

5

OBSAH

Obsah 1 Úvod a cíl práce 1.1 Uvedení do problematiky . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 8 8

2 Teoretická problematika implementace 2.1 Metodiky implementace podnikových IS . . . . . . . . 2.2 Teoretický základ komputerizace podnikových procesů . 2.2.1 Petriho sítě . . . . . . . . . . . . . . . . . . . . 2.2.2 C/E Petriho sítě . . . . . . . . . . . . . . . . . 2.2.3 P/T Petriho sítě . . . . . . . . . . . . . . . . . 2.2.4 Podtřídy P/T sítí . . . . . . . . . . . . . . . . . 2.2.5 Rozšíření Petriho sítí . . . . . . . . . . . . . . . 2.2.6 Petriho sítě vyšší úrovně . . . . . . . . . . . . . 2.2.7 Podnikové procesy a workflow . . . . . . . . . . 2.3 Standardy pro workflow . . . . . . . . . . . . . . . . . 2.3.1 XPDL . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Wf-XML . . . . . . . . . . . . . . . . . . . . . . 2.3.3 OMG Workflow Facility . . . . . . . . . . . . . 2.3.4 BPML . . . . . . . . . . . . . . . . . . . . . . . 2.4 Software pro podporu workflow . . . . . . . . . . . . . 2.4.1 Enhydra JaWE, Enhydra Shark . . . . . . . . . 2.4.2 Workflow::Wfmc . . . . . . . . . . . . . . . . . 2.4.3 Bonita . . . . . . . . . . . . . . . . . . . . . . . 2.4.4 JawFlow . . . . . . . . . . . . . . . . . . . . . . 2.4.5 Open Business Engine . . . . . . . . . . . . . . 2.4.6 WfMOpen . . . . . . . . . . . . . . . . . . . . . 2.5 Analýza současné situace na trhu ERP systémů . . . . 2.5.1 Metodika analýzy a zdroje informací . . . . . . 2.5.2 Klasifikační kritéria . . . . . . . . . . . . . . . . 2.5.3 Souhrnné charakteristiky ERP systémů . . . . . 2.6 Vyhodnocení analýzy trhu ERP systémů . . . . . . . . 2.7 Analýza možností vývoje software na míru . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

9 9 10 10 11 11 12 12 12 14 16 16 17 17 17 17 18 18 18 18 18 18 19 19 19 21 28 31

3 Projekt podnikového informačního systému 3.1 Úvodní studie . . . . . . . . . . . . . . . . . . . . 3.2 Základní zadání . . . . . . . . . . . . . . . . . . . 3.3 Analýza . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Stávající informační systém . . . . . . . . 3.3.2 Nový informační systém . . . . . . . . . . 3.4 Plánování zdrojů potřebných k realizaci projektu 3.5 Volba vhodných metodik a technologií . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

33 33 34 34 34 35 37 37

. . . . . . .

. . . . . . .

. . . . . . .

6

OBSAH

3.6 3.7 3.8 3.9 3.10 3.11 3.12

3.5.1 Technologie aplikační vrstvy . . . . . . 3.5.2 Technologie prezentační vrstvy . . . . 3.5.3 Technologie datové vrstvy . . . . . . . Sestavení datového schématu . . . . . . . . . . Návrh aplikační architektury . . . . . . . . . . 3.7.1 Lokalizace a národní prostředí . . . . . Koncepce a grafický návrh prezentační vrstvy Vlastní programátorské práce . . . . . . . . . Testování . . . . . . . . . . . . . . . . . . . . Nasazení do produkčního prostředí . . . . . . Správa, údržba a uživatelská podpora . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

4 Implementace podnikového informačního systému 4.1 Datový model ORM – Model . . . . . . . . . . . . 4.2 Aplikační vrstva – Workflow . . . . . . . . . . . . . 4.2.1 Standard XPDL . . . . . . . . . . . . . . . . 4.2.2 Interface subsystému workflow . . . . . . . . 4.3 Aplikační vrstva – Controller . . . . . . . . . . . . . 4.3.1 Mapování URL . . . . . . . . . . . . . . . . 4.3.2 Práce s daty . . . . . . . . . . . . . . . . . . 4.3.3 Systémová uživatelská práva a skupiny . . . 4.3.4 Obchodní skupiny a role . . . . . . . . . . . 4.3.5 Obchodní pravidla . . . . . . . . . . . . . . 4.4 Prezentační vrstva – View . . . . . . . . . . . . . . 4.4.1 Šablonovací systém . . . . . . . . . . . . . . 4.4.2 Formuláře . . . . . . . . . . . . . . . . . . . 4.4.3 Tabulky s daty . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

38 41 41 41 43 46 47 48 49 49 51

. . . . . . . . . . . . . .

52 52 55 55 56 57 57 58 59 60 60 62 62 63 64

5 Zhodnocení realizovaného projektu 67 5.1 Zhodnocení životního cyklu . . . . . . . . . . . . . . . . . . . . . . . 67 5.2 Ekonomické zhodnocení . . . . . . . . . . . . . . . . . . . . . . . . . 67 6 Diskuse

69

7 Závěr

70

8 Literatura

71

Přílohy

72

A Uživatelský manuál 73 A.1 Pracovní prostředí Workflow . . . . . . . . . . . . . . . . . . . . . . . 73 A.1.1 Horní panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 A.1.2 Levý panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7

OBSAH

A.2

A.3

A.4 A.5 A.6

A.1.3 Hlavní panel . . . . . . . . . . . . . . . A.1.4 Klávesy pro ovládání tabulky . . . . . A.1.5 Ovládání tabulky myší . . . . . . . . . A.1.6 Obecně platná pravidla . . . . . . . . . A.1.7 Uživatelská práva . . . . . . . . . . . . Vytvoření zakázky . . . . . . . . . . . . . . . A.2.1 Skupinová zakázka . . . . . . . . . . . A.2.2 Číslování zakázek . . . . . . . . . . . . A.2.3 Vytvoření nového zboží . . . . . . . . . A.2.4 Vytvoření nové objednávky . . . . . . A.2.5 Vytvoření objednávky do Prahy . . . . A.2.6 Přílohy zakázky a zboží . . . . . . . . A.2.7 Vytvoření nabídky . . . . . . . . . . . A.2.8 Celkový kalkulační list . . . . . . . . . A.2.9 Fakturace . . . . . . . . . . . . . . . . A.2.10 Workflow – proces zpracování zakázky Dodavatelské faktury . . . . . . . . . . . . . . A.3.1 Zadání nové dodavatelské faktury . . . A.3.2 Likvidace dodavatelských faktur . . . . Reporty . . . . . . . . . . . . . . . . . . . . . Kontakty . . . . . . . . . . . . . . . . . . . . Závěr . . . . . . . . . . . . . . . . . . . . . . .

B Náhledy obrazovek

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

73 75 75 75 75 77 78 78 79 80 81 82 82 82 83 84 86 86 87 88 89 90 91

1

ÚVOD A CíL PRÁCE

1 1.1

8

Úvod a cíl práce Uvedení do problematiky

Každá výrobní firma potřebuje ke své podnikatelské činnosti podporu v podobě kvalitního informačního systému, který podporuje realizaci vnitropodnikových procesů. Při rozhodování o nasazení vhodného informačního systému má každá firma na výběr obecně ze dvou možností. Firma si může pořídit na trhu hotové řešení, svěří nasazení informačního systému do rukou zkušeného implementátora a využije tak možností outsourcingu. Druhou možnou cestou je vytvoření software přímo na míru potřebám dané společnosti. Tato práce bude věnována aspektům rozhodování o informačním systému v konkrétní výrobní firmě, bude se zabývat všemi kritérii, které vedou ke konečnému rozhodnutí. Práce bude věnována konkrétnímu postupu v případě, že se daná firma rozhodne vyvinout informační systém na míru. Bude popsán celý životní cyklus nového informačního systému a ekonomické zhodnocení realizovaného projektu s přihlédnutím ke konkrétním přínosům pro firmu.

1.2

Cíl práce

Cílem této práce je implementace podnikového informačního systému pro výrobněobchodní společnost. Bude vybrána vhodná metodika a bude prezentován potřebný teoretický základ pro vlastní řešení projektu. Projekt informačního systému bude následně zpracován. Dále bude popsán životní cyklus vyvinutého informačního systému od úvodní studie po nasazení systému v produkčním prostřední a několik měsíců reálného provozu. Práce bude věnována zejména metodikám realizace dílčích problémů řešení z pohledu vedoucího projektu. Bude znázorněn průběh operativního, taktického a strategického rozhodování v průběhu řešení projektu. Práce bude rovněž věnována analýze současné situace na trhu ERP systémů v ČR, srovnání výhod a nevýhod pořízení ERP systému na trhu oproti možnosti vývoje vlastního softwarového produktu z pohledu managementu podniku.

2

TEORETICKÁ PROBLEMATIKA IMPLEMENTACE

2

9

Teoretická problematika implementace

2.1

Metodiky implementace podnikových IS

V současné době existují dvě významné kategorie metodik vývoje informačních systémů, které se liší v takzvané váze metodiky. První kategorií jsou rigorózní metodiky, označované jako „těžké metodikyÿ. Druhou kategorii představují agilní metodiky, klasifikované z pohledu váhy metodiky jako „lehké metodikyÿ. Váha metodiky je definovaná jako součin velikosti metodiky a hustoty metodiky. Velikost metodiky vyjadřuje počet kontrolních prvků obsažených v metodice. Hustota metodiky vyjadřuje míru podrobnosti a těsnost tolerance metodiky, požadovanou detailnost a konzistenci prvků (Buchalevcová, 2005). Rigorózní metodiky vycházejí z předpokladu, že proces vývoje IS lze popsat, plánovat, řídit a měřit. Metodiky jsou značně objemné, uplatňují zpravidla vodopádový způsob vývoje. Mezi tyto metodiky patří (Buchalevcová, 2005): • • • • •

Model zralosti pro software, metodika OPEN, metodika Rational Unified Process, metodika Enterprise Unified Process, metodika MMDIS.

Těžké metodiky lze vhodně použít v řízení rozsáhlých softwarových projektů, do kterých je zapojeno značné množství osob v oddělených pracovních skupinách. Tento styl řízení nutně vyžaduje pevně stanovená pravidla fungování pracovních skupin i jednotlivců, přesně dané nástroje a metody pro plánování, řízení a měření prací. V průběhu realizace projektů, ve kterých jsou uplatněné rigorózní metodiky, nutně vzniká značné množství dokumentů. Vnitřní i vnější prostředí podniků začíná podléhat velmi častým změnám, jejichž frekvence se stále zvyšuje v souvislosti s obecnými změnami ve společnosti. V podmínkách změn se jeví rigorózní metodiky jako nevyhovující a těžkopádné. Reakcí na nové podmínky jsou agilní metodiky, které umožňují rychlou tvorbu řešení. Vytvořené řešení je možné snadno a rychle přizpůsobovat změnám. Agilní metodiky prosazují názor, že jedinou cestou, jak prověřit správnost navrženého systému, je vyvinout jej co nejrychleji, předložit zákazníkovi a na základě zpětné vazby jej upravit. Hlavní myšlenky všech agilních metodik formuluje „Manifest agilního vývoje softwaruÿ, vytvořený Aliancí pro agilní vývoj softwaru. Manifest deklaruje následující čtyři citované stěžejní hodnoty, které dávají přednost (Buchalevcová, 2005): • • • •

individualitám a komunikaci před procesy a nástroji; provozuschopnému softwaru před obsažnou dokumentací; spolupráci se zákazníkem před sjednáváním kontraktu; reakci na změnu před plněním plánu.

Mezi agilní metodiky, které respektují výše uvedené principy, podle (Buchalevcová, 2005) patří:

2.2

• • • • • • • •

Teoretický základ komputerizace podnikových procesů

10

Dynamic Systems Development Method, Adaptive Software Development, Lean Development, Feature-Driven Development, Crystal metodiky, Scrum, Extrémní programování, Agilní modelování.

2.2


Obchodní i výrobní procesy řady podniků nabývají s aplikací nových technologií značné složitosti, která vede k nutnosti zavedení nových přístupů k návrhu, analýze a simulaci těchto procesů. Vhodný teoretický základ pro formální a grafické vyjádření složitých paralelních procesů, takzvané Petriho sítě, zavedl německý matematik C. A. Petri roku 1962 ve své doktorské disertační práci. Zavedené principy byly dále rozpracovány. Vznikla řada rozšíření, které nalezly své využití v oblasti počítačových systémů, telekomunikací a průmyslových automatizovaných systémů. Principy Petriho sítí mohou být v neposlední řadě použity při popisu a analýze obchodních procesů, které mohou být řízeny pomocí nástrojů pro podporu workflow. 2.2.1

Petriho sítě

Petriho sítě jsou formálním a grafickým jazykem určeným pro modelování a analýzu paralelních, distribuovaných, nedeterministických systémů, které sdílí určité omezené či neomezené zdroje. Jazyk byl definován německým matematikem C.A.Petrim v roce 1962 jako rozšíření modelovacích možností konečných automatů. Základem rozšíření konečných automatů jsou události systému propojené s podmínkami, které vyplývají z parciálních stavů systému.

Obr. 1: Petriho síť

2.2


11

Na obrázku 1 je vyobrazena jednoduchá Petriho síť s paralelní větví, kterou představují části od přechodu T1 po přechod T4. Parciální stavy, graficky zobrazované jako malé kružnice, se nazývají místa Petriho sítě (places). Události, graficky zobrazované jako obdélníky nebo úsečky, se nazývají přechody Petriho sítě (transitions). Dosažení jistého parciálního stavu je znázorněno tzv. značením místa (marking), graficky vyjádřeným určitým počtem teček, které nazýváme značkami (tokens). Místa a přechody jsou spojeny pomocí hran (arcs), znázorněných jako orientované úsečky či křivky. Formálně je sít vyjádřena takto: Trojici N = (P, T, F ) nazýváme sítí, jestliže P a T jsou disjunktní množiny a F ⊆ (P × T ) ∪ (T × P ) je binární relace. Množina P se nazývá množinou míst, množina T množinou přechodů sítě. Relace F je tokovou relací sítě N. Grafem sítě nazýváme bipartitní orientovaný graf, který vznikne grafovou reprezentací relace F . Množina P ∪ T je množinou vrcholů grafu sítě (Češka et al, 2006). 2.2.2

C/E Petriho sítě

Základním typem Petriho sítí jsou sítě složené z podmínek a událostí, tzv. C/E Petriho sítě (Condition-Event Petri Nets), které interpretují místa jako logické podmínky. Jedno místo může tedy obsahovat buď jednu značku, která vyjadřuje splnění podmínky (hodnotu true) anebo žádnou značku jako vyjádření nesplnění podmínky (hodnota false). Množina podmínek splněných ve stejný okamžik se nazývá případ. Provedení události znamená přesun značky do dalšího místa. Při provedení (výskytu) události nastává nový případ. Formálně je C/E síť definovaná jako síť N = (P, T, F ), kde podmnožina c ⊆ B se nazývá případ. Nechť e ∈ E a c ⊆ B. Událost e je c-proveditelná, jestliže • e ∈ c ∧ e• ∩ c = ∅. Nechť e ∈ E, c ⊆ B a nechť e je c-proveditelná. Případ c0 = (c \• e) ∪ e• se nazývá následným případem c při události e. Píšeme c[e > c0 (Češka et al, 2006). 2.2.3

P/T Petriho sítě

Síť sestavená na bázi míst a přechodů se nazývá P/T Petriho síť (Place-Transition). Na rozdíl od typu C/E může počet značek v jednom místě nabývat celé nezáporné hodnoty. Ve formální definici zavádíme symbol ω, který vyjadřuje neomezenou kapacitu místa neboli neomezený počet značek obsažených v místě. Síť P/T je formálně šestice N = (P, T, F, W, K, M0 , jestliže trojice (P, T, F ) je konečná síť, zobrazení W : F → N \ ∪0 je ohodnocení hran grafu sítě určující váhu každé hrany, zobrazení K : P → N ∪ ω specifikuje kapacitu (i neomezenou) každého místa, zobrazení M0 : P → N ∪ ω je počáteční značení míst sítě respektující kapacity míst, tj. ∀p ∈ P : M0 (p) ≤ K(p) (Češka et al, 2006). Přechod v P/T síti ze stavu a) do stavu b), znázorněný na obrázku 2, je určen proveditelností přechodu a pravidly pro následné značení po provedení přechodu. Formální definice pravidel pro přechody uvádí (Češka et al, 2006), na tomto místě

2.2


12

Obr. 2: Provedení kroku v P/T síti

zmíněny nebudou. Pro účel této práce je důležitější grafická reprezentace P/T sítí, určena následujícím výčtem konvencí: • • • •

Hrana f ∈ F je popsána ohodnocením W (f ) pouze v případě W (f ) ≥ 1. Kapacita místa p ∈ P je popsána ve tvaru κ = K(p). Neoznačená kapacita místa p znamená κ = ω. Hodnota značení místa p je vykreslena počtem černých teček uvnitř místa p, případně číslem M (p), je-li tato hodnota obtížně zobrazitelná tečkami, nebo symbolem ω.

2.2.4

Podtřídy P/T sítí

Podtřídy mají vyšší rozhodovací mocnost a nižší modelovací mocnost než vlastní P/T Petriho sítě. Stavové stroje, ekvivalentní s konečnými automaty, tvoří nejjednodušší podtřídu Petriho sítí. Dalšími podtřídami jsou značené grafy a Petriho sítě s volným výběrem, které umožňují, na rozdíl od předchozích podtříd, modelovat konflikty i paralelismus. 2.2.5

Rozšíření Petriho sítí

Rozšíření mají vyšší modelovací mocnost (až na úrovni Turingových strojů) než samotné Petriho sítě, mají výrazně nižší rozhodnutelnost problému analýzy. Petriho sítě s inhibitory obsahují tzv. množinu inhibičních hran, které ovlivňují proveditelnost přechodu, na obrázku 3 je inhibitor znázorněn jako hrana ukončená kroužkem. Výpočetní síla Petriho sítí s inhibitorem je ekvivalentní se silou Turingových strojů. Mezi další rozšíření patří časové a časované Petriho sítě (TPN), Stochastické Petriho sítě a Petriho sítě vyšší úrovně. 2.2.6

Petriho sítě vyšší úrovně

K nejrozšířenějším třídám Petriho sítí vyšší úrovně patří Pr/T Petriho sítě (Predicate/Transitions Petri nets), jejich podtřídy barvené Petriho sítě (CPN), hierarchické barvené Petriho sítě (HPN) a objektové Petriho sítě (OOPN). Barvené Petriho sítě přinášejí možnosti pro snadný popis manipulace s různými datovými typy,

2.2


13

Obr. 3: Petriho síť s inhibiční hranou

rozšiřují P/T sítě o definici množin barev, spojení značek s určitou barvou a o manipulaci barev značek při průchodu přechody pomocí tzv. inskripčních jazyků, pomocí nichž jsou definovány podmínky nad barvami manipulovaných značek (Češka et al, 2006). CPN jsou mnohdy v praxi upřednostňovány před jinými sítěmi, a to například v oblastech komunikačních protokolů a sítí (viz obrázek 4), software, hardware, řídících systémů či vojenských systémů. Existuje řada rozšíření CPN (např. rozšíření o fyzický čas, stochastickou simulaci či různé způsoby strukturování), která jsou spojena s různými nástroji pro analýzu CPN v praxi.

Obr. 4: Barvená Petriho síť – jednoduchý komunikační protokol

Základem inskripčního jazyka je zavedení konstant a proměnných pro jednotlivé hrany. Možnosti jsou dále rozšiřovány zavedením výrazů nad proměnnými, typováním míst pomocí přiřazení množin barev a zavedením stráží k přechodům, které omezují proveditelnost přechodů na základě vyhodnocení Booleovských podmínek přiřazených ke hranám. Formální definice syntaxe a sémantiky CPN, překračující rámec této práce, je uvedena v (Češka et al, 2006).

2.2


2.2.7

14

Podnikové procesy a workflow

Pro analýzu či modelování podnikových procesů můžeme s výhodou použít Petriho sítí. Příkladem může být libovolná výrobní linka, která funguje podle určitých pevně daných pravidel. V průběhu činnosti výrobní linky dochází k vyhodnocování provozních údajů, které tvoří vstup pravidel. Na základě vyhodnocení pravidel dojde k nastavení dalšího chování výrobní linky. Podobně lze modelovat i nevýrobní procesy, například tok obchodních či účetních dokumentů v instituci. Dokument je například nejprve převeden do elektronické podoby, je zaslán asistentce, která rozhodne na základě druhu dokumentu o jeho předání povolaným osobám, které jsou povinné doplnit k dokumentu určité provozní informace. Takto je může být dokument zpracován několika pracovníky různých rolí a nakonec je archivován. V obchodních procesech můžeme v poslední době podle (Dong a Chen, 2005) pozorovat následující trendy: • • • •

roste jejích důležitost, jsou předmětem častých změn, roste jejich složitost, zvyšuje se jejich počet.

Vzniká tedy potřeba efektivního řízení stávajících procesů a potřeba flexibility změn procesů či tvorby nových procesů bez nutnosti složitých zásahů do stávajících procesů. V této souvislosti jsou uplatňovány tzv. Business Process Reengineering (BPR) a Continuous Process Improvement (CPI). BPR je cíleným postupem, který optimalizuje podnikové procesy tak, aby přinášely optimální efekty při minimální spotřebě podnikových zdrojů. Důsledkem BPR jsou změny v organizační struktuře podniku. Smyslem CPI je neustálé zlepšování stávajících procesů vzhledem k probíhajícím změnám způsobeným vlivem vnějších i vnitřních faktorů (Gála, 2006). Obchodní procesy jsou často nasazovány do produkčního prostředí bez řádného testování a simulace, proto dochází k logickým chybám, uváznutí (deadlock), či vzniku úkolů, které není možné vyřešit. Zavedení testování a simulace může předejít řadě chyb a v konečném důsledku znamená snížení nákladů podniku. Petriho sítě, zvláště pak jejich varianty CPN, jsou vhodným nástrojem pro formální a neformální (grafickou) reprezentaci obchodních procesů, která vede k možnosti analyzovat, simulovat, a validovat obchodní procesy. Nástroje pro řízení obchodních či výrobních procesů se nazývají workflow management systems. Řada workflow systémů pracuje s interními zápisy procesů, které neumožňují provádění simulací a analýz. Existují proto nové přístupy, které se zabývají mapováním workflow procesů do podoby Petriho sítí, takzvané workflow nets (WF-nets) či time WF-nets (TWF-nets). Formálně je WF-net Petriho sítí P N = (P, T, F ), která splňuje tyto podmínky (Dong a Chen, 2005): 1. PN obsahuje dvě zvláštní místa: i a o . Místo i je vstupním místem (source place): •i = ∅ , místo o je výstupním místem (sink place): •o = ∅ .

2.2


15

2. Pokud je do PN, která spojuje místo o s místem i, vložen přechod t∗ (tj. •t∗ = o a zároveň t ∗ • = i), potom je výsledná Petriho síť silně souvislá (strongly connected). Dále je formálně definovaná tzv. rozšířená WF-síť (Extended WF-net) jako P¯T = (P¯ , T¯, F¯ ), ke které přidáme navíc přechod t∗, který propojí místo o s místem i podle definice: P¯ = P, T¯ = T ∪t∗, F¯ = F ∪< o, t∗ >, < t∗, i > (Dong a Chen, 2005). Podle architektury pro modelování podniku CIMOSA1 existuje několik procesních struktur, které můžou být převedeny do odpovídající Petriho sítě. Pro vytvoření struktur je nutné vycházet ze dvou kombinačních pravidel (Dong a Chen, 2005): 1. Souběžné aktivity zahájené rozdělujícími pravidly (nebo OR rozdělením) nesmí být spojeny slučujícími pravidly (či AND spojením). 2. Alternativní aktivity zahájené pravidly s podmínkami (nebo OR rozdělením) nesmí být doplněné slučujícími pravidly (nebo AND spojením). Aplikací výše uvedených pravidel získáme následující množinu struktur (Dong a Chen, 2005): 1. Paralelní struktura: rozdělení pomocí AND užité pro zahájení souběžné struktury a spojení AND užité pro ukončení souběžné struktury (obrázek 5f). 2. Výběrová struktura: rozdělení pomocí OR užité pro výběr jedné z několika struktur, spojení OR užité k ukončení těchto struktur (obrázek 5e). 3. Sekvenční struktura: následné struktury a povinně následné struktury (obrázek 5c). 4. Opakovací struktury: standardní o cykly (obrázek 5d). 5. Start: pravidla, která spouštějí proces (obrázek 5a). 6. Konec: pravidla, která ukončují proces (obrázek 5b).

Obr. 5: CIMOSA struktury vyjádřené pomocí Petriho sítí s volným výběrem 1

Computer Integrated Manufacturing Open System Architecture

2.3

Standardy pro workflow

16

Korektní model obchodního procesu musí splňovat následující požadavky (Dong a Chen, 2005): • free-deadlock: v procesu nesmí nikdy dojít k uváznutí, • omezenost: souvisí s omezenými zdroji, nesmí nikdy dojít k přetečení, • konečné cykly: model nesmí obsahovat nekonečný cyklus, • řádné ukončení: proces, který začíná v místě i musí skončit v místě o provedením posloupnosti obchodních procesů či aktivit. Na základě výše uvedených pravidel můžeme definovat dobře strukturovaný model procesu, který splňuje tyto podmínku: Model procesu je strukturovaný, pokud ověření jeho bezvadnosti má polynomiální časovou složitost a zároveň je model modulární, čitelný a udržovatelný. Podle CIMOSA algoritmu pro modelování obchodních procesů můžeme stanovit pravidla pro tvorbu workflow procesů pomocí Petriho sítí (Dong a Chen, 2005): • Každá podniková funkce (proces či aktivita) je přechodem, každé ukončení aktivity nebo podmínka je místem. • Každý proces obsahuje „Startÿ (source place) a „Konecÿ (sink place). • Spojovací pravidla a upravená vnořená pravidla jsou použity kdykoli v libovolném pořadí. Podle (Dong a Chen, 2005) jsou dále podrobně definovaná spojovací pravidla, vnořená pravidla, upravená vnořená pravidla a clustery. Tyto definice přesahují rozsah této práce.

2.3

Standardy pro workflow

Samotný workflow proces může být zaznamenán různými formami zápisu. Pro jednoduché procesy můžeme použít ústní podání či jednoduchý náčrtek, pro komplexní podnikové procesy je nutné použít komputerizaci procesů. Jako nejvýhodnější se jeví použití zápisu pomocí XML, který přinese řadu výhod od možnosti snadné výměny definic procesů mezi systémy či aplikacemi přes snadnou čitelnost a přehlednost až po možnosti grafické reprezentace XML dat či možnosti práce nad workflow definicemi pomocí databázových systémů. Během posledních několika let vznikla řada standardů, které splňují většinu požadavků kladených na workflow jak z pohledu teorie Petriho sítí, tak z pohledu architektury CIMOSA a dalších přístupů k modelování podniku. Tyto standardy jsou postaveny na jazyku XML a většina z nich umožňuje přehlednou grafickou reprezentaci procesů, která je velmi důležitá při komunikaci s managementem podniku (Zur Muehlen, 2004). 2.3.1

XPDL

Standard byl publikován v roce 2002 jako implementace referenčního modelu WPDL organizace Workflow Management Coalition (WfMC), od té doby byl implementován v řadě open-source projektů. Standard klade důraz na opakovanou použitelnost

2.4

Software pro podporu workflow

17

workflow modelů. Tento standard je nejvíce používaným standardem pro workflow v praxi. Mezi nejznámější společnosti, které implementovali do svých produktů podporu XPDL, patří Adobe, Fujitsu, IBM a Oracle. Poslední specifikace XPDL je ve verzi 2.1., která byla vydaná 10.10.2008. Specifikace a další dokumenty o standardu jsou zdarma dostupné v PDF na webu WfMC (WFMC, 2008). 2.3.2

Wf-XML

Standard specifikuje komunikaci mezi různými systémy ve smyslu vzájemné interakce současně probíhajících procesů. První verze byla publikovaná v roce 1996. Vzájemná komunikace mezi různými systémy je řešená pomocí HTTP protokolu. Tento standard zatím není ve větší míře využit v praxi, protože zatím nevznikl dostatečný tlak pro implementaci součinnosti stávajících workflow systémů (Zur Muehlen, 2004). 2.3.3

OMG Workflow Facility

Organizace Object Management Group (OMG) vyvinula v rámci projektu CORBA (Common Object Request Broker Architecture; standard umožňující spolupráci softwarových komponent psaných v různých programovacích jazycích) součást pro workflow management. Tato součást definuje rozhraní pro výměnu informací o workflow mezi různými programovými systémy, neřeší vnitřní architekturu workflow v jednotlivých aplikacích. Tento standard také není využíván ve větším měřítku z podobných důvodů jako Wf-XML. Zatím neexistuje dostatečná poptávka po interoperabilitě workflow systémů (Zur Muehlen, 2004). 2.3.4

BPML

Specifikace BPML (Business Process Markup Language) je historicky podmnožinou BPEL (Business Process Execution Language), jazyka definujícího interakci mezi webovými službami používanými v podnikovém prostředí. BPEL je označován jako „orchestration languageÿ, je zaměřený na spouštění událostí a procesů, nikoli na jejich ovládání a kontrolu. Samotný jazyk BPML slouží k modelování obchodních procesů. Byl navržen pro implementaci v produktech firem IBM a Microsoft. Plánovaná implementace však neproběhla, a tak neexistuje téměř žádná kompletní implementace jazyka BPML. Jeho vývoj byl ukončen 22.1.2008, kdy jazyk převzala organizace OMG, jazyk byl přejmenován na BPDL, pod tímto názvem je nadále vyvíjen (Zur Muehlen, 2004).

2.4


V této kapitole jsou uvedeny softwarové nástroje, podporující standard XPDL. Jedná se o open-source nástroje určené pro usnadnění vývoje a provozu workflow aplikací:

2.4


2.4.1

18

Enhydra JaWE, Enhydra Shark

Grafický editor Enhydra JaWE napsaný v jazyce Java podporuje standard XPDL verze 1, je prvním grafickým editorem, který podporuje standard XPDL. Umožňuje upravovat, zobrazovat a validovat workflow procesy. Workflow server Enhydra Shark je vytvořený také v jazyce Java, podporuje definice workflow procesů podle standardu XPDL. Enhydra Shark může být začleněn v rámci libovolného projektu jako knihovna, framework či webová služba. 2.4.2

Workflow::Wfmc

Workflow engine vytvořený v programovacím jazyce Perl, implementuje standard XPDL verze 2. Implementuje podporu pro vstupní a výstupní parametry workflow, směrování, call-back funkce a podmínky. Zatím nepodporuje podprocesy a výjimky. 2.4.3

Bonita

Workflow engine napsaný v jazyce Java, řešení je postaveno na základě PVM (The Process Virtual Machine2 ). 2.4.4

JawFlow

Framework pro propojení GUI klientských aplikací postavených na komponentách Swing s centrálním transakčním serverem, jádrem frameworku je Workflow Manager podporující standard XPDL. 2.4.5

Open Business Engine

Modulární workflow engine napsaný v jazyce Java, implementuje standard XPDL, je určený pro samostatný provoz v produkčním prostředí i pro zabudování do jiného řešení formou knihoven. 2.4.6

WfMOpen

Knihovna pro podporu workflow napsaná v jazyce Java, podporuje standardy WfMC a OMG, splňuje požadavky na CORBA services3 . 2

Knihovna pro tvorbu a vykonávání procesů definovaných pomocí grafů. Slouží jako základ pro implementaci workflow nebo BPM. Informace o knihovně jsou dostupné na webové stránce 3 Standard organizace OMG umožňující spolupráci a komunikaci různých softwarových komponent vytvořených v různých programovacích jazycích, které fungují na více počítačích.

2.5

Analýza současné situace na trhu ERP systémů

2.5 2.5.1

19

Analýza současné situace na trhu ERP systémů Metodika analýzy a zdroje informací

Analýza trhu se opírá zejména o informace ze Zpravodajského portálu časopisu IT systems4 , dále o výzkumy a data Českého statistického úřadu5 a o data prezentovaná výrobci či prodejci. Pro výzkum vlastních produktů je stanovena řada klasifikačních kritérií, na základě kterých je každý ze zkoumaných ERP systémů hodnocen. Nad ohodnocenými kritérii je pak prováděn výpočet základních statistických ukazatelů a rozdělení systémů do tříd. Výzkum se pokouší odpovědět jak na ekonomické otázky spojené s nákupem a nasazením ERP systémů, tak na technické otázky související s provozem, údržbou a správou ERP systémů v produkčním prostředí. Výzkum se zabývá také technologickými aspekty jednotlivých ERP systémů. Výzkum bude ve své první části statisticky zkoumat fakta, druhá část výzkumu bude věnována podrobnější charakteristice konkrétních produktů, vybraných dle stanoveného klíče. Cílem výzkumu je podat celkový pohled na aktuální stav tržního koše ERP systémů. Budou prezentovány údaje o využívání ERP systémů v českých podnicích a budou nastíněny trendy ve vývoji chápání ERP systémů v podnikové sféře. Výsledky výzkumu můžou sloužit jako faktory pro rozhodování o koupi či vytvoření nového ERP systému pro konkrétní podnik střední velikosti. 2.5.2

Klasifikační kritéria

Každý ERP systém je hodnocen řadou kritérií či klasifikován podle určených klíčů. Pro tento výzkum budou podstatná následující klasifikační kritéria: • Průmyslové odvětví: – potravinářský a nápojový průmysl, – stavebnictví – textilní a obuvnický průmysl, – strojírenský průmysl, – automobilový průmysl, – hutní průmysl, – chemický a farmaceutický průmysl. • Podpora pro specializované moduly: – elektronický nákupu a prodeje přes internet (B2B a B2C); – řízení produktových dat (Product data management, PDM) a řízení životního cyklu produktu (Product lifecycle management, PLM); 4 CCB spol. s r.o. . System On Line : Zpravodajský portál časopisu IT systems [online]. c2009 [cit. 2009-04-18]. Dostupný z WWW: . ISSN 1802-615. 5 Český statistický úřad. Český statistický úřad [online]. c2009 [cit. 2009-04-18]. Dostupný z WWW: .

2.5

•

• •

•


20

– pokročilé plánování (Advanced planning & scheduling, APS) a řízení dodavatelského řetězce (Supply chain management, SCM); – řízení podnikových aktiv (Enterprise asset management, EAM) a řízení údržby; – řízení projektů (Project management); – řízení jakosti (Quality management, QM); – řízení vztahů se zákazníky (Customer relationship management, CRM); – datový sklad (Data warehouse, DW) a manažerský informační systém (Management information system, MIS). Mezinárodní aspekty: – podpora mezinárodních účetních norem: IAS (International Accounting Standards), IFRS (International Financial Reporting Standards), GAAP (Generally Accepted Accounting Principles); – účtování v cizích měnách a kurzové rozdíly. Certifikace produktu (ISO, ISVS a další) Informace o uživatelích a nasazení produktu: – velikost podniku, pro kterou je daný systém určen: ∗ malé podniky (roční obrat do 100 mil. Kč nebo 10 až 49 zaměstnanců), ∗ střední podniky (roční obrat od 100 mil. Kč do 1 mld. Kč nebo 50 až 249 zaměstnanců), ∗ velké podniky (roční obrat nad 1 mld. Kč nebo 250 a více zaměstnanců), – reference produktu: ∗ počet instalací produktu; ∗ odvětví, ve kterých má systém reference; ∗ průměrná doba implementace produktu pro střední podnik; ∗ počty uživatelů systémů, které jsou nasazeny v produkčním prostředí. Technická data produktu: – systémová architektura, – podpora mobilních technologií, – podpora single sign-on, – podpora collaborative business, – podpora komunikačních protokolů a standardů, – podporované operační systémy, – podporované databázové systémy, – integrační platforma (middleware).

2.5


2.5.3

21

Souhrnné charakteristiky ERP systémů

Na českém trhu existuje celkem 124 ERP systémů od různých výrobců z ČR i ze zahraničí. Následující souhrnné tabulky obsahují relativní četnost výskytu vzhledem ke 124 zkoumaným ERP systémům. Klasifikaci ERP systémů dle konkrétních odvětví průmyslu shrnují tabulka 1 a tabulka 2. Nejvíce ERP systémů je navrženo pro použití v oblasti strojírenského, potravinářského, nápojového a automobilového průmyslu. Nejmenší podíl ERP systémů je navržen pro průmysl chemický, farmaceutický a hutní. Tab. 1: Určení ERP systémů pro průmyslová odvětví

Relativní četnost produktů určených pro odvětví strojírenský 76,6 % potravinářský a nápojový 66,9 % automobilový 66,1 % textilní a obuvnický průmysl 61,3 % stavebnictví 59,7 % chemický a farmaceutický 58,9 % hutní 53,2 % Odvětví (průmysl)

Tab. 2: Reference ERP systémů v průmyslových odvětvích

Relativní četnost produktů s referencemi v odvětví výrobní podniky 94,4 % obchod 91,1 % distribuce 83,1 % finance 50,8 % utility 49,2 % veřejný a státní sektor 42,7 % Odvětví

Podle tabulky referencí jsou ERP systémy nejčastěji používaný ve výrobních podnicích a dále v podnicích zaměřených na obchod a distribuci. Naopak nejméně jsou ERP systémy využívány ve finančnictví, v oblasti utilit, ve veřejném a vládním sektoru. Situaci na trhu z pohledu podpory specializovaných modulů charakterizuje tabulka číslo 3. Datový sklad a MIS patří mezi nejčastější moduly. Jedná se o nástroje kategorie business intelligence, slouží k vyhodnocování a analýze velkých objemů dat. Tyto nástroje využívá zejména vyšší management pro strategické rozhodování a plánování.

2.5


22

Nástroje CRM jsou určené pro podporu řízení vztahů se zákazníky, často je úzce propojen se systémy pro správu dokumentů (DMS, Document management system), se systémy elektronické pošty (MUA, MTA) a se systémy VoIP. Moduly B2B a B2C komputerizují obchodní vztahy mezi podnikem a dodavateli či podnikem a odběrateli z řad podniků a firem (B2B, Business-to-business), dále komputerizují obchodní vztahy mezi podnikem a koncovým zákazníkem (B2C, Business-to-customer či Business-to-consumer), který je spotřebitelem produktu. Běžně jsou pro vzájemné obchodní vztahy používané i další zkratky: • • • • •

B2G: business-to-government; vztahy mezi podnikem a vládní organizací; G2B: government-to-business: vztahy mezi vládní organizací a podnikem; G2C: government-to-citizen: vztahy mezi vládní organizací a občanem; C2B: consumer-to-business: vztahy mezi spotřebitelem a podnikem; C2C: consumer-to-consumer: vztahy mezi spotřebiteli.

Moduly EAM podporují řízení vnitropodnikových aktiv s cílem snížit náklady na kapitál, snížit provozní náklady a zvýšit ukazatel ROA (return on assets, rentabilita celkového vloženého kapitálu). Moduly APS podporují výrobní procesy s ohledem na efektivní alokaci vstupů nutných k uspokojení poptávky po výsledném produktu. Jsou úzce propojeny s moduly SCM určenými ke správě sítě dodavatelů. Správa pokrývá veškerý pohyb a skladování materiálních vstupů, jejich úpravy a přeměny až do podoby výsledného produktu. Moduly PDM a PLM jsou na trhu ERP systémů zatím nejméně rozšířené, pokrývají řízení a správu veškerých informací o vlastním produktu a o životním cyklu daného produktu. Informace o produktu zahrnují zejména technické specifikace pro výzkum a výrobu. Životním cyklem produktu se rozumí tyto fáze: • • • •

koncepce produktu (fáze myšlenek, představ a plánů) návrh produktu (fáze analýzy, projektování, vývoje, testování a validace) realizace (fáze výroby a prodeje) služby (podpora, servis, pozastavení, vyřazení, recyklace, likvidace)

Připravenost k použití v prostředí mezinárodních a nadnárodních organizací znázorňuje tabulka číslo 4. Zde jsou klíčové podmínky účtování v cizích měnách a podpora pro kurzové rozdíly. Tyto podmínky splňuje většina zkoumaných produktů. Při výběru ERP systému je jedním z důležitých kritérií certifikace a audit produktů. Toto hledisko shrnuje tabulka číslo 5. Poměrně malý podíl produktů je certifikován normou ISO. Zde se jedná zejména o následující normy: • ISO 9000: řízení jakosti; • ISO 9001: řízení jakosti, rozšiřuje normu ISO 9000. Další certifikací je tzv. certifikace ISVS (Informační systém veřejné správy). Do 1. ledna 2007 bylo pro dodavatele informačních systému pro veřejnou správu nutností prokázat ve výběrovém řízení atestaci podle standardu ISVS. Od 1. ledna 2007 musí provádět potřebnou atestaci přímo orgány veřejné správy. Význam standardu

2.5


23

Tab. 3: Podpora specializovaných modulů

Modul Relativní četnost produktů Datový sklad a MIS 81,5 % CRM 80,6 % B2B a B2C 78,2 % Řízení projektů 59,7 % Řízení jakosti 58,9 % EAM 52,4 % APS a SCM 48,4 % PDM a PLM 38,7 % Tab. 4: ERP systémy v globálním prostředí

Vlastnost Relativní četnost produktů Účtování v cizích měnách a kurzové rozdíly 97,6 % Podpora mezinárodních účetních norem 65,3 % ISVS popisuje následující úryvek z webového portálu ISVS. Metodický pokyn má sloužit pracovníkům orgánů veřejné správy i společností, které se zabývají vývojem informačních systémů pro orgány veřejné správy či dodávají služby v této oblasti, aby mohli snáze určit, zda je určitý informační systém informačním systémem veřejné správy ve smyslu zákona o ISVS6 . Velký podíl informačních systémů na trhu má ve svém popisu informaci o provedeném auditu. U některých produktů je upřesněný audit na účetní audit, ale není přesně jasné, jaký audit proběhl a podle jaké metodiky proběhl. Informace o podílu informačních systémů, které podléhají auditu, je proto zavádějící a nemá vypovídající hodnotu. Tab. 5: Certifikace a audit ERP systémů

Certifikace/audit Relativní četnost produktů Certifikace produktu či provedené audity 68,5 % Certifikace ISO 13,7 % Certifikace ISVS 2,4 % Účetní audit 6,5 % Tabulka číslo 6 znázorňuje souvislosti mezi velikostí podniku, relativní četností určení produktu pro konkrétní velikost podniku, průměrnou dobou implementace 6 ISVS.CZ - Informační Systémy Veřejné Správy : Metodika/atestace [online]. c2009 [cit. 200904-25]. Dostupný z WWW: . ISSN 1802-6575.

2.5

24


produktů v dané kategorii a průměrným počtem uživatelů produktu. Nejvyšší průměrná doba implementace v délce 22,2 týdnů platí pro produkty určené středním a velkým podnikům. Produkty v této kategorii mají samozřejmě nejvyšší průměrný počet uživatelů (655). Nejkratší doba implementace náleží produktům, které jsou určeny pouze pro malé podniky. Produkty na trhu jsou nejčastěji určené pro všechny velikosti podniků (podíl v tržní nabídce 59,7 %), průměrná doba jejich implementace je 15,1 týdnů. Tab. 6: Klasifikace ERP systémů dle velikosti podniku

malý střední velký průměrná doba rel. četnost podnik podnik podnik implementace ano ano ne ano

ano ano ano ne

ano ne ano ne

59,7 % 21,8 % 15,3 % 2,4 %

15,1 10,5 22,2 4,3

týdnů týdnů týdnů týdnů

průměrný počet uživatelů 231 35 655 8

Následující zkoumání a hodnocení je věnováno technickým a technologickým aspektům z hlediska softwarového a systémového inženýrství. Z tabulky číslo 7 jasně vyplývá většinové užití třívrstvé a vícevrstvé architektury. Pouhých 7,3 % produktů využívá dvouvrstvou systémovou architekturu, tzv. těžkého klienta. Velké množství produktů podporuje mobilní technologie, což odpovídá současným trendům růstu využívání mobilních zařízení (mobilní telefony, PDA, MDA). Poměrně zajímavým údajem je menšinová podpora tzv. single sign-on (SSO). Jedná se o podporu pro centrální řízení uživatelských účtů, ve většině případů pomocí systémů Kerberos či LDAP. S rostoucím počtem uživatelů a s rostoucím počtem informačních systémů v podniku značně rostou náklady na správu uživatelských účtů v jednotlivých systémech, a proto je podpora single sign-on strategicky nezbytná. Nástroje a podporu pro tzv. collaborative business (C-Bussiness) obsahuje pouhých 31,5 % produktů. Collaborative business zahrnuje nástroje pro elektronickou komunikaci mezi podniky, většinou formou tzv. EDI (electronic data interchange, elektronická výměna dat). Jedná se o určité standardy (ad-hoc či de-jure), které respektují oba komunikující podniky. Mezi tzv. de-jure standardy patří: • UN/EDIFACT: jediný mezinárodní standard, v praxi celosvětově využíván s výjimkou Severní Ameriky; • ANSI ASC X12: standard užívaný převážně v Severní Americe; • TRADACOMS: využíván zejména v obchodních společnostech ve Velké Británii; • ODETTE: využíván zejména v Evropském automobilovém průmyslu. Výsledky zkoumání hlediska podporovaných platforem shrnují tabulky číslo 8 a 9. Téměř polovinu produktů je možné provozovat na platformách Windows i Unix.

2.5


25

Tab. 7: Technické a technologické vlastnosti produktů

Technická vlastnost Relativní četnost produktů 2-vrstvá systémová architektura 7,3 % 3- a více-vrstvá systémová architektura 92,7 % podpora mobilních technologií 60,5 % podpora single sign-on (SSO) 35,5 % podpora collaborative business 31,5 % Na druhém místě v žebříčku podporovaných operačních systémů je výhradní podpora platformy Windows. Množství produktů, které je nutné provozovat výhradně na platformě Unix či na jiných platformách je zanedbatelné. Ve zkoumaných ERP systémech je jako relační databázový systém nejčastěji použit systém Microsoft SQL Server. Druhé místo zaujímá systém Oracle. Další otevřené i proprietární databáze jsou podporovány jen okrajově. Tab. 8: Operační systémy ERP

Relativní četnost produktů Windows a Unix 47,6 % Pouze Windows 45,2 % Pouze Unix 2,4 % Pouze ostatní platformy (OS/400, i5/OS, Progress) 4,0 % Operační systém

Z tabulky číslo 10 vyplývá míra využití nástrojů B2B a B2C jak přes web, tak díky EDI. Nástroje používají zejména velké podniky, přičemž objem nákupů i prodejů uskutečněných přes EDI je vyšší než objem nákupů a prodejů uskutečněných přes web. Použití webu na úkor EDI je patrné pouze v kategorii nákupů malých podniků. Prodeje malých podniků jsou realizovány častěji přes EDI. Obecně pro všechny podniky i formy platí vyšší podíl nákupů a nižší podíl prodejů. Tabulka číslo 11 řadí sestupně podíl na celkových elektronických nákupech/prodejích podniků v ČR za rok 2007 podle oborové klasifikace činnosti (OKEČ). Nejvyšší podíl (větší než 20 %) existuje v oborech maloobchod, činnosti v oblasti výpočetní techniky, prodej a oprava motorových vozidel a zpracovatelský průmysl. Nejmenší podíl (menší než 5 %) existuje v oborech ubytování, stavebnictví a činnosti v oblasti nemovitostí. V kategorii nákupů převažuje napříč obory EDI (53 % oborů), v kategorii prodejů také převažuje napříč obory EDI (60 % oborů). Míru použití manažerských informačních systémů (MIS) v českých podnicích za rok 2008 shrnují tabulky číslo 12 a číslo 13 nejprve podle velikosti podniku, potom podle OKEČ. Z tabulky vyplývá, že ERP systémy i ostatní MIS jsou používány zejména ve velkých a středních podnicích. Tento závěr doplňují a podporují data

2.5


26

Tab. 9: Databázové systémy ERP

Databázový systém Relativní četnost produktů MS SQL 50,8 % Oracle 45,2 % DB2 9,7 % Informix 7,3 % Sybase 5,6 % Progress 3,2 % Firebird 2,4 % MAX DB 2,4 % PostgreSQL 2,4 % DBF 2,4 % AIX 1,6 % DB/400 1,6 % Tab. 10: B2B a B2C: uskutečněné nákupy a prodeje dle velikosti podniku; podíl na celkových nákupech/prodejích podniku

Velikost podniku

Nákupy Prodeje Celkem Web EDI Celkem Web EDI malé (10-49 zam.) 12,0 % 6,3 % 5,7 % 7,0 % 3,0 % 4,0 % střední (50-249 zam.) 16,3 % 5,7 % 10,6 % 9,8 % 2,2 % 7,6 % velké (250 a více zam.) 19,8 % 4,0 % 15,9 % 18,8 % 4,4 % 14,3 % z tabulky číslo 6, která podává souhrnný pohled na nabídku ERP systémů z hlediska jejich vhodnosti pro danou velikost podniku. Nejvyšší podíl použití ERP (větší než 20 %) existuje v oborech činnosti v oblasti výpočetní techniky, pošta a telekomunikace, velkoobchod, výroba a rozvod elektřiny, plynu a vody. Nejmenší podíl (menší než 5 %) existuje v oboru kulturní, sportovní a ostatní rekreační činnosti. Nejvyšší podíl použití CRM (větší než 40 %) existuje v oborech činnosti v oblasti výpočetní techniky, pošta a telekomunikace, peněžnictví a pojišťovnictví. Nejmenší podíl (menší než 10 %) existuje v oboru stavebnictví. Nejvyšší podíl použití SCM (větší než 3 %) existuje v oborech prodej a oprava motorových vozidel, pošta a telekomunikace, velkoobchod. Nejmenší podíl (menší než 0,5 %) existuje v oborech činnosti v oblasti nemovitostí, kulturní, sportovní a ostatní rekreační činnosti. SCM systémy nejsou vůbec využívány v oblasti audiovizuální činnosti. Z tabulky číslo 13 vyplývá, že podniky v ČR (bez ohledu na velikost) pořídily na trhu nejčastěji samostatné CRM systémy. Nejčastější instalace CRM systémů

2.5

27


Tab. 11: B2B a B2C: uskutečněné nákupy a prodeje dle ekonomické činnosti podniku; podíl na celkových nákupech/prodejích podniků v ČR za rok 2007

Ekonomická činnost maloobchod činnosti v oblasti výpočetní techniky prodej a oprava motorových vozidel zpracovatelský průmysl velkoobchod pošta a telekomunikace ostatní podnikatelské činnosti doprava a skladování audiovizuální činnosti výroba a rozvod elektřiny, plynu a vody kult., sport. a ostatní rekreační činnosti ubytování stavebnictví činnosti v oblasti nemovitostí ostatní činnosti

Nákupy Prodeje Celkem Web EDI Celkem Web 27,6 % 6,6 % 20,9 % 2,1 % 0,8 %

EDI 1,3 %

25,6 % 14,9 % 10,7 %

8,1 %

3,9 %

4,2 %

23,7 % 11,3 % 12,4 %

5,3 %

3,6 %

1,7 %

20,3 % 19,8 % 13,2 %

3,8 % 16,5 % 7,6 % 12,3 % 2,4 % 10,8 %

22,9 % 15,6 % 9,1 %

5,2 % 17,8 % 3,4 % 12,2 % 0,8 % 8,3 %

8,7 %

5,4 %

3,3 %

5,5 %

1,5 %

4,0 %

8,0 % 6,6 %

3,3 % 1,9 %

4,7 % 4,7 %

9,9 % 1,9 %

5,4 % 1,2 %

4,5 % 0,7 %

5,4 %

1,1 %

4,3 %

2,5 %

1,4 %

1,1 %

5,2 %

3,7 %

1,6 %

4,2 %

3,3 %

0,9 %

4,7 % 4,2 %

3,6 % 2,8 %

1,2 % 1,5 %

16,7 % 10,1 % 0,9 % 0,4 %

6,6 % 0,6 %

2,5 %

1,5 %

1,0 %

0,9 %

0,4 %

0,5 %

2,1 %

1,6 %

0,5 %

2,0 %

0,7 %

1,3 %

jsou pak dle tabulky číslo 12 provedeny ve středních podnicích a malých podnicích. Nejlépe vybavenými obory v oblasti manažerských informačních systémů jsou pošta a telekomunikace, činnosti v oblasti výpočetní techniky. Nejméně vybavené jsou obory zabývající se rekreačními činnostmi, stavebnictví a nemovitostmi. Časové řady v tabulce číslo 14 naznačují tendenci růstu elektronických nákupů a prodejů. V prodejích došlo v roce 2005 k výjimečnému poklesu celkových elektronických prodejů o 1,3 % (z toho pokles prodejů přes web o 0,3 %, pokles prodejů přes EDI o 1,0 %). V následujícím roce potom došlo k růstu celkových elektronických prodejů o 1,4 % (z toho růst prodejů přes web o 0,5 %, růst prodejů přes EDI o 0,9 %) zejména díky růstu prodejů přes EDI. K největší změně v růstu elektronických nákupů a prodejů došlo v roce 2007, kdy celkové nákupy vzrostly o 6,6 % zejména díky rostoucím nákupům přes web (růst o 5,7 %) a celkové prodeje vzrostly o 5,6 % díky prodejům přes web (růst o 6,9 %). Prodeje přes web rostly v roce 2007 na úkor prodejů přes EDI, které poklesly o 1,3 %.

2.6

28

Vyhodnocení analýzy trhu ERP systémů

Tab. 12: Podniky v ČR používající manažerské IS; velikosti podniku za rok 2008

Velikost podniku ERP CRM SCM malé (10-49 zam.) 8,7 % 15,0 % 1,2 % střední (50-249 zam.) 29,6 % 34,1 % 1,3 % velké (250 a více zam.) 58,0 % 45,2 % 4,2 % Tab. 13: Podniky v ČR používající manažerské IS; podle ekonomické činnosti za rok 2008

Ekonomická činnost činnosti v oblasti výpočetní techniky pošta a telekomunikace velkoobchod výroba a rozvod elektřiny, plynu a vody zpracovatelský průmysl peněžnictví a pojišťovnictví audiovizuální činnosti maloobchod činnosti v oblasti nemovitostí prodej a oprava motorových vozidel doprava a skladování ubytování ostatní podnikatelské činnosti stavebnictví kult., sport. a ostatní rekreační činnosti ostatní činnosti

2.6

ERP 28,4 % 25,8 % 22,3 % 21,8 % 19,6 % 17,7 % 11,3 % 10,6 % 10,6 % 9,6 % 8,0 % 7,4 % 7,2 % 6,2 % 4,5 % 2,0 %

CRM SCM 48,4 % 1,8 % 46,4 % 4,3 % 25,8 % 3,1 % 26,7 % 1,7 % 20,7 % 0,8 % 44,5 % 1,9 % 14,0 % 0,0 % 14,8 % 2,0 % 18,7 % 0,2 % 27,8 % 5,1 % 13,7 % 0,5 % 19,4 % 0,5 % 18,2 % 0,2 % 9,7 % 1,5 % 13,5 % 0,2 % 8,3 % 0,0 %


Výše uvedená analýza bude v následujícím textu vyhodnocena z pohledu konkrétní výrobně-obchodní firmy, která se rozhoduje mezi nákupem produktu na trhu a vytvořením nového informačního systému na míru. Pro podnik platí pro rozhodování o pořízení ERP systému následující omezující podmínky: • v podniku je nasazen pro účetní agendu systém Navision; • systém Navision nebude využit jako ERP systém (přesto, že existuje možnost rozšíření o potřebné moduly); • ERP systém nebude obsahovat účetní agendu, musí sdílet informace se systémem Navision; • ERP systém bude zahrnovat cenné firemní know-how; • ERP systém musí fungovat v libovolném počtu jazykových mutací;

2.6

29


Tab. 14: Časové řady uskutečněných nákupů a prodejů; podíl na celkových nákupech/prodejích podniků v ČR

Rok 2002 2003 2004 2005 2006 2007 • • • • •

ERP ERP ERP ERP ERP

systém systém systém systém systém

Nákupy Celkem Web 3,7 % 1,9 % 6,4 % 2,7 % 7,1 % 3,3 % 9,8 % 2,9 % 10,6 % 5,7 % 17,2 % 11,4 % musí musí musí musí musí

EDI 1,8 % 3,7 % 3,8 % 6,9 % 4,9 % 5,8 %

Prodeje Celkem Web 5,2 % 2,4 % 6,1 % 2,1 % 8,1 % 3,1 % 6,8 % 2,8 % 8,2 % 3,3 % 13,8 % 10,2 %

EDI 2,8 % 4,0 % 5,0 % 4,0 % 4,9 % 3,6 %

podporovat single sign-on; obsahovat podporu pro cizí měny; podporovat zakázkovou hromadnou výrobu; obsahovat moduly PDM, PLM a CRM; mít reference v oblasti obchodu a výroby.

Podle průzkumu vlastností ERP systému, které lze pořídit na českém trhu, vyhovují výše stanoveným požadavkům produkty uvedené v tabulce číslo 15. Tabulky číslo 16 a 17 informují o hlavních referenčních zákaznících, o počtech konzultantů a počtech instalací. Tab. 15: Přehled ERP systémů na českém trhu

Průměrná doba Název Výrobce implementace v týdnech Helios Green LCS International, a.s. 16 i/2 Polynorm Software AG 18 Microsoft Dynamics AX Microsoft s.r.o. 24 Microsoft Dynamics NAV Microsoft s.r.o. 16 QAD Enterprise Applications QAD Inc. 20 SAP All-in-One SAP ČR, spol. s r. o. 28 SAP Business Suite SAP ČR, spol. s r. o. 24 Signys TreSoft s.r.o. 14 Průměrná pořizovací cena nasazení výše uvedených produktů se pohybuje pro střední a velké podniky od 1 milionu Kč. Cena zahrnuje analýzu podnikových procesů a pravidel, přizpůsobení produktu a modulů konkrétnímu podniku, vlastní implementaci a nasazení do produkčního prostředí.

2.6


30

Tab. 16: Přehled ERP systémů na českém trhu - referenční zákazníci

Název

Hlavní referenční zákazníci Ředitelství silnic a dálnic ČR, Euromédia Group, Helios Green Pražské vodovody a kanalizace ZC s.r.o., Jindřichův Hradec, H&D a.s., i/2 Prostějov, GM Electronic, spol. s.r.o. Microsoft Dynamics AX Spolchemie, ČKD, NOWACO Microsoft Dynamics NAV AAA Auto, Mountfield, Auto Palace Praha Madeta Group, United Bakeries, QAD Enterprise Applications Johnson Controls SAP All-in-One Siko koupelny, Rabat ČR, Saar Gummi SAP Business Suite ČEZ, O2, Škoda Auto ELCO s.r.o., Bikers Crown s.r.o., Signys KIS Plus a.s. Tab. 17: Přehled ERP systémů na českém trhu - počty instalací a konzultantů v ČR a SR

Název Počet konzultantů Počet instalací Helios Green 52 270 i/2 neuvedeno neuvedeno Microsoft Dynamics AX 180 110 Microsoft Dynamics NAV 500 950 QAD Enterprise Applications 50 105 SAP All-in-One 77 824 SAP Business Suite 77 824 Signys 5 130 Na základě znalostí o produktech na trhu můžeme říci, že na trhu existuje produkt, který odpovídá potřebám podniku. Podnikové procesy, které daný podnik bude komputerizovat pomocí ERP systému, nejsou klíčovým know-how, jejich únik ke konkurenčním firmám neohrožuje postavení podniku na trhu. Podnik má dostatečné disponibilní kapacity, technologie, metodologie a znalosti pro realizaci projektu ERP systému vlastními prostředky. Hlavní výhodou realizace vlastními prostředky je úspora nákladů na vývoj, správu a implementaci změn v budoucnu. Podstatnou nevýhodou je několikanásobně delší doba implementace oproti tržním produktům. Ve vnitřním prostředí podniku probíhají velmi časté změny, které se přímo dotýkají funkcionality ERP systému.

2.7

2.7

Analýza možností vývoje software na míru

31


V průběhu rozhodování o pořízení ERP systému musí management podniku zvážit možnost vývoje softwaru na míru. Vývoj může být realizován využitím vlastních prostředků či využitím služeb vhodného dodavatele. Pro variantu vývoje vlastními prostředky je nutné zvážit tyto klíčové faktory (Svozilová, 2006): • • • • • • • •

pořizovací náklady a kapitálová náročnost, možnosti integrace do stávajících systémů, disponibilní kapacity pro realizaci, disponibilní technologie, metodologie a znalosti, příspěvek realizace vlastními silami k vytvoření strategické výhody, nároky na řízení, potřeby dalších subdodavatelů, rizika změn ve vnějším i vnitřním prostředí.

Pro variantu vývoje využitím služeb externího dodavatele platí výše uvedené faktory s výjimkou disponibilních kapacit pro realizaci, disponibilních technologií, metodologií a znalostí a nároků na řízení. Pokud realizací projektu dojde k vytvoření strategické výhody, je nutné minimalizovat riziko úniku informací o projektu. Možný únik informací znamená pro podnik ve svém důsledku ztrátu konkurenční výhody a znehodnocení investice. Toto riziko je v případě realizace pomocí vlastních prostředků kontrolovatelné. V případě realizace externím dodavatelem je riziko podstatně vyšší a musí být smluvně ošetřeno definováním sankcí či autorských a majetkových práv k vytvořenému dílu. Ve většině případů není nově pořizovaný ERP systém prvním informačním systémem v podniku. ERP systém by měl v ideálním případě nahradit stávající informační systém importem všech dat stávajícího informačního systému nebo by měl doplňovat stávající informační systém o novou funkcionalitu při sdílení společných dat s existujícím informačním systémem. V žádném případě nesmí dojít k duplikaci dat uživatelským zadáváním jedné a té samé informace do dvou nebo více informačních systémů. Dvojí zadávání dat vede ke značnému poklesu efektivity práce uživatelů a ke zvýšeným nákladům na správu a řízení takovýchto dat. Nároky na řízení projektu jsou spojené s potřebou analýzy a tvorby programátorského zadání. Pokud v podniku existují zaměstnanci, kteří dlouhodobě znají potřeby podniku a jsou schopní podílet se na řízení projektu, analýze a na komunikaci s programátory, podnik může ušetřit jejich zapojením do projektu značné finanční náklady a může zkrátit dobu realizace projektu. Pokud dojde k realizaci projektu vlastními prostředky, projekt musí respektovat předpoklady vývoje změn vnějšího prostředí podniku. Projekt musí respektovat trendy ve vývoji legislativních norem, trendy vývoje technologií a trendy vývoje společnosti. Pokud je systém technicky na tyto změny připraven, jsou minimalizovány náklady na přizpůsobení změnám ve vnějším prostředí. Změny ve vnitřním prostředí podniku nastávají častěji než ve vnějším prostředí. Frekvence změn vnitřního prostředí se liší podle oboru podnikání dané firmy. Pokud

2.7


32

je frekvence změn velmi vysoká, je nutné počítat s dodatečnými náklady pro pravidelné přizpůsobování ERP systému daným změnám. Při velké frekvenci změn se jeví jako úspornější řešení ERP systému vlastními prostředky. Obecně je výhodné řešit potřebu ERP systému tvorbou software na míru, pokud je splněna alespoň jedna z následujících podmínek: • na trhu neexistuje vhodný produkt, který by naplňoval všechny klíčové potřeby a požadavky podniku; • produkt má obsahovat cenné firemní know-how, které je strategickou výhodou, ztráta této výhody buď finančně převyšuje náklady na tvorbu produktu anebo ohrožuje pozici podniku na trhu; • podnik má dostatečné disponibilní kapacity, technologie, metodologie a znalosti pro realizaci. Na základě vyhodnocení všech dostupných informací rozhodl management výrobně-obchodního podniku o implementaci formou vytvoření nového ERP systému na míru. Většina z projektu ERP systému je realizována využitím vlastních prostředků, menší část je realizována využitím služeb externích dodavatelů. Vlastnímu projektu je podrobně věnována následující kapitola číslo 3.

3

PROJEKT PODNIKOVÉHO INFORMAČNíHO SYSTÉMU

3

33

Projekt podnikového informačního systému

Vlastní projekt informačního systému bude rozdělen do řady navazujících fází. Některé z fází se mohou překrývat, realizace některých fází je podmíněna úspěšnou realizací fází předchozích. Těmito základními fázemi jsou: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

3.1

úvodní studie, základní zadání, analýza, plánování zdrojů potřebných k realizaci projektu, volba vhodných metodik a technologií, sestavení datového schématu, návrh aplikační architektury, koncepce a grafický návrh prezentační vrstvy, vlastní programátorské práce, testování, nasazení do produkčního prostředí, správa, údržba a uživatelská podpora.

Úvodní studie

Stěžejním podnikovým procesem ve výrobní firmě je nákup vstupů a jejich zpracování ve výsledný produkt s přidanou hodnotou. Každý výstupní produkt firmy je ve své podstatě originálem a závisí na individuálních požadavcích klienta. Každá zakázka, kterou výrobní firma realizuje, musí co nejpřesněji odpovídat zadání klienta, vstupní materiál a výstupní produkt jsou tedy pro každou zakázku jiné. Každá zakázka musí kromě vlastního výrobního procesu přeměny vstupů na výstupy podstoupit pevně stanovené pořadí administrativních úkonů, jejichž vykonání je podmínkou úspěšně realizované zakázky. Tyto úkony jsou navíc rozvrženy mezi několik pracovníků s různými odpovědnostmi, kteří musí úzce a efektivně spolupracovat. Na každé zakázce se takto podílí produktový manažer (product manager), manažer prodeje (account manager) a pracovník účtárny. Account manager je iniciátorem zakázky, jeho odpovědností je komunikace s klientem a vyjednání cenových podmínek. Product manager je zodpovědný za celý proces přeměny vstupů na výstupy. Product manager na základě informací od account managera stanoví potřebné vstupy spolu s nákupní cenou. Account manager na základě informací od product managera stanový výslednou prodejní cenu. Podobným způsobem probíhá výměna informací mezi product managerem a account managerem do té doby, než je výsledný produkt připraven k prodeji a dodán klientovi. V tomto okamžiku se zakázce věnuje pracovník účtárny, který je zodpovědný za zaúčtování a uzavření zakázky, která je následně archivována. Výrobní firma potřebuje nasadit nový informační systém, který bude komputerizovat výše zmíněné podnikové procesy, bude nástrojem pro operativní činnost

3.2

Základní zadání

34

zpracování jednotlivých zakázek. Nový informační systém bude rovněž sloužit vedoucím pracovníkům ke kontrole práce, ke sledování obchodních výsledků firmy a k plánování. Ve výrobní firmě je pro účetní potřeby nasazen software Navision, nový informační systém musí být s Navision úzce propojen tak, aby nedocházelo k duplikaci objednávek, faktur a dalších dokumentů. Firma stojí před rozhodnutím o konkrétním řešení potřeby nového informačního systému. První možnou variantou řešení je nákup vhodného softwarového řešení na trhu, druhou variantou je vývoj softwaru na zakázku.

3.2

Základní zadání

Management podniku vytvořil prvotní zadání, ze kterého vyplývají klíčové vlastnosti nového informačního systému: • • • • • • • •

plně nahradí stávající informační systém, respektuje základní principy, které jsou zavedeny v původním IS, bude propojitelný (a v budoucnu propojený) se softwarem Navision, rychle reaguje na změny obchodních pravidel, obsahuje funkce pro snadnou tvorbu ekonomických reportů, obsahuje vhodné nástroje pro uživatelskou filtraci a třídění dat, bude rychlejší než stávající informační systém, původní informační systém zůstane po neurčitou dobu dále v provozu kvůli přístupu k historickým datům, • nový informační systém přejímá z původního informačního systému pouze data o kontaktech (adresář dodavatelů a klientů).

3.3

Analýza

Projekt informačního systému navazuje na původní informační systém, který se ukázal jako nevhodný pro další provoz z důvodů obtížné správy, nesnadné implementace změn a rozšíření. Podstatná část analýzy nového informačního systému spočívá v analýze stávajícího řešení, hledání silných a slabých stránek stávajícího řešení. Zbývající část analýzy bude věnována aktuálnímu stavu podnikových procesů, možnému vývoji potřeb podniku v budoucnu a možnostem propojení nového informačního systému se softwarem Navision. 3.3.1

Stávající informační systém

Stávající řešení je vytvořeno jako webová aplikace, použitá architektura je třívrstvá. Prezentační vrstvu aplikace tvoří jazyky HTML, Java Script a CSS. Programový kód aplikační vrstvy je vytvořen pomocí jazyka PHP, část problémů je řešena pomocí XML. Datovou vrstvu představuje relační databázový systém PostgreSQL, část dat je uložena v souborovém systému jako serializované PHP objekty.

3.3

Analýza

35

Mezi hlavní silné stránky stávajícího řešení z pohledu uživatele řadíme: • přehledné a jednoduché uživatelské prostředí, • systém pracuje spolehlivě a bezchybně, • jednotná podoba formulářů a tabulek s daty. Mezi hlavní slabé stránky stávajícího řešení z pohledu uživatele řadíme: • pomalé výpočty klíčových ekonomických reportů, • složitá cesta v navigaci k rutinně používaným nabídkám, • nefunguje export do aplikace MS Excel. Z pohledu analytika a projektanta informačních systémů lze nalézt ve stávajícím řešení následující silné stránky: • vhodné řešení obrazovek, zejména obrazovek pro zadávání klienta či dodavatele (automatické doplnění podrobností o klientovi po zadání jeho jména aj.), • obecné objektové řešení tvorby formulářů a práce s daty. Informační systém obsahuje z pohledu projektanta a analytika řadu slabých míst: • překlepy a gramatické chyby v uživatelském rozhraní, • nejednotné strukturování zdrojového kódu, je patrné programování systému pod časovým tlakem, • zdrojové kódy neobsahují téměř žádné komentáře, • informační systém není programovaný ani čistě strukturovaně, ani čistě objektově, • v jednotlivých souborech zdrojový kódů jsou kombinovány uživatelský interface, aplikační část i práce s databází, • databázové schéma nerespektuje první normální formu, • kvůli nevhodně navrženému datovému schématu obsahuje systém značně komplikované SQL příkazy, jejichž vykonávání je příčinou pomalých odezev aplikace, • databázové schéma je pevně navázáno na informace v souborovém systému (na serializované PHP objekty), je zde patrný určitý pokus o vlastní implementaci objektové databázové abstrakce, která však není vhodně řešena, • k informačnímu systému neexistuje ani uživatelská dokumentace, ani projektová či programátorská dokumentace. 3.3.2

Nový informační systém

Z předchozí analýzy stávajícího informačního systému, z analýzy současných potřeb podniku a z analýzy možných změn ve vnitřním i vnějším prostředí podniku vyplývá ucelená analýza pro řešení nového informačního systému. Systém bude obsahovat moduly pro správu zakázek, dodavatelských faktur, ekonomických reportů, kontaktů a administrační modul pro správce systému.

3.3

Analýza

36

Modul pro správu zakázek bude pokrývat celý životní cyklus zakázky od nabídky pro klienta až po fakturaci a uzavření zakázky. Agenda vyřízení zakázky podléhá pevně stanoveným krokům, které jsou definovány podnikovými procesy. Na jedné zakázce může pracovat libovolný počet uživatelů v různých fázích daného podnikového procesu. Předávání zakázky mezi pracovníky v rámci jednotlivých fází procesu bude řešeno pomocí subsystému workflow, který bude podnikové procesy komputerizovat. Vlastní zakázka zahrnuje další nutnou agendu, zejména vytvoření nabídky pro klienta, vytvoření produktu (zboží) podle požadavků klienta, objednání vstupů nutných k vytvoření finálního produktu (zboží) pro klienta, fakturaci klientovi, plánování cashflow a ekonomické vyhodnocování zakázky v průběhu celého životního cyklu zakázky. Modul dodavatelských faktur umožňuje evidenci, likvidaci a archivaci faktur, které byly doručeny do podniku v souvislosti s objednáváním vstupů nutných pro výrobu výstupního produktu či v souvislosti s režií a provozní činností podniku. Modul ekonomických reportů podává kompletní seznam jednotlivých typů reportů. Reporty jsou určeny zejména k agregovanému pohledu na činnost jednotlivých pracovních skupin a poboček podniku s cílem monitorovat činnost a vyhodnocovat výkonnost jednotlivých organizačních složek podniku. Modul reportů je určen zejména pro vyšší management podniku, který na základě poskytovaných souhrnných dat činí strategická rozhodnutí. Modul kontaktů slouží k evidenci a klasifikaci kontaktů. Jednotlivé kontakty lze klasifikovat jako dodavatele, odběratele či jako dodavatele a odběratele zároveň. Modul kontaktů tvoří základ pro možné vytvoření CRM systému. Modul kontaktů bude po dokončení implementace systému úzce propojen s modulem kontaktů software Navision. Administrační modul bude přístupný pouze pro správce informačního systému, který bude spravovat uživatele, uživatelská oprávnění, role uživatelů v podniku a zařazení uživatelů do systémových či pracovních skupin. Nový IS bude pracovat s libovolnými měnami, bude napojený na kurzovní lístky odpovídajících centrálních bank a bude pracovat s aktuálními měnovými kurzy k danému datu. Systém bude podporovat libovolný počet překladů, výchozím jazykem systému bude anglický jazyk. Ve fázi nasazení do produkčního provozu bude k dispozici také jazyk český. Informační systém bude pracovat s daty využitím datových tabulek, které budou jednotné v celé aplikaci, budou poskytovat možnosti pro filtrování a řazení zobrazených dat. Datové tabulky umožní uživateli zobrazovat a skrývat jednotlivé sloupce. Zobrazená data bude možné exportovat do software MS Excel při respektování všech zadaných filtrů, pravidel pro řazení a nastavení zobrazení sloupců. Z výše uvedené základní analýzy plyne nutnost komputerizace podnikových procesů. Teoretickému základu komputerizace podnikových procesů je věnována kapitola 2.2.

3.4

3.4

Plánování zdrojů potřebných k realizaci projektu

37

Plánování zdrojů potřebných k realizaci projektu

Pro realizaci libovolného projektu je nutné využít řadu omezených zdrojů. Prvním klíčovým zdrojem jsou lidské zdroje. Druhým zdrojem jsou zdroje finanční. Dalšími zdroji mohou být například pracovní nástroje, kanceláře pro výkon projektových prací či odborné znalosti a zkušenosti pracovníků. Zdroje jsou omezené, a proto je nutné věnovat zvýšenou pozornost jejich výběru a alokaci (Rosenau, 2007). V případě lidských zdrojů je nutné zvážit, jaké potřeby je nutné v průběhu realizace projektu naplňovat. Podle potřeb se rozhodujeme o odbornostech pracovníků, kteří budou součástí projektového týmu. V průběhu projektu je nutné zajistit, aby všichni členové týmu byli optimálně vytížení. Nesmí docházet k přetěžování či naopak k nevyužití kapacit jednotlivých členů projektového týmu. V oblasti finančních zdrojů je klíčový plán financování projektu. Financování může probíhat buď formou předem stanoveného rozpočtu pro celý projekt anebo formou vykazování nákladů za stanovené časové úseky (například měsíčně). Neméně důležitá je alokace finančních zdrojů tak, aby byly co nejefektivněji využity pro cíle projektu. Tento konkrétní projekt bude financován metodou měsíčního vykazování nákladů spojených s projektem. Projekt vyžaduje zapojení následujících lidských zdrojů: • programátoři: kromě programování budou vykonávat analýzu a projektování, budou zařazeni v projektovém týmu po celou dobu životního cyklu IS; • grafik: do projektového týmu bude začleněn po dobu nezbytně nutnou k vytvoření grafického návrhu; • XHTML kodér: do projektového týmu bude začleněn po dobu nezbytně nutnou ke zpracování grafického návrhu do podoby XHTML šablon; • analytik: hlavní spojovací článek mezi managementem podniku a programátory, bude zařazen v projektovém týmu po celou dobu životního cyklu IS.

3.5

Volba vhodných metodik a technologií

Pro vývoj softwaru bude užito agilních metodik vývoje softwaru vzhledem k malému rozsahu projektového týmu. Na projektu bude po celou dobu jeho realizace pracovat zároveň nejvýše šest lidí. Konkrétní vybraná metodika je podrobněji popsána v kapitola 3.9 Z hlediska technologií je nutné rozhodnout o vhodných variantách pro prezentační, aplikační i datovou vrstvu. Rozhodnutí o technologiích je ve strategické rovině. V průběhu projektu lze technologie velice obtížně měnit a většinou je taková změna spojena s dodatečnými náklady. Výběru technologií je nutné věnovat v počáteční fázi projektu dostatečné množství času a úsilí.

3.5


3.5.1

38

Technologie aplikační vrstvy

Nejnáročnější a zároveň nejvíce klíčová pro budoucnost celého projektu je otázka výběru vhodného programovacího jazyka pro vytvoření aplikační vrstvy. Aplikační vrstva propojuje prezentační a datovou vrstvu, výběr technologií aplikační vrstvy proto ovlivní následné rozhodování o technologiích pro další vrstvy. Výběr technologie pro aplikační vrstvu lze rozdělit do dvou fází. První fází je výběr vhodného programovacího jazyka, druhou fází je rozhodnutí o použití či nepoužití některého z dostupných aplikačních frameworků. Pro programátora je volba programovacího jazyka víceméně subjektivní záležitostí osobních preferencí a zvyků. Z pohledu projektanta informačního systému existuje řada faktorů, která výběr programovacího jazyka ovlivní objektivně: • Minulost a budoucnost jazyka: Z jakého důvodu jazyk vznikl? Jaká je filosofie jazyka? Pro jaké užití v praxi je jazyk primárně určen? Bude jazyk využíván i v budoucnu anebo bude nahrazen vhodnějšími? • Situace na trhu práce: Jaká je na trhu práce nabídka pro daný programovací jazyk? Jaké jsou náklady na hodinu práce průměrného programátora ve srovnání s jinými programovací jazyky? • Syntaxe jazyka: Dovoluje jazyk vytváření konstrukcí, které jsou nečitelné? Nutí jazyk programátora psát kód přehledně? Bude zápisu jednoho programátora rozumět druhý programátor? • Vztah k jiným jazykům: Jaká je míra otevřenosti daného jazyka vůči jiným jazykům? Lze v daném jazyku využít moduly, třídy, funkce napsané v jiném jazyce? • Dostupné moduly a frameworky: Programátoři nesmí programovat kód, který už kdokoli jiný dříve naprogramoval. Jaká je dostupnost volných modulů, tříd, funkcí, frameworků pro daný jazyk? • Komunita: Je kolem daného jazyka vytvořena vyhovující komunita, která dokáže v diskusních fórech odpovídat na otázky či řešit problémy začátečníků? Pořádá komunita konference? Vydává komunita publikace? Z dostupných programovacích jazyků připadají pro rozhodování v úvahu následující jazyky: • • • •

Java, Perl, Python, Ruby.

Programovací jazyk Java byl oficiálně představen v roce 1995 společností Sun Microsystems. Práce na programovacím jazyku začaly již v roce 1990, kdy vznikl ve společnosti Sun Microsystems podnět pro vytvoření jazyka, který měl sloužit k vytváření softwaru pro domácí spotřebiče. Výsledkem vývoje se stal jazyk pojmenovaný „Oakÿ, který ale neuspěl na trhu. Nové uplatnění vzniklého programovacího jazyka bylo nalezeno na poli Internetu. Jazyk Oak byl použit pro výrobu appletů

3.5


39

pro webové stránky. Podpora appletů byla zabudována do nejrozšířenějšího prohlížeče Netscape a záhy do dalších prohlížečů. V roce 1995 bylo zjištěno, že již existuje programovací jazyk s názvem Oak. Proto byl jazyk přejmenován na jazyk „Javaÿ. Jazyk v současné době nalézá uplatnění v desktopových, serverových, webových i mobilních aplikacích. Programovací jazyk Java je v současnosti hojně používán pro vytváření různých typů aplikací včetně webových. Má integrovanou plnou podporu pro objekty, je jazykem se silnou kontrolou datových typů, což je výhodou pro týmovou práci a pro čitelnost kódu. Pro jazyk Java existuje řada vhodných frameworků. Komunita a dostupnost modulů či hotových řešení je vyhovující. Název jazyka Perl je zkratkovým slovem vytvořeným ze slovního spojení „Practical Extraction and Report Languageÿ (praktický jazyk pro výběry a tiskové sestavy). Jazyk navrhl původně pro svoji osobní potřebu Larry Wall. V roce 1987 byl jazyk zveřejněn k užívání. Velký ohlas vedl autora a jeho kolegy ke zlepšování a rozvíjení jazyka, který se tak stal plnohodnotným programovacím jazykem. Jazyk Perl přinesl do světa programovacích jazyků regulární výrazy, které jsou mocným nástrojem pro zpracování textu. Programovací jazyk Perl není vhodným kandidátem, protože je historicky jazykem určeným pro práci s textem. Navíc má těžkopádnou podporu objektového programování, které je jen dodatečnou nástavbou tohoto jazyka. Programovací jazyk Python publikoval v roce 1991 Guido van Rossum jako následníka jazyka ABC. Název jazyka pochází z názvu televizního pořadu „Monty Python’s Flying Circusÿ, který byl vysílán v době vzniku jazyka. Jazyk je inspirovaný programovacími jazyky ABC, ALGOL 68, C, Haskell, Icon, Lisp, Modula-3, Perl a Java. První verze jazyka Ruby byla publikována v roce 1995. Jazyk navrhl v roce 1993 japonský programátor Yukihiro Matsumoto s cílem vytvořit plně objektově orientovaný programovací jazyk v době, kdy Perl ještě nepodporoval objekty. Jazyk Ruby je inspirován jazykem Perl. Motivací autora bylo „vytvořit skriptovací jazyk, který bude silnější než Perl a více objektově orientovaný než Pythonÿ. Jazyk je inspirovaný programovacími jazyky Smalltalk, Perl, Lisp, Scheme, Python, CLU, Eiffel, Ada a Dylan. Výběr jednoho z výše uvedených jazyků bude probíhat v první fázi vylučovací metodou. Je vyloučen jazyk Perl, protože má nevyhovující podporu pro objektově orientované programování, dále má nevyhovující podporu pro výjimky. Podpora pro OOP a pro výjimky byly do jazyka přidány jako rozšíření až v jeho pozdějších verzích, jazyk nebyl od svého počátku vyvíjen jako objektový. Z těchto důvodů je v jazyku Perl poněkud těžkopádná práce s objekty a výjimkami. Jazyk Perl byl primárně navržen jako jazyk pro zpracování textu, další funkcionalita a rozšíření jazyka (OOP, CGI a jiné) staví na původních historických základech, které nepočítaly s rozšířením. Proto není vhodné použít jazyk Perl pro vývoj intranetového podnikového informačního systému objektově orientovaným způsobem. Druhým podstatným důvodem vyloučení jazyka Perl je nemožnost používat knihovny napsané v jazyku

3.5


40

Java. Posledním důvodem pro vyloučení jazyka Perl je jeho poměrně složitá a volná syntaxe, která dovoluje psát sice funkční, ale značně nepřehledné konstrukce, kterým mnohdy rozumí jen sám autor. Ze zbývajících třech programovacích jazyků je dále vyloučen jazyk Java. Hlavními důvody pro vyloučení jsou nízká vyjadřovací schopnost (anglický pojem „expressivenessÿ) a statické typování. Nízká vyjadřovací schopnost se projevuje v praxi potřebou až čtyřikrát většího počtu řádku kódu k vykonání stejné funkcionality při srovnání s kódem napsaným v programovacích jazycích Python a Ruby. Statické typování přináší do vývoje programu omezení přiřazení pouze jediného, předem určeného, datového typu do dané proměnné. Statické typování může komplikovat vývoj algoritmů a vede v určitých případech k vytváření komplikovaného kódu. Konečná fáze rozhodování stanoví použití jazyka Python či jazyka Ruby. Pro výběr vhodného jazyka bude použita srovnávací tabulka číslo 18, která obsahuje hodnocení klíčových kritérií. Tab. 18: Srovnání programovacích jazyků Python a Ruby

Kritérium Python 2.5 Ruby 1.8 Vestavěná podpora pro Unicode ano ne Vestavěná podpora pro vlákna ano ne Kompilace kódu pro virtuální stroj ano ne (Virtual machine code compilation) Syntax velmi striktní méně striktní Meta-programování: podpora ano ne dekorátorů a deskriptorů Objektová orientace hybridní čistá Počet aplikačních frameworků 6 4 Rok publikace jazyka 1991 1995 Vestavěná podpora Unicode je nutná, protože vytvořený software bude pracovat s mnoha různými jazyky. Vestavěná podpora pro vlákna je nezbytným předpokladem provozu softwaru na serveru s několika procesory. Možnost kompilace zdrojového kódu do jazyka virtuálního stroje (podobně jako funguje Java Virtual Machine) vede ke zrychlení běhu softwaru. Pro jakýkoli softwarový projekt, na kterém pracuje tým programátorů, je vhodnější jazyk se striktní syntaxí. Taková syntax většinou nutí programátora zapsat daný algoritmus pouze jedním způsobem, což je nezbytné pro pochopení kódu ostatními programátory. Míra objektové orientace jazyka není zcela klíčová, stejně jako podpora pro meta-programování. Oba dva srovnávané jazyky jsou objektové a obsahují určitou podporu pro metaprogramování. Rozdíly jsou pouze v detailech, které nejsou pro výběr zcela podstatné. Pro realizaci projektu bude využit jeden z dostupných frameworků, jejich počet pro jednotlivé jazyky je proto jedním z méně podstatných faktorů. Počet dostupných frameworků úzce sou-

3.6

Sestavení datového schématu

41

visí se stářím jazyka. Jazyk Python je oproti jazyku Ruby o čtyři roky starší, a proto pro jazyk Python existuje i více frameworků. Klíčová kritéria pro realizaci projektu splňuje na základě vyhodnocení srovnávací tabulky pouze jazyk Python. Aplikační vrstva projektu bude tedy vytvořena pomocí programovacího jazyka Python. Projekt bude vyvíjen v jazyku Python. Pro tento jazyk lze využít řadu frameworků, mezi nejpoužívanější patří Django, Pylons a TurboGears. 3.5.2

Technologie prezentační vrstvy

Informační systém bude webovou aplikací, budou tedy použity technologie HTML, CSS a Java Script. V aplikaci bude prezentační vrstva striktně oddělena od ostatních vrstev. Pro efektivní propojení aplikační a prezentační vrstvy bude použit šablonovací systém. 3.5.3

Technologie datové vrstvy

Databázový systém musí být licencován libovolnou open-source licencí. Výběr je tímto omezen na databázové systémy MySQL (InnoDB engine) verze 6, PostgreSQL verze 8.3 a Firebird 2.1. Klíčovými kritérii pro výběr vhodného databázového systému jsou: aktivní referenční integrita, podpora procedurálních rozšíření, podpora víceprocesorových serverů, podpora subselectů. Při vyhodnocení vlastností všech uvedených databázových systémů splňuje uvedená kritéria nejlépe systém PostgreSQL, který je pro projekt vybrán. Obecně vzato není změna databázového systému v budoucnu příliš nákladným krokem. Zejména proto, že budeme pro spojení databázové a aplikační vrstvy používat databázovou objektovou abstrakci a s databází tak nebudeme pracovat v aplikační vrstvě přímo.

3.6


Tabulky datového schématu bude plně respektovat první normální formu (všechny atributy jsou atomické) a druhou normální formu (primární klíče). Třetí normální formu (cizí klíče) bude respektovat všechny tabulky s výjimkou tabulek pro kontakty. Tabulka pro kontakty bude obsahovat kontaktní údaje z různých států, vzniká zde problém s poštovními směrovacími čísly. V některých státech (například v Číně) neexistují poštovní směrovací čísla, v dalších státech existují, ale jsou sestavena na základě různých systematik. Vytvářet pro každý stát databázi poštovních směrovacích čísel by nebylo smysluplné, a proto bude v tabulce kontaktů tolerováno porušení třetí normální formy. V tabulce kontaktů bude tedy jak sloupec pro cizí klíč města, tak sloupec pro PSČ, který bude moci obsahovat hodnotu NULL kvůli státům, které nepoužívají PSČ. Databázové schéma musí být schopné pracovat s vícejazyčnými texty, zejména s vícejazyčnými číselníky. Pro databázovou implementaci lokalizace obsahu do různých jazyků existuje řada možných řešení:

3.6


42

• sloupcové řešení: pro každý jazyk je vytvořen v dané tabulce odpovídající sloupec. Například lokalizace sloupce „nazevÿ v tabulce „zboziÿ spočívá ve vytvoření dodatečných sloupců „nazev csÿ, „nazev enÿ, „nazev deÿ atd. • řádkové řešení: pro daný řádek tabulky je stanoven identifikátor jazyka. Pro jednu položku zboží budou v databázi tři záznamy (řádky) odpovídající třem jazykovým variantám, které jsou rozlišené podle identifikátoru jazyka. • řešení centrální překladovou tabulkou, které předpokládá existenci tří dodatečných tabulek: Tabulka obsahující číselník podporovaných jazyků „ jazykyÿ, tabulka obsahující vlastní překlady „preklady obsahÿ a tabulka pro uchování identifikátoru obsahu překladu bez rozlišení jazyka „prekladyÿ. Tabulka vlastních překladů obsahuje cizí klíč jazyka a cizí klíč identifikátoru obsahu překladu. Tabulka zboží, ve které chceme mít lokalizované pole názvu zboží, bude obsahovat sloupec „nazevÿ, který bude cizím klíčem do tabulky identifikátorů obsahů překladů. Vlastní select zboží pro konkrétní jazyk pak může vypadat takto v případě jednoho překládaného sloupce: SELECT preklady_obsah.preklad AS nazev, zbozi.cena FROM zbozi JOIN preklady_obsah ON (preklady_obsah.identifikator_obsahu = zbozi.nazev AND preklady.jazyk = 1) V případě více překládaných sloupců je nutné použít poddotazy: SELECT (SELECT preklad FROM preklady_obsah WHERE identifikator_obsahu = zbozi.nazev AND jazyk = 1) AS nazev, (SELECT preklad FROM preklady_obsah WHERE identifikator_obsahu = zbozi.popis AND jazyk = 1) AS popis, cena FROM zbozi • řešení individuálními překladovými tabulkami: pro každou tabulku, jejíž obsah je nutné lokalizovat, je vytvořena dodatečná tabulka (např. s postfixem „prekladÿ). Sloupce, které je třeba lokalizovat, vyčleníme z původní tabulky do nové překladové tabulky, která navíc obsahuje identifikátor jazyka (cizí klíč do tabulky „ jazykyÿ) a identifikátor lokalizované položky (cizí klíč do tabulky zboží). Vlastní select zboží pro konkrétní jazyk pak bude následující: SELECT * FROM zbozi JOIN zbozi_preklad ON (zbozi_preklad.zbozi = zbozi.id AND zbozi_preklad.jazyk = 1) Řešení pomocí dodatečných sloupců je nevyhovující z pohledu rozšiřitelnosti. Pro přidání nového jazyka je nutné do všech tabulek přidat nové sloupce. Řešení pomocí dodatečných řádků pro jednotlivé lokalizace přináší duplicitu informací napříč jednotlivými řádky tabulky. V případě zboží jsou tak duplikovány informace o ceně zboží a další atributy, které nepodléhají překladu (většinou číselné informace).

3.7

Návrh aplikační architektury

43

Obě řešení pomocí oddělených překladových tabulek jsou korektní z pohledu třetí normální formy. Pokud je nutné lokalizovat v tabulkách více než jeden sloupec, jeví se jako výhodnější varianta několika oddělených překladových tabulek kvůli menší složitosti SQL dotazu, který nemusí obsahovat poddotazy. Pokud lokalizaci podléhá vždy právě jeden sloupec, je vhodnější pro takové tabulky použít centrální překladovou tabulku. Projekt vyžaduje pouze překlady číselníků, to znamená překlady právě jednoho sloupce z různých tabulek. Proto je zvoleno řešení pomocí centrální překladové tabulky.

3.7


Pro celý vývoj projektu platí, že programátor nesmí programovat funkcionalitu nebo kód, který už někdo jiný naprogramoval a poskytl k volnému užití. Z tohoto předpokladu vyplývá nutnost použití vhodného existujícího aplikačního frameworku, který bude základem pro projekt a stanoví vlastní rámec pro architekturu projektu. Pro programovací jazyk Python jsou volně k užití tyto frameworky pro webové aplikace: • • • • • •

Django, Grok, Pylons, TurboGears, Web2py, Zope.

Všechny uvedené frameworky podporují architekturu MVC (Model-ViewController). Tato architektura rozděluje na úrovni modulů a zdrojového kódu aplikaci na část komunikující s databází (Model), část prezentující data uživateli (View) a část, která propojuje Model a View pomocí business pravidel (Controller).

Obr. 6: Diagram modelu MVC

Architektura MVC je dále členěna na takzvanou Push MVC a Pull MVC architekturu. Členění vychází ze dvou různých přístupů ke vzájemnému vztahu mezi

3.7


44

částmi View a Controller. Push MVC architektura spočívá v interpretaci uživatelských činností pomocí částí Controller, která vygeneruje data. Tato data jsou předána části View a vygenerována uživateli do prezentační vrstvy. Anglický výraz „pushÿ lze přeložit jako „posunovatÿ. V tomto kontextu jde o posun dat z Controlleru do části View. Pull MVC architektura zpracuje uživatelský požadavek na zobrazení dat skrze View část, která skrze Controller získá data, která si uživatel vyžádal. Anglický výraz „pullÿ lze obdobně přeložit jako „tahatÿ, v Pull MVC architektuře tedy „vytahujeÿ část View potřebná data z Controlleru. Na základě výše uvedené klasifikace můžeme dále frameworky členit do dvou skupin podle podpory Push/Pull MVC architektury. Každý framework podporuje právě jeden ze zmíněných přístupů. Pull MVC architekturu využívají frameworky Grok a Zope. Push architektura je implementují frameworky Django, Pylons, TurboGears a Web2py. Pro projekt je výhodnější přístup Push, který je také obecně častěji využívaný v praxi. Ze zbylých čtyřech frameworků je nutné vyřadit Django. Tento framework je specializovaný pro vývoj webových portálů a CMS systémů, jeho největší výhodou je automatické vytváření administračního rozhraní webu na základě datového modelu. Tato výhoda je pro daný projekt neupotřebitelná, protože v projektu nebude aplikace rozdělena do veřejné a administrační části. Aplikace bude obsahovat jediné pracovní prostředí pro všechny uživatele. Hlavní výhodou frameworku Web2py je webová administrace vlastní aplikace, která je zaměřena spíše na okruh systémových správců a administrátorů. Webová aplikace umožňuje správu modulů a jejich zdrojových kódů, dále správu překladů a správu databáze. Nicméně, správa aplikace je vždy efektivnější přímým způsobem skrze terminál operačního systému. Oproti ostatním frameworkům Web2py nepoužívá moduly třetích stran, ale implementuje veškerou funkcionalitu vlastním způsobem. V tomto přístupu je jisté riziko nedokonalosti jednotlivých komponent frameworku a riziko nedostatečného tempa vývoje komponent, zejména vzhledem k malé komunitě, která pracuje na vývoji frameworku. Z výše uvedených důvodů je framework Web2py také vyřazen. Frameworky Pylons a TurboGears fungují na principu vzájemné integrace jinak samostatných komponent, které nezávisle vyvíjí početné komunity programátorů. Oproti Web2py je u těchto frameworků vysoká pravděpodobnost inovací jednotlivých nezávislých komponent. Použité komponenty lze kategorizovat do hlavních částí: • databázová abstrakce, která tvoří část Model; • šablonovací systém, který tvoří část View (templating system); • sady komponent uživatelského rozhraní, které doplňují část View (helpers); • řízení požadavků, které slouží ke směrování požadavků z dané URL do odpovídajícího modulu části Controller (request dispatching). Oba frameworky využívají takzvaného WSGI interface. Interface byl vytvořen jako standard v roce 2003, umožňuje součinnost různých webových frameworků napsaných v jazyce Python. Standard WSGI tvoří tři komponenty:

3.7


45

• aplikace, • servery, • middleware. Aplikacemi jsou funkční části, jejichž výstup je definován kódem HTTP odezvy, HTTP hlavičkami a vlastní odezvou (Gardner, 2008). WSGI aplikace mohou být vytvořeny jako funkce nebo jako instance tříd. Frameworky Pylons a TurboGears pracují na principu vytváření WSGI aplikací, pro jejich tvorbu poskytují určitou míru abstrakce a zjednodušení. Server je prostředím pro provoz WSGI aplikace, jeho hlavním úkolem je připravit pro WSGI aplikaci prostředí, které je definováno pevně stanovenou množinou proměnných. Existuje řada volně dostupných implementací WSGI serverů. Middleware je komponentou, která stojí mezi serverem a aplikací. Z pohledu aplikace se chová middleware jako server, protože stejně jako server definuje množinu proměnných prostředí a vrací stejným způsobem odezvu. Vlastní WSGI middleware přistupuje k serveru jako WSGI aplikace. Hlavním smyslem middleware je možnost změnit veškeré HTTP informace, které přijímá aplikace od serveru a možnost změnit veškeré HTTP informace, které server obdrží od aplikace. Middleware proto slouží zejména ke (Gardner, 2008): • • • • •

změnám HTTP požadavku, změnám stavového kódu HTTP, zachytávání chyb, přidávání, odebírání či změně hlaviček HTTP, změně odezvy.

Příklad praktického využití middleware nalezneme zejména v následujících oblastech (Gardner, 2008): • • • • • • • • • •

tvorba chybových dokumentů, které se zobrazují při chybách 404 a 500, reportování chyb pomocí e-mailu, interaktivní debuggery, přeposílání požadavků ostatním částem aplikace, ověření, zdali aplikace a servery splňují WSGI standard, autorizace uživatele, cachování stránek, úložiště pro sessions, zpracování cookies, komprimace odezvy.

Oba zmíněné frameworky jsou velice podobné, nabízejí možnost volby stejných hlavních komponent (DB abstrakce, šablonovací systém atd., viz výše). Každý z frameworků upřednostňuje jinou sadu výchozích komponent, které lze jednoduše nahradit jinými komponentami. Rozdílnost frameworků spočívá v komponentách, které tvoří vlastní jádro frameworku: • řízeni požadavků (request dispatching), • konfigurační rozhraní frameworku,

3.7


46

• rozhraní pro funkcionální testy. TurboGears je ve všech uvedených bodech silně závislý na HTTP frameworku CherryPy. Pylons využívá pro řízení požadavků komponentu Routes, konfigurace je realizována přes komponentu Paste Deploy a funkcionální testy probíhají přes komponentu Paste TestApp. Pylons navíc umožňuje nahrazení výchozí komponenty pro řízení požadavků libovolnou jinou komponentou. Pro práci s frameworkem je nejdůležitější dostupnost kvalitní dokumentace, literatury a existence silné komunity, která je schopná odpovídat složité otázky a řešit problémy na fórech. Z tohoto pohledu je vhodnějším frameworkem Pylons. Pro realizaci projektu je definitivně vybrán framework Pylons, ve kterém budou nahrazeny některé výchozí komponenty vhodnějšími komponentami. Hlavními důvody pro výběr tohoto frameworku byly lepší dokumentace, dostupnost literatury a menší závislost frameworku na jediné komponentě (TurboGears je silně závislý ve více oblastech na CherryPy frameworku). Pro účely projektu byla vybrána jak ORM komponenta (Object-relational mapping; objektová databázová abstrakce) SQLObject, šablonovací systém Genshi, knihovna komponentů UI ToscaWidgets. Ve frameworku Pylons byla ponechána výchozí komponenta pro řízení požadavků (request dispatching) Routes. Projekt bude ve fázi vývoje provozován na vývojovém HTTP serveru Paster. Ve fázi testování a produkčního provozu bude aplikace nasazena jako WSGI aplikace pro HTTP server Apache za použití modulu mod python a vhodné WSGI gateway (mod python / WSGI Bridge). 3.7.1

Lokalizace a národní prostředí

Lokalizace je často označována jako „i18nÿ. Tato zkratka vychází z prvního a posledního písmena anglického slova „internationalizationÿ, číslice 18 značí počet písmen mezi prvním písmenem „iÿ a posledním písmenem „nÿ. Slovo „internationalizationÿ lze přeložit jako „zmezinárodňováníÿ. Zkratka i18n je zažitou zkratkou, která neoznačuje žádnou konkrétní technologii lokalizace. Framework Pylons využívá pro účely i18n nástroj GNU „gettextÿ, vytvořený v rámci projektu GNU Translation Project. Tento nástroj umožňuje začlenit do zdrojového kódu texty, které mohou být přeloženy do libovolných jazyků a výsledně zobrazeny do uživatelského rozhraní ve zvoleném jazyce. Lokalizaci mohou podléhat následující součásti aplikace (Gardner, 2008): • • • • • •

jazyk, formát data a času, čísla – desetinné oddělovače, oddělovače tisíců, časové zóny, měny, váhy a míry.

3.8

Koncepce a grafický návrh prezentační vrstvy

47

V projektu bude implementována podpora pro změnu jazyků, ostatní součásti aplikace budou mít neměnný formát. Texty, které jsou určeny k překladu jsou zapisovány do zdrojového kódu v anglickém jazyce a jsou označeny pomocí funkce (). Tato funkce je aliasem pro funkci ugettext() z balíku GNU gettext. Vlastní zdrojový kód překladu vypadá například takto: def hello_world(): return _("Hello") Anglický výraz „helloÿ je uvedenou konstrukcí označen jako text k překladu. Po označení všech textů pro překlad je spuštěn nástroj, který projde veškeré zdrojové kódy a zpracuje veškeré označené texty do souboru s příponou POT (Portable Object Template). Tento soubor je základem pro vlastní překlad. Je z něj vytvořen soubor s příponou PO (Portable Object), který obsahuje seznam textů pro překlady. Soubor PO slouží k provedení vlastních překladů překladatelem, vypadá např. takto (Gardner, 2008): msgid "Hello" msgstr "Ahoj" Po přeložení všech výrazů následuje poslední krok, kompilace PO souboru do MO (Machine Object) souboru. MO soubor je optimalizovanou binární podobou překladového souboru, který umožňuje rychlejší provedení překladů za běhu programu (Gardner, 2008). Pylons umožňuje použít pro i18n balík nástrojů „Babelÿ. Tyto nástroje rozšiřují možnosti balíku GNU gettext o automatickou extrakci textů pro překlad šablon, kterým je podrobně věnována kapitola 4.4.1. Výhoda použití nástrojů Babel je patrná z následujících příkladů. Nejprve řešení překladu v šabloně za použití GNU gettext:
${_("Hello, world!")}
Tento způsob zápisu je pro šablonu značně komplikovaný a nepohodlný. Použití nástrojů Babel umožňuje následující zápis:
Hello, world!
Nástroje Babel jsou schopné automaticky rozpoznat a vyextrahovat ze šablony texty pro překlad bez nutnosti použít komplikované zápisy. Zápis textů v šablonách je evidentně efektivnější a přehlednější druhým uvedeným způsobem, proto budou pro lokalizaci použity nástroje Babel.

3.8

Koncepce a grafický návrh prezentační vrstvy

Uživatelský interface bude navržen s ohledem na uživatelská prostředí běžně používaných účetních programů či podnikových informačních systémů. Tato koncepce je výhodná pro budoucí uživatele systému, kteří se díky známému pracovnímu prostředí naučí používat nový informační systém rychleji. Uživatelé v praxi většinou znají pracovní prostředí informačních systémů Navision, SAP, či prostředí účetních programů Abra, Money, Pohoda a dalších.

3.9

Vlastní programátorské práce

48

Uvedené informační systémy mají společné rozložení obrazovky na jednotlivé části. Obecné ovládací prvky pro celou aplikaci jsou umístěny v horním pruhu obrazovky. Kontextové a specializované ovládací prvky jsou soustředěny do levého navigačního pruhu, který zaujímá minimální nutnou šířku pro zobrazení ovládacích komponent. Hlavní část obrazovky zabírá maximální prostor mezi horním a levým pruhem. Hlavní část je přímo ovládána z levého navigačního pruhu a obsahuje většinou tabulku s výpisem dat. Nový informační systém bude respektovat zažité uspořádání uživatelského rozhraní, které bude využívat výhod webové aplikace a přidá do vlastního ovládání řadu vylepšení, která usnadní práci uživatele.

3.9

Vlastní programátorské práce

Programový kód a komentáře budou psané v anglickém jazyce. Charakter projektu, malý vývojový tým a vlastní prostředí podniku, pro který je nový informační systém vyvíjen, jednoznačně vyžadují využití agilních metodik vývoje informačních systémů. Rigorózní metodiky se jeví jako nepružné, neefektivní a příliš svázané pevnými pravidly. Projekt bude respektovat principy metodiky Dynamic Systems Development Method (DSDM), která je postavena na následujících devíti klíčových principech (Buchalevcová, 2005): • • • • • • • • •

aktivní zapojení uživatele, tým s rozhodovací pravomocí, časté dodávky produktu, klíčovým kritériem pro přijetí dodávky je podpora podnikových cílů, iterativní a inkrementální vývoj jako nástroj postupného přibližování k žádoucímu řešení, změny v průběhu vývoje, definice požadavků na hrubé úrovni, testování v průběhu celého životního cyklu, spolupráce mezi členy týmu.

V průběhu vývoje bude pro správu zdrojového kódu využit systém Subversion. Pro správu chyb bude použit systém zasílání emailů. Pokud dojde v aplikaci k chybě nebo k výjimce, je vygenerovaná zpráva s detailním popisem výjimky. Zpráva je zaslána emailem všem programátorům do programátorské emailové konference. Autor kódu následně chybu opraví a zašle zprávu o opravě do emailové konference. V průběhu celého životního cyklu projektu bude platit zásada „DRYÿ (Don’t repeat yourself, tj. Neopakuj se), která má zabránit vzniku redundantního kódu. Redundance v programovém kódu je důsledkem nerespektování norem, je zbytečně prováděnou prací a z ekonomického hlediska je plýtváním omezenými zdroji. V klíčových a složitých místech programového kódu budou umístěné komentáře. Není nutné komentovat kód, který je na první pohled pochopitelný. Během programování je nutné klást důraz na vhodnou míru obecnosti algoritmů. Přílišný důraz na

3.10

Testování

49

obecnost algoritmu může vést k vytváření funkcionality, kterou zákazník nikdy nevyužije. Na druhou stranu přílišná konkrétnost vylučuje znovupoužitelnost algoritmů. Obecnost musí být nastavena v takové míře, kdy bude zajištěna znovupoužitelnost a zároveň řešení nebude zbytečně časově nákladné a nebude implementovat zbytečnou funkcionalitu.

3.10

Testování

Testování bude probíhat po celou dobu životního cyklu softwaru. Programátorské chyby odhalené během testování se evidují pomocí systému emailové konference, který se popsán výše. Chyby, které odhalí zákazník (objednavatel projektu), sdělí zákazník libovolným způsobem vývojovému týmu, který chybu opraví. Vlastní testování lze klasifikovat do třech kategorií (Gardner, 2008): • unit testing, • funkcionální testy, • uživatelské testy. Unit testing znamená testování základních jednotek zdrojového kódu, kterými jsou funkce či metody tříd. Funkcionální testy ověřují korektní funkcionalitu akcí jednotlivých kontrolerů v kontextu MVC modelu (Gardner, 2008). Tyto druhy testů vyžadují vytváření automatizovaných testovacích algoritmů pomocí specializovaných nástrojů. Z tohoto důvodu nebudou unit testy a funkcionální testy probíhat. Naopak uživatelské testy nevyžadují programování zvláštních algoritmů a můžou do nich být zapojeni uživatelé z řad zaměstnanců podniku. Takovéto zapojení externích testerů je vhodné ze dvou důvodů: • budoucí uživatelé mají dojem, že se podílejí na vytváření výsledného informačního systému, což může vést k jejich aktivnímu přístupu k prezentaci jejich očekávání a potřeb kladených na vyvíjený IS; • tým programátorů nemusí být doplněn o testery, programátoři se můžou plně věnovat programování vlastního kódu aplikace a případným reakcím testujících budoucích uživatelů.

3.11

Nasazení do produkčního prostředí

Před vlastním nasazením do produkčního prostředí proběhne převod dat ze stávajícího systému. Budou převedeny záznamy o uživatelích systému a záznamy z adresáře kontaktů. Pro převod budou vytvořeny specializované mechanizmy, pomocí kterých dojde k jednorázovému převodu potřebných dat z databáze původní aplikace do databáze nové aplikace. Vzhledem k tomu, že data v původní aplikaci nejsou v první normální formě, bude nutné pomocí konverzního mechanismu data normalizovat, vytvořit potřebné číselníky a hodnoty číselníků správně propojit s odpovídajícími záznamy.

3.11

Nasazení do produkčního prostředí

50

Nový informační systém bude nasazen na hardwarový server, kde je nainstalován stávající informační systém. Tento stávající systém musí být dostupný současně s novým informačním systémem kvůli přístupu k historickým datům. Stávající systém je nasazen jako PHP aplikace přes webový server Apache, datová vrstva aplikace je tvořena databázovým systémem PostgreSQL. Nový informační systém bude rovněž provozován na webovém serveru Apache, bude využívat stejný typ databázového systému jako systém stávající. Pro dosažení maximální nezávislosti obou systémů, budou výhradně pro provoz nového informačního systému nainstalovány nové servery: • HTTP server Apache verze 2.0.63, • databázový server PostgreSQL, verze 8.3. Pro server Apache bude nainstalován modul mod python verze 3.3.1. Původní aplikace bude dostupná pomocí původního HTTP serveru na portu 80, nový informační systém bude provozován na novém HTTP serveru na portu 5000. Původní databázový server PostgreSQL bude nadále využívat standardní port 5432, nově nainstalovaný PostgreSQL server bude provozován na portu 5433. V produkčním provozu jsou v případě chybových stavů (internal server error, HTTP stavový kód 500) nahrazeny ladící výstupy (traceback) jednotnou obrazovkou s grafickým designem uživatelského prostředí IS. Na obrazovce bude zobrazena srozumitelná zpráva o výskytu chyby, kontakt na správce aplikace a odkaz pro návrat na předchozí obrazovku. Podobně v případě pokusu o otevření neexistující URL je namísto standardní hlášky o HTTP chybě 404 zobrazena srozumitelná zpráva v designu uživatelského prostředí a možnost návratu zpět. V případě výskytu chyby na straně serveru (HTTP error 500) dojde k vygenerování zprávy o chybě a k jejímu zaslání do e-mailové konference vývojového týmu, který bude chybu okamžitě řešit. Díky propracovanému systému generování chybových zpráv jsou programátorům doručeny společně s popisem chyby i tyto provozní infromace: • proměnné CGI (IP adresa uživatele, port uživatele, identifikátory jeho webového prohlížeče, vyžádaná URI, proměnné serveru a jiné proměnné); • proměnné WSGI – obsah uživatelské session: z obsahu session lze vyčíst identifikátor uživatele. Je tedy možné ihned po výskytu chyby kontaktovat uživatele a řešit s ním vzniklý problém. – hodnoty parametrů zaslaných metodou GET nebo POST: tyto hodnoty jsou velmi užitečné pro simulaci chyby ve vývojovém prostředí, – parametry WSGI směrovače, – informace o využití cache a další užitečné informace. Na základě výše uvedených informací můžou programátoři začít pracovat na odstranění chyb ještě dříve, než chybu nahlásí uživatel. Pro uživatele i pro celý

3.12

Správa, údržba a uživatelská podpora

51

podnik je pozitivní, že programátoři mají potřebné znalosti o chybě, její příčině a jejím řešení už v okamžiku hlášení chybového stavu uživatelem, zejména v případě telefonického hlášení.

3.12

Správa, údržba a uživatelská podpora

Správa a údržba systému spočívá zejména v následujících úkolech: • správa uživatelů: označování neaktivních uživatelů v případě jejich odchodu z podniku, přidávání nových uživatelů, změny uživatelských jmen a hesel, zařazování uživatelů do obchodních a systémových skupin; • řešení chyb; • správa číselníků: přidávání či odebírání položek číselníků; • připojování nových poboček: spočívá zejména v napojení na nové centrální banky, zanášení nových jazykových mutací systému a aktualizaci číselníku poboček; • aktualizace business pravidel; • aktualizace workflow procesů. První oblast správy a údržby je plně v kompetenci systémového integrátora, který má administrativní přístup k veškerému nastavení uživatelů informačního systému. Oblast řešení chyb částečně sdílí systémový integrátor, částečně vývojový tým. Systémový integrátor řeši domnělé chyby uživatelů, které fakticky chybami nejsou, ale jsou přesto systémovému integrátorovi hlášeny v důsledku uživatelské neznalosti. Chyby, které jsou z pohledu programátorů skutečnými chybami, řeši vývojový tým. Ostatní oblasti správy a údržby jsou plně v kompetenci vývojového týmu. Tyto kompetence lze teoreticky převést na systémového integrátora. K tomu by ale bylo zapotřebí vyvinout nové moduly pro správu číselníků, překladů a dalších oblastí. Vzhledem k nízké frekvenci těchto změn se z ekonomického pohledu jeví jako úspornější nevyvíjet takovéto moduly a ponechat příslušné kompetence programátorům. Uživatelská podpora bude spočívat zejména ve vydání uživatelského manuálu, který bude vysvětlovat obecná pravidla pro práci se systémem i konkrétní postupy k dosažení požadovaných výsledků. Uživatelský manuál je dostupný jako příloha této práce. V průběhu nasazování IS do produkčního prostředí proběhne rovněž řada školení, na kterých budou uživatelé zběžně seznámeni s výhodami nového systému a se základními pravidly pro práci se systémem. Dotazy nad rámec školení a manuálu budou uživatelé konzultovat se systémovým integrátorem.

4

IMPLEMENTACE PODNIKOVÉHO INFORMAČNíHO SYSTÉMU

4

52

Implementace podnikového informačního systému

Počátek implementace informačního systému z pohledu architektury MVC bude věnován části Model. Po dokončení datového modelu bude souběžně probíhat vývoj částí Controller a View. Časovému rozvržení implementace jednotlivých částí architektury MVC odpovídá pořadí následujících kapitol.

4.1

Datový model ORM – Model

Datové schéma tvoří celkem 58 tabulek. Tabulkám jsou dle věcného významu přiřazeny prefixy: • • • • • • •

log – logování událostí v systému, pub – obecná data, která nemají přímý obchodní význam, stat – evidence statistik používání systému, sys – systémové tabulky tvořící jádro systému, cmp – podnikové tabulky obsahující obchodní informace, wfr – tabulky pro evidenci běhu workflow procesů, wft – evidence šablon a definic workflow procesů.

Pro účely aplikace byl rozšířen systém ORM (Object-relational mapper) o několik tříd, které jsou generalizací tříd pro definice samotných tabulek. V datovém modelu je nezbytné evidovat o každém řádku libovolné tabulky takzvaná metadata. Metadata jsou sadou informací o existujících datech, popisují uložená data podle zvoleného klasifikačního systému. Metadata pro vyvíjenou aplikaci obsahují tyto údaje: • • • • • • •

datum a čas vytvoření; datum a čas poslední změny; datum a čas smazání; uživatel, který vytvořil záznam; uživatel, který naposledy změnil záznam; uživatel, který vymazal záznam; systémová uživatelská skupina, která slouží pro nastavení oprávnění k záznamu ze systémového pohledu; • pracovní skupina, nastavuje oprávnění k záznamu z obchodního pohledu; • pobočka, které náleží daný záznam. Vhodnou úpravou ORM pomocí mezivrstvy je možné vytvářet tabulky, které automaticky obsahují cizí klíč do tabulky metadat, a navíc jsou metadata automaticky aktualizována podle provedených operací se záznamem. Druhým zásadním rozšířením ORM je zavedení databázových překladů. Překládané sloupce jsou při tomto přístupu cizími klíči do překladové tabulky. Nově vytvořená vrstva rozšíření umožňuje provádět dotazy tak, jako bychom pracovali se sloupci, které nejsou ve skutečnosti cizími klíči. Na základě předem definovaného identifikátoru jazyku dojde k automatickému propojení potřebných překladových

4.1


53

tabulek a k aktualizaci obsahu potřebných sloupců určenými jazykovými překlady. Vytvořené rozšíření tak umožňuje efektivně pracovat s vícejazyčnými daty bez nutnosti sestavování složitých dotazů, protože jsou potřebné dotazy vytvářeny a prováděny automaticky. Vlastní jádro práce s databází je zakotveno v souborech, které definují strukturu jednotlivých tabulek databázového schématu. Jednotlivé tabulky jsou zapsány jako třídy, které dědí vlastnosti příslušných rodičovských tříd ORM. Podle druhu a významu tabulky můžeme zvolit jednu z rodičovských tříd: • SQLObject – je výchozí rodičovskou třídou ORM systému; • DataSQLObject – jedná se o výše uvedenou mezivrstvu, která dědí všechny vlastnosti třídy SQLObject a přidává podporu pro automatizovanou práci s metadaty; • MultiLangSQLObject – tato třída dědí veškeré vlastnosti od předchozí třídy DataSQLObject a přidává podporu pro automatizaci překladů záznamů v jednotlivých řádcích tabulek; • PgViewObject – tato třída umožňuje definovat pohledy pro PostgreSQL databázi a umožňuje s definovanými pohledy pracovat jako s tabulkami. Dle výše popsaných pravidel je možné definovat v ORM tabulku pro objednávku například takto: class Order(DataSQLObject): class sqlmeta: table = "trg_order" # columns name = UnicodeCol(length = 56, notNone = True) quantity = IntCol(default = None) price = CurrencyCol(default = None) price_total = CurrencyCol(default = None) branch_number = IntCol(notNone = True) contact_person = UnicodeCol(length = 32, default = None) contact_email = UnicodeCol(length = 48, default = None) contact_phone = UnicodeCol(length = 18, default = None) contact_mobile = UnicodeCol(length = 18, default = None) price_exchange = LongCurrencyCol(default = None) discount_from_supplier = UnicodeCol(length = 128, default = None) payment_conditions = UnicodeCol(length = 128, default = None) authorized = BoolCol(default = False) # foreign keys goods = ForeignKey("Goods", dbName = "trg\_goods", notNone = True)

4.1


54

Po synchronizaci výše uvedené definice tabulky s relačním databázovým systémem dojde k vytvoření tabulky s odpovídajícími sloupci, navíc je implicitně generován sloupec pro primární klíč s názvem id a cizí klíč do tabulky metadat pro evidenci příslušných informací o záznamu. Níže uvedený kód znázorňuje příklad definice tabulky s vícejazyčnými záznamy: class TransportService(MultiLangSQLObject): class sqlmeta: table = "pub_transport_service" # foreign keys name = ForeignKey("Content", dbName = "sys_content_name", notNone = True) Tato tabulka slouží jako jednoduchý číselník přepravních služeb. Název přepravní služby je cizím klíčem do překladové tabulky. Rodičovská třída MultiLangSQLObject umožňuje elegantní práci s vícejazyčnými záznamy. Výběr všech přepravních služeb v českém jazyce (id = 1) proběhne takto: transport_services = TransportService.select(1) Prvním argumentem metody select je identifikátor příslušného jazyka. Jednotlivé záznamy pak můžeme pomocí cyklu procházet a tisknout na standardní výstup: for t in list(transport_services): print t.name Vložení nové přepravní služby do číselníku v českém jazyce a následné doplnění překladů do ostatních jazyků probíhá takto: new_transport_service = TransportService(lang = 1, name = "pošta") new_transport_service.set(lang = 2, name = "post") Pro práci s databázovými pohledy je vytvořena další rodičovská třída s názvem PgViewObject. Definované pohledy jsou syntakticky specifické pro databázi PostgreSQL, proto je zkratka názvu databáze obsažena v názvu třídy. Jednoduchý pohled, který vrací seznam archivovaných faktur, lze vytvořit pomocí rodičovské třídy PgViewObject takto: class ViewArchiveInvoices(PgViewObject): class sqlmeta: table = "view_invoices_archive" sql = """ SELECT cmp_invoice_type, cmp_period, cmp_branch, number FROM trg_invoice WHERE trg_invoice_type = 1 AND

4.2

Aplikační vrstva – Workflow

55

archive = TRUE """ #columns type = ForeignKey("InvoiceType", dbName = "cmp_invoice_type") period = ForeignKey("Period", dbName = "cmp_period") branch = ForeignKey("Branch", dbName = "cmp_branch") number = UnicodeCol() S vytvořenou třídou je možné dále v kódu pracovat jako se standardní tabulkou s tím, že jednotlivé výsledky provedeného dotazu není možné upravovat. Pro výběr všech archivovaných faktur a jejich tisk na standardní výstup je možné použít následující kód, ve kterém je mimo jiné znázorněn způsob práce s cizími klíči: archived_invoices = ViewArchiveInvoices.select() for a in list(archived_invoices): print "%s, %s, %s, %s" % (a.type.name, a.period.name, a.branch.name, a.number)

4.2


Workflow je implementováno jako autonomní subsystém, který může být využit jakoukoli další částí informačního systému. Z uživatelského pohledu tak může procesem workflow proběhnout jakýkoli objekt (objednávka, faktura, zakázka aj.). 4.2.1

Standard XPDL

Vlastní implementace workflow respektuje standard XPDL (XML Process Definition Language) obecně popsaný v kapitole 2.3. Z tohoto standardu jsou implementovány pouze ty části, které mají význam pro definici procesů podniku. Subsystém workflow je programován s ohledem na možné rozšíření podpory standardu XPDL. Stav implementace standardu shrnuje níže uvedený výčet podporovaných XML tagů (WFMC, 2008): • Package – PackageHeader – WorkflowProcesses ∗ WorkflowProcess Tag „Packageÿ shrnuje definované workflow procesy do jednoho balíčku, pomocí tagu „PackageHeaderÿ následně podává informace o vlastním balíčku a seznam definovaných procesů v tagu „WorkflowProcessesÿ. Jednotlivé procesy definované pomocí tagů „WorkflowProcessÿ obsahují tyto podporované vnořené tagy: • Participants – Participant

4.2


56

∗ ParticipantType • Activities – Activity ∗ Performer ∗ TransitionRestrictions · TransitionRestriction • Transitions – Transition Tag „Participantsÿ definuje množinu účastníků procesu, je implementována podpora pro účastníky typu „roleÿ. Tag „Activitiesÿ definuje množinu aktivit, které mohou provádět účastníci definováni pomocí „Performerÿ. Tag „Transitionsÿ definuje přechody mezi jednotlivými aktivitami. Tag „Activities/Activity/TransitionRestrictionsÿ definuje pravidla pro přechod z jedné aktivity do následných aktivit na základě níže uvedených vnořených tagů: • TransitionRestriction – Join – Split ∗ TransitionRefs · TransitionRef Tag „Joinÿ definuje sloučení přechodů z předchozích aktivit do dané aktivity. Aktivita může být zahájena buď po provedení všech přechodů (atribut type="AND") anebo po provedení alespoň jednoho přechodu (atribut type="XOR"). Tag „Splitÿ definuje rozdělení přechodů z dané aktivity do následných aktivit. Z dané aktivity je možné do následných aktivity provést všechny přechody současně (atribut Type=”AND”) anebo je možné provést jediný z definovaných přechodů (atribut type=”XOR”). Pro vytváření definic procesů podle standardu XPDL je použit open-source grafický editor „Enhydra JaWEÿ, popsaný v kapitole 2.4.1. 4.2.2

Interface subsystému workflow

Subsystém workflow je implementován pro použití v rámci jednotlivých kontrolerů, které implementují práci s vlastními objekty v systému. Kontrolerům je podrobně věnována následující kapitola 4.3. V systému existují kontrolery pro práci se zakázkami, fakturami, objednávkami a dalšími business objekty. Pro použití workflow nad daným objektem použijeme vícenásobné dědičnosti v rámci definice kontroleru. Běžný kontroler dědí třídu „DataControllerÿ, kontroler s podporou workflow dědí navíc třídu „WorkflowControllerÿ. Níže je uveden příklad definice kontroleru pro zakázky s podporou workflow: class JobsController(DataController, WorkflowController): Zděděním třídy WorkflowController rozšíříme metody třídy JobsController o následující metody, které umožní vlastní práci s workflow procesy:

4.3

Aplikační vrstva – Controller

57

workflow() Metoda poskytuje uživatelský interface pro práci s workflow. Uživatelský vstup, který poskytuje tato metoda, vyvolává vždy jednu z následujících metod. start() Metoda spouští nový workflow proces nad daným objektem v případě, že ještě žádný proces nad daným objektem nebyl spuštěn. request() Metoda zpracovává uživatelské požadavky pro běžící workflow. Těmito požadavky mohou být: • provedení přechodu z dané aktivity na další aktivitu, tj. situace, kdy uživatel dokončí svůj úkol a předává provedení následného úkolu jinému uživateli; • delegování dané aktivity jinému uživateli bez uskutečnění přechodu. undo() Metoda vrátí stav procesu workflow o jeden krok zpět v případě, že se proces nachází v ukončující aktivitě a je tím pádem ve stavu „dokončenoÿ. import xpdl() Metoda slouží k parsování souboru s definicí XPDL procesů a k importu podporovaných definic procesů do databáze.

4.3


Stěžejní význam aplikační vrstvy spočívá v zajištění čtyřech klíčových oblastí, některé z nich úzce souvisí s prezentační vrstvou. Způsob implementace jednotlivých oblastí shrnují následující podkapitoly: • • • •

mapování URL na metody tříd, práce s daty, definice a aplikace systémových práv, definice a aplikace obchodních pravidel.

4.3.1

Mapování URL

Základem webové aplikace z pohledu vykonávání požadavků ze strany klienta je návrh vhodné struktury a vhodných pravidel pro URL, dále zajištění mapování URL na metody kontrolerů. Použitý framework Pylons poskytuje výchozí tvorbu a mapování URL v rámci architektury MVC ve tvaru: http://hostname///[?par1=val1&par2=val2&... Tento výchozí stav je vyhovující a je použit pro implementaci. Na základě výše uvedeného schématu pro URL bude například editace faktury s id=123 volána pomocí: http://hostname/invoices/edit/123 Vlastní kontrolery jsou z pohledu programového kódu třídami, které dědí rodičovskou třídu DataController. Název třídy je mapován do výše uvedeného schématu pro URL jako . Akce kontrolerů mapované v URL jako jsou metodami tříd kontrolerů. Mapování z URL odpovídá parametru id metody

4.3


58

třídy kontroleru. Zdrojový kód, který je mapován pomocí URL podle uvedeného příkladu editace faktury může vypadat takto: class InvoicesController(DataController): def edit(self, id): #edit method definition...

4.3.2

Práce s daty

Práce s daty spočívá obecně v jejich vytvoření pomocí vhodných formulářů, v agregaci takto vytvořených dat pomocí tabulkových seznamů a v možnosti úprav či mazání existujících dat. Do této definice spadají také možnosti pro export a import dat. Obecně jsou v systému definovány tři akce pro práci s jednotlivými záznamy v databázi, z pohledu ORM jde o práci s instancemi objektů modelu: • add – umožní přidání nového záznamu, • edit – slouží k editaci libovolného záznamu, • delete – maže existující záznam či více záznamů. Dále jsou definovány dvě akce pro práci s agregovanými daty, tedy s množinou záznamů v databázi: • list – vytvoří pohled na data formou datové tabulky, která načte svůj obsah zavoláním akce xml (viz dále v kapitole Prezentační vrstva – View); • xml – dle zadaných omezení pro filtrování, řazení a počty vrácených záznamů generuje výpis záznamů jako XML soubor (slouží ke zpracování ve výše uvedené akci list); • xls – pracuje obdobně jako akce xml, narozdíl od této akce vrací XLS soubor pro otevření v aplikaci MS Excel či OpenOffice. Vrstva aplikace „Controllerÿ se skládá z kontrolerů (Controllers). Každý kontroler je ve své podstatě souborem s definovanou třídou. Třída běžně dědí rodičovskou třídu WSGIController. Ve vyvíjeném systému je vytvořena nástavba nad třídou WSGIController s názvem DataController. Tato třída definuje obecně všechny výše uvedené akce pro libovolný kontroler tak, aby tyto akce byly automaticky definovány (zděděny) pro každý kontroler. Každý kontroler obsahuje povinný atribut SOobject, který nastavuje primární třídu ORM modelu pro daný kontroler. Dále je pro každý kontroler nastavována v součinnosti s ORM množina polí pro zobrazení ve formuláři a množina polí pro zobrazení v tabulce. Toto nastavení řeší instance třídy DataHandler. Pro instanci třídy DataHandler jsou přidávány „sloupceÿ pomocí metody add col(), například takto: # data handler for rendering form and data grid self.handler = DataHandler("job", filter = True)

4.3


59

self.handler.set_object(self.SOobject) self.handler.add_col("periodID", label_text = _("Year"), option_text = "year", width = "80", fieldset = "general") self.handler.add_col("branch_number", label_text = _("Job Nr."), type ="hidden", in_datagrid = True, width = "105", sort = "ASC") Výše uvedený příklad vytváří novou instanci třídy DataHandler s identifikátorem „ jobÿ. Parametr filter = True aktivuje automatický uživatelský filtr pro prezentační vrstvu. Metoda set object nastavuje konkrétní ORM třídu, která bude jako výchozí pro danou instanci třídy DataHandler. Volání metod add col postupně přidává sloupce, resp. vstupní pole formuláře. Prvním argumentem metody je název sloupce z ORM. Na základě tohoto názvu systém automaticky zjistí datový typ, nastaví formátování a případně nastaví odpovídající vstupní pole pro formulář. Přehled dalších nastavovaných parametrů podává následující výčet: • label text – nastavuje popisek sloupce tabulky, resp. popisek vstupního pole formuláře; • option text – nastavuje, ze kterého sloupce číselníku bude pocházet zobrazená hodnota; • width – šířka sloupce pro datovou tabulku; • fieldset – definice skupiny vstupních polí pro formulář; • type – nastavuje skrytí vstupního prvku, nebude zobrazen ve formuláři; • in datagrid – nastavuje, zdali se má sloupec zobrazit v datové tabulce; • sort – nastavuje vzestupné nebo sestupné řazení podle jednoho vybraného sloupce. Provedené akce add, edit či list zpracují nastavení instance třídy DataHandler pro daný kontroler a zobrazí na základě tohoto nastavení odpovídající formulář či tabulku s daty. Vlastnímu vytvoření uživatelského rozhraní formuláře a tabulky bude podrobně věnována kapitola Uživatelské rozhraní (View). 4.3.3

Systémová uživatelská práva a skupiny

Každý uživatel informačního systému je zařazen ze systémového pohledu do uživatelské skupiny. Uživatelské skupiny jsou implementovány jako stromová datová struk-

4.3


60

tura, ve které probíhá hierarchické dědění práv pro přístup k jednotlivým částem systému. Způsob implementace uživatelských skupin znázorňuje následující přehled: Kořenová skupina stromu: Administrátoři • Majitelé podniku – Skupina s globálními právy ∗ Skupina s globálními právy pouze pro čtení ∗ Skupina s centrálními právy · Skupina uživatelů pobočky Praha ∗ Skupina poboček Skupina administrátorů má neomezená práva v celém systému. Práva podřazených skupin jsou postupně omezována podle hloubky zařazení do stromu práv. Skupina vždy dědí práva všech svých podskupin. Skupině s centrálními právy tak náleží všechna práva skupiny uživatelů pobočky Praha. Skupině s centrálními právy nenáleží žádné s práv skupiny s globálními právy, skupiny majitelů podniku ani skupiny administrátorů. Takto implementované skupiny věrně kopírují organizační strukturu podniku, která je rozhodující pro přidělení práv systémových. Stromová struktura umožní díky dědění práv přidělit množinu práv pro daného uživatele pomocí jediné skupiny. Stromová struktura práv umožňuje jednoduše omezovat přístup k jednotlivým sekcím systému přiřazením jediné skupiny. Nastavování práv řeší příslušný cizí klíč (relace 1:1) tabulky metadat. 4.3.4

Obchodní skupiny a role

Obchodní skupiny jsou podnikové interní organizační jednotky, jejichž členové patří do různých částí organizační hierarchie podniku v rámci jedné pobočky. Obchodní skupiny zpravidla seskupují pracovníky, kteří se společně podílejí na obchodní realizaci zakázky. Jednu zakázku tedy realizuje právě jedna obchodní skupina, každý uživatel je zařazen do právě jedné obchodní skupiny. Zařazení uživatele do skupiny řeší odpovídající cizí klíč v tabulce uživatelů (relace 1:1). Každý zaměstnanec v podniku zastává svou prací alespoň jednu roli. Podnik definuje role Account manager (AM), Product manager (PM) a Účetní. 4.3.5

Obchodní pravidla

Obchodní pravidla vyhodnocují stav workflow procesů, nastavení systémových uživatelských práv i nastavení obchodních skupin a rolí. Na základě vyhodnocení stavu obchodní pravidla rozhodují o přístupu k: • formulářům, • vstupním polím formulářů, • libovolným dílčím prvkům uživatelského interface.

4.3

61


Vlastní obchodní pravidla jsou zapisována centralizovaně pomocí takzvaných lambda-funkcí, které jsou klíčovým nástrojem pro funkcionální programování. Návratovou hodnotou lambda-funkce je vždy jedna z logických hodnot true nebo false. Hodnota true povoluje přístup k danému objektu, hodnota false zakazuje přístup k danému objektu. Obchodní pravidla jsou definována vždy pro určitý typ databázové entity, například pro faktury, zakázky, objednávky a jiné. Zápis pravidel probíhá do tříd, jejichž název odpovídá názvu databázové entity. Pro třídu jsou definovány atributy, které odpovídají atributům databázové entity. Příkladem může být zápis pravidel pro přístup ke zboží: class Goods(BusinessRules): init = lambda self: self.hasrole(’AM’) # and further conditions price_sell_total = lambda self: False class AM: # AM columns name = item_number = sale_quantity = material = price_buy = eta_delivery_place = eta_hamburg = etd =

lambda lambda lambda lambda lambda lambda lambda lambda

self: self: self: self: self: self: self: self:

True True True True False False False False

class PM: # PM columns name = item_number = sale_quantity = material = price_buy = eta_delivery_place = eta_hamburg = etd =

lambda lambda lambda lambda lambda lambda lambda lambda

self: self: self: self: self: self: self: self:

False False False False True True True True

Atribut init třídy Goods obsahuje obecná pravidla pro přístup ke všem atributům zboží. Pokud atribut init nabývá hodnoty false, je automaticky zablokován přístup ke všem atributům zboží a nejsou vyhodnocovány další pravidla (lambda-

4.4

Prezentační vrstva – View

62

funkce). Pokud atribut init nabývá hodnoty true, jsou vyhodnoceny všechna následující pravidla. Tato pravidla můžou být nezávislá na roli uživatele, jako v případě pravidla pro price sell total, kdy je celková prodejní cena zboží vždy nepřístupná pro editaci (protože je automaticky vypočtena jako součin množství a ceny). Pravidla můžou být dále závislá na roli uživatele. Tato pravidla jsou zapsána do podtříd AM a PM. Definovaná obchodní pravidla jsou aplikována na provádění dílčích metod ve zdrojovém kódu pomocí takzvaných dekorátorů. Dekorátorem je zvláštní funkce, která ovlivní vykonání jiné funkce (metody). V případě uvedených obchodních pravidel je dekorátor aplikován na metodu add col(), která zajišťuje vkládání vstupních polí do formulářů: @business_rules def add_col(self, column_name = None, *args, **kw): #method definition... Dekorátor je na metodu aplikován pomocí syntaxe @business rules. Tento dekorátor vyhodnotí pro každé vkládané vstupní pole dané databázové entity (např. výše uvedený příklad zboží) definovaná obchodní pravidla. Na základě vyhodnocení pravidel pak nastaví vstupní pole pro uživatele jako editovatelné či nepřístupné pro editaci.

4.4


Prezentační vrstva aplikace je tvořena kódem HTML, ve kterém jsou v případě potřeby použity zdrojové kódy jazyka Java Script či volání funkcí jazyka Java Script. Kód HTML je doplněn CSS styly. Veškerý HTML kód je obsažen v takzvaných šablonách systému Genshi. Je striktně zakázáno používat HTML kód mimo šablony. 4.4.1

Šablonovací systém

Šablonovací systém Genshi slouží primárně k prezentaci dat z kontrolerů ve formátu HTML. Systém obsahuje zvláštní syntaxi pro vkládání proměnných z příslušných kontrolerů, dále syntaxi pro takzvané direktivy šablon, které usnadňují vytváření HTML kódu šablon. Těmito direktivami jsou podmínky, cykly, definice pro makra, manipulace s HTML tagy a komentáře. Pro zvýšení znovupoužitelnosti kódu šablon je využit takzvaný XInclude (XML Inclusions), který umožní vkládat do vytvářené šablony již existující šablony. Níže je uvedena kompletní Genshi šablona jako příklad syntaxe zápisu direktiv pro podmínku, cyklus: lang="en"> <xi:include href="base.html" />

4.4


63

${title}

${item}

V kódu šablony je podstatná syntax pro vkládání proměnných z kontrolerů v podobě ${promenna}. Proměnné z kontrolerů jsou do šablon vkládány pomocí takzvaného generování šablony. Následně je vygenerovaná šablona vyrenderována podle požadovaného způsobu. Načtení, generování a renderování výše uvedené šablony (test.html) znázorňuje následující příklad: from genshi.template import TemplateLoader loader = TemplateLoader([templates_dir1, templates_dir2]) tmpl = loader.load("test.html") stream = tmpl.generate(title="Hello, world!", attributes={"class": "menu"}, items=["item1", "item2"]) print stream.render() 4.4.2

Formuláře

Formuláře jsou implementovány pomocí modulu „tw.formsÿ, který obsahuje sadu formulářových prvků (ToscaWidgets) pro sestavování HTML formulářů a jejich validaci na straně serveru. Následující příklad ilustruje způsob vytváření formulářů: import tw.forms as twf movie_form = twf.TableForm(’movie_form’, action=’save’, children=[ twf.HiddenField(’id’), twf.TextField(’title’, validator=twf.validators.NotEmpty), twf.TextField(’year’, size=4, validator=twf.validators.NotEmpty), twf.CalendarDatePicker(’release_date’), twf.SingleSelectField(’genera’, options=[’’, ’Action’, ’Comedy’, ’Other’]), twf.TextArea(’description’), ]) Nad tw.forms je provedena nástavba, která upravuje podobu formulářů a vstupních polí. Nástavba také definuje některá nová formulářová vstupní pole, zejména WYSIWYG editor TinyMCE.

4.4


4.4.3

64

Tabulky s daty

Tabulky pro práci s daty jsou implementovány pomocí technologie Java Script XMLHttpRequest. Tabulky jsou dynamicky vytvářeny na základě definovaných sloupců a datového modelu, způsob definice je popsán v kapitole 4.3.2. Na základě definic je vytvořeno záhlaví tabulky, uživatelské filtry a ovládací prvky tabulky. Obsah jednotlivých řádků tabulky je načítán pomocí Java Script metody XMLHttpRequest. Na server je odeslán požadavek na data v podobě HTTP GET požadavku, server vrátí odpověď ve formátu XML. Odpověď je zpracovaná na straně klienta do výsledné tabulky uživatelského rozhraní. Požadavek na výpis všech faktur je například odeslán pomocí URL: http://hostname/invoices/xml?id=invoice_data&page_size=50&offset=0& get_total=true&s2=ASC Pro volání požadavku na data metodou GET jsou užity následující parametry: • id: DOM identifikátor tabulky v uživatelském rozhraní klienta, kde může být více tabulek; • page size: velikost jedné stránky udaná počtem řádků, které mají být vráceny v odpovědi; • offset: pořadové číslo záznamu, který má být počátečním záznamem odpovědi. Pokud je hodnota offset rovna nule, jsou vráceny záznamy v pořadí 0 až 49, tzn. první stránka. Druhou stránku získáme nastavením parametru offset na hodnotu 50, budou vráceny záznamy v pořadí 50 až 99 a tak dále; • get total: pokud parametr obsahuje logickou hodnotu „trueÿ, je v odpovědi navíc uveden celkový počet záznamů; • s2: tento parametr nastavuje výchozí řazení podle druhého sloupce v odpovědi, hodnotou parametru mohou být konstanty „ASCÿ pro vzestupné řazení a „DESCÿ pro sestupné řazení. Níže je uveden příklad část XML odpovědi (pro přehlednost je uvedeno prvních pět sloupců tabulky) na požadavek výpisu všech faktur při parametru page size=3: 552009ZF93839948 562009ZF50913720 572009F20090010

4.4


65

76 <mydebug>{} V odpovědi je vždy první buňka na řádku prázdná. Tato buňka je v uživatelském rozhraní vyplněna vždy jedním z určených ovládacích prvků pro celou tabulku jednotně: • vstupní pole typu checkbox : je určené pro označování libovolného počtu řádků tabulky (např. mazání označených záznamů), • vstupní pole typu radio: slouží k označení nejvýše jednoho záznamu v tabulce (např. výběr objednávky pro likvidaci na danou fakturu). Mezi další ovládací prvky tabulky patří horizontální a vertikální posuvníky, tlačítka pro přechod na předchozí a následující stranu, tlačítka pro přechod na první stránku a na poslední stránku. Dále jsou nad tabulkou umístěny tlačítko pro export dat z tabulky do souboru formátu MS Excel a tlačítko pro zrušení všech nastavených filtrů (viz dále). Záhlaví tabulky jsou přiřazeny akce po klepnutí tlačítkem myši. Klepnutí levým tlačítkem nastavuje řazení dat dle daného sloupce vzestupně či sestupně. Klepnutí levým tlačítkem zobrazí vstupní pole pro jednoduchý filtr nad daným sloupcem. Hodnota, která je vepsána do filtrovacího pole je vyhodnocena v databázi jako LIKE "hodnota%". Nad tabulkou je dále k dispozici pokročilý filtr s následujícími vstupními poli: • column name: výběrové vstupní pole pro volbu jednoho sloupce, • operation type: výběrové vstupní pole, které podle datového typu sloupce zvoleného v předchozím bodu nabídne možné relace pro srovnávání, po zadání hodnoty pro filtrování provede příslušný SQL dotaz: – starts with: sloupec LIKE "hodnota%" – with the value: sloupec LIKE "%hodnota%" – without the value: sloupec NOT LIKE "%hodnota%" – greater than or equal: sloupec >= hodnota – less than or equal: sloupec <= hodnota • value: slouží k zadání hodnoty pro filtrování, • add, delete: tlačítka, která slouží k přidání nového kritéria pro filtrování či k výmazu daného kritéria pro filtrování. Tabulka s daty je implementována jako rozšíření open-source knihovny Rico 2.0 LiveGrid. Rozšíření knihovny proběhlo zejména v oblastech: • • • • •

filtrování, ovládání tabulky pomocí klávesnice a myši, možnost otevírání záznamů z tabulky na základě ID záznamů, propojení s modulem pro export dat do formátu MS Excel, vylepšení grafického designu tabulky.

4.4


66

Podrobný popis práce s tabulkou i s dalšími komponentami uživatelského rozhraní je uveden v uživatelském manuálu, který je přílohou této práce. Uživatelský manuál obsahuje kromě práce s uživatelským rozhraním návod na provádění častých úkonů. V přílohách této práce jsou dále umístěny náhledy obrazovek, které výstižně ilustrují design uživatelského prostředí popsaný v kapitole 3.8.

5

ZHODNOCENí REALIZOVANÉHO PROJEKTU

5

67

Zhodnocení realizovaného projektu

5.1

Zhodnocení životního cyklu

Jednotlivé fáze životního cyklu projektu od hrubého zadání po testovací provoz v produkčním prostředí probíhaly celkem 16 měsíců, z toho: • 6 měsíců probíhala analýza a projektování, • 7 měsíců programátorské práce, • 3 měsíce trval testovací provoz v produkčním prostředí. V průběhu výše uvedených šestnácti měsíců probíhaly práce na novém informačním systému a zároveň dílčí úpravy a údržba stávajícího IS z důvodů změn vnitřního a vnějšího prostředí firmy. Práce na novém informačním systému trvaly celkem 1 140 hodin. Úpravy a údržba stávajícího IS trvaly celkem 650 hodin. V prvních šesti měsících vývoje převažovaly práce na původním informačním systému nad pracemi na novém IS. V sedmém měsíci prací začal objem prací na původním IS stále klesat až do čtrnáctého měsíce, kdy práce na původním IS zcela ustaly. Průběh fáze testovacího provozu v produkčním prostředí vystihuje přehled počtů programových chybových zpráv, vytvořených pomocí systému pro správu chyb. Počty chyb jsou stanoveny jako průměrné denní množství chyb na jednoho uživatele informačního systému: 1. měsíc: 0,199 2. měsíc: 0,088 3. měsíc: 0,125 V následujících měsících po skončení testovacího provozu byla vygenerována následující množství chybových zpráv. Tyto zprávy jsou zejména informativního charakteru. Týkají se chybových stavů, které vznikly nekorektním užitím některých částí aplikace. 1. měsíc: 0,049 2. měsíc: 0,055

5.2

Ekonomické zhodnocení

Obecně lze metriky ekonomických přínosů rozdělit na kategorii metrik pro vývoj a zavedení IS a kategorii metrik pro inovace IS. V rámci každé kategorie lze vyhodnotit řadu finančních a technických kritérií. Metriky finančních kritérií hodnocení investic do IS lze členit na metriky nákladových kritérií, ziskových kritérií a metriky kritérií efektivnosti investic. Mezi nákladová kritéria patří ukazatel průměrných ročních nákladů a diskontovaných nákladů. Do kategorie ziskových kritérií lze řadit průměrnou výnosnost a dobu návratnosti. Kritéria efektivnosti investic hodnotí čistá současná hodnota a vnitřní výnosové procento (Učeň, 2001).

5.2

Ekonomické zhodnocení

68

Ukazatele ziskových kritérií a ukazatele efektivnosti investic kalkulují se ziskem a peněžními příjmy podniku. Tyto údaje jsou obchodním tajemstvím podniku, a proto není možné uvádět v této práci výpočty výše uvedených ukazatelů. Níže jsou uvedeny výpočty metrik nákladových kritérií pomocí ukazatele průměrných ročního nákladů pro původní a nový informační systém. Z pohledu podniku je nákupní cenou vytvořeného informačního systému suma nákladů na práci jednotlivých pracovníků vývojového týmu. Cena hardwarových prostředků není započítána, protože nový informační systém bude využívat disponibilní kapacitu stávajícího hardwarového vybavení podniku. Cena práce byla stanovena ve výši 400 Kč za jednu člověkohodinu jakékoli vykonávané práce. Výsledná cena je součinem T C = w.L, kde w je cena práce ve výši 400 Kč a L je celkový počet člověkohodin ve výši 1 140 (viz kapitola 5.1). Celkové náklady, respektive nákupní cena IS pro podnik, činí celkem 456 000 Kč. Životnost IS je odhadována na 4 roky, účetní odpisy jsou stanoveny odpisovou sazbou 25 % ročně. Roční provozní náklady na údržbu a správu jsou odhadovány na 150 000 Kč. Úroková sazba je stanovena ve výši 2,5 %. Průměrné roční náklady lze vyjádřit jako R = O + iJ + V , kde O jsou roční odpisy, i je úrokový koeficient, J je investiční náklad a V jsou ostatní roční provozní náklady. (Učeň, 2001). Dosazením odpovídajících hodnot získáme hodnotu průměrných ročních nákladů pro nový informační systém Rnovy = 725 400 Kč. Pro výpočet průměrných ročních nákladů na provoz původního informačního systému položíme O = 0, J = 0, celkové provozní náklady V stanovíme na základě průměrných ročních nákladů na provoz původního IS za dobu jeho provozu ve výši 182 000 Kč. Průměrné roční náklady na provoz původního informačního systému jsou vypočteny jako Rpuvodni = 728 000 Kč. Náklady na údržbu, správu a úpravy původního informačního systému činily ve sledovaném období 57 % z nákladů na vytvoření nového informačního systému za předpokladu stejných cen prací na novém i původním IS. Je zřejmé, že provoz původního informačního systému byl velice nákladný. Ze srovnání hodnot ukazatelů průměrných ročních nákladů pro nový a původní systém vyplývá jako vhodnější řešení právě nový IS. Nový informační systém byl od počátku vytvářen s ohledem na co nejjednodušší správu a co nejsnazší aplikaci změn. Nový informační systém přinese podniku úspory v platbách za správu a implementaci změn během provozu systému v následujících letech. Z pohledu podniku je možné srovnat náklady na vytvoření nového informačního systému s náklady na implementaci informačního systému Navision, který byl v podniku nasazen již před započetím vývojových prací na novém IS. Celková cena implementace systému Navision činila 1 500 000 Kč a zahrnovala pouze účetní moduly. Doba implementace činila 6 měsíců. Náklady na vytvoření nového IS činily pouhých 30 % ceny implementace systému Navision. Vzhledem k podobné míře vnitřní složitosti obou informačních systémů lze konstatovat, že vývoj nového informačního systému na míru znamenal pro podnik značnou úsporu finančních prostředků.

6

6

DISKUSE

69

Diskuse

Každý projekt podnikového informačního systému je unikátním z pohledu zúčastněných osob, které mají vliv na všechny klíčové aspekty výsledného řešení implementace. Všechny projekty rovněž sdílí společný hlavní cíl, kterým je uspokojení potřeb zadavatele projektu splněním stanovených plánů. Cíle projektu, který popisuje tato práce, lze dosáhnout řadou jiných metod, technologií a technických řešení. Stěžejními faktory, které ovlivní všechna následující rozhodnutí, je vždy volba programovacího paradigmatu, programovacího jazyka a metodiky implementace. Rozhodnutí o těchto stěžejních faktorech vždy podléhá značně subjektivním vlivům. Ve své podstatě může být informační systém programován objektově či strukturovaně za použití libovolného programovacího jazyka a libovolné metodiky. Takový je pohled podnikového zákazníka, který očekává spolehlivé a fungující řešení. Zákazník většinou nepotřebuje, a dokonce nechce vědět, jakým způsobem bylo daného řešení dosaženo. Popisovaný informační systém tedy mohl být vytvořen za použití technologií zcela odlišných od těch, které popisuje kapitola 3. Stejně tak mohlo být užito jiných metod v průběhu vlastní implementace, popsané v kapitole 4. Použití dané metodiky či technologie je závislé zejména na zkušenostech, znalostech a schopnostech strategického myšlení odpovědných osob, které svým rozhodnutím mohou pozitivně či negativně ovlivnit životnost produktu, jeho schopnost přizpůsobovat se změnám prostředí a možnosti pro rozšiřování či zlepšování funkcionality. Mezi silné stránky popsaného řešení patří přenositelnost, interoperabilita a možnosti rozšíření díky značné obecnosti algoritmů. Informační systém využívá pouze komponenty z kategorie open-source software. Nevýhodou řešení může být volba použitého programovacího jazyka z pohledu dostupnosti programátorů na trhu práce. V České republice nepatří v současné době jazyk Python mezi rozšířené a často používané jazyky. Použití open-source řešení v podnikové sféře může být diskutabilní, nicméně v poslední době se v této sféře otevřená řešení úspěšně prosazují. Vhodnost použití open-source potvrzují samotné výsledky této práce.

7

7

ZÁVĚR

70

Závěr

Podnikový informační systém byl přes drobné komplikace ve fázi „testování v produkčním prostředíÿ úspěšně implementován. Průběh projektování a průběh vlastních stěžejních programátorských prací byl zevrubně popsán v odpovídajících kapitolách této práce. Řada kapitol je věnována výběru vhodných technologií a postupů potřebných pro provedení vlastní implementace. V současné době systém používá více než padesát uživatelů ze všech poboček podniku. Uživatelé používají informační systém při každodenní práci, systém se stal nezbytnou klíčovou součástí pro vlastní fungování a podnikatelskou činnost podniku. Implementace nového informačního systému se stala pro podnik úsporou budoucích nákladů na údržbu, správu, rozšíření systému a implementaci nové funkcionality do systému v následujících letech životnosti informačního systému. Práce rovněž podala přehled napříč různými metodikami vývoje informačních systémů, teoretické aspekty počítačového zpracování podnikových procesů pomocí Petriho sítí a v neposlední řadě poskytla důkladnou analýzu situace na trhu ERP systémů v České republice.

8

8

LITERATURA

71

Literatura

Buchalevcová, A. Metodiky vývoje a údržby informačních systémů : kategorizace, agilní metodiky, vzory pro návrh metodiky. 1. vyd. Praga: Grada Publishing, 2005. 163 s. Management v informační společnosti. ISBN 80-247-1075-7 . Chu-Carroll, Mark C. Colored Petri Nets [online]. 2007 [cit. 2008-12-12]. Dostupný z WWW: . Češka, M. a kol. Petriho sítě : Studijní opora. 2006. 244 s. Dostupný z WWW: . Dong, Ming, Chen, F. Frank. Petri net-based workflow modeling and analysis of the integrated manufacturing business processes. The International Journal of Advanced Manufacturing Technology. 1.10.2005, vol. 26, no. 9-10, s. 1163-1172. ISSN 1433-3015. Gála, L. – Pour, J. Podniková informatika: počítačové aplikace v podnikové a mezipodnikové praxi, technologie informačních systémů, řízení a rozvoj podnikové informatiky. 1. vyd. Praha: Grada, 2006. 482 s. Management v informační společnosti. ISBN 80-247-1278-4. Gardner, J. The Definitive Guide to Pylons. Apress, Berkeley 2008. 568 s. ISBN 978-1-4302-0534-0. Jedlička, P. Objektová Petriho síť [online]. [2008] [cit. 2008-12-12]. Dostupný z WWW: . Zur Muehlen, M. Workflow-based Process Controlling : Foundation, Design and Application of Workflow-driven Process Information Systems. Berlin : Logos Verlag, 2004. 282 s. ISBN 3-83250388-9 . Rosenau, Milton D. Řízení projektů. Computer press, Brno 2007. 344 s. ISBN 978-80-251-1506-0 . Svozilová, A. Projektový management. Grada Publishing, Praha 2006. 360 s. ISBN 80-247-1501-5 . Učeň, P. a kol. Metriky v informatice: jak objektivně zjistit přínosy informačního systému. 1. vyd. Praha: Grada, 2001. 139 s. Management v informační společnosti. ISBN 80-247-0080-8. . The Workflow Management Coalition. Workflow Management Coalition Workflow Standard : Process Definition Interface – XML Process Definition Language. [s.l.] : [s.n.], 2008. 217 s .

Přílohy

A

UŽIVATELSKÝ MANUÁL

A

73

Uživatelský manuál

A.1

Pracovní prostředí Workflow

Do pracovního prostředí Workflow (dále „WFÿ) vstoupíme přes webový prohlížeč7 zadáním adresy http://wf/. Na této adrese je připraven rozcestník pro vstup do různých verzí WF. Do verze 2009 se dostaneme kliknutím na odkaz „WF 2009ÿ. Do vlastního pracovního prostředí vstoupíme po zadání uživatelského jména (login) a hesla (password). Pokud neznáte své uživatelské jméno nebo heslo, kontaktujte administrátora systému. A.1.1

Horní panel

Pracovní prostředí je rozděleno do tří celků. Horní šedý pruh s logem firmy obsahuje základní navigační prvky: pohyb vpřed, pohyb zpět a znovunačtení aktuální pozice. V pravé části pruhu jsou postupně zobrazeny následující položky: • vaše jméno a příjmení, níže je uvedena pobočka, pod kterou pracujete; • tlačítko „Odhlásitÿ, které použijete pro ukončení práce s WF; • tlačítko „Nastaveníÿ, které použijete pro změnu svého hesla do WF, telefonního a e-mailového kontaktu; • tlačítko „Tiskÿ slouží k vytištění obrazovky, kterou vidíte na svém monitoru; • tlačítko „Češtinaÿ slouží k přepínání jazyků a zároveň zobrazuje aktivní jazyk pro vaši práci. Pod horním šedým pruhem je zobrazena základní nabídka WF v podobě záložek. První záložkou, která je vždy automaticky zvolena po vašem přihlášení, je záložka s názvem „Homeÿ. Následují záložky pojmenované „Zakázkyÿ, „Fakturyÿ, „Reportyÿ a „Kontaktyÿ. Záložka „Homeÿ obsahuje výpis vašich osobních úkolů. Obsahu jednotlivých záložek se budeme věnovat v dalších kapitolách této příručky. Horní šedý pruh spolu s navigačními záložkami představují tzv. „horní panelÿ, který můžete v případě potřeby skrýt klepnutím na ikonu pro skrytí horního panelu. A.1.2

Levý panel

Pod horním panelem následuje tzv. „levý panelÿ. Zde naleznete kontextovou navigaci určenou pro aktuálně otevřenou stránku WF a výpis oblíbených položek. Levý panel můžete skrýt obdobně jako horní panel. A.1.3

Hlavní panel

Vpravo od levého panelu je zobrazen hlavní panel. Tento panel zobrazuje všechny potřebné formuláře, reporty a přehledy. Nejčastěji budete pracovat s přehledy dat v tabulkách. Tyto tabulky mají podobné vlastnosti jako tabulky MS Excel. 7

Podporované webové prohlížeče jsou Internet Explorer 7, Firefox 3, Opera 9.

A.1


74

Nad každou tabulkou je zobrazený ovládací pruh. První zleva je zobrazena záložka „Filtrÿ, která po otevření příslušným ovládacím prvkem nabídne pokročilé možnosti filtrování dat v tabulce. Pro filtrování vždy zvolíme z nabídky sloupec, který chceme filtrovat, zvolíme druh filtrování dat (hledání přesně zadané hodnoty, hledání podle prvních zadaných znaků, hledání větších/menších čísel) a nakonec zadáme hodnotu, podle které proběhne filtrování. Pro volbu více kritérií použijeme tlačítko „Přidatÿ, kterým můžeme přidat libovolný počet filtrovacích kritérií. Vpravo od záložky „Filtrÿ nalezneme další ovládací prvky: • Export do XLS: tímto tlačítkem vyexportujeme aktuální přehled dat do aplikace MS Excel8 ; • Vyčistit filtr: tímto tlačítkem zrušíme všechny nastavené filtry; • Navigační prvek: slouží pro pohyb po jednotlivých řádcích či stránkách tabulky s daty: – dvě šipky směřující vlevo posunou pohled na začátek, – dvě šipky směřující vpravo posunou pohled na konec výpisu, – šipka směřující vlevo posune výpis o jednu stránku vpřed, – šipka směřující vpravo posune výpis o jednu stránku zpět. • V prostřední části navigačního prvku je zobrazena poloha aktuálního pohledu na data, např. „1 – 14 / 182ÿ. Údaj „1 – 14ÿ znamená, že na obrazovce vidíme řádky v pořadí 1. až 14. řádek. Údaj „182ÿ značí celkový počet řádků tabulky. V tabulce se můžeme pohybovat také použitím svislého a vodorovného posuvníku pro pohyb vlevo, vpravo, nahoru či dolu. Vlastní tabulka se skládá ze záhlaví tabulky, sloupců a řádků dat. Záhlaví tabulky obsahuje názvy zobrazených sloupců. Sloupec, podle kterého jsou data seřazena, je zvýrazněn orámováním a dvěma šipkami. Šipky znázorňují dva způsoby řazení, vzestupně a sestupně. Způsob řazení změníme kliknutím levým tlačítkem myši na odpovídající záhlaví. Takto můžeme seřadit data podle libovolného sloupce v záhlaví tabulky vzestupně či sestupně. Záhlaví tabulky slouží také k jednoduchému filtrování dat bez použití výše popsaného pokročilého filtru. Filtrování nad libovolným sloupcem zahájíme klepnutím pravým tlačítkem myši na záhlaví. Zobrazí se vstupní pole pro zadání filtrovacího kritéria. Filtrování funguje na základě použití prvních zadaných znaků. Pokud například budeme filtrovat zakázky podle čísla, po zadání hodnoty „Gÿ dostaneme výpis všech skupinových zakázek s prefixem „Gÿ (např. G0001, G0002, atd.). Filtr zrušíme opětovným klepnutím pravým tlačítkem myši na odpovídající sloupec či použitím tlačítka „Vyčistit filtrÿ.

8

Podporované verze MS Excel 97, 2000, 2003, 2007

A.1


A.1.4

75

Klávesy pro ovládání tabulky

• • • • •

Šipka nahoru: posune výpis dat o jeden záznam nahoru; šipka dolu: posune výpis dat o jeden záznam dolu; šipka vpravo: posune výpis dat o jeden sloupec vpravo; šipka vlevo: posune výpis dat o jeden sloupec vlevo; enter: otevře položku, na které je kurzor, ve stejném okně (tzn. otevře řádek tabulky, který je obarven oranžově); • ctrl+enter: otevře položku, na které je kurzor, v novém okně; • delete: smaže všechny označené položky (položky, které jsou zatržené v prvním sloupci a obarvené modře), pokud máme právo na mazání. A.1.5

Ovládání tabulky myší

• Kliknutí levým tlačítkem na řádek: označení řádku (zatrhne se políčko v prvním sloupci tabulky a řádek se obarví modře); • dvojité kliknutí levým tlačítkem na řádek: otevření položky ve stejném okně; • ctrl+dvojité kliknutí levým tlačítkem na řádek: otevření položky v novém okně; • pravé tlačítko myši na libovolnou buňku tabulky: zobrazení pokročilých možností pro zobrazení tabulky. Zde můžeme zobrazovat a skrývat jednotlivé sloupce tabulky, nastavovat filtry a řazení dat. • Scrollovací kolečko myši: posouvá výpis dat směrem nahoru či směrem dolu. A.1.6

Obecně platná pravidla

• Zaokrouhlování: všechna čísla jsou zaokrouhlena na čtyři platná desetinná místa. • Mazání položek není povoleno s výjimkou: – záznamů o likvidaci došlých faktur, – neautorizovaného zboží (neplatí pro centrální zboží, které nelze smazat), – objednávek na neautorizované zboží (neplatí pro objednávku do Prahy, kterou nelze smazat). • Pokud potřebujete smazat položku, kterou podle výše stanovených pravidel nemůžete vymazat, kontaktujte administrátora systému. • Software Workflow 2009 je kompletně vícejazyčný, může být jednoduše přeložen do libovolného počtu cizích jazyků. Pro zavedení nového překladu kontaktujte administrátora. A.1.7

Uživatelská práva

Naše práva a oprávnění pro různé činnosti v systému WF 2009 je určeno nastavením různých práv. Schéma práv je následující:

A.1


76

• Skupina: můžeme být zařazeni do jedné z následujících hierarchicky uspořádaných skupin: – Global user: vidí záznamy všech poboček a může je upravovat; ∗ Global user readonly: vidí záznamy všech poboček, upravovat může pouze záznamy vlastní pobočky; ∗ Central user: má přístup k centrálním zakázkám a k zakázkám své pobočky, může je upravovat; · Prague user: má přístup pouze k zakázkám pražské pobočky pro čtení i pro úpravy; ∗ Branch user: má přístup k zakázkám vlastní pobočky a k centrálním zakázkám pro čtení i pro úpravy; • Pracovní skupina: určuje zařazení to pracovní skupiny v rámci interních pravidel (H0, H1, H2, . . .atd.) • Pobočka: určuje zařazení k určité pobočce (Praha, Bratislava, Budapešť, . . .atd.) • Role: přiřazení libovolných rolí z výčtu: – Account manager (AM), – Product manager (PM), – Book Keeper (UCTO). Pokud si myslíte, že vaše aktuálně nastavená práva nejsou v pořádku a potřebujete změnit nastavení práv dle výše uvedeného přehledu, kontaktujte administrátora systému.

A.2

A.2

Vytvoření zakázky

77


Novou zakázku můžete vytvořit pouze v případě, že máte nastavenou roli AM. Novou zakázku vytvoříme v záložce „Zakázkyÿ klepnutím na tlačítko „Nová zakázkaÿ v levém panelu. Novou zakázku můžeme také vytvořit klepnutím na tlačítko „Nová zakázkaÿ v oblíbených položkách, které jsou dostupné v libovolném místě WF vždy v levém panelu. Na obrazovce pro novou zakázku vyplníme formulář s následujícím obsahem: • Skupina obecných informací o zakázce: – Rok: rok, do kterého je zakázka zařazena obchodně. Nemusí se shodovat s rokem, ve kterém byla zakázka vytvořena. – Workgroup: pracovní skupina, je automaticky přednastavena dle vašeho zařazení do konkrétní pracovní skupiny. – Jméno: libovolné pojmenování zakázky. Toto pole je povinné. – Značka: značka (brand) zakázky. Toto pole je povinné, automaticky nabízí existující značky dle zadaných písmen. Všechna povinná pole jsou označena červenou ikonou šipky vedle popisku pole. • Skupina informací o klientovi: klienta lze vybrat z databáze existujících klientů. Po zadání několika prvních písmen se zobrazí nabídka volby existujícího klienta. Přes tento formulář můžete rovněž zadat nového klienta, který se po uložení automaticky uloží do databáze klientů. – Klient: jméno klienta, toto pole je povinné – IČO – DIČ – Ulice – PSČ: není povinný údaj. Město a stát neurčujeme podle PSČ, protože PSČ není používané celosvětově pro všechny státy. – Město: na základě zvoleného města je automaticky přiřazen stát. Stát tedy není nutné vyplňovat. Toto pole je povinné. Pokud v seznamu měst nenaleznete potřebné město, pošlete administrátorovi žádost o přidání nového města případně nového státu. – Telefon – E-mail – Fax • Skupina informací o kontaktní osobě: tato skupina informací není povinná. – Kontaktní osoba – Kontaktní osoba telefon – Kontaktní osoba email – Kontaktní mobil • Skupina informací o skladu: tato skupina informací není povinná.

A.2


– – – – –

Sklad Sklad Sklad Sklad Sklad

78

kontaktní osoba telefon od do

Formulář uložíme klepnutím na oranžové tlačítko „Uložitÿ umístěné nad formulářem a pod formulářem. V případě, že došlo k chybě v zadání informací (například pokud nevyplníte povinná pole), zobrazí se výzva k opravě chyb. Chybně vyplněná pole jsou pro snazší orientaci zvýrazněna červenou barvou. Po úspěšném uložení je zobrazeno prostředí pro další práci se zbožím, objednávkami a dalšími detaily zakázky Každá zakázka obsahuje následující záložky: • klient: výchozí záložka, kde jsou zobrazené základní údaje o zakázce; • celkový KL: záložka obsahuje celkový kalkulační list; • fakturace: záložka slouží k fakturaci zakázky klientovi; • workflow: záložka obsahuje prostředí pro předávání či delegování jiným pracovníkům, kteří se účastní procesu zpracování zakázky. A.2.1

Skupinová zakázka

Skupinovou zakázku vytvoříme klepnutím na tlačítko „Nová skupinová zakázkaÿ, které nalezneme v navigaci pod záložkou „Zakázkyÿ. Vytvoření skupinové zakázky se řídí výše uvedenými pravidly pro vytvoření zakázky. Skupinová zakázka se od běžné zakázky liší v těchto bodech: • na zakázku nelze vytvořit odchozí faktury; • číslování se řídí odlišnými pravidly, viz níže. A.2.2

Číslování zakázek

Každá zakázka má dva druhy čísel. Takzvaný krátký formát čísla zakázky je ve tvaru „X0000ÿ, kde X je nepovinný prefix (viz níže), na místě nul je uvedeno číslo zakázky. Konkrétní příklad krátkého formátu je „G0023ÿ. Takzvaný dlouhý formát čísla zakázky obsahuje krátký formát a navíc sadu dodatečných informací. Dlouhý formát je ve tvaru „RR KF / UZ-SK-PO | KL | NA | ZNÿ, uvedené zkratky znamenají: • RR: rok ve dvojciferném vyjádření (např. 09 pro rok 2009); • KF: krátký formát čísla zakázky (např. G0023); • UZ: uživatel, který vytvořil zakázku, ve tvaru tří velkých písmen (např. KKK); • SK: skupina, do které patří uživatel, který vytvořil zakázku (např. H0); • PO: trojmístný kód pobočky, do které patří zakázky; • KL: klient zakázky; • NA: název zakázky;

A.2


79

• ZN: značka zakázky.

• • • •

Pro vytváření krátkého formátu čísla zakázky platí následující výčet pravidel: každá pobočka má vlastní číselnou řadu pro zakázky, která začíná číslem 0000 a končí číslem 9999; centrální zakázky (viz níže) mají vlastní číselnou řadu; pro centrální zakázky je před číslo zakázky zařazen prefix „Cÿ (např. C0023) pro skupinové zakázky je před číslo zakázky zařazen prefix „Gÿ (např. G0023).

A.2.3

Vytvoření nového zboží

Nové zboží pro zakázku vytváříme vždy v otevřené zakázce pomocí tlačítka „Nové zbožíÿ v navigaci. Formulář pro zboží obsahuje následující informace: • Skupina obecných informací o zboží: – jméno: libovolný název pro zboží, bude automaticky navržen při fakturaci, povinný údaj, – číslo zboží, – materiál, – barva materiálu, – velikost, – balení, – barva obalu, – recykl. znak, – množství prodej: povinný údaj, – termín dodání: povinný údaj, – prodejní cena: plánovaná cena za jeden kus zboží, – celkem: dopočítá automaticky součin „množství prodejÿ a „prodejní cenaÿ. • Skupina informací o logu: – aplikace loga, – pozice loga, – velikost loga, – barva loga, • Skupina informací o obalu: – shipping mark karton, – shipping mark obal, – ks karton, – velikost kartonu, – CBM, – celní sazebník, – ETD: povinný údaj, – ETA Hamburg: povinný údaj, – ETA místo určení: povinný údaj.

A.2


80

• Skupina dalších informací o zboží – specifikace. Po uložení vyplněného formuláře je zboží zobrazeno jako obdélník, ve kterém je uveden název zboží. Vpravo vedle názvu zboží je umístěna červená ikona pro vymazání zboží. Ve spodní části obdélníku je umístěna ikona pro zobrazení objednávek zboží. Zboží můžeme upravit klepnutím na jeho název či vymazat klepnutím na červenou ikonu. A.2.4

Vytvoření nové objednávky

Novou objednávku zboží vytváříme vždy v otevřeném zboží pomocí tlačítka „Nová objednávkaÿ. Zobrazí se formulář k vyplnění následujících polí: • Skupina obecných informací o objednávce: – rok, – artikl: toto pole je povinné, – typ objednávky: volba jednoho z následujících typů: Goods, DHL, Internal freight, Foreign freight, Duty, Imprint, Tooling, Commission, Graphic, Express post, Messenger, Samples, Catalogues, Travelling expenses, Contract of services, Certificates, Packing, Cover, Working. Jako výchozí je nastavený typ Goods. • Skupina informací o množství a ceně: – cena: jednotková plánovaná cena, – množství: plánované objednávané množství, – celkem: automaticky dopočítaný součin ceny a množství. • Skupina informací o dodavateli: – klient: jméno klienta, toto pole je povinné – IČO – DIČ – Ulice – PSČ: není povinný údaj. Město a stát neurčujeme podle PSČ, protože PSČ není používané celosvětově pro všechny státy. – Město: na základě zvoleného města je automaticky přiřazen stát. Stát tedy není nutné vyplňovat. Toto pole je povinné. Pokud v seznamu měst nenaleznete potřebné město, pošlete administrátorovi žádost o přidání nového města případně nového státu. – Telefon – E-mail – Fax • Skupina informací o kontaktní osobě: tato skupina informací není povinná. – Kontaktní osoba – Kontaktní osoba telefon – Kontaktní osoba email

A.2


81

– Kontaktní mobil • Skupina informací o skladu: tato skupina informací není povinná. – Sklad – Sklad kontaktní osoba – Sklad telefon – Sklad od – Sklad do – Sleva dodavatele – Platební podmínky Po uložení nalezneme objednávku ve zboží. Objednávku můžeme upravit kliknutím na její název. Objednávku vymažeme pomocí červené ikonky pro mazání. A.2.5

Vytvoření objednávky do Prahy

Tento odstavec je určený pouze pro pobočky. pražské pobočka objednávky do Prahy nevytváří. Objednávku do Prahy vytvoříme v otevřeném zboží pomocí tlačítka „Objednávka do Prahyÿ. Pravidla pro vytváření a výčet jednotlivých polí formuláře je shodný s běžnou objednávkou. Podstatný rozdíl oproti běžné objednávce je ve vytvoření centrální zakázky a centrálního zboží, k vytvoření dojde automaticky po uložení objednávky. Automatické vytváření zakázky se řídí těmito pravidly: • Centrální zakázka s odpovídajícím číslem (např. C0008) je vytvořena pouze tehdy, jestliže neexistuje žádná centrální zakázka propojená s otevřenou lokální zakázkou, pro kterou je vytvářena objednávka do Prahy. • Název centrální zakázky je shodný s názvem prvního zboží, pro které je vytvořena objednávka do Prahy. • Klientem centrální zakázky je pobočka, která vytvořila objednávku do Prahy. • Značka centrální zakázky je shodná se značkou lokální zakázky. • Propojení centrálních a lokálních zakázek je realizováno na základě propojení alespoň jedné objednávky do Prahy na pobočce se zbožím na centrále. Pokud nalezneme takovouto propojenou dvojici zboží a objednávky, řekneme, že zakázky jsou vzájemně propojené. V takovýchto zakázkách je na kartě klienta zobrazený odkaz na související (centrální či lokální) zakázku.

nou • • •

Automatické vytváření zboží na straně centrály (pro existující či nově vytvořecentrální zakázku) se řídí následujícími pravidly: Název zboží je shodný s názvem objednávky do Prahy. Množství zboží je shodné s množstvím uvedeném na objednávce do Prahy. Jednotková cena zboží je shodná s jednotkovou cenou uvedenou na objednávce do Prahy.

A.2


82

• Měna vytvářené objednávky do Prahy je pevně nastavena na USD, měna centrálního zboží je rovněž nastavena na USD. Kurz CZK / USD na straně centrály je nastaven fixně na hodnotu 18 CZK / USD. Kurz lokální měny vůči USD na straně pobočky je stanoven dle aktuálního kurzovního lístku centrální banky pobočky. • Změny na objednávce do Prahy a změny na centrálním zboží jsou vzájemně synchronizovány. Synchronizace je aplikována na množství a cenu. A.2.6

Přílohy zakázky a zboží

K zakázce a ke zboží můžeme připojit libovolný soubor jako přílohu. Přidání nové přílohy provedeme pomocí formuláře ve spodní části otevřené záložky klienta (příloha pro zakázku) či pomocí formuláře ve spodní části otevřeného zboží (příloha pro zboží). Přiložené soubory nalezneme ve spodní části klienta (zboží). Každou přílohu můžeme otevřít pomocí klepnutí myši či smazat pomocí ikony pro mazání. A.2.7

Vytvoření nabídky

V zakázce na záložce klienta můžeme vytvořit nabídku kliknutím na tlačítko „Nabídkaÿ. Nabídka je automaticky vytvořena na základě zboží zakázky. Nabídka je vytvořena jako příloha a je přístupná mezi ostatními přílohami na spodní straně záložky klienta. Nabídku můžeme tisknout, případně upravit a provedené změny uložit. Vše provedeme kliknutím na ikonu objednávky v přílohách zakázky. A.2.8

Celkový kalkulační list

V horní části záložky celkového kalkulačního listu nastavujeme klíčové vlastnosti zakázky. Všechny provedené změny v následujícím nastavení jsou nevratné: • Skupinová zakázka: po zvolení se zakázka označí jako skupinová, změna typu zakázky se projeví v čísle zakázky (je přidán prefix „Gÿ). • Vyfakturováno vše: nastavíme, pokud jsme vystavili všechny potřebné faktury na záložce fakturace. • Dodáno vše: nastavíme, pokud bylo dodané veškeré objednané zboží od dodavatelů. • Zakázka uzavřena: odlišné chování pro pražskou pobočku a pro ostatní pobočky: – pro pobočku Praha: označeno, pokud je zakázka uzavřena přes workflow proces, nelze měnit – pro pobočky: nastavíme, pokud je zakázka uzavřena (pobočky nepoužívají workflow procesy) • Tlačítko „Eliminace kurzových rozdílůÿ: slouží k eliminaci kurzových rozdílů mezi plánem a skutečností v kalkulačním listu (podrobněji o plánu a skutečnosti níže). Po stisku tlačítka dojde k přenesení kurzu ze skutečného nákupu do plánovaného nákupu (kurz z faktur, které byly zlikvidovány na objednávky v plánu se přenese do těchto objednávek v plánu).

A.2


83

Vlastní kalkulační list je rozdělený na plán a skutečnost, dále na prodej a nákup. Plán prodej obsahuje zboží, skutečný prodej obsahuje vydané faktury. Plán nákup obsahuje objednávky, skutečný nákup obsahuje dodavatelské faktury, zlikvidované na objednávky na straně plánu. Nákup plán obsahuje růžové, modré a bílé řádky. Růžový řádek představuje zboží a seskupuje všechny objednávky daného zboží ve všech měnách. Modrý řádek pod růžovým řádkem seskupuje objednávky daného zboží pro jednu měnu. V kalkulačním listu tedy budou všechny objednávky v USD seskupeny v jednom modrém řádku, všechny objednávky v CZK budou seskupeny ve druhém modrém řádku apod. Bílé řádky pod modrými řádky představují vlastní objednávky v měně dané modrým řádkem. Díky výše uvedenému seskupení objednávek podle měn můžeme jednoduše autorizovat jednotlivé měny (tj. modré řádky). Autorizaci měny provedeme kliknutím na políčko umístěné v levé části modrého řádku dané měny. Zboží jako celek (růžový řádek) je autorizováno v případě, kdy autorizujeme všechny měny (modré řádky) zboží (růžového řádku). Políčko autorizace zboží (růžový řádek) nelze měnit, je zatrženo automaticky po autorizování všech měn. Autorizované zboží je uzamčeno, nelze nadále upravovat ani smazat. Uzamčení zboží je znázorněno ikonou visacího zámku. Kalkulační list není vždy zobrazený celý na šířku (zejména na menších monitorech). Pro pohyb doleva či doprava na kalkulačním listu můžeme použít šipky vlevo a vpravo na klávesnici nebo posuvník pod kalkulačním listem. A.2.9

Fakturace

Záložka fakturace na zakázce slouží k vystavení faktur pro klienta zakázky. Do formuláře vyplníme následující údaje: • Skupina obecných informací o faktuře: – číslo faktury, – název faktury, – datum zadání: toto pole je povinné, automaticky je předvyplněno aktuální datum. • Skupina informací o platebních podmínkách: – datum splatnosti: toto pole je povinné, automaticky je předvyplněno aktuální datum, – datum zdanění: toto pole je povinné, automaticky je předvyplněno aktuální datum, – cena celkem: je automaticky dopočítána z řádů faktury jako suma součinů množství a jednotkové ceny na řádcích faktury. • Skupina informací o klientovi: • – klient: jméno klienta, toto pole je povinné – IČO – DIČ

A.2


84

– Ulice – PSČ: není povinný údaj. Město a stát neurčujeme podle PSČ, protože PSČ není používané celosvětově pro všechny státy. – Město: na základě zvoleného města je automaticky přiřazen stát. Stát tedy není nutné vyplňovat. Toto pole je povinné. Pokud v seznamu měst nenaleznete potřebné město, pošlete administrátorovi žádost o přidání nového města případně nového státu. – Telefon – E-mail – Fax • Skupina ostatních informací: – Poznámka • Skupina řádků faktury: Řádky faktury jsou sestaveny na základě zboží a objednávek. V tabulce řádků faktury jsou uvedeny ceny z plánu. Pro libovolný (alespoň jeden) řádek doplníme skutečné množství a skutečnou jednotkovou cenu, kterou budeme fakturovat klientovi. V případě potřeby můžeme změnit popis řádku faktury. Vytváření nové faktury dokončíme uložením pomocí tlačítka „Uložitÿ. Pokud jsme všechny potřebné údaje vyplnili správně, nově vytvořenou fakturu nalezneme v tabulce pod formulářem pro novou fakturu. Fakturu můžeme otevřít a případně můžeme fakturu upravit (nelze měnit řádky faktury). Otevřenou fakturu lze vytisknout kliknutím na „Tisk této fakturyÿ. Všechny vytvořené faktury nalezneme v reportech, kterým je věnovaná oddělená kapitola této příručky. A.2.10

Workflow – proces zpracování zakázky

Záložka „workflowÿ obsahuje prostředí pro předávání zakázky mezi více pracovníky. Ve svém pracovním prostředí se můžete setkat s těmito situacemi: • Workflow proces není spuštěn: v případě potřeby je možné workflow proces spustit dle níže uvedeného návodu. • Workflow proces je spuštěn, současný úkol není v naši kompetenci: úkol neřešíme, systém nás pouze informuje, o jaký se jedná úkol a kdo tento úkol řeší. • Workflow proces je spuštěn, současný úkol je našim úkolem: jsme zodpovědní za vyřešení určitého kroku zpracování zakázky, naší povinností je splnit popsaný úkol a předat zakázku dalšímu pracovníkovi, jak je popsáno níže. • Workflow proces je ukončen: znamená to, že proces zpracování zakázky již proběhl a zakázka je tedy uzavřena. Aby bylo možné začít zakázku předávat, je třeba nejprve spustit tzv. workflow proces. Spouští jej vždy account manager (AM), který založil novou zakázku. Spuštění

A.2


85

proběhne kliknutím na tlačítko „Uložitÿ ve formuláři pro výběr typu procesu. Ve formuláři je vždy předvolený výchozí proces. Při ovládání workflow procesu mohou nastat dvě situace: • předání: předat úkol znamená posunout proces zpracování zakázky do další fáze dané popisem následujícího úkolu. Při předání vybereme z nabídky následující úkol (krok) procesu zpracování zakázky a dále zvolíme pracovníka, který bude odpovědný za zpracování tohoto úkolu. Klepnutím na tlačítko „Uložitÿ úkol předáme. Úkol se ihned zobrazí v osobních úkolech pracovníka, kterému jsme úkol předali. • delegování: použijeme v případě, kdy nechceme posunout zpracování zakázky do dalšího kroku a potřebujeme pověřit jiného pracovníka řešením stávajícího kroku zpracování zakázky. Vybereme pracovníka, kterému stávající úkol delegujeme a potvrdíme kliknutím na tlačítko „Uložitÿ.

A.3

Dodavatelské faktury

A.3 A.3.1

86

Dodavatelské faktury Zadání nové dodavatelské faktury

Novou dodavatelskou fakturu zadáme v záložce „Fakturyÿ pomocí tlačítka „Nová fakturaÿ. Druhou variantou je použití tlačítka „Nová fakturaÿ v oblíbených položkách z libovolného místa systému. Formulář pro novou dodavatelskou fakturu obsahuje následující prvky: • Skupina obecných informací: – rok, – číslo faktury: číslo faktury z podnikové číselné řady (pro Prahu dle Navision), – typ: výběr z výčtu F, ZF, E, M, DR, C, I, VD, Z. Jako výchozí volba je nastavena hodnota „Fÿ, – číslo faktury dodavatele: číslo dodavatelské faktury, – archivováno: volba ano/ne; pokud je zvoleno „anoÿ, faktura je zobrazena v reportech v archivu. V opačném případě je faktura obsažena ve výpisu faktur záložky „Fakturyÿ. • Skupina informací o dodavateli: • – klient: jméno klienta, toto pole je povinné, – IČO, – DIČ, – Ulice, – PSČ: není povinný údaj. Město a stát neurčujeme podle PSČ, protože PSČ není používané celosvětově pro všechny státy. – Město: na základě zvoleného města je automaticky přiřazen stát. Stát tedy není nutné vyplňovat. Toto pole je povinné. Pokud v seznamu měst nenaleznete potřebné město, pošlete administrátorovi žádost o přidání nového města případně nového státu. – Telefon, – E-mail, – Fax. • Skupina informací o platebních podmínkách: – Datum splatnosti, – datum zadání, – datum zdanění, – popis zboží, – množství: celková suma množství uvedená na dodavatelské faktuře, – cena celkem: celková suma uvedená na dodavatelské faktuře. Pozor, nezadávat jednotkovou cenu! – DPH: suma DPH uvedená na dodavatelské faktuře.

A.3

Dodavatelské faktury

A.3.2

87

Likvidace dodavatelských faktur

Likvidaci provádíme v otevřené faktuře. Každá faktura obsahuje několik záložek podobně jako zakázka, pro likvidaci použijeme záložku „Likvidaceÿ. Na této záložce je nejprve uvedena celková cena a množství uvedené na faktuře. Dále vidíme, jaká částka a jaké množství bylo zlikvidováno a kolik je ještě nutné zlikvidovat. Vlastní likvidaci uskutečníme vyplněním formuláře, kde zadáme množství pro likvidaci a částku pro likvidaci. Pozor, do pole „částkaÿ zadáváme celkovou částku, nikoli jednotkovou cenu! Druhý důležitý krok likvidace je výběr objednávky, na kterou budeme likvidovat. Objednávku vybereme v tabulce pod formulářem označením příslušného řádku (klikneme na řádek levým tlačítkem myši). Po výběru objednávky dokončíme likvidaci klepnutím na tlačítko „Uložitÿ. Seznam objednávek, na které jsme zlikvidovali otevřenou fakturu nalezneme pod záložkou „Objednávkyÿ. Zde v tabulce vidíme na jaké objednávky jsme likvidovali a v jaké výši jsme likvidovali. Pokud provedeme likvidaci chybně a potřebujeme tuto likvidaci zrušit, vymažeme jednoduše na záložce „Objednávkyÿ příslušný řádek. Dojde tak k vymazání záznamu o likvidaci, objednávka není tímto krokem smazána. Pro úplnost dodejme, že na záložce „Hlavičkaÿ nalezneme údaje, které jsme vyplnili při zadání nové faktury. Na záložce „Workflowÿ můžeme předávat fakturu dalším pracovníkům pomocí procesu zpracování faktury. Postup práce s workflow procesem je podrobně vysvětlen v předchozích kapitolách věnovaných zakázce. Různé pohledy na dodavatelské faktury nalezneme v reportech. Zde jsou faktury tříděny podle toho, zdali jsou zlikvidované, nezlikvidované či archivované. Více o reportech nalezneme v následující kapitole této příručky.

A.4

A.4

Reporty

88

Reporty

Pod záložkou reporty nalezneme řadu sestav, které prezentují data o uložených položkách vždy z určitého pevně daného pohledu. Můžeme použít následující reporty: • Zlikvidované faktury: zobrazuje pouze ty dodavatelské faktury, které jsou plně zlikvidované. • Nezlikvidované faktury: zobrazuje nezlikvidované dodavatelské faktury. • Archiv dodavatelských faktur: zobrazuje dodavatelské faktury určené k archivaci. • Faktury vydané: seskupuje všechny klientské faktury. • Report celkových kalkulačních listů: seskupuje údaje ze všech kalkulačních listů zakázek. • Report celkových kalkulačních listů 2: seskupuje údaje ze všech kalkulačních listů zakázek, jsou zde zavedeny zvláštní podmínky pro prezentaci dat: • Archiv faktur vydaných: seskupuje všechny klientské faktury určené k archivaci. • Stav zakázek: zobrazuje všechny zakázky s aktivovaným workflow procesem, zobrazí informaci o aktuálním stavu procesu, tj. pracovníka a jeho aktuální úkol. Výpis dat v reportech má stejnou formu, jako všechny výpisy dat, se kterými jsme se setkali například v zakázkách či fakturách. Fungují zde stejná pravidla pro filtrování i pro ovládání myší či pomocí klávesnice. Reporty můžeme také exportovat do MS Excel. Do seznamu reportů lze přidat libovolný nový report. Pro přidání nového reportu kontaktujte administrátora systému.

A.5

A.5

Kontakty

89

Kontakty

Nový kontakt přidáme na záložce „Kontaktyÿ pomocí tlačítka „Nový kontaktÿ v navigaci. Další variantou je použití tlačítka „Nový kontaktÿ v oblíbených položkách. Do formuláře pro nový kontakt vyplníme následující údaje: • Jméno: jméno klienta, toto pole je povinné, • Číslo v Navision: číslo, pod kterým je klient veden v software Navision, • IČO, • DIČ, • Ulice, • PSČ: není povinný údaj. Město a stát neurčujeme podle PSČ, protože PSČ není používané celosvětově pro všechny státy. • Město: na základě zvoleného města je automaticky přiřazen stát. Stát tedy není nutné vyplňovat. Toto pole je povinné. • Stát: pokud jste zvolili v předchozím poli existující město, stát je automaticky doplněn podle databáze měst a států. Pokud zadáváte nové město, které ještě není v databázi, zvolte odpovídající stát ze seznamu. Pokud v seznamu států nenaleznete potřebný stát, pošlete žádost o přidání nového státu administrátorovi systému. • Telefon, • Mobil, • E-mail, • Fax, • Typ: rozlišujeme tři typy kontaktů: „klientÿ, „dodavatelÿ, „klient a dodavatelÿ. Jako výchozí volba je nastaven typ „klientÿ.

A.6

A.6

Závěr

90

Závěr

Tento manuál je určený pro aktuálně platnou verzi systému Workflow 2009 k datu vydání manuálu. V případě aktualizací systému Workflow 2009 bude aktualizován i tento uživatelský manuál. Náměty a připomínky k tomuto manuálu či dotazy, které nejsou v tomto manuálu zodpovězeny, zasílejte na e-mailovou adresu administrátora systému.

B

B

NÁHLEDY OBRAZOVEK

Náhledy obrazovek

Obr. 7: Přihlašovací obrazovka

91

B

NÁHLEDY OBRAZOVEK

Obr. 8: Zakázka „Kancelářský stůl TOPÿ

92

B

NÁHLEDY OBRAZOVEK

Obr. 9: Zboží „Kancelářský stůlÿ

93

B

NÁHLEDY OBRAZOVEK

Obr. 10: Objednávka „Dřevěná deskaÿ

94

B

NÁHLEDY OBRAZOVEK

Obr. 11: Formulář pro zadání nové přijaté faktury

Obr. 12: Ovládání workflow procesu

95

B

NÁHLEDY OBRAZOVEK

Obr. 13: Výpis přijatých faktur

Obr. 14: Výpis kontaktů

96

B

NÁHLEDY OBRAZOVEK

Obr. 15: Likvidace přijaté faktury

Obr. 16: Pokročilý filtr

97

B

NÁHLEDY OBRAZOVEK

Obr. 17: Vstupní pole „autocompleteÿ pro výběr klienta nové zakázky

Obr. 18: Jednoduchý filtr nad sloupcem „workgroupÿ

98

B

NÁHLEDY OBRAZOVEK

Obr. 19: Filtr v kontextovém menu tabulky kontaktů

Obr. 20: Výběr zobrazených sloupců pro tabulku přijatých faktur

99

B

NÁHLEDY OBRAZOVEK

Obr. 21: Fakturace zboží

100

Implementace podnikového informačního systému

Recommend Documents

${title}