IT intsidendi loomine lahendamisel

Loo intsident, kasutades olemasolevat infot intsidendi kohta. Kasuta kliendilt saadud infot, määra intsidendile klient,
arusaadav ja asjakohane pealkiri ning kirjelda intsidendi olemust.

Oluline on kirja saada võimalikult palju infot, siiski mitte liiga palju infot. Kui hiljem tekkib intsidendile täiendavat infot siis
lisa see märkusena.

Võimalusel kasuta ekraanipilte, lisa juurde linke, vms näitlikustavat materjali.

Need intsidendi täitmiseks vajalikud etapid, mis on esmatähtsad võiksid sisestada ülesse ka checklistina. Sel juhul
meeskonnaliikmed teavad millised etapid peavad olema tehtud.

Sisesta ka tööaeg, mis möödus kliendiga rääkimiseks ning intsidendi kirja panekuks. Soovitavalt tee ka viited config item’ite
vahele. Korralikult koostatud intsident ehk korralikult sõnastatud probleemi olemus on juba pool lahendust

Määra prioriteet
Määra intsidendi prioriteet vastavalt intsidendi tekitavale mõjule ning pakilisusele. Kasuta prioriteedi määramiseks selleks
loodud tabelit! Vajalik võib olla intsidendi probleemi prioriteedi muutmine vastavalt kliendilt tulnud uuele infole või mõnele
muule mõjule.

Kuidas viia lahendust ellu
Pane paika või kasuta olemasolevat plaani intsidendi lahendamiseks. Lihtsama intsidendi jaoks pole plaani vaja, keerulisema
jaoks võiks olla kirjeldatud ka plaan. Plaani täitmist tuleks kontrollida ning vajadusel plaani parandada. Lahendus võib olla ellu
viidud kas meie spetsialistide poolt või ka kliendi enda poolt.

Monitoori(jälgi) muutusi
Jälgi intsidendi käiku alates selle tekitamise hetkest kuni sulgemiseni. Tee selgeks, kas intsidendi staatus on põhjendatud või
mitte

Käi koos kliendiga protsess või lahendus läbi
Edasta kliendile lahendus ja käi kliendiga kogu protsess läbi ning veendu, et lahendus on ellu viidud korretselt.

Määra töö edasisiseks analüüsiks. Eskalleeri teenus!
Määra intsident analüüsimiseks vastavale spetsialistile, kellel on rohkem pädevust ning volitusi küsimuse lahendamisel.
Võimalusel vestle spetsialistiga, et näha kas antud teema on tema pädevuses või mitte.

Määra kindlaks intsidendi mõju
Intsidentide mõju kindlaks tegemine tähendab seda, et selgitatakse milliseid äriprotsesse või teisi Config Itemeid antud
intsident mõjutab. Määra intsidendile mõju. Vajadusel uuenda mõju.

Mitmenda intsidendi tekkimisel ava probleemEnne intsidendi sulgemist proovi veenduda, kas intsident võib veel korduda. Kui tundub, et see võib korduda siis tee uus
intsident tüübiga probleem ning vajadusel määra spetsialistile edasiseks lahenduseks. Esialgne intsident peab olema viidatud
sellele probleemile ning jääma samuti lahtiseks kuni lahenduse korrektse ellu viimiseni.

Uuenda intsidendi informatsiooni
Intsidendi informatsioon võib olla ebapiisav või segadust tekitav. Võimalik, et on vaja kliendilt küsida täiendavat infot.
Ühenduse võtmisel kogu võimalikult palju infot. Eesmärk on koguda infot selliselt, et probleem või intsident muutub
mõistlikuks ja arusaadavaks.

Kategoriseeri intsident
Identifitseeri intsidendi sümptomid ning päritolu. Millest probleem tekkis? Mis hetkel? Peale millist tegevust? Millise
teenusega see seotud on?

Tee kindlaks kui kiiresti on vaja lahendust
Määra kindlaks intsdendi pakilisus. Kui kiiresti peab intsidendi lahendama? Mida see mõjutab?

Pane esialgne diagnoos
Selgita välja intsidendi põhjus ning proovi lahendada intsidenti.Kasuta kogu olemasolevat informatsiooni sarnaste
intsidentide, CI’de, kasutusjuhendite, Google otsingu, KKK teadmistebaasi, jne. Kui lahendust ei õnnestu ellu viia siis mõtle,
kellele see intsidend edasi määrata.

