Procesul de management al incidentelor

Din păcate, lumea nu este perfectă. Acest lucru este valabil și pentru serviciile IT. Pot apărea eșecuri în furnizarea serviciilor IT: serviciul poate deveni indisponibil, lucrul cu erori, se poate obține acces neautorizat la informații etc. Acestea. pot apărea abateri negative de la prestarea normală a serviciului. În ITIL, aceste abateri se numesc incidente.

Un incident este o întrerupere neplanificată sau o reducere a calității unui serviciu IT. Eșecul unui element de configurare care nu a afectat încă serviciul este, de asemenea, un incident, cum ar fi defecțiunea unei unități dintr-o matrice oglindă.

În unele cazuri, incidentul poate trece neobservat de utilizatori, în timp ce în altele poate avea un impact financiar, reputațional și de altă natură negativ semnificativ asupra afacerii. Dacă incidentul a avut loc, atunci este necesar să se minimizeze impactul negativ al acestuia.

Cum să o facă? Într-un caz - pentru a "repara" cât mai repede posibil, în celălalt - pentru a restabili cele mai importante funcții cât mai curând posibil, în al treilea - pentru a aplica o soluție, etc.

O soluție alternativă este reducerea sau eliminarea impactului unui incident sau al unei probleme pentru care nu este disponibilă în prezent o soluție completă.

De regulă, activitățile departamentelor IT legate de rezolvarea incidentelor au un impact semnificativ asupra percepției IT de către utilizatori în ansamblu. Pentru a gestiona eficient aceste activități, trebuie stabilit un curs adecvat de acțiune. În conformitate cu recomandările ITIL, ar trebui construit un proces de management al incidentelor pentru aceasta.

Managementul incidentelor este procesul responsabil de gestionarea ciclului de viață al tuturor incidentelor. Managementul incidentelor asigură că impactul asupra afacerii este minimizat și serviciul este restabilit la funcționarea normală cât mai repede posibil.

Ca parte a atingerii obiectivului, sarcinile procesului de management al incidentelor sunt:

• Asigurarea utilizării metodelor și procedurilor standard pentru un răspuns eficient și prompt, analiză, documentare, management continuu și raportare în cursul rezolvării incidentelor.
• Creșterea transparenței și a comunicării la rezolvarea incidentelor dintre business și IT.
• Îmbunătățiți percepția afacerii despre IT printr-o abordare profesională a soluționării incidentelor.
• Alinierea priorităților de rezolvare a incidentelor cu prioritățile de afaceri.
• Menținerea satisfacției utilizatorilor cu privire la calitatea serviciilor IT.

Activități ale procesului de management al incidentelor

Incidentele pot avea loc în orice parte a infrastructurii. Adesea sunt raportate de utilizatori, dar pot fi detectate și de angajații IT, dar pe baza informațiilor din sistemele de monitorizare.

În majoritatea cazurilor, incidentele sunt înregistrate de Service Desk, unde sunt raportate. Toate incidentele trebuie înregistrate imediat după primirea unui raport din următoarele motive:

• este dificil să înregistrați cu acuratețe informații despre un incident dacă acest lucru nu se face imediat;
• monitorizarea progresului lucrărilor pentru rezolvarea incidentului este posibilă numai dacă incidentul este înregistrat;
• incidentele înregistrate ajută la diagnosticarea noilor incidente;
• Managementul problemelor poate folosi incidentele raportate atunci când lucrează pentru a găsi cauzele principale;
• este mai ușor de determinat gradul de impact dacă toate mesajele (apelurile) sunt înregistrate;
• fără înregistrarea incidentelor, este imposibil să se controleze implementarea acordurilor (SLA);
• Înregistrarea imediată a incidentelor previne situațiile în care fie mai multe persoane lucrează la același incident, fie nimeni nu face nimic pentru a rezolva incidentul.

Toate informațiile relevante despre incident trebuie înregistrate și disponibile pentru echipele de asistență.

Un exemplu de informații despre incident:

Când un incident este înregistrat inițial, acesta trebuie clasificat.

O categorie este un grup numit de obiecte care au ceva în comun. Categoriile sunt folosite pentru a grupa obiecte similare. De exemplu, tipurile de costuri sunt folosite pentru a grupa costuri de același tip, categorii de incidente - de același tip de incidente, tipuri CI - de același tip de elemente de configurare.

Clasificarea corectă a incidentelor ajută la redirecționarea imediată a acestora către grupul potrivit și analiza incidentelor în diferite secțiuni și, de asemenea, formează baza pentru găsirea cauzelor incidentelor și eliminarea acestora ca parte a procesului de management al problemelor.

Fiecărui incident i se atribuie o anumită prioritate.

Prioritatea se bazează pe impact și urgență și este utilizată pentru a determina timpul necesar de procesare.

Urgența este o măsură a cât de repede, din momentul în care apare un incident, va avea un impact semnificativ asupra afacerii.

Gradul de influență (impact) - o măsură a impactului incidentului asupra procesului de afaceri.

Deci, de fapt, prioritatea este un număr bazat pe urgență (cât de repede trebuie remediat) și impact (cât de multe daune vor fi făcute dacă nu sunt reparate rapid). Prioritate = Urgență x Gradul de impact. Pe baza prioritatii se stabileste ordinea in care se rezolva incidentele.

Prioritatea este stabilită pe baza următorilor factori:

• Urgenţă
• Impact asupra afacerilor
• Risc pentru viață sau pentru membre
• Numărul de servicii afectate
• Pierderi financiare
• Impactul asupra reputației afacerii
• Impactul asupra conformării cu legile și alte reglementări etc.

Ținând cont de prioritatea stabilită și acordurile existente (SLA), utilizatorul este informat despre timpul maxim estimat pentru rezolvarea incidentului (termen limită). Aceste date sunt și ele fixe. Incidentului i se atribuie un număr unic și utilizatorului este informat despre numărul incidentului pentru identificarea corectă a acestuia în apelurile ulterioare.

Direct la solicitarea utilizatorului, specialistii Service Desk trebuie sa efectueze o diagnoza preliminara a incidentului pentru a obtine informatiile necesare pentru a determina cauza incidentului, daca este posibil, precum si pentru categorizarea corecta si trecerea la urmatoarea linie de suport. Dacă soluția incidentului este de competența angajatului Service Desk, atunci aceasta poate fi rezolvată imediat. Service Desk direcționează incidentele care nu au o soluție gata făcută sau depășesc competența angajatului care lucrează cu acesta, către următorul nivel de echipă de suport cu mai multă experiență și cunoștințe. Acest grup investighează și rezolvă incidentul sau îl transmite la următorul nivel de asistență.

În procesul de rezolvare a unui incident, diverși specialiști pot actualiza fișa de înregistrare despre acesta, modificând starea curentă, informații despre acțiunile efectuate, revizuirea clasificării și actualizarea orei și codului angajatului care a lucrat.

În cele mai multe cazuri, Service Desk este responsabil pentru monitorizarea progresului soluției, în calitate de „proprietar” al tuturor incidentelor. Acest serviciu ar trebui, de asemenea, să informeze utilizatorul despre starea incidentului. Feedback-ul utilizatorului poate fi adecvat după o schimbare de stare, cum ar fi redirecționarea unui incident către următoarea linie de asistență, o modificare a timpului estimat de rezolvare, escaladare etc. În timpul monitorizării, escaladarea funcțională către alte echipe de asistență sau escaladarea ierarhică pentru a lua decizii de management este posibil.

Escalarea este o activitate care vizează obținerea de resurse suplimentare atunci când este necesar pentru a atinge obiectivele de nivel de serviciu sau pentru a îndeplini așteptările clienților. Escaladarea poate fi necesară ca parte a oricărui proces de gestionare a serviciilor IT, dar este cel mai frecvent asociată cu gestionarea incidentelor, gestionarea problemelor și gestionarea reclamațiilor clienților. Există două tipuri de escaladare: escaladarea funcțională și escaladarea ierarhică.

După finalizarea cu succes a analizei și soluționării incidentului, angajatul înregistrează informații despre soluția aplicată. Dacă la un anumit moment în timp nu este posibilă rezolvarea completă a incidentului, impactul acestuia, dacă este posibil, ar trebui redus prin aplicarea unei soluții alternative. În cel mai rău caz, dacă nu se găsește o soluție, incidentul rămâne deschis.

După implementarea unei soluții care satisface utilizatorul, echipa de asistență transmite incidentul înapoi către Service Desk. Serviciul de service contactează angajatul care a raportat incidentul pentru a primi confirmarea că problema a fost rezolvată cu succes. Dacă el confirmă acest lucru, atunci incidentul poate fi închis; în caz contrar, procesul se reia la nivelul corespunzător. Când închideți un incident, trebuie să actualizați categoria finală, prioritatea, serviciile afectate de incident și CI care a cauzat defecțiunea.

Politici și principii de bază ale procesului de management al incidentelor

Politicile procesului de management al incidentelor trebuie urmate pentru a asigura eficacitatea și eficiența procesului și pot include următoarele aspecte:

• Bună coordonare între utilizatori și respondenții la incident
• Incidentele trebuie rezolvate în intervalul de timp convenit cu afacerea
• Satisfacția utilizatorilor trebuie să fie asigurată în toate etapele rezolvării incidentelor
• Activitățile de gestionare a incidentelor ar trebui să fie aliniate cu nivelurile de servicii și obiectivele de asistență bazate pe nevoile reale de afaceri
• Toate incidentele sunt gestionate și datele lor sunt stocate într-un singur sistem de management
• Toate incidentele trebuie să aibă o schemă standard de clasificare care să se potrivească cu procesele de afaceri ale întreprinderii.
• Înregistrările incidentelor trebuie verificate în mod regulat pentru introducerea corectă și clasificarea corectă.
• Toate înregistrările incidentelor ar trebui, în măsura posibilului, să aibă un format comun și un set de câmpuri de informații.
• Ar trebui să existe un set comun de criterii convenite cu afacerea pentru a prioritiza și escalada incidentele

În cele ce urmează sunt descrise principiile de bază care ar trebui luate în considerare la implementarea managementului incidentelor.

Scale de timp - pentru toate etapele procesării incidentului, trebuie convenite intervale de timp (vor diferi în funcție de nivelul de prioritate al incidentului). Toate grupurile de sprijin ar trebui să fie pe deplin conștiente de aceste intervale de timp.

Multe incidente nu sunt noi - sunt legate de ceva ce s-a mai întâmplat deja și se poate întâmpla din nou. Din acest motiv, ar fi înțelept să se definească în prealabil modele de incidente „standard” și să le aplice atunci când apar incidente relevante.

Un model de incident este o modalitate predefinită de a gestiona un anumit tip de incident.

Un model de incident poate include următoarele aspecte:

• O secvență predefinită de acțiuni pentru a gestiona un anumit tip de incident
• Responsabilitate predeterminată
• Măsuri de precauție înainte de rezolvarea incidentului
• Perioadele de timp și procedurile de escaladare
• Dovada activității (înregistrări, jurnale)

Incidentele majore sunt identificate ca parte a procesului de management al incidentelor.

Un incident semnificativ cauzează o pierdere semnificativă afacerii și ar trebui să aibă proceduri separate de manipulare.

Incidentele trebuie urmărite pe tot parcursul ciclului lor de viață pentru a se asigura că sunt gestionate corespunzător și raportate cu privire la starea incidentelor. Într-un sistem de management al incidentelor, codurile de stare pot fi legate de incidente pentru a indica unde se află acestea în raport cu ciclul de viață. Exemple dintre acestea ar putea include:

Starea incidentului indică starea incidentului în procesare. Exemple de stări sunt:

• nou;
• admis;
• planificat;
• numit;
• activ;
• amânat;
• permis;
• închis.

Valorile procesului de management al incidentelor

Pentru a gestiona și a evalua eficacitatea procesului de management al incidentelor, precum și pentru a oferi feedback altor procese de management, ITIL sugerează utilizarea următorilor indicatori cheie (CSF și KPI):

• CSF Rezolvarea rapidă a incidentelor, minimizând impactul acestora asupra afacerii
• KPI Timpul mediu necesar pentru a rezolva un incident
• KPI Distribuția incidentelor în funcție de stare
• KPI Procentul de incidente rezolvate prin suportul de primă linie
• KPI Procentul de incidente rezolvate de la distanță
• KPI Numărul de incidente rezolvate care nu au afectat afacerea
• Asistență pentru calitatea serviciilor IT CSF
• KPI Numărul total de incidente (benchmark)
• Dimensiunea cozii KPI Backlog per serviciu
• KPI Numărul și procentul de incidente majore per serviciu
• Asistență pentru satisfacția utilizatorilor CSF
• KPI Scorul mediu al sondajului realizat de utilizatori/clienți
• KPI Procentul de satisfacție a răspunsului în comparație cu numărul total de participanți la sondaj
• CSF Creșterea transparenței și a comunicării în rezolvarea incidentelor între business și personalul de suport IT
• KPI Numărul mediu de apeluri către biroul de asistență sau alte contacte cu utilizatorii despre incidente care au fost deja notificate
• KPI Numărul de reclamații și probleme privind conținutul și calitatea comunicațiilor la rezolvarea incidentelor
• CSF Alinierea priorităților activității de gestionare a incidentelor cu prioritățile de afaceri
• KPI Procentul de incidente rezolvate fără a încălca obiectivele SLA
• KPI Cost mediu pe incident
• CSF Asigurarea că metodele și procedurile standard sunt utilizate atunci când se confruntă cu incidente
• KPI Numărul și procentul de incidente atribuite greșit
• KPI Numărul și procentul incidentelor clasificate greșit
• KPI Numărul și procentul de incidente gestionate de angajații Service Desk
• KPI Numărul și procentul de incidente legate de modificări și lansări

Riscuri și dificultăți

La implementarea managementului incidentelor, trebuie luate în considerare următoarele riscuri potențiale și complexități:

• Necesitatea detectării timpurii a incidentelor - va fi necesară configurarea instrumentelor de management (monitorizare) a evenimentelor, precum și instruirea utilizatorilor în informarea cu privire la incidente
• Necesitatea înregistrării totale a incidentelor
• Necesitatea implementării unui sistem de management automatizat adecvat și a asigurării integrării acestuia cu diverse sisteme de management IT (de exemplu, CMS)
• Necesitatea unei disponibilitati ridicate a unui singur punct de contact
• Necesitatea de a se asigura că procesul este urmat și de a identifica ocolirile procesului - dacă utilizatorii remediază ei înșiși erorile emergente sau contactează specialiștii direct fără a urma procedurile stabilite, organizația IT nu va primi informații despre nivelul de serviciu efectiv furnizat, numărul de erori și multe altele. Mai Mult. De asemenea, rapoartele de management nu vor reflecta în mod adecvat situația.
• Lipsa resurselor în tratarea incidentelor, supraîncărcarea cu incidente și amânarea „pentru mai târziu” - cu o creștere neașteptată a numărului de incidente, este posibil să nu existe timp suficient pentru înregistrarea corectă, deoarece înainte de sfârșitul introducerii informațiilor despre incident de la unul utilizator, devine necesar să se servească următorul. În acest caz, este posibil ca introducerea descrierilor incidentelor să nu fie suficient de precisă, iar procedurile de atribuire a incidentelor pentru sprijinirea cadavrelor nu vor fi efectuate corespunzător. Ca urmare, soluțiile sunt de proastă calitate și volumul de muncă crește și mai mult. În cazurile în care numărul de incidente deschise începe să crească rapid, alocarea de urgență a resurselor suplimentare în cadrul organizației poate preveni supraîncărcarea personalului.
• Lipsa catalogului de servicii și a acordurilor de nivel de servicii (SLA) - Dacă serviciile și produsele acceptate nu sunt bine definite, atunci poate fi dificil pentru cei implicați în gestionarea incidentelor să refuze în mod justificat asistența pentru utilizatori.
• Lipsa angajamentului față de abordarea procesului din partea managementului și a personalului - gestionarea incidentelor folosind abordarea procesului necesită de obicei o schimbare a culturii și un nivel mai ridicat de responsabilitate pentru munca lor din partea personalului. Acest lucru poate provoca o rezistență serioasă în cadrul organizației. Gestionarea eficientă a incidentelor necesită ca angajații să înțeleagă și să se angajeze cu adevărat în abordarea procesului, nu doar în participarea.

Valoarea afacerii

Prin implementarea unui proces de management al incidentelor în conformitate cu recomandările ITIL și rezolvarea tuturor dificultăților care pot apărea în timpul implementării, se poate obține următoarea valoare pentru afacerea în ansamblu:

• Capacitatea de a reduce munca neplanificată și costurile pentru afaceri și IT cauzate de incidente
• Capacitatea de a detecta și rezolva incidente, reducând timpul de nefuncționare și crescând disponibilitatea serviciilor de afaceri
• Capacitatea de a aloca resurse IT în funcție de prioritatea lor de afaceri
• Capacitatea de a iniția îmbunătățirea serviciilor pe baza cunoașterii naturii incidentelor
• Capacitatea de a identifica nevoile de formare suplimentară a personalului

Procesul de management al incidentelor este semnificativ „vizibil” pentru afacere și vă permite să vedeți rezultatele relativ rapid după implementarea acestuia. Prin urmare, managementul incidentelor este adesea unul dintre primele procese implementate în tranziția către o organizație de management IT bazată pe procese. Un beneficiu suplimentar al acestui lucru este faptul că managementul incidentelor vă permite să evidențiați alte domenii ale managementului IT care necesită atenție - asigurându-vă astfel că resursele necesare sunt alocate pentru implementarea altor procese de management IT.

În timp, poate fi necesară schimbarea infrastructurii IT. Acest lucru poate fi cauzat de o serie de motive - nevoia de a remedia o problemă, dorința de a îmbunătăți calitatea serviciilor IT, o infrastructură îmbătrânită sau o modificare a legislației.

Experiența arată că dacă schimbări nu sunt controlate corespunzător, incidente pot apărea adesea ca urmare a implementării lor: eșecuri în prestarea normală a serviciilor. Motivele unor astfel de incidente pot fi diverse: neglijența angajaților, lipsa resurselor, pregătirea insuficientă, analiza deficitară a impactului schimbării, testarea imperfectă etc. Numărul de incidente poate crește, fiecare dintre ele va necesita acțiuni urgente, care la rândul lor pot duce la apariția de noi incidente. Planificarea zilnică nu reușește adesea să se adapteze la volumul de muncă în creștere.

