STUDIJJNÍ OPOR O RA DELOVÁNÍÍ BUSIINESSS MOD D Doc. RNDr. Vladimír Krajčík, Ph.D D. O Ostrava 201 11
Náázev: Business m modelování Au utoři: Doc. RNDrr. Vladimír Krrajčík, Ph.D. Vyydání: první, 2011 Po očet stran: 66 Vysoká ško Tisk: ola podnikán ní, a. s. Vysoká ško ola podnikán ní, a. s. v Ostravě Vyydala: Michálkovvická 1810/18 81 710 00 Osttrava – Slezsská Ostrava © © Vysoká škol la podnikání,, a.s. v Ostravě ISBN 978‐80‐7 7410‐029‐1
OBSAH Úvvod ....................................................................................................................................... 4 VÝÝSTUPY Z UČ ČENÍ .................................................................................................................. 5 1
2.
Procesní řízení a mod delování ........................................................................................ 6 1.1
Proccesní řízení ....................................................................................................... 6
1.2.
Proccesní modelo ování ........................................................................................... 10
Metodikyy a metody tvvorby podnikového IS ............................................................... 13 2.1 Metodikky a nástrojee podpory projektů podnikových IS ........................................... 14
3.
2.2.
Vym mezení metod dik, metod a nástrojů podnikových ISS...................................... 15
2.3.
Obecné principyy metodik vývvoje a tvorbyy projektu ISS ...................................... 17
Modelování procesů v podniku ................................................................................... 20 3.1. Proccesní mapováání jako základ tvorby modelů ................................................. 21 3.2.
4.
Refeerenční modeely řízení podnikové info ormatiky .............................................. 25
Metodikyy řízení projeektů informačních systém mů v podnicícch ................................... 40 4.1.
Mettodiky budovvání informaččních systém mů v podnicícch ................................... 41
4.2.
Přeh hled jednotlivvých metodik řízení proje ektů IS v pod dnicích ............................ 42
Metodikaa Project Management B Body of Know wledge (PMBOK) ................................ 42 Metodikaa ARIS ............................................................................................................. 45 Metodikaa RUP (Rational Unified P Process) .................................................................. 46 Metodikaa Prince 2 ( P Projets IN a C Controled Environment) ........................................ 49 5.
Modely u uživatelských h požadavků a jejich nasaazení při tvorrbě IS v podniku ............ 52 5.1.
Procces analýzy p požadavku užživatelů na in nformační syystém ............................. 53
5.2.
Zpraacování a přístupy k uživaatelským požžadavkům ........................................... 56
5.3.
Popiis procesu získávání uživaatelských po ožadavků ............................................. 59
Záávěr ..................................................................................................................................... 65 Po oužitá literattura a další zd droje .......................................................................................... 66
Bu usiness modeelování
Ú Úvod Vá ážení studenti, přřed Vámi sto ojí úkol abso olvovat mod dul Business modelováníí. Cílem toho oto modulu je j seeznámení se základy pro ocesního řízen ní a modelování informa ačních proceesů v podniku. Da alší kapitolyy modulu jso ou věnoványy popisu priincipů metod d tvorby po odnikového IS, I vččetně jejich vvymezení a o obecným prin ncipům jejich h nasazení. Využitím výýše popsanýcch prrincipů v pra axi lze dosá áhnout efekktivního řízeení informaččních služeb b v podnicích. So oučástí modu ulu je i přehlled jednotlivvých metodikk řízení projeektů IS v pod dnicích, včetn ně po odrobného zp pracování modelu uživattelských poža adavků. Prro srozumitelné, příjemnéé a zajímavéé chvíle strávvené s tímto m modulem jseem ho pro Vá ás zp pracoval ve fo formě studijn ní opory. Vytvvořený průvo odce je Vaším m pomocníkeem, který Vám ussnadní absollvování modu ulu. Při cíleném a koncen ntrovaném sstudiu tohoto o modulu brzzy do osáhnete požžadovaných výsledků Va aší práce, z ttohoto důvo odů doporuču ujeme, abyste jednotlivé kap pitoly procházeli systema aticky a důkla adně. Cílem m mé snahy je usnadnit Va aši prráci, proto jednotlivé j ka apitoly na sebe s navazujjí a bylo byy neefektivníí a bezúčeln né přřeskakování kkapitol, či jejjich povrchníí procházení.. Zá ávěrem Vám m přeji mno oho příjemn ných chvil strávených s p studiu ttohoto kurzu. při Neezapomínejtte na to, že jako j pedago ogové jsme tady t pro Váss, a proto jee třeba s nám mi ro ovněž komun nikovat. Děěkuji a přeji V Vám ještě jednou hodně úspěchů při studiu. Au utor
4
ČENÍ VÝÝSTUPY Z UČ
V VÝSTUPY Y Z UČENÍ Po o úspěšném absolvování modulu bud dou student schopni: Porozumět podnikkovým proceesům Vnímaat vliv processního řízení vv podniku Analyzzovat probleematiku modelování v po odniku Vymezzit základní p pojmy – metodika, metoda a nástroj podnikového IS Vysvěttli principy m metodik v pro ojektech IS Apliko ovat nástrojee na konkrétn ní podnikovýý IS Charakterizovat po odnikový mo odel v processním pohledu Zpraco ovat přehled d o referenčn ních modelecch podnikovéé informatikyy Charakterizovat m metodiky vývo oje a nasazení informačn ních systémů ů v podniku Porovnat metodikky PMBOK a A ARIS Vymezzit úrovně řízzení v metod dice PRINCE 2 Zařadiit zpracován ní uživatelských požadavvků do konttextu podnikání a vývoje inform mačního systému Popsat strukturu u zpracován ní uživatelských požad davků z hleediska vývoje mačního systému inform Popsat požadovan né vlastnosti a strukturu sspecifikace u uživatelských h požadavků
5
Bu usiness modeelování
1 Proce esní řízení a mo odelován ní Ú ÚVOD V kapitole see seznámíte se základyy procesního o řízení ve vazbě na p podnik a jeh ho infformační fun nkce a získátte základní přřístupy k bussiness modellování. CÍÍLE KAPITOLY Y Po o prostudová ání této kapiitoly a vypra acování úkollů budete UM MĚT: Porozumět podnikkovým proceesům Vnímaat vliv processního řízení vv podniku Analyzzovat probleematiku modelování v po odniku Po o prostudová ání této kapiitoly a vypra acování úkollů ZÍSKÁTE: Poznatkový systém m z oblasti prrocesů a pro ocesního řízení Inform mace o význaamu a příklad dech tvorby podnikového o procesního o modelu Po o prostudová ání této kapiitoly a vypra acování úkollů BUDETE SC CHOPNI: Vymezzit základní p pojmy v oblaasti procesníh ho řízení a m modelování Identiffikovat příno osy a důvodyy zavádění prrocesního řízzení Vymezzit, co od váss bude zaved dení procesního řízení vyyžadovat
1..1 Processní řízení Kaaždý proces existuje proto, aby přispíval p k naplnění n cílů podniku. Snažíme‐li se zleepšovat naše výsledky, zaměřujemee pozornost na průběh procesů. To o znamená, že neeřešíme nap př. personáln ní oddělení,, ale processy oblasti peersonalistikyy. Je to rozd díl, prrotože proceesy přecházeejí mezi různ nými organizzačními jedn notkami a tíím, že bycho om zaasáhli pouze do jedné z nich, mohli byychom celý p proces zhoršit. DEFIN NICE
Proces je op P pakovatelný sled činnosstí, jejichž výýsledkem jee měřitelný výstup, kterrý ěčí potřebu.. u uspokojuje n Naapříklad: vyd dání knihy, přijetí p studenta, podání žádosti o grrant, ale i přříprava oběd da, prraní prádla, aatd. DEFIN NICE
Procesní řízeení je takovýý styl řízení organizace, kdy na orgaanizaci nahlíížíme jako na P n s systém, kterrý produkuje nějaké výýrobky nebo služby, které k uspoko ojují potřeb bu z zákazníků org ganizace. 6
Prrocesní řízení a modelováání Orrganizaci ho odnotíme po odle spokojenosti jejich h zákazníků a ne podle objemovýých ukkazatelů. Teento princip p hodnocen ní se uplatňuje i uvnitř organizaace. Napříkllad no ormotvorný útvar nebud deme hodno otit podle to oho, kolik no ových norem m vyproduku uje, ale podle toho o, jak jsou no ormy použiteelné a používvané zaměstn nanci. Taato orientacce na zákazníka, na stáále dokonalejší uspokojjování jeho potřeb zajiistí prrůběžné zlep pšování proccesů. Děláme jen to, co o vede k usp pokojení zákkazníka. Dossud prrováděné čin nnosti, kteréé nepřispívally k dosažen ní tohoto cíle a pouze sspotřebovávaaly naaše zdroje, neprovádíme. Sttanovení cílů ů a ukazateelů, jejich naplnění n je velice důleežité, protožže právě niimi po oměřujeme efektivitu a a výkonnosst procesů. Musíme věědět, k čem mu má procces sm měřovat – cíll a jak se to procesu daříí ‐ ukazatel. Neméně důlležité je to, aaby cíl proce esu přřispíval k nap plnění cíle orrganizace jakko celku. To znamená, žee definice cílů ů musí začít na úrrovni nejvyšššího manageementu orgaanizace. Vedení organizaace má vizi –– ví, čeho ch hce do osáhnout, a u určí strategiii – dlouhodo obé cíle organ nizace a vyzn náváním jakýých hodnot jiich do osáhnout. Tu uto strategii musí rozpraacovat do cíllů pro nižší sstupně řízen ní a takto se cíl orrganizace konkretizuje ažž do cílů jedn notlivých pro ocesů. To pakk znamená, žže zaměstnanci věědí, co mají d dělat – vědí jjaký je cíl jejjich snažení, a vědí, pročč to mají dělaat ‐ vědí, že to je součástí strategie pro dosažení cílů celé organizzace a tím prro zajištění jeejí prosperityy a ko onkurenceschopnosti. Taato orientacee na cíle pakk znamená, žže vše (řízení, poskytovaané slu užby, contro olling, výkazn nictví, péče o lidské zdroje,…) musí být hodnocceno z hledisska přříspěvku k dosažení celkkového cíle organizace. Nehodnotím me činnost samu o sob bě, ale to jak tato činnost přispívá k naplnění cílů organizace. SCHÉM MA
Dekompozice vize organizace
Top p managem ment
S Střední man nagement
p provádí
V Vize
provádí
Strategie
Cíle e procesů
Vlastnícíí procesů provádí
Popisy ch pracovníc činností
o popis), an nalýza, optim malizace a měření pro ocesů probííhá Vlastní vytvářření (anebo n dynamický vývo oj procesního o modelu daané organizaace v ccyklech, kterré zajišťují neustálý v zzávislosti na její vizi. Takk je dosažen na aktuálnostt procesního o modelu a ttím jeho vazzba naa každodenn ní činnost orgganizace. Náásledující kro oky popisují jednotlivé fááze procesníího cyyklu.
7
Bu usiness modeelování Formo ování vize orgganizace a ukazatelů nap plňování vizee Návrh a analýza prrocesů Zachycení stávajícího stavu Definice cílového sstavu Definice procesnícch týmů a vlaastníků proce esů Definice nápravnýých opatření Zavedení změn v p procesech Měřen ní procesu
SCHÉM MA
Grafické znáázornění pro ocesního cyklu
Návrh
edení Zave
vize M Měření
procesního říízení Hllavní důvodyy zavádění p Rychléé a kvalitní uspokojení po otřeb zákazn níků a za rozu umnou cenu Nutno ost propojeníí vize organizzace s jejími procesy Vyjasn nění odpověd dnosti jedno otlivých útvarrů i funkčních míst Tlak na n průběžnéé snižování nákladů, zaajištění kvaliity a rychlo osti uspokoje ení potřeb b zákazníka Posílení vlastní konkurencesch hopnosti Snížen ní úniku firem mního know‐‐how při flukktuaci pracovvníků Potřeb ba srozumittelného a efektivního nástroje strukturalizac s ce, analýzy a optimalizace proceesů 8
Prrocesní řízení a modelováání ZAPAMATTUJTE SI
ní Přínosy procesního řízen
Organizace jaako celek bude táhnout zza jeden provaz – každý bude vědět, čeho chcem O me s společně dos sáhnout a jakk k tomu přisspívá. V každém okkamžiku budeete vědět, jaak se vám daaří váš cíl pln V nit a snadno identifikujette m místa vzniku případných problémů. Vaši zákaznícci budou s vašimi V v služb bami spokoje eni a nebud dou mít důvod přecháze et k ke konkurenc ci. O Organizační s schéma vaší organizace P Popis všech p probíhajících h procesů včeetně jejich vsstupů, výstup pů, nároků n na zdroje atd. Popis náplníí práce jedn P notlivých fun nkčních místt a seznam kompetencíí (schopnosttí, z znalostí a pra avomocí) požžadovaných pro jednotlivvá funkční m místa. Přehled o po P oužívaných ITT systémech, zákonech aa normách. TTo vám umo ožní jasně řícct, c co již nemusí íte udržovat,, archivovat aa co vám nao opak chybí. otřebuji zavé ést procesní řízení? Po Máte jjako organizace stanovenu vizi, cíl, ktterého chcette dosáhnou ut? Ví každý váš zaměstnanec, že p přispívá k do osažení tohotto cíle a ví čím? Dokážžete měřit, jaak úspěšně svvůj cíl plníte,, a děláte to?? osažení cíle,, a Dokážžete měřit každou k činno ost z hlediskka jejího přííspěvku k do dělátee to? Daří see vám plnit vvytčené cíle?? Máte vytvořen mo otivační systéém pro zlepššování vašich h činností? Víte, kkdo jsou vaši zákazníci (vně organizacce i uvnitř), vvíte, pro koho o tu jste? Jsou zákazníci s vaašimi službam mi spokojeni?? Dokážžete měřit jejjich míru spo okojenosti, a děláte to? PŘÍKLLAD
Požadavek na procesní řřízení.
C Co bude od v vás zavedeníí procesního o řízení vyžad dovat Vytvoření pro V ocesních tým mů, které bu udou bdít nad optimálním m průběhem m jednotlivýcch p procesů a bu dou je vylep pšovat. A Aktivní podp oru procesníích týmů ze sstrany veden ní organizacee ZZavedení mo otivačního syystému tak, aaby zaměstn nanci měli zájem na hladkém průběh hu p procesů. P Pořízení prog gramového vvybavení na p podporu tvorby procesníího modelu
9
Bu usiness modeelování ní je proces,, který musí být řízen sh hora a musí být do toho oto Zaavedení proccesního řízen prrocesu zahrn nuti všichni p pracovníci, kterých se to bude týkat.. Pouze tímto způsobem m je možné zajistit přijetí potřeebných opatřření a ochotu u je prosazovvat.
1..2.
Procesní m modelován ní
namické realitě přírodníích a společčenských sysstémů. Většiina Žijjeme v komplexní a dyn těěchto systém mů není v rovvnováze, něěkteré se postupně rozvííjí, jiné zanikkají. Aby byylo možné stav a vvývoj této reeality popsat, je nutné ji fformálně zob brazit určitým m modelem.. DEFIN NICE
odel Procesní mo
Procesní mod P del je myšlenkově nebo prakticky vyytvořená struktura, která zobrazuje a určitou stránku nebo čáást skutečno r reprodukuje osti v idealizo ované a názo orné podobě ě. M Model by měěl mít možnost odvodit chování mo odelovaného objektu. Procesní mode el v vychází z pod dnikových prrocesů. Cíílem popisu procesu ovšem není zmaapování současného stavvu, ale vytvo oření podkladu prro efektivnějjší řízení pro ocesu a jeho o neustálé zlepšování a tím ke zvýšení výkonno osti ceelé organizacce. Prrocesní modeel celé organ nizace umožň ňuje provádě ět taková op ptimalizační o opatření, kte erá see neprojeví negativně n v jjiných proceesech (nezruššíme doklad, který se po otřebuje jind de, neepropustímee člověka, kteerý je unikátn ním nositelem know‐how w apod.) Prrůběh proceesu (např. vydání knihyy) lze popsat sledem jeednotlivých ččinností, kte eré veedou od spouštěcí událo osti (rozhodn nutí vydat kn nihu) k cíli ceelého processu, ke koneččné ud dálosti (kniha vydána). Na N proces jee třeba se díívat jako na souvislý sleed činností bez b oh hledu na míssto jejich vyykonávání. To o znamená, že do popissu procesu sse zahrnují i ty čin nnosti, kteréé neumíme detailně po opsat, protožže se provádějí někde jjinde, ale jssou prro průběh procesu p nezbytné (Napřř. „Rozhodo ování MŠMTT o akredittaci studijníího prrogramu“ v p popisu proceesu Akreditacce studijního programu.) So oučástí popissu procesu jsou j i funkčn ní místa pod dílející se naa jeho činnostech, doklaady po oužívané v p průběhu pro ocesu, podp porující proggramové vyb bavení, znalosti potřeb bné prro kvalifikovaaný výkon čin nností atd. Z podrobných popisů proccesů je možné: přesněě vyčíst hran nice procesů v podobě sp pouštěcích a ukončovacícch událostí identiffikovat jedn notlivé činno osti, které musí m být prrovedeny k ttomu, aby byl b splněn n účel proceesu (vše co se musí ud dělat, abycho om mohli řííct „kniha byyla vydána“). zjistit jaká je pod dpora probíh hajících činn ností z hlediska IT. To zznamená, jaaké systém my se používvají – pak lzze porovnat s tím, co je koupeno a nepoužívá se,
10 0
Prrocesní řízení a modelováání lze porovnat, zda se neudržujee více licencíí, než je skuttečných uživatelů. Zjistím me, orovány a mo ohly by být, … … které činnosti nejssou IT podpo vyčíst jaké dokum menty se pou užívají – pakk lze kvalifikovaně optim malizovat jejich podle toho kde se využívají množsství i obsah p vyčíst jaké jsou u požadovaané znalostti, dovedno osti a jiné předpoklaady pro vyykonávání jed dnotlivých čiinností. To nám pomůže při personállních změnácch. vyčíst jakými přeedpisy (tzv. dokumentovanými znalostmi) je vvýkon proce esu upraveen. Tak získááme přehled o používanýých normách. navrhnout ukazatele pro hodnocení h účinnosti ú prrocesu, pro ocesy měřit a průběh vylepššovat jejich p vyčíst jaké zdroje p proces pro svvé fungování potřebuje vyčíst jaké procesn ní role se na jednotlivých h činnostech procesu pod dílí zjistit pro každé fu unkční místo o jaké procesní role zasttává a s využžitím předchozí inform mace vygeneerovat popiisy náplní práce p jedno otlivých funkkčních míst a ve vazzbě na požad dované znalo osti i kvalifikaační předpokklady. Ud držovaný prrocesní mod del organizace je důležitý prvek říízení kvality. Z procesníího modelu je možné m generrovat aktuální vnitropod dnikové směrnice, praccovní postup py, po opisy práce. Elektronickáá podoba pro ocesního mo odelu na intrranetu nahraazuje náklad dné vyydávání vnitrropodnikovýcch směrnic. Prrincip modeelování je základním principem metod m návrhu informačního systém mu. M Metodické po ostupy a vlastnosti v jeejich nástrojjů a technik vycházejíí z myšlenky, žee informační systém je modelem reálného systém mu (reálného o světa). Prrojektovaný informační systém je budován b posstupně po jeednotlivých hierarchickýých úrrovních návrrhu ‐ od konceptuální, přes techno ologický, až po implemeentační mod del, přřičemž každáá úroveň absttrahuje od specifických ccharakteristik ostatních ú úrovní. Prrincip vede kk jasnému od ddělení podsstaty systém mu (co systém m musí dělatt) od omeze ení, ktterá jsou do o návrhu přiidávána v důsledku d zvo olené techno ologie a imp plementačníího prrostředí (jakk to bude dělat). Realizace tohoto principu je zajištěna prostřednictvvím po oužívaných metod návrrhu IS, podp porovaných v maximáln ní míře auto omatizovanýými náástroji, a ved de ke snížení rizika nepřízznivých dopaadů změn na návrh systém mu.
ZAPAMATTUJTE SI
Proces je op P pakovatelný sled činnosstí, jejichž výýsledkem jee měřitelný výstup, kterrý ěčí potřebu.. u uspokojuje n TTvorba proceesních modeelů IS je cháp pána jako klíččový princip,, který umožžní analytikovvi a abstraktní p pohled na obecné ch harakteristikyy projektu informačníího systému u, n nezatížený m momentálním m stavem věccí, použitou technologií aa dalšími abstrahovaným mi c charakteristik kami.
11
Bu usiness modeelování KONTROLNÍÍ OTÁZKY
Jaké jsou důvodyy zavádění prrocesního řízzení? Jak p podporujemee zavádění prrocesního řízzení v podnikku? Jaké informace m můžeme zjistit z popisu procesního m modelu v podniku?
SH HRNUTÍ KAPITOLY
Processní řízení je takový styl řízení organizace, kdy na organizaci nahlížíme e jako n na systém, ktterý produku uje nějaké výýrobky nebo služby, kterré uspokojujíí potřeb bu zákazníků ů organizace.. Processní model je j myšlenko ově nebo prrakticky vytvvořená struktura, kteráá zobrazzuje a reprodukuje určitou stránku n nebo část skkutečnosti v idealizované é a názzorné podo obě. Mod del by mě ěl mít možžnost odvod dit chováníí modelovaného ob bjektu. STTUDIJNÍ LITEERATURA Řeepa, V.: Procesní řízení a modelováníí. Grada, a.s. Praha 2006 6, ISBN 80‐24 47‐1281‐4 nikové processy – procesní řízení a mo odelování. Prraha: Grada P Publishing, a.s, ŘEEPA, V. Podn 20 006. 265 s. ISSBN 80‐247‐1 1281‐4 ALA, J., MINISTR, J. Průvo odce analýzo ou a modelovváním proceesů. Ostrava: VŠB ‐ FIA Teechnická univverzita Ostraava, 2003. 10 09 s. ISBN 80 0‐248‐0500‐6 6
12 2
M Metodiky a m etody tvorbyy podnikovéh ho IS
2 Metodiky a m 2. metody tvorby podnikového IIS Ú ÚVOD Metodiky a metody tvo M orby a nasa azení podnikového info ormačního ssystému nám za abezpečují orrientaci tvorrby IS na pod dnikové cíle. Řeší efektivně problém informatizacce ceelé společnossti. Jejich zna alost je nezbyytná pro prácci informačního manažerra podniku. CÍÍLE KAPITOLY Y Po o prostudová ání této kapiitoly a vypra acování úkollů budete UM MĚT: Vymezzit základní p pojmy – metodika, metoda a nástroj podnikového IS Vysvěttlit principy m metodik v prrojektech IS Apliko ovat nástrojee na konkrétn ní podnikovýý IS Po o prostudová ání této kapiitoly a vypra acování úkollů ZÍSKÁTE: Vymezzení nástrojů ů v podnikovvých IS Přehleed a kategoriizaci oblastí metodik IS Po o prostudová ání této kapiitoly a vypra acování úkollů BUDETE SC CHOPNI: Popsat smysl meto odik pro řízení projektu IS Pocho opit uživatelsské a aplikačn ní zacílení metodik a mettod
13
Bu usiness modeelování
2..1 Metodikky a nástro oje podporry projektů ů podnikovvých IS a tvorby IS došlo v 80 0. letech miinulého století V teorii i praktické aplikaci vývoje a k d dosažení takkového stup pně lidského o poznání, ktteré umožniilo systemattizovat znalo osti a kategorie vee vazbě na vývoj v IS. To o se projevillo ve vymezzení pojmů jjako kvalita IS, becné postupy vývoje, pravidla p a standardní do okumenty tvvorby IS. Do osažení danýých ob milníků vývojee teorie projjektování IS se praktickyy projevilo vee vzniku mettodik, nástro ojů a ssystémů na podporu projektování. Vznikají prrvní systémyy CASE – Co omputer‐Aid ded So oftware Engineering. Je zajímavostí,, že se původ dní orientacee na softwarrovou podpo oru a nástroje rozšířila na všechny fáze živvotního cyklu projektu ISS, dokonce i na strategiccké prrocesy při prvních návrzícch IS a operaativní podporu činností ssouvisejících s provozem IS. Vlastní dopad dy užití CASE nástrojů se projevu ují ve všech projektovvých rolích IS, od d analytiků, p programátorrů až po vlastní uživatele e projektů IS.. Orientace ttěchto nástro ojů je možná v oblastech analýzzy stávajícího o a návrhu no ového systém mu, zpětnéého inženýrsství (proces vytváření specifikace návrhu systému nebo je eho částí zz existujícího programovéého kódu a d definice dat),, reengineeringu (n nástroje, kteeré analyzujjí existující systém a um možňují ihned dět změny v systému). provád ové trendy vývoje v CASE systému, modifikujeme m e‐li typy násstrojů, vždy se Hlledáme‐li no naakonec dostaaneme na prroces samotn né existence projektu IS, jeho vzniku a samozřejm mě naaplnění projektu IS v rámci základních fází jeho o životního cyklu. Veškeeré projekto ové akktivity nemohou tedy probíhat chaoticky, bez jasně stanovené metodologgie, prrojektového rámce projektů IS, bezz jasného záákladního peevného zako otvení, zázem mí, po ozadí. ZAPAMATTUJTE SI
TTento způso ob logickéh ho uspořádáání postupn ných kroků, myšlenek, činností a p projektových h aktivit pro ojektů IS zahrnujeme do pojmu metodika m tvo orby a vývojje p projektu IS. e možné vyvvinout IS bezz projektové ého Naabízí se záklaadní otázka při vývoji a tvorbě IS. Je řízzení? Stačí pouze znalost věcnéého obsahu u jednotlivýých fází živvotního cykklu beez projektovéého řízení celého pro ocesu? Odpověď je podle měě velmi jassně fo ormulovaná. Vlastní tvorba a vývoj IS je vždy projektově řízzen. Základní prvky, kte eré deeterminují fu unkci a procees vývoje IS, jsou obsaženy v kategorriích kdo, co,, proč, za kolik. Jakkoliv můžeeme připusttit myšlenku u neustálého o rozvoje vlastního IS, vždy je ten nto neekonečný prroces prakticcky časově rozdělen na konečný počet časověě ohraničenýých prrojektových částí. Každ dá tato část musí být projektově říízena, musí být stanove eny prrojektové role, odpovvědnosti a zpětnovaze ební mechaanismy. V Vlastní rozssah prrojektovanéh ho IS urču uje počet jednotlivých h uzavřenýcch celků aa konkretizaci prrojektových aaktivit. Naa závěr úvod dních úvah však konstattuji velmi dů ůležitý fakt. Čistá meto odika vývoje IS klaade důraz na n obsahovo ou část tvorb by IS. Její rozšíření r o zásady z projeektového říze ení 14 4
M Metodiky a m etody tvorbyy podnikovéh ho IS prrojektů IS přináší p i poh hled vlastní projektové realizace. Metodika M tvvorby a vývo oje prrojektu IS jee tedy smysluplným spo ojením dvou u pohledů, které k musí platit zárove eň. Prroto v této práci vždy důrazně používám p označení meetodik projeektů IS, kte eré zd důrazňuje výšše popsaný p projektový p přístup.
2.2.
Vymezen ní metodikk, metod a nástrojů p podnikových IS
Záákladním výcchodiskem následujících úvah je spráávné pochop pení pojmu m metodika. Taa je ob becně vysvěttlována jako o způsob usp pořádání myyšlenek a čin nů. Metodikyy pak obsah hují modely a odráážejí určité pohledy na so ouhrny myšle enkových vzo orů. Ap plikujeme‐li tuto definicci na process tvorby IS, pak smysl metodiky m neení v detailn ním po opisu kroků při vývoji IS, ale v an nalýze podsttatných fakttorů procesu u výstavby IS. V kontextu prrojektového chápání jdee o úplný proces p vývojje IS neoddělitelně spjaatý s ffázemi životn ního cyklu IS. Jeestliže hovořřím o metod dice v jedno otném čísle, chápu při jejím vymezzení i množinu metodik nižší úrovně. To znamená ap plikaci principu obecnéh ho na konkrétní metodiky, ktteré jsou v n ní obsažené. Tím zdůraazňuji akceptaci jednotlivých dílčích h projektovýých metodik (napřř. metodika u udržitelnostii IS) v celkové metodice ttvorby projeektu IS. K tom mu, ab by metodika byla využitelná pro vývvoj IS projekktovým způssobem, je nu utné definovvat náásledující požžadavky na n ni kladené. M Metodika: musí jasně deklaro ovat soubor hodnot, na kkterých je založena, respektive, kterýých chce d dosáhnout (n např. minimáální náklady tvorby IS, krrátká doba řešení, zahrnutí sociáln ního aspektu u do řešení), musí u určovat postup řešení, ab by bylo možn né celý procees vývoje IS p plánovat, musí u určovat priorrity řešení (co a kdy je dů ůležité), měla by doporuččovat metod dy, technikyy a nástrojee, které je vvhodné pou užít v jednotlivých fázích projektovvého řešení. mezení mettodik je jejjich uživatelské a aplikační zacíle ení. Výýznamným prvkem vym To o znamená, že metodikyy jsou určen ny pro konkkrétní projektové role, pro konkrétní prrojektové prvvky. V literattuře jsou deffinovány nássledující prvkky: organizační proced dura a postu upy. data, SW a H HW, organizační vlivy ISS, produkty a potřebné dokum menty v jed dnotlivých fázích f životn ního cyklu IS, použittelné metodyy, techniky aa nástroje v je ednotlivých fázích životn ního cyklu IS, pracovvníci – řešiteelé projektu, způsob řízení v jed dnotlivých fázích životníh ho cyklu IS.
15
Bu usiness modeelování v pojetí se nadálee budu zabývvat Uvvedené zacíllení metodikk je však vellmi široké, v užším po ouze některými prvky. Jedná se především p o pracovníky, dokumentty, produktyy a orrganizační prrocedury a postupy. Prro vymezení vlastního po ojmu metodika tvorby projektu IS lze použít mnoh ho přístupů. DEFIN NICE
Metodika podnikového IS
Metodika po M odnikového IS I je souhrn postupů, metod, technik a nástrojů ů, které sloužží k k vývoji a zav vedení inform mačního systtému v podniku. Metodika tvo M orby IS je doporučený souhrn s etap p, přístupů, zásad, z postu upů, pravide el, řízení, meto d dokumentů, od, technik a nástrojů pro o tvůrce IS, který pokrývvá celý životn ní c cyklus IS. Urč čuje, kdo, kd dy, co a proč má dělat bě ěhem vývoje a provozu ISS. Uvvedená defiinice je dlee osobního názoru velmi dobrým rámcem pro obsahovvou ch harakteristiku u metodik. V V literatuře jsou uveden ny i principy metodik tvo orby IS. Jed dná see o následujíccí principy: orienttace na podn nikatelský cíl,, odpovvědnost vedeení organizacce za obsah IIS, účast uživatelů na návrhu IS, uplatn nění ověřenýých metod a technik vývo oje IS, využití počítačové podpory, etapovvý charakterr metodik, iterativnost postupu etap, dokum mentace díllčích i fináálního výsle edku formo ou písemnýých materiáálů, které mají standarrdizovanou sstrukturu a platnost. Metodika by sse měla vztahovat na všeechny prvky IS (pracovnííky, organizaační procedury, M daata, SW a HW W), organizační vlivy IS, eekonomické otázky spojeené s vývojeem a provoze em IS,, doporučené dokumentty a případněě způsob říze ení v jednotliivých fázích žživotního cykklu IS. DEFIN NICE
M Metoda určuje, co jee třeba dělatt v určité fázzi nebo činn u nosti vývoje či provozu IIS. Metoda je j v vždy spojenaa s určitým přístupem, p jaako je funkčční, datový, nebo napřík n lad objektovvý p přístup. S přřihlédnutím k této chaarakteristice řeší každá metoda postup činnosstí v v určité částti (jedné neebo několikaa fázích) pro ocesu vývojje systému, nebo pouzze z z některého ú úhlu pohledu u na systém (data, funkce, SW, HW, aatd.). T Technika určuje, jak docílit po u ožadovaného o výsledku. Zpravidla určuje přeesný postu up jednotlivých činností, způ ůsob použití nástrojů, vaarianty rozho odnutí v určittých situacícch 16 6
M Metodiky a m etody tvorbyy podnikovéh ho IS aa co z nich vyplývá, vyymezuje obo or své působnosti atd. Na rozdíl o od metody je j p přesnější v zá ávěrech a om mezenější v o okruhu použiití. N Nástroj je prostředkkem k uskutečnění urččité činnosti v procesu vývoje a p provozu IS a p prostředkem m k vyjádřeníí výsledku tééto činnosti.. Nástroj je často svázán s konkrétn ní t technikou. N Nástroje vždyy formalizujíí vyjádření, proto je mo ožné a žádo oucí, aby byly v v maximální míře automaatizovány. mi pojmy je velmi různo orodý. Nelzee se omezit n na jednoducché Vzztah mezi výýše uvedeným tvvrzení, že jed dnotlivé meetody jednozznačně patříí určitým metodikám, m n nebo že kažždá teechnika či nástroj pod dporuje své vlastní metody. Nap příklad meto oda datové ého modelování je j uplatňovvána v mno oha metodikách, naop pak v jiných metodickýých přřístupech se plně uplatňu uje základní rozpor mezi funkční a daatovou větví metod. Ten nto ro ozpor spočívá ve faktu, že nelze usspokojivě provádět vývo oj projektu IIS ani směre em od d dat (datovéé základny syystému), anii směrem od d procesů (prrocesní záklaadny systému), an niž bychom přitom nevěnovali pozornost p druhé d složcce vytvářeného systém mu. Po ochopení to ohoto rozpo oru vede k formování k obecného a celostníh ho principu – k metodologii objektové o orientace vývvoje a tvorbyy projektů IS. Přřestože lze do d budoucnaa předpoklád dat nástup nových n techn nologií, zpraacování novýých metod, metod dik a nástro ojů vývoje projektů p IS, které se bu udou navzájeem ovlivňovvat, jedna základníí premisa je nezpochybnitelná. Při výývoji a tvorb bě projektu ISS je nutné vžždy vzzít do úvahy ffakt, že základ dní složky infformačního ssystému jsou u procesy a d data, bude n nutné vždy p provést analýýzu postaven nou na modeelování objekktivní reality.
2..3. Obeccné princip py metodikk vývoje a ttvorby pro ojektu IS Jeestliže pocho opíme metodiky IS jako o způsob zabezpečení efektivnosti e vývoje IS, pak p zee systémové pozice je nezbytné defin novat obecné é principy to ohoto pohled du na metodiky IS. Jinak řečeeno, vymezzujeme základní pravidla pro stan novení posttupu a obsahu živvotního cykklu projektu u IS, vymezujeme mírru obecnostti se zřeteelem na míru sp pecifičnosti a variantnosti daného konkrétního o řešení (m metoda, tech hnika, nástrroj) v d dané konkréétní vývojovéé etapě. Náásledující obecné o principy se staaly výchozím mi při mettodik vývoje a nasaze ení po odnikových IS. Orrientace proj ojektu IS na ccíle a problém my. Záákladním výcchodiskem při tvorbě projektu p IS je hledání prvotních p cíílů a problém mů v podniku, orgganizaci, insstituci a spo olečnosti. Z ttohoto pozn nání vychází odvození cílů c prrojektů inforrmačních sysstémů, kteréé je přesně vymezeno v a formulováno v příslušné ém prrojektovém dokumentu. Kromě to ohoto dokum mentu vznikkají při pro ojektu IS daalší píísemné doku umenty. Někkteré z nich mají v systém mu řízení pro ojektu IS chaarakter řídícíích do okumentů, které k podléhají procesu u schválení. Vlastní schvalovací p proces a je eho vyymezení je so oučástí meto odiky projekttu IS.
17
Bu usiness modeelování Užžití principu modelováníí a abstrakcee Prrincip modeelování je základním principem metod m návrhu informačního systém mu. M Metodické po ostupy a vlastnosti v jeejich nástrojjů a technik vycházejíí z myšlenky, žee informační systém je m modelem reálného systém mu (reálného o světa). Tvo orba modelů ů IS je chápána jako klíčový princip, p kterýý umožní analytikovi absstraktní pohled na obeccné ch harakteristikyy projektu in nformačního o systému, nezatížený n m momentálním m stavem vě ěcí, po oužitou tecchnologií a dalšími abstrahovaný a ými charakkteristikami. Projektovaaný informační sysstém je budo ován postupně po jednotlivých hieraarchických úrrovních návrrhu ‐ od koncepttuální, přes technologický, až po implementačční model, p přičemž kažždá úrroveň abstrrahuje od specifických charakteristik ostatníích úrovní. Princip ve ede k jjasnému oddělení podsttaty systému u (co systém m musí dělat) od omezeení, která jssou do o návrhu přid dávána v dů ůsledku zvoleené technolo ogie a impleementačního o prostředí (jjak to o bude dělaat). Realizacee tohoto prrincipu je zajištěna pro ostřednictvím m používanýých metod návrhu u IS, podporovaných v maximální m míře automatizovanými n nástroji, a ve ede kee snížení rizikka nepříznivýých dopadů zzměn na návvrh systému. Jak je vidět, při oddělován ní různých po ohledů hraje e vždy klíčovvou úlohu ab bstrakce. Ten nto záákladní rys metodik m protto bývá, těž nazýván prrincipem absstrakce. Hlavvním důvode em exxistence prin ncipu abstraakce v meto odách analýzzy a návrhu IS je snahaa po rozděle ení zkkoumané pro oblematiky. oje IS Ovvěřování a teestování návvrhu během celého vývo Jižž od počátečních etap výývoje se připrravuje testovvání systému u. Tento princip se realizu uje jednak prostřřednictvím řídící komise projektu u a jednak návrhem a průběžnýým up přesňováním m schvalovaccí proceduryy. Na konci každé projeektové činno osti se ověřu uje prrostřednictvíím milníků projektu ISS, zda výsle edky proved dené činnossti (projekto ové akktivity) odpo ovídají stano oveným cílům m projektu IS a požadavvkům uživatelů a zda jssou sp právné po forrmální i logiccké stránce. Teesty existují vve dvou rovinách: testy analytické funkcionalityy, pro kterré vytváří testovací pláány analyticcké odděleení, testy ttechnologie, zkoumající zzátěž, kritickké body systéému, krajní m meze naplně ění, rychlo ost. Tyto testy navrhuje d designér. V testech se p pochopitelně mimo jiné zzkoumá bezcchybnost fungování IS jakk v normálnícch, ních situacích. Testovací plány jsou n nezbytné nejenom z toho o důvodu, že e je tak v tzv. mezn třeeba výsledek testu zdokkumentovat, ale také prroto, že testeer se musí n nějak seznám mit s ttím, co se vlaastně má tesstovat. Princip iteratiivního postu upu vývoje projektu IS P Iteerativní posttup vývoje ISS pomáhá id dentifikovat rizika v každ dém stádiu žživotního cykklu prrojektu, čímžž značně sniižuje náklady na jejich odstranění. o Pro účely řízení se životní cyyklus projekttu rozděluje do určitých fází, přičem mž každá fázee je složena z řady malýých čáástí (iterací). Jednotlivé iterace i zahrn nují čtyři zákkladní aktivitty: sběr požaadavků, návrh, im mplementaci a vyhodnoceení. V jednotlivých h etapách see analyzují požadavky p na n IS a zjem mňují se pouze na takovvou úrroveň, aby bylo b možné na n základě provedené p analýzy navrh hnout systém m pro zaháje ení 18 8
M Metodiky a m etody tvorbyy podnikovéh ho IS daalší etapy. Tak T lze zabráánit zbytečn né podrobno osti návrhu na n začátku vvývoje a sníížit rizziko pozdějších změn po ožadavků. Po ožadavky se pouze zpod drobňují. V p případě změ ěny naadřízeného požadavku, p n nebo přidáním dalších požadavků p jee vždy nutnéé se vrátit k té přředcházející etapě, kde se s požadaveek poprvé prrojeví jako zm měna. Poté z ní vyplývajjící daalší změny lze promítnou ut do všech eetap následujjících. Teprve pak je možžné pokračovvat v d dalším návrh hu. Trransparentno ost, otevřenost a kompa atibilita meto odiky Metodika tvo M orby projektu IS by měěla být logiccky i formáálně dobře strukturovan ná, do okumentovatelná, otevřeená vůči dalššímu stupni poznání v daaném předm mětu zkoumáání. Záároveň by měla být založžena na kvalitních a ově ěřených metodách a tech hnikách vývo oje IS,, včetně po oužití nástro ojů CASE pro o její zaved dení. Dále je nezpochyybnitelný fakt, žee v konkrétníí podobě by měla vycházzet, či být kom mpatibilní see standardy aa standardníími metodikami vývoje IS. Přittom není dů ůležité, zda sse jedná o m metodiky zavvedené státe em, evvropskou institucí, či mezzinárodně uzznávanou fire emní metodiku. KONTROLNÍÍ OTÁZKY
Jaký je historický vývoj nástro ojů? Jak nám n metod diky a meto ody tvorby podnikového o informačn ního systém mu zabezpečují orien ntaci na zákaazníka? Popiššte princip itterativního p postupu vývo oje projektu IIS. S SHRNUTÍ KA PITOLY
Meto odika tvorbyy IS je dopo oručený sou uhrn etap, přístupů, p zássad, postupů ů, praviidel, dokumentů, řízení,, metod, tecchnik a násttrojů pro tvů ůrce IS, kterrý pokrýývá celý živo otní cyklus IS. Určuje, kdo, k kdy, co o a proč má dělat během m vývojje a provozu IS. Meto oda určuje, cco je třeba d dělat v určité é fázi nebo ččinnosti vývo oje či provozzu IS. M Metoda je vžd dy spojena s určitým přísstupem, jako o je funkční, datový, neb bo napřííklad objekto ový přístup. Nástroj je prosttředkem k uskutečnění u určité činnosti v procesu vývoje a provo ozu IS a prostředkem k vyjádření výýsledku této činnosti. Náástroj je častto svázáán s konkrétn ní technikou. STTUDIJNÍ LITEERATURA Po olák, J., Meru unka, V., Carrda, A.: Uměn ní systémové ého návrhu. Grada, Prah ha 2003, ISBN N 80 0‐247‐0424‐0 02 RO OBSON, M. – ULLAH, P. Praktická á příručka podnikového o reengeneeeringu. Prah ha: Press, 1998. ISBN 80‐859 M Management 943‐64‐6
19
Bu usiness modeelování
3 Mode 3. elování procesů ů v podn niku Ú ÚVOD Cíílem modelo ování je vytvvoření proceesního modeelu nebo jeh ho části. Prrocesní mod del můžeme chara akterizovat jjako strukturrovaně uspo ořádané informace o všeem, co se týkká fu ungování org ganizace, tzn n. o procesech, zdrojích h, výstupech h (výrobcích h a službách h), do okumentaci, cílech organ nizace atd. Úččelem proceesního modeelu je podpo orovat proceesní řízení organizace, o vv jehož rám mci um možňuje všeem skupinám zaměstnanců organ nizace čerpa at a využívvat informacce v m modelu uved dené v jakýcchkoliv souviislostech pro o různé účelyy. To je I zákkladní význam za ařazení I této o části modullu. CÍÍLE KAPITOLY Y Po o prostudová ání této kapiitoly a vypra acování úkollů budete UM MĚT: Charakterizovat po odnikový mo odel v processním pohledu Zpraco ovat přehled d o referenčn ních modelecch podnikovéé informatikyy Vymezzit referenčn ní model ITIL a SPSR Po o prostudová ání této kapiitoly a vypra acování úkollů ZÍSKÁTE: Schop pnost vymezit procesní m mapy a jejich zpracování Znalossti o postupu u implementace procesníího modelu Vymezzení a příklad dy oblastí mo odelu CMMI Po o prostudová ání této kapiitoly a vypra acování úkollů BUDETE SC CHOPNI: Vytvořřit obecný po ostup tvorbyy procesního mapování Zpraco ovat příklad doplňkových h modelů podnikové info ormatiky Charakterizovat do omény modeelu COBIT
20 0
M Modelování p rocesů v pod dniku
3..1. Proce esní mapovvání jako zzáklad tvorrby modelů ní procesů vžždy vycházím me z dané reality, nicmén ně je nutné ssi uvědomit, že Přři modelován přři modelování procesů vždy využívááme metodu abstrakce. Modelováním vytvářím me jakýsi „obraz““ reality, ve kkterém abstrrahujeme od d nepodstatn ných věcí (okkolností), ressp. d těch skuteččností, které nemají vliv n na námi vytvvořený modeel. od DEFIN NICE
Model
Model je úččelně defino M ovaná množiina prvků a vazeb mezzi nimi, kterré jako cele ek v vykazují charrakteristické vlastnosti. Model M proce esu znázorňu uje informacce, které nám m s slouží k tomu, abychom procesy mo ohli řídit. Mo odel procesu u je tvořen o objekty, resp p. p prvky, které n nám znázorň ňují podstatn né informace e o procesu. n možné postihnout všechny prvvky Z této definicce je jasné, že do modeelu jednak není reeality, ale hlaavně z hledisska modelovvání procesů to není ani vhodné. V m modelování jjde vžždy o to, že do určité míry m zjednodušeným a sttrukturovanýým způsobeem popisujem me reealitu, abycho om poté mohli přistoupitt k jejímu zko oumání. Modely a mo M odelování může m mít takké své negaativní stránkky: modely jjsou napříkllad neezbytně zjed dnodušující a a jejich auto oři mají častto tendenci soustředit sse na to, co je neejvíce vidět, některé věci mohou být skrytě ne eefektivní, nefunkční, aččkoliv na prvvní po ohled to nen ní patrné. Vzztah jednotlivých objekttů znázorněn ných v modeelu je vyjádřřen vaazbami. Procces nemohu u řídit, respektive řešit problémy, které se v jeho průbě ěhu neevyskytnou, pokud mu nerozumím m. Model prrocesu nám tedy odpovví na všech hny ottázky, které sse týkají proccesu. Záákladním principem pro ocesního mo odelování je e postup sh hora dolů, ttzv. top‐dow wn. To o znamená zaačít od identtifikace oblasstí procesů. Každá oblastt procesů se bez ohledu na to o, jestli spad dá do katego orie procesů ů hlavních, řídící ř nebo podpůrných, p , člení na niižší ro ozlišovací úro ovni do jedno otlivých skup pin procesů. Každá skupina procesů d dané oblasti se náásledně členíí na jednotlivvé procesy. Rozsáhlé a ssložité processy je vhodnéé dále členit na su ubprocesy (p podprocesy). Při vytvářen ní procesního modelu orrganizace je nutné se vžždy říd dit podle cílů ů dané organ nizace, nikoliiv podle orgaanizační stru uktury a vždyy se zaměřit na po odrobnosti tam, kde je tto potřebné, určit ukazattele a param metry výkonn nosti procesů ů a po ostupovat po odle předem m zpracovanéé, jednoznaččné a všem zúčastněným z m srozumitellné metodiky. DEFIN NICE
Procesní maapa
Procesní map P pa je základn ním prvkem procesního mapování. SSkládá se z h hierarchickýcch g grafických di agramů, dop plňujících texxtů, slovníku u použitých termínů a definic procesů ů, v včetně vzájem mných odkazzů.
21
Bu usiness modeelování by: Prrocesní mapaa je znázorněěna formou ggrafického jaazyka tak, ab umožn nila vyložení součástí pro ocesu v kontrrolované pod době, podpo orovala struččnost a přesn nost v popisu u procesní mapy, soustřředila pozorn nost na vzájeemné vztahy v procesní m mapě, poskyttovala vhodn ný schematiccký slovník, byla vhodným pod dkladem pro procesní analýzu. ZAPAMATTUJTE SI
Procesní maapa bere v úvahu činno P osti a informace a sou učasně vymeezuje i jejicch v vzájemné vzztahy. Procesní mapa nám n poskytu uje informacce o tom, jaak je činnosst v v procesní m mapě zajištěěna procesním mechanismem, včetně toho, jak jednotlivvý p procesní mechanismus může m ve funkční procesn ní mapě vykkonávat souvvisející funkcce n na několika r různých místech. oncepce procesního map pování Ko Záákladní konceepce mapovvání procesů je založena na metodě sstrukturní an nalýzy, kteráá je ossvědčeným nástrojem v v různých oblastech o po odnikání. Záákladní zásady úspěšného prrocesního maapování můžže shrnout do o následujícíích bodů: Porozumět proceesu nebo systému vyytvořením procesní m mapy, graficcky znázorňující prvkyy (objekty nebo informaace) a činno osti (vykonávvané člověke em nebo strojem). Procesní P maapa je navržena tak, aby a správněě a přehled dně znázornila jak prvkky, tak činnosti. Určit, jaké činnosti má systtém vykonávat na záklladě toho, jak je systé ém navržen. k dosaahování těchto činností n Hierarrchicky strukkturovat proccesní mapy ss hlavními činnostmi na nejvyšší úrovvni a detaaily zobrazenými na úro ovních nižšícch, přičemž je nutno d dbát na vnitřřní konzisstentnost jed dnotlivých map. Pravid delně a průkkazně hodno otit vývoj procesní map py a zaznam menat všech hna rozhod dnutí. To zajistí, že proccesní mapa maximálně odrazí úsilí zzodpovědné ého týmu. Prrocesní mapo ování obvykle začíná znáázorněním to oho, co je prrocesní prob blém. Součassně je procesní mapování m striktně odděěleno od náávrhu toho, jak bude ttento problé ém prrocesu řešen n a implemeentován. Začííná se znázo orněním procesu celého systému, jaako jednoduché m modulární jed dnotky. Větššinou je to obdélník znázzorňující systtémový procces jako celek, jehož popisekk je obecný,, spíše abstrraktní a nep příliš podrob bný. Jednotliivé syystémové pro ocesy jsou prrovázány pom mocí šipek vztahů.
22 2
M Modelování p rocesů v pod dniku PŘÍKLLAD
ntuje systém mový proces jako jeden modul. Ten n je následn ně Jeden obdélník reprezen z znázorněn na nižší úrovvni několika obdélníky propojenými p šipkami. Tyyto vzájemn ná s spojení znázo orňují hlavníí procesní submoduly rod dičovského m modulu. Každ dá následující ú úroveň proccesní mapyy odkrývá kompletní soubor sub bmodulů, kd dy každý je j r reprezentová án obdélníkkem, jehož hranice jso ou definovány šipkami vzájemnéh ho r rozhraní. V Vytvořte pro cesní mapu ččinností obchodního odd dělení společčnosti Prrocesní mapování poskyytuje pravidla pro postu upné odkrývání dalších d detailů běhe em daalší dekompozice processní mapy. Horní H mez še esti obdélníků jedné úrrovně processní mapy vyvíjí přři popisu složitých proceesních subjekktů tlak na p použití hierarchizace. Do olní mez tří obdéln níků slouží obvykle k zajišštění toho, žže je mapa natolik podro obná, že přináší prrocesu hodno otu. Vyytvoření pro ocesní mapy mají za úko ol procesní „tvůrci“. Jedn ná se o dynaamický proces, ktterý obvykle vyžaduje sp poluúčast vícce než jedné é osoby, přiičemž je upřřednostňováána týýmová práce. Vytvoření procesních map je cykliický proces hodnocení aa komentováání vyytvořených map, m který pokračuje do té dobyy, než jsou diagramy p procesní maapy a posléze i prrocesní mapaa procesním m týmem přiijaty. Tento cyklus zajisttí to, že chyyby a nedopatřeníí jsou odhaleny dříve, než mohou způsobit větší v problém my. Koncovýým dů ůsledkem to ohoto přístu upu k organ nizovanému porozuměn ní procesu jje ujištění se, žee procesní mapy jsou spráávné. ZAPAMATTUJTE SI
Obecný posstup tvorby p procesního m mapování
Vytvo oření stávající organizačn ní struktury Vytvo oření rámcovvého procesního modelu u Deko ompozice ideentifikovanýcch procesů Detailní popis kažždého proceesu Kontrola konzisteence Vyytvoření stávvající organizační struktu ury organizaace Vyytvoření orgganizačního diagramu d je základním krokem vytvváření proceesního mode elu orrganizace. Jee vhodné si namodelovaat organizačční strukturu u organizace až po úrovveň ob bsažení funkkčních míst p před vlastním m modelován ním procesů organizace, a to z důvo odu vaazby jednotlivých proceesů (vlastníkků procesů a vykonavattelů procesů ů) na stávajjící orrganizační strukturu v mo odelech proccesů. Vyytvoření rám mcového pro ocesního mod delu Mezi jednotlivvými procesyy existují vazzby, které jso M ou v každé organizaci utvvářeny odlišn ně. Ob blasti procesů lze identtifikovat na základě plněných úkolů ů, které by měly vycházzet z ccílů. Proto vytvořený rám mcový proceesní model má m úzkou vaazbu na misii, vizi a posláání orrganizace. Oblasti procesů následněě rozdělujem me do katego orií podle jejjich důležito osti dle přidávání h hodnoty pro externího záákazníka.
23
Bu usiness modeelování ekompozice identifikovaaných processů De Kaaždá skupinaa dané oblaasti se člení na jednotlivé podproceesy a proceesy. Procesy je vh hodné identiifikovat na základě z jejich h výstupů, které k mají ko onkrétního eexterního ne ebo interního zákaazníka. Procees, který tvořří soubor čin nností, musí mít jednozn načně určené é a po opsané inforrmace o jeh ho kontextu.. Existence kontextu k pro ocesu je nezbytná, pokkud ch hceme modeely procesů vvyužít k podp poře řízení o organizace. ZZde je na jednom místě vvše neezbytné: cíl p procesu, ukaazatele výkonnosti proce esu, vlastník procesu, vsttupy a výstu upy prrocesu a dalšší atributy prrocesu. De etailní popiss každého prrocesu U každého procesu p vytvváříme detaailní popis každého prrocesu včetně definováání prrocesních map. m Jedná se o tzv. modelování m procesů. Modelování M p procesu, ressp. modelování činností č proccesu se pou užívá k popiisu toho, jak vypadá průběh dané ého AS‐IS modelování). Při m modelování p procesu rozeebíráme procces po částe ech prrocesu (tzv. A naa činnosti, ktteré tvoří výýstup danéh ho procesu. Každý procees začíná nějjakou událosstí, ktterá vyprodu ukuje nějakou činnost, jeejímž výsledkkem je další událost, kteerá spustí daalší čin nnost atd. Při popisu pro ocesu se nezzatěžujeme sstávající organizační stru ukturou, pou uze zaaznamenávám me vykonavaatele dané ččinnosti. Při popisu procesu je vždy nutné stano ovit ro ozhraní s navvazujícím pro ocesem nebo o skupinou prrocesů. Ko ontrola konzzistence Ko ontrola kon nzistence slouží s pro ověření správnosti s modelovanéé skutečnossti. Ko ontrolujeme úplnost popisu p objektů, věcno ou správno ost, kontrolu návazno ostí jednotlivých p procesů. ZAPAMATTUJTE SI
Vlastní vytvo V oření procesn ní mapy před dchází několiik kroků, které je třeba u uskutečnit prro ú úspěšné vytv voření processní mapy. fáze sběru dat fáze uspořádání p procesní mapy fáze dokumentovvání mapy fáze zpětné interrakce Fááze sběru dat Prrocesní tým se v této fázi f snaží naasbírat co nejvíce n faktických inform mací o dané ém prrocesu. Při to omto může vvyužít např.: ‐
interview – struktu urované, nesstrukturovan né, introspekktivní,
‐
um písemnýcch pramenů, studiu
‐
dotazn níky – sestavvené jak pro uživatele, tak i vlastníky procesu,
‐
diskussi,
‐
autom matizované syystémy – datta mining, sp peciální systéémy,
‐
pozoro ování fungovvání procesu u a jeho účasttníků,
24 4
M Modelování p rocesů v pod dniku ‐
vlastní znalosti a zkušenosti z ttvorby proce esních map.
Jee rozhodnutíím procesníího týmu, jakou techniiku nebo jaaké technikyy se rozhod dne up platnit. Fááze uspořádaaní procesní í mapy Taato fáze v so obě zahrnuje jak nakresleení prvotních h procesních h map, tak i jjejich násled dné přřehodnoceníí, překresleníí až do okam mžiku, kdy naakreslené pro ocesní mapyy jsou skuteččně „ssprávné“. Fááze dokumen ntování map py Jeedná se o fázi, ve které nasb bírané inforrmace jsou uspořádán ny do form my strukturovanéého textu, přičemž se klade důraz, aby se jedn nalo o strukkturovaný te ext. Po o kompletacii všech dokkumentů se provádí jejich posouzeení prostřed dnictvím jinýých an nalytiků, kritiiků nebo člen nů týmu. Fááze zpětné in nterakce Přřipomínky reecenzentů do okumentace,, které byly autorovi pro ocesních map zaslány, jssou přředmětem tééto fáze. Po přečtení jednotlivých připomínek se otevírá diskkuse o reakcíích naa jednotlivé procesní mapy. m Cílem je dosáhno out shody k k procesní m mapě. Také se prrovádí brainsstorming dalšších kroků výývoje processní mapy.
3..2. Refere enční mode ely řízení p podnikové informatiky mohla být po odniková infformatika řízena efektivn ně, musí mít její pracovn níci K tomu, aby m přřehled o: struktuře IS/ICT (např. strruktuře harrdware, strruktuře liceencí software, přístupových práv), vzájem mných vztazíích mezi jedn notlivými IS/ICT, processech (pracovvních postup pech) spojenýých s IS/ICT (plánování, rozvoj, provo oz, řízení apod.), službáách podnikovvé informatikky. okud tento přehled neeexistuje pouze v hlavách h řídících prracovníků, aale je uložen n a Po sp pravován ve strukturovaané podobě (obvykle prostřednictvím m nástrojů podpory říze ení po odnikové informatiky), lzze ho nazvat modelem říízení podniko ové informattiky. Vzhlede em k tomu, že o každé součáásti podnikové informatiky je třeba sledovat po oněkud odliššné matiky z následujících čáástí: informace, skládá se modeel řízení podnikové inform systém mu evidence IS/ICT, architeektury zdrojů IS/ICT, modelu procesů ISS/ICT, katalo ogu služeb IS//ICT.
25
Bu usiness modeelování PŘÍKLLAD
Výše uvedené části jsou vv modelu řízzení podnikové informatiiky propojen V ny do jednoh ho c celku (např. S Služba "Účettnictví" je provozována n na serveru "kkotelna 125", využívá ji 1 18 u uživatelů z od ddělení "Účttárna"). Kromě těchto K o částí moho ou být do mo odelu řízení p podnikové in nformatiky p připojeny další č části – doplň ňkové modeely, které sp pecifikují říze ení podnikovvé informatiiky z určitýcch s specifických hledisek. Jso ou to např.: modeel bezpečnosti IS/IC CT (struktura bezpeečnostní d dokumentace e, bezpečnostní pro ověrky apod..), modeel řízení jako osti IS/ICT (sledované atributy jakostii u zdrojů, prrocesů, služe eb IS/ICTT, struktura dokumentacce jakosti, prrověrky jakossti apod.), modeel měření IS/ICT (proccesy měřeníí, způsoby vykazování, dokumentyy, metrriky a dimenzze IS/ICT apo od.), Princip refere enčních mod delů řízení po odnikové infformatiky Model řízení podnikové informatiky má však jednu základn M ní nevýhodu – na začáttku im mplementacee je zcela práázdný a je třeeba jej postu upně naplňo ovat (např. deefinovat jakýým zp působem bud de probíhat proces řízen ní konfiguraccí). To je velmi náročná činnost, kte erá vyyžaduje značčnou zkušen nost ve všeech oblastecch řízení po odnikové infformatiky. Pro P ulehčení tohoto postupu jjsou proto vyytvářeny urččité předlohyy, které již ob bsahují typiccké ko onfigurace (n nebo seznam my možností) řešení jedno otlivých částtí systému řízzení podniko ové informatiky. ní modely – jsou vytváře eny na základ dě zkušenosstí jejich tvůrrců Tyyto předlohyy – referenčn z řřízení inform matiky a obsahují o tedy ověřené é vzory či varianty řešení. Posttup im mplementacee modelu řízeení informatiky je potom m velmi usnad dněn: nejdřívve řešitel vybere v refeerenční mod del, který při p tvorbě modelu říze ení podnikové informaatiky bude využívat, potom m projde jeho o jednotlivé části a rozho odne, které zz variant navvržených řeše ení použije, dále příp padně upravví obsah referenčního modelu m podlle specifickýých potřeb b daného po odniku, provede implem mentaci (přřevod vybraných částtí referenččního mode elu utečného mo odelu řízeníí podnikové informatikyy) a zahájí p provoz mode elu do sku v podn niku. Z výše uvedených řádků by se mohlo o zdát, že implementace modelu řízeení informatiky s p použitím refferenčních modelů m je veelmi jednodu uchá činnostt. Postup im mplementace je vššak ovlivněn a významně ztížen následujícími vlasstnostmi refeerenčních mo odelů: existujjící referen nční modeely jsou obvykle o veelmi rozsáh hlé – snaaha po kom mplexnosti ((zahrnutí všeech možných h variant a faaktorů) vedlaa ke značném mu rozsah hu (řádově tisíce stránek textu), kterýý znesnadňuje jejich aplikaci, ne vššechny souččásti podnikkové informatiky jsou v referenčn ních modele ech pokrytty (např. nemá n cenu tvořit referenční mod del zdrojů ((hardwarovýých prostřředků a kom munikací), protože p ty se liší v každém podniku. Všech hny relevaantní metodiky, bez ohlednu na to o, zda se jm menují COBIIT, ITIL, Sele ect 26 6
M Modelování p rocesů v pod dniku Perspeective, CMM M, SPSPR atd d., se zabývvají tím, jak řídit, monittorovat, měřřit, vyhod dnocovat a vyylepšovat klííčové busine ess procesy p podniku/orgaanizace, její llidi (orgware), technologie i extern ní podnikate elské prostředí. ZAPAMATTUJTE SI
SSnahou procesně řízenýcch organizaccí je dospět d do stavu tzvv. událostmi řízené (even nt d driven) organ nizace a organizace praccující v reáln ném čase. To o znamená, žže organizacce m má (většinou u pomocí násstrojů IS/ICT)) aktivována čidla, která indikují vznikající událossti (příchod objednávky, čaas k podání daně z DPH H, výpadek výrobní linkky,…). Jakmille u událost vznik kne, ihned see spouští pro oces, který zzajišťuje reakkci podniku na příslušno ou u událost. Výsledná reakcce podniku musí přijít v v reálném čase, č tj. v ččase, který je j o optimální z h hlediska dodaavatelského řetězce, exte erního partn nera, zákazníka apod. To omuto trend du se přizpů ůsobuje i sam motné ICT podniku, p tj. řada podnikků přechází na prrocesní řízen ní vlastního ISS/ICT (např. implementu uje standardyy, jako jsou m metodiky ITIL a CO OBIT).
CO OBIT ‐ Conttrol OBjectivves for Info ormation an nd related TTechnologyy Metodologie COBIT™ (zkkratka z „C M Control OBje ectives for Information n and relatted Teechnology“), představujee v současnosti jednu z nejkomplexněějších metod dik formalizujjící řízzení a hodnocení IS/ICTT. Toto dílo vzniklo v ISSACF (Inform mation Systeems Audit and Co ontrol Found dation), asociaci vzniklé vv roce 1969. CO OBIT™ definu uje řízení ICTT jako korelační vazbu m mezi: cíli ICTT v souladu ss požadavky p podnikání, aktivittami / processy ICT, zdroji ICT.
Obráázek – Vazbaa mezi podnikovou a info ormační strattegií při řízen ní ICT
27
Bu usiness modeelování Sttruktura ICT procesů vytvváří smyčku,, která zárovveň obsahujee základní prrvky „životníího cyyklu“ ICT systtémů. IC CT procesy dle COBIT™ jso ou popsány vv členění na čtyři logickéé skupiny ‐ tzv. domény: plánovvání & organ nizace (domééna PO, obsaahuje 11 proccesů), akvizicce & implem mentace (dom ména AI, obsaahuje 6 proccesů), dodávvka & podpora (skupina D DP, obsahuje e 13 procesů), monitoring ‐ měřeení a hodnocení (skupina M, obsahujee 4 procesy). Ceelkem tedy d definuje COB BIT™ v těchtto 4 doménáách 34 ICT procesů. Pro každý z těch hto prrocesů je po opsán rozpaad na detailní činnosti (Activities), jejich vstu upy a výstup py. Prro každý pro oces je rovn něž navržen n referenčníí soubor cíllů (CSF ‐ kritické fakto ory ússpěšnosti), výýsledkových metrik (KGI ‐ Key Goal Indicators) a výkonnostních metrik (K KPI ‐ K Key Performaance Indicators). Dáále jsou ke každému k z 34 3 procesů k k dispozici konkrétní k krittéria a meto oda hodnoce ení ceelkové kvalityy procesu. Hodnotící škáála je společn ná pro všech hny procesy aa má 6 stupň ňů, od d 0 (proces n neexistuje), d do 5 (proces je zcela optiimalizován). Hodnocení kkvality proce esů slo oužící jako nástroj n audittorům inform mačních systtémů v podobě měkkýcch metrik, a to prro případ, žee auditovanýý informační systém po odniku nemáá zavedený ssystém měře ení přříslušných metrik, naznaččený výše. oučástí modeelu COBIT™ je rovněž mapování m strruktury COBIIT™ na strukkturu Balancced So Sccorecard (BSSC ‐ definu uje co man nagement míní m "proveedením činn ností" a mě ěří, zd da management dosah huje požad dovaných výsledků). v Pomocí m metodiky BSC B CO OBIT™rovněžž navrhuje, jjak efektivněě vytvořit infformační strategii podniku/organizacce. Vrrcholová čásst informačn ní strategie je definována jako sou ustava strateegických cílů ů v peerspektivách růstu/poznávání a interních processů. Návazně na tyto straategické cíle se vyytváří detailn ní „Scorecarrd“ informattiky, dělený na dílčí části (detailní „Scorecardyy“) ro ozvoje a pro ovozu IS. Přehledová sttruktura COB BITu (přirozeeně bez cílů ů a metrik) je uvvedena na náásledujícím o obrázku.
28 8
M Modelování p rocesů v pod dniku Podnikková (obchodní) strateg gie, její cíle a obchodní procesyy
Vedení (řízení) IS/IT
M1 monitoring procesů M2 ocenění do osažené úrovně řizení M3 hodnoceníí (nezávislá kontrola) M4 hodnoceníí (interní/ext. audit)
PO1 defice strategického plánu P p IS/IT P PO2 definice architektury IS/IT I P PO3 determinace technolo ogický ch trendů P PO4 definice organizace a v ztahů v IS/IT P PO5 řízení IT inv estic P PO6 řízení lidský ch zdrojů ů P PO7 komunikace strategie e a směru rozv oje P PO8 řízení shody s ex tern ními požadav ky P PO9 řízení rizik P PO10 řízení projektů P PO11 řízení kv ality /jakostii
COBIT
IS//IT kritéria
M ěření a hodnocení
efektivita e v výkonnost d důvěryhodnost in ntegrita d dostupnost p přizpůsobivost s spolehlivost
Plánování & Org ganizování
IT zdroje lid dé aplikace te echnologie prostředí, v y bav ení, podm mínky da ata
Dodávka & Podpora
Akvizice & Implementace
DS1 definice a správ a "serv isních úrov ní" DS2 správ a služe eb třetích stran DS3 řízení v ý konnosti a capacit DS4 kontrola konttinuity služeb DS5 kontrola bezp pečnosti sy stémů DS6 identifikace a alokace prov oz. nákladů ů DS7 v zděláv ání a osv ěta uživ atelů DS8 asistenční slu užba zákazníkům DS9 řízení konfigu urací DS10 řízení událostí a mezních stav ů DS11 správ a dat DS12 správ a v y bav b ení a prostředí DS13 správ a provv ozních procedur
AI1 AI2 AI3 AI4 AI5 AI6
iden ntifikace automatizov aný ch c řešení akvv izice aplikačního prog. v y bav ení akvv izice technologické infrasstruktury v ý v oj a správ a prov ozních procesů insttalace a certifikace sy stém mů říze ení změn
Obrázeek ‐ Strukturaa COBIT Ceelkem lze ted dy v COBITu najít kompleexní systém sstovek cílů a metrik pro vvšechny oblaasti IC CT. Právě vyssoká kompleexnost je hlaavní silnou, ale a i slabou stránkou CO OBITu, který je do obře uplatnitelný u veelkých podniků, pro malé a střed dní podniky je však je eho ko omplexnost a složitost příliš p vysoká. I střední po odniky ovšem m mohou z této metodiky prrofitovat, po okud si napřř. nechají provést auditt dle COBITu u od firmy specializovaané naa ICT poradenství.
M Model CMM MI – model zralostii software e Zkkratka CMM se již dlouh hou dobu po oužívá zejmé éna ve spojeení s tzv. Mo odelem zralo osti so oftware – CM MM‐SW (Cap pability Matu urity Model for Softwaree), nebo obeecně pro celou řaadu modelů zaměřených h na hodnoccení a zlepšo ování processů podnikovvé informatiky, ktteré jsou vyyvíjeny v Sofftware Engineering Insttitute (SEI), součásti Caarnegie Mellon
29
Bu usiness modeelování niversity. Přii zavádění CMM modelu u je nutné si uvědomit, žže jde o posttupný evolučční Un prroces, kdy ceelá firma se po jednotlivvých krocích h přetváří a vyvíjí. Každýý stupeň CM MM deefinuje cíle, které je nuttné splnit, aby a se napln nily podmínkky dané úrovvně. To má za náásledek plyn nulý přerod firmy v orgganizačně lep pší instituci, aniž by se dělaly nějaaké skkoky. Pravě takové rycchlé až hektické posu uny v organ nizaci firmyy mohou vé ést i kke zhoršení stavu s a v důsledku d pošškození jak firmy, tak i i klientů. Prroto je časo ový haarmonogram m nasazení CMM C dosti náročný a důležitý d a velmi v se ned doporučuje jej urrychlit či coko oliv vynechat. ZAPAMATTUJTE SI
Referenční model R m CMMI se skládá pouze z mo odelu processů. Další sou učásti modellu ř řízení podnikkové informaatiky zde neejsou zahrnu uty. CMMI v současné době zahrnujje č čtyři integro ované součáástí, které mohou být používány buď samostatně, neb bo d dohromady, aniž by došlo o ke vzájemn ným nekonzistencím. Tyyto oblasti jsou: systém mové inženýýrství (Systeems Engineering) – zaahrnuje vývo oj a dodávvku systém mů, které mohou m obsahovat softw ware. Systém moví inženýřři se soustře edí na transformaci požadavků zákazníků ů, jejich očekávání a omeze ení u těchto řešení v průbě ěhu do "prroduktových či systémových řešení"" a podporu životního cyklu sysstému, softwaarové inženýýrství (Softw ware Engineering) – zah hrnuje vývojj softwarovýých systém mů. Softwaaroví inženýýři se sou ustředí na aplikaci syystematickýcch, disciplinovaných a kvantifiko ovatelných přístupů p k vývoji, v provvozu a údržžbě softwaare, integrovaný vývo oj produktů a procesů ů (Integrateed Product and Proce ess opment IPPD D) – představuje systematický přístu up, s jehož p pomocí dochází Develo ke včaasné a přesn né spolupráci zodpověd dných osob v v průběhu žživotního cykklu produktu s cílem m lépe uspo okojit požad davky zákazzníků, jejich h očekávání a omezeení. IPPD sáám o sobě nepřinese podniku zleepšení. Je ttřeba ho vžždy kombiinovat se speecifickým mo odelem vývo oje produktu,, řízení dodavatelů (Supplier Sourcing) – jakk postupně ro ostou nárokyy na dodávku u a ných produkktů, mohou projekty využívat v dod davatelů, ktteří strukturu výsledn provád dějí činnosti nebo modiffikují produkkty, které pro ojekt potřebuje. V případ dě, že jso ou takové aktivity a pro projekt klíččové, lze veelmi mnoho efektů získkat prostřřednictvím činností č anaalýzy dodavvatelských zdrojů z a z monitorováání činnosstí dodavateele ještě před p dodávkkou. Tato oblast o zahrn nuje i procces pořizo ování (nákupu) produktů od dodavate elů. Přři implementtaci referenččního modelu CMMI lze postupovat dvěma záklaadními cestaami (p průběžnou a postupnou). 30 0
M Modelování p rocesů v pod dniku M Model průběž žného zlepšo ování (Contin nuous) Prrůběžné zleepšování needefinuje pořadí, p ve kterém mají být im mplementováány či zlepšovány jednotlivé procesy podnikové informatikyy. Používá tzv. "úrovvně scchopnosti" (C Capability Levvels), které jsou definováány pro každ dý proces CM MMI. S každou úrovvní schopno osti procesu jsou spojeny určité kon nkrétní požadavky na je eho prrůběh. Jejich náročnost ss rostoucí úro ovní roste. Pokud process splňuje požžadavky úrovvně 5, probíhá opttimálně. Teento model u umožňuje po odnikové info ormatice: vybratt si pořadí, v jakém budou b procesy zlepšovvány tak, ab by co nejlé épe podpo orovalo cíle p podnikání a o operativně o omezovat oblasti rizika, porovnávání napřříč a mezi jednotlivými podniky naa základě sttejných krite erií ocení, hodno využít výsledků zísskaných v podniku prostřřednictvím přředchozí aplikace M Model postup pného zlepšo ování (Staged d) Po ostupné zlep pšování defin nuje pořadí, ve kterém m mají být implementovány a zlepšováány jednotlivé pro ocesy podnikové inform matiky. Postu upné zlepšovvání používáá tzv. "úrovvně zralosti" (Maturity Levels). Pro každou u úroveň zralosti je defin nován seznam m a požadavvky naa průběh urččité skupiny procesů. S rostoucí úrovvní zralosti ro oste i počet požadovanýých prrocesů. Poku ud procesy podnikové informatiky splňují požaadavky úrovvně 5, pracu uje po odniková info ormatika opttimálně. Teento model u umožňuje po odnikové info ormatice: použítt ověřený po ostup zlepšo ování, který začíná s jed dnoduchými manažerskýými postup py (postupyy řízení) a a postupuje e po předeem definovvané sekvenci násled dných úrovníí, "jedno ohodnotové"" hodnocení stavu řízení informatiky podniku, porovnání stavu řízení ř inform matiky jako celku c s jiným mi podniky, kkteré používvají stejnýý přístup. Z hlediska po oužití tohoto o modelu v praxi měřen ní v procesu u chybí podrobnější popis jednotlivých činností č měřeení (týkajícícch se zejmén na analýzy, sběru s dat a jejich ukládáání do o databáze měření), m kteeré jsou zde uvedeny naa velmi obeccné úrovni. D Dále v mode elu CM MMI chybí seeznam metriik použitelnýých pro měře ení podnikovvé informatikky. ZAPAMATTUJTE SI
ZZásadní odliššností CMM od jiných no orem je, že sse nejedná o o model, který organizacce z zavede, získáá „certifikát““ a dál už může m jen udrržovat a inteerně vylepšo ovat. CMM je j s stavěno jako cesta, která pomáhá k n neustálému zzlepšování úrrovně řízení a vývoje.
31
Bu usiness modeelování ornění CMM je uvedeno na následujíícím obrázku u: Grrafické znázo
Obráázek ‐ Model C CMM
Kaaždá procesní oblast je v modelu specifikován na tzv. cíly a ty jsou dále upřesně ěny do oporučenými postupy, ale také příklady či odkazzy a vazbami na jiné oblasti některé ého z m modelů rodiny CMM.
M Model ITIL – Infrastrructure Lib brary ITIL ‐ Knihovnaa infrastruktury IT (Infrasstructure Lib brary) je rozssáhlý soubor postupů říze ení po odnikové info ormatiky pro ostřednictvím m služeb. Jde e o knihovnu u čítající vícee než 40 svazzků vyydaných britsskou vládní aagenturou C Central Comp puter and Teelecommuniccations Agen ncy (C CCTA). CCTA je v současn nosti začleněěna do strukktury Office o of Governmeent Commerrce (O OGC). ITIL byyl vyvíjen od o 80. let minulého m sto oletí. Cílem CCTA při výývoji ITIL byylo po odpořit efekktivitu využívvání informačního systé ému s ohledem na po ožadavky fire em sn nižovat náklady na úd držbu a zkkvalitňovat služby informatiky. ITIL je založžen naa mezinárodn ních normácch ISO řady 9000 a shrn nuje nejlepšíí zkušenosti z praxe. Prvvní ko ompletní sku upina knih byyla vydána v roce 1995. 32 2
M Modelování p rocesů v pod dniku ITIL měl již z počátku velkýý úspěch, ke kterému přisspěla řada faaktorů: přinášší ověřené po ostupy řízeníí podnikové iinformatiky ((Best Practicces), je pod dpořena celo ou řadou SW nástrojů, opírá se o normyy kvality ISO O řady 9000 0 či EFQM (European ( FFoundation for f Qualitty Management). ZAPAMATTUJTE SI
Referenční model R m ITIL se s skládá z modelu prrocesů, ke kterým k jsou v některýcch p případech př řipojeny mettriky jejich effektivnosti. D Dále jsou zdee uvedeny prrincipy tvorb by n nástroje evid dence IS/ICTT. Další sou učásti modellu řízení po odnikové informatiky zd de n nejsou zahrn uty. ůvodně každ dá z knih ITIL pokrývala jeden speciifický process informatikyy a popisovaala Pů jeho vazby k ostatním procesům. p Každá kniha mohla být čtena (a přříslušný procces im mplementováán) nezávislee na ostatních. Poskytováání služeb informatiky ovvšem může b být op ptimalizován no nejlépe teehdy, vezmou u‐li se v úvah hu všechny p procesy jako celek. Podniky vžždy získají vícce při implem mentaci všecch procesů, n než při separrátní implementaci proce esů vyybraných. Sn naha o lepší integraci pro ocesů vedla k revizi a vyydání aktualizzovaných kn nih, v nichž jsou hlavní procesyy seskupeny do svazků: oří základní zznalostní rám mec metodikky ITIL zahrnu uje: Záákladní svazeek – který tvo "Poskyytování inforrmačních slu užeb a řízení infrastruktu ury informatiiky" (IT Service Provission and IT Infrastructu ure Managem ment Set) – – skládá se ze dvou kn nih, popisu ujících klíčovvé procesy, které musí informatikaa provozovat, aby zajisttila kvalitn ní informaticcké služby pro své zákazn níky: "Podp pora služeb (Service ( Sup pport)" ‐ tato o kniha pop pisuje vzájem mně propoje ené processy, které pod dporují stabiilitu a flexibilitu poskytovvaných služeeb informatiky. Týkají se zejménaa identifikacce a sledováání konfiguraačních položžek, incidentů, probléémů a změn,, "Dodáávka služeb (Service Deelivery)" – taato kniha popisuje p procesy zajišťujjící dodávvku kvalitnícch služeb podnikové p informatiky. Tyto proccesy se týkkají plánovvání SLA, ko ontraktů, služžeb a řízení nákladů v průběhu p různých časovýých intervalů, Doplňkové svazkyy – přinášejí základní po ostupy či návvody, týkajíccí se činností a ocesů. Někte eré schopností nutnýcch pro efekttivní provádění výše uveedených pro jsou zaaměřeny na aplikace ITILL procesů ve specifických h oblastech: "Svazeek manažerra" (Manageer's Set) – knihy určeené vysokým m manažerů ům a koorrdinátorům služeb inforrmatiky, kteřří jsou zodp povědní za řřadu funkčníích oblasttí podnikovéé informatikky. Zahrnujíí informace o tom, jaak organizovvat pracovvníky (funkcce a role), a a informace o tom, jak plánovat a úspěšně říídit vztahyy s dodavateli a zákazníkyy,
33
Bu usiness modeelování "Podp pora softwarre" (Softwaree Support Se et) – popisuje ty aspektty řízení služžeb inform matiky, které se vztahují k vývoji softwarových prroduktů. Zah hrnuje zejmé éna tématta podpory životního cyklu softw ware a testtování informační služžby před jejím provozn ním používán ním, "Počíttačový provo oz" (Computter Operatio ons Set) – skupina s knih h týkajících se manažžerů provozzu počítačů (nebo praacovníků v této oblastti), kteří mají m na starosti rozsáhlé instalace (zejmén na mainfram me nebo centralizovaané provozu, říze ení serverrové farmy). Zahrnují zejména témaata řízení počítačového p nenah hraditelných zdrojů a zdro ojů třetích sttran a bezob bslužné operaace, "Prosttředí" (Enviro onmental Seet) – skupinaa knih, kteráá přináší návvody týkající se otázekk prostředí, které musí být řešeny v rámci plán nování, instaalace a údržžby infrasttruktury IS//ICT. Zahrn nují témata řízení um místění IS/IC CT, standarrdy pro um místění vyb bavení, prottipožární op patření, opaatření proti interferen nci, zajištěění dodávkky elektrickké energie, specifikacce kabelážee, omezováání akustického šumu, údržba kvaalitního prosttředí pro ICTT, lidské faktory v prostře edí CT, kanceláře, design kanceláře a její plánováání, pracovníí prostředí kaanceláře a IC řízení kvalitního prracovního prrostředí pro uživatele podnikové info ormatiky, "Obch hodní pohled d – pohled hlavních pro ocesů podniiku" (Busineess Perspectiive Set) – – knihy, týkaající se témaat, která by měl ovládaat každý manažer podniiku (nikoliiv jenom maanažer podnikové inform matiky) – změěny podnikovvých procesů ů a jejich dopad na po odnikovou in nformatiku, jak změny v informatice mohou změnit ocesů podnikku apod. způsob provádění hlavních pro užití tohoto m modelu v praaxi měření zd de chybí pop pis procesu m měření. To ne ení Z hlediska pou no žádným specifickým s procesem. U jednotlivýých procesů jsou ale vžždy v ITIL zajištěn uvvedeny poznámky týkajíccí se způsobu u jejich měře ení a případn ně vzorové m metriky. Naa druhou stranu jsou u jedno otlivých pro ocesů identtifikovány jjejich výstu upy (i s uvedenými konkrétním mi příklady), které slo ouží jako zááklad pro ttvorbu mettrik po odnikové info ormatiky.
M Model SPS PR Jeedním z problémů současného pod dnikového říízení je naleezení a zajišštění optimáální informatické p podpory pod dnikovým pro ocesům a tím m také zajišttění co nejvyyšší návratno osti nformačních a komunikačních technologií (ICT)). Tato kapitola objasňu uje investic do in model SPSPR, který byl vyyvinut na kaatedře inform mačních tech hnologií VŠE a který byl již něěkolikrát úsp pěšně ověřen n v praxi. Model řeší vztahy M v mezi řízením po odnikových procesů a řízením pod dnikových IC CT. Záákladem mod delu je řízeníí firmy na pěěti vzájemně provázaných h vrstvách S ‐‐ Strategy P ‐ Business Prrocesses S ‐‐ ICT Services
34 4
M Modelování p rocesů v pod dniku P ‐ ICT Processses R ‐ ICT Resources
Obrázzek – Model SPSPR ZAPAMATTUJTE SI
C Cílem rozděle ení řídících aaktivit do pětti vrstev (úro ovní) je: takovvé strukturo ování podnikových činností a zodpovvědností, kteeré optimáln ně odpo ovídá současným požadavkům na flexxibilní a efekktivní podniko ové řízení, jasnéé určení zodp povědností různých typů manažerů/sspecialistů v podniku, zprůh hlednění způsobu deko ompozice po odnikových cílů c až na ú úroveň řízen ní provo ozu ICT, vytvo oření schémaatu, ze kteréého je možné odvodit vh hodné metriky úspěšnossti jedno otlivých typů ů procesů a zza ně odpově ědných manažerů (viz míísta označen ná budíkkem).
35
Bu usiness modeelování olového (TO OP) Prrvní vrstva ‐ strategické řízení podniku je v plné kompeetenci vrcho managementu u. Hlavními vvýstupy této úrovně řízen ní jsou zejmééna tato rozh hodnutí: jaké cííle a priority bude podnikk sledovat, jaké produkty/služžby bude pod dnik poskyto ovat a jakému okruhu zákkazníků, do jakkých aliancí a kooperačních vztahů podnik vsto oupí. Které kompetence e a zdrojee podnik v ko ooperaci uplaatní a které n naopak očekává od svých h partnerů, jak naa hrubé úrovni budou u probíhat materiálové m a informačční toky mezi partneery v řetězci,, jaké liidské, znalosstní/informaační a finančční zdroje budou v podniku zapotře ebí a jak b budou získán ny (a přebyteečné uvolněn ny), jaké m metriky budo ou použity k m měření stupn ně dosažení cílů. mným trendeem této vrsttvy řízení prropojování, resp. společčná Z hlediska ICTT je význam tvvorba hlavníích částí po odnikové strategie, straategie podn nikových zdrrojů (Sourciing Sttrategy) a informační strategie. s Smysl a cíle e své existeence organizace naplňu uje prrostřednictvíím hlavního předmětu podnikání, tj. prostřednicttvím hlavnícch podnikovýých prrocesů. Úllohou druhéé vrstvy řízení – tj. vrstvvy hlavních a podpůrnýcch procesů ‐‐ je navrhno out a řřídit podniko ové procesyy tak, aby orrganizace do osáhla strateegických cílů ů definovanýých prrvní úrovní říízení. Hlavním mi aktivitami této úrovně ě řízení jsou:: definicce a optimalizace podnikkových proce esů, operativní řízení p procesů a kap pacit, monitoring processů, realizaace (vykonávvání) procesů ů.
36 6
M Modelování p rocesů v pod dniku
hy mezi jedn notlivými typy manažerů v SPSPR mod delu Obrrázek – Vztah de se dostávááme k významné charaktteristice mod delu SPSPR , která reaguje na součassný Zd treend v rozděělování pravvomocí mezi business a ICT manažeery. Manažeer zodpověd dný zaa definici a optimalizaci podnikovéh ho procesu je zodpověědný za navvržení proce esu (jeednotlivých činností, jejiich návaznossti, zodpovědností za jed dnotlivé činn nosti atd.) taak, ab by proces prrodukoval ko onkurenceschopný produ ukt/službu v v optimálním m čase, objem mu a kvalitě s přijaatelnými nákklady. ZAPAMATTUJTE SI
SSoučásti návvrhu podnikkového proccesu musí být b i návrh takových in nformatickýcch s služeb, které é budou optiimálně podp porovat příslušný proces. Zde je jedn no z klíčovýcch m modelu míst u. Není‐li mo ožné zajistit požadované é informaticcké služby zaa tuto limitn ní c cenu, je třeb a upravit hlaavní proces aa jeho požadaavky na inforrmatické služžby.
37
Bu usiness modeelování ní – k vrstvě řízení inform matických slu užeb. Potřeb bné Tím se dostáváme ke třetíí vrstvě řízen upuje“ manaažer procesu u manažeraa(ů) informatických služe eb. informatické sslužby „naku ní informatikky (který je s ohledem na zajištěn ní integrity ICT Přři centralizovvaném řízen vh hodnější) vysstupuje v ro oli manažeraa všech info ormatických služeb ředittel informatiky (C Chief Informaation Officer – CIO, inform mační manažžer). Jee vhodné, aby a definice informatickké služby měla m stejnou u strukturu, ať se služžba naakupuje inteerně v podn niku, nebo u u externího poskytovateele. Vhodná forma, běžžně po oužívaná při outsourcinggu, je tzv. SLA S (Service Level Agreeement), která pro každou slu užbu definuje její obsah, objem, kvallitu a cenu ‐ Použijeme‐lii stejnou stru ukturu definice slu užeb, pak máme m konzisstentní sadu kritérií pro rozhodnutí,, zda danou u službu (např. fu unkcionalitu aplikace pro o podporu výrobní logiistiky) nakou upíme od in nterního, ressp. exxterního poskytovatele. Informatická služba je prrodukována informatickkými procesyy. Příklady iinformatickýých prrocesů mohou být: Serrvice Level Managemen nt, Availability Managem ment, Incide ent M Management. . Informatickké procesy tvvoří čtvrtou vrstvu modeelu a jsou řízzeny manaže ery informatických h procesů. V Význam kvalitní definice informatickýých procesů roste zejmé éna s ttěmito param metry inform matických slu užeb: význam m podnikovvého processu, pro jeho ož podporu byla inform matická služžba vytvořřena (kritickéé podnikové procesy potřebují vysoce kvalitní slu užby), počet uživatelů služby s (napřř. je‐li službou „interneet banking“, pak čím vííce níků banky bude b tuto službu využívaat, tím preciizněji musí b být celý procces zákazn zajišťu ující službu říízen), nárokyy na kvalitu sslužby (dostu upnost, dobaa odezvy, bezpečnost, sp polehlivost), celkovvý počet infformatických h služeb (s růstem poččtu služeb rostou náro oky na inteegraci služeb b a integraci souvisejících h procesů a zzdrojů), celkovvý rozsah informatický i ých zdrojů, které jsou u informaticckými proce esy konzumovány. Z výše uveden ného plyne, že řízení infformatiky musí být v po odniku na tím m vyšší úrovvni, čím m více slu užeb si pod dnik zajišťu uje interně a čím nááročnější jso ou paramettry po oskytovaných h služeb. Po oslední, páttou vrstvou u řízení v SPSPR mod delu je řízeení (správa) jednotlivýých informatických h zdrojů. K nim patří zejm ména: techno ologická infrastruktura (h hardware, po očítačová síťť, základní so oftware), aplikační softwaree, data, spotřeební materiál a inform matický perso onál. Manažeři této M o úrovně majjí klasické informatické p profese: spráávce aplikacee, správce síítě, sp právce datab báze atd. Jeejich zodpovvědností je provozovat a udržovat svěřený zdroj s p přijatelnými náklady. Do správy teechnologických zdrojů patří p takové činnosti jakko: sleedování vytíížení zdroje aa jeho kapaccitní změny dle změn po ožadavků slu užeb, sledováání výývojových trrendů a pláánování dob by, kdy dojd de k upgrade zdroje aatd. Do říze ení peersonálních zdrojů patřří získávání pracovníků ů s příslušn nou kvalifikací, plánováání kvvalifikačního růstu a rekvvalifikací, řízeení časového o plánu jedno otlivých pracovníků atd.
38 8
M Modelování p rocesů v pod dniku Krritériem efeektivnosti prráce manažera zdroje je pořízení,, údržba a rozvoj zdro oje naa úrovni, kteerá je kvalittou srovnatelná s kvaliitou dostupnou na trhu a kapacittou od dpovídající nárokům inteerně zajišťovaaných inform matických slu užeb. KONTROLNÍÍ OTÁZKY
Co jee cílem proceesního modeelování v pod dniku? Co jee procesní maapa? Jak p postupujemee při tvorbě p procesní map py? Charakterizujte jeednotlivé refferenční mod dely podniko ové informattiky. Kterýý model osob bně doporuččujete a pročč? S SHRNUTÍ KA PITOLY
Model procesu znázorňuje informace, které nám slouží k tom mu, abychom m dit. Model p procesu je tvvořen objekty, resp. prvkky, které nám m proceesy mohli říd znázo orňují podstaatné informaace o processu. Proccesní mapa je základn ním prvkem m procesního mapován ní. Skládá se s z hierarchických grafických diagramů, d doplňujících textů, t slovnííku použitýcch mných odkazů ů termínů a definicc procesů, vččetně vzájem Referenční mod dely podnikkové inform matiky sou vytvářeny na základ dě ověřené vzorry zkušeeností jejich tvůrců z říízení informaatiky a obsaahují tedy o či varrianty řešeníí. STTUDIJNÍ LITEERATURA Baasl, J.: Podnikkové informa ační systémyy, Praha: Grad da, 2002, ISB BN 80‐247‐02 214‐2. apability Maturity Mod del® Integra ation (CMM MISM) – Veersion 1.1 – Continuo ous Ca Reepresentation, Technica al Report CMU/SEI‐20 002‐TR‐011, [online], TThe Softwaare En ngineering In nstitute, 2002 2, [cit. 2003‐‐06‐06], URL:
.. CO OBIT 3rd Ed dition – Control Objectivves, [online]], IT Govern nance Institu ute, 2000, [ccit. 20 003‐06‐06], U URL:
>, ISBN 1‐893 3209‐12‐1. ovotný, O.: SSystém evideence kompon nent IS/IT jakko základ prro měření ná ákladů IS/IT, In: No Syystems Integgration 2002,, Praha : Vyssoká škola ekkonomická, 2 2002, s. 429––436, ISBN 8 80‐ 24 45‐0300‐X.
39
Bu usiness modeelování
4 Metodiky řízzení pro 4. ojektů informaačních systémů ů v podnicích Ú ÚVOD Metodiky info M ormačních syystému v po odnicích nejssou samoúčeelné. Metod diky na úrovvni da aného podniiku či institu uce sjednocují a integrují. Jejich hlavní smysl je předevšíím v u upřesnění po ostupu vývoje projektu ISS a kodifikacii nástrojů a p pravidel upla atňovaných p při tvvorbě IS. Protto jejich důklladná znalost je nezbytná á pro práci podnikového informatika.. CÍÍLE KAPITOLY Y Po o prostudová ání této kapiitoly a vypra acování úkollů budete UM MĚT: Charakterizovat m metodiky vývo oje a nasazení informačn ních systémů ů v podniku Porovnat metodikky PMBOK a A ARIS Vymezzit úrovně řízzení v metod dice PRINCE 2 Po o prostudová ání této kapiitoly a vypra acování úkollů ZÍSKÁTE: Znalossti o projekto ovém a procesním pojetíí metodik Doved dnost zpracovat hlavní a podpůrné diisciplíny v meetodice RUP Schop pnost pracovaat s technikaami a procesyy v jednotlivých metodikkách Po o prostudová ání této kapiitoly a vypra acování úkollů BUDETE SC CHOPNI: Vymezzit přístupy aa funkcionality metodik Apliko ovat postupyy u jednotlivýých metodik na konkrétní podnikové situace Zpraco ovat inicializaační procesyy v jednotlivýých metodikáách
40 0
M Metodiky říze ní projektů informačních h systémů v p podnicích
4..1. Metod diky budovvání inform mačních sysstémů v po odnicích Metodiky vývo M oje projektů IS lze rozděllit podle mno oha kritérií. O Od jednoducchého přístupu přřes vlastní nosič metodiky (knihy, metodické m materiály, m skrripta, školen ní, elektroniccké do okumenty, html h dokum menty) až po p kritérium m nasazení metodiky ve specifickýých prrojektech vývvoje IS. Metodiky vývoje projektů M ů IS lze posu uzovat i podle dalšího výýznamného kritéria. Tím mto krritériem je právě p processní přístup a a jeho zabu udování v po ojetí dané m metodiky. Jaako metodiky s procesním p přřístupem ch hápu ty mettodiky vývoje IS, které mají ve svýých standardních postupech,, pravidlech h, dokumen ntech řízení, metodách, technikáách a nástrojích uplatňovány dříve uvedeené obecné principy pro ocesního příístupu k říze ení prrojektů IS. OTÁZZKY
Nabízí se zákkladní otázkaa při vývoji a tvorbě IS. Je N e možné vyviinout IS bez projektovéh ho ř řízení? Je mo ožné vyvinout IS bez prrocesního přřístupu? Staččí pouze znaalost věcnéh ho o obsahu jedn notlivých fázzí životního cyklu bez procesního řízení celého projektu u? O Odpověď je podle auto ora následujíící. Vlastní tvorba a výývoj IS je vžždy procesn ně a a projektově řízena. oces vývoje IS, jsou ob bsaženy nejjen Záákladní prvkky, které deeterminují funkci a pro v kategoriích kdo, k co, pro oč, za kolik, ale a i v kateggoriích opako ovatelných ččinností, jejicchž výýsledkem je měřitelný výýstup. Jakkolliv můžeme připustit myyšlenku neusstálého rozvo oje vlaastního IS, vždy je tento nekonečný proces prakticky p rozdělen na kkonečný poččet čin nností – pro ocesů. Každá tato část musí být procesně říízena, musí být stanove eni vlaastníci proccesů, proceesní vstupyy a výstup py, odpověd dnosti a zzpětnovazeb bné mechanismy. Oba přístu upy a akcentty však nejssou protichů ůdné – jsou to dvě straany stejné mince. Procesní příístup více geeneralizuje, vvytváří prosttor pro změny, zdůrazňu uje prrvky účelnéh ho řízení (p prostřednictvím strateggických proccesů jako základní složžky neeprodukčních h procesů), vytváří prostor pro konkrétní sled dování přidaného hodno oty prroduktu na jeho cestě ke konečném mu spotřebite eli a uživateli. Projektovvý přístup vííce fo ormalizuje, zaměřuje se na vlastní cestu c a obsaah řešení, neevytváří dostatečný rám mec prro strategii a a činnosti stratéga projeektu, tedy ve e svém koneečném důsleedku zmenšu uje prrostor strateegické řízení a plánováníí. Projektování zdůrazňu uje prvky účelovosti, vellmi po odrobně rozzpracovává metody, meetodiky a te echniky i v jejich konkrétním užitíí a vyyužitelnosti p podpůrných nástrojů a teechnologií.
41
Bu usiness modeelování onstatuji velmi důležitý ffakt. Naa základě přeedchozího ko ZAPAMATTUJTE SI
Čistá metodika vývoje IS klade důrazz na obsahovvou část tvo Č orby IS. Cílem m procesníh ho p přístupu v ře uze vytvořen ní pevného m modelu a pop pis stávajícíh ho šení projektů IS není pou p projektového o stavu. Jdee především o vytvořeníí předpoklad du pro kvalittní a efektivn ní ř řízení celého o procesu projektování IS, jeho prů ůběžné zlepšování a tak efektivnějšší n nasazení proj jektových teechnik, nástro ojů ve vazbě na vlastní projektové výýstupy. Metodika pro M ocesní tvorbyy a vývoje projektu IS je tedy smysluplným sspojením dvvou po ohledů, kteréé musí platitt zároveň. P Procesní řízení projektu jje takové jeh ho uspořádáání, ktteré maximálně odpovídá realizaci jeednotlivých p procesů v prrojektu. Základním prvke em je podstatná změna v myšlení m vykonavatelů a manažerů projektových p h aktivit, jejiich zm měna pohled du a role správce, tvůrcee, dohlížitele na kvalitu –– tedy na vlaastníky proce esů v projektu IS. Proto v této o práci je zdůrazněno ozznačení proceesních meto odik projektů ů IS (reespektive procesních prvků p v mettodikách pro ojektů IS), které je po oužito ve výýše po opsaném pro ocesním a prrojektovém p přístupu. Nííže uvedené metodiky projektů majíí za úkol neje en definovatt projektový čas, strukturu, prrojektové etapy, obsah a zdroje, alee vymezují i procesní vsstupy a výstu upy, činnostti a jejjich zabezpeečení odpověědnými vlastníky procesů ů, hledají pro ocesní nástro oje pro změn ny, zaabezpečení kvality k výstu upů, ale i po ostupy a vaazby k realizzaci procesů ů zabezpečujjící naaplnění projeektové strateegie ve vazběě na potřebyy konečného uživatele produktu.
4..2.
Přehlled jednotlivých mettodik řízen ní projektů IS v podniicích
M Metodika Project M Managem ment Bod dy of Knowledge ((PMBOK)) Taato metodika významn ně posunulla snahy o o standardizaci projekktového říze ení v zznalostním aa procesním pojetí (a to nejen v oblasti IS/IT). Jeejí jádro a záákladní pohlled naa všechny akkcepty projekktového řízeení byl navrže en již v roce 1987 na praacovišti Proje ect M Management Institut (USSA). Postupně byly vydávány další verze v této m metodiky, kte eré up přesňují vytvořené znalostní oblassti projektovvého řízení. Projekt je tedy založžen naa znalostech,, dovednosttech, nástrojjích a techn nikách, za účelem ú uspo okojení potřřeb prrojektových uživatelů. Standard rozděluje projekt do o 9 znalosstních oblaastí a 5 základních fází (stádií p projektu). Ab by byl projekkt úspěšný, projektový tým musí: vybratt vhodné pro ocesy z proceesních skupin n, dodržo ovat předem m definovanéé přístupy a sstandardy, vyhovvět požadavkkům zainteresovaných skupin, užívat procesní znalosti za účelem vyrovnání v m míry projekttových potřřeb davek na sysstém, rámec, čas, kvalitu,, zdroje a riziika). (požad Sttandard PMB BOK je primárně zaměřeen na podniky dodávajíccí služby pomocí projektů. Naavíc řeší so oužití liniovéé a projekto ové strukturry v projekttu, což je vvelmi výhod dné i p pro implementaci metodiky v jakémkkoliv odvětví a stylu řízen ní. 42 2
M Metodiky říze ní projektů informačních h systémů v p podnicích Prrocesní pojeetí metodikyy je chápán no již vlastním rozděleením projekktových aktiivit do o procesních skupin. V každé skupině jsou pop psány tzv. hlavní h (pro d danou skupinu klííčové) a pom mocné processy. Výstupy p pomocných procesů slou uží hlavním p procesům daané skkupiny. Pro ocesní skupin ny obsahují dle zpracovvané metod diky PMBOK dle P. Mau ule náásledující pro ocesy: Inicializační prrocesy ument pro tuto t skupinu u popisuje jeden proces a to procces inicializacce. Prrocesní doku Hllavním účelem tohoto procesu je vytvoření základní deefinice projeektu obsaže ené v zzakládající listině projeektu a získáání autorizacce pro vlastní realizacii. Jde v ně ěm přředevším o schválení pro ojektu popříp padě další fázze projektu. Plánovací procesy ů zasahujícíích Taato skupinaa obsahujee 10 hlavních a 9 podpůrnýcch procesů do o všech znalo ostních oblasstí. Proces p používá strategických výýsledků před dchozí procesní skkupiny a formuje je do taktického plánu realizaace. Jde o poměrně p klíččovou skupinu prrocesů, kteráá obsahuje procesy jako je např. definování d ro ozsahu, plán nování čerpáání zd drojů a přiřazení zdrojů ů činnostem m, odhady nákladů n a času č a v neeposlední řaadě ko ompletní analýzu rizik (nalézá ( se v v podpůrnýcch procesecch). Všechnyy procesy jssou po opsány ve zn nalostních ob blastech PMB BOK. Re ealizační pro ocesy Ob bsahují vlasttní řízení pro ojektu v jeho o průběhu, kkoordinaci akktivit, které jjsou zaměře eny naa výkon a koo ordinaci dřívve naplánovaaných prací p projektu. Obssahuje jeden n hlavní a sed dm po odpůrných procesů. p Hlaavní process nazvaný realizace r pláánu projektu je zaměřřen naa řízení dílčíích činností definovanýých v plánu. K tomu mu m napomááhají pomoccné prrocesy, jako jje např. distrribuce inform mací, dosaho ování kvality atd. Ko ontrolní a monitorovací procesy Jsou zaměřen ny na soulad d výkonu reealizačních složek s s jeh ho plánem. Tato procesní skkupina je rozdělena na dvva hlavní a šeest pomocnýých procesů.. Hlavní proccesy se nazývvají řízzení, monito orování, konttrola a integgrovaná konttrola. Zaměřují se zejména na zajiště ění kvvalitní zpětn né vazby, ko ontrolu sled dování týmo ového výkon nu, vlastní reportováníí a integrovanou kontrolu zm měn. Pomoccné procesy pak detailn něji popisujíí dílčí kontro oly (n např. kontrola změn, rizikk, harmonogrramu, kvalityy nákladů a vverifikace cílů ů a rozsahu). Ukkončovací a uzavírací procesy Um možňují vlastní finalizaci projektu. TTato skupina procesů neo obsahuje pom mocné proce esy a jje rozdělena do dvou hlaavních procesů nazvaných administraativní zakonččení a uzavíráání sm mluv (uzavíráání kontraktů ů se subdodaavateli). ZAPAMATTUJTE SI
ZZnalostní obllasti v processním pojetí ttvoří další základní část sstandardu PM MBOK. Každ dá z znalostní oblast je podrobně popsána svými vlastnostmi a frekvencí p použití. Každ dá k kapitola pakk obsahuje popis proceesů a jejich nástrojů a technik, kteeré umožňu ují r realizovat daanou oblast,, proces neb bo činnost. U každého znalostního z procesu jso ou d definovány v vstupy, výstupy, činnosti a vhodné náástroje pro daaný proces.
43
Bu usiness modeelování diky P. Mamu ule následujíí znalostní ob blasti: Sttandard rozlišuje dle přeekladu metod Ko oordinace a integrace prrojektu (Projject Integrattion Manage ement) Zn nalostní obllast zajišťuje především m integraci a návaznosti na jin né projekty a ko oordinování změn v celém průběhu proje ektu, zahrnuje metodyy a techniky prro plánování a koordinovvání projektu u, zejména p pak zpracováání požadavkků na změnu u a jejjich následn nou koordinaci. Kontrola změn se prolíná celýým projekteem a zasahu uje do o oblastí jako o je např. kontrola změn kvality, plán nu (naplánovvání času a zd drojů), rozsahu (specifikace neebo zadání p projektu), nákladů (rozpo očtu) atd. u (Project Sccope Manage ement) Říízení rozsahu Říízení rozsahu u především analyzuje ro ozsah projekttu. Rozsah p projektu je zd de chápán jaako so ouhrn a násleedný rozklad projektu naa menší jedno otky činnostíí. Říízení času (Project Time Managemen nt) Jd de především m o plánován ní časových aspektů projektu ve vztahu k ostatn ním atributům, jako jsou lid dské zdroje,, rozpočet, náklady a jiné. Pojeednává takéé o technikáách od dhadování času č jednotliivých úkolů (optimistickký, realistickký a pesimisstický) a jejiich prraktické využžití. Říízení finančn ních toků (Prroject Cost M Managementt) Říízení finančn ních toků jee oblast zam měřená na plánování a a řízení nákladů projektu. Prrocesy obsahují také sp právu zdrojů ů (resourcess pool), kterré zahrnují přehled vše ech zd drojových po otřeb (materiiál, finance aa pracovníci).. Říízení kvality (Project Quaality Manage ement) Říízení kvality prostupuje ccelým projekktem. Je třeba upozornitt, že zde je chápáno říze ení kvvality ve smyyslu zajištění kvalitního průběhu projektu a jeh ho kontroly. Kvalita se zde z neevztahuje po ouze ke kvalittě produktu//služby jako výstupu daného projektu u. Říízení lidských h zdrojů (Pro oject Human n Resource M Managementt) V této znalosstní oblasti jsou j popisovvány způsob by a procesyy vyhledávání nových liidí, z osti výývoje organiizační strukttury, definovvání rolí ‐ zodpovědno stí, zlepšováání výkonno týýmů a techniky jejich sesttavování. Říízení rizik (Prroject Risk M Managementt) Ob blast řízení rrizik je velmi podobná klaasickému riskk managemeentu, který vv sobě zahrnu uje prrocesy identtifikace rizikk, kvalifikacee rizik, zodp povědnosti za z rizika a kontrolu rizzik. PM MBOK v této o části popissuje velmi ob becně postupy pro identtifikaci, vyčísslení, násled dné zaajištění, snižo ování a elim minaci rizik. Detailněji popisuje p dokkumentaci riizik, plán rizzik, ktterý by měl být součásstí každého projektu, a a jeho údajje by měly být průběžžně akktualizovány v průběhu realizace projjektu. Říízení dodávkky (Project Procurement Management) Taato znalostní oblast se týká produkktu, který je e v rámci prrojektu vytváářen. Jsou zde z po opisovány zejména z obcchodní posttupy a techniky spolu u s definováním pravid del k udržování vzztahu se zákaazníky.
44 4
M Metodiky říze ní projektů informačních h systémů v p podnicích
M Metodika ARIS oučasných, v praxi pou užívaných nástrojů n pro o modelován ní procesů, je Jeedním ze so modelovací nástroj n ARIS,, jejímž auttorem je prrofesor A. W. W Scheer. Zkratka AR RIS hitekturu Inttegrovaných h informačníích Systémů. Nástroj up platňuje vlastní ozznačuje ARch prrocesní metodiku modeelování proccesů. Tato metodika m je podpořenaa softwarovýým prroduktem prro modelováání a optimalizaci processů (ARIS Too olset). Cílem této metodiky je vytvářet dyynamické po ohledy podnikových (pro ojektových) procesů, op ptimalizovat je a vvyužít je pro o celou řadu ččinností. ZAPAMATTUJTE SI
Metodika AR M RIS popisuje podnikovou u realitu pom mocí pěti zákkladních poh hledů: datovvý p pohled, proccesní pohled d, funkční pohled, p orgaanizační poh hled a výkonový pohled d. M Metodika staanovuje jedn notná pravid dla pro vytvááření, úpravu a udržování procesnícch m modelů orga nizace. nou ARISu jee, že dokáže snížit složito ost modelování reality procesů pomo ocí Veelkou výhodn výýše uvedenýcch pohledů, a to pomoccí vzájemné integrace v rámci použittého softwaru. V závislosti naa potřebách vedení orgaanizace je možné u jedno otlivých proccesů definovvat prro každý typ p procesu ro ozdílnou hlou ubku podrob bnosti. Dále je možné p při modelováání prro každý pro oces definovat jeho atributy, včetně ě časových a a nákladovýých parametrů, jako podklad d pro následnou simulaci a op ptimalizaci procesu. Zaaměříme‐li se naa modelován ní procesů nástrojem ARIS, pak mezi základ dními modeely z pohle edu orrganizace bu ude vytvořen ní organizační struktury procesní jeednotky, která je násled dně prrovázána s osstatními mod dely procesů ů v dalších po ohledech meetodiky ARIS.. V oblasti proccesních pohlledů je záklaadním mode elem Diagram m tvorby přidané hodno oty (D Diagram Valu ue Added Ch hain), který podává jasný přehled o celém proccesu na vyso oké ab bstraktní úro ovni. Funkcee (zde chápáána jako pro ocesní úlohaa, proceduraa nebo činno ost vyykonaná na o objektu) jsou u propojenyy do řetězce tvorby přidaané hodnotyy (Řepa, 200 06), přřičemž v tom mto řetězci see nevyskytujíí události. Te ento model m může zobrazzit posloupno ost prrocesů v rám mci procesníh ho řetězce, ale i hierarchické vztahy u u dílčích proccesů. Model se po oužívá pro znázornění zřřetězení procesů, kdy výýstup předch hozího proceesu je vstupe em náásledujícího procesu. Daalším význaamným pou užívaným modelem m je rozšířený procesní řřetězec říze ený ud dálostmi, ( eEPC e diagram ‐ extendeed Event drriven Processs Chain). Teento model je urrčený pro po opis procesu až do úrovně prováděnýých činností. Je to nejpod drobnější popis prrocesu. Procees je popsán n událostmi aa jimi spoušttěnými činno ostmi, které vvyvolávají daalší ud dálosti. Činno osti ke svém mu vykonání potřebují ně ějaké vstupy,, produkují n nějaké výstup py, jso ou podporovvány IT a jsou u vykonáván ny lidmi v mo odelu zastoupenými form mou procesníích ro olí. Pomocí tohoto t mod delu lze mod delovat proccedurální po osloupnost ffunkcí v rám mci ro ozsahu jednotlivých pro ocesů v orgaanizaci. Zákkladní prvky jsou funkcce, události a prropojovací konektory. k Funkce a události u hraají významn nou roli při reprezentaci prrocesních mo odelů. Modeel opět zobraazuje jak stattické vazby m mezi objekty z pohledu dat, fu unkcí, výstup pů ‐ výrobků//služeb, tak i organizačn ní hlediska a a dynamické chronologiccké to oky procesu.. Tyto modely lze přiro ovnat k posstupovým diagramům. d Jejich význaam
45
Bu usiness modeelování počívá v defiinování funkkcí (funkce popisují pro oces) a udállostí, které jsou iniciáto ory sp čin nností. Jednotlivé funkce lze dále hierarchizova h at na nižší úrovně pro zíískání úplné ého přřehledu o prrocesu. To jee výhodné zejména z u klíčových pro ocesů (proceesy s největšším výýznamem prro organizacci ve vztahu k plnění cílů). V těchtto modelech h lze používvat logické propojjovací operáttory (XOR, A AND, XOR). eré dávají celkový přeh hled aktuálníích Z pohledu výkonového lzze vytvářet modely, kte vsstupů a výstu upů včetně jejich vazeb. V pohledu ffunkčním lze pomocí modelů funkčníích stromů znázo ornit vzájem mné vazby mezi podnikkovými procesy a v rámci datové ého po ohledu lze využít v modeely přiřazení atributů (eERM ( diagrram – Extended Entityy – Reelationship M Model), kteréé znázorňujíí vazby mezi datovými objekty, zachyycení agregaace a ggeneralizacee. Metodika ARISS poskytuje řřadu různých M h pohledů na proces a jeeho kontext.. Jediným jejjím prroblematickýým místem je j pojetí udáálostí a stavvů jako jedno oho metaob bjektu (meto oda neerozlišuje výzznamově meezi stavem a událostí).
M Metodika RUP (Ra ational Un nified Process) Metodika RUP M P vznikla jakko důsledně podnikatelssky orientovaaná metodikka vytvořenáá a po oužívaná spo olečností Rattional Softw ware Corporaation. Společčnost ji distrribuuje formou so oftwarového produktu, demo veerze, která byla hlavvním zdrojem použitýým prro charakteriistiku dané metodiky. Veřejně je k dispozici na webovvých stránkáách sp polečnosti (w www.rational.com). Metodika Ration nal Unified Process z velkké části vychází z metodiky Objectory Pro ocess, jejíž první p verzi vytvořil v již v roce 1987 Ivar Jacobso on. M Metodika RUP rozlišuje mezi hlavníími a podpů ůrnými disciplinami. Hlavní discipliiny zaajišťují vlastn ní práci na projektu, podp půrné discipliny slouží k jejich řízení aa koordinaci. ZAPAMATTUJTE SI
Metodika RU M UP je předevvším podniko ová metodikka – metodikka tvorby po odnikových ISS. P tvorbu podnikového Pro p o modelu se využívají prostředky Un nified Modeling Languagge (UML), jedno otlivé podnikkové scénáře jsou znázo orněny pomocí podnikového modellu p případů užití, , jejich realizzaci popisujee podnikový objektový m model. Jazyk UML je využžit p pro objekto ové modelovvání jako unifikovaný u jazyk, pom mocí něhož se modelu ují p požadavky na a systém, ob bjekty třídy, ale i projekto ové procesy. Požadavkyy jsou kritériaa, jejichž splněn ní podmiňujee úspěch pro ojektu. ožadavky jee proto třřeba system maticky evvidovat a odpovídajícíím způsobe em Po do okumentovat a zapracovvávat jejich p případné zm měny. Správu požadavků autor definu uje jako systemattický přístup p ke zjišťování a dokume entaci požad davků na systém a procces zaajišťující sho odu mezi zadavatelem z a dodavatelem v přřípadě změny požadavvků naa systém. V metodice RUP je mimo ořádný důrazz kladen na tvorbu podn nikového mo odelu. Analyytik po odnikových procesů pop píše pomocíí modelů příípadů užití procesy, p kteeré se dotýkkají vyytvářeného ssystému. Jedná se dle Philippe Kruchttena o násleedující činnossti:
46 6
M Metodiky říze ní projektů informačních h systémů v p podnicích Identiffikace hlavníích procesů. Vytvořření seznamu procesů. Vytvořření procesn ní mapy, poso ouzení její úp plnosti. Posou uzení rozsahu u systému řízzení procesů. Návrh na změny, o optimalizace současného o stavu. Optim malizace systéému řízení – vytvoření náávrhu. Raational Unifiied Process používá pro o znázorněn ní architektu ury systému pět pohled dů. Jeednotlivé po ohledy řeší různé aspekty fungováání systému, jsou na ssobě závislé é a do o určité míryy se překrývají. Patří mezi ně následujjící: Lo ogický pohled Zn názorňuje lo ogickou stru ukturu systému z hledisska výsledné funkcionaality. Jedná se o abstraktní model m návrhu, který pop pisuje hlavní moduly, subsystémy a třídy. Hlavním prrostředkem je zde diaggram tříd znázorňující objektové třídy t a vztaahy mezi niimi (asociace, děd dičnost) a objektový diaggram popisujíící vztahy meezi konkrétními instance emi jednotlivých třříd. Im mplementačn ní pohled Zaachycuje systém z pohleedu organizaace statickýcch softwarovvých kompo onent. Hlavn ním prrostředkem ttohoto pohleedu je diagraam kompone ent. Po ohled nasaze ení Deefinuje souvislost processů s hardwarrovou architekturou systtému. Typickkým formáln ním prrostředkem je diagram nasazení v UML v (Arlow w, 2003). Tento T diagraam znázorňu uje jednotlivé hardwarové kom mponenty a jejich propojení. ohled případ dů užití Po Přřípady užití p představují p pohled na syystém z hled diska jeho funkcionality p pro koncové ého užživatele. Ten nto pohled je jádrem architekturyy systému, zbývající po ohledy zajišťťují reealizaci zde specifikovan ných požadaavků. Základ dním prostřeedkem tohoto pohledu je model případů ů užití, který se využívá p pro znázornění struktury požadavků. Prrocesní pohled Teento pohled d zachycuje software jako množin nu navzájem m komuniku ujících proce esů (p proces je chápán jako sou ubor úloh). M Modelování p procesů a jejjich komunikkace se prováádí po omocí processního diagramu. Z hlediska pod dpory modelování projekktových procesů v jazyce UML je doporučeno vyu užít ottevřenosti tohoto stand dardu a využít rozšíření nastaven ných základn ních elemen ntů naa UML Exten nsion for Bussiness Modeeling. Toto procesní p rozššíření bylo zzavedeno Haans Errik Eriksonem m a Magnussem Perkerrem. V proce esní notaci pak p nalezneme následujjící elementy: Projekktový process – množinaa činností navržená takk, aby vytvářela specificcký výstup p pro projekttové uživatelle výstupů. Cíl pro ocesu – vych hází ze samo otné podstaty a je zdůvo odnění vykon návání proce esu samottného. Výstup p ‐ kromě vvlastního pro oduktu nese i informaci o spotřebovvaných zdrojíích processu.
47
Bu usiness modeelování Událost – inicializaační a řídící im mpulsy v pro ocesu. ové prvky no otace UML Extension fo or Business Modeling jssou Záákladní proceesní objekto paatrné v násleedujícím schéématu: cd Model produ ukční a neprodukč ční
Model proje ktů IS v procesním přřístupu
Proj ektov v ý cíl
Info ormace k prod dukčním pro ocesům
Zdroj e produkčníc ch procesů ů
Účasttník - v stup Výstup pro oj ektu
Po ožadav ek na proj ektov e ý produkt
Proj ektov ý prrodukční proces
Účastník - uživ u atel v ýstupů prroj ektu
Obrázek k - Elementy y rozšíření UM ML
Jeednotlivé eleementy této o procesní notace n jazykka UML pakk vytváří m model, který je do ostačující pro o základní dokumentaci projektovýcch procesů. N Navíc kroměě této oficiállně do okumentované verze ro ozšíření je možné vytvvořit rozšířen ní definovan né samotnýými užživateli. V tomto pojettí lze dokon nce vytvořit i pohled příípadů užití, kdy jednotliivé prrojektové prrocesy jsou modeloványy s prvky účastníků (Acttors) na vstu upní i výstup pní straně projekttových procesů. Jeden model m element Actor vyyjadřuje jedeen prvek okkolí prrojektového procesního systému, ktterý se systtémem nějak komunikujje, používá jej k realizaci vlasstních processů. Actor nen ní prvkem syystému a rep prezentuje ko ohokoliv (nebo co okoliv) mimo o systém, kdo k nějak ko omunikuje se s systémem m a je s ním v interakkci. Úččastníka vyh hledáváme hlavně h proto o, abychom mohli vyjm menovat všeechny činnossti, ktteré musí pro ocesy obsahovat. Někdyy je velmi účelné účastnííka uvádět přesně, proto ože jím m nemusí býýt pouze živáá osoba (obssluha, manaažer, ředitel, aj.), ale takké jiné systém my (viděné jako externí sysstémy), datové přípojkky apod. V tomto případě vymeze ení úččastníků ukaazuje, co je předmětem m řešení apliikace a co nikoliv, n tj. cco se považu uje zaa externí prvvek. Mnohd dy se tato hranice práávě u systémů zanedbáává a vznikkají tak nedorozum mění. Základním vizuálním elementem účastníka je „panáčekk“, ale používvají see i jiné symbo oly, jako PC p pro externí systémy apod d. 48 8
M Metodiky říze ní projektů informačních h systémů v p podnicích
M Metodika Prince 2 2 ( Projetss IN a Con ntroled E Environm ment) Metodika PRINCE2 je stru M ukturovanou u metodikou u pro efektivvní řízení pro ojektu. Poprrvé byyla vydánaa v rocee 1989 společností s CCTA (th he Central Compute ers an nd Telecomu unications Aggency) ve Veelké Británii. Metodika P PRINCE navázzala na proje ekt PR ROMPTII (meetody pro řízzení projektů ů vytvořené firmou Simp pact Systemss v roce 1975). M Metodika PRO OMPTII byla přijata spoleečností CCTA A v roce 197 79 jako stand dard pro říze ení vláádních projeektů pro vývvoj informaččních systém mů. PRINCE nahradil PRO OMPTII v ro oce 19 989 včetně řízení vládn ních projektů ů. Dle SIEGEELAUB, M. Jay J metodikka popisuje 45 prrocesů, kteréé určují pop pisy činnostíí na projektu v dané fáázi, a 6 kom mponent, kte eré vyymezují určittou oblast projektového p o řízení. Pro opojení techn nik, kompon nent a proce esů z P PRINCE2 je p patrné na nássledujícím ob brázku:
Obrázek - Techniky, T kom mponenty a procesy p
místění komponent je patrno, p že sp pecifikace řízzení projektu je zaměře ena Z popisu a um naa vztah zákaazník‐dodavaatel a organ nizační struktura se od d této skutečnosti odvvíjí. Ko omponenta organizačníh ho řízení vyymezuje vztahy vedoucíího projektu u, zákazníkaa a osstatních členů projektu. PR RINCE2 rozliššuje dle P. M Matule čtyři p paralelní úrovvně řízení: Sp polečné řízen ní ‐ Corporaate or Prograamme Management Úrroveň strateegického rozhodování. Má na starosti převážžně ředitel podniku ressp. přředstavenstvvo.
49
Bu usiness modeelování Project Přřímé řízení ‐ Directing a P Taato úroveň spadá do kompetencí k vedoucího podniku nebo odděleníí. V souvislo osti s o organizační strukturou jde j o tzv. „Project „ boaard“ složenýý z několika rozhodujícíích záástupců (zákaazník, dodavatel a sponzo or). Prrojektové řízzení ‐ Managging a Projecct Úrroveň veden ní projektu zaastupují man nažeři projektů. Te echnologické é produkční řízení ‐ Man naging Produ uct delivery Úrroveň techn nologického řízení. Řízeení vývoje a a dodávky po p technolo ogické stráncce. Sp práva a zabezzpečení tech hnologií. Prrocesy projektového řízeení tvoří zákklad standard du PRINCE2. Tato meto odika má vellmi prrecizně definované procesy podle základnícch požadavků na deffinici processu. Dlle autorů je m možné zobraazit celkovou u strukturu procesů v nássledujícím schématu:
Obrázek - Struktura S procesů v PRIN NCE 2
Říízení projektu (DP) slouží jako komunikační kanáál s řídící kom misí a vedením organizacce. Prrocesy pláno ování (PL) zassahují do přípravných pro ocesů (SU) aa (IP). Zde se plánuje pou uze ráámcově. Následně pak plánovací p pro ocesy zasahu ují do realizaace projektu u (MP) a (M MS). Plánuje se jaak fáze (stagge) tak i saamotná práce obsaženáá v MP (ob bsahuje pou uze prrovedení úko olu, které jee v PRINCE2 terminologii nazýváno „work „ packaage“). Kontro ola ettapy (CS) tvo oří pomyslnéé jádro meto odiky (obsahu uje nejvíce zzpětných vazzeb s ostatníími prrocesy). Celkkově processy tvoří loggicky uspořádaný celek,, který se ssnáze pocho opí po o proniknutí do jednotlivvých procesů detailněji. PR RINCE2 je deetailním pop pisem navržeených proce esů, kompon nent a techn nik zajišťujícíích ússpěšné řízen ní projektů. Zabývá se však v i problé émy projektové organizační struktury, deefinicí rolí a o odpovědnosstí na projekttu. Je zaměřen na produ ukt a jeho kvalitní dodávkku. M Mezi jeho daalší přednostti patří velm mi detailní popis p a vzorry dokumen ntů, které jssou so oučástí řídícícch procesů p projektu. PRINCE2 podtrh huje, že defin nované procesy mohou b být
50 0
M Metodiky říze ní projektů informačních h systémů v p podnicích měněny, ale zza žádných okolností nem mohou být vyynechány. Sttandard má popsány vellmi úzzké vazby pro ocesů na rolee a jejich odp povědnosti. KONTROLNÍÍ OTÁZKY
Charakterizujte vazby v mezi procesním a projektovvým přístupem v použití meto odik. Jaké procesy obsahuje metod dika PMBOK?? Jaké jsou přednosti metodikyy ARIS? Vymeezte činnostii v metodice RUP. Kteréé jsou úrovněě řízení v meetodice PRINCE2. S SHRNUTÍ KA PITOLY
Čistá metodika vývoje v IS klaade důraz na n obsahovo ou část tvorby IS. Cílem m proceesního přísttupu v řešeení projektů IS není po ouze vytvořření pevnéh ho modeelu a popis stávajícího projektového stavu. Jd de především m o vytvořen ní předpokladu pro kvalitní a effektivní řízení celého proccesu. Meto odika ARIS popisuje p pod dnikovou reaalitu pomocí pěti základn ních pohledů ů: datovvý pohled, procesní pohled, p funkkční pohled d, organizačční pohled a výkonový pohled d. Metodika sstanovuje jed dnotná pravidla pro vytvváření, úpravvu a udrržování procesních modeelů organizacce. Meto odika RUP je předevšším podniko ová metodiika – meto odika tvorb by podn nikových IS. Pro tvorbu u podnikové ého modelu se využívaají prostředkky Unified Modelin ng Language (UML), jednotlivé j p podnikové sscénáře jso ou orněny pom mocí podnikkového modelu případ dů užití, jeejich realizaci znázo popissuje podniko ový objektový model. STTUDIJNÍ LITEERATURA Krruchten, P.: The Rational Unified Process: P An Introduction (2nd Edition), Addissson W Wesley, Toron nto 2003, ISB BN 0‐201‐707 710‐201 Molnár Z.: Mo M oderní metod dy řízení info ormačních syystémů. Grada Publishin ng, Praha 199 92, ISBN 80‐85623 3‐07‐02 M Molnár, Z. : Ef fektivnost infformačních ssystémů. Praaha: Grada, 2 2001. ISBN 80 0‐247‐0087‐5. PM MBOK® 1996 6. A Guide to o the Projecct Management Body of Knowledge [PDF manuáál]. M Materiál PMI ( (www.pmi.org), 1996. Po olák, J., Meru unka, V., Carrda, A.: Uměění systémovvého návrhu. Grada, Praaha 2003, ISBN 80 0‐247‐0424‐0 02 PR RINCE2, 2002 2 Managing succesfull projects with PRINCE2 2 [PDF man nuál]. Londo on: Sttationery offiice 2002. ISB BN 011 330 8 8914
51
Bu usiness modeelování
5 Mode 5. ely užživatelskkých požadav p vků a jejich h nasazzení při ttvorbě IS v pod dniku Ú ÚVOD Urrčení uživatelských požžadavků a tvorba t jejich h modelu přředstavuje sspolupůsobení říd dícího, sociá álního a info ormačního přřístupu za účelem ú vývojje takového informačníh ho syystému, kterýý bude odpo ovídat zamýššleným cílům m. Odvození p požadavků jee nejkritičtějjší čin nností vývoje informačn ního systému u, která je sp pojena s nem malým úsilím m analytiků a užživatelů. Protto je třeba věěnovat této ččinnosti maxximální pozorrnost. CÍÍLE KAPITOLY Y Po o prostudová ání této kapiitoly a vypra acování úkollů budete UM MĚT: Zařadiit zpracován ní uživatelských požadavvků do konttextu podnikání a vývoje inform mačního systému Popsat strukturu u zpracován ní uživatelských požad davků z hleediska vývoje inform mačního systému Popsat požadovan né vlastnosti a strukturu sspecifikace u uživatelských h požadavků Po o prostudová ání této kapiitoly a vypra acování úkollů ZÍSKÁTE: Základ dní přehled p problematikyy zpracování uživatelskýcch požadavků ů Schop pnost vymezit požadavky,, včetně jejicch správného o verbálního popisu Znalossti technik zp pracování mo odelu uživate elských požaadavků Po o prostudová ání této kapiitoly a vypra acování úkollů BUDETE SC CHOPNI: Orienttovat se v základních h souvislosstech a východiscích v h zpracování uživatelských požaadavků Rozlišiit základní typy t uživatelských požadavků. Navrrhnout záklaadní strukturru specifikace uživateelských požadavků Zvolit vhodný přísttup k identifikaci a násled dné správě u uživatelských h požadavků.
52 2
M Modely uživat telských požaadavků a jejich nasazení při tvorbě ISS v podniku
5..1. Process analýzy p požadavku uživatelů na informační systém m p informačního systému je pevně svázána s mírrou pochope ení Úččinnost a pružnost syystémových p potřeb danéého uživatelee, který před dstavuje jak zákazníka (m majitele firm my), tak i koncového uživatelee (pracovníkaa, který dan ný informačn ní systém po oužívá) dané ého v každém výývojovém pro ocesu jakého okoli produkktu informačního systému. Klííčovou roli v hrraje fáze urččení potřeb uživatele, ve v které se snažíme s přeesně porozum mět potřebáám užživatelů s cílem vylepšen ní programového vybave ení a transfo ormujeme tyyto potřeby do fo ormy přesnýcch a jednozn načných požaadavků, kterré jsou následně využity v rámci vývo oje informačního systému uživvatelů. DEFIN NICE
Proces analýzy požadavvků
Činnost, kterrá se zabýváá transformaací potřeb a plánovaných záměrů užživatelů, kteří Č s své požadavk ky vyjadřují většinou v n ne zcela ucellené formě, se nazývá proces analýzzy Smyslem tééto činnosti je tedy přřevedení často nepřesn p požadavků. ně a nejasn ně f formulovaný ých potřeb uživatele do d přesné, úplné a konzistentní specifikacce u uživatelských h požadavků ů v terminologii informaatiky za pou užití psané fformalizovan né s symboliky. V rámci procesu vývoje infformačního ssystému vstu upují do vzájemné interaakce požadavvky vššech účastníkků tohoto procesu. Zp pracování užživatelských požadavků lze z tohoto o pohledu ro ozdělit do dvvou základníích kaategorií, a to dle jejich zaměření na: popis přístupu ke zpracování uživatelských h požadavků ů, který je ob bvykle součáástí širší vývojové v meetodologie informačního o systému (Systems ( Engineering, ITTIL apod.)), popis souboru požžadavků z úzzkého filosoffického nebo o technologicckého hledisska my dopravy, eelektronický obchod apo od.). (rezervační systém Mezi stěžejní problémy v M v oblasti zpracování uživvatelských požadavků paatří pochope ení orrganizační stránky s zko oumaného systému s a vlivu této o stránky n na požadavvky informačního systému. Fo ormulace po ožadavků s cílem c posílení vlastnostíí informačníího syystému v sob bě mezi jiným m zahrnuje 2 intelektuáln ní činnosti, a to: analýzzu potřeb zákkazníka z hleediska jeho cíílů a předpokladů, vymezzení klíčovýcch požadavků ů a popis jejich vlivu na chování systtému v dané ém prostřředí. Uvvedené činno osti jsou uskkutečňovány v sociálním prostředí, ktteré zahrnujee: tvůrcee informačníh ho systému, uživatele‐zákazníkka, který dan ný informačční systém kupuje k a kteerý od nové ého mačního systtému očekáává zejménaa ekonomickký přínos a zjednoduše ení inform řízení organizace, konco ového uživatele, jenž daný informačční systém obsluhuje o a o očekává urččité usnadnění práce.
53
Bu usiness modeelování pracování užživatelských požadavků je interdisciplinárním oborem, kterrý se zaměřu uje Zp naa využití info ormační tech hnologie v ob blasti processu podnikáníí a vliv změn n okolí proce esu po odnikání na tento proces. Tato čin nnost klade důraz na komunikaci m mezi účastnííky výývoje informačního systéému a vede ččasto ke změ ěnám v orgaanizačním usspořádání daané firrmy. Zpraco ování uživateelských požaadavků je proto p tedy pevně p spjato s podporrou stanovených podnikatelsk p kých cílů, kteeré podléhajjí na základěě nastávajícíích změn okkolí syystému zpravvidla nové deefinici. ZAPAMATTUJTE SI
ZZpracování uživatelskýcch požadavků představvuje process transform mace obtížn ně identifikovatelných požad davků uživattele do srozu umitelné form malizované p podoby, kterrá je pochopiteelná všem zúčastněným stranám daného procesu vývoje informačníh ho s systému. Trransformované požadavvky dále sllouží nejen jako záklaadní podklady pro vývvoj informačního systému v rámci celéh ho jeho živo otního cyklu u, ale hlavně jako klíčo ové nality inform mačního systé ému z hlediskka zákazníka a uživatele. krritérium ověřření funkcion Od dvození uživvatelských po ožadavků přředstavuje nejnáročnějšíí část vývojee informačníího syystému. Aplikkování vhodn ného přístup pu na konkré étní problém proto význaamně ušetří jjak zd droje na straně vývoje infformačního systému, takk zdroje v orrganizaci, kdee je informačční syystém implem mentován. davků Úlloha zpracovvání uživatellských požad Přřesné a výsttižné pochop pení potřeb uživatelů ovvlivňuje celýý následujícíí životní cyklus prrojektovanéh ho informaččního systém mu. Dopad nesprávnéh ho pochopeení požadavvků užživatelů můžže mít v lepšším případě za následekk zvýšení celkových náklaadů na údržžbu informačního systému při jeho problémovém zavedení do provozu, p v h horším přípaadě ažž celkové odm mítnutí inforrmačního sysstému potenciálním uživaatelem. Z těcchto důvodů ů je nu utné při vývoji informaččního systém mu přesně po orozumět po otřebám uživatelů v rám mci ceelkového posílení jimi používaného programové ého vybaven ní, a to s dů ůrazem na cíle c ho ospodářské o organizace o od operativn ní až po strattegickou úro oveň. Transfo ormace potřřeb užživatelů do přesných a jednoznačnýých údajů je e tedy rozho odující činno ostí z hledisska náásledujících eetap vývoje iinformačního o systému. Ob becně lze vyycházet při d definici požad davků z mezzinárodního standardu IEEEE ’610, kte erý po ožadavek deffinuje jako: DEFIN NICE
Uživatelský požadavek
Uživatelský požadavek je podmínkka nebo sch U hopnost, ktterou potřebuje uživate el k k řešení pro oblému nebo k dosažeení cíle. V případě informačního systému jd de kterou mussí informačn o o vlastnost, ní systém (případně jeeho část) sp plňovat neb bo v vlastnit, aby byla splněn na smlouva, standard, daaná podmínka nebo jinéé předepsan né d dokumenty. 54 4
M Modely uživat telských požaadavků a jejich nasazení při tvorbě ISS v podniku Daaná definice je dosti obeecná a platí nejen v konttextu s inforrmačním sysstémem. Běžžné po ožadavky úččastníků pro ocesu vývojje informačního systém mu lze rozd dělit do dvvou záákladních oblastí. První oblast o tvoří vývojáři v a distributoři, jeejichž požad davky vycházzejí přředevším z trržních podm mínek. Druhou základní o oblast tvoří u uživatelé, jejiichž požadavvky jso ou na jedné straně dikto ovány vnitřníími potřebam mi hospodářřské organizaace a na straaně drruhé reálným mi možnostm mi dané organ nizace. ují požadavkky ze stranyy vývojářů aa distributorů, Prrojekty, při jejichž realizaci převažu vyykazují zpravvidla jednu neebo více z náásledujících vvlastností: specifikace požaadavků je prezentováána v tržn ní podobě s důraze em na nevvýznamné effekty, vývojááři mají méněě zkušenostíí v dané aplikkační oblasti,, budou ucí zákazník jje obtížně ideentifikovatelný, projekkty většinou u spoléhají na konzultaační pomoc při řešení problémovýých oblasttí, řešeníí problémů často postráádá strukturrovaný přístu up, což následně vyžadu uje přehodnocení exp perty, řešeníí požadavků uživatele je neúplné a m má neformalizzovanou pod dobu. ožadavky uživvatele vykazují jednu ne ebo Naopaak projekty řřešené s důrrazem na po více z následujících h vlastností: požadavky jsou rozsáhlé a vícee formalizovaané, specifikace požadaavků je tvořeena na základ dě technik so oftwarového o inženýrství,, specifikace požadaavků má častto podobu objemné dokumentace, vývojááři získávají hluboké znaalosti v oblassti řešené problematiky,, které mohou i překo onat znalosti personálu u uživatele, řešeníí spoléhá na personál uvn nitř organizaace uživatele, převažžuje strukturrovaný přístu up k řešení. Naa základě výýše uvedenýcch rysů projektů informačních systéémů, kde mů ůže převažovvat vliiv jedné nebo druhé straany základnícch účastníků procesu vývvoje informaččního systém mu, lzee obecně konstatovat, že dobrá kvalita k inforrmačního syystému vych hází předevšším z p požadavků uživatelů. u Trržní požadavvky představvované nároky vývojářů a distributo orů vššak motivují vvývoj inform mačního systéému, ale záro oveň tvoří jeho základní o omezení. Výývoj informaačního systém mu nelze ted dy v užším h hledisku cháp pat pouze jaako navrhováání daatabázových struktur a odpovídajícíích program mových algorritmů, ale p především jaako po ochopení uživatelských potřeb s s ohledem na jejich podnikatelsské strateggie. Taato skutečno ost vyjadřu uje přirozeený vztah uživatelů informačn ního systém mu k iinformačním mu systému jako takovém mu, vzhledem m k procesu p podnikání. Užživatelé info ormačního systému s zdee mají za úkol ú využívaat informacee poskytovaané prrostředím infformačního ssystému v po odnikání. Cíílem informaačního systém mu je poskyttnout informaci potřebno ou k podnikáání.
55
Bu usiness modeelování s ení řídícího, sociálního a Urrčení uživattelských požadavků přředstavuje spolupůsobe informačního přístupu za účelem vývvoje takovéh ho informaččního systém mu, který bu ude dpovídat zam mýšleným cílům. od V rámci stávajjícího masivního rozvojee podnikání v podmínkách tržního p prostředí Česské reepubliky vstu upují uživatellské požadavvky na inform mační systém m do nové kvvalitativní fáze. Po ohybují se nyní za traadiční autom matizací výrrobních a administrativ a vních proce esů op perativní úro ovně směrem k taktické a strategiické úrovni podnikatelské organizacce. Výývoj takovým m způsobem m koncipovvaných inforrmačních syystémů klade vyšší důrraz naa organizační hledisko, jež j v sobě zahrnuje přřání jednotlivvců a organ nizační kultu uru po odnikatelské jednotky. ZAPAMATTUJTE SI
U Uživatelské p požadavky paak kladou dů ůraz na následující činnossti: Zlepššení úrovně řízení (za předpokladu p jasné definice kritérií p podnikání, je ež mají vliv na vývoj v inform mačních sysstémů a přřekračují hrranici pouh hé ocesů). automatizace exiistujících pro Integgrace inform mačního systéému s podnikatelskými přístupy dan né organizacce při procesu odvození a oceňo ování uživate elských požad davků. Modelování imp plementace podnikatelskkých cílů do o struktury informačníh ho systéému s ohledeem na podnikatelskou strrategii. odářské orgaanizace v pro ocesu podnikkání bude v blízké budoucnosti závisset Ússpěch hospo neejen na trad dičních ukazaatelích, jako o jsou kvalitaa, inovace a a rychlá reakkce na změn ny, ale stále více na realizacci schopnossti podnikán ní podpořené informačn ní technologgií. Do osažení hosp podářského úspěchu je tedy t těsně spojeno s s inffrastrukturou organizace e a jejjí informačn ní podporou,, která skuteečně odpovídá objektivn ně hodnocen ným potřebáám orrganizace, ježž jsou formu ulovány uvnittř jejího orgaanizačního ráámce.
5..2.
Zpraccování a přřístupy k u uživatelskýým požadavvkům
Fo ormalizace uživatelských u h požadavků představuje e koncepční činnosti, při nichž vývojář vyyužívá oblast svých znalostí vyplývaajících z popisu podnikkatelské činn nosti spojenou s vvyužitím již existující, alle zatím ne schválené specifikace s p požadavků. P Proces ověře ení platnosti požaadavků před dstavuje porrovnání vývo ojářem již fo ormalizovanýých požadavvků s n neformálním mi požadavkyy uživatele. DEFIN NICE
Zpracování uživatelských požadavků ů
ZZpracování uživatelských u h požadavků ů lze definovvat jako sysstematický p proces vývojje p požadavků, z hlediska jejich upřeednostňován ní, v rámci interaktivně působícícch ž jsou: p procesů, jimi
56 6
M Modely uživat telských požaadavků a jejich nasazení při tvorbě ISS v podniku ‐ ‐
analýýza problému u,
‐ ‐
doku umentace výssledků pozorrování v různ norodé podo obě formátu,
‐ ‐
ověřeení správnossti dosaženéh ho porozumě ění problému.
Taato definice v sobě zahrn nuje sociálníí, presentačn ní i poznávaccí hledisko. K Každé hledissko v ssobě skrýváá určitý rozzsah problém mů, které je j nutné v průběhu p procesu vývo oje po ožadavků překonat. Jedn ná se hlavněě o problém m komunikacce mezi účasstníky processu. Teento proces jje velmi daleek determino ovanosti a je ednoduchosti. Specifikacee požadavků ů je jen zřídka vyttvořena jedn noduchým přímým p posttupem, ale v v naprosté většině je zde z platněn cyklický přístup, který postup pně upřesňujje uživatelskké požadavkyy. up dyž V praxi neexiistuje žádnýý standardní způsob vyttvoření speccifikace požaadavků, i kd litteratura uvád dí vlastnosti,, které by sp pecifikace po ožadavků měěla splňovat (doplnitelno ost, úp plnost, jedno označnost, pochopitelno p ost, modifikovatelnost, konsistence atd.). Mno ohé z u uvedených vlastností v lzee však v praxxi obtížně do osáhnout, prrotože si mo ohou navzáje em od dporovat. Zaatímco většin na dovednosstí potřebnýých k vývoji informačníh ho systému má m teechnický charakter, v ob blasti zjišťováání, stanovení a ověřováání platnosti uživatelskýých po ožadavků je jjich velký nedostatek. An nalýza uživatelských požžadavků mů ůže být cháp pána jako řeešení probléému. Z toho oto po ohledu je an nalýza požadavků processem usuzováání, který se snaží pocho opit požadavvky užživatelů za účelem ú syntéézy, tj. řešení informačn ního systém mu, které usp pokojí potře eby užživatelů. V průběhu toho oto procesu analytik vyu užívá informace a znalossti, které získal z rrozličných zd drojů probléémové oblasti a na záklaadě vlastních h zkušenostíí. Z uvedenýých skkutečností vyyplývá, že znalosti z vývo ojáře vyžadu ují interdisciplinární chaarakter. Procces an nalýzy uživatelských po ožadavků je prvořadým poznáním vlastností požadované ého syystému, kterrý vyžaduje po analytikkovi, aby vyttvořil struktturu a abstrrakci řešené ého prroblému, zpracoval rozm manité inforrmace a vyvvinul logickou, vnitřně sstrukturovanou sp pecifikaci požžadavků. Všechny ostatn ní dovednossti, jako jsou u například interpersonáální interakce neb bo organizáto orské doved dnosti, podporují tento proces pozn nání. Kritickýými zn nalostmi sou uvisejícími s s úspěchem m projektu se na základě zkušeností autora a od dborných zdrojů jeví znalosti z oblasti řešené prob blematiky. Hlavní obtííže paak způsobujee „vrtkavost““ uživatelskýcch požadavkků. Přřístupy k dokkumentován ní uživatelskýých požadavvků pecifikace po ožadavků, ktterou vytvořřili, Věětšina analyttiků je schopna popsat podstatu sp ale neumí už popsat způ ůsob, jakým k této specifikaci dosp pěli. Porovnáním přístupů zkkušených anaalytiků a anaalytiků‐nováččků k činnossti analýzy byyly vysledováány následujjící skkutečnosti. An nalytici použžívají informaace z prostřeedí implemen ntace inform mačního systéému za účele em klaasifikace jed dnotlivých problémů p a jejich uved dení do sou uvislostí s p předcházejícíími zkkušenostmi. Zkušení analytici na počátku p své činnosti seestavují sou ubor navzáje em so ouvisejících otázek, tep prve poté zvažují z alternativy. Větššina těchto otázek závvisí naa předcházejících znalosttech analyzo ovaného pro ostředí a dovednosti vyttvořit analoggie naa jejich záklaadě. Expertn ní analytici mají sklon začínat řešení problém mu vytvořen ním
57
Bu usiness modeelování ormací je ten nto mentálního modelu na absstraktní úrovvni. Na základě později zíískaných info mován v konkrétní model informačního systému. model postupně transform nalytici vyvííjejí hypotézzy v průběhu sběru informací. Zkušení Z analytici využívvají An hyypotetické příklady, aby získali více faktů f o uživatelích. Tyto o hypotetickéé příklady jssou ro ovněž využíváány k objasnění dříve nab bytých inform maci z oblastti řešení prob blematiky. Výývojáři většin nou shrnují informace zaa účelem ově ěření platnossti jejich zjištění. V průběhu scchůzky mezi uživatelem a analytikem m bylo v praaxi vypozoro ováno, že an nalytik prove ede dvvakrát až třikkrát sumarizaaci získaných h informací, kkteré vedou k novému so ouboru otáze ek. Přřed započettím etapy návrhu n info ormačního systému s je specifikace uživatelskýých po ožadavků mnohokrát m p porovnávána a se zjištěn nými změnami problémové oblassti. Sp pecifikace musí být zdoku umentovánaa a následně ohodnocenaa pro ověřen ní její platnossti. Teento opakovaný postup vvytváří poslo oupnost zjišttění, která sttále více upřřesňují vnímáání užživatele o cílo ovém inform mačním systéému. ZAPAMATTUJTE SI
Uživatelský p U požadavek naa zlepšení in nformačního systému staanoví počáteční hypotézu u, k která je čassto neurčitá a vyžadujee následné upřesnění. V V tomto sm myslu analýzza p požadavků už živatelů před dstavuje proces vytvářen ní hypotéz a jjejich násled dné vyvracen ní. H Hypotézy jso ou vytvářenyy a hodnoceny oproti oččekávaným vlastnostem v zamýšlenéh ho informačního o systému. Formulace F p procesu anallýzy požadavvků je zdrojeem informací z zamýšleného o systému. odnikatelské činnosti. Occenění hypottéz Úččastníci analýzy definují soubor charrakteristik po je založeno na n předpoklaadu, že všecchny hypoté ézy jsou pod drobeny possouzení a jssou zkkoumány z hlediska svvé platnosti, tedy z pohledu jisttoty vyvraccení hypotézy. To o znamená, že specifikaace uživatelských požaadavků z hlediska anallýzy problém mu po opisuje objeekty, procesyy, pravidla podnikání atd., a které presentují p soubor tvrze ení, ježž jsou považována za praavdivá, dokud se neprokááže opak. Vsstupem do tohoto t proceesu je zpravvidla obtížně ě definovanýý „seznam p přání“, zatím mco výýstup musí tvořit form malizované specifikace s požadavků, které jsou dostatečnýým zp působem pod drobeny anaalýze dané prroblémové o oblasti a odso ouhlaseny jaak uživateli, ttak výývojáři. Taktto vytvořenáá specifikace by měla být zpracovvána ve třeech základníích sm měrech, a to ve směru po opisu: klíčovýých stránek podnikatelsské činnosti ve formě definice pláánovaných cílů c hospo odářské organizace, vlastností, které má zamýšlený inform mační systém m vykazovaat v prostře edí m uspokoje ení hostiteelského syystému hosspodářské organizace za účelem podnikatelských cíílů. Oblasttí zájmů, které nejvííce ovlivňují přístup odvozování uživatelskýých požadavků, spadajjí do dvou širrokých kateggorií: zdrojeem požadavvků na funkkcionalitu a služby info ormačního ssystému bu ude zamýššlený systém,
58 8
M Modely uživat telských požaadavků a jejich nasazení při tvorbě ISS v podniku požadavky uživateelů budou odvozovány v v organizačním kontextu u hostitelské ého mu hospodářřské organizaace. systém Daané kategorrie vznikly na n základě přístupů p k tvorbě t informačního sysstému pomo ocí tzvv. „hard“ a „„soft“ metod d. Hard meto ody vývoje informačního systému se kkloní k formě ě a teerminologii, která je blízzká informattikům, což vede v k rychlému proved dení těch ettap výývoje inform mačního systému, které následují ettapu analýzyy. Soft meto ody se naop pak svvou formou aa terminologgií snaží o co o nejbližší přřiblížení k užživateli, aby co nejpřesn něji zaachytily požaadavky uživattelů na budo oucí informační systém. Poslední pozznatky spoje ené s vývojem sociálně‐technických systéémů otupují hranice vym mezeného ččlenění meto od, prrotože v so oučasnosti zkoumaná z p problémová oblast sociálně‐technicckých systém mů vyyžaduje vyváážený přístup p použití meetod při resp pektování teechnického i organizačníího po ohledu, což u umožňuje vznik nových technik v oblaasti Requirem ments Engineeringu.
5..3.
Popiss procesu zzískávání u uživatelskýých požadaavků
davků představuje shromáždění vše ech relevantních znalosstí, které jssou Zísskání požad nu utné pro vyytvoření mod delu požadaavků problémové oblasti. Po pochopení povah hy, vlaastností a omezení o pro oblému můžže analytik přistoupit k k formalizacii uživatelskýých po ožadavků, ktterá je vyjádřena specifikkací požadavvků. Následn ně může být přistoupeno o k vaalidaci požaadavků uživatelem, kteerá rozhodu uje o koneečném úspěěchu projekktu informačního systému. Taato etapa klade k vysokéé nároky naa dovednostti analytika vzhledem kke komunikaci s u uživatelem a často naa rychlé získání základních znalosstí z probléémové oblassti. Paaradoxem vššak je skuteččnost, že se dobrý analyttik dokonce může rozsahem získanýých zn nalostí stát v rámci řeššení projekttu expertem m v dané prroblémové o oblasti. Hlavvní prroblémy zprracování užiivatelských požadavků lze v zásad dě definovatt následujíccím zp působem: znalossti nejsou zprravidla ve tvaru, který může být použžit analytikem m, znalossti ze zdrojů informací, které předsttavují lidé „experti“ se získávají velmi obtížn ně. ZAPAMATTUJTE SI
Mezi základn M ní přístupy, ktteré pomáhaají získat a fo ormalizovat p požadavky užživatelů, pattří n následující př řístupy: ‐ ‐
přímá komunikacce s uživateleem,
‐ ‐
tvorb ba scénářů,
‐ ‐
analýýza formulářů,
‐ ‐
analýýza přirozenéého jazyka,
‐ ‐
opakkované využittí požadavků ů.
59
Bu usiness modeelování Přřímá komuniikace s uživaatelem Zísskání požadavků od uživvatelů, kteříí pracují v problémové p oblasti, se jeví jako velice intuitivní v případě těcch uživatelů ů, kteří maají jasnou představu „co vyžadu ují“ od d budoucího informačníh ho systému. V praxi ale aanalytik mussí spolupraco ovat ve většiině přřípadů s uživateli, jež je m možné charakterizovat náásledujícími vlastnostmi:: nemajjí jasnou přředstavu, co o požadují po p zamýšleném informaačním systém mu nebo jjeho části, těžce a nepřesn ně vytvářejí popis pro oblémové oblasti, jejíž problematiiku udoucí inform mační systém m řešit, má bu uživatele používají svůj specifiický slovník, který je rozd dílný od slovvníku analytikka, a tím d dochází k pro oblémům vee vzájemné komunikaci, ‐nemaají stimulaci k používán ní zamýšleného informačního systému, který je pro něě neznámý, aa tím i nejsou u ochotní poskytovat znaalosti analytikovi. ZAPAMATTUJTE SI
K překonání výše uveden K ných problém mů lze využítt některé tecchniky, kteréé zjednodušu ují p převod znalo ostí od uživvatele k hlavnímu tvůrcci informačn ního systém mu. Mezi tytto z základní tech hniky patří: ‐ ‐
rozho ovor typu „o open‐end“,
‐ ‐
strukkturovaný rozhovor.
peciální komunikační dovednosti na straně analytiků, proto ože Tyyto techniky vyžadují sp mají citlivou a delikátní povahu, kteerá může ovvlivnit přístu up uživatele k budoucím mu informačnímu u systému na základě jeeho osobníh ho vztahu k analytikovi. Nepřímý vliv v naa tyto techn niky má mnoho činiteelů, mezi klíčové k náleeží omezenýý čas analýýzy a psychologickké problémy uživatele přři stanovení u uživatelské eexpertizy. Daané dovedno osti zp pravidla analyytik získá až na základě d delší praxe. R Rozhovor typ pu „open ‐ en nd“ K poměrně jed dnoduché teechnice, kterrá si klade zaa cíl zachytitt interakci m mezi uživatele em ovor typu „open‐end“. „ Analytik při této mettodě získáváání a analytikem, patří rozho po ožadavků um možní uživateeli volně a beez přerušování hovořit o jeho práci. D Důraz je klad den naa formálně u uvolněnou attmosféru, vee které tento o rozhovor p probíhá a kteerá má za úkkol ussnadnit tok iinformací od d uživatele kk analytikovi.. Tato technika rozhovorru typu „ope en‐ en nd“ je vhodn ná pro získán ní celkového pohledu naa problémovo ou oblast, vee které má b být zaamýšlený infformační syystém umísttěn a vytipo ování klíčovvých požadaavků uživate elů. Niicméně tato o technika už u není adeekvátní při získávání z deetailní inform mace, proto ože „p přerušování aa připomínán ní“ v průběh hu takového rozhovoru jee většinou neeúplné a nem má strukturu podporující zamýšlené získán ní podrobné informace zz problémovéé oblasti. Sttrukturovanýý rozhovor Metodického přístupu pom M mocí struktu urovaného ro ozhovoru je používáno p pro získání vííce po odrobných in nformací. Taato technika získávání požadavků p veede uživatele k vytipováání problémovéé oblasti. Přři této techn prroblémů z analyzované a nice analytikk řídí rozhovvor uvvedením téématu, uko ončením téématu, dílččími doplňo ovacími dotazy. Účele em strukturovanéého rozhovorru je: 60 0
M Modely uživat telských požaadavků a jejich nasazení při tvorbě ISS v podniku vyplněění existujícícch informačn ních mezer vv problémovéé oblasti, odstraanění překážek při nedosstatku shody mezi uživateeli apod., dosažeení lepší pod dpory pro pro ostředí řešite elů. Sttrukturovanýý rozhovor je j v praxi nutné i někkolikrát opaakovat a velmi zde záleží naa schopnosti řídit komunikaci s uživattelem, aby b bylo dosaženo o výše uvedeených účelů. Tvvorba scénářřů Sccénářem se rrozumí formaa popisu praacovního posstupu. Přístupy této kategorie spoléh hají naa univerzáln nost formy šíření zkušeeností v rám mci dané organizace. o Vlastní scén nář ilu ustruje, jak bude zamýššlený inform mační systém m, který je takto určitým způsobe em vn nímán uživattelem, uspokojovat jeho o potřeby. Scénář S je dů ůležitým násstrojem tvorrby so ociálního názzoru a partiicipace uživaatele na odvození požaadavků, prottože umožňu uje po odrobný pop pis výskytů in nterakce „člo ověk – počítaač“. Sccénář může používat různá r médiaa (texty, ob brázky, diaggramy), kterré mohou být b strukturoványy do dialoggů nebo rozsáhlých po opisů. Existu uje úzká so ouvislost mezi p c informačního syytému, obeccně sccénářem a prototypem. Prototyp naapodobuje chování jako celku, zattímco scénářř předpokládá očekávané é užití inform mačního systéému. ňuje poměrrně snadný způsob získkání expertizzy od uživaatele na velmi Sccénář umožň po odrobné úro ovni. Velmi vhodný je postup, p kdy analytik po oužívá scénááře, které jssou zaaloženy na: obecn ném průběhu u činnosti užiivatele (vyúččtování faktu ury), paraleelním průběh hu činností (vvyúčtování více faktur), neočeekávaném ukkončení činno osti (storno ffaktury). Zááleží tedy naa analytikovii, aby vybral vhodný scénář. Je přittom omezen n časem, kte erý mu může uživvatel věnovvat. Použití scénářů je tedy vhodné k objasn nění spornýých po ožadavků, zeejména však je velice přín nosné pro urrčení vlastno osti uživatelsského rozhraaní. Zaatím neexisttuje lepší zp působ pochopení požad davků na in nterakci, nežž je konkrétní zkkušenost s informačním ssystémem. Teechniky tvorrby scénářů jsou založeeny na princcipu, kdy užživatel snadn něji předá své s zn nalosti analyytikovi v prrůběhu aktivvního tvořen ní popisu své práce see zamýšlenýým informačním ssystémem, n než dotazováním nebo strukturovanýým rozhovoreem. Společně s teechnikou pro ototypování představuje technika tvo orby scénářů ů při použití CASE nástro ojů veelmi slibné řešení ř komu unikace mezi analytikem m a uživateleem, které umožňuje vývvoj ob brazových výýstupů, jež zobrazují z po ožadavky na vlastnosti zamýšleného z o informačníího syystému. nalýza formu ulářů An Naa rozdíl od zatím popsaaných techniik analýza fo ormulářů neepracuje s užživatelem jaako prrvotním zdrrojem inforrmací o prroblémové oblasti. An nalýza form mulářů vychází zee skutečnostii, že formulář tvoří základ dní komunikační médium m ve většině organizací.
61
Bu usiness modeelování DEFIN NICE
Formulář
FFormulář přředstavuje strukturovaaný výběr proměnnýcch, které jjsou vhodn ně f formátovány y za účelem ssběru a vyhleedávání dat. Formulář je vhodný zdro oj informací a p problémové oblasti, prottože: ‐‐ formulář předstaavuje určitý formalizovaaný model, který k je vícee konzistentn ní n než znalosti v vyjádřené po omocí přirozeeného jazykaa, ‐‐ formulář je dato ovým modeelem, který může poskyytnout záklaad pro vývo oj k komponent f funkčního modelu, Fo ormulář před dstavují nejb běžnější vstup p do procesu u tvorby datového E‐R m modelu („enttity ‐ rrelationship““), který obsaahuje následující kompon nenty: entity jako objektyy zájmu v pro oblémové ob blasti, relacee jako význam mné vazby m mezi entitami, atributy jako vlastnosti entit. An nalýza formulářů má zaa úkol zmap povat skryté pojmy ve formulářích f a vytvořit E‐R E model. Obecn ně neexistují jasná pravvidla identifiikace entity,, relace a aatributu. Ten nto needostatek je překonáván použitím: manuáálních meto od odvozeníí a vyhotovvení E‐R mo odelu z forrmuláře, kte eré spoléh hají na posou uzení a zkušeenosti analyttika, autom matizovaného o postupu analýzy přii použití heeuristických pravidel, jak j vycházzejí z obsahu u a konstrukcce formulářů ů. V praxi jsou samozřejmě s žádány automatizované é přístupy analýzy form mulářů, proto ože sn nižují úsilí analytika a poččet jeho omyylů při konstrrukci E‐R modelu. nalýza přirozzeného jazykka An Prro většinu prroblémových h oblastí je n nejobvyklejšíím vyjádřením znalostí p přirozený jazyyk. Po otenciál odvvozování po ožadavků z popisu ve e formě přiirozeného jjazyka vychází zee skutečnostii, že vše, co jje nutné znáát o problém mové oblasti, je už někde napsáno ne ebo vyyjádřeno ve fformě přirozzeného jazykka. Přístupy aanalýzy přiro ozeného jazyyka lze rozdě ělit do o dvou základ dních katego orií, a to na: přímo působící na uživatele za účelem odvvození jeho p požadavků odvozující požadavvky z textů vv přirozeném m jazyce. Prro stanovení požadavků ů daným přřístupem jso ou rozhodujíící slovní záásoba, syntaaxe a neformální atmosféra. Slovní zássoba obsahu ující přibližn ně 1000 výýrazů z daané prroblémové oblasti o je účiinným komu unikačním médiem m při popisu p jakéko oliv představvy. Syyntaxe ve významu jazykkové skladbyy je užitečná vlastnost přřirozeného jazyka, která je běěžná v každodenním živvotě a nevyyžaduje zpraavidla nároky na samosstatnou výukku. Neeformální atmosféra má m za důsleedek, že výýpověď uživatele může být nejasn ná, neepřesná, neeúplná a protichůdná. Je však velmi v užitečná v počáttečních fázíích Reequirementss Engineeringgu, kdy usnaadňuje složitá jednání s s uživateli, n neboť dovolu uje ko omunikaci beez nejistoty zzacházení do o detailu řeše eného probléému.
62 2
M Modely uživat telských požaadavků a jejich nasazení při tvorbě ISS v podniku Au utomatizaci tohoto přísstupu velmi komplikuje e široké bohatství a m mnohoznačno ost přřirozeného jazyka, j která je také stále s neřešitelným problémem v oblasti umě ělé inteligence. Au utomatizovaané přístupy analýzy přiro ozeného jazyyka omezují vstupy do té éto čin nnosti na veelmi malou podmnožinu p u přirozeného jazyka a vytvářejí v model požadavvků jako málo form malizovaný. Manuální přístupy analýzyy přirozenéh M ho jazyka pro o získání uživvatelských p požadavků jssou prružnější než automatizo ované, proto ože spoléhajjí na lidský intelekt. Taakové přístu upy an nalýzy přirozzeného jazykka identifikujjí konstrukto ory (podstatn ná jména, přřídavná jmén na, slo ovesa atd.) m modelu podlee stanovenýcch pravidel. Op pakované po oužití požadavků Přřístup opako ovaného využití požadavvků vychází z z předpoklad du, že požad davky, které již jednou byly v nějaké aplikkaci informačního systém mu odvozenyy, mohou býýt opět použžity p v podobné aplikaci. Samotné odvozeení požadavkků představu v uje přři odvození požadavků neejvíce pracnou část vývoje informačního systém mu, a proto o jakékoliv u ušetření zdro ojů (času, financíí, atd.) můžže přinést velmi v význaamné zvýšen ní produktivvity při vývvoji informačního systému. Obecně O existtuje velký sttupeň podobnosti mezii informačníími syystémy v rámci stejné problémovéé oblasti. Litteratura uváádí, že pouzze 15 proce ent ceelkového po očtu požadavvků uživatellů na zamýššlený inform mační systém m je skuteččně un nikátních, tj. nových. ZAPAMATTUJTE SI
O Opakované v využití požad davků předpo okládá: snadnou dostu upnost uživatelských požadavků předešle odvíjenýcch inforrmačních systémů, stano ovení kritériií výběru „sstarých“ požžadavků, kteeré umožňujjí otestován ní, vhod dnost a úpravvu těchto po ožadavků vzh hledem k zam mýšlenému informačním mu systéému, menšší nákladnosst aplikace tohoto t přístu upu, než je tomu u jednoduchého a rychlého odvozen ní požadavků ů jiným přístupem. Výše uvedené přředpoklady splňují násle edující techn niky opakovaaného využití uživaatelských požžadavků. Jed dná se o: analýýzu problémové oblasti. nalýza problémové oblasti An An nalýza prob blémové oblasti je chaarakterizována jako základní podm mínka analýýzy užživatelských požadavků. Tento přřístup umožžňuje opako ované využžití požadavvků naa základě po odobnosti po ožadovaných h vlastností informačního systému vv rámci stejjné neebo podobn né problémo ové oblasti.. Při této činnosti č jsou identifiko ovány v rám mci prroblémové o oblasti: objektty, pravid dla, omezeení, ktteré jsou ob bvyklé mezi rozdílnými (ale i podobnými) ob blastmi prob blému a kte eré fo ormalizuje do o opakovaně použitelné p podoby.
63
Bu usiness modeelování nalýza problémové oblasti je způsobem odvoze ení požadavkků, který znaačně sníží úsilí An od dvození užživatelských požadavků ů, protože automatizzuje činnossti souvisejjící s u ukládáním, vyhledáváníím a modifiikací požadaavků aplikaccí databázovvých systém mů. Op pakované využití v výsleedků analýzyy podobnýcch problémových oblasstí je běžnou teechnikou, která je závisslá na zkušeenostech an nalytika využžívat nabízeených analoggií. Prroces analýzyy problémovvé oblasti lze rozdělit do n následujících h fází, a to naa: identiffikaci kateggorie probléémové oblassti, tj. přiřaazení dané aplikace k jí podob bným, identiffikaci a forrmalizaci vlastností, ktteré jsou podobné p meezi rozdílnýými aplikacemi v dané problémovéé oblasti, vytvořření knihovn ny opakovan ně použiteln ných požadaavků a jejich h zpřístupně ění ostatn ním projektům. An nalýza problémové oblaasti ve spojení s CASE nástroji mů ůže zásadněě změnit vývvoj informačního systému. Ap plikace tohotto přístupu je však poměěrně nákladn nou záležitosstí, dobných projektů. ktterá se zatím vyplatí ve výývoji rozsáhllých, ale pod KONTROLNÍÍ OTÁZKY
Uveď ďte možné informační zdroje pro získání a identifikaci uživatelskýcch požadavků Uveď ďte možné fo ormy vedení rozhovoru aa jejich vhodn nost použití Jakýcch chyb se dopouštějí při specifikaaci uživatelsských požad davků zkušen ní analyytici a nováčcci? (K čemu m mají sklon?) Charakterizujte základní z oblaasti, které nejvíce n ovlivň ňují přístup k odvozován ní uživaatelských požžadavků. S SHRNUTÍ KA PITOLY
Činno ost, která se zabývá tran nsformací potřeb a pláno ovaných záměrů uživatelů ů, kteří své požadaavky vyjadřujjí většinou v v ne zcela ucelené u form mě, se nazývvá ožadavků. procees analýzy po Uživaatelský požad davek je pod dmínka nebo o schopnost, kterou potřeebuje uživate el k řeššení problém mu nebo k do osažení cíle. V případě in nformačního o systému jd de o vlastnost, ktero ou musí inforrmační systé ém (případněě jeho část) ssplňovat neb bo vlastnit, aby byla splněna smlouva, sttandard, daná podmínkka nebo jin né předepsané doku umenty. Zpraccování uživaatelských po ožadavků lze definovat jako j systematický proce es vývojje požadavkků, z hlediskka jejich upřednostňován ní a v rámci interaktivn ně půso obících proceesů. K překonání výšše uvedenýcch problémů ů lze využít některé techniky, kterré zjedn nodušují přeevod znalosttí od uživattele k hlavnímu tvůrci informačníh ho systéému. 64 4
Záávěr STTUDIJNÍ LITEERATURA WIEGERS, K., EE. Požadavkyy na softwaree. Brno: Com W mputer Press,, a.s., 2008. 4 448s. ISBN 97 78‐80‐251‐18 877‐1 ŠM MÍDA, F. Zaváádění a rozvoj procesního řízení ve fiirmě. Praha: Grada Publishing a.s., 20 007, 293 s. ISSBN 978‐80‐2 247‐1679‐4 HA AMMER, M. – CHAPPY, J. Reengineerring – radikální proměna firmy. 3. vyd dání Praha: Press, 2000. ISBN 80‐726 M Management 61‐028‐7 RO OBSON, M. –– ULLAH, P. P Praktická přírručka podnikkového reenggeneeringu. Praha: M Management Press, 1998. ISBN 80‐859 943‐64‐6 Po olák, J., Meru unka, V., Carrda, A.: Uměn ní systémové ého návrhu. Grada, Prah ha 2003, ISBN N 80 0‐247‐0424‐0 02
Z Závěr Váážený čtenářři. Do opracovali jsste se k samo otnému závěěru a prošli ccelým modulem Businesss modelován ní. Peevně věřím, že získané poznatky p neb budou a nezzůstanou jen n v teoretickéé podobě, ale po omohou Vám m při řešení konkrétních h úkolů a zadání v oblassti podnikovéé informatikky. Žee naleznete ttu správnou cestu ke spráávným postu upům busineess modelováání. Naa této cestě Vám přeji ho odně úspěch hů Au utor
65
Bu usiness modeelování
P Použitá l literatura a další zdroje Řeepa, V.: Procesní řízení a modelováníí. Grada, a.s. Praha 2006 6, ISBN 80‐24 47‐1281‐4 ŘEEPA, V. Podn nikové processy – procesní řízení a mo odelování. Prraha: Grada P Publishing, a.s, 20 006. 265 s. ISSBN 80‐247‐1 1281‐4 FIA ALA, J., MINISTR, J. Průvo odce analýzo ou a modelovváním proceesů. Ostrava: VŠB ‐ Teechnická univverzita Ostraava, 2003. 10 09 s. ISBN 80 0‐248‐0500‐6 6 Po olák, J., Meru unka, V., Carrda, A.: Uměn ní systémové ého návrhu. Grada, Prah ha 2003, ISBN N 80 0‐247‐0424‐0 02 RO OBSON, M. – ULLAH, P. Praktická á příručka podnikového o reengeneeeringu. Prah ha: Press, 1998. ISBN 80‐859 M Management 943‐64‐6 Baasl, J.: Podnikkové informa ační systémyy, Praha: Grad da, 2002, ISB BN 80‐247‐02 214‐2. apability Maturity Mod del® Integra ation (CMM MISM) – Veersion 1.1 – Continuo ous Ca Reepresentation, Technica al Report CMU/SEI‐20 002‐TR‐011, [online], TThe Softwaare En ngineering In nstitute, 2002 2, [cit. 2003‐‐06‐06], URL: .. OBIT 3rd Ed dition – Control Objectivves, [online]], IT Govern nance Institu ute, 2000, [ccit. CO 20 003‐06‐06], U URL: >, ISBN 1‐893 3209‐12‐1. ovotný, O.: SSystém evideence kompon nent IS/IT jakko základ prro měření ná ákladů IS/IT, In: No Syystems Integgration 2002,, Praha : Vyssoká škola ekkonomická, 2 2002, s. 429––436, ISBN 8 80‐ 24 45‐0300‐X. WIEGERS, K., EE. Požadavkyy na softwaree. Brno: Com W mputer Press,, a.s., 2008. 4 448s. ISBN 97 78‐80‐251‐18 877‐1 ŠM MÍDA, F. Zaváádění a rozvoj procesního řízení ve fiirmě. Praha: Grada Publishing a.s., 20 007, 293 s. ISSBN 978‐80‐2 247‐1679‐4 HA AMMER, M. – CHAPPY, J. Reengineerring – radikální proměna firmy. 3. vyd dání Praha: Press, 2000. ISBN 80‐726 M Management 61‐028‐7
66 6
