Infoturbeintsidentidega tegelemine. Ib intsidendi uurimine tagaajamisel. OWA logi analüüs

Juhtumijuhtimise protsess

Kahjuks pole maailm täiuslik. See kehtib ka IT-teenuste kohta. IT-teenuste osutamisel võib esineda tõrkeid: teenus võib muutuda kättesaamatuks, töötada vigadega, võib kätte saada volitamata juurdepääs infole jne. Need. võib esineda negatiivseid kõrvalekaldeid tavapärasest teenuse osutamisest. ITIL-is nimetatakse neid kõrvalekaldeid vahejuhtumiteks.

Juhtum on IT-teenuse kvaliteedi planeerimata katkemine või langus. Konfiguratsiooniüksuse rike, mis ei ole teenust veel mõjutanud, on samuti vahejuhtum, näiteks ühe peegelmassiivi draivi rike.

Mõnel juhul võib juhtum jääda kasutajatele märkamatuks, mõnel juhul võib sellel olla oluline rahaline, maine ja muu negatiivne mõju ettevõttele. Kui juhtum siiski juhtus, on vaja selle negatiivset mõju minimeerida.

Kuidas seda teha? Ühel juhul - võimalikult kiiresti "remontida", teisel - kõige olulisemate funktsioonide võimalikult kiire taastamine, kolmandal - lahenduse rakendamine jne.

Lahendus on juhtumi või probleemi mõju vähendamine või kõrvaldamine Sel hetkel täiseraldusvõime pole saadaval.

IT-osakondade intsidentide lahendamisega seotud tegevusel on reeglina oluline mõju kogu kasutajate arusaamale ITst. Nende tegevuste tõhusaks juhtimiseks tuleb kindlaks määrata sobiv tegevussuund. ITIL-i soovituste kohaselt tuleks selleks luua intsidentide haldamise protsess.

Juhtumihaldus on protsess, mis vastutab kõigi intsidentide elutsükli haldamise eest. Juhtumijuhtimine tagab, et ärimõju minimeeritakse ja teenus taastub võimalikult kiiresti normaalseks toimimiseks.

Eesmärgi saavutamise osana on intsidendihaldusprotsessi ülesanded:

• Standardmeetodite ja protseduuride kasutamise tagamine tõhusaks ja kiireks reageerimiseks, analüüsiks, dokumenteerimiseks, jooksvaks juhtimiseks ja aruandluseks intsidentide lahendamise käigus.
• Läbipaistvuse ja suhtluse suurendamine äri ja IT vaheliste intsidentide lahendamisel.
• Parandage ettevõtte ettekujutust IT-st, kasutades juhtumite lahendamisel professionaalset lähenemist.
• Juhtumite lahendamise prioriteetide vastavusse viimine äri prioriteetidega.
• Kasutajate rahulolu säilitamine IT-teenuste kvaliteediga.

Juhtumijuhtimise protsessi tegevused

Juhtumid võivad juhtuda mis tahes infrastruktuuri osas. Tihti annavad neist teada kasutajad, kuid neid saavad tuvastada ka IT-töötajad, kuid seiresüsteemide info põhjal.

Enamasti registreerib vahejuhtumid teeninduskeskus, kus neist teatatakse. Kõik intsidendid tuleb registreerida kohe pärast teate saamist järgmistel põhjustel:

• on raske intsidendi kohta teavet täpselt fikseerida, kui seda ei tehta kohe;
• intsidendi lahendamise tööde edenemise jälgimine on võimalik ainult juhul, kui juhtum on registreeritud;
• logitud intsidendid aitavad diagnoosida uusi intsidente;
• Probleemide haldamisel saab algpõhjuste otsimisel kasutada teatatud juhtumeid;
• mõju määra on lihtsam määrata, kui kõik sõnumid (kõned) on registreeritud;
• ilma vahejuhtumeid registreerimata on võimatu kontrollida lepingute (SLA) täitmist;
• Juhtumite kohene registreerimine hoiab ära olukorrad, kus sama intsidendi kallal töötab mitu inimest või keegi ei tee juhtumi lahendamiseks midagi.

Kogu asjakohane teave intsidendi kohta tuleb salvestada ja tugimeeskondadele kättesaadav.

Juhtumiteabe näide:

Kui juhtum algselt registreeritakse, tuleb see kategoriseerida.

Kategooria on nimega objektide rühm, millel on midagi ühist. Kategooriaid kasutatakse sarnaste objektide rühmitamiseks. Näiteks kulutüüpe kasutatakse sama tüüpi kulude rühmitamiseks, intsidentide kategooriaid – sama tüüpi intsidentide puhul, CI tüüpe – sama tüüpi konfiguratsiooniüksuste kulusid.

Juhtumite õige kategoriseerimine aitab need kohe ümber suunata soovitud grupp ja analüüsida intsidente erinevatest vaatenurkadest ning on ühtlasi aluseks intsidentide põhjuste leidmisele ja nende kõrvaldamisele osana probleemihaldusprotsessist.

Igale juhtumile määratakse konkreetne prioriteet.

Prioriteet põhineb mõjul ja kiireloomulisel ning seda kasutatakse vajaliku töötlemisaja määramiseks.

Kiireloomulisus on mõõt, mis näitab, kui kiiresti intsident selle toimumise hetkest alates ettevõttele oluliselt mõjutab.

Mõju (mõju) määr – intsidendi mõju äriprotsessile mõõt.

Seega tegelikult on prioriteet number, mis põhineb kiireloomulisel (kui kiiresti see tuleb parandada) ja mõjul (milline kahju tekib, kui seda kiiresti ei parandata). Prioriteet = kiireloomulisus x mõju aste. Prioriteedist lähtuvalt määratakse vahejuhtumite lahendamise järjekord.

Prioriteet määratakse vastavalt järgmised tegurid:

• Kiireloomulisus
• Mõju ärile
• Oht elule või jäsemetele
• Mõjutatud teenuste arv
• Rahalised kahjud
• Mõju ettevõtte mainele
• Mõju seaduste ja muude määruste täitmisele jne.

Võttes arvesse kehtestatud prioriteetseid ja olemasolevaid lepinguid (SLA), teavitatakse kasutajat maksimaalsest eeldatavast intsidendi lahendamise ajast (tähtajast). Need kuupäevad on samuti fikseeritud. Juhtumile omistatakse kordumatu number ja kasutajat teavitatakse juhtumi numbrist, et seda järgmistel kõnedel täpselt tuvastada.

Otse kasutaja soovil peaksid Service Deski spetsialistid intsidendi eeldiagnoosi tegema, et võimalusel saada vajalikku teavet intsidendi põhjuse väljaselgitamiseks, samuti õigeks kategoriseerimiseks ja järgmisele tugiliinile üleviimiseks. Kui juhtunu lahendamine on Service Deski töötaja pädevuses, siis saab seda koheselt lahendada. Teeninduskeskus saadab juhtumid, mida pole valmis lahendus või väljaspool temaga töötava töötaja pädevust järgmise taseme tugimeeskond, kellel on rohkem kogemusi ja teadmisi. See rühm uurib ja lahendab juhtumit või edastab selle järgmisele toe tasemele.

Juhtumi lahendamise käigus saavad erinevad spetsialistid uuendada selle kohta käivat registreerimiskirjet, muutes hetkeseisu, teavet tehtud toimingute kohta, vaadata üle klassifikatsiooni ning uuendada töötanud töötaja aega ja koodi.

Enamikul juhtudel vastutab teeninduskeskus kui kõigi juhtumite "omanik" lahenduse edenemise jälgimise eest. See teenus peaks teavitama kasutajat ka juhtumi olekust. Kasutajate tagasiside võib olla asjakohane pärast olekumuutust, näiteks intsidendi edastamist järgmisele tugiliinile, hinnangulise lahendamise aja muutust, eskaleerumist jne. Järelevalve ajal toimub funktsioonide eskaleerimine teistele tugimeeskondadele või hierarhiline eskaleerimine juhtimisotsuste tegemiseks. võimalik.

Eskalatsioon – tegevused, mille eesmärk on hankida eesmärkide saavutamiseks vajadusel lisaressursse teenindustase või vastama klientide ootustele. Mis tahes protsessi käigus võib olla vajalik eskaleerimine IT juhtimine teenuseid, kuid on kõige sagedamini seotud juhtumite haldamise, probleemide haldamise ja klientide kaebuste haldamisega. Eskalatsiooni on kahte tüüpi: funktsionaalne eskalatsioon ja hierarhiline eskalatsioon.

Pärast analüüsi edukat lõpetamist ja intsidendi lahendamist fikseerib töötaja info rakendatud lahenduse kohta. Kui teatud ajahetkel ei ole võimalik intsidenti täielikult lahendada, tuleks selle mõju võimaluse korral vähendada, rakendades lahendust. Halvimal juhul, kui lahendust ei leita, jääb juhtum lahtiseks.

Pärast kasutajat rahuldava lahenduse juurutamist saadab tugimeeskond juhtumi tagasi teeninduspunkti. Teeninduskeskus võtab juhtumist teatanud töötajaga ühendust, et saada kinnitus, et probleem lahenes. Kui ta seda kinnitab, võib intsidendi lõpetada; vastasel juhul jätkub protsess sobival tasemel. Intsidendi sulgemisel peate värskendama viimast kategooriat, prioriteeti, teenuseid, mida juhtum mõjutab, ja tõrke põhjustanud CI-d.

Juhtumihaldusprotsessi põhimõtted ja aluspõhimõtted

Protsessi tõhususe ja tõhususe tagamiseks tuleb järgida intsidentide haldamise protsessi põhimõtteid, mis võivad hõlmata järgmisi aspekte:

• Hea koordineerimine kasutajate ja intsidentidele reageerijate vahel
• Juhtumid tuleb lahendada ettevõtjaga kokkulepitud aja jooksul
• Kasutajate rahulolu peab olema tagatud vahejuhtumite lahendamise kõigis etappides
• Juhtumijuhtimise tegevused peaksid olema vastavuses teenuste tasemete ja tugieesmärkidega, mis põhinevad tegelikel ärivajadustel
• Kõiki intsidente hallatakse ja nende andmed salvestatakse ühtsesse juhtimissüsteemi
• Kõigil intsidentidel peab olema standardne kategoriseerimisskeem, mis ühtib ettevõtte äriprotsessidega.
• Juhtumite dokumente tuleks korrapäraselt kontrollida, et tagada õige sisestus ja õige klassifitseerimine.
• Kõigil intsidentide kirjetel peaks võimaluse piires olema ühine vorming ja teabeväljade komplekt.
• Juhtumite tähtsuse järjekorda seadmiseks ja eskaleerimiseks peaksid ettevõttega kokku leppima ühised kriteeriumid

Järgnevalt kirjeldatakse põhiprintsiipe, mida tuleks intsidentide haldamise juurutamisel arvesse võtta.

Ajaskaala – kõikide juhtumite töötlemise etappide jaoks tuleb kokku leppida ajaraamid (need varieeruvad olenevalt juhtumi prioriteetsuse tasemest). Kõik tugirühmad peaksid olema nendest ajavahemikest täielikult teadlikud.

Paljud juhtumid ei ole uued – need on seotud millegagi, mis on juba juhtunud ja võib korduda. Sel põhjusel oleks mõistlik eelnevalt määratleda "standardsed" intsidentide mudelid ja rakendada neid asjakohaste juhtumite ilmnemisel.

Juhtumimudel on etteantud viis konkreetset tüüpi intsidendi käsitlemiseks.

Juhtumimudel võib sisaldada järgmisi aspekte:

• Eelmääratletud toimingute jada teatud tüüpi intsidendi käsitlemiseks
• Ettemääratud vastutus
• Ettevaatusabinõud enne intsidendi lahendamist
• Ajaraamid ja eskalatsiooniprotseduurid
• Tõendid tegevuse kohta (kirjed, logid)

Suuremad intsidendid tuvastatakse intsidentide haldamise protsessi osana.

Märkimisväärne vahejuhtum põhjustab ettevõttele märkimisväärset kahju ja sellel peaks olema eraldi käsitlemisprotseduurid.

Juhtumeid tuleb jälgida kogu nende elutsükli jooksul, et tagada nende nõuetekohane käsitlemine ja nende oleku kohta teatamine. Juhtumihaldussüsteemis saab olekukoode siduda juhtumitega, et näidata, kus need elutsükli suhtes asuvad. Nende näidete hulka võivad kuuluda:

Juhtumi olek näitab intsidendi olekut töötlemisel. Olekute näited on järgmised:

• uus;
• vastu võetud;
• planeeritud;
• määratud;
• aktiivne;
• edasi lükatud;
• lubatud;
• suletud.

Juhtumihaldusprotsessi mõõdikud

Juhtida ja hinnata intsidentide haldamise protsessi tõhusust ning tagada tagasisidet koos teiste haldusprotsessidega soovitab ITIL kasutada järgmisi põhimõõdikuid (CSF-id ja KPI-d):

• CSF Juhtumite kiire lahendamine, minimeerides nende mõju ettevõttele
• KPI Keskmine intsidendi lahendamiseks kulunud aeg
• KPI Juhtumite jaotus staatuse järgi
• KPI Esimese rea toega lahendatud juhtumite protsent
• KPI Kaugjuhtimisega lahendatud juhtumite protsent
• KPI Lahendatud juhtumite arv, mis ei mõjutanud ettevõtet
• CSF IT-teenuse kvaliteedi tugi
• KPI Juhtumite koguarv (võrdlusnäitaja)
• KPI mahajäämuse järjekorra suurus teenuse kohta
• KPI Suuremate vahejuhtumite arv ja protsent teenuse kohta
• CSF-i kasutajate rahulolu tugi
• KPI Keskmine küsitluse skoor kasutajate/klientide lõikes
• KPI Vastustega rahulolu protsent võrreldes küsitluses osalejate koguarvuga
• CSF Läbipaistvuse ja suhtluse suurendamine juhtumite lahendamisel äri- ja IT-tugipersonali vahel
• KPI Keskmine kasutajatoele tehtud kõnede või muude kasutajatega kontaktide arv juhtumite kohta, millest on juba teatatud
• KPI Kaebuste ja probleemide arv seoses side sisu ja kvaliteediga intsidentide lahendamisel
• CSF Juhtumijuhtimise tegevuste prioriteetide vastavusse viimine äritegevuse prioriteetidega
• KPI SLA eesmärke rikkumata lahendatud juhtumite protsent
• KPI Keskmine kulu juhtumi kohta
• CSF Tagamine, et vahejuhtumitega tegelemisel kasutatakse standardseid meetodeid ja protseduure
• KPI Valesti määratud juhtumite arv ja protsent
• KPI Valesti klassifitseeritud juhtumite arv ja protsent
• KPI Service Deski töötajate poolt käsitletud juhtumite arv ja protsent
• KPI Muudatuste ja väljalasetega seotud juhtumite arv ja protsent

Riskid ja raskused

Juhtumihalduse rakendamisel võtke arvesse järgmist. võimalikud riskid ja raskusaste:

• Vahejuhtumite varajase avastamise vajadus – sündmuste haldamise (seire) tööriistade seadistamine, samuti kasutajate koolitus intsidentidest teavitamisel
• Juhtumite täieliku registreerimise vajadus
• Vajadus juurutada piisav automatiseeritud süsteem juhtimine ja selle integreerimise tagamine erinevate IT juhtimissüsteemidega (näiteks CMS)
• Vajadus ühtse kontaktpunkti kõrge kättesaadavuse järele
• Vajadus tagada protsessi järgimine ja tuvastada protsessi möödaviigud – kui kasutajad parandavad ilmnevad vead ise või pöörduvad otse spetsialistide poole ilma kehtestatud protseduure järgimata, ei saa IT-organisatsioon teavet tegelikult pakutava teenuse taseme, vigade arvu ja muu kohta. rohkem. Juhtimisaruanded ei kajasta samuti olukorda piisavalt.
• Ressursipuudus intsidentidega tegelemisel, ülekoormus intsidentidega ja venitamine – juhtumite arvu ootamatu kasvu korral ei pruugi õigeks registreerimiseks piisavalt aega jääda, sest enne ühelt kasutajalt juhtunu kohta info sisestamise lõppu muutub see vajalik järgmise hooldamiseks. Sel juhul ei pruugi juhtumikirjelduste sisestamine olla piisavalt täpne ja surnukehade tugijuhtumite määramise protseduure ei tehta korralikult. Seetõttu on lahendused ebakvaliteetsed ja töömaht suureneb veelgi. Juhtudel, kui avatud intsidentide arv hakkab kiiresti kasvama, võib organisatsioonisisese lisaressursside erakorraline eraldamine vältida töötajate ülekoormust.
• Teenuste kataloogi ja teenusetaseme lepingute (SLA) puudumine – kui toetatavad teenused ja tooted pole selgelt määratletud, võib juhtumite haldamise spetsialistidel olla raske kasutajatele õigustatult keelduda.
• Juhtkonna ja personali vähene pühendumus protsessipõhisele lähenemisele – protsessipõhist lähenemist kasutavate juhtumite käsitlemine nõuab tavaliselt kultuurimuutust ja töötajate suuremat vastutust oma töö eest. See võib organisatsiooni sees põhjustada tõsist vastupanu. Tõhus intsidentide haldamine eeldab, et töötajad mõistavad ja tõesti pühenduvad protsessile, mitte ainult osalemisele.

Äriväärtus

Rakendades ITIL-i soovitustele vastava intsidentide haldamise protsessi ja lahendades kõik juurutamise käigus tekkida võivad raskused, on ettevõttele kui tervikule võimalik saada järgmine väärtus:

• Võimalus vähendada ettenägematuid töid ning intsidentidest tingitud äri- ja IT-kulusid
• Võimalus avastada ja lahendada vahejuhtumeid, vähendades seisakuid ja suurendades äriteenuste kättesaadavust
• Oskus jaotada IT-ressursse vastavalt oma äriprioriteedile
• Võimalus algatada teenuse täiustamist, tuginedes teadmistele juhtumite olemuse kohta
• Võimalus tuvastada personali täiendava koolituse vajadus

Juhtumihaldusprotsess on ettevõttele oluliselt "nähtav" ja võimaldab pärast selle rakendamist suhteliselt kiiresti tulemusi näha. Seetõttu on intsidentide haldamine sageli üks esimesi protsesse, mida rakendatakse üleminekul protsessipõhisele IT-haldusorganisatsioonile. Selle lisaeelis seisneb selles, et intsidentide haldamine võimaldab "esile tuua" teisi IT-juhtimise valdkondi, mis nõuavad tähelepanu – tagades seeläbi vajalike ressursside eraldamise teiste IT-haldusprotsesside juurutamiseks.

Aja jooksul võib tekkida vajadus IT-taristut muuta. Selle põhjuseks võivad olla mitmed põhjused – vajadus probleemi lahendamiseks, soov parandada IT-teenuste kvaliteeti, vananev infrastruktuur või muudatused seadusandluses.

Kogemus näitab, et kui muudatusi ei ole korralikult kontrollitud, võivad nende rakendamise tagajärjel sageli tekkida intsidendid: tõrked teenuste tavapärasel osutamisel. Selliste juhtumite põhjused võivad olla erinevad: töötajate hooletus, ressursside nappus, ebapiisav koolitus, muudatuse mõju halb analüüs, ebatäiuslik testimine jne. Juhtumite arv võib suureneda, igaüks neist nõuab kiiret tegutsemist, mis omakorda võib viia uute juhtumite ilmnemiseni. Igapäevane planeerimine ei suuda sageli suureneva töökoormusega toime tulla.

