UNIVERSITATEA XXXXXXXXXXXXXXXXXX FACULTATEA XXXXXXXXXXX

LUCRARE DE DIZERTATIE

Coordonator: Prof. Univ. Dr. XXXXXX

Autor: XXXXXXX

Bucuresti 2010

UNIVERSITATEA XXXXXXXXXXXXXXXXXX FACULTATEA XXXXXXXXXXX

Auditarea componentei financiar-contabile a sistemului informatic

Coordonator: Prof. Univ. Dr. XXXXXX

Autor: XXXXXXX

2

Bucuresti 2010

CUPRINS Introducere

Capitolul I Sistemele informatice si auditarea acestora. Caracteristici reprezentative1.1. 1.2. 1.3.

Obiectul auditului pentru sistemele informatice Integrarea printr-un sistem ERP Necesitatea auditarii unui sistem integrat

Capitolul II Standarde si tipuri de audit 2.1. Auditarea sistemelor integrate 2.2. Auditul specificatiilor 2.3. Auditul proiectului de sistem informatic

Capitolul III Studiu de caz privind procedurile auditului sistemului informatic financiar-contabil

3

Concluzii

Bibliografie

INTRODUCERE

Societatea informaional determin o cretere dramatic a dependenei tuturor domeniilor vieii economico-sociale de tehnnologiile informaionale. Sistemele informatice sunt construcii complexe care vizeaz mai multe probleme diferite ale unei companii. Avnd n vedere consumul de resurse umane i financiare la dezvoltarea unui sistem informatic, este necesar s se desfoare anumite activiti care s conduc la atingerea obiectivului propus, la timp, cu nivelul de calitate stabilit i n limita bugetului alocat. Una dintre aceste activiti, deosebit de important, att pentru realizatori, ct, mai ales, pentru utilizatori, este auditul sistemelor informatice (SI). Auditul SI este o ramur a auditului general care se ocup cu controlul tehnologiilor informaiilor i comunicaiilor. Auditul SI studiaz, n primul rnd, sistemele i reelele de calcul din punct de vedere al examinrii eficienei controlului tehnic i procedural pentru a minimiza riscurile. Auditarea SI presupune discuii cu personalul care stabilete specificaiile, dezvolt, testeaz, conduce, administreaz i utilizeaz sistemele de calcul. Obiectivul lucrrii l constituie realizarea unor cercetri comparative privind standardele europene utilizate in auditarea sistemelor informatice financiar contabile.

Auditul financiar este o component a reformei pe care sistemul financiar-contabil din Romnia trebuie s-l parcurg pentru a se alinia standardelor europene i el devine un serviciu foarte important pentru toate entitile economice. Este clar c Europa unit trebuie s vorbeasc aceeai limb n contabilitate. Subordonat acestor tendine, procesul de transformare a contabilitii romneti este n plin desfurare.4

Retratarea sistemului contabil nseamn, simplificnd la maximum, alinierea la standardele internaionale plus auditul financiar. Acesta va deveni treptat o component obligatorie a contabilitii societilor comerciale. Adevrul este c, fiecare administrator responsabil de activitatea pe care o desfoar unitatea pe care o conduce, n procesul de fundamentare a deciziilor pe baza crora se realizeaz managementul, are interesul legitim s cunoasc, n detaliu i n orice moment, starea patrimoniului. Pentru mediile organizaionale romneti, care au intrat n jocul integrrii, implementarea suitelor de aplicaii de ntreprindere (Enterprise Resource Planning - ERP) nseamn performan, eficien i controlul afacerii. Celelalte ezit nc, considernd integrarea un pas dificil, o decizie destul de greu de luat i nu n ultimul rnd, o investiie greu de amortizat. n cazul implementrii unui sistem integrat, procesul decizional este declanat de problemele care apar n colaborarea i interaciunea dintre departamentele organizaiei, mai precis din izolarea acestora. n principal, ERP presupune o politic care reflect ce nseamn s gndeti i s acionezi n sensul proceselor economice, fiind, de aceea, considerat o soluie strategic de management. Noul model de afacere, cu operaiuni orientate pe procese, sporete productivitatea i satisface cerinele de performan economic. Etapele operaionale economice trebuie s fie integrate, s pun n micare fluxuri de activiti, s controleze fluxurile de informaii i s eas conexiuni ntre organizaie, furnizori i clieni. Toate acestea presupun transformri organizaionale, optimizri tehnologice i, pn la urm, o nou identitate pentru ntreprinderi (redefinirea lor complet). Cunoatem complexitatea realizrii unui sistem informaional integrat ntr-o organizaie. Cifrele sunt relevante: 800-1000 procese economice, 8000-10000 de tabele de configurare ntrun ERP obinuit. Practic, implementarea se sprijin pe tehnici de reproiectare organizaional (Business Process Reenginering), Procesul presupune analiza unor factori importani, precum relaia dintre restructurare i adoptarea noilor aplicaii care, cel mai adesea, schimb radical modul de desfurare a activitii n cadrul organizaiilor. Dintre cele mai importante beneficii enunm: reducerea costurilor prin eficientizarea consumului de resurse (energie, ap, materii prime, for de munc, timp) i prin evitarea penalitilor (ntrzieri la pli, nerespectarea termenelor contractuale);

5

informaii de calitate i evitarea redundanei datelor i operaiunilor (baz de date unic); prevenirea i controlul riscurilor; anticiparea cerinelor legale i facilitarea conformrii cu acestea; mbuntirea mediului de lucru, motivarea, implicarea angajailor i munca n echip; mbuntirea imaginii i credibilitii pe pia (certificarea produselor); mbuntirea comunicrii interne i externe (dimensiunea colaborativ a relaiilor cu clienii, partenerii, furnizorii, autoritile), scderea timpului de rspuns datorit rapoartelor i informaiilor ad-hoc oferite de ctre sistem; deschiderea tehnologic (arhitectura sistemelor permite integrarea noilor tipuri de aplicaii e-business).

Toate aceste beneficii nu pot fi neglijate n sensul necesitii optimizrii proceselor economice i integrrii informaionale.

CAPITOLUL I

SISTEMELE INFORMATICE SI AUDITAREA ACESTORA. CARACTERISTICI REPREZENTATIVE

1.1.

Obiectul auditului pentru sistemele informatice

Auditul sistemelor informatice reprezint activitatea de colectare i evaluare a unor probe pentru a determina dac sistemul informatic este securizat, menine integritatea datelor prelucrate i stocate, permite atingerea obiectivelor strategice ale ntreprinderii i utilizeaz eficient resursele informaionale. n cadrul unei misiuni de audit a sistemului informatic cele mai frecvente operaii sunt verificrile, evalurile i testrile mijloacelor informaionale, astfel: - identificarea i evaluarea riscurilor din sistem;6

- evaluarea i testarea controlului din sistem; - verificarea i evaluarea fizic a mediului informaional; - verificarea i evaluarea administrrii sistemului informatic; - verificarea i evaluarea aplicailor informatice; - verificarea i evaluarea securitii reelelor de calculatoare; - verificarea i evaluarea planurilor i procedurilor de recuperare n caz de dezastre i continuare a activitii; - testarea integritii datelor. Auditul informatic reprezint o form esenial prin care se verific dac un SI i atinge obiectivul pentru care a fost elaborat. Standardele europene definesc clar domeniul, activitile, etapele, coninutul auditrii i formele de finalizare. Respectnd cerinele standardelor, rezultatul procesului de auditare informatic este eliberat de riscurile contestrii. Auditul informatic reprezint un domeniu cuprinztor n care sunt incluse toate activitile de auditare pentru : specificaii, proiecte, software, baze de date, procesele specifice ciclului de via ale unui program, ale unei aplicaii informatice, ale unui sistem informatic pentru management i ale unui portal de maxim complexitate, asociat unei organizaii virtuale. n domeniul informatic exist mai multe direcii de dezvoltare a auditului. Normele utilizate in acest sens si studiate pentru aceasta lucrare sunt: Legea Societatilor Comerciale nr. 31/1990 republicata, Legea Contabilitatii nr. 82/1991 republicata, Hotararea Guvernului privind prestarea serviciilor in domeniul contabilitatii verificarii si certificarii bilantului contabil nr. 483/1996, Normele de Audit si certificare a bilantului contabil, H.G. nr. 519/2000 privind auditul financiar, O.M.F. nr. 1752/2005 pentru aprobarea reglementarilor contabile conforme cu directivele europene completate si modificate cu O.M.F. nr. 2001/2006. Auditarea software const n activiti prin care se evideniaz gradul de concordan dintre specificaii i programul elaborat. Auditul software d msura siguranei pe care trebuie s o aib utilizatorul de programe atunci cnd obine rezultate. Sigurana se refer la corectitudinea i completitudinea rezultatelor finale atunci cnd datele de intrare sunt, de asemenea, corecte i complete. Auditul bazelor de date, este un domeniu de maxim complexitate avnd n vedere c, de regul, lucrul cu bazele de date presupune att datele ca

