Balans nr 7 1984

Revision: Så här utvärderas datoriserade order-, lager- och faktureringssystem

Behörighet, funktionsduglighet och ändamålsenlighet bör ägnas speciell uppmärksamhet vid utvärdering av ett terminalorienterat datasystem.

Det skriver Tommy Mårtensson vid Arthur Andersen & Co Revisionsbyrå AB i denna artikel. Han betonar att det inte finns några generella kontrolltekniker som i varje system direkt leder till en bra kontrollmiljö.

Av olika skäl använder sig flertalet företag av standardsystem i sin dataverksamhet. För de mindre och medelstora företagen sker detta främst av kostnadsskäl. Företagets verksamhet är inte tillräckligt omfattande för att ekonomiskt motivera egen utveckling av system.

För att fylla detta systembehov hos företagen finns därför ett flertal standardsystem med olika funktioner att köpa på marknaden, en del mer eller mindre bra. Det enskilda företaget måste därför vara mycket omsorgsfullt i sin upphandling av standardsystem, då flexibilitet, prestanda, inbyggda kontroller och leverantörsservice kan variera betydligt mellan systemen.

Vanligt förekommande standardsystem är system för att hantera ett företags rutiner för order, lager och fakturering (OLF). OLF-systemet är av särskilt intresse för varudistribuerande företag, då det är det centrala systemet i deras verksamhet. Med detta system styr de sin verksamhet, från kundorder till leverans. Samtidigt erhåller de som regel all sin redovisning från detta system, bortsett från löneredovisningen.

Även tillverkande företag har någon form av OLF-system, till vilket ett produktionssystem är kopplat.

Hur ser då ett typiskt OLF-system ut? Även om dess detaljutformning skiftar från företag till företag, kännetecknas ett modernt OLF-system i regel av följande:

– Systemet är företagsanpassat/skräddarsytt utifrån ett standardsystem

– Modulärt system, d v s möjligheter att använda olika funktioner i ett fullständigt OLF-system

– Terminalorienterat system, d v s registrering sker via bildskärm transaktion för transaktion (on-line-registrering)

– Användarvänligt system genom att bildskärmar med på förhand bestämd indata används

De moduler som vanligtvis ingår i ett mera fullständigt OLF-system är:

– Order/leverans. Registrering av kundorder och uppföljning av kundorder till utleverans

– Beställning/inköp. Registrering av beställningar och uppföljning av dem fram till inleverans samt lagerstyrning

– Kundreskontra och fakturering

– Leverantörsreskontra

– Statistik

– Registervård, d v s ändring, nyuppläggning och borttagande av registerposter.

Dessa moduler är oftast integrerade, så att en transaktion som registreras i en modul samtidigt uppdaterar ett register i en annan modul. Ett exempel härpå är att en registrerad kundorder uppdaterar artikelregistret för reservation av artiklar för utleverans. Detta kan i sin tur leda till att beställning från leverantör initieras via registrerad lagerreservations- och styrningsinformation.

Redovisningen sker oftast automatiskt i samband med registrering av information i de olika modulerna. Så kan registrering av leverantörsfaktura i modulen för leverantörsreskontra leda till att fakturan automatiskt åsätts ett huvudboksverifikationsnummer. Samtidigt lagras den i ett särskilt verifikationsregister för månadsvis uppdatering/utskrift av dagbok och huvudbok.

Antalet terminaler som används i systemet kan variera från företag till företag. För ett medelstort företag med mera omfattande varudistribution, typ grossistföretag, kan antalet vara mellan 10 och 25 terminaler.

Ett större antal terminaler förutsätter att företagets datadrift sker åtminstone i minidatormiljö, vilket också är normalfallet för flertalet medelstora företag samt ett antal mindre företag. Jag har därför i denna artikel utgått från att OLF-systemet opererar i minidatormiljö. Då ett antal mindre företag har ett OLF-system som opererar i mikrodatormiljö, har jag nedan kortfattat beskrivit olikheter i kontrollmiljö för mikro- och minidatormiljön och vad det innebär för systemutvärderingen.

