MASTER: MANAGEMENTUL INFORMAȚIEI ȘI AL DOCUMENTELOR [306516]

UNIVERSITATEA BUCUREȘTI

FACULTATEA DE LITERE

DEPARTAMENT: ȘTIINȚE ADMINISTRATIVE

MASTER: MANAGEMENTUL INFORMAȚIEI ȘI AL DOCUMENTELOR

Sisteme inteligente de monitorizare a [anonimizat]:

As. dr. ing. DUMITRACHE Mihail

ABSOLVENT: [anonimizat]

2017

Cuprins

Metodologia de Asistență Tehnică și Suport 3

1.Introducere 3

2.Termeni, definiții si abrevieri 3

3.Comunicare 7

3.1Diagrama de stari 7

4.SLA 8

5.Obligații 10

5.1Obligațiile furnizorului 10

5.2Obligațiile clientului 11

6.[anonimizat], înregistrări, documente 12

6.1Roluri 12

6.2Procesul de gestiune sesizari 12

6.3Activitati 14

6.4Procedura de Escaladare catre Management 23

6.5Formulare 24

6.6Matricea de Responsabilitati 25

7.Anexe 26

7.1Anexa 1: Formular Sesizare 26

7.2Anexa 2: Proces verbal de ședința 27

7.3Anexa 3: Raport de activitate servicii de asistenta tehnica si suport………………………………….28

Descriere si functionalitati aplicatie WTS 3

2.Logare in aplicatie 7

Flux de desfasurare a procesului de gestiune solicitari de suport 7

3.1Inregistrarea solicitarii de suport 7

3.2Receptionarea solicitarii de suport 9

3.3Verificarea si rezolvarea solicitarii de suport 10

3.4Urmarirea solicitarilor de suport 11

Metodologia de Asistență Tehnică și Suport pentru platforma

„INFRASTRUCTURĂ DE TIP CLOUD PENTRU INSTITUȚIILE PUBLICE DIN ROMÂNIA” – ICIPRO

1.Introducere

Prezenta procedura a fost elaborata in vederea descrierii detaliate a [anonimizat].

Procedura cuprinde următoarele secțiuni:

Definirea termenilor;

Descrierea aplicatiei de gestiune a sesizarilor

Detalierea calculului SLA si timpilor de răspuns si rezolvare;

Detalierea activităților;

Formularele utilizate;

Anexe.

2.Termeni, [anonimizat]:

1. Contract

Contractul de livrare încheiat intre Ofertant si Client.

2. Client=Beneficiar

Beneficiarul aplicației furnizata așa cum este definita in cadrul contractului.

3. Furnizor = Ofertant

4. [anonimizat].

5. Program de lucru

Intervalul orar in care se receptioneaza si se trateaza solicitarile de suport.

6. Timp de răspuns =Timp de luare la cunostinta=[anonimizat], intre momentul in care Furnizorul a receptionat sesizarea Utilizatorului si momentul in care Furnizorul a trimis mesajul cuprinzand numarul de inregistrare al sesizarii facute.

7. [anonimizat], intre momentul in care Furnizorul primeste in mod oficial o [anonimizat], [anonimizat], [anonimizat], o [anonimizat], [anonimizat].

8. Service Level Agreement

Prevedere a prezentei proceduri (sau contractului) care specifica timpii de răspuns si timpii de rezolvare asigurați de către furnizor pe perioada furnizării serviciilor.

9. SLA

Acronim pentru Service Level Agreement.

10. Aplicație = Sistem informatic in suport

Aplicația implementata de către furnizor având funcționalitățile descrise in documentele de analiza aprobate.

11. Aplicații externe

Orice sistem informatic si/sau aplicație, altele decât aplicația furnizată care influențează sau schimba date cu aplicația furnizată.

12. Echipamentele hardware ale sistemului

Infrastructura hardware furnizata in cadrul contractului, definita in lista de acceptanta si procesele verbale de Primire/Receptie constand in servere si statii de lucru

13. Utilizator: persoana desemnata de Beneficiar care utilizeaza Aplicatia furnizată si care poate transmite sesizari catre centrul de suport.

14. Responsabil Suport Client (RSC): este persoana desemnata de catre Beneficiar care verifica daca cererile de suport pot fi rezolvate intern si valideaza din punct de vedere al Beneficiarului cererile de suport transmise de catre Utilizator.

15. Specialist Suport Tehnic (SST): este persoana care receptioneaza/rezolva sesizarile sosite de la Utilizator prin intermediul telefonului si/sau a emailului si a aplicatiei de ticketing.

16. Consultant: persoana care ofera informatii sau executa actiuni de suport de Nivel superior (Nivel 2 sau Nivel 3) la cererea unui SST. Astfel, un Consultant poate sa fie un analist, un implementator, un dezvoltator sau un administrator de infrastructura.

17. Sesizare =Solicitare = Incident: solicitare de suport transmisa de Utilizator prin intermediul emailului Aplicatiei de Ticketing sau telefonului catre serviciul de suport.

18. Severitate = Prioritate

Categorie utilizata pentru a identifica importanta unei sesizari, a unei probleme sau schimbari. Prioritatea este bazata pe impact si urgenta si este utilizata pentru a identifica timpul necesar pentru desfasurarea actiunilor.

19. Formular Sesizare: document oficial (in format electronic) folosit de catre Utilizator pentru a defini si transmite catre SST, intr-un format standardizat, informatii cu privire la incidentele aparute.

