Hledejte v chronologicky řazené databázi studijních materiálů (starší / novější příspěvky).

Hlavní požadované vlastnosti MtS

1. Funkčnost MtS
o musí zajišťovat požadované spektrum funkcí pro různorodé skupiny uživatelů v prostředí dynamického vývoje IS
o musí věrně odrážet změny podniku i okolí
 podpora činností spojených s řízením vývoje a provozu IS na strategické, taktické i operativní úrovni
 umožnit koncovým uživatelům rychlou orientaci v rostoucí komplexnosti IS + význam uložených dat
 umožnit vzájemnou informovanost pracovníků podniku a partnerských organizací

2. Pružnost
o umožnit přidávání dalších objektů, vazeb a operací s nimi dle požadavků uživatelů
3. Jednoduchost použití


Přiměřená pracovní náročnost
• umožnit import dat
• většina atributů metaentit je nepovinná
• provoz MtS snižuje pracovní nároky při zajištění jiných úloh, umožňuje redukovat chyby při řízení provozu a vývoje IS/IT a tím snižovat náklady IS/IT

Přínosy
 perspektivní nástroj při řízení rozsáhlých a heterogenních IS
 společná platforma řešení problémů a sjednocení pohledů na IS
 vytvoření efektivních vazeb mezi globální a informační strategií a taktickým a operativním řízením
 multidimenzionální koncepce zajišťuje úplnost popisu IS a kontrolu konzistence
 přispívá ke schopnosti integrace podniku s okolím a pružnosti reakce na změny

Rizika
 při přílišné detailizaci – vysoké nároky na objem vstupních dat
 pokud nejsou funkce MtS přístupné všem uživatelům – vlastní evidence např. HW
 nejsou-li stanoveny odpovědnosti za aktualizaci dat v MtS  MtS = skladiště nepotřebných dat


Pokud chceme, aby byl vývoj informačního systému efektivní, musíme použít systematický přístup, který nám jasně vymezí postup jednotlivých fází a jejich obsah. Proto vzniklo již velké množství různých metodik, většinou od významných firem, jako jsou SSADM, Oracle CASE Method, SDM, SSM, DSDM a podobně. Dále musí metodika splňovat několik základních požadavků:
 Musí jasně deklarovat soubor hodnot - požadavků na vývoj systému systému (krátká doba řešení, levné, ..).
 Musí určovat postup řešení, aby jej bylo možné naplánovat.
 Musí určit priority řešení v každém okamžiku.
 Měla by doporučovat metody, techniky, nástroje.

1.5. Vztahy mezi obsahovými dimenzemi

• funkce  data
• řídící data – zákony
• rozsah dat – diskové kapacity
• programové moduly – počítače, sítě
• řídící odpovědnost funkčního místa
• funkční místa – počet pracovníků
• řídící a výkonné odpovědnosti – kvalifikace
• propojení HW, SW a datové dimenze 
o technologická architektura – definuje způsob zpracování aplikací IS (dávkově,…)
o vnitřní stavba aplikací (KIS,…) a uživatelské rozhraní


1.6. Přizpůsobení MDIS konkrétnímu projektu
Faktory, které je třeba brát v úvahu:

• charakter řešení
o nákup hotového TASW
 přizpůsobení procesů možnostem TASW
 výběr nejvhodnějšího TASW
o nákup vývojového prostředí a tvorba nového ASW pomocí něho
 vhodnost vývojového prostředí pro řešenou aplikaci
o realizace IS/IT včetně vývojového prostředí
 nejnáročnější
 nejméně používaná

• rozsah problému a jeho složitost
o čím složitější, čím je třeba více pracovníků na realizaci a tím obtížnější je jejich koordinace
o roste význam manažerské dimenze a význam prototypů

• požadovaná kvalita řešení a spolehlivost provozu – role testování a zodpovědností

o čas, který je objektivně dán na řešení – čím méně času, tím roste význam inkrementálního vývoje
o počet, schopnosti a zkušenosti řešitelů – školení a testování (u nesehraného týmu)
o počet a dosavadní zkušenosti uživatelů – s klesající zkušeností uživatelů roste význam úvodních fází vývoje IS
o finanční zdroje na řešení – čím méně peněz, tím „lepší“ (subtilnější) řešitelský tým, tím vyšší role TASW a úvodní studie
 menších projektů se spojuje několik fází do jedné etapy řešení
 nesmí ale znamenat vypuštění některé dimenze řešení
 váha dimenzí (obsahových) vyplývá z kritických faktorů úspěchu projektu


Požadavek krátké realizace při minimalizaci rizik a rostoucí komplexnost projektů
 možnosti řešení
a) prototypování
b) inkrementální vývoj
 cílem je co nejrychlejší dosažení přínosů projektu
 každá část aplikace prochází fázemi samostatně
(musejí ale být samostatně provozovatelné)

1.7. Metainformační systém jako nástroj řízení vývoje integrovaného IS

o metasystém = systém popisující/modelující jiný systém.
je jednotou metadatabáze (metadat) a operací umožňujících uchování a zpracování metadat

o metadata popisují IS/IT podniku a jejich vzájemné vazby na další součásti podniku a na podnikové aktivity

Komerčně nejúspěšnějším je ARIS (použitelný pro zavádění ISO 9000 i BPR).
MtS na VŠE – má zajistit integrovaný pohled rozdílných skupin uživatelů na IS.

Základní operace MtS
• operace realizující pasivní roli MtS (nevyžaduje přímé propojení MtS a IS)
o vytváření a údržba metadatabáze
o dotazy na obsah a strukturu IS/IT
o analýzy konsistence IS/IT (chybějící části IS, nadbytečná data,…)
o analýzy nad metadaty – co se stane, když…

• operace realizující aktivní roli MtS
o řízení IS/IT (spouštění dávek, kontrola přístupových práv,…)
o sledování provozu IS/IT (monitorování přístupu uživatelů k IS,…)

Životní cyklus projektu

Projekty definované v informační strategii se realizují v 6 fázích:
• úvodní studie = studie proveditelnosti, variantní návrh koncepce
• globální analýza a návrh = vymezení hlavních funkcí a dat na konceptuální úrovni
• detailní analýza a návrh – transformuje konceptuální do technologické (např. relační model)
• implementace – technologická do implementační (programování programů)
• zavádění – instalace, školení
• provoz a údržba


b. Obsahové a metodicko-organizační dimenze
obsahové
• data / informace
• funkce / procesy
• organizační a legislativní aspekty
• SW
• HW
• ekonomické a finanční aspekty

metodicko-organizační
• metody – určuje metody a nástroje pro jednotlivé fáze
• dokumenty – jaké dokumenty vznikají v průběhu, jejich obsah
• řízení prací dané fáze – postup při řešení fází vývoje IS


data / informace
potřebné typy informací, obsah a struktura DZ a její fyzické uložení
• signální (došlá faktura)
• strukturální (popisuje strukturu systému)
• genetické (uložená ve vlastní paměti systému – např. paměti lidí)

funkce / procesy
funkční pohled na IS/IT je statický – popisuje hierarchický rozpad funkcí IS
• výstupní data (hrubá mzda, daň ze mzdy,…)
• vstupní data (odpracovaný počet hodin,…)
• řídící data (zákon o dani z příjmu,…)

procesní – zajímá nás dynamika chování podniku při výskytu různých událostí
• informační (příchod faktury)
• časová (spojena s určitým časem)
• mimořádná (výpadek proudu)
organizační a legislativní
• musí respektovat platnou legislativu dané země a podnikové směrnice a normy
• popis organizační struktury platné v době provozu jednotlivých verzí IS/IT
o primární – obvykle stromová
o sekundární – při řešení specifických problémů (může jich být více)
– definuje pravidla pro vývoj, údržbu a provoz IS, zodpovědnosti a pravomoci, postupy prevence proti mimořádným stavům

pracovní, sociální a etické aspekty
• určit potřebnou strukturu pracovníků podniku (počet, kvalifikace, věk, pohlaví)
• analyzovat sociální a etické dopady přechodu na novou verzi IS
• jak do nového pracovníka přenést genetickou info
• jak využít znalosti nového pracovníka
• jak motivovat spolupráci

SW
• určení architektury programového systému – typy, parametry, vazby komponent ZSW a ASW
• nákup či vývoj SW komponent?

HW
• určení HW architektury IS – typy, parametry, počty počítačů, periferních zařízení, sítí

ekonomické/finanční
• finanční náklady tvorby a provozu IS + přínosy z použití IS
• kdy a z jakých zdrojů budou náklady na IS kryty

Multidimenzionální přístup k řešení IS

1.1. MDIS (Multidimensional Development of Information System)
cíl: vývoj a údržba komplexního a integrovaného IS/IT, který optimálně podporuje dosažení podnikových cílů
 nepředepisuje detailně jednotlivé kroky vývoje IS/IT- vychází z toho, že každý projekt je natolik specifický, že by to mohlo vést k hledání analogií i tam, kde nejsou
 metodika klade důraz na to
o jak strukturovat práci
o co by se mělo řešit v jednotlivých fázích vývoje IS/IT
o čem v jednotlivých fázích vývoje IS/IT přemýšlet
Mnohost pohledů na IS/IT jak při řešení, tak při provozu IS/IT = základní předpoklad efektivnosti IS/IT.
Multidimenzionalita = řešení IS/IT souběžně ze všech pohledů, které ovlivňují efektivitu IS/IT.

1.2. 2 základní skupiny dimenzí vývoje IS/IT
1. úrovně integrace, použitá úroveň abstrakce a časová dimenze
2. ty úrovně, které se aplikují v každé fázi vývoje IS/IT = obsahové dimenze
(informační / datová)
(procesní / funkční)
(ekonomická / finanční)
(organizační / legislativní)
(pracovní / sociální / etická)
(softwarová)
(hardwarová)
(metodická)
(manažerská)

1.3. Cíl multidimenzionality
 neopomenout žádná faktor, který ovlivňuje úspěšnost tvorby, zavedení, provozování a dalšího vývoje IS/IT
 neopomenout vzájemné ovlivňování (vazby) faktorů

1.4. Dimenze řešení IS = druhy pohledů na IS

Při řešení je nutno vycházet z uživatelských pohledů na IS/IT a ty postupně transformovat v řešitelské

Uživatelské pohledy
 pohled vrcholového vedení podniku – dlouhodobý a strategický charakter
o na podporu kterých podnikových procesů se zaměřit
o požadovaný čas nasazení dalších verzí IS/IT
o jaké finanční (i pracovní) zdroje může podnik na řešení uvolnit
 procesní pohled koncových uživatelů
o jaké procesy probíhají na sledované úrovni řízení podniku
o která data sbírat a uchovávat
o kdy data sbírat
o jaké transformace dat provádět
 pohled koncového uživatele na funkce IS při komunikaci s počítačem
o odvození návrhu průběhu komunikace uživatele s IS

Řešitelské pohledy na IS/IT
a. dimenze čas, úroveň abstrakce, úroveň integrace
Úlohou řešitelských pohledů je transformovat uživatelské pohledy (požadavky) nejdříve do logického návrhu a ten pak do fyzického.
Z této skupiny dimenzí (čas, úroveň abstrakce, úroveň integrace) jsou v MDIS odvozeny jednotlivé fáze vývoje IS/IT. Každá fáze má cíle, vstupy, výstupy a postup řešení.

Cíle rozdělení prací do fází
 rozdělit řešení do projektů – usnadní plánování a řízení prací
 vývoj po částech, které jsou samostatně co nejrychleji předatelné do provozu
 (zavedením projektu do provozu vzniká nová verze provozovaného IS/IT)
 jasně oddělit jednotlivé úrovně abstrakce při řešení IS/IT – sjednocování náročnosti
 zajistit adekvátní podporu globálních cílů podniku

Fáze: globální strategie = model budoucího stavu celého podniku
informační strategie = model budoucího stavu IS/IT (technologická integrace)

Obě fáze zajišťují integraci:
 vizí a idejí
 podniku s okolím
 interních podnikových procesů

1.3. Smysl metodiky:

základním přínosem zavedení metodiky tvorby informačního systému je zvýšení kvality vyvíjených informačních systémů vč. zvýšení konkurenceschopnosti firmy na trhu. toho je dosahováno především toho, že metodika umožní:
 dosáhnout větší produktivity a kooperace projektových týmů
 vytvořit přesně definovaný komunikační standard pro jednotlivé typy funkčních míst, a to jak tvůrců, tak i uživatelů systému.
 vetší specializaci projektových týmů a jejich členů na jednotlivé etapy životního cyklu vývoje IS
 získat větší nezávislost vyvíjených, či již vytvořených informačních systémů na konkrétních řešitelích
 dosáhnout větší pružnosti vytvářených IS vzhledem k vývoji potřeb uživatelů
 získat kvalitní a aktuální dokumentaci k IS
 dosáhnout efektivnější údržby IS
 definovat kritéria kvality vytvářených IS pro každou etapu životního cyklu vývoje IS pro každou etapu vývoje IS
 kvalitněji řídit a kontrolovat práci na projektech
 snížit rizika vyčerpání zdrojů na nerealizované IS, tj. soustředit se na vyvíjený systém především v počátku vývoje IS a odhalit nerealizovatelnost vývoje
 získat větší možnost přenositelnosti do jiných implementačních prostředí
 získat jasně určená východiska a kritéria pro výběr a použití prostředků CASE

Metodika má sloužit jako základní standard tvorby IS

