Projektování informačních sys- témů Distanční studijní text Dominik Vymětal, Roman Šperka, Petr Suchánek Karviná 2017 Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 2 Obor: Informační a komunikační technologie, Management a správa Klíčová slova: Informační systém, informační a komunikační technologie, projekt, modelování, hodnotový řetězec, simulace, řízení projektu. Anotace: Tato aktualizovaná studijní opora je především určena pro studenty studijního programu Manažerská informatika, kteří mají předmět Projektování informačních systémů ve studijním plánu jako jeden ze základních předmětů teoretického základu. Zabývá se představením základních pojmů z oblasti metodologie tvorby informačních systémů, modelování podnikových procesů a postupem realizace informačního systému podniku v podobě projektu. Po představení současného stavu používání informačních technologií jsou představeny základní metodologické principy tvorby informačních systémů, způsoby modelování podnikových procesů a přístupy k návrhu a analýze informačního systému podniku. Druhá část opory je věnována praktickým principům a postupům projektového řízení v oblasti informačních systémů podniku. Autor: Ing. Dominik Vymětal, DrSc. doc. RNDr. Ing. Roman Šperka, Ph.D. doc. Mgr. Petr Suchánek, Ph.D. Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 3 Obsah ÚVODEM............................................................................................................................8 RYCHLÝ NÁHLED STUDIJNÍ OPORY...........................................................................9 1 TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ.............10 1.1 Vymezení pojmů .................................................................................................11 1.1.1 Definice systému a informačního systému ..................................................11 1.1.2 Informační a komunikační technologie .......................................................13 1.1.3 Typy úloh zpracovávaných v informačních systémech...............................14 1.2 Úloha ICT v podnikovém řízení..........................................................................15 1.2.1 Úloha ICT v systémech řízení......................................................................15 1.2.2 Hodnota ICT pro podnik..............................................................................17 1.2.3 Hodnocení ICT pomocí produkční funkce ..................................................18 1.2.4 Pragmatický přístup k hodnocení ICT .........................................................18 1.2.5 Důvody pro informační projekty .................................................................20 1.3 Důležitá rozhodnutí na začátku projektu IS ........................................................21 1.4 Modelování procesů ............................................................................................22 1.5 Využití obchodních vzorů...................................................................................31 1.6 Modelování využívající hodnotové řetězce.........................................................34 1.7 Modelování režijních nákladů při plánování výroby pomocí modelu REA .......40 1.7.1 Koncept úrovně pravidel v modelu REA.....................................................40 1.7.2 Návrh modelování režijních nákladů v plánování výroby pomocí REA.....42 1.8 Dynamizace hodnotového modelu REA.............................................................44 1.8.1 Zachycení změny stavů................................................................................45 1.8.2 Diagram aktivit ............................................................................................46 1.8.3 Sekvenční diagramy.....................................................................................47 1.9 Zobecnění postupů při modelování a simulaci podnikových procesů. Agentový přístup. ...........................................................................................................................51 1.9.1 Zobecnění postupů při modelování. Simulace.............................................51 1.9.2 Agentový přístup k modelování a simulaci procesů....................................55 1.9.3 Příklad použití agentů pro simulaci obchodní organizace...........................57 1.9.4 Zobecnění postupu modelování...................................................................60 Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 4 1.10 Přístupy k návrhu a analýze IS ........................................................................61 1.10.1 Strukturovaný přístup...................................................................................62 1.10.2 Objektově orientovaný přístup.....................................................................63 1.10.3 Prototypování a agilní metody analýzy a návrhu.........................................64 1.10.4 Aspektové přístupy ......................................................................................67 1.10.5 Shrnutí přístupů k projektování a zavádění informačních systémů.............69 2 ŘÍZENÍ PROJEKTŮ IS.............................................................................................75 2.1 Management projektů a projektové organizační struktury..................................78 2.1.1 Čistá projektová organizační struktura ........................................................79 2.1.2 Útvarová projektová organizační struktura..................................................80 2.1.3 Maticová projektová organizační struktura .................................................81 2.1.4 Role v projektových strukturách..................................................................83 2.2 Týmové řízení projektu IS ..................................................................................84 2.3 Základní struktura organizace projektu IS ..........................................................85 2.3.1 Vlastník projektu..........................................................................................86 2.3.2 Řídící výbor projektu ...................................................................................86 2.3.3 Expertní tým.................................................................................................86 2.3.4 Vedoucí projektu IS .....................................................................................87 2.3.5 Typy manažerů ICT projektů z hlediska odborných kompetencí................88 2.4 Styly řízení projektu............................................................................................89 2.5 Vyjednávání v projektech IS...............................................................................90 2.6 Projektový tým ....................................................................................................91 2.6.1 Člen projektového týmu...............................................................................92 2.6.2 Komunikace jako důležitý nástroj ...............................................................94 2.6.3 Rizika konfliktů IS.......................................................................................97 2.6.4 Praktická doporučení ...................................................................................98 2.7 Jednání probíhající v průběhu projektu...............................................................99 2.7.1 Oficiální zahájení projektu...........................................................................99 2.7.2 Jednání řídícího výboru..............................................................................100 2.7.3 Jednání projektového týmu........................................................................100 2.7.4 Jednání dílčích týmů ..................................................................................101 2.7.5 Některá úskalí jednání týmů ......................................................................101 Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 5 2.8 Řízení projektu..................................................................................................102 2.8.1 Činnosti u dodavatele.................................................................................102 2.8.2 Činnosti u odběratele .................................................................................103 2.8.3 Řízení a alokace řešitelských zdrojů..........................................................103 2.8.4 Kontrolní činnosti v průběhu projektu IS ..................................................104 2.8.5 Rizika řízení projektů IS ............................................................................106 2.9 Motivace členů týmu a projektový marketing...................................................106 2.9.1 Marketing projektu.....................................................................................106 2.9.2 Faktory motivace projektového týmu ........................................................108 2.9.3 Riziko času a motivace týmu .....................................................................109 2.10 Projekty nadnárodních informačních systémů ..............................................109 2.10.1 Typy architektur nadnárodních informačních systémů..............................109 2.10.2 Formální předpoklady zavádění nadnárodních IS. ....................................110 2.10.3 Metodické otázky spojené s nadnárodními projekty informačních systémů 111 3 FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU ..................................114 3.1 Úvodní studie proveditelnosti IS.......................................................................115 3.1.1 Kdy provádět či neprovádět studii .............................................................116 3.1.2 Rámcový obsah studie ...............................................................................117 3.1.3 Cíle projektu...............................................................................................118 3.1.4 Kdo zpracovává studii................................................................................119 3.1.5 Role externích poradců ..............................................................................120 3.1.6 Analýza požadovaných funkcí...................................................................121 3.1.7 Určení budoucího vývoje požadavků na IS ...............................................122 3.1.8 Odvození požadavků na infrastrukturu......................................................123 3.1.9 Propočet nákladů........................................................................................124 3.1.10 Návrh organizace a řízení projektu............................................................124 3.1.11 Požadavky na lidské zdroje........................................................................125 3.1.12 Hrubý časový plán realizace ......................................................................126 3.1.13 Ekonomické hodnocení projektu ...............................................................126 3.1.14 Formulace závěrečného doporučení ..........................................................127 3.1.15 Časté chyby při rozhodováni o studii.........................................................127 Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 6 3.2 Fáze nabídkového řízení a výběru dodavatele ..................................................128 3.2.1 Výběrové řízení..........................................................................................129 3.2.2 Hodnocení nabídek a jednání o cenách......................................................130 3.2.3 Metoda BQA..............................................................................................131 3.3 Příprava smlouvy...............................................................................................133 3.3.1 Obsah smlouvy na dodávku IS ..................................................................133 3.3.2 Generální dodavatel, subdodavatelé, lokální partneři................................134 3.3.3 Dohoda o typu školení personálu odběratele.............................................135 3.3.4 Stanovení časového plánu projektu ...........................................................135 3.3.5 Problematika výběru dodavatelů a dalších podmínek smlouvy u nadnárodních projektů .............................................................................................136 3.4 Fáze vlastního návrhu IS...................................................................................138 3.4.1 Detailní analýza .........................................................................................139 3.4.2 Cílový koncept...........................................................................................140 3.4.3 Plánování zdrojů a rozpis prací..................................................................143 3.5 Realizační fáze ..................................................................................................145 3.5.1 Příprava realizace.......................................................................................145 3.5.2 Plánování, organizace a provedení převodu dat ........................................146 3.5.3 Akceptační testy.........................................................................................147 3.5.4 Školení a dokumentace ..............................................................................149 3.5.5 Vlastní náběh nového systému...................................................................150 4 KONTROLA A HODNOCENÍ PRŮBĚHU PROJEKTU ......................................152 4.1.1 Strategie kontroly.......................................................................................153 4.1.2 Nástroje kontroly průběhu projektu...........................................................154 4.2 Hodnocení projektů...........................................................................................154 4.2.1 Uživatelské a systémové hodnocení projektu............................................154 4.2.2 Ekonomická efektivnost (hlediska)............................................................156 4.2.3 Následná analýza .......................................................................................156 4.3 Konflikty po zavedení systému.........................................................................157 4.3.1 Koncoví uživatelé ......................................................................................157 4.3.2 Vedení firmy..............................................................................................158 4.3.3 Dodavatel...................................................................................................158 4.4 Důležitost a úloha Hotline po zavedení projektu ..............................................159 LITERATURA ................................................................................................................161 Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 7 SHRNUTÍ STUDIJNÍ OPORY.......................................................................................167 PŘEHLED DOSTUPNÝCH IKON.................................................................................168 Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 8 ÚVODEM Studijní opora je určena zejména studentům studijního programu Manažerská informatika, ve kterém je předmět Projektování informačních systémů zařazen do skupiny předmětů teoretického základu. Obsah a způsob výkladu jednotlivých kapitol může rozšířit obzory i studentům jiných studijních programů na SU OPF nebo jiných vysokých školách, kteří se třeba jen okrajově danou problematikou zabývají z vlastního zájmu nebo se s implementací informačních systémů setkali například ve svém zaměstnání a chtěli by se tímto zabývat i v budoucnu. Vhodným, nikoli nutným, předpokladem pro čtenáře studijní opory resp. studenty jsou základní znalosti z oblasti informačních systémů a jejich využitelnosti v různých typech komerčních i nekomerčních subjektů. Studijní opora je členěna do 4 kapitol, ve kterých jsou srozumitelnou formou prezentovány důležité teoretické i praktické poznatky vázané na jednotlivé části procesu implementace informačního systému. Kapitoly mají vždy stejnou strukturu a jsou v nich využity distanční prvky, z jejichž názvu je všem čtenářům zcela jistě jasný jejich význam. Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 9 RYCHLÝ NÁHLED STUDIJNÍ OPORY Studijní opora je členěna do 4 kapitol. V první kapitole jsou prezentovány základní pojmy a úrovně současného stavu poznání z oblasti informačních systémů (IS) a informačních a komunikačních technologií (ICT) a jejich úloze hodnotě v podnikovém řízení. Jádro první kapitoly tvoří představení modelování podnikových procesů s cílem objasnit složitosti problematiky návrhu IS. Důraz je kladen na procesní a hodnotově orientované metodiky. V závěru první kapitoly jsou představeny agilní, strukturované a objektově orientované metody analýzy a návrhu IS. Druhá kapitola je věnována problematice vlastního projektování IS. Projekty IS se řídí pravidly a zákonitostmi společnými i pro projekty v jiných oblastech. Konkrétní praxe však ukazuje, že bez ohledu na teorii projektového řízení mají projekty IS některé své zvláštnosti. Projekt IS se zpravidla týká technické, programové a organizační části systému jako celku případně jen jedné nebo dvou uvedených složek a to vždy podle toho zda obnovujeme systém jako celek nebo jeho technickou či programovou část. Z tohoto důvodu mohou mít projekty IS různý obsah i strukturu nad stejným objektem (podnikem) v různém čase (nejdříve se řeší hardware a software až následovně, řeší se jen doplnění hardware atd.), vždy však jedna část podmiňuje druhou a je nějakým způsobem projektem zasažena. Právě výše uvedená problematika a konkrétní oblasti a jejich vazby a specifika je obsahem druhé kapitoly. Po charakteristice problematiky řízení projektu přichází na řadu realizace projektu, která se skládá z jednotlivých fází. Ačkoliv můžeme proces realizace projektu krokovat, nelze opustit komplexní charakter projektů IS. Jednotlivé fáze projektu, jejich obsah a váhy se mohou u různých typů projektů lišit, podle čehož lze pak aplikovat různé metodiky. A právě tato témata jsou obsahem třetí kapitoly. Poslední částí každého projektu (nebereme-li v potaz časové období udržitelnosti), je kontrola průběhu projektu a následná nápravná opatření. Tyto činnosti jsou východiskem resp. hlavními metodami jak dosáhnout projektového cíle bez odchylek od původního záměru. Cílem čtvrté kapitoly je představit základní přístupy, metody a nástroje pro to, abychom bylischopnivyhodnotitvýsledekprojektuz hlediskajehofunkčnosti,užitečnostiaekonomické efektivity. TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 10 1 TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ RYCHLÝ NÁHLED KAPITOLY V úvodu provedeme shrnutí základních pojmů a úrovně současného stavu poznání z oblasti informačních systémů (IS). Následně se budeme věnovat úloze a hodnotě informačních a komunikačních technologií (ICT) v podnikovém řízení. Jádro kapitoly tvoří představení modelování podnikových procesů pro pochopení složitosti problematiky návrhu IS. Důraz je kladen na procesní a hodnotově orientované metodiky. Závěrem představíme agilní, strukturované a objektově orientované metody analýzy a návrhu IS. CÍLE KAPITOLY Po prostudování této kapitoly budete umět:  definovat informační systém;  objasnit úlohu ICT v podnikovém řízení;  vysvětlit potřebu modelování podnikových procesů;  objasnit podstatu procesního a hodnotového modelování;  vysvětlit a specifikovat rozdíly mezi strukturovaným, objektově orientovaným a agilním přístupem k analýze a návrhu IS. KLÍČOVÁ SLOVA KAPITOLY Informační systém, data, informace, model, podnikový proces, metodika, návrh, REA, strukturovaná a objektové orientovaná analýza, simulace, obchodní vzory, podnik. Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 11 1.1 Vymezení pojmů 1.1.1 DEFINICE SYSTÉMU A INFORMAČNÍHO SYSTÉMU K ZAPAMATOVÁNÍ Systém je obecně charakterizován jako množina prvků a vazeb. Prvky systémů na dané úrovni rozlišení se chápou jako nedělitelné. Vazby mezi prvky představují jednosměrné nebo obousměrné spojení mezi nimi. Systém se vyznačuje vstupními a výstupními vazbami, pomocí kterých získává informace z okolí a jiné informace do okolí předává. Na systémy nahlížíme zpravidla z hlediska toho, jak komunikují se svým podstatným okolím, jaké tedy mají cílové chování. DEFINICE Na základě uvedeného obecného pohledu, informační systém (IS) definujeme jako uspořádání vztahů mezi lidmi, datovými a informačními zdroji a procedurami jejich zpracování za účelem dosažení stanovených cílů. Z hlediska informačního obsahu zmíníme rozlišení mezi daty, informace a znalostmi pro účely zpracování v informačním systému. Signály - nejnižší složku - můžeme chápat jako analogové nebo digitální nosiče dat. Z pohledu informačního systému považujeme signály za něco, co je dané, za veličinu, která se mění v čase případně i v prostoru nebo místě vzniku. Pro informační systém je daleko důležitější pojem dat a informací. Podle Wienera (1963) je informace obsah toho, co si vyměňujeme s vnějším světem, když se mu přizpůsobujeme a působíme na něj svým přizpůsobováním. Vzhledem k tomu, že pojem informace nyní řadíme k nejobecnějším kategoriím vědy, známe různé definice pojmu informace podle toho, ve kterém vědním oboru se pohybujeme. Cílem naší práce je projektování IS. Proto budeme pojem informace pojímat v pragmatickém smyslu. Data chápeme jako rozpoznané signály (údaje), které vypovídají o situacích a stavech sledovaných a řízených objektů. Jsou podkladem pro další zpracování, během kterého se data mění na informace. Informace jsou tedy taková data, která jejich uživatel používá pro další rozhodování, kterým realizuje svoji zpětnou vazbu na informační systém, aby docílil jeho cílového chování. Při tom však stejná data podle pohledu nebo interpretace mohou mít pro různé uživatele Systém Informační systém Signály Data a in- formace TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 12 různý význam a tudíž představovat různé informace. Díváme-li se na informace z pragmatického pohledu, musíme z tohoto pohledu hodnotit také IS. K pragmatickému pohledu na IS se vrátíme později. Informační systém můžeme také chápat jako určitý druh regulačního obvodu. Základní vlastností regulačního obvodu je existence zpětné vazby korigující chování řízeného systému. Wolf (2006) uvádí zajímavou definici podniku jako regulačního obvodu zobrazenou na Obrázek 1. Podnik vyrábí a prodává výrobky a služby, dodává je na trh a provozuje další agendy jako je personalistika, IS/ICT a ostatní. Z okolí podniku působí na jeho části nejrůznější vlivy (legislativa, přírodní podmínky, konkurence, atd.), které jsou zde označeny jako poruchy. Obdobné vlivy okolí působí i na trh. Výsledkem akce podniku je nějaká regulovaná veličina například obrat, jejíž výstup je veden do měřícího členu, kterým je na příklad účetnictví a/nebo marketing. Výstup z podniku je srovnáván s cílem - vstupem a vzniká rozdílová veličina měřená diferenčním členem tvořeným vybranými podnikovými útvary. Uvnitř podniku ještě působí zpětné vazby, jako jsou informace o výrobě, zaměstnancích, atd. Pohlédneme-li se na podnik tímto způsobem, nevyhneme se otázce stability takového regulačního obvodu. PRŮVODCE TEXTEM V dalším ukážeme, že v rámci uvedených schémat lze nadefinovat celou řadu regulačních smyček, ve kterých působí zpětné vazby. Převážně se jedná o záporné zpětné vazby, u těch smyček, kde lze předpokládat kladnou zpětnou vazbu zase působí jiné vztahy omezující exponenciální růst (například limity skladových nebo výrobních kapacit). Z uvedeného základního pohledu na podnik budeme vycházet i v dalším textu. Umíme-li nadefinovat podnik ve stejné struktuře jako obecný regulační obvod, pak je zřejmé, že techniku projektování systémů založených na ICT můžeme použít jak na projektování technologických, tak i výrobních IS i systémů podporujících vyšší úrovně řízení (střednědobá koncepce, strategie, apod.). Z uvedeného obrázku také vyplývá role toku informací a posloupnosti činností v systému a jeho řízení (dále budeme používat termín workflow). Touto problematikou se zabývají komplexnější projekty, je však pro správnou roli IS klíčová. Pohled na technickou infrastrukturu ve formě blokového schématu uvádí Moos (1993). Sběr signálů (dat) může probíhat ručně, automatizovaně pomocí čárových kódů nebo RFID (Radio Frequency Identification), pomocí různých čidel zajišťujících sběr signálů nebo proudů dat. Tyto signály (data) odrážejí ve smyslu výše uvedeného stav řízeného subjektu. Kódování znamená transformaci těchto údajů do tvarů, které je dále možno zpracovat. IS jako re- gulační obvod Technická infrastruk- tura/blo- kové schéma Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 13 Obrázek 1 Podnik jako regulační obvod Zdroj: upraveno dle Wolfa (2006, s. 62) K ZAPAMATOVÁNÍ Na základě zpracování vzniká akční informace, mající za cíl změnu stavu řízeného subjektu. Aby této informaci řízený subjekt porozuměl, nebo mohl na ně reagovat, je nutné dekódování akční informace do tvaru čitelného řízeným subjektem. V tomto smyslu se technické regulační systémy v podstatě neliší od IS v ekonomickém smyslu. 1.1.2 INFORMAČNÍ A KOMUNIKAČNÍ TECHNOLOGIE DEFINICE Informační a komunikační technologie (dále jen ICT) chápeme jako množinu prostředků a metod sloužících k práci s daty a informacemi. Podle této definice je tedy pojem ICT značně široký. Zahrnuje nejen techniky a technologie pořizování a zpracování dat, ale také prostředky jejich přenosu, ukládání, využívání a následného vyhodnocování. Pronikání informačních technologií do veškerých činností společnosti znamená její vývoj do stavu, kterou řada autorů nazývá existencí informační společnosti. U informačních technologií rozeznáváme složky technickou, programovou /implementační/ a informační. Model technické infrastruktury jsme znázornili na Obrázek 2. ICT a jejich složky TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 14 Obrázek 2 Blokové schéma technické infrastruktury Zdroj: upraveno dle Moose (1993) Cílem projektování informačních systémů může být příprava a provedení změn ve všech částech této infrastruktury nebo jejich částech. Obecně lze říci, že problematickými body jsou také obě části přenosu informací, kde dochází k informačním šumům, které mohou vyvolat snížení kvality přenášené informace. Na vstupu to mohou být různá zkreslení zaváděných informací, na výstupu zase špatně komunikovaná nebo chápaná rozhodnutí. Model informační infrastruktury lze nejlépe charakterizovat hierarchickým modelem druhů IS. Na nejnižší úrovni zpracování fungují operativní transakční systémy řízení základních agend a operací. Informace z této úrovně se transformují a komprimují do podkladů pro taktické rozhodování, které například v obchodních firmách probíhá zejména v oblasti cenové tvorby, marketingu a podobných rozhodovacích procesů. Na nejvyšší úrovni probíhají strategická rozhodování (EIS), která vyžadují podporu datových skladů, systémů pro podporu rozhodování (DSS), ad hoc analýz a dalších postupů, které se v poslední době označují souhrnně jako Business Inteligence. Na programové úrovni dochází v poslední době k úvahám a prvním krokům v realizaci modulů Servisně orientované architektury (SOA). Tento přístup si zřejmě vyžádá razantní změny v oblasti programování. Tato oblast však není předmětem naší práce. Bude jen krátce analyzována, zejména v souvislosti s hodnotově orientovanými modely s využitím metodologie Resources Events Agents (REA). 1.1.3 TYPY ÚLOH ZPRACOVÁVANÝCH V INFORMAČNÍCH SYSTÉMECH Podle typů úloh se také řídí přístupy k projektování IS. Domníváme se, že k nejdůležitějším patří tyto hlediska:  časové osy;  úrovně podpory procesů; Hierarchický model IS Typy úloh IS Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 15  struktury rozhodovacích úloh. Podle časové osy rozlišujeme v podstatě jednotlivé fáze zpracování informace a jejich agregace v čase (pořízení dat, zpracování dat, analýza dle úrovně řízení, archivace). Hledisko struktury rozhodovacích úloh je svázáno s úrovní rozhodování. Na úrovni řízení technologických procesů je valná většina řídících úloh dostatečně popsána v potřebné struktuře. Také na úrovni řízení operací podniku jako je objednávání, fakturování, práce ve skladech apod. je možno hovořit o dostatečně strukturovaných procesech. Na druhé straně však u schvalování investic, zavádění nového výrobku, sociálního plánování, řady otázek z personalistiky, které patří do vyšších, tedy manažerských a strategických úrovní řízení, je strukturovanost řídících úloh značně nízká. Souhrnnou charakteristiku vztahů mezi úrovní řízení, typy rozhodovacích úloh a potřebnou podporou ze strany ICT uvádí Obrázek 4. Podle toho jak klesá strukturovanost úloh řízení a roste úroveň řízení, se informatické úlohy mění od podpory transakčních procesů až k expertním systémům strategického cha- rakteru. KONTROLNÍ OTÁZKA Mezi jaké typy strukturovaných úloh byste zařadili např. rozhodnutí o nákupu nového notebooku nebo výměnu kola u automobilu? Projektování IS podporujících strukturované (transakční a technologické) procesy je v dnešní době v zásadě zvládnuto. Projektování těch částí IS, které podporují střednědobé a strategické rozhodování (manažerské IS a jiné) je zpravidla spojeno s nasazením expertních systémů, datových skladů a heuristických modelů. Zavádění těchto technologií známými metodami projektového řízení v praxi zatím naráží na metodické i technické pro- blémy. 1.2 Úloha ICT v podnikovém řízení 1.2.1 ÚLOHA ICT V SYSTÉMECH ŘÍZENÍ ICT hrají významnou úlohu v systémech řízení. Spočívá zejména v tom, že v rámci podnikových procesů se ICT chápou obdobně jako ostatní obchodní, výrobní a jiné procesy. ICT tedy podléhají i obecným zásadám řízení. (Obrázek 3) Struktura úloh TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 16 Obrázek 3 Hierarchické úrovně v informačních systémech Zdroj: vlastní zpracování Existují pro to závažné důvody:  Nasazení ICT je třeba dlouhodobě a strategicky plánovat s tím, že musí být v souladu s celkovou strategií podniku.  Nasazení, přizpůsobování a změny použití ICT se váže na vnitropodnikovou politiku. V řadě případů u složitých organizací jsou příslušná rozhodnutí spojena se složitými organizačními změnami popřípadě i nadnárodními rozhodnutími koncernových centrál.  Nasazení ICT rovněž ovlivňuje organizaci podniku a využívání lidských zdrojů.  Nasazení ICT je vždy tak komplexní, že musí být dlouhodobě plánováno jak organizačně tak investičně, s přihlédnutím k potřebě příslušných podnikových zdrojů. Nejznámější zdůvodnění říká, že ICT jsou zdrojem racionalizačních efektů, zejména v oblasti zefektivnění administrativních činností. Ukazuje se, že tento pojem byl překotným vývojem z posledních let překonán. Důvodem pro nasazení ICT nebo pro změnu stávající technologie je stále více její přímé začlenění do tvorby hodnot podniku, jeho postavení na trhu, souhrnně řečeno otázkou jeho dalšího rozvoje nebo přežití. K tomuto tématu se ještě vrátíme. Přitom začlenění ICT do struktury základních podnikových činností může mít různý význam podle toho, o kterou část organizace se jedná. Například při rozvoji firemní strategie týkající se obchodních procesů má význam právě „přidaná hodnota", které mohou ICT generovat. Na druhé straně řízení lidských zdrojů nebo optimalizace využití základních prostředků nemívá příliš vliv na to, jak je podnik úspěšný v okolním světě. Zde půjde spíše o to, jak ICT přispívá k efektivnosti a tedy i ziskovosti organizace. Samostatnou kapitolou Zásady řízení ICT Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 17 je řízení provozů, případně provozních a technologických agregátů, kde se ICT již staly nedílnou součástí provozního řízení a význam těchto technologií se stále více posouvá do oblasti expertních systémů pro optimalizaci a plánování, logistiky a kvality. I v tomto smysle se tedy úlohy řízení agregátů a procesů přímo podílejí na tvorbě přidaných hodnot a tedy mají svoji vlastní hodnotu. ÚKOL K ZAMYŠLENÍ Co chápete obecně pod pojmem přidaná hodnota? Právě propojení „tvrdých (čistých, explicitních, kvantitativních)" s „měkkými" ukazateli hodnocení procesů, jako je pružnost, využití pracovní síly, celková efektivnost všech investic a jiných však vytváří problém při hodnocení významu ICT jako celku a stanovení její hodnoty pro podnik. Obrázek 4 Podpora řízení informatickými úlohami Zdroj: vlastní zpracování 1.2.2 HODNOTA ICT PRO PODNIK Na téma hodnoty ICT lze vysledovat celou řadu často i kontroverzních diskuzí. Postupný vývoj ukázal, že ICT napomáhají tvorbě hodnot tam, kde umožňují podporu podnikových procesů a to tak, že dochází k ziskům v technologických a obchodních částech podniku. Obecně lze na hodnotu ICT pro podnik pohlížet z hlediska analytického nebo pragmatického. Obecně analytický náhled lze vyjádřit například produkční funkcí. Ukazatele výkonu Produkční funkce TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 18 1.2.3 HODNOCENÍ ICT POMOCÍ PRODUKČNÍ FUNKCE Produkční funkci jako vztah mezi výstupem a vstupy podniku lze obecné formě vyjádřit vztahem (1): 𝑌 = 𝑓(𝐹, 𝑃) (1) kde F – základní fondy; P – živá práce; f je spojitá funkce. Často se používá dvoufaktorová produkční funkce Cobb-Douglasova1 , která pracuje s koeficienty pružnosti vzhledem k základním fondům a živé práci (2): 𝑌 = 𝑎𝐹 𝛼 ∗ 𝑃 𝛽 , 𝑎 > 0 (2) kde α, β - koeficienty pružnosti výroby; a – parametr, který obecně zohledňuje úroveň technologie, organizace, know-how, atd. Použití produkční funkce pro účely hodnocení přínosnosti hodnoty ICT pro podnik uvádí například Moos (1993). Pokud a obsahuje určitý vztah k hodnotě pragmatické informace Ip, lze tento vztah reprezentovat vzorcem (3): 𝑎 = 𝑒 𝐼 𝑝 (3) Obdobnou závislost definoval Timbergen. Veselý (2005) ukázal, že produkční funkce může sloužit jako nástroj ekonomické analýzy firem. Z těchto úvah vyplývá, že formální analytické hodnocení přínosu ICT pro výstup z podniku lze provést. Uvedený přístup však v případě použití rovnice (3) skrývá určité úskalí. Tento vzorec totiž neobsahuje žádnou vazbu na základní fondy a živou práci. Právě použitím informačních technologií musí docházet ke změnám ve struktuře základních fondů, živé práce nebo obojího, pokud mají informační technologie mít pozitivní smysl. Dalším nedostatkem této metody je potřeba použití dlouhodobých agregovaných časových řad. Její použití pro konkrétní podnik má tedy jen omezenou vypovídací schopnost. V praxi proto převažují pragmatická hodnocení ICT založená na snížení nákladů, zlepšení organizace práce, zvýšení pružnosti podniku na trhu atd. 1.2.4 PRAGMATICKÝ PŘÍSTUP K HODNOCENÍ ICT Jaká je skutečná hodnota ICT pro podnik vyjádřená v praktických údajích? Pro investice do této oblasti se stále ještě v rozhodující míře uvažuje s dostatečnou návratností. Silvius 1 VESELÝ, Jaroslav. ITS v podmínkách dopravně-telekomunikačního prostředí ČR (802/210/108) příloha č.9. Produkční funkce - nástroj analýzy přínosů ITS systémů [online]. 32 stran [cit. 2017-09-28]. Dostupné z: http://www.lt.fd.cvut.cz/its/rok_2003/dokumenty/priloha9_its2003.pdf Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 19 (2006) uvádí výsledky jednoho výzkumu z roku 2002, kdy více než 86% finančních manažerů odpovědělo, že používá klasické metody hodnocení kapitálu, jako je návratnost, doba návratnosti, diskontovaný cash flow a vnitřní dobu návratnosti. Naproti tomu vedoucí útvarů ICT (dále jen CIO) se orientovali na dodržení projektových nákladů, případně ukazatelů efektivnosti a snížení celkových nákladů svých oddělení. Z naší zkušenosti vyplývá, že ve velké řadě případů hodnotí podnikový management oddělení ICT právě podle nákladů (v případě outsourcingu včetně nákladů outsourcingu). Ukazateli kapitálové efektivnosti ICT se finanční management zabývá pouze v rámci jednotlivých projektů. Tento rozdíl mezi pohledem finančních manažerů a CIO je jedním ze zdrojů trvalých, často negativně laděných debat. Již jsme již zmínili, role ICT se v posledních letech radikálně změnila. Musí tedy i hodnota ICT pro podnik vycházet z jejího vlivu na celkové procesy v něm. Často se v této souvislosti zmiňuje hledisko úplných nákladů po dobu životnosti (Total Cost of Ownership – TCO). Samotné TCO, případně návratnost určitého projektu čistě z hlediska ICT hodnotu nemá. Hodnotu má však snížení TCO nebo zvýšení návratnosti investice do tohoto projektu. Toho dosáhneme v prvé řadě efektivním řízením projektu. Uplatnění výsledku daného projektu však může vést k podpoře dosažení požadované ceny zavedené technologie, uplatnění nového výrobku nebo služby, jejich prosazení na trhu, případně umožnění jeho efektivního marketingu. Pak je možno daný ICT projekt považovat za přínos pro tvorbu hodnot v daném podniku a přisoudit tomuto projektu nebo oddělení ICT roli tvůrce hodnot. Obdobně lze hodnotit dosažení pružnosti podniku díky informačním tech- nologiím. Zajímavou metodu ocenění hodnoty ICT vyvinula společnost Gartner (2008). Tato metoda nazvaná Total Value of Opportunity (TVO) si klade za cíl určit očekávané přínosy získané zavedením ICT. Cílem je přesvědčit rozhodující osoby (primary stakeholders) o finančních přínosech a návratnosti při užití jazyka a metrik rozhodujících uživatelů. Navrhuje se srovnání hlavních ukazatelů finančních a ukazatelů výkonnosti obchodních procesů dosažených využitím ICT s úplnými náklady na životní cyklus dané technologie. Zajímavé je, že se zde odhadují možné přínosy v budoucnosti a to metodou reálných opcí. Zatím jsme zmínili úvahy týkající se finančního hodnocení role ICT v podniku. Existuje však i významná role politická, kterou musí trvale vykonávat CIO. Jakékoli finanční ukazatele nenahradí při hodnocení ICT správně fungujícího CIO. Ten má zejména za úkol porozumět strategii, koncepci a procesům svého podniku a na tomto základě stanovit správnost strategie a koncepce ICT. Tuto strategii a koncepci musí definovat jazykem, kterému management rozumí, rozhodující část managementu pro ni získat a získat i rozhodující uživatele. Znamená to tedy, že „objektivní" hodnota ICT v daném podniku nemusí být totožná s hodnotou pragmatickou či subjektivní. Platí-li tento závěr pro ICT jako takovou, platí tím spíše i pro jednotlivé projekty v této oblasti. TCO TVO TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 20 1.2.5 DŮVODY PRO INFORMAČNÍ PROJEKTY Víme, že výrobky podléhají určitému životnímu cyklu. Proto můžeme chápat IS nebo jeho část také jako určitý výrobek podléhající životnímu cyklu. Výrobek postupně prochází fázemi zavedení, růstu, zralosti a poklesu. Podniky, které správně reagují na průběh tohoto cyklu, přizpůsobují své strategické a taktické cíle tomuto vývoji. Všeobecně uznávaným grafickým vyjádřením těchto cyklů jsou tak zvané S-křivky. Prodloužení životního cyklu výrobku se podnik snaží dosahovat investicemi do inovací a kvality, zvýšením orientace na zákazníka a zejména zaváděním služeb. Služby mohou s výrobkem nebo jejich skupinou přímo souviset, (na příklad nové typy servisních smluv ke strojům a zařízení) nebo zcela nezávisle vznikat. Typickou službou, která prodělává rychlý kvantitativní a kvalitativní rozvoj v oblasti ICT, je outsourcing, případně hostování serverů a procesů. Právě rozvoj služeb v poslední době vyvolal trend zavádění SOA. Nutnost zavedení SOA s cílem zvýšit pružnost na trhu bude zřejmě jedním z hlavních důvodů nových informačních projektů. Keřkovský a Drdla (2003) uvádějí vztah mezi životním cyklem výrobku a změnami priority cílů v oblasti ICT. V Tabulka 1 je znázorněn příklad životního cyklu výrobku a z něho vyplývající impulsy pro informační projekty. V etapě zavedení výrobku a také v období saturace trhu, firma zpravidla silně zvažuje podpůrné nebo zcela nové marketingové strategie. Znamená to tedy, že vzniká potřeba zásahu do IS s cílem zajistit informační podporu marketingových akcí (mailingy, analýzy, cenové propočty atd.). V období kdy se produkt stal v podstatě zralým a také při saturaci trhu, v níž silně působí konkurence, bude podnik zřejmě používat strategii snižování nákladů. Informační podpora tedy bude zaměřena zejména na dosažení cílů v této oblasti. S tím také bude souviset orientace IS na využívání kapacit. Naopak při zavádění výrobku se bude jednat o informační podporu pro rozšiřování výrobních kapacit. V praxi se ještě často stává, že informační projekt je vyvolán na základě určitých ambicí oddělení ICT. ICT specialisté jsou často technokrati žádající špičkové technologie bez ohledu na náklady nebo jejich užitek. Většinou se to týká nákupů hardware nebo systémového software. Pak se může stát, že se definice projektu dostane do rozporu s celkovou firemní politikou a reprodukovat přetrvávající pohled na ICT jako nákladovou složku podniku. Návaznost informačního projektu na celkovou firemní strategii a potřeby vyplývající z cyklu životnosti výrobku nebo služby je nutno považovat za zásadní předpoklad jeho úspěchu. Je tedy již na začátku nutné jasně stanovit, co projekt vyvolalo a jak hlavní myšlenka projektu souvisí se základními otázkami, které před podnikem stojí. S-křivky Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 21 1.3 Důležitá rozhodnutí na začátku projektu IS Již na samotném začátku projektu týkajícího se ICT je učinit některá zásadní rozhodnutí. I když z pohledu firmy může jít o rozhodování na taktické úrovni, v řadě případů jde o závěry mající pro podnik strategický význam, který se projeví v dlouhodobém horizontu. Některá rozhodnutí mohou mít značný vliv na celkové náklady projektu. Velmi často se tato rozhodnutí provádějí v koncernových organizacích, po sloučení dvou nebo více firem do jedné organizace, při nutnosti provést firemní restrukturalizaci apod. Tabulka 1 Důvody informačních projektů z hlediska životního cyklu projektu Zdroj: upraveno dle Keřkovského a Drdly Bez ohledu na to o jaký projekt se jedná co do rozsahu nebo obsahu, existují některé principy, ze kterých je při rozhodování o projektu nutno vycházet. Projekt by se měl řídit zejména těmito zásadami:  Zodpovědnost za projekt má vedení podniku a tento fakt dává neustále najevo.  Projekt vychází ze střednědobých nebo dlouhodobých záměrů podniku a orientuje se na jasně stanovené cíle, které jsou formulovány pokud možno současně s rozhodnutím o projektu.  Do návrhu systému jsou zapojeni budoucí uživatelé, zejména tvůrci podnikového veřejného mínění; jejich účast a odpovědnost je závazně a formálně definována.  Návrh systému vychází z detailní analýzy a modelování budoucího řešení na úrovni konceptuální. Oddělení konceptuálního řešení od technologie a zavedení systému pomáhá udržet konzistenci systému.  Analýza i návrh nového řešení probíhají v určitých cyklech (iteracích), popřípadě se již na začátku rozhodne o využití agilních metodik pro implementaci řešení. Zásady projektů TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 22 Kromě obecných rozhodnutí týkajících se metodiky zavedení nového IS je nutno rozhodnout nebo zvážit následující otázky:  Jedná se o rozhodnutí na úrovni podniku, nebo jde o rozhodnutí vynucené například silnějším partnerem, případně rozhodnutím ve vedení koncernu.  Dojde po realizaci k centralizaci zdrojů IS a jejich údržby, jaká bude organizace změn zavedeného řešení, jak bude probíhat další rozvoj systému.  Provede se zavedení na základě struktury procesů a programů přizpůsobené podniku, nebo půjde o centrálně nasazované řešení typu Rol in Out.  Je nebo není uvažováno s úplným nebo částečným outsourcingem.  Přizpůsobí se organizace podniku zavedenému a ověřenému řešení (u programových balíků), nebo se software bude přizpůsobovat stávajícím procesům.  Dojde současně se zavedením IS k zásadní změně podnikových procesů.  Jaká bude míra zapojení interních podnikových zdrojů do projektu.  Jak bude zajištěno zaškolení budoucích uživatelů, jaké bude zapojení interních zdrojů do tohoto školení.  Jaké priority dává vedení podniku projektu: prioritní je termín, prioritní je kvalita projektu bez ohledu na termín a náklady nebo jsou prioritní celkové náklady na projekt a termíny a kvalita se této prioritě musí přizpůsobit. 1.4 Modelování procesů Modelování obecně zaujímá v oblasti řízení důležitou úlohu. Mezi hlavní cíle spojené s modelováním lze zařadit hlavně:  optimalizaci podnikových procesů;  podporu při návrhu IS;  zkoumání a přípravu integrace obchodních, logistických, ekonomických a jiných procesů pomocí dílčích aplikací v IS;  analýzu dopadu rozhodnutí na podnikové výsledky, přezkoumání reálnosti stanovené strategie;  oddělení znalostí klíčových uživatelů od jejich konkrétních nositelů (obrana proti monopolizaci znalostí);  v neposlední míře i vytvoření zázemí pro školení nových pracovníků, nebo uživatelů změněného IS. DEFINICE Pod pojmem model se zpravidla rozumí zjednodušené zobrazení nějakého objektu (nebo jevu či děje), ať skutečného nebo zamýšleného. Modelem bývají obvykle zobrazeny jen určité vlastnosti, které nás v konkrétním případě zkoumání zajímají, zatímco od zobrazení Modelo- vání Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 23 ostatních vlastností se upouští, a to buď úmyslně, nebo proto, že některé vlastnosti zobrazovaného objektu neznáme. Výstupy z modelování zpravidla používají různé úrovně řídicích pracovníků. Týkají se však i dalších zaměstnanců, zejména těch, kteří působí v rolích analytiků nebo integrátorů jednotlivých podnikových procesů. Pokud modelování doplníme i přípravou kvantitativních výstupů získaných pomocí modelování, dojdeme k simulaci procesů. Simulace procesů je vhodné použít zejména při analýzách dopadů přijatých rozhodnutí a to i v reálně provozovaném IS. Pro informační systém představuje model výsledek analýzy dané problémové oblasti a syntézy získaných poznatků do celku, specifikujícího požadavky na funkce a informace, obecně na informační podporu činností v podniku. Proto je tématika modelování úzce spjata s problematikou vlastního projektování IS. Modelování lze pokládat za součást procesního řízení v podniku, protože procesní řízení svým obsahem představuje použití v praxi prověřených postupů ke zkvalitňování podnikových činnosti. V tomto smyslu procesní řízení využívá zejména:  snahu o optimalizaci podnikových činností;  kritické zhodnocení a zavedení nejlepších používaných praktik v oboru;  modelování a optimalizaci podnikových procesů;  učení se ze zkušenosti na realizovaných projektech. PRŮVODCE TEXTEM Modelování je v teorii i praxi zpravidla spojováno s použitím procesních modelů. Dále ukážeme, že lze použít i jiné přístupy, zejména modelování s využitím obchodních vzorů a hodnotových řetězců a výsledky tohoto přístupu s modelováním z hlediska procesů pro- pojit. Modelování a optimalizace procesů v podniku má dlouhý vývoj. Jedním z prvních impulzů byla Davenportova (1992, 2008) definice reengineeringu zdůrazňující zajištění inovativního chování podniku. Hammer a Champy (2000) kladli důraz na potřeby zákazníka a podtrhovali roli informačních technologií. Klasické původní metody reengineeringu, které věnovaly malou pozornost ideám a potřebám pracovníků, byly postupně nahrazeny metodami, které tato hlediska více zohledňovaly. Více se také začaly prosazovat metody modelování procesů vycházejících z cílů podniku. Modelování a si- mulace Procesní řízení Modelování a opti- malizace procesů TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 24 PRO ZÁJEMCE Reengineering (reinženýring nebo re-inženýring) je radikální přetvoření organizačních procesů v podniku, především procesů obchodních. Jde o postup, který optimalizuje podnikové procesy tak, aby přinášely maximální efekty při optimální spotřebě podnikových zdrojů. Modelování podnikových procesů vychází z těchto principů:  Předmětem (objektem) zkoumání jsou procesy, probíhající v podniku (hmotně-energetické, informační, řídící).  Výsledkem je model (zobrazení) procesu v různých stádiích jeho existence (model současného nebo minulého stavu procesu — deskriptivní model; model projektovaného stavu procesu — normativní model). Modelováním pro účely procesního řízení se u nás kromě jiných autorů podrobně zabývá Řepa, například (2006). Ve zmíněné publikaci analyzoval celou řadu používaných metodologií včetně metodiky MMABP dlouhodobě rozpracovávané na VŠE. Základními prvky modelování podnikových procesů podle Řepy jsou:  Proces. Proces je modelován jako struktura vzájemně navazujících činností. Platí, že podle sémantické relativity může být obecně každá činnost samostatně popsána jako proces.  Činnost. Činnosti procesu jsou řazeny do vzájemných návazností. Tyto návaznosti činí z množiny činností, tvořících proces, definovanou strukturu. Návaznosti činností jsou popsány pomocí vazeb.  Jednotlivé činnosti zpravidla neprobíhají náhodně či živelně, ale na základě definovaných podnětů či důvodů. Obecně může být podnětem vnější či vnitřní důvod. PRO ZÁJEMCE Metodika MMABP slouží k analýze procesů daného podniku a k vytvoření jejich komplexního modelu. Tato analýza a vytvořený model slouží k utvoření lepší představy o stavu procesů v podniku a umožňuje tak následně provést jejich optimalizaci (a to jak formou radikálního reengineeringu, tak i pomocí drobných změn a vylepšení). Dále může posloužit i jako podklad při tvorbě informačního systému, který bude tyto procesy podporovat, a obecně pomůže zlepšit procesní řízení v podniku (Business Process Management – BPM). Metodika respektuje základní cíle, stav a charakteristiky organizace a předpokládá, že všechny činnosti prováděné v organizaci slouží výhradně cílům organizace. Reengine- ering Modelování pod- nikových procesů Prvky mo- delování Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 25 Aby byla tato metodika v praxi použitelná, musí být doplněna nástroji umožňujícími modelování nástrojů ve shodě s jejími principy. Lze použít nástroje, obecně vycházející z notace BPMN (Business Process Model and Notation). Postup procesní analýzy dle této metodiky následně probíhá ve třech hlavních fázích:  Analýza elementárních procesů – zjištění základních procesů, jejich struktury a vazeb, za pomocí analýzy událostí a reakcí a jejich vzájemných souvislostí.  Specifikace klíčových procesů – zjištění klíčových procesů, jejich struktury a vazeb a jejich podstatných atributů, na základě výsledků předchozí fáze a za pomoci objektové analýzy produktů  Specifikace podpůrných procesů – zjištění podpůrných procesů, jejich struktury a vazeb a podstatných atributů, na základě výsledků předchozích fází a pomocí objektové analýzy organizace. BPM je manažérská disciplína, která pomáhá podnikům a organizacím standardizovat a neustále optimalizovat provozní procesy, které mají největší vliv na dosáhnutí firemních cílů. Business Process Model and Notation (BPMN) je notací pro modelování podnikových procesů, která poskytuje grafické znázornění pro specifikaci podnikových procesů z procesního diagramu (BPD). Procesní diagram je založen na flowchart technologii, která je velmi podobná diagramu aktivit z Unified Modeling Language (UML). V praxi je tedy diagram tvořen jakýmsi tokem aktivit, které se dějí za určitých okolností a v určitém pořadí. V tomto toku mohou také být velmi stručně, avšak přehledně, zaneseny i různé vnější okolnosti, které nemusí být součástí daných podnikových procesů, ale přesto modelované podnikové procesy přímo ovlivňují. Oproti již zmíněnému diagramu aktivit z UML pak BPMN přináší o něco lepší a přehlednější záznam právě takových vnějších aktivit, které mají přímý vliv na podnikové procesy, včetně časové dimenze. Účelem BPMN je podpora procesního řízení, čehož mohou využít jak analytici, vývojáři tak vlastníci podnikových procesů. BPMN poskytuje notaci, která je jednoduchá a intuitivní pro vlastníky procesu, ale zároveň je schopna vyjádřit komplexitu daných procesů. BPMN od verze 2 podporuje automatizaci procesů, tzv. workflow management, za tím účelem bylo do jazyka implementována řada "programátorských" rozšíření, např. subprocesy pro ošetřování výjimek nebo rozlišování typů cyklů a paralelního zpracování, které pomohly zpřesnit zápis. Důraz na přesnost a výstižnost jazyka ale snížil jeho srozumitelnost pro neškolené čtenáře (typicky business vlastníky procesů). Primárním cílem BPMN je poskytovat standardizovaný zápis ve snadno srozumitelné podobě pro všechny zainteresované osoby v organizaci. Mezi tyto zainteresované osoby patří podnikoví analytici, kteří vytvářejí a zdokonalují podnikové procesy, dále techničtí vývojáři zodpovědní za jejich implementaci a podnikoví manažeři, kteří je monitorují BPM BPMN TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 26 a řídí. BPMN tedy slouží jako společný jazyk, který překonává komunikační propast mezi návrhy podnikových procesů a následnou implementací. BPMN je nerozšířenějším jazykem používaným pro popis procesů. I když existuje více standardů pro modelování podnikových procesů, BPMN se stal de facto standardem, na který postupně přecházejí modelovací nástroje i aplikace podporující automatizaci procesů (exekuční stroje). Ze závěrů v uvedené publikaci vyplývají možnosti těchto metodologií pro zlepšování procesního řízení. Vzhledem ke komplexnosti celé problematiky však existuje v celé oblasti i v současné době ještě řada bílých míst. Sada metod IDEFxx (2008) vyvinutá pro potřeby ministerstva obrany USA se zabývá modelováním aktivit, rozhodovacích procesů a funkcí v podniku. (Integrated Definition for Function Modeling) Činnosti jsou ve vztahu svými vstupy, výstupy, kontrolními signály a mechanismy. (Obrázek 5) Obrázek 5 Princip metody IDEF0 Zdroj: https://www.researchgate.net/profile/Robby_Soetanto/publication/280194066/fi- gure/fig2/AS:284124544815114@1444751978265/Figure-2-IDEF0-Parent-Diagram-top- level.png IDEFxx Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 27 Činnosti IDEF0 mohou být dále rozkládány do modelů s podrobnějším rozlišením. IDEF0 však není určen k použití pro modelování sledu činností, ani k pochopení to ho, jak činnosti přidávají hodnotu ekonomickým zdrojům. Objekty IDEF0 jsou lidé, stroje nebo systémy, které zajišťují transformaci vstupů na výstupy. Hlavní výhodou IDEF0, kterou lze použít jako obecnou techniku modelování, je, že slouží jako nástroj pro komunikaci mezi uživateli, odborníky a projektanty a je vhodná pro pochopení podnikových procesů. Z ekonomického hlediska však model IDEF0 nedokáže odpovědět na otázku, jakým způsobem činnosti přispívají ke zvýšení hodnoty zdrojů podniku. V důsledku toho model neobsahuje odpověď' na otázku, proč těmto činnostem dochází. V řadě případů se pro popis podnikových procesů doporučují rozšíření univerzální notace UML pro podporu jejich modelování. Vyústění získaného modelu do definice rozhraní informační podpory uživatelů dává možnost jeho dalšího použití vzhledem k lidským zdrojům i technické a programové infrastruktuře. Otázkou zůstává, jak propojit poměrně přesné popisy podnikových procesů s přidanou hodnotou z jejich změny nebo optimalizace, případně se zvýšením pružnosti rozhodování. Všude tam, kde se uvažovalo nebo uvažuje se zavedením různých variant systémů SAP, se často používá systém ARIS prof. Scheera, viz například ARIS (2008). Podle našeho názoru je tento nástroj poměrně rozsáhlý a jeho zvládnutí není jednoduché a je tedy finančně náročné. To je jedním z důvodů, proč se používá především ve velkých, zejména nadnárodních firmách. Interakce procesů s okolím podniku jsou cílem definic na základě dalších modelů na příklad Business Process Modelling Language, který lze definovat jako doplněk prostředků pro grafický popis procesů ve firmě (BPM, 2008). Obdobnou problematikou se snaží řešit standardy ebXML (Dlouhý et al., 2007), které však pravděpodobně mají před sebou ještě dlouhý vývoj, než je bude možno uplatnit v každodenní praxi, zejména u segmentu malých a středních firem (Small and Medium-sized Enterprises – SME). Mezi další metody pro modelování podnikových procesů patří metoda ISAC (Information System Work and Analysis of Change), či DEMO (Dynamic Essential Modeling of Organizations) a jiné. Blíže např. Řepa (2006), Barjis (2007), Dietz (2009). V souvislosti s vývojem v oblasti objektového programování se jeho základní koncepty postupně přenášejí i do oblasti modelování procesů v podniku. Žid (2008) v této souvislosti připomíná, že procesní pohled na podnikové činnosti by měl být doplňován pohledem objektovým, který popisuje chování objektů v informačním systému, aniž by bral do úvahy nadřazené důvody pro toto chování (procesní pohled — účel, cíl, vnější podnět). Samotné modelování procesů ve firmě ještě nedává úplný obraz o vazbách na řízení rizik a zajišťování flexibility rozhodování. Proto je vhodné spojit tyto metody s metodami hodnocení rizik. Zde se jako potenciálně přínosné jeví propojení modelování procesů s hodnocením jejich přínosů. Za vhodné spojení modelu procesů s měřením výkonnosti podniku považujeme model firemních procesů v různých hierarchiích s využitím metody IDEF0 UML ARIS TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 28 Balanced Scorecard. Ucelený soubor uvedených nástrojů je prezentován na příklad firmou QPR2 . Přístupy k architektuře informačních systémů vyvíjely zejména ve směru podpory pružnosti podnikových procesů. Od původně používaných strukturovaných technologií přes objektově orientované přístupy vývoj dospěl až k současné tendenci projektovat a zavádět informační systémy typu servisně orientované architektury. Podstatou SOA je využití funkčních modulů, které byly identifikovány jako vícenásobně použitelné pro různé podnikové funkce. Praktické nasazení SOA v oblasti zejména v SME firmách naráží nejen na finanční možnosti podniků, ale také na jejich odhadovaný přínos. Její prosazení bude zřejmě ještě nějakou dobu trvat, je však nutné ji vzít do úvahy při plánování podnikové strategie ICT. PRO ZÁJEMCE UML, Unified Modeling Language je v softwarovém inženýrství grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů. UML nabízí standardní způsob zápisu jak návrhů systému včetně konceptuálních prvků jako jsou business procesy a systémové funkce, tak konkrétních prvků jako jsou příkazy programovacího jazyka, databázová schémata a znovupoužitelné programové komponenty. UML podporuje objektově orientovaný přístup k analýze, návrhu a popisu programových systémů. UML neobsahuje způsob, jak se má používat, ani neobsahuje metodiku/y, jak analyzovat, specifikovat či navrhovat programové systémy. Standard UML definuje standardizační skupina Object Management Group (OMG). Metodiku ARIS lze chápat jako jednu z metod reengineeringu procesů, která klade důraz na podporu řízení procesů pomocí IT systému. Název ARIS je vytvořen jako zkratka z celého názvu Architecture of Integrated Information Systems, česky pak Architektura integrovaných informačních systémů. Metodu vytvořila společnost IDS Scheer, která se již přes 20 let věnuje problematice optimalizace a modelování podnikových procesů. Metodika ARIS nemá za cíl vytvoření přesného postupu, jak přistupovat k reengineeringu procesů, spíše se snaží poskytovat řadu různých pohledů, pomocí níž lze modelovat jednotlivé situace. ARIS se zabývá jak samotným modelováním procesů, tak i následným zpracováním IT systémů pomáhajících k řízení podniku. Skládá se z různých dílčích nástrojů jako ARIS Easy Design, ARIS Toolset, ARIS ABC, ARIS Simulation a další. Pro samotné modelování a znázornění jednotlivých procesů, tedy jednotlivé modely v této práci, postačí ARIS Easy Design. Pro důkladnější analýzy spojené s reengineeringem procesů slouží zejména ARIS Toolset ve spojení s dalšími zmíněnými nástroji. ARIS vychází z důkladné analýzy podnikových procesů, které jsou modelovány pomocí různých pohledů. Výsledkem může být značně obtížný a nepřehledný model, který se díky rozdělení do jednotlivých 2 QPR. Gain the insight for informed decisions that make a difference [online]. [cit. 2017-09-28]. Dostupné z: https://www.qpr.com/ UML ARIS Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 29 pohledů stává mnohem srozumitelnějším a přehlednějším. Jednotlivé pohledy se dají popsat pomoci speciálních metod, které se hodí na konkrétní pohled a modelovanou situaci. Nemusí se tak příliš přihlížet k provázanosti s dalšími pohledy. Na závěr se jednotlivé pohledy a vztahy mezi nimi propojí, čímž se vytvoří komplexní pohled. ISAC (Information System Work and Analysis of Change) je metoda, zaměřená na vývoj informačního systému, zejména v jeho počátečních fázích. Hlavním předmětem zájmu této metody je totiž především reálný systém, jenž má být modelem známý jako business a dbát na jeho důkladné poznání ještě předtím, než bude zahájena práce. ISAC se řadí mezi metody tzv. „problémově orientované". Jejím základem je hledání příčin problémů, které pociťují uživatelé. Postupuje od analýzy problémů uživatelů a hledání možných a vhodných řešení těchto problémů. Odtud plyne i vhodnost použití metody ISAC v počátečních fázích životního cyklu IS. Jedním z principů je, že se nepředpokládá, že vývoj IS musí být jediným možným řešením nalezených problémů. Potřeba vývoje, resp. inovace IS se doporučuje pouze tehdy, jestliže IS bude mít vliv na zlepšení práce lidi. Prostý přínos pro organizaci není ještě důvodem k potřebě budování IS. Informační systém má hodnotu pouze tehdy, má-li hodnotu pro lidi, kterým slouží. ISAC se tak řadí k tzv. přístupům orientovaným na člověka (people-oriented) a které se jsou nazývány jako socio-technický přístup. Metoda BORM byla vyvíjena jako součást grantového projektu VAPPIENS Britské rady, a to postupně od roku 1993. Od počátku se zaměřuje na podporu tvorby objektově orientovaných systémů a využívá programovacích jazyků a vývojových prostředí, jako je například prostředí Smalltalku. Během práce na této metodě bylo zjištěno, že některé její techniky a nástroje je možné využít k reprezentaci znalostí a modelování business procesů. Metoda BORM se věnuje specifikaci problému v informačním systému a poskytuje podrobné metody pro transformaci těchto požadavků do zákaznického řešení. Nástroje a techniky pro modelování jsou velmi jednoduché a snadno pochopitelné a neobsahují softwarové koncepty, které jsou zapotřebí až v následujících fázích. PQM (Process Quality Management) je vyvinuta firmou IBM v návaznosti na metodu BSP a její úspěšnost si můžeme doložit tím, že už byla úspěšně aplikována v mnoha společnostech. Zaměřuje se zejména na identifikování poslání, cílů a faktorů úspěchu jako celku a podnikových procesů. Při použití této metody dosáhneme toho, že definované procesy skutečně korespondují se stanoveným posláním podniku, pomocí faktorů úspěchu je pak možno měřit jejich vliv na přispívání k naplnění podnikových cílů, a tak nalézt procesy, které jsou rozhodující pro správný chod organizace. Metoda PQM využívá při analýze směru postupu „shora dolů“ (top-down) a jejím přínosem má být zhodnocení stávajících IT aplikací a návrh na jejich případnou reorganizaci. BSC (Balanced Scorecard) Metoda byla vytvořena Robertem Kaplanem a Davidem Nortonem v roce 1992. Jedná se o systém pro měření účinnosti, kdy jsou na zřeteli důležité aspekty podnikání. Vyjadřuje základní orientaci a strategie cesty k její realizaci. Pomocí této metody demonstrovali, jak prosadit příliš pomalu se ujímající přesvědčení, že podniky jsou orientovány hlavně podle svého poslání, vize a strategie. Formulace strategických cílů však nepatři mezi jednoduchá zadání a BSC zásadní měrou přispělo ke zjednodušení této ISAC BORM PQM BSC TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 30 úlohy. Ta je definována jako sada indikátorů, které vytvářejí řídicí systém, sloužící k využití speciálních znalostí jednotlivců a k realizaci dlouhodobých cílů organizace. Původní hlediska, která se uplatnila u vzniku BSC, jsou: finanční výkonnost, znalost klienta, interní procesy a učení se a růst. Tato hlediska se v BSC využívají pro sladění individuálních a organizačních iniciativ. Kromě toho pomáhají stanovit, které procesy splňuji cíle klientů a ak- cionářů. Výsledky modelování procesů a simulace průchodnosti těchto procesů systémem slouží jako podklad pro rozhodování o další informační strategii firmy. V případě rozhodnutí o zavedení zásadní změny IS nebo o zavedení nového IS jsou tyto výsledky vstupem do Studií proveditelnosti a do fáze analýzy při projektování nového IS. Jiná situace zpravidla nastává při rozhodování o systémech řízení technologických procesů, výrobní linek, obecně tam, kde jsou ICT v podstatě realizátorem technologie. Zde neprobíhá rozhodování o projektu ICT odděleně, nýbrž je součástí rozhodnutí o projektu jako celku. Modelování procesů v této oblasti směřuje k zajištění kvality výrobku (například v hutním nebo chemickém průmyslu) nebo k zabezpečení průchodnosti výrobní linky na základě údajů o vytížení zdrojů, v systémech řízení skladů apod., viz např. Bucki (2005). Předmětem diskuzí v poslední době je také analýza vztahů mezi SOA a vlastním modelováním procesů, viz na příklad Dlouhý et al. (2007) nebo ebXML3 . Hlavním důvodem pro modelování procesů snaha změnit existující podnikové procesy nebo vytvořit procesy nové tak aby bylo dosaženo stanovených cílů. Při realizaci těchto záměrů však podniky narážejí na stávající, zpravidla značně konzervativně se chovající infrastrukturu ICT. Cílem SOA je dosáhnout požadované pružnosti reakce podniku na rychle se měnícím okolí poskytováním služeb s využitím pokud možno standardních, opakujících se modulů a to zejména na základě technologií webu. Tyto služby by měly fungovat „napříč" aplikacemi ICT a organizačními jednotkami podniku (tak zvané cross cutting concerns). Shrneme-li výše uvedené úvahy týkající se procesních modelů, můžeme dojít k následujícím závěrům:  procesní modely jsou základním nástrojem používaným v procesním řízení tam, kde jde o modelování sledu navazujících činností;  procesní modely však nevěnují pozornost hodnotovým tokům, a proto definice opakujících se činností (služeb), která je důležitá pro konceptuální modelování SOA je obtížná;  v důsledku toho mají procesní modely tendenci vytvářet architekturu „stovepipes" aplikací (cylindrů, továrních komínů). 3 EbXML Deliverables. EbXML Specs [online]. OASIS Open, 2006 [cit. 2017-09-28]. Dostupné z: http://www.ebxml.org/specs/ Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 31 PRO ZÁJEMCE Service Oriented Architecture (SOA, česky architektura orientovaná na služby) je sada principů a metodologií, která doporučuje skládat složité aplikace a jiné systémy ze skupiny na sobě nezávislých komponent poskytujících služby. V softwarovém inženýrství je založena na spolupráci nezávislých služeb. Služba je určitá část funkčnosti z informačních systémů organizace, zpřístupněná pomocí standardního rozhraní. Každý jednotlivý informační systém může poskytovat i větší množství služeb svému okolí. Službou zde myslíme něco, co poskytne přidanou hodnotu, v rámci firmy tedy jde o jasně definovanou podnikovou činnost jako například objednání zboží od dodavatele. V rámci aplikace to může být dílčí úkol, který je nutno splnit při obsluze uživatele. Jako příklad může posloužit aplikační mini modul, jenž zaokrouhluje čísla zobrazující se uživateli jako výsledek výpočtu. Při správném návrhu aplikace orientované na služby lze poté tuto komponentu odpojit a zapojit jinou, která bude zaokrouhlovat odlišně, aniž bychom nějak zasahovali do zbytku aplikace. Jednotlivé komponenty lze zpravidla různě kombinovat, doplňovat, případně nahrazovat jednu za druhou. Tímto přístupem se prvky v systému stávají samostatnými, systém je tedy stabilnější a také je zde výhodné rozložení zátěže na více komponent. Při výpadku jedné komponenty může být nahrazena jinou, funkční. Systém se pak lépe spravuje (při poruše komponenty lze jednoznačně určit, kde se vyskytla chyba), a také se pak snáze vylepšuje, jelikož je potřeba zasahovat jen do určité komponenty a ne do celého systému. Při dodržení principů SOA ve fázi návrhu lze výsledný systém přirovnat ke známé stavebnici Lego, jejíž součásti představují jednotlivé komponenty. 1.5 Využití obchodních vzorů Chceme-li důkladně porozumět podniku a zobrazit jej v jeho informačním systému, musíme identifikovat schéma, charakterizující objekty, které se obvykle opakovaně v podniku vyskytují (procesy, datové doky, události atd.) a také identifikovat schémata událostí, která zobrazují jejich typický sled. V této souvislosti se často používají pojmy schéma, vzor, v poslední době též pojem doménová ontologie. PRO ZÁJEMCE Ontologie se skládají ze čtyř základních prvků: tříd, vlastností, relací (vztahy mezi objekty) a individuí (konkrétní reálný objekt). Účelem ontologií je definovat sdílený a znovupoužitelný model, který usnadní porozumění a podpoří interoperabilitu mezi různými systémy. Často jsou také oborově zaměřené a bývají konstruovány jako pojmové hierarchie SOA Ontologie TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 32 nebo sítě. Za ontologii je ale možné považovat jakýkoli systém reprezentace znalostí, v němž jsou mezi jednotlivými objekty, nebo celými třídami objektů, definovány sémantické vztahy. Každý systém má však jinou sémantickou sílu (schopnosti struktury systému reprezentovat význam). Sémantika (též sémaziologie) je nauka o významu výrazů z různých strukturních úrovní jazyka – morfémů, slov, slovních spojení a vět, popř. i vyšších textových jednotek. Význam se často spojuje či ztotožňuje se vztahem těchto výrazů ke skutečnosti, kterou označují. Skutečností se rozumí to, co člověk poznal, tj. znalostní model té reality; o nepoznaném člověk nic neví. Slovo vzniklo z řeckého σημαντικός, sémantikos, od sémainó, označuji a séma, znak, znamení. Výraz (forma, syntaktická složka, jazykový konstrukt, řetězec symbolů) je nosná struktura, která umožňuje přenos, záznam (pamatování) a zpracování nesené informace – významu. Anglické slovo pattern znamená typ určité množiny prvků, obsahující opakující se události nebo objekty. Toto opakování probíhá tak, že je lze předpovídat. Uvedeme jednoduchý příklad vzoru. Mějme řadu znaků, např. ∑®€©∑®€©©∑…… z uvedené řady znaků můžeme odvodit její pokračování za třetím znakem ∑: ∑®€©∑®€©©∑®€©©©∑..atd. Uvedenou řadu opakujících se znaků ®€© s rostoucím počtem znaků © můžeme označit jako vzor nebo schéma. Ve většině případů se pro slovo pattern používá překlad — vzor. Podle našeho názoru je tento překlad vhodný v případě, že se jedná o návrh určitého pracovního postupu, struktury datové základny a podobně. Při analytickém pohledu na studovanou problematiku se nám zdá výhodnější použití slova schéma. V této práci budeme používat oba překlady podle kontextu popisované problematiky. Uvedli jsme, že pro další rozvoj ICT a jejich použití v rychle se měnícím světě je vhodné použít také techniku nejlepších praktik. PRŮVODCE TEXTEM Ukazuje se, že právě obchodní vzory se pro stanovení nejlepších praktik, modelování ekonomických procesů a podobně velmi dobře hodí, což ukážeme v následujících částech této práce. Sémantika Vzory Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 33 Pojem obchodní vzor se však někdy používá bez toho, že by měl pro ekonomickou realitu smysluplný obsah. Často k tomu dochází v oblasti návrhu software. Požadavky na vlastnosti obchodního vzoru prezentoval Veryard (2000). V naší úpravě je uvádíme v Tabulka 2. Tabulka 2 Požadavky na obchodní vzory Zdroj: Veryard (2000) Používání schémat a obchodních vzorů pro analýzu a návrh podnikových informačních systémů v celé jejich komplexnosti vede k systematickému a celostnímu porozumění toho jak podnik funguje. Takový konceptuální model podniku by měl být obsahovat prvky (částečné modely), které se z hlediska podnikových cílů chovají logicky a navazují na sebe. Jednotlivé prvky by měly pokrývat celou podnikovou problematiku, neměly by mezi nimi existovat rozpory a zároveň by jako celek měly zachycovat podstatné rysy podniku. Zároveň by měly abstrahovat od všech záležitostí spojených s jejich implementací. Takový model podniku nazývá např. Dietz (2009) ontologickým modelem. Problematika ontologií v modelování podniků je poměrně nová. Podle základní Gruberovy definice je ontologie formální specifikace vzájemně sdílené konceptualizace. Slovo konceptualizace zde znamená, že abstrahujeme od vlastních prvků reálného podniku obdobně jako u známého konceptuálního datového modelu. Slovo specifikace v této definici znamená, že používáme určitý formalismus, kterým konceptuální model zapisujeme. Slovo sdílená říká, že se o model budeme dělit s použitím určité komunikace s jinými osobami, které mají zájem o danou problematiku. Při tom zde můžeme mít na mysli velkou část reálného světa, nebo jeho určitou část – doménu. Účelem ontologie podnikových systémů je definice konstruktů společných všem podnikům a použití těchto konstruktů pro vyjádření integrovaného informačního systému podniku — tedy pro doménu podnikových řídicích nebo ekonomických systémů. Jedná se tedy o konceptuální model, toho, co podnik určuje v jeho základní struktuře, skrývající se za každodenními aktivitami. V této práci se nebudeme zabývat stránkami ontologií souvisejícími s umělou inteligencí, více např. Chandrasekaran et al. (1999), Gaševic et al. (2006), Gruber (2008) a jiní. Omezíme se na příklad jedné ontologie, která se TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 34 týká domény podnikových řídicích systémů a jejich zevšeobecnění pomocí analýzy používající hodnotové řetězce. 1.6 Modelování využívající hodnotové řetězce Modelování podnikových procesů na základě analýzy činností nemusí vždy vést ke zlepšení informačních toků pro řízení. Jednotlivé činnosti v podniku se totiž mohou v jeho různých odděleních opakovat, duplikovat nebo jinde mohou chybět. Jako příklad opakovaného procesu lze uvést příjem platby od zákazníka a kontrolu této platby účtárnou. Práce s bankovním účtem je v tomto případě obdobná jako práce s účtem při platbě dodavatelům. Takových činností může být celá řada a na jejich opakovatelnosti a generalizaci je založena myšlenka SOA. Jde tedy o to, nalézt pro podobné a opakující se procesy vhodná schémata (vzory, patterns). Dá se ukázat, že tomuto účelu lépe než modelování činností procesů vyhovuje modelování a analýza hodnotových řetězců. Popišme hodnotový řetězec. Na Obrázek 6 uvádíme obecný hodnotový systém podniku. Podnik vyrábí zboží a dodává služby zákazníkům a za to dostává peníze v hodnotě zboží a služeb. Pro tento proces potřebuje podnik provozní kapitál od investorů a věřitelů, zboží a služby od svých dodavatelů a práci svých zaměstnanců. Činitelé působící vně podniku zahrnují investory, věřitele, dodavatele, zákazníky a zaměstnance. Zaměstnanci jsou zahrnuti mezi externí činitele z toho důvodu, že pro podnik vykonávají služby a jsou za ně podnikem placeni. Investoři a věřitelé, dávají podniku zdroje ve formě peněz a na oplátku jim podnik poskytuje zdroj rovněž ve formě peněz. Investoři a věřitelé jsou ochotni dát podniku peníze, protože očekávají, že se jim vrátí částka peněz, která má vyšší hodnotu než hodnota peněz, které se původně vzdali, a to přebytek ve formě úroku, dividend nebo zhodnocení kapitálu. Obrázek 6 Podnikový hodnotový systém Zdroj: vlastní zpracování Hodnotový řetězec Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 35 Zdroje, které podnik získává od svých dodavatelů, jsou zboží a služby, v konkrétní podobě pak suroviny, součásti, stroje a zařízení, reklamní služby, účetnické služby, auditorské služby, opravárenské služby a další konkrétní podoby. Dodavatelé jsou ochotni podniku dodat zboží a služby, protože očekávají, že získají obnos peněz, který má pro ně větší hodnotu než zboží a služby, kterých se vzdali. Zaměstnanci dostávají od podniku peníze za práci. Zaměstnanci jsou ochotni dát práci podniku, neboť očekávají, že na oplátku získají obnos peněz, který má pro ně větší hodnotu než čas a úsilí, kterých se vzdali. Zdroje, které podnik poskytuje svým zákazníkům, jsou zboží a služby. Na oplátku od nich získává peníze. Podnik je ochoten poskytnout toto zboží a služby svým zákazníkům, protože očekává, že získá peníze, které pro něj mají větší hodnotu než zboží a služby, kterých se vzdává. Jakmile jsou identifikováni externí obchodní partneři a zdroje směňované mezi nimi, lze dále rozvíjet model vnitřních podnikových procesů a toky zdrojů, které je propojují. Takové zobrazení nazýváme hodnotový řetězec. Jeho příklad uvádí Obrázek 7. Ve srovnání se scénářem pro úroveň hodnotového systému zjišťujeme, že podnik lze rozčlenit na procesy, které budeme nazývat transakční cykly. Mezi transakčními cykly probíhá výměna hodnot:  finance (peníze jsou směňovány s investory a věřiteli);  lidské zdroje (peníze jsou směňovány za práce se zaměstnanci);  nákup (peníze jsou směňovány za materiál a nářadí s dodavateli);  výroba (výrobky jsou vyráběny);  prodej (zboží a služby jsou směňovány za peníze se zákazníky). Každý tok zdroje v tomto modelu představuje výstup z jednoho procesu a vstup do souvisejícího procesu. Podnik produkuje zboží v rámci výrobního (konverzního) cyklu. Pro tuto konverzi jsou potřebné zdroje, jako jsou suroviny, nástroje, výrobky a služby třetích stran. Tyto zdroje si podnik opatřuje a platí za ně v rámci cyklu nákupu a finančního cyklu. V průběhu výroby jsou také nutné lidské zdroje (práce) použité pro vlastní výrobu a řízení podnikových procesů. Práce se získává a platí se za ni v průběhu cyklu získání a placení lidských zdrojů. Platby se provádějí pomocí cyklu financování. Nezbytné peníze podnik získává z prodejního cyklu. Hodnotový řetězec podle Obrázek 7 vyjadřuje souhrnný pohled na vnitřní procesy podniku. Každý podnikový proces je znázorněn obdélníkovým blokem. Pro vyjádření podrobnějších směnných událostí a toků zdrojů z nich vycházejících je účelné každý z procesů dekomponovat na dílčí části na podrobnější rozlišovací úrovni. A to je doména pro hodnotový model REA. Budeme-li v uvedeném rozpadu dále pokračovat do úrovně operací, získáme soustavu procesů ne z hlediska průběhu činností (workflow), ale z hlediska hodnotových řetězců, které si můžeme všeobecně představit jako určité vzory chování (schémata, business patterns). Uvedené vzory mohou být použity pro sdílení informací, znalostí a funkcí podobně jako v SOA. Pomocí těchto vzorů se na této úrovni dekompozice dostaneme k ekonomickým událostem v jednotlivých transakčních cyklech. Na Obrázek 7 jsou uvedeny transakční Transakční cykly TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 36 cykly Výroba, Prodej, Nákup, Lidské zdroje a Finance. Hodnotový řetězec můžeme dále dekomponovat a definovat tak větší počet transakčních cyklů. Při návrhu úrovně ekonomických procesů (kterou nazýváme operační úroveň) se v rámci jednotlivých transakčních cyklů specifikují jednotlivé ekonomické události, jejich vazby, tok zdrojů mezi událostmi a agenty, kteří tyto události provádějí. Jakmile se ustanoví příslušná schémata, je možné přistoupit k e konceptuálnímu návrhu podnikové datové základny. Konečně na nejnižší úrovni dekompozice můžeme identifikovat jednotlivé úlohy realizující konkrétní transakce. Zde se opět přiblížíme k modelování z hlediska procesů. Určení schémat na úrovni činností není tak jednoduché jako na úrovních vyšších. Posloupnosti činností totiž obsahují prvky, které mohou být rámci racionalizace odstraněny, bez toho, že by se změnily podstatné vlastnosti modelované reality. Stejné či obdobné činnosti mohou také probíhat v různém pořadí v různých podnicích nebo v různých částech jednoho podniku a při tom jejich časový sled musí být na této úrovni modelování zobrazen. Naproti tomu modely hodnotových toků (v našem pojetí modely vyšší úrovně) nezobrazují časové posloupnosti událostí ale vazby mezi nimi. Existují však i další závažné rozdíly mezi modelováním z hlediska hodnotových toků a modelováním z hlediska procesů. O nich se zmíníme níže. Obrázek 7 Hodnotový řetězec podniku Zdroj: vlastní zpracování Pomocí hodnotových řetězců můžeme nahlížet na podnikové procesy všeobecněji, protože základní entity a vztahy jsou definovány obdobně pro všechny transakční cykly. Uvedený přístup k modelování a navrhování informačního systému podniku s použitím čtyř uvedených úrovní sémantické abstrakce představuje základ metodologie REA. V této zkratce R znamená resource – zdroj, E znamená event – událost a A znamená agent. Základní idea REA byla publikována v roce 1982 McCarthym (1982) jako všeobecný (generalizovaný) model pro účetní systémy. McCarthy tuto metodologii dále rozvíjí zejména Metodologie REA Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 37 s Geertsem a dalšími autory jako Chang a Ingraham (2007), Dunn, Cherrington a Hollander (2005), Hrubý (2006) a jiní. Přesnou definici REA modelu jako rámce pro modelování informačních systémů provedli Geerts a McCarthy (2006): In essence, the REA model is a pattern for the semantic definition of business processes. Phenomena captured by the REA model include the economic activities that take place in a company, the resources that are acquired and consumed, and the agents who are accountable for economic activities. Oba původní autoři analyzovali doménovou ontologii pro podniky (Geerts, 2007 a 2008). Tvrdí, že odpovídá definici ontologie podle Grubera (2007 a 2008) jako konceptuální specifikaci pro doménu obchodních a výrobních procesů. Pro oblast REA však dosud nebyl definován žádný matematický formalismus, i když v této oblasti existují dosud nepublikované snahy. Nyní uvedeme podrobnější popis modelu REA. Podstatnou částí tohoto modelu je operační úroveň, kterou popisujeme níže. Modelování na této úrovni probíhá s využitím následujících entit:  Ekonomický zdroj (dále jen zdroj - např. výrobky, služby, práce, peníze atd.);  Ekonomická událost (dále jen událost) představující bud' přírůstek, nebo úbytek hodnoty zdrojů, které má podnik k dispozici či pod kontrolou (např. výrobní operace, prodej výrobků, platby atd.);  Ekonomický agent (dále jen agent), kterým je jednotlivec, organizační jednotka nebo podnik. Ekonomický agent kontroluje zdroje podniku a může jejich hodnotu přesunovat na jiného agenta. Základním ekonomickým agentem, z jehož hlediska je model REA konstruován, je podnik. Obrázek 8 Všeobecné schéma prodeje Zdroj: upraveno dle Changa a Ingrahama (2007) Obrázek 8 uvádí všeobecné schéma prodejního cyklu z úrovně analýzy hodnotového řetězce. Každá ekonomická událost prodeje je spojena s určitou událostí příjmu peněz. Každá z těchto událostí je provedena (řízena) určitým agentem. Při realizaci událostí používají agenti zdroje. Základní teze ontologie REA říká, že v průběhu úbytkových událostí Popis modelu REA Směnná dualita TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 38 se agenti vzdávají určitých zdrojů, aby zvýšili hodnotu jiných svých zdrojů při realizaci přírůstkové události. Prodejní cyklus je podrobněji rozveden na Obrázek 9. Agent – podnik dává k dispozici zboží (zdroj) agentu – zákazník. V důsledku prodeje se hodnota zdrojů – zboží v podniku snižuje (úbytková událost – odtok). Agent zákazník obdrží zboží (zdroj) a platí penězi (zdroj) podniku (přírůstková událost – přítok). Vztah mezi úbytkovou událostí prodej a přírůstkovou událostí příjem peněz se nazývá směnnou dualitou. Prodávající strana odevzdává zboží, ale od zákazníka získává peníze, čímž zvětšuje hodnotu svých zdrojů. Použitím uvedených základních prvků a tezí lze v rámci REA modelovat ekonomické, obchodní a výrobní procesy nikoli na bázi jednotlivých činností ale na bázi ekonomických Modelování výroby v rámci analýzy Výrobního cyklu je založeno na sémantických prvcích týkajících se konverzního procesu REA. Cílem konverzního procesu je vytvoření nových zdrojů (výrobků) s použitím nebo spotřebou jiných zdrojů (materiál, práce, stroje, atd.) Na Obrázek 10 je uveden jeho všeobecný vzor. Zdroje Suroviny, Práce, Stroje, Nástroje, atd. se používají nebo jsou spotřebovány v rámci úbytkových událostí Spotřeba materiálu, Spotřeba práce a Práce stroje. Tyto úbytkové události jsou spojeny s přírůstkovou událostí Výrobní proces, která zvyšuje hodnotu zdroje Hotové zboží. Při realizaci vztahu konverze se tedy snižují hodnoty zdrojů Materiál, Práce a Stroj (Nástroje) zatímco hodnota zdroje Hotové zboží roste. Uvedená základní všeobecná schémata lze dále rozšiřovat, prohlubovat a spojovat v rámci analýzy jednotlivých transakčních cyklů. Tak na příklad lze spojit analýzu v rámci prodejního a výrobního cyklu pro s cílem modelovat také proces plánování výroby. Pro tento účel byla základní REA ontologie rozšířena o pojmy závazek, smlouva, rezervace, aj. a doplněna o normativní úroveň (policy level) (Geerts a McCarthy, 2006 a 2008). V práci Hruby et al. (2008) byla uvedena celá řada obecných schémat operační úrovně modelu REA, charakterizující jednotlivé procesy v průmyslovém podniku. Tato schémata je možno použít jako dílčí modely konceptuálního modelu hodnotových procesů. Základní výhodou systému REA je to, že modely jsou jednoduché, na úrovni abstrakce srozumitelné pro netechnicky orientované účastníky modelovacího procesu, tedy konečné uživatele a analytiky. Zároveň jsou dostatečně přesné na to, aby je bylo možné strojově interpretovat a automaticky přeložit do podoby softwarového systému, a to jen s malými úpravami ze strany programátora. Na rozdíl od tradičních přístupů, které modelují podnikové procesy pomocí obecných konceptů jako aktivity, datové entity, atd., používá model REA pouze pět výše uvedených základních pojmů. To, že jsou modelovací elementy konkrétnější, než elementy jako aktivita nebo datová entita, má značné důsledky pro množství informací obsažené v modelu, a to při zachování jeho jednoduchosti. REA navíc formuluje pravidla pro vytváření modelů. Tato pravidla slouží pro ověření konsistence modelu. Tak, například pro každý modelovaný ekonomický zdroj musí existovat ekonomická událost, která vysvětluje, jak podnik tento zdroj nabyl, a ekonomická událost modelující způsob, jak zdroj pozbude. Dále, ke každé ekonomické události, která zvyšuje hodnotu zdrojů, musí existovat událost, která snižuje hodnotu zdrojů, a pro každou ekonomickou událost musí Ekono- mický zdroj a událost Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 39 existovat dva ekonomičtí agenti – příjemce a poskytovatel zdroje vztaženého k této události. Hlavním rozdílem model u REA v porovnání s tradičními modely je to, že odpovídá na otázku, proč podnik určitou aktivitu vykonává, tedy proč ekonomické události nastávají. Obrázek 9 Zákazník obdrží zboží a platí Zdroj: upraveno dle Hruby [HRU 2006] Sekundární výhodou systému REA je to, že vede k návrhu softwarových systémů, ve kterých jsou zaznamenávána veškerá data ovlivňující hodnotu podnikových zdrojů. Proto software založený na systému REA umožňuje produkovat lepší a kompletnější výstupní sestavy a poskytovat relevantnější data podnikovému managementu, než jakýkoli současně dostupný software pro řízení podniku (Enterprise Resource Planning software – ERP). Další výhodou modelování na bázi hodnotových řetězců, tedy i REA je, ze své podstaty zachycují procesy probíhající napříč podnikovými aplikacemi a představují aktivity, které jsou vlastním cílem – výměnu hodnot. Na druhé straně hodnotově orientované modely neberou do úvahy pojem času, neurčují, co hodnotově orientovaný proces spouští a také neurčují pořadí jednotlivých událostí. To je úkolem procesně orientovaných modelů. PRŮVODCE TEXTEM Dá se ukázat, že při použití modelování na základě hodnotových řetězců jako základu lze dospět k procesním modelům (Vymětal, 2008b). Tuto myšlenku dále rozvineme níže. TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 40 Obrázek 10 Obecný vzor výrobního procesu Zdroj: vlastní zpracování KONTROLNÍ OTÁZKA Co to je směnná dualita? 1.7 Modelování režijních nákladů při plánování výroby pomocí modelu REA 1.7.1 KONCEPT ÚROVNĚ PRAVIDEL V MODELU REA Zatím jsme se zabývali pouze operační úrovní REA modelu. Tato úroveň v podstatě zachycuje co se v procesech děje nebo událo v minulosti. Je zřejmé, že to nestačí pro model plánování. Sémanticky vyšší úroveň, která popisuje co se státi má, může nebo musí v budoucnosti, se v modelu REA nazývá úroveň pravidel (policy level). Všeobecně tedy lze říci, že úroveň pravidel popisuje, co je plánováno, případně jaká platí pravidla pro směnu nebo výrobu na operační úrovni. Jako příklady entit na úrovni pravidel lze uvést kusovník, kontrakt, závazek, typ výrobku, typ práce atd. Je zřejmé, že k entitám úrovně pravidel dojdeme zejména sémantickou abstrakcí - typováním a seskupováním. Typování (typifikace) popisuje vlastnosti náležející množině entit. Seskupování (grouping) naopak popisuje vlastnosti kolekcí - členů určitých skupin. Jak docílíme v REA modelu transfer informací o tom co se má, může nebo musí stát k entitám Úroveň pravidel Typování a seskupo- vání Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 41 operační úrovně? Vztah operační úrovně k úrovni pravidel zjednodušeně znázorňuje Obrázek 11. Problematiku ozřejmíme na příkladu plánování a rozvrhování výroby. Pro plánování výroby jsou nutné následující základní údaje:  přesný popis výrobku, součástí a materiálů potřebných k jeho výrobě;  detailní popis pracovních postupů, strojů a nářadí potřebných pro výrobu a montáž výrobků (strukturovaný kusovník- viz Obrázek 12). V případě nákupu potřebných komponent je také nutný stav zásob na skladech a doba pro dodávku v případě nákupu; stav vytížení strojů. Obrázek 11 Zjednodušený vztah mezi operační úrovní a úrovní pravidel REA Zdroj: upraveno podle Geertse a McCarthyho (2006) Obrázek 12 Příklad strukturovaného kusovníku Zdroj: vlastní zpracování TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 42 Strukturovaný kusovník zde můžeme považovat za Informační popis dle Obrázek 11. Je výsledkem znalostí a pravidel nutných pro výrobu daného výrobku. Bez této znalosti nemůže být výroba zahájena. Jak jsme uvedli výše, výroba se plánuje na základě strukturovaného kusovníku a znalosti situace v provoze. Na základě těchto znalostí a zakázkové náplně, která také patří do úrovně pravidel (pro zjednodušení popisu jsme tyto entity vynechali) předák na provoze nebo plánovač rozvrhuje výrobu do výrobních příkazů. Tyto výrobní příkazy představují informaci, která se při výrobě použije nebo spotřebuje. Z hlediska REA modelu na operační úrovni tedy představuje specifický zdroj - znalost nutnou pro plánování. Zdroje jsou však výsledkem událostí na operační úrovni. To tedy znamená, že musí existovat procesy, které vedou k jejich vzniku. Tyto procesy (události) probíhají v části operační úrovně REA modelu, kterou jsme nazvali režijní procesy. 1.7.2 NÁVRH MODELOVÁNÍ REŽIJNÍCH NÁKLADŮ V PLÁNOVÁNÍ VÝROBY POMOCÍ REA Představme si režijní činnosti jako tu část operační úrovně REA, kde vznikají entity úrovně pravidel. Tento předpoklad je oprávněný, protože úroveň pravidel je rozšíření základního REA modelu, kde se specifikuje, co se má, může nebo musí odehrát v podniku v budoucnosti. Ontologie REA definuje zdroje, které jsou kontrolované agenty. Zdroje se používají, ale také vznikají pomocí ekonomických událostí. Jaké zdroje se používají pro vznik entit úrovně pravidel? Především je to práce spotřebovaná interními agenty při jejich definici. Dále se používají informační zdroje, které jsou nutné pro průběh událostí vytvářejících zdroje – pravidla dále použitá pro řízení událostí na operační úrovni. V průběhu ekonomických událostí vedoucích ke vzniku zdrojů – pravidel tedy dochází ke stejné spotřebě a vzniku zdrojů jako při směně nebo výrobě (konverzi). Z hlediska REA modelu zde tedy dochází k tomu, že ekonomické události v operační úrovni jedné části REA modelu vytvářejí entity úrovně pravidel jiné části modelu. Tento vztah nejlépe schematicky a zjednodušeně znázorníme pomocí Obrázek 13, který znázorňuje dva typy procesů – řídicí proces REA a řízený proces REA. Na straně řídicího procesu dochází v operační úrovni ke spotřebě zdroje – Práce plánovače a v důsledku ekonomických událostí vzniká zdroj – Plán výroby hotových produktů. Jedná se o informační zdroj typu cíl. Na straně řízeného procesu probíhá výroba (konverze), kde jedním ze spotřebovávaných (užitých) zdrojů je informace – Údaje o plánu. Operační úrovně REA modelu na straně řídícího procesu a na straně procesu řízeného nejsou přímo propojeny, protože z ontologie REA plyne, že přímá vazba zdroj – zdroj není možná. Předání údajů o Plánu výroby hotových výrobků do řízeného procesu výroby probíhá přes úroveň pravidel tohoto procesu, a to přes entitu typu schedule. Z uvedených důvodů jsme zavedli do modelu vazbu typu reflexe, která propojuje informačně shodné entity plánu výroby, které se však z hlediska sémantiky REA liší. Současně jsme zavedli dva typy REA modelů. REA model, který vytváří na své operační úrovni zdroj, který se má zrcadlit na úrovni pravidel jiného REA modelu, nazýváme řídicí REA systém. Adekvátně REA model, který na své operační úrovni spotřebovává nebo užívá zdroj z řídicího modelu, se nazývá řízený REA systém. Režijní procesy Řídicí a řízený proces a sys- tém Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 43 Existuje řada důvodů pro zavedení těchto pojmů, zejména:  charakter zdroje vytvořeného řídicím procesem má „znalostní „ charakter;  zavedení vazby typu reflexe znamená, že zdroj se zrcadlí z operační úrovně řídicího modelu do úrovně pravidel procesu řízeného;  vlastní realizace této vazby v programovém systému je možná;  ačkoli zdroj na operační úrovni procesu řídicího má informačně stejný obsah jako entita na úrovni pravidel procesu řízeného, jde o sémanticky různé objekty. Uvedený postup umožňuje doplnit REA modely základních podnikových hodnotových procesů o modely administrativních a řídicích procesů s respektováním jejich hodnotového vyjádření. Tím vzniká možnost tvorby komplexních podnikových modelů včetně modelů režijních nákladů. PRŮVODCE TEXTEM Jak ukážeme dále, je modelování řídicího a řízeného procesu pomocí REA přechodnou etapou k zobecněnému modelu podnikových činností. Pokusíme se dále ukázat, že zobecněný model s využitím hodnotových řetězců a obchodních vzorů založených na ontologii REA vede k uzavřené metodice modelování a simulací řídicích a informačních systémů. Obrázek 13 Řídící a řízený systém ve vztahu k úrovni pravidel Zdroj: vlastní zpracování TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 44 1.8 Dynamizace hodnotového modelu REA REA model na operační úrovni představuje nejnižší stupeň dekompozice hodnotově orientovaného modelu zvolené oblasti podnikových činností (domény). Přehledně uvádí toky hodnot mezi agenty a ekonomické události, které v těchto tocích působí a ovlivňují hodnoty vstupních a výstupních zdrojů. Při tom však neodpovídá na následující otázky:  jaká je posloupnost jednotlivých ekonomických událostí;  který účastník – ekonomický agent proces spustil a u kterého účastníka – ekonomického agenta proces skončí;  jak v modelu zobrazit podmínky a cykly;  je REA model konzistentní z pohledu vykonávaných úloh? Samozřejmě je možné namítnout, že posloupnost událostí je viditelná v průběhu vlastního procesu nebo po jeho skončení. Z hlediska modelu však tento pohled nestačí. Proto je nutné model REA doplnit o hledisko dynamiky průběhu. Jde tedy o to, zda je možné z modelu REA odvodit konzistentní procesní model. Postup tvorby konzistentního procesního modelu nazýváme dynamizací REA modelu. K dynamizaci používáme nástroje UML zejména diagram aktivit, dále stavové diagramy a sekvenční diagramy. Využití metod UML je vhodné zejména ze dvou důvodů:  Vlastní REA model k zobrazení používá syntaxi a grafické nástroje UML.  Vytvoření dynamických diagramů pomocí UML umožňuje ve fázi realizace použít metod objektového programování se standardními postupy, běžně užívající v praxi odpovídající vývojové prostředky (IDE). Příklad postupu při dynamizaci uvedeme na jednoduchém příkladu zpracování jednoho výrobního příkazu. Definujme provedení jednoduchého výrobního příkazu následovně. Na základě rozvrhu výroby předák zasílá dělníkovi výrobní příkaz definující výrobek, který má být vyroben, dobu začátku a délku trvání operace. Současně je informace o výrobku a jeho kusovník zaslán skladníkovi jako objednávka k vyskladnění nástrojů a materiálu. Skladník vydává materiál a nástroje a dělník začíná pracovat. Po zhotovení výrobku vrací dělník nástroje (materiál byl spotřebován při výrobě) skladníkovi a hlásí předákovi ukončení operace. Skladník informuje předáka, že nástroje byly vráceny do skladu. Předák označí výrobní příkaz za splněný. Jednoduchý REA model tohoto případu je uveden na Obrázek 14. Všimneme si, že do REA modelu byl zaveden zvláštní zdroj – Informace o plánu. Jedná se o zvláštní typ zdroje – informaci potřebnou, aby mohla proběhnout výroba. Tato informace je buď plně spotřebována v průběhu výroby nebo, pokud se jedná o typizovaný plán, je užita. Uvedený příklad demonstruje fakt, že pro úplný popis procesu je nutné vzít do úvahy také činnosti nutné k realizaci výrobního příkazu. Pro dynamizaci uvedeného příkladu využijeme tři základní procesní diagramy jazyka UML: jednoduchý stavový diagram, diagram aktivit a sekvenční diagram. Popis těchto diagramů a jejich využití je dostatečně znám z odborné literatury. Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 45 Obrázek 14 Jednoduchý model výroby Zdroj: vlastní zpracování 1.8.1 ZACHYCENÍ ZMĚNY STAVŮ REA model na operační úrovni specifikuje dvě základní duality mezi ekonomickými událostmi:  dualitu směny, kdy podnik předává zdroj — výrobek zákazníkovi a dostává za to od zákazníka zdroj — peníze;  dualitu konverze, kdy podnik používá nebo spotřebovává své interní zdroje pro výrobu nového zdroje — produktu. Pro případ směny byly stavové diagramy definovány ve standardu ISO/IEC 15944-4 jako fáze obchodní transakce. V tomto standardu jsou však identifikovány entity a stavy nejen operační úrovně ale i úrovní vyšších (plánování, vyjednávání atd.) Pro operační úroveň směny použijeme upravený stavový diagram, znázorněný na Obrázek 15. Obdobně lze sestavit stavový diagram výroby (dualita konverze) na operační úrovni pro případ průběhu uvedeného výrobního příkazu (Obrázek 16). Výrobní příkaz se může nacházet v šesti stavech. Jakmile je provádění výrobního příkazu zahájeno, probíhá inicializace zdroje Informace o plánu v průběhu, které jsou informace doručeny dělníkovi a skladníkovi. Tuto činnost provede předák, proces se dostává do stavu „uvolněno" a výroba začíná. Po skončení výroby dostává předák informaci o navráceném nářadí a ukončené výrobě. Za určitých okolností je nutno zaslat informaci o zpoždění. V obou předchozích případech je stav změněn na „aktualizováno". S použitím aktualizované informace předák označí výrobní příkaz za uzavřený. Je zřejmé, že veškeré entity REA modelu mohou být pro definici stavového diagramu použity. TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 46 Obrázek 15 Stavový diagram obchodního případu Zdroj: vlastní zpracování 1.8.2 DIAGRAM AKTIVIT Diagram aktivit slouží ke znázornění průběhu REA procesu na operační úrovni z hlediska zdrojů a činností souvisejících s jejich transformací a směnou. Podstatné u diagramu aktivit je, že určuje účastníky procesu, start a konec procesu a ekonomické agenty, kteří se procesu účastní a v jaké roli. Pro definici diagramu aktivit jsou použita následující pravidla:  každý REA ekonomický agent obdrží v diagramu aktivit svoji plavební dráhu;  každá relace v REA diagramu představuje aktivitu;  každý zdroj REA představuje objekt v diagramu aktivit a je umístěn bud' v plavební dráze některého agenta nebo na rozhraní mezi dvěma agenty pracujícími s tímto zdrojem;  zdroje a aktivity jsou soustředěny do rámců (UML frames), představujících jednotlivé ekonomické události REA;  duality jsou znázorněny jako vztahy propojující jednotlivé rámce;  pro sjednocení nebo rozdělení jednotlivých aktivit jsou použity standardní nástroje UML (join a fork); mezi aktivitami musí být dodrženo pravidlo řetězce „poskytuje" — zdroj — „přijímá". Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 47 Obrázek 16 Stavový diagram výrobního příkazu Zdroj: vlastní zpracování Důsledky výše uvedených pravidel jsou následující:  inherentní, ale v REA modelu neviditelná logika sledu jednotlivých ekonomických událostí a s nimi souvisejících činností je v diagramu aktivit viditelná;  je možné přistoupit k tvorbě sekvenčního diagramu UML, pokud je to z hlediska modelování potřebné;  rozdělením agentů do plavebních drah zpřehledňuje model vztahů ke zdrojům. Pomocí pravidla řetězce uvedeného výše lze kontrolovat konzistenci úplnost REA modelu na operační úrovni. Diagram aktivit jednoduchého výrobního příkazu je uveden na Obrázek 17. 1.8.3 SEKVENČNÍ DIAGRAMY Sekvenční diagramy slouží k zachycení časové posloupnosti jednotlivých aktivit a událostí (zpráv), které je vyvolávají. Časový průběh událostí je zaznamenán množinou nespojitých grafických objektů, které znázorňují aktivity jednotlivých agentů. Grafické objekty – aktivity jsou umístěny v plavebních drahách jednotlivých agentů. Mezi aktivitami různých agentů dochází k výměně zpráv. Zprávy znázorňují jednotlivé relace (operace) se zdroji. Zdroje, kterých se aktivity týkají, představují parametry uvedených zpráv. Uvedené schéma tak plně odpovídá principu objektového programování, kde zprávy představují jednotlivé metody volané agenty k uskutečnění aktivit na operační úrovni. Tvorba sekvenčních diagramů není nutnou podmínkou k dynamizaci REA modelů, představuje však jejich další TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 48 doplnění s možností hlubší kontroly konzistence modelů. Na obrázku Obrázek 18 je uveden příklad sekvenčního diagramu jednoduchého průběhu výrobního příkazu. Obrázek 17 Diagram aktivit při průběhu jednoduchého výrobního příkazu Zdroj: vlastní zpracování Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 49 Operace činnosti Předáka začíná dvěma asynchronními zprávami zaslanými agentům Skladník a Dělník. Tyto zprávy jim dodávají nutné informace k zahájení a průběhu výrobního příkazu. Po obdržení těchto informací Skladník vydá Dělníkovi nářadí a materiál nutný k provedení operace. Dělník pak začíná pracovat. Po dokončení práce zasílá zprávu Předákovi a vrací nářadí Skladníkovi. Skladním informuje Předáka. Když Předák obdrží obě zprávy, označí operaci za uzavřenou. Všechny nezbytné zprávy byly v tomto modelu odvozeny ze základního REA modelu na Obrázek 14. Jediným rozšířením je zpráva o ukončení práce a vrácení nářadí. Lze snadno ukázat, že jednoduché rozšíření modelu na Obrázek 18 by tento případ pokrylo. Lze tedy říci, že sekvenční diagram lze odvodit ze základního REA modelu na operační úrovni. Obrázek 18 Sekvenční diagram průběhu jednoduchého výrobního příkazu Zdroj: vlastní zpracování Schematické shrnutí uvedeného postupu modelování pomocí hodnotových řetězců uvádí Obrázek 19. Jednotlivé transakční cykly se postupně rozpadají do schémat operační úrovně a úrovně pravidel REA vytvářených na základě REA obchodních vzorů. Tato schémata se poté dynamizují a při tom probíhá kontrola konzistence jednotlivých modelů. Definované entity a jejich asociace slouží jako základ pro datové modelování. Datové modelování REA diagramů zahrnuje následující kroky: TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 50  vytvoření tabulky pro každou REA entitu;  vytvoření tabulek pro relace typu n:m (vyplývá z požadavků na normalizaci relačních databází);  stanovení polí pro každou tabulku a určení primárních klíčů;  stanovení cizích klíčů pro znázornění relací mezi jednotlivými tabulkami. Výsledkem těchto kroku je statický popis jednotlivých REA diagramů a jednotlivých informací, které REA entity obsahují. V rámci dynamizace REA diagramů se stanoví činnosti jednotlivých ekonomických agentů účastnících se ekonomických událostí a toky vyměňovaných zpráv. Výsledkem je celkový návrh umožňující postupně přejít k přípravě programového kódu. Lze tedy konstatovat, že dynamizací modelů REA lze dojít k procesnímu modelu, který je však konzistentní s hodnotovými toky podniku. Vzhledem k tomu, že jednotlivé ekonomické události nejsou definovány v závislosti na procesech a organizační struktuře modelované reality ale na toku hodnot, je možno definovat, případně realizovat vícenásobně použitelné moduly. Obrázek 19 Schematické shrnutí postupu při modelování pomocí hodnotových ře- tězců Zdroj: vlastní zpracování Statický popis REA diagramů Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 51 KONTROLNÍ OTÁZKA Je možné na základě REA modelu vytvořit analogický procesní model? Jak dochází k dynamizaci REA modelu? 1.9 Zobecnění postupů při modelování a simulaci podnikových procesů. Agentový přístup. 1.9.1 ZOBECNĚNÍ POSTUPŮ PŘI MODELOVÁNÍ. SIMULACE. Modely na základě hodnotových toků i modely procesů popisují události (činnosti) jako takové. Neříkají však, proč, za jakým účelem tyto události probíhají. REA modelování sice určuje, proč probíhá ekonomická událost ve vztahu k ekonomickým zdrojům, neříká však nic o tom, k jakým výsledkům pro podnik z hlediska jeho cílů tyto události mají vést, případně jaká opatření je třeba udělat, aby se žádaných cílů dosáhlo. Modelování procesů a hodnotových řetězců firmy tedy nedává úplný obraz o řízení a potřebné pružnosti v rozhodování. Na druhé straně má podnik více cílů než jen dosažení plánovaných ukazatelů. Jako sociální systém musí vyhovovat také určitým sociálním cílům a potřebám. Tyto cíle se odrážejí nejen na úrovni podniku jako takového ale také na nižších úrovních organizace a u jednotlivců. Sociální cíle se však mohou vzájemně ovlivňovat a vytvářet tak další vlivy vyžadující zásahy z hlediska řízení. Pro zkoumání a modelování takových faktorů nemusí být relativně statické výsledky procesního a hodnotového modelování dostatečné. V části 1.7.1 jsme popsali základní pohled na úroveň pravidel z pohledu klasické ontologie REA. Na úroveň pravidel REA však lze pohlížet i z jiné perspektivy. Úroveň pravidel přímo ovlivňuje operační úroveň REA a to tak že definuje typy entit operační úrovně, pravidla asociací (vazeb) jednotlivých entit úrovně pravidel, které se mohou různým způsobem promítat na operační úrovni (viz Geerts a McCarthy, 2006). Tento princip jsme dále rozvedli. Výsledek názorně ukazuje Obrázek 20. Sémantické abstrakce entit REA operační úrovně (typy, skupiny a další entity) si lze z praktického hlediska představit zejména jako informačně intenzivní položky (např. kusovníky), standardy a plány (rozpočty) a také validační pravidla. V tomto smyslu představují entity úrovně pravidel REA údaje, které regulují (řídí) chování entit na operační úrovni. Spolu s entitami operační úrovně představují řízený systém. Entity REA úrovně pravidel však na této úrovni podle pravidel platných pro REA ontologii nemohou vznikat ani se měnit, neboť tento proces je spojen vždy s ekonomickými událostmi, které mohou existovat na operační úrovni. Proto obě úrovně zahrnujeme do logického celku – řízeného systému. Kde tedy entity úrovně pravidel vznikají? Vznikají v jiné logické části námi analyzovaného systému – na operační úrovni systému řídicího. V části 1.7.2. a na Obrázek 13 jsme vazbu TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 52 mezi entitami operační úrovně řídicího systému a entitami úrovně pravidel řízeného systému nazvali jako vazbu typu reflexe. Hodnotový řetězec, ze kterého vychází metoda REA, definuje několik transakčních cyklů, jimž na další úrovni dekompozice odpovídají entity operační úrovně a úrovně pravidel REA seskupené do odpovídajících logických celků (viz Obrázek 21). Každý transakční cyklus zde představuje řízený systém ovládaný z operační úrovně řídicího systému přes úroveň pravidel odpovídajícího REA modelu. Je zřejmé, že i daný řídicí systém má svoji úroveň pravidel, ve které jsou zachyceny pravidla vyšší úrovně zpravidla reagující na celopodnikové cíle a strategii a chování okolí (legislativa, daně, nadnárodní standardy atd.). Hodnoty výskytů jednotlivých entit v modelovaném systému, jejich vazby, strategie a cíle podniku jsou zachyceny v odpovídajících databázích. Obrázek 20 REA úrovně jako řízený systém Zdroj: vlastní zpracování Takto pojatý model lze využít i k simulacím. Provedení simulací lze využít jak na úrovni konceptuálního modelování systému, kdy ji lze použít ke kontrole konzistence modelu a jeho případnému zlepšování a doplňování (zpřesňovaní), tak při rutinním provozu, kdy lze simulovat například vlivy okolí a důsledky přijatých rozhodnutí. PRO ZÁJEMCE Simulace je napodobení nějaké skutečné věci, stavu nebo procesu. Samotný akt simulace něčeho obecně znamená zobrazení některých klíčových vlastností nebo chování vy- Simulace Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 53 braných fyzikálních, nebo abstraktních systémů. Simulace se používá v mnoha souvislostech, zahrnujících modelování přírodních systémů nebo lidských systémů s cílem získat poznatky o jejich fungování. Jiné souvislosti zahrnují technologické simulace pro optimalizaci výkonu, bezpečnostní inženýrství, testování, školení a vzdělávání. Simulace může být použita pro zobrazení případných reálných dopadů alternativních podmínek a způsobů jednání. Klíčové otázky v simulaci zahrnují např. pořízení platných zdrojů informací o příslušném výběru klíčových charakteristik a chování, využití zjednodušujícího odhadu a předpokladů v rámci simulace a věrnost a platnost výsledků dané simulace. Simulace, při níž modelem je počítačový program, který se pokouší simulovat abstraktní model určitého systému se nazývá počítačová simulace. Úkolem simulačního programu je zjistit, jak se bude systém chovat pro zadaná vstupní data. Úkolem simulačního programu není provádět optimalizaci, tzn. hledat, pro která vstupní data dostaneme optimální řešení. Uživatel může provádět se simulačním programem opakované simulační experimenty s cílem zjistit očekávané výsledky pro různá vstupní data a nalézt tak optimální řešení problému. Simulace je v matematice a kybernetice vědecká metoda, při které se zkoumají vlastnosti nějakého systému pomocí experimentů s jeho matematickým mode-lem. V informatice má simulace poněkud zvláštní význam. Alan Turing použil výraz “simulace”, aby popsal, co se stane, když jeho tzv. univerzální stroj spustí přechodovou stavovou tabulku (v moderní terminologii: počítač spustí program), která popisuje stavovou přechodovou rovnici, vstupy a výstupy samostatného stroje. Počítač simuluje tento stroj. Obdobně v teoretické informatice je pojem simulace spojován se systémem překladače, který je užitečný pro studii operační sémantiky. Jestliže takto pojmeme definici úrovně pravidel („co se státi má) a operační úrovně („ co se děje, co se stalo"), a použijeme výše uvedené definice pro řídicí systém a jím řízené (sub)systémy, pak docházíme k závěru, že REA model ve své podstatě představuje obraz obecného regulačního obvodu. Model obsahuje v prvé řadě řízenou soustavu – jednotlivé podnikové subsystémy – v terminologii hodnotových řetězců transakční cykly. Řízený systém produkuje výrobky, které po prodeji generují obrat a zisk („tvrdé výstupy") a další výstupní veličiny jako jsou ukazatele o počtu a stavu zákazníků, návratnost investic, charakteristiky kvality lidských zdrojů a další „měkké" výstupy. Výstupní veličiny jsou zachycovány a měřeny podnikovými podpůrnými činnostmi, které realizují štábní útvary podniku, výstupy z informačního systému atd. Tyto podpůrné činnosti můžeme považovat za měřicí člen v soustavě. Výstupní ukazatele se v diferenčním členu srovnávají s požadovanými hodnotami a cíli podniku (dedukce, validace, analýza) a odchylky jsou k dispozici managementu, který přijímá patřičná operativní, taktická i strategická rozhodnutí. V naší abstrakci působí členové managementu s rozhodovací pravomocí (rozhodovatelé) jako řídicí systém. Na řízený systém působí vnější faktory, jejichž působení lze obecně předpokládat také u řídicího systému. Za ně zde považujeme změny v legislativě, informace o konkurenci, změny pravidel poskytování bankovních úvěru a jejich úrokové míry atd. Obdobně Počítačová simulace TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 54 lze předpokládat inherentní vlivy nebo šumy uvnitř celé soustavy. Jde například o změny kvality předávaných informací, chyby obsluhy prostředků informačního systému podniku, chyby v programech apod. Vzhledem k tomu že REA model používá obchodní vzory založené na sémantické abstrakci, můžeme formulovat závěr, že REA model představuje sémantickou abstrakci regulačního obvodu. Na rozdíl od klasické definice regulačního obvodu (viz např. Kubík et al., 1982) zde navíc existují sémantické abstrakce reality (co se děje, co se stalo), tedy zobecnění modelu účetnictví (což byl původní cíl, který si vytýčila ontologie REA) a sémantické abstrakce regulátoru. Jeho cílem je dosažení cílů a stability systému. Problematika stability ekonomických systémů z hlediska metodologie REA však přesahuje rámec této práce a jistě by si vyžádala další hluboký výzkum. Druhým rozdílem oproti klasickému modelu regulačního obvodu je existence rozhodovatelů (rozhodovacího členu), který může pro dosažení svých cílů zvolit různé strategie. Obrázek 21 REA transakční cykly jako řízené systémy Zdroj: vlastní zpracování Simulace důsledků rozhodování představuje možný krok ke zvýšení kvality řízení. Existuje celá řada procesních modelů s možností simulace jednotlivých procesů. V řadě případů je však vhodné simulační modely doplnit o simulace chování vícenásobně použitelných modulů. Vícenásobná použitelnost služeb je základem Servisně orientované architektury (SOA). Zařazení služby do celého systému se provádí orchestrací. Stanovení parametrů orchestrace je jedním z úzkých míst praktického použití SOA. My v souladu s názorem Hrubého (2006) oproti tomu navrhujeme používat standardní vzory chování těchto služeb. Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 55 Ukázali jsme, že použití hodnotových řetězců a ontologie REA umožňuje takové moduly definovat. Situaci názorně ukazuje Obrázek 22. Zde je ukázán výše uvedený přístup, kdy entity řízeného subsystému jsou ovlivňovány ze strany systému řídicího přes úroveň pravidel. REA model řídicího systému pro jednoduchost ve schématu neuvádíme. Simulace je v tomto schématu znázorněna jako podpůrný modul, který se připojuje k rozhodování se simulovanými důsledky rozhodnutí. Simulační modul je založen na REA modelu řízeného subsystému, s tím že modeluje chování operační úrovně REA na základě změn v úrovni pravidel vyvolané opatřeními rozhodovatelů. Výše uvedený obecný model podniku umožňuje specifikovat způsob komunikace mezi jeho jednotlivými částmi. Z povahy reálné vnitropodnikové komunikace plyne, že se uskutečňuje přenosem zpráv a to velmi často v asynchronním režimu. Simulace by i tento fakt měla vzít do úvahy. Při modelování však musíme mít na zřeteli, že i interní podnikové útvary mají určité hierarchie svých cílů, ne vždy přímo odvozených z cílů podniku. Standardní vzory chování cíle zpravidla nezachycují. Obrázek 22 Zařazení simulačního modelu do kontextu architektury využívající REA Zdroj: vlastní zpracování 1.9.2 AGENTOVÝ PŘÍSTUP K MODELOVÁNÍ A SIMULACI PROCESŮ Modelování a simulace se zahrnutím využitím soustavy podnikových cílů, působení okolí podniku a případných sociálních cílů jednotlivých podnikových složek vede zřejmě Agentové paradigma TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 56 k značně heterogennímu systému objektů. Ze stručných úvah uvedených výše lze dovodit, že změny vyvolávající řídicí zásahy nemají stejný zdroj, charakteristiky ani význam pro řízení. Z toho je zřejmé, že lze jen s obtížemi nalézt postupy, které by na ně na úrovni podniku určitým standardním způsobem reagovaly. Jde zde zřejmě o heterogenní systém jak na úrovni vstupů, tak na úrovni regulačních výstupů. Takový heterogenní systém je obtížné realizovat s využitím standardních strukturovaných postupů. Nabízí se tedy myšlenka použít takové přístupy, ve kterých by jednotlivé funkce či služby byly podporovány určitým stupněm lokální inteligence a odpovídající komunikací mezi simulovanými objekty. Tuto myšlenku mohou realizovat například přístupy s použitím softwarových agentů. Agent, v našem případě softwarový agent, je programový modul, který může rozhodovat o svých akcích tak, aby dosáhl stanoveného cíle. Tato schopnost je dána jeho chováním. V našem případě neuvažujeme pouze s jedním agentem, ale s celou jejich komunitou. Jedná se tedy o multiagentní systém. Agentové paradigma je založeno na následujících myšlenkách (Bellifemine, 2003):  Agent je autonomní – má do určité míry kontrolu nad vlastními akcemi a za určitých okolností může přijímat rozhodnutí vedoucí k dosažení stanoveného cíle.  Agent je proaktivní – nejen že reaguje na externí impulsy, může vykazovat cílové chování, případně vyvíjet vlastní iniciativy.  Agent má sociální chování – je schopen a má potřebu komunikovat s jinými agenty. Agentové paradigma neurčuje, jak velkou část reality má agent modelovat. Může to být ucelená část ERP systému nebo například model plánování výroby, průběhu prodeje, apod. To umožňuje jednak agenty do modelu přidávat, zvyšovat míru rozlišení u určitých částí modelu nebo realizovat podnikový model s různými mírami rozlišení reprezentace reality podle potřeby. Komunikace mezi agenty, která tvoří jednu ze základních myšlenek multiagentového přístupu, není založena na vzdálených voláních (RPC – remote procedure call), ale na systému asynchronních zpráv. Princip asynchronních zpráv umožňuje agentům komunikovat s jinými agenty, aniž by jejich jiné činnosti byly vázány na výsledek komunikace. Ukázali jsme, že při dynamizaci REA modelu (sekvenční diagram) lze přímo vytvořit podmínky definující způsob komunikace mezi jednotlivými ekonomickými agenty. Dá se tedy tvrdit, že dynamizovaný systém REA je s agentovým paradigmatem kompatibilní. Agentový přístup však jednoznačně vede k potřebě standardizace chování agentů a jejich vzájemné komunikace. Nejznámějším standardem v této oblasti je standard konsorcia FIPA (Foundation for Intelligent Physical Agents). Konsorcium FIPA vydalo referenční model agentové platformy v roce 2002 (Bellifemine, 2003). Tento standard vychází z myšlenky, že agenty vzájemně komunikují na principu peer-to-peer (P2P). Pro námi sledovaný účel však tento princip není optimální. Když vyjdeme z výše uvedeného obecného modelu systému podniku, docházíme k názoru, že je zde nutná určitá hierarchizace. Striktní stanovení určité hierarchie však znamená odklon od uvedeného agentového paradigmatu. Zavedení hierarchizace a smíšené komunikace je však nutné z důvodů, že s růstem počtu agentů roste kva- Komunikace mezi agenty Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 57 draticky počet vyměňovaných zpráva tím i spotřeba zdrojů v simulovaném i reálném systému. Použití smíšeného agentového přístupu umožňuje pokrýt poměrně rozsáhlou oblast řešení od komplexních automatizovaných systémů řízení výroby na úrovni agregátů (Vrba, 2004) až po plánování a simulaci výrobních celků (Bečvář et al., 2003), (Bucki, Wasilewski, 2004). Vzniká otázka, na jaké platformě navržený model realizovat. Z hlediska standardů se jako nejvhodnější jeví standardy konsorcia FIPA. Specifikace abstraktní architektury (FIPA-AAS) obsahuje povinné a volitelné oblasti. Mezi povinné části FIPA AAS patří následující moduly:  správa agentů;  správa služeb;  komunikační jazyky a zprávy;  transportní mechanizmus. Podrobný popis vztahů mezi prvky abstraktní architektury FIPA analyzoval Kubík (2004). Z dostupných literárních pramenů plyne, že jako jazyk realizace agentů se jeví možnost použití LISP nebo Javy. Vlastní programovací jazyk však v daném případě nepostačuje pro dodržení pravidel FIPA bez toho, že by bylo nutno vyvinout velké úsilí k přípravě celkového okolí simulace. Proto lze pro tyto případy doporučit platformu JADE, vyvinutou laboratoří TILAB firmy Telecom Italia. 1.9.3 PŘÍKLAD POUŽITÍ AGENTŮ PRO SIMULACI OBCHODNÍ ORGANIZACE Dosahování stanovených cílů je založeno na principu regulačního obvodu, ve kterém působí jednotlivé moduly jako softwarové agenty simulující chování obchodních zástupců, zákazníků, managementu, průběh marketingových akcí, nákupčí a dodavatele. Role managementu zde představuje řídící člen regulačního obvodu, obchodní zástupci, nákupčí a subsystém marketingu představují členy řízené. Měřicí člen je vytvořen aplikačním modelem podniku a to bud' modelem vytvořeným na základě MS Dynamics NAV nebo jiným aplikačním modelem. Aplikační model provádí činnosti subsystémů Zakázkové evidence a fakturace, Nákupu a skladového hospodářství, Marketingu, účetnictví, optimálně také řízení výrobních zakázek a dodává řídicímu členu údaje o prodeji, nákupu, obratu, zisku, zákaznících, závazcích a pohledávkách, cash flow atd. Při rozhodování používá management odchylky od plánovaných (rozpočtovaných) veličin a strategie realizující zápornou zpětnou vazbu popsané níže. Na podnik působí z okolí různé náhodné poruchy realizované dalšími softwarovými agenty. Systém obsahuje: Regulační obvod TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 58  aplikační model podniku obsahující základní podnikové subsystémy nakup, prodej, účetnictví, sklady a marketing, optimálně také plánovaní výroby, reagující na vstupy z okolí a rozhodnuti managementu;  sadu softwarových agentů simulující chováni trhu a poruchy tohoto chování;  sadu agentu simulující rozhodovací procesy managementu. Rozhodovací procesy realizují jednoduchou optimalizaci;  softwarové agenty odpovídají specifikaci FIPA (Foundation for Intelligent Physical Agents) a to minimálně v části komunikace agentů;  software realizující databázi cílů podniku a jeho složek jako parametru pro rozhodo- vání;  modelovací prostředí umožňující nastavovat a definovat agenty okolí a agenty ma- nagementu;  systém oprávnění v modelu s různými rolemi (supervizor, uživatel, atd.); Základní schéma systému uvádí Obrázek 23. Obrázek 23 Základní schéma simulačního systému Zdroj: vlastní zpracování Systém je tvořen regulačním obvodem se zápornou zpětnou vazbou. Agent – řídicí člen reaguje na odchylky zjištěné měřicím členem – ERP systémem pomocí zadání se snaží dosáhnout stanovených cílů, uložených v databázi cílů a rozpočtů. Jako řízené členy působí skupina Agentů – obchodních zástupců, Agent – marketingová kampaň, Agent – nákupčí Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 59 případně Agent – jednoduchý model výroby. Podnik dodává na trh představovaný skupinou Agentů – zákazníků a Agenty – dodavateli. Agenty obsahují určité koeficienty, které specifikují jejich chování. Hodnoty těchto koeficientů, případně některé další údaje ovlivňující chování agentů jsou soustředěny v databázi parametrů agentů. Přesná definice těchto údajů proběhne v období přípravy návrhu řešení. Systém je řízen grafickým uživatelským prostředím - speciálním agentem. Agenti dodavatelé hodnotí své nabídkové ceny obdobně jako zákazníci „dodavatelská produkční funkce". 1.9.3.1 Prodej Prodané kusy se řídí zejména cenou.  Zákazník dostává nabídku od obchodního zástupce. Tuto nabídku vyhodnotí vzorcem „produkční funkce". Výsledkem je počet kusů, který by zákazník od obchodního zástupce koupil a pošle tuto zprávu obchodnímu zástupci (OZ). OZ srovná počet kusů se zadáním, provede úpravu ceny a pošle nabídku znovu. Cyklus se opakuje, dokud není dosažen počet kusů, který má zástupce docílit a poté se provede prodejní zakázka v ERP včetně fakturace. Tyto cykly proběhnou u všech zákazníků daného OZ a produktu a poté se opakují postupně u všech OZ. (parametr – které zákazníky má OZ, které produkty prodává).  Systém provede závěrku za období a vypočítá rozdíly. Řídící člen rozhodne podle strategie o postupu v dalším cyklu. Uvažované strategie jsou následující.  Strategie Y – snaha dosáhnout co největšího prodeje kusů pomocí změny ceny C, tedy změnou — snížením povolené marže a tedy stanovením minimální možné ceny.  Strategie p – zvýšit potenciál obchodníků vypsáním cílových odměn a provizí; tato změna znamená zvýšení parametru p v databázi parametrů obchodníků.  Strategie M – vyřazení neproduktivních obchodníků s následným uplatněním strategie p; tato strategie znamená vyřazení OZ s nejmenším obratem celkem, přerozdělení kvót a změnu OZ u zákazníků, dále změnu p v „produkční funkci" o určitou hodnotu (parametr modelu měnitelný při ladění simulace).  Strategie Z – přijetí úkolu ve snížení nákladů se současným uplatněním strategie Y. Stanoví se maximální nákupní cena dle produktů a provede se nákupní cyklus. Pokud je úspěšný, adekvátně se sníží minimální marže (prodejní cena produktu). Pokud se snížené ceny nedosáhne, je tato strategie označena jako neúspěšná.  Strategie 'L – provedení marketingové akce s cílem zvýšit podíl na trhu. Výsledkem je zvýšení počtu zákazníků o určité procento (parametr simulace), což zvýší počet zakázek. Výpočet počtu zákazníků provede marketingový agent; noví zákazníci se zavedou do ERP; rozdělí se rovnoměrně na OZ (zjednodušení). Akce se provádí na jeden produkt. Pokud při fakturaci prodejních zakázek dojde k nedostatku zboží ve skladě, provede se objednávka dle platných cen s určením doby dodávky dle parametru zboží nastaveného TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 60 v ERP. Po zvýšení stavu informuje agent nákupčí agenty OZ a zakázka se spustí znovu. Je možné také formulovat nákupní objednávky na prodejní zakázky s úplným cyklem dodavatelských nabídek. 1.9.3.2 Nákup Cílem je dosažení stanované nákupní ceny. Dodavatelé prodávají výrobky se stanovenou marží (parametr pro každý výrobek a jednotlivého dodavatele). Při vytvoření nového agenta – dodavatele, se tento musí zanést do ERP jako firma – dodavatel. Při uplatnění výše uvedené strategie Z řídící člen bud' zadá všeobecné procentuální snížení nákupní ceny, nebo zadá pro nový výrobek. Agent nákupčí spustí výběrové řízení a vybere dodavatele s nejlepší cenou. Podle stavu skladu provede ihned objednávku, nebo tuto objednávku provede po dosažení minima skladu. Nákupčí vypisuje výběrové řízení na všechny dodavatele (výrobek, kusy). Tito po kontrole svých parametrů (prodejní cena, marže, případně znak, že výrobek tento dodavatel neprodává) nabídnou nejprve zboží za stanovenou cenu. Počet kusů definuje nákupní „produkční funkce„. Nákupčí srovná nabízenou cenu se svým zadáním a zakázku přijme nebo odmítne. Odmítne-li všem dodavatelům, nebo nabízený počet kusů nestačí, proběhne u dodavatelů úprava ceny obdobně jako u prodeje. Cyklus se opakuje, dokud není dosažen stanovený počet kusů a alespoň jeden z dodavatelů má marži větší než nula. Pokud se dodavatel nenajde, upraví se parametry jednoho nebo více agentů dodavatelů (GUI) Při funkcionalitě nákupu zboží pamatovat na možné rozšíření systému směrem k vý- robě. 1.9.3.3 Platba Zákazník i nákupčí má v sobě zabudovány funkce plateb, které probíhají v ERP a jsou vstupem pro výpočet cash flow. Penalizace není uvažována. 1.9.3.4 Poruchy Agent poruch na trhu simuluje hodnotu koeficientů produkční funkce u zákazníka a korekční funkce u OZ. Je založen na generátoru náhodných čísel. 1.9.4 ZOBECNĚNÍ POSTUPU MODELOVÁNÍ Na Obrázek 24 uvádíme hrubé schéma postupu při zobecnění procesního a hodnotového modelování s využitím agentů. Výchozím bodem je zde stanovení hodnotového systému a hodnotového řetězce podniku. Výsledkem je stanovení jednotlivých transakčních cyklů, které již na první, hrubé úrovni simulace mohou představovat jednotlivé regulační smyčky. Dalším krokem je formulace REA hodnotových modelů na operační úrovni REA. Dynamizací jednotlivých REA modelů se dosáhne přiblížení k procesnímu modelu. Současně se Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 61 definují zprávy, které proudí mezi jednotlivými objekty simulace. Na základě těchto výsledků lze již na zvolené úrovni rozlišení stanovit ty regulační smyčky, které budou modelovány a jejich jednotlivé členy. Následuje stanovení funkcí jednotlivých členů v regulačních smyčkách, což je zadání pro formulaci funkce jednotlivých agentů. Tyto kroky lze v iteracích opakovat a tak postupně zvyšovat úroveň rozlišení nebo komplexnost celého modelu. Paralelně s definicí jednotlivých cyklů a objektů REA se provádí definice položek v databázích entit a relací REA a jednotlivých cílů entit (agentů) obsažených v modelu. Tyto databáze tedy obsahují nejen objekty sytému REA, ale také další údaje a objekty sloužící k definici funkcionality agentů (například údaje k sociálnímu chování agentů, údaje reprezentující vnitřní i externí vlivy a poruchy ovlivňující chování členů regulačních smyček apod.). Obrázek 24 Zobecněný postup modelování podnikových činností s využitím agentů Zdroj: vlastní zpracování Shrneme-li úvahy v této podkapitole, pak můžeme konstatovat, že se na uvedený přístup můžeme dívat jako na zobecnění přístupu používajícího jak procesní tak hodnotové aspekty modelování a simulace podnikových řídicích systémů. Zahrnutí části sociálního chování do simulačního modelu umožňuje v zásadě simulovat také interní faktory a jejich vliv na výsledky podniku. 1.10Přístupy k návrhu a analýze IS Až donedávna se používaly klasické metodiky projektování založené na dvou základních přístupech, jejichž vývoj začal v závěru 70. let a které se dnes dají považovat za v podstatě ukončené: strukturované metodiky a objektově orientované metodiky. Pod pojmem metodika máme na mysli soubor zásad, pravidel, postupů a metod, které zahrnují všechny etapy vývoje IS. K ZAPAMATOVÁNÍ Metoda (z řeckého methodos – doslova "za cestou", cesta za něčím) je postup nebo návod, jak získávat správné poznatky, prostředek poznání. Metoda a systém tvoří podstatu vědy, přičemž systém představuje její obsahovou stránku, zatímco metoda její stránku formální. Systémem míníme uspořádaný celek poznatků či obsahů vědy. Naproti tomu za metodu označujeme v souhlasu se smyslem slova cestu, kterou je tento celek vybudován a získán. „Metodicky“ se zabýváme nějakou oblastí vědy, když ji plánovitě prozkoumáváme, Metoda TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 62 vypracujeme její jednotlivé členění, přiměřeně uspořádáme její dílčí poznatky, logicky je spojíme a učiníme náhlednutelnými. Metodika je obecně pracovní postup (metoda) nebo nauka o metodě. Metodika v oblasti metodologie vědy je metoda vědecké práce. Metodika v oblasti pedagogiky je nauka o metodě vyučování v určitém oboru (teorie vyučování). Ve vývoji software metodika představuje souhrn doporučených praktik a postupů, pokrývajících celý životní cyklus vytvářené aplikace. V tomto oboru velmi často dochází – kvůli nesprávnému překladu z angličtiny – k záměně pojmu metodika za metodologie. Pro řešení dílčích problémů mohou být v rámci nasazení metodiky uplatněny specifické postupy – metody. Metodologie (z řec. methodos, sledování, stopování, od hodos, cesta) je vědní disciplína, která se zabývá metodami, jejich tvorbou a aplikací. Patří do teorie či filosofie vědy a obecněji do epistemologie. Pod vlivem angličtiny se slovo někdy používá i pro metodiku (použitý postup či metodu). Tím se však ztrácí důležitý rozdíl mezi metodami jako nástroji vědeckého bádání a metodologií jako reflexí o vhodnosti či použitelnosti těchto nástrojů. 1.10.1 STRUKTUROVANÝ PŘÍSTUP Metody strukturovaného přístupu vznikaly v průběhu 70. a počátku 80. let a postupně se dále vyvíjely. Při tom prošly řadou změn. Základní charakteristikou strukturovaných metod je, že rozdělují problematiku do menších přesně definovaných činností (metodou shora dolů) a definují posloupnost návaznosti mezi nimi. Výhodou tohoto přístupu je, že se projekt může rozdělit na dílčí části, které se lépe řídí a kontrolují. Druhým hlavním rysem strukturovaných metod je dvojí pohled na modelovanou realitu. Jedním aspektem pro toto modelování je pohled na procesy, jim odpovídající datové toky v systému, druhým, relativně nezávislým pohledem je zobrazení datových struktur. Dalším rysem strukturovaných metod je, že při modelování do značné míry využívají různých grafických metod. Při strukturované analýze a návrhu se používají 3 hlavní nástroje: diagram datových toků DFD ilustrující funkce systému, diagram entit a vztahů ERD zobrazující datové prvky a vztahy mezi nimi a diagram přechodů STD, které se koncentrují na chování systému v čase. Pro popis toho, jaké informace se v systému užívají a mění a jak se s nimi pracuje, je nutné také používat slovník dat DD a specifikaci procesů. Dokumentace analýzy a návrhu je prezentována:  v grafickém provedení – sadami různých diagramů. Slovní doprovod slouží více jako příručka k diagramům než jako vlastní specifikace;  v samostatných oddílech, tyto oddíly mohou být používány nezávisle na sobě;  dokumenty s minimem redundantních údajů, což umožňuje zavádět změny do specifikace pouze jednou. Metodika Metodolo- gie Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 63 Jednou z výhod strukturovaných metod je možnost využívat v projektové práci i méně zkušené pracovníky, protože dokumentace analýzy a návrhu systému je dostatečně přehledná a názorná. V podstatě uzavřený vývoj strukturovaných metod a jasná definice používaných nástrojů umožnila vývoj nástrojů softwarového inženýrství a jejich automatizace (CASE – Computer aided software engineering). Mezi hlavní používané CASE nástroje umožňující strukturovaný přístup patří např. Oracle Designer. Existují i další nástroje podporující jak strukturovaný přístup, tak přístup objektový (viz níže). Postupně však strukturované metody narážely na hranice svých možností. Původní požadavky definované v 70. letech, které vyžadovaly přesnou definici uvedených návazností v celém projektu, se postupně staly nevýhodou těchto metod. Tento přístup totiž vedl k nekončícím změnám a špatné udržovatelnosti projektů. Stav strukturovaných metod a jejich změny za poslední léta obšírně shrnul Yourdon ve své publikaci Just enough structured analysis (2006), která představuje jeho doplněné a modernizované základní dílo Modern Structured Analysis z roku 1989. 1.10.2 OBJEKTOVĚ ORIENTOVANÝ PŘÍSTUP Objektově orientovaný přístup, rozvíjený od poloviny 80. let minulého století, je založen na objektech. DEFINICE Objekt je určitý prvek v systému, který vykazuje vlastní chování (reakci na vstupní impulsy - metody) a má určité vlastnosti (atributy). Objekty, které mají stejné chování a obdobné či stejné vlastnosti tvoří třídu objektů. Dalším charakteristickým rysem objektového přístupu je, že objekty nižší úrovně dědí vlastnosti objektů úrovně vyšší. Pro znázornění vztahů mezi třídami se používají různé druhy asociací. Model navrhovaného systému je tvořen sítí různých tříd spojených asociacemi. Na rozdíl od strukturovaných metod se objektově orientovaný přístup nezaměřuje na dekompozici funkcí, nýbrž vychází z identifikace objektů a jejich tříd. Vývoj objektově orientovaných metod (např. Rumbaugh et al., 1991; Booch, 1994) v počátku 90. let minulého století vedl k jejich značné rozmanitosti. V polovině 90. let se objevil Unified Modeling Language, který se v současné době stal de facto standardem pro zápis objektově orientovaných modelů. Popis UML v jeho tvaru z poloviny roku 2004 uvádí Rumbaugh et al., (2004). Také v rámci objektově orientovaného přístupu se používají různé diagramy pro znázornění reality. Vzhledem ke značnému počtu objektových metod však existuje celá řada diagramů. Prakticky všechny metody však používají diagram tříd – znázornění tříd Objekt Třídy a asociace UML dia- gramy TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 64 a vztahů mezi nimi, diagram objektů – objekty a jejich vztahy (interakce) a stavové diagramy – diagramy stavů a akcí probíhajících v jednotlivých stavech. Vývoj objektově orientovaných přístupů se stal výzvou pro přípravu softwarových nástrojů CASE. Avšak tyto nástroje většinou také podporují strukturovaný přístup. Jedná se zejména o podporu diagramů datového modelu. Datové modely mohou být tvořeny z diagramů tříd, nebo vygenerováním z existující databáze. Mezi nejznámější CASE nástroj založený na objektovém modelu patří produkt Rational Rose. V poslední době se začínají prosazovat metodiky využívající obchodní vzory a související ontologie. Předním představitelem tohoto přístupu je výše popsané modelování pomocí sytému REA. Stále více se také prosazují agilní metody projektování. KONTROLNÍ OTÁZKA Jaký je hlavní rozdíl mezi strukturovanými a objektově orientovanými metodami analýzy a návrhu IS? 1.10.3 PROTOTYPOVÁNÍ A AGILNÍ METODY ANALÝZY A NÁVRHU Vývoj IS je zpravidla spojen s vysokými náklady a poměrně dlouhým obdobím přípravy a zavádění. Časové i finanční obtíže vyvolané důsledným využitím strukturovaných i objektových přístupů vedly nejprve k tomu, že se v průběhu realizace projektu přistoupilo k technice prototypů. Technika prototypování patří do skupiny iterativních metod vývoje IS. Myšlenka prototypů je založena na rychlé realizaci určité základní funkce, která je předvedena budoucímu uživateli. Může se jednat například o prototypy rozvržení hlavních obrazovek a způsobu jejich využívání, nebo o prototypy funkcí systému v jejich základním tvaru apod. (nezaměňovat s prototypy funkcí v programování). K výhodám prototypování patří zejména:  včasné zapojení uživatelů do přípravy systému a získání jejich pozitivní motivace;  možnost dolaďovat systém tím, že se nejdříve testují hlavní funkce a podle připomínek uživatelů se jejich detailní funkce přizpůsobují uživatelským potřebám;  vedení projektu má větší přehled o postupu a plnění jednotlivých pracovních kroků. Použití techniky prototypování však v sobě skrývá i určitá rizika:  při nedostatečném naplánování může dojít k neorganizovanému vývoji, kdy se požadavky uživatelů zavádějí bez vazeb na jiné části systému nebo se porušují již odzkoušené funkce. Tím mohou stejně jako později v etapě testování vznikat sekundární chyby; Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 65  uživatel může mylně dojít k závěru, že systém je již téměř hotov a podceňuje fázi testování;  často dochází k tomu, že je nedoceněna práce na dokumentaci;  je zde určité riziko, že uživatelé své připomínky k prototypům mohou považovat za chyby sytému. Tím může vzniknout negativní motivace. Od techniky prototypování je již jen malý krok k myšlence agilních přístupů k zavádění IS. Hlavní myšlenkou agilního přístupu je co nejrychlejší vývoj jádra systému, diskuze s budoucími uživateli a následná úprava vyvinutého produktu na základě reakce zákazníka na předložený návrh. Agilní technika není v rozporu s tím, co jsme již uvedli výše, protože se opírá zejména o následující principy:  iterativní vývoj IS. Těchto iterací může být provedeno větší množství v co nejkratším čase;  předem připravené testy. Při každé iteraci je produkt podroben testování. Příprava testů musí být velice pečlivá, aby se zabránilo sekundárním chybám v již otestované předchozí verzi;  co nejširší komunikace vývojářů a budoucích uživatelů. Technikami agilního programování se zabýval např. Kadlec (2004), který srovnal tradiční metody projektování a zavádění IS s agilními metodikami jako jsou Extrémní programování, SCRUM a další. Ve stručnosti se zde zmíníme o posledních dvou technikách. 1.10.3.1Metodika SCRUM Název této metodiky není žádná zkratka, ale anglické slovo pro „mlýn" — pojem v rugby. V pozadí názvu stojí zásada, že projekční tým se přesunuje k cíli společně. Metodiku navrhli Japonci Hirotaka Takeuschi a Ikujiro Nonaka v roce 1986 jako přístup, který by měl zrychlit rychlost a pružnost zavádění nových procesů. Jméno SCRUM dostal přístup v roce 1991 od jiných autorů. Podstatné v této vedoucí agilní metodice je, že projekt realizuje určitý tým, ve kterém jsou přiděleny jasné role. Další podstatnou vlastností je, že celý projekt je rozdělen do malých přehledných částí, zvaných SPRINT, trvajících 15 - 30 dní, v průběhu kterých řešitelský tým realizuje určitý přírůstek hotového software. Obsah jednotlivých fází sprintu se vybírá ze zásobníku úkolů (product backlog). Základní myšlenkou SRCUM je fakt, že v podstatě jakýkoli uživatel může změnit svůj požadavek dříve, než je původní požadavek realizován – fakt, který je důvěrně znám všem tvůrcům IS. V průběhu každého sprintu je organizováno setkání řešitelů, kde tito referují o tom, co za uplynulý den udělali a co hodlají udělat, případně s jakými se setkali problémy při realizaci denních cílů. Nečlenové týmu se mohou účastnit, nedostanou však příležitost k diskuzi. Toto setkání nemá trvat déle než 15 minut a všichni při něm musí stát, aby se zabránilo dlouhavým diskuzím. V průběhu posledních let se ukázalo, že metodika SCRUM se může použít k řešení řady problémů i mimo oblast vývoje IS. Agilní pří- stup Sprint TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 66 1.10.3.2Extrémní programování Tato metodika nezavádí nějaké převratné změny do stávajících metod a technik, dovádí však jejich použití „do extrému". Pojem extrémní programování zavedl Beck v roce 1999 (1999, 2002). Extrémní programování se opírá o důsledné, až do extrémů dovedené provádění jinak známých postupů. Tyto postupy se liší podle toho, jde-li o plánování dalšího postupu, návrh jednotlivých modulů nebo přímo programování a testování. K hlavním principům extrémního programování patří: Aktivní účast zástupce uživatele. Požadavky uživatele se shromažďují do „User stories".  Iterativnost postupu.  Neustálé využívání zpětné vazby, maximální komunikace v projektovém týmu, neustálé testování jednotlivých modulů a vlivu změn na celkový výsledek, komunikace s uživatelem.  Maximální jednoduchost, programuje se jen to co je v daný moment potřebné, neustále se zkoumá, zda by mohla existovat ještě jednodušší varianta řešení.  Začíná se programovat od jednotkových testů. Podle jednotlivých úrovní projektu lze tyto zásady popsat následovně. Na úrovni pláno- vání:  Projekt je rozdělen do iterací; každá iterace začíná plánováním dalšího postupu.  Plánování probíhá na krátkých projektových schůzích. Aby se zabránilo dlouhých diskuzím, je doporučeno konat tyto schůze ve stoje. V průběhu plánování zákazník – uživatel stanovuje priority prací a programátoři odhadují čistý čas na provedení úkolu. Délka plnění úkolu by neměla přesáhnout 3 dny.  Na projektových schůzích se také měří rychlost, s jakou vývoj probíhá, a probíhají příslušné úpravy plánu.  Neustále se obnovují časové harmonogramy a plánují testy. Na úrovni návrhu modulů:  Probíhají neustálé testy, zda návrh programů odpovídá zadání.  Diskutují se a realizují se takové změny v programech, kdy se jejich funkčnost nemění, ale dochází k maximálnímu zjednodušení kódu programu, tím se zajišťuje čitelnost a udržovatelnost (refactoring).  Nepřidává se určitá funkčnost předčasně — realizuje se nejnutnější kód, tím se vylučují změny a testy, které v danou chvíli nejsou nutné. Při vlastním programování:  Stejný modul programují dva programátoři, kteří sedí u jednoho počítače. Diskuzí dvojice nad tvořeným programem se vyloučí chyby a dosáhne zjednodušení kódů.  Krátké iterace – provede se jedna změna v programu a ihned se ověřují výsledky. Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 67  Zdrojové kódy jsou vlastnictvím všech zúčastněných programátorů, všichni jsou společně zodpovědní za výsledek.  Neprovádí se žádná optimalizace, jestli má optimalizace proběhnout, pak se provede na konec.  Integrace napsaných kódů do existujícího řešení provádí v jeden okamžik pouze jedna dvojice programátorů – tím se vyloučí diskuze, ze kterého kódu vznikla případná chyba. Integrace se provádí co nejčastěji.  Na počátku se nepíše zdrojový kód řešení, ale připravují se jednotkové testy modulů.  Jednotliví programátoři ve dvojicích se obměňují. Při testování:  Programy se neustále testují, testovací moduly patří k vlastnímu aplikačnímu kódu.  Uvolnění kódu pro další použití je možné pouze při úspěšném průběhu předem napsaných testů.  Výsledky testů se neustále zaznamenávají a dokumentují.  Extrémní programování významně snižuje následující rizika vývoje aplikačních mo- dulů:  Účast uživatelů a princip iterace snižuje rizika, že vzniknou objemné knihy s projektovou specifikací, kterým nikdo nebude rozumět a nelze je udržovat v aktuálním stavu.  Obměna programátorů ve dvojicích snižuje nebezpečí monopolu na znalosti u předních programátorů, kteří mají často tendenci si některé vědomosti ponechávat pro sebe. Na druhé straně však praxe ukazuje, že uvedené principy agilních metod nemusí vyhovovat všem zákazníkům, nebo že personál dodavatele pro tuto metodu nedozrál, případně ji odmítá. Zde tedy nelze zacházet do extrémů v tom smyslu, že zákazníkovi „natlačíme" nové moderní metody a tím již předem zhoršíme úroveň komunikace v projektu. 1.10.4 ASPEKTOVÉ PŘÍSTUPY Aspektové přístupy se vyvíjejí zhruba od poloviny 90. let. Přestože v zásadě využívají myšlenky objektového programování, bývají často označovány za „post objektové" přístupy, což je dáno dobou jejich vzniku. Vznik aspektového programování byl vyvolán potřebou modularizovat často se opakující části programového kódu, které se nacházejí v různých místech aplikací. Jako klasický případ se uvádí potřeba logování operací prováděných nad daty. Takové části bývají zpravidla označovány za „záležitosti" – anglicky concerns a jejich „rozptýlený" výskyt v aplikacích vede k jejich označení „crosscutting concerns". (pozn. V anglické literatuře se také uvádí, že tyto bloky jsou zašmodrchány — tangled v různých částech obchodní logiky programu). Oddělení jednotlivých „záležitostí" do programových bloků (modulů), které lze vícenásobně a nezávisle použít v různých částech TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 68 aplikací je tedy základem aspektového programování, tyto moduly bývají označovány za „aspekty". Při klasickém aspektovém programování se nejdříve vyhledají nezávislé „crosscutting concerns" – například opakující se transakce nad databázemi, jejich logování, bezpečnostní procedury, apod. Poté se naprogramují kódy jednotlivých aspektů a tyto kódy se připojí k odpovídajícím modulům technikou „weaving" – spřádání. Teprve poté se provede případná kompilace. Vzniklý modul obsahuje jak obchodní logiku, tak programové kódy aspektů. Nejznámějším programovacím prostředkem pro realizaci aspektů je jazyk AspectJ, který vyvinul Georg Kiczales et al. (1997) ve vývojovém středisku firmy Xerox. Technika použitá v případě AspectJ je založena na tom, že k běžícímu programu může být v určitém bodě připojena určitá modifikace „advice" (filtr), která běh programu změní. Bod připojení se nazývá joinpoint a vlastní provedení modifikace může proběhnout před dosažením bodu připojení, v jeho průběhu nebo po něm. Více informací o této metodě lze nalézt např. v práci Kiczalese (2001) nebo Pícka (2004). Klasický přístup k aspektově orientovanému programování rozvinuli pracovníci IBM Harrison a Ossher (1993), kteří navrhnuli pravidla subjektově orientovaného programování. Cílem subjektově orientovaného programování je tvorba vzájemně spolupracujících systémů. Pod subjekty se rozumí nezávisle vytvořené aplikační moduly, (bloky), které mohou existovat samy o sobě nebo mohou být spojovány dohromady podle určitých (subjektivních) pravidel. Míra spojení nebo spolupráce subjektů může být volná až velmi těsná. Podle této metody se tedy aplikační doména rozdělí do subjektů, např. metod ukládání dat. Subjekty se podle doménových pravidel spojují do jedné aplikace. Subjektově orientované programování lze považovat za doplněk objektově orientovaného programování, který umožňuje řešit problémy vznikající při vývoji rozsáhlých aplikací nebo při integraci vzájemně spolupracujících aplikací. Stručný přehled podstaty subjektově orientovaného programování z hlediska autorů celé myšlenky lze nalézt v práci Osshera a Harrisona (1995). Zajímavé využití aspektového přístupu v oblasti programování hlavní aplikační logiky uvádí Hrubý (2006). V každé aplikaci lze vysledovat celou řadu částečných modulů, které plní obdobné úlohy. Na rozdíl od aspektů v klasickém pojetí jde o řádově větší objekty. Stále však se jedná o menší objekty, než ty, se kterými uvažuje SOA. Jako příklady lze uvést číslování. Číslování (identifikace) se týká zákazníků, čísel zboží, čísel zakázky atd. Pro tento typ lze připravit sdílenou aplikaci podle vzoru „Identifikace". Tento vzor definuje Hrubý jako aspekt. Protože podle konkrétní firmy se pravidla číslování (identifikace) vždy liší, musí být tento vzor (aspekt) konfigurovatelný pro konkrétní běh dané aplikace. Takových vzorů a jim odpovídajících aspektů lze definovat celou řadu. Na Obrázek 25 je uveden framework zajišťující pružnost a konfigurovatelnost řešení s využitím aspektového přístupu pro skupinu identifikátorů. Framework zavádí dvě úrovně abstrakce:  úroveň typu aspektu (abstraktní třída);  aplikační model (třída). Subjekty Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 69 Na úrovni typu aspektu se definují typy aspektů a metadata, která mohou být použita u aspektů na úrovni aplikačního modelu. Na druhé úrovni je zapouzdřena vlastní logika aspektu a jsou definovány vlastnosti, které lze nastavit při vlastní konkrétní parametrizaci aplikace. Uvedený přístup lze realizovat poměrně jednoduchými prostředky, které na úrovni typů aspektů využívají abstraktní třídy a na úrovni aplikačního modelu odpovídající třídy a metody. Vlastní instance tříd z úrovně typů aspektů představují jednotlivá nastavení, která proběhnou při běhu dané aplikace (například změna konkrétního identifikátoru). K ZAPAMATOVÁNÍ Metadata (z řeckého meta- = mezi, za + latinského data = to, co je dáno) jsou data, která poskytují informaci o jiných datech. Příkladem je katalogizační lístek v knihovně, obsahující data o původu a umístění knihy: jsou to data o datech v knize, uložená na katalogizačním lístku. Metadata mohou sloužit např. k snadnému vyhledávání knih. Metadata můžou obsahovat jak informace o vlastních datech, například počet stran knihy nebo rozměry obrázku, tak i informace o kontextu, například autora, datum pořízení, přístupová práva nebo druh komprimační metody. V principu nezáleží na tom, zda jsou metadata oddělena od dat, jako v případě katalogizačních lístků, spojena s daty (v souboru) na odděleném a určeném místě (nazývaném hlavička), jako např. ID3 tagy dále, nebo promíchána s daty, jako HTML nebo XML tagy. Metadata jsou strukturovaná často pomocí tagované reprezentace a někdy hierarchicky. Struktura metadat (a formát) je v mnoha oblastech a aplikacích dohodnut až standardizován. Pro jiného uživatele mohou být metadata data, se kterými pracuje. Například pro správce sítě můžou být metadata v logu o spojeních vlastní data, která analyzuje. 1.10.5 SHRNUTÍ PŘÍSTUPŮ K PROJEKTOVÁNÍ A ZAVÁDĚNÍ INFORMAČNÍCH SYSTÉMŮ Klasickým modelem životního cyklu IS je takzvaný vodopádový (kaskádový) model. V rámci kaskádového modelu probíhá vývoj IS a jeho inovace v předem stanoveném pořadí S minimálními iteracemi. Nezáleží na tom, zda vlastní metodika je založena na strukturovaném nebo objektovém přístupu, podstatné u tohoto modelu je, že jednotlivé fáze vývoje nového IS nebo jeho inovace probíhají za sebou. Realizace několika fází současně se v rámci tohoto modelu neprovádí. Podle metodiky vodopádového modelu se každý projekt skládá z fází:  definice problému; TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 70  analýzy současného stavu problémové oblasti a specifikace požadavků budoucích uživatelů, případně vedení podniku;  návrhu nového systému;  parametrizace, programování a implementace systému;  testování, školení uživatelů;  integračních testů a předávky zákazníkovi;  provozu, údržby a dalšího rozvoje. Obrázek 25 Framework pro nastavení aplikačních aspektů Zdroj: upraveno dle Hruby [HRU 2006] Princip sekvenčnosti jednotlivých fází znamená, že v případě vzniku požadavků na doplnění či změny již dokončené fáze znamená návrat k předchozí fázi a tím i zákonitě zpoždění projektu. Další nevýhodou je nerovnoměrné zapojení budoucích uživatelů do procesu. Často se po definici požadavků budoucí uživatelů setkávají s novým systémem až při testování. Vodopádový model prakticky neumožňuje vícenásobné iterace, nebo iterace přes více fází. To klade značné nároky na kvalitu fáze analýzy a návrhu nového systému, zejména na přesnost formulace požadavků. Vodopádový model také neuvažuje s prototypováním a dalšími aktivitami zapojujícími budoucího uživatele – zákazníka do průběhu Sekvenčnost fází Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 71 přípravy a realizace projektu. Tím vznikají značná časová, kapacitní a finanční rizika. S vyhodnocováním rizik však klasický vodopádový model nepočítá. Proto je tento model považován dnes za překonaný. Druhý základní model – spirálový model používá jiných postupů zejména:  projekt probíhá v cyklech, kdy se jednotlivé fáze opakují, jejich obsah zpřesňuje a současně se vyhodnocují rizika dalšího postupu;  klade se důraz na prototypování jako metodu zapojení budoucího uživatele do průběhu projektu s cílem snížit rizika v oblasti funkcionality a technických vlastností systému;  značný důraz se klade na plánování dalšího cyklu. PRŮVODCE TEXTEM Naše zkušenosti z praxe ukazují, že důsledné uplatněním spirálového modelu naráží na potíže. Jedná se zejména o to, že dodavatelé jen velmi neradi dodávají systémy „na klíč" a s pevnou cenou. K této problematice se obšírněji vrátíme v dalším textu. Znamená to, že zákazník – odběratel nese plné riziko růstu nákladů v případě zpoždění projektu. Proto je zejména ve fázi a návrhu nového systému nutné dojít k dostatečně úplnému řešení, aby bylo možno úspěšně dokončit cenová jednání s dodavatelem bez nebezpečí vícenákladů. Při implementaci již lze používat nové metody prototypování, případně agilní metody, které však musí vycházet z pevného rámce daného definicí cílového řešení (dále používáme název „Cílový koncept"). Aby se dosáhlo tohoto cíle, vidíme jako podstatnou důslednou přípravu Úvodní studie proveditelnosti, jako cílového rámce, kam má projekt dospět a za jakých podmínek. Při zpracování Úvodní studie proveditelnosti doporučujeme modelovat podnik z podhledu hodnotových řetězců a dosáhnout tak definice vícenásobně použitelných modulů, případně provádět simulace jednotlivých subsystémů z hlediska jejich průchodnosti a stability. V současné době se osvědčily zásady platné bez ohledu na použitou metodiku:  Postupný víceúrovňový rozpad oblasti řešení na menší části. Tímto principem se umožní celou problematiku rozdělit do zvládnutelných částí. Vznikne tak nejen prostor pro vlastní řešení na požadované úrovni podrobnosti, ale vytvoří se i základ pro budoucí plánování a kontrolu projektu. o Využití principu tří architektur. Na úrovni konceptuální je jedná o základní zobrazení systému, jeho vazeb s okolím a vazeb mezi jeho prvky. Podle použitých metodik se používají různé hloubky rozlišení a různé nástroje pro zachycení konceptuálních schémat. Na úrovni logické Princip tří architektur TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 72 vzniká zobrazení prvků konceptuální úrovně jazykem zobrazení dat a procesů vyúsťující do navržené architektury celého systému, avšak bez ohledu na konkrétně použité technologie. Na fyzické úrovni je provedeno zobrazení konkrétní realizace systému s použitím konkrétních technických programových prvků. o Použití metod modelování a abstrakce s cílem vytvořit generalizovaný (konceptuální) model celého systému nebo jeho částí. o Rozdělení projektu do etap, případně iterace jednotlivých výsledků analýzy a návrhu S rostoucí úrovní podrobnosti. Z uvedeného vyplývá, že považujeme vodopádový model za překonaný. Naopak doporučujeme na různých etapách přípravy a realizace IS nebo jeho podstatné inovace použít celou řadu podpůrných metod. Jejich shrnutí a naše doporučení uvádí Tabulka 3 Doporučené použití jednotlivých metod ve fázích vývoje a inovace IS. Ve fázi stanovení strategických cílů podniku a Předběžné studie proveditelnosti (pokud se provádí) doporučujeme použití modelování pomocí hodnotových řetězců systému REA, a na jejich základě provedení simulací důsledků rozhodování. Pružnost takových modelů lze podle našeho názoru dosáhnout simulacemi využívajícími softwarové agenty (i když zde zřejmě zbývá značný prostor pro další výzkum). Na úrovni Úvodní studie proveditelnosti se jako plně komplementární jeví modelování pomocí systémů REA a procesní modelování; stejné nástroje lze použít i pro stanovení zadání při výběrovém řízení a také při analýze a přípravě návrhu řešení (Cílového konceptu). Až do této fáze lze projekt provádět podle hlavních zásad vodopádového modelu. Později, při detailní specifikaci, parametrizaci a programování přicházejí navíc ke slovu metody spojené se spirálovým přístupem, zejména prototypování a agilní metodiky, případně je celou realizaci možno doplnit i využitím softwarových agentů. Stejná situaci nastává i v závěru projektu — při testování a školení. Jak vyplývá z Tabulka 3 Doporučené použití jednotlivých metod ve fázích vývoje a inovace IS, mají projektanti a implementátoři jakož i zákazník k dispozici celou řadu metod a postupů, které mohou podle specifických podmínek dodavatelské firmy i zákazníka uplatnit. Na rozdíl od běžně používaných metod v našem přístupu klademe důraz na metody REA opírající se o obchodní vzory jako integračního pohledu na podnikové procesy s možností definice vícenásobně použitelných modulů již od samého počátku projektování. Z hlediska pružnosti změn klademe důraz na modelování a případné simulace pomocí softwarových agentů. Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 73 Tabulka 3 Doporučené použití jednotlivých metod ve fázích vývoje a inovace IS Zdroj: vlastní zpracování OTÁZKY Po prostudování kapitoly byste měli být schopni vysvětlit následující: 1. Jaké vlastnosti má mít ICT, aby přinášela pozitivní efekt v organizaci? (viz 1.2) 2. Co je model, modelování, metoda, metodika, metodologie v oblasti projektování IS? (viz 1.4) 3. Charakterizuje modelování podnikových procesů pomocí hodnotových řetězců a jednotlivé úrovně tohoto modelování. (viz 1.6) 4. Charakterizuje metodu REA a popište její hlavní principy. (viz 1.6) 5. Co jsou to agilní metodiky vývoje IS a popište alespoň dvě z nich. (viz 1.10) 6. Charakterizujte pojem ontologie, doména, BPM a jejich význam pro modelování procesů. Charakterizujte modelovací notace IDEF a UML. (viz 1.4, 1.5) NEZAPOMEŇTE NA ODPOČINEK Po nastudování této rozsáhlé kapitoly z oblasti základních metod a postupů při projektování informačních systémů zasloužíte odpočinek. TEORIE A METODY PROJEKTOVÁNÍ INFORMAČNÍCH SYSTÉMŮ 74 SHRNUTÍ KAPITOLY Kapitola teorie a metody projektování informačních systémů představila základní pojmy z oblasti informačních systémů a jejich životního cyklu. Důraz byl kladen na metodický přístup při analýze a návrhu. Byl podán přehled v současnosti nejčastěji používaných metod modelování podnikových procesů a vývojových metodik. Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 75 2 ŘÍZENÍ PROJEKTŮ IS RYCHLÝ NÁHLED KAPITOLY Nyní přejdeme k problematice vlastního projektování IS. Obecně lze říci, že se projekty IS řídí pravidly a zákonitostmi společnými i pro projekty v jiných oblastech. Konkrétní praxe však ukazuje, že bez ohledu na teorii projektového řízení mají projekty IS některé své zvláštnosti (nemáme teď na mysli krátké úpravy a zadání v rozsahu několika dnů). Projekt I S se zpravidla týká technické, programové a organizační části systému jako celku případně jen jedné nebo dvou uvedených složek a to vždy podle toho zda obnovujeme systém jako celek nebo jeho technickou či programovou část. Z tohoto důvodu mohou mít projekty IS různý obsah i strukturu nad stejným objektem (podnikem) v různém čase (nejdříve se řeší hardware a software až následovně, řeší se jen doplnění hardware atd.), vždy však jedna část podmiňuje druhou a je nějakým způsobem projektem zasažena. Cílem kapitoly je seznámit čtenáře ve výše uvedených souvislostech s přístupy a řízením projektu. CÍLE KAPITOLY Po prostudování této kapitoly budete umět:  definovat jednotlivé kroky a činnosti v rámci přípravy a realizace projektu;  stanovit strukturu organizace projektu;  určit role v projektových strukturách;  určit požadavky na projektový tým;  používat různé styly řízení projektu. KLÍČOVÁ SLOVA KAPITOLY Projekt, projektová organizační struktura, role, projektový tým, řízení projektu. K ZAPAMATOVÁNÍ Projekty IS obvykle vykazují řadu společných rysů, a to bez ohledu na typ podniku, hierarchickou úroveň a typ. Mezi hlavní společné rysy patří následující:  vazba na technologii; Řízení projektů IS 76  bez ohledu na rozsah jsou vždy komplexní;  nemohou být zahájeny a řešeny bez vazby na strategii podniku;  zpravidla obsahují složku hardware a software. To znamená, že alespoň část řešitelského týmu musí mít rozsáhlé znalosti z ICT;  vždy obsahují organizační složku - v projektovém týmu musí být i koneční uživatelé;  řada dílčích úloh může být řešena paralelně a relativně samostatně;  mají vždy tendenci se zpožďovat;  znamenají změnu pro uživatele, a proto se setkávají s rezistencí a po zavedení jsou zpravidla kritizovány;  náklady mají tendenci nekontrolovaně růst;  dodavatelé mají tendenci zmenšovat dohodnutý obsah dodávky, odběratelé mají tendenci měnit své požadavky;  pro dodavatele i odběratele obsahují rizika, se kterými je nutno předem počítat. Při přípravě a realizaci projektů v oblasti IS lze při vší podobnosti používaných postupů vypozorovat, že se v konkrétních detailech a kritériích řízení projektů vyskytují odlišnosti podle toho, zda se na řízení projektu díváme z hlediska zákazníka, či budoucího uživatele nebo z hlediska potenciálního i skutečného dodavatele. To souvisí mimo jiné s tím, že obě strany mají od projektu jiná očekávání uvedená v Tabulka 4. PRŮVODCE TEXTEM I když k dosažení nejlepších výsledků doporučují různí autoři jeden pohled na řízení projektů obecně, nelze skutečnost rozdílných očekávání při projektování IS popřít. Proto se v této práci budeme zaměřovat na rozdílné stránky projektování informačních systémů z pohledu odběratele a dodavatele tam, kde to budeme považovat potřebné. DEFINICE Pro účely této práce chápeme projekt jako souhrn aktivit, zahrnujících plánování a řízení činností směřujících k dosažení stanoveného záměru. Projekt informačního systému je tedy v tomto smyslu souborem činností vedoucích k přípravě a zavedení informačního systému nebo jeho části v podniku a to jak z hlediska podniku (zákazníka, odběratele) tak z hlediska dodavatele. Projekt Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 77 Název projekt bývá často používán ve smyslu projektové dokumentace. Projektová dokumentace je však jedním z výstupů projektu v našem chápání, proto v této publikaci tento pohled nepoužíváme. K ZAPAMATOVÁNÍ Projekt informačního systému lze charakterizovat následovně:  Má jasně stanovený cíl (obměna informačního systému jako celku, změna části informačního systému a jeho uvedení do chodu, změna infrastruktury podporující fungování informačního systému atd.).  Má jasně stanovený počátek a konec. Počátek může být definován různým způsobem. Může se jednat o formální rozhodnutí vedení nebo vlastníka, zahájení prací na studii proveditelnosti, formální zahájení (kickoff meeting) apod. Stanovení konce projektu však již nebývá tak snadnou záležitostí. Není totiž vždy jednoduché oddělit testování a zavádění nového systému od realizace průběžných požadavků uživatelů v první fázi po startu.  Projekt se zpravidla vyznačuje omezenými zdroji a to jak finančními, tak lidskými, což platí zejména pro IS. Každý projekt se vyznačuje stupněm rizika. U informačních projektů je to zejména nebezpečí zpoždění a riziko vícenákladů. Tabulka 4 Očekávání od projektů IS na straně odběratele a dodavatele Odběratel Dodavatel Dosažení očekávaných výsledků zavedení IS. Optimální využití a synergie vlastních zdrojů. Kvalita dodávek. Získání dodatečných zakázek, nebo víceprací v případě změn v průběhu pro- jektu. Dodržení smluvené, případně dosažení nejnižší ceny. Dosažení co nejvyšší ceny. Dostatečná dokumentace a zaškolení uživatelů. Získání části kapacit zákazníka pro některé projekční činnosti. Výhodné platební podmínky. Co nejvýhodnější platební podmínky včetně zálohových plateb. Zdroj: vlastní Z pohledu odběratele není projekt zpravidla něčím, co se periodicky opakuje. V konkrétním podniku mívá jen zřídka určitý vzor v uplynulém období. Charakteristiky projektu IS Řízení projektů IS 78 Z pohledu dodavatele informačního systému je situace jiná. Přední dodavatelé nabízejí celou řadu metodik zavádění a realizace projektu (Cígler (2008), LBMS (2007), S&T (2008) ). Gareis (2005) uvádí přehlednou metodiku diferenciace velikosti projektu a nutných činnost v projektovém řízení, které z velikosti projektu vyplývají. Jako kritéria uvádí důležitost projektu z hlediska strategie. Tuto důležitost spojuje s očekávanou čistou současnou hodnotou výstupů z projektu (Net Present Value - NPV), délkou trvání, potřebnými Lidskými zdroji, náklady a počtem organizací spolupracujících na projektu. Podle rozsahu uplatnění těchto hledisek člení projekty na „malé" projekty, projekty a programy. Podle velikosti projektu stanoví potřebné činnosti v projektovém řízení. Naproti tomu Wolf (2006) zahrnuje všechny projekty z oblasti ICT do informačního managementu, kam zařazuje návrhy, projekty a implementace nových systémů řízení s jejich podporou ze strany ICT. V našem pojetí navrhujeme, aby uvedené členění bylo doplněno o hledisko dopadu na infrastrukturu podniku (vždy projekt), organizaci klíčových dat (vždy projekt) a dopad na systém řízení, s důsledky, které z pohledu organizování vlastního projektu z velikosti projektu vyplývají. 2.1 Management projektů a projektové organizační struktury DEFINICE Projektový management lze charakterizovat jako specifický druh řízení, kdy řídicí pracovníci uplatňují svůj vliv na pracovníky řízené, avšak pouze v rámci projektu. Při tom mohou podle formální definice organizace projektu vznikat různé organizační varianty. V prostředí projektů IS se navíc jedná opět o určitou dualitu mezi řízením pracovníků dodavatele, kde je formální složka uplatňována prakticky bez výjimky, zatímco na straně budoucího uživatele (zákazníka) se může uplatnit celá řada neformálních vlivů. K efektivnímu řízení projektu jsou nutné určité formální organizační struktury. Tyto struktury definují pravomoci a zodpovědnosti vedoucího projektu a členů projektového týmu vzhledem k vedení podniku a stávajícím organizačním strukturám. Teorie řízení projektů uznává obecně několik typů projektových organizačních struktur. Nejprve je třeba zdůraznit, že projekt zavedení nového IS zpravidla není projektem probíhajícím izolovaně od jiných projektových aktivit. Obecně lze konstatovat, že projekt IS spadá do oblasti celkového projektového řízení v podniku. Projektový ma- nagement Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 79 DEFINICE Projektové řízení v podniku má za cíl zabezpečovat realizaci jednotlivých projektů jako soustavy činností, které zajišťují stanovené podnikové cíle. Při tom má projektové řízení za úkol brát do úvahy časová ohraničení (termíny realizace projektů) i omezení zdrojů podniku (skloubení časových a kapacitních možností rozhodujících pracovníků - členů projektových týmů a finančních prostředků) a limitů daných okolím podniku (legislativní rámec, kapacity dodavatelů a subdodavatelů aj.) Racionálně organizované projektové řízení v podniku obsahuje zvlášť vydělené činnosti souvisejících s projekty a jejich koordinaci projektů dále i skupiny činnosti zajišťující jejich vlastní řízení. Projekt zavedení IS je tedy jen jedním z řady dalších podnikových projektů. I když v daném časovém období může být tím nejdůležitějším, podléhá organizaci projektových činností v podniku včetně jejich omezení. Z těchto hledisek je třeba zkoumat jednotlivé typy projektových organizačních struktur, jejich výhody i nevýhody. Projektové organizační struktury jsou dány především formálními dokumenty, které stanoví roli a strukturu projektu v rámci projektové organizace v podniku a dalšími dokumenty definujícími vedoucího projektového týmu, členy projektového týmu a jejich základní pravomoci a zodpovědnosti. V případě projektů zavádění IS se jedná o strukturu složenou jak ze specialistů na ICT tak zejména z představitelů rozhodujících uživatelských útvarů, které budou nový systém používat. Velkou roli zde hraje vlastní uspořádání projektového týmu a jeho vazba na existující organizační strukturu v podniku. Při tom je z povahy věci obvyklé, že může existovat jeden typ uspořádání (organizační struktury) projektového týmu u zákazníka (odběratele nového řešení) a jiný typ u dodavatele. Proto se těmto strukturám budeme krátce věnovat. 2.1.1 ČISTÁ PROJEKTOVÁ ORGANIZAČNÍ STRUKTURA DEFINICE „Čistá“ organizační struktura je základním typem projektové organizační struktury projektu. V této organizační struktuře se uvažuje s tím, že na omezenou dobu projektu vznikne zvláštní dílčí organizační struktura s vedoucím projektu, kterému jsou přímo podřízeni členové projektového týmu. Členové týmu jsou na dobu trvání projektu vyčleněni ze svých mateřských (kmenových) organizačních útvarů a předpokládá se, že se po skončení projektu do těchto útvarů vrátí. Projektové řízení Projektové organi- zační struktury Čistá orga- nizační struktura Řízení projektů IS 80 Z hlediska projektování IS má tato struktura na straně zákazníka (odběratele) výhody a nevýhody uvedené v Tabulka 5. Navíc v případě projektů IS zpravidla neplatí, že existuje jasná hranice, která definuje konec projektu a tím i okamžik konce existence projektové organizační struktury. Tabulka 5 Výhody a nevýhody čisté projektové organizační struktury Výhody Nevýhody Členové týmu se mohou plně soustředit na práci na projektu. Členové týmu zůstávají v nejistotě o své pracovní budoucnosti. Jednodušší koordinace časových možností členů týmu. Vedoucí mateřských organizačních útvarů přicházejí zcela o zdroje - své nejlepší pracovníky. Jednodušší komunikace v týmu. Určité odtržení členů týmu může vést ke specifikaci nevyhovující koncovým uživatelům. Relativně nízká tendence prosazovat útvarové priority. Jasné vztahy, zodpovědnosti a pravo- moci. Prakticky neexistuje nebezpečí střetu zájmů. Zdroj: vlastní Projekty IS mají i po realizaci tendenci se dále rozvíjet a realizovat změny požadované po zavedení systému. Tento fakt dále zvyšuje určitou nedůvěru vedoucích pracovníků mateřských organizačních útvarů a tím i nejistotu členů týmu o své pracovní budoucnosti. Na straně dodavatele se tato struktura téměř nevyskytuje. Dodavatelé musí z povahy věci své zkušené pracovníky používat ve více projektech. Ze strany dodavatele bývá zpravidla trvale a plně vyčleněn pouze vedoucí projektu, případně pracovník jeho organizační podpory (na příklad ve formě projektové kanceláře). Klíčoví pracovníci se speciálními znalostmi bývají dodavatelem přidělováni pouze na rozhodující období, kdy je jejich specializace pro projekt vyžadována. 2.1.2 ÚTVAROVÁ PROJEKTOVÁ ORGANIZAČNÍ STRUKTURA K ZAPAMATOVÁNÍ U útvarové organizační struktury je zpravidla jmenován jen vedoucí projektu, v závislosti od velikosti projektu buď s plným uvolněním pro projekt, nebo nad rámec jeho hlavních činností. Projektová struktura bývá složena z členů jednoho útvaru. Používá se pro menší projekty. Útvarová projektová struktury v případě projektů ICT bývá použita zejména v útvaru Útvarová organi- zační struktura Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 81 podléhajícímu CIO k přípravě a implementaci menších projektů a projektů týkajících se technologie nebo infrastruktury zpracování dat a komunikace, jako je inovace Firewall, zvýšení propustnosti sítě a podobných. 2.1.3 MATICOVÁ PROJEKTOVÁ ORGANIZAČNÍ STRUKTURA DEFINICE Maticovou organizační strukturu v klasickém pojetí lze chápat jako matici zodpovědností a problémových oblastí. Tato struktura se však v podmínkách reálného podniku transformuje do tvaru uvedeného na Obrázek 26. Vedoucí organizace Manažer 1 Manažer 2 Manažer 3 Vedoucí projektu Asistent Člen 1 Pracovník Pracovník Pracovník Člen 3 Člen 2 Obrázek 26 Reálná projektová struktura v podniku Zdroj: vlastní K ZAPAMATOVÁNÍ V případě maticové organizační struktury je zpravidla jmenován jen vedoucí projektu, v závislosti od velikosti projektu většinou s plným uvolněním pro projekt. Je však vyčleněna zvláštní projektová struktura určená k realizaci projektu. Tato struktura překrývá stávající trvalé organizační struktury v podniku. Maticová organi- zační struktura Řízení projektů IS 82 Členové týmu zařazení do uvedené struktury však zůstávají příslušníky svých mateřských organizačních útvarů s tím, že jsou pro projekt na určitou dobu do značné části uvolněni. To znamená, že vedoucí projektu nemá prakticky žádnou formální autoritu. Z hlediska zákazníka má tato struktura výhody a nevýhody uvedené v Tabulka 6. Tabulka 6 Výhody a nevýhody maticové organizační struktury Výhody Nevýhody Členové týmu zůstávají členy svých mateřských útvarů — nižší nejistota o budoucnosti a vyšší motivace. Konflikty s vedoucím kmenového organizačního útvaru. Vnitroútvarová komunikace umožňuje lépe specifikovat potřeby uživatelů. Nejsou garantovány zdroje — čas pracovníků v požadovaných časech (na příklad účetní závěrky). Klíčové zdroje útvarů jsou i nadále k dispozici v svých útvarech. Daleko větší zátěž vedoucího projektu z hlediska komunikace. Lepší využití klíčových specialistů pro projekt. Vyšší tendence prosazovat útvarové priority. Zdroj: vlastní Vedoucí projektu při této organizační struktuře musí využívat neformálních nástrojů. Efektivnost jejich využití záleží na odborné kompetenci, informačních výhodách vedoucího projektu oproti partnerům, na jeho mocenské pozici v organizaci a v neposlední řadě i na jeho charismatu. Proto lze tento typ projektové struktury nazvat Gareis (2005) „vlivovou" (influence) organizací projektu. Vzhledem ke členům svého projektového týmu má sice vedoucí projektu jasnou formální autoritu, ani tato autorita však výše uvedená rizika nezmenšuje. Maticová organizační struktura je vhodná u větších projektů s potřebou koordinace činností a využitím znalostí pracovníků z více útvarů. Je používaná u větších projektů v oblasti ICT. Na straně dodavatele se jedná o typickou organizační strukturu používanou při projektech s tím, že útvary mohou být chápány skutečně jako organizační jednotky dodavatele (na příklad konzultanti programátoři, techničtí specialisté) nebo jako jiné paralelně běžící projekty. Na druhé straně přidělováním klíčových pracovníků dodavatele na rozhodující období vzniká, nebo se zvyšuje riziko vyplývající z případných skluzů dílčích etap projektu. Hlavní výhodou maticové struktury jak na straně zákazníka, tak na straně dodavatele ICT je možnost racionálního využití klíčových specialistů jen pro období, kdy jsou v rámci dané etapy projektu nezbytní. Hlavní nevýhoda této struktury oproti čisté projektové struktuře se projeví tehdy, když dojde ke změně nebo posunu projektových termínů. Tehdy může docházet ke konfliktům v přidělování specialistů jak na straně odběratele (na příklad roční účetní závěrka) tak i na straně dodavatele (na příklad náběh jiného projektu). Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 83 2.1.4 ROLE V PROJEKTOVÝCH STRUKTURÁCH Obdobně jako v organizaci podniku existují i v projektové organizaci určité role. DEFINICE Slovem role máme na mysli fakt, že kromě obvyklých pracovních úkolů souvisejících s hlavní (trvalou) organizací podniku, vykonávají členové projektového týmu na straně odběratele další úkoly spojené s projektem informačního systému. Výjimkou by bylo použití čisté projektové organizační struktury, kdy jsou členové projektového týmu trvale určeni jen pro projekt. Tato situace v praxi u projektů IS nenastává. Roli můžeme charakterizovat jako „množinu očekávání", která jsou spojena Splněním této role. Tato očekávání existují ještě než určitá osoba nebo tým roli převezme. Role jsou nezávislé na individuálních osobách, ale jednotlivci mohou použít mnoho způsobů jak roli splnit. Strukturu rolí lze znázornit organizačním diagramem projektu. Hlavní role na straně odběratele a dodavatele uvádí Tabulka 7; v této tabulce nejde o porovnání rolí na straně dodavatel a odběratele, ale o jejich pouhé vyjmenování. Tabulka 7 Hlavní role v projektu IS Odběratel Dodavatel Vlastník projektu (vedoucí organizace, nebo člen vedení) Vedoucí projektu Řídící výbor Konzultant Vedoucí projektu Programátor Vedoucí dílčího projektu Technický specialista systémového software Člen projektového týmu Technický specialista hard- ware Případný externí expert Technický specialista sítí Případný asistent vedoucího projektu Popřípadě specialista pro školení uživatele Zdroj: vlastní Individuální role jsou definovány cíli, úkoly, pozicí v organizaci a přidělenou formální autoritou. U individuálních rolí by se jejich definice neměly překrývat. Obdobně existují i týmové role. Jejich definice však nejsou pouhým souhrnem individuálních rolí, ale jejich Role Individuální role Řízení projektů IS 84 sjednocením na základě projektových cílů. Podle teorie jsou v dobře připravených projektech IS základní individuální a týmové role definovány před formálním zahájením projektu a nezávisí na konkrétních jednotlivcích. V každodenní praxi jsou však vždy některé vlastnosti rolí přizpůsobeny osobám, které jsou pro projekt k dispozici. Tak například, je-li vedením podniku určeno, že vedoucím projektu IS bude osoba, která má vynikající manažerské schopnosti, ale malé znalosti ICT, bude zřejmě vytvořena role technického vedoucího projektu. Definice této role bude obsahovat požadavek znalostí ICT dostatečných pro zabezpečení technologické části projektu. KONTROLNÍ OTÁZKA Uveďte základní vlastnosti a tzv. měkké kompetence, kterými by měli být vybaveni jednotliví členové projektového týmu od manažera až po člena. Při definování týmů v projektech informačních systémů se zpravidla projevují i jisté politické tlaky a tomu odpovídající rozhodnutí. U podniků, skládajících se z několika územně rozdělených filiálek či oddělení se často obsazuje část týmu tak, aby tyto oddělené útvary měly zastoupení v projektové struktuře. Dalším případem bývá snaha začlenit do týmu pracovníka se značnou neformální autoritou s cílem použít jej jako propagátora projektu v kritické etapě testování a zavádění systému. Tyto snahy v sobě skrývají riziko, že se uvedení členové týmu budou zúčastňovat práce jen formálně, případně svými znalostmi nepřispějí k efektivní práci v týmu. Takovou praxi tedy nelze doporučit. 2.2 Týmové řízení projektu IS Týmové řízení projektu IS je součástí celkového řízení a koordinace projektu. Základními prvky určujícími způsob řízení projektu je struktura organizace projektu IS, určení rolí jednotlivých členů projektového týmu, jejich zodpovědností a pravomocí, způsob týmového managementu, koordinace projektového týmu a další aktivity. K ZAPAMATOVÁNÍ Do řízení a koordinace projektu zahrnujeme zejména:  stanovení případně úpravy základní struktury organizace projektu;  všechny aktivity zaměřené na provedení, časování a sladění prací definovaných v projektu; Řízení a koordinace pro- jektu Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 85  komunikaci v projektu; 1. řízení kvality projektu;  marketing projektu;  motivaci členů týmu. 2.3 Základní struktura organizace projektu IS Základní struktura organizace určuje vzájemné vztahy nadřízenosti a podřízenosti pracovníků podílejících se na projektových pracích. Struktura této hierarchie je vždy ovlivněna potřebou a charakterem požadovaných znalostí. Jak jsme zmínili výše, je to na straně odběratele IS obvykle smíšená struktura a hierarchie pracovníků ICT a uživatelů. U dodavatele často převažuje maticová struktura. Zejména na počátku by na straně odběratele měly převažovat odborné znalosti v oblastech zavedení (změn) IS. Na Obrázek 27 je uvedena typická struktura projektového týmu IS pro obchodní firmu. Obrázek 27 Typická struktura projektové organizace pro projekt IS u obchodní firmy Zdroj: vlastní Struktura organizace Řízení projektů IS 86 KONTROLNÍ OTÁZKA Navrhněte projektovou strukturu pro projekt IS u výrobního podniku, jehož model si vytvoříte sami, a uveďte základní rozdílnosti mezi projektovými strukturami u projektu obchodní a výrobní firmy. 2.3.1 VLASTNÍK PROJEKTU V uvedeném příkladu sehrává ředitel firmy i roli vlastníka projektu. Z titulu této funkce sehrává také roli člena Řídícího výboru. Role vlastníka projektu je u projektů IS zcela klíčová. Bez jasně deklarované podpory celému projektu a důsledně sehrávané role člena řídícího výboru je neúspěch projektu IS prakticky jistý. V praxi se však často stává, že důležitost této role není dostatečně rozpoznána. Hlavním cílem této role je prosazení zájmů podniku v rámci projektu cestou řídícího výboru, dodržení celkové podnikové strategie a dosažení správné informovanosti projektového týmu o dalších souvislostech a vazbách projektu. Cílem této role určitě není provádění úkolů za manažera projektu nebo rozhodování o sporech v projektovém týmu. 2.3.2 ŘÍDÍCÍ VÝBOR PROJEKTU Sestává zpravidla z vlastníka projektu, vedoucího projektu, vedoucího projektu dodavatele nebo zástupce vedení dodavatele, finančního kontrolora, případně externího poradce pro řízení kvality. Hlavním cílem této týmové role je kontrola realizace projektu podle zadání. Dále je to kontrola souvislostí se strategií podniku, rozhodování o stěžejních otázkách souvisejících s projektem jako je schválení dodatečných změn a víceprací, dodatečné přidělování zdrojů včetně finančních prostředků, stanovení priorit v případě nutných změn v projektu, stanovení a změny pravomocí, které jsou nutné pro další správný průběh projektu, sledování průběhu financování projektu. Stejně jako u vlastníka projektu není cílem řídícího výboru každodenní koučování manažera projektu nebo řešení kolizí v projektovém týmu. 2.3.3 EXPERTNÍ TÝM U velkých projektů IS se v některých případech používá služeb externích poradců, kteří sehrávají roli expertního týmu. Hlavním cílem této role je působit jako poradní orgán vlastníka projektu a řídícího výboru při vyhodnocování efektivnosti a kvality projektu. V této roli se členové expertního týmu mohou účastnit jednání projektového týmu a navrhovat některá opatření. Základním požadavkem na tuto roli je rozsáhlá zkušenost se zaváděním IS u jiných organizací, znalost problematiky projektování IS, zejména ekonomických souvislostí této problematiky. Vzhledem k požadované kvalitě je tato role značně nákladná a její zavedení do projektu zaslouží důkladnou analýzu a obezřetnost ze strany vlastníka projektu. Vlastník projektu Řídicí výbor pro- jektu Expertní tým Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 87 PRŮVODCE TEXTEM Další role popíšeme poněkud podrobněji ve více souvislostech. Je nutné si uvědomit, že nejde pouze o určení cílů a kompetencí jednotlivých rolí. Jde také o to, jasně specifikovat, co není cílem dané role. 2.3.4 VEDOUCÍ PROJEKTU IS Vedoucí projektu odběratele sehrává centrální roli v celém projektu. Je osobou, která reprezentuje projekt směrem k okolí jak v podniku, tak u dodavatele. Současně sehrává zásadní roli v kontaktu se všemi členy projektového týmu. V této souvislosti je důležité, jaké kompetence a dovednosti osoba určená k vedení projektu má a jak je dovede uplatnit. Pochopitelně jeho hlavní kompetencí je schopnost projekty vést. V oblasti informačních systémů to však není jednoduchá záležitost. Kromě informatických znalostí a kompetencí musí totiž manažer projektu ovládat i další oblasti a techniky. U dodavatele je role vedoucího projektu poněkud jiná. V prvé řadě musí jít o odborníka na projekty IS se znalostí informačních technologií a zkušeností s jejich nasazením v jiných projektech. K ZAPAMATOVÁNÍ Zodpovědnosti vedoucího projektu IS na straně odběratele:  plná zodpovědnost za řízení projektu a dosažení jeho cílů;  výběr členů projektového týmu;  řízení a koordinace počáteční fáze projektu a příprava výběru dodavatele;  plánování, realizace a koordinace veškerých prací na projektu;  koordinace dílčích projektových týmů;  řízení financí projektu, identifikace odchylek a realizace nápravných opatření;  poskytování informací o průběhu projektu Řídícímu výboru a vlastníku projektu;  formulování a předkládání požadavků nad rámec jeho povinností - tato úloha je z povahy projektů IS kritická;  sledování a vyhodnocování nákladů vzhledem k rozpočtu;  vytváření potřebných pracovních kontaktů na všech úrovních řízení;  koordinace spolupráce projektového týmu dodavatele a odběratele;  marketing projektu. Zodpovědnosti vedoucího projektu na straně dodavatele:  dosažení cílů projektu co do obsahu, termínu a nákladů definovaných ve smlouvě o dodávce;  koordinace činnosti konzultantů a programátorů; Vedoucí projektu Řízení projektů IS 88  koordinace spolupráce projektového týmu dodavatele a odběratele;  identifikace odchylek od plánů a realizace nápravných opatření;  poskytování informací o průběhu projektu odběrateli;  formulování a předkládání požadavků na definici víceprací;  sledování a vyhodnocování interních nákladů dodavatele k rozpočtu projektu. Hlavní věcné úkoly vedoucího projektu Úkoly vedoucího projektu se liší podle toho, zda jde o vedoucího na straně dodavatele nebo odběratele. U odběratele:  projednávání souladu cílů projektu IS s vrcholovým vedením;  koordinace a alokace klíčových uživatelů v etapě návrhu systému;  koordinace posouzení návrhu nového systému ve firmě;  koordinace dílčích projektových týmů s ICT týmem v období realizace;  návrh a dodržení časového harmonogramu přechodu na nový systém;  efektivní řízení požadavků na změny dodatečné funkce IS;  cenová vyjednávání s dodavatelem v etapě realizace projektu a jeho změn. U dodavatele:  organizace analýzy a návrhu systému včetně dokumentace;  alokace zdrojů dodavatele dle etap a potřeb realizace IS;  koordinace subdodavatelů;  výkaznictví o provedených pracích;  odhady spotřeby času a důsledků při požadovaných změnách;  sledování termínů a nákladů u dodávek dílčích částí dle projektového časového plánu a rozpočtu. 2.3.5 TYPY MANAŽERŮ ICT PROJEKTŮ Z HLEDISKA ODBORNÝCH KOMPETENCÍ Uvedli jsme, že počet osob vykonávajících roli vedoucího projektu může být jedna až dvě. Toto zdánlivě protismyslné doporučení je vyvoláno specifikou projektů IS a osobnostními typy, které jsou pro vedení tohoto druhu projekt potřebné. V zásadě jsou pro vedení projektů IS vhodné dva osobnostní typy: a) Odborník na ICT Tato osoba má zpravidla značné znalosti s technologiemi používanými v informačních systémech. Většinou se však soustřeďuje na technickou stránku problému, má tendenci Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 89 prosazovat dokonalá řešení a nemívá znalosti z oblasti financování a týmové komunikace. Proto je vhodný hlavně pro menší projekty s výraznou převahou techniky (zavedení LAN, WAN, úpravy existujících programů, změny a úpravy technologií webu apod.) b) Plánovač, komunikátor a koordinátor Tento osobnostní typ bývá menším odborníkem v oblasti ICT, zato však ovládá techniky vedení týmu, marketingu, financování a zejména komunikace. Je tedy vhodný zpravidla pro větší projekty s výraznou potřebou komunikace. Nižší znalosti ICT jej však omezují v dosažení cílů projektu. Nakonec každý projekt IS skončí etapou komplexních zkoušek systému, datových převodů, školení a realizace. Zde jsou specializované znalosti výhodou. V poslední době se spíše prosazují koordinátoři a komunikátoři, podporovaní tak zvanými technickými vedoucími projektů ovládajícími specializovanou ICT problematiku. 2.4 Styly řízení projektu Styl vedení projektu nepochybně ovlivňuje celkovou atmosféru v projektovém týmu. Při projektování IS je styl vedení projektu jedním z klíčových faktorů úspěchu. Je to proto, že styl vedení projektu má vliv nejen na tým, jeho výkonnost a motivaci, ale také proto, že se průběh projektu neobejde bez komunikace s budoucími uživateli. K ZAPAMATOVÁNÍ Za základní faktory, které mají vliv na styl vedení projektu lze považovat:  Vnitrofiremní kulturu. Jiný styl vedení projektu se projeví ve firmě, kde panují autoritativní přístupy k řešení problémů a jiný styl bude pravděpodobně použit tam, kde se klade důraz na komunikaci a pozitivní motivaci pracovníků.  Osobnostní charakteristika vedoucího projektu. Je-li vedoucí projektu spíše technokrat S malými komunikačními schopnostmi, povede tým jinak než komunikátor využívající svých komunikačních schopností k řešení problémů, které by jinak bylo obtížné odstranit běžnými metodami.  Typ projektu. Jedná-li se o kratší projekt spíše zaměřený technicky, bude vyhovovat i styl značně autoritativní. Jde-li však o rozsáhlý projekt, který zasáhne celý podnik, musí se tomu přizpůsobit i styl vedení projektu. V zásadě lze rozlišovat tři hlavní styly řízení projektu:  Autoritativní. Tento styl se projevuje více u dodavatelů. Používá se zejména u kratších projektů s časovým rizikem. Dodavatelé používají tento styl častěji, protože v rámci efektivního využívání klíčových odborníků je nutno dodržovat přesnou koordinaci činností. U velkých projektů IS se používá v krizových situacích, například po výměně vedoucího projektu, který má neúspěšný průběh. Faktory ovlivňující styl vedení projektu Řízení projektů IS 90  Demokratický. Vyznačuje se výraznou delegací pravomocí. Tento styl většinou slaví úspěch v případě projektů, které přinášejí výraznou inovaci a vyžadují značnou motivaci členů týmu. Potřeba tohoto stylu vzniká zejména u velkých projektů IS, kdy je třeba zajistit spolupráci velkého počtu interních pracovníků podniku.  Technokratický. Využití tohoto stylu řízení připadá do úvahy zejména u technologických projektů jako je obnova hardware, změna struktury a parametrů sítí apod. Nevýhodou tohoto stylu je, že naráží často na komunikační problémy S koncovými uživateli IS. 2.5 Vyjednávání v projektech IS Vedoucí projektu má zásadní vliv na vytvoření pozitivního pracovního prostředí v projektovém týmu. Proto schopnost vyjednávání patří ke klíčovým schopnostem vedoucího projektu IS. Praxe totiž ukazuje, že každá organizace má tendenci odmítat změny, které zavedení nového IS přináší. Proto lze očekávat, že se tyto tendence projeví určitým pasivním odporem budoucích uživatelů, vytvářením zástupných problémů, negativní argumentací ostatních liniových a štábních vedoucích a dalšími jevy. Mezi uvedené projevy se nejčastěji objevuje argumentace na téma vícepráce po zavedení projektu. Bývají také zpochybňovány nově zavedené funkce a jejich správnost a kompletnost, dochází k poukazování na důvody neplnění plánovaných ukazatelů z titulu nového systému a k dalším negativně laděným argumentacím. Proto by měl vedoucí projektu IS mít jako základní vlastnosti schopnost dosáhnout konsensu, rozhodnost, otevřenost v jednání, schopnost jasně definovat problémy, požadavky a srozumitelně prezentovat navrhovaná řešení. Při tom se vedoucí projektu IS může opírat o formální a neformální zdroje své autority. Mezi ně patří hlavně:  Autorita z titulu své pozice v podniku - pokud má vedoucí projektu pevnou, jasně definovanou a spolupracovníky uznanou pozici v podniku, je jeho vyjednávání vždy snadnější, než když tomu tak není.  Autorita z titulu vedoucího projektu - tu mu propůjčí hlavně podpora vrcholového vedení podniku. Zde nestačí pouze definovat pravomoci vedoucího projektu na začátku, jeho pravomoci a zodpovědnosti musí vlastník projektu neustále potvrzovat, protože se v průběhu projektu vždy se mohou projevit tendence k oslabení propůjčených pravomocí.  Autorita znalce problematiky - členové týmu v tomto případě respektují úroveň znalostí a zkušeností i schopností vedoucího projektu. Zde může být zdroj určitých problémů v případě, že vedoucí projektu IS není znalcem v oboru ICT. Jak jsme však uvedli výše, může být nižší autorita znalce dokonale nahrazena schopnostmi komunikovat a vyjednávat, případně mocí z titulu pozice vedoucího v podniku.  Vliv společenského uznání - tento vliv je založen na uznání a přirozené autoritě, kterou si vedoucí projektu získal již ve své základní funkci mimo projekt a dále rozvinut získáním autority vyplývající z úspěšného vedení projektu. Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 91 Mezi hlavní témata vyjednávání v projektech IS patří:  Uvolňování budoucích klíčových uživatelů do projektového týmu. Často vznikají konflikty s kmenovými liniovými vedoucími.  S uvedeným tématem souvisí i jednání o prioritách projektu v kontextu každodenní praxe podniku.  Neshody týkající se časového plánu a jeho případných změn. Tato jednání probíhají velmi často v případě problémů dodavatele a omezené dostupnosti jeho pracovníků nebo pracovníků subdodavatele.  Jednání týkající se nákladů projektu. Často dochází ke sporům, zda určité „vícepráce" a s nimi spojené náklady jsou součásti smlouvy o dodávce nebo její rámce překračují.  Koordinace dílčích týmů. Někdy bývá nutné předefinovat rozsah úkolů dílčích týmů a stanovit hranice mezi oblastmi řešenými těmito týmy.  Příprava školení a závěrečných integračních testů. Zde se jedná zejména o uvolnění potřebných zdrojů pro testy a stanovení plánu zaškolení koncových uživatelů. Protože vyjednávání v projektech úzce souvisí s komunikačními schopnostmi a zároveň je jedním z hlavních úkolů vedoucího týmu, měl by vedoucí týmu mít následující osobnostní rysy:  Je schopný a aktivní komunikátor.  Umí se rozhodující mírou se podílet na tvorbě komunikačního prostředí.  Působí jako efektivní koordinátor (moderátor) pracovních porad a diskuzí.  Dokáže naslouchat, zpracovávat, třídit a filtrovat získané informace, aniž by padl do pasti diskuzí o detailech.  Dokáže účinně motivovat (pochvalou, osobní pozorností, provokací profesionální pýchy členů týmu apod.).  Zvládá otevřené a neutrální řízení konfliktů. Uvedené vlastnosti a témata vyjednávání se v odpovídající míře týkají i vedoucích dílčích projektových týmů. 2.6 Projektový tým DEFINICE Projektový tým a dílčí projektové týmy jsou skupinové role, na které se kladou specifické požadavky. Projektový tým má za úkol projekt připravit a realizovat. Hlavní témata vy- jednávání v projek- tech Osob- nostní rysy ve- doucího týmu Projektový tým Řízení projektů IS 92 V případě, že na projektu pracují ještě dílčí projektové týmy, je hlavní úlohou projektového týmu v etapě realizace integrace jednotlivých řešení připravených těmito dílčími týmy. Vedoucím projektového týmu je vedoucí celého projektu. Dílčí projektové týmy pracují na řešení jednotlivých problémových oblastí projektu. Jeden dílčí tým řeší zpravidla otázky infrastruktury (hardware, software, síť, komunikační prostředky atd.). Při zkoumání role projektových týmů musíme odlišit roli týmu jako celku a roli jednotlivého člena týmu. Jen při tomto rozlišení lze analyzovat specifika týmové práce a zvláštnosti související s rolemi jednotlivců V této publikaci se nezabýváme charakteristikou projektového týmu na straně dodavatele, ta je vždy pro konkrétní projekt dána specifikou řešení a smlouvou o dodávce. Odběratel ji tedy s výjimkou kritických situací prakticky nemůže ovlivnit. 2.6.1 ČLEN PROJEKTOVÉHO TÝMU DEFINICE Role člena projektového týmu spočívá zejména v zajištění úkolů souvisejících s věcným obsahem projektu. Člen týmu zpravidla pracuje v rámci dílčího týmu řešícího odbornou problematiku související jeho znalostmi a kompetencemi. Role člena týmu je klíčová, protože bez jeho znalostí projekt nemůže dosáhnout úspěchu. Záměrně se zde nevěnujeme charakteristice role člena týmu u dodavatele. Dodavatel obvykle dodává konzultanta na danou problémovou oblast. Tento konzultant řídí jednoho nebo několik programátorů dodavatel v etapě realizace systému. Pro úspěch činností člena projektového týmu i celého projektu je nutné, aby byly jasně definovány povinnosti a případné pravomoci člena týmu a člen týmu tyto povinnosti a pravomoci jako osobní závazek přijal. Zde se jako velmi důležité ukazuje, aby člen týmu měl představu, jak dlouho bude projekt trvat, jaká omezení pro něj může výkon funkce v projektu znamenat, případně jaká bude jeho pracovní budoucnost po skončení projektu. V souvislosti otázkami členů projektového týmu se řada autorů zmiňuje o skupinovém chování a jeho rizicích (Svozilová (2006), Dolanský (1996), Gareis (2005)) a také o nejistotách členů týmu. Nejistoty členů projektového týmu se v projektech IS projevují výrazně. Změny v IS totiž souvisejí se změnami podnikových procesů. Změny podnikových procesů vždy znamenají změny v činnostech pracovníků, často také jejich úspory. Člen pro- jektového týmu Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 93 K ZAPAMATOVÁNÍ Mezi hlavní otázky či nejistoty lze zařadit následující témata:  Pro koho budu pracovat?  Jaká bude moje role?  Jaké budu mít pravomoci a zodpovědnosti?  Kdo bude mým nadřízeným, vztah k současnému nadřízenému?  Bude to pro mne mít pozitivní přínos?  Jak dlouho projekt potrvá?  S kým budu spolupracovat?  Co bude s mým původním místem?  Jak se na to dívá můj současný šéf?  Zvládnu to, co nato rodina?  Chci to skutečně dělat??? Je na vedoucím projektu, aby v přípravné fázi, kdy se rozhoduje o projektových týmech, ale také v průběhu celého projektu tyto nejistoty dokázal rozptýlit. K tomu však nezbytně potřebuje podporu vlastníka projektu a vedení celého podniku. Firemní kultura, ze které podpora projektu vychází a schopnosti vedoucího projektu se zásadním způsobem projevují na skupinovém chování týmů v projektu a zesilují nebo zeslabují rizika spojená s tímto chováním. Praxe ukazuje, že chování a klima v projektovém týmu a výkonnost tohoto týmu je do značné míry ovlivněno, ne-li přímo určeno chováním „nejpomalejšího" člena týmu. Slovo nejpomalejší zde chápeme nejen co do výkonu, ale také co do schopnosti se přizpůsobovat chování v celé skupině. „Nejpomalejší" člen v zásadní míře ovlivňuje „průměrnou" výkonnost týmu. Ve skupině však působí další osobnostní typy, které k rizikům mohou významnou měrou přispět. Sem patří zejména:  Asertivní až agresivní jedinci - tito mají tendenci prosazovat své názory, čímž klesá ochota projednávat v týmu různá variantní řešení. Absence promyšlených variant zejména v koncepční fázi projektu IS vede zpravidla ke značným potížím a vícenákladům v etapě zavedení.  „Osvícení jedinci — guru" - ti se velmi často rekrutují z oddělení ICT. Mají tendenci prosazovat technokratické názory a ostatní členové týmu jen těžko proti nim hledají argumenty. Své představy někdy prezentují i pro ostatní málo srozumitelnou hantýrkou.  Dominantní členové týmu - obdobně jako asertivní jednici mají tendenci prosazovat jedno správné řešení, prosazují se však více svojí neformální autoritou a členové Chování, klima a vý- konnost týmu Řízení projektů IS 94 týmu přijímají jejich návrhy s důvěrou. Opět zde může vzniknout riziko nedostatečně projednaných variant řešení. Dominantní členové týmu mohou navenek prezentovat iluzi ‚jednomyslnosti" týmu. Eliminace uvedených rizik v projektových jednáních může být velmi těžkým úkolem i pro velmi schopného vedoucího projektu. V projektu jako dočasné organizaci se zpravidla po krátké době vyvine vlastní interní projektová kultura. V prvé řadě se členové projektových týmů více či méně s projektem identifikují. U projektů IS to může být problematické, neboť u řady členů může existovat určitá vnitřní bariéra daná nižšími znalostmi ICT. Proto je důležité na začátku definovat, co je účelem a cílem projektu (mission) a hodnoty, které se v týmu budou považovat za zvlášť důležité (například přesnost v dodržování termínů, pozitivní přístup ke všem členům týmu, pravidla diskuze a komunikace atd.). Výše uvedená témata lze nazírat i z hlediska komunikace v projektu. 2.6.2 KOMUNIKACE JAKO DŮLEŽITÝ NÁSTROJ Komunikace patří k problémům projektového řízení obecně. U projektů IS je tato problematika prohloubena tím, že projektový tým je sestaven z odborníků na různé problémové oblasti podniku a navíc se v něm aktivně účastní odborníci na ICT. Již tedy na stupni verbální komunikace mohou vznikat šumy a neporozumění mezi tím co autor „vysílá" a co ostatní „přijímají". Komunikace probíhá mezi jednotlivými členy týmu, přičemž se musí odvíjet od jejich rolí, kompetencí, cílů apod. Tyto ukazatele jsou obsaženy v Tabulka 8. K ZAPAMATOVÁNÍ Uvádí se, (Dolanský 1996) že projektové týmy bývají mimořádně úspěšné, jestliže jejich členové (citujeme):  jsou přesvědčeni, že vytýčených cílů lze úspěšně dosáhnout;  mají ve vedoucího projektu důvěru a vzájemně spolupracují;  dobře vědí, co se od nich požaduje;  mají své práce dobře naplánované, organizované, koordinované a sledované;  jsou schopni předvídat vznik potenciálních problémů;  místo důvodů, proč něco nelze udělat, hledají všechny možnosti, jak to udělat co nejlépe;  nedělají dvakrát stejnou chybu;  dokáží naslouchat jeden druhému;  dokáží vnímat vnější vlivy, ovlivňující výsledky jejich práce. Interní pro- jektová kultura Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 95 Tabulka 8 Vybrané ukazatele projektového týmu Ukazatel Vedoucí projektu Projektový tým odběra- tele Dílčí projektový tým odběratele Člen projektového týmu Dodavatel Odběratel Odběratel Dodavatel Cílerole Splnit cíle projektu a jeho souvis- losti Splnit cíle projektu podle Smlouvy o dodávce IS Dosáhnout koordinace a synergické efekty v projektu, řešit konflikty mezi dílčími týmy, připravit, projednat a schválit celkový koncept a prováděcí projekt IS, organizovat školení uživatelů, zajistit komplexní testy Řešení a realizace jednotlivých částí pro- jektu. Splnit cíle projektu v zadané oblasti, zajistit transfer svých znalostí do projektu. Správně pochopit požadavky a navrhována řešení Kompetence Schopnost vést projekty, znalost organizace podniku, znalost řešené pro- blematiky, znalost IT Schopnost vést projekty, znalost IT, zkušenosti s obdobnými projekty Znalosti v problémové oblasti, znalosti IT Experti v dané oblasti Zkušenost v řešené oblasti, vhodná je alespoň základní znalost IT Znalosti IT a kompetence v oblasti problémové ob- lasti Osobnostnítyp Komunikátor a vůdce Koordinátor a znalec IT Komunikátor, týmoví hráči, individualisté jsou spíše pře- kážkou Pokud možno týmoví hráči, z povahy věci však individualisté nejsou vý- jimkou Týmový hráč Týmový hráč, komunikátor Conení úkolemrole Práce na obsahu projektu nebo jeho části Práce na obsahu projektu nebo jeho části Řešit obsah jednotlivých problémových oblastí Řešit souvislosti mezi jednotlivými problémovými oblastmi Být jediným expertem na danou oblast Ukazovat své znalosti Zdrojpracovníků Podnikový manažerský tým, případně exter- nista Tým dodavatele, případně exter- nista Budoucí klíčoví uživatelé jednotlivých problémových oblastí jeden až dva specialisté IT vedoucí projektového týmu dodavatele. Budoucí klíčoví uživatelé jednotlivých oblastí - vedoucí dílčích týmů, tým je doplněn budoucími uživateli znalými problematiky, někdy jen na určitou dobu. Interní podnikové útvary Dodavatel, spolupracující firmy Řízení projektů IS 96 Při splnění výše uvedených předpokladů sehrává rozhodující roli vedoucí projektu. K ZAPAMATOVÁNÍ Rozhodující při komunikaci v týmu je, aby se její účastníci pokud možno vyhnuli obvyklým chybám. Na straně zdroje (vysílajícího) jde zejména o:  nepřesné vyjadřování;  nepřipravenost na jednání;  nejistý projev;  komplikované a dlouhé monology (často se to stává odborníkům na ICT technolo- gie);  vyhýbavé odpovědi;  přehnanou kritiku, odsuzován;  podceňování schopností příjemce informace;  nepřipuštění vlastních chyb;  nezájem o problémy druhých; Na straně příjemce často pozorujeme:  nedostatečnou soustředěnost;  zaměřenost na detaily;  neochotu přijmout jiný názor;  nízkou úroveň znalostí dané problematiky;  používání neověřených informací jako protiargumentů (časté zástupné problémy při řešení problémových oblastí IS);  postranní kritiku. Se správně zvládnutou komunikací v projektu souvisí i dobře připravená, organizovaná a prováděná komunikace na dálku. U maticových projekčních týmů, které jsou u projektů IS obvyklé, je komunikace na dálku důležitou pomůckou. U projektů, kterých se účastní členové, jejichž kmenové pracoviště je od centra projektu geograficky vzdáleno, jde o základní formu komunikace. Přesto komunikace na dálku může vyvolat v projektu potíže. Komunikace na dálku může probíhat za pomocí e-mailových zpráv, telefonicky, pomocí technologií Skype nebo ICQ nebo jiných prostředků. Nejčastější formou komunikace na dálku zatím zůstává e-mail . Protože však každý e-mail je formou neosobní komunikace, skrývá v sobě určitá úskalí. Mezi ně patří hlavně:  Odesílá se příliš mnoho zpráv - může se stát, že je člen projektového týmu přehlédne nebo je prostě vůbec nečte. Chyby v komuni- kaci Komunikace na dálku Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 97  Neefektivní rozdělovníky - pokud forma komunikace a struktura příjemců zpráv v projektovém týmu není včas a správně definována, mohou být členové týmu zahlceni zprávami, nebo dostávat zprávy, které ani nemají z určitých důvodů vidět. (například výsledky obchodních jednání s dodavatelem). Rozdělovníky by tedy měly být strukturovány tak, aby dostával informace ten, kdo je potřebuje.  Riziko špatné formulace - sebelépe míněná zpráva může být špatně pochopena. To vede okamžitě k nebezpečí demotivace členů projektového týmu nebo koncových uživatelů. V praxi se osvědčily následující tipy:  určit pravidla používání elektronické komunikace, zejména e-mailových zpráv a zaškolit členy týmu do jejich používání;  dostatečně strukturovat rozdělovníky;  psát co nejkratší zprávy;  přílohy skladovat centralizovaně;  odstupňovat priority;  dobře uvážit použití potvrzení o dodání (přečtení). U intenzivní komunikace může být autor zaplaven potvrzeními a ztratit přehled o vlastních zprávách;  jako bezpodmínečnou nutnost pro důvěru v týmu je nutno uvést automatické oznámení o nepřítomnosti adresáta;  zakázat emotivní komunikace v e-mailovém provoze. 2.6.3 RIZIKA KONFLIKTŮ IS Je pochopitelné, že i velmi kvalitní vedoucí projektů IS musí v průběhu projektu čelit řadě konfliktních situací. Původ a příčiny těchto konfliktů mohou být různé, týkat se dodavatele nebo odběratele IS, případně může jít o konflikt týkající se obou stran. 2.6.3.1 Příčiny konfliktů u dodavatele  Nedostatek času. Dodavatel pod tlakem konkurence nebo přání odběratele přijal nereálný časový plán projektu. Nyní dochází ke zpoždění, což má za následek problémy v alokaci zdrojů.  Koordinace dílčích řešení není dostatečná. Vedoucí týmu dodavatele nedostatečně koordinuje činnosti poradců a programátorů v jednotlivých problémových oblastech IS. Vznikají potíže v projektovém týmu odběratele.  Překročení nákladů. Typickou příčinou je překročení časových plánů. 2.6.3.2 Příčiny konfliktů u odběratele  Nedostatek času na projekt. Členové řešitelského týmu jsou zatěžování úkoly ve svých kmenových odděleních. Hrozí zpoždění projektu. Konfliktní situace Konflikty u dodavatele Konflikty u odběratele Řízení projektů IS 98  Neuvolnění člena týmu liniovým šéfem. Typický problém maticových struktur, když se úkol na jedné straně matice dostane do problému. Hrozí zpoždění dojednaných termínů. Zvlášť problematická je tato situace v etapě tvorby konceptu celého systému.  Cíle podniku se liší od dílčích nebo celkových cílů projektu. Závažná projektová chyba Může vzniknout také přehodnocením střednědobé strategie a taktiky podniku. 2.6.3.3 Příčiny konfliktů mezi členy dodavatele a odběratele  Nedostatečný vzájemný soulad a spolupráce („chemie"). Tato příčina může přímo vést k ohrožení termínu projektu a vyžaduje rychlé řešení ze strany vedoucích projektů na obou stranách. Zpravidla je ji nutno řešit výměnou konzultanta dodavatele, protože na straně odběratele často není jiný pracovník se stejnými kompeten- cemi.  Co je a co není ve smlouvě. Tento konflikt vzniká u projektů se stanovenou pevnou cenou. Tendenci prohlašovat vše za vícepráce mají prakticky všichni dodavatelé.  Dodavatel nás nebere dostatečně vážně. Často zástupný problém ze strany budoucích uživatelů.  Subdodavatelé nefungují - odběratel je kontaktuje přímo. Má-li odběratel pocit, že jsou subdodavatelé špatně koordinováni, může se pokusit o přímý kontakt. Toto je závažná projektová chyba, která může vést i k právním následkům. Generální dodavatel je vždy plně zodpovědný za své partnery. 2.6.4 PRAKTICKÁ DOPORUČENÍ K ZAPAMATOVÁNÍ Z uvedených pohledů se nyní krátce pokusíme formulovat doporučení pro budování úspěšného a stabilního projektového týmu, a to zejména u odběratele. Důležité faktory se projevují již v přípravné fázi a na začátku projektu. Jde zejména o:  Diskuzi o možnosti plnění zadání s danými zdroji a v daném čase. Vedoucí týmu nebo i celý projektový tým bývá na začátku projektu pod tlakem zkrátit termíny při dodržení určitých cenových limitů. Vlastník projektu by měl o těchto záležitostech připustit otevřenou diskuzi, případně si vyžádat stanovisko externího poradce. Vynucené termíny jsou v oblasti projektů IS cestou k nevyhnutelnému neúspěchu projektu.  Budování a tvorba závazku klíčových členů týmu. Klíčoví členové týmu by měli být na samotném začátku projektu osloveni tak, aby se s projektem identifikovali a formálně zavázali k účasti na projektu v určené době a s určeným rozsahem úkolů při jasně stanovených kritériích úspěchu.  Jednoznačnou definici očekávaných výsledků. Viz výše  Popis projektu z hlediska očekávaného výsledku nikoli popis činností. Tento faktor je klíčovým pro identifikaci a motivaci členů projektového týmu vůbec. Někdy je však obtížné cíl projektu IS dostatečně jasně kvantifikovat. Konflikty mezi dodavateli a od- běrateli Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 99  Popis očekávaného cílového stavu jako nástroje budování týmového očekávání cíle.  Zajištění účasti klíčových členů týmu na plánování, na sdílení idejí, úspěchu i neúspěchu projektu. Zde je opět nezastupitelná role vedoucího projektu. Prvotní impuls však musí dát vlastník projektu. Vhodným prostředkem k tomu je oficiální zahájení projektu (kickoff meeting).  Stanovení jasných pravidel komunikace v projektu. Stanovení jasných pravidel motivace členů týmu a to jak ve formě hmotné, tak ve formě různých výhod a výhledů kariérního postupu. PRŮVODCE TEXTEM V etapě průběhu projektu je pro udržení stability a kvality projektového týmu důležité, aby projektová jednání splňovala podmínky kvality komunikace a řešení případných konfliktů v pozitivním duchu. V dalším se zaměříme na věcný obsah projektových jednání a některá jejich úskalí. 2.7 Jednání probíhající v průběhu projektu 2.7.1 OFICIÁLNÍ ZAHÁJENÍ PROJEKTU DEFINICE Oficiální zahájení (kickoff meeting) představuje úvodní jednání projektového týmu společně s vlastníkem projektu a řídícím výborem projektu. Hlavním cílem jednání je veřejné stanovení cílů projektu. V průběhu jednání vlastník projektu stanoví a vyhlásí cíle a organizaci projektu, základní pravidla komunikace v projektu a rozhodující termíny (milníky). Měla by také být vyhlášena pravidla motivace pro členy řešitelského týmu. Pro průběh projektu je důležité, aby na tomto jednání zazněly důvody pro projekt a závazek vedení k podpoře projektu. U dodavatele probíhá kickoff meeting v menším rozsahu, praktická zkušenost ukazuje, že i v tomto případě má svou důležitost. Jde hlavně o motivaci a koordinaci řešitelů ze strany dodavatele. Zahájení projektu Řízení projektů IS 100 2.7.2 JEDNÁNÍ ŘÍDÍCÍHO VÝBORU K ZAPAMATOVÁNÍ Zasedání řídícího výboru je hlavním nástrojem kontroly projektu ze strany vlastníka projektu. Probíhá zpravidla jednou až dvakrát za čtvrtletí, případně dle potřeby. Hlavním bodem jednání je zpráva vedoucího projektu o stavu průběhu projektu, jeho věcném a nákladovém řešení a srovnání s plánem projektu. V případě nutných změn jdoucích nad rámec pravomocí vedoucího projektu dochází k rozhodnutí o povolení nebo zamítnutí požadovaných změn. Řídící výbor také přijímá rozhodnutí o zahájení provozu nového IS. Pokud je projekt podporování externím týmem pro řízení kvality projektu, podává jeho zástupce zprávu o průběhu projektu, ve které se vyjadřuje ke zprávě vedoucího projektu. 2.7.3 JEDNÁNÍ PROJEKTOVÉHO TÝMU K ZAPAMATOVÁNÍ Jednání projektového týmu lze chápat jako základní nástroj operativního řízení pro- jektu. Probíhají podle délky a rozsahu projektu jednou týdně. Hlavní náplň těchto jednání se může měnit podle toho, ve které etapě se projekt nachází a podle celkového stavu projektu. V rámci jednání projektového týmu se projednávají zejména:  varianty řešení, a návrhy na změny postoupené k rozhodnutí z dílčích týmů;  způsoby integrace dílčích částí;  koordinace dílčích týmů pro příští období;  kontrola stavu projektu v jednotlivých dílčích týmech a celkem;  příprava zprávy o stavu projektu pro Řídící výbor projektu;  stav nákladů na projekt a srovnání s plánem;  schválení projektových dokumentů předložených dodavatelem;  návrhy na závažná rozhodnutí pro kompenzaci odchylek  návrhy změn mající dopad na rozpočet nebo termín projektu. Jednání projektového týmu řídí vedoucí projektu. Zde se v praxi projeví jeho komunikační a moderátorské schopnosti při vlastním jednání i při řešení případných konfliktů. Zasedání řídicího výboru Jednání projektového týmu Náplň jednání pro- jektového týmu Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 101 2.7.4 JEDNÁNÍ DÍLČÍCH TÝMŮ K ZAPAMATOVÁNÍ Jednání dílčích týmů mají za cíl rozpracovávat a realizovat vlastní řešení v dílčích problémových oblastech. Projednávají se hlavně následující otázky:  Způsob řešení dílčích úkolů týmu. Sem lze jako typické příklady zařadit: pracovní postupy připravovaného řešení, parametrizace programových modulů, otázky hardware, příprava testovacích variant, řešení návrhů z jiných dílčích týmů atd.  Návrhy změn v dílčích oblastech. 2.7.5 NĚKTERÁ ÚSKALÍ JEDNÁNÍ TÝMŮ V rámci práce týmů se již z povahy věci a složení týmu často objevují různá úskalí jako:  Podcenění přípravy jednání. Jde o chybu vedoucího příslušného týmu. Vede však zcela j i stě k problému při daném jednání.  Absence podkladů. Stává se, že často v časové tísni přijde člen týmu s návrhem, který není dostatečně zdokumentován. Tím může vyvolat neřízenou diskuzi na dané téma a způsobit ztrátu času případně narušit motivaci ostatních členů týmu.  Nedodržení programu. Častá chyba, když se projekt ocitá v časové tísni.  Nedostatečná moderace a kázeň členů týmu. Jde o chybu vedoucího projektu a má většinou stejné následky jako při absenci podkladů.  Míchání témat, která mají být řešena s tématy, která mají být rozhodnuta. Stává se často při rozporech týkajících se integrace dílčích týmů. Opět vede k neefektivnímu jednání.  Nedostatečná dokumentace z minulých jednání. Základní chyba vedoucího projektu zákazníka. Dodavatel zpravidla vede svou dokumentaci z jednání. Ta však může být formulována lehce ve prospěch dodavatele. Pokud dojde k rozporu později, je absence prokazatelné dokumentace velkým handicapem odběratele. Stává se také, že nedostatečně zdokumentované požadavky uživatelů opakovaně přicházejí na přetřes při jednání projektového týmu, což výrazně snižuje motivaci celého týmu. KONTROLNÍ OTÁZKA Liší se něčím úskalí komunikace v rámci jednání týmů při řešení projektů IS od jiných skupinových jednání? V čem byste našli základní odlišnosti? Úskalí jednání týmu Řízení projektů IS 102 2.8 Řízení projektu K ZAPAMATOVÁNÍ Základní výchozí motto: Kdo chce řídit, musí znát! 2.8.1 ČINNOSTI U DODAVATELE Dodavatel v průběhu projektu vykonává následující základní činnosti:  Nastartování projektu (dodavatelský kick off). V rámci nastartování projektu probíhá určení základních organizačních vztahů u dodavatele, určení projektového týmu a vedoucího projektu, hrubá specifikace finančního plánu projektu vycházející ze smlouvy o dodávce a rozhodnutí o přidělení specialistů podle hrubé časové osy pro- jektu.  Zpracování plánu projektu. Dodavatelský plán projektu vychází ze smlouvy o dodávce. Specifikuje členění dodávky do základních funkcí, základní časový plán projektu, plán odpovědností na straně dodavatele a odběratele vycházející ze smlouvy o dodávce a časový plán potřebných finančních zdrojů a řešitelských kapacit. Právě plán nasazení řešitelských kapacit je často úzkým místem dodavatelského plánování, protože se dodavatelů snaží o maximální využití svých špičkových specialistů, kteří zpravidla pracují na více projektech naráz. Plán řešitelských kapacit vychází v etapě analýzy a návrhu systému z hrubého projektového plánu specifikovaného v Úvodní studii proveditelnosti a smlouvě o dodávce, v realizační etapě z podrobného rozpisu prací.  Vlastní práce na projektu.  Práce na dokumentaci průběhu projektu. Obsahuje pořizování protokolů z jednání projektového i dílčích týmů, upřesňování smluvních vztahů v případě nejasností ve smlouvě a zejména dokumentace o proběhlých změnových řízeních. Zajišťuje rovněž archivaci těchto dokumentů.  Řízení práce s odběratelem. Sem patří zejména dodavatelské hodnocení termínů, kvality a nákladů na projekt a organizace řízení odchylek s cílem dosáhnout projektových cílů.  Průběžné hodnocení termínů, kvality a nákladů z pohledu dodavatele. Činnosti- dodavatele Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 103 2.8.2 ČINNOSTI U ODBĚRATELE Základní činnosti odběratele v průběhu projektu lze shrnout následovně:  Nastartování projektu (odběratelský kickoff).  Plánování. Odběratelský plán projektu vychází rovněž z Úvodní studie proveditelnosti a smlouvy o dodávce. V realizační etapě se zpracovává podrobný rozpis prací a potřeb interních řešitelských kapacit.  Organizace a koordinace projektu. Zahrnuje řízení činnosti projektového týmu a dílčích týmů, řízení požadavků na změny, v závěrečné etapě projektu řízení testů jednotlivých modulů a celkových (integračních) testů nového IS a řízení organizace školení koncových uživatelů.  Řízení práce s dodavatelem. Sem náleží hlavně veškerá komunikace s dodavatelem, organizace pracovních podmínek pracovníkům dodavatele, sledování a řízení odchylek v projektu a projednávání jejich řešení s dodavatelem. K ZAPAMATOVÁNÍ Na straně odběratele zpravidla spočívá iniciace a organizace změnových řízení. Větší podíl odběratele se projevuje i při řešení konfliktů a nenadálých situací. 2.8.3 ŘÍZENÍ A ALOKACE ŘEŠITELSKÝCH ZDROJŮ K ZAPAMATOVÁNÍ Alokace řešitelských zdrojů je jednou z kritických činností v rámci projektu IS. Nad rámec alokace zdrojů v jiných projektech je v případě IS nutno brát do úvahy i jiné okolnosti. Mezi ně patří zejména již zmíněný fakt, že se změny IS často potkávají s určitou rezistencí, která se projevuje i při uvolňování zdrojů a zástupnými problémy ze strany liniových vedoucích kmenových útvarů členů řešitelských týmů. Některé útvary, například účtárny mohou uvolňovat své pracovníky jen v určitých obdobích mimo měsíční a roční závěrky. Plánování a alokace zdrojů vychází z:  všeobecného hrubého časového plánu projektu;  návrhu projektové organizace. Činnosti odběratele Alokace řešitel- ských zdrojů Řízení projektů IS 104 a v dalších etapách také z  podrobného rozpisu prací;  harmonogramu projektu nebo jeho dílčí části. K ZAPAMATOVÁNÍ Při alokaci řešitelských zdrojů je nezbytná aktivní účast vedoucího projektu zejména v počáteční etapě, kdy probíhají diskuze s liniovými manažery a kandidáty na účast v projektu. Během těchto diskuzí se konzultuje hlavně dostupnost, kompetence a formy motivace uchazeče. Reálná alokace zdrojů není možná bez závazku všech stran týkajícího se způsobu a rozsahu účasti na projektu. Vzhledem k tomu, že nedostupné zdroje mohou být příčinou zpoždění v projektu s řetězovými následky v dalších etapách projektu a jiných zdrojích, je nutné, aby vedoucí projektu zpracoval alternativní varianty alokace řešitelských zdrojů a to alespoň v hrubé formě. Nástroje pro plánování alokace zdrojů, zobrazení úzkých míst a přetížení specifických zdrojů jsou dnes součástí všech dostupných programových balíků pro řízení projektů. Praktické zkušenosti lze shrnout následovně:  posledních 10% projektu často spotřebují 30% zdrojů;  při obsazování se má začínat od nedostatkových zdrojů pro činnosti ležící na kritické cestě;  posunovat činnosti v harmonogramu je nutno tak, aby bylo dosaženo optimální využití kapacity specialistů;  pokud je využití zdrojů na určitý úsek menší než 50%, lze potřebnou dobu zkrátit na polovinu;  externí dodavatelé často plánují specialisty na více projektů ve stejném čase s cílem maximalizovat fakturaci - problém pro manažera projektu;  hlavní dodavatelé často nemají kontrolu nad zdroji subdodavatelů;  linioví vedoucí někdy úspěšně prosazují realokaci jejich pracovníků pod záminkou ohrožení plnění úkolů. 2.8.4 KONTROLNÍ ČINNOSTI V PRŮBĚHU PROJEKTU IS K ZAPAMATOVÁNÍ Kontrolní činnosti v průběhu projektu IS mají za cíl sledovat průběh projektu po věcné, časové a finanční stránce a připravovat nezbytné korekce a rozhodnutí. Plánování alokace zdrojů Kontrolní činnosti Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 105 Tabulka 9 Popis procesu kontrola v průběhu projektu IS Vysvětlivky: V- vykonává; S – spolupracuje; I- informuje. Interval kontrolních činností závisí od rozsahu projektu, zpravidla se kryje se zasedáním Řídícího výboru projektu. Je však nezbytné, aby se vedoucí projektu věnoval kontrolním činnostem nepřetržitě. Způsob, rozsah a intervaly kontrolních činností se stanovují na začátku projektu. Kontrola v projektu obsahuje celou řadu činností prováděných pracovníky s různými individuálními i týmovými rolemi. V Tabulka 9 uvádíme přehled kontrolních činností založený na modelu Gareise. Z uvedené tabulky vyplývá role jednotlivých účastníků projektu a budoucích uživatelů (relevantního okolí projektu) v kontrole. Důležitým poznatkem uvedeným v této tabulce je, že výsledky kontrolních procesů se stávají podkladem pro marketing projektu. Marketingem projektu se budeme krátce zabývat v jiné části této práce. Intervaly kontrolních čin- ností Řízení projektů IS 106 2.8.5 RIZIKA ŘÍZENÍ PROJEKTŮ IS K ZAPAMATOVÁNÍ Vedle obvyklých rizik, se kterými se setkávají vedoucí projektu, se v projektech IS vyskytují některá další rizika. Mezi ně patří:  Riziko částečných úvazků. Projekty IS zpravidla mají v projektových týmech členy na částečný úvazek, což je dáno maticovou strukturou projektového týmu. Výjimky tvoří zpravidla pracovníci oddělení ICT.  Riziko soudržnosti týmu. Ti členové projektového nebo dílčích týmů, kteří pracují v týmu jen částečně či občas, se těžko sžívají se zbytkem a nedrží krok s projektem, protože jim chybí některé relevantní informace.  Hlavní pracovní náplň je vždy v konfliktu s prací v týmu.  Zpravidla se vyskytují dva nadřízení. Je pochopitelné, že členové tým dávají prioritu svým kmenovým útvarům a úkolům v neprospěch projektu.  Riziko ztráty souvislostí. Pokud se v rámci projektové porady začne prosazovat odborná ICT hantýrka, mohou se další členové týmu „odpojit" a ztratit kontakt s problematikou. V dalších krocích projektu pak vzniká komunikační problém. Riziko kompetencí a zodpovědnosti ICT. Některé úkoly v projektu leží na pomezí mezi problematikou ICT a věcnou problematikou problémové oblasti (útvaru). Pak může v konfliktní situaci zaznít věta typu „na co máme ICT?" K ZAPAMATOVÁNÍ Snižování uvedených rizik patří také k základním kompetencím vedoucího projektu. Zde je však nutno zmínit, že jejich vznik a cesty odstraňování silně závisí na vnitrofiremní kultuře a komunikaci v podniku obecně. 2.9 Motivace členů týmu a projektový marketing 2.9.1 MARKETING PROJEKTU Praktické zkušenosti ukazují, že se při řízení projektu IS nestačí soustředit pouze na obsah a kvalitu projektu. Pro úspěch projektu je nutná trvalá komunikace cílů, obsahu, organizace a výsledků projektu směrem k okolí. Tento fakt nebývá někdy spíše technicky zaměřenými CIO včas rozeznán. Výsledkem jsou pochybnosti o účelu, smyslu, nákladnosti Další rizika řízení pro- jektů Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 107 a přínosech projektu. Nejde jen o to projekt dostatečně prezentovat. I velmi kvalitní projekt ještě nemusí být svým okolím také akceptován. DEFINICE Marketing projektu může být definován jako zprostředkování informací o projektu dovnitř podniku. Marketing projektu je v prvé řadě úkolem vedoucího projektu a vedoucích dílčích projektových týmů. Při nedostatečném marketingu projektu se může stát, že nevzbudí dostatečnou pozornost vedení. To může vést k tomu, že projekt nedostane dostatečné zdroje nebo bude s úspěchem napadán ze strany svých odpůrců. Základní cíle marketingu projektu:  propagovat projekt u vedení podniku a budoucích uživatelů;  zajistit akceptování výsledků projektu a jeho dílčích výsledků uvnitř podniku, zejména u rozhodujících tvůrců vnitropodnikového veřejného mínění;  Snížit na nejmenší míru úroveň konfliktů spojených s projektem;  podporovat identifikaci členů projektového týmu s projektem;  vybavit členy projektového týmu argumenty, tak aby mohli získávat pracovníky ve svém okolí pro cíle a výsledky projektu. K nástrojům marketingu projektu paří mimo jiné:  Informace ve vnitropodnikových mediích (podnikový časopis, homepage v rámci Intranetu, krátké mailingy na téma projektu určené pracovníkům podniku atd.).  Pravidelné informace členům vedení, kteří nejsou účastni jednání Řídícího výboru projektu. Velmi důležitá je informovanost liniových vedoucích kmenových útvarů, ze kterých se rekrutují členové projektového týmu.  Pravidelná informovanost o průběhu dílčích částí projektu ze strany vedoucích a členů dílčích projektových týmů směrem k budoucím uživatelům.  Nástěnky, plakáty a prezentace na téma projektu na pracovištích a jiné. Marketing projekt však může být neúspěšný, případně i kontraproduktivní, pokud se nevyhne některým nástrahám. Úskalí a nebezpečí špatných kroků v projektovém marketingu lze shrnout následovně:  Držet projekt nebo jeho problémy v tajnosti. Okolí projektu musí dostávat vždy pravdivé informace, jinak ztratí v projekt důvěru. U projektů IS je zvláště citlivá otázky úspor pracovních míst nebo vyvolání zásadních změn ve vykonávání pracovních činností. Marketing projektu Cíle mar- ketingu projektu Nástroje marketingu pro- jektu Podmínky úspěšnosti marketingu pro- jektu Řízení projektů IS 108  Nebrat do úvahy očekávání pracovníků v okolí projektu a nereagovat na tato očeká- vání.  Slibovat, že projekt vše vyřeší a zajistí stisknutím „jednoho knoflíku".  Prodávat „teplou vodu". Organizovat formální akce marketingu bez skutečného věcného obsahu.  Informace podřizovat politickým zájmům určitých skupin v podniku nebo vedení. Výsledky a reakce okolí na marketing projektu tvoří také důležitou zpětnou vazbu pro další řízení projektu. K ZAPAMATOVÁNÍ K rysům marketingu, kterým se zatím věnuje menší pozornost, je fakt, že prostřednictvím marketingu projektu dostávají členové projektového týmu do rukou možnost sami sebe v podniku propagovat. Z tohoto pohledu patří správně vedený marketing projektu k nástrojům motivace členů týmu. 2.9.2 FAKTORY MOTIVACE PROJEKTOVÉHO TÝMU K ZAPAMATOVÁNÍ Motivace obecně patří k tak zvaným „měkkým" metodám řízení. Vedoucí projektu IS musí být schopen vyvolat v členech týmu touhu účastnit se na úspěšném provedení projektu a tento postoj v nich udržet pokud možno po celou dobu trvání projektu. Mezi hlavní faktory, ovlivňující motivaci členů projektových týmů patří:  firemní kultura a styl řízení projektu;  postoje vedení podniku k projektu a jeho podpora;  správné vedení projektu ze strany vedoucího projektu a kvalita práce dodavatele;  realistický časový plán projektu a přidělení dostatečných zdrojů;  styl motivace (pozitivní a negativní motivace);  pracovní podmínky pro členy projektu;  osobní vlastnosti vedoucího projektu (motivace a manipulace, spolehlivost ...);  schopnost členů týmu orientovat se v problematice. Motivace Hlavní faktory moti- vace Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 109 2.9.3 RIZIKO ČASU A MOTIVACE TÝMU K ZAPAMATOVÁNÍ Jedním z rozhodujících faktorů motivace je úspěšný časový průběh projektu a aktivní účast všech členů projektových týmů. Výkon týmu a kvalita řešení projektu je dána výkonností a kvalitou nejslabšího článku v týmu. Může se stát a i navenek aktivně pracující člen týmu nemá dostatečné znalosti, schopnosti nebo motivaci k optimálnímu výkonu. V důsledku toho pak může v projektu vznikat časové zpoždění, které se na motivaci dalších členů negativně projeví. Riziko času se může projevit zejména u velkých projektů IS. Délka samotného projektu sama o sobě možnosti dlouhodobé vysoké motivace snižuje. Dojde-li navíc k odložení rozhodujících termínů, nesplnění závazků dodavatele ve smluveném čase, snížení kvality dodávek, pak v určitém kritickém momentu přestane přes veškeré stimulace motivace fungovat. Dojde například k syndromu vyhoření, nastane preference rodinných zájmů a odpočinku (zaplacené dovolené apod.). Zkušenosti ukazují, že se tato situace dá předvídat, do jisté míry je možné se jí i vyhnout, pokud však nastane, je velmi těžké ji napravit. 2.10Projekty nadnárodních informačních systémů Významným důsledkem pokračující globalizace je změna modelu řízení mezinárodních firem působících v několika zemích a zejména nadnárodních firem působících celosvětově. Řízení takových organizaci v rychle se měnícím světě si vynucuje i adekvátní podporu informačním a řídicím systémem v centrále i dceřiných společnostech (Pobočkách). Z uvedených důvodů se stručně zmíníme o problematice zavádění nadnárodních projektů IS. 2.10.1 TYPY ARCHITEKTUR NADNÁRODNÍCH INFORMAČNÍCH SYSTÉMŮ Podle typu nadnárodní organizace a její celkové organizace lze vypozorovat tři základní modely provozování nadnárodního IS. Nejjednodušší model je nezávislé řešení, jež generuje nezávislé systémy. Při tomto způsobu řešení má každá z Poboček svého vlastního dodavatele IS, přičemž každý z těchto dodavatelů dodává lokální SW licenci systému (tj. lokalizovanou v dané zemi z hlediska lokální legislativy a jazyka) a samostatně implementuje IS v dané Pobočce. Je zřejmé, že nezávislé řešení vede k existenci heterogenních informačních systémů, které se chovají velmi nepružně. Systém jako celek jen pomalu reaguje na měnící se podmínky. Rychlost reakce je určena rychlostí změny v nejpomaleji reagující Pobočce. Proto nadnárodní společnosti preferují jiná řešení. Výkon týmu a kvalita ře- šení Architektury nad- národních IS Nezávislé řešení Řízení projektů IS 110 Druhý model je jednotné řešení, jež generuje systémy jednotnou funkcionalitou v základních problémových oblastech. Při tomto způsobu řešení má centrála svého hlavního dodavatele, který dodává centrále i Pobočkám jednotné řešení. Hlavní dodavatel tedy spravuje všechny SW licence, vyvíjí a udržuje jedno jednotné řešení pokrývající i všechny lokální legislativní úpravy a implementuje tento systém ve všech Pobočkách. Hlavní dodavatel má dále pro každou z Poboček svou vlastní pobočku nebo smluvně vázaného partnera - subdodavatele, jenž za řízení hlavního dodavatele poskytuje Pobočce ty služby, ke kterým se hlavnímu dodavateli zavázal. Programové moduly řešení běží na místních systémech v Pobočkách a na centrále. Tento model umožňuje Pobočkám značnou míru nezávislosti a rychlosti reakce na nutné lokální změny, Systém jako celek však vykazuje nedostatky obdobně jako v případě nezávislého řešení. Přesto se však poměrně široce používá. Poslední model je centralizované řešení, jež představuje navenek stejné systémy. Při tomto způsobu řešení má centrála svého hlavního dodavatele, který připravuje pro Pobočky menší či větší část řešení. Hlavní dodavatel tedy spravuje jednu SW licenci, vyvíjí a udržuje jedno centralizované řešení běžící na centralizovaných systémech a pokrývající také všechny lokální legislativní i jazykové úpravy. 2.10.2 FORMÁLNÍ PŘEDPOKLADY ZAVÁDĚNÍ NADNÁRODNÍCH IS. K ZAPAMATOVÁNÍ Aby byl nadnárodní systém úspěšný, musí být splněny některé základní formální předpoklady. Pokud nejsou splněny, pak v lokálních instancích ERP budou nutné různé výjimky, zpravidla v logice programů nebo jejich nastavení. Tím se smysl nadnárodního systému prakticky ztratí. Zmíníme zejména následující předpoklady:  Harmonizované právní systémy v jednotlivých zemích. Jedná se zejména o zákony z oblasti investic a odpisů. Jinak nastavené zákony o investicích a odpisech mohou vyvolat problémy v jednotném účetnictví, v oblasti pronájmů strojů a zařízení, při realizaci servisních smluv a dalších případech. Základním problémem jednotného řešení a téměř nepřekonatelnou překážkou centralizovaného řešení jsou rozdíly ve struktuře daní všeobecně, DPH zejména. Pokud jsou na příklad na určité typy plnění nastaveny jiné úrovně DPH, pak lze tento problém řešit určitou parametrizací. Pokud však jsou stejná plnění v různých zemích zařazena do jiných skupin DPH, nebo existuje více skupin D PH v jedné či více zemích, než ve většině Poboček, je nutno zpravidla zasáhnout do programových struktur a logiky. Jednotné řešení Centralizované ře- šení Předpoklady na nadnárodní IS Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 111  Pokud je nadnárodní řešení zaváděno ve skupině zemí, z nichž je část již členy EU a část ještě není, vzniká problematika celních skladů, což komplikuje logistickou část systému.  Záruka a zásady penalizace. Logika záruk a penalizací by měla být stejná. Pro jeden nadnárodní koncern tomu tak zpravidla je, pokud tomu nebrání národní právo nebo prostředí trhu dané země. V tom případě lze však vystačit se změnami v parametrizaci systému.  Měnové otázky. Pokud se všechny Pobočky nacházejí v Eurozóně, nevznikají žádné problémy. V opačném případě se za hlavní měnu považuje měna státu, kde je umístěna příslušná centrála. Koncernové výkaznictví se vede v hlavní měně, zbytek v měně lokální. Toto může být problémem u centralizovaných řešení. Jeho řešením je zavedení instancí systému, odpovídajících jednotlivým Pobočkám. Z centralizovaného řešení se tak stává řešení jednotné, tedy řešení s nižší mírou integrace.  Způsob řízení nadnárodní organizace a firemní kultura. Způsob řízení a firemní kultura hrají důležitou roli jak při vlastním strategickém rozhodnutí a zavedení nadnárodního ERP systému tak zejména při vlastním průběhu projektu a jeho realizaci v jednotlivých zemích. Existují dvě krajní varianty — liberální a tvrdě centralistická. Liberálnější přístup bývá obvyklý v organizacích obchodního typu, systémy založené na výrobě bývají řízeny silně centralisticky. Autor došel ke zkušenosti, že americká firemní kultura mnoho lokálních variant nepřipouští, japonská firemní kultura tíhne k centralizaci, ale i ve své liberální variantě pomalu reaguje na změny. Ve společnostech s koncernovým vedením v Evropě se prosazují častěji liberální koncepty zavádění a provozování ICT. V případě japonských koncernů také občas dochází k tomu, že rozhodování probíhá s malou znalostí evropských reálií.  Způsob řízení lokálních Poboček ze strany centrály hraje také významnou roli tehdy, když je nutno zaměnit heterogenní v Pobočkách provozované systémy za jeden společný systém s jednotnou podporou, údržbou a rozvojem. V jednotlivých pobočkách jsou tím často narušeny ekonomické a mocenské zájmy, takže nezbývá než přistoupit k úkolování vedoucích pracovníků Poboček. Lokální dodavatelé IS přicházejí o obchod a vliv v Pobočkách, takže se musí řešit často zástupné problémy nastolené jak Pobočkami, tak lokálními dodavateli. Často se právě argumentuje odlišných právním a tržním prostředí. Ve společnosti, kde autor pracoval mnoho let, dovedla tuto taktiku k dokonalosti jedna Pobočka, ve které se ještě v roce 2008, 8 let po základním rozhodnutí, nepodařilo zavést ani jednotné koncernové řešení. 2.10.3 METODICKÉ OTÁZKY SPOJENÉ S NADNÁRODNÍMI PROJEKTY INFORMAČNÍCH SYSTÉMŮ PŘÍPADOVÁ STUDIE Jako příklad metodických otázek a výzev, které lze podle našeho názoru zevšeobecnit, uvádíme hlavní charakteristiky projektu jednotného řešení ERP pro nadnárodní společnost Řízení projektů IS 112 s celoevropskou centrálou. Projekt se týkal zavedení jednotného řešení ERP systémů Poboček firmy na bázi Microsoft Dynamics NAV. Projekt byl nazván Navision Uniform Solution (NUS). Podrobnější zprávu o této problematice jsme podali ve Vymětal (2007). Evropská centrála stanovila pro projekt tyto hlavní cíle:  významné snížení TCO - Total Costs of Ownership (minimálně o 30%);  standardizovaná podpora typických obchodních procesů bez ohledu na zemi nasazení a z toho vyplývající synergické efekty;  zrušení lokálních monopolů jak preferovaných uživatelů a pracovníků ICT útvarů, tak lokálních partnerů Navision — dodavatelů lokalizovaných řešení Navision (dále LNP — Local Navision Partner);  dosažení jednoho řešení pro společné problémy jako na příklad SCM (Supply Chán  Management) mezi centrálními evropskými sklady a sklady v jednotlivých zemích atd. Souběžně byly také identifikovány nevýhody a případná rizika zvoleného řešení:  zvýšené počáteční náklady nutné pro vytvoření a implementaci NUS;  údržba NUS v celém životním cyklu vyžaduje silné řízení projektu včetně nadnárodních kompetencí;  nadnárodní kompetence vedoucího projektu a projekčního týmu mohou způsobit určité sociálně-psychologické problémy;  celková pružnost změnových cyklů (požadavky centrály, požadavky poboček, legislativní požadavky) se daným způsobem řízení projektu snižuje. Po analýze rizik uložila evropská centrála projektovému týmu využít všech známých výhod a definovat takovou projektovou strukturu, která by minimalizovala v té době známé nevýhody. Základní strategii použitou pro řízení projektu lze shrnout takto:  firma má jen jednoho partnera pro správu licencí Microsoft Dynamics NAV;  základním a jediným typem licence Microsoft Dynamics NAV je mezinárodní verze (tzv. W1).  pro projekt je určen jeden generální dodavatel, který nese zodpovědnost za celý projekt (SW licence, vývoj, implementace, údržba) ve všech zemích;  cena za SW licence, služby i údržbu jsou s generálním dodavatelem dohodnuty jed- notně;  projektový tým je složen z plně kompetentních zástupců jednotlivých dceřiných společností;  pro všechny dceřiné společnosti jsou stanoveny jednotná pravidla pro údržbu systému a pro registraci, schvalování a realizaci nových požadavků; Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 113  generální dodavatel i jeho subdodavatelé v jednotlivých zemích podepíší jako součást kontraktu souhlas s používáním vytvořeného řešení ve všech dceřiných společnostech v Evropě. OTÁZKY Po prostudování kapitoly byste měli být schopni vysvětlit následující: 1. Uveďte definici projektu a jeho obecnou charakteristiku. (viz definice str. 76) 2. Uveďte specifika projektu IS. (viz strana 77) 3. Definujte a uveďte bližší charakteristiku pojmu řízení projektu. (viz 2.1) 4. Charakterizujte jednotlivé typy projektových organizačních struktur. (viz 2.1) 5. Vyjmenujte a charakterizujte jednotlivé role v rámci projektu IS. (viz 2.1.4) 6. Popište typickou strukturu projektového týmu projektu IS. (viz 2.3, 2.6) 7. Uveďte a charakterizujte typické činnosti členů projektového týmu. (viz 2.3) 8. Charakterizujte jednotlivé styly řízení projektu IS. (viz 2.4) 9. Jaká jsou hlavní rizika řízení projektu IS? (viz 2.8.5) SHRNUTÍ KAPITOLY Nastavení optimálního systému řízení projektu je prvořadou podmínkou pro zajištění jeho úspěšnosti. Řízení musí být nastaveno a adekvátně prováděno ve všech fázích a krocích při realizaci projektu od jeho přípravy až po ukončení, kontrolu výstupů a vyhodnocení. Hlavním předpokladem úspěšnosti řízení je stanovení adekvátní struktury organizace projektu, určení rolí v projektové struktuře a požadavků na projektový tým a využívání odpovídajících stylů řízení. FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 114 3 FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU RYCHLÝ NÁHLED KAPITOLY V předcházející kapitole jsme popsali obecné otázky týkající se řízení projektů IS. Nyní se zaměříme více na jednotlivé fáze projektu. V této souvislosti připomínáme, že projekty IS mají komplexní charakter. Podle typu a rozsahu projektu se jednotlivé fáze, jejich obsah a váha v projektu mohou lišit. V této části budeme mít na mysli zejména klasické metodiky projektování a zavádění IS, zejména spirálový model. CÍLE KAPITOLY Po prostudování této kapitoly budete umět:  definovat jednotlivé fáze projektu;  vytvořit studii proveditelnosti pro projekty IS/IT;  určit východiska pro definici požadovaných funkcí systému;  stanovit postup pro určení finančních nákladů;  navrhnout metody organizace a řízení projektu;  stanovit podmínky výběrového řízení a tyto vyhodnotit;  orientovat se v problematice uzavírání smluv s dodavatelem. KLÍČOVÁ SLOVA KAPITOLY Fáze projektu, studie proveditelnosti, funkce systému, finanční náklady, organizace projektu, řízení projektu, výběrové řízení, smlouvy. Projekt IS lze obecně členit do několika fází, v nichž probíhají další aktivity. Připomínáme, že vycházíme z přijaté podnikové strategie, z níž se odvodila strategie informační. Projekt můžeme rozdělit do fází a aktivit uvedených v Tabulka 10. Fáze průběhu projektu IS Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 115 Tabulka 10 Základní fáze průběhu projektu IS a související aktivity Fáze Aktivita Iniciace projektu hrubá analýza současného stavu a souhrn požadavků. zpracování Předběžné studie proveditelnosti, rozhodnutí Předprojektová fáze základní analýza a soupis požadovaných funkcí. zpracování Úvodní studie proveditelnosti, rozhodnutí výběr dodavatele příprava a uzavření Smlouvy o dodávce Projektová fáze detailní analýza potřeb návrh řešení zpracování Cílového konceptu Fáze realizace příprava prototypů (volitelné v závislosti od rozhodnutí) stanovení zásad migrace dat ladění prototypů technická realizace souhrnný (integrační) test a příprava dokumentaceškolení uživatelů instalace, akceptační test Fáze provozu a uzavření projektu zahájení provozu (po rozhodnutí o zahájení) první období po zavedení vlastní uzavření projektu doporučení: následná analýza Při rozboru uvedených fází se zaměříme zejména na přípravu Úvodní studie proveditelnosti a přípravu Cílového konceptu řešení jako aktivit, které mají významný ne-li rozhodující vliv na konečný úspěch projektu. 3.1 Úvodní studie proveditelnosti IS K ZAPAMATOVÁNÍ Rozhodnutí o zavedení nového projektu musí být založeno nejen na podnikové strategii ale také na znalosti nové situace. Přitom je nutno vyhodnotit nejen vlastní záměr z hlediska funkcionality, ale také možná rizika, omezení zdrojů, jako jsou finanční, materiálové i řešitelské zdroje a samozřejmě i přínosnost celého projektu. U řady velkých a složitých projektů se za tímto účelem provádí Předběžná studie proveditelnosti (Pre-FeasibiIity Study). V oblasti projektů IS se předběžná studie provádí zřídka a přistupuje se k přímo k úvodní studii proveditelnosti (Feasibility Study - dále jen Rozhodnutí o za- vedení projektu Předběžná studie pro- veditel- nosti FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 116 ÚSP). ÚSP lze definovat jako analýzu a vyhodnocení možných vlivů navrhovaného projektu tak, aby rozhodovatelé mohli přijmout rozhodnutí o schválení nebo odmítnutí celého projektu (Thomson (2006)). ÚSP se obvykle provádí poté, co vedoucí zodpovědní za strategii a koncepci firemních procesů rozhodli o nutných změnách IS a společně s CIO dospěli k závěru, že je třeba provedení projektů IS zvážit. 3.1.1 KDY PROVÁDĚT ČI NEPROVÁDĚT STUDII K ZAPAMATOVÁNÍ Rozhodnutí o provedení ÚSP může mít závažné důsledky na chod podniku, zejména proto, že po určitou dobu dochází k blokování firemních specialistů pro práci na této studii. Přizvání externích partnerů na provedení této studie znamená určité finanční náklady, a to v době, kdy rozhodnutí o zavedení nového IS ještě být učiněno. Je tedy třeba zvážit, kdy tuto studii vůbec provádět. Udává se (např. Hopfstrand (2006)), že hlavní důvody pro provedení ÚSP jsou mimo jiné:  idea projektu se dostane do zorného pole podstatné části podniku;  v důsledku analýzy spojené s ÚSP se mohou objevit další alternativy změn IS, případně v podnikových procesech. Je možno zdokumentovat důvody, proč projekt ne- zahajovat;  dochází ke zvyšování pravděpodobnosti úspěchu projektu, protože je možno diskutovat faktory negativně ovlivňující projekt již v raném stádiu;  vzniká kvalitní informace pro rozhodování;  vzniká dokumentace, která popisuje procesy související s projekty IS. Tyto dokumenty jsou výsledkem poměrně rozsáhlé analýzy;  vznikají podklady pro financování projektu z interních zdrojů. Na druhé straně se objeví zpravidla celá řada důvodů proč studii neprovádět. Tyto důvody nemusí být vždy věcné nebo finanční. Mohou odrážet zájmy určitých zájmových skupin. Z našich zkušeností mohou proti studii argumentovat následující nositelé zájmů:  Vedoucí projektu, případně "nositel nápadu". Není vždy v zájmu vedoucího projektu, aby vznikla ÚSP. Vznikem ÚSP je dán poměrně pevný rámec, kterým se vedoucí projektu musí řídit. Pokud se jedná o projekt související s rozvojem technologie a prosazovaný oddělením ICT, bývá snaha ÚSP neprovádět poměrně silná.  Negativně naladěná lobby. Projekt v oblasti IS vždy znamená změnu procesů v podniku. Změna těchto procesů může vyvolat odpor určitých zájmových skupin, zejména tam, kde jde o změnu obsahu pracovní činnosti nebo změnu pravomocí. Důvody re- alizace/ne- realizace ÚSP Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 117  Pozitivně naladěná lobby. Projekt IS může vyvolat obtížné otázky, například je finančně velmi náročný nebo existují rizika nesplnění zadaných ukazatelů funkcionality a přínosů. Proto může mít pozitivně smýšlející zájmová skupina, která chce projekt prosadit, obavy z případného záporného rozhodnutí. Tato taktika je vysoce riskantní a neefektivní, přesto k ní v praxi dochází. Rozhodnutí nedělat ÚSP však může v konečném důsledku stát více peněz než náklady na studii. Existují i další pomocná kritéria pro rozhodnutí studii provádět a to:  Úroveň očekávaných nákladů na projekt. Zde mohou existovat jasná pravidla daná formální organizací, jako jsou směrnice, závazné pokyny atd.  Byla provedena předběžná studie proveditelnosti a ukázalo se, že investice do projektu IS je v zásadě výhodná.  Existuje nový business plán, který indikuje potřebu investic do IS, není však jasné jak velké tyto investice budou, jaký je časový rámec očekávaného projektu a zda neexistují jiné varianty řešení. 3.1.2 RÁMCOVÝ OBSAH STUDIE K ZAPAMATOVÁNÍ ÚSP by měla obsahovat následující části:  shrnutí pro vrcholové vedení;  informace o důvodech projektu;  návrh nového řešení;  srovnáni stávajícího stavu a navrhované řešení;  analýzu rizik;  analýzu přínosů a nákladů;  časový harmonogram projektu a závěrečné doporučení. Není vždy nutné zpracovávat ÚSP v tomto rozsahu. Je však vždy dobré v rámci přípravy studie každý z těchto bodů důkladně analyzovat a najít důvod proč jej do studie zahrnovat nebo naopak najít a připravit si odpověď pro závěrečná doporučení. Při koncipování celkové struktury ÚSP je nutno zvážit dva důležité aspekty. Za prvé je důležité aby ÚSP obsahoval a závěry možných řešení. V případě projektu IS to mohou být na příklad tyto věcné varianty:  způsob pořízení a provozování hardware, na příklad použití outsourcingu;  způsob vývoje nebo nákupu očekávaných funkčních modulů; Rámcový obsah ÚSP Aspekty struktury ÚSP FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 118  možné způsoby provozování datové sítě, na příklad použití pronajatých linek nebo spojení přes Internet. Navrhované varianty by měly obsahovat i provázanost na termínové plány. Z termínových plánů a jejich variant vyplynou i varianty potřeby interních i externích zdrojů. Z variant potřeby zdrojů se odvodí varianty financování. K ZAPAMATOVÁNÍ Je tedy zřejmé, že již v této etapě je nutno zajistit provázanost jednotlivých složek projektu. Připomeňme v této souvislosti vztah mezi kvalitou, časem a náklady na projekt. S kvalitou projektu roste jeho cena a klesá rychlost zpracování. Je evidentní, že není možno dosáhnout vysoké kvality projektu s nízkými náklady v co nejkratším možném čase. Je pochopitelně možné nacházet suboptimální varianty vztahu těmito složkami. Hledání suboptimálních variant musí být na úrovni ÚSP provedeno a tedy jednou z charakteristik přípravy ÚSP je nutnost určité iterace. Jestli vyžadujeme poměrně krátký termín realizace projektu a překračujeme zadaný nebo únosný limit nákladů na projekt, nezbývá než znovu otevřít diskuzi o kvalitě řešení, na příklad o rozsahu požadovaných funkcí, o zabezpečení nepřetržitého provozu sítě nebo servisu pro případ poruchy atd. Při této interpretaci je nutno současně zvažovat možná rizika, vyplývající z navržené varianty. Z uvedeného vyplývá, že již na úrovni ÚSP je vhodné opustit kaskádový model a držet se spirálového model projektování IS. 3.1.3 CÍLE PROJEKTU Různí autoři se bez výjimky shodují v tom, že základním předpokladem úspěšnosti projektu je správné stanovení cílů a to v takové struktuře, aby jak vedení podniku, tak projektovému týmu, budoucím uživatelům i dodavateli bylo jasné, čeho se má dosáhnout. V praxi však dochází k tomu, že stanovení cílů této kvality nedosahuje. Uveďme dvě možné technologie, které v rámci přípravy ÚSP lze použít pro jasné a přesné stanovení cílů projektu. Na Obrázek 28 je uvedeno použití metodiky Terče podle Fuerstbergra [FUR 2003] na příkladu stanovení cílů projektu nasazení automatického hlášení o stavu síťových tiskáren dodavateli, který působil současně jako servisní organizace. Stanovení cílů pro- jektu Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 119 Obrázek 28 Příklad použití Terče pro definici cílů projektu Základní otázkou, kterou je třeba si zodpovědět, je cíl a účel uvedený v levém horním kvadrantu kruhu. Komu má výsledek sloužit, je specifikováno otázkou určení zákazníka nebo koncového uživatele. V kvadrantu kritéria úspěchu se definují metriky dosažení úspěchu. V kvadrantu výsledek, je definováno, čeho má být projektem dosaženo. Jinou možností stanovení cílů projektů je také metoda Balanced Scorecard [ARV 2007], [KAP 2007]. KONTROLNÍ OTÁZKA S využitím elementárních matematických operací při zdánlivě stejné kvalitě nabídky funkcí nového systému různými dodavateli dojdeme vždy ke stejným výsledkům hodnocení nabídek nebo se vyhodnocení mohou lišit? Uveďte na příkladech. 3.1.4 KDO ZPRACOVÁVÁ STUDII Jak jsme již uvedli, zpracování ÚSP klade značný nárok na zdroje. Je tomu tak zejména proto, že:  Studii proveditelnosti nelze zpracovat bez účasti rozhodujících interních specialistů v oblasti ICT a budoucích uživatelů nového systému. To znamená, že po dobu zpracovávání studie jsou tito pracovníci do značné míry blokováni pro využití v dalších oblastech a procesech. Již v této etapě podle velikosti projektu dochází k definici FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 120 typu potřebné organizační struktury, která se pravděpodobně v případě kladného rozhodnutí bude používat i v etapě realizace.  U větších projektů je záhodno použít pro zpracování externí konzultanty, což znamená finanční zatížení. Interní zpracovatelé ÚSP by měli mít následující vlastnosti resp. kompetence:  Zkušenosti z tvorby takovýchto studií a to nejen v oblasti ICT, ale i z jiných typů projektů.  Podrobné znalosti z průběhu podnikových procesů, případně znalosti z práce se zákazníky. S výjimkou specialistů z oblasti ICT, u kterých se to předpokládá, by měli mít dostatečné znalosti z informatiky a mít k nasazení této technologie kladný vztah.  Měli by mít k navrhovanému projektu neutrální vztah. Tento požadavek není vždy lehké splnit. Specialisté ICT nemohou být k projektu IS neutrální již z podstaty své vlastní práce. Budoucí uživatelé mohou být jen těžko neutrální ke změně procesů vyvolaných zavedením nového systému či změnou systému stávajícího. 3.1.5 ROLE EXTERNÍCH PORADCŮ K ZAPAMATOVÁNÍ Externí poradci mohou sloužit nejen jako moderátoři diskuzí v průběhu analýzy spojené s tvorbou ÚSP, ale vnášet do celého procesu nezbytné know-how z jiných projektů. Jejich role je velmi významná, zejména při hledání variant. Pracovníci podniku totiž mohou často trpět určitou provozní slepotou. Významnou roli sehrávají externí pracovníci při zpracování ekonomické části studie. V řadě případů totiž mohou působit jako záruka pro vedení podniku, že bude dosaženo nejlepšího možného řešení z hlediska času, kvality a nákladů. Na druhé straně je však použití externích poradců také určitým rizikem. Z praktických zkušeností lze tato rizika v kostce shrnout následovně:  Vzhledem k nákladnosti externích poradců je nutno uzavřít s nimi dobře formulovanou smlouvu. V extrémním případě již příprava této smlouvy může stát více času a zdrojů než velká část zamýšlené ÚSP.  Externí poradci nemívají podrobnou znalost procesů konkrétního podniku. Může se stát, že dojde k problémům v komunikace z důvodů používané terminologie (pro tento problém se v německy mluvících zemích ujal název Firmensprache).  Externí poradci mívají tendenci říkat to, co chce slyšet zadavatel. Izde je tedynutné pečlivě připravit smlouvu s cílem jasně definovat úkoly externího poradce při tvorbě dané ÚSP. Kompetence zpra- covatelů ÚSP Rizika využití externích po- radců Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 121 KONTROLNÍ OTÁZKA Po shrnutí kladů a záporů využívání externích expertů je tedy otázka, zda externí poradce využívat či nikoliv? Svou odpověď zdůvodněte. 3.1.6 ANALÝZA POŽADOVANÝCH FUNKCÍ Analýza požadovaných funkcí je klíčovou částí ÚSP. Při koncipování této části ÚSP musíme mít na paměti, že vývoj IS je kontinuální proces. Je tedy poměrně obtížné určit, do jaké hloubky má být tato analýza provedena. V průběhu realizace projektu dojde k další podrobné analýze, která by měla na závěry uvedené v ÚSP navazovat. Mezi tvorbou ÚSP a realizací projektu však může dojít k poměrně dlouhé časové prodlevě, kdy se požadavky na nové řešení mohou změnit. Analýza na úrovni ÚSP tedy nemůže být příliš detailní. Na druhé straně však musí být zpracována do takové hloubky, aby bylo možno propočítat náklady na projekt a očekávané přínosy. Analýza požadovaných oblastí by měla obsahovat popis cílových oblastí, kterých se řešení týká. Jako příklady lze uvést zpracování úloh dle problémových oblastí uvedené v Tabulka 11. Tabulka 11 Příklady zpracování úloh dle problémových oblastí Problémová oblast Úloha Výroba náklady na jednotku produkce ovlivněné návrhem IS zavedení nového výrobku a jeho podpory pomocí IS náklady na zajištění kvality a inovační potenciál nového IS Obchodní činnosti nové distribuční kanály přímý a nepřímý prodej, dealeři, distributoři a jejich podpora Nové marketingové strategie podporované IS podpora mailingů, zpracování výsledků Call centra, řízení termínů schůzek obchodních zástupců atd. Zavedení CRM nebo SFA (Sales Force Automation) propojení CRM s hlavním informačním systémem a systémem marketingu ... Business Inteligence potřeby a záměry EIS kompatibilita dat s datovým skladem manažerské potřeby v souvislosti snovými obchodními procesy Servis mobilita servisních pracovníků nové typy servisních smluv nebo SLA (Service Level Agreement) použití www pro automatizaci servisu Analýza funkcí FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 122 K ZAPAMATOVÁNÍ Konkrétní požadavky na vývoj budoucího IS - zde ÚSP navazuje na definici cílů a obsahuje analýzu potřeb koncových uživatelů. Vysvětlení důvodů proč mají takové potřeby - Jde o návaznost na změny v procesech, které jsou vyvolány stanovením hlavních cílů. U projektů směřujících ke změně infrastruktury jsou tyto potřeby zpravidla vyvolány výkonnostními parametry technických prostředků, jako jsou koncové stanice, servery nebo parametry sítě. Které z navrhovaných nových funkcí přinesou efekt - zde se zpravidla začínají střetávat zájmy jednotlivých skupin a nezbývá než použít Parretovo pravidlo 80:20. Pokud v rámci přípravy nového IS proběhlo modelování podnikových procesů s cílem jejich optimalizace nebo dokonce simulace průchodnosti procesů systémem je nutno závěry těchto modelování srovnat s výsledky analýzy potřeb koncových uživatelů a rozhodnout o případných změnách, pokud se výsledky podstatně liší. 3.1.7 URČENÍ BUDOUCÍHO VÝVOJE POŽADAVKŮ NA IS K ZAPAMATOVÁNÍ Zhodnocení otevřenosti nového systému pro budoucnost - analýza nového systému pro budoucí období a navrhované změny jsou jedním ze základních kritérií posuzování variant řešení. Vývoj u konkurence - v prvé řadě jedná o vyhodnocení procesů v konkurenčních organizacích. Pokud chybí možnost takového srovnání, je nutno provést srovnání u organizací obdobného typu s využitím principu nejlepších praktik. Stanovení, zda je návrh otevřený vzhledem k možným legislativním změnám - klasickým případem může být problematika v daňovém a sociálním systému, v oblasti DPH, odpisů apod. Soulad s dlouhodobou strategií podniku - mohlo by se zdát, že je tato otázka zbytečná, protože ÚSP byla vyvolána potřebnými změnami ve strategii a taktice. Je tedy obsažena v zadání. Nicméně právě v etapě potřeb uživatelů může v důsledku tlaků různých zájmových skupin dojít k odchylce. Tento problém se může objevit také tehdy, když má nový projekt proběhnout na základě zadání z mateřské organizace v případě koncernu nebo v důsledku ujednání při realizaci Supply Chain Management - SCM. Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 123 Tuto část ÚSP při přípravě projektu IS dělá často jeden ze zvažovaných dodavatelů. Takovou praxi nelze považovat za optimální, protože se jednomu z uvažovaných dodavatelů dostává značné výhody, kterou může využít v předkontraktačních jednáních. Výsledkem práce je katalog funkcí, které se od IS nebo jeho změny vyžadují. Tento katalog specifikuje do nezbytné úrovně požadované funkce. Jak jsme již uvedli výše, vzniká zde jistý rozpor. Je-li katalog příliš podrobný, může být v etapě realizace projektu překonán novými požadavky uživatelů. Je-li příliš obecný, dá se jen špatně využít pro hodnocení ekonomické efektivnosti projektu a vůbec jej nelze využít při nabídkovém řízení, neboť potenciální dodavatelé dostávají o rozsahu jednání nedostatečné informace. 3.1.8 ODVOZENÍ POŽADAVKŮ NA INFRASTRUKTURU Z definovaných potřeb uživatelů na funkcionalitu a kvalitu nového IS lze odvodit základní požadavky na infrastrukturu potřebnou pro realizaci a úspěšné provozování hledaného řešení. Jedná se zejména o následující témata:  Určení potřeb hardware - zde je třeba rozebrat potřeby na koncové stanice, ať už na nové stanice nebo jejich inovaci, na nákup či inovaci serverů a zejména různé varianty těchto nákupů. Může jít o koupi v rámci investičního majetku, leasing, pronájem nebo outsourcing. Často bývá kladem menší důraz na problematiku ukládání dat a zajištění bezpečnosti a obnovy datových úložišť v případě havárie. Zejména u projektů menšího rozsahu bývá nutno iterativním způsobem řešit vztah mezi kapacitou diskových pamětí a kapacitou úložišť používaných pro zálohování.  Určení potřeb software - z definovaných funkcí nového IS nebo požadovaných změn se odvodí potřeba rozsahu inovace stávajícího software, vytvoření specifických modulů, nákup standardních modulů nebo se dojde k závěru o potřebě změny potřebné části stávajícího IS. S tím souvisí také zhodnocení nákupu licencí pro koncové stanice a servery, produkty zavedených software jako je na příklad Microsoft, Oracle a jiných. K této části také patří vyjádření k možnému použití produktů s Open Source licencí jako varianty možného financování části pořizovaného software.  Určení potřeb sítě - zde patří zejména: o Varianty návrhů architektury LAN a WAN a jejich změn. o Určení potřebné rychlosti a doby odezvy v provozovaných sítích. o Hrubá definice potřebných aktivních elementů sítě. o Požadovaná spolehlivost a SLA parametrů provozovatelů sítě, případně Outsourcingu. o Nepřetržitá dodávka proudu. Změny a rozšíření hardware v jednotlivých provozních místnostech mohou znamenat podstatný nárůst spotřeby elektrické energie. To může vyvolat nutnost změny výkonnosti záložního napájecího zařízení UPS. Na uvedený problém jsme v naší praxi vícekrát narazili a je zajímavé, že jeho řešení nebylo téměř nikdy předmětem USP. Katalog funkcí Požadavky na in- frastruk- turu FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 124 o Zhodnocení disponibility prostorů. Jako výsledek získáme být hrubý návrh stavebních změn a změn technologie. V souvislosti s možným zvýšením spotřeby elektrické energie v provozních prostorech může dojít ke změně v klimatizačních zařízeních. Ve svém souhrnu tyto změny mohou vyvolat zcela neočekávanou potřebu inovace kabeláže, a proto je nelze podceňovat. 3.1.9 PROPOČET NÁKLADŮ Z požadavků na infrastrukturu obecně se odvozují náklady na projekt. Podle rozsahu ÚSP je nutno propočítat náklady a následující položky:  Náklady na hardware - zde se na základě nabídek potencionálních dodavatelů uvádí pořizovací cena zařízení hardware, případně cena jejich inovace a provede srovnání variant financování z pohledu odpisů, leasingů, úvěrového zatížení nebo outsourcingu části zařízení.  Náklady na software - sem se zařazují potřebné náklady na licence, případně varianty plateb za licence, dále jako hlavní položka náklady na vývoj nového software nebo úpravy standardních komerčních balíků. Z těchto nákladů je poté nutno dle dostupných nabídek odvodit náklady na údržbu a podporu software. Důležitou položkou, kterou nelze opomenout, je alespoň hrubý odhad nákladů na synchronizaci verzí softwarových produktů od různých výrobců. Tato otázka nabývá na důležitosti stále více, zejména s rozvojem SOA.  Náklady na úpravy sítí - sem se zahrnují ceny definovaných nutných změn v kabeláži a využití aktivních elementů, dále sem patří varianty cen za používání WAN různých dodavatelů s přihlédnutím k požadované úrovni SLA.  Náklady stavebních úprav.  Náklady na pořízení dalších stavebních komponent s možnými variantami jejich financování.  Personální náklady - do této skupiny nákladů se zařazují náklady na případné zajištění nových pracovníků, dále náklady na jejich školení a také přímé náklady na školení budoucích uživatelů. Pokud je to možné, zahrnou se sem také přímé náklady spoluúčasti na školení uživatelů. Zvláštní kapitolu tvoří náklady na služby konzultantů, které použijeme na příklad pro zajištění kvality projektu, konzultantskou činnost v předkontraktačním období apod. 3.1.10 NÁVRH ORGANIZACE A ŘÍZENÍ PROJEKTU Komplexní projekty nového zavedení IS nebo jeho změn zpravidla vždy znamenají zásah do organizace a řízení. Je tedy nutno v rámci ÚSP provést základní vyhodnocení stávajícího organizačního uspořádání ve srovnání s navrhovanými variantami řešení. Téměř vždy bude nutná určitá organizační změna. Proto je nutné uvést zásady nového organizačního uspořádání v členění: Propočet nákladů Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 125  organizace nových procesů s podporou IS;  předpokládané změny v důsledku IS;  očekávané změny pracovních zařazení;  vliv nové organizace na režijní náklady;  v případě úspor pracovních sil se předkládá návrh zásad sociálního plánu vycházejícího z těchto úspor a odhad jeho nákladů;  vyhodnocení stávajícího organizačního uspořádání a jeho soulad s výstupy projektu. 3.1.11 POŽADAVKY NA LIDSKÉ ZDROJE V této části se zpravidla uvádí potřeby lidských zdrojů, které projekt vyvolá a způsoby jakým se interní pracovníci budou na projektu podílet. Patří sem zejména:  Požadavky na lidské zdroje vyvolané projektem - sem se zahrne v prvé řadě návrh projektové organizace. Ten vychází ze zásad projektového řízení v daném podniku a zpravidla využívá jednu z projektových organizací popsaných v kapitole 2. Z definované organizace projektů vyplývají potřeby pracovníků během jednotlivých etap projektu, případně požadavky na nové pracovníky. Správně definovaný projekt by měl již ve fázi ÚSP provést odhad zatížení stávajícího personálu po dobu projektu v důsledku přijaté projektové organizace a návrh nutného přerozdělení funkcí.  Chybějící kvalifikace - zde se provádí specifikace potřebných změn v kvalifikaci pracovníků vyvolaných projektem.  Školení - na základě hrubého časového plánu projektu se definují etapy školení. Současně se provádí návrh klíčových uživatelů, kteří by měli po realizaci projektu provádět hlavní funkce a podporovat další uživatele projektu. Zároveň se navrhne způsob školení. V zásadě mohou existovat dva základní typy školení a to, školení dodavatelské kdy dodavatel nového systému zaškolí všechny uživatele nebo školení typu „Train the trainer", kdy jsou zaškoleni hlavní uživatelé, kteří pak v režii podniku provádí školení jednotlivých uživatelů zabezpečujících dílčí funkce. Zde je třeba říci, že určení typu školení a jeho rozsahu se může zdát v této etapě jako předčasné. Na druhé straně však typ školení může představovat značnou část ceny celého projektu a být předmětem cenových vyjednávání. Proto je dobré když zpracovatelé ÚSP obě varianty zváží a zahrnou preferovanou variantu do závěrečného návrhu.  Návrh zásad systému motivace pracovníků - z hlediska dalšího hladkého průběhu je dobré, když vedení podniku předem stanoví zásady motivace pracovníků. Zpracovatelé ÚSP zde mohou přijít s vlastním návrhem. Zpracování zásad motivace se vyplatí zejména při maticové organizaci projektu, protože klíčoví pracovníci jsou po dobu projektu vystaveni pracovnímu přetížení. Zásady nového orga- nizačního uspořá- dání Lidské zdroje FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 126 3.1.12 HRUBÝ ČASOVÝ PLÁN REALIZACE Plán realizace projektu je klíčovou součástí ÚSP. Vychází jednak ze zadání, dále z odhadovaných časových nákladů na realizaci jednotlivých aktivit a také zkušeností s obdobnými projekty, které se v oblasti IS již dříve realizovaly. V této fázi se také příznivě může projevit účast externích poradců, kteří přinášejí do projektu zkušenosti z celé řady projektů dřívějších, případně nezávazná doporučení potenciálních dodavatelů projektů. Tento plán obsahuje hlavně:  klíčové aktivity v rámci projektu;  rozhodující závislosti mezi aktivitami;  navrhované kontrolní body (milníky);  termín zahájení a ukončení klíčových aktivit. K ZAPAMATOVÁNÍ Forma časového plánu v ÚSP může být různá. V praxi se však vzhledem k nejrůznějším provázanostem mezi aktivitami dobře osvědčuje produkt MS Project, pro grafické vyjádření na příklad MS Visio případně některý z open source produktů. 3.1.13 EKONOMICKÉ HODNOCENÍ PROJEKTU Na úrovni ÚSP se zpravidla předkládá hodnocení v různých variantách. Nejjednodušší hodnocení představuje srovnání výnosů z projektu a nákladů. Zde se v praxi často provádí pouze srovnání nákladů na projekt s hrubými výnosy a z tohoto srovnání se odvozuje doba návratnosti a návratnost investice. V projektech IS se v poslední době často používá hodnocení nákladů po dobu celkové životnosti navrhovaného systému - Total costs of ownership. Využití TCO v projektech IS nastává zejména, když se hodnotí různé nákladové varianty projektů, které jsou předem považovány za nezbytné; často se při tom ani podrobněji nehodnotí přínosová stránka. Základním nedostatkem těchto jednoduchých hodnocení je, že neberou do úvahy celkové finanční toky (Cash flow- dále jen CF) zahrnující výpočet hrubého a čistého zisku, jeho zdanění a zahrnutí předpokládaných odpisů do CF. U náročných projektů požadují zodpovědní pracovníci finančních oddělení také diskontování příslušných finančních ukazatelů. Právě na úrovni ÚSP je vhodné s diskontováním počítat a použít pro hodnocení takových projektů výpočet čisté současné hodnoty. Nicméně použití diskontovaných ukazatelů může vést k negativnímu hodnocení projektu vyžadujícího určitou pružnost v rozhodování, zahrnutí rizik a příležitostí do ekonomických úvah. Zde se již v odvětvích vykazujících značné výkyvy (volatilitu) výnosů a nákladů začínají uplatňovat reálné opce. Ekonomické hodnocení projektu a reálné opce jsme analyzovali ve [VYM 200913]. Plán realizace pro- jektu Forma ča- sového plánu Ekonomické hod- nocení projektu Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 127 3.1.14 FORMULACE ZÁVĚREČNÉHO DOPORUČENÍ Závěrečné doporučení shrnuje výše uvedené části ÚSP. Je základním podkladem pro rozhodnutí, zda v projektu pokračovat či nikoli. Obsahuje hlavně:  Shrnutí navrhovaných řešení a jejich variant a srovnání s definovanými cíli — zadáním projektu;  Shrnutí mimoekonomických vlivů;  ekonomické zhodnocení návrhu;  návrh dalšího postupu. Závěrečné doporučení se předkládá ve formě textu, tabulek a grafů. Dokument předkládá vedoucí projektu, případně zástupce firmy, která byla provedením ÚSP pověřena. Při zpracování závěrečného doporučení je nutno provést ještě jednou celkovou revizi ÚSP a zkontrolovat, že vyhovuje následujícím požadavkům:  Je srozumitelná a čitelná. Zejména úvodní část a návrh a závěrečné doporučení musí být formulováno jazykem rozhodovatelů (managementu). U projektu ICT vzniká nebezpečí, že studie obsahuje mnoho hantýrky, což může rozhodnutí o přijetí, zejména také rozhodnutí o alokaci zdrojů negativně ovlivnit.  Studie odpovídá zadání. Praktické zkušenosti ukazují, že na této úrovni se mohou objevit snahy o zahrnutí „osobních" odborných zájmů k dořešení.  Je logiky konzistentní. Protože u větších projektů je ÚSP zpracována velkým týmem, hrozí zde nebezpečí určité nekonzistence navrhovaných funkcí nebo textových popisů.  Obsahuje všechny požadované informace. Studie by měla dodat veškeré informace, které potřebují pro rozhodnutí. Tím máme na mysli, že by se neměla omezit pouze na jednoduché ekonomické propočty, ale měla by vzít do úvahy i nepřímé vlivy a důsledky. Pokud se pro zpracování ÚSP použilo konzultantů, je třeba provést kontrolu, zda obsah a forma odpovídá smlouvě. 3.1.15 ČASTÉ CHYBY PŘI ROZHODOVÁNI O STUDII Pokud byla studie zpracována podle těchto kritérií a odpovídá nejen zadání ale i strategii podniku v oblasti procesů a IS, nebývá obvykle problém se schválením. Přesto však může v procesu schvalování dojít k určitým chybám:  Rozhodovatelé se již rozhodli předem. Když pomineme aspekt, že náklady na ÚSP v tomto případě nebyly vynaloženy účelně, může příliš rychlé kladné rozhodnutí vyvolat problémy při realizaci projektu. Některé důležité údaje a návrhy ve studii obsažené nemusely být dostatečně zváženy.  Linioví vedoucí rozhodovatelé mají tendenci k „akci". I zde může dojít k tomu, že důležité aspekty uvedené ve studii jsou přehlédnuty. To může mít opět dopad v etapě realizace projektu. Obsah zá- věrečného doporu- čení Forma zá- věrečného doporu- čení Chyby v procesu schvalování ÚSP FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 128  Vzhledem k tomu že rozhodnutí o ÚSP je závažné a závěry analýzy jsou formulovány nedostatečně konkrétně, neprovede se rozhodnutí a žádají se další informace. Tento posun v rozhodování může vyvolat tlak na plánování projektu s cílem zkrátit dobu řešení o čas vynaložený na dodatečná doplnění ÚSP. K ZAPAMATOVÁNÍ Kladným rozhodnutím o ÚSP přechází projekt do fáze nabídkového řízení a výběru do- davatele. 3.2 Fáze nabídkového řízení a výběru dodavatele Základní otázkou, kterou je třeba rozhodnout při realizaci projektu, je určení, kdo tento projekt bude realizovat? V zásadě existují dvě možnosti. Menší projekty spojené zejména S účelovou změnou funkcionality IS nebo inovací infrastruktury, často provádí oddělení ICT. Projekty rozsáhlejší se zadávají externímu dodavateli. Při rozhodování o způsobu provedení se obvykle zvažují výhody nevýhody obou variant. Mezi výhody zajištění projektu interním dodavatelem patří zejména znalost místního prostředí, lepší komunikace s koncovými uživateli a náklady na projekt. Tento způsob má však také určité nevýhody. Pracovníci interních ICT mohou jen těžko konkurovat profesionálním dodavatelům co do znalostí v metodách zavádění nového systému, nemívají k dispozici adekvátní vývojové nástroje a vzhledem k reálně existující vysoké migraci ICT odborníků často vzniká problém dlouhodobé údržby nového řešení. Významným nebezpečím při tomto řešení také bývá vznik malé interní skupiny (1-2 pracovníci) interních expertů, kteří mají monopol na znalosti o systému a často této situace využívají. Naproti tomu přednosti externího dodavatele lze shrnout do následujících bodů:  značné zkušenosti z vývoje u jiných zákazníků;  zavedená metodika projektování a realizace IS;  má k dispozici vývojové prostředky;  při pořízení typového řízení se náklady na vývoj a údržbu rozdělí mezi více zákaz- níků. Existují však také nedostatky tohoto řešení, kam by bylo možno zařadit zejména komunikaci mezi externími řešiteli a uživateli zákazníka a složitost při vyjednávání o obsahu projektu, při změnových řízeních zajištěním údržby systému. Při rozhodování o tom, kdo bude projekt realizovat je nutno také vzít do úvahy interní kapacity a znalosti nutné k úspěšné realizaci projektu. Realizace nabídkového řízení Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 129 3.2.1 VÝBĚROVÉ ŘÍZENÍ Celý proces předkontraktačního a kontraktačního jednání lze rozdělit do několika kroků, přičemž některé z těchto kroků se mohou v případě potřeby opakovat. Dochází tedy v tomto jednání k určitému druhu cyklu (Tabulka 12). Před udělením kontraktu probíhá na základě ÚSP plánování celého procesu. Zde se připravují konkrétní požadavky specifikované v ÚSP do tvaru odpovídajícího očekávaných obchodním podmínkám. Fáze vlastního udělení kontraktu je zahájena vyhlášením nabídkového řízení. Při plánování IS se obvykle používá žádost o návrh (Request for Proposal - RFP). Zde je osloveno několik potenciálních dodavatelů, kteří podle specifikace uvedené ve zveřejněném dokumentu mají dodat definovaný objem výrobků a služeb. RFP bývá většinou zveřejňována u složitých projektů jako je záměna nebo komplexní inovace ERP systému, rozsáhlá změna systémů technologie sítě s velkým objemem hardware apod. Tabulka 12 Fáze kontraktačních jednání příklad U menších finančních objemů, u kterých je možné přesně definovat požadavky a služby, se zasílá žádost o nabídku (Request for Quotati on - RFQ). Po uplynutí vyhlášené lhůty je nastartováno vlastní výběrové řízení. Jak před vlastním výběrovým řízením, tak i v jeho průběhu dochází k upřesnění definovaných požadavků. Zodpovědní potenciální dodavatelé mají totiž vždy celou řadu dotazů ke zveřejněným do- kumentům. V oblasti IS se často rozhoduje o dodavateli po schválení Úvodní studie proveditelnosti nebo po interním rozhodnutí o zahájení projektu. Předkontraktační a kontraktační jed- nání Fáze udělení kon- traktu FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 130 3.2.2 HODNOCENÍ NABÍDEK A JEDNÁNÍ O CENÁCH Podle rozsahu projektu bývají z předložených nabídek vybráni potenciální dodavatelé, kteří postoupili do dalšího kola, a nastává fáze výběru. Zde se hodnotí předložené nabídky ze dvou hlavních pohledů. Za prvé se hodnotí nabídnuté parametry a funkce, které dodavatelé ve svých nabídkách předložili a kontroluje se jejich soulad s vyhlášenými kritérii, případně ÚSP. Paralelně probíhá hodnocení ekonomické, tj. cena, obchodní podmínky, navržený časový termínový plán a další. Je zřejmé, že mezi těmito dvěma skupinami hodnocených parametrů existuje silná závislost a právě toto je důvodem, že výběr případně celé předkontraktační jednání může probíhat v cyklech. Výsledkem této fáze je výběr vítězného dodavatele a nastává fáze konkrétních obchodních a technických jednání. Zde se vyjednává zejména cena projektu a vazba této ceny na požadované funkční technické a kvalitativní kvality uvažované dodávky. Cenová vyjednávání obecně a u zavádění IS zvláště, souvisí s pohledem zákazníka a s pohledem dodavatele. U zákazníka jde o jeho pohled na cenu, kvalitu a termíny projektu. To znamená, že se zákazník rozhoduje, zda dá větší důraz na nižší ceny při kompromisu z hlediska kvality a času nebo trvá na kvalitě celé dodávky či rychlém řešení a je ochoten akceptovat vyšší požadované ceny. U dodavatele jde samozřejmě o pokrytí nákladů s přiměřeným ziskem. Může však také brát do úvahy velikost zákazníka a tedy jeho vyjednávací sílu, případně zájem získání dlouhodobého partnera. Musí také respektovat existenci konkurenčního prostředí. U projektů IS se v praxi vyskytují riskantní strategie dodavatele, který nabízí nízkou cenu za projekt a doufá, že přiměřený zisk získá v průběhu změnových řízení nebo v etapě údržby produktu. Již v této etapě může dodavatel ztratit důvěru zákazníka, který pak může trvat na různých formách ceny. K ZAPAMATOVÁNÍ Při projektech IS se v zásadě používají tři typy cen:  Cena vycházející z nákladů na práci a materiál - zde je stanovena pevná částka za čas pracovníků dodavatele a odhadovaná částka za dodaný hardware a licencovaný materiál. Tato cena je pravděpodobně nejvýhodnější z pohledu dodavatele. Pro zákazníky však představuje značné riziko. Zavádění IS je typické tím, že jsou požadavky uživatele relativně stručné a zpřesňují se teprve v průběhu řešení. Výsledkem může být nekontrolovatelný nárůst nákladů v průběhu projektu z důvodu víceprací. Zákazník je tedy plným nositelem rizika.  Pevná cena - při použití pevné ceny je specifikována dodávka IS, licence a hardware za předem stanovenou částku. Dodavatel při pevné ceně zakalkuluje pevné ceny a přiměřený zisk. Vzhledem k tomu, že v etapě před zahájením vlastního projektu nejsou známy detailní požadavky na funkce IS nebo jeho části, je přijetí pevné ceny pro dodavatele značným rizikem, a proto tento způsob bývá zpravidla odmítán. Jako kompromis se často vyjedná pevná cena nebo nákladová cena za etapu do ukončení Pohledy hodnocení nabídek Typy cen Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 131 analýzy a návrhu nového systému. Po schválení dokumentu o zavedení nového systému pak bývá stanovena pevná cena nebo pevná cena plus cílová odměna pro fázi vlastní realizace projektu.  Pevná cena se stropem - pevná cena se stropem je variantou pevné ceny s cílovou odměnou, kde cílová odměna je limitována maximální možnou částkou. I když dodavatelé tuto cenu akceptují seznačnými výhradami a je předmětem složitého vyjednávání, z praktických zkušeností autora ji lze označit jako rozumný kompromis pro obě strany. 3.2.3 METODA BQA Velké projekty IS, které si dávají za cíl celkovou změnu IS, změnu infrastruktury nebo změnu některého z programových modulů jako například systému CRM jsou obvykle zahájeny po schválení Úvodní studie proveditelnosti. Prvním krokem přípravné fáze je výběr dodavatele. Ten probíhá formou výběrového řízení, a to na základě hodnocení nabídek zaslaných uchazeči. Při tom se hodnotí celá řada ukazatelů nabídky. Ukazatele a priority podniku organizujícího výběrové řízení se však mohou lišit v poměrně širokém rozsahu. Některé podniky uvažují pouze s navrženým řešením, dodávkou požadovaných funkcí a nabízenou cenou. Jiné organizace kladou důraz na kvalitu týmu dodavatele, stanoví další doplňující cíle atd. V těchto případech jsou požadovány nejen požadované funkce nového systému. Může se jednat například o počet konzultantů dodavatele připravovaných pro projekt, nebo obchodní a finanční stabilitu uchazeče a jejich partnerů v případě subdodávek. Uvedené ukazatele se mohou hodnotit na základě „tvrdých" nebo „měkkých" kritérií podle toho o jaký podnik se jedná. Proto je někdy těžké nabídky zaslané do výběrového řízení hodnotit. V případě většího množství zaslaných nabídek může být hodnotící proces značně složitý, vyvolat chyby a zvýšit spotřebu času na hodnocení. Existuje celá řad nabízených nástrojů pro hodnocení nabídek (na příklad [IFT 2007], [SICT 2007], [TEC 2007]). Většina z nich používá strukturovaný přístup s využitím až několika stovek hodnotících položek. Při tom však podporují vyhodnocení pouze individuálních nabídek s pevným množstvím kritérií. Má-li se hodnotit větší množství nabídek a provést jejich srovnání, musí být vyplněno větší množství šablon, což stojí mnoho času. Pro přípravu doporučení vrcholovému vedení musí být výsledky získané těmito nástroji dále upravovány. Při hodnocení uvedených komplexních záležitostí se často používá metoda Balanced Scorecard (BSC) vypracovaná Kaplanem a Nortonem [KAP 2007]. Celkový přehled BSC byl transparentně prezentován mnohými autory ([ARV 2007], [FUR 2003] a dalšími). Navrhnul i jsme modifikaci této metody. Tuto modifikaci jsme nazvali Balanced Quotation Analysis. (dále jen BQA[VYM 2008]), jejíž základní charakteristiky a příklad použití uvádíme níže. Nástroje hodnocení nabídek BSC FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 132 POSTUP PŘI PROVÁDĚNÍ BQA Jednotlivé kroky BQA obsahují: V etapě přípravy výběrového řízení:  definici požadovaných funkcí a jejich důležitost (Nezbytné, Důležité, Opce- volitelné), jejich ocenění na základě bodových hodnot (známek);  definici dalších kritérií a jejich ocenění;  definici vah požadovaných funkcí v hodnocení;  definici vah dalších kritérií v hodnocení;  zavedení kritérií a jejich hodnot do tabulky nastavení. Po obdržení nabídek od firem - uchazečů:  prověrku úplnosti a integrity nabídek;  bodové ocenění navrhovaných jednotlivých funkcí a jejich řešení;  bodové ocenění plnění dalších kritérií;  srovnání nabídek včetně grafické reprezentace výsledků. MATEMATICKÉ VYJÁDŘENÍ METODY Hodnocení bloků řešení navrhovaných funkcí: Hodnota bloku funkčních požadavků se stanoví vzorcem 𝐹𝑉𝑖 = ∑ 𝐹𝑗 𝑃𝑗 𝑛 𝑗=1 (4) kde Fj – hodnota přidělená jednotlivému funkčnímu požadavku; Pj - priorita požadavku (v tabulce nastavení); n - počet funkčních požadavků v bloku. Průměrná hodnota funkčních požadavků je definována rovnicí 𝑀𝐹 = 1 𝑚 ∑ 𝐹𝑉𝑖 𝑚 𝑖=1 (5) kde m – počet bloků funkčních požadavků. Průměrná hodnota funkčních požadavků se pak násobí jejich vahou v celkové bilanci a hodnocení je určeno vzorcem 𝐴𝐹 = 1 𝑤 𝑀𝐹 ∗ 𝑉𝐹 (6) kde WF - váha funkčních požadavků v bilanci; w – celková hodnota všech vah v bilanci. Kroky BQA Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 133 Hodnocení dalších krit0rií se provádí pomocí vzorce 𝐴𝑂 𝑘 = 1 𝑤 𝑂𝑉𝑘 ∗ 𝑊𝑂 𝑘 (7) kde OVk – hodnota k-tého kritéria; WOk – váha k-tého kritéria v bilanci. Celková vyvážená hodnota (bilance) hodnocení je dána vzorcem 𝐴𝐵𝐴 = 𝐴𝐹 + ∑ 𝐴𝑂 𝑘 𝑙 𝑘=1 (8) kde l – počet kritérií. Uvedené vzorce lze realizovat různými způsoby a celkový výsledek znázornit například pomocí MS Excel. 3.3 Příprava smlouvy 3.3.1 OBSAH SMLOUVY NA DODÁVKU IS V etapě přípravy smlouvy dochází ke konečnému dojednání rozsahu služeb, výše ceny, záručních podmínek, termínu etap apod. Smlouva by měla obsahovat zejména následující části:  specifikaci zadavatel e a dodavatele;  předmět smlouvy;  rozsah prací;  podmínky platnosti smlouvy;  typ ceny a celkovou cenu zakázky;  podmínky a možnosti uplatnění změn;  způsob a termíny plateb;  záruční podmínky a termíny podpory a údržby;  výši a podmínky penalizace v případě nedodržení termínu;  ujednání pro případ předčasného ukončení;  ujednání o utajení informací a autorských právech. K ZAPAMATOVÁNÍ Struktura smlouvy bývá zpravidla koncipována tak, že vlastní text hlavní smlouvy je doplněn celou řadou příloh, které jsou deklarovány jako nedílné součásti tohoto doku- mentu. FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 134 Záruční podmínky a způsob podpory programového vybavení a jeho vlastností mohou být definovány zvláštními dokumenty. Ve fázi administrace a definitivního uzavření kontraktu se projeví kvalita vedoucího projektu. Složitost obchodních, finančních a technických jednání vede k tomu, že vedoucí projektu, případně hlavní vyjednavač na straně zákazníka musí mít dostatečné kompetence a znalosti nejen v oblasti ICT, ale také v oblasti obchodního práva a financí. Tento fakt je jedním z důvodů, proč se u velkých projektů IS vyplácí použít dvojice hlavní vedoucí projektu - technický vedoucí projektu. U nadnárodních projektů dochází k dalšímu jednání a rozhodnutím, a to zejména v oblasti struktury a rozsahu dodávek, řešitelských týmů odběratele a způsobu školení. 3.3.2 GENERÁLNÍ DODAVATEL, SUBDODAVATELÉ, LOKÁLNÍ PARTNEŘI Použití systémového integrátora nebo generálního dodavatele projektu IS představuje zvláštní případ. Smlouva se podepisuje zpravidla s jedním partnerem. Systémový integrátor je zodpovědný za dodávky a kvalitu produktů a služeb svých subdodavatelů. Zde se můžeme setkat s pokusy subdodavatelů o přímá jednání se zákazníkem. Tyto pokusy je třeba ze strany zákazníka zásadně odmítat. Sebelepší smlouva totiž nedokáže formulovat všechny možné varianty budoucích stavů. Znamená to tedy, že mezi dodavatelem a zákazníkem musí existovat vysoká důvěra. Tato důvěra může být založena buď na zkušenostech z minulých dodávek, nebo u nových smluv a vztahů na chování potenciálního dodavatele a zákazníka v etapě vyjednávání. Přímá jednání zákazníka se subdodavateli mohou tuto důvěru narušit. Konflikty se subdodavateli nastávají zpravidla při dojednávání prací navíc a při termínových skluzech. Proto je vhodné, do smlouvy zakotvit klauzuli obsahující závazek odběratele, že nebude ani v těchto případech se subdodavateli jednat. Složitá situace nastává u nadnárodních projektů. U hlavního partnera na straně zákazníka (například koncernové centrály) se generální dodavatel setkává zpravidla s pochopením. Odlišná je situace u lokálních Poboček. Lokální partneři generálního dodavatele pochopitelně nejsou záměrem zavést jednotný nebo centralizovaný informační systém nadšeni. Přišli o obchod a obrat, který realizovali s lokální Pobočkou a také o určitý vliv. Personál Pobočky, generálním ředitelem a ICT manažerem počínaje a klíčovými uživateli konče zpravidla tomuto záměru také není nakloněn a je náchylný ke hledání nejrůznějších zástupných problémů. Autor zažil případ, kdy koncernová centrála byla nucena i za cenu určitých nákladů ukončit veškeré smlouvy lokálních Poboček s lokálními dodavateli, aby se vytvořil prostor pro práci generálního dodavatele. Tento proces samozřejmě vyvolal návazná jednání ve smyslu výpovědních lhůt a penalizací. Administrace a uzavření kontraktu Systémový integrá- tor/generální doda- vatel Konflikty se subdo- davateli Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 135 3.3.3 DOHODA O TYPU ŠKOLENÍ PERSONÁLU ODBĚRATELE I když z hlediska smluvních ujednání týkajících se dodávky nepředstavuje školení personálu odběratele zdánlivě závažnou tématiku, je školení pro celkový úspěch projektu podstatné. Při tom se v praxi opakovaně ukazuje, že pouze úspěšný projekt nebývá spojen s právními spory. Navíc školení personálu souvisí se změnami pracovních postupů, tedy i popisem práce. Tím vznikají vztahy na otázky související s pracovně právními předpisy. Při školení uživatelů se používají dvě hlavní varianty:  Plné zaškolení dodavatelem - tato varianta je u velkých projektů jen obtížně realizovatelná a to hlavně z finančních důvodů. U nadnárodních projektů zde navíc působí jazyková bariéra. Jen generální dodavatel má přehled o celkovém řešení a dodávaných funkcích. To znamená, že klíčoví pracovníci dodavatele nebo jeho subdodavatelů by museli školit v různých jazykových a kulturních prostředích. Z tohoto důvodu lze potíže považovat za předem dané. Teoreticky by bylo možné pro zaškolení použít lokálních subdodavatelů. Ti však zpravidla mají přehled jen o části řešení, např. o základní dodávce standardních modulů. O způsobech práce se zákaznickými moduly, nebo standardními moduly připravenými generálním dodavatelem by se stejně museli nechat zaškolit. Výhodou tohoto řešení je, že dodavatel je jasně zodpovědný za úroveň školení.  Metoda „train the trainer" - klíčoví pracovníci odběratele jsou proškoleni dodavatelem. Toto zaškolení stejně potřebují pro provedení akceptačních testů. Tito lokální „trenéři" poté zajistí školení koncových uživatelů. Uvedená metoda je pro zákazníka cenově výhodnější. Přes uvedené výhody a nevýhody obou zmíněných metod zůstává riziko některých nejasností. Materiály používané pro školení musí obsahovat firemní „hantýrku", aby řadoví uživatelé problematice rychle porozuměli. Proto jsou podklady pro školení téměř vždy zajišťovány odběratelem. To znamená, že v každém případě existuje potřeba jasného smluvního zajištění postupů v oblasti školení a řešení případných výjimečných stavů. Navíc platí, že klíčoví „trenéři" jsou již ke konci projektu značně unaveni a opotřebeni. Je zde určité nebezpečí pracovních sporů. Proto pro úspěšnou realizaci je nutné již v rozhodování o změnách v pracovních postupech a způsobu školení používat znalost pracovně právních před- pisů. 3.3.4 STANOVENÍ ČASOVÉHO PLÁNU PROJEKTU Časový plán projektu je v etapě přípravy smlouvy podkladem pro výpočet nákladů u dodavatele a tedy i pro jednání o ceně. V průběhu projektu je předmětem pravidelných kontrol a upřesňování oběma smluvními stranami. V případě projektových změn nebo zpoždění projektu je základem pro jednání o cenových změnách případně sankcích. Riziko ne- jasností Časový plán pro- jektu FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 136 K ZAPAMATOVÁNÍ Všimněme si, že existují různé pohledy a významy ze strany odběratele i dodavatele. U zákazníka jde zejména o to, které interní zdroje budou v kterém časovém období na projektu vázány. Pokud je pro realizaci nového IS zvolena čistá projektová struktura, nebývá plán čerpání zdrojů kritickým místem, i když může přitom docházet k jejich nižšímu využití v určitých obdobích. U typických projektů IS převládají maticové struktury, kde je plánování účasti rozhodujících uživatelů na projektu svázáno s jejich běžnými rutinními činnostmi. Právě tento fakt může v projektu vytvářet úzká místa. Dodavatelé mívají při jednáních o smlouvě často tendenci přistupovat na velmi náročné časové plány s malými rezervami. Při tom pochopitelně pracují na více projektech u více zákazníků. Pro velmi náročné projekty používají nejzkušenější pracovníky, jako jsou konzultanti a kvalitní programátoři. Tito pracovníci představují u dodavatelů kritické zdroje. Vzhledem k jejich ceně se dodavatelé pochopitelně snaží kritické zdroje nasazovat do více projektů. Proto je u dodavatele stanovení správného časového průběhu projektu a zejména stanovení určitých rezerv zásadní věcí. Pokud totiž dojde ke zpoždění některé z projektových etap, mohou rozhodující zdroje dodavatele chybět v daném projektu nebo při realizaci zakázky u jiného zákazníka. U nadnárodního projektu může v případě nedodržení časových plánů docházet v důsledku složitých vazeb u zákazníka i k dalším ztrátám, jako jsou náklady stornování letenek a rezervace hotelů, náklady přesunů důležitých akcí a činnosti v lokálních pobočkách a jiné. K ZAPAMATOVÁNÍ Z uvedených důvodů je nutno ve smlouvě dobře ošetřit plnění časových plánů, reakci na mimořádné situace a případné sankce za nekvalitní plnění nebo časová zpoždění. 3.3.5 PROBLEMATIKA VÝBĚRU DODAVATELŮ A DALŠÍCH PODMÍNEK SMLOUVY U NADNÁRODNÍCH PROJEKTŮ Po rozhodnutí o přípravě projektu je prvním úkolem rozhodnout o dodavateli. Pomineme-li problematiku výběrových řízení, vznikají v souvislosti s určením dodavatele nadnárodního projektu četné otevřené otázky a výzvy, které mají právní kontext: Výběr do- davatele nadnárodních pro- jektů Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 137  Sídlo firmy dodavatele - sídlo firmy dodavatele většinou také souvisí s určením měny, ve které budou provedeny platby za dodávky a služby. Pokud je sídlo dodavatele ve stejné zemi, jako je sídlo koncernové centrály, je otázka vyřešena prakticky ihned. Rada dodavatelů však nesídlí v Eurozóně, někdy jsou jejich součásti umístěny i mimo Evropu. Do zavedení Eura se tyto otázky často řešily platbami v dolarech. Nyní jsou cenová jednání spojena i s určitými kurzovými riziky, zejména tam, kde se může za určitých okolností jednat o platby ve více měnách. Tato rizika je nutno ošetřit v hlavní smlouvě.  Platnost práva - centrála, která rozhodla a zadává projekt, vždy prosazuje platnost práva té země, ve které centrála sídlí. Velcí dodavatelé se však tomuto přístupu brání, pokud sídlí v jiné zemi než odběratel. V jednom z projektů, které autor vedl, vznikla potřeba dohodnout se, zda bude platit právo rakouské, české nebo dánské. Jednání nakonec vyústila v platnost rakouského práva, ale jak uvedeme v Případové studii, ani tato dohoda nezabránila potížím později. Specifikem také mohou být drobné rozdíly v pojetí autorského práva v jednotlivých zemích.  Generální dodavatel, nebo více dodavatelů - u velkých dodávek, jakou jsou nadnárodní ERP systémy, se zpravidla postupuje cestou generálního dodavatele, který garantuje dodávky hardware, standardního software, parametrizace a naprogramovaných zákaznických modulů. S tím souvisí opět sídla firem subdodavatelů, platnosti záruk apod. I když je právní formulace smluv o subdodávkách věcí generálního dodavatele, je nutno postupovat při přípravě hlavní smlouvy obezřetně, což se pokusíme více osvětlit později.  Předpoklady podpory dodaného řešení v cílových zemích (Pobočkách) - je na odběrateli, aby posoudil schopnost firem, které až dosud zajišťovaly lokální podporu stávajících řešení, podporovat i řešení nové. Pokud panuje se službami lokálních subdodavatelů spokojenost, jsou doporučeni generálnímu dodavateli. Ten pak s nimi uzavře smlouvy ve své režii. Při tom je nutno posoudit i právní předpoklady pro uzavření a fungování uvedených smluv v cílových zemích. Jedná-li se o nadnárodní projekt, bývá očekávaný rozsah dodávek a služeb stanoven již před zahájením výběrového řízení. U projektů informačních systémů obecně, u nadnárodních projektů zejména však podrobná specifikace očekávaných funkcí bývá předmětem rozsáhlých úprav v průběhu přípravy prováděcího projektu, tedy v etapě analýzy. To má vliv nejen na jednání o ceně, ale vyvolává také obtíže při vlastní realizaci. Jsou totiž obvyklé dlouhé diskuze o tom, které požadované funkce jsou předmětem smlouvy a co je navíc. U nadnárodních projektů je navíc nutno vzít do úvahy požadovaná lokální specifika. Ne všechny požadavky Poboček totiž tvoří zástupné problémy, ale jsou vyvolány nutností reagovat na místní podmínky na trhu, případně odlišnosti lokální legislativy, které jsme zmínili výše. Proto rozsah dodávek tvoří často dokument značného rozsahu a přikládá se k hlavní smlouvě jako příloha. Důležité z hlediska případných dalších jednání v průběhu projektu je jednoznačné konstatování v hlavní smlouvě, že příloha (přílohy) specifikující rozsah dodávek, tvoří nedílnou součást smlouvy a má přednost před jakýmikoli obchodními FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 138 podmínkami dodavatele. Autorovi se v praxi osvědčilo, že k rozsahu dodávek byla připojena další příloha specifikující obchodní podmínky odběratele. Tím se zpravidla podařilo jasně specifikovat požadavky na kvalitu celého projektu. Stanovení jazyka je důležitou součástí celého procesu. Jde se o to, že některé právní termíny mohou mít v různých zemích poněkud jiný detailní význam. Autor se několikrát setkal s tímto problémem při stanovení autorských práv a při jednání o licencích. Proto lze jen doporučit, aby součástí hlavní smlouvy mezi stranami, které mají sídlo v různých zemích, byla na začátku jasná definice používaných pojmů v jazyce smlouvy. Jedním z důležitých závazků odběratele v případě nadnárodních projektů v oblasti ICT je závazek vytvořit nadnárodní řešitelský tým. Jde nejen o to, že nadnárodní řešitelský tým může sjednotit lokální stanoviska na straně odběratele, ale také zaručit, že nebudou přehlédnuty některé místní právní nebo kulturní zvláštnosti. Tento závazek má však své důsledky. Do nadnárodního řešitelského týmu musí být jmenováni pracovníci s dostatečnou rozhodovací pravomocí. To jsou zpravidla někteří důležití linioví nebo štábní řídící pracovníci. Pro to, aby mohli přijímat důležitá rozhodnutí v průběhu projektu, je vhodné, aby byli vybaveni příslušnými formálními dokumenty. Navíc musí být vyřešeny některé pracovně právní otázky spojené s jejich vysokým zatížením po dobu projektu. U nadnárodních projektů vyjednávání vedou zástupci centrály. Při jednání o odborných otázkách a lokálních úpravách se jednání účastní členové nadnárodního řešitelského týmu, pokud byl již jmenován. Podle toho, který model se zvolí, vede se jednání o ceně jednotného řešení nebo centralizovaného řešení jako jednoho balíku. Autor se však setkal i s modelem, podle kterého centrála financuje pouze kritické části řešení, jako jsou speciální moduly realizující společný firemní know-how. Pobočky v tomto případě financují standardní licence na použité programové vybavení. Tento model nedoporučujeme, protože kromě složitých právních otázek souvisejících s možnými odlišnými právními úpravami v jednotlivých zemích, dochází k rozmělnění pravomocí a zodpovědností za projekt. V důsledku toho nutně vzniká opět heterogenní systém. 3.4 Fáze vlastního návrhu IS Po podepsání smlouvy oficiálně, neoficiálně však i předtím je zahájena vlastní projektová a realizační fáze IS. Podle toho jak velký je projekt, dochází buď k přípravě naráz, nebo k zavádění jednotlivých částí (modulů připravovaného řešení). Nezáleží na tom, zda projekt realizuje externí dodavatel nebo interní pracovníci podniku, protože k dosažení cíle jsou používány velmi podobné postupy. PRŮVODCE TEXTEM V dalším textu budeme vycházet z maximální varianty zavedení nového IS externím dodavatelem. Připomínáme, že na základě našich zkušeností preferujeme modifikovaný spirálový model projektu IS. Stanovení jazyka Nadnárodní řešitelský tým Vyjednávání u nad- národních projektů Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 139 3.4.1 DETAILNÍ ANALÝZA Prvním krokem realizace je provedení detailní analýzy požadavků na nový systém. Cílem detailní analýzy je podrobně definovat detailní požadované funkce nového systému. Vychází se při tom z firemní strategie, výsledků modelování podnikových procesů, pokud se výsledky tohoto modelování nepromítly již do ÚSP. Dalším vstupem jsou závěry ÚSP, přičemž může docházet k určitým drobným korekturám. Dalším cílem detailní analýzy je dekompozice navrhovaného řešení do takových částí, aby bylo možno provést podrobný rozpis prací a zpracovat časové plány projektu. V rámci dekompozice se v etapě detailní analýzy uplatňují dva typy:  Dekompozice funkční - v této fázi se stanovují nové funkce IS a jejich vazby jak navzájem, tak k okolí zaváděného systému. Dekompozice končí u samostatně řešitelných a prováděných pracovních úloh a procesů. Pokud v rámci přípravy projektu došlo k modelování jednotlivých procesů, měla by funkční dekompozice výsledky modelování respektovat jako závazný vstup  Dekompozice předmětová - zde jde v podstatě o stanovení nezbytných prvků hardware a infrastruktury, které se projekt týká. Předmětová dekompozice pochopitelně vychází ze základního zadání, které bylo navrženo v etapě ÚSP. V praxi však běžně dochází k tomu, že jak jsou postupně analyzovány potřebné funkce a prováděna jejich dekompozice, mění se pohledy či požadavky na hardware a proto se může předmětná dekompozice od návrhu v ÚSP částečně lišit. V etapě předmětové dekompozice je možno provést kontrolní simulace průchodnosti procesů a výkonnosti sys- tému. K ZAPAMATOVÁNÍ Forma provedení detailní analýzy bývá různá. Většinou se používají metody workshopů, jejichž jednotliví účastníci jsou budoucí uživatelé a ICT odborníci zákazníka. Workshopy probíhají zpravidla podle dílčích oblastí navrhovaného řešení. To znamená, že se jich účastní členové dílčích pracovních nebo projektových týmů. Workshopy jsou moderovány konzultanty dodávající firmy. Skutečnost, že se detailní analýza provádí v dílčích týmech, vede k nutnosti pečovat o integritu celého řešení. Zajištění integrity je jedním ze základních úkolů vedoucích projektu jak na straně dodavatele, tak na straně odběratele. Probíhá obvykle formou koordinace vedoucích dílčích projektových týmů v průběhu detailní analýzy a dalších kroků, s tím, že na úrovni Cílového konceptu řešení dochází k integračnímu workshopu. Detailní analýza Dekompo- zice funkční Dekompozice před- mětová FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 140 3.4.2 CÍLOVÝ KONCEPT Po skončení detailní analýzy požadovaných funkcí a po zpracování rozpisů prací je nutno vytvořit dokument, který by se stal základem dalšího postupu řešení a zároveň nástrojem kontroly z hlediska věcného i nákladového. Pro dokumenty tohoto typu se ujala celá řada názvů. Vrana a Richta [VRA 2005] doporučují používat termín „Zaváděcí projekt", Svozilová [SVO 2006] používá důsledně termín Plán projektu pro všechny typy projektů. Německy mluvící literatura uvádí název Pflichtenheft. V našem pojetí budeme vycházet z toho, že uvedený dokument popisuje způsob realizace cílů celého projektu, a to na základě celkového konceptu řešení. Proto budeme používat termín "Cílový koncept". Účelem Cílového konceptu je komplexní návrh architektury celého řešení. Důvodem pro vznik Cílového konceptu řešení je také potřeba mít nástroj, pomocí kterého dojde k ohodnocení úspěšnosti implementace IS. Cílový koncept obsahuje zejména:  podrobný popis funkcí systému zachycený na příklad procesním modelem;  architekturu datového základny;  návrh řešení prvotní konverze dat a jejich převodu ze stávajícího do nového systému;  návrh potřebného hardware a celkové infrastruktury;  návrh způsobu konverze dat do nového systému;  aktualizaci spotřeby času a zdrojů;  údaje o množství informací pohybujících se v rámci nového systému (na příklad počty uživatelů, počty dokladů, počty položek zboží, strukturu hospodářských středisek a jiné);  bezpečnost systému a navrhované systémy oprávněných uživatelů. Výstupem z etapy Cílového konceptu je schválený návrh celkové architektury a funkcí systému, dále časových plánů a plánů zdrojů a aktualizace harmonogramů jednotlivých kroků realizace. Nedílnou součástí je návrh komponent infrastruktury, mezi které patří zvláště:  Definice systémového software zejména pro servery, nástrojů správy počítačové sítě, případně softwarových nástrojů pro spojení pracovních stanic s aplikačními a databázovými servery v členění požadovaném vlastní aplikací.  Určení složek hardware, tedy serverů, nových komponent počítačové sítě nebo potřebné výměny jejích stávajících komponent.  Specifikace dalších požadovaných pracovních stanic, vyplývající z předpokládaného použití aplikačních a systémových programových komponent.  Návrh organizace provozu včetně definice rolí rozhodujících pracovníků pro správný provoz infrastruktury. Cílový koncept Obsah cí- lového konceptu Komponenty in- frastruk- tury Role pro- vozních pracov- níků Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 141 Rozhodující role provozních pracovníků jsou definovány v rámci personálního zajištění provozu. Podle velikosti podniku je možné definovat více rolí pro jednoho pracovníka nebo naopak více pracovníků pro jednu roli. Zejména je nutno definovat následující role:  Správce číselníků použitých v systému - tato role nebývá vždy dostatečně doceněna. Většinou vznikne v důsledku určitého vývoje v oddělení ICT. Pokud však dochází ke změně podstatné části IS, je problém číselníků jedním z klíčových problémů vlastní realizace. V průběhu pozdějšího provozu poté správce číselníků dohlíží mimo jiné na to, aby nedocházelo k nedostatku volných číselných kódů, jako jsou čísla faktur, čísla objednávek, sériová čísla apod. Nedostatky v oblasti číselníků vedou zpravidla vždy k závažným problémům v provozu.  Administrátoři hardware - sem patří správci sítí, serverů a podpora pracovních stanic. Při využití případného outsourcingu jsou tyto role definovány plně nebo částečně u dodavatele.  Správce programových komponent - podle definovaných funkcí IS je třeba vytvořit více rolí, které jsou zodpovědné za správu, rozvoj, případně změnové řízení jednotlivých komponent IS a jejich integrace s ostatními součástmi. Tyto role bývají definovány v oddělení ICT.  Databázový administrátor. Zvláštním typem správce je administrátor datové základny. Kromě toho, že pečuje o vlastní softwarové prostředky správy databáze a spolupracuje se správci hardware, by měl být znalcem obsahu databáze a její výkonnosti. (optimalizace indexů, výkonnosti, datových úložišť a dalších prostředků). Často také vykonává část funkcí spojenou se zálohováním dat v systému a zodpovídá za možnosti obnovy dat v případě závažných poruch databázového systému. Účelem Cílového konceptu není vytvořit podklady pro rozhodnutí zákazníka o zavedení, toto bylo učiněno již v etapě ÚSP. Smyslem Cílového konceptu také nemůže být zpracování zcela vyčerpávajícího technického projektu, obsahujícího detailní popis hardware i software. Je na dodavateli, aby funkce a technické prostředky specifikované v Cílovém projektu optimálním způsobem zavedl a jejich zavedení zdokumentoval. Vzhledem k tomu, že v průběhu realizace a testování zaváděného projektu dochází k požadavkům na určité změny, případně k upřesněním, které vznikly teprve při vlastní realizaci, byla by nadměrná podrobnost Cílového konceptu s největší pravděpodobností zbytečnou prací a přinesla by zvýšení nákladů na projekt. Na druhé straně však Cílový koncept velmi často obsahuje podklady pro definitivní upřesnění ceny celkového projektu. V Tabulka 13 jsou jako příklad shrnuty doporučené části Cílového konceptu pro obchodní organizaci. Z této tabulky jasně vyplývá doporučený rozsah a vazba na smlouvu o zavedení IS. V této fázi se také definitivně rozhodne o metodě zavedení. U velkých projektů se zpravidla pokračuje v spirálovém způsobu zavedení, případně o tom, které části projektu budou zavedeny s využitím metody prototypování. Agilní metodiky, které jsme zmínili výše, se u velkých projektů obvykle nepoužívají, případně se rozhodne o jejich využití v určitých přesně specifikovaných částech a etapách realizace. Tato rozhodnutí jsou podkladem pro rozpis prací na realizaci. Cílový koncept pro obchodní or- ganizaci FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 142 Tabulka 13 Obsah dokumentu Cílový koncept IS obchodní organizace Popis současného stavu Organizační struktura zákazníka Technické vybavení Stávající programové vybavení Operační systémy Aplikační vybavení Návrh řešení Datová základna Počítačová sít' Výpočetní technika Servery Pracovní stanice Tiskárny Systémové programové vybavení Servery Pracovní stanice Zálohování dat Standardní typový programový balík Aplikace dodatečných modulů Moduly vytvořené na zakázku Návrh organizace datové základny Zajištění komunikace mimo centrálu Komunikace s jinými IS Komunikace se vzdálenými pracovišti zákazníka Nutná organizační opatření vztahující se k zavedení IS Návrh konverze dat Návrh školení Organizace akceptačních zkoušek Řízení projektu Nastavení a řešení požadovaných funkcí Finance Oběh účetních dokladů Účtová osnova atd. Prodej a pohledávky Správa zákazníků Zakázky a prodej Ceníky atd. CRM Servis Předměty servisu Servisní zakázky Dispečink atd. Nákup a závazky Správa dodavatelů Objednávky a nákup atd. Zásoby Zboží Evidence skladových položek atd. Specifické funkce Komunikacespartnerskými firmami Propojení s B2B atd. Zakázkové moduly Rozšířený systém uživatelských oprávnění Rezervace zboží na servisní zakázku Specifické sestavy atd. Cílový koncept je základním dokumentem zajišťujícím integraci celého řešení. Proto po jeho zpracování dodavatelem dochází k jeho kontrole ze strany hlavních uživatelů nového řešení. Tato kontrola může mít celou řadu forem. Nejvíce se osvědčila forma interního připomínkového řízení (dílčích oponentur), které může mít i několik kol. Dílčí otázky nebo námitky zákazníka dodavatel buď zapracovává do nových verzí Cílového konceptu, nebo po dohodě s vedením projektu připravuje požadované změny. Po dílčích oponenturách je Cílový koncept Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 143 nutno svolat závěrečný integrační workshop, během kterého dojde ke kontrole celkové integrity navrhovaného řešení. Poté je Cílový koncept schválen a projekt pokračuje přípravou realizace zavedení. 3.4.3 PLÁNOVÁNÍ ZDROJŮ A ROZPIS PRACÍ V etapě analýzy návrhu nového systému se práce a kapacity obvykle plánují na základě smlouvy o dodávce. Důvodem je, že dokud není návrh řešení (Cílový koncept) rozpracován do dostatečné hloubky, není možné realisticky plánovat strukturu a časový sled prací. Proto se podrobný rozpis prací provádí většinou současně s prací na Cílovém konceptu. Cílem rozpisu prací je detailní specifikace požadovaných funkcí a jim odpovídajících úkolů jednotlivých řešitelských dílčích týmů. Rozpis prací je základem prováděcího časového harmonogramu a podkladem pro sledování průběhu projektu. Na základě návazností mezi jednotlivými úkoly je také základem pro obsazení rolí v projektu, případně upřesnění projektové struktury. V praxi se podrobný rozpis prací často aktualizuje a to zejména při schválení změn projektu. Proto je práci na rozpisu prací nutno vždy považovat za iterativní proces. Výstupem podrobného rozpisu prací je:  časový harmonogram realizační části projektu, který vznikl na základě Cílového konceptu;  soupis úkolů a zodpovědností na jednotlivých dílčích projektech;  plán čerpání nákladů na projekt;  rozbor možných rizik a návrh opatření pro jejich omezení. Dílčí úkoly, které tvoří rozpis prací, představují obvykle nejnižší úroveň, na kterou jsou práce v projektu rozepisovány, řízeny a vyhodnocovány. Jejich popis obsahuje:  výsledek, kterého má být daným dílčím úkolem dosažen;  předpokládaná pracnost úkolu u dodavatele i odběratele;  jsou zařazeny do časového sledu projektu (časový sled, návaznost, nejkratší nebo nejzazší termín provedení, apod.);  přiřazení zodpovědnosti za úkol určité osobě nebo skupině osob;  používají se jako základní metrika projektu, kdy je výsledný stav porovnáván s předpokladem a to z pohledu času, čerpaných nákladů, dosaženého výsledku a kvality provedení. Z praxe vyplývají některá doporučení, jak účinně připravit časový rozpis prací. Doporučuje se:  Využít podklady nebo zkušeností z podobných projektů z minulosti. Zde lze s výhodou využít zkušeností, případně metodických postupů dodavatele. U interních ICT projektů, zejména menšího rozsahu však taková zkušenost často chybí. Rozpis prací Doporučení pro přípravu rozpisu prací FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 144  Využívat brainstorming klíčových uživatelů a členů týmu. Jedná se o velmi účinnou metodu. Jejich využití, případně efekt však závisí na kvalitě moderátora. Zde se může v plné míře ukázat rozdílnost „politických" zájmů jednotlivých uživatelů.  Opakovaně diskutovat o fázích a oblastech projektu. Nejde o to znovu otevírat již uzavřená rozhodnutí nebo vnášet pochybnosti do existujících řešení. Ze samotné podstaty ICT projektu vyplývá nutnost v rámci zajišťování integrity provádět určité iterace.  Rozpis úkolů provádět důsledně metodou shora dolů. V rámci přípravy rozpisů prací existují určitá nebezpečí. Jedná se hlavně o následující případy:  Nebezpečí rychlé definice struktur - přílišný spěch a fixace struktur, požadovaných funkcí, dat a dalších částí projektu. I když tento postup teoreticky správný není, v praxi k němu běžně dochází. Používá se také u agilních metodik. Protože v sobě skrývá určitá rizika, nelze jej doporučit.  Nebezpečí nesprávně stanovené úrovně podrobnosti - zde jde zejména o to, aby úroveň podrobnosti dekompozice funkcí a odpovídajících prací byla v zásadě stejná. Nejpozději na úrovni integrace celého řešení by mohlo docházet k problémům, pokud by některé části byly definovány příliš podrobně ve vztahu k částem nebo funkcím jiným.  Nebezpečí přílišného spěchu - často pod tlakem vedení dochází ke snaze zavádění systému urychlit, zkrátit nebo rychle dohnat vzniklá zpoždění. Takový postup lze považovat za fatální chybu, která nakonec vždy vede k následným opravám, druhotným chybám, nekonzistencím a v důsledku toho k celkovému nebo dalšímu zpoždění projektu  Nebezpečí přílišné podrobnosti plánování - při plánování je třeba dodržovat pohled na definované celkové cíle projektu a schválený Cílový koncept řešení. Pokud se tento princip nedodržuje, dojde k tomu, že se plán rozpadne do velkého počtu dílčích úkolů. Pak je jejich integraci těžké kontrolovat. Tím vzniká nebezpečí, že dojde k odchylce od skutečných cílů projektu. Současně s tím se ztrácí vazba dílčích prací k celkovým cílům a silně se znesnadňuje proces řízení projektu. Výsledkem jsou termínové skluzy a ztráta motivace jednotlivých účastníků. Podrobný rozpis prací a související časové plány mají různý význam pro dodavatele a zákazníka.  U zákazníka jde zejména o to, které interní zdroje budou v kterém časovém období na projektu vázány. Pokud je pro realizaci nového IS zvolena čistá projektová struktura, nebývá plán čerpání zdrojů kritickým místem, i když může přitom docházet k jejich nižšímu využití v určitých obdobích. U typických projektů IS převládají útvarové struktury, kde je plánování účasti rozhodujících uživatelů na projektu svázáno s jejich běžnými rutinními činnostmi. Právě tento fakt může v projektu vytvářet úzká místa. Význam rozpisu prací a ča- sového plánu Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 145  U dodavatele je stanovení správného časového průběhu projektu a zejména stanovení určitých rezerv zásadní věcí. Pokud totiž dojde ke zpoždění některé s projektových etap, mohou rozhodující zdroje dodavatele chybět v daném projektu nebo při realizaci zakázky u jiného zákazníka. K ZAPAMATOVÁNÍ Časové plány se často zpracovávají ve formě Ganttových diagramů. Bývají doplněny i diagramem milníků. Jako podpora zpracování těchto plánů se obvykle používá produkt MS Project. Mohou se také používat také různé síťové diagramy nebo diagramy PERT, případně výpočty kritických cest. 3.5 Realizační fáze 3.5.1 PŘÍPRAVA REALIZACE V rámci Cílového konceptu byl stanoven způsob, jakým se provede implementace systému. Bylo také rozhodnuto, které části požadovaných funkcí budou pokryty standardními typovými moduly dodavatele, u kterých modulů dojde k úpravám nebo nestandardní parametrizaci a které části požadované funkcionality je třeba zajistit novými (zákaznickými) programovými moduly. Bez ohledu na to, jaký způsob zvolíme při implementaci, lze tuto etapu rozdělit do následujících kroků:  instalaci hardware;  instalaci a konfiguraci standardních modulů software;  programování, instalaci a testování zákaznických modulů, které probíhá paralelně s výše uvedenými aktivitami. Při přípravě zákaznických modulů se vychází z návrhů funkcí definovaných v Cílovém konceptu. V rámci těchto prací lze doporučit:  Současně nebo ihned po schválení prototypů se připravují prototypy požadovaných funkcí (logiky) a probíhá jejich prověření.  Většina stávajících programových balíků je v současné době konstruována jako otevřený systém. Nastavení základních potřeb zákazníka a přizpůsobení typových funkcí jeho požadavkům se tedy nemusí provádět programováním. Místo toho se provádí parametrizace systémů, nebo příprava parametrizace předem připravených zákaznických modulů dodavatele se snahou co nejvíce omezit programování. Kroky přípravy rea- lizace Doporučení pro přípravu zákaznických mo- dulů FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 146 Zvláštní programové moduly totiž vždy vyvolávají problémy při aktualizaci (Upgrade) modulů typových. Programové změny, které byly provedeny nad rámec parametrizace, se v těchto případech vždy musí do značné míry přeprogramovat.  V rámci parametrizace se v kódech programu může provádět i příprava tiskových vzorů hlavních výstupních dokladů, případně přidání nezbytných polí do databázových tabulek, která by umožnila nebo usnadnila rychlé hledání v databázích. K ZAPAMATOVÁNÍ Souběžně s pracemi na úpravě zákaznických modulů vzniká zákaznická dokumentace. Etapa přípravy realizace plynule přechází do etapy převodu dat a akceptace. 3.5.2 PLÁNOVÁNÍ, ORGANIZACE A PROVEDENÍ PŘEVODU DAT Převod dat, pro který se někdy se používá termín konverze dat, je klíčovou částí etapy realizace systému. V praxi bývá tato problematika podceňována. U velkých projektů nebo u změny modulů, které vyvolávají změny ve struktuře datové základny, je nutno na převody dat plánovat dostatečně velkou časovou rezervu. Přípravu převodu dat je třeba zahájit v etapě Cílového konceptu řešení. Vlastní převod dat znamená export dat ze stávajícího systému a jejich import do struktur databázových tabulek systému nového. Tato zdánlivě jednoduchá procedura však má určitá úskalí. Jejich shrnutí uvádí Tabulka 14. Tabulka 14 Úzká místa převodu dat Kde Úzké místo Důsledek Dodavatel neznalost vztahů mezi původními datovými struktu- rami závažné chyby v systému Oddělení IT nedostatek kapacit v důsledku administrace běžícího IS riziko zpoždění Datová zá- kladna nového IS jiné datové struktury než ve stávajícím IS dodatečné programování, ruční opravy a zavádění nejasné vazby na části IS nepodléhající změně dodatečné programování, zpoždění Uživatelé nedostatek času na kontrolu pře- vodu kritické riziko Na druhé straně je nutno využít etapu přípravy a provedení konverze dat k vyčištění datové základny. Je vhodné provést úpravy uvedené v Tabulka 15. Převod dat Úpravy při převodu dat Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 147 Tabulka 15 Doporučené úpravy při konverzi dat Doporučená úprava Provádí odstranit duplicity údajů o zákaznících uživatelé na základě podkladů IT zrušit nebo upravit nepatřičná data a údaje v souborech, která se tam dostala v rámci „tvůrčí" činnosti koncových uživatelů (různé poznámky, znaky atd.) uživatelé na základě podkladů IT, resp. automaticky aktualizovat adresy, popisy, pomocné údaje a jiné IT na základě podkladů uživatelů doplnit chybějící údaje uživatelé připravit konverzní programy IT ruční opravy tam, kde nebylo možno činnosti alespoň částečně automatizovat uživatelé K ZAPAMATOVÁNÍ Z uvedeného vyplývá, že v této etapě se bez podpůrných prostředků zajišťujících konverzi a uvedení dat do správných dat nebude možno obejít. To je jeden z důvodů proč je nutné tuto etapu naplánovat již v etapě Cílového konceptu. Hlavním rizikem špatně naplánovaného převodu dat je téměř jisté zpoždění náběhu projektu. V případě, že je náběh nového systému svázán se zahájením nového účetního roku, je nebezpeční zpoždění kritickým faktorem celého projektu. 3.5.3 AKCEPTAČNÍ TESTY Akceptační testy jsou důležitým krokem, jehož výsledkem je souhlas ke startu rutinního provozu. Cílem akceptačních testů je:  provedení kontroly správnosti funkce jednotlivých modulů;  provedení kontroly integrovaných funkcí všech modulů a návazností na stávající aplikace;  provedení závěrečné kontroly převedených dat. Výstupem z akceptačních testů jsou jednotlivé protokoly o testech a návrh na zahájení provozu nového systému nebo komponenty. Cíle ak- ceptačních testů Výstup ak- ceptačních testů FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 148 U zavádění větších systémů je naprosto nutné, aby byl proces akceptace dostatečně řízen a strukturován. Proto je již v etapě Cílového konceptu a přípravě realizace potřebné připravit formální metodiku provádění akceptačních testů. Akceptační testy provádějí zpravidla rozhodující klíčoví uživatelé a personál ICT. Probíhají podle velikosti projektu i v několika etapách a to zejména v etapě akceptace jednotlivých modulů a v etapě závěrečného integračního testu. Hlavním nebezpečím v etapě akceptace je fakt, že klíčoví uživatelé často jen těžko rozlišují mezi požadavkem na odstranění chyby a požadavkem na změnu jinak dobře fungující programové části. Pokud je hlášena chyba programu, je ji třeba odstranit pokud možno již v etapě akceptace jednotlivých modulů. Je-li hlášen požadavek na změnu, je nutno striktně postupovat podle formálně odsouhlasené metodiky zásad změnového řízení. Požadavky na změny nelze schválit po ukončení etapy akceptace modul u. V etapě integračního testu je možno povolit pouze odstranění závad v integraci jednotlivých části systému. V praxi tomu však často bývá jinak. Podle síly jednotlivých rozhodujících uživatelů, případně argumentační způsobilosti vedoucího projektu u dodavatele i odběratele, dochází i v etapě integrace k pokusům zavádět do systému změny. Někdy tyto požadavky na změnu mohou vyplývat z chyb vzniklých již v období konceptuální přípravy nebo jako důsledek špatně naplánované konverze prvotních dat. Výsledkem jsou tzv. sekundární chyby. Za sekundární chybu považujeme stav, kdy v důsledku odstranění chyby v modulu jednom dojde ke změně podmínek pro logickou správnost funkce v modulu jiném. Tento modul, který mohl být již dříve akceptován, se dostane do chybového stavu. Uvedený stav se může cyklicky opakovat. Dostane-li se projekt do této situace, jsou potíže při startu nebo odložení startu předem naprogramovány. Proto lze pro akceptaci projektu doporučit následující zásady:  akceptační testy jsou předem připraveny jako dílčí případové studie (scénáře) včetně udání zdrojů dat pro tyto testy;  je striktně zakázáno, aby dodavatel prováděl změny a opravy chyb, či vylepšení modulů o své újmě;  pro evidenci akceptačních testů je schválena procedura postupu a struktura akceptačních protokolů;  je předem připraven akceptační protokol, ve kterém se definuje za jakých podmínek je provedena akceptace úplná, akceptace s výhradami a zamítnutí akceptace. Současně je definován postup, pro případ, že nedojde ke shodě akceptace mezi dodavatelem a odběratelem;  je stanoven přesný postup, jak řešit rozpor mezi názorem odběratele, že se jedná o chybu a názorem dodavatele, že jde o nový požadavek. Tento postup je svázán s dříve definovaným zásadami změnového řízení;  akceptační protokoly, ať již dílčí nebo protokol z integračního testu, jsou podepsány oběma stranami. V případě, že se zákazník k akceptaci nevyjádří do určitého předem stanoveného období, je dílčí akceptační test považován za úspěšný; Realizace akceptačních testů Zásady ak- ceptace projektu Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 149  v případě, že dodavatel opakovaně neodstraní deklarované chyby nebo dochází k sekundárním chybám, mohou v závislosti od smlouvy o dodávce vstoupit v platnost procedury penalizace, v extrémním případě až odstoupení od smlouvy. K ZAPAMATOVÁNÍ Výsledkem závěrečného integračního testu je zpráva řídícímu výboru s doporučením k zahájení provozu systému nebo jeho části a protokol o správném provedení převodu dat. Na základě tohoto návrhu vydá řídící výbor nebo vedení firmy souhlas ke startu nového systému. 3.5.4 ŠKOLENÍ A DOKUMENTACE V rámci smluvené podpory zavedení nového systému jsou v dodávce stanoveny způsoby a rozsah školení. Stejně tak je možno dohodnout rozsah dokumentace dodávané dodavatelem, případně účast odběratele na pořízení této dokumentace. Na úrovni ÚSP, případně v období přípravy kontraktu, byla provedena volba rozsahu školení a to buď v objemu úplného zaškolení dodavatelem nebo metodou train the trainer.  v etapě školení se často projevují další požadavky na změny již prakticky hotového systému. Rozsah a závažnost těchto požadavků přímo souvisí s aktivní účastí klíčových uživatelů v etapě Cílového konceptu, při zkoušení prototypů a akceptaci modulů. Pokud byli klíčoví uživatelé aktivní a v průběhu akceptace požadované funkce systému odsouhlasili, neměl by být pro ně problém koncové uživatele zaškolit a vést je ke správné práci s novým systémem.  v praxi se osvědčuje školit koncové uživatele těsně před náběhem nového systému na konkrétních případech a využít jich i k částečné kontrole proběhlé konverze dat. Tato školení prováděná v rámci cílených soustředění koncových uživatelů na jednom místě, mohou značně zkrátit dobu, po kterou se projevují prvotní potíže po startu nového systému. Se školením uživatelů a celkovou přípravou na náběh nového systému úzce souvisí způsoby komunikace a interní marketing celého projektu. Aktivní komunikace ze strany vedení projektu a klíčových uživatelů směrem k uživatelům koncovým a k managementu je předpokladem pro vytvoření důvěry v nový systém. Zvláště se osvědčilo do této komunikace zahrnout tvůrce veřejného mínění ve firmě. Tvůrce veřejného mínění ve firmě nemusí být nutně členem managementu nebo některým z klíčových uživatelů. Může to být také všeobecně respektovaný koncový uživatel, pracující i na filiálce vzdálené od centra firmy. Pokud tento uživatel nebyl dobře zaškolen a tedy i pozitivně motivován, bude veřejné mínění v dané filiálce negativně ovlivněno. Způsoby školení Způsoby komuni- kace FÁZE PŘÍPRAVY, VÝVOJE A REALIZACE SYSTÉMU 150 Dodavatel v rámci v kontraktu obvykle dodává základní dokumentaci k typovým a standardním modulům, případně ke svým doplňkovým zákaznickým modulům. Tato dokumentace co do podrobnosti však většinou koncovým uživatelům nestačí. Často se také stává, že některé pracovní postupy jsou popsány jazykem odlišným od zaběhnutých zvyklostí ve firmě nebo od termínů používaných ve starém systému. Proto se osvědčuje dodavatelská dokumentace doplněná dokumentací firemní. Firemní dokumentace, má za úkol popsat základní pracovní postupy nově zavedených modulů. V průběhu času je doplňována řešeními konkrétních pracovních případů a výjimek a to nejlépe ve formě znalostní databáze, svázané s linkou hot-line. 3.5.5 VLASTNÍ NÁBĚH NOVÉHO SYSTÉMU Způsob náběhu nového systému se stanoví zpravidla již v ÚSP, nejpozději však při schvalování Cílového konceptu. Existují tři hlavní způsoby náběhu:  „Vše naráz" (BIG BANG) - tento způsob se používá u změn v oblasti technologie IS a dále u těch změn IS, kde existuje značná provázanost jednotlivých modulů. Náběh typu „vše naráz" může být velmi výhodný, skrývá však v sobě riziko fatálních chyb v systému. Lze jej tedy doporučit pouze u dobře připravených a provedených akceptačních testů. Pod pojmem „vše naráz" však nelze chápat určitý konkrétní časový moment. U velkých IS může například finální převod dat a jejich kontrola trvat i několik dní. Základní nevýhodou je fakt, že zde hrozí značné nebezpečí potíží v prvním období po startu nového systému. Další nevýhodou bývá nutnost vázat se na některé základní termíny související s účetnictvím jako je roční závěrka, požadavky mateřské organizace u koncernových organizací apod.  Paralelní chod starého a nového systému - tento způsob je bezpečnější a riziko fatálních chyb zde není. Vyžaduje však značné zdroje na straně zákazníka.  Třetím způsobem je zavádění po jednotlivých modulech - při tomto způsobu musí být dobře propracovaná strategie nové datové základny a jejích vazeb na datovou základnu starou. Hlavní výhodou tohoto postupu je možnost postupného přechodu k novému systému. Jako první se zavádí jedna z méně složitých komponent, u které je vysoký předpoklad úspěšnosti. Úspěšné zavedení komponenty tak posílí důvěru uživatelů i managementu v nový systém. Určitou nevýhodou zavádění po komponentách je nebezpečí, že nebudou dodrženy důležité systémové vazby. Rozhodnutí o termínu a způsobu náběhu přijímá vlastník projektu (Řídící výbor) na doporučení vedoucího projektu. U náběhu typu „vše naráz" je však definitivní rozhodnutí o startu provozu nového IS možné až těsně před plánovaným náběhem a to na základě výsledků akceptačních testů. V tomto případě vedoucí projektu určí moment, od kterého probíhající již náběh není možné zastavit (point of no return). Současně s rozhodnutím o způsobu náběhu přijímá vlastník projektu také rozhodnutí, ve kterém časovém okamžiku náběh začne. Zde se skrývá určité úskalí. Závažné změny IS se většinou provádějí na konci určitého období. Může to být začátek nového kvartálu nebo Dokumen- tace Způsoby náběhu projektu Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 151 nového kalendářního či finančního roku. Tím vzniká určitý fixní termín, který je třeba dodržet. Mění-I i se s IS také celý systém účetnictví, je náběh na začátku nového finančního roku velkou zátěží pro uživatele v oddělení účetnictví v důsledku probíhající roční závěrky. Mění-I i se však tento systém na začátku některého měsíce, trpí tím kvalita statistických údajů v systému, které se navíc musí dodatečně do systému dostat, aby účetní data byla pro daný finanční rok kompletní Pokud dojde ke zpoždění v projektu a při tom je zadaný termín náběhu nutno dodržet, dochází ke značným rizikům. Uživatelé totiž nemohli být dostatečně proškoleni, není dostatečně odzkoušena část nově zaváděných funkcí, nemusí být úplně připravena data atd. V tomto případě lze doporučit posun termínu. Vznikne tím podstatně menší riziko neúspěchu projektu, než v případě kritických chyb systému způsobených výše uvedenými nedo- statky. OTÁZKY Po prostudování kapitoly byste měli být schopni vysvětlit následující: 1. Definujte smysl, obsah a typickou strukturu Studie proveditelnosti. (viz 3.1) 2. Co obsahuje Časový plán projektu IS a v jakých formách se zpracovává? (viz 3.1.12) 3. Co jsou to převody dat v rámci realizace projektu IS, kdo je připravuje, provádí a jaká mají rizika? (viz 3.5.2) 4. Co je to Podrobný rozpis prací, na jaké etapě se zpracovává a k čemu slouží? (viz 3.4.3) 5. Jaké jsou etapy realizace projektu IS? (viz 3.5) 6. Popište základní metodologie návrhu IS. (viz str. 78) 7. Co má obsahovat Smlouva o dodávce IS? (viz 3.3.1) 8. Co obsahuje Cílový koncept (Projekt) řešení IS? (viz 3.4.2) SHRNUTÍ KAPITOLY Fáze přípravy a realizace projektu představuje vlastní fyzickou realizaci, po jejímž ukončení se dá předpokládat plnohodnotné využívání IS ve prospěch plánovaných cílů. Projekty IS mají komplexní charakter, a proto je nutné, aby jednotlivé fáze byly plněny plně v souladu obsahového, časového, a finančního plánu. Případné odchylky mohou způsobit na jedné straně problémy nejen během samotné realizace projektu, ale co je podstatnější, mohou způsobit rozdílnosti ve funkčnosti výstupu projektu IS, tedy implementovaného IS. KONTROLA A HODNOCENÍ PRŮBĚHU PROJEKTU 152 4 KONTROLA A HODNOCENÍ PRŮBĚHU PROJEKTU RYCHLÝ NÁHLED KAPITOLY Kontrola průběhu projektu a následná nápravná opatření v případě odchylek jsou hlavními metodami, jak dosáhnout projektového cíle. Platí to pro projekty obecně tedy i pro projekty IS. Cílem této kapitoly je představit základní přístupy, metody a nástroje pro to, abychom bylischopnivyhodnotitvýsledekprojektuz hlediskajehofunkčnosti,užitečnostiaekonomické efektivity. CÍLE KAPITOLY Po prostudování této kapitoly budete umět:  koncipovat kontrolní systém projektu;  definovat strategii kontroly;  využívat nástroje kontroly průběhu projektu;  realizovat uživatelské a systémové hodnocení projektu;  vyhodnotit ekonomickou efektivnost projektu;  provést následnou analýzu;  identifikovat a vyhodnotit typické stížnosti uživatelů po zavedení systému;  identifikovat a vyhodnotit typické připomínky vedení firmy po zavedení systému;  identifikovat a vyhodnotit typické odpovědi dodavatelů po zavedení systému;  mo6nosti využití Hotline. KLÍČOVÁ SLOVA KAPITOLY Kontrolní systém, strategie kontroly, nástroje kontroly, uživatelské a systémové hodnocení projektu, ekonomická efektivnost, následná analýza, stížnosti koncových uživatelů, připomínky vedení firmy, typické odpovědi dodavatelů, hotline. Kontrolní systém by měl být koncipován tak, aby zajišťoval:  Zpětnou vazbu o kvalitě plánu projektu. U projektů IS jde zejména o časový plán a plán zdrojů na straně dodavatele i odběratele.  Včasnou identifikaci odchylek od plánu. Koncepce kontrolního sys- tému Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 153  Podklady pro rozhodování o přijatých korekčních opatřeních. Kontrola průběhu projektu je úkolem vedoucího projektu, který výsledky kontroly a navrhovaná opatření komunikuje vlastníkovi projektu a Řídícímu výboru. Kontrola projektu probíhá z různých pohledů:  Z pohledu obsahu (předmětu) projektových prací - sem patří hlavně vyhodnocení průběžného plnění smlouvy o dodávce a řešených funkcí IS.  Z pohledu časových plánů - hodnotí se stav prací na projektu z hlediska harmonogramu projektu ve smlouvě o dodávce a jeho aktualizací. Hledisko časových plánů je zejména u velkých projektů IS jedním z rozhodujících. Časový plán a jeho dodržení je často předmětem korekčních opatření a zdrojem konfliktů s dodavatelem.  Z pohledu nákladů na projekt - kontrola nákladů na projekt je obvykle jednou z úloh vedoucího projektu, která vedoucího projektu nejvíce zatěžuje. Vyplývá z povahy projektu IS, který se často řeší metodou postupného řešení jednotlivých modulů s iteracemi a z již zmíněné tendence dodavatelů účtovat vícepráce. V nákladech na projekt se také silně projevují různá změnová řízení, kterým se při realizaci projekt nelze vyhnout. 4.1.1 STRATEGIE KONTROLY Podle toho, jakou strategii určil podnik pro průběh projektu, realizuje se i kontrolní strategie. Dolanský a kol. [DOL 1996] definují následující kontrolní strategie:  Vyváženou - míra důrazu je zde rovnoměrně rozložena mezi kontrolu nákladů (zdrojů), kontrolu termínů a kontrolu kvality.  Se zaměřením na čas - zde je důraz kladen na plnění termínů. Požadavek na splnění plánovaných termínů zatlačuje do pozadí projektové náklady a kvalitu provedení. U projektů IS tato strategie nastupuje ve chvíli, kdy se projekt ocitá v termínových potížích.  Se zaměřením na náklady - prvořadá je zde kontrola čerpání zdrojů, kvalita a termíny ustupují do pozadí. Tato strategie se u projektů IS projevuje obvykle ve fázi přípravy Cílového konceptu řešení, později však často ustoupí kontrole zaměřené na čas.  Se zaměřením na kvalitu - zde je prvořadá kvalita provedení. V případě IS je tato strategie zmiňována na začátku projektu, ale v jeho průběhu téměř vždy ustoupí do pozadí. Kontrola průběhu projektu Kontrolní strategie KONTROLA A HODNOCENÍ PRŮBĚHU PROJEKTU 154 4.1.2 NÁSTROJE KONTROLY PRŮBĚHU PROJEKTU K nástrojům kontroly průběhu projektu patří především:  Interní podniková metodika a standardy - v zásadě tyto standardy platí pro všechny projekty, projekt IS není zde výjimkou.  Jednání o stavu projektu - toto jednání probíhá v rámci jednání projektového týmu. Výstupem jsou zápisy o stavu projektu, případně protokoly o přijatých opatřeních směrem k dodavateli nebo korekční změny v plánech, případně návrhy pro opatření ze strany Řídícího výboru projektu.  Interní reporting - jeho režim je dán výše uvedenými podnikovými standardy  Jednání Řídícího výboru projektu - výstupy jsou rozhodnutí o přijetí závažných korekčních opatřeních.  Při použití externích odborníků pro zajištění kvality projektu jsou to také zprávy externích odborníků s návrhy opatření pro Řídící výbor projektu. K ZAPAMATOVÁNÍ Důležitou vlastností výše uvedených zpráv a opatření je jejich bezpodmínečná archivace. Možným nástrojem pro zajištění kvality budoucích projektů je následná analýza, o které se krátce zmíníme níže. 4.2 Hodnocení projektů Po ukončení projektu probíhá určitá forma následného hodnocení celého projektu. Zde nejčastěji dochází k hodnocení funkcí nového systému z pohledu uživatelů. Skutečnému ekonomickému vyhodnocení a srovnání s údaji uvedenými v ÚSP se však obvykle věnuje menší pozornost. Ještě méně diskuze vzniká kolem zhodnocení průběhu projektu a skutečné podpory obchodních procesů novým IS. 4.2.1 UŽIVATELSKÉ A SYSTÉMOVÉ HODNOCENÍ PROJEKTU Uživatelské hodnocení projektu znamená určitou zpětnou vazbu uživatelů směrem k projektovému týmu. Kromě běžných uživatelských hodnocení probíhá často také hodnocení systémové. Vlček (1994) definoval celou řadu hledisek uživatelského a systémového hodnocení informačního systému. Shrnutí těchto hledisek uvádíme v Tabulka 16. Nástroje kontroly projektu Hodnocení projektu Uživatelské hod- nocení projektu Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 155 Tabulka 16 Hlediska hodnocení IS Hledisko Ukazatel Význam ukazatele Integrita Integrita s okolím pravdivý obraz reálného světa Integrita úloh IT datové výstupy z předcházející funkce mohou být použity ve funkci následující Redundance Zjištěné duplicitní vazby nadbytečnost informací Propustnost Měřené veličiny množství a času možná kapacitní omezení Účinnost Poměr mezi počtem funkcí vyšší úrovně složitosti k celkovému počtu funkcí i jakoby plně zaměstnaný proces nemusí být v rámci IS účinný Pohotovost Spotřeba času k dodání informace na místo jejího použití analytický a srovnávací ukazatel funkč- nosti Organizova- nost Úroveň podpory procesů měřítko nut- nosti odhalování konfliktů, synchronizací v systému Efektivnost Ukazatelé ekonomické efektivnosti hodnocení investic Tyto všeobecné systémové pohledy je v praxi nutno ještě doplnit hodnocením bezpečnosti realizovaných IS. Jejich stručnou charakteristiku uvádí Tabulka 17. Tabulka 17 Obecná charakteristika ukazatelů pro hodnocení bezpečnosti IS Hledisko Ukazatel Praktický význam Bezpečnost Ochrana před zneužitím ochrana citlivých dat a funkcí Ochrana před útokem zvenku ochrana před hackery, viry a dalšími útoky, spamy atd. Integrita oprávnění oprávnění platí pro systém jako ce- lek Modularita oprávnění oprávnění je možno parametrizovat a přizpůsobovat Soulad s firemními bezpečnostními pravidly platí zejména pro koncerny Soulad síťových a aplikačních bezpečnostních prvků docílení integrity v bez- pečnosti Robustnost Definované politiky restartů umožňuje řídit náběhy po poru- chách Úroveň zálohování docílení bezpečnosti a znovupoužitelnosti hlavních dat Připravenost k náběhu po fatální po- ruše možnost náhradního provozu a náběhu po katastrofách Kontrolní algoritmy proti uživatelským chybám prevence zbytečných chyb, podklady pro školení Hodnocení bezpeč- nosti KONTROLA A HODNOCENÍ PRŮBĚHU PROJEKTU 156 4.2.2 EKONOMICKÁ EFEKTIVNOST (HLEDISKA) Hodnocení ekonomické efektivnosti probíhá po určité době po zahájení projektu. Jak jsme se již zmínili, pozornost věnovaná následnému hodnocení ekonomické efektivnost po náběhu projektu je většinou nižší, než v průběhu jednotlivých etap projektu. Používají se zpravidla ukazatele rentability investic (ROI) s využitím účetních údajů a údaje TCO s použitím údajů o provozních nákladech na provoz IS. Různé metody ekonomického hodnocení včetně metody reálných opcí jsme analyzovali například ve Vymětal (2009b), proto jim v této práci nevěnujeme pozornost. 4.2.3 NÁSLEDNÁ ANALÝZA K ZAPAMATOVÁNÍ Aby bylo možno dosáhnout lepších výsledků u budoucích projektů, je nutné se z minulých projektů poučit. Platí to jak pro zákazníka - uživatele nového IS tak pro dodavatele. Na následnou analýzu lze pohlížet ze dvou hledisek podle toho, jaké cíle sledujeme:  Hlavním účelem je získání zkušeností pro lepší průběh příštího projektu IS. Tuto analýzu by měl provádět dodavatel. Radí se do kategorie „post mortem"  Hlavním účelem je posoudit úspěch zavedení (implementace) nového IS. Zde se více používá termín „evaluace po zavedení". Je prováděna na základě uživatelských kritérií uvedených výše. Pro analýzu prvního typu bývá použit termín „revize projektu - project review", post mortem", evaluace nebo audit projektu. Někteří používají tento termín pouze pro neúspěšné projekty. V každém případě je však cílem následné analýzy určit, zda řízení projektu vedlo k dosažení cílů. Podrobnou analýzu v této oblasti zpracoval McAvoy (2006). Při zhodnocení uživatelských funkcí nového IS je vhodné provést srovnání s definicí procesů stanovených jako zadání pro projekt. Definice procesů proběhla nejpozději v etapě Cílového konceptu. Srovnání procesního modelu na vstupu do projektu s procesy skutečně podporovanými novým IS by mělo být hlavním úkolem zmíněné „evaluace po zavedení". Výsledkem je nejen vlastní srovnání procesního modelu a průchodnosti systému se skutečností, ale také výstupy do formálních organizačních dokumentů podniku. Provádění následné analýzy nebývá vždy úspěšné. Pracovníci - členové týmu jsou na konci dlouhého cyklu zavádění IS frustrovaní, vyčerpaní a v důsledku potíží při náběhu systému, které zákonitě nastávají, i cyničtí. Je to jedním z důvodů, proč práci na následné analýze nemohou provést dobře. Avšak pokud by provedení následné analýzy bylo svěřeno externistům, došlo by zcela jistě ke komunikačním problémům. Externisté nemohou znát Hodnocení ekono- mické efektiv- nosti Hlediska následné analýzy Revize projektu Úspěšnost následné analýzy Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 157 detaily a podmínky, při kterých se prováděla rozhodnutí v průběhu projektu, a proto by jim geneze změn dílčích cílů, ke kterým v průběhu projektu zákonitě dochází, zcela unikala. To by nutně zkreslovalo vlastní analýzu. Tématika následných analýz je poměrně rozsáhlá. Přehledně ji popsali Myllyaho a kol. (2008). Podle jejich zkušeností je účinná u menších programátorských kolektivů pracujících s napjatými termínovými plány. Má-li se však post mortem analýza provádět systematicky, je zapotřebí provádět ještě další výzkumy ke zvýšení její účinnosti. 4.3 Konflikty po zavedení systému Zavedení systému je formálně potvrzeno podepsáním předávacích protokolů. Zdaleka to však neznamená, že je systém zcela hotov. Obvykle zbývají různé nedodělky, které nebrání provozu systému, případně definované změny, které vznikly v období integrace, školení uživatelů a závěrečného testu. Právě tato situace, kdy projekt nelze převzít jako zcela hotový výrobek, v sobě skrývá nebezpečí dalších konfliktů. 4.3.1 KONCOVÍ UŽIVATELÉ Koncoví uživatelé si většinou stěžují na to, že nebyli dostatečně zaškoleni. Příčina může být v tom, že nebyl přijat adekvátní způsob zaškolení. Při metodě train the trainer, hrozí nebezpečí, že trenéři některým zvláštním situacím chování systému nebo výjimkám v normálním průběhu procesu plně neporozuměli nebo je nedokázali komunikovat. U přímého zaškolení uživatelů dodavatelem mohla být školení z časového hlediska nedostatečně organizována (například málo přestávek, dlouhé úseky školení vedoucí ke ztrátám pozornosti atd.) nebo na probrání výjimečných situací nebylo pamatováno s dostatečnou časovou rezervou. Dalším častým důvodem je, že dokumentace školení vykazuje chyby a nedostatky. Koncoví uživatelé si také často stěžují na výkonnost systému. Zde se může jednat o málo výkonné hardware, chyby v práci aplikačních programů s datovou základnou (hledání dat), ale také o špatné rozvržení obrazovek, které nutí uživatele k nezvyklému pohybu mezi jednotlivými poli. Náprava tohoto nedostatku bývá zpravidla tématem pro jednání managementu, protože znamená změnu oproti převzatému systému, tedy vícepráce u dodavatele, následnou blokaci interních zdrojů při testování a ve svém důsledku zvýšení nákladů. Zavedení nového systému znamená pro uživatele vždy změnu systému práce. I při sebelepším marketingu projektu se najde část uživatelů, která je touto změnou frustrována. Hlásí tedy celou řadu skutečných či jiných nedostatků. Je úkolem vedoucího projektu nebo příslušného odborníka z oddělení ICT určit, zda se jedná o skutečný problém nebo o problém zástupný. Stížnosti koncových uživatelů KONTROLA A HODNOCENÍ PRŮBĚHU PROJEKTU 158 4.3.2 VEDENÍ FIRMY Pomineme-li případné problémy při dodržení termínu či plánovaných nákladů na projekt, soustřeďují se připomínky vedení firmy zpravidla na následující oblasti:  Ve srovnání se stavem před zavedením chybí některé starší sestavy, obecně informace ve složení, na které bylo vedení zvyklé. Pro členy vedení to může znamenat, že řídí firmu způsobem „let naslepo. To je důvodem vytváření značného tlaku na projektový tým.  Dodatečné požadavky uživatelů, které se objevují po zavedení systému, sice vedení podporuje, žádá však, aby byly dodavatelem řešeny v rámci záruky zdarma nebo jako pozornost dodavatele.  Střední a nižší management, zejména pokud se aktivně projektu neúčastnil, často uvádí zavedení nového systému jako příčinu přechodně sníženého obratu, přechodně zvýšených nákladů, vícepráce v jimi řízených organizačních útvarech atd. Zde nezbývá než využít podpory vedení firmy a snažit se neztratit v důsledku nevyvolaných chyb důvěru jednotlivých vedoucích.  „Nespiněné sliby". Tento problém souvisí zejména s nesprávným stanovením rozsahu projektu, v případě jeho špatným marketingem v jeho průběhu. Stále ještě se mohou objevovat „marketingová" prohlášení v průběhu projektu, že všechna řešení proběhnou na stisknutí jednoho tlačítka. Výsledkem mohou být fatální důsledky při akceptování systému uživateli po jeho náběhu. 4.3.3 DODAVATEL Dodavatel má pochopitelně zájem projekt předat, vyinkasovat zbývající finanční prostředky a případně uvolnit zdroje, které pro projekt alokoval. Při jednáních se zákazníkem se nejčastěji objevují následující odpovědi na stížnosti ze strany zákazníka:  „To nebylo ve smlouvě". Nezbývá než konkrétně analyzovat Cílový koncept nebo schválený obsah projektu a prací.  „Toto nepatří do záruky". Jedná se buď o špatně nebo nejasně naformulovanou smlouvu v obsahu záručních podmínek nebo pokus dodavatele o získání dodatečných finančních prostředků. Při skutečně dobrém partnerském vztahu v průběhu projektu, lze tento konflikt řešit vzájemnou dohodou.  „Uživatelé si nepamatují, co jsme je školili". Souvisí zpravidla s nedostatečně zpracovanou koncepcí školení a obvykle vede k nákladům buď u dodavatele, nebo interním nákladům v důsledku doškolování.  „Máme Hotline, nevolejte našim programátorům". Dodavatel má v zásadě pravdu. Nekoordinovaný a nedokumentovaný přístup k řešení problémů vyvolává další následné problémy. K úloze Hotline se krátce vrátíme v následující části. Připomínky vedení firmy Typické odpovědi dodavatelů Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 159  „Dodali jsme víc, než jste zaplatili". Tvrzení opět souvisí s kvalitní definicí projektu a s úrovní projektového řízení. Objevuje se tehdy, když vzájemná důvěra obou partnerů není na nejlepší úrovni.  „Naši subdodavatelé jsou neschopní". To může souviset buď tím, že si dodavatel vybral špatného subdodavatele, nebo došlo k posunu termínu projektu a subdodavatel nemá vol né kritické zdroje. Pokud byl obsah projektu, jeho změny případně změny termínového plánu odsouhlaseny oběma stranami, má sice dodavatel pravdu, avšak existuje zdroj značných konfliktů. Odběratel v tomto případě většinou osloví subdodavatele po své linii sám a tím naruší jak podmínky smlouvy, tak partnerské klima mezi oběma stranami. 4.4 Důležitost a úloha Hotline po zavedení projektu Pro podporu uživatelů k odstranění potíží po náběhu nového systému v poslední době velmi vzrostla úloha Hotline. Hotline může být zavedena přímo u odběratele a provozována oddělením ICT nebo může být zavedena u dodavatele a uživatelé nebo pověření pracovníci s touto Hotline pracují přímo. Může být používaná i kombinace obou metod. Na trhu je již celá řada programových produktů pro definici a provozování Hotline. Z našeho pohledu projektování IS má Hotline následující úlohy:  Nahlášení problémů a chyb. Uživatel registrovaných Hotline má možnost, dnes zpravidla přes webovské rozhraní, strukturovaně hlásit vzniklé potíže. Kromě krátkého popisu má možnost zasláním snímků nebo jiných příloh tyto potíže dokumentovat. Každému problému přidělí systém tzv. ticket. Registruje datum a čas vzniku ticketu.  Dispečer Hotline analyzuje tickety a přiděluje jejich řešení odpovídajícím osobám. Současně systém uvědomuje uživatele o tom, že ticket byl převzat a předán do plánovací fáze se současnou registrací data a času.  Zodpovědný řešitel řeší problém, uvědomuje o řešení dispečera. Systém automaticky registruje datum a čas vyřešení s tím, že také uživatel dostává informaci buď přímo nebo od dispečera Hotline. Realizací těchto základních funkcí vzniká možnost:  Strukturovaného popisu problému. Při pouhém telefonickém nahlášení ať na Hotline nebo přímo řešiteli (programátorovi) dochází k nestrukturované výměně informací, blokaci času řešitele a rovněž nejsou k dispozici základní data pro statistiku.  Je možno sledovat statistiku podle jednotlivých uživatelů. Při opakujících se problémech u jednotlivého uživatele je možnost nabídnout mu školení. Při analýzách ticketů lze najít slabá místa v programu nebo v jeho užívání.  Statistiku je možno použít pro účely záruky a jednání s dodavatelem.  V případě konfliktů na úrovni dodavatelů nebo managementu, které jsme zmínili výše, jsou k dispozici údaje pro statistiku vyhodnocující rychlost reakce dodavatele, rychlost reakce dispečera, statistiku slabých míst s návrhem případných změn a další účely. Hotline Úlohy Ho- tline KONTROLA A HODNOCENÍ PRŮBĚHU PROJEKTU 160 OTÁZKY 1. Popište základní ukazatele hodnocení efektivnosti a ukazatele uživatelského hodnocení projektů IS. (viz 4.2.1) 2. Uveďte postup vyhodnocování ekonomické efektivnosti projektu. (viz 4.2.2) 3. Charakterizujte nástroje kontroly průběhu projektu. (viz 4.1.2) 4. Uveďte typické stížnosti a připomínky uživatelů, vedení firmy a dodavatelů po zavedení systému. (viz 4.3) 5. Vysvětlete funkčnost Hotline a uveďte možnosti využití tohoto nástroje ve všech fázích přípravy a realizace projektu. (viz 4.4) SHRNUTÍ KAPITOLY Cílem projektování IS je dosáhnout stavu, kdy je IS implementován, uveden do plného provozu a podporuje všechny činnosti dle původního záměru s očekávanou efektivitou. Zda tomu tak skutečně je, to musí být posouzeno a zkontrolováno. Rychlá, ovšem důsledná analýza a kontrola v co možná nejkratším časovém intervalu po uvedení IS do ostrého provozu je předpokladem zajištění dostatečných nápravných opatření v případě zjištěných od- chylek. Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 161 LITERATURA APFEL, A., 2002. The Total Value of Opportunity Approach. Gartner: DF-17-0235 [online]. [cit. 2017-09-29]. Dostupné z: https://www.gartner.com/doc/365660/total-value-op- portunity-approach ARIS - Enterprise Methodologies. ARIS – (Architecture of Integrated Information Systems) [online]. [cit. 2017-09-29]. Dostupné z: http://www.pera.net/Methodolo- gies/ARIS/ARIS.html ARVESON, P., 2003. A Balanced Scorecard For City & County Services [online]. In: Balanced Scorecard Institute, s. 27 [cit. 2017-09-29]. Dostupné z: http://www.balancedscore- card.org/portals/0/pdf/bsc_for_city-county03.pdf BARJIS, J., 2007. Automatic business process analysis and simulation based on DEMO. Enterprise Information Systems 1(4), 365-381. BECK, K., 1999. Extreme programming: Embrace the chase. Addison-Wesley Professional. ISBN 0-201-64-641-6. BELLIFEMINE, F., CAIRE, G., POGGI, A. a G. RIMASSA, 2003. JADE A White Paper [online]. [cit. 2017-09-29]. Dostupné z: http://jade.tilab.com/papers/2003/WhitePa- perJADEEXP.pdf BEČVÁŘ, P., KOUT, J. a M. PĚCHOUČEK, 2004. Multiagentní řízení, simulace a plánování. AUTOMA (5). ISSN 1210-9592. BOOCH, G., 1994. Object-oriented analysis and design with applications. 2nd ed. Redwood City, Calif.: Benjamin/Cummings Pub. Co. ISBN 978-0-8053-5340-2. BUCKI, R. a F. MARECKI, 2005. Modelling and simulation. Parkland Florida: Network Integrators Associates. ISBN 83-891-0594-2. BUCKI, R. a P. WASILEWSKI, 2004. Efektywność zastosowania algorytmów heurystycznych do sterowania linią produkcyjną, In: „Strategie informatyzacji i zarządzanie wiedzą. Strategie informatyzacji i zarządzanie wiedzą. Warszawa: Wydawnictwo Naukowo Techniczne, s. 441-450. ISBN 9788320430141. Business Process Management Initiative (BPMI), 2003. Business Process Modeling Notation Working Draft (1.0) August 25, 2003 [online]. [cit. 2017-09-29]. Dostupné z: http://xml.coverpages.org/BPMNv10Draft.pdf Cígler Software. Target S3 [online], 2003. [cit. 2017-09-29]. Dostupné z: http://www.money.cz/money-s3/vlastnosti-systemu/target-s3/ CHANDRASEKARAN, B., JOSEPHSON, J.R. a V.R. BENJAMINS, 1990. What are ontologies and why do we need them? IEEE Intelligent Systems 14(1). ISSN 1541-1672. CHANG, C. J. a L.R. INGRAHAM, 2007. Modeling and designing accounting systems: using Access to build a database. Hoboken, N.J.: John Wiley. ISBN 04-714-5087-1. Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 162 Data Research, 2015. Boston Matrix [online]. [cit. 2017-09-29]. Dostupné z: http://www.dpu.se/boston_e.html DAVENPORT, T.H., 1993. Process innovation: reengineering work through information technology. Boston, Mass.: Harvard Business School Press. ISBN 08-758-4366-2. DAVENPORT, T.H., 1996. Some Principles of Knowledge Management [online]. [cit. 2017-09-29]. Dostupné z: https://www.strategy-business.com/article/8776?gko=f91a7 DLOUHÝ, M., 2007. Simulace podnikových procesů. Brno: Computer Press. ISBN 978- 80-251-1649-4. DIETZ, J. L.G., 2007. Understanding and Modeling Business Processes with [online]. [cit. 2017-09-29]. Dostupné z: http://citeseerx.ist.psu.edu/viewdoc/down- load?doi=10.1.1.203.2489&rep=rep1&type=pdf DOLANSKÝ, V., MĚKOTA, V. a V. NĚMEC, 1996 Projektový management. Praha: Grada. ISBN 80-716-9287-5. DOUCEK, P. a O. NOVOTNÝ, 2007. Standardy řízení podnikové informatiky. E&M Economics and Management. (3). ISSN 1212-3609. DUNN, C.L., CHERRINGTON, J.O. a A.S. HOLLANDER, 2005. Enterprise information systems: a pattern-based approach. 3rd ed. Boston: McGraw-Hill/Irwin. ISBN 00-724- 0429-9. ebXML DELIVERABLES, 2017. ebXML Specs [online]. [cit. 2017-09-29]. Dostupné z: http://www.ebxml.org/specs/ FOTR, J., 1999. Podnikatelský plán a investiční rozhodování. 2. přeprac. a dopl. vyd. Praha: Grada. ISBN 80-716-9812-1. FÜRSTBERGER, G., 2003. Projektmanagement, Seminarunterlagen. Wien: Management Development GmbH. GAREIS, R., 2005. Happy Projects! project and programme management, project portfolio management, management of the project-oriented organization, management in the project-oriented society ; (new theories, models, best practices, case studies]. 2nd edition. Vienna: Manz. ISBN 32-140-8268-X. GAŠEVIĆ, D., DURIĆ, D. a V. DEVEDZIC, 2006. Model driven architecture and ontolgy development. Berlin: Springer-Verlag. ISBN 978-3-540-32180-4. GEERTS, G.L. a E.W. McCARTHY, 2015. An ontological analysis of the economic primitives for the extended-REA enterprise information architecture [online]. [cit. 2017- 09-29]. Dostupné z: http://www.msu.edu/user/mccarth4/sowa.doc GEERTS, G.L. a E.W. McCARTHY, 2006. Policy Level Specifications in REA Enterprise Information Systems. Journal of Information Systems 20(2), 37-63. ISSN 1212-3609. GEERTS, G.L. a E.W. McCARTHY, 2000. The Ontological Foundation of REA Enterprise Information Systems [online]. [cit. 2017-09-29]. Dostupné z: http://www.msu.edu/user/mccarth4/Alabama.doc Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 163 GRUBER, T., 2009. Ontology [online]. [cit. 2017-09-29]. Dostupné z: http://tomgru- ber.org/writing/ontology-definition-2007.htm GRUBER, T., 2017. What is Ontology? [online]. [cit. 2017-09-29]. Dostupné z: http://www-ksl.stanford.edu/kst/what-is-an-ontology.html HAMMER, M. a J. CHAMPY, 2000. Reengineering - radikální proměna firmy: manifest revoluce v podnikání. 3. vyd. Praha: Management Press. ISBN 80-726-1028-7. HOPFSTRAND, D. a M. HOLZ-CLAUSE, 2006. What is a Feasibility study? [online]. [cit. 2017-09-29]. Dostupné z: https://www.extension.iastate.edu/agdm/whole- farm/html/c5-65.html HRUBÝ, P., 2006. Model-driven design using business patterns. New York: Springer-Verlag. ISBN 978-3-540-30154-7. HRUBÝ, P., HUČKA, M., HUŇKA, F., KAŠÍK, J. a D. VYMĚTAL, 2008. Modelování podnikových procesů na bázi hodnotových řetězců (Systém REA): Charakteristika a příklady aplikace (některé příklady aplikace). Ostrava: VŠB-TU Ostrava, Ekonomická fakulta a Ostravská univerzita, Přírodovědecká fakulta. ISBN 978-80- 48-1872-6. Integrated DEFinition Methods (IDEF), 2017. Overview [online]. [cit. 2017-09-29]. Dostupné z: http://www.idef.com/idefo-function_modeling_method/ IFT, 2007. This RFP Master [online]. [cit. 2017-09-29]. Dostupné z: http://www.infoti- vity.com/rfp_template_db-gen.html#css ISO 14258 - Concepts and rules for enterprise models. ISO 15704 – Requirements for enterprise-reference architectures and methodologies. ITILv3 [online], 2017 [cit. 2017-09-29]. Dostupné z: https://en.wikipe- dia.org/wiki/ITIL#Overview_of_the_ITIL_v3_library KADLEC, V., 2004. Agilní programování: metodiky efektivního vývoje softwaru. Brno: Computer Press. ISBN 80-251-0342-0. KAPLAN, R.S. a D.P. NORTON, 2007. Balanced Scorecard: strategický systém měření výkonnosti podniku. 5. vyd. Praha: Management Press. ISBN 978-80-7261-177-5. KEŘKOVSKÝ, M. a M. DRDLA, 2003. Strategické řízení firemních informací: teorie pro praxi. Praha: C.H. Beck. C.H. Beck pro praxi. ISBN 80-717-9730-8. KICZALES, G., LAMPING, J., MENDHEKAR, A., MAEDA, C., LOPES, C.V., LOINGTIER, J.M. a J. IRWIN, 1997. Aspect-Oriented Programming. In: Proceedings of the European Conference on Object-Oriented Programming (ECOOP): Lecture Notes in Computer Science book series (LNCS). 1241. Heidelberg: Springer-Verlag, s. 220-242. KLAILOVÁ, Š., 2015. Lidské zdroje v informační společnosti [online]. [cit. 2017-09-29]. Dostupné z: http://www.isss.cz/archiv/2007/program.asp KUBÍK, A., 2004. Inteligentní agenty. Brno: Computer Press. ISBN 80-251-0323-4. Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 164 KUBÍK S., KOTEK, Z., STREJC, V. a J. ŠTECHA, 1982. Teorie automatického řízení I. Praha: SNTL, 528 s. McAVOY, J., 2006. Evaluating the Evaluations: Preconceptions of Post Mortems [online]. [cit. 2017-09-29]. Dostupné z: http://www.ejise.com/issue/download.html?idArticle=765 MILDEOVÁ, S. a V. VOJTKO, 2006. Manažerské simulace dynamických procesů. Praha: Oeconomica. ISBN 80-245-1055-3. MOOS, P. a V. VOJTKO, 1993. Informační technologie. Praha: České vysoké učení technické. ISBN 80-010-1048-1. MYLLYAHOL, M., et al., 2015. A Review of Small and Large Post Mortem Analysis Methods [online]. [cit. 2017-09-29]. Dostupné z: http://virtual.vtt.fi/virtual/proj1/pro- jects/merlin/pub/pma_full_1.00-icssea-layout.pdf OSSHER, H. a W. HARRISON, 1993. Subject-oriented programming: a critique of pure objects. ACM SIGPLAN Notices, 28(10), 411 - 428. ISSN 0362-1340. PÍCKA, M., 2007. Aspektové programování v jazyku python [online]. [cit. 2017-09-29]. Dostupné z: http://prog-story.technicalmuseum.cz/images/dokumenty/Programovani- TSW-1975-2014/2007/2007-20.pdf QPR, 2008. Business Process Management - Prepare for process excellence [online]. [cit. 2017-09-29]. Dostupné z: https://www.qpr.com/solutions/business-process-management RUMBAUGH, J., JACOBSON, I. a G. BOOCH, 2005. The unified modeling language reference manual: procesní řízení a modelování. 2nd ed. Boston: Addison-Wesley. Management v informační společnosti. ISBN 03-212-4562-8. RUMBAUGH, J., BLAHA, M., PREMERLANI, W., EDDY F. a W. LORENSEN, 1991. Object-oriented modeling and design. 2nd ed. Englewood Cliffs, N.J.: Prentice Hall. ISBN 01-362-9841-9. ŘEPA, V. a V. VOJTKO, 2006. Podnikové procesy: procesní řízení a modelování. Praha: Grada. Management v informační společnosti. ISBN 80-247-1281-4. SCHOLLEOVÁ, H., 2007. Hodnota flexibility: reálné opce. V Praze: C.H. Beck. C.H. Beck pro praxi. ISBN 978-80-7179-735-7. SCHOLLEOVÁ, H., 2005. Reálné opce: reálné opce. Praha: Oeconomica. C.H. Beck pro praxi. ISBN 80-245-0868-0. SILVIUS, A.J., 2007. Does ROI matter? Insights into the true business value of ICT [online]. [cit. 2017-09-29]. Dostupné z: https://www.vanharen.net/Player/eKnow- ledge/does_roi_matter_insights_in_the_true_business_value_of_it.pdf SITELAB. RFP Templates [online]. 2007 [cit. 2017-09-29]. Dostupné z: https://www.me- tricstream.com/rfp-templates/index.htm SOA, 2017. Service Oriented Architecture [online]. [cit. 2017-09-29]. Dostupné z: https://en.wikipedia.org/wiki/Service-oriented_architecture STARÝ, O., 2003. Reálné opce. Praha: A plus. ISBN 80-902-5146-3. Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 165 SVOZILOVÁ, A., 2006. Projektový management. Praha: Grada. Expert (Grada). ISBN 80- 247-1501-5. TEC, 2007. RFP Templates [online]. [cit. 2017-09-29]. Dostupné z: https://www3.techno- logyevaluation.com/store/ THOMSON, A., 2005. Business Feasibility Study Outline [online]. [cit. 2017-09-29]. Dostupné z: http://bestentrepreneur.murdoch.edu.au/Business_Feasibility_Study_Outline.pdf VESELÝ, J., 2005. Produkční funkce – účinný nástroj ekonomické analýzy firem (2). AT&P Journal, (6). 73-75. VIKTOŘÍK, T. a A. STEHLÍK, 2008. Reálné opce jako podpora investičního manažerského rozhodování. E+M Ekonomie a management (1). ISSN 1212-3609. VLČEK, J., 1994. Inženýrská informatika. Praha: České vysoké učení technické. Expert (Grada). ISBN 80-010-1071-6. VRANA, I. a K. RICHTA, 2005. Zásady a postupy zavádění podnikových informačních systémů: praktická příručka pro podnikové manažery. Praha: Grada. Management v informační společnosti. ISBN 80-247-1103-6. VRBA, P., 2004. MAST – multiagentní simulační systém. AUTOMA, (5). ISSN 1210- 9592. VYMĚTAL, D. a S. MATÝŠEK, 2007. Implementace ERP systému u nadnárodní organizace. ICT Systems, (12). ISSN 1802-002-X. VYMĚTAL, D., 2008. Information Systems in Multi-Cultural Environments: Some Impacts and Ideas how to solve them. In: Proceedings of the 5th International Symposium on Business Administration. Canakkale-Turkey. ISBN 978-975-8100-78-1. VYMĚTAL, D., 2008. Balanced Quotation Analysis in ICT Projects. E+M Ekonomie a management, (2). ISSN 1212-3609. VYMĚTAL, D., 2009. Value Chain and Process Models: is the Gap between them real? In: Distance Learning Simulation and Communication Proceedings. Brno: Univerzita obrany. 198-205. ISBN 978-80-7231-638-0. VYMĚTAL, D., HUČKA, M., HUŇKA, F. a J. KAŠÍK, 2009. Process and value chain modeling: combining both perspectives into one. IN: Proceedings of CEE-SET 2009 part Software Engineering Techniques in Progress. Krakow: AGH University of Science and Technology Press. 43-52. ISBN 978-83-7464-259-0. VYMĚTAL, D., 2009. Informační systémy v podnicích: teorie a praxe projektování. Praha: Grada, 2009. Průvodce (Grada). ISBN 978-80-247-3046-2. WOLF, P., 2006. Úspěšný podnik na globálním trhu: teorie a praxe projektování. Bratislava: CS Profi-Public. Průvodce (Grada). ISBN 80-969-5465-2. WIENER, N., 1963. Kybernetika a společnost. Praha: Academia. ISBN 99-00- 01998-X. Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 166 YOURDON , E., 2006. Just enough structured analysis [online]. [cit. 2017-09-29]. Dostupné z: https://docs.google.com/file/d/0B42Cu1mD9Z7seVVHLUdqb1Q1SlU/preview ZID, N., 2008. Vybrané aspekty procesního řízení [online]. [cit. 2017-09-29]. Dostupné z: https://mpra.ub.uni-muenchen.de/10745/ Dominik Vymětal, Roman Šperka, Petr Suchánek - Projektování informačních systémů 167 SHRNUTÍ STUDIJNÍ OPORY Vážené čtenářky a čtenáři, V této chvíli již máte za sebou studium dané studijní opory, jejímž cílem bylo seznámit v první řadě studenty studijního programu Manažerská informatika na SU OPF s teorií a praxí zavádění IS do podniků a nekomerčních institucí, na straně druhé zájemce o danou problematiku z řad studentů jiných studijních oborů a programů, vše nejen na SU OPF, ale i jiných vysokých školách. Problematika zavádění IS je a i v budoucnu bude jedním z prvořadých proudů oboru informatika a management, protože význam IS pro podporu efektivity podniků a organizací neustále narůstá a odvíjí se od rozvoje nových technologií, nástrojů a přístupů, kterými mohou být například datové sklady, big data, data mining, business intelligence, virtuální realita, apod. Všechny uvedené a celá řada dalších již dnes mají a stále více budou mít významný vliv na možnosti, které IS budou v budoucnu uživatelům nabízet. O těchto technologiích ale již bude řeč v dalších předmětech. 168 PŘEHLED DOSTUPNÝCH IKON Čas potřebný ke studiu Cíle kapitoly Klíčová slova Nezapomeňte na odpočinek Průvodce studiem Průvodce textem Rychlý náhled Shrnutí Tutoriály Definice K zapamatování Případová studie Řešená úloha Věta Kontrolní otázka Korespondenční úkol Odpovědi Otázky Samostatný úkol Další zdroje Pro zájemce Úkol k zamyšlení Název: Projektování informačních systémů Autor: Ing. Dominik Vymětal, DrSc.; doc. RNDr. Ing. Roman Šperka, Ph.D.; doc. Mgr. Petr Suchánek, Ph.D. Vydavatel: Slezská univerzita v Opavě Obchodně podnikatelská fakulta v Karviné Určeno: studentům SU OPF Karviná Počet stran: 169 Tato publikace neprošla jazykovou úpravou.