20. Sesizare valida: sesizare pentru care Furnizorul a receptionat de la Utilizator toate informatiile de identificare si reproducere a incidentului, necesare solutionarii acestuia, descrise in Formular Sesizare.

21. Aplicatia de Ticketing = aplicatia folosita pentru gestionarea tuturor cererilor de suport

22. Rezolvare sesizare: Masuri luate pentru repararea unei cauze principale a unui incident sau a unei probleme. Rezolvarea unui incident poate sa aiba mai multe forme:

Transmiterea informatiilor cerute de utilizator;

Transmiterea catre utilizator a informatiilor necesare pentru efectuarea activitatii dorite;

Efectuarea activitatilor necesare pentru obtinerea rezultatului dorit;

Marcare incident " Functionalitate noua”;

Marcare incident “Infrastructura hardware”;

Marcare incident “Infrastructura comunicatii”;

Marcare incident “Infrastructura software”;

Marcare incident “Modificare aplicatie neautorizata”;

Marcare incident “Operare gresita”;

Marcare incident “In afara suportului”;

Marcare incident “Mediu server de test”;

Marcare incident “Utilizator neautorizat”;

Marcare incident ”Informatii insuficiente”;

Marcare incident ”Nu se reproduce”;

Marcare incident ”Incident nou”;

Marcare incident ”Modificare aplicatie” si Numarul buildului

23. Schimbare(Change): adaugare, modificare sau eliminare a oricarei functionalitati ce ar putea avea un efect asupra aplicatiei. Include orice schimbare asupra arhitecturilor, proceselor, instrumentelor, metricelor si documentatiilor, precum si schimbarilor serviciilor si a altor elemente de configuratie.

24. Managementul Schimbarilor(Change Management): procesul de identificare, control, analiza, aprobare si aplicare a schimbarilor.

25. Functionalitate noua: orice cerinta nespecificata in specificatiile functionale aprobate ale sistemelor informatice aflate in suport (Sistem Informatic in Suport) precum si de solicitarile de informatii, situatii sau rapoarte care nu se pot obtine prin rularea unei functionalitati existente in sistem. Functionalitatea noua poate fi determinata si:

de schimbarile legislative corespunzatoare ariei de acoperire a aplicatiei incluzand dezvoltare, configurare, scolarizare si testare;

ca urmare a modificarilor normelor interne privind aplicarea schimbarilor legislative corespunzatoare ariei de acoperire a aplicatiei incluzand dezvoltare, configurare, scolarizare si testare;

ca urmare a modificarilor normelor interne privind aplicarea legislatiei in vigoare corespunzatoare ariei de acoperire a aplicatiei, care nu decurg din modificari ale legislatiei respective;

ca urmare a unor cerinte de modificare a functionalitatilor existente care sunt in conformitate cu documentele de analiza aprobate;

ca urmare a unor cerinte de adaugare de functionalitati noi, in plus fata de functionalitatile prevazute si descrise in documentele de analiza aprobate.

Termenii si abrevierile de mai sus se vor utiliza in comunicarea oficiala intre părți, pentru orice referire la serviciile de asistență tehnică și suport tehnic si numai in conformitate cu definițiile corespunzătoare.

Singura interpretare posibila pentru termenii si abrevierile de mai sus este cea data de definițiile lor, așa cum sunt ele prezentate in acest document.

3. Comunicare

a. Metode de comunicare

Comunicarea intre client si furnizor se va desfășura cu preponderenta in scris, cu respectarea stricta a condițiilor de confidențialitate si folosind una din următoarele metode:

Întâlniri directe urmate de semnarea proceselor verbale de ședința,

Aplicatia de ticketing

Email

In situatii critice, in vederea transmiterii rapide de catre utilizator a solicitarilor de suport tehnic, comunicarea se va putea desfasura prin utilizarea telefonului.

b. Informații de contact

3.1 Diagrama de stari

Starile prin care trece o sesizare in ciclul ei de viata sunt urmatoarele:

SLA

In cele ce urmeaza este prezentat modul de calcul al SLA-ului pentru incidentele receptionate de Furnizor:

Data/ora pentru calcul

Datele si orele de inregistrare in Aplicatia de ticketing si care vor fi folosite pentru calcularea SLA-ului vor fi urmatoarele:

In cazul utilizarii telefonului: Data si ora de inregistrare in Aplicatia de ticketing = data si ora la care s-a incheiat convorbirea telefonica;

In cazul utilizarii emailului: Data si ora de inregistrare in Aplicatia de ticketing = data si ora la care furnizorul a receptionat emailul, reprezentand data si ora de serverul de email – in cazul primirii de informatii de catre furnizor, respectiv data si ora la care furnizorul a trimis emailul, reprezentand data de serverul de email – in cazul transmiterii de informatii de catre furnizor.

Calcul SLA Timp de Raspuns

Conform contractului se considera ca timpul de rapuns pentru o sesizare se calculeaza numai in timpul programului de lucru cu exceptia sesizarior de severitate critica si majorade orice severitate se calculeaza numai in timpul programului de lucru.

In momentul sosirii unui incident pe adresa de email sau prin telefon, acesta este inregistrat in Aplicatia de ticketing avand starea « creat ».

In momentul in care furnizorul trimite emailul de receptionare incident si numarul de ordine al incidentului, acest lucru este inregistrat in Aplicatia de ticketing, iar incidentul trece in starea « receptionat ».