1.4. Specifika zavádění metodiky do používání:
zavádění metodiky do organizace má vliv na celou organizaci jako celek. základem zavedení metodiky je výchozí verze metodiky tvorby IS pro organizaci. Výchozí verzi je nutné před použitím v reálné situaci upravit pro specifické podmínky v organizaci. dále je nutné provést změny v sociálně psychologické oblasti - protože musí být věcí lidí v organizaci. lidé budou s metodikou pracovat. nutno vytvořit vstupní podmínky pro metodiku:
 příznivé sociálně psychologické klima
 dostatečná kvalifikace pracovníků v oblasti metod technik a nástrojů vývoje IS
 jednotně koordinovaná a řízená organizační struktura vývoje IS, výsledkem je vytvořené metodické centrum, jehož náplní je údržba a rozvoj metodiky

1.5. Klasifikace metodik:

metodiky lze koupit v podobě:
 vytištěných publikací
 hypertextových souborů
 školení, kurzů

klasifikace:
 státem podporované (stát vyžaduje při státních zakázkách použití definované metodiky, případně je jím vlatníkem a zodpovídá za vytváření nových verzí metodik)
o SSADM (Structured Systems Analysis and Design Method) - Velká Británie
o SDM (System Development Methodology) - Holandsko
o MERISE - Francie
o V-MODEL - Neměcko
 Mezinárodní(zaměřené na pracovníky statní správy)
o Euromethod - EU
o Software Life-Cycle Process - ISO
 Firemní metodiky (ve vlastnictví významných firem, škol, institucí ... apod.)
o IE (Information Engineering Methodology - James Martin and Co.)
o SE (LBMS System Engineering)
o ORACLE CASE Metohd (Oracle Corp.)
o Accelerated System Development for Client/Server (Ernest and Young)
o RAP (Rapid Application Prototyping - Texas Instruments)
o RSDM (Rapid System DevelopmentMethodology - Bechman Information Systems)

zájem firemních metodik: specifický postup vývoje IS a tomu příslušné nástroje a pravidla, CASE
zájem státních a eurometod: integrovat jednotlivé vyvíjené systémy tak, aby vzájemně tvořily systém

Metodiky vývoje IS

1.1. Metodika
• systematický přístup k tvorbě IS, který jasně vymezuje postup a obsah jednotlivých fází vývoje IS/IT.
• Metodika je explicitní způsob strukturování myšlení a konání. Metodika obsahuje model, který reflektuje zvolené pohledy na realitu a který vychází z množiny filosofických paradigmat. Metodika musí říkat „jaké“ kroky a „jak“ je vykonat, ale nejdůležitější je, aby řekla proč se mají vykonat.
• Metodika je souhrnem etap, přístupů, zásad, postupů, pravidel, dokumentů, řízení, metod a nástrojů, který pokrývá celý životní cyklus informačního systému. Metodika by se měla vztahovat na všechny prvky IS (pracovníky, organizační procedury, data, SW, HW a další), organizační vlivy IS, ekonomické otázky spojené s vývojem a provozem IS a doporučené dokumenty způsobu řízení IS

Každá metodika MUSÍ (požadavky na metodiku):
 deklarovat soubor hodnot, na kterých je založena, resp. kterých chce u budovaného IS/IT dosáhnout (min. náklady tvorby, krátká doba řešení, apod.)
 určovat postup řešení, aby bylo možné celý proces vývoje IS plánovat
 určit priority řešení (co kdy a kde je důležité)
 doporučit metody, techniky a nástroje pro jednotlivé etapy řešení

1.2. Obecné principy:
 orientace na cíle a problémy: východisko tvorby IS=cíle a problémy
 účast zadavatele na projektu: protože vedení organizace má odpovědnost na obsahu realizovaného IS, musí se aktivně podílet na vývoji .
 klíčové dokumenty a jejich schvalování: dokumenty, které podléhají schválení ze strany vedení =klíčové; bez schválení nelze pokračovat ve vývoji IS, toto zajišťuje účast vedení na projektu
 zapojení uživatele do návrhu: klíčoví uživatelé (s pravomocí rozhodovat) se musí účastnit projektu
 modelování a abstrakce, princip tří architektur: vytvoření modelu úrovní modelů systému vede k oddělení podstaty systému od omezení vyplývající ze zvolené technologie a implementačního prostředí.
 ověřování a testování návrhu během celého vývoje: nutnost ověřování zda, každá činnost splňuje přepokládaný stav. realizuje se prostřednictvím řídících komisí a schvalovacích procedur.
 v každé etapě probíhá analýza a návrh: v jednotlivých etapách se analyzují požadavky na systém a zpodrobňují se pouze na takovou úroveň, aby bylo možné na základě takto provedené analýzy, navrhnout systém tak, aby mohla být zahájena další etapa. požadavky se pouze zpodrobňují. při změně nadřízeného požadavku, je nutné změnu provést až v etapě, kde byl daný požadavek zaveden. takto se změna požadavku promítne do všech etap, ve kterých se požadavek vyskytuje.
 vývoj probíhá z hlediska všech pohledů na systém: v každé etapě je třeba analyzovat a navrhovat na odpovídající úrovni podrobnosti:
o data
o funkce
o organizace
o sociální a psychologická hlediska
o technologie
o ekonomická hlediska
 otevřenost metodiky: musí být postavena na běžně používaných metodách a technikách vývoje IS a měla by být schopna vstřebat veškeré nové poznatky na tomto poli. umožňuje top použití CASE nástrojů. Každá metodika tak kompatibilní s s většinou standardních metodik vývoje IS.

1.6. VĚCNÁ TYPIZACE

Věcná typizace řeší určitý věcný problém. Pokrývá určitou aplikační oblast. Tento přístup k tvorbě TAV je široce uplatňován v různých výrobně technologických oblastech i při projekčních činnostech v konstrukčních kanceláří a při řízení sociálně ekonomických systémů.
Úroveň TAV a jeho význam pro uživatelskou sféru se liší tím, zda jsou samostatně řešeny jednotlivé subsystémy nebo zda je při řešení využita možnost promítnutí vazeb mezi jednotlivými subsystémy, které jsou propojeny datovými vazbami.
Zvláštní problém je, že uživatel aplikuje pouze části subsystému a kompletuje se svými vlastními programovacími produkty. Pro musí být TAV konstruován jako stavební kameny - moduly. K tomu musí být splněny mimo jiné tyto předpoklady
 přesně definovaný interface
 adaptivnost vytvořených modulů v konkrétních podmínkách
Co lze typizovat? Čím níže na úrovni řízení, tím jsou činnosti lépe typizovatelné.

1.7. SPECIFIKA EFEKTIVNOSTI TAV
Vzhledem ke specifickým charakteristikám TAV musíme při sledování jejich efektivnosti odlišovat tři samostatné fáze: tvorbu, zavádění a využívání TAV.
Připustíme-li, že náklady na zavádění a využívání jsou zhruba stejné, potom:
Nřeš.t. < Nřeš.i. Nřeš.t. - náklady na řešení Nřeš.i. - náklady na individuální řešení - počet aplikací typového řešení
Vzhledem k nárokům na řešení TAV musí být jeho užitná hodnota odhadnuta kvalifikovaně předem.

1.8. VÝVOJ TYPIZACE

Uživatelsky dominantním pohledem na typizaci je od samotného počátku vytváření ASŘ (začátek 70. let) věcný (obsahový) pohled. Ten se promítl v požadavcích na získání TAV. Tento pohled vyplynul do záměru budování ucelených typových ASŘ. Jejich nejvýznamnějším představitelem ve strojírenství byl typový projekt MARS a později VARS. Tyto projekty byly řešeny jako systémy funkčně provázaných podsystémů, určený pro řízení strojírenských podniků se sériovou výrobou.
Vztah k těmto projektům byl různý, od případů charakterizujících je jako ideální až po případy odmítající je jako nepoužitelné. Můžeme na nich proto formulovat určité zobecňující závěry:
 prakticky výhradním kritériem dekompozice systému řízené při vytváření projektu MARS byla věcná stránka
 nízký stupeň funkční pružnosti i nízký stupeň datové nezávislosti vedl k násilným změnám u uživatelů ve smyslu přizpůsobení se projektu
 v počátcích těchto projektů nebylo téměř žádné využívání technologicky orientovaných programových produktů (to vedlo k pracnému opakovanému programování technologicky podobných úloh)
Další vývoj typových projektů proto vyvolával potřebu jednak jejich efektivnější tvorbu a údržbu, jednak zvýšení jejich pružnosti a adaptibility. Významným směrem rozvoje programového vybavení proto byl rozvoj funkčních programových prostředků.
Postupné zavádění této technologie zpracování dat vedlo zprvu k vytváření jednotlivých obecných či typových programů. Postupně to však vedlo k vytváření ucelených programových systémů pro určitý typ technologie zpracování dat, např.:
 univerzální TP pro pokrytí všech fází dávkového zpracování dat
 konverze, aktualizace, výběr, transformace dat, výstup výsledků atd.
 databankové systémy pro pokrytí všech operací s daty v databázi (definování dat, fyzické ukládání dat, výběr dat, prezentace dat, zabezpečení dat atd.)

V souvislosti s rozvojem mikropočítačů se objevují další technologicky orientované programové prostředky, výrazně orientované na práci koncového uživatele (uživatelsky přívětivé):
 programové prostředky pro zpracování textových dat
 programy pro práci s tabulkami
 programové prostředky 4.generace (integrované prog. prostředky zahrnující různé typy technologií) /při použití těchto prostředků dochází k největším úsporám při implementaci aplikací a při jejich údržbě, jejich struktura vede k vyššímu stupni standardizace a výraznému zkrácení programů/
 programová podpora tvorby projekce (CASE) /Zatím posledním vývojovým stupněm. Je to systém pro tvorbu systémů. Představuje integraci celého procesu vyvolaného vytvářením aplikace. Zahrnuje programovou podporu všech činností (analýzu problému, specifikaci, zadání, formulaci algoritmů, jejich programový zápis a ladění, implementaci řešení a jejich údržbu). Generátory kódů programů vylučují vznik všech formálních chyb a řadu logických chyb. Umožňují až řádové zvýšení produktivity práce při tvorbě aplikace./

1.5. FUNKČNÍ TYPIZACE

Funkční typizace vychází se skutečnosti, že většina operací na datech se opakuje bez ohledu na vztahu ke konkrétní řídící fci. Např. procedury pro čtení a vstup, procedury pro manipulaci s daty atd..
Funkční typizace sebou přinesla i jistou formalizaci v tvorbě programů (normované programování, modulární programování), rozvinula velmi výrazně úroveň programovacích jazyků a kompilátorů. Je zřejmé, že při důsledné aplikaci funkčních typových modelů se snižuje (výrazně) počet příkazů, které tvoří programátor.
Je třeba dodat, že důsledné uplatnění funkční typizace vede k podstatnému zlepšení kvality programátorských produktů a značně urychluje proces tvorby programů. Aplikace funkční typizace vede k nové koncepci programátorské analýzy dané úlohy. Programátor musí znát technologické moduly a musí postupovat způsobem, který mu dovolí maximálně tyto moduly využít.
Funkční prvky představují určitou vrstvu ve struktuře programového vybavení, vytvářejí nadstavbu nad OS (eventuálně na aplikačními programy). V žádném případě to není vrstva poslední. Představuje určitý potenciál pružnějšího, rychlejšího a efektivnějšího vyřešení vlastního TAV.
Při aplikacích TAV v organizacích by se programování úloh mělo změnit na sestavování "technologických sledů" z funkčních TP.



1. Popisuje datové struktury na logické úrovni (název, délka, typ, povinnost zápisu atd.). Modul by měl umožnit parametrické zadání typu datové struktury z hlediska požadovaného přístupu k datům.
2. Zabezpečuje uložení dat ze vstupních médií do fyzických struktur vnějších paměťových médií.
3. Promítá do základních datových struktur různé typy změn. Typ změn by měl být jednoduše volitelný.
4. Dosavadní existence tohoto modulu je převážně spojena s jednoduššími aplikacemi, realizujícími výběr dat a jednoduché operace s nimi.
5. Zprostředkovává výsledky transformačního modulu na zvoleném médiu.

Z vývoje počítačových firem ve světě je patrný silný trend k rozvoji funkčních programovacích produktů, dovolujících rychlé programové vyřešení požadované aplikace. Zvlášť silný je trend u mini a mikropočítačů. Z uživatelského hlediska jsou významným směrem orientovány funkční prostředky, které umožňují formulaci požadavků na data a jejich provedení. Uživatel sám dostává s využitím těchto prostředků odpověď na zadaný požadavek.

