Ballafaqimi me incidentet e sigurisë së informacionit. Hetimi i ngjarjes pa vonesë. Analiza e regjistrit të OWA

Procesi i menaxhimit të incidentit

Fatkeqësisht, bota nuk është ideale. Kjo vlen njëlloj për shërbimet e IT. Gjatë ofrimit të shërbimeve të TI-së, mund të ndodhin dështime: shërbimi mund të bëhet i padisponueshëm, të funksionojë me gabime ose mund të merret akses i paautorizuar ndaj informacionit etj. ato. Mund të ndodhin devijime negative nga ofrimi normal i shërbimeve. Në ITIL, këto devijime quhen incidente.

Një incident është një ndërprerje ose ulje e paplanifikuar e cilësisë së një shërbimi IT. Dështimi i një artikulli konfigurimi që nuk ka ndikuar ende në shërbim është gjithashtu një incident, siç është dështimi i një disku në një grup pasqyrimi.

Në disa raste, një incident mund të kalojë pa u vënë re nga përdoruesit, ndërsa në të tjera mund të ketë një ndikim të rëndësishëm financiar, reputacion dhe ndikime të tjera negative në biznes. Nëse ndodh një incident, atëherë është e nevojshme të minimizohet ndikimi i tij negativ.

Si ta bëni këtë? Në një rast - për ta "rregulluar" atë sa më shpejt të jetë e mundur, në një tjetër - për të rivendosur funksionet më të rëndësishme në kohën më të shkurtër të mundshme, në të tretën - për të aplikuar një zgjidhje, etj.

Zgjidhja - zvogëlimi ose eliminimi i ndikimit të një incidenti ose problemi për të cilin momenti aktual Rezolucioni i plotë nuk ofrohet.

Si rregull, aktivitetet e departamenteve të TI-së në lidhje me zgjidhjen e incidenteve kanë një ndikim të rëndësishëm në perceptimin e përdoruesve për IT-në në tërësi. Për të menaxhuar në mënyrë efektive këto aktivitete, duhet të përcaktohet një kurs veprimi i duhur. Në përputhje me rekomandimet e ITIL, për këtë duhet të ndërtohet një proces i menaxhimit të incidentit.

Menaxhimi i Incidentit është një proces përgjegjës për menaxhimin e ciklit jetësor të të gjitha incidenteve. Menaxhimi i incidentit siguron që ndikimi në biznes të minimizohet dhe shërbimi të rikthehet në funksionimin normal në mënyrën më të shpejtë të mundshme.

Si pjesë e arritjes së qëllimit, objektivat e procesit të menaxhimit të incidentit janë:

• Siguroni përdorimin e metodave dhe procedurave standarde për reagim efektiv dhe të shpejtë, analizë, dokumentacion, menaxhim të vazhdueshëm dhe raportim gjatë zgjidhjes së incidentit.
• Rritja e transparencës dhe komunikimit gjatë zgjidhjes së incidenteve midis biznesit dhe IT.
• Përmirësimi i perceptimit të biznesit për IT përmes një qasjeje profesionale për zgjidhjen e incidenteve.
• Përafrimi i prioriteteve për zgjidhjen e incidenteve me prioritetet e biznesit.
• Mbështetja e kënaqësisë së përdoruesve me cilësinë e shërbimeve të IT.

Aktivitetet në kuadër të Procesit të Menaxhimit të Incidentit

Incidentet mund të ndodhin në çdo pjesë të infrastrukturës. Ato shpesh raportohen nga përdoruesit, por ato mund të zbulohen gjithashtu nga stafi i IT bazuar në informacionin nga sistemet e monitorimit.

Në shumicën e rasteve, incidentet regjistrohen nga Shërbimi i Shërbimit, ku edhe raportohen. Të gjitha incidentet duhet të regjistrohen menjëherë pas njoftimit për arsyet e mëposhtme:

• është e vështirë të regjistrohet me saktësi informacioni për një incident nëse kjo nuk bëhet menjëherë;
• Monitorimi i ecurisë së punës për zgjidhjen e një incidenti është i mundur vetëm nëse incidenti është i regjistruar;
• incidentet e regjistruara ndihmojnë në diagnostikimin e incidenteve të reja;
• Menaxhimi i problemeve mund të përdorë incidentet e regjistruara për të punuar drejt shkaqeve rrënjësore;
• është më e lehtë të përcaktohet shkalla e ndikimit nëse të gjitha mesazhet (thirrjet) regjistrohen;
• Pa regjistrimin e incidenteve, është e pamundur të monitorohet zbatimi i marrëveshjeve (SLA);
• Regjistrimi i menjëhershëm i incidentit parandalon situatat kur shumë njerëz po punojnë për të njëjtin incident ose askush nuk po bën asgjë për të zgjidhur incidentin.

Të gjitha informacionet përkatëse në lidhje me incidentin duhet të regjistrohen dhe të vihen në dispozicion të ekipeve mbështetëse.

Shembull i informacionit të incidentit:

Kur një incident regjistrohet fillimisht, ai duhet të kategorizohet.

Një kategori është një grup i emërtuar objektesh që kanë diçka të përbashkët. Kategoritë përdoren për të grupuar objekte të ngjashme së bashku. Për shembull, llojet e kostos përdoren për të grupuar kostot e të njëjtit lloj, kategoritë e incidenteve - incidentet e të njëjtit lloj, llojet KU - artikujt e konfigurimit të të njëjtit lloj.

Kategorizimi i saktë i incidenteve ndihmon për t'i ridrejtuar ato drejtpërdrejt në grupin e dëshiruar dhe analizon incidentet nga këndvështrime të ndryshme, dhe gjithashtu përbën bazën për gjetjen e shkaqeve të incidenteve dhe eliminimin e tyre si pjesë e procesit të menaxhimit të problemit.

Çdo incidenti i caktohet një prioritet specifik.

Prioriteti bazohet në ndikimin dhe urgjencën dhe përdoret për të përcaktuar kohën e kërkuar të përpunimit.

Urgjenca është një masë që tregon se sa shpejt, që nga momenti kur ndodh, një incident do të ketë një ndikim të rëndësishëm në biznes.

Shkalla e ndikimit (ndikimi) është një masë e ndikimit të një incidenti në një proces biznesi.

Pra, në fakt, përparësia është një numër i përcaktuar nga urgjenca (sa shpejt duhet të rregullohet) dhe ndikimi (sa dëm do të bëhet nëse nuk rregullohet shpejt). Prioriteti = Urgjenca x Ndikimi. Në bazë të prioritetit përcaktohet edhe radha në të cilën zgjidhen incidentet.

Prioriteti është vendosur duke marrë parasysh faktorët e mëposhtëm:

• Urgjenca
• Ndikimi në biznes
• Rrezik për jetën ose gjymtyrët
• Numri i shërbimeve të prekura
• Humbjet financiare
• Ndikimi në reputacionin e biznesit
• Ndikimi në respektimin e ligjeve dhe rregulloreve të tjera, etj.

Duke marrë parasysh prioritetin e vendosur dhe marrëveshjet ekzistuese (SLA), përdoruesi informohet për kohën maksimale të parashikuar për zgjidhjen e incidentit (afati). Edhe këto afate janë fikse. Incidentit i caktohet një numër unik dhe përdoruesi informohet për numrin e incidentit për identifikimin e saktë të tij gjatë thirrjeve të mëvonshme.

Direkt kur një përdorues kontakton specialistët e Shërbimit Desk, duhet të kryhet një diagnozë paraprake e incidentit për të marrë informacionin e nevojshëm për të përcaktuar shkakun e incidentit, nëse është e mundur, si dhe për kategorizimin e saktë dhe transferimin në linjën tjetër të mbështetjes. Nëse zgjidhja e incidentit është në kompetencën e punonjësit të Shërbimit, atëherë ai mund të zgjidhet menjëherë. Shërbimi i Shërbimit përcjell incidente që nuk kanë zgjidhje e gatshme ose jashtë kompetencës së punonjësit që punon me të, në ekipin mbështetës të nivelit tjetër me përvojë dhe njohuri të gjerë. Ky ekip heton dhe zgjidh incidentin ose e përshkallëzon atë në nivelin tjetër të ekipit mbështetës.

Gjatë procesit të zgjidhjes së incidentit, specialistë të ndryshëm mund të përditësojnë të dhënat e incidentit duke ndryshuar statusin aktual, informacionin për veprimet e ndërmarra, duke rishikuar klasifikimin dhe duke përditësuar kohën dhe kodin e punonjësit.

Në shumicën e rasteve, Shërbimi i Shërbimit, si “pronar” i të gjitha incidenteve, është përgjegjës për monitorimin e ecurisë së zgjidhjes. Ky shërbim duhet gjithashtu të informojë përdoruesin për statusin e incidentit. Reagimi i përdoruesit mund të jetë i përshtatshëm pas një ndryshimi në status, si përshkallëzimi i një incidenti në linjën tjetër mbështetëse, ndryshimi i kohës së vlerësuar të zgjidhjes, përshkallëzimi, etj. Gjatë monitorimit, përshkallëzimi funksional në grupe të tjera mbështetëse ose përshkallëzimi hierarkik për të marrë vendime ekzekutive është i mundur .

Përshkallëzimi - aktivitet që synon marrjen e burimeve shtesë kur është e nevojshme për të arritur treguesit e synuar niveli i shërbimit ose përmbushja e pritshmërive të klientëve. Përshkallëzimi mund të kërkohet brenda çdo procesi Menaxhimi i TI-së-shërbimet, por më së shpeshti shoqërohet me menaxhimin e incidenteve, menaxhimin e problemeve dhe menaxhimin e ankesave të klientëve. Ekzistojnë dy lloje të përshkallëzimit: përshkallëzimi funksional dhe përshkallëzimi hierarkik.

Pas përfundimit të suksesshëm të analizës dhe zgjidhjes së incidentit, punonjësi regjistron informacione për zgjidhjen e aplikuar.

Nëse, në një moment të caktuar kohor, zgjidhja e plotë e një incidenti nuk është e mundur, ndikimi i tij duhet, nëse është e mundur, të reduktohet duke aplikuar një zgjidhje. Në rastin më të keq, nëse nuk gjendet zgjidhje, incidenti mbetet i hapur.

Pasi një zgjidhje zbatohet për kënaqësinë e përdoruesit, ekipi mbështetës e përshkallëzon incidentin përsëri në Tavolinën e Shërbimit. Shërbimi i Shërbimit kontakton punonjësin që raportoi incidentin për të marrë konfirmimin se çështja është zgjidhur me sukses. Nëse ai e konfirmon këtë, atëherë incidenti mund të mbyllet; përndryshe, procesi rifillon në nivelin e duhur. Kur një incident mbyllet, duhet të përditësoni kategorinë përfundimtare, përparësinë, shërbimet e prekura nga incidenti dhe artikullin e konfigurimit që shkaktoi dështimin.

Politikat dhe parimet bazë të procesit të menaxhimit të incidentit

• Politikat e procesit të menaxhimit të incidentit duhet të ndiqen për të siguruar efektivitetin dhe efikasitetin e procesit, dhe mund të përfshijnë sa vijon:
• Koordinim i mirë midis përdoruesve dhe trajtuesve të incidenteve
• Incidentet duhet të zgjidhen brenda një afati kohor të rënë dakord me biznesin.
• Aktivitetet e menaxhimit të incidenteve duhet të përputhen me nivelet e shërbimit dhe objektivat mbështetëse bazuar në nevojat aktuale të biznesit
• Të gjitha incidentet menaxhohen dhe të dhënat e tyre ruhen në një sistem të unifikuar menaxhimi
• Të gjitha incidentet duhet të kenë një skemë standarde klasifikimi që korrespondon me proceset e biznesit të ndërmarrjes
• Të dhënat e incidentit duhet të rishikohen rregullisht për të siguruar hyrjen dhe klasifikimin e saktë.
• Të gjitha të dhënat e incidentit, kurdoherë që është e mundur, duhet të kenë një format të përbashkët dhe një grup fushash informacioni
• Duhet të ketë një grup të përbashkët kriteresh të dakorduara nga biznesi për prioritizimin dhe përshkallëzimin e incidenteve

Më poshtë përshkruhen parimet bazë që duhet të merren parasysh gjatë zbatimit të menaxhimit të incidentit.

Afatet kohore - Duhet të bien dakord për të gjitha fazat e përpunimit të incidentit (ato do të ndryshojnë në varësi të nivelit të prioritetit të incidentit). Të gjitha ekipet mbështetëse duhet të jenë plotësisht të vetëdijshme për këto afate kohore.

Shumë incidente nuk janë të reja - ato lidhen me diçka që tashmë ka ndodhur më parë dhe mund të ndodhë përsëri. Për këtë arsye, këshillohet që paraprakisht të përcaktohen modelet "standarde" të incidentit dhe të zbatohen ato kur ndodhin incidente të përshtatshme.

Një model incidenti është një mënyrë e paracaktuar për të trajtuar një lloj të caktuar incidenti.

Një model incidenti mund të përfshijë aspektet e mëposhtme:

• Një sekuencë e paracaktuar veprimesh për të trajtuar një lloj specifik incidenti
• Përgjegjësi e paracaktuar
• Masat para se të zgjidhni një incident
• Afatet kohore dhe procedurat e përshkallëzimit
• Dëshmia e aktivitetit (regjistrat, regjistrat)

Incidentet e rëndësishme janë identifikuar si pjesë e procesit të menaxhimit të incidentit.

Një incident i rëndësishëm shkakton humbje të konsiderueshme për biznesin dhe duhet të ketë procedura të veçanta trajtimi.

Incidentet duhet të gjurmohen gjatë gjithë ciklit të tyre jetësor për t'u siguruar që ato të përpunohen siç duhet dhe të raportohen për statusin e incidentit. Në një sistem të menaxhimit të incidenteve, kodet e statusit mund të shoqërohen me incidente për të treguar se ku janë ato në lidhje me ciklin e jetës. Shembuj të këtyre mund të përfshijnë:

Pozicioni i incidentit në procesin e përpunimit tregohet nga statusi. Shembuj të statuseve mund të jenë:

• e re;
• pranuar;
• planifikuar;
• emëruar;
• aktive;
• shtyhet;
• lejohet;
• mbyllur.

Treguesit e procesit të menaxhimit të incidentit

Të menaxhojë dhe vlerësojë efektivitetin e procesit të menaxhimit të incidentit dhe të sigurojë reagimet me proceset e tjera të menaxhimit, ITIL sugjeron përdorimin e treguesve kryesorë të mëposhtëm (CSF dhe KPI):

• CSF Zgjidhja e shpejtë e incidenteve, duke minimizuar ndikimin e tyre në biznes
• KPI Koha mesatare e shpenzuar për zgjidhjen e një incidenti
• KPI Shpërndarja e incidenteve sipas statusit
• KPI Përqindja e incidenteve të zgjidhura nga mbështetja e linjës së parë
• KPI Përqindja e incidenteve të zgjidhura nga distanca
• KPI Numri i incidenteve të zgjidhura që nuk ndikuan në biznes
• Mbështetje për cilësinë e shërbimit IT CSF
• KPI Numri total i incidenteve (pika referuese)
• Madhësia e radhës KPI e incidenteve të pazgjidhura për secilin shërbim
• Numri i KPI dhe përqindja e incidenteve të rëndësishme (të mëdha) për secilin shërbim
• Mbështetje për kënaqësinë e përdoruesit të CSF
• Rezultati mesatar i anketës KPI sipas përdoruesve/klientëve
• KPI Përqindja e kënaqësisë së të anketuarve në krahasim me numrin e përgjithshëm të të anketuarve pjesëmarrës në anketë
• CSF Përmirësimi i transparencës dhe komunikimit në zgjidhjen e incidenteve ndërmjet stafit mbështetës të biznesit dhe IT
• KPI Numri mesatar i thirrjeve mbështetëse ose kontakteve të tjera të përdoruesve në lidhje me incidentet që janë njoftuar tashmë
• KPI Numri i ankesave dhe problemeve në lidhje me përmbajtjen dhe cilësinë e komunikimeve gjatë zgjidhjes së incidenteve
• CSF Përafrimi i prioriteteve të menaxhimit të incidenteve me prioritetet e biznesit
• KPI Përqindja e incidenteve të zgjidhura pa shkelur qëllimet e SLA
• KPI Kostoja mesatare për incident
• CSF Sigurohuni që të përdoren metoda dhe procedura standarde për të zgjidhur incidentet
• Numri i KPI dhe përqindja e incidenteve të caktuara gabimisht
• Numri i KPI dhe përqindja e incidenteve të keqklasifikuara
• Numri i KPI dhe përqindja e incidenteve të trajtuara nga punonjësit e Shërbimit Desk
• Numri i KPI dhe përqindja e incidenteve që lidhen me ndryshimet dhe lëshimet

Rreziqet dhe vështirësitë

Gjatë zbatimit të menaxhimit të incidentit, duhet të merren parasysh sa vijon: rreziqet e mundshme dhe vështirësitë:

• Nevoja për zbulimin e hershëm të incidenteve - do të kërkohet konfigurimi i mjeteve të menaxhimit (monitorimit) të ngjarjeve, si dhe trajnimi i përdoruesve për të raportuar incidentet
• Nevoja për regjistrim total të incidenteve
• Nevoja për të futur adekuate sistem i automatizuar menaxhimin dhe sigurimin e integrimit të tij me sisteme të ndryshme të menaxhimit të IT (për shembull, CMS)
• Nevoja për disponueshmëri të lartë të një pike të vetme kontakti
• Nevoja për të siguruar respektimin e procesit dhe identifikimin e rasteve të anashkalimit të procedurave të procesit - nëse përdoruesit i zgjidhin vetë gabimet ose kontaktojnë drejtpërdrejt specialistët pa ndjekur procedurat e përcaktuara, organizata e IT nuk do të marrë informacion në lidhje me nivelin e shërbimit të ofruar në të vërtetë, numrin e gabimeve , dhe shumë më tepër. Raportet drejtuar menaxhmentit gjithashtu nuk do të pasqyrojnë në mënyrë adekuate situatën.
• Mungesa e burimeve gjatë zgjidhjes së incidenteve, mbingarkesa me incidente dhe shtyrja "për më vonë" - nëse ka një rritje të papritur të numrit të incidenteve, mund të mos ketë kohë të mjaftueshme për regjistrim të saktë, pasi para përfundimit të futjes së informacionit për incidentin nga një përdorues, bëhet e nevojshme të shërbehet tjetri. Në këtë rast, futja e përshkrimeve të incidenteve mund të mos jetë mjaft e saktë dhe procedurat për shpërndarjen e incidenteve tek organet mbështetëse nuk do të kryhen siç duhet. Si rezultat, vendimet janë të cilësisë së dobët dhe ngarkesa e punës rritet edhe më shumë. Në rastet kur numri i incidenteve të hapura fillon të rritet me shpejtësi, procedura për shpërndarjen emergjente të burimeve shtesë brenda organizatës mund të parandalojë mbingarkimin e stafit.
• Mungesa e katalogut të shërbimit dhe marrëveshjeve të nivelit të shërbimit (SLA) - Nëse shërbimet dhe produktet e mbështetura nuk janë të përcaktuara mirë, atëherë mund të jetë e vështirë për ata që janë të përfshirë në menaxhimin e incidentit të refuzojnë në mënyrë të arsyeshme ndihmën për përdoruesit.
• Mungesa e përkushtimit ndaj qasjes së procesit nga ana e menaxhmentit dhe stafit - Zgjidhja e incidenteve duke përdorur një qasje procesi zakonisht kërkon një ndryshim në kulturë dhe një nivel më të lartë të pronësisë së punës së tyre nga ana e stafit. Kjo mund të shkaktojë rezistencë të konsiderueshme brenda organizatës. Menaxhimi efektiv Menaxhimi i incidentit kërkon që punonjësit të kuptojnë dhe t'i përkushtohen vërtet një qasjeje procesi në vend që thjesht të marrin pjesë.

Vlera e biznesit

Duke zbatuar një proces të menaxhimit të incidentit në përputhje me udhëzimet ITIL dhe duke adresuar çdo sfidë që mund të lindë gjatë zbatimit, vlera e mëposhtme mund të arrihet për biznesin në tërësi:

• Mundësi për të reduktuar punën e paplanifikuar dhe kostot e biznesit dhe IT të shkaktuara nga incidentet
• Aftësia për të zbuluar dhe zgjidhur incidentet, duke reduktuar kohën e ndërprerjes dhe duke rritur disponueshmërinë e shërbimeve të biznesit
• Aftësia për të ndarë burimet e TI-së bazuar në prioritetin e biznesit
• Aftësia për të iniciuar përmirësime të shërbimit bazuar në njohuritë për natyrën e incidenteve
• Aftësia për të identifikuar nevojat për trajnim shtesë të stafit

Procesi i menaxhimit të incidentit ofron shikueshmëri të konsiderueshme për biznesin dhe lejon që rezultatet të shihen relativisht shpejt pasi të zbatohen. Prandaj, menaxhimi i incidenteve është shpesh një nga proceset e para të zbatuara gjatë kalimit në një organizatë të menaxhimit të TI-së të bazuar në proces. Një përfitim shtesë i kësaj është se menaxhimi i incidenteve mund të nxjerrë në pah fusha të tjera të menaxhimit të TI-së që kërkojnë vëmendje - duke siguruar kështu që burimet e nevojshme të shpërndahen në procese të tjera të menaxhimit të TI-së.

Me kalimin e kohës, mund të ketë nevojë për të ndryshuar infrastrukturën e IT. Kjo mund të shkaktohet nga një sërë arsyesh - nevoja për të rregulluar një problem, dëshira për të përmirësuar cilësinë e shërbimeve të IT, infrastruktura e vjetëruar ose ndryshimet në legjislacion.