Timpul de raspuns este calculat prin diferenta orelor din cadrul Programului de Lucru ditre cele 2 stari: creat si receptionat. Daca SLA-ul este afectat datorita incidentelor de comunicatii din infrastructura beneficiarului, timpul datorat acestor incidente va fi dedus din timpul de raspuns.

Calcul SLA Timp de Rezolvare

Conform contractului se considera ca timpul de rezolvare pentru o sesizare de orice severitate se calculeaza numai in timpul programului de lucru.

Timpul de rezolvare alocat unei sesizari de orice severitate se calculeaza incepand din momentul receptionarii unei Sesizari Valide. In acest moment sesizarea trece in starea “in curs de rezolvare” in Aplicatia de ticketing. Acest moment se considera startul contorului de timp pentru SLA-ul de rezolvare incident.

In momentul in care incidentul este rezolvat de catre furnizor trece in starea “rezolvat” in Aplicatia de ticketing. In acest moment se opreste contorul de timp pentru SLA-ul de rezolvare incident.

Timpul de rezolvare este calculat ca fiind timpul scurs in cadrul Programului de lucru intre cei doi timpi inregistrati in Aplicatia de ticketing corespunzatori celor 2 stari  « in curs de rezolvare »  si « rezolvat » din care se deduc urmatorii timpi :

Daca SLA-ul este afectat datorita incidentelor de comunicatii din infrastructura beneficiarului, timpul datorat acestor incidente va fi dedus din timpul de rezolvare.

Timpul de asteptare a informatilor de la beneficiar, timpul in care sesizarea este in starea « in asteptare informatii client »  (din momentul in care au fost cerute informatiile, pana in momentul in care au fost primite) va fi dedus din timpul de rezolvare.

5.Obligații

5.1 Obligațiile furnizorului

Furnizorul va respecta procedura descrisa in prezentul document.

Furnizorul va aloca o persoana de contact dedicata menținerii legăturii cu clientul si receptionarii incidentelor, pe toata perioada de furnizare a serviciilor.

Furnizorul va aloca o persoana cu rol de backup al persoanei de contact

Persoana de contact desemnata de către furnizor va avea toate atribuțiile necesare bunei desfășurări a procesului.

Schimbarea persoanei de contact se poate face numai cu notificare oficiala către client trimisa de către furnizor cu cel puțin 15 zile înainte de data de la care schimbarea devine efectiva.

Persoana de contact alocata de catre Furnizor va inregistra in Aplicatia de ticketing toate incidentele primite de la Utilizatorii aplicatiei precum si discutiile avute cu utilizatorii, referitoare la aceste incidente.

In momentul receptionarii unui incident persoana alocata va transmite catre utilizator un email de receptionare a incidentului, impreuna cu numarul incidentului, in conformitate cu timpul de raspuns stabilit.

Furnizorul va solicita clientului informatii suplimentare in situatia in care informatiile transmise nu sunt suficiente pentru finalizarea verificarilor situatie transmise si rezolvarii solicitarii de suport.

Furnizorul va solicita utilizatorului confirmarea rezolvarii solicitarii de suport si acordul pentru inchiderea incidentului.

Daca utilizatorul nu confirma/infirma rezolvarea incidentului in termen de 5 zile lucratoare Furnizorul va inchide in mod automat incidentul.

5.2 Obligațiile clientului

Clientul va respecta procedura descrisa in prezentul document

Clientul va desemna o persoana de contact dedicata menținerii legăturii cu furnizorul pe toata perioada de furnizare a serviciilor.

Persoana de contact desemnata de către client va avea toate atribuțiile necesare bunei desfășurări a activității.

Clientul va desemna o persoana de contact ce va fi disponibila pe tot parcursul programului de lucru, pe durata intregii perioade pentru care se acorda serviciile de suport si asistenta tehnica.

Schimbarea persoanei de contact se poate face numai cu notificare oficiala către furnizor trimisa de către client cu cel puțin 15 zile înainte de data de la care schimbarea devine efectiva.

Utilizatorii vor folosi aplicatia de ticketing ca mijloc de comunicare cu furnizorul si doar in caz de incidente critice sau de nefuncitonalitate a aplicatiei Aplicatiei de ticketing, vor utiliza telefonul .

Clientul va furniza toate informatiile necesare investigarii solicitarii de suport.

Clientul va furniza informatiile suplimentare solicitate de catre furnizor, necesare rezolvarii solicitarii de suport. Perioada de timp in care nu se poate investiga solicitarea de suport datorita lipsei informatiilor suplimentare va fi marcata cu mentiunea „In asteptare informatii client”

Clientul va formula o cerere de suport distincta, pentru fiecare incident semnalat. Daca un utilizator doreste sa formuleze mai multe cereri de suport, va raporta mai multe incidente.

Clientul va defini rezultatul asteptat intr-un mod clar si masurabil, astfel incat in momentul rezolvarii incidentului sa se poata decide usor daca a fost rezolvat sau nu.

Utilizatorul este responsabil sa verifice rezolvarea incidentului si sa confirme sau nu in termen de 5 zile de la primirea rezolvarii daca incidentul este rezolvat sau nu. Daca utilizatorul nu ofera niciun raspuns in intervalul de timp precizat, incidentul va fi inchis.

6. Flux de lucru, roluri, înregistrări, documente

6.1 Roluri

Rolurile implicate in procesul de furnizare a serviciilor sunt prezentate in tabelul de mai jos:

6.2 Procesul de gestiune sesizari