Även om OLF-systemet ger ett företag ett flertal möjligheter att både styra och effektivisera sin verksamhet, innebär det också ett flertal risker. Företaget bör därför uppmärksamma dessa risker. Så även dess revisorer, då ett flertal av riskerna kan innebära bristande intern kontroll i företagets system samt leda till väsentliga revisionsproblem. Dessutom är genomgång/utvärdering av ett företags OLF-system ett område där den mera datainriktade revisorn kan bidra som konsult.

Vilka områden bör då särskilt utvärderas för ett terminalorienterat OLF-system?

Systemutvärdering – syfte och omfattning

Liksom övriga tjänster vi revisorer utför för våra uppdragsgivare, kan syfte och omfattning för utvärdering av terminalorienterat OLF-system variera alltifrån en revisionsgenomgång till en genomgång av specifika delar av systemet på företagets egen begäran.

Revisionsgenomgången bör ske i samband med revisionens planering. Den bör vara en del av revisorernas riskanalys, i synnerhet om företagets system i hög grad är datoriserade. Användning av ADB påverkar då väsentligt företagets kontrollmiljö och kan ej förbises i en mera övergripande analys av risker/problem vid en revision.

Hur utvärderingen av ett företags datasystem skall ske i detalj är givetvis i hög grad beroende av hur systemet är uppbyggt. Men för att knyta an till det terminalorienterade OLF-systemet, har jag i tabell 1 sammanställt olika områden vilka bör täckas vid en utvärdering av ett terminalorienterat datasystem.

Tabell 1. Områden för utvärdering i ett terminalorienterat minidatorsystem

  1. Organisatoriska kontroller

    • Tekniker för att definiera och kommunicera ADB-funktionens rutiner och policies

    • Tekniker för arbets- och ansvarsfördelning inom dataavdelning/dataoperatör och mellan denna och andra avdelningar inom företaget

  2. Systemunderhåll och -utveckling

    • Systemunderhåll och -utveckling godkänns av både användare och ADB-ledning

    • Test, dokumentation och införande av nya system

    • Kontrollerad tillgång till systemdokumentation

  3. Behörighetssystem

    • Fysisk behörighet avseende tillgång till drift, terminaler samt systemdokumentation kontrollerad

    • Behörighet avseende datafiler och -program kontrollerad

  4. Drift, dvs drift sker endast på behörigt sätt och enligt fastställda rutiner

  5. Säkerhetskopiering av data och program

  6. Allmänna indata-, bearbetnings- och utdatakontroller för applikationssystemen

Även om samtliga dessa områden bör genomgås kräver i regel rutinerna för ansvars- och arbetsfördelning mellan dataavdelning/dataoperatör och övriga avdelningar, behörighetssystemet samt indata- och bearbetningskontroller särskild uppmärksamhet i ett sådant system. Detta hänger samman med att all registrering i systemet sker transaktionsvis och ibland i realtid, d v s register uppdateras i samma ögonblick som transaktioner registreras. Kontroller för att förhindra felaktigheter redan i samband med terminalregistrering måste därför finnas. Om inte, är det oftast för sent att reparera den skada som redan skett.

Övriga områden för utvärdering bör givetvis genomgås, men kräver i regel mindre arbetsinsats. Då flertalet mindre och medelstora företag inte har någon egen omfattande systemutveckling utan anlitar en utomstående konsult/mjukvaruleverantör härför, är riskerna för systemfel begränsade till tidpunkter för mera omfattande systemändringar. Men när dessa ändringar sker, är det viktigt att revisorn noggrant går igenom deras innebörd och företagets kontroller före deras genomförande.

Tidsinsatsen för revisionsgenomgången är normalt begränsad till mellan en halv till två mandagar beroende på systemets omfattning och komplexitet. Denna tidsinsats är tillräcklig för att uppnå målsättningen med genomgången – att identifiera större risker/problem att beaktas i revisionens uppläggning och att avrapporteras till klient. Denna begränsade tidsinsats – med tanke på de risker ADB-systemet kan innebära för ett företag – måste anses både skälig och försvarbar från revisionssynpunkt och inte minst med tanke på klientservice.

För den som är intresserad av att ytterligare fördjupa sig i hur revisionsgenomgången och revisorns granskning i praktiken bör ske i ett OLF-system i minidatormiljö, kan jag rekommendera att delta i IREVs datakurs Minidatormiljö – systemgenomgång och granskningsåtgärder.

