Tvorba a řízení změn architektury informačního systému

Rozměr: px
Začít zobrazení ze stránky:

Download "Tvorba a řízení změn architektury informačního systému"

Transkript

1 Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování Tvorba a řízení změn architektury informačního systému Diplomová práce Autor: Bc. Lubomír Bejšovec Informační technologie a management Vedoucí práce: Doc. Ing. Vlasta Svatá, CSc. Praha Duben,

2 Prohlášení: Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a s pouţitím uvedené literatury. V Praze dne XX. dubna 2010 Bc. Lubomír Bejšovec 2

3 Poděkování: Touto cestou bych rád poděkoval Doc. Ing. Vlastě Svaté, CSc. za odborné vedení při tvorbě této diplomové práce. Rovněţ bych rád poděkoval všem respondentům, kteří si našli čas a odpověděli na otázky mého dotazníku na téma nástroje pro návrh a řízení architektury informačního systému. 3

4 Anotace práce: Tato práce vzájemně porovnává současné teoretické postupy pro návrh, vytváření a řízení změn architektury informačního systému s praktickou zkušeností, jak jsou tyto postupy naplňovány v reálném prostředí. Snaţí se zachytit tyto procesy v průběhu celého ţivotního cyklu informačního systému. Od prvotní myšlenky nového informačního systému, aţ po jeho odstavení. Obsahuje přehled v současné době definovaných standardů pro oblast enterprise architektury. Cílem práce není prostý výčet detailů jednotlivých postupů, ale snaha o vnější pohled na to, jak jsou tyto postupy pouţívány a co přináší v reálném prostředí. Praktická část je vytvořena na základě výzkumu provedeného mezi manaţery informačních systémů, kteří mají jako jednu z hlavních pracovních povinností údrţbu a rozvoj těchto systémů. Současně je praktická část doplněna vlastními zkušenostmi. V závěru práce je provedeno shrnutí aktuálních moţností, jakým způsobem lze vyvíjet a udrţovat architekturu informačních systémů v dnešních podmínkách. Kde jsou kritická místa teorie při nasazení v praxi, a doporučení jakým způsobem je moţné taková rizika sníţit. The main goal of the graduation thesis Creation and Change Management of Information System Architecture is. Překlad doplnit po finalizaci celého textu. 4

5 Úvod Teoretická část Teoretické postupy pro vytváření architektury IS Pracovní rámce pro tvorbu architektury IS TOGAF Struktura pracovního rámce TOGAF TOGAF metoda ADM ZACHMAN Principy pracovního rámce ZACHMAN Schéma pracovního rámce ZACHMAN Teoretické postupy pro řízení změny architektury IS Řízení změny prostřednictvím pracovního rámce TOGAF Doporučení pro řízení změny enterprise architecture Obecné řízení změny Srovnání použití ITIL a TOGAF Praktická část Vlastní výzkum - zadání Vlastní výzkum - výsledky Víte, co to je enterprise architektura? Pokud ano, používáte ji nebo uvažujete o jejím nasazení? Pokud ji používáte, v jaké fázi implementace se nacházíte? Provádíte průběžné vyhodnocování architektury informačního systému? Jaké pracovní rámce a nástroje pro návrh, vývoj a provoz architektury informačních systémů znáte? Jaké pracovní rámce a nástroje pro návrh, vývoj a provoz architektury informačních systémů používáte? Pokud používáte pracovní rámce pro enterprise architecture, proč jste se rozhodli pro jejich nasazení? Pokud používáte pracovní rámce, jaké jsou jejich výhody/nevýhody?

6 Jaké zkušenosti máte se zaváděním architektury informačního systému? Co byste poradili těm, kteří plánují změnu architektury informačního systému? Vlastní výzkum - vyhodnocení Výstupy veřejně dostupných výzkumů Praktické zkušenosti s vytvářením architektury IS Praktické zkušenosti s prováděním změn architektury IS Závěr Seznam použité literatury Seznam obrázků Seznam tabulek Zadání diplomové práce

7 Úvod Pro návrh, budování a řízení změn v architektuře informačního systému není moţné vytvořit univerzální, stoprocentně platný postup pro kaţdý systém a všechna prostředí. To není reálně dosaţitelný cíl. Existující postupy jsou značně obecné a bez přímé vazby na konkrétní prostředí. Očekává se jejich přizpůsobení. Současně je nutné tyto postupy opakovaně a vytrvale zlepšovat. Doplňovat je o nové poznatky, odkrývat dosud nepopsané oblasti a zejména informovat o chybách a nedostatcích současných postupů. Věřím, ţe i tato práce napomůţe k částečnému posunu v této oblasti. Snaţím se o vzájemné porovnání vybraných teoretických postupů pro návrh, vytváření a řízení změn architektury informačního systému s praktickou zkušeností reálném prostředí. Pokouším se o zachycení těchto procesů v průběhu celého ţivotního cyklu informačního systému. Od prvotní myšlenky nového informačního systému, přes návrh, tvorbu, implementaci, provoz aţ po jeho odstavení. Teoretická část obsahuje základní charakteristiku a vymezení architektury informačních systémů a v současnosti pouţívaných pracovních rámců pro tuto oblast. Jsou zde definovány základní pojmy, způsob rozdělení pracovních rámců. Dva nejrozšířenější pracovní rámce jsou v této kapitole popsány podrobněji. V praktické části převáţně čerpám z vlastních zkušenosti získaných na realizovaných projektech v ČR i v zahraničí. Jedná se o projekty, jejichţ informační systém musí pracovat v reţimu 7x24 a zvládat obsluhu několika tisíc současně pracujících uţivatelů. Do největšího z nich je připojeno více neţ pracovních stanic a řídící část tohoto systému je rozprostřena do několika center po celém světě. Pro úspěšnou realizaci takovéhoto projektu je pochopitelně nutný kvalitně připravený návrh architektury a způsob provedení. Vlastní nasazení systému musí provádět dobře fungující pracovní tým s jasně nastavenými pracovními postupy. V kaţdém vícečlenném týmu zcela přirozeně dochází k rozchodu v názorech na některé pouţité postupy a řešení. Proto povaţuji za vhodné a uţitečné doplnit tuto práci o názory mých spolupracovníků a zákazníků, kteří se na těchto projektech podílí. Snaţím se (a alespoň v to upřímně doufám) o objektivní sepsání pohledu jak ze strany dodavatele, tak i z pohledu zákazníka. 7

8 1 Teoretická část Úvodem teoretické části bych rád vymezil některé pojmy a termíny pouţívané v další části textu tak, aby všichni čtenáři této práce měli sjednocenu terminologii a pro pouţité termíny měli pokud moţno shodnou představu. Jako první, nejdůleţitější a současně velmi rozlišně chápaný termín, povaţuji vysvětlení samotného spojení slov Informační systém. Co je to vlastně Informační systém? Při hledání odpovědi na takový typ otázky většina současné populace sedne ke svému počítači a pomocí webového prohlíţeče zadá dotaz na preferovaném webovém portálu. Pravděpodobně první nalezená odpověď bude z wikipedie. Tedy ze zdroje veřejně otevřené encyklopedie, kterou můţe kterýkoli čtenář/ka upravit. Osobně nemám tento zdroj informací příliš v oblibě. Velmi těţko se vyrovnávám s faktem, ţe informace nejsou stvrzeny globálně důvěryhodnou autoritou a poměrně často jsou nekomplexní a příliš obecné. Současně je však nutné uznat, ţe rozsah této encyklopedie rychle roste a kvalita informací se postupně zlepšuje. A zejména z pohledu masivního vyuţívání je potřeba wikipedii respektovat a povaţovat za oblíbený a rozšířený zdroj informací, který vyuţívá a proto ovlivňuje velké mnoţství populace. Na české verzi wikipedie se dozvídáme, ţe Informační systém je je systém pro sběr, udržování, zpracování a poskytování informací a dat. Příkladem informačního systému může být kartotéka, telefonní seznam, kniha došlé pošty nebo účetnictví. Systém nemusí být nutně automatizovaný pomocí počítačů a může být v papírové podobě 1. Pokud budeme hledat dále, dozvíme se, ţe informační systém můţe být složenou sítí všech komunikačních kanálů uvnitř organizace 2 nebo na počítačích založená část systému pro podporu podnikání 3 případně historicky definován jako most mezi uzavřeným světem informačních technologií a zbytkem organizace 4. Myslím, ţe na kaţdé z těchto definic je část pravdy. Avšak jeden velmi podstatný aspekt/dovětek mi zde schází. A sice, ţe by informační systém měl nebo ještě lépe musí vycházet z podnikové strategie. Podniková strategie je Koncept celkového chování organizace, dlouhodobý 1 Staţeno z 2 Staţeno z 3 Staţeno z 4 Staţeno z 8

9 program a pojetí činnosti organizace a alokace zdrojů potřebných k dosažení zamýšlených záměrů. 5 Tuto strategii musí respektovat a podporovat! Tento fakt je naznačen v definici normy ISO42010:2007, která jako systém označuje Soubor komponent účelově uspořádaných prodražení určitého cíle 6. Skloubením všech zmíněných zdrojů vzniká definice pouţívaná pro tuto práci: Informační systém, je systém pro sběr, udržování, zpracování a poskytování dat, informací a znalostí. Je realizován pomocí informačních a komunikačních technologií. Jeho neodmyslitelnou součástí jsou lidé, kteří s ním pracují. Vychází z podnikové strategie, kterou plně podporuje a rozvíjí. Aby informační systém skutečně efektivně a úspěšně podporoval a rozvíjel podnikovou strategii, musí mít odpovídající architekturu. Obecná definice architektury dle normy ISO42010:2007 zni: Architektura je fundamentální uspořádání systému, které tvoří komponenty a vztahy mezi nimi, včetně vztahu k prostředí, a principy, které řídí jeho návrh a rozvoj. 7 Pro potřeby této práce potřebuje definovat termín Architektura informačního systému. Vnímání tohoto termínu se mění a vyvíjí stejně rychle, jako přichází nové technologie. Historicky bylo toto spojení vnímáno výhradně jako technologická architektura, zahrnující pouze samostatný síťový počítačový systém. Často vnímané, jako něco zcela odtrţeného od dalších částí organizace. Postupně docházelo k rozšiřování o další komponenty (zejména telekomunikační). Následovalo přidání specializovaných aplikačních systémů a sluţeb. Dnes nejčastěji hovoříme o tzv. Enterprise Architecture. Velmi zjednodušeně řečeno jde architekturu informačního systému, od které se očekává přímá vazba a podpora obchodních cílů organizace. Při snaze o přesnější definici první problém nastává při překladu tohoto slovního spojení. Některé autority se pokouší zavést český termín znějící podniková architektura nebo architektura podnikání případně byznys architektura. Ţádný z těchto překladů však není dostatečně ustálen a navíc vzbuzuje představu, ţe se jedná o architekturu celé organizace. Tu tato architektura sice 5 Veber - Management 6 ISO/IEC 42010:2007 Systems and software engineering Recommended practice for architectural description of software-intensive systems 7 ISO/IEC 42010:2007 Systems and software engineering Recommended practice for architectural description of software-intensive systems 9

10 reflektuje, ale jedná se o architekturu informačního systému. V dalším textu budu pouţívat nepřeloţený výraz Enterprise Architecture pro označení aktuálního stadia architektury informačních systémů. Dle normy ISO/IEC 42010:2007 je Enterprise Architecture definována jako: přístup, koncept, prostředek a nástroj, kterým vyjadřujeme fundamentální uspořádání vztahu mezi byznysem a jeho informačním systémem, které vede k naplnění mise organizace, přičemž respektuje okolní prostředí a konzistentně dodržuje formulované principy návrhu a rozvoje systému. Cílem Enterprise Architecture je vytvořit, na bázi standardizovaného technického a programového vybavení, jednotné IT prostředí pracující v celé společnosti v souladu s globální strategií společnosti. Takový přístup znamená prosazení standardizace, opětovné vyuţití stávajících prostředků a sdílení společných postupů projektového řízení a vývoje informačního systému. Jedním z výstupů zavedení této architektury je vytvoření mapy všech částí informačního systému, obchodních procesů a řídících principů, které společně podporují a rozvíjí stanovenou obchodní strategii. Častou chybou je, ţe vytváření této mapy končí prostým popisem částí, jakou jsou servery, jejich umístnění, dílčí programy, způsob licencování apod., ale uţ nedojde k popisu procesů a jejich vazeb, natoţ nějaké vazby na strategické cíle organizace. Tím celá mapa de facto ztrácí svůj smysl. Existuje celá řada architektonických pracovních rámců specifikujících, co všechno má podniková architektura obsahovat. Některé jsou stručné, jiné obsáhlejší. Pracovní rámec pro návrh Enterprise Architecture, anglicky Framework je podle normy ISO 42010:2007 definován jako množina zájmů, zainteresovaných stran, předefinovaných hledisek a pravidel definujících vazby hledisek, které byly definovány pro popis architektury ve specifické oblasti. Tyto pracovní rámce lze rozdělit do třech kategorií. Na klasifikační, procesní, obsahové. Viz. Voříšek, Klasifikační pracovní rámce pomáhají rozloţit komplexní systém na jednotlivé pohledy, specifikovat aspekty těchto pohledů a radí jaké modely pouţít. Zpravidla jsou realizovány jako matice, kde jsou pohledy vepsány do řádků a sloupce uvádí aspekty, které je v daném pohledu vhodné řešit. Typickým představitelem klasifikačního rámce je ZACHMAN. Další kategorií jsou procesní pracovní rámce, které definují doporučené pracovní postupy během řízení Enterprise Architecture v celém období jejího ţivotního cyklu. Zástupcem tohoto typu je TOGAF. Poslední kategorií jsou obsahové rámce, které jsou úzce navázány na konkrétní odvětví. Např. v oblasti 10

