8. semester Økonomistyring og informatik Gruppe 3 …vbn.aau.dk/files/17590341/Grp_3._8._semesterprojeket_cand.merc.__k... · 20 5.3 Inmon vs. Kimball ... Kilde: Egen tilvirkning

8. semester Økonomistyring og informatik Gruppe 3

Side 1 af 90

Titelblad

Titel: Datafangst: Opbygning og design af registreringsopgaven dedikeret ledelses-

og beslutningsinformation samt udvikling af ledelsesinformationssystem. 5 Temaramme modul 1: Datafangst: Opbygning og design af registreringsopgaven dedikeret ledelses-

og beslutningsinformation. Temaramme modul 2: Multidimensionel afrapportering. 10 Opgave: 2. semesteropgave - cand.merc. Økonomistyring og Informatik Afleveringsdato: 28. maj 2009, Aalborg Universitet Normalsider: 60 15 Udarbejdet af: Gruppe 3 Vejledere: Henrik Find Fladkjær og Lars Ole Wiese 20

Kenneth Lefevre Nielsen ________________________________________________________________

Rasmus Jessen ________________________________________________________________

Henrik Hjort Nielsen ________________________________________________________________ 25

Jesper Schou Madsen ________________________________________________________________


Side 2 af 90

Indholdsfortegnelse:

1. Metode..................................................................................................................................................................4 1.1 Paradigmeopfattelse................................................................................................................................ 5

1.1.1 Virkelighedsopfattelse ...................................................................................................................... 6

1.1.2 Videnskabsopfattelse........................................................................................................................ 8 5

2. Indledning modul 1 ............................................................................................................................................... 10 3. Arbejdsparadigme modul 1 ................................................................................................................................... 11 4. Balanced scorecard ............................................................................................................................................... 13

4.1 Beskriv strategien .................................................................................................................................. 13

4.2 Balanced scorecard-konceptet .............................................................................................................. 14 10

4.3 Årsagsvirkningssammenhæng ............................................................................................................... 18

4.4 Den strategifokuserede organisation .................................................................................................... 20

4.5 Kritik og forudsætninger ved anvendelse af balanced scorecard.......................................................... 21

5. Data warehouse .................................................................................................................................................... 23 5.1 Data mart ............................................................................................................................................... 25 15

5.1.1 Dimensional modellering ................................................................................................................ 25

5.1.2 Metadata......................................................................................................................................... 28

5.2 ETL-processen ........................................................................................................................................ 29

5.2.1 Transformationsprocessen ............................................................................................................. 31

5.3 Inmon vs. Kimball................................................................................................................................... 32 20

5.3.1 Corporate Information Factory....................................................................................................... 33

5.3.2 Bus-arkitektur ................................................................................................................................. 34

6. Data warehouse og balanced scorecard ................................................................................................................ 36 6.1 Valgt tilgang til opbygning af data warehouse ...................................................................................... 37

7. Case....................................................................................................................................................................... 38 25 8. Opbygning af data warehouse............................................................................................................................... 42

8.1 Ledelsesinformation og afdelingsinformation....................................................................................... 42

8.2 Det opbyggede data warehouse............................................................................................................ 43

9. ETL-proces ............................................................................................................................................................. 46 10. Afrunding modul 1 .............................................................................................................................................. 48 30 11. Indledning modul 2 ............................................................................................................................................. 49 12. Arbejdsparadigme modul 2 ................................................................................................................................. 50


Side 3 af 90

13. Balanceret vækst................................................................................................................................................. 52 14. Balanceret vækst og BSC ..................................................................................................................................... 55 15. On-Line Analytical Processing.............................................................................................................................. 57

15.1 Krav til OLAP-applikationer.................................................................................................................. 57

15.2 MOLAP-kuber....................................................................................................................................... 59 5

15.3 Kubeopbygning og hierarkier............................................................................................................... 61

15.3.1 Hierarkityper ................................................................................................................................. 64

15.4 Opbygning af dimensioner i kuberne .................................................................................................. 69

15.5 PALO..................................................................................................................................................... 70

16. Fra teoretisk problem til praktisk problem i PALO............................................................................................... 71 10 16.1 Afrapportering i PALO.......................................................................................................................... 76

17. Afrunding modul 2 .............................................................................................................................................. 80 18. Litteratur ............................................................................................................................................................. 81 19. Bilag .................................................................................................................................................................... 84 15


Side 4 af 90

1. Metode

Afsnittet har til formål at skabe en forståelse af, hvordan hele projektprocessen er blevet tilrettelagt. Det vil

herunder fremstå, hvad metode er, og hvordan metode er brugt i indeværende projekt. Metode er i denne

forbindelse det middel, der bruges til erkendelse og videreformidling af denne erkendelse. Hvordan erken-

delse opnås, vil blive beskrevet i arbejdsparadigmerne, mens de grundlæggende antagelser om virkelighe-5

den og verden, der ligger til grund for projektet, vil blive beskrevet i det følgende. Der vil dog først blive re-

flekteret over selve projektets generelle opbygning igennem de to moduler. Dette gøres med udgangspunkt

i følgende figur:

Figur 1: Projektets fokusområder

10

Kilde: Egen tilvirkning med inspiration fra Kimball(1998)

Heraf kan det ses, at 1. modul hovedsageligt vil fokusere på udtrækning af data fra operationelle systemer,

lagring af disse data samt klargørelse og load af dataene til de respektive data marter i virksomheden. Efter-15

følgende vil 1. modul således danne udgangspunkt for 2. modul, hvor fokusområderne i høj grad bliver op-

sætningen af selve præsentationsserveren eller data warehouset for derefter at bearbejde data med OLAP-

kuber. På denne måde vil læringsprocessen blive en kontinuerlig proces henover modulerne, hvilket dog i

nogen grad kræver, at de to modulemner er sammenhængende. Det vil sige, at 1. modulemne derfor er be-

stemmende for omfanget af 2. modulemne. Denne fremlægning af modulerne hænger endvidere sammen 20

med undervisningen, da der sideløbende med 1. modul blev undervist i generel teori om data warehouse,

og der sideløbende med 2. modul blev undervist i multidimensionel analyse.

Source Systems Data Stagging Area Presentation Servers End Users

Operationelt

system -

ERP-system

Udtrækning

Lagring af

data

Klargørelse af

data til data

marts

Uploadning

Data Marts:

Dimensional, Subjektorienteret

Query-

baserede

feeds

Forskellige

slutbrugere

1. modul

2. modul


Side 5 af 90

Da der er tale om et sammenhængende projekt bestående af de 2 moduler bliver metodeafsnittet således

et overordnet afsnit til begge moduler. I det følgende vil paradigmeopfattelsen, herunder virkelighedsop-

fattelsen, og andre paradigmedannende elementer blive forklaret.

1.1 Paradigmeopfattelse

Törnebohms evolutionære paradigmeopfattelse benyttes i projektet, men der tages udgangspunkt i Kuhns 5

revolutionære paradigmeopfattelse for at forstå baggrunden for Törnebohms paradigmeopfattelse. Samti-

dig opnås der en refleksion over de to paradigmeopfattelser, og det vil være muligt at begrunde valget af

Törnebohms paradigmeopfattelse ud fra Törnebohms kritik af Kuhns paradigmeopfattelse.

Kuhn så det videnskabelige arbejde, som arbejde indenfor et givet paradigme, hvor der søges at påvise, at

anomalier, indenfor paradigmet, i bund og grund er forenelige med paradigmet. På denne måde bliver vi-10

denskab en disciplin i at påvise, at anomalier er forventelige størrelser i de paradigmer, de vedrører. I de

tilfælde, hvor dette ikke lader sig gøre, og anomalierne ikke kan forklares mere indenfor det gældende pa-

radigme, må dette afløses af et nyt paradigme. Dette er Kuhns videnskabelige revolution.1 Den revolutio-

nære opfattelse af paradigmet giver dog anledning til problemer, og specielt forskellen mellem naturviden-

skabernes og samfundsvidenskabernes paradigmer giver anledning til en anden paradigmeopfattelse. Tör-15

nebohm forklarer således, at forskere med stor prestige på grund af deres tidligere arbejde bliver ophævet

til autoriteter indenfor deres respektive felter, og god forskning bliver således bedømt i forhold til disse au-

toriteter, hvilket betyder, at god forskning er at efterligne autoriteterne indenfor et paradigme.2 Dette er

selvsagt uheldigt, da resultatet bliver et statisk paradigme uden nytænkning og udvikling. Inden for sam-

fundsvidenskaberne behøves der ikke nødvendigvis være noget i vejen for, at et nyt paradigme kan eksiste-20

re ved siden af et ældre paradigme. Törnebohm argumenterer således for, at et paradigmes bestanddele

ændres løbende i takt med udviklingen.3 Det er med denne baggrund, at Törnebohms paradigmeopfattelse

benyttes. Törnebohm definerer et paradigme på følgende måde:

”Ett paradigm är ett överordnet styr- och kontrollorgan inom ett under-

sökande system. Det består av dessa delar: en vetenskapsuppfattniung, 25 ett vetenskapsideal, en världsbild, en etik och en estetik.”

4

1 Pahuus i Christensen(red.)(2004) s. 17 2 Törnebohm(1974) s. 3 3 Törnebohm(1974) s. 10 4 Törnebohm(1974) s. 2


Side 6 af 90

I projektet benyttes der en modificeret udgave af Törnebohms paradigmeopfattelse. Det vil sige, Arbnor og

Bjerke(1997) omskriver ”Världsbild” til ”Conception of reality” eller ”virkelighedsopfattelse” på dansk. Pa-

radigmet kommer derfor til at bestå af følgende elementer i nævnte rækkefølge:5

• Virkelighedsopfattelse

• Videnskabsopfattelse 5

• Videnskabsidealer

• Etiske og æstetiske aspekter.

Hertil inddrages semantik og logik ligeledes som paradigmedannende elementer, og til forklaring af virke-

lighedsopfattelsen, som ligger til grund for projektet, tages der udgangspunkt i Nørreklits opfattelse af vir-

keligheden. Videnskabsidealer samt etiske og æstetiske aspekter inddrages dog ikke i den efterfølgende 10

behandling, da disse begreber ikke vil blive benyttet i projektet.

1.1.1 Virkelighedsopfattelse

Nørreklits virkelighedsopfattelse er en firedimensional opfattelse af virkeligheden. Disse fire dimensioner

består af fakticitet, mulighed,6 værdier og kommunikation. Alle fire er forbundet med følgende citat, som

kan danne udgangspunkt for en virkelighedsdefinition: 7 15

”Virkeligheden knytter sig til muligheden for at udføre bevidste virkende

handlinger”

Den første dimension, fakticitet, knytter sig til vores erfaringsgrundlag, hvorved det gøres muligt at skelne

mellem virkelighed og fiktion. Fakticitet er således en betingelse for virkelighed. Den næste dimension er

mulighed. Mulighed er en betingelse for livet, idet Nørreklit(2004) argumenterer for, at en aktør uden mu-20

lighed er død. Virkeligheden eksisterer endvidere kun, hvis der er en kombination af fakta og mulighed. Ek-

sempelvis kan der ligge en bog på et bord, som aktøren kan læse i eller undlade at læse i. Mulighederne

skabes altså gennem refleksion, som i høj grad sker gennem vores erfaringer.8 Mulighed er senere omskre-

vet til logik af Nørreklit et al.(2006), hvorved muligheder opstår som følge af erfaringsgrundlaget. Det vil si-

ge, at der skal oprettes et teoretisk grundlag om de benyttede teorier for, at der senere kan foretages en 25

analyse af en given problemstilling indenfor teorierne. For at det er muligt for aktøren at vælge mellem for-

5 Arbnor & Bjerke(1997) s. 13 6 I stedet for mulighed er begrebet logik senere inddraget, hvor mulighederne opstår gennem logiske refleksioner over

fakta. Logik og mulighed er derfor i vid udstrækning det samme i litteraturen. Se Nørreklit, Nørreklit & Israelsen(2006) 7 Nørreklit i Christensen(2004) s. 32 8 Nørreklit, Nørreklit & Israelsen(2006) s. 46


Side 7 af 90

skellige alternativer, som opstår på grund af mulighedsdimensionen, er det nødvendigt at inddrage den

tredje dimension; begrebet værdi.9 Værdibegrebet spiller en væsentlig rolle i forbindelse med virkelighe-

den, da det uden værdibegrebet vil være umuligt for aktøren at prioritere alternativer, og der vil ikke kunne

foretages et valg. Aktøren vil således være i stand til at prioritere, hvilken bog, vedkommende helst vil læse

i det tilfælde, at der ligger flere bøger på bordet. Værdi bliver derfor det:10 5

”… der knytter mig til verden for sin egen skyld, fordi det gør verden dejlig,

elskelig og spændende at være i.”

Den sidste dimension er kommunikation. Uden kommunikation vil virkeligheden mangle det intersubjektive

og sociale aspekt. Kommunikationen mellem aktørerne har derfor til mål at formidle de tre foregående di-

mensioner, og værdidimensionen vil udelukkende blive synlig gennem kommunikationen.11 Kommunikati-10

onsdimensionen bliver således en forklaring af handlinger foretaget på baggrund af de tre andre dimensio-

ner.

Vores grundlæggende antagelse om virkeligheden bliver derfor en firedimensional virkelighed, som kun ek-

sisterer som helhed, idet hver enkelt dimension i sig selv ikke kan forklare virkeligheden. Muligheder giver

eksempelvis ingen mening uden fakticiteten, og som beskrevet vil det ikke være muligt at vælge mellem al-15

ternative muligheder uden værdier.

Til disse fire dimensioner inddrages som skrevet semantik og logik. Semantik vedrører ords betydning. Det

er således nødvendigt at inddrage definitioner af begreber og lignende for at undgå misforståelser. Dahllöf

definerer semantikken således:12

”Semantiken kan […] definieras som det vetenskapliga studiet av 20 betydelse”

Denne definition stiller imidlertid spørgsmålet om, hvad ”betydelse” er. I indeværende projekt vil seman-

tikken benyttes som ords sproglige indhold. Betydning, som sprogligt indhold,13 skal forstås som definitio-

nen af forskellige begreber.14 Eksempelvis definitionen af ordet rente som værende prisen på kapital. I pro-

jektet vil det derfor være nødvendigt at definere, hvad eksempelvis et data warehouse og et data mart er, 25

samt hvordan begrebet balanced scorecard forstås – altså hvilken betydning balanced scorecard tillægges i 9 Nørreklit, Nørreklit & Israelsen(2006) s. 47 10 Nørreklit i Christensen(2004) s. 41 11 Nørreklit i Christensen(2004) s. 36-45 12 Dahllöf(1999) s. 10 13 Herudover kan betydning også forstås som en virkning og som grundlag for viden, men i indestående vil

semantikken kun hidrøre definitionsspørgsmålet. Dahllöf(1999) s. 19-20 14 Dahllöf(1999) s. 19


Side 8 af 90

projektet. Dette vil være nødvendigt, da opfattelsen af begrebers betydning nødvendigvis ikke er ens. Se-

mantikken kommer derfor til udtryk gennem kommunikationsdimensionen. Semantik har også stor indfly-

delse på logikken, som beskrives efterfølgende. Logik vil i projektet blive benyttet som metodisk procedure

til at drage konklusioner. Denne proces kan opstilles således:15

Præmis + præmis = Konklusion 5

Konklusionen følger præmisserne, hvilket vil sige, at hvis præmisserne accepteres, må konklusionen også

accepteres. Logikken stiller således ikke spørgsmål ved konklusionens indhold, men benyttes til at drage lo-

giske konklusioner på baggrund af præmisserne. Logikkens opgave er således at undersøge, om konklusio-

nen, som drages på baggrund af præmisserne, også fremkommer som følge af præmisserne.16 Det, at logik

benyttes som metodisk procedure i projektet, betyder, at der må oprettes nogle begrebsmæssige afsnit for 10

at sikre semantikken i projektet. Dette skyldes, at de opstillede præmisser ikke må kunne fejlfortolkes,

hvorved konklusionen også vil kunne fejlfortolkes. I denne forbindelse vil logikken blive benyttet på fakta og

mulighedsdimensionen. Et eksempel på logikken kunne være følgende:

Aktøren har læst alle bøger af Vagn Madsen + Der ligger en bog af Vagn Madsen på bordet 15 = Aktøren har læst bogen på bordet

Det følger som en logisk deduktion af præmisserne, at aktøren har læst bogen på bordet, hvorfor konklusi-

onen er korrekt. Det ses heraf, at der ikke stilles spørgsmålstegn ved præmisserne, men blot den efterføl-

gende konklusion. Måden semantikken skal benyttes i projektet er ved at redegøre for betydningen af ab-

strakte begreber i præmisserne. Dette kunne i ovenstående være ordet ”læst”, hvor det vil være nødven-20

digt at afdække, om det menes, at alle sider i bøgerne er læst, eller om der blot er tale om, at aktøren har

læst i alle bøgerne, og altså ikke alle siderne.

1.1.2 Videnskabsopfattelse

Gennem vores uddannelse er gruppen blevet bekendt med en række teoretiske modeller indenfor er-

hvervsøkonomi. Disse er blevet forelagt i studieretningens undervisningsforløb, og denne viden danner ud-25

gangspunkt for gruppens videnskabsopfattelse. Den lagrede viden påvirker således gruppens opfattelser af

de genstandsfelter, som der undersøges.17 Videnskab kan derfor ses som en subjektiv størrelse, der vil være

afhængig af den læring, der tidligere er blevet opnået gennem uddannelsen. Projektet vil således være

præget af det materiale der undervises i på semestret, tidligere semestres undervisning og tidligere modu-

15 Hartnack(1996) s. 8 16 Hartnack(1996) s. 8-9 17 Arbnor & Bjerke(1997) s. 15


Side 9 af 90

lers erkendelser. Den informationsteknologiske del af undervisningen lægger op til en systemisk objektiv

tilgængelig videnskab, mens økonomistyringsdelen i højere grad lægger op til en subjektiv aktørafhængig

videnskab. Dette paradoks løses ved, at informationsteknologien benyttes på økonomistyringen, hvorfor

videnskab, som afhængig af en eller flere aktører, må indarbejdes.

5


Side 10 af 90

2. Indledning modul 1

Ledelsens behov for beslutningsrelevant information er i dag større end nogensinde. Derfor er det nødven-

digt for beslutningstagerne at have så godt et grundlag som muligt at træffe deres beslutninger ud fra. Det-

te kan opnås ved, at de opdaterede data fra virksomheden samles i et data warehouse, hvorfra der efter-

følgende kan udarbejdes de af ledelsen efterspurgte rapporter. I udarbejdelsen af beslutningsrelevante 5

rapporter, udgør data warehouset en væsentlig rolle.

Nedenstående citat bekræfter ovenstående:18

”Knowledge Management er kommet højt på dagsordenen i danske virk-somheder. Men, hvis viden skal anvendes kreativt, forudsætter det, at man har kendskab og overblik over den viden, der allerede eksisterer i 10 virksomheden. Det kan den rigtige data warehouse-løsning sikre. Dermed kan man hurtigt opdage tendenser og levere analyser og nøgletal på nye områder.”

Dette modul tager sit udgangspunkt i balanced scorecard og opbygningen af et dertilhørende data ware-

house. Dette sker især med henblik på at transformere data fra de enkelte operationelle systemer, så de 15

kan samles i et data warehouse. Herefter lægges vægt på ETL-processen, og hvordan data samles i et data

warehouse samt udformningen af dette.

18 Hansen & Andersen(2000)


Side 11 af 90

3. Arbejdsparadigme modul 1

Til at operationalisere de overordnede tanker omkring de to moduler benyttes et arbejdsparadigme. For-

målet med arbejdsparadigmet er at vise, hvordan opbygningen af modulerne bliver, og derved hvilke afsnit,

der inddrages, samt hvilke teorier der benyttes i de respektive afsnit. Dette gøres for at skabe et overblik

over projektet både for gruppen og for læserne. Af arbejdsparadigmet vil det således fremgå, hvilke tilvalg 5

og fravalg der er foretaget i modulet.

Da projektet starter med modul 1, tager arbejdsparadigmet ligeledes udgangspunkt i emnet for modul 1.

emnet for modul 1 lyder således:

”Hvordan kan der udvikles et Balanced Scorecard ved brug af Data Warehousing?” 10

Heraf følger det, at der skal opbygges et teoretisk erfaringsgrundlag om balanced scorecard og data ware-

housing. Denne viden skal danne grundlag for en senere analyse af, hvordan balanced scorecard kan inte-

greres i et data warehouse. Modul 1 tager derfor udgangspunkt i underspørgsmålene; ”Hvad er balanced

scorecard?” og ”Hvad er data warehouse?”. Til at forklare balanced scorecard vil der blive inddraget littera-

tur af Per Nikolaj Bukh, Robert S. Kaplan og Anthony Atkinson samt andre forfattere indenfor fagområdet. 15

Til beskrivelse af data warehouse vil der hovedsageligt blive inddraget litteratur fra William H. Inmon og

