Hur skall internrevisorn lösa sina arbetsuppgifter inom ADB-området? Frågan behandlas i denna artikel av auktor revisor Gunnar Sjöquist, som också tar upp speciella problem i samband med introduktionen av ADB-kunniga revisorer inom ett företag.

Hur skall vi kunna bygga upp egen kompetens inom ADB-området för att kunna klara av de arbetsuppgifter vi förelagts? Vilka arbetsuppgifter skall vår nye ADB-revisor ha? Hur skall vi kunna bevaka system under utveckling med de begränsade resurser vi har?

Många internrevisionschefer har ställt dessa frågor. En klen tröst är att frågorna alls inte är främmande för de externa revisorerna vilka brottats med problemen många år. Lyckligtvis har internrevisorn ett bättre utgångsläge i och med att denne kan begränsa och fördjupa sitt ADB-tekniska kunnande till de system som finns inom den egna organisationen.

I det följande skall vi försöka belysa de arbetsuppgifter inom ADB-området som den interna revisorn oftast har att tacklas med. Vidare kommer vi att ta upp speciella problem i samband med introduktionen av ADB-kunniga revisorer inom ett företag.

ARBETSUPPGIFTER

Låt oss anta att internrevisorn har erhållit följande allmänna direktiv från företagsledningen:

  • Bevaka att de åligganden styrelsen och verkställande direktören har enligt aktiebolagslagen ifråga om redovisningen och medelsförvaltningen iakttas.

  • Bevaka att andra externa krav rörande redovisningen iakttas, t ex skydd av persondata.

  • Bevaka att de policy-beslut som fattas av företagsledningen efterlevs.

  • Bedöma och rapportera huruvida väsentliga system är ändamålsenliga.

  • Bedöma och rapportera huruvida väsentliga system ekonomiskt är väl underbyggda.

  • Agera som rådgivare i frågor rörande principer och metoder för intern kontroll.

  • Sprida kunskap om och förståelse för god internkontroll inom företaget genom utbildning av berörd personal samt allmän information.

Samspelet med den externa revisionen kommer inte att behandlas i det följande. Ej heller nämner vi något om de speciella utredningsuppdrag som internrevisorn kan erhålla från företagsledningen. Vi behandlar alltså enbart frågor om hur internrevisorn skall lösa sina uppgifter inom de allmänna direktiv som vi angav ovan.

ARBETSOMRÅDEN

Med våra direktiv i bakfickan kan vi nu försöka definiera de olika arbetsområdena som ADB-revisorn kommer att möta:

  • Granskning av övergripande ADB-mässiga kontroller.

  • Granskning av ADB-baserade applikationer i drift.

  • Insatser i samband med systemutveckling.

  • Allmänna preventiva åtgärder, t ex utbildning och information.

Nu bör vi vara klara att diskutera varje arbetsområde i relation till de direktiv vi formulerat och samtidigt också belysa några av de praktiska problem som vi ofta möter.

GRUNDLÄGGANDE PÅSTÅENDEN

Innan vi dyker ner i detaljer är det på sin plats att vi klarlägger vissa grundläggande principer rörande ADB-revisorns roll. Låt oss göra följande påståenden:

  • ADB-revisorns arbete skall vara helt integrerat med internrevisionens övriga arbete vilket bör medföra att:

    • ADB-revisorn måste ha förståelse för hur övriga internrevisorer arbetar och fungerar.

    • Alla medlemmar i internrevisionsgruppen måste vara förtrogna med de grundläggande principerna för hur ett ADB-system är uppbyggt och fungerar.

    • Chefen för internrevisionsgruppen måste ha tillräcklig ADB-kunskap för att kunna planera, bevaka samt utvärdera det arbete som utförs av ADB-revisorn.

  • Internrevisionens insats på ADB-området skall stå i direkt relation till det ADB-kunnande den innehar. Att försöka ersätta kompetens med avancerade verktyg kan på sikt få en förödande inverkan.

  • Direktiven för ADB-revisorns arbete skall vara helt kända för de berörda parterna inom företaget. Detta gäller inte bara de allmänna direktiven som vi angivit ovan utan också de speciella direktiv som kan gälla inom enskilda arbetsområden. Motivet bakom detta påstående behandlas i den följande texten, framförallt under rubriken ”Systemutveckling”.

ÖVERGRIPANDE KONTROLLER

Vissa av ADB-revisorns frågor rörande ADB-systemen är av naturliga skäl gemensamma för bolaget eller installationen som helhet. Det är därför praktiskt att utforma ett särskilt arbetsprogram för granskningen av sådana övergripande kontroller.

