STANDARDE SI TIPURI DE AUDIT - Auditarea sistemelor integrate, Auditul specificatiilor, Auditulului de sistem informatic

STANDARDE SI TIPURI DE AUDIT

1. Auditarea sistemelor integrate

Nu putem discuta despre o traditie romaneasca in domeniul evolutiei sistemelor informatice si cu atat mai putin despre o practica anume a integrarii acestora. Daca ne propunem sa discutam despre auditarea sistemelor informatice, de asemenea, trebuie sa remarcam ca, pana la mijlocul anului 2003, in Romania nu s-a pus problema auditarii sistemelor informationale. Expertii contabili si auditorii financiari autohtoni ar trebui sa acopere si acest domeniu in timpul misiunilor lor in baza standardelor de audit adoptate.

In majoritatea misiunilor de audit financiar autohtone intereseaza doar evaluarea raportarilor financiare si mai putin mijloacele prin care au fost obtinute datele din acestea. In 2003 a fost emis Ordinul nr. 1077 privind conditiile in care se pot edita, intr-un singur exemplar, facturile fiscale cu regim special de tiparire, inseriere si numerotare, utilizate in activitatea financiara si contabila. 1077 este primul act normativ care face referire la auditul sistemelor informationale, chiar daca se limiteaza la auditarea Planului de securitate al unei companii de catre un auditor CISA (Certified Information Systems Auditor). Altfel spus este un audit de conformitate, nu un audit de securitate!

Al doilea act normativ (si ultimul) este Ordinul MCTI nr. 218 din 2004 privind procedura de avizare a instrumentelor de plata cu acces la distanta, de tipul aplicatiilor Internet-banking, home-banking sau mobile-banking. Si in acest caz este vorba de auditarea planului de securitate, dar se adauga si auditarea aplicatiei folosita in tranzactiile de tip mbanking.

Inainte de a continua, trebuie sa facem o scurta mentiune: primul act normativ (1077/2003) face doar o scurta trecere in revista a aspectelor ce trebuie urmarite in Planul de securitate, in timp ce la doilea (218/2004) chiar prezinta o structura a unui astfel de document. Din punct de vedere legislativ la nivelul auditarii sistemelor informationale aceasta este situatia din Romania.

Pentru ca ERP-ul nu este corect inteles, in multe implementari autohtone revizia si auditul unor astfel de sisteme nu sunt luate in calculul proiectului. Aceasta deoarece lipsesc cerintele legale precum cele din legea Sarbanes-Oaxley in SUA. Orice implementare ar avea impact asupra firmelor. Prin urmare, aceste implementari trebuie monitorizate si controlate pentru a fi siguri de succesul unui astfel de demers deoarece riscurile sunt mult mai mari decit in cazul aplicatiilor 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 si procesele firmei. Pentru a asigura succesul, astfel de sisteme trebuie sa integreze in totalitate procesele si procedurile firmei;

companiile din statele membre UE au fost obligate, ca incepind cu 1 ianuarie 2005, sa intocmeasca raportarile financiar contabile in conformitate cu prevederile IAS. Mai mult, la ora actuala se poarta discutii intense intre International Accounting Standards (IAS) si Federal Accounting Standards Board (FASB) pentru a se elimina diferentele dintre standardele emise de cele doua organizatii;

3. auditarea implementarilor ERP autohtone ar scoate in evidenta in majoritatea cazurilor:

slaba planificare a proiectelor – auditul si revizia nefiind cuprinse in aceste

proiecte, nu sunt cunoscute abilitatile personale care ar trebui implicate intr-un

astfel de proces;

lipsa auditarii zonelor in care implementarea solutiilor ERP afecteaza controlul

intern al organizatiei;

competenta profesionistilor contabili este probabil cel mai grav aspect. In majoritatea cazurilor, cei implicati in auditarea firmelor nu au cunostintele si abilitatile necesare intelegerii unor astfel de sisteme. Auditarea se realizeaza exclusiv in jurul calculatorului;