Revisionsgenomgången av ett företags ADB-system kan leda till att behov av en mera fördjupad genomgång av ett visst område/aspekt av systemet identifieras. Men en sådan separat genomgång kan också begäras direkt av företaget, då man upplever att systemet ej fungerar tillfredsställande och har noterat olika indikationer därpå. Vilka problem i ett terminalorienterat OLF-system kan då indikera att systemet ej fungerar tillfredsställande samt vilka risker medför problemen och vilka kan deras orsaker vara?

Tänkbara problem

Tänkbara problem vid användningen av ett terminalorienterat OLF-system har sammanställts i tabell 2. Dessa kan indelas i tre huvudgrupper: behörighet, systemets funktionsduglighet samt dess ändamålsenlighet. Som nämnts ovan bör de två första grupperna ingå, åtminstone mera översiktligt, i en revisionsgenomgång. Vilka kontroller/aspekter bör då uppmärksammas vid utformningen av företagets OLF-system för att undvika dessa problem?

Tabell 2. Några större problemområden vid användning av ett terminalorienterat OLF-system

PROBLEMINDIKTATION

Behörighet:

  • Förluster/oegentligheter

  • Register ej korrekta

Funktionsduglighet:

  • Detaljlistor för olika konton, såsom lager, kundfordringar etc, överensstämmer ej med huvudbokskonton

  • Statistik såsom bruttomarginaler, inventeringsdifferenser etc, ej rimlig

  • Huvudboks- och resultatrapporter ej tillförlitliga

Ändamålsenlighet:

  • Rapporter används ej eller följs ej upp

  • Rapporter framställs manuellt utanför system

  • Företagsledningen kan ej förklara olika affärsmässiga samband

RISK

Behörighet:

  • Förluster för företaget

  • Registervård sker av obehöriga

Funktionsduglighet:

  • Programlogik fungerar ej

  • Integration mellan olika OLF-moduler fungerar ej

  • Validering vid indataregistrering otillräcklig

Ändamålsenlighet:

  • Ej ändamålsenliga rapporter från systemet för uppföljning och styrning av företagets verksamhet

  • Bristfällig affärsinformation till företagsledningen, t.ex. bruttovinster per produktgrupp säljare etc.

ORSAK

Behörighet:

  • Behörighet/ansvarsfördelning olämplig

  • Behörighetssystem följs ej

  • Användning av hjälpprogram kontrolleras ej

Funktionsduglighet:

  • Bristfällig systemtest innan systemet togs i drift

  • Standardsystemet medger ej omfattande validering vid registervård

Ändamålsenlighet:

  • Olika användare har ej varit tillräckligt involverade i systemutformning

  • Informationsbehovet ej väl definierat

Kontrollerad systembehörighet

Terminalerna är normalt placerade på olika platser inom företaget och ibland på olika orter. Risken för obehörig åtkomst till systemet är därför stor och måste kontrolleras. De olika OLF-standardsystemen har inbyggda system för behörighetskontroll. Detta garanterar emellertid ej att behörigheten är väl kontrollerad, då ett behörighetssystem liksom arbetsfördelning i ett manuellt system kan läggas upp på ett mer eller mindre lämpligt sätt. Vid uppläggningen av OLF-systemets behörighetssystem bör därför följande aspekter beaktas:

– Behörighetssystemet tar hänsyn till en lämplig arbets- och ansvarsfördelning

– Behörighetskoder ändras frekvent och skall vara lämpligt utformade

– Terminaler är försedda med lås

– Terminaler är placerade i övervakade områden

– Behörighetskod syns ej på skärm

– Terminal släcks ned viss tid efter avslutad registrering

– Terminaler kan användas endast under vissa tidpunkter på dagen

– Användningen av terminaler är begränsad till definierade menyer/funktioner inom applikationssystem

– Användares behörighet är begränsad till definierade menyer/funktioner

– Användning av terminaler loggas av systemet och genomgås regelbundet så att försök till obehörig användning upptäcks.

