SSD Detaljna Funkcionalna Specifikacija

Detaljna funkcionalna
specifikacija
111089 Span Service Desk
Span d.o.o.
Autor: Drago Topalović / SPAN d.o.o.
Verzija: 1
Datum: 26.10.2020.
Oznaka tajnosti dokumant: Interno
Ovaj dokument je osigurao Span d.o.o. za &Customer& u skladu sa Span projektnom metodologijom. &Customer& nema
ograničenja u smislu korištenja ovog dokumenta u skladu sa njegovom namjenom. Korištenje, kopiranje ili daljnja distribucija ovog
dokumenta izvan tvrtke &Customer& je strogo zabranjeno.
Projekt: 111089 Span Service Desk
1. Revizije dokumenta
Verzija Ime i prezime Datum Opis
1.0 Drago Topalović 13.5.2016. Prvi Draft
1.1 Drago Topalović 24.7.2016 Faza 1 definirana
2. Odobrenje dokumenta
Odobrio Potpis
Ime i prezime, SPAN d.o.o.
Opis projekta 2/35

3. Sadržaj
1. Revizije dokumenta ..................................................................................................................................................................... 2
2. Odobrenje dokumenta .............................................................................................................................................................. 2
3. Sadržaj ............................................................................................................................................................................................ 3
4. Sažetak vizije/dosega projekta................................................................................................................................................ 5
5. Povijest projekta .......................................................................................................................................................................... 5
6. Sažetak funkcionalne specifikacije .......................................................................................................................................... 6
7. Poslovni zahtjevi .......................................................................................................................................................................... 7
7.1. Analiza troškova i koristi ..................................................................................................................................................... 7

7.2. Skalabilnost i performanse ................................................................................................................................................ 7
7.3. Raspoloživost / Pouzdanost ............................................................................................................................................. 7
7.4. Sigurnost................................................................................................................................................................................. 7
7.5. Podrška za heterogenu arhitekturu ................................................................................................................................ 8
8. Korisnički zahtjevi ........................................................................................................................................................................ 8
8.1. Korisničko iskustvo................................................................................................................................................................ 9

8.2. Jednostavnost uporabe ...................................................................................................................................................... 9
8.3. Pouzdanost .......................................................................................................................................................................... 10
8.4. Višejezičnost ........................................................................................................................................................................ 10
8.5. Obuka korisnika .................................................................................................................................................................. 10
9. Zahtjevi na sustav ...................................................................................................................................................................... 10
9.1. Međuvisnosti sustava i usluga ......................................................................................................................................... 10
10. Operativni zahtjevi ................................................................................................................................................................... 11

11. Korisnički scenariji ...................................................................................................................................................................... 11
12. Pretpostavke i utjecaji ............................................................................................................................................................. 17
13. Konceptualni dizajn ................................................................................................................................................................. 17
13.1. Alternativni koncepti ........................................................................................................................................................ 18
13.1.1. Microsoft System Center Service Manager ................................................................................................ 18

13.1.2. Service Desk proizvodi iz gornjih kvadranta Gartnerovih izvješća ...................................................... 18
13.1.3. Jeftina i „besplatna“ open source rješenja .................................................................................................. 18
14. Logički dizajn ............................................................................................................................................................................ 18
14.1. Scenariji: Incident management .................................................................................................................................. 24
14.1.1. Scenarij: Kreiranje incidenta ........................................................................................................................... 24
Opis projekta 3/35

14.1.2. Scenarij: Ažuriranje incidenta ........................................................................................................................ 25

14.1.3. Scenarij: Rješavanje incidenta ........................................................................................................................ 26
14.1.4. Scenarij: Zatvaranje incidenta ........................................................................................................................ 26
14.1.5. Scenarij: Reopen incidenta ............................................................................................................................. 27
14.1.6. Scenarij: Pregled incidenata ........................................................................................................................... 27
14.2. Scenariji: Request fulfilment ......................................................................................................................................... 28
14.2.1. Scenarij: Kreiranje zahtjeva SD ...................................................................................................................... 28

14.2.2. Scenarij: Ažuriranje zahtjeva .......................................................................................................................... 30
14.2.3. Scenarij: Rješavanje zahtjeva ......................................................................................................................... 30
14.2.4. Scenarij: Zatvaranje zahtjeva .......................................................................................................................... 31
14.2.5. Scenarij: Reopen zahtjeva ................................................................................................................................ 31
14.2.6. Scenarij: Pregled Zahtjeva .............................................................................................................................. 32
14.3. Scenariji: Problem management ................................................................................................................................ 32
14.3.1. Scenarij: Kreiranje problema .......................................................................................................................... 32

14.3.2. Scenarij: Ažuriranje problema ....................................................................................................................... 33
14.3.3. Scenarij: Rješavanje problema ....................................................................................................................... 34
14.3.4. Scenarij: naslov................................................................................................................................................... 34
15. Fizički dizajn ............................................................................................................................................................................. 35

16. Pravni zahtjevi .......................................................................................................................................................................... 35
17. Rizici ............................................................................................................................................................................................ 35
18. Referentni dokumenti ......................................................................................................... Error! Bookmark not defined.
Opis projekta 4/35

4. Sažetak vizije/dosega projekta

Span kreće u razvoj Service Desk proizvoda.
Span Service Desk (SSD) će u prvom redu biti namijenjen rastućem broju postojećih korisnika koji iskazuju
potrebu za implementacijom IT Service management (ITSM) procesa i alata, a krajnji cilj je razviti proizvod
koji će eventualno i Span moći koristiti u punom opsegu svojih ITSM aktivnosti.
Span Service Desk neće biti ni najbolja ni revolucionarna aplikacija konkurentna service desk aplikacijama
iz Gartnerovih kvadranata, ali ćemo imati nad njom potpuno vlasništvo i mogućnost kontinuiranog
razvoja u skladu s našim potrebama. Moći ćemo je nuditi našim korisnicima po povoljnim uvjetima, i
eventualno je prodavati nepoznatim korisnicima u hosting načinu ili za on-premise upotrebu.
U skladu s našom orijentiranošću na korisnika, aplikacija će morati imati lijepo, zavodljivo i funkcionalno
sučelje za krajnjeg korisnika, s mogućnošću interakcije odgovarajuće ovlastima korisnika. Posebnu pažnju
obratit ćemo mobilnim korisnicima, njihovom izvještavanju i interakciji s aplikacijom. Aplikacija će se
zasnivati na jednostavnosti i intuitivnosti uporabe i minimalnoj potrebi za korisničkim uputama.
U isto vrijeme aplikacija će nuditi funkcionalno, pregledno i upotrebljivo sučelje za inženjere koje će
minimizirati vrijeme obrade ključnih procesa.
Sukladno našoj poslovnoj strategiji, takvo rješenje treba biti Cloud-based, zasnivano na Microsoft
tehnologijama. Span će omogućiti hostanje, prodaju licenci, instalaciju u korisnikovom private cloudu.
Lijepo bi bilo da pojedine instance mogu međusobno razmjenjivati tickete kako bi se automatizirala
eskalacija među pojedinim poslovnim subjektima.
SSD će pokrivati osnovne ITSM procese u skladu sa najboljim praksama i standardima (ITIL i ISO20000).
Podržavat će integracije na elementarnoj razini sa drugim SD aplikacijama i nadzornim alatima.
Aplikacija će pružiti pristup svim informacijama korisnicima u skladu sa njihovim ovlastima i potrebama.
Ovo će omogućiti složeni sustav rola i administracije korisnika.
Aplikacija neće biti posebno zahtjevna za performansama, ali će voditi računa o brzini obrade ITSM
procesa i rada sa ticketima na intuitivan i pregledan način, uz ugodno i učinkovito korisničko iskustvo.
Arhitektura mora podržavati visoku raspoloživost sustava, mislit će se na jednostavnost backup/restore
aktivnosti. Planirati višejezičnost, u prvoj fazi samo hrvatski i engleski jezik.
Projekt će se razvijati u nekoliko faza, unutar kojih će se razviti podrška za prioritetne ključne procese.
5. Povijest projekta
U zadnjih nekoliko mjeseci pojavljuje se pojačano zanimanje korisnika za ITSM projekte, od
implementacije procesa, konzaltinga do alata.
Što se alata tiče, naši korisnici su uglavnom orijentirani na Microsoft tehnologiju, a dosadašnji SC Service
Manager kao Service Desk proizvod za njih se uglavnom pokazao nepraktičnim, glomaznim i teškim za
implementaciju. Potreban im je jednostavan ticketing alat koji će im omogućiti automatizaciju osnovnih
ITSM procesa bez CapEx opterećenja licencama i konzultantskim uslugama uvođenja.
Span ima veliko iskustvo u ovom području po pitanjima
• implementacije ITSM alata
Opis projekta 5/35

• razvoja SD alata
• ustroja ITSM procesa
Uslijed pojave nekoliko poslovnih prilika za Service Desk proizvodom, a uz značajni rast Span
Development resursa, razvoj ovakvog proizvoda se može pokazati dobrom odlukom.
Radit će se na razvoju aplikacije koja obrađuje jednu od naših ključnih poslovnih aktivnosti u kojoj imamo
visok stupanj kompetencije, te ćemo jednostavno moći kreirati skup zahtjeva kao zajednički nazivnik
potreba većine korisnika.
Projekt će se razvijati u nekoliko faza, unutar kojih će se razviti podrška za prioritetne ključne procese.
Faza 1:
• Incident management - upravljanje incidentima u punom opsegu; kreiranje, klasifikacija,
dodjela, praćenje životnog vijeka incidenta, ažuriranja, dvostupanjsko zatvaranje, notifikacije,
reporting, ankete o zadovoljstvu
• Request fulfilment - kreiranje, klasifikacija, elementarno odobravanje, notifikacije,
dvostupanjsko zatvaranje
• Problem management - upravljanje problemima tj. uklanjanje uzroka pojave incidenata;
kreiranje, veze na incidente, klasifikacija, životni vijek (known error/workaround/permanent fix),
RCA, ažuriranje vezanih incidenata.
• Configuration management - bazično, vođenje osnovnih podataka o Configuration Itemima
(CI), dakle o serverima i dijelovima infrastrukture koji kreiraju usluge, u najosnovnijem opsegu
koji će omogućiti praćenje gornja tri procesa.
Faza 2:
• Dorada prethodno implementiranih procesa
• Configuration management - u punom opsegu, Configuration Management Database (CMDB)
poslovni i tehnički katalog usluga, veze na CI-jeve u stablastoj strukturi, import CI podataka
• Change and Release management - konrolirano upravljanje promjenama, kategorizacija,
životni tijek, odobravanja, praćenje zadataka nastalih iz zahtjeva, notifikacije, kreiranje
templatea za standardne izmjene
• Service Level Management - ugovori, SLA parametri po korisniku i usluzi, utjecaj na Incident i
change management, dashboardi, Operation level agreementi (OLA), Underpinning contracts
(UC), reporting
Faza 3:
• Dorada prethodno implementiranih procesa
• Asset management - Veza na Configuration management, ugovori, jamstva, statusi, otpisCI-ja
• Business relationship management - Analize zadovoljstva, on-demand survey, obrada pritužbi
• Supplier management - utjecaj UC-a na kvalitetu isporuke usluga
• Knowledge management - Osnovni elementi KM-a mogu se implementirati u ranijim fazama,
ovdje bi se zaokružila funkcionalnost
Ovaj dokument ima za svrhu detaljno opisati procese prve dvije faze i osnovne značajke procesa iz treće
faze.
6. Sažetak funkcionalne specifikacije

Iako je predviđen razvoj po fazama, u ovm dokumentu opisat će se puna funkcionalnost svih modula. Za
one module čiji razvoj se prostire kroz više faza bit će spomenuto koja funkcionalnost se očekuje na kraju
pojedine faze.
Dokument se kratko referira na poslovne, korisničke, sistemske i operativne zahtjeve.
Opis projekta 6/35

Obrađuju se osnovne pretpostavke i utjecaji, a naglasak je dan na dizajn rješenja:

• Konceptualni – sa okvirnim dizajnom komponenti i relacija
• Logički – ovdje je dan naglasak na razvoj UseCase scenarija
• Fizički – ovaj dio obradit će fizičke odnose apliakcije i vanjskih sustava te specifičnosti, ali bez
utjecaja na konkretni fizički dizajn, to prepuštamo razvoju
Na kraju se dokument bavi dodanim vrijednostim kao što su sugurnost i rizici, integracjia, podrživost i
eventualni pravni zahtjevi.
7. Poslovni zahtjevi
Ovdje su dani osnovni elementi poslovnih zahtjeva:
7.1. Analiza troškova i koristi

Početna ideja za proizvod čini se profitabilnom. Span ima nekoliko korisnika koji mogu alimentirati troškove
dijela projekta, a gotov će proizvod biti na tržištu i biti će ga lako upakirati u projekt sa implementacijom
ITSM-a ili kao poseban proizvod za nepoznatog kupca. Detaljnu analizu troškova i koristi obavit će v.d.
Direktor Razvoja nakon procjene utroška sati.
7.2. Skalabilnost i performanse

Prvi korisnici bit će Spanovi klijenti i koristit će aplikaciju za automatizaciju internog supporta. No nije
isključeno da će aplikacija nakon dvije faze razvoja biti postavljena u okruženje sa intenzivnijim zahtjevima.
Kako se radi o jednostavnoj client/server arhitekturi sa podacima na poznatoj SQL Server infrastrukturi,
nema razloga da se ne predvidi podrška većem broju transakcjia i podataka. Predviđa se da sustav može
podržati 100.000 ticketa godišnje (cca 10.000 mjesečno, 300 dnevno) i mora biti funkcionalan sa 1.000.000
ticketa u bazi i 200 ulogiranih istovremenih korisnika. U tim uvjetima kreiranje forme za incident ne smije
trajati više od 3 sekunde.
7.3. Raspoloživost / Pouzdanost

S obzirom na prirodu procesa koje obrađuje, aplikacija bi trebala biti visokodostupna, kako bi u incidentnim
situacijama operateri i krajnji korisnici mogli unositi podatke o incidentima, problemima i izmjenama. Ovo
se može postići na više načina, dva osnovna su redundandna arhitektura i jednostavnost platforme.
Redundanciju treba imati na pameti prilikom dizajna sustava, ali se ne opterećivati njome u prvoj fazi.
Pojednostavljenje platforme podrazumijeva što je veću moguću neovisnost od složenih arhitektura.
Osnovna funkcionalnost aplikacije ne smije biti ugrožena padom funkcionalnosti pojedinih vanjskih
serverskih i integracijskih komponenti. Radi inicijalnih zahtjeva aplikacija mora u nekoj mjeri biti integrirana
sa Sharepoint serverom, ali mora moći funkcionirati i samostalno.
Vremena planirane neraspoloživosti uslijed nadogradnji i održavanja ovisit će od situacije pojedinog
korisnika, ali treba dizajnirati aplikaciju na način da ti vremenski prozori budu minimalni.
7.4. Sigurnost
Aplikacija će pružiti pristup svim informacijama korisnicima u skladu sa njihovim ovlastima i potrebama.
Ovo će omogućiti složeni sustav rola i administracije korisnika.
Posebnu pažnju obratiti na sigurnost podataka o infrastrukturi korisnika: pristupni podaci na infrastrukturu
moraju biti štićeni dodatno nekom vrstom enkripcije.
Korisnici Span Service Deska bit će:
Opis projekta 7/35

• Service Desk operateri – moraju imati pristupa svim poslovnim procesima i osnovnim
administracijskim funkcijama
• Support inženjeri – samo rješavanje ticketa i taskova
• Vođe grupa (timova) inženjera - nadzor rezultata timova, assignanje ticketa
• Service manager - nadzor rada SD-a, reporting osnovnih KPI-jeva
• Account Manager – Mogu biti tehnički i komercijalni account manageri, njih zanima
nadzor Support & Delivery procesa
• CEO – dashboard sa elaboriranim grafičkim pregledom Support i Delivery parametara
uz mogućnost drill-downa.
• Administrator aplikacije - korisnička prava, kategorije, import podataka...
• Korisnici – ovdje je imperativ da korisnik nikako NE SMIJE vidjeti podatke koji su van
područja njegovog interesa, a pogotovo podatke o drugim korisnicima. Korisnik na
raspolaganju ima poseban dashboard sa lijepim i modernim izvještajima te mogućnost
iniciranja zahtjeva i pregleda/ažuriranja postojećih zahtjeva.
▪ Krajnji korisnik – vidi osnovne info o ticketima na kojima je on kontakt osoba,
ažuriranje ticketa i kreiranje novih zahtjeva
▪ Krajnji korisnik-Power korisnik - kao i krajnji korisnik, ali nad svim ticketima svoje
org. jedinice
▪ Krajnji korisnik-Super korisnik - kao i krajnji korisnik, ali nad svim ticketima svoje
firme
▪ Krajnji korisnik manager - kao i krajnji korisnik, ali na home pageu ima moderan
informativni dashboard kroz kojega može raditi drill down po ticketima
7.5. Podrška za heterogenu arhitekturu

Ideja je da glavni operaterski i korisnički klijent bude internet browser. Kroz njega bi se obavljala
najzahtjevnija interakcija korisnika i aplikacije. Ako se tijekom analize uslijed performansi/sigurnosti ili
drugih zahtjeva pokaže da browser nije odgovarajući klijent, razmislit će se o klijentskoj aplikaciji.
Aplikacija će imati i mobilni klijent na sve tri popularnije platforme, koji će uglavnom biti osmišljen kao
interaktivni dashboard sa mogućnošću dobro dizajnirane prezentacije podataka, inicijacije zahtjeva i
ažuriranja ticketa.
Aplikacija će podržavati integracijske mehanizme s drugim sličnim aplikacijama, tako da će moći
razmjenjivati eskaslacijske i sinkronizacijske podatke o ticketima putem Web servisa ili parsiranjem mail
notifikacija.
SSD će u završnim fazama moći pristupati podacima nadzornih alata MS System Center obitelji, s
naglaskom na SCOM i SCCM.
8. Korisnički zahtjevi
Ovaj odjeljak ima zadatak definirati osnovne nefunkcionalne aspekte interakcije korisnika sa aplikacijom.
Opis projekta 8/35

8.1. Korisničko iskustvo

Ovdje se koncentriramo na osnovne tri vrste korisnika: interne operatere-managere, korisnika ITSM usluge
i mobilne korisnike.
Interni korisnici, od SD operatera do Managera koriste aplikaciju dobrim dijelom u incidentnim situacijama
kada je potrebna brza reakcija aplikacije i kvalitetan brz pregled te pretraživanje podataka. Stoga se ovdje
fokusiramo na brzinu obrađivanja formi i štedljivo korištenje ekranskog prostora.
Interni korisnici u IT Support organizaciji kreiraju tickete, nadziru njihovo automatsko otvaranje ili
otvaranje od strane korisnika, ažuriraju tickete i taskove proizašle iz njih te sudjeluju u njihovom
razrješavanju i zatvaranju. Također, IT Suport manageri imaju redovite potrebe za izvještavanjem
periodično prema korisnicima i svojem managementu, ali i ad-hoc izvještavanjem po većini polja na
ticketu za zadana razdoblja i po drugim kriterijima. Treba složiti jednostavan i pregledan mehanizam
ovakvog reportinga sa mogućnošću personaliziranih pogleda na podatke i pohrane ad-hoc pretraga kao
standardnih pregleda (view-ova). Ovi pergledi mogu biti pohranjeni kao privatni i javni.
Krajnji korisnici ITSM usluge koji su navođeni kao kontakt osobe na pojedinim ticketima ili su predstavnici
klijenta za grupu usluga žele biti pravovremeno i kvalitetno obaviješteni o stanju usluga i ticketa. Ovo im
se omogućuje kroz:
• korisnički portal, dakle dashboard sučelje na kojemu mogu prijavljivati zahtjeve, gledati i ažurirati
postojeće zahtjeve, vidjeti grafički prikaz ključnih parametara usluge i administrirati osnovne
postavke.
• sustav notifikacija u kojemu će poruke dobivati mailom ili SMS porukama. Korisniku mora biti
omogućeno da jednostavno administrira koje će poruke dobivati. Može se pretplatiti na tickete
pojedinog tipa, prioriteta, zatim može uključivati i isključivati opcije po kojim događajima će
dobivati notifikacije: kod kreiranja, ažuriranja, razrješenja ili zatvaranja ticketa.
Mobilni korisnici u osnovi su sljedeći:
• Interni – ovdje se radi uglavno o odgovornim osobama na raznim razinama upravljanja uslugom.
Primjer ovih korisnika su TAM-ovi (Technical Account Manageri), KAM-ovi, Support team leaderi i
Manageri. Moraju imati mogućnost pretplate na pojedine korisnike, usluge ili razine prioriteta, sa
jednostavnim preglednim prikazom stanja na podacima koji ih zanimaju te notifikacijama o
događajima na njima. Također mogu ažurirati tickete.
• Krajnji korisnici – predstavnici korisnika koji imaju potrebu za mobilnom aplikacijom su manageri
korisnika koji komuniciraju sa IT Supportom ili eventualno tehničke osobe koje zanimaju tehnički
aspekti dostupnosti usluga za koje su zaduženi te notifikacije o događajima na tim uslugama.
Krajnji korisnici imaju jednake mogućnosti kao i prethodni Interni support, ali su ograničeni na
podatke samo za svoju poslovnu organizaciju. Zbog ovih korisnika potrebnmo je iznimnu pažnju
posvetiti izgledu i upotrebljivosti aplikacije. Aplikacija mora biti intuitivna, dobro dizajnirana i u
skladu s standardima, tako da zahtijeva minimalne ili nikakve korisničke upute.
8.2. Jednostavnost uporabe

Rješenje mora biti u skladu s ITIL najboljim praksama i ISO 20k standardom. Također, treba biti ustrojeno
slično najboljim aplikacijama na tržištu iz ove domene. Ovo će osigurati transparentnost terminologije i
odvijanja procesa, te skratiti krivulju učenja korisnika.
Kako je već prethodno spomenuto, mobilni korisnici morali bi imati minimalnu potrebu za učenjem
funkcionalnosti, uporaba bi trebala jednostavna i intuitivna.
Zgodan feature bi bio mogućnost korisnika da iznese primjedbe i prijedloge za poboljšanja unutar same
aplikacije.
Opis projekta 9/35

8.3. Pouzdanost
Kako je već navedeno, iz razloga kritičnih uvjeta u kojima se odvijaju ključni ITSM procesi, očekuje se
visoka razina pouzdanosti i raspoloživosti osnovne aplikacije za operatere i krajnje korisnike.
8.4. Višejezičnost
Za sada aplikacija mora podržavati dva osnovna jezika u svim sučeljima: Hrvatski i Engleski. Ostaviti
mogućnost proširenja skupa jezika.
8.5. Obuka korisnika

Iako minimalna, aplikacija će zahtijevati obuku korisnika i korisničke upute. Za svaku verziju po završetku
svake faze treba osigurati adekvatne osnovne upute u obliku dokumenta ili video tutoriala. Također treba
predvidjeti način (on site, online, video) i duljinu trajanja obuke korisnika, kako bi se to moglo ponuditi u
ugovoru.
9. Zahtjevi na sustav
Kako je osnovna ideja da SSD bude MS zasnovano cloud rješenje, sistemski zahtjevi su uglavnom
orijentirani na mrežnu propusnost, funkcionalnost klijenata, integracijske elemente te verzioniranje.
9.1. Međuvisnosti sustava i usluga
SSD kao aplikacija može funkcionirati samostalno bez konekcije na vanjske sustave, ali pojedine
komponente i vanjski servisi bitno doprinose vrijednosti automatizacije ITSM procesa.
• Mail sustav – za slanje notifikacija sudionicima procesa, i za automatski update ticketa obradom
replyja na te notifikacije
• Korisnički portal – ovo je dio SSD-a, ali je tretiran kao posebna aplikacija gdje će korisnik moći
jednostavno predati zahtjeve i pregledati status svoje organizacije u skladu s ovlastima
• Mobilna aplikacija – uvjetno rečeno dio SSD-a, posebna mobilna aplikacija koja će imati
jednostavni korisnički interface za funkcionalnost sličnu portalu
• Veza na slične Service Desk aplikacije – za eskalaciju i razmjenu podataka o infrastrukturi od
korisnika i potencijalnih 3rd party service vendora koji sudjeluju u procesima
• Sučelje prema nadzornim i upravljačkim alatima – npr. SCOM za automatsko generiranje
incidenata kod pojave specifičnih alerta, i SCCM za ažuriranje informacija o infrastrukturi
• Chat klijent – neki klijenti bi htjeli inicirati zahtjeve i ažurirati ih kroz Chat klijent. SKYPE?
• Veza prema društvenim mrežama – možda ćemo htjeti/moći ponuditi neke posebne
funkcionalnosti korisnicima kroz privatne Twiter ili FB accounte, instagram...
• Telefonija – integracija s telefonijom je feature primjereniji call centru, no možda će biti
zahtjeva da se na ekranu prikazuju informacije o korisniku preko CallerID-ja
• Ostalo
Verzioniranje treba osmisliti na način da se minimizira mogućnost ispunjavanja specifičnih zahtjeva
pojedinih korisnika koji neće doprinijeti funkcionalnosti ostalih korisnika. Ovo treba ustrojiti na način da
se maksimalno poštuje sukladnost sa standardima u ITSM-u.
Opis projekta 10/35