7

atare nsoite de relaiile create ntre ele, ct i programele cu care datele se gestioneaz. De aceea se impune efectuarea unei reparri. Auditul datelor vizeaz definirea acelor elemente prin care se stabilete msura n care datele stocate ndeplinesc cerinele de calitate: corectitudine, completitudine, omogenitate, comprehensibilitate, temporalitate, reproductibilitate. Pentru fiecare caracteristic exist o metric elaborat, iar auditorul de date trebuie s evalueze nivelul atins de caracteristic, pentru setul de date supus auditrii. n final, auditorul de date certific faptul c datele stocate n baze de date constituie intrri valabile pentru a obine rezultate corecte. n cazul auditrii riscului de gestiune a datelor stocate n baze de date se verific dac: programele refer corect cmpurile cu date stocate; - operaiile de prelucrare sunt cele din specificaii; - agregrile, sortrile, evalurile de expresii de extragere a subseturilor de date sunt n concordan cu specificaiile de obinere a rezultatelor ca structur, dimensiune i coninut. Auditul sistemelor informatice evalueaz riscurile unui mediu informatic sau ale unei aplicaii informatice, ca de exemplu calculul salariilor sau facturarea. Aceste misiuni se realizeaz alegnd, mpreun cu clientul, procesul de evaluare. Auditul informatic se poate referi la evaluarea riscurilor informatice ale securitii fizice, securitatea logic, managementul schimbrilor, planul de asisten etc. n cazul general, auditul informatic se refer la un ansamblu de procese informatice pentru a rspunde la o cerere precis a clientului. De exemplu, aprecierea disponibilitii informaiilor i a sistemului. n acest caz se controleaz care dintre procesele informatice rspund cel mai eficient la o asemenea cerere. n cazul disponibilitii, de exemplu, securitatea fizic i planul de continuitate. Auditul informatic poate, de asemenea, s evalueze aspecte strategice sau referitoare la calitatea sistemelor informatice. De exemplu, s verifice dac sistemul informatic al ntreprinderii rspunde n mod eficient la nevoile funciilor serviciului. Auditul mediului informatic se execut pentru a evalua riscurile sistemelor informatice necesare funcionrii aplicaiilor. De exemplu: securitatea fizic, securitatea logic, securitatea reelelor, plan de salvare. n urma auditrii, se ntocmete un raport n care sunt prezentate punctele slabe, nivelul de risc al acestora i msurile corective propuse. Analistul informatic are la dispoziie numeroase tehnici i metode pe care le adapteaz contextului. ntr-un fel este auditat un program de calcul statistic sau de optimizare i altfel este auditat o aplicaie care utilizeaz o baz de date. Pentru un sistem informatic complex exist metode adecvate de auditare, iar pentru aplicaiile web accentul auditrii este pus pe gradul de satisfacie a grupului int. Aplicaiile mobile au fundamente de auditare n care accentul este pus pe asigurarea continuitii, compatibilitii, accesibilitii rapide la resurse i, mai ales, asupra nivelului atins

8

de asigurarea securitii fluxurilor din ntregul sistem. De aceea, n cadrul procesului de audit informatic, planificarea i definirea metodei de audit este esenial. Alegerea unei metode neadecvate conduce la utilizarea de instrumente neadecvate, iar rezultatele auditului au caracter speculativ. Alegerea metodei presupune obinerea unor informaii privind contextul n care se deruleaz procesele legate de produsul software, de aplicaia informatic sau de sistemul informatic, obiecte ale auditrii. Auditul este, prin complexitatea sa, o activitate n care sunt luate n analiz legturile, implicaiile pe care le genereaz produsul software, aplicaia informatic sau sistemul informatic ntre dezvoltator - compania de software i utilizator. Raporturile trebuie privite din punct de vedere tehnic, financiar i juridic. Aspectul tehnic privete date de interior, algoritmi, rezultate, resurse folosite. Aspectul financiar vizeaz costul estimat al produsului software, aplicaie, sistem informatic i costul efectiv, modul n care s-au efectuat plile. Caracterul juridic al abordrii vizeaz obligaiile contractuale i legislaia din domeniul informatic. Toate aceste elemente conduc la stabilirea unor proceduri preliminare prin care sunt definite direciile de analiz, gradul de semnificaie pe care procesul de audit informatic l ofer i riscurile ca unele concluzii s fie infirmate de practica derulrii proceselor de utilizare curent a produsului software, a aplicaiei informatice sau a sistemului informatic n integralitatea lui. Pentru a realiza auditul informatic se definete planul de audit general i programul de audit. Structura planului i definirea programului sunt standard, presupunnd parcurgerea unor pai obligatorii. Specificitatea produsului software, a aplicaiei informatice sau a sistemului informatic i complexitatea acestora, determin efectuarea unor detalieri care difer de la un plan general la altul, respectiv de la un program de audit informatic la altul. Sarcinile care se includ n plan, ealonarea etapelor din program au elemente de variabilitate legate strict de structura i de diversitatea produselor informatice analizate. Standardele de auditare includ suficiente elemente astfel nct planul general i programul de audit s fie riguroase, fr ambiguiti i, mai ales, operaionale. nainte de a se trece la auditul informatic propriu-zis, datorit eforturilor ridicate de derulare i, mai ales, datorit riscurilor ca reproductibilitatea procesului de audit s fie afectat chiar de schimbrile care au loc n produsele informatice auditate, trebuie efectuate teste asupra mecanismelor de control i a mecanismelor de testare pe teste surs, pe specificaii, pe diagrame, pe documentaii, pe structuri de rezultate. Pentru a obine o reducere a nivelului estimat pentru riscul erorilor de analiz/control a produsului informatic n procesul de audit, printr-un proces iterativ se procedeaz la efectuarea de corecii asupra modalitilor n care se includ procedee tehnice, metode, modele de analiz/control a produselor informatice. Procesul iterativ se ntrerupe atunci cnd estimarea probabilitii ca rezultatele auditrii informatice s fie afectate de erori a atins un prag acceptabil. Auditul9

