Jedna od tema koje rado opisujem na ovim stranicama su slučajevi insajderskog računalnog kriminala. Pri tome obrađujem publicirane i, uglavnom, inozemne slučajeve (što naravno uopće ne znači da i mi nemamo konje za trku).
Najfriškiji i veoma ilustrativan primjer vezan je za posrnulu indijsku outsourcing tvrtku Satyam. Za neupućene, Satyam je jedan od najvećih primjera korporativne prijevare u posljednje vrijeme. Na naslovnice su izbili početkom godine, kada je utvrđeno da su u duljem razdoblju iskazivali napuhane poslovne rezultate. Klupko se počelo razmotavati nakon prošlogodišnjih sumnjivih poslovnih poteza kojima su izazvali dioničare.
Neću ulaziti u financijske detalje same prijevare, više o možete naći na ovoj stranici. Za nas priča počinje izvještajem o analizi ovog slučaja koji je objavljen početkom ovog tjedna. Kako javlja InformationWeek, Satyam je generirao oko 7.500 lažnih faktura klijentima čime je poslovne rezultate pokazao znatno boljim nego što su bili (i što je naravno utjecalo na cijenu dionica ove tvrtke). Za ove stranice je osobito zanimljiv način generiranja ovih faktura: Satyam (ponavljam još jednom - IT outsourcing firma sa 40.000 zaposlenih, a razvoj aplikacija im je jedna od središnjih kompetencija) nedozvoljeno je modificirao vlastite poslovne aplikacije i omogućio kreiranje lažnih faktura ali tako da njihovo postojanje ne izazove sumnju i tako da budu izdvojene od realnih transakcija (pogađate zašto: lažne fakture nisu nikad bile naplaćene). Na taj način je prikazan prihod od 946 milijuna USD.
Ovaj slučaj je dobar primjer kojim revizori uvijek mogu opravdati svoje inzisitranje na reviziji postupka upravljanja aplikativnim promjenama, što se često smatra dosadnim inzistiranjem na formalnim detaljima. Naime, veoma je teško provesti striktnu kontrolu procesa upravljanja promjenama. Mjere mogu biti presložene za manje i srednje organizacije (izolacija razvojne, testne i produkcijske okoline; zaštita programskih biblioteka; stroga definicija i dodjela korisničkih prava; odvajanje pristupnih privilegija; formalna procedura...), što i za velike organizacije često predstavlja ograničenje.
No, ovaj slučaj pokazuje i nedostatke same revizije provedene u Satyamu.
Prvi nedostatak se odnosi na reviziju procesa upravljanja promjenama u Satyamu. Ne znam koliko je detaljno napravljena revizija ovog procesa, no kada se ovakva prijevara dogovori na najvišoj razini i kada je u scenarij uključeno više ljudi s odgovarajućim pravima (a očigledno je da je u Satyamu bio takav slučaj), onda redovita revizija općih kontrola IS-a teško može dati rezultate.
Druga revizorska greška se zapravo pokazala ključnom: revizor je propustio, a svakako je morao, utvrditi da 7.500 faktura nije pokriveno prihodom na računu u banci.
Granica između financijske revizije i revizije informacijskih sustava je, govoreći rječnikom politike, veoma meka. Poznavanje i jedne i druge strane medalje je neohodno za uspjeh revizije.
No, ipak treba reći da je prijevara u Satyamu ponajprije bila omogućena pohlepom i prividnim dobrim rezultatima koji su, uostalom kao i u drugim segmentima ali u istim vremenima, zasigurno spriječili dioničare da na vrijeme pogledaju istinu.
Poprilično sam razočaran količinom tekstova u zadnje vrijeme na vašim stranicama.
OdgovoriIzbrišiŠteta, s obzirom da su tekstovi poprilično interesantni...