10. Operativni zahtjevi

Ovdje su ukratko navedeni aspekti poslovnih zahtjeva sa naglaskom na operativno upravljanje
aplikacijom.
• Skalabilnost – u testne scenarije uključiti provjeru s navedenom količinom testnih podataka i
provjeriti odziv aplikacije
• Sigurnost – provjeriti u testu ovlasti dane u posovnim zahtjevima
• Podrživost – osigurati dashboard za upozorenja o malfnuctionima i obavijesti odgovornim
osobama za evente koji ukazuju na njih
• Raspoloživost – u skladu s prethodnim, treba dizajnirati aplikaciju da se što više izmjena u
funkcionalnosti može obaviti administrativnim operacijama bez zahvata u kodu koji zahtijevaju
downtime. Npr: zahtjev za dodavanje assignment grupe u eksterne dobavljače usluga na kojima
se ne mjeri vrijeme do rješenja bi trebao biti administrativna akcija na nekom flagu grupe, a ne
dodavanje u listu unutrar koda.
• Zahtjevi za obukom – Treba uzeti „No manual“ princip uvjetno. Ovdje se radi o automatizaciji
kompleksnih procesa i metodologija, za koje se u pravilu podrazumijeva duga i opsežna obuka
korisnika u osnovnom setu vještina i funkcionalnosti. Dakle, operateri i inženjeri koji sudjeluju u
ključnim procesima moraju biti uvježbani kroz opsežan proces treninga i upoznavanja sa
materijom.
S druge strane, korisnici koji aplikaciji pristupaju kroz Customer portal i mobilnu aplikaciju neće
imati prilike prolaziti opsežnu ili možda nikakvu obuku, te će u njihovom slučaju intuitivnost,
izgled i korisničko iskustvo morati slijediti najbolje prakse izrade aplikacija bez priručnika..
11. Korisnički scenariji

U ovom poglavlju samo nabrajamo i kratko opisujemo korisničke scenarije. Detaljni raspis Use Case
scenarija slijedi u logičkom dizajnu.
Treba napomenuti da svi ticketi (Incident, Problem, Service request, Change) imaju slična ponašanja i
slična polja. Sami procesi se sa stanovišta aplikacije razlikuju u detaljima. Referentni opis ponašanja ticketa
bit će dan u opisu Incident management procesa a u ostalim procesima bit će definirani detalji razlike.
Korisnički scenariji su sljedeći:
• Incident management - upravljanje incidentima u punom opsegu.
o Kreiranje incidenta – incident najčešće kreiraju djelatnici Service Deska. Njihova glavna
zadaća je da ispravno popune podatke o incidentu, klasificiraju ga, prioritiziraju i
navedu kontakt podatke o korisniku te ga riješe ili dodijele inženjeru na rješavanje.
Service Desk Manager i članovi support management tima provjeravaju periodično ima
li incidenata koji su dulje vrijeme neažurirani ili im prijeti opasnost da probiju SLA
vremena. Dodijeljena osoba dobiva mail notifikaciju o otvaranju incidenta sa linkom na
incident. Kontakt osoba, ovisno o administrativnim postavkama dobiva poseban
korisnički email o otvaranju ticketa sa linkom.
▪ Svaki ticket ima master/detail podatke na način da se matična polja definiraju
u master podacima, a sve promjene tih matičnih podataka logiraju se u detail
redovima.
▪ Svaki ticket može imati tzv. Taskove na sebi, to je također vrsta detaila. Task
ima status, opis, zaduženu osobu, datum/vrijeme izvršavanja i standardni
životni vijek Open-Pending previous-Work in progress—
Closed(Sucessful/Unsucessful). Ima i polje Preceding, koje ako sadrži neku
vrijednost, znači da task ima neki prethodni task koji se mora izvršiti (preći u
status closed) da bi se počelo rješavanje ovog taska. Ticket može imati
proizvoljno taskova na sebi.
Opis projekta 11/35

Ovisno o individualnim postavkama, Kontakt osoba je obaviještena svaki put

kada se Task ažurira. Promjene polja se logiraju. Zadužena osoba je
obaviještena kada njegov task prelazi iz statusa Pending previous u Work in
progres.
▪ Prilikom otvaranja svakog ticketa Operater može popuniti proizvoljnu količinu
polja, kreirati taskove na ticketu i pohraniti ticket kao template pod nekim
imenom. Template može biti privatni i javni. Privatni template može koristiti
samo taj operater a javni je dostupan svima koji imaju ovlasti kreiranja ticekta.
Prilikom otvaranja novog ticketa Operatermože odabrati opciju „From
template“ i aplikacija će mu ponuditi dostupne javne i privatne template za tu
vrstu ticketa.
o Ažuriranje incidenta - incident najčešće ažurira dodijeljena osoba (assignee) na
incidentu. Ovo se u pravilu radi kroz korisnički interface aplikacije. Incident može
ažurirati i kontakt osoba kroz svoj pojednostavljeni interfejs na korisničkom portalu, ali i
bilo koji drugi sudionik procesa supporta. Prilikom ažuriranja korisnik može promijeniti
matične podatke o incidentu, dakle naslov, prioritet, kategoriju i uslugu na kojoj je
incident kreiran. Svaka promjena matičnih podataka se logira. Također, prilikom
ažuriranja kroz GUI korisnik MORA upisati kratki opis updatea. SSD bilježi tko je i kada
unio update.
Dodijeljena osoba dobiva mail notifikaciju o ažuriranju incidenta sa linkom na incident
uvijek kada ažuriranje obavi netko drugi. Kontakt osoba, ovisno o administrativnim
postavkama dobiva poseban korisnički email o otvaranju ticketa sa linkom.Incident se
može ažurirati i jednostavnim reply-jem na ovu notifikaciju. Cijeli tekst maila upisuje se
u polje Opis na retku ažuriranja.
U svakom trenutku iz Incidenta se može kreirati Change ili Problem ticket koji će biti
povezan na ovaj incident. Dalje opisano u Change i Problem managementu.
Također, u svako trenutku moguće je dodati attachment na ticket. Ovo važi za sve
tickete. Attachmenti se čuvaju u posebnom file ili sharepoint folderu/library-ju i
dostupni su za pretraživanje po punom tekstu. Imaju jasnu oznaku iz kojeg su ticketa
nastali.
o Rješavanje incidenta – Kada dodijeljena osoba zaključi da je usluga korisniku ponovno
uspostavljena, stavlja incident u status „Resolved“ i obavezno unosi opis rješenja. Ako je
rješenje zahtijevalo istraživanje i otkrivanje manje poznatih tehnoloških specifičnosti,
workarounda ili primjene specifičnih rješenja, rješavatelj označava incident sa
„Knowledge base candidate“. Kontakt osoba korisnika dobiva mail notifikaciju da je
incident riješen, te se moli da potvrdi rješenje.
o Zatvaranje incidenta – Zatvaranje incidenta obavlja se po primitku potvrde korisnika o
ispravnom rješenju kroz korisničko sučelje postavljanjem statusa incidenta u „Closed“.
Svi ticketi koji su riješeni u razdoblju definiranom u postavkama (npr. 48h), a za koje
nije zaprimljena potvrda korisnika o rješenju jednom dnevno se prebacuju status
Closed. Korisnik dobiva mail notifikaciju o rješenju i link na anketu o zadovoljstvu
korisnikla koju može ispuniti. Za tickete koji su u Resolved ili Closed statusu korisnik
uvijek može zatražiti da se ponovno otvore. Akcijom „Reopen“ operater ih vraća u
status „Work in progress“.
o Pregled – korisnik ima na raspolaganju nekoliko standardnih tabelarnih pregleda (view-
ova) incidenata. Svaki od njih može se exportati u Excel ili csv format. Također, korisnik
može prijeći u napredni način pretraživanja gdje može po ključnim poljima pretraživati
tickete. Jednom kada je na zadovoljavajući način postavio pretražne kriterije i
zadovoljan je postignutim pregledom (npr. Svi otvoreni ticketi za korisnika MZLZ
prioriteta 1 i 2), može taj pregled pohraniti pod nekim imenom kao javni ili privatni
pregled. Javne preglede vide svi drugi operateri a privatne samo taj operater.
Opis projekta 12/35

• Request fulfilment - Requesti su unaprijed odobrene jednostavne promjene, ili promjene koje
zahtijevaju tek jednostavno odobrenje jedne osobe.
o Kreiranje zahtjeva – zahtjev kreira operator kroz GUI ili korisnik kroz customer portal. Kao
i kod Incidenta, korisnik unosi jednostavni tekst zahtjeva, eventualno može odabrati vrstu
zahtjeva iz izbornika. SD operater mailom biva obaviješten o novom zahtjevu korisnika,
otvara ga putem linka i dodatno klasificira. Za malo složenije zahtjeve (tipa Novi djelatnik)
kao i kod Incidenta, može se kreirati i nekoliko Taskova pod requestom, npr Kreiranje
accounta, nabava računala, instaliranje SW-a, izdavanje kartice...
Po pohranjivanju novog ticketa korisnik biva obaviješten mail notifikacijom, a također i
zadužena osoba na request ticketu te zadužene osobe na svim taskovima kreiranim pod
njime. Ako je označeno da taj tip Requesta zahtijeva odobrenje, tada osoba zadužena
za odobrenje dobiva mail sa linkom na akciju odobravanja. Ostali sudionici po
odobravanju dobivaju obavijest o rezultatu odobrenja a ticket status ide u Work in
progress ili Closed sa podstatusom Rejected.
o Ažuriranje zahtjeva – može biti dodavanje detalja pojašnjenja na ticket, ili ažuriranje
bilo kojega od taskova pod ticketom. Logiraju se sve promjene statusa Ticketa i
Taskova.
o Rješavanje zahtjeva – Request može biti u standardnim ticket statusima – Open-
Pending approval-Work in progress-Pending Vendor/Customer-Resolved-Closed.
Request se rješava prebacivanjem u status Resolved i kratkim opisom rješenja. Korisnik
biva obaviješten mail notifikacijom i linkom na web anketu o zadovoljstvu rješenjem.
Ako su u trenutku resolva postojali Taskovi koji nisu u statusu Closed, prebacuju se u
Closed i njihovi assignee-i obaviješteni su mailom o tome, sa tekstom opisa rješenja.
Korisnik može potvrditi rješenje mailom ili telefonom ili ga ponovno otvoriti, kao i kod
incidenta.
o Zatvaranje zahtjeva – kao i kod incidenta.
o Administracija -
o Pregled – Kao i kod Incidenta.
• Problem management - upravljanje problemima tj. uklanjanje uzroka pojave incidenata;
kreiranje, veze na incidente, klasifikacija, životni vijek (known error/workaround/permanent fix),
RCA, ažuriranje vezanih incidenata.
o Kreiranje problema – problem kreira inženjer podrške. Problem je UVIJEK vezan na
BAREM JEDAN Incident, a može biti i na više njih. Iz Problem ticketa uvijek se može
kreirati Change ticket. Problem ticket ima set podataka sličan incidentu. Vezan je na
korisnika i glavnog assigneeja. Vezan je na uslugu a može biti i na configuration item iz
CMDB-a (Configuration Management Database). Kategorizacija je različita od
incidenta. O kreiranju Problema mailom se obavještavaju Problem manager i osobe
vezane na vezanu Uslugu (TAM, KAM).
o Ažuriranje problema – Problem ticket prolazi životni ciklus problem statusa: Known
error/Workaround/Permanent fix. Status ticketa može biti kao i kod incidenta: Open-
Work in progress-Closed, bez pendinga i nije potrebno dvostupanjsko zatvaranje.
Problem također može pod sobom imati taskove i može biti kreiran pomoću
prethodno definiranog templatea. U svakom trenutku moguće je dodati attachment.
Attachmenti koji nastaju iz problema su uglavnom različite analize i izvještaji (RCA
analiza, Problem report) koji su pohranom automatski postavljeni u bazu znanja.
Zgodno bi bilo da se ovih par reporta mogu kreirati iz Problem ticketa tako da se
osnovna polja reporta automatski popune.
o Zatvaranje problema – prilikom zatvaranja opisuje se rješenje problema i može se kao i
kod incidenta označiti da je rješenje „Knowledge base candidate“. Zatvaranjem
problema ažuriraju se i svi Incident ticketi vezani na njega, bez obzira u kojem su
statusu.
o Administracija
Opis projekta 13/35

