zaverecna_prace (3)

SLOVENSKÁ TECHNICKÁ UNIVERZITA V BRATISLAVE
Materiálovotechnologická fakulta so sídlom v Trnave
Evidenčné číslo: MTF-30179-6858
Manažment IT zmien a jeho implementácia podľa ISO 20000
Diplomová práca
2015 ............................................................................... Šimon Ivančík

SLOVENSKÁ TECHNICKÁ UNIVERZITA V BRATISLAVE
Materiálovotechnologická fakulta so sídlom v Trnave
Evidenčné číslo: MTF-30179-6858
Manažment IT zmien a jeho implementácia podľa ISO 20000
Diplomová práca
Študijný program: automatizácia a informatizácia procesov v priemysle
Číslo študijného odboru: 2621
Názov študijného odboru: 5.2.14. automatizácia
Školiace pracovisko: Ústav aplikovanej informatiky, automatizácie a mechatroniky
Vedúci záverečnej práce: prof. Ing. Pavol Tanuška, PhD.
Konzultant: Mgr. Juraj Hlavenka
2015 ............................................................................... Šimon Ivančík

Slovenska technicka univerzita v Bratislave Materialovotechnologicka fakulta so sidlom v Tmave
Ustav aplikovanej informatiky, automatizacie a mechatroniky Akademicky rok: 2014/2015
Evidenene 6fslo: MTF-30179-6858
• • • • STU• • • •
• • • • MTF
ZADANIE DIPLOMOVEJ PRACE
Student:
ID gtudenta:
tudijn5r program:
Studijny odbor:
Vedaci prace:
Konzultant:
Miesto vypracovania:
Bc. Simon Ivaneik
6858
automatizacia a informatizacia procesov v priemysle
5.2.14. automatizacia
prof. Ing. Pavol Tanuglca, PhD.
Mgr. Juraj Hlavenka
UIAM MTF STU v Trnave
Nazov prace: Manaiment IT zmien a jeho implementacia podl'a ISO 20000
gpecifikacia zadania:
I. °pate problematiku riadenia IT zmien.
2.Vykonajte analYzu problemovej oblasti, identifikujte slabe miesta riadenia IT slulieb v konkritnej
organizacii.
3.Navrhnite procesny tok, princip dokumentacie zmien a rozdelenie zodpovednosti.
4.Navrhnite smernicu pre implementaciu procesu do produk6neho prostredia riegenej organizacie.
5.Navrhnite procesnY nastroj pre spravu IT zmien a 6iastane ho implementujte.
Riegenie zadania pace od: 20. 02. 2015
Datum odovzdania price: 03. 05. 2015
Bc. Simon IvanZik
student
prof. Ing. Pavol Tanugka, PhD. Dr.h.c. prof. Dr. Ing. Oliver Moraveik
veditci pracoviska garant 'gtudijneho programu

Poďakovanie
Chcel by som využiť možnosť poďakovať prof. Ing. Pavlovi Tanuškovi, PhD.
za metodické a obsahové usmernenie pri tvorbe diplomovej práce. Rovnako vďaka
patrí Mgr. Jurajovi Hlavenkovi za poskytnutie odborných konzultácií. Ďakujem
patrí napokon všetkým mojim blízkym za podporu a pohodu vytvorenú počas
písania tejto práce.

Abstrakt
IVANČÍK, Šimon: Manažment IT zmien a jeho implementácia podľa ISO
20000. [Diplomová práca] - Slovenská technická univerzita v Bratislave.
Materiálovotechnologická fakulta so sídlom v Trnave; Ústav aplikovanej
informatiky, automatizácie a mechatroniky. Vedúci bakalárskej práce: prof. Ing.
Pavol Tanuška, PhD., Trnava: MTF STU, 2015. 73 s.
Cieľom záverečnej práce je analyzovať problematiku procesu Manažmentu zmien
ako jedného z procesov normy ISO 20000, ktorá definuje štandardy pre
poskytovanie IT služieb. Úvodná kapitola je venovaná teoretickým východiskám
a diskusii o význame, rámci a pridanej hodnote daného procesu. Kapitola 2
obsahuje praktickú smernicu pre implementáciu daného procesu, riešia sa otázky
korektnej stratégii plánovania a nasadenia procesu do produkčného prostredia
organizácie. Kapitola 3 je dedikovaná návrhu a čiastočnej implementácii
informačného systému ako nástroja pre podporu riešeného procesu. Záver zhŕňa a
zhodnocuje dosiahnuté výsledky našej práce.
Kľúčové slová:
Manažment IT zmien, ITIL, ISO 20000, Riadenie poskytovania IT služieb,
Informačný systém, PHP, MySQL, AJAX

Abstract
IVANČÍK, Šimon: IT Change management and its implementation in
accordance with ISO 20000. [Master thesis] - Slovak University of Technology in
Bratislava. Faculty of Materials Science and Technology in Trnava; Institute of
Applied Informatics, Automation and Mechatronics. Bachelor thesis supervisor:
prof. Ing. Pavol Tanuška, PhD., MTF STU, 2015. 73 p.
The aim of the thesis is to analyse the issue of Change management process, as one
as defined by ISO 20000 norm, which covers the standards for IT service
management. The introduction part is dedicated to theoretical background and
discussion with respect to scope and added value of the process. Chapter 2 covers
practical guidance for implementation of mentioned process, strategy of correct
planning and deployment of the process to production environment is described.
Chapter 3 is devoted to proposal and partial implementation of information system
as support tool for described process. The conclusion summarizes and evaluates
achieved results of our thesis.
Keywords:
IT Change management, ITIL, ISO 20000, IT Service management, Information
system, PHP, MySQL, AJAX

7
OBSAH
ÚVOD........................................................................................................................ 9
Cieľ práce...............................................................................................................10
Použité pojmy a akronymy.................................................................................... 11
1 TEORETICKÁ ANALÝZA .............................................................................14
1.1 Teoretické východiská.................................................................................14
1.1.1 ITSM - Riadenie IT služieb ......................................................................14
1.1.2 ITIL a ISO 20000.....................................................................................14
1.2 Formulovaná hypotéza................................................................................16
1.3 Význam a zámer procesu Riadenia zmien .................................................. 17
1.4 Rámec ..........................................................................................................18
1.5 Pridaná hodnota pre manažment a chod spoločnosti ................................19
1.6 Žiadosť o zmenu (RFC), rozdelenie typov žiadostí.................................... 20
1.7 Štruktúra procesného toku Riadenia zmien .............................................. 24
1.8 Zhrnutie kapitoly........................................................................................ 30
2 NÁVRH IMPLEMENTÁCIE PROCESU DO PRODUKCIE....................31
2.1 Identifikácia problémových faktorov..........................................................31
2.2 Prerekvizity implementácie.........................................................................33
2.3 Plánovanie ...................................................................................................33
2.3.1 Definícia požiadaviek .......................................................................... 34
2.3.2 Definícia procesu..................................................................................35
2.3.3 Dokumentácia RFC...............................................................................37
2.3.4 Posúdenie risku, autorizácia, schválenie ............................................ 38
2.3.5 Plán implementácie............................................................................. 39
2.4 Implementácia............................................................................................ 40
2.4.1 Výber procesného nástroja - informačného systému ......................... 40

8
2.4.2 Migrácia a konsolidácia dát................................................................. 42
2.4.3 “Oživenie procesu”............................................................................... 43
2.4.4 Beh pilotnej fázy a prechod z pilotu do produkcie.............................. 44
2.5 Zhrnutie kapitoly.........................................................................................45
3 NÁVRH A IMPLEMENTÁCIA PROCESNÉHO NÁSTROJA -
INFORMAČNÉHO SYSTÉMU........................................................................... 46
3.1 Analýza problémovej oblasti...................................................................... 46
3.2 Funkčná analýza..........................................................................................47
3.2.1 Katalóg používateľských požiadaviek ..................................................47
3.2.2 Nájdenie účastníkov a prípadov použitia............................................ 50
3.2.3 Behaviorálne a štruktúrne diagramy UML .........................................51
3.3 Dátová analýza ............................................................................................57
3.3.1 Definovanie entít, ich množín, atribútov a identifikácia relačných
vzťahov, entitno-relačný diagram......................................................................57
3.3.2 Fyzický model databázy........................................................................59
3.4 Implementácia.............................................................................................59
3.4.1 Použité technológie a metodika .......................................................... 60
3.4.2 Architektúra aplikácie ..........................................................................61
3.5 Dokumentácia ............................................................................................ 63
3.6 Testovanie systému .....................................................................................67
3.7 Zhrnutie kapitoly........................................................................................ 68
ZÁVER .................................................................................................................... 69
ZOZNAM BIBLIOGRAFICKÝCH ODKAZOV................................................. 71
ZOZNAM PRÍLOH................................................................................................72

9
ÚVOD
Ako jedno veľmi prepoužívané klišé vraví: “Svet je v pohybe.” Pohyb je z
fyzikálneho hľadiska definovaný ako zmena polohy vzhľadom na čas. Tým sme
definovali kľúčovú tému záverečnej práce - zmeny. Zmeny, samozrejme týkajúce sa
informačných technológií, budeme analyzovať, procesne skúmať, pojednávať o ich
štandardizovaní a najmä navrhovať ich riadenie.
Predmetom záverečnej práce je navrhnúť a implementovať proces Riadenia
zmien informačných technológií do produkčného prostredia stredne veľkej
spoločnosti.
Ako teoretické východisko použijeme dokumentáciu ITIL a smernice ISO
20000, ktoré definujú štandardy poskytovania IT služieb. V praktickej časti
rozoberieme nasadenie samotného procesu do produkcie, následne navrhneme
adekvátny nástroj k správe Riadenia zmien. Záverom posúdime návratnosť,
benefity.
Zmeny sú v priemysle alebo v odvetví služieb efektom prispôsobenia sa
trhu, odpoveďou na dopyt zákazníka, alebo výsledkom vývoja či zlepšenia - keďže
sú tieto faktory v nikdy nekončiacom kolobehu, výrobný a obchodný trh je v
princípe v jednej veľkej kontinuálnej zmene.
S výnimkou ručných dielní je každá, či už menšia alebo väčšia manufaktúra
naviazaná na automatizáciu a momentálne už aj informatizáciu. Okrem výroby
spomenieme samozrejme aj organizácie poskytujúce službu ako tovar, kde je
závislosť na informačných technológiách fundamentálna. Od osobného počítača na
vrátnici, cez CNC a PLC vo výrobe, operátorský panel velína až po smartfón
riaditeľa firmy, všade nachádzame IT službu.
Štúdiá aj prax ukazujú, že práve zmena je pre chod IT služby najväčším
rizikom a zároveň najčastejšou príčinou výpadku IT služby - prirodzene ide o
zmeny zle plánované, implementované alebo odkomunikované. Nie je asi potrebné
opisovať vplyv výpadku služby na chod spoločnosti - výroba alebo poskytovaná

