Tratarea incidentelor de securitate a informațiilor. Investigarea incidentului fără întârziere. Analiza jurnalului OWA

Procesul de management al incidentelor

Din păcate, lumea nu este ideală. Acest lucru este valabil și pentru serviciile IT. La furnizarea serviciilor IT, pot apărea eșecuri: serviciul poate deveni indisponibil, poate funcționa cu erori sau poate fi primit acces neautorizat la informare etc. Aceste. Pot apărea abateri negative de la prestarea normală a serviciilor. Î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 eșecul unui disc într-o matrice de oglindire.

În unele cazuri, un incident 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ă apare un incident, atunci este necesar să se minimizeze impactul negativ al acestuia.

Cum să faci asta? Într-un caz - pentru a-l „remedia” cât mai repede posibil, în altul - pentru a restabili cele mai importante funcții în cel mai scurt timp posibil, în al treilea - pentru a aplica o soluție, etc.

Soluție - reducerea sau eliminarea impactului unui incident sau al unei probleme pentru care momentul actual Rezoluția completă nu este disponibilă.

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

Managementul incidentelor este un proces 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ă în cel mai rapid mod posibil.

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

• Asigurați utilizarea metodelor și procedurilor standard pentru un răspuns eficient și prompt, analiză, documentare, management continuu și raportare în timpul rezolvării incidentelor.
• Transparență și comunicare sporite la rezolvarea incidentelor dintre business și IT.
• Îmbunătățirea percepției afacerilor despre IT printr-o abordare profesională a soluționării incidentelor.
• Alinierea priorităților de rezolvare a incidentelor cu prioritățile de afaceri.
• Sprijinirea satisfacției utilizatorilor cu privire la calitatea serviciilor IT.

Activități în cadrul procesului de management al incidentelor

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

În cele mai multe cazuri, incidentele sunt înregistrate de Service Desk, unde sunt raportate. Toate incidentele trebuie înregistrate imediat după notificare 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 unui incident este posibilă numai dacă incidentul este înregistrat;
• incidentele înregistrate ajută la diagnosticarea noilor incidente;
• Managementul problemelor poate folosi incidentele înregistrate pentru a rezolva 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 monitorizeze 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 puse la dispoziția echipelor de asistență.

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 - incidente de același tip, tipuri KU - articole de configurare de același tip.

Clasificarea corectă a incidentelor ajută la redirecționarea lor direct către grupul doritși să analizeze incidentele din diverse perspective ș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) este o măsură a impactului unui incident asupra unui proces de afaceri.

Deci, de fapt, prioritatea este un număr determinat de 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 Impact. Pe baza prioritatii se stabileste ordinea in care se rezolva incidentele.

Prioritatea este stabilită ținând cont următorii 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 termene sunt, de asemenea, fixe. Incidentului i se atribuie un număr unic și utilizatorului este informat despre numărul incidentului pentru identificarea precisă a acestuia în timpul apelurilor ulterioare.

Direct atunci când un utilizator contactează specialiștii Service Desk, trebuie efectuată o diagnosticare preliminară a incidentului pentru a obține informațiile necesare pentru a determina cauza incidentului, dacă este posibil, precum și pentru clasificarea corectă și transferul la următoarea linie de asistență. Dacă rezolvarea incidentului este de competența angajatului Service Desk, atunci acesta poate fi rezolvat imediat. Service Desk transmite incidentele care nu au soluție gata făcută sau dincolo de competența angajatului care lucrează cu el, până la următorul nivel de echipă de suport cu experiență și cunoștințe vaste. Această echipă investighează și rezolvă incidentul sau îl escaladează la următorul nivel al echipei de asistență.

Pe parcursul procesului de rezolvare a incidentelor, diverși specialiști pot actualiza evidența incidentelor prin modificarea stării curente, informații despre acțiunile întreprinse, revizuirea clasificării și actualizarea orei și codului angajatului.

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

Escalare - activitate care vizează obținerea de resurse suplimentare atunci când este necesar pentru atingerea indicatorilor țintă nivelul de serviciu sau îndeplinirea așteptărilor clienților. O escaladare poate fi necesară în cadrul oricărui proces management IT-servicii, dar este cel mai adesea asociat cu gestionarea incidentelor, managementul 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, rezolvarea completă a unui incident nu este posibilă, impactul acestuia ar trebui, dacă este posibil, să fie 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.

Odată ce o soluție este implementată spre satisfacția utilizatorului, echipa de asistență escaladează incidentul înapoi la Service Desk. Service Desk contactează angajatul care a raportat incidentul pentru a obține 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 un incident este închis, trebuie să actualizați categoria finală, prioritatea, serviciile afectate de incident și elementul de configurare 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:
• Bună coordonare între utilizatori și gestionarea incidentelor
• Incidentele trebuie rezolvate într-un interval 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 ale afacerii
• Toate incidentele sunt gestionate și datele lor sunt stocate într-un sistem de management unificat
• Toate incidentele trebuie să aibă o schemă standard de clasificare care să corespundă proceselor de afaceri ale întreprinderii
• Înregistrările incidentelor trebuie revizuite în mod regulat pentru a asigura intrarea și clasificarea corectă.
• Toate înregistrările incidentelor, ori de câte ori este posibil, ar trebui să aibă un format comun și un set de câmpuri de informații

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

Scale de timp - Termenele trebuie convenite pentru toate etapele procesării incidentului (acestea vor varia în funcție de nivelul de prioritate al incidentului). Toate echipele de asistență trebuie să cunoască pe deplin 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, este recomandabil să se definească în prealabil modele de incidente „standard” și să le aplice atunci când apar incidente adecvate.

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 unui incident
• Perioadele de timp și procedurile de escaladare
• Dovada activității (înregistrări, jurnale)

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

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

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

Poziția incidentului în procesul de prelucrare este indicată de stare. Exemple de stări ar putea fi:

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

Indicatori de proces de management al incidentelor

Să gestioneze și să evalueze eficacitatea procesului de management al incidentelor și să asigure feedbackîmpreună cu alte 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 petrecut pentru rezolvarea unui 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)
• Mărimea cozii KPI a incidentelor nerezolvate pentru fiecare serviciu
• KPI Numărul și procentul de incidente semnificative (mare) pentru fiecare serviciu
• Asistență pentru satisfacția utilizatorilor CSF
• KPI Scorul mediu al sondajului realizat de utilizatori/clienți
• KPI Procentul de satisfacție al respondenților în comparație cu numărul total de respondenți care au participat la sondaj
• CSF Îmbunătățirea transparenței și comunicării în rezolvarea incidentelor între business și personalul de suport IT
• KPI Numărul mediu de apeluri de asistență sau alte contacte de utilizatori cu privire la 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 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 Asigurați-vă că sunt utilizate metode și proceduri standard pentru rezolvarea incidentelor
• KPI Numărul și procentul de incidente atribuite incorect
• KPI Numărul și procentul de incidente 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 posibile si dificultati:

• Necesitatea detectării timpurii a incidentelor - va fi necesară configurarea instrumentelor de management (monitorizare) a evenimentelor, precum și instruirea utilizatorilor pentru raportarea incidentelor
• Necesitatea înregistrării totale a incidentelor
• Necesitatea introducerii adecvate sistem automatizat managementul și asigurarea integrării acestuia cu diverse sisteme de management IT (de exemplu, CMS)
• Nevoia de disponibilitate ridicată a unui singur punct de contact
• Necesitatea de a asigura aderarea la proces și de a identifica cazurile de eludare a procedurilor de proces - în cazul în care utilizatorii rezolvă singuri erorile sau contactează direct specialiștii fără a urma procedurile stabilite, organizația IT nu va primi informații despre nivelul serviciului efectiv furnizat, numărul de erori , și multe altele. De asemenea, rapoartele către conducere nu vor reflecta în mod adecvat situația.
• Lipsa resurselor la rezolvarea incidentelor, supraîncărcarea cu incidente și amânarea „pentru mai târziu” - dacă există 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 un utilizator, devine necesar să-l deservim pe următorul. În acest caz, este posibil ca introducerea descrierilor incidentelor să nu fie suficient de precisă, iar procedurile de distribuire a incidentelor către organismele de sprijin nu vor fi efectuate corespunzător. Ca urmare, deciziile 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, procedura de alocare 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 rezonabil asistența pentru utilizatori.
• Lipsa angajamentului față de abordarea procesuală din partea conducerii și a personalului - Rezolvarea incidentelor folosind o abordare a procesului necesită de obicei o schimbare a culturii și un nivel mai ridicat de proprietate asupra muncii lor din partea personalului. Acest lucru poate provoca o rezistență semnificativă în cadrul organizației. Management eficient managementul incidentelor necesită ca angajații să înțeleagă și să se angajeze cu adevărat în abordarea procesului, mai degrabă decât să participe.

Valoarea afacerii

Prin implementarea unui proces de management al incidentelor în conformitate cu ghidurile ITIL și abordând orice provocări care pot apărea în timpul implementării, următoarea valoare poate fi atinsă pentru afacerea în ansamblu:

• Oportunitatea de a reduce munca neplanificată și costurile de afaceri și IT cauzate de incidente
• Abilitatea de a detecta și rezolva incidente, reducând timpul de nefuncționare și crescând disponibilitatea serviciilor de afaceri
• Abilitatea de a aloca resurse IT pe baza priorității afacerii
• Capacitatea de a iniția îmbunătățiri ale serviciilor pe baza cunoașterii naturii incidentelor
• Capacitatea de a identifica nevoile de formare suplimentară a personalului

Procesul de management al incidentelor oferă o vizibilitate semnificativă afacerii și permite ca rezultatele să fie văzute relativ rapid odată implementate. Prin urmare, managementul incidentelor este adesea unul dintre primele procese implementate în timpul tranziției la o organizație de management IT bazată pe procese. Un avantaj suplimentar al acestui lucru este că managementul incidentelor poate evidenția alte domenii ale managementului IT care necesită atenție - asigurând astfel că resursele necesare sunt alocate 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, îmbătrânirea infrastructurii sau modificări ale legislației.

Experiența arată că dacă schimbari nu sunt controlate corespunzător, ele pot duce adesea la incidente: întreruperi î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 noi incidente. Planificarea zilnică nu reușește adesea să se adapteze la volumul de lucru în creștere.

Schimbarea este adăugarea, modificarea sau eliminarea a ceva care poate avea un impact asupra serviciilor 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 serviciului 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 schimbărilor, facilitând implementarea schimbărilor benefice 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
• 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 aduse 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 în cadrul procesului de management al schimbării

Figura arată schema generala procesul de management al schimbării. Pentru a asigura controlul schimbărilor, toate modificările trebuie înregistrate. Dacă este necesar făcând o schimbare adică în sfera unui proces, trebuie depusă o cerere de modificare (RFC).

O cerere de modificare este o propunere oficială de a face o schimbare. O cerere de modificare include detalii despre modificarea propusă și poate fi scrisă pe hârtie sau formular 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:

Schimbare standard - o schimbare preautorizată, cu risc scăzut, relativ de rutină și care urmează o procedură sau instructiuni de lucru. De exemplu, resetarea unei parole sau furnizarea unui nou angajat cu echipament standard. Modificările standard nu necesită implementarea unui RFC, dar sunt înregistrate și urmărite folosind un alt mecanism, cum ar fi cererile de servicii.

O modificare de urgență este o modificare care trebuie implementată cât mai repede posibil, de exemplu pentru a rezolva un incident semnificativ sau pentru a instala o actualizare de securitate. Procesul de management al schimbării are de obicei o procedură specifică pentru gestionarea schimbărilor de urgență.

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

Prin urmare, dacă o modificare se încadrează în categoria standard, aceasta trebuie gestionată ca parte a procesului de gestionare a cererilor de servicii. este schimbare definitivă standard sau normal este stabilit pentru fiecare organizație în mod independent. Pentru schimbările de urgență, procedurile normale nu sunt utilizate, deoarece resursele necesare sunt puse la dispoziție 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 relevante;
• motivul schimbării, inclusiv rațiunea și rezultatul de afaceri așteptat;
• curent şi noua versiune element de configurare variabilă;
• numele, adresa și numărul de telefon ale persoanei care face cererea;
• data de depozit;
• 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 modificare - Un document care conține o descriere la nivel înalt a unui serviciu potențial sau a unei schimbări semnificative, cazul de afaceri asociat și programul 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. Procesul de management al schimbării evaluează impactul potențial asupra altor servicii, resurse partajate și planul general de schimbare.

Toate cererile de modificare primite trebuie înregistrate și trebuie creată o înregistrare de modificare pentru fiecare modificare. Înregistrare modificare - o înregistrare care conține informații detaliate despre modificare. Fiecare modificare înregistrează documente ciclu de viață

o singura schimbare. O înregistrare de modificare este creată pentru fiecare cerere de modificare primită, chiar dacă ulterior este respinsă.