Ralph Kimball, da disse repræsenterer hver sin tilgang til data warehousing.

Projektdesign til modul 1 kan på denne baggrund opstilles således:

20

25


Side 12 af 90

Figur 2: Projektdesign for modul 1

Kilde: Egen tilvirkning

Efter underspørgsmålene er besvaret vil der følge en sammenkædning af de to teoretiske afsnit, hvor et

valg af data warehouse tilgang til opbyggelse af et BSC-koncept vil følge. Herefter opbygges der én case in-5

deholdende relevante KPI’er(Key Performance Indicators) i forhold til BSC-konceptet. Casen bliver ud-

gangspunktet for analysen, da denne danner grundlag for, hvorledes forskellige designvalg indenfor dimen-

sional modellering vil have indflydelse på det endelige design af data warehouset. Heraf følger det, at der

udvikles data marter efter balanced scorecard til data warehouset i dette afsnit. Dette betyder ligeledes, at

der skal udvikles metadata til designet i dette afsnit. Selve designet vil blive udviklet i Power Architect, 10

hvorefter det vil blive overført til Oracles database. Efter et design er valgt og udviklet, vil det være muligt

at påbegynde ETL-processen. Denne proces vil blive foretaget i Pentaho Data Integration(PDI), hvor det er

muligt at inddrage flere forskellige datakilder, og strømline dem efter metadataene fra det foregående af-

snit. Herefter bliver de transformerede data loadet ind i de dertil designede tabeller i Oracles database. Af-

slutningsvis vil der blive afrundet på modulet. Der bliver således afgrænset fra at rapportere på data ware-15

houset, men der vil dog i designet af data warehouset blive analyseret på, hvilke fordele og ulemper for-

skellige designvalg vil have.

Her benyttes Power Architect til designet

Til ETL-processen benyttes PDI

Balanced Scorecard

Opbygning af Data Warehouse ef-ter Balanced Scorecard

Arbejdsparadigme

ETL-Processen gennem Pentaho Data Integration

Data Warehouse

Case KPI’er og datakilder

BSC og Data Warehouse

Afrunding


Side 13 af 90

4. Balanced scorecard

I dette afsnit vil konceptet om balanced scorecard(BSC) blive belyst og konceptbeskrivelsen vil i den videre

fremstilling i modulet have fokus på, hvorledes data til de konkrete nøgletal i konceptet kan fremskaffes og

analyseres. Bukh et al.(2004) argumenterer således for at Kaplan, en af forfatterne bag konceptet, arbejder

med tre områder indenfor balanced scorecard nemlig; beskriv strategien, mål strategien og led strategien. 5

Modul 1 vil således særligt berøre det andet punkt, nemlig at måle strategien. Men før dette kan lade sig

gøre, skal konceptet belyses. Der tages udgangspunkt i flere forskellige forfattere til at belyse teorien om

BSC. Afsnittet afsluttes med en kritisk stillingtagen til konceptet.

4.1 Beskriv strategien

Før der kan udarbejdes et scorecard, skal virksomheden beskrive den vision og strategi, der skal sikre virk-10

somhedens overlevelse på lang sigt. En klar vision og strategi kan endvidere medvirke til at hele virksomhe-

den arbejder efter samme idéer og værdier, og at medarbejdernes handlinger tager udgangspunkt i samme

idé.

Da en strategi typisk har en anvendelig levetid på tre-fire år,19 skal der med jævne mellemrum enten ænd-

res i en strategi eller udformes en helt ny strategi. Når en ny strategi skal udformes, kræver det en intern 15

vurdering af virksomhedens fundamentale forretningsværdier, og af hvor konkurrencedygtig virksomheden

er. Ud fra et overordnet spørgsmål om hvilket forretningsområde virksomheden befinder sig i, og hvorfor

virksomheden fokuserer på lige præcis det udvalgte område, skal den øverste ledelse udarbejde virksom-

hedens vision, strategi samt dens grundlæggende værdier.

Når dette er gennemført, handler det om at finde ud af hvilke nøgleområder, der er på de forretningsom-20

råder, virksomheden befinder sig på. Denne strategiske analyse kan eventuelt foregå efter Michael Porters

tankegang med en vurdering af konkurrencevilkårene på et givent marked og derefter en vurdering af virk-

somhedens værdikæde. Dermed får virksomheden en oversigt over dens interne styrker og svagheder,

samt muligheder og trusler i forhold til markedet og markedsforholdene. Ud fra denne oversigt kan virk-

somheden så udarbejde selve strategiformuleringen, hvor det fremgår hvad de vil opnå og hvordan virk-25

somheden vil bære sig ad med at opnå den valgte strategi.

Kernen i enhver forretningsstrategi er at kende sin værdi for kunden, og virksomhederne kan ifølge

Kaplan(2000) typisk vælge mellem tre forskellige kundestrategier i form af operational excellence, customer

intimacy og product leadership, der på hver sin måde giver værdi for kunden. Operational excellence-

19 Kaplan & Norton(2008) s. 64


Side 14 af 90

strategien handler om at tilbyde konkurrencedygtige priser og hurtig levering. Customer intimacy skaber

værdi ved at have en tæt kontakt til kunden og fremragende service, mens product leadership fokuserer på

at have en førende produktfunktionalitet.20

4.2 Balanced scorecard-konceptet

I det følgende afsnit vil gruppens semantiske opfattelse af BSC-konceptet blive beskrevet. Konceptet er før-5

ste gang nævnt i artiklen ”The Balanced Scorecard – Measures that drive performance” af Kaplan og Norton

i 1992. Konceptet har efterfølgende udviklet sig til at være et værktøj til strategisk implementering, da stra-

tegien operationaliseres gennem nøgletallene, der måles på.21 Konceptet er således udviklet til at kommu-

nikere en flerstrenget målsætning, som en virksomhed ønsker at opnå. BSC omformer således virksomhe-

dens vision og strategi til konkrete målsætninger og målinger organiseret i fire perspektiver, værende det 10

finansielle, kunde-, interne og læringsperspektiv.22

Kaplan og Atkinsons definition af BSC lyder: 23

“A strategic management system that translate an organization’s strategy into clear objectives, measure, targets and initiatives organized by four perspectives” 15

Der arbejdes med fire perspektiver, som der oprettes målepunkter indenfor, således at der kan skabes en

årsagsvirkningssammenhæng mellem målepunkterne på tværs af de fire perspektiver.24 Ifølge Otley(1999)

har konceptet sin stærke berettigelse, da konceptet binder virksomhedens målingssystemer sammen med

virksomhedens strategi.25 Et af formålene med BSC er således, at virksomheden skal kunne identificere sine

kritiske succesfaktorer og ud fra disse udføre sin strategi. BSC understøtter derved at der skabes en sam-20

menhæng mellem de forskellige KPI’er i virksomheden og at der udvælges nøgletal, der kan medvirke til at

effektuere virksomhedens strategi. Der er dog ikke tale om, at virksomheden arbejder med balanced score-

card, før der er fremsat en årsagsvirkningssammenhæng imellem KPI’erne. En organisering af nøgletallene i

de fire perspektiver er således ikke nok.26

20 Kaplan & Norton(2000) s. 172 21 Bukh et al.(2004) s. 28 22 Kaplan & Atkinson(1998) s. 368 23 Kaplan & Atkinson(2004) s. 356 24 Kaplan & Atkinson(1998) s. 377 25 Otley(1999) s. 375 26 Kaplan & Atkinson(2004) s. 378


Side 15 af 90

Balanced scorecard består af en blanding af finansielle og ikke-finansielle nøgletal. Scorecardet balancerer

således traditionelle finansielle målepunkter for succes i en virksomhed såsom profit og afkastningsgrad

med ikke-finansielle målepunkter, som kan drive virksomhedens fremtidige finansielle performance.27 Ud-

over en balance mellem perspektiverne, skal der ligeledes være balance mellem de forskellige målsætnin-

ger under hvert perspektiv. 5

I nedenstående figur fremvises hvorledes perspektiverne påvirker hinanden:

Figur 3: Balanced Scorecard definerer strategiens årsagsvirkningssammenhæng

Kilde: Kaplan & Norton(2001) s. 91 10

I konceptet er visionen og strategien det overliggende niveau, mens målepunkter indenfor de fire perspek-

tiver skaber et årsags-virkningsforhold, og viser hvorvidt strategien bliver efterfulgt. Fælles for perspekti-

verne er, at der fremsættes målsætninger indenfor hvert perspektiv.

27 Kaplan & Atkinson(2004) s. 356


Side 16 af 90

I forhold til ovenstående figur optræder målsætninger, måltal, mål og initiativer under hvert af de fire per-

spektiver og de er i den amerikanske terminologi omtalt som henholdsvis objectives, measures, targets og

inititatives. Objectives er defineret som:28

”Concise statements in each of the four Balanced Scorecard perspectives that articulate what the organization hopes to accomplish.” 5

Og

“…Objectives are best stated as phrases expressing action…”

Gruppens semantiske opfattelse af objectives er målsætninger, der udtrykker handlinger. Det næste ameri-

kanske begreb er measures, der opfattes som både det, der skal måles, og nøgletallet der bliver målt på.

Target vil blive opfattet som det mål virksomheden sætter for nøgletallet. Initiatives vil blive forstået, som 10

de handlinger virksomheden vil iværksætte for at opnå målsætningen.

I kundeperspektivet kan målsætningen eksempelvis gå på kundefastholdelse, hvor der indenfor denne mål-

sætning sættes et måltal, der kunne være procentvis omsætningsvækst pr. eksisterende kunde.29 Dette

måltal skal dermed signalere, om virksomheden når sin målsætning om et givet kundefastholdelsesniveau. I

direkte forlængelse heraf, sættes der således et mål for måltallet, og der fremsættes initiativer, der kan på-15

virke målsætningen omkring kundefastholdelse.

Balanced scorecard udarbejdes således på strateginiveauet og implementeres i første omgang fra ledelsen

nedad i organisationen. Men efter strategien er defineret, skal årsags-virkningssammenhængene efterleve

strategiens intentioner nede fra og op.30 BSC anskues derved som et målingssystem af virksomhedens stra-

tegi, der er sigende for i hvilken grad strategi bliver efterlevet. Det er altså et system, der både er medvir-20

kende til at udføre strategien og ligeledes fungerer som et kontrolsystem for om strategien bliver efterle-

vet.31

Det finansielle perspektiv

Det finansielle perspektiv indeholder målinger af allerede udførte handlinger og består dermed af finansiel-

le målinger, der viser, om virksomhedens strategiske implementeringsforbedringer kan læses som forbed-25

ret resultat i regnskaberne. Dette måles blandet andet på baggrund af finansielle nøgletal, som for eksem-

28 Kaplan & Atkinson(2004) s. 356-357 29 Kaplan & Atkinson(1998) s. 552 30 Bukh et al.(2004) s. 26 31 Bukh et al.(2004) s. 24


Side 17 af 90

pel afkastningsgrad.32 Dette perspektiv indeholder dermed det overordnende perspektiv, hvorfra de øvrige

tre perspektivers indhold skal ses i forhold til. I denne sammenhæng kan figur 3 sætte de tre øvrige per-

spektiver i relation til det finansielle perspektivs pejlemærker.

Kundeperspektivet

Kundeperspektivet skal medvirke til at virksomheden i fremtiden kan forbedre de finansielle resultater.33 5

Det handler for lederne om at vælge og identificere de kunde- og markedssegmenter, som virksomheden

skal satse på i henhold til den overordnede strategi og vision. Måltallene kan blandt andet omhandle kun-

detilgang, kundetilfredshed, kunderentabilitet eller markedsandele. Et eksempel kunne være at kundetil-

gangen kan blive målt på antal nye kunder eller totalsalg til nye kunder i et valgt segment.34

Det interne perspektiv 10

I det interne perspektiv skal de vigtige processer identificeres af lederne i virksomheden.35 Det er de pro-

cesser der er afgørende for, om de allerede formulerede målsætninger for både kunde- og aktionærmål-

sætninger kan realiseres. Målsætningerne for det interne perspektiv udvikles herefter, da de udarbejdes

efter kundeperspektivet og det finansielle perspektiv, kan der fokuseres på de interne processer, der har en

indflydelse på de tidligere valgte målsætninger. 15

De interne processer består af innovationsprocessen, den operative proces og eftersalgsservice. De fleste

virksomheder fokuserer typisk på den operative proces, mens Kaplan & Norton(2004) mener, at der skal

ses på hele værdikæden i en virksomhed, der spænder fra innovationsprocessen til eftersalgsservicen. Ek-

sempler på måltal i innovationsprocessen kan være procentdel af omsætningen fra nye produkter eller den

tid, det tager at udvikle en ny generation af produkter. I den operative proces kan måltallene være produk-20

ters gennemløbstid eller produktionsomkostninger. Ved eftersalgsservice kan der blandt andet måles på

hvor stor en procentdel af kundehenvendelserne, der afhjælpes ved et servicebesøg.

Lærings- og vækstperspektivet

Lærings- og vækstperspektivet udvikler målsætninger, måltal, mål og initiativer der skal fremme læring og

vækst i organisationerne.36 De tre foregående perspektiver fokuserer på, hvilke områder en organisation 25

skal forbedre for at opnå resultater. Lærings- og vækstperspektivet måler den organisatoriske infrastruktur,

der muliggør en opnåelse af de tre andre perspektivers målsætninger. Det er også i dette perspektiv, at

32 Kaplan & Atkinson(1998) s. 368 33 Kaplan & Norton(2004) s. 41 34 Kaplan & Atkinson(1998), s. 552 35 Kaplan & Norton(2004) s. 111 36 Kaplan & Norton(2004) s. 147


Side 18 af 90

virksomhedens capabilities37 fremsættes som en strategisk faktor, hvor organisationen på baggrund af dens

capabilities kan opbygge sine strategiske konkurrenceparametre.

Kaplan & Norton mener, at det er vigtigt for virksomhederne at investere i den organisatoriske infrastruktur

såvel som i produktionsapparatet, forskning og udvikling, hvis der skal skabes økonomisk vækst på langt

sigt. De tre hovedkategorier i lærings- og vækstperspektivet er ”medarbejderkompetencer”, ”informations-5

systemernes formåen” samt ”motivation, empowerment og tilpasning”, og der kan derfor være målsætnin-

ger og måltal indenfor hver af disse tre hovedkategorier.

4.3 Årsagsvirkningssammenhæng

Et af de gennemgribende elementer i BSC er den årsagsvirkningssammenhæng, der fremsættes i konceptet.

Ideen er den, at virksomheden ud fra sin strategi fastlægger hvilke resultater virksomheden vil opnå i det 10

finansielle perspektiv.38 For offentlige virksomheder kan det dog være kundeperspektivet, der er det over-

ordnende styringsniveau. For belysning af private virksomheders scorecards kan det eksempelvis være at

skabe værdi for aktionærerne, der sættes som det overordnende mål, som virksomheden arbejder hen

imod. Det kunne eksempelvis være en målsætning om en afkastningsgrad(ROA) på 9 %.

Ideen er, at der sættes strategiske fokusområder for virksomheden. Disse fokusområder skal i kundeper-15

spektivet efterleves for at opnå resultaterne, der ønskes opnået i det finansielle perspektiv via fokusområ-

der i kundeperspektivet. Men disse resultater opstår ikke uden, at de interne processer i virksomheden er

tilrettelagt på bestemte måder, der igen er et resultat af de medarbejdermæssige forhold, der kan belyses i

læringsperspektivet. Denne proces skitseres i et strategikort.

Nedenstående figur 4 belyser årsagsvirkningsforholdene i det såkaldte strategikort: 20

37 Gruppens semantiske opfattelse af capabilities ses som et begreb der beskriver en persons, eller organisations kom-petencer og evner. 38 Bukh et al.(2004) s. 30


Side 19 af 90

Figur 4: Årsagsvirkningsforhold i strategy map

Kilde: Egen tilvirkning efter inspiration af Kaplan & Atkinson(2004) s. 375

Strategikortet er en visualisering af de årsagsvirkningsforholdene, der fremsættes under de fire perspekti-

ver i balanced scorecard.39 Hvis hypotesen bag denne årsagsvirkningsrelation er falsk vil virksomheden ikke 5

kunne opnå forbedringer af eksempelvis aktiernes værdi, hvis dette er set som det overliggende styrings-

punkt.40

Ifølge Bukh et al.(2004) vil de fleste virksomheder ønske at øge deres overskud. Dette må være generel be-

tragtning, men hvorledes opnås dette resultat? Teorien er den, at et øget overskud kan skabes ved, at virk-

somheden har profitable kunder, og disse profitable kunder opnås gennem en øget kundeloyalitet, der igen 10

kunne være et resultat af, at virksomheden har rettidige leverancer. De rettidige leverancer er således le-

dende indikatorer for kundeloyalitet, hvor forbedrede leverancer igen kunne være et resultat af forbedrede

procesoptimeringer i det interne perspektiv, fremkommet via forbedrede medarbejderkompetencer.

Bukh et al.(2004) fremsætter, at den årsags-virkningsrelation, der er beskrevet, ikke er en deterministisk

relation. Ved en deterministisk relation er der tale om en positivistisk tilgang, hvor ”A fører til B” og andre 15

faktorer er anset at have en neutral påvirkningskraft på resultaterne. Bukh et al.(2004) argumenterer for, at

der med konceptet er tale om strategiske hypoteser, hvor der, hvis de viser sig ikke at holde, vil være behov

39 Kaplan & Atkinson(2004) s. 388-389 40 Bukh et al.(2004) s. 31


Side 20 af 90

for at identificere nye kausale sammenhænge og reformulere virksomhedens strategi. Den semantiske kau-

salitetsrelation hos Kaplan og Norton skal således ikke læses som en positivistisk relation. Kaplan og Atkin-

son(2004) nævner ligeledes, at visse virksomheder statistisk har efterprøvet om denne kausalitet er til ste-

de eksempelvis omkring medarbejdertilfredshed og kundetilfredshed.41 Andre ledere går mere kvalitativt til

værks og vurderer på ledermøder om fremsatte initiativer har nogle gunstige effekter. Der er altså i ud-5

gangspunktet tale om en iterativ strategiformuleringsproces, som det også fremgår af nye indlæg til kon-

ceptet af Kaplan(2008).42 Den logiske slutning af præmisserne fra Bukh et al.(2004) og Kaplan og Atkin-

son(2004) må derfor lyde, at de årsagsvirkningssammenhænge som defineres i scorecardet, løbende kan

revurderes, hvorfor datakrav skal kunne understøtte dette.

4.4 Den strategifokuserede organisation 10

Kaplan har videre i sit arbejde med strategikortet og balanced scorecard fremsat retningslinjer for hvorle-

des en virksomhed kan arbejde på at blive en strategifokuseret organisation, og dette arbejde har frem-

bragt flere principper.

Et princip er, at der skal skabes en følelse af nødvendighed for strategien for at strategifokuseringen i en

virksomhed fungerer.43 Dette er også, hvad Kotter(1999) fremstiller for ethvert nyt forandringstiltag i en or-15

ganisation. Medarbejdere skal således føle, at der en mening med strategikortet og balanced scorecardet.

Dette må være en logisk slutning, når en virksomhed aktivt ønsker, at medarbejderne skal agere ud fra kon-

ceptet. Medarbejdernes læring omkring den valgte strategi skal endvidere fokuseres, således at eksempel-

vis brochurer og nyhedsbreve muliggør en kommunikation af strategien. Strategikortet er således et over-

ordnet værktøj til at kommunikere strategien med strategiske temaer, mens balanced scorecard mere mål-20

rettet måler effekten af strategiske initiativer for at kunne effektuere strategien. Virksomheder er således

blevet opmærksomme på, at strategien er en kontinuerlig proces, og organisationer, der har arbejdet med

balanced scorecard, har således oplevet, at processen omkring udarbejdelsen af balanced scorecard har

været givtig foruden selve målene i scorecardet. Konceptet giver lederne en ramme til at implementere

strategien.44 25

For virksomheder kan der endvidere arbejdes med både et overordnet scorecard for hele virksomheden,

for afdelinger, samt helt ned til det operationelle niveau. De personlige målsætninger skal dog i den teore-

41 Kaplan & Atkinson(2004) s. 387 42 Kaplan & Norton(2008) s. 65 43 Kaplan & Atkinson(2004) s. 386 44 Kaplan & Atkinson(2004) s. 382


Side 21 af 90

tiske ramme ses i forhold til et højere rangerende scorecard.45 En forankring for at nå de opsatte mål fra

medarbejdernes side kan beskrives i følgende citat: 46

“We could not have gotten the same focus on the scorecard if we didn’t have the link to pay.”

En forankring skal altså også tilføjes af et aflønningssystem, der kan konstrueres i forhold til en vægtning på 5

tværs af individuelle målsætninger med opnåelse af mål på det overordnede scorecard. I Kaplan og Atkin-

son(1998) gives der således bud på, hvorledes en bonusordning kan vægtes til balanced scorecards KPI’er.

