CAPITOLUL1: SISTEM INFORMATIC COMPLEXITATE SI COSTURI

Sistemul informatic are menirea de a acoperi toate problemele agentului economic, de a

crea interdependente ntre componente, astfel nct structurii fizice din sistemul atasat agentului
economic sa se suprapuna cu o structura n plan informational. Fluxurilor de productie le
corespund fluxuri informatice. Actorilor implicati n procese li se asociaza emitatori si receptori
de informatii cu niveluri diferite de prelucrare. Dezvoltarea directa de sisteme informatice se
dovedeste o ntreprindere riscanta daca nu este precedata de activitati care au menirea de a
impune o echipa, o tehnologie unitara de analiza, design, dezvoltare, implementare, exploatare si
mentenanta, aspecte care trebuie luate n considerare la efectuarea unui audit de sistem
informatic.
Sistemele informatice sunt constructii complexe, realizate pe parcursul mai multor ani,
necesitnd:
- fonduri foarte mari, uriase n anumite cazuri;
- echipe complexe si stabile de analisti, designeri, programatori si personal care se ocupa de
testare, implementare si mentenanta;
- stabilirea obiectivelor;
- definirea unei strategii de dezvoltare, exploatare si mentenanta;
- achizitionarea de echipamente, instrumente necesare realizarii de prelucrari, de conexiuni si
dezvoltarii fluxurilor cu exteriorul;
- calificarea personalului pentru utilizarea corecta si eficienta a sistemului.
Complexitatea sistemelor informatice si durata, relativ mare, de realizare a acestora
genereaza o serie de probleme care trebuie luate n considerare si solutionate astfel nct, n final,
sa se obtina rezultatele scontate.
n primul rnd, pe durata ciclului de dezvoltare a unui sistem informatic au loc schimbari
n echipa manageriala a beneficiarului. n cazul n care o noua echipa manageriala are
o altaviziune asupra indicatorilor agregati pe care si fundamenteaza deciziile, se produc
modificari n specificatii, care atrag modificari ale structurii sistemului informatic.
n al doilea rnd, noile tehnologii informatice care apar impun adaptarea din
mers a echipei de dezvoltare a sistemului informatic. Producndu-se schimbari n abordarea
instrumentelor de asistare, n utilizarea de optiuni. n final, o serie de componente se construiesc
utiliznd noile resurse. Sistemul informatic devine neomogen din punct de vedere al
tehnologiilor de dezvoltare.
n al treilea rnd, dezvoltarea companiei prin achizitionarea de noi echipamente,
reorganizarea fluxului de productie, trecerea la realizarea de noi produse, introducerea
elementelor de management total al calitatii vin sa influenteze calitativ si cantitativ structura si
functiile sistemului informatic. Problema achizitiilor de date capata o alta dimensiune n cazul
utilajelor cu comanda program sau n cazul liniilor de productie robotizate.
n al patrulea rnd, pe durata mai multor ani, nsasi echipa de programatori,
webdesigneri, testeri si implementatori sufera modificari. Diferiti specialisti rentregesc
echipa. Toate aceste fluctuatii se reflecta n sistemul de lucru, n calitatea componentelor sau
stadiilor sistemului informatic.
n al cincilea rnd, mediul economic, legislatia si dinamica proceselor din societatea
informationala conduc la evolutii care trebuie reflectate n sistemul informatic.
Modificarile unor algoritmi de calcul, necesitatea de a utiliza noi coeficienti, aparitia unor
schimburi de informatii ntre companie si institutiile publice ale statului trebuie reflectate, de
asemenea, din mers n sistemul informatic aflat n constructie.
Toate aceste procese se deruleaza concomitent, producnd efecte conjugate, n timp ce
obiectivul stabilit initial, acela de a realiza un sistem informatic pentru managementul companiei,
ramne nemodificat. Sunt situatii n care chiar conditiile privind termenele de predare ramn
neschimbate. n cazul n care noile cerinte conduc la cresterea semnificativa a complexitatii
produsului final - sistemul informatic pentru management - se impune cresterea volumului
investitiei pentru a suplimenta resursele necesare dezvoltarii unui volum mai mare de
activitati. Cresterea volumului de activitati care se deruleaza n paralel impune noi abordari la
nivelul conceptiei sistemului informatic.
Realizarea unui sistem informatic are menirea de a sprijini actul decizional la toate
nivelurile. Sporul de informatie, calitatea acesteia, promptitudinea cu care se obtine sunt
argumente puternice pentru a determina saltul calitativ pe care l presupune societatea bazata pe
cunoastere.
Din aceste considerente, implementarea unui sistem informatic trebuie sa genereze efecte
pozitive att pentru utilizatorii sai, ct mai ales, pentru beneficiarii directi ai informatiei
prelucrate. Pentru a se obtine acest deziderat, n procesul de elaborare este necesara aplicarea
tuturor cerintelor privind managementul calitatii sistemului informatic. De asemenea, este
necesar sa se realizeze auditul sistemului informatic pentru a se obtine garantia ca acesta
realizeaza corect si complet prelucrarile pentru care a fost proiectat, iar orice combinatie de date,
alta dect cea corecta si completa, este semnalata si nu este generatoare de efecte colaterale pe
termen mediu si lung.
n realizarea proceselor de auditare a dezvoltarii Sistemelor Informatice este necesar sa se
ia n considerare caracteristicile organizatiei pentru care se proiecteaza sistemul si, n primul
rnd, stabilitatea organitzatiei. Dezvoltarea Sistemelor Informatice se face n contextul evolutiei
mediului economico-social. Dinamismul schimbarilor n cadrul organizatiilor, indiferent de
dimensiunea acestora, impune adaptarea metodelor de dezvoltare a Sistemelor Informatice la
noile conditii sau aparitia unor concepte si metode noi de dezvoltare a acestora. Organizatiile n
dezvoltare, denumite n limba engleza, organizatii emergente, sunt organizatiile a
caror constanta o constituie ncercarea continua de adaptare la mediile n schimbare, dar care nu
ating niciodata stabilitatea pentru care actioneaza.
Acest tip de organizatii este foarte diferit de cele stabile. Din cauza ipotezelor
fundamental diferite privind realitatea si dezvoltarea SI, procesele de proiectare pentru
organizatii stabile, respectiv emergente, sunt diferite. De fapt obiectivele celor doua procese sunt
contradictorii.
Dezvoltarea SI pentru organizatii stabile are n vedere urmatoarele obiective :
- avantajele economice ale unei analize amanuntite;
- satisfactia utilizatorilor;
- cerinte abstracte;
- specificatii complete si lipsite de ambiguitati.
Obiectivele propuse pentru dezvoltarea SI destinate organizatiilor emergente sunt urmatoarele:
- analiza dinamica;
- negocierea cerintelor dinamice;
- specificatii utile, ambigue si incomplete;
- redezvoltare continua.
Printre metodele utilizate n dezvoltarea SI pentru organizatiile emergente se numara
modelarea conceptuala si evaluarea utilitatii si utilizabilitatii.Modelarea conceptuala la
reproiectarea schimbarilor sistemului si evaluarile utilizabilitatii pot fi vazute ca o forma de
analiza referitor la analiza permanenta care necesita a fi aplicata organizatiilor emergente.
Analizele publicate n literatura de specialitate si unele cercetari ale autorilor demonstreaza ca n
cadrul SI sunt ntotdeauna necesare schimbari, aspecte care se iau n considerare la auditarea SI.

2. REALIZAREA sI MSURAREA CONCORDANEI

O companie, oricare ar fi ea, este o suprapunere de sisteme.
Primul sistem este cel al echipamentelor dispuse ntr-o anumita ordine pentru a dezvolta
operatiile de prelucrare specifice unei tehnologii.
Al doilea sistem este cel al materiilor prime care fac obiectul prelucrarilor prin trecerea
de la un echipament la altul. Asupra lor se executa operatiile de prelucrare, rezultnd
transformari.
Al treilea sistem este acela de comanda a executiei, care include persoane calificate si, ntr-o
masura mai mica sau mai mare, roboti cu grade diferite de flexibilitate n actiune si decizie.
Al patrulea sistem este sistemul energetic care are menirea de a pune n miscare utilajele
si de a crea conditii optime persoanelor pentru a executa operatii.
Al cincilea sistem este sistemul informational. Rolul sau este determinant, ntruct
fluxurile informationale au menirea de a declansa functionarea utilajelor, generarea fluxurilor
materiale, crearea comunicarii dintre persoane. mpreuna cu sistemul energetic controleaza toate
etapele unui ciclu de productie. ntre cele cinci sisteme care alcatuiesc compania trebuie sa existe
oricnd o concordanta perfecta. Primele patru sisteme, n mod obiectiv, sunt realizate si exista
avnd o concordanta reala ntre scop si mijloacele de atingere a scopului. Orice neconcordanta
produce efecte negative si, din acest considerent, din procesul de proiectare sistemele sunt
concepute astfel nct sa se minimizeze neconcordantele.
Sistemul informational este singurul care nu are forma vizibila, care nu are fluxuri
impuse, iar efectele vizibile sunt cele negative, efectele pozitive fiind asociate n mod natural
echipei care dezvolta managementul companiei si n cazul sistemului informational este necesara
existenta unei concordante. n mod firesc, o tehnologie se conecteaza printr-o linie de
echipamente care este nsotita de software pentru sistemul informatic la cheie.
Caracterul local, particular al oricarui sistem informatic este dat de:
- legislatia tarii unde se implementeaza tehnologia;
- structurile documentelor;
- stadiul informatizarii sistemului financiar-bancar;
 - diferentele prin care se dezvolta comunicarea ntre agentii economici, fiecare avnd
sistemul lui informatic original;
- nivelul de dezvoltare a managemetului companiei;
- resursele financiare de care dispune compania pentru a investi n informatica;
- strategia companiei de a acorda informatiei rolul de motor spre progresul ei nsasi.
Sistemul informational trebuie sa fie si el n concordanta cu obiectivul companiei, cu
sistemul echipamentelor, cu sistemul materiilor prime, cu sistemul energetic si, mai ales, cu
sistemul fortei de munca. Neconcordantele dintre sistemul informational si celelalte sisteme
creaza probleme n principal prin neutilizarea resurselor la nivelurile pentru care au fost
proiectate. Acest mod de a realiza concordanta explica de ce aceleasi echipamente, aceleasi
materii prime, aceleasi consumuri energetice, aceleasi persoane au performante diferite, n
functie de context. Conceptul de context include nsasi sistemul informational ca expresie a
cerintelor managementului distribuit pe nivelurile de structurare a companiei.
Dezvoltarea unui mod dinamic de a derula procese si de a fundamenta decizii, depinde de
numerosi factori, dintre care cei care definesc persoanele, calitatile si defectele acestora, au o
pondere nsemnata.
n primul rnd, concordanta dintre sistemul informational si celelalte sisteme, ntre care
exista deja concordanta de natura obiectiva, se realizeaza prin definirea de fluxuri de informatie,
concretizate prin mesaje comensurate direct sau prin documente care urmaresc fluxurile de
productie, specifice echipamentelor si materiilor prime care prin transformari devin repere,
subansambluri si, n final, produse finite.
n al doilea rnd, concordanta se realizeaza prin stabilirea de puncte de preluare a
mesajelor care reflecta activitati efectuate, operatii executate, stadii, stari ale
echipamentelor. Trebuie realizat un echilibru ntre numarul emitatorilor potentiali si capacitatea
de preluare a mesajelor n vederea prelucrarii.
n al treilea rnd trebuie stabilite procedurile de prelucrare a mesajelor. Aceste proceduri
trebuie sa fie complete, n sensul luarii n considerare a tuturor tipologiilor de mesaje care se
constituie ca intrari pentru algoritmii de prelucrare. Procedurile de prelucrare au un nivel de
complexitate deosebit de ridicat, limitnd elementele care introduc riscuri n derularea proceselor
decizionale.
 n al patrulea rnd, concordanta sistemului informational este obtinuta din modul n care