o Pregled – slično kao kod incidenata

• Configuration management - bazično, vođenje osnovnih podataka o Configuration Itemima
(CI), dakle o serverima i dijelovima infrastrukture koji kreiraju usluge, u najosnovnijem opsegu
koji će omogućiti praćenje gornja tri procesa.
• Configuration management - u punom opsegu, Configuration Management Database
(CMDB) poslovni i tehnički katalog usluga, veze na CI-jeve u stablastoj strukturi, import CI
podataka
o Import i export podataka – radi se o podacima o serverima i mrežnoj opremi nad
kojima vršimo support. Ovi podaci su heterogeni i treba pronaći način da se
organiziraju ovisno o vrsti opreme. Često se u bulkovima dodaju i demotaju. Ovdje
treba osmisliti jednostavan mehanizam za njihov import u aplikaciju.
o Podaci:
▪ Modeli – osnovni template za tip CI-ja, dakle može biti tip Cisco switcha, Vrsta
servera itd. Problem koji imamo ovdje je konkretno kod ove dvije vrste
opreme
▪ CMDB – Configuration Management Database sadrži sve podatke o pojedinim
CI-jevima. Ovi podaci bit će vezani na većinu ticketa. CI-jevi mogu biti vezani u
Parent/Child hijerarhiskoj strukturi. Konkretan CI utječe na jednu ili više usluga
kod korisnika.
• Change and Release management - konrolirano upravljanje promjenama, kategorizacija,
životni tijek, odobravanja, praćenje zadataka nastalih iz zahtjeva, notifikacije, kreiranje
templatea za standardne izmjene. Change management je nešto složeniji proces. Change
ticketi nastaju samostalno ili iz Problema i Incidenata. Promjene mogu biti standardne,
normalne i hitne. Standardne promjene su unaprijed odobrene promjene koje su korisniku
dostupne iz kataloga usluga. Normalne promjene razlikuju se po utjecaju i količini posla,
obično se klasificiraju kao male, srednje i velike. U ovisnosti od klasifikacije, odobrava ih jedna
ili više osoba uključenih u isporuku i konzumiranje usluge. Hitne promjene imaju skraćenu
proceduru i obično su kreirane iz incidenata najvišeg prioriteta.
o Kreiranje zahtjeva – Promjena se kreira iz GUI sučelja operatera, a može je kao zahtjev
kreirati i krajnji korisnik kroz svoj portal. Također, može nastati iz Incidenta kao način
smanjenja utjecaja problema sa uslugom i iz Problema privremeni ili permanentni fix.
Definira se jedna ili više usluga ili skup CI-jeva nad kojima se vrši promjena.
Operater unosi podatke o Change ticketu i pohranjuje ga. Change manager i njegovi
zamjenici dobijaju mail notifikacije. Change Manager otvara ticket i šalje ga na
odobravanje. Ticket je u statusu Pending approval.
Svi sudionici, dakle kontakt osoba korisnika, TAM-ovi nad uslugama i Change manager
dobijaju mail notifikacije da je zahtjev kreiran i mogu pristupiti odobravanju. Change
manager na svoju odgovornost može odobriti u ime nedostupnih članova i pokrenuti
promjenu. Nakon odobravanja, ticket status prelazi u Work in progress.
Change se također može pokrenuti iz prethodno spremljenog templatea, sa unaprijed
postavljenim poljima i Taskovima.
o Ažuriranje zahtjeva – Ažuriranje se obavlja u detaljima Change ticketa ili ažuriranjem
njegovih Taskova. Change statusi su isti kao i kod incidenta, uz dodatak statusa
Pending approval..
o Rješavanje zahtjeva – Change se rješava prebacivanjem u status Resolved i kratkim
opisom rješenja. Korisnik biva obaviješten mail notifikacijom i linkom na web anketu o
zadovoljstvu rješenjem. Ako su u trenutku resolva postojali Taskovi koji nisu u statusu
Closed, prebacuju se u Closed i njihovi assignee-i obaviješteni su mailom o tome, sa
tekstom opisa rješenja. Korisnik može potvrditi rješenje mailom ili telefonom ili ga
ponovno otvoriti, kao i kod incidenta.
o Zatvaranje zahtjeva – kao i kod incidenta.
o Administracija
Opis projekta 14/35

o Pregled – slično kao kod incidenata

• Service Level Management - ugovori, SLA parametri po korisniku i usluzi, utjecaj na Incident i
change management, dashboardi, Operation level agreementi (OLA), Underpinning contracts
(UC), reporting. Unutar SLM-a je nekoliko vrsta zapisa:
o Ugovor – Osnovni podaci o ugovoru o podršci s korisnikom. Jedan korisnik može imati
više potpisanih ugovora.
o Service Level Agreement (SLA) je element Ugovora koji govori o konkretnim SLA
parametrima: u kojem vremenu se pruža podrška, i koja su vremena reakcije i
popravka za incidente po prioritetima. Service Level Agreement ima navedene usluge
korisniku na koje se odnosi.
o Usluga korisniku – je konkretna usluga iz Kataloga usluga vezana na pojedinog
korisnika. Usluga korisniku ima svog TAM-a, i CI-jeve koji utječu na nju. Npr. Usluga E-
mail je vezana na sve Exchange servere i mrežne konekcije u firmi. Ovo je instanca
objekta Usluga.
o Usluga – je model usluge koju Servce Provider pruža, nevezan na korisnika, dakle
objekt.
• Asset management – AM je nadgradnja configuration managementa sa fokusom na
financijske parametre i životni vijek CI-ja
o Ugovori o održavanju
o Jamstva
o Praćenje statusa CI-ja
o Životni vijek CI-ja
• Business relationship management – praćenje odnosa prema korisniku
o Anketiranje nakon ticketa
o On-demand survey
o Obrada pritužbi
o Analize podataka i izvještaji
o Razmjena podataka s CRM aplikacijom
• Supplier management – prati utjecaj UC-a pružatelja usluga koji service provideru pomažu u
Service Managementu na kvalitetu isporuke usluga
• Knowledge management – referira na KM funkcionalnu specifikaciju u SP Online.
• Administracija – Administracija aplikacije
o Company – podaci o tvrtkama korisnicima
▪ Division – podaci o organizacijskim jedinicama tvrtke korisnika (parent-chid
stablo)
▪ Person – podaci o svim korisnicima aplikacije – nema potrebe odvajati
operatere od korisnika, to se rješava rolama
▪ Prava – prava pojedinih korisnika na pojedine module aplikacije, po CRUD
principu.
▪ Role - skupine definiranih prava kao templatei za dodjeljivanje korisnicima
• Profili
o Generalna prava
o Prava za browse, edit i pozivanje komandi.
o Postavke notifikacija
▪ Kompetencije – detalji na zapisu osoba koje mogu biti zadužene na ticketima,
dodaju se kompetencije sa popisa kompetencija (vidi Ostalo) uz ocjenu 1-3
o Ticketi
▪ Statusi
▪ Kategorije
▪ Prioriteti – matrica 3x3 (Impact x Urgency) sa editabilnim vrijednostima unutar
matrice
▪ Resolution kodovi
Opis projekta 15/35

• Resolved – Successful
• Problem was by designed
• Could not reproduce
• Out of scope
• Customer resolved
• ...
▪ Tipovi aktivnosti za detalje ticketa: mogu imati oznaku „System“ i tada se ti
detalji ne prikazuju defaultno u ticketu, već samo ako se odabere checkbox
„System“ u zaglavlju
• Note – ažuriranje ticketa kroz GUI
• Field change – za logiranje promjene vrijednosti polja
• Mail in/Mail out – evidencija dolaznih mailova i odlaznih notifikacija
• Clock start / Clock stop – vezano za statuse ticketa, clock se uključuje
kod otvaranja ticketa i kod svakog mjerljivog statusa (Work in
progress) a isključuje kod svih Pending i Escalated statusa. Služi za
mjerenje TTR – Time to resolve. Status zapisi imaju boolean podatak
OnClockkoji govori mjeri li se vrijeme provedeno u njemu ili ne.
• ...
▪ Time to close - Podatak nakon koliko sati provedenih u „Resolved“ statusu se
incident automatski zatvara.
o Ostalo
▪ Assignment grupe – tehnološke kompetencijske grupe
▪ Popis kompetencija – tehnološke kompetencije
▪ Tipovi ugovora
▪ Zemlje
▪ Gradovi
▪ Kalendar (neradni dani po zemljama)
▪ Jezici
▪ Mail templatei
• Za krajnje korisnike
o Otvoren ticket
o Ažuriran ticket
o Riješen ticket
o Zatvoren ticket
o Ponovno otvoren ticket
• Za zadužene osobe
o Slično kao za krajnje korisnike
▪ Ankete
• administracija anketnih pitanja
• frekvencija kojom će se slati mailovi za obavijest o anketi, po svakoj
vrsti ticketa – nakon
o svakog
o svakog drugog
o svakog trećeg
o svakog četvrtog ticketa
o ...
▪ Grafičke teme
• Mobilna aplikacija
o Pregled ticketa prijavljenih od strane korisnika, ili svih ticketa na razini i ispod njegove
poslovne organizacijske jedinice
o Prijava incidenta/zahtjeva – jednostavno sučelje za prijavu incidenata i/ili zahtjeva
o Ažuriranje – mogućnost ažriranja prijavljenih ticketa
Opis projekta 16/35

o Praćenje tijeka riješavanja – notifikacije o tijeku rješavanja ticketa

o Pretplata – mogućnost pretplate na notifikacije o događajima na ticketima odabranim
po kriterijima vrijednosti ključnih polja, a u skladu s ovlastima korisnika
12. Pretpostavke i utjecaji