După înregistrarea unei cereri de modificare (RFC), Change Management efectuează o verificare inițială pentru a vedea dacă cererile sunt neclare, ilogice, nepractice sau inutile. Asemenea cereri sunt respinse motivate. Angajatului care face cererea ar trebui să i se ofere întotdeauna posibilitatea de a-și apăra cererea.

• Pentru a evalua o schimbare, 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 riscuri sunt asociate cu schimbarea? (RISCURI) (Care sunt RISCURILE implicate în schimbare?)
• Ce resurse sunt necesare pentru implementarea schimbării? (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?)

Dacă o cerere de modificare (RFC) este acceptată, înregistrarea modificării include informațiile necesare procesării în continuare a modificării.

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

• prioritate atribuită;
• evaluarea impactului și costurilor implicate;
• categorie;
• recomandări din partea managerului procesului de management al schimbării;
• data și ora autorizației de modificare;
• data programată;
• plan de retur;
• cerințe de suport;
• planul de implementare a schimbării;
• 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.

Odată ce este primită o cerere de modificare (RFC), prioritatea și categoria acesteia sunt determinate. Prioritatea arată cât de importantă este o anumită cerere în comparație cu altele. Aceasta, la rândul său, este determinată de urgența și gradul de impact.

Exemplu de sistem de codificare cu prioritate:

• Prioritate scăzută - modificarea este de dorit, dar implementarea ei poate fi amânată până la un moment mai convenabil (de exemplu, până la următoarea lansare sau întreținere programată).
• Prioritatea obișnuită este urgența scăzută și impactul ridicat, dar schimbarea nu ar trebui amânată.
• Prioritate mare — Schimbarea se referă la o eroare majoră care afectează un număr de utilizatori, o nouă eroare atipică care afectează un grup mare de utilizatori sau alte probleme urgente.
• Cererea de modificare cu cea mai mare prioritate (RFC) abordează o problemă care are un impact semnificativ asupra unui serviciu critic pentru clienți. Modificările cu această prioritate sunt clasificate drept „de urgență”.

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

Consiliul pentru schimbări este 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: gradul scăzut = 1 / gradul cel mai înalt = 3

Cele mai multe modificări se încadrează în primele două categorii. Pe baza evaluării impactului schimbării, nivelul de autorizare a modificării (autoritatea de modificare) trebuie determinat, de exemplu, așa cum se arată în figură.

Pe lângă clasificare, trebuie identificate și grupurile implicate în 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.

Procesul de management al schimbării coordonează implementarea. Dezvoltarea, testarea și implementarea directă sunt realizate în cadrul procesului de management al realismului și implementării. Implementarea modificării are loc după ce rezultatele testelor au fost aprobate ca parte a procesului de management al schimbării.

Ca parte a procesului de management al schimbării, se menține un program de schimbare. Program de modificare - un document cu o listă a tuturor modificărilor aprobate și a datelor planificate pentru implementarea lor, precum și date aproximative

implementarea modificărilor ulterioare. Membrii comisiei de schimbare (CAB) oferă consiliere cu privire la schimbările de planificare, deoarece este necesar să se țină cont de disponibilitatea personalului, resurselor, costurilor, serviciile implicate, precum și opiniile clienților. Consiliul pentru schimbare (CAB) servește ca organism consultativ și se întrunește în mod regulat. Informațiile despre planificarea schimbării ar trebui diseminate înainte de ședința consiliului de schimbare. Documentația și informațiile relevante despre punctele de pe ordinea de zi ar trebui, de asemenea, distribuite înainte de întâlnire.

Ordinea de zi a unei reuniuni a consiliului de schimbare ar trebui să includă o serie de puncte permanente, inclusiv:

• Modificări nereușite sau neautorizate
• Solicitări de modificări (RFC) transmise pentru schimbarea membrilor consiliului de administrație în ordinea priorității
• Cererile de modificări (RFC) examinate de comisia de modificare
• Planificarea schimbării și actualizarea programului de modificări
• Evaluări ale modificărilor efectuate
• Procesul de management al schimbărilor, completări și modificări ale procesului
• Realizările procesului și beneficiile de afaceri obținute prin procesul de management al schimbării
• Modificări neterminate și modificări în curs
• Programați cererile de modificare pentru a fi luate în considerare la următoarea comisie de schimbare
• Verificați modificările neautorizate detectate de procesul de gestionare a configurației și a activelor de serviciu

Ca parte a designului general al schimbării, ar trebui dezvoltată o procedură de rollback în cazul în care modificarea nu atinge rezultatul dorit. Managementul schimbărilor nu ar trebui să aprobe o modificare fără o procedură de returnare.

Este necesar să se evalueze modificările efectuate, cu posibila excepție a modificărilor standard. Dacă este necesar, Consiliul pentru schimbare (CAB) decide asupra măsurilor suplimentare ulterioare.

• Ar trebui luate în considerare următoarele aspecte:
• Schimbarea și-a atins obiectivele?
• Sunt utilizatorii și clienții mulțumiți?
• Ceva efecte secundare?
• Au fost folosite resursele pentru a implementa schimbarea conform planificării?
• Schimbarea a fost implementată la timp și fără depășiri de costuri?
• Planul de implementare a funcționat corect?
• Planul de recuperare a funcționat corect atunci când a fost nevoie?

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 este reluat 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.

Revizuirea rezultatelor implementării (PIR) - O revizuire efectuată după implementarea unei schimbări sau a unui proiect.

Evaluarea rezultatelor implementării determină succesul schimbării sau al proiectului și identifică oportunități 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, evaluarea unei modificări a unui computer personal utilizat zilnic poate dura câteva zile, dar o modificare a unui sistem utilizat o dată pe săptămână poate dura trei luni.

Efectuarea modificărilor 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 trebuie implementate cât mai curând posibil. Acestea necesită proceduri separate pentru procesarea urgentă, dar păstrează controlul general din procesul de management al schimbării. Dacă apare această situație, se poate organiza o reuniune a comisiei de schimbare de urgență (eCAB).

Emergency Change Board (eCAB) - un grup de persoane din cadrul Change Board care iau decizii cu privire la schimbările de urgență. Decizia privind componența participanților la consiliu pentru modificări urgente poate fi luată direct la organizarea ședinței. Necesitatea participării este determinată în funcție de natura schimbării urgente.

Dacă nu există timp pentru a face acest lucru sau dacă cererea este primită în afara orelor de lucru, trebuie să existe o metodă alternativă de obținere a autorizației de modificare. Aceasta nu trebuie să fie o întâlnire față în față, ci poate fi organizată o 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:
• Categorizarea schimbărilor, de exemplu modificări inovatoare, exploratorii, preventive, corective
• Determinarea responsabilității pentru schimbări în toate etapele ciclului de viață al serviciului
• Împărțirea responsabilităților de management
• Creați un singur punct de responsabilitate pentru schimbări pentru a reduce probabilitatea unor schimbări conflictuale și riscul de perturbare a mediului de producție

Indicatori de proces de management al schimbării

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 unei modificări exprimat ca „valoarea îmbunătățirilor aduse” + „impactul negativ evitat” în comparație cu costul implementării modificării
• Reduceți întreruperile serviciului, defectele și reluările cauzate de specificații inexacte sau de evaluarea impactului insuficientă
• Reducerea numărului de modificări neautorizate
• Reducerea stocului de cereri de modificare, a procentului de modificări neplanificate și remedieri urgente
• 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 de schimbare
• Acuratețea evaluării schimbării

Valoarea afacerii

