• No results found

Theoretical interpretation 2 Operational decisions

5.2 Theoretical interpretations

5.2.2 Theoretical interpretation 2 Operational decisions

Po vzpostavitvi sistema se pri delovanju pojavijo nove težave. Težave lahko strnemo v naslednje oblike (qSTC, 2006):

• Uporabniki in osebje IT se izogibajo proceduram upravljanja incidentov;

• Preveliko število incidentov in njihovo beleženje; • Prehitra eskalacija incidentov;

• Katalog storitev ni ažuren;

V primeru, ko uporabniki sami rešijo napako ali se sami neposredno obrnejo na podporno osebje in upoštevajo procedure, se zgodi, da organizacija nima zapisanega rezultata storitev in tudi ne števila napak. Posledično poročila o upravljanju ne vsebujejo ustreznih podatkov. Strokovno osebje se po nepotrebnem obremenjuje z

malenkostmi, kar posledično pripelje do neučinkovitosti in

preobremenjenosti osebja.

Ob pojavi nepričakovanega velikega števila incidentov običajno ni časa, da bi jih vse zapisali. Nepopolni podatki o incidentih lahko upočasnijo proces reševanja in otežujejo usmerjanje incidentov k ustreznim skupinam za podporo. V takšnih primerih je primerno izvesti vertikalno eskalacijo incidentov.

Prehitra ali nepotrebna eskalacija ima lahko neugoden učinek na strokovnjake enako kot neupoštevanje procedure, saj jih preveč in po nepotrebnem obremenjuje in jim ne dovoljuje opravljanja rednega dela.

SLA je osnovni pogoj za uspešno delovanje sistema. V primeru, da dogovora o ravni delovanja storitve ni ali pa je ta neažuren, je osebje prepuščeno samo sebi in težko določi obseg pomoči uporabniku. Običajno se zatika pri določanju prioritet in eskalaciji incidentov. V tem primeru mora vodstvo IT ukrepati z izdajo dodatnih navodil in z večjim neposrednim vplivom na procese upravljanja z incidenti.

Delo v procesni organiziranosti zahteva drugačno zavedanje in organizacijsko kulturo. V primeru neustreznega nivoja zavedanja o posebnosti procesnega organiziranja prihaja neprekinjeno do sporov med strokovnim osebjem, ki se ga poskuša reševati z linijskim vodstvom, le to pa spor rešuje z nepotrebnim birokratizmom in tako običajno zavira procesno organiziranost. Posledica je neučinkovitost sistema. V cilju izogiba temu je potrebno linijsko vodstvo ustrezno usposobiti, da prevzamejo načela ITIL kot osnovo svojega postopanja.

3 INCIDENTI V INFORMACIJSKIH SISTEMIH JAVNE

UPRAVE

Incident je vsako delovanje sistema, ki ni del standardnega načina delovanja. Incidenti lahko imajo vzrok v naključni napaki sistema, skriti napaki programske opreme, odpovedi strojne opreme, nepravilni uporabi informacijskega sistema, uporabniški prekoračitvi varnostnih pooblastil in dodeljenih pravic, itd. Incidente lahko zaznamo iz različnih virov.

Vsak informacijski sistem ima svojo lastno strukturo incidentov, ki je odvisna od lastnosti in namena sistema, načina upravljanja s sistemom, odnosa uporabnikov in IT osebja do sistema, odnosa vodstva, varnostne politike itd. Za pravočasno izvajanje ukrepov za obvladovanje incidentov mora vsaka organizacija imeti podatke o strukturi incidentov, ki nastajajo v informacijskem sistemu.

Strukturo incidentov v informacijskem sistemu je najlažje pridobiti v organizaciji, ki ima vzpostavljen storitveni center po priporočilih ITIL, kjer se beležijo vsi incidenti, ki nastanejo v sistemu. V tem primeru, ki ga obravnava ta naloga, je beleženje incidentov potekalo v storitvenem centru, ki je v začetni fazi formiranja in pokriva uporabnike za sedem organizacijskih enot, razmeščenih na treh lokacijah.

