Integrace dvou společností z hlediska IT architektury

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

Download "Integrace dvou společností z hlediska IT architektury"

Transkript

1 Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování Integrace dvou společností z hlediska IT architektury Diplomová práce Autor: Aleš Radoměřský Informační technologie a management Vedoucí práce: doc. Ing. Stanislav Horný, CSc. Praha Duben, 2009

2 Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně s použitím uvedené literatury. V Praze dne 15. dubna 2009 Aleš Radoměřský

3 Poděkování: Rád bych touto cestou poděkoval doc. Ing. Stanislavu Hornému, CSc., za odborné vedení a cenné připomínky v průběhu zpracování mé diplomové práce. Dále bych rád poděkoval zástupcům společností IBM Česká Republika a IDS Scheer za poskytnutí materiálů a cenných rad při popisu metodik. Také bych rád poděkoval zaměstnancům obou společností za vstřícnost a ochotu, kterou projevili při četných diskuzích na toto téma.

4 Anotace práce: Práce pojednává o integraci dvou společností z hlediska IT architektury. V úvodní části je vysvětlení cíle, který má integrace přinést dotčeným společnostem. Dále následuje seznámení se s různými metodikami, které lze pro tuto aktivitu použít. Z různých metodik bylo vybráno využití řešení CBM (Component Business Model) společnosti IBM jako referenční pro tuto aktivitu. V práci byla provedena analýza v obou společnostech z hlediska procesů, aplikační architektury a částečně také infrastruktury v oddělení IT a bylo navrženo cílové řešení. Detailně pak byla analyzována aktivita sloučení digitálního archivu. V závěru práce se vyhodnocuje finanční výhodnost jednotlivých aktivit, je zde poukázáno na kritická místa integrace a zvažuje se, jakými způsoby je možné k integraci přistoupit. Annotation: This work deals with the integration of two companies from the point of view of IT architecture. Introductory part presents the explanation of the goal, which the integration is to bring to the companies in question. Afterwards, an overview follows of various techniques and methods which can be used for this activity. Out of many alternatives it was chosen the solution CBM (Component Business Model) by the IBM company as reference for this activity. In this diploma work the IT analysis was undertaken in both companies from the point of view of processes, application architecture and partly also infrastructure in the IT department, and the final solution was suggested. Then the merger of the digital archive was analyzed in detail. At the end of the thesis there is a balance of financial convenience of the single activities, critical moments of integration are pointed out and the suitable ways how to approach integration are considered.

5 Úvod Seznámení se záměrem a strategií integrace Metodiky a možnosti řešení Metodika IBM Metodika společnosti IDS Scheer Framework TOGAF Definice postupu v řešení IT architektury Analýza současného stavu IT Představení společností z pohledu organizace IT Organizační struktura Základní procesy IT Analýza základních oblastí Infrastruktura Aplikační portfolio Návrh budoucí IT architektury společnosti Definice rychlých kroků vedoucích k finančním úsporám Cílová organizace IT Cílová SW architektura Cílová infrastruktura Návrh časového plánu integrace z pohledu IT Detailní analýza vybrané oblasti a návrh řešení Předpoklady a omezení řešení Popis výchozího a budoucího stavu Popis procesů Navrhované obchodní procesy Navrhované technické procesy Rizika definice Návrh řešení Návrh a popis změněných komponent Přehled funkčnosti nových komponent a zasažených IT systémů Popis procesů digitálního archivu Analýza dopadu Návrh projektového harmonogramu v dalších fázích Finanční dopad integrace Finanční dopad integrace IT architektury Náklady a finanční úspory zavedení jednotné digitalizace Závěry a doporučení Seznam použité literatury Seznam obrázků Seznam tabulek Seznam schémat Seznam grafů Seznam příloh Seznam používaných zkratek... 89

6 Úvod Téma diplomové práce, kterou jsem si zvolil, zní Integrace dvou společností z hlediska IT architektury. Akvizice různých společností je zvláště v dnešní době poměrně častý jev a téměř každá společnost má vlastní IT oddělení, nebo alespoň vlastní počítačové systémy, které bývají velice specifické, neboť poskytuje služby ostatním částem společnosti šité přímo dle jejich potřeb. Právě slučování IT služeb bývá často alfou a omegou v úspěchu plánované akvizice. Toto téma jsem si zvolil s ohledem na skutečnost, že je mně velice blízké, protože jsem byl od mého zaměstnavatele pověřen úkolem podílet se na integrační aktivitě dvou společností. V rámci projektového týmu jsem měl přímou zodpovědnost za definici cílové aplikační architektury a za odhad implementačních nákladů z hlediska aplikací. Tento úkol byl pro mě velkou výzvou, neboť jsem do této doby neměl s takto rozsáhlým integračním projektem bližší zkušenost, takže jsem toto uvítal jako příležitost rozšíření svých znalostí v této oblasti. Vzhledem k velice citlivým údajům jsem záměrně neuvedl, o jaké pojišťovací společnosti se jedná, a také některé názvy neodpovídají realitě. Číselné hodnoty jsou zcela zkresleny tak, aby nebyly zveřejněny interní čísla společností, nicméně jsem zachoval jejich vzájemné poměry, neboť tyto poměry vysvětlují některá rozhodnutí. Práci jsem rozdělil do následujících základních oddílů: Souhrn některých metodik, které se dají při integraci využít. Analýza současného stavu v obou IT. Návrh cílové struktury IT. Detailní analýza integrační aktivity sjednocení digitálního archivu. Finanční dopad integrace. Po úvodním seznámení se záměrem a omezeními, které zadavatel tohoto úkolu definoval, seznámím čtenáře se základy interní metodiky společnosti IBM, možným řešení pomocí 6

7 nástrojů společnosti ARIS a případně možnosti využití frameworku TOGAF. Pro následné řešení integrace v oblasti aplikační architektury byla zvolena interní metodika IBM. V druhém oddílu provedu analýzu obou IT oddělení rozdělenou na pohled infrastrukturní a aplikační. Taktéž popíši organizační členění jednotlivých oddělení a zmapuji základní principy fungování oddělení. Ve třetím oddílu této diplomové práce bude navržena cílová IT architektura společnosti. Navrhnu organizační strukturu, možnou cílovou aplikační architekturu, jejichž jednotlivé integrační kroky se budou muset potvrdit v úvodní studii každého projektu. Dále bude vytvořen návrh harmonogramu integračních aktivit. Následovat bude oddíl detailní analýzou vybrané integrační aktivity, pro kterou jsem si vybral sjednocení digitalizace dokumentů obou společností. Nejdříve popíši výchozí stav v této oblasti včetně předpokladů a omezení budoucího řešení, rizik a základních procesů. Poté navrhnu cílové řešení s dopadem na jednotlivé komponenty. V rámci tohoto projektu jsem byl opět zodpovědný za definici stávající architektury a následný návrh řešení vhodně zakomponovaného mezi všechny systémy. V závěru práce uvedu finanční dopad integrace. Porovnám provozní náklady na jednotlivé oblasti před plánovanou integrací a očekávané náklady po integraci. Také provedu odhad migračních nákladů k jednotlivým částem. Některá vložená schémata, grafy a obrázky jsou poměrně podrobná, proto jsem je také umístil v elektronické podobě na CD, kde je možné si případně prohlédnout detaily. 7

8 1. Seznámení se záměrem a strategií integrace Po zveřejnění záměru sloučit dvě pojišťovací společnosti v jeden holding vyvstala celá řada otevřených otázek, jak toto bude provedeno, které systémy budou zachovány, atd.. Byla vytvořena tzv. integrační kancelář, která měla za úkol všechny aktivity koordinovat a definovat také cíle integrace. Jedna z oblastí, které se sloučení výrazně dotýkalo, měla být samozřejmě informatika. Celý projekt byl rozdělen do několika samostatných subprojektů z pohledu potřeb odborných oddělení. Informatika se oficiálně měla zabývat IT architekturou, ale samozřejmě IT přímo zasahuje do dalších obchodních oblastí pojišťoven, např. digitalizace (sjednocení digitálního archivu a práce s digitálními dokumenty), Call- Centrum (sjednocení call-centra do jednoho, což mělo zásadní vliv na využívané aplikace), Účtárna, Platební styk, Životní pojištění a Neživotní pojištění. Z integrační kanceláře jednoznačně zaznělo, co je cílem tohoto projektu pro IT: o Navržení cílové IT organizace. o Konsolidace IT architektury na základě výstupů z ostatních obchodních projektů a zohlednění základních postulátů. o Snížení nákladů zejména v oblasti IT v krátkodobém horizontu, řádově týdnech. Po zvážení možností jsme se rozhodli požadovanou částku uspořit v části Infrastruktury. o Systémové snížení nákladů v průběhu 5 let. Naopak zde je značná příležitost k redukci nákladů v oblasti aplikačního portfolia a jeho optimalizace. Na schématu č. 1. vidíme organizační schéma celého projektu včetně načasování. Jak je z obrázku patrné, tak ve stejný čas začínají pracovat odborná oddělení na optimalizaci procesů a téměř zároveň startuje aktivita optimalizace aplikační architektury. Toto nelze považovat za šťastné řešení, protože při definici cílové aplikační architektury musí být plně respektovány požadavky odborných oddělení, které se však připravují ve stejnou dobu a tudíž nebudou k dispozici potřebné požadavky pro IT architekturu. Reálně tedy bude mít tým architektury jeden měsíc na přípravu všech podkladů a návrhu řešení. Abychom dokázali vše připravit v požadované kvalitě a rozsahu, budeme se průběžně účastnit ostatních aktivit a zjišťovat jejich požadavky na cílové řešení. Tímto dokážeme eliminovat nejasné zadání pro tým IT architektury. Samostatnou kapitolou je obchodní tým. Základní myšlenka je neslučovat společnosti z pohledu obchodních aktivit. V České Republice 8

9 budou nadále působit dvě společnosti, které se z pohledu klienta budou odlišovat. Proto je v této části možné sloučit pouze podpůrné procesy. Schéma č. 1: organizační schéma integračních aktivit Zdroj: vlastní znalosti Současně se zadáním byla definována jasná strategie v oblasti IT. Cílem je mít jednoduché aplikační portfolio, které umožní pružně reagovat na potřeby odborných oddělení při snížení nákladů, které v horizontu třech let znamenají roční úsporu 30% ze současných nákladů. Při první schůzce našeho projektového týmu jsme se shodli, že se rozdělíme do třech pracovních skupin dle zaměření, tj. Infrastruktura, Aplikační architektura a Organizace. Část infrastruktury bude popisovat vše ohledně hardware včetně otázky ohledně licencí. U aplikační architektury, jak již název vypovídá, bude záměr popsat aplikační portfolia a navrhnout jejich optimalizaci. Závěrečná skupina bude řešit zejména personální otázky včetně návrhu budoucí organizační struktury. Tyto skupiny spolu samozřejmě musí úzce spolupracovat. 9

10 2. Metodiky a možnosti řešení V následující kapitole popíši možnosti, jakými způsoby je možné pojmout mapování architektury, a na základě získaných informací doporučí náš projektový tým nejvhodnější způsob řešení. Architektura je prostředkem, jak zachytit a popsat role na straně IT a také na straně businessu. Aby IT/ICT plně podporovala podnikové procesy, což je základní požadavek na ni kladený, musí se při jejím popisu pamatovat na celou řadu hledisek a vazeb. Pohled na architekturu se postupně vyvíjel dle požadavků na informace a jejich zpracování. Z historického pohledu jako první architektura byla technologická, což znamenalo uspořádání technologií do vhodného a navzájem komunikujícího systému. Dále se pak architektura rozšířila o pohled na aplikace pro podporu businessu. V této etapě se začal používat výraz IS/ICT architektura, která spojovala architekturu technologickou, aplikační a informační. Dalšími významnými důvody pro vznik architektury jsou kvalitativní změny v ICT (vznik distribuovaných systémů a distribuovaného zpracování dat, příchod objektového přístupu), změny v ekonomice (globalizace, fůze a akvizice) a nové legislativní požadavky. V dnešní době je klíčové propojení architektury s business architekturou. Toto nazýváme Enterprise Architecture (EA). Vlastní popis a návrh architektury je velice náročný úkol. Proto vznikly různé architektonické rámce, což v podstatě znamená různé přístupy k návrhu a realizaci architektury. Architektonické rámce dělíme na klasifikační, procesní a obsahové. Klasifikační rámce nám umožňují systém rozdělit na jednotlivé pohledy, které nám umožní sledovat potřebnou doménu. Velice často je zobrazení prováděno formou matice. Tento způsob mapování je použit v metodice IBM. Procesní rámce se zabývají popisem postupu při řízení životního cyklu. Do této kategorie patří například TOGAF a metodika od IDS Scheer. Posledním rámcem je rámec obsahový. Tyto rámce jsou úzce spjaté s nějakým oborem a s větším detailem doplňují rámce procesní a klasifikační. Obsahový rámec může být například zaměřen na telekomunikace, bankovnictví apod. Popis Entrerpise Architecture zahrnuje analýzu původního stavu, popis stavu budoucího, ve kterém musí být zohledněny požadavky organizace, a popis transformace ze stavu původního na stav cílový. V závislosti na použitém rámci je popisována řada pohledů. Mezi nejčastější patří business, aplikační, informační/datový a technologický pohled. 10

11 Business pohled nám vyjadřuje, jaká je vize společnosti a jaké požadavky jsou kladeny pro podporu splnění vize. V pohledu aplikačním popisujeme aplikace, systémy a jejich vzájemné propojení. Informační a datový pohled obsahuje informaci s jakými informacemi a daty musíme pracovat, abychom splnili očekávání z pohledu business. Závěrečný technologický pohled nám popisuje technologickou infrastrukturu, která musí vyhovovat informačním systémům. Tyto pohledy jsou propojeny celou řadou vazeb, které jsou zachyceny v metamodelu. Mezi tyto vazby patří například fakt, že obchodní požadavky přímo ovlivňují aplikační architekturu (použité aplikace), dále pak ovlivňuje požadavky na informační pohled (data a informace). Následně informační architektura nám předurčuje, jaké využijeme technologie. Například jaké musíme zvolit datové úložiště pro specifické potřeby. Rád bych na tomto místě zmínil, že samotné zvolení jedné metodiky nevede automaticky k úspěšnosti záměru. Vždy je nutné doplnit metodiku skutečnými odborníky v dané oblasti, jejichž kombinace zaručuje úspěšnost aktivity. Dané metodiky poslouží převážně jako vodítko k udržení zvoleného postupu. Při jejich implementaci dochází k menším úpravám, zohledňujícím specifické požadavky a tím může v podstatě vznikat vlastní jedinečná metodika. 2.1 Metodika IBM Metodika IBM má typicky tři fáze, viz obrázek č. 1. První je analýza současného stavu, která vychází z obchodní strategie. K této analýze se využívá grafického znázornění obchodního modelu s cílem identifikovat důležité komponenty, kterými se budeme primárně zabývat. V druhé fázi se definuje cílový stav a cílová architektura. Definujeme zde nové požadavky na komponenty a jejich schopnosti a provádíme analýzu dopadu. Třetí fáze je již fáze návrhu konkrétních projektů, které by se měli realizovat včetně nákladů. Standardní metodika IBM má dva CBM 1, jeden vyjadřuje referenční model pro životní pojišťovny a druhý pro neživotní. Samozřejmě je možné tyto dva modely sloučit do jednoho univerzálního. 1 Zkratka CBM znamená Component Business Model 11