Procesul de gestiune a sesizarilor se va desfășura in conformitate cu diagrama prezentata mai jos:

Figura 2 : Diagrama proces gestiune si rezolvare sesizare

Activitati

Procedura de Escaladare catre Management

Prin intermediul aceastei proceduri, SST escaladeaza catre managementul beneficiarului si catre managementul furnizorului incidentele care necesita interventia managementului pentru clarificarea actiunii urmatoare.

Aceasta procedura se aplica in urmatoarele situatii:

Cand SST si utilizatorul nu sunt de acord asupra severitatii unui incident.

In cazul incidentelor cu severitate 1 sau 2.

In cazul in care utilizatorul a modificat informatiile ce definesc un incident (din formularul de sesizare a unui incident sau informatii cerute ulterior)

In cazul in care utilizatorul si SST nu au cazut de acord in ceea ce priveste rezolvarea unui incident si deschiderea unui incident nou.

Atat Beneficiarul cat si Furnizorul vor furniza numele unei persoane de contact pentru primul nivel de escaladare si numele unei persoane de contact pentru al-II-lea nivel de escaladare.

In timpul in care se asteapta decizia pentru continuarea incidentului din partea managementului beneficiarului si managementului furnizorului, incidentul va fi trecut in starea “In asteptare informatii client”(Suspendat). SST contacteaza (mai intai telefonic si apoi prin email) primul nivel de escaladare al beneficiarului si al furnizorului.

Daca SST nu reuseste contactarea telefonica a primului nivel de escaladare al beneficiarului si al furnizorului, contacteaza (mai intai telefonic si apoi prin email) al-II-lea nivel de escaladare al beneficiarului si al furnizorului.

Metodele de comunicare in cazul procedurii de escaladare sunt enumerate mai jos, in functie de urgenta si impactul sesizarii (daca atat urgenta, cat si impactul sunt mari, comunicarea se face prin discutie directa sau telefonica):

Discutie directa

Telefon

Email

Aplicatia de Ticketing.

Formulare

Matricea de Responsabilitati

Anexe

Anexa 1: Formular Sesizare

Nr. ……………. / din Data ………………………

Acest formular conține informațiile de identificare, reproducere si descriere a unui incident. Aceste informații sunt furnizate de către Utilizator.

Informațiile se vor completa in rubricile din dreapta, conform indicațiilor menționate cu font italic albastru.

Anexa 2: Proces verbal de ședința

PROCES VERBAL DE SEDINTA

General

Participanți

Discuții

Acțiuni ulterioare

DATA SI ORA URMATOAREI INTALNIRI: ………………

Anexa 3: Raport de activitate servicii de asistenta tehnica si suport

Raport de activitate servicii de asistenta tehnica si suport

Emis de :________________________________________________________________

Receptionat de:___________________________________________________________

Documente referite

Controlul distributiei

Controlul versiunilor

General

Aprobarile documentului

a. Furnizor

b. Beneficiar

Descrierea Activitatilor

Pentru o buna desfasurare a activitatilor de suport au fost monitorizate urmatoarele canale de comunicare:

– Aplicatia de ticketing

– Grupul de suport:………, in situatia in care Aplicatia de ticketing nu a putut fi accesata.

– Numarul de telefon: ……., in situatia in care clientul nu a avut conexiune internet.

Activitatile de suport desfasurate au fost centralizate in Aplicatia de ticketing – Aplicatia de gestiune a sesizarilor.

Observatii si recomandari

Beneficiar

Furnizor

Statistici privind activitatea de suport

Pe parcursul perioadei analizate in raport s-au inregistrat… solicitari, dintre care… au fost rezolvate iar …..se afla inca in curs de rezolvare.

5.1 Situatie incidente in functie de campul Incadrare

In perioada analizata in prezentul raport, situatia incidentelor in functie de incadrare este urmatoarea:

<<Grafic>>

5.2 Situatie incidente in functie de campul Modul

In perioada analizata in prezentul raport, situatia incidentelor in functie de modulul aplicatiei este urmatoarea:

<<Grafic>>

5.3 Situatie incidente in functie de campul Prioritate

In perioada analizata in prezentul raport, situatia incidentelor in functie de prioritate este urmatoarea:

<<Grafic>>

5.4 Situatie incidente in functie de campul Stare

In perioada analizata in prezentul raport, situatia incidentelor in functie de stare este urmatoarea:

<<Grafic>>

Lista sesizari, rezumat, status

In tabelul de mai jos este prezentata lista de sesizari inregistrate in perioada…….impreuna cu principalele informatii asociate:

Numarul unic de inregistrare

Modulul la care se refera sesizarea

Rezumatul sesizarii

Clasificarea sesizarii

Prioritatea/Severitatea sesizarii

Starea sesizarii

Cine a semnalat sesizarea/Apelant

Data cand a fost creata sesizarea

Cine a rezolvat sesizarea

Data rezolvarii sesizarii

Ghid utilizare aplicatie

SUPORT TEHNIC ONLINE

(WTS)

Descriere si functionalitati aplicatie WTS

Aplicatia Suport Tehnic On-line (WTS) este o aplicatie web fiabila, usor de utilizat si cu o interfata foarte intuitiva. Aplicatia este un mijloc de comunicare rapida si eficienta intre toate rolurile implicate in procesul de evidenta a solicitarilor de suport, un mijloc de publicare a informatiilor asociate fiecarei cereri de suport si a actiunilor efectuate pentru rezolvarea respectivei cereri.