Përvoja tregon se nëse ndryshimet nuk kontrollohen siç duhet, ato shpesh mund të rezultojnë në incidente: ndërprerje në ofrimin normal të shërbimeve. Arsyet për incidente të tilla mund të jenë të ndryshme: neglizhenca e punonjësve, mungesa e burimeve, trajnimi i pamjaftueshëm, analiza e dobët e ndikimit të ndryshimit, testimi i papërsosur, etj. Numri i incidenteve mund të rritet, secila prej tyre do të kërkojë veprime urgjente, të cilat nga ana tjetër mund të çojnë në incidente të reja. Planifikimi ditor shpesh nuk arrin të përballojë ngarkesat në rritje të punës.

Ndryshimi është shtimi, modifikimi ose heqja e diçkaje që mund të ketë ndikim në shërbimet e IT.

Ky kuadër duhet të përfshijë të gjitha ndryshimet në arkitekturat, proceset, mjetet, metrikat dhe dokumentacionin, si dhe ndryshimet në shërbimet e TI-së dhe elementë të tjerë të konfigurimit.

Një numër i proceseve të Tranzicionit të Shërbimit janë përgjegjës për ofrimin e kontrollit të ndryshimit në ITIL: Menaxhimi i Ndryshimit, Menaxhimi i Aseteve të Shërbimit dhe Konfigurimi, dhe Menaxhimi i lëshimit dhe vendosjes.

Menaxhimi i ndryshimit është procesi përgjegjës për menaxhimin e ciklit jetësor të të gjitha ndryshimeve, duke lehtësuar zbatimin e ndryshimeve të dobishme me ndërprerje minimale në shërbimet e IT.

• Si pjesë e arritjes së qëllimit, objektivat e procesit të menaxhimit të ndryshimit janë:
• Përgjigjuni kërkesave për ndryshim nga biznesi dhe IT për të siguruar që shërbimet plotësojnë nevojat e biznesit
• Sigurohuni që të gjitha ndryshimet të regjistrohen, vlerësohen, autorizohen, prioritizohen, planifikohen, testohen, zbatohen, dokumentohen dhe rishikohen në mënyrë të kontrolluar
• Sigurohuni që të gjitha ndryshimet në artikujt e konfigurimit të regjistrohen në sistemin e menaxhimit të konfigurimit (CMS)
• Optimizoni rreziqet e biznesit

Fusha e procesit të menaxhimit të ndryshimeve përfshin ndryshime në infrastrukturën e TI-së, proceset, mjetet, metrikat dhe dokumentacionin, si dhe ndryshimet në shërbimet e TI-së dhe elementë të tjerë të konfigurimit.

Aktivitetet në kuadër të Procesit të Menaxhimit të Ndryshimeve

Figura tregon skema e përgjithshme procesi i menaxhimit të ndryshimit. Për të siguruar kontrollin e ndryshimit, të gjitha ndryshimet duhet të regjistrohen. Nëse është e nevojshme duke bërë një ndryshim që është brenda objektit të një procesi, duhet të dorëzohet një kërkesë për ndryshim (RFC).

Një kërkesë për ndryshim është një propozim zyrtar për të bërë një ndryshim. Një kërkesë për ndryshim përfshin detaje të ndryshimit të propozuar dhe mund të shkruhet në letër ose formë elektronike. Termi "kërkesë ndryshimi" shpesh keqpërdoret për të nënkuptuar "ndryshim regjistrimi" ose "ndryshim" vetë.

Brenda procesit të menaxhimit të ndryshimeve ITIL, ekzistojnë tre lloje ndryshimesh:

Ndryshimi standard - një ndryshim i para-autorizuar, me rrezik të ulët, relativisht rutinë dhe duke ndjekur një procedurë ose udhëzimet e punës. Për shembull, rivendosja e një fjalëkalimi ose sigurimi i një punonjësi të ri me pajisje standarde. Ndryshimet standarde nuk kërkojnë një RFC për t'u zbatuar, por regjistrohen dhe gjurmohen duke përdorur një mekanizëm tjetër siç janë kërkesat e shërbimit.

Një ndryshim urgjent është një ndryshim që duhet të zbatohet sa më shpejt që të jetë e mundur, për shembull për të zgjidhur një incident të rëndësishëm ose për të instaluar një përditësim sigurie. Procesi i menaxhimit të ndryshimeve zakonisht ka një procedurë specifike për menaxhimin e ndryshimeve emergjente.

Një ndryshim normal është një ndryshim që nuk është urgjent ose rutinë. Ndryshimet normale përpunohen përmes hapave specifikë në procesin e menaxhimit të ndryshimeve.

Prandaj, nëse një ndryshim bie në kategorinë standarde, ai duhet të menaxhohet si pjesë e procesit të Menaxhimit të Kërkesave të Shërbimit. Është ndryshim i caktuar standard ose normal është vendosur për çdo organizatë në mënyrë të pavarur. Për ndryshimet emergjente, procedurat normale nuk përdoren pasi burimet e nevojshme vihen në dispozicion menjëherë.

Më poshtë është një shembull i informacionit që mund të përfshihet në kërkesat për ndryshim (RFC):

• numrin e identifikimit të kërkesës;
• Problemi/numri i njohur i gabimit (nëse ka) i lidhur me kërkesën;
• përshkrimi dhe përcaktimi i artikujve përkatës të konfigurimit;
• arsyen e ndryshimit, duke përfshirë arsyetimin dhe rezultatin e pritur të biznesit;
• aktuale dhe version i ri artikulli i konfigurimit të ndryshueshëm;
• emrin, adresën dhe numrin e telefonit të personit që bën kërkesën;
• data e paraqitjes;
• vlerësimi paraprak i burimeve dhe kohës së nevojshme;
• etj.

Kërkesa për ndryshim krijohet nga një iniciator, i cili mund të jetë një individ ose një grup njerëzish.

Nëse kërkohet një ndryshim i rëndësishëm, mund të kërkohet një propozim ndryshimi.

Propozimi për ndryshim - Një dokument që përmban një përshkrim të nivelit të lartë të një shërbimi të mundshëm ose ndryshimi të rëndësishëm, çështjen e lidhur me biznesin dhe planin e pritshëm të zbatimit. Propozimet për ndryshime zakonisht krijohen si pjesë e procesit të menaxhimit të portofolit të shërbimeve dhe i dorëzohen procesit të menaxhimit të ndryshimeve për autorizim. Procesi i menaxhimit të ndryshimit vlerëson ndikimin e mundshëm në shërbimet e tjera, burimet e përbashkëta dhe planin e përgjithshëm të ndryshimit.

Të gjitha kërkesat për ndryshime të marra duhet të regjistrohen dhe duhet të krijohet një regjistrim ndryshimi për çdo ndryshim. Regjistrimi i ndryshimit - një rekord që përmban informacion të detajuar rreth ndryshimit. Dokumentet e çdo ndryshimi regjistrojnë cikli jetësor

një ndryshim. Një regjistrim ndryshimi krijohet për çdo kërkesë ndryshimi të marrë, edhe nëse refuzohet më pas.

Pas regjistrimit të një kërkese për ndryshim (RFC), Change Management bën një kontroll fillestar për të parë nëse ndonjë kërkesë është e paqartë, e palogjikshme, jopraktike ose e panevojshme. Kërkesa të tilla refuzohen me arsyetimin e dhënë. Punonjësit që bën kërkesën duhet t'i jepet gjithmonë mundësia të mbrojë kërkesën e tij.

• Për të vlerësuar një ndryshim, ITIL sugjeron t'i përgjigjeni 7 pyetjeve (7 'R'):
• Kush është iniciatori? (NGRITUR) (Kush e ngriti ndryshimin?)
• Cila është arsyeja? (ARSYET) (Cila është ARSYEJA e ndryshimit?)
• Cilat janë rreziqet që lidhen me ndryshimin? (RREZIQET) (Cilat janë RREZIQET e përfshira në ndryshim?)
• Cilat burime kërkohen për të zbatuar ndryshimin? (BURIMET) (Cilat BURIME kërkohen për të dhënë ndryshimin?)
• Kush është përgjegjës për ndërtimin, testimin dhe zbatimin e ndryshimit? (Përgjegjës) (Kush është PËRGJEGJËS për ndërtimin, testimin dhe zbatimin e ndryshimit?)
• Cila është marrëdhënia midis kësaj dhe ndryshimeve të tjera? (MARRËDHËNIE) (Cila është marrëdhënia midis këtij ndryshimi dhe ndryshimeve të tjera?)

Nëse një Kërkesë për Ndryshimi (RFC) pranohet, regjistrimi i ndryshimit përfshin informacionin e nevojshëm për të përpunuar më tej ndryshimin.

Informacioni i mëposhtëm mund t'i shtohet rekordit më vonë:

• prioritet i caktuar;
• vlerësimi i ndikimit dhe kostove të përfshira;
• kategoria;
• rekomandimet nga menaxheri i procesit të menaxhimit të ndryshimeve;
• data dhe ora e autorizimit të ndryshimit;
• data e planifikuar;
• plani i kthimit;
• kërkesat për mbështetje;
• plani për zbatimin e ndryshimit;
• informacion rreth zhvilluesit dhe punonjësve përgjegjës për zbatimin e ndryshimit;
• data dhe ora aktuale e ndryshimit;
• data e vlerësimit të rezultateve;
• rezultatet e testit dhe problemet e gjetura;
• arsyet për refuzimin e kërkesës (nëse është e nevojshme);
• vlerësimin e rezultateve.

Pasi të merret një kërkesë për ndryshim (RFC), përcaktohet prioriteti dhe kategoria e saj. Përparësia tregon se sa e rëndësishme është një kërkesë e dhënë në krahasim me të tjerat. Kjo, nga ana tjetër, përcaktohet nga urgjenca dhe shkalla e ndikimit të saj.

Shembull i një sistemi kodimi prioritar:

• Prioritet i ulët - ndryshimi është i dëshirueshëm, por zbatimi i tij mund të shtyhet deri në një kohë më të përshtatshme (për shembull, deri në lëshimin e ardhshëm ose mirëmbajtjen e planifikuar).
• Prioriteti i zakonshëm është urgjenca e ulët dhe ndikimi i lartë, por ndryshimi nuk duhet të vonohet.
• Prioritet i lartë—Ndryshimi ka të bëjë me një defekt të madh që prek një numër përdoruesish, një defekt të ri atipik që prek një grup të madh përdoruesish ose çështje të tjera urgjente.
• Kërkesa me prioritet më të lartë për ndryshim (RFC) trajton një çështje që ka një ndikim të rëndësishëm në një shërbim kritik ndaj klientit. Ndryshimet me këtë prioritet klasifikohen si “emergjente”.

• Ndikim i ulët - Një ndryshim që kërkon pak punë.
• Ndikimi i rëndësishëm - Një ndryshim që kërkon përpjekje të konsiderueshme dhe ka një ndikim të rëndësishëm në shërbimet e IT. Këto ndryshime diskutohen në një bord ndryshimi (CAB) për të përcaktuar përpjekjen e kërkuar (burimet, etj.) dhe ndikimin e mundshëm.
• Ndikimi më i lartë është ndryshimi që kërkon përpjekje të konsiderueshme. Menaxheri i procesit duhet së pari të marrë autorizimin për të zbatuar ndryshimin nga menaxhimi i IT ose komiteti drejtues i IT, pas së cilës ndryshimi i dorëzohet bordit të ndryshimit (CAB).

Bordi i Ndryshimeve është një grup njerëzish që ndihmojnë në vlerësimin, prioritizimin, autorizimin dhe planifikimin e ndryshimeve. Bordi i ndryshimit zakonisht përfshin përfaqësues nga ofruesi i shërbimit të TI-së, biznesi dhe palë të treta (siç janë kontraktorët).

Këto kode mund të përfaqësohen në numra, për shembull: shkalla e ulët = 1 / shkalla më e lartë = 3

Shumica e ndryshimeve bien në dy kategoritë e para. Bazuar në vlerësimin e ndikimit të ndryshimit, duhet të përcaktohet niveli i autorizimit të ndryshimit (autoriteti i ndryshimit), për shembull, siç tregohet në figurë.

Përveç klasifikimit, duhet të identifikohen edhe grupet e përfshira në zgjidhjen teknike dhe shërbimet e prekura nga ndryshimi.

Nëse një ndryshim miratohet nga autoritetet përkatëse, ndryshimet e miratuara u komunikohen teknikëve përkatës të cilët do të zhvillojnë dhe zbatojnë ndryshimet.

Procesi i menaxhimit të ndryshimit koordinon zbatimin. Zhvillimi, testimi dhe zbatimi i drejtpërdrejtë kryhen në kuadër të procesit të menaxhimit të realizmit dhe vendosjes. Zbatimi i ndryshimit ndodh pasi rezultatet e testit të jenë miratuar si pjesë e procesit të menaxhimit të ndryshimit.

Si pjesë e procesit të menaxhimit të ndryshimit, mbahet një orar ndryshimesh. Orari i ndryshimit - një dokument me një listë të të gjitha ndryshimeve të miratuara dhe datat e planifikuara për zbatimin e tyre, si dhe datat e përafërta

zbatimin e ndryshimeve të mëvonshme. Anëtarët e bordit të ndryshimit (CAB) japin këshilla për ndryshimet e planifikimit, pasi është e nevojshme të merret parasysh disponueshmëria e personelit, burimeve, kostove, shërbimet e përfshira, si dhe mendimet e klientëve. Bordi i Ndryshimeve (CAB) shërben si një organ këshillues dhe takohet në baza të rregullta. Informacioni rreth planifikimit të ndryshimeve duhet të shpërndahet përpara mbledhjes së bordit të ndryshimit. Dokumentacioni dhe informacioni përkatës në lidhje me pikat e rendit të ditës duhet të shpërndahen gjithashtu përpara takimit.

Rendi i ditës për një mbledhje të bordit të ndryshimit duhet të përfshijë një numër pikash të përhershme, duke përfshirë:

• Ndryshime të pasuksesshme ose të paautorizuara
• Kërkesat për ndryshime (RFCs) të dorëzuara për ndryshimin e anëtarëve të bordit sipas prioritetit
• Kërkesat për ndryshime (RFC) të shqyrtuara nga bordi i ndryshimit
• Planifikimi i ndryshimit dhe përditësimi i orarit të ndryshimeve
• Vlerësimet e ndryshimeve të bëra
• Procesi i menaxhimit të ndryshimeve, shtesat dhe ndryshimet në proces
• Arritjet e procesit dhe përfitimet e biznesit të arritura përmes procesit të menaxhimit të ndryshimit
• Ndryshime të papërfunduara dhe ndryshime në progres
• Programoni kërkesat për ndryshim për shqyrtim në bordin e ardhshëm të ndryshimit
• Kontrolloni për ndryshime të paautorizuara të zbuluara nga aseti i shërbimit dhe procesi i menaxhimit të konfigurimit

Si pjesë e dizajnit të përgjithshëm të ndryshimit, duhet të zhvillohet një procedurë rikthimi në rast se ndryshimi nuk arrin rezultatin e dëshiruar. Menaxhimi i ndryshimit nuk duhet të miratojë një ndryshim pa një procedurë kthimi.

Është e nevojshme të vlerësohen ndryshimet e bëra, me përjashtim të mundshëm të ndryshimeve standarde. Nëse është e nevojshme, Bordi i Ndryshimeve (CAB) vendos për masat e mëvonshme shtesë.

• Duhet të merren parasysh çështjet e mëposhtme:
• A i arriti ndryshimi qëllimet e tij?
• A janë përdoruesit dhe klientët të kënaqur?
• Ndonjë efekt anësor?
• A u përdorën burimet për të zbatuar ndryshimin siç ishte planifikuar?
• A u zbatua ndryshimi në kohë dhe pa tejkalime të kostove?
• A funksionoi siç duhet plani i zbatimit?
• A funksionoi siç duhet plani i rimëkëmbjes kur ishte e nevojshme?

Nëse ndryshimi është i suksesshëm, kërkesa për ndryshim (RFC) mund të mbyllet. Kjo ndodh gjatë fazës së vlerësimit të rezultateve të zbatimit (PIR). Nëse ndryshimi dështon, procesi rifillon nga vendi ku dështoi duke përdorur qasjen e re. Ndonjëherë është më mirë të ktheheni dhe të krijoni një kërkesë të re ose të modifikuar për ndryshim (RFC). Vazhdimi me një ndryshim të dështuar shpesh e përkeqëson situatën.

Rishikimi i Rezultateve të Implementimit (PIR) - Një rishikim i kryer pasi një ndryshim ose projekt është zbatuar.

Vlerësimi i rezultateve të zbatimit përcakton suksesin e ndryshimit ose projektit dhe identifikon mundësitë për përmirësim.

Në varësi të natyrës së ndryshimit, vlerësimi mund të kryhet ose pas disa ditësh ose pas disa muajsh.

Për shembull, vlerësimi i një ndryshimi në një kompjuter personal që përdoret çdo ditë mund të zgjasë disa ditë, por një ndryshim në një sistem të përdorur një herë në javë mund të zgjasë tre muaj.

Kryerja e ndryshimeve emergjente

Pavarësisht se sa mirë është bërë planifikimi, mund të ketë ndryshime që kërkojnë prioritetin më të lartë. Ndryshimet emergjente janë shumë të rëndësishme për kompaninë dhe ato duhet të zbatohen sa më shpejt që të jetë e mundur. Ato kërkojnë procedura të veçanta për përpunimin urgjent, por ruajnë kontrollin e përgjithshëm nga procesi i menaxhimit të ndryshimeve. Nëse lind kjo situatë, mund të organizohet një takim i bordit të ndryshimit emergjent (eCAB).

Bordi i Ndryshimeve Emergjente (eCAB) - një grup njerëzish brenda Bordit të Ndryshimeve që marrin vendime për ndryshimet emergjente. Vendimi për përbërjen e pjesëmarrësve të këshillit për ndryshime emergjente mund të merret drejtpërdrejt gjatë organizimit të mbledhjes. Nevoja për pjesëmarrje përcaktohet në bazë të natyrës së ndryshimit urgjent.

Nëse nuk ka kohë për ta bërë këtë, ose nëse kërkesa merret jashtë orarit të punës, duhet të ekzistojë një metodë alternative për marrjen e autorizimit për ndryshim. Ky nuk duhet të jetë një takim ballë për ballë, por mund të mbahet një telefonatë konferencë.

• Politikat dhe parimet bazë të procesit të menaxhimit të ndryshimit
• Politikat e procesit të menaxhimit të ndryshimit duhet të ndiqen për të siguruar efektivitetin dhe efikasitetin e procesit dhe mund të përfshijnë sa vijon:
• Kategorizimi i ndryshimeve, p.sh. ndryshime inovative, eksploruese, parandaluese, korrigjuese
• Përcaktimi i përgjegjësisë për ndryshimet në të gjitha fazat e ciklit jetësor të shërbimit
• Ndarja e përgjegjësive të menaxhimit
• Krijoni një pikë të vetme përgjegjësie për ndryshimet për të zvogëluar gjasat e ndryshimeve konfliktuale dhe rrezikun e përçarjes në mjedisin e prodhimit

Treguesit e procesit të menaxhimit të ndryshimeve

Për të menaxhuar dhe vlerësuar efektivitetin e procesit të menaxhimit të ndryshimit, si dhe për të dhënë reagime ndaj proceseve të tjera të menaxhimit, ITIL sugjeron përdorimin e treguesve kryesorë të mëposhtëm:

• Përqindja e ndryshimeve që plotësuan kërkesat e klientëve
• Përfitimi i një ndryshimi i shprehur si "vlera e përmirësimeve të bëra" + "ndikimi negativ i shmangur" krahasuar me koston e zbatimit të ndryshimit
• Zvogëloni ndërprerjet e shërbimit, defektet dhe ripunimet e shkaktuara nga specifikimet e pasakta ose vlerësimi i pamjaftueshëm i ndikimit
• Reduktimi i numrit të ndryshimeve të paautorizuara
• Reduktimi i numrit të kërkesave për ndryshim, përqindja e ndryshimeve të paplanifikuara dhe rregullimet urgjente
• Reduktimi i numrit të ndryshimeve që kërkojnë rikuperim
• Reduktimi i numrit të ndryshimeve të pasuksesshme
• Koha mesatare e ekzekutimit sipas urgjencës/prioritetit/llojit
• Numri i incidenteve të ndryshimit
• Saktësia e vlerësimit të ndryshimit

Vlera e biznesit

Duke zbatuar një proces të menaxhimit të ndryshimit në përputhje me udhëzimet ITIL dhe duke adresuar çdo sfidë që mund të lindë gjatë zbatimit, vlera e mëposhtme mund të arrihet për biznesin në tërësi:

• Jepini përparësi dhe përgjigjeni kërkesave për ndryshim nga biznesi dhe klientët
• Zbatimi i ndryshimeve që plotësojnë kërkesat e dakorduara të shërbimit në një mënyrë me kosto efektive
• Reduktimi i numrit të ndryshimeve të pasuksesshme që çojnë në ndërprerje të shërbimit, defekte dhe ripunim
• Kryerja e ndryshimeve sipas afateve kohore të përcaktuara nga biznesi
• Ndiqni ndryshimet brenda ciklit jetësor të shërbimit dhe aseteve të klientëve tuaj
• Vlerësim më i mirë i cilësisë, kohës dhe kostos së ndryshimit
• Vlerësimi i rreziqeve që lidhen me ndryshimet e shërbimit (vënie në përdorim ose çaktivizim)
• Rritja e produktivitetit të stafit duke minimizuar numrin e ndryshimeve të paplanifikuara ose "urgjente" dhe, si rezultat, duke rritur disponueshmërinë e shërbimeve
• Reduktimi i kohës mesatare deri në rikuperim duke zbatuar ndryshime korrigjuese më shpejt dhe me sukses
• Lidhuni me procesin e ndryshimit të biznesit për të identifikuar mundësitë e përmirësimit të biznesit

Dëshironi që shërbimet që ju ofrohen të jenë të një cilësie të lartë? Unë mendoj se po. Një nga objektivat kryesore të ITSM, dhe gjithashtu ITIL, është të ofrojë shërbime IT me cilësi të lartë.