4.5 Kritik og forudsætninger ved anvendelse af balanced scorecard

I balanced scorecard skal der være balance mellem fortiden, nutiden og fremtiden i rapporteringen, og år-

sagsvirkningssammenhængene skal eksistere mellem perspektiverne. Det antages desuden, at virksomhe-10

den ud fra de ikke-finansielle målepunkter kan se tendenserne for fremtidens økonomiske resultater. 47

Kaplan fremfører, at de bedste resultater er opnået ved, at virksomheden fokuserer på alle fire perspekti-

ver og opererer med et tilstrækkeligt antal målepunkter, gerne fire til syv målepunkter i hvert perspektiv.48

Ledelsen skal endvidere være dedikerede til anvendelsen af konceptet, og en forankring af strategien til

menig mand på gulvet er essentielt.49 Ved implementeringen af BSC´s målepunkter kræver det ofte, at der 15

skal registreres nye data, og op til en tredjedel af disse data er ikke til stede ved projektets opstart.50

Det er ligeledes vigtigt, at målepunkterne ikke modarbejder hinanden. Der kan således forekomme dys-

funktionelle handlinger for at opnå de langsigtede krav opsat i BSC. Et eksempel ville være, at en virksom-

hed kunne udskyde kreditperioden for kunder for at forbedre kundetilfredsheden. Det kan være problema-

tisk, hvis scorecardets målepunkter integreres med virksomhedens bonusaflønningssystemer,51 da medar-20

bejderne dermed kan få incitament til at forværre virksomhedens økonomiske resultater på især langt sigt.

Det fremgår endvidere ikke af scorecardet, hvornår præstationerne kan måles, altså effekten af initiativer-

ne. Signalerne fra de ikke-finansielle nøgletal ses således forskudt i forhold til de økonomiske effekter. Der

45 Kaplan & Atkinson(2004) s. 385 46 Kaplan & Atkinson(2004) s. 385 47 Nørreklit et al.(2008) s. 65 48 Kaplan & Atkinson(2004) s. 376 49 Kaplan & Atkinson(2004) s. 388-389 50 Kaplan & Atkinson(2004) s. 390 51 Kaplan & Atkinson(2004) s. 420


Side 22 af 90

er således en tidsforsinkelse imellem årsag og virkning, og der kan være stor forskel på, hvornår de enkelte

indsatser kan ses på virksomhedens økonomiske resultater.52

En anden faktor, som Kaplan ikke nævner, i forhold til tidsdimensionen er endvidere, hvis tankerne fra

Cross et al.(1990) anvendes, ville nogle KPI’er skulle måles langt oftere end andre. Rapportering af virksom-

hedens markedsandel og rettidig leveringsrate kan således have en forskellig rapporteringshyppighed, da 5

de udvikler sig forskelligt over tid.53

Der har ligeledes været kritik af årsagsvirkningskæderne i strategikortet, da verden er så kompleks, at det

ikke kan udelukkes, at andre faktorer end de nævnte i et strategikort, påvirker et givet resultat. Dermed

findes der ikke fuldstændige bestemmende årsagsvirkningsrelationer mellem de opstillede sammenhænge.

Det kan blandt andet udmønte sig i, at ikke-opnåede målsætninger ville være nået, hvis ikke en ubeskrevet 10

faktor havde spillet ind, og så ville resultatet være misvisende for den proces, der er foregået i virksomhe-

den.

Bukh et al.(2004) forsvarer dog BSC ved at påstå, at strategikortets årsagsvirkningssammenhænge ikke var

tænkt som fuldstændige deterministiske relationer. Der er i stedet tale om at strategiske hypoteser og i til-

fælde af, at en hypotese ikke bliver opfyldt, må nye sammenhænge identificeres. At der kan være andre 15

faktorer, der påvirker et givent måltal, ændrer dog ikke ved, at hypoteserne er grundlaget for, at aktiviteter

kan iværksættes for at forbedre organisationens resultater. Det er således vigtigt, for at kunne identificere

virksomhedens styringsmekanismer, at der bliver opstillet hypoteser om kausale sammenhænge.54

52 Nørreklit et al.(2008) s. 66 53 Cross et al.(1990) s. 34 54 Bukh et al.(2004) s. 32


Side 23 af 90

5. Data warehouse

I 1980’erne gjorde de to IBM-udviklere Barry Devlin og Poul Murphy sig deres første tanker omkring data

warehouse(DWH), da de udviklede business data warehouse. Alligevel er det den amerikanske IT-ekspert

og forfatter William Harvey Inmon,55 der af mange er kendt som faderen til DWH. I slutningen af 80’erne og

i starten af 90érne var der dog flere som udviklede lignende løsninger, men Inmon var den første til at skri-5

ve en bog og holde foredrag om DWH.

Der findes mange forskellige varianter af DWH’et, da et DWH skal udvikles specifikt til en virksomheds unik-

ke karakteristika samt behov, og fordi skiftende omverdensforhold nødvendiggør en tilpasning af DWH’ets

enkelte bestanddele hertil. Dette kunne være økonomistyringsmæssige hensyn og lovmæssige hensyn.

Virksomhedernes behov for rettidig, korrekt beslutningsinformation er derfor ligeledes stigende. DWH’erne 10

er også i takt med informationsteknologiens frembrud blevet mere og mere populære, og er i dag udbredt i

alle typer af virksomheder. Dette skyldes for det første, at mængden af data, som de enkelte virksomheder

har behov for at indsamle og lagre, er langt større end tidligere. Denne data indsamles fra mange forskellige

kilder, og det er derfor nødvendigt at ensrette dataene. For det andet har informationsteknologien nu gjort

det muligt at arbejde hurtigt med store mængder data, der før krævede uanede mængder af ressourcer at 15

håndtere. For bedre at håndtere begrebet data warehouse tages der udgangspunkt i følgende definition:56

”A data warehouse is a: subject oriented, integrated, nonvolatile, time vari-ant collection of data in support of management decisions.”

Med subject oriented eller ”emneorienteret” mener Inmon(2000), at databasen skal være organiseret såle-

des, at alle data skal knyttes til bestemte objekter eller begivenheder i det enkelte DWH. Dette betyder, at 20

et DWH bliver dimensioneret på de største og vigtigste emner i virksomheden, hvor operationelle applika-

tioner oftere er dimensioneret på processer i virksomheden.57 At, et DWH skal være integrated betyder, at

de data, som virksomheden bruger, skal komme fra alle systemer og være konsistente. Dette vil sige, at

virksomheden konsekvent skal anvende de samme standarder for DWH’s attributter i de respektive tabeller

i DWH’et. Således opnås der en ensartethed, og dataene kan derfor sammenkædes på tværs af forskellige 25

systemer. Integrationen af data i et DWH kommer normalt til syne i ETL-processen, som vil blive forklaret

efterfølgende. Nonvolatile eller uforanderlige skal forstås sådan, at data aldrig ændres eller slettes. Data

skal lagres i det enkelte DWH, så de kan anvendes i fremtidige rapporter, og således at tidligere rapporter

ikke ændrer sig. På denne måde kan der altid ses tilbage og udformes rapporter på baggrund af udviklingen

55 William H. Inmon er også kendt som Bill Inmon. 56 Inmon(2000) s. 1 57 Inmon(2000) s. 2


Side 24 af 90

over tidligere år. Det, at data i en database skal være time variant eller ”tidsafhængige”, betyder, at datae-

ne altid skal sammenkædes med en dato, så ændringer kan ses over tid, hvorfor der skal indbygges en tids-

dimension. Til at forklare hvordan et DWH fungerer, tager resten af afsnittet udgangspunkt i følgende figur:

Figur 5: Data Warehousings bestanddele

5

Kilde: Egen tilvirkning på baggrund af Kimball(1998)

Af figuren ses det, at data fra de enkelte datakilder som ERP og andre operative systemer udtrækkes til et

lagringsareal, hvor dataene gennemgår en transformationsproces. Efter transformationen af data, kan de

uploades til præsentationsserveren eller DWH’et. Dataene uploades således ind i DWH’ets dimensioner og

facttabeller. Der sker således en organisering efter det opbyggede DWH. Herefter kan de enkelte 10

slutbrugere udtrække rapporter med relevant beslutningsinformation til benyttelse i beslutningssammen-

hænge. I de følgende afsnit vil DWH og præsentationsserver blive brugt simultant, idet Kimball ser hele

DWH’et som ovenstående figur, men Inmon benytter udelukkende begrebet DWH om præsentations-

serveren. Den semantiske opfattelse af DWH bliver derfor i rapporten lig med den semantiske opfattelse af

præsentationsserveren. 15

Efterfølgende forklares de enkelte bestanddele af figuren, hvorefter en diskussion af Inmons og Kimballs

tilgange vil fremstå. Der tages udgangspunkt i data marter i figuren for at få en generel forståelse for,

ETL-Processen:

Transformationspro-cessen af data er af størst betydning for det senere data warehouse. Dataene bliver her renset, standardiseret og kombineret gennem joins

Data Marter:

Dimensional model-lering af data marter i stedet for E/R Dia-grammering. Op-bygning af dimensi-oner og facttabeller til data marter på baggrund af desig-nede metadata

Datakilder Præsentation Server

Udtrækning

Udtrækning

Udtrækning

Der bliver uploadet data ind i alle dimensioner og facttabeller, hvilket betyder, at der sker en upload til de enkelte data mar-ter.

Forespørgsler:

Brugerne af Da-ta Warehouset har brug for forskellige rap-porter, og der skal genereres forespørgsler til hver enkel rap-port

Slutbrugere

Der skal oprettes forespørgsler til alle rapporter fra data warehouset.

Data Stagging Area


Side 25 af 90

hvorledes den dimensionale modelering benyttes for efterfølgende at forklare, hvordan dataene

transformeres til at understøtte den dimensionale modellering.

5.1 Data mart

Indenfor data warehousing indtager data marter en central rolle, idet et DWH består af en række data mar-

ter, der er sammenkædede gennem dimensionerne i DWH’et ifølge Kimball. Data marter er således små 5

delelementer af et DWH, opbygget efter dimensional modellering og indeholdende en facttabel samt alle

relevante dimensioner.58 Inmon(1999) sammenkæder endvidere data mart begrebet med den senere rap-

portering, hvilket ses af følgende citat:59

“A data mart is a collection of subject areas organized for decision sup-port based on the needs of a given department.” 10

Data marter kan heraf udledes til at være unikke for de enkelte formål, hvorom de er designede. Det vil si-

ge, at et data mart med salg i fokus vil være unikt for salgsafdelingen eksempelvis. Heraf kan det også ses,

at data marter ofte vil være opbygget om processer i virksomheden.

For at forstå sammenhængen mellem data marter og data warehousing vil begrebet dimensional modelle-

ring efterfølgende blive forklaret, og herunder vil dimensioner og facttabeller også blive forklaret. 15

5.1.1 Dimensional modellering

Dimensional modellering står i kontrast til ERP systemers E/R diagrammering, hvilket er hele ideen bag di-

mensional modellering. E/R diagrammering er god til at strukturere en stor mængde af data som transakti-

oner i en virksomhed, da opbygningen af et E/R diagram søger at fjerne redundans i databasen. Dimensio-

nal modellering kæder derimod forskellige aspekter af virksomheden sammen gennem opdelingen af fact-20

tabeller og dimensioner. Dimensional modellering er derfor bedre til at bearbejde forespørgsler, da det er

mere tydeligt, hvor de ønskede data skal findes, og det er samtidigt muligt at sammenkæde de ønskede

aspekter af virksomheden.60 Herudover skal færre tabeller joines i forhold til E/R diagrammet, hvilket giver

et bedre overblik.

Dimensionale modeller består altid af mindst én facttabel, med en syntetisk eller sammensat primærnøgle, 25

og en række dimensioner, der er relateret til den enkelte facttabel.61 En facttabel indeholder udover frem-

58 Kimball(1998) s. 144 59 Inmon(1999), s. 3 60 Kimball(1998) s. 147 61 Kimball(1998) s. 144


Side 26 af 90

mednøglerne til dimensionerne en eller flere numeriske fakta,62 som dimensionerne samtidig er sammen-

kædede med gennem den referentielle integritet. Det er disse fakta, der senere skal laves rapporter på.

Dimensionerne er beskrivende,63 og indeholder som sådan, normalt kun data, som beskriver den enkelte

dimension. Dataene i dimensionen vil således være så granulære som muligt, eksempelvis udspecificeret på

den enkelte kunde eller det enkelte produkt.64 Det bør nu være klart, at den samme dimension kan benyt-5

tes i flere forskellige data marter, hvorfor dimensionerne nødvendigvis må tilgodese flere formål. Proble-

matikken rejser sig, hvis der benyttes forskellige opfattelser af de samme begreber afdelinger i mellem i en

virksomhed. Her bliver begrebet konformitet af vigtig karakter. Konforme dimensioner eksisterer således,

hvis dimensionerne data marterne imellem er identiske.65 Gennem de konforme dimensioner kan hele data

warehouset sammenkædes, da de enkelte data marter kan sammenkædes gennem de konforme dimensio-10

ner. Dette ses af følgende citat af Kimball(1998):66

”A data warehouse is made up of the union of all its data marts”

Efterfølgende vil de forskellige designmuligheder indenfor dimensional modellering blive forklaret.

Stjerneskema

Stjerneskemaet er den mest simple form for data mart, da de enkelte dimensioner blot kædes sammen 15

med facttabellerne gennem fremmednøglerne i facttabellerne. Hver primærnøgle i dimensionerne refere-

rer således til en del af primærnøglen i facttabellen,67 hvorfor den referentielle integritet skal overholdes.

Stjerneskemaet kan ses af nedenstående figur 6. I stedet for at benytte en sammensat primærnøgle, er der

mulighed for at benytte en syntetisk primærnøgle i facttabellen. Både konstellationsskemaet og snowfla-

keskemaet bygger videre på stjerneskemaet og vil blive forklaret i det følgende. 20

62 Kimball(1998) s. 144 63 Kimball(1998) s. 144 64 Kimball(1998) s. 160 65 Kimball(2002a) s. 108 66 Kimball(1998) s. 18 67 Kimball(1998) s. 144


Side 27 af 90

Figur 6: Stjerneskema


Snowflakeskema

Et snowflakeskema bygger videre på stjerneskemaet, men dimensionerne i snowflakeskemaet er delvis 5

normaliserede, hvilket betyder, at der benyttes referentiel integritet. Snowflakeskemaet er således en ud-

videlse af stjerneskemaet, hvor de enkelte dimensioner delvis normaliseres på 3. normalform. Fordelen ved

dette er, at forespørgselsprocessen er hurtigere i nogle tilfælde, da der kræves mindre lagringsplads og på

grund af samling af mindre opslagstabeller end i stjerneskemaet. Ulempen er så til gengæld at de ekstra

opslagstabeller kræver yderligere vedligeholdelse og tager længere tid at oprette. Om det er nødvendigt at 10

lave et snowflakeskema afhænger i stor grad af, hvor mange data, der skal komponeres ud i en ny tabel.

Figur 7: Snowflakeskema


15


Side 28 af 90

Konstellationsskema

Det mest komplekse skema er konstellationsskemaet. Dette skyldes, at der er flere facttabeller i det samme

skema. Fordelen ved konstellationsskemaet er, at der undgås at oprette de forskellige dimensioner flere

gange, og dermed sikres det, at der er skabes konforme dimensioner. Der kan dog være problemer angå-

ende adgangen til skemaet, da det ikke er alle dele af konstellationsskemaet, som den enkelte bruger bør 5

have adgang til. Konstellationsskemaet kan ses af nedenstående figur.

Figur 8: Konstellationsskema


5.1.2 Metadata 10

Før at de enkelte data marter kan opbygges, er det vigtigt, at der er udarbejdet udførlige metadata, der kan

lægge til grundlag for den senere udarbejdelse af DWH’et. Metadataene bør ligeledes dokumenteres, så

nye medarbejdere kan arbejde videre med DWH’et problemfrit,68 hvilket vil sige, at DWH’ets dimensioner,

facttabeller og datakilder ikke skal kortlægges igen.

68 Kimball(1998) s. 436


Side 29 af 90

Metadata er ofte beskrevet som data om data,69 hvilket vil sige, at metadataene beskriver, hvor dataene

ligger i databasen, hvordan dataene er konstrueret, samt hvor dataene i DWH’et kommer fra, og hvordan

dataene var konstrueret i kildesystemet. Denne dokumentation indeholder således både metadataene for

præsentationsserveren og datakilderne. Metadataene kan derfor danne grundlag for den senere ETL-

proces, hvilket vil blive forklaret i følgende afsnit. 5

Til rapportens DWH benyttes følgende tabelstruktur til at beskrive metadataene:

Dimensi-

on/Fakta

Dimensions-

niveau

Dimensions-/Fakta

attribut

Kolonne-

navn

Data-

type

Læng

de

Not

Null

Kilde-

navn

Kilde-

tabel

Kildeko-

lonne

Data-

type

Læng

de

No-

ter

Efter metadatene til DWH’et er beskrevet, og tabelstrukturen er konstrueret, kan datafangsten ske. Dette

sker gennem ETL-processen.

5.2 ETL-processen 10

ETL står for Extraction, Transformation og Loading, og processen kan siges at være central for DWH’et, da

de fleste data, der findes i DWH’et, kommer andet steds fra. ETL-processen kan som sådant forstås som en

proces udenfor DWH’et. ETL-processens tre dele vil efterfølgende blive forklaret, men hele processen kan

forstås på følgende måde:70

“The data warehouse is loaded with data that has been transformed com-15 ing from operational systems. The data coming from the operational sys-tems undergoes a significant amount of conversion and transformation before the data is readied for loading into the data warehouse”

Denne fremlægning stemmer ikke overens med Kimballs(1998) udlægning af DWH’et. Hos Kimball(1998)

indgår der en række processer i hele DWH-miljøet. Det vil sige, at udtrækningen, transformationen og den 20

efterfølgende overførelse af data til præsentationsserveren er de processer, der foretages i Kimballs(1998)

stagging area.71 Hos Kimball er ETL-processen således en del af DWH’et. I anden litteratur ses ETL-

processen ikke som en del af data warehouset, men derimod som processen, hvorved data stilles til rådig-

hed for DWH’et. Denne uoverensstemmelse kan forklares ved, at Kimballs præsentationsserver af disse op-

fattes som selve DWH’et. Uanset hvilken tilgang der benyttes, kan følgende figur være med til at forklare 25

ETL-processen:

69 Imhoff(1999) s. 8 70 Inmon(2000) s. 1 71 Kimball(2002a) s. 8


Side 30 af 90

Figur 9: ETL-processen


Af figuren ses det, at udtrækning af data sker fra datakilderne - ofte fra de operationelle systemer. Herefter

transformeres dataene, så inkonsistens mellem metadataene undgås, hvorefter dataene kan loades i præ-5

sentationsserveren eller DWH’et. Af dette kan det udledes, at udtrækningen af data skal være den første

proces, da de følgende to processer sker på udtrækningens grundlag. Udtrækningen af data kan ses som

læsningen og forståelsen af kildedataene, hvorefter de kopieres over i et lagringsområde.72 Efter at dataene

er udtrukket, skal dataene transformeres, før de kan loades ind i DWH’et. Transformationsprocessen er den

mest krævende proces i ETL-processen, fordi der skal foretages en række delprocesser, før dataene fra de 10

forskellige systemer er kompatible med hinanden og kan loades ind i DWH’et.73 Transformationen af data

har således til formål at forberede dataene til præsentationsserveren.74 Det er tidligere skrevet, at et DWH

er integreret, og transformationsprocessen skal løse dette kriterium. Det betyder, at dataene skal standar-

diseres, så kildedata fra forskellige systemer kan fungere sammen, hvorfor metadatene bliver af stor inte-

resse. Af ovenstående figur 9 kan det udledes, at ETL-processen skal foretages, hver gang en ny datakilde 15

benyttes. Dataflowet skal i ovenstående både forstås som reelle data og metadatene, da der kan forekom-

me transformationer af begge. Dette kan skyldes, at kildesystemerne benytter forskellige datatyper til den

samme attribut, hvorfor både metadata og data må ensrettes efter en forelagt standard i DWH’et. Køn

kunne være et eksempel på denne problematik. Det er således transformationsprocessens formål, at løse

72 Kimball(1998) s. 23 73 Kimball(2002a) s. 8 74 Kimball(1998) s. 16

Datakilde

Extraction: Udtrækning af data

Transformation:

Dataene skal forarbejdes før de er klar til loadning. Dette skyldes forskellige dataformater, redundans mellem datakilderne o.l.

Lagringsareal

Load: Indførsel af data i DWH

Præsentationsser-ver/Data Warehouse

Dataflow fra data-

kilder

Tilbagefør-sel af me-tadata


Side 31 af 90

disse problemstillinger. Metadataene fra præsentationsserveren, som trækkes ind i lagringsområdet, er

dimensionernes og facttabellernes opbygning i data marterne. Disse metadata er den standard, som data-