Aplicatia WTS este conceputa pentru a gestiona toate cererile de suport adresate de catre utilizatori departamentului de suport si implicit, eventualele probleme/defecte, aparute in utilizarea unui produs sau a unei aplicatii. Solicitarile de suport sunt înregistrate în aplicație sub formă de tichete care conțin descrierea situatiei identificate.

Fig.1

Aplicatia Suport Tehnic On-line tine evidenta stricta a solicitarilor de suport, problemelor sau cererilor de schimbare aflate in diferite stari ale ciclului de viata (“Creat”, ”In curs de rezolvare”, “Rezolvat, etc.) si la informatiile generale cu privire la solutiile identificate, permitand utilizatorului urmărirea tichetelor din momentul deschiderii si până la închiderea acestora.

Datorita faptului ca este o aplicatie web, pentru accesarea si utilizarea acesteia nu sunt necesare instalari de componente hardware sau software, aplicatia fiind accesibila, pe baza de user si parola, tuturor utilizatorilor autorizati sa formuleze cereri de suport.

Pentru accesul in aplicatie sunt definite mai multe roluri (Fig. 2), fiecare rol avand drepturi diferite:

Utilizator – formuleaza si inregistreaza in aplicatie solicitarile de suport

Specialist de suport – preia si gestioneaza solicitarile de suport transmise de utilizatori

Manager de suport – analizeaza stadiul cererilor de suport si pe baza acestuia ia decizii de management

Administrator – configureaza si administreaza aplicatia

WTS permite definirea cozilor asociate diferitelor produse, toate cererile de suport transmise de-a lungul timpului de catre un anumit utilizator, pe un anumit produs fiind extrem de accesibile.

Aplicatia este intuitiva si usor de utilizat, deoarece actiunile executate de catre utilizator sunt simple, iar informatiile ce este necesar sa se completeze pentru fiecare cerere de suport introdusa sunt uzuale si intuitive (Titlu, Descriere, Severitate, Clasificare, etc.).

Web Technical Suport permite inregistrarea tuturor solicitarilor de suport si alocarea unui identificator unic fiecarei solicitari. La introducerea in aplicatie, fiecarei cereri de suport i se asocieaza automat un numar unic de inregistrare, ce permite gasirea foarte usoara a acesteia in sistem si gestionarea corecta a tuturor sesizarilor.

Orice cerere de suport introdusa in aplicatie poate fi cautata (fig.3) foarte rapid prin utilizarea diverselor filtre existente: Titlu , Numar, Stare, Data crearii, precum si a unor filtre complexe, create dinamic de catre utilizator.

De asemenea, aplicatia de ticketing WTS ofera posibilitatea de definire a unor categorii de apeluri de asistenta, precum si posibilitatea de definire si de incadrare a solicitarilor in categorii: eroare aplicatie, solicitare de informatii, cerere de schimbare etc.

Aplicatia permite inregistrarea datelor de identificare ale apelantului (persoana care a transmis solicitarea de suport), implicit atribuirea tichetului unui specialist de suport (persoana care verifica si rezolva solicitarea). In plus, toate detaliile referitoare la persoanele implicate in ciclul de viata al unei probleme pot fi foarte usor identificate doar prin deschiderea respectivei probleme.

Datele introduse se refera atat la date personale cat si la date de contact: telefon, email, judet, unitate administrativa, etc. (fig.4).

Fig.4

Suplimentar, aplicatia cuprinde baza de date cu personalul de suport caruia i se pot aloca spre rezolvare solicitarile, contine toate datele de contact si implicit persoanele, care pot fi considerate alocabile sau care pot aloca un tichet. Aceste date pot fi folosite in mod facil in cazul unui audit. De asemenea, WTS ofera posibilitatea de inregistrare a datelor de contact pentru responsabilii pentru activitatile de suport de nivel 1, 2 si 3 pentru diferitele componente ale sistemului informatic.

Este de asemenea foarte accesibila vizualizarea si gestionarea tuturor informatiilor referitoare la o cerere de suport intr-un singur loc, astfel incat dupa gasirea in aplicatie a unei cereri de suport se pot vizualiza toate detaliile sale: descriere, clasificare, persoana responsabila, persoana care a receptionat cererea, starea, data receptionarii, fisiere atasate, etc. Pentru fiecare cerere de suport se pot efectua mai multe activitati, iar informatiile despre acestea sunt atasate cererii de suport, detaliile asociate putand fi vizualizate in istoricul cererii.

WTS permite vizualizarea in orice moment a stadiului fiecarei cereri de suport. Pentru o intelegere cat mai buna a solicitarii de suport, aplicatia permite pe langa descrierea solicitarii si atasarea de documente suplimentare, ce descriu mesajele de avertizare, scenariile utilizate, capturile de ecrane, etc.. (fig.5)

Fig.5

La introducerea in aplicatia Suport Tehnic On-line a unei cereri de suport, data si ora primirii respectivei solicitari de asistenta este inregistrata automat in aplicatie. In plus, pentru fiecare solicitare inregistrata, aplicatia permite verificarea in timp real a actiunilor intreprinse si a istoricului acesteia.(fig.6)

Fig.6