Muuda – kõige selle lisamine, muutmine või eemaldamine, mis võib mõjutada IT-teenuseid. See raamistik peaks hõlmama kõiki muudatusi arhitektuurides, protsessides, tööriistades, mõõdikutes ja dokumentatsioonis, samuti muudatusi IT-teenustes ja muudes konfiguratsiooniüksustes.

ITIL-is muudatuste juhtimise eest vastutavad mitmed teenuse ülemineku protsessid: muudatuste haldus, teenusevarade ja konfiguratsioonihaldus ning väljalaske ja juurutamise haldus.

Muudatuste juhtimine on protsess, mis vastutab kõigi muudatuste elutsükli haldamise eest, nii et kasulikke muudatusi saaks rakendada IT-teenuseid minimaalselt häirides.

Eesmärgi saavutamise osana on muudatuste juhtimise protsessi eesmärgid:

• Reageerige klientide muutuvatele ärinõuetele, maksimeerides äriväärtust ning vähendades intsidente, tõrkeid ja ümbertöötamist
• Vastake ettevõtete ja IT muudatuste taotlustele, et tagada teenuste vastavus ettevõtte vajadustele
• Tagada, et kõik muudatused registreeritakse, hinnatakse, autoriseeritakse, prioriseeritakse, planeeritakse, testitakse, rakendatakse, dokumenteeritakse ja vaadatakse üle kontrollitud viisil
• Veenduge, et kõik konfiguratsiooniüksuste muudatused oleksid konfiguratsioonihaldussüsteemis (CMS) logitud.
• Optimeerige äririske

Muudatuste haldamise protsessi ulatus hõlmab IT infrastruktuuri, protsesside, tööriistade, mõõdikute ja dokumentatsiooni muudatusi, samuti IT-teenuste ja muude konfiguratsiooniüksuste muudatusi.

Muudatuste juhtimise tegevused

Joonis näitab üldine skeem muutuste juhtimise protsess. Muudatuste kontrolli tagamiseks tuleb kõik muudatused logida. Kui vajalik muudatuse tegemine protsessi raames tuleb esitada muudatustaotlus (RFC).

Muudatustaotlus on ametlik ettepanek muudatuse tegemiseks. Muudatustaotlus sisaldab üksikasju kavandatava muudatuse kohta ja võib olla kirjutatud paberkandjal või elektroonilisel kujul. Mõistet "muutmistaotlus" kasutatakse sageli vääralt, et tähendada "muutmiskirjet" või "muudatust" iseenesest.

ITIL-i muudatuste haldamise protsessis on kolme tüüpi muudatusi:

Standardmuudatus on eelnevalt volitatud muudatus, mis on madala riskiga, suhteliselt levinud ja järgib mõnda protseduuri või protseduuri. tööjuhised. Näiteks parooli lähtestamine või uue töötaja varustamine standardvarustusega. RFC-d ei pea standardmuudatusi rakendama, need salvestatakse ja jälgitakse mõne muu mehhanismi, näiteks teenusepäringute abil.

Hädaolukorra muudatus on muudatus, mis tuleb ellu viia nii kiiresti kui võimalik, näiteks suure intsidendi lahendamiseks või turvavärskenduse installimiseks. Muudatuste juhtimise protsess näeb tavaliselt ette konkreetse protseduuri hädaolukordade muudatuste juhtimiseks.

Tavaline muudatus on muudatus, mis ei ole kiireloomuline ega standardne. Tavalisi muudatusi käsitletakse muudatuste juhtimise protsessi konkreetsete etappide kaudu.

Seega, kui muudatus kuulub standardi kategooriasse, tuleks seda hallata teenusetaotluste haldusprotsessi osana. Kas see on teatud muutus standard või norm määratakse igale organisatsioonile eraldi. Erakorraliste muudatuste puhul tavalisi protseduure ei kasutata, kuna vajalikud vahendid tagatakse koheselt.

Järgmine on näide teabest, mis võib sisalduda muudatuste taotlustes (RFC).

• taotluse identifitseerimisnumber;
• päringuga seotud probleemi/teadaoleva vea number (kui see on olemas);
• vastavate konfiguratsioonielementide kirjeldus ja määratlus;
• muudatuse põhjus, sealhulgas põhjendus ja oodatav äritulemus;
• muudetava konfiguratsioonielemendi praegune ja uus versioon;
• päringu esitaja nimi, aadress ja telefoninumber;
• taotluse esitamise kuupäev;
• vajalike ressursside ja aja eelhinnang;
• jne.

Muudatustaotluse loob algataja, kelleks võib olla üksikisik või inimeste rühm. Kui on vaja teha olulisi muudatusi, võidakse nõuda muutmisettepanekut.

Muudatusettepanek – dokument, mis sisaldab potentsiaalse teenuse või olulise muudatuse kõrgetasemelist kirjeldust, sellega seotud ärijuhtumit ja eeldatavat rakendamise ajakava. Muudatustettepanekud luuakse tavaliselt teenuseportfelli haldamise protsessi osana ja esitatakse muudatuste haldamise protsessile autoriseerimiseks. Muutuste juhtimise protsessi osana hinnatakse võimalikku mõju teistele teenustele, jagatud ressurssidele ja üldisele muudatuste plaanile.

Kõik saadud muudatustaotlused tuleb logida ja iga muudatuse kohta luua muudatuste kirje.

Muudatuse kirje – kirje, mis sisaldab üksikasjalikku teavet muudatuse kohta. Iga muudatus registreerib dokumendid eluringüks muutus. Iga saadud muudatustaotluse kohta luuakse muudatuskirje, isegi kui see hiljem tagasi lükatakse.

Pärast muudatustaotluse (RFC) esitamist kontrollib muudatuste haldamine esmase kontrolli, et näha, kas taotlused on ebaselged, ebaloogilised, ebapraktilised või mittevajalikud. Sellised taotlused lükatakse tagasi koos põhjuste selgitusega. Taotluse esitavale töötajale tuleks alati anda võimalus oma taotlust kaitsta.

Muudatuse hindamiseks soovitab ITIL vastata 7 küsimusele (7 vastust):

• Kes on algataja? (TÕSTAS) (Kes TÕSTAS muudatuse?)
• Mis on põhjus? (PÕHJUS) (Mis on muudatuse PÕHJUS?)
• Millist tulemust on vaja? (TAGASTAMINE) (Mis on muudatusest nõutav TAGASTUS?)
• Millised on muudatusega kaasnevad riskid? (RISKID) (Millised RISKID muudatusega kaasnevad?)
• Milliseid ressursse on muudatuse tegemiseks vaja? (RESSURSSID) (Milliseid RESSURSSE on muudatuse edastamiseks vaja?)
• Kes vastutab muudatuse loomise, testimise ja rakendamise eest? (VASTUTUSLIK) (Kes VASTUTAB muudatuse koostamise, testimise ja rakendamise eest?)
• Milline on selle seos teiste muutustega? (SUHE) (Milline on SUHE selle muudatuse ja muude muudatuste vahel?)

Kui muudatustaotlus (RFC) võetakse töötlemiseks vastu, sisaldab muudatuste kirje muudatuse edasiseks töötlemiseks vajalikku teavet.

Kirjele võidakse hiljem lisada järgmine teave:

• määratud prioriteet;
• mõju hindamine ja kulumõju;
• kategooria;
• muudatuste juhtimise protsessijuhi soovitused;
• muudatuse lubamise kuupäev ja kellaaeg;
• ürituse kavandatud kuupäev;
• plaan naasta algsesse olekusse;
• toetuse nõuded;
• muuta plaani;
• teave arendaja ja muudatuse elluviimise eest vastutavate töötajate kohta;
• muudatuse tegelik kuupäev ja kellaaeg;
• tulemuste hindamise kuupäev;
• testitulemused ja leitud probleemid;
• taotluse tagasilükkamise põhjused (vajadusel);
• tulemuste hindamine.

Muudatustaotluse (RFC) saamisel määratakse selle prioriteet ja kategooria. Prioriteet näitab, kui oluline see taotlus teistega võrreldes on. Selle omakorda määrab selle kiireloomulisus ja mõju aste.

Prioriteedikoodisüsteemi näide:

• Madal prioriteet – muudatus on soovitav, kuid juurutamine võib viibida sobivama ajani (näiteks järgmise väljalaske või plaanilise hoolduseni).
• Tavaline prioriteet – kiireloomulisus ja suur mõju, kuid muudatustega ei tohiks viivitada.
• Kõrge prioriteet – muudatus puudutab tõsist viga, mis mõjutab paljusid kasutajaid, või uut ebatavalist viga, mis mõjutab suurt rühma kasutajaid, või muid kiireloomulisi probleeme.
• Kõrgeim prioriteet – muudatustaotlus (RFC) puudutab probleemi, millel on oluline mõju kliendikriitilisele teenusele. Selle prioriteediga muudatused liigitatakse "hädaolukordadeks".

• Madal mõju – muudatus, mis nõuab vähe tööd.
• Oluline mõju – muudatus, mis nõuab märkimisväärset pingutust ja millel on oluline mõju IT-teenustele. Neid muudatusi arutatakse muudatuste nõukogus (CAB), et määrata kindlaks vajalikud jõupingutused (ressursid jne) ja võimalik mõju.
• Suurim mõju on muutus, mis nõuab märkimisväärseid jõupingutusi. protsessijuhil tuleb esmalt hankida volitus muudatuse tegemiseks IT-juhtimise või IT juhtkomiteesse, misjärel esitatakse muudatus muudatuste nõukogule (CAB).

Muudatuste nõukogu – rühm inimesi, kes aitavad muudatusi hinnata, tähtsuse järjekorda seada, lubada ja ajastada. Muudatuste nõukogus on tavaliselt IT-teenuse pakkuja, ettevõtte ja kolmandate isikute (nt töövõtjate) esindajad.

Neid koode saab esitada numbritega, näiteks: madal = 1 / kõrge = 3

Enamik muudatusi kuulub kahte esimesse kategooriasse. Lähtudes muudatuse mõju hinnangust, tuleks määrata näiteks muudatuse volituse tase (muutmisvolitus), nagu on näidatud joonisel.

Lisaks klassifikatsioonile tuleks välja selgitada ka tehnilise lahenduse töösse kaasatud meeskonnad ja teenused, mida muudatus puudutab.

Kui vastavad asutused kiidavad muudatuse heaks, edastatakse heakskiidetud muudatused vastavatele tehnikutele, kes muudatused kavandavad ja rakendavad. Muutuste juhtimise protsessi osana koordineeritakse elluviimist. Otsene arendus, testimine ja juurutamine toimub osana realismi ja juurutamise juhtimise protsessist. Muudatuse rakendamine toimub pärast testitulemuste kinnitamist muudatuste juhtimise protsessi osana.

Muudatuste juhtimise protsessi osana peetakse muudatuste ajakava.

Muudatuste ajakava - dokument, milles on loetletud kõik heakskiidetud muudatused ja nende rakendamise kavandatud kuupäevad, samuti ligikaudsed kuupäevad hilisemate muudatuste rakendamine.

Muudatuste nõukogu (CAB) liikmed annavad nõu, kuidas muudatusi planeerida, kuna arvesse tuleb võtta töötajate kättesaadavust, ressursse, kulusid, kaasatud teenuste erinevaid aspekte ja klientide panust. Muudatuste nõukogu (CAB) on nõuandev organ ja kohtub regulaarselt. Muudatuste planeerimise teave tuleks levitada aegsasti enne muudatuste nõukogu koosolekut. Asjakohane dokumentatsioon ja teave päevakorrapunktide kohta tuleks samuti levitada enne koosolekut.

Muudatusnõukogu koosoleku päevakord peaks sisaldama mitmeid alalisi punkte, sealhulgas:

• Ebaõnnestunud või volitamata muudatused
• Muudatustaotlused (RFC-d) esitatakse muudatuste nõukogu liikmetele prioriteetsuse järjekorras
• Muudatuste taotlused (RFC-d) vaatas läbi muudatuste nõukogu
• Muudatuste planeerimine ja muudatuste ajakava uuendamine
• Hinnangud tehtud muudatustele
• Muudatuste juhtimise protsess, täiendused ja protsessi muudatused
• Protsessi saavutused ja ärikasud muutuste juhtimise protsessi kaudu
• Muudatused pooleli ja muudatused pooleli
• Muudatustaotluste ajakava läbivaatamiseks järgmisel muudatuste nõukogul
• Kontrollige, kas teenusevara ja konfiguratsioonihaldusprotsess ei tuvasta volitamata muudatusi

Muudatuse elluviimise üldise skeemi osana tuleks välja töötada protseduur algseisundisse naasmiseks juhuks, kui muudatus ei anna soovitud tulemust. Muudatuste juhtkond ei peaks heaks kiitma muudatuse rakendamist sisseregistreerimise protseduuri puudumisel.

Tehtud muudatusi on vaja hinnata, välja arvatud võimalikud standardmuudatused. Vajadusel otsustab muudatuste nõukogu (CAB) edasised järelmeetmed. Kaaluda tuleks järgmisi küsimusi:

• Kas muutus saavutas oma eesmärgid?
• Kas kasutajad ja kliendid on rahul?
• Kas kõrvalmõjusid ei olnud?
• Kas ressursse kasutati muudatuse elluviimiseks plaanipäraselt?
• Kas muudatus viidi ellu õigeaegselt ja ilma kulude ületamiseta?
• Kas rakendusplaan toimis õigesti?
• Kas taastusplaan toimis vajadusel õigesti?
• Jne.

Kui muudatus õnnestub, saab muudatustaotluse (RFC) sulgeda. See toimub rakendamise tulemuste hindamise (PIR) etapis. Kui muudatus ebaõnnestub, jätkub protsess uue lähenemisviisi abil kohast, kus see ebaõnnestus. Mõnikord on parem minna tagasi ja luua uus või muudetud muudatustaotlus (RFC). Ebaõnnestunud muudatusega jätkamine muudab olukorra sageli hullemaks.

Rakendamise mõju hindamine (PIR) on ülevaatus, mis tehakse pärast muudatuse või projekti elluviimist. Rakendamise hindamine määrab muudatuse või projekti edukuse ja selgitab välja parendusvõimalused.

Olenevalt muudatuse iseloomust võib hindamist läbi viia kas mõne päeva või mõne kuu pärast. Näiteks igapäevaselt kasutatava personaalarvuti muudatust saab hinnata mõne päeva pärast, kuid kord nädalas kasutatavas süsteemis saab muudatust teha alles kolme kuu pärast.

Erakorraliste muudatuste tegemine

Ükskõik kui hästi planeerimine on tehtud, võib ette tulla muudatusi, mis nõuavad kõige kõrgemat prioriteetsust. Erakorralised muudatused on ettevõtte jaoks väga olulised ja need tuleks võimalikult kiiresti ellu viia. Need nõuavad kiireks töötlemiseks eraldi protseduure, kuid üldise kontrolliga muudatuste haldamise protsessist. Sellise olukorra korral võidakse korraldada erakorraliste muutuste nõukogu (eCAB) koosolek.

Hädaolukordade muudatuste nõukogu (eCAB) – grupp inimesi muutuste nõukogus, kes teevad otsuseid hädaolukorra muudatuste kohta. Otsuse erakorraliste muudatuste juhatuse liikmete koosseisu kohta saab teha vahetult koosoleku korraldamisel. Osalemisvajaduse määramisel lähtutakse kiireloomulise muudatuse iseloomust.

Kui selleks pole aega või kui taotlus saabus pärast tööaega, peab muutmisvolituse saamiseks olema alternatiivne viis. See ei pea olema näost näkku kohtumine, selle asemel saab kasutada konverentskõnet.

Muutuste juhtimise protsessi poliitikad ja aluspõhimõtted

Protsessi tõhususe ja tõhususe tagamiseks tuleb järgida muudatuste juhtimise protsessi põhimõtteid, mis võivad sisaldada järgmist.

• Volitamata muudatuste absoluutne lubamatus, muutuste kultuuri loomine
• Muudatuste juhtimise vastavusse viimine muudatuste juhtimise protsesside ja kliendiprojektidega
• Muudatuste liigitamine, nt uuenduslikud, uurimuslikud, ennetavad, korrigeerivad muudatused
• Vastutuse kindlaksmääramine muudatuste eest kõigis kasutustsükli etappides
• Juhtkonna vastutuse lahusus
• Looge muudatuste eest ühtne vastutuspunkt, et vähendada vastuoluliste muudatuste võimalust ja ebaõnnestumise ohtu tootmiskeskkonnas

Muudatuste juhtimise protsessi mõõdikud

Muudatuste juhtimise protsessi efektiivsuse juhtimiseks ja hindamiseks ning teistele juhtimisprotsessidele tagasiside andmiseks soovitab ITIL kasutada järgmisi võtmenäitajaid:

• Kliendi nõudeid rahuldavate muudatuste protsent
• Muudatusest saadav kasu, mis on väljendatud kui "tehtud täiustuste väärtus" + "välditud negatiivne mõju" võrreldes muudatuse maksumusega
• Ebatäpsetest spetsifikatsioonidest või ebapiisavast mõjuhinnangust põhjustatud teenuste katkestuste, defektide ja ümbertöötamise vähendamine
• Volitamata muudatuste arvu vähendamine
• Vähendatud muudatustaotluste järjekord, planeerimata muudatuste määr ja kiirparandused
• Taastamist nõudvate muudatuste arvu vähendamine
• Ebaõnnestunud muudatuste arvu vähendamine
• Keskmine täitmisaeg kiireloomulisuse/prioriteedi/tüübi järgi
• Muudatusega seotud juhtumite arv
• Muuda hinnangu täpsust

Äriväärtus

Rakendades ITIL-i soovitustele vastava muudatuste juhtimise protsessi ja lahendades kõik juurutamise käigus tekkida võivad raskused, on võimalik saada ettevõttele tervikuna järgmine väärtus:

• Seadistage prioriteedid ja vastake ettevõtete ja klientide muudatustaotlustele
• Teenuste kokkulepitud nõuetele vastavate muudatuste elluviimine on optimaalselt kuluefektiivne
• Ebaõnnestunud muudatuste arvu vähendamine, mis põhjustavad teenuse katkemist, defekte ja ümbertöötamist
• Muudatuste elluviimine vastavalt ettevõtte määratud ajakavale
• Jälgige muutusi oma klientide teenuse ja varade elutsükli jooksul
• Parem hinnang muudatuste kvaliteedi, aja ja maksumuse kohta
• Teenuse muudatustega (kasutuselevõtt või dekomisjoneerimine) seotud riskide hindamine
• Personali tootlikkuse tõstmine planeerimata või "kiireloomuliste" muudatuste arvu minimeerimise kaudu ja selle tulemusena teenuste kättesaadavuse suurendamine
• Parandusmuudatuste kiirema ja edukama rakendamise tõttu väheneb keskmine taastumisaeg
• Säilitage suhtlust ettevõtte muutmise protsessiga, et tuvastada ettevõtte täiustamise võimalused

Kas soovite, et teile pakutavad teenused oleksid kvaliteetsed? Ma arvan, et jah. ITSM-i ja eelkõige ITIL-i üks peamisi ülesandeid on kvaliteetsete IT-teenuste pakkumine.

IT-teenuste haldus (ITSM) on ärivajadustele vastavate kvaliteetsete IT-teenuste juurutamine ja haldamine.

Alati ei ühti IT-teenuse pakkujate ja klientide arvamus teenuste kvaliteedi osas.