Schimbare - adăugarea, modificarea sau eliminarea oricărui lucru care ar putea afecta serviciile IT. Acest cadru ar trebui să includă toate modificările aduse arhitecturilor, proceselor, instrumentelor, metricilor și documentației, precum și modificările aduse serviciilor IT și ale altor elemente de configurare.

O serie de procese de tranziție a serviciilor sunt responsabile pentru asigurarea controlului schimbărilor în ITIL: Managementul schimbărilor, Managementul activelor și configurației serviciului și Managementul lansării și implementării.

Managementul schimbărilor este procesul responsabil de gestionarea ciclului de viață al tuturor modificărilor, astfel încât schimbările benefice să poată fi implementate cu întreruperi minime ale serviciilor IT.

Ca parte a atingerii obiectivului, obiectivele procesului de management al schimbării sunt:

• Răspundeți la cerințele de afaceri în schimbare ale clienților, maximizând valoarea afacerii și reducând incidentele, eșecurile și reluarea
• Răspundeți la solicitările de schimbare din partea companiei și IT pentru a vă asigura că serviciile răspund nevoilor afacerii
• Asigurați-vă că toate modificările sunt înregistrate, evaluate, autorizate, prioritizate, planificate, testate, implementate, documentate și revizuite într-o manieră controlată
• Asigurați-vă că toate modificările elementelor de configurare sunt înregistrate în sistemul de management al configurației (CMS)
• Optimizați riscurile de afaceri

Sfera de aplicare a procesului de management al schimbărilor include modificări ale infrastructurii IT, proceselor, instrumentelor, metricilor și documentației, precum și modificări ale serviciilor IT și ale altor elemente de configurare.

Activități de management al schimbării

Figura prezintă o diagramă generală a procesului de management al schimbării. Pentru a asigura controlul modificărilor, toate modificările trebuie să fie înregistrate. Dacă trebuie făcută o modificare în cadrul unui proces, trebuie depusă o cerere de modificare (RFC).

O cerere de modificare este o propunere oficială de a face o schimbare. Solicitarea de modificare include detaliile modificării propuse și poate fi scrisă pe hârtie sau în format electronic. Termenul „cerere de modificare” este adesea folosit greșit pentru a însemna „modificare înregistrare” sau „schimbare” în sine.

În cadrul procesului de management al schimbărilor ITIL, există trei tipuri de modificări:

O modificare standard este o modificare preautorizată care prezintă un risc scăzut, relativ comună și urmează o procedură sau o instrucțiune de lucru. De exemplu, resetarea unei parole sau furnizarea unui nou angajat cu echipament standard. RFC-urile nu sunt obligate să implementeze modificări standard, ele sunt înregistrate și urmărite folosind un alt mecanism, cum ar fi cererile de servicii.

O schimbare de urgență este o modificare care trebuie implementată cât mai repede posibil, cum ar fi pentru a rezolva un incident major sau pentru a instala o actualizare de securitate. Procesul de management al schimbării oferă de obicei o procedură specifică pentru managementul schimbărilor în situații de urgență.

O schimbare normală este o schimbare care nu este urgentă sau standard. Schimbările normale sunt gestionate prin pași specifici în procesul de management al schimbărilor.

Astfel, dacă o modificare se încadrează în categoria standard, atunci aceasta ar trebui gestionată ca parte a procesului de gestionare a cererii de servicii. Indiferent dacă o anumită modificare este standard sau normală, este stabilit pentru fiecare organizație în mod independent. Pentru schimbările de urgență nu sunt utilizate procedurile obișnuite, deoarece resursele necesare sunt asigurate imediat.

Următorul este un exemplu de informații care pot fi incluse în cererile de modificare (RFC):

• solicita numarul de identificare;
• problema/numărul de eroare cunoscut (dacă există) asociat cu cererea;
• descrierea și definirea elementelor de configurare corespunzătoare;
• motivul modificării, inclusiv justificarea și rezultatul economic așteptat;
• versiunea actuală și nouă a elementului de configurare care este schimbat;
• numele, adresa și numărul de telefon ale persoanei care face cererea;
• data aplicării;
• evaluarea prealabilă a resurselor și timpului necesar;
• etc.

O cerere de modificare este creată de un inițiator, care poate fi o persoană sau un grup de persoane. Dacă este necesară o modificare semnificativă, poate fi necesară o propunere de modificare.

Propunere de schimbare - Un document care conține o descriere la nivel înalt a unui serviciu potențial sau a unei schimbări semnificative, un caz de afaceri asociat și un program de implementare așteptat. Propunerile de modificare sunt de obicei create ca parte a procesului de gestionare a portofoliului de servicii și transmise procesului de gestionare a modificărilor pentru autorizare. Ca parte a procesului de management al schimbării, se evaluează impactul potențial asupra altor servicii, resurse partajate și planul general de schimbare.

Toate cererile de modificare primite trebuie să fie înregistrate și trebuie creată o înregistrare de modificare pentru fiecare modificare.

Înregistrare modificare - o înregistrare care conține informații detaliate despre modificare. Fiecare înregistrare de modificare documentează ciclul de viață al unei singure modificări. Se creează o înregistrare de modificare pentru fiecare cerere de modificare primită, chiar dacă ulterior este respinsă.

După depunerea unei cereri de modificare (RFC), Change Management efectuează o verificare inițială pentru a vedea dacă vreuna dintre solicitări este neclară, ilogică, impracticabilă sau inutilă. Astfel de cereri sunt respinse cu explicarea motivelor. Angajatului care face cererea ar trebui să i se ofere întotdeauna posibilitatea de a-și apăra cererea.

Pentru a evalua schimbarea, ITIL sugerează să răspunzi la 7 întrebări (7 „R-uri”):

• Cine este inițiatorul? (RAISED) (CINE A RISULTAT schimbarea?)
• Care este motivul? (MOTIVUL) (Care este MOTIVUL schimbării?)
• Ce rezultat se cere? (RETURNAREA) (Ce este RETURNUL cerut de la modificare?)
• Care sunt riscurile asociate cu schimbarea? (RISCURI) (Care sunt RISCURILE implicate în schimbare?)
• Ce resurse sunt necesare pentru a face schimbarea? (RESURSE) (Ce RESURSE sunt necesare pentru a realiza schimbarea?)
• Cine este responsabil pentru construirea, testarea și implementarea schimbării? (RESPONSABIL) (Cine este RESPONSABIL pentru construirea, testarea și implementarea schimbării?)
• Care este relația dintre aceasta și alte schimbări? (RELAȚIA) (Care este RELAȚIA dintre această schimbare și alte modificări?)

Când o cerere de modificare (RFC) este acceptată pentru procesare, înregistrarea modificării include informațiile necesare procesării ulterioare a modificării.

Următoarele informații pot fi adăugate în înregistrare ulterior:

• prioritate atribuită;
• evaluarea impactului și implicațiile costurilor;
• categorie;
• recomandări din partea managerului procesului de management al schimbării;
• data și ora la care a fost autorizată modificarea;
• data programată a evenimentului;
• planifică să revină la starea inițială;
• cerințe de suport;
• schimbarea planului;
• informații despre dezvoltator și angajații responsabili de implementarea schimbării;
• data și ora reală a modificării;
• data evaluării rezultatelor;
• rezultatele testelor și problemele găsite;
• motivele respingerii cererii (dacă este necesar);
• evaluarea rezultatelor.

La primirea unei cereri de modificare (RFC), prioritatea și categoria acesteia sunt determinate. Prioritatea indică cât de importantă este această solicitare în comparație cu altele. Aceasta, la rândul său, este determinată de urgența și gradul de impact.

Un exemplu de sistem de codificare cu prioritate:

• Prioritate scăzută - modificarea este de dorit, dar implementarea poate fi amânată până la un moment mai convenabil (de exemplu, până la următoarea ediție sau întreținere programată).
• Prioritate normală - fără urgență și impact mare, dar schimbarea nu ar trebui amânată.
• Prioritate mare - Modificarea se referă la o eroare gravă care afectează un număr de utilizatori sau o nouă eroare atipică care afectează un grup mare de utilizatori sau legată de alte probleme urgente.
• Cea mai mare prioritate - o cerere de schimbare (RFC) se referă la o problemă care are un impact semnificativ asupra unui serviciu critic pentru client. Modificările cu această prioritate sunt clasificate drept „de urgență”.

• Impact scăzut - O schimbare care necesită puțină muncă de făcut.
• Impact semnificativ - O schimbare care necesită efort semnificativ și are un impact semnificativ asupra serviciilor IT. Aceste modificări sunt discutate într-un Consiliu de schimbare (CAB) pentru a determina efortul necesar (resurse, etc.) și impactul potențial.
• Cel mai înalt grad de impact este schimbarea care necesită un efort semnificativ. managerul de proces trebuie să obțină mai întâi autorizația de a face o modificare la conducerea IT sau la comitetul de conducere IT, după care modificarea este transmisă comisiei de modificare (CAB).

Change Board - Un grup de persoane care ajută la evaluarea, prioritizarea, autorizarea și programarea modificărilor. Tabloul de schimbare include de obicei reprezentanți ai furnizorului de servicii IT, companiei și terțe părți (cum ar fi contractorii).

Aceste coduri pot fi reprezentate în numere, de exemplu: scăzut = 1 / mare = 3

Majoritatea modificărilor se încadrează în primele două categorii. Pe baza evaluării impactului schimbării, nivelul de autorizare a schimbării (autoritatea de modificare) ar trebui determinat, de exemplu, așa cum se arată în figură.

Pe lângă clasificare, trebuie identificate și echipele implicate în lucrul la soluția tehnică și serviciile afectate de modificare.

Dacă o modificare este aprobată de autoritățile competente, modificările aprobate sunt comunicate tehnicienilor corespunzători care vor dezvolta și implementa modificările. Ca parte a procesului de management al schimbării, implementarea este coordonată. Dezvoltarea, testarea și implementarea directă sunt efectuate ca parte a procesului de management al realismului și implementării. Implementarea modificării are loc după aprobarea rezultatelor testelor ca parte a procesului de management al schimbării.

Ca parte a procesului de management al schimbărilor, se menține un program de modificări.

Program de modificare - Un document care listează toate modificările aprobate și datele planificate pentru implementarea lor, precum și datele aproximative pentru implementarea modificărilor ulterioare.

Membrii Comitetului pentru schimbare (CAB) oferă sfaturi cu privire la modul de planificare a schimbării, deoarece disponibilitatea personalului, resursele, costurile, diferitele aspecte ale serviciilor implicate și contribuțiile clienților trebuie să fie luate în considerare. Consiliul pentru schimbare (CAB) servește ca organism consultativ și se întrunește în mod regulat. Informațiile privind planificarea schimbărilor ar trebui să fie distribuite cu mult înainte de ședința consiliului de schimbare. Documentația și informațiile relevante cu privire la punctele de pe ordinea de zi ar trebui, de asemenea, să fie distribuite înainte de reuniune.

Ordinea de zi a reuniunii consiliului de modificare ar trebui să includă o serie de puncte permanente, inclusiv:

• Modificări nereușite sau neautorizate
• Cererile de modificări (RFC) transmise membrilor Consiliului de modificare în ordinea priorității
• Solicitările de modificări (RFC) examinate de consiliul de modificare
• Planificarea schimbării și actualizarea programului de schimbare
• Evaluări ale modificărilor efectuate
• Procesul de management al schimbărilor, completările și modificările proceselor
• Realizări de proces și beneficii de afaceri prin procesul de management al schimbării
• Schimbări în curs și schimbări în curs
• Programarea cererilor de modificare pentru a fi luate în considerare la Consiliul Următoarea Schimbare
• Verificați modificările neautorizate detectate de procesul de gestionare a configurației și a activelor de serviciu

Ca parte a schemei generale de implementare a modificării, ar trebui dezvoltată o procedură de revenire la starea inițială în cazul în care modificarea nu atinge rezultatul dorit. Managementul schimbării nu ar trebui să aprobe implementarea unei modificări în absența unei proceduri de check-in.

Este necesar să se evalueze modificările efectuate, cu posibila excepție a modificărilor standard. Dacă este necesar, comisia de schimbare (CAB) decide asupra acțiunilor ulterioare. Ar trebui luate în considerare următoarele întrebări:

• Schimbarea și-a atins obiectivele?
• Sunt utilizatorii și clienții mulțumiți?
• Nu au existat efecte secundare?
• Au fost folosite resursele pentru a implementa schimbarea conform planificării?
• Schimbarea a fost implementată la timp și fără depășirea costurilor?
• Planul de implementare a funcționat corect?
• Planul de recuperare a funcționat corect dacă a fost necesar?
• etc.

Dacă modificarea are succes, cererea de modificare (RFC) poate fi închisă. Acest lucru are loc în timpul etapei de evaluare a rezultatelor implementării (PIR). Dacă schimbarea eșuează, procesul se reia de unde a eșuat folosind noua abordare. Uneori este mai bine să reveniți și să creați o cerere de modificare nouă sau modificată (RFC). Continuarea cu o schimbare eșuată înrăutățește adesea situația.

Evaluarea impactului implementării (PIR) este o revizuire efectuată după ce o schimbare sau un proiect a fost implementat. Evaluarea implementării determină succesul unei schimbări sau al unui proiect și identifică oportunitățile de îmbunătățire.

În funcție de natura schimbării, evaluarea poate fi efectuată fie după câteva zile, fie după câteva luni. De exemplu, o schimbare a unui computer personal utilizat zilnic poate fi evaluată în câteva zile, dar o schimbare a unui sistem o dată pe săptămână poate fi făcută în doar trei luni.

Efectuarea de modificări de urgență

Indiferent cât de bine este planificarea, pot exista modificări care necesită cea mai mare prioritate. Schimbările de urgență sunt foarte importante pentru companie și ar trebui implementate cât mai curând posibil. Acestea necesită proceduri separate pentru procesarea urgentă, dar cu control general din procesul de management al schimbării. În cazul unei astfel de situații, se poate organiza o reuniune a Comitetului pentru schimbări de urgență (eCAB).

Emergency Change Board (eCAB) - Un grup de persoane din consiliul de schimbare care iau decizii cu privire la schimbarea de urgență. Decizia privind componența membrilor consiliului pentru modificări urgente se poate lua direct la organizarea ședinței. Necesitatea participării este determinată în funcție de natura schimbării urgente.

Dacă nu există timp pentru aceasta sau dacă cererea a venit după programul de lucru, trebuie să existe o modalitate alternativă de a obține autorizația de modificare. Nu trebuie să fie neapărat o întâlnire față în față, poate fi folosit un apel conferință.

Politici și principii de bază ale procesului de management al schimbării

Politicile procesului de management al schimbării trebuie urmate pentru a asigura eficacitatea și eficiența procesului și pot include următoarele:

• Inadmisibilitatea absolută a modificărilor neautorizate, crearea unei culturi a schimbării
• Alinierea managementului schimbării cu procesele de management al schimbării și proiectele clienților
• Clasificarea modificărilor, de exemplu modificări inovatoare, exploratorii, preventive, corective
• Determinarea responsabilității pentru schimbări în toate etapele ciclului de viață al serviciului
• Separarea responsabilitatilor pentru management
• Creați un singur punct de responsabilitate pentru schimbări pentru a reduce șansa de schimbări conflictuale și riscul de eșec în mediul de producție

Măsuri de proces de management al schimbărilor

Pentru a gestiona și a evalua eficacitatea procesului de management al schimbării, precum și pentru a oferi feedback altor procese de management, ITIL sugerează utilizarea următorilor indicatori cheie:

• Procentul de modificări care au satisfăcut cerințele clienților
• Beneficiul modificării, exprimat ca „valoarea îmbunătățirilor aduse” + „impactul negativ evitat” în comparație cu costul modificării
• Reducerea întreruperilor serviciului, a defectelor și a reluării cauzate de specificații inexacte sau de evaluarea impactului insuficientă
• Reducerea numărului de modificări neautorizate
• Coadă redusă de cereri de modificare, rata de schimbare neplanificată și remedieri rapide
• Reducerea numărului de modificări care necesită recuperare
• Reducerea numărului de modificări nereușite
• Timp mediu de execuție în funcție de urgență/prioritate/tip
• Numărul de incidente legate de schimbare
• Schimbați acuratețea estimării

Valoarea afacerii

Prin implementarea unui proces de management al schimbării în conformitate cu recomandările ITIL și rezolvarea tuturor dificultăților care pot apărea în timpul implementării, se poate obține următoarea valoare pentru afacerea în ansamblu:

• Prioritizează și răspunde solicitărilor de modificare din partea afacerilor și clienților
• Implementarea modificărilor care îndeplinesc cerințele convenite pentru servicii este eficientă din punct de vedere al costurilor
• Reducerea numărului de modificări nereușite care duc la întreruperi ale serviciului, defecte și reluări
• Implementarea modificărilor în conformitate cu intervalul de timp determinat de afacere
• Urmăriți schimbările din timpul ciclului de viață al serviciului și al activelor clienților săi
• O estimare mai bună a calității, timpului și costului modificărilor
• Evaluarea riscurilor asociate cu modificările serviciului (punerea în funcțiune sau dezafectarea)
• Creșterea productivității personalului prin reducerea la minimum a numărului de modificări neplanificate sau „urgente” și, ca urmare, creșterea disponibilității serviciilor
• Timp mediu redus de recuperare prin implementarea mai rapidă și cu succes a modificărilor corective
• Menține comunicarea cu procesul de schimbare a afacerii pentru a identifica oportunitățile de îmbunătățire a afacerii

Ați dori ca serviciile oferite să fie de înaltă calitate? Cred ca da. Una dintre sarcinile principale ale ITSM, și ITIL în special, este de a oferi servicii IT de calitate.

Managementul serviciilor IT (ITSM) este implementarea și managementul unor servicii IT de calitate care răspund nevoilor afacerii.

Nu întotdeauna converge opinia furnizorilor de servicii IT și a clienților cu privire la calitatea serviciilor.

Calitatea este capacitatea unui produs, serviciu sau proces de a oferi valoarea așteptată de consumator. De exemplu, calitatea unei componente poate fi considerată înaltă dacă performanța acesteia corespunde așteptărilor și oferă fiabilitatea necesară.