Kontrolli Config Itemi (CI) vastavust
Kontrolli, kas CI infromatsioon OTRSis vastab seotud intsidendile. Vajadusel uuenda informatsiooni või tekita uus intsident
CI info uuendamiseks teise inimese poolt. Config Item’ite kirjeldamisest loe siit.

Sulge intsident
Ametlik intsidendi sulgemine. Intsidendi sulgemiseks küsi kliendilt luba selleks, et veenduda probleemi sobivas lahenduses

Kontrolli topelt intsidente
Topelt intsidentide olemasolul seo intsidendi OTRSis ning sulge need korraga peale lahenduse ellu viimist

Viia lahendus kliendini
Vii ellu konkreetne lahendus. See võib toimuda kliendiga ühenduses olles.

Kontrolli teenuse korrasolekut / probleemi lahendust
Kontrolli, kas lahendus lahendas probleemi või mitte. Kui lahendas siis sulge intsident. Kui ei lahendanud siis saada intsident
uuesti diagnoosimisele. Lihtsamate probleemide puhul on soovitatav kliendilt lahenduse sobivus üle küsida, keerulistemate
küsimuste puhul on see kohustuslik!

Tee kindlaks millise CI’ga on intsident seotud
Tee kindlaks millised CI’d on mõjutatud. Mõjutatud võivad olla nii konrkeetsed probleemsed CI’d kui ka nendega seotud CI’d.
Seo intsident nimetatud CI’dega. Võib ka siduda nende CI’dega mis ei ole niivõrd otseselt seotud!

Anna kiendile tagasisidet
Saada kliendile tagasisidet ning veendu, et klient tagasiside kätte sai.

Algata muutus IT süsteemis
Kui probleemi lahendamiseks on vaja ellu viia suurem muutus siis määra see intsident vastvale spetsialistile!

Vaata üle ja kontrolli intsidendi andmeid
Kasuta kõiki võimalikke andmeid veendumaks, et intsidendi olemusest ja juhtunust on võimalikult selge ülevaade. Intsident
peab olema mõistetav.

Lõpeta ja kontrolli intsidendi andmed
Täida kõik vajalikud andmed intsidendi sulgemiseks. Kontrolli, et lahenduskäik oleks kirjas ning intsident oleks õigesti
klassifitseritud ja priotiseeritud. Veendu, et lahendus oleks kirjeldatud selliselt, et seda saaks jägmise sarnase intsidendi
lahendisel. Kui leiad intsidendist vead siis informeeri sellest vastavaid inimesi ning juhata tähelepanu vigadele. Veendu, kas see
intsident võib põhjustada ka teisi intsidente või kas esksiteerib mingi juurpõhjus sellele intsidendile mis vajab lähemat
uurimist.Kui on siis tekita probleem.

Määra intsident peamiseks intsidendiks’
Määra intsident suureks või peamiseks probleemiks kui see mõjutab paljusid IT ja äriprotsesse ning vajab kiiret lahendamist
ning palju spetsialiste.

Otsi sarnaseid intsidente
Otsi sarnaseid intsidente, et saaks antud intsidenti kiiremini lahendada. Üle võib vaadata ka sarnased intsidendid.

Koosta KKK
Koosta kliendile ja meeskonnale KKK. Kategoriseeri KKK, kirjelda probleemi, sümptomeid ja lahendusi ning vajadusel
kommenteeri asjasse puutuva informatsiooniga. Kasutada võib ka ekraanipilte, vitieid CI’dele või asjasse puutuvatele
intsidentidele. Kliendile kirjutatud KKK peab olema topelt kontrollitud, et kõik oleks keeleliselt korrektne.

Kontrolli tööaja sisestamist
Kontrolli intsidendiga seotud tööaja sisestamist. Töö aja sisestamise juhendi leiad käesolevast dokumendist. S.h.kas on töö
lisatöö või on see väljaspool tööaega töö.

Kliendi identifitseerimine
Klient tuleb kõikidel töötajatel identifitseerida ees- ja perekonna nime järgi. Vajadusel tuleb kontrollida, kas kliendi andmed
OTRSis on värsked (nimi, telefon, ametikoht, e-maili aadress). Identifitseerimine on eriti oluline ligipääsuõguste andmisel.