propriu-zis include proceduri analitice, teste, prin care se evideniaz diferenele dintre ceea ce s-a planificat a se realiza i ceea ce s-a realizat. Procedurile analitice au la baz contractele ncheiate ntre pri, minutele care detaliaz obiective, sarcinile ce revin partenerilor, specificaiile. Auditorul tehnic trebuie s ierarhizeze informaiile astfel nct s identifice punctele cheie care definesc procesul de analiz, proiectare, dezvoltare, testare, implementare a produsului informatic, fie c este vorba de un simplu program, fie c este vorba de o aplicaie informatic desktop sau n reea, fie c este vorba de un sistem informatic care vizeaz ntreaga activitate a unei organizaii. Toate procedurile analitice i textele de detaliere aplicate modulelor, programelor i sistemelor de programe, au menirea de a evidenia comportamentul, pas cu pas, a secvenelor de program. n cazul n care auditorul informatic are la baz pregtire de programator, tie s aleag din multitudinea de proceduri i texte cu caracter analitic, pe acelea care ofer informaia reprezentativ privind produsul software auditat, fie c este vorba de un modul, fie c este vorba de un sistem complex. Efortul de auditare este ridicat indiferent de complexitatea produsului auditat. Auditul se ncheie cu raport care are la baz o serie de verificri ale intercondiionrilor dintre module, dintre programe, respectiv dintre subsistemele sistemului informatic, pentru momentul t, considerat baz. Se verific modul de producere a evenimentelor care sunt concretizate prin succesiuni de prelucrri, corespunztoare momentului t + 1. n acest fel, produsul informatic, proiectat pentru derularea unor seturi de prelucrri, este analizat innd cont tocmai de succesiunea prelucrrilor. Auditul informatic are la baz nregistrri privind structura software, structura bazei de date, nregistrri ale lungimilor, volumului, complexitii i nregistrri complete asupra comportamentului n timpul execuiei. n cazul n care exist seturi de date cu care au fost testate produse informatice din aceeai clas cu produsul auditat acum, se colecteaz serii de date privind comportamentul produsului pentru a fi comparat cu produsele deja existente. Cnd nu exist date, sunt generate i testarea produsului se realizeaz simultan cu produse din aceeai clas, tocmai pentru a efectua analize i 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 soluie final, imparial, pentru a justifica ipotezele unei pri contractante, fie c este vorba de cumprtor de software, fie c este vorba de beneficiar, cnd acetia cred n dreptatea lor absolut. n general, auditul este descris ca Examinarea independent a nregistrrilor i a altor informaii n scopul formrii unei opinii referitoare la integritatea sistemului controalelor i mbuntirea controalelor recomandate pentru limitarea riscurilor.

10

Definiia conine termeni semnificativi ca:-

examinare; auditarea implic culegerea i evaluarea informaiilor factuale din surse variate; este important ca rezultatele procesului de auditare (raportul primar de audit care conine recomandri pentru mbuntirea controalelor) s fie urmrit pn la sursele de informaii valide;

-

independent; auditorii nu sunt implicai direct n operaii sau n managementul funciei care se auditeaz; subordonarea lor trebuie s le asigure exprimarea liber a opiniilor;

-

nregistrri i alte informaii; termenii includ ceea ce adeseori sunt numite inregistrri de audit; auditorii trebuie s se refere la informaii privind procesul afacerii i sistemele aflate n revizii aa cum sunt formele complete de intrri de date, rapoarte generate de sistem i, bineneles, personalul implicat n desfurarea sau conducerea proceselor afacerii auditate;

-

opinie; auditorii furnizeaz att fapte obiective ct i opinii subiective pe o situaie dat; dei subiective, opiniile lor sunt bazate pe interpretarea faptelor i sunt deschise discuiilor; se poate s nu se fie de accord cu aceste opinii, dar trebuie purtat o discuie complet i sincer; - integritate; termenul integritate include completitudine, acuratee i credibilitate; un control al unui sistem care este numai parial efectiv poate fi mai bun dect nimic, sau poate da un sens fals de securitate; auditorul va lua n considerare ambele ci;

-

recomandare; auditorii genereaz recomandri, dar nu au autoritatea nici s implementeze schimbrile sugerate, nici s impun managementului s fac schimbri; mbuntirile se obin numai printr-un proces de explicare, justificare i persuasiune, explicnd riscurile reprezentate de punctele slabe constatate n SI n urma auditrii, justificnd nevoia de schimbare n cadrul procesului i/sau sistemului i sugernd managementului necesitatea alocrii unor resurse i luarea de msuri pentru gestionarea riscurilor;

-

mbuntirea controalelor; mbuntirea sistemului de control nseamn, n general, adugarea controalelor care lipsesc; sunt foarte rare cazurile n care

11

auditorii pot recomanda eliminarea unor controale, n general, din cauz c ele sunt ineficiente, distrugtoare sau costisitoare; limite; ricurile i erorile pot fi reduse, dar nu pot fi complet eliminate; o bun activitate implic minimizarea riscurilor cu cheltuieli eficiente i pregtirea pentru aciune n cel mai ru caz posibil care s-ar putea produce (planificare pentru aciuni n caz de dezastre);-

risc; posibilitatea ca ceva s se desfoare ntr-o direcie nefavorabil; formal, riscul este posibilitatea combinrii ameninrilor cauzate fie de cineva cu intenii rele, fie din neglijen sau incompeten, acionnd asupra vulnerabilitilor sistemului; vulnerabilitile sunt punctele slabe ale sistemului care apar, n general, din cauza lipsei controalelor n sisteme de calcul i n proceduri de operare; manifestarea riscurilor poate genera, n anumite SI, rezultate catastrofale.

1.2.

Integrarea printr-un sistem ERP

Prin integrare, aplicaiile i datele trebuie combinate ntr-o abordare care s asigure mai mult dect accesul la informaii i procese economice. ERP promite soluii efective, eficiente i ofer companiei oportunitatea de a implementa o interfa comun, care s permit integrarea informaional a tuturor departamentelor i gestiunea fluxurilor de date, stabilind un mediu n care s poat fi adoptate viitoarele iniiative tehnologice, n condiiile remodelrii proceselor economice sau a definirii unora noi. Dincolo de promisiuni presupune, n primul rnd, elaborarea de planuri i stabilirea de metode i instrumente adecvate pentru trecerea de la aplicaii disparate la o platform unic. Integrarea informaional trebuie privit ca un proces continuu i ominvestiie strategic pe termen lung, deoarece beneficiile sale nu se arat imediat, ci n timp. Poate fi considerat ca o asigurare de via pentru sistemul informaional al ntreprinderii. Abordarea integrrii trebuie s fie realist i s in cont de dou mari alternative: integrarea intern - vizeaz procesele economice intra-organizaionale, acoperite prin suite ERP; integrarea extern - combin servicii de la mai muli furnizori pentru a susine12

gestiunea tranzaciilor extinse, schimbul de informaii, coordonarea i colaborarea de-a lungul lanului valoric extins (extinderea aplicaiilor tradiionale ERP cu mai noile aplicaii Customer Relationship Management, Supply Chain Management).

1.3.

Necesitatea auditarii unui sistem integrat

Aplicaiile ERP formeaz coloana vertebral a unei organizaii i sunt "responsabile" de datele, informaiile i cunotinele interne organizaionale, Nucleul acestui pachet de aplicaii are misiunea de a gestiona datele interne. Acestea sunt organizate n cadrul depozitelor de date, de unde sunt extrase i analizate prin intermediul sistemelor suport pentru decizii (Decision Support System), utiliznd instrumente de tip OLAP (On-Line Analytical Processing) sau OLTP (On-Line Transaction Processing). n ansamblu, depozitele de date furnizeaz arhitecturi i instrumente utile conducerii la vrf prin organizarea sistematic, ntelegerea i utilizarea datelor n adoptarea deciziilor strategice; n particular, sprijin procesarea informaiilor furniznd o platform solid de consolidare a datelor istorice pentru analiz. Operaional, sistemele integrate au caracteristici distincte i partajeaz cinci atribute eseniale :

asigur compatibilitatea tehnic i funcional a departamentelor; tehnologiile implicate n procesarea datelor sunt relativ transparente pentru utilizatori.

Integrarea poate fi realizat la orice nivel de desfurare a afacerii i cu orice tip de tehnologie. Cheia succesului const n alegerea celei mai bune tehnologii care onoreaz cu performan urmtoarele criterii: suportul oferit utilizatorilor, longevitatea tehnologic, adaptabilitatea, scalabilitatea i rapiditatea n livrarea soluiei: sistemele de aplicaii, datele, cile de acces la date i interfaa grafic utilizator sunt armonizate i standardizate pentru utilizatori; raionalitatea datelor ntreprinderii - datele au acelai statut n sisteme i module diferite, sunt definite coerent la nivel organizaional; toate aplicaiile de gestiune i mediile informatizate sunt scalabile, portabile i acoper multiple funciuni.