Kontrolli Shërbimet e IT ami (Menaxhimi i shërbimit IT, ITSM) - zbatimi dhe menaxhimi i shërbimeve IT me cilësi të lartë që plotësojnë nevojat e biznesit.

Ofruesit dhe klientët e shërbimeve të TI-së nuk bien gjithmonë dakord për cilësinë e shërbimeve.

Cilësia është aftësia e një produkti, shërbimi ose procesi për të ofruar vlerën e pritur nga klienti.

Për shembull, një komponent mund të konsiderohet të jetë i cilësisë së lartë nëse funksionon siç pritet dhe arrin besueshmërinë e kërkuar.

Sa më sipër është përkufizimi ITIL i cilësisë. ato. Nëse duam të ofrojmë shërbime cilësore, është e nevojshme që ato të përmbushin pritshmëritë e klientit.

Siç thotë thënia e famshme: "Ju nuk mund të menaxhoni atë që nuk mund të matni". Kështu, për të siguruar ofrimin e shërbimeve cilësore, fillimisht është e nevojshme të qartësohen pritshmëritë e klientit në lidhje me shërbimet e TI-së, të bien dakord për to, mundësisht të kufizohen në një farë mënyre, për shembull, nëse kërkesa e klientit është jorealiste, dhe t'i prezantohen ato në formë e matshme. Hapi tjetër është të sigurohet që parametrat aktualë të shërbimit të përmbushin pritshmëritë e klientit dhe ta konfirmojnë këtë duke ofruar raportimin e duhur.

Sipas ITIL, procesi i menaxhimit të nivelit të shërbimit është përgjegjësia për të rënë dakord dhe dokumentuar objektivat dhe përgjegjësitë e nivelit të shërbimit në marrëveshjen e nivelit të shërbimit (SLA) dhe kërkesat e nivelit të shërbimit (SLR) për secilin shërbim dhe aktivitetet e tij të lidhura me TI-në për çdo shërbim IT organizatë ofruese.

Marrëveshja e nivelit të shërbimit (SLA) është një marrëveshje midis një ofruesi të shërbimit IT dhe një klienti. Marrëveshja e nivelit të shërbimit përshkruan shërbimin e TI-së, dokumenton objektivat e nivelit të shërbimit dhe tregon fushat e përgjegjësisë së palëve - ofruesit të shërbimit të TI-së dhe klientit. Një SLA e vetme mund të mbulojë shumë shërbime IT ose klientë të shumtë.

Kërkesa e nivelit të shërbimit (SLR) është një kërkesë e klientit për një shërbim IT.

Kërkesat e nivelit të shërbimit bazohen në objektivat e biznesit dhe përdoren për të negociuar dhe rënë dakord mbi objektivat e nivelit të shërbimit.

Nëpërmjet formimit të objektivave të nivelit të shërbimit, menaxhimi i nivelit të shërbimit vendos kërkesat dhe parametrat e funksionimit për një sërë procesesh të tjera operacionale dhe taktike ITIL, të tilla si: menaxhimi i incidentit, menaxhimi i kërkesave të shërbimit, menaxhimi i problemeve, menaxhimi i ndryshimeve, menaxhimi i lëshimit, menaxhimi i disponueshmërisë, etj.

Objektivi i nivelit të shërbimit - detyrimet e përcaktuara në marrëveshjen e nivelit të shërbimit. Objektivat e nivelit të shërbimit bazohen në kërkesat e nivelit të shërbimit dhe nevojiten për të siguruar që shërbimi i IT përmbush objektivat e biznesit. Objektivat e nivelit të shërbimit duhet të jenë SMART dhe zakonisht bazohen në treguesit kryesorë të performancës.

Nëse këto objektiva të nivelit të shërbimit janë në përputhje dhe pasqyrojnë me saktësi kërkesat e biznesit, atëherë shërbimi i ofruar nga ofruesit e shërbimeve do të përputhet me kërkesat e biznesit dhe do të përmbushë pritshmëritë e cilësisë së shërbimit të klientëve dhe përdoruesve. Nëse qëllimet nuk përputhen me nevojat e biznesit, atëherë performanca dhe nivelet e shërbimit të ofruesve të shërbimeve nuk do të përmbushin pritshmëritë e biznesit dhe mund të shfaqen probleme. Marrëveshja e nivelit të shërbimit - Niveli i garancisë ose garancisë në lidhje me nivelin e cilësisë së shërbimit të ofruar nga ofruesi i shërbimit për çdo shërbim të ofruar nga biznesi.

• Menaxhimi i nivelit të shërbimit është procesi që lidh ofruesin e shërbimit të IT dhe klientin. Ky proces ka detyrat e mëposhtme:
• Përcaktoni, dokumentoni, bini dakord, monitoroni, raportoni dhe vlerësoni nivelin e shërbimeve të ofruara të IT
• Mbani dhe përmirësoni marrëdhëniet dhe komunikimet me bizneset dhe klientët
• Sigurohuni që të ketë qëllime të qarta dhe të matshme për të gjitha shërbimet e IT
• Sigurohuni që pritshmëritë e nivelit të IT dhe shërbimit ndaj klientit të jenë të qarta dhe të paqarta
• Sigurohuni që përmirësimet proaktive të nivelit të shërbimit të zbatohen aty ku është e mundur dhe racionale.

Menaxhimi i nivelit të shërbimit duhet të sigurojë komunikim dhe komunikim të vazhdueshëm ndërmjet menaxherëve të organizatave të klientëve dhe bizneseve. Kjo duhet të ofrojë njohuri për biznesin në lidhje me ofruesin e shërbimit dhe për ofruesin e shërbimit të TI-së për biznesin.

Objekti i procesit të menaxhimit të nivelit të shërbimit duhet të përfshijë:

• Organizimi i marrëdhënieve me biznesin
• Diskutim dhe marrëveshje kërkesat aktuale dhe qëllimet, dokumentacionin dhe mirëmbajtjen e SLA për shërbimet e ofruara
• Diskutimi dhe pajtimi i kërkesave dhe qëllimeve, dokumentimi dhe mirëmbajtja e SLR për shërbimet e planifikuara të reja dhe të ndryshuara.
• Formimi dhe mirëmbajtja e marrëveshjeve të nivelit operacional (OLA) për të mbështetur qëllimet e SLA.
• Vlerësimi dhe përafrimi i të gjitha kontratave të jashtme (UC) me objektivat SLA - në lidhje me menaxhimin e furnizuesit.
• Parandalimi i dështimeve, ulja e rreziqeve dhe zbatimi i përmirësimeve të shërbimit funksionojnë së bashku me proceset e tjera.
• Siguroni raportim dhe vlerësim për të gjitha shërbimet dhe analizoni çdo devijim nga objektivat SLA.
• Iniconi dhe koordinoni Planin e Përmirësimit të Shërbimit (SIP).

Marrëveshja e nivelit operacional (OLA) është një marrëveshje midis një ofruesi të shërbimit të TI-së dhe një pjese tjetër të së njëjtës organizatë.

Një kontratë e jashtme (UC) është një marrëveshje midis një ofruesi të shërbimit IT dhe një pale të tretë.

Pala e tretë ofron mallra ose shërbime që mbështesin ofrimin e shërbimeve të TI-së për klientin.

Kontrata e jashtme përcakton qëllimin dhe përgjegjësitë e kërkuara për të arritur objektivat e dakorduara të nivelit të shërbimit në një ose më shumë marrëveshje të nivelit të shërbimit.

Plani i përmirësimit të shërbimit (SIP) është një plan formal për zbatimin e përmirësimeve në një proces ose shërbim IT.

Aktivitetet në kuadër të procesit të Menaxhimit të Nivelit të Shërbimit Figura tregon një diagram të përgjithshëm të procesit të menaxhimit të nivelit të shërbimit. Ndërsa bizneset bëhen gjithnjë e më të varura nga shërbimet e TI-së, kërkesa për shërbime të TI-së me cilësi të lartë rritet. Siç u përcaktua më sipër, cilësia e një shërbimi përcaktohet nga pritshmëritë e klientit, si dhe nga menaxhimi i vazhdueshëm i këtyre pritjeve, stabiliteti i shërbimit dhe pranueshmëria e nivelit të kostos. Prandaj më së shumti

Kërkesat e klientëve duhet të shprehen në terma të matshëm në mënyrë që ato të mund të përdoren në zhvillimin dhe monitorimin e shërbimeve të IT. Nëse matjet nuk bien dakord me klientin, atëherë do të jetë e pamundur të kontrollohet se sa mirë korrespondojnë shërbimet me marrëveshjet e arritura.

Hapi i parë për të hyrë në një marrëveshje për shërbimet aktuale ose të ardhshme të TI-së është identifikimi dhe përcaktimi i nevojave të klientit në formën e Kërkesave të Nivelit të Shërbimit (SLR). Krahas kryerjes së këtij lloj aktiviteti që në fillim të procesit, rekomandohet që kjo të bëhet rregullisht me kërkesë të klientit ose me iniciativën e vetë organizatës së IT-së dhe të mbulojë si shërbimet e reja ashtu edhe ato ekzistuese.

Fillimisht përcaktimi se çfarë duhet të përfshihet në kërkesat e nivelit të shërbimit dhe marrëveshjet e nivelit të shërbimit është një detyrë shumë e vështirë. Duhet të merren parasysh aftësitë dhe kufizimet e të gjitha proceseve në lidhje me matshmërinë dhe arritshmërinë e qëllimeve specifike të shërbimit.

Nëse ka ndonjë dyshim për realizueshmërinë e objektivave të shërbimit të kërkuar nga biznesi, atëherë objektivat përkatës mund të përfshihen në marrëveshjen pilot për monitorim dhe vlerësim gjatë periudhës së garancisë së kontrollit. Kjo do të ndihmojë për të marrë statistikat e nevojshme dhe për të bërë korrigjimet e nevojshme.

Ndërsa shumë organizata përpiqen të dokumentojnë kryesisht shërbimet që ofrojnë duke vendosur marrëveshje të përshtatshme të nivelit të shërbimit, dakordimi për kërkesat e nivelit të shërbimit për shërbimet e reja që zhvillohen ose blihen është gjithashtu një detyrë shumë e rëndësishme.

Kërkesat e nivelit të shërbimit duhet të jenë pjesë përbërëse e kritereve të projektimit të shërbimit, i cili përfshin gjithashtu specifikimet funksionale. Ata duhet të përcaktojnë kriteret e testimit dhe të ekzekutimit për fazat e ndryshme të projektimit dhe zhvillimit ose prokurimit që nga fazat më të hershme të projektimit. Kërkesat e nivelit të shërbimit do të rafinohen në mënyrë progresive në çdo fazë të ciklit jetësor, duke u bërë një marrëveshje pilot e nivelit të shërbimit gjatë fazës fillestare të mbështetjes. Një projekt-marrëveshje për nivelin e shërbimit duhet të nënshkruhet dhe zyrtarizohet përpara se shërbimi të vihet në funksionim dhe përdorim.

Përvoja tregon se shpesh vetë klientët nuk mund të përcaktojnë qartë pritshmëritë e tyre, ata thjesht supozojnë se shërbime të caktuara do t'u ofrohen atyre pa ndonjë marrëveshje specifike. Klienti mund të ketë nevojë për ndihmë për të kuptuar dhe artikuluar kërkesat, veçanërisht në lidhje me kapacitetin, sigurinë, disponueshmërinë dhe vazhdimësinë. Jini të përgatitur për faktin se kërkesat fillestare nuk do të bien dakord dhe miratohen menjëherë. Mund të duhen disa përsëritje të diskutimit të kërkesave përpara se të arrihet një ekuilibër i pranueshëm midis dëshirave dhe aftësive. Këto përsëritje mund të kërkojnë ridizajnim të zgjidhjes së shërbimit.

Ju lutemi vini re se mund të kërkohen burime shtesë për të mbështetur shërbimet e reja. Shpesh ekziston një pritshmëri që stafi tashmë i stërngarkuar do të përballojë në mënyrë magjike ngarkesën shtesë të punës që sjell shërbimet e reja.

Duke përdorur projekt-marrëveshjen si bazë, ju mund të negocioni me klientët ose përfaqësuesit e tyre për të finalizuar fushën e marrëveshjeve të nivelit të shërbimit dhe qëllimet fillestare të nivelit të shërbimit, dhe me furnitorët për të siguruar besimin se këto qëllime mund të arrihen.

Menaxhimi i nivelit të shërbimit duhet të hartojë një strukturë të përshtatshme të marrëveshjeve të nivelit të shërbimit për të siguruar që të gjitha shërbimet dhe të gjithë klientët të mbulohen në masën e duhur në lidhje me nevojat e organizatës. Ekzistojnë një numër opsionesh të mundshme të strukturës, duke përfshirë sa vijon:

• marrëveshjet e nivelit të shërbimit të bazuara në një shërbim të vetëm;
• marrëveshje të nivelit të shërbimit të bazuar në klient;
• marrëveshje të nivelit të shërbimit me shumë nivele.

SLA-të e bazuara në një shërbim të vetëm janë kur një marrëveshje e nivelit të shërbimit prek një shërbim për të gjithë klientët e atij shërbimi. Për shembull, një marrëveshje e nivelit të shërbimit mund të lidhet për një shërbim emaili që prek të gjithë klientët e atij shërbimi. Megjithatë, mund të lindin vështirësi nëse ka ndryshime në kërkesat e klientëve të ndryshëm të të njëjtit shërbim, ose nëse karakteristikat e infrastrukturës nënkuptojnë se nivele të ndryshme shërbimesh janë të pashmangshme.

Për shembull: stafi i zyrës qendrore mund të komunikojë duke përdorur një rrjet të shpejtë lokal, ndërsa zyrat lokale duhet të përdoret nga linja e ngadaltë WAN. Në raste të tilla, objektiva të veçanta mund të jepen në një marrëveshje të vetme. Megjithatë, për sa kohë që ofrohet një nivel i përbashkët shërbimi në të gjitha fushat e biznesit, si p.sh. për një shërbim emaili, SLA-të e bazuara në një shërbim të vetëm mund të shërbejnë si shembull qasje efektive. Mund të ketë nivele të shumta shërbimi brenda një marrëveshjeje të vetme, si ari, argjendi ose bronzi.

Marrëveshjet e nivelit të shërbimit të bazuar në klient - një marrëveshje me një grup individual klientësh që mbulon të gjitha shërbimet që ata përdorin. Për shembull, marrëveshjet mund të arrihen duke mbuluar departamentin e financave të sistemeve financiare të organizatës, sistemet e kontabilitetit, sistemet e faturimit, sistemet e faturimit, sistemet e blerjeve dhe çdo sistem tjetër IT që ata përdorin. Konsumatorët shpesh preferojnë marrëveshje të tilla, pasi të gjitha kërkesat e tyre mbulohen në një dokument. Si rregull, mjafton një nënshkrim nga klienti, gjë që thjeshton miratimin.

Një kombinim i çdo opsioni të strukturës është i mundur me kusht që të mos ketë dyfishim.

Disa organizata përdorin një strukturë marrëveshjesh të nivelit të shërbimit. Mund të përfshijë, për shembull, tre nivele:

• niveli i korporatës mbulon gjithçka pyetje të përgjithshme menaxhimi i nivelit të shërbimit, i zbatueshëm për të gjithë klientët në organizatë, si rregull, këto seksione nuk kërkojnë rishikim të shpeshtë;
• niveli i klientit përshkruan veçoritë e ofrimit të shërbimeve ndaj klientëve të veçantë ose grupeve të njësive të biznesit, karakteristikë e të gjitha shërbimeve që u ofrohen atyre;
• niveli i shërbimit përshkruan specifikën e shërbimeve individuale të ofruara për një klient ose grup të caktuar klientësh.

Kjo strukturë lejon që mbulimi i nivelit të shërbimit të mbetet brenda kufijve të menaxhueshëm, parandalon dyfishimin e panevojshëm dhe redukton nevojën për përditësime të shpeshta. Megjithatë, kjo kërkon përpjekje shtesë për të ruajtur integritetin e katalogut të shërbimit dhe lidhjeve të sistemit të menaxhimit të konfigurimit.

SLA-të me shumë nivele rrisin menaxhueshmërinë dhe reduktojnë dyfishimin e dokumentacionit brenda një organizate. Kjo do të thotë që përditësimet ndodhin vetëm kur kërkohet. Brenda një organizate, emrat e niveleve mund të ndryshohen, për shembull: korporata, departamenti dhe shërbimi ose grupi, zona e biznesit dhe shërbimi.

Është e nevojshme të sigurohet që administrimi i SLA-ve me shumë nivele të kontrollohet, pasi çdo ndryshim i paraqitur do të ketë ndikim në nivele të tjera. Kjo vlen për çdo ndryshim të bërë në SLA të korporatës - ato duhet të komunikohen në nivele të tjera. Administrimi i SLA-ve me shumë nivele është kompleks, por është më i lehtë sesa administrimi sasi e madhe SLA që nuk janë të kombinuara në një hierarki të tillë.

Shumë organizata e shohin të nevojshme përdorimin e standardeve dhe/ose modeleve të marrëveshjeve si bazë për përgatitjen e marrëveshjeve specifike të nivelit të shërbimit. Modele të tilla mund të përdoren për të zhvilluar projekt-marrëveshje.

Zhvillimi i standardeve dhe modeleve siguron që të gjitha marrëveshjet të zhvillohen në mënyrë konsistente, gjë që nga ana tjetër lehtëson përdorimin, menaxhimin dhe funksionimin e tyre të mëvonshëm.

Përcaktimi i roleve dhe përgjegjësive është pjesë e marrëveshjes së nivelit të shërbimit. Ekzistojnë tre këndvështrime për t'u marrë parasysh - furnizuesi i TI-së, klienti i TI-së dhe përdoruesi aktual.

Formulimi i marrëveshjes duhet të jetë i qartë dhe konciz dhe nuk duhet të lërë vend për paqartësi. Marrëveshjet në përgjithësi nuk kërkohet të shkruhen në terminologjinë ligjore dhe gjuha e thjeshtë ndihmon të kuptuarit e përbashkët. Është e dobishme të përfshihen persona të pavarur për korrigjimin përfundimtar të cilët nuk kanë qenë të përfshirë në krijimin e projekt-marrëveshjeve.

Është e rëndësishme që objektivat e dokumentuara dhe të dakorduara të jenë të qarta, specifike dhe të paqarta pasi ato ofrojnë bazën për marrëdhënien dhe cilësinë e shërbimit të ofruar.

Kërkesat nuk duhet të përfshihen në një marrëveshje të nivelit të shërbimit, ofrimi i së cilës në të ardhmen nuk mund të monitorohet dhe matet në nivelin e rënë dakord. Rëndësia e kësaj nuk mund të mbivlerësohet, pasi përfshirja e artikujve që nuk mund të monitorohen në mënyrë efektive pothuajse gjithmonë do të çojë në mosmarrëveshje dhe humbje të mundshme të besimit nga ana e klientit. Shumë organizata e kuptuan këtë nga gabimet e tyre dhe, si rezultat, morën kosto të mëdha, si brenda financiarisht

, si dhe në imazhin tuaj. Është absolutisht e nevojshme që të identifikohen rrethanat që pengojnë zbatimin e marrëveshjeve dhe çfarë veprimesh duhet të ndërmerren nëse krijohen rrethana të tilla.

Është thelbësore që monitorimi të përputhet me perceptimin e klientit për shërbimin. Për fat të keq, kjo është shpesh shumë e vështirë për t'u arritur. Për shembull, monitorimi i komponentëve individualë si rrjeti ose serveri nuk garanton që shërbimi do të jetë i disponueshëm për klientin siç pritej. Klienti shpesh shqetësohet vetëm për shërbimin që nuk mund ta marrë, megjithëse dështimi mund të ndikojë edhe në shërbime të tjera. Është e pamundur të merret një pamje e plotë pa monitoruar të gjithë komponentët dhe shërbimin në tërësi, dhe kjo është e vështirë dhe e shtrenjtë. Prandaj, përdoruesit duhet të jenë të vetëdijshëm se duhet të raportojnë menjëherë incidentet, veçanërisht incidentet e lidhura me performancën, për të ndihmuar përpjekjet monitoruese të shitësit.

Ka një sërë parametrash të rëndësishëm që nuk mund të maten duke përdorur mjete monitorimi, siç është perceptimi i klientëve për shërbimet (dhe kjo nuk përkon domosdoshmërisht me rezultatet e monitorimit). Për shembull, edhe kur kanë ndodhur një sërë incidentesh, klienti mund të mbajë një perceptim pozitiv të shërbimit përmes veprimeve të dukshme dhe korrekte për të korrigjuar situatën. Sigurisht, është e mundur edhe tabloja e kundërt, kur klienti mbetet i pakënaqur në mungesë të shkeljeve të marrëveshjes së nivelit të shërbimit.

Së pari, duhet të përpiqeni të menaxhoni pritjet e klientëve. Kjo nënkupton formimin e pritshmërive dhe qëllimeve të duhura, dhe më pas rregullimin sistematik në mënyrë proaktive të tyre, duke kujtuar se "kënaqësia = perceptimi - pritjet" (nëse vlera është më e madhe ose e barabartë me zero klienti është i kënaqur). Marrëveshjet e nivelit të shërbimit janë thjesht dokumente, dhe në vetvete nuk zëvendësojnë cilësinë e shërbimit të ofruar (edhe pse ato mund të ndikojnë në sjelljen dhe mund të kontribuojnë në zhvillimin e një kulture të përshtatshme shërbimi, e cila do të ketë efekte pozitive afatshkurtra dhe afatgjata) . Duhet të ushtrohet një shkallë e caktuar durimi dhe të jetë pjesë e pritshmërisë.