11 bankovnictví, pojišťovnictví nebo státní správy. Pro danou oblast rozšiřují/specifikují obsah rámců klasifikační a procesní. Principiálně lze u většiny pracovních rámců nalézt rozdělení Enterprise Architecture na následující čtyři části: Business architecture / Byznys architektura v hlavních rysech specifikuje nejdůleţitější obchodní procesy, sluţby jejich vazby v organizaci; je to klíčová a současně na specifikaci nejnáročnější část v podnikové architektuře. Information architecture / Informační-datová architektura identifikuje, kde a v jaké formě jsou uloţena data organizace a jakým způsobem je prováděno jejich zpracování, tak aby z nich vznikly informace mající hodnotu pro organizaci. Rovněţ je zde popsán způsob přístupu k nim a jejich zabezpečení. Application system architecture / Architektura aplikačních systémů obsahuje mapu vazeb, vstupů a výstupů mezi jednotlivými aplikacemi, aplikačními systémy a sluţbami. Infrastructure architecture / Architektura infrastruktury podrobný plán/mapu technologické infrastruktury zahrnující například fyzické prvky (počítače, disková pole, zálohovací knihovny) nebo síťové-komunikační prvky (přepínače, síťová rozhraní, firewall). Pro spolehlivé a efektivní fungování informačního systému je důleţité, aby byly vytvořeny, rozvíjeny a aktivně pouţívány všechny tyto části Enterprise Architecture. Důleţitým faktorem, který můţe zcela paralyzovat tuto architekturu je situace, kdy v organizaci není kvalitně formulovaná a komunikovaná podniková strategie. Pak není moţné kvalifikovaně sestavit Enterprise Architecture. Další problematická situace nastává v případě, kdy se zodpovědní pracovníci soustředí pouze na stránku vlastní informační technologie bez vazby na podnikovou strategii. Právě ignorace obchodní architektury způsobuje v reálném prostředí velké problémy. Čím je organizace rozsáhlejší a působí na větším trhu pod vlivem globálních trendů, tím více se tyto problémy zviditelňují a hůře napravují. Prostředí se de facto nedá efektivně udrţovat a kaţdá potřeba změny můţe způsobit kolaps informačního systému, který se v končeném důsledku projeví finanční ztrátou organizace. 11

12 Pro vývoj/nasazení enterprise architektury v organizaci jsou vyuţívány průmyslové mechanismy, mezi které řadíme architektonické principy, průmyslové standardy pro oblast IT, pracovní rámce a modely, vývojové nástroje. Jen velmi zřídka existuje moţnost vybudovat nový informační systém takříkajíc na zelené louce. Zpravidla je vývoj nové architektury připravován pod vlivem současného stavu. To můţe vyústit v situaci, kdy vývoj nové architektury je prováděn pracovníky úzce spjatými se současným řešením. Ti se velmi často nedokáţou oprostit od zaběhnutých způsobů. Omezení vývoje nové infrastruktury mohou být také vyvolána vnějšími vlivy. Jedná se o legislativní poţadavky, závazky nebo investované prostředky z minulosti, geografické vlivy apod. V kaţdém případě je nutné tuto skutečnost vzít v úvahu a existují-li omezení dané současným stavem je nezbytné je v novém návrhu zapracovat. Ať uţ přizpůsobením moţnostem stávající technologie nebo zapracováním komplexní náhrady pouţívané technologie. Pokusíme-li se vytvořit jednoduchý model enterprise architektury zahrnující základní vstupy a výstupy vznikne následující obrázek. 12

13 Obrázek 1 - Model enterprise architektury a základní vstupy a výstupy 8 text přeložte do češtiny Za podstatné a zdůraznění vhodné (klíčové) jsou zde dvě následující skutečnosti. Vstupem do architektury jsou poţadavky definované obchodními (strategickými) potřebami organizace a výstupem jsou poţadavky na vývoj, které se následně promítají aţ na úroveň operativního řízení. Převedeme-li základní model enterprise architecture (obsahující všechny čtyři její části) do vrstev, tak abychom viděli, co jsou logické zdroje a co skutečná fyzická vrstva, dostaneme níţe zobrazené schéma. Manaţerské řízení společně s operativními činnostmi, znázorněné vlevo se promítá do vrstvy logických zdrojů i fyzické vrstvy. 8 Zdroj 1.7 str 18 PDF 36 13

14 Obrázek 2 - Model enterprise architektury ve vrstvách 9 totéž Pro zpracování a tvorbu kaţdé vrstvy se pouţívají rozdílné nástroje. Skupiny těchto nástrojů společně s vazbou na architektonické principy (standardy) jsou na následujícím obrázku. 9 Zdroj 1.7 str 18 PDF 36 14

15 Obrázek 3 - Klíčové komponenty enterprise architektury 10 totéž Při budování enterprise architektury je důležité dodržet určitá základní pravidla. Mezi ně patří: Mít jasnou představu, co to je enterprise architektura. Je důleţité pozorně se seznámit s její charakteristikou, zejména s jejími vstupy a výstupy, tak aby došlo k plynulému provázání se strategickými cíly organizace. Vědět z jakých částí je enterprise architektura složena. Podstatné je znát způsob rozdělení Enterprise architektury, vědět čím se jednotlivé sub-architektury liší, co obsahují a při budování nového systému dodrţet tuto koncepci Znalost částí EA, které jsou aktuálně používaných organizaci Má-li jiţ organizace stávající systém, který byl budován podle jiných postupů, je potřeba zanalyzovat, které pouţívané komponenty je moţné vyuţít a to zejména s ohledem na jiţ vynaloţené prostředky. Použít vhodný architektonický pracovní rámec. (framework) To je pochopitelně velmi nelehký úkol, který má však zásadní vliv na 10 Zdroj 1.7 str 18 PDF 36 15

16 budoucí pruţnost při vývoji a změnách architektury. Moţná doporučení pro způsob volby naznačuje provedený výzkum, který je uveden v dalším textu. Definovat postupné kroky Zavedení nové architektury je komplexní úkol v řádu týdnů nebo měsíců v závislosti na velikosti organizace a sloţitosti systému. Zavádění je nutné rozloţit do časově kratších a méně rozsáhlých navazujících částí. Používání modelovacích nástrojů. Je prakticky nemoţné vytvořit a spravovat pohledy společně s vazbami pro jednotlivé části enterprise architektury. V dnešní době je pouţívání vizualizačních modelovacích nástrojů samozřejmostí. Znalost a dodržování technologických standardů. Při definování Enterprise Architecture je výhodné v maximální moţné míře vyuţít existující standardy a doporučení. Zabráníme tím opakování jiţ zjištěných chyb, ušetříme čas, zjednodušíme nasazení a máme lepší srovnání při následném vyhodnocení naši architektury. Najmutí a využití správných lidí. Volba a motivace lidí v realizačním týmu je dlouhodobě jedním z klíčových faktorů úspěšné implementace. Je nutný, aby realizační tým disponoval jak odbornými znalostmi, tak schopností domluvit se navzájem. Vysvětlit problematiku nové architektury managementu a zajistit si jeho podporu Další z klíčových faktorů, na kterém uţ ztroskotal nejeden projekt. Skutečnost, ţe bez aktivní komunikace s managementem, důsledné a přesvědčivé argumentaci není moţno dosáhnout stanoveného cíle, je všeobecně známá. Přesto se tento fakt neustále podněcuje a opakují se stejné chyby. Ideální je, pokud je člen managementu zároveň členem realizačního týmu a je za řádné dokončení odpovědný. Naopak vyvarovat bychom se měli: Vývoji a používání ryze vlastních pracovních rámců a postupů. Interní vývoj je zpravidla nákladný, zdlouhavý a neefektivní; lepší variantou 16

17 je přizpůsobení některého z rozšířených pracovních rámců, který má prostor pro vnitropodnikovou specifikaci. Např. TOGAF) Používání vlastních dočasných řešení (ignorace standardů). Poměrně častým problémem je nasazení řešení, o kterém se říká, ţe je pouze dočasné, přechodové apod. Tato dočasnost se současně pouţije jako argument pro omluvu faktu, ţe toto řešení není dostatečně zdokumentováno. Čím déle se pouţívá, tím hůře se nahrazuje transparentním a řádně zdokumentovaným řešení. To, co se na začátku jeví jako jasná úspora, se pak v průběhu svého ţivotního cyklu opakovaně prodraţuje. Práce bez jasné představy cílového stavu. Začínat jakoukoliv práci bez definovaného cíle je uţ na první pohled nevhodné a neprofesionální. Přesto se takové situace neustále opakují. Zpravidla jsou uvozeny tvrzením typu Musíme začít co nejdříve, pak uţ to přizpůsobíme. V absolutní většině případů je výsledné řešení takovéto aktivity nefunkční a vţdy ztrátové. Vývoje bez zadání z businessu. Obdobnou chybou je pokud se sice specifikuje technicky jasné a přesné zadání, ale opomene se projednat jeho vazba na celkovou strategii společnosti. Výsledkem je pak můţe být stav, kdy sice máme technologicky dokonalé prostředí, ale dělá to, co nikdo nepotřebuje; případně jeho vývoj a implementace je draţší neţ cena řešení, které by bylo pro organizaci dostačující. Používání výhradně levných řešení. Při nasazování nového řešení je důleţité posoudit cenu vynakládaných prostředků v celém průběhu ţivotního cyklu. Častou chybou je volba řešení, které mé velmi nízkou pořizovací cenu, ale náklady na jeho provoz a rozvoj výrazně převyšují cenu ostatních řešení. Angažování současných pracovníků, kteří nejeví zájem o změnu. Špatná volba pracovníků realizačního týmu můţe ohrozit úspěšnost řešení. Typickou chybou je angaţování pracovníků úzce spjatých se stávajícím řešením, kteří nejsou schopni myšlenkově připustit nový pohled na řešenou 17

18 problematiku. Při budování enterprise architektury je rovněţ nutné vymezit oblast, pro kterou je enterprise architektura budována. Ideální a nejvýhodnější je, pokud dochází k tvorbě nové enterprise architektury společně pro celou organizaci. V reálném světě však velmi často takto ideální situace není. Naráţíme na různé omezující podmínky. Například finanční (není dost zdrojů na pokrytí rozsáhlé celkové změny), geografické (části společnosti jsou příliš daleko od sebe pro vybudování centrálních systému), politické (část vedení organizace nebo dostatečný počet akcionářů blokuje přijmutí a provedení zásadní a potřebné změny). Obtíţné je také vyčíslení nákladů v počátečních fázích projektu a prokázání přínosu nového řešení. Právě finanční faktory pak hrají důleţitou úlohu při získávání podpory ze strany vedení společnosti. To vše mohou být překáţky, se kterými je nutné se vypořádat. Faktory uvedené v předchozím odstavci, pak mají význam pro sestavení odpovídajícího realizačního týmu a zejména stanovení rozsahu vytvářené Enterprise Architektury. Je přípustné, aby se stanovil rozsah vytváření architektury uţší, neţ je celá organizace. V takovém případě je oblast enterprise vymezena jako libovolná organizace spojená jasnými cíli, pro které má smysl takovou architekturu budovat. Termín Enterprise Architecture se stal tak široce rozšířeným, ţe jeho standardizací se začalo zabývat několik autorit. Nejvýznamnější z nich jsou uvedeny v následující tabulce: (ANSI) American National Standards Institute (CEN) European Committee for Standardization (IEEE) Institute of Electrical and Electronics Engineers (ISO) International Organization for Standardization (NIST) National Institute of Standards and Technology Tabulka 1 - Autority zabývající se standardizací Výstupem výše uvedených institucí je jiţ celá řada norem, např.: CEN ENV Enterprise Model Execution and Integration Services 18

19 CEN-ISO DIS Framework for Enterprise Modeling CEN-ISO WD Constructs for Enterprise Modeling ISO Concepts and rules for enterprise models ISO Requirements for enterprise-reference architectures and methodologies ISO Open systems application integration frameworks ISO Systems and software engineering Recommended practice for architectural description of software-intensive systems Tabulka 2 Normy vztahující se k enterprise architektuře Důleţitost definování standardů a norem je neoddiskutovatelná. Tyto dokumenty významně pomáhají sjednotit terminologii. Rovněţ jsou nezbytným předpokladem pro přijetí a následné rozšíření v reálném komerčním prostředí. Často se stávají i podmínkou v rámci výběrového řízení na dodávku IT sluţeb. Poslední termín této teoretické kapitoly, je ţivotní cyklus informačního systému. Ţivotní cyklus informačního systému začíná v momentě prvotního nápadu/myšlenky o novém informačním systému. Aţ do své poslední fáze, kterou je jeho odstavení, jsou cyklicky opakovány čtyři fáze zajišťující jeho stálé zlepšování. Jedná se tyto fáze: Plánuj (Plan) dochází k získávání vstupních informací, vyhodnocení a sestavení přípravného plánu. Dělej (Do) jsou provedeny činnosti definované v předchozím bodu. Kontroluj (Check) běţící systém je průběţně monitorován a dochází ke kontrole s definovanými parametry provozu. Konej (Act) bylo-li zjištěno, ţe systém nepracuje dle stanovených kritérii nebo vznikly nové poţadavky, je třeba vyvolat opakování tohoto čtyřfázového cyklu. 19