12 Obrázek č. 1: Základní schéma metodiky IBM Zdroj: Interní materiály Component Business Model pro Business IT, společnosti IBM Nyní se pokusím přiblížit zmíněný model CBM. Graficky je znázorněn na obrázku č. 2. Jak bývá poměrně obvyklé u konzultačních rámců, je model dvojrozměrný. Sloupce představují obchodní domény. Řádky pak odpovídají úrovni uskupení v organizaci. Tyto uskupení jsou pak rozděleny do třech oblastí: Strategická (Direct), Taktická (Control) a Provozní (Execute). Strategická část, jak již sám název napovídá, má za úkol definovat vlastní strategii a strategické záměry. Část taktická napomáhá naplňovat strategické cíle, což můžeme také definovat jako měření odchylek od definovaných výkonnostních úkolů a na tomto základě přijímat rozhodnutí kam může provoz směřovat. Třetí část popisuje vlastní provoz a nástroje k němu určené. Jednotlivé funkční domény jsou rozloženy do několika bloků, které se nazývají komponenty. Záměrem je rozložit komplexní složitý pohled na společnost do několika částí, čímž dosáhneme zjednodušení pohledu a zmíněná složitost zůstává na pozadí. Na jednotlivých komponentách je, aby si spravovaly vlastní zdroje a aby byly vlastníky 12

13 vybraných obchodních aktivit. Každá komponenta je pak určena k tomu, aby naplňovala nějaký obchodní účel společnosti. Obrázek č. 2: Referenční model CBM Zdroj: Interní materiály Component Business Model pro Business IT, společnosti IBM K lepšímu pochopení může posloužit trojrozměrný CBM na obrázek č. 3, kde si můžeme trojrozměrně představit jednotlivé komponenty, kde se na obchodní úrovni bavíme jen o obchodních aktivitách, které však musí být podporovány aplikační architekturou v širším slova smyslu, čímž jsou míněny nejen aplikační systémy, ale také organizační struktura a obchodní procesy. Tyto veškeré části musí mezi sebou komunikovat a proto je zde znázorněna vrstva zajišťující konektivitu. Pod tím vším figuruje společná základna, což znamená infrastruktura. Naskýtá se zde otázka, jaký je vztah mezi komponentou a procesem. V podstatě se jedná o kolmý pohled na věc. Společnosti se dnes často zabývají optimalizací procesů, což však nijak nenahrazuje skutečnost, že každá společnost je řízena primárně po své funkční linii a jsou zde definovány specifické role, které naplňují činnost společnosti a to jsou v tomto případě jednotlivé komponenty. Naproti tomu jsou procesy, 13

14 které jdou napříč společností a tyto procesy jsou vlastně jediné místo, kde lze měřit nějakou přidanou hodnotu, což typicky neplatí u komponent. Komponenty můžeme také chápat jako soubor obchodních funkcí. CBM slouží k uchopení složitosti daného problému a k barevné vizualizaci, jak v jednom schématu zachytit klíčové dimenze. Obrázek č. 3: Trojrozměrný pohled na CBM Zdroj: Interní materiály Component Business Model pro Business IT, společnosti IBM, vlastní úpravy Často se setkáváme s následujícími úrovněmi členění: První způsob členění spočívá v zachycení kompetencí jednotlivých komponent do třech úrovní činností. První úrovní rozumíme činnosti, které sice společnost zajišťuje, nicméně v nich nevidí významnou konkurenční výhodu. V podstatě se jedná o činnosti, které společnost musí dělat, aby mohla fungovat. Můžeme takto například označit účetnictví (neuvažujeme-li zrovna o společnosti, kde je provádění účetnictví předmětem jejich podnikání). Druhou úrovní jsou činnosti, kde se společnost cítí srovnatelná s konkurencí na trhu. Třetí úroveň jsou činnosti, které jsou všeobecně vnímány jako ty, které výrazně odlišují danou společnost na trhu. Jiný možný pohled na členění je přes výnosy rozdělené na nízké, střední a vysoké. Velice podobný pohled na členění jako v předchozím bodě je členění dle nákladů. 14

15 Také je možné složit pohledy výnosové, nákladové a kompetenční a zvýraznit zde komponenty, které jsou problémové a kterým se budeme v budoucnu věnovat. V následující části jsou popsány jednotlivé sloupce v CBM, opět se vracíme k obrázku č. 2 a při vyplňování je dobré mít na paměti členění řádků na strategickou, taktickou a provozní část: Product Management: Zde zaznamenáváme vše, co se týká vývoje produktů od strategického vývoje, přes analýzu produktů, strategie trendů společností, až po analýzu trhu. Toto se týkalo strategického řízení. Na úrovni taktického řízení je ekonomika, výkonnost a marketing. Marketingem je například myšleno řízené uvádění produktu na trh. V provozní části již můžeme vidět konkrétní detaily návrhu produktů, definice a parametry, které s vývojem souvisí. Risk Management: Je zde uvedeno vše, co se dotýká řízení rizika a to nejen k danému produktu, ale i věcí které s těmi věcmi souvisí. Business Acquisition and Channel Management: Zachycujeme zde vše, co se týká získávání nových klientů a správy odbytových cest. Dále se zde například řeší provize, definice jejich výplat. Policy: V této části zaznamenáváme vše, co se dotýká pojistných smluv, jejich správy, strategie v uzavírání pojistných smluv, oblast tisků a digitalizace. Policyholder / Affiliated Party: Zde zmiňujeme informace týkající se pojistníků, makléřů, agentů. Jako příklad je možné uvést kontaktní centrum. Policy Benefits / Claims: V tomto sloupci jsou například uvedeny informace týkající se likvidace pojistných událostí a vypořádání se s klientem, příjem hlášení o pojistné události. Cash Flow: Zde zaznamenáváme informace o inkasu (přijatých platbách do společnosti), exkasu (vyplacených platbách ze společnosti) a fakturaci. Financial Management: Zaměřujeme se zde na reporting, investice, management, finanční správu. Dále zde řešíme naplňování regulatorních požadavků směrem k České národní bance. Business Administration and Infrastructure: zde najdeme vše, co se dotýká řízení společnosti jako jsou veškeré účetní funkce, audity, reporty. Jednou z komponent, kterou má metodika IBM rozkreslenu do samostatné komponentní mapy je IT oblast. Dále zde najdeme personalistiku, vztah s veřejností, bezpečností služby, školení. 15

16 O jednu úroveň níže, nebo chceme-li hlouběji, v rámci této metodiky je tzv. Component Business Model pro Business IT (CBM-BoIT). Znázorněno na obrázku č. 4. IBM doporučuje tento model jako metodiku pro definici současného stavu a identifikaci možných základních oblastí IT pro modifikaci. Dokáže se dle této metodiky optimalizovat IT portfolio, vytvořit nové strategie, nastavit priority investic a navrhnout cílovou organizaci. Tento model je výstupem z IBM frameworku, obsahujícího IBM IT procesní model, IT infrastrukturní knihovnu a IT procesního modelu služeb. Opět se zde setkáváme s protínáním tří úrovní aktivit s rozdílnými zodpovědnostmi. Tři základní úrovně aktivit (plánování a řízení, rozvoj a provoz) se dále dělí na sedm klíčových komponent, které reprezentují klíčové oblasti. IT Customer Relationship Management: Tato komponenta slouží jako převod mezi obchodním a technickým oddělením. Určuje interní a externí trh, kterému jsou poskytovány servisy. IT Business Management: Komponenta sloužící pro definici dopadu jednotlivých IT rolí do obchodní části zaručující jasné pochopení situace. Jsou zde například definovány principy vedení IT. Business Resilience: Snaží se zajistit potřeby rozvoje s ohledem na předem definované regulace, dále zajišťuje, aby byla strategie realizována společně s infrastrukturou ve stejný čas. Information and Knowledge Management: Zde se definuje zodpovědnost za zásadní rozvojové přínosy a znalostní management IT funkcí. Service and Solution Development: Zde je zodpovědnost za rozvoj klíčových aktivit. Tyto nové aktivity by měly vést ke vzniku nových řešení, nových servisních služeb. Service and Solution Deployment: Tato část reprezentuje zodpovědnost za včasné nasazení změn do produkčního prostředí s minimálním narušením obchodních procesů. Service Delivery and Support: Zde je zodpovědnost za dennodenní provoz a za řešení uživatelské podpory. 16

17 Obrázek č. 4: Component Business Model pro Business IT Zdroj: Interní materiály Component Business Model pro Business IT, společnosti IBM, vlastní úpravy Další pomůckou používanou v rámci metodiky IBM je tzv. zdravotní dotazník. V podstatě se jedná o formulář detailně popisující danou aplikaci. Záměrem je takto popsat aplikace v každé společnosti, které pokrývají shodnou oblast a tím dostat jednotné měřítko na porovnání. Popisem se myslí ohodnocení jednotlivých otázek dle předdefinované klasifikace. Zdravotní dotazník je rozdělen do pěti základních oblastí, což jsou funkcionality, úroveň integrace, ohodnocení provozu, uživatelského pohledu na aplikaci a systémových informací. Každá vybraná osoba hodnotí aplikaci a danou oblast známkou od jedničky (nejhorší) do pětky (nejlepší). Malé úskalí tohoto dokumentu je oblast uživatelského pohledu, u které může vyplňující osoba často vyjadřovat subjektivní pohled na aplikaci. Tomuto je vhodné předejít tím, že se omezí skupina osob, která tuto část vyplňuje. Tato menší skupina je pak společně proškolena nad použitím dotazníku, aby všichni měli co nejvíce shodné měřítko. Zdravotní dotazník je uveden v příloze č

18 2.2 Metodika společnosti IDS Scheer Jedna z možností, jakým způsobem mapovat a následně navrhnout cílovou aplikační strukturu informatiky, je za podpory metodiky ARIS od společností IDS Scheer. Autorem této metodiky je profesor A.W.Scheer. Tato metodika je velmi propojena se stejnojmenným nástrojem. Hned na začátku je nutné připomenout, že cílová architektura musí podporovat celkovou strategii podniku. Abychom tuto metodiku mohli použít, je nezbytné se seznámit s pojetím managementu IT architektury a terminologií ARIS 2. Můžeme se setkat s vysvětlením, že se jedná o framework 3 pro popis společnosti a aplikačního software. Základní části architektury je možné rozdělit na služby, vlastní data, funkce, organizaci a procesy, viz obrázek č. 5. Obrázek č. 5: Základních částí architektury ARIS Zdroj: Interní materiály Designing and Improving Enterprise Architectures with ARIS IT Architect, společnosti IDS Scheer IDS Scheer má propracovaný architektonický model pro management IT architektury. Ten se skládá ze šesti základních map: mapa business procesů, mapa organizační struktury, mapa informační architektury, mapa aplikační architektury, mapa podpůrných procesů a mapa projektů. Každá z těchto pěti základních pohledů je rozdělena do tří úrovní. Úroveň věcná, úroveň zpracování dat a úroveň implementace systému. V první části se popisují všechny business procesy a to od nejvyšší úrovně do nejnižší. Při popisu procesů jsou rozeznávány následující komponenty: událost, funkce, data, zaměstnanec, organizační jednotka a produkt/služba. Ukázka takového procesu je uvedena v příloze č. 2. Následně se vytvoří organizační struktura, čímž je míněno schéma všech organizačních jednotek 2 Pojem ARIS je zkratka z anglického textu Architecture of integrated information system. 3 Framework je SW struktura sloužící jako podpora při programování. Její součástí jsou často různé pomocné programy, knihovny a vzory [zdroj: , 17:40] 18

19 a jejich hierarchické propojení. V následujícím kroku je nutné zmapovat informační architekturu, což zjednodušeně znamená schéma využitých technologií a platforem. Aplikační architektura znamená seznam všech používaných aplikací, jejich hierarchické propojení a přehled základních funkcionalit. Vše je mapováno na jednotlivé komponenty, které rozeznáváme softwarové, hardwarové a směrnice. Např. softwarové komponenty je možné rozdělit do oblastí, které reprezentují vývojové nástroje, nebo ERP 4 systémy. Ukázka takového znázornění, které jsem se pokusil za jednu společnost vytvořit v nástroji ARIS je uvedena v příloze č. 3. Podpůrné procesy mapují vazby mezi IT systémy, procesy a organizačními jednotkami. V podstatě základním krokem v této metodice je tvorba logického konceptu systému. Nástroje ARIS obsahují celou řadu technik a nástrojů, které tvoří přímou podporu metodice. Nástroje lze rozdělit do třech skupin. První je ARIS Design platform, což je nástroj pro modelování a návrh. Následují nástroje ve skupině ARIS Implementation platform, které slouží pro vlastní implementaci. Třetí velkou skupinou je ARIS Controlling platform zabývající se optimalizací a řízením podnikových procesů. Po detailnějším seznámení s nástroji ARIS od společnosti IDS Scheer se domnívám, že se tyto nástroje dají velice vhodně použít např. pro zmapování business procesů a jejich reengineering 5, ale již neposkytují dostatek možností pro vyhodnocení optimální cílové IT architektury. Z tohoto důvodu jsem nedoporučil použít pro náš záměr tyto nástroje. 2.3 Framework TOGAF TOGAF je metodický rámec s celou řadou podpůrných nástrojů pro návrh IT architektury. Framework byl vyvinut členy sdružení Open Group a Architecture Forum. Můžeme říci, že se jedná o otevřený standard postavený na základních procesech tvorby architektur, mezi které patří vize, business model, model dat, model aplikací, technologie, plán migrace, plán implementace a řízení změn. Klíčové pro tuto metodiku je ADM 6, což je prověřená metoda rozvoje podnikové architektury na základě obchodních potřeb organizace. 4 ERP Entrerprise Resource planning je informační systém, který integruje velké množství procesů podporující činnosti podniku. [zdroj: , 10:02 ] 5 Reengineering znamená, proces zahrnují popis současných procesů a navržení jejich optimalizace na základě požadovaných vstupů 6 Architecture Development Method 19