Prin implementarea unui proces de management al schimbării în conformitate cu ghidurile ITIL și abordând orice provocări care pot apărea în timpul implementării, următoarea valoare poate fi atinsă 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 de serviciu convenite într-o manieră rentabilă
• Reducerea numărului de modificări nereușite care duc la întreruperi ale serviciului, defecte și reluări
• Efectuarea modificărilor conform intervalelor de timp definite de afacere
• Urmăriți modificările din ciclul de viață al serviciului și al activelor clienților dvs
• O estimare mai bună a calității, timpului și costului schimbării
• Evaluarea riscurilor asociate cu schimbările de serviciu (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
• Reducerea timpului mediu de recuperare prin implementarea modificărilor corective mai rapid și cu succes
• Asigurați legătura 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 că da. Unul dintre obiectivele principale ale ITSM, dar și ITIL, este furnizarea de servicii IT de înaltă calitate.

Controla servicii IT ami (managementul serviciilor IT, ITSM) - implementarea și managementul serviciilor IT de înaltă calitate, care răspund nevoilor afacerii.

Furnizorii de servicii IT și clienții nu sunt întotdeauna de acord cu privire la calitatea serviciilor.

Calitatea este capacitatea unui produs, serviciu sau proces de a oferi valoarea așteptată de client.

De exemplu, o componentă poate fi considerată a fi de înaltă calitate dacă funcționează conform așteptărilor și atinge fiabilitatea necesară.

Cele de mai sus este definiția ITIL a calității. Aceste. Daca dorim sa oferim servicii de calitate, este necesar ca acestea sa corespunda asteptarilor clientului.

După cum spune celebrul proverb: „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 cu privire la serviciile IT, să le convingem, eventual să le limităm într-un fel, de exemplu, dacă cerința clientului este nerealistă, și să le prezentăm în formă măsurabilă. Următorul pas este să vă asigurați că parametrii actuali ai serviciului îndeplinesc așteptările clientului și să confirmați acest lucru prin furnizarea de rapoarte adecvate.

Conform ITIL, procesul de management al nivelului de servicii este responsabilitatea de a conveni și documenta obiectivele și responsabilitățile de nivel de serviciu în acordul de nivel de serviciu (SLA) și cerințele de nivel de serviciu (SLR) pentru fiecare serviciu și activitățile IT asociate pentru fiecare serviciu IT organizație furnizor.

Acordul de nivel de serviciu (SLA) este un acord între un furnizor de servicii IT și un client. Acordul de nivel de serviciu descrie serviciul IT, documentează obiectivele de nivel de serviciu și indică 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 țintelor de nivel de serviciu, managementul nivelului de serviciu stabilește cerințele și parametrii de operare 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 - obligațiile prevăzute în contractul de nivel de serviciu. Țintele de nivel de serviciu se bazează pe cerințele nivelului de serviciu și sunt necesare pentru a se asigura că serviciul 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 de nivel de serviciu sunt în concordanță cu și reflectă cu acuratețe cerințele de afaceri, atunci serviciul furnizat de furnizorii de servicii va fi aliniat cu cerințele de afaceri și va îndeplini așteptările clienților și utilizatorilor privind calitatea serviciilor. Dacă obiectivele nu se aliniază cu nevoile 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 - Nivelul de garanție sau asigurare cu privire la nivelul calității serviciilor oferite 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:
• Determinați, documentați, conveniți, monitorizați, raportați și evaluați nivelul serviciilor IT furnizate
• Mențineți și îmbunătățiți relațiile și comunicațiile cu companiile și clienții
• Asigurați-vă că există obiective clare și măsurabile pentru toate serviciile IT
• Asigurați-vă că așteptările privind nivelul IT și al clienților sunt clare și lipsite de ambiguitate
• Asigurați-vă că îmbunătățirile proactive ale nivelului de servicii sunt implementate acolo unde este fezabil și rațional.

Managementul nivelului de servicii ar trebui să asigure comunicarea și comunicarea constantă între managerii organizațiilor clienților și companiilor. Acest lucru ar trebui să ofere informații afacerii despre furnizorul de servicii și furnizorului de servicii IT despre afacere.

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

• Organizarea relatiilor cu afacerile
• Discuție și acord cerințele actualeși obiectivele, documentarea și întreținerea SLA pentru serviciile furnizate
• Discuție și acord cu cerințele și obiectivele, documentarea și întreținerea SLR pentru serviciile noi și modificate planificate.
• Formarea și menținerea acordurilor la nivel operațional (OLA) pentru a sprijini obiectivele SLA.
• Evaluarea și alinierea tuturor contractelor externe (UC) cu obiectivele SLA - în colaborare cu managementul furnizorilor.
• Prevenirea eșecurilor, reducerea riscurilor și implementarea îmbunătățirilor serviciilor funcționează împreună cu alte procese.
• Furnizați raportare și evaluare pentru toate serviciile și analizați orice abateri de la obiectivele SLA.
• Inițiază și coordonează Planul de îmbunătățire a serviciilor (SIP).

Acordul 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 extern (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.

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

Activități în cadrul procesului de management al nivelului de servicii Figura prezintă o diagramă generală a procesului de management al nivelului de servicii. Pe măsură ce întreprinderile devin din ce în ce mai dependente de serviciile IT, cererea pentru servicii IT de înaltă calitate crește. După cum sa definit mai sus, calitatea unui serviciu 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, cel mai mult

Cerințele clienților trebuie exprimate î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 va fi imposibil de verificat cât de bine corespund serviciile acordurilor încheiate.

Primul pas pentru încheierea unui acord privind serviciile IT actuale sau viitoare este identificarea și definirea nevoilor clienților sub forma cerințelor de nivel de serviciu (SLR). Pe lângă realizarea acestui tip de activitate chiar la începutul procesului, se recomandă ca aceasta să se facă în mod regulat la cererea clientului sau la inițiativa organizației IT însăși, și să acopere atât serviciile noi, cât și cele existente.

Determinarea inițială a ceea ce ar trebui să fie inclus în cerințele privind nivelul de servicii și în acordurile privind nivelul de servicii este o sarcină foarte dificilă. Trebuie luate în considerare capacitățile și limitările tuturor proceselor în ceea ce privește măsurabilitatea și realizabilitatea obiectivelor specifice de servicii.

Dacă există vreo îndoială cu privire la realizabilitatea obiectivelor de serviciu solicitate de afacere, atunci obiectivele relevante 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 se străduiesc să documenteze în primul rând serviciile pe care le furnizează prin stabilirea 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 trebuie să definească criterii 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 acord pilot de nivel de serviciu în timpul fazei inițiale 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ă anumite servicii le vor fi furnizate fără acorduri specifice; Clientul poate avea nevoie de asistență pentru înțelegerea și articularea 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 ale discuției despre cerințe înainte de a ajunge la un echilibru acceptabil între dorințe și capacități. Aceste iterații pot necesita reproiectarea soluției de serviciu.

Vă rugăm să rețineți că pot fi necesare resurse suplimentare pentru a sprijini noile servicii. Există adesea o așteptare că personalul deja supraîncărcat va face față în mod magic volumului de muncă suplimentar adus 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 servicii, iar cu furnizorii pentru a oferi încredere că aceste obiective pot fi atinse.

Managementul nivelului de servicii trebuie să conceapă o structură adecvată a acordurilor de nivel de serviciu pentru a se asigura că toate serviciile și toți clienții sunt acoperiți în măsura corectă în raport cu nevoile organizației. Există o serie de opțiuni de structură 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-urile bazate pe un singur serviciu sunt 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 ai aceluiaș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 locală rapidă, în timp ce birouri locale trebuie utilizat de linia WAN lentă. În astfel de cazuri, obiective separate pot fi prevăzute într-un singur acord. Cu toate acestea, atâta timp cât un nivel comun de servicii este furnizat în toate domeniile afacerii, cum ar fi pentru un serviciu de e-mail, SLA-urile bazate pe un singur serviciu pot servi ca exemplu 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, se pot ajunge la acorduri prin acoperirea departamentului financiar al sistemelor financiare ale organizației, sisteme contabile, sisteme de facturare, sisteme de facturare, sisteme de achiziții și orice alte sisteme IT pe care le folosesc. Clienții preferă adesea astfel de acorduri, deoarece toate cerințele lor sunt acoperite într-un singur document. De regulă, este suficientă o singură semnătură de la client, ceea ce simplifică aprobarea.

Este posibilă o combinație a oricăror opțiuni de structură, cu condiția să nu existe dublare.

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

• nivelul corporativ acoperă totul întrebări generale managementul nivelului de servicii, aplicabil tuturor clienților din organizație, de regulă, aceste secțiuni nu necesită revizuire frecventă;
• nivelul clientului 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 acoperirea nivelului de servicii să rămână în limite gestionabile, previne dublarea inutilă și reduce nevoia de actualizări frecvente. Cu toate acestea, acest lucru necesită efort suplimentar pentru a menține integritatea catalogului de servicii și a legăturilor cu sistemul de management al configurației.

SLA-urile pe mai multe 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.

Este necesar să se asigure că administrarea SLA-urilor pe mai multe niveluri este controlată, deoarece orice modificare introdusă va avea impact la alte 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șoară decât administrarea cantitate mare SLA care nu sunt combinate într-o astfel de ierarhie.

Multe organizații consideră că este necesar să utilizeze standarde și/sau șabloane de acord 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 șabloanelor asigură că toate acordurile sunt dezvoltate în mod consecvent, ceea ce, la rândul său, facilitează utilizarea, gestionarea și funcționarea ulterioară a acestora.

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. În general, 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 a calității serviciilor oferite.

Cerințele nu ar trebui incluse într-un acord de nivel de serviciu a cărui livrare viitoare nu poate fi monitorizată și măsurată la nivelul convenit. Importanța acestui lucru nu poate fi exagerată, deoarece includerea articolelor care nu pot fi monitorizate eficient va duce aproape întotdeauna la dispute și la o posibilă pierdere a încrederii din partea clientului. Multe organizații și-au dat seama de acest lucru din greșelile lor și, ca urmare, au primit costuri uriașe, ambele în financiar

, precum și după propria imagine. Este absolut necesar ca circumstanțele care împiedică implementarea acordurilor să fie identificate și ce acțiuni ar trebui întreprinse dacă apar astfel de circumstanțe.

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 rețeaua sau serverul, nu garantează că serviciul va fi disponibil clientului conform așteptărilor. Clientul este adesea preocupat doar de serviciul pe care nu îl poate primi, deși eșecul poate afecta și alte servicii. Este imposibil să obțineți o imagine completă 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 eforturile de monitorizare ale furnizorului.

Există o serie de parametri importanți care nu pot fi măsurați cu ajutorul instrumentelor de monitorizare, cum ar fi percepția clienților asupra serviciilor (și aceasta nu coincide 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 prin acțiuni vizibile și corecte pentru a corecta situația. Desigur, imaginea opusă este posibilă și atunci când clientul rămâne nemulțumit în absența încălcării acordului privind nivelul de servicii.

În primul rând, ar trebui să încercați să gestionați așteptările clienților. Aceasta înseamnă formarea așteptărilor și obiectivelor potrivite și apoi ajustarea sistematică a acestora în mod proactiv, amintindu-ne că „satisfacție = percepție - așteptări” (dacă valoarea este mai mare sau egal cu zero clientul este mulțumit). Acordurile de nivel de serviciu sunt doar documente și în sine nu înlocuiesc calitatea serviciului oferit (deși pot influența comportamentul și pot contribui 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 clientul plătește pentru serviciile furnizate, prețurile pot fi utilizate pentru a gestiona cererea. (Clienții pot obține tot ceea ce pot justifica - atâta timp cât se potrivește cu strategia întreprinderii - și au un buget autorizat pentru aceasta, care este limitat.) Acolo unde nu există niciun compromis, suportul managementului superior trebuie să fie asigurat pentru a limita clienții nerealisti. asteptari.

• sondaje periodice și sondaje ale clienților;
• feedback de la întâlnirile de evaluare a serviciilor;
• feedback în timpul evaluării 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 plângerilor și recunoștință.

Acolo unde este posibil, merită să definiți obiective de satisfacție și să le monitorizați ca parte a acordului privind nivelul de servicii. 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 dimensiunile 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ă că este util să formeze și ele simple acorduriîntre grupuri interne, denumite de obicei acorduri la nivel operațional.

„Acorduri de sprijin” este un termen general pentru toate acordurile de sprijin la nivel operațional, acordurile de nivel de servicii ș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ă acordul de nivel de serviciu necesită ca incidentele să fie rezolvate într-un anumit timp, acordul de nivel operațional ar trebui să includă restricții adecvate pentru fiecare element din lanțul de suport. Evident, obiectivele din SLA în acest caz nu trebuie să coincidă 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 susținere. Acordurile privind nivelul de servicii ar trebui să includă timpul de răspuns la solicitări, timpul necesar pentru escaladarea incidentelor către specialiștii tehnici și timpul de răspuns al acestora. Orele de asistență pentru fiecare grup de sprijin ar trebui, de asemenea, definite. Dacă există proceduri speciale de contact pentru personal ( linie telefonică

Acordul la nivel operațional ar trebui monitorizat pentru respectarea obiectivelor stabilite în acordurile de nivel de serviciu și contractele de sprijin, iar raportarea adecvată ar trebui să fie generată și comunicată managerilor echipei de asistență. 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 acordurilor formale la nivel operațional pentru toate echipele interne implicate în sprijinirea și furnizarea serviciilor operaționale.

În consecință, înainte de a semna un acord de nivel de serviciu 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 nu numai că cerințele procesului de management al nivelului de servicii sunt îndeplinite, ci și că sunt îndeplinite alte constrângeri, în special politicile și standardele contractuale.

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 atunci când apar abateri (sau amenințări de abateri) de la acordul de nivel de serviciu. Adesea implementarea acordurilor de nivel de servicii la stadiu inițial Operarea noului serviciu este dificilă din cauza numărului mare de solicitări de modificare primite. Se recomandă limitarea numărului de cereri de modificare permise în această etapă.

Mecanismele de raportare, intervalele și formatul de raportare 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ă detalieze performanța față de obiectivele acordului de nivel de serviciu, precum și să descrie tendințele și acțiunile de îmbunătățire a calității serviciilor. Este util să includeți tabele pe prima pagină a raportului în rapoartele SLA pentru a oferi o imagine de ansamblu rapidă asupra faptului că serviciul este adecvat 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; este puțin probabil ca primul rezultat să fie cel final.

Procesul de management al nivelului de servicii ar trebui să identifice nevoile de raportare și să automatizeze raportarea în măsura posibilului. Variabilitatea, acuratețea și ușurința de distribuire a rapoartelor sunt o parte importantă a criteriilor de selecție a instrumentelor 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, pentru a permite evaluarea și planificarea eficienței eforturilor 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 oricăror abateri și dificultăți care au apărut. Aceste întâlniri sunt de obicei 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 să fie înregistrate, iar implementarea lor trebuie monitorizată și verificată la întâlnirile ulterioare.

O atenție deosebită trebuie acordată întreruperilor de serviciu; trebuie clarificate cauzele și posibilele măsuri de prevenire a reapariției unor astfel de incidente. Dacă se stabilește că obiectivele stabilite anterior nu sunt realizabile, se poate lua o decizie de a evalua, rediscuta și conveni asupra obiectivelor de serviciu. Dacă întreruperea serviciului s-a datorat dependenței de terți, poate fi necesară renegocierea acordurilor de susținere. Analiza pierderilor asociate cu întreruperea 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.

Ar trebui să fie generate rapoarte privind progresul și rezultatele implementării planului de îmbunătățire a serviciilor 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 supuse controlului de gestionare a modificării și configurației și revizuite periodic, cel puțin anual, pentru a se asigura că sunt actuale, complete și conforme cu nevoile și strategia de afaceri.

Aceste analize ar trebui să asigure că acordurile sunt actualizate în ceea ce privește domeniul de aplicare și obiectivele declarate, confirmând că acordurile nu au devenit invalide din cauza oricăror modificări în infrastructură, afaceri, furnizori etc. La actualizarea acordurilor, modificările efectuate trebuie efectuate sub controlul managementului schimbărilor. Dacă acordurile sunt reflectate în sistemul de management al configurației ca KU, 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 în concordanță cu strategia și politicile IT și de afaceri.

Este 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 săi cheie. 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, manageri de afaceri și utilizatori;
• contribuie la menținerea datelor exacte în portofoliul și catalogul de servicii;
• oferă 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 afacerea, clienții și utilizatorii, formând relații pe termen lung ;
• Oferiți o înțelegere aprofundată a strategiei, planurilor, nevoilor și obiectivelor afacerii, clienților și utilizatorilor, dezvoltând un parteneriat între aceștia și IT;
• Analizați în mod regulat munca și experiența clienților - interni și externi - și comunicați informații relevante către IT;
• asigura disponibilitatea ș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țiunile acestora pe baza rezultatelor;
• reprezenta furnizorul de servicii la întâlnirile grupului de utilizatori;
• Cercetează în mod proactiv piața analizând utilizarea serviciilor și influențând portofoliul și catalogul de servicii;
• colaborează cu afacerea, clienții și utilizatorii 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 negocierea cerințelor corecte, realizabile și realiste ale nivelului de servicii și acordurilor de nivel de serviciu între IT și afacere;
• Asigurați-vă că întreprinderile, clienții și utilizatorii își înțeleg relațiile și dependențele IT;
• facilitează î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 citațiilor. Înregistrarea este adesea efectuată de biroul de service și este similară cu înregistrarea incidentelor și solicitărilor de servicii. Definițiile plângerii și recunoștinței trebuie convenite cu clienții, împreună cu punctele de contact și procedurile. Toate plângerile și citațiile trebuie înregistrate și transmise părților corespunzătoare.

Pentru toate reclamațiile, trebuie luate și acțiuni și decizii pentru a satisface inițiatorul. În cazul în care acest lucru nu se întâmplă, trebuie definite contacte și proceduri de escaladare. Toate reclamațiile serioase trebuie revizuite și aduse la cunoștința conducerii. Raportarea ar trebui să fie generată cu privire la statistici, tendințe, acțiuni și rezultate în domeniul procesării reclamațiilor și al recunoștinței.

• Indicatori de proces de management al nivelului de serviciu
• CSF Este important să se asigure managementul calității serviciilor în ansamblu, inclusiv acoperirea și nivelul de furnizare:
• KPI Ponderea reducerii nerespectării obiectivelor SLA
• KPI Procentul de reducere 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 din cauza dependenței de terți (UC)
• KPI Procentul de reducere a neconformităților asociate cu dependența de contractori interni (OLA)
• CSF Furnizarea de servicii în conformitate cu acordurile pentru bani rezonabili:
• KPI Numărul și procentul de creștere a numărului de SLA complet documentate
• KPI Ponderea îmbunătățirilor în SLA a vizat îmbunătățirea serviciilor deja furnizate
• KPI Ponderea reducerii costului de furnizare a serviciilor
• KPI Ponderea reducerii costurilor de monitorizare și raportare conform SLA
• KPI Ponderea creșterii vitezei de dezvoltare și aprobarea SLA
• KPI Frecvența întâlnirilor de evaluare a serviciului
• CSF Managementul interfeței dintre afaceri și utilizatori:
• KPI Creșterea numărului de servicii acoperite de SLA
• KPI Reducerea timpului de răspuns și execuție pentru solicitările SLA
• KPI Creșterea proporției de SLA-uri revizuite la timp
• KPI Reducerea ponderii SLA-urilor neîndeplinite supuse revizuirii
• KPI Reducerea proporției de SLA care necesită ajustări
• KPI Acoperire sporită a OLA și UC, reducând în același timp numărul de acorduri datorită consolidării și centralizării acestora
• KPI Disponibilitatea dovezilor documentate ale îmbunătățirilor ale abaterilor identificate de la SLA
• KPI Reducerea numărului și a gravității nerespectării obiectivelor SLA
• KPI Evaluare eficientăși procesarea tuturor abaterilor și neconcordanțelor de la SLA, OLA, UC

ITIL identifică măsuri subiective și obiective de performanță pentru managementul 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:

Riscuri și dificultăți

Satisfacția clienților îmbunătățită

• La implementarea managementului nivelului de servicii, trebuie luate în considerare următoarele riscuri și dificultăți posibile:
• Lipsa unei contribuții precise, implicare și interes din partea afacerilor și clienților
• Nevoia de resurse și instrumente pentru a negocia, documenta, monitoriza, raporta și evalua acordurile și nivelurile de servicii
• Procesul poate deveni excesiv de birocratic, concentrat mai degrabă pe procedurile 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 orientate spre afaceri sunt prea dificil de măsurat și îmbunătățit, așa că nu sunt colectate
• Nivel inadecvat de contact și coordonare
• Așteptări ridicate și satisfacție scăzută a clienților

Comunicații ineficiente cu afacerile

Procesul de management al problemelor

O problemă este cauza unuia sau mai multor incidente. De obicei, atunci când o problemă este înregistrată, cauza este necunoscută și procesul de gestionare a problemei este responsabil pentru investigarea ulterioară.

Pentru a identifica cauzele principale ale erorilor existente și potențiale de livrare a serviciilor, 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 acelor incidente care nu pot fi prevenite.

Managementul problemelor include activități proactive și reactive. Scopul componentelor reactive ale procesului de management al problemelor este de a determina cauza principală a incidentelor trecute și de a pregăti o propunere pentru eliminarea acesteia. Gestionarea proactivă a problemelor ajută la prevenirea incidentelor prin identificarea punctelor slabe ale infrastructurii și făcând propuneri de îmbunătățiri.

Astfel, obiectivele procesului de management al problemelor sunt:

• Prevenirea problemelor și incidentelor aferente
• Oprirea incidentelor să se repete
• Reducerea impactului incidentelor care nu pot fi prevenite

Activități în cadrul procesului 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ă numai atunci când incidentul se repetă, este probabil să se repete sau dacă este un incident izolat, dar grav.

Activitatea de „identificare a problemelor” este adesea realizată de coordonatorii problemei. Cu toate acestea, este posibil ca personalul care nu este implicat inițial în această activitate, cum ar fi specialiștii în managementul capacității, să identifice și probleme. Astfel de „descoperiri” ar trebui, de asemenea, înregistrate ca probleme.

Detaliile de înregistrare a problemelor sunt similare cu detaliile incidentului, dar în cazul unei probleme nu este necesar să se includă informații despre utilizator etc. Cu toate acestea, incidentele asociate cu o anumită problemă trebuie identificate și înregistrate în consecință. Următoarele sunt exemple de cazuri în care pot fi identificate probleme:

• Gestionarea incidentelor nu poate potrivi un incident cu problemele existente sau erorile cunoscute
• Analiza tendințelor incidentelor arată că poate exista o problemă
• Este necesară o analiză a cauzei unui incident major
• Alte funcții IT au stabilit că poate exista o problemă
• Personalul de la Service Desk nu a reușit să determine 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ă care trebuie rezolvată

Posibilele semne de probleme pot include:

• Incidente recurente în:
• Aceeași perioadă de timp
• Într-un domeniu (categorie)
• În același CI sau grup de CI similare
• În aceleași locații, ordine, împărțire
• Volumul incidentelor similare depășește un anumit nivel
• A fost aplicată o soluție pentru a rezolva incidentul.
• Depășirea termenului limită de procesare a incidentelor

Analiza tendințelor relevă zone care necesită o atenție specială.

• Indiferent de metoda de detectare a problemei, toate datele relevante despre problemă trebuie înregistrate într-o înregistrare a problemei:
• Informații despre utilizator(i)
• Informații despre serviciu(e)
• Informații despre echipamente
• Ora de înregistrare
• Prioritate, categorie
• Descrierea incidentelor conexe

Acțiuni întreprinse pentru a diagnostica și rezolva

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

La fel ca incidentele, problemele trebuie clasificate. Problemele pot fi clasificate în domenii (categorii). Clasificarea problemei se realizează concomitent 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. Pe baza rezultatelor clasificării, resursele și personalul sunt apoi alocate problemei ș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.

Investigarea și diagnosticul sunt faze iterative ale procesului ele se repetă de mai multe ori, de fiecare dată apropiindu-se de rezultatul dorit. De multe ori se încearcă reproducerea incidentului în condiții de testare. Pentru a rezolva problema, pot fi necesare cunoștințe suplimentare, de exemplu, puteți implica specialiști din echipa de asistență pentru a analiza și diagnostica problema.

Odată ce cauza problemei și o soluție de soluție au fost determinate, problemei i se atribuie starea de eroare cunoscută.

În multe cazuri, o soluție pentru problemă este deja disponibilă inițial, chiar dacă eroarea a fost găsită chiar de dezvoltatori. Dar, în unele cazuri, trebuie găsită o soluție și apoi transmisă procesului 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 implicat în managementul problemei determină ce trebuie făcut pentru a rezolva problema. Experții compară diverse solutii

, luând în considerare acordurile de nivel de servicii (SLA), costurile și beneficiile posibile.

Toată munca de dezvoltare a unei soluții trebuie să fie înregistrată în sistem, iar personalul trebuie să aibă mijloacele de a monitoriza problemele și de a determina starea acestora.

În etapele anterioare, este selectată soluția optimă. Cu toate acestea, se poate lua o decizie de a nu corecta o eroare cunoscută, de exemplu din cauza impracticității economice.

Odată ce faza de selecție este finalizată, există suficiente informații pentru a trimite o cerere de modificare. În continuare, problema (eroarea cunoscută) va fi corectată sub controlul procesului de management al schimbărilor.

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

Politici și metrici ale procesului de management al problemelor

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

• Problemele trebuie urmărite separat de incidente
• Toate problemele trebuie stocate și gestionate sistem unificat management
• Toate problemele trebuie să aibă o schemă standard de clasificare care să corespundă proceselor 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 de bază (CSF și KPI):

• CSF Minimizarea impactului asupra afacerii al incidentelor care nu pot fi prevenite
• KPI Numărul de erori cunoscute adăugate de KEDB
• KPI Procent de relevanță KEDB (pe baza auditului bazei de date)
• KPI Procentul de incidente închise de biroul de asistență („primul punct de contact”)
• KPI Timp mediu pentru rezolvarea incidentelor pentru care o problemă deschisă
• CSF Mentinerea calitatii serviciilor IT prin eliminarea incidentelor recurente
• KPI Numărul total de probleme (ca parametru de control)
• Dimensiunea cozii KPI în funcție de problemă pentru fiecare serviciu IT
• KPI Numărul de incidente repetate pentru fiecare serviciu IT
• CSF Asigurarea calității și a competenței în rezolvarea problemelor pentru a menține încrederea afacerii în capabilitățile IT
• KPI Numărul de probleme semnificative (deschise, închise și în coadă)
• KPI Procentul 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 intervalul de timp pentru 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 ghidurile ITIL și abordând orice provocări care pot apărea în timpul implementării, se poate obține următoarea valoare pentru afacere î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
• Aplicarea de soluții permanente în loc de peticerea continuă a găurilor.
• Activități sistematice de acumulare de cunoștințe.
• Abilitatea de a rezolva mai multe incidente pe prima linie de suport.
• Reducerea costului efortului la stingerea incendiilor sau rezolvarea incidentelor repetate

Procesul de gestionare a activelor și configurației serviciului

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

• dificultate de actualizare: la fiecare modificare, diagrama trebuie redesenată și tipărită din nou, 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 pe diagramă
• informații limitate: de regulă, pentru fiecare element sunt indicate doar cele mai importante informații, de exemplu, numele domeniului sau adresa IP
• complexitatea analizei: cu o acoperire mare a circuitului și în prezența diferitelor relații complexe între componente, analiza unor astfel de circuite este dificilă

Procesul de gestionare a activelor și configurațiilor de servicii, construit în conformitate cu recomandările ITIL, vă permite să utilizați datele disponibile pe 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 - activitatea sau procesul responsabil de urmărirea și raportarea valorii și a dreptului de proprietate asupra activelor pe parcursul ciclului lor de viață
• Managementul configurației este activitatea sau procesul responsabil de gestionarea informațiilor despre elementele de configurare necesare pentru furnizarea serviciilor IT, inclusiv relațiile acestora.

Obiectivele procesului de gestionare a activelor și configurației serviciului:

• Identificați, monitorizați, documentați, raportați și verificaț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 de serviciu ș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 stabilirea ș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, să le analizați și să le prezentați în diferite secțiuni.

Sistemul de management al configurației (CMS) este 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 sistem comun Managementul cunoștințelor serviciului 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.

Elementul de configurare (CU) este orice componentă sau alt activ de serviciu care trebuie controlat 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 menținute la zi pe tot parcursul ciclului său de viață prin procesul de gestionare a configurației și a activelor de serviciu.

Elementele de configurare sunt controlate de procesul de management al modificărilor. Acestea includ de obicei servicii IT, echipamente, software, clădiri, oameni și documente, cum ar fi documentația procesului și acordurile de nivel de serviciu. Unitățile de configurare pot fi mijloace tehnice, de toate tipurile software

• înregistrări ale elementelor de configurare, inclusiv atributele lor 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, aceste informații vor diferi cel mai probabil.

Un atribut este o informație despre un element de configurare. De exemplu, numele, locația, numărul versiunii și costul. Atributele KU sunt înregistrate într-o bază de date de management al configurației (CMDB) și menținute ca parte a unui sistem 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.

Tipul KE este o categorie care este utilizată pentru a clasifica elementele de configurare. Tipul CI determină ce atribute și relații sunt necesare pentru înregistrarea de configurare. Tipuri comune de KE - echipamente, documentație, utilizator etc. Setul de CI și relațiile lor reprezintă de fapt un model de configurare.
Figura prezintă un exemplu de model de configurare. CMS vă permite să luați în considerare eficient informațiile de configurare necesare, să le analizați și să le prezentați în sub diverse forme

• , inclusiv grafic. 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-urilor de tehnologie și software
• pentru planificarea pachetelor de lansare și replicarea serviciilor

pentru a optimiza utilizarea activelor și costurile

• Astfel, dacă managementul activelor de serviciu și al configurației este implementat eficient, acest proces poate furniza, de exemplu, informații despre următoarele: Informații financiare
• și politica de produse a 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 operațional și care necesită modernizare?
• Cât va costa înlocuirea anumitor componente?
• Ce contracte de suport 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 urgență?
• Va funcționa planul de recuperare în caz de dezastru dacă configurația infrastructurii a fost modificată?
• Ce componente IT vor fi afectate la implementarea noilor servicii?
• Cum este conectat echipamentul la rețea?
• Care module software incluse în fiecare pachet 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ă în curs?
• 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 și 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 utilizatorul și care sunt acceptate (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
• Planul evenimentelor 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 selectare a elementelor de configurare și a componentelor lor constitutive
• Selectarea elementelor și componentelor de configurare pe baza criteriilor documentate
• Atribuirea de identificatori unici
• Definirea atributelor pentru fiecare cheie
• Determinarea momentului în care CI preia controlul asupra procesului
• Determinarea proprietarului responsabil pentru fiecare KU

În funcție de amploarea infrastructurii IT și de complexitatea regulilor contabile, identificarea poate dura mult timp și necesită o cantitate semnificativă 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 pentru fiecare CU sunt clare)
  • Restricționarea accesului pentru modificarea datelor CMDB
  • Asigurarea protecției antivirus a controalelor CMDB
  • Furnizarea de capabilități de backup și de recuperare a datelor
• Regulile de control trebuie dezvoltate în etapa de planificare a procesului
• Reguli pentru transferul controlului de la proiecte sau furnizori
• Procedurile de control trebuie să corespundă tipurilor de KE

Starea configurației și activitățile de raportare includ:

• Mențineți înregistrările de configurare pe tot parcursul ciclului de viață al serviciului și arhivați-le în conformitate cu acordurile, cerințele externe, cele mai bune practici și standardele (de exemplu, ISO 9001)
• Gestionați documentația, preluarea ș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 disponibilității informațiilor de stare pe tot parcursul ciclului de viață al serviciului
• Documentarea modificărilor CI de la acceptare la dezafectare
• Asigurarea faptului că configurațiile de bază sunt documentate corect

Verificare si audit:

• Verificare - verificarea KE pentru conformitatea cu standardele sau cerințe funcționale:
• La înregistrarea inițialăîn CMDB
• Când primiți hardware sau software de la un furnizor
• În timpul punerii în funcțiune
• Audit - verificarea conformității între starea actuală a CI (ca atare) și descrierea CI în CMDB (cum ar trebui să fie)
• Audit standard
• Audit simplificat
• Audit curent (operațional).

• O perioadă scurtă de timp după implementare sistem nou/ proces de gestionare a configurației
• Înainte și după schimbări majore în infrastructura IT
• Înainte de a implementa software nou, verificați pregătirea pentru producție
• După revenirea după o defecțiune majoră (urgență)
• La detectarea unui număr mare de discrepanțe (de exemplu, ca parte a unui audit operațional)
• În mod regulat (cu frecvență predeterminată)
• Din când în când (verificări „bruște”)

Indicatori de proces de gestionare a activelor de serviciu și configurației

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 suportului ciclului de viață al activelor bazat pe principiul: nu prea mult, nici prea târziu
• Nivel de suport care satisface nevoile afacerii
• Active identificate ca fiind cauza defecțiunilor serviciului
• Creșterea vitezei de rezolvare a incidentelor și restabilirea serviciilor prin identificarea mai rapidă a CI-urilor defecte
• Identificați conexiunile între anumite tipuri de CI, incidente și probleme
• Mai mult utilizare eficientă active de servicii
• Utilizarea mai eficientă a licențelor achiziționate, costul mediu al licenței per utilizator
• Bugetul mai precis și taxele de utilizare a activelor
• 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 serviciile de asistență
• Reduceți timpul și costurile atunci când diagnosticați și rezolvați incidentele și problemele
• Reducerea timpului de identificare a activelor cu probleme de performanță
• 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:

• Personal convingător suport tehnic să respecte politicile contabile, care este adesea percepută ca o barieră în calea asistenței rapide a serviciilor.
• Atragerea și justificarea alocarii de fonduri pentru proces, deoarece, de obicei, procesul nu este vizibil pentru departamentele clientului care au autoritatea de a aloca fonduri. De obicei, finanțat ca element „invizibil” al managementului schimbării și alte procese mai „vizibile”.
• Abordare: „colectați toate datele posibile”, ceea ce duce la suprasolicitarea procesului, precum și la incapacitatea de a-l menține
• Lipsa de angajament și sprijin din partea conducerii care nu înțeleg rolul cheie al procesului

Metoda incidentului critic.

Identificarea unui incident critic - aceasta este o metodă menită să identifice

identificarea procesului, a subprocesului sau a zonei cu probleme care merită abordată

îmbunătăţi. Metoda a fost dezvoltată de Lawlor în 1985. Acesta este destul de deschis

O modalitate rapidă și scurtă de a obține informații despre problemele unei organizații. Ca o condiție prealabilă, se presupune că toți participanții sunt absolut liberi

în exprimarea opiniilor lor. Orice cenzură sau ascundere a informațiilor de teamă

nici că va fi prea sinceră este respins cu hotărâre.

Metoda include trei etape:

1). Sunt selectați participanții pentru analiză. Dacă scopul este să

luând o decizie de îmbunătățire a întregului proces, este firesc

include reprezentanți din diferite domenii ale organizației. Dacă

Lew este să determine cu mai multă precizie direcția de acțiune în interior

proces de afaceri deja definit, este mai bine să selectați persoanele implicate

acest proces.

2). Participanții la discuții sunt rugați apoi să răspundă la întrebări precum:

Ce incident a fost cel mai greu de rezolvat în ultima săptămână?

Ce episod a creat? cele mai mari probleme pentru a satisface nevoile

caracteristicile consumatorilor?

Care incident a costat cel mai mult în ceea ce privește atragerea

resurse suplimentare sau costuri directe?

În această etapă de utilizare a metodei, este important să se evidențieze așa-numitele strigăt-

incidente de tic, care într-un fel sau altul creează probleme

pentru angajatii individuali, pentru intreaga organizatie si pentru alti interesati

laterale de baie. Perioada acoperită de întrebare poate varia

de la câteva zile la câteva luni. Nu este recomandat, însă, ca dumneavoastră

alegeți o perioadă prea lungă, deoarece în acest caz poate fi dificil

Este dificil de identificat cel mai relevant incident critic, deoarece

că pe o perioadă lungă de timp ar putea fi multe astfel de incidente.

3). Răspunsurile colectate sunt sortate și se determină care dintre diferite

Dentov a fost menționat mai des decât alții. Pentru a evidenția un incident critic

Este convenabil să folosiți o reprezentare grafică a rezultatelor obținute. Că

incidentul care are loc mai des decât altele va fi critic. El - este -

un bun candidat pentru prevenire. Cu toate acestea, trebuie să lupți nu atât de mult cu tine însuți

incidentul și simptomul acestuia, precum și motivele care au dat naștere acestuia.

Exemplu.

A început o mare corporație cu 15 operatori de telefonie în personal

la proiectul de îmbunătățire a serviciului de telefonie pentru consumatori când

răspunde la apeluri. S-a decis să se folosească metoda de identificare a plânsului.

incident tic.

Toți operatorii de telefonie au fost rugați să descrie acele incidente care

evenimentele din ultima lună care i-au pus într-o situație extrem de dificilă. Rezultatele sondajului au fost sortate după frecvență

repetarea incidentelor. Ele sunt prezentate în Fig. 7.1 sub forma unei diagrame. din ri-

Imaginea arată că incidentele critice au fost: 1) incapacitatea de a ajunge

persoana care ar trebui să răspundă la apel, 2) neștiind cine anume ar trebui