kildernes metadata nødvendigvis må tilpasses til i lagringsområdet, for herefter at dataene fra datakilderne

kan tilbageføres til præsentationsserveren. Transformationsprocessen er således afgørende for dataene i

DWH’et, og denne delproces vil derfor blive uddybet i det følgende afsnit. 5

5.2.1 Transformationsprocessen

Transformationsprocessens overordnede mål er behandlet ovenfor, og transformationsprocessens ar-

bejdsområde vil blive uddybet i det følgende. Her vil fokus specielt være på at fjerne og ændre de fejldata,

der eksisterer ved udtrækningen fra de operationelle systemer.

Der skelnes mellem metadatarelaterede og datarelaterede problemer. Herudover kan der opstå problemer 10

indenfor det enkelte kildesystem og DWH’et, samt kildesystemerne imellem. Dette er illustreret i neden-

stående figur:

Figur 10: Datakvalitetsproblemer

15

Kilde: Egen tilvirkning af Rahm & Hai Do(2000)

Figuren viser, hvordan dataproblemer kan henføres til fire forskellige problemstillinger. Udover de fire

ovennævnte problemer, vil det oftest være tilfældet, at der opstår metadataproblemer indenfor det enkel-

te kildesystem og DWH’et, når kildesystemerne skal sammenkædes.75 Det vil sige, at sammenkædningen af 20

flere forskellige datakilder betyder, at det enkelte kildesystems data skal transformeres til nogle fastlagte

dimensioner og facttabeller i et DWH. Metadataproblemerne i den enkelte datakilde vedrører dataenes de-

sign i den enkelte datakilde. Manglende integritet i designet kan være et eksempel på metadataproblemer i

denne henseende, hvor dataproblemerne indenfor den enkelte datakilde vedrører alt det, der ikke kan re-

lateres til metadataproblemer.76 Det kan eksempelvis være stavefejl. 25

75 Rahm & Hai Do(2000) s. 2 76 Rahm & Hai Do(2000) s. 3

Transformation af dataene

Den enkelte datakilde Datakilderne imellem

Metadataproblemer Dataproblemer Metadataproblemer Dataproblemer


Side 32 af 90

I det tilfælde, at flere datakilder skal integreres med hinanden, antager problemerne en hel anden karakter.

Metadataproblemerne bliver i denne sammenhæng spørgsmål om navnemæssige og strukturelle konflikter

kildesystemerne imellem. Navngivningskonflikter skyldes, at forskellige datakilder vil benytte forskellige be-

tegnelser. Det kan således både være et problem, at det samme navn benyttes om forskellige objekter da-

takilderne imellem, og der benyttes forskellige navne om de samme objekter. Det kan eksempelvis tænkes, 5

at produktbegrebet benyttes forskelligt i produktionsafdelingen og salgsafdelingen i en virksomhed. De

strukturelle problemer vedrører, hvilke designvalg der er benyttet ved oprettelsen af tabeller i datakilderne

og inkonsistens mellem disse designvalg.77 Det kan være valget af datatyper, integritetsbegrænsninger og

lignende. De største problemer med dataene opstår datakilderne imellem, da ETL-processen bliver af en

mere omfattende karakter, når flere datakilder skal sammensættes. 10

5.3 Inmon vs. Kimball

Til udarbejdelse af et DWH findes der hovedsageligt to tilgange. Bill Inmon og Ralph Kimball repræsenterer

hver sin tilgang til data warehousing, men selv om Inmon og Kimball overordnet set er enige om DWH’ets

definition, er der flere punkter hvor de ikke er enige. Dette er især ved opbygningen af DWH’et, hvor de er

uenige i, hvordan data marterne skal opbygges. For at kunne arbejde videre med udviklingen af et DWH er 15

det nødvendigt at kende forskellene mellem de to tilgange, da valg og fravalg kan få betydning for, hvordan

det endelige design kommer til at fremstå. Det vil således få konsekvenser, om der anvendes Inmons ”Cor-

porate Information Factory”(CIF) eller Ralph Kimballs ”Bus-arkitektur”, da de grundlæggende er modstri-

dende tilgange til data warehousing.78

Nedenstående tabel opridser de væsentligste forskelle på de to tilgange: 20

25

77 Rahm & Hai Do(2000) s. 4 78 Kimball(1998) s. 18-19


Side 33 af 90

Figur 11: Inmon vs. Kimball

Inmon(Corporate Information Factory) Kimball(Bus-arkitektur)

Induktiv tilgang Deduktiv tilgang

Top-down Delvist Bottom-up

Data marter udspringer af data warehouse Data marter bliver til data warehouse

Lang udviklingsfase Hurtig udviklingsfase

Tillader ikke redundans Tillader redundans

Nem vedligeholdelse og fejlsøgning Mere problematisk vedligeholdelse og fejlsøgning


Som det ses i tabellen herover, er der store forskelle på de tilgange, som henholdsvis Inmon og Kimball re-

præsenterer. Tabellen er opstillet efter yderligheder, og forskellene er ikke helt så sort-hvide, som de frem-

står herover. Efterfølgende vil de to tilgange blive uddybet. 5

5.3.1 Corporate Information Factory

Inmon har, siden han nedfældede sine tanker om DWH, været fortaler for Corporate Information Factory

tilgangen. Inmon argumenterer for, at et DWH skal laves uafhængigt af de efterfølgende analyser. Denne

top-down tilgang betyder, at alle potentielle data skal konstrueres i DWH’et formålsuafhængigt. Den store

mængde indsamlede data skal således optræde i normaliserede tabeller, og de enkelte formål skal derfor 10

først defineres efter designfasen er gennemført.79 Bill Inmon er således fortaler for en induktiv tilgang, hvor

der først ved behovet for de enkelte rapporter, udformes de enkelte data marter i emnebestemte gruppe-

ringer, som kan afhjælpe svaret på de enkelte problemstillinger. Inmon(1999) argumenterer for dette, da

han ikke mener, det er muligt at følge Kimballs tilgang med at opbygge data marter og samle disse i et

DWH. Den væsentligste grund til, at Inmon argumenterer for denne tilgang er, at redundans undgås, da alle 15

data kun optræder én gang i det samlede DWH. Følges denne tilgang ikke opstår der redundans data mar-

terne imellem. Dette ses af nedenstående citat fra Inmon:80

79 Inmon(1999) s. 3 80 Inmon(1999) s. 2


Side 34 af 90

”… when you don't build a data warehouse, there is: massive redundancy of detailed and historical data from one data mart to another…”

Som udspring af dette bliver det også langt nemmere at fejlsøge og vedligeholde disse data, da der er klar-

hed over, hvor de enkelte data er lagret. Ulempen ved denne tilgang er dog derimod, at designfasen er

tidskrævende, da der formålsubestemt skal indsamles data. Dette bevirker, at der går længere tid, førend 5

der fremkommer resultater fra de enkelte data marter, da disse først kan designes, efter et fuldendt DWH

er færdiggjort. Ydermere vil nogle af de indsamlede data ikke nødvendigvis skulle anvendes til rapporter og

indsamles derfor uden nogen direkte nytte på kort sigt. Dog kan det på langt sigt være anvendeligt til sene-

re rapporter.

5.3.2 Bus-arkitektur 10

Kimball er dog af en anden overbevisning, da han er fortaler for bus-arkitekturen. Denne tilgang adskiller

sig i nogen grad fra Inmons tankegang. Kimball beskriver bus-arkitekturen således:81

”We impose some very specific design requirements on every data mart. Every data mart must be represented by a dimensional model and, within a single data warehouse. … This is the basis of the Data Warehouse Bus 15 Architecture.”

Han hælder mere til den deduktive bottom-up tilgang, der tager udgangspunkt i, at de mange data marter,

der designes, kan samles og dermed danne det samlede DWH. Denne tilgang bygger på konforme dimensi-

oner, hvor de enkelte data marter designes i et omfang, hvor de findes nødvendige.82 På den baggrund op-

står der et DWH, og det udvides efterfølgende med data marter, som hver især skal varetage et bestemt 20

formål. Da de enkelte data marter kan indeholde identiske data, opstår der redundans, når de forskellige

data marter samles i et DWH. Kimball ser dog ikke store problemer i dette, da noget redundans øger ha-

stigheden på forespørgsler, fordi færre tabeller skal joines. Denne tilgang giver en hurtig udvikling af

DWH’et, da det ikke tager ret lang tid at udarbejde et enkelt data mart, og informationen kan derfor hurtig

kanaliseres ud til beslutningstagerne. På lidt længere sigt er det dog ikke så nemt at vedligeholde og fejlsø-25

ge, da flere data går igen, og der er ikke umiddelbart nogen logisk sammenhæng imellem de enkelte data

marter, da de kan være designet forskelligt ude i de enkelte afdelinger. Dette kan vise sig at være proble-

matisk, da det i så fald vil øge tiden for at udtrække beslutningsrelevant information. Der opstår endvidere

problemer med konformiteten. Der kan således designes flere dimensioner om samme emne men med vidt

81 Kimball(1998) s. 18 82 Kimball(2002b) s. 1


Side 35 af 90

forskellige attributter, hvilket ikke er ønskværdigt i et helhedsperspektiv, da dette problematiserer ad hoc

analyser i DWH’et.

Som tidligere nævnt er modsætningerne ikke helt så store, som det er fremført i figur 11 tidligere i afsnit-

tet. Kimball(1998) skriver således i relation til bottom-up kontra top-down problematikken:83

”In both cases, the only workable solution is a blend of the two ap-5 proaches, where we put in place a proper architecture that guides the de-sign of all the separate pieces.”

Hvor Inmon er mere kontant i udmeldingen om sin tilgang, er Kimball mere midtersøgende, hvor han er til-

hænger af en blanding af de to tilgange. Dette skyldes ifølge Kimball, at en yderliggående top-down tilgang

skaber et stort og tungt DWH, der skal færdiggøres, før eventuelle data marter kan designes. Hvorimod en 10

yderliggående bottom-up tilgang skaber usammenhængende data marter, og denne tilgang er heller ikke

ønskværdig at implementere.84

83 Kimball(1998)s. 19 84 Kimball(1998)s. 18-19


Side 36 af 90

6. Data warehouse og balanced scorecard

I dette afsnit fremsættes nogle af de problemstillinger, er forbundet med den overordnede problemstilling;

at opbygge BSC i et data warehouse-design. Ricciardi(2005) nævner i denne sammenhæng, at når en virk-

somhed vælger at rapportere efter en BSC-model ved brug af DWH, bør virksomheden efterfølgende etab-

lere en overordnet IT-strategi for den konkrete virksomhed således, at virksomheden kan arbejde effektivt 5

med modellen. Dette nødvendiggør, at den enkelte virksomhed erhverver sig dedikerede IT-redskaber. Føl-

ges endvidere argumenterne fra Davenport(2006) vil der også i nogle tilfælde gå flere år, før virksomheder

opnår det fulde potentiale af deres implementerede DWH.85 Denne fremføring hænger også sammen

Kaplans egen belysning; at data i 30 procent af tilfældene ikke er til stede i virksomheden i implemente-

ringsfasen af et scorecard. 86 Strategier for registreringer af de ikke allerede eksisterende data, bør derfor 10

opstilles, mens kildedataanalysen bliver et afgørende punkt for at sortere i eksisterende data til den dimen-

sionale opbygning. Ricciardi(2005) nævner således, at den detaljerede sporing af kildedata kan være en

vanskelig og længerevarende proces, hvor mangel på validt data er et særligt problematisk punkt. Metada-

tabeskrivelsen bliver, ifølge Ricciardi(2005), derfor særdeles vigtig.87

Et af stederne, hvor der kan findes kildedata til DWH’et kan være i virksomhedens ERP-system, hvor data til 15

de finansielle nøgletal til den balancerede afrapportering kan findes. Derover skal der i designet af DWH’et

specificeres, hvilket detaljeringsniveau data bør loades ind i præsentationsserveren, da hastigheden i rap-

porteringen bliver særlig berørt af hvilket aggregeringsniveau data ligger på i DWH’et.88 I situationen, hvor

data loades, opstår der endvidere mulighed for fejl i opbygningen af DWH’et, hvis data er blevet fejlagtigt

kædet sammen. Der bør derfor være en nødvendig validering af data før DWH’et tages i anvendelse. 20

Det kan endvidere fremføres, at det kan være særdeles svært at måle den økonomiske effekt ved indførel-

sen af DWH og BSC.89 Dette skyldes, at det er vanskeligt at måle resultaterne på kort sigt, og det derfor ofte

er på længere sigt, at resultaterne kan ses. Så hvis virksomheden ikke direkte agerer på de af BSC frem-

komne resultater, er det svært at definere effekten af de samlede tiltag. Modargumentet til dette er, at

BSC skal i højere grad anses som et værktøj, der kommunikerer virksomhedens strategi, end et værktøj der 25

frembringer nøgletal. Anskues BSC på denne måde, er BSC en nødvendighed for at få implementeret stra-

85 Davenport(2006) s. 107 86 Kaplan & Atkinson(1998) s. 390 87 Ricciardi(2005) s. 12 88 Kimball(1998) s. 149 89 Bernberg(2003) s. 127


Side 37 af 90

tegien i hele organisationen, og virksomhedens samlede fremgang kan dermed betragtes som et delvist re-

sultat af den samlede indsats.

6.1 Valgt tilgang til opbygning af data warehouse

Problemstillingen lægger op til en løsning af DWH opbygningen efter BSC’s principper. Der kan derfor ar-

gumenteres for, at udviklingen af BSC skal følge en Bus-arkitektur, jævnfør Kimball, da Inmons tanker om 5

en fuldendt opbygning af et DWH til alle tænkelige rapporter er en proces, der rækker ud over en længere

periode, end der til dette modul er stillet til rådighed. Resultatet af et DWH ud fra Inmons tankegang ville

være, at der skulle simuleres alle givne tænkelige analyser, som en virksomhed kunne ønske sig, og løsnin-

gen vil derfor blive yderst kompleks.

Opbygningen vil ske efter en Kimball-tankegang, hvorfor det dimensionale design skal opbygges, så rappor-10

teringsmulighederne, for de opbyggede data marter, ikke kan benyttes til andet end de fastlagte formål.90

Der er derfor tale om en afgrænset Business Intelligence-løsning, hvor det opbyggede DWH kun understøt-

ter en BSC-analyse. Der opstår derfor det problem, at det oprettede DWH ikke bliver konformt,91 idet sam-

me dimension forventes, at skulle anvendes til andre rapporter, der kræver andre attributter end de allere-

de implementerede i dimensionerne. I det omfang, at efterfølgende rapporter skal være på allerede med-15

tagne attributter, er dimensionerne dog allerede konforme. Kimballs modargumentation er, at tilføre di-

mensionerne flere attributter for at imødekomme problemet omkring ikke-konformitet, når behovet for

yderligere rapporter opstår.

Idet følgende fremgår en fiktiv case, der har til formål at opridse grundlaget for balanced scorecardet, og

dermed de KPIér der senere skal danne grundlag for opbygningen af DWH’et. 20

90 Kimball(1998) s. 146 91 Kimball(1998) s. 156


Side 38 af 90

7. Case

Den nordjyske fremstillingsvirksomhed, ØKO IS, producerer flødeis med økologiske råvarer. Virksomheden

har i omegnen af 22 fuldtidsansatte og har været en succesfuld forretning siden opstarten i 1996, hvor øko-

logiske varer begyndte at blive populære. Med tiden har ØKO IS vokset sig til at have en væsentlig mar-

kedsandel på markedet for flødeis, men da det er et af de dyreste produkter på flødeismarkedet, erkender 5

virksomheden risikoen for, at den økonomiske krise får deres kunder til at købe billigere flødeis eller helt

fravælge flødeisen. Da ØKO IS i de to foregående regnskabsperioder har haft faldende overskud, kan en

kundeflugt få alvorlige økonomiske konsekvenser for virksomheden. Det har medført en øget mødeaktivitet

mellem virksomhedens direktion og bestyrelse. De er blevet enige om, at virksomhedens vision og strategi

skal finpudses og efterfølgende kommunikeres klart ud til virksomhedens ansatte, så alle arbejder i samme 10

retning. Til at hjælpe sig med det har de kontaktet den nystartede nordjyske konsulentvirksomhed, Rådgiv-

ning4U, som er specialister i at implementere BSC, der skal sikre, at alle ansatte i en virksomhed arbejder

mod samme mål. Rådgivning4U sender straks et kompetent konsulentteam på fire mand ud til ØKO IS, hvor

de holder møder med direktionen og bestyrelsen. Først finder de frem til en vision og strategi for ØKO IS.

Strategien lyder, at ØKO IS i løbet af to år skal være blandt de mest profitable virksomheder i branchen og 15

have markedsandel på mindst 12 procent. Dette skal ske ved, at ØKO IS primært skal forbedre indtjeningen

ved blandt andet at sætte fokus på kunderentabiliteten. Derudover skal der fokus på at nedbringe gælden

for at nedbringe risikoen i den kommende svære periode.

For at strategien kan gennemføres, skal der opsættes en række målsætninger på fire forskellige niveauer i

ØKO IS, henholdsvis det finansielle perspektiv, kundeperspektivet, det interne perspektiv, samt lærings- og 20

vækstperspektivet. Der blev udarbejdet følgende 10 key performance indicators (KPI’er), hvoraf de første

fire er i det nedenstående finansielle perspektiv:

Figur 12: Finansielt perspektiv i ØKO IS

FINANSIELT PERSPEKTIV

KPI Målt på Mål Initiativer

Afkastningsgrad (Årets resultat/ aktiver)

x 100

10 % Forbedret overskuds-

grad og AOH

Overskudsgrad Resultat efter rente/

omsætning) x 100

8 % Fokus på omkostninger-

ne


Side 39 af 90

Aktivernes omsætnings-

hastighed

Omsætning/aktiverne 1,25 gange Fokus på at nedbringe

gælden, samt at ned-

bringe lagerbinding


I det finansielle perspektiv bliver det besluttet, at ØKO IS skal have en afkastningsgrad på 10 procent. Det

skal ske ved at forbedre overskudsgraden såvel som aktivernes omsætningshastighed til henholdsvis 8 pro-

cent og 1,25 gange. For at opnå disse nøgletal bliver opgaven for ØKO IS at fokusere på at nedbringe både

omkostningerne og gælden, mens omsætningen som minimum skal være på samme niveau. 5

Disse tal er allerede eksisterende i virksomhedens kvartalsrapporter, hvorfor det ikke er nødvendigt at ind-

samle yderligere data til udregning af disse. Hvis det er nødvendigt for virksomheden at lave analyser, hvor

dette nøgletal skal bruges med en mere hyppig frekvens, skal tallene dog indsamles via SBO og derefter pe-

riodiseres, så de kan anvendes i beregningerne. Er dette tilfældet, er det vigtigt at være opmærksom på, at

der i de fleste brancher kan være store udsving fra uge til uge eller måned til måned, i så fald er anvende-10

ligheden af disse beregninger ikke så stor. Disse finansielle målsætninger skal understøttes af målsætninger

fra kundeperspektivet.

Figur 13: Kundeperspektiv i ØKO IS

KUNDEPERSPEKTIV


Kundeprofitabilitet (KundeDB/kundeomsætning)

x 100

60 % Fokus på uprofitable

kunder

Kundetilgang (Antal nye kunder / alle kun-

der) x 100

20 % Opsøgende salg. Give

nye kunder fordelagtig

aftaler

Kundefastholdelse 50 % salg i forhold til foregå-

ende periode

90 % af kunderne Besøge kunderne ofte-

re. Indgå lange strate-

giske aftaler med nøg-

lekunder


I kundeperspektivet vil ØKO IS måle på kundefastholdelse, kundetilgang samt kundeprofitabilitet som 15

nøgletal. Disse tre målepunkter er udset som essentielle punkter, da de kan medvirke til at forbedre

overskudsgraden, og i sidste ende afkastningsgraden. Kundefastholdelse skal vise hvorvidt kunderne bliver i


Side 40 af 90

virksomheden, og perioden er afgrænset til at være for det seneste år. Definitionen, på hvorvidt kunderne

er fastholdt, er, om de har handlet for mindst 50 % af det beløb, de handlede for i forrige år. Til at under-

støtte kundeperspektivet har virksomheden det interne perspektiv, hvor der er valgt de to nedenstående

målepunkter.

Figur 14: Internt perspektiv i ØKO IS 5

INTERN PERSPEKTIV


OTD Succesfulde antal leve-

ringer / antal leveringer)

x100

98 % Fokus på at forbedre

kommunikationen in-

ternt i virksomheden

MCE Gennemløbstid / (dato

for ordreafgivelse - dato

for levering)

>0,6 Forbedre informations-

deling internt


I det interne perspektiv bliver der målt på i hvilken grad virksomheden formår at levere ordrerne rettidigt,

og på tiden det tager virksomheden at levere en ordre efter ordreafgivelsen. For at nå de opsatte målsæt-

