ADB-Bulletin

I sin hittills femte ADB-Bulletin berättar FARs Databehandlingskommitté bl.a. om de alltmer spridda CASE-verktygen och om papperslös handel via Electronic Data Interchange (EDI). En annan viktig fråga: Hur kan brister i behörighetskontroll påverka revisionen? ADB-Bulletinen är en löpande avrapportering från kommitténs arbete och ska inte betraktas som rekommendationer eller uttalanden från FAR.

CASE – VAD ÄR DET?

Ordet CASE förekommer numera ofta i ADB-sammanhang. Det betyder Computer Aided Software Engineering. Det ska ses som ett samlingsnamn för verktyg för att utveckla system.

System- och programutveckling bör ju utföras systematiskt enligt en standardiserad metod och med automatiska hjälpmedel. Ett annat mål för systemutvecklingen är att höja kvaliteten på systemen och därigenom se till att slutprodukten klarar uppställda krav. Systemen måste också dokumenteras tillfredsställande.

CASE är den kedja av formella tekniker som används för att bygga upp modeller av verksamhetens data och funktioner. Modellerna förvaltas i en gemensam kunskapsbas (encyklopedi). Denna kan sedan utnyttjas för att skapa och underhålla databehandlingssystem.

CASE-verktygen är alltså hjälpmedel för att beskriva en verksamhet och dess rutiner (ofta grafiskt) och ur denna beskrivning ta fram datoriserade system. På köpet får man systemdokumentation, möjlighet till prototyping (funktionstest i begränsad miljö) och i vissa fall också en automatiskt framtagen programkod (Cobol, C, ADA m.fl.).

Figur: CASE är inte detsamma som 4GL

Inte samma sak som 4GL

CASE ska inte förväxlas med 4GL (4th Generation Language). I ett 4GL-verktyg ligger tyngdpunkten på att konstruera och realisera system. CASE-verktyg kan till skillnad från 4GL också användas för att analysera informationssystemen och normalt även grafiskt beskriva dem.

Bilden visar skillnaden mellan CASE- och 4GL-verktyg.

Lars Karlander, Industriell Datateknik, har ställt upp vissa krav för att få utnyttja benämningen CASE-verktyg.

Programmen ska enligt Karlander kunna grafiskt presentera data- och programflöden m.m., måla upp skärmbilder (layouter) för rapporter, skapa och underhålla en central databas (encyklopedi), kontrollera konsistens och fullständighet i databasen, generera programkod (Cobol etc) samt generera teknisk dokumentation och användarhandledningar.

CASE för olika miljöer

CASE-verktyg finns för olika miljöer såsom IBMs stor- och minidatorer, Vax, PC, Macintosh m.fl. Den främsta målgruppen för CASE-verktyg har varit större dataavdelningar och programvaruhus som själva utvecklar och underhåller system för större datorer. Verktygen har fått god spridning på marknaden därför att en stor del av utvecklingsarbetet för exempelvis stordatorer nu går att göra i PC-miljö. Färdiga system för en stordator kan först simuleras och testas i PC-miljö (prototyping).

CASE-verktygen ger normalt användarna ett mycket lättarbetat grafiskt gränssnitt av den typ som utmärker Macintosh-datorerna.

Fyra komponenter

CASE-verktyg består normalt av komponenterna Planering, Analys, Design och Konstruktion. När de här olika arbetsmomenten är klara kan kod genereras och systemet testas – antingen direkt genom prototyping eller efter överföring till stordatorn.

Planering innebär i regel att utveckla en modell för en organisations verksamhet och att identifiera den information som är basen för verksamhetens mål, funktioner och framgångsfaktorer. Vidare ska man fastställa en gemensam ram för att utveckla informationssystem i verksamheten och utveckla system som till grund har den strategiska planeringen i verksamheten.

Analysen omfattar utveckling av en detaljerad datamodell och en detaljerad processmodell för ett verksamhetsområde. Därtill ska områden för design av informationssystem identifieras.