abaterile din procesul tehnologic sunt corectate prin decizii luate rapid. Este vorba de viteza de
reactie pe care o asigura managementul prin canalele informationale.
n al cincilea rnd, concordanta dintre sistemul informational si celelalte
sisteme este dezvoltata odata cu definirea unor modalitati de culegere automata a datelor si prin
utilizarea unor algoritmi bazati pe esantionarea datelor din volume foarte mari de date. Trecerea
de la sistemele n care sunt nregistrate cantitati, valori, durate, la sistemele care preiau momente
de start si de ncheiere a unor activitati sau de definire a starilor, asigura saltul calitativ de la
tratarea calitativa a comportamentului de productie care este compania.
n al saselea rnd, concordanta se asigura eliminnd elementele subiective, dictate de
traditionalismul, de rutina specifica unui mod nvechit de tratare a informatiei, nici ca materie
prima, nici ca produs finit, nici ca purtator de valoare, ci pur si simplu ca mesaj auxiliar, optional
n derularea proceselor, care oricum se deruleaza si fara schimb de mesaje, ci numai prin
schimburi de semne sau numai prin schimburi de simboluri. Abordarea moderna impune o
schimbare profunda la nivelul transferului de mesaje. Mesajul ca orice fel de produs este generat
ntr-un interval de timp, urmeaza o traiectorie precisa si genereaza, la momente de timp date,
actiuni si noi mesaje. Sistemul informational devine o componenta de sine statatoare a companiei
care se defineste prin toate dimensiunile pe care le au toate celelalte sisteme care compun
compania.
n al saptelea rnd, sistemului informational i se asociaza costuri de definire si de
functionare. La rndul sau, prin efectele pe care le genereaza mesajele definite n sistem
genereaza costuri. Diferentele de costuri dau ponderea eficientei circulatiei informatiilor n
companie. Apar situatii n care costul informatiei se stabileste direct, o data cu el se obtine fie
nivelul de profit, fie nivelul pierderilor. Informatia din companie are natura economica asemenea
celorlalte sisteme care prin consumuri genereaza, pe de o parte, cheltuieli si pe de alta parte, prin
modul de valorificare a produselor sau serviciilor, genereaza profit, daca piata recunoaste aceste
rezultate sau pierderi. A privi sistemul informational ntr-o alta abordare, nseamna a crea o
componenta la nivelul companiei care frneaza evolutia acestuia, distrugnd-o.
n al optulea rnd, concordanta sistemului informational este o problema de timp.
Concordanta se dobndeste, se mentine, dar se si pierde cu mare usurinta atunci cnd
apare un decalaj ntre dinamica proceselor de productie si dinamica mesajelor care circula n
companie. Noilor moduri de organizare a productiei trebuie sa le corespunda modalitati adecvate
de culegere, prelucrare si transmitere a informatiei.
Concordanta are un caracter global si include n aceeasi masura si cu aceeasi intensitate
toate cele cinci sisteme ale companiei. Ea este o caracteristica pentru a asigura normalitatea
derularii tuturor proceselor din companie, ncepnd cu planificarea, continund cu
aprovizionarea, productia, desfacerea si ncheind cu reflectarea n plan financiar - contabil a
tuturor transformarilor si transferului, respectiv, cu toate deciziile echipei manageriale. Absenta
concordantei, mai ales n plan informational, creeaza decalaje care presupun luarea de decizii
bazate pe un minus de informatie. n plus, scaderea acuratetei informatiei transforma seturile de
mesaje n mesaje incomplete, cu efecte directe asupra cresterii ponderii deciziilor bazate pe
incertitudine.Devin frecvente situatiile n care decizii de rutina se transforma n decizii luate la
nivelurile superioare ale echipei manageriale, n concordanta cu capacitatea de asumare a
riscurilor generate de incompletitudinea informatiei furnizate de un sistem informational
neconcordant.
Din aceste considerent, auditarea unui sistem informatic dezvoltat pentru o
organizatie va avea n vedere existenta concordantei ntre subsisteme. n final, pentru certificarea
sistemului informatic, trebuie ca nivelurile planificate ale caracteristicilor de calitate sa fie mai
mari sau egale dect nivelurile reale. n activitatea de informatica aplicata trebuie parcurse pe
lnga etapele ciclului de dezvoltare, o serie de activitati care au menirea de a stabili ca produsul
program, baza de date, interfata web sau oricare alte componente, este exact ceea ce trebuie.
Aceste activitati au menirea de a stabili ca exista concordanta ntre ceea ce s-a planificat si
produsul finit existent.
Faptul ca activitatile sunt derulate de persoane apartinnd unor organisme independente,
reprezinta garantia ca rapoartele consemneaza diferentele reale dintre proiect si produs.
Auditarea reprezinta o activitate deosebit de importanta pentru companiile care realizeaza
sisteme informatice, ntruct rezultatele procesului de auditare se constituie n baza pentru
fundamentarea deciziilor pe termen lung privind politicile companiei.
Certificarea echipelor, companiilor, persoanelor, produselor informatice, evidentiaza capacitatea
de a derula procese, tranzactii, capacitate care trebuie sase manifeste ori de cte ori se dezvolta
un produs, prin respectarea standardelor, prin utilizarea tehnicilor, modelelor si instrumentelor
adecvate.
 Toate elementele conduc la obtinerea de produse si servicii de calitate.
Exista o importanta deosebire ntre ceea ce se doreste si ceea ce se efectueaza, se obtine si se
utilizeaza n activitatea economica de zi cu zi.
Garantarea calitatii este un concept de mare importanta, complexitate si dinamica.
Existenta unei marci este fundamentata pe existenta unei conduite, pe definirea de proceduri
restrictive, calificarea continua a persoanelor pe existenta unui management suficient al calitatii
si pe formarea constiintei orientate spre calitate.
Indiferent de contextul n care o companie ce dezvolta sisteme informatice si desfasoara
activitatea, societatea informationala, n stadiul aratat, impune ca dezvoltarea de sisteme
informatice sa genereze un efect de antrenare multipla, n directia pozitiva, a evolutiei gradului
de satisfactie nregistrat de utilizatorul final.

3. OBIECTUL AUDITULUI PENTRU SISTEME INFORMATICE

Auditul sistemelor informatice reprezinta activitatea de colectare si evaluare a unor probe
pentru a determina daca sistemul informatic este securizat, mentine integritatea datelor prelucrate
si stocate, permite atingerea obiectivelor strategice ale ntreprinderii si utilizeaza eficient
resursele informationale.
n cadrul unei misiuni de audit a sistemului informatic cele mai frecvente operatii sunt
verificarile, evaluarile si testarile mijloacelor informationale, astfel:
- identificarea si evaluarea riscurilor din sistem;
- evaluarea si testarea controlului din sistem;
- verificarea si evaluarea fizica a mediului informational;
- verificarea si evaluarea administrarii sistemului informatic;
- verificarea si evaluarea aplicatilor informatice;
- verificarea si evaluarea securitatii retelelor de calculatoare;
- verificarea si evaluarea planurilor si procedurilor de recuperare n caz de dezastre si
continuare a activitatii;
- testarea integritatii datelor.
Auditul informatic reprezinta o forma esentiala prin care se verifica daca un SI si atinge
obiectivul pentru care a fost elaborat. Standardele definesc clar domeniul, activitatile, etapele,
continutul auditarii si formele de finalizare. Respectnd cerintele standardelor, rezultatul
procesului de auditare informatica este eliberat de riscurile contestarii. Auditul informatic
reprezinta un domeniu cuprinzator n care sunt incluse toate activitatile de auditare pentru :
specificatii, proiecte, software, baze de date, procesele specifice ciclului de viata ale unui
program, ale unei aplicatii informatice, ale unui sistem informatic pentru management si ale unui
portal de maxima complexitate, asociat unei organizatii virtuale.
n domeniul informatic exista mai multe directii de dezvoltare a auditului.
Auditarea software consta n activitati prin care se evidentiaza gradul de concordanta
dintre specificatii si programul elaborat. Auditul software da masura sigurantei pe care
trebuie sa o aiba utilizatorul de programe atunci cnd obtine rezultate. Siguranta se refera la
corectitudinea si completitudinea rezultatelor finale atunci cnd datele de intrare sunt, de
asemenea, corecte si complete.
Auditul bazelor de date, este un domeniu de maxima complexitate avnd n vedere ca, de
regula, lucrul cu bazele de date presupune att datele ca atare nsotite de relatiile create ntre ele,
ct si programele cu care datele se gestioneaza. De aceea se impune efectuarea unei reparari.
Auditul datelor vizeaza definirea acelor elemente prin care se stabileste masura n care datele
stocate ndeplinesc cerintele de calitate: corectitudine, completitudine, omogenitate, claritate,
temporalitate, reproductibilitate. Pentru fiecare caracteristica exista o metrica elaborata, iar
auditorul de date trebuie sa evalueze nivelul atins de caracteristica, pentru setul de date supus
auditarii. n final, auditorul de date certifica faptul ca datele stocate n baze de date constituie
intrari valabile pentru a obtine rezultate corecte.
n cazul auditarii riscului de gestiune a datelor stocate n baze de date se verifica daca:
- programele refera corect cmpurile cu date stocate;
- operatiile de prelucrare sunt cele din specificatii;
- agregarile, sortarile, evaluarile de expresii de extragere a subseturilor de date sunt n
concordanta cu specificatiile de obtinere a rezultatelor ca structura, dimensiune si
continut.
Auditul sistemelor informatice evalueaza riscurile unui mediu informatic sau ale unei
aplicatii informatice, ca de exemplu calculul salariilor sau facturarea.Aceste misiuni se realizeaza
alegnd, mpreuna cu clientul, procesul de evaluare.
Auditul informatic se poate referi la evaluarea riscurilor informatice ale securitatii fizice,
securitatea logica, managementul schimbarilor, planul de asistenta etc. n cazul general, auditul
informatic se refera la un ansamblu de procese informatice pentru a raspunde la o cerere precisa
a clientului. De exemplu, aprecierea disponibilitatii informatiilor si a sistemului. n acest caz se
controleaza care dintre procesele informatice raspund cel mai eficient la o asemenea cerere. n
cazul disponibilitatii, de exemplu, securitatea fizica si planul de continuitate.
Auditul informatic poate, de asemenea, sa evalueze aspecte strategice sau referitoare la
calitatea sistemelor informatice. De exemplu, sa verifice daca sistemul informatic al
ntreprinderii raspunde n mod eficient la nevoile functiilor serviciului.
Auditul mediului informatic se executa pentru a evalua riscurile sistemelor informatice
necesare functionarii aplicatiilor. De exemplu: securitatea fizica, securitatea logica, securitatea
retelelor, plan de salvare. n urma auditarii, se ntocmeste un raport n care sunt prezentate
punctele slabe, nivelul de risc al acestora si masurile corective propuse.
Analistul informatic are la dispozitie numeroase tehnici si metode pe care le adapteaza
contextului. ntr-un fel este auditat un program de calcul statistic sau de optimizare si altfel este
auditata o aplicatie care utilizeaza o baza de date. Pentru un sistem informatic complex exista
metode adecvate de auditare, iar pentru aplicatiile web accentul auditarii este pus pe gradul de
satisfactie a grupului tinta. Aplicatiile mobile au fundamente de auditare n care accentul este pus
pe asigurarea continuitatii, compatibilitatii, accesibilitatii rapide la resurse si, mai ales, asupra
nivelului atins de asigurarea securitatii fluxurilor din ntregul sistem.
De aceea, n cadrul procesului de audit informatic, planificarea si definirea metodei de
audit este esentiala. Alegerea unei metode neadecvate conduce la utilizarea de instrumente
neadecvate, iar rezultatele auditului au caracter speculativ.
Alegerea metodei presupune obtinerea unor informatii privind contextul n care se
deruleaza procesele legate de produsul software, de aplicatia informatica sau de sistemul
informatic, obiecte ale auditarii.
Auditul este, prin complexitatea sa, o activitate n care sunt luate n analiza legaturile,
implicatiile pe care le genereaza produsul software, aplicatia informatica sau sistemul informatic
ntre dezvoltator - compania de software si utilizator. Raporturile trebuie privite din punct de
vedere tehnic, financiar si juridic. Aspectul tehnic priveste date de interior, algoritmi, rezultate,
resurse folosite. Aspectul financiar vizeaza costul estimat al produsului software, aplicatie,
sistem informatic si costul efectiv, modul n care s-au efectuat platile. Caracterul juridic al
abordarii vizeaza obligatiile contractuale si legislatia din domeniul informatic.
 Toate aceste elemente conduc la stabilirea unor proceduri preliminare prin care sunt
definite directiile de analiza, gradul de semnificatie pe care procesul de audit informatic l ofera
si riscurile ca unele concluzii sa fie infirmate de practica derularii proceselor de utilizare curenta
a produsului software, a aplicatiei informatice sau a sistemului informatic n integralitatea lui.
Pentru a realiza auditul informatic se defineste planul de audit general si programul de
audit. Structura planului si definirea programului sunt standard, presupunnd parcurgerea unor
pasi obligatorii. Specificitatea produsului software, a aplicatiei informatice sau a sistemului
informatic si complexitatea acestora, determina efectuarea unor detalieri care difera de la un plan
general la altul, respectiv de la un program de audit informatic la altul. Sarcinile care se includ n
plan, esalonarea etapelor din program au elemente de variabilitate legate strict de structura si de
diversitatea produselor informatice analizate.
Standardele de auditare includ suficiente elemente astfel nct planul general si
programul de audit sa fie riguroase, fara ambiguitati si, mai ales, operationale. nainte de a se
trece la auditul informatic propriu-zis, datorita eforturilor ridicate de derulare si, mai ales,
datorita riscurilor ca reproductibilitatea procesului de audit sa fie afectata chiar de schimbarile
care au loc n produsele informatice auditate, trebuie efectuate teste asupra mecanismelor de
control si a mecanismelor de testare pe teste sursa, pe specificatii, pe diagrame, pe documentatii,
pe structuri de rezultate. Pentru aobtine o reducere a nivelului estimat pentru riscul erorilor
de analiza/control a produsului informatic n procesul de audit, printr-un proces frecvent se
procedeaza la efectuarea de corectii asupra modalitatilor n care se includ procedee tehnice,
metode, modele de analiza/control a produselor informatice. Procesul se ntrerupe atunci cnd
estimarea probabilitatii ca rezultatele auditarii informatice sa fie afectate de erori a atins un prag
acceptabil.
Auditul propriu-zis include proceduri analitice, teste, prin care se evidentiaza diferentele
dintre ceea ce s-a planificat a se realiza si ceea ce s-a realizat.
Procedurile analitice au la baza contractele ncheiate ntre parti, minutele care detaliaza
obiective, sarcinile ce revin partenerilor, specificatiile. Auditorul tehnic trebuie sa ierarhizeze
informatiile astfel nct sa identifice punctele cheie care definesc procesul de analiza, proiectare,
dezvoltare, testare, implementare a produsului informatic, fie ca este vorba de un simplu
program, fie ca este vorba de o aplicatie informatica desktop sau n retea, fie ca este vorba de un
sistem informatic care vizeaza ntreaga activitate a unei organizatii.
 Toate procedurile analitice si textele de detaliere aplicate modulelor, programelor si
sistemelor de programe, au menirea de a evidentia comportamentul, pas cu pas, a secventelor de
program. n cazul n care auditorul informatic are la baza pregatire de programator, stie sa aleaga
din multitudinea de proceduri si texte cu caracter analitic, pe acelea care ofera informatia
reprezentativa privind produsul software auditat, fie ca este vorba de un modul, fie ca este vorba
de un sistem complex. Efortul de auditare este ridicat indiferent de complexitatea produsului
auditat.
Auditul se ncheie cu un raport care are la baza o serie de verificari ale
interconditionarilor dintre module, dintre programe, respectiv dintre subsistemele sistemului
informatic, pentru acel moment, considerat baza.
Se verifica modul de producere a evenimentelor care sunt concretizate prin succesiuni de
prelucrari, corespunzatoare momentului. n acest fel, produsul informatic, proiectat pentru
derularea unor seturi de prelucrari, este analizat tinnd cont tocmai de succesiunea prelucrarilor.
Auditul informatic are la baza nregistrari privind structura software, structura bazei de date,
nregistrari ale lungimilor, volumului, complexitatii si nregistrari complete asupra
comportamentului n timpul executiei.
n cazul n care exista seturi de date cu care au fost testate produse informatice din
aceeasi clasa cu produsul auditat acum, se colecteaza serii de date privind comportamentul
produsului pentru a fi comparat cu produsele deja existente. Cnd nu exista date, sunt generate si
testarea produsului se realizeaza simultan cu produse din aceeasi clasa, tocmai pentru a efectua
analize si pentru a compara produsele informatice. Seriile de date se constituie n baze de
redactare a raportului de auditare.
De cele mai multe ori, auditul informatic este cerut ca solutie finala, impartiala, pentru a
justifica ipotezele unei parti contractante, fie ca este vorba de cumparator de software, fie ca este
vorba de beneficiar, cnd acestia cred n dreptatea lor absoluta.
n general, auditul este descris ca Examinarea independenta a nregistrarilor si a altor
informatii n scopul formarii unei opinii referitoare la integritatea sistemului controalelor si
mbunatatirea controalelor recomandate pentru limitarea riscurilor.
Definitia contine termeni semnificativi ca:
- examinare: auditiarea implica culegerea si evaluarea informatiilor factuale din surse
variate, este important ca rezultatele procesului de auditare (raportul primar de audit care
 contine recomandari pentru mbunatatirea controalelor) sa fie urmarit pna la sursele de