Aty ku klienti paguan për shërbimet e ofruara, çmimet mund të përdoren për të menaxhuar kërkesën. (Klientët mund të marrin çdo gjë që mund të justifikojnë - për sa kohë që përshtatet me strategjinë e ndërmarrjes - dhe të kenë një buxhet të autorizuar për të, i cili është i kufizuar.) Aty ku nuk ka kompromis, duhet të sigurohet mbështetja e menaxhmentit të lartë për të kufizuar klientët jorealistë pritjet.

• anketa periodike dhe anketa të klientëve;
• reagimet nga takimet e vlerësimit të shërbimit;
• reagimet gjatë vlerësimit të ndryshimeve të bëra;
• anketat telefonike të kryera nga Shërbimi i Shërbimit;
• pyetësorët e kënaqësisë të shpërndara gjatë shërbimit dhe kontakteve të tjera;
• komunikimi me grupet e përdoruesve (në forume, etj.);
• analiza e ankesave dhe mirënjohja.

Aty ku është e mundur, ia vlen të përcaktohen objektivat e kënaqësisë dhe të monitorohen ato si pjesë e marrëveshjes së nivelit të shërbimit. Sigurohuni që çdo reagim nga përdoruesit t'i përgjigjet duke u demonstruar atyre se komentet e tyre janë përfshirë në planin tuaj të veprimit (Plani i Përmirësimit të Shërbimit). Të gjitha dimensionet e kënaqësisë duhet të vlerësohen, devijimet duhet të analizohen dhe rregullimet duhet të planifikohen bazuar në rezultatet e analizës.

Ofruesit e shërbimeve varen nga ekipet e tyre mbështetëse dhe nga partnerët ose shitësit e jashtëm. Ata nuk mund të garantojnë marrëveshje të nivelit të shërbimit nëse varësitë e brendshme dhe të jashtme nuk mbështesin të njëjtat qëllime. Kontratat me furnitorë të jashtëm janë një domosdoshmëri, por shumë organizata e shohin të dobishme të lidhin gjithashtu marrëveshje të thjeshta ndërmjet grupeve të brendshme, zakonisht të referuara si marrëveshje të nivelit operacional.

“Marrëveshjet Mbështetëse” është një term i përgjithshëm për të gjitha marrëveshjet mbështetëse të nivelit operacional, marrëveshjet dhe kontratat e nivelit të shërbimit.