20 Tento framework se začal vyvíjet v polovině devadesátých let po sloučení společností X/Open Company a Open Software Foundation. Je rozvíjen více než 200 dodavateli IT řešení z celého světa. Společnost Open Group je neziskovou organizací, a proto jsou všechny potřebné informace publikovány zdarma na webovské adrese pro všechny společnosti, které ji budou využívat pro interní vývoj a vlastní podnikovou architekturou. V případě komerčního využití je možné nalézt podrobné podmínky na již popsané webové adrese. Metodiku TOGAF můžeme rozdělit do tří základních částí. První část je TOGAF ADM, který poskytuje pohled na to, jakým způsobem rozvíjet architekturu, dále jakým způsobem má architektura zohledňovat obchodní požadavky. V této části ještě nalezneme ukázky praktického využití a informace o nástrojích k rozvoji architektury. ADM se skládá z následujících částí: vize architektury, business architektura, architektura informačního systému, technologická architektura, příležitosti a řešení, plánování migrace, zavedení řízení, řízení změn architektury. Na všechny tyto komponenty jsou navázány požadavky. Druhá část s názvem Enterprise Continuum obsahuje virtuální sklad částí architektury, jako jsou modely, vzory popisů architektur. TOGAF sám sobě poskytuje dva referenční modely. Prvním referenčním modelem je TOGAF Foundation Architecture, kde nalezneme obecné servisy a funkce, které poskytují základ pro stavbu architektury. V rámci tohoto referenčního modelu nalezneme TRM 7 a SIB 8. TRM poskytuje modely a ohodnocení obecných platforem a SIB je databáze otevřených průmyslových standardů, které mohou být použity k definování jednotlivých služeb rozšiřující specifickou architekturu. Druhým referenčním modelem je Integrated Information Infrastructure Reference Model, který je postaven na základech předchozího referenčního modelu a snaží se pomoci navrhnout infrastrukturní architekturu, která umožní podporu všech business požadavků. Třetí částí metodiky je TOGAF Resource Base, která obsahuje jednotlivé prostředky, jak vše popsat. Nalezneme zde směrnice, šablony a základní informace. Můžeme říci, že tato část pomáhá k využití ADM. 7 Technical Reference Model 8 Standards Infromation Base 20

21 TOGAF se zabývá následujícími typy architektury: Obchodní architektura zde jsou definovány obchodní strategie, řízení firmy, organizace a klíčové obchodní procesy. Aplikační architektura tento typ architektury poskytuje rozvoj individuálních aplikačních systémů a jejich vzájemné vazby nejen mezi sebou, ale také na obchodní procesy. Datová architektura zde se dozvíme, jak optimálně nastavit organizaci logické a fyzické data. Technologická architektura popisuje infrastrukturu učenou pro podporu a rozvoj kritických aplikací. 21

22 3. Definice postupu v řešení IT architektury Na základě metodiky IBM bude zvolen následující postup. Nejdříve budou definovány údaje, které budeme u jednotlivých aplikací sledovat a pomocí nichž budou posléze aplikace porovnávány. Dohodli jsme se na vytvoření a využití speciálního formuláře, který bude určen na sběr informací o systémech od různých zaměstnanců a tudíž je potřeba připravit srozumitelný formulář pro více osob. Tento formulář je možné rozdělit do několika částí. V první části se setkáváme se základním popisem vybrané aplikace a kontaktní osoby za danou aplikaci. Toto je z důvodu, abychom snadněji mohli vyřešit případné nedostatky. Druhý velký oddíl se týká popisu uživatelského pohledu na aplikaci. Správci jednotlivých systémů zde definují základní funkce a činnosti aplikace a to nejen současné, ale i plánované v horizontu dvou let. V následující části je uveden seznam vstupů a výstupů z aplikace se základními údaji k rozhraní. Druhý oddíl přibližuje administrátorský pohled na aplikaci, kde se dozvíme počty uživatelů, způsob řešení uživatelských účtů a přístupů, uzávěrky, kapacitní omezení, způsob řešení případných výpadků, zda je uzavřen pro aplikaci SLA 9, v jakém programovacím jazyku je aplikace napsána a jaké jsou dedikované kapacity na provoz a vývoj. Další části popisují hardware a software na straně serveru a v závěru se z dokumentu dozvíme, do jaké kategorie aplikace spadá, jaké uživatelské skupiny s aplikací pracují a způsob provozování. Tento formulář je uveden v příloze č. 4. Na základě těchto vyplněných formulářů a seznámení se s primárními procesy, budeme vědět, které aplikace zakreslíme do CBM a tento model vytvoříme. Následně provedeme diskuzi se zástupci vybraných oblastí, kterými má smysl se zabývat, což jsou aplikace pokrývající primární procesy pojišťoven a aplikace, kde je velký potenciál k úspoře nákladů. U těchto vydefinovaných aplikací vyplníme zdravotní dotazník, který nám napomůže v rozhodování, kterou aplikaci upřednostnit. Snížení nákladů, což je hlavní cíl této činnosti, můžeme v podstatě zajistit třemi možnostmi. První je konsolidace platforem, sdílením licencí a získání slev od dodavatelů. Druhou oblast můžeme definovat jako konsolidace aplikačních funkcí. Není důvod, aby v jedné společnosti vykonávaly stejnou funkci (například výpočet provizí) dvě aplikace. 9 SLA Service Level Agreement reprezentuje smlouvu o úrovni a kvalitě poskytovaných služeb. 22

23 Poslední možností je sdílení lidských zdrojů v analýze, vývoji, administrace, aplikační podpory a zajištění provozu. Hlavním cílem je úspora nákladů a proto provedeme u potenciálních kandidátů finanční analýzu, kolik nás bude stát integrace dané aplikace a její návratnost z hlediska úspory operativních nákladů. V této fázi je nesmírně důležité sladit pohled v obou společnostech na náklady jednotlivých aplikací, o což poprosíme oddělení controllingu. Jako postuláty v této oblasti lze brát, že nebudeme zohledňovat historii vývojových investic za dva roky zpětně, stejně tak vynecháme očekávané investice v následujících třech letech. Naopak budeme zohledňovat náklady spojené s aplikační podporou na tři roky dopředu a stejně tak očekávané náklady provozem platformy v následujících třech letech. Na základě získaných informací bude proveden návrh cílové aplikační architekty, která bude zohledňovat nejen poznatky získané během mapování současného stavu, ale také základní postuláty, které byly sděleny na začátku činnosti. Také vytvoříme návrh harmonogramu integrace, včetně odhadu časové náročnosti jednotlivých kroků a návazností mezi jednotlivými integračními aktivitami. Paralelně s touto činností se pokusíme definovat oblasti, ve kterých můžeme dosáhnout rychlé finanční úspory. Předpokládáme, že tyto oblasti budou zejména ve sdílení licencí, vyjednání lepších podmínek u dodavatelů a případně optimalizace práce v oblasti provozu. Nicméně tato domněnka bude potvrzena až v průběhu detailní analýzy. Pro skutečné vykázání úspor bude použit formulář Quick Win specifikace, který je uveden v příloze č. 5. V rámci metodiky IBM je také možné definovat rizika, která se v procesech vyskytují a tyto pak eliminovat. Toto je však poměrně časově náročné a tudíž se touto stránkou nebudu v následujících studiích integrace IT zabývat. Protože je však tato část velice důležitá, je nutné při detailní analýze dalších navržených aktivit tato rizika zohlednit. 23

24 4. Analýza současného stavu IT Abychom mohli navrhnout efektivně fungující IT, musíme nejdříve provést důkladnou analýzu současného stavu. Je důležité zajistit všechny současné procesy a návaznosti a případně provést jejich optimalizaci. 4.1 Představení společností z pohledu organizace IT V následující části se pokusím přiblížit základní odlišnosti ve způsobu řízení a organizace IT ve sledovaných společnostech. Jak již bylo zmíněno, obě společnosti jsou diametrálně odlišné, co se velikosti týče a stejně tak předpokládáme zásadní odlišnosti v pohledu na organizaci IT. Nejdříve popíši organizační strukturu a pak se zaměřím na způsob řízení lidí, podchycení procesů vývoje a zajištění provozu Organizační struktura Nejdříve se věnuji společnosti ALFA, která má organizační strukturu velice jednoduchou, viz schéma č. 2. Můžeme si všimnout, že se jedná v podstatě o velice plochou tří úrovňovou organizační hierarchii. Nejnižší vedoucí pozice je označována jako vedoucí skupiny, nad kterými je vedoucí oddělení IT, který již spadá přímo pod člena představenstva. Na oddělení IT pracuje celkem 40 lidí, kteří jsou rozděleny do pěti pracovních skupin. První skupina je User support, zajišťující běžné potřeby uživatelů od instalací počítačů až po problémy se sítí. V této skupině pracuje 11 odborníků. Následující dvě skupiny jsou rozděleny dle primárních aplikací, o které se starají. Jedna řeší produktové portfolio neživotního charakteru a druhá životního. Následuje skupina s názvem Vývoj. Jak již název napovídá, tato skupina se podílí na vývoji nových aplikací a provozu stávajících. V níže uvedené kapitole uvidíme, že vývoj je prováděn na několika platformách od AS400, přes Lotus Notes, Javu až po specifický datový sklad Cognos (zde se však nejedná o klasický vývoj aplikace, ale spíše o nastavování a rozšiřování stávajících struktur). Poslední tým s názvem Kompetenční centrum je velice specifický. Tento tým nesedí přímo v centrále společnosti, ale využívá se blízká spolupráce s Univerzitou Hradec Králové. Členové tohoto týmu jsou převážně studenti této univerzity a kromě vývoje na platformách Lotus Notes a Java pro různá odborná oddělení společnosti, se zde vychovávají budoucí pracovníci na centrále a to nejen na oddělení IT, ale i na ostatních zajímavých úsecích (účtárna, pojistná matematika, controlling, atd.). Ukazuje se, že 24

25 zkušenosti získané během této praxe společně jsou nenahraditelné. Tento tým je úzce organizačně řízen týmem Vývoje aplikací, neboť je zde nutná četná spolupráce. Celá tato struktura je poplatná velikosti celé informatiky. Při auditech často probíhají diskuze, že jako optimální se ukazuje členění na provoz a vývoj. Nicméně tato struktura by přinesla další mzdové náklady, což se samozřejmě u vedení společnosti neprosazuje jednoduše. Osobně se domnívám, že právě nynější počet zaměstnanců v oddělení informatiky společnosti ALFA je na hranici, kdy se může o rozdělení uvažovat. Dle mého názoru rozdělení na provoz a vývoj má své pozitivní dopady na optimalizaci práce jednotlivých zaměstnanců, snížení rizika podvodu (vývojoví pracovníci nemají přístup do produkčního prostředí) a za zásadní považuji transparentnost v nákladech na zavedení požadované změny. Naopak za nevýhodu lze považovat nutnost specifikovat způsob předání změn mezi provozem a vývojem a jasné vymezení pravomocí a zodpovědnosti. Schéma č. 2: Organizační struktura IT ve společnosti ALFA Zdroj: vlastní znalosti U společnosti BETA se naopak setkáváme s naprosto odlišným pojetím rozdělení IT. Vše již vychází z celkového počtu cca. 420 interních zaměstnanců IT. Hierarchie je zde pěti úrovňová. Na nejnižší vedoucí pozici jsou Vedoucí týmu, kteří jsou odpovědní Vedoucím referátů. Nad Vedoucím referátu je pozice Ředitel odboru, který přímo podléhá Vrchnímu řediteli. Nad vším bdí náměstek za oblast IT, který je členem vrcholného vedení společnosti. V takto košaté společnosti je již pochopitelně realizováno, auditory tak silně doporučované, rozčlenění na provoz a vývoj. Setkáváme se zde s Úseky, které spadají do 25

26 kompetencí jednotlivých vrchních ředitelů. Úseky jsou členěny následovně. Úsek Provozu, úsek Vývoje neživotního pojištění a úsek Vývoje životního pojištění. Kromě těchto úseků jsou přímo pod náměstkem také klíčové odbory a referáty. Mezi ně patří Odbor architektury, Odbor IT bezpečnosti, referát HR administrace a odbor metodologie a controllingu. Struktura je graficky znázorněna ve schématu č. 3. Schéma č. 3: Organizační struktura IT ve společnosti BETA Zdroj: vlastní znalosti Vzhledem k tomu, že byla pro realizaci zvolena metodika IBM, zobrazím také rozložení pracovníků v Component Business Model pro Business IT (CBM-BoIT), což je znázorněno na obrázku č. 7. Pracovníky IT jsem rozdělil do jednotlivých komponent, která vyjadřují obsah činností a odpovědností. Výsledkem je jednotný pohled na dané oblasti a jejich procentuální pokrytí pracovníky jednotlivých společností. Aby bylo možné srovnání, promítl jsem obě společnosti do stejného modelu. Levý sloupec pod danou oblastí reprezentuje společnost ALFA a sloupec pravý vyjadřuje společnosti BETA. Na první pohled je patrné, že zejména v oblasti provozu a rozvoje je nepoměrně větší počet zaměstnanců než v ostatních komponentách a to v obou společnostech. Společnosti se 26

27 odlišují zejména v počtu manažerských pozicích spadající pod IT Business management. Ve společnosti BETA je mnohonásobně více lidí na manažerských pozicích. Výsledek je jen potvrzením prvotních odhadů. Obrázek č. 6: Trojrozměrný pohled na CBM-BoIT Zdroj: Interní materiály Component Business Model pro Business IT, společnosti IBM, vlastní úpravy V následující tabulce č. 1 vidíme procentuální rozložení jednotlivých pracovníků dle metodiky IBM. Zajímavé je, že některé komponenty nejsou ve společnosti ALFA vůbec zastoupeny. Tyto činnosti se však musí také provádět i v této společnosti, ale nejsou na ně přímo vyhrazené pracovní síly. Jejich činnost je tudíž delegována na ostatní pracovníky. Toto přináší riziko v případě odchodu některého pracovníky na jinou pozici, případně do jiné společnosti. Musí se zabezpečit činnost i v těchto oblastech. 27

28 Tabulka č. 1: Procentuální rozložení zaměstnanců IT Zdroj: vlastní znalosti Základní procesy IT Jak jsme se již v předchozím textu seznámili, obě společnosti jsou z hlediska IT organizace naprosto odlišné, a tudíž můžeme předpokládat i jiné způsoby řízení a fungování IT. Pokusím se popsat zásadní činnosti IT, kterými jsou: zajištění provozu, předávání požadavků mezi IT a odborným oddělením a způsob vlastního vývoje. a) Zajištění provozu Jak se již stalo zvykem, nejdříve přiblížím společnost ALFA. Vzhledem k jejich poměrně nízkému počtu zaměstnanců v útvaru IT, není možné zajistit provoz 24 hodin a 7 dní v týdnu. Proto je garantovaný provoz základních 10 aplikací a systémů pouze v pracovní dny mezi 7:00 až 20:00, kdy je také k zastižení pracovník IT, který dokáže řešit nouzové situace. Z této garantované doby je možné ještě dále vymezit čas mezi 7:00 9:00 a 16:00 až 20:00, kde je možné na speciální lince hlásit poruchy. Čas mezi 9:00 až 16:00 je určen k hlášení nejen havarijních stavů, ale také k hlášení standardních požadavků na skupinu IT podpory. Toto hlášení může provést jakýkoliv zaměstnanec společnosti, tudíž IT zajišťuje i tzv. první úroveň podpory. Některé aplikace jsou instalovány na hardware mimo ČR a zde je provozní doba odpovídající lokálním zvyklostem. 10 Základními aplikacemi jsou míněny ty systémy, které přímo ovlivňují provoz společnosti. Jedná se o primární pojišťovací aplikace, ERP systém a komunikační platformu. 28

