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 informatice si auditarea acestora. Caracteristici reprezentative
1.1.
Obiectul auditului pentru sistemele informatice
1.2.
Integrarea printr-un sistem ERP
1.3.
Necesita Necesitatea tea audit auditarii arii unui unui sistem sistem integrat 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 informaţională determină o creştere dramatică a dependenţei tuturor domeniilor vieţii economico-sociale de tehnnologiile informaţionale. Sistemele informatice sunt construcţii complexe care vizează mai multe probleme diferite ale unei companii. Având în vedere consumul de resurse umane şi financiare la dezvoltarea unui sistem informatic, este necesar să se desfăşoare anumite activităţi care să conducă la atingerea obiectivului propus, la timp, cu nivelul de calitate stabilit şi în limita bugetului alocat. Una dintre aceste activităţi, deosebit de importantă, atât pentru realizatori, cât, mai ales, pentru utilizatori, este auditul sistemelor informatice (SI) . Auditul SI este o ramură a auditului general care se ocupă cu controlul tehnologiilor informaţiilor şi comunicaţiilor. Auditul SI studiază, în primul rând, sistemele şi reţelele de calcul din punct de vedere al examinării eficienţei controlului tehnic şi procedural pentru a minimiza riscurile. Auditarea SI presupune discuţii cu personalul care stabileşte specificaţiile, dezvoltă, testează, conduce, administrează şi utilizează sistemele de calcul. Obiectivul lucrării îl constituie realizarea unor cercetări comparative privind standardele europene utilizate in auditarea sistemelor informatice financiar contabile.
Auditul financiar este o componentă a reformei pe care sistemul financiar-contabil din România trebuie să-l parcurgă pentru a se alinia standardelor europene și el devine un serviciu foarte important pentru toate entitățile economice. Este clar că Europa unită trebuie să vorbească aceeași limbă în contabilitate. Subordonat acestor tendin țe, procesul de transformare a contabilită ții românești este în plină desfă șurare. 4
Retratarea sistemului contabil înseamnă, simplificând la maximum, alinierea la standardele internaționale plus auditul financiar. Acesta va deveni treptat o componentă obligatorie a contabilită ții societă ților comerciale. Adevărul este că, fiecare administrator responsabil de activitatea pe care o desfă șoară unitatea pe care o conduce, în procesul de fundamentare a deciziilor pe baza cărora se realizează managementul, are interesul legitim să cunoască, în detaliu și în orice moment, starea patrimoniului. Pentru mediile organizaţionale româneşti, care au intrat în jocul integrării, implementarea suitelor de aplicaţii de întreprindere (Enterprise Resource Planning - ERP) înseamnă performanţă, eficienţă şi controlul afacerii. Celelalte ezită încă, considerând integrarea un pas dificil, o decizie destul de greu de luat şi nu în ultimul rând, o investiţie greu de amortizat. În cazul implementării unui sistem integrat, procesul decizional este declanşat de problemele care apar în colaborarea şi interacţiunea dintre departamentele organizaţiei, mai precis din izolarea acestora. În principal, ERP presupune o politică care reflectă ce înseamnă să gândeşti şi să acţionezi în sensul proceselor economice, fiind, de aceea, considerată o soluţie strategică de management. Noul model de afacere, cu operaţiuni orientate pe procese, sporeşte productivitatea şi satisface cerinţele de performanţă economică. Etapele operaţionale economice trebuie să fie integrate, să pună în mişcare fluxuri de activităţi, să controleze fluxurile de informaţii şi să ţeasă conexiuni între organizaţie, furnizori şi clienţi. Toate acestea presupun transformări organizaţionale, optimizări tehnologice şi, până la urmă, o nouă identitate pentru întreprinderi (redefinirea lor completă). Cunoaştem complexitatea realizării unui sistem informaţional integrat într-o organizaţie. Cifrele sunt relevante: 800-1000 procese economice, 8000-10000 de tabele de configurare întrun ERP obişnuit. Practic, implementarea se sprijină pe tehnici de reproiectare organizaţională (Business Process Reenginering), Procesul presupune analiza unor factori importanţi, precum relaţia dintre restructurare şi adoptarea noilor aplicaţii care, cel mai adesea, schimbă radical modul de desfăşurare a activităţii în cadrul organizaţiilor. Dintre cele mai importante beneficii enunţăm: •
reducerea costurilor prin eficientizarea consumului de resurse (energie, apă, materii prime, forţă de muncă, timp) şi prin evitarea penalităţilor (întârzieri la plăţi, nerespectarea termenelor contractuale);
5
•
informaţii de calitate şi evitarea redundanţei datelor şi operaţiunilor (bază de date unică);
•
prevenirea şi controlul riscurilor;
•
anticiparea cerinţelor legale şi facilitarea conformării cu acestea;
•
îmbunătăţirea mediului de lucru, motivarea, implicarea angajaţilor şi munca în echipă;
•
îmbunătăţirea imaginii şi credibilităţii pe piaţă (certificarea produselor);
•
îmbunătăţirea comunicării interne şi externe (dimensiunea colaborativă a relaţiilor
•
cu clienţii, partenerii, furnizorii, autorităţile), scăderea timpului de răspuns datorită
•
rapoartelor şi informaţiilor ad-hoc oferite de către sistem;
•
deschiderea tehnologică (arhitectura sistemelor permite integrarea noilor tipuri de
•
aplicaţii e-business).
Toate aceste beneficii nu pot fi neglijate în sensul necesităţii optimizării proceselor economice şi integrării informaţionale.
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, menţine integritatea datelor prelucrate şi stocate, permite atingerea obiectivelor strategice ale întreprinderii şi utilizează eficient resursele informaţionale. În cadrul unei misiuni de audit a sistemului informatic cele mai frecvente operaţii sunt verificările, evaluările şi testările mijloacelor informaţionale, astfel: - identificarea şi evaluarea riscurilor din sistem; 6
- evaluarea şi testarea controlului din sistem; - verificarea şi evaluarea fizică a mediului informaţional; - verificarea şi evaluarea administrării sistemului informatic; - verificarea şi evaluarea aplicaţilor informatice; - verificarea şi evaluarea securităţii reţelelor de calculatoare; - verificarea şi evaluarea planurilor şi procedurilor de recuperare în caz de dezastre şi continuare a activităţii; - testarea integrităţii datelor. Auditul informatic reprezintă o formă esenţială prin care se verifică dacă un SI îşi atinge obiectivul pentru care a fost elaborată. Standardele europene definesc clar domeniul, activităţile, etapele, conţinutul auditării şi formele de finalizare. Respectând cerinţele standardelor, rezultatul procesului de auditare informatică este eliberat de riscurile contestării. Auditul informatic reprezintă un domeniu cuprinzător în care sunt incluse toate activităţile de auditare pentru : specificaţii, proiecte, software, baze de date, procesele specifice ciclului de viaţă ale unui program, ale unei aplicaţii informatice, ale unui sistem informatic pentru management şi ale unui portal de maximă complexitate, asociat unei organizaţii virtuale. În domeniul informatic există mai multe direcţii 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 activităţi prin care se evidenţiază gradul de concordanţă dintre specificaţii şi programul elaborat. Auditul software dă măsura siguranţei pe care trebuie să o aibă utilizatorul de programe atunci când obţine rezultate. Siguranţa se referă la corectitudinea şi completitudinea rezultatelor finale atunci când datele de intrare sunt, de asemenea, corecte şi complete. Auditul bazelor de date, este un domeniu de maximă complexitate având în vedere că, de regulă, lucrul cu bazele de date presupune atât datele ca
7
atare însoţite de relaţiile create între ele, cât şi programele cu care datele se gestionează. De aceea se impune efectuarea unei reparări. Auditul datelor vizează definirea acelor elemente prin care se stabileşte măsura în care datele stocate îndeplinesc cerinţele 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 auditării. În final, auditorul de date certifică faptul că datele stocate în baze de date constituie intrări valabile pentru a obţine rezultate corecte. În cazul auditării riscului de gestiune a datelor stocate în baze de date se verifică dacă: programele referă corect câmpurile cu date stocate; - operaţiile de prelucrare sunt cele din specificaţii; - agregările, sortările, evaluările de expresii de extragere a subseturilor de date sunt în concordanţă cu specificaţiile de obţinere a rezultatelor ca structură, dimensiune şi conţinut. Auditul sistemelor informatice evaluează riscurile unui mediu informatic sau ale unei aplicaţii informatice, ca de exemplu calculul salariilor sau facturarea. Aceste misiuni se realizează alegând, împreună cu clientul, procesul de evaluare. Auditul informatic se poate referi la evaluarea riscurilor informatice ale securităţii fizice, securitatea logică, managementul schimbărilor, planul de asistenţă etc. În cazul general, auditul informatic se referă la un ansamblu de procese informatice pentru a răspunde la o cerere precisă a clientului. De exemplu, aprecierea disponibilităţii informaţiilor şi a sistemului. În acest caz se controlează care dintre procesele informatice răspund cel mai eficient la o asemenea cerere. În cazul disponibilităţii, 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 răspunde în mod eficient la nevoile funcţiilor serviciului. Auditul mediului informatic se execută pentru a evalua riscurile sistemelor informatice necesare funcţionării aplicaţiilor. De exemplu: securitatea fizică, securitatea logică, securitatea reţelelor, plan de salvare. În urma auditării, se întocmeşte un raport în care sunt prezentate punctele slabe, nivelul de risc al acestora şi măsurile corective propuse. Analistul informatic are la dispoziţie 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 aplicaţie care utilizează o bază de date. Pentru un sistem informatic complex există metode adecvate de auditare, iar pentru aplicaţiile web accentul auditării este pus pe gradul de satisfacţie a grupului ţintă. Aplicaţiile mobile au fundamente de auditare în care accentul este pus pe asigurarea continuităţii, compatibilităţii, accesibilităţii rapide la resurse şi, mai ales, asupra nivelului atins
8
de asigurarea securităţii fluxurilor din întregul sistem. De aceea, în cadrul procesului de audit informatic, planificarea şi definirea metodei de audit este esenţială. Alegerea unei metode neadecvate conduce la utilizarea de instrumente neadecvate, iar rezultatele auditului au caracter speculativ. Alegerea metodei presupune obţinerea unor informaţii privind contextul în care se derulează procesele legate de produsul software, de aplicaţia informatică sau de sistemul informatic, obiecte ale auditării. Auditul este, prin complexitatea sa, o activitate în care sunt luate în analiză legăturile, implicaţiile pe care le generează produsul software, aplicaţia informatică sau sistemul informatic între dezvoltator - compania de software şi utilizator. Raporturile trebuie privite din punct de vedere tehnic, financiar şi juridic. Aspectul tehnic priveşte date de interior, algoritmi, rezultate, resurse folosite. Aspectul financiar vizează costul estimat al produsului software, aplicaţie, sistem informatic şi costul efectiv, modul în care s-au efectuat plăţile. Caracterul juridic al abordării vizează obligaţiile contractuale şi legislaţia din domeniul informatic. Toate aceste elemente conduc la stabilirea unor proceduri preliminare prin care sunt definite direcţiile de analiză, gradul de semnificaţie pe care procesul de audit informatic îl oferă şi riscurile ca unele concluzii să fie infirmate de practica derulării proceselor de utilizare curentă a produsului software, a aplicaţiei informatice sau a sistemului informatic în integralitatea lui. Pentru a realiza auditul informatic se defineşte planul de audit general şi programul de audit. Structura planului şi definirea programului sunt standard, presupunând parcurgerea unor paşi obligatorii. Specificitatea produsului software, a aplicaţiei 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, eşalonarea etapelor din program au elemente de variabilitate legate strict de structura şi de diversitatea produselor informatice analizate. Standardele de auditare includ suficiente elemente astfel încât planul general şi programul de audit să fie riguroase, fără ambiguităţi şi, mai ales, operaţionale. Î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 schimbările care au loc în produsele informatice auditate, trebuie efectuate teste asupra mecanismelor de control şi a mecanismelor de testare pe teste sursă, pe specificaţii, pe diagrame, pe documentaţii, pe structuri de rezultate. Pentru a obţine 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 corecţii asupra modalităţilor în care se includ procedee tehnice, metode, modele de analiză/control a produselor informatice. Procesul iterativ se întrerupe atunci când estimarea probabilităţii ca rezultatele auditării informatice să fie afectate de erori a atins un prag acceptabil. Auditul 9
propriu-zis include proceduri analitice, teste, prin care se evidenţiază diferenţele dintre ceea ce s-a planificat a se realiza şi ceea ce s-a realizat. Procedurile analitice au la bază contractele încheiate între părţi, minutele care detaliază obiective, sarcinile ce revin partenerilor, specificaţiile. Auditorul tehnic trebuie să ierarhizeze informaţiile astfel încât 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 aplicaţie informatică desktop sau în reţea, fie că este vorba de un sistem informatic care vizează întreaga activitate a unei organizaţii. Toate procedurile analitice şi textele de detaliere aplicate modulelor, programelor şi sistemelor de programe, au menirea de a evidenţia comportamentul, pas cu pas, a secvenţelor de program. În cazul în care auditorul informatic are la bază pregătire de programator, ştie să aleagă din multitudinea de proceduri şi texte cu caracter analitic, pe acelea care oferă informaţia 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 verificări ale intercondiţionărilor 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 prelucrări, corespunzătoare momentului t + 1. În acest fel, produsul informatic, proiectat pentru derularea unor seturi de prelucrări, este analizat ţinând cont tocmai de succesiunea prelucrărilor. Auditul informatic are la bază înregistrări privind structura software, structura bazei de date, înregistrări ale lungimilor, volumului, complexităţii şi înregistrări complete asupra comportamentului în timpul execuţiei. În cazul în care există seturi de date cu care au fost testate produse informatice din aceeaşi clasă cu produsul auditat acum, se colectează serii de date privind comportamentul produsului pentru a fi comparat cu produsele deja existente. Când nu există date, sunt generate şi testarea produsului se realizează simultan cu produse din aceeaşi 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 soluţie finală, imparţială, pentru a justifica ipotezele unei părţi contractante, fie că este vorba de cumpărător de software, fie că este vorba de beneficiar, când aceştia cred în dreptatea lor absolută. În general, auditul este descris ca Examinarea independentă a înregistrărilor şi a altor informaţii în scopul formării unei opinii referitoare la integritatea sistemului controalelor şi îmbunătăţirea controalelor recomandate pentru limitarea riscurilor.
10
Definiţia conţine termeni semnificativi ca: -
examinare;
-
auditarea implică culegerea şi evaluarea informaţiilor factuale din surse variate; este important ca rezultatele procesului de auditare (raportul primar de audit care conţine recomandări pentru îmbunătăţirea controalelor) să fie urmărit până la sursele de informaţii valide;
-
independent; auditorii nu sunt implicaţi direct în operaţii sau în managementul funcţiei care se auditează; subordonarea lor trebuie să le asigure exprimarea liberă a opiniilor;
-
înregistrări şi alte informaţii; termenii includ ceea ce adeseori sunt numite “inregistrări de audit”; auditorii trebuie să se refere la informaţii privind procesul afacerii şi sistemele aflate în revizii aşa cum sunt formele complete de intrări de date, rapoarte generate de sistem şi, bineînţeles, personalul implicat în desfăşurarea sau conducerea proceselor afacerii auditate;
-
opinie; auditorii furnizează atât fapte obiective cât şi opinii subiective pe o situaţie dată; deşi subiective, opiniile lor sunt bazate pe interpretarea faptelor şi sunt deschise discuţiilor; se poate să nu se fie de accord cu aceste opinii, dar trebuie purtată o discuţie completă şi sinceră; - integritate; termenul integritate include completitudine, acurateţe şi credibilitate; un control al unui sistem care este numai parţial efectiv poate fi mai bun decât nimic, sau poate da un sens fals de securitate; auditorul va lua în considerare ambele căi;
-
recomandare; auditorii generează recomandări, dar nu au autoritatea nici să implementeze schimbările sugerate, nici să impună managementului să facă schimbări; îmbunătăţirile se obţin numai printr-un proces de explicare, justificare şi persuasiune, explicând riscurile reprezentate de punctele slabe constatate în SI în urma auditării, justificând nevoia de schimbare în cadrul procesului şi/sau sistemului şi sugerând managementului necesitatea alocării unor resurse şi luarea de măsuri pentru gestionarea riscurilor;
-
îmbunătăţirea controalelor; îmbunătăţirea sistemului de control înseamnă, în general, adăugarea controalelor care lipsesc; sunt foarte rare cazurile în care
11
auditorii pot recomanda eliminarea unor controale, în general, din cauză că ele sunt ineficiente, distrugătoare 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 pregătirea pentru acţiune în cel mai rău caz posibil care s-ar putea produce (planificare pentru acţiuni în caz de dezastre);
-
risc; posibilitatea ca ceva să se desfăşoare într-o direcţie nefavorabilă; formal, riscul este posibilitatea combinării ameninţărilor cauzate fie de cineva cu intenţii rele, fie din neglijenţă sau incompetenţă, acţionând asupra vulnerabilităţilor sistemului; vulnerabilităţile 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, aplicaţiile şi datele trebuie combinate într-o abordare care să asigure mai mult decât accesul la informaţii şi procese economice. ERP promite soluţii efective, eficiente şi oferă companiei oportunitatea de a implementa o interfaţă comună, care să permită integrarea informaţională a tuturor departamentelor şi gestiunea fluxurilor de date, stabilind un mediu în care să poată fi adoptate viitoarele iniţiative tehnologice, în condiţiile remodelării proceselor economice sau a definirii unora noi. Dincolo de promisiuni presupune, în primul rând, elaborarea de planuri şi stabilirea de metode şi instrumente adecvate pentru trecerea de la aplicaţii disparate la o platformă unică. Integrarea informaţională trebuie privită ca un proces continuu şi ominvestiţie strategică pe termen lung, deoarece beneficiile sale nu se arată imediat, ci în timp. Poate fi considerat ca o „asigurare de viaţă” pentru sistemul informaţional al întreprinderii. Abordarea integrării trebuie să fie realistă şi să ţină cont de două mari alternative: •
integrarea internă - vizează procesele economice intra-organizaţionale, acoperite prin suite ERP;
•
integrarea externă - combină servicii de la mai mulţi furnizori pentru a susţine 12
gestiunea tranzacţiilor extinse, schimbul de informaţii, coordonarea şi colaborarea de-a lungul lanţului valoric extins (extinderea aplicaţiilor tradiţionale ERP cu mai „noile” aplicaţii Customer Relationship Management, Supply Chain Management).
1.3.
Necesitatea auditarii unui sistem integrat
Aplicaţiile ERP formează coloana vertebrală a unei organizaţii şi sunt "responsabile" de datele, informaţiile şi cunoştinţele interne organizaţionale, Nucleul acestui pachet de aplicaţii 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), utilizând 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 vârf prin organizarea sistematică, întelegerea şi utilizarea datelor în adoptarea deciziilor strategice; în particular, sprijină procesarea informaţiilor furnizând o platformă solidă de consolidare a datelor istorice pentru analiză. Operaţional, sistemele integrate au caracteristici distincte şi partajează cinci atribute esenţiale : •
asigură compatibilitatea tehnică şi funcţională a departamentelor;
•
tehnologiile implicate în procesarea datelor sunt relativ transparente pentru utilizatori.
Integrarea poate fi realizată la orice nivel de desfăşurare a afacerii şi cu orice tip de tehnologie. Cheia succesului constă în alegerea celei mai bune tehnologii care onorează cu performanţă următoarele criterii: suportul oferit utilizatorilor, longevitatea tehnologică, adaptabilitatea, scalabilitatea şi rapiditatea în livrarea soluţiei: •
sistemele de aplicaţii, datele, căile de acces la date şi interfaţa grafică utilizator sunt armonizate şi standardizate pentru utilizatori;
•
raţionalitatea datelor întreprinderii - datele au acelaşi statut în sisteme şi module diferite, sunt definite coerent la nivel organizaţional;
•
toate aplicaţiile de gestiune şi mediile informatizate sunt scalabile, portabile şi
•
acoperă multiple funcţiuni.
13
Din punct de vedere tehnologic, aplicaţiile pot fi reconfigurate rapid în funcţie de modificarea proceselor de afaceri şi dovedesc flexibilitate. Codul şi structura datelor suportă modificări şi reproduceri. Cele mai importante riscuri pe care şi le asumă organizaţia sunt: •
volumul foarte mare al investiţiilor iniţiale;
•
costuri ascunse semnificative;
•
incertitudini legate de software şi evoluţia viitoare a tehnologiilor informaţionale;
•
responsabilităţile sporite încredinţate personalului.
Dintre riscurile enunţate cel mai greu de cuantificat sunt costurile ascunse, în principal, acestea “cheltuindu-se” cu pregătirea profesională şi trainning-ul angajaţilor pe platforme. O altă pondere importantă este deţinută de costurile personalizării aplicaţiilor.
CAPITOLUL 2
STANDARDE SI TIPURI DE AUDIT
2.1. Auditarea sistemelor integrate
Nu putem discuta despre o tradiţie românească în domeniul evoluţiei sistemelor informatice şi cu atât mai puţin despre o practică anume a integrării acestora. Dacă ne propunem să discutăm despre auditarea sistemelor informatice, de asemenea, trebuie să remarcăm că, până la mijlocul anului 2003, în România nu s-a pus problema auditării sistemelor
14
informaţionale. Experţii 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 raportărilor financiare şi mai puţin mijloacele prin care au fost obţinute datele din acestea. În 2003 a fost emis Ordinul nr. 1077 privind condiţiile în care se pot edita, într-un singur exemplar, facturile fiscale cu regim special de tipărire, înseriere şi numerotare, utilizate în activitatea financiară şi contabilă. 1077 este primul act normativ care face referire la auditul sistemelor informaţionale, chiar dacă se limitează la auditarea Planului de securitate al unei companii de către 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 aplicaţiilor Internet banking, home-banking sau mobile-banking. Şi în acest caz este vorba de auditarea planului de securitate, dar se adaugă şi auditarea aplicaţiei folosită în tranzacţiile de tip mbanking. Înainte de a continua, trebuie să facem o scurtă menţiune: primul act normativ (1077/2003) face doar o scurtă trecere în revistă a aspectelor ce trebuie urmărite î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 auditării sistemelor informaţionale aceasta este situaţia din România. Pentru că ERP-ul nu este corect înţeles, în multe implementări autohtone revizia şi auditul unor astfel de sisteme nu sunt luate în calculul proiectului. Aceasta deoarece lipsesc cerinţele legale precum cele din legea Sarbanes-Oaxley în SUA. Orice implementare ar avea impact asupra firmelor. Prin urmare, aceste implementări trebuie monitorizate şi controlate pentru a fi siguri de succesul unui astfel de demers deoarece riscurile sunt mult mai mari decît în cazul aplicaţiilor 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 începînd cu 1 ianuarie 2005, să întocmească raportările financiar contabile în conformitate cu prevederile IAS. Mai mult, la ora actuală se poartă discuţii intense între International Accounting Standards (IAS) şi Federal 15
Accounting Standards Board (FASB) pentru a se elimina diferenţele dintre standardele emise de cele două organizaţii; 3. auditarea implementărilor ERP autohtone ar scoate în evidenţă în majoritatea cazurilor: •
slaba planificare a proiectelor – auditul şi revizia nefiind cuprinse în aceste proiecte, nu sunt cunoscute abilităţile personale care ar trebui implicate într-un astfel de proces;
•
lipsa auditării zonelor în care implementarea soluţiilor ERP afectează controlul intern al organizaţiei;
•
competenţa profesioniştilor contabili este probabil cel mai grav aspect. În majoritatea cazurilor, cei implicaţi în auditarea firmelor nu au cunoştinţele şi abilităţile necesare înţelegerii unor astfel de sisteme. Auditarea se realizează exclusiv în jurul calculatorului;
•
slaba cunoaştere a soluţiilor existente şi a tehnologiilor pe care se bazează acestea achiziţionarea se face de cele mai multe ori fără a se ţine cont de necesităţile reale ale firmelor;
•
rapoartele de audit sunt considerate, de cele mai multe ori, doar simple certificate de bună purtare, recomandările nefiind puse în practică.
În funcţie de dimensiunea proiectului, următorii actori ar trebui să se implice în auditarea sistemelor ERP: •
compartimentul de audit intern – (compartiment impus de lege numai în cazul organizaţiilor guvernamentale). În literatura de specialitate se precizează că acesta este compartimentul care cunoaşte 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/independenţi - chiar dacă nu trebuie să aibă cunoştinţe despre fiecare soluţie în parte, auditorii externi trebuie totuşi să deţină un minimum de cunoştinţe despre modul de funcţionare al acestor sisteme;
•
implementatorul – trebuie să cunoască foarte bine soluţia şi să înţeleagă procesele din firmă pentru a oferi sprijin planificării auditurilor. Realizează şi audituri proprii pentru certificarea configuraţiei soluţiei;
•
departamentele funcţionale – managerii departamentali se ocupă de particularităţile implementării, fiecare având responsabilităţi î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 soluţiei; •
conducerea executivă – neimplicarea reală a factorilor cu putere executivă este unul din principalii factori care conduc la eşec în implementarea soluţiilor ERP.
Succesul implementării depinde de modulele sistemului integrat, de aceea auditarea ia în calcul şi infrastructura sistemului informaţional: 1. echipamentele (resursele hardware) – fiecare soluţie are propriile cerinţe de sistem, considerate minime pentru funcţionarea pachetului integrat de aplicaţii. Fiecare componentă a acestui puzzle contribuie la succes; 2. componentele de reţea – ERP se bazează 100% pe infrastructura reţelei de comunicaţii. În acest caz trebuie avute în vedere viteza şi disponibilitatea liniilor de comunicaţii, accesul la reţea şi liniile redundante prin care se asigură traficul în cazul apariţiei unor evenimente neprevăzute; 3. nomenclatoarele (fişierele de bază) de clienţi, furnizori, personal, materiale, produse finite etc. reunesc toate datele de descriere a acestora şi interfaţează cu modulele aplicaţiei. Auditarea trebuie să aibă în vedere acurateţea datelor; 4. pachetul de aplicaţii – auditarea are în vedere structura şi funcţionarea modulelor pachetului ERP: • parametrii de configurare: controalele la nivel de aplicaţie, procedura de autorizare a
utilizatorilor, configuraţiile de securitate; •
securitatea modulelor şi pe ansamblu a aplicaţiei pentru a se asigura procesarea controlată şi sigură a datelor;
•
modificarea configuraţiilor predefinite, standard pentru garantarea integrităţii proceselor;
•
documentaţia sistemului şi help-ul de context ce sprijină utilizatorii;
•
administrarea securităţii informaţiilor la nivelul organizaţiei ş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 potenţiale specifice proceselor implementate;
• proiectarea şi implementarea controalelor care contribuie la eliminarea/diminuarea
riscurilor identificate; •
verificarea funcţionării controalelor implementate; 17
•
verificarea interfaţării modulelor ERP cu aplicaţii non-ERP;
•
revizia planurilor de continuitate a afacerii.
6. angajaţii – rolurile îndeplinite de aceştia sunt structurate în jurul soluţiei implementate: •
identificarea angajaţilor cu atribuţii de conducere, a responsabilităţilor şi aptitudinilor necesare pentru a-şi îndeplini sarcinile;
•
necesarul de cursuri de instruire şi maniera în care se realizează transferul de cunoştinţe;
•
clasificarea sarcinilor de serviciu.
7. strategia de implementare - tranziţia de la vechiul sistem ar trebui făcută cu un impact minim asupra angajaţilor. În realitate implementarea unui sistem integrat generează un veritabil seism organizaţional. Securitatea informaţiilor poate fi afectată în timpul acestei tranziţii, de aceea va fi aleasă cea mai potrivită strategie. 2.2. Auditul specificatiilor
Specificaţiile sistemului informatic, asemenea unei case, constituie temelia sistemului. De aceea auditul sistemului trebuie să înceapă cu auditul specificaţiilor. Specificaţiile au la bază surse precum: •
legi şi acte guvernamentale;
•
norme de aplicare a unor acte oficiale;
•
documentaţii tehnice privind echipamentele de producţie şi auxiliare;
•
documentele de creare şi funcţionare a companiei;
•
monografii, referate şi prezentări;
•
documente contabile şi de patrimoniu;
•
documente programatice: strategii şi planuri pe termene diferite;
•
rapoarte privind dinamica evoluţiei;
•
rapoarte privind conexiunile cu mediul de afaceri;
•
documentaţii privind publicitatea şi definirea imaginii de piaţă;
•
documentaţia privind forţa de muncă;
•
documentaţia privind activităţile de cercetare, studiile de piaţă, activităţile sociale.
18
Auditul are menirea de a defini gradul de cuprindere al documentelor necesare dezvoltării unor specificaţii 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 aparţinând fiecărui tip;
•
listele grupurilor de documente aparţinând fiecărei clase:
•
tabelele de descriere cantitativă a elementelor care alcătuiesc grupurile; pentru fiecare grup se defineşte un tabel.
Fiecare listă conţine elemente sub formă de texte structurate în triplete < xi , yi , zi > , i = 1, 2, ...ne , unde: xi - denumirea tipului, clasei sau grupului de pe poziţia i a listei; yi - variabilă egală cu 1 în cazul în care în dezvoltarea specificaţiei 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 specificaţiei elementele
specificate prin xi nu au fost folosite; în caz contrar se atribuie valoarea blanc; ne – numărul elementelor din listă.
Sunt situaţii în care, din motive de neclaritate, se combină funcţiile cu structurile companiei, rezultând modalităţi neomogene de agregare. Pentru a evita astfel de abordări, se construieşte matricea MFS de corespondenţă funcţii, subsisteme, având NFUN linii şi NSS coloane, iar elementul mfsij arată că între funcţia Fi şi subsistemul SSj există o legătură dacă are valoare 1. În cazul în care se atribuie acestui element valoarea 0, rezultă că nu există o legătură directă între funcţia Fi şi subsistemul SSj. Se consideră eroare situaţia în care o linie din matrice sau o coloană are toate elementele nule. Situaţia cea mai favorabilă este cea în care unei funcţii Fi îi corespunde doar un subsistem SSj. Înseamnă că în companie fiecare subsistem realizează o singură funcţie, sarcinile fiind foarte clar distribuite. Confuziile apar atunci când mai multe subsisteme au ca sarcină activităţi corespunzătoare aceleiaşi funcţii. Confuzii apar şi atunci când un subsistem realizează mai multe funcţii şi unele dintre funcţii sunt distribuite mai multor subsisteme. Un exemplu ar fi subsistemul in care SS3 realizează activităţile funcţiilor F1 şi F3 , iar funcţia F2 este distribuită 19
subsistemelor SS1 şi SS2, ceea ce complică procesul de auditare şi de regăsire a datelor din liste atunci când nu se menţine un grad de redundanţă, pentru a plasa aceleaşi documente referitoare la o aceeaşi activitate de funcţie pentru toate sistemele în care aceasta este gestionată. Printr-o reproiectare a legăturilor subsistem – funcţii se ameliorează distribuirea, încă înainte de a dezvolta sistemul informatic. Analistul are numai menirea de a consemna distribuirea difuză a sarcinilor pentru subsisteme. Se defineşte un algoritm pentru a analiza caracterul difuz sau bine definit al legăturilor funcţii – subsisteme. Se construieşte un indicator IDIF al difuziunii, care este 0 dacă matricea MSF are toate elementele egale cu 1 şi, respectiv,
este egal cu 1 dacă fiecărei funcţii 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 specificaţiilor. 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ă răspundă cerinţelor companiei. Aceste produse au fost proiectate pentru funcţiile întreprinderii. Se specializează persoane care să definească parametri pentru subsistemul de aprovizionare, pentru subsistemul de producţie, 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 operaţional. Metodele, tehnicile şi instrumentele au menirea de a uşura munca, de a sistematiza informaţii, de a minimiza inconsistenţele. Eforturile cele mai importante destinate definirii de entităţi, grupării acestora, realizarea modulelor, specificarea conexiunilor, aparţin designerilor sistemului informatic. Pornind de la listele şi tabelele rezultate din analiza specificaţiilor 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
componenţa sistemului. Al doilea nivel , corespunde unei detalieri mai accentuate, în care se disting părţile ce
alcătuiesc subsistemele şi fluxurile care au fost definite.
20
Al treilea nivel conţine detalii de organizare a operaţiilor şi a operatorilor. Diagramele
diferă în funcţie de modul în care este abordată soluţionarea din punctul de vedere al tehnologiei abordate. Gruparea operanzilor şi operatorilor prezintă o importanţă specială întrucât influenţează definirile specifice implementării algoritmilor de regăsire a informaţiei după una sau mai multe chei. Al patrulea nivel conţine reprezentări suficient de detaliate care se constituie în
specificaţii de programare. Activitatea de auditare a proiectului trebuie să traverseze toate cele patru niveluri de detaliere. Se stabileşte măsura în care nivelul următor este rezultatul direct al detalierii elementelor definite în nivelul precedent. În cazul în care pe nivelul precedent sunt elemente nedetaliate pe nivelul următor sau detalii de pe nivelul curent nu au corespondent pe nivelul precedent, se semnalează ca element de contradicţie în proiect. Dacă specificaţiile au un nivel de detaliere ridicat, proiectul sistemului informatic urmăreşte cu mai mare precizie fiecare detaliu din specificaţii, creându-se premisa unei abordări cât 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 rând , variabila asociată unui factor este unică, pentru că factorul este unic. În al doilea rând, un indicator are o singură expresie analitică. Două expresii analitice
aparţin la doi indicatori diferiţi numai dacă expresiile sunt diferite. În al treilea rând , un indicator este evaluat o singură dată pentru un set de date. El nu va
apărea spre a fi evaluat cu acelaşi set de date şi într-o altă componentă a proiectului. În al patrulea rând , pentru regruparea tuturor datelor operează un singur criteriu.
Introducerea mai multor criterii de regrupare a datelor creează condiţii favorabile creşterii riscului în gestionare a redundanţei în sistemul informatic care se dezvoltă în etapele următoare. Criteriul colectivităţii presupune existenţa unor colectivităţi omogene. Datele se grupează pentru descrierea completă a elementelor din fiecare colectivitate. Criteriul evenimentelor prevede definirea de activităţi, resurse, momente şi durate, iar datele se grupează strict pentru a defini complet mulţimile de evenimente. În al cincilea rând, proiectul include componente care vizează operaţii fundamentale
precum iniţializări, sortări, reutilări, concatenări, adăugiri, calcule, extrageri, regăsiri, modificări, afişări, actualizări, reorganizări etc.
21
Experienţa în designul sistemului permite gruparea indicatorilor IS11, IS12, ..., ISNSS,INNSS şi a variabilelor pe o structură ierarhizată, astfel încât la baza arborescenţei 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 interdependenţelor 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 cerinţe – rezultate al designerului de sistem crează baza de încapsulare separată a variabilelor şi încapsulare indicatori sau neîncapsulare a variabilelor cu indicatorii. În primul caz se obţin două mulţimi diferite de componente omogene, rezultat al încapsulării. În cel de al doilea caz se obţine o singură mulţime în care componentele sunt rezultatul încapsulării de variabile şi indicatori. Analistul proiectului are menirea de a stabili dacă structura arborescentă este completă, are numărul de niveluri corect obţinut. Carenţele structurii sunt: •
interschimbul de niveluri, în sensul că un indicator agregat devine indicator simplu sau invers;
•
interschimbul pe acelaşi nivel, ceea ce antrenează regruparea de variabile cu consecinţe directe asupra creşterii numărului de variabile comune mai multor regrupări de date;
•
realizarea unor legături incorecte între nivelul inferior şi nivelul superior ale nodurilor arborescenţei; în acest fel indicatorii agregaţi au ca inputuri indicatori simpli nenecesari sau pentru calculul indicatorilor agregaţi lipsesc indicatori simpli.
Se observă că în auditul proiectului sunt preluate numeroase elemente din specificaţii. Elaboratorul sistemului informatic dispune de o echipă de designeri de sistem care, prin modalităţi eficiente de comunicare, dezvoltă proiectul, verifică de fiecare dată specificaţiile cu cerinţele reale ale utilizatorilor. În mod normal, între toate construcţiile existente în documentaţie şi ceea ce rezultă în procesul de auditare, diferenţele trebuie să fie nesemnificative. În realitate apar diferenţe care, dacă nu semnificative, sunt diferenţe numeroase, generând neconcordanţe, unele afectând semnificativ utilizabilitatea sistemului informatic. Documentaţia de auditare a proiectului de sistem informatic conţine liste care permit 22
agregarea de indicatori, conducând în final la un singur indicator, care clasifică proiectul ca fiind foarte bun, bun, satisfăcător sau nesatisfăcător. În faza de definire a proiectului apar o serie de detalii privind: •
stabilirea domeniilor de variaţie a variabilelor de intrare şi domeniile variabilelor rezultative;
•
dimensiunile seturilor de date;
•
cheile de regăsire a datelor;
•
funcţiile de prelucrare care se dispun pe o structură arborescentă iniţială;
•
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 informaţiilor referitoare la perioade trecute de timp.
Se creează o imagine completă a produsului finit care, în final, va conţine software, baze de date, echipamente şi va fi conectat prin fluxuri de informaţii spre puncte de lucru prin accesare condiţionată. 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, restricţionate 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 desfăşoară 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 dispoziţia administratorului sistemului;
•
acest tip de acces permite lucrul pe componente, schimbarea drepturilor de acces pentru toţi ceilalţi utilizatori; administratorul este cel care realizează interfaţa sistemului, inclusiv cu cei care asigură întreţinerea sa curentă;
23
•
chei de acces la operaţii de mare risc asupra bazei de date, precum operaţiile nestandard, corespunzătoare unor preluări accidentale, care presupun luarea unor decizii majore privind sistemul de producţie, operaţii financiare;
•
chei de acces pentru efectuarea unei singure operaţii – adăugarea de informaţie; întrucât fiecare utilizator este specializat, prin introducerea parolei se produce şi asocierea operaţiei pentru câmpul de prelucrat; de exemplu, parola unui vânzător atrage după sine asocierea cu operaţia de scădere din stoc a produselor vândute;
•
chei de acces consultare întreaga colecţie de informaţii, 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 consultări în grup;
•
chei de acces pentru consultare parţială a bazelor de date;
•
corespund unei largi categorii de utilizatori;
•
chei de acces la informaţii de interes general, privesc indicatori agregaţi ai companiei;
•
chei de acces personale care permit accesul strict la datele personale ale individului; fiecare salariat are o astfel de cheie.
Accesul la informaţia publică este liber. Auditul parolelor stabileşte măsura î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 defineşte parola sa, se impune definirea unui alfabet propriu de construire a parolelor, astfel încât prin regulile definite să se asigure un nivel de securitate ridicat. Auditul sistemului de parole este important prin modul cum califică protecţia sistemului informatic faţă de operaţiile accidentale. Este important ca fiecărui utilizator să-i fie analizată activitatea prin consemnarea: •
numărului de operaţii efectuate zilnic;
•
calitatea operării de către utilizator;
•
numărul de incidente de prelucrare, diferenţiat pe tipuri.
Există necesitatea ca proprietarul sistemului să asigure un nivel de concordanţă şi o proporţie adecvată între structura sistemului informatic şi capacităţile 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 aşteptare, cu efecte negative asupra proceselor din companie.
24
Faza de design a sistemului acordă nivelul de modernitate a acestuia. Dacă echipa de designeri stăpâneşte tendinţele moderne de analiză şi proiectare, soluţia oferită este, de asemenea, modernă. În caz contrar, se obţine o soluţie 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 desfășurarea unei acțiuni de audit, echipa de audit trebuie să aleagă și să aplice acele proceduri de audit ce satisfac standardele de audit și în acela și timp să răspundă obiectivelor auditului.
Efectuarea procedurilor de fond
Pentru a detecta toate erorile și neregularită țile esen țiale 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 ob ține probe de audit în scopul detectării erorilor semnificative din situa țiile financiare. Procedurile de fond sunt de două tipuri: proceduri analitice și teste de fond. Pentru a evalua corect calitatea și corectitudinea func ționării sistemelor informatice financiar contabile desfășurate într-o entitate, și pentru a se pronun ța asupra realită ții și exactității cu care au fost întocmite situa țiile financiare pentru perioada analizată, auditorii trebuie să facă o serie de investigații:
26
a) Descrierea procedurilor în sistemul de culegere și prelucrare a datelor, cu scopul de
a stabili, pentru fiecare domeniu semnificativ (achizi ții de bunuri și servicii, stocări, produc ție, vânzări), care sunt procedurile folosite de societate pentru culegerea informa țiilor, întocmirea registrelor, prelucrarea datelor, înregistrarea operațiunilor din contabilitatea sintetică
și
analitică, în evidența cronologică și sistematică. Standardele Naționale de Contabilitate precizează: „Documentele justificative care stau la baza înregistrărilor în contabilitate angajează răspunderea persoanelor care le-au întocmit, vizat, aprobat sau înregistrat în contabilitate”, această precizare se regăse ște și în legea contabilită ții. 1 Procedurile descriptive se bazează pe manualul de proceduri interne și chestionare de control intern la care răspund persoanele din interior ce au atribu ții î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 funcționarea sistemului informatic financiar contabil, ci numai de a stabbili dacă sistemul descris mai sus este, bineîn țeles, cel real. c) Evaluarea preliminară (a riscului de erori)
După ce s-a obținut o descriere a sistemului de culegere și prelucrare a datelor contabile în sistemul financiar, se procedează la o evaluare preliminară a fiabilită ții acestei organizări 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 concep ție, urmțnd ca în etapa următoare să verifice modul de func ționare 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 deficien țe ale sistemului, care pot da na ștere unor riscuri de erori sau fraude. Auditorul va analiza dacă: 1
Legea 82/1991 a contabilității, 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 aplicării gre șite a procedurilor (func ționării sistemului). d) Teste de permanenț ă
Acestea urmăresc dacă procedurile sunt aplicate într-o manieră permanentă fără defecțiuni. Aceste teste trebuie să fie suficient de mari pentru a oferi certitudini asupra modului de funcționare a sistemului. Pentru depistarea riscurilor în funcționarea sistemului se procedează la analiza controalelor de prevenire și a controalelor de detectare prevăzute de întreprindere.
Efectuarea și documentarea procedurilor analitice
Auditorii concep și efectuează proceduri de fond pentru a răspunde la evaluarea aferentă cu privire la riscul de audit semnificativă la nivel de aser țiune. Procedurile de fond aplicate de auditori la nivel de aserțiune pot fi derivate din testele de detaliu, din procedurile analitice de fond, sau din combinarea ambelor. În conformitate cu Standardele Internaționale de Audit, procedurile analitice sunt utilizate în următoarele scopur i2: 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 când utilizarea lor poate fi mai funcțională și eficientă decât testele detaliilor pentru reducerea riscului de audit la nivel de aserț iune, la un nivel acceptabil scăzut; c) Ca o revizuire generală a sistemelor informatice si a situa țiilor financiare la sfârșitul anului.
2
Standardele Internaț ionale 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 opea țiuni în care cifrele sunt ușor de preliminat. Prima etapă a unei proceduri analitice este aceea de a stabili diferen ța acceptabilă dintre prognoza făcută de auditor și cifrele care apar în situa țiile financiare. De asemenea, auditorul va ține cont de relația dintre valoarea totală a categoriei de opera țiuni și baza materialită ții, calculând diferența acceptabilă conform următoarei formule3: Diferenț a acceptabilă = Nivelul materialității x V (Valoarea categoriei de operaț iuni/Rădăcina pătrată din baza materialită ț ii)
Exemplu
Un auditor stabilește nivelul materialită ții la 450.000 euro pentru entitatea X. Cheltuielile totale în valoare de 50 milioane euro reprezintă baza materialită ții. Auditorul dorește să efectueze o revizuire analitică pentru categoria de opera țiuni privind salariile personalului, care au o valoare de 40 mil euro. Calcul
40 mil. Euro (valoarea categoriei de opera țiuni) împăr țit la 50 mil. Euro (baza materialității) egal cu 0,8, din care auditorul extrage rădăcina pătrată (0,8944). Apoi, înmulțește acest rezultat cu nivelul materialită ții (450.000 euro) ob ținând diferen ța 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 cunoa ște valoarea care apare în situa țiile financiare. De aceea prognoza pe care auditorul o realizează trebuie să rezulte din date independente de înregistrările contabile. Rezultă că în acest caz informa țiile din surse din afara entită ții sunt mai valoroase decât cele ob ținute din interior.
3
Curtea de Conturi a României – Manualul de Audit Financiar ș i Regularitate, Bucureș ti, 2003
29
Exemplu
Dacă auditorul verifică o școală cu 150 cadre didactice angajate, care câ știgă 2000 euro pe an fiecare, atunci el se va a ștepta ca valoarea totală a cheltuielilor cu salariile să fie 300.000 (150 x 2.000). Dacă o entitate auditată colectează taxe locale de la popula ție, atunci auditorul va fi în măsură 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 a șteptat va fi:
Număr
Valoare
Total venituri
Apartamente
20.000
100 euro
2.000.000 euro
Case
5.000
150 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 opera ție 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 însemnând că diferen ța dintre prognoză și cifrele din cont este mai mică decât diferența acceptată. În situația în care ne încadrăm între aceste limite auditorul are certitudinea că operațiunile verificate sunt în conformitate cu reglementările în vigoare. Se acceptă doar o mică diferență între cifra reală și cea estimată (toleran ță maximă de 1 procent) în situația în care respectivele diferen țe nu pot avea explica ții adecvate. Dacă cifrele se situează în afara limitelor auditorul trebuie să solicite explica ții punctuale. Va folosi întrebări 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 situa țiile 30
previzionate fuseseră de 2.750.000 euro, atunci echipa de audit va cere explica ții pentru variația de 1.250.000 euro. Sistemul infomatic ar trebui prevăzut cu un sistem de aten ționare asupra variației mari (de 45%). Dacă ordonatorul de credite va explica echipei de audit că această creștere se datorează noilor spa ții date în folosi ță în timpul anului, atunci echipa va trebui să afle câte spații au fost construite și care a fost suprafa ța disponibilă închiriată, precum și
data începerii încasării 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 diferen țe acceptabile, atunci auditorul poate să se bazeze pe asigurarea planificată. În cazul în care procedurile analitice nu indică o previziune în limitele
diferenței
acceptabile,
atunci
asigurarea planificată nu poate fi preluată iar auditorul
trebuie
să
adopte
proceduri
alternative de audit menite să conducă la obținerea asigurării planificate. Evaluarea testelor de control
Dacă auditorii constată că unele controale nu au funcționat corespunzător vor analiza posibilitatea
testării
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ă situație conduce la efectuarea unui volum sporit de proceduri directe de fond. Dacă testele de control ale auditorului eșuează, asta nu înseamnă în mod obligatoriu că există erori bănești sau neregularități în categoria de operațiuni testată.
31
De exemplu, dacă nu se realizează o analiză a variației lunare a salariilor individuale aceasta nu înseamnă neapărat că ștatul de plată al salariilor pe acea lună este greșit.
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 audit” 4, 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
Evaluarea riscului la sa se verifice arborele deciziei care ar nivelul putea avea urmatoarea forma: sistemului informatic Exista riscuri care pot genera depasirea marjei de eroare acceptate? (materialitatea) DA
NU
Au fost utilizate controale interne pt reducerea riscurilor? DA NU Cu succes?
Au fost utilizate controale interne?
DA Cu succes?
NU
NU
NU
DA Controale interne eficace Controale 4 Standardele Internationale „Raportul de audit” interne eficace de Audit, ISA 700(asigurare) DA
(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, Bucureşti.
2. Ştefan Popa, Claudia Ionescu- Audit în medii informatizate, Editura Expert, 2005, Bucureşti. 3. Ali Eden, Victoria Stnciu- Auditul Sistemelor informatice, Editura Dual Tech, 2004, Bucureşti. 4. Munteanu A.- Auditul sistemelor informaţionale contabile, Editura Polirom, 2001, Iaşi. 5. Andronie Maria- Analiza şi Proiectarea sistemelor informatice de gestiune, Editura Fundaţiei Romania de Maine, 2007, Bucureşti.
6. O. Ray Whittington, Kurt Pany, Walter B. Meigs, Robert F. Meigs- Principles of Auditing, Tenth Edition, IRWIN Boston. 36