Kvaliteet on toote, teenuse või protsessi võime pakkuda tarbija poolt oodatud väärtust. Näiteks võib komponendi kvaliteeti lugeda kõrgeks, kui selle jõudlus vastab ootustele ja tagab vajaliku töökindluse.

Ülaltoodud on kvaliteedi määratlus ITIL-i järgi. Need. kui soovime pakkuda kvaliteetseid teenuseid, on vajalik, et need vastaksid kliendi ootustele.

Nagu öeldakse: "Sa ei saa hallata seda, mida te ei saa mõõta." Seega on kvaliteetse teenuse osutamise tagamiseks vaja esmalt selgitada kliendi ootused IT-teenustele, need kokku leppida, võimalusel neid kuidagi piirata, näiteks kui kliendi nõue on ebareaalne, ning esitada need mõõdetav vorm. Seejärel jääb üle veenduda, et teenuse tegelikud parameetrid vastavad kliendi ootustele ja kinnitada seda asjakohaste aruannetega.

ITIL-i järgi vastutab teenusetaseme haldamise protsess, mis on ülioluline, iga teenuse ja sellega seotud IT-tegevuste teenusetaseme eesmärkide ja kohustuste kokkuleppimise ja dokumenteerimise eest teenusetaseme lepingus (SLA) ja teenusetaseme nõuetes (SLR). iga IT-teenuse pakkuja organisatsioon.

Teenusetaseme juhtimine on protsess, mis vastutab teostatavate teenusetaseme lepingute läbirääkimiste ja läbirääkimiste ning nende täitmise tagamise eest. Teenusetaseme haldus vastutab selle eest, et IT-teenuste haldusprotsessid, operatiivtasandi kokkulepped ja välislepingud vastaksid kokkulepitud teenusetaseme eesmärkidele. Teenusetaseme haldamine jälgib teenindustasemeid ja annab nendest aru, viib koos klientidega läbi regulaarseid teenuste hindamisi ja tuvastab vajalikud täiustused.

Teenusetaseme leping (SLA) on leping IT-teenuse pakkuja ja kliendi vahel. Teenusetaseme lepingus kirjeldatakse IT-teenust, dokumenteeritakse teenusetaseme eesmärgid, määratakse osapoolte - IT-teenuse pakkuja ja kliendi - vastutusvaldkonnad. Üks SLA võib hõlmata mitut IT-teenust või mitut klienti.

Teenusetaseme nõue (SLR) on kliendi nõue IT-teenusele. Teenusetaseme nõuded põhinevad ärieesmärkidel ja neid kasutatakse teenusetaseme eesmärkides läbirääkimisteks ja nende kokkuleppimiseks.

Teenusetaseme eesmärkide kujundamise kaudu seab teenusetaseme haldamine nõuded ja jõudlusparameetrid paljudele muudele operatiivsetele ja taktikalistele ITIL-i protsessidele, näiteks juhtumite haldamine, teenusetaotluste haldamine, probleemihaldus, muudatuste haldamine, väljalaskehaldus, saadavuse haldamine, jne.

Teenusetaseme eesmärk – teenusetaseme lepingus sätestatud kohustused. Teenusetaseme eesmärgid põhinevad teenusetaseme nõuetel ja on vajalikud IT-teenuse ärieesmärkide täitmise tagamiseks. Teenusetaseme eesmärgid peaksid olema SMART ja põhinevad tavaliselt peamistel tulemusnäitajatel.

Kui need teenusetaseme eesmärgid ühtivad ja kajastavad täpselt ärinõudeid, on teenusepakkujate pakutav teenus ärinõuetele vastavuses ning klientide ja kasutajate ootustele teenuse kvaliteedi osas. Kui eesmärgid ei vasta ärivajadustele, siis ei vasta teenusepakkujate jõudlus ja teenindustase äri ootustele ning võib tekkida probleeme. Teenusetaseme leping – kindluse või kindlustunde tase teenusepakkuja pakutava teenuse kvaliteedi taseme kohta iga ettevõtte pakutava teenuse kohta.

Teenusetaseme haldamine on protsess, mis ühendab IT-teenuse pakkuja ja kliendi. Sellel protsessil on järgmised ülesanded:

• Pakutavate IT-teenuste taseme määratlemine, dokumenteerimine, kokkuleppimine, jälgimine, aruandlus ja hindamine
• Hoida ja parandada suhteid ja suhtlust ettevõtete ja klientidega
• Veenduge, et kõigi IT-teenuste jaoks on täpsed ja mõõdetavad eesmärgid
• Jälgige ja parandage klientide rahulolu teenuse kvaliteediga
• Tagada IT ja klientide teenindustaseme ootuste selgus ja ühemõttelisus
• Tagada, et ennetavaid teenusetaseme täiustusi rakendatakse, kui see on põhjendatud ja teostatav.

Teenindustaseme juhtimine peaks tagama kliendiorganisatsioonide ja ettevõtete juhtide pideva suhtluse ja suhtluse. See peaks andma ettevõttele tunde teenusepakkujast ja ettevõtte IT-teenuse pakkujast.

Teenuse taseme haldamise protsessi ulatus peaks hõlmama järgmist:

• Ettevõtlusega suhete korraldamine
• Arutelu ja kokkulepe kehtivad nõuded ja eesmärgid, dokumenteerida ja säilitada pakutavate teenuste SLA
• Nõuete ja eesmärkide arutamine ja kokkuleppimine, peegelkaamerate dokumenteerimine ja hooldamine kavandatavate uute ja muudetud teenuste jaoks.
• SLA eesmärkide toetamiseks töötage välja ja säilitage operatiivtasandi kokkulepped (OLA).
• Kõigi välislepingute (UC) hindamine ja vastavusse viimine SLA eesmärkidega – koos tarnijate juhtimisega.
• Rikete ennetamine, riskide maandamine ja teenuse täiustamise rakendamine toimivad koos teiste protsessidega.
• Kõigi teenuste aruandlus ja hindamine ning SLA eesmärkidest kõrvalekallete analüüs.
• Teenuse täiustamise kava (SIP) algatamine ja koordineerimine.

Operatiivtasandi leping (OLA) on leping IT-teenuse pakkuja ja sama organisatsiooni mõne muu osa vahel.

Alusleping (UC) on leping IT-teenuse pakkuja ja kolmanda osapoole vahel. Kolmas osapool pakub kaupu või teenuseid, mis toetavad IT-teenuste osutamist kliendile. Välisleping määratleb ühes või mitmes teenusetaseme lepingus kokkulepitud teenusetaseme eesmärkide saavutamiseks vajaliku ulatuse ja kohustused.

Teenuse täiustamise plaan (SIP) on ametlik plaan protsessi või IT-teenuse täiustamiseks.

Teenusetaseme haldusprotsessi tegevused

Joonisel on kujutatud teenusetaseme haldamise protsessi üldskeem.

Kuna ettevõtted muutuvad IT-teenustest sõltuvamaks, suureneb nõudlus kvaliteetsete IT-teenuste järele. Nagu ülalpool määratletud, määravad teenuse kvaliteedi kliendi ootused, samuti nende ootuste pidev juhtimine, teenuse stabiilsus ja kulutaseme vastuvõetavus. Seetõttu kõige rohkem Parim viis tagada sobiv kvaliteeditase – arutage seda küsimust kliendi endaga.

Kliendi nõuded tuleb esitada mõõdetavates terminites, et neid saaks kasutada IT-teenuste arendamisel ja jälgimisel. Kui mõõdikud ei ole kliendiga kokku lepitud, siis ei ole võimalik kontrollida, kuidas teenused vastavad saavutatud kokkulepetele.

Esimene samm praeguste või tulevaste IT-teenuste osas kokkuleppimiseks peaks olema kliendi vajaduste kindlakstegemine ja määratlemine teenusetaseme nõuete (SLR) näol. Lisaks seda tüüpi toimingute tegemisele selle protsessi alguses, on soovitatav seda teha regulaarselt kliendi soovil või IT-organisatsiooni enda algatusel ning hõlmata nii uusi kui ka olemasolevaid teenuseid.

Esialgne määratlemine selle kohta, mis peaks sisalduma teenusetaseme nõuetes ja teenusetaseme lepingutes, on väga keeruline ülesanne. Arvesse tuleks võtta kõigi protsesside võimalusi ja piiranguid seoses teatud teenuseeesmärkide mõõdetavuse ja saavutatavusega.

Kui tekib kahtlus ettevõtte poolt taotletava teenuse eesmärkide saavutatavuses, saab vastavad eesmärgid lisada kontrollgarantiiperioodi jooksul seireks ja hindamiseks pilootlepingusse. See aitab hankida vajalikku statistikat ja teha vajalikke parandusi.

Kui paljud organisatsioonid püüavad pakutavaid teenuseid dokumenteerida ennekõike vastavate teenusetaseme lepingute sõlmimisega, on väga oluline ülesanne ka uute arendatavate või hangetavate teenuste teenuste taseme nõuetes kokkuleppimine.

Teenusetaseme nõuded peaksid olema teenuse kavandamise kriteeriumide lahutamatu osa, mis hõlmab ka funktsionaalseid spetsifikatsioone. Nad peaksid määratlema katse- ja sissetöötamiskriteeriumid projekteerimise ja arenduse või hanke erinevate etappide jaoks alates projekteerimise varaseimatest etappidest. Teenusetaseme nõudeid täiustatakse järk-järgult igas elutsükli etapis, saades esialgses tugifaasis pilootteenuse osutamise lepingu. Enne teenuse kasutuselevõttu ja kasutamist tuleb allkirjastada ja vormistada teenusetaseme lepingu kavand.

Kogemus näitab, et sageli ei oska kliendid ise oma ootusi selgelt määratleda, nad lihtsalt eeldavad, et neile osutatakse mõnda teenust ilma konkreetsete kokkulepeteta. Klient võib vajada abi nõuete mõistmisel ja sõnastamisel, eelkõige seoses võimsuse, turvalisuse, kättesaadavuse ja järjepidevusega. Olge valmis selleks, et esialgseid nõudeid kohe kokku ei lepita ega kinnitata. Nõudearutelu võib kuluda mitu kordamist, enne kui soovide ja võimaluste vahel saavutatakse vastuvõetav tasakaal. Need iteratsioonid võivad vajada teeninduslahenduse ümberkujundamist.

Tuleb märkida, et uute teenuste toetamiseks võib vaja minna lisaressursse. Sageli eeldatakse, et niigi ülekoormatud töötajad saavad võluväel hakkama uute teenustega kaasneva lisatöökoormusega.

Lepingu kavandit kasutades saate pidada läbirääkimisi klientide või nende esindajatega, et täpsustada teenusetaseme lepingute ulatust ja esialgseid teenusetaseme eesmärke, ning hankijatega, et tagada nende eesmärkide saavutamine.

Teenusetaseme juhtkond peaks kavandama teenusetaseme lepingute jaoks sobiva struktuuri, tagamaks, et kõik teenused ja kõik kliendid on hõlmatud ulatuses, mida organisatsioon peab katma. Võimalikke struktuure on mitu, sealhulgas järgmised:

• ühel teenusel põhinevad teenusetaseme lepingud;
• kliendipõhised teenindustaseme lepingud;
• mitmetasandilised teenusetaseme lepingud.

Ühel teenusel põhinevad SLA-d on siis, kui teenusetaseme leping mõjutab ühte teenust kõigi selle teenuse klientide jaoks. Näiteks võib meiliteenuse jaoks sõlmida teenusetaseme lepingu, mis mõjutab kõiki selle teenuse kliente. Raskusi võib aga tekkida siis, kui erinevate klientide nõudmised samale teenusele on erinevad või kui infrastruktuuri iseärasused tähendavad, et erinevad teenuste tasemed on vältimatud.

Näiteks: Peakontori töötajad saavad suhelda kiire kohtvõrgu abil kohalikud kontorid peab kasutama aeglane WAN-link. Sellistel juhtudel võib ühes lepingus sätestada eraldi eesmärgid. Seni, kuni kõigis ärivaldkondades, näiteks meiliteenuse puhul, pakutakse ühtset teenusetaset, võivad näiteks olla ühel teenusel põhinevad SLA-d. tõhus lähenemine. Ühes lepingus võib olla mitu teenusetaset, näiteks kuld-, hõbe- või pronkstaset.

Kliendipõhised teenusetaseme lepingud – leping üksiku kliendirühmaga, mis hõlmab kõiki nende poolt kasutatavaid teenuseid. Näiteks on võimalik kokkuleppeid saavutada finantssüsteemide organisatsiooni finantsosakonna katte kaudu, raamatupidamissüsteemid, arveldussüsteemid, arveldussüsteemid, ostusüsteemid ja kõik muud nende kasutatavad IT-süsteemid. Tihti eelistavad kliendid selliseid lepinguid, kuna kõik nende nõuded on siis kaetud ühe dokumendiga. Reeglina piisab ühest kliendi allkirjast, mis lihtsustab kooskõlastamist.

Struktuuri mis tahes variantide kombinatsioon on võimalik tingimusel, et dubleerimist ei toimu.

Mõned organisatsioonid kasutavad mitmetasandilist SLA struktuuri. See võib sisaldada näiteks kolme taset:

• ettevõtte tasand hõlmab kõiki üldisi teenusetaseme juhtimise küsimusi, mis puudutavad kõiki organisatsiooni kliente, reeglina ei vaja need jaotised sagedast ülevaatamist;
• klientide tase kirjeldab konkreetsetele klientidele või äriüksuste rühmadele teenuste osutamise tunnuseid, mis on iseloomulikud kõigile neile osutatavatele teenustele;
• teenindustase kirjeldab konkreetsele kliendile või klientide rühmale osutatavate üksikute teenuste eripära.

See struktuur võimaldab hoida teenusetaseme teadmiste suurust hallatavates piirides, hoiab ära tarbetu dubleerimise ja vähendab vajadust sagedaste värskenduste järele. See hõlmab aga täiendavaid jõupingutusi teenusekataloogi ja konfiguratsioonihaldussüsteemi linkide terviklikkuse säilitamiseks.

Mitmetasandilised SLA-d suurendavad hallatavust ja vähendavad dokumentatsiooni dubleerimist kogu organisatsioonis. See tähendab, et värskendusi tehakse ainult vajaduse korral. Organisatsiooni sees saab tasemete nimetusi muuta, näiteks: ettevõte, osakond ja teenindus või grupp, ärivaldkond ja teenus.

Peate veenduma, et mitmetasandiliste SLA-de haldamine on kontrollitud, kuna kõik tehtud muudatused mõjutavad teisi tasemeid. See kehtib kõigi ettevõtte SLA-s tehtud muudatuste kohta – neist tuleb teavitada teisi tasemeid. Mitmetasandiliste SLA-de haldamine on keeruline, kuid lihtsam kui administreerimine suur hulk SLA-d, mis ei ole sellisesse hierarhiasse rühmitatud.

Paljud organisatsioonid peavad vajalikuks kasutada standardeid ja/või näidislepinguid, mis on aluseks konkreetsete teenusetaseme lepingute koostamisel. Selliseid malle saab kasutada lepinguprojektide väljatöötamiseks.

Standardite ja mudelite väljatöötamine tagab kõigi lepingute järjepideva väljatöötamise, mis omakorda hõlbustab nende hilisemat kasutamist, haldamist ja toimimist.

Rollide ja kohustuste määratlemine on osa teenusetaseme lepingust. Arvestada tuleb kolme vaatenurgaga – IT-müüja, IT-klient ja tegelik kasutaja.

Lepingu sõnastus peaks olema selge ja sisutihe ning ei tohiks jätta ruumi kahemõttelisusele. Reeglina ei nõuta lepingute kirjutamist juriidilises terminoloogias ning lihtne keelekasutus aitab ühist arusaamist. Lõplikuks korrektuuriks on kasulik kaasata sõltumatuid isikuid, kes ei osalenud lepinguprojektide loomisel.

Oluline on, et dokumenteeritud ja kokku lepitud eesmärgid oleksid selged, konkreetsed ja üheselt mõistetavad, kuna need loovad aluse osutatava teenuse suhtele ja kvaliteedi tagamisele.

SLA-d ei tohiks sisaldada nõudeid, mille tulevast pakkumist ei saa kokkulepitud tasemel jälgida ja mõõta. Selle olulisust ei saa üle tähtsustada, kuna selliste esemete kaasamine, mida ei saa tõhusalt jälgida, põhjustab peaaegu alati vaidlusi ja võimaliku kliendipoolse usalduse kaotuse. Paljud organisatsioonid on seda oma vigadest õppinud ja selle tulemusena saanud mõlema puhul suuri kulutusi rahalised tingimused, kui ka nende enda pildi järgi. Kindlasti tuleb välja selgitada asjaolud, mis takistavad kokkulepete täitmist ja tegevust selliste asjaolude ilmnemisel.

Olemasolevaid seirevõimalusi tuleks hinnata ja vajadusel ajakohastada. Ideaalis tuleks seda teha enne teenusetaseme lepingu koostamist või sellega samal ajal, mis aitab kasutada monitooringut kavandatud eesmärkide kinnitamisel.

On oluline, et jälgimine vastaks kliendi ettekujutusele teenusest. Kahjuks on seda sageli väga raske saavutada. Näiteks üksikute komponentide, näiteks võrgu või serveri jälgimine ei garanteeri, et teenus on kliendile ootuspäraselt kättesaadav. Klient muretseb sageli ainult teenuse pärast, mida ta ei saa, kuigi rike võib puudutada ka muid teenuseid. Tervikpilti ei saa ilma kõiki komponente ja teenust tervikuna jälgimata ning see on keeruline ja kulukas. Seetõttu peaksid kasutajad olema teadlikud, et nad peaksid seireteenuse osutaja töö abistamiseks viivitamatult teatama juhtumitest, eriti jõudlusega seotud juhtumitest.

On mitmeid olulisi parameetreid, mida ei saa seirevahenditega mõõta, näiteks klientide tajumine teenustest (ja see ei pruugi ühtida seiretulemustega). Näiteks isegi siis, kui on toimunud mitu intsidenti, saab klient nähtavate ja asjakohaste parandusmeetmete abil säilitada teenusest positiivse ettekujutuse. Muidugi on võimalik ka vastupidine, kus klient jääb rahulolematuks teenindustaseme lepingu rikkumiste puudumisel.

Esimene samm on püüda hallata klientide ootusi. See tähendab õigete ootuste ja eesmärkide seadmist ning seejärel nende süstemaatilist ennetavat kohandamist, pidades meeles, et "rahulolu = taju - ootused" (kui väärtus on suurem kui või null klient on rahul). SLA-d on vaid dokumendid ja iseenesest ei asenda pakutava teenuse kvaliteeti (kuigi need võivad mõjutada käitumist ja aidata arendada õiget teeninduskultuuri, millel on nii lühi- kui ka pikaajaline positiivne mõju). Tuleb varuda teatud määral kannatlikkust ja see peab olema osa ootustest.

Kui osutatavate teenuste eest tasub klient, saab hindu kasutada nõudluse juhtimiseks. (Kliendid võivad saada kõike, mida nad õigustavad – seni, kuni see sobib ettevõtte strateegiaga – ja neil on selleks volitatud eelarve, mis on piiratud.) Vastastikkuse puudumisel tuleb klientide ebarealistlike ootuste piiramiseks tagada tippjuhtkonna tugi.