13

Din punct de vedere tehnologic, aplicaiile pot fi reconfigurate rapid n funcie de modificarea proceselor de afaceri i dovedesc flexibilitate. Codul i structura datelor suport modificri i reproduceri. Cele mai importante riscuri pe care i le asum organizaia sunt: volumul foarte mare al investiiilor iniiale; costuri ascunse semnificative; incertitudini legate de software i evoluia viitoare a tehnologiilor informaionale; responsabilitile sporite ncredinate personalului.

Dintre riscurile enunate cel mai greu de cuantificat sunt costurile ascunse, n principal, acestea cheltuindu-se cu pregtirea profesional i trainning-ul angajailor pe platforme. O alt pondere important este deinut de costurile personalizrii aplicaiilor.

CAPITOLUL 2

STANDARDE SI TIPURI DE AUDIT

2.1. Auditarea sistemelor integrate

Nu putem discuta despre o tradiie romneasc n domeniul evoluiei sistemelor informatice i cu att mai puin despre o practic anume a integrrii acestora. Dac ne propunem s discutm despre auditarea sistemelor informatice, de asemenea, trebuie s remarcm c, pn la mijlocul anului 2003, n Romnia nu s-a pus problema auditrii sistemelor

14

informaionale. Experii contabili i auditorii financiari autohtoni ar trebui s acopere i acest domeniu n timpul misiunilor lor n baza standardelor de audit adoptate. n majoritatea misiunilor de audit financiar autohtone intereseaz doar evaluarea raportrilor financiare i mai puin mijloacele prin care au fost obinute datele din acestea. n 2003 a fost emis Ordinul nr. 1077 privind condiiile n care se pot edita, ntr-un singur exemplar, facturile fiscale cu regim special de tiprire, nseriere i numerotare, utilizate n activitatea financiar i contabil. 1077 este primul act normativ care face referire la auditul sistemelor informaionale, chiar dac se limiteaz la auditarea Planului de securitate al unei companii de ctre un auditor CISA (Certified Information Systems Auditor). Altfel spus este un audit de conformitate, nu un audit de securitate! Al doilea act normativ (i ultimul) este Ordinul MCTI nr. 218 din 2004 privind procedura de avizare a instrumentelor de plat cu acces la distan, de tipul aplicaiilor Internetbanking, home-banking sau mobile-banking. i n acest caz este vorba de auditarea planului de securitate, dar se adaug i auditarea aplicaiei folosit n tranzaciile de tip mbanking. nainte de a continua, trebuie s facem o scurt meniune: primul act normativ (1077/2003) face doar o scurt trecere n revist a aspectelor ce trebuie urmrite n Planul de securitate, n timp ce la doilea (218/2004) chiar prezint o structur a unui astfel de document. Din punct de vedere legislativ la nivelul auditrii sistemelor informaionale aceasta este situaia din Romnia. Pentru c ERP-ul nu este corect neles, n multe implementri autohtone revizia i auditul unor astfel de sisteme nu sunt luate n calculul proiectului. Aceasta deoarece lipsesc cerinele legale precum cele din legea Sarbanes-Oaxley n SUA. Orice implementare ar avea impact asupra firmelor. Prin urmare, aceste implementri trebuie monitorizate i controlate pentru a fi siguri de succesul unui astfel de demers deoarece riscurile sunt mult mai mari dect n cazul aplicaiilor contabile, de salarizare sau de gestiune a mijloacelor fixe clasice. Argumente: 1. sistemele ERP folosesc date din diferite sectoare ale unei firme pentru a sprijini managementul interdepartamental i procesele firmei. Pentru a asigura succesul, astfel de sisteme trebuie s integreze n totalitate procesele i procedurile firmei; 2. companiile din statele membre UE au fost obligate, ca ncepnd cu 1 ianuarie 2005, s ntocmeasc raportrile financiar contabile n conformitate cu prevederile IAS. Mai mult, la ora actual se poart discuii intense ntre International Accounting Standards (IAS) i Federal15

Accounting Standards Board (FASB) pentru a se elimina diferenele dintre standardele emise de cele dou organizaii; 3. auditarea implementrilor ERP autohtone ar scoate n eviden n majoritatea cazurilor: slaba planificare a proiectelor auditul i revizia nefiind cuprinse n aceste proiecte, nu sunt cunoscute abilitile personale care ar trebui implicate ntr-un astfel de proces;

lipsa auditrii zonelor n care implementarea soluiilor ERP afecteaz controlul intern al organizaiei; competena profesionitilor contabili este probabil cel mai grav aspect. n majoritatea cazurilor, cei implicai n auditarea firmelor nu au cunotinele i abilitile necesare nelegerii unor astfel de sisteme. Auditarea se realizeaz exclusiv n jurul calculatorului;

slaba cunoatere a soluiilor existente i a tehnologiilor pe care se bazeaz acestea achiziionarea se face de cele mai multe ori fr a se ine cont de necesitile reale ale firmelor;

rapoartele de audit sunt considerate, de cele mai multe ori, doar simple certificate de bun purtare, recomandrile nefiind puse n practic.

n funcie de dimensiunea proiectului, urmtorii actori ar trebui s se implice n auditarea sistemelor ERP:

compartimentul de audit intern (compartiment impus de lege numai n cazul organizaiilor guvernamentale). n literatura de specialitate se precizeaz c acesta este compartimentul care cunoate cel mai bine starea sistemului implementat i zonele n care un sistem integrat va asigura succesul firmei. Auditorii interni trebuie s fac parte n mod obligatoriu din echipa care se ocup de implementare;

auditorii externi/independeni - chiar dac nu trebuie s aib cunotine despre fiecare soluie n parte, auditorii externi trebuie totui s dein un minimum de cunotine despre modul de funcionare al acestor sisteme;

implementatorul trebuie s cunoasc foarte bine soluia i s neleag procesele din firm pentru a oferi sprijin planificrii auditurilor. Realizeaz i audituri proprii pentru certificarea configuraiei soluiei;

departamentele funcionale managerii departamentali se ocup de particularitile implementrii, fiecare avnd responsabiliti n aria sa de decizie.

16

Pentru c sunt beneficiarii rapoartelor pe care le genereaz sistemul trebuie s se implice pe tot parcursul ciclului de via a soluiei;

conducerea executiv neimplicarea real a factorilor cu putere executiv este unul din principalii factori care conduc la eec n implementarea soluiilor ERP.

Succesul implementrii depinde de modulele sistemului integrat, de aceea auditarea ia n calcul i infrastructura sistemului informaional: 1. echipamentele (resursele hardware) fiecare soluie are propriile cerine de sistem, considerate minime pentru funcionarea pachetului integrat de aplicaii. Fiecare component a acestui puzzle contribuie la succes; 2. componentele de reea ERP se bazeaz 100% pe infrastructura reelei de comunicaii. n acest caz trebuie avute n vedere viteza i disponibilitatea liniilor de comunicaii, accesul la reea i liniile redundante prin care se asigur traficul n cazul apariiei unor evenimente neprevzute; 3. nomenclatoarele (fiierele de baz) de clieni, furnizori, personal, materiale, produse finite etc. reunesc toate datele de descriere a acestora i interfaeaz cu modulele aplicaiei. Auditarea trebuie s aib n vedere acurateea datelor; 4. pachetul de aplicaii auditarea are n vedere structura i funcionarea modulelor pachetului ERP:

parametrii de configurare: controalele la nivel de aplicaie, procedura de autorizare a utilizatorilor, configuraiile de securitate; securitatea modulelor i pe ansamblu a aplicaiei pentru a se asigura procesarea controlat i sigur a datelor; modificarea configuraiilor predefinite, standard pentru garantarea integritii proceselor; documentaia sistemului i help-ul de context ce sprijin utilizatorii; administrarea securitii informaiilor la nivelul organizaiei i maniera prin care pot fi identificate i eliminate/diminuate riscurile.