ninger vil ØKO IS forsøge at forbedre kommunikationen mellem de relevante afdelinger for at minimere ri-

sikoen for misforståelser mellem salgsafdelingen og ekspeditionsfolkene. Den forbedrede interne kommu-10

nikation er også i fokus, når gennemløbstiden for produkter skal forbedres i forhold til hvornår ordren mod-

tages og leveres.

Figur 15: Lærings- og vækstperspektivet i ØKO IS

LÆRINGS- OG VÆKSTPERSPEKTIVET


Medarbejdertilfredshed Undersøgelse 3,8(på 1-6 skala) Flere samtaler og goder

Kompetenceudvikling Antal kursusdage 6(om året) Øget fokus på hvilke

kompetencer, de for-

skellige medarbejdere

bør have



Side 41 af 90

Lærings- og vækstperspektivet understøtter indirekte og direkte de tre foregående perspektiver. Det hand-

ler for ØKO IS om at have medarbejdere, der er villige og kompetente til at nå virksomhedens strategi og

vision, og derfor er målepunkterne medarbejdertilfredshed og kompetenceudvikling. Initiativerne til at

forbedre disse to målepunkter er blandt andet flere medarbejdersamtaler og at tilbyde udvalgte goder til

medarbejderne, samt at sørge for at kigge individuelt på hver enkelt medarbejders kompetencer og behov 5

for nye kompetencer.


Side 42 af 90

8. Opbygning af data warehouse

For at imødekomme ØKO IS’ behov for beslutningsinformation, skal der opbygges et DWH, der kan rappor-

tere på de fastlagte KPI’er indenfor BSC’s fire perspektiver. Det opbyggede DWH, eller rettere præsentati-

onsserver, vil derfor være en intelligent forespørgselsdatabase, der tilfredsstiler den delmængde af beslut-

ningsinformation, som ledelsen i ØKO IS efterspørger. Efterfølgende vil det valgte design blive beskrevet, og 5

overvejelser om opbygningen vil ligeledes fremgå. Der tages således udgangspunkt i en diskussion om hen-

holdsvis ledelsesinformationen og afdelingsinformation fra det opbyggede DWH, og hvordan denne beslut-

ningsinformation fremkommer.

8.1 Ledelsesinformation og afdelingsinformation

BSC anses, i relation til DWH, for at være en ledelsesmæssig rapporteringsmodel, hvor det er ledelsen, der 10

har adgang til informationerne fra modellen. Denne information kan efterfølgende kommunikeres ud til de

menige medarbejdere i organisationen.

Selve rapporteringen vil ske i modul 2, men da der er valgt at opbygge data marter med få attributter, vil

rapporteringen fra dette design kun have et relativt begrænset krav til indeksering,92 hvorfor rapporterings-

hastigheden må vurderes til at være relativ høj. En mere tung indeksering opstår i de tilfælde, hvor databa-15

sen skal indeholde mange attributter specielt i dimensionerne, men også i facttabellerne. Ulempen bliver

dog, at en senere udbygning af DWH’et skal finde sted for, at det kan bruges til andet end BSC. Et DWH kan

dog aldrig være udfyldende over tid, da ændringer i virksomhedens interne og eksterne omgivelser vil af-

stedkomme ændringer i dimensionerne og facttabellerne, da eksempelvis produkt- og kundedimensionen

udvikler sig.93 Et ændret rapporteringskrav vil således betyde, at dimensionerne må ændres med tiden. Ved 20

kun at inddrage attributter til BSC bliver det udviklede DWH dog meget begrænset i sin anvendelse. De få

attributter i dimensionerne danner dog et bedre overblik og øger hastigheden på præsentationsserveren,

men det begrænser som skrevet rapporteringsmulighederne. DWH’et skal derfor ses som et ledelsesrap-

porteringsværktøj, da det kun kan rapportere på de opstillede BSC-mål.

I modsætning til ledelsen vil der på afdelingsniveau være behov for flere attributter i dimensionerne og 25

facttabellerne, da behovet for operationelle beslutningsinformationer er større. Samtidig kan behovet for

ad hoc rapporter være højere, hvilket ligeledes kræver, at DWH’et inddrager data, der ligger uden for de

fastlagte formål for DWH’et. Det kunne eksempelvis være underliggende niveauer til produktdimensionen,

der var af interesse for produktionsafdelingen. For eksempel data om råvarer. Heraf følger det, at dimen-

92 Forstås som en søgeproces 93 Kimball(1998) s. 149


Side 43 af 90

sionerne skal udbygges i det opstillede DWH, hvilket ikke blot forringer hastigheden på afdelingsniveau

men ligeledes på ledelsesniveau i det omfang, at de samme dimensioner benyttes. Dette er dog nødvendigt

for at opnå konformitet i DWH’et. Det vil således altid være en afvejning af langsommere hastighed kontra

mere beslutningsinformation, der skal ligge til grund for virksomhedens DWH. Det vil eksempelvis ikke være

fordelagtigt med et DWH, der ikke kan levere rettidig, relevant og korrekt information. Her tænkes der, at 5

et langsomt DWH kan udforme rapporter, som på modtagelsestidspunktet allerede er forældede. Denne

problemstilling opstår i givet fald kun på afdelingsniveau, da ledelsen sjældent har behov for daglige rap-

porteringer på nøgletal, men nogle nøgletal kan dog være interessante, hvorfor DWH’et, i denne situation,

skal loades dagligt, og rapporterne skal ligeledes udformes dagligt. Dette kunne være information om leve-

ringstider, selvom det er ekstremt at foretage daglige rapporteringer. Alternativt kunne rapporterne, hvis 10

det er muligt, udtrækkes direkte fra de operationelle systemer.

Behovet for ad hoc rapporteringer på afdelingsniveau betyder ligeledes, at DWH’et skal loades med data,

der kan understøtte denne rapportering, hvorfor data uden fastlagt rapporteringsformål skal indsamles.

Ledelsens behov for ad hoc rapporteringer skal også adresseres i designet af DWH’et, men dette kræver

sjældent yderligere datafangst, da disse rapporter typisk vil være af finansiel karakter. Det kan dog sagtens 15

tænkes, at andre ad hoc rapporteringer på ledelsesniveauet kunne være interessante.

8.2 Det opbyggede data warehouse

I designet af DWH er der, som anført i afsnit 5.3, mulighed for to overordnede tilgange. Udgangspunktet for

det opbyggede DWH er, som allerede nævnt Kimballs tilgang, men tilgangen søges så vidt muligt sammen-

koblet med Inmons tilgang. Der opbygges således et DWH, som hverken er et bottom-down eller bottom-20

up DWH. Dette skyldes, at Inmons CIF findes for udfordrende indenfor modulets tidsramme, og da Kimballs

data mart tilgang findes for mangelfuld i designfasen, hvilket skal forstås således, at muligheden for mang-

lende konformitet er problematisk samt problemstillingen vedrørende ad hoc rapporter. Programmæssigt

vil data marterne blive oprettet i Power Architect, men Schemester kunne også være benyttet.

Der er oprettet et konstellationsskema med alle data marterne i Power Architect, der skal danne udgangs-25

punkt for den senere rapportering, og med dette skema vil det være muligt at imødekomme kravet om

konformitet. Ulempen ved konstellationsskemaet er, at alle brugere kan udtrække data fra alle facttabel-

lerne, hvilket kan være problematisk, men da ØKO IS’ formål er ledelsesinformation, ses der bort fra denne

problemstilling. Der kan dog være situationer, hvor hver afdeling kun skal have adgang til data vedrørende

afdelingen, og i en sådan situation skal der opbygges flere data marter som stjerneskemaer for at bruger-30

adgangen er sikret. Konstellationsskemaet er dog valgt for at sikre brugen af konforme dimensioner factta-


Side 44 af 90

bellerne imellem. De enkelte data marter kan ses af bilag 1, og vil blive forklaret i det følgende sammen

med metadataene, der kan ses i bilag 2 og 3.

Udgangspunktet for DWH’et er ØKO IS’ opstillede KPIér. For at udregne dem, er det nødvendigt at samle

data fra virksomhedens operativsystemer og transformere dataene, så de kan oploades til det udarbejdede

DWH. Før denne proces er mulig skal DWH’et dog først designes. Dette foregår ved at opbygge de factta-5

beller og dimensioner, der er nødvendige for at kunne beregne KPIérne. På baggrund af dette er der udar-

bejdet følgende facttabeller og dimensioner:94

Facttabeller: Finansielt

perspektiv

Kundeperspektiv On-Time-

Delivery

MCE Medarbejder-

tilfredshed

Medarbejder-

kompetence

Dimensioner: Kontoplan Tid Sted Medarbejder Partner Produkt

Som det ses af bilag 1, er der opbygget fire data marter til de udvalgte KPIér. For overskueligheden er de

fire data marter opdelt i de fire perspektiver i BSC. Det kan heraf ses, at der er tilknyttet to facttabeller til 10

både det interne perspektiv og læringsperspektivet, hvorfor disse er at opfatte som konstellationsskemaer.

Facttabellen for det finansielle perspektiv skal rapportere på alle KPI’erne i det finansielle perspektiv, hvil-

ket også er tilfældet for kundeperspektivet. On-Time-Delivery-facttabellen i det interne perspektiv har der-

imod kun til formål at rapportere på On-Time-Delivery, og MCE-facttabellen rapporterer også kun på én

KPI. Det samme gør sig gældende i lærings- og vækstperspektivet. 15

Fact- og dimensionstabellerne er opbygget efter metadata, som designet er specificeret i. Metadataene be-

skriver, hvorledes hver enkelt tabel er sammensat, hvilke datatyper der anvendes, og hvor de enkelte kil-

dedata forefindes, samt hvorledes sammenhængen mellem de forskellige niveauer skabes.

Metadataene til facttabellen for levering(On-Time-Delivery) fra det interne perspektiv i BSC, er indsat her-

under for efterfølgende at forklare tankegangen bag opbygningen af tabellen. 20

94 Se bilag 1.


Side 45 af 90

Figur 16: Uddrag af metadata for On-Time-Delivery

Metadataene for OTD i figuren herover viser, hvorledes denne facttabel er bygget op. Den syntetiske nøgle

”SK_OTD_ID” er en entydig nøgle for hver observation/værdi i tabellen. Denne nøgle opbygges ved at tilføje

en sekvens, som det vises senere. Alternativet, til at oprette en sekventiel nøgle, havde været at benytte en 5

sammensat primærnøgle af ordrenummeret og ordrelinjenummeret, for derved at regne på delleverancer.

For at kunne udregne nøgletallet for levering er det nødvendigt med leveringsdato og modtagelsesdato.

Disse datoer bliver således faktaene i tabellen, hvor de resterende attributter er beskrivende. Disse fra-

trækkes hinanden, og dermed fremkommer der enten en 0-værdi hvis ordren er leveret rettidigt, et nega-

tivt tal hvis der leveres for tidligt, og et positivt tal hvis der leveres for sent. På den måde opnås et heltal 10

som både definerer, om der er leveret til tiden, og hvor mange dage leveringen er for sen eller for tidlig.

Det er derefter muligt at selektere de tal, der skal laves rapporter på via select-sætninger, og dermed give

nøgletallet flere drill-down muligheder. Produktnøglen tilknyttes således, så det er muligt at lave en drill-

down for at kunne se, hvilke produkter der ikke leveres rettidigt, og kundenøglen for at se hvilke kunder der

ikke bliver leveret rettidigt til. Dette giver bedre beslutningsinformation om eventuelle handlingsalternati-15

ver for at forbedre leveringstiden.

Alle datoer bliver i designet omformet til heltal. Dette sker ved at kæde tidsdimensionen på datoattribut-

terne. Primærnøglen i tidsdimensionen er derfor datoer, og det er muligt at hente et heltal for dagen fast-

lagt i forhold til starttidspunktet. Det vil sige, at startdatoen i tidsdimensionen har fået tildelt værdien 1, og

efterfølgende kan disse datoer fratrækkes hinanden. Dette stiller dog krav til mange records i tidsdimensio-20

nen. I designet af tidsdimensionen, som denne facttabel refererer til, er der altså valgt at 1. januar 2005 er

begyndelsesdato og 31. december 2010 er slutdato. Tidsdimensionen afgrænses således i dette tilfælde, til

at have 2.192 records.

Efter metadataene og det dimensionale design er forklaret, skal overførslen af data fra kildesystemerne til

Oracles database forklares. Dette vil ske i det efterfølgende afsnit. 25


Side 46 af 90

9. ETL-proces

ETL-processen er teoretisk gennemgået tidligere, og dette afsnit bygger videre på det teoretiske afsnit ved

at inddrage ETL-processen i praksis. ETL-processen bliver gennemført i programmet Pentaho Data Integra-

tion(PDI). I dette afsnit vil udtrækningen, transformationen og den senere overførelse til det opbyggede

DWH i foregående afsnit derfor fremgå. Dataene til dimensionerne og facttabellerne fremkommer således i 5

dette afsnit. Datakilderne til de anvendte ETL-processer er enten SAP Business One(SBO) eller Microsoft Ex-

cel, og datakilderne bliver overført til PDI via henholdsvis Table input og Excel input. Gennem disse funktio-

ner bliver der således skabt forbindelse mellem datakilderne og PDI. I det følgende vil en enkelt transforma-

tion blive forklaret. For at følge foregående afsnit inddrages ETL-processen for facttabellen ”On-Time-

Delivery”. Et udpluk af de resterende transformationer kan ses af bilag 4. 10

Figur 17: ETL-processen for “On-Time-Delivery”

Af figuren kan det ses, at der trækkes data fra SBO fra kildetabellerne; ODLN, RDR1 og ORDR. Disse tre ta-

beller joines gennem funktionen merge join, og da alle tre tabeller indeholder ”DocEntry”, benyttes denne

attribut. Dette kan endvidere ses af metadatene i foregående afsnit. Det blev også nævnt, at der oprettes 15

en sekventiel nøgle, hvilket sker i funktionen Add sequence i figur 17. Den sidste funktion i transformatio-

nen uploader dataene til DWH-tabellen, som i dette tilfælde er i Oracles database. Der bliver således ud-

trukket data fra SAP Business One, som efterfølgende kædes sammen med en ny entydig primærnøgle, og

efterfølgende bliver dataene uploadet til DWH’et.


Side 47 af 90

I PDI kan der, i forlængelse af oprettelsen af transformationer, også oprettes job. Et job er en sekvens af

transformationer, der bliver kørt i den opstillede rækkefølge. I stedet for at køre hver enkelt transforma-

tion, kan alle transformationerne køres med det samme job. I nedenstående figur 18 findes et job for alle

dimensionstransformationerne i PDI.

Figur 18: Job for dimensionerne 5

Som det kan ses af bilag 4, er nogle af transformationer mere simple end andre. Dette skyldes i høj grad,

hvorledes kildesystemet er opbygget. Eksempelvis skal der kun inddrages en enkelt kildetabel til konto-

plansdimensionen, hvor stedsdimensionen benytter tre kildetabeller. Kompleksiteten af transformation-

erne afhænger derfor i høj grad af, hvor normaliseret kildetabellerne er, hvilket vil sige, at et normaliseret 10

kildesystem giver overblik, men samtidig nødvendiggør en mere udførlig ETL-proces.


Side 48 af 90

10. Afrunding modul 1

Gennem dette modul er teorien bag data warehouse og balanced scorecard blevet gennemgået og efter-

følgende sammenholdt med henblik på at belyse de problemstillinger, der opstår, når der skal oprettes et

DWH med udgangspunkt i BSC. Teorien er efterfølgende blevet anvendt på ØKO IS-casen, hvor der især har

været fokus på KPI’erne, da det er dataene til udregningen af KPI’erne, der skaber samspillet mellem BSC og 5

DWH. Derefter er der udarbejdet et dimensionalt design med facttabeller og dertilhørende dimensionsta-

beller. Som afslutning er ETL-processen gennemgået i praksis ud fra Pentaho Data Integration, hvor trans-

formeringsprocessen er analyseret. Modul 1 er dermed grundlaget for det videre arbejde i modul 2, og de

væsentligste dele af modul 1 kommer dermed til at indgå i den samlede semesterrapport.

I dette modul lød problemstillingen således: 10

”Hvordan kan der udvikles et Balanced Scorecard ved brug af Data Ware-housing?”

Det har vist sig, at der generelt kan oprettes et DWH ud fra to forskellige tilgange, og formålet med DWH’et

vil ofte kunne være bestemmende for, hvilken tilgang der bør benyttes. I indestående modul er Kimballs til-

gang valgt, da det derved er blevet muligt kun at udvikle et DWH til strategisk rapportering efter BSC. Alter-15

nativt kunne Inmons tilgang være valgt, hvor en afgrænsning fra andre områder end BSC havde været nød-

vendig, da modulperioden ikke muliggør oprettelsen af en CIF-struktur.


Side 49 af 90

11. Indledning modul 2

Beslutningsinformation er blevet et væsentligt konkurrenceparameter i dag. Virksomheders succes afhæn-

ger af de beslutninger, som virksomhederne træffer. Det vil sige, at den virksomhed, der er bedst til at træf-

fe beslutninger, vil have en fordel i forhold til sine konkurrenter. OLAP er et redskab til at fremskaffe be-

slutningsinformation i det format, som virksomhedslederne ønsker. Dette kan ske efter multidimensionale 5

kuber, hvor dimensionerne repræsenterer de variable, som lederne ønsker beslutningsinformation om.

Måden hvorpå denne beslutningsinformation fremskaffes bliver derfor af afgørende karakter for virksom-

hederne. I modul 1 blev der opbygget et DWH, hvor data i forskellige formater og af forskellig oprindelse

blev samlet. OLAP-løsningerne bygger på strukturerne i DWH, hvorfor OLAP-løsningen kun kan blive så

stærk, som DWH’et er opbygget til. Herudover vil en OLAP-løsnings succes være betinget af den bruger-10

funktionalitet, som løsningen stiller til rådighed.

I takt med at flere virksomheder benytter DWH’er, stiger interessen for OLAP-løsninger tilsvarende.

Codd(1993) skriver således:95

”The need which exists is NOT for yet another database technology, but rather for robust OLAP enterprise data analysis tools which complement 15 the enterprise’s existing data management system and which are rigorous enough to anticipate and facilitate the types of sophisticated business data analysis inherent in OLAP”

I samspil med udviklingen indenfor IT har virksomhedernes behov ligeledes udviklet sig. Dette vil sige, at

mange virksomheder behøver en OLAP-løsning, der tilfredsstiller virksomhedens behov for forespørgsler. 20

Disse løsninger er blevet nemmere at konfigurere med tilføjelsen af SQL/OLAP,96 hvorfor udviklingen af

unikke virksomhedsløsninger ligeledes er muliggjort.

95 Codd(1993) s. 5 96 Eisenberg & Melton(2000) s. 65


Side 50 af 90

12. Arbejdsparadigme modul 2

Til at operationalisere de overordnede tanker omkring de to moduler benyttes et arbejdsparadigme. For-

målet med arbejdsparadigmet er at vise, hvordan opbygningen af modulerne bliver, og derved hvilke afsnit,

der inddrages, samt hvilke teorier der benyttes i de respektive afsnit. Dette gøres for at skabe et overblik

over projektet både for gruppen og for læserne. Af arbejdsparadigmet vil det således fremgå hvilke tilvalg 5

og fravalg, der er foretaget i modulet. Udgangspunktet for disse valg er følgende problemstilling:

”Hvordan kan der teoretisk afrapporteres på balanced scorecard og ba-lanceret vækst ved brug af OLAP”

Af problemstillingen følger det, at der skal opbygges et teoretisk erfaringsgrundlag om balanced scorecard,

balanceret vækst og OLAP. Da BSC allerede er teoretisk behandlet i modul 1, vil der ikke forekomme en be-10

arbejdelse af begrebet igen. Rapporten vil i stedet omhandle det opbyggede erfaringsgrundlag i henhold til

balanceret vækst og OLAP, da forståelsen af OLAP er afgørende for den efterfølgende teoretiske gennem-

gang af det benyttede OLAP-værktøj. Arbejdsparadigmet for modul 2 kan ses af efterfølgende figur.

Figur 19: Projektdesign modul 2

15

20

Kilde: Egen tilvirkning 25

Arbejdsparadigme

OLAP

Rapportering på ØKO IS A/S

Afrunding på Modul 2

Balanceret vækst

Balanceret vækst og BSC

Opbygning af OLAP-kube

Her benyttes Palo til

at fremvise beslut-

ningsinformation

Rapportering på ud-

valgte nøgletal fra

casen


Side 51 af 90

Efter opbygningen af de teoretiske erfaringsgrundlag, vil det være muligt at drage analyser på baggrund af

disse. Balanceret vækst og BSC kædes således sammen i et afsnit, hvor fokus er på, hvordan de to begreber

kan komplementere hinanden i afrapporteringsøjemed. Herefter sættes denne analyse i relation til det op-

byggede DWH fra modul 1, og det undersøges, hvordan de to begreber kan sammenkædes i DWH’et. Der-

