Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií
Systémová integrace nezbytný předpoklad úspěšnosti zavádění IS/IT v podniku Bakalářská práce
Autor:
Jiří Nováček Informační technologie, správce informačních systémů
Vedoucí práce:
Praha
doc. Ing. Bohumil Miniberger, CSc.
červen, 2011
Prohlášení:
Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu.
Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.
V Lázních Toušeni dne:
Jiří Nováček
Poděkování Chtěl bych poděkovat panu doc. Ing. Bohumilu Minibergerovi, CSc. za odborné vedení a pomoc při vypracování mé bakalářské práce.
Dále bych chtěl poděkovat panu Milanu Flutkovi z firmy Kancelářské stroje s.r.o a panu Miroslavu Sládkovi z firmy BitServis s.r.o, oběma za poskytnutí konzultace a cenných informací a poznatků k praktické aplikaci systémové integrace v řízení a podmínkách servisní firmy.
Anotace práce Cílem je seznámení čtenářů s problematikou systémové integrace z pohledu úspěšnosti zavádění IS/IT v podniku. Nejprve se věnuji tomu, co nás vede k využívání systémové integrace. Poté se zmiňuji o tom, co je důležité při přípravě projektu systémové integrace a jaké jsou kritéria při volbě systémového integrátora. V závěru práce se zabývám praktickým uplatněním systémové integrace a zdrojům informací dostupným v České republice. Annotation The objective of this work is to acquaint readers with problems of system integration from the perspective of successful implementation in a company. At first, I attend to things that lead us to exploitation of system integration. Then I mention things that are important during preparation of project of system integration and what criterions are during selection of system integrator. In the conclusion, I deal with practical use of system integration and sources of information reachable in the Czech Republic.
Obsah práce Obsah práce ............................................................................................................................................................. 5 Úvod ........................................................................................................................................................................ 6 1. Důvody zavádění systémové integrace ............................................................................................................ 9 1.1 Počátky systémové integrace ................................................................................................................. 9 1.2 Účel a základ systémové integrace ...................................................................................................... 10 1.3 Důsledky systémové integrace na chod firmy...................................................................................... 11 1.4 Problémy systémové integrace............................................................................................................. 11 2. Stupně systémové integrace........................................................................................................................... 13 2.1 Datová integrace .................................................................................................................................. 13 2.2 Integrace aplikací ................................................................................................................................. 13 2.3 Integrace informačních technologií pro podporu činnosti podniku...................................................... 13 2.4 Integrace způsobu ovládání aplikací .................................................................................................... 14 2.5 Integrace metodická ............................................................................................................................. 15 2.6 Integrace hardwarová a technologická ................................................................................................. 15 3. Úrovně systémové integrace .......................................................................................................................... 18 4. Způsoby řešení vlastního IS/IT...................................................................................................................... 21 5. Systémový integrátor ..................................................................................................................................... 25 5.1 Důvody pro využití služeb systémového integrátora ........................................................................... 25 5.2 Faktory pro výběr systémového integrátora ......................................................................................... 25 5.3 Úlohy plněné systémovým integrátorem ............................................................................................. 27 5.4 Personální zajištění systémového integrátora ...................................................................................... 28 5.5 Výběr systémového integrátora............................................................................................................ 30 6. Metody systémové integrace ......................................................................................................................... 32 6.1 Úvod .................................................................................................................................................... 32 6.2 Metodika MDIS ................................................................................................................................... 33 6.3 Možnosti přístupu k řešení IS/IT ......................................................................................................... 35 6.3.1 Druhy pohledů ze strany uživatelů na IS/IT .................................................................................... 36 6.4 Přístupy řešitelů k IS/IT ....................................................................................................................... 37 6.4.1 Dimenze první skupiny .................................................................................................................... 38 6.4.2 Dimenze druhé skupiny ................................................................................................................... 40 6.5 Vytvoření konceptuálního schématu pomocí MDIS ............................................................................ 47 6.5.1 Konceptuální schéma MDIS ............................................................................................................ 47 7. Úprava metodiky MDIS na určitý projekt ..................................................................................................... 49 7.1 Důvody pro úpravu metodiky na určitý projekt ................................................................................... 49 7.2 Vytváření prototypů při práci na projektech IS/IT ............................................................................... 50 7.3 Přírůstkový přístup k tvorbě IS/IT ....................................................................................................... 51 8. Modelový podnik a SI ................................................................................................................................... 52 8.1 Vývoj vnitropodnikového informačního systému ................................................................................ 52 8.2 Shrnutí.................................................................................................................................................. 54 9. Systémová integrace v ČR............................................................................................................................. 55 9.1 Jak na výběr systémového integrátora ................................................................................................. 55 9.2 Internet a systémová integrace ............................................................................................................. 56 9.3 Kvalita informačních zdrojů ................................................................................................................ 56 9.3.1 Použití zprostředkované informace ................................................................................................. 56 9.3.2 Používání firemních webových informací ....................................................................................... 56 9.3.3 Veřejné seznamy a ankety ............................................................................................................... 57 9.3.4 Informace z tisku a internetových médií.......................................................................................... 57 10. Závěr.......................................................................................................................................................... 59 11. Seznam použité literatury .......................................................................................................................... 60
5
Úvod Cílem mé práce bylo přehledně popsat problematiku systémové integrace z pohledu zavádění IS/IT v podniku Systémová integrace prošla hlavně v průběhu posledních dvou desetiletí významným rozvojem. Cílem této práce je ukázat problematiku systémové integrace v celé její současné šíři a vysvětlit, proč je její správné provádění jednou z důležitých podmínek nejenom pro úspěšné zavádění podnikového IT, ale i fungování podniku samotného. Rozvoj informatiky v podnikové sféře byl úzce svázán s rozvojem nástrojů pro ekonomické řízení. Jedna z možností, jak si udržet konkurenceschopnost na trhu a optimalizovat ekonomické výsledky, je optimalizace, efektivní využívání a řízení rozvoje vlastních zdrojů podniku. Je to právě rozvoj metod a nástrojů pro ekonomické řízení, kterým informatika dává do ruky potřebné nástroje. Zároveň je však informatika jako součást podnikového portfolia zdrojů sama subjektem ekonomického řízení a řadou charakteristik a požadavků podobných jiným oblastem. Cílem systémové integrace je zajistit ekonomické, ale přitom efektivní nasazení, provozování a rozvoj prostředků informatiky v podnikovém prostředí. Systémová integrace přitom má značnou šíři záběru (technické prostředky, lidské zdroje, portfolio služeb) a značnou provázanost do všech klíčových oblastí činností moderního podniku. V průběhu času se v jejím rámci vyvinuly a využívají různé metody, od obecně zaměřených až po speciální. Z historického pohledu se původní, vyhraněně technický záběr systémové integrace, začal postupně rozšiřovat i do oblasti optimalizace služeb. Spolu s tím postupovala podpora efektivního řízení vnitropodnikových procesů a následně i procesů obchodních. V řadě oblastí nyní systémová integrace zasahuje i za rámec vnitropodnikové sféry. V souladu s hlavním cílem této práce, tj. seznámením s problematikou systémové integrace a její provázanosti s úspěšným zaváděním informačních systémů a technologií v podniku, je obsah zpracován v několika navazujících částech. V úvodních kapitolách jsou vysvětleny kořeny a obsah systémové integrace, následují vysvětlení aspektů důležitých při přípravě projektu systémové integrace a volbě systémového integrátora. Navazuje popis kritérií pro výběr vhodné metody, určené při projektech systémové integraci, s podrobným popisem metody MDIS. V závěrečných částech shrnuji praktické poznatky a přínosy ze zpracování práce. 6
Literární rešerše Při zpracování bakalářské práci jsem vycházel jednak z přednášek předmětu Organizační a informační strategie Doc. Ing. B. Minibergera, CSc., jednak z doporučené literatury k těmto přednáškám. Jedná se o publikaci Prof. Ing. Jiřího Voříška, CSc. jejíž přesný název je uveden v seznamu literatury na konci této práce. Dále jsem použil elektronické monografie, včetně firemních, opět s řádnou citací. Pokud byly převzaty části zdrojů beze zbytku, jsou uvedeny kurzívou a označeny uvozovkami. Jinak jsem texty upravil podle svého uvážení, abych sjednotil tyto části s celkovou koncepcí bakalářské práce.
7
Volba metodologie Při zpracování bakalářské práce jsem postupoval podle Metodických pokynů Bankovního institutu vysoká škola, které jsou dostupné na informačním systému BIVŠ na adrese https://is.bivs.cz/auth/dok/fmgr.pl?ag=do;furl=/do/6110/general/SO-JK/51297/;info= . Věcnou
náplň
bakalářské
práce
jsem
uspořádal
podle
metodiky
MDIS
(Multidimenzionální vývoj informačních systémů), která byla vyvinuta na katedře informačních technologií VŠE Praha, i když se v mém případě nejedná o projekt vývoje IS, ale pouze o jeho verbální popis. Vzhledem k zaměření této práce jsem nepokládal za vhodné používat formální modelovací jazyky typu UML (Unified Modelling Language), nebo jazyk ARIS Profesora Scheera1, či jiných, které jsou v systémovém inženýrství obvyklé.
1
ARIS Platform - Špičkové technologie pro řízení podnikových procesů [on/line][cit.2011-06-21]. Dostupný z: http://www.ids-scheer.cz/cz/ARIS/ARIS_ARIS_Platform/84388.html 8
1. Důvody zavádění systémové integrace V současné době je pro naprostou většinu podniků nezbytností mít a využívat kvalitní informační systém. Význam informačního systému bývá úzce spojen nejen s charakterem činnosti podniku, ale bývá i úměrný jeho velikosti. Stává se podmínkou správného fungování podniku jako celku. Pro podnik přináší správně navržený a užívaný informační systém vždy i určitou konkurenční výhodu. Proces správné přípravy a návrhu informačního systému však není jednoduchou záležitostí a vyžaduje vynaložení nemalých finančních prostředků. To však sebou nese nutnost řešit celou řadu požadavků a souvisejících problémů. K tomu abychom předešli zbytečnému vynakládání prostředků na informační technologie a snížili rizika chybných rozhodnutí, nám slouží metody systémová integrace. Na systémovou integraci a hlavně na její metody můžeme pohlížet jako na určitý soubor návodů, který nám říká, jakým směrem bychom se měli ubírat a jak následně udržovat IS/IT.
1.1 Počátky systémové integrace Počátky systémové integrace jsou datovány na konec osmdesátých let. V té době začali podniky nasazovat ve velkém počítače. Souběžně s nasazováním se ale začaly objevovat první problémy, vzhledem k ceně výpočetní techniky často velmi významné. Spousta projektů z tohoto období měla nedostatečně určené cíle, nejasný cílový efekt a byly na ně vynakládány neúměrně vysoké prostředky. Odrazem této skutečnosti byl vznik nové disciplíny „Softwarové inženýrství“.2 Od roku 1991 začaly i na trhu v České republice nabízet první dodavatelské firmy služby systémových integrátorů. V tomto období to byly hlavně pobočky větších zahraničních firem, které již měly z této oblasti zkušenosti ze zahraničních trhů. V roce 1993 se uskutečnila první konference s tématem systémové integrace. O jeden rok později, v roce 1994, vznikla Česká společnost pro systémovou integraci (oficiální
2
Softwarové inženýrství je činnost zahrnující inženýrství, informatiku a management. [on-line][2011-06-20], dostupné z http://cs.wikipedia.org/wiki/Softwarov%C3%A9_in%C5%BEen%C3%BDrstv%C3%AD 9
internetové stránky jsou na adrese http://www.cssi.cz). Tato společnost funguje dodnes. Vedle pořádání seminářů a konferencí vydává i specializovaný časopis Systémová integrace. Systémová integrace je neustálý proces. Neustále se vyskytují nové problémy a nápady, jak je řešit, nebo co by se mohlo dělat jinak a lépe. Nelze tak jednoznačně vymezit její hranice, ani co přesně by měla systémová integrace obsahovat a jakým směrem by se měla ubírat. Právě proto, že ji ovlivňuje každodenní dění. 1.2
Účel a základ systémové integrace Účelem systémové integrace je co nejefektivněji vytvořit, následně udržovat a řízeně
rozvíjet informační systém. To vše tak, aby mohl co nejlépe sloužit k podpoře podnikových požadavků. Informační systém přitom nevzniká na jednom počítači, ale snaží se propojit různé technické, softwarové vybavení a služby v podniku tak, aby navzájem spolupracovaly. Požadavky na vývoj IS/IT při využívání systémové integrace podle (1): 1. Vlastnosti informačního systému, především požadavky na poskytované služby, jsou specifikovány dle požadavků firmy. 2. Informační systém musí být funkčním celkem, i když vzniká propojením různých částí od mnoha výrobců jak technického, tak i softwarového vybavení. V tomto smyslu lze za hlavní části informačního systému považovat: počítače a další periferie lokální sítě a sítě WAN základní software (ZSW), technologicky orientovaný typový software (TESW), aplikační software (ASW) úložiště dat. 3. Komplexní pohled na zavedení informačního systému jako celku (měli bychom mít rozmyšlené vše, od návrhu, proškolení zaměstnanců až po jeho budoucí vývoj). 4. Nezávislost na úzce specifických standardech a normách. Neměly bychom se orientovat na normy jednoho výrobce. Tady vzniká velké riziko. Pokud přijmeme a užíváme obecně uznávané normy a standardy, nemáme tak velké problémy přejít v případě potřeby k jinému dodavateli. Ale pokud to budou normy pouze toho jednoho konkrétního výrobce tak
10
se nám v případě přechodu může tento přechod výrazně prodražit. A může se stát i to, že celý informační systém budeme stavět znovu. 5. Vytyčená a srozumitelná strategie rozvoje informačního systému. Ten by měl být rozvíjen jednotnou cestou a uživatelé i řešitelé by jí měli rozumět. 6. Stanovení jednotných pravidel pro užívání informačního systému a dohled nad dodržováním těchto pravidel. 1.3
Důsledky systémové integrace na chod firmy Dobře postavený informační systém nám usnadní a zpřehlední fungování firmy.
Konkrétní výhody záleží na typu firmy. Některé z výhod, které může přinést: aktualizace dat v reálném čase (např. finanční situace, přehled skladových zásob, výroby), propojení jednotlivých poboček prostřednictvím informačního systému nám může přinést aktuální přehled o zaměstnancích a pracovním vytížení, pokud zaměstnanci budou plnit pokyny k manipulaci s informačním systémem, nemělo by docházet např. k nahrávání stejných souborů (duplikování), nebo sdělování stejných firemních informací několikrát, dynamickou
komunikací
s obchodními
partnery
můžeme
sledovat,
vyhodnocovat a hlavně reagovat na situaci na trhu. 1.4
Problémy systémové integrace Systémovou integraci můžeme provádět na různých úrovních a různými metodami. Ne
všechny modely ale musí vždy vyhovovat, Vždy musíme volit s ohledem na charakter podnikání a zvažovat případná rizika. Pokud se například rozhodneme pro zavedení a údržbu informačního systému jinou firmou (outsourcing), tak se na ni stáváme plně závislými. Musíme spoléhat na její seriózní jednání. Další problém by mohl nastat s komplexností informačního systému – tedy že se každý zaměstnanec nebude schopen orientovat v našem IS. Musíme brát ohled, na to že informační systém nebudou používat jen vyškolení IT odborníci, ale i obyčejní lidé bez hlubších znalostí výpočetní techniky.
11
Výše uvedené jsou jen hrubé příklady některých problémů, která nás mohou potkat. V žádném případě to nejsou problémy, které by se nedaly řešit. Pouze to sebou přináší další nároky, které budeme řešit.
12
2.
Stupně systémové integrace
2.1 Datová integrace Už v 80. letech se vyskytly problémy se souběžným zpracováním informací na více počítačích. Dříve se data zpracovávala na každém počítači zvlášť. Jeden výrobek tak třeba mohl být veden pod více značeními na několika počítačích stejné firmy. Proto byla snaha propojit data jednotlivých počítačů/aplikací – tedy provést datovou integraci.
2.2 Integrace aplikací Jedná se o synchronizaci funkcí za předpokladu použití více specializovaných aplikací, které by měly dílčím způsobem spolupracovat, případně i nad sdílenými daty. Nejlépe je to patrné na příkladu, kdy máme dvě aplikace. První aplikace je Stav zásob, druhá se jmenuje Objednávka. Pokud aplikace Stav zásob zjistí, že je nedostatek nějakého typu zboží tak zkontaktuje aplikaci Objednávka, která zajistí objednání zboží. Požadavky této integrace podle (1): Musíme určit pořadí operací, dále jaké funkce budou mít přednost při zpracování a specifikovat o jaké funkce z jakých aplikací jde. Programy musí být schopny se navzájem oslovit. V případě, že dojde zboží ve skladu, musí být aplikace Stav zásob schopna oslovit aplikaci Objednávka, aby se zboží doobjednalo. Aplikace musí sdílet společné záznamy (v tomto případě o zboží). V případě, že dojde nějaký typ zboží tak aplikace Stav zásob musí předat údaje o zboží (název, počet kusů), které je potřeba objednat aplikaci Objednávka. 2.3
Integrace informačních technologií pro podporu činnosti podniku Tento druh integrace ukazuje, do jaké míry jsou informační technologie spjaty
s činnostmi prováděnými v podniku. Jsou tři možné situace podle (1):
13
činnosti jsou provozovány nezávisle (samostatné aplikace - např. kniha jízd, docházka), činnosti jsou částečně integrovány (pouze se vyhodnocují závěry z pobíhajících činností), činnosti jsou plně integrovány (IT je nedílnou součásti té činnosti). Je celkem běžný stav, že se v podniku používají aplikace s různým stupněm integrace současně. 2.4
Integrace způsobu ovládání aplikací Tento problém se začal řešit už v 80. letech. Na trh se vedle jednoúčelových
informačních systémů (např. sklad) začalo dostávat větší množství aplikací, pokrývajících širší spektrum uživatelských funkcí (textové editory, tabulkové procesory, grafické programy), pocházející od více nezávislých výrobců. Uživatelé tak začali používat ke své práci více aplikací najednou. To znamenalo větší nároky na uživatele z hlediska ovládání jednotlivých aplikací. Aplikace se poměrně značně odlišovaly ve způsobu komunikace s uživatelem. To ve svém důsledku znamenalo pro uživatele ztrátu času, protože se museli přeorientovat na nové prostředí. Aby se tento problém vyřešil, byla snaha sjednotit komunikaci mezi aplikací a uživatelem. Sjednocovaly se například funkce kláves, které slouží k ovládání programů (funkční klávesy) a dbalo se, aby výrobci používali stejná označení pro stejné objekty a funkce ve svých programech. V uživatelské oblasti je v současné době asi nejvíce patrná snaha k integraci ovládání graficky orientovaných víceúlohových operačních systémů (tlustý klient). Silný rozvoj stále probíhá v oblasti tvorby rozhraní pro internetové systémy (tenký klient). Standardy specifické pro grafická prostředí jsou většinou přímo poskytované a doporučované jejich tvůrci. Při vývoji rozhraní pro podnikové prostředí se z nich prakticky vždy vychází, pouze se vhodně omezují nebo doplňují. Aplikační rozhraní ale nemusí tvořit pouze rozhraní uživatelská. Mnoho aplikací používá současně (nebo i výhradně) rozhraní vůči jiným aplikacím. Zde došlo k mohutnému vývoji – od prostého předávání vstupních a výstupních dat na nosiči (tisky, páska, disk) až po současná automatizovaná rozhraní pro dynamická webových služeb a XML datových formátů. 14
poskytování/výměnu dat pomocí
2.5
Integrace metodická Jde o způsob jednotného přístupu k tvorbě, záznamu a rozvoje IS/IT. Je to posun od
individuální práce k týmové. Výhodou použití osvědčených metodik je jednak to, že představují již prověřené postupy, vedoucí k požadovanému cíli, poskytují základní nástroje a při správném užívání zajišťují i efektivní komunikaci uvnitř týmů. K většině trhem akceptovaných a rozšířených metodik jsou k dispozici i softwarové nástroje, které dále pomáhají nejen formalizovat, ale i dále udržovat a rozvíjet příslušné činnosti. Patří sem podle (9) například metodiky (příp. rámce): SSADM (Structured System Analysis and Design Methodology), SDM (System Development Methodology), MDIS (Multidimensional Development of Information System), ITIL (Information Technology Infrastructure Library), knihovna nejlepších praktik COBIT (Control Objectives for Information and related Technology), RUP (Rational Unified Process), Select Perspective. Celkem běžně dochází k situacím, kdy se využívá více metodik. Jsou metodiky vyvinuté speciálně pro určitý účel. Některé metodiky řešící shodnou oblast mohou být z nějakých důvodů výhodnější než jiné (třeba aktuální znalost metodiky v řešitelském týmu) Největší snahou při použití různých metodik je dnes to, aby výsledky dosažené různými metodikami šli navzájem použít. Toto má velký význam a využití hlavně v oblasti vývoje aplikačního software. 2.6
Integrace hardwarová a technologická Tato integrace má opět svůj počátek již v 80. letech. Původní model plně
centralizovaného zpracování informací začal být narušován ze dvou směrů. Prvním byla vzrůstající přenositelnost software mezi centrálními počítači (mainframe) a druhým bylo to, že se ve velkém začaly nasazovat a používat osobní počítače. Důležitým faktorem bylo ale
15
vytvoření průmyslového vzoru osobního počítače firmou IBM, který zajišťoval, že aplikační software byl schopen prakticky bez úprav pracovat na počítačích různých dodavatelů. Tato změna sebou přinesla i změnu na straně výrobců hardware i software. Ti se začali orientovat na výrobu jednotlivých komponent namísto toho, aby dodávali všechny komponenty do informačního systému sami. To zapříčinilo vznik nových problémů podle (1): Nyní už nebylo většinou možné a většinou ani finančně výhodné postavit informační systém na komponentech jednoho výrobce, který tak zaručoval kompatibilitu komponent. Na trhu se začalo objevovat mnoho komponent. A naskytla se tak možnost vybírat komponenty podle našich požadavků a specifikací. I přesto, že byla snaha vytvořit určité standardy na výrobu komponent a tím zaručit jejich kompatibilitu, vznikaly ale při stavbě informačních systémů s komponentami od různých výrobců velké problémy. S tím, jak se začala data zpracovávat na jednotlivých počítačích, vznikl problém jak zajistit, že data na nich jsou správná a aktuální. Jednotlivé počítače neměly o sobě navzájem přehled, propojení pomocí počítačových sítí a technologie na zajištění synchronizace dat se pomalu rozvíjely. Na počítačích se používaly programy se stejným účelem, ale od různých výrobců. Lišily se např. formáty ukládání souborů. To znamenalo velký problém např. při přenesení uložených dat na jiný počítač, protože tam bez příslušného programu od stejného výrobce se nedala použít. To znamenalo většinou náklady navíc v podobě koupení další licence na jiný počítač. Mohlo se stát, že programy pro podobný účel a s podobnými funkce, byly koupeny vícekrát na stejný počítač. Řešení všech těchto technických i ekonomických problému přiřklo systémové integraci velký význam. A stala se z ní samostatná a svébytně se rozvíjející oblast informatiky. Nejprve se začalo řešit propojování jednotlivých komponent tak, aby je bylo možné vzájemně propojit v rámci jedné podnikové počítačové sítě. Na straně výrobců byla snaha standardizovat rozhraní komponent, byly navrženy a připraveny síťové operační systémy. Dále se však vyskytovaly problémy, se kterými si nedokázali správci IT ve firmách poradit. Nebyla stanovena metodika a jednotné postupy vedoucí k nalezení chyb. Většinou se pracovalo způsobem pokus a omyl. Zkoušely se například měnit komponenty, nastavení apod. 16
V dnešní době hardwarová integrace už není tak aktuálním tématem. Kompatibilita, spolehlivost a hlavně standardizace komponent se mnohonásobně zvýšila. Když se do podnikových počítačových sítí připojovaly další hardwarové komponenty tak to sebou přineslo další problémy, které souvisely především s používáním software. Týkalo se to zejména údajů uložených v databázích, uživatelských rozhraní, základního i aplikačního softwaru. Těmto problémům se začala věnovat technologická integrace. Ta řeší hlavně efektivní zpracování dat. Důsledně využívá propojení na úrovni počítačové sítě, zároveň řeší i propojení aplikací na úrovni jednoho počítači.
17
3.
Úrovně systémové integrace V druhé polovině 90. let přešla snaha od technologické integrace ke snaze propojit
jednotlivé stávající metody systémové integrace mezi sebou a propojení s požadavky obchodních procesů firmy. Mělo to směřovat hlavně ke snaze, aby se nasazení informatiky sladilo se záměry a cíli celého podniku. Základem je sjednocení podnikové a informační strategie. Nejdříve se stanoví podniková strategie, která vytyčí cíle firmy. Informační strategie slouží jako podpůrný prostředek. Sjednocování obou strategií probíhá v několika fázích, které se starají o to, aby podnikové cíle šly v souladu s technickou podporou. Součástí fáze sjednocení jsou podle (1): sjednocení představy na IS/IT, nastavení informačního systému pro komunikaci se zákazníky, obchodními partnery, nalezení vazeb a možnost reakce na měnící se požadavky trhu, sjednocení vnitřních procesů ve firmě, vyřešení problémů, které vzniknou při propojování různých hardwarových komponent. Pokud využíváme při vývoji IS/IT více přístupů a některé z nich bychom potřebovali sjednotit, je vhodné použít metodickou integraci. Ta se zabývá sjednocováním různých přístupů k vývoji IS/IT do jedné ucelené metodiky. Pro úspěšné zavedení metodik a sjednocení představy na IS/IT je kriticky nutné, aby se s nimi identifikovali zaměstnanci na vedoucích pozicích. Na úrovni vedení a vedoucích zaměstnanců musí být jasná vize cílů IS/IT a přijata koncepce jak těchto cílů dosáhnout. Může to řešit například otázky podle (1): jakým způsobem nám IS/IT pomůže při podpoře konkurenčního boje co budeme očekávat od IS/IT (jaké funkce bude plnit) jak bude zajišťována technika pro provoz IS/IT (vlastní, outsourcing,…)
18
jak bude vybírán a zajišťován software pro IS/IT (nákup, pronájem…) kdo bude zajišťovat správu IS/IT kolik nás to bude stát
Ředitel pro informatiku (CIO chief information officer) Ředitel oddělení informatiky by měl být členem výkonného vedení (exekutivy) podniku. Hlavním důvodem je zejména to, že informatické procesy jsou nyní prakticky bezprostředně spjaté s fungováním celé firmy. Zároveň je informatika jednou z oblastí, která spoluvytváří tržní konkurenceschopnost firmy a umožňuje i bezprostředně reagovat na změny tržních podmínek. Vedle toho je i důležitým nástrojem vnitropodnikového řízení. Ředitel oddělení informatiky by tak měl rozumět celkovému kontextu a klíčovým požadavkům, vycházejícím z podniku vůči oddělení informatiky. Zároveň by měl být tím, kdo v souladu s těmito cíli přináší do vedení návrhy nového a efektivnějšího využívání informatiky. Brainstorming Pro sjednocení myšlenky společného postupu je doporučenou a vhodnou cestou uspořádání brainstormingové jednání. Na toto jednání se mohou vedle členů vrcholového vedení a vlastních specialistů pozvat i zástupci firem, které poskytují řešení IS/IT. A každý interpretuje své názory. A snaží se nalézt společnou cestu. Metodika BPR Sjednocení vnitřních procesů spočívá v jejich provázání a zefektivnění. Např. se snažíme o jejich zrychlení (rychlejší aktualizace skladových zásob), lepší podporu nabízených výrobků a služeb, a aby jejich provoz byl co nejméně nákladný. S tím nám může pomoci metodika BPR (Business Process Re-engineering). Je to postup, který se zabývá efektivním řešením postupů ve firmě s využitím informačního systému. Technologická integrace Na posledním místě řešíme technologickou integraci. Pomocí této úrovně integrace řešíme například: sdílené úložiště dat,
19
kompatibilitu hardwarových komponent v jedné počítačové síti, synchronizaci programů, jednotné ovládání programů.
20
4.
Způsoby řešení vlastního IS/IT Můžeme se rozhodnout, zda celé IS/IT zrealizujeme z vlastních zdrojů, nebo
použijeme služby externích dodavatelů. První možnost, že celé IS/IT zrealizujeme z vlastních zdrojů, je v dnešní době celkem nereálná. A jen málo firem si tuto možnost může dovolit. Pokud nemá naše firma s touto oblastí zkušenosti, tak se nám tato možnost oproti možnosti druhé zcela určitě prodraží, protože bychom museli celý vývoj zaplatit sami. Znamenalo by to kromě jiného najmout spoustu odborníků, kteří by měli veliký záběr znalostí, průběžně jim platit školení, aby zůstali jejich znalosti aktuální. Rovněž bychom museli řešit vysoké požadavky na počet lidí v týmu v úvodních fázích řešení oproti následné fázi pouhého provozování a dílčího rozvoje systému. Je třeba mít finanční prostředky na poměrně vysokou vstupní investici. Vytvořit tento tým lidí pro malou nebo střední firmu by bylo ekonomicky velice nevýhodné. Na druhé straně pokud použijeme na vše externího dodavatele s úplným outsourcingem služeb, tak můžeme mít o IS/IT nulové znalosti. O všechno se nám postarají externí dodavatelé. Z hlediska finančního lze celý systém hradit formou plateb za služby, pořízení bude rychlejší a levnější. Problém ale může nastat v tom, že nenajdeme nabídku služeb či produkty přesně odpovídající našim požadavkům. V praxi se IS/IT řeší často kombinovaným přístupem.
Případy, které mohou nastat podle (1): 1. Budeme starat sami o vývoj IASW (individuální software), zavedeme ho vlastními silami, obstaráme si sami i komponenty. Výhody: perfektní znalost, neznalost konkurence našeho IS/IT, IS/IT přesně odpovídá potřebám firmy. Nevýhody: vysoká cena, 21
dlouhá doba trvání realizace IS/IT, kvůli tomu, že si jdeme vlastní cestou, tak v případě řešení problémů nemáme tolik možností odkud čerpat znalosti jako v případě, že bychom používali světové a ověřené standardy.
2. IASW si objednáme od jiné firmy, zavedeme ho vlastními silami, obstaráme si sami komponenty. Výhody: IS/IT přesně odpovídá potřebám firmy, konkurence nazná náš IS/IT, nemusíme se spoléhat jen na znalosti našich pracovníků, ale můžeme využit i znalosti externích pracovníků. Nevýhody: vysoká cena (většinou vyšší než u předchozího postupu), dlouhá doba trvání realizace IS/IT (nicméně kratší doba než v předchozím případě), musíme se spoléhat na firmu, která dodává řešení, že je spolehlivá (bude nakládat s našimi firemními informacemi) protože hrozí únik citlivých informací.
3. Nakoupíme všechny hardwarové i softwarové části od různých výrobců. Zavedeme vlastními silami. V této variantě se používá TASW (typový aplikační software – je to v podstatě SW v krabici). Výhody: kratší doba realizace, rychlejší než v předcházejících dvou případech, kupujeme za nejnižší cenu (možnost výběru), vybíráme z prověřených výrobků. Nevýhody: požadavky podniku na IS/IT se musí přizpůsobit softwaru, 22
při koupi hardwarových a softwarových částí od různých výrobců je jisté riziko vzájemné nekompatibility.
4. Celé IS/IT koupíme od jednoho dodavatele. Využijeme služeb systémového integrátora. Výhody: nejrychlejší způsob realizace, za kompatibilitu komponent, realizaci softwarových částí a řízení projektu většinou plně odpovídá integrátor, řešení na úrovni, dodavatel má zkušenosti, nejlevnější ze všech možností. Nevýhody: požadavky podniku na IS/IT se musí přizpůsobit softwaru musíme se spoléhat na firmu, která dodává řešení, že je spolehlivá (bude nakládat s našimi firemními informacemi) protože hrozí únik citlivých informací jsme plně závislí na dodavateli
5. Celé IS/IT koupíme od jednoho dodavatele. Využijeme služeb systémového integrátora. Požadavky na údržbu IS/IT kompletně nebo jen částečně převedeme na jinou firmu. Využijeme tzv. outsourcing. Výhody: shodují se s variantou 4, dále k nim přibude: odpadá nutnost vysoké kvalifikace pracovníků na IS/IT v naší firmě, pokud vybraná firma udržuje IS/IT ještě pro někoho jiného, může nás to vyjít levněji než v předchozí variantě (provádí správu efektivněji), systémový integrátor nám může dát k dispozici svoje nejnovější technologie.
23
Nevýhody: shodují se s variantou 4, dále k nim přibude: v tomto případě budeme nejvíce odkázáni na cizí firmu ze všech možností.
24
5. Systémový integrátor 5.1 Důvody pro využití služeb systémového integrátora Pro využití systémového integrátora se rozhodujeme především tehdy, když existuje požadavek na systémovou integraci IS/IT a nejsme schopni tento požadavek sami pokrýt z vlastních zdrojů, Důvody mohou být kapacitní, kvalifikační i jiné. Pomoc při pokrývání požadavků si objednáme u jiné firmy, systémového integrátora.
Hlavní důvody proč bychom se měli obrátit na systémového integrátora: pokud se naše firma opírá o IS/IT tak v případě problémů s funkčností to pro nás může mít neblahé následky, naši pracovníci nemají dostatečné znalosti, nebo jich nemáme tolik, abychom pokryli požadavky na rozvoj a následnou údržbu IS/IT, využití služeb systémového integrátora nám urychlí práci v případě nedostatku času (tlaku na rychlé nasazení, změny apod.) nechceme plně a sami nést rizika spojená s realizací IS/IT. Záleží na uzavřené smlouvě. V ní se můžeme se systémovým integrátorem dohodnout, na rozdělení odpovědnosti. Toto se může týkat například projektového řízení, dodržování časového plánu, zaručení kvality práce. Smlouva také může stanovit případné sankce pro případ porušení smlouvy, a to pro obě smluvní strany.
5.2 Faktory pro výběr systémového integrátora V případě, že se rozhodneme řešit svoje IS/IT pomocí systémového integrátora. Je mnoho faktorů a kritérií, které by měl splňovat, a my bychom se jimi měli při výběru důsledně řídit. Faktory a kritéria pro výběr systémového integrátora se mohou velmi zásadně odlišovat podle typu připravovaného integračního projektu. Všeobecně platí, že integrační projekty jsou dlouhodobějšího charakteru, často významně zasahují do interního chodu podniku a kladou 25
velmi specifické požadavky na znalosti a zkušenosti týmu, který navrhuje a řídí integrační činnosti. Proto jsou i mnohem širší kritéria pro výběr integrátora (podle 1): Finančně zajištěná firma. V případě, že by systémový integrátor zkrachoval, nebo by nemohl plnit závazky vůči svým zákazníkům z jiných důvodů, mohlo by to mít vážné následky na chod naší firmy. Může být třeba požadována jistina nebo uplatňováno zádržně. Musí připravit a předložit strategii, podle které bude v našem případě postupovat při systémové integraci. Mělo by tam být, jakým způsobem bude práci provádět a vymezit jaká zodpovědnost bude na obou stranách. Musí mít dostatečné personální zajištění, tedy dostatek kvalifikovaných zaměstnanců a dobré rozvržení jejich časových možností. Může se stát, že firma systémového integrátora bude pracovat na více projektech. A vyčlenění zaměstnanci nebudou mít dostatek času plnit své závazky a povinnosti vůči naší firmě. Také by ve firmě mělo být více odborníků na jednu problematiku. V případě, že by jeden zaměstnanec nemohl plnit svou práci, tak ho zastoupí jiný. Integrátor by měl perfektně znát software, který nám bude nabízet. Předpokládá se nejen znalost funkční, ale třeba i implementační, dále i splnění právních otázek dodávaného software a jeho případná omezení, pokud v naší zemi existují a uplatňují se. Abychom si mohli vybrat nejlepší řešení, tak by nejen aplikační software, ale i systémový integrátor měli být nezávislí na jednom výrobci jak softwaru, tak hardwaru. Zajistit služby spojené s dodávanými částmi informačního systému. Tím se rozumí, že musí nejen dodat SW a HW, ale také zajistit např. instalaci, servis, nastavení aplikací a proškolení zaměstnanců. Pokud není schopen při realizaci IS vyřešit všechny požadavky pomocí vlastních firemních zdrojů, tak by měl mít připraveného kvalitního subdodavatele, který mu pomůže tyto nedostatky vyřešit. Musí mít osoby kvalifikované pro roli vedení projektu a to v celém životním cyklu a v souladu s charakterem projektu. Systémového integrátor musí být věrohodný, tedy zaručovat, že informace, které získá v naší firmě, nebude bez našeho svolení dále šířit a používat. Za určitých podmínek může být požadována garance (typicky u vývoje na zakázku), že ani dílčí řešení 26
připravená pro naši firmu nebudou opakovaně užity či zaváděny jinde. Nedojde k úniku know-how naší firmy, ani placení vývoje IS i pro jiné firmy.
5.3 Úlohy plněné systémovým integrátorem V předchozím případě jsme se zabývali tím, co by měl systémový integrátor splňovat, aby mohl spolehlivě plnit naše požadavky. Teď se podíváme na to, jaké úlohy může plnit systémový integrátor ve vztahu s námi.
Úlohy systémového integrátora mohou být (částečně podle 1): Zpracuje, nebo výrazně přispěje ke tvorbě informační strategie podniku včetně plánu dalšího rozvoje. Může výrazně přispět ve fázi akceptace projektového záměru. Vypracuje rozvahu, co bude potřeba, jak dlouho to potrvá a kolik bude stát zavedení IS/IT v plánovaném rozsahu do firmy. V tomto kroku se bude opírat o vytvořenou a schválenou informační strategii. Při celkovém návrhu IS/IT se snaží o to, aby součásti jak hardwarové, tak softwarové byly na sobě co možná nejméně závislými, respektive aby nevznikaly závislosti omezující, nebo svazující možnosti budoucího rozvoje Dále dbá o to, aby IS/IT mohl pružně reagovat na měnící se situace na trhu, nebo funkčním požadavkům na samotný systém při změnách z hlediska fungování naší firmy. Při celkovém návrhu vezme do úvahy existující aplikace, technologie, licence a smluvní podmínky. V celkové koncepci vezme ohled na efektivní využití již provedených investic, zohlední tedy i možnosti zachování a rozvoj určitých částí, existující znalosti a dovednosti. Vyhodnotí komplexně požadavky a dopady přechodu při přechodu na nové technologie. Řešení volí tak, abychom mohli do IS/IT časem flexibilně začleňovat nové technologie. Postupy a praktiky používané systémovým integrátorem musí být postaveny na metodickém základu. Volba metodik, poskytování formálních výstupů a případné proškolení pracovníků firmy je záležitostí upřesňovanou smluvně. Při vývoji aplikačního software musí být smluvně vyjasněn vztah zákazníka a systémového integrátora. Především jde o povinnosti na obou stranách, týkající se práv na 27
používání softwaru. Musíme mít na paměti, že při koupi „hotových“ programů získáme běžně pouze licenci na užívání, nikoli autorská práva. Jiní situace může nastat při vývoji software na zakázku. Tady je důležité vymezit, co všechno a za jakých podmínek si můžeme s programem dovolit (např. v případě nutnosti přepsat část programu). Také bychom si měli ujasnit, kdo a do jaké míry ručí za chyby vzniklé špatnou funkcí programu (ekonomické škody). Sjednocení představy obou stran, k tomu co čekáme od projektu a jak bude vypadat spolupráce. Pokrýt nejen realizaci, ale také následné fáze údržby již zavedeného IS/IT. Stanovit formální postupy (definovat metodiky) použité pro vývoj, testování a vyhodnocovat běhu softwaru, jak řešit případné problémy a reklamaci. Vymezit jaký specifický software a nástroje budeme používat. Po ucelení všech informací navrhne plán realizace. Koordinuje činnost stanovených členů týmů jak na své straně, tak na straně zákazníka. Zajistí kompletní proceduru ohledně hardwaru a softwaru (dodání, instalace, servis, správa, proškolení). Pokud se na projektu podílí více firem, tak může na základě a v rozsahu stanoveného oprávnění řídit jejich subdodavatelskou činnost. Musí zajistit, že všechny části dodávky budou spolu kompatibilní. Zaručí nám, že bude efektivně dodržován plán financování a čerpání našich finančních prostředků. Zaručí vysoký standard kvality práci ve všech cyklech projektu.
5.4 Personální zajištění systémového integrátora Jak jsem již uvedl dříve, tak by systémový integrátor měl mít dostatek kvalifikovaných zaměstnanců. Více odborníků na jednu problematiku zajišťuje dobrou zastupitelnost. V praxi je běžné, že na některé úlohy existují specializované firmy, nebo velmi úzká skupina odborníků. Systémový integrátor tyto služby může při plnění zakázky využít, jejich výběr a požadavky na zastupitelnost by měly splňovat vysoké standardy. Zcela nezastupitelná je role systémového integrátora při přípravě a řízení integračního projektu. 28
Zaměstnanci systémového integrátora by měli plnit tyto funkce (částečně podle 1): Prezentace poskytovaných služeb a sjednávání kontraktů se zákazníky. Tito lidé by měli znát požadavky trhu, specifických obchodních oblastí a vědět tak, co zákazníci chtějí. Zároveň by měli velmi dobře znát nabízené produkty. Tuto funkci nejčastěji plní obchodníci. Řízení projektů ve všech životních cyklech projektu. Toto provádí zaměstnanci schopní samostatného řízení projektů, role bývá označována jako projektový manažer. Poradenství a konzultace v oblasti obchodních procesů.
Jedná se o tzv.
obchodní konzultanty (business consultant), tj. konzultanty se specifickou znalosti prostředí a produktů pro oblast. ve které podnik působí. Analýza požadavků na software, Zahrnuje jak odborníky na TASW (analyzují oblast pro případ nasazení, zavádění, nastavování, testování a školení uživatelů), tak i na oblast IASW (analyzují požadavky na vývoj softwaru, navrhují, zavádějí a testují). Programování individuálního software podle potřeb zákazníka. Předpokládá se minimálně schopnost řízení projektu softwarového vývoje. Zavádění technického a programového vybavení do provozu a následná péče (aktualizace, servis). Pro tyto činnosti je třeba mít k dispozici velmi podrobné informace pro detailní plánování jednotlivých činností k sestavování harmonogramů pro sekvenční činnosti. Vzhledem k trendu používání pronajatého hardware, nebo umísťování do hostingových center, mají tyto činnosti dopady i na objednání souvisejících služeb (požadavky na infrastrukturu datacentra, zpřístupnění datacenter, pomocné prostory apod.). Technická podpora na telefonu pro vybrané činnosti. Při řešení projektu i následnou podporu by měl být systémový integrátor schopen poskytovat ve smlouvě stanovenou úroveň telefonické podpory. Udržování vysoké úroveň zaměstnanců. Systémový integrátor by měl dbát na vysokou úroveň zaměstnanců ve všech, tedy jak netechnických, tak i technických rolích. Všechny zaměstnance by měl systémový integrátor průběžně školit a to i přesto, že školení hlavně v technických profesích bývají velice nákladné. Nepředpokládá se, že pracovníci jsou využívání výhradně pro práci na jednom projektu (ekonomické důvody), jejich kapacita ale musí být dostatečná k včasnému a řádnému plnění smluvních závazků.
29
Udržování zkušenostních, profesních a osobních vazeb. Pro práci na projektech je za běžných okolností vhodné používat opakovaně stejné zaměstnance u stejných zákazníků. Dříve navázané pracovní vztahy, znalost konkrétního prostředí i problematiky zákazníka mohou výrazně pomoci se startem spolupráce na projektu. Na druhé straně musí být integrátor připraven vznášet i řešit případně požadavky na výměnu členů týmu, pokud to situace vyžaduje. Udržování oborových znalostí je výhodné pro integrátory soustřeďující se na omezenější segment trhu a zákaznické skupiny. Toto se týká jak udržování dobré znalosti obchodní problematiky, tak i specifických technických znalosti aplikovatelných v příslušném segmentu trhu. Perfektní znalost těchto potřeb, hlavně u globálně působících systémových integrátorů dává velkou výhodu a zvyšuje pravděpodobnost úspěšného projektu. Integrátor a nepřímo i firma může čerpat zkušenosti z velkého počtu projektů. Oproti tomu menší (lokální) systémový integrátor, působí na malém trhu, musí tyto znalosti většinou nakupovat. Menší firmy se často omezují pouze na systémovou integraci v úžeji vymezených oblastech, často svázaných s určitými technologiemi nebo produkty.
5.5 Výběr systémového integrátora Výběr vhodného systémového integrátora je velice citlivou a náročnou záležitostí. Pokud uděláme chybu, může nás to stát nejen vynaložení zbytečných peněz, ale může to vést i k ohrožení stability naší firmy. Při rozhodování o vhodném partnerovi pro systémovou integraci považuji za klíčový rozsah a obsah předpokládaných integračních prací. Pokud bych se rozhodoval v pozici firmy, která má záměr přípravy a následné realizace dlouhodobější vize, v rámci které budou řešeny klíčové firemní procesy (a tedy i obchodní aplikace), upřednostnil bych výběr spíše globálního integrátora, nebo lokálního integrátora se silnou znalostí problematiky trhu v oblasti působení firmy. Pokud by se jednalo o dílčí integrační zadání, například na úrovni technických prostředků, spolupráce aplikací apod. lze hlavně z ekonomických důvodů upřednostnit specializovanějšího lokálního integrátora. Je to ovšem za cenu určité ztráty kontinuity, neboť v případě jiného zadání bude nutné se obrátit na jiného dodavatele, a s určitým rizikem, že spolu s integrátorem nedohlédneme na všechny budoucí aspekty prováděné integrace. 30
V každém případě jsou velmi důležité reference integrátora (spektrum projektů, úspěšně dokončené projekty), doložení dosažených kvalifikací firmy a jejich zaměstnanců, případně speciální certifikace pokrývající specifické oblasti integrace. Často se jedná o speciální bezpečnostní nebo produktové certifikace. Pro úspěšnou realizaci všech typů IT projektů je vždy důležité kvalitní projektové řízení. Pro integrační projekty, často výrazně zasahujících do vnitropodnikových procesů, je kvalitní řízení projektu absolutní nutností. Za samozřejmost se považuje jak certifikace ISO, osvědčující nasazení a správné používání procesního řízení na straně integrátora, tak i certifikace projektových vedoucích (project manager) v použití metodik pro řízení projektu. Výběr metodiky pro řízení projektu může vycházet z požadavku podniku na základě užívaného vnitropodnikového standardu. Součástí požadavku na integrátora pak bývá tuto metodiku akceptovat, znamená totiž pro podnik nižší náklady (zaměstnanci mají její znalost). Integrátor ale může, a to i z důvodu specifických požadavků projektu, vhodnou metodiku vybrat a navrhnout. Výběr a seznámení týmu s metodikou řízení – v potřebné míře podle role v týmu pak bývá běžně součástí úvodních fází projektu.
31
6.
Metody systémové integrace
6.1 Úvod Oblast IS/IT je velice široká. Jak bychom měli věci řešit nelze jednoznačně definovat jedním řešitelským postupem. Do řešení problémů je zapojeno mnoho lidí s různou specializací a nápady jak věci řešit. Z toho důvodu vznikají různé metodiky. V metodice jde o snahu sjednotit přístup i postup k řešení problémů.
Existuje mnoho metodik, které se zaměřují na metody jak postupovat. Já bych zmínil tyto podle (9): SSADM (Structured System Analysis and Design Methodology) , SDM (System Development Methodology), SSM (Soft systems methodology), DSDM (Dynamic Systems Development Method), Oracle CASE Method.
Základní nároky na metodiky, které jsou nezbytné pro její úspěšnost: musí jednoznačně ukazovat na čem je postavena a čeho bychom v případě jejího použití měli dosáhnout, musí popisovat celý proces řešení aby, jsme mohli udělat časový plán na jeho vykonání a také stanovit důležitost jednotlivých řešení, vhodné by bylo, kdyby také u jednotlivých kroků odkazovala na různé metody, techniky a nástroje řešení, kterých bychom mohli využít
Standardy a referenční modely řešení Při návrhu řešení se i při používání metodik prakticky nikdy nevychází z nuly. V informatice se velmi intenzivně využívají různé standardy. Pokud existuje v rámci 32
standardů více možných řešení, vždy se jejich použití upřesňuje v počátcích projektu, obdobně jako když se upřesňuje, jaké metodiky budou v rámci projektu využívány a pro jaký účel. Naprostá většina řešení má opakující se charakter a vymýšlet neustále nová a nová řešení by nebylo efektivní. Proto se opakovaně používají určité osvědčené vzory (patterns) řešení. Tyto vzory mohou řešit například použití specifických algoritmů pro řešení určitých okruhů problémů, ale i řešení aplikace určitého typu (obchodní procesy), nebo třeba návrh architektury celého řešení. Tyto vzory jsou často „nadstavbou“ metodik (jsou vytvořeny v souladu s metodikou) a vyžadují vlastně pouze dopracování (úpravu) modelu podle skutečného zadání a potřeb. Zásadní výhodou je bezpečnost této cesty – jedná se o praxí ověřené a fungující vzory, které mají velmi dobře zpracován postup dopracování pro reálné požadavky. Některé vzory jsou volně k dispozici, řada z nich ale tvoří firemní know-how. Získávají se pak koupí, nebo jako součást služeb specializovaných firem či specialistů. V další kapitole se budu věnovat metodice MDIS. O vývoj této metodiky se stará katedra informačních technologií Vysoké školy ekonomické.
6.2 Metodika MDIS MDIS znamená Multidimensional Development of Information System. Poprvé byla zveřejněna v České republice v roce 1992. V roce 1993 byla představena v zahraničí. Podle (1), zaměřuje se především na to, jak bychom měli přemýšlet při vývoji IS/IT. Tím se liší od jiných metodik, které popisují jednotlivé kroky – předepisují co bychom v tom daném kroku měli udělat. Představitelem jsou například metodiky SSADM a Oracle CASE Method. Metodika MDIS uvažuje tím způsobem, že jednotlivé projekty jsou tak unikátní (např. časovou náročností, použitými technologiemi, schopnostmi řešitelů a uživatelů) že stanovit jednotný způsob, jakým bychom měli postupovat v jednotlivých krocích nelze. Proto se snaží o formulaci celkové práce. Všímá si hlavně fází vývoje. Snaží se říci, co bychom měli v jaké fázi udělat. Ale už nezachází do detailu v popisu, co by se mělo dělat v jednotlivých krocích. Abychom měli IS/IT úspěšné, tak musíme mít promyšlenou koncepci celkové práce, která ovlivňuje architekturu i způsob řešení. Podle metodiky MDIS nemůžeme vytvořit jeden 33
řešitelský postup a ten používat univerzálně ve všech projektech. Pokud se stane, že budeme používat jeden řešitelský postup na všechny projekty, tak se nám může přihodit, že ve výsledku budou projekty neefektivní. Proto je dobré uplatnit při navrhování řešení IS/IT více pohledů. Totéž platí i pro následný provoz. V první polovině 90. let se v českých firmách vyskytl problém. Mnoho firem nejdříve nakoupilo hardwarové vybavení, aniž by se zabývaly tím, jaký software budou na nakoupeném hardwaru provozovat. V takových případech docházelo k tomu, že některé firmy po vyhodnocení použitelnosti TASW pak došlo k tomu, že jim bude nakoupený hardware k ničemu. S problémy se potýkalo mnoho implementátorů typového aplikačního softwaru. Docházelo k tomu, že nakoupili veškeré hardwarové vybavení a všechen TASW. Potom začali přemýšlet, jestli je tento TASW vhodný pro danou firmu. V lepším případě tak dodaný hardware a TASW byly nakonec úspěšně provozovány. Ale analýza vhodnosti a nasazování trvaly tak dlouho, že museli po plném zprovoznění opět za poměrně krátkou dobu obměňovat hardware. Když nastal horší případ, tak došli k závěru, že nemohou nakoupený TASW provozovat na už nakoupeném hardwaru, nebo že není pro potřeby firmy vhodný a použitelný. Dalším výrazným znakem MDIS je multidimenzionalita. „To je řešení IS/IT souběžně ze všech pohledů, které ovlivňují efektivnost IS/IT.“(2) Metodika MDIS má dvě hlavní zaměření vývoje IS/IT (podle 1): 1. V prvním pohledu představuje stupně sjednocení IS/IT, jak podrobně se budeme jednotlivými problémy zabývat a jaké množství času nám to zabere. Všechno budeme uplatňovat v dílčích stupních budoucího vývoje IS/IT (např. kam bude podnik směřovat, co budeme v budoucnu očekávat od informačních technologií). 2. Ve druhém pohledu se zaměřuje na věci, které budeme aplikovat ve všech krocích budoucího rozvoje IS/IT.
Pomocí multidimenzionality bychom měli dosáhnout takové řešení, ve kterém zahrneme co možná nejvíce faktorů. Budeme si všímat jak faktorů zvlášť, i jak na sebe působí navzájem. V konečném stavu by nám všechny získané informace měly poskytnout dostatečné informace pro to, abychom si mohli úspěšně poradit s požadavky, se kterými se budeme potýkat od vytvoření až po budoucí udržování IS/IT.
34
Teď můžeme říci, že metodika MDIS se nám hlavně hodí k: „vývoji, údržbě a provozu komplexního a integrovaného informačního systému podniku, který optimálně podporuje dosažení celopodnikových cílů, přičemž bere současně v úvahu potřeby a znalosti pracovníků, kteří systému užívají. Metodika MDIS je postavena na přesvědčení, že takový IS/IT musí mít vyváženy a dobře integrovány všechny dimenze, které mají na vývoj, údržbu a provoz konkrétního IS/IT vliv.“ (3) Do této doby se vývoj metodiky MDIS zaměřoval hlavně na strategické řízení IS/IT. Důvodem je, že podle zjištění autorů většina chyb, které vedou k chybám v projektech, vzniká ve strategickém řízení.
6.3 Možnosti přístupu k řešení IS/IT V této kapitole se podíváme na to, jak můžeme přistupovat k řešení IS/IT. Ukážeme si, jak to vypadá z pohledu uživatele tak i z pohledu řešitele. Tohle je důležitě, protože když navrhujeme řešení IS/IT, tak se nejdříve podíváme na to, jak to vidí uživatel a poté od tohoto pohledu přejdeme k tomu, jak to vidí řešitel. Z pohledu uživatele budeme formulovat požadavky a tyto požadavky poté zpracujeme do řešitelského pohledu. Tímto také zjistíme, jestli požadavky ze strany uživatele dokážeme zrealizovat. Požadavek z pohledu uživatele může být definován takto: Chceme zavést docházkový systém. Bude v něm vedena evidence příchozích a odchozích zaměstnanců. Každý zaměstnanec obdrží čipovou kartu. A při příchodu nebo odchodu ji bude povinen přiložit ke snímači. Systém by měl být zprovozněn do 5 měsíců. Cena by neměla být vyšší než 200 tisíc korun.
Pokud toto převedeme do řešitelského pohledu tak dostaneme: 1. Pokud se má tento projekt stihnout do 5 měsíců tak bude stát 400 tisíc korun. Důvodem je, že do této doby nejsme schopni pouze ze svých zdrojů zajistit dodávku potřebného vybavení a musíme využít, některé další firmy. 2. Pokud se má dodržet cena tak se doba realizace zvýší z 5 měsíců na 8. Za 8 měsíců stihneme práci vykonat pouze ze svých zdrojů. 35
6.3.1 Druhy pohledů ze strany uživatelů na IS/IT 6.3.1.1 Řídící posty podniku Požadavky uživatelů v tomto pohledu se dost zaměřují na dlouhodobější cíle a mají pro firmu taktickou povahu. Požadavky, které dostaneme z názorů lidí na těchto postech, se dají zformulovat na tyto základní požadavky, které budeme klást na informační systém (částečně podle 1): podpora celopodnikových cílů, nástroj konkurenčního boje, pomocí informačního systému dosáhnout náskoku před konkurencí, efektivní podpora podnikových procesů, trvání co možná nejkratší dobu a co možná nejméně náročné na zdroje, aktuálnost
informací
a
rychlost
přístupu
k nim,
informace
uložené
v informačním systému musí být nejen aktuální, ale také pravdivé. Pokud se udělají nějaké změny v uložených datech tak se změna musí projevit okamžitě. Dále by měla být možnost prohlížet stará data a použít je např. k porovnávání s novými. Měl by obsahovat možnost všechny data přehledně zobrazit pomocí grafického rozhraní.
Formulaci požadavků na IS/IT je vhodné zpřesnit v těchto bodech: na co se budeme při vývoji IS/IT zaměřovat, časový harmonogram aktualizací IS/IT, s jakými prostředky můžeme počítat (jedná se jak o finanční zajištění tak o personální).
Pro toho, kdo řeší IS/IT v podniku je velice důležité, aby si co možná nejlépe ujasnil, co lidé na řídících pozicích chtějí. Protože jejich požadavky nám ukazují, kam se bude IS/IT v budoucnu ubírat. Pohledy a informace lidí na těchto pozicích jsou nejdůležitější pro stanovení hlavních cílů integračních projektů.
36
6.3.1.2 Koncoví uživatelé Koncoví uživatelé by chtěli podporovat svoje činnosti od IS/IT na dané pozici. Z jejich formulovaných požadavků lze vydedukovat: jaké pozice za co odpovídají, pro jaké činnosti nebo do jakých řešení problémů by šlo ještě více zapojit informační systém, jaké informace bychom měli ukládat do informačního systému, v jaký čas by bylo vhodné informace sbírat, jakým způsobem informace upravovat, než je uložíme do informačního systému. 6.3.1.3 Oprávnění uživatele a práce s informačním systémem Tady jde o to, jak uživatelé vidí funkce informačního systému z pohledu jejich pozice ve firmě. Je obvyklé řídit přístup k informacím pomocí vhodného nastavení přístupových práv. Např. servisní technik se může podívat na příjem objednávek nebo na skladové zásoby. Ale do účetnictví podniku už nemá přístup. Nejen proto, že by to pro něj bylo zbytečné, ale také proto, že se jedná o citlivá data a přístup k nim by měly mít pouze osoby k tomu oprávněné a potřebující je ke své práci.
6.4 Přístupy řešitelů k IS/IT Zde řešitelé vezmou požadavky, které nasbírali od uživatelů a udělají z nich logický návrh. V tomto návrhu se neberou ohledy na použité hardwarové a softwarové vybavení. Logický návrh poté předěláme na fyzický. Zde už ale budeme muset brát v potaz použitý hardware a software. Když tvoříme z uživatelských požadavků požadavky řešitelské tak si musíme dávat pozor jaký je použitý software. Zda jde o typový aplikační software, nebo individuální aplikační software. U individuálního aplikačního softwaru, který je tvořen přímo na míru podniku, je práce o dost složitější. V metodice MDIS se řešitelské pohledy nazývají dimenze řešení IS/IT. Tyto dimenze se dělí na dvě skupiny. „První skupina zahrnuje časovou dimenzi řešení, úroveň abstrakce při 37
řešení IS/IT, a úroveň integrace IS/IT. Druhá skupina pak zahrnuje obsahové a metodickoorganizační dimenze vývoje a provozu IS/I.“ (4) Dále se budu věnovat dimenzím, které patří do první skupiny.
6.4.1 Dimenze první skupiny 6.4.1.1 Vývojové stupně IS/IT V metodice MDIS se vývojové stupně odvíjí od první skupiny dimenzí. Pro každý vývojový stupeň je specifické to, čeho chceme dosáhnout a jakým způsobem budeme postupovat. Dále jsou upřesněny vstupní a výstupní data pro každý vývojový stupeň. Pokud rozdělíme práci na jednotlivé stupně tak dosáhneme: větší přehlednosti o probíhající práci, snazšího naplánování a řízení, možnosti při práci na projektu dávat přednost těm částem, které lze dříve zavést do provozu, snazšího přemýšlení a orientaci v projektu, pokud si práci rozdělíme na části tak máme možnost se věnovat jednotlivým částem zvlášť. To nám usnadní práci hlavně v tom, že když budeme přemýšlet, tak si utřídíme informace a vyhneme se chaotickému přemýšlení. toho, že smysl a cíle naší podnikové strategie se budou opírat o naše IS/IT, při plánování toho kam chceme posunout naše IS/IT musíme nejdříve navrhnout význam a účel našich podnikových procesů a poté se zabývat jak to můžeme podpořit pomocí IS/IT. Budeme navrhovat globální a informační strategii.
V každé strategii bychom měli mít tři body: 1. rozebrání existující situace, 2. vzor stavu, do kterého bychom chtěli dojít (globální strategie je vzorem stavu do kterého bychom chtěli dojít s celým podnikem, informační strategie je vzorem stavu jak by mělo vypadat IS/IT), 3. plán, jakým budeme postupovat ze stávajícího stavu do stavu budoucího. Pomocí při plánování IS/IT je globální podniková strategie (GST). Tato nám říká, jakými cestami se budeme ubírat a co pro nás bude mít jakou důležitost při vývoji podniku. Poté, co
38
sestavíme globální podnikovou strategii, tak sestavíme i informační strategii. V této strategii nám jde o to, abychom efektivně využili naše IS/IT k podpoře globální podnikové strategie. 6.4.1.2 Etapy života projektu Když navrhujeme plány na realizaci u informační strategie, tak se většinou snažíme zformulovat šest kroků: „úvodní studii, globální analýzu a návrh, detailní analýzu a návrh, implementaci, zavádění, provoz a údržbu.“ (5) Tyto kroky se mohou na projektu po nějaké době opakovat. Může se nám stát to, že pokud stále vylepšujeme naše IS/IT, požadované změny budou už tak velké, že nebudou stačit pouze dílčí úpravy, ale budeme muset celé IS/IT vybudovat znovu. 6.4.1.3 Úvodní studie Vypracováním této studie zjistíme, zda je možné a za jakých podmínek vypracovat projekt. Pokud zjistíme, že bude projekt hodně dlouhý, tak si můžeme práci rozdělit na tzv. subprojekty. Uděláme jádro řešení. K jádru postupně přidáváme další dílčí řešení. Dále se také budeme zabývat vazbami mezi jednotlivými subprojekty. V této studii také můžeme dojít ke zjištění, že projekt nelze realizovat. Důvodů může být mnoho, např. nedostatečný kapitál. V tomto případě se vracíme do informační strategie a musíme celý projekt předělat. 6.4.1.4 Globální analýza a návrh Zde se řídíme kostrou sestavenou v úvodní studii. Budeme popisovat základní vlastnosti aplikace na konceptuální úrovni. Tady nás zatím nezajímá, na jakém hardwaru aplikace poběží, nebo v jakém prostředí ji budeme provozovat. Pouze si řekneme, co bychom od ní očekávali a její základní charakteristiky (co by měla umět, kde ji provozovat atd.). 6.4.1.5 Detailní analýza a návrh Tady přecházíme od konceptuálního modelu k modelu technologickému. V tomto modelu nás už zajímá použité hardwarové a softwarové vybavení. Při zavádění se může stát, že bude použit relační model systému řízení báze dat. Pokud zde máme konceptuální datový model, tak budeme muset udělat převod do relačního modelu.
39
6.4.1.6 Implementace Zde přecházíme od technologického návrhu k implementačnímu plánu. Zde se už zabýváme konkrétními programy a práci s nimi (programování, testování). Také už kompletujeme dokument s popisem celého IS/IT. 6.4.1.7 Zavádění Dochází ke zprovoznění hardwarových a softwarových částí, zahajuje se proškolování uživatelů. Jsou prováděny testy aplikací a spouští se zkušební provoz. 6.4.1.8 Provoz a údržba Je konečnou etapou projektu. V této etapě už projekt plně funguje. Plní úlohy, pro které jsme ho realizovali. My jen částečně upravujeme aplikace na změny v požadavcích jejich využití. Budoucí efektivita vynakládaných prostředků na projekt se pozná až s odstupem času, tedy až uvidíme, jak dlouho projekt vydrží bez dalších větších zásahů. Tudíž bez dalších výrazných nákladů. Pokud si projekt rozdělíme na etapy, tak se nám zrychlí i zpřehlední práce. Bude se nám snáze přidělovat i kontrovat kdo co dělá. Uvidíme vztahy mezi našimi požadovanými funkcemi i to, jak jsou podporovány ze strany IS/IT. Vlastně všechno, co se bude dělat, budeme mít přehledně zformulováno v jedné ucelené soustavě.
6.4.2 Dimenze druhé skupiny Nyní se věnuji druhé skupině dimenzí. „Mezi obsahové dimenze řadíme: o data/informace, o funkce/procesy, o organizační a legislativní aspekty, o pracovní, sociální a etické aspekty, o software, o hardware, ekonomické a finanční aspekty.
40
Mezi metodicko-organizační dimenze patří: o metody, o dokumenty. v řízení prací dané fáze“. (6) Když pracujeme na projektu, tak v každé etapě použijeme tyto dimenze a jejich vzájemných vztahů. 6.4.2.1 Data/informace Tato dimenze se zaměřuje na informace, které se využívají při podpoře podnikových aktivit. Tvoří základ způsobu uložení dat a jejich organizace. Když se zabýváme touto dimenzi, tak tvoříme datovou architekturu IS/IT. Když hledáme východisko pro IS/IT, tak narazíme na mnoho případů, kdy musíme informaci definovat.
Typy případů: 1. Různé druhy informací např. signální, strukturální a genetická. Tohle rozdělení je důležité, protože každý druh informace jinak působí na systém. Na signální informaci narazíme při běžném transferu dat mezi částmi systému. Patří sem např. vyúčtování za telefon, které přišlo do firmy, nebo skladové zásoby. Strukturální informace zobrazuje uspořádání systému a říká, co si může jaká část dovolit. Ve firmě je obvykle použita při tvorbě organizační struktury a při definici pracovní náplně na jednotlivých postech. Také s její pomocí říkáme, jaké má kdo kompetence a definujeme, jak bychom měli postupovat v pracovních činnostech. Sem patří procesy, které svojí povahou mění strukturu informace. Genetická informace je určující v tom, jak bude systém jednat. Nachází se přímo v paměti systému. V podniku jsou nositelé genetické informace lidé. Při jejich chování se ukazuje. Genetickou informaci můžeme i zformulovat slovně na papír. Tak se nejčastěji děje v případech tvorby nové kultury podniku. Tato informace má také určitý podíl na tom, jak je podnik schopen reagovat na okolní vlivy a přizpůsobovat se jim, jaké vyznává hodnoty a jaké se snaží mít vztahy mezi zaměstnanci a zákazníky atd. Pokud chceme změnit genetické
41
procesy, tak to trvá déle než u procesů signálních, nebo strukturálních. Rozebrat a naplánovat genetickou informaci je velice důležité a má to velký vliv na úspěšnost celého projektu. Pokud tyto informace jsou v rozporu s tím, čeho chceme dosáhnout, tak se nám může stát, že nedosáhneme zdárného konce, i když vše ostatní bude fungovat bez problémů. Podniková a informační strategie si bere a používá informace, a to hlavně genetické a strukturální. Etapy života projektu rozebírají a využívají hlavně signální informace. 2. Obecnost informace – pokud jde o konkrétní informace, tak to může být třeba obsah v dopisu od banky. A abstraktní informace je v tomto dopise styl, jakým je to zformulované. 3. K čemu se informace váží (např. pronájem serveru). 4. Význam informace. 5. Časová definice informace – zde si ujasníme čas vzniku informace a k jakému časovému období se vztahuje. Pokud se informace vztahuje k současnému (momentálnímu) stavu, tak je aktuální (např. jací zaměstnanci jsou momentálně v kanceláři). Když se snažíme odhadnout, co bude (např. jaké budou zisky za pět let), tak tato informace je prognostická. Z aktuální informace se stane historická, pokud uběhla doba, kdy platila (např. stav peněz na účtu před vyplacením výplat). Totéž platí i u prognostické. Pokud v informačním systému zálohujeme historické informace, tak by bylo vhodné rozlišovat, jaké informace patřili mezi aktuální a jaké mezi prognostické. Pokud bychom tak nečinili, tak bychom si mohly plést naše odhady s reálnými údaji. Mohl by nastat např. takový případ, že v informačním systému bychom měli údaj, že v roce 1999 jsme vydělali 5 milionů korun. A žádné další informace by u toho nebyly. Takže nevíme, jestli jsme splnili naší prognostickou informaci ohledně plánovaného výdělku. 6. Odhad hodnoty informace – když podnik získává informace, tak nemá jistotu, že všechny získané informace jsou věrohodné. Protože se může stát, že si některé informace nemůže dostatečně ověřit. Ve chvíli, kdy se rozhodujeme, by se mohlo stát, že nás ovlivní chybné informace. Proto je dobré u uložených informací poznamenat jejich věrohodnost, nebo alespoň nějaké bližší informace. Uvádět můžeme například: odkud informace pramení, kdo informace získal, podobu informace (např. papír, zvuk, video),
42
množství informací, které obsahuje, kde je informace uložena. Pokud například využíváme služeb poradenských firem, tak se většinou přihlašujeme do jejich úložiště. V podniku může být informace uložena ve třech základních podobách v mysli zaměstnanců, v papírové podobě a elektronicky v informačním systému. Informace jsou v současné době velice ceněné zboží. Proto se spousta firem snaží všechny informace ukládat do informačního systému. Ve chvíli, kdy je tam uložíme, se už nemusíme spoléhat na to, jestli si je budou pamatovat zaměstnanci, nebo jestli člověk bude dostupný. Převedením informací do elektronické podoby se nám velice zvýší jejich dostupnost. 7. Co musí být splněno, abychom mohli informace efektivně využívat v podniku: dát podnět k tomu, aby zaměstnanci požadované a potřebné informace zajišťovali a zpracovávali, znalosti, které budeme hledat, musí informační systém obsahovat, zaměstnanci budou schopni vyhledávat v informačním systému, musí umět formulovat požadavky na vyhledávání, informace by měly být ukládány nějakou společnou metodou, to se hodí jak při čtení informací, tak při jejich vyhledávání, v případě, že s informací takto nakládáme, tak by se její využití mělo vyplatit. 6.4.2.2 Funkce/procesy V této části se zabýváme možností, jak podpořit podnikové procesy ze strany funkcí informačního systému. Jde nám o stanovení funkční a procesní architektury IS/IT. Funkční architektura IS/IT Funkční architektura je přehledný hierarchický model, ve kterém znázorníme funkce informačního systému. V tomto modelu zajdeme nejdále na úroveň podpory funkcí, které mají k dispozici samotní uživatelé. Budeme se zabývat tzv. elementárními funkcemi. Tyto funkce jsou definovány daty, které se přivádějí na vstup a jejich výstupy, způsobem jakým jsou data převedena ze vstupních na výstupní. Dále se zabýváme řídícími daty. Samotná řídící data se nezpracovávají, ale obsahují soubor pravidel, kterými se zpracování řídí.
43
Jako příklad elementární funkce lze uvést vyúčtování automobilu: Vstup: počet najetých kilometrů, průměrná cena pohonných hmot (podle účtenky nebo vyhlášky), průměrná spotřeba osobního vozu. Řídící data: schválení vyúčtování pověřeným pracovníkem, měsíční zúčtovací období. Výstup: výpočet náhrady zaměstnanci. Metodika MDIS rozděluje události na informační, časové a mimořádné. Informační událost vznikne, když do podniku přijde nějaká informace. Například příjmem účtu za telefon, aktualizací skladových zásob (dochází ke změně stavu). Časová událost se váže na určitý časový bod. Například do 20. dubna musíme zaplatit účet za telefon. Mimořádná událost porušuje normálně běžící procesy. Například nabourání firemního automobilu, vyhoření budovy atd. Toto rozdělení využijeme hlavně v případě, že se rozhodneme automatizovat řízení procesů. Procesní architektura IS/IT V rámci procesní architektury sledujeme, jak je podnik schopen reagovat na různé události.
Na události má podnik odezvy, které představují činnosti a funkce IS/IT. Do
činnosti spadají akce, které nemají zajištěnou přímou podporu u IS/IT. Funkce jsou akce zcela zajištěné a obsloužené ze strany IS/IT. Dále se zde můžeme setkávat s pojmem životní historie entity. Tato entita si všímá všech stavů, do kterých se může dostat datová entita. A také ji zajímají ty stavy, které vznikají při přeměnách mezi stavy. Přeměny mezi stavy vznikají v případě, že přijde nějaká událost, která ovlivní stav a dojde k přeměně. Ke ztvárnění životní historie entity se používají stavové diagramy entit. 6.4.2.3 Organizační a legislativní aspekty Provozované programy v podniku musí být v souladu se zákony dané země. Stejně tak musí vyhovovat nařízeními a předpisy podniku. Dále bychom při budování IS/IT měli respektovat obecně přijímané a uznávané normy. V této části se tedy snažíme zformulovat nařízení, předpisy a normy podle, kterých se budeme řídit při budování IS/IT podniku.
44
Většinou se stává, že když spustíme nové IS/IT, tak to ovlivní organizační strukturu podniku. Když popisujeme organizaci podniku, tak ji musíme s každou změněnou částí IS/IT upravit. Většinou se organizační struktura rozděluje na primární a sekundární. Primární se většinou znázorňuje typickou stromovou strukturou. V ní jsou znázorněny pozice v podniku s jejich pravomocemi. Pravomocemi se většinou myslí, jaká pozice má jaký vztah k ostatním pozicím. Vztah může byt nadřízený, podřízený, nebo na stejné úrovni. Sekundární organizační struktura se v podniku tvoří například v případě, když sestavujeme tým lidí, který bude pracovat na projektu. Nemusí být v podniku jediná, může být vytvářena účelově. Také zde upřesňujeme předpisy pro to, jak budeme postupovat při rozvíjení, servisu a chodu IS/IT. Jednoznačně určujeme, kdo se bude o co v podniku starat, jaké budou mít jednotlivé pozice práva a jaké budou postupy při řešení problémů. 6.4.2.4 Pracovní, sociální a etické aspekty V této dimenzi se zabýváme: složením pracovníků po zprovoznění nového IS/IT (věk, zkušenosti, kvalifikace), budoucích požadavků na zaměstnance a jejich ovlivněním novým IS/IT (školení, propouštění), způsobem vtisknutí naší firemní filozofie, jak budeme moci využít u nových zaměstnanců jejich předešlé zkušenosti a kontakty, školením zaměstnanců pro práci s informačním systémem, především pro ukládání dat a jejich hledání, jak dát podnět lidem k vyššímu výkonu. Pro efektivní práci s informačním systémem je velice důležité školení zaměstnanců. Lidé, kteří budou provádět školení, by neměli být vybírání pouze toho, že jsou služebně starší, protože se v podniku mohou zaměřovat pouze na funkce informačního systému, které využívají z pohledu své pozice. Proto mohou ztrácet přehled o ostatních funkcích. Jejich znalost ostatních funkcí se postupem času snižuje. Pokud tito lidé budou předávat svoje znalosti dále, tak se budou všeobecně a postupně znalosti o informačním systému snižovat, neboť se toho bude učit čím dál méně. 45
6.4.2.5 Software Zde určíme druh, způsob nastavení a jak na sebe budou působit části softwarového vybavení. Také se zde rozhoduje o tom, jestli a jaký software koupíme už hotový, nebo si ho necháme vyvinout. 6.4.2.6 Hardware V této dimenzi rozhodujeme o hardwarovém vybavení. Řešíme například potřebný počet serverů, pracovních stanic pro uživatele a jejich vybavení periferními zařízeními atd. 6.4.2.7 Ekonomické aspekty Uděláme finanční rozvahou celého IS/IT. Spočítáme si celkovou investici do přípravy, nasazení a provozovaní a porovnáme s předpokládanými přínosy – vyhodnotíme ekonomickou návratnost. Dále si ujasníme, odkud budeme čerpat peníze a jakou dobu. Stanovíme, co by mělo být v první řadě podpořeno ze strany IS/IT. Ale totéž uděláme naopak. Tedy řekneme si, co tuto podporu nevyžaduje, nebo není tak důležité. Tyto úvahy nám pomohou v případě, kdy musíme například snížit náklady a některé okrajové funkce systému obětovat. 6.4.2.8 Vztahy mezi dimenzemi Pokud pracujeme na nějakém návrhu řešení, tak je vhodné také řešit tyto dimenze ve vztahu k ostatním dimenzím. 6.4.2.9 Metody V této dimenzi si stanovíme, jaké techniky a prostředky budeme v jednotlivých etapách vývoje IS/IT používat. 6.4.2.10 Dokumenty Stanovíme, jaké údaje budeme zaznamenávat v etapách projektu a jaké dokumentace budou vznikat ve spojení s výstupy jednotlivých etap. 6.4.2.11 Řízení prací dané fáze V této dimenzi si určíme kroky, předpisy a strukturu práce na IS/IT. Řekneme si, jaký pracovník bude na jakou práci určený, kdy by jí měl udělat, kdo ponese za co odpovědnost, kolik peněž je vyčleněno atd. 46
6.5 Vytvoření konceptuálního schématu pomocí MDIS 6.5.1 Konceptuální schéma MDIS Při stavbě konceptuálního schématu vycházíme v metodice MDIS z obou řešitelských dimenzí. Zde se také setkáme s tím, že v metodice MDIS se v každé etapě snažíme použít všechna hlediska. Musíme si dávat pozor na to, že se důležitost jednotlivých hledisek mění, a to podle toho, v jaké etapě se nacházíme. Pokud v podniku používáme strategické řízení IS/IT, tak nám může pomoci při jeho plánování metainformační systém. Ten nám pomůže s popisem a zhodnocením verzí IS/IT z hlediska času a jejich vzájemným působením. Dále je vhodné podle metodiky MDIS použít postup, při kterém si řekneme hlavní body v jednotlivých etapách IS/IT (podle 1): 1. Vytyčení čeho chceme dosáhnout v té dané fázi. Přitom budeme brát ohledy i na ostatní fáze a cíle podniku. 2. Naplánování práce na etapě (např. kdo bude co dělat). 3. Zjištění problémů, které mohou nastat v jednotlivých etapách. Následně podle toho upravit způsob práce. 4. Načrtnutí toho, co budeme dělat v jednotlivých etapách (uděláme hrubý návrh). 5. Zhodnocení aktuálního stavu IS/IT z různých řešitelských pohledů a jejich vzájemných vazeb. 6. Uskutečnění kontroly čeho chceme dosáhnout. Pokud kontrola potvrdí, že naše cíle jsou v pořádku, pak můžeme pokračovat v realizaci. Ale pokud ne, tak se musíme vrátit k bodu číslo 2. Tedy k přepracování plánu prací na etapě. 7. Po návrhu pro jednotlivé úrovně abstrakce provedeme dílčí návrh IS/IT. Po návrhu globální architektury provedeme například postupně tyto další návrhy: datové architektury, funkční architektury, softwarové architektury, hardwarové architektury. a dále navrhneme potřebné úpravy organizační struktury podniku. 47
8. Zkoumání, jak na sebe působí různé dimenze. 9. Kontrola konceptu formou testování. 10. Představení řešení, závěrečná diskuze a použití v další etapě.
Pokud provádíme kontrolu, tak se řídíme tím, čeho chceme dosáhnout. Je vhodné určit nějakého zaměstnance, který bude tyto kontroly provádět. Většinou je tímto zaměstnancem manažer projektu. Také je důležité, aby tým měl alespoň hrubý návrh hlavních záměrů,toho, čeho bychom chtěli docílit. Důvodem je, že když se bude zhodnocovat aktuální stav IS/IT z různých řešitelských pohledů a jejich vzájemných vazeb (etapa 5.), tak se může stát, že se budeme zabývat věcmi, které pro nás nebudou důležité. Do příprav plánu práce je nutné sbírat informace jak od lidí na řídících pozicích, tak i od samotných uživatelů. Získané informace od lidí na řídících pozicích se využijí zejména při ujasnění, co se bude pomocí IS/IT v podniku podporovat a zhodnocení toho, jaký to bude mít pro podnik význam. Informace od uživatelů nám pomůžou při rozhodování, jaké jednotlivé funkce by měly programy plnit. Tady se budeme už zabývat podrobnějším popisem – analýzou dílčích činností. Z důvodu charakteristických rysů některých problémů musí být řešitelské pohledy upraveny při návrhu globální strategie podniku.
48
7. Úprava metodiky MDIS na určitý projekt 7.1 Důvody pro úpravu metodiky na určitý projekt Jak už jsem psal a vysvětlil v předchozích kapitolách, je každý projekt do jisté míry unikátní a nelze tak stanovit jeden univerzální řešitelský postup přístupu k řešení a samotnému řešení projektů IS/IT. My musíme tyto řešitelské postupy upravovat s ohledem na řešený problém. Dále se pokusím nastínit model, jak by mohl vypadat postup při řešení projektu IS/IT.
Co bychom měli brát v úvahu při práci na projektu (částečně podle 1): Povahu řešeného problému (např. u rozhodování před koupí softwaru): -
Koupíme TASW, který poté sami nastavíme pro potřeby procesů podniku. Nebo procesy podniku upravíme podle možností TASW. Také je důležitý krok výběr TASW.
-
Obstaráme si vše potřebné pro vývoj softwaru vlastními silami. Budeme používat ASW. Tady musíme dbát na vhodný výběr prostředí, ve kterém budeme vyvíjet a dobrou formulaci požadavků pro vývojáře.
-
Pouze v případě, že nenajdeme vyhovující TASW tak je dobré jít cestou individuálního vývoje. Protože tato cesta je velice náročná. Jak na peníze, tak na schopnosti řešitelů.
Poznámka: Může nastat i situace, kdy můžeme využít kombinaci těchto dvou metod. Rizika a velikost potíží a jejich náročnost Čím větší a náročnější problémy, tím bude potřeba větší účast pracovníků. Při velkém počtu pracovníků vzniká nutnost kvalitní koordinace práce. O to se většinou stará manažer projektu. Kolik času můžeme čemu věnovat Vlastnosti a množství pracovníků
49
Pokud se obrátíme na zaměstnance, kteří už řešili více projektů tak mohou mít spoustu metod vžitých a dělají je automaticky. Ale když oslovíme někoho, kdo tyto zkušenosti nemá, tak je nutné školení a podrobnější kontrola jejich práce. Vyčleněné peníze na projekt Pokud budeme mít málo peněz na projekt tak musíme být co možná nejpodrobnější při plánování.
Kvalitní manažeři (resp. projektové vedení) by měli být schopni rozpoznat všechny hrozby na projektu a přizpůsobit práci jejich významu. Nebezpečné je také to, když manažer hledá souvislosti s jinými projekty, tam kde nejsou. A poté se podle nich rozhoduje. U některých vyjmenovaných bodů, popisujících na co bychom si měli dávat pozor při přípravě a práci na projektu, je možné, že bude vhodné je spojit dohromady. To se děje většinou v praxi na menších projektech. Musíme si ale dát pozor na to, aby se nám neztratil obsah.
7.2 Vytváření prototypů při práci na projektech IS/IT Když řešíme projekt, pouze na základě slovního popisu
jak ho budeme dělat,
nemusíme vždy odhalit všechna úskalí. Ke snížení rizika nespravného fungování nějaké aplikace, je vhodné si vytvořit testovací model. Bude to prototyp, na kterém si vyzkoušíme to, co potřebujeme a to již v průběhu vývoje, nikoli až v ostrém provozu. Nemělo by se stát, že bychom předali zákazníkovi program, který bude např. pomalý, nepřehledný, příliš složitý. Chyb, které mohou vést k těmto problémům, je mnoho: špatně formulované požadavky ze strany zákazníka, řešitelé si jsou svou prací natolik jistí, že se nechtějí obtěžovat kontrolou, ten kdo si objednává a platí zakázku nechce financovat zbytečné pokusy. Na projektu postupujeme postupně po etapách. I v rámci etapy krok po kroku. Vracíme se na předcházející etapy nebo kroky pouze v případě, když odhalíme chybu. Čím později chybu odhalíme, tak je její odstranění nákladnější. Cílem vytváření prototypů je zmenšování rizika při práci na projektu.
50
Výhody vytváření prototypů: můžeme pomocí něho ukázat, jak bude např. konečná verze programu vypadat. Tento model poté můžeme prodiskutovat se zákazníkem, jestli je se vším spokojený, usnadňuje tvorbu a zavádění softwaru. Uděláním prototypu odhalíme chyby, které bychom pouze návrhem nezjistili.
Nevýhody vyváření prototypů: musíme si přesně rozmyslet, na co přesně použijeme prototyp a jakou hodnotu budou mít informace z něj získané. Protože by se mohlo stát, že prostředky vynaložené na tvorbu prototypu nebudou odpovídat hodnotě získaných informací, z důvodu snadných úprav prototypu by si uživatel mohl začít myslet, že se finální program bude také takto snadno upravovat, nemusí se dařit přesvědčit toho, kdo projekt platí, že tvorba prototypu je důležitá.
7.3 Přírůstkový přístup k tvorbě IS/IT Zde se snažíme o co možná nejrychlejší získání výsledků práce. Většina metod pracuje tím způsobem, že jdeme postupně od jedné etapy ke druhé. Abychom mohli jít do další, tak musíme úspěšně splnit předchozí. Zkoumáme proto i závislosti jednotlivých částí. Pokud to je možné, práci v jednotlivých etapách rozdělíme na jednotlivé vzájemně nezávislé části. A na každé takové části pak můžeme pracovat zvlášť. Podmínkou je, že každá část musí být schopna dílčího provozu samostatně. Funkčně testovat lze až po sloučení určitého počtu částí do dílčího řešení. Vždy se funkčně ověřují a testují výstupy etap.
51
8. Modelový podnik a SI V rámci přípravy své bakalářské práce jsem se byl podívat ve dvou firmách na to, jak se principy a postupy systémové integrace uplatňují v praxi. Záměrně jsem si vybral typické firmy z oblasti IT, firmu Kancelářské stroje s.r.o3 a Bitservis s.r.o4. V obou případech jsem získal informace od vedoucích pracovníků. Pro účely práce jsem zpracoval poznatky z firmy Kancelářské stroje.
8.1 Vývoj vnitropodnikového informačního systému Začal bych nejprve ekonomickým systémem. Firma začínala s ekonomickým systémem KSIS. Ten jí po nějaké době přestal vyhovovat, hlavně proto, že byl stavěn pro menší firmu. Byl vyvíjen a upravován na zakázku a nevýhodou byla závislost pouze na jednom programátorovi. Po analýze potřeb byl na základě požadavků vybrán nový a modulární systém Money S55. V první řadě do nového systému převedli ekonomickou agendu (příjem zboží, přijímání faktur, vklady, vydávání faktur, přijímání objednávek). Samotné účetnictví stále zpracovávala, stejně jako v případě staršího systému, externí firma. Vedla ho v systému Navision6, které ale účetnické výstupy byly předávány v papírové podobě. Po zavedení ekonomického systému Money S5 byl hlavní důraz kladen úspěšné převedení ekonomiky firmy. Ihned poté začali pracovat na tom, aby mohl být do řešení integrován i modul účetnictví a nové účetnictví vedeno v systému Money S5. Přípravná a integrační fáze trvala půl roku. Než systém plně nastavili a odladili, účetnictví zpracovávali souběžně v obou systémech. Po rozloučení s externí firmou dnes účetní agendu plně zpracovává jeden účetní poradce, který kontroluje správnost vedení účetnictví, a ekonomická ředitelka. Ostatní zaměstnanci systém využívajíc v rámci svých pracovních povinností. Velkou výhodou je, že systém poskytuje okamžité odezvy na vstupy, a nyní tak mohou vidět kompletní ekonomickou
3
www.kancelarskestroje.cz www.bitservis.cz 5 www.money.cz/money-s5 6 www.navisys.cz/cs/microsoft-dynamics?gclid=CPOp88691akCFdoS3wodi00FMQ 4
52
agendu a účetnictví online. Dřívější stav, kdy než externí firma účetní informace zpracovala, dosahovalo zpoždění informací o stavu firmy třeba i dva měsíce. Integrace modulu účetnictví byla provedena až na úroveň napojení na externí bankovní systém. Všechno je nyní elektronicky připojeno na firemní účet v bance. Tam se stahují výpisy z banky. Párují se proti jednotlivým operacím, fakturám a odcházejícím platbám do banky. Postupně byly využívány a integrovány další agendy, některé původně vedené ručně. Výsledkem projektu komplexní integrace vnitrofiremních agend do systému Money S5 je systém, ve kterém je vedena kompletní fakturace, zásoby na skladě, veškeré skladové operace, řízení objednávek, evidence majetku, personalistika a mzdy zaměstnanců. Dostali se do fáze kdy je v systému řešeno jak personalistika, mzdy, účetnictví tak celý oběh zboží. To, co neměli ještě úplně vyřešené, byla fakturace služeb. Služby se nedají účtovat obdobně jako zboží, protože cena se odvíjí od smlouvy, která je uzavřená s konkrétním zákazníkem. Proto potřebujeme vědět jaký zaměstnanec co a pro jakého konkrétního zákazníka dělal, a taky potřebujeme vědět, jakou s tímto zákazníkem máme domluvenou konkrétní sazbu. Fakturaci rovněž ovlivňuje, zda zákazníkovi poskytujeme služby za paušální platby, pevnou (fixní) cenu, nebo se každý měsíc vykazuje nějaký výkaz práce a podle toho fakturujeme. Tohle také dříve omezeně řešili v systému KSIS. Nakonec byly i tyto služby vyřešeny zakázkovým vytvořením vhodného modulu a jeho přímou integrací do systému Money S5. Napsání tohoto „Projektového modulu“ si objednali přímo na míru, cena za realizaci překročila půl milionu korun. Po úspěšné integraci mají technici firmy k dispozici webové rozhraní. Přes toto rozhraní se přihlásí na jejich interní server. Přes webové rozhraní si načítají úkoly a zadávají každý den, od kolika do kolika co dělali, a u jakých zákazníků. V tom je logika toho programu. Stačí zadat zákazníka, jaké činnosti tam dělali (dané smlouvou) a poté se automaticky vypočtou a zaúčtují ceny práce. Na konci měsíce systém vygeneruje přehledy těchto prací a potom faktury. Další věc, kterou se povedlo automatizovat, bylo integrace se systémy největších dodavatelů. Napojením se zajistilo, aby v tomto systému měly i jejich aktualizované ceníky. Při zpracování nabídek tak mohou využít ceny od těchto dodavatelů a mají aktuální přehledy o jejich cenách. Mohou porovnat ceny zboží mezi sebou a mají přehledy o jejich počtu na skladě. Také celá fakturace probíhá elektronicky.
53
8.2 Shrnutí Kancelářské stroje jsou firmou infrastrukturální, která poskytuje komplexní IT servisní služby. Zaměřuje se na střední a velké zákazníky, nevyužívají prodeje formou e-shopu. O vyhledávání zákazníků se starají dva obchodníci, často jsou doporučováni i stávajícími zákazníky. Komplexní integrací všech firemních agend do systému Money S5 spolu s vývojem části systému na zakázku se firmě Kancelářské stroje podařilo vytvořit vnitřní informační systém plně přizpůsobený vykonávaným činnostem. Díky pečlivému vývoji a integraci všech složek systém poskytuje on-line informace potřebné jak k ekonomickému řízení firmy, tak i k zajištění každodenních pracovních činností.
54
9. Systémová integrace v ČR Tato kapitola vznikla na základě praktických poznatků a informací, které jsem sbíral po dobu přípravy a psaní této práce. Vychází z poznatků z přednášek, vyhledávání na internetu a v neposlední řadě i z konzultací s odborníky z IT firem.
9.1 Jak na výběr systémového integrátora Integrační projekt ani volba systémového integrátora nebývají prakticky nikdy „stavbou na zelené louce“. V naprosté většině případů firmy staví na dlouhodobější spolupráci s dodavatelskými firmami a integrační služby tak hledají ve svém zavedeném portfoliu dodavatelů. Často ale dochází k tomu, že systémová integrace jde nad rámec možností těchto firem, ať už technickým rozsahem a kvalifikačními požadavky, tak i požadavky na garance pro pokrytí rizik a případných následných škod pro případ neúspěchu projektu. Právě požadavky na výši garancí (složení jistiny, možné smluvní pokuty) mnohdy směrují integrační projekty k firmám nebo skupinám s dostačující finanční silou. Pro rozhodování při výběru systémového integrátora je zřejmě nejlepším vodítkem ke snížení rizika neúspěchu nalezení takového integrátora, který má s integrací projektů v oblasti našeho zájmu zkušenosti a prokazatelné výsledky. Pro toto hledání je ale nutné mít velmi dobrou vlastní představu rozsahu a obsahu integračního projektu. Vzhledem k tomu, že se jedná o dlouhodobé projekty zasahující obchodní procesy firmy, je stále častější praxí použití externí konzultační firmy. Tyto firmy hlavně v rozsáhlejších projektech pomohou posunout projekt do kontextu rozvoje nejen IT technologií, ale i obchodních strategií. Zároveň se tím omezí i některé setrvačné vlivy a omezení daná „pohledem zevnitř“. I konzultační firmy, které formou studie připraví, upřesní nebo přímo definují projektový záměr, bývají specializované na určité oblasti IT, a často spolupracují se systémovými integrátory na následné realizaci projektu. Doporučení vhodného a ověřeného systémového integrátora pak může přijít i z této strany. Obdobně i řada výrobců unikátních programových i technických řešení má vlastní metodiky a certifikační programy, ve velké míře zajišťující úspěšnou implementaci a integraci a eliminující tak projektová rizika. Tito výrobci pak publikují seznamy firem, které splňují kvalifikační kritéria a jsou tak automaticky vhodnou volbou nejen pro implementační, ale i pro integrační projekty. 55
9.2 Internet a systémová integrace Výhodou českého trhu je, že firmy mohou poměrně bohatě čerpat z možností poskytovaných internetem. Prakticky všechny IT firmy, působící na českém trhu v oblasti systémové integrace, mají dobře zpracovanou internetovou prezentaci s detailními informacemi o své nabídce. Druhou výhodou je, že v České republice dlouhodobě působí Česká společnost pro systémovou integraci (ČSSI, http://www.cssi.cz/cssi/ ), která pořádá konference a vydává časopis Systémová integrace – obojí zaměřené na služby a informace o poskytovatelích služeb systémové integrace v ČR. Tradičně jsou sestavovány žebříčky úspěšnosti IT firem, včetně vyhodnocování v kategorii systémový integrátor. Tyto žebříčky jsou k dispozici na adrese http://top.hottop.cz/. Jsou kromě jiného i propozice soutěže a hlasovací formulář http://top.hottop.cz/files/hlasovani/hlas_ict_2011.htm , ze kterého je patrné, jaká kritéria se v žebříčku vyhodnocují.
9.3 Kvalita informačních zdrojů Jako ve všech oblastech ale platí, že je třeba při volbě systémového integrátora zvažovat a vyhodnocovat relevanci informací.
9.3.1 Použití zprostředkované informace Doporučení třetích firem nejen mohou, ale často i jsou ovlivněny dalšími, většinou vlastními ekonomickými zájmy. I když mohou být správná, nemusí nutně zahrnovat všechny (a možná i vhodnější nebo výhodnější) alternativy a nemusí tak nutně být vždy optimální.
9.3.2 Používání firemních webových informací Firmy nabízející služby systémové integrace často uvádí i reference na integrační projekty. Problémem těchto informací může být, že jsou sice věcně správně, ale nebývá z nich patrné, jaký rozsah služeb integrátor plnil vlastními silami, nakolik byly projekty ukončeny v termínech, jaké problémy je doprovázely. Mnohdy je uveden pouze zákazník bez upřesnění obsahu projektu. Dalším problémem je, že firmy musí získat svolení zákazníka k uvedení reference na projekt, tedy veřejně publikovat, že projekt proběhl. Informace o celé řadě projektů se tak vůbec nemusí do zveřejněných referencí dostat (typicky bezpečnostní
56
projekty, některé projekty pro státní správu). V některých případech se reference považují za vnitřní důvěrnou informaci a poskytují se pouze na vyžádání.
9.3.3 Veřejné seznamy a ankety Na tomto místě je třeba si uvědomit, že celá řada „registrů“ služeb vzniká dobrovolnou registrací firem s tím, že firma zařazuje a profiluje „sama sebe“. Problémem pak může být, že výstup takového registru postaví na roveň firmu, která jednou integrovala 3 servery zákazníka do virtuálního prostředí, s firmou, která integruje na mezinárodní úrovni IT zákazníka od datových center až po obchodní procesy. Podobné problémy zaznamenávají i různé otevřené ankety a z nich vyplývající žebříčky. Jinou vypovídací hodnotu asi má anketa ke spokojenosti se systémovým integrátorem provedená mezi řediteli IT oddělení, odpovědnými za projekty, a mezi veřejností.
9.3.4 Informace z tisku a internetových médií Tyto informace trpí často podobnými neduhy, jako firemní webové prezentace. Důvodem je hlavně relativní závislost autorů – a to jak profesní, tak i firemní. Na vině je komplexnost systémové integrace jako takové a značné množství používaných produktů a nástrojů. Špičkový specialista na systémovou integraci většinou potřebuje vyrůstat v prostředí, kde se projekty řeší (firma) a je svázán s určitým portfoliem nástrojů. Nevynucené přechody na jiné metodiky jsou neefektivní (finančně, časově). Důsledkem je, že naprostá většina jinak špičkových článků popisujících nástroje a metody systémové integrace je poplatná firmě, často i sponzorující článek do odborného periodika, a produktovým znalostem autora. Tyto články lze použít jako dobrý informační zdroj, ale jen velmi omezeně pro hodnocení a výběr založený na srovnání. Určitou výjimku tvoří teoretická pracoviště některých nadnárodních firem a akademická pracoviště, které ale mají malou publikační sílu, anebo články nejsou snadno dostupné. Poměrně poučné bývají články o zkušenostech z provedených integračních projektů ze strany zákazníků, ať už od projektových vedoucích nebo přímo z úrovně ředitelů (obchodního nebo pro informatiku). Většinou dobře definují rozsah projektu a zasazují ho do časového rámce.
57
Pro orientaci v problematice systémové integrace a pro výběr vhodného dodavatele je tedy k dispozici poměrně dost zdrojů. Z výše uvedeného vyplývá, že stejně jako v jiných oborech, není jedno univerzální řešení, jedna tabulka, podle které se lze řídit. Úspěšný výběr systémového integrátora se tak neobejde bez důkladné přípravy, širšího výběru kandidátů s použitím výše uvedených zdrojů, jejich prověřením a požadavkům na poskytnutí dodatečných informací. Závěrečná fáze se neobejde bez cenové orientační nabídky.
58
10. Závěr V práci jsem se pokusil zpracovat a ukázat problematiku systémové integrace. Vzhledem k rozsáhlosti a komplexnosti tématu jsem se soustředil hlavně na identifikaci hlavních požadavků kladených na systémovou integraci, důležitost správného výběru systémového integrátora a základní seznámení s metodami používanými v integračních projektech. Značná část práce je věnována popisům možných rizik a doporučením výběru vhodných postupů při řízení projektů systémové integrace a volbě metod. Část práce je věnována i praktické aplikaci metod systémové integrace. V rámci své bakalářské práce jsem získal praktické poznatky, které jsem v práci i částečně zpracoval. Jednalo se o firmy, které se zabývají službami v IT oblasti. Celkově jsem se při zpracování tématu systémové integrace poměrně podrobně seznámil s celou problematikou. Téma systémové integrace je velmi široké a pro jejich využívání je bezpodmínečně nutné důkladné seznámení s jejími metodami a hlavně praxe. Je totiž patrné, že každý projekt systémové integrace vyžaduje vlastní přístup a jen velmi těžko lze nalézt dva shodné projekty.
59
11. Seznam použité literatury Tištěné monografie (1) VOŘÍŠEK, Jiří. Strategické řízení informačního systému a systémová integrace. Praha : Management Press, 2002. 324 s. ISBN 80-85943-40-9. Části tištěných monografií (2) VOŘÍŠEK, Jiří. Strategické řízení informačního systému a systémová integrace. Praha : Management Press, 2002. Charakteristika MDIS, s. 119. (3) VOŘÍŠEK, Jiří. Strategické řízení informačního systému a systémová integrace. Praha : Management Press, 2002. Charakteristika MDIS, s. 119. (4) VOŘÍŠEK, Jiří. Strategické řízení informačního systému a systémová integrace. Praha : Management Press, 2002. Řešitelské pohledy na IS/IT – dimenze čas, úroveň abstrakce a úroveň integrace, s. 123. (5) VOŘÍŠEK, Jiří. Strategické řízení informačního systému a systémová integrace. Praha : Management Press, 2002. Řešitelské pohledy na IS/IT – dimenze čas, úroveň abstrakce a úroveň integrace, s. 125. (6) VOŘÍŠEK, Jiří. Strategické řízení informačního systému a systémová integrace. Praha : Management Press, 2002. Řešitelské pohledy na IS/IT – dimenze čas, úroveň abstrakce a úroveň integrace, s. 128. Příspěvky v elektronických monografiích a jejich částech (7) MATĚNA, Robert : Stavět eshop na míru nebo koupit hotový systém? IASW nebo TASW? [on line][cit. 2011-06-20]. Dostupný z http://www.solisshop.cz/clanek/Stavet-eshop-namiru-nebo-koupit-hotovy-system-IASW-nebo-TASW (8) MOTYČKA, Arnošt : Architektura IS. [on line][cit. 2011-06-20]. Dostupný z http://ari.wikidot.com/architektura-is (9) MINIBERGER, Bohumil. Organizační a informační strategie 1+2. Prezentace přednášek ze stejnojmenného předmětu-[on line][cit. 2011-06-20]. Dostupný z https://is.bivs.cz/auth/el/6110/leto2011/B101OIS2/?fakulta=6110;obdobi=57;predmet=14 881
60
61