Kako je rečeno u viziji/dosegu projekta, aplikacija će u prvom redu biti namijenjena postojećim korisnicima
Span IT usluga kojima će se nuditi kao jednostavan alat za obradu ključnih ITSM procesa.
Slijedom toga, aplikacija mora biti osmišljena za što kraću krivulju učenja. „No manual“ pristup nije u
potpunosti ostvariv na standardnom GUI klijentskom okruženju jer se ipak radi o kompleksnim procesima
za koje će vjerojatno korisniku trebati „bundlati“ i konzalting za ITSM. Dijelovi aplikacije kao što su
Customer portal i mobilna aplikacija moraju biti maksimalno pojednostavljeni i intuitivni, dakle ovdje „No
manual“ ima smisla. Bit će potrebno dobro surađivati sa dizajnerskim resursima iskusnim u kreiranju
funkcionalnih sučelja.
S obzirom na strateško opredjeljenje Spana, aplikacija bi trebala biti orijentirana na cloud tehnologije. Ovo
se može pokazati tehnološkom preprekom uslijed mladosti tehnologije i učestalih promjena koje se
događaju na cloud platformama. Također, jedan dio potencijalnih korisnika htjet će imati aplikaciju „on
premise“, pa i o tome treba voditi računa.
Aplikacija bi terbala biti otvorena za razmjenu podataka sa sličnim aplikacijama ili drugim instancama iste
aplikacije. Podaci koji se među aplikacijama razmjenjuju su uglavnom pojedinačni ticketi (Incident, change,
problem...) u slučajevima kada se ovi eskaliraju među raznim poslovnim subjektima. Način razmjene
trebao bi biti standardan i transparentan, dakle kroz poznate i provjerene tehnologije. Ovdje bi trebalo
angažirati developere koji su surađivali na projektima razmjene podataka (MORH, AZO, Infosys
sinkronizacija...)
SSD bi trebao u kasnijim fazama nekako biti povezan na alate za nadzor i upravljanje infrastrukturom
(SCOM, SCCM) kako bi se mogla održavati ažurne informacije o infrastrukturnim elementima (CMDB-
Configuration management database) te kako bi se u određenim uvjetima mogli automatski otvarati
incidenti za slučaj specifičnih problema u radu infrastrukture (Low disk space, hartbeat failuire). Ovo će
zahtijevati suradnju sa djelatnicima iz odjela supporta i infrastrukture koji poznaju prirodu podataka i
ponašanja sustava.
Procesi kojima se SSD bavi naslanjaju se na ITIL najbolje prakse i uglavnom su izravno izvedeni iz
ISO/IEC20000, tu će trebati surađivati sa kompetentnim djelatnicima iz tog područja.
13. Konceptualni dizajn

Span SSD inicijativa nastala je potaknuta pojačanim zanimanjem nekih ključnih korisnika Span Supporta za
znanjima, vještinama i alatima u domeni IT Service Managementa. Pokazalo se da korisnici prepoznaju
iskustva i kompetencije Spana u ovom području, te da su neki od njih spremni prepustiti Spanu razvoj
alata za ITSM.
SSD će tehnološki biti zasnovan na Microsoft tehnologijama, s naglaskom na cloud okružje. Konkretne
tehnologije koje će se koristiti su MS SQL Server, Azure, Sharepoint, HTML.
Opis projekta 17/35

13.1. Alternativni koncepti

13.1.1. Microsoft System Center Service Manager
SCSM je plod dugotrajnog razvoja alata unutar System Center obitelji, koji nažalost nije polučio velike
rezultate na svjetskom, a pogotovo na domaćem tržištu. Dosta korisnika sa dominantno MS
infrastruktirom je dugo čekalo MS proizvod koji će biti integriran u System Center obitelj.
• Prednosti – Integriranost sa SC proizvodima, poznati dobavljač.
• Nedostatci – Složena implementacija, neizvjestan roadmap proizvoda.
13.1.2. Service Desk proizvodi iz gornjih kvadranta Gartnerovih izvješća

Riječ je o leadeerima i challengerima: Service Now, BMC Remedy, Cherwell itd. Ovo su zreli flagship
proizvodi namijenjeni velikim organizacijama kojima je Service Management core business. Također,
ciljane su i velike korporacije kojima interni IT odrađuje servoce management s velikim volumenom ticketa
i issuea.
• Prednost – zreli, provjereni proizvodi sukladni najboljim praksama i standardima
• Nedostatci – cijena, složena i dugotrajna implemantacija
13.1.3. Jeftina i „besplatna“ open source rješenja

Postoji nekoliko otvorenih rješenja na tržištu.
• Prednost – besplatno, brzi start
• Nedostaci – Span nije dio open source community-ja
14. Logički dizajn

Ovdje će ukratko biti opisani osnovni objekti i njihova ponašanja.
Incident management
Glavna zadaća IM-a je ponovno uspostavljanje usluge, što je prije moguće.
Incident ticket može biti u nekoliko statusa:
Opis projekta 18/35

Incident je u statusima:
• Open – kada je tek otvoren
• Work in progres – nakon prve pohrane od strane zadužene osobe
• Pending – vrijeme provedeno u ovom statusu ne broji se u računanju TTR-Time To Resolve:
o Vendor – čeka se na response od dobavljača usluge, softvera, hardvera
o Customer – čeka se na response korisnika
o Escalated – incident je eskaliran vendoru ili 3rd party pružatelju usluga
• Resolved – kada zadužena osoba zaključi da je incident riješen i usluga vraćena korisniku
• Closed – kada korisnik potvrdi da je usluga OK ili nakon što prođe dogovoreno vrijeme bez
primjedbe korisnika
Iz incidenta mogu nastati:
• Change ticket – kada je za rješavanje incidenta potrebno izvesti izmjene na infrastrukturi. Obično
su to hitne izmjene kod rješavanja Major incidenta, ali mogu biti i standardne i normalne izmjene
za rješavanje desktop i sistemskih incidenata.
• Problem – kao skriveni uzr5ok jednog ili više incidenata ili kao ticket koji se otvara radi istraživanja
i izvještavanja uzroka i rješenja Major incidenta.
• Knowledge article – kao rezultat rješenja incidenta pri kojemu su primijenjena nova rješenja i
spoznaje.
Incident management dobiva informacije od
• Asset i configuration management – podaci o infrastrukturi, ugovorima i SLA parametrima
• Problem i Knowledge management – mogućim workaroundima i permanentnim rješenjima
• Configuration management – o stanju infrastrukturnih elemenata
O korištenim poljima:
• Kontakt osoba: osnovni podaci o osobi, ovo je customer koji ima pristup portalu, dakle, ime,
prezime, korisničko ime i password, kontakt podaci, sve se nalazi u tabeli Person, veza na
Customer (company) tablicu i na tablicu OrgUnit – hijerarhijsku organizacijsku tablicu.
• Customer (Company): podaci o tvrtki korisnika ili divisionu korisnika ako se support pruža unutar
korporacije.
• OrgUnit: ovo je tabela hijerarhijskih organizacijskih jedinica vezana na Customer ID. Na nju se
vežu kontakt osobe da znamo gdje su i da im možemo ograničiti pregled događaja samo na
podatke njihove organizacijske jedinice.
• Prioritet – bira se unutar matrice 3x3 u kojoj je jedna os Impact a druga Urgency, obično je
vrijednost 1-5, nekad 1-4 ili 1-6. Administrira se na način da se postavi matrica u
administracijskom modulu koja se popuni vrijednostima i to onda vrijedi za sve Customere.
Vremena reakcije i rješavanja ticketa po prioritetu se onda može štimati po Customeru kroz SLA
zapise. Primjer:
Opis projekta 19/35

Impact
Urgency 1 2 3
1 1 2 3
2 2 3 4
3 3 4 5
• Servis: Servis odnosno usluga je ono što pružamo korisniku. Dakle, održavanje AD-a,
Sharepointa, SQL-a ili specijaliziranih servisa kao što su PKI, GAM, MORE itd. Ovi servisi popisani
su u generalnom katalogu poslovnih usluga. Svaki od njih ima defaultne postavke kao što su
kategorije i SLA parametri. Pri dodjeljivanju servisa customeru bira se hoće li se pratiti ovi
defaultni parametri ili će se oni „overridati“ prilagođenim parametrima koje korisnik izričito traži.
• Ovi servisi vezani su na korisnika a inače se nalaze u vrhu hijerarhije CMDB-a (Configuration
Management DataBase-a) kao krovni Configuration Item (CI – osnovni građevni element CMDB-
a) na koji pokazuju oni CI-jevi koji čine tu uslugu: Serveri, mrežna oprema, software itd. Servis
ima proizvoljni broj CI-jeva. Jedan CI može činiti više servisa.
• Kategorija: Kategorije su po volji duboko stablo ispod svakog servisa. Tvrtke koje nemaju servise
imat će servis N/A ili Default koji će imati defaultne kategorije.
Svaka kategorija imat će opisni dio u kojemu će se definirati kratka checklista ili uputa za SD
djelatnika što treba napraviti, koga treba obavijestiti ili pitati, dakle proceduralni info. Npr: kod
kategorije Request/EnableVPN za određenog korisnika, opis će sadržati proceduru i način
odobravanja za VPN konekciju, eventualno popis ljudi koji smiju tražiti i link na proceduru. Ovaj
description pojavit će se po odabiru kategorije negdje na ticketu i moći će ga se „isključiti“.
Primjer za jednu tvrtku:
Usluga Kategorije
VPN • Request
o Create VPN
o Enable VPN
o Disable VPN
• Problems with VPN
• ...
Sharepoint • Request
o Add rights
o Remove rights
o Create list
o Create library
• Problems with SP
• ...
Active Directory • Request

o Account
▪ Create
▪ Disable
▪ Change
o Group
▪ Create
▪ Disable
▪ Change
o ...
•
Default • HW
o NW Equipment
▪ Replacement
Opis projekta 20/35

▪ Configuration
▪ ...
o Server
▪ ...
o PC
▪ ...
• SW
o Server
▪ Microsoft
• SQL
• Exchange
• ..
o Client
▪ ...
• Asset: – širi pojam koji se kod nas za sada može smatrati sinonimom za CI. U jednom aspektu
najboljih praksi Asset management je Configuration Management proširen za set znanja o
financijskim i lifecycle parametrima CI-ja: jamstvo, amortizacija, leasing ugovor itd. Još sam u
dilemi hoćemo li ovo zvati CI ili Asset. CI ima nekoliko glavnih polja: Naziv, AssetTag, Opis,
ParentCI.
Odnosi CI-jeva, usluga, SLA-ova:
1 Odnosi entiteta u CMDB-u
• Assignment group:-grupa inženjera zadužena za određene usluge ili kategorije usluga. Grupe se
pune ljudima (potencijalnim Assignee-jima)prema tehnološkim kompetencijama. Praksa u
ovakvim aplikacijama je da se ovo polje, ako je prazno, puni automatski odabirom servisa ili
kategorije.
• Assignee: Osoba iz Assignment grupe, također iz tabele Person. Ne može se odabrati dok nije
odabrana Assignment grupa. Može se odabrati samo među članovima grupe.
• Vrsta incidenta: za početak samo 3 vrijednosti: Downtime, Service degraded ili Possible
downtime. Služi za izračun koliko je usluga bila down za računanje SLA parametara. Lista će se
možda proširiti sa još par vrijednosti s vremenom.
Opis projekta 21/35

• OpenDateTime, ResolveDateTime, CloseDateTime vremena će biti logirana u detailima ali se

čuvaju i na master recordu radi reportinga. Za vrijeme rješenja ticketa izračunava se i TTR koji se
čuva na masteru jer se po njemu dosta izvještava. Paziti da se TTR briše kod Reopen ticketa.
• Resolution comment i Close comment su dva obavezna polja za update kroz GUI.
• Resolution code je obaveznno polje kod promjene statusa u Resolved, vezano na šifrarnik sa
tipičnim vrijednostima SUCCESSFUL, OUT OF SCOPE, USER FIX, ESCALATED...
• Detalji incidenta (važi za sve tickete)
o Bilješka (Note): kod svakog updatea kroz GUI čuva se bilješka (description), tko je
ažurirao i kada. Ova detail tablica može se kao objekt koristiti za čuvanje ostalih vrsta
detalja, tako da se koristi polje ActivityType vezano na šifrarnik Activities. Tipične
vrijednosti su: GUI Update, Mail Sent, Mail received, Field changed, Reassigned...
o Log: čuva podatke o promjenama master polja i događajima na ticketu
o Notifications: Logira sve mail notifikacije, odlazne i dolazne – tko je poslao, kome su
poslane, kada, sadržaj maila
o Attachments – podaci o tome tko je i kada dodao privitak na ticket. Idealno je da se sami
fajlovi čuvaju u file sistemu na serveru ili na sharepoint library-ju, sa istim imenom sa
kojim su došli + prefix=broj ticketa. Time se olakšava pretraga i pojednostavljuje backup.
o Task: Tko i do kada treba napraviti nešto. Funkcionalnost taska može u raznim fazama
biti različite složenosti, od jednostavnog recorda do funkcionalnosti radnog naloga.
o Approval: incidenti u ovoj fazi nemaju odobrenja ali kad spominjemo detalje ticketa,
neka i njih: odobrenja mogu biti višestruka, dakle čeka se da više osoba odobri ticket
prije nego može otići u obradu. Nema razloga za serijsko/paralelno odobravanje, sva
mogu biti istovremena. No, postojat će kod nekih korisnika potreba za fancy opcijama
tipa Financijsko odobrenje daje jedna osoba, ali Poslovno odobrenje može dati bilo koja
od ove tri osobe. Za sada svi odobravatelji idu u jedan container i ticket je odobren tek
kad svi odobre, ali treba razmisliti o rješenju koje će omogućiti dodavanje grupa
odobravatelja sa ANY/ALL opcijom.
• Pregledi (viewovi) će imati pretražni ekran nešto kao:
Opis projekta 22/35