1.3. VLASTNOSTI TP

 Opakovatelnost využití - jedná se o základní vlastnost TP. Míra opakovatelnosti musí být úměrná náročnosti tvorby TP. Vytvářet TP má smysl jen tehdy, je-li pracnost jejich tvorby a přizpůsobování při opakovaném použití nižší, než byla pracnost vytvoření všech konkrétních řešení těchto prvků, jejichž je TP reprezentantem.
 Zaměnitelnost - TP je obecně parametrický produkt (obsahuje konečný počet parametrů s definovaným oborem hodnot). Tento obor hodnot je takový, že pro každý konkrétní prvek z množiny, kterou TP reprezentuje, existuje taková hodnota parametrů, že po dosažení parametrů pro daný prvek do TP vznikne prvek zaměnitelný za tento konkrétní prvek, který nemá parametry (musí se přizpůsobit realita).
 Srozumitelnost -předpokládá, že při tvorbě TP je uplatněna metodika, která umožňuje nejen pochopení formulace a zápisu TP, ale i rychlé pochopení způsobu, jimž uživatel z tohoto TP vytvoří KP.
 Spolehlivost -je pravděpodobnost, že TP bude v daném čase a v konkrétních podmínkách plnit specifické funkce. Vzhledem k předpokladu, že funkce TP je mnohem víc než u individuálního prvku ohrožena možností pronikání chyb a nesprávných zásahů ze strany uživatele, musí být TP zabezpečen daleko více jak proti vnitřním , tak vnějším chybám.
 Snadná údržba - je přímo existenčním předpokladem TP. Souvisí s možností snadného promítání změn. To platí nejen pro gestora za rozvoj, ale hlavně pro mnohdy značný počet uživatelů. Tato vlastnost je proto bezprostředně podmíněna kvalitou dokumentace.
 Modulární výstavba - proto, aby TP splňoval předchozí požadavky musí být při konstrukci použita taková metoda, která jejich splnění podporuje.

1.4. TYPOVÉ APLIKAČNÍ VYBAVENÍ

Rozumíme jím programovou podporu TP, řešícího zvolenou problémovou oblast (úloha, skupina úloh, subsystém atd.). Jeho součástí je adekvátní struktura dokumentace, potřebná pro jeho vývoj, aplikaci, provoz a údržbu.
Principy, na nichž jsou řešeny programové prostředky pro řešená TAV, jsou založeny na standardizaci a na generování.
Standardizace vychází z existence určitých průměrných (standardních) podmínek. Je založena na sjednocení podmínek, tedy i při vytváření ASŘ je sledován cíl vícenásobného vytváření stejných nebo téměř stejných podmínek, ve kterých by mohl být daný standardní prvek uplatněn. Ve standardních funkčních prvcích se vzhledem k jejich charakteru, téměř nepředpokládá potřeba přizpůsobení individuálně odlišných podmínek a jsou proto vytvořeny "na tvrdo". Nezbytné přizpůsobení dosahuje možností parametrické volby. Mohlo by se zdát, že je tento princip nevhodný pro řešení funkčních prvků určených k vícenásobnému použití.
Generování je princip, který umožňuje beze zbytku řešit všechny požadavky vlastností TP. Přizpůsobování typového řešení do konkrétního tvaru se provádí na základě dosazení konkrétních hodnot za parametry typového řešení.
Generování spočívá převážně na tom, že speciální druh programového vybavení - generátor - je schopen na základě určitých pravidel automatizovaně vytvářet pro určitou třídu problémů konkrétní programové produkty.
Na tvorbu generátorů jsou kladeny podstatně vyšší nároky než na tvorbu konkrétních programů.Tyto vyšší nároky se však vracejí ve značné úspoře programátorských prací při sestavování konkrétních řešení. Na rozdíl od programování v určitém jazyce, kde programátor přímo vytváří konkrétní program, definuje v případě použití generátoru programů jen specifické vlastnosti konkrétního problému. Je zřejmé, že tento postup značně snižuje pracnost programování, jeho chybovost, nároky na ladění a současně se zvyšuje rychlost tvorby konkrétního řešení. Generátor programů lze tedy z hlediska konstrukce definovat jako určité zobecněné schéma programu a mechanismu, který je schopen po dosažení určitých hodnot parametrů automatizovaně vytvořit konkrétní program.
Automatizace procesu generování předpokládá, aby byl tento parametrizovaný produkt vyjádřen jednou ze dvou základních forem, které jsou:
1) parametrický program (funkce generátoru zabudována přímo v konkretizovaném algoritmu)
2) makrodefinice či soustava makrodefinic (generátor musí být konkretizován specifickým prostředkem, který je realizován samostatně nebo je součástí kompilátoru)/takový prostředek se nazývá "makroprocesor"/

Jasné vymezení úloh v oblasti technologie zpracování dat, větší možnosti jejich parametrizace a zejména široké možnosti jejich uplatnění byly důvodem pro vznik různých generátorů zajišťujících jednotlivé činnosti technologie zpracování dat. Jsou to především - generátory programů pro kontrolu a konverze dat
 generátory programů pro různé převody souborů
 generátory třídících programů
 generátory tiskových programů a sestav
Generátory programů pro technologii zpracování dat, ať na bázi makrodefinice nebo na bázi parametrického řízení jsou velmi účinným nástrojem tvorby aplikačních programů. Z hlediska požadavků koncového uživatele ASŘ mají však určitou nevýhodu. Jsou totiž orientovány převážně pro potřeby aplikačních programátorů.
Pro řešení ve specifických oblastech řízení jsou u nás dosud účelové funkční generátory programů využívány podstatně méně než v oblasti počítačové technologie zpracování dat. Příčinu lze spatřovat ve značné variantnosti problémů a v možnosti omezujících podmínek, které by bylo nutné zahrnout do obecného řešení. Proto byl dosavadní přístup k budování ASŘ a jeho typizaci orientován na tvorbu standardních řešení (MARS, VARS).

1.2. CHARAKTERISTIKY TP

Obecnost je dána velikostí množiny konkrétních prvků, které daný TP reprezentuje. Obecnější TP obsahuje z hlediska velikosti množiny prvek méně obecný jako vlastní podmnožinu. (Např. TP pro aktualizaci libovolného souboru je obecnější než TP pro aktualizaci stavu zásob na skladě). Postupným zužováním tohoto oboru hodnot dostatečně obecného TP získáme hierarchickou soustavu TP uspořádaných dle různých úrovní obecnosti (konkrétnosti).
Obecnější TP vyžaduje většinou více úprav při tvorbě konkrétního prvku, což se odráží v rozpracovanosti TP. Proces zužování oboru hodnot, jehož výsledkem je vytvoření méně obecného, konkrétnějšího TP a nakonec KP se nazývá konkretizace.

Funkční šíře vyjadřuje rozsah funkcí ASŘ, který daný TP zajišťuje. Ze dvou prvků je za funkční šíři považován takový, jehož funkce zahrnuje funkce užšího prvku jako podmnožinu. Proces tvorby funkční šíře TP z užšího se nazývá kompozicí TP.

1.7. Proč systémový integrátor?

Volba externího systémového integrátora je podmíněna podnikem z několika důvodů:
 IS/IT má pro podnik prioritní význam a jeho nefunkčnost může ohrozit dosažení podnikatelského záměru
 požadavky na realizátora přesahují možnosti vlastního týmu informatiků
 čas realizace IS/IT je kritickým faktorem
 vhodné rozložit rizika na několik subjektů

SI vystupuje vůči podniku jako hlavní dodavatel, dopovídá za všechny realizované záležitosti.

Úloha - předpoklady:
Jste reprezentantem dodavatelské firmy, působící jako systémový integrátor pro vámi zvoleného zákazníka.
Zadání:
 Jaké budou hlavní principy systémové integrace, o něž budete řízení rozvoje IS/IT opírat ?
 Jaké požadované služby od vás, jako systémového integrátora, bude zákazník zřejmě očekávat a jak je zajistíte ?
 Demonstrujte možné chyby v integraci IS/IT zákazníka a popište způsob jejich řešení.


Jaké budou hlavní principy systémové integrace, o něž budete řízení rozvoje IS/IT opírat? viz obecné principy.
Jaké požadované služby od vás, jako systémového integrátora, bude zákazník zřejmě očekávat a jak je zajistíte ?
 spolupráce na tvorbě a aktualizaci informační strategie
 tvorba úvodní studie (specifikace produktů, služeb, času, financí, atd. pro projekt)
 návrh architektury celého IS/IT aby bylo MOŽNO
o budovat IS/IT jako stavebnici z komponent
o přizpůsobovat IS/IT podnikovým změnám (cílům, vizím)
o přizpůsobovat IS/IT novým možnostem v IT
 dodání metodiky vývoje IS/IT; nutno definovat:
o odpovědnost integrátora a zákazníka v procesu vývoje IS/IT,
o licenční a leasingové podmínky na služby integrátora
o typové etapy vývoje IS/IT, vč. vstupů, výstupů, metod a řešení
o způsob a dokumentace předání, testování a vyhodnocení kvality komponent a služeb
o způsob podávání, řešení a dokumentace reklamací
 plánování projektu a tvorba harmonogramu
 řízení projektu
 konzultace optimalizace podnikových procesů
 zajištění dodávek a instalací HW a SW komponent, vč. dokumentace. Jedná se o tyto komponenty:
o HW (servery, koncové stanice, tiskárny a další přídavná zařízení)
o kabeláž
o síťový SW
o OS
o RDBMS
o DWH
o CASE, 4GL , apod.
o technologicky orientovaný SW(OIS, EDI, workflow, apod.)
o ASW
 koordinace subdodávek
 zajištění všech služeb (servis, údržba, konzultace, školení, apod.) související s integrací všech komponent
 udržování dokumentace
 garance funkčnosti a kvality

dle POUR:
 projekční služby (analýza, návrh, implementace a instalace jednotlivých komponent IS/IT)
 výběr vhodných produktů pro realizaci projektů - od aplikačního sw až po dílčí technické prostředky
 instalační služby - technických prostředků, kabeláže, ZSW
 školící služby - pro všechny typy komponent IS/IT a skupiny uživatelů, kde je školení účelné nebo je vyžadováno
 podíl na řízení projektů a provozu IS/IT
 zajišťování permanentního rozvoje IS/IT v souvislosti s novými funkčními požadavky, datovými zdroji, rozvojem IT a rozvojem znalostí uživatelské sféry

Demonstrujte možné chyby v integraci IS/IT zákazníka a popište způsob jejich řešení?
viz předchozí. (Rizika)

INDIVIDUÁLNÍ A TYPOVÁ ŘEŠENÍ - DODATEK

ÚS výběrové řízení na ASW a jeho dodavatele - poptávkový dokument
GAN + DAN prototypování TASW => detailní testování vhodnosti funkcí TASW pro podporu příslušných podnikových procesů
IMP implementace + customizace (nastavení parametrů, provedení programových změn)
ZAV zavádění
PÚ provoz a údržba

1.1. VYMEZENÍ POJMŮ
typizace -> identifikace mnohonásobně se vyskytujících se problémů, jejich zobecnění i tvorba odpovídají cích zobecněných řešení, mnohonásobné využití těchto řešení v procesu projektování
základní úlohou typizace je vytvoření unifikovaných a zobecněných řešení efektivně použitelných pro tvorbu konkrétních variant
v procesu typizace jsou prováděny tyto činnosti:
1. identifikace množiny konkrétních prvků, které jsou obdobné a u nichž jsou předpoklady jejich zobecnění
2. tvorba projektových produktů pro každou množinu identifikovanou předchozí činností
3. využití těchto programových produktů při budování konkrétních ASŘ
typový prvek -> nositel společných vlastností určité třídy konkrétních prvků ASŘ
 prvky jedné třídy mají v jistém smyslu podobné vstupní a výstupní informace i vztahy mezi nimi
 konkrétní prvek lze získat konkretizací tohoto zobecnění (pak se takové zobecnění nazývá typový prvek)
typová parametrické zobecnění třídy konkrétních úloh,
úloha -> přičemž definice typové úlohy z jedné strany představuje východisko pro vypracování typového řešení a z druhé strany slouží ke zjištění, zda ke zjištění konkrétní úlohy bude možno použít TP (zda daná úloha je reprezentována tímto prvkem)
typové řešení -> parametrizovatelný algoritmus - vytváření konkrétních řešení se provádí výběrem a dosazením konkrétních hodnot parametrů, které specifikují danou konkrétní úlohu
konkrétní prvek -> prvek konkrétního objektu řízení (nemusí být nositelem udělené funkce řízení, ale může být jen funkcí v ASŘ, která nemá odraz v systému řízení)
- má dvě formy:
1. konkrétní úloha - popis konkrétního prvku ve formě problému, který je v ASŘ řešen prostřednictvím tohoto prvku
2. konkrétní řešení - popisuje prvek ve formě algoritmu problému formulovaného v konkrét ní úloze

Systémová integrace

1.1. Systémová integrace
Jeden ze systematických a praxí ověřených postupů k vývoji a provozu IS/IT, zaměřený na minimalizaci rizik a maximalizaci efektů IS/IT.
Cílem SI je vytvoření a permanentní údržba integrovaného informačního systému, který optimálně využívá potenciálu dostupných IT k maximální podpoře podnikových cílů. Informační systém je přitom vytvářen integrací různých zdrojů, tj. různých produktů a služeb.

1.2. Principy vývoje IS/IT
 požadované funkce IS jsou odvozeny od podnikových cílů a potřeb podnikových procesů
 IS je řešen a realizován jako komplexní informační systém vytvořen z řady různých komponent různých výrobců. hlavní komponenty jsou:
o počítače a přídavná zařízení
o sítě LAN a WAN
o ZSW: řídí využití zdrojů počítačů a počítačové sítě (OS, SW pro řízení sítě, RDBMS)
o TESW (technologicky orientovaný typový software): podporuje základní administrativní činnosti a komunikaci mezi pracovníky (workflow, text. editor, tab. kalkulátor, email)
o ASW: pro podporu výrobních, ekonomických, distribučních a dalších procesů podniku. 1. TASW - standardizované řešení informačního systému podniku (výrobní, distribuční apod. podnik) 2. IASW - individuální ASW šité na míru potřebám podniku
o interní a externí datové zdroje
 IS je realizován jako integrovaný komplex služeb (projekční, implementační, instalační, školící, apod.)
 IS je realizován jako otevřený systém na bázi mezinárodních i podnikových standardů, zajišťující podniku nezávislost na určitém výrobci techniky a SW
 IS je rozvíjen pomocí jednotné metodiky
 IS je provozován na základě jednotné vrstvy pravidel, které musí dodoržovat všichni uživatelé