efter vil teorien bag OLAP blive beskrevet, herunder formål og opbygning. Der vil desuden blive beskrevet 5

hvilke muligheder, der er indenfor kubeopbygning og hierarkier. Efterfølgende opbygges en OLAP-kube til

afrapporteringen, hvilket sker i Jedox Palo, som er et MS Excel baseret analyseprogram. Afrapporteringen

sker på det finansielle perspektiv fra ØKO IS-casen fra modul 1. Modulet afrundes herefter med en opsam-

ling på hele modul 2.


Side 52 af 90

13. Balanceret vækst

Balanceret vækst vedrører vækststrategien i virksomheder, og hvordan denne vækst fremkommer. Der skal

således være sammenhæng mellem målsætningerne i virksomhederne for, at en langsigtet selvfinansieret

vækst kan opnås. I tilfælde af at målet om vækst bliver for dominerende, kan dette have en ødelæggende

effekt for den fremtidige drift. Der skal derfor være balance mellem målene i virksomheden, hvilket bety-5

der, at der skal indgås kompromisser mellem målsætningerne. Donaldson(1985) fremsatte i ”Financial goals

and strategic consequences” denne problemstilling, og udgangspunktet for indeværende afsnit er således

denne artikel.

Donaldson(1985) opstiller følgende forudsætninger for målsætningsprocessen i virksomheder:97

• Profitabilitet kommer ikke før alt andet. Virksomhedernes målsætninger ændrer sig løbende og af-10

hænger i høj grad af den kontekst, som virksomhederne befinder sig i.

• Virksomheder kan ikke frit sætte målsætninger. Indenfor de markeder virksomhederne agerer på,

findes der grænser og betingelser, som virksomhederne skal tage højde for i fastlægningen af mål-

sætningerne.

• De finansielle målsætninger skal revideres løbende, da en virksomheds omverden er dynamisk, 15

hvilket spiller ind på hvilke målsætningsniveauer, der er opnåelige. Dette er i særdeleshed interes-

sant indenfor konkurrerende måltal, da en ændring for et måltal kan afstedkomme ændringer i an-

dre.

• Virksomhedernes interne kapitalmarkeder skal kontinuerligt forsøge at balancere udbuddet af og

efterspørgslen efter kapital. Der skal således være balance mellem målsætninger, der trækker på 20

kapital, og målsætninger der generer kapital.

• De fleste ledere har svært ved at acceptere og forstå hele målsætningssystemet. De fleste ledere vil

kun fokusere på målsætninger, der har en direkte forbindelse til deres ansvarsområder. Direktører

vil ligeledes ofte prioritere nogle målsætninger over andre, selv om målsætningerne objektivt set er

ligestillet. 25

De finansielle problemstillinger opstår i de tilfælde, hvor virksomhederne ikke er opmærksomme på oven-

stående forudsætninger eller ikke anerkender dem. På baggrund af ovenstående kan følgende formel udle-

des, som danner udgangspunkt for den balancerede vækst i virksomheden:98

97 Donaldson(1985) s. 58 98 Donaldson(1985) s. 66