29 Ve společnosti BETA je zajištěn provoz základních aplikací 24 hodin a 7 dní v týdnu. Díky své velikosti se vyplatí zaměstnat tzv. operátory, kteří dohlížejí na provoz HW a základních aplikací. Pro tento účel je instalován důmyslný monitorovací systém. V případě nějaké poruchy pak dochází k vyrozumění odpovědné osoby za danou oblast, což je vlastně shodné u obou společností. b) Předávání požadavků mezi IT a odborným oddělením Ve společnosti ALFA je minimum požadavků řešeno formou projektu. Většinou se setkáváme s předáváním požadavků přímo od jednotlivých odborných oddělení. V lepším případě můžeme sledovat snahu k evidenci těchto požadavků a odsouhlasení požadavku ze strany zadavatele. U skupiny Vývoj je z důvodu rozmanitosti požadavků (velký počet rozdílných uživatelů aplikací s rozdílnými požadavky) nezbytná existence důsledné evidence požadavků a sledování jeho životního cyklu. Pro tento účel byla touto skupinou vyvinuta vlastní aplikace, do které mohou uživatelé vložit svůj požadavek. Po jeho schválení a implementaci je zde také zaznamenán, kdo realizovaný požadavek otestoval a kdo jej převedl do produkčního prostředí. Tento princip se snaží s větším, či menším úspěchem převzít také ostatní vývojové skupiny. Vzhledem k faktu, že tento proces není jednoznačně definován, často dochází k předávání informací zcela živelně na základě osobních vazeb. Ve společnosti BETA je situace podstatně systematičtější. Pro všechny části vývoje je využívána interní aplikace, do které jsou zaznamenávány veškeré požadavky na IT. Tyto požadavky mohou zadávat jen tzv. gestoři aplikace. Tím se záměrně eliminují nesmyslné požadavky. V případě větších požadavků je vše řešeno projektovým způsobem. Ve společnosti byla vyvinuta jakási metodika. Každý projekt začíná vytvořením tzv. analýzy dopadu, která společně s business-casem 11 umožní vedení rozhodnout o schválení celé aktivity. Poté je vytvořen dokument tzv.hld (High Level Design). Ten v sobě zahrnuje detailní popis zadání z odborného oddělení, popis výchozího a cílového stavu, popis všech ovlivněných procesů, návrh jeho implementace z hlediska logické architektury, přehledu funkčnosti, popis všech komponent a dopadů do všech IT systémů a v neposlední řadě také výčet předpokladů pro úspěšnou realizaci, omezení a rizika řešení. Na závěr tohoto dokumentu je zaznamenána předpokládaná doba implementace, která je v této fázi již poměrně přesná a tím pádem jsou také jasné předpokládané náklady a zpřesněn další 11 Business-case znamená porovnání přínosů a výdajů na zvolenou aktivitu a dobu návratnosti investice. Poskytuje obrázek o tom, jak výhodná je daná investice. 29

30 harmonogram činností. Tento dokument je po jeho vytvoření schvalován všemi útvary, kterých se změna dotýká. Za schválení je zodpovědný vždy vrchní ředitel daného útvaru. Po schválení tohoto dokumentu se přechází do fáze implementace. Pak již následuje testování, pilotní provoz a plné nasazení do produkčního prostředí. c) Způsob vývoje Vývoj SW je v obou společnostech velice podobný. Ve společnosti ALFA jsou požadavky nejdříve realizovány na vývojovém prostředí dané aplikace, poté jsou přesunuty na testovací prostředí, kde jsou prováděny akceptační testy uživateli. Po jejich kladném provedení se změna přesouvá do produkčního prostředí. Pro tento přesun nejsou předem definované termíny změn, ale provádí se v okamžiku potřeby po předchozím upozornění dotčených osob a oddělení. Ve společnosti BETA je princip shodný až na dvě nepatrné odchylky. První je rozdělení testovací fáze do dvou kroků a prostředí. První je akceptační test a druhý je test integrační. Tento test má za úkol prověřit, že změna v jedné aplikaci neovlivní negativně aplikace jiné. Druhý rozdíl je v termínech, kdy je možné změny převádět do produkčního prostředí. Každá významnější aplikace má svůj migrační plán. Například je zde popsáno, že velké změny v aplikaci je možné realizovat pouze čtyřikrát ročně a změny menší šestkrát do roka. Za zmínku stojí ještě popsat využívání outsourcingu 12. Společnost ALFA využívá tento druh spolupráce zejména při zajištění servisu PC. U vývoje aplikace se jedná pouze o velice ojedinělé aktivity v případech, že je nedostatek vlastních kapacit, případně znalostí. Naopak společnost BETA i přes svoji velkou strukturu využívá outsourcing nejen pro správu počítačů a také pro vývoj aplikací a poměrně velkou část (cca 30%) pro samotnou analýzu. Po provedení analýzy této části mohu konstatovat, že obě společnosti jsou orientovány na provoz a že jednotlivé procesy mají jednoznačného klienta na straně odborného oddělení. Některé procesy ve společnosti ALFA jsou jednodušší a transparentnější, díky čemuž mohu doporučit transportovat je do společnosti BETA. Toto sloučení nesmí narušit podporu společnosti ALFA. 12 Outsourcing je proces, při kterém společnost deleguje činnosti a práci ze svých interních zaměstnanců na externí firmy. 30

31 4.2 Analýza základních oblastí V této části dokumentu provedu analýzu infrastruktury a aplikačního portfolia společností. Jejich zápis provedu již ve formátu dle metodiky IBM. Pro získání všech potřebných údajů využiji kromě rozhovoru také dotazníkový formulář, který je uveden v příloze č Infrastruktura Serverová infrastruktura společnosti BETA je uvedena v příloze č. 6. Následující částí se pokusím přiblížit princip, jakým způsobem je tato struktura popsána a které prvky můžeme ve společnosti BETA nalézt. Jak je ze schématu patrné, ve společnosti jsou používány zejména dvě serverové technologie, které jsou od společnosti Intel a Sun. Společnost Intel byla založena v roce 1968 a působí v oblasti vývoje hardware, zejména v oblasti procesorů. Společnost Sun Microsystems, Inc. byla založena v roce 1982 a je poskytovatelem služeb a produktů pro stavbu a údržbu počítačových sítí. Jednotlivé servery jsou sloučeny do balíčků, které odpovídají vždy dané aplikační oblasti. V oblasti DA běží servery podporující aplikace digitálního archivu, v oblasti TIA jsou uvedeny servery pro podporu aplikací na likvidaci pojistných událostí, servery v oblasti JOK slouží pro celou oblast jednotné obsluhy klientů, oblast s názvem CTS je určena k tiskovému řešení. Další velkou oblastí je CDU, kde jsou servery využívány pro centrální evidenci klientů a uživatelů. Oblast DMZ 13 označuje část odděleného systému, kde se nacházejí zařízení, které zprostředkovávají služby, jak pro vnitřní sít, tak i pro síť vnější, například internet. Pro umístění zařízení do této části jsou zejména dva důvody. Prvním je rozdílná úroveň přístupu z různých sítí a druhý důvod je požadavek, aby vnější část neviděla část vnitřní a tudíž se snižuje riziko napadení vnitřní sítě útokem ze sítě vnější. Schéma propojení DMZ je uvedeno na obrázku č. 7. Bližší přiblížení jednotlivých názvů aplikací a jejich základních funkcionalit jsou uvedeny v kapitole Aplikační portfolio. Každý server obsahuje ve schématu několik částí. V horní vrstvě je uveden název serveru, v části pod ním je uvedena hrubá konfigurace serveru. Další vrstva přibližuje roli serveru a v nejnižší vrstvě můžeme vyčíst typ serveru. 13 DMZ je zkratka z anglického výrazu Demilitarized Zone a vyjadřuje oddělenou síťovou část 31

32 Obrázek č. 7: Zapojení DMZ v síti Zdroj: vlastní znalosti Kromě serverů jsou ve schématu také uvedeny switche. Switch je aktivní prvek, který propojuje jednotlivé segmenty sítě. V architektuře jsou použity dva typy, odlišující se použitým protokolem. Pro standardní rozvod Ethernetu je použit protokol TCPIP. Nicméně tento protokol se nehodí pro datová úložiště, kde je požadována velká datová propustnost a vysoký výkon. V různé literatuře se můžeme dočíst, že tento standard umí připojovat nejen počítačové sítě Ethernet, ale slouží také k připojení rychlých periférií. Dnes běžně dosáhneme přenosovou rychlost 4Gbps. Dle zkušeností kolegů ve společnosti BETA je však tato univerzálnost podmíněna použitím speciálních protokolů, které však nejsou zcela nejspolehlivější. Proto jsou tyto switche použity skutečně jen na spojení diskových úložišť, kde je využita jejich poměrně velká rychlost a průchodnost. Druhý důvod pro uvážené využití této komponenty je její cena, která je několikanásobně vyšší než cena klasických komponent pro Ethernet. Z tohoto důvodu je tato technologie využita právě jen na propojení datových polí. Dalším zařízením stojícím za popis je Load Balancer, který slouží k optimalizování rozložení vytížení jednotlivých serverů a tím dosažení, co nejvyššího výkonu a snížení času pro odezvu. Toto zařízení sleduje vytížení jednotlivých serverů a dokáže optimálně přesouvat běžící aplikace na méně vytížené servery. Tento přístroj se dá také použít na řešení výpadků hardware, kdy je schopen sám detekovat chybu na serveru a vše přesměrovat na jiný hardware. 32

33 Abychom dostali ucelený pohled na použité technologie s vazbou na aplikace, připravil jsem porovnání, jaké základní aplikace běží na dané platformě. Toto porovnání je zobrazeno na obrázku č. 8 vazba aplikací na platformu. Obrázek č. 8: Vazba aplikací na platformy Zdroj: vlastní znalosti Jak je ze schématu patrné, velká část technologií je v obou společnostech shodná. Nicméně zde také nacházíme poměrně zásadní rozdíly. Jen ve společnosti ALFA jsou použité následující technologie: 33

34 AS400 14, která je využita pro správu neživotního pojištění a všech aplikací týkajících se párování plateb a výpočtu provizí, Lotus Domino, která je společností ALFA využívána pro ového klienta a celou řadu podpůrných aplikací, Cognos, na kterém běží datový sklad, Firebird s aplikací pro podporu obchodní služby, MS Visual FoxPro pro aplikaci správy cestovního pojištění. Naopak ve společnosti BETA jsou využívány následující platformy a technologie, které nejsou použity v druhé společnosti: BEA WLI 15, která je využívána pro všechny moduly aplikace pro jednotnou obsluhu klienta, SAS 16, použité pro datový sklad, ORACLE, tato platforma je používána jako základní databáze pro celou řadu aplikací společnosti BETA, MS Sharepoint je platforma používána pro intranet a extranet. Obě společnosti mají rozsáhlou počítačovou síť po celé České Republice. Společnost ALFA má všechny servery umístěné na dvou místech v Praze navzájem propojené spojením o kapacitě 1Gb/s. V rámci ČR je přes pevnou linku spojení k osmi oblastním ředitelstvím s kapacitou 2 Mb/s. Spojení s agenturami je zajištěno prostřednictvím ADSL. Toto spojení se vyznačuje asymetrickým připojením, což znamená rozdílnou rychlost mezi přijímanými a odesílanými daty. Společnost ALFA spadá pod mezinárodní holding, a proto je napojena na svoji nadřízenou společnost do zahraničí prostřednictvím 2Mb linky. Prostřednictvím tohoto spojení je pak zajištěno spojení do holdingového datového centra, kde je například umístěn mainframe. Pojišťovací zástupci se mohou připojit do extranetu prostřednictvím spojení GPRS/UMTS. Toto spojení je zprostředkována sítí GSM. Výhodou tohoto spojení je mobilita, nicméně poslední dobou začíná být její technické omezení rychlosti limitující. Rychlost spojení je určena způsobem kódování a tudíž v ČR dosahuje max. 80 kbit/s. Provozovatelé se proto snaží přejít na další stupeň GSM spojení a tím je EDGE. Technologicky EDGE dovolí přenést pomocí osmistavové fázové modulace několik bitů pomocí jednoho symbolu, což je základní rozdíl oproti 14 AS400 je platforma dodávaná společností IBM (dnes nazývána iseries) 15 BEA WLI BEA WebLogic Integration je standardní řešení pro napojení aplikací, databází, procesů. 16 SAS poskytuje integrovanou a rozšiřitelnou integrační platformu, což tvoří základ datových skladů. 34

35 GPRS. Proto toto spojení umožní rychlost až 200 kbit/s. Toto spojení však již vyžaduje speciální funkci na mobilním zařízení, což dnes již není vůbec problém zajistit, a také pokulhává rozsah signálu na celém území ČR Aplikační portfolio Z důvodu lepšího grafického odlišení, jsou systémy společnosti ALFA uváděny červeně a barva modrá je použita pro společnost BETA. Pro grafickou názornost jsou aplikace rozděleny do několika funkčních oblastí, kterými jsou: životní pojištění, neživotní pojištění, finance a controlling, platby, obchod, tisky a kontaktní centrum. Nejdříve popíši část životního pojištění, viz. obrázek č. 9. Obrázek č. 9: Aplikační portfolio životního pojištění Zdroj: Interní materiály Projektová dokumentace Digitalizace, společností ALFA a BETA, vlastní úpravy, v Aplikace SYNPAC je primární aplikace pro správu pojistných smluv a řešení pojistných událostí. Spravují se zde produkty pojistných životního, úrazového, investičního pojištění a klienti ze všech těchto oblastí. Dále tento systém obsahuje účetní knihu 35

36 s předpisem pojistného, párováním plateb a upomínání. Je zde integrován modul pro výpočet provizí, dále modul na správu agentů. Aplikace INKAS je určena pro správu příchozích plateb do společnosti, párování přijatých plateb se seznamem pojistných smluv a základní evidenci pohledávek. Mezi základní funkcionality patří načítání bankovních výpisů, import pojistných smluv, u kterých je očekávána platba pojistného, párování plateb od klientů s pojistnou smlouvou a exporty informací zpět do ostatních aplikací. Zpětné dotazy jsou využívané ke zjištění detailnějších údajů o zdravotním stavu nových klientů životního pojištění. Prostřednictvím této jsou vyžádány od lékařů detailnější údaje. Aplikace Kukátko slouží k on-line přístupu do primárních aplikací prostřednictvím internetu, případně intranetu. Tuto aplikaci využívá cca 3000 uživatelů z řad obchodních zástupců, makléřů a zaměstnanců. Za zmínku stojí, že tato aplikace je jako primární aplikace pro call-centrum. Mezi základní funkcionality systému patří zobrazení informací o pojistné smlouvě, evidence komunikace s klientem, provádění základních změn nad pojistnou smlouvou, modul pro tiskové výstupy, zobrazení pohledávek nad pojistnou smlouvou, integrovanou ovou komunikaci s klientem prostřednictvím obchodní služby a evidence klientů Klubu ALFA pro marketingové účely. Aplikace Komix je speciálně vytvořena pro spolupráci s bankami a prodejem produktů prostřednictvím bankovní sítě. Poradce je aplikace určená pro pojišťovací agenty, kteří jejím prostřednictvím mohou uzavřít pojistnou smlouvu, vytisknout návrh pojistné smlouvy. Zprostředkovateli umožňuje evidovat svůj kmen, počítat odhady obdržených provizí a evidenci vlastní podřízené sítě. Elektronický archiv slouží k evidenci digitálních dokumentů od naskenovaných pojistných smluv, přes formuláře hlášení pojistných událostí, až po jejich fotografie. Aplikace KDP slouží stejně jako aplikace SYNPAC ke správě životního pojištění a řešení pojistných událostí těchto produktů. SPS je aplikace pro správu správců pojistných smluv. Mezi základní funkcionality patří tvorba dotazů na správce-vlastníka pojistné smlouvy a jejich historii na pojistných smlouvách, dotazy na smlouvy, o které momentálně nikdo nepečuje, změna pečujícího zprostředkovatele a předzpracování provizních správ pro jiné systémy. 36