slaba cunoastere a solutiilor existente si a tehnologiilor pe care se bazeaza acestea - achizitionarea se face de cele mai multe ori fara a se tine cont de necesitatile reale ale firmelor;

rapoartele de audit sunt considerate, de cele mai multe ori, doar simple certificate de buna purtare, recomandarile nefiind puse in practica.

In functie de dimensiunea proiectului, urmatorii actori ar trebui sa se implice in auditarea sistemelor ERP:

compartimentul de audit intern – (compartiment impus de lege numai in cazul organizatiilor guvernamentale). In literatura de specialitate se precizeaza ca acesta este compartimentul care cunoaste cel mai bine starea sistemului implementat si zonele in care un sistem integrat va asigura succesul firmei. Auditorii interni trebuie sa faca parte in mod obligatoriu din echipa care se ocupa de implementare;

auditorii externi/independenti - chiar daca nu trebuie sa aiba cunostinte despre fiecare solutie in parte, auditorii externi trebuie totusi sa detina un minimum de cunostinte despre modul de functionare al acestor sisteme;

implementatorul – trebuie sa cunoasca foarte bine solutia si sa inteleaga procesele din firma pentru a oferi sprijin planificarii auditurilor. Realizeaza si audituri proprii pentru certificarea configuratiei solutiei;

departamentele functionale – managerii departamentali se ocupa de particularitatile implementarii, fiecare avand responsabilitati in aria sa de decizie.

Pentru ca sunt beneficiarii rapoartelor pe care le genereaza sistemul trebuie sa se implice pe tot parcursul ciclului de viata a solutiei;

conducerea executiva – neimplicarea reala a factorilor cu putere executiva este unul din principalii factori care conduc la esec in implementarea solutiilor ERP.

Succesul implementarii depinde de modulele sistemului integrat, de aceea auditarea ia in calcul si infrastructura sistemului informational:

1. echipamentele (resursele hardware) – fiecare solutie are propriile cerinte de sistem, considerate minime pentru functionarea pachetului integrat de aplicatii. Fiecare componenta

a acestui puzzle contribuie la succes;

componentele de retea – ERP se bazeaza 100% pe infrastructura retelei de comunicatii. In acest caz trebuie avute in vedere viteza si disponibilitatea liniilor de comunicatii, accesul la retea si liniile redundante prin care se asigura traficul in cazul aparitiei unor evenimente neprevazute;

3. nomenclatoarele (fisierele de baza) de clienti, furnizori, personal, materiale, produse finite etc. reunesc toate datele de descriere a acestora si interfateaza cu modulele aplicatiei. Auditarea trebuie sa aiba in vedere acuratetea datelor;

4. pachetul de aplicatii – auditarea are in vedere structura si functionarea modulelor pachetului ERP:

parametrii de configurare: controalele la nivel de aplicatie, procedura de autorizare a utilizatorilor, configuratiile de securitate;

securitatea modulelor si pe ansamblu a aplicatiei pentru a se asigura procesarea controlata si sigura a datelor;

modificarea configuratiilor predefinite, standard pentru garantarea integritatii proceselor;

documentatia sistemului si help-ul de context ce sprijina utilizatorii;

administrarea securitatii informatiilor la nivelul organizatiei si maniera prin care pot fi identificate si eliminate/diminuate riscurile.

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

identificarea obiectivelor controalelor specifice proceselor implementate;

identificarea si evaluarea riscurilor potentiale specifice proceselor implementate;

proiectarea si implementarea controalelor care contribuie la eliminarea/diminuarea riscurilor identificate;

verificarea functionarii controalelor implementate;

verificarea interfatarii modulelor ERP cu aplicatii non-ERP;

revizia planurilor de continuitate a afacerii.

6. angajatii – rolurile indeplinite de acestia sunt structurate in jurul solutiei implementate:

identificarea angajatilor cu atributii de conducere, a responsabilitatilor si aptitudinilor necesare pentru a-si indeplini sarcinile;