1.3. Efekty SI
efekty se projevují v oblasti realizovaných procesů podniku. např.:
 zkrácení celkové doby reakce podniku na podněty z okolí (rozhodující)
 využití progresivních metod řízení podnikových zdrojů a procesů na základě vyšší dostupnosti a komplexnosti informací ze všech činností podniku
 integrace firemního know-how
 snížení chybovosti a nekonzistencí informací

1.4. Rizika SI
 vyšší závislost podniku na externích dodavatelích komponent a služeb IS/IT na kvalitě jejich práce, na jejich serióznosti a stabilitě
 vyšší složitost systému a nároky na projekci a přípravu řešitelů
 vyšší nároky na uživatele (pochopení relevantních vazeb, jejich významu a důsledků)

1.5. Složky SI
 Integrace dat
 Integrace aplikací (funkce, software, data)
 Integrace podnikových procesů a funkcí IS/IT
 Integrace uživatelských rozhraní aplikací
 Integrace metodická
 Integrace hardwarová a technologická

vývoj integrace – viz. Voříšek

1.6. Úrovně SI
 integrace vizí
 integrace podniku s okolím
 integrace interních podnikových procesů
 technologická integrace (data, HW, SW, uživatelské rozhraní)

1.7. Specifika prostředí v české republice

Specifika českého prostředí jsou dány hlavně odlišným vývojem během poválečných čtyřiceti let a zejména pozdější transformací ekonomiky. Během období centrálně plánovaného řízení státu nebyla potřeba při řízení podniků žádných radikálních změn, neboť požadavky na tyto podniky nevycházely ani tak ze strany zákazníků, jako ze strany státu.
Po roce 1989 došlo spolu s transformací ekonomiky k četným změnám, které mají dopad na hospodářství až dodnes a často způsobují nemalé problémy. Jedním z těchto globálně platných problémů, který bývá nejčastěji uváděn je nedokonalý právní systém. V oblasti IT se to týká například toho, že firma, která dodá a udržuje informační systém, je v případě způsobení škody uživateli v důsledku nefunkčnosti systému či jeho jednotlivých částí prakticky nepostižitelná. Pojištění je v této oblasti velmi sporadické.
Podniky, které prošly procesem transformace, se potýkají s problémy, které jsou taktéž specifické pro naše prostředí. Tyto problémy lze shrnout do několika následujících bodů :
 Došlo k rozptýlení majetkové struktury:
o nejasný vlastník,
o nejasná pozice managementu,
o bitva o moc mezi vlastníky (do ní mnohdy vstupoval i management),
o nejasná strategie dalšího rozvoje.
 Byla nemožnost restrukturalizace.
 Došlo ke ztrátě současných trhů. Mnohdy byly především v bývalých zemích SSSR opouštěny na základě jistého zadostiučinění dobře zajištěné trhy. Bohužel, to byl případ nerespektování jakýchkoli ekonomických pravidel.
 Je neperspektivní či neproškolitelný management. V drtivé většině případů se jednalo o managery, kteří věřili v návrat centrálního řízení ekonomiky, vědomě odmítali nová pravidla a v důsledku toho disponovali minimálními znalostmi tržní ekonomiky, manažerskými znalostmi a dovednostmi apod.
 Nepochopení procesu restrukturalizace, které vedlo k „zahledění se do sebe“. Toto se projevovalo zvláště v letech 1990 - 93, k čemuž silně přispívalo politické klima v České republice.
 Nasycený a především nepřehledný trh informačními systémy a technologiemi.
 Je nedostatečný počet zkušených lidí majících praktické zkušenosti se zaváděním moderních informačních systémů a technologií, jejich nedobrá znalost především angličtiny.

1.8. Charakteristika IT firem na českém trhu

Na českém trhu lze identifikovat velké množství softwarových firem, které mají širokou nabídku. Pro pracovníka, který má připravit podklady pro rozhodnutí, kterou z nich vybrat, je to nelehký úkol. Z publikovaných materiálů, které jsou všeobecně dostupné, konzultací s odbornými pracovníky až po většinou dokonalé zpracování nabídky je takřka nemožné si vybrat tak, aby se eliminovaly problémy jak při přípravě projektu, tak po jeho realizaci a následné údržbě. Na druhé straně je ještě nezbytné vzít v úvahu podstatně nižší úroveň jak odborných pracovníků tak managementu firem v oblasti IS/IT na rozdíl od pracovníků firem softwarových.


Tyto firmy lze rozdělit do následující skupin:
1. Firmy, které vznikly z původních státních podniků. To probíhalo většinou takovým způsobem, že tým zaměstnanců opustil podnik a tentýž tým založil novou firmu. Do této firmy přetáhl zakázky původní firmy a většinou uzavřel smlouvy s mateřským podnikem o spolupráci apod. Je zřejmé, že nová firma hojně využívala svých původních kontaktů. Zpočátku, vzhledem ke kontaktům na mateřskou firmu a zabezpečení zakázkami, měly tyto firmy nejrychlejší rozvoj. Negativem byly především staré způsoby řízení, ignorování pravidel trhu, přesvědčení, že základem businessu jsou pouze staré nebo stávající kontakty, známosti apod.
2. Firmy nové, založené většinou mladými nadšenci. Podstatným kladem těchto firem je především obrovská energie a chuť něčeho dosáhnout, vybudovat novou prudce se rozvíjející firmu, respektování a ztotožnění se s pravidly tržní ekonomiky, efektivní organizační struktura, odborná zdatnost, nízké náklady. Mezi negativa především patří: slabé finanční zabezpečení, neprovázanost s podniky, malé kontakty a z toho plynoucí nerovný boj o získávání zakázek, mnohdy opojení z rychlého rozvoje firmy předznamenávající problémy, nepevné postavení na trhu apod.
3. Zahraniční firmy (zde se nezmiňujeme o pokusech o prodej ve smyslu „pro východ je to dobré“). Klady - silné kapitálové zabezpečení, ověřené zboží, servis, především systémový přístup, silné postavení na mezinárodním trhu. Zápory - vysoké ceny, absolutní závislost na mateřské firmě, která je většinou mimo území České republiky, což zhoršuje komunikaci při zásadnějších rozhodnutích, jednoznačná definice hardware a software a v důsledku toho odmítání jakýchkoliv modifikací. Následující sdělení jsou také často používány: „Řízení firmy se musí přizpůsobit v drtivé většině případů navrženému software“. Pro navržený software je definovaná dodavatelská firma hardware.

1.9. Reengineering v českých podnicích
Myšlenka reengineeringu se v českých podnicích, podobně jako je tomu i v Americe a západní Evropě, šíří podivuhodnou rychlostí. Ve většině významnějších podniků v západních zemích pokud již není reengineering prováděn, tak je připravován. U nás se tímto ještě pochlubit nemůžeme. Reengineering resp. procesní řízení funguje maximálně v několika desítkách firem. Ale je nutno dodat, že tato oblast je docela dost diskutovaná a v mnoha firmách se již o tomto řešení uvažuje. Důvodem je i rostoucí motivace firem pro reengineering, kterou je zejména okolí (zákazníci a konkurence) a dále potřeba snížit náklady.
V současnosti na trhu IS/IT u nás působí veliké množství firem, které poskytují školení a poradenství v oblasti reengineeringu. Zájem o tyto služby začíná projevovat stále více podniků, z čehož lze také předpokládat, že v nejbližší době nastane výrazný rozmach reengineeringu i v české republice.

1.2. Charakteristiky reengineeringu

Úrovně reengineeringu
Reengineering podniku představuje světovou globální revoluci v ekonomickém, podnikovém a manažerském myšlení. Rozlišují se především tři úrovně reengineeringu podle toho, jak rozsáhlé oblasti se přeměna bude týkat:
 Pokud měníme způsob a organizaci provádění jen některých prací (operací) uvnitř podniku (např. konstrukčně technologické práce, zásobování, výrobu komponent či odbyt), hovoříme o tzv. WPR (Work Process Reengineering). Tato úroveň bývá někdy označována jako první fáze transformace. V této fázi transformace se jedná o snížení nákladů, vzrůst kapacity a zkrácení doby dodávky. Hlavním nástrojem této úrovně reengineeringu je automatizace, tj. rozsáhlé zavádění výpočetní techniky.
 Měníme-li způsob provádění a organizaci celého produkčního procesu uvnitř podniku (tj. všechny jeho životní etapy), pak hovoříme o BPR (Business Proces Reengineering). Tato úroveň reengineeringu se označuje jako druhá fáze transformace, kdy se naše pozornost zaměřuje na zlepšení vztahů k zákazníkovi. Typicky se tato snaha projeví hledáním způsobů, jak přidat hodnotu svému produktu tak, aby byl konkurenceschopnější a jak více vyhovět zákazníkovi. Tuto fázi můžeme nazvat prostě rozšířením, protože se jedná o rozšíření našich aktivit mimo hranice podniku. Zároveň je také tato fáze zlepšováním pozice podniku na trhu i na burze. V této fázi se obyčejně zavádějí nové výrobky a nové služby zákazníkovi.
 Nejvyšší úrovní reengineeringu je ta, která opouští hranice podniku a zahrnuje i jeho okolí, tj. zejména dodavatele a odběratele. Hovoříme potom o BRE (Business Reengineering). Ústředním problémem BRE je hledání odpovědí na otázky kde a jak můžeme vytvářet hodnoty jak pro zákazníky tak, i pro akcionáře. BRE je tedy vlastně jen jiným pohledem na klasické strategické plánování. V této třetí fázi transformace obyčejně nové výrobky či služby svým rozsahem přerostou aktivity původní a osamostatní se. V důsledku toho dojde k celkové restrukturalizaci podniku, k redefinici jeho aktivit (procesů). Proto tuto fázi nazývá W. H. Davidson redefinicí.

Kromě šíře záběru se liší uvedené úrovně reengineeringu zejména svými cíli. U prvních dvou (nižších) úrovní jde většinou o snahu snížit náklady, čas potřebný k dodávce produktu a zvýšení kvality. U nejvyšší úrovně se jedná většinou o hledání zcela nových produktů a nových forem uspokojování zákazníka. Např. slučováním hotelových služeb se službami cestovních kanceláří, leteckých společností, půjčovnami aut a pod. V oblasti výrobních podniků se jedná především o propojování výrobce s distributory, ale může se jednat také o poskytování finančních služeb, nabídku speciálních konstrukčně-technologických služeb a pod.
Rozdílné je také složení týmu odborníků, kteří by měli vytvořit návrh pro reengineering. Jestliže v prvním případě vystačíme se specialisty na danou činnost často z vlastních řad, u druhé úrovně je již třeba tým nezávislých odborníků pro danou oblast podnikání zvenčí a u třetí úrovně je nezbytné vytvořit tým složený z odborníků rozmanitých profesí a zkušeností, kde budou zastoupeni jak nezávislí experti, tak také vrcholoví manažeři zainteresovaných podniků.

1.3. Základní pravidla

M. Hammer ve svém pionýrském článku (již v úvodu zmiňovaném) a později ve své knize Reengineering the Corporation - A Manifesto for Business Revolution, která je jakousi „biblí reengineeringu“ rovněž stanovil principy reengineeringu. Některé z nich jsou v organizacích samozřejmě známy již delší dobu, ale nejsou systematicky a důsledně aplikovány. Principy reengineeringu jsou tyto:
1. Organizuj výsledek práce, nikoliv práci samu. To znamená organizovat práci tak, aby jedna osoba byla odpovědná za výsledný produkt (výrobek nebo službu) dodávaný zákazníkovi. Dosavadní většinou sekvenční systém, kdy jedno oddělení určuje co se má vyrábět, druhé podle toho zajišťuje technické podmínky, třetí peníze, čtvrté to vyrábí a páté to prodává, je časově náročný a nepružný. V tomto případě bude výhodnější, aby obchodník, který je zodpovědný za danou zakázku měl možnost řídit celý proces realizace této zakázky (Něco jako funkce generálního dodavatele.)
2. Určuj co a ne jak. Nech ty, kteří jsou zodpovědní za určitý proces, aby si tento proces sami organizovali. Např. v důsledku předchozí specializace útvarů došlo k tomu, že každý útvar dělá jen určitou práci a nic jiného. Když potřebují např. v dílně nový stroj, musejí o to požádat specializovaný útvar, který jediný má k tomu sice všechny potřebné informace, avšak neví přesně, co opravdu dílna potřebuje. Proto jeho jednání s dodavateli může být těžkopádné.
3. Umožni zpracování a užívání informací těm pracovníkům, kteří je vytvářejí. Např. účtárny nebo útvary řízení kvality sbírají a vyhodnocují informace, přičemž ty útvary, o nichž tyto informace jsou, se je dozvídají opožděně, často neprůhledně a někdy s obtížemi. V době centrálních databází mohou mít tyto informace k dispozici přímo ty útvary, které je vytvářejí a mohou na ně mnohem rychleji reagovat.
4. Pracuj s geograficky rozptýlenými zdroji tak, jako by byly centralizovány. Je to aplikace známého principu distribuovaných databází na hmotné objekty. Problém konfliktu mezi centralizací zdrojů vytvářející efekt zhromadňování a nepohotovostí servisu je notoricky znám. Proto je třeba globálně řídit disponibilní zdroje distribuované lokálně, tj. blízko zákazníkovi tak, aby nedocházelo ke zbytečné redundanci a operativně je předdisponovávat. Např. u náhradních dílů to vyžaduje mít dokonalou analýzu pravděpodobnosti potřeby jednotlivých náhradních dílů a rozdělit je na ty, které budou často potřeba ve všech místech a na ty, které budou potřeba jen občas a jejich dodávku operativně zabezpečit na základě globálního informačního systému o stavu zásob dílů v jednotlivých místech a jejich okamžité potřeby u zákazníka.
5. Důsledně prováděj paralelně ty procesy, které je možno paralelně provádět. Je to princip známý např. z tzv. „souběžného inženýrství“, kdy navrhujeme jednotlivé montážní celky finálního výroku současně, příp. souběžně tvoříme technologický postup a zajišťujeme materiál. Stejný princip se dá samozřejmě uplatnit i ve výrobě a montáži. Tento princip opět vyžaduje dokonalý informační systém přístupný všem účastníků.
6. Každá informace musí být zachycena pouze jednou a v jednom místě s adresnou odpovědností za její správnost. Takto zachycená informace musí být k dispozici okamžitě všem, kteří jí mohou potřebovat ke své práci. Je to vlastně princip, který přirozeně vyplývá z předchozích principů.
7. Přistupuj k návrhu organizačního řešení jako k čistému stolu, tj. neohlížej se na to, co dosud existuje.
8. Orientuj se vždy na co nejširší záběr prořezávající celý podnik.
9. Prováděj vždy radikální změny.
10. Využívej informační technologii vždy jako iniciátora a prostředek změny