Cele de mai sus reprezintă definiția calității conform ITIL. Acestea. daca dorim sa oferim servicii de calitate, este necesar ca acestea sa corespunda asteptarilor clientului.

După cum se spune: „Nu poți gestiona ceea ce nu poți măsura”. Astfel, pentru a asigura furnizarea unor servicii de calitate, este necesar mai întâi să clarificăm așteptările clientului față de serviciile IT, să cădem de acord asupra lor, eventual să le limitezi într-un fel, de exemplu, dacă cerința clientului este nerealistă, și să le prezentăm în o formă măsurabilă. Apoi, rămâne să ne asigurăm că parametrii actuali ai serviciului îndeplinesc așteptările clientului și să confirmăm acest lucru prin furnizarea de rapoarte adecvate.

Potrivit ITIL, procesul de management al nivelului de servicii, care este vital, este responsabil pentru acordul și documentarea obiectivelor și responsabilităților nivelului de serviciu în acordul de nivel de serviciu (SLA) și cerințele nivelului de serviciu (SLR) pentru fiecare serviciu și activitățile IT asociate. fiecare organizație furnizor de servicii IT.

Managementul nivelului de servicii este procesul responsabil de negocierea și negocierea acordurilor fezabile privind nivelul de servicii și de asigurarea îndeplinirii acestora. Managementul nivelului de servicii este responsabil pentru asigurarea faptului că procesele de management al serviciilor IT, acordurile de nivel operațional și contractele externe îndeplinesc obiectivele de nivel de serviciu convenite. Service Level Management monitorizează și raportează nivelurile de servicii, efectuează evaluări regulate ale serviciilor cu clienții și identifică îmbunătățirile necesare.

Un acord de nivel de servicii (SLA) este un acord între un furnizor de servicii IT și un client. Acordul de nivel de servicii descrie serviciul IT, documentează obiectivele nivelului de serviciu, specifică domeniile de responsabilitate ale părților - furnizorul de servicii IT și clientul. Un singur SLA poate acoperi mai multe servicii IT sau mai mulți clienți.

Cerința de nivel de serviciu (SLR) este o cerință a clientului pentru un serviciu IT. Cerințele de nivel de serviciu se bazează pe obiectivele de afaceri și sunt utilizate pentru a negocia și a conveni asupra țintelor de nivel de serviciu.

Prin formarea obiectivelor nivelului de serviciu, managementul nivelului de serviciu stabilește cerințele și parametrii de performanță pentru o serie de alte procese ITIL operaționale și tactice, cum ar fi: managementul incidentelor, managementul cererilor de servicii, managementul problemelor, managementul schimbărilor, managementul versiunilor, managementul disponibilității, etc.

Ținta de nivel de serviciu - Angajamente stabilite într-un acord privind nivelul de serviciu. Țintele de nivel de serviciu se bazează pe cerințele nivelului de serviciu și sunt necesare pentru a se asigura că un serviciu IT îndeplinește obiectivele de afaceri. Țintele de nivel de serviciu ar trebui să fie SMART și se bazează de obicei pe indicatori cheie de performanță.

Dacă aceste obiective privind nivelul de servicii se potrivesc și reflectă cu exactitate cerințele de afaceri, atunci serviciul furnizat de furnizorii de servicii va fi în conformitate cu cerințele de afaceri și va îndeplini așteptările clienților și utilizatorilor pentru calitatea serviciilor. Dacă obiectivele nu răspund nevoilor afacerii, atunci performanța furnizorilor de servicii și nivelurile de servicii nu vor îndeplini așteptările de afaceri și pot apărea probleme. Service Level Agreement - Un nivel de asigurare sau asigurare cu privire la nivelul de calitate al serviciului furnizat de furnizorul de servicii pentru fiecare serviciu furnizat de companie.

Managementul nivelului de servicii este procesul care leagă furnizorul de servicii IT și clientul. Acest proces are următoarele sarcini:

• Definiți, documentați, conveniți, monitorizați, raportați și evaluați nivelul serviciilor IT furnizate
• Mentine si imbunatateste relatiile si comunicatiile cu afacerile si clientii
• Asigurați-vă că există obiective precise și măsurabile pentru toate serviciile IT
• Monitorizați și îmbunătățiți satisfacția clienților cu calitatea serviciilor
• Asigurați claritatea și lipsa de ambiguitate a așteptărilor la nivel de serviciu de la IT și clienți
• Asigurați-vă că îmbunătățirile proactive ale nivelului de servicii sunt implementate acolo unde este justificat și posibil.

Managementul nivelului de servicii ar trebui să asigure comunicarea și comunicarea constantă a managerilor organizațiilor clienților și ai afacerilor. Acest lucru ar trebui să ofere afacerii un sentiment despre furnizorul de servicii și furnizorul de servicii IT al afacerii.

Sfera de aplicare a procesului de management al nivelului de servicii ar trebui să includă:

• Organizarea relatiilor cu afacerile
• Discutarea și convenirea asupra cerințelor și obiectivelor actuale, documentarea și menținerea SLA-urilor pentru serviciile furnizate
• Discutarea și convenirea asupra cerințelor și obiectivelor, documentarea și menținerea SLR-urilor pentru serviciile noi și modificate planificate.
• Dezvoltați și mențineți acorduri la nivel operațional (OLA) pentru a sprijini obiectivele SLA.
• Evaluarea si alinierea la obiectivele SLA a tuturor contractelor externe (UC) - impreuna cu managementul furnizorilor.
• Prevenirea eșecurilor, diminuarea riscurilor și implementarea îmbunătățirilor serviciilor funcționează împreună cu alte procese.
• Raportarea și evaluarea tuturor serviciilor și analiza oricăror abateri de la obiectivele SLA.
• Inițiază și coordonează Planul de îmbunătățire a serviciilor (SIP).

Un acord de nivel operațional (OLA) este un acord între un furnizor de servicii IT și o altă parte a aceleiași organizații.

Un contract de bază (UC) este un acord între un furnizor de servicii IT și o terță parte. Terțul furnizează bunuri sau servicii care sprijină furnizarea de servicii IT către client. Contractul extern definește domeniul de aplicare și responsabilitățile necesare pentru atingerea obiectivelor de nivel de serviciu convenite într-unul sau mai multe acorduri de nivel de serviciu.

Un plan de îmbunătățire a serviciilor (SIP) este un plan formal pentru implementarea îmbunătățirilor unui proces sau serviciu IT.

Activități ale procesului de management al nivelului de serviciu

Figura prezintă o diagramă generală a procesului de management al nivelului de servicii.

Pe măsură ce întreprinderile devin tot mai dependente de serviciile IT, cererea de servicii IT de înaltă calitate crește. După cum s-a definit mai sus, calitatea serviciului este determinată de așteptările clientului, precum și de gestionarea continuă a acestor așteptări, de stabilitatea serviciului și de acceptabilitatea nivelului de cost. Prin urmare, cea mai bună modalitate de a asigura un nivel adecvat de calitate este să discutați această problemă cu clientul însuși.

Cerințele clienților trebuie să fie prezentate în termeni măsurabili, astfel încât să poată fi utilizate în dezvoltarea și monitorizarea serviciilor IT. Dacă valorile nu sunt convenite cu clientul, atunci nu se va putea verifica modul în care serviciile corespund acordurilor încheiate.

Primul pas pentru a ajunge la un acord asupra serviciilor IT actuale sau viitoare ar trebui să fie identificarea și definirea nevoilor clienților sub forma cerințelor de nivel de serviciu (SLR). Pe lângă realizarea acestei activități chiar la începutul acestui proces, se recomandă să o faceți în mod regulat la cererea clientului sau la inițiativa organizației IT însăși și să acoperiți atât serviciile noi, cât și cele existente.

Definiția inițială a ceea ce ar trebui să fie inclus în cerințele de nivel de serviciu și acordurile de nivel de serviciu este o sarcină foarte dificilă. Ar trebui luate în considerare capacitățile și limitările tuturor proceselor în legătură cu măsurabilitatea și realizabilitatea anumitor obiective de serviciu.

Dacă există vreo îndoială cu privire la realizabilitatea obiectivelor serviciului solicitat de afacere, atunci obiectivele corespunzătoare pot fi incluse în acordul pilot pentru monitorizare și evaluare în perioada de garanție a controlului. Acest lucru va ajuta la obținerea statisticilor necesare și la efectuarea corecțiilor necesare.

În timp ce multe organizații caută să documenteze serviciile pe care le furnizează în primul rând prin încheierea unor acorduri adecvate privind nivelul de servicii, acordul asupra cerințelor de nivel de serviciu pentru noile servicii dezvoltate sau achiziționate este, de asemenea, o sarcină foarte importantă.

Cerințele de nivel de serviciu ar trebui să fie o parte integrantă a criteriilor de proiectare a serviciului, care includ și specificații funcționale. Aceștia ar trebui să definească criteriile de testare și de rulare pentru diferitele etape de proiectare și dezvoltare sau achiziție încă din primele etape de proiectare. Cerințele de nivel de serviciu vor fi rafinate progresiv la fiecare etapă a ciclului de viață, devenind un SLA pilot în faza inițială de suport. Un proiect de acord privind nivelul de serviciu trebuie semnat și formalizat înainte ca serviciul să fie pus în funcțiune și utilizat.

Experiența arată că adesea clienții înșiși nu își pot defini clar așteptările, ei pur și simplu presupun că unele servicii le vor fi furnizate fără acorduri specifice. Clientul poate avea nevoie de ajutor pentru înțelegerea și formularea cerințelor, în special în ceea ce privește capacitatea, securitatea, disponibilitatea și continuitatea. Fiți pregătiți pentru faptul că cerințele inițiale nu vor fi convenite și aprobate imediat. Poate fi nevoie de mai multe iterații în discuția despre cerințe înainte de a ajunge la un echilibru acceptabil între dorințe și capacități. Aceste iterații pot necesita o reproiectare a soluției de serviciu.

Trebuie remarcat faptul că pot fi necesare resurse suplimentare pentru a sprijini noile servicii. Există adesea o așteptare că personalul deja supraîncărcat va gestiona în mod magic volumul de muncă suplimentar generat de noile servicii.

Folosind proiectul de acord ca bază, puteți negocia cu clienții sau reprezentanții acestora pentru a finaliza domeniul de aplicare al acordurilor de nivel de serviciu și obiectivele inițiale ale nivelului de serviciu și cu furnizorii pentru a vă asigura că aceste obiective sunt realizabile.

Managementul nivelului de servicii ar trebui să conceapă o structură adecvată pentru acordurile de nivel de serviciu pentru a se asigura că toate serviciile și toți clienții sunt acoperiți în măsura în care trebuie să fie acoperiți de organizație. Există o serie de structuri posibile, inclusiv următoarele:

• acorduri de nivel de serviciu bazate pe un singur serviciu;
• acorduri de nivel de servicii bazate pe client;
• acorduri de nivel de servicii pe mai multe niveluri.

SLA bazate pe un singur serviciu este atunci când un acord de nivel de serviciu afectează un serviciu pentru toți clienții acelui serviciu. De exemplu, se poate încheia un Acord privind nivelul de servicii pentru un serviciu de e-mail, care afectează toți clienții serviciului respectiv. Cu toate acestea, pot apărea dificultăți dacă există diferențe în cerințele diferiților clienți pentru același serviciu sau dacă caracteristicile infrastructurii înseamnă că sunt inevitabile niveluri diferite de servicii.

De exemplu: personalul de la sediul central poate comunica folosind o rețea LAN rapidă, în timp ce birourile locale trebuie să fie utilizate de o linie WAN lentă. În astfel de cazuri, obiective separate pot fi prevăzute într-un singur acord. Cu toate acestea, atâta timp cât este furnizat un nivel de serviciu comun în toate domeniile afacerii, cum ar fi pentru un serviciu de e-mail, SLA-urile bazate pe un singur serviciu pot fi un exemplu de abordare eficientă. Pot exista mai multe niveluri de servicii într-un singur acord, cum ar fi Aur, Argint sau Bronz.

Acorduri de nivel de servicii bazate pe clienți - un acord cu un grup individual de clienți care acoperă toate serviciile pe care le utilizează. De exemplu, acordurile pot fi ajunse prin acoperirea departamentului financiar al unei organizații cu sisteme financiare, sisteme contabile, sisteme de decontare, sisteme contabile, sisteme de achiziții și orice alte sisteme IT pe care le utilizează. Clienții preferă adesea astfel de acorduri, deoarece toate cerințele lor sunt apoi acoperite de un singur document. De regulă, este suficientă o singură semnătură de la client, ceea ce simplifică coordonarea.

Combinarea oricăror variante ale structurii este posibilă cu condiția să nu existe duplicări.

Unele organizații folosesc o structură SLA pe niveluri. Poate include, de exemplu, trei niveluri:

• nivelul corporativ acoperă toate problemele generale de management al nivelului de servicii aplicabile tuturor clienților din organizație, de regulă, aceste secțiuni nu necesită revizuire frecventă;
• nivelul clienților descrie caracteristicile furnizării de servicii către anumiți clienți sau grupuri de unități de afaceri, caracteristice tuturor serviciilor oferite acestora;
• nivelul de serviciu descrie specificul serviciilor individuale furnizate unui anumit client sau grup de clienți.

Această structură permite ca dimensiunea cunoștințelor nivelului de serviciu să rămână în limite gestionabile, previne dublarea inutilă și reduce nevoia de actualizări frecvente. Totuși, acest lucru implică un efort suplimentar pentru a menține integritatea legăturilor din catalogul de servicii și din sistemul de management al configurației.

SLA-urile pe niveluri măresc gestionabilitatea și reduc duplicarea documentației în cadrul unei organizații. Aceasta înseamnă că actualizările au loc numai atunci când sunt necesare. În cadrul unei organizații, denumirile nivelurilor pot fi schimbate, de exemplu: corporativ, departament și serviciu sau grup, zonă de afaceri și serviciu.

Trebuie să vă asigurați că administrarea SLA-urilor pe mai multe niveluri este controlată, deoarece orice modificare introdusă va avea impact asupra altor niveluri. Acest lucru se aplică oricăror modificări aduse SLA-ului corporativ - acestea trebuie comunicate la alte niveluri. Administrarea SLA-urilor pe mai multe niveluri este complexă, dar este mai ușor decât administrarea unui număr mare de SLA care nu sunt organizate într-o astfel de ierarhie.

Multe organizații consideră că este necesar să utilizeze standarde și/sau acorduri șablon care sunt utilizate ca bază pentru pregătirea unor acorduri specifice privind nivelul de servicii. Astfel de șabloane pot fi folosite pentru a elabora proiecte de acorduri.

Dezvoltarea standardelor și modelelor asigură că toate acordurile sunt dezvoltate în mod consecvent, ceea ce, la rândul său, facilitează utilizarea, gestionarea și funcționarea lor ulterioară.

Definirea rolurilor și responsabilităților face parte din acordul privind nivelul de servicii. Există trei perspective de luat în considerare - furnizorul IT, clientul IT și utilizatorul real.

Formularea acordului trebuie să fie clară și concisă și să nu lase loc de ambiguitate. De regulă, acordurile nu trebuie să fie scrise în terminologie juridică, iar limbajul simplu ajută la înțelegerea comună. Este utilă implicarea unor persoane independente pentru corectarea finală care nu au fost implicate în elaborarea proiectelor de acorduri.

Este important ca obiectivele documentate și convenite să fie clare, specifice și lipsite de ambiguitate, deoarece oferă baza relației și asigurării calității serviciului furnizat.

SLA-urile nu ar trebui să includă cerințe a căror furnizare viitoare nu poate fi monitorizată și măsurată la un nivel convenit. Importanța acestui lucru nu poate fi subliniată prea mult, deoarece includerea articolelor care nu pot fi monitorizate eficient duce aproape întotdeauna la dispute și la o posibilă pierdere a încrederii din partea clientului. Multe organizații au învățat acest lucru din greșelile lor și, ca urmare, au primit costuri uriașe atât din punct de vedere financiar, cât și după propria imagine. Este imperativ identificarea circumstanțelor care împiedică implementarea acordurilor și a acțiunilor în cazul apariției unor astfel de circumstanțe.

Capacitățile de monitorizare existente ar trebui evaluate și, dacă este necesar, actualizate. În mod ideal, acest lucru ar trebui făcut înainte sau în același timp cu proiectarea acordului de nivel de serviciu, ceea ce va ajuta la utilizarea monitorizării în aprobarea obiectivelor propuse.

Este esențial ca monitorizarea să se potrivească cu percepția clientului asupra serviciului. Din păcate, acest lucru este adesea foarte greu de realizat. De exemplu, monitorizarea componentelor individuale, cum ar fi o rețea sau un server, nu garantează că serviciul va fi disponibil clientului așa cum se așteaptă. Clientul se îngrijorează adesea doar de serviciul pe care nu îl poate primi, deși eșecul poate viza alte servicii. O imagine completă nu poate fi obținută fără monitorizarea tuturor componentelor și a serviciului în ansamblu, iar acest lucru este dificil și costisitor. În consecință, utilizatorii ar trebui să fie conștienți de faptul că ar trebui să raporteze imediat incidentele, în special incidentele legate de performanță, pentru a sprijini activitatea furnizorului de monitorizare.

Există o serie de parametri importanți care nu pot fi măsurați cu ajutorul instrumentelor de monitorizare, cum ar fi percepția serviciilor de către clienți (și aceasta nu se potrivește neapărat cu rezultatele monitorizării). De exemplu, chiar și atunci când au avut loc o serie de incidente, clientul poate menține o percepție pozitivă asupra serviciului printr-o acțiune de remediere vizibilă și adecvată. Desigur, este posibil și opusul, în cazul în care clientul rămâne nemulțumit în absența încălcării acordului privind nivelul de servicii.

Primul pas este să încerci să gestionezi așteptările clienților. Aceasta înseamnă stabilirea așteptărilor și obiectivelor potrivite, iar apoi ajustarea sistematică a acestora în mod proactiv, amintindu-ne că „satisfacția = percepție - așteptări” (când valoarea este mai mare sau egală cu zero, clientul este mulțumit). SLA-urile sunt doar documente și prin ele însele nu înlocuiesc calitatea serviciului furnizat (deși pot influența comportamentul și pot ajuta la dezvoltarea unei culturi adecvate a serviciilor care va avea efecte pozitive atât pe termen scurt, cât și pe termen lung). Un anumit grad de răbdare trebuie exercitat și să facă parte din așteptări.