10
služba stojí, strácajú sa nemalé prostriedky, ako časové, tak aj finančné, prípadne
ide o stratu klienta. Nehovoriac o výpadkoch kritických služieb, kde môže ísť o
škody nielen na majetku ale priamo na živote. Týmto smerujeme k poukázaniu na
nutnosť mať tieto zmeny “pod kontrolou”.
Dôležitosť riadenia zmien bola uznaná už na prelome 19. a 20. storočia ako
echo na rapídny rozvoj industrializácie. Medzi prvých priekopníkov patril
Frederick W. Taylor, ktorý riadenie zmien spomínal v publikácii “The Principles of
Scientific Management” z roku 1911. Do podoby ako poznáme proces dnes ho
priniesli IT korporáty ako IBM a Microsoft počas 90-tych rokov. Dnes je Riadenie
zmien, alebo anglicky tiež “Change management” uznávanou súčasťou, alebo skôr
nutnosťou pri poskytovaní akejkoľvek IT služby.
Ako praktický príklad sa v záverečnej práci zameriame na rámcové riešenie
stredne veľkej firmy s komplexnou infraštruktúrou, avšak organizačne a procesne
neusporiadaným riadením. Bude potrebné navrhnúť proces riadenia zmien vhodný
do konkrétnej organizácie, definovať role, nájsť vlastníkov zodpovedných za
jednotlivé služby, skonsolidovať zdroje, naplánovať implementáciu procesu,
vyriešiť jeho kontinualitu a “vychytať” prípadné nedostatky.
Na záver navrhneme nástroj pre procesnú správu žiadostí o zmenu,
zameriame sa na jeho zarovnanie podľa teoretického východiska, preskúmame
„front-endovú a back-endovú“ časť aplikácie, teda dizajn formulárov, aplikačnú a
dátovú časť, následne nástroj čiastočne implementujeme a navrhneme formu
adekvátneho testovania.
Cieľ práce
Pre uvedenie do problematiky by sme radi demonštrovali praktický príklad
významu Riadenia zmien na šablónovej spoločnosti zaoberajúcou sa vývojom
priemyselného softvéru. Nevyhnutnou súčasťou existencie firmy je pripojenie do
internetu – komunikácia s klientmi, diaľková správa poskytovaného softvéru,
samotný vývoj softvéru – všetko závislé od tejto služby. Sieťový administrátor

11
počas kontroly logov zistí, že na porte 5938 boli vykonané pokusy o sieťový útok,
preto port obojsmerne uzavrie. Nevie však, že oddelenie klientskej podpory
používa komerčný softvér pre vzdialené pripojenie na plochu, ktorý využíva práve
spomínaný sieťový port. Vzniká incident, trvá hodiny, kým sa dopátra ku koreňovej
príčine problému a vykoná jej odstránenie, klientský servis je narušený, narastá
nespokojnosť na oboch stranách, mrhá sa ako časovými, tak finančnými
prostriedkami.
Všetkému sa dá samozrejme predísť zavedením poriadku formou
procesného riadenia zmien. Proces obdobné situácie vylučuje, nakoľko nastolí
jasné pravidlá, ako budú infraštruktuálne zmeny alebo zmeny IT služieb riešené.
Neautorizované zmeny sú neprípustné, návrhy zmien musia byť adekvátne
testované a IT personál ako aj používatelia služby musia byť o zmenách riadne
informovaní.
Cieľom záverečnej práce je popísať funkčný aspekt procesu Riadenia zmien,
prediskutovať teoretické východiská, vydefinovať pojmy spojené s procesom,
navrhnúť praktické zavedenie procesu do operatívy spoločnosti, od plánovania až
po vyhodnotenie a v rámci praktickej časti navrhnúť informačný systém ako
procesný nástroj, informačný systém, pre technické zázemie zavedeného procesu.
Použité pojmy a akronymy
Širším úvodom by sme radi upresnili pojmy, ktoré budú v práci opakovane
používané, preto je ich pochopenie pre čitateľa dôležité.
IT Služba, angl. IT Service
● poskytovanie alebo podpora informačných technológií, ktorých
konzumentom je priamo alebo nepriamo používateľ,
● príkladom môže byť poskytovanie a správa multifunkčných zariadení -
tlačenie, kopírovanie, administrácie autentifikácie a pod.

12
Poskytovateľ služby, Service Provider
● interná (vnútrofiremná) alebo externá (dodávateľ, angl. “outsorcing”)
organizácia poskytujúca IT službu,
● napríklad poskytovateľ služby pripojenia na internet.
ITSM
● z anglického IT Service Management, a síce Riadenie IT Služieb, teda
procesne založená metodológia poskytovania IT služieb
IT Organizácia
● spojenie IT personálu, IT manažmentu - teda organizačný celok, ktorý
operuje v definovanej hierarchii a v definovaných procesoch, ktorého zámer
je poskytovanie IT služieb s cieľom spĺňať potreby a požiadavky klienta
Biznis
● týmto pojmom budeme označovať klienta, odberateľa služieb chápaného
znova ako organizáciu,
● rozhoduje o rámci poskytovania služieb, definuje level poskytovania služieb,
teda principiálne objednávateľ služieb,
● všeobecne možno rozdeliť ako internú klientelu (vedenie firmy, spoločnosti)
alebo externú klientelu (zákazníci).
Zainteresovaná strana, angl. Stakeholder
● osoba, manažment alebo skupina v rámci ale aj mimo rámca organizácie,
ktorá je ovplyvnená v rámci riešenej problematiky a ktorá disponuje
rozhodujúcim právom nad touto problematikou.
Sponzor
● osoba, manažment alebo skupina, v rámci ale aj mimo rámca organizácie,
ktorá disponuje právom alokovať finančné, respektíve iné rozpočtové
zdroje.

13
CMDB
● z anglického Configuration Management DataBase - ako názov hovorí, je to
databáza všetkých konfiguračných jednotiek v rámci IT organizácie -
fyzických aj virtuálnych, spolu s definovanými vzťahmi, ktoré existujú medzi
týmito jednotkami. Za konfiguračnú jednotku môžeme považovať napríklad
server, sieť, dodávateľa, zákazníka, databázu, serverovňu, procedúru,
dokumentáciu, počítač - v princípe všetko čo s každodennou IT agendou
súvisí.

14
1 TEORETICKÁ ANALÝZA
Kapitola je venovaná teoretickému pozadiu riešeného procesu a bude slúžiť
ako základná platforma pre kapitoly venujúce sa propozícii návrhov pre konkrétne
riešenia.
1.1 Teoretické východiská
V nasledujúcej podkapitole objasníme zaradenie analyzovanej problematiky
do globálnejšieho okruhu a predstavíme všeobecne platnú metodiku, respektíve
štandardy, ktoré použijeme ako teoretické východiská pre záverečnú prácu.
1.1.1 ITSM - Riadenie IT služieb
Je potrebné spomenúť v úvode, že riešený proces (Riadenie zmien) je len
čiastková doména, ktorá patrí pod diametrálne rozsiahlejšiu problematiku a tou je
Riadenie IT služieb (ITSM). Riadenie zmien je podľa definície ISO/IEC (2011)
procesne zameraný prístup, ktorý rieši usmernenie dodávania IT služieb, ktoré sú v
súlade s potrebami organizácie, ktorá tieto služby používa.
V praxi povedané a jednoducho vysvetlené - ITSM je metodika, ktorá sa
snaží o súlad toho, čo IT poskytuje a čo firma naozaj potrebuje.
1.1.2 ITIL a ISO 20000
ITIL - z anglického Information Technology Infrastructure Library, voľne
preložené ako Infraštruktuálna Knižnica Informačných Technológií je komplexný
súhrn najlepších praktík, konceptov a postupov poskytovania IT služieb
pozorovaných a zaznamenaných na báze praxi komerčných a vládnych IT odvetví.
Prioritne ide o procesne orientovanú metodológiu riadenia IT služieb. Obecne
povedané - ITIL pomáha organizáciám zaviesť poriadok, skonsolidovať zdroje IT a
pomáha predísť štandardne prekonávaným chybám v rámci poskytovania IT
služieb. Momentálne, vo verzii 3, je ITIL rozčlenený do piatich okruhov:

15
● Stratégia služby,
● Návrh služby,
● Prechod služby,
● Operácia služby,
● Kontinuálne zlepšovanie služby.
Obrázok 1, Riadenie zmien a jeho zaradenie v ITIL
podľa Office of government commerce (2007, s. 11)
ITIL a jeho základné aspekty:
● procesne zamerané riadenie - definuje procedúry, role, kompetencie a
zodpovednosti;
● zákaznícky orientovaný prístup - priradená hodnota ITILu je zameraná v
prospech klienta;
● jednoznačná terminológia - zjednocuje niekedy nezrozumiteľnú IT
idiomatiku;
● nezávislosť na platforme - nezávislosť na IT odvetví, mierke organizácie
alebo zákazníkovi, možno použiť aj mimo IT;
● “Public Domain” - voľne (aj komerčne) použiteľné.

16
ITIL poslúži v kontexte tejto práce ako teoretické východisko, ktorého obsah
budeme považovať za axiomatický a všeobecne platný.
ISO/IEC 20000 - Ako už názov napovedá, ide o medzinárodne uznaný
štandard a certifikácia, konkrétne štandard poskytovania a riadenia IT služieb. ISO
20000 vychádza a čiastočne rozširuje ITIL praktiky - aj keď nemožno rozprávať o
totožnom obsahu, ITIL je najvhodnejší základ pre dosiahnutie ISO 20000
certifikácie. Pre ilustráciu - na Slovensku momentálne (2014) existuje len deväť
subjektov, ktoré spĺňajú podmienky a sú certifikované pre ISO 20000, verzia 2011.
1.2 Formulovaná hypotéza
Nakoľko v momentálnom stave nie sú dostupné údaje o dostupnosti služieb
a ich kvalite, nemá zmysel porovnávať súčasný stav so stavom po implementácii
procesu. Preto je dôležité ešte pred samotným návrhom riešenia objektívne
zachytiť situáciu v organizácii, teda zvoliť vhodné KPI, z angl. Key Performance
Indicator, kľúčový indikátor výkonu.
V našom prípade môžeme zvoliť dostupnosť služieb, ktorá je definovaná
vzťahom:
To principiálne znamená, že skúmame ako často organizácia čelí
incidentom, teda výpadkom služieb. Štatistiku pozorovania je nutné viesť
adekvátny čas pre objektívne vyhodnotenie.
Našou hypotézou tvrdíme nasledovné - po úspešnej implementácii procesu
riadenia zmien do produkčného prostredia organizácie, pri dodržiavaní
dohodnutých politík, procedúr a pravidelných auditoch by sa mala dostupnosť
poskytovaných IT služieb vo všeobecnosti zvýšiť.