Designstadiet innebär att med hjälp av grafiska verktyg göra design och specifikation av programstruktur, procedurlogik, skärmbilder, databasstruktur och utformning av rapporter. Slutanvändarna deltar aktivt i designprocessen.

Design, dokumentering och underhåll av system automatiseras.

Konstruktion betyder att kod både för program och databaser (strukturer) genereras automatiskt.

Påverkar revisionen

CASE kan påverka revisionen. Genom CASE-tillämpningar finns systemdokumentation med flödesbeskrivningar över system och program ständigt tillgängliga och aktuella på företagen.

CASE-verktygen genererar flöden även på en övergripande nivå. Det kan underlätta för revisorn att upprätta rutin- och systembeskrivningar.

Programmerarnas roll blir troligen mindre teknisk och mer analytisk och rutininriktad genom att de till stor del slipper arbeta med ren kodning. I stället kan de koncentrera sig på att utforma system (design).

CASE-verktygen bör, anser databehandlingskommittén, kunna underlätta för revisorn i hans arbete med att hjälpa klienter i systemutvecklingsarbete. CASE är också till hjälp när revisorn som ett led i revisionen ska dokumentera och förstå klienternas ADB-rutiner.

Brister i behörighetskontrollerna kan påverka revisionen

Ett företags information lagras och bearbetas numera i allt väsentligt i olika datasystem. Informationen används som underlag för åtgärder och beslut på alla nivåer i företaget. Ofullständig eller felaktig information kan leda till felaktiga beslut och åtgärder, som i förlängningen kan leda till att företaget drabbas av förluster. Datasystemen måste därför utformas så att de uppfyller krav på god intern kontroll.

Ett effektivt dataskydd förbättrar den interna kontrollen och krävs för att förhindra att känsliga eller konfidentiella data kommer i orätta händer. Ett bra dataskydd krävs också direkt eller indirekt av lagar och förordningar och syftar till att säkerställa att företaget inte förlorar data eller att data förvanskas eller avslöjas. Ett väl fungerande system för behörighetskontroll är ofta en viktig del av dataskyddet.

Revision av behörighetskontroller

Revisorn kan ha olika syften med att granska ett företags generella kontroller (där just behörighetskontroller ingår som en viktig komponent). Granskningen kan antingen ingå som led i förvaltningsrevisionen eller som en del i räkenskapsrevisionen. Arbetet kan också utföras som ett särskilt uppdrag utanför revisionen. Inriktning och omfattning styrs naturligtvis av syftet.

Väl fungerande behörighetskontroller är ofta av central betydelse i de fall revisorn i sin räkenskapsrevision tillämpar systembaserad granskning. Revisorn har då för avsikt att förlita sig på de generella kontrollerna i granskningen. Bra behörighetskontroller är då ett nödvändigt men inte tillräckligt rekvisit för att säkerställa dels att väsentliga funktioner och kontroller inte sätts ur spel i datorprogrammen (programsäkerhet) och dels att endast godkända data registreras i systemet samt att dessa data inte förvanskas när de är lagrade i registren (registersäkerhet).

Hur påverkas revisionen?

Det bör noteras att en analys av hur revisionen påverkas vid brister i behörighetskontrollerna endast kan göras för det enskilda fallet. Dessutom är det så att en i övrigt godtagbar nivå på den interna kontrollen inte i grunden behöver sättas ur spel av brister i program- och registersäkerheten.

En övergripande analys av hur revisionen påverkas vid brister i behörighetskontrollerna kan exempelvis göras genom att betrakta risken för avsiktliga fel (brott – fraud) och risken för oavsiktliga fel (misstag – error).

De flesta hot som kan identifieras vid en sådan analys är förknippade med risken för just avsiktliga fel. Risken för ”databrott” diskuteras allt oftare i olika sammanhang. Det viktigaste skälet till att ha bra program- och registersäkerhet samt god kontroll över bolagets tillgångar är att skydda företaget mot förskingringar och/eller förlust av tillgångar.