În cazul în care serviciile furnizate sunt plătite de către client, prețurile pot fi utilizate pentru a gestiona cererea. (Clienții pot obține orice pot justifica – atâta timp cât se potrivește cu strategia întreprinderii – și au un buget autorizat pentru a face acest lucru, care este limitat.) Acolo unde nu există reciprocitate, suportul managementului de vârf trebuie să fie asigurat pentru a limita așteptările nerealiste ale clienților.

• sondaje periodice și sondaje ale clienților;
• feedback la întâlnirile de evaluare a serviciilor;
• feedback la evaluarea modificărilor efectuate;
• sondaje telefonice efectuate de Service Desk;
• chestionare de satisfacție distribuite în timpul serviciului și a altor contacte;
• comunicarea cu grupurile de utilizatori (pe forumuri etc.);
• analiza reclamațiilor și mulțumirilor.

Acolo unde este posibil, obiectivele de satisfacție ar trebui definite și monitorizate ca parte a SLA. Asigurați-vă că orice feedback din partea utilizatorilor primește răspuns, demonstrându-le că comentariile lor au fost incluse în planul dvs. de acțiune (Planul de îmbunătățire a serviciilor). Toate măsurătorile satisfacției trebuie evaluate, abaterile trebuie analizate și ajustările trebuie planificate pe baza rezultatelor analizei.

Furnizorii de servicii depind de propriile echipe de asistență și de parteneri sau furnizori externi. Ei nu pot garanta acorduri de nivel de serviciu dacă dependențele interne și externe nu susțin aceleași obiective. Contractele cu furnizorii externi sunt obligatorii, dar multe organizații consideră, de asemenea, utilă încheierea unor acorduri simple între echipele interne, denumite în mod obișnuit acorduri la nivel operațional. „Acorduri de asistență” este un termen generic pentru toate acordurile de nivel operațional de sprijin, acordurile de nivel de serviciu și contractele.

Acordurile la nivel operațional nu ar trebui să fie excesiv de complexe, dar ar trebui să stabilească obiective clare pentru echipele de asistență pentru a se asigura că obiectivele acordului de nivel de serviciu sunt îndeplinite. De exemplu, dacă un SLA necesită ca incidentele să fie rezolvate într-un interval de timp specificat, Acordul la nivel operațional ar trebui să includă limite adecvate pentru fiecare element din lanțul de suport. Evident, obiectivele din SLA în acest caz nu ar trebui să fie aceleași cu obiectivele din acordurile de susținere, deoarece SLA-urile definesc timpul total, care include munca mai multor grupuri, pentru fiecare dintre acestea putând fi convenit un acord de sprijin.

SLA-urile ar trebui să includă timpul de răspuns la apel, timpul de escaladare a incidentelor către tehnicieni și timpul de răspuns. Orele de sprijin pentru fiecare grup de sprijin ar trebui, de asemenea, stabilite. Dacă există proceduri speciale de contact pentru personal (linie telefonică în afara orelor de program etc.), acest lucru ar trebui, de asemenea, documentat.

Acordul la nivel operațional ar trebui monitorizat pentru conformitatea cu obiectivele stabilite în acordurile de nivel de serviciu și contractele de sprijin, iar raportarea adecvată ar trebui să fie generată și comunicată managerilor de echipă de sprijin. Acest lucru poate ajuta la identificarea potențialelor zone cu probleme care necesită ajustări ale muncii sau acordurilor. Ar trebui să se acorde o atenție serioasă dezvoltării de acorduri formale la nivel operațional pentru toate echipele interne implicate în sprijinirea și furnizarea serviciilor operaționale.

În consecință, înainte de a semna un SLA nou sau revizuit, este important să revizuiți acordurile contractuale existente și, dacă este necesar, să le actualizați. Acest lucru poate necesita costuri suplimentare, din partea IT sau a clientului. În acest din urmă caz, aceste costuri trebuie convenite cu clientul, sau în contracte ar trebui incluse ținte mai blânde. Această revizuire ar trebui efectuată împreună cu managementul furnizorilor pentru a se asigura că nu numai cerințele procesului de management al nivelului de servicii sunt îndeplinite, ci și conformitatea cu alte constrângeri, cum ar fi politicile contractuale și standardele.

Odată ce un acord privind nivelul de servicii a fost convenit și acceptat, trebuie să se asigure monitorizarea și raportarea nivelului de serviciu atins. Rapoartele operaționale ar trebui să fie generate frecvent (cel puțin săptămânal) și, dacă este posibil, rapoartele de abatere ar trebui să fie generate ca răspuns la abaterile (sau amenințarea de abateri) de la SLA. Este adesea dificil să îndepliniți SLA-urile la începutul funcționării unui nou serviciu din cauza numărului mare de solicitări de modificare care vin. Vă recomandăm să limitați numărul de solicitări de modificare permise în această etapă.

Mecanismele de raportare, intervalele de raportare și formatul trebuie convenite cu clienții. Același lucru este valabil și pentru frecvența și formatul întâlnirilor de evaluare a serviciilor. Se recomandă intervale regulate, sincronizate cu raportarea regulată.

Raportarea periodică ar trebui să fie generată și trimisă clienților sau reprezentanților acestora și managerilor IT relevanți cu câteva zile înainte de întâlnirile de evaluare a serviciilor, astfel încât posibilele dificultăți și dezacorduri să fie rezolvate înainte de întâlnire și să nu interfereze cu evaluarea serviciului.

Raportarea periodică ar trebui să includă detalii despre performanța față de obiectivele SLA, precum și o descriere a tendințelor și acțiunilor de îmbunătățire a calității serviciilor. Poate fi convenabil să includeți tabele pe prima pagină a raportului în rapoartele SLA, astfel încât să vă puteți face o idee rapidă despre cum se potrivește serviciul scopului. Managerii IT pot solicita raportări intermediare pentru a evalua performanța acordurilor și contractelor la nivel operațional. Raportarea este un proces în evoluție, primul rezultat este puțin probabil să fie final.

Procesul de management al nivelului de servicii ar trebui să identifice nevoile de raportare și să automatizeze raportarea cât mai mult posibil. Variabilitatea, acuratețea și ușurința de difuzare a rapoartelor reprezintă o parte importantă a criteriilor de alegere a unui instrument de automatizare. Raportarea serviciilor nu ar trebui să includă doar detalii despre performanța serviciului, ci și să ofere informații istorice despre valorile și tendințele anterioare, ceea ce va permite evaluarea și planificarea eficienței măsurilor de îmbunătățire a serviciilor.

Ar trebui organizate întâlniri periodice cu clienții pentru a evalua în comun serviciile pe baza rezultatelor perioadei trecute și a abaterilor și dificultăților care au apărut. De obicei, aceste întâlniri sunt lunare sau cel puțin trimestriale.

La aceste întâlniri ar trebui planificate măsuri pentru corectarea deficiențelor în furnizarea și consumul de servicii. Deciziile ar trebui înregistrate și implementarea lor monitorizată și verificată la următoarele întâlniri.

O atenție deosebită trebuie acordată întreruperilor de serviciu; ar trebui clarificate cauzele și posibilele măsuri de prevenire a reapariției unor astfel de incidente. Dacă se stabilește că obiectivele stabilite anterior sunt de neatins, se poate lua o decizie de evaluare, renegociere și convenire asupra obiectivelor de serviciu. Dacă întreruperea serviciului s-a datorat unei dependențe de terți, poate fi necesară revizuirea acordurilor de susținere. Analiza pierderilor de întrerupere a serviciului oferă informații importante pentru planificarea îmbunătățirilor raționale. Urmărirea constantă a îmbunătățirii trebuie să țină cont de interesele afacerii, concentrând eforturile în domeniile cele mai importante și profitabile.

Progresul și rezultatele planului de îmbunătățire a serviciilor trebuie raportate pentru a evalua conformitatea cu planul și eficacitatea măsurilor luate.

Toate tipurile de acorduri trebuie menținute la zi. Acestea ar trebui să fie sub controlul managementului modificării și configurației și revizuite periodic, cel puțin o dată pe an, pentru a se asigura că sunt actuale, complete și în concordanță cu nevoile și strategia de afaceri.

Aceste verificări ar trebui să asigure că acordurile sunt actualizate în ceea ce privește domeniul de aplicare și obiectivele stabilite, confirmând că acordurile nu și-au pierdut valabilitatea (utilizabilitatea) din cauza oricăror modificări în infrastructură, afaceri, furnizori etc. Când acordurile sunt actualizate, modificările efectuate ar trebui să facă obiectul controlului de management al modificărilor. Dacă acordurile sunt reflectate în sistemul de management al configurației ca CI, acest control este mai ușor de efectuat, iar rezultatele sale sunt mai fiabile.

Evaluările ar trebui să acopere, de asemenea, documentele strategice generale pentru a se asigura că acordurile sunt aliniate cu strategia și politicile IT și de afaceri.

Este foarte important ca procesul de management al nivelului de servicii să construiască o relație de încredere și respect cu afacerea, în special cu reprezentanții cheie de afaceri. Pentru ca acest lucru să fie posibil, procesul de management al nivelului de servicii trebuie să realizeze următoarele activități:

• confirmarea listelor de părți interesate, clienți, lideri de afaceri și utilizatori;
• ajuta la menținerea datelor exacte în portofoliu și catalogul de servicii;
• oferi flexibilitate și disponibilitate pentru a răspunde nevoilor afacerii, clienților și utilizatorilor, înțelegerea proceselor de afaceri actuale și planificate și cerințele acestora pentru servicii noi și în schimbare, documentând și discutând aceste cerințe cu afaceri, clienți și utilizatori, formând relații pe termen lung;
• asigura o intelegere completa a strategiei, planurilor, nevoilor si obiectivelor afacerii, clientilor si utilizatorilor, dezvoltand parteneriate intre acestia si IT;
• Efectuează în mod regulat evaluări de performanță și studii despre experiența clienților - interne și externe - și comunică informații relevante către IT;
• să asigure existența și eficacitatea procedurilor de interacțiune și îmbunătățirea continuă a acestora;
• organizează și desfășoară sondaje de satisfacție a clienților, asigurând analiza și acțiunea acestora asupra rezultatelor;
• reprezenta furnizorul de servicii la întâlnirile grupului de utilizatori;
• cercetarea proactivă a pieței prin analizarea utilizării serviciilor și influențarea portofoliului și catalogului de servicii;
• colaborează cu afaceri, clienți și utilizatori pentru a se asigura că IT oferă un nivel de servicii care să răspundă nevoilor actuale și viitoare ale afacerii;
• promovează conștientizarea și înțelegerea serviciilor;
• creșterea gradului de conștientizare cu privire la beneficiile de afaceri ale utilizării noilor tehnologii;
• să faciliteze definirea și discutarea cerințelor corecte, realizabile și realiste privind nivelul de servicii și acordurile privind nivelul de servicii între IT și afacere;
• asigurați-vă că afacerile, clienții și utilizatorii își înțeleg relațiile cu IT și dependențele;
• promovează înregistrarea îmbunătățirilor și îmbunătățirilor.

Procesul de management al nivelului de servicii ar trebui să includă, de asemenea, activități și proceduri pentru înregistrarea și gestionarea reclamațiilor și a laudărilor. Înregistrarea este adesea efectuată de biroul de service și este similară cu înregistrarea incidentelor și solicitărilor de servicii. Definițiile de plângere și recunoaștere ar trebui convenite cu clienții împreună cu punctele de contact și procedurile. Toate plângerile și laudele trebuie înregistrate și transmise părților corespunzătoare. Toate reclamațiile trebuie, de asemenea, tratate și soluționate în mod satisfăcător pentru inițiator. În cazul în care acest lucru nu se întâmplă, trebuie definite contacte și proceduri de escaladare. Toate reclamațiile grave trebuie analizate și aduse la cunoștința conducerii. Raportarea ar trebui să fie făcută cu privire la statistici, tendințe, acțiuni și rezultate în gestionarea reclamațiilor și a laudărilor.

Valorile procesului de management al nivelului de serviciu

• CSF Este important să se asigure calitatea managementului serviciilor în general, inclusiv acoperirea și nivelul de livrare:
• KPI Procentul de reducere a nerespectării obiectivelor SLA
• KPI Procentul de atenuare a amenințărilor de neconformitate
• KPI Procentul de îmbunătățiri în percepția clienților și satisfacția față de realizările SLA pe baza întâlnirilor de evaluare a serviciilor și a sondajelor de satisfacție
• KPI Procentul de reducere a neconformităților asociate cu dependența de terți (UC)
• KPI Procentul de reducere a neconformităților asociate cu dependența de contractori interni (OLA)
• CSF Furnizare de servicii în conformitate cu acordurile pentru bani rezonabili:
• KPI Numărul și procentul de creștere a numărului de SLA-uri complet documentate
• KPI Procentul de îmbunătățiri SLA care vizează îmbunătățirea serviciilor deja furnizate
• KPI Ponderea reducerii costului de furnizare a serviciilor
• KPI Procentul de reducere a costurilor pentru monitorizarea și raportarea SLA
• KPI Procentul de creștere a vitezei de dezvoltare și aprobarea SLA
• KPI Frecvența întâlnirilor de evaluare a serviciului
• CSF Gestionarea interfeței dintre afaceri și utilizatori:
• KPI Creșterea numărului de servicii acoperite de SLA
• KPI Documentarea și alinierea procesului și procedurilor SLM
• KPI Reducerea timpului de răspuns și execuție pentru solicitările SLA
• KPI Creșterea ponderii SLA-urilor revizuite la timp
• KPI Reducerea ponderii SLA-urilor neîndeplinite supuse revizuirii
• KPI Scăderea proporției de SLA care necesită ajustare
• KPI Creșteți acoperirea OLA și UC, reducând în același timp numărul de acorduri prin consolidarea și centralizarea acestora
• KPI Dovezi documentare ale îmbunătățirilor ale abaterilor identificate de la SLA
• KPI Reducerea numărului și a gravității nerespectării obiectivelor SLA
• KPI Evaluarea și procesarea eficientă a tuturor abaterilor și inconsecvențelor de la SLA, OLA, UC

ITIL identifică măsuri subiective și obiective ale performanței managementului nivelului de servicii. Obiectiv:

• Numărul sau proporția obiectivelor de serviciu atinse
• Numărul și gradul (gravitatea) abaterilor și încălcărilor
• Numărul de SLA-uri actuale (actualizate)
• Numărul de servicii care sunt raportate și evaluate în timp util

Subiectiv:

• Îmbunătățiri ale satisfacției clienților

Riscuri și dificultăți

La implementarea managementului nivelului de servicii, trebuie luate în considerare următoarele riscuri potențiale și provocări:

• Lipsa datelor de intrare precise, a implicării și a interesului din partea afacerilor și clienților
• Nevoia de resurse și instrumente pentru a conveni, documenta, monitoriza, raporta și evalua acordurile și nivelurile de servicii
• Procesul poate deveni excesiv de birocratic, concentrat mai degrabă pe proceduri administrative decât pe îmbunătățirea efectivă proactivă a serviciilor
• Acces și suport pentru CMS și SKMS corecte și actualizate
• Nerespectarea procedurilor SLM
• Valorile bazate pe afaceri sunt prea greu de măsurat și îmbunătățit, așa că nu o vor face
• Nivel inadecvat de contact și coordonare
• Așteptări ridicate și satisfacție scăzută a clienților
• Comunicare ineficientă cu afacerile

Procesul de management al problemelor

La furnizarea de servicii IT, într-un fel sau altul, apar incidente (eșecuri). Și dacă aveți un proces de management al incidentelor organizat corespunzător și un proces de management al evenimentelor, atunci impactul negativ al incidentelor emergente va fi minimizat. Dacă apar incidente, atunci există un motiv necunoscut pentru acest lucru. Procesul de management al incidentelor începe când apare un incident și se oprește când situația este corectată. Aceasta înseamnă că cauza principală a unui incident nu este întotdeauna identificată și incidentul poate reapare. În ITIL, acest motiv se numește problemă.

O problemă este cauza unuia sau mai multor incidente. De obicei, atunci când se creează o înregistrare a problemei, cauza este necunoscută și este responsabilitatea procesului de gestionare a problemei să o investigheze în continuare.

Pentru a determina cauzele fundamentale ale defecțiunilor existente și potențiale ale serviciului, procesul de management al problemelor examinează infrastructura și informațiile disponibile, inclusiv baza de date de incidente.

Managementul problemelor este procesul responsabil de gestionarea ciclului de viață al tuturor problemelor. Managementul problemelor previne în mod proactiv apariția incidentelor și minimizează impactul incidentelor care nu pot fi prevenite.

Managementul problemelor include activități proactive (proactive) și reactive. Sarcina componentelor reactive ale procesului de management al problemelor este de a afla cauza principală a incidentelor trecute și de a pregăti o propunere pentru eliminarea acesteia. Managementul proactiv al problemelor ajută la prevenirea incidentelor prin identificarea punctelor slabe ale infrastructurii și pregătirea propunerilor de îmbunătățire.

Astfel, sarcinile procesului de management al problemelor sunt:

• Prevenirea problemelor și a incidentelor conexe
• Oprirea reapariției incidentelor
• Reducerea impactului incidentelor care nu pot fi prevenite

Activități de management al problemelor

În principiu, orice incident care are loc dintr-un motiv necunoscut poate fi asociat cu o problemă. În practică, are sens să inițiezi o problemă doar atunci când incidentul se repetă, este posibil să-l repeți sau dacă este un incident unic, dar grav.

Activitatea de „identificare a problemelor” este adesea efectuată de coordonatorii problemei. Cu toate acestea, se poate întâmpla ca personalul care nu este implicat inițial în această activitate, de exemplu, specialiștii în managementul capacității, să poată identifica și probleme. Astfel de „descoperiri” ar trebui, de asemenea, înregistrate ca probleme.

Detaliile de înregistrare ale problemelor sunt similare cu detaliile incidentelor, dar în cazul unei probleme, nu trebuie să includeți în descriere informații despre utilizator etc.. Cu toate acestea, incidentele legate de o anumită problemă trebuie identificate și înregistrat în consecință. Următoarele sunt exemple de cazuri în care pot fi identificate probleme:

• Gestionarea incidentelor nu poate potrivi (potrivirea) un incident cu problemele existente sau erorile cunoscute
• Analiza tendințelor incidentelor arată că poate exista o problemă
• Este necesară analiza cauzei unui incident major
• Alte funcții IT au stabilit că poate exista o problemă
• Personalul de la Service Desk nu a putut determina cauza incidentului și există suspiciunea că acest incident se poate repeta
• Analiza incidentului de către echipa de asistență a arătat că există (sau poate exista) o problemă
• Notificare de la furnizor că există o problemă de rezolvat

Posibilele semne de probleme pot include:

• Incidente recurente în:
• Același interval de timp
• Într-un domeniu (categorie)
• În același CI sau grup de CI similare
• În aceeași locație, ordine, împărțire
• Volumul incidentelor similare depășește un anumit nivel
• A fost aplicată o soluție pentru a rezolva incidentul
• Termenul limită de procesare a incidentului(e) a fost depășit

Analiza tendințelor vă permite să identificați zonele care necesită o atenție specială. Indiferent de metoda de detectare a problemei, toate datele relevante despre problemă ar trebui înregistrate într-o înregistrare a problemei:

• Informații despre utilizator(i)
• Informații despre serviciu(e)
• Informații hardware
• Ora de înregistrare
• Prioritate, categorie
• Descrierea incidentelor conexe
• Măsuri luate pentru diagnosticare și rezolvare

Înregistrare probleme - o înregistrare care conține o descriere detaliată a problemei. Fiecare înregistrare de emisiune documentează ciclul de viață al unei singure probleme.

La fel ca incidentele, problemele trebuie clasificate. Problemele pot fi clasificate în domenii (categorii). Clasificarea problemei se realizează în același timp cu analiza gradului de impact al acesteia, adică nivelul de severitate al problemei și impactul acesteia asupra serviciilor (urgență și grad de impact). În continuare, problemei i se atribuie o prioritate, la fel ca în procesul de gestionare a incidentelor. Apoi, pe baza rezultatelor clasificării, problemei sunt alocate resurse și personal și se determină timpul necesar pentru rezolvarea acesteia.

Clasificarea problemei include următoarele:

O eroare cunoscută este o problemă care are o cauză principală documentată și o soluție. Bug-urile cunoscute sunt create și gestionate pe tot parcursul ciclului lor de viață, ca parte a procesului de gestionare a problemelor. Bug-urile cunoscute pot fi identificate și de către dezvoltatori sau antreprenori.

Clasificarea nu este statică, se poate schimba pe parcursul ciclului de viață al problemei. De exemplu, o soluție sau o soluție rapidă poate ajuta la reducerea urgenței problemei, în timp ce noile incidente pot crește impactul problemei.

Investigarea și diagnosticarea sunt faze iterative ale procesului, ele se repetă de multe ori, de fiecare dată apropiindu-se de rezultatul dorit. Adesea, se încearcă reproducerea unui incident într-un mediu de testare. Pot fi necesare cunoștințe suplimentare pentru a rezolva problema, de exemplu, puteți implica specialiști din echipa de asistență pentru a analiza și diagnostica problema.

După ce s-a determinat cauza problemei și o soluție, problemei i se atribuie starea de „Eroare cunoscută”. În multe cazuri, există deja o soluție pentru o problemă, chiar dacă eroarea este găsită de dezvoltatori înșiși. Dar, în unele cazuri, trebuie găsită o soluție și apoi trecută la procesul de gestionare a incidentelor.

O soluție constă în reducerea sau eliminarea impactului unui incident sau al unei probleme pentru care nu este disponibilă în prezent o soluție completă. De exemplu, repornirea unui element de configurare eșuat. Soluțiile pentru probleme sunt documentate în înregistrările de erori cunoscute.

Personalul de management al problemelor stabilește ce trebuie făcut pentru a rezolva problema. Experții compară diferite soluții, ținând cont de acordurile de nivel de servicii (SLA), costurile și beneficiile posibile. Toată munca de dezvoltare a unei soluții ar trebui să fie înregistrată în sistem, personalul ar trebui să aibă mijloacele de a monitoriza problemele și de a determina starea acestora.

În etapele anterioare se alege soluția optimă. Cu toate acestea, se poate decide să nu se corecteze o eroare cunoscută, de exemplu, deoarece nu este fezabilă din punct de vedere economic.

După finalizarea fazei de selecție, există suficiente informații pentru a trimite o cerere de modificare. Corectarea ulterioară a problemei (eroare cunoscută) se va face sub controlul procesului de management al schimbărilor.

O modificare menită să rezolve o problemă trebuie luată în considerare atunci când se evaluează rezultatele implementării înainte ca problema să fie închisă. Dacă modificarea a produs rezultatul așteptat, problema poate fi închisă și starea acesteia poate fi schimbată în „rezolvată” în baza de date a problemelor. Managementul incidentelor va fi informat despre acest lucru și incidentele legate de această problemă pot fi, de asemenea, închise.

Evaluarea rezultatelor implementării - o revizuire efectuată după implementarea unei schimbări sau a unui proiect. Evaluarea implementării determină succesul unei schimbări sau al unui proiect și identifică oportunitățile de îmbunătățire.

Pe tot parcursul procesului, soluțiile alternative și remediile rapide sunt comunicate managementului incidentelor. Utilizatorii pot fi, de asemenea, informați despre acest lucru.

Politici și metrici de management al problemelor

Politicile procesului de management al problemelor trebuie aplicate pentru a asigura eficacitatea și eficiența procesului și pot include următoarele:

• Problemele trebuie urmărite separat de incidente
• Toate problemele ar trebui să fie stocate și gestionate de un singur sistem de management
• Toate problemele ar trebui să aibă o schemă standard de clasificare care să se potrivească cu procesele de afaceri ale întreprinderii.

Pentru a gestiona și a evalua eficacitatea procesului de management al nivelului de servicii, precum și pentru a oferi feedback altor procese de management, ITIL sugerează utilizarea următorilor indicatori cheie (CSF și KPI):

• CSF Minimizați impactul asupra afacerii al incidentelor care nu pot fi prevenite
• KPI Numărul de erori cunoscute adăugate de KEDB
• Procentul KPI de relevanță KEDB (prin auditul bazei de date)
• KPI Procentul de incidente închise de biroul de asistență („Primul punct de contact”)
• KPI Timp mediu pentru rezolvarea incidentelor pentru care este deschisă o problemă
• CSF menține calitatea serviciilor IT prin eliminarea incidentelor recurente
• KPI Numărul total de probleme (ca punct de referință)
• Dimensiunea cozii de probleme KPI per serviciu IT
• KPI Numărul de incidente repetate pentru fiecare serviciu IT
• CSF Asigurarea calitatii si profesionalismului in rezolvarea problemelor pentru a mentine increderea afacerilor in capacitatile IT
• KPI Numărul de probleme semnificative (deschise, închise și puse în coadă)
• Procentul KPI de revizuiri ale problemelor semnificative finalizate cu succes
• KPI Procentul de revizuiri ale problemelor semnificative finalizate cu succes și la timp
• KPI Numărul și procentul de probleme atribuite incorect
• KPI Numărul și procentul de probleme cu categorizare incorectă
• KPI Coada de probleme acumulate nerezolvate și tendința acesteia
• KPI Numărul și procentul de probleme care au depășit termenele limită de rezolvare
• KPI Procentul de probleme rezolvate în cadrul obiectivelor SLA
• KPI Costul mediu al rezolvării unei probleme

Valoarea afacerii

Prin implementarea unui proces de management al incidentelor în conformitate cu recomandările ITIL și rezolvarea tuturor dificultăților care pot apărea în timpul implementării, se poate obține următoarea valoare pentru afacerea în ansamblu:

• Îmbunătățirea calității serviciilor IT prin monitorizarea, documentarea și/sau eliminarea erorilor din infrastructură.
• Reducerea numărului de incidente.
• Creșterea productivității personalului
• Utilizarea de soluții permanente în loc de „găuri de plasture” continue.
• Activități sistematice pentru acumularea de cunoștințe.
• Abilitatea de a rezolva mai multe incidente pe prima linie de suport.
• Reducerea costurilor eforturilor de stingere a incendiilor sau de rezolvare a reincidentelor

Procesul de gestionare a activelor și configurației serviciului

Fiecare organizație are informații despre infrastructura IT. Adesea, pentru a structura și a rezuma informațiile disponibile, sunt dezvoltate diverse scheme care sunt atârnate pe perete. Această metodă permite într-adevăr, în anumite cazuri, obținerea rapidă a informațiilor despre configurația componentelor infrastructurii și relațiile acestora, dar are o serie de dezavantaje:

• complexitatea actualizării: la fiecare modificare, diagrama trebuie redesenată și retipărită, altfel nu se poate baza pe ea dacă este necesar
• acoperire limitată: componentele infrastructurii pot fi foarte strâns întrepătrunse și nu întotdeauna toate elementele pot fi reflectate în diagramă
• informații limitate: de regulă, pentru fiecare element sunt indicate doar cele mai importante informații, cum ar fi un nume de domeniu sau o adresă IP
• complexitatea analizei: cu o acoperire mare a schemei și în prezența diferitelor relații complexe între componente, analiza unor astfel de scheme este dificilă

Construit în conformitate cu recomandările ITIL, procesul de gestionare a activelor și configurațiilor de servicii vă permite să utilizați datele disponibile despre infrastructura IT în cel mai eficient mod, evitând în același timp aceste dezavantaje și obținând beneficii suplimentare.

Service Asset and Configuration Management (SACM) este procesul responsabil de asigurarea faptului că toate activele necesare pentru furnizarea serviciilor sunt controlate și că informațiile exacte și fiabile despre acestea sunt disponibile atunci când este necesar. Aceste informații includ configurația activelor și relațiile dintre acestea.

Gestionarea activelor și configurației serviciului include două subprocese:

• Managementul activelor este activitatea sau procesul responsabil de urmărirea și raportarea valorii și deținerii activelor pe parcursul ciclului de viață al acestora.
• Managementul configurației este activitatea sau procesul responsabil cu gestionarea informațiilor despre elementele de configurare necesare pentru furnizarea serviciilor IT, inclusiv relațiile acestora.

Sarcini ale procesului de gestionare a configurației și a activelor de serviciu:

• Identificați, controlați, documentați, raportați și validați activele serviciului și elementele de configurare, inclusiv versiunile, liniile de bază, componentele, atributele și relațiile acestora
• Responsabil pentru gestionarea și protejarea și protejarea integrității activelor serviciului și a elementelor de configurare (și, după caz, a celor deținute de client) pe tot parcursul ciclului de viață al serviciului, asigurându-se că sunt utilizate numai componentele autorizate și că sunt făcute numai modificările autorizate
• Asigurați integritatea activelor și a configurației necesare pentru a gestiona serviciile și infrastructura IT prin crearea și menținerea unui sistem de management al configurației precis și complet

Miezul procesului este sistemul de management al configurației (CMS). CMS vă permite să stocați toate informațiile de configurare necesare, analiza și prezentarea acesteia în diferite secțiuni.

Sistem de management al configurației (CMS) Un set de instrumente, date și informații care sunt utilizate pentru a sprijini procesul de gestionare a activelor și configurațiilor de servicii. CMS - parte a sistemului general de management al cunoștințelor de serviciu, include instrumente pentru colectarea, stocarea, gestionarea, actualizarea, analizarea și prezentarea informațiilor despre toate elementele de configurare și relațiile lor. CMS poate include, de asemenea, informații despre incidente, probleme, erori cunoscute, modificări și versiuni. CMS este susținut de procesul de gestionare a configurației și a activelor de servicii și este utilizat de toate procesele de management al serviciilor IT.

Un element de configurare (CI) este orice componentă sau alt activ de serviciu care trebuie gestionat pentru a furniza un serviciu IT. Informațiile despre fiecare element de configurare sunt înregistrate sub forma unei înregistrări de configurare în sistemul de management al configurației și sunt păstrate la zi pe tot parcursul ciclului de viață de către procesul de gestionare a configurației și a activelor de serviciu. CI sunt sub controlul procesului de management al schimbării. Acestea includ de obicei servicii IT, hardware, software, clădiri, oameni și documente, cum ar fi documentația procesului și acordurile de nivel de serviciu.

Elementele de configurare pot fi hardware, tot felul de software, elemente de rețea active și pasive, servere, blocuri de construcție, documentație, proceduri, servicii și toate celelalte componente IT controlate de organizația IT etc. Următoarele tipuri de obiecte sunt stocate în CMS:

• înregistrările elementelor de configurare, inclusiv atributele corespunzătoare
• relații (legături) între elementele de configurare

Atributele vă permit să luați în considerare informațiile necesare pentru un anumit tip de elemente de configurare. De exemplu, pentru servere și laptopuri, informații precum producător, nume de domeniu, perioada de garanție etc. pot fi de interes. Cu toate acestea, pentru software, este posibil ca aceste informații să fie diferite.

Un atribut este o informație despre un element de configurare. De exemplu, numele, locația, numărul versiunii și costul. Atributele CI sunt înregistrate în baza de date de management al configurației (CMDB) și menținute ca parte a sistemului de management al configurației (CMS).

Astfel, fiecare element de configurare trebuie să aparțină unui anumit tip (clasă), care definește atribute comune pentru toate CI de acest tip (clasă) și o listă de relații posibile între CI de acest tip și CI de alt tip.

Tip CU - o categorie care este utilizată pentru a clasifica elementele de configurare. Tipul CI determină ce atribute și relații sunt necesare pentru intrarea de configurare. Tipurile comune de CI sunt hardware, documentație, utilizator și așa mai departe.

Setul de CU și relațiile lor este de fapt un model de configurare. Figura prezintă un exemplu de model de configurare.
CMS vă permite să luați în considerare în mod eficient informațiile de configurare necesare, să analizați și să prezentați sub diferite forme, inclusiv grafice. CMS oferă informații altor procese de management al serviciilor:

• pentru a evalua impactul incidentelor și problemelor
• pentru a evalua impactul schimbărilor
• pentru planificarea și proiectarea de servicii noi și în schimbare
• pentru planificarea upgrade-ului de tehnologie și software
• pentru planificarea pachetelor de lansare și replicarea serviciilor
• pentru a optimiza utilizarea activelor și a costurilor

Astfel, dacă gestionarea activelor și configurațiilor de servicii este implementată eficient, atunci acest proces poate furniza, de exemplu, informații despre următoarele:

• Informații financiare și politica de produse ale companiei
• Ce componente IT sunt utilizate în prezent pentru fiecare model (versiune) și pentru cât timp?
• Ce tendințe există în diferite grupuri de produse?
• Care este valoarea curentă și reziduală a componentelor IT?
• Ce componente IT trebuie eliminate din mediul de operare și care necesită modernizare?
• Cât va costa înlocuirea anumitor componente?
• Ce licențe sunt disponibile și sunt suficiente?
• Ce contracte de escortă ar trebui revizuite?
• Care este gradul de standardizare a infrastructurii?
• Depanarea și evaluarea rezultatelor
• Ce componente IT sunt necesare pentru a sprijini procesul de recuperare în caz de dezastru?
• Va funcționa planul de recuperare în caz de urgență dacă configurația infrastructurii a fost modificată?
• Ce componente IT vor fi afectate atunci când sunt implementate noi servicii?
• Cum este conectat echipamentul la rețea?
• Ce module software sunt incluse în fiecare dintre pachetele software?
• Ce componente IT sunt afectate de modificări?
• Ce cereri de modificare (RFC) pentru anumite componente IT sunt în așteptare și ce incidente și probleme au apărut în trecut și sunt încă relevante?
• Ce componente IT cauzează erori cunoscute?
• Ce componente IT au fost achiziționate de la un anumit furnizor într-o anumită perioadă?
• Furnizare de servicii si facturare
• Ce configurații ale componentelor IT sunt esențiale pentru anumite servicii?
• Ce componente IT sunt utilizate în ce locație și de către cine?
• Ce componente IT standard poate comanda un utilizator și care sunt suportate (catalog de produse)?

Activități în cadrul procesului de gestionare a configurației și a activelor de servicii

Figura prezintă o diagramă a activităților tipice de gestionare a configurației.

În materialele ITIL, „planificarea” se referă la activitatea de organizare a procesului de management al configurației în sine. Managementul și planificarea ca tip de activitate sunt utilizate atât în ​​etapa de creație, cât și în etapa de îmbunătățire a procesului. Principalul rezultat al planificării este „Planul de management al configurației”.

Planul de management al configurației conține.

• Descrierea procesului de management al configurației
• Descrierea la nivel înalt a arhitecturii sistemului
• Planificați evenimente semnificative (identificare, lansări majore etc.)

Planul este un document viu și este supus revizuirii periodice. Managerul procesului de management al configurației este responsabil pentru actualizarea planului.

Activitățile de identificare a configurației includ:

• Definirea și documentarea criteriilor de selecție a elementelor de configurare și a componentelor lor constitutive
• Selectarea elementelor de configurare și a componentelor pe baza criteriilor documentate
• Atribuirea de identificatori unici
• Definirea atributelor pentru fiecare CI
• Determinarea momentului în care CU este luată sub controlul procesului
• Determinarea proprietarului responsabil pentru fiecare CI

În funcție de amploarea infrastructurii IT și de complexitatea regulilor contabile, identificarea poate fi consumatoare de timp și de resurse. Prin urmare, munca de identificare trebuie planificată cu atenție.

Activitățile de management al KE includ următoarele aspecte:

• Menținerea datelor CMDB la zi
• Asigurarea integrității datelor CMDB (originea și istoricul modificărilor fiecărui CI este clară)
  • Restricționarea accesului pentru modificarea datelor CMDB
  • Asigurarea protecției antivirus a controalelor CMDB
  • Oferiți capabilități de backup și restaurare
• Regulile de control ar trebui dezvoltate în etapa de planificare a procesului
• Reguli pentru transferul controlului de la proiecte sau furnizori
• Procedurile de control trebuie să corespundă tipurilor de CU

Activitățile de contabilizare și raportare a stării configurației includ:

• Menținerea înregistrărilor de configurare pe tot parcursul ciclului de viață al serviciului și arhivarea acestora în conformitate cu acordurile, cerințele externe, cele mai bune practici și standardele (de exemplu, ISO 9001)
• Gestionarea documentației, achiziționarea și consolidarea stării actuale a configurației și a stărilor tuturor configurațiilor anterioare pentru a asigura corectitudinea, promptitudinea, integritatea și securitatea informațiilor
• Asigurarea că informațiile despre stare sunt disponibile pe tot parcursul ciclului de viață al unui serviciu
• Documentarea modificărilor CI de la acceptare la dezafectare
• Asigurarea faptului că configurațiile de bază sunt documentate corespunzător

