Cred că sînt mai bine de trei ani de cînd, documentîndu-mă pentru un articol legat de managementul riscurilor, am început să citesc mai mult despre creier, psihologie cognitivă şi alte lucruri ce par a nu avea legătură directă cu domeniile mele de interes. Am spus “par”. Am descoperit însă, cu plăcere, că multe lucruri din…
(Această postare este un preambul la prezentarea ce o voi ţine la evenimentul organizat de PRMIA la Bucureşti în 11 noiembrie.) Constrîngeri? Au existat în trecut, există în prezent şi vor exista cu certitudine şi în viitor……Doar că în multe modele sînt omise. Despre auditul sistemelor informaţionale am spus că implică altceva decît completarea unor check listuri: înţelegerea riscurilor la care se supune organizaţia şi oferirea unor recomandări reale, deci cu valoare. Cam la fel şi cu managementul riscurilor: nu înseamnă preluarea unui model şi completarea unor template-uri….. Impactul şi frecvenţa sînt două variabile statistice aflate în legătură directă cu informaţiile din trecut. Probabilităţile se vor modifica în urma aplicării unor controale, doar în cazul în care acele controale sînt de tip preventiv. În cazul controalelor detective şi corective, probilitatea nu se modifică! În cazul riscurilor securităţii, impactul va fi evaluat asupra activului în sine…
Majoritatea metodologiilor de evaluare a riscurilor prezintă două dimensiuni ale subiectului: probabilitatea şi severitatea/impactul: În alte lucrări, imaginea de mai sus arată altfel: Aţi observat că sînt inversate axele? Am scris, de mai multe ori, că teoria riscurilor are la bază probabilităţi iar probabilităţile se bazează pe teoria numerelor mari. Altfel spus, atunci cînd dorim o modificare asupra viitorului, schimbarea trebuie realizată în prezent, pe baza unor informaţii cît mai corecte şi complete despre trecut. Am scris/spus, la fel de des, că în lipsa unor astfel de informaţii, managementul riscurilor este irelevant. Este făcut de dragul de a fi făcut sau pentru că e o cerinţă de conformitate. Recunosc că e puţin forţată afirmaţia anterioară. Ceva, ceva tot se obţine. Ce lipseşte din primul meu grafic şi din cel de la ITGI? Cea de a treia dimensiune care apare în ultima…
Un răspuns simplu ar fi să trimit cititorul către http://www.porcisme.ro ca să vedem costurile. Despre rezultate nu ştiu ce referinţe să dau. Mă întreb, retoric fireşte, ce se poate descoperi dacă s-ar audita toate proiectele de investiţii publice în IT din ultimii 10 ani. E posibil ca suma să fie impresionantă. Căzînd în păcatul “analiştilor” Tv mă hazardez să spun că majoritatea proiectelor publice suferă de aceleaşi simptome: lipsa unor obiective clare, reale şi care să pornesacă în primul rînd de la integrare; lipsa justificării soluţiei aleasă pentru implementare; lipsa unor rezultate bine definite; lipsa unor indicatori de măsurare a perfomanţei proiectelor; contracte suplimentate financiar; nici o vorbă despre managementul riscurilor în proiect. “Stakeholders”? Mă uitam mai deunăzi la organigrama Ministerului de Finanţe şi am observat că există o DIRECTIE GENERALA A TEHNOLOGIEI INFORMATIEI. Şi aici descopăr că este şi un Compartiment pentru strategie şi cooperare instituţională. Ştiu că şi la…
În postul anterior aminteam despre practicile generale de control ce pot fi trecute prea uşor cu vederea. Ghidul ce dă titlul acestui post vine cu detalii însă. Practicile de control sînt prezentate ca acţiuni ce trebuie implementate: ce, de ce şi cum trebuie implementat fiecare obiectiv al controlului în relaţiei cu riscurile identificate. Am mai scris printr-un alt post că în COBIT, proiectarea şi implementarea controalelor reprezintă responsabilitatea IT (domeniul Achiziţie şi Implementare) cu excepţia celor de la nivelul aplicaţiilor. În acest caz intervine responsabilul de proces economic! El este cel care trebuie să identifice cerinţele funcţionale şi de control iar IT-ul le pune în practică. O ultimă menţiune: practicile din acest ghid nu sînt prescriptive! Este disponibil ca download…
ADRIAN B. MUNTEANU 