17
1.3 Význam a zámer procesu Riadenia zmien
Existuje mnoho dôvodov príčin prečo daný proces zaviesť, rozdeľme ich
štruktúrne: proaktívne a reaktívne.
● Proaktívne vyhľadávať možnosti zefektívnenia danej služby, teda znižovať
náklady za službu, optimalizovať jej chod, znižovať komplexnosť služby a
tým zvyšovať jednoduchosť pre jej správu a podporu. Zároveň predvídať
možné problémy pri iných zmenách.
● Reaktívne, znamenajúc riešenie už vniknutých incidentov, alebo adaptácia
na zmenu prostredia, či už technického, legislatívneho, environmentálneho.
V ideálnom prostredí by mal prirodzene prevládať proaktívny typ Riadenia zmien
(“odchytiť” všetky potencionálne problémy ešte pred ich vznikom), avšak prax
ukazuje iné čísla. Štatistická krivka, ktorá by zobrazovala pokles reaktívnych zmien
a nárast proaktívnych zmien v čase, by svedčila o úspešnej implementácii procesu.
Základnými aspektmi úspešného Riadenia zmien by mali byť:
● optimalizácia risku spojeného so zmenami,
● zníženie potencionálneho dopadu pri neúspešnej implementácii,
● snaha o “byť úspešní na prvý krát”.
Vzhľadom na zámer, cieľ a výsledok zavedenia riešeného procesu, môžeme
definovať nasledovné:
● štandardizovať metódy a procedúry, ako dané zmeny procesne riešiť - to
znamená navrhnúť formu spracovania zmien, nástroj pre správu, úložisko,
definovať role procesného riadenia, etc..,
● zaistiť adekvátnu dokumentáciu zmien, a to nielen záznamov zmien ako
takých ale taktiež ich prelinkovanie s konfiguračnou databázou (CMDB),
viac v kapitole 1.6, Žiadosť o zmenu (RFC), rozdelenie typov žiadostí,

18
● poskytnúť promptnú odpoveď na požiadavky meniaceho sa trhu alebo
rozhodnutia manažmentu, to jest zaručiť rýchlu adaptáciu IT služieb či
infraštruktúry,
● ako už bolo spomínané, zaistiť čo najmenší potencionálny risk pri zmene.
1.4 Rámec
Ak by sme chceli vysloviť konkrétnu definíciu, hovoriacu o tom, čo je to
zmena v rámci procesu Riadenia IT zmien, narazíme na množstvo variácií -
zhrňme a zjednodušme ich teda v jednu, všeobecne platnú:
Podľa definície Office of Government Commerce (2007, s. 43), (IT) zmena je
pridanie, modifikácia alebo odstránenie autorizovanej, plánovanej alebo už
podporovanej IT služby, či pridružených softvérových alebo hardvérových
komponentov.
Pri implementácii procesu je tiež dôležité uviesť na správne hranice, čo je mimo
rámca problematiky, pre ilustráciu uvádzame:
● signifikantné zmeny presahujúce rámec manažmentu riadenia IT služieb,
t.j. organizačné zmeny, zmeny predpisov a smerníc, zmeny obchodných
činností organizácie,
● zmeny týkajúce sa veľmi nízkeho levelu operácií, alebo činnosti
každodenných rutínych aktivít, napríklad výmena toneru, zmena emailovej
distribučnej činnosti a podobne.
Iným ohraničujúcim faktorom, ktorý uzatvára rámec zmien v horizontálnom
smere je pojem Portfólio služieb. Portfólio služieb je, ako názov napovedá, list IT
služieb ktoré daný poskytovateľ služby rieši. V praxi to znamená - Tím
zabezpečujúci technickú prevádzku firemného intranetu (nazvime ho Intranet tím)
ponúka nasledovné služby: inštalácia riešenia, administrácia prístupov, upgrade
softvéru, riešenie technických problémov - spravovanie obsahu samotných stránok
je úlohou marketingového oddelenia a teda je mimo rámca poskytovania služieb
Intranet tímu a zároveň implicitne mimo rámca Riadenia zmien tejto služby.
Jednoduchý graf vytvorí celistvý obraz.

19
Obrázok 2, Rámec procesu Riadenia zmien
1.5 Pridaná hodnota pre manažment a chod spoločnosti
Spoľahlivosť chodu IT služieb a zaistenie ich prevádzky v každej situácii je
pre dnešné firmy kritické. Zmeny týkajúce sa služieb alebo infraštruktúry IT môžu
vo veľkej miere narušiť obchodné činnosti. V prípade neúspešných, alebo zle
zmanažovaných zmien rozprávame o skutočne nepríjemných konsekvenciách -
strata klientskych dát, nefunkčnosť služby poskytovanej externe, nedoručené
emaily obsahujúce dôležité informácie a podobne.
Riadenie zmien má slúžiť ako prevencia pred spomínaným a teda pridaná
hodnota pre samotný chod spoločnosti môže byť identifikovaná nasledovne:
● lepšie zarovnanie služieb pre potreby chodu spoločnosti,
● zvýšená viditeľnosť a zlepšená komunikácia zmien pre obe strany – biznis aj
IT podporný tím služby,
● znížený výskyt rizík spojených s dopadmi zmien,
● zlepšené posúdenie nákladov spojenými so zmenami, čo prináša presnejší
finančný reporting,

20
● minimalizácia neúspešných zmien a výpadkov služby, s tým spojená vyššia
efektivita zamestnancov a zlepšenie poskytovaných klientskych služieb
alebo produktivity,
● vyššia prispôsobivosť spoločnosti k dynamickému chodu skrz lepšiu
adaptabilitu a absorbčnosť,
● zlepšené povedomie IT organizácii voči manažmentu a tým lepšie
intrafiremné vzťahy a komunikácia.
Pravdepodobne najzásadnejším faktorom pri posudzovaní úspešnosti chodu
akejkoľvek divízie prevádzky – nielen IT – sú financie. Pri oddeleniach, ktoré sa
svojou činnosťou nepodieľajú na ziskoch, ale sú skôr spotrebiteľmi, sú financie
vyčíslené inými spôsobmi, pri IT je to jednoznačné – úspešnosť chodu služieb. Na
základe funkčnosti alebo aj nefunkčnosti služieb sú často prepočítavané
potencionálne straty na zisku v prevádzke. Preto optimalizácia, respektíve
minimalizácia akýchkoľvek výpadkov, či degradácií služby sú principiálne kľúčové.
Ak by sme chceli vyzdvihnúť znaky naozaj neúspešného vedenia procesu Riadenia
zmien, narazili by sme najmä na:
● vysoké číslo núdzových zmien,
● neautorizované zmeny,
● signifikantný počet neúspešných zmien,
● oneskorené zavádzanie zmien, a podobne.
Z pohľadu vedenia firmy sú tieto body prirodzene neakceptovateľné, pretože
všetko spomenuté má priamy dopad na prevádzku spoločnosti.
1.6 Žiadosť o zmenu (RFC), rozdelenie typov žiadostí
Základným kameňom celého procesu Manažmentu zmien je Žiadosť o
zmenu, taktiež anglicky Request for change, skrátene budeme používať RFC. RFC
je v princípe návrh pre zmenu IT služby, jej časti alebo infraštruktuálneho
komponentu, či jeho hardvérovej alebo softvérovej časti. Dôvody pre zmenu môžu
byť rozličného charakteru – zlepšenie služby, „upgrade“ softvéru, výmena
hardvéru, vypnutie servera, alebo aj migrácia dát z dôvodu zmeny legislatívy.

21
RFC žiadosti sú vytvárané a sprocesovávané štandardne v nástrojoch
špeciálne určených pre tento význam. V princípe ide o nenáročnú, avšak flexibilne
upraviteľnú aplikáciu umožňujúcu správu dokumentov (formulárov) a ich
procesné riadenie. Obdobný nástroj, jeho návrh a čiastočnú implementáciu
budeme riešiť v kapitole 3, Návrh a implementácia procesného nástroja. Takýto
systém je nevyhnutnou súčasťou implementácie Riadenia zmien.
V nasledovnej tabuľke priblížime atribúty, ktoré by mal formulár RFC povinne
obsahovať, Office of government commerce (2007, s. 47):
Názov atribútu Popis Typ položky
formulára
Povinný
atribút
(pri novom RFC)
Unikátny
identifikátor
Automaticky
generované
x
Kontaktná
osoba
Najčastejšie pôvodný žiadateľ
zmeny
Meno osoby x
Status zmeny Opisuje momentálny stav
zmeny, statusy sa definujú na
základe dohodnutého
procesu, viac v kapitole 1.7,
Štruktúra procesného toku
riadenia zmien
Výber z predom
definovaných
x
Opis zmeny Otvorený text x
Kategória
zmeny
Rozdeľuje podľa rozsahu a
dopadu zmeny – atribút,
ktorý nie je vypĺňaný
žiadateľom, posudzovaný
vedením procesu – bližšie
popísané v kapitole 1.7,

22
Štruktúra procesného toku
riadenia zmien
Dopad zmeny Akú veľkú časť používateľov
alebo produkcie zmena
ovplyvňuje
Výber z predom
definovaných
x
Plán
implementácie
zmeny
Opisuje logickú postupnosť
krokov vykonaných pri
implementácii zmeny
Otvorený text
Záznam zmeny Takzvaný „log“,
inkrementálny záznam
obsahujúci historický postup
riešenej zmeny
Otvorený text
Dôvod zmeny Opisuje podstatu žiadosti a
zároveň rieši možné riziká pri
neimplementovaní zmeny
Výber z predom
definovaných,
možný aj otvorený
text
x
Urgentnosť
zmeny
Principiálne rozdelená na
núdzové zmeny (riešenie
vzniknutého incidentu) a
plánované zmeny
Výber z predom
definovaných
x
Popis rizika
zmeny
Objektívne zhodnotenie rizík
pri neúspešnej implementácii
Otvorený text x
Pravdepodobno
sť výskytu rizika
Výber z predom
definovaných
x
Pridružené
prvky
Naväzbené prvky, ktoré budú
ovplyvnené pri riešenej
zmeny – ide napríklad o
služby, hardvérové
komponenty, aplikácie
Výber z predom
definovaných

23
a podobe – CI prvky CMDB
databázy
Načasovanie
zmeny
Časový údaj
Zainteresované
strany
V princípe ide o správcov
pridružených prvkov, ktorí
budú posudzovať zmenu a
rozhodovať o jej schválení,
prípadne neschválení
Mená osôb,
správcov služieb
Reverzný plán Je použitý v prípade
neúspešnej implementácii
zmeny
Otvorený text
Tabuľka 1, Atribúty RFC
RFCs je možné rozdeliť a členiť do rôznych kategórií na základe uvedených
atribútov, my sa zameriame na dva najdôležitejšie, a síce priorita a riziko, resp.
dopad zmeny, Office of government commerce (2007, s. 54-55):
Riziko/Pravdepodobnosť/Dopad:
Dopad zmeny
Vysoký dopad
Nízka pravdepodobnosť
Kategória rizika: 2, vysoké
Vysoký dopad
Vysoká pravdepodobnosť
Kategória rizika: 1, najvyššie
Nízky dopad
Nízka pravdepodobnosť
Kategória rizika: 4, najnižšie
Nízky dopad
Vysoká pravdepodobnosť
Kategória rizika: 3, nízke
Tabuľka 2, Matica - Riziko, pravdepodobnosť, dopad zmien

24
Priorita:
Priorita Korektívna zmena Zlepšovacia zmena
Ihneď (Núdzová zmena) Ohrozuje životaschopnosť
celej služby;
Možná príčina straty
rozsiahleho zisku;
Okamžitý zásah je nutný
-
Vysoká Ovplyvňujúca kľúčových
zákazníkov, alebo vo
všeobecnosti väčšie
množstvo používateľov
Nútená zmena na základe
legislatívnych zmien;
Podporuje signifikantný
obchodný zámer
Priemerná Bez rozsiahlejšieho
dopadu ale nemožno
čakať na plánované
vypustenie zmien
Podporuje plánovaný
obchodný zámer
Nízka Zmena je potrebná, ale vie
byť zakomponovaná do
plánovaného balíku zmien
Zlepšuje funkčnosť,
kvalitu, alebo dostupnosť
služby
Tabuľka 3, Rozdelenie zmien podľa priority
1.7 Štruktúra procesného toku Riadenia zmien
Nosnou časťou Manažmentu zmien je samozrejme proces ako taký, teda
forma procesného toku. Procesné riadenie je fundamentálnym základom
úspešného poskytovania a riadenia IT služieb, preto je definícia procesu, jeho
samotných krokov - aktivít, nadväzností a hlavne rolí najdôležitejším bodom
zavádzania a operatívy procesu Riadenia zmien.
Začíname diagramom, následne určíme role a ich zodpovednosti, napokon
širšie opíšeme separátne body procesu.
Na základe Office of government commerce (2007, s. 49):