1.4. Procesní řízení

S reengineeringem velice úzce souvisí princip procesního řízení firmy. Význam této filosofie podnikového managementu vzrostl právě s rostoucím významem reengineeringu. Tento přístup umožňuje v mnoha případech daleko efektivnější řízení firmy, úsporu nákladů a času, ale zásadně umožňuje kvalitnější uspokojování potřeb zákazníků.
Pracovně pro potřeby reengineeringu definujeme proces jako posloupnost předem daných činností vykonaných proto, aby bylo dosaženo předem daných podnokových výsledků (cílů). Každý proces musí mít svého jasného „vlastníka“ tj. pracovníka odpovědného za tento proces, a též svého „zákazníka“ což je nejčastěji jiný proces, který pro svoji realizaci potřebuje výsledky předchozího procesu.
Obecně se dají všechny procesy v podniku rozdělit na následující čtyři typy:
1. Kořenové procesy (Core processes), zabezpečující hlavní podnikové funkce a bezprostředně spojené s uspokojením zákaznických potřeb. Typickým reprezentantem je realizace zakázky. Kořenové procesy stojí v popředí hodnotového řetězce a na ně se obyčejně zaměřujeme především.
2. Podpůrné procesy (Support processes), které mají tzv. „vnitřní“ zákazníky (tj. procesy probíhající uvnitř podniku) a jsou v pozadí kořenových procesů. Typickým reprezentantem může být např. zásobování, fakturace, účetnictví a pod. Jedná se o administrativní činnosti, které se nacházejí v pozadí hodnotového řetězce, a proto se často tyto procesy řeší formou služeb interních či externích organizací (outsourcing).
3. Mezipodnikové procesy (Business network processes), které překračují hranice podniku, tj. jsou např. realizovány z části u dodavatelů (speciální příprava materiálů a subdodávek), u spolupracujících firem (distributorů či kooperujících a servisních firem) nebo přímo u konečného zákazníka. Pro realizaci těchto procesů je samozřejmě nezbytný zcela nový pohled na otevřenost a komunikaci, protože hlavní otázkou k řešení je, jak rozdělit jednotlivé části procesu mezi partnery a jak s nimi komunikovat.
4. Řídící procesy (Management processes), jimiž firma plánuje, organizuje a řídí své zdroje. Zde je hlavní otázkou k řešení míra autokracie a demokracie a s tím spojená delegace rozhodovacích pravomocí směrem shora dolů, resp. směrem k místům potřeby těchto zdrojů.

1.5. Postavení IT v reengineeringu

Informační systémy a informační technologie (IS/IT) se staly strategickou zbraní, která má podstatný vliv na efektivnost firem a to ve všech odvětvích. Cílem je získat konkurenční výhody, zkoušet a zavádět v reálném čase nové metody řízení.
Zvláště specifické postavení mají IT v souvislosti s reengineeringem, neboť právě ten je založen na automatizaci a na podstatném využívání IT. Reengineering nemění jenom hlavní podnikatelské procesy, ale potřebuje také, aby i útvary pro IS pracovaly zásadně jiným způsobem, aby byly schopné aplikovat nové technologie a nástroje, ukazovat šíři možných přístupů k informační technologii.

1.6. Význam reengineeringu v českých podmínkách
Po téměř deseti letech, co u nás funguje volná tržní ekonomika jsme dnes již dospěly do stadia, kdy u nás existuje poměrně kvalitní obchodní prostředí s množstvím profesionálně řízených firem, podobně jako je tomu třeba v západní Evropě. Manažeři podniků, pokud chtějí v tomto konkurenčním prostředí přežít, musejí provádět změny a rychle a flexibilně reagovat na potřeby zákazníků.
Manažer, stejně jako lékař, musí pečlivě sledovat zdravotní stav svého podniku a jeho vývoj. Musí analyzovat příčiny zhoršování zdravotního stavu a provádět především preventivní léčbu. Teprve tehdy, není-li preventivní léčba účinná a zdravotní stav se rychle zhoršuje, je třeba přistoupit k radikální léčbě - reengineeringu.
Každá léčba, zejména pak radikální, však představuje riziko. Proto si musí každý manažer položit především otázku: Mohu si toto riziko dovolit? Informace o atraktivních a pronikavých zlepšeních u společností, které prošly reengineeringem je třeba samozřejmě násobit příslušným koeficientem rizika, který se uvádí zhruba ve výši 50%.
Většina manažerů začíná s reengineeringem tak, že hledá detailní metodologii a nástroje na podporu řízení procesu reengineeringu. Mnohem podstatnější, než tyto nástroje je však to, aby celý management podniku měl správný a tvořivý přístup k potřebě změny, protože reengineering není nic jiného, než tvořivý přístup a přemýšlení nad problémem jak změnit podnik tak, aby vytvářel a poskytoval zákazníkovi vyšší hodnoty než dosud.

Úloha podnikových procesů při vývoji IS/IT

Důvody a podstatné rysy reengineeringu podnikových procesů (BPR). Statický versus procesní pohled na podnik. Úloha IS/IT v BPR a v řízení podnikových procesů. Úloha procesního řízení podniku ve vývoji IS/IT podniku.



1.1. Reengineering
Pojem reengineering byl poprvé použit Michalem Hammerem v roce 1990 v jeho článku Reengineering Work - Don’t Automate, Obliterate. Během této poměrně krátké doby nabyl takového významu, že dnes ve státech s vyspělou tržní ekonomikou již prakticky neexistuje významnější podnik, který by o reengineeringu alespoň neuvažoval.
Podnikatelské prostředí je v důsledku globalizace čím dál tím více turbulentnější, stává se náročnější, konkurenčnější a internacionálnější, takže jenom dynamicky se rozvíjející podniky mohou přežít. A právě reengineering se stává v posledních letech jedním z nejvýznamnějších prostředků k získání konkurenční výhody prostřednictvím efektivní změny řízení organizace. V České republice byl vývoj poněkud odlišný, neboť naše tržní prostředí je daleko mladší a díky specifickým podmínkám, které zde po roce 1989 nastaly, většina podniků až do nedávné doby nepociťovala potřebu žádné výraznější změny. Avšak s rozvojem a postupným přitvrzování konkurenčního prostředí je i u nás tento pojem čím dál tím více skloňován.

1.6. Model vývoje IS podniku

· Východiskem návrhu IS je globální podniková strategie (GST), která určuje hlavní směry a priority rozvoje podniku.
· Na globální podnikovou strategii (GST) navazuje informační strategie (IST), jejímž cílem je navrhnout IS/IT podniku tak, aby byly optimálně podpořeny celopodnikové cíle definované v GST. IST popisuje mj. všechny informatizační projekty podniku (stávající i budoucí) a zajišťuje jejich konzistenci - viz dále.
· Stávající i budoucí stavy IS/IT jsou popsány metasystémem (MtS). MtS je nástroj podporující řízení vývoje IS/IT. Umožňuje popis a ověřování konzistence jednotlivých stavů IS/IT. Detailněji jsou architektura a funkce MtS analyzovány např. v [VOR94a], [VOR94b], [VOR94d].
· Na IST navazují jednotlivé informatizační projekty v různém stavu rozpracovanosti - některé ve stavu plánování, jiné ve stavu vývoje (US-úvodní studie, GN-globální návrh, DN-detailní návrh, IM-implementace, ZA-zavádění) a ostatní ve stavu provozu a údržby (PU).
· Jak IST, tak i jednotlivé projekty jsou zpracovány z pohledu několika dimenzí a jejich vzájemných vazeb: informační/datové (inf), procesní/funkční (pro), ekonomické/finanční (eko), organizační (org), pracovní/sociální (pra), softwarové (sw), hardwarové (hw), metodické (met), dokumentační (dok) a manažerské (mng).

1.1. Globální strategie podniku - východisko IS podniku
· Globální podniková strategie (GST) není jedenkrát vytvořený neměnný dokument - prochází životním cyklem, který jednak zajišťuje realizaci stanovené GST a jednak umožňuje přizpůsobení GST změnám externích a interních podmínek - viz.
· Prvním krokem při formulaci GST dle MDIS je tzv. SWOT analýza (strengths, weaknesses, opportunities, threats), která analyzuje externí možnosti a hrozby a interní silné a slabé stránky podniku. Součástí analýzy je hledání příčin dané situace. SWOT analýza se provádí z různých pohledù (dimenzí). Každá dimenze představuje samostatný faktor, který významně ovlivňuje činnost podniku.
· Po analýze jednotlivých externích a interních faktorù následuje vymezení kritických faktorù rozvoje podniku. Při vymezení kritických faktorù se bere v úvahu závažnost (význam) každého faktoru a doba jeho působení. Současně se analyzují vzájemné vztahy faktorů a vymezují se oblasti "výzev" a "nebezpečí" pro podnikání podniku. Globální strategie by měla být pochopitelně formulována tak, aby podnik maximálně využil svých silných stránek a externích příležitostí a eliminoval své slabé stránky a vyhnul se externím hrozbám.
· Na základě provedené a vyhodnocené SWOT analýzy se ve druhém kroku tvorby globální strategie formuluje poslání (mission) podniku. Poslání definuje smysl existence firmy, tj. mìlo by odpovídat na následující otázky:
a) jaké potřeby chce firma uspokojit ?
b) jakých skupin zákazníkù ?
c) v jakém teritoriu ?
d) jakou technologií ?
· V třetím kroku tvorby GST se definují globální podnikové cíle, jejichž dosažením se naplní poslání podniku a uspokojí zájmy vlastníků podniku. Globální cíle se formulují na období tří až pěti let, a to ve čtyřech rovinách:
q cíle z hlediska vlastníků podniku ,
q cíle z hlediska vrcholového vedení podniku ,
q cíle z hlediska pracovníků podniku,
q cíle z hlediska společnosti .
· Aby podnik dosáhl svých cílù, vykonává řadu tzv. globálních podnikových funkcí. Vymezení těchto funkcí a celopodnikových programů (projektů) rozvoje je náplní čtvrtého kroku tvorby GST. Typickými globálními funkcemi výrobního podniku jsou:
q vrcholové řízení a organizace,
q nákup,
q výroba,skladování/služby,
q prodej (marketing, odbyt),
q výzkum & vývoj,
q personální řízení,
q finanční řízení,
q informatika.
· Celopodnikové programy rozvoje jsou návrhem alternativních cest dosažení podnikových cílů. Např. je-li jedním z cílů podniku proniknutí s produkty podniku do nového teritoria, může jeden z programů rozvoje specifikovat postup vytvoření sítě distributorů a dealerů v daném teritoriu.
· Posledním krokem tvorby GST, který je současně přechodem k implementaci globální strategie je tvorba strategií jednotlivých globálních podnikových funkcí (prodeje, výroby, informatiky atd.). GST je jednak zdrojem, na který všechny dílčí strategie navazují, a jednak nástrojem pro udržení konzistence a vzájemných vazeb mezi globálními podnikovými funkcemi. Konzistence je zajišťována celopodnikovými programy, které koordinují hlavní procesy probíhající na základě dílčích strategií. Například proniknutí do nového teritoria bude vyžadovat koordinaci marketingu (zmapování trhu v daném teritoriu), výroby (výroba produktů pro nový trh), odbytu (vytvoření nových distribučních kanálů), informatiky (informační podpora nové výroby a odbytu), personálního řízení (zajištění pracovníků pro práci v novém teritoriu) atd.

1.8. Informační strategie (IST)

