Förarbetet

I själva förarbetet har huvudsakligen allt arbete skötts från Storbritannien, med undantag för ett par småsaker har skötts från de lokala kontoren, så som undersöka de lokala riskerna, samt allo- kera monetära medel för investeringen. Detta är till skillnad från själva implementeringsarbetet som har skötts på nationell nivå i samarbete med den tredjeparten GRC Nordic. Vid samtal av GRC Nordic är implementeringsarbetet på ABB väldigt olikt det arbete som de har utfört åt andra kunder. GRC Nordic menar på att implementeringen av version 10 hos ABB från deras perspektiv är ett renodlat IT-projekt, då allt arbete med risker och segregering av uppgifter sker internt på ABB, till skillnad från andra kunder som GRC Nordic jobbar med utformning av riskmatris och segregeringsmatris. Anledningen till detta är det faktum att implementeringen av GRC v.10 är ny för ABB, så är inte verktyget GRC det. Det finns sedan tidigare riskmatris och segregeringsmatris, mer om detta tar författarna upp i stycken nedan.

Fas 1. Vid första fasen i implementeringsprocessen krävs det ett gediget förarbete angående vil-

ken leverantör man ska använda sig av för att kunna maximera sin nytta av GRC kopplat till det ERP-system som företaget har som grund. För ABB som redan har ett ERP-system från SAP (ECC 6) med en Oracle databas i grunden. Vid implementeringsprocessens start körde ABB Ltd redan en äldre GRC applikation i form av v.5.2. Förarbetet för ABB handlade snarare om huru- vida uppdateringen av GRC skulle bli till den uppdaterade versionen av den applikation de redan körde, i så fall den uppdaterade v.5.3 som byggde vidare på v.5.2. Alternativt skulle ABB uppda- tera till den helt nya versionen, då detta implementeringsarbete ska se över hela regionen (Storbri- tannien, Norge, Finland och Sverige).

De skandinaviska länderna hade inte tidigare använt sig av någon GRC-applikation tidigare, utan hade tidigare använt sig av manuella kontroller i ett så kallat spreadsheet. Därför behövdes det en lösning som skulle passa alla regionens länder, som standardlösning. Dock skulle de olika länder- nas nationella lagkrav variera.

Enligt GRC-ansvarig för ABB Ltd, var v.10 den version av GRC som var mest lämpad för en så- dan process och ABB valde då att väja den senaste versionen, v.10.

Fas 2: Eftersom implementeringsarbete skulle vara ett omfattande arbete samt väldigt kostsamt,

var det då viktigt att länderna i regionen var insatta i vad som skulle ske och krävas av dem. Vad det kommer att kosta samt att se till att de likvida medlen finns för processen. Detta skötes från England i samarbete med intern kontrollsansvarig i varje land i regionen. När de likvida medlen var säkrade, samt att det fanns en förståelse ute bland de andra ansvariga av intern kontroll inne-

förstådda på vad GRC var och vad det skulle innebära för deras organisation kunde man då gå vidare till nästa fas.

Fas3: Nästa steg var att bestämma varifrån implementeringsarbetet skulle börja. Det är ett omfat-

tande jobb att implementera GRC, detta måste då ske stegvis och ett land i taget. Projektgruppen i England utvärderade då kunskap och erfarenhet av de olika ländernas GRC arbete inom regio- nen. Det var bara två länder som tidigare hade kört någon form av GRC. Detta var Storbritanni- en som körde v.5.2 och Schweiz som körde v.5.3. De andra länderna i regionen har bara tidigare kört ett spreadsheet och skött det som GRC gör manuellt istället. Så utgångspunkten för detta omfattande implementeringsarbete skulle bli antingen Storbritannien eller Schweiz. Schweiz hade tidigare jobbat lite mer omfattande med GRC och har två stycken heltidsanställda som bara job- bar med arbetet med GRC till skillnad från Storbritannien som inte hade arbetat lika intensivt med GRC och ansvarig för GRC är en IS security and Compliance manager. Var tjänsten bara består till en del av GRC-arbete.