25
Obrázok 3, Procesný tok Riadenia zmien,
na základe Office of government commerce (2007, s. 49)

26
Žiadateľ
Osoba z organizácie IT, ktorá identifikovala potrebu pre zmenu. Žiadateľ nemusí
byť a často ani nie je dotyčný, ktorý zmenu vykoná, avšak je ten, ktorý musí vyplniť
minimálne povinné položky RFC – najčastejšie dôvod zmeny, urgentnosť a
podobne.
Manažér zmien
Alebo anglicky „Change manager“ je vlastníkom procesu a kľúčovou osobou pri
každom RFC. Manažér zmien je zodpovedný za vedenie zmeny, jej kategorizáciu,
širšiu identifikáciu spojených rizík, priradenie zainteresovaných strán a následnú
komunikáciu s nimi, komunikáciu s IT personálom, komunikáciu s používateľmi
služby, posúdenie načasovania zmeny (vylúčenie prípadného prekrytia s inými
zmenami) a najdôležitejšie – Manažér zmien je zodpovedný za finálne schválenie
alebo neschválenie navrhovanej zmeny. Manažér zmien je zároveň schopný (a
často povinný) poskytovať pravidelné reporty, analyzovať trendy zmien a podobne.
Skupina poradcov pri zmenách
Alebo aj „Change advisory board“, skrátene „CAB“ sú určení zástupcovia
zainteresovaných strán. Ako ich názov hovorí, poradca slúži ako primárna
kontaktná osoba pre Manažéra zmien na konzultáciu pri riešení signifikantných
zmien
Správna rada
Pozostáva z predstaviteľov zainteresovaných strán, v praxi ide o lídrov služieb.
Správna rada vstupuje do procesu v prípade zmeny, ktorá je kategorizovaná ako
významná, teda ovplyvňuje veľký počet používateľov, prvkov infraštruktúry, veľkú
časť poskytovanej služby, alebo je zmena komplexného charakteru. Pretože ide
spravidla o skupinu ľudí, zavádza sa hlasovanie ktoré schváli alebo neschváli
zmenu.

27
Nultý bod, „trigger“
Iniciátorom každej zmeny je prirodzene potreba pre zmenu, bezdôvodné zmeny
prakticky neexistujú. Túto potrebu nazvime „spúšťač“, alebo anglicky aj „trigger“.
Trigger prichádza štandardne z dvoch kanálov – IT strana alebo biznis.
Nové RFC
Proces sa začína vytvorením RFC v nástroji pre správu, kde sú vyplnené všetky
povinné atribúty opísané v predošlej kapitole. RFC je uložené do databázy,
Manažér zmien je notifikovaný o existencii novej žiadosti, je nutné RFC
kategorizovať.
Autorizácia
Na základe posúdenia kategórie typu zmeny, podľa toho, či je riešená zmena
minoritná, signifikantná alebo významná, podlieha žiadosť autorizácii troma
kanálmi:
● minoritné zmeny autorizuje priamo Manažér zmien,
● signifikantné zmeny sú autorizované na základe konzultácie s CAB,
● významné zmeny podliehajú hlasovaniu správnej rady.
Za zmienku stojí špeciálny typ zmeny, takzvané predschválené zmeny, ktoré
nepodliehajú celému procesu. Ich atribúty sú vždy rovnaké, mení sa len
načasovanie zmeny a preto nie je potrebná separátna analýza. V každom prípade aj
predschválené zmeny musia byť štandardne dokumentované a schválené pre
implementáciu.
Príprava plánu implementácie a testovanie
Po autorizácii je žiadateľ v koordinácii s vlastníkmi služieb povinní zabezpečiť:
● prípravu detailného plánu implementácie,

28
● testovanie vykonania zmeny (najčastejšie v testovacom prostredí),
● a prípravu „back-out“ plánu v prípade neúspechu.
Schválenie RFC, implementácia, evaluácia a uzatvorenie zmeny
Ak sú všetky predchádzajúce body zabezpečené a testovanie prebehlo úspešne,
Manažér zmien žiadosť schváli. Podieľajúci sa personál zabezpečí zavedenie zmeny
na základe dohodnutých časových rozmerov.
Zmena je po implementácii monitorovaná pre prípad vedľajších efektov, je
dodržaný časový odstup a nakoniec je zmena formálne vyhodnotená a uzavretá.
Iné typy procesných tokov RFC
Špeciálnym prípadom procesného toku sú zmeny vytvárané v dôsledku nehody,
incidentu, teda ide o núdzové zmeny (priorita 1), ktoré majú za úlohu vzniknuté
zmeny vyriešiť. Pri riešení núdzových zmien je vždy prítomný tlak časového
náporu, preto je proces upravený a je akceptované väčšie riziko. Avšak aj pri
katastrofálnych scenároch nie je akceptované zavádzanie zmien bez zalogovania
zmeny a bez dozoru Manažéra zmien.

29
Obrázok 4, Procesný tok núdzovej zmeny,
Iným prípadom sú takzvané modelové zmeny, ktoré riešia bežné operačné
záležitosti a ich riziko bolo už pred tým zhodnotené, tiež testovanie prebehlo
úspešne, preto nie je dôvod byrokratických prieťahov, procesný tok je

30
zjednodušený. Štandardne ide o inštaláciu “upgrade-ov”, servisné kontroly a
podobne.
Obrázok 5, Procesný tok modelovej zmeny,
1.8 Zhrnutie kapitoly
V prvej kapitole práce sme teoreticky rozanalyzovali proces Riadenia zmien,
Vysvetlili sme prečo je proces kritický pre každú rozsiahlejšiu IT organizáciu, prečo
je zavedenie procesu dôležité z biznis hľadiska a aké sú jeho benefity. Ďalej sme
definovali čo je IT zmena samotná, čo spadá do jej rámca, čo je žiadosť o zmenu,
ako sa procesne spracúva, aké sú formálne role a ich právomoci a záverom sme
vyčlenili špeciálne prípady zmien.

31
2 NÁVRH IMPLEMENTÁCIE PROCESU DO PRODUKCIE
V nasledujúcej kapitole je našim cieľom navrhnúť detailný plán zavedenia
procesu do produkčnej činnosti. Plán je navrhnutý na základe teoretickej analýzy
vykonanej v kapitole 1 a je v súlade so štandardom ISO 20000 a metodikou ITIL.
Plán bude slúžiť ako smernica alebo príručka “krok-za-krokom” pre nami riešenú
rámcovú spoločnosť, zároveň je plne použiteľný ako šablóna pre implementáciu do
akejkoľvek inej firmy alebo organizácie.
Je dôležité spomenúť, že štandard ISO 20000 ani ITIL nevraví o
konkrétnych spôsoboch zavádzania, preto je náš plán možné použiť ako chýbajúci
most dokumentácie pre implementáciu. Iným nemenej podstatným faktom je, že
štandardy nepíšu o konkrétnych povinnostiach ITSM, ale o rámcoch, ktoré by mala
organizácia plniť - prakticky povedané v príklade - ISO ani ITIL nedefinujú, aký
nástroj pre správu RFCs organizácia musí použiť, podstatný je záznam a logovanie
zmien, hypoteticky môže slúžiť ak excelová tabuľka.
2.1 Identifikácia problémových faktorov
Riešená organizácia je momentálne vo fáze konsolidácie riadenia IT služieb,
to znamená, že v tomto stave:
● nie sú zavedené žiadne IT procesy (začína iniciatíva ich zavádzania),
● hierarchia IT organizácie nie je jednoznačne určená,
● zodpovednosti členov nie sú konkrétne definované,
● právomoci členov nie sú konkrétne definované.
Dôsledky sú teda prirodzene signifikantné - jednotlivé tímy pracujú
nekoordinovane, chýbajú jasné pravidlá a kompetencie jednotlivých vedúcich
tímov, chýba identifikácia a rámec poskytovaných služieb, spracovanie IT
požiadaviek a riešenie incidentov nie je štandardizované a formalizované,
neexistuje centralizované repozitorum (databáza), ktoré by obsahovalo informácie
o aktívach IT infraštruktúry. V neposlednom rade zmeny v IT infraštruktúre alebo
v ich poskytovaní nie sú plánované, koordinované ani predom revidované, čo

32
spôsobuje časté výpadky služieb z dôvodu prekrývajúcich sa zmien, alebo
chybnými zmenami. Všetky, ale nielen tieto nedostatky spôsobujú všeobecnú
nespokojnosť koncových používateľov a celkové, nie pozitívne renomé IT tímu.
Spoločnosť si je vedomá týchto nedostatkov, preto sa rozhodla
skonsolidovať intrafiremnú činnosť IT. Za vhodný spôsob metodiky bol zvolený
ITIL a norma ISO 20000. Je prirodzené, že nie všetky procesy sa dokážu
implementovať naraz - zavádzanie akéhokoľvek procesného prístupu vyžaduje
prostriedky a zdroje - časové, personálne ale aj finančné.
Ako najzávažnejší okruh zlyhávania boli posúdené: chýbajúca definícia
organizačnej štruktúry, štandardizované spracovanie IT požiadaviek a incidentov a
štandardizované spracovanie IT zmien - preto sa spoločnosť rozhodla v prvej fáze
konsolidácie vykonať nasledovné:
● vykonať dôkladnú analýzu rolí a zodpovedností a vybudovať organizačnú
štruktúru v rámci IT tímu,
● zaviesť proces Manažment incidentov a spracovania požiadaviek (ITIL
proces),
● zaviesť proces Riadenia zmien (ITIL proces).
Obrázok 6, IT Organizácia

33
2.2 Prerekvizity implementácie
Návrh ráta s predpokladom, že organizácia prešla organizačnou
reštruktualizáciou a teda sú jasne dané role, pozície, ich zodpovednosti a
právomoci - je zriadený vrcholový manažment IT organizácie, lídri služieb,
manažéri obchodného styku a manažéri dodávateľov. Návrh reštruktualizácie by
bol mimo rámca predmetu záverečnej práce. V každom prípade zavádzaním
Riadenia zmien prichádzajú niektoré (už spomenuté) role, ktoré treba personálne
zabezpečiť. Tieto role sú konkrétnejšie definované v sekcii 1.7, Štruktúra
procesného toku riadenia zmien, no pre rýchlu rekapituláciu uvádzame:
● Manažér zmien;
● Skupina poradcov pri zmenách, skrátene „CAB“ a Núdzový CAB;
● Správna rada.
Iným faktorom je, že samotné zavedenie procesu sa môže stať dlhodobejším
a náročným projektom bude (pravdepodobne) vyžadovať nasadenie projektového
manažéra s adekvátnymi skúsenosťami.
Neposledným činiteľom je finančné podchytenie projektu, preto treba
myslieť na rozpočet projektu, obchodný zámer investície a sponzora (v rámci firmy
alebo organizácie). Možnými položkami sú zaškolenie personálu alebo informačný
systém pre podporu procesu a jeho infraštruktuálne požiadavky.
2.3 Plánovanie
Faktor úspešnosti každého projektu je fundamentálne závislý na plánovacej
fáze. Hlavným cieľom plánovania musí byť vymedzenie atribútov procesu
a robustný projektový plán.