20 Obrázek 4 - Fáze životního cyklu IS Architektura informačního systému musí být navrţena tak, aby v kaţdé části jeho ţivotního cyklu poskytovala potřebnou moţnost změny. 1.1 Teoretické postupy pro vytváření architektury IS Po teoretickém vymezení v předchozí kapitole se v této části zmiňuji o moţnostech jak dosáhnout poţadovaného stavu architektury informačního systému, jaký konkrétní typ nástrojů pouţít pro definování odpovídajících vrstev této infrastruktury Pracovní rámce pro tvorbu architektury IS Snaha o zpřehlednění a sjednocení při návrhu a tvorbě architektury informačních systému vedla ke vzniku několika více či méně uznávaných a rozšířených pracovních rámců (v anglické literatuře se pouţívá termín framework ; viz. Definice pojmů v předcházející kapitole), které standardizují tento komplexní proces. Následující tabulka uvádí částečný přehled pracovních rámců: 1. Zachman Enterprise Architecture Framework (ZIFA) 2. The Open Group Architecture Framework (TOGAF) 3. Extended Enterprise Architecture Framework (E2AF) 4. Enterprise Architecture Planning (EAP) 5. Federal Enterprise Architecture Framework (FEAF) 20

21 6. Treasury Enterprise Architecture Framework (TEAF) 7. Integrated Architecture Framework (IAF) 8. Joint Technical Architecture (JTA) 9. Command, Control, Communications, Computers, Intelligence, (C4ISR) Surveillance, and Reconnaissance and DoD Architecture Framework (DoDAF) 10. Department of Defense Technical Reference Model (DoD TRM) 11. Technical Architecture Framework for Information Management (TAFIM) 12. Computer Integrated Manufacturing Open System Architecture (CIMOSA) 13. Purdue Enterprise Reference Architecture (PERA) 14. Standards and Architecture for egovernment Applications (SAGA) 15. European Union IDABC & European Interoperability Framework 16. ISO/IEC (IEEE Std ) 17. IEEE Std IEEE Recommended Practice for Architectural Description Tabulka 3 - částečný přehled pracovních rámců (framework) pro architekturu IS 11. V následujících dvou kapitolách se podrobněji věnuji nejčastěji zmiňovaným a nejvíce rozšířeným zástupcům pracovních rámců z výše uvedené tabulky. Jedná se o TOGAF a ZACHMAN. TOGAF je zástupcem procesního pracovního rámce a je volně šiřitelný (při dodrţení určitých pravidel) a ZACHMAN, který je zástupcem klasifikačního rámce a jedná se o komerční produkt TOGAF Název TOGAF vznikl jako akronym ze slov The Open Group Architecture Framework. Jedná se o všeobecně uznávaný pracovní rámec (detailně rozpracovaná metoda včetně sady podpůrných nástrojů, zahrnující doporučení a standardy), který je vyuţíván pro řízení návrhu architektury informačního systému ve společnosti. Tento pracovní rámec je volně dostupný a můţe být vyuţíván libovolnou organizací, pokud je pouţit pro interní implementaci 12. Jeho cílem je definování dlouhodobého strategického řízení. TOGAF se věnuje skutečné enterprise architektuře, tak jak jsme ji definovali v úvodu teoretické části této práce. Přitom umoţňuje kaţdé organizaci, která se rozhodne pouţít tento rámec, přizpůsobení jejím individuálním specifikám a poţadavkům. Klade 11 Zdroj str 12 PDF Detailní podmínky na 21

22 velký důraz na vzájemné propojení strategických obchodních cílů organizace s jejím IT prostředím. TOGAF je velmi dobře přizpůsobivý, umoţňuje spolupráci s jiţ vytvořenými strukturami v organizaci, jakoţ i vyuţití stávajících prostředků projektového řízení. Navíc jsou pro některé modelovací nástroje pro enterprise architekturu vytvářeny certifikace vyuţití právě s pracovním rámcem TOGAF. TOGAF je v současnosti vyvíjen členy seskupení The Open Group pracujícími v rámci Architecture Forum 13. Historie TOGAF začala v roce 1995, kdy byla vypracována první verze ministerstvem obrany USA. V roce 2009 byla zveřejněna, zatím poslední, verze Struktura pracovního rámce TOGAF Struktura dokumentace TOGAF v. 9 je rozdělena do sedmi částí. Následující obrázek zachycuje jejich vzájemnou vazbu. 13 Více na 14 Více na nebo 22

23 Obrázek 5 - Struktura dokumentace TOGAF 9 15 Část I Introduction přehledově popisuje klíčové koncepty enterprise architektury a její konkrétní navázání v rámci TOGAF. Obsahuje definice pouţívaných termínů, seznam rozdílů oproti předchozím verzím TOGAF. Část II ADM (Architecture Development Method) - je klíčovou částí TOGAF. Popisuje metodu pro vývoj enterprise architektury označovanou jako ADM. Detailně stylem krok za krokem popisuje, jak přistupovat k vývoji enterprise architektury. Část III ADM Guidelines and Techniques obsahuje sadu doporučení, vodítek a technik pro pouţití TOGAF a metody ADM. Část IV Architecture Content Framework popisuje náplň vlastního pracovního rámce TOGAF včetně strukturovaného meta modelu pro architektonické artefakty, 15 Zdroj 1.7 str 18 PDF 36 23

24 opakované pouţití jiţ vytvořených architektonických celků a přehled typických výsledků enterprise architektury. Část V Enterprise Continuum & Tools tato část pojednává o vhodných nástrojích a systematičnosti pro rozčlenění a uloţení výstupů z činností v rámci organizace. Část VI TOGAF Reference Models poskytuje výběr odkazů na architektonické modely včetně modelu vytvořeného v rámci TOGAF a modelu III-RM (Integrated Information Infrastructure Reference Model). Část VII Architecture Capability Framework tato část prochází organizaci, její procesy, dovednosti, role a odpovědnosti potřebné pro nastavení a fungování funkční architektury v organizaci. 24

25 TOGAF metoda ADM Jak jiţ bylo zmíněno v předchozím textu, klíčovou částí je ADM (Architecture Development Method). Tato část si bezesporu zasluhuje samostatný a hlubší rozbor. Metoda ADM obsahuje mimo ryze technické tvorby enterprise architektury i důleţité prvky a části. Jedná se např. o přípravu projektu, plánování, vývoj a kontrolu implementace nebo řízení změn architektury v dlouhodobém horizontu při zachování její integrity. Zásadním pohledem této metody je systematické, pozvolné a nenásilné směřování změny současného stavu architektury do stavu v budoucnosti označovaného za stav racionalizovaný. Jednotlivé fáze metody ADM jsou zobrazeny na následujícím obrázku. Obrázek 6 fáze metody TOGAF ADM Zdroj 1.7 str 18 PDF 36 25

26 Nyní si jednotlivé fáze probereme detailněji. Přípravná fáze (preliminary) V této fázi dochází k popsání a zahájení přípravných činností pro vytvoření architektury tak, aby plnila definovanou strategii organizace. Cílem je přezkoumání všech souvislostí, které na ni mohou mít vliv. Zajištění sponzora z vedení organizace, definování členů týmu, stanovení jejich povinností a zodpovědnosti. Současně jsou přijata opatření, která připraví vhodné podmínky celému týmu. Je přijat rámcový postup, přičemţ se očekává vyuţití metody GOGAF ADM. Jsou vybrány nástroje, které budou vyuţívány. Jednou větou tato fáze vymezuje Kdo, Co, Kde, Proč a Jak bude vytvářet Enterprise Architecture). Fáze A Vize architektury (Architecture Vision) - v této části dochází k přesnému vymezení působnosti všech zainteresovaných stran. Definuje se vývojový cyklus, klíčové poţadavky řešení, případná omezení, dochází k formalizaci plánu vývoje. Dochází k vytvoření komplexního projektového plánu dle pouţívané projektové metodiky. Po zformulování vize architektury je potřeba zajistit schválení navrţeného postupu. Fáze B Byznys architektura (Business Architecture) základním předpokladem pro řízení této vrstvy Enterprise architektury je znalost a popsání aktuálního stavu. Následně je stanoven a namodelován cílový stav. Na základě zjištěných rozdílů mezi cílovým a současným stavem se definuje plán pro dosaţení cílového stavu. Fáze C Architektura IS (IS Architecture) tato část se skládá ze dvou kroků. V prvním z nich jsou specifikovány hlavní zdroje a typy údajů. Vytváří se tzv. datová architektura. Smysl této činnosti je definici datových entit, které mají být kompletní, srozumitelné, konzistentní a hlavně stálé. Je nutné zdůraznit, ţe se nejedná o návrh databáze, logické ani fyzické úrovně. Druhým krokem je určení aplikačních systémů, které budou spravovat dat definovaná v předchozím kroku. Jedná se stanovení logiky věci, niko-li o výběr a určení konkrétní technologie. Stanovená aplikační logika je stabilní a v průběhu času relativně neměnná. Zatímco technologie pouţitá pro realizaci se můţe v průběhu času měnit (např. nová verze databázového serveru). Fáze D Technologická architektura (Technology Architecture) v rámci této fáze dochází k mapování aplikační architektury na konkrétní technologické (hardwarové 26

27 a softwarové) komponenty, kterými organizace jiţ disponuje, nebo jsou pro ni dostupné. Tím dochází k definici fyzické vrstvy, coţ má značný vliv na obsah a průběh konkrétního realizačního projektu. Fáze E Příleţitosti a řešení (Opportunities and Solutions) popisuje způsob/proces identifikace prostředků potřebných pro vlastní realizace Enterprise Architecture. Je to první fáze, která se zabývá otázkou, jaké konkrétní kroky a opatření budou provedeny během realizace. Jednotlivé kroky mohou být seskupeny do odpovídajících skupin v rámci hlavního nebo dílčích projektů. Toto dělení je závislé na velikosti prostředí, rozsahu a mnoţství jednotlivých kroků. Fáze F Plánování migrace (Migration Planning) tato fáze se zabývá vlastní přípravou implementace a migračního plánu na základě výstupu předcházející fáze. Cíl je dokončit prováděcí a migrační plán. Jeho součástí je zajištění koordinace jednotlivých aktivit v rámci organizace, přiřazení priority a potvrzení/schválení vazeb definovaných v předchozích fázích. Fáze G Zavedení dohledu (Implementation Governance) tato část se zabývá zavedením architektonického dohledu nad implementací. Dochází k formulaci doporučení pro jednotlivé projektové fáze, zajišťuje se, ţe tento projekt je ve shodě s ostatními probíhajícími i plánovanými projekty v rámci organizace. Je-li potřeba, jsou přijata opatření pro zajištění bezproblémového průběhu projektu. Fáze H Řízení změny architektury (Architecture Change Management) obsahem této kapitoly je stanovení postupů pro řízení změn nové architektury. Základním smyslem je zajistit, aby byly podporovány strategické cíle organizace a současně byl základ architektury otevřený pro změny, které mohou v budoucnosti nastat. Detailněji je tato fáze rozepsána v kapitole 0 Správa poţadavků (Requirements Management) jako je z výše uvedeného obrázku patrné, tato část uvnitř celé ADM a zaměřuje se na proces řízení poţadavků mezi jednotlivými fázemi ADM. Způsob identifikace, označovaní, zpracování a uloţení mezi příslušnými ADM fázemi je dynamický proces. Jde o to, aby jednotlivé poţadavky navzájem neohroţovaly průběh v rámci kaţdé fáze ani proces zavádění a řízení celé architektury. 27

28 1.1.3 ZACHMAN Druhým pracovním rámcem zmíněným v této práci je Zachman Framework for Enterprise Architecture. Jedná se o velmi rozšířený (podle některých statistik dokonce vůbec nejrozšířenější) pracovní rámec pro návrh, vývoj nebo zdokumentování enterprise architektury. ZACHMAN má jasnou a logickou strukturu pro klasifikaci a zorganizování těch částí organizace, které mají zásadní vliv na pouţívaný informační systém v organizaci. Struktura je rozdělena na dvě základní osy. Horizontální a vertikální, kaţdá z nich je v základní verzi rozdělena na šest dílů, tak jak jsou zobrazeny na následujícím obrázku. Obrázek 7 - Základní schéma pracovního rámce ZACHMAN Vertikální osa zobrazuje náhled na celkovou strukturu organizace. Horizontální klasifikuje různé artefakty architektury. Podobně jako u většiny pracovních rámců i ZACHMAN se snaţí poskytnout náhled na základy architektury informačního systému, jehoţ úkolem je podpora organizace, integrace, vývoje a řízení v dané organizaci. První verzi tohoto pracovního rámce publikoval v roce 1987 John Zachman. Autor vycházel z tradičních postupů a architektury v době vzniku. V následujících letech původní 28