Aplicatia permite alocarea unui criteriu de urgenta (severitatea solicitarii de suport) pe baza impactului si urgentei acesteia. In aplicatia se pot configura diferite grade de prioritate, in concordanta cu cele stabilite: severitate mica, medie, mare, blocanta. Nivelul de severitate asociat unei solicitari determina timpul de raspuns si timpul de rezolvare al acesteia (SLA-ul), conform contractului. Momentul (data si ora) corespunzator fiecarei schimbari de stare a sesizarii este inregistrat automat in istoricul tichetului astfel, timpii de raspuns si de rezolvare sunt calculati foarte usor. Datorita acestor functionalitati, se pot defini clar criteriile de calitate si performanta (SLA) pentru rezolvarea diferitelor categorii de solicitari de asistenta.

Solicitaril de suport introduse in aplicatie urmeaza un proces de suport stabilit, starea cererii schimbandu-se in functie de actiunile efectuate si de responsabilul curent. Astfel, o cerere de suport urmeaza o serie de stari in ciclul ei de viata: “Creat”, “Receptionat”, “In Curs de rezolvare”, “Rezolvat”, “Inchis”, asa cum sunt definite in cele ce urmeaza:

– Creat – status aferent introducerii solicitării în aplicația de gestiune și salvării datelor adăugate.

– Recepționat – status aferent recepționării solicitatii de suport de catre specialistul de suport;

– În curs de rezolvare – status aferent preluarii spre verificare si analizare a solicitarii. Acest status poate fi modificat doar de către specialistii de suport;

– In asteptare informatii client – status aferent cererii utilizatorului care a transmis solicitarea a unor informatii suplimentare, absolut necesare pentru solutionare problemei

– Problemă rezolvată – status aferent unei solicitari de suport rezolvate. Acest status poate fi modificat doar de către specialistii de suport;

Închis – statusul aferent unei solicitari de suport închise și arhivate.

In timpul unui ciclu de viata, o cerere de suport poate sa urmeze un flux de escaladare (pe nivele functionale de suport) iar responsabilul de rezolvare sa fie schimbat in functie de complexitatea solicitarii, de domeniul de expertiza, sau de severitatea cererii de suport. In cazul in care rezolvarea solicitarii depaseste competentele specialistului de suport, aplicatia permite escaladarea acesteia catre nivelele superioare de suport si urmarirea facila a rezolvarii ei. In situatia in care, pe parcursul rezolvarii apar dificultati in flux (se apropie termene limita de SLA, nivelele superioare nu colaboreaza suficient de rapid, nu sosesc informatii utile de la utilizator, utilizatorul doreste sa escaladeze, etc.) aplicatia ofera posibilitatea de escaladare catre management in vederea efectuarii actiunilor necesare.

O functionalitate importanta a WTS este cea de notificare pe email atunci cand s-au efectuat schimbari asupra unei cereri de suport. Astfel, pentru a cunoaste statusul unei cererei de suport, aceasta poate fi vizualizat oricand in aplicatie, dar poate fi urmarit si pe email.

Totodata, aplicatia ofera posibilitatea de alocare a unor coduri de solicitare care sa indice cauza probabila a situatiei identificate si gruparea pe module a solicitarilor. In situatia in care, la inchiderea unei solicitari, codul alocat acesteia nu se considera a fi in concordanta cu cel setat initial, aplicatia permite modificarea acestui cod.

Sunt de asemenea puse la dispozitia utilizatorilor cu drepturi necesare, rapoarte de activitate in functie de tipul de solicitare, nivelul de urgenta, timpul de rezolvare, modulul sau produsul pentru care a fost identificata situatia etc.

Logare in aplicatie

Pentru logarea in aplicatia WTS este necesara o conexiune la Internet.

Se recomanda ca pentru accesarea aplicatiei sa se utilizeze blowser-ul Internet Explorer, in fereastra de autentificare introducandu-se datele de conectare:

– "User name": reprezinta numele de utilizator cu ajutorul caruia se realizeaza logarea in aplicatie

– "Password": reprezinta parola aferenta numelui de utilizator introdus anterior

Nota: User-ul si parola sunt furnizate de Furnizor, la solicitarea clientului.

Flux de desfasurare a procesului de gestiune solicitari de suport

Fluxul de gestiune si rezolvare a unei solicitari de suport incepe din momentul transmiterii de catre utilizator a unei cereri de suport si se deruleaza astfel:

Inregistrarea solicitarii de suport

In vederea adaugarii unei solicitari in aplicatie este necesar sa se acceseze tab-ul “Adaugare problema” din meniul principal sau se apese butonul “Nou” din tab-ul “Lista probleme”. In fereastra nou aparuta (“Inregistrare problema”) se vor completa urmatoarele campuri:

Nume = rezumatul solicitarii (descrierea pe scurt a situatiei identificate de utilizator).

Produs = produsul/aplicatia din cadrul sistemul informatic, pentru care se introduce solicitarea de suport. Prin apasarea butonului din dreapta acestui camp se deschide lista cu produsele/aplicatiile inregistrate si se selecteaza un produs/aplicatia pentru care se introduce solicitarea (Fig. 7)

Fig. 7

Versiune produs = versiunea produsului, pentru care este solicitata asistenta tehnica. Prin apasarea butonului din dreapta acestui camp se deschide lista cu versiunile pentru produsul/aplicatia selectata din care se selecteaza o versiune

Modulul aplicatiei = modulul aplicatiei la care face referire solicitarea. Prin apasarea butonului din dreapta acestui camp se deschide lista cu modulele care formeaza aplicatia si se selecteaza modulul aferent solicitarii.

Prioritate = severitatea situatiei identificate (solicitarii de suport), in conformitate cu specificatiile aferente proiectului si agreate cu utilizatorul.

