Vysoká škola ekonomická v Praze

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra systémové analýzy

Uplatnění systémového myšlení v analytické fázi vývoje IASW doktorská disertační práce

Doktorand :

Ing. Anna Exnarová

Školitel

:

doc. Ing. Stanislava Mildeová, CSc.

Obor

:

Informatika

© 2013 Anna Exnarová [email protected]

při citaci uvádějte odkaz: Exnarová, Anna. Uplatnění systémového myšlení v analytické fázi vývoje softwaru. Disertační práce, VŠE FIS, Praha, 2013.

Praha, květen 2013

Anna Exnarová

Abstrakt Informační systémy (jako jeden z typů komplexních systémů) jsou v procesu vývoje zatíženy poměrně vysokým procentem neúspěšnosti. Pomoci při řešení problémů informačních systémů (či jejich dílčích složek) můžou disciplíny, které jsou orientované na řešení komplexních problémů. Systémové myšlení a systémová dynamika, jakožto součásti systémové vědy, poskytují nástroje, které umožňují pochopit systémy a adekvátně reagovat na dynamické změny prostředí. Návrh uplatnění systémového myšlení v analytické fázi vývoje individuálního aplikačního softwaru (IASW) je hlavním cílem této disertační práce. Nástrojem pro toto uplatnění jsou modely – návrh propojuje modely systémového myšlení a systémové dynamiky s modely vývoje IASW dle notace UML. Dílčím cílem práce je uvedení pojmu model, který je propojujícím pojmem a je v celé práci diskutován v různých kontextech. Dále práce vymezuje pojmy systém, informační systém a IASW, systémové myšlení a systémová dynamika s cílem objasnění jejich vzájemného kontextu z pohledu aplikovatelnosti v analytické fázi vývoje IASW. Dalším cílem, který vychází z hlavního cíle práce, je aplikace návrhu v praktické studii. Generalizujícím přínosem práce je propojení pojmů systém, model a systémové myšlení z pohledu aplikovatelnosti těchto kategorií v analytické fázi vývoje IASW. Hlavním přínosem je vytvoření návrhu aplikace systémového myšlení do oblasti vývoje IASW. Tímto způsobem je definován popis přístupu jak je možné uplatnit systémové myšlení v procesu vývoje softwaru a tím zvýšit úspěšnost vývoje softwaru, potažmo vývoje celého informačního systému. Práce potvrdila, že v analytické fázi vývoje IASW existuje možnost uplatnění systémového myšlení a toto rozšíření je přínosné. Práce je rozdělena na teoretickou a praktickou část. V teoretické části jsou diskutovány relevantní pojmy a jejich charakteristiky a provedeno jejich kritické zhodnocení ve vztahu k možnosti uplatnění systémového myšlení v analytické fázi IASW. Rovněž v této části práce je předložen návrh, jak je možné systémové myšlení uplatnit při vývoji IASW. V praktické části práce je dokumentováno využití systémového myšlení při vývoji IASW v praxi.

Klíčová slova Systémové myšlení, systémová dynamika, model, vývoj software, individuální aplikační software

2 | 146

Anna Exnarová

Abstract The main objective of this dissertation is to propose an application of systems thinking in the analytic stage of the development of individual application software (IASW). The tools for this application are models – the proposal connects models of systems thinking and system dynamics with IASW development models according to the UML notation. The partial objective of this dissertation is to introduce the concept of model which is the interconnecting concept and which is discussed in different contexts throughout the dissertation. Furthermore, the dissertation defines the concepts of system, information system and IASW, systems thinking and system dynamics with the aim of clarifying their mutual context from the point of view of their applicability in the analytic stage of the IASW development. A further objective which follows from the main objective of the dissertation is the application of the proposal in a practical study. The general contribution of this dissertation is the interconnection of the concepts of system, model and systems thinking from the point of view of the applicability of these categories in the analytic stage of the IASW development. The main contribution is the creation of a proposal of systems thinking application in the field of IASW development. This defines the approach for applying systems thinking in the process of software development and thus for increasing the success of the software development, or possibly of the whole information system. The dissertation proved that systems thinking can be applied in the analytic stage of the IASW development and that this broadening is beneficial. The dissertation is divided into a theoretical and a practical part. The theoretical part includes a discussion of the relevant concepts and their characteristics and it also includes their critical assessment in relation to the possibility of using systems thinking in the analytic phase of IASW. This part of the thesis also includes a proposal on how systems thinking can be applied in the IASW development. The practical part of the thesis documents the use of systems thinking in the practical development of IASW.

Keywords Systems thinking, system dynamics, model, software development, individual application software

3 | 146

Anna Exnarová

Zusammenfassung Das Hauptziel dieser Dissertation ist der Anwendungsentwurf der systemischen Denkweise in der analytischen Entwicklungsphase der individuellen Applikationssoftware (IASW). Als Instrumente für diese Anwendung stehen Modelle zur Verfügung – der Entwurf verbindet Modelle der systemischen Denkweise und der Systemdynamik mit Modellen der IASW-Entwicklung nach der Notation der Sprache UML. Das Teilziel dieser Arbeit ist die Anführung des Begriffes "Modell", das ein Verbindungsbegriff ist und das in der ganzen Arbeit in verschiedenen Kontexten diskutiert wird. Ferner definiert die Arbeit Begriffe wie "das System", "das Informationssystem und die IASW", "die systemische Denkweise und die Systemdynamik" mit dem Ziel, ihren gegenseitigen Kontext aus der Sicht der Anwendbarkeit in der analytischen Entwicklungsphase der IASW zu erklären. Ein weiteres Ziel, das vom Hauptziel der Arbeit ausgeht, ist die Anwendung des Entwurfes in der praktischen Studie. Einen generalisierenden Beitrag dieser Arbeit stellt die Verbindung der Begriffe "das System", "das Modell" und "die systemische Denkweise" aus der Sicht der Anwendbarkeit dieser Kategorien in der analytischen Entwicklungsphase der IASW dar. Der Hauptbeitrag ist die Erstellung eines Entwurfes der Anwendung der systemischen Denkweise im Bereich der IASW-Entwicklung. Auf diese Art und Weise wird die Beschreibung der Einstellung definiert, wie es möglich ist, die systemische Denkweise im Softwareentwicklungsprozess anzuwenden und dadurch den Erfolg der Softwareentwicklung, beziehungsweise den Erfolg der Entwicklung des ganzen Informationssystems zu erhöhen. Die Arbeit bestätigte, dass in der analytischen Phase der IASW-Entwicklung die Möglichkeit der Anwendung der systemischen Denkweise existiert und dass diese Erweiterung nutzbringend ist. Die Arbeit ist in einen theoretischen und einen praktischen Teil unterteilt. Im theoretischen Teil werden relevante Begriffe und ihre Charakteristiken diskutiert und es wird ihre kritische Bewertung in Bezug auf die Möglichkeit der Anwendung der systemischen Denkweise in der analytischen IASW-Phase durchgeführt. In diesem Teil der Arbeit wird ebenfalls der Entwurf vorgelegt, wie es möglich ist, die systemische Denkweise bei der IASW-Entwicklung anzuwenden. Im praktischen Teil der Arbeit wird die Nutzung der systemischen Denkweise bei der IASW-Entwicklung in der Praxis dokumentiert.

Schlüsselworte Systemische Denkweise, Systemdynamik, Modell, Softwareentwicklung, individuelle Applikationssoftware

4 | 146

Anna Exnarová

Poděkování Za obětavou podporu a velkou trpělivost bych velmi ráda poděkovala všem mým blízkým.

Velmi velké děkuji patří doc. Ing. Stanislavě Mildeové, CSc. za odborné rady, konzultace a připomínky a rovněž za podporu i čas, které mi věnovala v průběhu celého mého studia i při vzniku této disertační práce.

5 | 146

Anna Exnarová

Prohlášení Prohlašuji, že doktorskou práci na téma „Uplatnění systémového myšlení v analytické fázi vývoje IASW“ jsem vypracovala samostatně. Použitou literaturu a podkladové materiály uvádím v přiloženém seznamu literatury.

v Praze dne 31. května 2013

………………………………. Podpis

6 | 146

Anna Exnarová

Obsah 1

Úvod ........................................................................................................................................... 11 1.1 Vymezení řešené oblasti, objekt, předmět, nástroj zkoumání ......................................................... 13 1.2 Cíle a předpokládané přínosy práce................................................................................................. 14 1.3 Hypotézy a omezení práce ............................................................................................................... 15 1.4 Použité metody ................................................................................................................................ 16 1.5 Struktura práce ................................................................................................................................ 17

2

Systém a model ........................................................................................................................... 19 2.1 Teoretická východiska objektu zkoumání ........................................................................................ 19 2.1.1 Rozbor pojmu systém............................................................................................................... 19 2.1.2 Analytický versus systémový přístup ....................................................................................... 21 2.1.3 Základní vlastnosti systémů ..................................................................................................... 24 2.1.4 Dělení systémů ......................................................................................................................... 26 2.1.5 Organizace a její informační systém......................................................................................... 30 2.2 Model............................................................................................................................................... 41 2.2.1 Životní cyklus modelů............................................................................................................... 42 2.2.2 Modely informačních systémů ................................................................................................. 44 2.2.3 Vlastnosti modelů z pohledu standardizace ............................................................................ 45 2.2.4 Modely vytvářené v analytické fázi vývoje IASW ..................................................................... 50

3

Systémové myšlení a Systémová dynamika ................................................................................ 58 3.1 Informace a znalosti v organizaci .................................................................................................... 58 3.1.1 Koncept data, informace, znalosti............................................................................................ 58 3.1.2 Znalosti v organizaci ................................................................................................................. 59 3.1.3 Znalostní proces ....................................................................................................................... 60 3.1.4 Problematika kvality a kvantity dat .......................................................................................... 63 3.2 Systémové myšlení a jeho modely ................................................................................................... 64 3.2.1 Systémový přístup .................................................................................................................... 64 3.2.2 Systémové myšlení ................................................................................................................... 66 3.2.3 Dovednosti systémového myšlení............................................................................................ 69 3.2.4 Mentální modely ...................................................................................................................... 70 3.2.5 Myšlenkové mapy .................................................................................................................... 72 3.2.6 Modely šestiúhelníků ............................................................................................................... 74 3.2.7 Diagram příčin a následků ........................................................................................................ 75 3.2.8 Příčinně – smyčkové diagramy ................................................................................................. 77 3.3 Systémová dynamika a její modely.................................................................................................. 79 3.3.1 Model stavů a toků .................................................................................................................. 81

4

Uplatnění systémového myšlení v analytické fázi vývoje IASW ................................................... 84 4.1 Stav poznání .................................................................................................................................... 84 4.2 Uplatnění systémového myšlení v analytické fázi vývoje IASW prostřednictvím modelů systémového myšlení ............................................................................................................................. 90 4.2.1 Důvody vytvoření návrhu ......................................................................................................... 90 4.2.2 Podmínky návrhu uplatnění systémového myšlení v analytické fázi vývoje IASW .................. 94 4.2.3 Uplatnění jednotlivých typů modelů v analytické fázi vývoje IASW ........................................ 95 4.2.4 Vztahy jednotlivých typů diagramů........................................................................................ 100 4.2.5 Závěry návrhu......................................................................................................................... 103

5

Aplikace návrhu uplatnění systémového myšlení v analytické fázi vývoje IASW v praxi ............ 105

7 | 146

Anna Exnarová

5.1 Úvod praktické studie .................................................................................................................... 105 5.2 Firma a její způsob vývoje softwaru .............................................................................................. 106 5.3 Sběr požadavků ............................................................................................................................. 107 5.3.1 Okolí Firmy ............................................................................................................................. 107 5.3.2 Vliv okolí na Firmu .................................................................................................................. 111 5.3.3 Formulace zadání ................................................................................................................... 117 5.3.4 Případy užití a katalog požadavků .......................................................................................... 123 5.4 Analýza .......................................................................................................................................... 126 5.4.1 Pohled na aplikaci EVZ z pohledu entit .................................................................................. 126 5.4.2 Stavový a procesní pohled na aplikaci EVZ............................................................................. 129 5.4.3 Návrh architektury systému ................................................................................................... 133 5.5 Zhodnocení validace návrhu .......................................................................................................... 133 6

Závěr ......................................................................................................................................... 135 6.1 Naplnění cílů práce ........................................................................................................................ 135 6.2 Ověření hypotéz ............................................................................................................................. 136 6.3 Přínosy disertační práce................................................................................................................. 136 6.3.1 Zhodnocení validace návrhu .................................................................................................. 137 6.4 Předpokládané další využití práce ................................................................................................. 138

7

Použitá literatura ...................................................................................................................... 139

8

Vlastní publikace ....................................................................................................................... 145

9

Přehled zkratek ......................................................................................................................... 146

8 | 146

Anna Exnarová

Seznam tabulek Tab. 1 Porovnání syntéza vs. analýza (Haines, 2000, str. 8)........................................................ 24 Tab. 2 Silné a slabé stránky iterativního modelu životního cyklu IASW (upraveno dle (Buchalcevová, 2009)) ................................................................................................................. 37 Tab. 3 Perspektivy systému a jejich UML diagramy (Chang, 2005, str. 5) .................................. 54 Tab. 4 Porovnání atributů systémové dynamiky a objektově-orientovaného přístupu (Chang, 2005) ........................................................................................................................................... 85 Tab. 5 Integrovaný proces vývoje (Chang, 2005, str. 16) ............................................................ 86 Tab. 6 Objektově orientovaný přístup a relevantní pohled systémové dynamiky (Tignor, 1999) ..................................................................................................................................................... 89 Tab. 7 Vybrané příčiny neúspěchu vývoje IASW ......................................................................... 92 Tab. 8 Mapování diagramu hladin a toků na diagram stavů....................................................... 98 Tab. 9 Modely aplikace EVZ ...................................................................................................... 121 Tab. 10 Funkční požadavky (Firma, 2011) ................................................................................. 123

Seznam obrázků Obr. 1 Hranice disertační práce .................................................................................................. 13 Obr. 2 Cíle disertační práce ......................................................................................................... 14 Obr. 3 Struktura disertační práce ................................................................................................ 18 Obr. 4 Systém a jeho vlastnosti................................................................................................... 25 Obr. 5 Dekompozice systému (zdroj neznámý) .......................................................................... 25 Obr. 6 Komponenty organizace a jejich vztahy (Vodáček, 1997, str. 39) ................................... 31 Obr. 7 Fáze vývoje IS podle MMDIS (upraveno z (Voříšek, 2008, str. 132)) ............................... 35 Obr. 8 Iterativní model životního cyklu softwaru (Buchalcevová, 2009, str. 53) ........................ 37 Obr. 9 Fáze a disciplíny UP (Buchalcevová, 2009, str. 122)......................................................... 40 Obr. 10 Atributy standardizovaných modelů .............................................................................. 47 Obr. 11Atributy nestandardizovaných modelů........................................................................... 49 Obr. 12 Struktura UML ................................................................................................................ 52 Obr. 13 – typy diagramů UML (upraveno z (Arlow, 2007, str. 37))............................................. 53 Obr. 14 Transformace informace (upraveno z (Vodáček, 1997, str. 63)) ................................... 59 Obr. 15 Cyklus znalostí SECI (upraveno (Umemoto, 2002) a (Gasson, 2007)) ............................ 61 Obr. 16 Stavy lidského poznání (Vodáček, 1997, str. 29)............................................................ 63 Obr. 17 Příklad myšlenkové mapy .............................................................................................. 73 Obr. 18 Diagram hexagonů ......................................................................................................... 75 Obr. 19 Příklad diagramu příčin a následků ................................................................................ 76 Obr. 20 Příklad příčinně-smyčkového diagramu (převzato z (TMCG, 2013)).............................. 78 Obr. 21 Systémové myšlení a systémová dynamika ................................................................... 79 Obr. 22 Proces modelování (upraveno z (Sterman, 2000, str. 88)) ............................................ 81 Obr. 23 Příklad diagramu stavů a toků (převzato z (TMCG, 2013)) ............................................ 82 Obr. 24 Integrovaný informačný systém (Chang, 2005, str. 17) ................................................. 87 Obr. 25 Diagram hladin a toků SD založen na diagramu aktivit UML (Tignor, 2003, str.8) ........ 88 Obr. 26 Vztahy mezi jednotlivými typy diagramů ..................................................................... 101 Obr. 27 Následnost diagramů v návrhu .................................................................................... 102 Obr. 28 Informační tok .............................................................................................................. 103 Obr. 29 Možnost rozšíření návrhu do ....................................................................................... 104 Obr. 30 IS VZ, náhled na formulář veřejné zakázky, (MMR, 2013) ........................................... 109 Obr. 31 IS VZ, vyhledávání podle více parametrů, (MMR, 2013) .............................................. 110 Obr. 32 Analýza příčin transformace systému veřejných zakázek ............................................ 111

9 | 146

Anna Exnarová

Obr. 33 Informační potřeba – změna struktury zainteresovaných zaměstnanců .................... 112 Obr. 34 Obecný model trhu VZ ................................................................................................. 114 Obr. 35 Vnitřní proces ve Firmě ................................................................................................ 115 Obr. 36 Důvody změn ve Firmě – myšlenková mapa................................................................ 116 Obr. 37 Důvody změn ve Firmě – rybí páteř ............................................................................. 117 Obr. 38 Potřeba rozšíření portfolia ........................................................................................... 117 Obr. 39 Důvody vzniku interní aplikace EVZ ............................................................................. 118 Obr. 40 Činnosti Firmy v souvislosti s VZ .................................................................................. 119 Obr. 41 Diagram požadavků (Firma, 2011) ............................................................................... 124 Obr. 42 Use case model EVZ (Firma, 2011) ............................................................................... 125 Obr. 43 Use case model EVZ – doplněk (Firma, 2011) .............................................................. 126 Obr. 44 Use case model EVZ – doplněk 2 (Firma, 2011) ........................................................... 126 Obr. 45 Možné stavy VZ – zkoumání entit ................................................................................ 127 Obr. 46 Konceptuální model tříd (Firma, 2011) ........................................................................ 128 Obr. 47 Doménový model – původní návrh (Firma, 2011) ....................................................... 128 Obr. 48 Doménový datový model ............................................................................................. 129 Obr. 49 Původní návrh stavového modelu ............................................................................... 129 Obr. 50 Stavy veřejných zakázek z pohledu interních procesů Firmy ....................................... 130 Obr. 51 Stavový diagram (Firma, 2011) .................................................................................... 131 Obr. 52 Zvýšení kvality dat v EVZ .............................................................................................. 132 Obr. 53 Možné rozšíření aplikace z pohledu správy kompetencí ............................................. 132 Obr. 54 Návrh architektury EVZ ................................................................................................ 133

10 | 146

Anna Exnarová

1 ÚVOD Dynamika, zrychlování, komplexita prostředí, složitost problémů, nárůst interakcí, přibližování se bodu zvratu – pojmy, které moderní společnost musí akcentovat ve všech oborech. Současný vývoj společnosti vede ke zrychlování změn i nepředvídatelnosti chování jejích systémů. Objevující se nepravidelnosti, vzorce chování se vyskytují ve složitějších interakcích a strukturách. Změny, které se ve společnosti projevují již několik desetiletí, jak konstatoval např. Drucker (1994), jsou nepravidelné a nelineární. Na rozdíl od minulosti jsou problémy, které ve společnosti vznikají, mnohem více nevypočitatelné a neočekávané (rozsahem i dopady). Nahlédnutím do historie lze najít paralely současného vývoje společnosti – chybné definování příčin a následků, změna konkurenčního prostředí, morální a etický pokles společnosti, technické vynálezy či měnící se principy dělby práce. „Mravní bída je příčina, hospodářský úpadek je následek. V postavení, v němž se nacházíme, nepotřebujeme žádných geniálních obratů a kombinací. Potřebujeme mravní stanoviska k lidem, k práci a veřejnému majetku. Máte pravdu, je třeba překonat krizi důvěry, technickými zásahy, finančními a úvěrovými ji však překonat nelze, důvěra je věc osobní a důvěru lze obnovit jen mravním hlediskem a osobním příkladem.“ (Baťa, 1932) V čem jsou tedy současné problémy tak jiné? Proč je potřebné hledat nová řešení a nelze použít zkušeností a poučení z historie? Pokud se opakují vzorce chování a základní principy problémů jsou stejné, z jakého důvodu lidstvo není schopné uplatnit uspokojivý způsob řešení? Současné působení globalizace a rychlého pokroku v oblasti technologií má značný dopad na společnost. Pojem globalizace spojuje Mildeová (2007) s nárůstem interakcí, komplexitou systémů, zvyšujícím se rizikem rozhodování, měnící se společenskou dělbou práce i jejím charakterem, změnou v sociálně-ekonomické kooperaci i měnícími se podmínkami konkurenčního chování. Integrovat do svého chování schopnost přizpůsobit se změnám a novým podmínkám, schopnost učení se, talent správně pracovat s informacemi, způsobilost vyhodnocovat zpětné vazby na své chování, to vše jsou dovednosti, které úspěšná společnost či organizace musí dokonale ovládat. V opačném případě není možné, aby dlouhodobě byla úspěšná a (na trhu) přežila. Úspěšnost je spojena také se schopností uplatnit svou konkurenční výhodou. Ta ale není statická, dle měnících se podmínek musí organizace neustále reagovat na své okolí a korigovat podle změn okolí i svoji konkurenční výhodu tak, aby o ni nepřišla. „Každá nová diskontinuita vyžaduje, aby podniky utlumily stávající činnosti a vyvinuly nové schopnosti a zdroje podnikání.“ (Beer, 2010) Organizaci nepostačuje pouze schopnost sledovat změny v okolí. Musí se jim aktivně přizpůsobovat a aktivně vyhledávat místa na trhu, která může díky svým schopnostem a dovednostem zaplnit. Samozřejmě, tyto aktivity musí být v souladu s požadavkem na dosažení zisku či jiného cíle. Zcela přirozeně se tak snaží vytvářet nové konkurenční výhody a uplatňovat svůj rozvoj tak, aby byl ekonomicky výhodný. „Společným jmenovatelem výzvy turbulentní či chaotické budoucnosti je umění včas získat a

11 | 146

Anna Exnarová

zhodnotit klíčový zdroj podmiňující podnikatelsky účelné a ekonomicky účinné chování organizace.“ (Vodáček, 1997, str. 116) Nástroje na to, jak se lépe vyrovnat s dynamickými změnami okolí, jak dokázat pracovat s neustálými reformami, jak se naučit pochopit systémy a správně reagovat, poskytují systémové přístupy, a mezi nimi systémové myšlení a systémová dynamika. Nástroje těchto oborů umožňují analyzovat komplexní systémy, objevovat příčinněnásledkové vazby, zpoždění a zpětné vazby. (Mildeová, 2006, str. 40) Důsledkem již existujících změn a zároveň i příčinnou vzniku nových jsou mimo jiné také pokroky v technologiích – jak obecně, tak jmenovitě v oblasti informačních a komunikačních technologiích (ICT). V mnoha oborech je pokrok a vývoj ovlivněn právě novými možnostmi, které se objevují v souvislosti s vývojem technologií, s čímž velmi úzce souvisí také pokrok a rozvoj v oblasti informačních systémů (IS). Praxe ukazuje, že rozvoj a uplatňované trendy neodráží plně reálnou potřebu. Vývoj informačních systémů zklamal tím, že je poměrně drahý, pomalý a nepředvídatelný. (Schwaber, 2012) Bohužel dlouhodobě je zatížen poměrně vysokým procentem neúspěšnosti. Ve výsledné zprávě výzkumného projektu „CHAOS“ Standish Group z roku 2011 (Schwaber, 2012) bylo dokladováno, že více než polovina projektů vývoje informačních systému, které byly vytvářeny v letech 2002 až 2010, byla vyhodnocena jako neúspěšné. Pouze 37% bylo zařazeno do kategorie úspěšných projektů1. Pravděpodobnost, že vývoj informačního systému bude úspěšný, nejsou velké. Snaha o výrazné zvýšení úspěšnosti projektů vývoje informačních systémů je do velké míry hnacím motorem rozvoje tohoto oboru. Domnívám se, že poptávka po implementaci nových technologií je v mnoha případech vedená ze strany soukromých organizací, které dokáží státní orgány přesvědčit o naléhavosti problémů a samozřejmě možnostech, které jim nabízí při řešení. Mnohdy ale chybí nebo není dostatečně ověřena skutečná potřeba, prozkoumány relevantně a hlavně komplexně problémy a všechny možnosti jejich řešení, včetně finančních kritérií a možností úspor. Dle výzkumu publikovaného Voříškem (2012) je také potvrzeno, že pouhé nasazení ICT nezvyšuje produktivitu práce. Bohužel v průběhu vývoje a nasazení, a ani po jejich ukončení a vyhodnocení vývoje nejsou k dispozici metriky produktivity a hodnocení úspěšnosti. „Samotné nasazení nových technologií nevede automaticky k pozitivním efektům. Nepromyšlená investice může naopak vést k vysokým ztrátám – to platí zejména pro ICT.“ (Voříšek, 2012) Nicméně trend je jasný – velké finanční objemy v oblasti implementace nových systémů, integrace na centrální registry, nebo povyšování hardwaru jsou často financované za výrazné podpory Evropské unie. Pro zvýšení efektivity je klíčovým správné využití dostupných technologií. V rámci této diskuse připomeňme, že jednou z významných částí informačního systému je software, konkrétně individuální aplikační software (IASW). Předkládaná disertační práce spojuje problematiku vývoje IASW (jako součást informačního systému, který 1

Pojem úspěšný projekt představuje ty projekty, které za plánovanou cenu poskytnou všechnu požadovanou funkcionalitu v požadovaném termínu. Samozřejmě výzkum pracuje s předem danými parametry, které jsou hodnoceny, a které nepokrývají všechny dimenze, které projekt ovlivňují.

12 | 146

Anna Exnarová

chápu jako komplexní systém) s disciplínami, které pomáhají řešit dynamické problémy komplexních systémů – systémovým myšlením a systémovou dynamikou. Touto cestou se pokouším poskytnout nástroj na zlepšení výsledků analytické fáze a tím i celého vývoje IASW, potažmo vývoje informačního systému. 1.1 Vymezení řešené oblasti, objekt, předmět, nástroj zkoumání Hranicemi předkládané disertační práce jsou následující (relativně samostatné) oblasti: • systémové myšlení a systémová dynamika, • vývoj IASW (který je součástí informačního systému), především v jeho analytické fázi vývoje. Tyto relativně samostatné oblasti jsou vzájemně propojeny modelováním – v práci jsou diskutovány a uplatněny modely systémového myšlení a systémové dynamiky, stejně tak jako modely používané v analytické fázi vývoje IASW2 (konkrétně se jedná o modely vytvořené v notaci UML3). Vymezení hranic disertační práce dokumentuje Obr. 1.

Obr. 1 Hranice disertační práce

Objektem zkoumání je systém4. Vzhledem k zastřešení celé práce systémovými vědami je pojem systém výchozím pojmem, který je akcentován a vyskytuje se v práci v různých kontextech ve všech kapitolách. Obecný termín systém je konkretizován na kategorii informační systém5, software a IASW. S pojmem IASW je dále pracováno a pozornost je zaměřena na analytickou fázi jeho vývoje. Hranice zkoumání byly vytyčeny objektově orientovaným vývojem a použitím metodiky Unified proces (UP). Předmětem zkoumání je model6. Model je uváděn v různých souvislostech, které jsou příslušné jednotlivým kapitolám a jejich zaměření. První důležitou kategorií pojmu model je jeho konkretizace na model informačního systému a dále na modely IASW

2

Individuální aplikační software (též aplikace, software) – součást programového vybavení, komponenta informačního systému, která umožňuje realizaci a automatizaci konkrétní funkcionality. 3 Unified Modeling Language – viz např. http://www.uml.org/. 4 Systém je reálný objekt, ve kterém existují prvky a jejich vzájemné vazby a existuje bez zásahu pozorovatele. 5 Informační systém je účelové uspořádání vztahů mezi komponentami (lidé, datové zdroje, procedury a jejich zpracování, technologické prostředky). 6 Model je chápán jako reprezentace reálného systému, diagram je vizuální podoba modelu.

13 | 146

Anna Exnarová

v notaci UML. Druhou konkretizací předmětu mého výzkumu jsou modely systémového myšlení a systémové dynamiky7. Propojením těchto dvou kategorií pojmu model je vytvořen návrh uplatnění systémového myšlení v analytické fázi vývoje IASW. Takto vymezené hranice výzkumu jsou dány těmito faktory: • studijní zaměření na modelování informačních systémů; • dlouhodobé studium systémového myšlení a možností jeho aplikace; • reálné praktické zkušenosti z firemní praxe na pozici „model architect“. 1.2 Cíle a předpokládané přínosy práce Generalizujícím cílem práce je propojení pojmů systém, model a systémové myšlení z pohledu aplikovatelnosti v analytické fázi vývoje IASW. Kontext těchto pojmů přináší nový autorský pohled na spojení uvedených kategorií a rozšiřuje uplatnění systémového myšlení. Návrh uplatnění systémového myšlení v analytické fázi vývoje individuálního aplikačního softwaru je hlavním cílem této disertační práce. Jedná se tedy o návrh na konkrétní aplikaci systémového myšlení. Nástrojem pro toto uplatnění jsou modely – návrh propojuje modely systémového myšlení a systémové dynamiky s modely vývoje IASW dle notace UML. Myšlenkou tohoto cíle je navrhnout, jak je možné uplatnit systémové myšlení v procesu vývoje IASW a tím zvýšit úspěšnost realizace jeho vývoje, potažmo vývoje celého informačního systému. Tento cíl je dále zkráceně uváděn jako „návrh uplatnění SM“.

Obr. 2 Cíle disertační práce

Výše uvedené hlavní cíle práce jsou podpořeny dílčími cíli v jednotlivých oblastech (viz Obr. 2 Cíle disertační práce).

7

Systémové myšlení chápu jako integrální součást systémové dynamiky, včetně jejich společných nástrojů.

14 | 146

Anna Exnarová

Dílčím cílem v souvislosti s pojmem systém je vytvoření uceleného rámce poznatků, které jsou relevantní pro „návrh uplatnění SM“. Naplnění tohoto cíle přináší ucelenou relevantní analýzu pojmu systém. Zároveň také definuje hranice „návrhu uplatnění SM“ – konkrétně se jedná o vymezení typů systémů, vývojového cyklu a metodiky, které jsou pro návrh vhodné. Dílčím cílem v oblasti modelování je představení pojmu model a jeho charakteristik, relevantních pro naplnění hlavních cílů práce. Pojem model je uváděn do souvislostí s dalšími pojmy. V oblasti systémového myšlení je dílčím cílem představení současného stavu vědeckého poznání se současným hledáním oblastí, které jsou relevantní z pohledu „návrhu uplatnění SM“. Pozornost je zaměřena na systémové myšlení a systémovou dynamiku a jejich nástroje. V oblasti aplikace „návrhu uplatnění SM“ je dílčím cílem aplikace návrhu v praxi. Realizace tohoto dílčího cíle dokladuje použitelnost návrhu uplatnění SM“ v praxi, jeho verifikace je provedena formou praktické studie. Studie zároveň poskytuje dokumentované nasazení „návrhu uplatnění SM“ v praxi.

Dle výše uvedených komentářů k jednotlivým cílům práce lze očekávat následující přínosy: • Ucelená kritická rešerše systémového myšlení a jeho modelů. • Vytvoření rámce poznatků systémového myšlení relevantních pro vytvářený návrh. • „Propagace“ a rozšíření oborů systémové myšlení a systémová dynamika do odborných skupin zabývající se vývojem softwaru, resp. informačních systémů. • Vytvoření návrhu uplatnění systémového myšlení v analytické fázi návrhu a vývoje IASW. • Praktická studie dokladující použití uvedeného návrhu v praxi. Spojení systémového myšlení a vývoje IASW je v české literatuře novým tématem, které není podrobněji prozkoumáno. Ve světových publikacích je pouze částečně rozpracován vztah systémové dynamiky a UML, a vztah systémové dynamiky a objektově-orientovaného vývoje. 1.3 Hypotézy a omezení práce Z uvedených cílů vyplývá základní hypotéza zkoumaná v disertační práci: stávající analytickou fázi vývoje IASW je možno rozšířit směrem k systémovému pojetí. Vedle této základní hypotézy je v rámci výzkumu pracováno také s dalšími dílčími hypotézami: • Analytická fáze vývoje IASW neposkytuje dostatečné výsledky. Tyto nedostatky mohou být jednou z příčin neúspěchu celého projektu vývoje IASW, potažmo celého informačního systému. • Systémové myšlení je oborem, který by mohl pomoci odstranit některé příčiny neúspěchů vývoje IASW v analytické fázi.

15 | 146

Anna Exnarová

• • •

Modely systémového myšlení a modely systémové dynamiky je možné použít v analytické fázi návrhu IASW. Aplikací systémového přístupu dochází k posunu, resp. k rozšíření znalostního portfolia firmy. V procesu vývoje IASW, příp. informačních systémů, lze a je vhodné použít modely systémové dynamiky, včetně jejich simulací.

V práci jsou propojeny dvě velké a zároveň relativně oddělené oblasti – systémové myšlení a vývoj informačních systémů (reprezentován vývojem IASW). Omezení práce z pohledu vlastního výzkumu souvisí především s hloubkou provedených a v práci dokladovaných rešeršních činností. Není možné provést úplnou komplexní analýzu tak širokých oborů jako je systémové myšlení a vývoj IASW. Detail provedené analýzy byl odvozován od hlavního cíle práce, nicméně lze konstatovat, že pro další rozvoj tématu je mnoho oblastí, které by bylo možné diskutovat. Zaměření práce na spojení vývoje IASW a systémových věd předurčuje, že větší pozornost je věnována oblasti systémových věd, která je nově aplikována do „známé“ oblasti vývoje informačních systémů. Literární prameny byly vyhodnocovány s vlastními kritickými komentáři a byl vytvořen rámec poznatků systémového myšlení, které jsou relevantní pro vytvoření návrhu rozšíření vývoje IASW.

1.4 Použité metody Použité metody vědecké práce jsou v souladu s kategorizací a s doporučeními pro vědeckou práci, které byly publikovány v (Molnár, 2012). Strategií (ve smyslu stanovení cílů a jejich dosažení), kterou jsem si na začátku řešení disertační práce stanovila, bylo rozdělení disertační práce na dvě části. První část disertační práce je zaměřena na uvedení teoretických východisek a vytvoření vlastního rámce poznatků systémového myšlení relevantních pro vytvářený návrh. Druhá část je praktická, orientovaná na realizaci výzkumu a aplikaci jeho závěrů v praxi. Metoda vědeckého výzkumu je postup, jak pomocí určitých principů dosáhnout pravdivého poznání (dle (Molnár, 2012)). Tamtéž je uvedeno, že metodikou je rozuměn pracovní postup; technika je konkrétní nástroj, který vychází z principů metody a umožňuje získat konkrétní poznatky o zkoumaných jevech. V tomto kontextu je metodou, metodikou pro mou disertační práci systémové myšlení. Vzhledem k povaze systémového myšlení lze konstatovat, že jeho principy lze použít jako metodiku i techniku pro řešení úloh konkrétní oblasti. Systémové myšlení tvoří nosnou část mé vědecké práce. Systémové myšlení jsem v práci využila ve smyslu komplexního pohledu na problematiku, v aplikaci zpětné vazby, v pohledu na systém v rovině systémové hierarchie a dynamického chápání souvislostí. Jak je dále v práci detailně představeno, použití systémového myšlení je spojeno s akcentem příčin, následků a zpětnovazebních smyček, se zaměřením se na procesy a integrace. Dalším charakteristikou je, že systémové myšlení umožňuje pohled na problematiku z pozice systémové hierarchie, komplexní tvorby modelů a jejich ověřování v praxi.

16 | 146

Anna Exnarová

V první etapě výzkumu byly použity především empirické metody výzkumu – konkrétně pozorování, na základě kterého jsem identifikovala možnosti zájmu mého zkoumání. Pomocí technik sběru dat jsem na základě skutečných dokumentů konkretizovala předmět zkoumání. V této fázi byl použit deskriptivní přístup a logické metody indukce a dedukce. Komunikací s odborníky z praxe, při řízeném interview, byla získána zpětná vazba ze strany odborníků z praxe, kde jsem si v úzkém vybraném okruhu ověřila smysluplnost zaměření výzkumu. Následující fáze zpracování disertační práce již byla spojena s normativním přístupem, tedy na základě literární rešerše a podrobné analýzy a syntézy poznatků byly navrženy teoretické závěry. Lze tedy konstatovat, že zde byly rovněž použity logické metody zkoumání: analýza a syntéza pro zpracování informací a vytvoření uceleného a navzájem provázaného systému znalostí. Poslední jmenovanou metodou, ale nikoliv svým významem pro zkoumání v disertační práci bylo modelování. Jednotlivé použité metody jsem kombinovala, jejich využití nebylo oddělené, ale naopak často kombinované a provázané. V dílčích oblastech jsem využívala iterativního přístupu, výstupy byly verifikovány a doplňovány dle dílčích výsledků i dle potřeb a výsledků navazujících částí.

Nezbytnou součástí bylo využití následujících softwarových nástrojů: • Enterprise Architect firmy Sparx Nástroj pro vizualizaci, modelování a design, obsahuje plnou integraci notace UML; v práci byl použit pro tvorbu modelů dle notace UML; http://www.sparxsystems.com/. • MS Visio firmy Microsoft Nástroj na kreslení nestandardizovaných schémat a modelů, obsahuje základní integraci notace UML; v práci byl použit pro tvorbu nestandardizovaných modelů; http://office.microsoft.com/cs-cz/visio/business-and-software-diagramsvisio-professional-FX103472299.aspx. • XMind firmy XMind Nástroj pro myšlenkové modelování; v práci použit při tvorbě myšlenkových map a rybí páteře; http://www.xmind.net/; • Vensim firmy Ventana Systems Nástroj pro vytváření modelů systémové dynamiky; v práci použit pro vytváření příčinně-smyčkových modelů a modelů stavů a toků; http://vensim.com/.

1.5 Struktura práce Jednotlivé kapitoly disertační práce pokrývají tři hlavní oblasti: 1) První oblast je zaměřena na představení teoretických východisek, kritického hodnocení a záměrného výběru pojmů a jejich charakteristik s ohledem na předmět zájmu. K tomuto bodu se vážou kapitoly 2 a 3. Druhá kapitola nejprve charakterizuje pojem systém, který je upřesněn na pojem organizace a její informační systém a graduje

17 | 146

Anna Exnarová

k definování klíčového pojmu IASW. V druhé části této kapitoly je představen pojem model, jeho charakteristiky a je vztažen k pojmu IASW ve smyslu modelů vývoje IASW v notaci UML. Třetí kapitola dokumentuje vybrané relevantní charakteristiky a modely systémového myšlení a systémové dynamiky, které jsou vztaženy k pojmu systém přes koncept data-informace-znalosti. 2) Druhá oblast představuje návrh uplatnění systémového myšlení v analytické fázi vývoje IASW. Tomuto se věnuje čtvrtá kapitola, která obsahuje popis současného stavu poznání a uvádí publikace, ze kterých bylo při návrhu vycházeno. Dále jsou zde uvedeny předpoklady, omezení a především popis vlastního návrhu. 3) Třetí oblastí je praktická studie. Ta je obsahem páté kapitoly a dokumentuje uplatnění systémového myšlení při vývoji IASW na reálném případě. Vzhledem k tomu, že se jedná o dokumentaci reálné situace, neodpovídají některé parametry (např. terminologie, použití modelů dle notace UML, fáze vývoje) teoretickým definicím a standardům. Cílem kapitoly nicméně není narovnávat vlastní proces vývoje IASW dle vědecké teorie, ale ověřit, zda je možné aplikovat v reálném prostředí prvky systémového myšlení na základě vytvořeného návrhu. Strukturu disertační práce a její kapitoly demonstruje Obr. 3.

Obr. 3 Struktura disertační práce

18 | 146

Anna Exnarová

2 SYSTÉM A MODEL Kapitola Systém a model předkládá výsledky analýzy objektu a předmětu zkoumání. První část kapitoly je věnována pojmu systém. Nejdříve jsou uvedeny závěry rešeršní činnosti týkající se pojmu systém, jeho základních vlastností a kategorií, především z pohledu systémových věd, na což navazuje diskuse o systémovém a analytickém přístupu k řešení problémů8. Konkrétní aplikací pojmu systém jsou následně diskutované pojmy – organizace a informační systém. V kontextu informačního systému jsou uvedeny jeho vybrané aspekty a komentován jeho životní cyklus s cílem uvedení východisek pro kapitolu 4.2 – Uplatnění systémového myšlení v analytické fázi vývoje IASW prostřednictvím modelů. Druhá část této kapitoly je zaměřena na pojem model a jeho vybrané charakteristiky. Je definován vztah k pojmu diagram a uvedeny kategorie modely informačních systémů a modely UML. Modely UML tvoří druhou skupinu východisek pro návrh uplatnění systémového myšlení v analytické fázi vývoje IASW (kapitola 4.2). 2.1 Teoretická východiska objektu zkoumání 2.1.1 Rozbor pojmu systém

Systém je pojem rozšířený, běžně používaný v nejrůznějších kontextech a v mnoha oborech. Vzhledem k rozšířenosti tohoto pojmu v běžném životě i praxi se mnoho autorů vyhýbá jeho bližší specifikaci. Pojem systém je často definován vymezením, že se jedná o skupinu / soubor / množinu / shluk vymezených / vybraných částí / prvků, které tvoří jeden celek. Obecné vymezení pojmu systém je možné definovat následujícím způsobem: systém je soubor jeho prvků. Domnívám se, že v mnoha případech toto zjednodušení nelze odmítat nebo vytýkat. Jsou legitimní případy, kdy opravdu není potřebné detailnější definice, ani není potřebné hlubší pochopení tohoto pojmu. V souladu s uvedenou obecnou definicí pojmu systém je vymezení systému dle Ludwiga von Bertalanffyho (1696) jako kombinace prvků, které se nacházejí ve vzájemné interakci nebo jsou na sebe vzájemně závislé a tvoří celek. Tato definice v sobě nese pokus o uchopení složitých a komplexních jevů tím, že se pokouší tyto jevy roztřídit do dílčích částí. Nedochází však k jejich striktnímu „vyčlenění“ ze systému, nýbrž stále přetrvává snaha o uchování všech vazeb mezi částmi systému. V tomto pojetí je tedy možné systém chápat jako: • něco více než jen jednoduchý součet částí, • soubor určitých částí (prvků, složek), mezi kterými kolují látky a energie.

8

K pojmům týkající se systémových věd se práce vrací v kapitole 3, která obsahuje analýzu pojmů systémové myšlení, systémová dynamika a jejich modely (včetně pojmu mentální model a diskuse k pojmům data, informace a znalosti.).

19 | 146

Anna Exnarová

Křemen ve své publikaci (2007, str. 72) uvádí: „Systém je soubor relevantních znalostí o vytyčené části reálného světa zapsaných ve vhodném objektovém jazyce, který je součástí formálního jazykového systému se syntaktickou inferencí. Hodnota intenzionální vágnosti významu všech jazykových konstrukcí objektového jazyka se tedy nutně blíží k nule.“ Zároveň konstatuje, že systém je „z hlediska lidského vědomí vnějším modelem“. Autor v této publikaci poměrně důsledně komentuje problematiku jazyka, lidského vědomí a přístupu k pojmu systém. Deklaruje, že při práci s pojmem systém je nezbytně nutné věnovat pozornost a vyjasnit problematiku zaměňování reality se znalostmi o realitě. (Křemen, 2007, str. 70) Mezi další, často citované definice, patří poznatky od R. Gibbsona, který pod pojmem systém vidí integrovaný souhrn vzájemně působících prvků, určený na kooperativní plnění předem stanovené funkce. J. Veselý představuje systém jako účelově definovanou množinu prvků (jistých vlastností) a množinu vazeb (jistých vlastností) mezi nimi, které spolu určují vlastnosti, chování a funkce systému jako celku. W. R. Ashby k systému přistupuje jako k jakémukoliv souhrnu proměnných, které pozorovatel vybírá z počtu proměnných vlastních reálnému světu. (definice převzaty z (Rosický, 2005)) Na rozdíl od této definice R. Gibbson chápe systém jako existující entity, bez ohledu na člověka. Ale v definici od Veselého je již pozorovatel akcentovaný. Veselý uvádí„účelově definovanou množinu“ – tedy musí existovat pozorovatel, který zná účel, má svůj mentální model i znalosti a na základě nich dokáže systém vymezit. Ashby již doslovně mluví o pozorovateli a jeho aktivnímu přispění ke vzniku systému – bez „výběru proměnných“ (tj. bez aktivní činnosti) by systém neexistoval. Nicméně všechny definice mluví o reálném světě, reálných entitách, ze kterých je vybíráno. Naproti tomu Křemen definuje systém jako soubor „relevantních znalostí“. Tedy už ne objekty reálného světa, ale mentální modely. Haines (2011, str.1) definuje systém jako množinu částí, které pracují společně pro cíl celku. Tento přístup předpokládá, že části jsou součástí jednoho systému, jehož účelu a cíli slouží. Otázkou ale je, zda části systému nutně patří pouze do jednoho systému nebo mohou „sloužit“ cílům více systémů. V takovém případě by pak účel systému a funkce jeho částí nebyly v přímém vztahu příčiny (cíle systému) a důsledku (účelu částí), ale důsledkem by byl samotný výběr vhodných částí s patřičnou funkcí. Tento výběr probíhá u různých systémů v různý okamžik – např. u biologických systémů evolučně, u informačních systémů ve fázi návrhu atp. Dalším pohledem na systém, který koresponduje s touto prací je pohled Meadowse. D.H. Meadows (2008, str. 11) uvádí, že „systémem rozumíme množinu vzájemně propojených prvků, které jsou bezrozporně organizovány takovým způsobem, že něčeho dosahují. Pokud se podíváme na definici blíže, můžeme vidět, že systém se musí skládat ze tří druhů částí: prvků, vazeb a funkcí či účelu.“ Navíc systém má vlastnosti, které vznikají emergencí dílčích částí a existují pouze díky existenci celého systému (tedy nejen díky jeho částem, ale i díky existenci struktury systému). K tomuto pojetí je možné doplnit Caprův pohled, který říká, že tyto nově vzniklé vlastnosti existují pouze se systémem a v případě, že dojde k zániku systému jeho rozložením na izolované části, tyto vlastnosti zanikají. „Vlastnosti částí systému nejsou

20 | 146

Anna Exnarová

skutečnými vlastnostmi systému“ a tudíž nelze analýzou systému (ve smyslu rozkladu systému na jeho části a jejich izolovaném zkoumání) poznat skutečné vlastnosti systému. (Capra, 2004, str.39, 40) Každý systém má své okolí. „Okolí tvoří prvky nebo systémy, jejichž vzájemné vazby nejsou z hlediska řešení našeho systému zajímavé.“ (Bébr, 2005, str. 46) Prvky okolí nejsou předmětem zkoumání, nicméně ovlivňují systém a proto je potřebné akcentovat vazby z okolí na zkoumaný systém. Tomu odpovídá např. i notace modelů systémové dynamiky, která pro tento typ prvků zavádí samostatnou grafickou reprezentaci (více kapitola 3.3.1 – Model stavů a toků). Pro práci s pojmem systém často nepostačuje pouhé definování. Pro to, aby bylo možné považovat složitý reálný objekt za systém, je rozhodující přístup k tomuto objektu, způsob jeho pojetí, způsob práce s ním, nikoliv jeho věcná povaha. (Rosický, 2005) Diskusi o systémovém přístupu k řešení problémů jako protikladu ke klasickému analytickému řešení problémů (potažmo základní předpoklady kategorie systémové myšlení) je věnovaná podkapitola 2.1.2 Analytický versus systémový přístup. Některé publikace systém vymezují pouze na jeho tvrdou část (hardware a software). Nicméně s přetrvávajícími problémy při vývoji, nasazování a správě rozsáhlých informačních systémů, a potažmo hledání možných příčin a snaze o jejich odstranění, se ukazuje toto pojetí za nedostačující. Stále ve větší míře se lze setkat s přístupem, který akcentuje také měkké prvky systému a chápe systém v kontextu systémových přístupů dle výše uvedených definic jako komplexní celek. Tedy systém není pouze souborem jednotlivých částí, ale vlastnosti systému jsou tvořeny i jeho strukturou a okolím. Z pohledu norem je možno pojem systém nalézt v mezinárodní normě ISO/IEC 15288, která popisuje životní cyklus systému, nebo v normě ISO/IEC 12207, která se věnuje vývoji softwaru. V kontextu těchto norem Buchalcevová (2009, str. 15) uvádí systém „jako soubor komponent účelově uspořádaných k dosažení určitého cíle nebo skupiny cílů. Obecné systémy definované v normě ISO/IEC 15288 jsou systémy vytvořené a používané lidmi. Tyto systémy poskytují produkt nebo službu v definovaném prostředí pro uspokojení potřeb uživatelů a ostatních zainteresovaných stran. Zahrnují hardware, software, data, lidi, procesy a procedury, zařízení, materiál a přírodní zdroje.“ V rámci této práce je systémem chápán reálný objekt, ve kterém existují prvky a jejich vzájemné vazby, a tyto existují bez zásahu pozorovatele. Význam pozorovatele je v tom, že přisuzuje význam a vybírá z reality vazby a definuje si obraz systému pomocí svých mentálních modelů. Systém tedy existuje i bez jeho zásahu. 2.1.2 Analytický versus systémový přístup

Literatura zabývající se systémovým myšlením či systémovou dynamikou dává do opozice k systémovému přístupu tradiční způsob řešení problémů – nazývaný mechanistický nebo analytický (např. (Bureš, 2011), (Vodáček, 1997), (Haines, 2000), (Mildeová, 2007), (Capra, 2004)). Pro tuto kategorii v práci používám pojem „tradiční analytický“ přístup. Bureš (2011) tradiční analytický přístup nazývá mechanistický, za základ tohoto přístupu považuje redukcionismus a mechanismus. Rozklad jakéhokoliv problému na 21 | 146

Anna Exnarová

soubor dílčích prvků, které jsou atomické, nazývá „analytickým výkladem objektivní zkušenosti“. V tomto kontextu konstatuje, že pojem analyzovat znamená následující kroky. • Rozložit problém na základní prvky. • Vysvětlit chování jednotlivých prvků osamoceně. • Odůvodnit chování celku na základě chování jeho částí. Vodáček (1997) popisuje rozpor analytického přístupu a systémového přístupu. Upozorňuje na kvalitu systému a jeho vlastnosti, které se vynořují pouze u funkčního celku a při analytické dekompozici se ztrácí. Rozkládat systém na části a těm se nezávisle věnovat, je přístup, který je možný pouze u jednoduchých typů systémů. U všech ostatních systémů vede analytické úsilí k nepřípustnému zjednodušení systému (označovanému jako redukcionismus) a náhradě systémového přístupu za analyticko— mechanický. Tento přístup je důsledkem víry člověka v to, že co je možné aplikovat (redukcionismus) v měřítku malém (tedy v jednoduchém systému), platí i ve velkém (tedy složitém, komplexním systému). Bébr velmi vhodně konstatuje, že „je zajímavé, že systém jako celek vykazuje nejen vlastnosti dané sjednocením vlastností všech jednotlivých prvků, ale i vlastnosti další, zcela nové. Tomu se říká emergence.“ (Bébr, 2005, str. 45) V konkretizaci s praxí informatiky pak říká: „V praxi se pak projevuje obdobný úkaz, dosud nepojmenovaný a vědecky nezpracovaný: Při vývoji systému se potkáváme neustále s takřka nepřekonatelnými překážkami, pracně a s námahou řešíme základní požadované funkce a obrovské úsilí vynakládáme na sladění funkcí alespoň na elementární úrovni. V určité fázi tvůrčí práce nastane zlomový okamžik, kdy systém náhle začne snadno a dobře plnit veškeré zadané úlohy, různé jeho funkce a činnosti bez problémů hladce spolupracují – k tomu všemu pak systém od této chvíle umí mnohem víc, než se po něm původně chtělo! Jakoby samy od sebe odkrývají se nové funkce a činnosti, po nepatrných úpravách zpracovává systém i úlohy, které v zadání vůbec nebyly a na které řešitel původně ani nepomyslel. Teoretický důkaz tohoto tvrzení chybí, praxe ho však plně potvrzuje.“ (Bébr, 2005, str. 45) Mechanismus je založen na názoru, že veškeré chování a poznávání může být zcela vysvětleno pomocí kauzálně interagujících mechanických procesů, což lze na zkoumání závislostí a jevů aplikovat tak, že všechny závislosti mezi nimi lze vysvětlit opakovaným použitím jednoduché souvislosti „příčina-následek“, neboli kauzalitou. Důsledky tohoto přístupu spatřuje Bureš (2012) ve schematizaci myšlení, domněnce, že následky lze beze zbytku vysvětlit příčinami. Tento způsob myšlení způsobuje nemalé množství problémů a obtíží. Slabé stránky analytického přístupu byly podnětem pro vznik systémovému přístupu. Kromě zmíněné dekompozice systému na prvky a s tím související další charakteristiky, se jedná také o přístup vysvětlit každé chování přísně kauzálním lineárním mechanismem a navazujícími procesy. „Běžné analytické myšlení ignoruje dynamiku a variabilitu.“ (Mildeová, 2007, str. 8) V systémovém myšlení je celek primární a jeho části jsou sekundární. Naproti tomu v analytickém myšlení jsou části primární a celek je sekundární. (Haines, 2000, str. xiii)

22 | 146

Anna Exnarová

„Hlavními rysy systémového přístupu jsou za první komplexnost a za druhé důmyslná koncepce a současně pečlivé provedení detailů.“ (Bébr, 2005, str. 71) „Obrovským šokem vědy dvacátého století bylo to, že systémům nemůžeme porozumět na základě jejich analýzy. Vlastnosti částí nejsou skutečnými vlastnostmi, ale mohou být pochopeny pouze v kontextu většího celku.“ (Capra, 2004, str. 40) Capra (2004) uvádí, že systémový přístup je tzv. „kontextuální“ a je opakem analytického. Analytický přístup je postaven na rozdělení systému do částí a ty v zájmu porozumění odděleně zkoumá. Přistupovat k problému pomocí systémového myšlení znamená umístit problém do kontextu většího celku. V systémovém přístupu je možné pochopit vlastnosti částí i celku pouze na základě vlastností a chování celého systému, myšlení se nesoustřeďuje na stavební bloky celku, ale spíše na základní principy a chování organizace. Dle výše uvedené teorie můžeme hovořit o čtyřech základních principech: přístup ke struktuře a její hierarchii, vazby obohacené o zpětné smyčky, kruhovost a nelinearitu, a vzájemné komunikaci jak uvnitř systému, tak s okolím. Jak již bylo naznačeno, systémové myšlení můžeme vnímat jako jakýsi protipól ke standardnímu analytickému přístupu řešení problémů. „Systémové myšlení je kontextuální, což je opakem analytického myšlení. Analýza znamená pojímat něco odděleně v zájmu porozumění. Systémové myšlení znamená umístit to do kontextu většího celku.“ (Capra, 2004, str. 40) Pokud bude problém řešen s použitím systémového přístupu a konkrétně použitím myšlení v uzavřených smyčkách, Mildeová (2007) uvádí, že bude systém reprezentován jako dynamický sled vzájemně závislých procesů. V případě, že by byl systém zkoumán pouze z pohledu jednosměrných vztahů, bude jeho model pouze skupinou faktorů a jevů, které tyto faktory způsobují. „Přesvědčení, že v každém složitém systému lze chování celku zcela porozumět z vlastností jeho součástí, je ústřední v karteziánském paradigmatu. To byla Descartova proslulá metoda analytického myšlení, která se stala základní charakteristikou moderního vědeckého myšlení. Analytický neboli redukcionistický přístup nedokáže dále analyzovat samotnou část, aniž by ji redukoval na stále menší části. A opravdu, západní věda dosud takto postupuje. Na každém kroku je úroveň základních složek taková, že už je nelze dále analyzovat.“ (Capra, 2004, str. 39) Uplatnění systémového přístupu Bébr (2005, str. 71) spojuje s: • cíleně vytvářeným a účelově využívaným komplexem dílčích disciplín, na základě jejich propojení vytvoření adekvátního celku znalostí; • způsobem myšlení a jednání, kdy zkoumané a řešené problémy jsou zkoumány komplexně v jejich vnitřních i vnějších souvislostech.

23 | 146

Anna Exnarová

Následující tabulka (Tab. 1) uvádí porovnání jednotlivých kategorií analytického a systémového přístupu dle Hainesa. Tab. 1 Porovnání syntéza vs. analýza (Haines, 2000, str. 8)

Systémový přístup Synergismus

Interakce částí taková, že výsledný efekt je větší než součet individuálních částí (2+2=5)

Syntéza

Kombinace částí nebo elementů tak, aby tvořily celek

Synergický

Spoluprácující, kooperující

Analytický přístup Redukcionismus

Zúžení; pokus vysvětlit všechny biologické procesy stejnými vysvětleními, které chemici a fyzikové používají k interpretaci neživé hmoty; redukuje složitá data nebo jevy na jednoduché pojmy, tj. zjednodušení

Analýza

Oddělení celku na jeho části, výzkum složité entity jejích elementů a vztahů

Analytický

Rozdělující něco v části

Pro aplikaci způsobu myšlení nutného pro systémový přístup Bébr (2005) uvádí tyto požadavky: • Je potřebné poznat a pochopit všechny vazby a vztahy mezi prvky uvnitř systémů, i mezi systémem a jeho okolím; pozornost musí být věnována všem aspektům, tj. technickým, organizačním, personálním, sociálnům, kulturním, atd. • Velmi často je zjištěno, že zdánlivě nesmyslné nebo nemožné vazby systém výrazně ovlivňují. Také těmto vazbám musí být věnována pozornost a musí se s nimi náležitě pracovat. • Je nutné zabývat se proporcionálně celkem i detailem. • Při řešení problémů klást důraz na to „kam se potřebujeme dostat“, na cílový stav.

2.1.3 Základní vlastnosti systémů

Systémový přístup je vědní disciplína, jejíž snahou je vysvětlení chování reálných entit pomocí teorie systémů, přičemž důraz klade na pojem systém a na základě jeho charakteristik se snaží toto chování vysvětlit. Chápání systému v rámci této disciplíny je zakotveno ve způsobu komplexního myšlení nad prvky systému a vazbami v rámci vnitřních i vnějších souvislostí. Definovat systém znamená dokázat definovat jeho části a vztahy v rámci interních i externích souvislostí tak, aby byla zabezpečena celistvost systému.

24 | 146

Anna Exnarová

Systémový přístup je definován 4 základními principy, které lze aplikovat také při popisu základních vlastností systémů9 (Mildeová, 2007): • holismus a emergence; • systémová hierarchie; • zpětná vazba; • komunikace. Pojmy uvedené v první odrážce jsou stavebními kameny systémových přístupů. Pro správnou aplikaci je nezbytně nutné respektovat systémový způsob celistvého nazírání na zkoumané objekty. „Respektuje se tzv. holismus, tj. osobitá kvalita systému, která není dána jenom vlastnostmi jeho jednotlivých částí. Teprve jejich vzájemná interakce – navíc v určitém prostředí – vytváří tzv. emergentní vlastnosti systému.“ (Vodáček 1997, str. 51) Na Obr. 4 Systém a jeho vlastnosti jsou znázorněny prvky, jejich vazby, a to v daném prostředí teprve vytváří systém. Vlastnosti, které se vynořují, objevují (emergují) jsou výsledkem kooperace a integrace dílčích částí s jejich dílčími vlastnostmi. Vlastnosti celého systému jsou souborem dílčích vlastností jednotlivých částí a emergujících vlastností existujících pouze v případě, že systém existuje jako celek.

Obr. 4 Systém a jeho vlastnosti

Následující příklad demonstruje skutečnosti, že sloučením částí do celku ještě nemusí vzniknout ten samý objekt jako před rozložením. Problém nerekonstruovatelnosti systému (tedy problém rozložení systému na jednotlivé části a „zapomnění“ vlastností celku) je patrný při rozložení a opětovném složení jednoduchého obrazce na Obr. 5. Informace o celku jsou nepopiratelně stejně důležité jako informace o jednotlivých prvcích systému. Nemůžeme odděleně od sebe pozorovat části, důležité jsou jejich vazby a synergie nových vlastností. (Senge, 1995) Zároveň s nutnou interakcí prvků je potřebné akcentovat vliv prostředí, které rovněž systém formuje a určuje jeho vlastnosti. Na níže uvedeném obrázku vedle nově vzniklých interakcí je znázorněno rovněž rozdílné působení okolí a tudíž vznik jiných vlastností systému jako celku.

Obr. 5 Dekompozice systému (zdroj neznámý)10 9

Podrobněji jsou tyto vlastnosti diskutovány v kapitole 3.2.

25 | 146

Anna Exnarová

Systémové myšlení je jedním z prostředků, jak nahlížet na svět ve shodě se systémovými přístupy a s uvedenými definicemi pojmu systém. Autoři Vojtko (2005) a Komárek (2006) uvádějí shodný přístup k pojmu systémové myšlení – systémové myšlení je určitý specifický a unikátní způsob pohlížení na svět spolu, který se snaží respektovat a překonávat určitá omezení našeho každodenního myšlení vzhledem k realitě. Tyto omezení mohou být dána přírodou a strukturou našeho mozku, nebo výchovou a vzděláním. Systémové myšlení je disciplína, pomocí které můžeme lépe popisovat realitu – konstruovat model reality a kvalitněji simulovat a odhadovat chování systému za pomocí těchto modelů. Umožňuje přesněji odhadnout důsledky, které přinese naše rozhodnutí. Tím lze zvyšovat pravděpodobnost úspěchu našeho jednání. Systémovému myšlení se dále věnuje kapitola 3.2.

2.1.4 Dělení systémů

Systémy lze dělit z různých hledisek, podle toho, k jakému účelu a s jakým cílem toto dělení je nutné provést. Často uváděné základní kategorie systémů jsou: • umělé a přirozené, • živé a neživé, • otevřené a uzavřené, • technické a sociální, • měkké a tvrdé, • konkrétní a abstraktní. Pro potřeby systémových přístupů se ukazují tyto základní dělení jako nedostatečná, proto se lze setkat s mnoha dalšími dělení. Mezi již tradiční rozdělení systémů patří Checklandovo a Bouldingovo dělení. Bouldingovo dělení živých systémů (Haines, 2000, str. 13) definuje sedm úrovní hierarchie. Toto členění se v současnosti často používá pro kategorizaci organizací či jiných sociálních skupin. 1. Buňky (základní jednotka života) 2. Orgány (organické systémy uvnitř našich těl) 3. Organismus (jednoduché organismy jako lidi, zvířata) 4. Skupina (týmy, oddělení, rodiny,…) 5. Organizace (firma, sousedství, komunita, město, soukromé, veřejné, neziskové) 6. Společnost (státy, provincie, země, národy, regiony uvnitř zemí) 7. Nadnárodní systém (kontinenty, regiony, Země) Existuje rozšíření tohoto dělení, kdy buňky jsou nejmenší, ale existují ještě tři nižší stupně hierarchie, které již nejsou živými systémy, a to jsou chromozomy, DNA a geny. Toto rozšíření je vhodné pro případy, kdy model zahrnuje i hierarchie na takto nízké úrovni.

10

Obrázek byl pravděpodobně uveden v (Rosický, 2005), původ se nepodařilo zjistit.

26 | 146

Anna Exnarová

Ve mnoha případech postačuje členění tří úrovní, tj. (1) organizmus, jedinci; (2) skupiny, týmy, rodiny; (3) organizace a komunity. Tyto úrovně živých systémů utvářejí základ, každá systémová úroveň je v hierarchii se všemi dalšími a má také vazby s jinými živými systémy na jejich vlastní úrovni. Jedinci interagují jednu k jedné, týmy či oddělení spolupracují (či si vzájemně konkurují), organizace jako celky mají také vazby na své okolí. Tyto vztahy rozšiřují zaměření systému na změnu každé z těchto úrovní: 3a. jedna ku jedné; 4a. mezi odděleními; 5a. mezi organizací a okolním prostředím. Z pohledu vývoje systému, jeho prvků a struktur je možné na systém pohlížet z pohledu dynamiky. Statický systémy je systém, který se v čase nemění, naproti tomu dynamický systém vykazuje v čase proměnlivost prvků, vazeb, charakteristik. Z pohledu dalšího zkoumání je právě kategorie dynamického systému zásadní, protože právě tato kategorie je především předmětem zkoumání systémového myšlení a systémové dynamiky. Mezi další kategorii systémů, které jsou dále v práci akcentované patří dělení systémů na měkké a tvrdé. Měkký a tvrdý systém

Jedno z hlavních členění systémů je kategorizace na měkké a tvrdé systémy. Pod pojmem tvrdý systém najdeme systémy, které jsou především technologického charakteru, základním rysem je jejich dobrá strukturovatelnost a popsatelnost. Tyto systémy lze dobře popsat, kvantifikovat a exaktně vyjádřit vztah mezi vstupními a výstupními proměnnými. V případě tvrdých problémů lze většinou řešení algoritmizovat, což následně vede k automatizaci řešení. Protipólem tvrdých systémů jsou měkké systémy, které představují špatně strukturované systémy. Jsou to poměrně vysoce strukturované a složité systémy, počet vztahů a prvků je vysoký a špatně popsatelný. Míra rizika, neurčitosti a nejistoty jsou poměrně časté a zvyšují komplexitu systému. K popsání systému jsou často využívány přibližné a vágní popisy a hodnoty. Chování těchto systémů je těžko předvídatelné a jde pouze s určitou mírou pravděpodobnosti popsat vztah mezi vstupními a výstupními hodnotami. Častým prvkem těchto systémů je člověk a sociální skupiny. Jeho chování je predikovatelné pouze v omezené míře. Pojem měkký systém zavedl Peter Checkland jako reakci na obecnou teorii systémů vytvořenou von Bertalanffym, která byla vybudovaná na základě odpozorovaných izomorfních vztahů mezi biologickými a fyzikálními systémy. Obecná teorie systémů říká, že je možné vytvářet interdisciplinární modely a ty (nezměněné) využívat v různých oblastech vědy. Toto je tvrdý systémový přístup = všechny prvky a vztahy v systému jsou měřitelné a lze je zkoumat obecně platnými modely a nástroji. Tvrdý systémový přístup hojně využívá matematického aparátu (např. operačního výzkumu). Měkký systémový přístup se naopak snaží o vytvoření metodologie (prostředky jak co nejlépe popsat problém – nematematickými nástroji, často i vágním způsobem, neboť jiná možnost není), která identifikuje základní elementy problému a na základě nich je pak rozhodnuto jaká metodologie a jaké nástroje mají být použity k řešení. 27 | 146

Anna Exnarová

Příkladem řešení tvrdého problému může být optimalizace chodu výrobní linky – zadání problému je dobře definovatelné (např. snížit čas na vyrobení jednoho výrobku) a všechny údaje je možné získat exaktním měřením (současný čas na vytvoření jednoho výrobku, jednotlivé fáze výroby…). Naopak typicky měkkým problémem je zodpovězení otázky „Jak zkvalitnit služby poskytované našim zákazníkům?“. Peter Checkland člení systémy do čtyř skupin (Rosický, 2005): 1. Přirozené systémy (které lze rozdělit na systémy živé a neživé). 2. Navrhované umělé systémy (ty systémy, které jsou vytvářené člověkem s daným záměrem, cílem). 3. Systémy lidských aktivit (systémy, jejichž základem jsou sociální systémy a mezilidské vztahy, nicméně nezbytnou součástí jsou i technické systémy). 4. Transcendentální systémy (jsou to systémy, které přesahují hranice lidského chápání, ale jeho podmnožiny jsou skupiny systémů výše zmíněné). Druhým významným dělení systémů představují kategorie definované Kennethem Bouldingem. Bouldingova taxonomie systémů (převzato z (Rosický, 2005)): • Fyzikální systémy: Prvky jsou fyzikální částice a vztahy představují fyzikální zákony. Existuje tu lineární řád a vzájemně se kontrolující síly. • Mechanické systémy: Stroje, zařízení, technologie, vztahy se řídí jasnými pravidly a existuje zde deterministické chování. • Kybernetické systémy: Systémy se zpětnou vazbou, díky ní lze regulovat chování systému. • Otevřené systémy: Systémy spojené s existencí života, interakce s okolím. • Genetické systémy: Tyto systémy mají společný genetický kód, nastávají zde změny organizace a tím rozvoj genofondu. • Animální systémy: Tyto systémy se vyznačují účelovým chováním, mobilitou vůči okolí a schopností adaptace na okolí (pouze pasivní = reakce na to co se stalo). • Člověk: Významným se stává vědomí vlastní existence. Dokáže se aktivně přizpůsobovat a adaptovat na změny v okolí (nejen ve vztahu k minulosti ale i k budoucnosti). Vnímání reality a komunikace je prostřednictvím záměrně vytvořených symbolů. • Sociální systémy: Jsou to záměrně vytvářené systémy, kde dochází ke konfrontaci a kooperaci prvků a sdílení informací a jazyka. • Transcendentální systémy: Označení pro systémy, které nejsou popsatelné současnou mírou poznání. Systém jako objekt

Systém obsahuje prvky a vazby mezi nimi. Na těchto bodech se shodne většina definic. Výrazně se liší v tom, zda tyto prvky a vazby jsou obsahem reálného světa (a zda jsou závislé na pozorovateli nebo existují i bez jeho aktivity), nebo zda jsou obsahem modelu, který pozorovatel vytvořil. Tedy lze pozorovat dva základní koncepty systému – systém jako model a systém jako objekt.

28 | 146

Anna Exnarová

Za systém můžeme považovat složitý reálný nebo abstraktní objekt, v němž rozlišujeme části, vztahy mezi nimi a vlastnosti. Vůči okolí vystupuje systém jako celek. Části systému jsou ve vzájemné interakci a interagují i se systémem jako celkem. Označujeme je jako prvky systému a vztahy mezi nimi nazýváme vazbami systému. Pro to, abychom považovali složitý reálný objekt za systém, rozhoduje náš přístup k tomuto objektu, způsob jeho pojetí, způsob práce s ním, nikoliv jeho věcná povaha. (Rosický, 2005) Uvedená definice pracuje se systémem jako s objektem reálného světa. Objekt reálného světa nicméně neznamená pouze hmotné entity, ale také abstraktní pojmy. Můžeme je spíše definovat jako na pozorovateli systému nezávislé entity, které by existovaly i bez snahy pozorovatele definovat tento systém. Existují dvě možnosti jak nahlížet na systém jako objekt: • Systém existuje bez vazby na pozorovatele. • Systém ke svému vzniku potřebuje pozorovatele. Toto dvojí možné chápání systému je patrné i z definic systémů dle různých autorů. Systém jako entita reálného světa bez vazby na pozorovatele je systém, který existuje bez lidského přičinění. Takto vnímaný systém existuje neustále, jeho existence je dána, struktura a vazby na okolí jsou přirozeně vytvořené vývojem. Samotná existence a vývoj zabezpečuje základní principy existence systému. Například strom v lese je samostatným systémem, který je vymezen svojí strukturou a vazbami mezi jednotlivými částmi, komunikace s okolím je prostřednictvím větví, kůry, zpětná vazba v reakci na změny v prostředí, emergence systému lze spatřovat v životě stromu, systémová hierarchie je samostatně tvořena na úrovni koruny, listů, buněk,… V takto vnímaném systému je výrazným faktorem samo-organizace a spontánní vývoj. Je potřebné si také uvědomit, že pokud je nějaký systém zkoumán, nejde toto zkoumání provádět bez zásahu do systému. Může se zdát, že např. při zkoumání toho, jak jsou v podniku prováděny procesy, pozorovatel neovlivňuje tyto procesy. Pouze je pozoruje a snaží se je pochopit. Ale i samotnou svou existencí tyto procesy může ovlivňovat (např. pracovníci pod dohledem se snaží, aby byli plně vytíženi, aby bylo patrné, že jejich přítomnost je nepostradatelná, …). Markantní je to v případě zkoumání jednobuněčných organismů nebo struktur na úrovni atomů. Zde již samotné pozorování (je nutné provádět za speciálních podmínek, aby bylo možné uskutečnit), výrazně ovlivňuje chování systému. Systém vytvořený pozorovatelem jako entita reálného světa je koncept systému, kdy pozorovatel záměrně vybírá z reality reálné nebo abstraktní entity a modeluje si z nich svoji vlastní podobu systému. Částečně se tento koncept kryje s předchozím konceptem ve chvíli, kdy na scénu nastupuje pozorovatel. Ten vždy musí záměrně vybírat entity, které zkoumá a tím vytváří vlastní systém. Nikdy není schopen pojmout svůj pohled na systém s tím, jak ve skutečnosti existuje – důvodem je jeho omezená schopnost vnímání, kdežto realita je souborem nekonečných variací. Nicméně ve chvíli, kdy pozorovatel vytváří systém a snaží se ho v realitě vyčlenit, musí již pracovat se svým mentálním modelem – pouze tak dokáže o systému přemýšlet a pracovat s ním. Tím se vlastně stává systém modelem.

29 | 146

Anna Exnarová

Systém jako model

Výrazným faktorem v konceptu systému jako modelu je proces poznávání a lidského myšlení. Tyto procesy jsou prostředkem pro vytvoření modelu. Na základě poznání kognitivních funkcí je možné lépe porozumět tvorbě i interpretaci modelů. Model, chápán jako obraz reality, který je vytvořený s určitým cílem, je součástí mnoha oborů – od stavitelství, přes technické vědy, biologii, sociologii a psychologii, ekonomii až k umění. Především v uměleckém světě je pojem model posunut do jiné roviny, než v ostatních oborech – model zde představuje podobu reality, vzor, se kterým je pracováno. Vytvořený model může sloužit k formulaci hypotéz a jejich uchování, nebo pro prezentaci představ, reality, pocitů. Model slouží tvůrci jako reflexe, ale také k přenosu informací a sdělení poznatků ostatním lidem. Model je explicitním vyjádřením našich představ, našeho vidění reality a světa kolem nás. Jsou v něm zachyceny takové aspekty reality, které považujeme za účelné, významné, důležité pro zaznamenání v modelu. Po vytvoření modelu se model sám stává součástí reality. Tato skutečnost je celkem zřejmá např. z oblasti architektury. Model Petřínské rozhledny je modelem skutečného objektu, ale zároveň sám o sobě tvoří součást reality – je to samostatný systém. Model informačního systému také dokumentuje informační systém, jeho vazby, vztahy na okolí. Ale zároveň existence modelu, např. v elektronické podobě v konkrétním nástroji, je novým systémem, byť do určité míry abstraktním. Model by měl být chápán a akcentován v dvojí roli – jako obraz reality a zároveň jako realita sama. Pojmu model je věnována podrobně podkapitola 2.2 – Model.

2.1.5 Organizace a její informační systém 2.1.5.1 Organizace

Synonyma pro pojem organizace jsou podnik, firma, útvar. (SEVOCAB, 2013)11 uvádí následující definice pojmu organizace: 1) osoba nebo skupina lidí a vybavení s uspořádáním odpovědností, oprávnění a vztahů; 2) sestava lidí a procesů k tvorbě určitého výstupu (produktu nebo služby); 3) firma, společnost, vláda, nezisková nebo jiná účelově vytvořená organizace, včetně asociací, klubů, společenství, vládních agentur, soukromých firem, výhradních prodejců, které mají své funkce a administrativu. V kontextu vymezených hranic zkoumání v této disertační práci se jedná o organizaci odpovídající druhé definici z publikace SEVOCAB, v soukromém sektoru, jejíž hlavním předmětem podnikání je vývoj a dodávka informačních systémů (někdy je tento typ organizace označován pojmem dodavatel IT).

11

Vyhledáno dle hesla „organization“.

30 | 146

Anna Exnarová

„Komplexní pojetí hospodářské organizace vychází z vnímání organizace jako otevřeného systému, a to s výraznými vlastnostmi sociálního (měkkého) systému.“ (Mildeová, 2007, str. 10) Organizace je zástupcem kategorie komplexních, měkkých, sociálních (dle Bouldingovy taxonomie) systémů. Systémy lidských aktivit (dle Checklanda) jsou významnou složkou, která výrazně ovlivňuje strukturu tohoto systému a jeho chování. Dle Vodáčka (1997) jsou základní komponenty organizace (viz Obr. 6): • manažerské procesy, • struktura, • strategie, • technologie, • lidé a role. Uvedené komponenty systému mezi sebou vytvářejí důležité vazby, které mají dopad na vlastnosti celého systému. Mimo vlastností těchto komponent je systém (organizace) tvořen dalšími vlastnostmi, které synergicky vznikly na základě existence jednotlivých komponent, jejich vzájemných vazeb, a také díky existenci vazeb na okolí (obdobně jako bylo diskutováno v kapitole 2.1.3).

Obr. 6 Komponenty organizace a jejich vztahy (Vodáček, 1997, str. 39)

Principy systémového myšlení nás vedou k prozkoumání organizace jako systému s definovanou hierarchickou strukturou. Jedna z velmi významných hierarchií organizace je organizační. Tedy pohled na tento systém z pohledu jeho částí (lidí), kteří jsou seskupeni a organizováni v určitých jednotkách tohoto systému. Vzhledem k hierarchickému uspořádání je pozice managementu určující. Diskutované vlastnosti měkkých systémů, a snaha mnoha autorů o jejich uchopení, není bez příčiny. Domnívám se, že byť se ke konci dvacátého století začalo mluvit o globální společnosti a byly uváděny mnohé příklady toho, jak se společnost změnila a jaké jsou její důsledky, nebyly tyto úvahy plně konzistentní s pohledem na svět ze strany systémových přístupů. Častá argumentace propojení trhů v mezinárodním měřítku, jejich vzájemné ovlivňování a nastolení globálních pravidel spolupráce, byla často posuzována pouze z kontextu předchozí doby rozdělení Evropy a světa na uzavřené oblasti. Pokud se ale podíváme do historie, tak v období první republiky byla společnost

31 | 146

Anna Exnarová

celosvětově propojena, existovaly komunikační i obchodní toky, které dnes vnímáme jako globální. Např. se dovážely suroviny z kontinentů na kontinent, komunikovalo se mezikulturně, bylo požadováno rychlé jednání a přizpůsobení se trhu. Rozdíl je v rychlosti – výrobní proces se zkrátil, dodací lhůty jsou mnohonásobně rychlejší, komunikace se stala de facto online záležitostí, u které nedochází k významným zpožděním. Proč nastalo odcizení od toho, co kdysi fungovalo a nepřinášelo zásadní problémy? Nebo problémy byly ale vzhledem k historickému posunu, zkreslení, představy „kdysi bejvávalo líp“ se nám zdají menší? Domnívám se, že v případech, kdy se zemědělec staral o svou půdu, dokázal se přizpůsobovat chování na trhu, měnícím se povětrnostním podmínkám, rozuměl perfektně systému – tomu co pěstuje, co potřebuje ta daná půda, jak zacházet se změnami, které nastanou, existovala tu lidová moudrost, znalosti a zkušenosti děděné a přenášené, podrobná znalost řemesla, které navíc často bylo obohaceno o znalosti, které učedník získal „na zkušené ve světě“ – toto vše umožňovalo poměrně efektivní přístup k řešení problémů. Pravděpodobně v tomto období společnost často vykazovala prvky chování systému, který splňuje podmínky systémových přístupů. Urychlení, odtržení od podstaty věci, zvětšení počtu parametrů, které vstupují do řešení, jsou poměrně zásadní v tom, že člověk přestal pohlížet systémově. Rozvoj hlavně v dvacátém století v souvislosti s rozvojem počítačů a analytického myšlení, podle mě měl za cíl stav, kdy lidé začali od systémového přístupu mířit k analytickému. Pokoušejí se problém rozdělit, vydělit a analyzovat, ne systémové zkoumat. V literatuře se někdy lze setkat s tvrzením, že toto analytické myšlení nastoupilo již v průběhu 17. století. Domnívám se, že při překladech a výkladech dochází k omylu. I Isaac Newton musel přemýšlet systémově a bez jeho pohledu by nikdy nebyl schopen vymyslet to, co vymyslel. Pokud se podíváme na příklad zemědělce v současném světě, jeho problém je opravdu složitý. V případě, že nemá dostatečné znalosti a technické prostředky, jeho snahy o vyrovnání se s konkurencí a úspěšnou adaptací na změny jsou při řešení problémů často neúspěšné. Důsledkem nepřizpůsobení se technickému pokroku neznamená nic jiného, než že dochází k velké izolovanosti od zdrojů problémů, od vidění problémů v kontextu celého systému. Organizace je objektem zkoumání. Organizaci tvoří seskupení lidí, které je spojováno jak formálními a právními náležitostmi, tak společným cílem (který nemusí být nutně formálně definován). Důležitá je realizace vzájemné kooperace za účelem dosažení cíle, k dosažení tohoto cíle je přistoupeno k dělbě práce a specializaci členů, kteří ale vzájemně musí kooperovat a spolupracovat. V práci je pozornost věnována organizaci, jejíž předmět zájmu je vývoj informačních systémů. Dále v textu je pojmem organizace označován tzv. Dodavatel IT služeb.

32 | 146

Anna Exnarová

2.1.5.2 Informační systém a IASW Informační systém

Cílem existence informačního systému (IS) je umožnit práci s daty – potažmo vytváření, zpracování, ukládání a přenos dat a informací. „Pojmem informační systém budeme rozumět účelové uspořádání vztahů mezi lidmi, datovými zdroji a procedurami jejich zpracování, a to včetně technologických prostředků. Toto uspořádání zajišťuje sběr, přenos, uchování, transformaci, aktualizaci a poskytování dat pro jejich informační využití lidmi. Pokud jde o počítačově podporované IS, pak jejich součástí je i disponibilní hardwarové a softwarové vybavení.“ (Vodáček, 1997, str. 87) Tato definice je relevantní s dalšími následně uváděnými. „Informační systém je takový systém, kde se vazby mezi prvky systému a vazby s okolím (vstupy a výstupy systému) realizují předáváním dat a informací.“(Doucek, 2004, str. 11) Doucek ve své práci pod pojmem firemní informační systém rozumí takový systém, který pro svou práci využívá informační a komunikační technologie. V souladu s Voříškem (2008) jsou součástí tohoto pojmu chápány moderní technologie ve smyslu výpočetní techniky, infrastruktur a aplikačního vybavení. Nicméně z obecného pohledu je pojem informační systém chápán i nadále jako systém pro práci s daty. Velký vývoj obsahu této kategorie není ve způsobu práce s daty a principielním základem, základní procesy s daty jsou stále stejné, tj. vytváření, přenášení, uchovávání, vyhledávání. Díky technologickému pokroku se výrazně mění právě technologie, které umožňují tyto procesy s daty realizovat. Pro potřeby této práce je pojem IS chápán totožně jako uvádí Doucek a Voříšek ve výše diskutovaných publikacích. Dle Vodáčka (1997, str. 88) je IS „vytvářen třemi složkami. První je založena na formalizované práci s informacemi prostřednictvím IT, druhá je vytvořena formálně organizačně-správním způsobem a třetí neformální komponenta zahrnuje formálně nevymezené informační toky a především znalosti jednotlivých pracovníků.“ Dle Voříška (2008), je informační systém souborem informačních a komunikačních technologií, dat a lidí, jehož cílem je efektivní podpora informačních, rozhodovacích a řídících procesů na všech úrovních řízení organizace. Tato definice uvádí do souvislosti cíl a existenci informačního systému. Z pohledu teorie systémů jde tedy pravděpodobně o pojetí systému ve smyslu účelově definované struktury. Pojem informační systém je možné dále zpřesňovat, často se jedná o konkretizaci technologií, které umožňují práci s daty. Pro tyto technologie byl definován samostatný pojem – informační a komunikační technologie (ICT). ICT je soubor hardwarových (HW) a softwarových (SW) nástrojů, které v informačním systému zabezpečují po technologické stránce informační a komunikační procesy. Na tyto procesy je možné pohlížet jako na dvě skupiny: • procesy týkající se dat, tj. činnosti od vytváření, přes sběr, zpracování, vyhledávání, až po ukládání a archivaci dat; • procesy komunikační, tedy umožnění práce s informacemi, jejich výměnu a sdílení, tedy část zaměřenou na práci s daty v kontextu lidské složky informačního systému.

33 | 146

Anna Exnarová

Individuální aplikační software (IASW)

Části informačního systému, které jsou zpracovávány za pomocí technologických prostředků, které realizují sadu instrukcí, jsou programy (počítačové programy). Pro souhrnné označení všech počítačových programů v informačním systému se používá pojem software. Software je možné rozdělit do dvou základních kategorií – systémový (vlastní funkce počítače) a aplikační. Aplikační software (také aplikace) je programové vybavení, které umožňuje realizaci konkrétní funkcionality nejčastěji za účasti uživatele. V publikaci (SEVOCAB, 2013) 12 lze nalézt následující definice pojmu aplikační software, které jsou v souladu s výše uvedenou charakteristikou: 1) software navržený tak, aby pomohl uživatelům provádět určité činnosti nebo řešit určité typy problémů, na rozdíl od softwaru, který řídí samotný počítač; 2) software nebo program specifický pro řešení problému; 3) software navržený ke splnění specifických potřeb uživatele. Aplikace mohou existovat izolovaně, nicméně ve většině organizací formují složitý systém vzájemně propojených aplikací, provázaný na datové, aplikační a i na uživatelské úrovni, tvořící významnou součást informačního systému organizace. Tato integrace v mnohých případech není pouze v rámci jednoho informačního systému, ale často přesahuje hranici podniku (např. IS finančních institucí mohou být integrovány na národní registry obyvatel). Pro vznik nové komponenty informačního systému v oblasti aplikací je možno v principu využít dvou přístupů. Na trhu může již existovat software, který pokrývá požadovanou funkcionalitu. Organizace se tedy rozhodne o jeho implementaci do svého informačního systému ve smyslu nastavení požadovaných parametrů. V tomto případě se jedná o tzv. typový aplikační software (TASW, krabicový systém). V případě, že software je vyvíjen pro konkrétní potřeby konkrétního zákazníka, přesně respektuje jeho požadavky a vychází z funkční analýzy a analýzy potřeb zákazníka, hovoříme o individuálním aplikačním software, neboli software na zakázku (IASW).13 V další části práce je pozornost věnována pouze IASW, pro tuto kategorii je používáno označení IASW, příp. software (např. v kontextu životního cyklu vývoje softwaru, kde toto spojení je zaužívaným spojením). V praktické části disertační práce je z důvodu převzetí firemní dokumentace a terminologie konkrétního praktického příkladu využíváno označení aplikace. Jelikož IASW je podmnožinou pojmu software, jsou výroky a hodnocení, které jsou uvedené pro pojem software či aplikace, platné rovněž pro IASW.

Vývoj informačního systému

Vývoj a nasazení informačního systému v organizaci a jeho následné udržování je rozsáhlý a velmi náročný proces. Z pohledu procesů se většinou rozděluje do několika 12 13

Pro vyhledání pojmu bylo použito heslo „application software“. Dělení na IASW a TASW viz např. (Brucker, 2012).

34 | 146

Anna Exnarová

dílčích navazujících a souvisejících projektů, jejichž cílem je realizace určité vybrané části informačního systému (neboli realizace vybraných etap a fází). V případě velkých informačních systémů bývají vyvíjeny a nasazovány dílčí celky (software) v rámci dílčích projektů. Problematika vývoje informačního systému je složitou a obsahově velmi náročnou oblastí. Ve vztahu k cílům práce považuji za vhodné uvést základní kategorie této problematiky, které oblast mého výzkumu zasazují do širšího kontextu. Pro stručnou charakteristiku vývoje informačního systému jsem zvolila metodiku MMDIS (Multidimensional Management and Development of Information System). MMDIS je metodikou katedry informačních technologií Vysoké školy ekonomické v Praze, jejímž cílem je „vývoj, údržba a provoz komplexního a integrovaného informačního systému podniku, který optimálně využívá potenciálu dostupných informačních technologií a informatických služeb k maximální podpoře podnikových cílů.“ (Voříšek, 2008, str. 129) Tato metodika obsahuje návrh tří skupin pohledů jak je možné na informační systém nahlížet (následující tři odstavce jsou převzaty z (Voříšek, 2008, str. 132)). První skupina obsahuje dva pohledy: • Uživatelský pohled „odpovídá na otázku, komu je informační systému určen a jaké ICT služby bude nabízet jednotlivým skupinám uživatelů.“. • Řešitelský pohled definuje způsob, jakým bude systém realizován a jak bude provozován. Druhá skupina pohledů „reprezentuje použité úrovně abstrakce a časovou dimenzi řešení. Tato skupina dimenzí se v MMDIS promítá do jednotlivých fází vývoje a provozu informačního systému . Jednotlivé projekty realizované na základě informační strategie potom procházejí životním cyklem projektu, který se skládá z fází: úvodní studie, globální analýza a návrh, detailní analýza a návrh, implementace, zavádění, provoz, údržba a vyřazení.“ Uvedené fáze jsou schématicky dokumentované na převzatém Obr. 7 Fáze vývoje IS podle MMDIS (upraveno z (Voříšek, 2008, str. 132)).

Obr. 7 Fáze vývoje IS podle MMDIS (upraveno z (Voříšek, 2008, str. 132))

35 | 146

Anna Exnarová

Třetí skupinu tvoří obsahové dimenze IS/ICT: • informační/datová, • procesní/funkční, • ekonomická/finanční, • organizační/legislativní, • pracovní/sociální/etická, • uživatelský interface,

• • • • • •

bezpečnost a kvalita, softwarová, hardwarová, metodická, dokumentační, manažerská.

Uvedené pohledy a dimenze dle MMDIS dokumentují složitost a komplexnost projektu, kterým nasazení a následné udržování informačního systému v organizaci je. Dimenze a pohledy na informační systém a jeho vývoj se transformují do vybraných pohledů a dimenzí jeho částí (komponent), a jsou tedy propojeny i s dále diskutovaným vývojem softwaru.

Pro doplnění souvisejících pojmů se zmíním o již uvedeném pojmu projekt. Projektem informačního systému je dle Doucka (2004) rozuměna cílevědomá, plánovaná, řízená, časově ohraničená skupina činností, která má dané vstupy a výstupy. Na projekt lze nahlížet z různých úhlů – Doucek (2004) tyto pohledy nazývá dimenze a rozděluje je na obchodní, technologickou a procesní. Domnívám se, že aspekty, kterým je nutné v projektu věnovat pozornost, je možno oproti uvedeným dimenzím rozšířit – např. v maximální šíři dle metodiky MMDIS a jejím obsahovým dimenzím. V případě, že v rámci projektu není vyvíjen celý informační systém, ale pouze jednotlivé IASW, lze hovořit o projektu vývoje IASW. Model životního cyklu IASW

Na vývoj IASW je možné pohlížet obdobně jako na vývoj informačního systému, pro tuto práci považuji za relevantní následující aspekty: • obchodní (legislativní rámec, smluvní podmínky, finanční náležitosti), • technologické (nástroje a technologie používané v průběhu projektu), • procesní (např. projektové řízení, metodika vývoje), • sociální (komunikace, interpersonální vztahy, charakteristiky členů), • informační (sdílení informací, znalostní management, mentální modely), • organizační (struktura týmů na straně dodavatele i zadavatele, pravidla komunikace). Tento uvedený seznam dimenzí je dále diskutován v kapitole 4.2 Uplatnění systémového myšlení v analytické fázi vývoje IASW prostřednictvím modelů.

Metodika MMDIS uvádí sadu fází životního cyklu aplikace (v terminologii této práce IASW): úvodní studie, globální analýza a návrh, detailní analýza a návrh, implementace, zavedení, provoz a údržba, vyřazení (fáze byly uvedeny na Obr. 7 Fáze vývoje IS podle MMDIS (upraveno z (Voříšek, 2008, str. 132))). Buchalcevová (2009, str. 16) konstatuje, že „životní cyklus softwaru je časový úsek, který začíná úmyslem

36 | 146

Anna Exnarová

vytvořit software a končí, když se software přestane používat.“ Model životního cyklu „představují rámec realizace procesů životního cyklu v časové posloupnosti.“ (Buchalcevová, 2009, str. 47) Modely životního cyklu softwaru se věnují popisu a časové následnosti jednotlivých fází či etap, které v procesu vývoje softwaru je nutné realizovat. V Tab. 2 jsou uvedeny hlavní silné a slabé stránky vybraného modelu životního cyklu IASW – iterativního modelu (v terminologii Buchalcevové se jedná o model životního cyklu softwaru). Jedna a ta samá vlastnost může být z pohledu zákazníka vnímána pozitivně, kdežto z pohledu dodavatele produktu se jedná o slabinu. Zároveň podle typu projektu a dle specifických podmínek konkrétní situace se objevují další vlastnosti, které je nutno akcentovat. Tab. 2 Silné a slabé stránky iterativního modelu životního cyklu IASW (upraveno dle (Buchalcevová, 2009))

Model

Silné stránky

Slabé stránky

Iterativní (evoluční)

Častá zpětná vazba od zákazníka

Špatná představa o rozsahu celého řešení

Specifikace požadavků na začátku každé iterace – možnost realizovat změny

Obtížně realizovatelné u projektu s pevnou cenou

Časná a častá integrace

Vysoké nároky na dostupnost Přírůstková spotřeba personálních zákazníka zdrojů Instalace a akceptace jednotlivých verzí může být nákladná

Popis jednotlivých fází a jejich vazeb modeluje následující diagram Obr. 8 Iterativní model životního cyklu softwaru (Buchalcevová, 2009, str. 53).

Obr. 8 Iterativní model životního cyklu softwaru (Buchalcevová, 2009, str. 53)

37 | 146

Anna Exnarová

Vymezení hranic zkoumání vůči agilnímu vývoji

V několika posledních letech jsou prosazovány metodiky založené na agilním vývoji, proto považuji za vhodné uvést stručný komentář k této problematice. Agilní metodiky jsou založeny na iterativním či inkrementálním vývoji, umožňují rychlý vývoj a základním principem je předání výsledného produktu zákazníkovi v co možná v nejkratším čase, přičemž dodávka je dělena do malých částí. Tyto přístupy umožňují reagovat na dynamické změny zadání v průběhu vývoje, jsou zaměřeny na rychlost a efektivnost. Nicméně jsou poměrně významně odlišné od klasického přístupu k vývoji, a proto vyžadují příslušné znalosti všech členů týmu na straně dodavatele i zákazníka. V publikaci (Schwaber, 2012) je uváděno, že agilní přístup k vývoji softwaru je skoro 3-krát úspěšnější než vodopádový přístup. Tento fakt nicméně je potřebné dát do souvislosti s předpoklady, za kterých je možné agilní přístup pro vývoj softwaru uplatnit. Ve výše uvedené studii jsou diskutovány tři hlavní kategorie, které ovlivňují výrazně úspěch projektu: požadavky, technologie a lidé. Buchalcevová (2009) ve své publikaci dokumentuje vybrané metodiky i modely životního cyklu vývoje softwaru, včetně jejich hodnocení dle vybraných kritérií. V souladu s uvedeným výzkumem, s dalšími publikacemi dle vlastností agilních metodik je ale nutné konstatovat, že agilní přístup není možné využít pro 100% projektů. Důvody jsou obsaženy v již zmíněných kategoriích, které ovlivňují projekt. Možnost nasazení agilních metodik je ovlivněna lidmi (jak ze strany vývojového týmu, tak ze strany zákazníka). Obě tyto skupiny musí mít znalosti, dovednosti a kompetence pro tento typ vývoje. Rovněž organizační a procesní struktury organizací i vlastního projektu musí respektovat odlišnosti, které agilní vývoj přináší. V projektu musí být k dispozici technologie, na kterých je vývoj postaven a požadavky musí svým charakterem i rozsahem odpovídat možnostem agilního vývoje. Buchalcevová v uvedené publikaci uvádí, že nejvýznamnější důvody odmítnutí agilních metodik jsou v právních důvodech, odmítnutí přístupu zákazníky, omezená použitelnost pro rozsáhlé projekty a menší pozornost věnovaná návrhu předem (Buchalcevová, 2009, str. 84). Domnívám se, že tyto důvody vedou v praxi k tomu, že v mnoha organizacích přetrvávají různé modifikace vodopádového, potažmo iterativního vývoje; případně dochází ve vybraných fázích vývoje k určité kombinaci s agilním přístupem. Rovněž Buchalcevová (2009, str. 81) uvádí, že „v české praxi se zatím agilní metodiky nedočkaly většího rozšíření.“ Důsledkem uvedených skutečnosti je propojení navrhovaného rozšíření vývoje softwaru s klasickým přístupem.

Modely životního cyklu softwaru popisují následnost dílčích etap či činností. Metodiky udávají soubor těchto postupů, ale také soubor pravidel, nástrojů, specifických postupů a doporučení, které je v průběhu životního cyklu možné používat. Rámec pro metodiku vývoje IASW, který je používán v kapitole 4.2 Uplatnění systémového myšlení v analytické fázi vývoje IASW prostřednictvím modelů, tvoří metodika Unified Process.

38 | 146

Anna Exnarová

Metodika Unified Process

Proces vývoje softwaru je popsán mnoha různými metodikami, které se liší charakterem, komplexností, způsobem jakým k projektu přistupují, cíli, které definují. Mezi ty nejznámější lze zařadit Unified Process (resp. komerční rozšíření RUP od firmy IBM, či variantu OpenUP), metodiku Select Perspective, SCRUM nebo extrémní programování. V české literatuře podává Buchalcevová (2009) podrobný a metodicky korektní popis základních metodik a jejich hodnocení. Jednou z nejznámějších metodik vývoje softwaru je metodika Unified Process (UP). Je založena na iterativním a přírůstkovém procesu, přičemž každá iterace obsahuje všechny prvky softwarového projektu (Arlow, 2007): • plánování, • analýzu a návrh, • tvorbu, • integraci a testování, • interní nebo externí uvedení. V každé iteraci existuje pět základních pracovních postupů (nazývaných též disciplín), jež určují, co je potřeba udělat, a způsob, jakým toho dosáhnout. Kromě pěti základních postupů obsahuje každá iterace ještě další pracovní postupy, jako jsou plánování, odhad a vše, co je pro danou iteraci specifické. Základními postupy jsou: • požadavky – zachycují to, co by měl systém dělat; • analýza – vybroušení požadavků a jejich strukturování; • návrh – realizace požadavků v architektuře systému; • implementace – tvorba softwaru; • testování – ověření, zda implementace funguje tak, jak se od ní očekává. Metodika UP se skládá ze čtyř po sobě jdoucích fází, z nichž každá končí hlavním milníkem: • Zahájení (inception) – období plánování, • Rozpracování (elaboration) – období architektury, • Konstrukce (contruction) – počátky provozuschopnosti, • Zavedení (transition) – nasazení produktu do uživatelského prostředí. Obr. 9 Fáze a disciplíny UP (Buchalcevová, 2009, str. 122) dokumentuje vztah fází, disciplín a iterací, které metodika UP podrobně definuje. V kontextu této práce je potřebné na tomto místě zmínit pojem analytická fáze vývoje IASW, který v této práci je používán. Analytickou fází vývoje IASW je označení spojení dvou disciplín „Sběr požadavků“ a „Analýzy a návrh“z metodiky UP.

39 | 146

Anna Exnarová

Obr. 9 Fáze a disciplíny UP (Buchalcevová, 2009, str. 122)

Pro návrh uvedený v kapitole 4.2 Uplatnění systémového myšlení v analytické fázi vývoje IASW prostřednictvím modelů byla použita právě metodika Unified Process (UP).

Lze konstatovat, že problematika vývoje informačních systémů, potažmo vývoje IASW, vykazuje všechny aspekty (komplexnost, měkké prvky, dynamické změny na základě změn organizace i okolí, zahrnutí sociálních aspektů, množství prvků a jejich vzájemných, často skrytých, vazeb), které opodstatňují a směřují k aplikaci systémových přístupů, potažmo systémového myšlení a systémové dynamiky14. Domnívám se, že v propojení systémových věd, především systémového myšlení a systémové dynamiky a oblasti vývoje a provozu informačních systémů je velký potenciál.

14

Pojem systémová dynamika a další související pojmy jsou diskutovány v kapitole3 Systémové myšlení.

40 | 146

Anna Exnarová

2.2 Model Modelování je soubor činností, které vedou k vyjádření různých pohledů na vybraný systém standardizovanými, příp. formalizovanými prostředky. Z obecného pohledu Křemen (2007) říká, že model je ve své podstatě jazykovým útvarem, který slouží jako komunikace-schopný záznam rozpracovanosti. Tedy dokumentuje to, co bylo vytvořeno a co se očekává, že vytvořeno bude. Model chápu jako obraz reality, který je vytvořený s určitým cílem. Tvorba modelů v analytické fázi (a následně samozřejmě jejich tvorba i využití v dalších fázích vývoje) je běžnou součástí praxe. Tvorba modelů je také jednou z nejdiskutovanějších činností ve fázi analýzy – velkou měrou k tomu přispěly specifikace modelovacích jazyků i provázání modelů s metodikami. Nutno podotknout, že pojem model a diagram nejsou jednotně chápány ani napříč vědní oblastí informatiky. Např. (Buchalcevová, 2009, str. 188) uvádí pojem model jako „dílčí pohled na vytvářený systém, diagram naplněný daty.“ Z pohledu nástrojů, ve kterých jsou modely realizovány, model představuje abstraktní pohled na systém, přičemž různé diagramy poskytují určitou podobu navrhovaného systému. V této práci pojmem diagram rozumím grafický model, grafickou reprezentaci, na rozdíl od modelu, který nemusí mít automaticky grafickou podobu, ale může být vyjádřen například textově. Model nemusí (ale může) být soubor diagramů. Řepa ve své práci komentuje obtíže, které souvisí s modelováním procesů. „Oblast modelování podnikových procesů je, díky šíři záběru, relativní čerstvosti problematiky, silnému ovlivnění technologií a dalším situačním a dobovým charakteristikám, i z hlediska standardů poněkud nepřehlednou. Přirozená nedostatečnost standardizace oblasti a z toho plynoucí problémy, jež se musí řešit, vyvolávají tlak na vznik kdejakých návrhů, aspirujících na de facto standardy nejrůznější kvality a šíře záběru, což působí značné obtíže s jejich vzájemnou srovnatelností, klasifikací, apod.“ (Řepa, 2007, str. 123) Domnívám se, že to co Řepa uvádí pro modely podnikových procesů, lze konstatovat i obecně o modelech informačních systémů, a to vzhledem k tomu, že procesy organizace jsou jednou z dimenzí informačního systému (viz diskutované obsahové dimenze informačního systému dle metodiky MMDIS uvedené v kapitole 2) Důvody, proč model informačního systému vzniká, stanovuje významně jeho charakteristiky a ovlivňuje jak celý životní cyklus modelu, tak i činnosti, které jsou ve vztahu k modelu i celému IS vykonávány. Důvody existence modelů lze vybrat z následující množiny: (Exnarová, 2008) • Požadavek na přehled o stavu vývoje. • Komunikace jak uvnitř týmu, tak vzhledem k zákazníkovi. • Požadovaná součást dokumentace systému. • Hierarchické uspořádání systému a jeho částí. • Možnost simulace. • Tvorba prototypů, automatizace tvorby výstupů, realizace. • Odstínění od nepodstatných charakteristik v dané fázi návrhu.

41 | 146

Anna Exnarová

Model informačního systému bývá nejčastěji používán k: (Exnarová, 2011) • formulaci hypotéz a jejich uchování, • zachycení reality s definovanými charakteristikami, • prezentaci představ (budoucí stav vs. realita), • dokumentaci současného stavu, • zachycení změn v systému.

2.2.1 Životní cyklus modelů

Na svět nahlížíme přes naše mentální modely, které jsou velice individuální, obsahují ze své podstaty chyby a samostatně použité poskytují nevyhovující výsledky při řešení složitých problémů. Systémové myšlení pomáhá měnit mentální modely. Představuje soubor metod, přístupů, modelů, které po úspěšném zvládnutí poskytují velkou výhodu – schopnost lépe řešit problémy, přizpůsobovat se změnám okolí a chápat podstatu světa. Systémové myšlení je uměním a vědou o tom, jak formulovat spolehlivé závěry o chování systému, a to na základě hlubokého pochopení jeho struktury. Lidské mentální modely jsou komplexní a multidimensionální směsicí obrazů a zkušeností, a poměrně důsledně odrážejí osvojený způsob myšlení. Od dětství máme naučené postupy rozdělit problém na menší části a řešit samostatné fragmenty. Je to postup, který nám zdánlivě „ulehčí“ řešení složitých úloh. Daň, kterou za to musíme platit, je nemožnost vidět důsledky a ztráta smyslu pro souvislosti s větším celkem. Pokud chceme vidět celý obraz, musíme se pokusit znovu poskládat jednotlivé kousky do celku včetně jejich souvislostí. (Senge, 1995). Jedna z cest, jak odstranit přirozené hranice mentálních modelů je tvorba a používání formalizovaných modelů. Tento proces (životní cyklus modelu) lze shrnout do sedmi základních kroků. 1. Vyjasnění, k čemu model bude používán, jaký je cíl jeho existence. 2. Analýza reálné situace (z pohledu systému i z pohledu dostupných nástrojů, znalostí tvůrců, schopností budoucích uživatelů). 3. Tvorba / výběr metodiky modelu – jazykové prostředky, nástroje a metodiky. 4. Sběr informací, které jsou nezbytné pro vytvoření modelu (v druhém kroku byla provedena analýza, na základě které byla zvolena metodika – díky ní se lze vrátit zpět a získat všechny potřebné informace). 5. Tvorba samotného modelu. 6. Využívání modelu uživateli. 7. Aktualizace modelu (příp. odstranění). Klíčovým bodem je krok 1 – definování cíle existence modelu je nesmírně důležité proto, aby bylo možné zvolit správný typ modelu, konkrétní postup jeho tvorby a celý jeho životní cyklus (s ohledem na náklady a přínosy, které samozřejmě každý model provází). Existence modelu může být definována velmi odlišně.

42 | 146

Anna Exnarová

Obdobně uvádí Mildeová (2006, str. 19) faktory, které při vytváření modelu, tedy zjednodušení reality, je nutné akcentovat: • účel modelu, • hranice modelu, • zpětné vazby, které se v modelu vyskytují, • časový horizont pro použití modelu, • zahrnutí neracionálního chování subjektů, • zahrnutí nedokonalé informovanosti prvků, zpoždění, chyb, • robustnost modelu, • schopnost úpravy modelu v případě změny podmínek, • dokumentace modelu, • vztah k simulaci, optimalizaci. Model je explicitním vyjádřením našich představ, zachycuje vybrané aspekty systému. Je reflexí reálných situací nebo představ. Obecně lze říci, že model může sloužit k: • formulaci hypotéz, • záznamu vybraných charakteristik reality, • dokumentaci současného stavu, • zachycení změn v systému, • simulaci chování systému. Každý krok životního cyklu modelu by měl být ovlivněn odpověďmi na otázky: • Proč model vzniká – jaký je důvod jeho existence. • Jaký systém zobrazuje, jakou realitu představuje. • Kdo ho vytváří, s jakými nástroji a znalostmi. • Kdo ho bude používat, s jakými nástroji a znalostmi. • Jak často se bude aktualizovat, jaká je periodicita změn a jejich objem. Na základě těchto otázek (potažmo odpovědní) a aplikací systémového myšlení byly navrženy dvě skupiny modelů: modely standardizované a modely nestandardizované (jejich charakteristiky jsou uvedeny v následujících podkapitolách). Rozdělení modelů do těchto dvou velkých skupin považuji za významné. V podnikové praxi jsou obě tyto skupiny nezastupitelné, i když především ve firmách více technicky orientovaných se setkáváme s podceňováním skupiny nestandardizovaných modelů. Přínosy tohoto dělení modelů jsou: • Zdůraznění (často opomíjené) existence nestandardizovaných modelů. • Definování charakteristiky jasně deklarující vlastnosti modelu – zvolením konkrétního typu modelu musíme akceptovat jeho vlastnosti. Díky jasné definici by nemělo docházet k rozčarování při implementaci daného typu modelu v reálné situaci. • Poskytnutí pomoci při rozhodování o výběru konkrétního typu modelu v prvních krocích životního cyklu modelu. • Existující klasifikace s deklarovanými vlastnostmi pro práci s modely a analýzu dané oblasti, které by při celistvém pohledu bez kategorizace nemusely být identifikovány. 43 | 146

Anna Exnarová

2.2.2 Modely informačních systémů

Základem úspěchu je vždy dobrý plán. Pro vývoj informačního systému je potřebné mít plán toho, jaké činnosti se budou realizovat i plán toho, co se vyvíjí. Každý informační systém má svého uživatele, zákazníka a investora. S každou skupinou je potřebné umět komunikovat a sdělit jí relevantní informace. Vývoj je málokdy „one-man-show“. V drtivé většině se jedná o vývoj v týmu, kde komunikace a sdílení znalostí je klíčové. A projekt vývoje je vždy něčím omezen (lidskými zdroji, financemi, časem, lokalizací). Potřeba kvalitních návrhů a pokrytí výše uvedených potřeb byla motivující pro vznik modelovacích technik určených pro vývoj aplikací. „Modelování je vyjádření různých pohledů na systém (předem vymezený a definovaný) standardizovanými, resp. formalizovanými výrazovými prostředky (modelovacím jazykem).“ (Svoboda, 2008) V procesu tvorby modelu se sám model stává realitou – je jedním z objektů reálného světa. Tato dualita má také odraz v oblasti modelování IS: model dokumentuje reálný svět (např. informační systém), jeho existence tvoří součást reálného světa (např. v podobě aplikace, dokumentace), ale také může být primární součástí tohoto světa, který realitu utváří. Primárním modelem, se kterým běžně pracujeme, je mentální model. Nicméně jeho vlastnosti (např. Mildeová (2006)) determinují rozsah jeho použití. Je základem pro lidské myšlení, ale v realitě bývá často doplněn (nahrazen) vytvořeným modelem (ať již počítačově nebo ručně zpracovaným). Základní zúžení pojmu model, které je zavedeno v tomto textu, je podoba modelu jako vizuální reprezentace reality. V disertační práci aplikovaný přístup přitom reflektuje variabilitu typů modelů i různorodost účelu jejich tvorby a současně respektuje skutečnost, že model je vždy zjednodušením reality. (Mildeová, 2006) Tvorba modelů v průběhu vývoje softwaru je v dnešní praxi součástí běžných činností. Propracovanost modelovacích technik, metodik a modelovacích nástrojů umožňuje vytvářet složité modely informačních systémů a dokumentovat složitou realitu. I u malých projektů (viz např. odpovědi na otázku č. 6 výzkumu autora Beneše (2002)) je běžně uvažována tvorba modelů IS a použití modelovacího nástroje – ať již se jedná o konceptuální modely na logické úrovni, nebo o propracované modely určené přímo pro generování zdrojového kódu. Odborná veřejnost i praxe věnovala rozvoji modelů a modelování informačních systémů velkou pozornost (např. (Exnar (2009), Larman (2002), OMG (2009)). Přibližně před dvaceti lety docházelo k rozvoji objektového programování v propojení s metodami modelování, které dříve byly využívány především v oblasti analýzy. Jedním z velkých přínosů pro rozvoj těchto konceptů byly aktivity odborných skupin, které se vývojem softwaru zabývaly, a modelování bylo jednou z klíčových oblastí, které věnovaly pozornost (jmenujme například velkou skupinu OMG nebo odborné skupiny v rámci velkých softwarových společností). V roce 1995 bylo v rámci vývoje softwarových produktů použito pouze zlomek modelovacích nástrojů, v roce 2006 společnost Gartner odhadovala, že více než 10 miliónů IT profesionálů používá UML, do roku 2008 již toto číslo vzrostlo na více než 70% organizací, které se vývojem softwaru zabývají (Watson, 2010).

44 | 146

Anna Exnarová

V současné době především mnoho praktiků považuje otázku modelování za uspokojivě vyřešenou (jak ve smyslu výběru modelů, dostupnosti modelovacích technik, tak i kvality metodik, které vymezují jejich aplikaci v reálném projektu). Diskuse o modelování nicméně v odborné literatuře neustále probíhají. Po stanovení základních pravidel modelování, přichází etapa, kdy se pokoušíme ověřit a relevantně ohodnotit přínosy jednotlivých modelů a modelovacích technik (viz studie věnované hodnocení úspěšnosti a použitelnosti modelů (Riedermann (2009), Dobing (2006), Cao (2009) jejichž výsledky jsou uvedeny v závěru kapitoly 2.2.4).

2.2.3 Vlastnosti modelů z pohledu standardizace

Modely je možné rozdělit z pohledu standardizace na (Exnarová, 2009): • standardizované modely; • nestandardizované modely. Vytvoření těchto kategorií má význam jak pro teorii, ale také pro praxi. Pro tvorbu a používání modelů je nutné akcentovat všechny vlastnosti modelů, které jsou níže v kapitole diskutovány, ale také zvláštnosti, které přináší tyto dvě kategorie. I když běžně jsou diskutovány a vyučovány pouze standardizované modely (např. UML), u kterých jsou jasné jejich formální náležitosti a pravidla použití. Nicméně v praxi jsou často používané i modely nestandardizované – typickým příkladem je model architektury systému. Tento typ modelů je tvořen bez jakýchkoliv omezení a záleží pouze na tvůrci, jaké prostředky pro tento model využije. I když používání standardizovaných modelů je běžné, domnívám se, že je nutno připomínat jejich základní vlastnosti (byť se na první pohled zdají samozřejmé). Mnohé problémy praxe, kdy standardizovaný model nesplní očekávání, jsou spojeny právě s nízkou akceptací vlastností těchto modelů a tedy i limity, které tyto modely mají. Domnívám se, že skupina nestandardizovaných modelů má dominantní význam především v souvislosti s dvěma klíčovými skupinami: manažery a zákazníkem. Na základě navržené klasifikace je možné tuto kategorii modelů uchopit a akcentovat ty charakteristiky, které mají přímý dopad na vnímání těchto modelů klíčovými skupinami uživatelů. Což znamená „pečovat“ o manažera i zákazníka ve smyslu vytváření přesně cílených customizovaných výstupů. V souvislosti s výzkumným záměrem s disertační práce je členění na standardizované a nestandardizované modely významné pro pochopení možností a současně limitů představeného autorského návrhu. Tato kategorizace byla publikována také v (Exnarová, 2010).

45 | 146

Anna Exnarová

Standardizované modely Standardizované modely jsou modely, které mají definovanou notaci, která je vyvíjena v dlouhém období za spoluúčasti významných organizací a institucí a jejichž použití se významně rozšířilo do praxe. O těchto modelech lze říci, že jsou obecně „well-known“ – velmi dobře známé. Velkou výhodou je jejich obecné použití – díky obecné znalosti je model srozumitelný v širokém okruhu tvůrců i uživatelů (většinou z okruhu IT). Metodika je většinou oddělená od modelu (např. UML metodiku nemá, ale často bývá spojován např. s metodikou UP). Mezi standardizované modely můžeme řadit celou škálu modelů – od samozřejmě přijímaných modelů UML (Unified Modeling Language), DFD (data flow diagram), BPMN (business process modeling notation), E-R diagramy (entity-relation diagram), až ke modelům systémového myšlení nebo systémové dynamiky. Všechny tyto modely mají svojí notaci vizualizace informací, a pomocí všech těchto modelů můžeme modelovat určitou část či vybrané charakteristiky systému. Standardizované modely mají více či méně specifikovaný účel existence – např. model rybí páteře je určen pro zobrazení příčin a následků. Definování účelu je spojeno s vymezením části reality, která je modelována. Ve většině případů není vhodné u standardizovaných modelů měnit jejich primární účel nebo realitu, kterou by měly zobrazovat. Tvůrcem a zároveň příjemcem většiny standardizovaných modelů jsou odborníci (v případě modelů informačních systémů jsou to analytici, architekti, designéři i programátoři). Na tvůrce i uživatele ale kladou požadavek na znalost jazykové struktury a schopnost aplikovat tuto obecnou znalost na konkrétní situaci. Všeobecně známá standardizovaná jazyková struktura modelu je poměrně dobrým předpokladem pro jeho obecné používání. K rozšířenosti modelů ve velké míře přispívá také podpora softwarových nástrojů, které umožňují daný typ modelů vytvářet, nebo dokonce podpořit celý životní cyklus modelu. Pokud se jedná o komerční nástroje, jsou většinou na vysoké úrovni propracovanosti a obsahují velké množství dalších funkcionalit (např. automatické generování dokumentace, generování kódu, verzování, podpora fáze designu a programování, atd.). Je vhodné si uvědomit, že většina modelů je tvořena pomocí softwarových nástrojů, které do velké míry diktují a upravují charakteristiky vytvářených modelů a definují vlastní metodiku použití modelu v konkrétních krocích návrhu. Proto v mnohých případech musí vznikat vedle obecných metodik také detailní metodické postupy – tyto detailní postupy obsahují navíc aplikaci obecných modelovacích postupů v daném nástroji ve vazbě na konkrétní situaci a modelovaný systém. Tak se i v běžné praxi setkáváme s přechodem od obecných standardizovaných modelů k instanci konkrétního modelu a někdy až k vytvoření individuálních nestandardizovaných modelů. V některých případech je ale situace opačná – nástroj omezuje v modelování reality a výsledný model je „ochuzený“ o informace, které by dle metodiky standardizovaného modelu měly být obsaženy. S touto situací se musí vyrovnat jak tvůrce, tak uživatel, a je velmi podstatné si tento rozdíl uvědomit.

46 | 146

Anna Exnarová

S rostoucí oblibou a možnostmi modelovacích jazyků roste samozřejmě i jejich rozsáhlost a komplexnost i komplikovanost. Tvorba a práce s těmito modely se tak stává odbornou záležitostí. Požadavkem na tvůrce je znalost a schopnost skloubení jak obecné metodiky, tak možností modelovacího nástroje a konkrétních vlastností IS. Výše uvedené a komentované charakteristiky standardizovaných modelů jsou schematicky uvedeny na Obr. 10.

Obr. 10 Atributy standardizovaných modelů

Nestandardizované modely Praxe často přináší složité situace, ve kterých je model možným způsobem řešení – např. zákazníkovi je potřebné představit budovaný informační systém a zdůraznit vybrané charakteristiky, kterých si musí být vědom. Klíčovým bodem je volba správné formy komunikace složitých a rozsáhlých informací. Vizualizace informací formou modelů bývá jednou z obecně rozšířených variant. Účelem nestandardizovaných modelů je poskytnout možnost, jak sdělit informace specifickou formou v konkrétní situaci s přesně cílenou vizualizací pro daného zákazníka. Většina nestandardizovaných modelů je tvořena s cílem rychlého a jednoduchého sdělení informací. Nestandardizované modely nemají definované obecné jazykové výrazové prostředky, nejsou univerzálně použitelné, jejich tvůrci musí postavit celou strukturu modelu a liší se případ od případu. V praxi se pro tyto modely někdy užívá označení „fun diagramy“ nebo „manažerské modely“. Základní charakteristiky nestandardizovaných modelů uvádí Obr. 11Atributy nestandardizovaných modelů. Tyto modely jsou naproti výše uvedeným standardizovaným modelům určeny především pro uživatele, kteří nemají potřebný technický a metodický základ znalostí. Mohou být proto určeny širšímu okruhu příjemců, nebo příjemcům s odlišnou bází znalostí a zkušeností (např. zákazníkovi, manažerům, účetním). Znázorněné informace modelovaného systému na druhou stranu nemohou mít stejnou míru detailu jako standardizované modely. Jejich výhoda je v jednoduchém a přehledném zobrazení informací. Na uživatele neklade skoro žádné nároky. Tyto modely jsou většinou používané pro zákazníka ze skupiny „ne IT“, pro manažerské rozhodování, nebo pro rychlou orientaci v systému.

47 | 146

Anna Exnarová

Naproti tomu pro tvůrce je tvorba poměrně složitou záležitostí – neexistuje konkrétní jazyk ani metodika, kterou by bylo možno použít. (Samozřejmě, že tyto modely mohou být tvořeny na základě již existujících standardizovaných modelů, nicméně jejich výsledná podoba a použití je natolik rozdílné, že již nelze mluvit o instanci daného modelu.) Všechny takto vytvořené modely se musí vytvářet na míru uživateli a systému. Tvůrce většinou vychází z již existujícího standardizovaného jazyka, který je ale výrazně upravován a na základě kterého je vytvářen nový jazyk. Tento proces bývá do značné míry ovlivněn konvencemi, které jsou ve firmě zaužívané, ale také schopností a kreativitou tvůrce. Proces stabilizace nového jazyka je poměrně dlouhý a je také výrazně ovlivněn nástrojem, který je pro daný model vybrán, a který staví mantinely jak v definici jazyka, tak v metodice. Výběr softwarového nástroje pro modelování omezuje a určuje základní modelovací prvky jazyka, které tvůrce musí definovat a určit jejich význam a použití v nově tvořeném modelu. Nástroj většinou musí splňovat požadavky na grafickou úpravu a výsledný design, proto je ve většině případů nutné volit nástroje typu MS Visio, kde lze skloubit základní nástroje pro tvorbu diagramů, nicméně lze je v široké paletě nástrojů graficky modifikovat. Při tvorbě těchto modelů můžeme používat celou řadu SW nástrojů, které jsou určené přímo pro tvorbu různých typů standardizovaných modelů. Pokud se jedná o komerční nástroje, jsou většinou na vysoké úrovni propracovanosti a obsahují velké množství dalších funkcionalit. Jednou z nich je možnost generování dokumentace (žádný model není úplný bez dokumentace). V případě tvorby nestandardizovaných modelů v nástrojích typu MS Visio, nebo dokonce grafických nástrojích, je tvorba modelu rozdílná – nástroje umožňují vytvořit dokonalejší grafickou stránku modelu (což pro nestandardizované modely je jedno z hlavních kritérií), nicméně neobsahují žádné další nadstavby a v případě dokumentace je nutno tvořit ji ručně. V současné době jsou však již i běžné nástroje pro tvorbu modelů natolik propracované, že grafické výstupy z těchto nástrojů začínají být plně dostačující. Aktuálnost modelu je jedním z hlavních požadavků, který na již vytvořený model, mají uživatelé. Snadnost aktualizace dat je do velké míry ovlivněna opět výběrem konkrétního nástroje. Lze konstatovat, že i v tomto případě standardní modelovací nástroje poskytují propracovanější možnosti správy a aktualizace jednotlivých elementů (správa elementů v rámci centrálního úložiště a následné využívání těchto elementů v různých diagramech snižuje náročnost aktualizace). Nestandardizované modely obsahují méně informací, ale většina těchto informací by z nich měla být velmi lehce zjistitelná (obvykle na první pohled). Díky této vlastnosti jsou nestandardizované modely velmi lehce převoditelné do podoby obrázků (u standardních modelů se z pouhého obrázku v porovnání s modelem dozvíme pouze velmi omezený okruh informací). Výše uvedené charakteristiky nestandardizovaných modelů jsou schematicky uvedeny na následujícím obrázku.

48 | 146

Anna Exnarová

Již z výše uvedeného vyplývá, že na uživatele modelu jsou kladeny poměrně menší nároky z pohledu znalostí oproti standardizovaným modelům. Nicméně pro tvůrce tento typ modelu přináší i odlišné požadavky na znalosti a dovednosti: • ovládání daného software (pro sofistikované modely je nutno znát i pokročilé funkce, příp. znalost odborného nástroje pro grafiku), • schopnost grafického cítění a kreativity při strukturovaném zobrazení reality a tvorbě vlastního modelovacího jazyka a metodiky, • dodržení obecně používaných výrazových prostředků, s důrazem na přesnost a přehlednost, ale i grafickou nápaditost, • nalezení odpovídajících vztahů realita – model (často bez opory např. v již vytvořených obecných vzorech).

Obr. 11Atributy nestandardizovaných modelů

Tvůrce nestandardizovaných modelů má daleko větší možnosti uplatnit při tvorbě modelů vlastní kreativitu a cit. Dle mého názoru a zkušenosti z praxe se domnívám, že v mnoha případech grafický návrh nestandardizovaných modelů (např. popis architektur systémů nebo koncepce řešení) bývá problematický. Nápomocným bývají firemní grafické manuály a pravidla. Pokud takovéto pravidla chybějí, může se z nestandardizovaného modelu stát opravdový „fun“ model, který je plný barev a ikon, ale pro uživatele je vysoce nepoužitelný a nesrozumitelný. Navržená klasifikace umožňuje analyzovat vlastnosti jednotlivých skupin odděleně a upozornit tak na charakteristiky, které by ze sumarizovaného pohledu byly zastíněny nebo neakcentovány. Zaměření se na určitou specifickou část odděleně pomáhá v rozboru této oblasti, v definování základních rysů, vysvětlení a objasnění skutečností. Z praktického hlediska lze navrženou klasifikaci, charakteristiky i ukazatele využít v analytických činnostech i v rámci řízení projektů, a to pro rozhodování a hodnocení modelovacích aktivit. Kromě informatické praxe bude možné navržený koncept aplikovat i v procesu výuky, kdy jednoznačně zafixované a klasifikované souvislosti, členění a charakteristiky jednotlivých skupin pomohou v jednoznačném začlenění, vysvětlení a ukotvení pojmů týkajících se modelování.

49 | 146

Anna Exnarová

2.2.4 Modely vytvářené v analytické fázi vývoje IASW

Oblast procesů a modelování procesů organizace je doménou také mnoha dalších oborů. V české literatuře je tato oblast kvalitně dokumentována v publikaci Řepy (2007), kde jsou uvedeny vybrané hlavní přístupy k modelování procesů organizace, jejich uchopení v kontextu reengineringu. Tato oblast se domnívám je velmi dobře prozkoumána jak v oblasti teoretické a vědecké, tak v oblasti praktického využití, kde existuje řada úspěšných a prakticky ověřených metodik a standardů. V mnoha případech jsou tyto systémy dostačující, ale zároveň se domnívám, že je mnoho případů, kdy výsledky nejsou optimální. Především v kapitole 3.2 jsou diskutovány hlavní důvody, které jsou příčinnou neúspěšného řešení problémů. Domnívám se, že jednou z možností, jak tyto problémy řešit, je uplatnění systémového myšlení v praxi. Toto uplatnění je samozřejmě možno realizovat rozličným způsobem. Například je možné zvolit cestu vzdělávání s cílem schopnosti aplikovat systémové myšlení při využívání stávajících postupů a přístupů, tedy využití systémového myšlení v procesu návrhu informačního systému, s předpokladem použití např. kombinace modelů UML a BPMN (Business proces modeling notation, notace pro modelování procesů). Mnou navrhovaný přístup předpokládá dostatečnou znalost UML modelů. Tyto modely doporučuji doplnit o „procesní“ a zároveň systémový pohled na řešenou problematiku pomocí modelů systémového myšlení (resp. systémové dynamiky). Tvorba těchto modelů stejně tak jako schopnost systémového myšlení vyžadují vzdělání, nicméně aktivní používání modelů systémového myšlení přímo vede k jejich aplikaci a tedy k efektivnějšímu uchopení problematiky.

Modely notace UML (Unified Modeling Language)

Výrazný rozvoj a posun v modelovacích technikách provázel rozvoj objektově orientovaného návrhu i programování. Většina modelovacích technik vychází z modelů, které byly v druhé polovině dvacátého století navrhovány autory Grady Booch, Jim Rumbaugh, nebo Ivar Jacobson, UML se objevilo jako vedlejším produktem objektověorientovaného designu a stalo se velmi rozšířeným nástrojem pro jeho modelování. UML (Unified Modeling Language, unifikovaný modelovací jazyk) je univerzálním jazykem pro vizuální modelování systémů. Základy tohoto jazyka jsou postaveny na nejlepších existujících postupech modelovacích technik a softwarového inženýrství. Je přímo navržen tak, aby byl jednoduše implementovatelný do různých CASE nástrojů (computer aided software engineering). Sám o sobě nenabízí žádnou metodiku modelování, poskytuje pouze syntaxi, kterou lze při sestavování modelů využít. Metodik modelování, využívajících jazyk UML, je více, mezi nejznámější patří Unified Proces (UP) a Object-oriented Process, Environment and Notation (OPEN). (Arlow, 2007) Rovněž jazyk UML není vázán na žádnou specifickou metodiku vývoje životního cyklu softwaru či informačního systémů. Lze je možné kombinovat se všemi typy, nicméně přirozeně z vlastní podstaty i v praxi ověřené zkušenosti je často používán UML společně s variantami metodiky Unified Process.

50 | 146

Anna Exnarová

UML poskytuje více pohledů na systém, ale s malou podporou aspektů chování a simulace. Vznik UML 2.0, mělo tuto mezeru vyplnit, ale studie indikují, že se tyto očekávání nenaplnila. A nenaplnily je ani další jazyky, např. SimML nebo Rational Rose TauGeneration 2. (Tignor, 2004) (Chang, 2005) ve své publikaci uvádí, že UML je používáno softwarovými inženýry jako standardní prostředek komunikace zahrnující jednotlivé typy diagramů. Rovněž jeho přístup je založen na objektově orientovaném vývoji informačního systému. UML je použitelné k ujasnění jaké softwarové objekty jsou potřebné, tj. jaké proměnné, metody, události by měly mít, a jak by měly být organizovány aby se max. výkon, flexibilita a udržovatelnost. (Tignor, 2003) Modely vytvořené pomocí notace UML poskytují pohled na systém v různých úrovních detailu. Některé z nich popisují systém na vyšší, více abstraktní úrovni. Jiné zase představují detailní úroveň popisu systému. UML modely obsahují elementy jako např. aktéři, případy užití, třídy, balíčky, a také jeden nebo více diagramů, které ukazují specifický pohled na systém. Model může rovněž obsahovat jiné, více detailní modely. Je možné použít modelování diagramů pro zachycení případů užití systému během fáze sběru požadavků, lze definovat domény aplikace do analytického modelu ve fázi analýzy systému, a je možné upřesnit model aplikace v designu modelu při podrobném fáze návrhu. Model je možné použít jako: • vizuální představu o systému, který je vytvářen, • nástroj komunikace představ o systému pro ostatní členy týmu; • nástroj pro rozvoj a testování architektury systému; • nástroj, který umožňuje generování kódu. Struktura jazyka UML obsahuje tři části: stavební bloky (tj. prvky, relace a diagramy modelu), společné mechanismy (obecné způsoby pro dosažení specifických cílů) a architekturu (architektura navrhovaného systému pomocí UML). Jazyk (stavební bloky) UML se skládá ze tří stavebních bloků (dle (Arlow, 2007)): • předmětů: o podstatná jména vyjadřují strukturní abstrakce, o slovesa vyjadřují chování, o balíček seskupuje významově související předměty; • relací propojujících jednotlivé předměty; • diagramů znázorňujících zajímavé pohledy na model. Architektura systému, který je modelovaný pomocí UML, je založena na tzv. 4+1 pohledu (Arlow, 2007). Každá úrovně pohledu se zaměřuje na jinou část systému • Logický pohled se zaměřuje na funkce systému a slovník. • Pohled procesů demonstruje výkon systému, škálovatelnost a propustnost. • Pohled implementace je zaměření pozornosti na montáž systému a správu konfigurace. • Pohled nasazení popisuje topologii systému, distribuci, doručení a instalaci. • Všechny pohledy mají být sjednoceny v pohledu případ užití, který deklaruje požadavky uživatele. 51 | 146

Anna Exnarová

Hlavním důvodem vzniku UML byl požadavek na vznik jednotného výrazového prostředku pro vizualizaci systému za použití objektově orientovaného přístupu. „Jazyk UML byl navržen proto, aby spojil nejlepší existující postupy modelovacích technik a softwarového inženýrství. Jako takový je explicitně navržen takovým způsobem, aby jej mohly implementovat všechny nástroje CASE. Zmíněná koncepce vychází z pochopení skutečnosti, že se rozsáhlé softwarové systémy obvykle bez podpory nástrojů CASE neobejdou. Diagramy vytvořené v jazyku UML jsou srozumitelné pro lidi, ale navíc je mohou snadno interpretovat i programy CASE.“ (Arlow, 2007, str. 28) S příchodem stále složitějších systémů se stal tento vizuální a propracovaný jazyk důležitou součástí vývoje aplikací. Použití UML je v současné době natolik rozšířené, že jeho použitím se výrazně zvýší okruh příjemců modelu. Model se stává použitelnějším v širším spektru. A díky neustálému rozvoji UML se okruh použitelnosti rozšiřuje. Tomuto přístupu vysoce nahrává UML a jeho implementace společně s metodikou UP. Standard UML se skládá z těchto částí (OMG GROUP. UML® Resource Page [online]. 1997, 2013 [cit. 2013-01-28]. Dostupné z: http://www.uml.org/): • UML 2.0 SuperStructure – popis UML z hlediska uživatele. Tato část popisuje jednotlivé diagramy. • UML 2.0 Infrastructure – metamodel stojící v pozadí za UML, specifikovaný pomocí Meta-Object Facility (MOF). • UML 2.0 Object Constraint Language (OCL) – jazyk pro specifikaci vstupních a výstupních podmínek, invariantů v jednotlivých diagramech. • UML 2.0 Diagram Interchange – popis XML struktur pro výměnu konkrétních modelů mezi jednotlivými modelovacími nástroji.

Obr. 12 Struktura UML

Jazyk UML se neustále vyvíjí, doplňují se možnosti podrobnějšího modelování, nebo dochází k jeho rozšíření na základě specifických potřeb. Obr. 13 – typy diagramů UML (upraveno z (Arlow, 2007, str. 37) demonstruje úplný výčet diagramů specifikace UML2.

52 | 146

Anna Exnarová

Obr. 13 – typy diagramů UML (upraveno z (Arlow, 2007, str. 37))

Rozsah diagramů UML má velmi velký záběr. V praxi často dochází k používání pouze základní sady. Dále uvedu pouze stručnou charakteristiku nejpoužívanější základní sady diagramů. Diagramy struktur: • Diagram tříd (class diagram): Popisuje statickou strukturu systému, datové položky a operace objektů systému, jakož i vztahy mezi objekty. Je používán od konceptuální až po implementační úroveň, kde lze použít pro generování kódu. • Komponentový diagram (component diagram): Ukazuje, jak jsou jednotlivé části systému spojeny dohromady, a tvoří pak větší komponenty a celé systémy. • Composite structure diagram: Ukazuje vnitřní strukturu třídy a spolupráce, které tato struktura umožňuje, jak obsažené části systému podporují chování celku. • Diagram nasazení (deployment diagram): Modeluje fyzické umístění částí systému na propojených uzlech infrastruktury. • Diagram balíčků (package diagram): Ukazuje závislosti mezi balíčky (packages), které tvoří model. • Diagram objektů (object diagram): Ukazuje kompletní nebo částečný pohled na strukturu modelovaného systému v určitý čas. Diagramy chování: • Diagram aktivit (Activity diagram): Ukazuje tok řízení a dat. Typicky se používá na modelování workflow, funkčních procesů, obrazovek, algoritmů. • Diagram případů užití (Use case diagram): Vizualizuje vztahy mezi aktéry a případy užití systému, které jsou vizualizací funkčních požadavků na systém. • Stavový diagram (State diagram): Modeluje stavy objektu v systému a přechody mezi stavy. Diagramy interakce: • Sekvenční diagram (Sequence diagram): Ukazuje na časové ose posloupnost zasílání zpráv mezi objekty systému. • Diagram komunikace (Communication diagram): Modeluje vzájemné působení mezi částmi systému ve smyslu podsloupnosti zpráv mezi těmito částmi. 53 | 146

Anna Exnarová

•

•

Interaction overview diagram: Zobrazuje přehled interakcí a aktivit v systému a používá se jako zjednodušení obzvláště u složitých scénářů, které v detailu představují složitý model aktivit nebo posloupností kroků. Diagram časování (Timing diagram): Používá se ke zkoumání chování systému (typicky změnám stavu) v určité periodě času.

Chang (2005) uvádí přehled jednotlivých UML diagramů a možnosti jejich aplikace ve vztahu k perspektivě systému – úhlu pohledu, jak je systém zkoumán. Perspektivy odrážejí fáze vývoje z metodiky UP, přičemž první tři jsou zahnuty v analytické fázi. Tab. 3 Perspektivy systému a jejich UML diagramy (Chang, 2005, str. 5)

Perspektiva systému

UML diagram

Aplikace

Použití

Diagram případů užití

Akce uživatelů, analytiků, systémových inženýrů pro použití systému

Návrh

Diagram tříd Diagram objektů

Návrh funkcí nebo služeb

Procesy

Sekvenční diagram Diagram spolupráce Diagram stavů Diagram aktivit

Popis procesů systému

Nasazení

Diagram komponent

Zobrazení komponent nebo součástí systému

Implementace

Diagram nasazení

Dokumentace síťové infrastruktury nebo hardwarových prvků pro nasazení systému

Důvody, proč je UML tolik populární, mohou být tyto: • UML je de facto standardem v oboru informačních technologií, který je obecně používaným. • Je udržován a zaštiťován velkou skupinou OMG, která se rovněž stará o jeho rozvoj. • Existuje široká základna vývojářů a informatiků se znalostí UML. UML se stalo komunikační platformou, která díky tomu, že se jedná o vizualizační jazyk, odbourává částečně i jazykové bariéry. UML pomáhá pochopit problematiku také ne-informatikům – základy jsou jasné, jednoduché a účelné. • Jednoduchost a v některých bodech až názornost UML umožňuje soustředění se na obsah (za předpokladu základní znalosti UML, příp. modelovacího nástroje, jinak snaha o správnou formu převažuje nad obsahem a z výhody se stává nevýhoda).

54 | 146

Anna Exnarová

Výhody použití je možno nalézt také v definovaných primárních cílech pro UML (převzato z (Dorsey, 2004)): • UML poskytuje uživatelům „ready-to-use“ vizuální jazyk, který umožňuje vyvíjet a měnit význam a podstatu modelů. • Umožňuje rozšiřitelnost a poskytuje speciální mechanizmy na rozšíření základních pojmů. • Je nezávislý na konkrétním programovacím jazyce a vývojovém procesu. • Poskytuje formální základ pro pochopení modelovacího jazyka. • Podporuje rozvoj objektově orientovaných nástrojů. • Podporuje rozvoje koncepcí jako je spolupráce, rámce, vzory, komponenty. • Integruje best practices. Velkou nevýhodou je velice rozsáhlá detailní specifikace. Nevýhodu UML lze spatřovat také v přílišných očekáváních. Projektu, lidem a organizacím jejich problémy nevyřeší UML, je potřeba kvalitní metodiky, procesní řízení a orientaci na potřeby. UML může pomoci, ale někdy je nutno UML rozšířit, příp. opustit. Další nevýhodou, kterou uvádí (Dorsey, 2004), je skutečnost, že UML stále poměrně obtížně pracuje s propojením času v diagramech (z pohledu životního cyklu jednotlivých entit, „time-related classes“). K rozsahu, ve kterém je UML používán, výrazně přispívají také softwarové nástroje, které UML podporují a rozšiřují. Vzhledem k tomu, že UML je pouze technikou bez konkrétní metodiky, spektrum použití je poměrně široké a i dva obdobné projekty za použití odlišných nástrojů mohou mít výrazně odlišné modely. Sofistikovanější modelovací nástroje rovněž nabízí svoje vlastní metodiky – podrobněji výhody a nevýhody standardizovaných modelů byly diskutované v (Exnarová, 2009). V časopisech IEEE Software a ACM Community byly publikovány tři výzkumy ((Riedemann, 2009), (Dobing, 2006), (CAO, 2009)), které se zabývaly hodnocením úspěšnosti a použitelnosti vybraných modelů v procesu návrhu informačních systémů. Autoři Riedemann, Dobin a Cao se ve svých výzkumech zaměřili především na hodnocení modelů UML, příp. porovnání s jejich alternativami. Charakteristiky hodnocené a zkoumané v těchto výzkumech mohou tvořit soubor ukazatelů vhodných pro hodnocení modelů.

V publikaci (Riedemann, 2009) se autorky věnovaly studii, ve které zkoumaly jak lze modelovat a pracovat se znalostmi v procesu tvorby IS (především ve fázi analýzy) – vybraly si tři hlavní techniky (případy užití (use case), user story a scénář problémů), které vzájemně porovnávaly. Studie se věnuje otázce použitelnosti modelů a technickým prostředkům, které daný typ modelů podporují. V této studii se autorky nevěnují pouze vizuálním typům modelů, ale jsou zde uvedeny i modely textové. Velká pozornost se v této práci věnuje jejich silným a slabým stránkám. Každá technika má jinou úroveň abstrakce a zaměření na potřeby uživatele, chování systému, dokumentaci, změny požadavků a testování požadavků.

55 | 146

Anna Exnarová

Publikace (Dobing, 2006) představuje studii, která zjišťovala preference v používání základních UML diagramů. Autoři výzkumu na základě literární rešerše vybrali 7 základních diagramů, které následně zkoumali. Na základě výzkumu sestavili dle procenta využívanosti pořadí jednotlivých typů diagramů: • diagram tříd – „class diagram“; • diagram použití – „use case diagram“; • sekvenční diagram – „sequence diagram“; • diagram případů užití ve formě vyprávění – „use case narrative“; • diagram aktivit – „activity diagram“; • stavový diagram – „statechart diagram“; • diagram spolupráce – „collaboration diagram“. Závěry této studie lze shrnout takto: • Použití UML diagramů se značně liší: diagramy tříd, sekvenční diagramy a diagramy případů užití jsou používány nejčastěji. • Použití diagramů tříd podstatně překračuje používání diagramů případů užití. • Analytici a programátoři se většinou spoléhají na diagramy tříd a sekvenční diagramy. Používají také diagramy případů užití, což může naznačovat potenciální problémy s komunikací, na které se ale praxe tolik nezaměřuje. • Případy užití nedokážou zachytit všechny požadavky. • Diagramy tříd, sekvenční diagramy a stavové diagramy poskytují další přidané informace nad rámec případů užití. • Složitost UML je poměrně velká, o čemž svědčí množství programů, které se snaží pomoci IS profesionálům a jejím klientům jazyk naučit a efektivně využívat. Vzhledem k zaměření UML, bývají modely tvořeny v notaci UML v praxi běžně doplňovány vybranou notací pro modelování procesů. UML bývá běžně doplňováno vybranou notací pro modelování procesů. V návrhu uvedeném v kapitole 4.2 je použito spojení UML a modelů systémového myšlení a systémové dynamiky.

Metodiky určují hlavní body a kroky vývoje IS. Vztah modelů a jednotlivých fází vývoje IASW v obecné rovině je popsán pouze omezeně, většina publikací se zaměřuje na jeden konkrétní modelovací jazyk nebo přístup. Jako příklad lze uvést publikace zaměřené na konkrétní modelovací jazyky: (Larman, 2002), (Arlow, 2007), (Page, 2001), (Riedemann, 2009), (Řepa, 2007), (Dijkman, 2008), (Dobing, 2006) nebo publikace, které se snaží najít nové způsoby modelování (Grossmann, 2008), (Zhang, 2008). Díky rozšířenosti, obecné znalosti, propracované definici je možné vázat tyto modely na obecně definovaný postup vývoje. To, že se jedná o standardizované modely, koresponduje i s jejich vlastnostmi. Vazba obecných metodik vývoje s nestandardizovanými modely je účelová činnost, spojená s konkrétní situací v konkrétním vývojovém procesu (tyto úvahy byly publikovány v (Exnarová, 2009) a jsou jedním z východisek pro klasifikaci modelů začleněnou do disertační práce).

56 | 146

Anna Exnarová

Další typy modelů vývoje IASW v analytické fázi

Vedle UML je v praxi rozšířena velká skupina standardizovaných modelů, které jsou orientované více na vizualizaci procesních náležitostí podniku i informatiky. Mezi obecné základy, ze kterých mnoho dalších reprezentací vychází, je jazyk BPMN. Stručná charakteristika konceptu dle Řepy: „BPMN (business process modeling notation) je standardem pro grafickou reprezentaci firemních procesů v diagramech, jeho doplňkem je BPMNL (business process modeling language), jazyk pro modelování a popis procesů, vycházející z XML (Extendible Markup Language). Autorem BPMN/BPML je konsorcium Business Process Management, sdružení firem z oblastí vývoje informačních systémů. Vyvíjené standardy tak odráží požadavky a zkušenosti předních osobností oblasti modelování firemních procesů. Je svým způsobem reakcí na problematickou schopnost společnosti OMG vyrovnat se v jazyku UML s problematikou modelování podnikových procesů, BPMN/BPML je tak do jisté míry standardem konkurenčním UML v této oblasti.“ (Řepa, 2007, str. 125) Textem, věnujícím se procesnímu modelování a základním charakteristikám a porovnání jednotlivých modelovacích technik je publikace (Svatá, 2009). V současné praxi se lze setkat s dalšími modely procesů. Jednou skupinou je výběr modelů UML. Dále jsou to modely např. BPEL, data flow diagramy (DFD). Výběr konkrétních typů modelů procesů se, rovněž jako u UML, odvíjí mimo jiného od modelovacího nástroje a jeho možností. Modelování procesů je samostatnou, většinou částečně oddělenou, oblastí vývoje informačních systémů. Jejich rozšíření do oblasti dynamizace je pouze částečně prozkoumané, ukazuje se, že v tomto směru zde existuje také velký potenciál výzkumu. Nicméně tato oblast přesahuje vymezené hranice této práce, je pouze doporučením pro další rozvoj. Modelování procesů je v práci dále věnována pozornost z trochu jiného pohledu. Dle Capry je „systémové myšlení vždy myšlením o procesech.“ (Capra, 2004, str. 51). Následující kapitoly se věnují systémovému myšlení a pohledu na procesy organizace očima systémového myšlení a systémové dynamiky.

57 | 146

Anna Exnarová

3 SYSTÉMOVÉ MYŠLENÍ A SYSTÉMOVÁ DYNAMIKA Kapitola 3 Systémové myšlení a Systémová dynamika dokumentuje výsledky zkoumání související s pojmem systémové myšlení. První část kapitoly je věnována diskusi pojmu informace a znalosti. Tyto pojmy jsou klíčové z pohledu modelování, které je ve své podstatě především o uchovávání dat, sdělování informací a vytváření znalostí. Jsou diskutovány různé pohledy na znalosti a informace a vztaženy k organizaci. Další část kapitoly je věnována systémovému myšlení. Od systémového přístupu (který částečně již byl diskutován v předcházející kapitole) je pozornost zaměřena na systémové myšlení. Systémové myšlení je představeno diskusí vybraných klíčových charakteristik. Pro možnost aplikace systémového myšlení jsou uvedeny jeho základní dovednosti, které jsou použité v dalších kapitolách práce. Dále je pozornost zaměřena na nástroje systémového myšlení – konkrétně jeho modely. Systémová dynamika je vědní obor, který se systémovým myšlením má poměrně velký průnik. Další část kapitoly představuje systémovou dynamiku a především její model. Informace uvedené v této kapitole jsou stěžejním podkladem pro následující kapitolu. 3.1 Informace a znalosti v organizaci „Porozumět informaci a pak rozvíjet potřebné schopnosti (informační kompetenci) s ní pracovat patří k stěžejním nárokům, které informační společnost na podnikatele a manažery klade.“ (Vodáček, 1997, str. 12) 3.1.1 Koncept data, informace, znalosti

Dle Vodáčka (1997) nebo Rosického (2005) je informaci možné chápat jako data, kterým člověk přisuzuje význam. Přisouzení významu je spojeno s mentálním procesem příjemce, v rámci kterého informace musí zpracovat v kontextu svých znalostí. Informace uspokojují subjektivní informační potřebu jedince. Pro uspokojení konkrétní informační potřeby musí manažer účelově shromažďovat a následně vybírat vhodná data, ze kterých za pomocí svých znalostí dokáže čerpat informace. Ty se následně můžou stát dalším rozšířením jeho znalostí. Informace je sama výsledkem myšlenkových procesů, ale zároveň je také iniciátorem dalšího tvořivého myšlení. Data jsou nositelem informace. Znalosti jsou výsledkem aktivního kognitivního procesu příjemce. V souladu s výše uvedeným vymezením Buchalcevová (2009, str. 184) konkretizuje nositele informace takto: data jsou „jakékoli fyzické (materiálně) zaznamenané znalosti (vědomosti), poznatky, zkušenosti nebo výsledky pozorování procesů, projevů, činností a prvků reálného světa.“ Brucker (2012, str. 183) k tomuto pojetí doplňuje, že „informace dávají datům jejich význam a u příjemce snižují entropii (neurčitost).“

58 | 146

Anna Exnarová

Na informaci je možné nahlížet ze tří úrovní: (upraveno z (Vodáček, 1997, str. 62)) • z pohledu syntaxe jako na uspořádání vztahů mezi znaky, • z pohledu sémantiky reprezentuje vztahy znaku k objektu, který tento znak reprezentuje, tento pohled není přímo závislý na příjemci, • z pohledu pragmatiky odpovídá na otázku jakou mírou je příjemce informace schopen tuto informaci také využít.

Obr. 14 Transformace informace (upraveno z (Vodáček, 1997, str. 63))

Syntaxe je v procesu transformace ta část, která popisuje reprezentaci signálů a znaků pomocí vybraných symbolů (viz Obr. 14). Sémantické aspekty jazykové komunikace se zaměřují na obsahový význam sdělení. Tedy obsah sdělení, to co příjemce chápe sdělovanými signály (znaky, sekvencemi znaků). Pragmatické aspekty jsou výsledky aktivity lidského vědomí, příjemce dává do souvislosti informaci se svými znalostmi, sdílenými hodnotami a záměry. 3.1.2 Znalosti v organizaci

Konkurenční výhoda organizací nespočívá pouze ve vlastnictví dat. „Informace jsou data, obohacená o relevantnost a účelnost, přeměna dat v informace tudíž vyžaduje znalosti.“ (Drucker, 1995, str. 191) Pro uplatnění konkurenční výhody je nezbytnou podmínkou také schopnost organizace s daty kvalitně pracovat, schopnost interpretace dat do informací a transformace do znalostí zaměstnanců. K tomuto účelu jsou v organizacích implementovány nástroje tzv. knowledge managementu. Označovány bývají jako informační zdroje, nicméně z pohledu teorie se jedná o zdroje dat. Znalosti, na rozdíl od informace, jsou interním vlastnictvím každého člověka. Transformace informace do znalosti je procesem, ve kterém dochází k vytvoření nových či pozměnění stávajících vazeb mezi nově začleňovanou informací do již existující struktury znalostí. Tato transformace je složitou množinou mentálních aktivit, mezi které můžeme řadit (upraveno z (Molnár, 2012, str. 26), (Vodáček, 1997, str. 13)): • Srovnávání: porovnání informace s již existující strukturou znalostí. • Spojování: vytvoření nových nebo úprava stávajících vazeb mezi objekty, které reprezentují informaci a původní strukturu znalostí. • Hodnocení: vyhodnocení, zda informace má dopad na změnu struktury znalostí. • Zapomínání: výmaz objektů či vazeb ze struktury znalostí. • Komunikování: sdílení informace mezi lidmi (přímá i nepřímá forma komunikace).

59 | 146

Anna Exnarová

Zapomínání je neregulovatelný proces, který ale významně ovlivňuje strukturu znalostí. Tento proces je důvodem toho, že ve firmách je nutné budovat znalostní báze a efektivně sdílet informace. Tyto nástroje samozřejmě slouží jako prostředek pro distribuci nových informací. Nicméně ve většině případů ve firmě lidé vědí, že informace existuje, ale ve svých znalostech přišli o nějakou její část (vazbu na okolí, detaily objektu). Proces zapomínání odstranil některé charakteristiky objektu v struktuře znalostí. Proto je potřebné, aby tyto nástroje byly přizpůsobeny nejen pro získávání nových informací, ale také umožňovali efektivně vyhledávat a doplňovat existující struktury znalostí zaměstnanců novými informacemi. Znalosti poskytují kompetence k práci s informacemi, v organizaci umožňují efektivní vyhledávání potřebných datových zdrojů a jejich používání. Uvedené aktivity přirozeně rozdělují znalosti na dvě skupiny – ty, které jsou pouze interní, zpracovávané pouze mentálně jedincem, a ty, které zprostředkovává ostatním, tedy je musí komunikovat a předávat dál. Jak bude uvedeno dále, tyto dvě kategorie znalostí jsou středem zájmu SECI modelu. Molnár (2012, str. 26) uvádí, že informace jsou vstupem do znalostního procesu, „tj. účelovou koordinací činností.“ Pojem účelovosti byl v této publikaci uveden v souvislosti s tvorbou znalostí vědeckého poznání. V obecné rovině se domnívám, že znalosti jsou často vytvářeny bez primárního účelu, proces tvorby znalostí je automatický – po přijetí je informace mentálně zpracována v kontextu znalostí. Pokud dojde k rozšíření znalostí díky této informaci, může to být nezáměrný a neúčelový proces. Účel a záměr této transformace může být rozpoznán až dodatečně. „Znalost se skládá z celé množiny porozumění, zkušeností a procedur, které lze považovat za správné a pravdivé a které proto vedou k uvažování, jednání a komunikaci lidí. Znalost spočívá v uvažování o informacích a datech za účelem umožnění, řešení problémů, rozhodování a učení se.“ (Molnár, 2012, str. 26) Informace jsou vstupem pro vytváření znalostí. Nejvyšším stupněm lidského poznání bývá nazývána moudrost, která zahrnuje znalosti, obohacuje je o hodnotové aspekty a lidský vztah k okolnímu světu. (Vodáček, 1997, str. 65) 3.1.3 Znalostní proces

V roce 1995 publikoval Nonaka a Takeuchi (1995) práci, ve které představili kategorizaci znalostí a kontinuální dynamiku přechodů mezi nimi, která vede ke vzniku nových vlastností. Spirálový model vzniku nových znalostí nazvali SECI – socialization (socializace), externalization (externalizace), combination (kombinace) a internalization (internalizace). V souladu s uvedenou charakteristikou tento model chápe znalosti jako vnitřní vlastnictví člověka, které ale lze rozdělit do dvou skupin – tacitní a explicitní. Explicitní znalost zahrnuje skupinu znalostí, které jsou natolik dobře strukturované a popsatelné, že je možné jejich vyjádření, komunikace a sdílení ve skupině. Forma vyjádření odpovídá typu znalostí – od verbálního popisu, přes pantomimické znázornění, až k psané či kreslené formě. Data, pomocí kterých jsou tyto informace předávány, mohou mít nejrůznější podobu. A právě proto, že tyto znalosti jsou vyjádřené pomocí dat, je

60 | 146

Anna Exnarová

možné je skladovat, uchovávat, pracovat s nimi i mimo lidský mozek. Skupina znalostí, která je pevně vázána na lidskou paměť, je nazývána tacitní. Jsou to ty znalosti, které neumíme sdílet s ostatními, není možné je přetransformovat do jejich popisu pomocí dat. „Jsou spojené s individuální zkušeností, dovedností, činností, intuicí, osobními představami, mentálními modely, emocemi jedince.“ (Molnár, 2012, str. 27) Klíčovým pro představení SECI modelu je fakt, že znalost je pevně vázaná na jednoho člověka, jejím sdílením dalšími jedinci pomocí komunikace generuje vznik další znalosti. Dochází tedy k neustálému nárůstu a obohacování znalostí.

Obr. 15 Cyklus znalostí SECI (upraveno (Umemoto, 2002) a (Gasson, 2007))

Spirála znalostí uvedená na Obr. 15 demonstruje transformaci tacitní znalosti na explicitní, v cyklu dále na tacitní, explicitní, atd. V modelu se objevují čtyři základní procesy. Socializací můžeme rozumět sdílení „pomocí nesdělování“. Znalosti nejsou apriori vyslovovány. K jejich přenosu na další lidi dochází pomocí napodobování nebo pozorování. A také sdílením souvisejících zkušeností, ale ne přímo sdělováním těchto znalostí. Toto sdílení může mít různou formu, např. brainstorming. V procesu externalizace dochází k vyjádření znalostí explicitní formou pomocí formalizovaných prostředků. Pro komunikaci znalostí uvnitř skupiny je možné použít slovní nebo grafické vyjádření (např. popisem nebo modelem). Sdělování znalostí v rámci skupiny je postiženo, oproti předchozímu procesu, daleko větší mírou nepřesnosti. Tato nepřesnost souvisí s nutností vyjádřit znalosti za pomocí jazyka, který ale (jak již bylo diskutováno) neumožňuje úplné sdělení mentálních modelů a procesů. Následnou identifikací a sdílením znalosti v organizaci je realizován proces kombinace. Činnosti, které v tomto procesu jsou vykonávané, souvisí s tříděním, vytvářením

61 | 146

Anna Exnarová

kategorií znalostí, posun znalostí do metodik organizace. V rámci tohoto procesu dochází k synergickému efektu, kdy explicitní znalosti vytvářejí další explicitní znalosti, které jsou komplexnější. K osvojení znalosti, její integraci do systému znalostí dochází v procesu internalizace.

Aplikace SECI modelu v organizaci

V jednotlivých krocích SECI modelu jsou tvořeny a používány různé formy znalostí. Proces tvorby znalostí v organizaci ve fázi analýzy vývoje informačního systému lze popsat takto: V procesu socializace pracuje analytik se zadáním, informace o problematice transformuje do znalostí. V procesu analýzy komunikuje s dalšími členy týmu, mezi nesdělované tacitní informace patří např. dovednosti a schopnosti analýzy, řešení problémů, komunikace. Výstupy přímo neobsahují vyjádřené tacitní znalosti, tyto znalosti jsou „vedlejším produktem“ uvedených výstupů. Mezi výstupy této fáze, které se podílí na sdílení tacitních znalostí, můžeme řadit: • diskusi a brainstorming, • prezentaci, • pozorování. Externalizace představuje vyjádření znalostí explicitní formou. V modelovém příkladu se jedná např. o sdělení výsledků analýzy, návrhy řešení, podkladové materiály pro další fáze. Výstupy obsahující formalizovaný popis znalostí mohou být: • analytická dokumentace a modely, • zápisy z jednání interní i se zákazníkem, • prezentace (ve smyslu činnosti i dokumentace). Ve fázi kombinace jsou vytvářeny nové explicitní znalosti synergií existujících. Na základě sdělení znalostí v předchozím kroku dochází k vzniku dalších informací. Výstupy této fáze mohou být: • revize dokumentů, • aktualizace dokumentace, • reporty a přehledy. Internalizace je fází osvojení si nově vzniklých informací.

Pro práci se znalostmi v organizaci je důležité znát skutečný stav znalostí i poznání. Nedostatek znalostí v organizaci může být velkou konkurenční nevýhodou. Ale ještě horší dopady může mít stav, kdy organizace je přesvědčena, že nějakou znalostí disponuje. Většinou se rozdíl mezi domněnkou a realitou ukáže v nejméně vhodný okamžik. Obr. 16 demonstruje možné kombinace stavu znalostí a stavu poznání. Model je možné transformovat do prostředí organizace, přičemž stav poznání představuje míru poznání v příslušném oboru.

62 | 146

Anna Exnarová

Obr. 16 Stavy lidského poznání (Vodáček, 1997, str. 29)

3.1.4 Problematika kvality a kvantity dat

Dopad rozvoje technologií v oblasti dostupnosti dat je v posledních několika desetiletích enormní. Jedním z výrazných změn, které globalizace ruku v ruce s rapidním vývojem technologie přinesla, je sběr, uchovávání a dostupnost dat. Západní civilizace mají nebývalé možnosti, co se týče práce s daty. (S nadsázkou se říká, že co nelze najít na internetu, jakoby neexistovalo.) Možnosti, které poskytují ve svých aplikacích velké firmy zabývající se prací s informacemi, jsou neuvěřitelné. Rozvoj je velmi rychlý, před několika lety zdánlivě nerealizovatelné „sci-fi“ nápady, jsou dnes realitou. Dle předmětu zprávy, e-mailu jsou automaticky navrhované stránky s příslušnou tématikou, existují možnosti vyhledávání dat v obrazových materiálech, dostupnost literatury, její kategorizace a třídění. Ve většině oborů je možné dohledat velmi velké množství údajů, informační technologie a informační systémy se stali hlavním zdrojem dat pro západní civilizaci. „Problémem není nedostatečné množství dat. Je ovšem obtížné je získat a především pochopit. Přetransformovat v informace a složit z nich mozaiku znalostí.“ (Mildeová, 2007, str.8) Mildeová konstatuje, že pod pojmem množství dat rozumí jak kvantitu tak také kvalitu. Kvalita uveřejňovaných dat, jejich věrohodnost, ověřenost a ověřitelnost, dohledatelnost původu, srozumitelnost jsou často opomíjené. V celospolečenském měřítku jsou tyto charakteristiky často vázané na zdroj, který danou informaci publikoval. Některé společenské skupiny lidí považují informace publikované v bulvárních plátcích za věrohodné a nezpochybnitelné, jiné skupiny tento zdroj informací v žádném případě nebudou akceptovat jako relevantní zdroj, ale např. Hospodářské noviny budou považovat za důvěryhodný. Z pohledu dat v organizaci dochází podle mých zkušeností často k omylům v tom smyslu, že pokud nějaká informace je publikována (ať již e-mailem, nebo na intranetu), musí být vždy kvalitní. Dá se říct, že v Internetu a v rámci informačního systému firmy jsou obvykle dostupná téměř všechna data, která jsou potřebná k jakémukoli podnikatelskému rozhodnutí. (Mildeová, 2006) S rostoucí dynamizací změn v organizaci i v jejím okolí, dochází zcela přirozeně i k zvýšení frekvence změn, aktualizace či růstu dat. Jedním z pilířů schopnosti firem uchovávat data a pracovat s nimi jsou právě informační technologie. Moderní ICT přispívají k podstatnému zrychlení informačních toků, což od firem vyžaduje i zrychlení rozhodovacích procesů. (Mildeová, 2007)

63 | 146

Anna Exnarová

3.2 Systémové myšlení a jeho modely 3.2.1 Systémový přístup

V turbulentním globalizovaném prostředí, s výrazným dynamickými přechody a klíčovým faktorem znalostí jsou změny natolik výrazné, že v prostředí organizací vznikla potřeba změny myšlení i jednání. Mildeová (2007, str. 9) tento stav komentuje: • „Vztahy mezi různými ekonomickými, sociálními, ekologickými či fyzikálními subsystémy, které utvářejí svět, jsou provázány tak složitě, že pochopení vazeb v těchto systémech je pro nás příliš náročné. • Nesystémově vedené zásahy vyplývající z tohoto našeho omezení mohou vést ke zdánlivým řešením, ale bezpočet případů z praxe potvrzuje, že takováto rozhodnutí často přináší dlouhodobé problémy. V konečném důsledku mohou i znemožnit odstranění skutečných příčin problému a problémy, kterým čelíme a snažíme se je řešit, se tak stávají proti našim zásahům imunní. • Žádná řešení považovat a priori za správná a je nutné dodržet holistický systémový pohled při současném respektování toho, že každý přístup má své přínosy a omezení.“ Z výše uvedeného vyvstává potřeba systémového přístupu. Ten je základem moderních teorií managementu. Jeho podstatou je snaha vysvětlit a zdůvodnit pohyb reálných objektů pomocí systémů, jejichž celistvost je dána množinou vzájemně propojených prvků. Systémový přístup k řízení je způsob myšlení, způsob řešení problémů a způsob konání, při kterém jevy chápeme komplexně v jejich vnitřních i vnějších souvislostech. Chápání systému v rámci systémového přístupu je zakotveno ve způsobu komplexního myšlení nad prvky systému a vazbami v rámci vnitřních i vnějších souvislostech. Definovat systém znamená dokázat definovat jeho části a vztahy v rámci interních i externích souvislostí tak, aby byla zabezpečena celistvost systému. Řešení složitějších problémů, které v sobě zahrnují větší počet proměnných a faktorů, je pro přirozené mentální procesy neefektivně zvládnutelné. V systémových vědách se setkáváme s dvojím přístupem k řešení problémů – tyto přístupy vycházejí ze dvou zásadních směrů: • Systematický přístup odpovídá nahlížení na svět v tradičních souvislostech. Svět a realitu kolem nás tvoří složitá struktura prvků a vazeb. V jeho vývoji můžeme najít pravidelné zákonitosti. Naše poznání a omezení pochopení a uchopení světa je vysvětlováno pouze mírou přesnosti a podrobnosti zkoumání. Informace jsou považovány za reprezentaci skutečnosti. Dle Molnára (2012, str. 82) je systematické myšlení myšlením metodickým. • Druhým přístupem je přístup systémový. Respektuje samo-organizování systému, složitost systému (bez ohledu na naše zkoumání a znalosti), lidské znalosti a jejich omezení a významný vliv procesu lidského poznávání na tvorbu znalostí. O systému se zde uvažuje jako o komplexitě s danou složitostí, samoorganizací a vazbou na změny v čase a dynamiku. Systémové myšlení koresponduje právě se systémovým přístupem. Molnár (2012, str. 82) uvádí, že

64 | 146

Anna Exnarová

používat systémové myšlení znamená vidět věci v interakci s ostatními. Systemické myšlení je založeno na schopnosti nalézt a vidět systémové vzory. Vznik systémového přístupu je spjat se vznikem všeobecné teorie systémů a kybernetiky. Všeobecná teorie systémů je metodologická koncepce analýzy systémů, která vede k vytvoření exaktního zobrazení světa jako množiny systémů a procesů. Systémový přístup je definován základními principy, které lze aplikovat při popisu systémů (Mildeová, 2007, str. 11): • Holismus a emergence představují skutečnost, že není možné na základě dekompozice systému na části poznat vlastnosti celého systému, jeho chování a existenci. Kompozicí izolovaných prvků není možné popsat ten samý systém, který je dán těmito prvky, ale i vazbami a vnější i vnitřní interakcí. „Kvalita systému je prezentována spolupůsobením jeho vlastností, které se „vynořují“ v průběhu konkrétní interakce jeho částí.“ • Součet vlastností jednotlivých částí nekoresponduje s vlastnostmi celku, při spojení jednotlivých částí do celku vyvstávají také nové vlastnosti, které ze zkoumání jednotlivých částí neexistují. Celek je více než jen součet jednotlivých částí. Příkladem může být přirozený jazyk se svými charakteristickými vlastnostmi – jednotlivá slova mají svůj význam, ve větě lze informaci díky kontextu vnímat odlišně a často pouze pozměnění pořadí slov je vytvořen nový význam. • Systémová hierarchie zkoumá systém jako součást systému vyšší úrovně a naopak považuje každou část systému za autonomní. Toto pojetí se od tradičního rozpadu systému na jednodušší části liší. Systémová hierarchie pracuje se systémem, tedy neustále má na zřeteli systém a jeho vazby na okolí – okolní systémy, vazby uvnitř systému, jeho vlastnosti, funkce a chování. Není to tvrdé oddělení části celku a jeho izolované zkoumání. • Zpětná vazba je nepostradatelná pro systémy, kde je nutná regulace a samoregulace. Čím vyšší komplexitu systému pozorujeme, tím vyšší a složitější systémy zpětných vazeb lze nalézt. Proces samoregulace v případě lidského systému představuje sekreci hormonů, přizpůsobování teploty organismu okolním podmínkám, regulace tepové frekvence odpovídající fyzické námaze apod. Kromě fyzických regulačních procesů (které jsou často na naší vůli nezávislé), můžeme pozorovat proces zpětné vazby například v procesu učení se. Význam této vlastnosti výrazně vzrostl v souvislosti s řízením systémů a kybernetikou prvního i druhého řádu. • Komunikace systémů představuje výměnu informací / dat mezi prvky systému nebo okolím. Jednou z vlastností živých systémů je komunikace, která je základním předpokladem pro schopnost reakcí na podněty z okolí i uvnitř systému. Rovněž význam této vlastnosti výrazně vzrostl s pojmem kybernetiky.

65 | 146

Anna Exnarová

„Systémové přístupy pomáhají informační procesy plánování ve firmě správně strukturovat, slaďovat do informačně integrovaných plánovacích soustav, vytvářet pro ně přiměřené modely k řešení jejich analytických a rozhodovacích funkcí, být základem pro tvorbu počítačově podporovaných systémů jejich zpracování.“ (Vodáček, 1997, str. 86) 3.2.2 Systémové myšlení

Problémy dnešního světa jsou způsobeny naší neschopností pracovat a vidět systémy i jejich problémy jako celek. (Senge, 1995) Systémové myšlení (system thinking) je způsob, jehož aplikací při nahlížení na svět budeme schopni akcentovat a pracovat se systémy v souladu s principy systémového přístupu. „Systémové myšlení je disciplína, která nám pomáhá konstruovat s realitou lépe sladěné mentální modely a simulovat je přesněji. Zvyšuje tak pravděpodobnost, že opravdu vyprodukujeme naším jednáním a rozhodnutími důsledky, které jsme předem zamýšleli.“ (Vojtko, 2005) Systémové myšlení (rovněž tak i systémová dynamika) poskytují nástroje, které nám umožňují překonat omezení našich vlastních mentálních modelů. „Na základě našich mentálních modelů běžně odhadujeme, co se může asi ve vnějším světě stát a jaké strategie a činy povedou ke kýženým cílům. Bohužel, často se mýlíme a nepředpokládané důsledky naše úmysly znehodnocují.“ (PROVERBS, 2013) Na svět nahlížíme přes naše mentální modely, které jsou velice individuální, obsahují ze své podstaty chyby a samostatně použité poskytují nevyhovující výsledky při řešení složitých problémů. Systémové myšlení pomáhá měnit mentální modely. Představuje soubor metod, přístupů, modelů, které po úspěšném zvládnutí poskytují velkou výhodu – schopnost lépe řešit problémy, přizpůsobovat se změnám okolí a chápat podstatu světa. Systémové myšlení je uměním a vědou o tom, jak formulovat spolehlivé závěry o chování systému, a to na základě hlubokého pochopení jeho struktury. (Exnarová, 2011) Způsob myšlení je utvářen celou řadou faktorů. Zcela určitě to je celá skupina geneticky daných predispozic, vrozených archetypů procesů a stylů. Dále jsou ty části našeho myšlení, které jsou získány v průběhu našeho života, ovlivněny výchovou, vzděláním, sociální skupinou, ve které se pohybujeme. V systémových teoriích se mluví o paradigmatu myšlení, které popisuje všechny faktory určující náš konkrétní způsob myšlení. Dle Mildeové (2008) lze vyzdvihnout čtyři hlavní negativní paradigmata, které nám zabraňují systémovému myšlení: • příčina – následek, • zpětnovazební smyčka, • časové hledisko, • simulovat a myslet současně. Paradigma je myšlenka, postoj, názor, nebo vybraný způsob řešení, který je obecně přijímán odbornou veřejností. Velmi úzce tento pojem souvisí s mentálními modely, je určujícím faktorem pro porozumění informacím. Pokud chce jedinec řešit komplexní úlohy úspěšně, musí aktivním kognitivním procesem trvale pracovat na korekci svých mentálních modelů i paradigmat (upraveno dle (Molnár, 2012, str. 77)). Dle Mildeové (2007) a (2012) je základem paradigmatu „vhodnost postavení“ a schopnost myslet. Pod

66 | 146

Anna Exnarová

pojmem „vhodnost postavení“ je chápán postoj k problému, vnímání a chápání jak problému, tak jeho okolí. Efektivní pohled na problém je vyhledáním jakési rovnováhy vzdálenosti, tj. ani ne zblízka příliš detailní, ani ne z velké dálky, tak aby nebyly zanedbané podstatné skutečnosti. To co vnímáme je závislé na našem způsobu nahlížení. Pozornost by měla být věnována nejen struktuře, ale také vzorům chování a jeho důsledkům. Hledání příčin a následků je v západním způsobu myšlení velmi pevně zakořeněný přístup k řešení problémů. Ať již v soukromém, profesním nebo vědeckém životě – všude jsme obklopeni výčtem příčin a důvodů, které mají za následek nějaké chování nebo stav. A většinou se snažíme se dopátrat úplného výčtu – čím víc tím líp. Jedná se přitom o hledání jednoduchých kauzálních vztahů, jednosměrného a bez jakéhokoliv vymezení vzájemného působení mezi příčinami. Také zde neexistuje akcent na zpětné působení od následku k příčině. Při modelování problémové situace je absolutně zanedbána skutečnost, že důsledek může mít velký vliv i na původní příčiny. Domnívám se, že jedním z důvodů, proč tato paradigmata existují, je silná vazba lidské existence na čas. Čas, který plyne lineárně, v našem pojetí neexistují zpětné vazby, neumíme se vrátit k minulému. Zároveň náš styl myšlení nám umožňuje ukládat vzpomínky v lineární posloupnosti vázanou na čas. Akce a reakce se staticky definovanými procesy a neměnnými účinky působení neumožňují pohlížet na svět dynamickým a systémovým přístupem. (Exnar, 2013) Lidská paměť obsahuje otisky událostí minulosti (ať již všech a jen některé jsou zvědomělé, nebo pouze určité skupiny) a dle obecných zkušeností je zřejmé, že jejich uchovávání je velmi individuální proces, který je zatížen množstvím chyb (neúplnost a záměrná i nezáměrná selekce, úprava skutečnosti, chybné vyhodnocení parametrů, atd.). V současné globální společnosti jak již bylo zmíněno, je mnoho procesů, jejichž dílčí činnosti probíhají v pozičně i časově oddělených okamžicích. Lidský mozek pokud není záměrně k tomuto veden, má tendenci dlouhotrvající procesy rozdělovat na menší úseky a ty zpracovávat a nedávat je do souvislostí. „Naše současná rozhodnutí ovlivní budoucnost, a to i budoucnost, která se nás osobně již nemusí týkat. Bez ohledu na přijatá normativní stanoviska simulace přiměje uživatele k porovnávání krátkodobých a dlouhodobých účinků téhož rozhodnutí – jejich dopady mohou být v extrémním případě zcela protichůdné.“ (Mildeová, 2007, str.9) Metoda systémového myšlení spočívá ve dvou paralelně probíhajících procesech. V prvním procesu se stanovují a testují hypotézy, na základě kterých jsou tvořeny závěry, ty jsou hodnoceny a následně implementovány. Druhý paralelní proces tvoří definování, provedení a implementace organizace učení (Vojtko, 2005). Komplexní pohled na svět, odpovídající principům systémových přístupů, je podstatný pro • pochopení skrytých a „neviditelných“ příčin, které za událostmi stojí, • interpretaci událostí a příčin, • nalezení účinného řešení problémového chování systému. Systémové myšlení vychází ze systémových přístupů. Z toho důvodu autoři mezi základní principy systémového myšlení řadí ty principy, které jsou charakteristické pro

67 | 146

Anna Exnarová

systémové přístupy obecně, tj. holistický přístup, systémová hierarchie, zpětná vazba a komunikace s okolím. (Mildeová, 2007) Holismus a emergence vyjadřují myšlenku, že výslednou kvalitu systému nelze odvodit z dekompozice na části a jejich analýzy jakožto izolovaných prvků. Vlastnosti systému se vynořují (emergují) při interakci jednotlivých komponent v konkrétní situaci. Synergetika je věda zabývající se utvářením, stabilizací a zánikem systémových struktur. Je zřejmé, že většina systémů je součástí jiných systémů (živý systém člověk je součástí sociálního systému) a naopak každý systém může být dekomponován na komponenty, které jsou samy systémy (živý systém člověk lze rozložit na biologické systémy buněk). Tento poznatek shrnuje pojem systémové hierarchie, jež uvažuje systém jako součást systému vyššího a naopak každý prvek systému za autonomní systém. Pojem zpětné vazby, zavedený v kybernetice, umožňuje, pokud je toho systém schopen, učení systému. Díky korekčním datům, která systém pomocí zpětné vazby získá, může své chování v dané situaci upravit. Komunikací v systémovém myšlení myslíme především výměnu informací mezi systémem a okolím. Informace, které systém získá od okolí, významně ovlivňují chování systému vůči jiným systémům (okolí) nebo jednotlivých prvků systémů mezi sebou. „Systémové myšlení: • Znamená myšlení v procesech. Systémový pohled pozoruje svět se zřetelem k souvislostem a integraci. Systémy jsou integrované celky, jejichž vlastnosti se nedají redukovat na vlastnosti menších jednotek. Systémové učení se soustřeďuje na základní organizační principy místo na základní stavební kameny a základní substance. • Zdůrazňuje vztahy mezi vzájemně závislými prvky uvnitř systému (na rozdíl od toho analytické myšlení se soustřeďuje na hlubší poznání každého prvku jednotlivě). • Je to přístup k realitě, který počítá s dynamickou složitostí systému a s cyklickým řetězením příčin a následků v čase. (viz dále součásti systémového myšlení). • Takovému způsobu myšlení je třeba se systematicky učit a je potřeba naučit se systémové myšlení používat jako samozřejmý nástroj každodenní činnosti – a k tomu vám vaše tvorba simulátorů bude velmi nápomocná. Vyžaduje skutečnou změnu v myšlení spojenou s nezbytností zbavit se dosavadních zvyklostí a přístupů. • Je potřebný způsob nového myšlení a učení (se). Lidé, kteří se sami snaží pochopit podstatu věcí, se naučí mnohem více než lidé, kteří jsou o dané podstatě pouze přesvědčováni. Je to dilema mezi starým a novým, mezi rigiditou a flexibilitou. Čím více lidí získá schopnost systémového vidění světa, tím snadnější bude udržovat svět v žádoucím a stabilním stavu. • Je uměním a vědou o tom, jak formulovat spolehlivé závěry o chování systému, a to na základě hlubokého pochopení jeho základní struktury.

68 | 146

Anna Exnarová

•

Je paradigmatem i výukovou metodou. Paradigma podmiňuje výukovou metodu, která zpětně podporuje paradigma – tyto dvě části vytvářejí synergický efekt.“ (Mildeová, 2007, str. 10)

Aplikace systémového myšlené umožňuje reálný posun v způsobu našeho myšlení • od jednosměrné ke kruhové příčinnosti, • od nezávislých faktorů k souboru vzájemně propojených faktorů s proměnnou váhou působnosti, Tento posun potvrzuje ve svých výzkumech v českých publikacích např. Mildeová, Vojtko, v zahraničních např. Richmond. Z pohledu rozpadu je možné systémové myšlení chápat jako soubor tří základních dovedností: příčinné myšlení, myšlení v uzavřených smyčkách a operační myšlení. (Richmond, 1994), (Mildeová, 2007) 3.2.3 Dovednosti systémového myšlení

Příčinné myšlení (Cause Thinking) vychází z předpokladu, že struktura systému ovlivňuje jeho chování. Pro zkoumání problému je tedy důležité zaměřit se na strukturu zkoumaného systému. Myšlení v uzavřených smyčkách (Closed-loop Thinking) představuje druhý pilíř systémového myšlení. Pro zkoumání problému je důležité zaměřit se na zkoumání zpětných smyček v systémech. Chování je ovlivněno strukturou, ale zároveň struktura ovlivňuje chování. Příčinné souvislosti nejsou pouze jednosměrné, pro úspěšné řešení problému nepostačuje zkoumat závislost příčina – následek. Důležité je prozkoumání i zpětných vazeb, které můžou být přímo následek – příčina, nebo jsou složitější o další proměnné (o další následky a příčiny). Myšlení v uzavřených smyčkách umožňuje pohlížet na svět dynamicky, jako na soubor vzájemně závislých a neustále probíhajících procesů. Dle Mildeové (2007) jsou právě tyto smyčky zodpovědné za projevy chování systému. Aplikací tohoto myšlení dochází k posunu identifikace příčin. Vnější faktory nejsou příčinou, i když mohou přispět k vzniku následku příčiny. Uzavřené příčinné smyčky jsou příčinou chování systému. Posledním krokem pro úplný obraz systémového myšlení je operační myšlení (Operational Thinking). Tento krok nahlíží na uzavřené příčinné a umožňuje jejich zkoumání z pohledu systému. Aplikovat operační myšlení znamená přemýšlet tak, jak věci fungují v realitě. Zkoumání systému přirozeným způsobem je uplatňováno pomocí hladin a toků. Požadavkem na správné uplatnění tohoto druhu myšlení je práce pouze s reálnými objekty, skutečně existujícími v systému. Uplatnění systémové myšlení v praxi je spojeno s aplikováním jeho dovedností, s akcentováním a využíváním systémového přístupu a částečně s vytvářením a používáním modelů systémového myšlení nebo systémové dynamiky. Nicméně samotná tvorba modelů není zárukou systémového myšlení. Modely jsou prostředkem, nástrojem na to, jak umožnit, ulehčit a zpřístupnit proces systémového myšlení.

69 | 146

Anna Exnarová

3.2.4 Mentální modely

„Znalostním (kognitivním) modelem rozumíme soubor relevantních znalostí o jisté ontologické entitě. Se znalostními modely se setkáváme jak v běžném životě, tak v odborné práci, a to mnohem častěji, než si vůbec uvědomujeme.“ (Křemen, 2007, str.9) Lze říci, že lidské mentální modely jsou komplexní a multidimensionální směsicí obrazů a zkušeností, a poměrně důsledně odrážejí osvojený způsob myšlení. Od dětství máme naučené postupy rozdělit problém na menší části a řešit samostatné fragmenty. Je to postup, který nám zdánlivě „ulehčí“ řešení složitých úloh. Daň, kterou za to musíme platit, je nemožnost vidět důsledky a ztráta smyslu pro souvislosti s větším celkem. Pokud chceme vidět celý obraz, musíme se pokusit znovu poskládat jednotlivé kousky do celku včetně jejich souvislostí. (Senge, 1995). Mentální modely, jak již bylo konstatováno při definici systémového myšlení, jsou (a v práci jsou také dle této definice chápány) zjednodušením reality, které si člověk vytváří proto, aby mohl v realitě vůbec existovat a schopen o ní přemýšlet. Na základě mentálních modelů je člověk schopen přemýšlet o vnějším světě, vytvářet si simulace a plánovat strategie pro to, aby dosáhl požadovaného stavu. Bohužel, často jsou tyto modely nesprávné, jsou vytvářené chybné úsudky a nastávají nepředpokládané důsledky. (PROVERBS, 2013) Mentální model představuje zjednodušení reality, který si vytváříme v našich hlavách a který potřebujeme k tomu, abychom byli schopni v realitě existovat. Je to pouze zjednodušený obraz, žádný model není dokonalou kopií reality. Zahrnuje v sobě ty vlastnosti systému, které považujeme za potřebné. Dle mého názoru pojem mentální model výstižně definuje (Richmond, 1994): lidské mentální modely sestávají z komplexní a multidimensionální směsice obrazů a zkušeností. Každý z nás si v průběhu života vytváří velké množství mentálních modelů, které potřebuje pro svou existenci. Realitě přisuzujeme obraz a význam prostřednictvím svých mentálních modelů. Neuvažujeme nad realitou, ale právě nad svým modelem. Množství a kvalita mentálních modelů a zkreslení modelu závisí na: • našich schopnostech vnímat svět, • mentálních schopnostech, • schopnosti práce s informacemi, • množství informací, které jsme schopni získat a zahrnout do modelu, • angažovanosti k řešení dané situace. Můžeme mít k dispozici stovky tisíc statistických údajů pro danou problematiku, ale mentálně tyto čísla nejsme schopni do žádného mentálního modelu zahrnout. Narážíme na faktický problém obsahu naší paměti i na schopnost aktivně sledovat vazby a existenci několika entit najednou. Odhadovat vývoj situace ve zkoumaném systému umožňují mimo jiných také mentální modely. Je nástrojem pro řešení problému. Představují nejjednodušší simulační prostředí. Pomocí něho se snažíme odhadnout vývoj situace a aplikaci vhodné strategie pro řešení konkrétního problému. Můžeme snadno na základě našich znalostí a

70 | 146

Anna Exnarová

mentálních dovedností odhadovat různé dopady jednotlivých variant řešení. Zahrnutím různých stupňů podrobností lze model upřesňovat. Modely obecně nejsou bezchybné a při jeho používání musíme často celý model upravovat podle nově zjištěných skutečností. Změna v realitě, pokud je zaznamenána a zpracovatelná, může být poměrně snadno včleněna do mentálního modelu. Vyznačuje se poměrně vysokým stupněm flexibility. Podstatná je také ochota a vůle změnit mentální model. Pokud je problém velkých rozměrů a je v něm zaangažovaných více lidí, je nutnost podělit se o řešení problému. Myslím si, že je problematické vzájemné vyměňování si svých modelů a jejich sdílení. Předávání mentálního modelu okolí znamená zatížení předávaného modelu nepřesnostmi a problémy, které v sobě obsahuje jazyk. Při jeho používání si musíme být vědomi jeho omezení, ale je to jediný prostředek komunikace, pomocí kterého můžeme části svých modelů předávat. Naše mentální modely jsou zatíženy chybami, které pocházejí z neschopnosti pojmout myšlenkově celý model světa, z linearity přemýšlení, z existencí pouze lineární vazby příčina – následek. V průběhu evoluce nebyl náš mozek nucen myslet jinak, než v příčinně-následné vazbě, pochopení složitých dynamických dějů s výskytem zpětných vazeb a zpoždění nebylo až do nástupu průmyslové revoluce nutné pro přežití. (Mildeová, 2003) Mentální model je silně individuální záležitostí, je omezen schopnostmi jedince, jeho vzděláním a pozicí v systému. Zároveň je mentální model silně navázán na jazyk, protože ten tvoří rámec našeho uvažování a v jeho mezích se naše uvažování tvoří. Stručně můžeme říci, že mentální modely jsou zatíženy především: • předpoklady, které jsou základem pro vytvoření mentálních modelů a které nejsou s realitou v dostatečném souladu, • naše simulace (odhadování důsledků) chování modelu nepostihuje všechny podstatné důsledky, které vyplývají z daných předpokladů (převzato z (Vojtko, 2005)). Problematickým, v našem vnímání, je sklon k linearizaci a neschopnost uvažovat v zpětnovazebních smyčkách s dynamickými proměnnými (celkově se tyto vlivy označují jako „omezená racionalita“) a defenzivním chováním komplexních sociálních systémů. Nejsme schopni složité dynamické jevy, vycházející ze zpětnovazebních struktur, korektně interpretovat. Poznatky o vlastnostech mentálních modelů lze shrnout do výčtu základních charakteristik. Pozitivními vlastnostmi mentálních modelů je jejich úzká vazba na znalosti a kognitivní procesy tvůrce. Jejich existence v mysli umožňuje možnost okamžitého použití kdykoliv a kdekoliv. Obsahují vazby, znalosti, zkušenosti, které jsou vlastní jen tvůrci, a není možné je nikde jinde získat. Umožňují pracovat s tacitními znalostmi. Nedostatky mentálních modelů jsou tyto jejich vlastnosti: (převzato z (Costello, 2007), (Chermack, 2003), (Molnár, 2012)): • jsou nekompletní, • limitované schopnostmi lidí „řídit“ jejich mentální modely, 71 | 146

Anna Exnarová

• • • • •

jsou nestabilní, bez jasně definované hranice, nevědecké, obvykle zahrnují pověrčivé chování a nedůvěru k technologiím, z části nevědomé, obtížně komunikovatelné a sdílené.

Problematika mentálních modelů bývá spojována s obtížným sdílením modelů. „Mentální modely jsou filtry, kterými interpretujeme své zkušenosti, měníme plány a vybíráme z několika variant.“ (Mildeová, 2006, str. 18) Porozumění mentálnímu modelu jiného člověka bývá složité a nutně musí docházet ke zjednodušování a úpravě modelu dle charakteristik příjemce. Bohužel vedle problému se sdílením existují i problémy již u vlastníka mentálních modelů. „Je ale propastný rozdíl mezi tím, jaký je mentální model a tím, co skutečně vnímáme.“ (Mildeová, 2006, str. 18) Lidský mozek a základní parametry kognitivních procesů neumožňují práci s konstrukcí mentálních modelů v libovolném rozsahu. Problematickým se také stává chápání vlastních mentálních modelů, či jejich používání v procesu rozhodování. (Molnár, 2012). Nedostatky mentálních modelů se pokoušejí odstranit modely systémového myšlení.

3.2.5 Myšlenkové mapy

Mentální mapy (mind mapy) umožňují vizualizovat vybranou část mentálních modelů, umožňují vizualizovat a dokumentovat předávané informace. Myšlenková mapa je grafické znázornění pojmů, jejich vazeb a souvislostí, doplněné např. grafikou, obrázky, ikony, barevným odlišením. Tyto modely jsou založeny na jednom z principů přemýšlení – lidé nemyslí čistě lineárně, ale vytváří si mapy myšlenek, které různě rozvíjí a propojují. (Buzan, 2011) Myšlenkové mapy pravděpodobně poprvé dokumentoval zmíněný T. Buzan v 60.letech 20. století. Z pohledu struktury dat se jedná o diagramy v mnoha případech tvořené „od ruky“ (během přemýšlení, učení nebo v průběhu jednání). Nezastupitelnou úlohu hrají modely, které vzniknout formou brainstormingu, či jsou výsledkem jednání. Lidé si uvědomují, že tyto modely jsou nenahraditelné. Pouhým výčtem či běžným zápisem z jednání, zaznamenáním informací formou lineárních zápisů je zabezpečeno plné zaznamenání informace a umožnění jejího přenosu dále pouhým čtením. Naproti tomu mentální modely díky své struktuře umožňují zdůraznění a rychlé uchopení hlavních pojmů, vytvoření proudu asociací, vytvoření vazeb mezi pojmy. Zároveň, díky softwarovým nástrojům, umožňují vytvořit přitažlivé „marketingově“ a „zákaznicky“ orientované výstupy. Z těchto důvodů bývají tyto modely součástí běžných zápisů z jednání, nebo přímo součástí dokumentace systémů. Ve firemní praxi bývají používané také specializované nástroje a programy, které umožňují tvořit diagramy vysoké grafické kvality. Takto vytvořené modely jsou většinou určeny pro dokumentaci problematiky, zároveň je využívána možnost transformace a propojení s prezentačními programy či sdílení ve firemních znalostních nástrojích.

72 | 146

Anna Exnarová

Obr. 17 Příklad myšlenkové mapy

Mentální mapa je tvořena okolo textu uprostřed, se kterým se pojí myšlenky, slova či představy. Hlavní prvky se odvíjejí z centrálního bodu, ty podružnější jsou pak podřízené větve těm hlavním. Prvky jsou reprezentovány slovy, myšlenkami, úkoly či dalšími typy souvisejícími s centrálním slovem či myšlenkou. Systémem hlavních větví, které se dále štěpí na další dílčí podskupiny. Grafická podoba může být centralizovaná, stromová, hierarchická, některé programy umožňují také transformaci do modelu rybí páteře či tabulkové podoby. Příklad myšlenkové mapy je znázorněn na Obr. 17 – jsou zde zaznamenány relevantní parametry, které ovlivňují řešení úkolu. Problematika „Řešení úkolu“ je jednoduchým příkladem, na kterém jsou postupně demonstrovány modely systémového myšlení a systémové dynamiky. Myšlenkovou mapou jsou vymezeny prvky systému a identifikovány parametry, které ovlivňují to, zda řešený úkol je vyřešen či nikoliv. Na řešení problému má přímý vliv časový plán (termíny, disponibilní čas, požadované časové prodlevy), postoj člověka, efektivita a úsilí, které věnuje řešení problému a samozřejmě technické a procesní záležitosti. Příklad rovněž dokumentuje některé možnosti, které myšlenkové mapy získávají díky použitému softwaru – barevné odlišení, znázornění, vložení grafických prvků, atd. Vše s cílem zpřehlednění, zdůraznění či „prodat“ předkládanou informaci co možná nejefektivnějším způsobem. V tomto typu diagramů lze jasně, názorně a hlavně přehledně postihnout to, co se je obsahem mentálních map. Navíc tento mechanismus struktury diagramu umožňuje ujasnit si prioritu a důležitost jednotlivých pojmů a dát jim odpovídající místo a postavení. Díky paralelní tvorbě grafického vzhledu a informační náplně mapy splývá logická, plánovací a třídící funkce levé hemisféry s grafickou, vizuální a také intuitivní funkcí pravé hemisféry. Díky této synergii pracuje mozek rovnoměrně a výsledky tohoto postupu jsou bohatší než použití strukturovaných diagramů. Lze tedy říci, že výhody myšlenkové mapy se nejvíce uplatní v kreativních fázích projektu, kdy je nutné dostat ten správný nápad, najít správnou cestu, přístup k řešení problému. Díky jednoduchosti jsou vhodné pro tvorbu v týmu a sdílení myšlenek. Myšlenková mapa má ale jednu vlastnost, která je u ní ještě více akcentována než u jiných diagramů. Její přínos je poměrně velký již při samotné tvorbě, nikoli v samotném diagramu (vizualizaci). Diagram dá možnost myšlenkám proudit a vést k nalezení řešení. Pokud je proces úspěšný a je řešení nalezeno, dá se říci, že taková mapa splnila účel. Osamocená existence vizualizace není příliš důležitá, je to pouze dokumentace 73 | 146

Anna Exnarová

toho, jak bylo řešení nalezeno. Pro aktéry, kteří se účastnili její tvorby, nicméně je velmi důležitým dokumentačním nástrojem. Pokud je aktérovi zobrazen zápis z jednání formou dokumentu či strukturovaných bodů, je kognitivní funkce „rozpomínání“ na danou problematiku mnohem pomalejší a má poměrně horší výsledky než v případě, kdy mu bude předložena mentální mapa, na jejíž vytvoření se podílel a jejíž vznik sledoval i z grafické stránky. Buzan (2007) považuje za hlavní výhodu mentálních map skutečnosti, že jejich tvorbou a používáním si uživatelé i tvůrci více pamatují. Umožňují pracovat s problematikou komplexně, odráží požadavky na systémový přístup k řešení problémů. Nevýhodou je potřeba použití krátkých textů, kterou lze ale odstranit použitím komentářů, či doplněním vizuální části modelu jeho textovou částí. Myšlenkové mapy jsou zaměřeny na vizuální stránku předkládané informace, z tohoto důvodu nemusí vyhovovat lidem preferujícím jiný typ komunikace. Frey (2010) ve své práci uvádí dle mého názoru zajímavé výsledky výzkumu zaměřeného na využívání mentálních map s porovnáním výsledků mezi roky 2006 a 2010. Mezi nejčastější aktivity, pro které jsou myšlenkové mapy používány, patří plánování, přemýšlení, učení se a uspořádávání znalostí, vytváření seznamů úkolů (tzv. to-do list), příprava prezentací a řešení problémů. Poměrně zajímavým výsledkem oproti mým očekáváním je vyhodnocení používání modelů mezi členy týmu – pouze 9% respondentů odpovědělo, že své modely nikdy nesdílí s dalšími členy týmu. Ve všech ostatních případech dochází aspoň k občasnému sdílení modelů. Což může naznačovat potvrzení hypotézy, že tyto modely jsou přínosné pro týmovou práci, sdílení znalostí a potažmo pro rozšiřování znalostního portfolia členů týmu či organizace. Mezi nejvýznamnější přínosy, které použití těchto mentálních map přináší, uvádí Frey tyto: • především výrazné zvýšení produktivity práce, • zlepšení jasnosti, přehlednosti myšlení, • řízení přehlcení informacemi, • vizualizace vazeb mezi informacemi, • získání lepší organizace informací. Domnívám se, že používání mentálních map je přínosné a poskytuje poměrně jednoduchý nástroj, který umožňuje a ulehčuje aplikovat systémové myšlení v reálných situacích.

3.2.6 Modely šestiúhelníků

K pokrytí mezery mezi myšlením „bez nástrojů“ a tvorbou specializovaných modelů pro řešení konkrétního problému navrhl Hodgson (1992) ve své práci nový typ modelů – hexagony. Hexagonální modely, jsou modely systémového myšlení a slouží jako jednoduchá a zároveň účinná technika k překonání rozdílů mezi zobecňujícím myšlením těch co rozhodují, a specializací modelářů, tedy tvůrců diagramů. (Hodgson, 1992)

74 | 146

Anna Exnarová

Tento rozdíl je dán nedostatečným stupněm systémového myšlení a pochopení dynamický vztahů. Diagramy hexagonů (diagramy šestiúhelníků, někdy také označovány pojmem „issue maps“) obsahují základní prvky systému a vazby mezi nimi. Pro dokumentaci vazeb mezi prvky jsou ale poměrně vhodné z důvodu nenáročnosti notace a možnosti využití pro jejich tvorbu libovolného nástroje. Oproti jiným diagramům je zajímavé, že tento typ modelů pro znázornění vazeb používá pouze styčné body šestiúhelníků, nejsou zde (v jiných diagramech obvyklé) vazby znázorněné pomocí čar či šipek. Domnívám se, že právě z tohoto důvodu je vhodné hexagonové modely řadit velmi blízko k mentálním modelům. Oproti výše uvedeným mentálním mapám nejsou hexagony v praxi příliš využívané, bohužel ani neexistuje dostatečná podpora v běžně rozšířených modelovacích nástrojích, které by bylo možné využít. Jistou nevýhodu lze spatřovat v jejich horší čitelnosti pro nezúčastněného pozorovatele. Jak již bylo uvedeno, modely systémového myšlení jsou představeny na problematice „Řešení úkolu“. Na Obr. 18 je pomocí modelu šestiúhelníku znázorněna část této problematiky. Pro oblast „Řešení“ je důležitým parametrem „schopnost řešit problém“, který je v tomto modelovém příkladě ovlivněn „efektivitou“ a „tlakem na řešení“. V pravé části modelu jsou obdobně znázorněny parametry související s „Plánováním“ realizace úlohy. Diagram šestiúhelníků tedy v příkladu vymezil vzájemné vztahy mezi identifikovanými parametry a prvky.

Obr. 18 Diagram hexagonů

Modely hexagonů dokumentují velmi dobře provázanost dílčích akcí. Tyto modely lze dále rozvinout do modelů příčin a následků, kdy jsou vytvářeny příčinné vazby mezi prvky. (Hodgson, 1992)

3.2.7 Diagram příčin a následků

Dnes již klasickým prostředkem pro vizualizaci příčin a následků je tzv. diagram příčin a následků, neboli diagram rybí páteř, diagram rybí kosti, fishbone diagram, někdy také označována jako Ishikawův diagram. Diagram slouží jako prostředek analýzy příčin a

75 | 146

Anna Exnarová

následků, v některých případech bývá používán obdobně jako myšlenkové mapy pro sumarizaci souvisejících prvků a jejich vazeb. Diagram poprvé představil Kaoru Išikawa jako nástroj pro nalezení pravděpodobné příčiny problému. Diagram je tvořen od prvku představujícího řešený problém, který je představován např. slovem nebo krátkým textem. Tento prvek představuje důsledek, k němuž je hledána příčina. Na tento hlavní prvek je napojena „páteř“, na kterou jsou následně napojeny „větve“, tedy kategorie řešení problému. Můžou to být např. oblasti hledání příčiny problému. Na větve jsou pak napojeny podkategorie, kterými můžou být typicky potenciální příčiny hledaného důsledku v dané oblasti. Následně mohou být příčiny ohodnoceny váhovým koeficientem. Výsledkem je tedy seznam možných příčin s největší váhou, u kterých je prováděna další analýza. Dalšími metodami (např. Paretovou analýzou) je možné určit pořadí ověřování jednotlivých příčin. Pokud se podařilo příčinu nalézt, je tvorba diagramu u konce, pokud ne, je nutné pokračovat v hledání dalších vazeb, kategorií a subkategorií dokud není řešení nalezeno. To může spočívat nejen v příčině jedné, ale i v kombinaci příčin. Obvykle se ale doporučuje dosáhnout maximálně dvou úrovní kategorií (např. oblast příčiny a možné příčiny), aby diagram zůstal přehledný a vypovídající.

Obr. 19 Příklad diagramu příčin a následků

Ishikawův diagram je, podobně jako myšlenková mapa, s výhodou využit při skupinové práci jako prostředek sdílení myšlenek. Jeho výhodou je kombinace grafického a informačního obsahu, ale jeho hodnota přetrvává i po vyřešení problému, neboť systém váhových koeficientů a kombinací příčin jako exaktní výsledek zkoumání, může být velmi cenným know-how s využitím a rozvojem v budoucnu.

76 | 146

Anna Exnarová

Při tvorbě tohoto diagramu je vysoce hodnocena jeho přidaná hodnota právě v ujasnění skutečných příčin problémů (a jejich důsledků). Tímto procesem dochází k ujasnění pojmů příčina a následek, ale také k jejich vztažení k časové ose. Řešení problému z pohledu příčin a následků navozuje potřebu dívat se na systém dynamicky, hledat souvztažnosti a skutečně precizně vymezit oblast řešeného problému. Obr. 19 Příklad diagramu příčin a následků na ukázkovém příkladě představuje příčiny, které ovlivňují vyřešení úkolu. Příčiny jsou rozděleny do tří skupin. Jak je v příkladu uvedené, v některých případech je vhodné využít různé slovní formulace a jazykové spojení (např. „Nestíhám!“), které mohou pomoci lepšímu porozumění, nebo pomůžou lepší zapamatovatelnosti. Diagram rybí kosti vychází z myšlenkových map a diagramu šestiúhelníku, kde byly definovány prvky. Diagram rybí kosti umožňuje navíc vymezit příčiny a důsledky (a jejich vztahy), které se v systému objevují.

3.2.8 Příčinně – smyčkové diagramy

Příčinně smyčkové diagramy (causal loop diagram, CLD) umožňují modelovat příčinnosti a tendence vývoje. Diagram kauzálních smyček je nástrojem pro vizualizaci a následnou analýzu vzájemných vlivů proměnných v modelech systémové dynamiky. Vzájemné vztahy proměnných usnadňují pochopení a kvantifikaci funkcí komplexních systémů. Konvence diagramu hladin a toků (pochází od J.W.Forrestera z roku 1961) byla založena na metafoře zásoby vody – toku vody dovnitř a ven z rezervoáru. Množství vody v rezervoáru odpovídá rozdílu objemu přítoku a objemu odtoku vody. Stejným principem funguje sledování stavu zásob jakéhokoli jiného materiálu. Využití diagramu kauzálních smyček tkví v modelování dynamických systémů. V současné době se použití diagramu kauzálních smyček rozšířilo i na modelování organizací či databází. Základními prvky diagramu jsou kauzální vztahy a kauzální smyčky. Pravděpodobně první formální použití tohoto typu modelu představil D.Meadows na konferenci „Systems Thinking & Dynamic Modeling Conference“.15 Významným propagátorem modelu je také Dr. J. Forrester z MIT’s Sloan School of Management.

15

77 | 146

Anna Exnarová

Úkoly k řešení

Aktuální datum

-

Termín odevzdání

Zbývající čas +

+ Časový tlak -

Míra vyřešení + + +

Produktivita

+

Přesčasy

Obr. 20 Příklad příčinně-smyčkového diagramu (převzato z (TMCG, 2013))

Kauzální vztah je znázorněn šipkou mezi uzly tvořící proměnné. Šipka na začátku šipky je kauzální příčinnou, zatímco proměnná na konci šipky je ovlivňovaná proměnná. Označení šipky znaménkem plus či mínus vyjadřuje pozitivní, resp. negativní závislost ovlivňované proměnné na růstu, resp. poklesu proměnné představující příčinu. Každá šipka v diagramu vyjadřuje hypotézu závislosti dvou proměnných, která by měla být objektivně ověřitelná. V okamžiku, kdy kauzální vztahy utvoří uzavřený kruh, hovoříme o kauzální smyčce. Tato situace pak reprezentuje takové chování proměnných, kdy změna jedné proměnné ovlivní jednu nebo více dalších proměnných, které pak zpětně ovlivní hodnotu původní proměnné. Zpětné ovlivnění je nazýváno zpětnou vazbou. Pokud cyklus smyčky není uzavřený, nazývá se smyčka otevřenou. Smyčky se zpětnou vazbou můžeme rozlišit na posilující (reinforcing loop, také zesilující smyčka; značené v diagramu R, RL, či +) a rovnovážné (balancing loop, vyrovnávající smyčka; značené B, BL, či -). Posilující smyčky jsou spojeny s exponenciálním růstem hodnot proměnných, zatímco rovnovážné smyčky jsou spojeny s dosažením rovnovážných hodnot. V ilustraci příčinně-smyčkového diagramu se vraťme k již uvedenému příkladu. Obr. 20 Příklad příčinně-smyčkového diagramu (převzato z (TMCG, 2013)) dokumentuje vazby mezi jednotlivými prvky systému „Řešení problému“. Na „zbývající čas“ má přímý vliv „aktuální datum“ a „termín odevzdání“, z kterých je „zbývající čas“ určen. Ten negativně ovlivňuje „časový tlak“ – čím méně je času k zpracování, tím větší časový tlak je vyvíjen. „Časový tlak“ ovlivňuje „produktivitu“ (zde záleží na konkrétním případě, protože někteří jedinci pod časovým tlakem pracují efektivněji a rychleji, někteří naopak podávají horší výkony). „Časový tlak“ rovněž ovlivňuje „přesčasy“. „Produktivita“ a „Přesčasy“ mají vliv na „Míru vylepšení“. Čím vyšší čas a větší úsilí je věnováno na řešení, tím lepších výsledků je docíleno. Při zvyšující se „Míře vylepšení“ se snižuje počet úkolů, které jsou k řešení („Úkoly k řešení“). Jejich snižování má pozitivní vliv na“Časový tlak“. Příčinně-smyčkový diagram vymezuje mezi prvky, které byly definovány v předcházejících typech diagramů, vazby a zpětné vazby.

78 | 146

Anna Exnarová

3.3 Systémová dynamika a její modely Vznik systémové dynamiky (system dynamics) má základy v systémovém myšlení. Systémová dynamika se zaměřuje na zkoumání „systémů a jejich chování v čase, je to prakticky orientované disciplína, která napomáhá našemu kvalitnějšímu poznávání okolních systémů, zejména těch, ve kterých se vyskytuje vysoká míra detailní a dynamické komplexity“. (Proverbs, 2013) Systémová dynamika byla představena v roce 1956 profesorem J. W. Forrester z MIT’s Sloan School of Management, který základy systémové dynamiky předložil ve významné publikaci „Industrial Dynamics“. Systémová dynamika je zařazována mezi tvrdší systémové přístupy oproti přístupům měkčím, představovaným především měkkou systémovou metodologií. (Checkland, 1981) Vztah systémové dynamiky a systémového myšlení není ve vědecké ani odborné veřejnosti ujednocen. V rámci této práce jsou systémové myšlení a systémová dynamika postaveny na principech systémových přístupů a vzájemně se překrývají (Obr. 21). Tento překryv obsahuje také sadu společných nástrojů, kterými mimo jiné jsou i modely příčinně-smyčkové a modely stavů a toků. Systémová dynamika je z pohledu modelů rozšířena o možnosti simulace. V dalším textu mluvím o modelech systémového myšlení a systémové dynamiky, které akcentují právě principy systémového myšlení a systémových přístupů.

Obr. 21 Systémové myšlení a systémová dynamika

Systémové myšlení je hlavním východiskem disciplíny systémová dynamika. Systémová dynamika vznikla jako východisko pro studium systémů • u nichž je zásadní proměnnou čas a proměnlivost veličin v čase, • kde je nutné studovat příčiny a důsledky chování komponent, • kde dekompozice a studium částí systému neodpovídá na otázky chování systému jako celku. Typickými příklady takových systémů jsou podle (Bureš, 2011) • sociální systémy jako rodina, organizace (firmy, státní instituce), • celky (státy, globální ekonomika). Nelze opomenout ani živé systémy (Haines, 2000), které jsou typické složitostí chování v čase, hierarchiemi a zpětnými vazbami, které jejich chování ovlivňují. Tyto situace typicky není schopen analytický přístup řešit, a to z těchto důvodů:

79 | 146

Anna Exnarová

•

• •

Analytické modely se dělí na strukturální, behaviorální a interakční. Strukturální diagramy popisují systém staticky a z principu neřeší změny systému v čase. Behaviorální diagramy ukazují chování aktérů v čase, interakční pak ukazují i časové hledisko na úrovni interakce a komunikace komponent systému. Žádný model ovšem neřeší sledování veličin systému v čase a vliv vazeb komponent na ně. Analytické modely umožňují dekompozici ale nikoli hierarchické členění subčástí. Analytické modely neumožňují modelovat příčiny a důsledky chování komponent, zpětnou vazbu.

Při modelování pomocí systémové dynamiky je nutné překonat přežívající paradigmata vnímání reality vedoucí k tradičním analytickým metodám (Mildeová, 2003), to je hlavně linearizace (tedy přílišné zjednodušení modelu) a tendence k vynechávání zpětných vazeb a zpoždění, ke kterým v systémech běžně dochází. Důvodem těchto paradigmat je to, že vnímání složitých systémů se zpětnými vazbami a zpožděními nebylo nutné až do průmyslové revoluce, nejsou tedy zcela nepřirozené našemu přirozenému myšlení. Díky nim nejsme schopni interpretovat složité dynamické jevy zcela správně. Používání systémové dynamiky v situacích souvisejících s rozhodováním managementu není nutně přímočaré, ale je to metoda, kterou je možné prozkoumat vnímanou realitu. A vytvořit efektivní a relevantní dohody na klíčových aspektech situace. Tignor (2003) uvádí, že pro tyto aktivity jsou velmi dobře použitelné modely stav a toků, které umožňují zaměřit pozornost na důležité aspekty řešeného problému a vytváří možnosti pro pochopení dynamiky situace. Sterman (2000) uvádí, že systémová dynamika může být použita pro modelování byznys procesů a k řešení složitých problémů, včetně problém a situací, kde dochází k průběžným změnám, jsou řízeny zpětnou vazbou, jsou nelineární, závislé na historii, samoorganizující a neintuitivní. Systémová dynamika se zdá, že je mocnější než běžně používané metodiky, obzvláště u dynamických a nelineárních procesů. Systémová dynamika může pomoci vyřešit problémy zpoždění a komplexity systémů, což tradiční informační systémy neumí. (Sterman, 2000) uvádí, že modelování je založeno na dynamice systémů. Obr. 22 Proces modelování (upraveno z (Sterman, 2000, str. 88)) dokumentuje iterativní systémově dynamický proces modelování (Iterative System Dynamics Modeling Process), který je založen na pěti krocích (citováno z (Chang, 2005, str. 16)): • definování problému a jeho hranic – je to o tom, co je problém a horizont času; • vytvořit mapy příčinných struktur založených na známých teoriích; • formulovat simulační model; • ve fázi testování testovat robustnost za extrémních podmínek a citlivosti; • vyhodnocení a návrh další strategie. V levé části je popsán proces systémové dynamiky (SD proces). Proces systémové dynamiky vstupuje jako jedna z aktivit do procesu modelování, který je uveden v pravé

80 | 146

Anna Exnarová

části. Efektivní modelování obsahuje neustálé opakování mezi experimenty a učením ve virtuálním světě a experimenty a učením v reálném světě. Reálný svět 1. Vyjádření problému 5. Formulace strategie a vyhodnocení

Rozhodnutí

Zpětná vazba

2. Definování hypotéz

SD proces

4. Testování

SD proces

3. Formulace Strategie, struktura, rozhodovací pravidla

Mentální modely reálného světa

Obr. 22 Proces modelování (upraveno z (Sterman, 2000, str. 88))

3.3.1 Model stavů a toků

Jazykem systémové dynamiky jsou modely stavů a toků (Stock and flow diagrams, SFD). Autorem tohoto diagramu je J. Forrester. Tyto modely slouží k vyjádření vývoje proměnných systému v čase. Základní stavební kameny tohoto diagramu jsou: • hladiny (akumulace, charakterizující stav systému, zároveň reprezentují i zpoždění); • přítoky a odtoky s ventily (vyvolávají změny hladin dané nastavením ventilů).

81 | 146

Anna Exnarová

Operační myšlení (jedna z dovedností systémového myšlení) může být modelováno právě pomocí diagramů stavů a toků (viz Obr. 23 Příklad diagramu stavů a toků). V předešlých diagramech ukázkového příkladu byly identifikovány prvky, diagram stavů a toků k těmto prvkům doplňuje informaci o změně stavů v čase. Tento typ diagramu umožňuje modelovat entity systému, pomocí zpětněvazebných smyček kauzalitu a příčiny a následky, vazby mezi proměnnými. Diagram hladin a toků by měl modelovat systém tak jak ve skutečnosti existuje, dokumentovat reálné vazby a vztahy. úsilí

Úkoly k řešení

míra vyřešení

Vyřešené úkoly

produktivita aktuální datum přesčasy zbývající čas

časový tlak

termín odevzdání

Obr. 23 Příklad diagramu stavů a toků (převzato z (TMCG, 2013))

Modely stavů a toků umožňují pracovat s následujícími prvky diagramů (částečně převzato z (Molnár, 2012, str. 80)). • Hladina (stock) – proměnná, která akumuluje změny. • Tok (flow) – stavební bloky, které ovlivňují hladiny, zaznamenávají transformaci z jedné hladiny do druhé. • Sektor (sector) – všechny struktury, které jsou vázané na jednu hladinu. • Informační spoj (information) – vazba, která přenáší informace z jedné proměnné do druhé. • Konstanta – statická proměnná obsahující konstantní hodnoty. • Mrak – entita zaznamenávající přítok nebo odtok za hranicí modelovaného systému. Důležitou vlastností diagramu stavů a toků je možnost jeho rozšíření pro tvorbu simulací systému, kdy výsledkem je např. grafické vyjádření hladin systému v čase. Simulace je vlastně analytický postup, který umožňuje ukázat, jakým způsobem se bude systém vyvíjet, pokud se změní některé jeho části, či hodnoty vybraných parametrů. (Bureš, 2011) Latinské slovo simulare znamená „imitovat“ nebo „napodobovat“. Účelem simulačního modelu je napodobení chování reálného systému, aby mohlo být zkoumáno. Simulační model (většinou formou počítačového programu) při svém chodu napodobuje podstatné stránky modelovaného systému. (Mildeová, 2007, str. 14)

82 | 146

Anna Exnarová

„Tvorba simulátorů povede vás jako tvůrce (a následně uživatele) k posunu od jednosměrné ke kruhové příčinnosti, od nezávislých faktorů k vzájemně závislým, kde faktory nemají statickou váhu. Tj. posunu od pohledu na svět jako na soubor statiky a vztahů akce či reakce k pohledu na svět jako na trvající, vzájemně závislý, sám sebe podporující dynamický proces. Takovýto přístup následně umožňuje přemýšlet jiným způsobem o tom, co se děje v našem okolí.“ (Mildeová, 2007, str. 9)

Simulace prováděné pomocí modelů, které lze vytvořit pomocí různých programů, jsou velice prospěšné. Umožňují (Exnar, 2009): • ověřit hypotézy o chování systému v závislosti na zkoumaných skutečnostech, • sledovat, které změny vytváří jaké důsledky a v jaké míře, • testovat různá opatření pro zlepšení chování systému, • prozkoumávat aspekty a neočekávané důsledky jednotlivých opatření.

83 | 146

Anna Exnarová

4 UPLATNĚNÍ SYSTÉMOVÉHO MYŠLENÍ V ANALYTICKÉ FÁZI VÝVOJE IASW Čtvrtá kapitola disertační práce je rozdělena do dvou částí. V první části je představen současný stav poznání a zmíněny relevantní publikované výzkumy ve světové literatuře. Spojení systémového myšlení a systémové dynamiky s vývojem IASW (potažmo softwaru) je v odborné literatuře poměrně novým tématem. Aplikace systémové dynamiky byla od počátku zaměřena do oblasti měkkých a komplexních systémů (především socio-ekonomické systémy). Nicméně ve světové literatuře jsou publikovány také výzkumy související s aplikací systémové dynamiky v oblasti informatiky. Výzkumy a publikace jsou zaměřeny především na komparaci principů systémové dynamiky s principy analytického či objektově orientovaného přístupu a na analýzu styčných ploch modelů systémové dynamiky a modelů dle notace UML. Zveřejněných výsledků výzkumů je ale poměrně málo a ve všech případech jsou zaměřeny pouze na systémovou dynamiku. Z pohledu české literatury je toto téma nové a nebylo dosud uceleně publikováno. Pro úplnost nutno podotknout, že spojení systémové dynamiky s procesním pohledem na organizaci, informační systém či vývoj informačního systému je rozpracováno ve větší míře a to jak v české tak zahraniční literatuře16.

V této kapitole uvádím zde některé aplikace spojení systémové dynamiky a UML zkoumané v kontextu informačních systémů. Z pohledu české literatury je toto téma nové a nebylo dosud uceleně publikováno. Na základě těchto publikovaných výsledků je v druhé části kapitoly představen vlastní návrh uplatnění systémového myšlení v analytické fázi vývoje IASW. Zároveň do tohoto návrhu vstupují informace a znalosti, které byly uvedeny v předešlých kapitolách. Pro návrh jsou diskutovány podmínky, za kterých je vytvářen. Návrh aplikace systémového myšlení je založen na uplatnění modelů systémového myšlení a systémové dynamiky. Z tohoto důvodu je pozornost zaměřena na jednotlivé typy modelů – pro každý typ modelů jsou uvedeny jeho přínosy použití. Na závěr jsou diskutovány možnosti dalšího rozšíření i v jiných fázích vývoje IASW. 4.1 Stav poznání Spojení systémové dynamiky – potažmo jejich modelů s modely UML bývají diskutovány z pohledu vývoje informačních systémů, ale také ve vazbě na jiné obory. Například v publikaci (CLENDENING, 2009) jsou řešeny problémy z oblasti ekologie (predikce dopadů hurikánu). V této práci je publikována metodika pro sjednocení funkční analýzy se systémovou za použití modelů UML a modelů systémové dynamiky s cílem popsání znalostí o chování systému.

16

Spojení procesních modelů (např. dle notace BPMN) s modely systémové dynamiky je za vymezenými hranicemi této práce.

84 | 146

Anna Exnarová

Spojení UML a systémové dynamiky pro analýzu systému používá např. (Grasl, 2008). Ve své práci představuje analýzu byznysového modelu. Využívá jednak modelů UML pro modelování struktury a chování a také systémovou dynamiku pro modelování dynamiky a simulaci systému. Nicméně studie se nezabývá informačním systémem.

Poměrně bohatou diskusi spojení systémové dynamiky a informačních systémů přináší ve své publikaci Chang. Chang (2005) konstatuje, že přes všechny výhody, systémová dynamika nepatří k rozšířeným modelům softwaru a uvádí návrhy, jak je možné dosáhnout propojení těchto dvou oborů. Ve své práci diskutuje spojení objektově orientované analýzy a designu (OOAD) a systémové dynamiky. Objektem rozumí kombinaci stavů a metod, které ztělesňují abstrakci chování. Hlavní vlastností OOAD, kterou Chang uvádí, je kombinace dat a chování zapouzdřených do tříd. Třídy se tedy skládají z atributů a metod a představují interní strukturu objektů. Z pohledu softwaru jsou atributy data či informace získaná z databáze nebo od uživatelů. Metody obsahují akce, popis chování, nebo změny stavů tříd. Vlastnosti OOAD dává Chang porovnává s principy systémové dynamiky. Modely systémové dynamiky rovněž modelují entity, jejich stavy, chování, reakce na základě vnějších podnětů. Výsledky detailní komparace obou přístupů Chang dokumentuje v tabulce (Tab. 4). Tab. 4 Porovnání atributů systémové dynamiky a objektově-orientovaného přístupu (Chang, 2005)

Komponenta systémové dynamiky

Objektově orientovaný koncept

Sektor (sector)

Třída (class)

Hladina (level, stock)

Atribut (attribute)

Tok (rate, flow)

Metoda (operation, behavior)

Pomocná proměnná (auxiliary)

Atribut(attribute)

Chang dále porovnává vývojový proces systémové dynamiky a RUPu. Uvádí, že existuje mnoho podobných fází, které si vzájemně odpovídají. Disciplíny RUP úvodní plánování, byznys modelování, sběr požadavků a analýza doplňuje diagramy UML o diagramy příčin a následků. Pro disciplíny návrh, implementace, testování a nasazení využívá diagramu hladin a toků. Uvádí, že pro oblast testování neexistuje žádný základní UML diagram, a právě diagramy hladin a toků můžou být nástrojem pro vytvoření modelů testů a nasazení. Dokumentace porovnání fází RUP a systémově dynamického procesu modelování je uvedena v Tab. 5 Integrovaný proces vývoje (Chang, 2005, str. 16).

85 | 146

Anna Exnarová

Tab. 5 Integrovaný proces vývoje (Chang, 2005, str. 16)

Rational Unified Process

Systémově dynamický proces modelování

Diagramy systémové dynamiky a UML

Úvodní plánování (initial planning)

Definování problému a jeho hranic

Diagram případů užití

Byznys modelování (business modeling)

Vytvoření hypotéz

Diagram případů užití

Sběr požadavků (requirements) Analýza (analysis)

Diagram případů užití Diagram příčin a následků Formulace

Návrh (design)

Implementace (implementation)

Diagram komponent Sekvenční diagram Diagram aktivit Diagram stavů Diagram hladin a toků Testování

Testování (test) Nasazení (deployment)

Diagram tříd Diagram objektů Diagram spolupráce Diagram příčin a následků

Diagram nasazení Diagram hladin a toků Diagram hladin a toků

Vyhodnocení

Diagram hladin a toků

Ve své práci Chang rovněž zdůvodňuje a navrhuje, že pro úspěšnou implementaci systémové dynamiky v organizaci je nezbytně nutné jí (resp. její simulační modely) integrovat do byznysově orientovaného informačního systému. Integrací systémové dynamiky rozumí využívání modelů a výsledků simulací jako integrální součásti běžných činností manažerů. Nejlepší cestou integrace je spojení vývoje informačního systému přímo s implementací systémové dynamiky. Tento cíl je dosažen pomocí integrace UML modelů, business procesů a systémově dynamických modelů. Chang (2005) navrhuje vytvořit integrované informační systémy, které by obsahovaly nejen tradiční Transaction Process System (TPS), Management Information Systems (MIS) a Decision support Systems (DSS), ale kombinací s modely a simulačními modely systémové dynamiky by tyto systémy poskytovaly data pro rozhodování (viz Obr. 24 Integrovaný informačný systém (Chang, 2005, str. 17)).

86 | 146

Anna Exnarová

Obr. 24 Integrovaný informačný systém (Chang, 2005, str. 17)

Chang uvádí na závěr práce následující doporučení: pokud organizace chtějí aplikovat systémovou dynamiku a úspěšně ji využívat pro řešení problémů, musí jí integrovat s informačním systémem. (Chang, 2005)

V souladu se závěry Changa rozpracovává ve své práci také Hu možnosti, jak je možné systémovou dynamiku aplikovat ve firemním prostředí. Vychází z omezení, že modely systémové dynamiky jsou úzce vázané na prostředí, ve které jsou tvořeny. Pro skupinu uživatelů na úrovni managementu (tzv. „decission-maker“ a příp. další) samozřejmě není možné, aby bylo požadováno používání přímo nástroje, ve kterém jsou modely vytvářeny. Jednou z variant, jak těmto uživatelům zpřístupnit modely (nebo výsledky simulací) je předložením studie, publikováním výsledků na interním portálu firmy, či využitím např. prostředků pro zprostředkování těchto modelů – tento návrh je uveden v publikaci (Hu, 2011).

Dalším autorem, který se dlouhodobě zaměřuje na spojení UML a systémové dynamiky a v této oblasti realizoval ucelenější výzkum, je W. Tignor. Tignor (2003) ve svém příspěvku diskutuje možnost spojení UML diagramu aktivit a diagramu hladin a toků systémové dynamiky a jejich možnou synergii. Ke spojení těchto dvou přístupů vedl pokus o uplatnění čistě UML v konkrétním případě, který nebyl úspěšný. Ve vybraném případě bylo důvodem ohrožení efektivní komunikace mezi zákazníkem a programátory. UML produkuje statické, detailní modely neumožňující simulaci. UML produkuje podklady, které se dají plně použít pro tvorbu softwaru. UML poskytuje standardní způsob psaní systémového návrhu, pokrývající konceptuální (konkrétní byznysové procesy a systémové funkce), stejně jako konkrétní položky jako jsou třídy, napsané ve specifickém (programovacím) jazyce, databázové schémata a softwarové komponenty. Naproti tomu modely systémové dynamiky umožňují vytvářet dynamické, spustitelné simulační modely. Tignor uvádí, že nejdříve by měly být pomocí systémové dynamiky identifikovány kritické procesy, které je nutné vylepšit a až následně použity modely UML. Systémově dynamický model je základ, poskytuje informaci o chování systému a identifikuje problematické místa, které vyžadují detailnější analýzu. Systémově dynamické modely dle Tignora tedy: • ujasňují priority a identifikují kritické procesy ke zlepšení; • identifikuje různé strategie implementace a zkoumá jejich efekt na systém jako celek; • vytváří sdílený konsensus mezi lidmi o jedné nebo všech výše uvedených věcech. 87 | 146

Anna Exnarová

Tignor (2003) ve svém příspěvku představuje také hlavní charakteristiky aktivity diagramu UML a diagramu systémové dynamiky hladin a toků, a následně uvádí návrh na jejich spojení. Aktivity v diagramu aktivit jsou to samé co toky v diagramu hladin a toků. Tedy aktivity z UML diagramu „přenesl“ do diagramu systémové dynamiky (viz Obr. 25).

Obr. 25 Diagram hladin a toků SD založen na diagramu aktivit UML (Tignor, 2003, str.8)

Domnívám se, že i vzhledem k dále neuveřejněným výsledkům avizovaného následného výzkumu, není možné striktně (automaticky) převádět aktivity z diagramu aktivit do diagramu hladin a toků. Ale je vhodné a možné tyto entity z těchto dvou diagramů dát do kontextu a porovnat, zda diagram SD nepřinesl entity, které diagram aktivit nepodchytil. Nicméně v úvodu práce Tignor diskutuje (a uvádí související citace dalších autorů) fakt, že diagram hladin a toků by měl být jakýmsi výchozím podkladem pro detailnější modelování, měl by ujasnit priority a identifikovat kritické procesy, které jsou dále pomocí UML zpracovány do konkrétních analytických výstupů. Synergie použití těchto dvou modelů je jednoznačně v uplatnění principů systémového myšlení při analýze, zapojení dynamického pohledu na problematiku, akcent zpětněvazebných smyček, vztažení systému do časové osy.

Tignor (2004) řeší otázku, zda je potřeba nového jazyka, když systémová dynamika vznikla kvůli tomu, aby simulovala. Pokud strukturu informačního systému a jeho chování je možné pospat UML, je možné tyto popisy přeložit do jazyka systémové dynamiky? Tignor představuje UML z pohledu možné přeložitelnosti do modelu systémové dynamiky (konkrétně při použití produktu firmy Vensim). Hrubým porovnáním výsledků simulace jsou podobné výsledků, které vytvořil pomocí SimML17. Použití systémové dynamiky k modelování architektury a návrhu informačního systému před implementací má potenciálně významný vliv na úsporu nákladů a dodržování termínů. Nicméně Tignor konstatuje, že systémová dynamika potřebuje vytvořit 17

SimML je speciálně upravený koncept UML pro vytváření simulací. Nicméně použití v praxi ani v odborných publikacích pro vývoj softwaru není velký a je poměrně náročné získat relevantní údaje. Je používán spíše v oblasti související se znalostním inženýrstvím.

88 | 146

Anna Exnarová

rozhraní do svých simulačních jazyků, které bude akceptovat UML (nejspíše pomocí standardu XML). Ucelené rozhraní mezi UML a simulačními jazyky je nutné, jinak vzniknou nové specializované jazyky, které budou duplikovat a konkurovat jazykům systémové dynamiky. Uvedené závěry vychází z dlouhodobého zkoumání této oblasti. Tignor v publikaci (1999) představil návrh porovnání objektově orientovaného přístupu (OO) a systémové dynamiky (SD) (viz Tab. 6 Objektově orientovaný přístup a relevantní pohled systémové dynamiky (Tignor, 1999)). Autor uvádí, že systémová dynamika a softwarové inženýrství mají stejné nebo podobné problémy, hlavně při komunikaci se zákazníkem. Proto byl v objektově orientovaném přístupu vyvinut jazyk UML, který měl pomáhat s touto komunikací. V práci uvádí návrh jak UML je možné rozšířit a zlepšit jeho použití za pomocí současného využití systémové dynamiky. Tignor práci uzavírá s konstatováním, že existuje silná vazba mezi systémovou dynamikou (potažmo jejími modely) a softwarovým inženýrstvím a jejich propojení může vést k signifikantním zlepšením výsledků procesu vývoje softwaru. Tab. 6 Objektově orientovaný přístup a relevantní pohled systémové dynamiky (Tignor, 1999)

OO/SD

Popis problému

Případ užití (use case)

X

Diagram případů užití (use case diagram)

X

Diagram tříd

Příčinně smyčkový diagram

Diagram hladin a toků

X

X

Diagram balíčků

X

Diagram aktivit

X

Závěrem uvádím doporučení, kterým Tignor (2003) uzavírá svou práci: zcela určitě pro úspěch projektu ale platí, že není vhodné měnit strategii (tj. zapojení systémové dynamiky) v průběhu projektu.

89 | 146

Anna Exnarová

4.2 Uplatnění systémového myšlení v analytické fázi vývoje IASW prostřednictvím modelů systémového myšlení 4.2.1 Důvody vytvoření návrhu

Jak již bylo v úvodu konstatováno, výsledná zpráva výzkumného projektu „CHAOS“ Standish Group z roku 2011 (Schwaber, 2012) uvádí, že více než polovina SW produktů vytvářených v letech 2002 až 2010 byla vyhodnocena jako pozastavená nebo předčasně ukončena. Pouze 37% projektů bylo zařazeno do kategorie úspěšných implementací (ve smyslu dodržení ceny, termínu a dodání požadované funkcionality). Dle studie Standish Group citované v (Yap, 2011) se až 64% implementovaných funkcí nikdy nepoužije nebo jejich použití je vyjímečné. Dle závěrečné zprávy projektu „CHAOS“ z roku 2007 (AS, 2013) je úspěšných IT projektů 35%, neúspěšných projektů je 19%. Přehled o vývoji úspěšnosti softwarových projektů dle dílčích zpráv projektu „CHAOS“ uvádí přehledně ve své publikaci Bruckner (2012), dlouhodobý trend úspěšnosti se zlepšuje, Bruckner odkazuje zejména na aplikaci různých standardů a metodik. Samozřejmě vždy u všech statistických údajů je nezbytné věnovat pozornost metodice výzkumu a správně interpretovat uvedená data. Nicméně z jakéhokoliv úhlu pohledu je možné konstatovat, že projekty vývoje informačních systémů, či jejich částí v podobě dílčích softwarů, vykazují velkou míru neúspěšnosti a potýkají se neustále se zásadními problémy. V různých publikacích se uvádí nejrůznější žebříčky „top x“ faktorů, které ovlivňují výsledek projektů. Tyto seznamy bývají velmi podobné a často obsahují následující seznamy (AS, 2013): • nekompletní nebo měnící se požadavky, • malé zapojení koncových uživatelů, • nízká dostupnost zdrojů pro realizaci, • nereálné očekávání, • malá podpora managementu organizace, • malá podpora IT managementu, • nedostatek plánování, • systém nebo aplikace jsou již nepotřebné, • nevyzrálá technologie, • jiné důvody. Dílčí problémy, které nakonec vedou k neúspěšnosti IT projektů, je možné zařadit do různých kategorií (tyto kategorie vycházejí z uvedených aspektů projektů). S tím souvisí i kategorie opatření, které se dlouhodobě v IT projektech snaží odborná veřejnost uplatňovat, s cílem výrazného zlepšení úspěšnosti projektů. Jak již bylo zmíněno v prvním odstavci, podle studie „CHAOS“ z roku 2007 (AS, 2013) je 19% projektů neúspěšných. Z tohoto objemu je 50% projektů neúspěšných, protože realizované řešení nevyhovovalo byznysovým požadavkům, v 80% případů bylo vyhodnoceno, že projekt byl neúspěšný, protože vycházel z požadavků, které nebyly vhodně uchopeny. Důvody toho, že ve výsledku požadavky nevyhovují potřebám

90 | 146

Anna Exnarová

byznysu nebo jsou nevhodně zpracovány, je možné spatřovat v různých aspektech projektu. S určitou mírou zjednodušení lze říci, že neúspěchy projektů velmi úzce souvisí se schopností úspěšně definovat požadavky a úspěšně a efektivně realizovat analytické činnosti. (Další nástrahy a možné příčiny neúspěchu na projekt samozřejmě číhají v dalších činnostech.) Výsledky publikovaných výzkumů, mé znalosti z oblasti vývoje informačních systémů i systémových věd a vlastní zkušenost z praxe z pozice analytika i projektového vedoucího byly důvodem zaměření mé pozornosti právě na oblast analýzy a práci s požadavky. Domnívám se, že nejvýrazněji se krystalizují jako příčiny problémů faktory související s komplexitou systému, dynamickým chováním, schopnosti správné komunikace a sdílení znalostí. Informační systémy jsou systémy komplexní, jejich složitost roste s počtem integrovaných prvků, a to jak technologických a technických, tak sociálních. Zcela přirozeně se v nich vyskytují jevy, které souvisí s dynamikou celého systému, běžně zde lze najít množství zpětných i příčinných vazeb. Všechny tyto aspekty ukazují na vhodnost využít systémové dynamiky a systémového myšlení při vývoji i řízení informačních systémů.18

Výše uvedené výzkumy jsem použila pro definování souboru faktorů, které mohou ovlivňovat úspěšnost vývoje IASW. Faktory, které mohou způsobit neúspěšný vývoj IASW, člením do následujících okruhů problémů: • Požadavky na cílové chování nejsou správně definovány, jejich popis není úplný a fakticky správný. Důvodem může být např. neznalost prostředí, špatná komunikace a rozdílná znalost komunikujících stran (řešitele a zadavatele). Významným faktorem může být nedokonalost procesu transformace tacitních a explicitních znalostí (viz diskuse k Obr. 15). • Struktura i výčet požadavků se mění. Příčinou může být špatná komunikace řešitele a zadavatele, ale i opomenutí měnícího se okolí systému a potlačení jeho dynamických vlastností. • Chybné vytipování klíčových bodů, upřednostnění bezvýznamných funkcionalit, zaměření pozornosti na domnělé cíle, které neodpovídají realitě. V průběhu analýzy musí řešitel správně pochopit a uchopit očekávanou funkcionalitu systému. Klíčovým faktorem je tedy vytvoření si správného modelu znalostí, úprava a korekce mentálního modelu dle reality a zpětných vazeb od zadavatele (uživatelů). • Nerespektování skutečných vazeb systému na jeho okolí, spokojení se s hrubou analýzou, neprozkoumání zdánlivě nevýznamných či nemožných interakcí bývá

18

V případě, že bychom uvažovali pouze o vývoji aplikace (tedy zaměřili bychom pozornost pouze na vývoj „technické“ – softwarové a hardwarové části IS, bez akcentu na měkké části systému), je přístup za pomoci systémového myšlení rovněž užitečný. Aplikace může být izolována od ostatních SW a ICT, ale vždy existuje v reálném světě, člověk vystupuje v roli tvůrce a uživatele. Aplikace z pohledu procesů slouží k automatizaci vykonávání dílčích činností v reálném světě. Komplexitu a další systémové faktory není možné vynechat ani u malých aplikací.

91 | 146

Anna Exnarová

příčinnou pozdního odhalení dalších požadavků na vytvoření vazeb, nebo např. nastavení reakcí na konkrétní podnět. Tyto faktory byly podkladem pro hlubší analýzu problémů, které ovlivňují vývoj IASW. Následující tabulka uvádí možné příčiny neúspěchů vývoje IASW. Tab. 7 Vybrané příčiny neúspěchu vývoje IASW

Neúspěch vývoje SW Požadavky • Neznalost řešitele systému jako celku, soustředění se pouze na dílčí vybrané faktory, které avizuje zadavatel • Měnící se nebo nekompletní požadavky • Nevhodná, zavádějící formulace zadání • Nevyhovující komunikace týmů zadavatele a řešitele • Nerealistická očekávání • Nepochopení zadání Komplexita systému • Neakceptování systémové hierarchie - rozpad systému na dílčí části a řešení jednotlivých oblastí a jejich vlastností individuálně • Neakceptování zpětněvazebních smyček systému • Neuvažování o emergentních vlastnostech celku • Neakceptování vazeb systému a jeho okolí • Neakceptování dynamiky systému Cíle systému • Ukazatele, parametry, které měly být klíčové se nesledují • Je řešeno podrobně něco co mělo být pouze okrajové, a naopak řešení klíčových otázek je povrchní • Neřešena skutečná potřeba, ale potřeba, která byla objevena v průběhu analýzy a je domnělá, neodpovídá skutečnosti Informace, znalosti • Rozdílné znalostní struktury řešitelského a zadavatelského týmu • Rozdílné "jazyky" zadavatele, uživatele, vývojového týmu • Neochota řešitele "opustit" myšlenku způsobu řešení i když není v souladu s požadavky • Nízké zapojení koncových uživatelů

V Tab. 7 uvádím příčiny, které vstupují do vývoje IASW a mohou být důvodem jeho neúspěchu. Příčiny jsou rozděleny do čtyř skupin: cíle systému, požadavky, informace a znalosti, komplexita systému. Tyto skupiny přímo akcentují možnost a vhodnost použití

92 | 146

Anna Exnarová

systémového myšlení pro zkoumání těchto příčin. Uvedené příčiny jsou orientovány především na měkké části systému. Jak je tedy možné zefektivnit analytické činnosti? Je možné uvedené příčiny odstranit, či aspoň zmírnit jejich dopady? Domnívám se, že uvedená identifikace problémů nabízí jako řešení uplatnění systémových přístupů – konkrétně systémové dynamiky a systémového myšlení. Aplikace systémových přístupů v praxi znamená, že při běžně realizovaných činnostech budou akcentovány již uvedené a diskutované jednotlivé systémové vlastnosti. Samozřejmě je možné, aby člověk, který má již dlouhodobé zkušenosti a dovednosti, aplikoval tyto principy v průběhu obvyklých činností. Většina lidí ale potřebuje pro osvojení používání nástrojů, které umožní, pomůžou a „donutí“ akcentovat systémový přístup, např. systémovou hierarchii nebo zpětné vazby. Těmito nástroji, které poskytuje systémové myšlení a systémová dynamika, jsou právě jejich modely. Vytvářený model plní dvojí funkci: • jeho tvorba podporuje uplatnění systémového myšlení, • a zároveň při zpětném ověřování je možné modely systémového myšlení (myšlenkové mapy, rybí páteře, či příčinně-smyčkové diagramy) použít jako jednoduché diagramy pro komunikaci.

Jak již bylo diskutováno, pro popis procesů existují specifické notace. V souvislosti s procesním pohledem na systém a vymezením hranic disertační práce považuji za nutné uvést pár komentářů. Kombinace modelů dle notace UML a vybrané techniky popisu procesů je běžnou praxí. Notace UML neobsahuje dostatečně silný aparát pro popis modelů, proto dochází v praxi k této kombinaci. Použití dvou notací souvisí rovněž z objektovým a procesním přístupem k popisu systému. Nicméně nepodařilo se mi dohledat výzkum, který by uváděl, že spojení konkrétního typu procesního modelování a UML by dokázalo odstranit problémy, které vedou k neúspěchům vývoje IASW. Domnívám se, že je možné vytvořit model systému za použití • objektového pohledu založeného na diagramech notace UML a • procesního pohledu, který by byl zastoupen modely systémového myšlení a systémové dynamiky (konkrétně příčinně-smyčkovým diagramem a diagramem hladin a toků). Popis procesů informačního systému je vždy v úzké souvislosti s popisem procesního modelu celé organizace. Ne vždy je ale k dispozici procesní model organizace a jeho rozpad na příslušné relevantní úrovně. Pro modelování informačního systému je v tomto případě nutné vytvořit „fingované“ modely procesů v organizaci a na nich stavět procesy informačního systému. Domnívám se, že díky charakteristice příčinněsmyčkových diagramů, jsou tyto typy diagramů pro analýzu a modelování procesů vhodnější.

93 | 146

Anna Exnarová

Tvorba procesního modelu organizace, i celého informačního systému, je velmi náročnou disciplínou. Velmi obtížné je nastavení správných úrovní podrobností a správné zaměření pozornosti. Pokud při vývoji informačních systémů neparticipují zkušení procesní analytici, může špatně zvolený procesní model velmi negativně ovlivnit celý následný proces vývoje IASW. Obdobně jako u předchozího komentáře, i zde se domnívám, že příčinně-smyčkový diagram poskytuje nástroj, který umožní procesy modelovat a může být díky svým vlastnostem efektivnější. V návrhu uplatnění systémového myšlení v analytické fázi vývoje IASW je popis procesů realizován pomocí notace modelů systémového myšlení a systémové dynamiky, příp. dle notace UML.

4.2.2 Podmínky návrhu uplatnění systémového myšlení v analytické fázi vývoje IASW

V kapitole 2.1.5.2 – Informační systém a byly řešeny jednotlivé aspekty informačního systému, aplikace a jejich projektů. V návaznosti na uvedené poznatky jsou v předkládaném návrhu použity následující předpoklady. Dimenze systému (vychází z dimenzí vývoje IASW), které je možné postihnout návrhem: • Obchodní aspekty nejsou řešeny. • Technologické aspekty aplikace návrh pokrývá, zapojuje tento pohled do jednotlivých typů diagramů (dle UML, příp. je možné i pomocí diagramů systémového myšlení či systémové dynamiky). • Procesní aspekty aplikace, potažmo systému, ve kterém bude aplikace implementována, jsou řešeny jak standardními diagramy UML, tak diagramy systémového myšlení i systémové dynamiky. • Sociální a informační aspekty aplikace, potažmo systému jsou řešeny ve smyslu modelování komunikace, modelování interpersonálních vztahů pomocí diagramů systémového myšlení. Komunikaci ve smyslu zabezpečení komunikace pomocí navrhované aplikace je možné modelovat rovněž pomocí diagramů UML. • Organizační aspekty vývoje IASW mohou mít velmi košatou strukturu týmů na straně dodavatele i zadavatele. Role a strany, které bývají definovány jsou např. zadavatel, dodavatel, sponzor, objednatel, řešitelský tým, klíčoví uživatelé, atd. Dále v této práci bude použito výrazné zjednodušení celé organizační struktury projektu: vymezuji pouze dvě skupiny: stranu dodavatelskou (řešitelskou, s techniky orientovanými pracovníky), a strana objednatele (zadavatele), jejíž členové mají především znalosti procesní a byznysové. Modely systémového myšlení a systémové dynamiky umožňují v rámci jednoho diagramu zobrazit vztahy mezi prvky z různých dimenzí, např. dimenze technologie ve vazbě na dimenzi organizačně legislativní, v UML je tato možnost omezenější. Model životního cyklu vývoje softwaru je použit iterativní vývoj a metodikou je Unified Process (viz podkapitola

94 | 146

Anna Exnarová

Metodika Unified Process). Jak již bylo uvedeno, v kontextu této práce je pojem analytická fáze vývoje IASW označením spojení dvou disciplín „Sběr požadavků“ a „Analýzy a návrh“z metodiky UP. Na základě nejrozšířenějších aktuálních přístupů je tento návrh založen na předpokladu použití objektově-orientovaného přístupu pro vývoj IASW. Vzhledem k definovaným hranicím výzkumu pouze na analytickou fázi vývoje IASW, návrh nediskutuje a neřešení etapy následující po ukončení vývoje IASW a jeho nasazení do produktivního provozu – tj. nejsou řešeny otázky provozu, udržování a ukončení provozu. V první iteraci jsou vytvářeny jednotlivé diagramy modelu systému, v každé další iteraci jsou některé diagramy dle potřeby zpřesňovány, doplňovány, nebo vytvářeny nové. Pro diagramy dle notace UML se jedná především o vytváření nových diagramů (v návaznosti na rozšíření funkcionality v každé iteraci). Diagramy systémového myšlení lze jejich zaměření jsou buď pouze aktualizovány, nebo vytvářeny nové. Vzhledem k tomu, že iterativní životní cyklus nedefinuje způsoby rozdělení řešení na jednotlivé iterace, budou určitě existovat situace, kdy druhá a další iterace budou pouze doplňovat existující diagramy, a situace, kdy budou vznikat zcela nové. Návrh nediskutuje zapojení rolí v analytické fázi projektu. Předpokládá, že v analytické fázi vývoje IASW jsou zapojeni především analytici (se zaměřením na procesy, byznys, detailní funkční specifikaci, nebo návrh), architekti a příp. designéři. Analytici jsou tvůrci návrhu řešení, dokumentace a tedy i modelů. Ve většině případů budou další členové týmu (testeři, programátoři, projektoví manažeři a i členové týmu zákazníka) uživateli těchto modelů. Z pohledu dalších disciplín UP (např. Řízení projektu) je možné využití jak systémového myšlení a tak jeho modelů. Největší požadavky jsou kladeny na analytika (zaměřeného na business i detailní funkční specifikaci), architekta, designéra, testera. Tyto role v různých fázích modely tvoří, upravují nebo verifikují. Druhá skupina členů týmů, kam zařazuji projektového manažera, zadavatele, vývojáře, je pouze příjemcem modelů ve formě zadání práce nebo ve formě dokumentace. (V kapitole 2.1.5.1 – Organizace byly diskutovány a uvedeny základní kategorie týmu – zadavatel a řešitel).

4.2.3 Uplatnění jednotlivých typů modelů v analytické fázi vývoje IASW

V následující podkapitole jsou uvedeny vybrané typy modelů, které je možné využít v analytické fázi vývoje IASW. Pozornost je zaměřena na modely systémového myšlení a systémové dynamiky. Vzhledem k tomu, že návrh je založen na použití těchto modelů zároveň s modely UML, jsou zde stručně diskutovány i vybrané modely dle notace UML. (Exnarová, 2013) Mentální modely

Prvním modelem, který je nutné v souvislosti se systémovým myšlením zmínit, jsou mentální modely. Tedy modely, které jsou vytvářeny kognitivním procesem v myslích tvůrců. Samozřejmě, že jejich používání je automaticky a není možné je vyčlenit.

95 | 146

Anna Exnarová

Při použití systémového myšlení je ale potřebné jeho existenci akcentovat – a to v tom smyslu, že tvůrce musí vědomě pracovat s tímto modelem, a na základě dalších modelů aktivně přistupovat k jeho aktualizaci a revizi. Tyto modely jsou klíčovým faktorem v celém návrhu, v komunikaci s ostatními členy týmu, ve sdílení myšlenek a informací, významně zde vstupuje znalostní proces SECI diskutovaný v kapitole 3.1.3.

Specifikace požadavků, model požadavků

Fáze specifikace požadavků (standardní fáze UP) z mého pohledu zahrnuje také vytvoření či rozbor vlastního zadání. Tyto činnosti z pohledu projektu (ve smyslu ohraničené skupiny aktivit vývoje a implementace aplikačního vybavení) často bývají mimo projekt, v případě, že jsou vstupem pro jeho start, nebývá možná jejich změna. I v tomto případě je ale potřebné, aby řešitelský tým tuto oblast analyzoval. Prvním krokem, který UP definuje, je práce s požadavky. Tradiční metoda soupisu požadavků obsahuje vytvoření seznamu požadavků formou textové specifikace v dokumentu, dále konzultace, dotazníkové šetření a workshopy s (klíčovými) členy zadavatelského týmu. Tyto aktivity jsou podkladem pro tvorbu katalogu požadavků. Model požadavků může být reprezentován i graficky pomocí diagramu požadavků, který obsahuje jejich výčet, příp. jejich vazby, a umožňuje je seskupovat do balíčků požadavků. Aplikace uvedených modelů se odvíjí od konkrétních podmínek, preference tvůrce. Vytvářením a současným používáním více modelů, či jejich revizí dochází k synergickému efektu a jsou vytvářeny vzájemně kompatibilní ověřené výstupy.

Myšlenkové mapy (mind mapy)

Ve fázi specifikace požadavků je vhodné vytvořit modely typu myšlenkové mapy, které: • popisují potřeby řešení; • deklarují důvody vzniku systému; • v případě složitějších interakcí dokumentují očekávané potřeby dle uživatelů; • popisují chování systému; • dokumentují dotčené komponenty systému; • nastiňují možné vazby na okolí. Potřeba, která vyplývá z účelu systému a jeho vztahu s okolím. Potřeba není pouze to, když „někdo říká, že něco potřebuje“. Model by měl otestovat to, co říká zadavatel. Měl by tedy vytvořit jakési porovnání toho, zda zadavatel na něco nezapomněl. Z těchto modelů může plynout také potřeba redefinice nebo doplnění výčtu požadavků na systém. Tvořením a následnou diskusí lze opětovně ověřit to, zda je realizován požadovaný systém a potřeba jeho vzniku je reálná. Tedy jde o pokus odstranění jednoho k top -10 faktorů – vývoj nepotřebného softwaru nebo funkcionality.

96 | 146

Anna Exnarová

Důsledky existence těchto modelů jsou (mohou být): • revize požadavku na vytvoření systému, • revize rozsahu projektu a cíle, • revize (doplnění nebo zrušení) seznamu požadavků, • opětovná diskuse se zadavatelem o cílech a očekáváních, • zjištění potřeby externích konzultací o okolí systému, pro které nemáme dostatek informací, • vytipování parametrů, které vyplývají ze specifikace požadavků, a které budou použité pro tvorbu případů užití, • identifikace bodů, které je případně nutné zpracovat pomocí vybrané notace procesního modelování.

Rybí páteř

Diagram rybí páteře popisuje příčiny a následky řešení problémů. V kontextu vývoje informačního systému by v této fázi měl obsahovat popis příčin, které by měl vyvíjený SW řešit. Řazení tohoto modelu do skupiny nestandardizovaných modelů umožňuje velkou variabilitu, co se týče možných podob i struktury zaznamenaných informací. Jak již bylo nastíněno, při tvorbě tohoto typu diagramu je velmi důležitým prvkem ujasnění skutečných příčin řešeného problému a ujasnění jeho dílčích následků. Použitím může rovněž vyplynout nutnost dalších změn mimo plánovaný vývoj informačního systému, např. organizační a metodické změny, nebo změna jiných procesů, než ve zkoumaném systému. Důsledky existence tohoto diagramu: • revize požadavku na vytvoření systému, • revize rozsah projektu a cíle, • opětovná diskuse se zadavatelem o cíli a očekáváních, • definování příčin a následků zasazení problematiky do časové osy.

Příčinně-smyčkový diagram

Pohled na entity, veličiny, parametry, či části systému a jejich vzájemné vztahy, vazby a procesy umožňuje modelovat příčinně-smyčkový diagram. Diagram umožňuje: • identifikovat a modelovat klíčové parametry, které by systém měl ovlivňovat, naplňovat (např. míra vyřízených objednávek v případě implementace elektronického obchodu), • identifikovat posilující a balanční smyčky, které popisují principy chování systému a tudíž umožňují najít efektivní způsoby řešení problémů, • modelovat vazby systému na okolí (podporuje vyhledávání skrytých nezjevných interakcí, nebo interakcí, které nejsou přímé), • v případě několika diagramů z různých úrovní pohledu je možné vybudovat odpovídající model hierarchie dílčích částí systémů,

97 | 146

Anna Exnarová

•

zachytit vlastnosti, vnitřní závislosti, systémovou hierarchii, procesy uvnitř systému i celé organizace.

Klasické modelování entit často ohraničuje pozornost pouze na vnitřní vazby systému. Příčinně-smyčkový diagram podporu modelování a přemýšlení o vazbách systému na okolí a pomáhá přemýšlet o procesech a vztazích v příčinných i zpětně-vazebních smyčkách. Důsledky existence tohoto diagramu: • revize požadavku na vytvoření systému, • revize rozsahu projektu, • revize (doplnění nebo zrušení) seznamu požadavků, • opětovná diskuse se zadavatelem o cílech a očekáváních, • existence procesního modelu, který je možný se zadavatelem diskutovat, přímo podporuje diskusi o dynamickém chování systému, nevyžaduje znalost notace, • identifikace entit, které následně budou vystupovat v logickém modelu (příp. jejich verifikace, pokud je identifikace provedena na základě seznamu požadavků), • nalezení kritických procesních bodů, které je vhodné modelovat pomocí specializované notace procesního modelování.

Diagram hladin a toků

Diagram umožňuje: • podrobněji popsat, specifikovat klíčové parametry, které by systém měl ovlivňovat, naplňovat (některé z těchto parametrů byly identifikovány v příčinně-smyčkovém diagramu), • podrobněji dokumentovat vazby, které v systému působí, • konkretizovat působení balančních a posilujících smyček ve smyslu identifikace parametrů, pomocných proměnných a konstant, které v těchto procesech působí, • vytvoření simulací, na základě kterých je možné podrobně specifikovat chování systému za konkrétních podmínek, • identifikovat stavy systému, potažmo vybraných entit, Dle již uvedených výsledků (Chang, 2005) je možné v tomto diagramu identifikovat kandidáty na třídy, jejich atributy a metody pro logický diagram tříd. Lze identifikovat hlavní entity, u kterých bude potřebné sledovat jejich stavy (viz Tab. 8). Tab. 8 Mapování diagramu hladin a toků na diagram stavů

Diagram hladin a toků

Stavový diagram

Hladina (level, stock)

Entita (class)

Tok (rate, flow)

Stav (state)

98 | 146

Anna Exnarová

Simulace umožňují ověření hypotéz, testování chování systému za určitých podmínek, akcentování dynamiky systému a zkoumání důsledků změn systému i změn v okolí systému. Vytvoření simulačního modelu je již náročnější na zkušenosti a znalosti tvůrce, v tomto případě již nelze použít běžně dostupné systémy, je potřebné mít znalost softwarového produktu, ve kterém simulace bude realizována a samozřejmě ho mít dostupný. Přidanou hodnotou jsou potom všechny benefity, které simulace nabízí. Z pohledu praxe se domnívám, že je reálné uvažovat o situaci, kdy principy systémové dynamiky management organizace považuje za vhodné a snaží se o jejich aktivní začlenění do organizace. Pokud by byl požadován informační systém, kterého jednou z funkcionalit by byla tvorba simulačních modelů pro konkrétní potřeby byznysu, bylo by do tohoto IS nutné integrovat softwarovou podporu pro tuto funkcionalitu. V tomto případě by bylo vhodné, aby samotný vývoj IS byl v souladu s principy systémové dynamiky. Možnosti využití simulace v průběhu vývoje informačního systému (nejčastěji ve fázi designu): • sizing databází (simulace zatížení databází při vytváření složitých reportů či vysoké zátěži dotazů, návrh a simulace potřebné kapacity pro běžnou a extrémní zátěž), • návrh přenosových kapacit sítí, • ověření požadavků na hardwarové vybavení aplikačních serverů či klientských stanic, • doba generování složitých reportů, atd. Důsledky existence tohoto diagramu: • identifikace entit, které následně budou vystupovat v logickém modelu (příp. jejich verifikace, pokud je identifikace provedena na základě seznamu požadavků), • identifikací klíčového parametru může dojít k nutné revizi požadavků a cílů, • důsledky simulací mohou mít vliv na kritické faktory celého vývoje informačního systému, až po drobné úpravy nastavení parametrů, • simulací ověřené a potvrzené očekávané hodnoty, následné úpravy návrhu a designu systému, v horším případě způsobu implementace,

Případy užití

Diagramy případů užití vizualizují vztahy mezi funkcionalitou systému a aktéry. Použitím systémového myšlení před nebo současně s tvorbou případů užití se ověří, příp. doplní jejich seznam, zároveň tyto modely umožní detailněji popsat scénáře jednotlivých případů užití, příp. vytvořit relevantní testovací scénáře.

99 | 146

Anna Exnarová

Diagram tříd

Model tříd dokumentuje statickou strukturu systému – entity (příp. jejich atributy a operace) a vztahy mezi nimi. Na konceptuální a logické úrovni je možná jeho validace na základě již uvedených vlastností diagramu hladin a toků. Další zpodrobnění na implementační rovině je již více záležitostí designu.

Diagram aktivit

Diagram UML modelující funkční procesy, algoritmy je diagram aktivit. Zpodrobňuje identifikované procesy, uplatňuje na ně technický a implementační pohled. Tento diagram ale nemůže nahradit model procesů vytvořený pomocí uvedených modelů systémového myšlení a systémové dynamiky, nebo pomocí specializovaných notací procesního modelování.

Diagram stavů

Pro dokumentaci stavů hlavních entit existuje v UML diagram stavů. Modeluje stavy objektu v systému a přechody mezi stavy. Z diagramu stavů a toků jsou identifikované entity, u kterých bude nutné sledovat jejich stavy. Nicméně je nutné konstatovat, že v diagramech systémové dynamiky se jedná většinou o byznysový pohled (i když to nemusí být pravidlo), a tudíž je pravděpodobné, že se v průběhu implementace mohou, vyskytnou další entity, které nebyly identifikovány a jejichž stav bude nutné evidovat (nejčastěji se bude jednat o technické implementační entity).

4.2.4 Vztahy jednotlivých typů diagramů

Použití diagramů systémového myšlení a systémové dynamiky vychází z již uvedeného procesu systémové dynamiky (viz Obr. 22 Proces modelování (upraveno z (Sterman, 2000, str. 88))) a zároveň s charakteristik jednotlivých modelů. V myšlenkových mapách jsou vymezovány prvky systému. Diagram šestiúhelníků umožňuje identifikovat základní vazby mezi prvky a prohloubit vymezení prvků. Diagram rybí kosti vymezuje prvky, jejich vzájemné vazby a umožňuje navíc definovat vztahy mezi příčinami a důsledky. Příčinně-smyčkový diagram definuje prvky, jejich vazby a také zpětněvazbení smyčky. V diagramu hladin a toků je možné modelovat prvky, jejich vazby, zpětněvazební smyčky a také dynamiku systému a jeho chování v čase.

100 | 146

Anna Exnarová

Při tvorbě modelů a diagramů je tvůrce ovlivňován a přenáší informace získané v jednom diagramu do druhého. Následující diagram (Obr. 26) dokumentuje již diskutované vazby mezi jednotlivými typy modelů a dává je do souvislosti se základními disciplínami Unified processu.

Obr. 26 Vztahy mezi jednotlivými typy diagramů

Obr. 26 neuvádí následnost jednotlivých diagramů, ale zobrazuje existenci vazeb mezi nimi. Pro jednotlivé disciplíny Unified Process je možné využít jak diagramů UML (což je běžně používáno), tak doplnit je diagramy systémového myšlení a systémové dynamiky, a tím umožnit efektivnější aplikování systémového myšlení do procesu vývoje IASW.

Disciplína Specifikace požadavků V této disciplíně je možné pro upřesnění zadání a cíle použít myšlenkové mapy, diagram rybí páteře a příčinně smyčkové diagramy. Pro specifikaci případů užití je možné použít také myšlenkové mapy a dále diagram hladin a toků a příčinně-smyčkový diagram. Všechny tyto diagramy mají dopady na specifikaci požadavků. V této disciplíně je možné rovněž vytvořit simulační model hladin a toků, jehož výsledky primárně ovlivňují případy užití a seznamy požadavků. Disciplína Analýza V analýze je možné využít diagram hladin a toků, který má přímou vazbu na diagram tříd a diagram případů užití. Rovněž je možné použít jeho simulaci.

101 | 146

Anna Exnarová

Disciplína Návrh V oblasti návrhu se rovněž jedná o spojení diagramu hladin a toků s dalšími diagramy UML, především se stavovým diagramem.

Návaznost jednotlivých typů modelů nejsou striktně dány. Jak z pohledu systémového myšlení, tak z pohledu modelů dle notace UML (potažmo metodiku UP) je určitá volnost v pořadí, v jakém jsou modely vytvářeny. Objevuje se zde synergický efekt v případě vytváření (či používání) jednotlivých modelů současně a v opakovaném používání či úpravě modelů. I přesto je možné navrhnout sled, jak které modely by bylo vhodné vytvářet (viz Obr. 27). Levá strana dokumentuje již diskutované a charakterizované modely systémového myšlení a systémové dynamiky, pravá část obsahuje základní sadu modelů dle notace UML. Existuje zde určitý posun, kdy modely UML je vhodné vytvářet s určitým „zpožděním“ v čase oproti modelům systémového myšlení. Ale přibližně od úrovně modelu Příčin a následků je vhodné zapojit tvorbu diagramu požadavků a dalších UML.

Obr. 27 Následnost diagramů v návrhu

102 | 146

Anna Exnarová

4.2.5 Závěry návrhu

Uplatnění systémového myšlení v analytické fázi vývoje IASW velmi úzce souvisí také s oblastí kvantity a kvality dat (problematika byla uvedena v kapitole 3.1.4 Problematika kvality a kvantity dat )a s problematikou informačního řetězce. Ten můžeme na tomto místě namodelovat pomocí modelu stavů a toků (viz Obr. 28 Informační tok). Data jsou transformována do znalostí procesem přisuzování významu příjemcem. Do tohoto procesu vstupují zkušenosti, návyky, již existující mentální modely a znalosti, mentální procesy i způsob myšlení příjemce. Přechod informací do stavu znalostí je spojen s aktivní kognitivní činností příjemce, který začleňuje nové znalosti do struktury existujících znalostí a zároveň upravuje svoje mentální modely. Aktivní kognitivní procesy příjemce mohou být reprezentovány právě uplatněním systémového myšlení, potažmo tvorbou a používáním modelů systémového myšlení a systémové dynamiky. Zkušenosti příjemce Návyky příjemce Způsob myšlení příjemce

Mentální modely příjemce

Kognitivní procesy příjemce

Znalosti příjemce

Znalosti

Informace

Data přisuzování významu

transformace do struktury znalostí

Aktivní kognitivní procesy příjemce Obr. 28 Informační tok

Použití modelů systémového myšlení a systémové dynamiky v analytické fázi vývoje IASW umožňuje: • Pochopit fungování systému, jednotlivé stavy a toky, které se v systému vyskytují. • Identifikovat smyčky v chování systému a najít způsob jejich zpracování. • Zachytit dynamiku systému a jeho prvků, pochopit zpoždění. • Popsat a pochopit příčiny a následky, které se v systému vyskytují. • Vytvořit simulace, specifikovat chování systému za konkrétních podmínek.

103 | 146

Anna Exnarová

Použití modelů systémového myšlení při návrhu IASW: • pomáhá provést revizi požadavků, nebo jejich stanovení; • poskytuje nástroje pro komunikaci, které více akcentují mentální a kognitivní procesy; • umožňuje lépe identifikovat entity a parametry, kterým je dále nutné věnovat pozornost (a budou dále rozvíjeny, např. v modelech dle notace UML); • umožňuje simulaci; • v neposlední řadě umožňuje akcentovat systémový přístup a poměrně efektivně zapojit systémové myšlení bez nutnosti umělého zavádění dovedností systémového myšlení. Možný další rozvoj návrhu

Dle uvedeného životního cyklu softwaru a jednotlivých typů diagramů lze dále navrhnout použití jednotlivých typů diagramů v dalších fázích životního cyklu dle Obr. 29 .

Obr. 29 Možnost rozšíření návrhu do

Lze konstatovat, že uvedený návrh by vzhledem k obecnosti modelů systémového myšlení a systémové dynamiky bylo možné použít i v jiných konceptech životního cyklu IASW, i vývoje informačního systému. Vedle konkrétního uplatnění modelů systémového myšlení a systémové dynamiky při vývoji informačních systémů spatřuji velký potenciál v uplatnění principů systémového myšlení v tomto procesu a příp. vytvoření metodiky vývoje akcentující tyto principy. 104 | 146

Anna Exnarová

5 APLIKACE NÁVRHU UPLATNĚNÍ SYSTÉMOVÉHO MYŠLENÍ V ANALYTICKÉ FÁZI VÝVOJE IASW V PRAXI Kapitola dokumentuje na skutečném reálném případě použití systémového myšlení v analytické fázi vývoje IASW. Jak již bylo zmíněno, dokumentována je reálná situace, z toho důvodu jsou v praktické studii použity reálné pojmy, použití modelů, metodika, které nejsou v 100% souladu s teorií a standardy. Cílem kapitoly není narovnání těchto pojmů, ale ověření návrhu uplatnění systémového myšlení. Z tohoto důvodu je dokumentace provedena stylem „as-it-is“ (tak jak to skutečně bylo). V této části je pojem IASW nahrazen pojmem aplikace, tak jak byl v praxi skutečně používán. Vývoj IASW probíhal v roce 2011, celý projekt trval přibližně pět měsíců, trvání projektu nejvíce ovlivnili interní rozhodovací procesy a změna znalostní báze, tak aby všichni zainteresovaní zaměstnanci měli potřebné a relevantní informace jak o průběhu vývoje, tak o finální podobě vyvíjeného IASW. Vytvořený produkt je dosud používán. 5.1 Úvod praktické studie Vývoj informačních systémů je hnacím motorem rozvoje dalších oborů, především rozvoje hospodářských organizací. Dynamika a změny se netýkají pouze soukromého sektoru. Tyto změny mají velký dopad i do procesů na straně zadavatelů a zákazníků, a v oblasti veřejného sektoru. V České republice můžeme za posledních několik let sledovat masivní rozvoj veřejného sektoru v oblasti informačních technologií. Jmenujme aspoň některé oblasti, které se v této kategorii zapsaly do dějin IT ve veřejné správě: Základní registry, Registr vozidel, Datové schránky, Elektronický podpis, zákonná povinnost o používání spisové služby. Vláda ČR schválila strategický dokument v oblasti informačních a komunikačních technologií, ve kterém jsou mimo jiné předkládána doporučení a opatření „pro rozvoj a využití přínosu ICT pro společnost včetně celkové strategie integrovaného řešení řízení investic do ICT ve státní správě.“(Vláda ČR, 2013) Dle učiněných kroků se lze domnívat, že státní správa chce občanům poskytnout za co nejnižší cenu co nejlepší, největší, nejmodernější a nejpohodlnější služby s co nejmodernějším využitím informačních technologií. Požadované zdokonalení a zvelebení systémů by se ale mělo dotýkat všech jeho složek (od informační, přes procesní a organizační, až k technickým), což v realitě ne vždy bývá akcentováno a asi dochází k mylnému názoru, že po upgradu jedné části – nejčastěji ICT, dojde ke zlepšení celkového stavu. Návratnost investic po realizaci změn často není ani ve spokojenosti zadavatele/uživatele/obyvatelstva, ani v naplnění informačních požadavků.

Kapitola „Aplikace evidence veřejných zakázek“ uvádí verifikaci předloženého návrhu uplatnění systémového myšlení ve vývoji informačního systému na základě kritického vyhodnocení teoretických východisek a vlastního návrhu. Stěžejním motivem kapitoly je propojení dvou již dříve diskutovaných přístupů (analytického a systémového)

105 | 146

Anna Exnarová

k vývoji informačního systému. Analytický přístup rozšiřuji použitím systémových přístupů, modelů systémového myšlení a systémové dynamiky. První jmenovaná skupina, tj. analytický přístup, je technika analýzy, běžně používaná a v praxi rozšířená, založená na dekompozici zkoumaného systému na samostatné prvky, vytváření hierarchie, zkoumání kauzality ve formě příčina – následek a formulaci otázek kdo, co, kdy, kde, jak pro prvky systému. Přirozeně je tato technika propojená s dělbou práce mezi jednotlivé členy týmu. Doplnění této techniky koresponduje s uplatněním systémového myšlení a akcentem na základní systémové vlastnosti. Cílem kapitoly je popis a analýza aplikace teoretických přístupů a verifikace propojení těchto přístupů s vlastními návrhy na jejich užití. Tento cíl je v souladu s vymezenými cíli disertační práce – kapitola uvádí do souvislosti vybrané koncepce modelování, představuje rozšíření analytické koncepce o modely systémové na konkrétním v praxi vytvořeném a používaném systému. Proces, ve kterém byla praktická aplikace uplatněna, je vývoj vybrané aplikace „Evidence veřejných zakázek“ (EVZ), se zaměřením na sběr požadavků a analýzu. Vývoj aplikace EVZ byl realizován prakticky v konkrétní organizaci. Tato případová studie přistupuje k vývoji ve dvou rovinách: • Popis vývoje, dokumentace reálného procesu vzniku aplikace s důrazem na vytvářené modely a použité přístupy. • Komentář dílčích kroků vývoje z pohledu teoretických východisek této disertační práce, komentář k použitým metodám z pohledu systémových přístupů, vlastní doplnění a rozšíření řešení o modely systémového myšlení a systémové dynamiky (v textu zvýrazněn odlišným formátem písma). Projekt vývoje a nasazení aplikace EVZ do interního prostředí firmy byl klasifikován jako menší interní projekt. V rámci týmu jsem na projektu v první fázi působila na pozici analytika a projektového manažera, ve fázi detailní analýzy a designu jako projektový manažer. Projektový tým tvořilo několik členů, stejně jako já i ostatní zastávali kumulované role: analytik a tester, architekt, designér a vývojář, databázový specialista. Členové týmu mají rozsáhlé praktické zkušenosti z příslušných odborných oblastí vývoje informačních systémů. Teoretické znalosti či praktické zkušenosti z oblasti systémových věd a systémové dynamiky nebyly mezi ostatními členy týmu zastoupeny, nicméně musím konstatovat, že v mnohých případech jsou jimi aplikované postupy velmi blízké výstupům realizovaným pomoci systémových věd. Popis implementace, nasazení, použité technologie, či konkrétní parametrizace nejsou předmětem této praktické studie. Systémové myšlení vystupuje v této kapitole ve dvou rovinách. Byl to nástroj a způsob práce v procesu vývoje aplikace EVZ, a zároveň systémové myšlení je použito pro popis tohoto procesu a jako nástroj vytvoření této práce. 5.2 Firma a její způsob vývoje softwaru Organizace, ve které byla aplikace EVZ vyvíjena, a následně i nasazena, je velká mezinárodní společnost, jejíž česká pobočka se věnuje vývoji, implementaci i podpoře informačních systémů. Zkušenosti členů týmů podílejících se na vývoji aplikace EVZ jsou jak z oblasti vývoje informačních systémů na míru dle konkrétních potřeb a požadavků zákazníka, tak z oblasti customizace standardizovaných krabicových řešení a

106 | 146

Anna Exnarová

jejich integrace do existujících informačních systémů zákazníků. Tato organizace bude nadále označována pojmem Firma. Metodikou vývoje aplikace EVZ byla firemní metodika vývoje softwaru používaná ve Firmě, její základní rysy jsou velmi blízké standardní metodice Unified Process. Nejvíce se proces vývoje ve Firmě blíží inkrementálnímu modelu životního cyklu vývoje aplikací. Obecný životní cyklus informačního systému můžeme v této souvislosti popsat následovně: 1. Vytvoření specifikace, v rámci které je potřebné definovat základní funkcionalitu budoucího systému a jeho hranice. 2. Návrh a implementace, kde jsou realizovány aktivity, které mají za cíl vytvoření informačního systému dle požadavků. 3. Testování a nasazení, které jsou důležité pro validaci návrhu systému, zároveň testování není pouhým ověřením, ale často řádnou součástí vývoje, testování probíhá většinou v různých prostředích (typické kategorie jsou vývojové, testovací, integrační, školící, pilotní, produkční), do kterých systém musí být nasazen. 4. Evoluce systému, jakožto přímý odraz dynamického prostředí a měnících se požadavků uživatelů. 5.3 Sběr požadavků Zadání, které vedení firmy předložilo našemu týmu, znělo: „Vytvořit aplikaci, ze které budeme moci získávat relevantní informace o veřejných zakázkách.“ Systémovějším chápáním s aspekty informační podpory lze zadání pojímat ve smyslu „zajištění informačních potřeb o veřejných zakázkách příslušných zainteresovaných zaměstnanců.“ Toto zadání lze chápat jako „vyřčený cíl“, který má aplikace splnit. Z hlediska systémového přístupu ale bylo nutné pátrat i po „nevyřčeném cíli“, a zde jsem jednoznačně došla k tomu, že tímto nevyřčeným cílem je podpořit úspěšnost Firmy v získávání a realizaci VZ, což je základní faktor, se kterým se Firma potýká a je také hlavním motivem proč ke změně přístupu k VZ ve Firmě dochází. Uvažovaná aplikace tedy při uplatnění systémového přístupu nemůže plnit pouze vyřčený cíl, ale musí podpořit i ten nevyřčený, který je ve skutečnosti tím hlavním, který Firma sleduje. Navíc tento nevyřčený cíl lze exaktně měřit (např. sledováním trendu podílu vítězných nabídek ku všem podaným nabídkám). 5.3.1 Okolí Firmy

Z pohledu typů zákazníků Firmy se jedná o organizaci, která poměrně velkou část svého portfolia směřovala a směřuje do veřejného sektoru. Od roku 2006 dochází v České republice k poměrně velké transformaci v oblasti veřejných zakázek (VZ). Právní a legislativní rámec je mimo jiné upřesňován v zákoně o veřejných zakázkách č. 137/2006 Sb., ve znění pozdějších předpisů a také v § 32 zákona č. 139/2006 Sb., o koncesních smlouvách a koncesním řízení. Vzhledem k právním, společenským i politickým změnám ve společnosti dochází k poměrně velkým změnám i v oblastech veřejných zakázek. Došlo ke změnám v procesu zadávání veřejných zakázek, způsobu i 107 | 146

Anna Exnarová

obsahu informování, v požadovaných náležitostech i procesech plnění. Trendem je také rušení vyhlášených veřejných zakázek a zvyšující se četnost podávání stížností na průběh veřejných soutěží či výsledků výběrových řízení. Na dodržování příslušných právních předpisů dohlíží především Úřad pro ochranu hospodářské soutěže. Každá jednotka, organizace, orgán státní správy má dle příslušných zákonných mantinelů možnost vypisovat výběrová řízení či zadávat veřejné zakázky. Jednotlivé organizace veřejné správy si agendu související s veřejnými zakázkami řeší individuálně v rámci svého působení (např. informace o vypsaných veřejných zakázkách Magistrátem hlavního města Prahy19; nebo agenda veřejných zakázek na Ministerstvu zemědělství ČR20; či publikované informace o veřejných zakázkách České správy sociálního zabezpečení21). Ministerstvo pro místní rozvoj ČR zastřešuje agendu veřejných zakázek za celou státní správu ve smyslu provozu informačního systému o veřejných zakázkách22, který poskytuje zadavatelům, dodavatelům, odborné i široké veřejnosti „informace o činnosti věcně příslušných správních úřadů v oblasti veřejných zakázek a koncesí.“ (MMR, 2013) Součástí tohoto informačního systému je portál informačního systému o veřejných zakázkách a koncesích23. Tento portál poskytuje komplexní informace o všech veřejných zakázkách, příslušné číselníky a klasifikace, statistické výstupy o veřejných zakázkách, rejstřík koncesních smluv, atd. Uveřejňování informací o veřejných zakázkách je realizováno tzv. Věstníkem veřejných zakázek24. Informace ke každé veřejné zakázce jsou publikované v rámci jednoduchého formuláře (viz Obr. 30 IS VZ, náhled na formulář veřejné zakázky, (MMR, 2013)), kde mezi základní informace patří evidenční číslo zakázky, číslo formuláře, datum uveřejnění, typ, kontaktní údaje a předmět činnosti zadavatele, předmět a popis veřejné zakázky, právní, ekonomické, finanční a technické informace.

19

http://www.praha.eu/jnp/cz/home/magistrat/uredni_deska_a_oznameni/deska /?strana=37&typ=&odbor=&nazev=&text=&stranavel= 20

http://eagri.cz/public/app/eagriapp/VZ/Prehled/Default.aspx?theme=MZE&stamp=634984293705522489 http://www.cssz.cz/cz/verejne-zakazky 22 http://www.portal-vz.cz/cs/Uvodni-strana 23 www.isvz.cz 24 http://www.vestnikverejnychzakazek.cz/ 21

108 | 146

Anna Exnarová

Obr. 30 IS VZ, náhled na formulář veřejné zakázky, (MMR, 2013)

V době vývoje aplikace EVZ portál umožňoval vyhledávat veřejné zakázky pomocí základních kritérií i pomocí rozšířeného vyhledávání, umožňoval vytvářet jednoduché sestavy (viz Obr. 31 IS VZ, vyhledávání podle více parametrů, (MMR, 2013)). Funkcionalita a forma poskytovaných informací nesplňovaly požadované parametry a nedokázaly plně uspokojit informační potřebu jednotlivých uživatelů. Z tohoto důvodu bylo rozhodnuto o vývoji aplikace EVZ interně, pro interní potřeby Firmy.

109 | 146

Anna Exnarová

Obr. 31 IS VZ, vyhledávání podle více parametrů, (MMR, 2013)

Proces zadávání veřejných zakázek, jejich vyhlašování, uzavírání, vyhodnocování je v posledních letech velmi dynamickou oblastí. Průběh je ovlivněn změnou struktury celého prostředí, zvýšenou složitostí dílčích kroků, změnou nastavených okolních procesů, zvyklostí. Tyto změny mají bohužel často dopad na kvalitu a ceny zakázek. Daný stav je odrazem dvou snah, které v současné době naše společnost řeší: snaha o nastavení protikorupčních pravidel s cílem zabránění neetickým a nezákonným praktikám, a snaha o zefektivnění služeb, které stát nakupuje. Bohužel se často pojem efektivní zaměňuje s pojmem nejlevnější, a není neobvyklé se setkat s veřejnými zakázkami, kde v procesu rozhodování je jediným kritériem cena. Transformace celého systému veřejných zakázek má velký dopad do státní správy a jejích procesů, ale také do soukromého sektoru. Organizace, ve kterých významnou část portfolia zákazníků tvoří veřejných sektor, musely změnit interní procesy, způsoby práce i myšlení. Jedním z důležitých prvků rozhodování se pro tyto organizace (včetně Firmy, která je předmětem této případové studie) staly informace o veřejných zakázkách a důkladné pochopení celého systému veřejných zakázek.

110 | 146

Anna Exnarová

Na následujícím modelu (Obr. 32) je pomocí jednoho z typů modelů systémového myšlení, a to příčinného myšlení, graficky reprezentovaného metodou rybí páteře, dokumentována oblast VZ. Modelovány jsou dílčí faktory a příčiny, které vstupují do procesu transformace systému veřejných zakázek, a jejichž důsledkem jsou změny v systému a procesu veřejných zakázek.

Obr. 32 Analýza příčin transformace systému veřejných zakázek

Provedený rozbor okolí organizace a příčin změn v systému veřejných zakázek pomohl s rozpoznáním nutné změny interních procesů Firmy.25 Ukázalo se tedy, že pro splnění cíle nebude dostatečné vytvořit aplikaci EVZ, ale bude nutná i úprava interních procesů firmy. 5.3.2 Vliv okolí na Firmu

Změnu v okolí organizace (ve veřejné správě, v systému veřejných zakázek) bylo možné zaznamenat poměrně rychle. Transformace v oblasti formálních dopadů do soukromého sektoru byla poměrně rychlá. Zdlouhavým se ale stalo praktické přizpůsobení organizace na tyto změny. Domnívám se, že největším problémem bylo uvědomění si, jaké dopady budou mít tyto změny do interních procesů organizace. Externí a formální procesy směrem k zákazníkům byly jasně specifikovány a dány.

25

Bohužel uvedené poznatky čím dál více dokumentují i výzkumy a statistiky z oblasti veřejných zakázek. Jedním z posledních příkladů je výzkum poradenské společnosti Otidea, která tvrdí, že „Celých 90 procent zadavatelů veřejných zakázek ve státní správě a samosprávě je pak přesvědčeno, že přístup, kdy jim nadřízené orgány přikazují používat jako základní hodnotící kritérium nejnižší nabídkovou cenu, ohrožuje kvalitu budoucího plnění zakázky (Zdroj: ČT24. Úředníci: Vítězí nejnižší cena. I když víme, že práce bude nekvalitní. 14.3.2013. Online. http://www.ceskatelevize.cz/ct24/ekonomika/218790-urednicivitezi-nejnizsi-cena-i-kdyz-vime-ze-prace-bude-nekvalitni/).

111 | 146

Anna Exnarová

Nicméně vnitřně v organizaci bylo nutné změnit proces předávání informací, zajistit sdílení znalostí, pokrýt nově vzniklé informační potřeby. Tyto změny souvisely i s potřebou změnit mentální modely zaměstnanců, začlenit do nich nové proměnné a změnit procesy. A následně umět tyto změny v mentálních modelech adekvátně využít. Získat dovednost a učinit na základě nich rozhodnutí. Rozšířila se množina zaměstnanců, jejichž informační potřeba zahrnovala informace o veřejných zakázkách. Už to nebyli pouze obchodníci a management na vrcholové úrovni. Nově bylo nutné, aby se informacemi o veřejných zakázkách, sledováním změn o konkrétní zakázce nebo naopak komplexem celého spektra veřejných zakázek začali zabývat i analytici, architekti a business konzultanti. Analýza této problematiky je dokumentována na Obr. 33 Informační potřeba – změna struktury zainteresovaných zaměstnanců, za použití myšlenkové mapy pro dokumentaci mentálního modelu.

Obr. 33 Informační potřeba – změna struktury zainteresovaných zaměstnanců

Tento diagram pomohl identifikovat správnou skupinu zaměstnanců jako uživatele systému EVZ: • Vedení společnosti a top management – tito lidé se podílí na strategických rozhodnutích o účasti na vybraných VZ, zároveň požadují mít v odpovídajícím sumarizovaném pohledu k dispozici informace o účasti Firmy na VZ a její úspěšnosti. • Obchodníci a projektoví manažeři, kteří jsou zodpovědní za účast na konkrétních veřejných zakázkách, potřebují mít k dispozici informace o konkrétní veřejné zakázce, na které pracují (ať již ve fázi nabídky, nebo její vlastní realizaci); zároveň pro své rozhodování a pro podporu svých rozhodnutí vůči top managementu potřebují mít k dispozici detailní statistický přehled. • Členové týmů, které příslušný projektový manažer potřebuje pro realizaci nabídky či dodávky, musí mít k dispozici aktuální a relevantní informace. V aplikaci se tyto informační potřeby uživatelů transformují do příslušných případů užití. V dokumentu byl definován základní set těchto případů: • Vedení společnosti o Statistika úspěšnosti firmy ve VZ o Statistika přímých konkurentů v úspěšnosti ve VZ o Rozdělení VZ mezi dílčí obchodníky, úspěšnost obchodníků/PM • Obchodníci a PM zodpovědní za účast na VZ

112 | 146

Anna Exnarová

o Informace o celé paletě vyhlašovaných VZ o Statistiky VZ • Pracovníci podílející se na tvorbě nabídek pro konkrétní VZ, realizace VZ o Detailní informace o dílčí konkrétní VZ

V tuto chvíli se naplno „zviditelnil“ původně nevyřčený cíl, tedy podpořit úspěšnost Firmy ve VZ, a to konkrétně v 1. setu případů užití.

Současně s analýzou struktury zainteresovaných zaměstnanců bylo nutné analyticky prozkoumat informační potřebu ve Firmě. Po nasazení aplikace EVZ do produkce by mělo dojít k uspokojení definovaných informačních potřeb. EVZ bude tvořit nedílnou součást informačního systému Firmy, bude umožňovat ukládání, vyhledávání a práci s informacemi o veřejných zakázkách a tudíž by měla poskytnout technické prostředky pro práci s explicitními znalostmi, které se této oblasti týkají. Zaznamenání nezbytnosti změny informační potřeby bylo prvním krokem. V druhém kroku bylo potřebné navrhnout realizaci změn, tak aby bylo možné tyto potřeby uspokojit. Vznikl požadavek na vytvoření aplikace. Klíčovým prvkem mentálních modelů bylo správně zkonstruovat a pochopit principy a vazby, které systém VZ ve Firmě má. Prvním bodem byla dokumentace obecného modelu trhu veřejných zakázek. Tento model (viz Obr. 34 Obecný model trhu VZ) je z pohledu organizace možné popsat jednou posilující a jednou balanční smyčkou, jejichž společným průnikem je úspěšnost Firmy v získávání veřejných zakázek (již na začátku definovaný jako nevyřčený cíl tohoto systému). Levá posilující smyčka umožňuje Firmě získávat a vyhrávat ve výběrových řízeních. Pro vytvoření a podání nabídky musí organizace investovat interní zdroje. Nejvýraznější položkou interních zdrojů jsou lidé. Firma může investovat ve smyslu: • využívané kapacity (čas věnovaný přípravě nabídky); • v případě nedostatečných znalostí ve smyslu investice do získávání nových kompetencí; • v případě potřeby investice do počtu členů týmu pro přípravu nabídek. Dále může být potřebné investovat do technologií i spotřebního materiálu. Lze konstatovat, že čím jsou větší investice pro přípravu nabídky, tím se zvyšuje schopnost Firmy tvořit nabídky, které budou splňovat zadávací kritéria a budou vítězné. Tudíž dojde ke zvýšení úspěšnosti Firmy ve výběrových řízeních. Předpokladem tohoto modelu je fakt, že Firma se účastní pouze těch výběrových řízení a připravuje takové nabídky, u kterých realizace veřejné zakázky bude pro firmu zisková. Tedy díky zvýšené úspěšnosti firmy se zvyšuje i její zisk, který umožní vyčlenit větší objem investic do dalších nabídek. Ale i kdyby se jednalo o úspěšnou firmu, která vyhrává jedno výběrové řízení za druhým, získávání veřejných zakázek není nekonečné – hranice tohoto růstu (vedle

113 | 146

Anna Exnarová

vnitrofiremních) jsou dány velikostí trhu a jeho naplněním, potažmo tedy množstvím zakázek, které jsou k dispozici. Toto množství se s každou vyhranou zakázkou mění. Parametr velikost trhu je pro tento model zjednodušením celého procesu vyhlašování a uzavírání veřejných zakázek. Tento proces je poměrně složitý a závisí nejen na organizacích, které veřejné zakázky vyhlašují, ale také na politické situaci, finančních a rozpočtových omezeních organizace i státního rozpočtu, často také na rozhodnutích a podpoře Evropské unie. Rozpracování těchto parametrů pro proces tvorby aplikace EVZ má nízkou váhu, tudíž bylo použito uvedené zjednodušení. I uvedený parametr trhu vytváří balanční smyčku, která celý model udržuje v rovnováze. Pro tento typ modelu byl použit diagram příčinně-smyčkový, který je aplikací dovednosti systémového myšlení – konkrétně myšlení ve zpětných smyčkách.

+

Schopnost tvořit vítězné nabídky

Velikost trhu

+ % úspěšnosti -

Investice do nabídek + Zisk

+ Obsazení trhu

+

Obr. 34 Obecný model trhu VZ

Zkoumání systému veřejných zakázek a to za pomocí právě uvedeného modelu poskytlo základní představu o fungování trhu, definovalo základní proměnné a vyplynula z něho potřeba detailnějšího prozkoumání vnitřních parametrů, které ovlivňují tvorbu nabídek. Dalším krokem byla analýza a dokumentace z Firmy. Levá část modelu (viz Obr. 35 Vnitřní proces ve Firmě), posilující smyčka, zůstala obdobná jako v předchozím modelu. V pravé části modelu je také balanční smyčka, jež modeluje parametry, které v organizaci mají vliv na úspěšnost v získání veřejné zakázky. Jak již bylo diskutováno, jedná se především o personální pohled (např. na počet konzultantů, kterých pro vyšší počet nabídek je potřebné vyšší množství). Zároveň je potřebné zaměstnance kvalifikovat dle požadavků nabídek na příslušné technologie, nástroje, metodiky. Se zvyšující se složitostí nabídek (nebo jejich množstvím) na kterých je nutná participace, se zvyšuje (a často exponenciálně) složitost řízení tvorby nabídky. Změny těchto parametrů mají za následek zvýšené finanční prostředky, které je nutné na přípravu vynaložit. Snižující se efektivita práce na nabídkách má přímý dopad na jejich kvalitu i počet nabídek, které Firma je schopná podat, a tím je snížena míra úspěšnosti. Parametr „Kvalita řízení projektu“ je určující, podle tohoto parametru je smyčka buď balanční, nebo rostoucí. V případě, že „Kvalita řízení projektu“ je dostatečná a odpovídá složitosti nabídky, Firma je plně schopna pokrýt zvýšené požadavky na řízení,

114 | 146

Anna Exnarová

zvyšuje se efektivita práce, roste kvalita nabídky nebo jejich počet a zvyšuje se jejich úspěšnost. V případě ale, že parametr „Kvalita řízení projektu“ je nižší než Složitost řízení nabídky, mění se pravá smyčka na balanční. Příkladem může být situace, kdy tvorbou velké nabídky je pověřen junior projektový manažer bez dostatečných znalostí, zkušeností a kompetencí. Musí tedy vynaložit větší úsilí na řízení projektu, ale zároveň nízká kvalita řízení má vliv na výstupy dalších členů týmů a výrazně se snižuje efektivita práce, kvalita výstupů a tím i celková úspěšnost. Technologie Kvalita řízení projektu

Počet konzultantů +

Schopnost tvořit + vítězné nabídky

Investice do nabídek +

+

+ % úspěšnost -

R (+)

+ Složitost řízení + tvorby nabídky

Kvalifikace konzultantů

B (-)

+ Prostředky vynaložené na tvorbu nabídky

Kvalita nabídky -

+ Zisk Počet nabídek

-

Míra efektivity

-

Investice z dalších zdrojů firmy Obr. 35 Vnitřní proces ve Firmě

Důvody, proč problematika veřejných zakázek byla ve Firmě řešena právě vývojem interní aplikace, byly dlouhodobě diskutovány. Diskuse a komunikace o těchto důvodech samozřejmě vedla k úpravě mentálních modelů členů týmů i k úpravě systému znalostí. Pro dokumentaci výsledků tohoto procesu jsem vytvořila modely (viz Obr. 36; Obr. 37; Obr. 38), které představují jednotlivé skupiny příčin, které vedli následně k vytvoření aplikace EVZ. Tyto diagramy pomohly dále pracovat s nutnými změnami v interních procesech firmy, bez kterých by samotná aplikace EVZ nevedla k dosažení cíle. Pro modelování důvodů (příčin) vzniku myšlenky na interní aplikaci jsem v prvním kroku zvolila pro tuto oblast typicky model rybí páteře (neboli model příčin a následků). Modelovaná situace je rozdělena do dvou diagramů. Na Obr. 37 jsou popsány obecné

115 | 146

Anna Exnarová

příčiny, Obr. 38 detailněji popisuje příčiny jedné vybrané oblasti – potřeby rozšíření portfolia projektů. Pro porovnání Obr. 36 zachycuje ty samé informace, nicméně formou myšlenkové mapy. Především z důvodu, že se jedná o delší textové struktury, tato varianta je přirozenější.

Obr. 36 Důvody změn ve Firmě – myšlenková mapa

116 | 146

Anna Exnarová

Obr. 37 Důvody změn ve Firmě – rybí páteř

Obr. 38 Potřeba rozšíření portfolia

5.3.3 Formulace zadání

Dle obvyklých postupů vznikl dokument popisující projektový záměr. Jeho cílem bylo poskytnout sponzorovi projektu relevantní informace pro rozhodnutí o spuštění projektu a jeho rozsahu (kromě níže uvedených analytických informací dokument obsahoval části projektového řízení, které ale nejsou objektem zájmu této práce).

117 | 146

Anna Exnarová

Výchozí předpoklady zadání byly dvě: • existence portálu veřejných zakázek v rámci Informačního systému VZ (IS VZ); • a dosud manuální distribuce informací o relevantních veřejných zakázkách. V minulosti byly z portálu IS VZ data o veřejných zakázkách filtrována a vybírána ručně, rovněž vyhodnocení relevantnosti dat nebylo automatizované. Tyto informace byly ručně vkládány do strukturované e-mailové zprávy a rozesílány příslušným zaměstnancům. Požadavkem bylo zajistit kvalitní nástroj pro práci s informacemi o relevantních veřejných zakázkách na jednom místě, zachovat proces distribuce uživatelům a případně implementovat další novou funkcionalitu. V této fázi bylo potřebné rozhodnout, zda je nutné vytvářet novou aplikaci, nebo je možné využít existujícího portálu IS VZ. Tento portál částečně pokrýval požadovanou funkcionalitu, ale pouze omezeně. Diskusí a brainstormingem týkajících se možností použít IS VZ nebo vytvoření vlastní aplikace bylo rozhodnuto o připravení návrhu a popisu způsobu řešení vytvořením interní aplikace EVZ. Mentální mapa na Obr. 39 dokumentuje tyto diskutované důvody, které vedly k vybranému řešení.

Obr. 39 Důvody vzniku interní aplikace EVZ

Tento model pomohl kvalitně zpracovat katalog požadavků na aplikaci EVZ. Aplikace EVZ měla za cíl stahovat, aktualizovat a ukládat pouze relevantní data z portálu veřejných zakázek, umožnit jejich prohlížení a třídění, tvorbu statistických výstupů. Bylo nutné zachovat funkcionalitu informování o veřejných zakázkách zainteresované skupině uživatelů prostřednictvím strukturovaného e-mailu. V rámci návrhu projektu byla dále navrhována integrace aplikace s dalšími aplikacemi, a dále vytvoření workflow pro řízení procesu práce s veřejnou zakázkou.

Ve Firmě je možné činnosti týkající se problematiky veřejných zakázek rozdělit do dvou kategorií: nabídka na VZ a realizace VZ. Aplikace EVZ poskytuje informační podporu především pro první kategorii – pro činnosti, které souvisejí s tvorbou nabídek a poptávání veřejných zakázek. 118 | 146

Anna Exnarová

Obr. 40 Činnosti Firmy v souvislosti s VZ

Aplikace EVZ musela zajistit pokrytí informační potřeby příslušných uživatelů. Tyto potřeby korespondují s činnostmi, které se po jednotlivých zaměstnancích vyžadovaly (viz Obr. 40 Činnosti Firmy v souvislosti s VZ). Bylo to především: • efektivní participace na přípravě nabídky, dokonalá znalost obsahu a stavu nabídky, • aktivní spolupráce na rozšiřování portfolia VZ, • rozšiřování znalostí a kompetencí při podávání VZ, • dokonalý přehled o trhu VZ v příslušné odborné oblasti, • práce se statistikami VZ, příprava reportů a prezentací o úspěšnosti Firmy ve VZ. Mimo těchto činností bylo cílem aplikace EVZ také pokrytí informační potřeby vrcholového managementu pro rozhodovací proces „GO/NO GO“ pro podání nabídky na VZ. Příslušní manažeři by tedy měli mít na základě dostupných informací z aplikace EVZ (a z dalších jejich znalostí, zkušeností a schopností) rozhodnout o tom, zda Firma má nebo nemá věnovat interní zdroje pro tvorbu nabídky. Pokud je rozhodnutí „GO“, ve Firmě se startují již standardizované procesy pro tvorbu a podání nabídky. Činnosti související s realizací veřejné zakázky jsou již, v případě výhry VZ, z pohledu Firmy chápány jako standardní projekt.

Na základě výše uvedených informací byl sponzorovi projektu předložen Projektový záměr a diskutovány způsoby a možnosti řešení. V prvním kole představení návrhu aplikace a výstupů projektů (a samozřejmě souvisejících odhadů pracností a požadovaných zdrojů), bylo ze strany sponzora projektu požadováno upřesnění projektu a definování podrobnějších parametrů realizace. Důvodem požadavku na upřesnění a okomentování projektového záměru bylo rozdílné chápání celého systému veřejných zakázek. Vrcholový management firmy a obchodníci, kteří se i v minulosti podíleli 119 | 146

Anna Exnarová

aktivně na výběrových řízeních ve veřejném sektoru a rozhodovali o účasti na konkrétních projektech, dosud neakceptovali všechny parametry, které se v procesu veřejných zakázek měnily. Rovněž bylo potřebné, aby se i noví členové týmu, kteří do té doby nebyli v kontaktu s výběrovým řízením ve veřejném sektoru, plně seznámili s touto problematikou. Pro další upřesnění projektového záměru vznikaly další podkladové materiály, které všem zúčastněným pomohly ve správném uchopení problému. Došlo k úpravě mentálních modelů a také k sjednocení terminologie a vytvoření sdílených znalostí o problematice. Aplikace základních přístupů systémových věd pro pochopení problematiky se potvrdila jako přínosná. Proces úpravy mentálního modelu byl poměrně zjednodušen, pokud při jeho transformaci bylo pracováno s modely systémového myšlení a byly akcentovány základní systémové vlastnosti. Vzhledem k senioritě a zkušenosti členů týmů bylo zajímavé pozorovat, že tvorba modelů systémového myšlení individuálně, a následná diskuse pouze výsledků úprav, měly za následek správný posun a úpravu mentálních modelů i ostatních členů týmu. Na základě celého setu těchto informací rozhodl top managementem Firmy, jako investor projektu, o startu projektu Vývoje interní aplikace EVZ. Lze konstatovat, že systémový přístup pomohl ve správné interpretaci zadání a jeho formalizaci při návrhu skupin uživatelů systému a souvisejících případů užití. Ve výsledku pak vedl k souhlasnému stanovisku vedení Firmy s realizací projektu. Vytvářená aplikace byla pojmenována „Evidence veřejných zakázek“, zkratka EVZ. Jedná se o interní aplikaci Firmy, která pravidelně poskytuje automatické reporty o změnách z portálu veřejných zakázek dle příslušných parametrů, poskytuje rozhraní pro zobrazení informací z portálu veřejných zakázek, umožňuje vytvářet jednoduché statistiky a přehledy. Účelem aplikace je poskytnutí informací o VZ vedení Firmy a top managementu, obchodníkům a projektovým manažerům, kteří sledování těchto výběrových řízení mají v popisu práce, a také všem pracovníkům, kteří v rámci konkrétní pracovní činnosti potřebují získat potřebné údaje o konkrétní zakázce. Zároveň slouží pro vedení společnosti, které na základě dostupných statistik může rychle a efektivně zjistit stav úspěšnosti v porovnání s konkurencí na trhu VZ. Vedení firmy očekává, že zaměstnanci budou mít všechny potřebné informace o VZ k dispozici v rámci interní infrastruktury a nebudou nuceni přecházet mimo interní síť. Pro vytváření dlouhodobých strategií, plánování kapacit a nastavování parametrů dalšího vývoje firmy je potřebné mít k dispozici údaje o počtu vyhraných VZ, počtu zakázek, kterých se firma účastnila celkově, počtu VZ, které získali v příslušném období přímí konkurenti firmy, cenové objemy, za které tyto VZ byly uskutečněné.

Základní kroky, které v průběhu vývoje aplikace EVZ byly realizovány, jsou následující: 1) zjištění informační potřeby, požadavek od vedení společnosti na vytvoření zadání; 2) specifikace zadání, zjištění dostupných možností, konkretizace řešení, vytvoření dokumentace řešení ve smyslu „proof of concept“; 120 | 146

Anna Exnarová

3) odsouhlasení návrhu řešení, založení interního projektu; 4) detailní analýza; 5) návrh architektury řešení, design aplikace, interface, komunikace s okolím, začlenění do informačního systému/portálu firmy; 6) vývoj aplikace a její implementace; 7) testování aplikace, ladění; 8) nasazení aplikace do produkce.

V průběhu vývoje vznikala celá škála modelů, jejichž účelem bylo sdílení znalostí o aplikaci, komunikace způsobu řešení či problémové situace, záznam a dokumentace způsobu řešení, částečně modely také sloužily jako součást designu pro následné automatické generování databázových skriptů. Následující tabulka (Tab. 9 Modely aplikace EVZ) dokumentuje výčet jednotlivých typů modelů. Tab. 9 Modely aplikace EVZ

Typ modelu

Detaily

Modely před rozhodnutím o zahájení projektu vývoje aplikace EVZ Mentální model

Sdílení myšlenky, komunikace zadání směrem k PM

Mentální model

Vytvoření modelu o daném úkolu, vytvoření si vlastní představy o úkolu

Mentální model

Upřesnění modelu při zjišťování informací, komunikace s ostatními členy týmu

Myšlenková mapa

1) Popis potřeby řešení 2) Popis chování aplikace 3) Vstupující komponenty 4) Uživatelé a tvůrci 5) Vazba na okolí

Model systémového myšlení

1) Rozdělení VZ na trhu 2) Model toho, kolik VZ je pro nás vhodných, kolik e-mailů / událostí je odesláno, víme kolik času to bude, jak je potřebné rozdělit parametry

Diagram případů užití

Textový popis základních případů užití

Nestandardizovaný Návrh architektury model (fun diagram) Analytická fáze vývoje aplikace EVZ Myšlenková mapa

Upřesnění výše uvedeného modelu

121 | 146

Anna Exnarová

Typ modelu

Detaily

LDM – class model (diagram tříd)

LDM, číselníky aplikace EVZ ohledně VZ

Stavový diagram

Stavy veřejných zakázek

Use case (diagram případů užití)

Detailní use case společně s variantami řešení, scénáře

Návrh designu aplikace EVZ Diagram komponent

Komponentový diagram, popis dílčích částí řešení

Diagram nasazení

Fyzické umístění artefaktů řešení na prvcích infrastruktury

Implementace FDM – class model (diagram tříd)

Fyzický datový model obsahující rozložení atributů a operací do tříd

Testování Test case

Popis podmínek a proměnných, za kterých tester aplikace určí zda je aplikace či systém funkční

Tyto uvedené diagramy byly v průběhu vývoje aplikace reálně vytvořeny. Pro splnění cíle práce postačuje uvedení pouze relevantního výběru. Některé z modelů rovněž není možné uveřejnit z důvodu požadavku na utajení know-how řešení a implementace Firmy.

Činnosti před zahájením projektu a částečně v analytické fázi vývoje EVZ je možné chápat jako disciplínu Sběr požadavků v metodice UP. Analytická fáze vývoje aplikace EVZ a Návrh designu aplikace EVZ odpovídají disciplíně Analýza a návrh v metodice UP.

Vzhledem k požadavku na co nejvyšší míru efektivity projektu bylo potřebné zvažovat přínosy a metody realizace. Pro každý typ modely bylo potřebné ujasnit si jeho základní parametry: 1. Definice cílu a účelu modelu. 2. Výběr metodiky modelu – jazykové prostředky, nástroje a metodiky. 3. Sběr informací, které jsou nezbytné pro vytvoření modelu 4. Tvorba samotného modelu. 5. Využívání modelu uživateli. 6. Aktualizace modelu (příp. odstranění).

122 | 146

Anna Exnarová

Klíčovým bodem je krok 1 – definování cíle existence modelu je nesmírně důležité proto, aby bylo možné zvolit správný typ modelu, konkrétní postup jeho tvorby a celý jeho životní cyklus (s ohledem na náklady a přínosy, které samozřejmě každý model provází). Tyto skutečnosti pomohly také stanovit výše uvedený seznam modelů, který oproti rozsáhlým aplikacím byl výrazně zjednodušen. 5.3.4 Případy užití a katalog požadavků

Prvním analytickým krokem bylo zjištění kompletního seznamu požadavků, které mají být realizovány. Vznikl katalog požadavků (Tab. 10 Funkční požadavky (Firma, 2011)), ke kterému existuje také model v příslušné nástroji (viz Obr. 41 Diagram požadavků (Firma, 2011)). Tab. 10 Funkční požadavky (Firma, 2011)

Funkce

Popis

Nastavení kritérií pro stahování dat

Zadání základních kritérií pro výběr VZ z IS VZ a určení frekvence stahování

Stahování dat

Stažení relevantních dat z IS VZ, a to v požadovaném časovém intervalu

Prohlížení a třídění dat

Zobrazení dat VZ v požadovaném tvaru

Vyhledání dat

Vyhledání a zobrazení dat na základě zadaného výběrového kritéria

Odeslání dat e-mailem

Upozorňování na nově vyhlášené zakázky

Zobrazení detailu VZ

Link na detail zakázky v IS VZ

Aktualizace dat

Průběžná aktualizace (synchronizace) dat o evidovaných VZ

Evidence stavu VZ

Informace o stavu, uzavření VZ

Evidence dodavatelů

Pořízení DB dodavatelů

Aktualizace evidence dodavatelů

Průběžná údržba DB dodavatelů

Propojení VZ a dodavatele

Zajištění jednoznačného propojení VZ na dodavatele

Statistiky

Tvorba statistických výstupů podle zadaných kritérií

Export statistik

Export statistických výstupů

Evidence a aktualizace číselníků

Údržba číselníků souvisejících s danou oblastí

Workflow

Evidence jednotlivých kroků, osob a stavů v procesu zpracování veřejné zakázky

Správa aplikace

Nastavení parametrů aplikace, nastavení oprávnění uživatelů

Integrace s ostatními systémy

123 | 146

Anna Exnarová

Funkce

Popis

Údržba dat

Dlouhodobá archivace dat, rušení dat

Generování tisků

Zpracování tiskových výstupů - informace o veřejných zakázkách - statistiky

Obr. 41 Diagram požadavků (Firma, 2011)

Na základě získaných poznatků z prvotní fáze, včetně úpravy mentálních modelů na základě tvorby modelů systémového myšlení, jsem vytvořila návrh případů užití: • přehled o vyhlášených VZ (selekce podle daných kritérii); • přehled o uzavřených VZ a jejich výsledcích; • předání informace o VZ konkrétnímu obchodníkovi; • automatické zasílání e-mailu o nových VZ; • přiřazení konkrétní VZ danému obchodníkovi /projektovému manažerovi; • detail vybrané VZ (datum vyhlášení, cena, podmínky, kontaktní údaje zadavatele,…); • vyhledávání podle parametrů mezi VZ; • generování statistik. Na následujících obrázcích (Obr. 42 Use case model EVZ (Firma, 2011); Obr. 43 Use case model EVZ – doplněk (Firma, 2011); Obr. 44 Use case model EVZ – doplněk 2 (Firma, 2011)) jsou uvedeny dva diagramy případů užití, které byly vytvořeny analytikem. Ty byly transformovány do modelu Use case, v rámci kterého byly rozpracovány jednotlivé případy užití, diskutovány scénáře, tak aby na základě nich mohly být vytvořeny testovací scénáře.

124 | 146

Anna Exnarová

Množina navržených případů užití za použití výstupů modelů systémového myšlení a množiny případů užití vytvořených analytikem standardní cestou byla velmi podobná, komparací z nich byl vytvořen základní soubor případů užití.

Obr. 42 Use case model EVZ (Firma, 2011)

125 | 146

Anna Exnarová

Obr. 43 Use case model EVZ – doplněk (Firma, 2011)

Obr. 44 Use case model EVZ – doplněk 2 (Firma, 2011)

5.4 Analýza 5.4.1 Pohled na aplikaci EVZ z pohledu entit

Detailní prací s katalogem požadavků byla určena základní entita aplikace EVZ: Zakázky. Na tuto entitu z pohledu konceptuálního modelu byly navázány další dvě třídy: Dodavatelé a Zadavatelé. V první variantě analytického návrhu obsahoval model pouze entitu Zakázky. Tato entita by dokázala pokrýt informační potřeby související s vlastnostmi veřejné zakázky, jejími stavy, a bylo by možné evidovat i zadavatele, 126 | 146

Anna Exnarová

vítěze zakázky. Dle pravidel normalizace pro databázové entity ale byla identifikována možná potřeba rozšíření na několik entit. Modelem systémové dynamiky (Obr. 45 Možné stavy VZ – zkoumání entit), který byl vytvořen za účelem prozkoumání jednotlivých stavů VZ, bylo rovněž potvrzeno podezření na existenci dalších entit: seznamu zadavatelů VZ, zájemců a výherců. Možné entity zájemců a výherců bylo možné zapouzdřit pojmem dodavatelé. Tento model reprezentuje jednu ze základních schopností systémového myšlení – operační myšlení.

Obr. 45 Možné stavy VZ – zkoumání entit

Analytický konceptuální model tříd (viz Obr. 46) modeluje základní entity aplikace EVZ: „Zakázky“, „Dodavatelé“ a „Zadavatelé“. Hlavní entitou je entita „Zakázky“, na kterou jsou ostatní vázané. Hladiny z diagramu Obr. 45 reprezentují ty samé objekty, které byly identifikovány a použity v analytickém přístupu. Hladiny „Koncepce VZ“, „Vyhlášená VZ“, „Uzavřená VZ“, „Zrušená VZ“ jsou pro entitu „Zakázky“ z diagramu na Obr. 46 jejími stavy.

127 | 146

Anna Exnarová

Obr. 46 Konceptuální model tříd (Firma, 2011)

Konceptuální model základních entit byl dále rozšířen do doménového modelu (Obr. 47 Doménový model – původní návrh (Firma, 2011) a Obr. 48 Doménový datový model) s již podrobnějším výčtem entit. Základní entitou je entita Zakázky. Obsahem této entity jsou replikovaná data z portálu IS VZ týkající se příslušných veřejných zakázek. Na ní je napojena entita Stav s případnými komentáři či Poznámkami, dále entita Pracovníci – ve smyslu přiděleno obchodníkovi a nakonec entita Dodavatelé.

Obr. 47 Doménový model – původní návrh (Firma, 2011)

128 | 146

Anna Exnarová

Obr. 48 Doménový datový model

5.4.2 Stavový a procesní pohled na aplikaci EVZ

Již v předcházejících modelech a úvahách o aplikaci bylo patrné, že je nutné věnovat pozornost procesům a stavům, které se v systému vyskytují. Z pohledu Firmy jsou stavy veřejné zakázky vázané na to, zda se jí Firma účastní a nebo nikoliv a zda danou zakázku vyhraje. Na základě těchto informací by aplikace EVZ pokrývala informační potřebu o tom, jakých veřejných zakázek se Firma účastní, kolik z nich bylo úspěšných, jakého typu jsou vyhrané veřejné zakázky. Z toho by bylo možné usuzovat na kompetenci, která je ve Firmě zastoupena a je možné ji dále rozvíjet a uplatňovat při podávání nových nabídek. Na základě tohoto pohledu vznikl následující stavový model (viz Obr. 49 Původní návrh stavového modelu).

Obr. 49 Původní návrh stavového modelu

Následným ověřením zvoleného modelu se ale ukázalo, že není dostatečný a vyhovující pro implementaci v aplikaci EVZ. Důvodů bylo několik: • Odráží stavy pouze z pohledu Firmy. Aplikace EVZ by měla dát přehled o stavu VZ z pohledu celého systému IS VZ.

129 | 146

Anna Exnarová

• •

Tento pohled neumožní odpovědět na otázku, který konkurent vyhrál danou zakázku. Stavy Neúčast na VZ, Výhra VZ a Prohra VZ jsou stavy, které nás informují o tom, jak úspěšná je Firma. Po provedení dalšího zkoumání ale bylo potvrzeno, že pro evidování údaje naší úspěšnosti postačuje evidovat pouze entitu veřejné zakázky, její stav je možné zjistit z naplnění příslušných charakteristik.

Z hlediska sledování cíle existence aplikace (úspěšnosti Firmy ve výběrových řízeních) má uvedený stavový diagram pro aplikační implementaci skoro nulovou hodnotu. Nepostihuje cíl. Ke korekci modelu stavů jsem použila modelování situace pomocí modelů systémového myšlení – operační myšlení pomocí stavů a toků. Následující model (viz Obr. 50 Stavy veřejných zakázek z pohledu interních procesů Firmy) sloužil jako podklad pro brainstorming, který vyústil v úpravu stavového diagramu. V modelu jsou zobrazeny tři hladiny veřejné zakázky: • Všechny VZ = obsahuje všechny VZ, které jsou v systému veřejných zakázek, které na trhu existují. • Druhý stav obsahuje pouze ty VZ, kterých se Firma účastnila. • Poslední stav obsahuje ty, ve kterých Firma byla úspěšná a vyhrála.

Obr. 50 Stavy veřejných zakázek z pohledu interních procesů Firmy

Model Obr. 51 Stavový diagram (Firma, 2011) již dokumentuje finální podobu stavového modelu entity „Zakázky“.

130 | 146

Anna Exnarová

Obr. 51 Stavový diagram (Firma, 2011)

Model na Obr. 52 analyzuje vztah kvality dat, které jsou umístěny v aplikaci EVZ a úspěšnosti Firmy ve výběrových řízeních VZ. Jedná se o příčinně smyčkový diagram demonstrující aplikaci systémového myšlení, především jeho dovednosti myšlení v uzavřených a zpětněvazebných smyčkách. Levá smyčka je posilující, čím více je k dispozici dat v aplikaci EVZ, tím je větší možnost čerpání těchto dat pro rozhodování. Je tedy ve větší míře podpořen znalostní proces a rozhodování je kvalitnější. Čím kvalitnější je rozhodování (např. o tom jakých VZ se má Firma účastnit), tím je větší úspěšnost ve výběrových řízeních. Účastní na výběrových řízeních i realizaci veřejných zakázek je možné do aplikace EVZ vkládat další relevantní data. Zde se nabízelo evidovat i další data, které jsou pro firmu důležitá (např. který zaměstnanec pracoval na které VZ a tedy jakou novou kompetenci získal, kterou bude možné využít pro další VZ). Rozšíření o evidenci dat je diskutováno níže, jelikož překračuje hranice aplikace EVZ, nebylo v tomto modelu zobrazeno. Pravá smyčka je balanční, zvyšující se množství dat přímo ovlivňuje jejich složitost, což má přímé dopady na zvýšené náklady na správu dat. Pokud se dostaneme za únosnou hranici množství dat, sníží se jejich kvalita ve smyslu vypovídající schopnosti – příliš mnoho dat zahltí systém i uživatele. Snížení kvality dat má tedy dopad na snížení úrovně pokrytí informačních potřeb z aplikace EVZ a tedy i na kvalitu rozhodování o dalších investicích a VZ.

131 | 146

Anna Exnarová

Množství dat v EVZ

Rozpočet projektu +Složitost dat v EVZ

+

+

Vkládání dat do EVZ

+ Náklady na správu dat v EVZ

Vznik dat, které je do EVZ možné vložit +

Míra úspěšnosti ve VZ +

+ Čerpání dat z EVZ pro rozhodování

R (+)

B (-)

+

Kvalita dat v EVZ

Kvalita rozhodování o investicích Vypovídající hodnota dat v EVZ -

Obr. 52 Zvýšení kvality dat v EVZ

Jednou z informačních potřeb, která vyplynula z modelu interních procesů, je poskytnout informace o tom, zda firma má dostatečné kompetence a kvalifikované odborníky pro úspěšnou účast na konkrétním výběrovém řízení. Tento cíl nebyl původně při definování cílů aplikace identifikován. Vytvořený model identifikoval vztah mezi schopností aplikace tyto informace poskytovat a vazbami, které tuto schopnost posilují a oslabují. Následně byly identifikovány funkční moduly (viz Obr. 53 Možné rozšíření aplikace z pohledu správy kompetencí), které by takovou informační základnu plnily. Byly nalezeny překryvy s dalšími informačními systémy Firmy, konkrétně zaměstnaneckým portálem (kde jsou evidovány aktivity zaměstnanců a informace o nich) a Knowledgebase (kde jsou data o kompetencích).

Obr. 53 Možné rozšíření aplikace z pohledu správy kompetencí

Bylo rozhodnuto o tom, že tyto potenciální moduly jsou za hranicemi aplikace a vazba EVZ na Knowledbase a zaměstnanecký portál bude vybudována využitím identifikátoru

132 | 146

Anna Exnarová

VZ v těchto systémech (atribut idVZ entity Aktivita v zaměstnaneckém portálu a atribut idVZ dokumentu v Knowledgebase). 5.4.3 Návrh architektury systému

Architektura aplikace EVZ (Obr. 54) musela být navržena tak, aby především vyřešila základní omezení portálu IS VZ. Toto omezení spočívalo v neexistenci standardizovaného aplikačního rozhraní, které by bylo možné z aplikační vrstvy EVZ automatizovaně volat a získávat potřebné informace. Omezení vedlo k návrhu vytvoření služby aplikace EVZ, která bude vytěžovat příslušná data přímo z portálu IS ZV. Zároveň návrh musel být koncipován tak, aby byl v souladu s požadavky na omezený rozpočet realizace a využití stávajících zdrojů. Zároveň bylo počítáno s iterativním vývojem, nasazením prvního prototypu se základní funkčností, která se v dalších etapách bude dále rozvíjet. Účelem modelů architektury je představit způsob řešení, integraci do stávajících i na okolní systémy. Tyto modely plně patří dle autorsky navržené kategorizace do skupiny nestandardizovaných modelů, tj. modelů plně uzpůsobených a customizovaných pro konkrétní použití.

Obr. 54 Návrh architektury EVZ

5.5 Zhodnocení validace návrhu Praktická studie popisuje vývoj interní aplikace EVZ. V průběhu jejího vývoje bylo evidentní, že uplatnění systémových prvků do procesu vývoje má příznivé dopady na efektivitu dosažení výsledku. Standardní výstupy analytické fáze bylo možné velmi vhodně obohatit modely systémového myšlení i systémové dynamiky. Vývoj aplikace EVZ byl od začátku realizován standardním analytickým přístupem při současném uplatnění systémového myšlení, rovněž tak modely, které vznikaly. Pomocí modelů systémového myšlení a systémové dynamiky byl vývoj aplikace pozitivně ovlivněn a zkvalitněn, což je zřejmé z vyhodnocení přínosu jednotlivých modelů a jejich vlivu na analytické výstupy – katalog požadavků, případy užití, logický model, stavový model. Velmi podstatný je též důsledek systémového myšlení na nutnost změn v interních procesech organizace a jejích vnitřních parametrech pro zvýšení její úspěšnosti. 133 | 146

Anna Exnarová

Zároveň byly v procesu vývoje aplikace použity modely systémového myšlení na úrovni projektového řízení a komunikace se sponzorem projektu. Tyto přístupy obohatily řešení, vedly k preciznějšímu řešení a efektivnějšímu způsobu nasazení. Lze konstatovat, že systémový přístup pomohl ve správné interpretaci zadání a jeho formalizaci při návrhu skupin uživatelů systému a souvisejících případů užití. Ve výsledku pak vedl k souhlasnému stanovisku vedení Firmy (sponzora projektu) s realizací projektu. V procesu vývoje aplikace byly kroky analytického a systémového přístupu aplikovány postupně. Čistě analytickým přístupem by v tomto případě nebyla docílena požadovaná funkcionalita za obdobného nasazení zdrojů a v daném časovém horizontu. Praktickou aplikací, reálným používáním aplikace ve Firmě je možné konstatovat, že rozšířením analytických metod o systémové prvky dochází ke zlepšení výsledného produktu. Došlo k úpravě mentálních modelů, ke sjednocení terminologie a k vytvoření sdílených znalostí o problematice. Aplikace základních přístupů systémových věd pro pochopení problematiky se potvrdila jako přínosná. Proces úpravy mentálního modelu byl poměrně zjednodušen, pokud při jeho transformaci bylo pracováno s modely systémového myšlení a byly akcentovány základní systémové vlastnosti. Pro rozvoj aplikace EVZ navrhuji v dalším kroku využití modelů systémové dynamiky – uvažovaným příkladem je vytvoření modelu vytíženosti serverů při generování statistik a reportů. Generování statistik je výkonově poměrně náročné, s rostoucími objemy dat je potřebné jeho spouštění korigovat vůči ostatním procesům, které nad příslušnou databází běží. Model systémové dynamiky by umožnil k modelu vytvořit i simulační prostředí. Získání základních parametrů a vztahů pro relevantní simulaci je možné získat, neboť se jedná o technické poměrně snadno vyčíslitelné proměnné. Návrh uvedený v kapitole 4.2 – Uplatnění systémového myšlení v analytické fázi vývoje IASW prostřednictvím modelů systémového myšlení považuji, vzhledem k dokumentovanému uplatnění v praxi a zároveň vzhledem k provedené hloubce analýzy, za verifikovaný. Domnívám se, že hloubka analýzy, tj. kvalitativní aspekty jsou dostatečně relevantní pro posouzení verifikace, a jsou významnější než aspekt kvantitativního ověření.

134 | 146

Anna Exnarová

6 ZÁVĚR 6.1 Naplnění cílů práce Předložená práce obsahuje návrh rozšíření teorie systémového myšlení do oblasti vývoje IASW v jeho analytické fázi. V úvodu stanovené cíle byly v práci naplněny. V úvodu byl uveden generalizující cíl práce (tj. propojení pojmů systém, model a systémové myšlení z pohledu aplikovatelnosti v analytické fázi vývoje IASW). Byla provedena detailní rešeršní činnost a v rámci druhé a třetí kapitoly poskytnuty její výsledky. Rešerše svým provedením poskytuje dostatečnou hloubku relevantních informací, které byly vztaženy k objektu a předmětu zkoumání. Hlavnímu cíli práce (tj. vytvoření návrhu na uplatnění systémového myšlení v analytické fázi vývoje IASW) je věnována čtvrtá kapitola disertační práce. V této kapitole je představen konkrétní návrh, jak je možné systémové myšlení v analytické fázi vývoje IASW uplatnit. Nástrojem pro toto uplatnění je využití modelů systémového myšlení a systémové dynamiky. Tyto modely jsou diskutovány z pohledu jejich přínosů v případě, že budou při vývoji uplatněny. Jelikož vývoj IASW je rozvinutým oborem, bylo nutné začlenit systémové myšlení do kontextu již existujících přístupů. Hranice výzkumu byly dány modely dle notace UML. Dílčí cíle práce byly postaveny na jednotlivých oblastech zájmu výzkumu. V oblasti systém, model a systémové myšlení byly vytvořeny rámce poznatků, které jsou relevantní pro splnění hlavního cíle práce. Po úvodní první kapitole, druhá kapitola analyzuje pojmy systém a model. Poznatky v oblasti vývoje IASW byly analyzovány a v práci publikovány tak, aby na jedné straně informačně relevantně, ale na druhé straně obsahově dostatečně zajistili vytvoření rámce informací pro návrh uplatnění systémového myšlení v analytické fázi vývoje IASW. V třetí kapitole je diskutováno systémové myšlení s akcentem na pojmy systém a model. Systémové myšlení bylo představeno jako obor, který pomáhá řešit problémy komplexních, dynamických systémů. Lze rovněž konstatovat, že informační systémy, jsou komplexní systémy a není důvod, proč by nebylo možné i na tyto systémy (či jejich části) aplikovat principy systémového myšlení či systémové dynamiky a získat obdobné pozitivní výsledky jako je dosahováno v jiných oborech (např. ekonomických nebo ekologických) při použití těchto principů. V praktické části byl vytvořený návrh uplatnění systémového myšlení v analytické fázi vývoje IASW realizován a bylo dokumentováno užití poznatků systémových věd přímo ve firemní praxi. Na základě výsledků disertační práce považuji její hlavní i dílčí cíle za splněné a vlastní autorské přínosy práce za validované. Uplatnění systémového myšlení v analytické fázi vývoje IASW může být jedním z faktorů umožňujícím zvýšení efektivity IT projektů.

135 | 146

Anna Exnarová

6.2 Ověření hypotéz Výsledky uváděných výzkumů a závěry rešeršní činnosti potvrdily hypotézu o nízké úspěšnosti projektů vývoje softwaru. Jednou z klíčových příčin jsou problémy související s definováním požadavků a cílů vytvářeného systému, jakožto jednou z činností analytické fáze vývoje IASW. Práce potvrdila hypotézu, že v analytické fázi vývoje IASW existuje možnost uplatnění systémového myšlení. Charakteristiky systémového myšlení umožňují odstranit některé příčiny neúspěchu vývoje IASW. Uplatnit systémové myšlení v analytické fázi vývoje IASW je možné pomocí jeho modelů. Byla tedy rovněž potvrzena další hypotéza, že modely systémového myšlení je možné použít v analytické fázi vývoje IASW.Překročení hranic mentálních modelů bylo dokladováno také v případové studii, kdy v procesu vývoje byly upraveny mentální modely řešitelů na základě uplatnění systémového myšlení a vytvoření modelů systémového myšlení a systémové dynamiky. V praktické studii bylo na reálném případu z informatické praxe dokladováno, že aplikací systémového myšlení a systémové dynamikydojde k rozšíření znalostního portfolia. Byla diskutována otázka uplatnění simulačních modelů systémové dynamiky v průběhu vývoje IASW i následně jejich integrace do informačního systému organizace. Rovněž bylo potvrzeno, že je možné využít modely systémové dynamiky v průběhu vývoje IASW. Na základě rešeršní činnosti i vlastního návrhu bylo ověřeno, že modely systémové dynamiky mají své uplatnění v průběhu vývoje IASW. 6.3 Přínosy disertační práce Předložená disertační práce přináší následující přínosy: • Ucelená kritická rešerše systémového myšlení a jeho modelů. • Vytvoření rámce poznatků systémového myšlení relevantních pro vytvářený návrh. • „Propagace“ a rozšíření oborů systémové myšlení a systémová dynamika do odborných skupin zabývající se vývojem softwaru, resp. informačních systémů. • Vytvoření návrhu uplatnění systémového myšlení v analytické fázi návrhu a vývoje IASW. • Praktická studie dokladující použití uvedeného návrhu v praxi. Použití modelů systémového myšlení v analytické fázi vývoje IASW umožní: • Pochopit fungování systému, jednotlivé stavy a toky, které se v systému vyskytují. • Identifikovat smyčky v chování systému a najít způsob jejich zpracování. • Zachytit dynamiku systému a jeho prvků, pochopit zpoždění. • Popsat a pochopit příčiny a následky, které se v systému vyskytují. • Vytvořit simulace,specifikovat chování systému za konkrétních podmínek.

136 | 146

Anna Exnarová

Použití modelů systémového myšlení při návrhu IASW: • pomáhá provést revizi požadavků, nebo jejich stanovení; • poskytuje nástroje pro komunikaci, které více akcentují mentální a kognitivní procesy; • umožňuje lépe identifikovat entity a parametry, kterým je dále nutné věnovat pozornost (a budou dále rozvíjeny, např. v modelech dle notace UML); • umožňuje simulaci; • v neposlední řadě umožňuje akcentovat systémový přístup a poměrně efektivně zapojit systémové myšlení bez nutnosti umělého zavádění dovedností systémového myšlení. 6.3.1 Zhodnocení validace návrhu

Praktická studie popisuje vývoj IASW EVZ. V průběhu jejího vývoje bylo evidentní, že uplatnění systémových prvků do procesu vývoje má příznivé dopady na efektivitu dosažení požadovaného výsledku. Standardní výstupy analytické fáze bylo možné velmi vhodně obohatit modely systémového myšlení i systémové dynamiky. Vývoj IASW EVZ byl od začátku realizován standardním analytickým přístupem za využití interní vývojové metodiky (která se blíží metodice UP) a při využívání základní sady modelů dle notace UML. Pomocí modelů systémového myšlení a systémové dynamiky byl vývoj IASW pozitivně ovlivněn a zkvalitněn. Velmi podstatný byl též důsledek použití systémového myšlení, který upozornil na nutnost změn v interních procesech organizace a jejích vnitřních parametrech pro zvýšení její úspěšnosti na konkurenčním trhu. Zároveň byly v procesu vývoje IASW použity modely systémového myšlení na úrovni projektového řízení a komunikace se sponzorem projektu. Tyto přístupy obohatily řešení, vedly k preciznějšímu řešení a efektivnějšímu způsobu nasazení. Lze konstatovat, že systémový přístup pomohl ve správné interpretaci zadání a jeho formalizaci při návrhu skupin uživatelů systému a souvisejících případů užití. Ve výsledku pak vedl k souhlasnému stanovisku vedení Firmy (sponzora projektu) s realizací projektu. V procesu vývoje EVZ byly kroky analytického a systémového přístupu aplikovány postupně. Čistě analytickým přístupem by v tomto případě nebyla docílena požadovaná funkcionalita za obdobného nasazení zdrojů a v daném časovém horizontu. Praktickou aplikací, reálným používáním aplikace ve Firmě je možné konstatovat, že rozšířením analytických metod o systémové prvky dochází ke zlepšení výsledného produktu. Došlo k úpravě mentálních modelů, ke sjednocení terminologie a k vytvoření sdílených znalostí o problematice. Aplikace základních přístupů systémových věd pro pochopení problematiky se potvrdila jako přínosná. Proces úpravy mentálních modelů řešitelů byl podpořen, při jeho transformaci bylo pracováno s modely systémového myšlení a byly akcentovány základní systémové vlastnosti. Návrh uvedený ve čtvrté kapitole disertační práce považuji, vzhledem k dokumentovanému uplatnění v praxi, kde se stal součástí know-how firmy, a zároveň vzhledem k provedené hloubce analýzy, za verifikovaný. Domnívám se, že hloubka

137 | 146

Anna Exnarová

analýzy, tj. kvalitativní aspekty jsou dostatečně relevantní pro posouzení verifikace, a jsou významnější než aspekt kvantitativního ověření. 6.4 Předpokládané další využití práce Systémový přístup jako takový se ukazuje jako vhodný krok pro lepší výsledky vývoje softwaru. Uplatnění modelů systémového myšlení při vývoji softwaru je omezeno poměrně velkou finanční náročností a dosud velkou diskutabilní návratností investic. Množství finančních prostředků, které budou firmy ochotné investovat do rozvoje i praktické aplikace systémového myšlení a systémové dynamiky v podnikové praxi, se domnívám, že bude růst. Ale vzhledem ke stavu současného vývoje informačních systémů, stavu ekonomiky a celé společnosti, je nutné ne hledat, ale implementovat řešení. Systémově dynamické simulační modely v návrhu informačních systémů zatím nebývají obvyklé. Ale při vývoji složitých systémů s vysokou mírou variability, jsou modely podporující systémové myšlení a modely systémové dynamiky nepostradatelné. Zvláště v oblasti socioinformatiky a informačního managementu je tato oblast velmi perspektivní. Lze konstatovat, že uvedený návrh by vzhledem k obecnosti modelů systémového myšlení a systémové dynamiky bylo možné použít i v jiných konceptech životního cyklu IASW, i vývoje informačního systému. Vedle konkrétního uplatnění modelů systémového myšlení a systémové dynamiky při vývoji informačních systémů spatřuji velký potenciál v uplatnění principů systémového myšlení v tomto procesu a příp. vytvoření metodiky vývoje akcentující tyto principy. Další rozvoj této oblasti vidím v možném propojení simulačních modelů systémové dynamiky do oblasti vývoje informačních systémů. Rovněž velký potenciál se nabízí v integraci simulačních modelů – či spíše simulačních aplikací do informačních systémů podniků, pravděpodobně jako jedna z komponent manažerských informačních systémů. V oblasti aplikace systémové dynamiky v oblasti vývoje informačních systémů je možné provádět výzkum v oblasti možného propojení simulačních modelů systémové dynamiky do oblasti vývoje informačních systémů. Rovněž velký potenciál se nabízí v integraci simulačních modelů – či spíše simulačních aplikací do informačních systémů podniků, pravděpodobně jako jednu z komponent manažerských informačních systémů.

138 | 146

Anna Exnarová

7 POUŽITÁ LITERATURA ARLOW, J., NEUSTADT, I., 2007. UML 2 a unifikovaný proces vývoje aplikací: Objektově orientovaná analýza a návrh prakticky. Překlad B. Kiszka. 1. vyd. Praha: Computer Press, 2007. 567 s. ISBN 978-80-251-1503-9. AS, 2013. ADVISORY SERVICES SOLUTION OF CAMBRIDGE TECHNOLOGY PARTNERS. Project Success Assessment. In: [online]. 2009 [cit. 2012-04-18]. Dostupné z: http://ctp-advisoryservices.blogspot.cz/2009/01/project-success-assessment.html.

BÉBR, R., DOUCEK, P., 2005. Informační systémy pro podporu manažerské práce. 1. vyd. Praha: Professional Publishing, 2005, 223 s. ISBN 80-864-1979-7. BEER, D., 2010. Manažerské simulátory pro podporu strategického rozhodování v malých a středních firmách, disertační práce, VŠE-FIS, Praha, 2010. BENEŠ, M., 2002. Využití různých analytických metod při projektování informačních system. [s.l.], 2002. 83 s., 3 Vysoká škola ekonomická v Praze. Fakulta informatiky a statistiky. Vedoucí diplomové práce Helena Jilková. Dostupný z WWW: . BERTALANFFY, L. 1969. General system theory: foundations, development, applications. 1st pub. New York: George Braziller, 1969, xxiv, 295 s. ISBN 0-8076-0453-4. BRUCKNER, T., 2012. Tvorba informačních systémů: principy, metodiky, architektury. 1. vyd. Praha: Grada, 2012, 357 s. Management v informační společnosti. ISBN 978-80-247-4153-6. BUCHALCEVOVÁ, A., 2009: Metodiky budování informačních systémů. Praha: Oeconomica, 2009. 205 s. ISBN 978-80-245-1540-3. BUREŠ, V., 2011. Systémové myšlení pro manažery. Praha: Professional Publishing, 2011, 264 s. ISBN 978-80-7431-037-9. BUZAN, T., B., 2011. Myšlenkové mapy: probuďte svou kreativitu, zlepšete svou paměť, změňte svůj život. Vyd. 1. Brno: Computer Press, 2011, 213 s. ISBN 978-80-251-2910-4. BUZAN, T., 2007. Mentální mapování. Vyd. 1. Praha: Portál, 2007, 165 s. ISBN 978-80-7367200-3. CAO, L., RAMESH, B., ROSSI, M, 2009. Are Domain-Specific Models Easier to Maintain Than UML Models?, IEEE Software, vol. 26, no. 4, pp. 19-21, July/Aug. 2009, doi:10.1109/MS.2009.87. CAPRA, F., 2004. Tkáň života: nová syntéza mysli a hmoty. Praha, Academia, 2004; ISBN: 80200-1169-2.

139 | 146

Anna Exnarová

CLENDENING, R.J., 2009. A structured methodology for unifying functional analysis with systems analysis to enhance system behavior knowledge. Washington D.C., USA, 2009. Disertační práce. The George Washington University. COSTELLO, W., 2007: Computer_Based Simulations as Learning Tools: Changing Student Mental Models of Real-Word Dynamical Systems; Creative Learning Exchange. [online]. 2001. [cit. 2007-01-10]. Dostupné z WWW: http://www.clexchange.org/ftp/documents/Implementation/IM200104ChangingStuMentMod.pdf. DIJKMAN, R. M., DUMAS, M., OUYANG, C., 2008. Semantics and analysis of business process models in BPMN. Inf. Softw. Technol. 50, 12 (Nov. 2008), 1281-1294. DOI= http://dx.doi.org/10.1016/j.infsof.2008.02.006 DOBING, B., PARSON, J., 2006. How UML is used. Commun. ACM 49, 5, May. 2006, 109113. DOI= http://doi.acm.org/10.1145/1125944.1125949. DORSEY, P., DULCIAN, INC., 2004. UML Data Modeling in JDeveloper [online]. 2004 [cit. 2009-09-05]. Dostupný z WWW: . DOUBRAVOVÁ, J., 2002. Sémiotika v teorii a praxi; Portál, Praha, 2002. DOUCEK, P., 2004. Řízení projektů informačních systémů. 1. vyd. Praha: Professional Publishing, 2004, 162 s. ISBN 80-864-1971-1. DRUCKER, P.F., 1995. Nové reality. Praha, Management Press, 1995. ISBN 80-85603-85-3. DRUCKER, P. F., 1994. Řízení v turbulentní době. Praha: Management Press,1994. ISBN 8085603-7-5. FIRMA, 2011. Interní firemní materiály, dokumentace systému EVZ. 2011. FORRESTER, J.W., A961. Industrial dynamics. Waltham, MA: Pegasus Communications. 1961.FREY, CH., 2010. Mind Mapping Software User Survey. The MindMapping SoftwareBlog. [online]. 2010 [cit. 2013-04-20] http://www.humanmapping.com/blog/up/etudemm.pdf. GASSON, S., SHELFER, K. M., 2007. IT-based knowledge management to support organizational learning: Visa application screening at the INS. In: Information Technology & People, Vol. 20 Iss: 4, pp.376 – 399. Dostupné z: http://www.emeraldinsight.com/journals.htm?articleid=1640532&show=html. GRASL, O., 2008. Business Model Analysis: A Multi-Method Approach. In: 26th International Conference of the System Dynamics Society [online]. 2008. vyd. Atény, Řecko: System Dynamics Society, 2008 [cit. 2013-05-04]. Dostupné z: http://www.systemdynamics.org/conferences/2008/proceed/papers/GRASL405.pdf GROSSMANN, G., SCHREFL, M., STUMPTNER, M. 2008. Modelling inter-process dependencies with high-level business process modelling languages. In Proceedings of the Fifth on Asia-Pacific Conference on Conceptual Modelling - Volume 79 (Wollongong, NSW, Australia, January 01 - 01, 2008). A. Hinze and M. Kirchberg, Eds. Conferences in

140 | 146

Anna Exnarová

Research and Practice in Information Technology Series, vol. 325. Australian Computer Society, Darlinghurst, Australia, 89-102. HAINES, S. G., 2000. The Complete guide to systems thinking and learning. Amherst, MA: HRD Press, 2000. ISBN 08-742-5571-6. HODGSON, A. M., 1992. Hexagons for systems thinking. The European Journal of Systems Dynamics. 1992, roč. 59, č. 1. Dostupné z: http://www.brahmatwinn.unijena.de/fileadmin/Geoinformatik/projekte/brahmatwinn/Workshops/FEEM/Hodgson_1992_ Hexagons_for_system_thinking.pdf. HU, B. a A. LEOPOLD. Web - based Participatory System Dynamics Modelling – Concept and Prototype Development. In: 29th International Conference of the System Dynamics Society [online]. Washington DC, USA: System Dynamics Society, 2011 [cit. 2013-05-04]. Dostupné z: http://www.systemdynamics.org/conferences/2011/proceed/papers/P1179.pdf. CHANG, L.; TU, Y., 2005. Attempt to Integrate System Dynamics and UML in Business Process Modeling. In International System Dynamics Conferences [online]. Boston : July 17 21, 2005, 2005 [cit. 2011-01-24]. Dostupné z WWW: . CHECKLAND, P., 1981. Systems Thinking, Systems Practice. John Wiley&Sons Ltd., New York, 1981. CHERMACK, T. J., 2003. Mental Models in Decision Making and Imlications for Human Resource Development; SAGE Publications, Advances in Developing Human Resources, Vol. 5, No. 4, 408-422, [online]. 2003. [cit. 2007-01-15]. Dostupné z WWW: http://adh.sagepub.com/cgi/content/abstract/5/4/408. KOMÁREK, J., 2006. Systémové myšlení v manažerské výuce a praxi. In: konference Systémové přístupy 2006 KSA VŠE, Praha, 2006, ISBN 80-245-1153-3. KŘEMEN, J., 2007. Modely a systémy. 1. vyd. Praha: Academia, ČMT, 2007. ISBN 978-80200-1477-1. LARMAN, C., 2002. Applying UML and patterns : An introduction to object-oriented analysis and design and the Unified Process. 2nd edition. [s.l.] : Prentice Hall PTR, 2002. 627 s. ISBN 0-13-092569-1. MEADOWS, D. H., WRIGHT, D., 2008. Thinking in systems: a primer. White River Junction, Vt.: Chelsea Green Pub., 2008, xiii, 218 p. ISBN 16-035-8055-7. MILDEOVÁ, S., a kol., 2007. Tvorba manažerských simulátorů: vaše virtuální firma. Oeconomica, Praha, 2007. ISBN 978-80-245-1286-0. MILDEOVÁ, S., 2006. Simulation for the Shift of Paradigm. In: Magnani, Lorenzo. Model Based Reasoning in Science and Engineering. London : Department of Computer Science, 2006, s. 67–74. ISBN 1-904987-23-0. MILDEOVÁ, S., VOJTKO, V., 2006. Manažerské simulace dynamických procesů. Praha: Oeconomica, 2006. 106 s. ISBN 80-245-1055-3.

141 | 146

Anna Exnarová

MILDEOVÁ, S., 2003. The Reasons of Systems Dynamics Models Applications in the Decision Support Systems. In: Informatika 2003. Bratislava: Dom techniky ZSVTS Bratislava, 2003, s. 5. ISBN 80-233-0491-7. MILLEN, D. R., A. SCHRIEFER, D.Z. LEHDER a S.M. DRAY. Mind Maps and Causal Models: Using Graphical Representations of Field Research Data. In: Conference on Human Factors in Computing Systems [online]. 1997 [cit. 2013-03-17]. Dostupné z: http://www.sigchi.org/chi97/proceedings/poster/mil.htm#U2 MMR, 2013. MINISTERSTVO PRO MÍSTNÍ ROZVOJ ČR. Portál o veřejných zakázkách a koncesích. Ministerstvo pro místní rozvoj [online]. 2013 [cit. 2013-03-09]. Dostupné z: http://www.portal-vz.cz/cs/Uvodni-strana. MOLNÁR, Z., MILDEOVÁ, S., ŘEZANKOVÁ, H., BRIXÍ, R. KALINA, J., 2012. Pokročilé metody vědecké práce. 1. vyd. Praha: Profess Consulting s.r.o., 2012. ISBN 978-80-7259064-3. OMG, 2009. UML - Unified Modeling Language [online]. 2009 [cit. 2009-09-15]. Dostupný z WWW: . PAGE-JONES, M., 2001. Základy objektově orientovaného návrhu v UML. Přeložil K. Voráček. 1st edition. Praha : Grada Publishing, 2001. 368 s. ISBN 80-247-0210-X. PROVERBS, 2013. Systémové myšlení. Proverbs [online]. 2011 [cit. 2013-05-01]. Dostupné z: http://www.proverbs.cz/systemove-mysleni/. RIEDEMANN, C., FREITAG, R., 2009. Modeling Usage: Techniques and Tools. IEEE Software [online]. 2009, vol. 26, no. 2 [cit. 2009-06-13], s. 20-24. RICHMOND, B., 2004. An introduction to systems thinking: ithink software. Hanover, NH: High Performance Systems, 2004. ISBN 09-704-9210-3. RICHMOND, B., 1994. System Dynamics / System Thinking: Let’s just get on with it. [online]. International Systems Dynamics Conference in Sterling, Scotland 1994. [cit. 2007-01-20]. Dostupné z WWW: http://www2.umassd.edu/systemdynamics/paper.pdf. ROSICKÝ, A., 2005. Studijní materiály k předmětu Teorie a praxe informačních systémů: Vysoká škola ekonomická v Praze. Praha, KSA, 2005. ROSICKÝ, A., 2001. Systémové myšlení a/nebo poznání, Člověk jako prvek a jako pozorovatel systému. In: Sborník konference Systémové přístupy 2001 KSA VŠE, Praha, 2001, ISBN 80-245-0253-4. ŘEPA, V., 2007. Podnikové procesy. Procesní řízení a modelování. 2. vyd. Praha : Grada, 2007. 281 s. ISBN 978-80-247-2252-8. SENGE, P. M., 1995. Piata disciplína manažmentu, Systémové myslenie predpoklad rozvoja organizácií, Open Windows, Bratislava, 1995, ISBN 80-85741-10-5. SEVOCAB, 2013. Software and Systems Engineering Vocabulary. EEE, ISO/IEC JTC1, and PMI. [online] 2013. [cit. 2013-05-02]. http://pascal.computer.org/sev_display/index.action.

142 | 146

Anna Exnarová

SCHWABER, K., SUTHERLAND, J.V., 2012. The Crisis in Software: The Wrong Process Produces the Wrong Results. Software in 30 days: how agile managers beat the odds, delight their customers, and leave competitors in the dust. [online] Hoboken, N.J.: John Wiley, 2012, s. 14 [cit. 2013-04-02]. ISBN 978-1-118-20666-9. STERMAN, J. D., 2000. Business Dynamics: Systems Thinking and Modelling for a Complex World. USA: McGraw-Hill Higher Education, 2000. ISBN 0-07-231135-5. SVATÁ, V., 2009. Business Process Modelling in Government Institutuins. In DOUCEK, P., CHROUST, G., OŠKRDAL, V.. IDIMT 2009 : System and Humans - A Complex Relationship. [s.l.] : [s.n.], 2009. s. 95-104. ISBN 978-3-85499-624-8. SVOBODA, K., 2008. Objektovné modelování: Oficiální stránky k předmětu Objektové modelování [online]. 2008 [cit. 2008-11-01]. Dostupný z WWW: . TIGNOR, W., 2004. System Engineering and System Dynamics Models. In Science Applications International Corporation (SAIC) – International Conference of the System Dynamics Society. [online] Oxford, England: July 25 – 29, 2004, 2004 [cit. 2011-02-20]. Dostupné z WWW: http://www.systemdynamics.org/conferences/2004/SDS_2004/PAPERS/137TIGNO.pdf. TIGNOR, W., 2003. Stock and Flow, and Unified Modeling Language Relationships. In: 21 System Dynamics Conference, New York City, New York, USA. [online]. System Dynamics Society, 2003 [cit. 2013-11-02]. Dostupné z: http://www.systemdynamics.org/conferences/2003/proceed/PAPERS/206.pdf TIGNOR, W., 1999. System Dynamics Models and the Object-Oriented Paradigm. In: 17th International Conference of the System Dynamics Society [online]. 1999. vyd. Wellington, Nový Zéland: System Dynamics Society, 1999 [cit. 2011-05-04]. Dostupné z: http://www.systemdynamics.org/conferences/1999/PAPERS/PARA109.PDF TMCG, 2013. TRANSENTIS MANAGEMENT CONSULTING GMBH & CO. KG. Business Prototyping Blog: Introduction to System Dynamics [online]. 2013 [cit. 2013-04-16]. Dostupné z: http://www.business-prototyping.com/step-by-step-tutorials/introduction-tosystem-dynamics/ TOMAN, P., 2003. Teorie a praxe informace; VŠE Praha, Praha. UMEMOTO, K., 2002. Managing Existing Knowledge is Not Enough: Knowledge Management Theory and Practice in Japan. In Strategic Management of Intellectual Capital & Organizational Knowledge.[online] Oxford, Oxford University Press, pp.463-476. [cit. 2012-12-10]. Dostupné z WWW: http://www.jaist.ac.jp/ks/labs/umemoto/km_e.html. VLÁDA ČR. Digitální Česko v. 2.0: Cesta k digitální ekonomice. 2013. Dostupné z: http://www.vlada.cz/assets/media-centrum/aktualne/Digitalni-Cesko-v--2-0_120320.pdf VODÁČEK, L., ROSICKÝ, A., 1997. Informační management: Pojetí, poslání a aplikace. 1. vyd. Praha: Management Press, 1997. ISBN 80-85943-35-2. VOJTKO, V., 2005. Co je to systémové myšlení? [online] 2005. [cit. 2007-05-20]. Dostupné z WWW: http://proverbs.cz/default.asp?id=4&mnu=4. 143 | 146

Anna Exnarová

VOŘÍŠEK, J., NOVOTNÝ, O., 2012. Závěry a doporučení VŠE a NERV k řízení IT ve VS. In: Přístupy k řízení IT architektur a center sdílených služeb ve veřejné správě [online]. VŠE Praha, 9.2.2012 [cit. 2012-02-10]. Dostupné z: http://www.cssi.cz/cssi/system/files/all/2012_02_seminar-vorisek_novotny.pdf VOŘÍŠEK, J., 2008. Principy a modely řízení podnikové informatiky. 1.vyd. Praha: Oeconomica, 2008. ISBN 978-80-245-1440-6. WATSON, A., 2010. Visual Modelling: past, present and future [online]. Object Management GroupTM, c1997-2010 [cit. 2010-01-07]. Dostupný z WWW: . YAP, M., 2011. Anti-Patterns: Part 4: Copy the Old One. In: AgileIQ Blog [online]. 2011 [cit. 2012-25-11]. Dostupné z: http://www.solutionsiq.com/resources/agileiqblog/?Tag=product%20owner. ZHANG, Z., YANG, Z., LIU, Q., 2008. Modeling Knowledge Flow Using Petri Net, kam, pp.142-146, 2008 International Symposium on Knowledge Acquisition and Modeling, 2008.

144 | 146

Anna Exnarová

8 VLASTNÍ PUBLIKACE EXNAR, Z., EXNAROVÁ, A., 2013. Kauzalita a systémové myšlení. In: Sborník z 44. ročníku konference Systémové inženýrství 2013 – Systémové inženýrství a informatika. Květen 2013, Fakulta ekonomicko-správní Univerzity Pardubice, Pardubice. (Sborník z konference, v tisku) EXNAR, Z., EXNAROVÁ, A., 2009. Kybernetika, model, simulace. In: LACKO, B. Šedesát let kybernetiky. Brno: Akademické nakladatelství CERM, 2009, s. 61–66. 299 s. ISBN 97880-7204-662-1. EXNAROVÁ, A., 2013 Uplatnění systémového myšlení v analytické fázi vývoje aplikací. In: Acta Informatica Pragensia, Vysoká škola ekonomická v Praze, 2013. ISSN: 1805-4951. (V recenzním řízení do recenzovaného vědeckého časopisu.) EXNAROVÁ, A., DALIHOD, M., MILDEOVÁ, M., 2011. Measuring Systems Thinking Ability. Prague 09.06.2011 – 10.06.2011. In: Efficiency and Responsibility in Education. Praha : Czech University of Life Sciences in Prague, 2011, s. 66–74. ISBN 978-80-2132183-0. EXNAROVÁ, A., 2011. Modely ve vývoji informačních systémů. In: Journal of Technology and Information Education. Olomouc: Katedra technické a informační výchovy, Pedagogická fakulta Univerzity Palackého v Olomouci, 2/2011, Volume 3, Issue 2. ISSN 1803-6805. EXNAROVÁ, A., 2010. Modely v informatice. Praha 11.02.2010. In: Sborník prací účastníků vědeckého semináře doktorandského studia Fakulty informatiky a statistiky VŠE v Praze. [online] Praha: Oeconomica, 2010, s. 21–28. ISBN 978-80-245-1647-9. URL: http://fis.vse.cz/studium/doktorske-studium/den-doktorandu/den-doktorandu-2010/. EXNAROVÁ, A., 2009. Models in Informatics. Jindřichův Hradec 09.09.2009 – 11.09.2009. In: IDIMT-2009 System and Humans – A Complex Relationship. Linz: Trauner Verlag universitat, 2009, s. 175–184. ISBN 978-3-85499-624-8. EXNAROVÁ, A., 2008. Proč modelujeme? Praha 06.11.2008. In: Systémové přístupy 2008 [CD-ROM]. Praha: Oeconomica, 2008, s. 1–9. ISBN 978-80-245-1481-9. MILDEOVÁ, S., DALIHOD, M., EXNAROVÁ, A, 2012. Mental Shift Towards Systems Thinking Skills in Computer Science. Journal on Efficiency and Responsibility in Education and Science [online], 2012, roč. 5, č. 1, s. 25–35. ISSN 1803-1617. URL: http://www.eriesjournal.com/_papers/article_165.pdf. MILDEOVÁ, S., VOJTKO, V. 2008. Systémová dynamika. 2. přeprac. vyd. Praha : Oeconomica, 2008. 150 s. ISBN 978-80-245-1448-2. (Další autoři: EXNAROVÁ, A., BEER, D., VELEHRADSKÝ, P.). MILDEOVÁ, S., a kol., 2007. Tvorba manažerských simulátorů: vaše virtuální firma. Oeconomica, Praha, 2007. ISBN 978-80-245-1286-0.

145 | 146

Anna Exnarová

9 PŘEHLED ZKRATEK BPM(N)

Business Process Modeling (Notation)

CASE

Computer-aided software engineering, počítačem podporované softwarové inženýrství

CLD

Causal-loop diagram, příčinně-smyčkový diagram

DP

Disertační práce

EVZ

Aplikace Evidence veřejných zakázek, vyvíjená aplikace pro potřeby Firmy

FDM

Fyzický datový model

HW

Hardware

ICT

Informační a komunikační technologie

IS

Informační systém

IS VZ

Informační systém veřejných zakázek, www.isvz.cz; portál veřejných zakázek http://www.vestnikverejnychzakazek.cz/

LDM

Logický datový model

MMDIS

Multidimensional Management and Development of Information System

MMR

Ministerstvo pro místní rozvoj

Model

Grafická nebo jiná reprezentace reálného systému

OO

Objektově orientovaný přístup

OOAD

Objektově orientovaná analýza a design

SM

Systémové myšlení

SD

Systémová dynamika

SFD

Stock and flow diagram, diagram hladin a toků

SW

Software, programové vybavení, část IS

UML

Unified Modeling Language

UP

Unified process

VZ

Veřejné zakázky

146 | 146