Verificare si audit:

• Verificare - verificarea CU pentru conformitatea cu standardele sau cerințele funcționale:
• La înregistrarea inițială în CMDB
• Când primiți hardware sau software de la un furnizor
• La punerea în funcţiune
• Audit - verificarea corespondenței dintre starea actuală a CI (așa cum este) și descrierea CI în CMDB (cum ar trebui să fie)
• Audit standard
• Audit simplificat
• Audit curent (operațional).

• La scurt timp după introducerea unui nou proces de management al sistemului/configurației
• Înainte și după schimbări majore în infrastructura IT
• Înainte de a implementa un nou software de pregătire pentru producție
• După revenirea după o întrerupere majoră (de urgență)
• La descoperirea unui număr mare de discrepanțe (de exemplu, ca parte a unui audit operațional)
• În mod regulat (la intervale prestabilite)
• Din când în când (verificări „bruște”)

Valori de proces de gestionare a activelor și configurației serviciului

Pentru a gestiona și a evalua eficacitatea procesului de management al schimbării, precum și pentru a oferi feedback altor procese de management, ITIL sugerează utilizarea unor indicatori cheie precum:

• Procentul de îmbunătățire a ciclului de viață al activelor în funcție de principiu: nu prea mult, nici prea târziu
• Gradul în care sprijinul satisface nevoile afacerii
• Active identificate ca fiind cauza întreruperilor serviciului
• Creșterea vitezei de rezolvare a incidentelor și de recuperare a serviciului prin identificarea mai rapidă a CI-urilor eșuate
• Identificarea legăturilor între tipuri specifice de CI, incidente și probleme
• Utilizarea mai bună a activelor de servicii
• Utilizarea mai eficientă a licențelor achiziționate, costul mediu al licenței per utilizator
• Bugetare mai precisă și active cu plata pe utilizare
• Audituri mai eficiente ale activelor
• Îmbunătățirea calității și acurateței informațiilor despre active
• Mai puține erori cauzate de lucrul cu date învechite
• Reducerea numărului și a sferei de audit
• Utilizarea redusă a hardware-ului și software-ului neautorizat, ceea ce duce la reducerea costurilor și a riscurilor în suportul de service
• Reduceți timpul și costurile în diagnosticarea și rezolvarea incidentelor și problemelor
• Reducerea timpului de identificare a activelor care sunt problematice din punct de vedere al performanței
• Reducerea numărului de modificări nereușite cauzate de evaluări incorecte de impact, date incorecte în CMS sau control slab al versiunilor
• Reduceți riscul prin detectarea timpurie a modificărilor neautorizate

Dificultăți

Atunci când implementați gestionarea activelor și configurației serviciului, trebuie luate în considerare următoarele provocări potențiale:

• Convingerea personalului de asistență tehnică să respecte politicile contabile, ceea ce este adesea perceput ca un obstacol în calea asistenței rapide.
• Atrageți și justificați alocarea de fonduri pentru proces, deoarece, de obicei, procesul nu este vizibil pentru departamentele clienți care au autoritatea de a aloca fonduri. De obicei, finanțat ca element „invizibil” al managementului schimbării și alte procese mai „vizibile”.
• Abordare: „adunăm toate datele pe care le putem”, ceea ce duce la suprasolicitarea procesului, precum și la incapacitatea de a le menține
• Lipsa de angajament și sprijin din partea conducerii care nu înțeleg rolul cheie al procesului

5.3.1 Gestionarea unui incident.

Majoritatea departamentelor IT și a grupurilor specializate sunt implicate într-o oarecare măsură în gestionarea incidentelor. Biroul de service este responsabil pentru monitorizarea procesului de rezolvare a tuturor Incidentelor raportate și este proprietarul de facto al tuturor Incidentelor. Acest proces este în mare parte reactiv. Pentru a răspunde productiv și eficient, sunt necesare metode de lucru formale care pot fi susținute de instrumente software.

Incidentele pe care Service Desk nu le poate rezolva imediat pot fi îndrumate către una dintre echipele dedicate pentru tratare. Rezoluția sau soluția de soluționare trebuie trimisă cât mai curând posibil pentru a restabili serviciul utilizatorilor cu un impact minim asupra activității lor. După ce cauza Incidentului este eliminată și serviciul convenit este restabilit, Incidentul este închis.

Figura 5.2 prezintă procesele care au loc în timpul ciclului de viață al unui Incident. Anexa 5D prezintă aceste procese dintr-un punct de vedere diferit.

Figura 5.2 - Ciclul de viață al incidentului.

Starea unui incident reflectă poziția sa actuală în ciclul de viață, uneori denumită „poziția sa în diagrama fluxului de lucru”. Fiecare angajat trebuie să cunoască toate stările posibile și semnificațiile acestora. Câteva exemple de categorii de statut:

■ nou;.

■ acceptat;.

■ termenii sunt definiți;.

■ repartizat/transferat la un specialist;.

■ în lucru (Work In Progress, WIP);

■ așteptare;.

■ permis;.

■ închis.

Pe parcursul ciclului de viață al unui Incident, este important ca evidența incidentului să fie ținută la zi. Acest lucru va permite oricărui membru al echipei de service să furnizeze Clientului date actualizate cu privire la evoluția cererii. Câteva exemple de acțiuni de actualizare a înregistrărilor:.

■ actualizarea informațiilor istorice;

■ schimbarea statusului (de exemplu, de la „nou” la „în curs” sau „în așteptare”);

■ modificarea impactului asupra afacerii și prioritățile;

■ introduceţi timpul petrecut şi costurile;

■ Urmăriți starea unei escalade.

Descrierea declarată inițial de către Client se poate modifica în timpul ciclului de viață al unui Incident. Cu toate acestea, este important să lăsați o descriere a simptomelor de bază atât pentru analiză, cât și pentru ca plângerea să poată fi trimisă folosind limbajul conținut în cererea inițială. De exemplu, Clientul ar putea pretinde că imprimanta nu funcționează, dar s-a stabilit că problema a fost cauzată de o defecțiune a rețelei. Când răspundeți Clientului, este mai bine să explicați mai întâi că incidentul de imprimantă este rezolvat, mai degrabă decât să vorbiți despre rezolvarea problemelor de rețea.

Un istoric verificat al unui Incident este necesar atunci când se analizează progresul procesării acestuia, este deosebit de important atunci când se rezolvă probleme legate de încălcarea SLA. În timpul ciclului de viață al unui Incident, trebuie înregistrate următoarele actualizări ale înregistrării acestuia:.

■ Numele persoanei care a făcut modificarea înregistrării.

■ data și ora modificării;.

■ ce anume a schimbat această persoană (de exemplu, prioritate, statut, istoric);

■ De ce a fost făcută schimbarea.

■ timp pierdut.

Dacă furnizorii externi sunt împiedicați să actualizeze înregistrările Service Desk (ceea ce este recomandat), atunci trebuie definită o procedură de actualizare a înregistrărilor pentru furnizor. Acest lucru asigură că resursele utilizate sunt contabilizate corespunzător. Cu toate acestea, dacă software-ul permite posibilitatea de a izola o clasă de Incidente rezolvate de furnizori externi și de a prevalida informațiile introduse, atunci poate fi foarte convenabil pentru unele organizații să permită vânzătorilor externi să actualizeze informațiile direct. Dacă decideți să faceți acest lucru, trebuie să determinați ce informații nu sunteți dispus să furnizați furnizorului și câte detalii trebuie să fiți informat despre acțiunile furnizorului.

Aceeași situație poate apărea atunci când Service Desk actualizează solicitarea în locul specialistului de suport tehnic care se află în afara biroului. Uneori poate fi necesară actualizarea contului de Incident ulterior, de exemplu, dacă specialiștii lucrează seara, iar Serviciul de service trebuie să actualizeze înregistrările în locul lor a doua zi dimineață.

5.3.2 Prima, a doua și a treia linie de sprijin.

Adesea, departamentele și echipele de asistență (specializate) care nu fac parte din Service Desk sunt denumite echipe de asistență de linia a doua sau a treia. Au abilități mai specializate, timp suplimentar sau alte resurse pentru a rezolva Incidentele. Pe baza acestui lucru, Service Desk este numit prima linie de suport. Figura 5.3 arată cum se leagă această terminologie cu activitățile de management al incidentelor discutate în paragrafele anterioare.

Rețineți că linia a 3-a și/sau a N-a de asistență poate include în cele din urmă furnizori externi care pot avea acces direct la facilitățile de raportare a incidentelor (în funcție de problemele de securitate și tehnice).

Figura 5.3 ~ Prima, a doua și a treia linie de sprijin.

5.3.3 Comparație între escaladarea funcțională și ierarhică.

„Escalarea” este un mecanism care facilitează rezolvarea în timp util a unui Incident. Poate funcționa în orice etapă a procesului de rezoluție.

Transferul unui Incident de la asistența de prima linie la asistența de a doua linie sau mai departe se numește „escaladare funcțională” și se datorează lipsei de cunoștințe sau abilități. De preferință, escaladarea funcțională ar trebui să aibă loc atunci când expiră timpul convenit pentru rezolvarea unui Incident. O escaladare funcțională automată care este declanșată după o anumită perioadă de timp trebuie să fie planificată cu atenție și nu trebuie să depășească timpul de rezoluție convenit (în SLA).

O „escaladare ierarhică” poate avea loc în orice moment al procesului de rezolvare dacă există posibilitatea ca rezolvarea unui Incident să nu fie finalizată la timp sau să fie nesatisfăcătoare. În cazul în care există o lipsă de cunoștințe sau abilități, escaladarea ierarhică se face de obicei manual (de către biroul de service sau alt personal de asistență). O escaladare ierarhică automată poate fi luată în considerare după o perioadă critică de timp, când devine evident că Incidentul nu va fi rezolvat în timp util. De preferință, escaladarea ar trebui să aibă loc cu mult înainte de expirarea timpului alocat (în SLA) pentru rezoluție. Acest lucru va permite managementului de linie cu autoritatea adecvată să ia măsuri corective, cum ar fi angajarea unui furnizor extern.

5.3.4 Prioritate.

Prioritatea unui Incident este determinată inițial de impactul acestuia asupra afacerii și de urgența cu care trebuie furnizată o soluție sau o soluție. Țintele pentru rezolvarea incidentelor sau gestionarea cererilor sunt de obicei incluse în SLA. În practică, țintele de rezolvare a incidentelor sunt adesea asociate cu categorii. Exemple de categorii și priorități, precum și sistemele de codificare ale acestora, pot fi găsite în anexele 5A și, respectiv, 5B.

Biroul de service are un rol important de jucat în procesul de management al incidentelor:.

■ toate Incidentele sunt raportate Biroului de Asistență, iar angajații acestuia înregistrează Incidentele; în cazurile în care Incidentele sunt generate automat, procesul ar trebui să includă în continuare înregistrarea prin Service Desk.

■ majoritatea Incidentelor (poate până la 85% cu un nivel ridicat de abilități ale personalului) vor fi rezolvate de Biroul de Asistență;

■ Serviciul de service este un departament „independent” care supraveghează rezolvarea tuturor Incidentelor raportate.

Mai jos este o listă a principalelor acțiuni care sunt efectuate de Service Desk după primirea notificării unui Incident:.

■ înregistrarea informațiilor de bază – inclusiv ora și detaliile simptomelor primite;

■ Dacă se face o cerere de serviciu, cererea este procesată conform procedurilor standard ale organizației.

■ Pentru a completa înregistrarea incidentului pe baza CMDB, sunt selectate elementele contabile (CI) raportate ca fiind cauza incidentului.

■ stabilirea priorității corespunzătoare și transferarea către Utilizator a unui număr unic de Incident generat automat de sistem (pentru a-l raporta în timpul apelurilor ulterioare către serviciu);

■ Evaluarea Incidentului și, dacă este posibil, oferirea de recomandări pentru rezolvarea acestuia: acest lucru este adesea posibil pentru Incidente standard sau atunci când este cauzat de o Problemă/Eroare cunoscută;

■ Închiderea înregistrării incidentului după rezolvarea cu succes a acesteia: adăugarea detaliilor acțiunii de rezoluție și setarea codului de categorie corespunzător.

■ escaladarea unui Incident la o echipă de asistență de linie secundară (adică o echipă dedicată) după o încercare de rezolvare eșuată sau când se stabilește că este nevoie de un nivel mai ridicat de asistență.

5.3.5 Legături între incidente, probleme, erori cunoscute și cereri de modificare (RFC).

Incidentele rezultate din defecțiuni sau erori ale infrastructurii IT au ca rezultat abateri reale sau potențiale de la funcționarea planificată a serviciilor IT.

Cauza Incidentelor poate fi evidentă și nu este necesară nicio investigație suplimentară pentru a rezolva cauza. Acest lucru va avea ca rezultat o reparație, o soluție sau un RFC care va remedia eroarea. În unele cazuri, remediați incidentul în sine - de ex. impactul său asupra clientului poate fi destul de rapid. Este posibil ca o repornire a computerului sau reinițializarea canalului de comunicare să fie pur și simplu necesară, fără a identifica cauza de bază a Incidentului.

În cazurile în care cauza de bază a unui Incident este necunoscută, poate fi oportun să se înregistreze Problema. Deci, problema este de fapt un indicator al unei erori necunoscute în infrastructură. De obicei, o problemă este înregistrată numai atunci când necesitatea unei investigații este justificată de gravitatea problemei.

Impactul unei astfel de Probleme va fi adesea evaluat pe baza impactului (atât real, cât și potențial) asupra serviciilor de afaceri, precum și a numărului de Incidente similare raportate care pot avea aceeași cauză principală. Crearea unui cont de problemă poate fi adecvată chiar și după ce incidentul a fost rezolvat. Prin urmare, o înregistrare a problemei poate fi considerată independent de înregistrările sale asociate de incident și atât înregistrarea problemei, cât și investigația asupra cauzei acesteia pot continua chiar și după ce incidentul inițial a fost închis cu succes.

Procesarea cu succes a intrării Problemă va avea ca rezultat identificarea erorii de rădăcină; această intrare poate deveni o intrare de eroare cunoscută după ce este dezvoltată o soluție de soluție și/sau RFC. Acest lanț logic, de la notificarea inițială până la rezolvarea problemei inițiale, este prezentat în Figura 5.4.

Figura 5.4 - Relații între incidente, probleme, erori cunoscute și cereri de modificare (RFC).

Astfel, avem următoarele definiții:

■ Problemă: Cauza principală necunoscută a unuia sau mai multor Incidente.

■ Eroare cunoscută: o problemă care a fost diagnosticată cu succes și pentru care este cunoscută o soluție.

■ RFC: Solicitare de modificare a oricărei componente a unei infrastructuri IT sau a oricărui aspect al unui serviciu IT.

Problema poate duce la multe Incidente; de asemenea, este posibil ca o problemă să nu fie diagnosticată până când nu au avut loc mai multe Incidente într-o anumită perioadă de timp. Gestionarea problemelor este destul de diferită de Gestionarea incidentelor și, prin urmare, este acoperită de procesul de management al problemelor.

În timpul procesului de rezolvare, incidentul este verificat pentru legături în baza de date Probleme și erori cunoscute. De asemenea, ar trebui verificat pentru link-uri în baza de date de incidente pentru a determina dacă există Incidente similare deschise și dacă Incidente similare anterioare au fost rezolvate. Dacă o soluție sau o soluție este deja disponibilă, incidentul poate fi rezolvat imediat. În caz contrar, procesul de gestionare a incidentelor este responsabil pentru rezolvarea sau găsirea unei soluții alternative cu întreruperi minime ale procesului de afaceri.

Când Managementul incidentelor găsește o soluție, aceasta va fi revizuită de echipa de management al problemelor, care va actualiza apoi înregistrarea corespunzătoare a problemei (vezi Figura 5.5). Trebuie remarcat faptul că este posibil să nu existe încă o înregistrare a problemei corespunzătoare în acest moment, de exemplu, o soluție ar putea fi trimiterea prin fax a unui raport din cauza unei eșecuri a legăturii, dar o înregistrare a problemei pentru acea eșec a conexiunii poate să nu existe; în acest caz, echipa de management al problemelor trebuie să-l creeze. Deci, procesul include activități în care Service Desk leagă Incidentele care sunt rezultatul unei probleme înregistrate.

Figura 5.5 - Soluții de procesare și soluții de incidente.

De asemenea, este posibil ca echipa de management al problemelor, în timp ce investighează o problemă asociată cu un incident, să găsească o soluție sau o soluție pentru problema în sine și/sau pentru unele incidente conexe. În acest caz, echipa de management al problemelor trebuie să raporteze acest lucru procesului de gestionare a incidentelor pentru a schimba starea Incidentelor deschise în Eroare cunoscută sau Închis.

Atunci când, la momentul depunerii unui Incident, se presupune că Incidentul ar trebui tratat ca o Problemă, atunci acesta ar trebui să fie trimis imediat la procesul de management al problemelor, unde, dacă este necesar, este emisă o nouă înregistrare a problemei. Procesul de management al incidentelor va fi, ca întotdeauna, responsabil pentru continuarea lucrului la rezolvarea incidentului pentru a minimiza impactul acestuia asupra proceselor de afaceri.

Activ Ediție de la 27.12.2007

Numele documentului	"STANDARD NATIONAL AL ​​FEDERATIEI RUSA. TEHNOLOGIA INFORMATIEI. METODE SI MIJLOACE DE SECURITATE. MANAGEMENTUL INCIDENTELOR DE SECURITATE A INFORMATIILOR. GOST R ISO/IEC TO 18044-2007"
Tip de document	ordine, standard, gust
Corpul gazdă	Rostekhregulirovanie
numarul documentului	18044-2007
Data acceptarii	01.01.1970
Data revizuirii	27.12.2007
Data înregistrării în Ministerul Justiției	01.01.1970
stare	valabil
Publicare	La momentul includerii în baza de date, documentul nu a fost publicat
Navigator	Note