34
2.3.1 Definícia požiadaviek
Tak ako vývoj softvérových záležitostí, tak aj vývoj procesu musí byť pri jeho
plánovaní zadefinovaný špecifickými požiadavkami. Zoznam požiadaviek nie je
dôležitý len z hľadiska výsledného efektu, ale je taktiež dôveryhodnou “mierkou”
ako rozsiahly projekt organizácia očakáva - teda zaváži stratégiu spoločnosti vo
všeobecnosti. Požiadavky by mali byť vecné, stručné a špecifické - prax
projektového manažmentu jednoznačne ukazuje, že projekty s vágnymi a veľmi
všeobecnými požiadavkami sú čiernymi dierami pre časové a finančné zdroje.
Z toho hľadiska je nutné sa vyvarovať frázam ako “Vyriešiť kontrolu nad zmenami”.
Podľa Klosterboera (2007, s. 35) vieme požiadavky logicky rozdeliť do
štyroch okruhov, od globálnych po detailné, nadväzujúce na seba:
1. biznis požiadavky - riešia sa náklady, návratnosť, produktivita, efektívnosť;
2. procesné požiadavky - riešia vlastnosti procesného toku, procedúr, politík;
3. systémové požiadavky - riešia nároky na nástroj pre podporu procesu, tieto
požiadavky detailne rozoberieme v kapitole 3.2.1, Katalóg používateľských
požiadaviek.
List požiadaviek samozrejme nie je vecou rozhodnutia samotnej IT organizácie,
respektíve projektového manažmentu pre zavedenie. Požiadavky musia ísť
spätným revíznym chodom:
Obrázok 7, Definícia požiadaviek a ich revízia

35
Výsledkom tejto fázy by mal byť dokument, ktorý obsahuje ako minimum list
zainteresovaných strán (stakeholderi, sponzori) a ich schválenia, stručný prehľad
definovaného projektu, obchodný zámer (náklady, prínosy) a ako príloha detailný
list identifikovaných požiadaviek.
2.3.2 Definícia procesu
Status quo pre plánovaciu fázu je samozrejme zadefinovať, čo chceme
implementovať - každá organizácia môže zvoliť iný rámec, iné služby, rozhodnutie
je na strane IT manažmentu. Kostra musí byť však rovnaká, dokumentácia procesu
musí obsahovať nasledovné, Klosterboer (2007, s, 42):
Obrázok 8, Definícia procesu
Procesný tok
● Je prehľad aktivít, ktoré sú vykonávané v rámci procesu a ich logický sled,
ktorý musí byť dodržaný. Zvyčajne ide o štruktúrny diagram. Exemplárny
procesný tok je ilustrovaný v kapitole 1.7, Štruktúra procesného toku
riadenia zmien, ktorý bol koncipovaný podľa ITILu.
● Procesný tok nemusí byť jednotvárny pre všetky typy zmien - ak to situácia
vyžaduje procesný tok môže byť upravený a prispôsobený na rôzne typy
zmien podľa prostredia, podľa komplexnosti, podľa objektu zmeny, podľa
rizika, urgentnosti atď. Myšlienkou procesu je kontrolovať a vyhodnocovať

36
zmeny, nie je nutné zaťažovať beh každodennej rutiny zbytočnou
byrokraciou na viac. Ako príklad uvedieme špeciálne prípady procesných
tokov:
○ zmeny dátových centier (vysoký dopad, vysoké riziko, komplexnosť),
○ zmeny na pracovných staniciach (vysoký dopad, vysoké riziko),
○ modelová zmena (nízke riziko, štandardná zmena),
○ zmena v dokumentácii (nízky dopad, nízke riziko),
○ núdzová zmena (rôzne riziká, časová obmedzenosť)
- vidíme, že je vhodné poopraviť procesný tok adekvátne k riešeným zmenám.
Podprocesy
● Opcia. Aktivity procesného toku nie sú atomické, preto je možné ich rozbiť
na ďalšie podprocesné toky.
Politika
● Je dôležitý dokument definujúci hranice procesu, obecne povedané – „čo
spadá do vnútra“ - ktoré služby, ktoré hardwarové komponenty, ktoré
aktivity, etc. Politika vymedzuje, čo je v rámci organizácie považované za
zmenu a akým spôsobom musia byť zmeny procesované.
● Politika musí byť jednoznačná a jasná.
● Zavedenie politiky alebo jej zmena musí byť dôkladne odkomunikovaná
všetkým členom v rámci organizácie.
Procedúry
● Aktivity procesného toku sú len heslovité, procedúry slúžia na detailné
popísanie činnosti, ktorú ma zodpovedná osoba vykonať.

37
Pracovné inštrukcie
● Opcia. Opisujú technický spôsob ako sa majú procedúry vykonávať.
● Príkladom môže byť používateľský manuál k procesnému nástroju -
informačnému systému.
2.3.3 Dokumentácia RFC
Dokumentovanie požiadaviek o zmenu sme už konkrétne rozobrali v
kapitole 1.6, Žiadosť o zmenu (RFC), rozdelenie typov žiadostí. Je dôležité si
uvedomiť, že šablónová koncepcia nemusí sedieť každej organizácii, preto sú
možnosti dokumentácie v princípe otvorené úpravám a pridaniu ďalších atribútov.
Preto je na uváženie zvolenie takého nástroja pre správu RFCs, ktorý bude
poskytovať možnosti prispôsobenia vstupných formulároch pre dokumentáciu
zmien.
Iným nemenej dôležitým aspektom dokumentácie je identifikácia aktív,
ktoré budú zmenou dotknuté - či už rozprávame o hardvérových komponentoch,
databázach, systémoch, službách, etc. To znamená, že systém pre správu by mal
byť linkovaný s takzvanou CMDB (angl. Configuration Management DataBase,
Databáza Riadenia Konfigurácie). Návrh a teoretická analýza CMDB by znova
prekročila rámec tejto práce, ale pre stručnú ilustráciu - CMDB je databáza, resp.
systém obsahujúci informácie o všetkých aktívach IT infraštruktúry, jej
hardvérové, softvérové prvky ako aj licenčné či dodávateľské jednotky. Najväčším
prínosom CMDB nie sú len informácie samotné, ale vzťahy medzi nimi - to
znamená že dokážeme identifikovať nie len prvok, ktorého sa zmena týka, ale aj
pridružené prvky, respektíve služby, ktoré sú závislé na tomto prvku. Napríklad -
zmena diskového poľa serveru:

38
Obrázok 9, CMDB závislosť
Z obrázku 9 vidíme, že zmena na hardvérovej úrovni daného serveru priamo
ovplyvní službu tlačenia (na serveri je inštalovaný servis pre manažment tlačenia a
tlačiarní). Pri každej infraštruktúre, ktorá má istú komplexnosť, je teda CMDB
nutnosťou.
2.3.4 Posúdenie risku, autorizácia, schválenie
Kľúčové je posúdiť dopad pri zlyhaní žiadanej zmeny a pravdepodobnosť
tohto výskytu, tak ako znázorňuje Tabuľka 2. Samozrejme nie vždy je matrica
adekvátnou mierkou posúdenia, preto musí schvaľovateľ zmeny použiť “zdravý
rozum” - akokoľvek sa budeme snažiť zmeny zovšeobecniť a riešiť ich šablónovite,
výnimky budú prichádzať na pravidelnej báze, preto musí schvaľovateľ, teda
manažér zmien, jednať racionálne a zmeny vyhodnocovať vždy s prihliadnutím na
individualitu.
Po posúdení zmeny je zmena autorizovaná, to znamená že je povolené
vykonať hlbšiu analýzu a zmena môže byť implementovaná - neznamená to však
povolenie pre implementáciu - až keď je návrh pre zmenu zhodnotený, úspešne
otestovaný, je vytvorený spätný plán, načasovanie, zmena je dôkladne

39
dokumentovaná a všetky zainteresované strany vyjadria súhlas so zmenou, až
následne môže byť zmena definitívne schválená. Celý procesný tok znázornený v
diagrame, obrázok 3, kapitola 1.7.
2.3.5 Plán implementácie
Za úspešnú implementáciu považujeme splnenie všetkých požiadaviek,
ktoré boli definované v rámci fázy ich definície. Je opäť nutné rozanalyzovať list
požiadaviek a konvertovať ich na jednotlivé úlohy a k jednotlivým úlohám priradiť
časové a personálne zdroje - samozrejme zohľadňujúc ich komplexicitu. Nie všetky
úlohy sú rovnako náročné preto “prvý nástrel” rozhodenia úloh nemusí byť finálny,
každá úloha by mala byť po priradení znova analyzovaná a v prípade potreby
upravená - úlohy môžu byť rozbité na sub-úlohy, respektíve sa môže uvážiť
rozšírenie personálnych zdrojov. Vzniká kolobeh:
Priradenie -> Analýza -> Úprava
dovtedy, kým nie sú jednotlivé úlohy adekvátne rozdelené a ich časový sled nie je
zarovnaný.
Nadväzujúcou aktivitou je identifikácia nadväzností jednotlivých úloh a ich
vzájomných nadväzností. Príkladom dvoch úloh môže byť:
1.) inštalácia procesného nástroja (informačného systému),
2.) import dát (používatelia, špecialisti, skupiny...).
Z príkladu je očividné, že úlohy musia nasledovať v slede 1.) a 2.), opačný postup
nie je možný - príklad sa zdá primitívny, avšak pri narastajúcom počte úloh a pri
ich rôznorodosti to nemusí byť vždy na pohľad jasné. Je potrebné vidieť ucelený
list úloh, mať ucelený prehľad nad nimi a vyskladať toto “puzzle” na základe
vzťahov medzi nimi.
Poslednou súčasťou plánu implementácie je formalizácia predchádzajúcich
dvoch aktivít - vytvorenie projektového plánu. Správny projektový plán by mal
pozostávať z nasledujúcich častí:

40
1. Zámer a rámec projektu - hlavička projektového plánu musí obsahovať
základné informácie o projekte a najmä jeho určenie zámeru a prínosov.
2. Časový plán úloh - list jednotlivých úloh v logickom časovom slede,
rozdelené na sub-úlohy, znázornené preväzbenie úloh, priradení
zodpovedajúci členovia - príkladom môže byť klasický MS Project sheet,
Gantov graf.
3. Komunikačný plán - obsahuje identifikáciu sponzorov, stakeholderov,
projektového tímu, plus šablóny jednotlivých informačných emailov, ktoré
budú v priebehu implementácie projektu zaslané - implementácia projektu
musí byť dôkladne odkomunikovaná všetkým zainteresovaným stranám ako
sme už viac krát opisovali.
4. Finančný plán - teda rozpočet projektu, odhady nákladov a odhadovaná
návratnosť (ak sa dá vyčísliť).
2.4 Implementácia
Prechádzame z fázy plánovacej do exekúcie projektu. Implementačná časť sa
zameria na výber vhodného nástroja pre podporu procesu, migráciu pôvodných
dát, návrh pilotného behu a finálne nasadenie procesu do produkcie.
2.4.1 Výber procesného nástroja - informačného systému
Dnešný trh ponúka skutočne široké spektrum nástrojov pre podporu
procesu riadenia zmien - väčšina z nich vznikla ako nadstavbové moduly k
nástrojom pre správu IT incidentov a požiadaviek. Našim zámerom bude
samozrejme navrhnúť vlastný nástroj a demonštrovať tým že development
vlastného, na mieru ušitého systému, nie je ničím prevratným. Ak sa organizácia
rozhodne pre implementáciu treťostranového produktu, je kľúčové, aby systém
spĺňal nasledovné:

41
● zhoda s definovanými požiadavkami na systém,
● možná integrita s ostatnými podpornými nástrojmi riadenia IT služieb,
● kompatibilita s IT prostredím,
● kolidovanie so schváleným rozpočtom.
V prípade viacerých kandidátov je vhodné vytvoriť tabuľku posúdenia, ktorou
vieme posúdiť vhodnosť v rámci rovnakých metrík. Napríklad:
Váha Systém X [body] Systém Y [body] Systém Z [body]
Požiadavka 1 V A K I
Požiadavka 2 W B L J
Požiadavka 3 U C M K
... ... ... ... ...
Spolu (V*A)+(W*B)+(U*C) (V*K)+(W*L)+(U*M) (V*I)+(W*J)+(U*K)
Tabuľka 4, Posúdenie vhodnosti nástroja
Pre ilustráciu - krátky prehľad dostupných komerčných nástrojov:
BMC Remedy:
http://www.bmc.com/it-solutions/remedy-change-management.html

42
SunView ChangeGear:
http://www.sunviewsoftware.com/products/change-management
HP IT Change Management Suite (HP Service Manager)
http://www8.hp.com/us/en/software-solutions/itil-change-configuration-release-
management/
Obrázky 10, 11 a 12, Komerčné nástroje pre riadenie zmien
2.4.2 Migrácia a konsolidácia dát
Prax ukazuje, že väčšina organizácií má svoj neoficiálny proces pre riadenie
zmien - Excel tabuľka so zmenami a ich popisom, Lotus Notes databáza so
záznamami zmien, rôzne prispôsobené kalendáre s prehľadmi zmien - informácie v
nich sú dôležité a mala by sa vždy zvážiť ich možnosť pre import do nového
systému - kvôli archivačným a štatistickým dôvodom. Určite narazíme na diskusie
ohľadom nekompletnosti dát a nezhody v atribútoch - je samozrejmé, že dáta

43
nebudú kompletné, no je vhodné využiť, čo je k dispozícii a “vyparsovať” maximum
dát. Tieto zmeny by mali figurovať v novom systéme ako uzavreté, bez možnosti
editácia - “read only” mód.
Čo sa týka nových záznamov zmien v novo-implementovanom systéme, je
doporučené nastaviť proces archivácie dát - vytvoriť politiku pre retenciu dát
systému. Nie je potrebné v systéme držať zmeny 10 a viac rokov staré, najmä ak ide
napríklad o záznamy serverov, ktoré sú dávno odstránené z infraštruktúry.
Zbytočne veľký počet záznamov môže pôsobiť kontraproduktívne - zníženie
výkonu systému, spomalenie prehľadávania, a tak ďalej. Proces môže v prehľade
vyzerať napríklad nasledovne:
Obrázok 13, Retencia dát RFC záznamov
2.4.3 “Oživenie procesu”
Míľnikom pre reálny štart akéhokoľvek procesu je „workshop” - pracovné,
viacdenné stretnutie, ktoré by malo priniesť reálne výstupy. Je prirodzené, že
všetky doteraz spomínané body od plánovania po začiatky implementácie sa
nedajú realizovať bez spoločného zasadnutia všetkých zainteresovaných. Výstupom
workshopu by mali byť:
● všetky formálne dokumenty - procesný tok, politiky, procedúry, etc,
● rozhodnutie a ukončenie výberu informačného systému,
● obsadenie rolí procesu - manažér zmien, CAB, správna rada,
● vyriešenie všetkých nejasností a otvorených otázok ohľadom
implementácie.

44
Po obsadení rolí procesu personálom je dobrým zvykom nechať personál
certifikovať. Všetci členovia IT organizácie by mali mať zvládnutý ako minimum
kurz ITIL v3 Foundation, pre členov tímu implementácie je vhodný ISO 20000, to
znamená zoznámiť sa s procesným IT riadením na vyššom leveli, a pre samotného
manažéra zmien má zmysel zvážiť ITIL Service Transition Intermediate Level
certifikáciu.
Nemenej dôležité je pripraviť tréningy a školenia pre všetkých používateľov
zvoleného nástroja - systému. Je nutné, aby v deň „roll-outu“ (uvedenia do
produkcie), každý člen organizácie vedel, kde sa systém nachádza a ako sa má
používať.
2.4.4 Beh pilotnej fázy a prechod z pilotu do produkcie
Posledným krokom pred absolútnym spustením je úspešný beh pilotnej
fázy. Pilotnou fázou rozumieme beh IT služieb už pod implementovaným
procesom, ale pri zúženom rámci. V princípe ide o testovanie procesu za reálneho
behu. Je vhodné v rámci pilotného záberu vybrať komplexnejší cieľ - najlepšia
cesta ako identifikovať možné nedostatky procesu a včas ich odstrániť. Cieľom
behu pilotnej fázy by malo byť okrem iného:
● získať istotu pre prechod do ostrej fázy,
● odstrániť všetky nedostatky technického charakteru,
● získať prvé benefity návratnosti ako dôkaz úspešnosti projektu.
Ak sú splnené všetky predpoklady, ktoré boli pojednané, proces môže byť po
vhodnom načasovaní a dôkladnom ohlásení spustený do ostrého chodu. V prípade
menších organizácií nie je problémom spustiť „roll-out“ v jeden deň, pri tých
rozsiahlejších má zmysel spúšťať štart vo fázach s dostatočným časovým
rozostupom kvôli prevencii nečakaného spätného náporu.
Prirodzene, v iniciálnych fázach je nutné zabezpečiť zvýšenú podporu pre
používateľov - ako po strane technickej, tak aj po tréningovo-školiacej.

45
Cieľom kapitoly bolo vytvoriť propozíciu pre plán zavedenia procesu do
produkčnej činnosti. Použitím príručky by nami riešená spoločnosť mala predísť
všetkým rizikovým fázam implementácie a zároveň upozorniť na potencionálne
“bottlenecky”, teda úzke miesta s možným spojeným rizikom. Inou problematikou,
ktorá by prekročila rámec záverečnej práce, sú operačné záležitosti pri chode
procesu v produkcii. Je nutné podotknúť, že implementačnou fázou nie je proces
reálne zavedený a ustanovený.

46
3 NÁVRH A IMPLEMENTÁCIA PROCESNÉHO NÁSTROJA -
INFORMAČNÉHO SYSTÉMU
V nasledujúcej kapitole navrhneme a čiastočne implementujeme
informačný systém, ktorý bude slúžiť ako nástroj pre podporu procesného riadenia
zmien. Systém je v súlade s teoretickým zázemím prvej kapitoly záverečnej práce
a je zároveň súčasťou implementačného plánu popísaného v kapitole druhej.
Definujeme požiadavky pre navrhovaný systém, vykonáme funkčnú a
dátovú analýzu. Ako hlavný nástroj pri návrhu použijeme UML (Unified Modeling
Language) - všetky grafy, diagramy a ich obsahujúca symbolika bude v súlade s
touto vizualizačnou notáciou. Ďalej priblížime čitateľovi architektúru aplikácie,
objasníme použité technológie a záverom systém demonštrujeme formou ukážok
systému a vykonáme adekvátne testovanie.
Úroveň návrhu a implementácie systému má plošný charakter a je
postavená na globálnejšom leveli - detailný rozbor problematiky je mimo nášho
zámeru. Náš primárny cieľ je poukázať na jednoduchosť vývoju systému, ktorý
reálne zastreší základné potreby pre operatívu procesu Riadenia zmien.
3.1 Analýza problémovej oblasti
Úplný popis významu zavedenia procesu bol opísaný v kapitole 1.3, Význam
a zámer procesu Riadenia zmien, pre rekapituláciu zhrnieme hlavné nedostatky
situácie pred zavedením a najvýznamnejšie dôvody pre implementáciu:
● nejednotné, prípadne absolútne chýbajúce procedúry a politiky pre
zavádzanie IT zmien,
● chýbajúca dokumentácia zmien,
● chýbajúce riadenie zmien, ich časovanie, vyhodnocovanie z pohľadu rizík a
schvaľovací proces,
● chýbajúca komunikácia zmien a teda minimálna alebo žiadna
informovanosť IT tímu,
● chýbajúce štatistiky pre riadenie IT služieb.

47
Z nedostatkov vyplývajúce dopady, najmä:
● vysoký počet incidentov IT služieb (výpadkov alebo degradácií služieb) z
dôvodu:
○ chybných zmien,
○ neschválených zmien,
○ zle zkoordinovaných zmien,
○ prekrývajúcich sa zmien,
● počet incidentov priamo a nepriamo ovplyvňuje samotnú produkciu firmy -
výpadky, prerušenia služieb a pod. - preto má dopad aj finančný charakter,
● nemožnosť sa vrátiť k historickým zmenám, teda bez možnosti využitia bázy
poznatkov,
● nemožnosť reportingu pre manažment - ako IT tak aj vedenie organizácie.
3.2 Funkčná analýza
Z predchádzajúcej kapitoly je zrejmé, že situácia je neúnosná a možným
riešením je návrh a implementácia informačného systému, ktorý by slúžil ako
nástroj pre podporu procesného riadenia. Je potrebné definovať požiadavky -
popis funkcií a vlastností daného informačného systému.
3.2.1 Katalóg používateľských požiadaviek
Požiadavky rozdeľujeme štandardne do dvoch kategórií:
● funkčné požiadavky - určujú funkčné charakteristiky, ktoré má požadovaný
informačný systém spĺňať,
● nefunkčné požiadavky - určujú charakteristiky systému, ktoré síce nebudú
mať priamy vplyv pre používateľa, ale budú zohľadnené pri návrhu a
implementácii informačného systému.
Katalóg požiadaviek je vytvorený na základe diskusií manažmentu spoločnosti,
manažmentu IT organizácie, biznis analytikov, projekt manažérov a developerov.

48
Konkrétny katalóg funkčných a nefunkčných požiadaviek uvádzame v nasledujúcej
tabuľke:
# Funkčné
požiadavky
Podrobné informácie Priorita
(1 min - 3 max)
R01 Správa RFCs (angl. request
for changes, žiadosti o zmenu)
Systém bude schopný
vytvárať, ukladať, editovať
a mazať požiadavky a
modifikovať ich atribúty
3
R02 Správa používateľov Systém umožní registráciu
používateľských účtov, ich
modifikáciu a pridelenie
používateľských rolí
3
R03 Správa rolí Systém umožní správu
používateľských rolí a
nastavenia ich oprávnení
3
R04 Konfigurácia procesu Systém umožní
konfiguráciu pridruženého
procesu – bude možné
nastaviť parametre pre
jednotlivé kroky
schvaľovacieho procesu
RFC
2
R05 Nastavenie formulárov Systém poskytne možnosť
úpravy formulárov pre
správu RFC – pridanie
poľa, zmena, skrytie
2
R06 Export štatistík Systém bude poskytovať
funkciu pre zobrazenie
štatistík záznamov
3