Ett särskilt problem i minidatormiljön som sällan uppmärksammas är behörighet att använda olika hjälpprogram (s k utilities) med vilka både dataprogram och -register kan ändras utan att några spår lämnas. Dessa hjälpprogram är effektiva hjälpmedel i företagets dataverksamhet och används därför. Men de innebär samtidigt en risk för företaget – i synnerhet ifall endast ett fåtal personer handhar datadriften – och deras användning måste därför kontrolleras och följas upp. Detta kan ske exempelvis genom att användningen av dessa hjälpprogram löpande loggas och logginnehåll genomgås för behörigt användande.

Systemets funktionsduglighet

Kan vi lita på systemet? Denna fråga känner många revisorer igen. Även om denna fråga för ett terminalorienterat system inrymmer även behörighetskontrollsystemet, förknippar vi revisorer oftast denna fråga med systemets funktionsduglighet, d v s fungerar systemet som det är tänkt.

Kontroller för att eliminera riskerna i samband med ett systems bristande funktionsduglighet är i hög grad relaterade till företagets rutiner för test innan ett nytt system eller ändringar i ett befintligt system tas i drift. För upphandlade standardsystem sker dessa tester oftast av en utomstående konsult, varför det är viktigt att konsulten väl dokumenterar och går igenom utförda tester med någon kontaktperson från företagets sida.

Riskerna för att systemet ej kommer att fungera ökar ju mer omfattande anpassning av standardsystemet till företagets behov som behöver ske. All anpassning kräver omprogrammering av ett från början testat och fungerande standardsystem. Den ändrade programlogiken p g a omprogrammeringen måste således testas för att tillförsäkra att systemet utför avsedda uppgifter.

Som nämnts ovan är indata- och bearbetningskontroller mycket viktiga i ett terminalorienterat system. Det gäller ju att fånga felen vid källan; om inte är det oftast för sent. Då dessutom vissa funktioner i systemet opererar i realtid, är risken för felaktig och ofullständig registrering stor om indata- och bearbetningskontrollerna är bristfälliga. Exempel på olika indata- och bearbetningskontroller (förutom behörighetskontroller, se ovan) har medtagits i tabell 3. Tyvärr kan någon generell rekommendation avseende vilka indata- och bearbetningskontroller som bör finnas ej ges. De kontroller som behövs för varje specifikt företag är helt beroende av hur systemet i övrigt är uppbyggt.

Tabell 3. Exempel på indata- och bearbetningskontroller i ett terminalorienterat system.

INDATAKONTROLLER

  • Om lämpligt, bearbetning av godkänd on-line indata sker satsvis och avstäms mot kontrolltotaler

  • Transaktioner loggas i en transaktionsfil med datum, tid och användaridentifikation

  • Vissa väsentliga fält har bestämda övre/undre gränser avseende indatavärden (t ex bruttomarginal, rabattsats)

  • Bildskärmar med på förhand bestämda indata används för att vägleda användaren vid dataregistrering och för att till- försäkra att all data blir införd

  • Validering av olika fält sker av applikationsprogrammet. Exempel härpå är kontroll av att enbart siffror registreras för ett numeriskt fält

  • Felaktiga indatadokument följs upp manuellt

  • Felaktigheter noteras vid indataregistrering och rättas i samband därmed

BEARBETNINGSKONTROLLER

  • Transaktioner valideras innan bearbetning gentemot huvudregister innehållande godkända kunder, leverantörer, lagerartiklar etc

  • Indatadokument avseende ändringar i huvudregister är förnumrerade och kontrolleras

  • Indatadokument avseende ändringar i huvudregister skall vara behörigen godkända innan de registreras och bearbetas

  • Begränsat antal personer kan ändra i huvudregister

  • Dataprogram räknar fram kontrolltotaler för varje utdatafil. Dessa totaler kontrolleras sedan av varje program som läser filen

  • Program för uppdatering av huvudregister avstämmer indataregister och transaktioner med utdataregister

  • Dataprogram utför rimlighetsberäkningar av resultat av kritiska beräkningar

  • Felaktigheter under bearbetning rapporteras av systemet och uppföljning av fel noteras manuellt i en logg

  • Operatören känner till rutiner för att rekonstruera register och program efter bearbetning och/eller registerförstörelse (återstart- och återhämtningsrutiner)

  • Kopia av applikationsprogram på disk eller magnetband finns och förvaras på annat ställe

  • Speciella tekniker finns för att hålla reda på senaste bearbetad transaktion före driftavbrott