"STANDARD NATIONAL AL ​​FEDERATIEI RUSA. TEHNOLOGIA INFORMATIEI. METODE SI MIJLOACE DE SECURITATE. MANAGEMENTUL INCIDENTELOR DE SECURITATE A INFORMATIILOR. GOST R ISO/IEC TO 18044-2007"

6 Exemple de incidente de securitate a informațiilor și cauzele acestora

Incidentele de securitate a informațiilor pot fi intenționate sau accidentale (de exemplu, rezultatul unui fel de eroare umană sau fenomene naturale) și sunt cauzate atât de mijloace tehnice, cât și non-tehnice. Consecințele acestora pot fi evenimente precum dezvăluirea sau modificarea neautorizată a informațiilor, distrugerea acestora sau alte evenimente care le fac inaccesibile, precum și deteriorarea sau furtul bunurilor organizaționale. Incidentele de securitate a informațiilor care nu au fost raportate dar au fost identificate ca incidente nu pot fi investigate și nu pot fi aplicate măsuri de protecție pentru a preveni reapariția acestor incidente.

Următoarele sunt câteva exemple de incidente de securitate a informațiilor și cauzele acestora, care sunt furnizate doar în scopul clarificării. Este important de menționat că aceste exemple nu sunt exhaustive.

6.1 Refuzarea serviciului

Refuzarea serviciului este o categorie largă de incidente de securitate a informațiilor cu un lucru în comun.

Astfel de incidente de securitate a informațiilor duc la incapacitatea sistemelor, serviciilor sau rețelelor de a continua să funcționeze cu aceeași performanță, cel mai adesea cu refuzul complet de acces utilizatorilor autorizați.

Există două tipuri principale de incidente de securitate a informațiilor de denial-of-service generate prin mijloace tehnice: distrugerea resurselor și epuizarea resurselor.

Câteva exemple tipice de astfel de incidente tehnice deliberate de refuzare a serviciului sunt:

Verificarea adreselor de difuzare a rețelei pentru a umple complet lățimea de bandă a rețelei cu trafic de mesaje de răspuns;

Transferarea datelor într-un format neintenționat către un sistem, serviciu sau rețea în încercarea de a perturba sau perturba funcționarea normală a acestuia;

Deschiderea mai multor sesiuni către un anumit sistem, serviciu sau rețea în același timp, în încercarea de a le epuiza resursele (adică, le încetinește, le blochează sau le distruge).

Unele incidente tehnice de refuzare a serviciului pot apărea accidental, de exemplu, ca urmare a unei erori de configurare făcută de operator sau din cauza incompatibilității software-ului aplicației, în timp ce altele pot fi intenționate. Unele incidente tehnice de refuzare a serviciului sunt inițiate în mod deliberat pentru a distruge un sistem, un serviciu și pentru a reduce performanța rețelei, în timp ce altele sunt doar produse secundare ale altor activități rău intenționate.

De exemplu, unele dintre cele mai comune metode de scanare și identificare ascunse pot duce la distrugerea completă a sistemelor sau serviciilor vechi sau configurate greșit atunci când sunt scanate. Trebuie remarcat faptul că multe incidente tehnice deliberate de refuzare a serviciului sunt adesea inițiate anonim (adică sursa atacului este necunoscută), deoarece atacatorul de obicei nu primește informații despre rețeaua sau sistemul atacat.

Incidentele de securitate a informațiilor de refuz de serviciu create prin mijloace non-tehnice și care conduc la pierderea de informații, servicii și (sau) dispozitive de procesare a informațiilor pot fi cauzate, de exemplu, de următorii factori:

Încălcări ale sistemelor de protecție fizică care conduc la furt, deteriorarea intenționată sau distrugerea echipamentelor;

Deteriorarea accidentală a echipamentului și/sau a amplasării acestuia prin incendiu sau apă/inundație;

Condiții de mediu extreme, cum ar fi temperaturi ridicate (din cauza defecțiunii sistemului de aer condiționat);

Funcționare necorespunzătoare sau supraîncărcare a sistemului;

Schimbări necontrolate în sistem;

Software sau hardware defect.

6.2 Colectarea informațiilor

În termeni generali, incidentele de securitate a informațiilor din „strângerea de informații” implică activități legate de identificarea potențialelor ținte de atac și obținerea unei perspective asupra serviciilor care rulează pe țintele de atac identificate. Astfel de incidente de securitate a informațiilor necesită recunoaștere pentru a determina:

Având o țintă, obținerea unei idei despre topologia rețelei care o înconjoară și cu cine este asociată de obicei această țintă cu schimbul de informații;

Potențiale vulnerabilități în țintă sau în mediul său imediat de rețea care pot fi exploatate.

Exemple tipice de atacuri care vizează colectarea de informații prin mijloace tehnice sunt:

Eliminarea înregistrărilor DNS (Domain Name System) pentru domeniul Internet țintă (transfer zonă DNS);

Trimiterea cererilor de testare către adrese aleatoare ale rețelei pentru a găsi sisteme de lucru;

Sondarea sistemului pentru a identifica (de exemplu, prin suma de verificare a fișierelor) sistemul de operare gazdă;

Scanarea porturilor de rețea disponibile pentru sistemul de protocol de transfer de fișiere pentru a identifica serviciile corespunzătoare (de exemplu, e-mail, protocol FTP, rețea etc.) și versiunile software ale acestor servicii;

Scanarea unuia sau mai multor servicii cu vulnerabilități cunoscute pe o serie de adrese de rețea (scanare orizontală).

În unele cazuri, colectarea de informații tehnice se extinde în acces neautorizat dacă, de exemplu, un atacator încearcă să obțină acces neautorizat în timp ce caută o vulnerabilitate. Acest lucru este realizat de obicei prin instrumente automate de hacking care nu numai că caută vulnerabilități, ci și încearcă automat să exploateze sisteme, servicii și/sau rețele vulnerabile.

Incidentele de culegere de informații create prin mijloace non-tehnice au ca rezultat:

Dezvăluirea sau modificarea directă sau indirectă a informațiilor;

Furt de proprietate intelectuală stocată în formă electronică;

Încălcarea contabilității, de exemplu, la înregistrarea conturilor;

Utilizarea greșită a sistemelor de informații (de exemplu, cu încălcarea legii sau a politicii organizaționale).

Incidentele pot fi cauzate, de exemplu, de următorii factori:

Încălcări ale protecției securității fizice care conduc la acces neautorizat la informații și furtul dispozitivelor de stocare care conțin date sensibile, cum ar fi cheile de criptare;

Sisteme de operare prost și/sau configurate greșit din cauza modificărilor necontrolate ale sistemului sau a unui comportament necorespunzător al software-ului sau al hardware-ului care are ca rezultat accesul personalului organizațional sau neautorizat la informații fără autorizație.

6.3 Acces neautorizat

Accesul neautorizat ca tip de incident include incidente care nu sunt incluse în primele două tipuri. Acest tip de incident constă în principal în încercări neautorizate de a accesa un sistem sau în utilizarea greșită a unui sistem, serviciu sau rețea. Câteva exemple de acces neautorizat prin mijloace tehnice includ:

Încercări de extragere a fișierelor cu parole;

Atacurile de depășire a tamponului pentru a obține acces privilegiat (de exemplu, la nivel de administrator de sistem) la rețea;

Exploatarea vulnerabilităților protocolului pentru a intercepta o conexiune sau falsificarea conexiunilor de rețea legitime;

Încercările de a extinde privilegiile de acces la resurse sau informații dincolo de ceea ce are un utilizator sau un administrator în mod legitim.

Incidentele de acces neautorizat create prin mijloace non-tehnice care au ca rezultat dezvăluirea sau modificarea directă sau indirectă a informațiilor, încălcări ale înregistrărilor sau utilizarea greșită a sistemelor de informații pot fi cauzate de următorii factori:

Distrugerea dispozitivelor de protecție fizică cu acces ulterior neautorizat la informații;

Configurarea nereușită și/sau greșită a sistemului de operare din cauza modificărilor necontrolate ale sistemului sau a disfuncționalității software-ului sau hardware-ului, rezultând rezultate similare cu cele descrise în ultimul paragraf al 6.2.

marimea fontului

STANDARD NAȚIONAL AL ​​FEDERAȚIA RUSĂ - TEHNOLOGIA INFORMAȚIEI - METODE ȘI MIJLOACE DE SECURITATE - MANAGEMENT ... Relevant în 2018

6 Exemple de incidente de securitate a informațiilor și cauzele acestora

Incidentele de securitate a informațiilor pot fi intenționate sau accidentale (de exemplu, rezultatul unui fel de eroare umană sau fenomene naturale) și sunt cauzate atât de mijloace tehnice, cât și non-tehnice. Consecințele acestora pot fi evenimente precum dezvăluirea sau modificarea neautorizată a informațiilor, distrugerea acestora sau alte evenimente care le fac inaccesibile, precum și deteriorarea sau furtul bunurilor organizaționale. Incidentele de securitate a informațiilor care nu au fost raportate dar au fost identificate ca incidente nu pot fi investigate și nu pot fi aplicate măsuri de protecție pentru a preveni reapariția acestor incidente.

Următoarele sunt câteva exemple de incidente de securitate a informațiilor și cauzele acestora, care sunt furnizate doar în scopul clarificării. Este important de menționat că aceste exemple nu sunt exhaustive.

6.1 Refuzarea serviciului

Refuzarea serviciului este o categorie largă de incidente de securitate a informațiilor cu un lucru în comun.

Astfel de incidente de securitate a informațiilor duc la incapacitatea sistemelor, serviciilor sau rețelelor de a continua să funcționeze cu aceeași performanță, cel mai adesea cu refuzul complet de acces utilizatorilor autorizați.

Există două tipuri principale de incidente de securitate a informațiilor de denial-of-service generate prin mijloace tehnice: distrugerea resurselor și epuizarea resurselor.

Câteva exemple tipice de astfel de incidente tehnice deliberate de refuzare a serviciului sunt:

Verificarea adreselor de difuzare a rețelei pentru a umple complet lățimea de bandă a rețelei cu trafic de mesaje de răspuns;

Transferarea datelor într-un format neintenționat către un sistem, serviciu sau rețea în încercarea de a perturba sau perturba funcționarea normală a acestuia;

Deschiderea mai multor sesiuni către un anumit sistem, serviciu sau rețea în același timp, în încercarea de a le epuiza resursele (adică, le încetinește, le blochează sau le distruge).

Unele incidente tehnice de refuzare a serviciului pot apărea accidental, de exemplu, ca urmare a unei erori de configurare făcută de operator sau din cauza incompatibilității software-ului aplicației, în timp ce altele pot fi intenționate. Unele incidente tehnice de refuzare a serviciului sunt inițiate în mod deliberat pentru a distruge un sistem, un serviciu și pentru a reduce performanța rețelei, în timp ce altele sunt doar produse secundare ale altor activități rău intenționate.

De exemplu, unele dintre cele mai comune metode de scanare și identificare ascunse pot duce la distrugerea completă a sistemelor sau serviciilor vechi sau configurate greșit atunci când sunt scanate. Trebuie remarcat faptul că multe incidente tehnice deliberate de refuzare a serviciului sunt adesea inițiate anonim (adică sursa atacului este necunoscută), deoarece atacatorul de obicei nu primește informații despre rețeaua sau sistemul atacat.

Incidentele de securitate a informațiilor de refuz de serviciu create prin mijloace non-tehnice și care conduc la pierderea de informații, servicii și (sau) dispozitive de procesare a informațiilor pot fi cauzate, de exemplu, de următorii factori:

Încălcări ale sistemelor de protecție fizică care conduc la furt, deteriorarea intenționată sau distrugerea echipamentelor;

Deteriorarea accidentală a echipamentului și/sau a amplasării acestuia prin incendiu sau apă/inundație;

Condiții de mediu extreme, cum ar fi temperaturi ridicate (din cauza defecțiunii sistemului de aer condiționat);

Funcționare necorespunzătoare sau supraîncărcare a sistemului;

Schimbări necontrolate în sistem;

Software sau hardware defect.

6.2 Colectarea informațiilor

În termeni generali, incidentele de securitate a informațiilor din „strângerea de informații” implică activități legate de identificarea potențialelor ținte de atac și obținerea unei perspective asupra serviciilor care rulează pe țintele de atac identificate. Astfel de incidente de securitate a informațiilor necesită recunoaștere pentru a determina:

Având o țintă, obținerea unei idei despre topologia rețelei care o înconjoară și cu cine este asociată de obicei această țintă cu schimbul de informații;

Potențiale vulnerabilități în țintă sau în mediul său imediat de rețea care pot fi exploatate.

Exemple tipice de atacuri care vizează colectarea de informații prin mijloace tehnice sunt:

Eliminarea înregistrărilor DNS (Domain Name System) pentru domeniul Internet țintă (transfer zonă DNS);

Trimiterea cererilor de testare către adrese aleatoare ale rețelei pentru a găsi sisteme de lucru;

Sondarea sistemului pentru a identifica (de exemplu, prin suma de verificare a fișierelor) sistemul de operare gazdă;

Scanarea porturilor de rețea disponibile pentru sistemul de protocol de transfer de fișiere pentru a identifica serviciile corespunzătoare (de exemplu, e-mail, protocol FTP, rețea etc.) și versiunile software ale acestor servicii;

Scanarea unuia sau mai multor servicii cu vulnerabilități cunoscute pe o serie de adrese de rețea (scanare orizontală).

În unele cazuri, colectarea de informații tehnice se extinde în acces neautorizat dacă, de exemplu, un atacator încearcă să obțină acces neautorizat în timp ce caută o vulnerabilitate. Acest lucru este realizat de obicei prin instrumente automate de hacking care nu numai că caută vulnerabilități, ci și încearcă automat să exploateze sisteme, servicii și/sau rețele vulnerabile.

Incidentele de culegere de informații create prin mijloace non-tehnice au ca rezultat:

Dezvăluirea sau modificarea directă sau indirectă a informațiilor;

Furt de proprietate intelectuală stocată în formă electronică;

Încălcarea contabilității, de exemplu, la înregistrarea conturilor;

Utilizarea greșită a sistemelor de informații (de exemplu, cu încălcarea legii sau a politicii organizaționale).

Incidentele pot fi cauzate, de exemplu, de următorii factori:

Încălcări ale protecției securității fizice care conduc la acces neautorizat la informații și furtul dispozitivelor de stocare care conțin date sensibile, cum ar fi cheile de criptare;

Sisteme de operare prost și/sau configurate greșit din cauza modificărilor necontrolate ale sistemului sau a unui comportament necorespunzător al software-ului sau al hardware-ului care are ca rezultat accesul personalului organizațional sau neautorizat la informații fără autorizație.

6.3 Acces neautorizat

Accesul neautorizat ca tip de incident include incidente care nu sunt incluse în primele două tipuri. Acest tip de incident constă în principal în încercări neautorizate de a accesa un sistem sau în utilizarea greșită a unui sistem, serviciu sau rețea. Câteva exemple de acces neautorizat prin mijloace tehnice includ:

Încercări de extragere a fișierelor cu parole;

Atacurile de depășire a tamponului pentru a obține acces privilegiat (de exemplu, la nivel de administrator de sistem) la rețea;

Exploatarea vulnerabilităților protocolului pentru a intercepta o conexiune sau falsificarea conexiunilor de rețea legitime;

Încercările de a extinde privilegiile de acces la resurse sau informații dincolo de ceea ce are un utilizator sau un administrator în mod legitim.

Incidentele de acces neautorizat create prin mijloace non-tehnice care au ca rezultat dezvăluirea sau modificarea directă sau indirectă a informațiilor, încălcări ale înregistrărilor sau utilizarea greșită a sistemelor de informații pot fi cauzate de următorii factori:

Distrugerea dispozitivelor de protecție fizică cu acces ulterior neautorizat la informații;

Configurarea nereușită și/sau greșită a sistemului de operare din cauza modificărilor necontrolate ale sistemului sau a disfuncționalității software-ului sau hardware-ului, rezultând rezultate similare cu cele descrise în ultimul paragraf al 6.2.

Această carte poate fi numită o enciclopedie practică. Acesta oferă o acoperire maximă a problemelor de securitate a informațiilor, începând cu abordări moderne, o revizuire a suportului de reglementare în lume și în Rusia și terminând cu luarea în considerare a domeniilor specifice de securitate a informațiilor (asigurarea securității informațiilor la perimetru, contracararea atacurilor, monitorizarea securitatea informațiilor, rețele private virtuale și multe altele), soluții hardware și software specifice în acest domeniu. Cartea va fi utilă conducătorilor de afaceri ai companiilor și celor a căror competență include rezolvarea problemelor tehnice de securitate a informațiilor.

Toate drepturile rezervate. Nicio parte a acestei cărți nu poate fi reprodusă sub nicio formă sau prin orice mijloc, inclusiv postarea pe Internet și în rețelele corporative, precum și înregistrarea în memoria computerului pentru uz privat sau public, fără permisiunea scrisă a deținătorului drepturilor de autor. Pentru organizarea accesului la biblioteca electronică a editurii vă rugăm să contactați

mailto:% [email protected]

[email protected]

În plus, la 26 noiembrie 2004, restul de șase suspecți au fost reținuți, inclusiv trei angajați ai serviciului de abonați al VimpelCom însuși. În timpul anchetei, s-a dovedit că site-ul a fost creat de un fost student al Universității de Stat din Moscova, care nu a lucrat pentru această companie.

Procesul pe marginea acestui incident a devenit posibilă datorită deciziei Curții Constituționale, pronunțată în 2003, care a recunoscut că detaliile apelurilor conțin secretul convorbirilor telefonice, protejat de lege.

Oportunități din interior

Doi dintre angajații Vimpelcom identificați printre participanții la incident lucrau ca casier în companie, iar al treilea era un fost angajat și, la momentul crimei, lucra la piața Mitinsky.

Lucrarea în cadrul companiei în calitate de casier indică faptul că acești angajați au avut acces direct la informațiile oferite spre vânzare pe site-ul www.sherlok.ru. În plus, întrucât fostul angajat al companiei lucra deja pe piața Mitinsky, se poate presupune că, în timp, această piață ar putea deveni unul dintre canalele de distribuție pentru aceste informații sau orice alte informații din bazele de date VimpelCom.

Efecte

Principalele consecințe pentru VimpelCom ale acestui incident ar putea fi o lovitură adusă reputației companiei în sine și pierderea clienților. Cu toate acestea, acest incident a fost făcut public direct datorită acțiunilor active ale companiei însăși.