ABB Ltd valde att utgå ifrån Schweiz som en modell för detta implementeringsarbete, då det här ABB:s huvudkontor ligger och det är detta kontor som har använts sig längst av GRC-verktyg, och därför har den bäst utarbetade grunden i hela koncernen. Detta följdes sedan av en imple- mentering i Storbritannien, Norge, Finland och slutligen kommer implementeringsarbetet ske i Sverige i maj 2012. Eftersom målsättningen med implementeringsarbetet av GRC var att samma applikation skulle köras över hela regionen, var det också viktigt att alla ländernas GRC applika- tioner skulle vara kopplade till samma servrar. ABB har vad de kallar deras strategiska datacenter nere i Eigen, Tyskland. Vilket också skulle ligga som bas för alla länderna i regionens applikatio- ner.

Fas 4: Efter att ha utvärderat den interna kompetensen blev det tydligt att för att kunna sköta

detta implementeringsarbete så smidigt som möjligt, behövdes det en tredjepart som skulle jobba med det praktiska arbetet med att implementera applikationen. Det skulle krävas hög kompetens, kompetens som ABB själva saknade inom området för att kunna sköttas så felfritt som möjligt. ABB tog då in offerter från totalt fyra bolag som jobbar med konsulttjänster inom SAP och/eller GRC. När offerterna hade kommit in, började då arbetet med vilken tredjepart ABB skulle välja. Pris ställdes mot erfarenheter och meriter. Vilken tredjepart ABB skulle välja var väldigt viktigt, inte bara för att det skulle bli kostnadseffektivt och rätt från början, men också på grund av om- fattningen i arbetet. Implementeringen skulle ske över hela regionen och det var därför väldigt viktigt att den tredjepart ABB skulle välja skulle klara av ett så omfattande arbete samt kunna prestera väl under tiden de gör detta. I slutändan valde ABB ett konsultbolag i Finland som job-

bar med affärssystemet SAP men är huvudsakligen ett konslutbolag inom GRC. Detta bolag är GRC Nordic.

4.4.2 Implementeringsarbetet

Fas 5: I fas fem börjar det tekniska arbetet med implementeringen, denna fas kallas Risk contai-

ning och i denna fas utvecklar ABB en riskmatris och ett riskramverk för att undersöka vilka ris- ker det finns för företaget och vilka risker man är ute efter att åtgärda med GRC verktyget. I själva riskmatrisen undersökes ett antal faktorer, dels går man igenom riskgrupperna. Dessa riskgrupper har olika hög sannolikhet att inträffa, samt att de har olika konsekvenser för företa- get, i form av kostnader och skadat varumärke. Meningen med fasen är att skapa medvetenheten om riskerna i företaget och hur de ska kunna elimineras med hjälp av GRC. I samförstånd med GRC applikationen utarbetas de kontroller som kommer att laddas upp i applikationen.

ABB använder sig av en standard-riskmatris som från början kommer från SAP. Denna har blivit uppdaterad via huvudkontoret i Schweiz för att anpassas till klimatet och riskerna som finns inom koncernen. Eftersom olika regler och kulturer finns inom de olika länderna, så utvecklas ofta den redan uppdaterade riskmatrisen för att passa landet i frågan.

ABB Ltd är av den meningen att standardmatrisen från ABB inte innehåller tillräckligt många ris- ker, så har de då valt att utveckla matrisen något och införa fler risker och framför allt kolla på segregeringen av uppgifter (Access Control) vilket är den huvudsakliga interna kontrollen som GRC används för inom ABB Ltd.

Fas 6: När riskerna har blivit undersökta och fastställda är nästa steg att lägga in dessa i systemet,

