by Dacă navigăm pe internet căutând dupa sintaxa “suport tehnic wikipedia” găsim o mulţime foarte “colorată” de răspunsuri: suport tehnic, mentenanţă şi suport tehnic, întreţinere şi suport tehnic etc. Acest articol are legătură directă cu derularea contractelor după obţinerea acceptanţei finale şi declanşarea perioadelor de garanţie (şi post-garanţie) şi suport. Concret materialul ţinteşte către “binele” din perioada de implementare care începe acum să îşi arate roadele.
Dar, să o luăm cu începutul si să definesc inainte de toate conventiile pentru 2 notiuni la care voi face referire:
-
ce este un „false event” – un eveniment (tichet) declanşat de utilizatorul final al unei soluţii/funcţionalităţi/facilităţi şi care nu se confirmă/simulează la echipa de suport tehnic; acest eveniment are la bază necunoaşterea facilităţii/funcţionalităţii pentru care se declanşează evenimentul, cunoaşterea insuficientă a acestor facilităţi/funcţionalităţi sau cunoaşterea parţială, eronată.
-
ce este “acceptanta finala” – este faza şi setul de documente care atestă acceptarea calitativă şi cantitativă a obligaţiilor asumate prin obiectul şi scopul contractului – finalizarea contractului de implementare.
Exemplu: proiectul nostru – “Proiect de implementare soluţie ERP”.
Acest proiect a avut o perioadă de derulare care a inclus si livrarea unui set de servicii şi care ar fi trebuit, indiferent de obiectul proiectului nostru să cuprindă documentaţii: de analiză, de utilizare, de parametri, de training, de configurare, de instalare, de rapoarte, de testare, “matricea de roluri şi responsabilităţi”, “fluxuri de lucru”, etc.
Ma voi opri mai jos la “matricea de roluri şi responsabilităţi” şi “fluxurile de lucru” deoarece aceste tipuri de documente sunt cele care pot face utilizarea soluţiei implementate să fie facilă pentru utilizatorii finali şi apoi în perioada de după acceptanţa finală pot face ca modul de colaborare a acestora cu echipa de suport tehnic să fie una agreabilă.
De ce?
-
“Fluxuri de lucru”
Deoarece lipsa acestui tip de documentatie este “cuiul lui Pepelea” al zilelor noastre, calitatea şi consistenţa acestora făcând uşor diferenţa de la uşor şi practic la greu şi incoerent:
-
utilizatorul final, care la rândul său este supus dinamicii de personal, poate facil utiliza această documentaţie în procesul de autoinstruire şi preluare “din mers” a utilizării sistemului (în cazul fericit al existenţei acestui material, în formă şi calitate bună) sau
-
utilizatorul final poate resimţi profund lipsa acestei documentaţii şi astfel poate să declanseze “re-implementarea” prin transmiterea către echipa de suport tehnic a “unui tir permanent” de “false events”.
Acestea sunt momentele când se declanşează tirul de “justificări” dinspre client spre furnizor şi echipa de suport, dinspre echipa de suport către echipa client (cu răspunsuri de toate felurile) şi dinspre echipa de suport către echipa de implementare proprie:
-
utilizatorul final argumentează că la training nu i s-au prezentat toate functionalităţile, că nu a primit deloc sau a primit insuficientă informaţie (fluxuri de lucru de slabă calitate), etc. – toate acestea dupa faza de acceptanţă a proiectului;
-
responsabilul de suport tehnic care solicita către echipa client tot felul de informaţii ajutatoare (de clarificare) care să îi permită înţelegerea “problemelor” care iniţial îi par de neînţeles;
-
responsabilul de suport tehnic care solicită catre echipa de implementare proprie fluxurile de lucru (dacă acestea există) sau îi adresează întrebari de clarificare (în situaţia în care nu au fost realizate aceste fluxuri de lucru sau dacă acestea nu sunt actualizate cu ultimele informaţii din soluţia implementată).
Astfel trecerea in garantie (post-garantie) si suport tehnic este momentul care face ca tensiunile să se nască (dacă nu au fost pana atunci), iar daca au fost şi în proiect să se acutizeze.
2. “Matricea de roluri si responsabilitati”
-
este un document simplu cu putere magică, care tratează împărţirea pe module, funcţii, funcţionalităţi, operaţii a soluţiilor implementate;
-
este baza configurării în sistemul implementat a regulilor de acces şi usabilitate (roluri) – acest document ţinteşte granula funcţională descrisă în “fluxurile de lucru”.
Şi atunci daca este aşa de bun şi necesar care este hiba acestui document? Nici una practică, una majoră operaţional: lipsa lui.
Din comoditate acest document nu se realizează, ceea ce va conduce la generarea de roluri în sistemul implementat după reguli de moment şi apoi realizarea eronat de fluxuri de lucru la acel nivel.
Ce se întâmplă peste timp?
Aşa cum menţionam, dinamica de personal afecteaza echipa client astfel incat utilizatorii iniţiali (se schimbă, primesc responsabilităţi noi în activitatea curentă şi implicit în sistemul implementat) şi apoi ajung în situaţia nedorită în care trebuie să utilizeze sistemul şi ceea ce au ca pornire şi bază (fluxurile de lucru) nu sunt ceea ce au nevoie: este momentul în care utilizatorul crede că sistemul nu îi aduce plus valoare (nu îl ajutî).
Ce este de făcut?
-
Nu lăsaţi matricea de roluri şi reponsabilităţi doar ca un material bun de făcut şi atât – realizaţi-l şi completaţi-l cu informaţii, prezentaţi-l şi agreaţi-l cu echipa client – peste timp se va dovedi de mare valoare şi va ajuta la tranşarea corectă a disfunctionalităţilor de cererile de modificare (“false events”-urile utilizatorilor);
-
Realizaţi fluxuri de lucru de mare calitate şi conţinut – acestea vor aduce plus valoare atât echipei client cât şi echipelor proprii (implementare, dezvoltare, suport tehnic) – principiul conform căruia “nu documentez deoarece este mai ieftin şi oricum ţin minte căci este uşor” este eronat;
-
Validaţi şi acceptaţi aceste documente cu echipa client – peste timp. In momentele “nu am primit”, “nu ni s-a explicat”, “nu am ştiut”, se vor dovedi a avea o valoare inestimabilă – cu puţin efort vor ajuta la transformarea “false events” în cereri de modificare şi vor ajuta echipele (client, furnizor) să înţeleagă soluţiile implementate şi astfel vor putea ajunge să comunice şi să colaboreze eficient utilizînd limbajul sistemului implementat.