Suport = persoana din echipa suport care a preluat solicitarea

Nota: Acest camp va fi completat de catre specialistul de suport, la receptionarea solicitarii.

Alege Apelant = numele si prenumele persoanei care a transmis solicitarea de suport. Apelantul se va selecta din lista de lista de apelanti autorizati agreata cu clientul si adaugata in aplicatie

Descriere = descrierea detaliata a situatiei identificate. Campul in care se vor introduce cat mai multe detalii privind solicitarea semnalata: situatia identificata,eroarea intalnita, ecranul in care s-a generat eroarea, numarul de utilizatori afectati,

Categorie = categoria in care este incadrat tichetul: solicitare de suport, incident, problema, cerere de schimbare

Data stare = se completeaza automat de catre sistem cu data si ora introducerii sesizarii in WTS

Incadrare = incadrarea aferenta solicitarii introduse: acces aplicatie, modificari in aplicatie, utilizare aplicatie, operare eronata, eroare aplicatie, solicitare informatii/servicii, indisponibilitate aplicatie, intretinere si mentenanta echipamente, intretinere si mentenanta software, monitorizare

Nota: Se recomanda completarea tuturor campurilor astfel incat descrierea solicitarii sa fie completa iar rezolvarea acesteia sa se poata efectua cat mai repede.

Nota: Toate campurile semnalate prin steluta rosie reprezinta campuri obligatori,i fara de care nu se poate salva tichetul introdus

Dupa completarea campurile mentionate mai sus, pentru salvarea inregistrarii, se apasa butonul Salveaza aflat in coltul din stanga sus al template-ului de solicitare. In momentul salvarii, aplicatia va aloca solicitarii de suport, in mod automat, un numar unic de inregistrare (ce va fi afisat in campul “Numar”) va completa automat campul stare cu statusul “Creat”. (fig.8)

Fig. 8

De asemenea, o data cu inregistrarea si salvarea sesizarii in aplicatie, se vor activa urmatoarele butoane: “Adauga fisier”, “Vizualizeaza fisiere” si “Raport de problema”. Pentru a salva fisierele asociate se apasa butonul "Salveaza si inchide"

In cazul in care solicitarea de suport este insotita de fisiere/documente atasate acestea vor fi adaugate in WTS cu ajutorul butoanelor “Adauga fisier (sau “Add files”, pentru adaugarea mai multor fisiere). Documentele atasate pot fi vizualizate ulterior, prin intermediul butonului ”Vizualizeaza fisiere”.

Receptionarea solicitarii de suport

Pentru a se marca sesizarea in status Receptionat se completeaza campul “Data Stare” cu data urmatoarei stari si se alege din lista de stari, statusul Receptionat.

In cazul in care se doreste modificarea datei starii Receptionat, in campul “Data stare” se va completa noua data si se va salva modificarea efectuata(prin apasarea butonului Salveaza din template-ul de sesizare).

Pentru a se marca sesizarea in status Receptionat se completeaza campul “Data Stare” cu data urmatoarei stari si se alege din lista de stari, statusul Receptionat.

In cazul in care se doreste modificarea datei starii Receptionat, in campul “Data stare” se va completa noua data si se va salva modificarea efectuata(prin apasarea butonului Salveaza din template-ul de sesizare).

Pentru a se marca sesizarea in status Receptionat se completeaza campul “Data Stare” cu data urmatoarei stari si se alege din lista de stari, statusul Receptionat.

In cazul in care se doreste modificarea datei starii Receptionat, in campul “Data stare” se va completa noua data si se va salva modificarea efectuata(prin apasarea butonului Salveaza din template-ul de sesizare).

Pentru a se marca sesizarea in status Receptionat se completeaza campul “Data Stare” cu data urmatoarei stari si se alege din lista de stari, statusul Receptionat.

In cazul in care se doreste modificarea datei starii Receptionat, in campul “Data stare” se va completa noua data si se va salva modificarea efectuata(prin apasarea butonului Salveaza din template-ul de sesizare).

Actiunea de receptionare a solicitarii este realizata de catre specialistul de suport si presupune transmiterea mail-ului de confirmare a preluarii solicitarii si schimbarea statusul tichetului in ”Receptionat”. Mail-ul de confirmare primire (mail-ul de receptie a solicitarii) se transmite catre utilizatorul care a semnalat situatia (apelant) si contine numarul unic de inregistrare al acesteia si prioritatea alocata.

Dupa ce starea solicitarii a fost modificata in “Receptionat”, in template-ul de solicitare, pot fi vizualizate tab-urile: Discutii, Actiuni Client, Actiuni Suport si Istoric solicitare.

Verificarea si rezolvarea solicitarii de suport

Demararea verificarilor si a actiunilor de rezolvare a solicitarii este marcata in aplicatie prin modificarea starii in “In curs de rezolvare” si apasarea butonului Salveaza.

Fig. 9

Dupa ce solicitarea a fost luata in lucru, fluxul de rezolvare al acesteia poate fi urmatorul:

a) transmiterea, catre utilizator, a rezolvarii solicitarii si marcarea acesteia in “Problema rezolvata”. Dupa transmiterea rezolvarii catre utilizator, acesta poate confirma sau infirma solutionarea.

– in situatia in care utilizatorul aproba rezolvarea (transmite notificare de confirmare), specialistul de suport inchide si arhiveaza solicitarea, marcand-o cu statusul “Inchis”.