necesarul de cursuri de instruire si maniera in care se realizeaza transferul de cunostinte;

clasificarea sarcinilor de serviciu.

7. strategia de implementare - tranzitia de la vechiul sistem ar trebui facuta cu un impact minim asupra angajatilor. In realitate implementarea unui sistem integrat genereaza un veritabil seism organizational. Securitatea informatiilor poate fi afectata in timpul acestei tranzitii, de aceea va fi aleasa cea mai potrivita strategie.

Auditul specificatiilor

Specificatiile sistemului informatic, asemenea unei case, constituie temelia sistemului. De aceea auditul sistemului trebuie sa inceapa cu auditul specificatiilor. Specificatiile au la baza surse precum:

legi si acte guvernamentale;

norme de aplicare a unor acte oficiale;

documentatii tehnice privind echipamentele de productie si auxiliare;

documentele de creare si functionare a companiei;

monografii, referate si prezentari;

documente contabile si de patrimoniu;

documente programatice: strategii si planuri pe termene diferite;

rapoarte privind dinamica evolutiei;

rapoarte privind conexiunile cu mediul de afaceri;

documentatii privind publicitatea si definirea imaginii de piata;

documentatia privind forta de munca;

documentatia privind activitatile de cercetare, studiile de piata, activitatile sociale.

Auditul are menirea de a defini gradul de cuprindere al documentelor necesare dezvoltarii unor specificatii complete, corecte si in concordanta cu obiectivul definit pentru sistemul informatic.

Se intocmesc mai multe liste si tabele si anume:

lista tipurilor de documente;

listele claselor de documente apartinand fiecarui tip;

listele grupurilor de documente apartinand fiecarei clase:

tabelele de descriere cantitativa a elementelor care alcatuiesc grupurile; pentru fiecare grup se defineste un tabel.

Fiecare lista contine elemente sub forma de texte structurate in triplete < xi , yi , zi > , i = 1, 2, ne, unde:

xi

- denumirea tipului, clasei sau grupului de pe pozitia i a listei;

yi - variabila egala cu 1 in cazul in care in dezvoltarea specificatiei au fost incluse elementele ca tipul, clasa, grupul i; in caz contrar se atribuie valoarea blanc;

zi - variabila egala cu 1 in cazul in care in dezvoltarea specificatiei elementele specificate prin xi nu au fost folosite; in caz contrar se atribuie valoarea blanc;

ne – numarul elementelor din lista.

Sunt situatii in care, din motive de neclaritate, se combina functiile cu structurile companiei, rezultand modalitati neomogene de agregare.

Pentru a evita astfel de abordari, se construieste matricea MFS de corespondenta functii, subsisteme, avand NFUN linii si NSS coloane, iar elementul mfsij arata ca intre functia Fi si subsistemul SSj exista o legatura daca are valoare 1. In cazul in care se atribuie acestui element valoarea 0, rezulta ca nu exista o legatura directa intre functia Fi si subsistemul SSj.

Se considera eroare situatia in care o linie din matrice sau o coloana are toate elementele nule.

Situatia cea mai favorabila este cea in care unei functii Fi ii corespunde doar un subsistem SSj. Inseamna ca in companie fiecare subsistem realizeaza o singura functie, sarcinile fiind foarte clar distribuite.

Confuziile apar atunci cand mai multe subsisteme au ca sarcina activitati corespunzatoare aceleiasi functii. Confuzii apar si atunci cand un subsistem realizeaza mai multe functii si unele dintre functii sunt distribuite mai multor subsisteme. Un exemplu ar fi subsistemul in care  SS3 realizeaza activitatile functiilor F1 si F3 , iar functia F2 este distribuita subsistemelor SS1 si SS2, ceea ce complica procesul de auditare si de regasire a datelor din liste atunci cand nu se mentine un grad de redundanta, pentru a plasa aceleasi documente referitoare la o aceeasi activitate de functie pentru toate sistemele in care aceasta este gestionata.