5. procesele auditul unui sistem ERP trebuie s ofere suficiente probe cu privire la integritatea proceselor implicate. Trebuie avute n vedere mai ales:

identificarea obiectivelor controalelor specifice proceselor implementate; identificarea i evaluarea riscurilor poteniale specifice proceselor implementate; proiectarea i implementarea controalelor care contribuie la eliminarea/diminuarea riscurilor identificate; verificarea funcionrii controalelor implementate;17

verificarea interfarii modulelor ERP cu aplicaii non-ERP; revizia planurilor de continuitate a afacerii.

6. angajaii rolurile ndeplinite de acetia sunt structurate n jurul soluiei implementate:

identificarea angajailor cu atribuii de conducere, a responsabilitilor i aptitudinilor necesare pentru a-i ndeplini sarcinile; necesarul de cursuri de instruire i maniera n care se realizeaz transferul de cunotine; clasificarea sarcinilor de serviciu.

7. strategia de implementare - tranziia de la vechiul sistem ar trebui fcut cu un impact minim asupra angajailor. n realitate implementarea unui sistem integrat genereaz un veritabil seism organizaional. Securitatea informaiilor poate fi afectat n timpul acestei tranziii, de aceea va fi aleas cea mai potrivit strategie. 2.2. Auditul specificatiilor

Specificaiile sistemului informatic, asemenea unei case, constituie temelia sistemului. De aceea auditul sistemului trebuie s nceap cu auditul specificaiilor. Specificaiile au la baz surse precum: legi i acte guvernamentale; norme de aplicare a unor acte oficiale; documentaii tehnice privind echipamentele de producie i auxiliare; documentele de creare i funcionare a companiei; monografii, referate i prezentri; documente contabile i de patrimoniu; documente programatice: strategii i planuri pe termene diferite; rapoarte privind dinamica evoluiei; rapoarte privind conexiunile cu mediul de afaceri; documentaii privind publicitatea i definirea imaginii de pia; documentaia privind fora de munc; documentaia privind activitile de cercetare, studiile de pia, activitile sociale.

18

Auditul are menirea de a defini gradul de cuprindere al documentelor necesare dezvoltrii unor specificaii complete, corecte i n concordan cu obiectivul definit pentru sistemul informatic. Se ntocmesc mai multe liste i tabele i anume: lista tipurilor de documente; listele claselor de documente aparinnd fiecrui tip; listele grupurilor de documente aparinnd fiecrei clase: tabelele de descriere cantitativ a elementelor care alctuiesc grupurile; pentru fiecare grup se definete un tabel. Fiecare list conine elemente sub form de texte structurate n triplete < xi , yi , zi > , i = 1, 2, ...ne, unde: xi - denumirea tipului, clasei sau grupului de pe poziia i a listei; yi - variabil egal cu 1 n cazul n care n dezvoltarea specificaiei au fost incluse elementele ca tipul, clasa, grupul i; n caz contrar se atribuie valoarea blanc; zi - variabil egal cu 1 n cazul n care n dezvoltarea specificaiei elementele specificate prin xi nu au fost folosite; n caz contrar se atribuie valoarea blanc; ne numrul elementelor din list. Sunt situaii n care, din motive de neclaritate, se combin funciile cu structurile companiei, rezultnd modaliti neomogene de agregare. Pentru a evita astfel de abordri, se construiete matricea MFS de coresponden funcii, subsisteme, avnd NFUN linii i NSS coloane, iar elementul mfsij arat c ntre funcia Fi i subsistemul SSj exist o legtur dac are valoare 1. n cazul n care se atribuie acestui element valoarea 0, rezult c nu exist o legtur direct ntre funcia Fi i subsistemul SSj. Se consider eroare situaia n care o linie din matrice sau o coloan are toate elementele nule. Situaia cea mai favorabil este cea n care unei funcii Fi i corespunde doar un subsistem SSj. nseamn c n companie fiecare subsistem realizeaz o singur funcie, sarcinile fiind foarte clar distribuite. Confuziile apar atunci cnd mai multe subsisteme au ca sarcin activiti corespunztoare aceleiai funcii. Confuzii apar i atunci cnd un subsistem realizeaz mai multe funcii i unele dintre funcii sunt distribuite mai multor subsisteme. Un exemplu ar fi subsistemul in care SS3 realizeaz activitile funciilor F1 i F3 , iar funcia F2 este distribuit19

subsistemelor SS1 i SS2, ceea ce complic procesul de auditare i de regsire a datelor din liste atunci cnd nu se menine un grad de redundan, pentru a plasa aceleai documente referitoare la o aceeai activitate de funcie pentru toate sistemele n care aceasta este gestionat. Printr-o reproiectare a legturilor subsistem funcii se amelioreaz distribuirea, nc nainte de a dezvolta sistemul informatic. Analistul are numai menirea de a consemna distribuirea difuz a sarcinilor pentru subsisteme. Se definete un algoritm pentru a analiza caracterul difuz sau bine definit al legturilor funcii subsisteme. Se construiete un indicator IDIF al difuziunii, care este 0 dac matricea MSF are toate elementele egale cu 1 i, respectiv, este egal cu 1 dac fiecrei funcii Fi i corespunde unul i numai unul dintre subsisteme, respectiv subsistemul SSj. 2.3. Auditul proiectului de sistem informatic

Proiectul sistemului informatic este realizat pe baza specificaiilor. Cele mai multe dintre proiecte sunt structurate pe subsisteme. Exist numeroase produse informatice complexe care, printr-o bun parametrizare, genereaz un sistem informatic customizat, capabil s rspund cerinelor companiei. Aceste produse au fost proiectate pentru funciile ntreprinderii. Se specializeaz persoane care s defineasc parametri pentru subsistemul de aprovizionare, pentru subsistemul de producie, pentru subsistemul de desfacere, pentru subsistemul financiar-contabil etc. Indiferent de metoda folosit, indiferent de mediul de dezvoltare utilizat, numai un proiect bun are menirea de a dezvolta un sistem informatic operaional. Metodele, tehnicile i instrumentele au menirea de a uura munca, de a sistematiza informaii, de a minimiza inconsistenele. Eforturile cele mai importante destinate definirii de entiti, gruprii acestora, realizarea modulelor, specificarea conexiunilor, aparin designerilor sistemului informatic. Pornind de la listele i tabelele rezultate din analiza specificaiilor 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, identific subsistemele care intr n componena sistemului. Al doilea nivel, corespunde unei detalieri mai accentuate, n care se disting prile ce alctuiesc subsistemele i fluxurile care au fost definite.

20