Marrëveshjet e nivelit operacional nuk duhet të jenë tepër komplekse, por duhet të përcaktojnë synime të qarta për ekipet mbështetëse për të siguruar që qëllimet e marrëveshjes së nivelit të shërbimit janë përmbushur. Për shembull, nëse marrëveshja e nivelit të shërbimit kërkon që incidentet të zgjidhen brenda një kohe të caktuar, marrëveshja e nivelit operacional duhet të përfshijë kufizime të përshtatshme për çdo element në zinxhirin mbështetës. Natyrisht, qëllimet në SLA në këtë rast nuk duhet të përkojnë me qëllimet në marrëveshjet mbështetëse, pasi SLA-të përcaktojnë kohën totale, e cila përfshin punën e disa grupeve, për secilën prej të cilave mund të bihet dakord për një marrëveshje mbështetëse. Marrëveshjet e nivelit të shërbimit duhet të përfshijnë kohën e përgjigjes ndaj kërkesave, kohën për të përshkallëzuar incidentet tek specialistët teknikë dhe kohën e përgjigjes së tyre. Orët e mbështetjes për çdo grup mbështetës duhet gjithashtu të përcaktohen. Nëse ka procedura të veçanta kontakti për stafin ( linjë telefonike

Marrëveshja e nivelit operacional duhet të monitorohet për pajtueshmërinë me objektivat e përcaktuara në marrëveshjet e nivelit të shërbimit dhe kontratat mbështetëse, dhe duhet të krijohet raportimi i duhur dhe t'u komunikohet menaxherëve të ekipit mbështetës. Kjo mund të ndihmojë në identifikimin e fushave të mundshme problematike që kërkojnë rregullime në punë ose marrëveshje. Një konsideratë serioze duhet t'i kushtohet zhvillimit të marrëveshjeve formale të nivelit operacional për të gjitha ekipet e brendshme të përfshira në mbështetjen dhe ofrimin e shërbimeve operacionale.

Prandaj, përpara nënshkrimit të një marrëveshjeje të re ose të rishikuar të nivelit të shërbimit, është e rëndësishme të rishikohen marrëveshjet ekzistuese kontraktuale dhe, kur është e nevojshme, të përditësohen ato. Kjo mund të kërkojë kosto shtesë nga ana e IT ose klientit. Në rastin e fundit, këto kosto duhet të bien dakord me klientin, ose objektiva më të buta duhet të përfshihen në kontrata. Ky rishikim duhet të kryhet së bashku me menaxhmentin e furnizuesit për të siguruar jo vetëm që kërkesat e procesit të menaxhimit të nivelit të shërbimit janë përmbushur, por edhe se kufizimet e tjera janë duke u përmbushur, veçanërisht politikat dhe standardet kontraktuale.

Pasi të jetë rënë dakord dhe pranuar një marrëveshje për nivelin e shërbimit, duhet të sigurohet monitorimi dhe raportimi i nivelit të shërbimit të arritur. Raportimi operacional duhet të gjenerohet shpesh (të paktën çdo javë) dhe, nëse është e mundur, duhet të krijohen raporte të devijimeve kur ndodhin devijime (ose devijime të kërcënuara) nga marrëveshja e nivelit të shërbimit. Shpesh zbatimi i marrëveshjeve të nivelit të shërbimit në faza fillestare Funksionimi i shërbimit të ri është i vështirë për shkak të numrit të madh të kërkesave për ndryshim që vijnë. Rekomandohet të kufizohet numri i kërkesave për ndryshim të lejuara në këtë fazë.

Mekanizmat e raportimit, intervalet dhe formati i raportimit duhet të bien dakord me klientët.

E njëjta gjë vlen edhe për shpeshtësinë dhe formatin e takimeve të vlerësimit të shërbimit. Rekomandohen intervale të rregullta të sinkronizuara me raportim të rregullt.

Raportimi periodik duhet të detajojë performancën kundrejt objektivave të marrëveshjes së nivelit të shërbimit, si dhe të përshkruajë tendencat dhe veprimet për të përmirësuar cilësinë e shërbimit. Është e dobishme të përfshihen tabela në faqen e parë të raportit në raportet SLA për të ofruar një pasqyrë të shpejtë nëse shërbimi është i përshtatshëm për qëllimin. Menaxherët e TI-së mund të kërkojnë raportim të ndërmjetëm për të vlerësuar performancën e marrëveshjeve dhe kontratave të nivelit operacional. Raportimi është një proces në zhvillim;

Procesi i menaxhimit të nivelit të shërbimit duhet të identifikojë nevojat e raportimit dhe të automatizojë raportimin aq sa është e mundur. Ndryshueshmëria, saktësia dhe lehtësia e shpërndarjes së raporteve janë një pjesë e rëndësishme e kritereve të përzgjedhjes së mjeteve të automatizimit. Raportimi i shërbimit nuk duhet të përfshijë vetëm detaje të performancës së shërbimit, por gjithashtu duhet të sigurojë informacion historik rreth vlerave dhe tendencave të kaluara për të mundësuar vlerësimin dhe planifikimin e efektivitetit të përpjekjeve për përmirësimin e shërbimit.

Duhet të organizohen takime periodike me klientët për të vlerësuar së bashku shërbimet bazuar në rezultatet e periudhës së kaluar dhe çdo devijim dhe vështirësi që ka ndodhur. Këto takime janë zakonisht mujore ose të paktën tremujore.

Në këto takime duhet të planifikohen masa për korrigjimin e dobësive në ofrimin dhe konsumin e shërbimeve. Vendimet duhet të regjistrohen dhe zbatimi i tyre të monitorohet dhe verifikohet në mbledhjet e mëpasshme.

Vëmendje e veçantë duhet t'i kushtohet ndërprerjeve të shërbimit; duhet të sqarohen shkaqet dhe masat e mundshme për të parandaluar përsëritjen e incidenteve të tilla. Nëse përcaktohet se qëllimet e vendosura më parë nuk janë të arritshme, mund të merret një vendim për të vlerësuar, ridiskutuar dhe rënë dakord për qëllimet e shërbimit. Nëse ndërprerja e shërbimit ishte për shkak të varësisë nga palët e treta, mund të jetë e nevojshme të rinegociohen marrëveshjet mbështetëse. Analizimi i humbjeve që lidhen me ndërprerjen e shërbimit ofron informacion të rëndësishëm për planifikimin e përmirësimeve racionale. Ndjekja e vazhdueshme e përmirësimit duhet të marrë parasysh interesat e biznesit, duke përqendruar përpjekjet në fushat më të rëndësishme dhe fitimprurëse.

Duhet të krijohet raportim mbi ecurinë dhe rezultatet e zbatimit të planit të përmirësimit të shërbimit për të vlerësuar përputhshmërinë me planin dhe efektivitetin e masave të marra.

Të gjitha llojet e marrëveshjeve duhet të mbahen të përditësuara. Ato duhet t'i nënshtrohen ndryshimeve dhe kontrollit të menaxhimit të konfigurimit dhe të rishikohen periodikisht, të paktën çdo vit, për t'u siguruar që janë aktuale, të plota dhe në përputhje me nevojat dhe strategjinë e biznesit.

Këto rishikime duhet të sigurojnë që marrëveshjet janë të përditësuara për sa i përket fushëveprimit dhe objektivave të deklaruara, duke konfirmuar që marrëveshjet nuk janë bërë të pavlefshme për shkak të ndonjë ndryshimi në infrastrukturë, biznes, furnitorë, etj. Gjatë përditësimit të marrëveshjeve, ndryshimet e bëra duhet të kryhen nën kontrollin e menaxhimit të ndryshimeve. Nëse marrëveshjet pasqyrohen në sistemin e menaxhimit të konfigurimit si KU, ky kontroll është më i lehtë për t'u kryer dhe rezultatet e tij janë më të besueshme.

Rishikimet duhet të mbulojnë gjithashtu dokumentet e përgjithshme të strategjisë për të siguruar që marrëveshjet janë në përputhje me strategjinë dhe politikat e IT dhe biznesit.

Është e rëndësishme që procesi i menaxhimit të nivelit të shërbimit të ndërtojë një marrëdhënie besimi dhe respekti me biznesin, veçanërisht me përfaqësuesit kryesorë të tij. Që kjo të jetë e mundur, procesi i menaxhimit të nivelit të shërbimit duhet të kryejë aktivitetet e mëposhtme:

• konfirmoni listat e palëve të interesuara, klientëve, menaxherëve të biznesit dhe përdoruesve;
• kontribuojnë në ruajtjen e të dhënave të sakta në portofolin dhe katalogun e shërbimeve;
• ofrojnë fleksibilitet dhe gatishmëri për t'iu përgjigjur nevojave të biznesit, klientëve dhe përdoruesve, duke kuptuar proceset aktuale dhe të planifikuara të biznesit dhe kërkesat e tyre për shërbime të reja dhe në ndryshim, duke dokumentuar dhe diskutuar këto kërkesa me biznesin, klientët dhe përdoruesit, duke krijuar marrëdhënie afatgjata ;
• Të sigurojë një kuptim të plotë të strategjisë, planeve, nevojave dhe objektivave të biznesit, klientëve dhe përdoruesve, duke zhvilluar një partneritet midis tyre dhe IT;
• Rishikoni rregullisht punën dhe përvojën e klientëve - të brendshëm dhe të jashtëm - dhe komunikoni informacionin përkatës në IT;
• të sigurojë disponueshmërinë dhe efektivitetin e procedurave të ndërveprimit dhe përmirësimin e vazhdueshëm të tyre;
• organizojnë dhe kryejnë sondazhe të kënaqësisë së klientëve, duke siguruar analizat dhe veprimet e tyre bazuar në rezultatet;
• përfaqëson ofruesin e shërbimit në takimet e grupit të përdoruesve;
• Hulumtoni në mënyrë proaktive tregun duke analizuar përdorimin e shërbimit dhe duke ndikuar në portofolin dhe katalogun e shërbimeve;
• punoni me biznesin, klientët dhe përdoruesit për të siguruar që TI ofron një nivel shërbimi që plotëson nevojat aktuale dhe të ardhshme të biznesit;
• promovojnë ndërgjegjësimin dhe të kuptuarit e shërbimeve;
• të rrisë ndërgjegjësimin për përfitimet e biznesit nga përdorimi i teknologjive të reja;
• të lehtësojë përcaktimin dhe negocimin e kërkesave korrekte, të arritshme dhe realiste të nivelit të shërbimit dhe marrëveshjeve të nivelit të shërbimit ndërmjet IT dhe biznesit;
• Sigurohuni që bizneset, klientët dhe përdoruesit të kuptojnë marrëdhëniet dhe varësitë e tyre të TI-së;
• lehtësojnë regjistrimin e përmirësimeve dhe përmirësimeve.

Procesi i menaxhimit të nivelit të shërbimit duhet të përfshijë gjithashtu aktivitete dhe procedura për regjistrimin dhe menaxhimin e ankesave dhe citimeve. Regjistrimi kryhet shpesh nga Shërbimi i Shërbimit dhe është i ngjashëm me incidentet e regjistrimit dhe kërkesat e shërbimit. Përkufizimet e ankesës dhe mirënjohjes duhet të bien dakord me klientët së bashku me pikat e kontaktit dhe procedurat. Të gjitha ankesat dhe citimet duhet të regjistrohen dhe t'u përcillen palëve përkatëse.

Për të gjitha ankesat, duhet të ndërmerren veprime dhe vendime për të kënaqur iniciuesin. Në rast se kjo nuk ndodh, duhet të përcaktohen kontaktet dhe procedurat e përshkallëzimit. Të gjitha ankesat serioze duhet të shqyrtohen dhe të sillen në vëmendjen e menaxhmentit. Raportimi duhet të gjenerohet mbi statistikat, tendencat, veprimet dhe rezultatet në fushën e përpunimit të ankesave dhe mirënjohjes.

• Treguesit e procesit të menaxhimit të nivelit të shërbimit
• CSF Është e rëndësishme të sigurohet menaxhim cilësor i shërbimeve në tërësi, duke përfshirë mbulimin dhe nivelin e ofrimit:
• KPI Pjesa e reduktimit të mospërputhjes me objektivat SLA
• KPI Përqindja e reduktimit të kërcënimit të moskonformitetit
• KPI Përqindja e përmirësimeve në perceptimin e klientit dhe kënaqësinë me arritjet e SLA bazuar në takimet e vlerësimit të shërbimit dhe anketat e kënaqësisë
• KPI Përqindja e reduktimit të mospërputhjeve për shkak të varësisë nga palët e treta (UC)
• KPI Përqindja e reduktimit të mospërputhjeve të lidhura me varësinë nga kontraktorët e brendshëm (OLA)
• CSF Ofrimi i shërbimeve në përputhje me marrëveshjet për para të arsyeshme:
• Numri i KPI dhe përqindja e rritjes së numrit të SLA-ve plotësisht të dokumentuara
• KPI Pjesa e përmirësimeve në SLA synon përmirësimin e shërbimeve të ofruara tashmë
• KPI Pjesa e uljes së kostos së ofrimit të shërbimeve
• KPI Pjesa e uljes së kostos së monitorimit dhe raportimit sipas SLA
• KPI Pjesa e rritjes së shpejtësisë së zhvillimit dhe miratimit SLA
• KPI Frekuenca e takimeve të vlerësimit të shërbimit
• Menaxhimi i CSF i ndërfaqes midis biznesit dhe përdoruesve:
• KPI Rritja e numrit të shërbimeve të mbuluara nga SLA
• KPI Reduktoi përgjigjen dhe kohën e ekzekutimit për kërkesat SLA
• KPI Rritja e përqindjes së SLA-ve të rishikuara në kohë
• KPI Reduktimi i përqindjes së SLA-ve të paplotësuara që i nënshtrohen rishikimit
• KPI Reduktimi i përqindjes së SLA-ve që kërkojnë rregullime
• KPI Rriti mbulimin e OLA dhe UC duke ulur numrin e marrëveshjeve për shkak të konsolidimit dhe centralizimit të tyre
• KPI Disponueshmëria e dëshmive të dokumentuara të përmirësimeve në devijimet e identifikuara nga SLA
• KPI Reduktimi i numrit dhe ashpërsisë së mospërputhjes me qëllimet SLA
• KPI Vlerësimi efektiv dhe përpunimi i të gjitha devijimeve dhe mospërputhjeve nga SLA, OLA, UC

ITIL identifikon masat subjektive dhe objektive të performancës për menaxhimin e nivelit të shërbimit.

• Objektivi:
• Numri ose përqindja e synimeve të arritura të shërbimit
• Numri dhe shkalla (ashpërsia) e devijimeve dhe shkeljeve
• Numri i SLA-ve aktuale (të përditësuar)

Numri i shërbimeve që raportohen dhe vlerësohen në kohën e duhur

• Subjektiv:

Rreziqet dhe vështirësitë

Përmirësimi i kënaqësisë së klientit

• Gjatë zbatimit të menaxhimit të nivelit të shërbimit, duhet të merren parasysh rreziqet dhe vështirësitë e mundshme të mëposhtme:
• Mungesa e të dhënave, angazhimit dhe interesit të saktë nga biznesi dhe klientët
• Nevoja për burime dhe mjete për të negociuar, dokumentuar, monitoruar, raportuar dhe vlerësuar marrëveshjet dhe nivelet e shërbimit
• Procesi mund të bëhet tepër burokratik, i fokusuar në procedurat administrative dhe jo në përmirësimin aktual proaktiv të shërbimeve
• Qasje dhe mbështetje për CMS dhe SKMS korrekte dhe të përditësuara
• Mosrespektimi i procedurave SLM
• Metrikat e orientuara nga biznesi janë shumë të vështira për t'u matur dhe përmirësuar, kështu që ato nuk mblidhen
• Niveli i papërshtatshëm i kontaktit dhe koordinimit
• Pritshmëri të larta dhe kënaqësi të ulët të klientit

Komunikime joefektive me biznesin

Procesi i menaxhimit të problemeve

Një problem është shkaku i një ose më shumë incidenteve. Në mënyrë tipike, kur regjistrohet një problem, shkaku është i panjohur dhe procesi i menaxhimit të problemit është përgjegjës për hetimin e mëtejshëm.

Për të identifikuar shkaqet rrënjësore të gabimeve ekzistuese dhe të mundshme të ofrimit të shërbimeve, procesi i menaxhimit të problemit shqyrton infrastrukturën dhe informacionin e disponueshëm, duke përfshirë bazën e të dhënave të incidenteve.

Menaxhimi i çështjeve është procesi përgjegjës për menaxhimin e ciklit jetësor të të gjitha çështjeve. Menaxhimi i problemeve parandalon në mënyrë proaktive incidentet dhe minimizon ndikimin e atyre incidenteve që nuk mund të parandalohen.

Menaxhimi i problemit përfshin aktivitete proaktive dhe reaktive. Qëllimi i komponentëve reaktivë të procesit të menaxhimit të problemit është të përcaktojë shkakun rrënjësor të incidenteve të kaluara dhe të përgatisë një propozim për eliminimin e tij. Menaxhimi proaktiv i problemeve ndihmon në parandalimin e incidenteve duke identifikuar dobësitë në infrastrukturë dhe duke bërë propozime për përmirësime.

Kështu, objektivat e procesit të menaxhimit të problemit janë:

• Parandalimi i problemeve dhe incidenteve të lidhura me to
• Ndalimi i përsëritjes së incidenteve
• Ulja e ndikimit të incidenteve që nuk mund të parandalohen

Aktivitetet në kuadër të Procesit të Menaxhimit të Problemeve

Në parim, çdo incident që ndodh për një arsye të panjohur mund të shoqërohet me një problem. Në praktikë, ka kuptim të fillohet një problem vetëm kur incidenti përsëritet, ka të ngjarë të përsëritet ose nëse është një incident i izoluar, por serioz.

Aktiviteti i "identifikimit të problemeve" kryhet shpesh nga koordinatorët e problemeve. Megjithatë, mund të ndodhë që personeli që nuk është përfshirë fillimisht në këtë punë, si specialistët e menaxhimit të kapaciteteve, mund të identifikojë gjithashtu probleme. Të tilla “gjetje” duhet gjithashtu të regjistrohen si probleme.

Detajet e regjistrimit të problemeve janë të ngjashme me detajet e incidentit, por në rastin e një problemi nuk ka nevojë të përfshihen informacionet e përdoruesit etj. Megjithatë, incidentet që lidhen me një problem specifik duhet të identifikohen dhe regjistrohen në përputhje me rrethanat. Më poshtë janë shembuj të rasteve kur mund të identifikohen problemet:

• Menaxhimi i incidentit nuk mund të përputhet me një incident me problemet ekzistuese ose gabimet e njohura
• Analiza e tendencës së incidentit tregon se mund të ketë një problem
• Kërkohet një analizë e shkakut të një incidenti të madh
• Funksione të tjera të TI-së kanë përcaktuar se mund të ketë një problem
• Stafi i Shërbimit të Shërbimit nuk ishte në gjendje të përcaktonte shkakun e incidentit dhe ekziston dyshimi se ky incident mund të përsëritet.
• Analiza e incidentit nga ekipi mbështetës tregoi se ka (ose mund të ketë) një problem
• Njoftim nga furnizuesi se ka një problem që duhet zgjidhur

Shenjat e mundshme të problemeve mund të përfshijnë:

• Incidentet e përsëritura në:
• E njëjta periudhë kohore
• Në një fushë lëndore (kategori)
• Në të njëjtin CI ose grup CI të ngjashme
• Në të njëjtat lokacione, rend, ndarje
• Vëllimi i incidenteve të ngjashme tejkalon një nivel të caktuar
• Është zbatuar një zgjidhje për të zgjidhur incidentin.
• Tejkalimi i afatit për përpunimin e incidenteve

Analiza e trendit zbulon fusha që kërkojnë vëmendje të veçantë.

• Pavarësisht nga metoda e zbulimit të problemit, të gjitha të dhënat përkatëse në lidhje me problemin duhet të regjistrohen në një regjistër problemi:
• Informacion në lidhje me përdoruesit
• Informacion në lidhje me shërbimin(et)
• Informacioni i Pajisjeve
• Koha e regjistrimit
• Prioriteti, kategoria
• Përshkrimi i incidenteve të lidhura

Veprimet e marra për të diagnostikuar dhe zgjidhur

Regjistrimi i problemit - një regjistrim që përmban një përshkrim të detajuar të problemit. Çdo regjistrim i botimit dokumenton ciklin jetësor të një numri.

Ashtu si incidentet, problemet duhet të klasifikohen. Problemet mund të klasifikohen në fusha (kategori). Klasifikimi i problemit kryhet njëkohësisht me analizën e shkallës së ndikimit të tij, d.m.th., shkallës së ashpërsisë së problemit dhe ndikimit të tij në shërbime (urgjenca dhe shkalla e ndikimit). Pas kësaj, çështjes i jepet prioritet, ashtu si në procesin e menaxhimit të incidentit. Bazuar në rezultatet e klasifikimit, burimet dhe personeli më pas caktohen për problemin dhe përcaktohet koha e nevojshme për zgjidhjen e tij.

Klasifikimi i problemit përfshin sa vijon:

Një gabim i njohur është një problem që ka një shkak rrënjësor të dokumentuar dhe zgjidhje.

Hetimi dhe diagnostikimi janë faza përsëritëse të procesit, ato përsëriten shumë herë, duke u afruar çdo herë me rezultatin e synuar. Shpesh bëhen përpjekje për të riprodhuar incidentin në kushte testimi. Për të zgjidhur problemin, mund të kërkohen njohuri shtesë, për shembull, mund të përfshini specialistë nga ekipi mbështetës për të analizuar dhe diagnostikuar problemin.

Pasi të jetë përcaktuar shkaku i problemit dhe një zgjidhje, problemit i caktohet statusi i një gabimi të njohur.

Në shumë raste, një zgjidhje për problemin është tashmë e disponueshme fillimisht, edhe nëse gabimi është gjetur nga vetë zhvilluesit. Por në disa raste, duhet të gjendet një zgjidhje dhe më pas të kalohet në procesin e menaxhimit të incidentit.

Një zgjidhje është zvogëlimi ose eliminimi i ndikimit të një incidenti ose problemi për të cilin nuk disponohet aktualisht zgjidhja e plotë. Për shembull, rinisja e një artikulli konfigurimi të dështuar. Zgjidhjet për problemet dokumentohen në të dhënat e njohura të gabimeve. Personeli i përfshirë në menaxhimin e problemit përcakton se çfarë duhet bërë për të zgjidhur problemin. Ekspertët krahasojnë zgjidhje të ndryshme

, duke marrë parasysh marrëveshjet e nivelit të shërbimit (SLA), kostot dhe përfitimet e mundshme.

E gjithë puna për të zhvilluar një zgjidhje duhet të regjistrohet në sistem dhe stafi duhet të ketë mjetet për të monitoruar problemet dhe për të përcaktuar statusin e tyre.

Në fazat e mëparshme, zgjidhet zgjidhja optimale. Megjithatë, mund të merret një vendim për të mos korrigjuar një gabim të njohur, për shembull për shkak të joprakticitetit ekonomik.

Pasi të përfundojë faza e përzgjedhjes, ka informacion të mjaftueshëm për të paraqitur një kërkesë ndryshimi. Më pas, problemi (gabimi i njohur) do të korrigjohet nën kontrollin e procesit të menaxhimit të ndryshimeve.

Zgjidhjet dhe rregullimet e shpejta i komunikohen Menaxhimit të Incidentit gjatë gjithë procesit. Për këtë mund të informohen edhe përdoruesit.

Politikat dhe matjet e procesit të menaxhimit të problemeve

Politikat e procesit të menaxhimit të problemeve duhet të ndiqen për të siguruar efektivitetin dhe efikasitetin e procesit, dhe mund të përfshijnë sa vijon:

• Problemet duhet të gjurmohen veçmas nga incidentet
• Të gjitha çështjet duhet të ruhen dhe menaxhohen sistem të unifikuar menaxhimit
• Të gjitha problemet duhet të kenë një skemë standarde klasifikimi që korrespondon me proceset e biznesit të ndërmarrjes

Për të menaxhuar dhe vlerësuar efektivitetin e procesit të menaxhimit të nivelit të shërbimit, si dhe për të dhënë reagime ndaj proceseve të tjera të menaxhimit, ITIL sugjeron përdorimin e treguesve kryesorë të mëposhtëm (CSF dhe KPI):

• CSF Minimizimi i ndikimit të biznesit të incidenteve që nuk mund të parandalohen
• KPI Numri i gabimeve të njohura të shtuara nga KEDB
• Përqindja KPI e rëndësisë së KEDB (bazuar në auditimin e bazës së të dhënave)
• KPI Përqindja e incidenteve të mbyllura nga qendra e ndihmës ("pika e parë e kontaktit")
• KPI Koha mesatare për të zgjidhur incidentet për të cilat është hapur një çështje
• CSF Ruajtja e cilësisë së shërbimeve të IT duke eliminuar incidentet e përsëritura
• KPI Numri total i problemeve (si parametër kontrolli)
• Madhësia e radhës KPI sipas çështjes për çdo shërbim IT
• KPI Numri i incidenteve të përsëritura për çdo shërbim IT
• CSF Sigurimi i cilësisë dhe aftësisë në zgjidhjen e problemeve për të ruajtur besimin e biznesit në aftësitë e IT
• KPI Numri i çështjeve të rëndësishme (të hapura, të mbyllura dhe në radhë)
• Përqindja KPI e rishikimeve të çështjeve të rëndësishme të përfunduara me sukses
• KPI Përqindja e rishikimeve të çështjeve të rëndësishme të përfunduara me sukses dhe në kohë
• Numri i KPI dhe përqindja e problemeve të caktuara gabimisht
• Numri i KPI dhe përqindja e problemeve me kategorizim të pasaktë
• KPI Radha e problemeve të akumuluara të pazgjidhura dhe tendenca e saj
• Numri i KPI dhe përqindja e problemeve që tejkaluan kornizën kohore për zgjidhje
• KPI Përqindja e çështjeve të zgjidhura brenda qëllimeve të SLA
• KPI Kostoja mesatare e zgjidhjes së një problemi

Vlera e biznesit

Duke zbatuar një proces të menaxhimit të incidentit në përputhje me udhëzimet ITIL dhe duke adresuar çdo sfidë që mund të lindë gjatë zbatimit, mund të arrihet vlera e mëposhtme për biznesin në tërësi:

• Përmirësimi i cilësisë së shërbimeve të IT duke monitoruar, dokumentuar dhe/ose eliminuar gabimet në infrastrukturë.
• Ulja e numrit të incidenteve.
• Rritja e produktivitetit të stafit
• Aplikimi i solucioneve të përhershme në vend që të mbyllni vazhdimisht vrimat.
• Aktivitete sistematike për të grumbulluar njohuri.
• Aftësia për të zgjidhur më shumë incidente në linjën e parë të mbështetjes.
• Ulja e kostos së përpjekjeve gjatë shuarjes së zjarreve ose zgjidhjes së incidenteve të përsëritura

Procesi i menaxhimit të aseteve të shërbimit dhe konfigurimit

Çdo organizatë ka informacion për infrastrukturën e saj IT. Shpesh, për të strukturuar dhe përmbledhur informacionin e disponueshëm, diagrame të ndryshme zhvillohen dhe varen në mur. Kjo metodë në të vërtetë lejon, në raste të caktuara, marrjen e shpejtë të informacionit në lidhje me konfigurimin e komponentëve të infrastrukturës dhe marrëdhëniet e tyre, por ka një sërë disavantazhesh:

• vështirësia e përditësimit: me çdo ndryshim, diagrami duhet të rivizatohet dhe të printohet përsëri, përndryshe nuk mund të mbështetet nëse është e nevojshme.
• mbulim i kufizuar: komponentët e infrastrukturës mund të ndërthuren shumë ngushtë dhe jo gjithmonë të gjithë elementët mund të pasqyrohen në diagram
• informacion i kufizuar: si rregull, vetëm informacioni më i rëndësishëm tregohet për secilin element, për shembull, emri i domenit ose adresa IP
• kompleksiteti i analizës: me një mbulim të madh qarku dhe në prani të marrëdhënieve të ndryshme komplekse midis komponentëve, analiza e qarqeve të tilla është e vështirë

Procesi i menaxhimit të aseteve dhe konfigurimeve të shërbimit, i ndërtuar në përputhje me rekomandimet e ITIL, ju lejon të përdorni të dhënat e disponueshme për infrastrukturën e IT në mënyrën më efektive, duke shmangur këto disavantazhe dhe duke marrë përfitime shtesë.

Menaxhimi i Aseteve të Shërbimit dhe Konfigurimit (SACM) është procesi përgjegjës për të siguruar që të gjitha asetet që kërkohen për të ofruar shërbime janë të kontrolluara dhe informacioni i saktë dhe i besueshëm rreth tyre është i disponueshëm kur nevojitet. Ky informacion përfshin konfigurimin e aseteve dhe marrëdhëniet ndërmjet tyre.

Menaxhimi i aseteve të shërbimit dhe konfigurimit përfshin dy nënprocese:

• Menaxhimi i Aseteve - aktiviteti ose procesi përgjegjës për gjurmimin dhe raportimin e vlerës dhe pronësisë së aseteve gjatë ciklit të tyre jetësor
• Menaxhimi i konfigurimit është aktiviteti ose procesi përgjegjës për menaxhimin e informacionit në lidhje me artikujt e konfigurimit të nevojshëm për të ofruar shërbime IT, duke përfshirë marrëdhëniet e tyre.

Objektivat e procesit të menaxhimit të aseteve të shërbimit dhe konfigurimit:

• Identifikoni, monitoroni, dokumentoni, raportoni dhe verifikoni asetet e shërbimit dhe artikujt e konfigurimit, duke përfshirë versionet, linjat bazë, komponentët, atributet dhe marrëdhëniet e tyre
• Përgjegjës për menaxhimin dhe mbrojtjen dhe mbrojtjen e integritetit të aseteve të shërbimit dhe artikujve të konfigurimit (dhe, sipas rastit, atyre në pronësi të klientit) gjatë gjithë ciklit jetësor të shërbimit, duke siguruar që të përdoren vetëm komponentët e autorizuar dhe të bëhen vetëm ndryshime të autorizuara
• Siguroni integritetin e aseteve dhe konfigurimit të kërkuar për të menaxhuar shërbimet dhe infrastrukturën e TI-së duke krijuar dhe mbajtur një sistem të saktë dhe të plotë të menaxhimit të konfigurimit

Thelbi i procesit është sistemi i menaxhimit të konfigurimit (CMS). CMS ju lejon të ruani të gjithë informacionin e nevojshëm të konfigurimit, ta analizoni dhe ta prezantoni në seksione të ndryshme.

Sistemi i menaxhimit të konfigurimit (CMS) është një grup mjetesh, të dhënash dhe informacioni që përdoren për të mbështetur procesin e menaxhimit të aseteve dhe konfigurimeve të shërbimit. CMS - pjesë sistemi i përbashkët Menaxhimi i njohurive të shërbimit përfshin mjete për mbledhjen, ruajtjen, menaxhimin, përditësimin, analizimin dhe paraqitjen e informacionit për të gjithë artikujt e konfigurimit dhe marrëdhëniet e tyre. CMS mund të përfshijë gjithashtu informacione rreth incidenteve, çështjeve, gabimeve të njohura, ndryshimeve dhe lëshimeve. CMS mbështetet nga procesi i menaxhimit të aseteve të shërbimit dhe konfigurimit dhe përdoret nga të gjitha proceset e menaxhimit të shërbimit të IT.

Artikulli i konfigurimit (CU) është çdo komponent ose aktiv tjetër shërbimi që duhet të kontrollohet për të ofruar një shërbim IT. Informacioni për çdo artikull të konfigurimit regjistrohet në formën e një regjistrimi konfigurimi në sistemin e menaxhimit të konfigurimit dhe mbahet aktual gjatë gjithë ciklit të tij jetësor nga aseti i shërbimit dhe procesi i menaxhimit të konfigurimit.

Artikujt e konfigurimit kontrollohen nga procesi i menaxhimit të ndryshimeve. Këto zakonisht përfshijnë shërbimet e TI-së, pajisjet, softuerin, ndërtesat, njerëzit dhe dokumentet si dokumentacioni i procesit dhe marrëveshjet e nivelit të shërbimit. Njësitë e konfigurimit mund të jenë mjete teknike, të të gjitha llojeve software

• të dhënat e artikujve të konfigurimit, duke përfshirë atributet e tyre përkatëse
• marrëdhëniet (lidhjet) ndërmjet artikujve të konfigurimit

Atributet ju lejojnë të merrni parasysh informacionin e kërkuar për një lloj të caktuar të artikujve të konfigurimit. Për shembull, për serverët dhe laptopët, informacione të tilla si prodhuesi, emri i domenit, periudha e garancisë, etj. mund të jenë me interes.

Megjithatë, për softuerin ky informacion ka shumë të ngjarë të ndryshojë.

Një atribut është një pjesë e informacionit në lidhje me një artikull konfigurimi. Për shembull, emri, vendndodhja, numri i versionit dhe kostoja. Atributet KU regjistrohen në një bazë të dhënash të menaxhimit të konfigurimit (CMDB) dhe mbahen si pjesë e një sistemi të menaxhimit të konfigurimit (CMS).

Kështu, çdo artikull konfigurimi duhet t'i përkasë një lloji (klase) të veçantë, i cili përcakton atributet e përbashkëta për të gjitha CI të këtij lloji (klasë) dhe një listë të marrëdhënieve të mundshme midis CI të këtij lloji dhe CI të një lloji tjetër.

Lloji KE është një kategori që përdoret për të klasifikuar artikujt e konfigurimit. Lloji CI përcakton se cilat atribute dhe marrëdhënie kërkohen për regjistrimin e konfigurimit. Llojet e zakonshme të KE - pajisjet, dokumentacioni, përdoruesi, etj. Grupi i CI-ve dhe marrëdhëniet e tyre përfaqësojnë në fakt një model konfigurimi.
Figura tregon një shembull të një modeli konfigurimi. CMS ju lejon të merrni parasysh në mënyrë efikase informacionin e nevojshëm të konfigurimit, ta analizoni dhe ta paraqisni atë në forma të ndryshme

• , duke përfshirë grafikun. CMS ofron informacion për proceset e tjera të menaxhimit të shërbimeve:
• për të vlerësuar ndikimin e incidenteve dhe problemeve
• për të vlerësuar ndikimin e ndryshimeve
• për planifikimin dhe projektimin e shërbimeve të reja dhe në ndryshim
• për planifikimin e teknologjisë dhe përmirësimeve të softuerit
• për planifikimin e paketave të lëshimit dhe përsëritjen e shërbimeve

për të optimizuar përdorimin dhe kostot e aseteve

• Kështu, nëse menaxhimi i aseteve të shërbimit dhe konfigurimit zbatohet në mënyrë efektive, ky proces mund të sigurojë, për shembull, informacion në lidhje me sa vijon: Informacion financiar
• dhe politika e produktit të kompanisë
• Cilët komponentë të IT janë aktualisht në përdorim për çdo model (version) dhe për sa kohë?
• Çfarë tendencash ka në grupe të ndryshme produktesh?
• Cila është vlera aktuale dhe ajo e mbetur e komponentëve të TI-së?
• Cilët komponentë të TI-së duhet të hiqen nga mjedisi operacional dhe cilët kërkojnë modernizim?
• Sa do të kushtojë zëvendësimi i disa komponentëve?
• Cilat kontrata mbështetëse duhet të rishikohen?
• Cila është shkalla e standardizimit të infrastrukturës?
• Zgjidhja e problemeve dhe vlerësimi i rezultateve
• Cilët komponentë të TI-së nevojiten për të mbështetur procesin e rikuperimit në rast të emergjente?
• A do të funksionojë plani i rimëkëmbjes nga fatkeqësitë nëse konfigurimi i infrastrukturës është ndryshuar?
• Cilët komponentë të TI-së do të ndikohen gjatë vendosjes së shërbimeve të reja?
• Si lidhet pajisja me rrjetin?
• E cila modulet e softuerit përfshihet në çdo paketë softuerike?
• Cilët komponentë të TI-së ndikohen nga ndryshimet?
• Cilat kërkesa për ndryshim (RFC) për komponentë specifikë të TI-së janë në pritje dhe çfarë incidentesh dhe çështjesh kanë ndodhur në të kaluarën dhe janë ende në vazhdim?
• Cilët komponentë të TI-së shkaktojnë gabime të njohura?
• Cilët komponentë të TI-së janë blerë nga një furnizues specifik gjatë një periudhe të caktuar?
• Ofrimi i shërbimit dhe faturimi
• Cilat konfigurime të komponentëve të TI-së janë thelbësore për shërbime të caktuara?
• Cilët komponentë të TI-së përdoren në cilin vend dhe nga kush?
• Cilët komponentë standardë të TI-së mund të porosisë përdoruesi dhe cilët janë të mbështetur (katalogu i produkteve)?

Aktivitetet brenda aseteve të shërbimit dhe procesit të menaxhimit të konfigurimit

Figura tregon një diagram të aktiviteteve tipike të menaxhimit të konfigurimit.

Në materialet ITIL, "planifikimi" i referohet aktivitetit të organizimit të vetë procesit të menaxhimit të konfigurimit. Menaxhimi dhe planifikimi si një lloj aktiviteti përdoret si në fazën e krijimit ashtu edhe në fazën e përmirësimit të procesit. Rezultati kryesor i planifikimit është "Plani i Menaxhimit të Konfigurimit".

Plani i menaxhimit të konfigurimit përmban.

• Përshkrimi i procesit të menaxhimit të konfigurimit
• Përshkrimi i nivelit të lartë të arkitekturës së sistemit
• Plani i ngjarjeve të rëndësishme (identifikimi, publikimet kryesore, etj.)

Plani është një dokument i gjallë dhe i nënshtrohet rishikimit të rregullt. Menaxheri i procesit të menaxhimit të konfigurimit është përgjegjës për përditësimin e planit.

Aktivitetet e identifikimit të konfigurimit përfshijnë:

• Përcaktimi dhe dokumentimi i kritereve për përzgjedhjen e artikujve të konfigurimit dhe përbërësve të tyre
• Përzgjedhja e artikujve dhe komponentëve të konfigurimit bazuar në kriteret e dokumentuara
• Caktimi i identifikuesve unikë
• Përcaktimi i atributeve për çdo çelës
• Përcaktimi i momentit kur CI merr kontrollin e procesit
• Përcaktimi i pronarit përgjegjës për çdo KU

Në varësi të shkallës së infrastrukturës së TI-së dhe kompleksitetit të rregullave të kontabilitetit, identifikimi mund të zgjasë shumë dhe të kërkojë një sasi të konsiderueshme burimesh. Prandaj, puna e identifikimit duhet të planifikohet me kujdes.

Aktivitetet e menaxhimit të KE përfshijnë aspektet e mëposhtme:

• Mbajtja e të dhënave CMDB të përditësuara
• Sigurimi i integritetit të të dhënave CMDB (origjina dhe historia e ndryshimeve për çdo CU janë të qarta)
  • Kufizimi i aksesit për të modifikuar të dhënat CMDB
  • Sigurimi i mbrojtjes antivirus të kontrolleve CMDB
  • Sigurimi i aftësive rezervë dhe rikuperimi të të dhënave
• Rregullat e kontrollit duhet të zhvillohen në fazën e planifikimit të procesit
• Rregullat për transferimin e kontrollit nga projektet ose furnitorët
• Procedurat e kontrollit duhet të korrespondojnë me llojet e KE

Statusi i konfigurimit dhe aktivitetet e raportimit përfshijnë:

• Mbani të dhënat e konfigurimit gjatë gjithë ciklit jetësor të shërbimit dhe arkivoni ato në përputhje me marrëveshjet, kërkesat e jashtme, praktikat dhe standardet më të mira (p.sh. ISO 9001)
• Menaxhoni dokumentacionin, rikthimin dhe konsolidimin e statusit aktual të konfigurimit dhe statuseve të të gjitha konfigurimeve të mëparshme për të siguruar korrektësinë, afatin kohor, integritetin dhe sigurinë e informacionit
• Sigurimi i disponueshmërisë së informacionit të statusit gjatë gjithë ciklit jetësor të shërbimit
• Dokumentimi i CI ndryshon nga pranimi në çmontim
• Sigurimi që konfigurimet bazë janë të dokumentuara saktë

Verifikimi dhe auditimi:

• Verifikimi - kontrollimi i KE për përputhshmëri me standardet ose kërkesat funksionale:
• Në regjistrimin fillestar në CMDB
• Kur merrni harduer ose softuer nga një furnizues
• Gjatë vënies në punë
• Auditimi - kontrollimi i përputhshmërisë midis gjendjes aktuale të CI (siç është) dhe përshkrimit të CI në CMDB (siç duhet të jetë)
• Auditimi standard
• Auditim i thjeshtuar
• Auditimi aktual (operativ).

• Një periudhë e shkurtër kohore pas zbatimit sistemi i ri/ procesi i menaxhimit të konfigurimit
• Para dhe pas ndryshimeve të mëdha në infrastrukturën e IT
• Përpara se të vendosni softuer të ri, verifikoni gatishmërinë e prodhimit
• Pas rikuperimit nga një dështim i madh (urgjent)
• Me zbulimin e një numri të madh mospërputhjesh (për shembull, si pjesë e një auditimi operacional)
• Rregullisht (me frekuencë të paracaktuar)
• Herë pas here (kontrolle "të papritura")

Treguesit e procesit të menaxhimit të aseteve të shërbimit dhe konfigurimit

Për të menaxhuar dhe vlerësuar efektivitetin e procesit të menaxhimit të ndryshimit, si dhe për të dhënë reagime ndaj proceseve të tjera të menaxhimit, ITIL sugjeron përdorimin e treguesve kryesorë si:

• Përqindja e përmirësimit në mbështetjen e ciklit jetësor të aseteve bazuar në parimin: jo shumë, jo shumë vonë
• Niveli i mbështetjes që plotëson nevojat e biznesit
• Pasuritë e identifikuara si shkaku i dështimeve të shërbimit
• Rritja e shpejtësisë së zgjidhjes së incidenteve dhe rikthimit të shërbimeve përmes identifikimit më të shpejtë të CI-ve me defekt
• Identifikoni lidhjet midis llojeve të veçanta të CI, incidenteve dhe problemeve
• Më shumë përdorim efikas asetet e shërbimit
• Përdorim më efikas i licencave të blera, kosto mesatare e licencës për përdorues
• Tarifa më të sakta të buxhetit dhe përdorimit të aseteve
• Auditime më efikase të aseteve
• Përmirësimi i cilësisë dhe saktësisë së informacionit të aseteve
• Më pak gabime të shkaktuara nga puna me të dhëna të vjetruara
• Reduktimi i numrit dhe fushëveprimit të auditimeve
• Përdorimi i reduktuar i harduerit dhe softuerit të paautorizuar, gjë që çon në uljen e kostove dhe rreziqeve në shërbimet mbështetëse
• Zvogëloni kohën dhe koston gjatë diagnostikimit dhe zgjidhjes së incidenteve dhe problemeve
• Reduktimi i kohës për të identifikuar asetet me probleme të performancës
• Reduktimi i numrit të ndryshimeve të pasuksesshme të shkaktuara nga vlerësime të pasakta të ndikimit, të dhëna të pasakta në CMS ose kontroll i dobët i versionit
• Zvogëloni rrezikun me zbulimin e hershëm të ndryshimeve të paautorizuara

Vështirësitë

Gjatë zbatimit të menaxhimit të aseteve të shërbimit dhe konfigurimit, duhet të merren parasysh sfidat e mëposhtme të mundshme:

• Staf bindës mbështetje teknike në përputhje me politikat e kontabilitetit, e cila shpesh perceptohet si një pengesë për mbështetjen e shpejtë të shërbimit.
• Tërheqja dhe justifikimi i alokimit të fondeve për procesin, pasi, zakonisht, procesi nuk është i dukshëm për departamentet e klientit që kanë autoritetin për të ndarë fonde. Në mënyrë tipike financohet si një element "i padukshëm" i menaxhimit të ndryshimit dhe proceseve të tjera më "të dukshme".
• Qasja: "mbledh të gjitha të dhënat e mundshme", gjë që çon në mbingarkesë të procesit, si dhe në pamundësi për ta ruajtur atë.
• Mungesa e përkushtimit dhe mbështetjes nga menaxhmenti i cili nuk e kupton rolin kyç të procesit

Metoda e incidentit kritik.

Identifikimi i një incidenti kritik - kjo është një metodë e krijuar për të identifikuar

identifikimi i procesit, nënprocesit ose fushës së problemit që ia vlen të trajtohet

përmirësuar. Metoda u zhvillua nga Lawlor në 1985. Kjo është mjaft e hapur

Një mënyrë e shpejtë dhe e shkurtër për të marrë informacion rreth problemeve të një organizate. Si parakusht, supozohet se të gjithë pjesëmarrësit janë absolutisht të lirë

në shprehjen e pikëpamjeve të tyre. Çdo censurë apo fshehje informacioni nga frika

as që ajo do të jetë shumë e sinqertë refuzohet me vendosmëri.

Metoda përfshin tre faza:

1). Përzgjidhen pjesëmarrësit për analizë. Nëse qëllimi është që