soţiile să răspundă. Pe baza rezultatelor studiului s-au făcut eforturi

să creeze un sistem de urmărire a mișcărilor fiecărui angajat, precum și

au fost elaborate instrucțiuni cu privire la care dintre angajați ar trebui să răspundă la care cerere

răspuns. Lista de verificare - Aceasta este o formă sau o formă specială destinată

început pentru înregistrarea datelor, Rolstados (1995) . Unul dintre motivele principale

Scopul listei de verificare este să înregistreze cât de des

apar diverse probleme sau incidente. Aceasta oferă informații importante

informații despre zonele cu probleme sau posibilele cauze ale erorilor. Utilizare

listele de verificare oferă o bază bună pentru luarea deciziilor privind locul

eforturile de îmbunătățire ar trebui concentrate.

Completarea fișei de verificare are loc de obicei în mai multe etape:

1) A ajunge la un acord asupra evenimentelor care trebuie înregistrate. Toate acestea sunt necesare

determina exact astfel încât să nu existe îndoială dacă evenimentul a avut loc

De fapt. De asemenea, este indicat sa includeti in foaia de control pozitia

„Altele” pentru a înregistra incidente care sunt greu de atribuit

2) Determinarea perioadei de înregistrare a datelor și împărțirea convenabilă a acesteia în inter-