Al treilea nivel conine detalii de organizare a operaiilor i a operatorilor. Diagramele difer n funcie de modul n care este abordat soluionarea din punctul de vedere al tehnologiei abordate. Gruparea operanzilor i operatorilor prezint o importan special ntruct influeneaz definirile specifice implementrii algoritmilor de regsire a informaiei dup una sau mai multe chei. Al patrulea nivel conine reprezentri suficient de detaliate care se constituie n specificaii de programare. Activitatea de auditare a proiectului trebuie s traverseze toate cele patru niveluri de detaliere. Se stabilete msura n care nivelul urmtor este rezultatul direct al detalierii elementelor definite n nivelul precedent. n cazul n care pe nivelul precedent sunt elemente nedetaliate pe nivelul urmtor sau detalii de pe nivelul curent nu au corespondent pe nivelul precedent, se semnaleaz ca element de contradicie n proiect. Dac specificaiile au un nivel de detaliere ridicat, proiectul sistemului informatic urmrete cu mai mare precizie fiecare detaliu din specificaii, crendu-se premisa unei abordri ct mai fidele. n dezvoltarea unui proiect trebuie respectate o serie de reguli, iar procesul de auditare are menirea de a analiza dac aceste reguli au fost respectate. n primul rnd, variabila asociat unui factor este unic, pentru c factorul este unic. n al doilea rnd, un indicator are o singur expresie analitic. Dou expresii analitice aparin la doi indicatori diferii numai dac expresiile sunt diferite. n al treilea rnd, un indicator este evaluat o singur dat pentru un set de date. El nu va aprea spre a fi evaluat cu acelai set de date i ntr-o alt component a proiectului. n al patrulea rnd, pentru regruparea tuturor datelor opereaz un singur criteriu. Introducerea mai multor criterii de regrupare a datelor creeaz condiii favorabile creterii riscului n gestionare a redundanei n sistemul informatic care se dezvolt n etapele urmtoare. Criteriul colectivitii presupune existena unor colectiviti omogene. Datele se grupeaz pentru descrierea complet a elementelor din fiecare colectivitate. Criteriul evenimentelor prevede definirea de activiti, resurse, momente i durate, iar datele se grupeaz strict pentru a defini complet mulimile de evenimente. n al cincilea rnd, proiectul include componente care vizeaz operaii fundamentale precum iniializri, sortri, reutilri, concatenri, adugiri, calcule, extrageri, regsiri, modificri, afiri, actualizri, reorganizri etc.

21

Experiena n designul sistemului permite gruparea indicatorilor IS11, IS12, ..., ISNSS,INNSS i a variabilelor pe o structur ierarhizat, astfel nct la baza arborescenei se afl indicatorii cu cel mai redus nivel de agregare, iar la nivelul cel mai ridicat sunt indicatorii cei mai sintetici, profit, cifr de afaceri i rentabilitate. Modul n care se realizeaz regruparea indicatorilor este rezultatul analizei interdependenelor indicatori factori (inputuri), indicatori outputuri. Prezint o importan special asigurarea unui nivel ridicat de ortogonalitate n procesul de elaborare a structurii arborescente. Oricare este tehnologia de dezvoltare a sistemului informatic, structura arbore cerine rezultate al designerului de sistem creaz baza de ncapsulare separat a variabilelor i ncapsulare indicatori sau nencapsulare a variabilelor cu indicatorii. n primul caz se obin dou mulimi diferite de componente omogene, rezultat al ncapsulrii. n cel de al doilea caz se obine o singur mulime n care componentele sunt rezultatul ncapsulrii de variabile i indicatori. Analistul proiectului are menirea de a stabili dac structura arborescent este complet, are numrul de niveluri corect obinut. Carenele structurii sunt:

interschimbul de niveluri, n sensul c un indicator agregat devine indicator simplu sau invers; interschimbul pe acelai nivel, ceea ce antreneaz regruparea de variabile cu consecine directe asupra creterii numrului de variabile comune mai multor regrupri de date;

realizarea unor legturi incorecte ntre nivelul inferior i nivelul superior ale nodurilor arborescenei; n acest fel indicatorii agregai au ca inputuri indicatori simpli nenecesari sau pentru calculul indicatorilor agregai lipsesc indicatori simpli.

Se observ c n auditul proiectului sunt preluate numeroase elemente din specificaii. Elaboratorul sistemului informatic dispune de o echip de designeri de sistem care, prin modaliti eficiente de comunicare, dezvolt proiectul, verific de fiecare dat specificaiile cu cerinele reale ale utilizatorilor. n mod normal, ntre toate construciile existente n documentaie i ceea ce rezult n procesul de auditare, diferenele trebuie s fie nesemnificative. n realitate apar diferene care, dac nu semnificative, sunt diferene numeroase, genernd neconcordane, unele afectnd semnificativ utilizabilitatea sistemului informatic. Documentaia de auditare a proiectului de sistem informatic conine liste care permit22

agregarea de indicatori, conducnd n final la un singur indicator, care clasific proiectul ca fiind foarte bun, bun, satisfctor sau nesatisfctor. n faza de definire a proiectului apar o serie de detalii privind:

stabilirea domeniilor de variaie a variabilelor de intrare i domeniile variabilelor rezultative; dimensiunile seturilor de date; cheile de regsire a datelor; funciile de prelucrare care se dispun pe o structur arborescent iniial; 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 dezvolt sistemul informatic; definirea echilibrului dintre outputurile imprimate i cele n format electronic; stabilirea modului de arhivare a informaiilor referitoare la perioade trecute de timp.

Se creeaz o imagine complet a produsului finit care, n final, va conine software, baze de date, echipamente i va fi conectat prin fluxuri de informaii spre puncte de lucru prin accesare condiionat. Auditul acestui proiect ia n analiz toate aspectele. De exemplu, n cazul analizei sistemului de parole se inventariaz punctele de acces care se amplaseaz la nivelul companiei. Amplasamentul fizic este corelat i cu utilizarea. Posturile de lucru dedicate, restricionate prin anumite tipologii de acces, permit o bun 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 i desfoar activitatea. n mod curent, n practic, exist mai multe tipologii de parole de acces, n raport cu drepturile asupra resurselor sistemului i anume:

chei de acces total la dispoziia administratorului sistemului; acest tip de acces permite lucrul pe componente, schimbarea drepturilor de acces pentru toi ceilali utilizatori; administratorul este cel care realizeaz interfaa sistemului, inclusiv cu cei care asigur ntreinerea sa curent;

23

chei de acces la operaii de mare risc asupra bazei de date, precum operaiile nestandard, corespunztoare unor preluri accidentale, care presupun luarea unor decizii majore privind sistemul de producie, operaii financiare;

chei de acces pentru efectuarea unei singure operaii adugarea de informaie; ntruct fiecare utilizator este specializat, prin introducerea parolei se produce i asocierea operaiei pentru cmpul de prelucrat; de exemplu, parola unui vnztor atrage dup sine asocierea cu operaia de scdere din stoc a produselor vndute;

chei de acces consultare ntreaga colecie de informaii, corespund unei categorii de utilizatori; este vorba de utilizatorii care fac parte din echipa managerial; ei au dreptul de a consulta numai baza de date; unele aspecte fac obiectul consultri n grup;

chei de acces pentru consultare parial a bazelor de date; corespund unei largi categorii de utilizatori; chei de acces la informaii de interes general, privesc indicatori agregai ai companiei; chei de acces personale care permit accesul strict la datele personale ale individului; fiecare salariat are o astfel de cheie.

Accesul la informaia public este liber. Auditul parolelor stabilete msura n care persoanele din companie, n calitate de utilizatori, au o singur parol. Modul de distribuire a parolelor i de gestionare a acestora constituie, de asemenea, obiectul auditului. Este important s se defineasc un sistem de parolare i gestiune a parolelor. n cazul n care se acord o parol i utilizatorul i definete parola sa, se impune definirea unui alfabet propriu de construire a parolelor, astfel nct prin regulile definite s se asigure un nivel de securitate ridicat. Auditul sistemului de parole este important prin modul cum calific protecia sistemului informatic fa de operaiile accidentale. Este important ca fiecrui utilizator s-i fie analizat activitatea prin consemnarea: numrului de operaii efectuate zilnic; calitatea operrii de ctre utilizator; numrul de incidente de prelucrare, difereniat pe tipuri.

Exist necesitatea ca proprietarul sistemului s asigure un nivel de concordan i o proporie adecvat ntre structura sistemului informatic i capacitile de acces la acestea n punctele de lucru din companie. n cazul n care exist dezechilibre, apar fie posturi de lucru neutilizate, fie fire de ateptare, cu efecte negative asupra proceselor din companie.

24

Faza de design a sistemului acord nivelul de modernitate a acestuia. Dac echipa de designeri stpnete tendinele moderne de analiz i proiectare, soluia oferit este, de asemenea, modern. n caz contrar, se obine o soluie veche, caracterizat printr-un mod rigid, hibrid i neperformant de lucru.

25

CAPITOLUL 3