Primjer iz Service Now:
Ponašanja objekata ostalih procesa prve faze slijedit će u dobroj mjeri ponašanja objekata
Incident management pocesa i bit će definirana kroz interaktivne sessione SCRUM-like sprint i
dnevnih sastanaka i storyboarda.
Opis projekta 23/35

14.1. Scenariji: Incident management

14.1.1. Scenarij: Kreiranje incidenta
Naziv Kreiranje incidenta

Korisnik SD Operater
Preduvjeti SD Operater je ulogiran u aplikaciju i nalazi se na Home pageu
Tijek aktivnosti • Korisnik bira opciju NOVI INCIDENT
• Aplikacija otvara panel za unos podataka novog incidenta
• Korisnik unosi podatke o novom incidentu
o Kontakt osoba – Jedna od osoba tvrtke korisnika koja ima plrava
prijaviti incident. Moguće je odabrati prvo tvrtku pa onda osobu
unutar nje, aplikacija podatke o korisniku i njegovoj tvrtki
pohranjuje u incident „Read only“
o Osoba za koju se prijavljuje incident (opcionalno) – osoba koja
nije na popisu osoba koje mogu tražiti incident ili osoba koja
trenutno nema tehničkih uvjeta za prijavu incidenta, ali je usluga
namijenjena njoj i treba joj slati obavijesti o stanju zahtjeva
o Predmet (Title) – slobodni kratki tekst naslova incidenta
o Opis – dugi opis incidenta
o Prioritet se odabire iz matrice 3x3 (Impact x Urgency) sa
popunjenim administriranim vrijednostima
o Servis – IT usluga iz Kataloga usluga vezana na tvrtku Kontakt
osobe
o Kategorija – bira se iz stabla kategorija dodijeljenog na odabranu
uslugu
o Asset – Bira se iz popisa Asseta (Configuration Itema) vezanih na
Kontakt osobu i Servis ako je odabran. Korisnik može proširiti listu
za odabir na SVE Assete odabrane tvrtke Kontakt osobe
o Zadužena grupa (Assignment group) – grupe su tehnološki
fokusirane i vezane na Servis i Kategoriju, ako je polje prazno,
popunjava se vrijednošću iz Servisa ili Kategorije
o Zaduženi djelatnik (Assignee) – bira se među članovima
Zadužene grupe
o Vrsta incidenta: Downtime, Service degraded ili Possible
downtime.
▪ Početak utjecaja (Date/Time)
▪ Kraj utjecaja (Date/Time)
• Korisnik bira opcjiu SAVE
• Aplikacija će u ovisnosti o odabranom servisu i SLA na ticketu popuniti
dva date/time polja Respond by i Resolve by
• Aplikacija zatvara panel za unos podataka, pohranjuje podatke o novom
incidentu i šalje mail notifikacije zainteresiranim kontaktima u skaldu s
predefiniranim mail obrascima:
o Assignee – kratka poruka o dodjeli incidenta
o ako assignee nije dodijeljen incidentu, mail se šalje manageru
Assignment grupe
o Kontakt osoba – dulji mail s podacima o novom incidentu
o KAM – zaposlenik definiran kao KAM za tvrtku korisnika
o TAM – zaposlenik definiran kao TAM za navedenu uslugu kod
korisnika
Opis projekta 24/35

o Svim osobama pretplaćenim na obavijesti o incidentima

o Svim zaposlenicima koji imaju taskove na ticketu u statusu Work
in progres
Završno stanje Incident je pohranjen u statusu „Open“
Alternativni • Ako pri unosu podataka nema zapisa o Kontakt osobi, Korisnik ih ovisno o
scenariji ovlastima, može unijeti kroz panel za brzi unos korisnika
• Ako se ne odabere Servis, kod odabira kategorija prikazuje se neko defaultno
stablo kategorija koje nije vezano ni na jedan Servis, a asseti se biraju vezano
na Kontakt osobu ili prošireno na Tvrtku korisnika
• Korisnik tijekom kreiranja incidenta može dodati bilo koji file kao attachment
na ticket
• Korisnik tijekom kreiranja incidenta može kreirati Task vezan na incident, koji
ima zaduženu osobu i datum izvršenja.
• Nakon što korisnik popuni proizvoljni broj polja i kreira task(ove), može
pohraniti ticket kao javni ili privatni template pomoću kojega će u budućnosti
kreirati nove tickete
• Sukladno tome, korisnik u može kreirati Incident odabirom opcije Create
incident from template i odabrati jedan od ponuđenih prethodno spremljenih
templatea.
Frekvencija 300 dnevno
14.1.2. Scenarij: Ažuriranje incidenta
Naziv Ažuriranje (update) incidenta

Korisnik SD Operater ili zadužena osoba
Preduvjeti Korisnik je ulogiran u aplikaciju i nalazi se na panelu za pregled incidenata
Tijek aktivnosti • Korisnik bira željeni incident
• Aplikacija otvara incident u Edit modeu
• Korisnik unosi novu bilješku i mijenja sadržaj željenih polja.
• Korisnik bira opciju SAVE
• Aplikacija
o sprema bilješku
o logira promjenu sadržaja polja
o šalje notifikacije zainteresiranim osobama
o zatvara panel za ažuriranje ticketa
Završno stanje Incident je pohranjen sa novim podacima u statusu Open
Alternativni • Ako je incident prvi puta ažurirao Assignee, a prethodno je bio u statusu
scenariji Open, i podatak o statusu nije mijenjan, ticket se sprema sa statusom Work in
progress
• Korisnik tijekom ažuriranja može dodati bilo koji file kao attachment na ticket.
OVO VRIJEDI ZA SVE DALJE NAVEDENE TICKETE.
• Tijekom ažuriranja u Edit modeu korisnik osim master polja može vidjeti i
tabelarni prikaz svih detail polja – bilješke, logove, taskove, odaslane i
primljene mailove... odabirom na zaglavljima tabele može sortirati i filtrirati
tabelarni prikaz. Može otvarati pojedine detail zapise i u skladu s ovlastima ih
editirati ili brisati. Ovo je isto za sve dalje navedene vrste ticketa.
Opis projekta 25/35

• Tijekom ažuriranja incidenta mogu se kreirati ticketi vezani na njega, u koje će

inicijalno biti prenijeti osnovni podaci o korisniku, vrsti usluge i kategoriji.
Ticketi će biti otvoreni u edit modu i njihova dalja obrada opisana je u
njihovim Use Caseovima. Ticketi se kreiraju odabirom opcije
o RELATED CHANGE (u fazi 2)
o RELATED PROBLEM
o RELATED REQUEST
• Svaki put kada se ažurira ticket vezan na druge tickete, istim komentarom
ažuriraju se i ticketi u relaciji s njime i zainteresirane osobe dobivaju mail.
• Bilo koja zainteresirana osoba može odgovoriti na mail notifikaciju, ovo će
automatski ažurirati incident. Cijeli tekst maila upisuje se u polje Opis na retku
ažuriranja a attachmenti maila se pohranjuju kao attachmenti incidenta (ovdje
jako paziti na moguće petlje)
• Ticket može ažurirati i Kontakt osoba ili ovlaštena osoba korisnika kroz
Customer portal jednostavnom bilješkom
• Tijekom prikaza incidenta u detail panelu vide se u posebnim odjeljcima
skupine tabelarnih podataka: Notes(updatei), Log (povijest promjena
vrijednosti polja), odlazne/dolazne mail notifikacije; Taskovi, Attachmenti,
Related tickets. Moguće je na zaglavljima tabela izvoditi standardne operacije
Sort Asc/Desc i Filter
Frekvencija 100/h
14.1.3. Scenarij: Rješavanje incidenta
Naziv Rješavanje incidenta

Tijek aktivnosti • Korisnik bira željeni incident
• Korisnik bira opciju RESOLVE
• Aplikacija otvara panel sa obaveznim podacima za unos
o Kraj utjecaja (Date/Time)
o Resolution code (odabir jedne od ponuđenih opcija)
o Resolution description – dugi tekst
• Korisnik unosi podatke i bira opciju SAVE
• Aplikacija sprema podatke o incidentu, izračunava vrijeme rješavanja TTR
(TimeToResolve = ResolveTime-OpenTime–Pending times), obavještava
zainteresirane osobe i zatvara panel incidenta
Završno stanje Incident je spremljen sa statusom Resolved
Alternativni • Korisnik po unosu odabranih podataka može označiti polje Knowledge base
scenariji candidate. Aplikacija šalje mail obavijest osobi administriranoj kao Knowledge
manager
14.1.4. Scenarij: Zatvaranje incidenta
Naziv Zatvaranje incidenta

Korisnik SD operater
Opis projekta 26/35


Tijek aktivnosti • Korisnik bira željeni incident koji je u statusu Resolved
• Korisnik bira opciju CLOSE
• Aplikacija otvara panel sa poljem za unos komentara zatvaranja
• Korisnik unosi komentar i bira opciju SAVE
• Aplikacija sprema podatke o incidentu, obavještava zainteresirane osobe i
zatvara panel incidenta
• Aplikacija korisniku šalje email sa linkom na anketni panel na internetu na
kojemu korisnik može ocijeniti svoje zadovoljstvo. Mail se ne šalje svim
korisnicima već ovisno o postavkama u administraciji (Svaki, svaki drugi, svaki
treći...)
Završno stanje Incident je spremljen sa statusom Closed
Alternativni • <Napomena> Gornji happy path je zapravo izuzetak i omogućuje operateru
scenariji da zatvori riješeni ticket po odobrenju tj. potvrdi korisnika telefonom ili
mailom. Riješeni ticketi se u 99% slučajeva zatvaraju automatski po sljedećem
scenariju:
o Posebnaprocedura jednom dnevno ili svakih sat vremena traži sve
tickete koji su resolvani (riješeni) prije administracijom postavljenog
broja sati (kod nas 48) i prebacuje ih u status Closed sa komentarom
„Closed automatically“.
o Mail na anketni panel šalje se kao gore.
Frekvencija 300/d
14.1.5. Scenarij: Reopen incidenta
Naziv Reopen (ponovno otvaranje) incidenta

Korisnik SD operater, Kontakt osoba
Tijek aktivnosti • Korisnik bira željeni incident koji je u statusu Resolved ili Closed
• Korisnik bira opciju REOPEN
• Aplikacija otvara panel sa poljem za unos komentara pnovnog otvaranja
• Aplikacija mijenja status incidenta u Work in progress, sprema podatke o
incidentu, obavještava zainteresirane osobe i zatvara panel incidenta
Završno stanje Incident je spremljen sa statusom Work in progres
Alternativni • Reopen može napraviti i kontakt osoba kroz Customer portal
scenariji
Frekvencija 300/d
14.1.6. Scenarij: Pregled incidenata
Naziv Pregled incidenata

Korisnik SD operater ili zadužena osoba
Opis projekta 27/35

Tijek aktivnosti • Korisnik se nalazi u tabelarnom pregledu incidenata sa karakterističnim