marrja e një vendimi për të përmirësuar të gjithë procesin, është e natyrshme

përfshijnë përfaqësues nga fusha të ndryshme të organizatës. Nëse

Lew është të përcaktojë më saktë drejtimin e veprimit brenda

proces i përcaktuar tashmë i biznesit, është më mirë të zgjidhni njerëzit e përfshirë në

këtë proces.

2). Më pas pjesëmarrësve të diskutimit u kërkohet t'u përgjigjen pyetjeve si:

Cili ishte incidenti më i vështirë për t'u përballur në javën e kaluar?

Çfarë episodi krijoi? problemet më të mëdha për të plotësuar nevojat

karakteristikat e konsumatorit?

Cili incident kushtoi më shumë përsa i përket tërheqjes

burime shtesë apo kosto direkte?

Në këtë fazë të përdorimit të metodës, është e rëndësishme të theksohen të ashtuquajturat qaj-

incidente tik, të cilat në një mënyrë apo në një tjetër krijojnë probleme

për punonjës individualë, për të gjithë organizatën dhe për të interesuar të tjerë

anët e banjës. Periudha e mbuluar nga pyetja mund të ndryshojë

nga disa ditë në disa muaj. Megjithatë, nuk rekomandohet që ju

zgjidhni një periudhë shumë të gjatë, pasi në këtë rast mund të jetë e vështirë

Është e vështirë të veçosh incidentin më të rëndësishëm kritik, sepse

se gjatë një periudhe të gjatë kohore mund të ketë shumë incidente të tilla.

3). Përgjigjet e mbledhura renditen dhe përcaktohet se cila nga të ndryshmet

Dentov u përmend më shpesh se të tjerët. Për të nënvizuar një incident kritik

Është i përshtatshëm për të përdorur një paraqitje grafike të rezultateve të marra. Se

incidenti që ndodh më shpesh se të tjerët do të jetë kritik. Ai - është -

një kandidat i mirë për parandalim. Sidoqoftë, nuk duhet të luftoni shumë me veten tuaj

incidentin dhe simptomat e tij, si dhe arsyet që e shkaktuan atë.

Shembull.

Filloi një korporatë e madhe me 15 operatorë telefonik në staf

për projektin për përmirësimin e shërbimit telefonik për konsumatorët kur

përgjigjuni thirrjeve. U vendos që të përdoret metoda e identifikimit të klithjes

incident tic.

Të gjithë operatorëve telefonikë iu kërkua të përshkruanin ato incidente që

ngjarjet e muajit të fundit që i kanë vënë në një situatë jashtëzakonisht të vështirë. Rezultatet e anketës u renditën sipas frekuencës

përsëritja e incidenteve. Ato janë paraqitur në Fig. 7.1 në formën e një diagrami. nga ri-

Fotografia tregon se incidentet kritike ishin: 1) pamundësia për të arritur

personi që duhet t'i përgjigjet thirrjes, 2) duke mos ditur se kush duhet t'i përgjigjet saktësisht

gratë të përgjigjen. Bazuar në rezultatet e studimit, u bënë përpjekje

për të krijuar një sistem për gjurmimin e lëvizjeve të çdo punonjësi, si dhe

janë zhvilluar udhëzime se cili nga punonjësit duhet t'i përgjigjet cilës kërkese

përgjigje. Lista kontrolluese - Ky është një formë ose një formë e veçantë e synuar

filloi për regjistrimin e të dhënave, Rolstados (1995). Një nga arsyet kryesore

Qëllimi i listës së kontrollit është të regjistrojë sa shpesh

ndodhin probleme apo incidente të ndryshme. Kjo jep informacion të rëndësishëm

informacion në lidhje me zonat problematike ose shkaqet e mundshme të gabimeve. Përdorimi

listat kontrolluese ofrojnë një bazë të mirë për të marrë vendime se ku

përpjekjet për përmirësim duhet të përqendrohen.

Plotësimi i fletës së kontrollit zakonisht bëhet në disa faza:

1) Arritja e marrëveshjes se cilat ngjarje duhet të regjistrohen. E gjithë kjo është e nevojshme

të përcaktojë saktësisht në mënyrë që të mos ketë dyshim nëse ka ndodhur ngjarja

Në fakt. Këshillohet gjithashtu të përfshini në fletën e kontrollit pozicionin

"Të tjera" për të regjistruar incidente që është e vështirë t'u atribuohen

2) Përcaktimi i periudhës së regjistrimit të të dhënave dhe ndarja e saj e përshtatshme në ndër-

3) Zhvillimi i një formulari (formular) të një flete kontrolli që përdoret për regjistrim

traditat. 4) Mbledhja e të dhënave ndodh gjatë gjithë periudhës kohore të rënë dakord.

Së pari duhet të siguroheni që të gjithë që marrin pjesë në

Kur mbledhin të dhëna, ata kanë të njëjtin kuptim të asaj që po ndodh. Më pas u mblodhën

njerëz të ndryshëm të dhënat do të jenë të vlefshme.

5) Pas përfundimit të mbledhjes së të dhënave, ato analizohen për të identifikuar ngjarjet

lidhjet që kanë frekuencën më të lartë të manifestimit. Kjo do t'ju lejojë të përcaktoni

prioritetet e fushave problematike brenda një procesi të caktuar biznesi për

duke dhënë theksin në punën e përmirësimit. Ndihmës i përshtatshëm

Një mjet i dobishëm për kryerjen e një analize të tillë është diagrami Pareto Diagrami Pareto

Ndërtimi i kësaj skeme bazohet në të ashtuquajturin parim Pareto, duke formuar

modeluar nga matematikani italian Vilfredo Pareto në vitet 1800. nën-

Detajet e kësaj skeme mund të gjenden gjithashtu në librin e Rolstados. Pareto ishte

i shqetësuar me shpërndarjen e pasurisë në shoqëri dhe besonte se 20% e popullsisë ishte në pushtet

përbëjnë 80% të të gjithë pasurisë. Përkthyer në gjuhën moderne të sistemeve të cilësisë, kjo

parimi është se shpesh rreth 80% e të gjitha manifestimeve të mundshme

janë për shkak të rreth 20% të të gjitha shkaqeve të mundshme. Një qasje e zgjuar për këtë

rast - filloni punën për përmirësim duke sulmuar pikërisht këto 20%

rang, të cilat zakonisht quhen "pakica vitale". Kjo është plotësisht

nuk do të thotë se 80% e mbetur e arsyeve mund të injorohen: në kohën e duhur

moment në kohë nga këto arsye, të cilat quhen “kjo më e rëndësishmja

tism” duhet trajtuar gjithashtu. Parimi Pareto përcakton prioritetet e pro-

problemet që duhen adresuar.

Vetë grafiku Pareto ofron një interpretim grafik në

formë e një shpërndarjeje të zhdrejtë të të ashtuquajturit rregulli “80/20”. Këto janë arsyet

të renditura sipas rëndësisë, sipas shpeshtësisë së shfaqjes, sipas kostos,

sipas nivelit të treguesve etj. Kur renditni shkaqet në një tabelë Pareto

më të rëndësishmit prej tyre janë caktuar në skajin e majtë të diagramit, në mënyrë që të jetë “vitale

pakicë e rëndësishme” ishte e lehtë për t'u identifikuar. Për të rritur informacionin

aktiviteti i diagramit Pareto, kurba e akumuluar e frekuencës zakonisht vizatohet në të.

Se. Një shembull i ndërtimit të një diagrami është paraqitur në Fig. 7.4.

Kur punoni me një tabelë Pareto, bëni sa më poshtë:

1). Identifikoni problemin kryesor të ngjarjes dhe shkaqet e ndryshme të mundshme të saj.

renditet. Duke marrë parasysh supozimet e bëra në këtë libër, ne do të supozojmë se

se tashmë është përzgjedhur një proces specifik që është e dëshirueshme të përmirësohet. Pra

Kështu, qëllimi i ndërtimit të një grafiku Pareto është identifikimi

arsyet kryesore të nivelit të ulët të treguesve.

2). Përcaktoni se cili tregues sasior do të përdoret kur

krahasimi i shkaqeve të mundshme. Si një tregues i tillë mund të

marrin shpeshtësinë e shfaqjes së llojeve të ndryshme të problemeve apo pasojat e tyre në territor

minierat e kostove të parave të gatshme dhe kushteve të tjera.

3). Përcaktoni periudhën kohore gjatë së cilës do të mblidhen të dhënat dhe

merrni ato. Shpesh kjo punë tashmë është përfunduar më herët kur kërkohet.

plotësimi i listave kontrolluese. Thelbi i listës së kontrollit përshkruhet në § 7.2.

4). Rregulloni shkaqet nga e majta në të djathtë përgjatë boshtit horizontal të diagramit

Pareto në rend zbritës të rëndësisë së tyre relative. Vizatoni një tabelë -

Skemat biki. Lartësia e tyre korrespondon me shkallën e rëndësisë relative të përkatëses

arsye përkatëse. 5). Shënoni vlerat absolute të marra të treguesve në vertikalën e majtë

boshti i noahut. Vini re vlerat relative të treguesve si përqindje në të djathtë

ulërima e boshtit vertikal. Vizatoni një kurbë të akumulimit të rëndësisë përgjatë majës

skajet e kolonave.

Studimi i tabelës Pareto mund t'u përgjigjet pyetjeve të tilla si: 1) “Çfarë është

paraqesin dy ose tre arsye kryesore për nivelin e ulët të treguesve të kësaj

proces? ose 2) “Sa është pjesa e kostove që i atribuohen më jetike

arsye të reja? Ky informacion mund të përdoret për veprime të tilla si:

synojnë përpjekjet për të përmirësuar procesin drejt arritjes

rezultatet e tij më të larta.

Ndërtimi i një grafiku Pareto mund të thjeshtohet nëse përdorni standardin

softuer teknik kompjuterik i destinuar për përpilimin e elektronikës

tavolina ron. Në të njëjtën kohë, ekzistojnë mjete speciale për ndërtimin e diagrameve Pareto.

softuer zirovanny. Dy programe të tilla të specializuara kompjuterike janë StatGraphics Plus Dhe ASAS/QC. Ata gjithashtu japin

aftësia e përdoruesit për të ndërtuar grafikët e kontrollit për SUP Ne gjithashtu shënojmë paketën

Softueri Memory Jogger, të cilat mund të përdoren me disa mjete

përmirësimin e cilësisë.

Përparësitë: Ju lejon të merrni informacion në lidhje me cilësitë që kontribuojnë ose pengojnë arritjen e rezultateve në punë. Promovon të kuptuarit më të mirë përmbajtjen puna.

Të metat: Disa nga informacionet e marra mund të mos përdoren gjatë krijimit të modelit, pasi një numër i incidenteve të përshkruara përfundimisht mund të rezultojnë krejtësisht jokarakteristikë të punës.

11 tetor 2012 në ora 10:58

Puna me incidente siguria e informacionit

• Siguria e informacionit

Mirëdita, i dashur habrahabr!

Unë vazhdoj të botoj artikuj nga praktika e sigurisë së informacionit.
Këtë herë do të flasim për një komponent kaq të rëndësishëm si incidentet e sigurisë. Puna me incidente do të marrë pjesën e luanit të kohës pasi të jetë vendosur regjimi i sigurisë së informacionit (dokumentet janë pranuar, instaluar dhe konfiguruar pjesa teknike, u zhvilluan trajnimet e para).

Raportimi i incidentit

Gjëja e parë që duhet të bëni është të merrni informacion në lidhje me incidentin. Kjo pikë duhet menduar në fazën e formimit të një politike sigurie dhe krijimit të prezantimeve mbi programet arsimore në sigurinë e informacionit për punonjësit.
Burimet kryesore të informacionit:

1. Helpdesk.
Si rregull (dhe kjo është një traditë e mirë), ata telefonojnë ose shkruajnë në tryezën e ndihmës së shërbimit tuaj të IT për çdo keqfunksionim, keqfunksionim ose keqfunksionim në pajisje. Prandaj, është e nevojshme që paraprakisht të "integroheni" në procesin e biznesit të ndihmës dhe të tregoni llojet e incidenteve me të cilat kërkesa do të transferohet në departamentin e sigurisë së informacionit.

2. Mesazhe direkt nga përdoruesit.
Organizoni një pikë të vetme kontakti dhe komunikoni këtë në trajnimin për sigurinë e informacionit për punonjësit. Për momentin, departamentet e sigurisë së informacionit në organizata, si rregull, nuk janë shumë të mëdha, shpesh përbëhen nga 1-2 persona. Prandaj, nuk do të jetë e vështirë të caktoni dikë që është përgjegjës për marrjen e incidenteve, madje nuk duhet të shqetësoheni me caktimin e një adrese emaili për nevojat e IS Helpdesk.

3. Incidentet e zbuluara nga stafi i sigurisë së informacionit.
Gjithçka është e thjeshtë këtu dhe nuk kërkohen lëvizje fizike për të organizuar një kanal të tillë pritjeje.

4. Regjistrimet dhe sinjalizimet e sistemit.
Konfiguro sinjalizimet në tastierën e antiviruseve, IDS, DLP dhe sistemeve të tjera të sigurisë. Është më i përshtatshëm të përdorni grumbullues që mbledhin gjithashtu të dhëna nga regjistrat e programeve dhe sistemeve të instaluara në organizatën tuaj. Vëmendje e veçantë duhet t'i kushtohet pikave të kontaktit me rrjetin e jashtëm dhe vendeve ku ruhen informacione të ndjeshme.

Megjithëse incidentet e sigurisë janë të ndryshme dhe të ndryshme, ato janë mjaft të lehta për t'u ndarë në disa kategori, të cilat janë më të lehta për t'u mbajtur statistika.

1. Zbulimi i informacionit konfidencial ose të brendshëm, ose kërcënimi për një zbulim të tillë.
Për ta bërë këtë, duhet të keni, të paktën, një listë të përditësuar të informacionit konfidencial, sistemi i punës vulosje e mediave elektronike dhe të letrës. Shembull i mirë- Modelet e dokumenteve për pothuajse të gjitha rastet, të vendosura në portalin e brendshëm të organizatës ose në depozitën e brendshme të skedarëve, si parazgjedhje janë shënuar "Vetëm për përdorim të brendshëm".
Më lejoni të sqaroj pak në lidhje me kërcënimin e zbulimit në një postim të mëparshëm kam përshkruar një situatë ku një dokument i etiketuar "Vetëm përdorim i brendshëm" ishte postuar në një sallë të përbashkët ngjitur me një organizatë tjetër. Ndoshta nuk kishte vetë zbulim (ai u postua pas përfundimit të ditës së punës dhe u vu re shumë shpejt), por fakti i kërcënimit të zbulimit është i dukshëm!

2. Qasje e paautorizuar.
Për ta bërë këtë, ju duhet të keni një listë të burimeve të mbrojtura. Domethënë ato ku ndodhet çdo informacion i ndjeshëm i organizatës, klientëve apo kontraktorëve të saj. Për më tepër, është e dëshirueshme që në këtë kategori të përfshihet jo vetëm depërtimi në një rrjet kompjuterik, por edhe aksesi i paautorizuar në ambiente.

3. Teprica e autoritetit.
Në parim, ju mund ta kombinoni këtë pikë me atë të mëparshme, por është më mirë ta theksoni atë dhe të shpjegoni pse. Qasja e paautorizuar i referohet aksesit nga persona të cilët nuk kanë asnjë akses ligjor në burimet ose mjediset e organizatës. Ky është një ndërhyrës i jashtëm pa hyrje legjitime në sistemin tuaj. Teprica e autoritetit kuptohet si akses i paautorizuar në çdo burim dhe ambient të punonjësve ligjorë të organizatës.

4. Sulmi me virus.
Në këtë rast, duhet të kuptoni sa vijon: një infeksion i vetëm i kompjuterit të një punonjësi nuk duhet të çojë në proces gjyqësor, pasi kjo mund t'i atribuohet një gabimi ose faktorit famëkeq njerëzor. Nëse një përqindje e konsiderueshme e kompjuterëve të organizatës janë të infektuar (këtu vijojmë nga numri i përgjithshëm i makinave, shpërndarja, segmentimi i tyre, etj.), Atëherë është e nevojshme të fillohet një hetim i plotë i incidentit të sigurisë me kërkimin e nevojshëm për burimet e infeksionit, shkaqet etj.

5. Kompromisi i llogarisë.
Kjo pikë i bën jehonë 3 . Në fakt, ngjarja vjen nga 3 V 5 kategori nëse gjatë hetimit të incidentit rezulton se përdoruesi në atë moment ka qenë fizikisht dhe faktikisht i paaftë për të përdorur kredencialet e tij.

Klasifikimi i incidenteve

Kjo pikë në punën me incidentet mund të trajtohet në 2 mënyra: e thjeshtë dhe komplekse.
Mënyra më e lehtë është të merrni marrëveshjen tuaj të nivelit të shërbimit të TI-së dhe ta përshtatni atë sipas nevojave tuaja.
Mënyra e vështirë: bazuar në analizën e rrezikut, identifikoni grupe incidentesh dhe/ose pasurish për të cilat zgjidhja ose eliminimi i shkaqeve të incidentit duhet të jetë i menjëhershëm.
Mënyra e thjeshtë funksionon mirë në organizata të vogla ku nuk ka shumë informacion të pronarit dhe jo sasi e madhe punonjësit. Por ia vlen të kuptohet se shërbimi i IT-së e bazon SLA-në në rreziqet e veta dhe statistikat e incidenteve. Është shumë e mundur që një printer i bllokuar me letër të jetë në tryezë drejtor i përgjithshëm do të ketë një prioritet shumë të lartë nëse kompromisi i fjalëkalimit të administratorit të bazës së të dhënave të korporatës është më i rëndësishëm për ju.

Mbledhja e dëshmive të ngjarjes

Ekziston një shkencë e posaçme e aplikuar - kriminalistika, e cila merret me çështje të mjekësisë ligjore në fushën e krimeve kompjuterike. Dhe ka një libër të mrekullueshëm nga N. N. Fedotov. “Forenzika – kriminalistika kompjuterike”. Nuk do të përshkruaj me detaje tani aspektet e mjekësisë ligjore, thjesht do të veçoj 2 pika kryesore në ruajtjen dhe sigurimin e provave që duhen respektuar.