All granskning bör naturligtvis vara målinriktad och avslutas med rapport om huruvida de uppställda målen nåtts eller ej. Låt oss som exempel citera de mål som de övergripande kontrollerna skall uppnå enligt vad som beskrivs i ”Computer Audit Guidelines” utgiven av The Canadian Institute of Chartered Accountants (härefter kallat ”CICA”):

  • Är de funktioner som koncentrerats till ADB-avdelningen väl segregerade inom denna avdelning?

  • Utövar företagsledningen effektiv kontroll över utnyttjandet av ADB-resurserna?

  • Beaktas alla relevanta bearbetningsalternativ när beslut fattas om datorisering av nya rutiner?

  • Utnyttjar företaget en effektiv metod för att kontrollera och styra systemutvecklingsprocessen?

  • Fungerar underhållet av system och program effektivt?

  • Tillämpas effektiva metoder för att förhindra eller upptäcka oavsiktliga fel som uppstått under databehandlingen?

  • Tillämpas effektiva metoder för att förhindra eller upptäcka uppsåtlig manipulering av data och för att förhindra obehörigt utnyttjande av sekretessbelagd information?

  • Har bolaget vidtagit effektiva åtgärder för att gardera sig mot oavsiktlig förstörelse av data och mot allvarligare driftsavbrott?

  • Har bolaget fastställt enhetliga och godtagbara standards för dokumentation av system, program och driftsinstruktioner?

Ett lämpligt frågeformulär är ett utmärkt verktyg för att styra granskningen av de övergripande kontrollerna. Förutom att frågeformuläret skall vara så strukturerat att slutsatser lätt kan dras beträffande de ställda må len bör även referens finnas till hur sakinformationen erhölls och till underliggande bilagor med detaljer. Vidare bör utrymme finnas för referenser till av revisorn utförda tester som gjorts för att förvissa sig om riktigheten av de erhållna uppgifterna.

En särskild rapport över granskningen av de övergripande kontrollerna är ofta önskvärd för att ”kalibrera” bedömningen med ADB-ansvarigas uppfattning innan man attackerar enskilda applikationer. Några praktiska anvisningar kan aldrig upprepas tillräckligt ofta:

  • Låt alltid ADB-ansvariga ta del av rapporten innan den utges och begär alltid deras skriftliga kommentarer. Många missuppfattningar kan elimineras med en sådan rutin.

  • All kritik skall vara konstruktiv. Om internrevisorn inte kan komma med ett konstruktivt förslag till åtgärd rörande en viss punkt bör punkten strykas i rapporten.

  • I de fall då ADB-ansvariga i sina kommentarer inte bifaller revisorns förslag till åtgärder och refererar till orimlig relation mellan kostnad för åtgärden och den potentiella besparingen bör revisorn inte i rapporten inkludera sådant förslag utan att underbygga detsamma med tillräckliga argument. Ofta kan det vara praktiskt att helt utelämna punkten till dess att man testat effekten av bristen inom en eller flera applikationer.

APPLIKATIONER I DRIFT

Även granskningen av applikationer i drift bör vara målinriktad. CICA talar om fyra olika mål för applikationsinriktade kontroller: 1) fullständighet, 2) riktighet, 3) behörighet samt 4) ”audit trail”. Praktiska skäl talar emellertid för att underordna dessa kontrollmål till förmån för applikationsinriktade mål. Om vi t ex granskade en rutin för orderbehandling, fakturering, reskontra och för färdigvarulager skulle vi helst vilja dra slutsatser på en nivå som kan exemplifieras av mål liknande:

  • Finns effektiv kontroll av att alla varor som lämnar lager blir föremål för fakturering?

  • Levereras varor enbart till kreditvärdiga kunder? ... etc.

Detta innebär att internrevisorn bör utforma skräddarsydda arbetsprogram (och ev frågelistor) för varje enskild applikation. Ett sådant arbetsprogram omfattar naturligtvis även alla manuella rutiner och får alltså representera ett integrerat granskningssätt.

ADB-revisorns roll vid granskning av applikationer i drift begränsas ofta till:

  • Att lämna råd och anvisningar i samband med utformningen av granskningsprogrammen.

  • Att biträda vid revisorernas utredning rörande systemets uppbyggnad och funktion.

  • Att genomföra tester med utnyttjande av dator.

  • Att utveckla förslag till ADB-mässiga åtgärder.

Beträffande rapportering gäller i stort sett vad som sagts rörande övergripande kontroller. Skillnaden ligger nu framförallt i att mottagaren vanligtvis är en användaravdelning och inte ADB-avdelningen som tidigare.

SYSTEMUTVECKLING