poljima: INC#; Priority; Title; OpenDate; Status; Service; Category; Customer;
Contact; Assignee...
• Korisnik u navigacijskom panelu bira predefinirane poglede (view-ove) na
incidente (My open incidents; Incidents for my groups; My TAM incidents)
• Aplikacija prikazuje odabrane tabelarne preglede za odabrani view
• Korisnik bira opciju NAPREDNO PRETRAŽIVANJE
• Aplikacija otvara panel za napredno pretraživanje u kojemu se mogu birati
vrijednosti svih ključnih polja
• Korisnik unosi granične i sadržajne vrijednosti ključnih polja i bira opciju APPLY
• Aplikacija tabelarno prikazuje rezultat pretrage
• Korisnik bira opciju SAVE VIEW AS
• Aplikacija prikazuje panel za unos naziva pregleda i oznake privatnosti
• Korisnik unosi naziv pregleda i ostavlja oznaku PRIVATNO neoznačenu
• Aplikacija sprema javni pregled (Public view) incidenata, zatvara panel za
napredno pretraživanje, otvara panel za pregled incidenata sa prikazanim
zadnjim kreiranim pregledom
Završno stanje Korisnik je sretan kao malo dijete. Spremljeni view vidljiv je unavigacijskom panelu
javnih viewova
Alternativni • Korisnik može spremiti pregled sa označenim poljem PRIVATNO, i u tom
scenariji slučaju vidi ga samo on, i prikazan je u navigacijskom panelu privatnih
viewova
• U tabelarnom pregledu korisnik može standardnim akcijama na zaglavlju
sortirati i filtrirati incidente.
• Kada ima prikazan tablični pregled, Korisnik u svakom trenutku može
pokrenuti eksport prikazanih podataka u .csv ili .xls file
• Prilikom kreiranja novog view-a, korisnik može mijenjati redoslijed kolona
tabele te brisati i dodavati kolone.
Frekvencija Pristup viewovima jako često, pohrana viewova jako rijetko
14.2. Scenariji: Request fulfilment

14.2.1. Scenarij: Kreiranje zahtjeva SD
Naziv Kreiranje zahtjeva

Korisnik SD operater
Preduvjeti Korisnik je ulogiran u aplikaciju i nalazi se na home panelu
Tijek aktivnosti • Korisnik mailom ili telefonski zaprima zahtjev kontakt osobe korisnika.
• Korisnik bira opciju NEW REQUEST
• Aplikacija otvara panel za unos zahtjeva
• Korisnik unosi podatke zahtjeva:
o Kontakt osoba – Jedna od osoba tvrtke korisnika koja ima prava
prijaviti zahtjev. Za svaku uslugu i request unutar nje postojat će
popis osoba koje imaju pravo tražiti request. Moguće je odabrati
prvo tvrtku pa onda osobu unutar nje, aplikacija podatke o korisniku i
njegovoj tvrtki pohranjuje u request „Read only“
Opis projekta 28/35

o Osoba za koju se prijavljuje zahtjev (opcionalno) – osoba koja nije na

popisu osoba koje mogu tražiti request, ali je usluga namijenjena njoj
i treba joj slati obavijesti o stanju zahtjeva
o Predmet (Title) – slobodni kratki tekst naslova zahtjeva
o Opis – dugi opis zahtjeva
o Prioritet se odabire iz matrice 3x3 (Impact x Urgency) sa popunjenim
administriranim vrijednostima
o Servis – IT usluga iz Kataloga usluga vezana na tvrtku Kontakt osobe
o Kategorija – bira se iz stabla kategorija dodijeljenog na odabranu
uslugu. Kod service requesta bit će popis vrsta requesta koje korisnik
može tražiti
o Asset – Bira se iz popisa Asseta (Configuration Itema) vezanih na
Kontakt osobu i Servis ako je odabran. Korisnik može proširiti listu za
odabir na SVE Assete odabrane tvrtke Kontakt osobe. Ovdje bi bilo
dobro da se prilikom izbora asseta tj. CI-ja može birati kroz neki
grafički prikaz stabla ovisnosti CI-ja. Na master dijelu requesta bira se
primarni asset, a na detail dijelu moguće je dodati više dodatnih
asseta vezanih za pojedini request
o Zadužena grupa (Assignment group) – grupe su tehnološki
fokusirane i vezane na Servis i Kategoriju, ako je polje prazno,
popunjava se odabirom defaultne vrijednosti iz Servisa ili Kategorije
o Zaduženi djelatnik (Assignee) – bira se među članovima Zadužene
grupe
• Korisnik kreira jedan ili više Taskova za request, unosi kratki opis taska,
date/time do kada trebaju završiti i dodjeljuje ih grupama i assigneejima
• Korisnik na odjeljku Approval dodaje jednu ili više osoba koje trebaju odobriti
Request
• Korisnik bira opcjiu SAVE
requestu i šalje mail notifikacije zainteresiranim kontaktima u skaldu s
o Assignee – kratka poruka o dodjeli requesta
o Approveri – osobe navedene u odjeljku Approval – dobivaju link na
dio aplikacije gdje mogu pregledati zahtjev i jednostavno ga odobriti
ili odbiti
o ako assignee nije dodijeljen requestu, mail se šalje manageru
Assignment grupe
o Kontakt osoba – dulji mail s podacima o novom requestu
korisnika
o Svim osobama pretplaćenim na obavijesti o requestima
o Svim zaposlenicima koji imaju taskove na ticketu u statusu Work in
progres
Završno stanje Request je pohranjen s novim podacima u statusu Open
Alternativni • Ako je u odjeljku Approval navedena makar jedna osoba, Request se sprema
scenariji u statusu Pending approval
pohraniti request kao javni ili privatni template pomoću kojega će u
budućnosti kreirati nove requeste
Opis projekta 29/35

• Sukladno tome, korisnik u može kreirati request odabirom opcije Create

request from template i odabrati jedan od ponuđenih prethodno spremljenih
templatea. Vremena u Taskovima računat će se relativno od kreiranja
incidenta.
• Task može imati prethodni task, dakle mogu biti stablaste strukture za
paralelno-serijsko izvršavanje. Taskovi čiji prethodnici nisu još završili su u
statusu Pending previous.
Frekvencija Do 300 dnevno
14.2.2. Scenarij: Ažuriranje zahtjeva
Naziv Ažuriranje zahtjeva

Korisnik SD operater ili zaduženi inženjer
Preduvjeti Korisnik je ulogiran u aplikaciju na panelu za pregled zahtjeva (Requesta)
Tijek aktivnosti • Korisnik bira željeni request
• Aplikacija otvara request u Edit modeu
• Aplikacija:
o sprema bilješku
o zatvara panel za ažuriranje ticketa
Završno stanje Request je pohranjen sa novim podacima
Alternativni • Nakon što je request prvi puta ažurirao Assignee, a prethodno je bio u statusu
scenariji Open, ticket se sprema u statusu Work in progress
• Zaduženi inženjer ili kontakt osoba mogu ažurirati Request mail reply-jem na
mail notifikaciju pristiglu iz Requesta. Aplikacija će unijeti novi detail redak u
Request sa komentarom
• Bilo koja zainteresirana osoba može odgovoriti na mail notifikaciju, ovo će
automatski ažurirati Request dodavanjem novog retka u detail tabeli. Cijeli
tekst maila upisuje se u polje Opis na retku ažuriranja a attachmenti maila se
pohranjuju kao attachmenti incidenta (ovdje jako paziti na moguće petlje)
• U vrijeme ažuriranja moguće je kreirati nove taskove i ažurirati postojeće.
• Osoba zadužena na Tasku koji je u statusu Active može ažurirati task novim
komentarom koji će se dodati na activity log Taska.
• Osoba zadužena na tasku koji je u statusu Active može zaključiti task unosom
komentara zatvaranja i biranjem opcije Close. Aplikacija će promijeniuti status
Taska u Closed, a taskove kojima je ovaj Task „parent“ prebaciti iz statusa
Pending previous u Active i poslati mail notifikacije njihovim zaduženim
osobama
14.2.3. Scenarij: Rješavanje zahtjeva
Naziv Rješavanje zahtjeva

Preduvjeti Korisnik je ulogiran u aplikaciju i nalazi se na panelu za pregled requesta
Opis projekta 30/35

Tijek aktivnosti • Korisnik bira željeni request

• Korisnik bira opciju RESOLVE
• Aplikacija otvara panel sa obaveznim podacima za unos
o Resolution code (odabir jedne od ponuđenih opcija)
o Resolution description – dugi tekst
• Korisnik unosi podatke i bira opciju SAVE
• Aplikacija sprema podatke o incidentu, izračunava vrijeme rješavanja TTR,
obavještava zainteresirane osobe i zatvara panel incidenta
Završno stanje Request je pohranjen sa statusom Resolved
Alternativni • Ako su u trenutku resolva postojali Taskovi koji nisu u statusu Closed, aplikacija
scenariji ih prebacuje u Closed i obavještava njihove assignee-je mailom o tome, sa
tekstom opisa rješenja.
14.2.4. Scenarij: Zatvaranje zahtjeva
Naziv Zatvaranje zahtjeva

Korisnik SD Operater
Preduvjeti Korisnik je ulogiran u aplikaciju i nalazi se na panelu za pregled requesta
Tijek aktivnosti • Korisnik bira željeni request koji je u statusu Resolved
• Korisnik bira opciju CLOSE
• Aplikacija otvara panel sa poljem za unos komentara zatvaranja
• Aplikacija sprema podatke o requestu, obavještava zainteresirane osobe i
zatvara panel requesta
• Aplikacija korisniku šalje email sa linkom na anketni panel na internetu na
kojemu korisnik može ocijeniti svoje zadovoljstvo. Mail se ne šalje svim
korisnicima već ovisno o postavkama u administraciji (Svaki, svaki drugi, svaki
treći...)
Završno stanje Request je spremljen sa statusom Closed
Alternativni • <Napomena> Gornji happy path je zapravo izuzetak i omogućuje operateru
scenariji da zatvori riješeni ticket po odobrenju tj. potvrdi korisnika telefonom ili
mailom. Riješeni ticketi se u 99% slučajeva zatvaraju automatski po sljedećem
scenariju:
• Posebnaprocedura jednom dnevno ili svakih sat vremena traži sve tickete koji
su resolvani (riješeni) prije administracijom postavljenog broja sati (kod nas 48)
i prebacuje ih u status Closed.
• Mail na anketni panel šalje se kao gore.
Frekvencija <Očekivana frekvencija događaja opisanog UseCase-om, npr 5-10 puta dnevno,
60 puta u minuti...>
14.2.5. Scenarij: Reopen zahtjeva
Naziv Reopen (ponovno otvaranje) zahtjeva

Korisnik SD operater, Kontakt osoba
Preduvjeti Korisnik je ulogiran u aplikaciju i nalazi se na panelu za pregled zahtjeva
Opis projekta 31/35

Tijek aktivnosti • Reopen scenarij je identičan Reopen scenariju Incidenta
Završno stanje Request je spremljen sa statusom Work in progres

Alternativni • Reopen može napraviti i kontakt osoba kroz Customer portal
scenariji
Frekvencija Do 5 mjesečno
14.2.6. Scenarij: Pregled Zahtjeva

Pregled zahtjeva je identičan kao kod Incident managementa
14.3. Scenariji: Problem management

14.3.1. Scenarij: Kreiranje problema
Naziv naslov
Korisnik Inženjer podrške ili Problem manager
Preduvjeti Korisnik je ulogiran u aplikaciju
Tijek aktivnosti • Korisnik bira opciju NOVI PROBLEM
• Aplikacija otvara panel za unos podataka novog problema
• Korisnik unosi podatke o novom problemu
o Vezani incident(i) – ovo je posebni odjeljak u detail dijelu na kojemu
se može odabrati jedan ili više incidenata vezanih na ovaj problem.
Ovo bi mogao biti poseban use case ali da ne kompliciramo:
Odabirom opcije ADD RELATED INCIDENT korisnik preko pretražnog
panela odabire jedan ili više incidenata vezanih na ovaj problem.
o Aplikacija automatski prenosi polja iz prvog odabranog incidenta u
prazna (nepopunjena) polja problem ticket:
▪ Kontakt osoba
▪ Predmet (Title)
▪ Opis
▪ Prioritet
▪ Servis
▪ Kategorija
▪ Asset
▪ Zadužena grupa (Assignment group)
▪ Zaduženi djelatnik (Assignee)
• Korisnik modificira informaciju prenešenu iz incidenta i bira opcjiu SAVE
problemu i šalje mail notifikacije zainteresiranim kontaktima u skaldu s
o Assignee – kratka poruka o dodjeli problema
o ako assignee nije dodijeljen problemu, mail se šalje manageru
Assignment grupe
o Kontakt osoba – dulji mail s podacima o novom problemu
korisnika
Opis projekta 32/35