37 Systém APO je předchůdce aplikace KDP pro správu životního pojištění. Od roku 2004 se zde již nesjednávají nové pojistné smlouvy, ale pouze se udržují dříve sjednané pojistné smlouvy, které se zatím nepodařilo přesunout do nástupce. Aplikace APO MF je jednou ze dvou komponent systému APO, která spolu s kooperující aplikací APO_PC vytváří kompletní funkcionalitu systému APO. Tato aplikace reprezentuje BACKEND systému APO. JOK PPO slouží ke sjednání pojistné smlouvy prostřednictvím internetových stránek společnosti BETA a po telefonu. Aplikace je integrována s platebním a doručovacím modulem, čímž jsou umožněny platby po telefonu, přes internet a následné doručení smlouvy kurýrem. JOS WEPOS je jednotný obchodní systém určený pro modelování a sjednávání pojistných smluv. Systém DA je centrální digitální archiv určený pro archivaci dokumentů v elektronické podobě a podporu obchodních procesů nad dokumentem. Mezi tyto obchodní procesy patří například likvidace pojistné události. FSCD je jeden z modulů známého systému SAP. Tento modul řeší příchozí a odchozí platby a jejich párování s primárními systémy. Aplikace sřsl slouží ke komunikaci s externími lékaři. Externí lékař pomocí této aplikace přijímá požadavky, dostane se na elektronické formuláře a může zde vytvářet lékařské zprávy, které se vrací zpět do společnosti. Malá aplikace WF Oceňování slouží k oceňování zdravotního stavu a lékařských výkonů. Mimo tuto základní funkci tato aplikace také slouží ke komunikaci s lékaři včetně urgování a odesílání honorářů a hledání termínů výpovědných lhůt. Aplikace CDU slouží jako centrální databáze uživatelů různých aplikací. Na tuto aplikaci se ostatní systémy napojují buď přímo on-line, nebo se data přehrávají dávkově např. každou noční uzávěrku. Aplikace Daňové Doklady slouží pro evidenci smluv životního pojištění daňově uznatelných a k nim vystavených daňových potvrzení. Umožňuje zobrazit a vytisknout kopii hromadně vystaveného potvrzení a zároveň umožňuje ruční vystavení potvrzení. Nyní stejným způsobem popíši oblast neživotního pojištění. Základní schéma aplikací neživotního pojištění je uveden na obrázku č. 10. V následujícím popisu již nejsou obsaženy aplikace, které jsem popsal v předchozí části. 37

38 Obrázek č. 10: Aplikační portfolio neživotního pojištění Zdroj: Interní materiály Projektová dokumentace Digitalizace, společností ALFA a BETA, vlastní úpravy, v VIAS aplikace je určena pro správu většiny neživotních pojistných smluv. Mezi základní funkcionality patří pořizování, změny a ukončování pojistných smluv, vytváření předpisů následného pojistného, hlídání upomínacího cyklu, správa údajů o klientech, výpočet provizí na základě zadaných parametrů a řešení pojistných událostí. Aplikace GIS slouží pro posouzení rizikovosti záplavových zón při vzniku pojistných smluv. Zároveň je dle této aplikace možné kontrolovat zadané adresy klientů. Aplikace CP slouží k evidenci cestovního pojištění. Obdobně jako jiné primární systémy i tato aplikace má následující základní funkcionality: vytvoření, změnu a uzavření pojistných smluv, tiskový modul, řešení pojistných událostí, agenturní systém, modul pro řešení přijatého pojistného od klientů a v neposlední řadě řešení pohledávek. 38

39 WEB CP slouží jako internetová aplikace pro vytvoření pojistné smlouvy v oblasti cestovního pojištění. Můžeme zde také zahrnout řešení pro SMS 17 a WAP 18 Tour. Klienti mohou prostřednictvím této aplikace uzavřít cestovní pojištění a smlouvu si vytisknout. Aplikace Modrá Linka slouží uživatelům na oddělení Call Centrum pro hlášení pojistných událostí. Tato aplikace je nahrazována systémovým řešením Kukátko. Aplikace Prohlídky slouží k evidenci žádostí o prohlídku likvidátora v případě pojistné události. Požadavek na prohlídku může vzniknout buď automaticky se založením pojistné události, nebo ručně na žádost klienta. E-Foto je aplikace sloužící jako uživatelské webové rozhraní k nahrávání dokumentů k pojistným událostem. Hlavní funkčností je možnost automatické komprese vkládaného dokumentu. K dokumentu je dále vygenerován XML soubor, který definuje vlastnosti dokumentu. Aplikace Audatex, Eurocalc a Eurotax slouží k získávání standardních cen pojištěných věcí, případně jejich částí. Například slouží k ocenění mimořádné výbavy konkrétního typu vozidla. Aquarius je aplikace postavená nad aplikací GIS. Využívá prvotní data, nad kterými jsou připravené speciální grafické pohledy. Jsou zde využity další geografická data a informace vztahující se k adresním lokalitám). Aplikace GOLEM je jeden ze starších primárních systémů, který je dnes již využíván jen na správu pojištění velkých a středních rizik. Aplikace TIA je systém pro správu a likvidaci neživotního pojištění. Obsahuje stejné funkce, jako jsem popsal například u aplikace VIAS. Můžeme se ještě setkat s aplikací TIA KUK, která slouží primárně pro prohlížení těchto pojistných smluv. Aplikace JOK (zkratka jednotná obsluha klientů) obsahuje několik modulů, mezi které patří: JOK PPO aplikace pro sjednání pojištění přes internetové stránky, JOK SPO sjednání pojištění povinného ručení a motorových vozidel, JOK INET slouží mobilním technikům k likvidaci pojistných událostí, prohlížení a plnění úkolů od nadřízených, JOK PK práce s klientem. 17 SMS znamená Short message service a vyjadřuje službu pomocí které lze odeslat krátkou textovou zprávu 18 WAP znamená Wireless Application Protokol určený pro prohlížení obsahu internetových stránek prostřednictvím mobilního telefonu. 39

40 Další porovnání bylo provedeno nad oblastí financí a controlling viz. Obrázek č. 11. Obrázek č. 11: Aplikační portfolio finanční oblasti Zdroj: Interní materiály Projektová dokumentace Digitalizace, společností ALFA a BETA, vlastní úpravy, v DWH aplikace shromažďuje data ze všech primárních systémů. Nad těmito daty jsou prováděny různé analýzy a statistické sestavy. V DWH jsou evidovány údaje o pojistných smlouvách, upomínacího řízení, pojistných událostech, vyplacených provizí a organizační struktuře. Aplikace Coins slouží jako manažerský informační systém pro speciální druh reportů zaměřených na finanční oblast. Mezi základní funkcionality patří controllingová oblast (analýza ziskovosti), provozní náklady, investiční náklady, finanční účetnictví a obchodní a personální reporting. Ve druhé společnosti se pro toto používá aplikace IRIS. Jako primární finanční aplikace je používán produkt SAP. Tento produkt se dělí do několika modulů. Modul FI hlavní kniha evidující všechny účetní případy. Finanční účetnictví je rozděleno na hlavní knihu a vedlejší knihu. Ve vedlejší knize jsou evidováni dodavatelé, odběratelé a jednotlivé pohledávky, závazky. Modul CO se zaměřuje na účetnictví režijních nákladů, řízení profitability a manažerské účetnictví. Modul HR slouží 40

41 k administraci personálních údajů, tvorba a údržba organizační struktury, zúčtování mezd a odměňování spolupracovníků, vzdělávání a personální rozvoj, řešení cestovních náhrad a reporting. Další modul je MM, který řeší celý proces nákupu od vložení objednávky, jejího schválení, objednání a sleduje doručení cílovému odběrateli včetně návaznosti na správné zaúčtování. Modul SD se zabývá udržováním číselníků budov, služeb na pronájmy, evidenci všech těchto smluv a jejich změn. Aplikace ProAs je primární aplikace pro správu personálních údajů obchodních zástupců a makléřů, výpočet speciálních odměn a provizí, provádění podpůrného účtování každému zprostředkovateli, evidenci absolvovaných seminářů a analýzu motivačních prvků. Skladová Evidence je název menší aplikace, která umožňuje provádět analýzu stavu skladu, uživatelské objednávání skladového materiálu a objednávání materiálů u dodavatelů. ČKP je malá aplikace, která zprostředkovává přenos dat se stejně označovanou Českou kanceláří pojistitelů. Obsahuje pojistné smlouvy a pojistné události. Na dalším grafickém zobrazení můžeme vidět analýzu oblasti plateb viz. obrázek č. 12. Aplikace fakturace slouží ke správě a vytváření sdružených dokladů, tzn. sdružených složenek a faktur, a dovoluje provádět ruční úpravy těchto dokladů. Mezi základní funkcionality patří sdružování předpisů na základě společné identifikace, ruční nebo automatická tvorba faktur, správa sdružených dokladů a jejich export jako podklad pro tisk a spolupráce při rozúčtování úhrad faktur na pojistné smlouvy. Aplikace epohledávky je intranetová aplikace vyvinutá pro skupinu řízení pohledávek. Umožňuje evidenci pohledávek ve společnosti ALFA a zabezpečuje výměnu dat se spolupracujícími firmami. Tato aplikace řeší vymáhání dlužného pojistného, regresů a postihů. Aplikace ExkAs slouží ke zpracování bezhotovostních a hotovostních plateb z primárních systémů a následný export plateb na poštu a do bank. Tento systém je úzce spjat s tiskovým řešením. Aplikace CZP (centrální zpracování plateb) je obdoba aplikace Inkas a Exkas. Slouží tedy k předávání plateb z bankovních výpisů, složenek a hotovostních plateb na provozní systémy a vytváření příkazů k inkasu na základě požadavků primárních systémů. Zároveň tento systém generuje informace pro řešení upomínek. 41

42 O aplikaci JOK jsem se již zmiňoval, nicméně v tomto schématu můžeme vidět další její části. JOK HPP je řešení pro správu hromadných plateb pojistného. Umožňuje firmám, které přispívají svým zaměstnancům na soukromé životní pojištění pasivně kontrolovat stav jimi poukázaných plateb pojistného. JOK PMO umožňuje provádění online plateb přes internet a umožňuje získávání informací o takto provedených platbách. JOK APH je systém pro správu pohledávek. Má obdobné funkce jako aplikace epohledávky. JOK EIB slouží obchodníkům společnosti BETA k předávání údajů o platbách od klienta do centrálního zpracování plateb. Obrázek č. 12: Aplikační portfolio oblasti plateb Zdroj: Interní materiály Projektová dokumentace Digitalizace, společností ALFA a BETA, vlastní úpravy, Další ze sledovaných funkčních oblastí je oblast obchodu. Grafické znázornění je na obrázku č

43 Aplikace ipov slouží k online sjednávání povinného ručení. Obsahuje webové rozhraní pro klienty, ke sjednání pojištění. Dále rozhraní pro klienta Lotus Notes, kde je možné provádět zpracování návrhů smluv, schvalování, editaci, exporty sjednaných dat. Portál epoint je internetová B2R aplikace založená na platformě Lotus Notes, poskytující pojišťovacím zprostředkovatelům aktuální informace (pojistný kmen, pohledávky, provize, chybovost, rizikové zóny záplav, sazebníky, tiskopisy). Její základní součástí je také ový klient. Prostřednictvím tohoto portálu jsou také řešeny přístupy do aplikací Kukátko, cestovní pojištění a rizikových zón záplav. WF Matrika je aplikace pro správu získatelů. Je určen pro pořizování (sběr) datových záznamů na agenturách, které následně na centrále vstupují do systému SAP. Jedná se o požadavky na zařazení nových získatelů (obchodníků), nebo na změny v jejich údajích, které se mají promítnout do centrální evidence. Obrázek č. 13: Aplikační portfolio obchodní oblasti Zdroj: Interní materiály Projektová dokumentace Digitalizace, společností ALFA a BETA, vlastní úpravy, 43

44 JOS POVHAV je aplikace sloužící pro modelaci pojistných smluv u produktů povinného ručení a havarijního pojištění. JOS WEPOS je stejný systém, ale určený pro modelaci životního a neživotního pojištění. Aplikace RIS je pro podporu obchodní služby ve smyslu orientace na množství, zaměření a stávající propojištěnost podniků v ČR a sledování akvizičních jednání správců firem. SUP je aplikace zajišťující výpočet a zpracování podkladů pro výplatu provize, superprovize, odměn z prémiových fondů, paušálních odměn, zádržného, úroku ze zádržného, zácvikového paušálu, dopočet do zaručené odměny. Malá aplikace ISPEK slouží k definici individuálních provizních sazeb obchodníků. Další popsanou oblastí je oblast Tisky. Schéma je uvedeno na obr. č. 14 aplikační portfolio tisky. Aplikace ARC je využívána ve společnosti ALFA pro prohlížení elektronických dokumentů v archivu. Tyto dokumenty je možné si vytisknout a případně k nim doplnit chybějící indexy. Aplikace KOFAX je určena ke skenování dokumentů a uložení do elektronického archivu. Skenování probíhá v hromadných dávkách s automatickým oddělením jednotlivých dokumentů. V rámci tohoto systému je také možné využít automatické rozpoznávání typu dokumentu pomocí ICR. Aplikaci využívá společnost ALFA. Aplikace Tisky slouží k hromadnému zpracování tisků klientům. Vše probíhá dávkově v průběhu nočních uzávěrek. Tato aplikace byla vyvinuta interně ve společnosti ALFA. Aplikace JOK PWB umožňuje generování PDF dokumentů jako tiskové výstupy ke korespondenci se zákazníky. PrintNet je komplexní řešení společnosti BETA na zpracování tiskových výstupů veškerých produktových (pojistných a jiných) systémů včetně archivace do DA. Aplikace umožňuje online zpracování dat s centrálním generováním tiskových náhledů, neboli lokální tisky a offline zpracování dat ve formě dávek, neboli centrální dávkové tisky. Aplikace OPUS je další aplikací ve společnosti BETA určená k tisku dokumentů, tentokráte úzce zaměřené na spolupráci s Českou Poštou. Pracuje pouze off-line a zajišťuje třídění a svazkování zásilek. 44