informatii valide;
- independent: auditorii nu sunt implicati direct n operatii sau n managementul functiei
care se auditeaza; subordonarea lor trebuie sa le asigure exprimarea libera a opiniilor;
- nregistrari si alte informatii: termenii includ ceea ce adeseori sunt numite "inregistrari
de audit", auditorii trebuie sa se refere la informatii privind procesul afacerii si sistemele
aflate n revizii asa cum sunt formele complete de intrari de date, rapoarte generate de
sistem si, binenteles, personalul implicat n desfasurarea sau conducerea proceselor
afacerii auditate;
- opinie: auditorii furnizeaza att fapte obiective ct si opinii subiective pe o situatie
data; desi subiective, opiniile lor sunt bazate pe interpretarea faptelor si sunt deschise
discutiilor; se poate sa nu se fie de accord cu aceste opinii, dar trebuie purtata o discutie
completa si sincera;
- integritate: termenul integritate include completitudine, acuratete si credibilitate; un
control al unui sistem care este numai partial efectiv poate fi mai bun dect nimic, sau
poate da un sens fals de securitate; auditorul va lua n considerare ambele cai;
- recomandare: auditorii genereaza recomandari, dar nu au autoritatea nici sa
implementeze schimbarile sugerate, nici sa impuna managementului sa faca schimbari;
mbunatatirile se obtin numai printr-un proces de explicare, justificare si persuasiune,
explicnd riscurile reprezentate de punctele slabe constatate n SI n urma auditarii,
justificnd nevoia de schimbare n cadrul procesului si/sau sistemului si sugernd
managementului necesitatea alocarii unor resurse si luarea de masuri pentru gestionarea
riscurilor;
- mbunatatirea controalelor: mbunatatirea sistemului de control nseamna, n general,
adaugarea controalelor care lipsesc; sunt foarte rare cazurile n care auditorii pot
recomanda eliminarea unor controale, n general, din cauza ca ele sunt ineficiente,
distrugatoare sau costisitoare;
- limite: ricurile si erorile pot fi reduse, dar nu pot fi complet eliminate; o buna activitate
implica minimizarea riscurilor cu cheltuieli eficiente si pregatirea pentru actiune n cel
mai rau caz posibil care s-ar putea produce (planificare pentru actiuni n caz de dezastre);
 - risc: posibilitatea ca ceva sa se desfasoare ntr-o directie nefavorabila; formal, riscul
este posibilitatea combinarii amenintarilor cauzate fie de cineva cu intentii rele, fie din
neglijenta sau incompetenta, actionnd asupra vulnerabilitatilor sistemului,
vulnerabilitatile sunt punctele slabe ale sistemului care apar, n general, din cauza lipsei
controalelor n sisteme de calcul si n proceduri de operare. Manifestarea riscurilor poate
genera, n anumite SI rezultate catastrofale.
Din alt punct de vedere auditul informatic este mecanismul de examinare a eficientei
organizatiilor, sistemelor, proceselor riscurilor si controalelor. Auditul da posibilitatea
managementului sa:
- descopere ceea ce se ntmpla n realitate la un moment dat;
- depisteze problemee potentiale nainte de a fi prea trziu pentru remediere;
- evalueze n mod obiectiv situatia afacerii;
- accepte realitatea si sa ia, n cunostiinta de cauza, decizii chiar daca sunt dificile;
- implementeze actiuni corective, schimbari si mbunatatiri acolo unde este necesar.
Auditul nu se refera numai la conformitate. Auditul poate include un element de control
privind conformitatea cu politica/standardele/procedurile interne ale companiei sau cu legi,
reguli si termeni contractuali externi, dar conformitatea este activitatea zilnica a
managementului. Auditorii experimentati controleaza daca procesele de management pentru
realizarea si evaluarea conformitatii sunt eficiente, care reguli sunt potrivite si suficiente pentru
SI auditat. Auditorii sesizeaza mai mult absenta conformitatii si nu att de mult cautarea
simptomelor problemelor n adncime.
Organizatiile de audit n SI au cai diferite de desfasurare a auditarilor, iar auditorii au
metodele lor preferate de lucru.
Amploarea unui audit informatic presupune realizarea n mod normal, a unei balante ntre
cantitate, referitor la numarul subsistemelor din compunerea unui SI care se auditeaza si calitate,
nsemnnd nivelul de detaliere la care se auditeaza subsistemele selectate.
Resursele auditului SI sunt directionate, n primul rnd, catre zonele cu grad ridicat de
risc. Aplicatiile utilizate n zonele critice ale afacerii se recomanda sa fie revizuite anual. Zonele
cu nivel de risc mai scazut pot fi auditate la intervale mai mari, n general odata la trei ani,
imediat dupa un incident sau cnd se considera necesar de catre echipa manageriala.
Principalele tipuri de audit informatic sunt:
- auditul sistemului operational de calcul; revizia controalelor sistemelor
operationale de calcul si retelelor, la diferite niveluri; de exemplu, retea, sistem de
operare, software de aplicatie, baze de date, controale logice/procedurale, controale
preventive/detective/corective etc;
- auditul instalatiilor IT; include aspecte cum sunt securitatea fizica, controalele
mediului de lucru, sistemele de management si echipamentele IT;
- auditul sistemelor aflate n dezvoltare; acopera unul sau ambele aspecte: (1)
controalele managementului proiectului si (2) specificatiile, dezvoltarea, testarea,
implementarea si operarea controalelor tehnice si procedurale, incluznd controalele
securitatii tehnice si controalele referitoare la procesul afacerii;
- auditul managementului IT; include: revizia organizatiei, structurii, strategiei,
planificarii muncii, planificarii resurselor, stabilirii bugetului, controlul costurilor etc.;
n unele cazuri, aceste aspecte pot fi auditate de catre auditorii financiari si
operationali, lasnd auditorilor informaticieni mai mult aspectele tehnologice;
- auditul procesului IT; revederea proceselor care au loc n cadrul IT cum sunt
dezvoltarea aplicatiei, testarea, implementarea, operatiile, mentenanta, gestionarea
incidentelor;
- auditul managementului schimbarilor; revizia planificarii si controlului
schimbarilor la sisteme, retele, aplicatii, procese, facilitati etc., incluznd
managementul configuratiei, controlul codului de la dezvoltare, prin testare, la
productie si managementul schimbarilor produse n organiza tie ca rezultat al ICT;
- auditul controlului si securitatii informatiilor; revizia controalelor referitoare la
confidentialitatea, integritatea si disponibilitatea sistemelor si datelor;
- auditul conformitatii cu legalitatea; copyright, conformitate cu legislatia, protectia
datelor personale;
- auditul accidentelor dezastruoase/planificarii continuitatii afacerii/refacerii dupa
dezastre; reviziile masurilor propuse pentru restaurarea dupa un dezastru care
afecteaza sistemul si evaluarea modului n care organizatia abordeaza managementul
riscurilor;
- auditul strategiei IT; revizia aspectelor variate ale strategiei IT, viziune si planuri,
inclusiv relatiile cu alte strategii, viziuni si planuri.
 Auditarea sistemelor informatice aflate n dezvoltare este considerat cel mai dificil tip de