– in situatia in care utilizatorul nu confirma rezolvarea solicitarii, specialistul de suport redeschide tichetul si reia procesul de verificare a solicitarii.

Lipsa primirii, in termen de 5 zile lucratoare, a unui raspuns in ceea ce priveste confirmarea sau infirmarea rezolvarii, determina inchiderea automata a tichetului. In cazul in care utilizatorul revine dupa termenul de 5 zile, specialistul va deschide un alt tichet pentru tratarea situatiei in cauza.

b) cererea, de la utilizator, a unor detalii suplimentare, necesare continuarii verificarilor si rezolvarii situatiei semnalate si marcarea tichetului in status “In asteptare informatii client”. Lipsa primirii, in termen de 5 zile lucratoare, a informatiilor suplimentare solicitate (fara de care verificarea solicitarii nu poate continua) determina de asemenea inchiderea automata a tichetului. In cazul in care utilizatorul revine cu detaliile solicitate dupa termenul de 5 zile, specialistul va deschide un alt tichet pentru tratarea situatiei in cauza.

Urmarirea solicitarilor de suport

Verificarea si urmarirea solicitarilor de suport se poate realiza prin introducerea in campul de cautare (pozitionat in coltul dreapta jos al aplicatiei) a criteriului pe baza caruia se face cautarea (fig.15).

Fig.10

Dupa introducerea filtrului de cautare, aplicatia va afisa doar solicitarile de suport care indeplinesc criteriile de cautare.

Procedura interna de utilizare a aplicatiei Ticketing – WTS

1. Descriere si functionalitati aplicatie WTS

Aplicatia Suport Tehnic On-line (WTS) este o aplicatie web fiabila, usor de utilizat si cu o interfata foarte intuitiva. Aplicatia este un mijloc de comunicare rapida si eficienta intre toate rolurile implicate in procesul de evidenta a solicitarilor de suport, un mijloc de publicare a informatiilor asociate fiecarei cereri de suport si a actiunilor efectuate pentru rezolvarea respectivei cereri.

2. Logare in aplicatie

– Pentru logarea in aplicatia WTS este necesara o conexiune la Internet, (Se recomanda ca pentru accesarea aplicatiei sa se utilizeze bowser-ul Internet Explorer).

– Din meniul Internet Explorer se acceseaza:

tools\settings\compatibility views

– se adauga adresa (195.216.218.11:8080) la compatibility view settings

– se selecteaza cele 2 optiuni din partea de jos a ferestrei

– se acceseaza adresa 195.218.218.11:8080

se introduce username : intranet\username si password

Ridicarea unui ticket, (Adaugare problema) in WTS

Din meniul principal se selecteaza Adaugare problema

La campul Nume se introduce o scurta descriere a ticketului (problemei).

-La campul Produs se incadreaza ticketul in functie de problema, selectand una din cele doua optiuni:

a) Infrastructura hardware

b) infrastructura software

Se seteaza prioritatea ticketului din campul Prioritate, astfel:

Prioritate 1 – prioritate maxima

Prioritate 4 – prioritate minima

Din campul Suport se selecteaza utilizatorul current (cel care inregistreaza cererea de suport) si se da click pe OK.

Din campul Alege appelant se selecteaza utilizatorul current(cel care inregistreaza cererea de suport) si se da click pe OK.

La campul Descriere, se introduce un text care sa cuprinda o descriere cat mai exacta a incidentului, precum si alte detalii legate acesta si se da click pe OK.

La campul Categorie se incadreaza cererea de support selectand una din cele 4 optiuni, dupa care se da click pe OK.

Cerere de schimbare

Problema

Incident

Solicitare support

La campul Incadrare, se asociaza cererea de suport cu tipul de problema din meniu, alegand una din urmatoarele optiuni, dupa care se da click pe OK.

Monitorizare

Intretinere si mentenanta software

Intretinere si mentenanta echipamente

Indisponibilitate aplicatie

Solicitare informatii/servicii

Eroare aplicatie

Operare eronata

Utilizare aplicatie

Modificari in aplicatie

Acces aplicatie

La final se salveza solicitarea de suport (ticketul) apasand tasta F2 sau dand click pe casuta salveaza.

Se acceseaza campul Lista probleme, ticketului asignandui se in mod automat un numar de inregistrare.

In partea dreapta a numarului de inregistrare a ticketului, regasim mai multe detalii ale acestuia.

Adaugarea de fisiere ( capturi de ecran sau poze care sa ajute la identificarea mai usoara a problemei) :

Se da dublu click pe campul cu numarul de inregistrare a ticketului, dupa care se da da click pe casutal Add files ( se pot adauga maxim 3 fisiere de tipul – gif, jpg, jpeg, png).

Fisierele se incarca dand click pe casuta Browse dupa care se da click pe OK.

Fisierele incarcate se pot vizualiza dand click pe casuta Vizualizeaza fisierele.

Dupa ce ticketul a fost ridicat , se va primi un e-mail din partea echipei de suport, care confirma preluarea ticketului de catre team-support.

Evolutia ticketului se poate urmari dand click pe casuta Discutii.

Aici regasim mai multe detalii legate de ticket ( data si ora inregistrarii ticketului, numele persoanei care a preluat ticketul etc)

Tot din casuta Discutii se pot adauga ulterior alte informatii dand click pe casuta Adauga discutie, menite sa faciliteze rezolvarea ticketului intr un interval de timp cat mai scurt.

Dupa adaugarea discutiei se da click pe casuta Salveaza si inchide.