Är systemet ändamålsenligt?

Detta problemområde förbises oftast, både av företaget självt och deras konsulter vid installation av nytt system. Att så sker är märkvärdigt, då det primära syftet med ett datoriserat OLF-system är att täcka ett informationsbehov och förhoppningsvis på ett bättre sätt än tidigare. För att råda bot på detta problem krävs att företagets ledning och olika användare på ett tidigt stadium i införandet av ett nytt OLF-system identifierar sitt informationsbehov från systemet. Därefter sker en anpassning av standardsystemet för att det skall kunna möta detta informationsbehov.

Det är därför viktigt att både företagsledning och olika användare engagerar sig vid införandet av ett nytt OLF-system. Om ej, riskerar man efterföljande programändringar, manuella kringrutiner samt en negativ attityd till det nya systemet av företagets anställda.

Mikrodatormiljön

Som alltid är det svårt att skilja på vad som är mikro- eller minidatormiljö. Men vid utvärderingen av ett datoriserat system är denna skillnad endast semantisk. Endast systemets egentliga utformning har någon betydelse för utvärderingen.

För mikrodatormiljön är dock enarbetsstationer vanligast. Både registrering och bearbetning sker i samma maskin, d v s maskinen utför både terminal- och processorfunktionerna i ett minidatorsystem. Oftast har företaget flera mikrodatorer vilka ej är sammankopplade.

Generellt kan man utgå ifrån att kontrollerna i mikrodatormiljön är sämre än i minidatormiljön. Orsakerna härtill kan vara flera såsom:

– Användning av mikrodatorerna övervakas ej. Kontroll av behörighet är därför begränsad.

– Användning och förvaring av disketter är ej kontrollerad. Detta innebär att ändringar i program och register ej följs upp.

– Driftsrutiner finns ej och driften kontrolleras ej. Användning av felaktiga program och register i driften kan därför ske.

– Standardsystem erbjuds av ett flertal leverantörer och är av olika kvalitet. Detta innebär att programlogik, inbyggda indata- och bearbetningskontroller etc kan vara otillfredsställande.

– Säkerhetskopiering och förvaring av program och register kan vara bristfällig.

Detta kan givetvis innebära väsentliga risker från revisionssynpunkt och att revisorn ej helt kan förlita sig på företagets rutiner, utan måste genom andra granskningsåtgärder förvissa sig om att företagets redovisning är riktig.

Det bör i detta sammanhang observeras att flertalet av dessa brister i kontrollmiljön kan avse begränsningar i maskin- och mjukvara och betyder ej att företaget är ointresserat av god ordning och kontroller. Emellertid kan en del av dessa brister delvis motverkas genom införande av olika manuella kontroller, såsom avstämningar av olika slag, förbättrad arbetsfördelning etc, vilket bör uppmärksammas av både företaget och dess revisor.

Framtidsperspektiv

Den snabba tekniska utvecklingen inom dataområdet innebär nya möjligheter till mera effektiva och ändamålsenliga system. Men samtidigt innebär den nya risker från kontrollsynpunkt. Dessa kräver i sin tur nya kontrolltekniker.

Det talas idag om system där mikrodatorer är sammankopplade eller kopplade till större datorer. Vidare blir realtidstillämpningar allt vanligare. Att dessa system innebär nya och särskilda kontrollbehov kan nog alla inse.

Liksom idag kommer olika kombinationsmöjligheter vad beträffar maskinvara, mjukvara och användarrutiner att innebära att utvärderingen av datoriserade OLF-system måste ske utifrån ett specifikt system. Det finns ej några generella kontrolltekniker vars tillämpning kommer i varje system att direkt leda till en bra kontrollmiljö.

I framtiden kommer allt fler kontroller att byggas in i själva datasystemen, både i maskin- och mjukvara, vilket kommer att göra utvärderingen av dessa mera komplex. Att förstå dessa kontroller och hur de påverkar företagets kontrollmiljö kommer att bli ett måste och en nödvändighet för revisorn. Möjligheterna att som idag till viss del förlita sig på kontrollerna utanför maskinen kommer att bli alltmer begränsade.

Tommy Mårtensson, auktoriserad revisor, Arthur Andersen & Co Revisionsbyrå AB i Stockholm