Oavsett vilka åtgärder som vidtas för att skydda företaget mot förskingringar och/eller förlust av tillgångar krävs dock ett minimum av program- och registersäkerhet för att man skall kunna skydda sig mot oavsiktliga fel. Sådana fel kan t.ex. uppstå när i och för sig godkända transaktioner registreras men med hjälp av felaktiga funktioner i systemet.

De avsiktliga felen kan exempelvis delas in i följande kategorier:

* Förskingring och bedrägeri. Förskingringar som utförs av anställda torde utgöra den största risken.

* ”Försköning”/Förfalskning av räkenskaper, s.k. ”Management Fraud”.

* Obehörigt utnyttjande av resurser.

Förskingringar som utförs av anställda utgör en källa till problem för företagsledningen, varför svagheter som kan resultera i brott bör rapporteras till företagsledningen.

Tillgrepp (stöld) av ett företags tillgångar kan döljas genom manipulation av bokföringsdata. Brister i registersäkerheten kan möjliggöra sådan manipulation. Utom i vissa speciella branscher är risken för väsentliga fel i bokslutet liten. Väl fungerande rutinorienterade kontroller bör dessutom försvåra större tillgrepp och därigenom minska risken för avsiktliga fel ytterligare.

”Försköning”/Förfalskning av räkenskaper kan göras i syfte att vilseleda omvärlden beträffande företagets resultat och ställning och får därigenom väsentlig betydelse för revisionen. ”Försköningar” kan göras på företagsnivå eller inom en division/resultatenhet. Denna typ av brott uppmärksammas normalt inte av den interna kontrollen men lite tillspetsat skulle man kunna påstå att tillvägagångssättet och omfattningen i den numera klassiska ”Equity Funding”-svindeln knappast varit möjlig om goda kontroller funnits.

Risken för förskingring varierar kraftigt mellan olika företag och branscher. Inom finanssektorn är riskerna och följaktligen kraven på säkerhet mycket höga eftersom tillgångarna är lätta att omsätta och kunderna kräver att dessa skyddas. Kunddata är också mycket känsliga. Det bör dock påpekas att inom nästan alla företag finns det vissa rutiner (t.ex. utbetalningsrutiner) där risken för förskingringar är högre än i andra rutiner.

Revisionen har inte som självständigt syfte att uppmärksamma förskingringar eller andra brott. Revisorn skall i sin granskning i stället utgå från att brott inte föreligger men man bör vara uppmärksam på tecken som kan tyda på att brott ändå har skett.

Om det visar sig att det finns brister i program- och registersäkerheten och revisorn bedömer risken för väsentliga fel i bokslutet som inte försumbar, finns följande alternativ för fortsatt granskning:

* att överge ett systembaserat granskningsupplägg för en ansats som baseras på ren substansgranskning

* att identifiera och testa viktigare funktioner i programmen som har avgörande betydelse för den interna kontrollen

* att identifiera program som förändrats under perioden och granska förändringarna mot olika typer av underlag

* att överväga om de rutinorienterade kontrollerna kan kompensera de identifierade svagheterna.

Slutsats

En i övrigt godtagbar nivå på den interna kontrollen behöver inte i grunden sättas ur spel på grund av brister i program- och registersäkerheten. System och rutiner som uppfyller krav på god intern kontroll kan resultera i att merparten av de oavsiktliga felen och en del av de avsiktliga felen uppmärksammas. En godtagbar nivå på den interna kontrollen innebär också att substansgranskningsinsatserna kan göras mera selektiva och välriktade.

EDI – papperslös handel

För de allra flesta av oss är EDI – Electronic Data Interchange – ännu ett okänt begrepp.

EDI avser utbyte av strukturerad handelsinformation mellan datorsystem hos olika parter. I praktiken är EDI elektroniska rutiner som ersätter manuell administration. EDI är således inte enbart en fråga för dataavdelningen, utan är aktuellt för alla funktioner inom ett företag. Fördelen med EDI är bl.a. kortare genomloppstid och enklare hantering av information.