49
R07 Autentifikácia Systém je zabezpečený
voči neautorizovanému
prístupu, prihlásenie
pomocou mena, hesla
3
R08 Prístup cez webový prehliadač Ako aplikačný “front-end”
bude použitá webová
stránka
3
R09 Interface pre mobilné
aplikácie a iné systémy
Systém bude poskytovať
webové služby pre
prípadne pripojenie k
mobilným aplikáciám
alebo iným systémom
1
R10 Rozšíriteľnosť Systém bude rozšíriteľný o
prídavné funkčné moduly
pomocou “plug-in”
riešenia
1
R11 TLS zabezpečenie Prenos dát medzi klientom
a serverovou časťou
aplikácie bude kryptované
pomocou TLS
1
# Nefunkčné
požiadavky
Podrobné informácie Priorita
R12 Kompatibilita s PHP verzia
5.4
3
R13 Kompatibilita s MySQL verzia
5.5
3
Tabuľka 5, Katalóg požiadaviek

50
3.2.2 Nájdenie účastníkov a prípadov použitia
Informačný systém by mal mať definovaných vo fáze návrhu svojich
účastníkov, aktérov. Pojmom účastník sa chápe rola, v ktorej bude daný používateľ
so systémom interagovať. Spravidla reprezentujú a odrážajú reálnu úlohu
konkrétneho zamestnanca v organizácii, no v častých prípadoch môže jeden
zamestnanec vystupovať pod viacerými rolami. Ku každej roli sa viažu oprávnenia
a prípady použitia s rolou spojené. Základné role systému uvádzame, no systém
bude schopný definovať role v rámci administrácie.
# Názov účastníka Detailný popis
A01 Administrátor Systémový administrátor, ktorý má oprávnenie k
všetkým úkonom - okrem registrácie, editácie a
mazania RFCs, disponuje právom nad
používateľskými účtami, databázou CMDB a
konfiguráciou systému.
A02 Manažér zmien Disponuje právom editovať položky, ktoré sú
povolené pre len procesnú rolu manažéra zmien
a má oprávnenie posúvať RFC do statusov
“autorizované” alebo “schválené”.
A03 Používateľ Bežný používateľ s právom vytvoriť RFC a
editácie RFC.
A04 Systém Niektoré aktivity nevyvolávajú priamo
používatelia IS, iniciuje ich systém automaticky
na základe indirektných podnetov. Kvôli jasnej
diferenciácii pridávame “Systém” ako
samotného aktéra.
Tabuľka 6, Role používateľov

51
3.2.3 Behaviorálne a štruktúrne diagramy UML
Prípad požitia, resp. Use Case je aktivita iniciovaná všeobecným
používateľom, ktorej účel je dosiahnutie určitého cieľa, výstupu, najčastejšie ide o
zmenu dátovej časti systému, alebo interakciu s ňou. Prehľad najvýznamnejších
prípadov použitia uvádzame v nasledujúcej tabuľke.
# Názov prípadu použitia
UC01 Vytvor RFC
UC02 Edituj RFC
UC03 Zmaž RFC
UC04 Autorizuj RFC
UC05 Schváľ RFC
UC06 Autentifikuj používateľa
UC07 Skontroluj autentifikáciu
UC08 Odhlás používateľa
Tabuľka 7, Prípady použitia
Pre vizualizáciu prípadov použitia je vhodné použiť diagram, ktorý používa
niekoľko symbolov:
● postavička - účastník, aktér,
● elipsa - prípad použitia,
● spojovacie šípky - priraďuje oprávnenie prípadu použitia a aktéra,
● “prevod” - použité ako nie-štandard, vyjadruje interakciu systému
samotného.

52
Obrázok 14, Diagram prípadov použitia
Scenár prípadu použitia je jednoducho opísateľný ako logická sekvencia krokov
interakcie medzi účastníkom a informačným systémom. Pre príklad uvádzame
jeden z možných scenárov.

53
Prípad použitia: Registrácia požiadavky
ID: 01
Aktéri: Používateľ
Vstupné podmienky:
1. Používateľ má vytvorené konto
1. UC (Use Case) začína návštevou prihlasovacej stránku IS.
2. Používateľ zadá prihlasovacie meno (e-mail) a heslo.
3. Systém overí vstupné detaily s databázou.
4. Ak systém vyhodnotí správnosť údajov, zobrazí sa hlavný panel, ak nie,
používateľ je presmerovaný na prihlasovaciu stránku.
5. Používateľ klikne na možnosť pridať RFC.
6. Systém ponúkne formulár pre registráciu.
7. Používateľ zadá detaily RFC a uloží ho.
8. Systém požiadavku spracuje a uloží ju do databázy.
9. Používateľ môže registrovať ďalšiu požiadavku, alebo môže zo systému
odísť.
Tabuľka 8, Príklad prípadu použitia
List diagramov pokračuje nasledujúcimi:
 Obrázok 15 - diagram tried (štruktúrny diagram), ktorý definuje list tried
spolu s pridruženými metódami týchto tried a zároveň logické väzby medzi
týmito triedami
 Obrázok 16 a 17 - príklady sekvenčných diagramov – autentifikácia
používateľa a zobrazenie listu RFCs – konkrétne list RFCs priradené
autentifikovanému používateľovi,
 Obrázok 18 - diagram stavov pre triedu Ticket (RFC) – stavy sú navrhnuté
v súlade s procesným tokom Riadenia zmien, obrázok 3.
Diagram aktivít neuvádzame nakoľko je totožný s procesným tokom Riadenia
zmien – Obrázok 3.

55
Obrázok 16, Sekvenčný diagram – autentifikácia používateľa
Obrázok 17, Sekvenčný diagram – zobrazenie listu RFCs

56
Obrázok 18, Diagram stavov triedy Ticket (RFC)

57
3.3 Dátová analýza
Na základe funkčnej analýzy je potrebné vykonať propozíciu pre dátovú
štruktúru aplikácie. Jednotlivé entity a vzťahy medzi nimi sú navrhnuté
vychádzajúc z diagramu tried.
3.3.1 Definovanie entít, ich množín, atribútov a identifikácia relačných
vzťahov, entitno-relačný diagram
Celý proces definície dátovej štruktúry spojíme z dôvodu prehľadnosti a
stručnosti do jedného grafu, v ktorom zachytíme:
● entity a ich množiny,
● relácie (vzťahy) medzi množinami,
● kardinalitu a modalitu relácií,
● transformáciu entít a vzťahov do tabuliek fyzickej databázy,
● atribúty entít vo fyzickej databáze,
● primárne kľúče a cudzie kľúče.
Diagram je v princípe štandardný entitno-relačný diagram rozšírený o
transformačný proces a názvy tabuliek spolu s atribútmi.

58
Obrázok 19, Entitno-relačný diagram + transformácie relačných vzťahov

59
3.3.2 Fyzický model databázy
Na základe teoretického dátového návrhu sa model pretransformuje do
reálnej databázy. V našom prípade bolo vybrané riešenie už spomenuté MySQL
5.5. Pre vytvorenie dátovej štruktúry použijeme webovú aplikáciu pre databázový
manažment – phpMyAdmin. Nasledovný diagram je vytvorený pomocou funkcie
Designer.
Obrázok 20, Fyzický model databázy
3.4 Implementácia
Okrem propozičnej časti je našim cieľom daný systém aj čiastočne
implementovať. Rozhodli sme sa pre implementáciu nosnej časti – autentifikácia,
hlavný panel – „dashboard“ a pridávanie a editácia RFC záznamov.

60
3.4.1 Použité technológie a metodika
Navrhnutý systém bol implementovaný ako webová aplikácia. Je množstvo
dôvodov prečo zvoliť architektúru webserver - klient, najpodstatnejšie sú najmä:
● nezávislosť na zariadení - podpora PC, Mac, mobilné telefóny (smartfóny),
tablety,
● nezávislosť na operačných systémoch,
● potreba lokálneho klienta nahradená internetovým prehliadačom - odpadá
nutnosť inštalácie klienta, údržby a aktualizácie,
● všeobecná dostupnosť - nezávislosť na sieti (LAN, WAN, VPN),
● aplikácia je centralizovaná - funkčná aj logická časť je na strane servera,
● v neposlednej rade aj “trend” - snaha o škálovateľnosť aplikácií a ich
migrácia na „klaudové“ riešenia.
PHP, HTML, MySQL, jQuery a AJAX - sú jazyky, nástroje a systémy, použité pri
implementácii aplikácie. Pre konkrétnejšie vysvetlenie:
● “Back-endová” časť aplikácie, rozumieme jadro, ktoré spracováva klientske
požiadavky, vytvára dopyty na databázy a generuje výstupy, je
programovaná v skriptovacom jazyku PHP.
● Vstupné formuláre, “dashboard”, výstupy aplikácie, v princípe “front-
endová” časť aplikácie je web stránka, na ktorej pozadí je klasický HTML
pseudo-kód.
● Dátová časť aplikácie je postavená na obľúbenej platforme MySQL, ktorá je
obdobne ako PHP open source softvér. Spoločne s Apache službou bežiacou
na Linux serveri sa kombinácia Linux-Apache-MySQL-PHP obecne
označuje ako takzvaný „LAMP stack“ a je momentálne najčastejším
podvozkom pre chod webových aplikácií.
● Z dôvodu vylepšenia používateľského zážitku sme do “front-endovej” časti
implementovali jQuery skriptovanie, ktoré dynamicky mení základnú
stránku aplikácie na základe vstupov a výstupov. Dáta sa vymieňajú za
pomoci AJAX prenosov, asynchrónnych dátových tokov na pozadí. Takýto

61
princíp má dve hlavné výhody - aplikácia vyzerá dizajnovo a graficky na
lepšej úrovni a rýchlosť interakcie je rovnako výrazne zvýšená.
Za zmienku stojí použitie metodiky objektovo-orientovaného programovania,
ktoré by malo byť štandardom pri implementácii akéhokoľvek informačného
systému. V našom prípade sú objekty, ich atribúty a metódy definované v súbore
class.php.
3.4.2 Architektúra aplikácie
Nasledujúci diagram vysvetľuje väzbu komponentov aplikácie a dátový tok,
ktorý prebieha medzi nimi. V praxi používateľ pristupuje len dve “stránky”:
● index.php, ktorá slúži ako “landing page” - má za úlohu:
○ zobraziť prihlasovací panel v prípade neprihláseného používateľa,
○ presmerovať na main.php v prípade prihláseného používateľa,
● main.php, ktorá má funkciu základného panelu - v reálnom čase mení svoj
obsah a generuje sa na podnet interakcie používateľa so systémom.
Ostatné komponenty majú za úlohu čiastkové funkcie - spracovávajú podnety
prijaté od main.php a generujú výstup, ktorý main.php spätne zobrazuje:
● new_ticket.php - zobrazí formulár pre nové RFC,
● ticket_lisy_my.php - vytvorí list RFC na základe prihláseného používateľa
(jemu priamo priradené),
● ticket_list_group.php - vytvorí list RFC na základe prihláseného
používateľa (priradené skupinám do ktorých patrí),
● ticket_list_all.php - vytvorí list najnovších desiatich RFC,
● read_preview.php - zobrazí RFC,
● edit_preview.php - zobrazí RFC v editovacom režime,
● process_ticket.php - spracuje nové alebo editované RFC.
Autentifikáciu zabezpečujú check_login.php a logout.php.
Definícia tried a funkcií sa nachádza v súbore class.php (nie je v diagrame).