45 JOK DMO je aplikace sloužící k doručování dokumentů. Umožňuje získání seznamu dokumentů k doručení a získání obsahu těchto dokumentů. Je určený pro přímý prodej přes internet a využívá ji společnost BETA. Obrázek č. 14 Aplikační portfolio oblasti tisků Zdroj: Interní materiály Projektová dokumentace Digitalizace, společností ALFA a BETA, vlastní úpravy, Poslední analyzovanou funkční oblastí je oblast kontaktního centra. Grafické znázornění je na obrázku č. 15. DA je aplikace společnosti BETA, která je určena ke zpracování a uchování elektronických dokumentů. Detailní popis této aplikace je uveden v kapitole č. 6 Detailní analýza vybrané oblasti a návrh řešení, která se právě zabývá optimalizací této aplikace. Aplikace WFM je používána pouze v rámci klientského centra. Významná funkce je předpověď zatížení klientského centra a na základě těchto předpovědí je využívána pro plánování směn na klientském centru. JOK KC je další z celé řady modulů aplikace Jednotné obsluhy klientů. Tento modul řeší oblast jednotné fronty, což znamená, že všechny příchozí požadavky přes 45

46 , fax, elektronický dokument jsou do této fronty zařazeny a postupně dle nastavených priorit předávané do produkce. Aplikace CALLREC má jednoduchou funkci pro nahrávání hovorů s klientem a uchování pro pozdější využití. Například při reklamaci, nebo pro zpětné vyhodnocení kvality práce operátora. OPENMINDER je všeobecně známá aplikace pro práci kontaktních center. Základní funkcionality můžeme rozdělit do aktivního a pasivního volání, tvorby statistických reportů, automatického zpracování dokumentů pro klienty a aktivního prodeje po telefonu. Základní rozdíl mezi aktivním a pasivním volání je následující. Aktivní znamená, že společnost se snaží kontaktovat klienta například z důvodu dlužného pojistného. Naopak pasivní znamená, že klient volá společnosti a má zájem o nějaké informace. Obrázek č. 15: Aplikační portfolio kontaktního centra Zdroj: Interní materiály Projektová dokumentace Digitalizace, společností ALFA a BETA, vlastní úpravy, 46

47 Aplikace IPCC je základní aplikace pro příjem telefonního hovoru a vlastního volání. Mohli bychom ji rozdělit do třech modulů. Pomocí aplikace Cisco CTI Toolkit se operátoři mohou přihlásit do agentských lišt, přijmout hovor, ukončit hovor, předat dál, výstup z hovoru zaznamenat a přijmout další hovor. Komponenta Cisco ICM zajišťuje centrální rozhodovací logiku IP kontaktního centra. Za tímto účelem jsou konfigurovány směrovací skripty. Směrovací skripty slouží ke zpracování příchozích požadavků o sestavení hovoru z aplikace Cisco CallManager. Hovory předává k přehrání uvítací hlášky s následným přehráním voleb IVR stromu. Na základě informaci z aplikace Cisco CallManager, rozhodne o výběru optimálního agenta a následném jeho přepojení. Portál HELPKC slouží pro všechny operátory společnosti BETA, kteří na jednom místě naleznou nápovědy k jednotlivým aplikacím, k novinkám, které jsou pro klienty připraveny. Ve společnosti ALFA je toto řešeno prostřednictvím Intranet KC. 47

48 5. Návrh budoucí IT architektury společnosti Při návrhu budoucí IT architektury vycházím z analýzy prostředí popsané v předchozím bodu. Nejdříve se budu věnovat tzv. Quickwins, což znamená popsat rychlé kroky, vedoucí k finančním úsporám s minimem nákladů. Poté představím cílovou organizaci IT, cílovou SW architekturu a cílovou infrastrukturu. V závěru navrhnu časový plán integrace z pohledu IT. 5.1 Definice rychlých kroků vedoucích k finančním úsporám V této části popíši definici rychlých kroků, které přinesou finanční úspory s minimálními náklady. Vzhledem ke své povaze se všechny tyto kroky týkají převážně infrastruktury a provozu. V oblasti SW jsou samozřejmě velké potenciály k finančním úsporám, nicméně je zde potřeba delší čas na realizaci. Této části se budu věnovat u SW architektury. Mezi rychlé kroky patří: Síťové spojení mezi společností ALFA a BETA. Toto propojení bude základem pro vnitrofiremní komunikaci. Řešení společného ového klienta. Hlavní výhodou tohoto řešení bude kromě finanční úspory za licence také využití společného plánování schůzek a jednání, což přinese vyšší efektivitu zaměstnanců v komunikaci. Po úvodní analýze se nabízí tři možnosti řešení. První je příprava spojovacího můstku mezi aplikací Lotus Notes (společnost ALFA) a Outlookem (společnost BETA). Druhé řešení je migrace aplikace z LN do Outlooku. Toto řešení se zdá být z prvního pohledu velikosti společností jako vhodné, nicméně ve společnosti ALFA jsou Lotus Notes používány nejen jako ový klient, ale z velké části také jako platforma pro malé aplikace. Třetí možná varianta je přesun z Outlooku do Lotus Notes, nicméně zde nehovoří příznivě počet uživatelů pro přeškolení. Po zvážení všech variant a finančního dopadu je navržena první varianta, tj. příprava přechodového můstku. Vytvoření jednotné pracovní stanice. Tento krok povede ke zjednodušení správy pracovních stanic a k úspoře za platby duplicitních licencí. Hlavní výhodou bude možnost sdílení týmu, starajícího se o tyto PC. Porovnání současných smluv jednotlivých společností a společný tlak na snížení cen. Zde je velký prostor ke snížení nákladů, zejména při využití nadnárodních smluv 48

49 našeho holdingu. Jako první možnosti k vyjednávání jsou oblasti společností Microsoft, IBM, Cisco a oblast podpory SW a HW formou outsourcingu. 5.2 Cílová organizace IT Za velice zásadní při definování cílové organizační struktury IT se jeví nutnost vytvoření třetí společnosti, která bude poskytovat služby oběma společnostem. Dle vyjádření státního dozoru, není možné poskytovat služby IT z jedné pojišťovny do pojišťovny druhé. Jiné uspořádání by bylo velice riskantní a je zde poměrně velké nebezpečí vysoké pokuty. Již při zkoumání současného stavu byl zjištěn podstatný rozdíl ve velikosti organizačních struktur jednotlivých IT oddělení. Jedním z cílů integrace dvou společností bylo stabilizovat stávající prostředí. V návaznosti na poslední dva důvody, jsem cílovou organizační strukturu navrhl realizovat ve dvou fázích. V první fázi dojde pouze ke sloučení obou IT pod jedno metodické řízení, bez redukce pracovníků. Obě IT budou nadále figurovat v rozdílných společnostech, jen náměstek pro IT bude mít duální kontrakt se společností ALFA a společností BETA. Dle vyjádření právníků je toto řešení také možné. Graficky jsem toto znázornil na schématu č. 4. Schéma č. 4: Organizační schéma přechodné struktury Zdroj: vlastní znalosti 49

50 Jako druhý krok bude následovat vytvoření třetí servisní organizace jako třetí společnost poskytující IT služby ostatním společnostem. Vytvoření této organizace je poměrně složitý krok ze strany legislativní, neboť je zde celá řada bodů k řešení. Hlavní důvody pro vznik servisního centra je snížení rizika sdílení osobních dat a vyšší transparentnost pro ČNB. Mezi dvě zásadní oblasti řešení patří vybudování řídícího a kontrolního systému odpovídajícímu společnostem, pro kterou budou poskytovat služby. V našem případě toto znamená kompletní systém auditu a certifikace normy ISO. Pro tento první krok je potřeba nastavit vhodné účtování a controlling. Protože se předpokládá přechod většiny zaměstnanců do této nové organizace, je nutné vyřešit otázku smluvního vztahu. Zde se jeví jako možný způsob tzv. odštěpení části podniku, které by znamenalo výhodu v automatickém převodu pracovních smluv nejen se zaměstnanci, ale také převod licenčních ujednání ohledně poskytování software. Ve spolupráci s právníky jsem navrhl následující oblasti, které je nutné prozkoumat a následně realizovat: Zajištění právní stránky: zde se nachází např. komunikace s Českou Národní Bankou, založení nové organizace, živnostenské oprávnění, zajištění plných mocí, návrhy smluv mezi servisní organizací a společnostmi ALFA a BETA, řešení podpůrných funkcí, kterými jsou např. evidence majetku a jeho převod, problematika zpracování mezd, nájemní smlouvy a nákup materiálu. Finanční oblast: zde bych zařadil zvážení dopady daní a jejich optimalizaci, vybudování účetního a auditního systému. Bude nutné zajistit vnitřní kontrolní systém, který zajistí pravdivost, celistvost, vypovídací schopnost zpracovávaných a předávaných informací mezi společnostmi a servisní organizací. Ve třetí oblasti se již budeme zabývat vlastní problematikou IT. Bude nutné zmapovat veškeré dodavatele, prověřit smluvní vztahy a jejich případné úpravy, nákupy nového materiálu pro zajištění provozu atd. Další podstatnou výhodou tohoto řešení je případná možnost využití servisní organizace i pro jiné oblasti než je jen IT. Využití by zcela jistě našlo například i v oblasti řešení pojistných událostí, kde by mohlo dojít k přiblížení a zefektivnění procesů. Další oblast je digitalizace, která je v obou společnostech řešena poměrně odlišně, a tudíž je zde také velký prostor k optimalizaci. Vytvoření této organizace až ve druhém kroku navrhuji ze dvou důvodů. První důvod jsou omezené zdroje pro tyto aktivity v současné době. Druhým důvodem je fakt, že se obě IT budou optimalizovat a domnívám se, že bude efektivnější a tím pádem levnější realizovat přesun IT až po jejich optimalizaci. Dojde tak dle mého názoru k úspoře nezanedbatelných finančních nákladů. 50

51 Na schématu č. 5. jsem navrhl cílovou organizační strukturu. V současné době jsem záměrně neuvedl počty zaměstnanců v jednotlivých jednotkách, protože dojde k optimalizaci aplikací a procesů na IT, nicméně předpokládám jejich podstatnou redukci oproti stávajícímu stavu minimálně o 30%. Dále bych rád navrhl zavedení kariérního postupu zaměstnanců. Bylo by dobré vytvořit základní kostru zaměstnanců, kteří by měli hluboké znalosti daných oblastí. Tito pracovníci by pak byli doplňováni kolegy na pozicích juniorů. Tento princip by dle mého názoru také napomohl snížit náklady a zachovat kontinuitu v návazných procesech. Schéma č. 5: Organizační schéma cílové struktury Zdroj: vlastní znalosti 5.3 Cílová SW architektura Na základě analýzy v kapitole 4.2 Analýza základních oblastí (Infrastruktura, Aplikace), byla navržena následující aplikační architektura. Základním předpokladem bylo minimalizování duplicitních aplikací zajišťující stejnou funkcionalitu, zohlednění obchodních požadavků odborných oddělení, jejich priorit a zkvalitnění služeb poskytujících IT. Druhým efektem je optimalizace celé architektury, aby další vývoj 51

52 v aplikacích byl co nejjednodušší. Kompletní znázornění integračních příležitostí jsem připravil na obrázku č. 16. Budoucí stav je kromě rozdělení do již známých business oblastí rozdělen také do různých časových intervalů. Následující návrhy nezohledňují cenu migračních aktivit a jejich efektivnost. Této problematice se budu věnovat v kapitole č. 7 Finanční dopad integrace. Obrázek č. 16: Navržená integrace aplikací Zdroj: vlastní znalosti 52

53 V oblasti Životního pojištění dojde k redukci z původních čtrnácti aplikací na cílových sedm. Postupně dojde k útlumu aplikací KDP, APO, APO MF, HERMES, KOMIX, JOS WEPOS a FSCD. Jako primární aplikace bude použita aplikace SYNPAC a po přechodnou dobu migrace ještě aplikace APO. Tato přechodná doba je navržena na 5 let. V oblasti Neživotního pojištění dojde k ještě výraznějšímu utlumení aplikací. Celkový počet aplikací evidovaných v této části je 29 a po optimalizaci dojde k redukci na 19. Jako cílové aplikační portfolio jsou navrhovány aplikace TIA a GOLEM. Po přechodnou dobu budou ještě podporovány aplikace VIAS a aplikace CP (cestovní pojištění). Pro migraci dat z primárního systému VIAS do aplikace TIA bude použita tzv. obchodní migrace. Ta spočívá v postupném převodu pojistných smluv v době jejich výročí prostým přepisem do nové aplikace. Tuto metodu lze použít u neživotních pojištění, kde je délka smlouvy v řádu maximálně několika let. Naopak u životního pojištění, kde je délka smlouvy v řádech desítek let, je nutné dělat migraci i aktivních smluv. Zajímavostí v této oblasti je vznik dvou nových aplikací. Dle vyjádření uživatelů jsou stávající aplikace na likvidaci pojistných událostí nevyhovující v obou společnostech, proto bude připraven návrh na aplikaci novou. Nad tímto novým systémem vznikne nová Expertní aplikace, která bude umožňovat provádět různé analýzy dat, což by mělo mít pozitivní dopad na úsporu nákladů. V oblasti Plateb jsou navrženy dvě fáze integrace. V první fázi dojde k napojení aplikace SYNPAC na aplikaci CZP, čímž dojde k zachování funkcionalit. První fáze by měla být ukončena v horizontu cca třech let. Druhá fáze již zajistí migraci původních dat z aplikací Inkas, Exkas, Fakturace do aplikace CZP a měla by proběhnout do pěti let. Celkový cílový počet aplikací je navrhován 6, oproti současnému stavu 10. Oblast Finance a controlling je poměrně specifická, poněvadž zde nedojde k redukci aplikací. Důvod je jednoduchý. Na trhu budou nadále působit obě společnosti samostatně, a tudíž je nutné zachovat účetnictví a výkaznictví oddělené. Protože obě společnosti budou spadat pod stejný holding a ten bude vyžadovat po obou společnostech stejné vykazování, je zde příležitost k sladění účetní osnovy, formy vykazování atd. Jako cílová platforma v nově vzniklém holdingu pro oblast účetnictví byla nařízena aplikace SAP, ale obě společnosti již tento software implementovaný mají. V oblasti Tisky budou cílově dvě aplikace. První je aplikace PrintNet úzce spolupracující s aplikací DA. Toto předpokládá migraci aplikace z elektronického archivu společnosti ALFA do aplikace DA a útlum aplikací OPUS, Tisky, Kofax do aplikace PrintNet. 53