29 verzi postupně doplňoval o nové podněty. Zásadní změna přišla v roce 1992, kdy John F. Sowa a John Zachman představili nový pohled/koncept, který dal tomuto rámci charakteristický tvar. V současné době je tento pracovní rámec vyvíjen, rozpracováván a publikován prostřednictvím ZIFA - Zachman Institute for Architecture Advancement. (Proto se v některé literatuře označuje jako ZIFA). Do aktuální verze je moţné zahrnout globální popis enterprise architektury, její technické detaily, logicky přehledné obrázky stejně dobře jako systémovou specifikaci celkové architektury i dílčích částí. Zkrátka jedná se o komplexní nástroj, jehoţ nasazení je intuitivní a řada vývojových nástrojů ho zná, rozumí mu a dokáţe tento pracovní rámec podporovat Principy pracovního rámce ZACHMAN Mezi základní principy současné verze patří: Kompletní systém lze modelovat po nalezení odpovědi na otázky: Proč?, Kdo?, Co?, Jak?, Kde?, Kdy? Šest pohledů/hledisek zachycuje všechny důleţité modely pro vývoj systému Sloupce prezentují různou míru abstrakce ve snaze sníţit komplikovanost, tak jak by tomu bylo v případě jediného modelu Pořadí sloupců není důleţité, je moţné ho přeházet Model v kaţdém sloupci musí být jedinečný Kaţdý řádek prezentuje unikátní náhled Kaţdá buňka je specifická Základní logika je opakovatelná 29

30 Schéma pracovního rámce ZACHMAN Důleţitou charakteristikou tohoto modelu je skutečnost, ţe se nesnaţí o definování jednotlivých kroků ani neříká, v jakém pořadí mají výt uskutečňovány. Specifické pojetí tohoto pracovního rámce spočívá v tom, ţe kaţdá buňka tabulky reprezentuje určitý pohled, pro který určuje téma, roli a její zodpovědnost. Konkrétní pohled dostaneme zkříţením sloupců a řádků tabulky. Vertikální dimenze představuje oprávnění a horizontální představuje přiřazení odpovědností. Proto je důleţité vědět co jednotlivé řádky a sloupce reprezentují. Obrázek 8 - detailní schéma pracovního rámce ZACHMAN Definice řádků: Rozsah (Scope) definuje roli Projektant (Planner); představuje hlavní cíle, záměry vztaţené k organizaci, reflektuje, proč byla organizace zaloţena, čeho se snaţí dosáhnout 30

31 Byznys model (Business Model) definuje roli Vlastník (Owner); zobrazuje nejdůleţitější obchodní procesy, sluţby a jejich vzájemné propojení v organizaci Systémový model (System Model) definuje roli Systémový Architekt (Designer); jsou zde určovány datové prvky, systémové funkce, které reprezentující výstupy byznys modelu Technologický model (Technology Model) definuje roli Tvůrce (Builder); určuje, které technologie jsou pouţitelné pro realizaci systémového modelu Komponenty (Detailed Representations) definuje roli Sub-dodavatel (Subcontractor); reprezentuje jednotlivé nezávislé moduly, které mohou být pouţity v rámci implementace Reálný funkční systém (Functioning Enterprise) popisuje stav, kdy systém je implementován Definice sloupců: Kdo (Who) reprezentuje lidské zdroje v rámci organizace Kdy (When) představuje čas a vztahy mezi jednotlivými událostmi, čímţ odkrývá případná limitní omezení. To vše je nutné pro reálné sestavení projektového harmonogramu Proč (Why) popisuje motivaci organizace, proč mají být stanovené cíle splněny, jaký je podnikatelský plán, znalost a návrh architektury Co (What) popisuje entity obsaţené v jednotlivých pohledech. Například systémové objekty, tabulky v databázi nebo definici polí. Jak (How) zobrazuje funkci v rámci kaţdého pohledu. Například obchodní procesy, aplikační funkce, hardwarové funkce apod. Kde (Where) zobrazuje umístnění a propojení/vazbu v rámci organizace. Například geografické umístnění 31

32 1.2 Teoretické postupy pro řízení změny architektury IS Kaţdá organizace prochází v průběhu času určitými změnami. Těmto změnám se nutně musí přizpůsobit, jinak hrozí, ţe dojde k utlumení její činnosti a v krajním případě k jejímu krachu. Musí zareagovat a provést adekvátní změny, aby mohla pokračovat dál a rozvíjet své obchodní aktivity. Je to obecně platný jev, který se v konečném důsledku nevyhýbá ani architektuře informačních systémů. Přináší však řadu specifických otázek, na které je nutné nalézt odpověď. Mezi takové otázky patří: jak rychle dokáţe organizace na nový podnět reagovat jaký je rozsah změn, které musí být zapracovány je současná architekturu ve stavu, který je vůbec moţné změnit jak rychle lze připravit novou enterprise architekturu je moţné implementovat novou enterprise architekturu plynule / bez výpadků jaké budou celkové náklady této implementace jak dlouho bude celý proces zavedení trvat je organizace schopná provést změnu v rámci interních zdrojů To jak uspokojivé odpovědi na uvedené otázky je organizace jako celek schopna nalézt, do značné míry záleţí na zavedeném způsobu řízení architektury v rámci organizace. Ideální je pokud organizace vyuţívá pracovní rámec, který řízení takové změny přímo podporuje. V případě, ţe byl tento rámce vyuţit i pro nasazení aktuální enterprise architektury, pak je velmi pravděpodobné, ţe provedení potřebné změny bude koordinované, efektivní a hlavně funkční. Příkladem takového pracovního rámce je TOGAF, konkrétně fáze H metody ADM, která se přímo řízením změny enterprise architektury zabývá. Tato fáze je rozebrána v kapitole Existuje však nemalé procento organizací, které nepouţívají, ţádný nástroj, který by tuto změnu byl schopen podpořit. I v této situaci není vše ztraceno. K dispozici jsou obecné postupy, které je moţno uplatnit ad-hoc. Taková situace je nastíněna v kapitole 0. 32

33 1.2.1 Řízení změny prostřednictvím pracovního rámce TOGAF Tato kapitola detailněji rozebírá fázi Řízení změny architektury (Architecture Change Management). Pro tuto fázi je charakteristické, ţe se snaţí o nastavení takového způsobu fungování enterprise architecture, které zajistí moţnost provedení změn v rámci této architektury. Postupy definované v této fázi jsou vyuţívány, jak při počáteční tvorbě nové enterprise architecture, tak v průběhu jejího ţivotního cyklu. Obrázek 9 - Vazba fáze H na ostatní fáze metody TOGAF ADM Očekávaným cílem této fáze je: Ve fázi budování nové architektury zajistit, aby základ enterprise architektury byl schopen přijmout budoucí změny Zajistit, aby bylo moţné sledovat výkonnost enterprise architecture v průběhu celého ţivotního cyklu Na základě sledování výkonnosti má být moţno navrhovat opatření vedoucí ke zlepšení tohoto výkonu Zajistit, aby provádění změn korespondovalo s ostatními fázemi pouţívání pracovního rámce TOGAF Maximalizace strategických cílů organizace 33

34 Doporučení pro řízení změny enterprise architecture Jak jiţ bylo několikrát zmíněno při kaţdé aktivitě v rámci tvorby i změny enterprise architecture je nutné myslet na vazbu se strategickými cíli organizace. Konkrétně v této fázi to znamená, ţe základ architektury i kaţdá nová změna musí být provedeny tak dobře, aby tento úkol splnily. Pochopitelně je to úkol extrémně sloţitý, protoţe předvídat budoucnost dost dobře nelze. V rámci fáze Architecture Change Management pracovního rámce TOGAF jsou definovány techniky, které mohou tento úkol zjednodušit. Jedná se o následující doporučení: Správa změn jen prováděna tak, ţe dodrţuje návaznosti na ostatní fáze pracovního rámce a jsou dodrţována architektonická pravidla. Typicky je prováděn průběţný monitoring celé enterprise architecture. Tento monitoring proaktivně upozorňuje na potencionálně slabá nebo nevýkonné části. V některých prostředích se můţe stát, ţe zatímco provedení změny na úrovni byznys a informační-datové architektury je moţné, tak provedení změny na úrovni aplikační a technologické architektury provést nelze. Zpravidla kvůli pevným limitům na straně technologické vrstvy. To je relativně častý jev, se kterým musí enterprise architekt počítat. Není moţné ho zcela vyloučit. Doporučenou cestou je stanovení odpovídajících metrik, které se nastaví v rámci monitoringu. Výsledkem je, ţe management organizace i enterprise architekt mají moţnost připravit úpravu architektury dřív, neţ se její omezení projeví ve funkčních systémech. Je-li to moţné, je doporučeno vybírat řešení pouţívané na aplikační a technologické vrstvě architektury tak, aby umoţňovalo škálovatelnost. V reálné praxi je tento problém moţno řešit pomocí outsourcingu na těchto dvou vrstvách. Řízení celé architektury zůstává plně v kompetenci vlastní organizace a mnoţství výkonu v aplikační a technologické vrstvě se pronajímá dle aktuálních potřeb. Kapacita měření a doporučení pro plánování jsou klíčovým aspektem této fáze. Pochopitelně neexistuje univerzální doporučení pro všechny organizace. Je třeba promítnout specifické vazby dané sektorem podnikání, velikostí organizace i různým pohledem na míru rizika, co se stane, kdyţ architektura nebude stoprocentně funkční. 34

35 Kritickým faktorem v této fázi je stanovení kritéria, které umí rozlišit, kdy je ještě moţné reagovat na nové poţadavky provedením změny v architektuře a kdy uţ je nutné začít uvaţovat o úplně novém návrhu enterprise architecture. Samostatnou problematikou řízení změny architektury je stav, kdy předmětem změny je začlenění existující architektury. Moţné jsou následující tři způsoby: Změna je řízena direktivním způsobem top-down (shora-dolů) na úrovni strategického managementu. Typicky se vyuţívá v situaci, kdy jedna organizace přebírá formou akvizice jinou do té doby samostatnou organizaci. Nebo při rozšiřování portfolia společnosti, kdy jsou zaváděny nové obchodní procesy a funkce. Výhodou tohoto způsobu je, ţe změna je vedena jasným a přímočarým způsobem. Nevýhodou, zejména při akvizici, se můţe stát fakt, ţe zaměstnanci přebírané společnosti (kteří jako jediní dobře znají přebíraný systém) nejsou aktivní a během změny dojde ke ztrátě původních výhod systému. Změna je řízena způsobem bottom-up (zdola-nahoru) na úrovni operativního managementu. Tento způsob se vyuţívá zejména v situaci, kdy je potřeba zvýšit výkonnost stávající infrastruktury. Je to situace, kdy logická část infrastruktury je vyhovující a je potřeba provést změny v kapacitě a výkonnosti dílčích komponent. Výhodou je potencionální rychlost celého procesu změny z pohledu funkčních systémů. Je-li špatně zaveden způsob řízení změny, můţe se stát, ţe informace o provedené změně se nepromítne do vyšších vrstev architektury. Bohuţel je to častý nešvar na úrovni operativního řízení. Tato skutečnost můţe v budoucnosti způsobit značné problémy, protoţe enterprise architekti při plánování jiné změny budou předpokládat jiný výchozí stav neţ je ve skutečnosti. Posledním způsobem pro začlenění stávající architektury je způsob zaloţený na zkušenostech z obdobného prostředí. Obrovskou výhodou tohoto způsobu, ţe je ideálním vyváţením obou předcházejících způsobů. Je prokazatelně nejefektivnější a nerychlejší. Problémem je nedostatek lidí disponujících takovými znalostmi a schopnostmi. Navíc je situace komplikována faktem, ţe pokud někdo provádí takovouto integraci, pak má zpravidla ve své pracovní smlouvě doloţku zakazující provádění této činnosti u konkurenčních organizací, coţ jsou právě ty, jejichţ infrastruktura je nejpodobnější a vyuţití získaných znalostí by bylo nejefektivnější. 35

36 1.2.2 Obecné řízení změny I v případě, ţe nemá organizace nástroj/prostředek specificky určení pro řízení změn v enterprise architektuře, má moţnost vyuţít obecně platná doporučení/standardů pro řízení podnikové informatiky, která jí pomohou vyrovnat se s vzniklou situací. Jedním z takových řešení je vyuţití pracovního rámce ITIL, konkrétně jeho modulu pro řízení změn. ITIL je souhrn obecně platných doporučení pro řízení zejména sluţeb v rámci ICT prostředí. Vznikl z popudu britské vlády v osmdesátých letech minulého století. Zadáním bylo vypracování pro účelnou správu a vyuţití IT zdrojů ve veřejném sektoru. Tohoto cíle bylo dosaţeno a vznikl rámec s názvem Government Information Technology Infrastructure Management Method. Z pohledu dnešní enterprise architecture tento rámec řešil pouze spodní dvě vrstvy; tedy vrstvu aplikačních systémů a technologickou. Postup času docházelo k rozvoji tohoto rámce a dostalo se mu i dnešního jména ITIL. Coţ je zkratkou pro Information Technology Infrastructure Library. Na vrchol oblíbenosti coby mezinárodně uznávaný standard pro řízení ICT sluţeb se ITIL dostal s vydáním verze 2, která začala vycházet v roce Obrázek 10 - ITIL v2 - základní schéma 36