Printr-o reproiectare a legaturilor subsistem – functii se amelioreaza distribuirea, inca inainte de a dezvolta sistemul informatic. Analistul are numai menirea de a consemna distribuirea difuza a sarcinilor pentru subsisteme. Se defineste un algoritm pentru a analiza caracterul difuz sau bine definit al legaturilor functii – subsisteme. Se construieste un indicator IDIF al difuziunii, care este 0 daca matricea MSF are toate elementele egale cu 1 si, respectiv, este egal cu 1 daca fiecarei functii Fi ii corespunde unul si numai unul dintre subsisteme, respectiv subsistemul SSj.

3. Auditul proiectului de sistem informatic

Proiectul sistemului informatic este realizat pe baza specificatiilor. Cele mai multe dintre proiecte sunt structurate pe subsisteme. Exista numeroase produse informatice complexe care, printr-o buna parametrizare, genereaza un sistem informatic customizat, capabil sa raspunda cerintelor companiei. Aceste produse au fost proiectate pentru functiile intreprinderii.

Se specializeaza persoane care sa defineasca parametri pentru subsistemul de aprovizionare, pentru subsistemul de productie, pentru subsistemul de desfacere, pentru subsistemul financiar-contabil etc. Indiferent de metoda folosita, indiferent de mediul de dezvoltare utilizat, numai un proiect bun are menirea de a dezvolta un sistem informatic operational. Metodele, tehnicile si instrumentele au menirea de a usura munca, de a sistematiza informatii, de a minimiza inconsistentele. Eforturile cele mai importante destinate definirii de entitati, gruparii acestora, realizarea modulelor, specificarea conexiunilor, apartin designerilor sistemului informatic.

Pornind de la listele si tabelele rezultate din analiza specificatiilor se trece la studirea proiectului. Un proiect de sistem informatic este dezvoltat pe mai multe niveluri.

Primul nivel, cu gradul de agregare cel mai ridicat, identifica subsistemele care intra in componenta sistemului.

Al doilea nivel, corespunde unei detalieri mai accentuate, in care se disting partile ce alcatuiesc subsistemele si fluxurile care au fost definite.

Al treilea nivel contine detalii de organizare a operatiilor si a operatorilor. Diagramele difera in functie de modul in care este abordata solutionarea din punctul de vedere al tehnologiei abordate. Gruparea operanzilor si operatorilor prezinta o importanta speciala intrucat influenteaza definirile specifice implementarii algoritmilor de regasire a informatiei dupa una sau mai multe chei.

Al patrulea nivel contine reprezentari suficient de detaliate care se constituie in specificatii de programare.

Activitatea de auditare a proiectului trebuie sa traverseze toate cele patru niveluri de detaliere. Se stabileste masura in care nivelul urmator este rezultatul direct al detalierii elementelor definite in nivelul precedent. In cazul in care pe nivelul precedent sunt elemente nedetaliate pe nivelul urmator sau detalii de pe nivelul curent nu au corespondent pe nivelul precedent, se semnaleaza ca element de contradictie in proiect.

Daca specificatiile au un nivel de detaliere ridicat, proiectul sistemului informatic urmareste cu mai mare precizie fiecare detaliu din specificatii, creandu-se premisa unei abordari cat mai fidele.

In dezvoltarea unui proiect trebuie respectate o serie de reguli, iar procesul de auditare are menirea de a analiza daca aceste reguli au fost respectate.

In primul rand, variabila asociata unui factor este unica, pentru ca factorul este unic.

In al doilea rand, un indicator are o singura expresie analitica. Doua expresii analitice apartin la doi indicatori diferiti numai daca expresiile sunt diferite.

In al treilea rand, un indicator este evaluat o singura data pentru un set de date. El nu va aparea spre a fi evaluat cu acelasi set de date si intr-o alta componenta a proiectului.