så i detta steg implementeras mitigation of controls, vilket är de interna kontrollerna som ska hålla koll på att transaktionerna sköts korrekt och att det inte finns några uppenbara fel och brister. Detta är en av de svåraste faserna i implementeringsarbetet, då det är oerhört omfattande kon- troller som ska laddas upp i applikationen och detta arbete är något som tar väldigt lång tid och kräver kunskap i företagets risker och kontroller. Som GRC-applikationen ser ut i dagsläget, är detta den en av två delar som fortfarande sköts manuellt av de som jobbar med interna kontrol- ler. Kontrollerna förs manuellt in i applikationen, för att minska risken att onödiga kontroller går in i systemet. Detta kräver en stor kunskap om såväl företagets risker som tidigare kontroller. Detta har varit den stora bristen i implementeringsarbetet i Finland till exempel, då ansvarig för interna kontroller är ny på jobbet och har inte den insyn som de andra intern kontrollansvariga i regionen.

Fas 7: I fas sju utarbetats berhörighetskonceptet och i denna fas kollar man på det viktigaste som

finns i SAP GRC Access Control. Själva behörigheterna och rollerna som hela system från grun- den bygger på. Behörigheten handlar om vilka transaktioner en anställd har behörighet att utföra ifrån sin roll. Rollen kan förklaras som den position på företaget den anställde har, till exempel är controller en roll. Behörigheten för controller X, kan då vara vad han eller hon har rätt att utföra från ett finansiellt perspektiv. En controller ska till exempel inte ha möjlighet att ta betalt från kunder eller kunna utföra kreditfakturor.

Detta är också en av de lite mer komplicerade faserna. Detta arbete måste ske manuellt och kan ske från två förhållningssätt. Det kan antingen vara role-based vilket innebär att behörighetskon- ceptet utgår från rollen. Till exempel behöver en controller kunna göra viss transaktioner och be- höver vissa behörigheter. Detta ger ett mer konsekvent system där det är lättare att tilldela nya roller till personer som byter jobb eller kommer in nya i företaget. Det är lättare att hålla koll på roller och behörigheter.

Den andra inriktningen som kan användas för behörighetskoncepten är user-based, till skillnad från role-based utgår detta ifrån individen som sitter på en viss position. När behörighetskonceptet be- stämts så kollar man på till exempel Herr X. Herr X har tjänsten som controller, men hjälper även till med lite andra saker, därför behöver han ha dessa behörigheter och rätt till att göra dessa transaktioner. När Herr X byter jobb eller position och Fru Y istället tar över hans tidigare posi- tion ska arbete göras om och man utgår från vilka behörigheter hon behöver som person, och dessa kan vara helt annorlunda gentemot vad Herr X hade.

Det senare sättet att förhålla sig till behörighetskonceptet hittas endast i Sverige, och kan knytas samman med den svenska arbetsmarknadskulturen. I resten av regionen så använder de nationella kontoren sig av role-based förhållningssätt och det är det författarna utav uppsatsen kommer att fokusera på.

Nytt för den nya versionen jämfört med den äldre är simuleringsmöjligheterna. När behörighets- koncepten tidigare var bestämda behövde de ansvariga kontrollera varje roll manuellt. Detta för att de inte skulle vara i konflikt med andra roller, eller att transaktionerna som var kopplade till en roll inte var i konflikt med varandra. Detta arbete var väldigt omfattande tidigare då varje roll har ett x antal transaktioner som han/hon kan utföra att kontroller alla roller och transaktioner blir då oerhört kostsamt i tid. I v.10 kan de ansvariga nu istället ladda upp de olika behörighetskon- cepten och testa dessa emot varandra utan att föra i dem i systemet. Detta går betydligt snabbare än i den tidigare versionen och enligt GRC-ansvarig i Storbritannien är en av de största vinsterna

med att implementera den nya versionen istället för en uppdatering av den gamla. Själva arbetet med behörighetskonceptet sker utav GRC-ansvarig i respektive land.

Fas 8: Detta är implementeringsarbetets sista fas innan systemet ska go live och börjar brukas.