37 Základ této verze tvořilo osm knih: Řízení a správa aplikací (Application Management), Řízení a správa infrastruktury (Infrastructure Management), Byznys pohled (Business Perspectives), Řízení a správa bezpečnosti (Security Management), Plánování implementace řízení a správy sluţeb (Planning to Implement Service Management), Řízení a správa SW majetku (Software Asset Management), Podpora sluţeb (Service Support), Poskytování sluţeb (Service Delivery). Zejména poslední dvě knihy se staly velmi oblíbené. Jejich obrovským přínosem bylo, ţe se díky jim podařilo sjednotit terminologii pro oblast řízení sluţeb. Jejich pouţívání se stalo doslova masovou záleţitostí. Téměř kaţdý se v procesech definovaných ITILem našel. Současně došlo k vymezení jednotlivých oblastí, které se zabývaly podporou sluţeb, jejich zavádění, správy, řešení bezpečnosti, řešení chybových stavů a také řešení poţadavků na změnu a jejich zpracování. Jak jiţ bylo zmíněno, osm základních knih vznikalo postupně a na jejich vzniku se podílelo více autorů, kteří některé části interpretovali rozdílným způsobem, a existovalo několik protichůdných doporučení. Tento nedostatek byl odstraněn ve verzi 3 vydané v roce Po zkušenostech z předchozí verze byly vydány všechny knihy společně a během přípravy byla práce na jednotlivých knihách koordinována. Počet knih byl sníţen na pět a došlo k jejich celkovému přepracování. Zásadní nově zpracovanou myšlenkou je ţivotní cyklus sluţby, který se promítá do všech popisovaných procesů. ITIL v3 se skládá z těchto pěti knih: Strategie sluţeb (Service Strategy) Design sluţeb (Service Design) Přechod na sluţby (Service Transition) Provozování sluţeb (Service Operation) Nepřetrţité zlepšování sluţeb (Continual Service Improvement) 37

38 Obrázek 11 - ITIL v3 - základní schéma ITIL v3 nedosáhl na takový stupeň obliby jako jeho předchozí verze i kdyţ k tomu měl všechny předpoklady. Oproti verzi 2 došlo k odstranění některých protichůdných myšlenek a všech pět knih je vzájemně konzistentních. I zavedení ţivotního cyklu do jednotlivých procesů bylo logické, smysluplné a v souladu s vývoje celého ICT prostředí. Přesto přijetí širokou veřejností i po třech letech od uvedení je stále vlaţné. Co je důvodem? Pochopitelně spekulací je celá řada. Několik z nich je uvedeno ve výsledcích provedeného výzkumu v praktické části této diplomové práce. Pro problematiku řízení změn v rámci enterprise architektury lze z ITILu v2 vyuţít doporučení z knihy Řízení a správa infrastruktury (Infrastructure Management), která popisuje provádění změn po dobu jejího ţivotního cyklu. Vlastní cyklus řízení je popsán pomocí těchto procesů: Návrh a plánování (Design and Planning) tento proces zajišťuje prvotní návrh a přípravu řešení; snaţí se reflektovat všechny potencionální části, které řešení můţe ovlivňovat Nasazení (Deployment) proces řešící vlastní implementaci a zavádění řešení do provozu, tak aby byly ostatní činnosti ovlivněny co nejméně 38

39 Provozování (Operations) tento proces obsahuje všechny nutné k plánovanému vyuţití provozovaného řešení, tak jak bylo navrţeno. Současně zajišťuje dodrţení všech parametrů stanovených v rámci SLA (Service Level Agreement) Technická podpora (Technical Support) proces zahrnující podporu, rozvoj a testování současného řešení a současně poskytuje technickou podporu pro připravovaná řešení. Ve své podstatě je ITIL (zejména ve verzi 2) velmi srozumitelný koncept, jehoţ zásadním rozdílem oproti pracovním rámcům specificky zaměřeným na návrh, provoz a řízení enterprise architektury je fakt, ITIL nemá exaktně stanové předpisy, které je potřeba dodrţet. Nabízí obecně platnou moţnost řízení prostředí a dává kaţdé organizaci moţnost vybrat se jen tu část, kterou povaţuje za vhodnou a uţitečnou. To platí i pro verzi 3, kde však nelze tak snadno vybrat jen tu část, kterou by organizace chtěla pouţívat. Je to způsobeno právě přepracování a zavedením ţivotního cyklu do všech procesů. Výsledkem je, ţe de facto kaţdý proces souvisí s kaţdým. Například doporučení pro řízení architektury jiţ není v jedné knize, ale její částí jsou rozprostřeny do všech pěti knih. Pravděpodobně nejblíţe problematice řízení změn architektury je kniha Nepřetržité zlepšování služeb (Continual Service Improvement), která se zabývá moţnostmi pro neustále zlepšování sluţeb během ţivotního cyklu a zajišťováním souladu se strategickými cíli organizace. 39

40 1.2.3 Srovnání použití ITIL a TOGAF Po přečtení předcházejících kapitol můţe vyvstat otázka, který ze zmíněných rámců je pro řízení změny lepší? Otázka je to bezesporu legitimní a jasná. Ovšem odpověď uţ tak jasná a jednoznačná není. Oba pracovní rámce mají jiţ vydobyto své místo na trhu. O tom není pochyb. První moţností jak oba srovnat je podle stupně řízení pro které jsou nejlépe vyuţitelné. Výstiţně to vystihuje následující obrázek. Obrázek 12 - Srovnání ITIL a TOGAF dle úrovně řízení Z toho obrázku vyplývá, ţe zatímco TOGAF je dominantní pro vrcholové strategické řízení, tak ITIL nejvíce rozpracován pro oblast operativního řízení. Další srovnání, které můţeme provést je podle toho, které vrstvy enterprise architektury jednotlivé pracovní rámce pokrývají. Respektive, kde se překrývají. Obrázek 13 - Srovnání ITIL a TOGAF dle vrstev enterprise architektury 40

41 Zatímco TOGAF pokrývá jednotlivé vrstvy enterprise architektury, tak jak je definována v úvodu teoretické části této práce, tak ITIL se věnuje niţším vrstvám (mimo Byznys architektury, kterou očekává jako definovaný vstup) a oproti TOGAFu navíc rozpracovává niţší procesy prováděné v rámci reálného funkčního systému. Poslední srovnání, které je zde uvedeno porovnání oblastí, které pokrývají knihy ITIL v3 a jednotlivé fáze ADM metody pouţívané v TOGAFu. Obrázek 14 - Srovnání ITIL v3 a TOGAF metody ADM I z tohoto srovnání je patrné, ţe z velké části jsou pokryty shodné oblasti. Opět zde máme zvýrazněn rozdíl v části návrhu pro vrstvu Byznys architektury. Zatímco TOGAF ji definuje ve fázi B metody TOGAF ADM, tak ITIL v3 očekává, ţe tyto informaci jiţ pouze zapracuje v rámci procesu pro řízení vstupních poţadavků (Requirements Management). 41

42 2 Praktická část Cílem praktické části bylo získat nezávislé informace z reálného prostředí a vyhodnotit, které standardy, doporučení, nástroje a pracovní rámce jsou dnes pouţívány. Základem je provedený výzkum uskutečněný cíleně pro tuto diplomovou práci. Výstupy tohoto výzkumu jsou porovnány s výsledky veřejně dostupných průzkumů zaměřených na oblast enterprise architecture a pracovních rámců. Souhrnné vyhodnocení všech průzkumů je doplněno vlastními zkušenostmi Vlastní výzkum - zadání Během přípravy obsahu této diplomové práce jsem koncem léta 2009 dospěl k názoru, ţe by bylo vhodné podpořit ji informacemi z reálného prostředí. Proto jsem se rozhodl sestavit dotazník s otázkami na dané téma a poţádal celkem 14 respondentů o vyplnění tohoto dotazníku. Jednalo se o manaţery a odborné technické pracovníky, kteří mají v rámci své pracovní činnosti za úkol také návrh a správu architektury informačních systémů. Ve svém prostředí musí zabezpečit plynulý a efektivní provoz všech částí informačního systému. Zpravidla se jedná o nadnárodní společnosti s desítkami serverů v centrálních částech informačního systému a s počtem koncových stanic v rozmezí od do Provedený výzkum byl rozdělen na dvě části. Nejprve respondenti obdrţeli dotazník, kde byly následující otázky: Víte, co to je enterprise architektura? Pokud ano, pouţíváte ji nebo uvaţujete o jejím nasazení? Pokud ji pouţíváte, v jaké fázi implementace se nacházíte? Provádíte průběţné vyhodnocování architektury informačního systému? Jaké pracovní rámce a nástroje pro návrh, vývoj a provoz architektury informačních systémů znáte? Jaké pracovní rámce a nástroje pro návrh, vývoj a provoz architektury informačních systémů pouţíváte? 42

43 Pokud pouţíváte pracovní rámce pro enterprise architecure, proč jste se rozhodli pro jejich nasazení? Pokud pouţíváte pracovní rámce, jaké jsou jejich výhody/nevýhody? Jaké zkušenosti máte se zaváděním architektury informačního systému? Co byste poradili těm, kteří plánují změnu architektury informačního systému? Po zpracování dotazníků z první části proběhl s kaţdým respondentem individuální rozhovor, kde jsme rozebrali podrobnosti jejich odpovědí. Podmínkou respondentů bylo zachování jejich anonymity. 43

44 2.1.2 Vlastní výzkum - výsledky V této kapitole jsou uvedeny výsledky odpovědí na jednotlivé otázky výzkumu Víte, co to je enterprise architektura? Odpovědi respondentů: Ano, vím přesně co to je. 9 Ano, mám rámcovou představu. 5 Ne, nevím. 0 Ano, vím přesně co to je. Ano, mám rámcovou představu. Ne, nevím. Obrázek 15 - Odpovědi na otázku Víte, co to je enterprise architektura? 44

45 Pokud ano, pouţíváte ji nebo uvaţujete o jejím nasazení? Odpovědi respondentů: Ano, tuto architekturu jiţ plně vyuţíváme. 6 Ano, vyuţíváme ji, ale zatím jen částečně. 3 Uvaţujeme o její implementaci. 3 Ne, zatím ji neplánujeme pouţívat. 2 Ano, tuto architekturu již plně využíváme. Ano, využíváme ji, ale zatím jen částečně. Uvažujeme o její implementaci. Ne, zatím ji neplánujeme používat. Obrázek 16 - Odpovědi na otázku Používáte EA nebo uvažujete o jejím nasazení?" 45

46 Pokud ji pouţíváte, v jaké fázi implementace se nacházíte? Odpovědi respondentů: Máme implementovánu část Byznys architektura. 6 Máme implementovánu část Informační-datová architektura. 7 Máme implementovánu část Architektura aplikačních systémů. 7 Máme implementovánu část Architektura infrastruktury. 9 Máme implementovánu část Architektura infrastruktury Máme implementovánu část Architektura aplikačních systémů Máme implementovánu část Informačnídatová architektura Máme implementovánu část Byznys architektura Obrázek 17 - Odpověď na otázku "V jaké fázi implementace EA se nacházíte?" 46

47 Provádíte průběţné vyhodnocování architektury informačního systému? Odpovědi respondentů: Ano, vyhodnocování provádíme pravidelně. 6 Ano, ale jen kvůli vedení (případně auditu). 6 Ne, vyhodnocujeme pouze v případě problému. 2 Ne, vyhodnocení neprovádíme. 0 Ano, vyhodnocování provádíme pravidelně. Ano, ale jen kvůli vedení (případně auditu). Ne, vyhodnocujeme pouze v případě problému. Ne, vyhodnocení neprovádíme. Obrázek 18 - Odpověď na otázku "Provádíte průběžné vyhodnocování architektury IS?" 47

48 Jaké pracovní rámce a nástroje pro návrh, vývoj a provoz architektury informačních systémů znáte? Respondenti uvedli, ţe znají tyto pracovní rámce: ITIL v2 ITIL v3 TOGAF ZACHMAN DODAF FEAF Respondenti uvedli, ţe znají tyto nástroje: IDS Sheer - ARIS IBM - Rational Software Architect CA - Erwin CA - NetViz Suite Sparx - Enterprise Architect Alfabet - Planning IT 48

49 Jaké pracovní rámce a nástroje pro návrh, vývoj a provoz architektury informačních systémů pouţíváte? Respondenti uvedli, ţe pouţívají tyto pracovní rámce: ITIL v2 11 ITIL v3 3 TOGAF 3 ZACHMAN 4 DODAF 1 FEAF 1 Poznámka: V několika prostředí je vyuţíváno více pracovních rámců (jak rámce pro správu enterprise architecture, tak pro řízení sluţeb), proto je celkový součet pouţívaných pracovních rámců vyšší neţ počet respondentů. FEAF DODAF ZACHMAN TOGAF ITIL v3 ITIL v Obrázek 19 - Odpověď na otázku "Jaké pracovní rámce používáte?" 49

50 Respondenti uvedli, ţe pouţívají tyto nástroje: IDS Sheer - ARIS 4 IBM - Rational Software Architect 2 CA - Erwin 1 CA - NetViz Suite 1 Sparx - Enterprise Architect 2 Alfabet - Planning IT 1 Poznámka: V prostředí jednoho respondenta jsou vyuţívány dva nástroje společnosti CA, proto je součet pouţívaných nástrojů vyšší neţ počet respondentů. Alfabet - Planning IT Sparx - Enterprise Architect CA - NetViz Suite CA - Erwin IBM - Rational Software Architect IDS Sheer - ARIS Obrázek 20 - Odpověď na otázku Jaké nástroje používáte?" 50

