Embed Size (px)
Citation preview
Informační systémy
sestavil
Jiří Horák
HGF VŠB-TU Ostrava
Institut geoinformatiky
Ostrava, 5.vydání, 2015
2
Obsah:
1 Vymezení informatiky a informačního systému ............................................................................. 6 2 Charakteristika současných IS ......................................................................................................... 7
2.1.1 Strategický význam IS pro budoucnost podniku ............................................................. 8 2.1.2 Současné trendy světa a dopad na IS ............................................................................... 8
3 Současné problémy informačních systémů ................................................................................... 10 3.1 Maintenance boom ................................................................................................................ 10 3.2 Specifické vlastnosti softwaru ............................................................................................... 10 3.3 Nedostatečná orientace IS na uživatele ................................................................................. 11 3.4 Nedostatečná reakce na změny v prostředí podnikání ........................................................... 11 3.5 Aspekty managementu .......................................................................................................... 12 3.6 Odtržení informatiky a jejího řízení od ostatních oblastí podnikového řízení ...................... 12 3.7 Chybějící vazby funkcí IS/IT na prioritní, strategické potřeby podniku ............................... 12 3.8 Problematické ekonomické efekty vzhledem k vynaloženým nákladům na informatiku ..... 12 3.9 Zdlouhavý a neúměrně nákladný vývoj IS ............................................................................ 13 3.10 Chybějící jednotná koncepce tvorby a rozvoje IS/IT ............................................................ 13
4 Pozice řízení IS/IT v systému řízení podniku ................................................................................ 14 4.1 Současné nároky na řízení IS/IT ............................................................................................ 14
4.1.1 Pozice řízení IS/IT v systému řízení podniku ............................................................ 14 4.1.2 Úrovně řízení IS/IT...................................................................................................... 15 4.1.3 Model řízení IS/IT ....................................................................................................... 15
4.2 Vedení informatiky ................................................................................................................ 18 5 Strategické řízení informačních systémů ....................................................................................... 19
5.1 Principy strategického řízení IS/IT ........................................................................................ 19 5.2 Informační strategie ............................................................................................................... 19
5.2.1 Možné přístupy manažerů k informační strategii .................................................... 20 5.2.2 Proces formulace informační strategie ...................................................................... 20 5.2.3 Problémy při řešení informační strategie .................................................................. 22 5.2.4 Využití informační strategie ....................................................................................... 22
6 Architektura aplikací, možnosti řešení, specifika .......................................................................... 24 6.1.1 Význam pojmu architektura IS/IT ................................................................................. 24
6.2 Grid computing ...................................................................................................................... 29 6.3 Cloud computing ................................................................................................................... 31
7 Úlohy a typy projektů při výstavbě IS ........................................................................................... 33 7.1 Úlohy v aplikační vrstvě IS/IT .............................................................................................. 33 7.2 Úlohy na architektuře IS/IT ................................................................................................... 33
7.2.1 Úlohy systémových vlastností ..................................................................................... 33 7.2.2 Úlohy ekonomicko-organizační .................................................................................. 36 7.2.3 Integrační úlohy ........................................................................................................... 37
7.3 Metody výběru vhodných aplikací IT (i hodnocení stavu IT) ............................................... 38 7.3.1 Porterův rozšířený model .............................................................................................. 38 7.3.2 McFarlanův model aplikačního portfolia ...................................................................... 39 7.3.3 BCG Boston Consulting Group ..................................................................................... 39 7.3.4 SWOT ............................................................................................................................ 40
8 Systémová integrace ...................................................................................................................... 41 9 Metodické základy výstavby informačních systémů ..................................................................... 42
9.1 Softwarové inženýrství .......................................................................................................... 42 9.2 Informační inženýrství .......................................................................................................... 42 9.3 Organizační inženýrství ......................................................................................................... 42 9.4 Rapid development metody ................................................................................................... 43
10 Přístupy k výstavbě informačních systémů ............................................................................... 44 10.1 Tradiční strukturovaný přístup životního cyklu. ................................................................... 44 10.2 Prototypový přístup ............................................................................................................... 44 10.3 Objektově orientované modelování ....................................................................................... 46
10.3.1 Charakteristiky objektů ................................................................................................. 46
3
10.3.2 Hlavní myšlenkové principy objektového modelování ................................................. 46 10.3.3 Objektově orientovaná metodologie .............................................................................. 46 10.3.4 The Unified Process (UP) .............................................................................................. 47
10.4 Rapid development metody ................................................................................................... 53 11 Rozdělení informačních systémů - podle funkce a postavení v organizaci ............................... 57
11.1 Transakční systémy (TPS) ..................................................................................................... 59 11.2 Úlohy pro podporu taktického a operativního řízení – MIS (součást ERP) .......................... 59 11.3 Úlohy manažerské – typu EIS (často chápáno jako součást Business Intelligence) ............. 60 11.4 Úlohy typu datový sklad (DWH) (často chápáno jako součást Business Intelligence) ......... 60 11.5 Úlohy elektronické výměny dat – typu EDI (řízení externích vztahů) .................................. 61 11.6 Úlohy pro podporu kancelářských prací – OIS ..................................................................... 62 11.7 Systémy pro podporu rozhodování ........................................................................................ 63
11.7.1 Ukázka DSS .................................................................................................................. 63 11.8 Expertní systémy ................................................................................................................... 64 11.9 Strategické informační systémy ............................................................................................ 65 11.10 Metainformační systémy ................................................................................................... 65
12 Základní požadavky na dodavatele programového vybavení pro IS ......................................... 68 12.1 Základní údaje ASW (aplikačního software) ........................................................................ 68
12.1.1 Tvůrci, distributoři ......................................................................................................... 68 12.1.2 Základní orientace ASW ............................................................................................... 68
12.2 Architektura, skladba modulů ............................................................................................... 69 12.3 Instalace ASW (reference) .................................................................................................... 70 12.4 Provozní prostředí ................................................................................................................. 70 12.5 Vývojové a uživatelské prostředí .......................................................................................... 71 12.6 Dokumentace a jazykové prostředí ....................................................................................... 72 12.7 Doplňující služby .................................................................................................................. 73 12.8 Standardy, certifikace, integrace ........................................................................................... 74 12.9 Flexibilita............................................................................................................................... 75
12.9.1 Možnosti úprav (customizace) ...................................................................................... 76 12.9.2 Provozní flexibilita ........................................................................................................ 76
12.10 Funkční možnosti .............................................................................................................. 77 13 Exekutivní informační systémy (Business Intelligence) ........................................................... 78
13.1 Podstata EIS a jejich místo v architektuře IS/IT.................................................................... 78 13.2 Technologické principy EIS .................................................................................................. 78 13.3 OLAP Technologie ................................................................................................................ 79
14 Datové sklady (Business Intelligence) ...................................................................................... 82 14.1 základní principy Data Warehousingu .................................................................................. 82 14.2 Data Warehouse a Data Mart ................................................................................................ 83 14.3 Data Mining ........................................................................................................................... 84
15 Aplikace pro řízení externích vztahů ......................................................................................... 86 15.1 Elektronická výměna dokumentů (EDI) ................................................................................ 86
15.1.1 Podstata a místo EDI v architektuře IS/IT ..................................................................... 86 15.1.2 Technologické principy EDI ......................................................................................... 88 15.1.2.1 Vazba na aplikační software ...................................................................................... 88 15.1.3 Standardy EDI ............................................................................................................... 88
15.2 CRM systémy ........................................................................................................................ 90 15.2.1 Filosofie, organizace...................................................................................................... 90 15.2.2 Výhody CRM ................................................................................................................ 90 15.2.3 Postupy CRM ................................................................................................................ 90
16 Outsourcing ............................................................................................................................... 94 16.1 Obecný popis outsourcingu IT .............................................................................................. 94
17 ERP a ERP II, TOC ................................................................................................................... 97 18 Business System Planning – BSP .............................................................................................. 99
18.1 Sestavení studijního týmu...................................................................................................... 99 18.2 Příprava a zahájení studie .................................................................................................... 100
4
18.3 Definování podnikových procesů ........................................................................................ 100 18.4 Definování podnikových dat ............................................................................................... 101 18.5 Definování informační architektury .................................................................................... 101 18.6 Analýza dosavadní podpory podnikových činnosti IT ........................................................ 102 18.7 Projednání analýzy s vedoucími pracovníky podniku ......................................................... 102 18.8 Zpracování výsledků analýzy .............................................................................................. 103 18.9 Stanovení priorit v informační architektuře ........................................................................ 103 18.10 Návrh řízení informačních zdrojů.................................................................................... 104 18.11 Tvorba doporučení........................................................................................................... 104 18.12 Prezentace výsledků ........................................................................................................ 104 18.13 Návrh dalších opatření ..................................................................................................... 104
19 Process Quality Management - PQM ...................................................................................... 105 19.1 Principy a postup metody PQM .......................................................................................... 105 19.2 Definování poslání podniku ................................................................................................ 106 19.3 Určení dominantních vlivů .................................................................................................. 106 19.4 Definování kritických faktorů úspěchu ............................................................................... 108 19.5 Stanovení podnikových procesů .......................................................................................... 109 19.6 Přiřazení kritických faktorů úspěchu podnikovým procesům ............................................. 109 19.7 Určení nejkritičtějších procesů a priorit IT.......................................................................... 110 19.8 Portofolio analýza ................................................................................................................ 111 19.9 Shrnutí několika zásadních pravidel metody PQM ............................................................. 111
20 Efektivnost IS .......................................................................................................................... 112 20.1 Náklady na IT, jejich struktura a měření ............................................................................. 112
20.1.1 Druhy nákladů na IT................................................................................................. 113 20.1.2 Techniky pro odhadování nákladů .......................................................................... 114 20.1.3 Hodnocení nákladů na IT v podniku ....................................................................... 114
20.2 Vyjádření efektů .................................................................................................................. 114 20.2.1 Přímé ekonomické efekty ............................................................................................ 114
20.3 Základní metody pro stanovení odhadované finanční hodnoty projektu ............................. 115 20.3.1 Analýza čisté současné hodnoty (NPV) .................................................................... 115 20.3.2 Návratnost investice (ROI = Return of Investment) .............................................. 115 20.3.3 Analýza doby návratnosti (Playback Period) ......................................................... 115
20.4 Měření pracovního výkonu - metoda řízení vytvořené hodnoty (earned value management,
EVM) 116 20.5 Nepřímé efekty .................................................................................................................... 118 20.6 Komplexní hodnocení projektů IT (pro současné hodnocení přímých a nepřímých efektů)
118 20.6.1 Hodnota návratnosti investic .................................................................................... 118 20.6.2 Bodové hodnoty ostatních přínosů a rizik pro podnik ........................................... 119 20.6.3 Technologické vlastnosti aplikace ............................................................................ 120 20.6.4 Výsledné bodové hodnocení ...................................................................................... 122
21 CASE ....................................................................................................................................... 123 21.1 Základní pojmy .................................................................................................................... 123 21.2 Funkce a vlastnosti CASE produktů .................................................................................... 123 21.3 Hlediska pro hodnocení CASE systémů .............................................................................. 124
21.3.1 Hledisko podpory metodologie ................................................................................... 124 21.3.2 Hledisko uživatelských funkcí .................................................................................... 124 21.3.3 Hlediska zaveditelnosti v podniku ............................................................................... 124 21.3.4 Hlediska poprodejního servisu .................................................................................... 125
21.4 Rozhodnutí o nákupu CASE systému ................................................................................. 125 22 Role lidí v informačním systému ............................................................................................ 126 23 Analýza uživatelů .................................................................................................................... 126 24 Analýza uživatelských potřeb.................................................................................................. 130
24.1 Typy požiadaviek ................................................................................................................ 130 24.1.1 Funkčné požiadavky – zjištěné u uživatele.............................................................. 130
5
24.1.2 Podnikateľské požiadavky ........................................................................................ 131 24.1.3 Funkční požadavky normativní (podnikatelská pravidla) .................................... 131 24.1.4 Systémové požiadavky ................................................................................................ 132 Bežné požiadavky ................................................................................................................ 132 Základné (očakávané) požiadavky ...................................................................................... 132 Neznáme požiadavky .......................................................................................................... 132
24.2 Zber vývoj a špecifikácia požiadaviek ................................................................................ 132 24.2.1 Proces vývoja požiadaviek .......................................................................................... 132 24.2.2 Rozsah projektu a vízie projektu ................................................................................. 133 24.2.3 Hľadanie tried užívateľov a ich vlastnosti ................................................................... 134 24.2.4 Výber produktových šampiónov ................................................................................. 134 24.2.5 Výber skupiny typických užívateľov (focus groups) .................................................. 134 24.2.6 Hľadanie prípadov použitia ......................................................................................... 135 24.2.7 Hľadanie systémových udalostí a ich odpovedí ...................................................... 136 24.2.8 Požiadavkový workshop .............................................................................................. 136 24.2.9 Sledovanie užívateľov pri práci, rozhovor .............................................................. 137 24.2.10 Hľadanie nápadov na zlepšenie staršieho systému ............................................. 137 24.2.11 Požiadavky minulých projektov alebo konkurenčných projektov ................... 138
24.3 Analýza požiadaviek (specifikace požadavků) .................................................................... 138 24.3.1 Dátový slovník ............................................................................................................ 138 24.3.2 Modelovanie požiadaviek .......................................................................................... 138 24.3.3 Navrhovanie prototypov ........................................................................................... 141 24.3.4 Priority požiadaviek .................................................................................................. 143 24.3.5 Rozdelenie požiadaviek medzi podsystémy ............................................................. 144 24.3.6 QFD (Quality Function Deployment) ...................................................................... 144
24.4 Správa požiadaviek .............................................................................................................. 145 24.4.1 Stav požiadaviek .......................................................................................................... 145
24.5 Kontrola požiadaviek .......................................................................................................... 146 24.5.1 Recenzie / audit ........................................................................................................... 146 24.5.2 Podmienky prijatia....................................................................................................... 147
24.6 Záver k analýze uživatelských požadavků .......................................................................... 147 25 Strategie zavádění IS ............................................................................................................... 148 26 Spolehlivost IT a testování SW ............................................................................................... 149
26.1 Testování SW ...................................................................................................................... 149 27 Ochrana informačních systémů ............................................................................................... 151
27.1 Význam ochrany IS ............................................................................................................. 151 27.2 Příčiny ohrožení IS .............................................................................................................. 151 27.3 Ochranná opatření ............................................................................................................... 152
27.3.1 Všeobecná ochranná opatření ...................................................................................... 152 27.3.2 Ochranná opatření na úrovni aplikací .......................................................................... 152
28 FUNKČNÍ ANALÝZA ........................................................................................................... 154 28.1 Životní cyklus informačního systému ................................................................................. 154 28.2 Funkční analýza a funkční model ........................................................................................ 156 28.3 Diagram datových toků ....................................................................................................... 156 28.4 Minispecifikace ................................................................................................................... 159 28.5 Datový slovník .................................................................................................................... 160
29 Procesní řízení ....................................................................... Chyba! Záložka není definována. 30 Literatura: ................................................................................................................................ 162
6
1 Vymezení informatiky a informačního systému
Informatika
Studium struktury a obecných vlastností informace v přírodních i umělých
systémech, transformací informací na znalosti a pak v teorie, technickými
problémy komunikačních procesů od sběru dat přes zpracování a užití
informace.
Informační věda (information science)
Věda o informacích. Zkoumá funkce, struktury a přenos informací, vč. řízení
informačních systémů
Schejbal et al. (2004).
Data – formalizované aspekty reality, např. výsledky měření, pozorování
Informace – vzniká interpretací dat, jejich význam, důležitý kontext
Znalosti – zobecněné poznání reality, vyšší abstrakce, stálejší
Data (stavy reality v určitém okamžiku)
Informace (data+kontext+odvoz.mech.)
Znalosti (informace+kont.+zkušenosti+o.m.)
Informatizace
získávání, agregování, odvozování a distribuce informací ve společnosti.
Informace jako zdroj rozvoje národního hospodářství.
Globalizace
sjednocování světa, standardizace, unifikace
Internet
CESNET připojen 1991, veřejnost 1995
Informační systém (IS) definuje Molnár (1992) jako soubor lidí, technických prostředků a metod,
zabezpečujících sběr, přenos, uchování a zpracování dat za účelem tvorby a prezentace informací pro
potřeby uživatelů činných v systémech řízení.
Pokorný (1992) vymezuje pojem informační systém obecněji:
IS je systémem (tj. souborem prvků ve vzájemných informačních a procesních vztazích, souhrnně
informační procesy), které zpracovávají data a zabezpečují komunikaci mezi prvky. IS se často člení
na systém zpracování dat a komunikační systém.
Předmětem činnosti IS je účinné řešení informačních procesů Pokorný (1992). Problémem není jen
analyzovat IS v závislosti na informačním prostředí, ale optimalizovat jej tím, že navrhneme a
realizujeme jeho automatizovanou část. Vznikne tak automatizovaný informační systém
(AIS).
Informace se stávají nezbytným výrobním zdrojem stejně tak jako pracovní síla, suroviny, výrobní
zařízení a peníze. Jestliže tradičně používáme celou řadu metod pro řízení těchto zdrojů tak, aby byly
co nejefektivněji využívány, pak bychom měli mít i odpovídající metody pro řízení informací.
Pro kvantitu informace existuje objektivně práh nasycení, za kterým již není člověk schopen další
informace zpracovat. Tím nutně klesá jejich využitelnost, a tedy i užitná hodnota dat. Proto bychom se
měli dále ubírat především cestou zvyšování kvality informace.
Aplikace podnikové informatiky
Aplikace osobní informatiky – HW (tablety, smartphones, Wifi), SW (textové editory,
grafické, osobní db), elektronické informační zdroje (internet, vyhledávací služby, katalogy)
nejsou předmětem těchto skript.
7
2 Charakteristika současných IS (Zpracováno podle Molnára, Richty, Vávry, Šmídy a doplněno)
1. IS významně ovlivňují celkovou úspěšnost či neúspěšnost podniku
2. Postupná integrace informatiky do nejrůznějších podnikových, ale i běžných lidských aktivit
Rostoucí okruh uživatelů
Zvyšování rozsahu, komplexnosti, složitosti IS
Rostoucí nároky na vývoj, provoz, užití, řízení IS
3. IS/IT, počítačové sítě, internet se výraznou měrou podílejí:
Globalizace ekonomiky
Přestávají platit klasické hranice mezi podniky, regiony, státy
4. Interorganizační systémy – založené na organizační a ekonomické provázanosti s podporou
elektronicky realizovaných vazeb a výměny dat.
Globální informační prostředí
Virtuální firmy
Virtuální týmy
5. Řízení podniků doznává zásadních změn – objevují se zcela nové nároky na analýzu a projekci IS
Rozsah
Flexibilita
Orientace na podporu globálních logistických řetězců
Více jazyčné prostředí
Zohlednění legislativního prostředí, zvyklostí, …
přechod k plochým strukturám řízení od hierarchických, více samostatného rozhodování
na nižší úrovni
6. Rychlost vývoje a měnící se a rozšiřující se nabídky IT
Heterogenní charakter nových produktů
Permanentní rekvalifikace informatiků i uživatelů
Vysoké nároky na vytváření ekonomických a organizačních podmínek rekvalifikačních
procesů
7. Rychlost změn zvyšuje nároky na průběžné analýzy trhu IT na proces výběru adekvátních produktů
Udržení konsistence IS ve verzích SW a parametrů technického prostředí
Udržení kontinuity služeb IS/IT v průběhu výměny verzí nebo produktů
Integrace stávajících zdrojů do inovovaných - uchování dříve vynaložených
prostředků a práce do IS/IT
8. IS se vytvářejí a rozvíjejí aplikací a vzájemnou integrací hotových programových produktů
(aplikační, technologický, základní software), jen specializované funkce jsou projektovány a
programovány tzv. na míru
9. Rostoucí rozdíl mezi potřebami uživatelů a funkcionalitou hotového ASW.
s tím souvisí
10. Měnící se projektování IS/IT – projekční postupy se orientují na hotový SW a jeho následnou
přizpůsobení
11. Implementace IS/IT je spojena s rekonstrukcí a racionalizací ekonomických, obchodních,
administrativních, atd. procesů = BPR – Business Process Reengineering
12. Řešení IS/IT založeno na systémové integraci produktů a služeb
8
13. Nárůst tzv. outsourcingu – vyčlenění činností, jejichž realizace vlastními silami je neefektivní,
mimo organizaci
14. Dynamika změn ekonomického prostředí i IT – vyvolává rostoucí nároky v oblasti projekční,
konzultační a především v oblasti řízení IS
15. Pokles cen produktů, nárůst cen a objemu služeb
2.1.1 Strategický význam IS pro budoucnost podniku
Již v 90tých letech se zdůvodňovala potřeba IS následovně:
a) 25 až 80 procent všech informačních toků souvisejících s řízením podniku se zpracovává on-
line. Kvalita systému řízení a kvalita IS jsou vzájemně závislé a výpadek IS vede okamžitě
k zastavení chodu celého podniku.
b) Elektronická výměna dokumentů (Electronic Document Interchange – EDI) mezi podniky se
stává normou nahrazující dosavadní papírové dokumenty. EDI zkracuje dodací lhůty, zvyšuje
pružnost k zákazníkovi, snižuje zásoby a chybovost v komunikaci s partnery a v neposlední řadě
snižuje náklady na administrativu. Podnik, který nebude v budoucnu respektovat EDI, bude
postupně ztrácet své obchodní partnery.
c) Elektrické zpracování obrazů (image technology) se stává nezbytností nejen v inženýrství
(CAD/CAM), ale i při zpracování ostatních podnikových dokumentů, které nejsou zpracovávány
na bázi EDI. Tzv. dokument-handing umožňuje sejmout dokument, uložit ho a manipulovat s ním
podle potřeby po celou dobu jeho života. Image technology může zpracovávat ručně psané
dokumenty, fotografie, podpisy, zvukové záznamy telefonátů apod. Je to umožněno nástupem
nové IT zvané multimedia.
d) Princip just-in-time (JIT) se uplatňuje nejen ve výrobě, ale i v řízení zásob, prodejů a plateb. To
je realizováno zřizováním tzv.point-of-sale (POS) spojených s podnikovým IS elektronicky a
umožňujících přímo řídit a sledovat všechny potřebné transakce (nákupy i prodeje) jak po věcné,
tak i po finanční stránce (elektronické platby).
e) Reorganizace podniku se provádí mnohem častěji a není žádnou výjimkou. Podniky se slučují
nebo rozdělují, mění své podnikatelské aktivity atd. Z toho vyplývá nejen požadavek vysoké
flexibility IS umožňující rychlou reakci na požadavek nových informací, ale i dodržování určitých
standardů umožňujících snadné vzájemné slučování podniků.
f) Zvyšuje se nezávislost práce na místě, kde je prováděna. Jestliže 25 až 80 procent informačních
toků v podniku je realizováno elektronicky, pak může být např.konstrukční nebo obchodní
oddělení umístěno mimo výrobní provozy tam, kde je to třeba lacinější (cena pracovní síly, cena
ploch apod.). Jsme svědky toho, že významné firmy mají své kanceláře a provozy roztroušené po
celém světě. Řada pracovníků projekčních nebo obchodních firem pracuje doma nebo na cestách
(tzv. „logická kancelář“).
2.1.2 Současné trendy světa a dopad na IS
(upraveno podle Šmídy)
1) Klesající porodnost ve vyspělých zemích vede ke stárnutí populace, nutnosti
zaměstnávat starší osoby a také k nepřiměřené podpoře dětí. To vše má dopady na
byznys a IS.
2) Trh dělí služby na takové, které uspokojují základní materiální potřeby (a musí se tedy
kupovat vždy) a na služby pro zbytné potřeby (nemateriální potřeby). IS zpravidla
poskytují služby pro zbytné potřeby, což se nepříznivě projeví v době omezování
osobních/firemních disponibilních příjmů.
3) zesilování konkurence. Lze konkurovat cenou? Nebo vyšší kvalitou?
9
4) Prohlubování rozdílu mezi bohatými a chudými státy světa má dopady v nárůstu
terorismu, zvyšování migrace a dalších aspektech.
5) Na trhu existuje výrazný převis nabídkou nad poptávky. Např. ve 2.pol. 90tých let
byla výrobní kapacita 70-75 mil. aut, zatímco poptávka na úrovni 55 mil.aut.
6) Existuje nesoulad politické a ekonomické reality. Hovoří se o existenci cca 8-9
„civilizací“.
7) individualizace lidí – pro ně vhodná zakázková produkce.
8) Růst obyvatel ve městech způsobuje nárůst kriminality a růst dopravy, problémy
zásobování vodou a energií.
9) důraz na ekologii a ekologickou produkci
10) prolínání oborů, multidisciplinární produkty a služby
11) vývoj vědy a růst jejího uplatnění
12) zvyšování automatizace a podílu duševní práce
13) terorismus a obavy z něj
14) nestabilita počasí
15) nelineární vývoj budoucnosti
Příklady nerovnováhy:
General Motors měl v roce 1997 příjmy stejné jako GDP zemí Tanzanie, Keňa, Etiopie,
Nepál, Bangladéš, Zair, Nigérie, Uganda, Pákistán dohromady!
70% světového obchodu zabezpečuje cca 500 korporací, zodpovědných pouze svým
vlastníkům
10
3 Současné problémy informačních systémů Současně s tím vzrůstá trvale podíl nákladů na programové zabezpečení IT v celkových nákladech na
výrobu a zavádění IT, který dosáhl již počátkem 90tých let více než 50%. Příčiny jsou známé. Zatímco
ceny technického vybavení rostou zhruba lineárně, přičemž cena vztažená na jednotku výkonu se
výrazně snižuje, pak náklady na tvorbu programového vybavení rostou exponenciálně v důsledku:
- početního růstu programů v souvislosti s rozšiřujícím se používáním IT ve všech oblastech lidské
činnosti
- růstu rozsahu programů v důsledku rostoucí složitosti řešených úloh
- nízkého stupně automatizace vytváření programového vybavení.
3.1 Maintenance boom
Molnár (1991) tvrdí, že současný svět IT trpí chronickým nedostatkem profesních pracovníků
schopných vytvářet nové aplikace nejen z důvodů uvedených výše, ale i proto, že podle světových
statistik bylo již počátkem 90tých let téměř 70% dostupných lidských zdrojů pro tvorbu
programového vybavení spotřebováno na údržbu a provoz stávajících IS.
3.2 Specifické vlastnosti softwaru
F.P.Brooks ve svém článku „No Silver Bullet“ (in Molnár, 1991) velmi výstižně charakterizuje tvorbu
softwaru z hlediska jeho specifických problémů, které vyvěrají z jeho esenciálních, podstatných
vlastností, a proti kterým není dosud nalezena účinná zbraň (tj. stříbrná kulka, která měla podle pověsti
sloužit k zabití vlkodlaka).
K esenciálním vlastnostem softwaru patří zejména dále uvedené vlastnosti.
1. Složitost (complexity). Softwarová díla jsou složitější než kterákoliv jiná lidská díla, neboť se
v nich neopakují dva stejné prvky (pokud uvažujeme vyšší rozlišovací úroveň, než je jednoduchý
programový příkaz), a i když používáme třeba opakující se subrutiny v různých částech programu,
dává jejich použití vždy jiný výsledek v závislosti na předaných hodnotách parametrů. I když
počítač sám o sobě je snad nejsložitější dílo, které kdy člověk vytvořil – může totiž nabývat
ohromného počtu různých stavů, softwarové dílo, které je vlastně jakousi nadstavbou počítače,
může nabývat řádově vyššího počtu různých stavů. Jednotlivé prvky softwaru komunikují spolu
navzájem a počet těchto vzájemných interakcí samozřejmě roste rychleji než lineárně s velikostí
softwarového díla, tj. s počtem jeho prvků.
2. Nutnost přizpůsobení se (conformity) rozmanitým podmínkám prostředí a požadavkům
uživatelů. Je to dáno především tím, že software přijde na scénu při zavádění IT až jako poslední a
musí se tudíž přizpůsobit stávající složitosti a rozmanitosti prostředí.
3. Proměnlivost, měnivost (changeability). Softwarové dílo je pod stálým tlakem na úpravy,
doplňky a změny. Samozřejmě, že i ostatní lidské výrobky podléhají změně, ale ta je prováděna
prostě tím, že například starý automobil, který neplní požadované funkce, se nahradí koupí
nového, stejně tak jako se starší typ počítače nahradí novějším. Málokoho napadne montovat do
starého automobilu jinou, např. vícestupňovou převodovku, ale požadavek zapracování nových
funkcí do starých programů je však zcela běžný. Úspěšné programové produkty přežívají počítače,
pro které byly původně vytvořeny, protože lidé je chtějí i nadále používat. To ale znamená, že se
postupně mění prostředí pro tyto programy, a je tedy nutno stále je upravovat.
4. Neviditelnost (invisibility) a také nezviditelnost. Stavební plány nebo výkresy strojních součástí
nám dávají zcela jasnou představu o struktuře i funkcích staveb nebo výrobků. Země má své
mapy, integrovaný obvod své funkční logické schéma, počítač své schéma propojení. Jakmile se
však pokusíte zobrazit strukturu softwaru, narazíte na to, že musíte zobrazit hned několik
vzájemně souvisejících struktur. Potřebujeme zobrazit strukturu dat, strukturu programu, jejich
vzájemné závislosti, časové aspekty apod.
Navzdory pokroku, který byl dosažen v omezení a zjednodušení softwarových struktur (např.
zavedením strukturovaného přístupu), zůstává stále mnoho neviditelného, a tedy nedovolujícího použít
11
některý z výkonný koncepční nástroj. Proto dochází Brooks závěrem ke konstatování, že nejtěžší částí
vývoje softwaru je zvládnutí výše uvedených podstatných inherentních vlastností softwaru, spíše než
překonávání příležitostných problémů (accidents) vznikajících v podstatě jenom z důvodů dosud
nedokonalých nástrojů, které máme k dispozici.
3.3 Nedostatečná orientace IS na uživatele
Podle Molnára (1991) byl dosavadní vývoj IS příliš technologicky orientován a byl doménou
profesních pracovníků – informatiků, zatímco vlastní uživatelé, tj. řídící pracovníci, stáli stranou.
Pro mnohé z nich je stále výpočetní technika „nepřátelská“.
Technologický přístup k výstavbě IS se projevuje také tím, že v řadě případů postupujeme tak, že
nejprve rozhodneme o nákupu počítačů komunikačních prostředků (hardware), když je máme,
zajišťujeme nejdříve potřebné programové vybavení (software), a pak teprve nutíme uživatele
přizpůsobit se těmto programům a řešíme potřebné organizační změny, tj. řešíme tzv.orgware. I když
nákup počítačů může někdy inspirovat uživatele k požadavku tvorby aplikace, jsou známy případy,
kdy počítač „leží“ nevyužit, protože není zcela jasno, co se s ním bude řešit.
Zdánlivě výhodná a rychlá koupě se může vzápětí ukázat jako ztráta. Praxe prokázala i určité
souvislosti těchto ztrát.
Dalším nedostatkem IS je, že většina aplikací IT v podniku se týká zpracování informací o minulosti,
zatímco uživatelé – řídící pracovníci potřebují ke svému rozhodování informace o budoucnosti.
3.4 Nedostatečná reakce na změny v prostředí podnikání
Podle Molnára (1991) čím dál tím zrychlující se změny v prostředí podnikání vedou k tomu, že
vznikají neustále nové a nové požadavky na IS. Přitom flexibilita stávajícího programového vybavení
je nízká a IS není schopen uspokojovat tyto neustále se měnící informační potřeby.
Stejně tak jako podléhá změnám prostředí technologie, mění se i prostředí podnikání. Došlo
k významným změnám na poli ekonomiky a vedení podniků muselo přehodnotit způsob vedení
konkurenčního boje za úspěšný rozvoj nebo alespoň za přežití. Změnil se i trh pracovních sil
ovlivňující způsob fungování organizací. To vše tlačí IS k tomu, aby poskytoval čím dál tím více ad
hoc informací získávaných převážně z externích. tj.mimopodnikových zdrojů.
Zkracuje se cyklus vývoje nových výrobků a služeb. Podniky mají stále méně času na jejich vývoj.
Konkurenční boj se neustále zostřuje a schopnost udržet se na trhu často závisí na využití
nejkritičtějšího zdroje – času.
Probíhají samozřejmě také změny v oblasti pracovního prostředí, kde nejvýznamnějším rysem je
změna způsobů vedení lidí v organizacích. Některé z nejpodstatnějších změn s největším dopadem na
práci zaměstnanců uvádí Naisbitt:
1. Oslabování hierarchie a přechod na tzv. „ploché“ organizační struktury s relativně samostatnými
„buňkami“. To vytváří mnohem pružnější organizaci, ale samozřejmě také zvyšuje nároky na
vnitropodnikové komunikace. V hierarchické struktuře jsou zaměstnanci na nejnižší úrovni velmi
úzce specializováni a přicházejí do styku s informacemi nutnými pro vykonávání jen jednoho
druhu pracovní činnosti. Přísné vertikální řízení je založeno na svislém řetězci příkazů, aniž by
docházelo ke křížení odpovědnosti, a každá významnější iniciativa v důležitých otázkách podléhá
schválení shora. Taková organizace nemůže pružně reagovat na změny, neboť její struktura
vyžaduje stálou komunikaci shora dolů a zdola nahoru, což zabírá příliš mnoho času.
2. Stále rostoucí zájem o lidské zdroje. Zkušenosti vyspělých a úspěšných podniků ukazují, že
důraz dosud kladený na finanční prostředky se přenáší na lidský potenciál. Lidské zdroje jsou totiž
hlavním omezujícím faktorem konkurenceschopnosti podniků. Proto podniky, které budou ke
svým zaměstnancům přistupovat s větším zájmem, nutně dosáhnou vyšších zisků. Jedním
z aspektů tohoto trendu je např.rostoucí péče o zdraví a pohodu pracovníků. Tento zájem o „lidský
faktor“ však přesáhne hranice podniku a zaměří se rovněž na zákazníka. K tomu všemu může
přispět informační technologie tím, že bude jak k zaměstnancům, tak i k zákazníkům „přátelská“,
a že se lidé budou cítit s IT dobře.
12
3. Omezování střední úrovně managementu je podle Naisbitta dalším významným trendem
současnosti a blízké budoucnosti. Informační technologie umožňují stále větší redukci střední
vrstvy řízení, neboť sběr, zpracování a přenos informací může zajistit technika. Navíc se objevuje
stále více samosprávných organizačních jednotek s poměrně velkou samostatností (viz bod 1.),
takže tradiční hierarchická organizační struktura má stále menší opodstatnění. Tento trend s sebou
v současnosti přináší ještě jeden problém, a to zejména pro lidi narozené v poválečných letech.
Právě ti dosahují v současné době věku pro přestup do střední vrstvy řízení, ale vzhledem
k omezování této vrstvy i vzhledem k tomu, že tyto ročníky byly populačně silné, mohou
organizace přijít o mnoho talentovaných a zkušených zaměstnanců, pokud se jim nepodaří včas
vytvořit alternativní organizační struktury.
3.5 Aspekty managementu
Šmída () zdůrazňuje, že:
1) Management nesmí být interně orientován. Platí nadvláda zákazníka. Musí být
otevřenost a připravenost na vnější vlivy
2) působnost management v globalizovaném světě není právně a politicky vymezena
3) využití trendů a novinek z jiných oborů - má vysoké dopady
3.6 Odtržení informatiky a jejího řízení od ostatních oblastí podnikového řízení
Molnár (skripta) varuje před chápáním informatiky jako obslužné činnosti realizované „výpočetním
střediskem s uzavřeným provozem“.
Vysoká disponibilita personálních počítačů způsobuje, že informatika se stává integrální součástí
řídících a administrativních procedur a nelze ji od nich oddělovat. Tomu musí odpovídat i úroveň
řízení informatiky podniku.
3.7 Chybějící vazby funkcí IS/IT na prioritní, strategické potřeby podniku
Molnár (skripta) požaduje odpovídající organizační úroveň řízení informatiky. Jinak se očekávají
obchodní a ekonomické ztráty podniku, a tedy z dlouhodobého hlediska možné ohrožení
konkurenceschopnosti.
3.8 Problematické ekonomické efekty vzhledem k vynaloženým nákladům na informatiku
Podle Molnára (skripta) vinu nese většinou jak dodavatel, tak zákazník.
Dodavatel:
- Nepoměr ceny a kvality služeb a produktů
- Nedostatečné personální kapacity
- Nestabilita, neserióznost firmy
Zákazník:
- Chyby v řízení informatiky a v celkové koncepci jejího řešení, nezájem vedení
podniku formulovat tuto koncepci (neexistence koncepce)
- Chyby při výběru dodavatelů a uzavírání smluv
- Neochota plně a kvalifikovaně využívat nové zdroje – běžné je využívání cca 30%
funkčnosti programového vybavení
- Chyby v určování základní strategie rozvoje IS a nasazování jeho jednotlivých
komponent (plošná instalace techniky před řešením aplikací, podcenění role uživatelů
v procesu analýz a projekce, ….)
- Problematické zásahy vlastníků firem do strategie rozvoje informatiky
13
3.9 Zdlouhavý a neúměrně nákladný vývoj IS
Podle Molnára (skripta) je zdlouhavý vývoj IS dán často velkým rozsahem projektu a neuspokojenými
vysokými nároky na řízení projektu. Důvodem je tedy podcenění rozsahu projektů a problémů
spojených s řízením.
3.10 Chybějící jednotná koncepce tvorby a rozvoje IS/IT
Podle Molnára (skripta) nejzávažnější problém, který způsobuje:
Nekompatibilitu postupně nakupované výpočetní techniky a aplikací
Postupnou desintegraci funkcí, dat, SW a HW, neprůhlednost a komplikovanost architektury
systému, dlouhou dobu reakce na události z okolí, desintegraci podnikových útvarů atd.
Obtížnou údržbu a problematické možnosti dalšího rozvoje ve vztahu k měnícím se potřebám
uživatelů a rychlým změnám v IT
Řízení IS a zejména strategické řízení je klíčovým momentem rozvoje IS/IT a určuje rámec
pro následné řešení různých projekčních, technologických a technických problémů.
14
4 Pozice řízení IS/IT v systému řízení podniku
4.1 Současné nároky na řízení IS/IT
1. Pozice řízení IS/IT v modelu řízení celého podniku
2. Úrovně řízení IS/IT
3. Model řízení IS/IT
4.1.1 Pozice řízení IS/IT v systému řízení podniku
Řízení IS je specifickou integrální součástí řízení podniku.
Je nezbytné jasně definovat pozici řízení informatiky v systému řízení podniku.
Parsons (in Molnár, skripta) charakterizuje možné strategie přístupu k řízení IS/IT následovně:
Monopol, který je charakteristický tím, že aplikace IS/IT jsou realizovány jediným útvarem
pro všechny uživatele. To umožňuje i omezenými zdroji uspokojit rychle všechny uživatele a
výdaje na IS/IT jsou dobře kontrolovatelné. Ne vždy však jsou uživatelé spokojeni
s aplikacemi, které také ne vždy reflektují potřeby konkurenceschopnosti společnosti.
Příkladem mohou být organizace, které jsou charakteristické významným postavením
technických štábů určujících standardizaci pracovních postupů). Pak je IS/IT zabezpečována
centrálně ve všech funkcích, tj. funkci manažerské, technologické i provozní. Typicky se s ní
můžeme setkat u bank, pojišťoven apod. Extrémní varianta – koncový uživatel nesmí nic
nastavovat, natož instalovat.
Centrální plánování, které je charakteristické tím, že strategie IS/IT je plně integrována
s podnikatelskou strategií a řízena útvarem pro IS na vrcholové úrovni, což umožňuje lepší
pochopení příležitostí a potřeb společnosti a také efektivní nákupy optimální rozdělování
zdrojů. Vyžaduje však přímou angažovanost vrcholových manažerů a je málo flexibilní
vzhledem k vývoji IS/IT a často se setkává s odporem nižších složek řízení. Typicky se s ní
můžeme setkat v organizacích holdingového (divizního) typu, kde je uplatněn princip řízení
standardizací výstupů a dohlížecí systémy jsou výsledkem funkce technických štábů, které
proto musejí mít rozhodující slovo při určování informační strategie holdingu. Relativní
nezávislost dcer (divizí) umožňuje zvolit si vlastní způsob řízení IS/IT, uzpůsobený místním
podmínkám (tradice, lidské zdroje apod.).
Vedoucí role, která je charakteristická tím, že vychází ze skutečného chápání vedoucí role IT
pro konkurenceschopnost společnosti, užívá nejmodernější technologie, ale tím čerpá značné
náklady. Snaží se rozsáhle implementovat poslední novinky. Aplikace jsou často rizikové a
vyžadují podporu vrcholového managementu. Setkáme se s ní u všech podniků, které mají
IS/IT v předmětu svého podnikání (IT firmy), nebo je aplikace IS/IT významnou
podnikatelskou složkou podniku (bankovní domy apod.). Pozor na nadměrné náklady.
Volný trh, který předpokládá, že uživatelé nejlépe znají jakou IS/IT potřebují, což umožňuje
výběrově aplikovat progresivní technologie, ale vlastní útvar pro IS/IT musí čelit konkurenci
externích firem a má malou podporu vrcholového managementu. To způsobuje plýtvání zdroji
a vede k nerovnoměrnému vývoji IS/IT ve společnosti a brání její integraci. Příkladem mohou
být organizace, jejichž činnost je založena na profesních znalostech a dovednostech
(nemocnice, poradenské firmy apod.), kde musí být IS/IT co nejlépe přizpůsobeny potřebám
„profesionálů“ a jejich osobnímu pracovnímu stylu.
Omezené zdroje je způsob řízení IS/IT, při kterém jsou výdaje na IS/IT předem dány a o
portfoliu aplikací rozhodují finanční manažeři. Hlavním hlediskem hodnocení aplikací je
návratnost. Útvar pro IS/IT je veden jako nákladové středisko a IS/TT není chápána jako
konkurenční zbraň. Obtížně se reflektují změny v požadavcích uživatelů. I když se tento
princip uplatňuje zejména v malých a začínajících podnicích, je typický pro většinu podniků a
je jenom otázkou, do jaké míry se prosazuje. Čím slabší je postavení IT manažera, tím více
šancí má tento přístup k uplatnění.
15
Nezbytné zlo, které je charakteristické tím, že IT je aplikována jen tam, kde to vyžadují
předpisy nebo tam, kde není žádná jiná alternativa řešení problému. Aplikace musí vykazovat
vysokou návratnost. Je aplikován všude tam, kde vládne opatrný management, což způsobuje
demoralizaci až odchod kvalifikovaných pracovníků a nutně vede ke ztrátě
konkurenceschopnosti společnosti. Jako na nezbytné zlo se nemusíme dívat na výdaje do IS/IT
jako takové, ale i na některé oblasti či aplikace IS/IT, kde si to vyžadují objektivní okolnosti.
Tak např. mnoho manažerů našich podniků bylo až nepříjemně dotčeno tím, že na nich IT
manažeři vyžadovali značné finanční prostředky na řešení problému roku 2000. Jiným
nepříjemným zdrojem tlaku na výdaje do IS/IT je samozřejmě naše konkurence. Jestliže jiná
banka zavedla home-banking či podobné zákaznicky orientované aplikace Internetu, pak nám
nic jiného nezbývá, než tyto aplikace zavést také. Jestliže celní správa či jiné státní úřady si
předepíší předávání dokumentů prostřednictvím EDIFACTu, pak nám také nic jiného
nezbývá. Stejně tak jako chceme-li obchodovat s nadnárodními řetězci apod. Příklad od nás –
zavedení elektronických schránek povinných pro firmy ve styku s úřady.
Samozřejmě, že v „čisté“ formě se s těmito přístupy v praxi nesetkáme, ale vždy se bude jednat o
určité kombinace těch či oněch přístupů. Pro naše účely je důležité správné pochopení toho, jaký
přístup převládá, protože podle toho také bude v podniku „nastaven“ systém hodnocení efektivnosti
IS/IT. Tak např. nemůžeme chtít od „volného trhu“ či „vedoucí role“ výrazné snižování výdajů na
IS/IT, stejně tak jako nemůžeme chtít od „nezbytného zla“, aby IS/IT byla významným zdrojem
prosperity a konkurenceschopnosti podniku.
4.1.2 Úrovně řízení IS/IT
Vlastní řízení IS/IT se realizuje na 3 základních úrovních (Dohnal, Pour 1997 ?):
1. Strategická – zahrnuje formulaci informační strategie podniku, řešení zásadních koncepčních
otázek, výběr externích partnerů, apod.
2. Taktická – řízení jednotlivých projektů, řízení analytických a projekčních činností, řízení
vazeb na ostatní projekty, řízení implementace projektů, řízení směřování ze stávajícího stavu
IS na nově implementované úlohy, vytváření provozních předpokladů, analýzy provozu
projektů a řešení zásadních změn, apod.
3. Operativní – řízení provozu IS, instalace, údržby techniky, běžné údržby provozovaných
programů, zajišťování provozního materiálu, konzultačních služeb, technické podpory, apod.
Každá z úrovní řízení IS má svá pravidla, metody a formy řízení.
4.1.3 Model řízení IS/IT
Znamená vymezení funkcí a procesů řízení IS a zdrojů řízení, které tyto procesy a funkce realizují
nebo jejich realizaci umožňují.
Pro realizaci řízení je nezbytné mít připravené následující zdroje:
- personální
- metodické
- technické a softwarové
- finanční
16
Funkce a procesy řízení IS/IT
Ekonomika IS/IT Organizace IS/IT Personální řízení IS/IT
Specifikace a zadání projektů
Řešení na bázi typového ASW Řešení specializovaná
Řízení rozvoje IT Řízení datových zdrojů Řízení systémových vlastností
Řízení počítačové sítě a provozu
Obr. 1 Schéma rozdělení funkcí a procesů řízení IS/IT (Dohnal, Pour 1997)
Funkce a procesy řízení IS/IT:
1. Rozvoj organizace a procedur řízení IS/IT – zahrnuje definování organizačních schémat a
pravidel pro vývoj a provoz IS/IT a to v celkovém kontextu podnikové organizace, např.:
a. definování a průběžný rozvoj organizační struktury IS/IT a její integrace do
organizační struktury celého podniku,
b. reengineering procesů v oblasti řízení IS/IT, optimalizace řídících procesů IS/IT ve
vazbě na optimalizaci celopodnikových procesů,
c. organizační analýzy a optimalizace organizační struktury,
d. definování vztahů informatických útvarů na ostatní organizační jednotky podniku,
e. řízení vztahů s externími partnery v oblasti IS/IT,
f. definování jednotlivých projekčních týmů, jejich vnitřní struktury a úkolů,
g. popisy jednotlivých funkčních míst v rámci organizační struktury IS/IT.
2. Řízení ekonomiky IS/IT – představuje jak finanční plánování v oblasti IS/IT, tak analýzy
nákladů a dosahovaných efektů, např.:
a. Dlouhodobé plánování nákladů na IS/IT,
b. Analýzy vzhledem k celkovým investičním nákladům,
c. Zpracování rozpočtů na provoz a rozvoj IS,
d. Analýzy nákladů na IS/IT podle zvolených hledisek, analýzy dle druhů nákladů, dle
nákladových, resp. hospodářských středisek apod.,
e. Analýzy a návrh cenové strategie za služby poskytované externím zákazníkům
v oblasti IS/IT, i interním zákazníkům
f. Analýzy dosahovaných efektů (přínosů).
3. Personální řízení IS/IT – zahrnuje plánování personálních kapacit a vytváření podmínek pro
kvalifikační rozvoj jak pro pracovníky úseku informatiky, tak celé uživatelské sféry, např.:
a. Analýzy vlastních pracovních kapacit, jejich stavu, věkové struktury, kvalifikační
úrovně,
b. Hodnocení personálního zajištění jednotlivých projektů, vytížení pracovníků
c. Plánování potřeby vlastních pracovníků podle jednotlivých funkcí, projektů, …
d. Plánování potřeby externích kooperací z hlediska personálních kapacit,
e. Dlouhodobý kvalifikační program – pro uživatelské útvary a závody, pro úsek
informatiky,
f. Operativní plánování jednotlivých odborných školení, jejich personální a organizační
zajištění.
4. Formulace a zadávání projektů IS/IT – tj. základní rámec projektů (řešených dodavatelsky i
vlastními kapacitami), např.:
a. Analýzy uživatelských požadavků na rozšíření a rozvoj IS/IT,
b. Vstupní analýzy před specifikací jednotlivých projektů,
c. Specifikace projektů – obsah, forma dokumentace, návaznosti na ostatní řešené nebo
provozované projekty,
17
d. Posuzování zadaných projektů – vzhledem k celkové architektuře a integračním
možnostem a problémům, efektivnosti řešených projektů a očekávaných přínosů,
možností kapacitního zajištění projektů, možností externích kooperací,
e. Zadání projektu řešitelskému útvaru v případě řešení vlastními silami,
f. Realizace výběrového řízení v případě dodavatelského způsobu řešení,
g. Kontraktační řízení.
5. Řízení dodavatelsky řešených projektů, zahrnuje např.:
a. Úvodní studie projektu – zadání struktury úvodní studie a specifických požadavků na
její obsah, zajištění konzultací při řešení úvodní studie, posouzení a oponentura
úvodní studie,
b. Příprava organizace projektu – určení organizační struktury projektu, obsazení řídící
skupiny projektu a jednotlivých projekčních týmů, způsob kooperace s dodavatelem,
c. Kontraktační řízení na celý projekt,
d. Prototypování – ověřování prototypů, návrhy úprav a jejich posuzování (kdo, jak),
e. Implementace, příp. customizace,
f. Testovací procedury – dokumentace, řešení změn a úprav,
g. Příprava provozu a migrace – konverze datových zdrojů, upgrade techniky,
implementace vazeb na stávající aplikace, organizační opatření pro provoz, aplikační
a provozní školení uživatelů,
h. Předávací procedury – dokumentace, řešení změn a úprav,
i. Zahájení vlastního provozu a jeho monitorování.
6. Řízení projekčních a analytických činností IS/IT – definuje metodiky, metody, techniky a
nástroje (např. volba CASE) pro řešení projektů a analyzuje jejich využití a dodržování, např.:
a. Úvodní studie projektu – zpracování úvodní studie projektu – s respektováním vazeb
na ostatní řešené projekty, analýza rizik projektu, posouzení a oponentura úvodní
studie,
b. Příprava organizace projektu (na základě úvodní studie)
c. Implementace a testování – řešení dílčích prototypů, implementace programů a jejich
testování, dokumentace.
7. Řízení datových zdrojů IS/IT – zajišťuje analýzy a projektování interních i externích
datových zdrojů, např.:
a. Analýzy stavu interních datových zdrojů, databází – z hlediska rozsahu, nároků na
zdroje, kvality databází, z hlediska dostupnosti pro uživatele apod.,
b. Plánování rozvoje interních datových zdrojů – řešení vazeb na projekty, možnosti
sdílení, zvyšování kvality interních datových zdrojů,
c. Analýzy potřeb a možností externích datových zdrojů,
d. Plánování potřeb externích datových zdrojů,
e. Operativní zajišťování externích datových zdrojů,
f. Analýzy možností a plánování mobilních databází.
8. Řízení sítě a provozu IS/IT, zahrnuje, např.:
a. Monitorování provozu IS/IT,
b. Správa sítě,
c. Správa datových bází,
d. Definování provozních pravidel – pro archivaci, zálohování, bezpečnost, …
e. Definování a přiřazování přístupových práv,
f. Řešení provozních poruch a chyb,
g. Zajišťování průběžných konzultačních služeb,
h. Řešení provozních problémů s dodavateli IT.
9. Řízení rozvoje IT, zahrnuje, např.:
a. Výběr a instalace základních komponent IT,
b. Realizace jednotného operačního prostředí (operační systémy, databázové systémy),
c. Rozvoj produktů pro podporu kancelářských prací,
d. Rozvoj aplikací pro vstup podniku do infrastruktury Internetu.
10. Řízení systémových vlastností, zahrnuje např.:
a. Definování nároků a způsobů řešení zajištění bezpečnosti IS,
18
b. Řešení problémů spojených s výkonem IS a dosažením požadované doby odezvy,
c. Řešení nároků na integraci jednotlivých aplikací,
d. Řešení nároků na dosažení požadované flexibility IS.
Organizační a personální realizace této dekompozice se pak výrazně modifikuje podle toho, kdo plní
úlohu systémové integrace, resp. systémového integrátora.
4.2 Vedení informatiky
Vedení informatiky musí mít zastoupení v nejvyšších orgánech podniku. Na vrcholu stojí informační
manažer (CIO chief information officer): - Ve vyspělých organizacích je informační manažer přímo podřízen generálnímu řediteli
- Rozsah pravomocí a odpovědností informačního manažera závisí na tom, na jaké úrovni řízení
podniku je zařazen.
- neměl by být zatěžován běžnými provozními problémy nebo dílčími problémy jednotlivých
projektů
- svou orientací nebo kvalifikací by měl mít blíže k ekonomice a obchodu než k vlastním IT
Funkční náplň informačního manažera obsahuje především koncepční, ekonomické a obchodní
otázky IS:
- formulace celkové strategie IS – informační strategie
- naplňování informační strategie jednotlivými projekty a technologickým zázemím (realizace
informační strategie)
- rozvoj efektivních organizačních struktur a řídících procedur
- analýzy a návrhy nových informačních služeb
- rozvoj elektronického obchodu a řešení dopadů do obchodních procedur podniku
- formulace strategie prezentace firmy
- vyhodnocování ekonomických analýz IS, jeho ekonomických a neekonomických efektů, struktury
a objemu nákladů
- řízení kooperací s externími partnery v IT
- řešení vztahů informačních projektů a ostatních rozvojových projektů podniku (certifikace podle
ISO 9000, rekvalifikační projekty, projekty investičních akcí, …)
- personální strategie
Řídící komise nebo řídící výbor pro informatiku:
- v čele je představitel podniku (generální ředitel nebo jeho náměstek)
- kromě informačního manažera reprezentanti všech rozhodujících úseků podniku (tj. stakeholders)
- musí mít jasně vymezenou působnost, kompetence, obsah a formy práce
Jasné definování pozice řízení IS/IT v celém systému podnikového řízení a vymezení jeho vztahů
k ostatním úsekům umožňuje vytvoření ucelené koncepce rozvoje podnikové informatiky, která
řeší vazbu podnikové strategie a strategie rozvoje informatiky podniku.
19
5 Strategické řízení informačních systémů 80. a 90. léta – zájem o strategické řízení IS
důvod - analýzy různých kolapsů a nezdarů velkých IS
vzniká řada pracovišť specializovaných na strategické řízením IS, např. při Harvardské
universitě, Institut pro strategické řízení IS při Oxfordu, …
současnost
většina velkých podniků si uvědomuje nutnost uplatňovat principy strategického řízení i
v oblasti informatiky
firmy sami řeší nebo si nechávají zpracovat své informační strategie
na trhu existuje řada konzultačních firem a softwarových domů, které v rámci svých služeb
nabízejí řešení informační strategie
s rostoucí komplexností IS, různorodostí produktů potřeba strategického řízení dál poroste
5.1 Principy strategického řízení IS/IT
Principy strategického řízení IS vycházejí ze zkušeností praxe (Dohnal, Pour 1997):
Strategické řízení informačního systému musí být součástí strategického řízení podniku a musí
být řešeno v úzké vazbě na jeho ostatní oblasti (marketingové strategie, výrobní strategie
apod.),
Základním dokumentem strategického řízení IS/IT je informační strategie – viz další
podkapitola,
Na strategickém řízení a formulaci informační strategie se musí podílet především celé vedení
podniku, nikoli řadoví pracovníci,
Strategické řízení informačního systému se od ostatních oblastí liší svým průřezovým
charakterem a zejména podstatně kratším inovačním cyklem informačních technologií, ve
srovnání s jinými produkty. To znamená, že má určité specifické nároky, např. na časový
horizont formulovaných strategií, který je v informatice podstatně kratší, než v jiných
oblastech,
Ústředním prvkem strategického řízení IS/IT a informační strategie je celková architektura
informačního systému a z ní vycházející další rozvojové záměry a návrhy.
5.2 Informační strategie
Informační strategií obecně rozumíme soustavu cílů a způsobů jejich dosažení.
Cíle informační strategie podniku lze vyjádřit v otázkách:
Jak zvýšit výkonnost pracovníků podniku pomocí IS/IT?
Jak podpořit dosahování strategických cílů podniku pomocí IS/IT?
Jak může informační technologie přidat hodnotu naším produktům?
Jaký informační systém zvýší nejvíce naší konkurenceschopnost?
Jak vytvářet pro podnik další strategické příležitosti rozvoje?
Informační strategie má určit i jak těchto cílů dosáhnout. Je přitom užitečné si klást otázky (podle
Molnára (skripta):
Kdo a jak má řídit rozvoj a provoz IS/IT?
Jak má být rozvoj a provoz IS/IT organizován?
Kolik prostředků máme vydávat na rozvoj a provoz IS/IT?
Kde a jak máme získávat tyto zdroje a jak hodnotit jejich efektivnost?
Jak vychovávat a motivovat pracovníky ve využívání IS/IT?
20
Informační strategie je základní dokument koncepční fáze rozvoje IS podniku, tj. dlouhodobý záměr,
který zahrnuje především plánování IS, plánování rozvoje jednotlivých informačních zdrojů a služeb.
Jejím hlavním smyslem je formulovat celkový koncept informačního systému tak, aby co nejlépe
podporoval rozvoj podniku v jeho jednotlivých oblastech řízení – obchodu, výroby, investičních
aktivitách, organizačním rozvoji apod.
Informační strategie vytváří podklad pro zadání jednotlivých projektů, případně pro specifikaci
poptávkových dokumentů pro realizaci výběrového řízení na dodavatele informačních technologií.
V rámci většiny IS/IT se realizuje několik projektů (současně nebo následně), např. pro různé
organizační jednotky (centrum, závody, afilace, …) nebo speciální projekty pro určité oblasti řízení
(např. marketing). Informační strategie tak přispívá k dosažení vzájemné synchronizace a provázání
navrhovaných, řešených i provozovaných projektů a aplikací. Informační strategie je fáze vývoje IS/IT
pro všechny projekty společná, zatímco ostatní se již váží k jednotlivým definovaným projektům.
Informační strategie je podmínkou pro dosažení vzájemné synchronizace a provázání navrhovaných,
řešených i provozovaných projektů a aplikací
Jednou z jeho klíčových částí informační strategie je návrh architektury IS podniku (viz další
kapitola).
5.2.1 Možné přístupy manažerů k informační strategii
Podle toho, jaký je poměr sil mezi tradičními manažery a informatiky je IS/IT do podniku „tlačena“,
pokud informatici mají převahu nad tradičními manažery, nebo je naopak těmito informačně
gramotnými manažery do podniku „tažena“. V podmínkách konkrétní společnosti pak může převládat
některý z dále uvedených způsobů řízení IS/IT podle zda jsou informace chápány jako obranná či
útočná zbraň, jaké finanční a lidské zdroje má podnik k dispozici a jakou má vnitřní mocenskou
strukturu.
5.2.2 Proces formulace informační strategie
Proces formulace informační strategie podniku se dotýká všech otázek spojených s rozvojem
informačních systémů podniku a stejně jako všechna ostatní strategická rozhodnutí by měla být
zpracována písemně a měli by ho spoluvytvářet všichni řídící pracovníci podniku. Tím na sebe
automaticky berou závazek podpory této strategie.
Proces definování informační strategie podniku je trvalý dialog mezi obecným managementem
podniku a odborníky-informatiky (interními i externími) a rozhodně by neměl být orientován na řešení
technických problémů (datovou analýzu, výběr hardware či software a pod.), ale měl by být orientován
především na analýzu procesů (interních i externích) a jejich možnou podporu IS/IT. Neměl by řešit
dílčí zavádění informačních systémů do jednotlivých funkčních oblastí podniku, ale měl by řešit
komplexní, systematické a integrované zavádění IS/IT včetně systematického vytváření potřebné
informační infrastruktury.
Cílem procesu stanovení informační strategie společnosti je především určení oblastí, ve kterých
očekáváme efekty z nasazení IS/IT co největší a určení cesty jak těchto efektů dosáhnout. K tomu si
samozřejmě musíme analyzovat, jaká je naše současná úroveň využívání IS/IT, jaké jsou naše
možnosti a konfrontovat tuto situaci a možnostmi s obecnými principy a zákonitostmi rozvoje IS/IT.
K tomu byla vyvinuta ve světě celá řada metod a technik, které nám pomáhají určit „optimální“
portfolio potřeb IS/IT v závislosti na současné situaci a potřebách dalšího rozvoje podniku.
Při koncipování informační strategie podniku bychom měli nejen vnímat podnikatelský aspekt celého
problému, ale také obecné vývojové trendy IS/IT. Pro naše účely se na vývoj IS/IT budeme dívat více
ze systémového hlediska než z hlediska technologického.
V procesu tvorby informační strategie se musí uvažovat řada možných variant. U každé varianty
musíme před konečným rozhodnutím hodnotit zejména:
Přinese nám realizace strategie nějakou výhodu? Jakou?
21
Jak zajímavá je strategie z pohledu trhu?
Jak trvale je udržitelná konkurenční výhoda této strategie?
Má podnik dostatek schopností a zdrojů realizovat tuto strategii?
Pochopili pracovníci danou strategii a jsou pro ní zavázáni?
Jsou rizika spojená s implementací strategie přijatelná?
Hlavní vstupy (podkladové dokumenty) pro informační strategii jsou:
Podniková nebo globální strategie, obsahující záměry rozvoje podniku ve všech klíčových
oblastech činnosti (výroba, obchod, surovinová orientace, rozvoj personálních zdrojů, finance,
marketing, …),
Základní podnikové dokumenty a směrnice, organizační řád, výroční zprávy,
Analýzy vývojových trendů v oblasti informačních technologií, v oblasti ekonomiky a dalších
disciplin,
Analýzy trhu informačních technologií,
Podklady o rozvoji informačních systémů v konkurenčních nebo partnerských organizacích.
Zpracování informační strategie se realizuje vedením podniku většinou ve spolupráci s externí
(konzultační) firmou. Doba řešení se pohybuje kolem 3 měsíců.
Obr. 2 Struktura Informační strategie (Dohnal, Pour 1997)
Příprava informační strategie zahrnuje tyto základní části:
1. formulaci cílů, struktury, rozsahu a eventuelně omezujících podmínek informační strategie,
2. analýzu základních koncepčních materiálů podniku (podnikovou strategii, marketingové analýzy
apod.),
3. formulaci cílů informačního systému, diskusi a formulaci tzv. kritických faktorů úspěchu IS/IT
(CSF – Critical Success Factors), tj. takových vlastností nového IS/IT, které výrazně ovlivní
celkové efekty řešení, resp. mohou přispět k celkové úspěšnosti obchodních a dalších aktivit
podniku,
4. analýzu současného stavu IS/IT a zejména určení rozhodujících problémů provozu a dalšího
rozvoje IS/IT,
5. návrh celkové architektury IS/IT (viz další kapitola), tj. celkového schématu, jeho jednotlivých
úloh a modulů, jejich podstatných vazeb,
22
6. vymezení základní funkční struktury, nejdůležitějších funkcí a požadavků na realizaci, vymezení
nejdůležitějších datových zdrojů (interních i externích) a hlavních požadavků na tyto zdroje
(obsah, dostupnost, distribuci, zabezpečení, …)
7. řešení rozhodujících technologických, organizačních, personálních, ekonomických, legislativních
aspektů rozvoje IS/IT,
8. definici jednotlivých projektů, jejich vzájemných vazeb, priorit, zodpovědnosti za jejich řešení,
návrh jejich harmonogramu, předpokládaný způsob řešení (dodavatelsky / vlastním vývojem),
včetně odhadu jejich pracovní a finanční náročnosti.
Následuje odsouhlasení informační strategie ve vedení podniku a seznámení s ní všech
zainteresovaných pracovníků.
Proces formulace informační strategie podniku se dotýká všech otázek spojených s rozvojem
informačních systémů podniku. Stejně jako všechna ostatní strategická rozhodnutí by měla být
strategie zpracována písemně a měli by ji spoluvytvářet všichni řídící pracovníci podniku. Tím na sebe
automaticky berou závazek podpory této strategie.
V případě dodavatelského způsobu řešení IS/IT se připravuje výběrové řízení na systémového
integrátora. To znamená, že se připravuje poptávka, definuje způsob hodnocení nabídek, určují se
organizační principy výběrového řízení.
5.2.3 Problémy při řešení informační strategie
V současnosti zejména tyto problémy:
klíčovým problémem je situace, kdy vedení podniku není připraveno hrát v koncipování rozvoje
IS/IT předpokládanou klíčovou roli a informatiku považuje za okrajovou záležitost, jejíž řešení je
svěřeno úzkému okruhu specialistů,
je nutné stanovit odpovídající dobu a rozsah řešení informační strategie. Informační strategie by
měla být zpracovávána, s ohledem na vysoké tempo v ekonomice i v IT na 2 – 3 roky. Měla by
však být periodicky aktualizována. Právě aktualizace tohoto dokumentu je v praxi často
problémem, který vede ke znehodnocení původně pracovních i finančních investic,
pro zpracování informační strategie nejsou k dispozici potřebné vstupní dokumenty (podniková
strategie apod.),
nevěnuje se odpovídající pozornost jasné formulaci cílů IS/IT ve vazbě na podnikové cíle (např.
na rozvoj řízení, jeho centralizaci, decentralizaci, řešení vazeb IT na rozvoj výrobních,
skladovacích a dalších technologií apod.),
není schopen význam celkové architektury IS/IT a není dosaženo souladu představ vedení
podniku, vedení informatiky o této architektuře,
při řešení se preferují technologické aspekty, přičemž na této úrovni je prioritní obsah řešení,
organizační, ekonomické, personální otázky, zatímco problémy technologické jsou na této úrovni
sekundární,
navazující výběrové řízení na systémového integrátora postrádá jasně definovaná pravidla,
komplexní a kvalitně připravený poptávkový dokument, přesně definovaný způsob hodnocení
návrhů, resp. nabídek apod.
5.2.4 Využití informační strategie
Informační strategie vytváří podklad pro zadání jednotlivých projektů, pro specifikaci poptávkových
dokumentů pro realizaci výběrových řízení na dodavatele IT nebo služeb.
Projekty IS/IT pro různé organizační jednotky
Projekty IS/IT pro určité oblasti řízení
Informační strategie je fáze vývoje IS/IT pro všechny projekty společná, zatímco ostatní se již váží
k jednotlivým definovaným projektům.
23
Obr. 3 Informační strategie jako východisko pro jednotlivé projekty (Dohnal, Pour 1997)
Z hlediska sledování a vyhodnocování efektivnosti IS/IT je třeba, aby v rámci procesu vytváření
informační strategie podniku, tj. v etapě plánování, bylo pro každou aplikaci resp. každý projekt byly:
Jasně definovány cíle, kterých má být danou aplikací (projektem) IS/IT dosaženo
při definování těchto cílů bylo uvažováno s celým generickým portfoliem možných přínosů
každé aplikace (zvýšení účinnosti, zlepšení výkonnosti a vytváření nových příležitosti)
K těmto cílům byly určeny ukazatele (metriky) dosažení těchto cílů
Informační strategie
Projekt 1 Projekt 2 Projekt n
Úvodní studie
…
…
Úvodní studie
…
…
Úvodní studie
…
…
24
6 Architektura aplikací, možnosti řešení, specifika Cílem informatiků a vedoucích podnikových pracovníků při definování architektury IS/IT je stanovení
globální, přesto jasné a přesné specifikace jednotlivých dimenzí IS, jejich vzájemných vazeb a vazeb
IS na své okolí.
Součástí architektury IS je určení hlavních komponent – stavebních bloků, jejich vzájemné
provázanosti při respektování předpokládaných vývojových změn.
6.1.1 Význam pojmu architektura IS/IT
Obecná definice architektury (Dohnal, Pour 1997):
Architektura je dílo navrhovatele vytvářející funkční prostor pro další realizaci podle
základních ideových představ a technických možností daných dobou.
Architektura je i ideovou jednotou použitých prvků, má definovaný styl, smysl i poslání. Může
být otevřenou, přístupnou k celé řadě změn a přestaveb, které však musí být realizovány
v určitém stanoveném stylu.
V IS/IT se termín architektura používá od 60. let.
Architektura jako schéma počítače, uspořádání jeho komponent
Architektura v oblasti základního software – vrstvená architektura, uspořádání komponent
OS, případně dalších základních programových prostředků do vzájemně podřízených vrstev,
kde nadřízená vrstva definuje své požadavky a využívá služeb podřízené vrstvy na základě
přesně definovaných vazeb.
Architektura aplikačních programových balíků
Main-line, aplikační software BOMP (Bill of Material Planning),
PICS, COPICS, …
Od druhé poloviny 80. let se používá pojem „celková architektura IS/IT“ jako graficky vyjádřená
představa IS/IT jako celku, nejen technického a programového vybavení.
Termín je dnes značně využíván hlavně v souvislosti s tvorbou informační strategie a návrhem
rozsáhlých projektů IS/IT.
Definice architektury IS/IT (Dohnal, Pour 1997):
Architektura IS/IT je technologické schéma orientující vývoj IS/IT podniku nebo instituce
k uspokojování informačních nároků z hlediska řízení a obchodu. Architektura je základní schéma pro
analýzu a návrh IS/IT.
Celková architektura IS/IT je schéma zohledňující všechny podstatné dimenze návrhu IS.
„Pravidlo jednoho papíru“,
Architektura představuje výchozí bod pro dosažení potřebné úrovně konsistence, integrace a
interoperability IS.
25
Obr. 4 Východiska a výstupy architektury IS//T (Dohnal, Pour 1997)
Architektura IS/IT tvoří klíčový prvek řízení IS, z něhož pak vycházejí postupně detailizované
analytické i plánovací charakteristiky celého IS,
Architektura musí respektovat strategii podniku, podnikové cíle a cíle IS,
Do architektury se musí promítat stav a rozvoj produkčních a řídících aktivit a jim
odpovídajících zdrojů, a to ve vzájemných vazbách,
Architektura je postavena z bloků, resp. hlavních úloh odpovídajících optimálnímu logickému
uspořádání produkčních a řídících procesů a zdrojů,
Architektura musí být postavena tak, aby byla schopna respektovat dynamiku změn
v procesech a zdrojích a promítat je do navazujících aktivit řízení IS.
Architektura zohledňuje následující dimenze IS/IT (Dohnal, Pour 1997):
Funkční – funkční struktura, náplň jednotlivých funkcí IS/IT (např. evidence studijních
výsledků, zadávání výsledků zkoušek do systému),
Procesní – vymezení klíčových procesů v IS/IT (např. absolventské řízení u studentů),
Datová – určení datových objektů a zdrojů v rozlišení na interní a externí zdroje,
Softwarová – v rozlišení na aplikační a základní nebo systémový software (použijeme OS Win?
Klient na webu? Http nebo https? Jaká úroveň kódování, 16bitová?),
Technická – postihující celý komplex prostředků počítačové a komunikační techniky (budeme
používat pouze infrastrukturní prvky Cisco?, pozor na rozdílné ovládání různých prvků sítě,
NAS),
Organizační – zahrnující organizační strukturu a vymezení jednotlivých organizačních jednotek,
Personální – zahrnující profesní a kvalifikační struktury (např. požadavky na kvalifikaci, popisy
pracovních činností).
.
Vazby mezi dimenzemi IS/IT:
Funkce IS/IT-aplikační software,
Aplikační software-organizační jednotky,
Aplikační software-základní software,
Technické prostředky-základní software,
…..
26
Principy tvorby architektury IS/IT:
musí být postavena perspektivně – návrh architektury se realizuje v úzké spolupráci projektantů
a uživatelů tak, aby byla jasně pochopitelná oběma stranám,
architektura vyjadřuje celkovou vizi IS a musí být oproštěna od jakýchkoliv detailů. Musí však
vycházet z plného pochopení ekonomické, obchodní a výrobní podstaty činnosti organizace a
cílů, které tato organizace do budoucnosti sleduje,
musí být přiměřeně jednoduchá a srozumitelná. V rámci vývoje IS/IT bude architektura
naplňována postupně. Představuje určitý skelet do něhož budou postupně zasazovány jednotlivé
aplikace a v jehož rámci budou řešeny jednotlivé projekty. Zadání projektů tak musí být
verifikováno vůči navržené architektuře.
Význam celkové architektury IS/IT (Dohnal, Pour 1997) 1. architektura vytváří relativně stabilní rámec, do něhož se v průběhu doby vývoje IS/IT
začleňují jednotlivé aplikace a prostředky podle potřeby, podle technologických,
ekonomických a dalších možností, avšak s předem definovanými základními vazbami na ostatní
části IS/IT,
2. architektura IS/IT je významným komunikačním prostředkem mezi vedením společnosti,
projektanty a návrháři při formulaci základních představ o IS/IT a prioritách řešení,
3. architektura, pokud je navržena jako dostatečně otevřená, předvídající předpokládané změny,
zajišťuje stabilitu vývoje IS/IT i při rychlém technologickém vývoji IT,
4. architektura umožňuje již v počátku řešení IS/IT zohlednit hlavní požadavky na vlastnosti
IS/IT a z ní odvíjet konsistentní specifikace jednotlivých projektů respektující požadované
vlastnosti, např.:
obsah řešení, jaké úrovně a oblasti řízení a s jakými prioritami mají být řešeny, v jakých
vzájemných vazbách,
rozsah řešení, jaké organizační celky a v jakých lokalitách mají být řešeny,
charakter řízení, který má být informatikou podporován,
flexibilita IS/IT z hlediska organizačních, datových i technologických struktur,
spolehlivost IS/IT, požadovaná odolnost proti technickým výpadkům systému, úmyslným i
neúmyslným destruktivním zásahům člověka apod.
5. architektura IS/IT je významná i z ekonomického pohledu. Umožňuje organizaci minimalizovat
náklady na chybně zadané projekty nebo dokonce náklady na rekonstrukci celého IS/IT v důsledku jeho další neudržitelnosti,
6. architektury IS/IT reagují rovněž na trendy směřující k řešení IS/IT na bázi hotových produktů a
na jejich stále vyšší heterogenitu. S rozmanitostí používaných technických a softwarových
prostředků souvisí i heterogenita projektů. Projekty se pak liší nejen ve svém obsahu, ale i
v projekčních přístupech, metodách, nástrojích. Architektura by měla ukázat pozici těchto
projektů, resp. úloh v celém IS/IT a vytvořit základ pro efektivní řízení vývoje a provozu IS/IT.
Tab. 1 Podstatná hlediska ovlivňující architekturu a výslednou podobu IS/IT (Dohnal, Pour 1997)
Hledisko
návrhu
Důsledky pro návrh architektury Příklady
1. Předmět
činnosti
organizace
definování obsahu jednotlivých bloků
architektury a jejich vazeb,
orientace na adekvátní ASW a jeho
architekturu
výrobní podnik vs obchod
vs finanční ústavy, apod.
2. Charakter
činnosti
vymezení jádra architektury vs obslužné
bloky,
vymezení úloh na úrovni TPS,
vazby na specifické úlohy nebo
technologie (CAD, CAM, GIS, …)
bezpečnostní požadavky
řízení zakázek u kusové
výroby,
rezervační úlohy u
dopravních a zásobovacích
27
organizací
3. Organizace,
org. struktura
analýza řídících úrovní, jejich funkcí a
vazeb, možnosti komunikace,
posouzení možností zásahu, resp. úprav
do organizačních struktur
členité vs ploché struktury
4. Dislokace
organizačních
jednotek
možnosti komunikace, komunikační
infrastruktura,
stanovení centralizace/decentralizace
výpočetních a datových zdrojů, jejich
alokace,
standardizace IS/IT na dislokovaných
pobočkách,
velké výrobní systémy
s dislokovanými
pobočkami,
finanční a obchodní
společnosti
5. Dislokace
mimo ČR
nalezení efektivní a bezpečné
komunikace,
vysoce obtížná standardizace,
promítání vlivu zahraničního prostředí,
legislativní vlivy
výrobní a obchodní
společnosti se sítí poboček
6. Centralizace/
decentralizace
řízení
dopady do funkční architektury,
distribuce funkcí,
vybavení podnikatelských jednotek
celým spektrem funkcí IS/IT,
rozhodnutí, které funkce centralizovat,
které chápat jako primární a které
obslužné
decentralizace řízení u
obchodních společností,
centralizace např.
marketingu, problém
ochoty sdílet a naplňovat
společné databáze
7. Charakter a
spektrum
externích
partnerů
návrh realizace externích vazeb
(obsahově, technologicky, organizačně)
dodavatelé-odběratelé,
průmysl, obchod-banky
ČUZK
8. Rozsah a
úroveň
uživatelské sféry
zajištění podpory konzultačních funkcí,
náročnost/jednoduchost
předpokládaných aplikací a jejich vazeb,
analýza zkušeností uživatelů v IT,
s dopady na uživatelské rozhraní
podpora „help desk“, „hot
line“,
zejména u velkých
systémů s účastí
veřejnosti, silnou dislokací
jednotek
9. Stav IS/IT možnosti integrace stávajících zdrojů do
nové architektury IS/IT,
možnosti integrace stávajících
personálních kapacit organizace do
vývoje a provozu IS/IT
organizace s dlouholetou
tradicí a zkušenostmi
v IS/IT při přechodu na
novou architekturu
10.
Předpokládané
změny
v předmětu a
charakteru
činnosti
orientace na vysokou flexibilitu IS/IT,
zajištění možností rekonfigurace IS
vzhledem k organizačním změnám
organizační změny
související s vlastnickými
otázkami, restrukturalizací
výroby, …
28
Vrstva prostředí
Ekonomické prostředí, legislativa, organizační struktury, personální kapacity, jejich kvalifikace,
zkušenosti v IT, motivace pro IT, …
Vrstva aplikační
Provozované i řešené projekty určující charakter aplikací, jejich dokumentace, funkční a datové
specifikace, organizační pravidla, aplikační software, …
Vrstva technologická
Návrh a provoz počítačových sítí, vymezení jednotlivých komponent IT – základního software,
technických prostředků, jejich vazby a vnitřní struktura, …
Obr. 5 Vrstvy v architekturách IS/IT (Dohnal, Pour 1997)
Vrstvy IS jsou chápány ze dvou pohledů:
1. vrstvy IS jako celku
2. vrstvy v rámci každého ze stavebních bloků architektury
Na úrovni aplikační a technologické vrstvy zahrnuje IS řadu různorodých komponent, které jsou pak
založeny na vlastních, vnitřních architekturách respektujících potřeby vyjádření základní logiky řešení.
Vedle celkové architektury IS/IT a jejích vrstev existují další dílčí architektury odpovídající základním
dimenzím.
Vrstvu aplikační tvoří: Funkční a procesní architektura,
Datová architektura,
Aplikační architektura, aplikační software a jejich architektury.
Vrstvu technologickou tvoří: Informační technologie jako celek,
Komponenty základního software a jejich architektury (architektury databázových systémů,
operačních systémů atd.)
Jednotlivé technické prostředky a jejich vnitřní architektury.
Do aplikačního software se promítají požadované funkce (funkční architektura) a zpracovávaná data
(datová architektura).
Technologická architektura (IT) vytváří společný rámec, společné principy, na nichž se provozují a
obsluhují prostředky a moduly základního software a technických prostředků (HW) – hlavně
centrálních počítačů, serverů nejvíce ovlivňujících výkon celého IS.
29
Základním problémem v řešení IS/IT je najít takové vztahy mezi jednotlivými architekturami, které
povedou k zvýšení kvality a výkonu celého IS. Chyby v této oblasti znamenají:
Neúměrnou složitost systému,
Prodlužování vývoje a řešení systému,
Prodlužování doby odezvy,
Snižování flexibility vzhledem k novým uživatelským požadavkům,
Snižování spolehlivosti, zvyšování rizika výpadků, apod.
Jiný přístup k pojetí SW architektury přináší Gála et al. (2009, s. 53-59), kteří rozlišují:
Modely s centralizovaným zpracováním
Modely s decentralizovaným zpracováním
Modely s distribuovaným (klient-server) zpracováním.
Pro libovolnou aplikaci informačního systému je definována:
o Prezentační logika
o Aplikační logika, někdy ještě členěná na aplikačně specifické prvky (application logic)
a prvky obchodních pravidel a omezení (business logic)
o Datová logika (čtení a zápis dat, kontrola dat)
Podle rozmístění zpracování dat se rozlišuje:
o Dvoúrovňový model klient/server, kde klient je zpravidla realizován jako tenký nebo
tlustý klient
o Tříúrovňový model klient/server
o N-úrovňový model klient/server
Vzory výměny zpráv.
6.2 Grid computing
Grid v pravém slova smyslu je dnes definován jako infrastruktura umožňující sdílet kapacity a funkce,
integrovat služby a prostředky v rámci organizací a mezi nimi, umožňující aktivní spolupráci
v distribuovaném multiorganizačním prostředí. Mezi prostředky, s nimiž grid nakládá, patří výpočetní
kapacity (uzly, procesory), úložné prostředky (paměť, archivy, úložné sítě), data (charakterizovaná
umístěním a dostupností), sítě (charakterizované šířkou pásma a zpožděním), software a služby
(Pužmanová, 2010).
Hlavní cílem grid computimgu je propojit distribuované výzkumné skupiny s jejich výpočetními a
úložnými prostředky do jednotného systému schopného zvládnout úkol přesahující možnosti každého
jednotlivého výzkumného centra s využitím velmi rychlých sítí a vhodného softwaru .
Taková infrastruktura je na rozdíl od svých předchůdců (superpočítačů) a současníků (klastrů)
specifická tím, že ji vlastní, spravuje a využívá větší počet organizací. Už se nejedná o monolitickou
strukturu z hlediska hardwaru a softwaru, ale o infrastrukturu sestávající z různých typů operačních
systémů i síťových technologií. Takže grid ve své podstatě může zahrnovat nejrůznější typy systémů:
od stolních počítačů až po superpočítače a klastry, úložná zařízení a databáze, senzory i vědecké
přístroje (Pužmanová, 2010).
Soustava (grid) výpočetních systémů nemá moc dlouhou historii a je výsledkem vývoje
distribuovaných výpočetních systémů. Původní superpočítače značné velikosti rozdělovaly zátěž mezi
několik procesorů. Po nich přišly klastry, které již využívaly dostupných počítačových systémů (PC
typicky s Linuxem) a nabídly značné kapacity pro paralelní zpracování dat, byť jen na malém prostoru
oddělení či kampusu. Nasazení klastrů splývá s počátky gridu, protože jejich existence umožnila, aby
si uživatelé sami stavěli velké výpočetní systémy (Pužmanová, 2010).
Název grid (ve významu mřížka) jakoby vypovídá o topologickém propojení jednotlivých výpočetních
systémů, ale je za ním ještě něco víc. Podobně jako elektrická distribuční síť (označovaná odedávna
právě jako grid) je dnes dostupná téměř každému kdekoli na světě, i moderní komunikační grid by měl
být dostupný všude, a tak zpřístupnit výpočetní kapacity skutečně globální vědecké komunitě.
A možná nejen jí, protože každý uživatel v ideálním světě by mohl svůj počítač prostě k takové síti
30
připojit a získat okamžitě přístup k supervýpočetním možnostem za dostupnou cenu (Pužmanová,
2010).
Proč vůbec budovat a používat grid?
Z četných výzkumů vyplývá, že PC každého z nás využívá pouze 10% z celkového strojového času a
po většinu doby jen nečinně vyčkává na další úkoly. Asi nejznámější implementací Grid computingu -
a snad největším distribuovaným počítačem světa - je projekt SETI@home (Searching for
ExtraTerrestrial Intelligence project) z Kalifornské univerzity v Berkeley, zabývající se hledáním
mimozemských inteligentních civilizací analýzou signálů přicházejících z vesmíru. SETI využívá
výpočetní kapacitu našich PC a aktivuje se např. v době spuštění šetřiče obrazovky a pomáhá s
analýzou malých vzorků dat centrálnímu superpočítači umístěnému přímo v kampusu univerzity
(Moser, 2003).
Obr. Příklad fungování gridu na bázi frameworku BOINC, využitého např. pro SETI projekt
Grid vs Cluster (http://kfe.fjfi.cvut.cz/~stanek/Data/grid.pdf):
cluster se nachází na jednom geografickém místě
počítače v gridu mohou vykonnávat jen mezi sebou nezávislé úkoly
počítače v clusteru sdílejí společnou paměť
Výhody / Nevýhody gridů (http://kfe.fjfi.cvut.cz/~stanek/Data/grid.pdf)
nižší pořizovací cena
geografická rozptýlenost
snažší programování než pro super-počítače
malá rychlost komunikace mezi jednotlivými proceosry a datovýmí oblastmi =>
vhodné jen pro určité typy aplikací
Celosvětově i v rámci regionů vznikají organizace (Globus, GGF - Global Grid Formu, EGF -
Eouropean Grid Forum) finančně podporující vývoj projektů ve snaze uvést teoretické modely
do praxe a zpřístupnit enormní výpočetní výkon nejrůznějším oblastem vědy a výzkumu
(Moser, 2003):
31
lékařství
genetika
strukturní biologie včetně návrhu léčiv
fyzika částic
astronomie
kvantová chronodynamika
nelineární fluidní dynamika
doprava
geologický průzkum
oceánografie
rozpoznávání řeči
vidění
datamining
environmentalistika - sledování vlivů průmyslu a zásahů člověka do životního prostředí,
klimatologie a předpověď počasí
chemie - vývoj nových sloučenin,
materiálové vědy včetně návrhu polovodičů
6.3 Cloud computing
Cloud computing je na Internetu založený model vývoje a používaní počítačových technologií. Lze
ho také charakterizovat jako poskytování služeb či programů uložených na serverech na Internetu s
tím, že uživatelé k nim mohou přistupovat například pomocí webového prohlížeče nebo klienta dané
aplikace a používat je prakticky odkudkoliv. Uživatelé neplatí (za předpokladu, že je služba placená)
za vlastní software, ale za jeho užití. Nabídka aplikací se pohybuje od kancelářských aplikací, přes
systémy pro distribuované výpočty, až po operační systémy provozované v prohlížečích, jako je
například eyeOS, Cloud či iCloud (Wikipedia).
Technologie Cloud computingu se vyznačuje následujícími atributy (Wikipedia):
Multitenancy - tento pojem lze volně přeložit jako "více nájmů". Jedná se o to, že počítačové
zdroje jsou sdílené mezi všemi uživateli
Obrovská škálovatelnost a elasticita - umožní uživatelům rychle změnit výpočetní zdroje dle
potřeby.
Pay as you go - tento přístup je založen na principu kolik toho uživatel spotřebuje, tolik
zaplatí.
32
Aktualizovanost (Up-to-date) - všechen software je automaticky aktualizovaný, uživatel
nemusí do tohoto procesu nijak zasahovat, vše zařídí poskytovatel.
Přístup přes Internet - uživatelé se mohou ke svému softwaru připojit kdekoliv po celém světě.
Model nasazení nám říká, jak je cloud poskytován (Wikipedia).
Veřejný (Public cloud computing) — Někdy je označován jako klasický model cloud
computingu. Jedná se o model, kdy je poskytnuta a nabídnuta široké veřejnosti výpočetní
služba.
Soukromý (Private cloud computing) — Oblak je v tomto případě provozován pouze pro
organizaci a to buď organizací samotnou, nebo třetí stranou.
Hybridní (Hybrid cloud computing)— Hybridní cloudy kombinují jak veřejné tak soukromé
cloudy. Navenek vystupují jako jeden cloud, ale jsou propojeny pomocí standardizačních
technologií
Distribuční model se zabývá tím, co je v rámci služby nabízeno, obvykle software nebo
hardware či jejich kombinace (Wikipedia).
IaaS — infrastruktura jako služba (z "Infrastructure as a Service") — v tomto případě se
poskytovatel služeb zavazuje poskytnout infrastrukturu. Typicky se jedná o virtualizaci.
Hlavní výhodou tohoto přístupu je to, že se o veškeré problémy s hardwarem stará
poskytovatel. Na druhou stranu je někdy velice těžké toto akceptovat vzhledem k tomu, že
hardware se bere jako něco, co vlastníme, na co můžeme sáhnout a jsme za to zodpovědní.
IaaS je vhodné pro ty, kteří vlastní software (či jejich licence) a nechtějí se starat o hardware.
Příkladem IaaS jsou Amazon WS, Rackspace nebo Windows Azure. Zkratka IaaS může také
znamenat integrace jako služba (z "Integration as a Service").
PaaS — platforma jako služba (z "Platform as a Service") — poskytovatel v modelu PaaS
poskytuje kompletní prostředky pro podporu celého životního cyklu tvorby a poskytování
webových aplikací a služeb plně k dispozici na Internetu, bez možnosti stažení softwaru. To
zahrnuje různé prostředky pro vývoj aplikace jako IDE nebo API, ale také např. pro údržbu.
Nevýhodou tohoto přístupu je proprietární uzamčení, kdy může každý poskytovatel používat
např. jiný programovací jazyk. Příkladem poskytovatelů PaaS jsou Google App Engine nebo
Force.com (Salesforce.com).
SaaS — software jako služba (ze "Software as a Service") — aplikace je licencována jako
služba pronajímaná uživateli. Uživatelé si tedy kupují přístup k aplikaci, ne aplikaci samotnou.
SaaS je ideální pro ty, kteří potřebují jen běžné aplikační software a požadují přístup
odkudkoliv a kdykoliv. Příkladem může být známá sada aplikací Google Apps, nebo v
logistice známý systém Cargopass.
33
7 Úlohy a typy projektů při výstavbě IS
Úlohy můžeme rozdělit na úlohy v systému a na systému (Vlček, 1991?). Úlohy v systému
řeší úlohy pro vertikálně vymezené části IS, např. pro jednotlivé moduly, může ale jít i o
vývoj celého komplexního informačního systému.
7.1 Úlohy v aplikační vrstvě IS/IT
Řešení aplikační vrstvy IS:
a) Vývoj specializovaného, „jednoúčelového“ software podle potřeb konkrétního zákazníka.
státní správa, bankovnictví, armáda, ….
b) Nákup a instalace typového aplikačního software s minimálními nároky na jeho úpravy
(customizaci).
malé projekty - účetnictví firem, systémy malých provozoven, …
c) Komplexní projekty založené na výběru aplikačního SW, jejich customizace, jejich
vzájemná integrace a případné dořešení a implementace částí nebo modulů, které typový SW
nepokrývá nebo neodpovídá potřebám zákazníka.
střední a velké průmyslové a obchodní podniky, banky, dopravní společnosti, větší společnosti
cestovního ruchu, …
Většina projektů využívá outsourcing. Externím dodavatelem je většinou tvůrce nebo distributor
ASW.
Systémovým integrátorem je buď externí firma nebo zákazník sám.
Využívají se různé metodiky, v praxi jich existuje celá řada. Jedná se především o metodiky jejichž
autory jsou velké SW nebo konzultační firmy.
SAP pro R/3, BAAN pro BAAN, ODW (Object Development Workbench) firmy SSA pro BPCS,
4Front firmy Delloite and Touche, SmartStep firmy Dun & Bradstreet, …
Metodiky a jejich metody musí být jen doporučením, nikoliv dogmatem, které se musí pružně
přizpůsobovat potřebám a zvyklostem prostředí ve kterém se aplikují. Rovněž musí splňovat
požadavek na modularitu, tzn. že v daném případě může být aplikována pouze vybraná část metody
nebo k ní vázané techniky nebo nástroje.
7.2 Úlohy na architektuře IS/IT
7.2.1 Úlohy systémových vlastností
Cílem těchto úloh je dosáhnout určitých požadovaných vlastností informačního systému na základě
analýzy současných problémů a dostupných zdrojů a navrhnout účinný způsob jejich využití. Je nutné
v této souvislosti zdůraznit, že většinou nejde pouze o zdroje technologické (technologické vrstvy) ale
i personální, metodické, organizační opatření a další.
Zařazujeme sem úlohy podle následujícího přehledu:
Úlohy zajištění bezpečnosti systému:
cílem úloh bezpečnosti IS/IT je zajistit jeho obranyschopnost proti úmyslnému nebo neúmyslnému
narušení přístupových práv uživatelů, zneužití dat a případně jiných zdrojů a dále ochranu
uživatelů před fatálními chybami nebo omyly při práci s aplikacemi IS/IT,
34
řešení bezpečnosti systému představuje analýzy bezpečnostních rizik a na jejich základě formulaci
bezpečnostních pravidel a norem,
bezpečnostní úlohy se promítají do nároků na zajištění bezpečnosti v řešení a provozu
jednotlivých projektů do kritérií pro výběr jednotlivých technologických komponent
(databázových systémů, operačních systémů, …), do specifikace požadované úrovně bezpečnosti
těchto komponent (např. na základě mezinárodních norem),
bezpečnostní úlohy formulují komplex organizačních opatření spojených s provozem celého
informačního systému.
Úlohy spolehlivosti systému:
cílem úloh spolehlivosti je dosažení požadované úplnosti, konsistence, přesnosti, validity
zpracovávaných dat,
zahrnují snížení chybovosti dat minimalizací jejich přepisování, duplicitního zpracování nebo
uložení,
úlohy spolehlivosti se promítají do nároků na kontrolní rutiny řešené jako součást jednotlivých
projektů, do nároků na zálohování a archivaci dat, do organizačních opatření spojených
s testovacími a předávacími procedurami projektů,
Úlohy systémové doby odezvy:
cílem úlohy je zkrácení celkové doby odezvy IS/IT na vstupy z okolí (např. snížení doby reakce na
příchod objednávky, zkrácení obchodních a výrobních cyklů apod.),
latency versus response time
úlohy systémové doby odezvy se promítají do nároků na výkon instalovaných informačních
technologií, přenosových cest, na efektivnost řešení aplikačních software z pohledu dosahované
doby odezvy, ale i (a často nejpodstatněji) do nároků na racionalizaci obchodních procedur a jejich
zjednodušení.
Příklad z Horák et al. (2012): Hodnocení výkonnosti, kapacity a dostupnosti služeb bylo provedeno na základě požadavků NAŘÍZENÍ KOMISE (EU) č. 1088/2010 ze dne 23. listopadu 2010, kterým se mění nařízení (ES) č. 976/2009, pokud jde o služby stahování dat a transformační služby, 8.12.2010, L323/1.
Výkonnost:
Normální situací se rozumí období mimo špičkové zatížení. Představuje 90 % času.
U operace „získat metadata služby stahování dat“ (Get Download Service Metadata) musí být za normální situace doba odezvy k odeslání prvotní odpovědi nejvýše 10 sekund.
U operací „získat sadu prostorových dat“ (Get Spatial Data Set) a „získat prostorový objekt“ (Get Spatial Object) a u dotazu sestávajícího výlučně z geografického ohraničujícího obdélníku musí být za normální situace doba odezvy k odeslání prvotní odpovědi nejvýše 30 sekund a služba stahování dat poté musí, stále za normální situace, udržovat odezvu vyšší než 0,5 megabytu za sekundu nebo vyšší než 500 prostorových objektů za sekundu.
U operací „popsat sadu prostorových dat“ (Describe Spatial Data Set) a „popsat typ prostorového objektu“ (Describe Spatial Object Type) musí být za normální situace doba odezvy k odeslání prvotní odpovědi nejvýše 10 sekund a služba stahování dat poté musí, stále za normální situace, udržovat odezvu vyšší než 0,5 megabytu za sekundu nebo vyšší než 500 popisů prostorových objektů za sekundu.
Kapacita:
35
Minimální počet požadavků simultánně vyřizovaných službou stahování dat musí být 10 požadavků za sekundu, aby došlo ke splnění kvalitativních kritérií týkajících se výkonnosti. Počet souběžně vyřizovaných požadavků může být omezen na 50.
Dostupnost:
Pravděpodobnost dostupnosti síťové služby musí být 99 % času.
Úlohy kapacitní
cílem kapacitních úloh je dosažení kapacity a výkonu informačního systému, aby odpovídal
požadavkům zákazníka s přiměřenou rezervou,
Např. požadavky INSPIRE na kapacitu síťových služeb (prohlížecí 20 už. současně).
kapacitní úlohy musí zahrnovat analýzy nejrůznějších sezónních výkyvů v zatížení informačního
systému (např. na konci finančních období, při obchodních špičkách,apod.) – na tyto mezní situace
musí být systém dimenzován nebo zajištěny záložní zdroje,
řešení kapacitních úloh se promítá vedle obvyklých nároků na technologické zdroje i do nároků na
personální kapacity a s tím související organizaci pracovních týmů, do nároků na organizaci
provozu, do nároků na získání a využití externích pracovních nebo technologických zdrojů,
Obr. Celkový výkon prezentovaný zpracováním počtu požadavků za sekundu (Horák et al., 2010)
36
Obr. Nárůst chybovosti v závislosti na počtu uživatelů (Horák et al., 2010)
Úlohy flexibility informačního systému:
cílem úloh flexibility je dosažení požadované pružnosti informačního systému v reakcích na
změny v okolí (v legislativě, změnách ve vztazích s obchodními partnery, s bankovním sektorem
apod.) a dále v reakcích na změny v podnikové strategii, cílech podniku, na změny organizačních
personálních struktur podniku,
např. co když dojde ke změně DPH? Co když se objeví nový zdroj leteckých dat?
řešení úloh se promítá do nároků na řešení projektů, úroveň jejich parametrizace, na otevřenost
prostředků základního software a technických prostředků, ale i do nároků na organizaci
projekčních týmů jejich přizpůsobitelnost novým požadavkům podniku, do nároků na kvalifikační
přípravu pracovníků a schopnost jejich přizpůsobení novým technologiím a novým nárokům.
Dostupnost systému – externí služby
7.2.2 Úlohy ekonomicko-organizační
Úlohy ekonomicko-organizační se orientují na ekonomické analýzy vývoje a provozu informačního
systému, dosažení příznivých ekonomických i mimoekonomických efektů informačního systému,
rozvoj organizačních struktur v rámci informatiky a jejich zasazení do celopodnikových struktur apod.
do této skupiny řadíme následující úlohy:
Úlohy ekonomických i mimoekonomických efektů IS/IT:
cílem úlohy je formulace, sledování a vyhodnocování efektů spojených s rozvojem informačního
systému a na základě analýzy vývoje těchto efektů určování dalšího rozvoje IS/IT,
v rámci hodnocení těchto efektů je nutné počítat s úrovní jejich měřitelnosti a přesnosti
naměřených hodnot,
řešení úlohy se promítá do stanovení priorit a obsahu zadání projektů (např. posílení váhy úlohy
analytického charakteru), do definování nových informačních služeb poskytovaných zákazníkům,
do nároků na nové aplikace a technologie podporující např. elektronickou výměnu dat, do
37
formulace kvalifikačních programů ve směru vytvoření předpokladů pro využití náročných
aplikací a případně jejich vlastní další rozvoj.
Celkově zvýšení efektivity
Úlohy nákladových analýz IS/IT (zejména snížení nákladů):
cílem nákladových úloh je dosažení předpokládané úrovně nákladů, resp. jejich snížení, s využitím
analýz nákladů podle jejich druhů, nositelů, projektů a dalších hledisek,
úlohy nákladových analýz se promítají do nároků na sledování a vyhodnocování nákladů
vedoucími pracovníky projektů a provozních útvarů, na snížení nákladů na duplicitní nebo
multiplicitní operace s daty, na optimalizaci provozu informačních technologií z pohledu spotřeby
nákladů, a další
Úlohy racionalizace obchodních a řídících procedur:
cílem úloh je zjednodušení a optimalizace (z časového i nákladového hlediska) všech procesů
významných pro zajištění funkcí podniku a zkvalitnění předmětu řešení IS/IT již na samém
zahájení řízení nových projektů,
jednou ze součástí řešení úloh je využití progresivních řídících metod (JIT, OPT) a zhodnocení
disponibilních kapacit pro jejich uplatnění,
řešení úloh se promítá do nejrůznějších organizačních směrnic a pravidel podniku (na úrovni
vrstvy prostředí), do změn v popisech pracovních činností, do zadání jednotlivých projektů, do
požadavků na řešení technologické, komunikační infrastruktury,
např. slučování malých oborů
Úlohy rozvoje organizačních struktur IS/IT:
cílem úlohy je rozvoj organizační struktury IS/IT v souvislosti s novými požadavky na služby
systému, s rozvojem celopodnikové organizační struktury, s rozvojem vztahů s externími partnery,
řešení úloh se promítá do změn v organizačních směrnicích podniku, do složení a funkční náplně
pracovních týmů.
7.2.3 Integrační úlohy
Integrační tendence v informačních systémech jako výraz snahy o provázání jejich jednotlivých částí
se projevovaly již od šedesátých let, především s rostoucím uplatněním počítačů v ekonomické sféře.
Výsledky byly poplatné celkovému pojetí informačních systémů, použitým projekčním metodologiím
a ve značné míře i dostupným informačním technologiím. Ty ovlivnily i výrazné výkyvy
v dosahované úrovni integrace IS/IT, v pozitivním, ale i v negativním smyslu. To platí např. pro
osobní počítače, které právě ve své první fázi vývoje přinesly do informačních systémů vysokou míru
dezintegrace a teprve další posun ve vývoji počítačových sítí znamenal řešení takto vzniklých nových
integračních problémů.
Bez ohledu na vývojové cykly a změny lze říci, že integrace v IS/IT je trvalá vývojová tendence
s určitými obecně platnými znaky. Podstatou integrace je dosažení určité míry provázanosti
(efektivních vazeb) jednotlivých prvků IS/IT, např. na bázi automaticky předávaných dat mezi
úlohami nebo automaticky spouštěných procedur podle vzniklých událostí, a to i při vysoké
různorodosti nebo dislokaci těchto prvků. Z povahy těchto úloh již vyplývá, že se jejich řešení promítá
prakticky do všech vrstev architektury i do jejich jednotlivých komponent. Do integračních úloh
zařazujeme tyto úlohy:
Úlohy vnitřní / vnější integrace
cílem úloh vnitřní integrace je integrace jednotlivých elementů (software, hardware, dat, lidí)
IS/IT uvnitř systému.
cílem vnější integrace je realizace vazeb systému k okolí, tj. k dodavatelům, zákazníkům,
finančním ústavům, veřejným informačním službám apod. Někdy se tato integrace označuje jako
38
integrace s prostředím. Pro integraci IS/IT s okolím se v praxi jako rozhodující prosazuje
technologie EDI (Electronic Data Interchange) a služby Internetu
Úlohy vertikální / horizontální integrace
pro rozlišení integrace vertikální a horizontální jsou rozhodující úrovně řízení podniku.
Rozlišujeme zde úroveň vrcholového, středního a operativního řízení a úroveň provozní nebo
transakční, kterou se chápe např. řízení dílen, konstrukce apod. Cílem vertikální integrace je
provázáním jednotlivých úrovní řízení prostředky IT mezi sebou, zatímco horizontální integrace je
integrace úloh, dat, prostředků na jedné úrovni řízení.
Např. Komunikace, sdílení či výměna dokumentů
7.3 Metody výběru vhodných aplikací IT (i hodnocení stavu IT)
Při výběru jednotlivých aplikací, pořadí jejich realizace nebo prioritizace mohou pomoci následující
přístupy k jejich hodnocení (Molnár, skripta):
7.3.1 Porterův rozšířený model
Hodnotu jednotlivých aplikací IS/IT a jejich význam pro zabezpečování podnikových cílů si můžeme
odvodit od známého Porterova modelu pěti konkurenčních sil. Tento model je známým nástrojem
strategického auditu podniku a jeho schéma v rozšířené podobě je uvedeno na obr. 5. Zásadní otázky,
které si klademe při hledání odpovědi na otázku, jak nám může pomoci aplikace IS/IT k zachování
resp. získání konkurenceschopnosti je: „Jaká aplikace IS/IT zmírní či odstraní některou z hrozeb?“
Obr. 6 Porterův rozšířený model (Molnár, skripta)
Hrozbě stávajících konkurentů může podle Portera čelit buď (Klimeš, 2006):
strategií nízkých nákladů, zavedením IS pro řízení nákladů,
strategií kvality, zavedením IS pro řízení kvality
Rychlost, zavedením IS pro řízení zakázek,
strategií odlišení či nalezením mezery na trhu, zavedením Competitive Intelligence.
Hrozba vstupu nových subjektů na trh znamená, že by mohlo dojít ke globálnímu zvýšení výrobních
kapacit, tím pádem by převážila nabídka nad poptávkou, a tudíž by poklesla cena. Pomocí IS/IT tomu
můžeme čelit důslednějším řízením nákladů, výroby, zvýšením podílu inovovaných výrobků,
zvýšením úrovně distribučních kanálů, apod.
39
Hrozba nových produktů či služeb může být přímá (přechod z plynového na elektrické vytápění) nebo
nepřímá (nákup TV místo dovolené). Znamená to opět cenovou válku. Také zde ale může pomoci
aplikace vhodného IS/IT: snížení ceny produktu, lepší kontrola nákladů pomocí IS/IT, předvídání
preferencí zákazníka zavedením marketingového IS, zvýšení užitné hodnoty produktu (např. dálkové
monitorování), apod.
Hrozba stávajících konkurentů je nebezpečná v případě poklesu trhu. Mít správný produkt na
správném místě ve správný čas za správnou cenu, znamená mít perfektně fungující IS/IT o všech
těchto aspektech. IS/IT musí důkladně podporovat podnikatelskou strategii, podle Portera může být:
strategie nízkých nákladů, odlišení se či nalezení mezery na trhu. Znamená to mít perfektně fungující
marketingový IS – hlavně o zákazníkovi, počítačem integrovanou výrobu, kalkulační IS.
Vyjednávací síla dodavatelů, odběratelů je nebezpečná, existuje-li na některé straně monopol, je
nedostatek našich potřebných zdrojů nebo převaha nabídky našich produktů na trhu nad poptávkou. V
obou případech to lze řešit opět zavedením dobře fungujícího marketingového IS pro oblast prodejů a
nákupů, mít dokonalý přehled o dodavatelích i odběratelích (jejich zvyklostech, cenách, podmínkách,
…), mít možnost různých kalkulací obchodních nákladů (přirážky, rabaty).
7.3.2 McFarlanův model aplikačního portfolia
Tento model rozvádí podrobně přínosy jednotlivých aplikací pro podnik z pohledu jejich realizace v
současnosti či v budoucnosti. Míra přínosu je dána také tím, jestli je daná aplikace pro podnik kritická
nebo není.
Obr. 7 McFarlanův model (Klimeš, 2006)
Každý podnik by si měl sledovat jaké je jeho portfolio aplikací (jaké procento výdajů do IS/IT tyto
aplikace buduje a provozuje). Investice do potenciálních aplikací jsou velmi rizikové, proto se uvádí
různá procenta z celkových výdajů na IS/IT, která by měla být věnována které kategorii. Tyto procenta
je třeba brát jen jako orientační hodnoty. Význam jednotlivých typů aplikací na tvorbu přínosů pro
podnik je zachycen v následující matici (Klimeš, 2006):
Strategické Potenciální
Restrukturalizace procesů Inovace procesů
Klíčové Podpůrné
Koordinace procesů Úspora nákladů
7.3.3 BCG Boston Consulting Group
40
Mar
ket
gro
wth
rat
e STARS ? QUESTION MARKS
CASH COWS DOGS
Relativní podíl na trhu
7.3.4 SWOT
SWOT analýza je metoda, jejíž pomocí je možno identifikovat silné (ang: Strengths) a slabé (ang:
Weaknesses) stránky, příležitosti (ang: Opportunities) a hrozby (ang: Threats), spojené s určitým
projektem, typem podnikání, podnikatelským záměrem, politikou (ve smyslu opatření) apod.
V zásadě se hodnotí 2 základní aspekty – pozitiva a negativa, resp. vnitřní a vnější faktory (tj. 4 pole).
Jedná se o metodu analýzy užívanou především v marketingu, ale také např. při analýze a tvorbě
politik (policy analysis). Díky tomu je možné komplexně vyhodnotit fungování firmy, nalézt problémy
nebo nové možnosti růstu. Je součástí strategického (dlouhodobého) plánování společnosti (Klimeš,
2006).
Analýza silných a slabých stránek se zaměřuje především na interní prostředí firmy, na vnitřní faktory
podnikání. Příkladem vnitřních faktorů podnikání je výkonnost a motivace pracovníků, efektivita
procesů, logistické systémy, a podobně. Silné a slabé stránky jsou obvykle meřeny interním
hodnotícím procesem nebo benchmarkingem (srovnáváním s konkurencí). Silné a slabé stránky
podniku jsou ty faktory, které vytvářejí nebo naopak snižují vnitřní hodnotu firmy (aktiva, dovednosti,
podnikové zdroje atd.) (Klimeš, 2006).
Naproti tomu hodnocení příležitostí a ohrožení se zaměřuje na externí prostředí firmy, které podnik
nemůže tak dobře kontrolovat. Přestože podnik nemůže externí faktory kontrolovat, může je alespoň
identifikovat pomocí například vhodné analýzy konkurence, demografických, ekonomických,
politických, technických, sociálních, legislativních a kulturních faktorů působících v okolí podniku. V
běžné praxi tvoří SWOT analýzu soubor potřebných externích i interních analýz podniku. Mezi externí
faktory firmy se řadí například devizový kurz, změna úrokových sazeb v ekonomice, fáze
hospodářského cyklu a další (Klimeš, 2006).
41
8 Systémová integrace Úkolem systémové integrace je zajistit, aby se všechny části IS/IT podniku chovaly jako 1 logicky
fungující celek (Molnár). To platí i pro produkty různých výrobců a různých funkcí.
Pokud se používá vrstvená architektura aplikace, jedná se o problém rozhraní (interface) mezi
jednotlivými částmi IS/IT.
Systémová integrace zahrnuje:
ve strategické rovině – propojení podnikatelských záměrů do informační strategie (rozhraní mezi
vrstvou prostředí a aplikačních vrstvou)
v projektové rovině – konsistentní architektura a navržení procesů informačního systému (rozhraní
mezi aplikacemi)
v řídící rovině – optimalizace organizace a řízení dodávek komponent informačního systému od
subdodavatelů (rozhraní mezi aplikací a technologickou vrstvou)
v technicko-technologické rovině – propojení HW a SW (rozhraní mezi technologickými
komponentami IS/IT), přenosy dat
Z tohoto rozdělení vyplývají základní typy systémových integrátorů:
1) Stratég Jeho doménou je informační strategie. Primární je zajištění „správných věcí“, tedy co se má dělat
proč, až následně jak. Proč a jak se má investovat do IS/IT. Hledá přínosy a převádí je do
měřitelných cílů.
2) Projektant.
Připravuje návrhy řešení jednotlivých projektů. Zpravidla aplikuje vodopádový životní cyklus.
3) Manažer.
Soustřeďuje se na řídící výstupy systémově integračních projektů, zejména časové a nákladové
aspekty. Definuje způsob řízení projektu, řídící struktury projektu, řídící procedury pro řízení
jakosti atd. Sladění harmonogramů.
4) Technik.
Zaměřuje se na propojení komponent systému.
42
9 Metodické základy výstavby informačních systémů Převzato z Molnára (1991).
9.1 Softwarové inženýrství
Požadavek zvýšení efektivnosti tvorby programového vybavení vedl ke vzniku samostatné vědní
disciplíny zvané softwarové inženýrství (SI). SI vznikla aplikací inženýrských, vědeckých a
matematických přístupů pro oblast tvorby softwaru. Jde o systematický přístup k vývoji, implementaci
a údržbě softwaru. Skládá se z metod, technik, nástrojů a přístupů, jejichž používání se v praxi ukázalo
jako efektivní. Metodologové SI zobecňují zkušenosti úspěšných systémových analytiků, projektantů,
programátorů a administrátorů databází tak, aby s jejich úspěšnými metodami mohli pracovat i ostatní.
Softwarové inženýrství vychází z pěti principů.
1. Princip modelování je dán využíváním různých grafických zobrazovacích metod, jako jsou
diagramy toku dat, procesní diagramy, akční diagramy, diagramy datových struktur apod.
Zvláštním případem modelování je používání tzv. živých modelů zvaných prototypy.
2. Princip iterace vychází z toho, že v praxi se málokdy podaří napoprvé vyřešit celý komplexní
problém k úplné spokojenosti uživatele. Tento princip je opět zvýrazněn v již zmíněném
prototypovém přístupu.
3. Princip strukturování, tj. postupného hierarchického rozkladu celého komplexního problému na
menší celky, které jsou zvládnutelné v podmínkách omezených technických i lidských zdrojů
v rozumném čase. Problém „jak úlohu řešit“ je nutno již od samého začátku spojit s problémem
„jak úlohu rozdělit“.
4. Princip životního cyklu zachycuje komplexně celý proces vývoje i užívání IS, zejména pak
rozdělení nákladů v čase a umožňuje používat diferencované nástroje pro řízení IS v jeho
jednotlivých životních fázích.
5. Princip automatizace, resp. počítačové podpory, znamená využívání počítačové podpory pro
celou dobu životního cyklu. Především jde o jednotnou databázovou podporu v podobě tzv.
projektové databáze a využívání především různých grafických zobrazovacích technik a
generátorů programů.
9.2 Informační inženýrství
Informační inženýrství je pojem zavedený J. Martinem na začátku 80.let zejména v souvislosti
s výstavbou velkých databázových systémů. Zaměřuje se na informace uložené a udržované v počítači
a ostatní informace z nich odvozené za účelem vytvoření „informačního modelu podniku“.
Jeho centrální hypotézou je, že data (informace) jsou srdcem IS, a že různé systémy IT jsou určeny
jenom k tomu, aby je vytvářely, udržovaly, manipulovaly s nimi a rozšiřovaly je. Druhou jeho
hypotézou je, že data jsou nejstabilnější složkou IS. Proto Martin upřednostňuje datově orientované
(„data-driven“), tj. relativně málo se měnící stabilní systémy oproti procedurově orientovaným
„procedure-driven“ systémům, které se mění velmi často. Proto také hlavní role ve výstavbě IS je
přisuzována funkci administrátora databáze (správci dat) v podniku.
Podle hesla „rozděl a panuj“ vychází Martin z toho, že pokud je k dispozici normalizovaná centrální
logická databáze obsahující veškerá potřebná data v podniku, pak je možno strukturovat i poměrně
složité IS systémy do řady malých jednoduše zvládnutelných aplikací, které je pak možno nad touto
databází poměrně rychle implementovat, zejména jsou-li k tomu používány výkonné neprocedurální
programovací jazyky čtvrté generace. Minimalizují se tím i problémy komunikace spojené s řízením
velkého týmu programátorů, protože veškerý styk vývojových pracovníků se děje prostřednictvím
jednotného datového modelu.
9.3 Organizační inženýrství
Softwarové a informační inženýrství je zaměřeno více na technologickou stránku tvorby a užití IS, tj.
nezabývá se do velké podrobnosti problematikou obsahu IS, jeho účelu a prostředí, ve kterém má být
43
používán, tj. podnikem a jeho organizací. Proto prosazoval komplexnější přístup k výstavbě IS
označovaný termínem „organizační inženýrství“.
Termínem organizační inženýrství se rozumí systematický inženýrský přístup k budování prosperující
a výkonné organizace podniku založené na pružné a objektivní práci s aktuálními informacemi v tzv.
„firemní paměti“. Organizační inženýrství je spojením metod informačního inženýrství a
organizačních metod a praktik.
Základ organizačního inženýrství je možno vyjádřit zkratkou KISS – Komunikace, Informace,
Systémovost a Standardizace. V praktickém postupu to znamená zaměření na komunikace podniku,
podobně jako je to u přístupu informační architektury (viz dále), otevření a zpřístupnění informací
prostřednictvím centrálního katalogu dat (podnikové encyklopedie), systematické provádění všech
opatření s použitím inženýrských metod a maximální standardizaci všech rozhraní pro předávání
informací podobně, jako to u nás navrhoval již v 60.létech prof. Vlček.
Postup budování organizace se provádí obecně ve dvou krocích, jimiž jsou:
- diagnostika stavu a identifikace problémů
- zlepšování stavu, jeho kultivace
Systematická kultivace organizace je založena na tzv. Organization Performance modelu (model
zvyšování výkonnosti organizace), který je tvořen následujícími vzájemně provázanými bloky:
1. Zhodnocení situace v organizaci vzhledem k jejímu okolí
2. Stanovení nebo korekce strategických cílů
3. Formování spočívající v:
- identifikaci činností
- přiřazení lidí k činnostem
- vytvoření struktury
- návrhu principů oceňování důležitosti činností
- identifikaci informačních potřeb
- rozdělení kompetencí
4. Budování kultury organizace spočívající v:
- pracovních zvycích, návycích a chování
- praktikách a způsobech realizace poslání organizace
5. Analýza výsledků působení organizace
Celý proces probíhá formou pracovních seminářů podle připraveného scénáře. Výsledky všech etap
budování IS jsou zaznamenány a přesně dokumentovány v metainformačním systému zvaném
CENCAT – Centrální komunikační katalog. Veškeré v něm uložené informace lze operativně
aktualizovat, prohledávat a vyhodnocovat.
9.4 Rapid development metody
Za nový přístup můžeme označit metody rychlého vývoje, které využívají výhod CASE systémů a
návrh a vývoj urychlují postupným vývojem v tomto prostředí a přímo realizací produktu na základě
generovaného programového kódu.
Více viz další kapitola.
44
10Přístupy k výstavbě informačních systémů
10.1 Tradiční strukturovaný přístup životního cyklu.
Životní cyklus (live cycle) každého IS je tvořen jeho životními fázemi popisujícími jeho život od
narození do smrti. Počet životních fází je podle různých autorů různý (pohybuje se od 4 do 8) a
všeobecná tendence je redukovat jejich počet. Obyčejně se spokojíme se čtyřmi fázemi:
- plánování (specification, inception)
- návrh (design)
- zavádění (implementation)
- provoz a údržba (operation and maintenance)
Cíle tradičního a strukturovaného vývoje byly především:
- zvýšení discipliny tím, že se zavedla jednotná a povinná dokumentace a řada standardů, které
bránily vytváření tzv. „špagety kódů“, tj. nepřehledných vývojových diagramů programů
- možnost řešení komplexnějších problémů tím, že se uplatňovala strukturovaná hierarchická
funkční dekompozice shora dolů (top-down analysis)
- zvýšení spolehlivosti a snadnost oprav chyb tím, že na každém stupni vývoje byly prováděny
podrobné kontroly tak, aby byla chyba zachycena co nejdříve
- zvýšení využití zdrojů jak lidských, tak i finančních tím, že byla systematicky prováděna kontrola
provedených prací a nákladů v jednotlivých fázích výstavby
- lepší řízení
Za hlavní nedostatek přístupu životního cyklu se uvádí příliš dlouhá průběžná doba od definice
potřeby (specifikace požadavků) do zavedení systému do užívání. V důsledku této doby často
docházelo ke změně těchto potřeb a systém byl pak nepoužitelný, nebo se musely pracně a nákladně
provádět změny. Proto se na počátku 80. let metodologie soustřeďují na problematiku počátečních
vývojových fází systému, tj. na fázi specifikace požadavků, resp. plánování IS, aby se dělalo co
nejméně chyb v těchto počátečních fázích vývoje systému, jak již bylo uvedeno v předchozí kapitole.
V 80. letech se klasický vodopádový přístup modifikuje ve dvou směrech, a to směrem k tzv.
prototypovému přístupu a směrem k zajišťování výstavby IS nákupem hotových aplikačních
programových systémů.
10.2 Prototypový přístup
Myšlenka prototypového přístupu k výstavbě IS vznikla ze vcelku oprávněného požadavku uživatelů
implementovat co nejrychleji alespoň nějakou fungující část IS za účelem produktivního využívání
instalované výpočetní techniky. Uživatelé si často a právem stěžují nejen na to, že průběžná doba od
zahájení projektu do jeho předání uživateli je příliš dlouhá, ale i na to, že IS nesplňuje to, co od něho
očekávali, a že se obtížně rozšiřuje nebo upravuje.
Výše uvedené potíže vyplývají především z nedorozumění mezi uživatelem a projektantem. Toto
nedorozumění pramení ze dvou příčin.
1. Z neschopnosti uživatele formulovat dostatečně přesně své požadavky. Tento problém je
implicitně obsažen v každém lidském konání, které směřuje od formulace cílové funkce nějakého
systému k jeho realizaci a testování. Teprve ověření praxí ukáže, zda systém přináší ty efekty,
které uživatel očekával.
2. Z rozdílnosti „jazyků“, jimiž se mezi sebou dorozumívají. Toto je zapříčiněno nejen odlišným
způsobem uvažování, odlišným systémem preferencí a odbornými termíny, ale především tím, že
předpokládají, že znalosti jedné strany jsou samozřejmě i znalostí druhé strany.
Další nedorozumění pramení z neporozumění datům. Touto chybou se vyznačují zvláště projektanti,
kteří se více soustřeďují na algoritmickou stránku řešení a neuvědomují si, že to, co je v systému
nejstabilnější a co zároveň integruje celý systém, jsou právě data ve smyslu jejich typů a vzájemných
45
vztahů. Je proto nutno vést projektanty k tomu, aby se zaměřili především na poznání, porozumění
datům, se kterými v informačním systému pracují.
Přístup k budování IS, který preferuje zaměřenost na analýzu procesů a postupné spojování těchto
procesů vede ke „slepování“ datových struktur navržených pro jednotlivé procesy. To pak vždy skončí
zjištěním, že data jsou nekonsistentní a je třeba přestavět datové struktury a v důsledku toho předělat i
programy s nimi pracující.
Cílem prototypového řešení je tedy vytvořit co nejrychleji, třeba i v triviální formě (tzv. 1. prototyp)
jádro budoucího systému a pak toto jádro postupně zkvalitňovat, tj. rozvíjet a rozlišovat podle potřeb
uživatelů a možností řešitelských kapacit. Tím se postupně vytvářejí další prototypy souběžně s již
rutinně provozovanými prototypy předchozími.
V literatuře se uvádějí různé definice prototypingu, z nichž si uveďme aspoň dvě:
Def.: Prototyp informačního sytému je dočasná verze systému, jež ukazuje základní rysy
systému, který bude později implementován. Zdůrazňuje se zde to, že prototyp musí být vytvořen
rychle, aby mohl sloužit jako vzor pro budoucí systém. Tento přístup bývá také nazýván „throw-it-
away“ (tzv. „zahazovací prototyp“). Jeho cílem je vytvořit fungující kostru systému a na ní odzkoušet
schůdnost a účinnost řešení. Tyto kostry se mohou vytvořit i dvě, tři a po jejich vyzkoušení se teprve
vypracuje zadání pro konečný systém.
Def.: Prototyping je metoda vývoje informačního systému založená na vytváření a užití modelu
systému (tzv. živý model) jako prostředku návrhu, oživení, testování a zavedení systému. Tato
definice akceptuje evoluční přístup, při kterém je vytvořený prototyp zahrnut do budoucího systému.
Je zde analogie s automobilem, který má nejprve jen motor, základní ovládací agregáty, a teprve pak
se na něj postupně montuje karosérie a další vylepšení.
Předpokladem úspěšné aplikace koncepce prototypů je třeba dodržování určitých zásad. Jde zejména o
tyto zásady:
a) Řádně vést projekt. Vedení projektu řešeného metodou prototypingu je velmi náročné, protože
zde dochází k překrývání fází projektu a nejsou jasně definované a odsouhlasené milníky
ukončující jednu fázi a vytvářející zadání pro fázi následující. Paralelní tok fází v prototypingu
umožňuje měnit požadavky na systém ještě ve fázi ověřování systému. Vedoucí projektu musí
citlivě posoudit, kdy je možno ještě uživateli vyhovět a kdy je již třeba další požadavky
nerespektovat. S tím souvisí i vedení dokumentace plynule vznikajících verzí programů. Toto je
možno zabezpečit dokonalým počítačově vedeným metainformačním systémem tak, jak to dnes
provádějí prakticky všechny systémy CASE – Computer Aided Software Engineering.
b) Předřadit datovou analýzu před analýzu funkční. To znamená, že dříve než se začnou tvořit
programy, je třeba mít definovány datové struktury. Tyto musí být naplněny vzorkem dat, kterým
budou měnit funkce, programy, počítač i programovací jazyky, ale nemělo by být důvodu ke
změnám datového modelu informačního systému.
c) Brzy uvést data do pohybu. Uživatel přizvaný ke zkoušení prototypu musí pracovat
s programem, který mu ukazuje, jak konkrétní data na vstupu vyvolají určitý proces zpracování,
jež vyprodukuje určitý konkrétní výstup. Uživatel tím získá pocit reálného ovládání programu a
program se mu už nejeví jako černá schránka.
d) Často zkoušet prototyp a modifikace provádět rychle, aby uživatel ani projektant neztráceli
souvislost. Jak uživatel, tak projektant se tedy musejí věnovat vývoji systému s plným časovým
nasazením. Pokud tento závazek na jedné ze stran není možno získat, nelze odpovědně přistoupit
ani k prototypingu. Požadavek snadného provádění rychlých změn opět podporují systémy typu
CASE.
46
10.3 Objektově orientované modelování
10.3.1 Charakteristiky objektů
Objektově orientované modelování je nový způsob přemýšlení o problému užitím modelů
organizovaných konceptů reálného světa. Základním stavebním prvkem je objekt (entita), který
v sobě zahrnuje jak datovou strukturu popisující určitou entitu, tak i pravidla chování této entity.
Objekt může být konkrétní, jako např. výrobek, zaměstnanec apod., ale i abstraktní, jako plánovací
strategie atd.
Pro každý objekt zavádíme čtyři charakteristické aspekty – jedinečnost, zatřiditelnost, mnohotvárnost
a dědičnost.
Jedinečnost (identity) znamená, že každý objekt je rozlišitelnou entitou, i když má jinak stejné
kvalitativní i kvantitativní charakteristiky (např. dvě úplně stejná jablka zůstávají stále dvěma
rozlišitelnými objekty, tj. jedno z nich můžeme sníst a druhé darovat). K rozlišení objektů pak musíme
při implementaci IS zavést identifikační klíč.
Zatřiditelnost (classification) znamená, že objekty se stejnou datovou strukturou (atributy) a
chováním (operacemi) jsou seskupovány do tříd. Třída je potom abstrakcí, jež popisuje vlastnosti
důležité pro určitou aplikaci a ignoruje ostatní vlastnosti. Každý objekt je přitom výskytem (instancí)
této třídy.
Mnohotvárnost (polymorphism) znamená, že ta samá operace se může chovat rozdílně a dávat
rozdílné výsledky pro různé třídy objektů. Např. operace pohyb znamená něco úplně jiného pro třídu
objektů „šachové figurky“ a něco jiného pro třídu objektů „výrobky na dílně“. Specifická
implementace operace pro určitou třídu objektů se nazývá metoda. V reálném světě však každý objekt
„ví jak“ má danou operaci provádět, a stejně tak i objektově orientovaný programovací jazyk zvolí
správnou metodu pro implementaci dané operace.
Dědičnost (inheritance) je sdílení atributů a operací mezi třídami založenými na hierarchických
vztazích. Třída může být definována poměrně široce a potom ji lze následně zjemňovat do podtříd.
Každá podtřída pak zahrnuje vlastnosti své nadřazené třídy.
10.3.2 Hlavní myšlenkové principy objektového modelování
Objektově orientované modelování je založeno na dále uvedených myšlenkových principech, které
nejsou samy o sobě ani nové, ani výhradou objektového modelování, ale které dobře vyjadřují
podstatu objektového přístupu.
1. Zobecnění (abstraction), které představuje zaměření na podstatné vnitřní aspekty objektivů, a
které ignoruje jeho nepodstatné vedlejší vlastnosti. Při vývoji systému to znamená klást důraz na
to, co objekt je, a co by měl dělat, a ne na to, jak by to měl dělat. Tato abstrakce nás chrání před
nezralými a přitom závaznými rozhodnutími o detailu.
2. Zapouzdření (encapsulation) nebo také“zakrytí informace“, což znamená oddělení externích
aspektů objektu, které jsou dostupné ostatním objektům od interních implementačních detailů
objektu, zakrytých ostatním objektům. Encapsulace chrání systém před závislostí na malých
změnách objektů, které by mohly mít masivní vliv na rozrušení systému. Jinými slovy to znamená,
že implementace objektu může být změněna, aniž by se to dotklo aplikací, ve kterých je objekt
použit.
3. Sdílení (sharing), které je umožněno dědičností datových struktur a chování mezi několika
podobnými subtřídami bez redundance. To umožňuje opakované užití (reusing) již navržených a
ověřených programů v dalších aplikacích.
4. Spolupůsobení (synergy). Jedinečnost, zatřiditelnost, mnohotvárnost a dědičnost charakterizují
hlavní proud objektově orientovaných jazyků. Každý z těchto aspektů může být izolován, ale
dohromady působí synergicky.
10.3.3 Objektově orientovaná metodologie
Zásadní důležitost je v objektově orientované metodologii (OOM) přisuzována tvorbě abstraktního
esenciálního modelu aplikační domény bez ohledu na možnou implementaci prostřednictvím IT.
47
Odložením implementačních detailů na pozdější fáze návrhu se zajišťuje flexibilita konečného řešení.
Nejdůležitější je tedy způsob abstraktního přemýšlení o problému užitím konceptů reálného světa,
spíše než používání počítačových konceptů. Tím se zásadně odlišuje od všech dosavadních
metodologií, které jsou stále orientovány funkčně a implementačně. V konečné implementační fázi
může být použit jakýkoliv programovací jazyk, a to konvenční nebo databázový. Nejlépe však je užít
jazyk objektový, což ovšem vůbec není podmínkou používání OOM.
OOM je tvořena dále uvedenými etapami (fázemi):
1. Analýza, která začíná definicí problému a sestavením modelu reálného světa, jež zachycuje jeho
vlastnosti důležité pro daný problém. Analytik musí pracovat v těsné součinnosti se zadavatelem
(budoucím uživatelem) tak, aby dobře porozuměl problému, který bývá na začátku obyčejně velmi
nepřesně nebo dokonce nesprávně formulován. Analytický model musí být stručnou, ale přesnou
abstrakcí toho, CO má požadovaný systém dělat, a nikoli JAK to bude dělat. Neměl by tedy
obsahovat žádné implementační koncepty takové, jako jsou např. datové struktury, algoritmy
apod. Dobrý model musí být srozumitelný konečnému uživateli, který není specialistou v IT.
2. Systémový návrh, který definuje celkovou architekturu systému, tj. jeho členění na
subsystémy. V průběhu návrhu systému musí systémový návrhář optimalizovat výkonové
charakteristiky systému, stanovit strategii jejich dosažení a způsob rozvržení dostupných zdrojů.
3. Objektový návrh, který je založen na analytickém modelu, ale obsahuje již implementační
detaily. Návrhář přidá detaily v souhlase se strategií systémového návrhu. Jak objekty z aplikační
domény, tak objekty z počítačové domény jsou popisovány užitím stejných objektově
orientovaných konceptů a notací, přestože existují v různých koncepčních rovinách.
4. Implementace, ve které se transformují do konečné podoby programového jazyka všechny třídy
objektů a jejich relace specifikované v předchozích fázích. Programování je relativně méně
důležitá a více mechanická záležitost vývojového cyklu. Jestliže je náš objektový model
„správný“, bude automaticky „správný“ i systém z něho vzniklý.
Další rozšíření připravila RNDr. Daniela Szturcová, Ph.D.
10.3.4 The Unified Process (UP)
The Unified Software Development Process is an industry standard software engineering process
It is commonly referred to as the "Unified Process" or UP
It is the generic process for the UML
It is free - described in "The Unified Software Development Process", ISBN:0201571692"
UP is:
Use case (requirements) driven (požadavky / případové studie)
Risk driven (řízení rizika)
Architecture centric (ústředním konceptem je architektura)
Iterative and incremental (je iterační a přírůstková)
UP is a generic software engineering process. It has to be customised (instantiated) for your project
In house standards, document templates, tools, databases, lifecycle modifications, …
Rational Unified Process (RUP) is an instantiation of UP (RUP jako varianta, instance UP)
RUP is a product marketed and owned by Rational Corporation
RUP also has to be instantiated for your project
UP history
48
Obr. 8 Vývoj UP
Iterations
Iterations are the key to the UP
Each iteration is like a mini-project including:
Planning
Analysis and design
Implementation
Integration and test
An internal or external release (předání)
We arrive at a final product release through a sequence of iterations
Iterations can overlap - this allows parallel development and flexible working in large teams
Requires careful planning
Iterations are organised into phases
Iteration workflows
Each iteration may contain all of the core workflows but with a different emphasis depending on
where the iteration is in the lifecycle.
Obr. 9 Iteration workflow
Baselines and increments
Each iteration generates a baseline
49
A baseline is a set of reviewed and approved artefacts that:
Provide an agreed basis for further review and development
Can be changed only through formal procedures such as configuration and change
management
An increment is the difference between the baseline generated by one iteration and the
baseline generated by the next iteration
This is why the UP is called “iterative and incremental”
UP Structure
Obr. 10 Struktura UP
Each phase can include several iterations
The exact number of iterations per phase depends on the size of the project! e.g. one
iteration per phase for small projects
Each phase concludes with a major milestone
Phases and Workflows
4fáze – Záměr (Inception), Vypracování (elaboration), Konstrukce (Construction), Předání
(Transition)
This figure is the key to understanding UP!
For each phase we will consider:
The focus in terms of the core workflows
The goal for the phase
The milestone at the end of the phase
50
Obr. 11 Phases and Workflows (význam jednotlivých typů činností (WF) v jednotlivých etapách)
Inception
Obr. 12 Inception
R – definice business případů a rozsahu, zachycení uživ. Požadavků
A – ověřování proveditelnosti (feasibility study)
D – definování proof of concept, prototypu
I – výstavba proof of concept
Cíle – ověřit proveditelnost, vytvořit business případy …
Inception – milestone
Life Cycle Objectives - conditions of satisfaction:
51
System scope has been defined
Key requirements for the system have been captured. These have been defined and
agreed with the stakeholders
An architectural vision exists. This is just a sketch at this stage
A Risk Assessment
A Business Case
Project feasibility is confirmed
The stakeholders agree on the objectives of the project
Elaboration
Obr. 13 Elaboration
R – úprava rozsahu systému a požadavků
A – hlavní analýza – pospat co je potřeba postavit
D – založit stabilní architekturu
I –dtto
T- test architektury
Elaboration – milestone
Lifecycle Architecture - conditions of satisfaction:
A resilient, robust executable architectural baseline has been created
The Risk Assessment has been updated
A project plan has been created to enable a realistic bid to be formulated
The business case has been verified against the plan
The stakeholders agree to continue
Construction
52
Obr. 14 Construction
Construction – milestone
Initial Operational Capability - conditions of satisfaction:
The product is ready for beta testing in the user environment
Transition
53
Obr. 15 Transition
Transition – milestone
Product Release - conditions of satisfaction:
Beta testing, acceptance testing and defect repair are finished
The product is released into the user community
Architecture
"The organisational structure of a software system"
UML specification & IEEE Std. 610.12-1990
RUP has a 4+1 view of architecture
Obr. 16 Architecture
Summary
UP is a risk and use case driven, architecture centric, iterative and incremental software
development process
UP has four phases:
Inception
Elaboration
Construction
Transition
Each iteration has five core workflows:
Requirements
Analysis
Design
Implementation
Test
Architecture
10.4 Rapid development metody
54
Základní informace připravila RNDr. Daniela Szturcová, Ph.D.
Typy metod:
Extrémní programování (XP)
SCRUM Development Process
Test Driven Development
Crystal
Agile Modeling
Agile Unified Process (AUP)
přístup
"Agilní" přístup je založený na pravidelném kontaktu se zákazníkem a iterativním vývoji.
Obr. 17 Martinásek, P: Změna metodiky řízení SW projektů, bc práce VŠB - TUO
2001 – The Agile Manifesto
Definované přednosti (rozdíl proti tradičním metodikám):
Individualita a interakce před procesy a nástroji.
Fungující software před obsáhlou dokumentací.
Spolupráce se zákazníkem před sjednáváním smluv. (může být nebezpečné)
Reakce na změnu před plněním plánu. (může být nebezpečné)
Extrémní programování (XP)
XP určuje pouze čtyři základní činnosti:
Testování – testuje se pořád, před i po integrování modulu.
Psaní zdrojového kódu.
Naslouchání – Vývojáři musí naslouchat klientům, ale i kolegům.
Navrhování – Děje se pravidelně jako u předchozích činností. Dbá se na neustálé navrhování,
jak systém zjednodušit a uspořádat modely tak, aby se při opravě jedné části se nemusely
opravovat ostatní.
SCRUM
55
Obr. 18 SCRUM (http://www.mautilus.cz/jak_vyvijime_software.html)
Základem Scrumu je Sprint - periodická činnost (s periodou obvykle 2-3 týdny), která je neustále
kontrolována (každých 48 hodin). Vstupními parametry Sprintu jsou tzv. Backlog itemy (seznam
návrhů na vylepšení stávajícího produktu, příp. chyby) a výstupním parametrem je Produkt s novou
funkcionalitou, příp. bez zjištěných chyb (UVT MU, 2015).
(UVT MU, 2015)
56
Role účastníků celého procesu se dělí do dvou skupin: Kuřata a Prasata (pojmenování vychází z
následující "anekdoty"). (UVT MU, 2015)
Ne díky. Já bych se přidal, ale pokud jen ty se zúčastníš…
Kuřata - osoby, kterých se problém 'pouze týká', tzv. Stakeholders, tj. uživatelé produktu, manažeři
společnosti, která produkty vytváří,... (UVT MU, 2015)
Prasata - osoby, přímo souvisící s vývojem produktu (UVT MU, 2015):
Product Owner - osoba zodpovědná za výsledný produkt, přiřazuje priority jednotlivým
backlog itemům (vytváří Selected Backlog)
Scrum Master - osoba, jejíž úkolem je zajistit hladký průběh sprintu, organizovat schůzky,
řešit případné administrativní problémy
Team - programátoři
Důležitým prvkem zajišťujícím funkčnost celého procesu jsou pravidelné schůzky. Sprint zahajuje tzv.
Planning, jehož výsledkem je podrobné rozplánování vybraných backlog itemů, včetně časových
odhadů (UVT MU, 2015).
Každé 2 dny probíhá tzv. Stand-up - max. 15 minutová schůzka teamu, na které jednotliví členové
shrnou co udělali od posledního Stand-upu, co udělají do následujícího a co je zdržuje v práci. Scrum
Master tak má možnost sledovat, zda se naplánované odhady shodují s realitou a při případných
nestíháních (podhodnocený odhad, výskyt nečekaných problémů) přesunout itemy do dalšího sprintu
(UVT MU, 2015).
Sprint zakončuje Review, na kterém je funkčnost nového produktu předvedena všem - kuřatům i
prasatům. Po ukončení proběhne Retrospektiva sprintu, kde se kriticky zhodnotí jeho průběh a padnou
návrhy na vylepšení (UVT MU, 2015).
Zdroje
http://www.agilemanifesto.org/
Martinásek, P: Změna metodiky řízení SW projektů, bc práce VŠB – TUO
(UVT MU, 2015) Ústav výpočetní techniky MU, 2015:
http://www.muni.cz/ics/925600/web/scrum
57
11Rozdělení informačních systémů - podle funkce a
postavení v organizaci
IS lze členit podle řady hledisek, podle různých kritérií (Pokorný 1988). Je možné rozlišit IS
podle informačního prostředí, tj. podle daného světa objektů. Existuje-li v reálném světě
více podobných informačních prostředí, je možné, že bude existovat několik podobných IS.
Tento jev vede často ke vzniku tzv. typových projektů, které jsou na úrovni např.
softwarového řešení prázdné, avšak je možné je použít pro vznik IS ve stejných informačních
prostředích, třeba jen jednoho typu. Příkladem může být IS „Knihovna“ nebo „Lékárna“.
IS můžeme také rozlišit také podle organizační úrovně řízení. Může se zde uplatnit
hierarchické řízení, ale i vertikální členění organizací (Pokorný 1988).
Důležité klasifikační hledisko představuje převládající funkce, kterou plní IS. Lze tak rozlišit
(Pokorný 1988):
1) dokumentografické (Storage and Information Retrieval Systems)
2) faktografické (Information Management Systems)
3) měřící, regulační (používané v IS řízení technologických procesů).
Za povšimnutí stojí i jeden zajímavý důsledek historického vývoje prvních dvou tříd IS
(Pokorný 1988). IS typu 1 souvisí s jedním směrem vývoje tzv. (bibliografické) informatiky,
která má u nás hlubší tradici než informatika, která se ve světě rozvíjí jako věda o počítačích.
Současný trend je ovšem takový, že se postupně smazává rozdíl mezi oběma tendencemi
vývoje a směřuje se, zvláště s rozvojem osobních počítačů a zpracováním textových informací
společně s formátovanými údaji, k jednomu pojetí informatiky jako oboru, kde data a
algoritmy tvoří základní pojmy. Faktografické IS jsou v současné době často realizovány
spolu s dokumentografickými v jedné integrované struktuře.
Jako další hledisko při členění IS lze vzít režim činnosti IS (Pokorný 1988):
a) individuální zpracování požadavku
b) dávkové zpracování dat
c) zpracování dat v reálném čase
d) integrované zpracování dat v centralizovaných databázích či v distribuovaném systému
počítačů nebo distribuované bázi dat.
Hledisko úrovně automatizace zohledňuje využití organizační a výpočetní techniky v IS.
Hovoříme pak např. o automatizovaném řízení fondů informací (k tomu přispívají SŘBD), o
automatizovaném sběru dat (např. u řízení technologických procesů), objevuje se i
automatická selekce či indexace vstupních dat (např. u dokumentografických IS), případně i
automatická dokumentace informačních procesů (např. historie akcí prováděných s databází)
(Pokorný 1988).
Obecnější dělení aplikací podnikové informatiky popisuje Gála et al. (2009, s. 124-126):
1. Infrastrukturní aplikace (aplikace pro správu dokumentů, správu webového obsahu, řízení
pracovních toků apod.). Celé komplexy se označují jako ECM (Enterprise Content
Management).
2. Celopodnikové transakční aplikace (ERP). Vytváření rozsáhlých datových bází, realizace
procesů operačního charakteru, vytvářet a prezentovat výstupy.
3. Aplikace řízení externích vztahů
58
Rozdělení informačních systémů - podle funkce a postavení v organizaci
Obr. 19 Informační pyramida (Dohnal, Pour 1997)
Vnitřek pyramidy odpovídá většinou celopodnikovým transakčním aplikacím ve smyslu Gála et al.,
kromě CIS. CIS a EDI odpovídají aplikacím řízení externích vztahů. OIS je možné přiřadit k
infrastrukturním aplikacím.
EIS a DWH je možné chápat jako součást BI. Vztah ale není vyhraněný.
Business Intelligence je chápána jako množina teorií, methodologií, procesů, architektur a technologií,
které transformují primární data na smysluplné a užitečné informatice. BI může pracovat s velkými
objemy imformací s cílem identifikovat nové příležitosti a implementovat efektivní strategie, které
mohou poskytnout konkurenční výhodu a dlouhodobou stabilitu. Making use of new opportunities and
implementing an effective strategy can provide a competitive market advantage and long-term stability
(Rud, Olivia (2009). Business Intelligence Success Factors: Tools for Aligning Your Business in the Global
Economy. Hoboken, N.J: Wiley & Sons. ISBN 978-0-470-39240-9.).
BI technologie poskytuje pohledy na historii, součast i budoucnost obchodních operací. K základním
funkcím patří reportování, OLAP, analýzy, data mining, proces mining, komplexní zpracování
událostí, řízení výkonnosti, benchmarking, text mining, prediktivní a preskriptivní analýzy.
http://en.wikipedia.org/wiki/Business_intelligence
Někdy se chápe BI jako synonym pro konkurenční inteligenci (competitive intelligence). Rozdíl je v
tom, že BI analyzuje především interní data, zatímco CI sbírá a analzuje údaje o konkurenci. Někteří
ale chápou CI jako podmnožinu BI.
59
11.1 Transakční systémy (TPS)
- nástupci klasických dávkových systémů
- úzká oblast působnosti
11.2 Úlohy pro podporu taktického a operativního řízení – MIS (součást ERP)
Cíle a vymezení úlohy:
úlohy pokrývají všechny oblasti řízení organizace (finance, prodej, nákup, …) na taktické a
operativní úrovni s převažující mírou evidenčních a analytických operací (aktualizace datových
bází, zpracování základních přehledů, výběrů atd.),
cílem úloh je zajištění průběžné evidence produkčních procesů a zdrojů podniku, zpracování
požadovaných dokumentů daných legislativou i vnitropodnikovými směrnicemi, zpracování
ekonomických dalších analýz a z podkladů pro rozhodování,
Určení úlohy:
úlohy jsou primárně určeny pracovníkům na střední a nižší úrovni řízení, některé výstupy slouží i
pro řízení na nejvyšší úrovni řízení podniku
přímými uživateli úloh je naprostá většina technicko hospodářských a administrativních
pracovníků podniku,
Technologická základna:
je založena převážně na silných relačních databázích (Oracle, Informix, Sybase, Progress,
DB/400…) a jim odpovídajících počítačích,
ve stále větší míře se uplatňují objektové přístupy k vývoji aplikací a jim odpovídající produkty,
datové báze průměrných podniků představují desítky gigabytů dat,
Projekční postupy:
cesta řešení je často v kombinaci aplikačního software a vývoje specializovaných nebo
strategických funkcí IS/IT zajišťovaného dodavatelsky či vlastními kapacitami. Od toho se
odvíjejí i projekční přístupy,
pro vývoj ASW se používají nejrůznější firemní metodiky (např. metodika LBMS, SDM, SSADM
a další), stejně tak firemní metodiky pro nasazování ASW u zákazníky) SAP, BAAN, … - viz
dále),
pro vývoj aplikačních programových balíků nebo specializovaných úloh se běžně využívá
integrovaných vývojových prostředí a nástrojů CASE (jako např. Excellerator, System Engineer,
CASE 4.0, SDW), a to i pro reengineering stávajících aplikačních programových balíků,
Provozní a organizační nároky:
s ohledem na rozsah aplikací a počet uživatelů vyžadují tyto úlohy z provozního hlediska většinou
největší pozornost – provoz musí být zajišťován prakticky trvale, vysoké nároky na archivaci a
zálohování dat, zajištění bezpečnosti provozu, průkaznost operací) zejména pro finanční a
obchodní moduly),…
Kritické faktory úspěchu úlohy:
výběrové řízení a správná volba aplikačního programového balíku – ASW pro MIS je
nejdůležitější částí celého IS/IT, jeho výběru je ze strany zákazníka věnována daleko vyšší
pozornost než výběru hardware nebo základního software,
správná strategie zavedení MIS do provozu – nejprve je třeba podrobně seznámit uživatele
s možnostmi instalovaného ASW a teprve pak definovat specifické nároky a potřeby úprav ASW
pro MIS,
kvalita použitých metod a nástrojů pro zavedení ASW do provozu podniku,
60
11.3 Úlohy manažerské – typu EIS (často chápáno jako součást Business Intelligence)
Cíle a vymezení úlohy:
úlohy poskytují komplexní analýzy aktivit podniku podle nejrůznějších kritérií, z nejrůznějších
pohledů, a to využitím dat získaných v úlohách typu MIS, CIS apod.
cílem úloh je připravovat podklady pro rozhodování na základě komplexních analýz,
Určení úlohy:
úlohy jsou určeny především pro pracovníky nejvyšších úrovní řízení, stále častěji se však
uplatňují pro operace analytického charakteru i na střední úrovni řízení,
úlohy jsou orientovány na cca 30 – 40% technicko hospodářských a administrativních pracovníků
podniku,
Technologická základna:
úlohy jsou převážně založeny na tzv. multidimenzionálních databázích (viz dále),
pracují v síťovém prostředí, ale velmi často mají individuální charakter (podle potřeb jednotlivých
vedoucích pracovníků),
oproti ostatním typům úloh (MIS, CIS, datové skladby) pracují většinou s menšími rozsahy
databází (desítky až stovky Mb),
Projekční postupy:
vývoj úloh je založen na specifických postupech a metodikách, vyplývajících již z technologické
podstaty těchto úloh (multidimenzionálních databází) a z jejich orientace na převážně analytický
charakter úloh,
obdobně se tyto postupy liší od úloh MIS i při nasazování úlohy do provozu,
Provozní a organizační nároky:
úlohy mají nižší nároky na zajištění provozu s ohledem na menší počet uživatelů a rozsah řešení,
vyžadují však provozní podporu zejména pro konverze dat z databází MIS, CIS apod. do databází
EIS,
s ohledem na jejich individuální charakter vyžadují specifickou konzultační podporu pro uživatele
– vedoucí pracovníky a podporu při průběžných modifikacích aplikací podle okamžitých potřeb
uživatelů,
Kritické faktory úspěchu úlohy:
vědomí skutečné potřeby úloh tohoto typu ve vedení podniku a pochopení jejich principů a
možností,
volba vhodného produktu odpovídajícího potřebám a možnostem většiny vedoucích pracovníků
podniku
kvalita ostatních úloh a databází, z nichž se do EIS čerpají data,
11.4 Úlohy typu datový sklad (DWH) (často chápáno jako součást Business Intelligence)
Cíle a vymezení úlohy:
cílem úloh je shromažďování vybraných informací z různých databází ostatních úloh do
jednotného technologického prostředí a zpracování širokého spektra analýz,
zajišťují zpracování analýz velkého rozsahu nad uloženými daty, a to i za poměrně dlouhá časová
období,
Určení úlohy:
61
úlohy jsou určeny většině vedoucích pracovníků podniku, pracujících s analýzami dat za delší
časová období,
Technologická základna:
založeny na multidimenzionálních databázích, resp. databázích kombinujících multidimenzionální
a relační technologie,
oproti úlohám typu EIS pracují s podstatně větším rozsahem databází, od několika gigabytů až po
terabyty dat,
Projekční postupy:
projekce datových skladů je založena na specifických projekčních přístupech zaměřených
především na analýzy disponibilních datových zdrojů, výběr a konverze dat do datových skladů a
přípravu rozsáhlých ekonomických analýz,
Provozní a organizační nároky:
vyžaduje vytvoření dostatečné diskové kapacity pro datový sklad a kvalitní správu databází
v datovém skladu,
vysoké nároky na monitorování stavu „vstupních“ databází (úloh MIS, CIS, …) a zajištění
zpřístupnění nebo konverzí těchto dat do databází datového skladu,
Kritické faktory úspěchu úlohy:
reálný odhad potřeb podnikových analýz, a to i perspektivních potřeb, spolupráce na formulaci
těchto potřeb s vedením podniku,
vhodný výběr produktů nejen pro vytvoření a správu datového skladu, ale i pro realizaci analýz
(tzv. data mining – viz dále),
11.5 Úlohy elektronické výměny dat – typu EDI (řízení externích vztahů)
Dnes součást B2B – elektronický obchod mezi firmami
A B2C (business to customer) elektronický obchod firma-zákazník
Zajištění interoperability
Cíle a vymezení úlohy:
cílem úloh je zajistit výměnu dat s obchodními partnery, případně dalšími ekonomickými subjekty
v elektronické formě a dosáhnout potřebného zjednodušení a zrychlení obchodních procedur,
v rámci těchto úloh dochází k výměně pevně strukturovaných dat na základě dohodnutých
mezinárodních standardů (objednávek, smluv, faktur, celních deklarací, …)
Určení úlohy:
úlohy jsou zaměřeny na potřeby pracovníků obchodních útvarů, finančních útvarů podniku, kde se
realizují přímé kontakty se zákazníky, dodavateli, finančními ústavy, orgány státní správy,
Technologická základna:
úlohy jsou realizovány pomocí speciálních programových modulů v rámci komplexních
aplikačních software nebo specializovaných programových prostředků. V obou případech jde
zejména o konverze dat (smluv, faktur, …) ze struktur a formátů odesílající aplikace do
dohodnutého mezinárodního standardu a na místě příjmu jde opět o konverzi ze standardu do
formátu přijímající aplikace,
pro přenosy dat jsou většinou využívány veřejné počítačové sítě s přidanou hodnotou ) WAN a
s nimi spojené služby, resp. infrastruktura Internetu,
Projekční postupy:
62
rovněž projekční postupy pro EDI mají specifický charakter daný tím, že v tomto případě se jedná
o projekt pro minimálně dva partnery,
projekty EDI jsou založeny z velké části na aplikaci mezinárodních standardů pro vyjádření
určitých datových struktur a s nimi spojených transformací do, nebo z datových struktur vlastního
aplikačního software (faktura, celní deklarace, …),
Provozní a organizační nároky:
úlohy EDI vyžadují připojení informačního systému do veřejných počítačových sítí a zajištění
přístupu k jejich službám,
musí dojít k sladění odpovídajících provozních pravidel mezi obchodními partnery,
Kritické faktory úspěchu úlohy.
výběr vhodného obchodního partnera nebo partnerů pro realizaci úloh EDI,
ekonomický nebo obchodní tlak na potřebu těchto úloh (např. EDI jako nezbytná podmínka pro
získání zajímavé, dlouhodobé zakázky),
11.6 Úlohy pro podporu kancelářských prací – OIS
Chápáno i jako součást ECM (Enterprise Content Management).
Cíle a vymezení úlohy:
redukce nároků na běžné administrativní operace (psaní textů, běžné kalkulace, …) a zvýšení
úrovně pořádku v administrativě podniku (správa dokumentů, dokumentace předávaných zpráv,
…)
zrychlení a zkvalitnění běžné komunikace mezi pracovníky podniku i s pracovníky externích
organizací – na bázi elektronické pošty,
využití dostupných zdrojů nabízených v prostředí Internetu, (šablony, pravidla)
dosažení vyšší formální úrovně kancelářských prací – formální úrovně dopisů, zpráv, katalogů, …
Určení úlohy:
úlohy typu OIS jsou určeny nejširšímu okruhu pracovníků ze všech typů úloh, prakticky všem
pracovníkům využívajícím počítačovou síť podniku,
s ohledem na rozsah uživatelské sféry se kancelářské aplikace chápou jako páteř celé architektury
informačního systému,
Technologická základna:
úlohy typu OIS jsou založeny na integrovaných kancelářských balících, zahrnujících textové
procesory, tabulkové kalkulátory, elektronickou poštu, grafické editory, pracovní kalendáře a
plánovače, plánovače oběhu dokladů v podniku, příp. další produkty,
Microsoft SharePoint. Document Management Systems.
Projekční postupy:
projekce kancelářských úloh je oproti ostatním typům relativně jednodušší a orientuje se, kromě
výběru, instalace a integrace programových produktů, na vytvoření podnikových standardů pro
určité typy dokumentů (dopisy, zprávy, …), jejich formální úpravy a náležitosti, plánování a řízení
oběhu dokladů, pravidla pro správu dokumentů,
Provozní a organizační nároky:
jedním z klíčových provozních nároků kancelářských aplikací je vytvoření a udržení jednotného
uživatelského prostředí, tj. minimalizace nasazení různých produktů pro tytéž operace, např.
omezení různých textových editorů apod.,
Kritické faktory úspěchu úlohy:
63
kvalita vybraného produktu pro integrovaný kancelářský software,
disciplína pracovníků při dodržování stanovených standardů při tvorbě a využívání dokumentů,
11.7 Systémy pro podporu rozhodování
Někdy se vymezují systémy pro podporu rozhodování (Decision Support Systems – DSS), zpravidla
jako výsledek aplikace MIS. Tyto systémy mají schopnost provádět rozmanité analýzy stejných dat
bez potřeby složitějšího programování, protože požadavky na výstupy jsou často velmi neurčité a
vyjasňují se až v průběhu řešení úlohy. Jedná se většinou o jednorázovou úlohu, která se neopakuje, a
když ano, tak vždy v pozměněných podmínkách, přičemž řešení je obyčejně vyžadováno ve velmi
krátkém čase. Mohou být například prováděny korelace mezi různými daty v MIS, aniž bychom tato
data museli někam přepisovat. Často mají tyto systémy velmi účinnou grafiku, která má pro řídící
pracovníky mnohem vyšší vypovídací schopnost. Mají rovněž prostředky pro analýzu důsledků různě
se měnících podmínek („what – if“ analýzy).
Tam, kde jsou DSS použity nad MIS, slouží k podpoře taktického řízení, mohou však podporovat i
strategické řízení. Potom jsou ale obyčejně použity nad jinými daty, která jsou popsána u systémů pro
vrcholové řízení.
Problémem u DSS je to, že jsou obyčejně založeny na použití osobních počítačů a tzv. personálních
(privátních) databází. Distribuce resp. sdílení dat větším počtem PC je zatím v našich podmínkách
nedostatečná, protože vyžaduje hierarchickou síťovou architekturu technického zabezpečení. Proto se
často tyto systémy používají tak, že si uživatelé sami zadávají data přes klávesnici. Tento způsob je
samozřejmě neefektivní, má velké riziko chyb a doufejme, že je jen dočasný.
V drtivé většině případů jde o používání tabulkových procesorů. Problémem ale je, že výsledky
získané ze spreadsheetu nejsou vždy zaručeně správné, protože řada pracovníků není dostatečně
zkušená v jeho používání.
11.7.1 Ukázka DSS
V rámci projektu TRANSCAT byly následující systémy DSS připravovány pro integraci v rámci
prototypového řešení:
Systém mDSS je jedním z výstupů projektu MULINO (Multisectoral Integrated and Operational
Decision Support System for sustainable use of water resource at the catchment scale), 5.rámcový
program EU. Využívá metodiku DPSIR, doporučenou EEA pro environmentální monitoring a
reporting. Tato metodika popisuje na konceptuální úrovni (potřebné pro pochopení vazeb mezi
jednotlivými faktory ovlivňující rozhodování) – řídící síly (Driving forces), tlaky (Pressure), stavy
(Status), indikátory (Indicators). Jednotlivé aktivity vyvolají příslušné odpovědi (Responses), které
zpětně ovlivňují jednotlivé DPSI ukazatele.
Je nasazován v případech výběru mezi konkrétními opatřeními v povodí. K hodnocení alternativ
používá multikriteriální analýzu (MCA), která je doplněna citlivostní analýzou a analýzou
udržitelnosti režimu řízení. Přiřazené váhy jednotlivým faktorům jsou prověřeny, kombinovány a
následně použity ve výpočtu určitého skóre jednotlivých variant. Přitom je podporováno skupinové
rozhodování. Více informací je na http://siti.feem.it/mulino/index1.htm.
64
Obr. 20 Postup metodiky MULINO při rozhodování (http://siti.feem.it/mulino/index1.htm)
Mediator reprezentuje nástroj pro skupinové rozhodování. Pro zvolený problém je nabízeno několik
variant řešení, u kterých uživatel vyjadřuje svoje preference. Tyto preference jsou následně
agregovány podle sady pravidel. Systém následně ukáže výsledky agregací při aplikaci různých
pravidel a umožňuje iteračním způsobem při vzájemné komunikaci partnerů dospět k cílové variantě
(http://oxygene.ibspan.waw.pl/mediator/cgi-bin/mediator.cgi).
ProDec usnadňuje vytváření rozhodovacích stromů a dovoluje aplikovat fuzzy logiku v jednotlivých
pravidlech.
BarTend představuje jednoduchou aplikaci pro situace, kdy realizaci a naopak nerealizaci jistých
opatření lze finančně hodnotit.
11.8 Expertní systémy
Expertní systémy (ES) jsou často uváděny jako zvláštní kategorie IS. Expertní systémy jsou programové prostředky určené k řešení takových úloh, které jsou považovány za obtížné a jejichž uspokojivé řešení může provést pouze specialista v daném oboru - expert (Vondrák 1994). V zásadě rozdělujeme ES na systémy pracující s bází znalostí a systémy neuronové.
Systémy znalostní jsou podle Molnára () založeny na systému pravidel, který pomáhá ne příliš
zkušenému a znalému pracovníkovi řešit úlohy často diagnostického charakteru. Cílem je poskytnout
znalosti, které má několik málo (případně jen jeden) zkušených pracovníků, více pracovníkům
v podniku. ES používají technologie z oblasti umělé inteligence (Artificial Intelligence – AI). Užití
technologie AI znamená, že znalosti nejsou zabudovány do programu, ale jsou v podobě soustavy
pravidel produkčního typu uloženy samostatně v tzv. bázi znalostí.
Báze znalostí může být realizována jako soustava IF – THEN výrazů, které jsou postupně
vyhodnocovány v průběhu tzv. konzultace s uživatelem. Od něho ES získává informace o stavu
řešeného problému, které nemůže odvodit z vlastní báze znalostí, případně získat dotazem do báze dat
popisujících danou realitu.
65
ES mohou mít značný dopad do podnikového systému řízení. Vidíme, že informační technologie
směřuje k tomu, že vyřazuje odborně méně zdatné pracovníky z pracovního procesu. Je proto třeba
najít takový aplikační systém, který umožní předávat po léta získané znalosti a zkušenosti starších
pracovníků pracovníkům mladším a méně obratným.
Nicméně i zde je zřejmá tendence k integraci TPS s ES. Stejně důležité je i to, že AI aplikovaná v ES
odstraňuje dichotomii mezi daty a programem tím, že se na obě složky IS dívá jako na znalosti. To
skutečně může obohatit technologii tvorby IS.
Neuronové systémy nepoužívají žádnou bázi znalostí.
Trénovací sada dat. Zpětné učení (back propagation). Počet vrstev.
Vysvětlení a příklady jsou uvedeny např. ve Schejbal et al. (2004).
http://geologie.vsb.cz/geoinformatika/kap07.htm
11.9 Strategické informační systémy
U některých firem se prosazuje vnímání IT v podobě tzv. Strategických informačních systémů – SIS,
které musíme odlišovat od EIS určených pro strategická rozhodování. Jsou to aplikace IT, resp.IS,
jejichž cílem je zvýšení konkurenceschopnosti podniku. K tomuto účelu samozřejmě přispívají
všechny ostatní druhy aplikace IT v podniku, protože snižují náklady a zvyšují produktivitu, či
zkvalitňují rozhodování řídících pracovníků. To jsou ovšem všechno aplikace IT, které jsou
orientovány převážně dovnitř podniku, jsou spjaté s jeho systémem řízení a jejich působení je spíše
evoluční. SIS naproti tomu působí převážně v oblasti trhu, tj. v oblasti okolí podniku, a jejich účinek
musí být revoluční. SIS musí významně, tj, řádově změnit efektivnost podniku.
V průmyslové oblasti to bylo především zabudování numerického řízení, resp. programování
výrobních strojů (NC systémy), které změnilo zásadně jejich užitné vlastnosti, dále počítačem
podporovaná konstrukce výrobků a technologická příprava výroby (CAD/CAM systémy), které
výrazně zvyšují konkurenceschopnost výrobků v důsledku zkracování technické přípravy i v důsledku
vyšší možné diverzifikace a zákaznického přizpůsobování výrobků, a v poslední době je to pak
počítačem integrovaná výroba (CIM systémy), která výrazně mění organizaci podniku, snižuje
náklady a zvyšuje kvalitu výrobků.
V obchodní oblasti se jedná především o zavedení elektronické pošty, resp. výměny dokumentů
(Electronic Document Interchange – EDI) mezi zákazníky, tj. jak dodavateli, tak odběrateli, což nejen
výrazně zkracuje časy potřebné na vyřízení různých objednávek, ale vytváří to i určité aliance podniků
napojených na EDI, do kterých mají ostatní podniky obtížnější přístup. Hovoříme o tzv. SIS
kooperativního typu.
11.10 Metainformační systémy
Patří mezi infrastrukturní aplikace ve smyslu Gála et al. (2009).
Podle Molnára (1991) pro řízení projekčních prací, výstavbu i provoz IS i pro potřeby uživatelů je
třeba mít průběžně k dispozici dokonalý a podrobný obraz podnikového IS nejlépe formou
automatizovaného IS nazývaného v této souvislosti metainformační systém, zkráceně METIS. METIS
vzniká již v etapě plánování (analýzy) a je pak dotvářen a průběžně udržován v aktuálním stavu po
celou dobu výstavby a provozu IS. Obsahuje nejen pouhý přehled prvků IS, ale i celou řadu ostatních
informací o podniku, takže je někdy nazýván podnikovou encyklopedií.
Žádná ze současných moderních metod plánování a výstavby IS se neobejde bez nějaké podoby
METIS. Jedním z hlavních efektů počítačem podporovaného projektování IS (CASE) je právě
používání databázově spravované encyklopedie.
Struktura METIS
Základními prvky (objekty) každého METIS by měly být:
- SOUBOR
- ÚDAJ
- ČÍSELNÍK
- DOKLAD
66
- ZPRÁVA
- ÚLOHA
- UŽIVATEL
- PROGRAM
- ORGANIZAČNÍ STRUKTURA
- TECHNICKÉ PROSTŘEDKY
- PRACOVNÍ NÁVODY atd.
Mezi jednotlivými prvky IS existují vzájemné vazby, které musí být také předmětem modelového
zobrazení pomocí METIS. Tak např. určitá úloha je používána určitým uživatelem a je zabezpečována
určitými programy. Ty zase potřebují určité soubory a produkují určité zprávy atd. Schematicky je
možno tyto vzájemné vazby mezi prvky IS vyjádřit maticí v následující tabulce.
Tab. 2 Matice vazeb VAZBY
V METIS
SOUBOR
ÚDAJ
DOKLAD
ZPRÁVA
PROGRAM
UŽIVATEL
ČÍSELNÍK
SOUBOR
ÚDAJ
DOKLAD
ZPRÁVA
PROGRAM
UŽIVATEL
ČÍSELNÍK
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Obsah METIS
Jak již bylo řečeno, je METIS soustava katalogů (souborů) popisujících jednotlivé prvky IS pomocí
jejich atributů a vzájemných vazeb. Abychom odlišili dvojí charakter zpracovaných dat, nazýváme
data zobrazující předmět IS (tj. výrobky, stroje, pracovníky, zakázky apod.) jako objektová data,
zatímco data týkající se informačního systému a jeho fungování nazýváme metadata.
Pokud jde o vlastní obsah jednotlivých katalogových záznamů, neexistuje pro něj žádný předpis,
záleží pouze na našich potřebách a samozřejmě možnostech. Jako ukázku si můžeme uvést přehled
nejdůležitějších atributů, které bychom neměli opomenout:
SOUBOR:
- identifikátor, tj. jméno souboru
- struktura souboru (soupis datových položek – údajů)
- délka věty a počet vět, tj. velikost souboru
- nositel, případně způsob organizace souboru
- soupis programů pracujících se souborem a typ operace
- garant souboru odpovědný za obsahovou správnost atd.
ÚDAJ:
- identifikátor, tj. jméno údaje
- sémantika, tj. popis obsahu údaje
- formát (typ a rozsah)
- doména možných hodnot (číselník)
- užití ve zprávách, dokladech a souborech atd.
PROGRAM:
- jméno, identifikátor
- charakteristika účelu a popis funkce programu
- příslušnost k úloze
- návaznost na jiné programy
- použitý programovací jazyk
- programátor
67
- verze a datum vzniku
- způsob spuštění a obsluhy programu
- vstupní soubory a doklady
- výstupní soubory a zprávy atd.
UŽIVATEL:
- identifikátor funkčního místa
- postavení uživatele v organizační struktuře
- oprávnění k přístupu do souborů
- používané úlohy a programy
- dislokace
- telefonní linka atd.
DOKLAD/ZPRÁVA
- identifikace dokladu/zprávy
- charakteristika dokladu/zprávy
- nositel dokladu/zprávy (papír, obrazovka, disketa)
- uživatel dokladu/zprávy
- účel dokladu/zprávy
- obsah dokladu/zprávy (soupis údajů)
- případné uspořádání (setřídění) zprávy apod.
- periodicita
- počet vyhotovení atd.
68
12Základní požadavky na dodavatele programového
vybavení pro IS Kapitola podle Dohnal, Pour 1997.
12.1 Základní údaje ASW (aplikačního software)
Patří sem charakteristiky ASW vymezující jeho historii na trhu, základní orientaci, vývojářské a
distribuční zázemí, tj. dodavatelské firmy, které vývoj a distribuci aplikačního balíku zajišťují.
12.1.1 Tvůrci, distributoři
Rok zahájení distribuce první verze ASW na trhu:
dokumentuje historii produktu, resp. dobu vývoje, zkušenosti jeho tvůrců,
Rok zahájení distribuce poslední verze ASW na trhu:
určuje na jedné straně ověření poslední verze produktu v praxi, na druhé straně však
dokumentuje i periodicitu uvádění nových verzí na trh,
Tvůrce ASW:
kromě základních informací (název, adresa, kontaktní pracovníci) zahrnuje:
orientaci vývojářské firmy (obor činnosti – obchod, výroba, bankovnictví, …)
charakteristiku, zda firma současně plní funkci systémového integrátora nebo se
soustřeďuje výhradně na vývoj ASW,
personální sílu firmy – počet pracovníků, ev. s dislokací personálních kapacit ve světě,
počet pracovníků určených pouze pro vývoj produktu (analytiků, programátorů, …
počet pracovníků post-implementační podpory, tj. konzultantů, aplikátorů, implementátorů
působících u distributorů a zákazníků,
Distributor:
charakterizuje kvalitu a sílu distributorské firmy, zahrnuje, obdobně jako u tvůrce ASW,
základní kontaktní informace, orientaci firmy, celkový počet pracovníků, počet pracovníků
post-implementační podpory a zejména zaměření a rozsah poskytovaných služeb (projekční,
konzultační, školicí, instalační, …),
Dealeři:
charakterizuje rozsah distribuční sítě a dislokaci poskytovaných služeb.
12.1.2 Základní orientace ASW
Orientace na sektor ekonomiky:
ukazuje na jedné straně úroveň obecnosti ASW (resp. jeho použitelnost v různých sektorech
ekonomiky a využití zkušeností z různých oborů), na druhé straně však při široké obsahové
orientaci i jeho případnou složitost a zvýšené nároky na úpravy pro konkrétního zákazníka,
Orientace na velikost organizace:
orientace na předpokládanou velikost zákazníka, např. podniky podle počtu pracovníků na
velké (nad 600 pracovníků), střední (100-600), malé (pod 100 pracovníků). Z ASW, kterými
se v našem textu zabýváme, se jich většina primárně orientuje na velké a střední zákazníky,
teprve sekundárně na podniky menšího rozsahu,
Cenové charakteristiky:
69
cenové charakteristiky se váží jednak k jednotlivým modulům a současně vyjadřují celkovou
cenovou strategii dané distributorské firmy. Ceny dodávky ASW je často nutné chápat
v komplexu pořizovací ceny základního produktu, ceny za poskytované nové verze (upgrade)
produktu, ceny za údržbu a ceny dalších doprovodných služeb,
cenové strategie se v tomto směru dosti podstatně liší vyšší ceny produktu oproti cenám služeb
a naopak). Liší se i způsob stanovení pořizovací ceny produktu, která je buď relativně
jednoduše vázaná na modul a počet zakoupených licencí a nebo se do této ceny promítají další
faktory, jako např. databázové prostředí na němž má být ASW provozován, technická
konfigurace serverů, resp. celé sítě, rozsah a úroveň dokumentace a další faktory,
Úroveň lokalizace:
úroveň lokalizace vyjadřuje přizpůsobení ASW podmínkám příslušného národního prostředí.
To zahrnuje především:
přizpůsobení ASW po stránce jazykové, tedy překlad do češtiny, slovenštiny apod.
z hlediska jednotlivých komponent dodávky (základní komunikace – datové obrazovky,
nápověda – help, dokumentace, projekce, školení, apod.),
přizpůsobení ASW po stránce legislativní, především ve finančních modulech (účetnictví,
pohledávky, závazky, …) příp. dalších (majetek, doprava), ve funkcích poskytujících
výkazy pro státní správu apod.
je zřejmé, že problém lokalizace se váže především k zahraničním ASW a zejména dosažení
plného souladu ASW s platnou legislativou patří k nejsložitějším problémům spojeným se
vstupem takového ASW na náš trh,
ještě složitější je situace v případech, kdy ASW má být implementován u nadnárodních
společností nebo poboček zahraničních firem působících na trhu, kdy např. výkaznické funkce
musí respektovat dvojí nebo dokonce multiplicitní legislativní nároky (např. účetní výkazy
musí odpovídat jak podmínkám naší legislativy, tak i legislativy států mateřských firem).
12.2 Architektura, skladba modulů
Tato část popisu ASW navazuje na poznámky uvedené v části věnované architekturám v úvodu tohoto
textu.
Celkové schéma architektury:
Architektura aplikačního software sleduje obdobné principy, jako tomu je v případě základního
software. Jde o vyjádření základního schématu, celkové koncepce návrhu a dalšího rozvoje
aplikačního software s respektováním jeho hlavních cílů a požadavků, určující např.:
jaké oblasti informačního systému, resp. řízení podniku ASW pokrývá,
jak jsou jednotlivé moduly mezi sebou provázány, pomocí jakých datových rozhraní
(sdílených databází, dávkových přenosů),
jaké jsou možnosti sestavení výsledného řešení z pouze vybraných modulů aplikačního balíku,
tj. i možnosti samostatného využití dílčích programových modulů,
jak bude řešena otevřenost balíku, tj. možnosti postupného připojení dalších aplikačních
modulů,
jak budou řešeny vazby aplikačního software na základní software, např. s respektováním
možností postupné portace ASW, monitorování provozu (uživatelé, chyby, …)
budou-li do ASW integrovány vlastní, specializované vývojové prostředky a jak,
jak bude řešena on-line dokumentace (help), na bázi centralizovaných /decentralizovaných
slovníků, souborů zpráv, textů nápovědy,
Vymezení základních modulů
u jednotlivých modulů ASW jsou definovány jejich základní charakteristiky:
název a funkční charakteristiky modulu,
technická náročnost modulu, tj. nároky na diskovou kapacitu, nároky na RAM (většinou
však tyto charakteristiky distributoři uvádějí pro aplikační balík jako celek),
70
cenové charakteristiky modulu,
možnosti úpravy modulu,
případná variantní řešení modulu, pokud je modul vytvořen ve více variantách,
datové zdroje nutné pro funkce modulu, s příp. rozlišením na interní (podnikové) zdroje a na
externí datové zdroje (externí databáze specializovaných firem),
Vazby na základní software:
způsob řešení vazeb na produkty základního software (zejména databázové systémy),
výchozí možnosti (dané architekturou) portace a provozování aplikačního software v různých
systémových prostředích,
Místo vlastních a dalších vývojových prostředků:
některé aplikační programové balíky jsou postaveny na vlastních vývojových
a implementačních prostředcích umožňujících efektivní další vývoj ASW a zejména efektivní
implementaci, nasazení ASW u zákazníka,
Vazby na další aplikace:
obdobně jako v případě vazeb na základní software, jsou v rámci této části definovány
principy rozhraní na další aplikační produkty, umožňující otevřenost produktu vzhledem
k doplňování ASW o specializované aplikační produkty (často např. pro potřeby řízení
marketingu, vazby na prostředky pro podporu konstrukčních prací – CAD a další).
12.3 Instalace ASW (reference)
Charakteristiky vztahující se k dosavadním instalacím ASW jsou většinou zákazníky, stojícími před
volbou nového aplikačního software, ty nejžádanější. Podle nich lze odhadovat úspěšnost aplikačního
balíku na trhu, zkušenosti implementačního týmu distributora a lze tak současně získat i kontakty na ty
zákazníky ASW, které jsou předmětu podnikání daného zákazníka nejbližší. ověřování tzv.
referenčních instalací patří mezi nejdůležitější části celého výběrového řízen na ASW, příp. na
systémového integrátora.
Hodnocení počtu a struktury dosavadních instalací ASW se většinou člení především podle
teritoriálního hlediska na:
instalace v České republice,
instalace ve světě
a dále se často sledují instalace ve Slovenské republice, v SRN, ve Velké Británii, v Evropě
celkem, v USA,
je účelné rozlišovat instalace podle počtu a druhu nasazených modulů, tj. komplexní instalace
(nasazeny všechny moduly nebo jejich převážná část) a dílčí instalace (pouze vybrané
moduly).
12.4 Provozní prostředí
Technologická architektura:
vyjadřuje základní technologickou architekturu, na níž je aplikační balík postaven
a provozován, jako např.:
centralizovaná, založená na centrálním počítači a terminálovém provozu, resp. emulaci
terminálů,
client / server, příp. s určením typu této architektury (např. podle klasifikace Partner
Group),
architektura NCC (Network Centric Computing),
jiná speciální architektura.
Databázové prostředí:
71
vymezení databázových systémů, na nichž je aplikační software provozován. Mezi nejčastější
dnes patří Oracle, Informix, Progress, DB2, Sybase, …
do této charakteristiky patří i popisy organizace souborů, pokud je ASW provozován
v souborovém prostředí, např. na indexsekvenčních souborech,
Převažující orientace na základní software:
i když rozhodující z těchto charakteristik jsou použité databázové systémy, zahrnuje tato
charakteristika i vymezení převažující orientace na operační systémy (Unix, Linux, Windows
apod.) a síťová prostředí,
Převažující technická orientace:
většina uváděných aplikačních software a jejich databázových systémů je provozovatelná na
technice většiny světových výrobců počítačů. Tato charakteristika pouze uvádí orientaci
distributora na určitého výrobce hardware, pokud taková orientace existuje nebo je významná,
12.5 Vývojové a uživatelské prostředí
Do této skupiny zahrnujeme charakteristiky programových prostředků použitých pro vývoj
aplikačního software a dále základní charakteristiky uživatelského interface.
Integrované vývojové prostředí, CASE:
podává přehled o použitých prostředcích pro podporu jednotlivých činností spojených
s vývojem ASW, a to pro:
řízení a plánování projekčních a analytických prací,
datovou analýzu, datové modelování, návrh databází
funkční analýzu, návrh funkcí,
řešení prototypů,
generování programů,
vlastní tvorbu programů,
testování jednotlivých komponent ASW a jejich vazeb,
řízení verzí programů,
veškeré dokumentační činnosti,
do této skupiny patří:
prostředky integrovaných vývojových prostředí,
systémy CASE (Computer Aided Software Engineering), jako např. Systém Engineer,
Excelerator, Oracle Case, SDW, CASE 4.0 a další,
specializované prostředky pro plánování a řízení projektů, které mohou být součástí CASE
systémů nebo specializovanými produkty, jako např. Microsoft Project,
některé aplikační softwarové balíky byly vyvíjeny již od počátku s podporou některého
z CASE systémů, v jiných případech byl u již hotových produktů proveden reengineering
s pomocí CASE,
Uživatelské rozhraní:
charakteristiky uživatelského rozhraní určují:
zda je systém postaven na grafickém (GUI) nebo alfanumerickém rozhraní, příp. jejich
kombinaci,
zda jsou podporovány možnosti hypertextové komunikace,
jaká je celková struktura komunikace, struktura menu,
jak je uživateli mapovaná cesta, kterou v menu již prošel,
jak jsou nabízeny hodnoty, např. číselníků, pro jednotlivá vstupní pole,
jak je realizována on-line dokumentace – help (k celé aplikaci, k jednotlivým obrazovkám,
k jednotlivým polím),
72
zda má help kontextový charakter, např. informace je poskytována podle povahy chyby,
resp. nastalé situace,
jaké jsou možnosti racionalizace komunikace, např. přímého volání funkcí (mimo menu
zadáním názvu funkce),
Standardy v uživatelském rozhraní:
úroveň standardizace uživatelského rozhraní a komunikace uživatele s aplikačním software
výrazně ovlivňuje efektivnost práce uživatele a zejména rychlost jeho zaškolení pro práci
s ASW. Svým způsobem i demonstruje úroveň řízení projektu ASW a koordinace a
vývojových týmů,
tato charakteristika pokrývá uplatnění definovaných standardů na jednotlivé dílčí prvky
komunikace (formáty obrazovek, help, …),
do oblasti standardizace uživatelského rozhraní se nejčastěji zahrnuje:
standardní rozvržení formátů obrazovek (záhlaví, event. patičky, struktura datové části
obrazovky, prvotní umístění oken apod.)
standardizace zadávání základních operací – zadání výběrových a třídících podmínek,
standardizace formy výstupních přehledů, tisků apod.,
standardní přiřazení významu jednotlivým funkčním klávesám nebo jejich kombinacím,
standardizace chybových hlášení, včetně použité terminologie,
standardizace struktury a terminologie nápovědy (help).
12.6 Dokumentace a jazykové prostředí
Jazyky:
jazyková charakteristika určuje, v jakých světových a dalších jazycích je aplikační software
využitelný,
počet jazyků je významný zejména pro nadnárodní společnosti, zastoupení zahraničních
společností na našem trhu,
důležitou charakteristikou je přitom i možnost automatického přepínání mezi jazykovými
mutacemi při běžném provozu ASW,
z pohledu jazykových prostředí je nutné posuzovat možnosti využití různých jazyků.
v běžné komunikaci na obrazovkách (menu, popisy datových polí, chybová hlášení),
v nápovědě (help),
v zadávání a zpracování textových dat,
v tištěné dokumentaci,
v souvislosti s předchozí charakteristikou je podstatná i úplnosti překladu, tj. všech částí a
úrovní menu, textů nápovědy apod. (v některých případech jsou např. přeloženy pouze části
nápovědy a ostatní jsou již v angličtině, němčině, apod.)
v současné době podporují světově rozšířené aplikační balíky 10 i více jazyků, v řadě případů
včetně orientálních, japonštiny, čínštiny a dalších,
Dokumentace:
určuje, zda dokumentace vůbec existuje a zde je dostupná zákazníkům,
určuje rozsah a strukturu dokumentace, zejména.
dokumentaci uživatelskou – zahrnující celkovou strukturu a logiku ASW, funkční popis
jednotlivých modulů a návod na jejich obsluhu,
dokumentaci provozní – pro správu ASW, jeho databází, archivační operace, zálohování
apod.
dokumentaci projekční a vývojářskou,
dokumentaci použitých implementačních metodologií, technik, nástrojů pro nasazení
ASW do provozu,
stále častěji se vedle tištěné dokumentace využívají možnosti CD-ROM či web a to může být
další podstatnou charakteristikou.
73
12.7 Doplňující služby
Služby spojené s dodávkou aplikačního balíku jsou významnou součástí jeho posuzování. Jejich
úroveň, rozsah, kvalita je samozřejmě velmi silně závislá na dodavateli (distributorovi, dealerovi) a
může se pro jeden a tentýž ASW výrazně měnit. Na druhé straně je však i závislá na potřebách a
personálních kapacitách zákazníka (síle jeho informatického týmu, potřebě školicích a konzultačních
služeb vzhledem k počtu a kvalifikaci uživatelské sféry).
Údržba a nové verze (upgrade):
údržba aplikačního software zahrnuje zejména jeho úpravy podle legislativních změn a
průběžné úpravy podle potřeba zákazníka,
u nových verzí produktu je podstatná jejich periodicita (většinou se pohybuje v rozmezí ½
roku – 1 rok), finanční náročnost (často je na úrovni 10 – 15% pořizovací ceny aplikačního
software),
v souvislosti s instalacemi nových verzí ASW i realizaci jeho průběžných úprav je podstatné
organizační zvládnutí těchto akcí, tj. zejména informovanost uživatelů o provedených
změnách a instalacích, přesné vymezení oprávnění a zodpovědnosti za formulaci požadavků
na tyto změny (kdo může změny definovat a kdo je schvaluje), úroveň dokumentace změn
apod.,
Služba horké linky:
služba horké linky (hot – line) je dnes běžnou součástí služeb prakticky každého většího
dodavatele v oblasti informačních technologií. Otázkou je pouze její dostupnost, tj. denní
doba, kdy je provozována, zda je k dispozici i o sobotách, nedělích, svátcích apod.,
některé firmy nabízejí i tzv. hot-spot, tedy místo, resp. počítačové kapacity schopné převzít
provoz informačního systému zákazníka v případě havárie, výpadku, přírodní katastrofy,
Projekční služby:
charakteristiky projekčních služeb zahrnují komplex aktivit dodavatele (v kooperaci se
zákazníkem) související s analýzou informačního systému, návrhem úprav ASW, zpracováním
prototypových řešení, customizací modulů, jejich testováním vzájemnou integrací, integrací
na ostatní produkty a další,
z pohledu úrovně projekčních služeb je podstatné:
kdo tyto služby zajišťuje, tj. zda tvůrce ASW, dodavatel ASW, konzultační firma,
jakým způsobem jsou do projekce zapojeni pracovníci zákazníka – uživatelé, analytici,
programátoři,
jaké projekční metodologie a programové nástroje dodavatel pro projekci využívá a jakým
způsobem je zpřístupňuje zákazníkovi,
jaká je časová a ekonomická náročnost projekčních prací, jaká jejich část je zahrnuta do
ceny produktu,
součástí projekce IS/IT, ještě před implementačními postupy, je stále častěji realizován tzv.
BPR „Business Process Re-engineering“, tedy analýza a optimalizace obchodních, výrobních
a dalších procesů zákazníka.
Školící služby:
školící služby jsou rovněž běžnou součástí služeb dodavatele ASW a je pro ně podstatné:
kdo tyto služby zajišťuje – dodavatel ASW, specializovaná školící firma, konzultační
firma, apod.
jaká je struktura školících služeb, tj. školení projekčních metod pro implementační týmy,
uživatelská školení jednotlivých modulů, školení správy aplikací, databází, technická
školení atd.
74
jaký je předpokládaný časový rozsah jednotlivých typů školení projekčních metod pro
implementační týmy, uživatelská školení jednotlivých modulů, školení správy aplikací,
databází, technická školení atd.
jaký je předpokládaný časový rozsah jednotlivých typů školení,
jaká je kapacita školení z hlediska počtu účastníků. Tato charakteristika je velmi
významná u velkých obchodních a průmyslových podniků, bank, rozsáhlých systémů
státní správy, kdy jde o školení až tisíců uživatelů,
jaká je forma školení, úroveň školících materiálů, jazyk školení, technické vybavení
školících prostor,
jaká je ekonomická náročnost školících činností, jaká jejich část je zahrnuta do ceny
produktu,
Konzultační služby:
konzultační služby se většinou primárně váží k funkcím programových modulů ASW a jejich
ovládání a různým provozním aspektům, např. přístupovým právům, archivacím, problémům
doby odezvy apod. Stále častěji se však v souvislosti s inovací informačních systémů a
instalací nových ASW objevují požadavky na konzultační služby v oblasti organizace a řízení,
marketingu, logistiky, řízení výroby a další. Dodavatelé ASW a informačních systémů jsou tak
zcela logicky postaveni před úkol podílet se na komplexním rozvoji řízení firmy zákazníka a
neomezovat svou působnost pouze na čistě informatické aspekty projektů,
Další poskytované služby:
do této kategorie služeb patří např. vzdálené monitorování provozu (např. v případě systému
R/3 tzv. EARLY WATCH), provádění oprav a úprav programů na dálku v terminálovém
provozu, průběžná optimalizace konfigurování systému, databází apod.
12.8 Standardy, certifikace, integrace
Do skupiny Standardů, norem, integrace zahrnujeme ve dvou podskupinách popis toho, jakým
normám, standardům ASW vyhovuje, nebo jaké podporuje a na druhé straně s jakými produkty a
technologiemi může být ASW na bázi standardních rozhraní integrován.
Audit ASW:
audit aplikačního software představuje jeho ověření určitou nezávislou organizací, která má
k tomu oprávnění, že aplikační software je z pohledu funkcí a výstupů v souladu s platnými
právními předpisy. Většinou se audit vztahuje především na moduly, kde má legislativa
zvláštní význam, tj. účetnictví, finanční řízení, různé funkce pro výkaznictví apod.
v případě ASW je důležité rozlišit, zda audit má zahraniční charakter a nebo je realizován i
pro podmínky České republiky,
auditorem ASW jsou proto často svazy účetních, velké konzultační firmy, jako např. Andersen
Consulting, Ernst&Young, Deloitte&Touche, Coopers&Lybrand, KPMG.
Podpora ISO 9000:
normy řady ISO 9000 se nazývají „Normy pro řízení a zabezpečování jakosti“. Jejich obsahem
je definice opatření, která by měl dodavatel produktů a služeb v jednotlivých fázích produkce
zajistit k dosažení požadované kvality. Tato opatření tvoří systém jakosti a jednotlivé normy
řady, tj. ISO 9001, ISO 9002 a ISO 9003, představují různé modely tohoto systému. Systém
jakosti podle norem ISO 9000 především zavádí do firmy pořádek zahrnující přesné stanovení
a dokumentaci pracovních postupů, stanovení pravomocí a odpovědnosti všech aktivit
tvořících součást podnikových procesů, popis uložení materiálů, způsob jejich přejímky,
charakteristiky dodavatelů, charakteristiky výrobních kapacit apod.,
normy ISO 9000 byly vytvořeny na základě zobecnění poznatků nejlepších světových výrobců
a poskytovatelů služeb. Certifikaci firmy podle norem ISO 9000 zajišťují specializované
organizace, které k tomu mají oprávnění. V České republice jsou zastoupeny prakticky
75
všechny významné světové certifikační firmy. Získání certifikátu ISO 9000 má pro firmu
přínos v posílení její konkurenceschopnosti a důvěry zákazníků.
právě s ohledem na posílení své konkurenceschopnosti některé softwarové firmy získaly
certifikaci podle ISO 9000, některé o ni usilují,
na druhé straně je významnou charakteristikou ASW i podpora norem ISO 9000 v nabízeném
aplikačním software, tj. podpora kontrolních činností, vyhodnocování testů výrobků,
dokumentace výrobních procesů, skladovacích prostor apod.
ISO 9000-3
v rámci norem ISO 9000, byla s ohledem na specifický charakter vývoje a nasazování
software zpracována aplikační norma určená speciálně pro softwarové firmy postavená na
zkušenostech největších světových producentů software,
norma ISO 9000-3 je směrnicí pro využití normy ISO 9000 „Systémy jakosti – Model
zabezpečování jakosti při navrhování, vývoji, výrobě, uvádění do provozu a servisu“ v oblasti
software. Charakteristikou aplikačního software je tak i respektování této směrnice,
Ostatní certifikace, ocenění:
do této skupiny charakteristik zahrnujeme další certifikace produktu, event. dodavatele, jako
např. respektování a potvrzení specifických výrobních nebo jiných norem,
v souvislosti s oceněními produktu se uvádí zejména Czech Made, ocenění na veletrzích,
výstavách, v rámci odborných časopisů, sdružení a organizací,
Možnosti vazeb na specializované produkty:
tato charakteristika vyjadřuje realizaci datových rozhraní a integraci ASW na další
programové produkty, např.:
na produkty integrovaných kancelářských systémů – OIS (Office Information System),
jako např. Microsoft Office, Lotus Notes, Uniplex a další,
na produkty EIS (Executive Information System) podporující úlohy pro vedení podniku,
jako např. Commander Comshare, LightShip, Media, PowerPlay a další,
na produkty pro elektronickou výměnu dat – EDI (Electronic Data Interchange),
na produkty pro podporu konstrukčních prací – CAD
u některých z těchto typů produktů (zejména EIS, EDI) může být aplikační software vybaven
speciálními moduly plnícími funkce těchto produktů anebo přes definovaná rozhraní využívat
služeb specializovaných produktů,
Možnosti podpory specializovaných technologií:
nejčastěji se uvádějí možnosti využití čárového kódu, QR kódu, vazby na automatizaci řízení
výrobních linek, automatizaci skladů, osobní magnetické/čipové karty, docházkové lístky
apod.
12.9 Flexibilita
Flexibilitou aplikačního software se rozumí míra jeho pružnosti při jeho přizpůsobování uživatelským
požadavkům před nasazením do provozu a míra jeho pružnosti během provozu. Flexibilita tak výrazně
závisí na počtu a charakteru parametrů, s jejichž pomocí v různých situacích a v různých oblastech
použití lze měnit chování software. Současně je však zřejmé, že s flexibilitou software stoupá i jeho
složitost a nároky na jeho zvládnutí.
76
12.9.1 Možnosti úprav (customizace)
Customizace, resp. úpravy software podle potřeb zákazníka (customer = zákazník), je proces tvořící
jednu z rozhodujících částí celého postupu projektu a nasazení a aplikačního software u zákazníka.
Customizaci předchází většinou rozsáhlá analýza, příprava prototypů a další činnosti.
Předmětem customizace většinou je:
úpravy struktury funkcí a komunikace – struktury menu, potlačení některých voleb, příp.
doplnění dalších funkcí,
nastavení základních předpokládaných (default) hodnot – jazyk, měna, …
definice organizační struktury,
nastavení účetní osnovy,
definice struktury nákladových středisek,
úpravy a naplnění číselníků (materiálů, výrobků, externích partnerů, zemí, měnových
jednotek, …)
úpravy výstupních informací – sestav, zpráv, přehledů,
úpravy funkcí (výpočtů, např. cenových kalkulací, oceňování zásob apod., testů, např. pro
přijetí kontraktů, omezujících podmínek, např. úvěrových limitů, apod.),
úpravy formátů obrazovek – struktura obrazovek, rozmístění polí na obrazovce,
úpravy náplně datových položek a jejich struktury, např. struktury klíčů, dodefinování a
doplnění dalších požadovaných údajů,
přiřazení určité skupiny funkcí v podobě upraveného menu jednotlivým uživatelům nebo
typům uživatelů. Každý uživatel tak má nabízenu pouze svoji strukturu funkcí,
technologické úpravy – standardní nastavení barev, rámečků apod.
Možnosti realizace úprav jsou závisle na použité programátorské technologii. Uveďme alespoň
některé možnosti:
generování aplikace výběrem z nabízených modulů a jejich propojením, sestavením do
funkčního celku,
výběr požadovaných funkcí podle nabídky a jejich trvalé nastavení do uživatelského menu,
definování hodnot parametrů do předem definovaných tabulek, z nichž pak jednotlivé moduly
si vybírají potřebné parametry (koeficienty, testovací hodnot apod.)
přímá úprava parametrů v příkazech volání jednotlivých procedur.
12.9.2 Provozní flexibilita
V případě provozní flexibility jde o možnosti různých variant zpracování úloh a změn v provádění
standardních (již customizovaných) funkcí. Do provozní flexibility se promítá i schopnost zachytit
vlastní i zákaznickou organizační strukturu a na základě jejich monitorování a analýzy upravovat
nastavení systému.
Parametrizace funkcí:
určuje rozsah uživatelsky dostupných parametrů pro úpravy funkci ASW, jejichž některé
možnosti jsou uvedeny v předchozí části,
Generování tiskových výstupů:
představuje běžné funkce spojené s tiskovými generátory – výběr položek, výběrová, třídící a
agregační kritéria, nastavení hlaviček, patiček, písma atd.
Počet paralelně zpracovávaných organizací (mandantů).
určuje kolik různých organizací lze současně provozovat na jednom instalovaném aplikačním
software. Touto samostatně zpracovávanou organizací (podnikem, firmou) se rozumí
mandant,
77
Počet paralelních organizačních struktur:
určuje kolik různých organizačních struktur lze současně provozovat a na jejich základě
realizovat různé prodejní, ekonomické, personální a další analýzy,
Zpracování textových informací:
tato charakteristika je úzce závislá na použitém databázovém systému. Určuje, jak lze
kombinovat běžná „tabulková“ data s textovými daty a na těchto datech realizovat i textové
operace. Určuje rovněž, do jaké míry aplikační software tyto databázové možnosti využívá,
např. pro technické popisy výrobků, dodavatelů, zákazníků, dodacích podmínek apod.
Zpracování grafických informací:
obdobně jako v předchozím případě, jde o integraci grafů, grafických informací a operace na
nich do funkcí poskytovaných aplikačním software, tzn. např. zpracování grafů na základě
číselných hodnot, úpravy grafů s jejich promítnutím do základních hodnot, zpracování
schémat a jejich úpravy atd.
12.10 Funkční možnosti
Jak jsme uvedli na začátku této kapitoly je funkční struktura ASW, tedy „co skutečně aplikační
software umí“ ta nejdůležitější charakteristika a nepřísluší ji poslední paragraf v našem přehledu. Je to
dáno pouze tím, že tato charakteristika je velmi obtížně formalizovatelná a její popis je většinou různě
rozsáhlý a proto v rámci profilu ASW ji ponecháváme závěrečnou část.
Funkce aplikačního software můžeme pracovně rozdělit do těchto skupin, resp. typů funkcí:
a) funkce evidenčního charakteru – zajišťující základní vstupy, kontroly, aktualizace, přehledy
dat, jako např. evidence zákazníků, dodavatelů, zboží, materiálů,
b) funkce operativního charakteru – zajišťující např. zpracování objednávky, nabídky, přípravu
smlouvy, platebního příkazu, celního dokladu, zaúčtování jednotlivých dokladů,
c) funkce analytického charakteru – představuje zpracování nejrůznějších finančních analýz,
prodejních analýz, nákladových analýz, analýz hospodářských středisek,
d) funkce plánovacího charakteru – podporující návrhy plánů výroby, rozvrhů výrobních
zakázek, kapacitních plánů, rozpočtů, personálních plánů,
e) funkce kontrolního charakteru – které jsou většinou založeny na sledování zadaných limitních
hodnot a vyhodnocování stavů databází vůči těmto limitům. V okamžiku vybočení hodnot
mimo tyto meze se spouští procedury, které mohou mít různý charakter, např. hlášení výjimek,
automatická příprava dokladů, např. objednávek materiálu, požadavků na výrobu, zajištění
blokace materiálů na skladech,
f) funkce správního charakteru (administrativní) – monitorující a vyhodnocující vlastní provoz
informačního systému a umožňující nastavovat různé technologické parametry, jako např.
přístupová práva, standardní tiskové parametry.
Toto rozdělení zde uvádíme proto, že při posuzování funkčnosti aplikačního software je účelné si
poskytované funkce obdobným způsobem rozdělit. Funkce evidenční, operativní a správní jsou zhruba
většinou srovnatelné, neboť bez nich by aplikace většinou vůbec nefungovaly (každý musí být
schopen evidovat zákazníky, materiály atd.). Funkční spektra se většinou výrazněji liší u funkcí
analytických plánovacích a kontrolních na ně je účelné se při výběru aplikačního software zaměřit.
78
13Exekutivní informační systémy (Business Intelligence)
13.1 Podstata EIS a jejich místo v architektuře IS/IT
EIS (Executive Information System) jsou úlohy IS/IT specializované na podporu vedení podniků a
institucí. EIS byl původně orientován na podporu nejvyšší úrovně řízení podniků. V současné době
však jsou tyto aplikace stále více orientovány i na střední management, který dnes tvoří již většinu
jejich uživatelů a rovněž na další podnikové specialisty. Toto rozložení dnes tvoří již většinu jejich
uživatelů a rovněž na další podnikové specialisty. V souvislosti s tímto pronikáním EIS i na nižší
stupně řízení se stále častěji zkratka EIS chápe v relativně novém významu, a to jako „Enterprise
Information System“, event. jako BIS – „Business Intelligent System“.
Z průzkumu aplikací EIS ve Velké Británii v roce 1996 vyplývá, že je z přímých uživatelů již pouze
15% ředitelů. Ostatní uživatelé jsou pracovníci střední úrovně řízení a specialisté – profesionálové.
EIS využívá všech dostupných informačních zdrojů vytvářených na nižších úrovních informačního
systému, tj. úlohami transakčního charakteru (TPS – Transaction Processing System), úlohami pro
taktické a operativní řízení (MIS – Management Information System), úlohami pro podporu
rozhodování (DSS – Decision Support System). Úlohy TPS a MIS připravují a aktualizují data pro
řídící aktivity na nejnižší a střední úrovni řízení a mají převážně evidenční charakter. Systémy pro
podporu rozhodování (DSS) představují již podstatně výraznější orientaci na analytické a rozhodovací
algoritmy a v tom jsou obdobné systémům EIS. Rozdíl spočívá především v tom, že DSS primárně
podporují střední úroveň řízení a mají většinou izolovaný charakter (optimalizace výrobních dávek,
dopravních cest atd.). S tím souvisejí i poměrně nižší nároky DSS na integraci různých úloh, datových
zdrojů, pracovních metod, současně i nižší nároky na presentaci a interpretaci informací.
EIS v sobě integruje všechny nejdůležitější datové, procedurální a další zdroje systému, významné pro
řízení organizace jako celku. S tím jsou spojeny i specifické nároky na presentace informací a jejich
zpřístupnění vedoucím pracovníkům firmy. EIS je tak především analytický a presentační nástroj
založený na využití již existujících dat, nikoli nástroj na vstup dat.
Z uvedené pozice EIS v architektuře informačního systému vyplývají jeho hlavní požadované
vlastnosti:
a) EIS zajišťuje výběr a zpracování nejdůležitějších dat ze všech podstatných řídících úloh
(zejména z oblasti finančního a personálního řízení, z oblasti marketingu, obchodu, řízení
výroby, vývoje a výzkumu),
b) EIS poskytuje vlastní prostředky pro modelování analytických a rozhodovacích procesů,
s event. využitím adekvátních exaktních statistických a ekonometrických metod,
c) EIS umožňuje permanentní aktualizaci svých modelů z dostupných interních i externích
datových zdrojů. To znamená, že zajišťuje transformace vybraných a agregovaných dat
z databází IS/IT v předem zadaných časových intervalech nebo podle okamžité potřeby,
d) EIS respektuje nároky na vysokou vypovídací hodnotu výstupů (schopnost kombinace
tabulkových výstupů s doplňujícími texty, grafické a obrazové výstupy apod.)
e) EIS nabízí systematickou strukturalizaci a restrukturalizaci rozhodujících ekonomických a
dalších ukazatelů, a to v takové míře detailu, která je adekvátní konkrétní situaci nebo
problému,
f) EIS zajišťuje identifikaci odchylek a kritických bodů pro jednotlivé oblasti řízení (ve
výkyvech produkce, limitní hodnoty zásob apod.)
13.2 Technologické principy EIS
Základní princip, resp. jádro EIS je několikadimenzionální tabulka (spreadsheetového charakteru)
umožňující velmi rychle a pružně měnit jednotlivé dimenze a měnit tak pohledy uživatele na
modelovanou ekonomickou realitu. jde tak v podstatě o princip „n-dimenzionální Rubikovy kostky“
naplněné nejdůležitějšími podnikovými daty.
Standardními dvěma dimenzemi jsou v EIS ekonomické proměnné (ukazatele) a čas. Ostatní dimenze
(viewpoints) se pro jednotlivé modely definují podle potřeby, např. komodita, zákazník, dodavatel,
79
teritorium, konkurent apod. Obsah dimenzí je tvořen prvky dimenzí (viewpoint member), tj.
konkrétními zákazníky (nebo jejich skupinami), dodavateli, komoditami apod. Promítnutí všech
dimenzí do jednoho bodu tvoří základní prvek modelu (kostky) a tím je prvek modelu. Každý prvek
modelu může pak obsahovat data nebo předpisy (algoritmy) pro jejich transformace představující
základ pro tvorbu jednotlivých modelů. Ke každému prvku modelu je tak možné přiřadit relativně
složitý úsek programu pro výpočet jeho vlastní výsledné hodnoty nebo hodnot jiných prvků.
Je třeba však současně připomenout, že různé produkty používají pro výše uvedené termíny různou
terminologii.
Prvky dimenzí jsou většinou uspořádány v hierarchické struktuře, tzn. že se rozdělují na skupiny
prvků, podskupiny, atd. až na jednotlivé prvky. Produkty EIS pak zajišťují automatické agregace
hodnot (ekonomických proměnných) podle hierarchických úrovní dimenzí. Jednoduchými příklady
takových struktur může být dimenze „teritoria“, nebo dimenze „organizační struktura“. Úloha EIS pak
bude automaticky sledovat např. hodnoty výroby, prodejů zboží, zásob, zisku apod. podle uvedené
struktury teritorií, podle organizační struktury a zajišťovat příslušné agregace a další výpočty
(ukazatele finančních analýz, různé statistické ukazatele apod.).
Obdobně se definují struktury zákazníků, dodavatelů, obchodních divizí, obchodních zástupců,
komodit a dalších.
Podstatnými vlastnostmi EIS z aplikačního hlediska je to, že umožňují velmi rychle a pružně
doplňovat a měnit zobrazení dat podle jednotlivých dimenzí a měnit tak pohledy uživatele na
modelovanou ekonomickou realitu.
Kromě toho umožňují tzv. „drill-down“, tzn. že uživatel může získávat hodnoty v požadované úrovni
detailu, resp. pohybovat se na úrovních detailu podle potřeby. Např. hodnoty výroby za závody se
zobrazí v rozdělení odpovídajících provozů, z hodnot prodeje za světadíly můžeme postupně získávat
hodnoty za jednotlivé státy, apod.
13.3 OLAP Technologie
Až dosud jsme se zabývali jedním z nejpodstatnějších technologických rysů současných EIS –
multidimenzionalitou. Z tohoto pohledu definoval E. F. Codd 12 pravidel (včetně uvedené
multidimenzionality) pro hodnocení tzv. OLAP (On –Line Analytical Processing) produktů, které jsou
základem prostředků i projektů EIS. Tato pravidla byla pak dle tzv. „OLAP New Report“
restrukturalizována, upravena a doplněna na současných 18 pravidel. V dalším přehledu uvádíme nové
definice s tím že u názvu pravidla je v závorce doplněno číslo původního pravidla, příp. „nové“
představuje nová pravidla. Ke každému pravidlu doplníme vždy v několika bodech jeho stručnou
charakteristiku.
B – Základní vlastnosti
1. Multidimenzionální koncept uložení a manipulace s daty (1):
realizuje uložení dat v kombinaci různých definovaných dimenzí,
multidimenzionální konceptuální schéma usnadňuje analýzu a návrh jednotlivých modelů,
definování výpočtů uvnitř dimenzí i mezi dimenzemi,
umožňuje uživateli různé pohledy na data podle dimenzí (řezů) a podle potřeby je dynamicky
měnit,
umožňuje interdimenzionální a intradimenzionální výpočty,
2. Intuitivní manipulace s daty (10):
předpokládá grafické rozhraní aplikací,
možnosti drill down (pohyb ve směru vyššího detailu hodnot a zpět) se vyvolává přímo na
datových prvcích a nikoli přes menu nebo jinými cestami,
3. Dostupnost OLAP jako Mediator (3)
poskytuje možnost získávat data z heterogenních datových zdrojů,
80
OLAP nástroje si musí mapovat stav uložení dat, přístupu k nim a zajistit příslušné konverze do
vlastní datové báze,
4. Dávkové výběry vers. interpret (nové):
produkty musí nabízet jak jejich vlastní databázi pro OLAP tak přímý přístup do externích dat,
5. Analytické modely OLAP (nové):
musí podporovat všechny známé typy analytických modelů, parametrizované statické přehledy,
členění hodnot (slicing – diving), „what if“ analýzy, specifikace cílů (goal seeking),
6. Klient/server architektura (5):
server OLAP nástrojů musí být dostatečně vybaven pro připojení různých klientů s minimálním
úsilím a programátorskými nároky,
7. Transparentnost (2):
OLAP nástroje musí být schopné integrace s jinými nástroji, aniž by ohrozily funkčnost
hostitelského prostředku. Uživatel tak může přistupovat k databázi pomocí nástrojů, na které je
zvyklý,
OLAP nástroje musí uživateli zajistit potřebnou úroveň funkcí, aniž by zvýšily složitost jejich
užití,
vnitřní organizace dat musí být uživateli transparentní,
8. Podpora multiuživatelského provozu (8):
OLAP nástroje musí podporovat zajištění paralelního přístupu, integrity a bezpečnosti provozu
v multiuživatelském provozu,
S – Speciální vlastnosti:
9. Zpracování nenormalizovaných dat (nové):
musí být zajištěna integrace dat v OLAP prostředí a nenormalizovaných zdrojových dat,
10. Uložení výsledků OLAP, jejich uchování mimo zdrojová data (nové):
aplikace OLAP read/write by neměly být implementovány přímo na živých transakčních datech a
změny dat v OLAPu by neměly být uchovány odděleně od transakčních dat,
11. Oddělení (extrakce) chybějících hodnot (nové):
chybějící hodnoty musí být odlišeny od nulových hodnot,
12. Zpracování chybějících hodnot:
všechny chybějící hodnoty musí být ignorovány OLAP analyzátory bez ohledu na jejich zdroj
(vztahuje se k pravidlu 11),
R – Report (přehledové) vlastnosti:
13. Flexibilní poskytování výstupů (11):
OLAP nástroje musí umožňovat snadné úpravy výstupů, jejich kombinace podle okamžitých
potřeb uživatele,
musí rovněž poskytovat zobrazení dat podle definovaných dimenzí a jejich snadné redefinice,
14. Konsistentní (konstantní) výkon na výstupech (4):
výkon OLAP produktů by neměl být ovlivněn počtem, resp. nárůstem definovaných dimenzí
i při narůstajícím počtu dimenzí nebo velikosti databází musí být zachována snadnost použití,
15. Dynamická manipulace s řídkými maticemi (7):
OLAP nástroje musí zajistit efektivní zobrazení a manipulace s nulovými nebo prázdnými
hodnotami v maticích,
81
přístupové metody musí být dynamicky měnitelné a měly by zahrnovat různé přístupové
mechanismy (přímé výpočty, B-stromy, …)
D – Řízení dimenzí:
16. Generická dimenzionalita (6):
dodatečně přidávané funkce musí být zajištěny pro jakoukoliv dimenzi,
17. Neomezený počet dimenzí a agregačních úrovní (12):
počet dimenzí pro model by neměl být limitován,
18. Neomezené cross-dimenzionální operace (9):
operace s daty mezi jednotlivými dimenzemi nemohou být omezeny počtem dimenzí.
Uvedená pravidla OLAP splňují jednotlivé produkty v různé míře a jejich hodnocení musí být součástí
výběrového řízení EIS.
82
14Datové sklady (Business Intelligence)
14.1 základní principy Data Warehousingu
Nejrůznější studie ukazují, že objem dat v podniku nebo organizaci se zdvojnásobí každých pět let.
Většina firem tak nemá problém s nedostatkem dat, ale naopak se zahlcením redundantními a
nekonsistentními daty, které jsou nakonec obtížně využitelné v rozhodovacích procesech. To vyvolalo
potřebu takových nástrojů, které by umožňovaly transformaci těchto obrovských objemů dat do
přijatelné a zejména využitelné formy.
Základní koncept datového skladu je definován jako integrovaný a konzistentní systém pro
poskytování informací pro podporu rozhodování. Jde tak o proces, v němž organizace extrahují ze
svých informačních zdrojů takové informace, které mají zásadní význam pro úspěšné řízení firmy.
Datové sklady řeší některé stávající překážky současných informačních systémů z hlediska potřeba
analytických úloh. Mezi tyto problémy patří např.:
data potřebná pro komplexní rozhodovací aktivity jsou většinou rozptýlena v různých
aplikacích a jejich konzistence je tak často problematická,
základní, transakční systémy jsou z hlediska doby odezvy ve složitějších analytických úlohách
obvykle nevyhovující. Návrh databází pro transakční úlohy je optimalizován na jiný typ
činností,
transakční systémy nevyužívají většinou nástroje pro analýzy časových řad, příp. další
analytické operace, neboť jsou primárně koncipovány pro jiný druh úloh.
Jaký je způsob řešení uvedených problémů na bázi datového skladu? Rozlišuje zde úroveň
uživatelských (business) potřeb a vývojových (development) potřeb. Na úrovni vývojových potřeb jde
o vytváření, správu a údržbu datového skladu. Na úrovni uživatelských potřeb jde o různé možnosti
přístupu k datům a jejich vyhodnocení.
Základní koncept datového skladu formuloval koncem 80. let William Inmon, a to jako strategii
přístupu k datům. Inmon a Hackthorn pak definují datový sklad jako databázi, která je organizovaná
tak, aby sloužila jako neutrální datový prostor. Je využívána pomocí data mining a dalšími aplikacemi
a využívá data, která odpovídají předem definovanému souboru podnikových kritérií. Pro datové
sklady jsou podle Inmona charakteristické tyto vlastnosti:
data jsou předmětně organizovaná, podle zájmů manažerů,
je dosažena vysoká integrace a hamonizace dat,
aktualizace neprobíhá ihned, ale po dávkách,
uplatňuje se výrazný vliv časového faktoru, sekvence časových snímků o podniku, důraz na
časové řady,
zpracovávají se velké objemy dat – GB až TB.
Technologickým základem datových skladů (obdobně jako u produktů EIS) je technologie OLAP (On
Line Analytical Processing) v kombinaci s tzv. relačním OLAPem (R-OLAP). Umožňuje i zde
definovat nejrůznější dimenze (pohledy) na ekonomická data a ty pak s pomocí programových
nástrojů datového skladu analyzovat. na rozdíl od standardní OLAP technologie je technologie R-
OLAP (Relational OLAP) založena na relačních databankách s možnostmi přístupu k datům pomocí
SQL a s celou řadou různých optimalizačních technik, jako např. denormalizace, indexování,
faktografických, relačních a prohledávacích tabulek (Fact Tables, Relational Tables. Look-up Tables).
Databáze datových skladů jsou navíc koncipovány jako tzv. WORM/DN (Write Once Read Many /
Delete Never), tzn. že datové sklady jsou určeny pro analýzy a nikoli transakční operace.
Datové sklady se často používají pro spojení dat pocházejících z různých systémů za účelem vytvoření
smysluplných, konzistentních a pravidelně aktualizovaných skupin informací, které lze použít pro
proces rozhodování. Většina odborníků nenahlíží na sklady dat jako na produkt, či jeden systém, ale
83
jako na proces, který je třeba realizovat i v případě jedné OLAP aplikace, která čerpá data z více
systémů.
Formální datové sklady nabývají podobu velkých relačních databází, konvenčních výstupů
a dotazovacích nástrojů, které lze použít přímo s těmito databázemi. Relační databáze byly pro denní
provoz vybrány především pro svoji schopnost zpracovávat velké objemy dat a ukládat podrobné
informace, které nemají multidimenzionální strukturu.
Při procesu rozhodování má multidimenzionální obraz organizace mnohem větší vypovídající
schopnost než informace podané ve formě seznamu, který odpovídá filozofii systémů transakčního
zpracování.
To vše vedlo k tomu, že trh velmi rychle akceptoval specializované OLAP nástroje, které spolupracují
se zdrojovými databázemi, a datová skladiště, která odpovídajícím způsobem umožňují spravovat
velké objemy dat a poskytují pružnou multidimenzionální analýzu s uživatelsky přátelským
rozhraním.
Podstatnou součástí celého systému datového skladu je tzv. datová pumpa. Jde o komplex
programových komponent zajišťujících transfer dat z produkčních databází do datového skladu.
Datová pumpa (ETL) zajišťuje takové funkce jako selekci a extrakci dat, transformaci,
restrukturalizaci, agregaci a konsolidaci dat. Datová pumpa zajišťuje i výchozí vytváření
požadovaných časových řad.
V souvislosti s technologií OLAP se často datové sklady dávají do souvislosti s úlohami EIS.
Zdůrazněme alespoň hlavní rozdíly:
v některých případech nepostačuje pouze EIS, a to zejména při značných objemech analyzovaných
dat, při požadavcích na složité a rozsáhlé analýzy,
datové sklady lépe zajišťují konsistenci a konsolidaci vstupních dat z produkčních databází,
datové sklady přispívají k řešení nejednotností dat mezi jednotlivými odděleními podniku,
datové sklady poskytují možnosti realizovat analýzy ve více vrstvách detailu,
datové sklady zahrnují podporu data mining (viz dále).
14.2 Data Warehouse a Data Mart
Základní otázkou před zahájením projektu datových skladů je, jak efektivně úlohu realizovat
a dosáhnout co nejdříve očekávaných efektů. Jednou z cest jak dosáhnout těchto efektů v relativně
krátké době je technologie tzv. data mart. Jde o implementaci menších datových skladů na úrovni
jednotlivých oddělení nebo pracovních skupin. Tento přístup umožňuje rychlejší start celého řešení
projektu, snížení prvotních nákladů. Navíc poskytuje možnost postupného rozšiřování kapacity
datového skladu jak v celkovém objemu dat, tak v počtu aplikací těchto dílčích skladů. Jejich
postupnou integrací pak může vzniknout celopodnikový datový sklad.
Běžný princip navrhování datových skladů odpovídá přístupu shora-dolů s respektováním potřeb celé
organizace. Takový komplexní přístup má evidentní celosystémové výhody, ale na druhé straně
obtížně reaguje na rychlé a dynamicky s měnící potřeby managerů na informace analytického
charakteru, jak je dnes v praxi běžné. Data mart reaguje na tyto problémy schopností podstatně
rychlejší implementace a vyšší pružností vzhledem ke změnám v datových zdrojích i potřebách
uživatelů.
Jedním z produktů podporujících tuto technologii „dílčích“ datových skladů je IBM Visual
Warehouse. Podporuje všechny běžné činnosti spojené s implementací datového skladu. Je schopen
vybírat a transformovat data ze širokého spektra vysoce heterogenních interních i externích datových
zdrojů. Jeho jádrem je integrované „repositury“ metadat, které zajišťuje správu systému, popisy dat a
řídící informace pro standardní operace. Pro každý datový zdroj, který má být pro datový sklad
zpřístupněn, se v repositury uvádí jeho obsah a umístění. Takto vytvořená metadata jsou pak
využívána pro mapování, výběry, filtrování a transformace datových zdrojů do datového skladu.
Vlastní data jsou uložena do datového skladu ve formě tzv. „business views“, což jsou obrazy dat,
které se již váží k jednotlivým definovaným obchodním procesům. Tyto „business views“ jsou
uloženy rovněž v repositury a jejich hlavním účelem je zjednodušit komunikaci uživatele s datovým
skladem pro standardní aplikace a potřeby. Kromě toho, řídící informace uložené v repositury
84
umožňují automatizovat i provozní a správní procesy datového skladu, např. mohou obsahovat přesný
časový harmonogram obnovy dat různých částí datového skladu z primárních datových zdrojů a
požadované transformační rutiny spouštět automaticky (to je obdobné jako u současných EIS
produktů).
Jak jsem se již zmínili, jsou aplikace na bázi data mart rozšiřovatelé, „škálovatelné“ podle rostoucích
potřeb uživatele. Podstatnou vlastností těchto produktů je však zejména jejich následná vzájemná
integrace do celopodnikového datového skladu, teda možnost efektivní kombinace rychlejší
implementace dílčích řešení s jejich postupnou integrací. Tyto možnosti vyplývají z celkové
architektury těchto produktů (viz obrázek), založené na plně distribuované klient/server technologii.
Ta poskytuje přístup k nejrůznějším technologickým platformám a vysokou flexibilitu funkcí.
Zahrnuje tyto hlavní komponenty:
manager,
řídící databáze,
klienty pro administraci,
agenty pro přístup k datovým zdrojům.
Manager zajišťuje řízení procesů datového skladu, jako např. kooperaci jeho jednotlivých komponent,
monitorování, automatizaci a rozvrhování procesů zajišťovaných datovým skladem a řízení aktivit
vykonávaných jednotlivými agenty. Řídící databáze obsahuje řídící informace – metadata „business
views“, provozní protokoly harmonogramy, resp. plánovače funkcí datového skladu. Tato řídící data
jsou pak využívána jednotlivými agenty.
Agenti zajišťují přístup k jednotlivým datovým zdrojům, tzn. filtrování dat, jejich transformace a
přenos do databází datového skladu. Znamená to, že agenti musí být schopni pracovat nad vysoce
heterogenními databázovými systémy v různém technologickém prostředí. Využívají k tomu primárně
ODBC driverů. Počet agentů není omezen a jejich skutečná potřeba pouze závisí na různorodosti
provozního prostředí a potřebách organizace. Klienti pro administraci zajišťují vazbu na funkce
datového skladu, tj. definování „business views“, definování databází v datovém skladu, registraci
zdrojů, určování harmonogramu obnovy databází v datovém skladu, zajišťování bezpečnostních
funkcí. Klient na základě takto definovaných pravidel a řídících informací již vytváří a spouští
jednotlivé prováděcí rutiny.
Reportování.
Řešení datového skladu na základě dílčích datových skladů a jejich postupné integrace, tak má své
opodstatněné výhody, které by měli projektanti těchto aplikací již v etapě specifikace projektu brát
v úvahu.
14.3 Data Mining
Data mining („dolování dat“) lze obecně charakterizovat jako proces extrakce relevantních, předem
neznámých nebo nedefinovaných informací z velmi rozsáhlých databází. Pro podporu data mining
existuje již řada produktů. Umožňují identifikovat skryté korelace, analýzy vazeb ve velkých
objemech dat, vytvářet modely pro predikci různých situací a procesů apod. Jde především o tzv.
„data-driven“ analýzy, tj. analýzy odvozované z obsahu dat, nikoli předem specifikované uživatelem
nebo implementátorem.
Data mining je postaven na několika technikách, k nimž uvedeme jejich stručnou charakteristiku:
clustering – znamená rozdělení databází, takže záznamy jsou seskupovány podle obdobných
charakteristik (např. objemů prodeje, komodit, lokalit apod.),
klasifikace – vytváří profily každé skupiny objektů definováním podstatných atributů těchto
objektů,
predikce – odhaluje závislosti hodnot jednoho atributu na hodnotách ostatních atributů v tomtéž
záznamu a predikuje specifické hodnoty atributu pro nové záznamy,
asociace – odhaluje veškeré asociace mezi transakcemi, tj. odvozuje z hodnot jedné transakce
možnosti jejich výskytu v jiných transakcích,
85
odhalování sekvenčních vzorů – nachází obdobné vzory v transakcích odvozováním z podobností
logiky posloupností jejich operací nebo položek,
odhalování obdobných časových sekvencí – nachází obdobné časové sekvence činností nebo
procesů zaznamenaných v databázích.
Data mining je ve vazbě s datovými sklady významným analytickým nástrojem integrujícím v sobě
možnosti rozsáhlých databází a jejich zpracování na bázi výkonné techniky a velmi sofistikovaných
algoritmů, dnes v běžných aplikacích nedostupných.
86
15 Aplikace pro řízení externích vztahů Gála et al., 2011.
B2C
B2B
o Elektronická výměna dokumentů (EDI)
o Elektronické zásobování
o Elektronické tržiště
o Elektronické aukce
B2G (Business to Government) - např. elektronické celní řízení
C2G (Citizen to Government) – např. Czech Point
C2C – elektronické obchodování mezi zákazníky, typu např.eBay.
B2E (Business to Employee) – informace a dodávky služeb zaměstnancům
mobilní aplikace jako m-Commerce, m-Presence, m-Payment, m-Shop, m-Marketing atd.
Výhody a specifika – nezávislost na místě, dosažitelnost kdekoliv, jednoznačná identifikace
zákaznika, lokalizace partnerů, jednodušší platby.
CRM – Customer Resource Management
B2C (Business to Consumers) – prodejcem je podnik a nakupujícím je konečný spotřebitel. Někdy se
používá termín e-tailing.
Základem jsou webové aplikace napojené na databáze ERP spojené s prodejem. Prodej se realizuje bez
přímé spolupráce obchodníka.
Základní činnosti zahrnují:
Prohlížení katalogu zboží a služeb
Výběr zboží
Výběr podmínek dodání a platby
Kontrola a platba
Uplatní se klasické e-shopy i e-mally (tržiště pro více obchodníků).
B2B (Business to Business) – nákup i prodej (či jiné aktivity) realizují samy podniky.
Základní činnosti zahrnují:
Prezentace, nabídky
Výběry,
Příprava obchodních dokumentů
Výměna obchodních dokumentů (EDI)
Vytěžování informací z obchodních transakcí pro analytické a plánovací úlohy.
Např. technologie AIF (Application Integration Framework) umožňuje vyměňovat data s externími
systémy pomocí XML dokumentů. Zajišťuje nejen vlastní komunikaci, ale i řešení aplikační a
obchodnéí logiky, podle které komunikace probíhá. Např. definice činnosti a pravidel po přijetí
dokumentu.
Vedle EDI sem patří i elektronické zásobování (e-Procurement) pro zajištění dodávek zboží,
elektronické tržiště (e-Marketplace) pro společné řešení obchodních vazeb nakupující-prodávající
(tržiště horizontální, vertikální, komoditní) a elektronické aukce, určené k soutěžení nabídek.
15.1 Elektronická výměna dokumentů (EDI)
15.1.1 Podstata a místo EDI v architektuře IS/IT
EDI se chápe jako způsob výměny strukturovaných dat (např. objednávek faktur, dobropisů apod.) na
základě dohodnutých standardů zpráv mezi informačními systémy jednotlivých obchodních parametrů
pomocí elektronických prostředků EDI tak vede k „bezpapírovému“ obchodu.
87
Na rozdíl od elektronické pošty pro předávání jakýchkoli (nestrukturovaných) zpráv je pro EDI
podstatné to, že jde o přenosy strukturovaných dat, které pak musí podléhat dohodnutým pravidlům
jejich strukturalizace, syntaxe apod. Při elektronické výměně dat jde primárně o komunikaci mezi
dvěma aplikacemi, aplikačním software a to znamená, že vzájemně předávaná data musí být
konvertována do dohodnutých standardů podle výše zmíněných pravidel. Kromě dohod o formálních
standardech dokumentů musí mezi oběma obchodními partnery dojít i k dohodě o legislativních
aspektech dokumentů předávaných formou EDI.
Na rozdíl od elektronické pošty orientované primárně na osobní, individuální poštovní schránky
(mailboxy), EDI preferuje podnikové schránky („elektronické podatelny“), z nichž se potom
dokumenty směrují příslušným pracovníkům. EDI však není zdaleka pouze otázka technická.
Vyžaduje potřebné technologie pro přenos dat, ale současně představuje výrazné změny v obchodních
postupech a obchodních vztazích.
Původ EDI lze hledat v 60. letech v USA, kdy v některých sektorech ekonomiky (automobilový
průmysl, letectví, zdravotnictví) se začalo s EDI experimentovat, ještě však na bázi dostatečných
informačních technologií a slabě definovaných komunikačních standardů. První úspěšná praktická
aplikace se však objevila na londýnském letišti Heathrow na počátku 70.let v podobě systému LACES
pro celní odbavování leteckých nákladů.
Názory na rozšíření EDI a jeho dopady na organizaci se různí, převládají však jednoznačně pozitivní
tendence. Z průzkumu provedeného konzultační firmou Deloitte & Touche mezi 400 informačními
manažery v USA vyplynulo, že naprostá většina z nich považuje EDI za klíčový moment zásadní
restrukturalizace řídících a obchodních procesů. V různých státech se však využití EDI značně různí a
právě USA a Velká Británie patří k zemím s jeho největším rozšířením.
Převážně dochází k tomu, že podnik, který začíná komunikovat prostřednictvím EDI s několika
obchodními partnery, rychle rozšiřuje tento způsob práce na všechny relevantní kooperující
organizace. Tomu odpovídají i výsledky průzkumu provedeného americkou organizací EDI Group
Ltd., kde se předpokládá prudký rozvoj trhu s EDI službami a produkty. V roce 1993 byl celkový
obrat v této oblasti 1,2 miliardy USD, přičemž v roce 1997 by měl vzrůst na 3,5 miliardy USD.
EDI se uplatňuje především v obchodních transakcích, má však velmi výrazný dopad i do dalších
oblastí řízení podniku. Např. ve výrobě je jedním z předpokladů uplatnění metody Just-In-Time, kde
má EDI výrazný vliv na snižování délky výrobních cyklů, vysokou flexibilitu výrobních procesů a
kapacit, snižování velikosti výrobních dávek, minimalizaci zásob materiálů, polotovarů i hotových
výrobků. Anketa provedená mezi informačními manažery skupiny PREMIER 100 v USA (sto
nejúspěšnějších podniků z hlediska aplikací INFORMAČNÍCH TECHNOLOGIÍ v daném roce)
vyplynulo toto rozdělení relativního významu EDI pro organizaci:
1. 58% - prodej a marketing
2. 27% - výroba
3. 15% - finance, účetnictví.
Hlavní přínosy EDI pro postavení a rozvoj podniku jsou:
podstatné zrychlení obchodního cyklu (nabídka – objednávka – potvrzení objednávky – smlouva –
faktura - …), odhaduje se průměrné snížení doby obchodního cyklu o 44-50%,
vytvoření pevných vazeb k obchodním partnerům a obrana proti nové konkurenci (nastupujícím
firmám, které takové vazby ještě nemají vybudovány),
předpoklady pro uplatnění moderních metod řízení výroby (viz výše),
snížení dodacích lhůt – i v důsledku urychlení nezbytných doprovodných operací (celní odbavení,
pojištění, urychlení transportu snížením čekacích dob na překladištích v přístavech, …),
snížení nákladů na administrativu (poštovné, mzdové náklady, …)
urychlení platebního styku a lepší možnosti sledování cash flow,
snížení chybovosti obchodních dokumentů minimalizací jejich přepisování, v průměru o 27%,
výchova pracovníků podniku k rychlejší a pružnější komunikaci s partnery.
K masovému uplatnění EDI v praxi postupně přispěly takové faktory jako nové informační
technologie – jejich zvýšení dostupnosti (PC, počítačové sítě, …), rozšíření telekomunikačních sítí,
potřeba EDI ve vedení podniků a společností vyvolaný tlakem konkurence, stále vyšší variabilitou
88
trhu, nároky na pohotovější a flexibilnější služby dodavatelů (při průzkumu v Anglii se již pro EDI
vyslovilo 69% respondentů, zatímco proti 21%, deregulace telekomunikací (zatím v zahraničí), která
vedla při potlačení státního monopolu k vytvoření nových výkonných sítí.
15.1.2 Technologické principy EDI
Na provozování EDI existují tyto základní požadavky:
Vytvoření smlouvy mezi obchodními partnery – to znamená dohodnout se na každém
typu zprávy, která bude posílána mezi partnery (tj. souhlasit s typem zprávy, její
skladbou, použitým standardem, typem komunikace atd.), dále na aktuálnosti zasílaných
dat a jejich kódování, vymezení vzájemné zodpovědnosti při vzniklých chybách. Toto je
ovlivněno právními aspekty daného státu (jako např. kdy bude daná faktura platná, jaké
jsou požadavky od vlády, zda musí být každá faktura zkopírována a potvrzena) a
standardizací definic a kódování zboží (např. kódování EAN).
Vytvoření EDI transakce – zahrnují oblasti definovaných zpráv (obchod, finance,
doprava, proclení).
Vytvoření EDI výměny – zahrnuje jednu nebo více zpráv pro jednoho partnera.
Na požadavky na provozování EDI navazuje potřeba jednotlivých komponent pro integrované
provozování EDI.
15.1.2.1 Vazba na aplikační software
Počátečním a konečným momentem výměny dat mezi IS/IT obou obchodních partnerů je převedení
dat z formátu obchodní aplikace (aplikačního software) do formátu EDI software a naopak převzetí dat
z formátu EDI software do formátu dat obchodní aplikace (aplikačního software). Tyto operace jsou
součástí aplikačního interface.
Implementace těchto komponent se může lišit podle přístupu, který je v dané firmě zvolen. Tak např.
transformační algoritmy mohou být realizovány na straně aplikačního software nebo speciálních EDI
procedur.
Přijatá data od externího partnera mohou být okamžitě předána aplikaci, aplikačnímu software a
spuštěna příslušná akce nebo mohou být pouze uložena do příslušné databáze pro další zpracování.
Softwarové produkty pro EDI mají charakter obecně použitelných softwarových nástrojů nebo
produktů tvořících součást velkých aplikačních programových balíků.
Základní komponentou v programovém systému BPCS pro EDI je tzv. EDI-SOL. EDI-SOL je
překladač EDI s řešením dotazů on-line, výměnou a údržbou zpráv a možnostmi získání nejrůznějších
statistických zpráv. EDI-SOL je dodáván se standardy ANSI X.12, EDI-FACT. Dále je podporována
údržba celního zpravodajství, vícenásobná jazyková podpora pro obrazovky a chybová hlášení, HELP
texty a ostatní dokumentaci.
15.1.3 Standardy EDI
EDI standard se definuje jako „dohodnutá reprezentace informace (jaké položky, jak strukturovány a
kompletovány), která se má přenášet z jedné počítačové aplikace do jiné“ [Berge, J.“ The EDIFACT
standards, NCC Blackwell, 1991]. Standardy EDI tak definují způsob vyjádření jednotlivých částí
obchodních dokumentů, tj. jednotlivých položek (identifikace zboží, cena, datum dodání, …) a jejich
seskupování do obchodních dokumentů nebo zpráv (objednávka, faktura, …).
Standardy EDI se vztahují k jednotlivým částem, resp. hierarchickým úrovním obchodní
dokumentace, které jsou vymezeny takto:
Datové prvky (Data Elements)
89
Datové prvky jsou všechny základní údaje obsažené v dokumentu, např. identifikace, název
zboží apod. Standardizuje se forma vyjádření jednotlivých datových prvků, např. datum, váha
zboží apod.
U některých standardů (viz dále) se uvádí ještě tzv. složený datový prvek (Composite Data
Element).
Segment (Segment)
Segment je logickým seskupením datových prvků do vyššího celku, např. popis zboží, adresa
zákazníka apod. Obsah a uspořádání těchto segmentů se pak vztahuje k různým dokumentům,
např. vyjádření adresy je stejné pro dodací list, fakturu atd.
Zpráva (message)
Zpráva je určitým druhem EDI komunikace pro zajištění požadované obchodní funkce, např.
fakturování, zaslání objednávky apod. Zprávy se sestavují ze segmentů a musí dodržovat
definovaná syntaktická pravidla (viz dále).
Funkční skupiny (Functional Groups)
Funkční skupina je souhrn všech zpráv stejného typu, např. všech objednávek podniku.
„Výměna“ (Interchange)
Interchange tvoří základní jednotku, obálku komunikace v EDI mezi obchodními partnery a
obsahuje logickou strukturu zpráv a funkčních skupin.
Syntaktická pravidla (Syntax Rules)
Syntaktická pravidla určují jak jednotlivé prvky komunikace (datové elementy, zprávy,
funkční skupiny) sestavovat a vzájemně uspořádat do logických celků.
Pravidla pro návrh zpráv (Message Design Guidelines)
Tato pravidla se vztahují pro návrh nových zpráv nebo modifikaci existujících tak, aby byly
srozumitelné všem ostatním uživatelům.
Počátek vývoje těchto standardů se váže k organizaci SITPRO (Simplification of International Trade
Procedures Board), která na počátku 70. let vydala soustavu syntaktických pravidel a slovník
základních datových prvků pro obchodní dokumenty. Tato soustava byla později přijata UNECE
(United Nations Economic Commission for Europe) a na jejím základě vytvořila UN/TDED (United
Nations / Trade Data Element Direktory), která se stala plným mezinárodním standardem (ISO 7372).
UNECE pak vytvořila syntaktické standardy a pravidla pro výměnu obchodních dat UN/TDI (United
Nations /Trade Data Interchange).
UN/TDI byla postupně aplikována v různých sektorech ekonomiky, zejména v Evropě, pro vytvoření
vlastních standardů výměny dat. Tak např. pro obchod vznikl TRADACOMS, pro automobilový
průmysl ODETTE apod.
Ve Spojených státech se standardizační práce rozvíjely v rámci organizace ANSI (Američan National
Standards Institute). Standard výměny dat pro EDI ANSI X.12 byl pak úspěšně přijat a aplikován
v USA, částečně v Austrálii, v ostatních částech světa však nebyl příliš akceptován.
Z předchozího textu vyplývá, že standardizace v EDI šla dvěma základními směry – ANSI X.12 a
UN/TDI. Evidentní potřeba sjednotit oba směry vedla k vytvoření společné skupiny v rámci OSN UN-
JEDI (UN point EDI group). Tato skupina vytvořila první společný standard syntaktických pravidel
pro EDI s označením ISO 9735, resp. EDIFACT (Electronic Data Interchange for Administration,
Commerce and Transport).
V Belgii a Lucembursku vznikl pro oblast obchodu standard ICOM (systém ICODIF de
Communication, kde ICODIF znamená Institut de COdification des DIstributeurs et des Fabricants).
V dnešní době nelze nezmínit XML jako významný nástroj standardizace komunikace mezi systémy.
Jeho význam je o to větší, že vůči klasickým systémům EDI jsou výhrady pro jejich cenu a jistou
omezenost aplikace.
90
15.2 CRM systémy
Další čtení z Gála L., Pour J., Prokop T. Podniková informatika, Grada 2006. s. 165-172.
15.2.1 Filosofie, organizace
CRM - (Customer Relationship Management, česky bychom řekli řízení vztahu se zákazníkem),
informační systémy zajišťující správu dat souvisejících s péčí o zákazníky. Názory na přesnou definici
pojmu CRM se velmi různí, většina se však shoduje v tom, že CRM neznamená pouze implementaci
technologie. Velmi často se naopak hovoří o kulturní změně ve vnímání zákazníka.
Kdybychom se chtěli pokusit o přesnou definici pojmu, mohli bychom říci, že "CRM je: filozofie,
která staví zákazníka na nejvyšší místo a sbližuje firmu s jejím zákazníkem". CRM je proces, jehož
cílem je udělat vztah se zákazníkem ziskovým. K dosažení tohoto cíle je třeba, aby marketing, obchod
a služby fungovaly jako jednotný celek, který sdílí stejné informace. A právě to je umožněno
automatizovanou podporou CRM.
CRM problematika zasahuje velmi širokou oblast, v podstatě všechny procesy týkající se zákazníků.
Tedy nejenom poskytování služeb dosavadním zákazníkům, ale i podporu pro získávání nových a
vytváření nabídky služeb a produktů na míru jednotlivým klientům. Firma, která tuto problematiku
dobře zvládla, již není zaměřena na informační technologie, výrobu ani schopnost realizovat dodávku,
ale na zákazníka.
Pro podporu všech zmíněných oblastí jsou vhodné různé specifické systémy. I když dnešní CRM
systémy jsou vysoce sofistikované, na celkovém výsledku se podílí další prostředky, ať již technické
či softwarové. Správné složení těchto prvků do efektivně pracující mozaiky vyžaduje předem
promyšlený koncept řízení zákaznických vztahů.
15.2.2 Výhody CRM
Mezi hlavní výhody patří:
efektivní řízení vztahů se zákazníky
automatizace rutinních procesů
sdílení informací a týmová spolupráce
sběr a analýza informací z různých zdrojů a různého formátu
přístup k relevantním informacím,
sledovaní efektivnosti zainteresovaných pracovníků a činností
15.2.3 Postupy CRM
Jeden z možných konceptů respektuje požadavky na otevřenost a budoucí rozšiřování o další systémy
a technologie, které ani ještě nemusí být na trhu. Zároveň poskytuje komplexní řešení pokrývající
stávající potřeby zákaznických procesů. V celkovém pohledu na architekturu oblasti zákaznických
vztahů je třeba rozlišit 4 hlavní vrstvy které se podílí na realizaci řízení vztahů se zákazníky. Jde o
vrstvu komunikačních kanálů realizující fyzické spojení firmy a zákazníka, vrstvu logického řízení
těchto kontaktů - realizovanou v CRM systému, vrstvu realizující systémovou integraci - middleware a
oblast všech ostatních back office systémů.
1. vrstva - Komunikační kanály pro kontakt se zákazníky
Vrstva komunikačních kanálů reprezentuje technické prostředky pro realizaci přístupových cest
(komunikačních, distribučních kanálů). Některé prostředky mohou komunikovat přímo se systémem
CRM, jiné potřebují spojovací článek. Tím je například CTI software (Computer Telephony
Integration) v případě komunikace pobočkové ústředny a informačního systému.
V současné době jsou standardně k dispozici tyto kanály a technické prostředky pro jejich realizaci:
a) Osobní kontakt na pobočce firmy - POS (Point of Sale), nepoužívá se žádná specifická
technologie, pro pracovníka na pobočce je primární aplikací CRM systém. Kontakt a jeho obsah je
91
zaznamenán do CRM, takže mezi informacemi o zákazníkovi je vidět, že navštívil pobočku a
proč.
b) Písemná korespondence - Systém pro elektronickou správu dokumentů EDMS (Electronic
Document Management System) realizuje podporu korespondence se zákazníkem, evidenci
uzavřených smluv. EDMS systém je s CRM systémem integrován, takže pracovník firmy má
snadný přístup k existující písemné dokumentaci týkající se zákazníka. Standardně EDMS systém
eviduje i korespondenci elektronickou poštou. Využité technologie: EDMS
c) Elektronická pošta - Slouží pro vznášení požadavků ze strany zákazníka, stejně jako odchozí
komunikační kanál pro poskytování informací pro zákazníka. Tento kanál je realizován e-mail
serverem a pro evidenci využívá EDMS. Příchozí e-mail s příslušnými parametry může potom
přímo v CRM automaticky spouštět definované akce a procesy. Využité technologie: E-mail
server, EDMS
e) Faxová komunikace - Většinou se využívá jako odchozí komunikační kanál pro opakované
poskytování informací (výpisy z účtů, kurzovní lístek). Je realizován faxovým serverem a pro
uchování korespondence je opět využit EDMS. Využité technologie: Fax server, EDMS
f) Telefonický kontakt (mobilní, fixní) - Zahrnuje komunikaci mobilními telefony i komunikaci
pomocí pevných linek. Komunikace mobilními telefony poskytuje rozšířenou funkcionalitu (SMS,
WAP), na druhou stranu potřebuje i dodatečnou sofistikovanou technologii jako je SMS centrum
pro poskytování objednaných textových zpráv nebo specializovaný WAP portál společnosti. V
případě WAPu se jedná i o telefonní přístroj umožňující tuto technologii.
Oba druhy telefonní komunikace využívají pobočkovou ústřednu (PaBX), automatický hlasový systém
(IVR) pro automatické vyřízení standardizovaných dotazů a odpovědí (zůstatek na účtu,
protelefonované minuty, obecné informace apod.), dialer pro automatické vytáčení odchozích hovorů -
tato funkcionalita může být poskytnuta v rámci CTI prvku. CTI komponenta (Integrace telefonní a
počítačové sítě - Computer Telephony Integration) je využita pro přenos telefonního čísla (či jiného
identifikátoru) do LAN sítě a jeho následného využití jako vyhledávacího parametru.
Využité technologie: PaBX (Private Branch Exchange), IVR (Interactive Voice Response), Dialer,
CTI (Computer Telephony Integration), SMS centrum (Short Message Service), WAP (Wireless
Application Protocol)
g) Komunikace přes internet (webové stránky) - V případě řízení vztahů se zákazníky je jedná
primárně o nabídku samoobslužných funkcí pro koncového zákazníka firmy. Zákazník firmy
přistupuje klasickým způsobem na internetovou stránku, která mu nabízí různé možnosti.
Self service - samoobsluhu pro vznášení požadavků vůči firmě. Tyto požadavky mohou být ve
formě objednávky zboží, nebo požadavku na informace nebo například zaregistrování stížnosti či
problému pro řešení. Přístup k těmto možnostem může být samozřejmě limitován například na
existující zákazníky.
Zákazník může mít během pohybu na našich stránkách upřesňující dotazy. Nabízí se mu
příležitost si tyto dotazy upřesnit pomocí on line výměny textu (chatu) s pracovníkem firmy.
Jinou možností je zákazníkovo přání, aby mu bylo zavoláno v určitý čas zpět (Call back button) a
dotazy vyřešit telefonicky.
h) BLOG
i) Sociální sítě
Všechny příchozí požadavky jsou v příslušné formě zaznamenány do CRM systému a dle jejich typu
(objednávka, problém,...) jsou směrovány k řešení pomocí workflow CRM systému.
Využité technologie: Internet, Chat (On line výměna textu po internetu), Call Back (Zpětné volání)
Pokud se společnost rozhodne implementovat CRM systém nebo lépe zdokonalit péči o své zákazníky,
je obvykle první krokem rozhodnutí o realizaci Call Centra. Firma tak doplní dosavadní prostředky
kontaktu se zákazníky o další kanál. Pak většinou přichází na řadu zpřístupnění kontaktů a služeb
prostřednictvím webových stránek a elektronické pošty. Následují možnost komunikace pomocí
krátkých textových zpráv (SMS), chytré telefony, BLOG, sociální sítě.
92
2. vrstva - CRM - vrstva firemních procesů
Základním principem je záznam požadavku zákazníka jako objektu (případ, hovor, příležitost), který
je následně směrován k dalšímu zpracování pomocí zabudovaného workflow. Objekty mohou být
směrovány jak uživatelům CRM systému, tak i dalším stranám, které se na procesu podílejí.
Workflow (předdefinovaný tok objektů v rámci obchodního procesu) je podporováno v rámci všech
modulů CRM. Tak je připravena architektura pro realizaci předávání požadavků a práce mezi
jednotlivými odděleními firmy. Těmi jsou obsluha a služby zákazníkům (Customer services), obchod
(Sales) a marketing.
Obecný koncept CRM systému vychází z toho, že všechny moduly sdílí jednu databázi. Moduly CRM
systému typicky pokrývají organizační oblasti firmy - marketing, prodej, péče o zákazníky.
Informace o zákaznících a jejich chování a z nich vyvozené závěry jsou pak přímo přístupné všem
pracovníkům, kteří zasahují do životního cyklu zákazníka. CRM systém pak tvoří jediný zdroj
informací o zákazníkovi a je zaručena jejich konzistentnost a aktuálnost.
Podpora marketingu
Podpora marketingu v rámci CRM spočívá ve dvou základních principech:
poskytnutí softwarového nástroje pro řízení marketingových kampaní (výběr cílové skupiny,
odchozí volání zákazníkům, sledování výsledků kampaně, evidování nákladů na kampaň,
sledování návratnosti a další ukazatele)
urychlení procesu ovlivnění marketingových záměrů dle analyzovaného chování zákazníka
(sdílením informací s oddělením péče o zákazníka je možné téměř okamžitě po spuštění zjistit
problémovou či výrazně úspěšnou službu a vlastní jednání tomu přizpůsobit)
Obecně jde o proaktivní strategii využívání informací a informačních technologií v marketingu s cílem
přiřadit marketingové zdroje aktivitám, komunikačním kanálům a mediím s nejvyšší mírou návratnosti
a nejúčinnějším dopadem na vztah se zákazníkem.
Tradiční metriky podílu na trhu a penetrace jsou doplněny metrikami ziskovosti (konkrétního)
zákazníka, hodnoty zákazníka v životním cyklu (customer lifetime value) a příspěvku zákazníka pro
společnost (firmu). Pro podporu marketingu v rámci CRM se také používá termín Technology enabled
marketing (TEM).
Podpora obchodu
Obchodní procesy v rámci CRM jsou standardně podporovány specializovanými moduly Sales.
Podpora obchodu se nazývá také Technology enabled selling (TES) nebo sales force automation
(SFA). Jedná se o podporu obchodu prostřednictvím různých obchodních kanálů - například podpora
osobního prodeje, prodej přes telefon (telesales), prodej přes web (e-sales). Cílem TES je integrace
technologie s optimálními procesy tak, aby bylo možné průběžně zlepšovat efektivitu prodejního týmu
a efektivnost prodejních kanálů.
Mezi komponenty TES patří
Osobní prodej (Field Sales), pro což se také používá označení sales force automation (SFA).
Zahrnuje aplikace pro obchodní zástupce, kteří musí často pracovat v terénu mimo kancelář bez
možnosti datového spojení s firmou. Pro svou práci však potřebují přístup k aplikacím a databázím
a sdílet data.
Podpora vzdáleného přístupu je téměř vždy standardem CRM systému (mobile client), většinou s
možností omezit přístup na specifická data (např. dle příslušného teritoria).
Podpora služeb zákazníkům
Tato oblast bývá také označována jako customer service (CS) a jejím cílem je udržení a rozšiřování
vztahu se zákazníkem po uzavření smlouvy. Oddělení služeb zákazníkům jsou v kontaktu se
zákazníky (na reaktivní či proaktivní bázi) mnohem častěji než jakákoli jiná část podniku a proto je
jejich práce kritická pro udržení spokojenosti zákazníka. V důsledku vzrůstající komplexity kontaktu
se zákazníkem vyžaduje podpora této oblasti komplexní technologickou infrastrukturu, která je
93
flexibilní, rozšiřovatelná a integrovaná tak, aby vyhovovala potřebám zákazníků a jejich představám o
korektní a rychle poskytované službě.
Mezi komponenty CS patří:
Řízení příchozích požadavků - klíčová funkcionalita všech aplikací. Tato komponenta je
používána pro záznam všech příchozích požadavků (telefon, www, email, osobní kontakt) a pro
řízení jejich životního cyklu od příjmu až do uzavření. K tomu je třeba integrovat CRM systém s
komunikačními kanály. Proto jsou CRM systémy vybaveny hotovými konektory, které příslušnou
integraci realizují bez nutného vývoje rozhraní.
Obsluha zákazníků prostřednictvím Internetu (e-service) - tyto aplikace a nástroje umožňují
zákazníkům a partnerům komunikovat se společností prostřednictvím www, Internetu nebo
extranetu. Interaktivní služby zákazníkům by měly být integrovány s front-end aplikacemi pro
obsluhu zákazníka (služby zákazníkům, obchod, marketing, e-commerce).
Služby v terénu (Field Service) - FS je historicky back-office funkcí, ale na trhu služeb se stává
kritickým faktorem pro služby zákazníkům a je tedy i důležitou aplikační oblastí CS a tedy i
CRM.
3. vrstva - Integrační platforma - vrstva vzájemné komunikace
Pro poskytnutí kvalitní služby je nutné zpřístupnit pracovníkům organizace na jedné obrazovce i data z
fakturačních a ostatních systémů. Jde například o situace, kdy pracovník firmy hovoří se zákazníkem o
vydané faktuře a potřebuje sdělit zákazníkovi rychle a přesně korektní údaje a proto potřebuje
jednoznačné informace z billingového systému.
Lze očekávat, že v blízké budoucnosti se CRM systémy stanou primárními zdroji dat. Zákazník tedy
bude měnit svá data (parametry služby, osobní údaje a pod.) přímo v prostředí CRM systému (ať již
prostřednictvím operátora nebo sám přes internet) a tyto změny budou dále postoupeny do systémů,
které tato data fyzicky zpracovávají.
V prvních fázích je nezbytné zprovoznit interface mezi CRM systémem a fakturačním systémem. V
úvahu přichází dvě možnosti:
proprietární rozhraní, vytvořené na míru dané konfiguraci (specifikováno která data, jaké množství
a jak často)
použití middlewaru.
4. vrstva - Back office systémy
V této poslední vrstvě leží podnikové systémy, které zajišťují zpracování dat nutných pro realizaci
poskytovaných služeb a produktů. Jde o fakturační (billingové), podnikové systémy, systémy pro
řízení sítě, síťové komponenty a další. Tyto systémy byly dosud primárním zdrojem dat o zákazníkovi.
S realizací jednotného pohledu na zákazníka pomocí CRM systému se však přechází k obrácenému
směru, tak aby primárním zdrojem dat byl CRM systém a jeho údaje byly směrovány do back office
systémů.
94
16Outsourcing
Outsourcing je pojem, který vychází ze slov out (=vnější) a source (=zdroj) a znamená
uskutečňování činností pomocí vnějších zdrojů. "Outsourcing" představuje vyčlenění správy
informačních technologií mimo vlastní společnost a začíná být aktuálním trendem ve světě IT.
Hovoříme-li tedy o outsourcingu ve spojitosti s informačními technologiemi (IT), znamená to
vyčlenění oblasti IT z organizační struktury podniku, zpravidla včetně zaměstnanců a
hardwarového i softwarového potenciálu a organizačního zajištění. V oblasti IT využívají outsourcing společnosti, které poznaly, že vlastní vývoj a údržba jejich
informačního systému je pro ně z ekonomického hlediska nevýhodná. Využívají služeb počítačových
firem - poskytovatelů outsourcingu, kterým předají odpovědnost za návrh, budování a správu
jejich informačního systému.
Outsorcing je moderní formou spolupráce podniků. V podstatě se jedná se o možnost nákupu
čehokoli. Outsorcing slouží k zvyšování produktivity a flexibility. Firmy si kupují to, co neumí dělat
dostatečně produktivně realizovat sami. Outsorcing umožňuje i pružnou reakci podniku na kolísání
poptávky. Při náhlém růstu poptávky si podnik koupí to, co přesahuje jeho úzká hrdla (ve výrobě,
konstrukci i jinde), při poklesu poptávky je outsorcing omezován. Outsorcing při velkém
celosvětovém převisu kapacit umožňuje jednotlivým podnikům pracovat téměř bez kapacitních
omezení.
Metoda outsourcingu se provozuje již od sedmdesátých let a v létech osmdesátých se stala pro
mezinárodní koncerny, jako např. Kodak, Xerox, GM, apod., součástí podnikových procesů pro
vybrané podpůrné oblasti.
16.1 Obecný popis outsourcingu IT
Outsourcing IT znamená pro vrcholové vedení zadavatele vyjasnění a definici jeho vlastních
podnikových procesů. Tyto procesy se třídí do kategorií základních a podpůrných podnikových
funkčních oblastí.
Pro outsourcing IT je důležitá role informačního systému pro zadavatele, tzn. jakým způsobem je
ovlivněná podnikatelská činnost podniku provozem informačního systému.
Všechny podpůrné procesy mohou být předmětem outsourcingu, splní-li další kriteria, jako je
například schopnost naprosto jasné definice rozhraní outsourcovaného procesu.
Co přináší outsourcing IT:
Ekonomické výhody
Management většiny podniků v ČR se domnívá, že outsourcing IT je mnohem nákladnější než provoz
ve vlastní režii. Ovšem z finančního hlediska je výhodnější zajistit provoz definovaných oblastí
pomocí vlastních zdrojů. Proto jsou zde uvedeny ty faktory, které zpravidla nejsou zahrnuty do
finanční kalkulace při hodnocení vlastního zajištění provozu IS a jsou tak často podhodnoceny.
o Konzultační služby pro vývoj informačního systému
o Náklady na výběr nových technologií
o Likvidace zastaralých technologií
o Testování nových technologií před implementací
o Podpůrné technologie, které nejsou plně využité
o Organizační náklady pro pracovníky (pracoviště, personální náklady, pojištění)
o Školení operátorů, administrátorů a programátorů
o Exaktní přehled nákladů na informační systém
o Kalkulované, pravidelné a plánované náklady o Vlastní riziko při výpadku informačního systému
95
Personální výhody Klíčovou výhodou je záruka dostupnosti týmu odborníků, kteří jsou seznámeni s informačním
systémem zákazníka (většinou jej navrhovali a realizovali). Podnik, který není zaměřen na obor
informačních technologií (používá IT pouze pro svůj hlavní podnikatelský záměr), a který není
schopen dlouhodobě zaměstnávat tým expertů a nabízet jim tak osobní a profesní růst, může využít
služeb poskytovatele outsourcingu.
Dalšími přímějšími výhodami outsourcingu jsou:
Zastupitelnost operátorů, administrátorů atd.
Tým expertů pro různé oblasti IT (Knowledge Base)
Znalost nejnovějších technologií
Zkušenosti s problematikou informačních systémů
Angažovanost personálu
Administrační výhody Je to především převedení administračních procesů pro IT na poskytovatele outsourcingu:
Budování a udržení výpočetního střediska
Odpovědnost za řízení výpočetního střediska
Příprava na audit informačního systému
Projektové řízení všech procesů uvnitř informačního systému
Existují 2 hlavní skupiny outsourcingu:
Úplný outsourcing (outsourcing zodpovědnosti)
Úplný outsourcing obsahuje dodání všech součástí informačního systému jako je např.
hardware, software, údržba, podpůrné služby, odpovědnost za funkčnost systému, školení
uživatelů, bezpečnost informací, plnění právních norem, atd. Použití většinou u nově
vznikajících firem a při kompletní obměně IT. V případě úplného outsourcingu, poskytne
firma celý informační systém a převezme zodpovědnost za jeho provozování. Zákazník pak
platí dohodnuté měsíční paušály za užívání systému(toto není leasing).
Personální outsourcing
Personální outsourcing obsahuje poskytování služeb a personálu pro údržbu, zajištění funkčnosti,
rozvoj informačního systému, školení uživatelů a jiné služby, které jsou nutné pro definovaný
provoz informačního systému.
Výhody a nevýhody řešení situace formou outsourcingu:
a) Výhody outsourcingu (podle Gála, Pour, Toman Podniková informatika):
Možnost soustředit se na hlavní činnosti podniku a tam trvale zvyšovat kvalitu
V případě vysoce kvalitního dodavetele se nabízí přístup k aplikacím a technologiím na
špičkové úrovni
Rychlejší uplatnění nových technologií
Zvýšení flexibility rozvoje informatiky vzhledem k požadavkům uživatelů – dodavatel
většinou disponuje větším zázemím zdrojů než vlastní útvar informatiky zákazníka
Rozložení nákladů na produkty a služby a s tím související uvolnění personálních zdrojů nebo
kapitálových prostředků na jiné účely
Snížení nákladů na informatiku, neboť dodavatel většinou sdílí zdroje pro více zákazníků
96
Řešení problému, kdy zákazník nedisponuje potřebnými zdroji pro rozvoj
Snížení odpovědnosti za správu a řízení outsourcované oblasti
b) Nevýhody outsourcingu:
IT Outsourcing v sobě skrývá také nebezpečí a nevýhody. Nicméně tyto nevýhody lze
minimalizovat a případně eliminovat správně navrženým a zajištěným outsourcingovým
kontraktem:
Dlouhodobá závislost na jednom dodavateli, protože výměna dodavatelské firmy je náročnou
operací; nevratnost rozhodnutí
Bezpečnostní rizika, jak v oblasti provozu, tak možnost úniku interních informací
Nedostatečné znalosti dodavatele v předmětné oblasti zákazníka (nerozumí tomu, co
zákazníka živí)
Špatný smluvní vztah
Podcenění procesních a organizačních pravidel kooperace
Průběh Outsourcingu:
Outsourcing se realizuje jako proces pomocí projektu. Jeho průběh je vždy velmi specifický a je přímo
závislý na typu a struktuře organizace objednatele. Samotný proces lze rozdělit do několika stěžejních
fází:
1) analýza funkčních oblastí
2) určení oblasti, které budou vytěsněny
3) výběr dodavatele
4) vymezení vztahu objednatel x poskytovatel, smlouva
5) řízení a kontrola vztahu
6) transformace, tj. oursourcing služeb
97
17 ERP a ERP II, TOC ERP (Enterprise Resource Planning) představuje softwarové řešení pro MIS. Základem je architektura,
která výrazně přibližuje výrobní a finanční moduly. Snaží se integrovat a automatizovat klíčové
podnikové procesy, funkce a data v rámci celé firmy (Gála,..).
ERP navazuje na předcházející řešení aplikací:
MRP (Material Requirements Planning) – plánování potřeb výroby, nákupů apod.
MRP II (Manufacturing Resource Planning) – zahrnuje i plánování výrobních kapacit.
ERP zpravidla obsahuje moduly:
Aplikační – základní funkcionalita v různých oblastech řízení
Dokumentační – on-line help
Technologické a správní – nastavování, analýzy operací pomocí ERP
Implementační – definování a optimalizace podnikových procesů
Kastemizační
Vývojové prostředí
Rozhraní – k databázovým systémům, operačním atd.
ERP II systémy integrují více další typy aplikací, jako jsou CRM, BI, e-Business, SCM (Supply Chain
Management) (Gála.., Blažek..)
SCM (Supply Chain Management)
Metoda TOC – OPT, DBR pokračuje až 158. Zejména ale 247-262
TOC (theory of constraints).
Charakteristické rysy TOC (Básl, Blažíček 2):
Plánování soustředěno na „kdy“, cílem je včasné dodání
„Jak“ je vyráběn produkt (zejména se soustřeďuje na úzká místa ve výrobě)
OPT (Optimised Production Technology):
Zdroje jsou úzkoprofilové (omezující) a neúzkoprofilové.
10 pravidel:
1. Vytíženost neúzkého místa není určena jeho kapacitou (potenciálem), ale jiným omezením
v systému
2. Vytíženost a aktivace zdroje nejsou totéž
3. Hodina ztracená na úzkém místě je ztrátou celého systému
4. Hodina ušetřená na neúzkém místě nemá smysl - je pouhým přeludem
5. Úzká místa určují propustnost a výši zásob v systému
6. Dopravní dávka se nesmí rovnat výrobní dávce
7. Výrobní dávka by neměla být fixní, ale proměnlivá
8. Kapacity a priority by měly být uvažovány souběžně a ne sekvenčně
9. Je potřebné vyrovnávat tok materiálu a ne kapacity
10. Suma lokálních optim není rovna globálnímu optimu
DBR (drum, buffer, rope – buben, zásobník, lano):
Buben je úzké místo v systému, které udává takt pro celou výrobu
Zásobník je časový a chrání průtok před nahodilostmi, aby buben nikdy nestál nevyužit
Lano svazuje a synchronizuje toky.
Využití TOC při inovaci podnikových procesů (s.247-262)
Soustřeďuje se na hlavní vstupy a výstupy z pohledu globální optimalizace.
Jednotlivé části se musí podřídit celku a sjednocujícímu cíli.
5 bodů pro trvalé zlepšování:
98
1. Identifikace úzkého místa
2. Maximální využití tohoto úzkého místa
3. Podřízení dalších částí podniku tomuto úzkému místu
4. Rozšíření tohoto úzkého místa
5. Návrat do bodu 1
3 základní oblasti uplatnění TOC:
Podpora rozhodování pro hlavní podnikové činnosti
Logická analýza v TOC (Thinking proces)
Průtoková analýza – finanční aplikace
Diagramy thinking process - modelují stávající a budoucí realitu v přesné akuzalitě a to pomocí
stromů:
Strom současné reality (CRT current reality tree) – popisuje současný stav a identifikuje
budoucí problém
Strom budoucí reality (FRT Future reality tree) – zachycení požadovaného stavu a hlavních
žádoucích efektů
Strom předpokladů (Prerequisite tree) – specifikace možných překážek navrhovaného zlepšení
a jejich řešení
Strom přechodu (TT transition tree) – specifikace dílčích kroků řešení s určením nutných
podmínek i očekávaných výsledků
Hledání odpovědí na:
Co změnit
Na co to změnit
Jak změnu provést
Přístup Necessary but not sufficient
Reakce TOC na neefektivní implementace ERP do podniků – absence změny chování uživatelů.
Jakákoliv technologie může přinést zlepšení jen tehdy, pokud zmenší vliv existujících omezení.
Critical Chain
Posloupnost závislých činností
99
18Business System Planning – BSP Podle Molnára (1991)
Tato metodika firmy IBM je jednou z prvních komplexnějších metodik určených pro plánování a
řízení postupu prací při výstavbě podnikového automatizovaného informačního systému. Vychází
z předpokladu, že prostředí podnikových informačních systémů se mění od operativního řízení
k managementu. Klade důraz na definování podnikových dat z informačních potřeb pro řízení a
stanovení koncepce řešení a její efektivní hardwarové a softwarové zabezpečení. Základním
východiskem metody BSP je chápání dat jako podnikových zdrojů. Jako taková musí být tato data
řízená jako každé jiné podnikové zdroje tak, aby co nejlépe sloužila podnikovým cílům a podporovala
potřebné rozhodovací procesy. I když se termínem „podniková data“ rozumí veškerá data
zpracovávaná v podniku, metodika BSP se zabývá jenom daty zpracovávanými počítačově.
Cíle a přístup metody BSP
Metoda BSP si klade následující cíle:
- definovat stálou informační architekturu podniku, která podporuje všechny podnikové procesy
(jestliže se jednou definuje, jaká data jsou potřebná pro určitý podnikový proces, např. nákup
polotovarů, potom pokud nedojde k zásadní změně tohoto procesu, zůstává stejný i příslušný
informační rámec tohoto procesu, a to i když dojde k organizačním změnám v podniku).
- stanovit priority informačního systému bez ohledu na lokální podnikové zájmy
- zabezpečit vývoj systému s dlouhým životním cyklem, který zabezpečí návratnost vložených
investic, protože vychází z podnikových cílů a ne z jeho organizačního uspořádání
- definovat data jako podnikové zdroje, které musejí být plánovány, řízeny a kontrolovány jako
každé jiné podnikové zdroje tak, aby byly užívány efektivně všemi útvary
- zabezpečit řízení datových zdrojů tak, aby účinně a efektivně podporovaly podnikové cíle
- zvýšit důvěru vedené tím, že bude vytvořen schopnější systém s rychlou návratností
- zlepšit vztahy mezi Útvarem pro IS a uživateli tím, že plánovaný systém bude odpovídat
uživatelským potřebám a prioritám.
Přístup BSP je charakterizován tím, že:
- analyzuje podnik shora dolů a postupně získává vedoucí pracovníky pro projekt, zahrnuje je do
něho (committment) a přitom studuje podnik od obecnosti k detailu
- buduje IS zdola nahoru od dílčích aplikací
- užívá důsledně strukturovanou metodologii
- převádí podnikové cíle do informačních potřeb
Nedostatkem metody BSP je to, že je příliš datově orientovaná a že jen málo podniků si může dovolit
vybudovat celou podnikovou databázi v jednom jediném „dramatickém“ záběru. Proces výstavby IS
je ve skutečnosti postupný (IS „roste“) a mnohotvárný. Dalším omezením této metody je to, že byla
navržena pro centralizované prostředí velkých výpočetních systémů nákupem komplexních
aplikačních programových systémů dodávaných na klíč tak, jak to odpovídá tradiční koncepci firmy
IBM.
18.1 Sestavení studijního týmu
Pracovníci studijního týmu by měli mít několik let praxe v podniku a dobré znalosti své vlastní
pracovní oblasti. Zároveň by měli být uznáváni „zbytkem“ podniku, schopni porozumět problému a
analyzovat ho, být ochotni podřídit se závěrům a doporučením s dlouhodobým dopadem na podnik a
být chápáni ostatními pracovníky podniku jako kompetentní a odpovědní pracovníci, jejichž
zkušenosti mají váhu.
Doporučuje se následující struktura týmu:
100
executive sponzor (ředitel podniku), vydá příkaz, viditelně a verbálně podporuje práci týmu a
určí jeho orientaci, sleduje pokroky a výsledky, účastní se podle potřeby na interview, působí
jako spojovací prvek mezi výkonnými vedoucími, dostane závěrečnou zprávu a udělá konečné
rozhodnutí
vedoucí týmu, který je odpovědný za to, že studie bude úspěšně dokončena, má vedoucí roli
v interview, organizuje práci týmu atd.
sekretář týmu, který asistuje vedoucímu, píše, kreslí apod.
členové týmu (4 až 7), zástupci jednotlivých hlavních funkčních oblastí podniku a jeden
odborník na IS/IT
zástupce hlavního dodavatele systému (např. firmy IBM)
Tým by měl pracovat na plný úvazek cca po dobu 8 až 12 týdnů. Je možné i řešení prací na částečný
úvazek, ale zde je nebezpečí, že se čas potřebný ke studii neúměrně protáhne a tím ztratí studie na
účinnosti. Kromě toho jsou pracovníci odváděni každodenními starostmi (operativou) od odpovědného
plnění úkolů v týmu.
18.2 Příprava a zahájení studie
Příprava studie je obyčejně plně v kompetenci vedoucího týmu a zahrnuje stanovení časového plánu
studie, vytvoření seznamu výkonných manažerů podniku, se kterými budou vedeny rozhovory,
shromáždění výchozích podkladů a zajištění pracovní místnosti.
Na zahajovacím setkání studijního týmu jsou cíle studie presentovány sponzorem a vedoucí týmu
provede přehled dosavadních přípravných prací a sdělí časový i obsahový plán studie.
18.3 Definování podnikových procesů
Řízení podniku se realizuje v jeho jednotlivých procesech (činnostech), které naplňují jednotlivé cíle
podniku. Proto studie BSP začíná analýzou těchto činností tak, abychom pro každou činnost mohli
určit její smysl a příspěvek k naplňování podnikových cílů. Výsledkem by měly být systémové
souvislosti, a tím i tok informací buď v celém podniku, nebo v určité jeho části, která je předmětem
našeho zájmu a vymezuje oblast budoucího řešení. Stupeň rozlišení podnikových procesů by neměl
být příliš vysoký, tzn., že se spokojíme s počtem okolo 30 procesů.
Začínáme tak, že postupujeme v souladu s životním cyklem výrobku či služby poskytované podnikem
a seskupujeme nebo rozdělujeme činnosti do skupin realizovaných vždy v jednom organizačním místě
nebo za jedním cílem. Vycházíme přitom z katalogu činností a organizačních míst, který podle potřeby
doplníme o činnosti, které se ukáží jako potřebné pro zajištění podnikových cílů.
Pro každý proces definujeme nejen to, z jakých dílčích činností se skládá, ale i to, jaké zásadní
rozhodovací procesy něm probíhají. Současně si zaznamenáváme, k jakým organizačním místům tyto
procesy přísluší, a to nejlépe formou vazbové matice funkční místo/proces. V této matici vazeb
uvedeme do sloupců procesy a do řádků pak jednotlivá funkční místa v organizaci podniku s cílem
vymezit podíl těchto organizačních míst na příslušných procesech. Obyčejně identifikujeme 20 až 30
podnikových organizačních míst, která nějakým způsobem ovlivňují podnikové procesy a spokojíme
se s rozlišením čtyř úrovní podílu organizačních míst, a to:
prázdné políčko = organizační místo nemá žádný vztah k procesu
O = organizační místo odpovídá za proces a rozhoduje o něm
V = organizační místo má významný vliv na proces
D = organizační místo má jen dílčí vliv na proces
Smyslem této matice je jednak vymezit oblast našeho zájmu (matice nemusí vždy pokrývat celý
podnik), jednak si připravit výchozí podmínky pro následné zjišťování informačních potřeb pro
jednotlivé procesy. Současně tím i jednoduchým statistickým propočtem zjistíme zátěž jednotlivých
organizačních míst (řádkové součty), či naopak důležitost a integrační charakter jednotlivých procesů
(sloupcové součty), což je pro nás vodítkem při rozdělování našeho úsilí při projektování IS.
101
18.4 Definování podnikových dat
Jak již bylo uvedeno, je definování podnikových procesů jenom přípravou pro následný krok, kterým
je definování podnikových dat. Postupujeme při tom v dále uvedených třech krocích.
1. Identifikace a definice podnikových entit. Podniková entita je něco, co je předmětem trvalého
zájmu pracovníků podniku, něco, o čem si pracovníci přejí mít nějaké informace. Entita může být
interní nebo externí z hlediska podniku a může představovat:
osoby - zákazník, dodavatel, zaměstnanec
místa - dílny, sklady, kanceláře
věci - stroje, výrobky, zařízení
zásady - právní nárok, funkce, organizační místo
jevy - dodávky, nákupy, výroba dílu apod.
Proto musí být každá entita jednoznačně identifikovatelná nějakým identifikátorem, klíčem (viz dále).
2. Určení dat potřebných a vznikajících v procesech. Pro každý podnikový proces si sestavíme
soupis potřebných dat a dat, která v procesu vznikají. Smyslem je zpřehlednit podniková data tak,
aby byly zřejmé nekonzistence dat a chybějící data, - a to především – připravit si podmínky pro
následné přiřazování datových položek entitám. Ne vždy se musí jednat o popis všech dat
v podniku, může jít o data, která jsou předmětem zájmu určité části podniku, jejíž informační
systém jsme se rozhodli automatizovat. Vznikne nám pak tzv. Data Subjekt Area – DSA.
3. Identifikace a definice datových skupin. Znalost vazby podnikových dat na podnikové procesy nás
přivede okamžitě k identifikaci a definici podnikových datových skupin. Datová skupina
representuje informace o entitě. Z toho je zřejmé, že bychom měli seskupovat dat podle entit,
přičemž musíme sledovat hledisko integrity podnikových dat. Neměl by tedy existovat více než
jeden zdroj dat, který je zodpovědný také za jejich přesnost, platnost atd. Proto mohou být data o
jedné entitě často rozdělena do více datových skupin podle svého zdroje (např. o výrobku existuje
řada datových skupin – skupina technologických údajů, za které je odpovědné oddělení
technologie, skupina obchodně-cenových údajů, za které je odpovědné obchodní oddělení atp.)
Každá podniková entita musí mít alespoň jednu datovou skupinu, která je s ní spojená. Pro zpracování
přehledu, tj. pro identifikaci dat a jejich zdrojů, můžeme s výhodou použít databázový metainformační
systém, resp. datový slovník jakéhokoliv CASE systému. Běžný strojírenský podnik vystačí obyčejně
s 60 až 100 datovými skupinami.
18.5 Definování informační architektury
Cílem tohoto kroku je ukázat vztahy mezi datovými skupinami a procesy v informačním systému.
Děláme to proto, abychom zjistili, jak jsou data vytvářena a užívána jednotlivými procesy, a abychom
se ujistili, že všechny datové skupiny a procesy byly identifikovány, a že jenom jeden proces vytváří
danou datovou skupinu.
Provedeme to opět formou vazbové matice proces/datová skupina. Jako symboly příslušné vazby
můžeme použít např. písmena:
T pro tvorbu
U pro užití dat
Postupujeme v následujících krocích:
1. Procesy zapisujeme do řádků pod sebe v pořadí, v jakém jsou spojeny s životním cyklem výrobku,
tj. začneme procesem strategického plánování a končíme obslužnými správními procesy.
2. Datové skupiny řadíme horizontálně do sloupců tak, že začneme prvním procesem v pořadí a
zapíšeme všechny datové skupiny, které jsou tímto procesem tvořeny. Do průsečíkového políčka
zapíšeme symbol T, protože se jedná o vytváření datové skupiny. Pak pokračujeme dále v pořadí
procesů a zařadíme další datovou skupinu, označíme políčko T (případně políčka , pokud proces
vytváří více skupin). Tak pokračujeme dále, až jsou všechny datové skupiny zařazeny. Pokud je to
102
možné, tak k sobě seskupujeme datové skupiny podle entit, ale vždy dbáme na to, aby v řádku
předcházelo T.
3. Po řádcích umístíme U do sloupců těch datových skupin, které jsou užívány pro proces uvedený
v daném řádku.
4. Prověříme, že všechny datové skupiny máme zaneseny v tabulce, a že v každém sloupci je jen
jedno T.
Výše uvedeným postupem vytvoříme vazbovou matici, kde symboly T budou soustředěny okolo
hlavní diagonály, což nám dává jistou záruku homogenního toku dat v souhlase s životním cyklem a
umožňuje nám i seskupovat datové skupiny do dílčích databází se společnou vazbou na přirozené
skupiny procesů. Schematická ukázka takové vazbové matice proces/datové skupiny je na obr. 5-6.
18.6 Analýza dosavadní podpory podnikových činnosti IT
Východiskem tohoto kroku je inventura dosavadních aplikací IT v podniku. Ty jsou buď soustředěny
v dosavadním obyčejně centrálně budovaném automatizovaném informačním systému (AIS/ASŘ),
nebo jsou rozptýleny v isolovaných aplikacích (např. automatizace inženýrských prací – AIP apod.).
Inventuru provádíme proto na úrovni samostatných systémů, či subsystémů, které pokrývají určitou
oblast činnosti podniku.
Výsledkem tohoto kroku je zachycení dosavadní počítačové podpory IS. Přitom se zajímáme o to, jak
jsou stávajícími aplikacemi IT podporována jednotlivá organizační místa v podniku, jednotlivé
podnikové procesy, a jak jsou počítačově zpracovávány jednotlivé datové skupiny. Rozlišujeme, zda
organizační místo, proces, či datová skupina jsou podporovány uspokojivě (úplně), částečně, či vůbec
ne, případně zda je již rozpracována nějaká aplikace, kde jsou redundance a kde by bylo možno využít
stávající zpracování i pro další organizační místa, či podnikové procesy.
Opět k tomu nejlépe využijeme techniky vazbových matic systém/organizace, systém/proces a
systém/data..
18.7 Projednání analýzy s vedoucími pracovníky podniku
Postup metody BSP shora dolů nám velí, že musíme projednat dosavadní výsledky analýzy
s příslušnými liniovými vedoucími. Účelem této etapy je uzavřít analytickou část studie. K tomu
potřebujeme:
odsouhlasit si s vedením podniku provedenou klasifikaci (rozlišení) podnikových procesů,
organizačních jednotek a datových skupin včetně jejich vzájemných vztahů
vyjasnit si budoucí směry podnikání a jejich dopad na informační systém (priority)
identifikovat a zaznamenat podnikové problémy, které se vztahují k podnikovým procesům a
datovým skupinám
kvantifikovat – tam kde je to možné – hodnoty přínosů z vyřešení těchto problémů
K projednání s vedoucími pracovníky je nejlépe připravit si sadu otázek, na které by měli tito
pracovníci písemně odpovědět předem. Otázky by měly být zhruba takové, jaké jsou uvedeny v Tab.
Jaké jsou Vaše cíle?
Jaké jsou Vaše odpovědnosti?
Jaká opatření (rozhodování) provádíte?
Jaké informace potřebujete?
Jaké jsou Vaše problémy?
Jaké změny, které ovlivní podnik vidíte do budoucnosti?
Jaké jsou kritické faktory bránící Vám v úspěchu?
Jaká informace je pro Vás nejužitečnější?
Jak hodnotíte Vaši dosavadní informační podporu z hlediska adekvátnosti, hodnoty, včasnosti,
konsistence, nákladů, objemu apod.?
Jaký je Váš názor na tuto studii?
103
Je samozřejmé, že se snažíme všechny odpovědi okamžitě promítat do již dříve vytvořených analýz
procesů, organizačních jednotek a datových skupin s cílem jejich budoucího upřednostnění.
18.8 Zpracování výsledků analýzy
Jelikož studijní tým v předchozích analytických etapách shromáždil ohromné množství podkladů,
musí je zpracovat tak, aby z nich mohl určit architekturu budoucího IS podniku. Ke všem problémům
a možnostem odhaleným při analýze musí zaujmout nějaké stanovisko a udělat závěry. Zejména se
zaměřuje na tyto kategorie problémů:
správnost stanovení cílů pro podnik jako celek i pro jeho hlavní funkce, jejich hierarchická
strukturalizace a jejich vztah k současnému informačnímu systému, zejména pokud jde o
schopnost poskytovat informace k měření stupně dosahování těchto cílů
organizace podniku, zejména to, zda se v ní odráží řídící filosofie podniku, zda jsou správně
rozloženy pravomoce a odpovědnosti, zda jsou zřejmé změny v organizaci, a jaký mají dopad
na IS
plánování v podniku – do jaké míry je formalizováno,a zda lze automatizovat, jaký je vztah
mezi dlouhodobým, krátkodobým a operativním plánováním, jak je plánování závislé na
informačním systému, kde a jak jsou používány počítačové modely apod.
sledování výsledků, jak je efektivní dosavadní systém kontroly výsledků, jaká jiná opatření by
byla možná pro jeho zlepšení a jaká další data by k tomu byla potřebná
vlastní provádění podnikových operací jako jsou prodeje, výroba, nákupy, technická příprava
výroby apod. z hlediska jejich hlavních nedostatků způsobujících nízkou produktivitu, vysoké
náklady, dlouhé průběžné doby atd.
dosavadní podpora výpočetní technikou, zejména jaké informační potřeby nejsou dosud
uspokojovány, jaký je stav současných dat zpracovávaných počítačem z hlediska jejich
dostupnosti, přesnosti, formátů, redundance, zpoždění apod., jaká je současná architektura IS,
tj. stupeň její integrace, konsistence, centralizace, distribuce, proniknutí do různých úrovní
řízení, interface s konečným uživatelem atd.
Je zřejmé, že některé problémy se objeví ve více kategoriích, zatímco některé problémy budou
izolované v jedné kategorii. Pro následný krok upřednostnění nás nejvíce zajímá seřazení problémů
podle počtu dotčených kategorií (čím většího počtu kategorií se problém dotýká, tím bude jeho řešení
naléhavější), a zejména pak podle podnikových procesů, se kterými jsou tyto problémy spjaty.
18.9 Stanovení priorit v informační architektuře
V tomto kroku musí studijní tým stanovit, v jakém pořadí se bude systém budovat. Vychází přitom ze
závěrů minulého kroku a z naléhavosti požadavků řídících pracovníků zlepšit určitý podnikový proces.
Prvním krokem v této etapě je rozhodnutí o kritériích, která budou použita pro upřednostnění
jednotlivých aplikací IT. měli bychom přitom zohlednit běžná kritéria, která používá vedení podniku
při rozhodování o jakýchkoliv jiných investicích, protože se stále jedná o jedny peníze, které musejí
přinést efekt. V úvahu bereme následující hlediska:
1. Potencionální přínosy, a to krátkodobé, přímo měřitelné klasickými ekonomickými ukazateli
návratnosti investic, dlouhodobé, měřitelné nepřímo pomocí odhadů a přínosy ve sféře zvýšení
konkurenceschopnosti.
2. Vyvolané změny v podniku, zejména to jak určitá aplikace IT ovlivní činnost jednotlivých
útvarů podniku, kolika útvar a pracovníků se dotkne a jakým způsobem, zda vyřeší palčivé
problémy chodu podniku, a zda zlepší kvalitu výrobků, či služeb zajišťovaných podnikem.
3. Pravděpodobnost úspěchu, do které zahrneme především podnikové klima, tj. zda v podniku
jsou zaměstnanci nakloněni „novotám“, technickou a organizační náročnost aplikace, dobu
implementace (čím rychleji, tím lépe) a výchozí podmínky pro ni, případně i omezenost
finančních zdrojů při postupném financování výstavby aplikace. Klademe si především následujíc
otázky:
Jsou zde nějaké skryté faktory, které by měly být uvažovány?
104
Jak dlouho bude výstavba a implementace trvat?
Jedná se o nákladnou aplikaci, která je výrazně závislá na dostupných finančních prostředcích?
Jak budou lidé aplikaci přijímat?
4. Požadavek (naléhavost) aplikace ze strany uživatelů, a to zejména ve srovnání se stávající
aplikací (pokud existuje), vztahy k jiným aplikacím a jejich ovlivnění (zda se uplatní synergický
efekt, či naopak může dojít ke zhoršení funkce jiných aplikací), počet uživatelů (čím více, tím
lépe).
Druhým krokem je potom volba metody hodnocení a vytvoření pořadí aplikací od nejdůležitější
k nejméně významné. Obyčejně se jedná o klasický vícekriteriální problém rozhodování, který je
všeobecně znám z teorie řízení [18], kde použijeme jakoukoliv metodu založenou na kombinaci
objektivního měření a subjektivního hodnocení s využitím různých systémů škálování, resp. bodování.
Pro větší názornost při presentaci výsledků se doporučuje grafické zobrazení výsledků hodnocení
např. formou ukázanou na obr. 5-8., kde při hodnocení byla použita pro každé hledisko desetibodová
stupnice. Maximální možný součet bodů za všechna čtyři hlediska je tedy 40.
Třetím krokem musí být návrh toho, jak danou aplikaci IT implementovat, tj. rozhodnout na základě
analýzy stávajícího stavu kapacit pro výstavbu IS podniku a úrovně jejich řízení (Information
Ressource Management – IRM) [62], zda bude koupena jako hotová aplikace, či její výstavba bude
zadána externí organizaci, případně si ji vyvineme sami.
18.10 Návrh řízení informačních zdrojů
Jak již bylo konstatováno, informace se stávají základním zdrojem podnikové činnosti, a proto je třeba
je i odpovídajícím způsobem řídit. Tento úkol je ve většině podniků svěřen Útvarům pro IS (dříve
ASŘ), či jiným k tomu pověřeným oddělením, komisím nebo samostatným pracovníkům. (Této
problematice je věnována blíže samostatná kapitola knížky.) Studijní tým musí posoudit, zda
výstavba navrhované informační architektury je zabezpečena adekvátním systémem řízení a
odpovědností, a když ne, tak předložit potřebné návrhy.
Studijní tým musí tedy shrnout své dosavadní výsledky do podoby nároků na peníze, pracovní
kapacity, hardware, aplikační software, atd. To jsou všechno zdroje, ze kterých bude budován IS
podniku.
18.11 Tvorba doporučení
Výsledkem tohoto kroku je konečné doporučení způsobu řešení výstavby IS a stanovení prováděcího
plánu pro jeho výstavbu. Doporučení by mělo pokrýt tři oblasti, a to:
návrh architektury informačního systému, tj. jeho hardwarové zabezpečení a strukturalizaci do
subsystémů
způsob řízení informačního systému, zejména řízení a správu dat
pořadí,v jakém bude systém vyvíjen
18.12 Prezentace výsledků
Studijní tým musí získat konečné požehnání od sponzora, tj. od vrcholového vedení podniku tak, aby
se jejich doporučení i prováděcí plán staly závaznými pro celý podnik. Presentace by měla být jak
písemná, tak i ústní.
18.13 Návrh dalších opatření
Vzhledem k tomu, že výstavbou IS bude dotčena řada lidí v podniku, je třeba zakončit studii návrhem
následných organizačních opatření, zejména odpovědnostmi za implementaci systému.
105
19 Process Quality Management - PQM
19.1 Principy a postup metody PQM
Metoda PQM byla rovněž vyvinuta firmou IBM v návaznosti na metodu BSP a byla již úspěšně
aplikována v mnoha podnicích a firmách v západní Evropě i ostatních průmyslově vyspělých zemích
světa. Zaměřuje se zejména na zkoumání poslání, cílů a faktorů úspěchu podniku jako celku a z toho
vyplývajících podnikových procesů. Tak lze dosáhnout toho, že definované procesy opravdu
odpovídají stanovému poslání podniku, pomocí faktorů úspěchu je možno měřit míru jejich přispívání
k naplnění podnikových cílů, a tak nalézt procesy kritické, rozhodující pro úspěšný provoz organizace.
Následné stanovení pořadí důležitosti investic do IT jakož i hrubá představa o konkrétních aplikacích z
metody PQM přímo vyplývá a je její nedílnou součástí. Metoda PQM tedy patří mezi metody
posupující při analýze podniku „odshora dolů“ (top-down) a jejím výsledkem má být zhodnocení
stávajících používaných IT aplikací a návrh na jejich případnou reorganizaci. Vedle důsledků pro
plánování a řízení informačních technologií však z analýzy organizace touto metodou často vyplynou i
důsledky pro vlastní systém řízení podniku.
Metoda PQM si tedy klade za cíl především:
určit klíčové, rozhodující procesy pro úspěch provozu organizace
zhodnotit stávající investice do IT
posoudit kvalitu jejich dosavadního plánování
identifikovat potřeby nových investic do IT
stanovit pořadí jejich důležitosti
zajistit vhodnost nových aplikací IT pro podnik a jejich koordinaci s aplikacemi již
používanými
Metoda je koncipována pro použití vrcholovým vedením podniku formou týmové práce. Tento aspekt
je velmi důležitý a na výběru členů týmu o značné míry závisí úspěch celé práce. Tým by se měl
skládat přibližně z deseti členů. Ze zkušeností vyplývá, že v tomto počtu je obvykle spolupráce
nejsnadnější. Menší počet se jeví jako nedostatečný, při větším počtu členů týmu může naopak
docházet ke komplikacím s udržením kontroly a koordinace práce jednotlivých členů. Členy týmu by
měly být klíčové osobnosti managementu organizace zainteresovaných organizačních jednotek. Ti si
samozřejmě mohou určit pomocníky a osobní asistenty, kteří by však neměli mít přístup na plánovací
a kontrolní schůzky. Při projednávání jednotlivých dílčích problémů je velmi vhodné přizvat ad hoc ke
spolupráci ty pracovníky nebo experty, kteří mají k dílčímu problému co říci.
Vedoucím týmu je tzv. „sponzor“, osoba odpovědná za naplnění poslání podniku. Předsedá všem
schůzím a řídí diskusi, musí mít vždy přehled o momentálním stavu prací, dbá na to, aby každá schůze
měla jasný cíl a je odpovědný za plánování celého průběhu práce. V týmu by neměl chybět člen mající
zkušenosti s metodou PQM a navrhováním informačních systémů všeobecně, tzv. „koordinátor“. (V
anglickém originálu název této funkce zní „facilitator“ ze slovesa ‘facilitate‘, což znamená ‘usnadnit‘),
jehož úlohou j asistovat sponzorovi při použití metody PQM, při práci s týmem a dohlížet na správné
provádění metodologie. Koordinátor je obvykle externí pracovník, avšak může to být i člověk
z vlastního Ústavu pro IS.
Rozhodující pro úspěšné použití metody PQM je ovšem zajištění spolupráce v rámci týmu. Členové
musí mít zájem na splnění společného úkolu a nikoli na prosazování svých osobních a „politických“
zájmů. Rovněž časové plánování schůzí je nutno provádět tak, aby se jich mohli zúčastnit všichni
odpovědní členové týmu. Nevyhovuje-li dohodnutý termín některému z odpovědných pracovníků, je
lépe schůzi odložit na dobu, kdy budou mít čas všichni. V praxi se mnohokrát projevilo, že kdy
kdykoli na schůzi chyběl některý významný člen týmu a odsouhlasilo se něco bez něho, vznikaly
později potíže a komplikace.
Před samotným začátkem práce by měl koordinátor seznámit sponzora s metodou PQM, s jejími cíly,
použitím v praxi a pracovními postupy. Na ustavující schůzi se především provede definitivní výběr
106
týmu, analyzují se předchozí práce a studie provedené v oblasti plánování IT v organizaci, zejména
z hlediska možnosti jejich případného využití v současném projektu. Aby se zabránilo nežádoucí
duplicitě prací již vykonaných, koordinátor seznámí členy týmu s metodologií PQM a stanoví se hrubý
časový rozvrh prací. Je dobré načrtnout schémata hlavních skupin, se kterými přijde tým v průběhu
práce do styku, a to jak vnitřních, tak vnějších. Sponzor je rovněž odpovědný za technické
zabezpečení všech plánovacích a kontrolních schůzek.
19.2 Definování poslání podniku
Poslání tak, jak je chápáno metodou PQM, vyjadřuje vysvětlení toho, proč vlastně celá organizace
existuje, co je hlavním jejím smyslem. Představuje jakousi vůdčí směrnici pro řídící pracovníky
organizace i všechny jejich podřízené, jsou s ním seznámeny všechny interní skupiny, a tam, kde je to
třeba, rovněž zákazníci, dodavatelé a obchodní partneři.
Formulace poslání pak je kolektivní záležitostí. Je bezpodmínečně nutné, aby se jeho tvorby zúčastnili
opravdu všichni členové vrcholového řízení organizace, aby se s ním všichni ztotožnili, aby ho „přijali
za své“.
Při vlastní formulaci poslání je třeba dodržet několik základních principů:
mělo by být krátké, maximálně 3 – 4 věty
musí být jasné, srozumitelné, vylučující dvojsmyslný výklad
může obsahovat formulace jako …dělat …něco … pro … aby … cílů …bylo … dosaženo …
Někdy management podniku formuluje celou sadu fundamentálních elementů, tvořících „pozadí
poslání a vyjadřujících „nejvyšší principy“ nebo základní kameny podnikové víry“. Jejich příkladem
může být:
kvalita a bezpečnost jsou dominantní principy ve všem, co děláme
lidé jsou naším nejdůležitějším zdrojem
služba našim zákazníkům je pro nás prvořadý úkol apod.
V některých případech řídící týmy dokonce sestavují jakési „slovníky pojmů“, které do hlubších
detailů rozvádějí význam klíčových výrazů poslání.
Každé poslání však musí mít konkrétního „vlastníka“, pracovníka zodpovědného za jeho naplnění. Je
to obvykle nejvyšší vedoucí pracovník dané organizační jednotky, například výkonný ředitel
společnosti, vedoucí divize nebo třeba vedoucí projektu, zkrátka pracovník – člen týmu s nejvyšší
zodpovědností za řízení týmu. V terminologii metody PQM plní tuto funkci sponzor.
Příklady poslání a jejich vlastníků:
Představenstvo národní společnosti má za úkol uspokojit požadavky zákazníků
v celosvětovém měřítku jako dodavatel širokého sortimentu materiálů a systémů založených
na účelových aplikacích poznatků nauky o materiálech.
Ředitel výrobního podniku má za úkol podporovat výrobky a služby schopné konkurence po
stránce funkčnosti, ceny, kvality a dodání, a zajistit tak uspokojení zákazníka.
Vedoucí personálního oddělení má za úkol podporovat vedení podniku v oblasti péče
o zaměstnance, jejich evidence i náboru, popřípadě i jejich vyškolování tak, aby bylo dosaženo
podnikových cílů.
19.3 Určení dominantních vlivů
Stanovením poslání tým přesně definuje smysl existence podniku. V dalším kroku pak identifikuje
dominantní vlivy, které nejvíce ovlivňují naplnění poslání a tím i celý výsledek činnosti podniku.
Velmi vhodnou metodou pro určování dominantních vlivů bývá práce formou brainstormingu. Každý
člen týmu může uvést jakýkoli faktor, o kterém se domnívá, že ovlivňuje dosažení poslání. Často se
totiž stává, že právě při takovémto kolektivním zamyšlení nad problémem si jednotliví členové týmu
přesně uvědomí a formulují myšlenky., které „nosili někde v hlavě“, ale nikdy „nebyl čas“ je takto
vyjádřit. Často dojde i k překvapujícím zjištěním, co si vlastně jednotliví spolupracovníci mysleli o
věcech, které se zdály být jednoznačné a samozřejmé. Pro úspěch skupinové diskuse – brainstormingu
107
– je však velmi důležité vytvořit otevřenou pracovní atmosféru, kde jsou potlačeny do pozadí emoce,
osobní ambice, sympatie a antipatie, „politické“ a „mocenské“ vztahy, aby každý člen týmu mohl
maximálně přispět k dosažení konečného výsledku bez ohledu na podřízenost nebo nadřízenost vůči
ostatním týmu. Zajištění takového společenského klimatu je ovšem velmi náročným úkolem sponzora,
který takovou diskusi řídí.
V průběhu určování dominantních vlivů může také dojít k drobným zpětným úpravám poslání, jeho
jemnému doladění apod.
Příklady dominantních vlivů:
ziskovost zákazníka
legislativní podmínky
budoucí poptávka
ekologické souvislosti
omezování nákladů
vnitropodniková komunikace
styl řízení
služby zákazníků
obchodní bariéry
výrobní kapacity
konkurence
informace vedení
školení zaměstnanců
důvěra zaměstnanců
Faktory ovlivňující činnost podniku jsou různé povahy. Některé z nich budou mít přímou vazbu na
konkrétní kritické faktory úspěchu, zatímco jiné jsou nezávislým projevem okolí, které nelze ovlivnit.
Dobrým nástrojem k zobrazení dominantních vlivů z poněkud odlišného úhlu pohledu může být
rovněž Porterův model nebo analýza matice S.W.O.T. (viz dále).
Porter uvádí pět základních konkurenčních sil, se kterými se podnik musí vyrovnat:
1. Síla nově vstupujících konkurentů do dané oblasti podnikání, jinak též výška vstupní bariéry
odvětví nebo trhu pro nově vstupující podnikatelské subjekty.
2. Síla zákazníků – do jaké míry jsou naši zákazníci závislí na nás a do jaké míry my na nich.
3. Síla dodavatelů – analogicky jaké možnosti volby dodavatelů a jejich případné změny
v budoucnu máme.
4. Hrozba náhradních výrobků nebo služeb – příkladem náhradního výrobku pro automobil
v podmínkách města může být motocykl, elektronická pošta může nahradit klasický koloběh
papíru apod.
5. Intenzita stávajícího konkurenčního boje v odvětví.
Na základě analýzy tohoto modelu nabízí Porter tři základní strategie k překonání negativních účinků
těchto sil:
a) strategie odlišení – představením výrobku odlišného od ostatní nabídky (a tedy „lepšího“
v očích zákazníků) může podnik dosáhnout vyšších cen, snížit vliv síly zákazníků apod.; tato
strategie je podle Portera v podnikatelské praxi nejoblíbenější
b) strategie nízkých nákladů – při postupu podle této strategie podle Porterova varování nestačí
být jedním z výrobců s nízkými náklady, protože nejsou-li naše náklady nejnižší, hrozí
uvíznutí „uprostřed“ bez reálné schopnosti konkurovat
c) strategie cíleného trhu – tržní mezery (niky); podnik orientující se na takové mezery na trhu
může navíc účinně spojit výhody strategie odlišení a nízkých nákladů
Analýza matice S.W.O.T. nám zase umožňuje pohled na vlastní podnik z hlediska jeho předností a
silných stránek (Strenghts), slabin (Weaknesses), příležitostí trhem nabízených (Opportunities) a
ohrožení (Threats).
108
Prostým zápisem faktorů podle výše uvedené klasifikace si všichni členové týmu uvědomí, v jakém
prostředí organizace vyvíjí svou činnost, čeho chce dosáhnout a jak k tomu může přispět informační
technologie.
19.4 Definování kritických faktorů úspěchu
Kritické faktory úspěchu (Critical Success Factors CSF) představují několik oblastí činností, kde
uspokojivé výsledky zajistí organizaci úspěšné fungování v konkurenčním prostředí. Jinými slovy to
jsou klíčové oblasti, kde musí všechno fungovat správně, aby podnik splnil svá předsevzetí a záměry.
Kritické faktory úspěchu vyplývají z výsledků skupinového rozboru dominantních vlivů.
Metodu analýzy CSF pro definování informačních potřeb řídících pracovníků použil poprvé J.
Rockart. Rockart rozlišuje čtyři zdroje CSF:
vlastní specifické podmínky podnikové činnosti dané oborem činnosti podniku
postavení podniku v rámci daného obou činnosti
okolí podniku a jeho zákaznické trendy, ekonomické a politické faktory země apod.
okamžité organizační faktory, které normálně nevyžadují zvláštní pozornost, ale které jsou
právě v důsledku vzniklé situace důležité
Dále Rockart rozlišuje dva typy CSF, a to:
sledovací, které jdou ruku v ruce s podnikovými událostmi
výstavbové, které způsobují změny v podniku a jsou iniciovány řídícími pracovníky
Čím výše se nacházíme v řídící hierarchii, tím více přibývá výstavbových CSF. Je samozřejmé, že
CSF se mění v čase, a že je tudíž třeba je čas od času revidovat a konfrontovat se stávajícím
informačním systémem.
Zkušenosti s využitím metody PQM při řešení mnoha studií ukazují, že optimální počet kritických
faktorů úspěchu je 4 až 6, v žádném případě by jich však nemělo být více než 8. Tento počet je
odvozen z počtu úkolů, které může tým zvládnout současně. V organizacích, které se nacházejí
v krizové situaci, může tým definovat menší počet skutečně kritických faktorů úspěchu, tj. 3 až 5.
Každý faktor by se měl týkat jediného problému. Není dobré slučovat dohromady dva nebo více
navzájem odlišných problémů do jednoho faktoru, například pomocí spojek a, jakož, i apod. Některé
týmy se mohou dostat do pokušení redukovat tímto způsobem celkový počet kritických faktorů
úspěchu, ovšem je třeba takovému pokušení nepodlehnout.
Kompletní sada kritických faktorů úspěchu bývá obvykle kombinací faktorů taktických a
strategických. Jejich vzájemný poměr závisí v hlavní míře na povaze činnosti organizace týmem
řízené. Generální ředitelství koncernového podniku bude klást větší důraz na strategické cíle, zatímco
vedení prodejního oddělení se zaměří spíše na taktické kritické faktory. Pomineme-li však jedno
opomenutí strategických cílů a přílišná koncentrace pozornosti na operativní rozmach organizace a
vzápětí její strmý pád (tzv. supernova – efekt). Naopak zanedbání taktických kritických faktorů může
přivodit kolaps organizace plánující nádhernou, ale příliš vzdálenou budoucnost. Konečná formulace
kritických faktorů úspěchu musí být stejně jako poslání akceptována všemi členy týmu.
Příklady kritických faktorů úspěchu:
zajištění efektivní spolupráce se všemi klíčovými zákazníky
přesná znalost kritérií, podle kterých nás hodnotí naši zákazníci
zvýšení obecného povědomí o naší organizaci
zajištění dostatečných dodávek komponentů splňujících naše kvalitativní požadavky
Každý z kritických faktorů úspěchu by měl být podmínkou nutnou k úspěšnému naplnění poslání
podniku. Splnění celého souboru faktorů pak musí být zároveň podmínkou postačující. Vhodnou
kontrolou nezbytnosti kritických faktorů je ověření, zda nesplnění některého z nich bude opravdu
příčinou nesplnění poslání.
Je nutné neustále porovnávat faktory při jejich specifikaci s posláním. Obsahuje-li poslání slova „stát
se celosvětově rozšířeným dodavatelem širokého sortimentu“, pak kritický faktor „stát se světově
109
rozšířeným dodavatelem širokého sortimentu“ je bezcenný, neboť neříká nic o tom, jak konkrétně
tohoto poslání dosáhnout, a co je skutečně kritické pro to, aby se tak stalo. Jinými slovy, kritické
faktory by neměly být jen rozpracovanou kopií poslání.
Všechny kritické faktory jsou si rovny. Jejich splnění může být různě časově náročné. Ovšem musí
platit, že pokud nebudou uspokojivě naplněny všechny faktory, nebude splněno ani poslání
organizace.
Řídící tým musí rovněž vzít v úvahu, že kritické faktory úspěchu jsou definovány „teď a tady“, to
znamená, že každá případná změna poslání nebo i jen okolního prostředí by měla vyvolat jejich revizi.
Taková kontrola kritických faktorů úspěchu by se ostatně měla v každém případě pravidelně opakovat.
Nyní tedy tým zná poslání i kritické faktory úspěchu, jejichž dosažení je pro naplnění poslání
nezbytné. Faktory však není možné přímo ovládat, popisují jen stav, jehož musí být dosaženo a
měřítko pro hodnocení, jak jsou v organizaci realizovány vlastní podnikové procesy.
19.5 Stanovení podnikových procesů
Podnikovými procesy rozumíme sadu souvisle navzájem navazujících aktivit přesahujících funkční
hranice organizace, které musí podnik provádět, aby zabezpečil své efektivní fungování. Například
aktivity nutné pro dodání výrobku na trh, pro správné provádění finančních transakcí, pro zajištění
dodávek komponent a podobně. na rozdíl od kritických faktorů úspěchu, které představují „rizikové
oblasti“, jsou podnikové procesy faktické činnosti, u nichž má smysl zkoumat toky vstupních a
výstupních informací, vzájemnou návaznost a tak dále. Zpočátku členové týmu obvykle neuspořádaně
kupí procesy jako „údržba“, „prodej“ či fakturování“, takový popis ovšem není příliš užitečný. Metoda
PQM proto doporučuje dodržet při označování podnikových procesů několik základních principů:
popis procesu by měl obsahovat spojení sloveso + podst. jméno
každý proces by měl mít svého vlastníka zodpovědného za realizaci procesu
vlastník procesu by měl být členem týmu a účastnit se definování kritických faktorů úspěchu
jeden vlastník by měl zodpovídat za provádění tří, maximálně čtyř procesů
Důležité je, aby kvalit provádění procesů byla měřitelná. Je rovněž důležité si uvědomit,že sloves jako
„redukovat“, „zvýšit“, „optimalizovat“ nepopisují podnikové procesy, nýbrž jejich žádoucí výsledky.
Například „optimalizovat zásoby“ popisuje spíš záměr, zatímco řídící tým by se měl soustředit spíše
na procesy, které k optimalizování zásob vedou, například sledovat materiálový tok skladem, plánovat
výrobu apod. Dobrou kontrolou správné formulace podnikových procesů bývá otázka, kdo z členů
týmu má zájem stát se vlastníkem takového procesu. O procesy „omezit režii“, „zvýšit disciplínu
zaměstnanců“ atd. se obvykle hlásí jen málo dobrovolníků. Tým by se měl také vyhnout přídavným
jménům a příslovcím jako „účinně“, „přesně“, „správně“, „efektivní“ apod., neboť opět popisují spíše
kýžený výsledný stav než podnikový proces.
19.6 Přiřazení kritických faktorů úspěchu podnikovým procesům
Jak již bylo řečeno, kritické faktory úspěchu představující stav, jehož má být dosaženo, můžeme
ovládat a naplnit pouze prostřednictvím podnikových procesů. Proto je nutno provázat podnikové
procesy s kritickými faktory, k čemuž nám nejlépe poslouží jejich vynesení do tabulky (matice
vzájemných vazeb).
Ilustrativní ukázka je vzata z analýzy prováděné pro obchodní společnosti HG GROUP, která je
součástí společnosti HG HOLDING. Posláním společnosti HG GROUP je vyrábět dostatečné kvalitní
výrobky lehkého strojírenství cenově dostupné co nejširšímu okruhu zákazníků. Hlavním předmětem
podnikání (LOB) je výroba jízdních kol. Pro FG GROUP byly stanoveny kritické faktory úspěchu:
F1 – efektivní a fungující systém řízení výroby
F2 – dostatek vlastních výrobních prostor
F3 – fungující marketingový systém spojený s HGTRADING
F4 – důvěryhodnost pro poskytování bankovních úvěrů
F5 – kvalitní, konkurenceschopné výrobky
110
F6 – nízké vlastní náklady výroby
Matice vazeb má dvě části – část detailní, určenou pro vlastní zachycení vzájemných vazeb kritických
faktorů a podnikových procesů, a část analytickou, která umožňuje stanovit relativní důležitost
jednotlivých procesů a poskytuje základnu pro určení nejkritičtějších procesů.
Při vyplňování matice nejprve do tabulky vyneseme kritické faktory (vodorovně) a procesy (svisle).
Ke každému kritickému faktoru pak hledáme procesy, jejichž dobré provádění zajistí splnění
kritického faktoru. Poté následuje test úplnosti: Jsou tyto procesy opravdu postačující ke splnění
kritického faktoru? V případě potřeby je nutno dodefinovat další procesy a určit jejich vlastníky.
V této fázi se práce týmu stává opravdu tvůrčí, tým objevuje nové úhly pohledu, zjišťuje, co skutečně
musí být prováděno navíc oproti současnému stavu. Celý postup opakujeme analogicky pro všechny
kritické procesy.
Analytická část matice obsahuje tři základní indikátory relativní důležitosti procesů:
1. Součet – čím více kritických faktorů úspěchu ten který proces zasahuje, tím bude potenciálně
důležitější. První sloupec analytické části matice proto zachycuje počet faktorů procesem
ovlivněných.
2. Kvalita procesu je vyjádřena ve druhém sloupci pomocí pětistupňové známkovací škály.
A – proces nepotřebuje zlepšení
B – proces je prováděn dobře, drobná zlepšení přicházejí v úvahu
C – funkce je zajištěna, ale potřebuje výrazně zlepšit
D – proces byl zaveden, ale nefunguje
E – proces je ve stadiu zavádění
3. Zdroje – tento sloupec pak indikuje tzv. „procesy – spotřebiče“, čili takové procesy, na jejichž
provádění se spotřebovává velké množství zdrojů.
Obyčejně k analytické matici připojujeme ještě dvě hlediska hodnotící IT. Prvním z nich je Význam
IT, který provádí odpovědný řídící pracovník na základě své vlastní dosavadní zkušenosti a svých
představ o funkci IT v podniku. obvykle vystačíme s obvyklou školskou klasifikační stupnicí:
A = výborně
B = velmi dobře
C = dobře
D = uspokojivě
E = nedostatečně
Druhým doplňujícím hlediskem je Technická kvalita úrovně dosud používané IT pro proces.
Toto hodnocení provádí odborník na výpočetní techniku podle stejné stupnice jako byla použita pro
VÝZNAM. Technickou kvalitou se v tomto případě rozumí nejen hardware, ale především stáří
softwarových produktů, náklady nutné na údržbu systémů, možnosti rozšíření těchto systémů
produktů, náklady nutné na údržbu systémů, možnosti rozšíření těchto systémů atd. Tato analýza může
mnohé odhalit a překvapit vedení podniku, když se např. zjistí, že jejich významný a pro podnik
životně důležitá aplikace IT nemá žádnou dokumentaci, je stará více než 20 let a prošla za tuto dobu
nezjistitelným počtem úprav.
19.7 Určení nejkritičtějších procesů a priorit IT
Nyní tedy máme pohromadě všechna potřebná data i kvalitativní podklady pro analýzu důležitosti
procesů a nalezení skutečně zásadních problémů IT v podniku, na jejichž vyřešení záleží naplnění
nebo nenaplnění poslání.
Údaje získané v analytické části matice vazeb pro názornost vynášíme do tzv. přehledové sítě. Je to
jakási mapa důležitosti nebo kritičnosti procesů. Na osu x vynášíme kvalitu procesů, na osu y počet
kritických faktorů procesem ovlivněných, procesy – spotřebiče – označujeme kroužkem. V levém
horním kvadrantu se potom zobrazí skutečně kritické procesy a záleží na zkušenostech a přehledu
členů týmu, jak velkou zónu nejkritičtějších procesů stanoví. Zlepšení provádění procesů může mít za
111
následek pouze zlepšení jeho kvality, tedy jeho případný posun po vodorovné ose, neboť nelze snížit
počet kritických faktorů procesem ovlivňovaných. Důležité je také pamatovat na to, že procesy mají
samovolnou tendenci zhoršovat svou kvalitu, není-li jim věnována náležitá pozornosti, a proto nesmí
být podceněna ani důležitost procesů zdánlivě bezproblémových.
Rozdělení podnikových procesů na zóny určující kritičnost procesů je nejčastěji používaným
postupem při práci týmu. Některé týmy dávají přednost jinému postupu, např. mohou přiřadit číselné
hodnoty (váhy) každému stupni kvality procesu (A = 1, E = 5 atd.), tuto hodnotu násobit počtem CSF
faktorů a podle hodnoty tohoto součinu se rozhodnout o kritičnosti procesu.
19.8 Portofolio analýza
Nejčastěji zaměřují manažerské týmy svou pozornost na procesy zóny 1, tj. na nejkritičtější procesy.
Jelikož jsou tyto procesy již známy, může se management soustředit na realizaci opatření vedoucích
k jejich zlepšení. Pro naplánování a řízení investic by měly být použity obvyklé metody s tím, že pro
konečné rozhodnutí o plánu rozvoje IT, tedy o postupu investic do IT, nám může posloužit portofolio
analýza. Za tím účelem si sestavíme matici „význam a kvalita IT“.
Samostatné analýze by měly být podrobeny procesy, které v matici vůbec uvedeny nejsou, protože
nemají žádnou počítačovou podporu. Ty by měly mít vůbec nejvyšší prioritu, pokud mají vysokou
kvalitu, tj. vliv na kritické faktory, a pokud se ukáže, že by k jejich zlepšení mohlo dojít aplikací IT.
Po nich se na druhém místě důležitosti nacházejí procesy v 1. kvadrantu.
19.9 Shrnutí několika zásadních pravidel metody PQM
1. Nezačínejte žádnou plánovací schůzi PQM, dokud koordinátor podrobně neinformoval
sponzora o používání a možnostech metody PQM.
2. Nezačínejte žádnou plánovací schůzi, pokud některý z klíčových členů týmu není přítomen.
3. Poslání musí být stanoveno a formulováno předtím, než se přistoupí k dalším fázím
metodologického postupu, jinak hrozí, že celá další práce bude zbytečná.
4. Zajistěte, aby určení dominantních vlivů bylo kolektivním dílem za přispění všech členů týmu,
aby nebyla opomenuta žádná maličkost reálně ovlivňující poslání.
5. Počet kritických faktorů úspěchu musí být takový, aby každý z nich byl unikátní podmínkou
nutnou a všechny dohromady pak postačující ke splnění poslání.
6. Každý kritický faktor musí mít svého vlastníka, který patří mezi členy týmu a zúčastnil se
definování kritických faktorů úspěchu.
7. U každého kritického procesu uvažte, které podnikové procesy ho ovlivňují, a v případě
potřeby přidejte nový proces.
8. Počet nejkritičtějších procesů musí být velmi omezený, aby se poslání nestalo nesplnitelným
pro příliš mnoho nejkritičtějších procesů.
9. Pro vypracování a implementaci projektů na zvýšení kvality použijte obvyklé způsoby řízení.
10. Věnujte náležitou pozornost kvalitě současného portfolia aplikací informačních technologií
v organizaci, jakož i jeho neustálému rozvoji. Mohl by být klíčem k rozhodujícímu zlepšení
provádění nejkritičtějších podnikových procesů.
112
20 Efektivnost IS Jde o komplexní a dosud ne dost uspokojivě prakticky i teoreticky vyřešený problém. Obecně je
efektivnost vyjádřitelná podílem přínosů a nákladů. Potíž je však v tom, že neumíme dostatečně přesně
a objektivně měřit přínosy IS, které se projevují většinou nepřímo v systému řízení podniku, a navíc se
skládají s celou řadou dalších faktorů působících na systém řízení a na celkovou efektivnost podniku.
Jak již víme, jsou rozhodnutí o informačním systému podniku rozhodnutími strategické povahy a
jejich důsledky se projeví až v delším časovém horizontu.
Problematikou efektivnosti IS se musíme zabývat po celou dobu jeho života a to jak ex-ante, tak ex-
post. V předprojektové přípravě při plánování IS se jedná o odhady budoucích nákladů a přínosů, které
se v průběhu projektování a zavádění upřesňují. V etapě užívání pak musíme konfrontovat tyto odhady
s realitou. Je bohužel prověřenou skutečností, že zpřesňování odhadů nákladů vždy vede k jejich růstu,
zatímco očekávané přínosy se časem redukují.
20.1 Náklady na IT, jejich struktura a měření
Definice: Náklady jsou zdroje, které obětujeme nebo kterých se vzdáme ve snaze o
dosažení určitého cíle.
Něco, čeho se vzdáme výměnou za něco jiného.
Náklady se často počítají v peněžních jednotkách a vyjadřují částku, kterou musíme zaplatit
pro získání určitého zboží nebo služeb.
Při řešení problému peněz určených na výstavbu IS musíme strategicky rozhodovat nejen o jejich výši,
ale i o dalších dvou stejně důležitých a strategických vlastnostech IS, tj. času, za který jsme schopni
potřebný IS uvést do života, a jeho kvalitě (tj. především jeho schopnosti plnit všechny požadavky).
Tyto tři strategické vlastnosti IS jsou ve svém účinku protichůdné. Chceme-li kvalitnější IS, či
chceme-li ho mít rychleji implementovaný, musíme vynaložit více peněz. Rozhodneme-li se naopak
zkrátit dobu vývoje při stejných nákladech, pak se to samozřejmě projeví zhoršením kvality.
Tato všeobecně známá skutečnost je zobrazitelná „magickým“ trojúhelníkem. Zobrazuje se situace,
kdy projektovou variantu P1 realizovatelnou v čase T1, vyžadující objem prostředků ve výši N1 a
zajišťující kvalitu řešení v úrovni K1, nahrazujeme projektovou variantou P2, která vyžaduje méně
peněz (N2 < N1), bude implementována dříve, (T2 < T1), ale za cenu zhoršení kvality (K2 < K1).
Problém nákladů na IT se dnes soustřeďuje především do oblasti softwaru, který představuje čím dál
tím větší část nákladů na IT ve srovnání s hardwarem. Je to dáno tím, že zatímco ceny HW rostou
zhruba lineárně, přičemž poměr cena/výkon klesá řádově, rostou náklady na SW exponenciálně.
Obr. 21 Vztah mezi kvalitou, náklady a časem u projektů (Molnár 1991)
113
Poznámka: Místo KVALITA si představte NEKVALITA, pak všechny rohy trojúhelníka jsou
klasifikovány jako 0 hodnota příslušného faktoru. Peníze rostou směrem od P, čas roste směrem od Č,
nekvalita roste směrem od NK.
Procesy řízení nákladů: 1. Odhad nákladů 2. Rozpočet nákladů 3. Řízení nákladů – řízení změn v rozpočtu projektu
Důležité principy, myšlenky a pojmy z řízení nákladů 1. Zisk – rozdíl mezi příjmy a výdaji 2. Zisková marže – poměr mezi ziskem a příjmy 3. Náklady životního cyklu – náklady na vlastnictví+náklady na podporu 4. Analýza cash flow – metoda stanovení odhadovaných ročních nákladů a výnosy 5. Uchopitelné náklady a výnosy 6. Neuchopitelné náklady a výnosy – těžko se kvantifikují, bývá těžké je obhájit 7. Přímé náklady – lze vyčíslit 8. Nepřímé náklady (režie) 9. Utopené náklady 10. Teorie křivky učení 11. Rezervy:
a. mimořádné (známé neznámé) b. manažerské (neznámé neznámé)
20.1.1 Druhy nákladů na IT
Do nákladů na IT musíme počítat následující druhy nákladů:
1. Náklady na nákup a instalaci technických prostředků a ostatní vyvolané investice, jako jsou
stavební úpravy, rozvody kabelů, klimatizace apod.
2. Náklady na řešení projektu, kam musíme započítat cenu za projekt, pokud je vy tvářen cizí
organizací, cenu za nákup softwaru a náklady vlastních řešitelských kapacit včetně případného
strojového času na ladění programů.
3. Náklady u uživatele, které vzniknou zejména v etapě zavádění z nákladů sběru dat,
ověřovacích chodů, přeškolování pracovníků apod.
4. Náklady provozu a údržby, kam musíme započítat náklady provozu techniky (energie,
spotřební materiál, technická údržba), náklady provozních programátorů provádějících úpravy
a doplňky v systému apod.
Jiné dělení (Basl 2002 Grada):
Jednorázové náklady:
Nákup HW
Nákup SW
Datové naplnění systému a tvorba datových rozhraní na existující řešení
v podniku
Úpravy obrazovek a sestav, tvorba a tisk nových formulářů
Doprogramování speciálních úloh
Úpravy podnikových procesů
Školení uživatelů
Provozní náklady:
Servisní poplatky za HW (cca 10% ročně z nákupní částky)
114
Servisní poplatky za SW (cca 10% ročně z nákupní částky)
Poradenská činnost
Zabezpečení provozu vlastního IT
20.1.2 Techniky pro odhadování nákladů
1. Odhad podle analogie (odhad shora dolů) 2. Odhad zdola nahoru (lze určit dostatečně přesně výpočtem z ceníků, pokud jde o
nakupované položky) 3. Parametrické modelování
a. model COCOMO (Constructive Cost Model), Barry Boehm, funkční body, KSLOC
b. COCOMO II 4. Počítačové nástroje
Nejvíce problémů může přinést odhad pracnosti projektových a programátorských prací. Pro odhady
pracností těchto prací byly v minulosti snahy vytvářet určité normativy, ale jejich účinnost s ohledem
na rychle se měnící podmínky byla velmi nízká, a proto se musíme spokojit jenom s kvalifikovanými
odhady na základě analogií a vlastních zkušeností. (viz parametrické modelování).
Pomocníkem by nám mělo být softwarové inženýrství, kde byly vypracovány určité metodiky
vycházející z principů empirických koeficientů.
Použití vybraných ukazatelů demonstruje Molnár (1991).
20.1.3 Hodnocení nákladů na IT v podniku
V podniku se používají různé ukazatele, např. (Basl 2002 Grada):
Roční výdaje na IS/IT jako procento celkového rozpočtu
Roční výdaje na IS/IT jako procento obratu firmy
Roční mzdové výdaje na IS/IT jako procento celkových mzdových výdajů
Poměr mezi výdaji na HW, SW a službami IS/IT
Roční výdaje na IS/IT vztažené na 1 pracovníka
Roční procento investic na IS/IT jako procento z celkových výdajů na investice
Tyto ukazatelé by se měly dlouhodobě sledovat, porovnávat a vyhodnocovat.
20.2 Vyjádření efektů
20.2.1 Přímé ekonomické efekty
U výpočtů ekonomické efektivnosti zavádění IT se obyčejně uspokojíme jen s vyčíslením přímých
ekonomických přínosů, které přináší především:
1. Úspora pracovních sil, resp. pracnosti náhradou lidské práce počítačem
2. Úspora materiálových a režijních nákladů v důsledku rychlejších a přesnějších výpočtů
3. Zkrácení průběžných (dodacích) dob výroby, resp. dodacích termínů v důsledku rychlejšího a
přesnějšího plánování a přímého řízení výroby a skladů
4. Zvýšení výroby resp. obratu v důsledku rychlejšího, pružnějšího a přesnějšího plánování a
řízení zdrojů
5. Zvýšení objemu zisku v důsledku zvýšení výroby, resp. prodejů zvýšením výroby, či snížením
nákladů
6. Úspora finančních nákladů v důsledku přesnějšího, rychlejšího a komplexnějšího sledování
finančních toků, úvěrů, plateb apod. (řízení cash flow)
115
7. Nové produkty - prodej
Na základě vypočtených, či odhadnutých ekonomických přínosů můžeme pak počítat klasické
ukazatele ekonomické efektivnosti investic.
20.3 Základní metody pro stanovení odhadované finanční hodnoty projektu
20.3.1 Analýza čisté současné hodnoty (NPV)
diskontovaná hodnota zisku v celém období
NPV = A/(1+r)t A (objem cash flow), r (diskontní sazba), t (číslo roku) diskontní faktor: 1/(1+r)t
Peníze přijaté nyní mají větší hodnotu než peníze přijaté někdy v budoucnosti. Velikost rozdílu s časem narůstá. Tento rozdíl rovněž roste s vyšší úrokovou mírou. Současná hodnota budoucích příjmů je stanovena přepočtem budoucích příjmů na současnou úroveň za použití vhodné úrokové míry. Budoucí příjmy jsou tak konvertovány na ekvivalentní množství v jednotném časovém okamžiku, čímž je zohledněna „časová hodnota peněz“. Úroková míra použitá pro výpočty je označována jako předpokládaná úroková míra.
Přepočet budoucích příjmů na současnou hodnotu peněz dovoluje srovnání ekonomických přínosů soupeřících alternativ. „Čistá současná hodnota“ každého z těchto finančních příjmů je použita pro stanovení jejich relativní atraktivnosti. Míra rizika spojená s investováním je zohledněna v přepokládané úrokové míře. Pokud je investice shledána relativně rizikovější, je pro ni požadována větší návratnost, aby bylo riziko ospravedlnitelné.
To znamená, že analýze „čisté současné hodnoty“ je použita vyšší předpokládaná úroková míra. Můžete být šťastní, když obdržíte 5 % úrok z peněz uložených v bance, ale můžete chtít daleko větší úrok z peněz půjčených příbuznému. Pokud je „čistá současná hodnota“ při předpokládané úrokové míře větší než nula, investice je odůvodněná. Záporná hodnota svědčí o tom, že investice nedosáhne požadované návratnosti.
20.3.2 Návratnost investice (ROI = Return of Investment)
Návratnost = (celkové diskontované přínosy – celkové diskontované náklady) / diskontované náklady V %
20.3.3 Analýza doby návratnosti (Playback Period)
Doba návratnosti je množství času, které potrvá navrácení všech finančních prostředků
investovaných do projektu, a to ve formě čistých peněžních příjmů.
Jinými slovy: analýza doby návratnosti stanovuje, kolik doby uplyne, než postupně narůstající výnosy dosáhnou výše narůstajících nákladů. Okamžik návratnosti – bod zvratu
116
Obr. 22 Stanovení doby návratnosti
K dalším patří třeba vnitřní výnosové procento (IRR = Internal RAte of Return) či poměr „benefit
/cost“ (angl. Benefit / cost ratio)
S výhodou můžeme pro výpočty návratnosti investic použít jakýkoliv tabulkový procesor, který má
v sobě zabudovány všechny výše uvedené finanční funkce, např. MS Excel.
20.4 Měření pracovního výkonu - metoda řízení vytvořené hodnoty (earned value management, EVM)
Metoda pro měření efektivity pracovního výkonu v projektu – podmínkou je existující
směrný plán projektu s definovanými náklady a důsledné vedení skutečných údajů o
pokračování projektu.
Princip metody:
Pro každou aktivitu nebo souhrnnou aktivitu ze struktury WBS je nutné počítat následující
tři hodnoty:
1. Plánovaná hodnota (planed value, PV) = rozpočet, hodnota, která měla být
utracena během daného časového období. Odpovídá na otázku, kolik peněz jsme ke
konkrétnímu datu realizace projektu měli utratit podle plánu.
2. Skutečné náklady (actual cost, AC) = skutečně vynaložené náklady na aktivitu,
která byla odvedena v daném časovém období. Odpovídá na otázku, kolik peněz
jsme k aktuálnímu datu skutečně utratili.
3. Vytvořená hodnota (earned value, EV) = hodnota vykonané práce měřená cenou
dle plánu. Odpovídá na otázku, jaká je hodnota vykonané práce k aktuálnímu datu
Např. dle plánu na konci měsíce mělo být vyrobeno A1 (plánovaná cena 5), A2
117
(plánovaná cena 10) a A3 (plánovaná cena 8). Na konci měsíce ale bylo ve
skutečnosti vyrobeno jen A2 a utraceno 15. Z toho vyplývá, že:
EV= 10
AC=15
PV=23
Míra efektivity (rate performance RP), také SPI = EV/PV udává poměr mezi vytvořenou
hodnotou a plánovanou hodnotou.
Ukazatel aktivity Týden 1
Vytvořená hodnota (EV) 5000
Plánovaná hodnota (rozpočtové náklady plánovaných prací (PV)
10000
Skutečné náklady (AC) 15000
Odchylka nákladů (CV) -10000
Odchylka časového plánu (SV) -5000
Index efektivity nákladů (CPI) 33%
Index efektivity časového plánu (SPI) 50%
Náklady podle směrného plánu (Budget at Completion, BAC)
CV = EV – AC = 5 000 – 15 000 = -10 000 SV = EV – PV = 5 000 – 10 000 = -5 000 CPI = EV/AC = 5 000 / 15 000 = 33% SPI = EV/PV = 5 000 / 10 000 = 50%
Ukazatel Vzorec Vytvořená hodnota (Earned value EV) EV = PV x RP
Odchylka nákladů (cost variance, CV) CV = EV - AC
Odchylka časového plánu (Scheduled Variance, SV)
SV = EV - PV
Index efektivity nákladů (Cost Performance Index, CPI)
CPI = EV/AC
Index efektivity časového plánu (Scheduled Performance Index, SPI)
SPI = EV/PV
Odhad nákladů na dokončení (EAC) EAC = BAC/CPI
Odhad času na dokončení Původní odhad času / SPI
Odchylka nákladů při dokončení (Variance at Completion, VAC)
VAC = BAC-EAC
Odchylka nákladů: Rozdíl mezi rozpočtovými náklady provedených prací (EV) úkolu a skutečnými náklady provedených prací (AC). Je-li hodnota CV kladná, jsou náklady v současnosti pod částkou rozpočtu, je-li záporná, je rozpočet úkolu v současnosti překročen.
118
Odchylka plánování představovaná rozdílem mezi rozpočtovými náklady provedených prací [EV] a rozpočtovými náklady plánovaných prací [PV]. Ukazatel efektivity (TCPI) zbývající práce daný poměrem práce, kterou zbývá vykonat k datu stavu, a financí, které zbývá k tomuto datu utratit [BAC - EV]/[BAC - AC]. Hodnota TCPI větší než 1 znamená nutnost zvýšit na projektu výkon. Hodnota menší než 1 znamená, že lze snížit výkon.) je poměr práce, kterou zbývá k datu stavu provést, a finančních prostředků, které zbývá k datu stavu vynaložit. Pokud SPI (ukazatel plnění plánu) nabývá hodnot vyšších než 1, jedná se většinou o předbíhání plánu, hodnota menší než 1 naopak znamená, že za plánem k aktuálnímu datu zaostáváme nebo byl v průběhu projektu vůči plánu snížen rozpočet. Ukazatel plnění plánu je dán poměrem vykonané a plánované práce. SPI je ukazatelem časovým. CPI (ukazatel čerpání nákladů, index efektivity nákladů) je poměr rozpočtových nákladů (dle směrného plánu) a skutečně čerpaných nákladů. Pokud je hodnota CPI nižší než 1, projekt čerpá z rozpočtu více nákladů než by měl. Pokud je hodnota naopak vyšší než 1, není pravděpodobně dodržen naplánovaný cashflow a/nebo pravděpodobně nebylo provedeno tolik práce, kolik bylo naplánováno. CPI je ukazatelem nákladovým.
20.5 Nepřímé efekty
Nepřímé efekty, jinak také institucionální, představují přínosy, které nelze přímo ekonomicky (finančně) vyjádřit. Např. spokojenost zaměstnanců při práci s moderní technikou, lepší image firmy, dojem na zákazníky.
20.6 Komplexní hodnocení projektů IT (pro současné hodnocení přímých a nepřímých efektů)
Velmi ucelený a komplexní systém hodnocení projektů IT z hlediska potřeb jejich prioritace pro
konečné rozhodnutí o jejich budování předložili Parker a Benson. Ukažme si zde principy jejich
přístupu.
„Hodnota“ projektu se skládá z jeho hodnocení ve třech oblastech, jimiž jsou:
- návratnost investic
- ostatní přínosy a rizika pro podnik = neuchopitelné
- hodnota aplikace z hlediska použité IT
Pro jednotlivé oblasti stanovují komponenty, které působí příznivě či nepříznivě a navrhují jednotný
systém bodového hodnocení pětibodovou stupnicí (0-5). Výsledná hodnota projektu je pak dána
součtem těchto bodů. Všechny projekty se pak seřadí podle získaných bodů, a tím je dána jejich
priorita.
20.6.1 Hodnota návratnosti investic
Pro bodové ohodnocení navrhují Parker a Benson tuto stupnici:
Tab. 3 Hodnocení bodové návratnosti (Molnár 1991)
Body Jednoduchá návratnost
0 záporná nebo nula
1 1 % až 299 %
2 300 % až 499 %
119
3 500 % až 699 %
4 700 % až 899 %
5 přes 900 %
20.6.2 Bodové hodnoty ostatních přínosů a rizik pro podnik
Tato oblast hodnocení aplikace IT je tvořena pěti dílčími komponentami (hledisky), a to vztahem
k podnikovým cílům, podporou konkurenceschopnosti podniku, podporou manažerského
informačního systému MIS, tj. poskytováním informací pro jejich rozhodování, naléhavosti řešení
daného problému a projektovými, či organizačními riziky spojenými s vývojem nebo provozem dané
aplikace.
Bodové stupnice pro jednotlivé oblasti jsou uvedeny v následujících tabulkách.
Tab. 4 Hodnocení podpory strategických cílů podniku (Molnár 1991)
Body Podpora strategických cílů podniku
0 nemá žádnou souvislost s cíli podniku
1 nemá přímou ani nepřímou souvislost s nějakým cílem, ale zlepšuje provozní efektivnost podniku
2 nemá přímou souvislost s nějakým cílem, ale je nezbytná pro jinou aplikaci, která částečně podporuje nějaký cíl
3 nemá přímou souvislost s nějakým cílem, ale je nezbytná pro jinou aplikaci, která přímo podporuje nějaký cíl
4 podporuje částečně nějaký podnikový cíl
5 podporuje přímo nějaký podnikový cíl
Tab. 5 Hodnocení podpory konkurenceschopnosti podniku (Molnár 1991)
Body Podpora konkurenceschopnosti podniku
0 aplikace nepřispívá ke styku s okolím, tj. se zákazníky, dodavateli, či partnery
1 aplikace nepřispívá ke styku s okolím, ale přispívá ke zvýšení provozní efektivnosti
2 aplikace nepřispívá ke styku s okolím, ale přispívá ke zvýšení efektivnosti klíčové strategické oblasti podniku (LOB)
3 aplikace podporuje částečně styk s okolím, a tím přispívá mírně ke zlepšení pozice podniku na trhu
4 aplikace podporuje částečně styk s okolím, a tím přispívá k výraznému zlepšení pozice podniku na trhu
5 aplikace zásadně mění styk se zákazníky, a tím zajišťuje služby, které jim nemůže poskytnout konkurence
Tab. 6 Hodnocení podpory řízení podniku (Molnár 1991)
Body Podpora řízení podniku
0 aplikace není spojena s řízení základních činností podniku
1 aplikace není spojena s řízením základních činností, ale poskytuje určitá data funkcím v těchto činnostech
2 aplikace není spojena s řízením základních činností, ale poskytuje informace, funkcím, které přímo podporují jejich řízení
3 aplikace není spojena s řízením základních činností, ale poskytuje
120
zásadní informace nutné k jejich řízení
4 aplikace je zásadní pro zajišťování základních činností v budoucnosti
5 aplikace je zásadní pro zajišťování základních činností v současnosti
Tab. 7 Hodnocení naléhavosti řešení podnikových problémů (Molnár 1991)
Body Podpora řešení problému
0 aplikace může být odložena nejméně o rok, aniž by to mělo nějaký dopad na postavení podniku na trhu
1 odložení aplikace nemá vliv na postavení podniku na trhu a stejné výsledky by byly dosaženy s minimálním zvýšením pracnosti
2 odložení projektu nemá vliv na postavení podniku na trhu, ale dosažení stejných výsledků si vyžádá výrazné zvýšení pracnosti
3 jestliže bude aplikace odložena, neohrozí to postavení podniku, ale na některé změny nebude podnik schopen včas reagovat
4 odložení aplikace může vést ke ztrátě konkurenceschopnosti podniku nebo ke ztrátě současného úspěšného postavení podniku
5 Odložení aplikace způsobí ztrátu konkurenceschopnosti nebo ztrátu současného úspěšného postavení podniku
Tab. 8 Hodnocení organizačního rizika – záporné (Molnár 1991)
Body Organizační riziko (záporné)
0 podnik má dobře formulovaný plán pro zavedení aplikace, která má navíc plnou podporu vedení a nevyžaduje výrazné změny v organizaci
podniku ani přeškolování lidí
1 jako v předchozím případě, ale zavedení bude vyžadovat přeškolení lidí
2 jako v předchozím případě, ale zavedení bude znamenat mírné změny v organizaci podniku
3 jako v předchozím případě, ale zavedení bude znamenat výrazné organizační změny v podniku
4 podnik nemá žádný plán pro zavedení aplikace a odpovědnost za ni není jasně stanovena, ale nevyžádá si změny v organizaci podniku
5 podnik nemá žádný plán pro zavedení aplikace a odpovědnost za ni není jasně stanovena a zavedení bude znamenat změny v organizaci
podniku
20.6.3 Technologické vlastnosti aplikace
Jelikož mnoho důležitých hodnot, ale i rizik uvažované aplikace IT není zahrnuto v hodnocení
z ekonomického, či podnikového hlediska, musíme ještě zvážit další hledisko vlastní informační
technologie. To nám pomůže vybrat z několika jinak rovnocenných variant tu, která bude nejlépe
vyhovovat strategickým požadavkům rozvoje IT v podniku, uvažovat rozsah změn a s nimi spojená
rizika i požadavky progresivnosti řešení.
Tab. 9 Hodnocení souhlasu se staregickou koncepcí IS (Molnár 1991)
Body Souhlas se strategickou koncepcí IS
0 aplikace nemá žádnou souvislost s koncepcí IS
1 aplikace je částí koncepce, ale její priorita není určena
2 aplikace je částí koncepce IS, má nízké náklady, ale není nutná pro žádnou jinou aplikaci v koncepci
121
3 aplikace je integrální součástí koncepce, má střední náklady, ale není nutná pro jiné aplikace v koncepci
4 aplikace je integrální součástí koncepce, má vysoké náklady, ale není nutná pro jiné aplikace v koncepci
5 aplikace je integrální součástí koncepce a je nezbytná pro ostatní aplikace v koncepci
Tab. 10 Hodnocení definiční nejistoty aplikace – záporné (Molnár 1991)
Body Definiční nejistota aplikace (záporné)
0 požadavky na aplikaci jsou pevně stanoveny a je zanedbatelná pravděpodobnost změn
1 požadavky jsou částečně stálé, ale je malá pravděpodobnost významných změn
2 jako v předchozím případě, ale je značná pravděpodobnost významných změn
3 jako v předchozím případě, ale aplikace je rozsáhlá a změny jsou téměř jisté
4 požadavky i jejich specifikace nejsou pevně dány, aplikace je rozsáhlá, změny jsou téměř jisté ale specifikovatelné
5 požadavky i jejich specifikace jsou neznámé, aplikace je rozsáhlá a změny mohou být významné a nejsou předem specifikovatelné
Další jsou záporné:
Tab. 11 Hodnocení rozdílu mezi požadovanou a disponibilní kvalifikací pracovníků (Molnár 1991)
Body Rozdíl mezi požadovanou a disponibilní kvalifikací pracovníků
0 není žádný rozdíl
1 mírná změna kvalifikace je nutná pro výkonné pracovníky, ale ne pro řídící pracovníky
2 mírná změna kvalifikace je potřebná pro všechny
3 mírná změna kvalifikace je potřebná pro výkonné pracovníky a výrazná pro řídící pracovníky
4 výrazně nová kvalifikace je třeba pro výkonné pracovníky a mírná pro řídící pracovníky
5 výrazně nová kvalifikace je třeba pro všechny
Tab. 12 Hodnocení rizika požadovaného softwaru (Molnár 1991)
Body Rizika požadovaného softwaru
0 standardní software, malé nebo žádné programátorské nároky
1 standardní software, ale jsou potřebné značné programátorské kapacity
2 jsou potřebné některé nové prostředky pro zajištění interface mezi programy
3 jsou potřebné některé nové prostředky v zajištění komplexního interface mezi programy
4 jsou potřebné některé nové moderní prostředky, které dosud v podniku nejsou známé
5 jsou potřebné nové špičkové softwarové prostředky
Tab. 13 Hodnocení rizika požadovaného hardwaru (Molnár 1991)
Body Rizika požadovaného hardwaru
0 hardware je již používán pro podobnou aplikaci
122
1 hardware je již používán pro jinou aplikaci
2 hardware je již v podniku testován, ale není ještě v běžném provozu
3 hardware jiš existuje, ale není dosud instalován v podniku
4 některé klíčové komponenty hardwaru nejsou dosud ověřeny v podniku
5 klíčové požadavky hardwaru nejsou dosud dostupné
Tab. 14 Hodnocení rizika aplikačního softwaru (Molnár 1991)
Body Rizika aplikačního softwaru
0 existuje již v podniku aplikační program s minimem nutných úprav
1 aplikační program se dá koupit a je třeba minimum úprav
2 aplikační program se dá koupit a jsou třeba středně velké úpravy
3 aplikační program se dá koupit, ale jsou třeba rozsáhlé úpravy
4 není k dispozici aplikační program a je třeba jej navrhnout a vytvořit
5 není k dispozici aplikační program a je třeba ho vytvořit s pomocí externích dodavatelů
Tab. 15 Hodnocení rizika infrastruktury IS v podniku (Molnár 1991)
Body Riziko infrastruktury IS v podniku
0 aplikace využívá stávající služby a zařízení, není nutná žádná další investice do IS
1 je potřebná změna jen jedné části IS podniku
2 jsou nutné malé změny v několika částech IS
3 jsou nutné středně velké změny v několika částech IS
4 je potřebná zásadní změna v jedné části IS
5 jsou potřebné zásadní změny v několika částech IS
20.6.4 Výsledné bodové hodnocení
Výsledné bodové hodnocení aplikace získáme prostým součtem přidělených bodů v jednotlivých
oblastech se zřetelem na jejich kladný, či záporný vliv na hodnotu aplikace.
Tab. 16 Výsledné bodové hodnocení (Molnár 1991)
Ukazatel Bodové hodnocení
Návratnost investic 1
Podpora strategických cílů 5
Podpora konkurenceschopnosti 5
Podpora řízení 5
Naléhavost řešení problémů 4
Organizační riziko -3
Souvislost s koncepcí IS 3
Definiční nejistota -3
Technická nejistota -(4+3+3+2)/4=-3
Riziko infrastruktury IS -2
CELKEM 12
Podobným způsobem byly ohodnoceny ostatní projekty IT a vytvořeno pořadí pro jejich postupnou
realizaci.
123
21 CASE
21.1 Základní pojmy
Počítačem podporovaný vývoj IS, označovaný v literatuře jako Computer Aided Software Engineering
– CASE, je jednou z cest, jak překonat problémy spojené s výstavbou i provozem IS.
Již sama zkratka CASE v sobě spojuje dva aspekty, a to aspekt softwarového inženýrství, které bylo
vybudováno pro realizaci rozsáhlých softwarových projektů užitím určitých standardizovaných
(inženýrských) metodologií a aspekt počítačové podpory těchto metodologií v podobě různých
softwarových nástrojů, případně specializovaného hardwaru.
Nástroje (CASE tools), představují integrovanou sadu programů, které podporují úlohy prováděné při
vývoji softwaru automatizovaným způsobem, a které užívají centrální databázi, v níž jsou uloženy
všechny technické, organizační a řídící informace nutné pro výstavbu i údržbu určitého projektu IS.
Z formální hlediska se někdy rozlišují typy CASE podle toho, pro jakou fázi životního cyklu IS jsou
určeny na tzv.:
- upper CASE, který podporu fázi plánování, specifikaci požadavků, modelování organizace
podniku a globální analýzu IS
- middle CASE, který podporuje detailní analýzu a vlastní návrh IS
- lower CASE (nazývaný také Computer Aires Programming), který podporuje fyzickou, tj.
programovou realizaci systému
Toto členění je dáno systémy, které jsou nabízeny na trhu. Vývoj však spěje k tzv. integrovaným
systémům označovaným jako I – CASE, čili Integrated CASE. I – CASE je CASE, který podporuje
všechny fáze životního cyklu vývoje IS v jediném komplexním programovém systému.
Enterprise Architect
IPSE – Integrated Project Support Environment je kompatibilní sada nástrojů pro automatizovanou
podporu specifikace, projektování, programování, testování a údržbu nejen jednoho projektu IS. Spolu
s řídícími nástroji a procedurami, které využívají uspořádanou a konsistenční projektovou databázi
slouží k řízení výstavby a údržby všech aplikací IT v podniku. Je to jakási nadstavba CASE obohacená
zejména o procedury plánování a řízení projektů.
21.2 Funkce a vlastnosti CASE produktů
Na softwarovém trhu je dnes již dostatečná nabídka různých CASE produktů, jejichž vlastnosti funkce
se liší poměrně málo (jako je tomu konečně u všech v současné době nabízených softwarových
systémů určité třídy). Prakticky všechny CASE produkty podporují strukturovanou metodologii
životního cyklu a techniky, zejména Data Flow Diagramming, Jackson Structure Design, Entity
Relationship Diagramming a Prototyping.
UML
Bez ohledu na typ CASE a podporovanou metodologii počítáme k jeho funkční výbavě
(technologickému prostředí CASE ) především dále uvedené vlastnosti:
1. Konsistentní grafické komunikační (ovládací) prostředí nejčastěji prostřednictvím ikona
systému oken (windowing), či roletových menu ovládané myší.
2. Centrální databázi (encyklopedii) pro uchovávání informací o všech objektech IS (jednou
vložená informace je použitelná v libovolném dalším kroku), což zaručuje především integritu
a konsistenci systému.
3. Prostředky pro verifikaci konsistence a kompletnosti dat včetně podpory normalizace
datových struktur.
4. Textový editor umožňující vytvářet popisy objektů a jejich vazeb pro účely dokumentace
systému včetně možnosti tisku různých zpráv.
124
5. Možnosti rychlého návrhu uživatelských obrazovek vstupů/výstupů (uživatelského prostředí)
včetně možnosti simulace vstupů a výstupů a snadnou modifikaci vstupů/výstupů tak, jak to
vyžadují princip prototypingu.
6. Generátor zdrojových programů umožňující automatickou tvorbu aplikačních programů.
7. Export/import textových, či databázových souborů do/z jiných programových systémů.
8. Prostředky pro podporu řízení projektů typu CPM, PERT apod. Rovněž pokud jde o
hardwarové prostředí, je většina CASE systémů provozovatelná na různých konfiguracích
architekturách.
21.3 Hlediska pro hodnocení CASE systémů
Pro hodnocení CASE systémů byla již v literatuře publikována nejrůznější hlediska, jejichž
významnost se samozřejmě mění tak, jak se stále bouřlivě vyvíjejí CASE produkty a jejich nabídka na
trhu. Problém hodnocení je navíc komplikovaný tím, že vlastně nejsou dosud k dispozici žádné
standardy, existuje značná rozmanitost hardwarového i softwarového prostředí u uživatelů a samo
hodnocení (má-li být provedeno správně) je proces drahý a časově náročný.
Poměrně obecný a dosti výstižný rámec pro hodnocení CASE systémů navrhuje S. K. Misra.
Rozděluje hodnotící hlediska do čtyř kategorií:
- hlediska podpory metodologie
- hlediska uživatelských funkcí
- hlediska zaveditelnosti v podniku
- hlediska poprodejní podpory
21.3.1 Hledisko podpory metodologie
Zde se klade důraz především na podporu strukturovaných metodologií. CASE by měl především
podporovat tu metodologii, která se v podniku dosud používala. Problém ale je, zda se v podniku před
zavedením CASE důsledně a systematicky používala vůbec nějaká metodologie. Potom může nastat
velmi riskantní situace v důsledku nutnosti zvládnutí jak nové metodologie, tak i CASE produktu.
Pokud je potřeba, zajímá se EIS o prostředky na podporu reengieeringu, či reverse engineeringu.
21.3.2 Hledisko uživatelských funkcí
Některé nezbytné funkční charakteristiky CASE byly již uvedeny. Vyčerpávající vyhodnocení všech
uživatelských funkcí je v podstatě nemožné bez delší doby práce se systémem, což je prakticky
nerealizovatelné. Zde jsme odkázáni jen na demonstrační ukázky, či prospektové údaje. Nicméně
zaměříme se na typy implicitních komponent zobrazovaných ikonami, zejména na real-time ikony,
snadnost vytváření diagramů, jejich možné modifikace včetně automatického „hlídání“ konsistencí při
přejmenování, či vymazávání některých komponent, možnost odvolání nechtěného úkonu (UNDO),
úpravy grafů jako je změna měřítka, rotace, zoom, možnost rychlého přepínání, či současného
sledování více grafů současně (windowing), možnost dalších grafických vstupů jako je světelné pero,
digitizér apod., a samozřejmě možnosti úprav tištěných výstupů.
Zvláštní pozornost věnujeme centrální databázi, zda je opravdu integrovaná, zda má nějaká kapacitní
omezení, jak je chráněná, zda je možný import/export, jaký textový procesor je použit pro popisy
komponent atd. Nezbytností je trvalé sledování konsistence centrální databáze. Zajímáme se rovněž o
možnost získání různých přehledových sestav umožňujících analýzy navrhovaného IS, jako je např.
soupis všech izolovaných datových položek, externích vazeb, procesů a modulů bez potřebné
specifikace apod.
Nezbytná je možnost prototypingu včetně možností simulací uživatelských funkcí.
21.3.3 Hlediska zaveditelnosti v podniku
Měli bychom dbát na to, aby zakoupený CASE byl provozovatelný bez větších problémů v tom
hardwarovém/softwarovém prostředí, které již máme podniku k dispozici bez dodatečných investic.
125
Dalším problémem je vyškolení pracovníků v práci s CASE produktem. Jde většinou o poměrně
složité systémy, jejichž zvládnutí není záležitostí krátkodobého kursu. Hodnotíme především to, zda
systém ovládání je konsistentní, dobře zapamatovatelný a uživatelsky přívětivý. Navíc je třeba
zhodnotit případnou potřebu výchozích znalostí a dovedností pracovníků podniku nutných k tomu,
aby vůbec mohli začít s CASE produktem pracovat. Hodně nám v tomto problému pomůže dobrá a
přehledná dokumentace, dostatek demonstračních příkladů a samozřejmě dobře propracovaný systém
školení dodavatelem, úroveň a zkušenosti školitelů.
Posuzujeme, zda k vlastnímu provozu CASE systému budeme potřebovat vlastní specialisty zabývající
se jenom „provozem“ tohoto systému, nebo zda systém „poběží sám“ jenom za účasti uživatelů
(projektantů).
21.3.4 Hlediska poprodejního servisu
Pohotový a kvalitní poprodejní servis je životně důležitý a je dán solidností, velikostí a minulostí
dodavatele. Proto dáme přednost renomovanému a silnému dodavateli.
21.4 Rozhodnutí o nákupu CASE systému
Jak je zřejmé z výše uvedeného přehledu hledisek, jedná se při rozhodování o nákupu CASE systému
opět o vícekriteriální problém, který je třeba řešit známými a již několikrát uvedenými metodami.
Rozhodující je ale však cíl (účel) pro jaký si CASE chceme koupit. Ten by měl být vyjasněn
především. Samozřejmě jiné důvody bude mít podnik zabývající se projektováním a dodávkami si
(Software & Systém House) a jiné konečný uživatel.
Pokud jde o Software & Systém House – SSH, pak je rozhodnutí vcelku jednoduché, pokud se SSH
zabývá vývojem aplikací pro zákazníka. Investice vložená do CASE systému se jistě vrátí ve zvýšené
produktivitě práce a zrychlením vývoje při opakovaných aplikacích.
Pokud jde o konečného uživatele, tj. podnik, který si pořídí CASE systém pro „vlastní“ potřebu, pak je
již rozhodování složitější. Málokterý podnik si dnes vyvíjí aplikace IT svými vlastními silami.
Obyčejně to řeší nákupem hotových aplikačních systémů, nebo v úzké spolupráci s některým SSH.
Zde by se zdálo, že pořízení CASE systému by byly vyhozené peníze. Není to však pravda, protože i
když není CASE systém použit bezprostředně pro vývoj systémů, jsou jeho služby nenahraditelné při
provozu a údržbě IS, jak již o tom byla několikrát zmínka.
Rozhodnutí o nákupu a zavedení CASE systému znamená především velký závazek pro všechny
zainteresované pracovníky v podniku, počítače vedením podniku až po každého řadovaného
projektanta IS v podniku. Nejde jenom o to, že se jedná o velmi drahé produkty (řádově stovky tisíc
Kč), ale že se jedná i o poměrně složité systémy, jejichž zvládnutí není otázkou několika dnů, ale
několika měsíců. Rovněž musí být nasazení CASE provedeno plošně na všechny vyvíjené aplikace,
což ve svém důsledku znamená nejen vyškolení všech pracovníků v oblasti IT v podniku, ale, a to
zejména, změnu dosavadního stylu jejich práce. Toto vše je nejen finančně, ale i časově náročné. Proto
se jako velmi výhodné jeví uzavření tzv. „after – sale“ smlouvy se SSH (dodavatelem), od kterého
kupujeme CASE systém, o další spolupráci při využívání CASE systému v podniku.
Je velkou chybou chápat CASE jenom jako elegantní počítačovou náhradu tužky a papíru. Především
jde o zavedení systematického průběžného zaznamenávání informací o všech objektech v centrální
databázi a vytváření podnikové encyklopedie, která je použitelná i mimo rámec výstavby a provozu IS
podniku.
126
22Role lidí v informačním systému Podle Doucek et al. (2007, in Gála et al. 2009, s. 28-29) patří k základním rolím:
Byznys analytik – architekt
Manažer rozvoje a provozu IS/IT
Obchodník s produkty a službami
Vývojář nebo IS architekt
Správce aplikací a IT struktury
23Analýza uživatelů
Cílem analýzy uživatelů je zmapování potřeb uživatelů. Uživatele je tedy nezbytné nejdříve
identifikovat.
Dále je potřebné vytvořit skupiny uživatelů, kteří mají obdobné požadavky na navrhovaný systém.
Jsou vybrány a vymezeny skupiny, jejichž požadavky by měly být prioritně uspokojeny.
Potřeby uživatelů budou rozpracovány tak, aby mohly být formulovány jako požadavky na
navrhovaný systém.
Součástí uživatelské analýzy je také vymezení povinností jednotlivých skupin uživatelů. Tyto
povinnosti přímo vyplývají z platné legislativy.
Uživatelská analýza je prováděna také za účelem vyhodnocení vztahu uživatelů k projektu. Výsledky
analýzy mohou být využity jako základ pro vybudování konkrétní fungující spolupráce v případě, že
vztahy subjektu k projektu jsou kladné, v případě že nikoli, lze pracovat na zlepšení těchto vztahů.
Přímé zapojení všech potenciálně zainteresovaných uživatelů se však nepředpokládá.
V návaznosti na výsledky analýzy lze snáze zjistit požadavky uživatelů systému na funkčnost
navrhovaného systému, náklady a nároky na technické vybavení a na pořízení a provozování
navrhovaného systému.
Definice uživatele
Uživatel je osoba nebo skupina osob, jež má zájem o projekt, jelikož projekt nebo jeho výsledky by
mohly přímo zasáhnout do jejich životů. Uživatelem ale může být i jedinec nebo instituce, které
projekt či jeho výsledky použijí při své práci, při rozhodování nebo jiném podnikání.
Uživatelská analýza nemá jednu standardní metodiku, pro tento účel tedy může být s úspěchem
použito více metod, viz např. Řepa (1999).
Metodiky provádění uživatelských analýz vychází z typů projektů, respektive z typů vytvářených
systémů. Systémy lze obvykle zařadit do jedné z následujících kategorií [Kravál, 2003], [Paleta,
2003]:
Systémy pro volný trh. Zde se jedná o různé kancelářské programy, antivirové programy, apod.
Specifikou projektů pro volný trh je předpokládaný široký okruh uživatelů, kteří nejsou na začátku
projektu přímo adresováni. Není předem jisté kolik zákazníků si daný produkt koupí a bude jej
využívat. Analýza uživatelů zde vychází z marketingových průzkumů.
Business systémy, podnikové systémy. Do této kategorie patří systémy vyvíjené na zakázku, na
míru určitému konkrétnímu odběrateli (podnikové systémy, banky, dopravní systémy apod.). Zde
jsou uživateli systému především zaměstnanci dané organizace, případně také jejich klienti.
Podkladem k identifikaci uživatelů je organizační struktura podniku a vztah jejích jednotlivých
částí k navrhovanému systému.
Entusiastické programy. Tyto programy vznikají na základě specifických požadavků malé
skupiny osob, například studentů, astronomů, apod.; zpravidla pro vlastní potřebu. Zde většinou
není potřeba provádět uživatelskou analýzu.
127
Mezi uživatele lze zahrnout všechny jedince (nebo skupiny) se zájmem o předmět projektu. Konkrétně
jsou to uživatelé, kteří buď jsou, nebo budou projektem přímo ovlivněni nebo mají znalosti o předmětu
projektu či zkušenosti s ním.
Při kategorizaci uživatelů je možné vycházet z několika obvyklých členění uživatelů:
1. Podle sektoru působnosti uživatelů. Například při hodnocení vývoje odběrů vod byly
použity tyto kategorie: zemědělství, energetika, průmysl a ostatní [VÚV, 2001].
2. Podle vztahu k subjektu, který systém provozuje: interní a externí uživatelé.
3. Podle množství a exkluzivity procesů, které uživatelé v systému využívají. Například
uživatelé českého webhostingu se dělí na: běžné uživatele (pro ně je určeno omezené
množství běžných, často používaných funkcí systému), na náročnější uživatele a na
profesionály (ti mají k dispozici rozšířenou nabídku náročnějších funkcí systému)
[Šindelář, 2005].
4. Obdobné členění je podle pravomocí uživatelů v rámci daného systému. Například
uživatelé Elektronického podání [Veřejná správa, 2003] mohou být zástupci,
organizace a občané.
5. podle potenciální míry ovlivnění uživatele navrhovaným systémem (dle toho jakým
způsobem výsledky projektu zasáhnou do jeho běžné činnosti). Možné dělení:
5.1 Primární – uživatel, jehož hlavní zájmy jsou nějakým způsobem projektem
ovlivněny. Uživatel zároveň profituje z projektu či jeho výsledků.
5.2 Sekundární - uživatel, jehož zájmy jsou nějakým způsobem projektem ovlivněny,
leč méně významně než v předchozí kategorii. Spadají sem např. dodavatelé projektových
vstupů.
5.3 Klíčový aktér – uživatel, který přímo ovlivňuje výstupy projektu, ale který sám
není přímo ovlivněn, např. zákonodárci nebo státní úředníci, významné instituce státní
správy a samosprávy, které mohou ovlivnit fungování projektu, či jeho uvedení do praxe.
5.4 Konečný uživatel – subjekt využívající výsledky projektu (např. instituce
používající navrhovaný systém v praxi).
5.5 Ostatní – subjekt profitující z výsledků projektu, který není přímo zapojen do
projektu (např. občan, kterého pozitivně ovlivní skutečnost, že instituce používá
navrhovaný systém). Příležitostně nebo minoritně ovlivňován výsledky projektu.
Uživatelé klasifikovaní jako „koneční uživatelé“ jsou důležitější skupinou zejména v ohledu
analytických a vývojových aktivit projektu, zatímco „ostatní“ mohou být přínosem např.
z hlediska organizace a problematiky legislativy.
6. dle právní formy subjektu a sektorů jejich působnosti
Veřejnoprávní orgány:
Státní správa
Ministerstva, centrální orgány státní správy
Státní instituce realizující se v jednotlivých odvětvích
Správy Národních parků, Správa ochrany přírody
Agentura ochrany přírody a krajiny, Česká inspekce životního prostředí, Hygienické
stanice, ČHMÚ
Státní podniky Povodí (jednotlivých řek)
128
Ředitelství, inspektoráty, svazy a rady působící v oblastech vodního, lesního a
zemědělského hospodaření
Samospráva
Krajské úřady
Obecní úřady
Podniky v soukromém, státním i obecním vlastnictví v následujících odvětvích:
Vodohospodářství (městské vodovody a kanalizace)
Energetika
Rybářství
Územní plánování
Geologie, hydrogeologie
Geodézie, kartografie
Těžba nerostných surovin
Lesní hospodářství
Ostatní:
Vzdělání a výzkum
Vysoké školy
Výzkumné organizace
Sdružení
Sdružení měst a obcí
Euroregiony
Nevládní neziskové organizace
Bezpečnostní složky
Požární sbory
Armáda
Policie
Občané (široká veřejnost)
7. Typ uživatele dle očekávané míry zapojení
Uživatele lze rozdělit na aktivní a pasivní na základě jejich ochoty a připravenosti účastnit se projektu.
Rozdělení z tohoto hlediska je výhodné např. pro šíření nových výsledků či žádosti o komentáře a
připomínky ze strany uživatelů.
Většina rozdělení uživatelů určitého systému vychází z pravomocí uživatelů, od kterých se odvíjí
dostupnost Tato dělení jsou už přímo spjata s využíváním informačních systémů.
Tab. 17 Přehled potenciálních uživatelů komunální sféry (Tandem)
Uživatelé (a
jejich počty
v ČR)
Působnost / odpovědnost v
oblasti*
Potenciální přispění
do projektu
Kategorie uživatele
v projektu**
Krajské úřady
(14)
Nakládání s vodami
(povolení, rozhodnutí,
souhlasy, vyjádření na krajské
úrovni)
Plánování v oblasti vod
Ochrana vod a vodních
Poskytnutí
dat
Regionální
strategické plány
Klíčový aktér
129
zdrojů
Povodňová
protipovodňová opatření
Vyjádření ke stavbám
Rozhodování ve věcech
hraničních vod
Vodních děl
Obecní, městské
úřady a
magistráty
(6248)
Nakládání s vodami
(povolení, rozhodnutí,
souhlasy, vyjádření na lokální
úrovni)
Poskytnutí
dat
Vymezení
problémů
vyplývajících ze
socio-
ekonomických
parametrů oblasti
Konečný uživatel,
Ostatní
* Zdroj: Zákon č. 254/2001 Sb. ve znění pozdějších předpisů a vlastní zjištění
** Dle kapitoly 4, bodu 1 Typ uživatele podle potenciální míry ovlivnění uživatele navrhovaným systémem
Ze zprávy k projektu TANDEM.“Výzkum a vývoj modulového systému pro tvorbu aplikací
využitelných v oblasti integrovaného vodního hospodářství“, Ev.č.: FT-TA2/009.
Mgr. Zuzana Kodrová et al.: Etapa č. 03 Zpracování uživatelské analýzy v podnikové, komunální i
státní sféře s ohledem na povinnosti ČR vyplývající z Water Framework Directive
Kvantifikace – kolik uživatelů a kolik z toho současně.
130
24Analýza uživatelských potřeb Neexistuje jedna univerzálna definícia požiadaviek. Slovník softwarovej terminológie (IEEE Standard
Glossary of Software Engineering Terminology, 1990) definuje požiadavku ako:
1. Podmienku alebo funkciu, ktorú užívateľ potrebuje pre riešenie problému alebo dosiahnutia nejakého cieľu.
2. Podmienku alebo funkciu, ktorú musí systém alebo jeho časť splňovať, aby vyhovel zmluve, štandardu, špecifikácií alebo inému dokumentu, ktorý sa na ňu formálne vzťahuje.
3. Dokumentovanú podobu niektorého z predchádzajúcich dvoch bodov.
Požiadavku by sme tiež mohli charakterizovať ako podmienku vyžadovanú klientom k vyriešeniu
problému alebo dosiahnutia cieľa.
Požiadavky popisujú ako sa má IS správať a aké má mať vlastnosti. Môžu však predstavovať aj
obmedzenie pre proces vývoja aplikácie (Katolický, 2007).
Obr. 23 Schéma jednotlivých disciplín pre prácu s požiadavkami (Wiegers, 2008).
24.1 Typy požiadaviek
Na požiadavky sa dá nazerať s rôznych pohľadov, každý pohľad môže definovať určitú skupinu
požiadaviek.
Základní rozdělení může být na požadavky:
Funkční: o Zjištěné přímo u uživatele o normativní - vyplývající z legislativy, normativů, standardů, administrativních
pravidel o Určené z podnikových dokumentů
Systémové
Někdy se ještě vymezují „podnikatelské požadavky“, které představují vhodné pozadí pro celý projekt.
24.1.1 Funkčné požiadavky – zjištěné u uživatele
Funkčné požiadavky popisujú funkcionalitu systému, popisujú čo musia programátori naprogramovať,
aby užívatelia mohli využívať IS. Môže to byť napr.:
Tab. 18 Príklady funkčných požiadaviek
131
ID Popis FP01 Do systému sa môže prihlásiť ľubovoľný počet užívateľov. FP02 Prístup do systému bude autentizovaný FP03 Systém sa užívateľa vždy spýta, či má vybraného klienta naozaj zmazať ...
24.1.2 Podnikateľské požiadavky
Zdrojom podnikateľských požiadaviek je hlavne manažment a ostatné riadiace orgány spoločnosti.
Definujú hlavné ciele spoločnosti, ktoré chce dosiahnuť prostredníctvom používania nového
informačného systému. Podnikateľské požiadavky pomáhajú definovať víziu projektu a jeho rozsah.
Niektorý autori napr. (Wiegers, 2008) doporučujú zapisovanie podnikateľských požiadaviek do
nového dokumentu, ktorý obsahuje určité podnikateľské pozadie celého projektu. Dokument obsahuje:
1. Podnikateľské požiadavky a spôsob ako merať ich úspešné splnenie. a. Finančné
i. Dosiahnuť do X mesiacov Y % podiel na trhu. ii. Zvýšiť hrubý zisk terajšieho podnikania z X % na Y %
iii. atď. b. Nefinančné
i. Vyhovieť konkrétnym predpisom. ii. atď.
2. Návrh riešenia ako základná predstava o fungovaní systému. 3. Rozsah o obmedzenie jednotlivých verzií systému. 4. Podnikateľský kontext, ktorý hovorí o jednotlivých aktéroch IS a ich motivácií pri využívaní IS.
Taktiež sa na tomto mieste definuje obchodné obmedzenia pre jednotlivých aktérov a ich názory k novo budovanému IS.
24.1.3 Funkční požadavky normativní (podnikatelská pravidla)
Podnikateľské pravidlá si môžeme predstaviť ako firemné predpisy, zákony ktoré firma musí
dodržiavať, priemyslové štandardy atď. Wiegers tvrdí, že podnikateľské pravidlá nepatria medzi
požiadavky na softvér, pretože existujú mimo hranice systému.
Analytik môže podľa podnikateľských pravidiel rýchlejšie objaviť požiadavky ktoré by sa pri
rozhovore so zamestnancom nemuseli objaviť. Môžeme ich tiež chápať ako vyššiu úroveň abstrakcie
požiadaviek.
Podnikateľské pravidlá sa môžu zapisovať do samostatného katalógu podnikateľských pravidiel.
Tab. 19 Podnikateľské pravidlá
ID Popis Typ pravidla Statické -dynamické
Zdroj
PR01 Platbu odpočítaním od mzdy, môžu využívať iba zamestnanci s plným úväzkom
Obmedzenie Statické Účtovné oddelenie
PR02 Celková fakturačná cena sa vypočíta ako cena jednotlivých položiek krát ich počet plus DPH plus cena za dopravu
Výpočet Dynamické Predajňa; zákon o daniach
...
Typ pravidla Pravidlá môžeme deliť na:
1. Fakty, sú to základné pravdy o danom podnikaní.
132
2. Obmedzenie na niektoré užívateľské alebo systémové akcie. 3. Aktivátory ako spúšte akcií. 4. Výpočty. 5. Implikácie sú podobné ako aktivátory, ale namiesto akcie implikujú fakty.
Statické – dynamické Definuje pravdepodobnosť s akou sa dané pravidlo v čase bude meniť.
24.1.4 Systémové požiadavky
Uživatele „nezajímají“ z hlediska vyžadovaných funkcí (co má systém dělat), ale jsou nezbytné k
zajištění adekvátního fungování systému, zajištění správného fungování systému, správné architektury
pro další rozvoj atd.
Definujú podporné informácie o systéme (Výkon, kapacita, hardware,...)
Môžeme ich rozdeliť na:
1. Bezpečnostné požiadavky 2. Kvalitatívne požiadavky 3. Výkonnostné požiadavky
Tab. 20 Systémové nefunkčné požiadavky (Wiegers, 2008)
ID Popis VP01 Maximálne veľkosť latencie webového rozhrania musí byť 10 sekúnd. BE01 Všetky transakcie budú šifrované podľa normy ...
Jiné hledisko:
Podľa (Kano, 1994) existujú tri typy požiadaviek z hlediska popisu stavu znalostí:
Bežné požiadavky
o Zákazník je schopný ich pomenovať s pomocou zhotoviteľa systému.
Základné (očakávané) požiadavky
o Zákazník nepovažuje za podstatné s takýmito požiadavkami zhotoviteľa systému
dotazovať, pretože ich považuje za samozrejmé a automaticky predpokladá že budú
do systému implementované.
Neznáme požiadavky
o Požiadavky ktoré zákazník nie je schopný pomenovať, pretože nedokáže myslieť
dostatočne abstraktne a neočakáva ich. Takéto požiadavky musí odhaliť analytik.
24.2 Zber vývoj a špecifikácia požiadaviek
Každý typ požiadaviek pochádza z iného zdroja a potrebuje iný spôsob publikácie.
24.2.1 Proces vývoja požiadaviek
Na úplný začiatok je potrebné stanoviť proces pre vývoj požiadaviek, v ktorom sa popíše ako bude
naša spoločnosť zbierať, analyzovať, dokumentovať a kontrolovať požiadavky.
Celý proces vývoja požiadaviek nie je lineárny, dokumentuje to obr. 2.
133
Obr. 24 Proces vývoja požiadaviek, zdroj (Wiegers, 2008).
V tomto procese analytici komunikujú so zákazníkmi, kladú im otázky, počúvajú ich odpovede
a sledujú ich pri práci, túto časť procesu nazývame zber informácií. Nazbierané informácie sa
spracujú, definujú sa funkčné požiadavky, táto časť sa nazýva analýza. Takto nazbierané
a analyzované informácie zapíšeme vo forme rôznych dokumentov a diagramov nazývaných aj
požiadavková dokumentácia, táto časť sa nazýva špecifikácia. Nakoniec zákazníkov zástupca
potvrdzuje správnosť, presnoť a úplnosť požiadavkovej dokumentácie, poprípade opravíme chyby,
táto časť sa nazýva kontrola. Celý proces je iteratívny a opakuje sa.
Tento popis je však značne zjednodušený a preto presne nezodpovedá realite, slúži iba ako
architektúra popisujúca vývoj požiadaviek.
Účastníci vývoja požiadaviek 1. Investor. 2. Zástupca užívateľov. 3. Vedenie projektu. 4. Vývojári. 5. Analytici.
Wiegers (2008) tvrdí že analytik je rola ktorú niekto hrá na danom projekte, a nemusí to byť nutne povolanie. Môže byť v podstate pridelená komukoľvek kto sa zúčastňuje na projekte, dokonca aj užívateľovi.
6. Testeri projektu. 7. iný účastníci.
Všeobecne rozoznávame tri role, ktoré vstupujú do procesu vývoja požiadaviek:
1. Zadávateľ, sú to zvyčajne ľudia z vedenia spoločnosti, ktorý sa rozhodli zadovážiť IS. 2. Riešiteľ je spoločnosť ktorá bola požiadaná o zhotovenie a implementáciu IS. 3. Používateľ je osoba ktorá bude vyvinutý IS využívať.
Potrebné schopnosti analytika ako ich definoval Wiegers (2008).
1. Umenie poslúchať. 2. Umenie pýtať sa a viesť rozhovor. 3. Analytické schopnosti. 4. Moderátorské schopnosti. 5. Pozorovacie schopnosti. 6. Vyjadrovacie schopnosti. 7. Organizačné schopnosti. 8. Modelovacie schopnosti. 9. Sociálna inteligencia. 10. Nápaditosť.
24.2.2 Rozsah projektu a vízie projektu
Jedná sa o dokument, ktorý sprostredkuje predstavu o projekte všetkým zúčastneným stranám.
Definuje jasné ciele a priority projektu. Môže sa pozvoľné meniť s jednotlivými verziami projektu.
134
V skratke by sme mohli povedať, že sa jedná o dokument ktorý definuje základné ciele projektu
pomocou ktorých dosiahneme maximálny „príjem“ pre firmu.
Dokument by mal byť rozhodujúci pri možných konfliktoch medzi účastníkmi projektu, ktorých
rozdeľuje určitý politický pohľad na daný problém.
1. Podnikateľské požiadavky 1.1. Pozadie 1.2. Podnikateľská príležitosť 1.3. Podnikateľské ciele a meradlá úspechu 1.4. Potreby zákazníkov alebo trhu 1.5. Podnikateľské riziká
2. Vízia riešenia 2.1. Hlavné vízie 2.2. Hlavné funkcie 2.3. Predpoklady a závislosti
3. Rozsah a obmedzenie 3.1. Rozsah prvej verzie 3.2. Rozsah ďalších verzie 3.3. Obmedzenie
4. Podnikateľský kontext 4.1. Profily účastníkov 4.2. Priority projektu 4.3. Prevádzkové prostredie
Obr. 25 Šablóna pre popis vízie a rozsahu dokumentu (Wiegers, 2008)
24.2.3 Hľadanie tried užívateľov a ich vlastnosti
Riešiteľ hľadá rôzne skupiny užívateľov ktoré budú systém používať, každá skupina môže mať svoje
špecifické potreby, prístup do systému, a pod.
Každá trieda používateľov má svoje vlastné požiadavky a priority ktoré vyplývajú s ich úloh ktoré
riešia. Niekedy sa za užívateľskú triedu berie aj ďalšie softwarové alebo hardwarové komponenty.
Nájdené triedy užívateľov sa zaznamenávajú do dokumentu v ktorom je poznačený aj počet
užívateľov v jednotlivých triedach a ich zjednodušené úlohy. Z dokumentu by sa mali dať odhadnúť
približné počty a frekvencia užívateľských transakcií, ktoré budú zástupcovia jednotlivých tried na
systém vytvárať. (Wiegers, 2008)
24.2.4 Výber produktových šampiónov
Zadávateľ sa snaží vyberať ideálnych zástupcov z jednotlivých tried užívateľov, takéto osoby sa
nazývajú produktový šampióni. Tieto osoby potom zastupujú danú užívateľskú triedu. Niekedy sa
môže jednať aj o beta testerov a pod. Produktový šampióni sa aktívne zúčastňujú na procese tvorby
systému a majú právo rozhodovať o užívateľských požiadavkách.
Výber jednotlivých zástupcov tried môže byť značne problematický. Na jednej strane by sa malo
vyberať z ľudí ktorý sú nadšenci pre danú problematiku. Na druhej strane by sa malo dať pozor aby
výsledný produkt(systém) nebol vhodný iba pre takýchto nadšencov, ale aby bol prístupný aj pre
bežných užívateľov. Preto sa ako reprezentanti tried, často vyberajú experti aj menej zdatný užívatelia.
Každý produktový šampión slúži ako hlavné rozhranie medzi analytikom požiadaviek a členmi jednej
triedy užívateľov. (Wiegers, 2008)
24.2.5 Výber skupiny typických užívateľov (focus groups)
Zhotoviteľ vyberá reprezentatívnu skupinu užívateľov ktorej dá otestovať buď minulú verziu systému,
alebo podobný systém aký bude vyvíjať. Vyžiada si ich názor na daný systém ohľadne funkcií
a kvality. Táto skupina nemá rozhodovacie právo ako produktový šampión. (Wiegers, 2008)
135
24.2.6 Hľadanie prípadov použitia
Analytik spolu s produktovými šampónmi hľadajú všetky prípady použitia, alebo úlohy s ktorými má
software budúcim užívateľom pomáhať. Hľadajú tiež všetky interakcie systému s užívateľom. Zistené
informácie zapíšeme podľa našich štandardov.
Prípad užitia popisuje interakciu medzi aktérmi ktorý sú súčasťou vonkajšieho sveta
a uzavretým systémom s pohľadu aktéra, pričom aktér môže byť osoba, iný systém, čas, hardware.
Vývojári pracujú na základe funkčných požiadaviek, teda na popise správania sa jednotlivých častí
systému. Prípady užitia sú pre nich nedostatočné. V reálnom svete však neexistuje čiara ktorá
dokonale oddelí funkčnú požiadavky od prípadov použitia, preto niekedy považujeme prípady použitia
za funkčné požiadavky. Prípady použitia sa zapisujú textovo alebo graficky ako na obr. 4. (Wiegers,
2008)
Obr. 26 USE CASE (zdroj: http://tinyurl.com/64um95x)
Dokumentácia prípadov použitia
Textový zápis prípadov použitia môžu byť rôzne, jednu možnosť zobrazuje následující tabuľka.
Tab. 21 Textový zápis prípadu užitia, zdroj (Wiegers, 2008)
Use Case ID: 1
Názov: Objednávanie chemikálie
Autor: Karl Wiegers Autor posledných zmien: Jan Novák
Dátum vytvorenia: 4. 2. 2001 Dátum poslednej zmeny: 5. 7. 2002
Aktéri: Objednávateľ
Popis: Jednoznačný popis prípadu užitia. Ako aktér alebo aktéri komunikujú so
systémom a ako systém odpovedá aktérom.
Vstupné podmienky: Čo musí byť splnené aby prebehol celý proces úspešne.
Výstupné podmienky: Jednotlivé výstupné podmienky napr.
Bežná cesta: 1.0 Názov cesty
Krok - 1
....
Krok - n
Alternatívne cesty: 1.0 Názov cesty
Krok - 1
....
Krok - n
Výnimky: Definujeme jednotlivé kroky ktoré budú inicializované ak nastane výnimka.
1.0 Názov výnimky
136
Krok - 1
....
Krok - n
Vložené prípady
použitia:
Odkazujeme sa na ďalšie spresňujúce prípady užitia, ktoré súvisia
s popisovaným prípadom užitia.
Priorita: Priorita je dôležitosť funkcionality pre zákazníka.
Frekvencia používania: Akú frekvenciu používania prípadu užitia predpokladáme.
Podnikateľské pravidlá: Odkazy na nájdené podnikateľské pravidlá ktoré súvisia s daným prípadom
použitia.
Zvláštne požiadavky: Špecifické požiadavky
Predpoklady:
Poznámky a problémy:
Scenáre použitia (testovacie scenáre) Scenár použitia je vlastne „simulácia“ prípadu použitia. Zobecnením skupiny scenárov sa dá objaviť
nejaký prípad použitia, alebo niekoľko prípadov použitia. Niekedy môžeme podľa scenára zistiť, že
prípad použitia nerieši všetky možnosti scenára použitia, teda že existujú alternatívne scenáre, ktoré
nepatria do danej skupiny scenárov užitia. (Wiegers, 2008)
24.2.7 Hľadanie systémových udalostí a ich odpovedí
Jedná sa o hľadanie vnútorných udalosti na ktoré systém musí reagovať a zároveň aj hľadanie
očakávaných odpovede na tieto udalosti. Môže sa napríklad jednať o automatickú zálohu dát, alebo
o automatický import dát v daný čas a pod.
Na hľadanie systémových udalostí a ich odpovedí sa používa tabuľka udalostí a odpovedí, ktorá
obsahuje udalosti a odpoveď systému na tieto udalosti. Odpoveď systému závisí aj od stavu systému.
Tab. 22 Tabuľka udalostí a odpovedí, zdroj (Wiegers, 2008).
ID Udalosť Stav
systému
Odpoveď
systému
1 Nastaviť
pomalý
chod
stieračov.
Stierače
vypnuté.
Nastaviť
motor
stieračov na
pomalý chod.
...
Výsledkom hľadania sú užívateľské požiadavky.
Možné nástroje při zjišťování:
Dotazník
Řízené rozhovory
Workshop
Sledování při práci
Hledání nápadů
Studium starších projektů a konkurečních projektů
24.2.8 Požiadavkový workshop
Požiadavkový wokshop sa chápe ako príležitosť na stretnutie vývojárov a zákazníkov. Takéto
stretnutia sú moderované moderátorom, ktorý workshop plánuje, vyberá účastníkov a vedie
k úspešnému výsledku.
137
Na workshopoch sa zúčastňujú aj programátori, ktorý majú jedinečnú príležitosť reagovať na
užívateľov, dokážu odhaliť napríklad nesplniteľnú alebo problematickú požiadavku z technického
hľadiska.
Dôležitý aspekt požiadavkových workhopov je ich postupné opakovanie, v dostatočných časových
intervaloch (cca 1-2 dni). Takéto opakované stretnutie slúži na utriedenie a kontrolu nazbieraných
informácií s predchádzajúcich workshopov. (Wiegers, 2008)
Základné pravidlá workshopu (Wiegers, 2008)
1. Dohoda na základných pravidlách wokshopu 2. Dodržovanie stanoveného rozsahu 3. Niektoré informácie je potrebné uložiť na neskôr 4. Obmedzenie diskusie časovým limitom 5. Tvorba menších skupín ale kvalitnejší účastníci 6. Všetci účastníci sa zapájajú
Triedenie získaných informácií (Wiegers, 2008)
Analytik musí kvantá zistených informácií transformovať do stručných, úplných zoznamov
a kategorizovať ich, pre neskoršie zdokumentovanie a použitie. analytik môže zistiť nasledovné
kategórie informácií:
1. Podnikateľské požiadavky 2. Návrhy riešení 3. Definíciu dát 4. Obmedzenie 5. Požiadavky na vnútorné rozhranie 6. Kvalitatívne parametre 7. Funkčné požiadavky 8. Podnikateľské pravidlá 9. Prípady použitia a scenáre 10. Iné
24.2.9 Sledovanie užívateľov pri práci, rozhovor
Analytik strávi určitý čas s užívateľom aktuálneho systému alebo s užívateľom ktorý bude využívať
nový systém. Analytik sleduje pracovné postupy užívateľa. Pri tejto činnosti môže: overiť správnosť
už získaných požiadaviek, zistiť chyby terajšieho systému a zistiť ako by nový systém lepšie poslúžil
užívateľovi.
Analytik diskutuje s užívateľom, vedie s ním rozhovor o jeho úlohách vo firme, práve tieto úlohy sa
týkajú užívateľských požiadaviek. Analytik by mal z rozhovoru pochopiť skutočné potreby
užívateľov. Postupne kladie doplňovacie otázky „prečo?“ pýta sa na rôzne varianty možného
užívateľského postupu, zisťuje možné výnimky „ako by sa mal systém chovať keď nastane akákoľvek
udalosť“.
Analytik by mal byť schopný nájsť funkcie a vlastnosti systému, ktoré užívatelia očakávajú alebo ich
predpokladajú ako samozrejmosť.
Rozhovory môžu byť s jednotlivými užívateľmi alebo aj skupinami užívateľov, analytik sa snaží
všetky zistené požiadavky zobecniť.
Postupne analytik zaznamená zdroj a obsah každého požiadavku, pre prípad že v budúcnosti bude
potrebné spresniť danú požiadavku. (Wiegers, 2008)
24.2.10 Hľadanie nápadov na zlepšenie staršieho systému
V prípade ak spoločnosť vlastní alebo vlastnila starší systém, tak je možné hľadať nové požiadavky
v zoznamoch chybových hlásení, žiadostiach o zlepšení systému a informácie od technickej podpory
staršieho systému.(Wiegers, 2008)
138
24.2.11 Požiadavky minulých projektov alebo konkurenčných projektov
Niekedy sú potreby užívateľov podobné vo viacerých projektoch, preto je vhodné prispôsobiť už
získané požiadavky pre nových užívateľov. Môže sa jednať napríklad o spôsoby autentifikácie
a verifikácie, a pod. Niekedy sa na trhu nachádza konkurenčný produkt, ktorý môžeme analyzovať
(reverse engineering). (Wiegers, 2008)
24.3 Analýza požiadaviek (specifikace požadavků)
Analýzou požiadaviek dostávame postupne čoraz presnejšie a správnejšie požiadavky. Analýza
pomáha nazerať na požiadavky z viacerých pohľadov a tým pádom ujasňuje predstavu jednotlivým
členom týmu. Požiadavky sa analyzujú pomocou rôznych techník, ktorých kombinácia napomáha
k lepšiemu pochopeniu požiadaviek, zo strany klienta, ako aj zo strany zhotoviteľa systému.
24.3.1 Dátový slovník
Pre záznam dátovej štruktúry a ustálenie dátovej terminológie sa používa dátový slovník, kde sa
zaznamenávajú jednotlivé definície dátovej štruktúry. Dátový slovník spojuje definíciu dát, ktorá je
porozhadzovaná na rôznych miestach v požiadavkovej dokumentácií. Dátový slovník býva prepojený
s ER a DFD diagramom.
Zápis v dátovom slovníku sa skladá zo znakov v tabuľke č.
Tab. 23 Znaky v dátovom slovníku, zdroj (http://tinyurl.com/6kekw5r)
Znak Definícia
= Údaj je zložený
+ Logické spojenie
{} Opakovanie obsahu v zátvorkách
[] Obsah zátvoriek obsahuje výčet možností ktoré sú oddelené
znakom“|“
() Parameter môže ale nemusí existovať
*…* Poznámka, komentár
@ Označenie primárneho kľúča
Príklady zápisu v dátovom slovníku:
adresa = +číslo
+ ulica
+ číslo domu
+ psč
+ mesto
+ štát
* adresa osoby alebo firmy*
Stav objednávky = [
|neúplná
| prijatá
| pripravená
| doručuje sa
| doručená
]
*Jednotlivé stavy objednávky z menu*
24.3.2 Modelovanie požiadaviek
Pre komplexný pohľad na daný problém alebo nejasnosť, je vhodné kombinovať textový popis
a grafickú interpretáciu problému.
Diagramy dátových tokov (DFD) Pomocou DFD diagramov sa znázorňujú jednotlivé kroky podnikateľských procesov, alebo prevádzky
navrhovaného systému. Pre prehľadnosť sa môžu DFD diagramy zapísať vo viacerých úrovniach.
139
Obr. 27 Diagram dátových tokov, (zdroj: http://tinyurl.com/6c39c4e)
ER, ERD diagramy ED a ERD diagramy pomáhajú pochopiť dátovú štruktúru navrhovaného systému.
Obr. 28 ERD diagram, Zdroj (http://www.ipower.sk/dbs/firebird/uloha1.html)
Stavové (prechodové) diagramy Stavové diagramy pomáhajú vývojárom pochopiť ako budú medzi sebou komunikovať jednotlivé
triedy systému. Často sa tento diagram konzultuje so zákazníkom, ktorý dokáže zhodnotiť správnosť
daného diagramu.
Stavové diagramy sa môžu používať aj pre popis užívateľských rozhraní, kde sa modelujú
komunikácie užívateľa s dialógovým oknom systému.
140
Obr. 29 Stavový diagram Zdroj (http://cs.wikipedia.org/wiki/Stavov%C3%BD_diagram)
Diagram tried
Obr. 30 Diagram tried Zdroj (http://tinyurl.com/5rcx7va)
Diagram tried s pohľadu požiadaviek pomáha modelovať, čo so systémom potrebujú urobiť užívatelia
a funkcie ktoré budú na túto činnosť potrebovať. Taktiež pomáha modelovať potrebnú dátovú
štruktúru, pomocou atribútov jednotlivých tried.
Rozhodovacie diagramy Analytik sa snaží rozhodovacím diagramom pokryť všetky možné kombinácie podmienok, ktoré môžu
pri modelovaní funkcionality systému nastať. Pri neošetrení všetkých možností, musí neúplnú
funkcionalitu doprogramovať podľa seba, čo môže spôsobiť značné problémy, alebo neošetrenú
podmienku konzultuje s analytikom.
141
Obr. 31 Rozhodovací diagram, zdroj(http://tinyurl.com/6xnj5x7)
24.3.3 Navrhovanie prototypov
Budúci užívatelia vyvíjaného systému mávajú často problém s presnou definíciou svojich požiadaviek,
je to úplne bežné a normálne. Opisovať niečo slovom, textom alebo obrázkom môže byť pre veľa ľudí
pomerne zložite. Preto existuje technika ktorá užívateľom pomáha pri podrobnejšom a zároveň
zrozumiteľnejšom definovaní svojich požiadaviek, nazýva sa softwarové prototypovanie .
Táto technika je opísaná frázou „I’ll know it when I see it” (až to uvidím tak to poznám) , v skratke
IKIWISI.
Softwarový prototyp môže byť, statický návrh, funkčný model systému, simulátor, video, emulácia,
atď.
Prototyp má podľa Wiegersa (2008) tri základné úlohy:
1. Ujasniť a doplniť požiadavky 2. Preskúmať rôzne varianty návrhu 3. Postupne návrh transformovať do hotového stavu
Horizontálny prototyp Tento prototyp sa nesnaží popísať zložitú funkcionalitu systému ale iba užívateľské rozhranie. Na
užívateľoch pozorujeme ako s prototypom pracujú, aké majú výhrady k práci a či podľa prototypu
dokážu splniť svoju úlohu. Takýto prototyp nemusí mať integrovanú žiadnu funkcionalitu, poprípade
stačí že obsahuje iba simuláciu funkcionality. (Wiegers, 2008)
Obr. 32 Horizontálny prototyp v papierovej podobe Zdroj: (http://tinyurl.com/6daudwk)
142
Vertikálny prototyp Vertikálne prototypy umožňujú testovanie robustnosti a použiteľnosti architektúry alebo funkcií
budovaného systému. Ich podstatou je silná implementácia funkcionality systému a slabá alebo žiadna
implementácia rozhrania. (Wiegers, 2008)
Jednorazový (skúšobný) prototyp Pri jednorazovom prototype sa neprihliada na kvalitu kódu, odolnosť, spoľahlivosť, ale na rýchlu
implementáciu s rôznymi zmenami. Je potrebné aby sa takýto prototyp nedostal do produkčného
systému, ale rovno zahodil. Často tento prototyp využívajú programátori ktorý dostali neúplné alebo
nejasné požiadavky a potrebujú otestovať návrh svojho riešenia. (Wiegers, 2008)
Evolučný prototyp Evolučný prototyp je opakom jednorazového prototypu, často sa používa pre inkrementálny vývoj
systémov. Pri evolučných prototypoch je potrebné zacieliť na: architektúru systému a kvalitný kód.
Tento typ prototypu sa vyvíja iteratívne, prvá verzia je pilotný systém, ostatné verzie sú postupne
vylepšované, vývoj končí finálnou verziou systému. Tento druh prototypu sa používa pri tvorbe
webových aplikácií. (Wiegers, 2008)
143
Jednorazový
prototyp
Evolučný prototyp
Horizontálne
prototypy Spresnenie prípadov
použitia a funkčných požiadaviek
Hľadanie chýbajúcich požiadaviek
Skúšanie rôznych variant užívateľského rozhrania
Implementácia hlavných prípadov použitia
Implementácia ďalších prípadov použitia podľa priorít
Implementácia a vylepšovanie webových stránok
Úprava systému podľa často sa meniacich podnikateľských požiadaviek
Vertikálne
prototypy Analýza uskutočniteľnosti Implementácia
a vylepšovanie základných komunikačných funkcií typu klient/server
Implementácia a optimalizácia základných algoritmov
Testovanie a ladenie výkonu
Obr. 33 Použitie softwarových prototypov, prezvané z (Wiegers, 2008)
Hodnotenie prototypov Prototyp testujú užívatelia podľa nejakého scenára použitia, analytik sa ich spytuje na otázky typu:
1. Implementuje prototyp funkcionalitu tak ako ste si predstavovali? 2. Nechýba Vám nejaká funkcionalita? 3. Napadajú Vás chybové stavy na ktoré prototyp nemyslel? 4. Sú v prototype nejaké funkcie naviac? 5. Zdá sa Vám navigácia logická a úplná? 6. Sú niektoré postupy v prototype zložité a zbytočné?
Zistené informácie zaznamenáme ako špecifikácie požiadaviek. (Wiegers, 2008)
24.3.4 Priority požiadaviek
Stanovenie priority požiadaviek rieši, kedy bude daná požiadavka implementovaná. Definovanie
priorít pomáha manažmentu plánovať jednotlivé verzie systému. Definovaním priority sa môžu do
systému dodať podstatné funkcie hneď na začiatku a menej podstatné až na koniec. Niekedy menej
podstatné požiadavky neimplementujeme vôbec.
Prioritu požiadaviek definuje klient v spolupráci s programátorom, ktorý ho môže upozorniť na určité
zvýšené náklady a riziká spojené z danou požiadavkou a tým pádom nasmeruje klienta
k správnejšiemu nastaveniu priority požiadavku. Programátor tiež môže implementovať niektoré
požiadavky s malou prioritou ale zároveň s malými nákladmi, rizikami a vplyvom na architektúru.
(Wiegers, 2008)
144
Rozdelenie priority požiadaviek:
Požiadavky s vysokou prioritou Bez požiadavku by podnikový systém nemohol správne fungovať.
Požiadavky so strednou prioritou Požiadavky sú dôležité ale dajú sa odložiť.
Požiadavky s nízkou prioritou Požiadavky ktoré užívatelia nepotrebujú bezprostredne k svojej práci, niekedy sa nemusia
vôbec implementovať.
Ostatné požiadavky Tieto požiadavky sa neimplementujú.
24.3.5 Rozdelenie požiadaviek medzi podsystémy
Zložité systémy sa skladajú z viacerých systémov a je potrebné utriediť požiadavky medzi jednotlivé
podsystémy.
24.3.6 QFD (Quality Function Deployment)
QFD sa snaží identifikovať ktoré požiadavky sú pre zákazníka najpodstatnejšie, teda požiadavky ktoré
sa budú postupne prenášať do vyvíjaného systému.
Obr. 34 QFD matica zdroj (http://tinyurl.com/4qqwvy4)
Presnosť tejto techniky je úmerná správnym odhadom výhod, nevýhod, nákladov a rizík požiadaviek.
145
24.4 Správa požiadaviek
V projekte sa odsúhlasením požiadaviek končí etapa vývoja požiadaviek a začína etapa správy
požiadaviek. Každý člen týmu má prístup k aktuálnej verzií požiadavkovej dokumentácie.
Každý požadavek musí mít svůj identifikátor a zdroj.
V tomto momente môže nastať situácia, ktorá bude znamenať zmenu už schválenej požiadavky.
Na začiatku projektu sa vypracuje a príjme, komplexný systém správy požiadaviek, ktorý bude
obsahovať techniky a potupy pre zber, správu a riadenie zmien požiadaviek. (Wiegers, 2008)
Verzovanie požiadaviek Každá verzia požiadavkovej dokumentácie má svoje číslo (identifikátor), každý člen vývojového týmu
musí vedieť, ktorá verzia je aktuálna. Zmeny v jednotlivých verziách musia byť jednoznačne
dokumentované.
Príliš veľká aktivita zmien požiadavkovej dokumentácie má negatívny dopad na termíny projektu
a jeho celkovú cenu.
Súčasťou požiadavkovej dokumentácie by mala byť aj história zmien kde je uvedené:
1. Dátum každej zmeny 2. Autor zmeny 3. Popis zmeny
Pri menších projektoch sa požiadavky zaznamenávajú do niekoľkých samostatných
dokumentov(súborov), ale pri väčších projektoch môže tomto spôsobe dôjsť k:
1. Zlej aktualizácií a synchronizácií jednotlivých dokumentov 2. Nepohodlným prístupom k jednotlivým požiadavkám 3. Problematickej komunikácií týmu s požiadavkami 4. Problematické zmeny v súvislosti s viac užívateľským prístupom k dokumentom 5. ....
Preto je vhodné použiť komerčné produkty ktoré sa špecializujú na správu požiadavkovej
dokumentácie a sú založená na databázovej technológií. (Wiegers, 2008)
Komisia pre riadenie zmien Komisia pre riadenie zmien môže byť jednotlivec alebo skupina, ktorá rozhoduje o prijatí alebo
zamietnutí navrhovaných zmien, nových funkcií a opravy chýb. Komisia má stanovené rozhodovacie
pravidlá a rozhodovací proces, taktiež má definované svoje právomoci.
Komisia pre riadenie zmien musí pri svojom rozhodovaní určiť správny pomer medzi pozitívnymi
dopadmi a negatívnymi dopadmi, ktoré vyplývajú z jej rozhodnutí. (Wiegers, 2008)
24.4.1 Stav požiadaviek
Sledovanie stavu požiadaviek má za úlohu presnejšie popísať v ako vývojovom štádiu sa dané
požiadavky nachádzajú. V priebehu správy požiadaviek sa požiadavky môžu nachádzať v týchto
stavoch:
Predložený Požiadavka bola predložená oprávneným členom týmu.
Schválený Schválená požiadavka prešla analýzou a plánovaným dopadom na konkrétnu verziu vyvíjaného
systému. Účastníci procesu schvaľovania sa dohodli na prijatí požiadavky a vývojári súhlasia s jej
implementáciou.
146
Implementovaný Pre implementovanú požiadavku bol napísaný a s časti otestovaný programový kód.
Otestovaný Požiadavka bola otestovaná, to znamená, že bola overená jej funkčnosť pri integrácií do vyvíjaného
systému. Takáto požiadavka sa považuje za splnenú.
Zmazaný Schválená požiadavka bola zmazaná. Zaznamenáva sa kto ju zmazal a prečo bola zmazaná.
Zamietnutý Požiadavka bola navrhnutá ale nakoniec sa s ňou pri implementácií nepočíta. Je potrebné poznačiť aj
dôvod zamietnutia a autora ktorý zamietnutie navrhol. Takéto požiadavky sa zaznamenávajú preto,
aby sa im v budúcnosti predchádzalo.
24.5 Kontrola požiadaviek
Dopady nepresných alebo chybných požiadaviek bývajú fatálne v implementačnej fáze, preto sa
vývojársky tým snaží toto riziko maximálne eliminovať. Kontrola požiadaviek môže byť priebežná.
Kontrola sa snaží zistiť:
1. Aby špecifikácie správne popisovali požadované vlastnosti systému, ktoré sú potrebné pre uspokojenie jednotlivých účastníkov projektu.
2. Aby boli požiadavky správne odvodené zo systémových požiadaviek, podnikateľských pravidiel a ďalších zdrojov.
3. Aby boli požiadavky úplné a kvalitné 4. Aby si požiadavky navzájom neprotirečili. 5. Aby požiadavky poskytovali primeranú základňu pre návrh a implementáciu systému.
(Wiegers, 2008)
Jednotným znakom všetkých typov kontrol je testovanie systému na chybové stavy s pohľadu
požiadaviek. Kontrolór sa snaží zistiť interakciu systému na rôzne vstupné dáta, na rôzne podmienky
a na výnimky ktoré môžu nastať. Často sa pre túto činnosť využívajú testovacie scenáre.
Kontroly požiadaviek sa vykonávajú pomocou: recenzovania, inšpekcie požiadaviek, podmienok
prijatia.
24.5.1 Recenzie / audit
Jedná sa o prezeranie výstupu práce na projekte, niekým iným ako autorom, táto osoba je recenzent.
Recenzent hľadá v tomto výstupe chyby a nejasnosti, táto činnosť sa volá recenzné riadenie. Na
recenznom riadení sa môže zúčastňovať viacero recenzentov. Recenzné riadenie sa môže vykonať aj
pomocou workshopov. (Wiegers, 2008)
Neformálna recenzia Neformálna recenzia je vo svojej podstate nesystémová, pretože nedefinuje presnú štruktúru
výstupného formátu recenzného riadenia. Neformálnu recenziu zvyčajne vykonáva spolupracovník,
alebo skupina spolupracovníkov, ktorý sa vyjadrujú pomocou svojich pripomienok k danému riešeniu.
Formálna recenzia Formálna recenzia je systémová, prebieha pomocou presne určeného procesu a aj jej výstupy sú
v presne určenej štruktúre.
147
Inšpekcia požiadaviek Špecifickým typom recenzného riadenia je inšpekcia. Predmetom inšpekcie môže byť akýkoľvek
výstup na projekte od plánu projektu po zdrojový kód. Cieľ inšpekcie je hľadať chyby a možné
zlepšenia.
Inšpekcia sa vykonáva pomocou inšpekčného týmu, ktorý je zložený z:
1. Autorov posudzovaného výstupu. 2. Autor ktorý špecifikovali (spresnili) posudzovaný výstup, alebo zástupca zákazníka ktorý
bude overovať, že špecifikácia obsahuje úplný a správny popis jeho požiadaviek. 3. Zástupci vývojárov a testerov. 4. Ľudia ktorý hľadajú ako zmeny spôsobené inšpekčným týmom ovplyvnia ostatné časti
systému.
V inšpekciách by mal požiadavky čítať a vykladať podstatu kontrolovaných požiadaviek, niekto iný
ako autor, čaká sa či čitateľ pochopí požiadavky inak ako autor danej požiadavky. Výsledky inšpekcie
sa zaznamenávajú takým spôsobom, aby bol jasne a presne popísaný nájdený problém. (Wiegers,
2008)
24.5.2 Podmienky prijatia
Testy prijatia vykonáva zákazník aby zistil či splňuje podmienky prijatia. Podmienky prijatia(testy
prijatia) by mali zhodnotiť či systém splňuje požadovanú funkcionalitu a je pripravený na nasadenie
do reálneho prostredia.
Ak spoločnosť ktorá vytvárala systém úspešne prebehne testami prijatia, znamená to, že správne
pochopila požiadavky ktoré od nej zákazník žiadal.
24.6 Záver k analýze uživatelských požadavků
Problematika riadenia požiadaviek je značne zložitá, existuje v nej mnoho problémov ktoré sú
spôsobené chýbajúcou terminológiou a podceňovaním teoretických poznatkov.
Katolický a Wiegers hovoria o podceňovaní riadenia požiadaviek, čo má za následok
nedodržanie zmluvných termínov a nadmerné riziko nepochopenia potrieb zákazníka. Wiegers
tvrdí že chyby pri analýze požiadaviek sú zodpovedné za 40 až 60 percent všetkých chýb
softwarových projektov, to znamená že približne polovicu problémov bolo možné odstrániť
z príslušných projektov.
Písanie kvalitných požiadaviek si vyžaduje čas a prax. Veľmi dôležitými faktormi v procese správy
požiadaviek je správna organizácia práce, jasný cieľ a hlavne kvalitný ľudia.
148
25 Strategie zavádění IS
Pokud použijeme pro vývoj IS klasický strukturovaný vodopádový přístup nebo pokud řešíme tuto
etapu nákupem hotového aplikačního programového vybavení, pak dospějeme v určitý okamžik do
situace, kdy máme instalovaný hardware a musíme začít systém plnit daty, zaškolit uživatele, provést
potřebné organizační změny a přejít ze starého způsobu práce na nový.
Zde si uvedeme obecně čtyři základní strategie přechodu na nový systém.
Při souběžné strategii pokračuje činnost starého systému spolu se systémem novým po dobu několika
pracovních cyklů (podle charakteru systému obyčejně několik týdnů, či měsíců), a to tak dlouho,
dokud nový systém nepracuje spolehlivě a starý systém může být proto opuštěn. Je to velmi bezpečná
strategie, ale velmi náročná na pracovní kapacity, protože pracovníci musejí souběžně vykonávat dvojí
práci, což je může stresovat a naladit proti novému systému. Někdy se proto najímají po tuto dobu
externí pracovníci. Někdo musí také porovnávat výsledky nového systému se starým a v případě
rozdílností určit příčiny a provést korekce nového systému.
Při pilotní strategii se zavede nový systém např. jednom v jednom oddělení, pobočce či kanceláři a
teprve po jeho ověření se zavede nový systém naráz v celé organizaci. Při pilotní aplikace se získávají
jednak zkušenosti se zaváděním, odstraní se všechna problémová místa a mohou se na ní vyškolit i
pracovníci ostatních oddělení, pro které je aplikace rovněž určena.
Postupnou strategii použijeme především u rozsáhlejších systémů se složitými vzájemnými vazbami.
Obyčejně začínáme úlohami, které jsou podmiňující pro ostatní úlohy a postupujeme v zavádění
v souhlase se životním cyklem výrobku, či služby. Typická je tato strategie např. pro rozsáhlé
komplexní systémy řízení výroby. Je to strategie, která musí být velmi dobře naplánovaná a která je
časově náročná. Často se v průběhu zavádění ukáže potřeba dalších doplňujících projektů, či aplikací
zejména pro spolupráci se starým systémem.
Při nárazové strategii ukončí starý systém práci např. v pátek a v pondělí již zahájí práci nový systém.
Sobota a neděle jsou obyčejně věnovány na nezbytné ukončovací a startovací přípravné práce. Je to
velmi riskantní strategie, ale vyhneme se při ní více pracem spojeným se souběžností dvou systémů. Je
vhodná všude tam, kde souběžná činnost dvou systémů je nemožná, např. v důsledku nedostatečných
kapacit výpočetní techniky, nebo tam, kde není dostatek pracovních kapacit pro pokrytí nároků obou
systémů.
Je samozřejmé, že reálný život je mnohem pestřejší než jsou výše uvedené čtyři strategie, a že často
vhodně kombinujeme tyto strategie podle potřeby. Tak se např. nejčastěji kombinuje postupná
strategie s paralelní nebo nárazovou.
149
26 Spolehlivost IT a testování SW Spolehlivost IT je rozhodující pro spolehlivost celého IS a ovlivňuje i výrazně jeho efektivnost.
Kromě toho nespolehlivá IT může odradit uživatele od jejího používání a vést někdy až k jejímu
všeobecnému odmítnutí, protože malá spolehlivost degraduje IT ze všestranného pomocníka na věc,
která je jenom na obtíž a zdržuje. V mnohých aplikacích, jako je např. přímé řízení výroby, může mít
nespolehlivá IT i tragické následky.
Spolehlivost IT je výslednicí celého komplexu faktorů počínaje technickou spolehlivostí jednotlivých
částí, přes jejich stavební uspořádání až po operační systémy umožňující detekovat a eliminovat chyby
hardwaru. Samostatnou kategorií je spolehlivost, tj. bezchybnost funkce aplikačních programů, ale o
tom bylo již pojednáno v kapitolách předchozích zabývajících se vývojem IS.
Pod pojem spolehlivost IT zahrnujeme nejen nebezpečí vzniku poruchy, ale i náročnost odstraňování
poruch a náročnost údržby IT pro její udržení v provozuschopném stavu.
Nicméně výchozí je technická spolehlivost každé části (zdroje IT), která je vyjádřitelná údajem střední
doby mezi dvěma poruchami (Mean Time Between Failure – MTBF). Je povinností každého výrobce
udávat tento údaj pro dodávaná zařízení. Součastná zařízení dosahují značně vysoké technické
spolehlivosti, která se pohybuje řádově v desítkách až stovkách tisíc hodin MTBF.
Vedle MTBF je dobré znát i střední dobu nutnou k odstranění poruchy a restartu systému (Mean Time
To Restart – MTTR). Ta je výslednicí nejen konstrukčního principu (výměnnost dílů), ale i celého
komplexu servisních služeb dodavatele (sklady náhradních dílů, vyškolený technický personál apod.).
Vedle vlastního času opravy musíme do této doby počítat i čas nutný k restartu systému, což je zase
záležitostí softwarového zabezpečení a celého systému organizace práce výpočetního systému
(kontrolní body, umístění záložních kopií atd.). V tomto ukazateli se již může IT výrazně lišit podle
jednotlivých dodavatelů. Obyčejně „dražší“ dodavatel nám zaručuje výrazně nižší MTTR v důsledku
dokonalejšího a rozsáhlejšího servisu.
Dalším faktorem, který musíme uvážit při posuzování nezbytné míry spolehlivosti IT, je průměrná
doba výpočtů. Máme-li totiž úlohy s dlouhými zpracovatelskými chody, roste nebezpečí jejich
„zhroucení“. Čili čím delší máme úlohy, tím spolehlivější musí být IT.
Oba výše uvedené průměrné časy můžeme složit v jediný ukazatel pohotovosti:
Kp = MTTRMTBF
MTBF
Případ, kdy výpočetní systém má vysokou hodnotu mezi poruchami a současně i delší dobu k restartu,
je všeobecně příznivější, než případ, kdy se porouchá každou chvíli a je rychle opravitelný. Důvodem
je to, že na „těžší havárii“ systému se mohu připravit zálohovým zpracováním. Druhý případ
představuje vyloženě nespolehlivý systém, kterého se musíme vyvarovat.
Jako velmi užitečné u rozsáhlých terminálových systémů se doporučuje zřízení „hot-line“ telefonní
linky, resp. „help desk“ služby pro uživatele pro případ, že jim nefunguje terminál, ať už je toho
příčinou cokoliv. Tyto služby samozřejmě zabezpečuje Útvar pro IS, resp. provoz výpočetního
střediska.
Do testování spolehlivosti IT zahrneme i testování SW.
26.1 Testování SW
Obecně se při testování SW využívá tzv. black box testing a white box testing
(http://en.wikipedia.org/wiki/Software_testing). Jak název napovídá, u černé skříňky nemá testující
subjekt žádné informace o vnitřní implementaci systému, zatímco u bílé skříňky může využít takové
informace využít.
Software testing methods are traditionally divided into black box testing and white box testing (http://en.wikipedia.org/wiki/Software_testing). Black box testing treats the software as a black
150
box without any knowledge of internal implementation. White box testing utilizes the knowledge about the algorithm implementation. The advantage of black box testing is that we are not constrained by the programmer’s approach and it is more probable to detect bugs. Unfortunately, black box testing may cause a situation where some parts of the SW are not tested at all, while other parts are redundantly tested.
Uživatelský přístup k testování je však potřebné doplnit také o technická hlediska kvality služby,
protože bez zajištění splnění jejich dostatečné úrovně nelze uživatele uspokojit bez ohledu na vlastní
seznam dostupných témat.
Testování a hodnocení geoportálů lze provádět zejména z hlediska obsahového (např. volba
dostupných dat), funkčního (nástrojového, zaměřeného na nabídku síťových služeb) a síťového
(rychlost poskytování informací, výskyt chyb apod.). Je zřejmé, že všechny tyto 3 části musí být pro
uživatele uspokojivě vyřešeny a že případné nedostatky v některém z aspektů nemohou být
kompenzovány jinými výhodami (Menascé 2002).
Funkcionality geoportálu popisuje např. Man (2007). Síťové aspekty geoportálu mohou být dále
rozlišeny, zda jde o základní parametry (obecně výkon, dostupnost, doba odezvy atd.), nebo se jimi
měří výkon při činnostech specifických pro geoportály, jako je provádění prostorových operací,
překreslování, vizualizace apod.
Na rozdíl od uživatelské funkcionality, vyjadřované zpravidla expertním uspokojením nad dostupnými
datovými tématy, jsou technické aspekty zpravidla kvantitativního charakteru, tedy dobře měřitelná,
zdánlivě objektivní, opakovatelná a automatizovaně vyhodnocovatelná. Důležitá je jejich
srozumitelnost, protože pouze dobře srozumitelná kritéria budou správně aplikována a interpretována
zejména širší veřejností (nespecialisty), mezi nimiž hraje důležitou roli exekutiva.
Pro testování na straně klienta je důležité i další odstupňování času zpracování požadavků. Podle
některých autorů je za limitní čas odezvy považována hodnota 10 s, což je označováno za maximální
čas, pokdy se uživatel soustředí na dialog aplikace (Krejcar a Černohorský 2008). Doporučuje se
rozdělovat čas odezvy na dobu do 0,1 s, kterou lze považovat za plynulou reakci, na dobu do 1 s
(zaznamenané zdržení, ale uživatel nevyžaduje žádnou akci) a do 10 s (ztráta pozornosti, uživatel se
začíná věnovat jiné činnosti). Jiní autoři uvádějí, že ke snížení výkonnosti uživatele dochází, jakmile
se odezva zvýší nad 4 sekundy, a za kritickou mez považují dobu odezvy 8 sekund, kdy za touto
hranicí již uživatel není schopen udržet svoji pozornost na aplikaci. (Krejcar, 2010).
Příklad pro testování síťových webových služeb:
U serverů je potřebné rozdělit testování na stranu serveru a na stranu klienta. První typ popisuje např.
a používají se metriky jako jsou: Number of Visit Actions, Session Duration, Relationship between
Visit Actions and Session Duration, Average Time per Page, Duration for Individual Pages. Druhý typ
vhodně využívá automatizovaného testování na straně klienta. Podle [3] lze odlišit 5 základních typů
takového testování: Test precondition data, Functional testing, Stress test functionality, Capacity
testing and Load and performance testing.
Velmi často se používají zátěžové testy, které simulují očekávané chování uživatelů v současném
počtu přístupů, odpovídajícímu očekávanému provozu. Naproti tomu stress testování vytváří schválně
vysoké zátěže pro simulaci chování ve špičkách a abnormálních situacích.
Jaká kritéria se pro sledování obecně používají? Zpravidla jde o:
zpoždění (Time delay), které je vyjádřeno buď “latency” nebo “response time”. Definice a jejich
rozdělení lze najít např. na wikipedii, ve [2], v případě webových služeb pak [5].
výskyt chyb (Error occurrence) – používá se průměrný čas mezi výskytem 2 chyb nebo procenta
výskytu chyb během “session” nebo při jistém počtu iterací.
dostupnost (Availability) - zpravidla procentuální vyjádření času, kdy je služba dostupná.
151
27 Ochrana informačních systémů
27.1 Význam ochrany IS
Je bohužel známou pravdou, že hodnotu čehokoliv si uvědomíme až v okamžiku, kdy to ztratíme. To
platí plně i o IS. O tzv. „počítačové kriminalitě“ byly napsány již stovky článků a publikací a stále
vznikají nové a nové příběhy. Z toho plyne, že je to problém vysoce aktuální.
V důsledku toho, že se IS stávají stále významnějším faktorem dlouhodobého úspěchu či naopak
neúspěchu podniku, musí jejich ochraně věnovat nejen vedení, ale všichni pracovníci podniku zvláštní
pozornost. Vedení podniku si musí být vědomo toho, jaké ztráty může přinést podniku poškození,
zneužití nebo zničení jejich IS a podle toho věnovat příslušné úsilí i prostředky na ochranu svého IS.
Ochranou IS rozumíme komplex organizačních, programových, technických a sociálně-personálních
opatření spojených s minimalizací možných ztrát vzniklých podniku v důsledku poškození, zničení či
zneužití jeho IS.
Ochrana IS by měla být organickou součástí komplexu veškerých ochranných opatření, která jsou
v podniku uplatňována na jakékoliv podnikové zdroje.
Škody, které mohou vzniknout podniku, je možno rozdělit do následujících kategorií:
1. Přímé ztráty v důsledku nelegálních finančních transakcí, které jsou typické především pro
finanční podniky (banky, pojišťovny atd.).
2. Nepřímé ztráty v důsledku přerušení normálního chodu podniku (výroby či expedice) a z toho
vyplývající ztráty z nerealizovaných tržeb (a tudíž zisku). Kromě toho může dojít i ke ztrátě
dobrého jména podniku, což může vést k trvalé ztrátě zákazníků.
3. Nekvalitní, resp. špatné rozhodování v důsledku špatných informací (např. chybného
rozhodnutí o přijetí zakázky, na kterou nemáme potřebné kapacity).
4. Zvýšené náklady na získání potřebných informací, které nemohu získat v důsledku
porouchaného IS.
5. Zvýšené náklady na odstranění důsledků škod z výpadku IS (např. slevy při nedodržení
termínů, příplatky za urgentní dodání materiálu, který nebyl včas objednán apod.).
Ochrana IS se vztahuje nejen na data, ale i na programy, protože jejich poškození samozřejmě rovněž
vede k nesprávné funkci systému. Proto je třeba se věnovat problematice ochrany IS po celou dobu
jeho životního cyklu, tj. jak v předprojektové přípravě, tak při projektování a programování, a
samozřejmě i po dobu jeho rutinního používání.
Ochranná opatření vždy přinášejí zvýšení pořizovacích i provozních nákladů a pro pracovníky IS i
uživatele vždy přinášejí určitá nepohodlná omezení. Samozřejmě, že tyto náklady a úsilí musí být
přiměřené odhadnutým ztrátám, nicméně se všeobecně považuje za přiměřené věnovat 10 až 20 %
z celkových nákladů na IS na zabezpečení jeho ochrany.
27.2 Příčiny ohrožení IS
Identifikace a klasifikace možných příčin ohrožení IS je nezbytná k tomu, abychom dovedli správně
určit potřebná ochranná opatření. Příčiny ohrožení IS můžeme členit především na úmyslné a
neúmyslné. K úmyslným příčinám řadíme především tzv. počítačové pirátství, jehož cílem je
proniknout do našeho IS a buď neoprávněně získat data, která jsou jinak předmětem utajení, nebo je
neoprávněně měnit. Takový systém pracuje zdánlivě normálně a odhalení takovéhoto poškození je
velmi obtížné. Někdy může být cílem i úmyslné zničení IS (atentáty). V obou případech ještě musíme
rozlišit, zda se jedná o poškození z příležitosti, či o systematickou cílevědomou činnost.
K úmyslným příčinám je třeba počítat také ohrožení IS prostřednictvím počítačových virů, i když toto
ohrožení není většinou motivováno poškozením určitého konkrétního IS. Tento soudový mor osobních
počítačů trápí jejich uživatele již od samého počátku éry PC a s jejich propojováním do lokálních sítí
roste stupeň ohrožení IS podniku.
U neúmyslných příčin rozlišujeme dále podle původu příčiny způsobené:
152
- lidským faktorem, tj. zejména chybami operátorů, chybami vstupních dat, neautorizovaným
přístupem atd.
- programovým vybavení, tj. chybami v programech, ať již systémových či aplikačních
- technickým vybavením, tj. selháním některé části počítače, či komunikačního vybavení
- prostředím, tj. klimatizací, výpadkem napájení, přírodní katastrofou apod.
27.3 Ochranná opatření
Ochranná opatření by měla nejen chránit systém před chybami, ale měla by samozřejmě i odhalovat
vzniklé chyby a pokud možno i opravovat (/napravovat) tyto chyby nebo jejich důsledky. Systémy
odolné proti poruchám nazýváme také někdy jako robustní systémy.
Za bezpečnost IS odpovídá samozřejmě vedoucí příslušné organizace nebo její části, které IS slouží
k řízení. Při současných složitých organizačních strukturách podnikového systému řízení obyčejně
ještě rozlišujeme opatření realizovaná na všeobecné podnikové úrovni, na úrovni systémové a na
opatření zavedená pro každou jednotlivou aplikační oblast samostatně.
27.3.1 Všeobecná ochranná opatření
K opatřením na všeobecné podnikové úrovni patří především stanovení celkové bezpečnostní politiky
podniku. K tomu se často zřizuje bezpečnostní komise jakožto poradní orgán vedení. Jejím úkolem je
především trvale zdokonalovat systém ochranných opatření, prověřovat a schvalovat nové projekty
z hlediska ochrany, vyhledávat zranitelná místa zejména simulováním havárií a tvorbou scénářů
pronikání do systému, ovlivňovat personální politiku včetně organizační struktury podniku apod.
Velmi významným preventivním opatřením je trvalá výchova všech pracovníků podniku
v uvědomování si důležitosti IS pro podnik, jeho možné zranitelnosti a vytváření všeobecného klimatu
odpovědnosti všech pracovníků za ochranu IS. K všeobecným opatřením patří samozřejmě i
všeobecná fyzická ochrana objektů a fyzická kontrola pohybu osob.
K programově technickým opatřením na všeobecné úrovni patří zejména dodržování jednotné
programovací a projektové metodiky respektující zásady strukturovanosti a transparentnosti programů,
včetně jejich řádné dokumentace udržované v aktuálním stavu. Neměla by samozřejmě chybět ani
řádně vedená dokumentace provozu výpočetního střediska u dávkových úloha a automaticky vedená
dokumentace transakcí (log – on) u interaktivních systémů. Samozřejmostí by měla být všeobecná
snaha podniku používat jenom spolehlivý hardware.
Do této kategorie ochranných opatření zahrnujeme i veškeré protivirové ochrany, zejména důsledné
používání legálního softwaru, pravidelné antivirové kontroly a minimalizace práce s disketami.
K organizačně personálním opatřením na všeobecné úrovni patří především přesné a jasné vymezení
funkcí a kompetencí, provozní řád všech výpočetních systémů, systematické vedení a bezpečné
skladování záložních kopií. Pro případy mimořádných událostí by měl být vypracován plán záložního
zpracování využitím externích kapacit na základě smluvního dojednání.
27.3.2 Ochranná opatření na úrovni aplikací
Zásadním programově-technickým opatřením na ochranu dat na úrovni aplikací je především otázka
autorizace, tj. oprávnění provádět určité transakce jen určitými osobami. Tato se zabezpečí pomocí
přístupových hesel, která „odemknou“ příslušnou transakci. Tato hesla se samozřejmě musí pravidelně
měnit. Autorizace se může týkat nejen oprávnění spustit nějakou transakci, či získat přístup
k nějakému souboru, ale např. i určitých omezení v možných vkládaných datech, např. určitý
pracovník nemá právo vystavit objednávku s vyšší cenou než 1 milión Kč.
Zásadní kontrolní úsilí věnujeme kontrole vstupních dat. Začínáme již u vzniku transakce, kde by
mělo být zabezpečeno, že každá provedená transakce bude předána k počítačovému zpracování. Jde
především o systémy, ve kterých probíhá tzv. sekundární sběr dat a kde je možno transakci (např.
výdej zboží ze skladu) provést mimo rámec počítačového zpracování. Zde se spoléháme na
systematické srovnávání stavu datových souborů se skutečností.
K vlastní kontrole správnosti vstupních dat máme k dispozici několik osvědčených technik:
153
1. Kontrola kontrolní číslicí, která se používá především pro zajištění správnosti klíčových
položek, sloužících k identifikaci. Spočívá v tom, že k hodnotě klíče přidáme kontrolní číslici,
jejíž velikost je vytvořena nějakým matematickým výpočtem z číslic klíče. Tak např. kontrolní
číslice „modulo 11“ je vytvořena tak, že váhový součet číslic odečteme od nejbližšího vyššího
násobku 11 a výsledek nám dá žádanou kontrolní číslici. Tak např. při (dřívějším)
šestimístném IČO strojní fakulty ČVUT 0022691 je kontrolní číslice 1, protože
6 x 0 + 5 x 2 + 4 x 2 + 3 x 6 + 2 x 9 = 54, což po odečtení od 55 dá 1.
2. Kontrola kontrolními součty, která se používá především pro kontrolu úplnosti zpracování.
Spočívá v tom, že každý vstupní záznam (větu) opatříme navíc součtovou položkou obsahující
součet všech numerických hodnot ve větě. (Samozřejmě, že jiný, než kontrolní smysl takto
vypočtená hodnota nemá.) Při vstupu věty kontroluje systém automaticky shodu této hodnoty
s vypočtenou. Kromě tohoto tzv. „horizontálního“ kontrolního součtu opatřujeme v případě
dávkového vstupu celou dávku vstupních vět ještě tzv. „vertikálním“ kontrolním záznamem,
jeho položky obsahují součty hodnot odpovídajících položek ve všech větách vstupní dávky.
3. Kontrola příslušnosti k požadované doméně reprezentuje skupinu tzv. logických kontrol a
spočívá v tom, že kontrolujeme formát a velikost vstupní položky, např. u položky množství
musí být číselná hodnota, u položky pohlaví musí být buď muž nebo žena apod. Do této
kategorie kontroly patří i kontrola sémantické integrity při práci s databází, kdy se např.
kontroluje, zda číslo zákazníka uvedené na objednávce je v souboru zákazníků apod.
4. Šifrování dat, které se provádí u zvláště citlivých dat, která by neměla být použitelná
neoprávněnou osobou. Spočívá v převedení otevřeného textu do nesrozumitelné podoby. Pro
šifrování se používá jak technických, tak i programových prostředků, které provádějí buď
transpozici, tj. přeskupení původního textu podle určitých pravidel, nebo substitucí, tj. náhradu
výchozích znaků jinými.
V průběhu zpracování sledujeme především správnost všech provedených zápisů do pamětí a to
jednak systémem paritních bitů, jednak systémem kontrolních čtení (read-after-write). Oba druhy
těchto kontrol provádějí soudobé prostředky IT automaticky.
Na výstupu kontrolujeme především u dávkových tištěných výstupů jejich úplnost (mohlo dojít
k přetržení či ukončení papíru) a zabezpečujeme, aby se tištěné výstupy dostaly do správných rukou.
Slouží k tomu většinou oddělení výstupní kontroly ve výpočetních střediscích.
154
28 FUNKČNÍ ANALÝZA Podle Šarmanové (1997).
28.1 Životní cyklus informačního systému
Než si popíšeme nejrozšířenější metodu pro záznam funkční analýzy, zopakujme si několik pojmů ze
základů softwarového inženýrství.
Existuje řada způsobů, jak rozložit vývoj informačního systému do etap. Liší se obvykle jen různou
mírou podrobnosti či přeléváním některých činností z jedné etapy do druhé. Seznámíme se s jedním
často uváděným životním cyklem informačního systému, nazývaným obvykle vodopádový:
Zadání zadání popsáno slovně, pseudokódy
metody strukturované analýzy + prototyp
Analýza objektově orientovaná analýza
strukturovaný návrh
Návrh objektově orientovaný návrh
strukturované programování + dokumentace
Kódování objektově orientované programování
Testování
Předání
Provoz
Obr. 35 Životní cyklus IS
1. Zadání - SPECIFIKACE POŽADAVKŮ
Etapu zahájí nápad někoho využít pro řešení něčeho počítač.
Zadání je nutno rozpracovat do první verze písemného zadání. To provádí osoba znalá oboru, která
nemusí nic vědět o počítači, zadání formuluje slovně. Proto však zadání bývá často nejednoznačné,
neúplné, nepřesné. Protože cena za předělání programu po realizaci takového zadání by byla vysoká,
je vhodné upřesňovat zadání již v této etapě.
Ideální by bylo použití nějakého formálního jazyka, to však zadavatel obvykle neumí. Proto se na této
úrovni dělají kompromisy ve formě zpracování zadání.
2. Analýza - SPECIFIKACE PROBLÉMU
Etapa znamená převod slovního zadání či jinak zpřesněného popisu reality do tvaru, který může
sloužit jako podklad pro zahájení návrhu řešení a pro implementaci. Nazývá se obvykle analýzou
problému nebo specifikací problému. Analýza znamená studium problému (jeho poznání, popis,
namodelování) dříve, než se začnou provádět akce směřující k řešení problému. Za řešení se považuje
155
i odůvodněné negativní stanovisko, odmítnutí realizace. Současně se provádí návrh ovládání programu
a jeho vzhledu. Pro analýzu je navržena řada metod, některými se budeme zabývat v následujících
kapitolách.
3. Návrh - NÁVRH IMPLEMENTACE, programování ve velkém
Po ukončení specifikace (zadavatel souhlasí s formulací specifikace) se zahájí návrh implementace tj.
dekompozice řešení na malé moduly. Používá se metody shora dolů nebo zdola nahoru nebo
kombinované, definují se funkce jednotlivých modulů.
4. Programování - IMPLEMENTACE A DOKUMENTACE, programování v malém
Předání návrhu modulů dílčím programátorům, implementace dílčích částí, ladění modulů, syntéza
modulů, ladění subsystémů a systému. Zpracování dokumentace programu.
5. Testování - TESTOVÁNÍ SYSTÉMU
Testování, zda se chování systému shoduje se specifikací a dokumentací.
6. Předání - ZAVEDENÍ SYSTÉMU DO PROVOZU
Systém otestovaný na zkušebních datech ve zkušebním provozu se po odstranění chyb předá uživateli.
To znamená přechod na nový způsob práce, zaškolení uživatele, napojení na okolí systému, na vstupy
(na informace vstupující z okolí do systému) a výstupy (kam směřují informace vystupující ze
systému).
7. Provoz - PROVOZ, ÚDRŽBA A ROZVOJ
Po zaběhnutí provozu se dále sleduje provoz, provádí se opravy chyb u programu i dokumentace,
provádí se údržba, registrují připomínky, návrhy na zlepšení, doplnění ap.
Informační systém a jeho dimenze
Z hlediska zkoumání informačního systému a z hlediska typů metod používaných k jeho vývoji
rozeznáváme obvykle tři základní dimenze: data, operace a čas. Jim odpovídají tři základní typy
analýzy IS: datová (objektová), funkční a časová.
Modely programových systémů mohou být orientované několika způsoby nebo jejich kombinacemi:
Procesně orientovaný přístup (funkční přístup) modeluje systém jako množinu spolupracujících
akcí; systém je modelován pomocí procesů, které jsou propojeny datovými toky; procesy realizují
funkční transformace dat v orientovaných datových tocích (systémy pro podporu technických
výpočtů, expertních systémů ap.).
Datově orientovaný přístup modelují základní datové struktury, funkční stránka je druhotná.
(většinou u informační systémy).
Dynamicky orientovaný přístup (časový přístup) modeluje chování systému v časové posloupnosti
stavů systému (real-time systémy).
Objektově orientovaný přístup modeluje systém jako množinu spolupracujících objektů, kde
operace působící na objekty jsou zapouzdřeny v samotných objektech.
Datové analýze IS a datovým modelům jsme věnovali předcházející kapitoly. V této kapitole se
seznámíme s nejčastěji používanou metodou pro popis funkční analýzy.
156
28.2 Funkční analýza a funkční model
Modelem vždy rozumíme abstraktní obraz reality. Při analýze se vytváří modely - pro správné
pochopení systému a pro komunikaci mezi Uživatelem, Analytikem a Realizátorem. První dvojice (U-
A) vyžaduje srozumitelné prostředky, druhá (A-R) přesné. Také funkční model jako výsledek funkční
analýzy musí být srozumitelný zadavateli a přitom dostatečně přesný pro budoucí implementaci.
Funkční analýza vychází opět ze zadání IS. Je výhodné, když se v zadání vyskytují následující prvky:
Seznam funkčních požadavků: požadavky na vnitřní chování systému; např. očíslovaný seznam
výstižných krátkých textů; mohou být seskupeny podle charakteru a významnosti.
Seznam událostí / reakcí jako model vnějšího chování systému; např. jako tabulka dvojic událost /
reakce formou krátkých textů.
Požadované vstupy a výstupy: které údaje, případně v jaké formě a formátu do systému vstupují a
které jsou od systému očekávány.
Z nich vytváří analytik funkční model, vyjadřující logický sled a podstatu transformací údajů do
systému vstupujících a ze systému vystupujících. Vnější pohled jen hrubý, vnitřní podrobně
rozpracovaný pro jednotlivé akce.
28.3 Diagram datových toků
Diagram datových toků (Date Flow Diagram, DFD) je grafický prostředek pro návrh a zobrazení
funkčního modelu systému. Podobně jako ERD je dostatečně jednoduchý a názorný i pro uživatele a
může sloužit i k upřesňování zadání.
DFD popisuje dynamiku systému, vyjadřuje transformace dat z jedné formy do druhé; modeluje
funkce systému pomocí grafu a přitom používá následujících základních grafických prvků:
procesy
paměti (zásobárny dat) datový tok proces
terminátory
datové toky paměť terminátor
Proces (transformace, funkce)
provádí transformaci dat vstupních na data výstupní, realizuje nějakou funkci nad daty. Zakresluje se
kruhovým uzlem v grafu (někdy elipsou, obdélníkem), v uzlu je zaznamenán název funkce.
přijetí
zaměstnance
Procesy se dále rozlišují na
Datové procesy, které vyjadřují fyzickou transformaci dat, tj. změnu reprezentace dat nebo změnu
stavu dat, modifikaci údajů, vznik nových údajů, zrušení údajů; úkolem datového procesu tedy je
zpracovávat data.
Řídicí procesy, které provádějí řídicí akce, řídí vzájemné časové návaznosti procesů; používají se
k popisu real-time charakteristik aplikace; na rozdíl od datových procesů řídicí procesy
nezpracovávají data.
Každý proces v DFD má svůj název a jednoznačné číslo. Čísla je vhodné přidělovat hierarchicky:
součástí čísla je číslo nadřízené funkce, do jejíhož rozkladu popisovaná funkce patří, druhou část tvoří
jednoznačné číslo v rámci úrovně rozkladu (nemusí mít žádný vztah k pořadí provádění funkce).
157
Datový tok
Datový tok vyjadřuje přesun dat nebo informací z jedné části systému do jiné, z okolí systému do
systému nebo ze systému do jeho okolí. Znázorňuje se hranou (úsečkou, obloukem) opatřenou šipkou,
znamenající směr toku. Je možné použít šipky i oboustranně, když jde o dialog a stejná data tekou
oběma směry.
nový zaměstnanec
Datový tok musí mít známý obsah a je zase pojmenovaný. Datové toky obsahují data, která jsou do
systému vkládána, systémem zpracovávána nebo ze systému vypouštěna. U programových systémů
jsou obsahem datových toků zprávy, čísla, znaky, záznamy, bity. Datové toky jsou jednou z forem
propojení (komunikace) procesů.
Datová paměť (Data store, zásobník)
Paměť je místo dočasného uchování dat pro jejich pozdější využití.
Je to obecnější pojem než soubor. Může být implementován jako pole, soubor textový, soubor
databázový, kniha, šanon a leccos jiného. Používá se tam, kde mezi procesy existuje časové zpoždění
při předávání dat. Znázorňuje se pomocí dvou rovnoběžek, mezi nimi je název paměti.
mzdové údaje
zaměstnanec
Pro každou paměť musí existovat alespoň jeden datový tok směřující do paměti a jeden směřující z
paměti. Datový tok může vyjadřovat 1 výskyt dat, více výskytů dat, část jednoho výskytu či část z více
výskytů. Paměť je pasivní prvek, data do paměti i z paměti musí vždy procházet přes proces. Paměť je
další formou propojení procesů.
Terminátor
Terminátor znázorňuje externí zdroj nebo cíl dat, objekt vně systému, s nímž systém komunikuje.
Může to být člověk, skupina lidí (oddělení), jiný systém ap. Platí pro ně :
terminátory jsou vně systému, toky mezi nimi a systémem představují rozhraní mezi systémem a
vnějším světem,
analytik nemá možnost měnit organizaci a chování entit vně systému ani změnit chování
terminátorů,
vztahy mezi terminátory se v DFD nezachycují; mohou sice existovat, ale nejsou součástí
navrhovaného systému; pokud by měly být terminátory a vztahy mezi nimi zahrnuty do systému, je
třeba DFD reorganizovat.
Graficky se znázorňuje obdélníkem či čtvercem, opět má název.
uchazeč o studium
Při mírném zobecnění můžeme terminátory chápat jako další typ propojení procesů.
158
Hierarchie DFD
Model systému vyjádřený pomocí DFD má hierarchickou strukturu. Jen velmi malý systém je možno
vykreslit jediným diagramem. Proto dle podrobnosti rozkladu obvykle rozlišujeme několik úrovní
DFD: vrchní (top), střední (middle), spodní (bottom).
Pokud se IS vyvíjí postupem shora dolů, začíná se od přehledového diagramu a pokračuje se ke stále
detailnějším diagramům.
Na vrcholu hierarchie je pouze jeden DFD zvaný kontextový. Ten obsahuje celý systém jako jednu
funkci, definuje hranice systému a všechny terminátory - zdroje systému a cílová místa dat. Systém je
zde černá skříňka s definovanými vstupy a výstupy.
Bezprostředním rozkladem kontextového diagramu je DFD úrovně 0. Obsahuje základní funkce
systému (často rozklad na subsystémy) a jejich vztahy vyjádřené prostřednictvím datových toků a
pamětí. Terminátory systému jsou totožné s kontextovým diagramem.
Dále se postupuje v rozkladu funkcí obdobně. Každá funkce, kterou je možno dále rozložit, se
rozkresluje novým diagramem nižší úrovně až na elementární úroveň. Nejnižší úroveň obsahuje
primitivní uživatelsky dále nedělitelné funkce (stanovení, co je elementární fce a co dále dělitelná, je
věcí analytika). Platí však pro ně, že:
- činnosti se provádějí jako celek
- jsou buď celé ruční nebo automatizované
- jsou opakovatelné
- jsou elementární, nemají další podrobnější DFD.
Pravidla tvorby DFD :
1. Při číslování procesů se identifikuje jednak úroveň rozkladu, do něhož funkce patří, jednak proces
v rámci úrovně (např. 2.4.3)
2. Názvy procesů má být stručné, výstižně vyjadřovat funkční náplň procesu (např. Vystavení faktury,
ne Zpracování dat).
3. Složitost jednoho DFD má být taková, aby formát nepřesahoval velikost A4, aby neobsahoval
velké množství uzlů (někdy se doporučuje jen 6 uzlů, rozhodně počet funkcí v rozmezí 3 - 9) a aby
byl srozumitelný pro uživatele, analytika a návrháře
4. Diagram má být technicky správný (konzistentní), srozumitelný, přehledný a esteticky uspořádaný
(bubliny stejně velké, toky se nekříží ap., překreslovat až do grafické dokonalosti).
5. Konzistence DFD, logická soudržnost diagramu. Ta není samozřejmá, protože jedna skutečnost je
díky hierarchickému rozkladu rozkreslena více či méně podrobně na několika DFD.
Pravidla týkající se funkcí
1. Neznázorňují se žádné inicializační ani závěrečné procedury.
2. Neznázorňují se cykly mezi funkcemi.
3. Datové procesy (neřídicí) nesmějí být propojeny řídicími toky.
4. Žádné dvě funkce nesmí mít stejný název.
Pravidla týkající se datových toků
1. Nesmí existovat proces generující výstupy bez pomoci vstupů (perpetum mobile).
2. Nesmí existovat proces, který má pouze vstupy a žádné výstupy (černá díra).
3. Datové paměti smějí být propojeny jen prostřednictvím funkce, tedy datový tok do / z paměti musí
vycházet z / do procesu.
4. Datový tok z / do terminátoru musí procházet přes proces.
5. Datové toky mezi funkcemi znázorňují pouze přenášená data, nevyjadřují volání jedné funkce
druhou ani předávání řízení.
6. Datový tok s týmž názvem může být v DFD použit na více místech pokud název znamená
skutečně tentýž datový tok se stejným obsahem.
7. Doporučuje se dodržovat označení datového toku z/do datové paměti :
159
- bez označení = přenáší se jeden výskyt
- označen datovou pamětí = přenáší se jeden nebo více výskytů
- označen jednoznačně jinak = přenáší se část výskytů.
Pravidla týkající se datových pamětí
1. Paměti se objeví až na té úrovni, kde jsou viditelné funkce do pamětí zapisující a z pamětí čtoucí.
2. Vyhledání pro aktualizaci paměti se chápe jako součást zápisu do paměti, nevyznačují se zvláštní
šipkou; šipka dovnitř znamená jakékoliv provádění změn (vkládání dat, aktualizaci, rušení).
3. V paměti jsou uloženy výskyty dat se stejnou strukturou. Jestliže tok z / do paměti přenáší celý
výskyt, nemusí se pojmenovávat, je určen obsahem a názvem paměti.
28.4 Minispecifikace
Minispecifikace je popis procesu na nejnižší úrovni hierarchického rozkladu. Upřesňuje se logika
procesu (co se dělá když .., jak dlouho ap.). Týká se samozřejmě jen elementárních funkcí. Funkce na
vyšších úrovních nemá smysl specifikovat, protože jsou jen množinou funkcí nižší úrovně.
K minispecifikaci lze použít mnoho forem popisu - od přirozeného jazyka až po formální nástroje
popisu algoritmu. Vždy je však třeba dodržet následující pravidla pro každou minispecifikaci:
1. Existuje jedna pro každou elementární funkci z množiny DFD.
2. Vyjadřuje postup, jak jsou datové toky do funkce vstupující transformovány na výstupní datové
toky.
3. Vyjadřuje, co funkce znamená věcně, nemusí vyjadřovat způsob implementace funkce.
4. Nezavádí redundandní popisy, nevyjadřuje znovu, co je popsáno v DFD nebo v datovém slovníku.
5. Množina výrazů pro popis by měla být jednoduchá a nepříliš rozsáhlá, má používat standardní
vyjadřování.
6. Musí být srozumitelná analytikovi, programátorovi i uživateli.
7. Popis procesu musí být strukturovaný.
Pro minispecifikaci by mohl sloužit běžný programovací jazyk nebo vývojový diagram, ale pro
analytickou práci a pro konzultace se zadavatelem to nejsou vhodné prostředky. Minispecifikace
popisují pravidla transformace vstupních datových toků na výstupní datové toky. Popisují je věcně,
formulují postupy a pravidla, nepopisují implementaci (i proto není vhodný programovací jazyk).
Popisují však všechny podrobnosti transformace dat včetně základního formátování dat na vstupu a
výstupu.
Strukturovaný jazyk
Strukturovaný jazyk je často používaný prostředek pro popis minispecifikací. Původní návrh
strukturované angličtiny pochází od DeMarca.
Strukturovaný jazyk je přirozený jazyk doplněný o omezující pravidla tvorby vět (syntaxe), aby
výsledný popis nepřipouštěl několik různých výkladů. V případě angličtiny lze strukturovaný jazyk
přirovnat jazyku Pascal s tím, že lze používat rozšířených funkcí. Při dodržení pravidel lze definovat
libovolné funkce dle potřeby. V literatuře se často vyskytuje strukturovaná angličtina. Pro popis
programátorům je vhodná, ovšem pro komunikaci s českým uživatelem ne. Jak jsme již zdůrazňovali
vícekrát, je nutné s uživatelem komunikovat jemu co nejbližšími prostředky. Pokud ho budeme nutit k
dodržování pravidel formulování svých tvrzení v češtině, tak se s tím smíří, ale používání anglických
slov bude považovat za programování a řekne si, proč vlastně toho programátora platí.
Slovník jazyka je složen z
rozkazovacího způsobu sloves
pojmů (podstatných jmen) z datového slovníku
rezervovaných slov pro fomulaci logiky procesu
160
Syntaxe jazyka obsahuje následující řídicí struktury pro definování procesu:
jednoduché oznamovací věty
uzavřené rozhodovací formule:
(1) JESTLIŽE <podm>
PAK
JINAK <činnost pro neplatnou podmínku>
(2) VYBER ALTERNATIVU
PŘÍPAD 1: <podm1>
<činnost pro platnou podmínku 1>
PŘÍPAD 2: <podm2>
<činnost pro platnou podmínku 2>
. . .
JINAK <činnost pro neplatnou žádnou podmínku>
uzavřené opakovací formule
(1) DOKUD <podm> DĚLEJ <opakovaná činnost >
(2) PRO KAŽDÝ <paměť> DĚLEJ <opakovaná činnost >
(3) DĚLEJ <opakovaná činnost > DOKUD <podm>
Příklad: Proces, který rozhodne u každého studenta o přidělení prospěchového stipendia.
ZADEJ nejvyšší, průměrné, nejnižší stipendium
PRO KAŽDÉHO studenta DĚLEJ
JESTLIŽE student má uzavřený ročník
PAK
VYBER ALTERNATIVU:
PŘÍPAD 1: studijní průměr < 1.50
přiděl nejvyšší stipendium
PŘÍPAD 2: studijní průměr < 1.50, 1.75>
přiděl průměrné stipendium
PŘÍPAD 3: studijní průměr < 1.80, 2.00>
přiděl nejnižší stipendium
PŘÍPAD 4: studijní průměr > 2.00
žádné stipendium
JINAK
žádné stipendium
28.5 Datový slovník
Důležitou součástí datové analýzy a nástroj k provázání datové, funkční i časové analýzy je datový
slovník (Data Dictionary - DD). Slouží ke slovnímu formalizovanému popisu dat systému z pohledu
uživatele.
Obsahuje :
význam datových pamětí z DFD
význam datových toků z DFD
složení dat v datových tocích (rozložení na atomické položky)
složení dat v datových pamětech
specifikace možných domén a měrných jednotek dat v datových tocích a pamětech
údaje o vztazích mezi entitami z ERD.
Notace zápisu pro složení dat obvykle vychází ze zjednodušené BNF a používá symbolů :
= skládá se z, je definován jako
+ a
(. . .) volitelný člen, výskyt vůbec, jednou nebo vícekrát
{. . .} opakovaný člen jednou nebo vícekrát
161
[. . .|. . .] výběr z možností
*. . .* poznámka
#, @, _ identifikátor klíče v paměti (entitě)
Příklad: adresa = [(titul) + jmeno + prijmeni + ulice
|poštovní schránka] + mesto + (PSC) + (zeme) titul = [pan | paní | slečna | Dr. | Ing. | Profesor] jmeno = {povoleny znak} prijmeni = {povoleny znak} . . . povoleny znak = [A - Z | a - z | | - | ' ]
Celkem tedy by definice datového prvku měla obsahovat :
význam prvku v aplikaci formou poznámky
název = identifikátor prvku
složení prvku, pokud není atomický, elementární
pro každý elementární prvek : * význam prvku
* název prvku
* doména prvku
* formát prvku (datový typ, velikost ve znacích, desetinná místa)
* měrná jednotka prvku
Vhodné je dále k definici datových prvků zaznamenat :
příslušnost k datové paměti
příslušnost k datovému toku
označení klíčových prvků v dané paměti
162
29. Literatura:
Basl, J. : Podnikové informační systémy - podnik v informační společnosti, Grada publishing, Praha,
2002, ISBN 80-247-0214-2.
Dohnal J., Pour J.: Architektury informačních systémů v průmyslových a obchodních aplikacích.
Ekopress 1997. ISBN 80-86119-02-5.
Kapitoly 7.1-7.6, 8,9,10,11
Gála L., Pour J., Prokop T. Podniková informatika, Grada publishing 2006.
Klimeš C. (2006): Informační systémy. Skripta Univerzita Konštantíta Filozofa.
http://www1.osu.cz/~prochazka/rpri/skripta.pdf
Longley, P.A., Goodchild M.F., Maguire D.J., Rhind D.W.: Geographical Information Systems and
Science. Wiley, 2005.
Molnár Z.: Moderní metody řízení informačních systémů. Grada publishing 1992. ISBN 80-85623-07-
2.
Kapitoly 1,2,3,5,6,7.7-7.10, 13, 14
Molnár, skripta
Pokorný J.: Databázové systémy a jejich použití v informačních systémech. Academia, 1992. Pokorný: Konstrukce databázových systémů. ČVUT Praha 1998
Schejbal C., Homola V., Staněk F. Geoinformatika. PONT. 2004. ISBN 80-967611-8-8.
Šarmanová J.: Teorie zpracování dat. Skripta VŠB-TUO. 106 stran. 1997.
Šmída, F. Zavádění a rozvoj procesního řízení ve firmě, 2007, Grada Publishing
Vlček, 1991? Inženýrská informatika
Vondrák I.: 1994.
Vondrák. (2002). Úvod do softwarového inženýrství. Cit. 27. 4 2011. Dostupné na Internete:
http://vondrak.cs.vsb.cz/download/Uvod_do_softwaroveho_inzenyrstvi.pdf
Voříšek J.: Strategické řízení informačního systému a systémová integrace. Management Press, Praha
2006. ISBN 80-85943-40-9.
Vrána I., Richta K.: Zásady a postupy zavádění podnikových informačních systémů. Grada, Praha
2005. ISBN 80-247-1103-6.
Kapitola 7: http://www.systemonline.cz/, http://www.e-komerce.cz/, http://www.infocom.cz/,
www.djgeo.cz/, www.skill.cz, www.adhoc.cz
Zdroje
http://office.ccb.cz/site/top_story/12-2000/debis2.htm
http://www.cpc.iol.cz/strategie/06-Strategie.htm
163
http://www.perseus.cz/outsourc.htm
http://www.tnet.cz/index.php?cat_id=12
IEEE Standard Glossary of Software Engineering Terminology. (1990). Engineering IEEE Standard
Glossary of Software.
Kano. (1994). Attractive Quality and Must-be Hinshitsu.
Katolický. (2007). Requirements Management - SRM. Cit. 4. 4 2011. Dostupné na Internete:
http://srm-aka.akamonitor.cz/
Wiegers. (2008). Požadavky na software. Brno: Computer Press.
Gála L., Pour J., Šedivá Z.: Podniková informatika. Grada 2009. ISBN 978-80-247-2615-1.
VÚV (2001)
Pužmanová R. (2010): http://www.lupa.cz/clanky/grid-computing-ve-firemnim-
prostredi/
Moser T. (2003): Grid computing.
http://www.fi.muni.cz/usr/jkucera/pv109/2003/xmoser_grid_computing.htm
![5. Stejnosměrné stroje [Režim kompatibility]homel.vsb.cz/~mlc37/TZB III (FAST)/Prednasky/13dStS.pdfMechanické charakteristiky DC motoru s cizím buzenímmotoru s cizím buzením](https://img.pdfslide.tips/doc/110x75/60997f3cf0b1750c7613a978/5-stejnosmrn-stroje-reim-kompatibilityhomelvsbczmlc37tzb-iii-fastprednasky.jpg)