Për dokumentet në letër, origjinali ruhet në mënyrë të sigurt me një regjistrim të personit që zbuloi dokumentin, ku u zbulua dokumenti, kur u zbulua dokumenti dhe që ishte dëshmitar i zbulimit. Çdo hetim duhet të sigurojë që origjinalet nuk janë falsifikuar
Për informacion mbi median kompjuterike: imazhet pasqyrë ose çdo media e lëvizshme, informacioni në hard disk ose memorie duhet të merret për të siguruar aksesueshmërinë. Duhet të mbahet një regjistër i të gjitha aktiviteteve gjatë procesit të kopjimit dhe procesi duhet të dëshmohet. Media dhe protokolli origjinal (nëse kjo nuk është e mundur, atëherë të paktën një imazh pasqyre ose kopje) duhet të mbahen të mbrojtura dhe të paprekura

Pas zbardhjes së ngjarjes

Pra, ngjarja ka përfunduar, pasojat janë eliminuar dhe është kryer hetim zyrtar.
Por puna nuk duhet të përfundojë me kaq.
Veprimet e mëtejshme pas incidentit:

Rivlerësimi i rreziqeve që çuan në incident
përgatitja e një liste masash mbrojtëse për të minimizuar rreziqet e identifikuara në rast të përsëritjes së incidentit
përditësimin e politikave të nevojshme, rregulloreve, rregullave të sigurisë së informacionit
të kryejë trajnime për personelin e organizatës, duke përfshirë punonjësit e IT-së, për të rritur ndërgjegjësimin për sigurinë e informacionit

Kjo do të thotë, është e nevojshme të ndërmerren të gjitha veprimet e mundshme për të minimizuar ose neutralizuar cenueshmërinë që çoi në zbatimin e një kërcënimi të sigurisë dhe, si rezultat, shfaqjen e një incidenti.

1. Mbani një regjistër incidenti, ku regjistroni kohën e zbulimit, detajet e punonjësit që zbuloi incidentin, kategorinë e incidentit, asetet e prekura, kohën e planifikuar dhe aktuale për të zgjidhur incidentin, si dhe punën e kryer për të eliminuar incidentin dhe pasojat e tij.
2. Regjistroni veprimet tuaja. Kjo është e nevojshme, para së gjithash, për veten tuaj, për të optimizuar procesin e zgjidhjes së incidentit.
3. Njoftoni punonjësit për incidentin në mënyrë që, së pari, të mos ndërhyjnë në hetimin tuaj dhe së dyti, të përjashtojnë përdorimin e aseteve të prekura gjatë hetimit.

Sigurimi i sigurisë së informacionit të biznesit Andrianov V.V.

4.1.4. Shembuj incidentesh

4.1.4. Shembuj incidentesh

Informacione të përgjithshme

Ky seksion përshkruan detaje të publikuara të disa prej incidenteve të profilit të lartë. Në të njëjtën kohë, përgjithësimi i incidenteve siguron një sërë rrethanash që karakterizojnë shumëllojshmërinë e kërcënimeve të sigurisë së informacionit nga personeli, si në aspektin e motiveve dhe kushteve, ashtu edhe në aspektin e mjeteve të përdorura. Ndër incidentet më të shpeshta, vëmë re si më poshtë:

Rrjedhja e informacionit zyrtar;

Vjedhja e klientëve dhe e biznesit të organizatës;

Sabotimi i infrastrukturës;

Mashtrimi i brendshëm;

Falsifikimi i raporteve;

Tregtimi në tregje bazuar në informacione të brendshme dhe të pronarit;

Abuzimi me autoritetin.

Shënim

Si hakmarrje për një bonus shumë të vogël, 63-vjeçari Roger Duronio (ish-administrator i sistemit në UBS Paine Webber) instaloi një "bombë logjike" në serverët e kompanisë, e cila shkatërroi të gjitha të dhënat dhe paralizoi punën e kompanisë për një kohë të gjatë.

Përshkrimi i incidentit

Duronio ishte i pakënaqur me pagën e tij prej 125,000 dollarë në vit, e cila mund të ketë qenë arsyeja e futjes së bombës logjike. Megjithatë, pika e fundit për administratorin e sistemit ishte bonusi që ai mori në shumën prej 32,000 dollarë në vend të 50,000 dollarëve të pritur. Kur zbuloi se bonusi i tij ishte shumë më i vogël nga sa priste, Duronio kërkoi që shefi i tij të rinegocionte kontratën e tij të punës me 175,000 dollarë në vit ose do të largohej nga kompania. Atij iu refuzua rritja e pagës, si dhe iu kërkua të largohej nga ndërtesa e bankës. Si hakmarrje për një trajtim të tillë, Duronio vendosi të përdorte "shpikjen" e tij të prezantuar paraprakisht, duke parashikuar një kthesë të tillë të ngjarjeve.

Duronio zbatoi "bombën logjike" nga kompjuteri i tij i shtëpisë disa muaj përpara se të merrte atë që ai e konsideronte si një bonus shumë të vogël. Bomba logjike u instalua në rreth 1500 kompjuterë në një rrjet degësh në të gjithë vendin dhe u vendos në një orë specifike - 9.30, pikërisht në kohën e fillimit të ditës bankare.

Duronio dha dorëheqjen nga UBS Paine Webber më 22 shkurt 2002 dhe më 4 mars 2002, një bombë logjike fshiu në mënyrë sekuenciale të gjithë skedarët në serverin kryesor të bazës së të dhënave qendrore dhe 2000 serverë në 400 degët e bankës, ndërsa çaktivizoi sistemin rezervë.

Gjatë gjykimit, avokati i Duronios vuri në dukje se i akuzuari nuk mund të ishte fajtori i incidentit: duke pasur parasysh pasigurinë e sistemeve IT të UBS Paine Webber, çdo punonjës tjetër mund të kishte arritur atje nën hyrjen e Duronios. Problemet me sigurinë e IT në bankë u bënë të njohura që në janar 2002: gjatë një auditimi, u zbulua se 40 persona nga shërbimi i IT mund të hynin në sistem dhe të merrnin të drejtat e administratorit duke përdorur të njëjtin fjalëkalim dhe të kuptonin se kush e bëri saktësisht atë ose ndonjë tjetër. veprim tjetër nuk ishte i mundur. Avokati akuzoi gjithashtu UBS Paine Webber dhe kompaninë @Stake, të punësuar nga banka për të hetuar incidentin, për shkatërrimin e provave të sulmit. Megjithatë, prova e pakundërshtueshme e fajit të Duronios ishin pjesët e kodit keqdashës të gjetura në kompjuterët e shtëpisë së tij dhe një kopje e printuar e kodit në dollapin e tij.

Mundësitë e Brendshme

Si një nga administratorët e sistemit të kompanisë, Duronio-s iu dha përgjegjësia dhe aksesi në të gjithë rrjetin kompjuterik UBS PaineWebber. Ai gjithashtu kishte akses në rrjet nga kompjuteri i tij i shtëpisë nëpërmjet një lidhjeje të sigurt në internet.

Arsyet

Siç u tha më herët, motivet e tij ishin paratë dhe hakmarrja. Duronio mori një pagë vjetore prej 125,000 dollarë dhe një bonus prej 32,000 dollarë, ndërsa priste 50,000 dollarë dhe kështu u hakmor për zhgënjimin e tij.

Përveç kësaj, Duronio vendosi të fitonte para nga sulmi: duke parashikuar një rënie të aksioneve të bankës për shkak të një katastrofe të IT-së, ai bëri një urdhër të së ardhmes për të shitur në mënyrë që të merrte diferencën kur norma binte. I pandehuri shpenzoi 20,000 dollarë për këtë. Megjithatë, letrat me vlerë të bankës nuk ranë dhe investimet e Duronios nuk dhanë rezultat.

Pasojat

“Bomba logjike” e vendosur nga Duronio ndaloi punën e 2000 serverëve në 400 zyra të kompanisë. Sipas menaxheres së UBS Paine Webber IT, Elvira Maria Rodriguez, ishte një katastrofë "një 10 plus në një shkallë 10". Kaosi mbretëroi në kompani, e cila mori 200 inxhinierë nga IBM për t'i eliminuar për pothuajse një ditë. Në total, rreth 400 specialistë punuan për korrigjimin e situatës, përfshirë edhe vetë shërbimin IT të bankës. Dëmi nga incidenti vlerësohet në 3.1 milionë dollarë. Tetë mijë agjentë në të gjithë vendin u detyruan të ndërpresin punën. Disa prej tyre mundën të riktheheshin në funksionimin normal pas disa ditësh, disa pas disa javësh, varësisht nga sa keq ishin prekur bazat e të dhënave të tyre dhe nëse dega e bankës kishte kopje rezervë. Në përgjithësi, operacionet bankare u rifilluan brenda pak ditësh, por disa serverë nuk u rivendosën kurrë plotësisht, kryesisht për faktin se 20% e serverëve nuk kishin pajisje rezervë. Vetëm një vit më vonë, i gjithë parku i serverëve të bankës u restaurua plotësisht përsëri.

Gjatë gjykimit të Duronios në gjykatë, ai u akuzua për akuzat e mëposhtme:

Mashtrimi i letrave me vlerë - Kjo akuzë mbart një dënim maksimal prej 10 vjet burg federal dhe një gjobë prej 1 milion dollarë;

Mashtrimi kompjuterik - Kjo akuzë mbart një dënim maksimal prej 10 vjet burg dhe një gjobë prej 250,000 dollarë.

Si rezultat i gjyqit në fund të dhjetorit 2006, Duronio u dënua me 97 muaj pa lirim me kusht.

"VimpelCom" dhe "Sherlock"

Shënim

Për qëllime fitimi, ish-punonjësit e kompanisë VimpelCom ( markë tregtare"Beeline") ofroi detaje përmes faqes së internetit bisedat telefonike operatorët celularë.

Përshkrimi i incidentit

Punonjësit e kompanisë VimpelCom (ish dhe aktual) organizuan faqen e internetit www.sherlok.ru në internet, për të cilën kompania VimpelCom mësoi në qershor 2004. Organizatorët e kësaj faqeje ofruan një shërbim - kërkimin e njerëzve me mbiemër, numrin e telefonit dhe të dhëna të tjera. Në korrik, organizatorët e faqes propozuan shërbim i ri- detajet e bisedave telefonike të operatorëve celularë. Detajet e thirrjeve janë një printim i numrave të të gjitha thirrjeve hyrëse dhe dalëse, duke treguar kohëzgjatjen e thirrjeve dhe koston e tyre, të përdorura nga operatorët, për shembull, për abonentët e faturimit. Bazuar në këto të dhëna, mund të nxjerrim një përfundim në lidhje me aktivitetet aktuale të pajtimtarit, zonën e tij të interesit dhe rrethin e njohjeve. Në njoftimin për shtyp të Drejtorisë “K” të Ministrisë së Punëve të Brendshme (në tekstin e mëtejmë Ministria e Punëve të Brendshme) sqarohet se një informacion i tillë i kushton klientit 500 dollarë.

Punonjësit e kompanisë VimpelCom, pasi zbuluan këtë faqe, mblodhën në mënyrë të pavarur prova veprimtari kriminale vendndodhja dhe lënda ia kaloi Ministrisë së Punëve të Brendshme. Punonjësit e Ministrisë së Punëve të Brendshme hapën një çështje penale dhe së bashku me kompaninë VimpelCom konstatuan identitetin e organizatorëve të këtij biznesi kriminal. Dhe më 18 tetor 2004, i dyshuari kryesor 1 u ndalua në flagrancë.

Përveç kësaj, më 26 nëntor 2004, gjashtë të dyshuarit e mbetur u arrestuan, duke përfshirë tre punonjës të shërbimit parapagues të vetë kompanisë VimpelCom. Gjatë hetimit, rezultoi se siti ishte krijuar nga një ish-student i Moskës universiteti shtetëror i cili nuk punonte në këtë kompani.

Dokumentacioni për këtë incident u bë i mundur falë vendimit të Gjykatës Kushtetuese të vitit 2003, e cila pranoi se detajet e thirrjeve përmbanin sekretin e bisedave telefonike, të mbrojtura me ligj.

Mundësitë e Brendshme

Dy nga punonjësit e VimpelCom të identifikuar mes pjesëmarrësve në incident punonin si tregtarë në kompani dhe i treti ishte një ish-punonjës dhe punonte në tregun Mitinsky në kohën e krimit.

Puna si tregtarë në vetë kompani tregon se këta punonjës kishin akses të drejtpërdrejtë në informacionin e ofruar për shitje në faqen e internetit www.sherlok.ru. Për më tepër, që nga ish punonjës Kompania tashmë po punonte në tregun Mitinsky, mund të supozohet se me kalimin e kohës ky treg mund të bëhet një nga kanalet e shpërndarjes për këtë informacion ose ndonjë informacion tjetër nga bazat e të dhënave të kompanisë VimpelCom.

Pasojat

Pasojat kryesore për VimpelCom nga ky incident mund të jenë një goditje për reputacionin e vetë kompanisë dhe humbjen e klientëve. Megjithatë, ky incident u bë publik drejtpërdrejt falë veprimeve aktive të vetë kompanisë.

Për më tepër, bërja publike e këtij informacioni mund të ketë një ndikim negativ tek klientët e VimpelCom, pasi detajet e bisedave na lejojnë të nxjerrim një përfundim në lidhje me aktivitetet aktuale të pajtimtarit, zonën e tij të interesit dhe rrethin e njohjeve.

Në mars 2005, Gjykata e Qarkut Ostankino e Moskës dënoi të dyshuarit, përfshirë tre punonjës të kompanisë VimpelCom, me gjoba të ndryshme. Kështu, organizatori i grupit u gjobit me 93,000 rubla. Sidoqoftë, funksionimi i faqes së internetit www.sherlok.ru u ndal për një kohë të pacaktuar vetëm nga 1 janari 2008.

Rrjedhja më e madhe e të dhënave personale në historinë japoneze

Shënim

Në verën e vitit 2006, ndodhi rrjedhja më e madhe e të dhënave personale në historinë e Japonisë: një punonjës i gjigantit të printimit dhe elektronikës Dai Nippon Printing vodhi një disk me informacione private të pothuajse nëntë milionë qytetarëve.

Përshkrimi i incidentit

Kompania japoneze Dai Nippon Printing, e specializuar në prodhim produktet e printimit, lejoi rrjedhjen më të madhe në historinë e vendit të saj. Hirofumi Yokoyama, një ish-punonjës i një prej kontraktorëve të kompanisë, kopjoi të dhënat personale të klientëve të kompanisë në një hard disk celular dhe e vodhi atë. Gjithsej 8.64 milionë njerëz ishin në rrezik sepse informacioni i vjedhur përfshinte emrat, adresat, numrat e telefonit dhe numrat e kartave të kreditit. Informacioni i vjedhur përfshinte informacione për klientët nga 43 kompani të ndryshme, si 1,504,857 klientë të American Home Assurance, 581,293 klientë të Aeon Co dhe 439,222 klientë të NTT Finance.

Pas vjedhjes së këtij informacioni, Hirofumi hapi tregtinë e informacionit privat në pjesë prej 100,000 regjistrimesh. Falë të ardhurave të qëndrueshme, insajderi ka lënë edhe punën e përhershme. Në momentin e arrestimit, Hirofumi kishte arritur t'i shiste të dhënat e 150,000 klientëve të firmave më të mëdha të kreditit një grupi mashtruesish të specializuar në blerjet online. Përveç kësaj, disa nga të dhënat tashmë janë përdorur për mashtrime me karta krediti.

Më shumë se gjysma e organizatave, të dhënat e klientëve të të cilave u vodhën, as nuk u paralajmëruan për rrjedhjen e informacionit.

Pasojat

Si pasojë e këtij incidenti, humbjet e qytetarëve që pësuan për shkak të mashtrimit me karta krediti, që u bë e mundur vetëm si pasojë e kësaj rrjedhjeje, arritën në disa milionë dollarë. Në total, klientët e 43 kompanive të ndryshme u prekën, duke përfshirë Toyota Motor Corp., American Home Assurance, Aeon Co dhe NTT Finance. Megjithatë, më shumë se gjysma e organizatave as që u paralajmëruan për rrjedhjen.

Në vitin 2003, Japonia miratoi Aktin e Mbrojtjes së Informacionit Personal 2003 (PIPA), por prokurorët nuk ishin në gjendje ta zbatonin atë në procedurat penale aktuale. këtë rast në fillim të vitit 2007, prokuroria dështoi të akuzonte personin e brendshëm për shkelje të PIPA-s. Ai akuzohet vetëm se ka vjedhur një hard disk me vlerë 200 dollarë.

Nuk vlerësohet. Hakeri i Zaporozhye kundër një banke ukrainase

Shënim

Një ish-administrator i sistemit të një prej bankave të mëdha në Ukrainë transferoi rreth 5 milionë hryvnia përmes bankës ku ai punonte më parë nga llogaria e doganave rajonale në llogarinë e një kompanie të falimentuar inekzistente Dnepropetrovsk.

Përshkrimi i incidentit

Karriera e tij si administrator sistemi filloi pasi ai mbaroi shkollën teknike dhe u punësua nga një nga bankat e mëdha në Ukrainë në softuer dhe mbështetje teknike. Pas ca kohësh, menaxhmenti e vuri re talentin e tij dhe vendosi që ai të ishte më i dobishëm për bankën si shef departamenti. Megjithatë, ardhja e menaxhmentit të ri në bankë solli edhe ndryshime në personel. Atij iu kërkua të lirojë përkohësisht pozicionin e tij. Së shpejti, menaxhmenti i ri filloi të formonte ekipin e tyre, por talenti i tij rezultoi i padeklaruar dhe atij iu ofrua posti inekzistent i zëvendësshefit, por në një departament tjetër. Si rezultat i ndryshimeve të tilla të personelit, ai filloi të bënte diçka krejtësisht të ndryshme nga ajo që dinte më mirë.

Administratori i sistemit nuk mund ta duronte këtë qëndrim të menaxhmentit ndaj vetes dhe u largua me vullnetin e tij të lirë. Sidoqoftë, ai ishte i përhumbur nga krenaria dhe pakënaqësia e tij ndaj menaxhmentit, përveç kësaj, ai donte të provonte se ishte më i miri në biznesin e tij dhe të kthehej në departamentin ku filloi karriera e tij.

Pas dorëheqjes, ish-administratori i sistemit vendosi të kthejë interesin e ish-drejtuesit për personin e tij duke përdorur papërsosmëritë e sistemit “Bank-Klient” i përdorur pothuajse në të gjitha bankat në Ukrainë 2 . Plani i administratorit të sistemit ishte që ai vendosi të zhvillonte programin e tij të sigurisë dhe t'ia ofronte bankës, duke u kthyer në vendin e tij të mëparshëm të punës. Zbatimi i planit konsistonte në depërtimin në sistemin bankë-klient dhe bërjen e ndryshimeve minimale në të. E gjithë llogaritja është bërë për faktin se banka do të kishte zbuluar një hakim të sistemit.

Për të depërtuar në sistemin e specifikuar, ish-administratori i sistemit ka përdorur fjalëkalime dhe kode që i ka mësuar gjatë punës me këtë sistem. Të gjitha informacionet e tjera të nevojshme për hakerim janë marrë nga faqe të ndryshme hakerash, ku janë përshkruar në detaje raste të ndryshme hakerimi. rrjetet kompjuterike, teknikat e hakerimit dhe përmbanin të gjithë softuerin e nevojshëm për hakerim.

Pasi krijoi një boshllëk në sistem, ish-administratori i sistemit depërtoi periodikisht në sistemin kompjuterik të bankës dhe linte shenja të ndryshme në të, duke u përpjekur të tërhiqte vëmendjen për faktet e hakerimit. Specialistët e bankës duhej të zbulonin hakimin dhe të jepnin alarmin, por, për habinë e tij, askush nuk e vuri re as depërtimin në sistem.

Pastaj administratori i sistemit vendosi të ndryshojë planin e tij, duke bërë rregullime në të që nuk mund të kalonin pa u vënë re. Ai vendosi të falsifikojë urdhërpagesë dhe transferoni një shumë të madhe përmes saj përmes sistemit kompjuterik të bankës. Duke përdorur një laptop dhe telefon celular me një modem të integruar, administratori i sistemit depërtoi në sistemin kompjuterik të bankës rreth 30 herë: shikoi dokumentet, llogaritë e klientëve, trafikun para të gatshme- kërkimi i klientëve të përshtatshëm. Si klientë të tillë ai zgjodhi doganat rajonale dhe një kompani të falimentuar të Dnepropetrovsk.

Pasi fitoi edhe një herë akses në sistemin e bankës, ai krijoi një urdhërpagesë në të cilën llogari personale doganat rajonale u tërhoqën dhe transferuan përmes bankës në llogarinë e një kompanie të falimentuar 5 milionë hryvnia. Për më tepër, ai me qëllim bëri disa gabime në "pagesë", të cilat nga ana tjetër duhet të kishin ndihmuar më tej të tërhiqnin vëmendjen e specialistëve të bankës. Sidoqoftë, edhe fakte të tilla nuk u vunë re nga specialistët e bankës që i shërbenin sistemit Bank-Klient dhe ata transferuan me qetësi 5 milion hryvnia në llogarinë e një kompanie të zhdukur.

Realisht, administratori i sistemit priste që fondet të mos transferoheshin, fakti i hakerimit të zbulohej para se të transferoheshin fondet, por në praktikë gjithçka doli ndryshe dhe ai u bë kriminel dhe transferta e tij e rreme u përshkallëzua në vjedhje.