Informační strategie představuje dlouhodobou orientaci podniku v oblasti informačních zdrojù, služeb a technologií. Jejím cílem je formulace cílů podnikové informatiky, návrh cest jejich realizace a minimalizace rizik vývoje IS. Je zpracovávána variantně, aby podnik měl připraveny reakce na očekávané změny jak uvnitř podniku, tak zejména v jeho okolí.
Metodologie MDIS definuje obsah informační strategii následujícími body:

1. Specifikace vazeb informační strategie na globální strategii. Jde o výběr cílů globální strategie, podnikových programů a funkcí, které budou vyžadovat specializovanou a/nebo rozsáhlou informační podporu, resp. budou mít vliv na provoz IS (např. jeden z programů rozvoje podniku plánuje zřídit další pobočku firmy v jiném městě a počítá s jejím úzkým informačním propojením na hlavní sídlo firmy).

2. Analýza současného stavu a vývoje informačního systému podniku. Stávající informační systém se analyzuje z hlediska všech dimenzí IS (viz výše). Při analýze by neměla být podceňována "historická" hlediska. Umožní nám lépe pochopit a odhadnout zakódované zvyklosti v chování pracovníků a jejich vztah k informačním technologiím, umožní i posoudit úroveň dosud poskytovaných služeb zákazníkům a s tím související pozici na trhu apod. Souhrnně směřuje tato část k určení faktoru, který se označuje jako genetický kód organizace. Genetický kód do značné míry předurčuje směr evolučního vývoje podniku. O co víc budou nové podnikové cíle ležet mimo směr určovaný stávajícím genetickým kódem o to více zdrojů a úsilí bude nutné vynaložit na jejich dosažení, protože bude nutné změnit i genetický kód. K výrazné změně genetického kódu dochází například při právě probíhající privatizaci podniků.

3. Určení cílů IS/IT a určení kritických faktorů dosažení těchto cílů. Podobně jako tomu bylo v případě globální strategie i zde se na základě provedené analýzy stavu IS a závěrů globální strategie identifikují kritické faktory rozvoje podnikové informatiky a formulují se cíle informatiky na období dvou až tří let. Cíle IS/IT určují druh, objem a kvalitu budoucích informačních zdrojů a služeb v rozdělení na interní a externí. Modifikace stávajících a aktivace nových informačních zdrojů a služeb je zaměřena na dosažení nové kvality řídících, obchodních, výrobních a dalších aktivit. Zvláštní pozornost se zde věnuje externím informačním zdrojům a službám, tj. využívání služeb specializovaných institucí a jejich databází pro marketing, strategické a taktické řízení a na druhé straně služeb poskytovaných podnikem jeho partnerům. Tendence velkých zahraničních podniků směřuje dnes k tzv. IOS (InterOrganization Systems), tedy k přímému terminálovému nebo počítačovému provázání podniku s jeho zákazníky, dodavateli a dalšími partnery. To vede k mimořádnému zvýšení pružnosti v objednávkové činnosti, spolehlivosti poskytovaného garančního i pogarančního servisu, snížení nákladů na ně a tím i k udržení stávajících zákazníků event. získání nových. Tato tendence se začíná projevovat již i u nás. Přímé propojení na zákazníky zavádějí některé banky a RM-systém.

4. Návrh architektury informačního systému. Protože informační strategie je řešena ve všech obsahových dimenzích IS, má návrh architektury několik částí:
 globální architektura IS,
 datová architektura,
 funkční architektura,
 procesní architektura,
 softwarová architektura,
 hardwarová architektura.
Globální architektura IS je konceptuálním modelem celého informačního systému a je jedním z nejdůležitějších výstupů informační strategie, protože syntetizuje všechny pohledy na IS a provozované, řešené i plánované projekty. Na globální architekturu pak navazují další uvedené architektury.

5. Návrh nutných změn v organizaci a v systému řízení, které obvykle směřují ke zplošťování organizačních struktur a posilování horizontálních vazeb. Je evidentní, že informační technologie hrají v těchto změnách významnou roli. Na druhé straně je nutné počítat i se vznikem zcela nových útvarů uvnitř podniku, spojených s rozvojem IS/IT, jako jsou informační centra (tzv. "hot line" nebo "help desk"), správci sítí, dispečerská střediska pro řešení vnějších informačních služeb apod.

6. Kvalifikační, resp. rekvalifikační program ve vazbě na rozvoj informačních technologií a na změny v organizaci. Určují se skupiny pracovníků, pro které bude nutné uspořádat školení, obsah těchto školení, časový harmonogram, organizační a personální zajištění, softwarová podpora jeho realizace, stimulace a motivace pracovníků.

7. Ekonomické aspekty informační strategie zahrnují kalkulaci nákladů navrhovaných interních i externích informačních služeb, cenovou politiku v oblasti informačních služeb a zaměření marketingu v této oblasti. Jde tak o vytvoření obchodní a cenové strategie v oblasti informatiky. Současně se analyzují ekonomická rizika navržených variant řešení a celkové ekonomické efekty informační strategie. Tyto efekty jsou primárním cílem IST. Jednotlivé etapy realizace IST proto nekončí dodávkou hardware a software, ale až "dodávkou" příslušného ekonomického efektu.

8. Metodické standardy projekce a implementace jednotlivých projektů. Informační strategie standardizuje metody a prostředky projekce a implementace informačního systému (např. CASE nebo jiné nástroje této orientace), neboť jejich použití má dlouhodobý dopad na údržbu a další rozvoj informačního systému (zejména z hlediska ceny a rychlosti řešení).
9. Definování jednotlivých informatizačních projektů a jejich základních parametrů a vzájemných vazeb. Tato část informační strategie je jejím nejpodstatnějším výstupem, protože jsou v něm shrnuty a "materializovány" všechny předcházející části.
Popisují se zde všechny stávající informatické projekty (provozované i v současné době vyvíjené) a jejich vzájemné vazby. Tyto projekty de facto popisují stávající stav informatiky podniku.
Navazující částí je popis budoucích informatických projektů a jejich vazeb. Tyto projekty představují transformaci stávajícího stavu do požadovaného budoucího (cílového) stavu IS/IT, který byl z hlediska jednotlivých dimenzí specifikován v předcházejících částech IST.
Jak bylo uvedeno výše, realizace informatických projektů musí být koordinována s ostatními procesy v podniku. Tuto koordinaci zajišťují celopodnikové programy definované v rámci globální podnikové strategie.

Dalšími klíčovými otázkami spojenými s informační strategií jsou:
 kdo řeší IST?
 v jaké podrobnosti?
 jak dlouho?
 kdy se IST mění?

• Řešitelem IST je obvykle tým složený z vrcholových pracovníků podniku a z externích konzultantů. Není vhodné, aby IST byla vytvořena pouze externí organizací. Hlavním důvodem je, že IST musí měnit genetickou informaci podniku. Této změny nelze dosáhnout dodávkou mnohastránkového dokumentu. Žádoucí změny genetického kódu organizace se dosáhne pouze "dodávkou" nových znalostí a nového hodnotového systému formou diskusí mezi externími konzultanty a pracovníky podniku, školením a řídícími zásahy vedení podniku.
• Informační strategie nesmí zabíhat do přílišných detailů, a to zejména v části týkající se použitých IT. Informační technologie se vyvíjejí tak rychle, že by IST detailně popisující budoucí IT zastarala příliš rychle. Detailní specifikaci IT je proto vhodné nechat až na jednotlivé naplánované projekty.
• Aby informační strategie přinesla skutečně strategický efekt, nesmí se vytvářet ani realizovat příliš dlouho. Obvyklou dobou tvorby výchozí verze IST jsou 2-3 měsíce a obvyklým horizontem a dobou realizace IST jsou 2 roky.
• Hospodářské prostředí se v současné době vyvíjí také velmi rychle. Podnik nereagující permanentně na nastávající změny brzy začne stagnovat nebo se dokonce dostane do existenčních potíží. Z toho důvodu se musí podniková strategie pružně vyvíjet. Mění-li se GST musí se měnit i IST, jinak by IS/IT podniku nemohly podporovat dosažení cílů stanovených v GST. Obvyklou periodou změn GST a tím i IST je jeden rok.
• Jak je z výše uvedeného zřejmé, pokrývá informační strategie v pojetí metodologie MDIS značný rozsah problémů zásadního významu pro většinu aktivit podniku. Úspěšné vyřešení těchto problémů může být podstatným impulsem dynamického rozvoje podniku.
• IS a IT jsou v současné době jeden z rozhodujících faktorů zajištění konkurenceschopnosti podniku. Aby bylo možné dosáhnout optimálně fungujícího IS, je potřeba integrovat IS/IT s globální podnikovou strategií. Tato integrace procházela několika stádii (nezávislé IS a GST, částečná integrace a úplná integrace). Úkolem IST je zajistit integraci IS/IT s globálními cíly organizaci, tedy s GST. IST je dlouhodobou koncepcí pro oblast informatiky v organizace. Cílem je formulovat a podporovat kritické faktory úspěchu informatiky v dané organizaci. IST se zpracovává variantně na období cca 3 - 5 let a průběžně se aktualizuje.

Zatím, co ve vyspělých státech jsou IST součástí běžné praxe i universitního výzkumu, v našich podmínkách musíme počítat ještě s řadou problémů.
V prvé řadě se jedná o současné ekonomické a legislativní problémy. Tyto problémy zastiňují postavení IT a jejich význam pro řešení některých problémů podniku. Jako další problém se jeví snaha v řadě podniků udržet provoz původních projektů, jejich použitelnost je stále více omezována měnícími se ekonomickými podmínkami. Vedoucí pracovníci v oblasti informatiky jsou přetíženi operativními problémy a "nemají čas" na koncepční řešení.
Řešení IST je v zahraničí převážně záležitostí specializovaných konzultačních firem ve spolupráci s vrcholovým vedením organizace, jehož členem je též obvykle informační manažer. Ukazuje se totiž, že externí pohled na rozvoj informatiky bývá nezbytným při hledání nových cest řešení.
Tato fáze životního cyklu IS může být v různých metodologiích nazývána různě, její cíl je však všude stejný. Odlišnosti mohou být ve vazbě na GST, některé metodologie začínají až u IST a ne u GST. Příkladem odlišné metodologie, z heldiska vztahu ke GST je SDM - začíná fází Information Systems Planning = IST. (dále viz rozdílly jednotlivých metodologií.

Vztah globální a informační strategie podniku

Charakterizujte obsah globální a informační strategie podniku a jejich vzájemné časové a obsahové vazby. Význam, cíle a obsah informační strategie. Vazba IST a jednotlivých projektů. Kritické faktory úspěchu IST.



1.1. Význam a cíle IST
informační strategie je modelem budoucího stavu IS/IT
spolu s globální podnikovou strategií zajišťuje:
q integraci vizí a idejí
q integraci podniku s okolím
q integraci interních podnikových procesů

sama pak ještě navrhuje řešení technologické integrace IS/IT
Cílem IST je navrhnout celkovou koncepci IS/IT podniku tak, aby byly optimálně podpořeny celopodnikové cíle definované v globální podnikové strategii a navrhnout jednotlivé kroky realizace IS/IT (= jednotlivé verze IS/IT)

IST
q navrhuje technologickou integraci IS/IT
q navrhuje celkovou architekturu IS/IT
q určuje legislativní rámec a standardy závazné pro celý IS/IT
q definuje všechny informační projekty podniku (stávající i budoucí)
q zajišťuje konzistenci těchto projektů

1.2. Principy tvorby informační strategie
q nezbytná účast vedení podniku – formalizují hlavní cíle IS/IT
q doba řešení – cca 3 měsíce, rozsah 120 – 200 stran
q časový horizont: 2 – 3 roky (vzhledem k rychlosti změn ekonomického prostředí i IT)
q periodické aktualizace informační strategie (1/2 – 1 rok)
q dostupnost informační strategie všem zainteresovaným pracovníkům
q verifikace nových projektů vzhledem k informační strategii


1.3. Struktura informační strategie
Shrnutí (5 – 8 stran)
nejhrubší pohled na IS/IT
shrnuje základní závěry a doporučené strategie
Hlavní část (80 – 120 stran)
zdroje, cíle a východiska zpracování informační strategie
analýza a hodnocení současného stavu IS/IT v podniku a ve světě
návrh cílového stavu IS/IT
způsob transformace ze současného do cílového stavu
Přílohy
podrobné informace týkající se jednotlivých analýz a návrhů

1.4. Postup tvorby informační strategie
Plánování informační strategie
q upřesnění obsahu a hloubky řešení
q návrh organizace řešení
q složení řešitelského týmu, definování odpovědností a pravomocí řešitelů, určení pracovních podmínek
q stanovení harmonogramu řešení

Převzetí závěrů globální strategie a jejich verifikace
q výběr faktorů SWOT analýzy, cílů globální strategie a podnikových programů rozvoje, které budou vyžadovat specializovanou a/nebo rozsáhlou informační podporu, resp. budou mít vliv na provoz IS/IT

Formulace vize a cílů IS/IT
q analýza a hodnocení trendů IS/IT
q analýza a hodnocení dosavadního IS/IT
q shrnutí požadavků na IS/IT
q formulace vize a cílů IS/IT
q odsouhlasení závěrů etapy

Reengineering IS/IT

q návrh cílového stavu IS/IT a návrh cest transformace současného stavu do stavu cílového (v předchozích etapách byly shromážděny všechny informace, které jsou pro reingeneering IS/IT potřebné) – kroky:
§ globální architektura IS/IT
§ funkční a procesní architektura
§ datová architektura
§ technologická architektura
§ softwarová architektura
§ hardwarová architektura
§ organizační a legislativní aspekty
§ pracovní, sociální a etické aspekty IS/IT
§ principy řízení vývoje IS/IT
§ principy řízení provozu IS/IT
§ specifikace projektů a jejich priorit
§ harmonogram realizace informační strategie
§ ekonomická analýza a rozpočet informační strategie
§ prezentace a odsouhlasení informační strategie

1.1. Východiska přístupu k řešení IS podniku
Zde prezentovaný přístup ke strategickému řízení IS podniku vychází z MDIS (Multidimensional Development of Information System) - metodologie vyvíjené katedrou informačních technologií, VŠE. Aby se informační systém mohl projevit jako strategický faktor prosperity a konkurenceschopnosti podniku, musí mít dle MDIS následující základní charakteristiky:
a) musí být navržen tak, aby podporoval dosažení strategických cílů podniku; jinými slovy, návrh IS musí vycházet z globální podnikové strategie,
b) musí být budován jako integrální, konzistentní celek s jednoduchou a řešitelům i uživatelům srozumitelnou architekturou,
c) musí být chápán vedením i všemi ostatními pracovníky podniku jako jedno z hlavních jmění podniku, a podle toho s ním musí být nakládáno.