62
Obrázok 21, Architektúra aplikácie

63
3.5 Dokumentácia
Systém je dostupný na adrese http://chm.gapps.sk .
Podporované sú internetové prehliadače Chrome, Mozilla Firefox, Opera Browser
a MS Internet Explorer od verzie 9.
Obrázok 22, Prihlasovací formulár
Poznámka - Pre vstup do systému sa môžu použiť nasledujúce údaje:
● Manažér zmien - meno: filip.kubis@gapps.sk , heslo: filipkubis
● Používateľ - meno: martina.pasztorova@gapps.sk , heslo:
martinapasztorova
Autentifikácia je v súlade s požiadavkou R07 a technické pozadie funkcie opisuje
sekvenčný diagram „Autentifikácia používateľa“, obrázok 16.
Po autentifikácii je používateľ presmerovaný na hlavný panel - “dashboard”, ktorý
obsahuje list RFCs zoradený od najaktuálnejších po historické. Zároveň je list
rozdelený do troch podskupín pre lepšiu orientáciu:
1. RFCs priradené mne,
2. RFCs priradené mojim skupinám,
3. Prehľad najnovších RFC (10).

64
Zobrazenie listu RFCs, možnosti pre pridanie a editáciu sú v súlade s požiadavkou
R01. Technicky funkciu popisuje sekvenčný diagram „Zobrazenie listu RFCs“,
obrázok 17.
Obrázok 23, “Dashboard”
Pre vytvorenie nového RFC, je potrebné rozbaliť formulár pomocou linku “Nové
RFC” - Systém následne “rozbalí” formulár pre registráciu novej žiadosti. Žiadosť
sa uloží kliknutím na ikonu v hornom rohu formulára.

65
Obrázok 24, Nové RFC
Pre zobrazenie detailov RFC stačí kliknúť na piktogram štvorca v riadku
konkrétnej žiadosti - systém expanduje riadok a dynamicky dotiahne dáta o
zvolenom RFC.
Obrázok 25, Zobrazenie RFC
Podobne, v prípade potreby editácie alebo zmeny statusu RFC sa klikne na ikonu
editácie – následne sú zobrazené detaily RFC v editovacom móde. Pre uloženie
zmien je potrebné kliknúť na piktogram uložiť.

66
Obrázok 26, Editácia RFC
Možnosti pre editáciu statusu RFC sú automaticky generované na základe role
prihláseného používateľa – tým je dosiahnutý a zabezpečený procesný tok
definovaný na obrázku 3, Procesný tok Riadenia zmien.
Pre rekapituláciu, používateľ (žiadateľ zmeny) môže uviesť RFC záznam do
nasledujúcich statusov:
 nové,
 testovanie úspešné,
 implementované,
 zmena zvrátená,
 uzavreté.
Manažér zmien disponuje právom všetkých statusov, ale kľúčové pre proces sú:
 autorizované,
 neautorizované,
 schválené.
Jednotlivé stavy, ktoré môže nadobudnúť RFC sú logicky popísané na obrázku 18,
Diagram stavov triedy Ticket (RFC).

67
3.6 Testovanie systému
Pre uzatvorenie softvérového cyklu vývoju aplikácie je nutné vykonať
adekvátne testovanie. Testovanie nami implementovaného systému prebehlo
v dvoch fázach:
1. Interné testovanie:
Testovanie zabezpečené interným testerom, zámer testovania na verifikáciu
produktu. Interné testovanie odhalilo nedostatky v kóde a zároveň stavy pri
ktorých aplikácia nebola dostatočne ošetrená. Pre dokumentáciu testovacích
procedúr boli použité tzv. „Testovacie protokoly“ – príklad protokolu uvádzame
nižšie.
Testovací protokol
Číslo: 12 Projekt: Portál Manažmentu Zmien - DP Verzia: 0.14
Fáza testovania: Verifikácia
Testovaná funkcionalita: Autentifikácia
Internetový prehliadač: Chrome Verzia: 42.0.2311.90
Popis interakcie so systémom, očakávaný výstup:
Pokus o „bypass“ autentifikácie pomocou SQL injekciou „WHERE 1=1”.
Aplikácia by mala odfiltrovať špeciálne znaky autentifikačných údajov
Zistené nedostatky: Áno / Nie
Opis:
Systém autentifikuje používateľa aj bez korektných údajov.
Klasifikácia: Chyba aplikácie / Funkčná chyba / Pripomienka
Navrhované odstránenie:
Odfiltrovanie špeciálnych znakov pri autentifikácii
Testoval: Ivančík Dátum: 4. 3. 2015

68
Zhodnotenie a výsledok opravy:
Pridaná funkcia preg_replace() v check_login.php, konkrétne:
$email = preg_replace(‘/[^A-Za-z0-9-@.]/’, ‘’, $_POST[‘email’]);
$password = md5(preg_replace(‘/[^A-Za-z0-9]/’, ‘’, $_POST[‘password’]));
Tabuľka 9, Testovací protokol
2. UAT (z angl. User’s Acceptance Testing – testovanie prijateľnosti pre
používateľov)
Testovanie koncovými používateľmi, zamerané na validáciu produktu, to znamená
či je dodaný softvér v súlade so stanovenými požiadavkami a že plní
predpokladané funkcie. Nakoľko systém nebol plne implementovaný,
zodpovedajúce testovanie bolo v tomto smere limitované.
Návrhom a implementáciou systému sme chceli demonštrovať, že reálne
oživenie procesu riadenia zmien po technickej stránke nemusí byť zložité a zároveň
ani nákladné po finančnej stránke. Samozrejme je potrebné myslieť na možné
rozšírenie nástroja, prípadne jeho preväzbenie s inými procesnými nástrojmi.
Preto je potrebné zvážiť, či je aplikácia vytvorená “in-house” vhodným riešením.
Inou alternatívou sú hotové riešenia, ktorých prehľad sme načrtli v kapitole 2.4.1,
Výber procesného nástroja - informačného systému.

69
ZÁVER
Cieľom záverečnej práce bolo objasniť problematiku procesu Riadenia
zmien ako jeden z procesov definovaných normou ISO 20000, navrhnúť nasadenie
daného procesu do produkčného prostredia riešenej organizácie a záverom
realizovať propozíciu návrhu a čiastočnú implementáciu informačného systému,
ktorý slúži ako podporný nástroj pre prevádzku procesu. Stanovené ciele
záverečnej práce boli dosiahnuté.
Riešená organizácia proces reálne implementovala - za najprínosnejšie
kroky, ktoré priniesli okamžitú návratnosť patria okrem iných:
● spoločnosť stanovila procedúry, smernice a politiky, ktorými sú zmeny v IT
infraštruktúre spracovávané,
● spoločnosť nasadila systém pre správu zmien,
 Nami vytvorený systém nebol zavedený, nakoľko nebol plne
implementovaný a nedokážeme garantovať dlhodobú podporu
vytvoreného nástroja, ani akékoľvek dodatočné rozšírenie či vývoj
aplikácie. Implementovaný bol komerčne dostupný produkt, ktorý splnil
všetky definované požiadavky.
● spoločnosť zabezpečila uvedenie a dodržiavanie procesu počas denných
rutín operácií.
Návratnosť sa prejavila v priebehu relatívne krátkej časovej periódy (3-4 mesiace)
a to v podobe nasledovného:
● zvýšená viditeľnosť a zlepšená komunikácia IT zmien pre obe strany –
biznis aj IT podporný tím služby,
● znížený výskyt rizík spojených s dopadmi zmien,
● zlepšené posúdenie nákladov spojenými so zmenami, a teda presnejší
finančný reporting,
● minimalizácia neúspešných zmien a výpadkov služby, s tým spojená vyššia
efektivita zamestnancov a zlepšenie poskytovaných klientskych služieb
alebo produktivity,

70
● vyššia prispôsobivosť spoločnosti k dynamickému chodu skrz lepšiu
adaptabilitu a absorbčnosť,
● zlepšené povedomie IT organizácii voči manažmentu a tým prítomné
zlepšenie intrafiremných vzťahov a komunikácie.
V neposlednom rade samozrejme výsledná spokojnosť na strane interného aj
externého zákazníka.

ZOZNAM BIBLIOGRAFICKÝCH ODKAZOV
ISO/IEC. 2011. Information technology – Service Management, Part 1 – Service
management system requirements. Switzerland: ISO/IEC. 26 s.
ISO/IEC. 2012. Information technology – Service Management, Part 2 –
Guidance on the application of service management systems. Switzerland:
ISO/IEC. 85 s.
Guidance on scope definition and applicability of ISO/IEC 20000-1. Switzerland:
ISO/IEC. 34 s.
Exemplar implementation plan for ISO/IEC 20000-1. Switzerland: ISO/IEC. 41 s.
KANISOVÁ, H., MÜLLER, M. UML srozumitelně. Brno: Computer Press, 2006.
176 s. ISBN 80-251-1083-4
KLOSTERBOER, Larry. 2009. Implementing ITIL Change and Release
anagement. USA: IBM Press. 228 s. ISBN 9780138150419
OFFICE OF GOVERNMENT COMMERCE. 2007. The Official Introduction to the
ITIL Service Lifecycle. UK: London TSO. 238 s. ISBN 9780113310616
OFFICE OF GOVERNMENT COMMERCE. 2007. ITIL Service Transition. UK:
London TSO. 262 s. ISBN 9780113310487
W3Schools: PHP - AJAX and MySQL, [online] 2015, [cit. 2015-02-16]. Dostupné
na internete: http://www.w3schools.com/php/php_ajax_database.asp
W3Schools: jQuery ajax() Method, [online] 2015, [cit. 2015-02-20]. Dostupné na
internete: http://www.w3schools.com/jquery/ajax_ajax.asp

ZOZNAMPRÍLOH
Príloha A – CD nosič obsahujúci:
 zdrojový kód aplikácie,
 SQL skript (vytvorenie tabuliek + naplnenie exemplárnych dát),
 elektronickú formu tejto záverečnej práce vo formáte .PDF .

ČESTNÉ VYHLÁSENIE
Ja, dole podpísaný Šimon Ivančík týmto čestne vyhlasujem, že diplomovú
prácu na tému: “Manažment IT zmien a jeho implementácia podľa ISO 20000”
som vypracoval samostatne na základe poznatkov získaných počas štúdia,
samoštúdia a informácií z dostupnej literatúry uvedenej v bibliografických
odkazoch.
V Trnave, dňa 28. apríla 2015 _____________________
Šimon Ivančík, autor

zaverecna_prace (3)

Recommended

Recommended

More Related Content

Featured

Featured (20)

zaverecna_prace (3)