51 Pokud pouţíváte pracovní rámce pro enterprise architecture, proč jste se rozhodli pro jejich nasazení? Odpovědi respondentů: Snaha o lepší vazbu mezi byznysem a informačním systémem. 9 Očekávali jsme zefektivnění řízení organizace. 8 Očekávali jsme úsporu investic do informačního systému. 7 Předpokládali jsme lepší podmínky pro následnou konsolidaci IS. 6 Jiné. Prosím doplňte. 2 Respondenti ještě doplnili tyto dva důvody: Potřebovali jsme podporu při akvizicích dalších společností. Doufali jsme, ţe pouţití standardizovaného postupu zlepší dokumentaci jednotlivých procesů, datového modelu a vazbu na funkční systém Snaha o lepší vazbu mezi byznysem a informačním systémem. Předpokládali jsme lepší podmínky pro následnou konsolidaci IS. Očekávali jsme úsporu investic do informačního systému. Očekávali jsme zefektivnění řízení organizace. Jiné. Prosím doplňte Obrázek 21 - Odpověď na otázku Proč jste se rozhodli pro nasazení pracovního rámce? 51

Vývoj informačních systémů. Obecně o IS

Vývoj informačních systémů. Obecně o IS Vývoj informačních systémů Obecně o IS Informační systém Informační systém je propojení informačních technologií a lidských aktivit směřující k zajištění podpory procesů v organizaci. V širším slova smyslu

Více

CobiT. Control Objectives for Information and related Technology. Teplá u Mariánských Lázní, 6. října 2004

CobiT. Control Objectives for Information and related Technology. Teplá u Mariánských Lázní, 6. října 2004 CobiT Control Objectives for Information and related Technology Teplá u Mariánských Lázní, 6. října 2004 Agenda Základy CobiT Pojem CobiT Domény CobiT Hodnocení a metriky dle CobiT IT Governance Řízení

Více

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Procesy, procesní řízení organizace Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Co nového přináší ISO 9001:2008? Vnímání jednotlivých procesů organizace jako prostředku a nástroje

Více

Stav řešení Enterprise Architektury na Moravskoslezském kraji

Stav řešení Enterprise Architektury na Moravskoslezském kraji Stav řešení Enterprise Architektury na Moravskoslezském kraji Zpracoval(a): Ing. Tomáš Vašica Datum: 23. 9. 2015 Obsah prezentace 1. Představení projektového záměru 2. Co očekává Moravskoslezský kraj od

Více

Co je to COBIT? metodika

Co je to COBIT? metodika COBIT Houška, Kunc Co je to COBIT? COBIT (Control OBjectives for Information and related Technology) soubor těch nejlepších praktik pro řízení informatiky (IT Governance) metodika určena především pro

Více

Obsah. ÚVOD 1 Poděkování 3

Obsah. ÚVOD 1 Poděkování 3 ÚVOD 1 Poděkování 3 Kapitola 1 CO JE TO PROCES? 5 Co všechno musíme vědět o procesním řízení, abychom ho mohli zavést 6 Různá důležitost procesů 13 Strategické plánování 16 Provedení strategické analýzy

Více

GIS Libereckého kraje

GIS Libereckého kraje Funkční rámec Zpracoval: Odbor informatiky květen 2004 Obsah 1. ÚVOD...3 1.1. Vztah GIS a IS... 3 2. ANALÝZA SOUČASNÉHO STAVU...3 2.1. Technické zázemí... 3 2.2. Personální zázemí... 3 2.3. Datová základna...

Více

Představení projektu Metodika

Představení projektu Metodika Představení projektu Metodika přípravy veřejných strategií Strategické plánování a řízení v obcích metody, zkušenosti, spolupráce Tematická sekce Národní sítě Zdravých měst Praha, 10. května 2012 Obsah

Více

ÚVOD DO PROBLEMATIKY PROJEKTŮ, KATEGORIE

ÚVOD DO PROBLEMATIKY PROJEKTŮ, KATEGORIE PROJEKTOVÉ ŘÍZENÍ STAVEB ÚVOD DO PROBLEMATIKY PROJEKTŮ, KATEGORIE Vysoká škola technická a ekonomická v Českých PROJEKTŮ Budějovicích Institute of Technology And Business In České Budějovice Tento učební

Více

Analýza a Návrh. Analýza

Analýza a Návrh. Analýza Analysis & Design Návrh nebo Design? Design = návrh Není vytváření použitelného uživatelského prostředí (pouze malinká podmnožina celého návrhu) Často takto omezeně chápáno studenty nedokáží si představit,

Více

Outsourcing v podmínkách Statutárního města Ostravy

Outsourcing v podmínkách Statutárního města Ostravy Outsourcing v podmínkách Statutárního města Ostravy Říjen 2009 Ing. Stanislav Richtar Ředitel společnosti 1 OBSAH PREZENTACE 1. Outsourcing - obecně 2. Výchozí stav projektu 3. Model poskytovaných služeb

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

Otázky kurzu 4IT417 Řízení podnikové informatiky verze z 1/2/2009. 1.Podniková informatika pojmy a komponenty

Otázky kurzu 4IT417 Řízení podnikové informatiky verze z 1/2/2009. 1.Podniková informatika pojmy a komponenty Otázky kurzu 4IT417 Řízení podnikové informatiky verze z 1/2/2009 1.Podniková informatika pojmy a komponenty (1) Objasněte pojmy: IS, ICT, ICT služba, ICT proces, ICT zdroj. Jakou dokumentaci k ICT službám,

Více

19.11.2013. Projektový management. Projektový management. Další charakteristiky projektu. Projekt

19.11.2013. Projektový management. Projektový management. Další charakteristiky projektu. Projekt Projektový management Lekce: 8 Projektový management Doc. Ing. Alois Kutscherauer, CSc. Projektový management je typ managementu uplatňovaného k zabezpečení realizace jedinečných, neopakovatelných, časově

Více

Vysoká škola finanční a správní, o.p.s. Katedra řízení podniku a podnikové ekonomiky. Metodické listy pro předmět ŘÍZENÍ PODNIKU 2

Vysoká škola finanční a správní, o.p.s. Katedra řízení podniku a podnikové ekonomiky. Metodické listy pro předmět ŘÍZENÍ PODNIKU 2 Vysoká škola finanční a správní, o.p.s. Katedra řízení podniku a podnikové ekonomiky Metodické listy pro předmět ŘÍZENÍ PODNIKU 2 Studium předmětu umožní studentům základní orientaci v procesech, které

Více

S T R A T E G I C K Ý M A N A G E M E N T

S T R A T E G I C K Ý M A N A G E M E N T S T R A T E G I C K Ý M A N A G E M E N T 3 LS, akad.rok 2014/2015 Strategický management - VŽ 1 Proces strategického managementu LS, akad.rok 2014/2015 Strategický management - VŽ 2 Strategický management

Více

Informační strategie. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz

Informační strategie. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Informační strategie Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz 23 1 Firemní strategie Firma Poslání Vize Strategie Co chceme? Kam směřujeme? Jak toho dosáhneme? Kritické faktory úspěchu CSF 23 2 Strategie

Více

Standardy/praktiky pro řízení služeb informační bezpečnosti. Doc. Ing. Vlasta Svatá, CSc. Vysoká škola ekonomická Praha

Standardy/praktiky pro řízení služeb informační bezpečnosti. Doc. Ing. Vlasta Svatá, CSc. Vysoká škola ekonomická Praha Standardy/praktiky pro řízení služeb informační bezpečnosti Doc. Ing. Vlasta Svatá, CSc. Vysoká škola ekonomická Praha Služby informační bezpečnosti Nemožnost oddělit informační bezpečnost od IT služeb

Více

Zavádění projektového řízení ve společnosti

Zavádění projektového řízení ve společnosti Zavádění projektového řízení ve společnosti Monika Pidrmanová 26.10.2011 ZÁKLADNÍ POJMY Projekt = Jedinečný proces sestávající z řady koordinovaných a řízených činností s daty zahájení a ukončení, prováděný

Více

POŽADAVKY NORMY ČSN EN ISO 9001:2009 idt. ISO 9001:2008

POŽADAVKY NORMY ČSN EN ISO 9001:2009 idt. ISO 9001:2008 POŽADAVKY NORMY ČSN EN ISO 9001:2009 idt. ISO 9001:2008 Vývoj ČSN EN ISO 9001:2009 Systémy managementu kvality Požadavky idt ISO 9001:2008 Struktura a obsah normy Obsah normy ISO 9001:2008 0 Úvod 1 Předmět

Více

Nástroje IT manažera

Nástroje IT manažera Obsah Nástroje IT manažera Školení uživatelů Ochrana osobních údajů Bezpečnostní politika Software a právo Legální software Management jakosti Výběr a řízení dodavatelů Pracovněprávní minimum manažerů

Více

Procesní řízení. Hlavní zásady a praxe dodavatele Komix

Procesní řízení. Hlavní zásady a praxe dodavatele Komix Procesní řízení Hlavní zásady a praxe dodavatele Komix 1 Obsah prezentace Teoretická část (menšího objemu) orientace na zákazníka hodnocení procesu podmínky procesního řízení cyklus zlepšování procesu

Více

X36SIN: Softwarové inženýrství. Životní cyklus a plánování

X36SIN: Softwarové inženýrství. Životní cyklus a plánování X36SIN: Softwarové inženýrství Životní cyklus a plánování 1 Kontext Minule jsme si řekli, co to je deklarace záměru, odborný článek, katalog požadavků, seznam aktérů a seznam událostí. Seznam aktérů a

Více

Bezpečnostní normy a standardy KS - 6

Bezpečnostní normy a standardy KS - 6 VŠFS; Aplikovaná informatika; SW systémy 2005/2006 1 Bezpečnost informací BI Ing. Jindřich Kodl, CSc. Bezpečnostní normy a standardy KS - 6 VŠFS; Aplikovaná informatika; SW systémy 2005/2006 2 Osnova historický

Více

Vysoká škola technická a ekonomická v Českých Budějovicích. Institute of Technology And Business In České Budějovice

Vysoká škola technická a ekonomická v Českých Budějovicích. Institute of Technology And Business In České Budějovice PROCES STRATEGICKÉHO ŘÍZENÍ, HIERARCHIE STRATEGIE (KOMPLEXNÍ PODNIKOVÁ STRATEGIE CORPORATE STRATEGY,, OBCHODNÍ STRATEGIE, DÍLČÍ STRATEGIE) Vysoká škola technická a ekonomická v Českých Budějovicích Institute

Více

HODNOCENÍ VÝKONNOSTI PODNIKU VE SPOJITOSTI SE STRATEGICKÝMI CÍLY

HODNOCENÍ VÝKONNOSTI PODNIKU VE SPOJITOSTI SE STRATEGICKÝMI CÍLY 29 HODNOCENÍ VÝKONNOSTI PODNIKU VE SPOJITOSTI SE STRATEGICKÝMI CÍLY POKORNÝ Karel Abstrakt: Metoda Balanced Scorecard (BSC) její podstata, obsah a principy. Vztah BSC ke strategickému a operativnímu řízení

Více

Jak na jakost v podnikovém IT Evropský týden kvality Praha 10.11.2004

Jak na jakost v podnikovém IT Evropský týden kvality Praha 10.11.2004 Jak na jakost v podnikovém IT Evropský týden kvality Praha 10.11.2004 Jiří Sedláček AIT s.r.o, Sinkulova 83, 140 00 Praha 4 tel. 261 225 072 www.ait.cz AIT, 2004 1 Program Současné postavení IT v podniku

Více

PROJEKTOVÝ ZÁMĚR. Základní škola a Mateřská škola Verneřice, příspěvková organizace Název projektu: Moderní škola 2011 Název operačního programu:

PROJEKTOVÝ ZÁMĚR. Základní škola a Mateřská škola Verneřice, příspěvková organizace Název projektu: Moderní škola 2011 Název operačního programu: PROJEKTOVÝ ZÁMĚR Operační program Vzdělávání pro konkurenceschopnost Oblast podpory 1.4 Zlepšení podmínek pro vzdělávání na základních školách Ţadatel projektu: Základní škola a Mateřská škola Verneřice,

Více

Manažerská ekonomika

Manažerská ekonomika PODNIKOVÝ MANAGEMENT (zkouška č. 12) Cíl předmětu Získat znalosti zákonitostí úspěšného řízení organizace a přehled o současné teorii a praxi managementu. Seznámit se s moderními manažerskými metodami

Více

Představení normy ČSN ISO/IEC 20000 Management služeb

Představení normy ČSN ISO/IEC 20000 Management služeb Představení normy ČSN ISO/IEC 20000 Management služeb Luděk k Novák konzultant, ANECT Agenda Historie a souvislosti ISO/IEC 20000 Postavení vůči ITIL Procesy pro řízení služeb PDCA model pro řízení služeb

Více

STRATEGIE A PROJEKTY ODBORU INFORMATIKY MHMP

STRATEGIE A PROJEKTY ODBORU INFORMATIKY MHMP STRATEGIE A PROJEKTY ODBORU INFORMATIKY MHMP Ing. Ivan Seyček Vedoucí oddělení realizace řešení a provozu Odbor informatiky MHMP 1 / 30. dubna 2009 AGENDA PREZENTACE 1. Strategie Odboru informatiky MHMP

Více

Sjednocení dohledových systémů a CMDB

Sjednocení dohledových systémů a CMDB Řízení dodávky IT služeb v enterprise společnosti Sjednocení dohledových systémů a CMDB Václav Souček, ČEZ ICT Services, a.s. Jaroslav Jičínský, AutoCont CZ, a.s. 26. Ledna 2012 Agenda Úvod Výchozí stav

Více

Analýza a vytváření pracovních míst

Analýza a vytváření pracovních míst Analýza a vytváření pracovních míst Definice pracovního místa a role Pracovní místo Analýza role Roli lze tedy charakterizovat výrazy vztahujícími se k chování existují-li očekávání, pak roli představuje

Více

VIZE INFORMATIKY V PRAZE