3) Elaborarea unui formular (formular) de fișă de control utilizată pentru înregistrare

traditii. 4) Colectarea datelor are loc pe toată perioada de timp convenită.

Mai întâi trebuie să vă asigurați că toți participă la

Atunci când colectează date, ei au aceeași înțelegere a ceea ce se întâmplă. Apoi colectate

persoane diferite, datele vor fi valabile.

5) La finalizarea colectării datelor, acestea sunt analizate pentru identificarea evenimentelor

legături care au cea mai mare frecvenţă de manifestare. Acest lucru vă va permite să determinați

priorităţile zonelor problematice din cadrul unui proces de afaceri dat pentru

acordând accent în munca de îmbunătățire. Ajutor convenabil

Un instrument util pentru realizarea unei astfel de analize este diagrama Pareto diagrama Pareto

Construcția acestei scheme se bazează pe așa-numitul principiu Pareto, formând

modelat de matematicianul italian Vilfredo Pareto în anii 1800. Sub-

Detalii despre această schemă pot fi găsite și în cartea lui Rolstados. Pareto era

preocupat de distribuţia bogăţiei în societate şi credea că 20% din populaţie era la putere

reprezintă 80% din toată averea. Tradus în limbajul modern al sistemelor de calitate, aceasta

principiul este că adesea aproximativ 80% din toate manifestările posibile

se datorează aproximativ 20% din toate cauzele posibile. O abordare inteligentă a acestui lucru

caz - începeți munca la îmbunătățire atacând tocmai aceste 20%

rang, care sunt de obicei numite „minoritate vitală”. Acest lucru este complet

nu înseamnă că restul de 80% din motive pot fi ignorate: în timp util

moment în timp prin aceste motive, care sunt numite „aceasta cel mai important

ar trebui de asemenea abordată. Principiul Pareto determină prioritățile pro-

probleme care trebuie abordate.

Diagrama Pareto în sine oferă o interpretare grafică în

forma unei distribuții distorsionate a așa-numitei reguli „80/20”. Acestea sunt motivele

sortate după importanță, după frecvența de apariție, după cost,

după nivelul indicatorilor etc. La ordonarea cauzelor pe o diagramă Pareto

cele mai importante dintre ele sunt atribuite marginii din stânga a diagramei, astfel încât să fie „vital

minoritate importantă” a fost ușor de identificat. Pentru a spori informația

activitatea diagramei Pareto, curba de frecvență acumulată este de obicei trasată pe ea.

Că. Un exemplu de construire a unei diagrame este prezentat în Fig. 7.4.

Când lucrați cu o diagramă Pareto, faceți următoarele:

1). Identificați principala problemă a evenimentului și diversele sale cauze potențiale.

ranguri. Luând în considerare ipotezele făcute în această carte, vom presupune că

că a fost deja selectat un anumit proces pe care este de dorit să îl îmbunătățim. Aşa

Astfel, scopul construirii unei diagrame Pareto este de a identifica

principalele motive pentru nivelul scăzut al indicatorilor.

2). Determinați ce indicator cantitativ va fi utilizat când

compararea cauzelor posibile. Ca un astfel de indicator s-ar putea

luați frecvența de apariție a diferitelor tipuri de probleme sau consecințele acestora în teritoriu

mine de costuri în numerar și alte condiții.

3). Stabiliți perioada de timp în care vor fi colectate datele și

ia-le. Adesea, această lucrare a fost deja finalizată mai devreme, când a fost solicitată.

completarea listelor de verificare. Esența listei de verificare este descrisă în § 7.2.

4). Aranjați cauzele de la stânga la dreapta de-a lungul axei orizontale a diagramei

Pareto în ordinea descrescătoare a importanței lor relative. Desenați un tabel -

Scheme de biki. Înălțimea lor corespunde gradului de importanță relativă a corespondentului

motiv relevant. 5). Marcați valorile absolute obținute ale indicatorilor pe verticala stângă

axa noah. Notați valorile relative ale indicatorilor sub formă de procente din dreapta

urlet al axei verticale. Desenați o curbă de acumulare de importanță de-a lungul vârfului

marginile coloanelor.

Studierea diagramei Pareto poate răspunde la întrebări precum: 1) „Ce este

reprezintă două sau trei motive principale pentru nivelul scăzut al indicatorilor acestui lucru

proces? sau 2) „Care este ponderea costurilor atribuibile celor mai vitale

motive noi? Aceste informații pot fi utilizate pentru acțiuni precum:

vizând eforturile de îmbunătățire a procesului de realizare

cele mai înalte rezultate ale sale.

Construcția unei diagrame Pareto poate fi simplificată dacă utilizați standardul

software de calculator tehnic destinat compilarii electronice

ron mese. În același timp, există instrumente speciale pentru construirea diagramelor Pareto.