54 Poslední aplikace, která bude zrušena v této oblasti, je aplikace ARC, bude nahrazena JOK a Kukátkem. Oblast Obchod je druhou oblastí cílové architektury, kde nedojde k redukci počtu aplikací. Důvod je velice podobný jako u oblasti finanční. Vzhledem k faktu, že zde budou na trhu nadále působit dvě společnosti, je jednoznačný požadavek ze strany obchodu na zachování odlišností v této oblasti. Přesto zde cíleně vzniknou dvě nové aplikace a těmi jsou Sales Workspace a BMS. Sales Workspace má být nástroj obchodního zástupce, který mu bude napomáhat ve všech jeho směrech činností. Od kalkulace pojistného, přes centrální evidenci informací o klientech až po vedení vlastní agentury. BMS bude mít za cíl nastavit systematický kariérní žebříček u všech zaměstnanců a obchodních partnerů společností. Já osobně navrhuji zachovat stávající aplikace tak, jak jsou a jak s nimi jsou zvyklí pracovat stávající zaměstnanci a nové aplikace zpracovat tak, aby byly využitelné pro obě společnosti a umožnili parametricky nastavit požadavky obou společností. Aktivity v této oblasti by měly skončit v horizontu cca 5. let. Další oblastí je Kontaktní centrum. Zde opět dojde k výrazné redukci používaných aplikací a to na celkový počet čtyř. V první fázi dojde k migraci IPCC Expres do verze Enterprise a zavedení nové aplikace JWS, což bude systém, který bude integrovat všechny potřebné funkcionality. Mezi ně patří napojení na OpenMinder, Kukátko, primární systémy, DA, intranetu atd. Další krokem v této části bude napojení IPCC s DWH, což umožní lepší možnosti při tvorbě reportů. V druhé fázi bude integrace IPCC s aplikací JWS. 5.4 Cílová infrastruktura Navrhnout cílovou infrastrukturu po základní analýze je velice složité a riziko chybného návrhu je poměrně vysoké. Z tohoto důvodu zde navrhnu pouze několik oblastí, které se musí následně detailně propracovat. Mezi tato základní témata patří: Virtualizace serverů. Virtualizací se rozumí uspořádání, kdy k systémovému zdroji můžeme přistupovat různými způsoby bez ohledu na to, kde je HW fyzicky umístěn. S hardwarovou vizualizací má poměrně bohaté zkušenosti společnost ALFA. Je zde nasazen VMware Server. Jiné možnosti jsou například využití aplikační vizualizace. Jednotlivé aplikace v tomto případě běží na hardware a používají jeho zdroje, nicméně běží v malém virtuálním prostředí, kde jsou komponenty pro jejich běh. Toto se chová jako mezi aplikací a operačním systémem. Virtualizace vede ke snížení nákladů, neboť se uspoří na počtu serverů a tím pádem dojde i ke snížení nutné administrace těchto strojů. 54

55 Rozšíření datových prostor. Vzhledem k plánované integraci aplikací je nutné pro tyto aplikace zajistit dostatečně dostupný hardware. Je nutné prozkoumat, zda cílový HW pojme nový objem dat, druhou otázkou pak je, zda zvýšený objem dat a počet uživatelů nezpomalí běh aplikace pro uživatele. Zavedení monitorovacího systému ve společnosti ALFA. Monitorovací systém je nástroj pro správu, řízení a monitoring rozsáhlých zařízení v sítích LAN 19 a případně i WAN 20. Nasazení monitorovacího systému výrazně zvyšuje efektivitu správy rozsáhlých sítí. Monitorovací systém neustále sleduje jednotlivé klienty a služby. V případě výpadku některé služby je tato informace předávána do operačního střediska, kde běží nepřetržitý dozor 24 hodin a 7 dní v týdnu. V případě zásadního výpadku jsou poté ihned kontaktovány odpovědné osoby za danou oblast, aby bylo vše co nejrychleji opraveno. Samozřejmě u zásadních funkcionalit operátoři přepnou systémy na záložní řešení. Takto propracovaný systém funguje ve společnosti BETA a je zde velký prostor pro použití i v druhé společnosti. Jednotná správa uživatelů. Vzhledem k ostatním aktivitám, kde chceme například sjednotit uživatelskou podporu, zavést jednotné aplikační portfolio a společnou pracovní stanici, je nutné zajistit i shodnou evidenci uživatelských přístupů a nastavení oprávnění uživatelům. Přesunutí mainframe 21 do holdingového datového centra. Některé aplikace společnosti BETA běží na vlastním mainframu. Z výkonnostních důvodů je nutné provést rozšíření tohoto mainframu. Vzhledem k tomu, že mainframe je využíván i v jiných holdingových společnostech, je nutné zvážit přesunutí aplikací do holdingových datových center. Jako problém se zde může jevit rozdílná verze operačních systémů, což přinese nutnost vše důkladně otestovat. Společná uživatelská podpora. Dnes má každá společnost svůj vlastní tým zajišťující uživatelskou podporu. Zde je nutné týmy sjednotit a nastavit shodné procesy pro podporu uživatelů. Přesunutí provozu servisního centra SAP společnosti ALFA do společnosti BETA. Sjednocení IP telefonie. IP telefonie, někdy také nazývána VoIP (Voice over Internet Protokol), umožňuje přenos digitalizovaného hlasu prostřednictvím počítačové 19 LAN Local Area Network takto jsou označovány počítačové sítě malého rozsahu. Pokrývá například domácnosti, společnosti. Dosahují poměrně vysokých přenosových rychlostí, řádově v Gb/s. 20 WAN Wide Area Network takto jsou značeny rozsáhlé počítačové sítě. 21 Mainframe je sálový počítač konstruován pro vysoké výkony. Například se jedná o Systém IBM/

56 sítě. Díky tomu je telefonování v rámci jedné společnosti téměř zdarma, v podstatě jen za cenu počátečních investic do zařízení. Vzhledem k faktu, že přenos dat probíhá pomocí paketů, je možné využít jednu linku pro několik hovorů současně. Tato aktivita může uspořit nemalé finanční částky. 5.5 Návrh časového plánu integrace z pohledu IT V následujících dvou schématech navrhnu časový postup v implementaci změn v oblasti infrastruktury a aplikační architektury. Žlutou barvou jsou označeny aktivity, které již probíhají, modře jsou označeny aktivity, které jsou již schválené, a bíle pak vidíme aktivity, které se budou teprve schvalovat vedením na základě úvodní studie. Při návrzích jsem zohledňoval kapacitní možnosti personálních zdrojů v obou společnostech. Na schématu č. 6 je zobrazeno schéma časové implementace jednotlivých aktivit. Schéma č. 6: Časový návrh integrace infrastruktury Zdroj: vlastní znalosti Při návrhu integrace v oblasti aplikační architektury jsem musel ještě zohledňovat návaznosti jednotlivých aktivit. Například migrace ze systému KDP do systému SYNPAC je podmíněna dokončením migrace v oblasti Platby (migrace aplikací Inkas, Exkas, 56

57 Fakturace a AZP do systému CZP). Obdobná návaznost je mezi oblastí Neživotního pojištění a Tisků. V oblasti Neživotního pojištění (migrace aplikace VIAS do aplikace TIA) jsem zatím neuvedl detailnější časový plán, neboť nemohu doporučit schválení úvodní studie u této aktivity. Důvod, proč tato aktivita není zatím schválena, je poměrně vysoké navýšení provozních nákladů po této migraci a blíže je uvedu v kapitole Závěry a doporučení. Grafické znázornění časového harmonogramu je uvedeno na schématu č. 7. Schéma č. 7: Časový návrh integrace aplikační architektury Zdroj: vlastní znalosti Kromě popisu integračních aktivit jsem také navrhl, kdo bude za danou aktivitu odpovědný. Uvedl jsem, zda odpovědnost bude mít osoba z oblasti IT, nebo z odborného oddělení. V dalším sloupci jsou uvedeny předpokládané doby trvání jednotlivých aktivit. Číslo vyjadřuje potřebné pracovní dny, nikoliv vlastní celkovou délku aktivity. 57

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

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

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

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

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

Podrobná analýza k aktivitě č. 3 - implementace procesního řízení do praxe úřadu

Podrobná analýza k aktivitě č. 3 - implementace procesního řízení do praxe úřadu Příjemce dotace: Město Moravská Třebová Název projektu: Zvýšení kvality řízení a poskytovaných služeb MÚ Moravská Třebová Registrační číslo projektu: CZ.1.04/4.1.01/89.00116 Podrobná analýza k aktivitě

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

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

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

PROVÁDĚCÍ SMLOUVA Č. 2. (č. ev. ČSÚ: 180 2013 S)

PROVÁDĚCÍ SMLOUVA Č. 2. (č. ev. ČSÚ: 180 2013 S) PROVÁDĚCÍ SMLOUVA Č. 2 (č. ev. ČSÚ: 180 2013 S) k Rámcové smlouvě na služby odborné podpory IT v rámci projektu Redesign statistického informačního systému v návaznosti na zavádění egovernmentu v ČR uzavřené

Více

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Aplikace IS, outsourcing, systémová integrace Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Kontext Dodavatelé Strategická Zákazníci ERP Taktická Operativní Kategorie ERP - zaměřeno na

Více

INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005

INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005 INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005 AGENDA definice IS, zavedení pojmů možnosti a rozdělení typická struktura technologie nasazení praktická ukázka

Více

SW podpora projektového řízení

SW podpora projektového řízení Browser MS-Project SW podpora projektového řízení Společnost appcore s.r.o. nabízí služby v oblastech systémové integrace, softwarové integrace a řízení organizace. Veškeré služby naší společnosti jsou

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

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

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

RDF DSPS ROZVOJ PORTÁLU

RDF DSPS ROZVOJ PORTÁLU RDF DSPS ROZVOJ PORTÁLU ČEZ Distribuce, a.s. HSI, spol. s r.o. Zbyněk Businský Miroslav Kaňka ZÁKAZNÍK A DODAVATEL ČEZ DISTRIBUCE, A.S. ČEZ distribuční síť Od r. 2012 implementován GEOPORTÁL (1. ETAPA),

Více

Efektivnější systém pro vyřizování požadavků na IT v ČMSS

Efektivnější systém pro vyřizování požadavků na IT v ČMSS 2 Shared Experience Technologická řešení Efektivnější systém pro vyřizování požadavků na IT v ČMSS Efektivnější systém pro vyřizování požadavků na IT v ČMSS přinesl procesní zpracování požadavků všech

Více

1.05 Informační systémy a technologie

1.05 Informační systémy a technologie Vypracoval Gestor Schválil Listů Příloh D. Marek(EOS/2) EOS VS 5 Směrnice platí pro všechny závody ŠKODA AUTO. Obsah: 1. Použité pojmy a zkratky 2. Plánování IT 3. Pořízení IT 4. Dodání IT 5. Provoz a

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

Personální audit. a personální strategie na úřadech. územních samosprávných celků

Personální audit. a personální strategie na úřadech. územních samosprávných celků Personální audit a personální strategie na úřadech územních samosprávných celků Dělat (vybrat) správné věci je úkolem zejména zastupitelů města. Dělat (vybrat) správné věci Správně je provádět Správně

Více

GINIS na KrÚ Středočeského kraje

GINIS na KrÚ Středočeského kraje 9.4.2014 GINIS na KrÚ Středočeského kraje Informační systém GINIS na Krajském úřadu Středočeského kraje GINIS na KrÚ Středočeského kraje, Václav Pávek, www.gordic.cz GORDIC Specialista v oblasti veřejné

Více

1.05 Informační systémy a technologie

1.05 Informační systémy a technologie Vypracoval Gestor Schválil Listů Příloh D. Marek(EOS/2) EOS VS 7 Směrnice platí pro všechny závody ŠKODA AUTO. Obsah: 1. Použité pojmy a zkratky 2. Plánování IT 3. Pořízení IT 4. Dodání IT 5. Provoz a

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

ADOit. IT architektura a řízení IT služeb. Luděk Kryšpín, Lukáš Dvořák, PADCOM, s.r.o.

ADOit. IT architektura a řízení IT služeb. Luděk Kryšpín, Lukáš Dvořák, PADCOM, s.r.o. ADOit IT architektura a řízení IT služeb Luděk Kryšpín, Lukáš Dvořák, PADCOM, s.r.o. Představení PADCOM Základní informace o firmě Poradenská firma s výhradně českým kapitálem Zahájení činnosti 2008 Počet

Více

Využití EPM 2013 pro podporu řízení projektů - Případová studie

Využití EPM 2013 pro podporu řízení projektů - Případová studie Využití EPM 2013 pro podporu řízení projektů - Případová studie Martin Répal, AutoCont CZ, a.s. Petr Drábek, UniControls, a.s. Klíčový hráč na českém i světovém trhu v oblasti řídicích systémů Ročně realizuje

Více

Business Intelligence

Business Intelligence Business Intelligence Josef Mlnařík ISSS Hradec Králové 7.4.2008 Obsah Co je Oracle Business Intelligence? Definice, Od dat k informacím, Nástroj pro operativní řízení, Integrace informací, Jednotná platforma

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

Reportingová platforma v České spořitelně

Reportingová platforma v České spořitelně Reportingová platforma v České spořitelně Agenda Implementované prostředí Cognos 8 v ČS Marek Varga, Česká spořitelna, a.s. Využití platformy Cognos z pohledu businessu Petr Kozák, Česká spořitelna, a.s.

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

Vnitřní integrace úřadu Středočeského kraje

Vnitřní integrace úřadu Středočeského kraje VIÚ Středočeského kraje, Mgr. Jan Drnovský, Mgr. Václav Pávek 09/11/15 Vnitřní integrace úřadu Středočeského kraje Vnitřní integrace úřadu KUSK Krajský úřad Středočeského kraje 2 Obecné předpoklady řešení

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

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

Novell Identity Management. Jaromír Látal Datron, a.s.

Novell Identity Management. Jaromír Látal Datron, a.s. Novell Identity Management Jaromír Látal Datron, a.s. 19.4.2012 1 Identity management základní vlastnosti Jednoduché a rychlé poskytování uživatelských účtů Samoobslužné funkce pro uživatele Snadný návrh

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

KATALOG SLUŽEB NÁSLEDNÉ PODPORY

KATALOG SLUŽEB NÁSLEDNÉ PODPORY KATALOG SLUŽEB NÁSLEDNÉ PODPORY Společnost WEBCOM a. s. Vám nabízí kompletní pokrytí Vašich požadavků na zajištění služeb technické podpory Microsoft Dynamics přesně podle Vašich potřeb a v požadovaném

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

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER váš partner na cestě od dat k informacím globtech spol. s r.o. karlovo náměstí 17 c, praha 2 tel.: +420 221 986 390 info@globtech.cz

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

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

Business Suite for Notes

Business Suite for Notes Business Suite for Notes Systém BSFN byl vytvořen na základě zkušeností s podporou a řízením procesů v obchodní firmě. Během několika let existence na trhu se osvědčil u mnoha zákazníků. Z nejvýznamnějších

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

Softwarová podpora v procesním řízení

Softwarová podpora v procesním řízení Softwarová podpora v procesním řízení Zkušenosti z praxe využití software ATTIS Ostrava, 7. října 2010 www.attis.cz ATTN Consulting s.r.o. 1 Obsah Koncepce řízení výkonnosti Koncepce řízení výkonnosti

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

Podnikatelský záměr - PZ (Osnova)

Podnikatelský záměr - PZ (Osnova) Příloha č. 5 Podnikatelský záměr - PZ (Osnova) 1 Identifikační údaje žadatele o podporu 1.1 Obchodní jméno, sídlo, IČ/DIČ 1.2 Jméno a příjmení osoby statutárního zástupce žadatele/osoby oprávněné jednat

Více

Chytrá systémová architektura jako základ Smart Administration

Chytrá systémová architektura jako základ Smart Administration Chytrá systémová architektura jako základ Smart Administration Ing. Petr Škvařil, Pardubický kraj Dipl. Ing.Zdeněk Havelka PhD. A-21 s.r.o. 1 Nepříjemné dotazy Jsme efektivní v provozování veřejné správy?

Více

Požadavky na připojení regionálních/metropolitních sítí do CMS