• perioodilised küsitlused ja klientide küsitlused;
• tagasiside teenuste hindamise koosolekutel;
• tagasiside tehtud muudatuste hindamisel;
• teeninduskeskuse telefoniküsitlused;
• teeninduse ja muude kontaktide käigus jagatud rahuloluküsimustikud;
• suhtlus kasutajagruppidega (foorumites jne);
• kaebuste analüüs ja tänud.

Võimaluse korral tuleks SLA osana määratleda ja jälgida rahulolu eesmärgid. Veenduge, et kasutajate tagasisidele vastatakse, näidates neile, et nende kommentaarid on lisatud teie tegevuskavasse (teenuste täiustamise kava). Kõiki rahulolu mõõtmisi tuleks hinnata, kõrvalekaldeid analüüsida ja analüüsi tulemuste põhjal planeerida kohandusi.

Teenusepakkujad sõltuvad oma tugimeeskondadest ja välistest partneritest või müüjatest. Nad ei saa tagada teenusetaseme kokkuleppeid, kui sisemised ja välised sõltuvused ei toeta samu eesmärke. Lepingud väliste pakkujatega on kohustuslikud, kuid paljude organisatsioonide arvates on kasulik ka sõlmida lihtsad kokkulepped sisemiste rühmade vahel, mida tavaliselt nimetatakse operatiivtasandi kokkulepeteks. "Toetuslepingud" on üldmõiste kõikidele toetavatele operatiivtasandi lepingutele, teenusetaseme lepingutele ja lepingutele.

Tegevustasandi kokkulepped ei tohiks olla liiga keerulised, vaid peaksid seadma tugimeeskondadele selged eesmärgid, et tagada teenusetaseme lepingu eesmärkide täitmine. Näiteks kui SLA nõuab vahejuhtumite lahendamist kindlaksmääratud aja jooksul, peaks tegevustasandi leping sisaldama tugiahela iga elemendi jaoks asjakohaseid piiranguid. Ilmselgelt ei tohiks SLA eesmärgid sel juhul olla samad, mis toetavates lepingutes, kuna SLA-d määratlevad koguaja, mis hõlmab mitme grupi tööd, millest igaühele saab kokku leppida toetava lepingu.

SLA-d peaksid sisaldama kõnele reageerimise aega, intsidendi eskalatsiooni aega tehnikutele ja reageerimisaega. Samuti tuleks kindlaks määrata iga tugirühma tugitunnid. Kui töötajatega suhtlemiseks on kehtestatud eriprotseduurid ( telefoniliin tööajaväliste kõnede jms puhul), tuleks see samuti dokumenteerida.

Jälgida tuleks tegevustasandi kokkuleppe vastavust teenusetaseme lepingutes ja tugilepingutes sätestatud eesmärkidele ning koostada ja edastada tugimeeskonna juhtidele asjakohane aruandlus. See võib aidata tuvastada võimalikke probleemseid kohti, mis nõuavad töö või kokkulepete kohandamist. Tõsiselt tuleks kaaluda ametlike operatiivtasandi kokkulepete väljatöötamist kõigi operatiivteenuste toetamise ja osutamisega seotud sisemeeskondade jaoks.

Sellest tulenevalt on enne uue või muudetud SLA allkirjastamist oluline olemasolevad lepingulised kokkulepped üle vaadata ja vajadusel neid uuendada. See võib nõuda IT-lt või kliendilt lisakulusid. Viimasel juhul tuleb need kulud kliendiga kokku leppida või lepingutesse lisada pehmemad eesmärgid. See ülevaatus tuleks läbi viia koos tarnija juhtkonnaga, et tagada mitte ainult teenusetaseme juhtimise protsessi nõuete täitmine, vaid ka vastavus muudele piirangutele, nagu lepingupoliitika ja standardid.

Kui teenusetaseme kokkulepe on kokku lepitud ja aktsepteeritud, tuleks tagada saavutatud teenusetaseme jälgimine ja aruandlus. Tegevusaruandeid tuleks genereerida sageli (vähemalt kord nädalas) ja võimalusel tuleks koostada kõrvalekaldeteateid vastuseks SLA-st kõrvalekalletele (või kõrvalekallete ohule). Tihti on SLA-de täitmine uue teenuse varases staadiumis raske sissetulevate muudatustaotluste arvu tõttu. Soovitame teil selles etapis lubatud muudatustaotluste arvu piirata.

Aruandlusmehhanismid, aruandlusintervallid ja -vorm tuleks klientidega kokku leppida. Sama kehtib teenuste hindamise koosolekute sageduse ja vormi kohta. Soovitatavad on regulaarsed intervallid, mis on sünkroonitud regulaarse aruandlusega.

Perioodiline aruandlus tuleks koostada ja saata klientidele või nende esindajatele ja asjaomastele IT-juhtidele paar päeva enne teenuse hindamise koosolekuid, et võimalikud raskused ja lahkarvamused saaksid enne koosolekut lahendatud ega segaks teenuse hindamist.

Perioodiline aruandlus peaks sisaldama üksikasju toimivuse kohta SLA eesmärkidega võrreldes, samuti teenuse kvaliteedi parandamise suundumuste ja tegevuste kirjeldust. SLA aruannetesse võib olla mugav lisada aruande esilehel olevaid tabeleid, et saaksite kiiresti aimu, kuidas teenus eesmärgiga sobib. IT-juhid võivad nõuda vahearuandlust, et hinnata tegevustasandi kokkulepete ja lepingute täitmist. Aruandlus on arenev protsess, esimene tulemus ei ole tõenäoliselt lõplik.

Teenusetaseme haldusprotsess peaks tuvastama aruandlusvajadused ja automatiseerima aruandluse nii palju kui võimalik. Aruannete varieeruvus, täpsus ja levitamise lihtsus on oluline osa automatiseerimisvahendi valiku kriteeriumidest. Teenuste aruandlus ei peaks sisaldama ainult teenuse toimivuse üksikasju, vaid pakkuma ka ajaloolist teavet varasemate väärtuste ja suundumuste kohta, mis võimaldab hinnata ja kavandada teenuse parandamise meetmete tõhusust.

Korraldada tuleks perioodilisi kohtumisi klientidega, et ühiselt hinnata teenuseid möödunud perioodi tulemuste ning tekkinud kõrvalekallete ja raskuste põhjal. Tavaliselt toimuvad need koosolekud kord kuus või vähemalt kord kvartalis.

Nendel kohtumistel tuleks kavandada meetmed teenuste osutamise ja tarbimise puuduste kõrvaldamiseks. Otsused tuleks protokollida ning nende täitmist jälgida ja kontrollida järgmistel koosolekutel.

Erilist tähelepanu tuleks pöörata teenuste katkestustele; tuleks selgitada selliste vahejuhtumite põhjused ja võimalikud meetmed, et vältida selliste juhtumite kordumist. Kui tehakse kindlaks, et varem seatud eesmärgid ei ole saavutatavad, võidakse teha otsus teenuseeesmärkide hindamiseks, uuesti läbirääkimiseks ja kokkuleppimiseks. Kui teenuse katkestus oli tingitud sõltuvusest kolmandatest isikutest, võib osutuda vajalikuks toetuslepingute ülevaatamine. Teenuse katkemise kadude analüüs annab olulist teavet ratsionaalsete parenduste kavandamiseks. Pidev parendamise püüdlus peab arvestama ettevõtte huvidega, koondades jõupingutused kõige olulisematesse ja kasumlikumatesse valdkondadesse.

Teenuse täiustamise plaani edusammudest ja tulemustest tuleks aru anda, et hinnata kava järgimist ja võetud meetmete tõhusust.

Igat liiki lepinguid tuleb ajakohastada. Need peaksid olema muudatuste ja konfiguratsioonihalduse kontrolli all ning neid tuleks perioodiliselt, vähemalt kord aastas, üle vaadata, et tagada nende ajakohasus, täielikkus ning ärivajaduste ja strateegiaga vastavus.

Need kontrollid peaksid tagama lepingute ajakohasuse oma ulatuse ja püstitatud eesmärkide osas, kinnitades, et lepingud ei ole kaotanud oma kehtivust (kasutatavust) infrastruktuuri, äritegevuse, tarnijate jms muutuste tõttu. Kui lepinguid uuendatakse, peaks tehtud muudatused olema allutatud muudatuste juhtimise kontrollile. Kui kokkulepped kajastuvad konfiguratsioonihaldussüsteemis CI-dena, on seda kontrolli lihtsam teostada ja selle tulemused on usaldusväärsemad.

Ülevaatused peaksid hõlmama ka üldisi strateegilisi dokumente, et tagada lepingute vastavus IT- ja äristrateegia ning poliitikaga.

On väga oluline, et teenusetaseme juhtimise protsess looks usaldusliku ja austava suhte ettevõttega, eriti ettevõtte võtmeisikutega. Et see oleks võimalik, peab teenusetaseme haldamise protsess läbi viima järgmised tegevused:

• kinnitada huvirühmade, klientide, ettevõtete juhtide ja kasutajate nimekirjad;
• aidata säilitada portfellis ja teenuste kataloogis täpseid andmeid;
• pakkuda paindlikkust ja valmisolekut reageerida äri, klientide ja kasutajate vajadustele, mõistes käimasolevaid ja kavandatavaid äriprotsesse ning nende nõudeid uutele ja muutuvatele teenustele, dokumenteerides ja arutades neid nõudeid ettevõtja, klientide ja kasutajatega, luues pikaajalisi suhteid;
• tagada täielik arusaam äri, klientide ja kasutajate strateegiast, plaanidest, vajadustest ja eesmärkidest, arendades nende ja IT vahelist partnerlust;
• Viia regulaarselt läbi tulemuslikkuse ülevaatusi ja kliendikogemuse uuringuid – sise- ja väliseid – ning edastada asjakohast teavet IT-le;
• tagama suhtlemisprotseduuride olemasolu ja tõhususe ning nende pideva täiustamise;
• korraldada ja läbi viia kliendirahulolu uuringuid, tagades nende analüüsi ja tegutsemise tulemustele;
• esindama teenusepakkujat kasutajarühmade koosolekutel;
• ennetavalt turgu uurima, analüüsides teenuste kasutamist ning mõjutades teenuste portfelli ja kataloogi;
• teha koostööd ettevõtete, klientide ja kasutajatega tagamaks, et IT pakub praegustele ja tulevastele ärivajadustele vastavat taset;
• edendada teenuseteadlikkust ja teenustest arusaamist;
• tõsta teadlikkust uute tehnoloogiate kasutamise eelistest äritegevusele;
• hõlbustada õigete, saavutatavate ja realistlike teenusetaseme nõuete ning IT ja ettevõtte vaheliste teenusetaseme lepingute määratlemist ja arutamist;
• tagada, et ettevõtted, kliendid ja kasutajad mõistaksid oma suhteid IT-ga ja sõltuvustega;
• edendada paranduste ja täienduste salvestamist.

Teenusetaseme haldamise protsess peaks hõlmama ka tegevusi ja protseduure kaebuste ja kiituste registreerimiseks ja haldamiseks. Logimist teostab sageli teeninduskeskus ja see sarnaneb juhtumite ja teenusepäringute logimisega. Kaebuste ja kinnituste määratlused tuleks klientidega kokku leppida koos kontaktpunktide ja protseduuridega. Kõik kaebused ja kiitused tuleb protokollida ja edastada vastavatele osapooltele. Kõik kaebused tuleb samuti käsitleda ja lahendada algatajat rahuldaval viisil. Kui seda ei juhtu, tuleks määratleda kontaktid ja eskalatsiooniprotseduurid. Kõik tõsised kaebused tuleks analüüsida ja juhtkonna tähelepanu juhtida. Kaebuste ja kiituste käsitlemise statistika, suundumuste, tegevuste ja tulemuste kohta tuleks aru anda.

Teenusetaseme haldusprotsessi mõõdikud

• CSF Oluline on tagada teenuste haldamise kvaliteet üldiselt, sealhulgas katvus ja pakkumise tase:
• KPI SLA eesmärkide mittejärgimise vähenemise protsent
• KPI mittevastavuse ohu leevendamise protsent
• KPI Klientide tajumise ja SLA saavutustega rahulolu paranemise protsent teenuse hindamiskoosolekute ja rahulolu-uuringute põhjal
• KPI Kolmandatest osapooltest sõltumisega seotud mittevastavuste vähenemise protsent (UC)
• KPI Sisetöövõtjatele tuginemisega (OLA) seotud mittevastavuste vähenemise protsent
• CSF Teenuste osutamine vastavalt lepingutele mõistliku raha eest:
• KPI Täielikult dokumenteeritud SLA-de arvu ja suurenemise protsent
• KPI SLA täiustuste protsent, mille eesmärk on parandada juba pakutud teenuseid
• KPI Teenuste osutamise kulude vähenemise osa
• KPI SLA jälgimise ja aruandluse kulude vähendamise protsent
• KPI Protsent arenduskiiruse suurendamisest ja SLA heakskiitmisest
• KPI Teenuse hindamise koosolekute sagedus
• CSF Ettevõtte ja kasutajate vahelise liidese haldamine:
• KPI SLA-ga hõlmatud teenuste arvu suurendamine
• KPI SLM-protsessi ja protseduuride dokumenteerimine ja joondamine
• KPI Vähendatud reageerimis- ja täitmisaeg SLA taotlustele
• KPI Õigeaegselt läbi vaadatud SLA-de osakaalu suurendamine
• KPI Ülevaatamisele kuuluvate täitmata SLA-de osakaalu vähendamine
• KPI Kohandust vajavate SLA-de osakaalu vähenemine
• KPI Suurendage OLA ja UC katvust, vähendades samal ajal lepingute arvu nende konsolideerimise ja tsentraliseerimise kaudu
• KPI Dokumentaalsed tõendid SLA-st tuvastatud kõrvalekallete paranemise kohta
• KPI SLA eesmärkidele mittevastavuse arvu ja raskusastme vähendamine
• KPI Tõhus hindamine ning kõigi SLA, OLA, UC kõrvalekallete ja ebakõlade töötlemine

ITIL tuvastab teenusetaseme juhtimise tulemuslikkuse subjektiivsed ja objektiivsed mõõdikud. Eesmärk:

• Saavutatud teenuseeesmärkide arv või osakaal
• Hälvete ja rikkumiste arv ja aste (raskusaste).
• Praeguste SLA-de arv (ajakohased)
• Teenuste arv, millest teatatakse ja mida hinnatakse õigeaegselt

Subjektiivne:

• Klientide rahulolu paranemine

Riskid ja raskused

Teenusetaseme juhtimise rakendamisel tuleb arvestada järgmiste võimalike riskide ja väljakutsetega:

• Täpsete sisendandmete puudumine, ettevõtete ja klientide kaasatus ja huvi
• Vajadus ressursside ja tööriistade järele kokkulepete ja teenusetasemete kokkuleppimiseks, dokumenteerimiseks, jälgimiseks, aruandluseks ja hindamiseks
• Protsess võib muutuda liiga bürokraatlikuks, keskendudes pigem haldusprotseduuridele kui tegelikule teenuste ennetavale parandamisele
• Juurdepääs õigele ja ajakohasele CMS-ile ja SKMS-ile ning nende tugi
• SLM-protseduuride mittejärgimine
• Ettevõtlusest lähtuvaid mõõdikuid on liiga raske mõõta ja täiustada, mistõttu nad seda ei tee
• Sobimatu kontakti ja koordinatsiooni tase
• Suured ootused ja madal klientide rahulolu
• Ebaefektiivne suhtlus äriga

Probleemide haldamise protsess

IT-teenuste osutamisel juhtub nii või teisiti intsidente (tõrkeid). Ja kui teil on korralikult korraldatud intsidentide haldusprotsess ja sündmuste haldamise protsess, on tekkivate intsidentide negatiivne mõju minimaalne. Kui juhtub vahejuhtumeid, on sellel teadmata põhjus. Juhtumihaldusprotsess algab intsidendi ilmnemisel ja peatub olukorra parandamisel. See tähendab, et intsidendi algpõhjust ei tuvastata alati ja vahejuhtum võib korduda. ITIL-is nimetatakse seda põhjust probleemiks.

Probleem on ühe või mitme intsidendi põhjus. Tavaliselt on probleemikirje loomisel põhjus teadmata ja probleemi edasise uurimise eest vastutab probleemihaldusprotsess.

Nii olemasolevate kui ka võimalike teenusetõrgete algpõhjuste väljaselgitamiseks uurib probleemihaldusprotsess infrastruktuuri ja saadaolevat teavet, sealhulgas juhtumite andmebaasi.

Probleemide haldamine on protsess, mis vastutab kõigi probleemide elutsükli haldamise eest. Probleemide haldamine hoiab ennetavalt ära intsidentide toimumise ja minimeerib nende juhtumite mõju, mida ei ole võimalik ära hoida.

Probleemide juhtimine hõlmab proaktiivseid (proaktiivseid) ja reageerivaid tegevusi. Probleemihaldusprotsessi reaktiivkomponentide ülesanne on selgitada välja minevikuintsidentide algpõhjus ja koostada ettepanek selle kõrvaldamiseks. Proaktiivne probleemihaldus aitab intsidente ära hoida, tuvastades infrastruktuuri nõrkused ja koostades parendusettepanekuid.

Seega on probleemihaldusprotsessi ülesanded:

• Probleemide ja nendega seotud vahejuhtumite ennetamine
• Juhtumite kordumise peatamine
• Selliste juhtumite mõju vähendamine, mida ei saa ära hoida

Probleemihaldustegevused

Põhimõtteliselt võib iga teadmata põhjusel aset leidnud intsident olla seotud probleemiga. Praktikas on probleemi algatamine mõttekas alles siis, kui juhtum kordub, seda on võimalik korrata või kui tegemist on ühe, kuid tõsise intsidendiga.

"Probleemi tuvastamise" tegevust teostavad sageli probleemi koordinaatorid. Siiski võib juhtuda, et probleeme suudavad tuvastada ka selle tööga mitteseotud töötajad, näiteks võimsusjuhtimise spetsialistid. Sellised "leiud" tuleks ka probleemidena kirja panna.

Probleemide registreerimisandmed on sarnased juhtumite üksikasjadega, kuid probleemi ilmnemisel ei pea te kirjeldusse lisama teavet kasutaja kohta jms. Konkreetse probleemiga seotud juhtumid tuleks aga tuvastada ja vastavalt logitud. Järgmised näited juhtudest, kus probleeme saab tuvastada.

• Juhtumihaldus ei saa intsidenti sobitada olemasolevate probleemide või teadaolevate vigadega
• Juhtumitrendi analüüs näitab, et probleem võib olla
• Suure intsidendi põhjuse analüüs on vajalik
• Teised IT-funktsioonid on tuvastanud, et probleem võib olla
• Service Deski töötajad ei suutnud intsidendi põhjust kindlaks teha ja on kahtlus, et see juhtum võib korduda
• Juhtumi analüüs tugimeeskonna poolt näitas, et probleem on (või võib olla).
• Tarnija teade, et probleem tuleb lahendada

Probleemide võimalikud märgid võivad hõlmata järgmist:

• Juhtumid, mis korduvad:
• Sama ajaperiood
• Ühes ainevaldkonnas (kategoorias)
• Samas CI-s või sarnaste CI-de rühmas
• Samas kohas, järjekorras, jaoskonnas
• Sarnaste juhtumite maht ületab teatud piiri
• Juhtumi lahendamiseks rakendati lahendus
• Juhtumi(te) töötlemise tähtaeg on ületatud

Trendianalüüs võimaldab tuvastada valdkonnad, mis nõuavad erilist tähelepanu. Olenemata probleemi tuvastamise meetodist tuleks kõik asjakohased andmed probleemi kohta salvestada probleemikirjesse:

• Teave kasutaja(te) kohta
• Teave teenuse(te) kohta
• Riistvara teave
• Registreerimise aeg
• Prioriteet, kategooria
• Seotud juhtumite kirjeldus
• Diagnoosimiseks ja lahendamiseks võetud meetmed

Probleemi kirje – kirje, mis sisaldab probleemi üksikasjalikku kirjeldust. Iga väljaande kirje dokumenteerib ühe väljaande elutsükli.

Nii nagu vahejuhtumid, tuleb ka probleemid salastada. Probleeme saab liigitada valdkondadesse (kategooriatesse). Probleemi klassifitseerimine toimub samaaegselt selle mõju astme analüüsiga, st probleemi tõsiduse taseme ja selle mõju teenustele (kiirelisus ja mõju aste). Pärast seda määratakse probleemile prioriteet, nagu ka intsidentide haldamise protsessis. Seejärel määratakse klassifikatsiooni tulemuste põhjal probleemile ressursid ja personal ning määratakse selle lahendamiseks kuluv aeg.

Probleemi klassifikatsioon sisaldab järgmist:

Teadaolev viga on probleem, millel on dokumenteeritud algpõhjus ja lahendus. Tuntud vead luuakse ja hallatakse kogu nende elutsükli jooksul osana probleemihaldusprotsessist. Tuntud vead võivad tuvastada ka arendajad või töövõtjad.

Klassifikatsioon ei ole staatiline, see võib muutuda kogu probleemi elutsükli jooksul. Näiteks võib lahendus või kiirparandus aidata probleemi kiireloomulisust vähendada, samas kui uued juhtumid võivad probleemi mõju suurendada.

Uurimine ja diagnoosimine on protsessi iteratiivsed faasid, neid korratakse mitu korda, jõudes iga kord soovitud tulemusele lähemale. Sageli üritatakse testimiskeskkonnas juhtunud intsidenti reprodutseerida. Probleemi lahendamiseks võib vaja minna lisateadmisi, näiteks saate probleemi analüüsimiseks ja diagnoosimiseks kaasata tugimeeskonna spetsialiste.

Pärast probleemi põhjuse ja lahenduse kindlakstegemist määratakse probleemile olek "Teadatav viga". Paljudel juhtudel on probleemile lahendus juba olemas, isegi kui vea avastavad arendajad ise. Kuid mõnel juhul tuleb leida lahendus ja seejärel minna juhtumihaldusprotsessi.

Lahendus on vähendada või kõrvaldada intsidendi või probleemi mõju, mille jaoks pole praegu saadaval täielikku lahendust. Näiteks ebaõnnestunud konfiguratsiooniüksuse taaskäivitamine. Probleemide lahendused on dokumenteeritud teadaolevates veakirjetes.

Probleemihalduspersonal otsustab, mida on vaja probleemi lahendamiseks teha. Eksperdid võrdlevad erinevaid lahendusi, võttes arvesse teenusetaseme lepinguid (SLA), võimalikke kulusid ja tulusid. Kõik lahenduse väljatöötamise tööd tuleks süsteemi registreerida, töötajatel peaks olema vahendid probleemide jälgimiseks ja nende staatuse kindlaksmääramiseks.

Eelmistes etappides valitakse optimaalne lahendus. Siiski võidakse otsustada mitte parandada näiteks teadaolevat viga, kuna see pole majanduslikult otstarbekas.

Pärast valikuetapi lõppu on piisavalt teavet muutmistaotluse esitamiseks. Edasine probleemi (teadaoleva vea) parandamine toimub muudatuste juhtimise protsessi kontrolli all.

Probleemi lahendamiseks mõeldud muudatust tuleks juurutustulemuste hindamisel arvesse võtta enne probleemi sulgemist. Kui muudatus andis oodatud tulemuse, saab probleemi sulgeda ja selle olekuks muuta probleemide andmebaasis "lahendatud". Sellest teavitatakse intsidentide juhtkonda ning selle teemaga seotud intsidendid võidakse samuti sulgeda.

Rakendamise tulemuste hindamine - muudatuse või projekti elluviimise järel teostatav ülevaatus. Rakendamise hindamine määrab muudatuse või projekti edukuse ja selgitab välja parendusvõimalused.

Kogu protsessi vältel edastatakse intsidentide haldusele lahendused ja kiirparandused. Ka kasutajaid saab sellest teavitada.

Probleemide haldamise põhimõtted ja mõõdikud

Protsessi tõhususe ja tõhususe tagamiseks tuleb jõustada probleemijuhtimise protsessipoliitikad ning need võivad sisaldada järgmist.

• Probleeme tuleks jälgida juhtumitest eraldi
• Kõik probleemid tuleb salvestada ja hallata ühtne süsteem juhtimine
• Kõikidel probleemidel peaks olema standardne kategoriseerimisskeem, mis sobib ettevõtte äriprotsessidega.

Teenusetaseme juhtimise protsessi efektiivsuse juhtimiseks ja hindamiseks ning teistele juhtimisprotsessidele tagasiside andmiseks soovitab ITIL kasutada järgmisi võtmenäitajaid (CSF ja KPI):

• CSF Minimeerige selliste juhtumite mõju ärile, mida ei saa ära hoida
• KPI KEDB lisatud teadaolevate vigade arv
• KPI protsent KEDB asjakohasusest (andmebaasi auditi järgi)
• KPI protsent intsidentidest, mille on lõpetanud kasutajatugi ("esimene kontaktpunkt")
• KPI Keskmine aeg juhtumite lahendamiseks, mille puhul probleem on avatud
• CSF säilitab IT-teenuste kvaliteedi, kõrvaldades korduvad juhtumid
• KPI probleemide koguarv (võrdlusalusena)
• KPI probleemi järjekorra suurus IT-teenuse kohta
• KPI Iga IT-teenuse korduvate juhtumite arv
• CSF Kvaliteedi ja professionaalsuse tagamine probleemide lahendamisel, et säilitada ettevõtte usaldus IT-võimaluste vastu
• KPI Oluliste probleemide arv (avatud, suletud ja järjekorras)
• KPI protsent edukalt lõpetatud oluliste probleemide ülevaatustest
• KPI Edukalt ja õigeaegselt lõpetatud oluliste probleemide ülevaatuste protsent
• KPI Valesti määratud probleemide arv ja protsent
• KPI Vale kategoriseerimisega probleemide arv ja protsent
• KPI Kuhjunud lahendamata probleemide järjekord ja selle trend
• KPI Lahendustähtaega ületanud probleemide arv ja protsent
• KPI SLA eesmärkide raames lahendatud probleemide protsent
• KPI Keskmine kulu ühe probleemi lahendamiseks

Äriväärtus

Rakendades ITIL-i soovitustele vastava intsidentide haldamise protsessi ja lahendades kõik juurutamise käigus tekkida võivad raskused, on ettevõttele kui tervikule võimalik saada järgmine väärtus:

• IT-teenuste kvaliteedi tõstmine infrastruktuuri jälgimise, dokumenteerimise ja/või vigade kõrvaldamise kaudu.
• Juhtumite arvu vähendamine.
• Personali tootlikkuse tõstmine
• Püsilahenduste kasutamine pidevate aukude lappimise asemel.
• Süstemaatilised tegevused teadmiste kogumiseks.
• Võimalus lahendada rohkem vahejuhtumeid esimesel tugiliinil.
• Tulekahju kustutamiseks või korduvate juhtumite lahendamiseks tehtavate jõupingutuste kulude vähendamine

Teenuse varade ja konfiguratsiooni haldusprotsess

Igal organisatsioonil on info IT infrastruktuuri kohta. Sageli töötatakse olemasoleva teabe struktureerimiseks ja kokkuvõtmiseks välja erinevaid skeeme, mis riputatakse seinale. See meetod võimaldab tõesti teatud juhtudel kiiresti hankida teavet infrastruktuuri komponentide konfiguratsiooni ja nende suhete kohta, kuid sellel on mitmeid puudusi:

• uuendamise keerukus: iga muudatusega tuleb diagramm uuesti joonistada ja uuesti välja trükkida, vastasel juhul ei saa sellele vajadusel tugineda
• piiratud katvus: infrastruktuuri komponendid võivad olla väga tihedalt läbi põimunud ja kõik elemendid ei kajastu alati diagrammil
• piiratud teave: reeglina näidatakse iga elemendi kohta ainult kõige olulisem teave, näiteks domeeninimi või IP-aadress
• analüüsi keerukus: skeemi suure katvuse ja erinevate komponentidevaheliste keerukate suhete olemasolul on selliste skeemide analüüs keeruline

ITIL-i soovituste järgi üles ehitatud teenusevarade ja konfiguratsioonide haldamise protsess võimaldab teil IT-infrastruktuuri kohta saadaolevaid andmeid kõige tõhusamal viisil kasutada, vältides samal ajal neid puudusi ja hankides täiendavaid eeliseid.

Teenusevarade ja konfiguratsioonihaldus (SACM) on protsess, mis vastutab selle eest, et kõiki teenuste osutamiseks vajalikke varasid kontrollitakse ning nende kohta on vajaduse korral saadaval täpne ja usaldusväärne teave. See teave hõlmab varade konfiguratsiooni ja nendevahelisi seoseid.

Teenuse varade ja konfiguratsiooni haldamine sisaldab kahte alamprotsessi:

• Varahaldus on tegevus või protsess, mis vastutab varade väärtuse ja omandiõiguse jälgimise ja aruandluse eest kogu nende elutsükli jooksul.
• Konfiguratsioonihaldus on tegevus või protsess, mis vastutab IT-teenuste osutamiseks vajalike konfiguratsiooniüksuste teabe haldamise eest, sealhulgas nende suhete eest.

Teenusevarade ja konfiguratsioonihaldusprotsessi ülesanded:

• Identifitseerige, kontrollige, dokumenteerige, teatage ja kinnitage teenusevarad ja konfiguratsioonielemendid, sealhulgas versioonid, lähtetasemed, komponendid, nende atribuudid ja seosed
• Vastutab teenuse varade ja konfiguratsiooniüksuste (ja vajaduse korral kliendile kuuluvate) terviklikkuse haldamise, kaitsmise ja kaitsmise eest kogu teenuse elutsükli jooksul, tagades, et kasutatakse ainult volitatud komponente ja tehakse ainult volitatud muudatusi.
• Tagage teenuste ja IT-infrastruktuuri haldamiseks vajalik varade ja konfiguratsiooni terviklikkus, luues ja hooldades täpset ja terviklikku konfiguratsioonihaldussüsteemi

Protsessi tuum on konfiguratsioonihaldussüsteem (CMS). CMS võimaldab salvestada kogu vajaliku seadistusteabe, selle analüüsi ja esitluse erinevatesse sektsioonidesse.

Konfiguratsioonihaldussüsteem (CMS) Tööriistade, andmete ja teabe kogum, mida kasutatakse teenusevarade ja konfiguratsioonide haldamise protsessi toetamiseks. CMS – osa üldisest teenuse teadmiste haldamise süsteemist, sisaldab tööriistu kõigi konfiguratsiooniüksuste ja nende seoste kohta teabe kogumiseks, salvestamiseks, haldamiseks, värskendamiseks, analüüsimiseks ja esitamiseks. CMS võib sisaldada ka teavet juhtumite, probleemide, teadaolevate vigade, muudatuste ja väljalasete kohta. CMS-i toetab teenusevarade ja konfiguratsioonihaldusprotsess ning seda kasutavad kõik IT-teenuste haldusprotsessid.

Konfiguratsioonielement (CI) on mis tahes komponent või muu teenuse vara, mida tuleb IT-teenuse pakkumiseks hallata. Teave iga konfiguratsiooniüksuse kohta salvestatakse konfiguratsioonihaldussüsteemis konfiguratsioonikirje kujul ning teenusevara ja konfiguratsioonihaldusprotsess hoiab seda kogu elutsükli jooksul ajakohasena. CI-d on muudatuste juhtimise protsessi kontrolli all. Tavaliselt hõlmavad need IT-teenuseid, riistvara, tarkvara, hooneid, inimesi ja dokumente, nagu protsessidokumentatsioon ja teenusetaseme lepingud.

Konfiguratsiooniüksused võivad olla tehnilisi vahendeid, igat tüüpi tarkvara, aktiivsed ja passiivsed võrguelemendid, serverid, ehitusplokid, dokumentatsioon, protseduurid, teenused ja kõik muud IT-organisatsiooni kontrollitavad IT-komponendid jne. CMS-is on salvestatud järgmist tüüpi objekte:

• konfiguratsiooniüksuse kirjed, sealhulgas nende vastavad atribuudid
• konfiguratsioonielementide vahelised suhted (lingid).

Atribuudid võimaldavad teil arvesse võtta teatud tüüpi konfiguratsiooniüksuste jaoks vajalikku teavet. Näiteks serverite ja sülearvutite puhul võib huvi pakkuda selline teave nagu tootja, domeeninimi, garantiiaeg jne. Tarkvara puhul on see teave aga tõenäoliselt erinev.

Atribuut on infokild konfiguratsiooniüksuse kohta. Näiteks nimi, asukoht, versiooni number ja hind. CI atribuudid salvestatakse (CMDB) ja neid hoitakse osana konfiguratsioonihaldussüsteemist (CMS).

Seega peab iga konfiguratsiooniüksus kuuluma kindlasse tüüpi (klassi), mis määratleb kõigi seda tüüpi (klassi) CI-de ühised atribuudid ning seda tüüpi CI-de ja teist tüüpi CI-de vaheliste võimalike seoste loendi.

CU tüüp – kategooria, mida kasutatakse konfiguratsioonielementide klassifitseerimiseks. CI tüüp määrab, millised atribuudid ja seosed on konfiguratsioonikirje jaoks vajalikud. Levinud CI tüübid on riistvara, dokumentatsioon, kasutaja jne.

CU-de komplekt ja nende seosed on tegelikult konfiguratsioonimudel. Joonisel on konfiguratsioonimudeli näide.
CMS võimaldab tõhusalt arvesse võtta vajalikku konfiguratsiooniteavet, analüüsida ja esitada erinevaid vorme sealhulgas graafiline. CMS pakub teavet teistele teenusehaldusprotsessidele:

• vahejuhtumite ja probleemide mõju hindamiseks
• muutuste mõju hindamiseks
• uute ja muutuvate teenuste kavandamiseks ja kujundamiseks
• tehnoloogia ja tarkvara uuendamise planeerimiseks
• väljalaskepakettide planeerimiseks ja paljundusteenuste jaoks
• varade ja kulude kasutamise optimeerimiseks

Seega, kui teenusevarade ja konfiguratsioonide haldamine on tõhusalt rakendatud, võib see protsess anda teavet näiteks järgmise kohta:

• Finantsteave ja ettevõtte tootepoliitika
• Millised IT-komponendid on praegu iga mudeli (versiooni) puhul kasutusel ja kui kaua?
• Millised trendid on erinevates tooterühmades?
• Mis on IT-komponentide jooksev- ja jääkväärtus?
• Millised IT-komponendid tuleb töökeskkonnast eemaldada ja millised kaasajastamist?
• Kui palju maksab teatud komponentide väljavahetamine?
• Millised litsentsid on saadaval ja kas neist piisab?
• Millised saatelepingud tuleks üle vaadata?
• Milline on infrastruktuuri standardimise aste?
• Veaotsing ja tulemuste hindamine
• Milliseid IT-komponente on vaja taastumisprotsessi toetamiseks hädaolukord?
• Kas situatsiooni taastamise plaan töötab, kui infrastruktuuri konfiguratsiooni on muudetud?
• Milliseid IT-komponente mõjutab uute teenuste kasutuselevõtt?
• Kuidas on seadmed võrku ühendatud?
• Milliseid tarkvaramooduleid iga tarkvarapakett sisaldab?
• Milliseid IT komponente muudatused mõjutavad?
• Millised muudatustaotlused (RFC-d) konkreetsete IT-komponentide jaoks on ootel ning millised intsidendid ja probleemid on minevikus esinenud ja on endiselt asjakohased?
• Millised IT-komponendid põhjustavad teadaolevaid vigu?
• Milliseid IT-komponente osteti konkreetselt müüjalt teatud perioodi jooksul?
• Teenuste pakkumine ja arveldamine
• Millised IT-komponentide konfiguratsioonid on teatud teenuste jaoks olulised?
• Milliseid IT-komponente millises kohas ja kes kasutab?
• Milliseid standardseid IT-komponente saab kasutaja tellida ja milliseid toetatakse (tootekataloog)?

Tegevused teenusevarade ja konfiguratsioonihaldusprotsessi raames

Joonisel on kujutatud tüüpiliste diagramm.

ITIL-i materjalides tähendab "planeerimine" konfiguratsioonihaldusprotsessi enda korraldamise tegevust. Juhtimist ja planeerimist kui tegevusliiki kasutatakse nii loomise kui protsessi täiustamise etapis. Planeerimise põhiväljundiks on "Konfiguratsioonihaldusplaan".

Konfiguratsioonihaldusplaan sisaldab.

• Konfiguratsioonihaldusprotsessi kirjeldus
• Süsteemi arhitektuuri kõrgetasemeline kirjeldus
• Planeerige olulisi sündmusi (tuvastus, suuremad väljaanded jne)

Plaan on elav dokument ja see vaadatakse korrapäraselt läbi. Plaani uuendamise eest vastutab konfiguratsioonihalduse protsessihaldur.

Konfiguratsiooni tuvastamise tegevused hõlmavad järgmist:

• Konfiguratsioonielementide ja nende koostisosade valiku kriteeriumide määratlemine ja dokumenteerimine
• Konfiguratsioonielementide ja komponentide valik dokumenteeritud kriteeriumide alusel
• Unikaalsete identifikaatorite määramine
• Iga CI atribuutide määratlemine
• Selle hetke kindlaksmääramine, millal CU protsessi kontrolli alla võetakse
• Iga CI eest vastutava omaniku määramine

Olenevalt IT infrastruktuuri mastaabist ja raamatupidamisreeglite keerukusest võib tuvastamine olla aeganõudev ja ressursimahukas. Seetõttu tuleb identifitseerimistööd hoolikalt planeerida.

KE juhtimistegevused hõlmavad järgmisi aspekte:

• CMDB andmete ajakohasena hoidmine
• CMDB andmete terviklikkuse tagamine (iga CI päritolu ja muudatuste ajalugu on selge)
  • Juurdepääsu piiramine CMDB andmete muutmiseks
  • CMDB juhtelementide viirusetõrje tagamine
  • Pakkuge varundamise ja taastamise võimalusi
• Kontrollireeglid tuleks välja töötada protsessi planeerimisetapis
• Projektide või tarnijate kontrolli üleandmise reeglid
• Kontrolliprotseduurid peavad vastama CU tüüpidele

Konfiguratsiooni oleku arvestus- ja aruandlustegevused hõlmavad järgmist:

• Konfiguratsioonikirjete säilitamine kogu teenuse elutsükli jooksul ja nende arhiveerimine vastavalt lepingutele, välisnõuetele, parimatele tavadele ja standarditele (nt ISO 9001)
• Dokumentatsiooni haldamine, praeguse konfiguratsiooni oleku ja kõigi eelmiste konfiguratsioonide olekute hankimine ja konsolideerimine, et tagada teabe õigsus, õigeaegsus, terviklikkus ja turvalisus
• Olekuteabe kättesaadavuse tagamine kogu teenuse elutsükli jooksul
• CI muutuste dokumenteerimine vastuvõtmisest dekomisjoneerimiseni
• Põhikonfiguratsioonide nõuetekohase dokumenteerimise tagamine