In al patrulea rand, pentru regruparea tuturor datelor opereaza un singur criteriu. Introducerea mai multor criterii de regrupare a datelor creeaza conditii favorabile cresterii riscului in gestionare a redundantei in sistemul informatic care se dezvolta in etapele urmatoare. Criteriul colectivitatii presupune existenta unor colectivitati omogene. Datele se grupeaza pentru descrierea completa a elementelor din fiecare colectivitate. Criteriul evenimentelor prevede definirea de activitati, resurse, momente si durate, iar datele se grupeaza strict pentru a defini complet multimile de evenimente.

In al cincilea rand, proiectul include componente care vizeaza operatii fundamentale precum initializari, sortari, reutilari, concatenari, adaugiri, calcule, extrageri, regasiri, modificari, afisari, actualizari, reorganizari etc.

Experienta in designul sistemului permite gruparea indicatorilor IS11, IS12, , ISNSS,INNSS si a variabilelor pe o structura ierarhizata, astfel incat la baza arborescentei se afla indicatorii cu cel mai redus nivel de agregare, iar la nivelul cel mai ridicat sunt indicatorii cei mai sintetici, profit, cifra de afaceri si rentabilitate.

Modul in care se realizeaza regruparea indicatorilor este rezultatul analizei interdependentelor indicatori – factori (inputuri), indicatori – outputuri. Prezinta o importanta speciala asigurarea unui nivel ridicat de ortogonalitate in procesul de elaborare a structurii arborescente.

Oricare este tehnologia de dezvoltare a sistemului informatic, structura arbore cerinte – rezultate al designerului de sistem creaza baza de incapsulare separata a variabilelor si incapsulare indicatori sau neincapsulare a variabilelor cu indicatorii.

In primul caz se obtin doua multimi diferite de componente omogene, rezultat al incapsularii.

In cel de al doilea caz se obtine o singura multime in care componentele sunt rezultatul incapsularii de variabile si indicatori. Analistul proiectului are menirea de a stabili daca structura arborescenta este completa, are numarul de niveluri corect obtinut.

Carentele structurii sunt:

interschimbul de niveluri, in sensul ca un indicator agregat devine indicator simplu sau invers;

interschimbul pe acelasi nivel, ceea ce antreneaza regruparea de variabile cu consecinte directe asupra cresterii numarului de variabile comune mai multor regrupari de date;

realizarea unor legaturi incorecte intre nivelul inferior si nivelul superior ale nodurilor arborescentei; in acest fel indicatorii agregati au ca inputuri indicatori simpli nenecesari sau pentru calculul indicatorilor agregati lipsesc indicatori simpli.

Se observa ca in auditul proiectului sunt preluate numeroase elemente din specificatii. Elaboratorul sistemului informatic dispune de o echipa de designeri de sistem care, prin modalitati eficiente de comunicare, dezvolta proiectul, verifica de fiecare data specificatiile cu cerintele reale ale utilizatorilor. In mod normal, intre toate constructiile existente in documentatie si ceea ce rezulta in procesul de auditare, diferentele trebuie sa fie nesemnificative. In realitate apar diferente care, daca nu semnificative, sunt diferente numeroase, generand neconcordante, unele afectand semnificativ utilizabilitatea sistemului informatic. Documentatia de auditare a proiectului de sistem informatic contine liste care permit agregarea de indicatori, conducand in final la un singur indicator, care clasifica proiectul ca fiind foarte bun, bun, satisfacator sau nesatisfacator.

In faza de definire a proiectului apar o serie de detalii privind:

stabilirea domeniilor de variatie a variabilelor de intrare si domeniile variabilelor rezultative;

dimensiunile seturilor de date;

cheile de regasire a datelor;

functiile de prelucrare care se dispun pe o structura arborescenta initiala;

fluxurile de date;

amplasarea punctelor de colectare a datelor in locuri precizate din companie;

stabilirea nivelurilor de securitate pentru fiecare punct de colectare/extragere a datelor;

definirea formatelor de prezentare a rezultatelor;

stabilirea nivelului de validare a datelor de intrare;

stabilirea arhitecturii pe care se dezvolta sistemul informatic;