Att ta del i systemutvecklingsprocessen och direkt påverka utformningen är för ADB-revisorn den mest effektiva metoden, åtminstone teoretiskt, att få sina synpunkter accepterade och tillgodosedda. Många åtgärder som är tämligen enkla att genomföra under systemutvecklingsprocessen kan samtidigt vara mycket kostsamma om de genomförs när systemet gått i drift.

Tyvärr har det ofta visat sig att även i de sammanhang där internrevisorn tagit mycket aktiv del i systemutvecklingen har ändå resultatet varit otillfredsställande både när det gäller systemets slutliga utformning och när det gäller de inblandade parternas attityd. Vad kan nu detta bero på?

Om vi bortser från de fall där internrevisorn inte varit kompetent för uppdraget kan vi oftast hitta förklaringen i dålig eller obefintlig planering samt i bristande direktiv för vad revisorn egentligen skall göra i projektet. Även om man menar att revisorns blotta närvaro under utvecklingsskedet bör ha en positiv effekt så är nog fallet att ingen insats alls från internrevisionens sida är att föredra framför en halvhjärtad sådan. Det händer alltför ofta att defekta system går i drift trots internrevisorernas deltagande under systemutvecklingsskedet. Det farliga i sammanhanget är emellertid att de systemansvariga lätt kan tolka läget så vid idriftstagandet att systemet har fått en godkännandestämpel av revisorerna eftersom dessa inte framfört några allvarligare invändningar.

Receptet för att lyckas med insatsen under utvecklingsarbetet kan sammanfattas på följande sätt:

  • Formulera mål och delmål för internrevisorns insatser som på ett påtagligt sätt är kopplade till revisorns kompetensnivå, projektets natur och det sätt på vilket projektarbete bedrivs inom företaget.

  • Sätt i förväg upp kriteria för vad som krävs för att uppnå de mål och delmål som fastställts.

  • Undvik kvalitativa utlåtanden. Om bedömning av fattade beslut skall göras bör dessa grunda sig på huruvida relevanta beslutsunderlag varit för handen vid beslutstillfället.

  • Planera insatserna i detalj.

  • Se till att berörda parter är till fullo informerade om de direktiv som gäller för revisorns insatser i systemutvecklingsarbetet.

De arbetsmoment som ADB-revisorn kan utföra inom ramen för ett systemutvecklingsprojekt kan sammanfattas på följande sätt:

  • Granska projektdokumentationen och bedöm huruvida den står i överensstämmelse med de standards företaget fastställt.

  • Genomför en stegvis granskning och bedömning av den applikation som projektet avser, helt i enlighet med de riktlinjer vi drog upp tidigare för granskning av applikationen i drift.

  • Granska de system- och programtester som genomförs och utför vid behov egna tester som komplettering.

  • Granska arbetet kring omläggningen till det nya systemet.

  • Studera löpande de planer som upprättas för projektarbetet. Se till att projektansvariga blir medvetna om de krav som ställs på det system som utvecklas.

  • Acceptera aldrig formen att enbart ”sitta med” i projekt- och referensgrupper eller att utan förpliktelser ”ta del” i systemutvecklingsarbetet.

PREVENTIVA ÅTGÄRDER

Det ligger nära till hands att den ADB-kunnige revisorn, eller revisionskunnige ADB-specialisten, anlitas för att sprida kunskap och förståelse för ADB-mässiga kontrollmetoder. Det är inte bara användarna som behöver insikt i ämnet utan även systemmän och programmerare som i sin utbildning ofta helt saknar kunskap i grundläggande kontrollmetoder.

HUR INTRODUCERAS EN ADB-REVISOR I INTERNREVISIONSGRUPPEN?

Många försök att tillföra ett grundligt ADB-kunnande i internrevisionsgruppen har ömkligen misslyckats. I de fall man valt att satsa på en redan befintlig internrevisor och utsätta denne för intensiv utbildning och praktiskt arbete inom ADB-funktionen har det ofta hänt att den utvalde revisorn sadlat om eftersom han funnit att det ”rena” ADB-arbetet varit mer givande än internrevisionsuppgifterna. Då man rekryterat ADB-specialister har man ofta inte lyckats attrahera den kaliber av specialister som kan hävda sig mot ADB-teknikerna.

Ett praktiskt sätt att komma förbi svårigheterna är att starta ett projekt vars mål är att t ex utreda, bedöma och komma fram med konstruktiva förslag rörande generella arbetsmetoder inom företagets eller koncernens ADB-funktioner. Projektet bör förankras i direktiv som utfärdats av företagsledningen och bör bemannas med minst ett par ADB-specialister samt en eller flera representanter för internrevisionen. På så sätt kan man få en möjlighet att bedöma projektdeltagarnas lämplighet och samtidigt få ADB-ansvariga att vänja sig vid kritisk granskning av sitt arbete.

Gunnar Sjöquist, auktor revisor