Kontrollimine ja audit:

• Kontrollimine – CU vastavuse kontrollimine standarditele või funktsionaalsetele nõuetele:
• Kell esmane registreerimine CMDB-s
• Kui saate tarnijalt riist- või tarkvara
• Kasutuselevõtmisel
• Audit – CI praeguse oleku (nagu see on) ja CMDB-s oleva CI kirjelduse (nagu see peaks olema) vastavuse kontrollimine
• Standardne audit
• Lihtsustatud audit
• Jooksev (tegevus)audit

• Vahetult pärast rakendamist uus süsteem/ konfiguratsioonihaldusprotsess
• Enne ja pärast suuri IT infrastruktuuri muudatusi
• Enne uue tootmisvalmidustarkvara juurutamist
• Pärast suurest katkestusest taastumist (hädaolukord)
• Suure hulga lahknevuste avastamisel (näiteks tegevusauditi käigus)
• Regulaarselt (ettemääratud ajavahemike järel)
• Aeg-ajalt ("äkilised" kontrollid)

Teenuse varade ja konfiguratsioonihaldusprotsessi mõõdikud

Muudatuste juhtimise protsessi tõhususe juhtimiseks ja hindamiseks ning teistele juhtimisprotsessidele tagasiside andmiseks soovitab ITIL kasutada selliseid põhinäitajaid nagu:

• Varade elutsükli toe parandamise protsent põhimõtte järgi: mitte liiga palju, mitte liiga hilja
• Mil määral toetus vastab ettevõtte vajadustele
• Teenuse katkestuste põhjusena tuvastatud varad
• Juhtumite lahendamise ja teenuse taastamise kiiruse suurendamine ebaõnnestunud CI-de kiirema tuvastamise kaudu
• Seoste tuvastamine konkreetset tüüpi CI-de, vahejuhtumite ja probleemide vahel
• Rohkem tõhus kasutamine teenuse vara
• Ostetud litsentside tõhusam kasutamine, keskmine litsentsikulu kasutaja kohta
• Täpsem eelarve koostamine ja kasutuspõhised varad
• Tõhusamad varaauditid
• Varade teabe kvaliteedi ja täpsuse parandamine
• Vähem aegunud andmetega töötamise põhjustatud vigu
• Auditite arvu ja ulatuse vähendamine
• Volitamata riist- ja tarkvara väiksem kasutamine, mis vähendab teenindustoe kulusid ja riske
• Vähendage vahejuhtumite ja probleemide diagnoosimise ja lahendamise aega ja kulusid
• Toimivuse seisukohalt probleemsete varade tuvastamiseks kuluva aja vähendamine
• Ebaõigetest mõjuhinnangutest, CMS-i ebaõigetest andmetest või kehvast versioonikontrollist põhjustatud ebaõnnestunud muudatuste arvu vähendamine
• Vähendage riski volitamata muudatuste varajase avastamisega

Raskused

Teenusevarade ja konfiguratsioonihalduse juurutamisel tuleb arvestada järgmiste võimalike väljakutsetega.

• Personali veenmine tehniline abi järgima arvestuspõhimõtteid, mida sageli tajutakse teenuste kiirel toetamisel takistusena.
• Protsessi jaoks raha eraldamist meelitada ja põhjendada, kuna tavaliselt ei ole protsess raha eraldamiseks volitatud kliendiosakondadele nähtav. Tavaliselt rahastatakse muudatuste juhtimise ja muude "nähtavamate" protsesside "nähtamatu" elemendina
• Lähenemisviis: "kogume kõik andmed, mida saame", mis põhjustab protsesside ülekoormust ja võimetust neid säilitada
• Juhtkonna pühendumuse ja toetuse puudumine, kes ei mõista protsessi võtmerolli

Kriitiliste juhtumite meetod.

Kriitilise juhtumi tuvastamine - see on tuvastamiseks loodud meetod

protsess, alamprotsess või probleemvaldkond, mida tasub kaaluda

parandada. Meetodi töötas välja Lawlor 1985. aastal. See on üsna avatud

Lühim ja lühim viis saada teavet organisatsiooni probleemide kohta. Eelduseks on, et kõik osalejad on täiesti tasuta

oma seisukohti esitades. Igasugune tsensuur või teabe varjamine kartuses

ega seda, et see osutub liiga ausaks, lükatakse kindlalt tagasi.

Meetod sisaldab kolme etappi:

üks). Valitakse analüüsis osalejad. Kui eesmärk on

Otsuse tegemine kogu protsessi täiustamiseks on loomulik

kaasata organisatsiooni erinevate valdkondade esindajaid. Kui

Eesmärk on täpsemalt määratleda tegevuse suund

juba määratletud äriprotsess, on parem valida sellega seotud inimesed

seda protsessi.

2). Seejärel palutakse osalejatel vastata järgmistele küsimustele:

Millise juhtumiga eelmisel nädalal oli kõige raskem toime tulla?

Millise episoodi sa lõid? suurimad probleemid vajaduste rahuldamiseks

tarbijate vajadused?

Milline juhtum maksis kaasamise mõttes kõige rohkem

lisaressursse või otseseid kulusid?

Selles meetodi kasutamise etapis on oluline esile tuua nn Cree-

tic juhtumid, mis ühel või teisel viisil probleeme tekitavad

üksikutele töötajatele, kogu organisatsioonile ja teistele sidusrühmadele

vannitoa küljed. Ajavahemik, millega küsimus on seotud, võib erineda.

mitmest päevast mitme kuuni. Ei soovita siiski

võtab liiga kaua aega, sest antud juhul võib see nii olla

tüütu tõsta esile kõige olulisemat kriitilist juhtumit, sest

et pika aja jooksul võib selliseid juhtumeid olla palju.

3). Kogutud vastused sorteeritakse ja tehakse kindlaks, milline erinevatest algatustest

Dentovit mainiti sagedamini kui teisi. Kriitilise juhtumi esiletõstmiseks

mugav on kasutada saadud tulemuste graafilist esitust. See

juhtum, mis leidis aset sagedamini kui teised ja on kriitiline. Ta on jav-

ennetustöö kandidaat. Siiski peate võitlema mitte niivõrd iseendaga

juhtum ja selle sümptom, nii palju kui ka selle põhjustanud põhjused.

Näide.

Algas suurkorporatsioon, mille koosseisus oli 15 telefonioperaatorit

tarbijate telefoniteenuse parandamise projektile

sõnumeid kõnede jaoks. Otsustati kasutada kriitilise tuvastamise meetodit

tic juhtum.

Kõigil telefonioperaatoritel paluti kirjeldada juhtumeid

eelmisel kuul, mis pani nad äärmiselt raskesse olukorda. Küsitluste tulemused sorteeriti sageduse järgi

vahejuhtumite kordumine. Need on näidatud joonisel fig. 7.1 diagrammi kujul. ri-

päike näitab, et kriitilised juhtumid olid: 1) suutmatus läbi saada

isik, kes peaks kõnele vastama, 2) ei tea, kes täpselt peaks

naised vastama. Uuringu tulemuste põhjal tehti jõupingutusi

luua süsteem iga töötaja liigutuste jälgimiseks, samuti

la töötas välja juhised, kes töötajatest ja millisel nõudmisel peaks

vastata. Kontrollnimekiri - see on vorm-vorm või selleks ette nähtud erivorm

alustas andmete logimisega, Rolstados (1995). Üks peamisi

Kontrollnimekirja eesmärk on salvestada, kui sageli

kokku puutuda erinevate probleemide või vahejuhtumitega. See annab olulist teavet

teave probleemsete piirkondade või võimalike vigade põhjuste kohta. Kasutamine

kontrollnimekirjad annavad hea aluse otsustamiseks, kus

jõupingutused tuleks koondada parandamisele.

Kontrollnimekirja täitmine toimub tavaliselt mitmes etapis:

1) Kokkuleppe saavutamine, milliseid sündmusi salvestada. Kõik see on vajalik

määrata täpselt nii, et poleks kahtlust sündmuse toimumises

tegelikult. Samuti on soovitatav lisada punkt kontrollnimekirja

"Muu", et registreerida juhtumeid, millele on raske omistada

2) Andmete salvestamise perioodi kindlaksmääramine ja selle mugav jaotamine inter-

3) Registreerimiseks kasutatava kontrolllehe vormi (tühi) väljatöötamine

traditsioonid. 4) Andmete kogumine toimub kogu kokkulepitud aja jooksul.

Kõigepealt peate veenduma, et kõik osalejad

andmete kogumine mõistab samavõrra ka toimuva olemust. Seejärel koguti

erinevate inimeste andmed on järjepidevad.

5) Andmete kogumise lõpus analüüsitakse neid sündmuste tuvastamiseks

seosed kõrgeima avaldumissagedusega. See määrab

prioritiseerida probleemsed valdkonnad antud äriprotsessis

rõhuasetuse tõstmine parendustööle. Mugav abivahend

võimas tööriist sellise analüüsi läbiviimiseks on Pareto diagrammPareto diagramm

Selle skeemi ülesehitus põhineb nn Pareto põhimõttel,

jäljendas Itaalia matemaatik Vilfredo Pareto 1800. aastatel. alla-

selle skeemi üksikasjad leiate ka Rolstadose raamatust. Pareto oli

mures rikkuse jaotumise pärast ühiskonnas ja uskus, et 20% elanikkonnast

moodustavad 80% kogu rikkusest. Kvaliteedisüsteemide kaasaegsesse keelde tõlgituna see

põhimõte on, et sageli umbes 80% kõigist võimalikest ilmingutest

ligikaudu 20% kõigist võimalikest põhjustest. tark lähenemine sellele

juhtum – alustada tööd täiustamise nimel, rünnates just neid 20%

auastmed, mida tavaliselt nimetatakse "eluliseks vähemuseks". See on üsna

ei tähenda, et võite ülejäänud 80% põhjustest ignoreerida: õiges

ajahetkel nendel põhjustel, mida nimetatakse "see kõige olulisem

vara”, tuleks samuti käsitleda. Pareto põhimõte seab esikohale

lahendamist vajavad probleemid.

Pareto diagramm ise on graafiline tõlgendus

nn 80/20 reegli kaldjaotuse näol. Need on põhjused

sorteeritud tähtsuse, esinemissageduse, maksumuse järgi,

näitajate taseme järgi jne. Põhjuste tellimisel Pareto diagrammil

kõige olulisemad neist on viidatud skeemi vasakusse serva, nii et see on "eluline

oluline vähemus" oli lihtne tuvastada. Teabe parandamiseks

sellele rakendatakse tavaliselt Pareto diagrammi aktiivsust ja akumuleeritud osade kõverat

et. Diagrammi koostamise näide on näidatud joonisel fig. 7.4.

Pareto diagrammiga töötades tehke järgmist.

üks). Tuvastage sündmuse põhiprobleem ja selle erinevad võimalikud kasutusvõimalused.

auastmed. Selles raamatus tehtud eelduste põhjal eeldame, et

et konkreetne protsess on juba valitud, mida on soovitav täiustada. Niisiis

Seega on Pareto diagrammi koostamise eesmärk tuvastada

madala jõudluse peamised põhjused.

2). Otsustage, millist mõõdikut millal kasutada

võimalike põhjuste võrdlus. Selline näitaja võiks olla

võtta territooriumil erinevate probleemide esinemise sagedus või nende tagajärjed

rahaliste kulude ja muude tingimuste kaevandused.

3). Määrake ajavahemik, mille jooksul andmeid kogutakse ja

võta neid. Sageli tehakse see töö juba varem ära, kui

kontrollnimekirjade täitmine. Kontrollnimekirja olemust kirjeldab § 7.2.

neli). Järjestage põhjused vasakult paremale piki diagrammi horisontaaltelge

Pareto nende suhtelise tähtsuse kahanevas järjekorras. Joonista tabel

skeemi majakad. Nende kõrgus vastab suhtelise tähtsuse astmele

juhtiv põhjus. 5). Märkige saadud indikaatorite absoluutväärtused vasakpoolsesse vertikaali-

telg. Märkige paremal indikaatorite suhtelised väärtused protsentides

vertikaaltelje ulgumine. Joonistage piki ülaosast kogunemiskõver

talle veergude servad.

Pareto diagrammi uurimine võib anda vastuse järgmistele küsimustele: 1) „Mis on

on kaks või kolm peamist põhjust madala jõudluse tasemeks selles

protsessi? või 2) „Milline osa kuludest läheb kõige olulisematele

põhjused?". Seda teavet saab kasutada toiminguteks

keskendunud jõupingutustele, et parandada protsessi saavutamise suunas

tema kõrgeimad hinded.

Pareto diagrammi ehitust saab lihtsustada, kui kasutada standardit

arvutitarkvara, mis on ette nähtud elektrooniliseks kompileerimiseks

kroonlauad. Samas on olemas spetsialistid Pareto diagrammide koostamiseks.

kontrollitud tarkvara. Kaks sellist spetsiaalset arvutiprogrammi on StatGraphics Plus ja ASAS/QC. Annavad ka

kasutajal on võimalus koostada EMS-i juhtimiskaarte "a. Märkame ka paketti

Memory Jogger tarkvara, mida saab rakendada mõne tööriistaga

kvaliteedi parandamine.

Eelised: Võimaldab saada infot omaduste kohta, mis aitavad kaasa või takistavad töös tulemuste saavutamist. Soodustab paremat mõistmist sisu tööd.

Puudused: Mõnda saadud teavet ei pruugita mudeli loomisel kasutada, kuna mitmed kirjeldatud juhtumid võivad lõpuks osutuda töö jaoks täiesti ebatüüpilisteks.

11. oktoober 2012, kell 10:58

Juhtumi käsitlemine infoturbe

• Infoturbe

Tere päevast, kallis habrahabr!

Jätkan artiklite avaldamist infoturbe praktikast.
Seekord räägime sellisest olulisest komponendist nagu turvaintsidendid. Juhtumitega töötamine võtab pärast infoturbe režiimi kehtestamist lõviosa ajast (dokumendid võetakse vastu, installitakse ja konfigureeritakse tehniline osa viis läbi esimesed koolitused).

Juhtumite aruandlus

Kõigepealt peate saama teavet juhtumi kohta. Seda punkti tuleb arvestada turvapoliitika kujundamise ja töötajate infoturbealase õppeprogrammi esitluste koostamise etapis.
Peamised teabeallikad:

1. Helpdesk.
Reeglina (ja see on hea traditsioon) helistatakse või kirjutatakse seadmete töös esinevatest probleemidest, riketest või tõrgetest teie IT-teenuse kasutajatoele. Seetõttu on vaja eelnevalt kasutajatoe äriprotsessi "kinnitada" ja märkida ära juhtumitüübid, millega taotlus infoturbe osakonda edastatakse.

2. Sõnumid otse kasutajatelt.
Korraldage ühtne kontaktpunkt, millest teavitatakse töötajate infoturbe koolitusel. Hetkel ei ole organisatsioonide infoturbe osakonnad reeglina kuigi suured, koosnevad sageli 1-2 inimesest. Seetõttu on vahejuhtumite vastuvõtu eest vastutaja määramine lihtne, ei pea vaeva nägema isegi IS-i kasutajatoe vajadusteks e-posti aadressi eraldamisega.

3. IS-i töötajate avastatud juhtumid.
Siin on kõik lihtne ja sellise vastuvõtukanali korraldamiseks pole vaja keha liigutusi teha.

4. Logid ja süsteemihoiatused.
Seadistage viirusetõrje, IDS, DLP ja muude turvasüsteemide konsoolis hoiatused. Mugavam on kasutada koondajaid, mis koguvad andmeid ka teie organisatsiooni installitud programmide ja süsteemide logidest. Erilist tähelepanu tuleks pöörata kokkupuutepunktidele välisvõrguga ja kohtadele, kus hoitakse tundlikku teavet.

Kuigi turvaintsidendid on mitmekesised ja mitmekesised, on neid üsna lihtne jagada mitmesse kategooriasse, mille kohta on lihtsam statistikat pidada.

1. Konfidentsiaalse või mitteavaliku teabe avaldamine või sellise avalikustamise oht.
Selleks on vajalik vähemalt ajakohane konfidentsiaalse teabe loend, toimiv süsteem elektrooniliste ja paberkandjate tembeldamiseks. Hea näide- peaaegu kõikidel juhtudel organisatsiooni siseportaalis või sisemises failimälus asuvatel dokumendimallidel on vaikimisi silt "Ainult sisekasutuseks".
Et selgitada veidi avalikustamise ohtu, kirjeldasin eelmises postituses olukorda, kus dokument, millel oli silt "Ainult sisekasutuseks", postitati teise organisatsiooni kõrval asuvasse ühissaali. Võib-olla ei olnud avalikustamist ennast (see postitati pärast tööpäeva lõppu ja seda märgati väga kiiresti), kuid avalikustamise ähvarduse fakt on näos!

2. Volitamata juurdepääs.
Selleks peab teil olema kaitstud ressursside loend. See tähendab, et need, kus on mis tahes tundlikku teavet organisatsiooni, selle klientide või töövõtjate kohta. Veelgi enam, sellesse kategooriasse on soovitav lisada mitte ainult arvutivõrku tungimine, vaid ka volitamata juurdepääs ruumidele.

3. Liigne volitus.
Põhimõtteliselt saab selle punkti kombineerida eelmisega, kuid parem on see eraldi välja tuua, selgitan, miks. Volitamata juurdepääs viitab nende isikute juurdepääsule, kellel puudub seaduslik juurdepääs organisatsiooni ressurssidele või ruumidele. See on väline sissetungija, kellel pole teie süsteemi seaduslikku sisenemist. Võimu kuritarvitamise all mõistetakse volitamata juurdepääsu organisatsiooni seaduslike töötajate mis tahes ressurssidele ja ruumidele.

4. Viiruse rünnak.
Sel juhul peate mõistma järgmist: töötaja arvuti ühekordne nakatumine ei tohiks viia menetluse algatamiseni, kuna see võib olla tingitud veast või kurikuulsast inimtegurist. Kui märkimisväärne protsent organisatsiooni arvutitest on nakatunud (siinkohal lähtuge masinate koguarvust, nende jaotusest, segmenteerimisest jne), siis on vaja kasutusele võtta turvaintsidendi täiemahuline arendus koos vajalike otsingutega. nakkusallikad, põhjused jne.

5. Kontode kompromiteerimine.
See punkt kajab 3 . Tegelikult toimub juhtum alates 3 sisse 5 kategooria, kui juhtumi uurimise käigus selgub, et kasutaja ei saanud sel hetkel füüsiliselt ja tegelikult oma mandaate kasutada.

Juhtumi klassifikatsioon

Selle vahejuhtumitega töötamise punktiga saate teha kahte võimalust: lihtsat ja keerukat.
Lihtne viis on võtta oma IT-teenuse taseme leping ja kohandada seda vastavalt oma vajadustele.
Keeruline viis: riskianalüüsi põhjal tuvastada intsidentide ja/või varade rühmad, mille puhul peab toimuma viivitamatu lahendus või intsidendi põhjuste kõrvaldamine.
Lihtne tee töötab hästi väikestes organisatsioonides, kus pole palju tundlikku teavet ja ei tohutu hulk töötajad. Kuid tuleb mõista, et IT-teenus lähtub SLA-st oma riskidest ja juhtumite statistikast. Võimalik, et ummistunud printer on laual tegevdirektor on väga kõrge prioriteediga, kui teie jaoks on olulisem ettevõtte andmebaasi administraatori parooli rikkumine.