definirea echilibrului dintre outputurile imprimate si cele in format electronic;

stabilirea modului de arhivare a informatiilor referitoare la perioade trecute de timp.

Se creeaza o imagine completa a produsului finit care, in final, va contine software, baze de date, echipamente si va fi conectat prin fluxuri de informatii spre puncte de lucru prin accesare conditionata.

Auditul acestui proiect ia in analiza toate aspectele. De exemplu, in cazul analizei sistemului de parole se inventariaza punctele de acces care se amplaseaza la nivelul companiei.  Amplasamentul fizic este corelat si cu utilizarea. Posturile de lucru dedicate, restrictionate prin anumite tipologii de acces, permit o buna disciplinare a utilizatorilor sistemului. Fiecare utilizator are drept de acces la resursele sistemului numai in anumite puncte de lucru. Se are in vedere apropierea de locul in care utilizatorul isi desfasoara activitatea. In mod curent, in practica, exista mai multe tipologii de parole de acces, in raport cu drepturile asupra resurselor sistemului si anume:

chei de acces total la dispozitia administratorului sistemului;

acest tip de acces permite lucrul pe componente, schimbarea drepturilor de acces pentru toti ceilalti utilizatori; administratorul este cel care realizeaza interfata sistemului, inclusiv cu cei care asigura intretinerea sa curenta;

chei de acces la operatii de mare risc asupra bazei de date, precum operatiile nestandard, corespunzatoare unor preluari accidentale, care presupun luarea unor decizii majore privind sistemul de productie, operatii financiare;

chei de acces pentru efectuarea unei singure operatii – adaugarea de informatie; intrucat fiecare utilizator este specializat, prin introducerea parolei se produce si asocierea operatiei pentru campul de prelucrat; de exemplu, parola unui vanzator atrage dupa sine asocierea cu operatia de scadere din stoc a produselor vandute;

chei de acces consultare intreaga colectie de informatii, corespund unei categorii de utilizatori; este vorba de utilizatorii care fac parte din echipa manageriala; ei au dreptul de a consulta numai baza de date; unele aspecte fac obiectul consultari in grup;

chei de acces pentru consultare partiala a bazelor de date;

corespund unei largi categorii de utilizatori;

chei de acces la informatii de interes general, privesc indicatori agregati ai companiei;

chei de acces personale care permit accesul strict la datele personale ale individului; fiecare salariat are o astfel de cheie.

Accesul la informatia publica este liber. Auditul parolelor stabileste masura in care persoanele din companie, in calitate de utilizatori, au o singura parola. Modul de distribuire a parolelor si de gestionare a acestora constituie, de asemenea, obiectul auditului. Este important sa se defineasca un sistem de parolare si gestiune a parolelor. In cazul in care se acorda o parola si utilizatorul isi defineste parola sa, se impune definirea unui alfabet propriu de construire a parolelor, astfel incat prin regulile definite sa se asigure un nivel de securitate ridicat. Auditul sistemului de parole este important prin modul cum califica protectia sistemului informatic fata de operatiile accidentale. Este important ca fiecarui utilizator sa-i fie analizata activitatea prin consemnarea:

numarului de operatii efectuate zilnic;

calitatea operarii de catre utilizator;

numarul de incidente de prelucrare, diferentiat pe tipuri.

Exista necesitatea ca proprietarul sistemului sa asigure un nivel de concordanta si o proportie adecvata intre structura sistemului informatic si capacitatile de acces la acestea in punctele de lucru din companie. In cazul in care exista dezechilibre, apar fie posturi de lucru neutilizate, fie fire de asteptare, cu efecte negative asupra proceselor din companie.

Faza de design a sistemului acorda nivelul de modernitate a acestuia. Daca echipa de designeri stapaneste tendintele moderne de analiza si proiectare, solutia oferita este, de asemenea, moderna. In caz contrar, se obtine o solutie veche, caracterizata printr-un mod rigid, hibrid si neperformant de lucru.