Side 53 af 90

)investmenton return :(tilnærmet assetsnet on return RONA

skatefter gæld på rente i

forhold apitalgæld/egenkd

resultat årets af delsesratetilbageholr

salget i vækstrateng(S)

:Hvor

i))d(RONAr(RONAg(S)

====

=

−+=

Donaldsons model viser således, hvordan forholdet mellem væksten i salget, RONA og gælds-

/egenkapitalforholdet skal være for, at virksomheden opnår en selvfinansierende vækst.99 Der skal derfor

være sammenhæng mellem alle nøgletallene i formlen for at opnå en selvfinansiering af væksten. Alterna-

tivet er, at finansiere væksten med ekstern kapital. Ligningen er grafisk illustreret i nedenstående figur, 5

hvor positioner over ligningen giver et underskud i finansielle midler og positioner under ligningen giver et

overskud af finansielle midler.

Figur 20: Livscyklus over finansielle prioriteter i virksomheder

Kilde: Donaldson(1985) s. 63 10

99 Donaldson(1985) s. 60


Side 54 af 90

En virksomheds finansielle underskud må enten finansieres med virksomhedens egenkapital eller med eks-

tern kapital, hvorfor gælds-/egenkapitalforholdet vil blive forøget, da gælden enten er steget eller egenka-

pitalen faldet. Modellen er af strategisk karakter og kan som sådan benyttes i planlægningsfasen. Dette

skyldes i høj grad, at der ikke tages højde for ekstraordinære hændelser, der får en indflydelse på de enkel-

te måltal. Som strategisk værktøj kan modellen opdeles i fire sektorer, hvor virksomhedens årlige resultater 5

vil indtage en række forskellige positioner. Målet er at ligge så tæt på ligningen som muligt, men i praksis vil

dette være umuligt. Formålet med ligningen vil således være at planlægge efter ligningen således, at virk-

somhedens målsætninger ikke er umulige at opnå. Samtidig må det fra virksomhedens side være gunstigt

at have produkter i forskellige faser i produktlivscyklussen. For at øge væksten og forbedre RONA, vil det

derfor ofte være nødvendigt først at investere i nye produktmarkeder, hvilket forringer resultatet på kort 10

sigt, men på længere sigt vil forbedre RONA.100 Udviklingen kan ses ud fra ovenstående figur, hvor et pro-

dukts livscyklus finansielt er illustreret. Positionerne 1 og 2 er således kendetegnet ved udgifter i produkt-

udvikling og markedsføring, hvorfor fasene trækker på virksomhedens finansielle midler. Positionerne 3 og

4 er kendetegnet ved et stagnerende marked, en standardiseret produktion og fornuftige dækningsgrader,

hvilket afspejles i et finansielt overskud af kapital. I takt med udfasningen af produktet stiger konkurrencen 15

for at kapre de resterende markedsandele, hvilket mindsker produkternes dækningsbidrag betydeligt, og

det finansielle overskud af midler mindskes. Diversifikation er en mulighed for at undgå for store finansielle

udsving over tid, og Donaldson(1985) skriver følgende:101

”To require the self-sufficiency of all product market positions is to deny

not only reality but also one of diversification’s primary objectives – to 20

make an orderly transition from an income stream that has dried up to

one that is still abundant”

Udover problemstillingen ved at negligere fremtidens finansielle indbetalinger ved at fokusere på kortsigtet

performance, vil ledelsens mål for afkastningsgraden også ofte være arbitrære forstået på den måde, at det

bliver et mål i sig selv at overgå tidligere års resultater uafhængigt af virksomhedens nuværende situation. 25

Herudover vælges der også afkastningsgrader, der kan være med til at selvfinansiere væksten i virksom-

heden, selv om dette måske er urealistisk.102 Det bliver derfor afgørende for virksomhedens langsigtede re-

sultater, at ledelsen tager højde for betalingsstrømmene i virksomheden ved at fastlægge forskellige måltal.

100 Donaldson(1985) s. 62 101 Donaldson(1985) s. 65 102 Donaldson(1985) s. 66


Side 55 af 90

14. Balanceret vækst og BSC

Indeværende afsnit har til formål at kortlægge mulige synergieffekter mellem Donaldsons balancerede

vækstmodel og BSC. Udgangspunktet vil således være at finde ligheder ved at undersøge de underliggende

logiske strukturer bag de to modeller for at sammenkæde dem.

BSC arbejder med 4 perspektiver, hvor balanceret vækst udelukkende arbejder med finansielle tal. Sam-5

menkædningen af BSC og balanceret vækst kan således udelukkende ske ved at sammenkæde BSC’s finan-

sielle perspektiv med den balancerede vækstmodel. Den balancerede vækstmodel er opbygget omkring det

finansielle nøgletal RONA (eller tilnærmet ROI) og væksten i salget. Herudover er det som nævnt forholdet

mellem RONA og andre variable, som er afgørende for den mulige vækst i salget. På denne måde benytter

Donaldsons(1985) model den samme årsagsvirkningssammenhæng, som balanced scorecard bygger på, 10

men denne årsagsvirkningssammenhæng er kun til stede mellem ligningens variable, hvorfor der ikke kan

drages en sammenhæng til de andre perspektiver i BSC. Et finansielt underskud af midler, vil således nød-

vendiggøre en ændring af gælds-/egenkapitalforholdet, som tidligere nævnt. Ved et finansielt overskud af

midler vil det ligeledes være muligt at øge egenkapitalen eller afvikle en del af gælden, hvorfor en ændring

af gælds-/egenkapitalforholdet vil finde sted. Den samme kausalitet lægger til grund for BSC, idet det for-15

udsættes, at der findes en sammenhæng mellem nøgletallene i de fire perspektiver. Denne kausalitet er

dog i mindre grad sikker, end tilfældet er med den balancerede vækstmodel, da sammenhængen i BSC byg-

ger på opstillede hypoteser om nøgletallene. Hvis den matematiske logik sidestilles med BSC’s årsagsvirk-

ningshypoteser, kan modellerne derfor sammenkædes.

I de tilfælde, hvor væksten i salget, RONA eller andre variable i den balancerede vækstmodel indgår som 20

KPI’er i det finansielle perspektiv i BSC, vil det være muligt at sammenkæde den balancerede vækstmodel

og BSC. Dette kan ses af følgende figur.


Side 56 af 90

Figur 21: Sammenkædning af BSC og den balancerede vækstmodel


Da både den balancerede vækstmodel og BSC er strategiværktøjer, komplementerer den balancerede

vækstmodel BSC i strategifastlæggelsen, og kan derfor benyttes til at understrege den likviditetsmæssige 5

strategi. I rapporteringsøjemed vil den balancerede vækstmodel derfor kunne uddybe effekten af strategi-

en bag BSC. Det vil sige, at de likviditetsmæssige effekter af en given strategi kan kortlægges, og det vil væ-

re muligt proaktivt at initiere initiativer for at undgå likviditetsmæssige under- eller overskud. Herved bliver

det muligt for virksomheden, at væksten bliver så høj som muligt, uden virksomheden kommer i likvidi-

tetsmæssige problemer. Den balancerede vækstmodel kan alternativt benyttes som kontrol af, om de op-10

stillede mål for KPI’erne er realistiske, eller om virksomheden bør justere målene, således at et likviditets-

mæssigt underskud undgås.


Side 57 af 90

15. On-Line Analytical Processing

OLAP er et akronym dannet af On-Line Analytical Processing, og begrebet analyserer på data fra blandt an-

det On-Line Transaction Processing (OLTP) systemer, som der tidligere er arbejdet med på studiet. OLAPs

formål er således at udtrække data, hvor OLTP-applikationernes formål er at lagre dataene. OLAP-

applikationernes hovedformål er at fremskaffe hurtig beslutningsinformation til analyser, hvor DWH data 5

aggregeres, hvilket giver slutbrugeren mulighed for hurtigt at analysere dataene.103

For at dataene kan udtrækkes, skal der opbygges en struktur, der underbygger udtrækningen. En OLAP-

applikation kan bygge på enten en relationel database eller en multidimensionel database. Tabellerne i den

multidimensionale database kan yderligere deles op i facts og dimensioner, hvilket er beskrevet i første

moduls afsnit om dimensional modellering. Den relationelle databasestruktur benytter ikke opdelingen i 10

facts og dimensioner, men lagrer derimod dataene i en normaliseret struktur. OLAP-systemer kan således

enten være multidimensionale – MOLAP – eller relationelle – ROLAP.

I MOLAP-strukturer gemmes både granulære kildedata og aggregerede data på højere niveauer. Dette be-

tyder, at MOLAP er væsentligt hurtigere til at hente data, men samtidigt kræver langt mere dataplads.

Denne problemstilling var dog langt større for få år tilbage, men grundet den teknologiske udvikling er MO-15

LAP nu langt nemmere at effektuere. I ROLAP er al data derimod lagret i en relationel database, hvilket sik-

rer den referentielle integritet. Dette kan være et problem ved større data warehouse implementeringer,

da dette stiller langt større krav til behandlingen af data. ROLAP er således langsommere til udtræk af data,

da flere tabeller skal indekseres end ved en multidimensional struktur. I indeværende modul vil ROLAP ikke

blive behandlet dybdegående, da der udelukkende arbejdes med MOLAP. Det følgende afsnit bygger såle-20

des videre på det opbyggede DWH fra det første modul. Der vil derfor kort komme en gennemgang af hi-

storien bag OLAP med hovedvægten på kravene til OLAP-systemer efterfulgt af en teoretisk gennemgang af

kubebegrebet i relation til MOLAP.

15.1 Krav til OLAP-applikationer

OLAP-begrebet opstod første gang i 1993 hvor E. F. Codd udsendte sine 12 regler104 for OLAP-applikationer. 25

På samme tid blev anvendelsen af DWH mere udbredt i virksomhederne, hvorfor behovet for forespørgsler

til DWH’et steg. Behovet for OLAP-applikationer steg således også. Anvendelsen af OLAP har gennem de

seneste 10-15 år oplevet en stor fremgang, hvilket skyldes, at flere virksomheder har opdaget værdiskabel-

sen af OLAP-analyser. Samtidig er mængden af de data, den enkelte virksomhed skal håndtere nu, blevet

103 Pedersen et al.(2001) 104 Der var reelt 13 regler, men da han gav dem numre fra 0-12, kom det til at hedde de 12 regler


Side 58 af 90

større end for bare ti år siden, og det er derfor vigtigere at anvende de metoder og teknikker, som OLAP

bygger på. OLAP spiller derfor en vigtig rolle i de fleste større virksomheder, da det er med til at danne de

rapporter, som ledelsen, i de enkelte virksomheder, tager deres beslutninger ud fra. I 1998 udsendte Mi-

crosoft MS OLAP Server, som var den første applikation dedikeret til OLAP, hvorefter mængden og kvalite-

ten af OLAP applikationer har været stigende.105 5

Ahmad Taleb(2007) har defineret følgende krav til OLAP-applikationer, der er de vigtigste og som stadig er

gældende i dag for OLAP-applikationer:106

• Multidimensionelt konceptuelt view • Gennemsigtighed • Tilgængelighed 10 • Fleksibel rapportering • Ubegrænsede dimensioner og aggregerede levels

Taleb(2007) mener dermed, at fokus bør ligge på dimensionerne, hvor gennemsigtigheden er essentiel, da

slutbrugeren ikke skal bekymre sig om at få adgang til de enkelte data eller andre underlæggende foran-15

dringer. Det eneste slutbrugeren skal anvende er et simpelt logisk skema, som forklarer de enkelte data på

forståelig vis, uanset ændringer i de bagvedliggende data. Anvendeligheden af OLAP-applikationen skabes

af, at der kan tilknyttes mange dimensioner, så beslutningstagerne dermed får et værktøj, som kan bringe

langt mere beslutningsrelevant information på en mere overskuelig måde end spreadsheets alene, selvføl-

gelig forudsat at registreringerne til disse rapporter forefindes i den database, som OLAP-applikationen 20

bygges ovenpå.

Thomsen(2002) benytter fire krav til OLAP-systemer tilsvarende Talebs(2007) fem krav. Thomsen lægger

ligeledes vægt på fleksibiliteten i rapporteringen. Kravet om fleksibilitet findes af afgørende betydning for

OLAP-systemerne, da præsentationen af data kan være afgørende for beslutningstageren. Dette kræver

fleksible strukturer, hvor samme dimension kan illustreres gennem flere hierarkier. Pedersen et al.(2001) 25

lægger ligeledes vægt på hierarkiopbyggelsen som krav til OLAP-applikationer, hvorfor netop dette krav

findes essentielt for afrapporteringen.

Fordelen ved at anvende OLAP består derfor i, at det er muligt at tilføje lige netop de dimensioner, som

brugeren ønsker. Brugeren kan dermed lave sine analyser komplekse med mange dimensioner eller mere

simple med få dimensioner. Herudover vil det via forespørgsler være muligt at lave drill-down og slice-and-30

105 Pedersen & Jensen(2001) s. 41 106 Taleb(2007) s. 9


Side 59 af 90

dice for at se de underliggende årsager for dataene på de aggregerede niveauer. Ved brug af multidimen-

sionelle kuber opnås der rapporter på langt flere data, i en langt mere overskuelig grad end for eksempel i

det todimensionelle spreadsheets.107 Hierarkierne i dimensionerne bliver derfor vigtige. Disse hierarkier får

således afgørende betydning for kubernes udformning, og vil derfor efterfølgende blive behandlet i relation

til OLAP-kuberne. 5

15.2 MOLAP-kuber

Afsnittet tager udgangspunkt i MOLAP-kubernes placering i forhold til tidligere behandlede begreber inden

for data warehousing. I nedenstående figur fremstår gruppens forståelse således af OLAP-processen i en

MOLAP-sammenhæng.

Figur 22: Multidimensional rapportering med OLAP 10

Kilde: Egen tilvirkning med inspiration fra Chaudhuri & Dayal(2003) s. 2 og Kimball (1998) s. 14

I ovenstående figur er det således i processen fra præsentationsserver-området til OLAP-serverområdet, at

opbyggelsen af selve kuberne opstår. De i figuren viste kuber er således alle tredimensionelle, men de kun-

ne ligeså vel have været fire- eller femdimensionale kuber. Kubefremstillingen bliver altså en metafor for de 15

multidimensionale strukturerer,108 som afrapporteringen med OLAP-værktøjer muliggør. Når kubefremstil-

lingen er beskrevet, kan det belyses, at rapporteringen fra de opførte data marter kan foregå på forskellige

107 Thomsen(2002) s. 58 108 Thomsen(2002) s. 66

Slutbrugere

Extract

Transform

Load

Data marter

Datakilder Data Stagging Præsentation Server

Extract

OLAP-server

Eks. PALO

Forespørgsler


Side 60 af 90

måder, hvorfor hierarkiopbygningen i kuberne får betydning for OLAP-applikationernes korrekthed i bereg-

ningerne109 og dermed aggregeringsmuligheder i kuberne.

Dataene i MOLAP-applikationer vises således i multidimensionale kuber med celler for hver kombination af

dimensionerne.110 Rent grafisk vil visningen af celler dog være todimensional, da der i indeværende modul

benyttes PALO, som er opbygget i Excels todimensionelle design, til afrapporteringen. En sådan kube inde-5

holder numeriske facts også kaldet måltal, der har relation til de dimensioner, der er udvalgt i forbindelse

med opbyggelsen af DWH’et. Data marterne til kuben er typisk lavet på baggrund af et stjerneskema eller

snowflakeskema, hvor de enkelte måltal er fremkommet af registreringerne, som findes i facttabellen og

dimensionerne.111

Som tidligere nævnt er datakuberne centrale i OLAP, da det er her, at muligheden for at overskue store 10

mængder data i et multidimensionelt view. Dette understreges af Thomsen i følgende citat:

“Multidimensional database technology is a key factor in the interactive analysis of large amounts of data for decision-making purposes. In con-trast to previous technologies, these databases view data as multidi-15 mensional cubes that are particularly well suited for data analysis.”112

Et eksempel på brugen af en kube kan være, at en handelsvirksomhed har brug for at vide hvilke af deres

produkter, der bliver solgt mest af i henhold til tre regioner og fordelt på måneder. Denne virksomhed kan

udtrække denne rapport i et almindelig spreadsheet, i for eksempel MS Excel eller lignende. Men ved at 20

anvende en MOLAP-kube får de alle tænkelige kombinationer i bare én enkelt kube. Hvorimod hvis virk-

somheden ønskede, at få hver af disse kombinationer fremlagt på enkelte arbejdspapirer ville det være

nødvendigt at udarbejde 48(4*3*4) individuelle celler. Ved at anvende spreadsheets stiger antallet af nød-

vendige udregninger ekspotentielt med antallet af mulige kombinationer. I figur 3 herunder ses eksempler

på to kuber med henholdsvis 48 og 125 mulige celler. Figuren viser, at en kube dækker både 48(4*3*4) og 25

125(5*5*5) mulige kombinationer af dimensionerne.

109 Thomsen(2002) s. 94 110 Thomsen(2002) s. 49 111 Thomsen(2002) s. 34-35 112 Pedersen & Jensen(2001) s. 40


Side 61 af 90

Figur 23: OLAP-kuber

Kilde: Egen tilvirkning på baggrund af Taleb(2007)

Den største fordel ved at anvende kuben er, at virksomheden får mulighed for at benytte drill-down og roll-

up samt slice and dice. Drill-down og roll-up betyder, at aggregerede niveauer kan deles ud i underliggende 5

niveauer ned til det mest granulære niveau i dimensionerne.113 Dette kan for eksempel være en virksom-

hed, der ønsker at se kundeprofitabiliteten på dækningsbidragsniveau helt nede på transaktionsniveau. Her

vil det øverste niveau i kubens hierarki være, hvor alle celler er lagt sammen og dermed vise den samlede

kundeprofitabilitet for alle kunder. Herefter kan kundeprofitabiliteten for den enkelte kunde ses ved efter-

følgende drill-down, og der kan foretages yderligere drill-down helt ned på transaktionsniveau. Når kubens 10

celler så efterfølgende aggregeres igen anvendes der roll-up, og disse to begreber er således sammenhæn-

gende, men anvendes modsatrettet i kuben.114 Slice and dice minder meget om drill-down og roll-up, da dis-

se forespørgsler også er med til at udvælge de mest væsentlige steder i kuben for brugeren. Men hvor den

førnævnte forespørgsel var med til at åbne og lukke kuben, reducerer slice én eller flere af dimensionerne i

kuben til kun at have én værdi, og dice skærer nogle af dimensionerne helt væk. Den reducerede kube bliver 15

derfor meget mindre end den oprindelige kube og de efterspurgte resultater kan langt hurtigere findes

frem, og fokus kan lægges på disse.115

15.3 Kubeopbygning og hierarkier

Når kubebegrebet er belyst er det relevant at behandle hierarkierne nærmere, idet disse er væsentlige i

forhold til beregningsmulighederne i de enkelte kuber. Herudover bliver hierarkierne i kuberne afgørende 20

for de afrapporteringsmuligheder slutbrugeren får. Gruppens forståelse af hierarkibegrebet bygger på ne-

denstående figur, hvor de forskellige typer af hierarkier er inddraget.

113 Taleb(2007) s. 10 114 Pedersen & Jensen(2001) s. 43 115 Taleb(2007) s. 10


Side 62 af 90

Figur 24: Forståelse af hierarkier


Figuren viser, at hierarkier kan deles op i naturlige og problemafledte hierarkier, som kan være enten re-

kursive, levelbaserede, symmetriske eller asymmetriske. Hierarkier kan derfor besidde forskellige karakte-5

ristika, hvilket får indflydelse på udarbejdningen af kuberne. Der er således en række problemstillinger ved-

rørende hierarkierne, som der bør tages højde for i opbygningen af kuber. Kubeopbygningen er således af-

hængig af en hierarkisk struktur til den databearbejdning, som slutbrugeren foretager i forhold til hen-

holdsvis slice and dice, roll-up og drill-down. Malinowski og Zimányi(2004) definerer overordnet et hierarki

på følgende vis: 116 10

“A hierarchy is a set of binary relationships between dimension levels.”

I ovenstående citat er der altså tale om et hierarki, der består af relationer mellem dimensionsniveauerne,

og der er derved tale om, at der er hierarkier på dimensionerne.117 Dimension levels er af gruppen forstået

som det niveau, hvor et sæt af members118 deler en mængde af attributter.119 En dimension i hierarkiet

danner således gruppe af noget, der kan anses som en beslutningsenhed.120 I nedenstående figur, der be-15

116 Malinowski & Zimányi(2004) s. 3 117 Thomsen(2002) s. 80 118 Members forståes af gruppen som attributbeskrivelse 119 Colossi et al.(2002) s. 715 120 Thomsen(2002) s. 108


Side 63 af 90

står af fire dimensionsniveauer, er et dimensionsniveau eksempelvis by, delt ud på fire instances:121 by 1, by

2, by 3 og by 4.

Figur 25: Eksempel på hierarki

Kilde: Egen tilvirkning på baggrund af Malinowski og Zimányi (2004) s. 5 5

Et andet begreb indenfor den hierarkilitteraturen er hierarchycal path, som beskriver stien fra det øverste

dimensionsniveau til det nederste dimensionsniveau. Der kan ligeledes tales om en path length, som i

ovenstående figur kan være fra ”Butik 4” til ”Land A”, hvilket er fire dimension levels. Det øverste dimensi-

onsniveau kaldes i øvrigt root, mens det nederste dimensionsniveau kaldes leaf.122 Der opstår således et

parent-child-relation imellem de enkelte niveauer, hvor det er kendetegnende, at root i øverste led i hierar-10

kiet ikke har nogen parent, da dette er det mindst granulære niveau, og leafs ikke har nogen childs af sam-

me grund.123 Et hierarki vil normalt have en root, men kan sagtens have mange leafs, som tilfældet er i

ovenstående figur. I den følgende figur vil, der fremvises en normaliseret tabelstruktur med en geografisk

hierarkistruktur, hvor begreberne leaf, member og root illustreres.124

Figur 26: Normaliseret tabelstruktur 15

Kilde: Egen tilvirkning på baggrund af Malinowski og Zimányi(2004) s. 3

121 Instance er af gruppen omfattet som attributværdi i dimensionen ved henledning til Thomsen(2001) s. 73 122 Thomsen(2002) s. 112 123 Thomsen(2002) s. 109 124 Malinowski & Zimányi(2004) s. 3

Leaf

Root

member


Side 64 af 90

15.3.1 Hierarkityper

Hierarkier kan, som vist i figur 24, enten være naturlige eller problemafledte,125 og et naturligt hierarki de-

fineres som:

”et hierarki bestående af entiteter og eller attributter, som er logisk set er

over/underordnet eller sideordnet med hinanden.”126 5

Det kan udledes af ovenstående citat, at naturlige hierarkier er hierarkier, der ikke kan stilles spørgsmåls-

tegn ved. Tid kan være et naturligt hierarki, da eksempelvis år altid vil have kvartaler under sig, og kvartaler

vil altid have måneder under sig. Nogle tidsdimensioner vil dog være problemafledte i og med uger inddra-

ges, da ugerne på et år varierer. Problemafledte hierarkier er i kontrast til naturlige hierarkier, og alle hie-

rarkier, der ikke er naturlige, må således være problemafledte hierarkier. Der findes således langt flere pro-10

blemafledte hierarkier end naturlige hierarkier, og de problemafledte hierarkier kan ofte være mere inte-

ressante at arbejde med, da de løser en specifik problemstilling. Hvor naturlige hierarkier er almene, er

problemafledte hierarkier derfor specifikke, hvilket ses ud fra nedenstående citat.

”Et problemafledt hierarki er ikke alment gældende for alle typer af analy-

ser… … det er således kun gyldigt til brug for den analyse hvortil den er de-15 signet.”

127

Naturlige og problemafledte hierarkier kan endvidere opdeles i tre hierarkityper. Rekursive hierarkier er så-

ledes hierarkier, hvor der eksisterer en parent-child relation mellem niveauerne i hierarkiet. Det nederste

hierarki refererer således til et overliggende niveau i hierarkiet, hvor flere underliggende niveauer aggrege-

res. Herudover kan der også være registreringer på et parent-niveau, hvorfor aggregeringen ikke bliver 20

overensstemmende med de underliggende niveauer. På studiet er der tidligere benyttet rekursive hierarki-

er i forbindelse med Vagn Madsens variabilitetsprincip for at undgå arbitrære registreringer af omkostnin-

ger. Rekursive hierarkier kan enten være strict eller non-strict.128 Et strict rekursivt hierarki betyder, at der

kun eksisterer ”1-til-mange”-relationer i hierarkiet. Det vil sige, at hvert child kun har en parent. Non-strict

rekursive hierarkier benytter derimod ”mange-til-mange”-relationer, hvor hver child kan have flere parents. 25

Dette kan i flere situationer være hensigtsmæssigt, men det åbner muligheden for redundans, hvilket er ek-

semplificeret i nedenstående figur:

125 Wiese(2005) s. 402 126 Wiese(2005) s. 402 127 Wiese(2005) s. 403 128 Pedersen et al.(2001) s. 386


Side 65 af 90

Figur 27: Rekursivt hierarki med ”mange-til-mange”-relation


I figuren indgår ”FP Brugsbutik” både i kundegruppen ”detailsalg” og ”engrossalg”, hvilket giver et problem,

når der aggregeres til højeste niveau – ”alle kunder”. Problemstillingen er, at en aggregering af ”detailsalg” 5

og ”engrossalg” vil betyde, at ”FP Brugsbutik” bliver medtaget to gange. Der skal således laves en regnere-

gel, der løser dette problem i OLAP-værktøjet.

I levelbaserede hierarkier kan der i forhold til rekursive hierarkier ikke registreres data på de mellemliggen-

de niveauer. Et levelbaseret hierarki er således kendetegnet ved, at alle dataene ligger på det mest granu-

lære niveau, og de overliggende niveauer er udelukkende aggregeringer af disse data. Et sådant hierarki er 10

også rekursivt, og der kan således sagtens eksistere et rekursivt levelbaseret hierarki. Problemstillingen ved

aggregeringen af niveauer med mange-til-mange relationer kan også forekomme. Herudover er det et pro-

blem, at der må foretages arbitrære fordelinger af eksempelvis omkostninger på mellemliggende niveauer,

der er fælles for flere records på nederste niveau. Alternativt skal der oprettes en record på nederste ni-

veau, hvor fællesregistreringerne kan lagres. Dette er dog uhensigtsmæssigt, da nogle analyser på nederste 15

niveau vil give ukorrekte resultater.

Udover at enten være rekursivt, levelbaseret eller begge dele vil et hierarki også altid være enten symme-

trisk eller asymmetrisk. Denne skilning beror på om, der eksisterer en balanceret hierarchial path, hvilket er

et symmetrisk hierarki. Malinowski og Zimányi(2004) arbejder med flere definitioner af hierarkier i hen-

holdsvis symmetriske og asymmetriske strukturer.129 Thomsen(2001) anvender synonymer for begge be-20

greber og benytter i denne sammenhæng level og ragged hierarkier.130, 131 Nedenfor anvises forskellen

imellem de symmetriske og asymmetriske hierarkiers individuelle opbygning ud fra Malinowski og Zima-

129 Malinowski & Zimányi(2004) s. 4 130 Thomsen(2002) s. 111 131 En semantisk vurdering af begrebernes gyldighedsområde er særdeles relevant, da flere forfattere anvender for-skellige begreber for beskrivelser af hierarkier. Her kan henledes til Malinowski & Zimányi(2004) s. 4


Side 66 af 90

nyi(2004). Eksemplerne på symmetriske hierarkier kan være tid. Eksempler på asymmetriske hierarkier kan

være en organisationsstruktur og er eksemplificeret i nedenstående. 132

Figur 28: Eksempel på asymmetrisk hierarki

Kilde: Egen tilvirkning 5

Hierarkiet er asymmetrisk, idet længden fra root til leaf ikke er ens i begge grene. Der eksisterer et niveau

mere under Salg Danmark, hvilket skaber en ubalance. Pedersen et al.(2001) omtaler dette som not onto133

eller ikke balanceret. I tilfældet af, at leafs havde været på samme dimensionsniveau, men antallet af ni-

veauer havde været forskelligt, ville der også være tale om et asymmetrisk hierarki. Der ville således være

et mellemliggende niveau mindre i en af grenene, hvilket kaldes et non-covering hierarki.134 10

På baggrund af de forskellige muligheder, der er indenfor opbygning af hierarkistrukturer kan kuberne så-

ledes udformes på forskellige måder. I nedenstående figur illustreres hierarkistrukturen i en kube med

mange hierarkier.

132 Malinowski & Zimányi(2004) s. 3 133 Pedersen et al.(2001) s. 386 134 Pedersen et al.(2001) s. 387


Side 67 af 90

Figur 29: Eksempel på kube


I opbygningen af kuberne skal der således udfærdiges dimensioner og measures for den aktuelle kube,

hvorefter der er muligheder for at slice and dice og drill-down/roll-up i kuben. Der opbygges således nye 5

dimensioner i OLAP-serverområdet, hvori hierarkier indgår. Eksempelvis kan en tidsdimension have forskel-

lige hierarkier, som kan påvirke de analysemuligheder, der opnås i de senere opbyggede kuber til afrappor-

tering. I nedenstående figur er der således angivet hierarkier i en tidsdimension, der har relationer til en

specifik facttabel i en data mart.

Byer

Trondheim Bergen

Oslo

Kontinenter

Produktgruppe

År

Lande

1400

1400

1400

1400

1400 1400

100

1400

300

1110 1500 800

1400

1410 700 400

1400 1200

1400 1400

1400 1400

1400 900 Produkt Støvler

Træsko

Sandaler

Jan. Feb. Mar. Apr.

Kvartal


Side 68 af 90

Figur 30: Hierarkier i data warehouset

Kilde: Egen tilvirkning efter inspiration af Chaudhuri & Dayal(2003) s. 5

I ovenstående figur er der således belyst to former for hierarkier, hvor der øverste er et snowflakeskema

indeholdende to eksplicite hierarkier. Af figuren ses det, at tidsdimensionen også kan opbygges i en 5

dimension, hvor de samme hierarkier er mulige at lave efterfølgende i selve kuben, men de fremgår ikke

direkte fra skemaet.135 I den sidstnævnte figur kan der derfor ikke direkte ses, at uger ikke er child til

måneder, hvilket skyldes, at dette er et problemafledt hierarki, hvorimod år à kvartal à måned kan siges

at være et naturligt hierarki. Det skal også pointeres, at dimensionerne, der opbygges i kuberne, er

afhængige af de attributter, der er blevet medtaget i data stagging-området for de enkelte dimensioner fra 10

data marten, da det ikke vil være muligt at oprette hierarkier på ikke-eksisterende data i data marterne.

Der er endvidere muligheder for at lave flere hierarkier i kuberne udfra samme grunddimensioner i data

martene. Om den konkrete dimension i data marten er snowflake-struktur(normaliseret) eller i

stjernetabel-struktur, må være et spørgsmål om performancehastigehed for data warehouset,136 og ikke et

spørgsmål om hvilke hierakier der mulige at oprette efterfølgende i kuben. 15

135 Chaudhuri & Dayal(2003) s. 5 136 Kimball(1998) s. 172


Side 69 af 90

15.4 Opbygning af dimensioner i kuberne

Der er nu beskrevet, at der kan være tale om flere mulige hierarkier, som kan opbygges til de enkelte ku-

ber, der er fundamentale for analysemulighederne. Til opbygning af hierarkier kan der således være flere

kombinationsmuligheder, hvor nedenstående er nogle er de muligheder som skabes fra leaf-niveau til root-

niveau i et pågældende problemafledt hierarki. 5

Figur 31: Eksempler på problemafledte hierarkier


I ovenstående figur illustreres det således, at der arbejdes med flere problemafledte hierarkier. Der kan så-

ledes nævnes, at anvendelsen af hierarkier skaber fundamentet for de samlinger af grupper(dimensioner), 10

som virksomheder ønsker at tage beslutninger om.137 Ses der på det første problemafledte hierarki, til ven-

stre i figur 31, kan summering foretages i en samlet dimension i OLAP værktøjet, hvor et join i transforma-

tionen fra præsentationsområdet til OLAP-serverområdet danner mulighed for at aggregere på salgsområ-

deniveau. Alternativt kan summeringsmulighederne opnås ved at medtage en kundedimension og en geo-

grafisk dimension i OLAP-serverområdet, altså to dimensioner i kuben. 15

Det andet hierarki i figur 31 illustrerer, at kunder kan aggregeres på et bestemt kundetypeniveau. Kundety-

pen kan for slutbrugeren være forskellig, hvorfor der må være tale om et problemafledt hierarki i rapporte-

ringen. Ved eksempelvis unge mennesker, midaldrende og ældre mennesker kunne en relevant analyse væ-

re at bedømme, hvor mange nye kunder der tilgik i sidste måned for segmentet unge mennesker. En sådan

analyse kan have strategisk karakter, som KPI, i en bankvirksomhed. Alternativt kunne en anden slutbruger 20

ønske at se kundetilgangen fra hver kommune i sidste periode. Er kommune ikke et niveau i en geografisk-

dimension, skal der dannes et nyt problemafledt hierarki, hvor niveauet er kunde-kundeområde - alle kun-

137 Thomsen(2002) s. 108


Side 70 af 90

der. Problematikken omkring de sidste to problemafledte hierarkier i figur 31 vil blive belyst senere i kapitel

16, hvor praktiske problemstillinger fra applikationsværktøjet PALO vil blive inddraget.

15.5 PALO

PALO er et tilføjelsesprogram til Microsoft Excel, der anvendes til at præsentere multidimensionel data. Da

det er et Excel-værktøj, foregår beregningerne på baggrund af data i de enkelte celler. Værdierne i dimen-5

sionerne kan opstilles i kolonner eller rækker, men hvor der i Excel kun kan vises to dimensioner, kan PALO

indeholde op til 256 dimensioner.138 Disse dimensioner administreres i kuber, der er opbygget efter hierar-

kiske principper. I og med, at PALO er ”memory-baseret”, og at der ikke nogle tidskrævende forespørgsler

kan resultaterne fremvises i løbet af kort tid.139 Andre multidimensionale databaser er langsommere end

PALO, men har så til gengæld en større kapacitet. 10

138 Raue et al.(2008) s. 44 139 Raue et al.(2008) s. 50


Side 71 af 90

16. Fra teoretisk problem til praktisk problem i PALO

Den tidligere bearbejdning af hierarkibegrebet har kun været af rent teoretisk karakter, og i dette afsnit vil

denne bearbejdning blive eksemplificeret i OLAP-værktøjet PALO. Der vil således blive gennemgået eksem-

pler med tidsdimensionen og kontoplansdimensionen, hvor problematikker ved de to hierarkier vil blive

diskuteret. Tidsdimensionen er et naturligt hierarki, og kontoplansdimensionen er et problemafledt hierar-5

ki, hvorfor begge typer af hierarkier vil blive behandlet. Der vil også blive inddraget eksempler på asymme-

triske hierarkier, og hvordan sådanne hierarkier nødvendigvis må behandles i PALO. Herudover vil rekursive

levelbaserede hierarkier blive berørt.

Kontoplansdimensionen bliver kaldt ”Økonomi” i PALO, da regnskabstallene fremkommer gennem regne-

regler i PALOs rule editor. Rule editoren kan benyttes til at opstille regneregler gældende for de enkelte 10

elementer i dimensionen. ”Dækningsbidrag” kan således opstilles som ”Omsætning” – ”Variable omkost-

ninger”. Dette kræver dog, at ”Dækningsbidrag” er oprettet som element indenfor økonomidimensionen.

Der bliver således oprettet en resultatopgørelse og en balance i PALO ved at benytte økonomidimensionen.

Dimensionen kan ses af nedenstående screen shot fra PALO.

Figur 32: Økonomidimension i PALO 15

Det kan ses af figuren, at der eksisterer tre overordnede niveauer i dimensionen, som er ”Årets resultat”,

”Aktiver” og ”Passiver”. Næste niveau eksisterer gennem en opbygget struktur i to Excel-regneark, hvor alle

konti fra kildesystemet er blevet kædet sammen med et overordnet aggregeringsniveau. ”Aktiver” er såle-

des delt op i ”Omsætningsaktiver” og ”Anlægsaktiver”, ”Passiver” er delt op i ”Kortfristet gæld”, ”Langfri-20

stet gæld” og ”Egenkapital”, og ”Årets resultat” er opstillet i bidragsform, hvor de enkelte deltotaler er op-

stillet gennem regneregler. Økonomidimensionen i PALO kan derfor benyttes til at opstille regnskab efter.

Rent teknisk sker hierarkiopbygningen som sagt gennem strukturerne fra Excel-regnearkene. Excel-

regnearkene er derefter overført til Oracles databaser, hvorefter de benyttes i transformationsprocessen

fra DWH til PALO. Denne transformation kan ses i nedenstående figur: 25


Side 72 af 90

Figur 33: Transformation for økonomidimension til PALO

Det første, der sker i transformationen, er, at kontoplansdimensionen hentes fra DWH. Samtidig hentes

”TP_Kontoplan” og ”TP_Resultatopg” også fra Oracles database. Disse to tabeller er opbygget på følgende

måde: 5

Figur 34: Regnskabstabeller

Der eksisterer et parent-child forhold mellem tabellerne, og ”TP_Resultatopg” er således parent til

”TP_Kontoplan”. Efter tabellerne er hentet fra Oracles database, bliver de relevante attributter valgt ud, og

der sorteres over attributter, som der skal joines over. Herefter joines der over kontonummer mellem 10

”TP_Kontoplan” og Kontoplansdimensionen, og over ”PK_Resopg” og ”FK_Resopg” mellem ”TP_Kontoplan”

og ”TP_Resultatopg”. Herved kan alle attributterne fra de tre tabeller samles i et output ved at joine over

kontonummer bagefter. Der tilføjes herefter en konstant således, at hver record kan aggregeres op på hø-

jeste niveau, som i dette tilfælde er ”Årets resultat”. Dimensionen er nu færdig, og hierarkierne til resultat-

opgørelsen og balancen består af tre niveauer. Disse to hierarkier er begge levelbaserede, hvilket skyldes, 15

at alle dataene i kildesystemet, SBO, ligger på nederste niveau. SBO’s opbygning er dog ikke et levelbaseret

hierarki, da der ikke er nogen referentiel integritet mellem niveauerne, men aggregeringen sker gennem

regneregler i SBO. Derfor er det valgt at sikre den referentielle integritet gennem ovenstående tabeller for

at sikre datakvaliteten. Økonomidimensionen er endvidere et problemafledt hierarki, da hierarkiet er speci-

fikt på regnskabsproblematikker for ØKO IS. Der kan heller ikke argumenteres for, at der er tale om et na-20

turligt hierarki, da niveauerne i et sådant hierarki må afhænge af virksomhedens regnskabspraksis.


Side 73 af 90

For at der kan laves en kube, hvor økonomidimensionen indgår, vil det være nødvendigt med en tidsdimen-

sion, fordi dataene, der rapporteres på, skal afgrænses for, at kubens celler skal give retvisende resultater.

Tidsdimensionen er den mest grundlæggende dimensionen i et DWH, da alle data skal kædes op på tid, så

forskydninger i dataene kan ses over tid. Uden tidsdimensionen vil det således ikke være muligt at se, hvor

mange kursusdage en medarbejder har haft i indeværende år, men det vil derimod kun være muligt at se, 5

hvor mange kursusdage medarbejderen har haft gennem hele sin ansættelsesperiode. Tidsdimensionen i

PALO er opbygget i et Excel-regneark med seks niveauer bestående af ”Alle år”, ”År”, ”Halvår”, ”Kvartaler”,

”Måneder” og ”Dato”. I PALO overføres kun de fem niveauer, da datoattributten ikke bruges i afrapporte-

ringen, da denne er af strategisk karakter. Tidsdimensionen overføres gennem følgende transformationen

fra DWH, som tidsdimensionen tidligere er blevet overført til. 10

Figur 35: Transformation for Tidsdimension til PALO

På samme måde som med økonomidimensionen tilføjes der en konstant for alle år således, at dette bliver

det øverste niveau. Herudover skal der ikke hentes data fra andre tabeller, da hele tidsdimensionen ligger i

den samme tabel. Tidsdimensionen kan ses af nedenstående figur, hvor de fem hierarkiniveauer kan ses. 15

Figur 36: Tidsdimensionen i PALO


Side 74 af 90

Tidsdimensionen er et naturligt hierarki, da den opbyggede struktur kan siges at være alment gældende.

Der er således ikke inddraget attributter i tidsdimensionen, som kunne have været specifikke for ØKO IS.

Dette kunne eksempelvis have været en sæsonattribut for at skelne mellem højsæson og lavsæson for is.

Med en sådan attribut ville tidsdimensionen have været problemafledt. Herudover er tidsdimensionen re-

kursiv, da registreringer vedrørende den enkelte måned, det enkelte halvår eller det enkelte år kan foreta-5

ges. Problemet opstår ved overførslen til PALO, da dette program kun opererer med levelbaserede hierar-

kier. Alle registreringer skal således foreligge på det nederste niveau i hierarkiet, hvorfor registreringer for

eksempelvis halvår eller år skal sammenkædes med en måned. Dette er dog uheldigt, da det bliver umuligt

at sammenligne én måneds registreringer med én anden måneds registreringer, hvad enten det er i det

samme år eller ej. For at løse problemet må der oprettes en pseudo-post på nederste niveau for, at regi-10

streringer på overliggende niveauer ikke umuliggør sammenligninger på de mest granulære niveauer. Hie-

rarkiet bliver i dette tilfælde problemafledt, da dette ikke er naturligt. Rent praktisk er denne problemstil-

ling dog ikke bearbejdet, da alle kildedataene stammer fra SBO og derfor er sammenkædet med en enkelt

dato. Dette giver dog en række periodiseringsproblemstillinger.

Efter at de to dimensioner er oprettet i PALO, skal der oprettes en måltalsdimension for, at der efterfølgen-15

de kan oprettes kuber. I måltalsdimensionen medtages de facts, som der ønskes rapporteringer på. Dette

kunne eksempelvis være beløb til resultatopgørelsen og balanceposterne. Det kunne også være en mæng-

depost for at se, hvor hvordan omsætningen fordelte sig på forskellige produkter. Der er således tale om, at

måltalsdimensionen i PALO skal loades med facts fra DWH’et. Kuben for det finansielle perspektiv kommer

til at indeholde de dimensioner, hvor der er en relation til facttabellen for det finansielle perspektiv. Det vil 20

sige, at data marterne fra modul 1 kan anvendes til at strukturere kubeopbygningen i PALO. I nedenstående

screen shot kan kuben for det finansielle perspektiv ses. Denne kube er døbt ”Regnskab”, da den kan rap-

portere på flere regnskabstal.


Side 75 af 90

Figur 37: Eksempel på kube

Til det finansielle perspektiv skal facts hertil selvfølgelig benyttes. Det vil sige, at facttabellen for det finan-

sielle perspektiv skal benyttes. De finansielle måltal i ovenstående figur svarer således overens med facts

fra facttabellen. Måden, hvorpå facts overføres på, kan ses af nedenstående transformation, hvor dimensi-5

onsværdierne ligeledes kædes på for, at registreringerne kan fordeles ud på kubens enkelte celler.

Figur 38: Transformation af måltal til PALO

Af figur 38 ses det, at facts til det finansielle perspektiv udtrækkes, hvorefter der gennem to Database loo-

kup kædes attributter på fra både kontoplansdimensionen og tidsdimensionen. Dette svarer til Merge join 10

funktionen fra tidligere. Herved inddrages fremmednøglerne til dimensionerne i PALO, hvorfor der skal væ-

re overensstemmelse mellem de enkelte dimensionsværdier og værdierne i kuben. Group by-funktionen

grupperer dataene efter dimensionerne således, at aggregeringerne allerede er fundet sted på de overlig-

gende niveauer. I Group by-funktionen er der således grupperet over måned og konto, idet måned og konto

er de mest granulære niveauer i dimensionerne tid og økonomi. Det rekursive hierarki skaber dermed mu-15

ligheden for drill-down og roll-up i den pågældende kube på dimensionerne tid og økonomi. Palo Cells Out-

put henter kubens bestanddele fra PALO, som efterfølgende skal sammenkædes med værdier fra transfor-

mationen. Det bliver derfor nødvendigt, at dataene i transformationen stemmer overens med dimensions-


Side 76 af 90

værdierne i PALO. PALO accepterer således ikke, at data kan eksistere på mellemliggende niveauer, hvorfor

PALO udelukkende understøtter levelbaserede hierarkier.

Funktionaliteten i kuben, ”Regnskab”, er således betinget af den struktur, der er opbygget i transforma-

tionsprocessen. Det vil sige, at det ikke er muligt efterfølgende at drill-down på dagsniveau, da kuben er ag-

gregeret på månedsniveau. For at kunne dette, skal hele hierarkiet i tidsdimensionen bygges om således, at 5

det understøtter denne funktionalitet. I relation til økonomidimensionen understøtter denne dimension

kun et hierarki efter bidragsmetoden. Denne struktur skal således også bygges om, hvis en anden hierarki-

struktur ønskes benyttet.

Opbygningen af hierarkier kan således blive mange i PALO, da den enkelte dimension i programmet kun

understøtter ét hierarki. Eksempelvis må medarbejderdimensionen opdeles i to dimensioner for både at 10

kunne rapportere på medarbejderstillinger og medarbejderkøn. Økonomidimensionen kunne også opdeles

i flere hierarkier, hvis flere modeller eksempelvis bliver benyttet på samme tid. I tilfældet af, at der skulle

opbygges et hierarki over sæsoner på tidsdimensionen, ville det også være nødvendigt at dele denne di-

mension ud i to dimensioner.

16.1 Afrapportering i PALO 15

Der er nu beskrevet, hvordan en kube opbygges rent praktisk ved hjælp af PALO. I det følgende vil afrap-

porteringen blive vist, og det vil fremgå, hvordan drill-down, roll-up og slice and dice foregår i PALO. Afrap-

porteringen kan således formes lige efter brugerens ønsker, hvis alle dimensioner eksisterer i opbygningen

af kuben. Talebs(2007) krav om tilgængelighed og ubegrænsede dimensioner kræver således et væsentlig

arbejde fra udviklernes side, før slutbrugeren kan siges at have de muligheder, som er opstillet for et OLAP-20

værktøj. Det betyder derfor, at alle dimensionerne skal opbygges, og loades ind i kuben, hvilket stiller store

krav til udviklerens overblik, da der, som allerede nævnt, kun kan laves et hierarki i hver dimension.

I nedenstående figur er resultatopgørelsen og balancen eksemplificeret, hvor de forskellige niveauer kan

ses. Alle overskrifterne med fed kan således føres ned til de enkelte konti, der påvirker det overliggende ni-

veau. Der kan således drill-down på kontoplansdimensionen. 25


Side 77 af 90

Figur 39: Resultatopgørelse og balance i PALO

I tilfælde af, at der ønskes en anden periodes regnskabstal skal der laves et slice i kuben, hvilket betyder, at

alt andet end denne periode fravælges. Dette sker ved at ændre alle år til en given periode, hvilket sker ved 5

at trykke på alle år i Excel-regnearket. Herefter kommer der et nyt vindue frem med tidsdimensionen, hvor

perioden kan vælges.

I relation til ØKO IS’ balanced scorecard model skulle der afrapporteres på tre finansielle nøgletal. Hertil

blev den balancerede vækst inddraget, hvorfor der også rapporteres på ROI, da dette kan bruges som til-

nærmet RONA. Disse nøgletal er ligeledes oprettet i økonomidimensionen, hvorfor der ved brug af rule edi-10

toren er oprettet regneregler. Dette ses af nedenstående figur.

Figur 40: Finansielt perspektiv i PALO


Side 78 af 90

Det finansielle perspektivs nøgletal fremkommer på denne måde gennem en række regneregler i PALO,

hvorfor brugeren nødvendigvis må have et indgående kendskab til, hvorledes programmet fungerer. Op-

bygningen af PALOs dimensioner kræver også, at udvikleren på udviklingstidspunktet overfører alle tænke-

lige hierarkier til PALO således, at brugerne ikke kommer i en situation, hvor en ad hoc analyse ikke kan lø-

ses, da dimensionerne ikke er opsat korrekt. Dette stiller eksempelvis store krav til udviklingen af kundedi-5

mensionen, da kundehierarkiet vil være afhængigt af, hvordan kundesegmenter eksempelvis opdeles. Kun-

degrupper fordelt på omsætning nødvendiggør opbygningen af en dimension i PALO, hvor kundegrupper

opdelt på geografisk placering nødvendiggør opbygningen af en anden dimension i PALO. Dette gør, at di-

mensionsstrukturen i PALO bliver uoverskuelig, da der ved mange forskellige afrapporteringer skal opbyg-

ges dimensionshierarkier, der understøtter alle. Salgsafdelingen ønsker måske analyser på kunder fordelt 10

på omsætning, hvor markedsføringsafdelingen i stedet skal benytte kunder fordelt på geografi. I nedenstå-

ende figur er vist et eksempel på to problemafledte hierarkier indenfor samme dimension.

Figur 41: Eksempel på flere hierarkier indenfor samme dimension

ØKO IS’ afrapportering indenfor vækst- og læringsperspektivet nødvendiggør to hierarkier på medarbejder-15

dimensionen, da der både ønskes analyser på titler og køn. Det kunne eksempelvis være medarbejdertil-

fredsheden, der ønskes undersøgt på både titel og køn. I dette tilfælde skal begge dimensionshierarkier

inddrages i kuben, og der må så slices i kuben bagefter for at benytte dimensionerne.

ØKO IS kan nu regne deres maksimale selvfinansierede vækst ud, hvis de opstiller mål for de resterende

elementer i ligningen for balanceret vækst. Eksempelvis kan det ønskes, at egenkapitalen skal udgøre 40 % 20

af finansieringen og de resterende 60 % skal være gæld. Herudover kan det være et mål, der udloddes 8 %


Side 79 af 90

af årets resultat til aktionærerne, hvorfor der vil være en tilbageholdelsesrate på 92 %. Nu skal renten på

gælden efter skat udregnes for at ligningen kan benyttes. I dette tilfælde sættes denne rente til 6 %.

5

Under forudsætning af disse tal vil den maksimale selvfinansierede vækst således være 0,4002 eller 40 %.

Da flere af forudsætningerne er mål fra ledelsens side, vil der dog ofte forekomme ændringer i ligningen,

hvis en eller flere forudsætninger ikke holder.

10


Side 80 af 90

17. Afrunding modul 2

Der er i dette projekt arbejdet både med økonomistyring og informatikmæssig teori. Økonomistyringsteori-

en er behandlet med økonomistyringsmodellen, balanced scorecard, hvor der efterfølgende er oprettet en

data warehouse-løsning efter en Kimball-tankegang. På baggrund af det opbyggede data warehouse er det

senere teoretisk blevet belyst, hvorledes der kan rapporters på nogle af de nøgletal, som var indeholdt i ca-5

sen ØKO IS. Der er i projektet arbejdet med registreringsgrundlag, hvor datakilden SBO har været af mest

anvendte datakilde, og gruppen har udarbejdet metadata til data warehouset, hvori der er specificeret,

hvorfra data er hentet til de forskellige dimensioner og facttabeller, samt hvordan dataene skal lagres i data

warehouset.

I modul 2 er der endvidere blevet medtaget en anden erhvervsøkonomisk model i form af Donaldsons tan-10

ker om balanceret vækststrategi. Balanceret vækst er med i modul 2, da Donaldsons teori ses som kom-

plementær til de målsætninger, som sættes i ØKO IS´ BSC-koncept, da elementerne i det finansielle per-

spektiv i BSC-konceptet kan sammenholdes i forhold til en selvfinansieret vækststrategi. Den balancerede

vækststrategi kan derfor inddrages både som komplementær model til de opstillede mål i BSC og/eller som

kontrollerende model af målene i BSC’s finansielle perspektiv. Ligningen for balanceret vækst er således 15

blevet benyttet som komplementær model, hvor den maksimale selvfinansierende vækst er blevet fastlagt

for ØKO IS.

Den multidimensionale rapportering er anskueliggjort med reference til hierarkibegrebets betydning i den

multidimensionale opbygning. Teoretiske problemstillinger om hierarkier er således blevet behandlet,

hvorefter de er forsøgt løst i praksis i OLAP-værktøjet PALO. 20


Side 81 af 90

18. Litteratur

Bøger:

Arbnor & Bjerke (1997). Methodology for Creating Business Knowledge. Sage publications.

Bukh, Per Nikolaj et al. (2004). Strategikort- Balanced scorecard som strategiværktøj – danske erfaringer. 1. 5 udgave, 2. oplag. Børsens forlag.

Christensen, Jens (2004). Vidensgrundlag for handlen. Aalborg Universitetsforlag.

Dahllöf, Mats (1999). Språklig betydelse: en introduuktion till semantik och pragmatik. Studenterlitteratur.

Hartnack, Justus(1996). Logik: Klassisk og moderne. C.A. Reitzel.

Kaplan, Robert S. & Atkinson, Anthony (1998). Advanced Management Accounting. 3. udgave, Prentice 10 Hall.

Kaplan, Robert S. & Atkinson, Anthony (2004). Management accounting. 4. udgave. Prentice Hall.

Kaplan, Robert. S. & Norton, David (2004). Balanced Scorecard. Sådan bygges bro mellem vision, værdier og strategier. 4. udgave. Børsens Forlag.

Kimball, Ralph (1998). The Data Warehouse Lifecycle Toolkit. 15

Kimball, Ralph (2002). The Data Warehouse Toolkit.

Kotter, John P. (1999). I spidsen for forandringer (1.udgave, 4.oplag) Peter Assenhenfeldts nye Forlag a/s

Thomsen, Erik(2002). OLAP Solutions, John Wiley & Sons Inc., 2. udgave,.

Törnebohm, Håkan (1974). Paradigm i Vetenskapernas Värld och i Vetenskapsteorin.

20

Artikler:

Bukh, Per Nikolaj & Bang, Heine (2004). Balanced Scorecard og Strategikortlægning. Børsens ledelses-håndbog.

Bernberg, Frank (2003). Controlling the Data Warehouse a Balanced Scorecard approach. Institute for Business Informatics, University of Muenster Leonardo-Campus 3, 0-48149 Muenster, Germany. 25

Davenport, Thomas (2006). Competing on Analytric. Havard Businees revirew.

Chaudhuri, Surajit & Dayal, Umeshwar (2003). An Overview of Data Warehousing and OLAP Technology.

Codd, E.F. et al.(1993). Providing OLAP to User-Analysts: An IT Mandate, White Paper, Arbor Software Cor-poration, 1993.


Side 82 af 90

Colossi, N., W. Malloy & B. Reinwald(2002). Relational extensions for OLAP, IBM Systems Journals, Vol. 41, No. 4

Cross, Kelvin F. & Lynch, Richard L. & McNair, Carol J. (1990). Do Financial and Nonfinancial performance Measure have to Agree. Management Accounting; November; 72,5:

Donaldson, G.(1985). »Financial Goals and Strategic Consequences«. Harvard Business Review, May-June, 5 57-66

Eisenberg & Melton(2000). SQL Standardization: The Next Steps, SIGMOD Record, Vol 29, No. 1, Marts

Hansen, Kirsten Lei & Andersen, Dorthe(2000). Data varehuset skal levere værdi. Børsen, 11. juni 2000.

Imhoff, Claudia(1999). The Corporate Informantion Factory. Information management Magazine, Decem-ber vol. 1. 10

Inmon, William H. (1999). Data Marts Does not Equal Data Warehouse. Infomanagement Direct, November 20.

Inmon, William H. (2000). Loading Data into the Warehouse. Pensum fra tidligere økonomistyringshjem-meside.

Inmon, William H. (2000). What is a datawarehouse. Pensum fra tidligere økonomistyringshjemmeside. 15

Kaplan, Robert S. & Norton, David (2000). Having trouble with your Strategy - Then map it. Harvard Busi-ness Review. September/October.

Kaplan, Robert S. & Norton, David (2001). Transforming the Balanced Scorecard from Performance Meas-urement to Strategic Management: Part I, Accounting Horizons, Vol 15, No. 1, March, 2001.

Kaplan, Robert S. & Norton, David P. (2008). Mastering the Management System. Harvard Business Re-20 view.

Kimball (2002b). You don’t need an EDW. Kimball Group.

Malinowski, Elzbieta og Esteban Zimányi(2004). OLAP Hierarchies: A Conceptual Perspective. Department of Informatics CP 165/15.Université Libre de Bruxelles, 50 av. F.D. Roosevelt.1050 Brussels, Belgium.

Nørreklit, Lennart, Nørreklit, Hanne & Israelsen, Poul(2006). The validity of management control topoi. 25

Nørreklit, Hanne. Jacobsen, Marten. Mitchell, Falconer(2008). Pitfalls in Using the Balanced Scorecard.Wiley Peridiocals, Inc.

Otley, D. (1999). Performance management: a framework for management control systems research, Man-agement Accounting Research, 10, 363-382.

Pedersen, Torben. Jensen, Christian & Dyreson, Curtis(2001). A foundation for capturing and querying 30 complex multidimensional data. Information systems, Vol. 26 s. 383-423.

Pedersen, Torben & Jensen, Christian(2001). Multidimensional database Technology. Computer. Decem-ber

Rahm, Erhard & Hai Do, Hong (2000). Data Cleaning: Problems and Approaches.


Side 83 af 90

Raue, Kristian, Barczaitis, Holger. Wolff ,Torsten. Endlich, Stephanie, Tutas, Jörg, Moser, Karin, Lenz, Dominik og Kriehn, Werner(2008) Palo Manual 2.5. side 1-353.

Ricciardi, Ettore (2005). Balanced Scorecard and its information system: The performance data warehouse. SASE What Counts? Calculation,Representation, Association. Annual Meeting on Socio-Economics Central European Universty and Corvinus University of Budapest. 5

Riebel, Paul og Johann Wolfgang (1994). Core features of the “Einzelkosten- und Deckungsbeitrags-rechnung”, European Accounting Association.

Taleb, Ahmad(2007). An efficent framework for the manipulation of OLAP Hierarchies. A thesis in the de-partment of computer science and software engineering. Presented in partial fulfilment of the require-ments for the degree of master of computer science at Concordia University Montreal, Quebec. 10

Wiese, Lars Ole (2005). Rapportering med ABC modellen, Økonomistyring & Informatik, 21. årgang, Num-mer 4.


Side 84 af 90

19. Bilag

Bilag 1: Data marter til balanced scorecard

Det finansielle perspektiv

Kundeperspektivet 5


Side 85 af 90

Det interne perspektiv

Lærings og vækstperspektivet

5


Side 86 af 90

Bilag 2: Metadata til dimensionerne


Side 87 af 90

Bilag 3: Metadata til facttabellerne


Side 88 af 90

Bilag 4: ETL-processerne

Stedsdimensionen

5

Tidsdimensionen

Produktdimensionen

10


Side 89 af 90

Partnerdimensionen

Medarbejderdimensionen

5 Kontoplansdimensionen

Finansielt perspektiv

10

15


Side 90 af 90

Kundeperspektivet

Documents

8. semester Økonomistyring og informatik Gruppe 3 …vbn.aau.dk/files/17590341/Grp_3._8._semesterprojeket_cand.merc.__k... · 20 5.3 Inmon vs. Kimball ... Kilde: Egen tilvirkning