Na razpolago sta bili dve zbirki podatkov. Prva je za čas enoletnega preizkusnega delovanje centra za omejeno število uporabnikov in vsebuje podatke o:

• Šifri incidenta; • Datumu nastanka;

• Datumu začetka reševanja;

• Datum zaključka reševanja incidenta;

• Skupnem številu dni za reševanje incidentov.

Druga zbirka podatkov o incidentih pa je nastala z namenom in ciljem, da bodo tako pridobljeni podatki uporabljeni v tej magistrski nalogi. Zajema čas štirih tednov delovanja in vsebuje vse podatke, ki opisujejo pot od nastanka do rešitve. Podatke so zbirali zaposleni v storitvenem centru po vnaprej pripravljenih pisnih navodilih. Z vsemi zaposlenimi je bila narejena tudi priprava za zbiranje podatkov. Nadzor nad zbiranjem podatkov je izvajal vodja storitvenega centra. Del podatkov je sestavni del podatkovne zbirke za podporo delovanja storitvenega centra, del podatkov pa so zaposleni zbirali neposredno od izvajalcev.

Zbirali so se podatki o informacijskem sistemu, ki je bil razvit za 702 uporabnika in razmeščen na treh lokacijah, ki so med seboj oddaljene od 10 do 45 km (Tabela 1). Uporabniki so bili iz 6-ih različnih organizacijskih enot.

Enota LOK1 LOK2 LOK3 Skupaj Delež v %

Enota A 235 - - 235 33,48 Enota B 8 86 - 94 13,39 Enota C 17 17 - 34 4,84 Enota D 18 - - 18 2,56 Enota E - 47 - 47 6,70 Enota F - 14 260 274 39,03 Skupaj 278 164 260 702 100 Delež v % 39,60 23,36 37,04 100,00

Tabela 1: Pregled števila uporabnikov po lokacijah in enotah V podatkovni zbirki so zbrani podatki o incidentih za:

• Datum prijave napake na sistemu, ki je enak datumu nastanka incidenta, saj je v organizaciji običaj oziroma politika, da uporabnik takoj ob zaznavi napake pokliče storitveni center na splošno znano telefonsko številko;

• Ura nastanka napake se zabeleži na enak način kot datum nastanka in se je vodila na minuto točno;

• Šifra incidenta je bila vzeta iz podatkovne zbirke programa za upravljanja z incidenti. Namen je bil, da se lahko zbrani podatki primerjajo s podatki iz programa;

• Kategorija incidenta, ki opisuje skupino incidentov. Ta podatek je imel vlogo zbrati podobne incidente v logično skupino;

• Opis napake, s katerim se na kratko opiše vsebina napake; • Lokacija nastanka napaka;

• Organizacijska enota, kateri prizadeti uporabnik pripada; • Datum, kdaj je bila napaka odpravljena;

• Ura, kdaj je bila napaka odpravljena;

• Podatek, ali je bila napaka enaka, kot je bila opredeljena ob prijavi napake;

• Čas, ki so ga vsi vpleteni v proces odprave napake dejansko aktivno (brez časa čakanja) uporabili za odpravo incidenta; • Kdo je napako odpravil (storitveni center, II. nivo, III, nivo itd) • Katera oseba je odpravila incident;

Zbrani podatki so bili preverjeni in dopolnjeni v procesu analize, preverjanja in čiščenja podatkov. Ugotovljeno je bilo:

• Da so podatki o dejanski porabi časa nepopolni, saj so zbrani le za eno lokacijo;

• Podatki o incidentih, ki so se zaključili v času klica uporabnika v storitveni center, se niso beležili v podatkovno zbirko in so bili dodani kasneje.

Kljub vsem ugotovljenim pomanjkljivosti in napakah na zbranih podatkih o incidentih je možno zbrane podatke vzeti kot reprezentativni vzorec incidentov, ki nastaja v informacijskem sistemu javne uprave.