software-ul zirovanny. Două astfel de programe de calculator specializate sunt StatGraphics PlusŞi ASAS/QC. De asemenea, dau

capacitatea utilizatorului de a construi diagrame de control pentru SUP. De asemenea, notăm pachetul

Software-ul Memory Jogger, care poate fi folosit cu unele unelte

îmbunătățirea calității.

Avantaje: Vă permite să obțineți informații despre calitățile care contribuie sau împiedică obținerea rezultatelor în muncă. Promovează o mai bună înțelegere conţinut lucru.

Defecte: Este posibil ca unele dintre informațiile obținute să nu fie utilizate la crearea modelului, deoarece o serie de incidente descrise se pot dovedi în cele din urmă a fi complet necaracteristice lucrării.

11 octombrie 2012 la ora 10:58

Lucrul cu incidente securitatea informatiei

• Securitatea informațiilor

Bună ziua, dragă habrahabr!

Continui să public articole din practica de securitate a informațiilor.
De data aceasta vom vorbi despre o componentă atât de importantă precum incidentele de securitate. Lucrul cu incidente va lua cea mai mare parte din timp după ce a fost stabilit regimul de securitate a informațiilor (documentele au fost acceptate, instalate și configurate partea tehnica, au fost efectuate primele antrenamente).

Raportarea incidentelor

Primul lucru pe care trebuie să-l faceți este să obțineți informații despre incident. Acest punct trebuie gândit în stadiul formării unei politici de securitate și al creării de prezentări privind programele educaționale în securitatea informațiilor pentru angajați.
Principalele surse de informare:

1. Serviciu de asistență.
De regulă (și aceasta este o tradiție bună), ei sună sau scriu la biroul de asistență al serviciului dumneavoastră IT despre orice defecțiuni, defecțiuni sau defecțiuni ale echipamentelor. Prin urmare, este necesar să „integrați” în prealabil procesul de afaceri al biroului de asistență și să indicați tipurile de incidente cu care solicitarea va fi transferată către departamentul de securitate a informațiilor.

2. Mesaje direct de la utilizatori.
Organizați un singur punct de contact și comunicați acest lucru în cadrul formării de securitate a informațiilor pentru angajați. În prezent, departamentele de securitate a informațiilor din organizații, de regulă, nu sunt foarte mari, fiind adesea formate din 1-2 persoane. Prin urmare, nu va fi dificil să desemnați pe cineva responsabil pentru primirea incidentelor, nici măcar nu trebuie să vă deranjați cu alocarea unei adrese de e-mail pentru nevoile IS Helpdesk.

3. Incidente detectate de personalul de securitate a informațiilor.
Totul este simplu aici și nu sunt necesare mișcări fizice pentru a organiza un astfel de canal de recepție.

4. Jurnalele de sistem și alertele.
Configurați alerte în consola antivirus, IDS, DLP și alte sisteme de securitate. Este mai convenabil să utilizați agregatoare care colectează și date din jurnalele de programe și sisteme instalate în organizația dvs. O atenție deosebită trebuie acordată punctelor de contact cu rețeaua externă și locurilor în care sunt stocate informații sensibile.

Deși incidentele de securitate sunt variate și diverse, ele sunt destul de ușor de împărțit în mai multe categorii, care sunt mai ușor de păstrat statistici.

1. Dezvăluirea informațiilor confidențiale sau interne sau amenințarea unei astfel de dezvăluiri.
Pentru a face acest lucru, trebuie să aveți, cel puțin, o listă actualizată de informații confidențiale, sistem de lucruștampilarea suporturilor electronice și de hârtie. Bun exemplu- șabloanele de documente pentru aproape toate ocaziile, aflate pe portalul intern al organizației sau în depozitul de fișiere intern, sunt marcate implicit „Numai pentru uz intern”.
Permiteți-mi să clarific puțin despre amenințarea dezvăluirii într-o postare anterioară, am descris o situație în care un document etichetat „Numai pentru uz intern” a fost postat într-o sală comună adiacentă unei alte organizații. Poate că nu a existat nicio dezvăluire în sine (a fost postată după sfârșitul zilei de lucru și a fost observată foarte repede), dar faptul amenințării dezvăluirii este evident!

2. Acces neautorizat.
Pentru a face acest lucru, trebuie să aveți o listă de resurse protejate. Adică acelea în care se află orice informație sensibilă a organizației, clienților sau contractorilor acesteia. Mai mult, este de dorit să se includă în această categorie nu numai pătrunderea într-o rețea de calculatoare, ci și accesul neautorizat la spații.

3. Excesul de autoritate.
În principiu, puteți combina acest punct cu cel anterior, dar este mai bine să îl evidențiați și să explicați de ce. Accesul neautorizat se referă la accesul persoanelor care nu au acces legal la resursele sau sediul organizației. Acesta este un intrus extern fără intrare legitimă în sistemul dumneavoastră. Excesul de autoritate este înțeles ca acces neautorizat la orice resurse și sedii ale angajaților legali ai organizației.

4. Atacul de virus.
În acest caz, trebuie să înțelegeți următoarele: o singură infecție a computerului unui angajat nu ar trebui să ducă la litigii, deoarece aceasta poate fi atribuită unei erori sau unui factor uman notoriu. Dacă un procent semnificativ din calculatoarele organizației sunt infectate (aici se pornește de la numărul total de mașini, distribuția, segmentarea acestora etc.), atunci este necesar să se lanseze o investigație completă a incidentului de securitate cu căutarea necesară pentru surse de infecție, cauze etc.

5. Compromisarea contului.
Acest punct răsună 3 . De fapt, incidentul pleacă de la 3 V 5 categorie dacă în timpul investigației incidentului se dovedește că utilizatorul în acel moment era în imposibilitatea fizică și efectivă de a-și folosi acreditările.

Clasificarea incidentelor

Acest punct în lucrul cu incidente poate fi tratat în 2 moduri: simplu și complex.
Modalitatea ușoară este să luați acordul de nivel de servicii IT și să îl adaptați nevoilor dvs.
Pe calea grea: pe baza analizei de risc, identificați grupuri de incidente și/sau active pentru care rezolvarea sau eliminarea cauzelor incidentului trebuie să fie imediată.
Modul simplu funcționează bine în organizațiile mici unde nu există prea multe informații proprietare și nu cantitate uriașă angajati. Dar merită să înțelegeți că serviciul IT bazează SLA pe propriile riscuri și statistici de incidente. Este foarte posibil ca pe masă să fie o imprimantă blocată cu hârtie director general va avea o prioritate foarte mare dacă compromiterea parolei administratorului bazei de date corporative este mai importantă pentru dvs.

Strângerea dovezilor incidentului

Există o știință aplicată specială - criminalistica, care se ocupă de probleme de criminalistică în domeniul infracțiunilor informatice. Și există o carte minunată de N.N Fedotov. „Legal – criminalistica computerizată”. Nu voi descrie în detaliu aspectele criminalisticii acum, voi evidenția doar 2 puncte principale în conservarea și furnizarea dovezilor care trebuie respectate.

Pentru documentele pe hârtie, originalul este stocat în siguranță cu o înregistrare a persoanei care a descoperit documentul, unde a fost descoperit documentul, când a fost descoperit documentul și care a asistat la descoperire. Orice investigație trebuie să se asigure că originalele nu au fost falsificate
Pentru informații despre mediile computerizate: imagini în oglindă sau orice suport amovibil, trebuie luate informații despre hard disk-uri sau memorie pentru a asigura accesibilitatea. O evidență a tuturor activităților din timpul procesului de copiere trebuie păstrată și procesul trebuie asistat. Media și protocolul original (dacă acest lucru nu este posibil, atunci cel puțin o imagine în oglindă sau o copie) trebuie să fie păstrate protejate și intacte

După rezolvarea incidentului

Deci, incidentul s-a încheiat, consecințele au fost eliminate și s-a efectuat o anchetă oficială.
Dar munca nu ar trebui să se termine aici.
Acțiuni suplimentare după incident:

Reevaluarea riscurilor care au dus la incident
întocmirea unei liste de măsuri de protecție pentru a minimiza riscurile identificate în cazul reapariției incidentului
actualizarea politicilor, reglementărilor, regulilor de securitate a informațiilor necesare
organizarea de formare pentru personalul organizației, inclusiv angajații IT, pentru a crește gradul de conștientizare a securității informațiilor

Adică, este necesar să se întreprindă toate acțiunile posibile pentru a minimiza sau neutraliza vulnerabilitatea care a dus la implementarea unei amenințări de securitate și, ca urmare, la apariția unui incident.

1. Păstrați un jurnal al incidentelor, în care înregistrați ora descoperirii, detaliile angajatului care a descoperit incidentul, categoria incidentului, activele afectate, timpul planificat și efectiv pentru rezolvarea incidentului, precum și munca depusă. pentru a elimina incidentul și consecințele acestuia.
2. Înregistrați-vă acțiunile. Acest lucru este necesar, în primul rând, pentru dvs., pentru a optimiza procesul de rezolvare a incidentelor.
3. Notificați angajații despre incident, astfel încât, în primul rând, să nu interfereze cu investigația dvs. și, în al doilea rând, să excludă utilizarea bunurilor afectate în timpul investigației.

Asigurarea securității informațiilor de afaceri Andrianov V.V.

4.1.4. Exemple de incidente

4.1.4. Exemple de incidente

Informații generale

Această secțiune descrie detalii publicate ale unora dintre incidentele importante. În același timp, generalizarea incidentelor oferă o grămadă de circumstanțe care caracterizează varietatea de amenințări la securitatea informațiilor din partea personalului, atât în ​​ceea ce privește motivele și condițiile, cât și în ceea ce privește mijloacele utilizate. Printre incidentele cele mai frecvente, remarcăm următoarele:

Scurgeri de informații oficiale;

Furtul clienților și afacerilor organizației;

Sabotajul infrastructurii;

fraudă internă;

Falsificarea rapoartelor;

Tranzacționarea pe piețe pe baza informațiilor privilegiate și de proprietate;

Abuz de autoritate.

Adnotare

Ca răzbunare pentru un bonus prea mic, Roger Duronio, în vârstă de 63 de ani (fost administrator de sistem la UBS Paine Webber) a instalat o „bombă logică” pe serverele companiei, care a distrus toate datele și a paralizat mult timp munca companiei.

Descrierea incidentului

Duronio a fost nemulțumit de salariul său de 125.000 de dolari pe an, care ar fi putut fi motivul introducerii bombei logice. Cu toate acestea, ultima picătură pentru administratorul de sistem a fost bonusul pe care l-a primit în valoare de 32.000 USD în loc de cei așteptați 50.000 USD. Când a descoperit că bonusul său era mult mai mic decât se aștepta, Duronio i-a cerut șefului său să-și renegocieze contractul de muncă la 175.000 de dolari pe an, altfel va părăsi compania. I s-a refuzat o creștere de salariu și i s-a cerut și să părăsească clădirea băncii. Ca răzbunare pentru un astfel de tratament, Duronio a decis să-și folosească „invenția”, introdusă în prealabil, anticipând o astfel de întorsătură a evenimentelor.

Duronio a implementat „bomba logică” de pe computerul său de acasă cu câteva luni înainte de a primi ceea ce el considera a fi un bonus prea mic. Bomba logică a fost instalată pe aproximativ 1.500 de calculatoare dintr-o rețea de sucursale din toată țara și setată la o oră anume - 9.30, exact la timp pentru începerea zilei bancare.

Duronio a demisionat de la UBS Paine Webber pe 22 februarie 2002, iar pe 4 martie 2002, o bombă logică a șters secvențial toate fișierele de pe serverul principal al bazei de date și 2.000 de servere din cele 400 de sucursale ale băncii, în timp ce a dezactivat sistemul de rezervă.

În timpul procesului, avocatul lui Duronio a subliniat că acuzatul nu poate fi vinovatul incidentului: având în vedere insecuritatea sistemelor IT UBS Paine Webber, orice alt angajat ar fi putut ajunge acolo sub login-ul lui Duronio. Problemele cu securitatea IT la bancă au devenit cunoscute încă din ianuarie 2002: în timpul unui audit, s-a constatat că 40 de persoane din serviciul IT se puteau conecta în sistem și puteau obține drepturi de administrator folosind aceeași parolă și să înțeleagă cine exact a făcut-o sau oricare. altă acțiune nu a fost posibilă. Avocatul a mai acuzat-o pe UBS Paine Webber și compania @Stake, angajată de bancă să investigheze incidentul, că au distrus dovezile atacului. Cu toate acestea, dovada de nerefuzat a vinovăției lui Duronio au fost bucățile de cod rău intenționat găsite pe computerele sale de acasă și o copie tipărită a codului din dulapul lui.

Oportunități din interior

Ca unul dintre administratorii de sistem ai companiei, Duronio a primit responsabilitatea și accesul la întreaga rețea de calculatoare UBS PaineWebber. De asemenea, avea acces la rețea de pe computerul său de acasă printr-o conexiune securizată la internet.

