Oral Exam Questions 2021-2022 PDF

Otázky (tematické okruhy) ke zkoušce 4IT216 verze 18.1.2022 +-----------------------------------+-----------------------------------+ | 1 | Definujte pojmy: byznys, systém, | | | informační systém, informační | |...

Otázky (tematické okruhy) ke zkoušce 4IT216 verze 18.1.2022 +-----------------------------------+-----------------------------------+ | 1 | Definujte pojmy: byznys, systém, | | | informační systém, informační | | | technologie, aplikační software | | | (aplikace), informatická služba, | | | informatický zdroj, projekt. Jaké | | | jsou vztahy mezi těmito pojmy? | | | | | | **Byznys** = organizace, která | | | poskytuje produkty nebo služby | | | zákazníkům, na rozdíl od podniku | | | zahrnuje i neziskové organizace a | | | organizace veřejné správy. | | | | | | **Systém** = celek tvořený svou | | | jednak celistvostí (danou obvykle | | | cílem či účelem) a jednak | | | souhrnem částí (komponent, prvků) | | | a jejich vzájemných, často | | | dynamických vztahů (interakcí). | | | | | | **Informační systém** = je | | | systém, jehož účelem je zajištění | | | správných informací na správné | | | místě ve správný čas. Tyto | | | informace jsou dodávané zpravidla | | | lidem, kteří jsou součástí byznys | | | systému. | | | | | | **Informační technologie** = | | | hardware + software pro sběr, | | | přenos, ukládání a distribuci | | | informací. | | | | | | **Aplikační software** = software | | | (programové vybavení), určený pro | | | použití uživatelem (v tomto | | | případě se jedná o uživatele, | | | kteří řeší informační potřebu | | | v byznysu) | | | | | | **Informatická služba** = ICT | | | služba jsou koherentní (spojité) | | | aktivity a/nebo informace | | | dodávané poskytovatelem ICT | | | služby příjemci služby. Tato | | | služby je vytvářena ICT procesy, | | | které při svém průběhu konzumují | | | ICT zdroje. | | | | | | **Informatický zdroj** = | | | Komponenta (HW, SW, | | | data-informace-znalost) nutná | | | k tvorbě a provozu informatické | | | aplikace / služby. | | | | | | **Projekt** = je jedinečný proces | | | sestávající z řady koordinovaných | | | a řízených činností s daty | | | zahájení a ukončení, prováděný | | | pro dosažení cíle, vyhovuje | | | specifickým požadavkům, včetně | | | omezení daných časem, náklady a | | | zdroji. | +===================================+===================================+ | 2 | Jaké je místo IS/ICT a jeho | | | řízení při řízení organizace? | | | Jaký je vztah mezi byznys cíli, | | | byznys procesy, informatickými | | | službami, informatickými procesy | | | a informatickými zdroji? Popište | | | model SPSPR. | | | | | | **Jaké je místo IS/ICT a jeho | | | řízení při řízení organizace?** | | | IS/IC dnes zabírá klíčové místo | | | při řízení organizace. Podporuje | | | obchodní procesy a zjednodušuje a | | | zefektivňuje tím jejich | | | provádění. Díky nim mohou | | | organizace poskytovat nové | | | služby, které byly předtím | | | nemyslitelné, díky čemuž mohou | | | dosahovat vyšších obratů. | | | | | | **Jaký je vztah mezi byznys cíli, | | | byznys procesy, informatickými | | | službami, informatickými procesy | | | a informatickými zdroji?** Jsou | | | navzájem provázané, bez nich by | | | nemohl být podnik efektivně | | | řízen. | | | | | | Podnikové procesy směřují k | | | naplnění byznys cílů. | | | Informatická služba je zaměřená | | | na podporu jednoho nebo více | | | byznys procesů. Informatický | | | zdroj je součást nutná k tvorbě a | | | provozu informatické služby. | | | | | | **Byznys cíl** = to, čeho chce | | | podnik dosáhnout na základě své | | | globální strategie. Podnikové | | | cíle by měly být tzv. | | | | | | SMART. (konkrétní, měřitelné, | | | dosažitelné, realistické, správně | | | načasované) | | | | | | **Byznys proces** = je proces, | | | kterým byznys zajišťuje naplnění | | | byznys cílů, reaguje na významné | | | události a | | | | | | zajišťuje produkci plánovaných | | | výstupů (produktů, služeb apod.) | | | Pojmem proces rozumíme skupinu | | | navazujících činností, které jako | | | celek přinášejí hodnotu | | | zákazníkovi (procesu). | | | | | | **Informatická služba** = viz | | | otázka 1. | | | | | | **Informatický proces** = viz | | | otázka 1. | | | | | | **Informatický zdroj** = viz | | | otázka 1. | | | | | | **Popište model SPSPR.** Tento | | | model využívá ICT služby jako | | | základního nástroje pro | | | komunikaci mezi byznysem a ICT | | | útvarem. Model definuje | | | zodpovědnosti byznys a ICT | | | manažerů při řízení vztahu | | | byznys- podniková informatika. | | | Základem modelu je řízení vztahu | | | byznys-informatika v pěti | | | vzájemně provázaných vrstvách | | | (S-Strategy, P- Business | | | Processes, S -ICT Services, P | | | -ICT Processes, R -ICT | | | Resources). ICT služby jsou v | | | modelu chápány jako rozhraní mezi | | | byznysem a informatikou, přes | | | které poskytovateli ICT služeb | | | podporuje jednotlivé byznys | | | procesy podniku či jejich dílčí | | | aktivity. ICT službu lze buď | | | nakoupit na ICT trhu, nebo ji | | | dodávat interně. V druhém případě | | | musí ICT útvar podniku zajistit | | | ICT procesy, které službu dodají, | | | a ICT zdroje (HW, SW, data, lidé | | | \... ), jež jsou pro průběh ICT | | | procesů nezbytné. | | | | | | Cílem rozdělení řídicích aktivit | | | do pěti vrstev je: | | | | | | jasné určení zodpovědností | | | různých typů manažerů/specialistů | | | v podniku, | | | | | | zprůhlednění způsobu | | | dekompozice podnikových cílů až | | | na úroveň řízení ICT, | | | | | | vytvoření schématu, ze kterého | | | je možné odvodit vhodné metriky | | | úspěšnosti jednotlivých typů | | | procesů a za | | | | | | ně odpovědných manažerů. | | | | | |  | +-----------------------------------+-----------------------------------+ | 3 | Charakterizujte tyto alternativy, | | | resp. situace: | | | | | | vývoj aplikace vers. provoz | | | aplikace, | | | | | | IASW vers. TASW, | | | | | | řešení vlastními zdroji vers. | | | řešení externími zdroji | | | | | | **Vývoj aplikace** | | | | | | Vývoj aplikace je proces, jehož | | | cílem je dosažení plánované změny | | | informačního systému podniku | | | (aplikace). Změna se může týkat | | | kterékoliv komponenty IS (nová | | | aplikace, změna technologické | | | infrastruktury apod.). Podstatné | | | změny se realizují projektem. | | | Ukončením projektu vzniká nová | | | verze IS podniku (aplikace). | | | | | | **Provoz aplikace** | | | | | | Provoz IS (aplikace) je procesem, | | | který zajišťuje běh jednotlivých | | | aplikací a dodávání ICT služeb | | | koncovým uživatelům. Služby | | | musejí být provozem IS zajištěny | | | tak, aby dosahovaly vlastností | | | (například dostupnost, doba | | | odezvy, bezpečnost), které byly | | | mezi provozovatelem služby a | | | jejím zákazníkem dohodnuty. | | | | | | **Individuální aplikační software | | | (IASW)** | | | | | | Při použití IASW je [aplikace | | | vytvořena na míru podle potřeb | | | podniku], instalována | | | na definované technologické | | | | | | platformě a poté pro uživatele | | | daného podniku provozována. | | | Funkcionalita aplikace je | | | navržena tak, aby optimálně | | | podporovala činnosti podnikového | | | procesu, pro který je určena. | | | Výhodou této alternativy je, že | | | podnik může aplikací podpořit | | | svoje specifické procesy a | | | dosažení specifických cílů na | | | trhu. | | | | | | **Typový aplikační software | | | (TASW).** | | | | | | Aplikace je vytvořena a dále | | | rozvíjena specializovaným | | | výrobcem generalizací požadavků | | | určité třídy podniků například | | | bank, výrobců automobilů apod. I | | | když celkové náklady vývoje TASW | | | jsou výrazně vyšší než v případě | | | IASW, cena licence TASW je pro | | | zákazníka obvykle nižší, protože | | | celkové náklady vývoje se | | | rozpustí mezi více zákazníků. | | | Další výhodou je, že celková doba | | | nasazení aplikace je kratší, | | | protože se instaluje již hotový | | | produkt. Nevýhodou ale je, že | | | podporovaný podnikový proces se | | | musí přizpůsobit logice a | | | možnostem TASW. Na druhé straně | | | přední výrobci TASW zabudovávají | | | do funkcionality svých produktů | | | nejlepší praktiky, které jsou v | | | daném odvětví známy. Instalací | | | TASW a přizpůsobením svých | | | podnikových procesů tak může méně | | | vyspělý podnik aplikovat | | | zkušenosti a nejlepší praktiky | | | lídrů na trhu. Další nevýhodou | | | TASW je, že podnik obvykle | | | nevyužije veškerou funkcionalitu | | | TASW, tzn., že de facto kupuje i | | | to, co nepotřebuje. | | | Z charakteristiky vyplývá, že | | | TASW je výhodné volit především | | | pro vysoce standardizované | | | aplikace jako účetnictví, | | | zpracování mezd, správa řízení | | | dokumentů apod. | | | | | | **Řešení vlastními zdroji vs | | | řešení externími zdroji** | | | | | | Kritéria, která v tomto | | | rozhodování hrají nejdůležitější | | | roli, jsou: náklady, | | | spolehlivost, bezpečnost dat a | | | míra závislosti podniku na | | | externích dodavatelích. | | | | | | V současnosti většina podniků | | | řeší vývoj aplikací outsourcingem | | | nebo nákupem TASW, neboť vlastní | | | vývoj softwaru bývá časově i | | | cenově nákladnější varianta. | | | Provoz IS naopak většina podniků | | | v současnosti řeší vlastními | | | zdroji. Důvodem je, že zatím tuto | | | alternativu vyhodnocují jako | | | nákladově výhodnější a zejména | | | méně rizikovou z hlediska | | | bezpečnosti dat. Nicméně počet | | | firem, které přecházejí na | | | outsourcing provozu celého IS, | | | resp. některé z aplikací IS, | | | neustále roste a dá se | | | předpokládat, že do konce druhého | | | desetiletí 21. století bude | | | outsourcing provozu a zejména | | | jeho varianta SaaS převažující | | | formou provozu podnikových IS. | +-----------------------------------+-----------------------------------+ | 4 | V čem spočívají zásadní | | | odlišnosti vývoje nové aplikace | | | | | | je-li aplikace řešena jako IASW | | | | | | je-li aplikace řešena jako TASW | | | | | | **Vývoj řešen jako IASW** | | | | | | **Výhody** | | | | | | - IS šitý na míru potřebám | | | podniku (funkce IS přesně | | | odpovídají požadavkům | | | podnikových procesů) | | | | | | - inkrementální růst IS dle | | | potřeb podniku | | | | | | - detailní znalost | | | provozovaného IS/ICT je přímo | | | v podniku | | | | | | - konkurence nezná silné a | | | slabé stránky podnikového | | | IS/ICT | | | | | | - snadná reakce | | | | | | **Nevýhody** | | | | | | - vysoké náklady | | | | | | - do IASW nejsou obvykle | | | zabudovány celosvětově | | | osvědčené pracovní postupy | | | | | | - dlouhá doba řešení | | | | | | - obvykle nižší kvalita IASW a | | | obtíže s integrací celého | | | IS/ICT zapříčiněné relativně | | | nízkou kvalifikací domácích | | | řešitelů | | | | | | - nízká parametričnost IASW - | | | jestliže vývoj IASW je | | | odvozen od okamžitých | | | požadavků uživatelů a | | | požadavky nejsou dostatečně | | | zobecněny, není řešení | | | realizováno jako parametrické | | | a tím se prodlužuje a | | | prodražuje budoucí údržba | | | | | | - při fluktuaci řešitelů značná | | | rizika nekonzistencí | | | | | | **Vývoj řešen jako TASW** | | | | | | **Výhody** | | | | | | - rychlá realizace | | | | | | - nízké náklady | | | | | | - lze vybrat osvědčená řešení | | | pro každou část IS | | | | | | - TASW má zapracované best | | | practises | | | | | | - TASW je parametrické a tím je | | | možné řešit řadu nových | | | požadavků pouze jiným | | | nastavením parametrů místo | | | reprogramováním | | | | | | **Nevýhody** | | | | | | - procesy v podniku se musejí | | | přizpůsobit možnostem TASW | | | | | | - obtížná integrace různých | | | aplikací do jednoho IS - | | | vysoké nároky na řešitelský | | | tým | | | | | | - obtíže s údržbou vazeb mezi | | | aplikacemi a tím i relativně | | | nízká stabilita celého IS | +-----------------------------------+-----------------------------------+ | 5 | V čem spočívají zásadní | | | odlišnosti vývoje nové aplikace | | | | | | je-li aplikace vyvíjena pomocí | | | vlastních zdrojů | | | | | | je-li aplikace vyvíjena pomocí | | | externích zdrojů (dodavatelsky) | | | | | | **Vývoj řešen pomocí vlastních | | | zdrojů** | | | | | | **Výhody** | | | | | | - inkrementální růst dle potřeb | | | podniku | | | | | | | | | | | | - konkurence nezná silné a | | | slabé stránky podnikového | | | IS/ICT | | | | | | - detailní znalost | | | provozovaného IS/ICT je přímo | | | v podniku | | | | | | - snadná reakce na okamžité | | | potřeby uživatelů | | | | | | **Nevýhody** | | | | | | - většinou vysoké náklady a | | | dlouhá doba řešení | | | | | | - aplikovatelné jen pro některý | | | ASW (téměř vyloučené pro HW a | | | ZSW) | | | | | | - při fluktuaci řešitelů značná | | | rizika nekonzistencí | | | v systému | | | | | | **Vývoj řešen pomocí externích | | | zdrojů** (Nákup celého IS/ICT od | | | generálního dodavatele) | | | | | | **Výhody** | | | | | | rychlá realizace, nízké náklady | | | | | | optimálně využity znalosti | | | interních i externích specialistů | | | | | | profesionální řešení každé | | | komponenty i celého IS/ICT | | | | | | lze vybrat osvědčená řešení pro | | | každou část IS | | | | | | integrace všech komponent je | | | garantována dodavatelem | | | | | | dodavatelem může být | | | garantována i stabilita vývoje | | | IS/ICT | | | | | | **Nevýhody** | | | | | | rizika úniku konfidenčních | | | informací mimo podnik | | | | | | závislost na dodavateli a jeho: | +-----------------------------------+-----------------------------------+ | 6 | V čem spočívají zásadní | | | odlišnosti provozu aplikace | | | | | | je-li aplikace provozována | | | pomocí vlastních zdrojů | | | | | | je-li aplikace provozována | | | pomocí externích zdrojů | | | (dodavatelsky) | | | | | | **Provoz pomocí vlastních | | | zdrojů** | | | | | | **Výhody** | | | | | | rychlá realizace (údržby) | | | | | | nezávislost na externím | | | dodavateli | | | | | | **Nevýhody** | | | | | | při nákupu TASW po jednotlivých | | | komponentách od různých | | | dodavatelů a provozu vlastními | | | | | | zdroji jsou kladeny vysoké nároky | | | na interní řešitelský tým, čímž | | | vzniká nestabilita IS spojená | | | | | | s obtížnou údržbou vazeb mezi | | | jednotlivými aplikacemi | | | | | | **Provoz pomocí externích | | | zdrojů** | | | | | | **Výhody** | | | | | | snížení nároků na provozní | | | personál | | | | | | podnik se může lépe soustředit | | | na svůj hlavní předmět činnosti, | | | | | | snadnější přizpůsobování | | | kapacit IT dle potřeb podniku, | | | | | | jedná-li se o velmi silného | | | systémového integrátora | | | (dodavatele) provozujícího IS/ICT | | | pro | | | | | | několik zákazníků, mohou být | | | náklady jednotlivých zákazníků | | | ještě nižší | | | | | | dodavatelem může být | | | garantována i stabilita vývoje | | | IS/ICT, | | | | | | možnost využívání | | | nejprogresivnějších technologií | | | (systémový integrátor může | | | rychleji | | | | | | obměňovat svůj technologický | | | park), | | | | | | rozložení rizik mezi podnik a | | | systémového integrátora, | | | | | | rychlé dosažení požadovaných | | | služeb, | | | | | | vysoká flexibilita služeb -- | | | služby lze aktivovat a | | | deaktivovat dle potřeb podniku | | | | | | obvyklá vyšší úroveň kvality | | | služeb a spolehlivosti | | | | | | **Nevýhody** | | | | | | vyšší náklady (ale obvykle při | | | vyšší kvalitě služeb a při vyšší | | | spolehlivosti) | | | | | | při stejné úrovni služeb jako | | | při interním provozu bývají | | | náklady nižší | | | | | | roste závislost na systémovém | | | integrátorovi a jeho: | +-----------------------------------+-----------------------------------+ | 7 | Principy modelování při analýze a | | | návrhu IS/ICT. Co je to model? | | | K čemu slouží? Jak vypadá? Na | | | základě čeho se vytváří? Jaké | | | modely znáte? Jaké jsou kritické | | | faktory úspěchu modelování. | | | | | | **Principy modelování při analýze | | | a návrhu IS/ICT** | | | | | | **Model** | | | | | | Modelem rozumíme obecně | | | reprezentaci něčeho jiného, která | | | má některé podobné vlastnosti | | | jako to původní, takže pomocí | | | této reprezentace lze to původní | | | poznat. Model je obvykle | | | zjednodušující, tedy volí jen | | | některé podobné vlastnosti toho | | | původního, podle zvoleného | | | hlediska. | | | | | | Příkladem modelu může být model | | | auta jako hračka napodobující | | | skutečný automobil, může to být | | | maketa | | | | | | stavby, může jít o matematický | | | model nějakého jevu a podobně. | | | Dále se podíváme na možnosti | | | modelování | | | | | | byznys systémů. | | | | | | **Obecná charakteristika modelu** | | | | | | Model je formulován jako | | | systém, tedy souhrn prvků a | | | jejich vazeb. Konkrétní povaha | | | prvků i | | | | | | vazeb je dána použitým hlediskem | | | (data/operace) | | | | | | Zvláštní význam v modelu | | | zaujímají jeho hraniční prvky, | | | tedy prvky, které mají vazby s | | | okolím | | | | | | systému (modelu). Těmito prvky je | | | definována hranice systému, tedy | | | jeho kontext. | | | | | | Obsah modelu (souhrn jeho prvků | | | a vazeb) je vždy objektivní, tedy | | | každý prvek modelu musí | | | | | | odpovídat některému objektu | | | reálného světa. | | | | | | Vnitřní struktura systému | | | (uspořádání prvků) je vždy | | | poplatná struktuře světa. | | | | | | Modelování -- princip tří | | | „architektur" | | | | | | **Modelování slouží pro | | | možnost:** | | | | | | prozkoumat možnosti změn bez | | | vlivu na reálné činnosti | | | | | | vystopovat příležitosti | | | vylepšení | | | | | | odhadnout a měřit účinky | | | zamýšlených změn | | | | | | demonstrovat a sledovat průběh | | | analýzy | | | | | | předávat nápady efektivně a | | | jednoznačně mezi členy | | | projektového týmu | | | | | | **Využití** | | | | | | model aktuálního stavu X | | | cílového stavu | | | | | | analýza vlastností reality na | | | základě modelu | | | | | | řízení reality na základě | | | modelu | | | | | | Není tedy často účelné vytvářet | | | matematický model, ale obvykle se | | | tvoří model pomocí diagramu nebo | | | sady diagramů tvořených sjednanou | | | notací. Modely se pak většinou | | | snaží zahrnout celý systém z | | | nějakého zvoleného hlediska | | | (například procesní model, datový | | | model, funkční model a další). | | | | | | **Jak vypadá?** | | | | | | Může vypadat např. jako diagram. | | | Tvorba diagramů pro modelování | | | systému bývá obvykle svázána | | | sadou pravidel, tzv. notací. Pro | | | zachycení okamžitého byznys | | | nápadu podnikatele může být | | | vhodné použít obrázek jako náčrt | | | bez striktní notace, která by | | | autora omezovala, takže má | | | svobodu v komunikačním nástroji. | | | Při preciznější analýze a návrhu | | | s následnou automatizací je | | | naopak nutné použít model s | | | konkrétní striktní notací (v | | | různých případech různou). | | | | | | **Jaké modely znáte?** | | | | | | **Kritické faktory úspěchu | | | modelování** | | | | | | jsou takové faktory, které mohou | | | zapříčinit neúspěšnost | | | modelování, patří mezi ně např.: | | | | | | jednotliví řešitelé musí být | | | dostatečně seznámeni s | | | problematikou projektu -- | | | komunikace s klientem | | | | | | musí dodržovat předem | | | domluvenou jednotnou techniku | | | modelování (notace UML, BPMN) | | | | | | dobré rozvržení práce: např. | | | přiřazení procesů jako je | | | fakturace -- specialistovi na | | | finanční procesy (kryje se s | | | klíčovými faktory úspěchu) | | | | | | Je nutná kontrola konzistence | | | -- při použití více typů modelů | | | -- aby každý z nich nevypovídal | | | něco jiného (více typů a pohledů | | | pomáhá k většímu pochopení | | | požadavků na IS/ICT, a proto při | | | nekonzistenci modelů může dojít v | | | budoucím vývoji k problémům) | | | | | | snaha o zachycení všech | | | aspektů, které jsou pro zkoumání | | | systému podstatné a eliminace | | | aspektů nepodstatných | +-----------------------------------+-----------------------------------+ | 8 | Podnikový proces. Co je to | | | proces? Popište principy | | | procesního řízení a možnosti | | | dokumentace procesů. Popište | | | model KBPR. Možnosti optimalizace | | | procesů. | | | | | | **Proces** = Pojmem proces | | | rozumíme skupinu navazujících | | | činností, které jako celek | | | přinášejí hodnotu zákazníkovi | | | (procesu). Další definicí může | | | být: proces je sada logicky | | | spojených úloh prováděných tak, | | | aby přinášely definovaný výstup | | | byznysu. | | | | | | **Procesní řízení** = sleduje na | | | sebe navazující činnosti podle | | | logiky jejich návazností a podle | | | hodnoty, kterou společně | | | vytvářejí pro zákazníka, a to za | | | podpory informačních technologií. | | | Tyto skupiny činností | | | procházející přes různé funkční | | | oblasti podniku se nazývají | | | procesy. | | | | | | **Principy procesního řízení** | | | | | | Procesní řízení podniku je v | | | současné době převládajícím | | | stylem podnikového řízení. Proto | | | je mu věnován | | | | | | další výklad. Aby analytik mohl | | | byznys analýzu dobře provést, | | | musí vědět, jaké jsou principy | | | procesního řízení, | | | | | | jaká jsou klíčová rozhodnutí při | | | tomto stylu řízení a v jakém | | | pořadí se obvykle provádějí. | | | Základní fáze řízení | | | | | | u procesně řízené organizace jsou | | | zachyceny na obrázku 3.6. | | | | | |  | | | | | | **Dokumentace procesů** | | | | | | Po prozkoumání jednotlivých | | | procesů je možné modelovat | | | procesní architekturu systému | | | pomocí | | | | | | diagramů nazývaných diagram | | | návaznosti procesů, procesní dům | | | nebo procesní mapa. V těchto | | | diagramech | | | | | | jsou zobrazeny všechny procesy | | | probíhající v systému a jsou | | | nějakým způsobem logicky | | | seskupeny. Často | | | | | | takový diagram vypadá jako dům, | | | proto se mu říká procesní dům | | | (process house). | | | | | | **Metoda KBPR (Knowledge Based | | | Process Reengineering)** | | | | | | Východiskem metody je kritika | | | \"mechanických\" přístupů | | | k mapování a reengineeringu | | | podnikových procesů, které jsou | | | příliš technicky zaměřené, málo | | | respektují znalosti lidí | | | podílejících se na procesech a | | | nedostatečně zohledňují nutnou | | | míru kreativity člověka v | | | příslušném procesu. | | | | | | Metoda rozlišuje čtyři úrovně | | | modelování a návrhu procesu. | | | Úrovně se liší zejména v tom, | | | jaká úroveň znalostí a zkušeností | | | se předpokládá jednak na straně | | | pracovníků navrhujících proces a | | | jednak na straně pracovníků | | | podílejících se na realizaci | | | procesu. Je věcí tvůrců definice | | | procesu, aby pro každý z procesů | | | vybrali optimální úroveň. | | | Jednotlivé úrovně popisu jsou | | | charakterizovány následovně. | | | | | | 1. Úroveň | | | | | | cíle procesu (například | | | produkt/služba a jejich | | | charakteristiky), | | | | | | událost aktivující daný proces, | | | | | | role, resp. funkční místo | | | zodpovědné za celý proces | | | (vlastník procesu), | | | | | | zákazník procesu, | | | | | | kvalitativní a kvantitativní | | | metriky procesu, | | | | | | omezující podmínky procesu | | | (například finanční nebo časový | | | limit pro průběh procesu). | | | | | | 2. Úroveň\ | | | V druhé úrovni je navíc | | | definován výstup procesu | | | (například požadovaná | | | struktura výsledného | | | dokumentu, model výrobku, | | | výkres produktu apod.). | | | | | | 3. Ve třetí úrovni jsou navíc | | | definovány: | | | | | | seznam činností, které jsou | | | součástí procesu (není však | | | definována návaznost činnosti, | | | | | | seznam rolí, resp. funkčních | | | míst, podílejících se na | | | realizaci procesu (role ale | | | nejsou přiřazeny k činnostem), | | | | | | seznam všech externích vstupů | | | do procesu (ale vstupy nejsou | | | přiřazeny k činnostem), | | | | | | seznam vhodných informatických | | | nástrojů pro podporu procesu. | | | | | | 4. Úroveň | | | | | | 5. Čtvrtá úroveň definice | | | procesu je typická pro | | | hromadnou výrobu - například | | | výrobu automobilů, výrobu | | | jídel | | | | | | v restauracích McDonald | | | apod.Firemní znalost versus | | | znalost pracovníků | | | | | | Ve čtvrté úrovni jsou navíc | | | definovány: | | | | | | vstupy a výstupy každé | | | činnosti, | | | | | | návod (algoritmus) každé | | | činnosti, | | | | | | návaznost činností, | | | | | | přiřazení zodpovědných rolí k | | | jednotlivým činnostem, | | | | | | doba trvání každé činnosti, | | | | | | náklady činností, resp. náklady | | | celého procesu. | | | | | | První úroveň popisu procesu se | | | využívá v případě, když | | | akumulovaná firemní znalost je | | | nedostatečná, resp. když každý | | | průběh procesu je velmi odlišný | | | vlivem měnících se podmínek a | | | externích faktorů. Taková situace | | | nastává zejména u procesů | | | strategického řízení. První | | | úroveň tak předpokládá vysoce | | | kvalifikované a kreativní | | | pracovníky, kteří při průběhu | | | procesu budou schopni naplánovat | | | a realizovat všechny dosud | | | nedefinované charakteristiky | | | procesu. | | | | | | Naopak čtvrtá úroveň popisu | | | procesu předpokládá vysokou | | | kvalifikaci a rozsáhlé zkušenosti | | | pracovníků | | | | | | definujících proces. V praxi se | | | často pro definici procesu na | | | této úrovni využívají znalosti | | | pracovníků konzultačních firem, | | | kteří znají nejlepší praktiky | | | používané v dané oblasti | | | podnikání. Čtvrtá úroveň současně | | | představuje nejvyšší stupeň | | | standardizace průběhu procesu. | +-----------------------------------+-----------------------------------+ | 9 | Procesní modelování -- cíle, | | | principy, standardy, modely, | | | komponenty | | | | | | **Cíle procesního modelování** | | | | | | Simulace reálných procesů, | | | které probíhají v organizaci | | | | | | Zachytit chování reality | | | podnikových procesů | | | | | | Grafické znázornění procesů | | | (diagramy procesů) | | | | | | **Principy** | | | | | | Vhodné pojmenování | | | | | | Dodržení grafické notace | | | | | | **Standardy** | | | | | | **ARIS (EPC diagram)** | | | | | | V diagramu jsou vertikálně shora | | | dolů modelovány střídavě objekty | | | znázorňující události a činnosti | | | (objekt pro událost a stav | | | procesu je totožný). Šipka mezi | | | těmito objekty zobrazuje | | | následnost (logickou nebo | | | časovou). Vedle činností se dále | | | zobrazují jejich informační | | | vstupy a výstupy (obvykle pomocí | | | objektů dokument, cluster, | | | dokumentovaná znalost apod.), a | | | to vlevo shora vstupy (šipkou | | | směrem k činnosti) a vlevo dolů | | | výstupy (šipkou směrem od | | | činnosti). Vpravo vedle činnosti | | | se zobrazují aktéři procesu | | | pomocí procesních rolí, funkčních | | | míst, organizačních jednotek či | | | týmů , a dále například aplikace | | | použité při výkonu činnosti. | | | Vztah aktéra a činnosti může být | | | různého typu (například provádí, | | | spolupracuje apod.). Větvení a | | | spojování větví procesů se | | | modeluje pomoci logických | | | operátorů | | | | | | **BPMN** | | | | | | Business Process Model and | | | Notation- BPMN je otevřený | | | standard, jehož aktuální verze je | | | dostupná na stránkách | | | http://www.bpmn.org. Standard | | | BPMN je podporován většinou | | | společností, které se zabývají | | | tvorbou nástrojů pro podporu | | | procesního modelování. BPMN je | | | chápán jako komplexní přístup, | | | který kombinuje služby, činnosti, | | | data, procesy, choreografie a | | | konverzace do souvisejícího | | | systému, který umožňuje | | | automatizaci. Proces se typicky | | | zobrazuje (modeluje) zleva | | | doprava, začíná startovací | | | událostí, následuje sekvence | | | činností a končí koncovým stavem. | | | Notace pro modelování procesů | | | rozlišuje množství typů událostí | | | a interních stavů procesů zvaných | | | triggery, a také typů šipek pro | | | rozlišení normálního toku, | | | podmíněného toku, toku zprávy | | | apod. Celkově je modelování v | | | BPMN primárně určeno pro | | | zobrazení logiky toku procesu a | | | pro sladění toku procesu mezi | | | různými účastníky procesu. Proto | | | se pro aktéry procesu používá | | | přístup plaveckých drah, zde | | | rozlišený na bazén (pool)- | | | účastník procesu a dráha (lane) | | | pro skupinu souvisejících | | | činností. | | | | | | **Erikssonovo a Penkerovo | | | rozšíření UML** | | | | | | Erikssonovo a Penkerovo rozšíření | | | UML se pokouší vyřešit nevhodnost | | | standardu UML pro procesní | | | modelování. Diagram aktivit se | | | hodí pro základní modelování | | | návaznosti činností čili | | | workflow, neumožňuje však vhodně | | | modelovat některé byznys aspekty | | | procesů , například kvantitativní | | | cíle procesu. Eriksson a Penker | | | navrhují modelovat proces jako | | | celek a sledovat u něj vstupní a | | | výstupní objekty, kontrolní | | | | | | a podpůrné zdroje a hlavně cíl | | | procesu. Tento přístup pak lze | | | kombinovat se standardním | | | diagramem aktivit | | | | | | UML pro zobrazení toku činností v | | | rámci procesu, případně pro | | | předávání událostí mezi procesy. | | | | | | **Modely** | | | | | | Nevím, co je tím myšleno, může | | | být to samé co standardy. | | | | | | **Komponenty:** | | | | | | o Proces | | | | | | o Činnost | | | | | | o Podnět | | | | | | o Událost | | | | | | o Stav | | | | | | **Proces** | | | | | | „Účelně naplánovaná a realizovaná | | | posloupnost činností, ve kterých | | | za pomoci odpovídajících zdrojů | | | | | | probíhá transformace vstupů na | | | výstupy." | | | | | | „Soubor činností, který vyžaduje | | | jeden nebo více vstupů a tvoří | | | výstup, který má nějakou hodnotu | | | | | | pro zákazníka." | | | | | | \- Je iniciován událostí. | | | | | | \- Výstupem je událost | | | signalizující dosažení jednoho z | | | koncových stavů procesu. | | | | | | \- Cílem procesu je „hodnota pro | | | zákazníka" | | | | | | **Činnost** | | | | | | Základní prvek procesu, | | | zpracování vstupu na výstupy. | | | Činnost může být komplexní nebo | | | primitivní | | | | | | (elementární) prováděna | | | | | | \- pouze člověkem („zkoušení | | | studenta") | | | | | | \- strojem („vylisování nárazníku | | | auta") | | | | | | \- člověkem za podpory stroje | | | („přišití knoflíku") | | | | | | \- člověkem za podpory ASW | | | („zaevidování známky ze zkoušky") | | | | | | \- ASW („hlídání poklesu zásoby | | | pod limit") | | | | | | **Událost** | | | | | | Externí podnět procesu/činnosti. | | | Reprezentuje požadavek | | | libovolného zákazníka/aktéra | | | procesu. | | | | | | Například: příchod objednávky | | | zákazníka | | | | | | **Stav** | | | | | | Výsledek činnosti v systému. | | | Například: faktura zkontrolována | +-----------------------------------+-----------------------------------+ | 10 | Objektové modelování -- cíle, | | | principy, standardy, modely, | | | komponenty | | | | | | **Cíl** | | | | | | - zachytit strukturu reality | | | | | | - používá se k tomu jazyka UML | | | (obecný a univerzální | | | objektově orientovaný | | | modelovací jazyk, | | | | | | - sloučení několika populárních | | | OO přístupů), složitost je | | | redukována rozdělením do | | | subsystémů a | | | | | | - delegováním „odpovědnosti" na | | | jednotlivé objekty. | | | | | | **Principy** | | | | | | Rozložení reality na jednotlivé | | | prvky (objekty), které spolu | | | interagují, každý objekt (věc, | | | prvek, jev, | | | | | | pojem v reálném světě) je něčím | | | jedinečný. | | | | | | **Standardy** | | | | | | Diagram tříd - použití: | | | | | | Prozkoumání problémové domény | | | (typy objektů reality) | | | | | | Analýza požadavků IS =\> ASW | | | (konceptuální =\> logický model) | | | | | | Zachycení detailního návrhu | | | objektově orientovaného SW | | | | | | **Komponenty** | | | | | | objekt = prvek, jev, věc, pojem | | | v reálném světě | | | | | | třída = Kategorie, skupina věcí | | | se stejnými vlastnostmi a stejným | | | chováním (nebo | | | | | | podobným), tj. ve smyslu množina | | | objektů stejného typu | | | | | | atribut = podstatná | | | charakteristika/vlastnost | | | třídy/asociace | | | | | | asociace = vztah mezi dvěma | | | objekty | | | | | | operace = metoda, funkce, | | | kterou může objekt vykonávat | +-----------------------------------+-----------------------------------+ | 11 | Datové modelování -- cíle, | | | principy, standardy, modely, | | | komponenty | | | | | | **Cíl** | | | | | | zobrazuje funkce jako | | | transformace vstupních datových | | | toků na výstupní, zároveň | | | umožňuje znázornit kontext | | | systému (vstupy z okolí a výstupy | | | do okolí) a uchovávaná data | | | | | | **Princip** | | | | | | zobrazuje funkce, jako | | | transformace vstupních datových | | | toků na výstupní, znázorňuje se | | | diagramem datových toků (DFD, ten | | | je spojován se strukturovanými | | | metodami) | | | | | | **Standardy** | | | | | | K zachycení datového modelu na | | | konceptuální úrovni se používá | | | řada různých modelovacích | | | | | | nástrojů. Mezi nejznámější patří | | | různé modifikace tzv. ER(A) | | | diagramů. | | | | | | **Modely** | | | | | | Při tvorbě datových modelů se | | | dají rozlišovat (podobně jako u | | | modelu tříd) následující úrovně | | | popisu datových struktur: | | | | | | **Komponenty** | | | | | | symboly | | | | | | terminátor (v obdélníkovém | | | rámečku), | | | | | | datový tok (musí mít směr), | | | | | | funkce (v kolečku), | | | | | | data store (ohraničené čárami), | +-----------------------------------+-----------------------------------+ | 12 | Funkce IS, hierarchie funkcí, | | | funkcionalita IS. Funkční | | | modelování -- cíle, principy, | | | standardy, modely, komponenty. | | | | | | **Funkce IS** = prvek chování | | | informačního systému, resp. | | | aplikace. | | | | | | » Příklady: založení nového | | | zákazníka, vystavení objednávky, | | | vložení obrázku do textu. | | | | | | **Funkcionalita IS** = souhrn | | | funkcí IS | | | | | | » je-li funkce zpracovávána | | | transakčním zpracováním nazývá se | | | transakcí | | | | | | **Hierarchie funkcí IS** | | | | | | **Standardy** | | | | | | **DFD - Data Flow Diagram** | | | (diagram datových toků) slouží | | | jako grafický prostředek návrhu a | | | zobrazení | | | | | | funkčního modelu systému- je | | | základním nástrojem pro vyjádření | | | konceptuálního funkčního modelu | | | ve | | | | | | strukturovaných metodách. | | | | | |  | | | | | | **Komponenty** | | | | | | V DFD se používají základní | | | prvky: | | | | | | Funkce (v DFD označované ne | | | úplně správně jako \"proces\"56, | | | proto je v níže uvedeném obrázku | | | nahrazen | | | | | | oproti původnímu zdroji | | | správnějším označením \"funkce\", | | | tedy \"co systém dělá\", jaké | | | vstupy transformuje | | | | | | na výstupy, bez