Uvedené charakteristiky, resp. předpoklady efektivního IS podniku, vycházejí z následující argumentace.
· Vysoké investice do moderních IS/IT nejsou automatickou zárukou efektivnosti informačního systému podniku. Z provedených analýz vyplývá, že u řady podniků neexistuje významná korelace mezi investicemi do IS/IT a prosperitou podniku. Tehdy, když IS nepodporuje celopodnikové zájmy a cíle, ale naopak je budován na základě lokálních zájmů jednotlivých útvarů podniku, může IS dokonce napomáhat k nízké celopodnikové efektivitě, nebo dokonce k postupné desintegraci podniku.
· Z charakteristiky ad (a) vyplývá, že nemá-li podnik ujasněnou svoji strategii, nemá-li jasnì definované své poslání a cíle své činnosti, je nereálné předpokládat, že nákupem nejmodernějších IT dosáhne vyšší efektivnosti.
· Kvalita architektury IS značně ovlivňuje náklady vývoje, údržby i užití informačního systému. IS musí být proto budován jako konzistentní celek, a to na základě jasné a všem (tvůrcům i uživatelům) srozumitelné architektury a na základě přesně vymezených standardů (technických, softwarových, datových, komunikačních, metodických atd.).
· I když IS splňuje první dvě uvedené charakteristiky, je ho neustále třeba chápat jako potenciál prosperity podniku, nikoliv jako investici, prosperitu automaticky zajišťující. Teprve tvůrčím využitím informací a funkcí IS se podnik může začít pohybovat směrem k cílům vytčeným v podnikové strategii.
· Je třeba si uvědomit, že hodnota informací, resp. znalostí uložených v IS neklesá s jejich použitím, ale s časem. Nejvhodnějším postupem v tomto směru je, dát uložené informace co nejdříve k dispozici co možná nejširšímu spektru zaměstnanců podniku. Úzkostlivé chránění přístupu k informacím v IS může být dalším faktorem, který snižuje využití potenciálu, který je v IS skryt.

Zodpovědnost za IS/IT podniku

Charakterizujte možné varianty řešení IS/IT podniku z hlediska zodpovědnosti za tvorbu, integraci a provoz IS/IT. Analyzujte přínosy a rizika těchto variant.



Promítání změn do projektu, dlouhodobá údržba projektu, důvody změn, odpovědnost za údržbu, předpoklady údržby projektů, životnost projektu, přípravy inovace projektu, autorský dozor

1.1. Životnost projektu
Každý automatizační projekt prochází 3 obdobími:
1) období tvorby projektu a jeho ověřování
2) období relativní spolehlivost projektu (rutinní využívání)
3) období morálního znehodnocení projektu


· V prvním období se odstraňují nedostatky, ověřují se programy..
· Druhé období znamená průběžnou údržbu projektu, promítání změn, které nenarušují základní filosofii systému.
· Třetí období je podle rozboru jednotlivých stadií projektování nejdůležitější. Každý projekt se mění a vyvíjí v čase - často dochází k prudkému znehodnocení projektu. Je to způsobeno nespolehlivostí stárnoucího počítače, zastarávání dokumentace, potřebou řešit nové požadavky uživatelů, v dnešní době způsobují asi nejvíce znehodnocení projektů změny právních předpisů a hospodaření vůbec.

1.2. Dlouhodobá údržba
q stadium rozvoje a údržby systému nabylo veliké důležitosti
q v některých podnicích existuje už dnes v analyticko programátorských úsecích převaha prací zaměřených na údržbu a doplňování již realizovaných projektů
q např. 80 % všech kapacit firmy slouží údržbě a vývoji dříve vytvářených objektů
q je nutné zabývat se otázkami:
§ jaké jsou příčiny změn
§ jak tvořit projekty snadno udržovatelné
§ kdo má realizovat zásahy do projektů
§ jak slouží dokumentace k podpoře údržby projektů

1.3. Důvody změn
charakter změn
q změny snadno realizovatelné(nové výstupní sestavy, změny algoritmů bez změny DZ, ..)
q změny závažného charakteru (změna DZ, změna filosofie zpracování úlohy, ..)

promítání změn do projektu je závislé na celkovém návrhu projektu
pokud se v návrhu počítá s budoucím vývojem, pak se změny v projektu snadno realizují

1) Změny od uživatelů
vnitřní vývoj systému řízení v podniku
q každý projekt je odrazem určitého stavu systému řízení a slouží k podpoře tohoto systému
q důležité je, aby změny v systému řízení byly před jejich utvářením konfrontovány s projektanty a případně byly modifikovány, aby nezasáhly rušivě do stávajících projektů
q při dobré spolupráci je možné provádět řadu změn se stávajícími daty
vnější vlivy na podnik
q trh, legislativa
q tyto vnější vlivy jsou uživateli projektu interpretovány jako nezbytně nutné zásahy do řízení a zprostředkovaně do projektů = jsou nutné pro přežití podniku
q tyto změny přinášejí velké ztráty způsobené přepracováním projektů
q je třeba zvážit, zda je lépe projekty změnit, či vytvořit nové
zjištění chyb a nedostatků v uživatelských projektech
q týká se to hlavně velkých projektů, kde je často pomocí zkušebních souborů dat ověřena pouze část variant, hlavně z důvodů časových nákladů na zkušební provoz

2) Změny z pozice řešitelů
změny výpočetního systému
q nový HW, SW,OS, SŘBD
q lze jej rozdělit na inovaci celého systému či dílčích částí
optimalizace některých funkcí projektu
q zlepšení spolehlivosti, komunikace, bezpečnosti, efektivnosti, objektivizace DZ
q optimalizaci projektu je třeba provádět uváženě, neboť velké zásahy do projektu mohou znamenat narušení stability a omezení dalšího vývoje projektu

nejčastěji jsou požadované změny vyvolány uživatelskou sférou
její schválení nesmí být soukromou věcí či dohodou mezi programátory a uživateli
většinou je stanoven kolektiv vedoucích pracovníků, kteří hodnotí požadované změny do projektu

Kdo změny realizuje:
q zbytky původního řešitelského týmu
q provozní programátoři
q kdokoliv z analytiků a programátorů
Dohled nad provozem mají provozní programátoři a při dobré dokumentaci jsou schopni realizovat malé změny do projektu.

1.4. Předpoklady údržby
q mít metodu projektování
q strukturovaný přístup
q perfektní dokumentace (automatizovaná)
q určení odpovědnosti za údržbu
q předpokládat, že se systém bude udržovat
q nové metody CASE - zlepšuje dokumentaci, přehlednost, strukturovanost, transparentnost, ..

1.5. Příprava inovace projektu
q prostudovat si dostupnou dokumentaci
q specifikovat charakter změny a akceptační kritéria - projednat to s uživatelem
q návrh realizace změn
q změny v projektu (zachování původního kódování, ..)
q vytvoření plánu testů, ověření funkcí po změnách
q implementace opraveného systému - uvedení do provozu a zaznamenávání všech změn do dokumentace