Juhtumite tõendite kogumine

On olemas spetsiaalne rakendusteadus – kriminalistika, mis tegeleb arvutikuritegude valdkonna kriminalistikaga. Ja seal on suurepärane raamat Fedotov N.N. "Kriminalistika – arvutiekspertiis". Ma ei hakka praegu kohtuekspertiisi üksikasjalikult kirjeldama, vaid toon välja 2 põhipunkti tõendite säilitamisel ja esitamisel, millest tuleb kinni pidada.

Paberdokumentide puhul: originaali hoitakse turvaliselt koos dokumendiga, kes dokumendi avastas, kust dokument leiti, millal dokument leiti ja kes avastamist nägi. Igasugune uurimine peab tagama, et originaale ei ole võltsitud.
Teabe saamiseks arvutimeediumite kohta: peegeldus või mis tahes irdkandja, kättesaadavuse tagamiseks tuleb võtta teave kõvaketaste või mälu kohta. Kõigi kopeerimisprotsessi käigus tehtud tegevuste kohta tuleb pidada arvestust ja protsessi pealt näha. Originaalkandja ja protokoll (kui see pole võimalik, siis vähemalt üks peegelpilt või koopia) tuleb hoida turvaliselt ja puutumata

Pärast juhtumi lahendamist

Seega on juhtum lahendatud, tagajärjed likvideeritud ja ametkondlik juurdlus läbi viidud.
Kuid töö ei pea sellega lõppema.
Järgmised sammud pärast juhtumit:

Intsidendi toimumiseni viinud riskide ümberhindamine
kaitsemeetmete loetelu koostamine tuvastatud riskide minimeerimiseks juhtumi kordumise korral
vajalike poliitikate, määruste, infoturbe reeglite uuendamine
viia läbi organisatsiooni personali, sh IT-töötajate koolitusi infoturbealase teadlikkuse tõstmiseks

See tähendab, et on vaja võtta kasutusele kõik võimalikud meetmed, et minimeerida või neutraliseerida haavatavust, mis viis turvaohu realiseerumiseni ja sellest tulenevalt intsidendini.

1. Pidage vahejuhtumite logi, kuhu salvestate avastamise aja, juhtumi avastanud isiku andmed, intsidendi kategooria, mõjutatud vara, juhtumi lahendamise kavandatud ja tegeliku aja, samuti intsidendi lahendamiseks tehtud töö. lahendada juhtum ja selle tagajärjed.
2. Salvestage oma tegevused. See on vajalik ennekõike enda jaoks, et intsidendi lahendamise protsessi optimeerida.
3. Teavitage juhtunust töötajaid, et nad esiteks teie uurimist ei segaks ja teiseks välistaks mõjutatud varade kasutamise uurimise käigus.

Ettevõtluse infoturbe tagamine Andrianov V.V.

4.1.4. Näited juhtumitest

4.1.4. Näited juhtumitest

Üldine informatsioon

Selles jaotises kirjeldatakse mõnede kõrgetasemeliste juhtumite avaldatud üksikasju. Samas annab intsidentide üldistamine terve hunniku asjaolusid, mis iseloomustavad personalist lähtuvate IS-ohtude mitmekesisust nii motiivide ja tingimuste kui ka kasutatavate vahendite osas. Kõige sagedamini esinevate juhtumite hulgas märgime järgmist:

Teenusteabe lekkimine;

Organisatsiooni klientide ja äri varastamine;

Infrastruktuuri sabotaaž;

Sisemine pettus;

Aruandluse võltsimine;

Kauplemine turgudel, mis põhineb siseringiteabel;

Võimu kuritarvitamine.

annotatsioon

Kättemaksuks liiga madala boonuse eest pani 63-aastane Roger Duronio (endine UBS Paine Webberi süsteemiadministraator) ettevõtte serveritesse "loogikapommi", mis hävitas kõik andmed ja halvas ettevõtte pikaks ajaks.

Sündmuse kirjeldus

Duronio polnud rahul oma 125 000 dollari suuruse aastapalgaga, mis võis olla "loogikapommi" kasutuselevõtu põhjuseks. Süsteemiadministraatori viimane õlekõrs oli aga loodetud 50 000 dollari asemel saadud 32 000 dollari suurune boonus. Kui ta avastas, et tema boonus on palju väiksem, kui ta ootas, nõudis Duronio ülemustelt 175 000 dollari suuruse töölepingu uuesti läbirääkimisi, vastasel juhul lahkub ta ettevõttest. Talle keelduti palgatõusust ja tal paluti pangahoonest lahkuda. Kättemaksuks selle kohtlemise eest otsustas Duronio kasutada oma eelnevalt tutvustatud "leiutist", nähes ette sündmuste sellist pööret.

Duronio viis "loogikapommi" sissetoomise koduarvutist läbi mitu kuud enne, kui sai tema arvates liiga väikese boonuse. "Loogikapomm" paigaldati umbes 1500 arvutisse kontorite võrku üle kogu riigi ja seati kindlale kellaajale – 9:30, täpselt pangapäeva alguseks.

Duronio lahkus UBS Paine Webberist 22. veebruaril 2002 ja 4. märtsil 2002 kustutas "loogikapomm" järjest kõik failid peamises keskandmebaasi serveris ja 2000 serveris 400 pangakontoris, samal ajal keelates varusüsteemi.

Kohtuprotsessil juhtis Duronio advokaadi tähelepanu sellele, et intsidendi süüdlased ei saanud olla ainult süüdistatavad: UBS Paine Webberi IT-süsteemide ebaturvalisust arvestades võis Duronio sisselogimise all sinna pääseda iga teine ​​töötaja. IT-turvaprobleemid pangas said teatavaks juba 2002. aasta jaanuaris: kontrollimisel selgus, et 40 IT-teenindajat said sama parooliga sisse logida ja administraatori õigused saada ning aru saada, kes mida täpselt tegi või mis tahes muud toimingut tegi. pole võimalik. Advokaat esitas rünnaku tõendite hävitamises süüdistuse ka UBS Paine Webberile ja @Stake'ile, kelle pank palkas juhtunut uurima. Vaieldamatuks tõendiks Duronio süüst olid aga tema koduarvutitest leitud pahatahtliku koodi killud ja koodi prinditud koopia kapist.

Siseringi võimalused

Ettevõtte ühe süsteemiadministraatorina sai Duronio vastutuse ja ligipääsu kogu UBS PaineWebberi arvutivõrgule. Samuti oli tal turvalise internetiühenduse kaudu juurdepääs võrgule koduarvutist.

Põhjused

Nagu varem öeldud, olid tema motiivid raha ja kättemaks. Duronio sai aastapalgaks 125 000 dollarit ja boonust 32 000 dollarit, kui ta ootas 50 000 dollarit, ja maksis sellega oma pettumuse kätte.

Lisaks otsustas Duronio rünnakust kasu lõigata: IT-katastroofi tõttu panga aktsiate kukkumise ootuses tegi ta müügiks futuurikorralduse, et kursi langemise korral vahe kätte saada. Kostja kulutas sellele 20 000 dollarit. Panga paberid aga ei kukkunud ning Duronio investeering ei tasunud end ära.

Efektid

Duronio paigaldatud "loogikapomm" peatas 2000 serveri töö 400 ettevõtte kontoris. UBS Paine Webberi IT-juhi Elvira Maria Rodriguezi sõnul oli tegemist katastroofiga "10 pluss skaalal 10". Ettevõttes valitses kaos, mille 200 inseneri IBM-ist peaaegu päevaks kõrvaldasid. Kokku töötas olukorra parandamisega umbes 400 spetsialisti, sealhulgas panga enda IT-teenus. Juhtunu kahju on hinnanguliselt 3,1 miljonit dollarit. Kaheksa tuhat maaklerit üle kogu riigi olid sunnitud töö lõpetama. Mõned neist suutsid mõne päeva pärast tavapäraste tegevuste juurde naasta, mõned mõne nädala pärast, olenevalt sellest, kui halvasti nende andmebaasid mõjutati ja kas pangakontorist tehti varukoopiaid. Üldiselt taastati pangatoimingud mõne päeva jooksul, kuid mõne serveri töö ei taastunud täielikult, peamiselt seetõttu, et 20% serveritest puudusid varuvõimalused. Vaid aasta hiljem taastati kogu panga serveripark täielikult uuesti.

Duronio juhtumit kohtus arutades süüdistati teda järgmiste artiklite alusel:

Väärtpaberipettus – selle artikli alusel süüdimõistva kohtuotsusega kaasneb maksimaalne karistus 10 aastat föderaalset vanglat ja 1 miljon dollarit trahvi;

Pettus arvutiga seotud tegevustes – selle artikli alusel esitatud süüdistuse eest võib määrata kuni 10-aastase vanglakaristuse ja 250 000 dollari suuruse trahvi.

Kohtuprotsessi tulemusel mõisteti Duronio 2006. aasta detsembri lõpus 97 kuuks tingimisi vabastamise õiguseta.

VimpelCom ja Sherlock

annotatsioon

Kasumi saamise eesmärgil on VimpelComi endised töötajad ( kaubamärk"Beeline") pakkus veebisaidi kaudu mobiilsideoperaatorite telefonivestluste üksikasju.

Sündmuse kirjeldus

VimpelComi töötajad (endised ja praegused) korraldasid Internetis veebisaidi www.sherlok.ru, millest VimpelCom sai teada 2004. aasta juunis. Selle saidi korraldajad pakkusid teenust - otsige inimesi nime, telefoninumbri ja muude andmete järgi. Juulis pakkusid saidi korraldajad uut teenust - mobiilsideoperaatorite telefonivestluste üksikasjad. Kõnede üksikasjad on kõigi sissetulevate ja väljaminevate kõnede numbrite väljatrükk, mis näitab kõnede kestust ja nende maksumust, mida operaatorid kasutavad näiteks abonentidele arveldamiseks. Nende andmete põhjal saab teha järelduse tellija praeguse tegevuse, tema huviala ja tutvusringkonna kohta. Siseministeeriumi büroo "K" (edaspidi Siseministeerium) pressiteates on kirjas, et selline teave läks kliendile maksma 500 dollarit.

Selle saidi avastanud VimpelComi töötajad kogusid iseseisvalt tõendeid kuritegelik tegevus kohas ja andis asja üle siseministeeriumile. Siseministeeriumi töötajad algatasid kriminaalasja ja tegid koos VimpelComiga kindlaks selle kuritegeliku äri korraldajad. Ja 18. oktoobril 2004 tabati peamine kahtlusalune 1 teolt.

Lisaks peeti 26. novembril 2004 kinni ülejäänud kuus kahtlusalust, sealhulgas kolm VimpelComi enda abonentteenuse töötajat. Uurimise käigus selgus, et saidi lõi endine Moskva üliõpilane riigiülikool ei tööta selles ettevõttes.

Selle juhtumi menetlemine sai võimalikuks tänu konstitutsioonikohtu 2003. aastal tehtud otsusele, milles tunnistati, et kõnede üksikasjad sisaldasid seadusega kaitstud telefonivestluste saladust.

Siseringi võimalused

Juhtunus osalejate seas tuvastatud Vimpelcomi töötajaist kaks töötasid ettevõttes telleritena ning kolmas oli endine töötaja ja töötas kuriteo ajal Mitinski turul.

Töö ettevõttes endas tellerina näitab, et neil töötajatel oli otsene juurdepääs veebisaidil www.sherlok.ru müügiks pakutavale teabele. Lisaks, kuna ettevõtte endine töötaja töötas juba Mitinsky turul, võib eeldada, et aja jooksul võib sellest turust saada üks selle teabe või muu VimpelComi andmebaaside teabe levitamise kanal.

Efektid

Selle juhtumi peamised tagajärjed VimpelComile võivad olla löök ettevõtte enda mainele ja klientide kaotus. See juhtum tuli aga avalikuks otseselt tänu ettevõtte enda aktiivsele tegevusele.

Lisaks võib selle teabe avalikustamine avaldada negatiivset mõju VimpelComi klientidele, kuna vestluste üksikasjad võimaldavad meil teha järeldusi tellija praeguse tegevuse, tema huviala ja tutvusringkonna kohta.

2005. aasta märtsis mõistis Moskva Ostankinski ringkonnakohus kahtlustatavatele, sealhulgas kolmele Vimpelcomi töötajale, erinevad rahatrahvid. Nii sai grupi korraldaja 93 000 rubla trahvi. Saidi www.sherlok.ru tegevus lõpetati aga määramata ajaks alles 1. jaanuarist 2008.

Jaapani ajaloo suurim isikuandmetega seotud rikkumine

annotatsioon

2006. aasta suvel toimus Jaapani ajaloo suurim isikuandmetega seotud rikkumine, kui trüki- ja elektroonikahiiu Dai Nippon Printing töötaja varastas ligi üheksa miljoni kodaniku privaatset teavet sisaldava plaadi.

Sündmuse kirjeldus

Trükitoodete tootmisele spetsialiseerunud Jaapani firma Dai Nippon Printing tegi oma riigi ajaloos suurima lekke. Ettevõtte ühe töövõtja endine töötaja Hirofumi Yokoyama kopeeris mobiilsele kõvakettale ja varastas ettevõtte klientide isikuandmed. Kokku oli ohus 8,64 miljonit inimest, kuna varastatud teave sisaldas nimesid, aadresse, telefoninumbreid ja krediitkaardinumbreid. Varastatud teave sisaldas 43 erineva ettevõtte kliendiandmeid, näiteks 1 504 857 American Home Assurance'i klienti, 581 293 Aeon Co klienti ja 439 222 NTT Finance'i klienti.

Pärast selle teabe varastamist avas Hirofumi privaatse teabe kauplemise 100 000 kirje kaupa. Tänu stabiilsele sissetulekule lahkus sisering isegi oma alalisest töökohast. Vahistamise hetkeks oli Hirofumil õnnestunud müüa 150 000 suurimate krediidifirmade kliendi andmed internetiostlemisele spetsialiseerunud petturite grupile. Lisaks on osa andmeid juba kasutatud krediitkaardipettusteks.

Rohkem kui pooled organisatsioonid, kelle kliendiandmed varastati, ei saanudki infolekke eest hoiatatud.

Efektid

Selle intsidendi tagajärjel ulatusid krediitkaardipettuste tõttu kannatanud kodanike kahjud, mis said võimalikuks alles selle lekke tagajärjel, mitme miljoni dollarini. Kokku mõjutati 43 erineva ettevõtte kliente, sealhulgas Toyota Motor Corp., American Home Assurance, Aeon Co ja NTT Finance. Enam kui pooled organisatsioonid ei saanud aga lekke eest isegi hoiatust.

Jaapan võttis 2003. aastal vastu 2003. aasta isikuandmete kaitse seaduse (PIPA), kuid prokurörid ei suutnud seda 2007. aasta alguses juhtumi tegelikul arutamisel kohaldada. Prokuratuur ei esitanud siseringi isikule süüdistust PIPA rikkumises. Teda süüdistatakse ainult 200-dollarilise kõvaketta varguses.

Pole hinnatud. Zaporožje häkker Ukraina panga vastu

annotatsioon

Ukraina ühe suurima panga endine süsteemiadministraator kandis omal ajal töötanud panga kaudu regionaaltolli kontolt olematu Dnepropetrovski pankrotistunud ettevõtte arvele umbes 5 miljonit grivnat.

Sündmuse kirjeldus

Süsteemiadministraatori karjäär algas pärast seda, kui ta oli lõpetanud tehnikumi ja ta palkas ühte Ukraina suurimasse panka tarkvara ja tarkvara osakonda. tehniline abi. Mõne aja pärast märkas juhtkond tema talenti ja otsustas, et osakonnajuhatajana oleks ta pangale kasulikum. Uue juhtkonna tulek panka tõi aga kaasa personalimuudatused. Tal paluti ajutiselt oma koht vabastada. Peagi hakkas uus juhtkond moodustama nende meeskonda ja tema talenti ei kasutatud ning talle pakuti olematut asejuhi kohta, kuid teises osakonnas. Taoliste personali ümberkorralduste tulemusena hakkas ta tegema midagi täiesti erinevat sellest, mida ta kõige paremini oskas.

Süsteemiadministraator ei suutnud leppida sellise juhtkonna suhtumisega endasse ja lahkus ametist omal soovil. Teda jäi aga kummitama tema enda uhkus ja solvumine juhtkonna suhtes, lisaks soovis ta tõestada, et on oma ala parim, ning naasta osakonda, kust tema karjäär alguse sai.

Pärast ametist lahkumist otsustas endine süsteemiadministraator taastada endise juhtkonna huvi oma isiku vastu, kasutades peaaegu kõigis Ukraina pankades kasutatava süsteemi “Pank-klient” ebatäiuslikkust 2 . Süsteemihalduri plaan oli selline, et ta otsustas oma kaitseprogrammi välja töötada ja oma eelmisele töökohale naastes seda pangale pakkuda. Plaani elluviimine seisnes süsteemi "Pank-Klient" tungimises ja selles minimaalsete muudatuste tegemises. Kogu arvutus tehti selle põhjal, et pank oleks pidanud avastama süsteemi häkkimise.

Sellesse süsteemi tungimiseks kasutas endine süsteemiadministraator paroole ja koode, mille ta õppis selle süsteemiga töötades. Kogu muu häkkimiseks vajalik info saadi erinevatelt häkkerite saitidelt, kus kirjeldati üksikasjalikult erinevaid arvutivõrkude häkkimise juhtumeid, häkkimise tehnikaid ning postitati kogu häkkimiseks vajalik tarkvara.

Süsteemi lünga tekitanud endine süsteemiadministraator tungis perioodiliselt panga arvutisüsteemi ja jättis sinna erinevaid märke, püüdes juhtida tähelepanu häkkimise faktidele. Panga spetsialistid pidid häkkimise tuvastama ja häirekella andma, kuid tema üllatuseks ei märganud keegi süsteemi tungimist.

Seejärel otsustas süsteemiadministraator oma plaani muuta, tehes selles muudatusi, mis ei saanud märkamata jääda. Ta otsustas võltsida maksekorraldus ja selle kaudu panga arvutisüsteemi kaudu suur summa üle kanda. kasutades sülearvutit ja mobiiltelefon sisseehitatud modemiga tungis süsteemiadministraator umbes 30 korda panga arvutisüsteemi: vaatas läbi dokumente, kliendikontosid, liikumist Raha- Sobivate klientide leidmine. Selliste klientidena valis ta piirkondliku tolli ja Dnepropetrovski pankrotistunud ettevõtte.

Saanud taas ligipääsu panga süsteemile, lõi ta maksekorralduse, milles koos isiklik konto piirkondlik toll taganes ja kandis panga kaudu pankrotistunud ettevõtte arvele 5 miljonit grivnat. Lisaks tegi ta "maksmisel" teadlikult mitu viga, mis omakorda oleks pidanud veelgi panga spetsialistide tähelepanu köitma. Kuid isegi selliseid fakte ei märganud panga "Pank-Klient" süsteemi teenindavad spetsialistid ja nad kandsid rahulikult 5 miljonit grivnat ettevõtte arvele, mida enam ei eksisteeri.

Tegelikult eeldas süsteemihaldur, et raha üle ei kanta, häkkimise fakt tuvastatakse enne raha ülekandmist, kuid praktikas läks kõik teisiti ja temast sai kurjategija ning tema võltsülekandest sai vargus.