Motive

După cum am spus mai devreme, motivele lui au fost banii și răzbunarea. Duronio a primit un salariu anual de 125.000 de dolari și un bonus de 32.000 de dolari, în timp ce se aștepta la 50.000 de dolari, și astfel și-a răzbunat dezamăgirea.

În plus, Duronio a decis să facă bani din atac: anticipând o scădere a acțiunilor băncii din cauza unui dezastru IT, a făcut un ordin futures de vânzare pentru a primi diferența atunci când cursul a scăzut. Inculpatul a cheltuit 20.000 de dolari pentru asta. Totuși, titlurile băncii nu au căzut, iar investițiile lui Duronio nu au dat roade.

Consecințele

„Bomba logică” instalată de Duronio a oprit activitatea a 2.000 de servere din 400 de birouri ale companiei. Potrivit managerului IT UBS Paine Webber, Elvira Maria Rodriguez, a fost un dezastru „un peste 10 pe o scară de 10”. Haosul a domnit în companie, care au avut nevoie de 200 de ingineri de la IBM pentru a-i elimina timp de aproape o zi. În total, aproximativ 400 de specialiști au lucrat pentru a corecta situația, inclusiv serviciul IT al băncii însuși. Prejudiciul cauzat de incident este estimat la 3,1 milioane de dolari. Opt mii de brokeri din toată țara au fost forțați să nu mai lucreze. Unii dintre ei au reușit să revină la operațiunile normale după câteva zile, alții după câteva săptămâni, în funcție de cât de grav au fost afectate bazele lor de date și dacă filiala băncii avea copii de rezervă. În general, operațiunile bancare au fost reluate în câteva zile, dar unele servere nu au fost niciodată complet restaurate, în mare parte din cauza faptului că 20% dintre servere nu aveau facilități de backup. Doar un an mai târziu, întregul parc de servere al băncii a fost complet restaurat din nou.

În timpul procesului lui Duronio în instanță, el a fost acuzat de următoarele acuzații:

Frauda cu valori mobiliare - Această acuzație implică o pedeapsă maximă de 10 ani de închisoare federală și o amendă de 1 milion de dolari;

Fraudă informatică - Această acuzație implică o pedeapsă maximă de 10 ani de închisoare și o amendă de 250.000 USD.

În urma procesului de la sfârșitul lui decembrie 2006, Duronio a fost condamnat la 97 de luni fără eliberare condiționată.

„VimpelCom” și „Sherlock”

Adnotare

În scopul profitului, foștii angajați ai companiei VimpelCom ( marcă comercială„Beeline”) a oferit detalii prin intermediul site-ului convorbiri telefonice operatori celulari.

Descrierea incidentului

Angajații companiei VimpelCom (fostă și actuală) au organizat pe internet site-ul www.sherlok.ru, despre care compania VimpelCom a aflat în iunie 2004. Organizatorii acestui site au oferit un serviciu - căutarea persoanelor după nume, număr de telefon și alte date. În iulie, organizatorii site-ului au propus serviciu nou- detalii despre convorbirile telefonice ale operatorilor de telefonie celulară. Detalierea apelurilor este o imprimare a numerelor tuturor apelurilor primite și efectuate, care indică durata apelurilor și costul acestora, utilizată de operatori, de exemplu, pentru facturarea abonaților. Pe baza acestor date, putem trage o concluzie despre activitățile curente ale abonatului, domeniul său de interes și cercul de cunoștințe. Comunicatul de presă al Direcției „K” a Ministerului Afacerilor Interne (denumit în continuare Ministerul Afacerilor Interne) clarifică faptul că o astfel de informație costă clientul 500 USD.

Angajații companiei VimpelCom, după ce au descoperit acest site, au colectat în mod independent dovezi activitate criminală site-ul și a transferat cazul Ministerului Afacerilor Interne. Angajații Ministerului Afacerilor Interne au deschis un dosar penal și, împreună cu firma VimpelCom, au stabilit identitățile organizatorilor acestei afaceri criminale. Și la 18 octombrie 2004, principalul suspect 1 a fost reținut în flagrant.

Î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 companiei VimpelCom însăși. În timpul anchetei, s-a dovedit că site-ul a fost creat de un fost student al Moscovei universitate de stat care nu a lucrat pentru această companie.

Hârtiile privind acest incident au devenit posibile datorită deciziei Curții Constituționale din 2003, care a recunoscut că detaliile convorbirilor 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 lucra la piața Mitinsky în momentul crimei.

Lucrul ca casier în cadrul companiei indică faptul că acești angajați aveau acces direct la informațiile oferite spre vânzare pe site-ul www.sherlok.ru. Mai mult, din moment ce fost angajat compania 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 ale companiei VimpelCom.

Consecințele

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, publicarea 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 Ostankino din Moscova i-a condamnat pe suspecți, inclusiv trei angajați ai companiei VimpelCom, la diverse amenzi. Astfel, organizatorul grupului a fost amendat cu 93.000 de ruble. Cu toate acestea, funcționarea site-ului www.sherlok.ru a fost oprită pe termen nelimitat abia de la 1 ianuarie 2008.

Cea mai mare scurgere de date personale din istoria Japoniei

Adnotare

În vara lui 2006, a avut loc cea mai mare scurgere de date cu caracter personal din istoria Japoniei: un angajat al gigantului de tipar și electronice Dai Nippon Printing a furat un disc cu informații private de aproape nouă milioane de cetățeni.

Descrierea incidentului

Compania japoneză Dai Nippon Printing, specializată în producție produse de imprimare, a permis cea mai mare scurgere din istoria țării sale. Hirofumi Yokoyama, un fost angajat al unuia dintre contractorii companiei, a copiat datele personale ale clienților companiei pe un hard disk mobil și le-a furat. Un total de 8,64 milioane de persoane au fost în pericol, deoarece informațiile furate includ nume, adrese, numere de telefon și numere de card de credit. Informațiile furate au inclus informații despre clienți de la 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ă furtul acestor informații, Hirofumi a deschis comerț cu informații private în porțiuni din 100.000 de înregistrări. Datorită veniturilor stabile, insiderul și-a părăsit chiar locul de muncă permanent. Până la arestarea sa, 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 achiziții 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.

Consecințele

Î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.

În 2003, Japonia a adoptat Legea privind protecția informațiilor cu caracter personal din 2003 (PIPA), dar procurorii nu au putut să o aplice în cadrul procedurilor penale efective. acest caz la începutul anului 2007, procuratura nu a reușit să acuze persoana din interior pentru încălcarea PIPA. El este acuzat doar că a furat un hard disk în valoare de 200 de dolari.

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

Adnotare

Un fost administrator de sistem al uneia dintre marile bănci din Ucraina a transferat aproximativ 5 milioane de grivne prin intermediul băncii în care anterior lucra din contul vămii regionale în contul unei inexistente companie falimentară din Dnepropetrovsk.

Descrierea incidentului

Cariera sa de administrator de sistem a început după ce a absolvit școala tehnică și a fost angajat de una dintre marile bănci din Ucraina în software și suport tehnic. 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 la bancă a presupus și 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, dar talentul lui s-a dovedit a fi nerevendicat și i s-a oferit postul inexistent de șef adjunct, dar într-un alt departament. Ca urmare a unor astfel de schimbări de personal, a început să facă ceva complet diferit de ceea ce știa cel mai bine.

Administratorul de sistem nu a putut să suporte această atitudine de conducere față de sine și să renunțe din proprie voință. Cu toate acestea, era bântuit de propria mândrie și resentimente față de management, în plus, a vrut să demonstreze că este cel mai bun în afacerea lui și să se întoarcă la departamentul în care și-a început cariera.

După ce a demisionat, fostul administrator de sistem a decis să returneze interesul fostului management față de persoana sa, folosind imperfecțiunile sistemului „Bancă-Client” folosit în aproape toate băncile din Ucraina 2 . Planul administratorului de sistem era ca acesta să decidă să-și dezvolte propriul program de securitate și să-l ofere băncii, revenind la locul de muncă anterior. Implementarea planului a constat în pătrunderea sistemului Bancă-Client și efectuarea unor modificări minime la acesta. Întregul calcul a fost făcut pe baza faptului că banca ar fi descoperit un hack de sistem.

Pentru a pătrunde în sistemul specificat, 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 diferite cazuri de hacking retele de calculatoare, tehnici de hacking și conținea 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ă falsească ordin de platași transferați o sumă mare prin intermediul acestuia prin sistemul informatic al băncii. Folosind un laptop și telefon mobil cu un modem încorporat, administratorul de sistem a pătruns în sistemul informatic al băncii de aproximativ 30 de ori: s-a uitat la documente, conturile clienților, traficul numerar- cautare clienti potriviti. A ales ca atare clienți vama regională și o companie falimentară din Dnepropetrovsk.

După ce a obținut din nou acces la sistemul băncii, a creat un ordin de plată în care cont personal vama regională a retras şi transferat prin intermediul bancii în contul unei companii falimentare 5 milioane grivne. În plus, a făcut intenționat mai multe greșeli în „plată”, care, la rândul lor, ar fi trebuit să ajute și mai mult să atragă atenția specialiștilor bănci. Cu toate acestea, nici măcar astfel de fapte nu au fost observate de specialiștii băncii care deservesc sistemul Bank-Client și au transferat cu calm 5 milioane de grivne în contul unei companii defuncte.

În realitate, administratorul de sistem se aștepta ca fondurile să nu fie transferate, să se descopere faptul hacking-ului înainte ca fondurile să fie transferate, dar în practică totul a ieșit altfel și a devenit infractor, iar transferul său fals a escaladat în 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 raportat că nimeni nu a transferat o asemenea sumă. Banii au fost returnați de urgență băncii, iar un dosar penal a fost deschis la parchetul din regiunea Zaporojie.

Consecințele

Banca nu a suferit nicio pierdere, din moment ce banii au fost restituiți proprietarului, iar sistemul informatic a primit daune minime, drept care conducerea băncii a refuzat orice pretenție împotriva fostului administrator de sistem.

În 2004, prin decretul președintelui Ucrainei, a fost întărită răspunderea penală pentru infracțiunile informatice: amenzi de la 600 la 1000 de minime scutite de taxe, închisoare de la 3 la 6 ani. Cu toate acestea, fostul administrator de sistem a comis o infracțiune înainte de intrarea în vigoare a decretului prezidențial.

La începutul anului 2005 a avut loc un proces al 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 - interferență ilegală în funcționarea sistemelor informatice care dăunează și în temeiul părții 5 a articolului 185 - furt comis la scară deosebit de mare. Dar, deoarece conducerea băncii a refuzat să facă vreo pretenție împotriva lui, acuzația de furt a fost înlăturată 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 banca 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 Jerome Kerviel. După cum a arătat o investigație internă, de câțiva ani traderul a deschis poziții peste 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 de control intern al computerului a emis un avertisment cu privire la posibile încălcări de 75 de ori (de câte ori Jerome Kerviel a efectuat tranzacții neautorizate sau pozițiile sale au depășit limita admisă). Angajații departamentului de monitorizare a riscurilor băncii nu au efectuat verificări detaliate asupra acestor avertismente.

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 din Londra), așa că primii 500.000 de euro au fost câștigați. Ulterior, Kerviel le-a povestit anchetatorilor despre sentimentele pe care le-a trăit de la primul său succes: „Știam deja să-mi închid poziția și eram mândru de rezultat, dar în același timp am fost surprins. Succesul m-a făcut să continui, a fost ca un bulgăre de zăpadă... În iulie 2007, mi-am propus să iau o poziție scurtă în așteptarea unui declin al pieței, dar nu am primit sprijin de la managerul meu. Prognoza mea s-a adeverit și am făcut profit, de data aceasta a fost complet legal. Ulterior, am continuat să efectuez astfel de operațiuni pe piață, fie cu acordul superiorilor mei, fie în lipsa obiecției sale explicite... Până la 31 decembrie 2007, profitul meu a ajuns la 1,4 miliarde de euro. În acel moment, nu știam cum să declar asta la banca mea, deoarece era o sumă foarte mare care nu era declarată nicăieri. Eram fericit și mândru, dar nu am știut să explic conducerii mele primirea acestor bani și să nu am suspiciunea de a efectua tranzacții neautorizate. Prin urmare, am decis să-mi ascund profitul și să conduc operațiunea fictivă opusă...”

De fapt, la începutul lunii ianuarie a acelui an, Jerome Kerviel a reintrat în joc cu contracte futures pe cei trei indici Euro Stoxx 50, DAX și FTSE, care l-au ajutat să învingă piața la sfârșitul anului 2007 (deși a preferat să fie scurt la timp). Conform calculelor, în ajunul zilei de 11 ianuarie, portofoliul său conținea 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). per 1 contract) pentru indicele FTSE. În total, 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 a lucrat.