Spridningen av EDI är i gång i Sverige men vi ligger fortfarande långt efter andra länder.

Standardisering av meddelanden är mycket viktig för en framgångsrik spridning av EDI. Detta illustreras bäst om man tänker sig två företag som beslutat sig för att använda EDl för ömsesidig överföring av t.ex. order. Båda företagens datorsystem medverkar i processen, vilket troligen medför att man på respektive sida behöver översätta (konvertera) informationen från motparten till det egna datorsystemets standard. Om ytterligare företag med olika datorsystem involveras måste samtliga inblandade anskaffa eller utveckla översättningsprogram för de andra parternas standarder. Ju längre man går i denna spridning, ser man snart att de praktiska omständigheterna blir ohållbara. Det är mot denna bakgrund lätt att inse betydelsen av en gemensam EDI-standard för utformning av elektroniska meddelanden.

Internationellt pågår därför ett omfattande arbete i syfte att skapa generella standards för elektroniskt informationsutbyte.

Hur påverkar spridningen av EDI kontrollmiljön hos företagen?

Traditionellt kontrollerar vi underskrifter för att styrka vem som står bakom ett dokuments innehåll. Vi kan i juridisk mening inte utan vidare påstå att någon annan har utformat eller skrivit under dokumentet.

I den elektroniska miljön används datorer för att skapa dokument, kommunicera informationen via öppna datanät etc.

Kan vi påstå att meddelanden lagrade i datafiler och skickade via kommunikationsnät är lika säkra som informationen på ett underskrivet papper? Upphovsmannen kan naturligtvis hävda att meddelandet förvanskats någonstans i den elektroniska kommunikationskedjan mellan sändande och mottagande datorsystem.

Man kan lockas att tro att kryptering ensamt löser problemet. Används bara traditionell kryptering som stöd i denna process, är det dock så att mottagaren i och för sig inte kan starkare bevisa äktheten i ett dokument utan bara att informationen varit konfidentiell under den tid den transporterats mellan avsändare och mottagare.

Ett exempel på lösning av signaturproblemet (underskriften) är en s.k. asymmetrisk krypteringsmetod. Metoden använder sig av två nycklar, en privat och en allmänt tillgänglig. Finessen med detta är att avsändaren av ett dokument använder sig av en privat nyckel som den som tar emot dokumentet ej behöver känna till för att dekryptera innehållet. I den privata nyckeln finns ett sammanfattningsdokument som innehåller ett visst värde. Vid dekrypteringen kontrolleras detta värde och mottagaren kan därigenom försäkra sig om att dokumentet ej har förvanskats eftersom de numeriska värdena fortfarande är lika.

Det återstår många problem att lösa i samband med att EDI får en mer allmän spridning. Några områden som måste uppmärksammas är bl.a. den allmänna nyckelhanteringen och administrationen kring denna. Hur skall detta gå till och av vem skall det ombesörjas? Dessutom måste säkerheten kring nyckelhanteringen ute i organisationer och företag hållas på en tillräckligt hög nivå. Kanske kräver detta lokala åtgärder långt utöver vad som idag är infört för övrig informationsbehandling?

Slutsats

EDI kan för företagen betyda en viktig möjlighet till rationell informationshantering. Revisorskåren måste å sin sida ta ställning till och utveckla granskningstekniker, såväl datoriserade som manuella, för att möta EDI-systemens speciella revisionsproblematik.

DATABEHANDLINGSKOMMITTÉNS MEDLEMMAR

Tommy Mårtensson, ordförande, Peters & Co, Stockholm, Tomas Ahlgren, SET, Malmö, Anders Hult, Öhrlings Reveko, Stockholm, Torsten Lyth, Hagström & Olsson, Stockholm, Anders Malmeby, Bohlins, Stockholm, Per Wardhammar, Öhrlings Reveko, Stockholm.