Eriti suures ulatuses raha häkkimise ja varguse fakt avastati alles paar tundi pärast ülekannet, kui pangatöötajad helistasid ülekande kinnitamiseks tolli. Aga nad ütlesid, et sellist summat pole keegi üle kandnud. Raha tagastati kiiresti panka ja Zaporožje oblasti prokuratuuris algatati kriminaalasi.

Efektid

Pank kahju ei kandnud, kuna raha tagastati omanikule ning arvutisüsteem sai minimaalselt kahju, mistõttu panga juhtkond loobus igasugustest nõuetest endise süsteemihalduri vastu.

2004. aastal tõsteti Ukraina presidendi dekreediga kriminaalvastutust arvutikuritegude eest: rahatrahvid 600-lt 1000-le maksuvabale miinimumile, vangistus - 3-lt 6-le aastale. Endine süsteemiadministraator pani aga kuriteo toime enne presidendi dekreedi jõustumist.

2005. aasta alguses toimus kohtuprotsess süsteemiadministraatori üle. Teda süüdistati kuriteo toimepanemises Ukraina kriminaalkoodeksi artikli 361 2. osas - arvutisüsteemide töösse ebaseaduslikus sekkumises koos kahju tekitamisega ja artikli 185 5. osas - eriti suures ulatuses varguses. Kuid kuna panga juhtkond keeldus igasugustest nõuetest tema vastu, eemaldati temalt varguse artikkel ja artikli 361 2. osa muudeti osaks 1 – ebaseaduslik sekkumine arvutisüsteemide töösse.

Kontrollimatu kauplemine Societe Generale'is

annotatsioon

24. jaanuaril 2008 teatas Societe Generale oma kaupleja Jérôme Kervieli mahhinatsioonide tõttu 4,9 miljardi euro suurusest kahjust. Nagu näitas sisejuurdlus, avas kaupleja mitme aasta jooksul Euroopa aktsiaindeksite futuuride ülelimiidipositsioone. Avatud positsioonide kogumaht ulatus 50 miljardi euroni.

Sündmuse kirjeldus

2006. aasta juulist kuni 2007. aasta septembrini andis arvutipõhine sisekontrollisüsteem 75 korral (mitu korda tegi Jerome Kerviel volitamata tehinguid või ületasid tema ametikohad lubatud piiri) hoiatuse võimalike rikkumiste kohta. Panga riskijärelevalve töötajad neid hoiatusi üksikasjalikult ei kontrollinud.

Esimest korda alustas Kerviel volitamata kauplemise katsetamist 2005. aastal. Seejärel võttis ta Allianzi aktsiate suhtes lühikese positsiooni, oodates turu langust. Peagi turg tõesti kukkus (pärast Londoni terrorirünnakuid), seega teeniti esimesed 500 000 eurot. Oma tunnetest, mida ta oma esimesest edust koges, rääkis Kerviel hiljem uurimisele: "Ma teadsin juba, kuidas oma positsiooni sulgeda, ja olin tulemuse üle uhke, kuid samal ajal olin üllatunud. Edu sundis mind jätkama, see oli nagu lumepall... Juulis 2007 pakkusin turu languse ootuses lühikese positsiooni võtmist, kuid ei leidnud oma juhi toetust. Minu ennustus läks tõeks ja saime kasumit, seekord oli see täiesti seaduslik. Seejärel jätkasin selliste tehingute tegemist turul, kas võimude nõusolekul või nende selgesõnalise vastulause puudumisel ... 31. detsembriks 2007 ulatus minu kasum 1,4 miljardi euroni. Sel hetkel ma ei teadnud, kuidas seda oma pangale teada anda, kuna see oli väga suur summa, mida polnud kuskil deklareeritud. Olin õnnelik ja uhke, kuid ma ei teadnud, kuidas oma juhtkonnale selle raha laekumist selgitada ja mitte tekitada kahtlust volitamata tehingute tegemises. Seetõttu otsustasin oma kasumit varjata ja viia läbi vastupidise fiktiivse operatsiooni ... ".

Tegelikult sisenes Jérôme Kerviel sama aasta jaanuari alguses uuesti mängu Euro Stoxx 50, DAX ja FTSE kolme indeksi futuurilepingutega, aidates tal 2007. aasta lõpus turgu võita (kuigi ta eelistas siis võtta lühikest positsiooni ). Hinnanguliselt oli tema portfellis 11. jaanuari eelõhtul 707,9 tuhat futuuri (igaühe väärtusega 42,4 tuhat eurot) Euro Stoxx 50-l, 93,3 tuhat futuuri (192,8 tuhat eurot 1 tk) DAX-il ja 24,2 tuhat futuuri (82,7 tuhat eurot). eurot 1 lepingu kohta) FTSE indeksil. Üldjoontes võrdus Kervieli spekulatiivne positsioon 50 miljardi euroga ehk see oli rohkem kui panga väärtus, kus ta töötas.

Teades kontrollide aega, avas ta õigel ajal fiktiivse riskimaandamispositsiooni, mille hiljem sulges. Selle tulemusena ei näinud arvustajad kunagi ühtegi positsiooni, mida võiks nimetada riskantseks. Neid ei saanud hoiatada suured tehingumahud, mis on indeksite futuurilepingute turul üsna tavalised. Teda vedasid alt pangaklientide kontodelt tehtud fiktiivsed tehingud. Erinevate pangaklientide kontode kasutamine ei toonud kaasa kontrolleritele nähtavaid probleeme. Teatud aja möödudes hakkas Kerviel aga kasutama samade klientide kontosid, mis tõi kaasa nendel kontodel täheldatud "ebanormaalse" tegevuse ja pälvis omakorda vastutavate töötlejate tähelepanu. See oli pettuse lõpp. Selgus, et Kervieli partner mitme miljardi dollari suuruses tehingus oli Saksa suurpank, kes väidetavalt kinnitas astronoomilist tehingut meili teel. Elektrooniline kinnitus äratas aga inspektorites kahtlust, mille kontrollimiseks moodustati Societe Generale'is komisjon. 19. jaanuaril ei tunnistanud Saksa pank palve peale seda tehingut, misjärel kaupleja nõustus ülestunnistusega.

Kui spekulatiivse positsiooni astronoomiline suurus avastati, teatas Societe Generale tegevjuht ja direktorite nõukogu esimees Daniel Bouton kavatsusest Kervieli avatud riskantne positsioon sulgeda. See võttis kaks päeva ja tõi 4,9 miljardi euro suuruse kahjumi.

Siseringi võimalused

Jerome Kerviel töötas viis aastat panga nn tagakontoris ehk divisjonis, mis otseselt tehinguid ei sõlmi. See tegeleb ainult raamatupidamise, tehingute sooritamise ja registreerimisega ning kontrollib kauplejaid. See tegevus võimaldas mõista panga juhtimissüsteemide toimimise iseärasusi.

2005. aastal edutati Kerviel. Temast sai tõeline kaupmees. Otsestes kohustustes noor mees hõlmas elementaarseid toiminguid riskide minimeerimiseks. Euroopa aktsiaindeksite futuurilepingute turul töötades pidi Jerome Kerviel jälgima, kuidas panga investeerimisportfell muutub. Ja tema põhiülesanne, nagu selgitas üks Societe Generale esindajatest, oli riske vähendada, mängides vastupidises suunas: "Jämedalt öeldes, nähes, et pank panustab punasele, oleks pidanud panustama mustale." Nagu kõigil juuniorkauplejatel, oli ka Kervielil piir, mida ta ületada ei saanud, seda jälgisid tema endised kolleegid tagakontorist. Societe Generale kaitsetas mitut taset, näiteks said kauplejad positsioone avada vaid tööarvutist. Kõik andmed avamispositsioonide kohta edastati automaatselt reaalajas tagakontorisse. Aga nagu öeldakse, parim salakütt on endine metsamees. Ja pank tegi andestamatu vea, pannes endise metsamehe jahimehe olukorda. Jérôme Kerviel, kellel oli kauplejate jälgimisel peaaegu viis aastat kogemust, ei olnud sellest süsteemist mööda hiilida. Ta teadis teiste inimeste paroole, teadis, millal pangas tšekke tehti, oli sellega hästi kursis infotehnoloogia.

Põhjused

Kui Kerviel tegeles pettusega, siis mitte isikliku rikastumise eesmärgil. Nii räägivad tema advokaadid ja panga esindajad tunnistavad seda, nimetades Kervieli tegevust irratsionaalseks. Kerviel ise ütleb, et tegutses ainuüksi panga huvides ja tahtis vaid oma andeid kauplejana tõestada.

Efektid

2007. aasta tegevus tõi pangale umbes 2 miljardit eurot kasumit. Kerviel ise igatahes ütleb nii, põhjendades, et ilmselt panga juhtkond teadis, mida ta teeb, kuid eelistas nii kauaks silmi kinni pigistada, kuni ta kasumis oli.

Kervieli avatud riskantse positsiooni sulgemine tõi kaasa 4,9 miljardi euro suuruse kahjumi.

2008. aasta mais astus Daniel Bouton Societe Generale tegevjuhi kohalt tagasi ja teda asendas sellel ametikohal Frédéric Oudéa. Aasta hiljem oli ta sunnitud lahkuma panga direktorite nõukogu esimehe kohalt. Lahkumise põhjuseks oli ajakirjanduse terav kriitika: Butonit süüdistati selles, et tema kontrolli all oleva panga tippjuhid õhutasid pangatöötajate riskantseid finantstehinguid.

Vaatamata juhatuse toetusele suurenes surve hr Butonile. Tema tagasiastumist nõudsid nii panga aktsionärid kui ka paljud Prantsuse poliitikud. Ka Prantsusmaa president Nicolas Sarkozy kutsus Daniel Boutoni tagasi astuma pärast seda, kui sai teatavaks, et skandaalieelse pooleteise aasta jooksul andis Societe Generale'i arvuti sisekontrollisüsteem hoiatuse umbes 75 korral, s.o iga kord, kui Jerome Kerviel tegi volitamata toiminguid. võimalikud rikkumised.

Kohe pärast kahjude avastamist moodustas Societe Generale kaupleja tegude uurimiseks spetsiaalse komisjoni, kuhu kuulusid panga direktorite nõukogu sõltumatud liikmed ja PricewaterhouseCoopersi audiitorid. Komisjon jõudis järeldusele, et panga sisekontrollisüsteem ei olnud piisavalt tõhus. See tõi kaasa selle, et pank ei suutnud nii suurt pettust ära hoida. Aruandes märgitakse, et "panga töötajad ei kontrollinud süstemaatiliselt" kaupleja tegevust ja pangal endal puudub "kontrollisüsteem, mis suudaks pettusi ära hoida".

Kaupleja kontrolli tulemuste aruandes on kirjas, et uurimise tulemusena võeti vastu otsus "oluliselt tugevdada Societe Generale töötajate tegevuse sisemise järelevalve korda". Seda tehakse panga erinevate osakondade töö rangema korraldamise ja nende koostöö koordineerimise kaudu. Samuti võetakse meetmeid pangatöötajate kauplemistoimingute jälgimiseks ja isikupärastamiseks, "tugevdades IT-turvasüsteemi ja arendades isikutuvastuse (biomeetria) kõrgtehnoloogilisi lahendusi".

Raamatust Äriinfo turvalisus autor Andrianov V. V.

4.2.2. Juhtumite tüpoloogia Maailmapraktika üldistamine võimaldab eristada järgmisi organisatsiooni personali puudutavate infoturbeintsidentide liike: - ametliku teabe avalikustamine; - aruandluse võltsimine; - rahaliste ja materiaalsete varade vargused; - sabotaaž.

Raamatust Pension: arvutamise ja registreerimise kord autor Minaeva Lyubov Nikolaevna

4.3.8. Juhtumi uurimine Organisatsiooni töötajaga seotud intsident on enamiku organisatsioonide jaoks hädaolukord. Seetõttu sõltub uurimise korraldamise viis suuresti organisatsioonis valitsevast ettevõttekultuurist. Aga võid kindel olla

Raamatust Päevakauplemine Forexi turul. Kasumistrateegiad autor Lyn Ketty

2.5. Näited Kaaluge mõningaid tööpensioni määramise võimalusi pensionifondi territoriaalsetele asutustele dokumentide posti teel üleandmisel: Näide 1 Vanaduspensioni määramise avaldus saadeti fondi territoriaalsele asutusele

Raamatust Juhtimispraktika inimressursside abil autor Armstrong Michael

3.5. Näited Näide 1 Tööstaaž koosneb tööperioodidest 15.03.1966 kuni 23.05.1967; 15. septembrist 1970 kuni 21. maini 1987; alates 01.01.1989 kuni 31.12.1989; alates 09.04.1991 kuni 14.07.1996; alates 15.07.1996 kuni 12.07.1998 ja ajateenistus 27.05.1967 kuni 06.09.1969. Arvutame pensioniõiguste hindamiseks staaži

Autori raamatust

4.4. Näited Näide 1 1950. aastal sündinud insener Sergeev A.P. taotles vanaduspensioni 2010. aasta märtsis. 2010. aastal sai ta 60-aastaseks. Kogu pensioniõiguste hindamise staaž 1. jaanuari 2002 seisuga on 32 aastat 5 kuud 18 päeva, sealhulgas 30 aastat enne 1991. aastat.

Autori raamatust

6.3. Näited Näide 1 Töötas müügijuht Sokolov V.N tööleping 01.01.2010 kuni 01.01.2013 sureb 25-aastaselt. Samas on tal veel töövõimelised vanemad, töövõimeline naine ja tütar 3-aastaselt. Sel juhul õigus tööle saada

Autori raamatust

7.4. Näited Näide 1 Juht Vassiljev R.S., 60 aastat vana. Kogustaaži pensioniõiguste hindamise tööraamatu järgi seisuga 01.01.2002 on 40 aastat. Keskmine kuupalk aastatel 2000–2001 on isikustatud arvestuste järgi 4000 rubla. Arvutage ja võrrelge pensione

Autori raamatust

8.3. Näited Näide 1 Pensionär saab I grupi töövõimetuspensioni. 20. maist 5. juunini 2009 läbis ta BMSE-s järjekordse korduvekspertiisi ja tunnistati III grupi invaliidiks 3. juunil 2009. Antud juhul puudegrupp langes. Põhiosa alluvad pensionile

Autori raamatust

10.4. Näited Näide 1 Pensionäri surm saabus 28. jaanuaril 2009. Pensionäri lesk taotles pensioni 2009. aasta veebruaris. Lese kooselu pensionäriga surmapäeval ei tuvastatud.

Autori raamatust

14.7. Näited Näide 1 Koshkina VN, kes oli oma surnud abikaasa ülalpeetav, sai 3 kuud pärast tema surma 55-aastaseks. Ta taotles pensioni 1 aasta möödumisel abikaasa surma kuupäevast.Pensioniseaduste kohaselt määratakse pension alates päevast

Autori raamatust

17.5. Näited Näide 1 Neli inimest töötavad üksikettevõtja juures töölepingu alusel: Moroz KV (sünd. 1978), Svetlova T. G. (s. 1968), Leonova T. N. (s. 1956) ja Komarov S. N. (s. 1952). Oletame, et igakuiselt palk igaüks neist on 7000 rubla.

Autori raamatust

Näited Vaatleme mõnd näidet selle strateegia toimimisest.1. 15-minutiline EUR/USD diagramm joonisel fig. 8.8. Selle strateegia reeglite järgi näeme, et EUR/USD kukkus ja kauples alla 20 päeva libiseva keskmise. Hinnad jätkasid langust liikudes 1,2800 suunas, mis on

Autori raamatust

Näited Vaatame mõningaid näiteid.1. Joonisel fig. Joonis 8.22 näitab 15-minutilist USD/CAD graafikut. Kanali koguulatus on ligikaudu 30 punkti. Vastavalt meie strateegiale esitame sisenemistellimused 10 punkti kanali kohal ja all, st 1,2395 ja 1,2349. Ostutellimus täidetud

Autori raamatust

Näited Vaatame mõningaid selle strateegia näiteid tegevuses.1. Joonisel fig. Joonis 8.25 näitab EUR/USD päevagraafikut. 27. oktoobril 2004 moodustasid EUR/USD liikuvad keskmised järjepideva õige järjekorra. Avame positsiooni viis küünalt peale moodustamise algust 1.2820.

Tere kõigile petjatele,
väga sageli kõlab protsessiteenusena suurte ja väikeste IT-osakondade töötajatelt üks väga populaarne küsimus: mis vahe on teenusepäringul ja intsidendil?

Selleteemalised arutelud on sama vanad kui kõik IT-juhtimise metoodikad kokku, kuid pöördugem siiski algallikate poole.

Mida ITIL meile ütleb (sõnastiku kolmanda versiooni ametlik tõlge):

Teenuse taotluse- kasutaja teabe- või nõuandetaotlus või standardne muudatus, juurdepääs IT-teenusele.

Intsident- IT-teenuse planeerimata katkemine või IT-teenuse kvaliteedi langus.

Tavapäraselt ei lasku metoodika asjade sügavusse ja tõesti ei meeldi vastata sisulistele küsimustele ühegi Service Deski töötajatelt, kes kasutajate päringuid klassifitseerivad. Ja vahepeal on selliseid küsimusi palju, siin on mõned näited:

1) Kristofääriline kõne kasutajalt, kes palub parooli lähtestamist – kuidas tuleks seda liigitada teenusetaotluseks või intsidendiks? Või äkki infoturbeintsidendina?

2) Kõne kasutajalt, kelle ettevõtte post ei tööta. Apellatsiooni pealiskaudne analüüs viitab sellele, et kasutaja peab tegema meilikliendi esialgse konfiguratsiooni. Sellegipoolest on tema seisukohalt tegemist intsidendiga, sest. teenus pole saadaval ja keegi ei teavitanud teda, et "post ise ei lenda"

Ütlematagi selge, et esmane klassifikatsioon on väga oluline, kuna see määrab apellatsiooni kogu järgneva elutsükli, sh. ja tähtajad.

Minu arusaam sellest küsimusest taandub hindamise küsimusele teenuse katkestused lõppkasutaja jaoks ja seega:

Intsident on enamasti kasutajale eelnevalt kinnitatud režiimis pakutud IT-teenuse katkestus või osaline katkestus (teenus on saadaval 24/7 või 5/8).

Näide: ettevõtte pearaamatupidaja kaotas ootamatult juurdepääsu süsteemile finantsaruandlus. Ühest küljest on juurdepääsu andmine klassikaline teenusetaotlus, kuid sel juhul on tegemist teenuse selge katkestusega ja selle tulemusena äriprotsessi osalise halvenemisega.

Teenuse taotluse- see on taotlus kasutajalt, kes on huvitatud ühenduse loomisest lisateenus või olemasolevate teenuste funktsionaalsuse parandamine.

Näide: eriti uudishimulik kasutaja üritas avada sama finantsaruandluse süsteemi üht moodulit, kuid sai veateate. Tema tz. see on juhtum, kuna ta ei saavutanud soovitud eesmärki ega saanud otsitavat teavet, vaid vaatenurgast. ülalkirjeldatud on klassikaline teenusetaotlus juurdepääsu saamiseks, mis nõuab heakskiitu ja täidetakse standardprotseduuri järgi kokkulepitud ajal.

Samas ei tohiks unustada ka erijuhtumeid, mida üldiselt on raske klassifitseerida, ülalkirjeldatud seisukoht ei pretendeeri dogmaks, vaid püüab aidata vähendada valesti klassifitseeritud kõnede arvu ja parandada IT üldine reageerimisaeg ettevõtte vajadustele.