Fakti i hakimit dhe vjedhjes së fondeve në një shkallë veçanërisht të madhe u zbulua vetëm pak orë pas transferimit, kur punonjësit e bankës thirrën doganën për të konfirmuar transferimin. Por ata raportuan se askush nuk kishte transferuar një shumë të tillë. Paratë u kthyen urgjentisht në bankë dhe u hap një çështje penale në zyrën e prokurorit të rajonit Zaporozhye.

Pasojat

Banka nuk ka pësuar asnjë humbje, pasi paratë i janë kthyer pronarit dhe sistemi kompjuterik ka pësuar dëme minimale, si pasojë e të cilit drejtuesit e bankës kanë refuzuar çdo pretendim ndaj ish-administratorit të sistemit.

Në vitin 2004, me dekret të Presidentit të Ukrainës, përgjegjësia penale për krimet kompjuterike u forcua: gjoba nga 600 në 1000 minimume pa taksa, burgim nga 3 në 6 vjet. Megjithatë, ish-administratori i sistemit ka kryer një krim para hyrjes në fuqi të dekretit presidencial.

Në fillim të vitit 2005, u zhvillua një provë e administratorit të sistemit. Ai u akuzua për kryerjen e një krimi sipas Pjesës 2 të nenit 361 të Kodit Penal të Ukrainës - ndërhyrje e paligjshme në funksionimin e sistemeve kompjuterike që shkakton dëm dhe sipas Pjesës 5 të nenit 185 - vjedhje e kryer në një shkallë veçanërisht të madhe. Por meqenëse menaxhmenti i bankës refuzoi të bënte ndonjë pretendim ndaj tij, akuza për vjedhje u hoq nga ai dhe pjesa 2 e nenit 361 u ndryshua në pjesën 1 - ndërhyrje e paligjshme në funksionimin e sistemeve kompjuterike.

Tregtim i pakontrolluar në bankën Societe Generale

Shënim

Më 24 janar 2008, Societe Generale njoftoi një humbje prej 4.9 miliardë eurosh për shkak të makinacioneve të tregtarit të saj Jerome Kerviel. Siç tregoi një hetim i brendshëm, për disa vite tregtari hapi pozicione mbi limitet në të ardhmen për indekset evropiane të aksioneve. Shuma totale e pozicioneve të hapura arriti në 50 miliardë euro.

Përshkrimi i incidentit

Nga korriku 2006 deri në shtator 2007, sistemi i kontrollit të brendshëm kompjuterik lëshoi ​​një paralajmërim për shkelje të mundshme 75 herë (pra sa herë Jerome Kerviel kreu transaksione të paautorizuara ose pozicionet e tij tejkaluan kufirin e lejuar). Punonjësit e departamentit të monitorimit të riskut të bankës nuk kanë kryer kontrolle të hollësishme për këto paralajmërime.

Kerviel fillimisht filloi të eksperimentonte me tregtimin e paautorizuar në vitin 2005. Më pas ai mori një pozicion të shkurtër në aksionet e Allianz, duke pritur që tregu të bjerë. Shumë shpejt tregu ra vërtet (pas sulmeve terroriste në Londër), kështu që u fituan 500 mijë eurot e para. Kerviel më pas u tha hetuesve për ndjenjat e tij që përjetoi që nga suksesi i tij i parë: "Unë tashmë dija ta mbyllja pozicionin tim dhe isha krenar për rezultatin, por në të njëjtën kohë isha i befasuar. Suksesi më bëri të vazhdoj, ishte si një top bore... Në korrik 2007, propozova të merrja një pozicion short në pritje të rënies së tregut, por nuk mora mbështetje nga menaxheri im. Parashikimi im u realizua dhe fituam, këtë herë ishte plotësisht i ligjshëm. Më pas kam vazhduar të kryej operacione të tilla në treg, qoftë me pëlqimin e eprorëve, qoftë në mungesë të kundërshtimit të tij të qartë... Më 31 dhjetor 2007, fitimi im arriti në 1.4 miliardë euro. Në atë moment nuk dija si ta deklaroja këtë në bankën time, pasi ishte një shumë shumë e madhe që nuk ishte deklaruar askund. Isha i lumtur dhe krenar, por nuk dija t'i shpjegoja menaxhmentit tim marrjen e këtyre parave dhe të mos dyshoja për kryerjen e transaksioneve të paautorizuara. Prandaj vendosa të fsheh fitimin tim dhe të kryej operacionin e kundërt fiktiv...”

Në fakt, në fillim të janarit të atij viti, Jerome Kerviel rihyri në lojë me kontrata të së ardhmes në tre indekset Euro Stoxx 50, DAX dhe FTSE, të cilat e ndihmuan atë të mposhtte tregun në fund të vitit 2007 (megjithëse ai preferoi të shkonte shkurt në koha). Sipas përllogaritjeve, në prag të 11 janarit, portofoli i tij përmbante 707,9 mijë kontrata të së ardhmes (secila me vlerë 42,4 mijë euro) në Euro Stoxx 50, 93,3 mijë Futures (192,8 mijë euro për 1 copë) në DAX dhe 24,2 mijë Futures (82,7 mijë euro). për 1 kontratë) për indeksin FTSE. Në total, pozicioni spekulativ i Kerviel ishte i barabartë me 50 miliardë euro, domethënë ishte më shumë se vlera e bankës në të cilën ai punonte.

Duke ditur kohën e çeqeve, ai hapi në momentin e duhur një pozicion mbrojtës fiktiv, të cilin e mbylli më vonë. Si rezultat, rishikuesit nuk panë kurrë një pozicion të vetëm që mund të konsiderohej i rrezikshëm. Ata nuk mund të alarmoheshin nga shumat e mëdha të transaksioneve, të cilat janë mjaft të zakonshme në tregun e indeksit të së ardhmes. Ai u zhgënjye nga transaksionet fiktive të kryera nga llogaritë e klientëve të bankave. Përdorimi i llogarive të klientëve të ndryshëm të bankave nuk ka sjellë probleme të dukshme për kontrollorët. Megjithatë, me kalimin e kohës, Kerviel filloi të përdorte të njëjtat llogari klientësh, gjë që çoi në aktivitet "jonormal" të vërejtur në këto llogari dhe, nga ana tjetër, tërhoqi vëmendjen e kontrollorëve. Ky ishte fundi i mashtrimit. Doli se partneri i Kerviel në marrëveshjen shumëmiliardë dollarëshe ishte një bankë e madhe gjermane, e cila dyshohet se konfirmoi transaksionin astronomik me email. Megjithatë, konfirmimi elektronik ngriti dyshime tek inspektorët dhe u krijua një komision pranë Societe Generale për verifikimin e tyre. Më 19 janar, në përgjigje të një kërkese, banka gjermane nuk e njohu këtë transaksion, pas së cilës tregtari pranoi të rrëfente.

Kur u bë e mundur të zbulohej përmasat astronomike të pozicionit spekulativ, CEO dhe kryetari i bordit të drejtorëve të Societe Generale, Daniel Bouton, njoftoi synimin e tij për të mbyllur pozicionin e rrezikshëm të hapur nga Kerviel. Kjo zgjati dy ditë dhe rezultoi me humbje prej 4.9 miliardë eurosh.

Mundësitë e Brendshme

Jerome Kerviel punoi për pesë vjet në të ashtuquajturën back office të bankës, domethënë në një departament që nuk përfundon drejtpërdrejt asnjë transaksion. Merret vetëm me kontabilitetin, ekzekutimin dhe regjistrimin e transaksioneve dhe monitoron tregtarët. Ky aktivitet na mundësoi të kuptojmë veçoritë e sistemeve të kontrollit në bankë.

Në 2005, Kerviel u promovua. Ai u bë një tregtar i vërtetë. Në përgjegjësitë e menjëhershme i ri përfshinte operacione bazë për të minimizuar rreziqet. Duke punuar në tregun e të ardhmes për indekset evropiane të aksioneve, Jerome Kerviel duhej të monitoronte se si po ndryshonte portofoli i investimeve të bankës. Dhe detyra e tij kryesore, siç shpjegoi një përfaqësues i Societe Generale, ishte të zvogëlonte rreziqet duke luajtur në drejtim të kundërt: "Përafërsisht, duke parë që banka po vinte baste në të kuqe, ai duhej të vinte bast për të zezën." Si të gjithë tregtarët e vegjël, Kerviel kishte një kufi që nuk mund ta kalonte, ky monitorohej prej tij ish-kolegët në zyrën e pasme. Societe Generale kishte disa shtresa mbrojtjeje, për shembull tregtarët mund të hapnin pozicione vetëm nga kompjuteri i tyre i punës. Të gjitha të dhënat për hapjen e pozicioneve u transmetuan automatikisht në kohë reale në zyrën e pasme. Por, siç thonë ata, gjuetari më i mirë është një ish-pylltar. Dhe banka bëri një gabim të pafalshëm duke e vënë ish-pylltarin në pozitën e një gjahtari. Jérôme Kerviel, i cili kishte pothuajse pesë vjet përvojë në monitorimin e tregtarëve, nuk e pati të vështirë ta anashkalonte këtë sistem. Ai dinte fjalëkalimet e të tjerëve, dinte kur kryheshin kontrollet në bankë, ishte i njohur mirë teknologjia e informacionit.

Arsyet

Nëse Kerviel ishte i përfshirë në mashtrim, kjo nuk ishte për qëllimin e pasurimit personal. Këtë e thonë avokatët e tij dhe këtë e pranojnë edhe përfaqësuesit e bankës, duke i quajtur veprimet e Kerviel-it të paarsyeshme. Vetë Kerviel thotë se ai veproi vetëm në interes të bankës dhe vetëm donte të provonte talentin e tij si tregtar.

Pasojat

Në fund të vitit 2007, aktivitetet e saj i sollën bankës rreth 2 miliardë euro fitim. Në çdo rast, këtë e thotë vetë Kerviel, i cili pretendon se drejtuesit e bankës ndoshta e dinin se çfarë po bënte, por preferoi të mbyllte një sy për sa kohë ai ishte fitimprurës.

Mbyllja e pozicionit të rrezikshëm të hapur nga Kerviel çoi në humbje prej 4.9 miliardë eurosh.

Në maj 2008, Daniel Bouton u largua nga posti i CEO i Societe Generale dhe u zëvendësua në këtë pozicion nga Frederic Oudea. Një vit më vonë, ai u detyrua të jepte dorëheqjen nga posti i tij si kryetar i bordit drejtues të bankës. Arsyeja e largimit të tij ishte kritika e mprehtë nga shtypi: Bouton u akuzua për faktin se drejtuesit e lartë të bankës nën kontrollin e tij inkurajuan transaksione financiare të rrezikshme të kryera nga punonjësit e bankës.

Me gjithë mbështetjen e bordit të drejtorëve, presioni ndaj z. Bouton u rrit. Aksionerët e bankës dhe shumë politikanë francezë kërkuan dorëheqjen e tij. Presidenti francez Nicolas Sarkozy gjithashtu i bëri thirrje Daniel Bouton të jepte dorëheqjen pasi u bë e ditur se një vit e gjysmë para skandalit, sistemi kompjuterik i kontrollit të brendshëm të Societe Generale lëshoi ​​një paralajmërim 75 herë, pra çdo herë që Jerome Kerviel kryente transaksione të mundshme të paautorizuara .

Menjëherë pasi u zbuluan humbjet, Societe Generale krijoi një komision të posaçëm për të hetuar veprimet e tregtarit, i cili përfshinte anëtarë të pavarur të bordit të drejtorëve të bankës dhe auditorë PricewaterhouseCoopers. Komisioni arriti në përfundimin se sistemi i kontrollit të brendshëm të bankës nuk ishte mjaft efektiv. Kjo rezultoi që banka të mos ishte në gjendje të parandalonte një mashtrim kaq të madh. Raporti thotë se “stafi i bankës nuk kreu kontrolle sistematike” të aktiviteteve të tregtarit dhe vetë banka nuk kishte “një sistem kontrolli që mund të parandalonte mashtrimin”.

Në raportin mbi rezultatet e auditimit të tregtarit thuhet se pas rezultateve të hetimit, është marrë një vendim për të “forcuar ndjeshëm procedurën e mbikëqyrjes së brendshme të aktiviteteve të punonjësve të Societe Generale”. Kjo do të bëhet përmes një organizimi më të rreptë të punës së divizioneve të ndryshme të bankës dhe koordinimit të ndërveprimit të tyre. Gjithashtu do të merren masa për gjurmimin dhe personalizimin e operacioneve tregtare të punonjësve të bankës duke “forcuar sistemin e sigurisë së IT dhe duke zhvilluar zgjidhje të teknologjisë së lartë për identifikimin personal (biometrik).

Nga libri Sigurimi i sigurisë së informacionit të biznesit autori Andrianov V.V.

4.2.2. Tipologjia e incidenteve

Nga libri Pensioni: procedura e llogaritjes dhe e regjistrimit autor Minaeva Lyubov Nikolaevna

4.3.8. Hetimi i incidentit Një incident në të cilin është përfshirë një punonjës i një organizate është një emergjencë për shumicën e organizatave. Prandaj, mënyra e organizimit të një hetimi varet shumë nga situata mbizotëruese. kulturën e korporatës organizatave. Por ju mund të sigurt

Nga libri Tregtia Ditore në Tregun Forex. Strategjitë e fitimit nga Lyn Ketty

2.5. Shembuj Le të shqyrtojmë disa opsione për caktimin e pensioneve të punës në rast të transferimit të dokumenteve në organet territoriale të fondit pensional me postë: Shembulli 1 Një kërkesë për caktimin e një pensioni pune pleqërie iu dërgua organit territorial të fondit.

Nga libri Praktika e Menaxhimit burimet njerëzore autor Armstrong Michael

3.5. Shembuj Shembulli 1 Përvoja e punës përbëhet nga periudha pune nga 15 mars 1966 deri më 23 maj 1967; nga 15.09.1970 deri më 21.05.1987; nga 01.01.1989 deri më 31.12.1989; nga 04.09.1991 deri më 14.07.1996; nga 15.07.1996 deri më 12.07.1998 dhe shërbimi ushtarak nga 27.05.1967 deri më 09.06.1969

Nga libri i autorit

4.4. Shembuj Shembulli 1 Inxhinieri Sergeev A.P., i lindur në 1950, aplikoi për pension pleqërie në mars 2010. Në vitin 2010, ai mbushi 60 vjeç. Kohëzgjatja totale e shërbimit për vlerësimin e të drejtave pensionale që nga 1 janari 2002 është 32 vjet, 5 muaj, 18 ditë, duke përfshirë 30 vjet para 1991.

Nga libri i autorit

6.3. Shembuj Shembulli 1 Menaxheri i shitjeve V.N kontrata e punës nga 01/01/2010 1 janar 2013 vdes në moshën 25 vjeçare. Në të njëjtën kohë ai ka ende prindër të aftë për punë, një grua të aftë dhe një vajzë 3 vjeç. Në këtë rast, e drejta për të marrë punë

Nga libri i autorit

7.4. Shembuj Shembulli 1 Menaxheri Vasiliev R. S., 60 vjeç. Përvoja totale e punës libri i punës për vlerësimin e të drejtave pensionale me 01.01.2002 është 40 vjet. Të ardhurat mesatare mujore për 2000-2001, sipas të dhënave të personalizuara të kontabilitetit, janë 4000 rubla. Ne do të llogarisim dhe krahasojmë shumat e pensioneve sipas

Nga libri i autorit

8.3. Shembuj Shembulli 1 Një pensionist merr një pension invaliditeti të grupit I. Nga data 20 maj deri më 5 qershor 2009, ai iu nënshtrua një riekzaminimi në BMSE dhe u njoh si invalid i grupit III më 3 qershor 2009. Grupi i aftësisë së kufizuar në këtë rast u ul. Pjesa bazë subjekt pensioni

Nga libri i autorit

10.4. Shembuj Shembulli 1 Vdekja e një pensionisti ka ndodhur më 28 janar 2009. E veja e pensionistit ka aplikuar për pension në shkurt të vitit 2009. Bashkëjetesa e gruas së ve me pensionistin në ditën e vdekjes nuk është krijuar në këtë rast organi territorial i fondi pranoi

Nga libri i autorit

14.7. Shembuj Shembulli 1 Koshkina V.N., e cila ishte në varësi të bashkëshortit të saj të ndjerë, arriti moshën 55 vjeçare 3 muaj pas vdekjes së tij. Kam aplikuar për pension pas 1 viti nga data e vdekjes së bashkëshortit tim

Nga libri i autorit

17.5. Shembuj Shembulli 1 U sipërmarrës individual Katër persona punojnë me kontratë pune: Moroz K.V (l. 1978), Svetlova T. G. (l. 1968), Leonova T. N. (l. 1956) dhe Komarov S. N. (l. 1952). Le të supozojmë çdo muaj pagat secila prej tyre është 7000 rubla.

Nga libri i autorit

Shembuj Le të shohim disa shembuj se si funksionon kjo strategji: 1. Grafiku 15-minutësh i EUR/USD në Fig. 8.8. Sipas rregullave të kësaj strategjie, shohim se EUR/USD ra dhe tregtohej nën mesataren lëvizëse 20-ditore. Çmimet vazhduan të bien, duke lëvizur drejt 1,2800, që është

Nga libri i autorit

Shembuj Le të studiojmë disa shembuj.1. Në Fig. Figura 8.22 tregon një grafik 15-minutësh të USD/CAD. Gama e përgjithshme e kanalit është afërsisht 30 pikë. Në përputhje me strategjinë tonë, ne vendosim porosi hyrjeje 10 pikë sipër dhe poshtë kanalit, pra në 1.2395 dhe 1.2349. Urdhri i blerjes u ekzekutua

Nga libri i autorit

Shembuj Le të shohim disa shembuj të kësaj strategjie në veprim.1. Në Fig. Figura 8.25 tregon grafikun ditor të EUR/USD. Më 27 tetor 2004, mesataret lëvizëse EUR/USD formuan një renditje korrekte të qëndrueshme. Ne hapim një pozicion pesë qirinj pas fillimit të formimit në 1.2820.

Përshëndetje të gjithë Habrazhitëve,
Shumë shpesh, si një shërbim procesi, dëgjoni një pyetje shumë të njohur nga punonjësit e departamenteve të mëdha dhe të vogla të IT: cili është ndryshimi midis një kërkese shërbimi dhe një incidenti?

Diskutimet mbi këtë temë janë po aq të vjetra sa të gjitha metodologjitë e menaxhimit të TI-së të marra së bashku, megjithatë, le të kthehemi te burimet parësore.

Çfarë na tregon ITIL (përkthimi zyrtar i fjalorit sipas versionit të tretë):

Kërkesa për shërbim- Kërkesa e një përdoruesi për informacion, ose konsultim, ose ndryshim standard, akses në shërbimin IT.

Incidenti- ndërprerje e paplanifikuar e një shërbimi IT ose ulje e cilësisë së një shërbimi IT.

Si zakonisht, metodologjia nuk gërmohet në thellësi të gjërave dhe me të vërtetë nuk i pëlqen t'u përgjigjet pyetjeve thelbësore nga punonjësit e çdo Tavoline Shërbimi që klasifikon kërkesat e përdoruesve. Ndërkohë pyetje të tilla ka plot, ja disa shembuj:

1) Thirrje kristomatike nga një përdorues që kërkon rivendosjen e fjalëkalimit - si ta klasifikoni atë si një kërkesë shërbimi ose një incident? Apo ndoshta si një incident i sigurisë së informacionit?

2) Një telefonatë nga një përdorues, emaili i korporatës së të cilit nuk funksionon. Një analizë e shpejtë e kërkesës sugjeron që përdoruesi duhet të kryejë konfigurimin fillestar të klientit të postës elektronike. Megjithatë, nga këndvështrimi i tij, ky është një incident, sepse... shërbimi nuk është i disponueshëm dhe askush nuk e njoftoi atë se "vetë posta nuk do të fluturojë"

Eshtë e panevojshme të thuhet se klasifikimi parësor është shumë i rëndësishëm, pasi ai përcakton të gjithë ciklin e mëvonshëm të jetës së ankesës, përfshirë. dhe afatet.

Kuptimi im për këtë çështje vjen në një çështje vlerësimi ndërprerjet e shërbimit për konsumatorin përfundimtar, dhe kështu:

Incidenti- kjo është, në shumicën e rasteve, një ndërprerje ose ndërprerje e pjesshme e një shërbimi IT që i është ofruar më parë përdoruesit në një modalitet të miratuar (shërbimi është i disponueshëm 24/7 ose 5/8).

Shembull: Kryekontabilisti i kompanisë humbi papritur aksesin në sistem pasqyrat financiare. Nga njëra anë, ofrimi i aksesit është një kërkesë klasike e shërbimit, por në këtë rast ka një ndërprerje të qartë të shërbimit dhe, si pasojë, degradim të pjesshëm të procesit të biznesit.

Kërkesa për shërbim- kjo është një kërkesë nga një përdorues që është i interesuar të lidhet shërbim shtesë, ose përmirësimin e funksionalitetit të shërbimeve ekzistuese.

Shembull: Një përdorues veçanërisht kurioz u përpoq të hapte një nga modulet e të njëjtit sistem raportimi financiar, por mori një mesazh gabimi. Nga këndvështrimi i tij ky është një incident, pasi ai nuk ia arriti qëllimit të dëshiruar dhe nuk mori informacionin që kërkonte, por nga pikëpamja. e përshkruar më sipër është një kërkesë klasike shërbimi për akses, që kërkon miratim dhe kryhet sipas një procedure standarde brenda një afati kohor të rënë dakord.

Në të njëjtën kohë, ne nuk duhet të harrojmë për shumëllojshmërinë e rasteve të veçanta që përgjithësisht janë të vështira për t'u klasifikuar, këndvështrimi i përshkruar më sipër nuk pretendon të jetë një dogmë, por vetëm përpiqet të ndihmojë në minimizimin e numrit të kërkesave të klasifikuara gabimisht dhe të përmirësojë; koha e përgjithshme e përgjigjes së TI-së ndaj nevojave të biznesit.