audit informatic. n majoritatea cazurilor, proiectele auditate implica sume mari de bani, iar
practica demonstreaza ca n domeniul IT, un management corespunzator al proiectelor este mai
mult o exceptie dect o regula. Un auditor experimentat n domeniul SI depisteaza simptomele
unui dezastru iminent privind evolutia unui proiect, dar nu poate sa opreasca un proiect aflat n
dezvoltare.
Auditul sistemelor informatice nu este un audit financiar. Nu se testeaza date din punct de vedere
al formularelor financiare pentru a determina completitudinea, drepturi si obligatii, evaluari sau
alocari, prezentari sau divulgari.
Auditul sistemelor informatice implica:
- executarea unei serii de teste pentru a se asigura ca exista un control adecvat asupra
sistemului informatic;
- controale generale;
- controalele aplicatiilor.
Controlul general presupune:
- controal ce afecteaza mediul de procesare al calculatoarelor incluznd:
- managementul resurselor computerelor; o copii de salvare si arhivare;
- controlul schimbarilor n programul computerului;
- controlul sistemului de operare.
Control al aplicatiilor:
- specific pentru o aplicatie: acceptarea datelor autorizate;
- procesarea este completa si corecta; o output-urile sunt corecte si credibile.
Controalele generale formeaza baza controalelor aplicatiilor. Auditul informatic trebuie
astfel planificat nct sa se obtina rezultatele pe care le urmaresc att auditorul ct si organizatia
auditata. n planificarea auditului, auditorul trebuie sa nteleaga sistemul si sa planifice auditul.
Auditorul trebuie santeleaga complexitatea sistemului informatic si, de asemenea, modul
n care mediul n care evolueaza sistemul informatic influenteaza evaluarea si controlul
riscurilor.
Auditorul trebuie sa nceapa cu intervievarea echipei manageriale si a personalului din
sistemul informatic pentru a culege informatiile necesare desfasurarii auditului. Auditorul
trebuie sa examineze activitatile care se desfasoara n cadrul functional al sistemului informatic,
sa revada documentele elaborate de auditarile anterioare si sa revada documentatia sistemului
informatic.
Este necesar ca auditorul sa revada informatiile colectate astfel nct sa capete o buna
ntelegere a tuturor controalelor care exista n cadrul organizatiei.
Auditul este o activitate complexa, realizata de specialisti cu nalta calificare si experienta
n domeniu. Auditul nu este o activitate de control. Orice activitate de control presupune
existenta unui sistem n functiune. Controlul are menirea de a stabili daca au fost respectate sau
nu procedurile de desfasurare a activitatilor, daca s-au nregistrat plusuri sau minusuri. Se
stabilesc diferentele dintre nivelurile reale si cele scriptice si se propun masuri de recuperare a
pierderilor sau de valorificare a plusurilor. Activitatea de control are caracter repetat, se executa
la anumite intervale. Se constata fie ca sistemul functioneaza corect/normal, fie ca exista abateri
n plus sau n minus si apar sanctiuni si masuri de remediere, respectiv de valorificare.
Auditul nu este o activitate de expertizare. O expertiza presupune doua parti adverse, cel
putin, si mai multe cauze care au generat un eveniment. Expertiza se executa de specialisti,
numiti experti, cu vasta experienta n domeniul evenimentelor. Expertiza are menirea de a stabili
cauze, de a demonstra legatura dintre cauze si efecte. Expertiza se concretizeaza printr-un raport
care are menirea de a clarifica, fara a mai lasa loc interpretarilor, toate aspectele definite de cei
care au solicitat-o. Se fac expertize la accidente, la modul n care au fost realizate constructii.
Sunt expertize judiciare, sunt expertize contabile, sunt expertize tehnice. Expertizele se
repeta. Exista superexpertize asa cum exista si supracontroale.
Ideea de baza este de a stabili un mod real n care s-a derulat un eveniment, care au fost cauzele
care au favorizat o anumita directie. Se stabilesc vinovati atunci cnd controlul, respectiv
expertiza, o cer.
Auditul presupune un produs nou care se lanseaza n uz curent. Specialistii care asigura
auditul sunt auditori. Activitatea de auditare are menirea de aanaliza un produs nainte de a fi
lansat n utilizare curenta. Auditarea se efectueaza de catre o echipa independenta care se bucura
de credibilitate. Credibilitatea echipei de auditori este transferata, prin
intermediul raportului, asupra produsului auditat. La livrarea unui produs auditat, prin
specificarea echipei de auditare, cumparatorul/utilizatorul capata ncrederea ca produsul
achizitionat are, n realitate, parametrii nscrisi n documentatie, la nivelurile specificate. De
asemenea, cumparatorul/utilizatorul primeste toate informatiile legate de avantaje, performante,
dar, n egala masura, primeste si informatiile privind riscuri si efecte secundare, negative sau
pozitive, rezultate din constructia produsului.
Cnd este finalizat un sistem informatic exista:
- documentatia privind contractul pe baza caruia se construieste sistemul, fondurile disponibile,
duratele de timp rezervate; documentatia cuprinde obiectivul sistemului informatic, sarcinile ce
revin echipei de realizatori si sarcinile care revin beneficiarilor;
- documentatia tehnica n care este definita calitatea planificata, exigentele exprimate de
beneficiar si modul n care se efectueaza testarea ntregului sistem;
- specificatiile sistemului informatic si minutele ncheiate ntre realizator si beneficiar care au
reiterat acele aspecte necesare satisfacerii cerintelor beneficiarilor pentru a atinge obiectivul
propus la ncheierea contractului; se are n vedere rolul activ al echipei de realizatori pentru a
orienta pe beneficiar spre solutii care au acoperire n plan informatic, platforme si arhitecturi
moderne;
- setul de date de test discutat si avizat de beneficiarul sistemului informatic, inclusiv indicatiile
pentru generarea de extensii de date de test att de catre realizatorul sistemului, ct si de catre
beneficiar, fara ca aceste extensii sa depaseasca structurile definite n contractul pe baza caruia se
dezvolta investitia;
-setul de nregistrari privind comportamentul sistemului pe parcursul efectuarii testelor; sunt
incluse si procedurile, algoritmii si rezultatele intermediare ale indicatorilor de calitate asa cum
au rezultat pentru diferitele componente ale sistemului informatic;
-evidentele de distribuire a sarcinilor pe membrii echipei de realizatori, rezultnd cu claritate ce
module a realizat un anumit programator, ce componente a testat un specialist n evaluarea
subsistemelor, ce date au fost ncarcate de fiecare operator n parte; aceste evidente contin si
termenele si consumurile de resurse pentru a stabili corelatia dintre calitate si cost, dintre
consumurile de resurse si complexitatea componentelor realizate;
- documentatia completa de realizare a produsului, scheme, diagrame, descrieri ale modulelor,
ale procedurilor, ale variabilelor, ale rezultatelor, ale fluxurilor, ale structurilor de date; sunt date
mesajele oferite operatorilor si semnificatia fiecaruia; sunt indicate valorile implicite si
combinatiile de optiuni care pun n opera sistemul de programare; se definesc conditiile
minimale care trebuie asigurate pentru ca sistemul sa fie operational;
- rapoartele de predare-primire pentru asamblarea componentelor;
- rapoartele de testare ale subsistemelor de programe folosind datele de test convenite
cu beneficiarul si ncarcate n bazele de date de test; rapoartele de testare ale ntregului sistem;
-rapoartele grupurilor de lucru pe parcursul derularii procesului de dezvoltare, urmarindu-se
fiecare etapa a ciclului de realizare;
-fisierele cu variantele de module, de biblioteci de obiecte, nsotite de rapoartele de acceptare si
de unele comentarii privind trecerea de la o varianta la alta;
-documentatia de prezentare si de instalare precum si totalitatea software si baze de date pe
suport pentru a fi preluate ca produse portabile, la beneficiar.
Obiectivul auditului pentru un sistem informatic ia n analiza totalitatea elementelor pentru a
proba daca produsul finit - sistemul informatic al companiei - raspunde cerintelor formulate n
contractul n baza caruia s-a efectuat investitia.
Pentru a avea un audit de calitate trebuie ndeplinite urmatoarele conditii:
- echipa de auditare trebuie sa primeasca totalitatea informatiilor are sa constituie intrari ale
procesului de auditare;
- tehnicile si metodele de auditare trebuie sa fie utilizate corect, folosind tot ceea ce este necesar
pentru a obtine rezultate reale, neafectate de factorii perturbatori sau de abordari partiale;
- sa existe clar delimitat ceea ce trebuie sa realizeze sistemul informatic si ceea ce realizeaza
efectiv; auditarea scoate n evidenta diferentele, efectund si unele cuantificari, pentru a reiesi
mai precis pentru fiecare cerinta n parte, ponderea a ceea ce lipseste sau ponderea a ceea ce este
n plus.
Pornind de la obiectivul auditarii, de la importanta pe care o prezinta rezultatul auditarii, echipa
de specialisti dimensioneaza efortul care trebuie depus de la ntocmirea planului de auditare, ca
atare, si pna la elaborarea raportului de auditare.
La desfasurarea obiectivului auditarii trebuie sa fie introduse acele elemente care subliniaza
ncrederea pe care utilizatorul sistemului informatic trebuie sa o aiba pe durata exploatarii.
Raportul de auditare trebuie sa faca dovada n mod convingator ca achizitionnd un produs sau
utiliznd un sistem informatic rezultat al unui proces investitional, utilizatorul va beneficia de
servicii de calitatea dorita.
La fel ca n cazul unei operatii chirurgicale, n care viata pacientului este mai presus de orice, n
auditul sistemelor informatice nu exista o diferentiere n profunzimea cu care este abordat
procesul de auditare. Daca obiectivul definit este cu un enunt comun precum stabilirea
concordantei dintre produsul dorit si cel real n vederea consolidarii ncrederii n utilizarea
produsului real, el trebuie interpretat prin prisma rigurozitatii si profesionalismului cu care sunt
parcurse toate etapele. Este cunoscut faptul ca auditarea unui produs, de complexitatea sistemelor
informatice, reprezinta o investitie morala, a carei pierdere nu se mai recupereaza
niciodata. Companii renumite de audit au disparut atunci cnd rezultatul auditului a fost unul, iar
realitatea privind produsul auditat a fost alta. Auditul nu are menirea de a stabili ncrederea ntr-
un sistem informatic. De exemplu, un sistem este livrat, utilizatorul si exprima nemultumirea,
iar dupa un timp doreste sa recupereze pe cale judiciara daune. Atunci producatorul cere
auditarea sistemului informatic pentru a restabili ca produsul e bun, altele fiind cauzele care
genereaza nemultumirea beneficiarului. Aceste aspecte revin expertizelor tehnice. Auditul
transfera credibilitate unui produs nou. Obiectivul clar al auditului este de a se concentra ntreaga
activitate, prin analiza, pe aspecte calitative si cantitative, din care rezulta concordanta dintre
produsul planificat a fi realizat si produsul pe cale de a fi livrat. Auditul sistemului informatic
este un proces extrem de complex, iar echipa care realizeaza un astfel de audit trebuie sa aiba o
diversitate de specialisti, iar acestia, la rndul lor, trebuie sa aiba o bogata experienta
profesionala si vaste cunostiinte teoretice. Un sistem informatic nu se auditeaza de persoane care
nu stapnesc domeniul afectat etapei din procesul de auditare. Asa cum n dezvoltarea sistemului
informatic exista un ciclu de dezvoltare, divizat n etape, tot asa exista etape ale ciclului de
auditare. Fiecare etapa reprezinta un sistem de diviziune a muncii, iar comunicarea este un factor
esential. Este vorba de comunicarea ntre membrii echipei de auditare, respectiv, comunicarea
ntre auditori. De asemenea, auditorii trebuie sa comunice, pentru a clarifica unele aspecte, cu
echipa care a realizat sistemul informatic.
n domeniul sistemelor informatice, categoria importanta o constituie sistemele informatice de
management, a caror auditare prezinta anumite paricularitati.
Sistemele informatice pentru management sunt constructii deosebit de complexe care au ca
obiectiv ridicarea la cote maxime a procesului de informatizare la nivelul organizatiilor.
Daca o organizatie este caracterizata prin functiile F1, F2,...Fk, structura sistemului informatic
pentru management include k subsisteme, SS1, SS2,...SSk, pentru fiecare functie un subsistem.
ntregul sistem informatic este proiectat sub forma unor subsisteme cu stabilirea legaturilor
dintre ele.
Abordarea sistemelor pentru management presupune un fundament teoretic si practic deosebit de
solid si acceptarea unui demers de anvergura pe o perioada de doi-cinci ani. Tehnicile si
metodele de analiza si proiectare au la baza o cunoastere n detaliu a stadiului actual atins de
procesul de informatizare la nivelul organizatiei.
Exista sisteme puternice de gestiune a bazelor de date, de solutionare a problemelor definite n
cadrul fiecarei functii din organizatie. Trecerea la dezvoltarea unui sistem informatic pentru
management trebuie sa ia n considerare existenta acestor componente. n acelasi fel se pune
problema si n cazul n care se doreste dezvoltarea de sisteme de gestiune a documentelor, din
moment ce exista deja astfel de sisteme livrate la cheie. A spune acum ca o organizatie are
particularitatile ce impun definirea unei structuri proprii de sistem informatic nseamna a
considera ca echipele care au proiectat sisteme care se aplica n foarte multe tari nu sunt
competente, iar organizatia este att de speciala nct nu se ncadreaza n nici o categorie.
Abordarea este nu numai absurda prin simplismul ei, dar denota un nivel de ignoranta greu de
acceptat din punctul de vedere al nivelului actual al informaticii.
Problemele de audit pentru un sistem informatic de management au o alta anvergura fata de
celelalte entitati, produsul program sau aplicatia informatica. Literatura de specialitate include
numeroase lucrari care se adreseaza celor care elaboreaza sisteme informatice orientate pe
gestiune financiar-contabila.
Auditul acestor sisteme este o problema extrem de actuala pentru ca:
- sistemele informatice de gestiune contabila neauditate conduc la efectuarea de operatii
neautorizate;
- sunt situatii n care nu exista concordanta ntre teoria contabilitatii si procedurile care se
apeleaza pentru a efectua prelucrari;
- n faza de analiza sunt definite incomplet cerintele care corespund laturilor calitative si
cantitative definite prin relatia ntre conturi, prin restrictii privind efectuarea de operatii si prin
proportii impuse unor niveluri cu care se efectueaza debitarile sau creditarile;
- prioritatilor de efectuare a operatiilor existente n teoria contabila trebuie sa le corespunda
secvente de testare care sa asigure concordanta ntre listele prioritatilor existente n teoria
contabila si listele generate prin procesele de prelucrare prin programe;
- validarile datelor capata o alta semnificatie, fiind legate nu numai de apartenenta la un anumit
domeniu de variatie, ci fiind dependente de context, ntruct operatiunile contabile sunt definite
n cadrul unui anumit context;
- interfetele acestor sisteme trebuie sa fie orientate spre o abordare a proceselor n timp real,
ntruct numeroase operatii se deruleaza prin sistemul e-banking, e-commerce; operatorii trebuie
sa lucreze n regim responsabilizat cu nregistrarea operatiei ntr-o structura impusa din care sa
nu lipseasca momentul efectuarii operatiei si elementele de identificare a operatorului;
- ntre sistemul de restrictii de acces la efectuarea de operatii n baza de date si cerintele teoriei si
practicii contabile trebuie sa existe o concordanta perfecta; trebuie sa existe persoane care au
acces la consultarea ntregii baze de date; trebuie sa existe alte persoane care au acces la
consultarea unor parti din baza de date, sunt alte persoane din organizatie care au drept de a
consulta numai operatiile care privesc activitatea lor; lista persoanelor care opereaza pe baza de
date se defineste asa nct, pe masura cresterii importantei operatiei n baza de date, numarul si
functia n organizatie se definesc cu un nivel de exigenta sporita, regulile impuse au menirea de a
tine sub control totalitatea operatiilor pe cmpurile bazei de date;
- sistemul informatic de gestiune financiar-contabila se proiecteaza incluznd numeroase chei de
control care sa evidentieze frecvente ale unor operatiuni, apropierile de limitele domeniilor de
variatie, astfel nct sa se ia rapid deciziile adecvate;
- la proiectare si la realizare se definesc situatiile de blocare pentru a semnaliza tentativele de
efectuare a operatiilor interzise;
- aceste sisteme sunt organizate ca structuri ierarhice, cu interventii de asemenea, ierarhice, daca
s-a produs un eveniment la nivelul K+1, numai un administrator de la nivelul K al structurii
arborescente intervine si produce deblocarea sau efectueaza operatia care trebuie autorizata
pentru a readuce sistemul la nivelul de operare normala; toate procesele de blocare/deblocare
sunt nregistrate si se trateaza distinct.
Rezulta ca un sistem informatic pentru management n general, iar un sistem informatic pentru
managementul financiar contabil n special, trebuie nzestrat pe lnga functiile clasice de
prelucrare, de extragere a rezultatelor si de creare-actualizare a bazei de date, cu functii de
management pentru calitatea si protectia sistemului informatic nsusi.
Marile probleme rezultate n activitatea curenta a implementarii de software pentru contabilitate
au impus dezvoltarea auditului spre aceasta categorie de produse program.
Exista o preocupare speciala pentru auditul sistemelor informatice de gestiune financiar-
contabila. si celelalte sisteme informatice sunt auditate.Principiile auditului sistemelor
informatice de gestiune sunt o particularizare a principiilor auditului pentru sistemele informatice
pentru management.
Asa cum n modul clasic de operare pe documente exista riscul transferurilor de fonduri si de
mijloace care genereaza fraude mpotriva companiei, fraude mpotriva altor companii, fraude ale
managerilor, fraude ale unor membri ai companiei, n cazul implementarii unui sistem informatic
de gestiune contabila, toate aceste tipuri de fraude se reproduc daca si numai daca sistemul nu
contine procedurile care sa semnaleze efectuarea de operatii neconsistente n raport cu criterii
precis stabilite.
n primul rnd, legile definesc situatiile n care o persoana nu are drept sa ia un credit.
Sunt date reguli extrem de precise n a defini un creditor ca fiind rau-platnic.
Sistemul informatic dintr-o banca trebuie sa includa proceduri prin care se verifica statutul
solicitantului si ncadrarea n categoria :
- rau platnicilor;
- creditorilor al caror plafon de creditare a fost atins;
- creditorilor care mai pot solicita un credit, nu mai mare dect o valoare impusa;
- creditorilor care au dreptul sa solicite credit cu valoare care se ncadreaza ntr-un interval
definit de garantii, de cifre de afaceri si de istoricul lor n relatia cu banca.
Evident, rolul auditului unui astfel de sistem este de a testa daca respectivul sistem bancar
include proceduri. Datele de text sunt date reale cu care se opereaza n banca unde sistemul
informatic va fi operational.
Sistemul informatic bancar nu trebuie sa valideze efectuarea unor operatii interzise prin acte
normative, dintre care operatia de efectuare de plati ale ratelor unui credit cu banii obtinuti dintr-
un alt credit. Auditorii sistemelor informatice bancare au deja inclusa aceasta operatie n lista
operatiilor interzise, lista folosita cu prioritate n testarea comportamentului unui sistem
informatic bancar.
Un sistem informatic de management financiar-contabil auditat devine credibil cnd echipa
conchide n raportul de audit ca sistemul raspunde tuturor cerintelor din specificatii, din legi si
regulamente, iar securitatea operatiilor este asigurata, conditiile de risc n utilizare fiind minime.
Auditul sistemelor de gestiune financiar-contabila are menirea de a oferi ncredere utilizatorului
n produsul informatic.
De aceea trebuie supuse auditarii toate componentele sistemului, intrarile si iesirile
acestora. Numai prin coborrea auditului la nivelul detaliilor se vor obtine informatiile necesare
fundamentarii unei concluzii finalizate printr-o propozitie simpla, fara echivoc, de calificare a
sistemului.
Prin specificatii este creata o imagine, un sistem informatic virtual. Daca se adauga noi cerinte
desprinse din legislatie, din experienta curenta, daca se produce o ierarhizare a prioritatilor
privind operatii permise, respectiv, operatii interzise, se creeaza proiectia unui sistem informatic
virtual si ideal. Toate comparatiile sistemului real sunt efectuate strict fata de coordonatele pe
care le ofera ca reper sistemul virtual ideal.
Auditul unui sistem informatic de gestiune financiar-contabil nu are rolul de a controla. Esenta
auditului nu este controlul. Auditorii sunt persoane cu nalta calificare care nu se substituie
controlorilor de calitate, controlorilor care stabilesc existenta fizica a unui produs, exprimnd-o
prin cantitate, dupa masurare.
Auditul este o activitate superioara de orientare, analiza si de sinteza. Este o necesitate tocmai
prin extensiile pe care le determina asupra ntregii viziuni de abordare.
Planul de audit si programul de audit presupun activitati clare, nici una dintre acestea nefiind de
control.
Specificatiile reprezinta un text structurat. Sistemul informatic reprezinta o structura. Auditorul
are menirea de a stabili existenta corespondentei dintre componentele textului structurat si,
respectiv componentele sistemului, identificnd concordanta perfecta, concordanta partiala,
concordanta redusa sau absenta concordantei.
Componentele din structura textului care alcatuiesc specificatiile includ:
- nivelul managementului;
-ciclul de elaborarea a sistemului informatic de gestiune financiar-
-contabila;
- securitatea sistemului prin: precizarea responsabilitatilor, separarea functiilor incompatibile,
ierarhizarea accesului la resursele sistemului, gestiunea copiilor;
- nivelul operational n modul de lucru, prin procedurile pe care operatorii le efectueaza n ceea
ce priveste: introducerea de date, manipularea de documente, manipularea dischetelor cu date
intermediare, nregistrarea evenimentelor, asistenta tehnica;
- nivelul aplicatiilor presupune parcurgerea de catre auditor a tuturor etapelor astfel nct sa se
dezvolte convingerea ca sistemul informatic de gestiune contabila este chiar constructia n care
utilizatorul trebuie sa aiba mare ncredere; se reia un ciclu complet de prelucrare, de la initierea
procesului, pregatirea datelor, procesarea acestora si obtinerea rezultatelor: fisierele, bazele de
date sufera o serie de modificari pe care analistul trebuie sa le analizeze pentru a vedea daca
exista sau nu si alte efecte secundare;
nivelul de acces presupune identificarea modului n care au fost solutionate elementele
fundamentale ale accesului la resursele sistemului informatic - proceduri, baze de date, modul n
care se dezvolta si alte canale de transfer a informatiilor si cum se asigura robustetea retelei de
calculatoare.
Echipa de audit colecteaza date proprii, dar preia si rezultate oferite de sistemul informatic de
gestiune financiar-contabila. Pe masura ce se traverseaza etapele ciclului de dezvoltare, echipa de
realizare a sistemului informator elaboreaza parti ale documentatiei care nsoteste sistemul.
Echipa de audit analizeaza si aceasta documentatie pentru a urmari traseul parcurs de la
specificatii, pna la obtinerea produsului finit n forma livrabila catre organizatii.
Raportul de audit este un document sinteza care efectueaza analiza comparata ntre un sistem
virtual-ideal si un sistem real. Toate datele nregistrate n procesul de auditare se coroboreaza cu
specificatiile, cu documentatia. Se calculeaza o serie de indicatori. n final se spune ca
sistemul este sau nu credibil, asigura sau nu calitatea prelucrarilor, ca exista sau nu garantia ca
sistemul informatic sa dea satisfactie clientului n raport cu un obiectiv stabilit.
Auditul informatic este un demers deosebit de complex, motiv pentru care trebuie asezat pe un
fundament solid.
Obiectivul fundamental al activitatii de auditare informatica este stabilirea gradului de
credibilitate a sistemului informatic de management. Fluxurile de informatii specifice oricarui
sistem informatic trebuie sa asigure integritatea informatiilor organizatiei, completitudinea
prelucrarilor, corectitudinea rezultatelor si mai ales accesibilitatea beneficiarului la informatia
asteptata, obtinnd n acest fel un nivel maxim al satisfacerii cerintelor proprii.
Din punct de vedere al echipelor de auditare auditul sistemelor informatice se clasifica astfel:
- audit intern, prin care se confirma respectarea procedurilor de transformare a datelor de intrare
n rezultate - urmarindu-se modul n care noul sistem n care se implementeaza este mai eficient,
este nsotit de economisire de resurse;
- audit extern care include proceduri prin care se evidentiaza comportamentul sistemului
informatic, prin testari cu ajutorul carora se evidentiaza ct de stabile, ct de fiabile, mentenabile
sunt procedurile de control care intra n componenta sistemului si care implementeza toate
cerintele exprese incluse n specificatii, n legi, n regulamnete si care restrictioneaza prin blocare
orice tentativa de executie a operatiilor interzise.
Pentru a dezvolta un proces de auditare a sistemului informatic de management sunt parcursi
urmatorii pasi:
- planificarea proceselor de auditare avnd la baza o serie de
elemente prin care se stabileste anvergura prin cunoasterea unor elemente
legate de complexitatea sistemului informatic si mai ales prin stabilirea nivelului de
credibilitate pe care trebuie sa-l stabileasca auditorii sistemului;
- evaluarea riscurilor legate de influentele negative care se manifesta asupra
componentelor sistemului informatic ce vor fi auditate, pe
masura ce se activeaza procedurile de control;
- elaborarea programului de audit ce include: definirea scopului, stabilirea obiectivelor,
efectuarea planificarii, derularea propriu-zisa, ntocmirea de rapoarte;
-culegerea de date ce evidentiaza modul cum se executa prelucrarile, care sunt neconcordantele
ntre specificatii si produsul real; datele apar sub forme extrem de variate, de la liste, fisiere de
tranzactii, liste de erori, chestionare care vizeaza obtinerea unor raspunsuri cu cheie, diagrame,
texte sursa, seturi de date de text, documentatia care se livreaza o data cu implementarea
sistemului informatic, ghidurile de utilizare si de administrare;
- elaborarea raportului de auditare care preia elemente definite n planul de audit a sistemului
informatic la care sunt adaugate detalii asupra modului cum s-a derulat procesul de auditare,
gradul de transparenta asigurat.
ntruct auditorii de sisteme informatice pentru management sunt specialisti de nalta calificare
n domeniu, enumera n raport totalitatea diferentelor care au fost ntlnite, ntre sistemul real si
sistemul virtual-ideal; nu sunt incluse solutii, desi auditorii prin competenta lor deosebita au
capacitatea de a le oferi; auditul sistemelor informatice pentru manangement consemneaza numai
diferentele; caracterul sistematic al procesului de auditare ofera o grupare ascendenta n raport cu
profunzimea efectelor de antrenare, a diferentelor; n cazul n care sunt identificate erori, toate
erorile sunt tratate distinct si contributia lor n diminuarea nivelului de credibilitate a sistemului
informatic pentru management este amplificata prin utilizarea de coeficienti de importanta
cunoscuti att de auditori, ct mai ales de cei care au dezvoltat sistemul informatic.
Activitatea de audit pentru sisteme informatice se bazeaza pe agregarea unor indicatori si pe
obtinerea de valori care sa fundamenteze apartenenta sistemului informatic la clasa de sisteme
credibile n care se garanteaza calitatea solutiilor asteptate de beneficiar sau, din contra, sistemul
nu e credibil si trebuie sa fie supus unor corectii si din nou unui proces de auditare.
Daca tehnica de auditare si procedurile de masurare a diferentelor sunt clar definite, procesul de
audit pentru sisteme informatice este reproductibil n proportie de 100%.
Asociatiile care au preocupari n a elabora tehnici si metode de auditare sau de a certifica
speculatii n auditul sistemelor informatice pentru
management si-au concentrat atentia asupra algoritmizarii proceselor de auditare, n viitor
trebuind sa defineasca metrici pentru a asigura caracter obiectiv auditului, prin transferul din
zona interpretarilor, n zona certitudinilor.
Particularitatile auditarii sistemelor informatice, comparative cu alte produse, si necesitatea unei
pregatiri corespunzatoare a auditorilor, necesita existenta unor standarde corespunzatoare acestui.
Obiectivele acestor standarde sunt de a informa:
- auditorii de sisteme informatice privind nivelul minim de pregatire;
- managerii si alte personae interesate privind asteptarile unei activitati de auditare.
Standardele definesc cerintele obligatorii pentru desfasurarea auditului si pentru modul de
ntocmire a rapoartelor de audit.
4. CONSTRUIREA DE LISTE
O lista este o constructie liniara, formata din elemente dispuse unul dupa altul. O lista presupune
parcurgerea secventiala, de la primul element, elementul din capul listei, pna la ultimul element.
Construirea unei liste se realizeaza pentru a obtine:
- enumerarea elementelor unei colectivitati ntr-o ordine stabilita, ca de exemplu, n ordinea
sosirii ntr-un fir de asteptare, n ordinea servirii, n ordinea importantei sau ntr-o ordine a
preferintelor;
- stabilirea etapelor unui proces, n ordinea derularii lor;
- setul de documente necesar pentru a obtine calitatea de eligibilitate n vederea acordarii unor
fonduri pe baza de proiect;
- o ierarhizare a elementelor unei colectivitati n functie de un criteriu de performanta stabilit si
acceptat de participanti;
- un inventar al componentelor care alcatuiesc un subansamblu sau un produs finit; se specifica
denumirea reperelor si numarul de repere de acelasi fel care intra n alcatuirea subansamblului;
- un sir de valori care corespund unor momente de timp; sirul include elemente omogene, care se
supun acelorasi prelucrari.
n procesul de auditare, rigurozitatea si profesionalismul impun elaborarea de liste complete,
structurate strict pe importanta sau pe ordinea de executie.
Planul de auditare se constituie ca lista de activitati care trebuie executate. Derularea activitatii n
sine este descrisa ca o lista a activitatilor. Raportul de auditare este, de asemenea, o lista de
calificative. Lungimea listelor depinde de complexitatea sistemului informatic. Procesul de
auditare se deruleaza dupa reguli precise. El se constituie din etape fixe date de tehnicile si
standardele de auditare. Fiecarei etape i corespunde o componenta n lista de baza a auditului
sistemului informatic, avnd asociat un text care indica obiectivul etapei, inputurile etapei si
outputurile acesteia.
La rndul lor, etapele sunt detaliate prin construirea unor liste de activitati formate din elemente,
fiecare element fiind concretizat printr-un text care contine detalii privind modul cum se
realizeaza fiecare dintre activitatile corespunzatoare etapei.
Pna n acest stadiu de detaliere, auditarii i corespunde o agregare de liste simple, pe doua
niveluri, obtinndu-se o lista de liste. Este vorba de lista etapelor care contine liste de activitati.
Daca detalierea este aprofundata, fiecarei activitati i corespund sarcini, rapoarte, persoane,
pentru toate acestea definindu-se noi liste, care conduc la o noua agregare. Auditarea este o
agregare de nivel a listelor. Cu ct nivelul este mai mare, cu att rigurozitatea demersului este
mai ridicata. Faptul ca fiecarei activitati i se asociaza inputuri, outputuri si sarcini, nseamna ca
procesul de auditare este constituit ca un mecanism care doar trebuie pornit pentru a merge
perfect.
si auditul sistemelor informatice, ca orice activitate complexa, este o activitate de echipa.
Consultingul n echipa presupune:
- existenta unui manager cu experienta si cu reale calitati n domeniul lucrului cu oamenii, pentru
a crea cadrul adecvat activitatilor de audit, pentru a mentine nivelul de exigenta la cote ridicate,
fara a face rabat de la sarcini si, mai ales, pentru ncadrarea n termene si limite de calitate;
- stabilirea unor criterii riguroase de selectie a membrilor echipei; auditul unui sistem informatic
este un proiect; ca orice proiect pentru care exista un management, o atributie a managerului este
formarea echipei; n cazul unor structuri birocratice, constituite pe criterii n cadrul carora
performanta si coeziunea nu sunt prioritare, este dificil sa se deruleze un proces de audit de
sistem informatic cu eficienta; restrictiile auditului nu permit rabat, iar orice neconcordanta n
functionarea echipei, n special n planul comunicarii si n planul compensarilor n vederea
echilibrarii sarcinilor, conduce la dereglaje, mai ales n ce priveste termenele asociate fiecarei
etape a auditului; arta managerului consta n a-i cunoaste pe oameni, a sti ce putere de munca are
fiecare, ce calitati, ct de eficient este; pozitionarea unei persoane din echipa, din punct de vedere
al sarcinilor, apartine managerului de proiect de audit sistem informatic; o aceeasi persoana pusa
la un loc cu sarcini pe care le ndeplineste, este omul potrivit, la locul potrivit, cum, desigur, prin
plasarea la un loc de munca neadecvat calitatilor si pregatirii, este omul nepotrivit, la locul
nepotrivit;
- realizarea unei discipline a lucrului n echipa; este cunoscut faptul ca n activitatea unei echipe
exista patru momente: primul moment corespunde definirii problemei de rezolvat, al doilea
moment corespunde formularii de solutii, al treilea moment este activitatea propriu-zisa, pentru a
transpune solutiile n practica, iar ultimul moment, al patrulea, corespunde
evaluarii rezultatului muncii echipei; este important ca, la definirea problemei si la elaborarea de
solutii, membrii echipei sa comunice; parerile, dezbaterile, sunt esentiale n a obtine cea mai
buna definire a problemei, pentru a obtine cea mai buna solutie; n zona auditului superlativele
sunt necesare, pentru ca altfel rezultatul auditului nu are acele elemente care sa transfere
sistemului informatic credibilitatea necesara; definirea incompleta a problemei de audit conduce
la abordari partiale avnd drept consecinte revenirea la unele etape trecute si modificarea
costurilor legate de reluarea unor activitati; disciplina impusa de managerul proiectului de audit
sistem informatic vizeaza dialogul deschis n timpul definirii problemei si prezentarii de solutii
si, respectiv, la alegerea solutiei de auditare efective; disciplina trebuie astfel dirijata, nct, dupa
luarea unei decizii, nici unul dintre participanti sa nu mai discute despre o solutie foarte buna pe
care el ar putea sa o propuna, dar care, stie el exact, nu ar fi fost adoptata din considerente pe
care nu le face cunoscute; asa-zisii experti n a da solutii, prin regulile impuse de managerul de
proiect, aveau dreptul sa le faca cunoscute; din lipsa de idei, evident, se ascund n spatele unor
ipotetice solutii de sertar, inexistente n realitate, producnd un soi de disidenta neproductiva
pentru procesul de auditare; un manager de proiect de audit, care continua, la un alt proiect, sa
includa astfel de persoane n echipa, nseamna ca accepta si chiar cultiva un stil de lucru
neproductiv; mai mult, daca aceste solutii sunt rediscutabile la nivelul echipei, etapa de alegere a
solutiei se prelungeste; mai dificil este atunci cnd etapa de alegere a solutiei este reluata dupa ce
au fost parcurse deja alte etape ale procesului de auditare; n acest caz, se manifesta
disfunctionalitati chiar la nivelul managementului de proiect de auditare, iar pna la
compromiterea procesului de auditare este numai un pas;
- elaborarea de rapoarte n timp real; este cunoscuta tentatia de a scrie rapoarte dupa derularea
fazelor; programatorii elaboreaza schemele logice sau alte tipuri de diagrame numai daca acest
lucru este cerut imperios, desi standardele impun acest lucru; elaborarea documentatiei se face
mult mai trziu, ceea ce explica numeroasele lacune, aspectele extrem de ermetice pe care
designerii le includ, creznd ca toata lumea stie despre sistemul informatic tot ceea ce stiu si ei;
elaborarea rapoartelor n timp real nseamna, n primul rnd, efectuarea unor nregistrari ale
constatarilor "la cald", a ceea ce s-a vazut n cadrul realizarii fiecarei activitati pe care auditorul o
bifeaza n lista primita; trebuie sa existe o ordine n aceste notite
pentru a reconstitui pasii, pentru a opera pe seturile de date n vederea obtinerii, n final, a unor
rezultate coerente; existenta unei bune comunicari ntre membrii echipei care realizeaza aceleasi
activitati conduce la construirea de structuri de tabele compatibile, la abordari uniforme, care, n
final, dau unitate raportului de auditare; mai mult, pentru a obtine date comparabile, membrii
echipei trebuie sa comunice cu privire la procedurile pe care le adopta si sa ramna constanti n a
le utiliza pe toata durata procesului de auditare; realizarea stadiilor din rapoarte, bazata pe
proceduri unice, este sansa de a da consistenta concluziilor raportului final;
- adoptarea unui standard de auditare si folosirea unei singure metode; ntr-un razboi este folosita
o singura strategie, o singura tactica, iar armamentul este compatibil pentru a avea o comanda
unica; n cazul procesului de auditare lucrurile stau n mod similar; se adopta un standard pentru
auditul sistemului informatic, se fixeaza o metoda de auditare; obtinerea calitatii de auditor de
sisteme informatice presupune obtinerea de calificative de trecere la o serie de examene;
nseamna ca auditorul cunoaste standardele si metodele de auditare; managerul de proiect fixeaza
sau, ntr-un context mai democratic, supune atentiei si apoi adoptarii cele doua instrumente de
lucru; odata stabilite, se trece la punerea n miscare a ntregului proces de auditare a sistemului
informatic; auditarea este asemenea vizionarii cu specialisti si cu critici a unui spectacol, naintea
premierei de a doua zi; spectacolul e gata; el este vazut de specialisti; modificari nu se mai fac de
pe o zi pe alta; exista nsa o tensiune specifica, tensiune care precede momentul vizionarii, cu
tendinta de a face lucrurile ct mai bine, ntruct cei care vizioneaza spectacolul sunt detinatorii
efectului de ghilotina; tot n acelasi mod trebuie privit si procesul de auditare; cnd elaboratorii
sistemului informatic stiu ca sistemul lor - produs finit - va fi auditat, stiu si standardele si
tehnicile de auditare care se folosesc; de aceea, pe ntreg parcursul de realizare se face referire la
acestea, cu consecinte benefice asupra produsului final; desi exista tehnici de dezvoltare
software, standarde si instrumente, toate sunt putin folosite, iar produsul finit realizat are abateri
suficient de mari fata de ceea ce s-a propus initial, daca nu este prevazut din start si un proces de
auditare; chestiunea auditarii trebuie precizata nca de la ncheierea contractului, ca o conditie
necesara de acceptare a produsului de catre beneficiari; echipa care elaboreaza sistemul
informatic trebuie sa lucreze n cunostiinta de cauza, adica, din primul moment trebuie sa stie ca
produsul - sistemul informatic -
va fi auditat; mai mult, trebuie sa fie cunoscuti termenii auditarii n detaliu; sistemul informatic
nu se produce pentru a fi auditat, ci se produce pentru a satisface niste nevoi n plan
informational ale unui beneficiar; un sistem informatic se produce ntr-un fel daca se stie ca va fi
auditat si cu totul n alt fel daca nu este auditat. Daca se realizeaza un experiment: doua echipe
sunt puse sa dezvolte un acelasi sistem informatic, una stiind de la nceput ca sistemul realizat va
fi auditat, iar cealalta aflnd ca sistemul informatic produs va fi auditat dupa ce l-a realizat n
forma finala, livrabila; desi echipele sunt la fel de performante, rapoartele de auditare vor
semnala diferente importante, numai raportul primei echipe fiind cu certitudine favorabil.
Toate aceste elemente creeaza un cadru favorabil nceperii activitatii echipei de audit sisteme
informatice.
Construirea listelor este o activitate complexa, deosebit de importanta. Listele trebuie sa fie
complete, sa includa toate elementele unei colectivitati. Este adevarat ca, daca lipsesc elemente,
se adauga sau se insereaza. Sau daca sunt incluse si elemente ale altor colectivitati, acestea sunt
sterse pentru a obtine liste complete. Listele trebuie sa fie, de asemenea, corecte, adica ordinea
de dispunere trebuie sa corespunda pozitiei sau importantei elementului.
Continutul textului care descrie sau defineste un element al listei trebuie sa fie clar, concis,
simplu, complet, sa genereze actiuni n succesiune logica, cu intrari si iesiri specificate. Toate
acestea trebuie sa impuna eliminarea din texte a acelor elemente generatoare de ambiguitati, de
solutii multiple, transformnd n acest fel un act de executie n act de decizie urmat de executie
n conditii de incertitudine. Aceste liste, planuri de activitate, pasi ai unor proceduri, tabele cu
caracteristici, nu sunt niste dogme. Ele se constituie n seturi de reguli de urmat. Exista si abateri,
dar abaterile nu se transforma n reguli.
Daca, n final, dintr-un numar de N elemente ale unei liste enumerative, 5-10% difera de forma
initiala, prin comunicare ntregul esafodaj se adapteaza n asa fel nct elementele nou introduse
sa-si gaseasca corespondent n celelalte liste. O astfel de abordare evidentiaza caracterul dinamic,
viu al procesului de auditare. Se produc ajustari din mers, toate avnd menirea de a mbunatati
procesul, iar transferul final de credibilitate sa fie real, sa aiba acoperire, validarea prin practica
sa ncununeze o munca tenace a echipei de auditare si nu invers, sa se constate
ca auditarea e un esec ireversibil. Listele trebuie sa contina elemente disjuncte pentru a reduce
ct mai mult posibil suprapunerile care sunt generatoare de confuzii si contradictii.
n medicina exista ghiduri care concentreaza experienta pozitiva, oferind dezvoltari de proceduri
pas cu pas pe care trebuie sa le urmareasca un medic n ambulatoriu. n acelasi fel trebuie
procedat si pentru audit. Existenta standardelor si a tehnicilor de auditare stau la baza construirii
de liste. Este important ca listele sa fie astfel elaborate nct sa nu lase loc
interpretarilor. Acumularea experientei permite gestionarea metodelor si standardelor de
auditare.
ntruct rezultatul auditarii este un produs oficial cu care se demonstreaza transferul de
credibilitate, toate elementele trebuie sa respecte strict standardele si tehnicile de auditare,
ntruct, n caz de forta majora, se face referire, rnd pe rnd, la articolele dupa care au fost
executate activitatile de auditare. Nu se executa nici o activitate daca nu figureaza n procedurile
standard de auditare. Daca se executa evaluari, mai nti sunt culese date si se fac prelucrari
pentru a calcula indicatorii din metodologiile recunoscute. n cazul n care se experimenteaza
componente suplimentare sau se demonstreaza ca unele proceduri noi, neincluse n standarde,
sunt superioare celor obligatorii, pe lnga cele obligatorii se executa si noile proceduri. La
rezultatele obligatorii se adauga noi rezultate, care vin sa ntareasca rezultatele obtinute prin
proceduri oficiale. n listele enumerate se face distinctie ntre tot ceea ce este obligatoriu si
pentru care exista proceduri rigide si tot ceea ce este suplimentar. Nu este vorba de optionalitate,
ci de prelucrari necesare, dar neobligatorii din punctul de vedere al beneficiarului raportului de
auditare. Acesti pasi suplimentari sunt obligatorii numai pentru auditori, ntruct sunt n sprijinul
procesului de auditare.
Exista prototipuri de sisteme informatice carora li s-au definit entitati distincte. Experienta
acumulata a condus la elaborarea de liste n format extrem de cuprinzator. Ele se constituie ca
punct de plecare n elaborarea de liste pentru sisteme informatice date, particulare n raport
cu un context definit. Principiile care stau la baza adaptarii listelor vizeaza elemente specifice
customizarii. Pornind de la un sistem informatic de baza foarte general, particularizarea ia n
considerare outputurile sistemului care se doreste a fi implementat. Din aproape n aproape,
folosind matricile de corespondenta ale sistemului derivat, prin reutilizare de componente,
pornind de la experienta acumulata, se preiau din listele generale acele elemente care sunt
specifice sistemului informatic ce face obiectul auditarii.
Aceste liste permit efectuarea unui audit total, care include, pe lnga sistemul informatic - produs
finit - si alte elemente ce dau substanta transferului de credibilitate. Caietul de sarcini reprezinta
o componenta exterioara procesului de realizare a sistemului informatic. n cazul n care acesta
contine suficiente detalii tehnice, se constituie n specificatiile de baza sau macrospecificatiile
sistemului informatic.
Macrospecificatiile sunt materia prima a construirii listelor enumerative, de derulare, de
prioritati, de caracteristici si de evaluare ale sistemului informatic.
Listele enumerative contin, dispuse unele dupa altele, componente omogene, precum numele
modulelor, numele fisierelor, numele entitatilor, numele parametrilor, codurile asociate
mesajelor, numele asociate
rapoartelor, parole de acces si rezultate ale evaluarilor. Listele enumerative se construiesc pe
masura ce se proiecteaza sistemul informatic si se actualizeaza pe masura ce se deruleaza etapele
de realizare ale sistemului informatic. Dinamica de continut a listelor enumerative da o imagine
suficient de clara n legatura cu echipa de designeri, privind experienta si, mai ales, gradul de
cuprindere si de detaliere de care aceasta a dat dovada.
Listele de derulare includ etape, activitati, operatii care trebuie parcurse ntr-o anumita ordine
pentru a atinge un anumit obiectiv. La fel ca n cazul gamei de operatii, sunt specificate
precedentele si, mai ales, restrictiile de ncepere, de continuare si de ncheiere. Listele de
derulare se dovedesc a fi corect elaborate cnd, pe masura ce se executa etape ale ciclului de
dezvoltare a sistemului informatic, nu sunt necesare interschimburi de pozitie si nici inserari de
noi elemente n liste. Listele de derulare concentreaza multa experienta si sunt elemente de start
n definirea de proceduri standard, asemanatoare celor din ghidurile de medicina pentru primul
ajutor, care trebuie respectate cu strictete pentru ca pacientul sa supravietuiasca.
Listele de prioritati reprezinta o forma concreta de manifestare a viziunii managerului de
proiect. Prioritatile vizeaza raportul dintre calitate si cantitate, modalitati de elaborare a criteriilor
de selectie a membrilor echipei de dezvoltare a sistemului informatic si stabilirea pozitiei pe care
o are managementul calitatii sistemului informatic. Prioritatile definite au caracter obligatoriu de
aplicabilitate. Fluctuatiile n timp sau pe compartimente n aplicarea prioritatilor au drept
consecinta determinata cresterea gradului de neomogenitate a componentelor sistemului
informatic.
Listele de caracteristici vizeaza extragerea dintr-o multitudine de caracteristici a acelora pe care
managerul proiectului le considera esentiale si pe care le urmareste pe toata durata procesului de
dezvoltare a sistemului informatic. Listele de caracteristici tin seama de destinatia sistemului
informatic.Orientarea sistemului informatic spre cerintele utilizatorului conduce la includerea cu
prioritate a caracteristicilor care vizeaza obtinerea unui singur nivel maxim de satisfactie la
nivelul beneficiarului, pe masura ce acesta exploateaza sistemul informatic. Pentru gestionarea
eficienta a resurselor companiei de informatica, lista include si caracteristici tehnice, interne ale
sistemului informatic. n cazul n care se schimba raportul caracteristicilor, n favoarea celor care
l privesc exclusiv pe dezvoltator, creste riscul de a obtine un sistem informatic pentru un
beneficiar ipotetic,
altul dect cel care plateste aceasta investitie, cu toate consecintele care vizeaza efectuarea de
corectii sau reluarea unor etape ale ciclului de elaborare, pe cheltuiala elaboratorului.
Listele de evaluare prezinta importanta att n procesul de elaborare, ct si n procesul de
auditare, ntruct creeaza premisele derularii mai nti a procesului de autoevaluare si dupa aceea
a procesului de evaluare. n conditii normale nu trebuie sa existe diferente semnificative ntre
autoevaluarea si, respectiv, evaluarea sistemului informatic sau a componentelor acestuia.
Transparenta construirii si utilizarii listelor are menirea de a crea unitate n echipa de auditare a
sistemului informatic. Cunoasterea completa a listelor estefundamentala pentru definirea
sarcinilor membrilor echipei de auditare. n dreptul fiecarui element din lista va fi trecut numele
unui membru din echipa de auditare. Se creeaza un nivel ridicat al responsabilizarii, ntruct att
calitatea, ct mai ales noncalitatea, trebuie asumata. Auditul sistemului informatic, ca
activitate ce se deruleaza dupa o schema ierarhizata pe niveluri, are la baza liste care conexeaza
elemente omogene detaliate cu rapoartele de sinteza, figura 5.4.
Este necesar ca n raportul de sinteza sa se faca referire directa la rapoartele de detaliu R1,
R2, ... , Rv si sa se efectueze prelucrarea datelor din aceste rapoarte pentru a obtine indicatori
agregati, care privesc un ansamblu printr-o descriere sintetica. Construirea listelor de liste
creeaza cadrul pe care se construiesc din aproape n aproape rapoartele, asa cum se prezinta,
schematic.
Includerea de rapoarte pe niveluri crescatoare de agregare conduce la completarea documentatiei
din aproape, n aproape.
Procesul de auditare se defineste ca mod de traversare a listelor de liste prin completarea cu
informatii specifice rapoartelor. Procedurile de agregare sunt standard. Esential este ca baza
privind procesul de auditare sa fie solida, bazata pe masuratori si pe analize foarte riguroase.
Construirea listelor reprezinta latura esentiala a procesului de auditare - planificare. Fara un plan
bine elaborat, articulat si fara o viziune unitara, rezultatul final este afectat de factori
perturbatori. Acesta este motivul pentru care, nainte de a ncepe auditarea propriu-zisa, se trece
la clarificarea tuturor aspectelor.
6. AUDITUL SPECIFICAIILOR
Specificatiile sistemului informatic, asemenea unei case, constituie temelia sistemului. De aceea
auditul sistemului trebuie sa nceapa cu auditul specificatiilor. Specificatiile au la baza surse
precum:
- legi si acte guvernamentale;
- norme de aplicare a unor acte oficiale;
- documentatii tehnice privind echipamentele de productie si auxiliare;
- documentele de creare si functionare a companiei;
- monografii, referate si prezentari;
vdocumente contabile si de patrimoniu;
- documente programatice: strategii si planuri pe termene diferite;
- rapoarte privind dinamica evolutiei;
- rapoarte privind conexiunile cu mediul de afaceri;
- documentatii privind publicitatea si definirea imaginii de piata;
- documentatia privind forta de munca;
- documentatia privind activitatile de cercetare, studiile de piata, activitatile sociale.
Auditul are menirea de a defini gradul de cuprindere al documentelor necesare dezvoltarii unor
specificatii complete, corecte si n concordanta cu obiectivul definit pentru sistemul informatic.
Se ntocmesc mai multe liste si tabele si anume:
- lista tipurilor de documente;
- listele claselor de documente apartinnd fiecarui tip;
- listele grupurilor de documente apartinnd fiecarei clase:
- tabelele de descriere cantitativa a elementelor care alcatuiesc grupurile; pentru fiecare grup se
defineste un tabel.
7. AUDITUL PROIECTULUI DE SISTEM INFORMATIC
Proiectul sistemului informatic este realizat pe baza specificatiilor. Cele mai multe dintre
proiecte sunt structurate pe subsisteme. Exista numeroase produse informatice complexe care,
printr-o buna parametrizare, genereaza un sistem informatic customizat, capabil sa raspunda
cerintelor companiei. Aceste produse au fost proiectate pentru functiile ntreprinderii. Se
specializeaza persoane care sa defineasca parametri pentru subsistemul de aprovizionare, pentru
subsistemul de productie, pentru subsistemul de desfacere, pentru subsistemul financiar-contabil
etc. Indiferent de metoda folosita, indiferent de mediul de dezvoltare utilizat, numai un proiect
bun are menirea de a dezvolta un sistem informatic operational. Metodele, tehnicile si
instrumentele au menirea de a usura munca, de a sistematiza informatii, de a minimiza
inconsistentele. Eforturile cele mai importante destinate definirii de entitati, gruparii acestora,
realizarea modulelor, specificarea conexiunilor, apartin designerilor sistemului informatic.
Pornind de la listele si tabelele rezultate din analiza specificatiilor se trece la studirea
proiectului. Un proiect de sistem informatic este dezvoltat pe mai multe niveluri.
Primul nivel, cu gradul de agregare cel mai ridicat, identifica subsistemele care intra n
componenta sistemului.
Al doilea nivel, corespunde unei detalieri mai accentuate, n care se disting partile ce alcatuiesc
subsistemele si fluxurile care au fost definite.
Al treilea nivel contine detalii de organizare a operatiilor si a operatorilor. Diagramele difera n
functie de modul n care este abordata solutionarea din punctul de vedere al tehnologiei abordate.
Gruparea operanzilor si operatorilor prezinta o importanta speciala ntruct influenteaza
definirile specifice implementarii algoritmilor de regasire a informatiei dupa una sau mai multe
chei.
Al patrulea nivel contine reprezentari suficient de detaliate care se constituie n specificatii de
programare.
Activitatea de auditare a proiectului trebuie sa traverseze toate cele patru niveluri de detaliere. Se
stabileste masura n care nivelul urmator este rezultatul direct al detalierii elementelor definite n
nivelul precedent. n cazul n care pe nivelul precedent sunt elemente nedetaliate pe nivelul
urmator sau detalii de pe nivelul curent nu au corespondent pe nivelul precedent, se semnaleaza
ca element de contradictie n proiect.
Daca specificatiile au un nivel de detaliere ridicat, proiectul sistemului informatic urmareste cu
mai mare precizie fiecare detaliu din specificatii, crendu-se premisa unei abordari ct mai
fidele.
n dezvoltarea unui proiect trebuie respectate o serie de reguli, iar procesul de auditare are
menirea de a analiza daca aceste reguli au fost respectate.
n primul rnd, variabila asociata unui factor este unica, pentru ca factorul este unic.
n al doilea rnd, un indicator are o singura expresie analitica. Doua expresii analitice apartin la
doi indicatori diferiti numai daca expresiile sunt diferite.
n al treilea rnd, un indicator este evaluat o singura data pentru un set de date. El nu va aparea
spre a fi evaluat cu acelasi set de date si ntr-o alta componenta a proiectului.
n al patrulea rnd, pentru regruparea tuturor datelor opereaza un singur criteriu. Introducerea
mai multor criterii de regrupare a datelor creeaza conditii favorabile cresterii riscului n
gestionare a redundantei n sistemul informatic care se dezvolta n etapele urmatoare. Criteriul
colectivitatii presupune existenta unor colectivitati omogene. Datele se grupeaza pentru
descrierea completa a elementelor din fiecare colectivitate. Criteriul evenimentelor prevede
definirea de activitati, resurse, momente si durate, iar datele se grupeaza strict pentru a defini
complet multimile de evenimente.
n al cincilea rnd, proiectul include componente care vizeaza operatii fundamentale precum
initializari, sortari, reutilari, concatenari, adaugiri, calcule, extrageri, regasiri, modificari, afisari,
actualizari, reorganizari etc.
n faza de definire a proiectului apar o serie de detalii privind:
- stabilirea domeniilor de variatie a variabilelor de intrare si domeniile variabilelor rezultative;
- dimensiunile seturilor de date;
- cheile de regasire a datelor;
- functiile de prelucrare care se dispun pe o structura arborescenta initiala;
- fluxurile de date;
- amplasarea punctelor de colectare a datelor n locuri precizate din companie;
- stabilirea nivelurilor de securitate pentru fiecare punct de colectare/extragere a datelor;
- definirea formatelor de prezentare a rezultatelor;
- stabilirea nivelului de validare a datelor de intrare;
- stabilirea arhitecturii pe care se dezvolta sistemul informatic;
- definirea echilibrului dintre outputurile imprimate si cele n format electronic;
- stabilirea modului de arhivare a informatiilor referitoare la perioade trecute de timp.
Se creeaza o imagine completa a produsului finit care, n final, va contine software, baze de date,
echipamente si va fi conectat prin fluxuri de informatii spre puncte de lucru prin accesare
conditionata.
Auditul acestui proiect ia n analiza toate aspectele. De exemplu, n cazul analizei sistemului de
parole se inventariaza punctele de acces care se amplaseaza la nivelul companiei.
Amplasamentul fizic este corelat si cu utilizarea. Posturile de lucru dedicate, restrictionate prin
anumite tipologii de acces, permit o buna disciplinare a utilizatorilor sistemului.
Fiecare utilizator are drept de acces la resursele sistemului numai n anumite puncte
de lucru. Se are n vedere apropierea de locul n care utilizatorul si desfasoara activitatea.
n mod curent, n practica, exista mai multe tipologii de parole de acces, n raport cu drepturile
asupra resurselor sistemului si anume:
- chei de acces total la dispozitia administratorului sistemului; acest tip de acces permite lucrul
pe componente, schimbarea drepturilor de acces pentru toti ceilalti utilizatori; administratorul
este cel care realizeaza interfata sistemului, inclusiv cu cei care asigura ntretinerea sa curenta;
- chei de acces la operatii de mare risc asupra bazei de date, precum operatiile nestandard,
corespunzatoare unor prelua ri accidentale, care presupun luarea unor decizii majore privind
sistemul de productie, operatii financiare;
- chei de acces pentru efectuarea unei singure operatii - adaugarea de informatie; ntruct fiecare
utilizator este specializat, prin introducerea parolei se produce si asocierea operatiei pentru
cmpul de prelucrat; de exemplu, parola unui vnzator atrage dupa sine asocierea cu operatia de
scadere din stoc a produselor vndute;
- chei de acces consultare ntreaga colectie de informatii, corespund unei categorii de utilizatori;
este vorba de utilizatorii care fac parte din echipa manageriala; ei au dreptul de a consulta numai
baza de date; unele aspecte fac obiectul consultari n grup;
- chei de acces pentru consultare partiala a bazelor de date; corespund unei largi categorii de
utilizatori;
- chei de acces la informatii de interes general, privesc indicatori agregati ai companiei;
- chei de acces personale care permit accesul strict la datele personale ale individului; fiecare
salariat are o astfel de cheie.
Accesul la informatia publica este liber. Auditul parolelor stabileste masura n care persoanele
din companie, n calitate de utilizatori, au o singura parola. Modul de distribuire a parolelor si de
gestionare a acestora constituie, de asemenea, obiectul auditului. Este important sa se defineasca
un sistem de parolare si gestiune a parolelor. n cazul n care se acorda o parola si utilizatorul si
defineste parola sa, se impune definirea unui alfabet propriu de construire a parolelor, astfel nct
prin regulile definite sa se asigure un nivel de securitate ridicat. Auditul sistemului de
parole este important prin modul cum califica protectia sistemului informatic fata de operatiile
accidentale.
Este important ca fiecarui utilizator sa-i fie analizata activitatea prin consemnarea:
- numarului de operatii efectuate zilnic;
- calitatea operarii de catre utilizator;
- numarul de incidente de prelucrare, diferentiat pe tipuri.
Exist a necesitatea ca proprietarul sistemului sa asigure un nivel de concordanta si o proportie
adecvata ntre structura sistemului informatic si capacit atile de acces la acestea n punctele de
lucru din companie. n cazul n care exista dezechilibre, apar fie posturi de lucru neutilizate, fie
fire de asteptare, cu efecte negative asupra proceselor din companie.
Faza de design a sistemului acorda nivelul de modernitate a acestuia. Daca echipa de designeri
sta pneste tendintele moderne de analiza si proiectare, solutia oferita este, de asemenea,
moderna. n caz contrar, se obtine o solutie veche, caracterizata printr-un mod rigid, hibrid si
neperformant de lucru.
n procesul de auditare a proiectului se urmareste masura n care designerii clarifica problematica
definirii de clase distincte si dezvolta atribuiri de resurse care nu genereaza ambiguitati.
Noile tehnici de proiectare includ numeroase instrumente care din start i asista pe designeri si i
orienteaza spre a asigura aceasta proprietate atunci cnd sunt construite perechi de clase, triplete
de clase sau chiar n cazul n care se dezvolta k-tuple de clase. si n cazul auditului proiectului,
documentatia este laborioasa si vizeaza n primul rnd laturile calitative ale solutiei adoptate.
Elementele cantitative sunt un suport real pentru calitatea proiectului, nsa, exista numeroase
modalitati de a compensa absenta lor n etapele urmatoare de dezvoltare a sistemului
informatic. Directia de dezvoltare o da calitatea arhitecturii definita prin proiect. Clase clar
definite,
operatii de agregare a claselor dispuse ntr-o arborescenta echilibrata, proceduri cu grad de
generalitate ridicat, sunt numai cteva din obiectivele pe care designerii trebuie sa le atinga.
Auditul de proiect de sistem are menirea de a constata gradul n care aceste obiective au fost
ndeplinite. Designerii construiesc matrice, liste, arbori. Aplicnd aceleasi principii, auditorii
identifica elemente lipsa, interschimbari de pozitii, elemente suplimentare, obtinnd matrice, liste
si arbori proprii care difera mai mult sau mai putin de constructiile designerilor sistemului
informatic. Se impune construirea unui indicator care sa reflecte gradul de asemanare dintre doua
matrice.
10. RAPORTUL DE AUDITARE
Procesul de auditare se finalizeaza cu ntocmirea unui raport care contine propuneri de masuri de
reducere si de mentinere sub control a riscurilor importante ale noii aplicatii. Raportul de
auditare este o lucrare de sinteza care are la baza o analiza a rezultatelor obtinute din parcurgerea
textelor sursa, din lansarea n executie a programelor si din interpretarea rezultatelor finale, mai
ales prin interpretarea rezultatelor intermediare si a celor de urmarire a programului.
Raportul de audit este o lucrare cuprinzatoare care ofera o imagine privind siguranta pe care o da
produsul. Raportul de audit are un rol esential n angajamentele de audit si asigurare, deoarece
comunica verdictul auditorului. Utilizatorii sistemului informatic se asteapta ca raportul
auditorului sa ofere ncredere n utilizarea sistemului informatic.
Raportul de audit este un element fundamental al auditarii prin intermediul caruia se prezinta
situatia sistemului auditat asa cum a fost evaluata de auditori. Prin raportul de audit sunt
communicate, partii auditate, aprecierile si concluziile auditorilor. Obiectivele raportului de audit
sunt:
- redarea ncrederii managerilor n sistemul informatic, imediat dupa terminarea misiunii de
audit;
- sa ofere redomandari utile referitor la perfectionarea procedurilor de control si eficienta
activitatii operative;
- sa asigure o nregistrare oficiala a activitatii de audit si a raspunsului managerilor.
n practica, nainte de a prezenta un raport formal, n scris, auditorul are obligatia de a prezenta
un raport verbal celor care raspund de activitatea analizata. Cu exceptia cazurilor de frauda,
cnd este necesar uneori ca lucrurile sa ramna secrete pna la prezentarea raportului oficial, n
majoritatea cazurilor auditorul discuta, n prealabil, cu managerul continutul raportului de audit.
n acest fel se reduce riscul ca rezultatele auditului sa nu fie acceptate de catre manager.
Raportul de auditare este un text structurat care contine:
- prezentarea contextului;
- rezultatul procesului de auditare;
- evaluarile finale;
- nregistrarile din fiecare etapa a procesului de auditare.
Raportul de auditare contine detalii privind:
- descrierea produsului;
- stabilirea conditiilor de utilizare normala;
- operatiile interzise a fi efectuate folosind produsul;
- functiunile pe care le dezvolta n conditii normale, indicnd intrarile, respectiv output-urile;
- efectele secundare care apar atunci cnd intrarile sunt complete si corecte;
- riscurile care apar atunci cnd intrarile sunt incomplete si incorecte;
- modalitati de reluare a procedurilor de utilizare.
Raportul de auditare arata ca produsul este utilizabil sau produsul devine utilizabil daca se
executa o serie de mbunatatiri.
Raportul de auditare trebuie astfel ntocmit astfel nct sa fie o imagine fidela a programului de
auditare, a resurselor, a input-urilor, a output-urilor si a metodelor utilizate.
Calitatea raportului este data de modul n care se construiesc componentele. Textul structurat se
alcatuieste pas cu pas prin raspunsuri scurte si clare la ntrebarile: cine? ce? cum? de ce? Este
obligatoriu ca raporul sa includa sectiuni care abordeaza gradat problematica de audit pentru un
sistem informatic.
Prima sectiune include elemente de identificare pentru:
- sistemul informatic ce face obiectul auditarii;
- baza n care se deruleaza procesul de auditare;
- prezentarea echipei de auditori;
- prezentarea elaboratorilor sistemului informatic;
- prezentarea beneficiarului procesului de auditare. A doua sectiune include elemente pentru:
- definirea obiectivului urmarit;
- stabilirea metodelor si tehnicilor stabilite si acceptate;
- structurarea procesului de auditare.
A treia sectiune defineste planul de auditare si conttine descrieri pentru:
- etapele care trebuie parcurse;
- resursele alocate fiecarei etape:
- fluxurile care se genereaza;
- nivelul de exigenta si moduri de mentinere constanta a nivelului;
- comunicarea ntre membrii echipei de auditori, comunicarea auditorilor cu realizatorii
sistemului informatic, cumunicarea cu beneficiarii procesului de auditare.
A patra sectiune contine detalierea tuturor surselor utilizate ca ntrebari pentru procesul de
auditare:
- contracte;
- specificatii;
- proiectul sistemului informatic;
- textele sursa;
- bazele de date;
- rezultatele testarii efectuate de echipa care a elaborat sistemul informatic;
- documentatii de proces;
- instrumente utilizate de catre echipa care a dezvoltat sistemul informatic.
Sunt descrise listele elementelor utilizate cu comentarii privind calitatea textelor ntrebuintate de
auditori.
Raportul de audit trebuie sa fie clar, concis, constructiv si ntocmit la timp.
Raportul de auditare reprezinta o proba importanta n orice actiune declansata de beneficiarul
unui sistem informatic atunci cnd sunt nregistrate diferente semnificative ntre ceea ce trebuia
sa execute sistemul informatic si ceea ce executa n realitate. Raportul de auditare trebuie sa fie
clar, concis, sa nu lase loc la interpretari.
Cnd se utilizeaza sintagma toate variantele nseamna ca pentru cele n noduri terminale ale
unei structuri arborescente au fost construite n seturi de date test, atingndu-se cele n noduri
terminale.
Raportul de auditare:
- enumera toate componentele;
- analizeaza toate variantele;
- include toate rezultatele;
- enumera situatiile pe categorii de stari, fara a lasa unele situatii neclarificate;
- trateaza cu aceeasi masura toate componentele;
- pentru fiecare situatie creata se enumera componentele identificate;
- utilizeaza pentru componentele aceluiasi nivel, aceleasi instrumente;
- este o constructie consistenta;
- include ipoteze, constatari, masuratori care, prin
- profesionalismul cu care se realizeaza, nu au fundamente pentru a fi contestate.
Transparenta procesului de auditare, rigurozitatea cu care sunt aplicate cerintele standardelor si
claritatea cu care se prezinta rezultatul auditarii da o singura directie destinatiei raportului si
anume acceptarea concluziilor, indiferent care sunt acestea, de catre cel care a solicitat auditul
sistemului informatic. Raportul de auditare trebuie sa fie convingator pentru a nu face obiectul
comentariilor. Trebuie sa contina descrierea unor aspecte evidente care nu fac obiectul
comentariilor sau negocierilor. Structura anuntata trebuie respectata, iar textul trebuie sa fie
consistent. O afirmatie facuta trebuie cel mult sustinuta. Ea nu trebuie nici nuantata, cu att mai
mult nu trebuie contrazisa.
Este determinant pentru un raport de auditare sa fie calitativ peste nivelul documentatiei,
specificatiilor sau oricarui alt text care provine de la elaboratorii sistemului informatic.
11. CONCLUZII
Auditul informatic reprezinta o ramura distincta a auditului. Aici se includ tehnici si metode de
auditare a software, a aplicatiilor informatice, a sistemelor informatice traditionale, a sistemelor
informatice moderne, a aplicatiilor mobile si a tuturor aplicatiilor informatice care utilizeaza
resurse Internet.
Pe masura cresterii complexitatii proceselor din societatea informationala, cerintele sistemelor
informatice impun un nivel de credibilitate deosebit de ridicat pe care numai auditul informatic l
sustine cu succes.
Pe timpul planificarii auditului informatic exista factori care se iau, n mod obligatoriu, n
considerare; acesti factori determina modul n care auditorul abordeaza procesul de auditare.
Auditorul va lua n considerare nivelul riscurilor generate de utilizarea sistemului informatic.
Auditul sistemelor informatice devine un punct focal al auditului independent, auditul
conformitatii si auditul operational. Realizarea auditului sistemului informatic contribuie la:
- mbunatatirea sistemului si controalelor procesului;
- prevenirea si detectarea erorilor si a fraudelor;
- reducerea riscurilor si mbunatatirea securitatii sistemului;
- planificarea pentru refacere n caz de accidente si dezastre;
- managementul informatiilor si dezvoltarii sistemului;
- evaluarea utilizarii eficiente a resurselor.
Auditorul sistemelor informatice trebuie sa aiba capacitatea de a asista echipa manageriala n
stabilirea marimii sistemului informatic si a numarului de personal necesar, domeniile de afaceri
n care se utilizeaza eficient sistemele de calcul, natura afacerilor, pierderi potentiale n cazul
caderii sistemului informatic, extinderea controalelor manuale si gradul de complexitate tehnica.
Auditul sistemelor informatice este o activitate complexa. Unei activitati de echipa - realizarea
sistemului informatic - i corespunde, de
asemenea, tot o activitate de echipa - auditarea. Pentru a realiza un proces de auditare eficient
este necesar sa se parcurga urmatorii pasi:
- definirea obiectului auditarii sistemului informatic;
- construirea planului de auditare;
- atribuirea sarcinilor fiecarui membru din echipa de auditori;
- preluarea structurilor de tabele pentru nregistrarea rezultatelor auditarii;
- derularea, pas cu pas, a procesului de auditare folosind standarde, tehnici si metode stabilite;
- nregistrarea rezultatelor si evaluarea fiecarei etape parcurse;
- regruparea documentatiei provenite din diferite stadi ale
- procesului de auditare si construirea raportului final. Exista doua rezultate pentru un produs
supus auditarii.
Primul caz, cel nefavorabil, corespunde situatiei n care procesul de auditare conduce la
concluzia ca exista diferente esentiale ntre sistemul informatic real si sistemul informatic
asteptat de utilizator; sistemul informatic nu executa integral functiile de prelucrare stabilite;
rapoartele obtinute sunt numai o parte din cele stabilite; auditorii recomanda completarea cu noi
module care sa dezvolte si prelucrarile planificate, dar nerealizate; diferentele care apar sunt
cauzate de rezultatele incomplete din raport; se recomanda completarea cu module care aduc
rapoartele la nivelul de completitudine necesar; diferentele se refera la modul de calcul al
indicatorilor; se recomanda modificari n secventele de program care fie ca includ toate
elementele de prelucrare, fie ca modifica criteriile de filtrare, fie modifica espresiile de evaluare;
daca sunt identificate cauze pe nivelurile superioare ale arborescentei asociate sistemului
informatic cerintele de modificare cerute n raportul de auditare au o profunzime mai mare. n
toate cazurile se precizeaza care sunt diferentele si se stabileste necesitatea de a fi eliminate sau
atenuate. Auditul nu da solutii. Raportul de auditare nu transfera credibilitate si de fapt esteraport
de constatare. Nu este rezonabil sa se ntocmeasca n acest context un raport de audit pentru ca
elaboratorul are la dispozitie un document prin care daca prezinta trunchiat informatia, lasa sa se
nteleaga ca sistemul informatic a fost auditat. Daca se prezinta rezultatul negativ al auditarii, se
subntelege ca auditarea a fost pozitiva. Elaboratorul de sistem informatic nu va fi acuzat pentru
ca nu a detaliat daca nu i s-a stabilit acest lucru. Dupa efectuarea modificarilor, n software, n
bazele de date, se reia procesul de auditare si raportul de constatare se
transforma n raport de auditare si se elibereaza un certificat de catre auditor, prin care se
recunosc calitatile sistemului informatic, iar utilizatorii trebuie sa aiba ncredere n sistemul
informatic auditat.
n cel de al doilea caz, favorabil, diferentele dintre ceea ce s-a asteptat de catre utilizator si ceea
ce s-a realizat sunt nesemnificative sau sunt favorabile cresterii calitatii produsului. Raportul de
auditare este o constructie complexa, dezvoltata de membrii echipei de auditare. Asemenea unei
carti organizate pe capitole, este o constructie arborescenta. Fiecare nod al arborescentei are o
informatie cu structura standard:
- obiectiv;
- input-uri, output-uri;
- continut, prelucrari;
- nregistrare rezultat analiza;
- evaluare proces;
- concluzii, calificare.
Agregarea se realizeaza de la baza spre radacina structurii arborescente. Raportul de
auditare este o constructie de maxima detaliere. Modul de abordare expus arata clar
care este diferenta ntre alte activitati si audit. Se observa clar ca auditul are ca rezultat o analiza,
o serie de evaluari si evidentierea cu maxima rigurozitate a diferentelor dintre sistemul
informatic solicitat de utilizator si descris n specificatiile convenite, pe de o parte, si sistemul
informatic aflat n forma livrabila, pe de alta parte.
Auditarea este solicitata de elaborator sau de beneficiar pentru a obtine acele informatii care dau
ncredere n utilizare, certitudinea ca rezultatele asteptate sunt corecte, complete, exact n
structura solicitata si se obtin n timp real.
Auditarea are menirea de a transfera certitudine si ncredere n sistemul informatic prin rezultatul
pozitiv stabilit de catre o echipa de auditori, apartinnd unei firme de consultanta cu autoritatea
data de auditari anterioare.
Managementul auditarii are particularitati specifice legate n principal de capacitatea auditorilor
de a nvata proceduri si, mai ales, de a aplica aceste proceduri n mod unitar.
Orice manifestare spontana sau de orgoliu aduce diferentieri de abordare care se concretizeaza
prin discrepante n a alege modele, n a culege date. Se reduce n acest fel comparabilitatea
datelor, iar agregarea
datelor se reduce pna la imposibilitatea de a opera cu seturi de date care privesc componentele
apartinnd aceleiasi clase.
Auditul unui sistem informatic presupune un volum important de munca ntruct se reface
ntregul traseu parcurs de echipa de realizatori a sistemului si, chiar mai mult, ntruct intra n
analiza nsasi specificatiile cu sursele pe baza carora au fost construite.
Efectul imediat al auditului sistemului informatic este folosirea lui cu ncredere daca rezultatul
auditarii ofera aceasta ncredere. Pentru echipa de dezvoltare a sistemului informatic, daca a
trecut de testul auditarii, se creeaza conditii favorabile dezvoltarii de noi sisteme informatice,
mult mai complexe.
n cazul n care sistemul informatic nu a trecut testul auditarii, apar serioase semne de ntrebare
legate de managementul companiei de software care a dezvoltat un astfel de sistem.
Trebuie sa apara schimbari majore la nivelul managementului si la nivelul echipelor de
dezvoltare. Trebuie adoptate tehnici de analiza, proiectare, programe testare, implementare,
mentenanta, eficiente care sa genereze fluxuri de dezvoltare compatibile.
Auditul presupune un mod activ de corectare a produsului, variante de lansare n uz curent daca
acest lucru se impune. Auditul este necesar pentru orice sistem informatic. Este normal
ca un sistem informatic neauditat, cnd genereaza erori, compania care utilizeaza sa plateasca
toate daunele. Lipsa auditului nseamna riscuri asumate. Riscurile nseamna costuri si costurile
trebuie suportate de catre cel care si-a asumat riscurile la un nivel care depaseste limite rationale.
Auditul este un proces optional pna la un punct. n conditiile software public, n care cetateanul
dezvolta procese de prelucrare n interes propriu, auditul devine o necesitate, devenind
obligatoriu. Obligativitatea este o masura de autoconservare a companiei care utilizeaza software
public pentru a derula servicii spre cetateni cu resurse proprii pentru a satisface cerinte ale
cetatenilor. O astfel de organizatie nu trebuie sa riste. Auditul nseamna transfer de ncredere si
mentinerea riscurilor la niveluri suportabile cu asigurarea unui nivel bun al profitabilitatii.
n conditiile societatii informationale, conectarea la o arhitectura de sisteme informatice auditate
a unui nou sistem este efectiva daca si numai daca sistemul care se conecteaza este auditat, iar
rezultatul auditarii permite conectarea. n caz contrar, efectele de antrenare multipla la nivelul
riscurilor devinde necontrolat.
Societatea informationala dezvolta o noua atitudine fata de audit. l considera un element esential
pentru construirea de arhitecturi software complexe de utilitate publica n regim continuu si fara
asistenta. Crearea civilizatiei bazata pe informatie obtinuta interactiv pleaca de la ideea
completitudinii si corectitudinii obtinerii informatiei. Pentru a avea costuri bune, sistemele
informatice trebuie sa utilizeze resursele la niveluri minime. Numai n procesul de auditare
rezulta ca a fost urmata calea spre minimizarea costurilor. Sunt argumente, sunt masuratori si
ntregul demers trebuie sustinut cu calcule de eficienta.
Auditul trebuie privit ca o investitie suplimentara. Compania de software care dezvolta un sistem
informatic si deruleaza procedee de audit creeaza premisele autoprotectiei fata de riscurile
generatoare de cheltuieli ce depasesc potentialul companiei.
Se creeaza o noua atitudine fata de auditul sistemelor informatice, fiind considerat altceva dect
o activitate impusa sau un rau necesar, transformndu-se n singura modalitate prin care se obtin
garantii reale asupra calitatii sistemului informatic, pe care utilizatorii le percep n timp.
Odata implementat, un sistem informatic este obligatoriu sa fie auditat periodic pentru a se
asigura ca ndeplineste toate sarcinile cerute la cel mai ridicat grad posibil de eficienta si
eficacitate. Cresterea organizatiei, cresterea volumului afacerilor, schimbarile n mediul
afacerilor, schimbarile tehnologice si noile cerinte de informatii toate plaseaza o cerere crescnda
asupra sistemului informatic existent si adeseori impun modificarea sau extinderea acestuia pe
baze ad-hoc.
Exemple ale unui audit de SI aflat n functiune:
- reevaluarea cerintelor de informatii;
- verificarea modificarilor propuse la proiectarile de baza existente;
- investigarea oportunitatii noilor tehnologii;
- mbunatatirea procedurilor de operare.
-
Din practica s-a constatat necesitatea auditarii unui sistem informatic odata la trei ani sau ori de
cte ori schimbarile aparute o impun.