o Svim osobama pretplaćenim na obavijesti o problemima

Završno stanje Problem je pohrajnen u statusu „Open“
Alternativni • Korisnik tijekom kreiranja problema može dodati bilo koji file kao attachment
scenariji na ticket
• Korisnik tijekom kreiranja problema može kreirati Task vezan na Problem, koji
ima zaduženu osobu i datum izvršenja.
pohraniti ticket kao javni ili privatni template pomoću kojega će u budućnosti
kreirati nove tickete
• Korisnik može Problem kreirati također i iz panela za pregled/edit incidenta na
način da odabere opciju CREATE RELATED PROBLEM, scenarij je isti kao
nakon odabira vezanih incidenata u glavnom scenariju.
Frekvencija Do 100/mj
14.3.2. Scenarij: Ažuriranje problema
Naziv Ažuriranje problema

Korisnik Zaduženi djelatnik na problemu, Problem manager
Preduvjeti Korisnik je ulogiran u aplikaciju na panelu za pregled problema
Tijek aktivnosti • Korisnik bira željeni problem
• Aplikacija otvara problem u Edit modeu
• Aplikacija:
o sprema bilješku
o zatvara panel za ažuriranje problema
Završno stanje Problem je pohranjen sa novim podacima u statusu Work in progress
Alternativni • Nakon što je request prvi puta ažurirao Assignee, a prethodno je bio u statusu
scenariji Open, ticket se sprema u statusu Work in progress
• Rad sa mail notifikacijama isto kao i kod prethodnih ticketa u scenariju
ažuriranja
• Rad sa taskovima kao i kod prethodnih ticketa u scenariju ažuriranja
• Iz panela za ažuriranje problema može se u svakom trenutku kreirati Incident
biranjem opcije NEW RELATED INCIDENT. Aplikacija će otvoriti panel za
kreiranje incidenta sa već popunjenim poljima iz Problema
• Iz panela za ažuriranje problema može se u svakom trenutku kreirati Request
(u kasnijim fazama i Change) biranjem opcije NEW RELATED REQUEST.
Aplikacija će otvoriti panel za kreiranje Zahtjeva sa već popunjenim poljima iz
Problema
• Problem ima polje ProblemStatus koje se linearno kreće Analysis-KnownError-
Workaround-PermanentFix, korisnik ga može birati po volji.
• Bilo bi ODLIČNO da korisnik može kreirati par vrsta predefiniranih reporta u
MS Word formatu koji će automatski biti tagirani i inicijalno popunjeni
podacima iz problema. Ovi reporti bi se mogli pohranjivati i naknadno
editirati, nalazili bi se u bazi znanja, s tim da bi se linkom na njih moglo doći iz
Problem ticketa
Opis projekta 33/35

Frekvencija Do 500/mj
14.3.3. Scenarij: Rješavanje problema
Naziv Rješavanje problema

Korisnik <Actor koji inicira Use Case. Teži se da na jedan UC djeluje samo jedan actor, što
se postiže iterativnim postupkom analize UC-a kako bi se dobila zadovoljavajuća
granularnost.>
Preduvjeti <Preduvjeti koji moraju biti ispunjeni da se UC izvrši. Sustav mora biti u
odgovarajućem stanju prije nego se omogući inicijacija UC-a. Npr. ako postoji
međuovisnost UC-a tipa uses ili extends, zahtjev može biti da se jedan ili više UC-a
mora izvršiti prije ovoga.>
Tijek aktivnosti • <Jednostavni opis niza interakcija aktora i sustava koji definira što korisnik radi
i kako mu sustav odgovara. Tijek događaja se navodi bez grananja, alternativnih
staza i petlji-tzv. Main Course ili Happy Path, niz događaja koji se odvijaju u
najpoželjnijem slučaju. Rečenice trebaju biti jednostavne, imenica-glagol-
imenica, npr. "1. Korisnik bira opciju PRETRAGA. 2. Aplikacija otvara panel za
pretraživanje.3. Korisnik unosi kriterij pretraživanja i bira opciju TRAŽI". Zgodno
je svaku interakciju odvojiti u novi red i numerirati. Ne opisuju se izgledi sučelja
ni egzaktna funkcionalnost, tj. korisnik bira opciju, a ne tipku ili drop-down polje,
aplikacija otvara ekran ili panel, a ne html frame sa zaglavljem od 120 pixela... >
Završno stanje <Stanje u kojemu se sustav nalazi po završetku glavnog scenarija>
Alternativni • <Alternativni ishodi UC-a. Ovdje opisujemo sva moguća odstupanja od
scenariji Glavnog scenarija, tj. alternativne načine na koje ovaj UC može završiti,
uspješno ili neuspješno. Nekad postoji više načina na koje UC može uspješno
završiti.>
14.3.4. Scenarij: naslov
Naziv naslov
Korisnik <Actor koji inicira Use Case. Teži se da na jedan UC djeluje samo jedan actor, što
se postiže iterativnim postupkom analize UC-a kako bi se dobila zadovoljavajuća
granularnost.>
Preduvjeti <Preduvjeti koji moraju biti ispunjeni da se UC izvrši. Sustav mora biti u
odgovarajućem stanju prije nego se omogući inicijacija UC-a. Npr. ako postoji
međuovisnost UC-a tipa uses ili extends, zahtjev može biti da se jedan ili više UC-a
mora izvršiti prije ovoga.>
Tijek aktivnosti • <Jednostavni opis niza interakcija aktora i sustava koji definira što korisnik radi
i kako mu sustav odgovara. Tijek događaja se navodi bez grananja, alternativnih
staza i petlji-tzv. Main Course ili Happy Path, niz događaja koji se odvijaju u
najpoželjnijem slučaju. Rečenice trebaju biti jednostavne, imenica-glagol-
imenica, npr. "1. Korisnik bira opciju PRETRAGA. 2. Aplikacija otvara panel za
pretraživanje.3. Korisnik unosi kriterij pretraživanja i bira opciju TRAŽI". Zgodno
je svaku interakciju odvojiti u novi red i numerirati. Ne opisuju se izgledi sučelja
ni egzaktna funkcionalnost, tj. korisnik bira opciju, a ne tipku ili drop-down polje,
aplikacija otvara ekran ili panel, a ne html frame sa zaglavljem od 120 pixela... >
Opis projekta 34/35

Završno stanje <Stanje u kojemu se sustav nalazi po završetku glavnog scenarija>

Alternativni • <Alternativni ishodi UC-a. Ovdje opisujemo sva moguća odstupanja od
scenariji Glavnog scenarija, tj. alternativne načine na koje ovaj UC može završiti,
uspješno ili neuspješno. Nekad postoji više načina na koje UC može uspješno
završiti.>
<<Begin text here>>
15. Fizički dizajn

Fizički dizajn bit će definiran u suradnji sa Developmentom u skladu s prethodnim poglavljima.
16. Pravni zahtjevi

Ovdje bismo se trebali orijentirati na suradnju s našim pravnim odjelom, pretpostavka je da bi u ovom
trenutku osim standardnih zahtjeva po pitanju ugovora i SLA tema mogla biti i nova europska inicijativa
za zaštitu privatnih podataka. Treba omogućiti da se u slučaju odlaska bilo koje privatne osobe iz
poslovne organizacijske jedinice omogući uklanjanje njezinog identiteta iz aplikacije bez narušavanja
referencijalnog integriteta baze i uz zadržavanje integralnih podataka o događajima u sustavu.
[Description: The Legal Requirements Summary section is a summary of any legal requirements to which
the project must adhere. Legal requirements may come from the customer’s corporate policies or from
regulatory agencies governing the customer’s industry.
17. Rizici
Ovo je proces u kojemu bi svi akteri trebali sudjelovati tijekom cijelog procesa razvoja u svim fazama.
Identificirati sve rizike i procijeniti njihovu izloženost, te definirati načien mitigiranja tih rizika u slučaju
njihovog aktiviranja tj. pojave.
Primjer:
Rizik Vjerojatnost Utjecaj Akcija ublažavanja posljedica
(1.-10) (1-10)
Odustajanje korisnika x 3 8 Implementacija kod korisnika x igrala je značajnu
od implementacije ulogu u odluci za kretanje u razvoj, bit će potrebno
pronaći zamjenske korisnike koji će opravdati
nastavak razvoja ili obustaviti projekt
[Description: The Risk Summary section identifies and describes the risks associated with the Functional
Specification. This should include all risks that may impact development and delivery of the solution where
the risk source is the content of the Functional Specification. The list of risks should be accompanied by
the calculated exposure for each risk. If appropriate, this section may also contain a summary of the
mitigation plans for those risks.
Opis projekta 35/35

SSD Detaljna Funkcionalna Specifikacija

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SSD Detaljna Funkcionalna Specifikacija

Uploaded by

Copyright:

Available Formats

Detaljna funkcionalna

Autor: Drago Topalović / SPAN d.o.o.

Oznaka tajnosti dokumant: Interno

Verzija Ime i prezime Datum Opis

1.0 Drago Topalović 13.5.2016. Prvi Draft

1.1 Drago Topalović 24.7.2016 Faza 1 definirana

Ime i prezime, SPAN d.o.o.

Opis projekta 2/35

7.1. Analiza troškova i koristi ..................................................................................................................................................... 7

8. Korisnički zahtjevi ........................................................................................................................................................................ 8

8.1. Korisničko iskustvo................................................................................................................................................................ 9

9. Zahtjevi na sustav ...................................................................................................................................................................... 10

9.1. Međuvisnosti sustava i usluga ......................................................................................................................................... 10

10. Operativni zahtjevi ................................................................................................................................................................... 11

13.1. Alternativni koncepti ........................................................................................................................................................ 18

13.1.1. Microsoft System Center Service Manager ................................................................................................ 18

14. Logički dizajn ............................................................................................................................................................................ 18

14.1. Scenariji: Incident management .................................................................................................................................. 24

14.1.1. Scenarij: Kreiranje incidenta ........................................................................................................................... 24

Opis projekta 3/35

14.1.2. Scenarij: Ažuriranje incidenta ........................................................................................................................ 25

14.2. Scenariji: Request fulfilment ......................................................................................................................................... 28

14.2.1. Scenarij: Kreiranje zahtjeva SD ...................................................................................................................... 28

14.3. Scenariji: Problem management ................................................................................................................................ 32

14.3.1. Scenarij: Kreiranje problema .......................................................................................................................... 32

15. Fizički dizajn ............................................................................................................................................................................. 35

Opis projekta 4/35

4. Sažetak vizije/dosega projekta

Podržavat će integracije na elementarnoj razini sa drugim SD aplikacijama i nadzornim alatima.

Opis projekta 5/35

6. Sažetak funkcionalne specifikacije

Opis projekta 6/35

Obrađuju se osnovne pretpostavke i utjecaji, a naglasak je dan na dizajn rješenja:

7.1. Analiza troškova i koristi

7.2. Skalabilnost i performanse

7.3. Raspoloživost / Pouzdanost

Opis projekta 7/35

7.5. Podrška za heterogenu arhitekturu

Opis projekta 8/35

8.1. Korisničko iskustvo

8.2. Jednostavnost uporabe

Opis projekta 9/35

8.5. Obuka korisnika

9.1. Međuvisnosti sustava i usluga

Opis projekta 10/35

10. Operativni zahtjevi

11. Korisnički scenariji

Opis projekta 11/35

Ovisno o individualnim postavkama, Kontakt osoba je obaviještena svaki put

Opis projekta 12/35

Opis projekta 13/35

o Pregled – slično kao kod incidenata

Opis projekta 14/35

o Pregled – slično kao kod incidenata

Opis projekta 15/35

Opis projekta 16/35

o Praćenje tijeka riješavanja – notifikacije o tijeku rješavanja ticketa

12. Pretpostavke i utjecaji

13. Konceptualni dizajn

Opis projekta 17/35

13.1. Alternativni koncepti

13.1.2. Service Desk proizvodi iz gornjih kvadranta Gartnerovih izvješća

13.1.3. Jeftina i „besplatna“ open source rješenja