STUDIU DE CAZ PRIVIND PROCEDURILE AUDITULUI SISTEMULUI INFORMATIC FINANCIAR-CONTABIL

n desfurarea unei aciuni de audit, echipa de audit trebuie s aleag i s aplice acele proceduri de audit ce satisfac standardele de audit i n acelai timp s rspund obiectivelor auditului.

Efectuarea procedurilor de fond Pentru a detecta toate erorile i neregularitile eseniale din punct de vedere cantitativ, echipa de audit trebuie s se asigure c tehnicile i procedurile utilizate sunt suficiente i relevante i acestea pot fi utilizate n toate etapele auditului. Procedurile de fond reprezint testele efectuate de auditori pentru a obine probe de audit n scopul detectrii erorilor semnificative din situaiile financiare. Procedurile de fond sunt de dou tipuri: proceduri analitice i teste de fond. Pentru a evalua corect calitatea i corectitudinea funcionrii sistemelor informatice financiar contabile desfurate ntr-o entitate, i pentru a se pronuna asupra realitii i exactitii cu care au fost ntocmite situaiile financiare pentru perioada analizat, auditorii trebuie s fac o serie de investigaii:

26

a) Descrierea procedurilor n sistemul de culegere i prelucrare a datelor, cu scopul de a stabili, pentru fiecare domeniu semnificativ (achiziii de bunuri i servicii, stocri, producie, vnzri), care sunt procedurile folosite de societate pentru culegerea informaiilor, ntocmirea registrelor, prelucrarea datelor, nregistrarea operaiunilor din contabilitatea sintetic i analitic, n evidena cronologic i sistematic. Standardele Naionale de Contabilitate precizeaz: Documentele justificative care stau la baza nregistrrilor n contabilitate angajeaz rspunderea persoanelor care le-au ntocmit, vizat, aprobat sau nregistrat n contabilitate, aceast precizare se regsete i n legea contabilitii.1 Procedurile descriptive se bazeaz pe manualul de proceduri interne i chestionare de control intern la care rspund persoanele din interior ce au atribuii n acest sens. b) Testele de conformitate Testele de conformitate au rolul de a stabili dac procedurile descrise mai sus exist, indiferent dac ele se aplic sau nu. n aceast etap nu se pune problema descoperirii erorilor n funcionarea sistemului informatic financiar contabil, ci numai de a stabbili dac sistemul descris mai sus este, bineneles, cel real. c) Evaluarea preliminar (a riscului de erori) Dup ce s-a obinut o descriere a sistemului de culegere i prelucrare a datelor contabile n sistemul financiar, se procedeaz la o evaluare preliminar a fiabilitii acestei organizri pentru a putea pune n eviden punctele forte i punctele slabe ale procedurilor sistemului. n aceast etap se analizeaz dac sistemul este bine conceput, pentru a pune n eviden riscurile de concepie, urmnd ca n etapa urmtoare s verifice modul de funcionare a acestui sistem. Punctele forte sunt constituite din controale plasate n fluxul de prelucrare a datelor, care garanteaz o corect contabilizare a acestora. Punctele slabe sunt reprezentate de deficiene ale sistemului, care pot da natere unor riscuri de erori sau fraude. Auditorul va analiza dac:1

Legea 82/1991 a contabilitii, republicat, art 6

27

- dispozitivele de control ale ntreprinderii sunt efective i permanente (realitatea punctelor forte); - care sunt punctele slabe datorate conceperii defectuoase a sistemului; - care sunt punctele slabe datorate aplicrii greite a procedurilor (funcionrii sistemului). d) Teste de permanen Acestea urmresc dac procedurile sunt aplicate ntr-o manier permanent fr defeciuni. Aceste teste trebuie s fie suficient de mari pentru a oferi certitudini asupra modului de funcionare a sistemului. Pentru depistarea riscurilor n funcionarea sistemului se procedeaz la analiza controalelor de prevenire i a controalelor de detectare prevzute de ntreprindere.

Efectuarea i documentarea procedurilor analitice Auditorii concep i efectueaz proceduri de fond pentru a rspunde la evaluarea aferent cu privire la riscul de audit semnificativ la nivel de aseriune. Procedurile de fond aplicate de auditori la nivel de aseriune pot fi derivate din testele de detaliu, din procedurile analitice de fond, sau din combinarea ambelor. n conformitate cu Standardele Internaionale de Audit, procedurile analitice sunt utilizate n urmtoarele scopuri2:a) Ca proceduri de evaluare a riscului n vederea ob inerii unei n elegeri asupra

entit ii i a mediului; b) Ca proceduri de fond, atunci cnd utilizarea lor poate fi mai func ional i eficient dect testele detaliilor pentru reducerea riscului de audit la nivel de aser iune, la un nivel acceptabil sczut; c) Ca o revizuire general a sistemelor informatice si a situa iilor financiare la sfritul anului.

2

Standardele Internaionale de Audit nr. 520, paragraf 7

28

Procedurile analitice constituie un instrument util, care ajut auditorul s evalueze dac anumite cifre sunt rezonabile. Acestea sunt potrivite pentru categoriile de opeaiuni n care cifrele sunt uor de preliminat. Prima etap a unei proceduri analitice este aceea de a stabili diferena acceptabil dintre prognoza fcut de auditor i cifrele care apar n situaiile financiare. De asemenea, auditorul va ine cont de relaia dintre valoarea total a categoriei de operaiuni i baza materialitii, calculnd diferena acceptabil conform urmtoarei formule3: Diferen a acceptabil = Nivelul materialit ii x V (Valoarea categoriei de opera iuni/Rdcina ptrat din baza materialit ii)

Exemplu Un auditor stabilete nivelul materialitii la 450.000 euro pentru entitatea X. Cheltuielile totale n valoare de 50 milioane euro reprezint baza materialitii. Auditorul dorete s efectueze o revizuire analitic pentru categoria de operaiuni privind salariile personalului, care au o valoare de 40 mil euro. Calcul 40 mil. Euro (valoarea categoriei de operaiuni) mprit la 50 mil. Euro (baza materialitii) egal cu 0,8, din care auditorul extrage rdcina ptrat (0,8944). Apoi, nmulete acest rezultat cu nivelul materialitii (450.000 euro) obinnd diferena acceptabil de 402.292 euro.

A doua etap a unei proceduri analitice este aceea de a face o estimare. Auditorul trebuie s efectueze aceast procedur nainte de a cunoate valoarea care apare n situaiile financiare. De aceea prognoza pe care auditorul o realizeaz trebuie s rezulte din date independente de nregistrrile contabile. Rezult c n acest caz informaiile din surse din afara entitii sunt mai valoroase dect cele obinute din interior.

Curtea de Conturi a Romniei Manualul de Audit Financiar i Regularitate, Bucureti, 20033

29

Exemplu Dac auditorul verific o coal cu 150 cadre didactice angajate, care ctig 2000 euro pe an fiecare, atunci el se va atepta ca valoarea total a cheltuielilor cu salariile s fie 300.000 (150 x 2.000). Dac o entitate auditat colecteaz taxe locale de la populaie, atunci auditorul va fi n msur s estimeze care ar trebui s fie veniturile totale. Astfel, dac entitatea colecteaz 100 euro pentru fiecare apartament din zon i 150 euro pentru fiecare cas i sunt 20.000 apartamente i 5.000 de case atunci venitul ateptat va fi:

Numr Apartamente Case 20.000 5.000

Valoare 100 euro 150 euro

Total venituri 2.000.000 euro 750.000 euro 2.750.000 euro