În plus, dezvăluirea acestor informații ar putea avea un impact negativ asupra clienților Vimpelcom, deoarece detaliile conversațiilor ne permit să tragem o concluzie despre activitățile curente ale abonatului, domeniul său de interes și cercul de cunoștințe.

În martie 2005, Tribunalul Districtual Ostankinsky din Moscova i-a condamnat pe suspecți, inclusiv trei angajați Vimpelcom, la diverse amenzi. Deci, organizatorul grupului a fost amendat cu 93.000 de ruble. Cu toate acestea, funcționarea site-ului www.sherlok.ru a fost încetată pe o perioadă nedeterminată abia de la 1 ianuarie 2008.

Cea mai mare încălcare a datelor cu caracter personal din istoria Japoniei

adnotare

În vara anului 2006, cea mai mare încălcare a datelor cu caracter personal din istoria Japoniei a avut loc atunci când un angajat al gigantului de imprimare și electronice Dai Nippon Printing a furat un disc care conținea informațiile private a aproape nouă milioane de cetățeni.

Descrierea incidentului

Firma japoneză Dai Nippon Printing, specializată în producția de produse de imprimare, a făcut cea mai mare scurgere din istoria țării sale. Hirofumi Yokoyama, un fost angajat al unuia dintre contractorii companiei, a copiat pe un hard disk mobil și a furat datele personale ale clienților companiei. În total, 8,64 milioane de persoane erau în pericol, deoarece informațiile furate conțineau nume, adrese, numere de telefon și numere de card de credit. Informațiile furate au inclus detalii despre clienți pentru 43 de companii diferite, cum ar fi 1.504.857 clienți American Home Assurance, 581.293 clienți Aeon Co și 439.222 clienți NTT Finance.

După ce a sustras aceste informații, Hirofumi a deschis un comerț cu informații private în porțiuni din 100.000 de înregistrări. Datorită unui venit stabil, insiderul și-a părăsit chiar locul de muncă permanent. Până la momentul arestării sale, Hirofumi reușise să vândă datele a 150.000 de clienți ai celor mai mari firme de credit unui grup de escroci specializați în cumpărături online. În plus, unele dintre date au fost deja folosite pentru fraudă cu cardul de credit.

Mai mult de jumătate dintre organizațiile cărora le-au fost furate datele clienților nici măcar nu au fost avertizate cu privire la scurgerea de informații.

Efecte

În urma acestui incident, pierderile cetățenilor care au suferit din cauza fraudei cu cardul de credit, care au devenit posibile doar ca urmare a acestei scurgeri, s-au ridicat la câteva milioane de dolari. În total, clienții a 43 de companii diferite au fost afectați, inclusiv Toyota Motor Corp., American Home Assurance, Aeon Co și NTT Finance. Cu toate acestea, mai mult de jumătate dintre organizații nici măcar nu au fost avertizate cu privire la scurgere.

Japonia a adoptat Legea privind protecția informațiilor personale din 2003 (PIPA) în 2003, dar procurorii nu au reușit să o aplice în procesul propriu-zis al cazului la începutul anului 2007. Procuratura nu a acuzat persoana din interior pentru încălcarea PIPA. El este acuzat doar că a furat un hard disk de 200 de dolari.

Nu este apreciat. Hacker din Zaporojie împotriva băncii ucrainene

adnotare

Fostul administrator de sistem al uneia dintre cele mai mari bănci din Ucraina a transferat circa 5 milioane de grivne prin banca unde lucra din contul vamei regionale în contul unei firme inexistente din Dnepropetrovsk falimentare.

Descrierea incidentului

Cariera de administrator de sistem a început după ce a absolvit o școală tehnică și a fost angajat de una dintre cele mai mari bănci din Ucraina în departamentul de software și hardware. După ceva timp, conducerea i-a observat talentul și a decis că va fi mai util băncii ca șef de departament. Cu toate acestea, apariția unui nou management în bancă a dus la schimbări de personal. I s-a cerut să-și părăsească temporar postul. Curând, noua conducere a început să-și formeze echipa, iar talentul lui a fost nerevendicat și i s-a oferit un post inexistent de șef adjunct, dar într-un alt departament. Ca urmare a unor astfel de remanieri de personal, a început să facă ceva complet diferit de ceea ce știa cel mai bine.

Administratorul de sistem nu a putut suporta o asemenea atitudine de management față de sine și și-a dat demisia din proprie voință. Cu toate acestea, era bântuit de propria mândrie și resentimente față de conducere, în plus, a vrut să demonstreze că este cel mai bun din domeniul său, și să se întoarcă la departamentul din care și-a început cariera.

După ce și-a dat demisia, fostul administrator de sistem a decis să-și recapete interesul față de persoana sa de la fosta conducere folosind imperfecțiunea sistemului Bancă-Client folosit în aproape toate băncile din Ucraina. Planul administratorului de sistem era ca acesta să decidă să-și dezvolte propriul program de protecție și să-l ofere băncii atunci când se întoarce la locul de muncă anterior. Implementarea planului a constat în pătrunderea sistemului „Băncă-Client” și efectuarea unor modificări minime la acesta. Întregul calcul a fost făcut pe faptul că banca ar fi trebuit să descopere un hack în sistem.

Pentru a pătrunde în acest sistem, fostul administrator de sistem a folosit parole și coduri pe care le-a învățat în timp ce lucra cu acest sistem. Toate celelalte informații necesare pentru hacking au fost obținute de pe diverse site-uri de hackeri, unde au fost descrise în detaliu diverse cazuri de hacking rețele de calculatoare, tehnici de hacking și a fost postat tot software-ul necesar pentru hacking.

După ce a creat o lacună în sistem, fostul administrator de sistem a pătruns periodic în sistemul informatic al băncii și a lăsat diverse semne în el, încercând să atragă atenția asupra faptelor de hacking. Specialiștii băncii trebuiau să detecteze hack-ul și să tragă alarma, dar, spre surprinderea lui, nimeni nu a observat nici măcar pătrunderea în sistem.

Apoi administratorul de sistem a decis să-și schimbe planul, făcându-i ajustări care nu puteau trece neobservate. A decis să falsifice un ordin de plată și să transfere o sumă mare de bani prin sistemul informatic al băncii. Folosind un laptop și un telefon mobil cu modem încorporat, administratorul de sistem a pătruns în sistemul informatic al băncii de aproximativ 30 de ori: a căutat prin documente, conturi clienți, flux de numerar - în căutarea clienților potriviți. Ca atare clienți, a ales vama regională și compania falimentară Dnepropetrovsk.

După ce a obținut din nou acces la sistemul băncii, a creat un ordin de plată, în care a retras 5 milioane de grivne din contul personal al vămii regionale și a transferat prin bancă în contul companiei falimentare. În plus, a făcut în mod deliberat mai multe greșeli în „plată”, care la rândul lor ar fi trebuit să atragă și mai mult atenția specialiștilor băncii. Cu toate acestea, nici măcar astfel de fapte nu au fost observate de specialiștii băncii care deservesc sistemul „Băncă-Client” și au transferat cu calm 5 milioane de grivne în contul unei companii care nu mai există.

De altfel, administratorul de sistem se aștepta ca fondurile să nu fie transferate, să fie depistat faptul de hacking înainte de transferul fondurilor, dar în practică totul a ieșit altfel și a devenit infractor, iar transferul său fals s-a transformat într-un furt.

Faptul de hacking și furt de fonduri la scară deosebit de mare a fost descoperit la doar câteva ore de la transfer, când angajații băncii au sunat la vamă pentru a confirma transferul. Dar au spus că nimeni nu a transferat o asemenea sumă. Banii au fost returnați de urgență înapoi la bancă, iar un dosar penal a fost deschis la parchetul din regiunea Zaporojie.

Efecte

Banca nu a suferit nicio pierdere, din moment ce banii au fost restituiti proprietarului, iar sistemul informatic a primit daune minime, drept urmare conducerea bancii a renuntat la orice pretentii la adresa fostului administrator de sistem.

În 2004, prin decretul președintelui Ucrainei, răspunderea penală pentru infracțiunile informatice a fost majorată: amenzi de la 600 la 1000 minime scutite de taxe, închisoare - de la 3 la 6 ani. Cu toate acestea, fostul administrator de sistem a comis infracțiunea înainte ca decretul prezidențial să intre în vigoare.

La începutul anului 2005 a avut loc un proces asupra administratorului de sistem. El a fost acuzat de săvârșirea unei infracțiuni în temeiul părții 2 a articolului 361 din Codul penal al Ucrainei - imixtiune ilegală în funcționarea sistemelor informatice cu cauzarea prejudiciului și în temeiul părții 5 a articolului 185 - furt săvârșit la scară deosebit de mare. Dar, deoarece conducerea băncii a refuzat orice pretenție împotriva lui, articolul pentru furt a fost eliminat de la el, iar partea 2 a articolului 361 a fost schimbată în partea 1 - interferență ilegală în funcționarea sistemelor informatice.

Tranzacționare necontrolată la Societe Generale

adnotare

Pe 24 ianuarie 2008, Societe Generale a anunțat o pierdere de 4,9 miliarde de euro din cauza mașinațiunilor comerciantului său Jérôme Kerviel. După cum arată o investigație internă, de câțiva ani traderul a deschis poziții over-limit în futures pentru indici bursieri europeni. Valoarea totală a pozițiilor deschise s-a ridicat la 50 de miliarde de euro.

Descrierea incidentului

Din iulie 2006 până în septembrie 2007, sistemul computerizat de control intern de 75 de ori (de câte ori Jerome Kerviel a efectuat tranzacții neautorizate sau pozițiile sale au depășit limita admisă) a emis un avertisment cu privire la posibile încălcări. Personalul de monitorizare a riscurilor din cadrul băncii nu a efectuat verificări detaliate asupra acestor avertismente.

Pentru prima dată, Kerviel a început să experimenteze tranzacțiile neautorizate în 2005. Apoi a luat o poziție scurtă pe acțiunile Allianz, așteptându-se ca piața să scadă. La scurt timp, piața a căzut cu adevărat (după atacurile teroriste de la Londra), așa că primii 500.000 de euro au fost câștigați. Despre sentimentele pe care le-a trăit de la primul său succes, Kerviel a povestit ulterior anchetei: „Știam deja să-mi închid postul și eram mândru de rezultat, dar în același timp am fost surprins. Succesul m-a obligat să continui, a fost ca un bulgăre de zăpadă... În iulie 2007, m-am oferit să iau o poziție scurtă în așteptarea unei căderi a pieței, dar nu am primit sprijinul managerului meu. Predicția mea s-a împlinit și am făcut profit, de data aceasta a fost destul de legal. Ulterior, am continuat să efectuez astfel de tranzacții pe piață, fie cu acordul autorităților, fie în lipsa obiecției lor explicite... Până la 31 decembrie 2007, profitul meu a ajuns la 1,4 miliarde de euro. În acel moment, nu știam cum să anunț acest lucru băncii mele, întrucât era o sumă foarte mare, nedeclarată nicăieri. Eram fericit și mândru, dar nu am știut să explic conducerii mele primirea acestor bani și să nu am suspiciune în efectuarea de tranzacții neautorizate. Prin urmare, am decis să-mi ascund profitul și să efectuez operațiunea fictivă opusă ... ".

De fapt, la începutul lunii ianuarie a acelui an, Jérôme Kerviel a reintrat în joc cu contracte futures pentru Euro Stoxx 50, DAX și FTSE trei indici, ceea ce l-a ajutat să învingă piața la sfârșitul anului 2007 (deși a preferat să ia o poziție scurtă). apoi). Potrivit estimărilor, în portofoliul său în ajunul zilei de 11 ianuarie existau 707,9 mii futures (fiecare în valoare de 42,4 mii euro) pe Euro Stoxx 50, 93,3 mii futures (192,8 mii euro pe 1 bucată) pe DAX și 24,2 mii futures (82,7 mii euro). euro pentru 1 contract) pe indicele FTSE. În general, poziția speculativă a lui Kerviel era egală cu 50 de miliarde de euro, adică era mai mult decât valoarea băncii în care lucra.

Cunoscând ora controalelor, a deschis la momentul potrivit o poziție de acoperire fictivă, pe care a închis-o ulterior. Drept urmare, recenzenții nu au văzut niciodată o singură poziție care ar putea fi numită riscantă. Aceștia nu au putut fi alertați de cantități mari de tranzacții, care sunt destul de comune pentru piața de contracte futures pentru indici. A fost dezamăgit de tranzacțiile fictive efectuate din conturile clienților băncilor. Utilizarea conturilor diferiților clienți bănci nu a dus la probleme vizibile controlorilor. Cu toate acestea, după o anumită perioadă de timp, Kerviel a început să folosească conturile acelorași clienți, ceea ce a dus la activitatea „anormală” observată în aceste conturi și, la rândul său, a atras atenția controlorilor. Acesta a fost sfârșitul înșelătoriei. S-a dovedit că partenerul lui Kerviel în afacerea de mai multe miliarde de dolari era o mare bancă germană, care ar fi confirmat tranzacția astronomică prin e-mail. Cu toate acestea, confirmarea electronică a stârnit suspiciuni în rândul inspectorilor, pentru care a fost creată o comisie la Societe Generale pentru verificare. Pe 19 ianuarie, ca răspuns la o solicitare, banca germană nu a recunoscut această tranzacție, după care comerciantul a acceptat să facă o mărturisire.

Când a fost descoperită dimensiunea astronomică a poziției speculative, CEO-ul și președintele consiliului de administrație al Societe Generale, Daniel Bouton, și-a anunțat intenția de a închide poziția riscantă deschisă de Kerviel. A durat două zile și s-a soldat cu o pierdere de 4,9 miliarde de euro.

Oportunități din interior

Jerome Kerviel a lucrat timp de cinci ani în așa-numitul back office al băncii, adică într-o divizie care nu încheie direct nicio tranzacție. Se ocupă doar de contabilitate, executarea și înregistrarea tranzacțiilor și controlează comercianții. Această activitate a făcut posibilă înțelegerea caracteristicilor funcționării sistemelor de control din bancă.

În 2005, Kerviel a fost promovat. A devenit un adevărat comerciant. Responsabilitățile imediate ale tânărului au inclus operațiuni elementare de minimizare a riscurilor. Lucrând pe piața contractelor futures pentru indici bursieri europeni, Jerome Kerviel a trebuit să monitorizeze modul în care portofoliul de investiții al băncii se schimbă. Iar sarcina sa principală, după cum a explicat unul dintre reprezentanții Societe Generale, a fost să reducă riscurile jucând în direcția opusă: „În linii mari, văzând că banca pariază pe roșu, ar fi trebuit să parieze pe negru”. Ca toți comercianții juniori, Kerviel avea o limită pe care nu o putea depăși, foștii săi colegi din back office monitorizau acest lucru. Societe Generale avea mai multe niveluri de protecție, de exemplu, comercianții puteau deschide poziții doar de pe computerul lor de lucru. Toate datele despre pozițiile de deschidere au fost transmise automat în timp real către back office. Dar, după cum se spune, cel mai bun braconier este un fost pădurar. Și banca a făcut o greșeală de neiertat punându-l pe fostul pădurar în postura de vânător. Jérôme Kerviel, care avea aproape cinci ani de experiență în monitorizarea comercianților, nu a avut nicio dificultate în a ocoli acest sistem. Știa parolele altora, știa când se făceau cecuri la bancă și cunoștea bine tehnologia informației.

Motivele

Dacă Kerviel a fost implicat în fraude, nu a fost în scopul îmbogățirii personale. Așa spun avocații săi, iar reprezentanții băncii recunosc acest lucru, numind acțiunile lui Kerviel iraționale. Kerviel însuși spune că a acționat exclusiv în interesul băncii și a vrut doar să-și demonstreze talentele de comerciant.

Efecte

Activitățile sale din 2007 au adus băncii un profit de aproximativ 2 miliarde de euro. În orice caz, Kerviel însuși o spune, argumentând că conducerea băncii probabil știa ce face, dar a preferat să închidă ochii atâta timp cât avea profit.

Închiderea poziției riscante deschise de Kerviel a dus la o pierdere de 4,9 miliarde de euro.

În mai 2008, Daniel Bouton a demisionat din funcția de CEO al Societe Generale și a fost înlocuit în această funcție de Frédéric Oudéa. Un an mai târziu, a fost nevoit să demisioneze din funcția de președinte al consiliului de administrație al băncii. Motivul plecării a fost critica acerbă din partea presei: Buton a fost acuzat de faptul că managerii de vârf ai băncii controlate de el au încurajat tranzacțiile financiare riscante efectuate de angajații băncii.

În ciuda sprijinului consiliului de administrație, presiunea asupra domnului Buton a crescut. Demisia sa a fost cerută de acționarii băncii și de mulți politicieni francezi. De asemenea, președintele francez Nicolas Sarkozy i-a cerut lui Daniel Bouton să demisioneze după ce s-a știut că în anul și jumătate dinaintea scandalului, sistemul informatic de control intern al Societății Generale a emis un avertisment de aproximativ 75 de ori, adică de fiecare dată când Jerome Kerviel a efectuat operațiuni neautorizate. posibile încălcări.

Imediat după descoperirea pierderilor, Societe Generale a creat o comisie specială pentru a investiga acțiunile comerciantului, care includea membri independenți ai consiliului de administrație al băncii și auditori ai PricewaterhouseCoopers. Comisia a ajuns la concluzia că sistemul de control intern din bancă nu a fost suficient de eficient. Astfel, banca nu a putut preveni o astfel de fraudă majoră. Raportul precizează că „personalul băncii nu a verificat sistematic” activitățile comerciantului, iar banca însăși nu are „un sistem de control care ar putea preveni frauda”.

În raportul privind rezultatele verificării comerciantului se arată că, în urma investigației, s-a luat decizia de „întărire semnificativă a procedurii de supraveghere internă a activităților angajaților Societe Generale”. Acest lucru se va realiza printr-o organizare mai strictă a activității diferitelor departamente ale băncii și coordonarea interacțiunii acestora. De asemenea, vor fi luate măsuri de urmărire și personalizare a operațiunilor de tranzacționare ale angajaților băncii prin „consolidarea sistemului de securitate IT și dezvoltarea de soluții de înaltă tehnologie pentru identificarea personală (biometrie)”.