Cunoscând momentul efectuării verificărilor, 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 considerată riscantă. Ei nu au putut fi alarmați de cantitățile mari de tranzacții, care sunt destul de frecvente pe piața futures pe indici. A fost dezamăgit de tranzacțiile fictive efectuate din conturile clienților băncilor. Utilizarea conturilor diverșilor clienți ai băncilor nu a dus la probleme vizibile controlorilor. Cu toate acestea, de-a lungul timpului, Kerviel a început să folosească conturile acelorași clienți, ceea ce a dus la activitate „anormală” observată pe 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 prin e-mail tranzacția astronomică. Cu toate acestea, confirmarea electronică a stârnit suspiciuni în rândul inspectorilor, iar la Societe Generale a fost creată o comisie care să le verifice. Pe 19 ianuarie, ca răspuns la o solicitare, banca germană nu a recunoscut această tranzacție, după care comerciantul a acceptat să mărturisească.

Când a fost posibil să se afle 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. Acest lucru a durat două zile și a dus la pierderi de 4,9 miliarde de euro.

Oportunități din interior

Jerome Kerviel a lucrat cinci ani în așa-numitul back office al băncii, adică într-un departament care nu încheie direct nicio tranzacție. Se ocupă doar de contabilitate, executarea și înregistrarea tranzacțiilor și monitorizează comercianții. Această activitate ne-a permis să înțelegem caracteristicile sistemelor de control din bancă.

În 2005, Kerviel a fost promovat. A devenit un adevărat comerciant. În responsabilitățile imediate tânăr au inclus operațiuni de bază pentru a minimiza riscurile. Lucrând pe piața futures a indicilor bursieri europeni, Jerome Kerviel a trebuit să monitorizeze modul în care portofoliul de investiții al băncii se schimbă. Iar sarcina lui principală, după cum a explicat un reprezentant al 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, a trebuit să parieze pe negru”. La fel ca toți comercianții juniori, Kerviel avea o limită pe care nu o putea depăși, aceasta a fost monitorizată de el foști colegiîn back office. Societe Generale avea mai multe straturi 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 i-a fost greu să ocolească acest sistem. Știa parolele altora, știa când se făceau verificări la bancă, cunoștea bine tehnologia de informație.

Motive

Dacă Kerviel a fost implicat în fraudă, nu a fost în scopul îmbogățirii personale. Avocații săi spun asta, iar reprezentanții băncii recunosc și ei acest lucru, considerând 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.

Consecințele

La sfârșitul anului 2007, activitățile sale au adus băncii un profit de aproximativ 2 miliarde de euro. În orice caz, asta spune însuși Kerviel, susținând că conducerea băncii probabil știa ce face, dar a preferat să închidă ochii atâta timp cât era profitabil.

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

În mai 2008, Daniel Bouton a părăsit postul de CEO al Societe Generale, fiind înlocuit în această funcție de Frederic Oudea. 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 sale a fost critica acerbă din partea presei: Bouton a fost acuzat de faptul că managerii de vârf ai băncii aflate sub controlul său au încurajat tranzacțiile financiare riscante efectuate de angajații băncii.

În ciuda sprijinului consiliului de administrație, presiunea asupra domnului Bouton a crescut. Acţionarii băncii şi mulţi politicieni francezi i-au cerut demisia. 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 Societe Generale a emis un avertisment de 75 de ori, adică de fiecare dată când Jerome Kerviel a efectuat posibile încălcări neautorizate .

Imediat după ce au fost descoperite pierderile, 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 auditorii PricewaterhouseCoopers. Comisia a concluzionat că sistemul de control intern al băncii nu a fost suficient de eficient. Acest lucru a dus la imposibilitatea băncii de a preveni o asemenea fraudă la scară largă. Raportul precizează că „personalul băncii nu a efectuat verificări sistematice” ale activităților comerciantului, iar banca însăși nu avea „un sistem de control care ar putea preveni frauda”.

Raportul privind rezultatele auditului comerciantului arată că în urma rezultatelor 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 divizii ale băncii și coordonarea interacțiunii acestora. De asemenea, vor fi luate măsuri pentru urmărirea și personalizarea operațiunilor de tranzacționare ale angajaților băncii prin „consolidarea sistemului de securitate informatică și dezvoltarea de soluții de înaltă tehnologie pentru identificarea personală (biometrie)”.

Din cartea Asigurarea securității informațiilor în afaceri autorul Andrianov V.V.

4.2.2. Tipologia incidentelor Generalizarea practicii mondiale ne permite să identificăm următoarele tipuri de incidente de securitate a informațiilor care implică personalul organizației: - dezvăluirea de informații oficiale - furtul de bunuri financiare;

Din cartea Pensie: procedura de calcul si inregistrare autor Minaeva Lyubov Nikolaevna

4.3.8. Investigarea incidentelor Un incident în care este implicat un angajat al unei organizații este o urgență pentru majoritatea organizațiilor. Prin urmare, metoda de organizare a unei investigații depinde în mare măsură de situația predominantă. cultura corporativă organizatii. Dar poți cu încredere

Din cartea Day Trading in the Forex Market. Strategii de profit de Lyn Ketty

2.5. Exemple Să luăm în considerare câteva opțiuni de atribuire a pensiilor de muncă în cazul transferului documentelor către organele teritoriale ale Fondului de pensii prin poștă: Exemplul 1 O cerere de atribuire a unei pensii de muncă pentru limită de vârstă a fost transmisă organului teritorial al fondului

Din cartea Management Practice resurse umane autor Armstrong Michael

3.5. Exemple Exemplul 1 Experiența de muncă constă în perioade de muncă de la 15 martie 1966 până la 23 mai 1967; de la 15.09.1970 la 21.05.1987; de la 01.01.1989 la 31.12.1989; de la 04.09.1991 la 14.07.1996; de la 15.07.1996 la 12.07.1998 și serviciul militar de la 27.05.1967 la 09.06.1969 Să calculăm vechimea în muncă pentru evaluarea drepturilor de pensie

Din cartea autorului

4.4. Exemple Exemplul 1 Inginerul Sergeev A.P., născut în 1950, a solicitat o pensie pentru limită de vârstă în martie 2010. În 2010, a împlinit 60 de ani. Vechimea totală pentru evaluarea drepturilor de pensie de la 1 ianuarie 2002 este de 32 de ani, 5 luni, 18 zile, inclusiv 30 de ani înainte de 1991.

Din cartea autorului

6.3. Exemple Exemplul 1 la care a lucrat managerul de vânzări V.N contract de munca de la 01.01.2010 1 ianuarie 2013 moare la vârsta de 25 ani. În același timp, mai are părinți apți de muncă, o soție aptă de muncă și o fiică în vârstă de 3 ani. În acest caz, dreptul de a primi muncă

Din cartea autorului

7.4. Exemple Exemplul 1 Manager Vasiliev R. S., 60 de ani. Experienta totala in munca cartea de munca pentru evaluarea drepturilor de pensie de la 01.01.2002 este de 40 de ani. Câștigul mediu lunar pentru 2000–2001, conform datelor contabile personalizate, este de 4.000 de ruble. Vom calcula și compara sumele pensiei conform

Din cartea autorului

8.3. Exemple Exemplul 1 Un pensionar primește o pensie de invaliditate din grupa I. Din 20 mai până în 5 iunie 2009, a fost supus încă o reexaminare la BMSE și a fost recunoscut ca grupa III de dizabilități la 3 iunie 2009. Grupa de dizabilități în acest caz a scăzut. Partea de bază supuse pensiei

Din cartea autorului

10.4. Exemple Exemplul 1 Decesul unui pensionar s-a produs la 28 ianuarie 2009. Văduva pensionarului a solicitat pensie în februarie 2009. În acest caz de pensie nu a fost stabilită convieţuirea văduvei cu pensionarul fondul acceptat

Din cartea autorului

14.7. Exemple Exemplul 1 Koshkina V.N., care era dependentă de soțul ei decedat, a împlinit vârsta de 55 de ani la 3 luni după moartea acestuia. Am solicitat pensie după 1 an de la data decesului soțului/soției mele Conform legislației privind pensiile, pensia se va atribui de la data

Din cartea autorului

17.5. Exemple Exemplul 1 U antreprenor individual Patru persoane lucrează în baza unui contract de muncă: Moroz K.V (n. 1978), Svetlova T. G. (n. 1968), Leonova T. N. (n. 1956) și Komarov S. N. (n. 1952). Să presupunem lunar salariile fiecare dintre ele este de 7.000 de ruble.

Din cartea autorului

Exemple Să ne uităm la câteva exemple despre cum funcționează această strategie: 1. Graficul de 15 minute a EUR/USD din Fig. 8.8. Conform regulilor acestei strategii, vedem că EUR/USD a scăzut și se tranzacționa sub media mobilă pe 20 de zile. Prețurile au continuat să scadă, îndreptându-se spre 1.2800, adică

Din cartea autorului

Exemple Să studiem câteva exemple.1. În fig. Figura 8.22 prezintă un grafic de 15 minute de USD/CAD. Raza totală a canalului este de aproximativ 30 de puncte. În conformitate cu strategia noastră, plasăm ordine de intrare cu 10 puncte deasupra și sub canal, adică la 1.2395 și 1.2349. Ordin de cumpărare executat

Din cartea autorului

Exemple Să ne uităm la câteva exemple ale acestei strategii în acţiune.1. În fig. Figura 8.25 prezintă graficul zilnic EUR/USD. Pe 27 octombrie 2004, mediile mobile EUR/USD au format o ordine corectă consistentă. Deschidem o poziție la cinci lumânări după începerea formării la 1.2820.

Salutare tuturor Habrazhiters,
Foarte des, ca serviciu de proces, auziți o întrebare foarte populară din partea angajaților departamentelor IT mari și mici: care este diferența dintre o solicitare de serviciu și un incident?

Discuțiile pe această temă sunt la fel de vechi ca toate metodologiile de management IT luate împreună, totuși, să ne întoarcem la sursele primare.

Ce ne spune ITIL (traducerea oficială a glosarului conform celei de-a treia versiuni):

Solicitare de service- cererea unui utilizator de informații, sau de consultare, sau modificare standard, acces la serviciul IT.

Incident- întreruperea neplanificată a unui serviciu IT sau reducerea calității unui serviciu IT.

Ca de obicei, metodologia nu pătrunde în profunzimea lucrurilor și chiar nu-i place să răspundă la întrebările de fond ale angajaților oricărui Service Desk care clasifică solicitările utilizatorilor. Între timp, există o mulțime de astfel de întrebări, iată câteva exemple:

1) Apel Christomatic de la un utilizator care cere resetarea parolei - cum se clasifică drept solicitare de serviciu sau incident? Sau poate ca un incident de securitate a informațiilor?

2) Un apel de la un utilizator a cărui e-mail corporative nu funcționează. O analiză rapidă a solicitării sugerează că utilizatorul trebuie să efectueze configurarea inițială a clientului de e-mail. Cu toate acestea, din punctul lui de vedere, acesta este un incident, pentru că... serviciul nu este disponibil și nimeni nu l-a notificat că „e-mailul în sine nu va zbura”

Inutil să spunem că clasificarea primară este foarte importantă, deoarece determină întregul ciclu de viață ulterior al recursului, inclusiv. și termenele limită.

Înțelegerea mea despre această problemă se rezumă la o chestiune de evaluare întreruperi ale serviciului pentru consumatorul final și astfel:

Incident- aceasta este, în cele mai multe cazuri, o întrerupere sau o întrerupere parțială a unui serviciu IT care a fost furnizat anterior utilizatorului într-un mod aprobat (serviciul este disponibil 24/7 sau 5/8).

Exemplu: Contabilul-șef al companiei a pierdut brusc accesul la sistem situatii financiare. Pe de o parte, asigurarea accesului este o cerere clasică de serviciu, dar în acest caz există o întrerupere clară a serviciului și, în consecință, o degradare parțială a procesului de afaceri.

Solicitare de service- aceasta este o solicitare din partea unui utilizator care este interesat să se conecteze serviciu suplimentar, sau îmbunătățirea funcționalității serviciilor existente.

Exemplu: Un utilizator deosebit de curios a încercat să deschidă unul dintre modulele aceluiași sistem de raportare financiară, dar a primit un mesaj de eroare. Din punctul lui de vedere acesta este o întâmplare, întrucât nu și-a atins scopul dorit și nu a primit informațiile pe care le căuta, ci, din punct de vedere. descris mai sus este o cerere clasică de serviciu pentru acces, care necesită aprobare și efectuată conform unei proceduri standard într-un interval de timp convenit.

În același timp, nu ar trebui să uităm de varietatea cazurilor speciale care sunt în general dificil de clasificat, punctul de vedere descris mai sus nu se pretinde a fi un dogmă, ci se străduiește doar să contribuie la minimizarea numărului de solicitări clasificate incorect și să îmbunătățească; timpul general de răspuns IT la nevoile afacerii.