VIZE INFORMATIKY V PRAZE VIZE INFORMATIKY V PRAZE Václav Kraus, ŘED INF MHMP 1 / 30. 4. 2009 PRAHA MĚSTO PRO ŽIVOT Město mezinárodně uznávané, ekonomicky prosperující a úspěšné. Město bezpečné a přívětivé, město sebevědomých a

Více

Aktuální stav přípravy. Národní strategie elektronického zdravotnictví. v České republice

Aktuální stav přípravy. Národní strategie elektronického zdravotnictví. v České republice Aktuální stav přípravy Národní strategie elektronického zdravotnictví v České republice 17. září 2014 Malostranský palác, Praha Konference ICT ve zdravotnictví Ing. Martin Zeman Oddělení poradců a strategií

Více

ABC s.r.o. Výtisk číslo: PŘÍRUČKA ENVIRONMENTU. Zpracoval: Ověřil: Schválil: Č.revize: Počet příloh: Účinnost od:

ABC s.r.o. Výtisk číslo: PŘÍRUČKA ENVIRONMENTU. Zpracoval: Ověřil: Schválil: Č.revize: Počet příloh: Účinnost od: ABC s.r.o. PŘÍRUČKA EMS Výtisk číslo: Zpracoval: Ověřil: Schválil: Tento dokument je duševním vlastnictvím společnosti ABC s.r.o. Rozmnožování a předávání třetí straně bez souhlasu jejího jednatele není

Více

KIV/SI. Přednáška č.2. Jan Valdman, Ph.D. jvaldman@dns.cz

KIV/SI. Přednáška č.2. Jan Valdman, Ph.D. jvaldman@dns.cz KIV/SI Přednáška č.2 Jan Valdman, Ph.D. jvaldman@dns.cz 8.3.2011 ITIL Information Technology Infrastructure Library ITIL v současnosti zahrnuje: Samotnou knihovnu Oblast vzdělávání a certifikace odborné

Více

Náležitosti ICT plánu Cíl kapitoly. Základní pojmy. Kam patří ICT plán?

Náležitosti ICT plánu Cíl kapitoly. Základní pojmy. Kam patří ICT plán? Náležitosti ICT plánu Cíl kapitoly Podrobněji přiblížit proces plánování, začlenění ICT plánu do systému plánů ve škole a předložení oblastí, které je třeba v ICT plánu popsat ve fázích: popisu aktuálního

Více

Projekt Metodika přípravy veřejných strategií. Akční plán aktivit v oblasti strategické práce na rok 2013

Projekt Metodika přípravy veřejných strategií. Akční plán aktivit v oblasti strategické práce na rok 2013 Projekt Metodika přípravy veřejných strategií Akční plán aktivit v oblasti strategické práce na rok 2013 Listopad 2012 Obsah Obsah... 2 1. Kontext vzniku akčního plánu... 3 2. Přehled aktivit... 4 3. Akční

Více

www.tuv-sud.cz TÜV SÜD Czech s.r.o. Systém energetického managementu dle ČSN EN 16001

www.tuv-sud.cz TÜV SÜD Czech s.r.o. Systém energetického managementu dle ČSN EN 16001 www.tuv-sud.cz s.r.o. Systém energetického managementu dle ČSN EN 16001 Zavádění sytému energetického managementu dle ČSN EN 16001 Záměr zvyšování energetické účinnosti trvalý proces zefektivňování snížení

Více

ČSN ISO/IEC 27001:2014 a zákon o kybernetické bezpečnosti

ČSN ISO/IEC 27001:2014 a zákon o kybernetické bezpečnosti ČSN ISO/IEC 27001:2014 a zákon o kybernetické bezpečnosti Ing. Daniel Kardoš, Ph.D 4.11.2014 ČSN ISO/IEC 27001:2006 ČSN ISO/IEC 27001:2014 Poznámka 0 Úvod 1 Předmět normy 2 Normativní odkazy 3 Termíny

Více

Inovace bakalářského studijního oboru Aplikovaná chemie http://aplchem.upol.cz

Inovace bakalářského studijního oboru Aplikovaná chemie http://aplchem.upol.cz http://aplchem.upol.cz CZ.1.07/2.2.00/15.0247 Tento projekt je spolufinancován Evropským sociálním fondem a státním rozpočtem České republiky. 9. přednáška Normy ISO 9001, ISO 14001 a OHSAS 18001 Doc.

Více

ISO 9001 : 2015. Certifikační praxe po velké revizi

ISO 9001 : 2015. Certifikační praxe po velké revizi ISO 9001 : 2015 Certifikační praxe po velké revizi Audit Audit z lat. auditus, slyšení Vzhledem k rozsahu prověřování se audit obvykle zabývá jen vzorky a jeho výsledek tedy neznamená naprostou jistotu,

Více

Úvodní přednáška. Význam a historie PIS

Úvodní přednáška. Význam a historie PIS Úvodní přednáška Význam a historie PIS Systémy na podporu rozhodování Manažerský informační systém Manažerské rozhodování Srovnávání, vyhodnocování, kontrola INFORMACE ROZHODOVÁNÍ organizace Rozhodovacích

Více

Jednotný NIS Prezentace k zahájení projektu pro Radu kraje Vysočina. Projektový manažer - Ing. Ivan Sokolov, Ph.D.

Jednotný NIS Prezentace k zahájení projektu pro Radu kraje Vysočina. Projektový manažer - Ing. Ivan Sokolov, Ph.D. Prezentace k zahájení projektu pro Radu kraje Vysočina Projektový manažer - Ing. Ivan Sokolov, Ph.D. Obsah Úvod Cíle projektu Rozsah projektu Projektové řízení základní východiska Základní organizační

Více

Projektové řízení jako základ řízení organizace

Projektové řízení jako základ řízení organizace Projektové řízení jako základ řízení organizace Aleš Chudý, ředitel divize IW ales.chudy@microsoft.com Technický seminář Bratislava 6.10.2008 Obsah Potřeby byznysu a IT Řešení EPM Microsoft EPM Optimalizační

Více

Metodický list pro první soustředění kombinovaného studia. předmětu Management ve finančních službách

Metodický list pro první soustředění kombinovaného studia. předmětu Management ve finančních službách Metodický list pro první soustředění kombinovaného studia předmětu Management ve finančních službách Název tematického celku: Základní koncepční přístupy a osobnost manažera Cíl: V návaznosti na poznatky

Více

Řízení podniku a prvky strategického plánování

Řízení podniku a prvky strategického plánování 6.2.2009 Řízení podniku a prvky strategického plánování Semestrální práce z předmětu KMA/MAB Vypracoval: Tomáš Pavlík Studijní č.: Obor: E-mail: A05205 GEMB - Geomatika pavlikt@students.zcu.cz 1 Úvod Podnikové

Více

Kvalita ve veřejné správě. Ing. Mgr. David Sláma ředitel odboru strategického rozvoje a koordinace veřejné správy Ministerstvo vnitra

Kvalita ve veřejné správě. Ing. Mgr. David Sláma ředitel odboru strategického rozvoje a koordinace veřejné správy Ministerstvo vnitra Kvalita ve veřejné správě Ing. Mgr. David Sláma ředitel odboru strategického rozvoje a koordinace veřejné správy Ministerstvo vnitra Kvalita ve veřejné správě Kvalita ve veřejné správě = míra naplňování

Více

Bezpečnostní politika společnosti synlab czech s.r.o.

Bezpečnostní politika společnosti synlab czech s.r.o. Bezpečnostní politika společnosti synlab czech s.r.o. Platnost dokumentu: 14. ledna 2015 Datum vypracování: 8. ledna 2015 Datum schválení: 13. ledna 2015 Vypracoval: Schválil: Bc. Adéla Wosková, Ing. Jaroslav

Více

Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace

Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace B5 Program Téma obsahuje informace o programech a programovém řízení a klade si za cíl především vysvětlit

Více

Úvod do projektu. Standardizace provozních funkcí ÚSC. Součást projektu Korporátní styl řízení ve veřejné správě

Úvod do projektu. Standardizace provozních funkcí ÚSC. Součást projektu Korporátní styl řízení ve veřejné správě Úvod do projektu Standardizace provozních funkcí ÚSC Součást projektu Korporátní styl řízení ve veřejné správě Měníme zvyky a posouváme mentální bloky POPTÁVKA Tlak na rozpočet, obtížně stanovitelné rozpočtové

Více

SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE

SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE Václav Šebesta Ústav informatiky Akademie věd ČR, e-mail: vasek@cs.cas.cz Abstrakt Jestliže ještě před

Více

BEZPEČNOST IS. Ukončení předmětu: Předmět je zakončen zkouškou sestávající z písemné a doplňkové ústní části.

BEZPEČNOST IS. Ukončení předmětu: Předmět je zakončen zkouškou sestávající z písemné a doplňkové ústní části. BEZPEČNOST IS Předmět Bezpečnost IS je zaměřen na bezpečnostní aspekty informačních systémů a na zkoumání základních prvků vytváření podnikového bezpečnostního programu. Má představit studentům hlavní

Více

Od životních situací ke kompetenčnímu modelu. Bc. František Aubrecht, MBA Ing. Miroslav Vlasák

Od životních situací ke kompetenčnímu modelu. Bc. František Aubrecht, MBA Ing. Miroslav Vlasák Od životních situací ke kompetenčnímu modelu Bc. František Aubrecht, MBA Ing. Miroslav Vlasák Obsah Životní situace Procesní model úřadu Případová studie Magistrát města Kladno Závěr Životní situace -

Více

ARCHITEKTURA INFORMAČNÍCH SYSTÉMŮ PODLE ÚROVNĚ ŘÍZENÍ

ARCHITEKTURA INFORMAČNÍCH SYSTÉMŮ PODLE ÚROVNĚ ŘÍZENÍ ARCHITEKTURA INFORMAČNÍCH SYSTÉMŮ PODLE ÚROVNĚ ŘÍZENÍ Podle toho, zda informační systém funguje na operativní, taktické nebo strategické řídicí úrovni, můžeme systémy rozdělit do skupin. Tuto pyramidu

Více

Zvýšení kvality IA s využitím nových technologií: Představení řešení IDEA - SymSure pro CCM

Zvýšení kvality IA s využitím nových technologií: Představení řešení IDEA - SymSure pro CCM Jaromír Jiroudek Lukáš Mikeska J + Consult Ernst & Young Zvýšení kvality IA s využitím nových technologií: Představení řešení IDEA - SymSure pro CCM Náplň setkání 1. Rychlý úvod do CCM/CPM 2. Představení

Více

Strategické řízení IS Strategické řízení Základní pojmy

Strategické řízení IS Strategické řízení Základní pojmy Strategické řízení IS Základní pojmy Informatika Informatika je multidisciplinární obor, jehoţ předmětem je tvorba a uţití informačních systémů v podnicích a společenstvích a to na bázi informačních a

Více

Zavedení e-learningu

Zavedení e-learningu Zavedení e-learningu Česká pojišťovna snižuje díky e-learningu náklady na školení svých pracovníků Přehled Země: Česká republika Odvětví: Bankovnictví a finance Profil zákazníka Česká pojišťovna a.s. je

Více

Nástroje IT manažera

Nástroje IT manažera Obsah Nástroje IT manažera Školení uživatelů Ochrana osobních údajů Bezpečnostní politika Software a právo Legální software Management jakosti Výběr a řízení dodavatelů Pracovněprávní minimum manažerů

Více

ANALÝZA VAZEB STRATEGIE MĚSTA PRACHATICE VŮČI STRATEGICKÉMU RÁMCI UDRŢITELNÉHO ROZVOJE ČR

ANALÝZA VAZEB STRATEGIE MĚSTA PRACHATICE VŮČI STRATEGICKÉMU RÁMCI UDRŢITELNÉHO ROZVOJE ČR ANALÝZA VAZEB STRATEGIE MĚSTA PRACHATICE VŮČI STRATEGICKÉMU RÁMCI UDRŢITELNÉHO ROZVOJE ČR Analýza byla vypracována týmem Národní sítě Zdravých měst ČR v rámci projektu Analýza vazeb rozvojových strategií

Více

TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE

TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE Tel. +420 543426329 TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE Autor: Vít Chvál Verze dokumentu: 1.0 Datum poslední změny: 18.2.2013 Obsah: 1 Pracovník 3 2 Pracovní činnosti (Náplň práce)

Více

P2: Program rozvoje obce kontext, struktura, tvorba

P2: Program rozvoje obce kontext, struktura, tvorba Elektronická metodická podpora tvorby rozvojových dokumentů obcí (CZ 1.04/4.1.00/62.00008) Část III.b: Postupná realizace vzdělávacích aktivit projektu v řešených územích Dvoudenní vzdělávací kurz TVORBA

Více

Enterprise Architecture na MPSV 23.9.2015

Enterprise Architecture na MPSV 23.9.2015 Enterprise Architecture na MPSV 23.9.2015 Mgr. Bc. et Bc. Robert Baxa, náměstek ministryně Mgr. Jiří Károly, ředitel odboru rozvoje a bezpečnosti ICT Enterprise Architecture (EA) na MPSV Východiska pro

Více

Obsah: Základní pojmy, definice Informační systémy IT architektura Typické aplikační komponenty Implementace aplikací

Obsah: Základní pojmy, definice Informační systémy IT architektura Typické aplikační komponenty Implementace aplikací Monitorovací indikátor: 06.43.10 Počet nově vytvořených/inovovaných produktů Akce: Přednáška, KA 5 Číslo přednášky: 30 Téma: INFORMAČNÍ SYSTÉMY A ARCHITEKTURA IT V PODNIKU Lektor: Ing. Michal Beránek Třída/y:

Více

INFORMACE O ZAVEDENÉM SYSTÉMU KVALITY dle normy ČSN EN ISO 9001:2009 ve společnosti

INFORMACE O ZAVEDENÉM SYSTÉMU KVALITY dle normy ČSN EN ISO 9001:2009 ve společnosti INFORMACE O ZAVEDENÉM SYSTÉMU KVALITY dle normy ČSN EN ISO 9001:2009 ve společnosti Obsah: 1) Adresa společnosti 2) Historie firmy 3) Rozsah systému kvality 4) Systém managementu kvality 5) Povinnosti

Více

Management. Ing. Jan Pivoňka

Management. Ing. Jan Pivoňka Management Ing. Jan Pivoňka Stanovení osobní vize V souladu s kotvou Konkrétní představa Citový náboj Stimul pro aktivní jednání Krátkodobější cíle motivace Výjimky Jasná vize Pohodoví lidé Úspěch bez

Více

Management projektů. Programová podpora auditu sytému managementu kvality HOT 4IT. Plán projektu

Management projektů. Programová podpora auditu sytému managementu kvality HOT 4IT. Plán projektu Management projektů Programová podpora auditu sytému managementu kvality HOT 4IT Plán projektu Historie Verze Datum Status Kdo Poznámka 0.1 8. 4. 2010 Špaček Petr Vytvoření 0.2 11. 4. 2010 Špaček Petr

Více

Informační systémy ve výuce na PEF Information Systems in teaching at the FEM

Informační systémy ve výuce na PEF Information Systems in teaching at the FEM Informační systémy ve výuce na PEF Information Systems in teaching at the FEM Edita Šilerová, Čestmír Halbich, Jana Hřebejková Cíle Předmět Informační systémy je postupně od roku 1994 zařazován na všechny

Více

Audit ICT. KATALOG služeb. Ing. Jiří Štěrba

Audit ICT. KATALOG služeb. Ing. Jiří Štěrba KATALOG služeb Ing. Jiří Štěrba Obsah Úvod 3 Služby 4 Zaměření 5 Nabídka 7 Poptávka 8 Ke stažení 9 Reference 10 Informace 11 Kontakty 12 2 Úvod Dovolte, abychom Vám poskytli informace, které jsou věnovány

Více

Standardy projektového řízení

Standardy projektového řízení Standardy projektového řízení Project Management Body of Knowledge Aktuálně pátá verze Zaštítěn Project Management Institute (PMI) V ČR Česká komora PMI Partner Studentského klub projektového řízení Rozšířen

Více

Faktory ovlivňující řízení podnikové informatiky

Faktory ovlivňující řízení podnikové informatiky Faktory ovlivňující řízení podnikové informatiky Jiří Voříšek katedra informačních technologií Vysoká škola ekonomická v Praze vorisek@vse.cz Proč toto téma? s růstem významu IT pro podnik růst významu

Více

Potřeba vypracovat Strategický plán rozvoje ITS pro ČR

Potřeba vypracovat Strategický plán rozvoje ITS pro ČR Potřeba vypracovat Strategický plán rozvoje ITS pro ČR Roman Srp Sdružení pro dopravní telematiku V Praze dne 23.11.2010 Prezentace pozičního dokumentu pro Ministerstvo dopravy ČR Obsah prezentace Stručně

Více

Personální audit. Audit informačního systému. Audit SW a HW

Personální audit. Audit informačního systému. Audit SW a HW Personální audit Audit informačního systému Audit SW a HW Jméno: UČO: forma studia: ročník: 2014 Brno Úvodní zpráva Konkretizujte předmět auditovaní. Identifikace objektu pozorování. Účel auditu. Stanovené

Více

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT)

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Charta projektu má za cíl poskytnout úplné a pevné informační základy pro schválení projektu. Následně je Charta projektu rozpracována do

Více

EXTRAKT z české technické normy

EXTRAKT z české technické normy EXTRAKT z české technické normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním 35.240.60 materiálem o normě. Komunikační infrastruktura pro pozemní mobilní zařízení (CALM) Architektura

Více

POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ

POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ ŽIVOTNÍ CYKLUS IS Stejně jako stroje a technologické linky, které jsou pořízeny, provozovány a následně, po opotřebování vyřazeny, má i informační systém svůj

Více

Marketingový plán základ podnikatelského plánu část 2. MUDr. Jan Šrogl 21.5.2013

Marketingový plán základ podnikatelského plánu část 2. MUDr. Jan Šrogl 21.5.2013 Marketingový plán základ podnikatelského plánu část 2 MUDr. Jan Šrogl 21.5.2013 Doporučená struktura I. Titulní strana II. Shrnutí plánu (executive summary) III. Popis Vaší společnosti IV. Popis vašeho

Více

Příspěvek je věnován základním informacím o způsobu volby vhodné strategie řízení kontinuity činností v organizaci.

Příspěvek je věnován základním informacím o způsobu volby vhodné strategie řízení kontinuity činností v organizaci. Mgr. Monika Johaníková Ochrana & Bezpečnost 2013, ročník II., č. 3 (podzim), ISSN 1805-5656 Stanovení strategie řízení kontinuity činností Anotace Příspěvek je věnován základním informacím o způsobu volby

Více

Logický rámec projektu (Logical Framework Matrix LFM)

Logický rámec projektu (Logical Framework Matrix LFM) Logický rámec projektu (Logical Framework Matrix LFM) Při přípravě, realizaci, monitorování a hodnocení programů a projektů se obvykle uplatňuje ve vyspělých zemích i v mezinárodních organizacích (EU,

Více

TOGETHER WE CAN projekt interních koučů v UniCredit Bank

TOGETHER WE CAN projekt interních koučů v UniCredit Bank TOGETHER WE CAN projekt interních koučů v UniCredit Bank Firma: UniCredit Bank Czech Republic, a.s. Na Příkopě 858/20 111 21 Praha 1 www.unicreditbank.cz Kontaktní osoba: Lenka Štěpánová Learning & Development

Více

End-to-end testování. 26. dubna Bořek Zelinka

End-to-end testování. 26. dubna Bořek Zelinka End-to-end testování 26. dubna 2013 Bořek Zelinka Bořek Zelinka Unicorn Systems, Test architekt Unicorn, 2004 Testování Quality Assurance ČVUT, Fakulta stavební, 2004 2 Agenda Princip end-to-end testů

Více

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Microsoft SharePoint Portal Server 2003 Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Přehled Země: Česká republika Odvětví: Velkoobchod Profil zákazníka

Více

Příručka jakosti a environmentu

Příručka jakosti a environmentu Příručka jakosti a environmentu Datum platnosti: Datum účinnosti: Změna: 1.5.2005 1.5.2005 0 Dne: 13.4.2005 Dne: 25.4.2005 1 / 6 O B S A H : 1. Úvod 3 2. Oblast použití systému řízení 3 3. Politika 3 4.

Více

Struktura Pre-auditní zprávy

Struktura Pre-auditní zprávy Příloha č. 1 k Smlouvě o Pre-auditu: Struktura Pre-auditní zprávy 1. Manažerské shrnutí Manažerské shrnutí poskytuje nejdůležitější informace vyplývající z Pre-auditní zprávy. 2. Prohlášení o účelu a cílů

Více

HR controlling. Ing. Jan Duba HRDA 26.9.2014

HR controlling. Ing. Jan Duba HRDA 26.9.2014 HR controlling Ing. Jan Duba HRDA 26.9.2014 Anotace Zkušenosti s nastavováním systému měření výkonu pracovních skupin a jednotlivců Jak zavést živý controlling pro řízení firmy? Anotace Interim HR manažer

Více

Management kvality cesta k udržitelnému rozvoji cestovního ruchu. Ing. Jiří Sysel Citellus, s.r.o.

Management kvality cesta k udržitelnému rozvoji cestovního ruchu. Ing. Jiří Sysel Citellus, s.r.o. Management kvality cesta k udržitelnému rozvoji cestovního ruchu Ing. Jiří Sysel Citellus, s.r.o. Pojetí kvality Kvalita patří mezi základní filosofické kategorie, ale v současném ekonomickém a manažerském

Více

Rizika na liberalizovaném trhu s elektřinou

Rizika na liberalizovaném trhu s elektřinou Rizika na liberalizovaném trhu s elektřinou Fórum užívateľov prenosovej sústavy, Košice 27. a 28.3.2003 Tento dokument je určen výhradně pro potřebu klienta. Žádná jeho část nesmí být zveřejněna, citována

Více

Zdravotnická informatika z pohledu technických norem ISO a EN. RNDr. Vratislav Datel, CSc. Praha 26. dubna 2011

Zdravotnická informatika z pohledu technických norem ISO a EN. RNDr. Vratislav Datel, CSc. Praha 26. dubna 2011 Zdravotnická informatika z pohledu technických norem ISO a EN RNDr. Vratislav Datel, CSc. Praha 26. dubna 2011 Co je technická norma? Technická norma je dokumentovaná úmluva obsahující technické specifikace

Více

Přednáška č.13. Organizace firmy při zahraniční činnosti

Přednáška č.13. Organizace firmy při zahraniční činnosti Přednáška č.13 Organizace firmy při zahraniční činnosti Organizační struktura Organizační struktura je vedením určený systém hierarchicky rozčleněných míst, útvarů, skupin (organizačních jednotek). Cílem

Více

Řízení Lidských Zdrojů

Řízení Lidských Zdrojů Katedra Řízení Podniku Řízení Lidských Zdrojů Ing. Miloš Krejčí milos.krejci@mail.vsfs.cz Řízení Lidských Zdrojů 1. Řízení lidských zdrojů jako součást podnikové strategie 2. Řízení Lidských Zdrojů Řízení

Více

A. Návrhy na nové aktivity v roce 2015:

A. Návrhy na nové aktivity v roce 2015: AKČNÍ PLÁN ZLEPŠOVÁNÍ PROCESU MÍSTNÍ AGENDY 21 Co je Akční plán zlepšování procesu místní Agendy 21? Součástí každé metody modernizace veřejné správy, každého úspěšného procesu, je formulace přehledného

Více

Modelový program výcviku manažerů

Modelový program výcviku manažerů Modelový program výcviku manažerů (se specifickým zaměřením na prvoliniový management) CÍL VÝCVIKU... 2 METODY VÝCVIKU... 2 NÁPLŇ VÝCVIKU... 2 1. ROLE A OSOBNOST SUPERVIZORA (= PRVOLINIOVÉHO MANAŢERA)

Více

Vstupní analýza absorpční kapacity OPTP. pro programové období 2014 2020

Vstupní analýza absorpční kapacity OPTP. pro programové období 2014 2020 Manažerské shrnutí 1 Výstup zpracovaný k datu: 10. 2. 2014, aktualizace k 7.5. 2014 Zpráva zpracována pro: Ministerstvo pro místní rozvoj ČR Staroměstské náměstí 6 110 15 Praha 1 Dodavatel: HOPE-E.S.,

Více

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Architektury Informačních systémů Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Nutné pojmy Co je to informační systém? Jaké oblasti zahrnuje? Jaká je vazba IS na podnikovou strategii?

Více

Normy a systémový přístup k zavádění, provozování a evaluaci ICT systémů pro výuku, vzdělávání a školení. Josef Myslín katedra informatiky VŠMIEP

Normy a systémový přístup k zavádění, provozování a evaluaci ICT systémů pro výuku, vzdělávání a školení. Josef Myslín katedra informatiky VŠMIEP Normy a systémový přístup k zavádění, provozování a evaluaci ICT systémů pro výuku, vzdělávání a školení Josef Myslín katedra informatiky VŠMIEP E-learning? E-learning se stává stále oblíbenějším prostředkem

Více

Informace a znalosti v organizaci

Informace a znalosti v organizaci Informace a znalosti v organizaci Vladimíra Zádová Postavení informací a znalostí z hlediska úspěšnosti firmy Vnitřní faktory Rámec 7S faktorů úspěchu firmy [ Mc Kinsey ] Struktura Strategie Systémy Spolupracovníci

Více

Výhody a rizika outsourcingu formou cloud computingu

Výhody a rizika outsourcingu formou cloud computingu Výhody a rizika outsourcingu formou cloud computingu Jiří Voříšek katedra informačních technologií Vysoká škola ekonomická v Praze vorisek@vse.cz 1 Výchozí model MMDIS pro identifikaci možností outsourcingu

Více

Aktuální otázky provozu datových skladů PAVEL HNÍK

Aktuální otázky provozu datových skladů PAVEL HNÍK Aktuální otázky provozu datových skladů PAVEL HNÍK K čemu slouží datové sklady IT podporuje business podniků S velikostí podniku se zvyšuje náročnost zpracování dat DWH = unifikovaná datová základna pro

Více

QUO VADIS ICT. z pohledu ICZ. Roman Zemánek, obchodní ředitel ICZ a.s., Praha, 25. září 2014

QUO VADIS ICT. z pohledu ICZ. Roman Zemánek, obchodní ředitel ICZ a.s., Praha, 25. září 2014 QUO VADIS ICT. z pohledu ICZ Roman Zemánek, obchodní ředitel ICZ a.s., Praha, 25. září 2014 Dokument: Informační prezentace Důvěrnost: Veřejná www.i.cz 1 ZÁKLADNÍ ÚDAJE Společnost zaloţena 1997 Jediný

Více