Ligipääsuõiguste andmine
Ligipääsuõigusi antakse eranditult SMS teel. St.kasutajanimi ja parool edastatakse vaid SMS teel, mitte mingil teisel meetodil.
Selliselt välistatakse ligipääsuõiguste sattumine valede inimeste kätte (social engineering).

Ligipääsu andmine kliendiportaali.
Klienti tuleb informeerida, et tal on võimalus logida sisse kliendiportaali ning sealt näha kõiki temaga seotud intsidente, nende
lahenduskäiku ja lahendusi. Lisaks saab klient sealt ka lugeda korduma kippuvaid küsimusi. Kliendiportaalis ei tohi enne KKK
moodulit aktiveerida kui seal on piisvalt sisu. Kliendiportaali sisu peab teenuse juht kontrollima vahetult konkreetse kasutaja
kasutajanime ja parooliga.

Telefonikõnede suunamine
Teenuse juht vastutab, et kõned oleks alati vastatud või delegeeritud õigele inimesele.

Kaugtoe osutamiseks vajaliku info salvestamine
Vajalik on seadistada igale arvutile TeamVieweri püsi ligipääs. Serverite jt.seadmete puhul vastavalt kas RDP, SSH, vms
ühendus. Teenuse juht hoolitseb, et kõik vajalik info kaugelt haldamiseks ja ligipääsuks on OTRSis kirjas. Soovitav mõelda
selleks mingi teistele ja endale arusaadav süsteem.

Lisada/muuta või kustutada teenus/CI monitooringusse
Vajadusel lisada teenus või config item monitooringusse vastavalt monitooringu teenuse kirjeldusele. Paremaks probleemi
lahendamiseks

Teenuse juht peab töögraafiku arvestust
Teenuse juht on kursis tehnikute töögraafikuga sisestades vastavad parameetrid intsidendi andmetesse.

Rämpsposti filtreerimine
Tõstab rämpsposti “Junk” nimekirja (queue)

it juhtimine

Miks nõuda teenusepakkujalt teenuse juhtimist?

Kas Te teate, et paljudel IT teenuse pakkujatel on probleem mitte teenuse osutamine vaid kasutajate teavitamine lahendatud intsidentidest? Kas te olete mõelnud mitu korda spetsialist lahendab taas ühte ja sama probleemi? Mitu tundi või päeva aastas veedab spetsialist paroolide reset’imisele?

Mitu korda te olete pidanud samast probleemist rääkima kuni selle tegelema asumiseni lõpuks jõutakse?

Kas teil lahendatakse ikka probleeme või üksikuid intsidente ikka ja jälle? Palju kulub aega erinevate küsimuste lahendamiseks?

Ülevalpool kirjeldatud pildilt joonistub selgelt välja rida probleeme. Mõtleva inimesena näete seal kindlasti emotsionaalset pinget, tööaja kulutamist, kindlasti raiskamist ja arvatavasti ka umbmäärasust. Kui Te lubate siis ma ajan pildi veel segasemaks.

Kus asub konkreetne arvuti? Millised tarkvarad sellel on? Mis süsteemide toimimist on veel vaja, et selle arvuti taga istuv töötaja saaks oma tööd teha? Mis on selle arvuti parool? Millal see osteti? Kaua kehtib garantii? Kuhu printerisse see kasutaja tahab printida? Mis on tema jaoks oluline? Mitu korda see arvuti on remondis käinud? Kui tihti see töötaja kasutab IT toe teenuseid? Küsimusi saab olla lõputult.

Oluline on aga see, et arvuti vahetamisel kõik toimiks vaetult – mitte see, et it spetsialist kulutab kohapeal enda aega ja ka teie töötaja aega kuni lõpuks kõik on selline nagu enne arvuti vahetamist!

Oletame aga, et jutt käib asutuses kasutatavast võrguseadmest. Sellel seadmel on 48 võrgupesa – iga kaabel jookseb kuskile. Iga kaabli otsas on veel sadu kaableid. Teatud kaablitest jookseb avalik internet, teatud kaablitest telefonikõned, teatud kaablitest missioonikriitiline andmestik, jne. Oletame, et switch läheb katki. Mis te arvate kaua läheb aega kui kellegi vihikunurgale tehtud märkmetest hakata mõtlema missugused andmed millisest võrgupesast liiguvad?