A treia etap a procedurilor analitice este aceea de a compara prognoza cu valoarea contului. Aceasta constituie o operaie simpl pe care auditorul trebuie s o nregistreze n documentele de lucru, ulterior trebuind s evalueze dac cifrele efective se ncadreaz n limitele acceptabile, aceasta nsemnnd c diferena dintre prognoz i cifrele din cont este mai mic dect diferena acceptat. n situaia n care ne ncadrm ntre aceste limite auditorul are certitudinea c operaiunile verificate sunt n conformitate cu reglementrile n vigoare. Se accept doar o mic diferen ntre cifra real i cea estimat (toleran maxim de 1 procent) n situaia n care respectivele diferene nu pot avea explicaii adecvate. Dac cifrele se situeaz n afara limitelor auditorul trebuie s solicite explicaii punctuale. Va folosi ntrebri deschise precum: ce factori au afectat veniturile respective ?, i nu va ntreba de ce venitul rezultat este mai mare sau mai mic n acest an.

Exemplu Dac veniturile nregistrate n sistemul informatic financiar contabil aferente concesiunilor i nchirierilor persoanelor juridice sunt de 4.000.000 euro iar situaiile30

previzionate fuseser de 2.750.000 euro, atunci echipa de audit va cere explicaii pentru variaia de 1.250.000 euro. Sistemul infomatic ar trebui prevzut cu un sistem de atenionare asupra variaiei mari (de 45%). Dac ordonatorul de credite va explica echipei de audit c aceast cretere se datoreaz noilor spaii date n folosi n timpul anului, atunci echipa va trebui s afle cte spaii au fost construite i care a fost suprafaa disponibil nchiriat, precum i data nceperii ncasrii chiriilor. Considerente privind evaluarea procedurilor analitice i a testelor de control ale sistemului informatic:

Evaluarea procedurilor analitice

Dac procedurile analitice permit formularea unei previziuni n limitele unei diferene acceptabile, atunci auditorul poate s se bazeze pe asigurarea planificat. n cazul n care procedurile analitice nu indic o previziune n limitele auditorul diferenei trebuie s acceptabile, adopte atunci proceduri asigurarea planificat nu poate fi preluat iar alternative de audit menite s conduc la obinerea asigurrii planificate.

Evaluarea testelor de control

Dac auditorii constat c unele controale nu au funcionat corespunztor vor analiza posibilitatea testrii altor controale (alternative). n cazul n care nu se pot identifica controale alternative sau dac acestea se dovedesc ineficace, auditorul trebuie s revizuiasc planul de audit. n mod uzual, aceast situaie conduce la efectuarea unui volum sporit de proceduri directe de fond. Dac testele de control ale auditorului eueaz, asta nu nseamn n mod obligatoriu c exist erori bneti sau neregulariti n categoria de operaiuni testat.

31

De exemplu, dac nu se realizeaz o analiz a variaiei lunare a salariilor individuale aceasta nu nseamn neaprat c tatul de plat al salariilor pe acea lun este greit.

Raportul de audit

Raportul de audit trebuie sa cuprinda o exprimare clara a opiniei pe baza evaluarii concluziilor trase conform probelor obtinute in cursul auditului. Potrivit Standardului de audit nr. 700, Raportul de audit4, acesta trebuie sa contina in scris o exprimare clara a opiniei asupra situatiilor financiare considerate un tot unitar. Inainte de a incepe activitatea de redactare a raportului de audit nu este lipsit de interes sa se verifice arborele deciziei care ar nivelul sistemului forma: putea avea urmatoareainformatic Exista riscuri care pot genera depasirea marjei de eroare acceptate? (materialitatea) Evaluarea riscului la

DA

NU

Au fost utilizate controale interne pt reducerea riscurilor? DA NU Cu succes? DA NU

DA Cu succes? NU

Au fost utilizate controale interne? NU

DA Controale interne eficace Controale 4 Standardele Internationale de Audit, ISA 700 Raportul de audit (asigurare) interne eficace (asigurare) Proceduri de audit (teste) 32 Proceduri de audit (teste) Proceduri de audit (teste) Proceduri de audit (teste) standard

Pentru a selecta cele mai potrivite proceduri de audit, care sa fie utilizate pentru verificarea sistemului informatic financiar contabil, consideram ca auditorii ar trebui sa utilizeze arborele deciziei. Pornim de la evaluarea riscului pentru sistemul informatic in ansamblu precum si pentru fiecare modul in parte. In cazul in care au fost identificate riscul de erori semnificative, auditorii trebuie sa verifice controalele interne ale entitatii efectuate pentru prevenirea si diminuarea riscurilor. In cazul in care auditorii in urma evaluarii au constatat ca nu exista riscuri semnificative acestia trebuie sa examineze controalele interne relevante pentru a se asigura de un nivel corespunzator de incredere privind continutul datelor analizate prin sistemul informatic.

33

CONCLUZII

In urma analizei efectuate si a compararii standardelor europene utilizate in auditarea sistemelor informatice financiar contabile am constat o serie de elemente comune necesare a fi introduse si folosite in standardele romanesti. In acest sens auditul sistemelor informatice financiar contabile ar trebui sa fie:a)

usor de inteles trebuie sa se utilizeze un limbaj cat mai clar, simplu bineinteles in masura in care obiectivele auditului o permit. Formularea continutului raportului de audit trebuie sa fie accesibila celor carora li se adreseaza.

b)

lipsit de ambiguitate auditorul se va asigura ca toate constatarile sunt exprimate cu acuratete si nu lasa loc de interpretari, cel mai usor mod de a fi pe deplin inteles este acela de a folosi formule standard care sunt general acceptate.

34

c)

complet un audit trebuie sa cuprinda toate informatiile necesare pentru a satisface in primul rand obiectivele auditarii si apoi exigentele entitatii auditate.

d)

exact o prezentare corecta presupune descrierea cu acuratete a sferei de cuprindere a auditului si a metodelor folosite. O inexactitate aparuta in raportul de audit poate crea indoieli asupra validitatii integului raport si poate atrage atentia de la esenta raportului.

e)

obiectiv un raport de audit are o credibilitate considerabil mai mare daca probele de audit sunt prezentate intr-o maniera impartiala.

f)

convingator utilizatorul trebuie sa fie convins de realitatea constatarilor de rezonabilitatea concluziilor si de beneficiul aplicarii recomandarilor formulate.

g)

concis auditul trebuie sa fie concis si sa cuprinda concluzii si recomandari care sa sprijine probele prezentate.

Un raport de audit trebuie sa precizeze natura si intinderea lucrarii, a stadardelor internationale de audit IFAC si a Normelor de Audit Intern sau International pe baza carora s-au realizat aceste lucrari.

35

BIBLIOGRAFIE

1. Boulecu Mircea, Doina Fusaru, Zenovic Gherasim- Auditul Sistemelor Informatice Financiar- Contabile, Editura Tribuna Economic, 2005, Bucureti. 2. tefan Popa, Claudia Ionescu- Audit n medii informatizate, Editura Expert, 2005, Bucureti. 3. Ali Eden, Victoria Stnciu- Auditul Sistemelor informatice, Editura Dual Tech, 2004, Bucureti. 4. Munteanu A.- Auditul sistemelor informaionale contabile, Editura Polirom, 2001, Iai. 5. Andronie Maria- Analiza i Proiectarea sistemelor informatice de gestiune, Editura Fundaiei Romania de Maine, 2007, Bucureti. 6. O. Ray Whittington, Kurt Pany, Walter B. Meigs, Robert F. Meigs- Principles of Auditing, Tenth Edition, IRWIN Boston.

36

7. Jack J. Champlain- Auditing Information Systems, Second Edition, John Wiley & Sons, Inc. , 2003, USA. 8. Victor Munteanu- Control i Audit Financiar Contabil, Editura LUMINALEX, 2003, Bucureti. 9. Violeta Tataru Auditul financiar, Editura Cavallioti, 2007, Bucuresti 10. Renard Jacques Teoria si practica auditului intern, Ministerul Finantelor publice, 2004 11. Curtea europeana de conturi Standardele europene de audit ale Organizatiei Europene a Institutiilor Supreme de audit, 2002 12. Curtea europeana de conturi Liniile directoare europene de implementare a standardelor de audit INTOSAI, Curtea de Conturi a Romaniei, 2002

37