1.6. Další souvislosti
q kde jsou hranice únosných změn systému
q odhad budoucího vývoje systému (vyhodnocování dotazů, reklamací, automatizovaných statistik provozu
q sledování nákladů o změnách
q seznámení uživatelů se změnami
q sledování vytíženosti HW
q shoda stavu systému se stavem globální a informační strategie

Řízení ekonomiky IS/IT

 Finanční plánování v oblasti IS/IT, analýzy nákladů a dosahovaných efektů.
 Cíl – dosažení optimálního poměru cena/výkon
 Vstupy – informační strategie, podklady z účetnictví (náklady, efekty)
 Výstupy – nákladové analýzy na IS/IT, finanční plány a rozpočty
 Zodpovědnost – většinou informační manažer + pracovníci úseku IT a ekonomičtí specialisté


Hlavní náplň:
 Koncepce sledování a vyhodnocování nákladů a přínosů IS/IT
 Dlouhodobé plánování nákladů na IS/IT
 Zpracování rozpočtů na provoz a rozvoj IS
 Kalkulace nákladů na IS/IT
 Evidence nákladů na IS/IT v rámci analytického účetnictví
 Analýza nákladů na IS/IT podle zvolených hledisek
 Analýzy a návrh cenové strategie za služby
 Analýzy dosahovaných efektů

Personální řízení IS/IT
 Plánování personálních kapacit, kvalifikační rozvoj pracovníků.
 Cíl – takový rozvoj kvalifikace a znalostí pracovníků firmy, které zaručí efektivní využití vložených investic do informatiky (řízení znalostí podniku)
 Vstupy – informační strategie, podklady z podnikové personalistiky, potřeby personálních kapacit projektů
 Výstupy – plány rozvoje personálních kapacit, školení, rekvalifikace
 Zodpovědnost – informační manažer

Hlavní náplň:
 Analýzy vlastních pracovních kapacit
 Hodnocení personálního zajištění IS/IT
 Plánování stavu personálu pro IS/IT
 Operativní evidence pracovníků
 Kvalifikační programy v oblasti IS/IT
 Operativní plánování a zajištění jednotlivých odborných školení

Řízení disponibility – systémových vlastností
 Plánování a vyhodnocování průřezových charakteristik celého inf. systému podniku
 Cíl – dosažení požadovaných provozních charakteristik IS za přijatelných nákladů
 Vstupy – informační strategie, organizační řád, provozní řád IS/IT, podnikové bezpečnostní směrnice, dokumenty ISO 9000
 Výstupy – definování specifických projektů rozvoje bezpečnosti, spolehlivosti, výkonu, nové či upravené podnikové směrnice
 Zodpovědnost – informační manažer, vedoucí provozu IT, týká-li se to specifické oblasti – pracovník dané oblasti

Hlavní náplň:
 Řízení bezpečnosti IS/IT
 Řízení systémové doby odezvy
 Řízení pružnosti (flexibility) systému

Řízení datových zdrojů
 Projektování interních i externích datových zdrojů, nikoli správa databází
 Cíl – dosažení optimálního rozsahu a kvality dat pro provozované aplikace, žádoucí poměr mezi vlastními a externími zdroji
 Vstupy – informační strategie, operativní evidence využívaných dat. zdrojů a projekční a provozní dokumentace
 Výstupy – plány rozvoje a integrace datových zdrojů včetně externích.

Hlavní náplň:
 Analýza stavu interních datových zdrojů, databází
 Plánování rozvoje interních datových zdrojů
 Analýzy potřeb a možností externích datových zdrojů
 Analýzy možností a plánování mobilních databází
 Prezentace ve veřejných datových zdrojích a službách
 Řešení integrace databází a datových zdrojů

Řízení informačních technologií
 Analýza, výběr, pořízení všech komponent informačních technologií – DB systémů, operačních systémů, technických prostředků.
 Cíl – rozvíjet a naplňovat kvalitní technologickou architekturu systému a vytvořit tak předpoklad pro efektivní provoz IT, min.nákladů na správu, prostor pro rozšiřování.
 Vstupy – informační strategie – definice základní koncepce rozvoje, studie specializovaných firem na analýzy trendů IT, analýzy trhů atd.
 Výstupy – konkretizace a detailizace technologické architektury IS/IT, stanovení standardů a požadavků na výběr komponent, plány a požadavky na upgrade, atd.
 Zodpovědnost – pověřený specialista (vedoucí rozvoje IT, systémový architekt, atd.)

Hlavní náplň:
 Řízení technologické architektury
 Pořízení nových komponent technologického prostředí
 Řízení upgrade všech komponent HW, ZSW
 Řízení technologické integrace
 Systémová podpora provozu
 Definování standardů a pravidel pro použití IT

Řízení rozvoje aplikací – zadávání a koordinace projektů
 Projekty IS/IT – formulace zadání, posuzování, způsob řešení – řízení rozvoje celkové funkcionality IS/IT podniku.
 Cíl – směřovat IS/IT k optimální funkcionalitě – pokrytí všech potřebných funkcí aplikační produkty, redukovat duplicity. Řídící procesy směřují k obsahové optimalizaci zadání nových projektů a současně k časové synchronizaci řešených projektů.
 Vstupy – informační strategie, celková, funkční a procesní architektura, evidence uživatelských požadavků na nové funkce a služby.
 Výstupy – zadávací dokumentace projektů a dokumentace výběrových řízení (až smlouva s dodavatelem)
 Zodpovědnost – za nové projekty – vedoucí oddělení vývoje IS/IT, u větších projektů celé vedení firmy.
Hlavní náplň:
 Analýzy uživatelských požadavků na rozšíření a rozvoj IS/IT
 Vstupní analýzy před zahájením projektu
 Specifikace projektů, projektový záměr
 Posuzování projektových záměrů
 Rozhodnutí o přijetí či nepřijetí projektu a způsobu řešení
 Zadání projektu řešitelskému týmu
 Realizace výběrového řízení (v případě dodavatelského řešení) - postup
 Kontraktační řízení na úvodní studie

1.1.3. Operativní úroveň
Implementace a zavádění
 Implementace/customizace
 Testovací procedury
 Příprava provozu a migrace
 Předávací procedury

Řízení provozu
 Veškeré řídící aktivity spojené s provozem celého informačního systému a jeho jednotlivých komponent.
 Cíl – zajisti provoz jednotlivých aplikací a požadovanou úroveň konzultační a technické podpory.
 Vstupy – provozní dokumentace projektů.
 Výstupy – provozní dokumentace – deníky sítě, serverů, databází, hot-line, help-desk.
 Zodpovědnost – vedoucí provozu IT

Hlavní náplň:
 Plánování zařazování projektů do provozu
 Přebírání projektu do provozu
 Provoz Hot-line a Help-desk
 Řízení správy serverů, sítě a databází
 Správa koncových stanic sítě
 Výběr a nákup počítačového materiálu

Model řízení IS/IT

= vymezení funkcí a procesů řízení IS a zdrojů, kterými jsou tyto procesy realizovány.

Zdroje: personální, metodické, technické / softwarové a finanční


Funkce a procesy:
1. Rozvoj organizace a procedur řízení IS/IT
definování organizačních schémat a pravidel pro vývoj a provoz IS, a to v celkovém kontextu organizace – vazba na organizační strukturu podniku, reengineering a optimalizace struktur, popis jednotlivých funkčních míst atd.
2. Řízení ekonomiky IS/IT
finanční plánování v oblasti IS/IT, analýzy nákladů a efektů
3. Personální řízení IS/IT
plánování personálních kapacit a podmínek pro kvalifikační rozvoj jak pro informatiky tak pro uživatele
4. Formulace a zadávání projektů IS/IT
základní rámec projektů (řešených dodavatelsky i vlastními silami) – analýza požadavků na rozšíření a rozvoj IS/IT, vstupní analýzy před specifikací jednotlivých projektů, návaznost projektů, realizace výběrových řízení atd.
5. Řízení dodavatelsky řešených projektů
úvodní studie projektu, příprava organizace projektů, kontraktační řízení, implementace / customizace, příprava provozu a migrace, testovací procedury atd.
6. Řízení projekčních a analytických činností IS/IT
definice metodik / metod / nástrojů pro řešení projektů, analýza jejich využití a dodržování
7. Řízení datových zdrojů IS/IT
analýza a projektování interních i externích datových zdrojů – analýza stavu datových zdrojů, plánování rozvoje, analýza potřeb a možností externích datových zdrojů ad.
8. Řízení provozu IS/IT
monitorování provozu IS/IT, správa sítě, správa DB, řešení poruch a chyb, help-desk
9. Řízení rozvoje IT
realizace jednotného operačního prostředí (OS, DBMS, OIS), vazba na internet, výběr a instalace komponent IT ad.
10. Řízení systémových vlastností
analýza a realizace zabezpečení IS/IT, výkon IS/IT (doba odezvy), integrace aplikací a technologií, flexibilita IS/IT

vlastní realizace těchto funkcí a procesů záleží na tom, kdo plní úlohu systémové integrace (systémového integrátora)


1.3. Problémy a omezení
nepochopení informatiky a její možností
vazba informatiky a vlastního businessu
náročnost na zdroje (personální, finanční, časové, znalostní)
dynamika oboru – těžký výběr partnerů






1.4. Organizace a řízení projektu
Do procesu řešení IS/IT vstupují zpravidla tyto subjekty:
 Zákazník
o vedení podniku – navrhuje celkovou koncepci, rozhoduje o výběru dodavatele, rozhoduje o zásadních organizačních a ekonomických otázkách
o vedení informatiky podniku – navrhuje celkovou koncepci IS/IT, jeho celkovou architekturu, připravuje a organizuje výběrové řízení, řídí řešení IS/IT
o uživatelé podílející se na řešení – spolupracují na specifikaci požadavků, analýze, posuzování prototypových řešení
o pracovníci útvaru informatiky – spolupracují na analýze a návrhu řešení, částečně implementaci
 Dodavatel
o vedení firmy – řeší zásadní ekonomické a organizační otázky celé dodávky
o konzultanti / analytici – řeší celkovou koncepci projektu, analýzu a návrh systému, specifikují rozsah a charakter potřebných úprav ASW, podílejí se na customizaci
o implementátoři – zajišťují customizaci, prototypování, dokumentaci řešení
o systémový servis – specialisté na databáze, HW, OS
 Externí konzultanti
o formulace celkového konceptu IS/IT, organizace výběrového řízení na dodávku IS/IT, formulace zadání jednotlivých projektů

1.4.1. Organizace týmů při realizaci projektu ASW
 řídící výbor projektu
je složen z představitelů zákazníka a dodavatele. Řeší zásadní sporné otázky spojené s projektem, kontroluje plnění harmonogramu a rozpočtu, posuzuje celkovou úroveň řešení.
 vedení projektu
je hlavní výkonnou řídící složkou projektu. Zastoupen vedoucí projektu ze strany zákazníka i dodavatele. Řeší základní koncepční otázky projektu, stanovuje základní pravidla a standardy projektu.
 správa projektu
udržuje celkovou dokumentaci projektu, administrativní činnosti.
 jednotlivé projekční týmy
jsou tvořeny analytiky a konzultanty dodavatele a analytiky a klíčovými uživateli zákazníka. Řeší analýzu a nasazení jednotlivých aplikačních modulů, vazby na ostatní moduly, případně vazby na stávající ASW.

IT trh - strukturalizace, možnosti a problémy jeho analýzy

Druhy a oblasti standardů v IT. De jure standardy, de facto standardy, orgány pro tvorbu a dohled nad standardy, přínosy standardizace.



Trh IT je velmi nepřehledný, jeho struktura – mnoho různých přístupů – např. (toto dělení je neoficiální)
 HW
 Servery
 Periferie
 Síťové prvky
 PC
 komponenty
 software
 OS
 TASW
 Ostatní
 služby

Zdroje pro hodnocení – odborné časopisy – PCWorld, Computerworld; Specializované agentury IDG, IDC, konzultanti
Analýzy – žebříčky, hodnocení, srovnání – pro výběr partnerů, orientaci na progresivní technologie, nákupy aj.
Problémy – nepřehlednost trhu, špatně strukturované informace, neporovnatelná měřítka, potíže se získáváním informací.

1.1. Trh s IS/IT v ČR
Na trhu s IS/IT došlo za posledních 20 let k výraznému rozvoji. V ČR měl tento vývoj některé odlišnosti a to zejména do roku 1989a krátce po něm.

Do r. 1989
 Toto období charakterizovala snaha o vývoj informatiky v zemích RVHP nezávislý na zemích západního světa.
 Vyvíjené počítače i základní software kopírovaly vzory západních výrobců ( pro stroje JSEP byla vzorem řada počítačů IBM 370, pro SMEP řada PDP 11 firmy Digital).
 Kopírování omezovalo tvořivost vývojových pracovníků
 Vývoj zaostával za západem o cca 5 let
 Dovoz výpočetní techniky omezoval složitý byrokratický aparát – pro možnost dovést počítače ze západu bylo nutno projít složitým schvalovacím řízením. Omezení byly i na straně vývozců – vyvážet se směly pouze ty výrobky, které prošly schválením organizace COCOM, která posuzovala vývoz strategického zboží.
 Hlavními vývojovými organizacemi v ČR byly VÚMS, Kancelářské stroje, Datasystém, Orgaprojekt aj. Vyráběly se počítače EC1021, EC1027 (řady JSEP (IBM S/370), SM3, SM4 (řady SMEP (PSP 11)). Operační systémy DOS-4/JS, DOS-RV. Aplikační software DUORS, VARS, DARS.
 Každý větší podnik vlastnil výpočetní středisko s vývojovými pracovníky, techniky a systémovými programátory – tato skupina se starala o chod systému a snažila se vytěžit maximální výkon, projektanty a aplikačními programátory – ti řešily standardní problémy ekonomiky, bohužel byli nuceni technikou k nestandardním postupům. Koncem 80. let takto pracovalo cca 100 000 pracovníků.
 Zaměření vysokoškolského studia kopírovalo tehdejší stav techniky a vývoje.

Po roce 1989
 Ve velmi krátké době se ukázalo, že vývoj HW a ZSW není v naší ekonomice možný díky obrovskému náskoku zahraničí. Mnoho z podniků výpočetní techniky se v krátkém čase rozpadlo.
 Problematickým se ukázal i při vývoji ASW.
 Změny legislativy
 Změny hospodářského a konkurenčního prostředí
 Náskok zahraničních výrobců
 Nedostatek financí pro vývoj
 Došlo k radikální změně požadavků na pracovníky informatiky. Mnoho pracovníků vývoje přešlo na poskytování konzultačních služeb a na obchod s IS/IT. Na tuto změnu reagovaly VŠ zařazením ekonomických předmětů.

Současný stav trhu s IS/IT v ČR
Mezi předními poskytovateli služeb v ČR jsou společnosti IBM, PVT, Compaq, Hewlett-Packard, APP Group, Andersen Consulting, Unisys, SAP, Deloitte & Touche, Oracle a další.
Celkově se dá říci, že po propadu v roce 1997 došlo k mírnému oživení, které se nicméně netýkalo všech segmentů. Podle IDC patří trh IT v České republice mezi nejrozvinutější trhy ve střední a východní Evropě, a to zejména díky své progresivní struktuře výdajů, jež se zřetelně posouvají směrem k sítím (HW i SW) a především ke službám. V ČR činily v roce 1998 výdaje IT "na hlavu" 141 dolarů, což nás řadí na 2. místo v regionu (za Slovinsko). Hodnota trhu dosáhla 1, 456 miliardy dolarů, přičemž pro rok 1999 předpovídá IDC nárůst na 1,57 miliardy dolarů. Tahounem trhu se stal segment malých a středních firem, výdaje státní správy i velkých podniků stále stagnují.

PC, servery a počítačové systémy
Prodej PC vcelku věrně kopíroval trendy v celém IT -- zatímco dodávky do oblasti státní správy a velkých firem poklesly a poptávka ve školství stagnovala, podstatně vzrostl zájem o PC v segmentu malých a středních firem. Zajímavá je skladba prodejců PC: navzdory tlaku světových značek si většinu na trhu (53,8 %) stále drží lokální assembleři (AutoCont, ProCa, Comfor aj.). Růst svého podílu (41,6 % dodaných PC) si společnosti jako Dell, Compaq a Hewlett-Packard zajistily spíš na úkor dovážených neznačkových výrobků a méně známých domácích assemblerů. Přestože počet dodávaných kusů PC meziročně vzrostl o 4,3 %, z 233 200 v roce 1997 na 243 165 v roce 1998, jejich finanční hodnota klesla o téměř 10 %.

Servery a počítačové systémy jsou oblastí, která přece jen přinesla trochu optimismu -- meziroční nárůst ve výši téměř 15 % znamená v našich podmínkách téměř explozi. Nicméně i zde platí, že ve více než v 90 % jde o prodej těch levnějších variant (kategorie do 25 000 dolarů). Trh je u nás ovládán intelovskou platformou (téměř 90 %), mezi dodavateli vedla společnost Compaq.

Software
Operační systémy pro desktopy i přenosná zařízení jsou v ČR téměř plně (97 %) dílem společnosti Microsoft. To ovšem neplatí pro oblast integrovaných podnikových aplikací, kde si 57% podíl drží Unix. I podíl Windows NT stále roste, v roce 1998 je využilo 22,2 % ze všech licencovaných aplikací.

Opravdu dynamickým se jeví trh s podnikovými aplikacemi -- v roce 1998 dosáhl hodnoty 37,52 milionu dolarů, což znamená 19% meziroční nárůst. Zájem je o ně především mezi výrobními podniky, jež si drží, pokud jde o výdaje na ERP systémy, vedoucí postavení. Tato orientace napomohla společnosti SAP, která zůstává s 52,3 % vedoucí firmou na trhu.

Služby
O situaci na trhu služeb jsme již psali, takže jen shrnutí: podíl služeb na celkovém trhu IT stále stoupá, v roce 1998 dosáhl již 37 %. Jeho hodnota meziročně (97/98) vzrostla o 7,9 %, což odpovídá růstu z 502,62 milionu dolarů v roce 1997 na 542,56 milionu v roce 1998. Co do struktury služeb stále vede hardwarová podpora následovaná systémovou integrací. Vedoucí firmou na trhu byla společnost IBM.

Hardwarová podpora a instalace/20,8 %
Systémová integrace/18,3 %
Vývoj aplikací a údržba/17,6 %
Softwarová podpora a instalace/14,3 %
Síťové poradenství a integrace/9,5 %
IT poradenství/6,6 %
Ostatní/12,9 %
Celková hodnota trhu: 542,56 milionu dolarů