Lihtne seadmevahetamine võib võtta aega veerand tundi või kaks päeva!

Loomulikult teavad it spetsialistid ise oma haldusalas oleva asutuse infosüsteemi iseärasusi unepealt – ma tahaks ka nii uskuda. Tahes tahtmata tekinud küsimused ununevad ja ununevad ka lahendused. Kas mitte nii ei jää lihtsasti märkamata mustrid, korduvused või koguni raha kokkuhoidvad tähelepanekud? Paljudele juhtidele muidugi ei lähe korda need tühised summad. Kui suure ettevõtte IT eelarve on vaid 100 000EUR ning niigi on koguaeg kokkuhoiu poliitika siis vaevalt seal midagi erilist kokku annab hoida? Tegelikult annab. Päris viisakaid summasid on võimalik nii kokku hoida. Olen nõus, et kõik oleneb asjaoludest – kas 25% on piisav? Kas ennetatud või kiiremini lahendatud probleem, mis hoiab ka teie ettevõtte aega kokku on piisav?

Hallatud teenuspäringud, hallatud probleemid, hallatud konfiguratsioon, hallatud muudatused ja hallatud teadmised. Mida see kõik annab?

Oluline on, et teenuse pakkuja või ka üksik IT spetsialist talletaks oma teadmised ja oskused selleks, et vähendada töö uuesti tegemist või vältida koguni topelt tööd.

Mis juhtub kui IT spetsialist otsustab töökohta vahetada? Kui ta haigestub?

Arvutikasutajate vajadused peavad olema teada ning paremini ühenduses äri vajadustega ning IT juhtimine ja strateegia peab haakuma äristrateegiaga. Mis küsimused üldse on tekkinud? Mis on probleemid? Millised võimalused meil on? Mida me muutma peame?

Mis on see vähim, mida saame teha, et kõige rohkem inimeste aega kokku hoida?

Tähtis on, et inimesed õpiksid oma varasematest kogemustest, et õpitud kogemused oleks kättesaadavad ka teistele. Palju kulub aega samade asjade üha uuesti rääkimisele? Üha uuesti (taas)lahendamisele?

Millised IT seadmed on kasutuses? Mis konfiguratsiooniga? Kas neid on vaja uuendada? Milliste seadmetega on millised probleemid? Kus on ostuarved? Oluline on vähendada IT tööjõukulusid, jättes tegemata mõtetut tegevused.

Tähtis on, et IT varad ja IT kulud (IT juhtimine) oleks läbipaistvamad ning, et arvutikasutaja saaks teha oma tööd.

Oletame, et Teie töötaja pöördub IT poole küsimusega, mis on spetsialistile piisavalt ebamugav lahendada – pöördub korra, pöördub kaks ja kolmandat korda helistab! Kas seda on üldse vaja? Hallatud teenus tähendab, et kokku lepitud reageerimisaja jooksul mitte vastamine tähendab automaatselt spetsialisti juhi teavitamist antud küsimusest. Võib-olla aga võiks spetsialisti teavitada paar tundi varem kui nimetatud aeg täituma hakkab? Võib-olla peaks aga IT spetsialistidele antud ülesandeid vastavalt tehnikute personaalsetele võimetele ringi jaotama?

Käesoleva kirjutisega ma ei pretendeeri kirjeldamaks IT juhtimine ja sellega seotud kõiki nüansse. Juhin tähelepanu, et IT teenus peab olema juhitud. Ma olen seda korduvalt näinud – irooniaga öeldes – see on Teie valida milliste küsimustega te tahate tegeleda ja millistega mitte.

Eestis tegeleb teenuste haldamise heade tavade ja praktikate populariseerimise, spetsialistide oskuste suurendamise ning kogemuste jagamisega itSMF Estonia. Visioline Infra OÜ on selle organisatsiooni liige juba aastaid. Leiame, et pidev õppimine ja täiustamine teenuse juhtimise valdkonnas on just see küsimus, millest võidab just klient.

IT süsteemi hinnangut ja pakkumist saab küsida siit: http://www.visioline.ee/it-hooldus/