Požadavky na připojení regionálních/metropolitních sítí do CMS Požadavky na připojení regionálních/metropolitních sítí do CMS Verze 1.00 BDO IT a.s. Poradenství v informačních technologiích IČ: 25 05 66 46 DIČ: CZ 25 05 66 46 Městský soud v Praze, oddíl B, vložka

Více

Hynek Cihlář Podnikový architekt 7.11..2013. Od Indoše ke Cloudu

Hynek Cihlář Podnikový architekt 7.11..2013. Od Indoše ke Cloudu Hynek Cihlář Podnikový architekt 7.11..2013 Od Indoše ke Cloudu Jediná jistota je změna Rychlost vstupu na trh, zvyšování efektivity, zjednodušení funkčnosti, snižování nákladů Obtížnost řízení a kontroly

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

Cobit 5: Struktura dokumentů

Cobit 5: Struktura dokumentů Cobit 5: Struktura dokumentů Cobit 5 Framework; popisuje základní rámec (principy, předpoklady, vazby na jiné rámce), Cobit 5 Enabler Guides; jde o dokumenty, které jsou obecným návodem na vytváření předpokladů

Více

Strategie a Perspektivy ČP OZ ICT Služby 2015

Strategie a Perspektivy ČP OZ ICT Služby 2015 Strategie a Perspektivy ČP OZ ICT Služby 2015 Jan Přerovský Česká pošta, s.p., Odštěpný závod ICT služby 9. 9. 2014 1 Mikulov 09.09. 2014 Obsah Obsah Cíle strategie předpoklady úspěchu strategie přehled

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

HREA Excellence Award 2013

HREA Excellence Award 2013 HREA Excellence Award 2013 I. Základní informace o projektu 2. kategorie společnost nad 500 zaměstnanců Název projektu: Kariérní plánování v centru sdílených služeb Siemens, s.r.o. Career@GSS Předkladatel

Více

Elektronická podatelna a výpravna České správy sociálního zabezpečení v návaznosti na systém datových schránek

Elektronická podatelna a výpravna České správy sociálního zabezpečení v návaznosti na systém datových schránek Elektronická podatelna a výpravna České správy sociálního zabezpečení v návaznosti na systém datových schránek 8.4.2013 Internet ve státní správě a samosprávě Hradec Králové Petr Oplátek, Simona Rákosová

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

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Příloha č. 3 k č.j. MV-159754-3/VZ-2013 Počet listů: 7 TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Nové funkcionality Czech POINT 2012 Popis rozhraní egon Service Bus Centrální Místo Služeb 2.0 (dále jen CMS

Více

JAK NA PAPERLESS. Petr Dolejší Senior Solution Consultant

JAK NA PAPERLESS. Petr Dolejší Senior Solution Consultant JAK NA PAPERLESS Petr Dolejší Senior Solution Consultant PAPERLESS CO TO VLASTNĚ JE Wikipedia - Paperless představuje fungování, kde je odstraněno nebo výrazně omezeno používání papíru. Toho se dosáhne

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

Kompetence řídících pracovníků k zajištění rozvoje ICT ve škole či školském zařízení Osobní kompetenční portfolio

Kompetence řídících pracovníků k zajištění rozvoje ICT ve škole či školském zařízení Osobní kompetenční portfolio Kompetence řídících pracovníků k zajištění rozvoje ICT ve škole či školském zařízení Osobní kompetenční portfolio Radek Maca NIDM Obsah prezentace Vize aneb modely budoucnosti škol Škola jako učící se

Více

PAVEZA &EVEZA PRODUKTOVÉ PORTFOLIO ELEKTRONICKÝCH NÁSTROJŮ PRO SPRÁVU VEŘEJNÝCH ZAKÁZEK

PAVEZA &EVEZA PRODUKTOVÉ PORTFOLIO ELEKTRONICKÝCH NÁSTROJŮ PRO SPRÁVU VEŘEJNÝCH ZAKÁZEK PAVEZA & PRODUKTOVÉ PORTFOLIO ELEKTRONICKÝCH NÁSTROJŮ PRO SPRÁVU VEŘEJNÝCH ZAKÁZEK PAVEZA / PAVEZA LIGHT Intranetová aplikace PAVEZA (a její odlehčenější verze PAVEZA LIGHT) jako velmi efektivní elektronický

Více

Příloha č. 2 ke smlouvě. Rozsah a podmínky provozní podpory

Příloha č. 2 ke smlouvě. Rozsah a podmínky provozní podpory Příloha č. 2 ke smlouvě Rozsah a podmínky provozní podpory Předmět smlouvy v části Provozní podpora zahrnuje zejména: A) Technickou, uživatelskou a administrativní správu a provozní podporu APV IS ROS

Více

BEZPEČNÁ SPRÁVA KLÍČŮ POMOCÍ HSM. Petr Dolejší Senior Solution Consultant

BEZPEČNÁ SPRÁVA KLÍČŮ POMOCÍ HSM. Petr Dolejší Senior Solution Consultant BEZPEČNÁ SPRÁVA KLÍČŮ POMOCÍ HSM Petr Dolejší Senior Solution Consultant OCHRANA KLÍČŮ A ZOKB Hlavní termín kryptografické prostředky Vyhláška 316/2014Sb. o kybernetické bezpečnosti zmiňuje: v 17 nástroj

Více

Mobilní aplikace ve světě ERP. Asseco Solutions, a.s. a Simac Technik ČR, a.s.

Mobilní aplikace ve světě ERP. Asseco Solutions, a.s. a Simac Technik ČR, a.s. Mobilní aplikace ve světě ERP Michal Hanko Petr Kolda Asseco Solutions, a.s. a Simac Technik ČR, a.s. Skupina Asseco Solutions Asseco Solutions je průkopníkem a vizionářem na poli informačních systémů

Více

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Aplikace IS, outsourcing, systémová integrace. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Aplikace IS, outsourcing, systémová integrace Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Kontext Dodavatelé Strategická Zákazníci ERP Taktická Operativní Kategorie ERP - zaměřeno na

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

Ú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

Příloha č. 3: Technické zadání zakázky Instalace a služby pro technologické centrum MÚ Pohořelice

Příloha č. 3: Technické zadání zakázky Instalace a služby pro technologické centrum MÚ Pohořelice Příloha č. 3: Technické zadání zakázky Instalace a služby pro technologické centrum MÚ Pohořelice Účelem veřejné zakázky je vybudování, provoz a údržba infrastruktury pro provozování aplikací a služeb

Více

Řízení rizik. Ing. Petra Plevová. plevova.petra@klikni.cz http://plevovapetra.wbs.cz

Řízení rizik. Ing. Petra Plevová. plevova.petra@klikni.cz http://plevovapetra.wbs.cz Řízení rizik Ing. Petra Plevová plevova.petra@klikni.cz http://plevovapetra.wbs.cz Procesní řízení a řízení rizik V kontextu současných změn je třeba vnímat řízení jakékoli organizace jako jednoduchý,

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

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

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

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

KATEDRA ŘÍZENÍ PODNIKU. Obchodní, organizační, personální plán, IT

KATEDRA ŘÍZENÍ PODNIKU. Obchodní, organizační, personální plán, IT Business model KATEDRA ŘÍZENÍ PODNIKU Obchodní, organizační, personální plán, IT Mapa cílů Vyšší zisk Vyšší tržby Finanční stabilita image Rozšíření na další trhy Navýšení stávajícíc h tržních podílů Udržení

Více

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1 Metodický list č. 1 Cíl: Cílem předmětu je získat přehled o možnostech a principech databázového zpracování, získat v tomto směru znalosti potřebné pro informačního manažera. Databázové systémy, databázové

Více

Telelogic Focal Point využití pro řízení a optimalizaci projektového portfolia Verze 1.0

Telelogic Focal Point využití pro řízení a optimalizaci projektového portfolia Verze 1.0 DISTRIBUTOR White Paper Verze 1.0 Ing. Jiří Gryc 26.4.2007 Tento dokument ve stručnosti představuje možnost využití špičkového Telelogic Focal Point pro řízení a optimalizaci projektového portfolia. Další

Více

Slovenská spořitelna:

Slovenská spořitelna: Případová studie Slovenská spořitelna: Microsoft Dynamics CRM pro správu klientů ze segmentu malých a středních podniků Jak jsme Slovenské spořitelně usnadnily a zefektivnily práci s klienty ze segmentu

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

Strategie rozvoje ICT resortu MPSV v souvislosti s novými technologiemi a trendy. Bc. Vladimír Šiška, MBA, I. NM, MPSV

Strategie rozvoje ICT resortu MPSV v souvislosti s novými technologiemi a trendy. Bc. Vladimír Šiška, MBA, I. NM, MPSV Strategie rozvoje ICT resortu MPSV v souvislosti s novými technologiemi a trendy. Bc. Vladimír Šiška, MBA, I. NM, MPSV Cíle Zefektivnění provozu ICT v resortu (MPSV, ČSSZ, ÚP, SUIP) jednu službu (funkci)

Více

Projekt Zefektivnění činnosti TAČR v oblasti podpory VaVaI a podpora posilování odborných kapacit organizací veřejné správy v oblasti VaVaI

Projekt Zefektivnění činnosti TAČR v oblasti podpory VaVaI a podpora posilování odborných kapacit organizací veřejné správy v oblasti VaVaI Projekt Zefektivnění činnosti TAČR v oblasti podpory VaVaI a podpora posilování odborných kapacit organizací veřejné správy v oblasti VaVaI Reg. č. CZ.1.04/4.1.00/D4.00003 Projekt Zefektivnění činnosti

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

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

Software a související služby

Software a související služby Software a související služby Webové technologie, přístup uživatele do systému přes webový prohlížeč Software na zakázku Webové stránky a e-shopy s plnou administrací Intranet, webové aplikace, informační

Více

Korporátní systém řízení ÚSC přístup v Liberci. Ing. Jaroslav Bureš 21.4.2011

Korporátní systém řízení ÚSC přístup v Liberci. Ing. Jaroslav Bureš 21.4.2011 Korporátní systém řízení ÚSC přístup v Liberci Ing. Jaroslav Bureš 21.4.2011 Východiska projektu KSŘ SML Výzvy vedení města: Transparentnost Efektivita Profesionalita K naplnění těchto výzev bude muset

Více

Odbor informatiky a provozu informačních technologií

Odbor informatiky a provozu informačních technologií POLICEJNÍ PREZIDIUM ČR Odbor informatiky a provozu informačních technologií Příloha č. 1 a) název zakázky, Technická podpora software pro systém NS-VIS a VISMAIL b) předmět a rozsah plnění veřejné zakázky

Více

Pořízení nových systémů na MPSV děláme to ponovu

Pořízení nových systémů na MPSV děláme to ponovu Pořízení nových systémů na MPSV děláme to ponovu 13. dubna 2015 Hradec Králové Ing. Iva Merhautová, MBA Mgr. Bc. et Bc. Robert Baxa Michal Rada ICT MPSV Základní oblasti řízení: ICT ministerstva práce

Více

Strategie, architektury a projekty jako nástroj řízení IT ve veřejné správě

Strategie, architektury a projekty jako nástroj řízení IT ve veřejné správě Strategie, architektury a projekty jako nástroj řízení IT ve veřejné správě Tomáš Hrabík ICZ a.s. Konference Řízení informatiky v soukromém a veřejném sektoru 1 Otázky 1. Je egovernment o elektronizaci

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

Virtualizace serverů v ČSOB

Virtualizace serverů v ČSOB 5 Shared Experience Technická řešení Virtualizace serverů v ČSOB ČSOB jsme pomohli vybudovat globální evropské data-centrum, ušetřit náklady a zkrátit dobu dodání serverů pro nové aplikace a to díky virtualizaci

Více

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4 DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4 Zadavatel: Česká republika Ministerstvo životního prostředí Sídlo: Vršovická 1442/65, 100 10 Praha 10 IČO: 00164801 Jednající: Název veřejné zakázky: Ing.

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

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

E-DOCHÁZKA VE ŠKODA AUTO PREZENTACE PROJEKTU 27.01.2011

E-DOCHÁZKA VE ŠKODA AUTO PREZENTACE PROJEKTU 27.01.2011 E-DOCHÁZKA VE ŠKODA AUTO PREZENTACE PROJEKTU 27.01.2011 TOMÁŠ BONHARD, ONDREJ TROJÁK Škoda Auto AGENDA Výchozí fakta Cíle projektu Základní principy procesu Kontextové schéma Docházkové terminály Schvalovací

Více

1. Dostupné řešení CRM

1. Dostupné řešení CRM 1. Dostupné řešení CRM 1.1. Popis řešení Kompaktní CRM řešení s garantovaným časem zavedení! Komunikační systémy společnosti Siemens ve spojení se speciálním startovacím balíčkem osvědčeného evropského

Více

Přehled použitých výrazů a zkratek

Přehled použitých výrazů a zkratek Orgány vývoje klinických standardů a proces plánování Příloha 4b Závěrečné zprávy projektu č. NS 10650-3/2009 podpořeného Interní grantovou agenturou MZ ČR, Výzkum metod standardizace zdravotní péče zaměřený

Více

PROCESY CO ZÍSKÁTE: Předpoklad pro certifikace ISO. Lean Six Sigma Fast Track

PROCESY CO ZÍSKÁTE: Předpoklad pro certifikace ISO. Lean Six Sigma Fast Track PROCESY CO ZÍSKÁTE: Jasná pravidla pro provádění činností, uložení know-how Jasně definované zodpovědnosti za celý proces i jednotlivé kroky Zprůhlednění organizace plynoucí z jasně definovaných vstupů,

Více

Výzkum komunikačního účinku propagace firmy GOTECH s.r.o. Eva Solařová

Výzkum komunikačního účinku propagace firmy GOTECH s.r.o. Eva Solařová Výzkum komunikačního účinku propagace firmy GOTECH s.r.o. Eva Solařová Bakalářská práce 2008 ABSTRAKT Tato bakalářská práce se zabývá analýzou marketingové komunikace firmy GOTECH s.r.o. Rozbor probíhá

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

Praktické aspekty ABC

Praktické aspekty ABC Praktické aspekty ABC Metoda maticového propočtu 1. Zjednodušený procesní model 2. Produktový přístup k nákladům 3. Analýza vnitřních produktů 4. Sestavení ABC rozpočtů 5. Maticový propočet Tomáš Nekvapil

Více

CHARAKTERISTIKA VEŘEJNÉ ZAKÁZKY

CHARAKTERISTIKA VEŘEJNÉ ZAKÁZKY Příloha č. 1 CHARAKTERISTIKA VEŘEJNÉ ZAKÁZKY Veřejná zakázka Poskytování služeb outsourcingu Zadavatel: Nemocnice Český Krumlov a.s., sídlem: Český Krumlov, Horní Brána 429, PSČ 381 27 IČ: 260 95 149 DIČ:

Více

IntraVUE 2.0.3 Co je nového

IntraVUE 2.0.3 Co je nového IntraVUE 2.0.3 Co je nového Michal Tauchman Pantek (CS) s.r.o. Červen 2008 Strana 2/8 Úvod IntraVUE je diagnostický a podpůrný softwarový nástroj pro řešení komunikačních problémů, vizualizaci a dokumentaci

Více