Denna fas kallas för previsoning fasen. Previsoning är när man delar ut behörigheten till personer och efterföljer naturligt fasen där behörigheterna bestäms. I denna fas implementeras de testade be- hörigheterna och laddas upp i systemet för att kunna verkställas.

Det är i denna fas applikationer gör själ för sitt namn Access Control. Det är här dörrar öppnas och dörrar stängs till förmån för att minimera riskerna för stöld, bedrägeri och finansiella misstag ge- nom att införa kontrollen av segregering av uppgifter. Huvudsakligen är dock GRC ett verktyg som ska fungera internt, eftersom det som sker under det löpande arbetet samt av intern personal och ledning. Samtidigt som den huvudsakliga anledningen till varför ABB ens avvänder det är ex- terna skäl, då man på grund av sin marknadsnotering i USA är skyldiga att efterleva SOX.

Fas 9: Detta är den sista och go live fasen, när hela projektet sjösätts och denna ser lite olika ut

inom regionen beroende på vilken erfarenhet man har av GRC på nationell nivå. De Skandina- viska länderna som tidigare inte har jobbat med GRC kommer en stor del av den femte fasen be- stå utav utbildning av personal inom den nya systemmiljön som är skapad. Medan i Storbritanni- en som har tidigare erfarenhet kommer inte utbildning ta lika mycket utrymme utan det handlar snare om att förmedla de nya förändringar som har kommit i v.10.

Det skiljer sig dessutom förhållandevis mycket i design och layout av den nya versionen och det kommer krävas ett tag även för de lite mer erfarna att anpassa sig till den nya versionen. När ut- bildning och inlärningsfasen är över kommer GRC applikation kopplas samman till det ERP- system som ABB bygger på. I ABB Ltd:s fall deras ECC6 plattform och de ansvariga kommer då börja testa kontrollerna i applikationen mot det som är rapporterat i ERP-systemet.

Här börjar även utvecklingen av workflows. Vilket är en av de fundamentala byggstenarna för att nytta GRC snabbt och effektivt. Ett workflow är en förutbestämd handling som en person med behörighet för detta kan utföra, ett workflow fungerar på det sätt att det sätter igång en kedjeeffekt. Ett workflow kan vara helt administrativt, helt finansiellt, eller en hybrid där emellan. Ett bra ex- empel att beskriva vad ett workflow kan användas till för att skapa kedjeeffekter är sjukanmälan av en anställd. Denne person ringer till sin chef för att anmäla sig sjuk och kommer inte kunna ta sig till jobbet. Dennes chef lägger då in ett workflow på en sjukanmälan på denna person. Workflows startar då en kedjeeffekt av allt som berörs av att denne person är sjuk. Finns det någon arbets- syssla som måste skötas trots sjukdom? Då skickas det ut förfrågan till någon annan som har en

liknande tjänst om att detta behöver göras, personer som berörs av den sjuka personens arbete blir varnade via systemet att denne person är borta för dagen och så vidare.

Go live: När alla dessa faser hade blivit genomförda var det då dags för ABB att go live och börja

köra systemet i verkligheten mot de transaktioner, roller, kontroller och konflikter som finns i den vardagliga affärsverksamheten. Arbetet med GRC sker löpande och kan delas upp i två mo- ment: godkännande och kontroll.

Den godkännande delen är delen gällande segregeringen av uppgifter, här sker det manuellt huruvi- da en person ska ha rätt till en roll eller en transaktion. Denna godkännande del sköts bara av en person och det är GRC ansvarige i England. Den godkännande delen sköts via modullen Acecess Control och är den mest grundläggande funktionen.

Kontrollerande delen består av interna kontroller och simulation. Samtidigt som det är här själva fö- rarbetet till hur vidare GRC-ansvarige ska godkänna en roll, person eller en transaktion. Kon- trolldelen är den grundläggande delen i risk management-modulen och från den hämtas utdrag som skickas en gång i kvartalet till Local Business Unit (LBU) controller som är ansvarig för att sig- nera att kontrollerna som finns styr upp företagets konflikter.