Økonomisk beskrivelsesteknik og teknologier for systemanvendelse

Transkript

1 Aalborg Universitet Cand.merc. økonomistyring og informatik 1. semester Økonomisk beskrivelsesteknik og teknologier for systemanvendelse Gruppe 3

2 Titelblad Titel: Temaramme modul 1: Temaramme modul 2: Opgave: Afleveringsdato: Økonomisk beskrivelsesteknik og teknologier for systemanvendelse Grundregnskabet og udvalgte økonomistyringsmodeller, samt relevant teknologi for systemanvendelse Beskrivelsesteknikker 1. semesteropgave - cand.merc. Økonomistyring og Informatik. januar 09, Aalborg Universitet 1 Normalsider: 70 Udarbejdet af: Gruppe 3 Vejledere: Henrik Find Fladkjær, Jens Godik Højen og Lars Ole Wiese Kenneth Lefevre Nielsen Rasmus Jessen 2 Henrik Hjort Nielsen Jesper Schou Madsen 1

3 Indholdsfortegnelse Forord Metode Paradigmeopfattelse Opsamling Indledning - Modul Det operative paradigme - Modul Variabilitetsprincippet Dimensioner i variabilitetsprincippet Kritik af variabilitetsprincippet Activity Based Costing Trin 1: Fordeling fra ressourcepulje til aktivitet Trin 2: Fordeling fra aktivitet til omkostningsobjekt Kritik og forudsætninger for brug af ABC-modellen Variabilitetsprincippet og ABC Direkte og indirekte omkostninger Manglende indtægter Manglende mængder Designvalg af løsningsforslaget fra et økonomistyringsperspektiv Opsamling Informatik Relationsdatabaser Structured Query Language Case: Solipstoid Entitets-Relations diagram Normalformer Rapportering Afrunding - Modul

4 11. Indledning - Modul Det operative paradigme - Modul Enterprise Resource Planning Historien bag ERP ERP-begrebet ERP-systemet ERP som koncept - tankegangen bag ERP Fordele ved ERP-systemer SAP Business One Forskellen mellem ERP og ABC Data fra SBO til ABC-kalkulation Information fra SBO Rapporteringsobjekter og tidshorisont Direkte omkostninger Indirekte omkostninger og ressourcepuljer Aktiviteter Costdrivere Indtægtsdata Case til Modul Entitets-Relations diagram Rapportering på omkostningsobjekterne Henføring af de direkte omkostninger Fordeling af de indirekte omkostninger Det samlede omkostningstræk Afrunding - Modul Litteraturliste Bilag

5 Forord Dette projekt er udarbejdet på 1. semester på cand.merc.-studiet i Økonomistyring og Informatik på Aalborg Universitet. Nærværende semester har temarammen Økonomisk beskrivelsesteknik og teknologier for systemanvendelse, og der vil indenfor denne overordnede ramme blive arbejdet med 2 separate seminarrapporter. Det endelige projekt består således af to dele, modul 1 og 2, der udgør hver sin del af projektet. Begge moduler tager udgangspunkt i et konkret seminaremne, og begge moduler er bearbejdet i midtvejsseminarer samt afslutningsseminarer, hvor der er opponeret på det skrevne. Modul 1 har temarammen Grundregnskabet og udvalgte økonomistyringsmodeller, samt relevant teknologi for systemanvendelse, og indenfor denne ramme vil der blive arbejdet i dybden med et seminaremne. Modul 2 har temarammen Beskrivelsesteknikker, og indenfor denne ramme vil der blive arbejdet med en konkret problemstilling vedrørende temarammen. Der skal rettes en tak til de respektive vejledere, der har været tilknyttet de to seminarer, og en tak til de medstuderende for deres opponentindlæg. 1 4

6 1. Metode 1 2 Metoden kan ses som den første del af enhver problemorienteret proces, da der bør gøres nogle overvejelser om, hvordan et givet problem skal gribes an. Metoden kan således være afgørende for, hvilket svar eller løsning projektforløbet kan give på et givet problem. Metoden er således det middel, som bruges til erkendelse og videreformidling af denne erkendelse. Den valgte metode bliver derfor grundlaget for hele pro- jektprocessen og kommer til at styre hvilken retning processen bevæger sig. For at anskueliggøre metoden tages der i det følgende udgangspunkt i paradigmebegrebet, der vil blive forklaret. Herunder vil gruppens grundlæggende antagelser blive belyst. Disse danner udgangspunkt for arbejdet med seminaremnerne. Udgangspunktet for forståelsen af paradigmebegrebet er Törnebohms evolutionære paradigme. Før gennemgangen af paradigmeopfattelsen skal der lige knyttes en generel kommentar til det problemori- enterede projektarbejde. Til beskrivelse heraf benyttes følgende citat af Illeris(1974): Det helt centrale ved den problemorienterede undervisningsform er, at udgangspunktet ikke tages i de gennem traditionen udviklede fag, hvis konstituering ligger langt tilbage i fortiden og var betinget af for længst forsvundne samfundsforhold, men derimod i foreliggende problemer, der findes her og nu, i hvis behandling de forskellige fags viden, metoder og teorier inddrages i det omfang, det netop ud fra den pågældende problemstilling er relevant 1 Illeris sætter problemet i fokus, hvilket er hovedpunktet ved problemorienteret projektarbejde. Ved at sætte problemstillingerne forrest sikres der relevante problemløsninger, i det omfang, at der inddrages rele- vante delelementer fra de berørte fagområder, der er berørt af problemstillingen. Herved undgås det, at projektet bliver fanget i ét fagområdes paradigme, hvorved løsningen af problemstillingen kun kan ske ved brug af viden, metoder og teorier indenfor det gældende paradigme. Det problemorienterede projektarbejde vil derfor ofte være tværfagligt, hvilket eksempelvis er tilfældet i dette projekt, hvor der benyttes økonomistyringsteori og informatik. Da seminarrapporten vil blive baseret på teoretisk materiale, vil empiri ikke blive inddraget. Følgevirkningerne af det er, at rapporten bliver produktet af gruppens virkelighedsopfattelser. Fokus vil ligge på økonomisk teori og sammenkædningen med informatikken. I det følgende vil paradigmeopfattelsen blive forklaret Paradigmeopfattelse Udgangspunktet for paradigmeopfattelsen er som nævnt Törnebohms paradigmeopfattelse, men for at forstå baggrunden for Törnebohms paradigmeopfattelse, bør Kuhns paradigmeopfattelse inddrages. Kuhn så det videnskabelige arbejde, som arbejde indenfor et givet paradigme, hvor man søger at påvise, at ano- 1 Illeris(1974) s. 80

7 malier, indenfor paradigmet, i bund og grund er forenelige med paradigmet. På denne måde bliver videnskab 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 paradigme, må dette afløses af et nyt paradigme. Dette er Kuhns videnskabelige revolution. 2 Den revolutionære opfattelse af paradigmet giver dog anledning til problemer, og specielt forskellen mellem naturvidenskabernes og samfundsvidenskabernes paradigmer giver anledning til en anden paradigmeopfattelse. Inden for naturvidenskaben er det således tydeligt, at et gældende paradigme bliver afløst af et nyt, men indenfor samfundsvidenskaben behøves der ikke nødvendigvis være noget i vejen for, at et nyt paradigme ikke kan eksistere ved siden af ældre paradigmer. Det er med denne baggrund, at Törnebohms paradigmeopfattelse benyttes. Törnebohms paradigmeopfattelse består af følgende elementer: 3 Conception of reality (Virkelighedsopfattelse) Conception of science (Videnskabsopfattelse) Scientific ideals (Videnskabsidealer) Ethical/aesthethical aspects (Etiske/æstetiske aspekter) 1 2 Efterfølgende vil en forklaring af disse punkter i relation til vores paradigmeopfattelse følge, med undtagelse af scientific ideals og ethical/aesthethical aspects, da disse elementer ikke vil blive anvendt i projektet. Virkelighedsopfattelse Der findes en række grundlæggende antagelser om virkeligheden, og disse er grundlaget for det, der kendes som videnskabsteoretiske positioner. Der findes derfor en række videnskabsteoretiske positioner med forskellige opfattelser af virkeligheden. Positivismen har således en helt anden opfattelse af virkeligheden end eksempelvis kritisk rationalisme. Dette skyldes de grundlæggende antagelser, der ligger til grund for de to positioner. Derfor forklares de grundlæggende antagelser, som lægger til grund for projektet i det følgende. Gruppens virkelighed er en social konstruktion, hvor gruppemedlemmerne gennem dialog ændrer forforståelse til ny forståelse, som så er udgangspunkt for en ny for-forståelse. Virkeligheden eksisterer således der, hvor gruppemedlemmernes forståelser stemmer overens. Samtidig ses genstandsfeltet mellem økonomistyringsbegrebet og informatikken som et kontinuerligt udviklende genstandsfelt, hvor nye idéer og tilgange løbende ændrer praksis ved at bringe ny viden i spil. I Danmark kan Vagn Madsen efter grup- 2 Pahuus i Christensen(red.)(04) s Arbnor & Bjerke(1997) s. 13 6

8 1 2 pens opfattelse ses som én af foregangsmændene indenfor dette genstandsfelt. Ved at præsentere variabilitetsprincippet påvirkede Vagn Madsen således gruppens virkelighedsopfattelse af økonomistyringsbegrebet. Den tyske retning indenfor økonomistyring bidrager på samme måde til paradigmet. Ved at inddrage andre tilgange end Vagn Madsens, udbygges forståelsen af økonomistyringsparadigmet. På denne måde udbygges økonomistyringsparadigmet kontinuerligt ved, at nye teoretiske aspekter afprøves og indlejres i paradigmet. Fokus indenfor økonomistyring kan således vurderes til at have flyttet sig fra kontrol af omkostninger til, at kunne levere beslutningsinformation. Dette fordrer således et alsidigt registreringssystem, som kan tilgodese flere formål. Paradigmet er derfor et dynamisk paradigme, som ændrer sig i takt med samfundet. Gruppens virkelighedsopfattelse bliver på denne måde en social konstruktion, og virkelighedsopfattelsen vil nu blive uddybet med udgangspunkt i Lennart Nørreklits tilgang til begrebet. 4 Nørreklit benytter fire dimensioner på virkeligheden, som vil blive kort forklaret følgende. Disse er fakticitet, mulighed, værdier og kommunikation. Alle fire er forbundet med følgende citat, som kan danne udgangspunkt for en virkelighedsdefinition: Virkeligheden knytter sig til muligheden for at udføre bevidste virkende handlinger 6 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(04) argumenterer for, at en aktør uden mulighed er død. Virkeligheden eksisterer endvidere kun, hvis der er en kombination af fakta og mulighed. Eksempelvis kan der ligge en bog på et bord, som aktøren kan læse eller lade være med at læse. Mulighederne skabes altså gennem refleksion, som i høj grad sker gennem vores erfaringer. 7 Mulighed er senere omskrevet til logik af Nørreklit et al.(06), hvorved muligheder opstår som følge af erfaringsgrundlaget. Det vil sige, at der skal oprettes et teoretisk grundlag om økonomistyring, ERP og informatik for at kunne sammenkæde begreberne. For at det er muligt for aktøren at vælge mellem forskellige alternativer, som opstår på grund af mulighedsdimensionen, er det nødvendigt at inddrage den tredje dimension; begrebet værdi. Værdibegrebet spiller en væsentlig rolle i forbindelse med virkeligheden, i og med det uden værdibegrebet ville være umuligt for aktøren at prioritere alternativer, og der ville ikke kunne foretages et valg. Aktøren vil 4 Nørreklit i Christensen(red.)(04) 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 (06) 6 Nørreklit(04) s Nørreklit, Nørreklit & Israelsen(06) s. 46 7

9 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: der knytter mig til verden for sin egen skyld, fordi det gør verden dejlig, elskelig og spændende at være i 8 1 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 dimensioner, og værdidimensionen vil udelukkende blive synlig gennem kommunikationen. 9 Kommunikationsdimensionen bliver således en forklaring af handlinger foretaget på baggrund af de tre andre dimensioner. Vores grundlæggende antagelse om virkeligheden bliver derfor en firedimensional virkelighed, som kun eksisterer 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 alternative muligheder uden værdier. Videnskabsopfattelse Gennem vores uddannelse er gruppen blevet bekendt med en række teoretiske modeller indenfor erhvervsøkonomi som er blevet forelagt i studieretningens undervisningsforløb, og denne viden danner udgangspunkt for gruppens videnskabsopfattelse. Denne lagrede viden påvirker således gruppens opfattelser af de genstandsfelter, som der undersøges. 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. Gruppen er derfor i høj grad præget af teoretisk tunge økonomimodeller i gruppens videnskabsopfattelse, idet det hidtidige uddannelsesforløb har haft hovedfokus på netop dette Opsamling I det foregående metodeafsnit er gruppens opfattelse af økonomistyringsparadigmet blevet beskrevet, og denne beskrivelse vil danne udgangspunkt for det videre arbejde. Projektet vil derfor blive opbygget på en sådan måde, at de ovennævnte begreber bringes i spil. For at svare på seminaremne 1 vil det således være nødvendigt at definere Vagn Madsens variabilitetsprincip og Cooper og Kaplans ABC-begreb. Herved skabes muligheden for at drage logiske deduktioner mellem de to dele i analyseafsnittet, da der er opbygget et erfaringsgrundlag om de to begreber. Først vil der såle- 8 Nørreklit(04) s Nørreklit(04) s Arbnor & Bjerke(1997) s. 1 8

10 des være en teoretisk analyse af, hvordan variabilitetsprincippet kan levere data til en ABC-kalkulation for herefter at lave en applikation som kan rapportere efter ABC-begrebet på baggrund af variabilitetsprincippets registreringer. 1 Seminaremne 2 vil derimod lægge vægt på ERP-begrebet, hvorfor der opbygges et erfaringsgrundlag om ERP-begrebet til den senere analyse. ERP kædes derefter sammen med ABC-begrebet, hvor der først fokuseres på hvilke data, der kan bruges fra ERP-systemer til ABC-kalkulationer. Herefter udvikles der endnu en applikation, som skal rapportere efter ABC-begrebet, men i denne applikation inddrages der også indtægter. Metoden i projektet bliver derfor at opbygge et teoretisk erfaringsgrundlag om de berørte begreber, hvorefter disse kædes sammen gennem logiske deduktioner. Til at strukturere de to analyser benyttes ABCmodellen som metodisk procedure. Dette vil sige, at analyserne opbygges efter ABC modellen bestanddele. Dette er valgt, fordi ABC-begrebet indgår i begge seminaremner, og da denne opbygning af analysen ligeledes understøtter tankegangen brugt i udviklingen af applikationerne. Opbygningen af de to seminaremner kan ses mere udførlig i de tilhørende operative paradigmer, som forklarer den praktiske tilgang til seminaremnerne. Der kan således forekomme små afvigelser fra ABC-modellen i de to operative paradigmer, hvor dette er fundet nødvendigt for at svare på seminaremner. 9

11 2. Indledning - Modul 1 Allerede midt i det sidste århundrede fremlagde Vagn Madsen variabilitetsprincippet efter studier i udlandet. Vagn Madsen mente, at det var nødvendigt med yderligere omkostningsstyring til at løse de seks regnskabsopgaver, end den der i forvejen var almen anvendt. Vagn Madsen var dermed forud for sin tid. På trods af at hans oprindelige variabilitetsprincip ikke er anvendt i sin rene form den dag i dag, danner hans idéer om variabilitetsprincippet grundlag for tankegangen bag nogle af de modeller der stadig anvendes. I det følgende vil der således blive belyst et omkostningsregistreringsprincip, kaldet variabilitetsprincippet, som er behandlet af Madsen(191). Dette omkostningsregistreringsprincip bygger på en skarp adskillelse mellem dataregistrering og dataanvendelse, hvilket får den betydning, at grundregistreringer skal være uafhængige af efterfølgende rapportering på data. Der vil derved i dette modul arbejdes ud fra et formålspluralistisk omkostningsregistreringsprincip, som kan understøtte flere alsidige rapporteringer. I moderne IT-systemer, hvor den relationelle database understøtter virksomhedernes registreringsgrundlag, vil det dermed blive interessant at undersøge, hvorledes den relationelle database kan understøtte tankerne for variabilitetsprincippet, som Israelsen(1989) mener den relationelle database kan. 1 Via inddragelsen af informationsteknologi for en faktisk anvendelse af de teoretiske økonomistyringsmodeller vil idéerne fremført af Vagn Madsen(variabilitetsprincippet) og Kaplan(ABC) derved komme skridtet videre fra bøgerne og over i de nutidige informationsstyringssystemer, der danner fundamentet for styring af nutidige komplekse virksomhedsstrukturer. Det vil således i dette modul være interessant at arbejde med Madsens variabilitetsprincip og ABC som rapporteringsteknik og derved udvikle det hidtidige forståelsesgrundlag for fagområderne økonomistyring og informatik. Sigtet bliver dermed, at udvide forståelsen af økonomistyringsmodellernes anvendelsesmuligheder i en relativ database.

12 3. Det operative paradigme - Modul 1 I det følgende vil arbejdsmetoden blive beskrevet. Her vil der blive arbejdet ud fra den problemstilling, som gruppen lagde som ramme for nærværende projektet. Problemstillingen lyder; 1 2 Et forslag til anvendelse af variabilitetsprincippet som registreringsgrundlag og ABC som rapporteringsteknik med produktet som omkostningsobjekt Den grafiske illustration for projektet er belyst i figur 1 og fordrer således en belysningen af regnskabsteoretikeren Vagn Madsens(1969) fremstilling af det interne regnskabsvæsens registreringsgrundlag; variabilitetsregnskabet. 11 Dette grundregnskab er således en fremstilling, der giver et bud på, hvorledes virksomhedens interne registrering kan foregå med det formål at tilfredsstille alle regnskabets opgaver. Formålet med projektet bliver at udarbejde en registreringsmodel, der kan rapportere på Activity Based Costing. Figur 1: Det operative paradigme Først vil omkostningsregistreringsprincippet, variabilitetsprincippet, blive belyst. Herefter vil en teoretisk fremstilling af ABC blive Variabilitetsprincippet Activity Based Costing fremført for, at der i det efterfølgende afsnit kan vurderes, hvilke elementer der kan forene de to modeller ud fra et økonomisty- Variabilitetsprincippet og ABC ringsperspektiv. Efterfølgende vil et hovedafsnit om den informatikmæssige del af projektet fremstå. Teorien om den relationelle Informatik Case database vil herefter belyses direkte via en fiktiv case, der belyser hvorledes variabilitetsprincippet og ABC kan indarbejdes i den relationelle database. Det næste hovedafsnit indeholder derfor ca- Kilde: Egen tilvirkning Afrapportering sebeskrivelsen, hvorefter en grafisk brugerflade ovenpå selve databasen, der i dette tilfælde bliver udarbejdet i Oracles Applikation Express(APEX), vil fremstå. Sigtet med opgaven er derved, at konstruere en database, der via en applikation kan registrere omkostningsdata samt udtrække ABC-information på produkter. Det afsluttende afsnit, afrapportering, forklarer således denne opbygningsfase og giver eksempler via screen shots. 11 Madsen(1969) s

13 4. Variabilitetsprincippet 1 2 Dette afsnit tager udgangspunkt i Vagn Madsens variabilitetsprincip og skal forklare hovedtrækkene i variabilitetsprincippet. Herunder skal det fremhæve intentionen med variabilitetsprincippet som grundregistreringssystem og redegøre for grundtankerne i modellen. Til sidst afsluttes med kritik af variabilitetsprincippet som overgang til afsnittet om Activity Based Costing. Sidst i 60 erne kom den danske professor i økonomi, Vagn Madsen, med et bud på et registreringssystem der ikke arbejder med arbitrære fordelinger. Formålet med dette var, at have et formålsneutralt grundregnskab, hvori data til løsning af forskellige økonomistyringsopgaver skulle registreres. Variabilitetsprincippet tog udgangspunkt i, at virksomhederne havde flere forskellige opgaver at løse med deres registreringer indenfor økonomistyring og regnskab. Disse opgaver samlede han under seks grupperinger: Registreringsopgaven, overskudsopgaven, kalkulations- og prisfastsættelsesopgaven, kontrolopgaven, alternativopgaven og budgetopgaven. 12 Praksis havde hidtil været, at et regnskabssystem var rettet mod at løse hovedsageligt én opgave. Men Vagn Madsen ville, med anvendelse af variabilitetsprincippet, foretage dataregistrering uafhængigt af måden, hvorpå de pågældende data efterfølgende anvendes. Der kan derfor anvendes variabilitetsprincippet som grundlag for udarbejdelsen af de seks regnskabsopgaver, dog med det forbehold at visse af regnskabsopgaverne kræver indtægtsregistrering, der ikke er indeholdt variabilitetsprincippet i sin grundform. Når der derved skal foretages forskellige kalkulationer og rapporteringer bringes finansregnskabets og variabilitetsprincippets registreringer sammen Dimensioner i variabilitetsprincippet Grundlaget for at kunne udføre Vagn Madsens forskellige opgaver er, at registreringsopgaven er løst i henhold til variabilitetsprincippet. Der tages udgangspunkt i de tre dimensioner, art, sted og formål. Kravet er derfor i variabilitetsprincippet, at ethvert forbrug kan karakteriseres under kriterier for såvel arts-, steds- og formålsdimensionen. 14 Artsdimensionen er en beskrivelse af hvad det er der forbruges. Eksempler herpå kan være løn og materialer. Efter registreringen er udført på artsdimensionen, skal stedet hvor forbruget finder sted defineres, hvilket kan være i direktionen, økonomiafdelingen, udviklingsafdelingen, hos salgsfunktionen eller i produktionen. Til sidst skal der registreres på formålsdimensionen, hvilket kan være et givent produkt, omstilling, service eller vedligeholdelse. Der oprettes således specifikke kontonumre til hver eneste art, sted og formål, således at ethvert forbrug altid kan karakteriseres ud fra enhver af de tre dimen- 12 Madsen(1969) s Bukh & Israelsen(04) s Bukh & Israelsen(04) s

14 sioner og samtidigt kan sammenhængen mellem de tre ses via krydshenvisninger. Arterne har således kontonumre fra , stederne for , mens formål har fra i Madsens klassificeringer af de tre dimensioner. 1 Et af formålene ved variabilitetsprincippet er at undvige, at der opstår arbitrære fordelinger af omkostningerne i registreringen. Arbitrære fordelinger undgås i de enkelte registreringsdimensioner ved at operere med hierarkier, hvor de forskellige konti opstilles som hierarkisk ordnede i forhold til hinanden. Det gælder, at abstraktionsniveauet mindskes desto længere ned i hierarkiet registreringen foretages. Omkostningerne må i registreringen placeres direkte i nærmest mulig kontakt med den faktor, hvormed de varierer, ud fra den tankegang, at man kun kan påvirke de omkostninger, der er forbundet med mængden, forudsat at priserne er konstante. 16 Det vil sige, at hvis en omkostning ikke kan splittes op skal den føres op på et højere niveau indtil den kan fordeles i hierarkiet for dimensionerne sted og formål. En omkostning placeres dermed så langt nede i hierarkiet, som en ikke-arbitrær fordeling muliggør. I figuren herunder ses et eksempel på en teoretisk opdeling efter hierarkier. 1 Madsen(191) s Madsen(191) s

15 Figur 2: Arts-, steds- og formålsdimensionen opstillet efter hierarkier Kilde: Egen tilvirkning Et eksempel fra figur 2 kan være en medarbejder der har arbejdet i produktionen med montage på både produkt A, B og C. Her skal denne medarbejders lønomkostninger placeres umiddelbart på niveauet over selve produkterne. Dette er tilfældet, hvis omkostningerne ikke kan henføres direkte til de enkelte produkter. Dog med det forbehold, at hvis medarbejderens omkostningsforbrug til det enkelte produkt kan måles ved produktionen, kan denne omkostning konteres helt nede på produktniveau. Medarbejderens løn skulle således konteres under timeløn under artsdimensionen, montage i stedsdimensionen, samt under produktion i formålsdimensionen, hvilket er markeret i boksene herover. 4.2 Kritik af variabilitetsprincippet Siden Vagn Madsen nedfældede tankerne om variabilitetsprincippet er flere teoretikere kommet med kritik. Hovedtrækkene i kritikken går ofte på mangler ved princippet i dets grundlæggende form. En kritik er at der udelukkende foretages omkostningsregistrering. Indtægtsbeskrivelsen hos Madsen er ikke dimensione- 14

16 1 ret, hvorfor rapportering af kundeprofitabilitet i variabilitetsprincippet ikke umiddelbart synes mulig. 17 Endvidere forholder variabilitetsprincippet sig ikke til omkostningernes reversibilitet. Der kan derfor tilføjes en ekstra dimension hertil, for at afhjælpe problemstillinger hvor reversibilitet kan være et væsentligt beslutningsparameter. Det skal yderligere bemærkes, at variabilitetsprincippet ikke registrerer på ikkeøkonomiske nøgletal, som for eksempel sygefravær, kundetilfredshed, loyalitet og medarbejdertilfredshed. Dette betyder, at de beslutninger der skal træffes, ikke altid har et tilstrækkeligt datagrundlag til alle beslutningssituationer, som nutidens virksomheder kan befinde sig i. Der kan dog erkendes, at disse parametre ikke var alment anvendt, da variabilitetsprincippet tog sin form i begyndelsen af 190 erne, og flere af parametrene optræder derfor ikke i variabilitetsprincippet i dets grundlæggende form. Den sidste betydelige kritik af Vagn Madsen, som der lægges vægt på er, at variabilitetsprincippet ikke lægger op til en registrering af en omkostnings mængdeside, hvilket kan være uhensigtsmæssigt, idet det herved ikke er muligt at forklare ud fra registreringen, hvorvidt en omkostningsafvigelse skyldes mængde- eller prismæssige ændringer eller en kombination heraf. Dette kan igen vise sig, at være kritisk, da valg af andre alternativer kan være truffet på et forkert grundlag med yderligere omkostninger til den givne virksomhed som følge heraf. Efter at have gennemgået registreringsgrundlaget, vil det næste afsnit omhandle ABC, hvor det i dette modul skal anvendes som rapporteringsteknik. 17 Wiese (0/06) s

17 . Activity Based Costing Activity Based Costing er et fordelingsregnskab, opstået i USA som kritik af de traditionelle omkostningsfordelingsregnskaber. 18 Foregangsmændene for dette princip, Robert S. Kaplan og Robin Cooper, fremførte således i 1980 erne idéer for fordeling af omkostninger i en to-trins-procedure. 19 Konceptet har løbende været ændret, og der er dukket alternativer op, der tager udgangspunkt i den aktivitetsbaserede fordelingstankegang, blandt andet Timedriven-ABC. Følgende beskrivelse vil tage afsæt i Kaplan & Cooper(1998), idet undervisning på denne studieretning har understøttet det modelapparat, der er angivet i denne bogudgave. Selve idéen med ABC er, at kunne afspejle årsagerne i omkostningsforbruget for givne omkostningsobjekter, hvor begrebet omkostningsobjekter kan henledes til et analyseobjekt, eksempelvis værende et produkt, serviceydelser eller kunder. 21 Fremgangsmåden er illustreret i nedenstående figur: Figur 3: ABC-modellen Trin 1 Ressource- Pulje 1 Ressource- Pulje 2 Ressource- Pulje n Ressourcecostdrivere Aktivitet 1 Aktivitet 2 Aktivitet n Trin 2 Aktivitetscostdrivere Direkte omkostninger Omkostningsobjekter: - Produktenheder, serier, produkter, produktgrupper, salgsordrer, kunde, kundegrupper Kilde: Egen tilvirkning på baggrund af Kaplan og Cooper(1998) s. 84, samt Bukh og Israelsen(04) s Bukh & Israelsen(04) s Bukh & Israelsen(04) s. 31 Anderson & Kaplan(04) 21 Bukh & Israelsen(04) s

18 1 2.1 Trin 1: Fordeling fra ressourcepulje til aktivitet Oprindelig var modellen udarbejdet til at fordele periodiserede udgifter, som det direkte fremgår af modelopbygningen af Kaplan og Cooper(1998). 22 For denne metodefremgang kan modellen således ændres, hvorom omkostninger kan blive den monetære enhed der fordeles gennem modellen. Dette er, hvad der vil blive valgt, når Madsens(191) bud på omkostningsregistreringsdata skal konstrueres med henblik på et analyseformål med den konkrete model. Omkostningsvurderingsprincippet bliver i dette tilfælde således på faktorprisen, budgetsatser, når Madsens registreringsdata skal anvendes i modellen. Bukh og Israelsen(04) nævner således, at omkostningsvurderingsprincippet af ressourceomkostninger ikke er problematiseret i ABC-litteraturen. 23 Det må derfor antages, at omkostningsvurderingsprincippet skal klarlægges før modellen konstrueres. Omkostninger fra finanskontoplan tildeles til aktiviteterne gennem ressourcepuljer Bukh og Israelsen(04) belyser endvidere, at tankegangen med ABC er, at omkostningsobjekterne skaber behov for en aktivitetsudførelse, som igen stiller krav for at have ressourcer, der kan udføre aktiviteterne. Ressourcerne medfører hermed omkostninger. 24 Bukh og Israelsen(04) har med denne udlægning oversat ABC-tankegangen til fordelingen af omkostninger. Videreførelsen af dette betyder, at aktiviteter i en organisation kan defineres, hvorefter en ressourceallokering til aktiviteter kan finde sted. Dette sker under trin 1 i figur 3. Fordelingen af ressourceomkostninger sker i første trin på de aktiviteter, som foretages i organisationen, værende omstilling eller telefonopkald med mere. Grupperingen af indirekte omkostninger til ressourcepuljer sker udenfor modellen og vil i praksis tages fra virksomhedens finanskontoplan. En viderefordeling af disse grupper af omkostninger sker således ud på de udførte aktiviteter. 2 Angående de direkte relaterede omkostninger til omkostningsobjekter i form af eksempelvis direkte materiale og direkte løn henføres disse direkte til omkostningsobjekterne, som det fremgår af modellen. De direkte omkostninger inddrages dermed ikke i fordelingsfremgangen, der bliver beskrevet i det efterfølgende. Aktivitetsdefineringen i organisationen kan i designfasen være bredspekteret og spænde fra få aktivitetsdefineringer, -30, til over Dette bliver et spørgsmål om detaljeringsgraden af fordelingen, som senere vil blive taget op under kritikpunkter ved modellen. Under trin 1 sker der således en fordeling af indirekte omkostninger ud på de enkelte aktiviteter. En værdiansættelse af virksomhedens udførte aktiviteter bliver 22 Kaplan & Cooper(1998) s Bukh & Israelsen(04) s Bukh & Israelsen(04) s Bukh & Israelsen(04) s Kaplan & Cooper(1998) s

19 hermed en del af processen. 27 Selve fordelingen fra ressourcer til aktiviteter kan ske ved spørgeskema eller interviews fra de enkelte ansatte. Henføringen ligger i begrebet ressourcecostdriver der beskrives i næstkommende afsnit. 1 Ressourcecostdriver Indsamlingen af dette fordelingsmateriale kan ske, hvor en registrering af det anvendte tidsforbrug for de udførte aktiviteter fremgår. 28 Eksemplet kan være en /30/60 procentfordeling af den enkelte homogene medarbejdergruppes tidsanvendelse for tre forskellige udførte aktiviteter. Ressourcecostdriversatsen er i dette eksempel således, 30 og 60 procent. Fordelingen af indirekte lønomkostninger fra finanskontoplanen bliver herved spredt ud på tre angivne aktiviteter. Erfaringer fra danske virksomheders ABC-projekter har i denne sammenhæng vist, at fordelingen af forskellige omkostningsarter via skønsmæssige procentsatser har været anvendt i praksis. 29 Hierarkier i ABC Med ABC-modellen har Cooper og Kaplan(1998) i deres modelarbejde udviklet hierarkimodellen. 30 Dette modelarbejde har medvirket til at inddele aktiviteterne i hierarkiniveauer, som benævnes enheds- og serierelateret niveau, samt produkt- og virksomhedsbevarende niveau. 31 Det enhedsrelaterede niveau kan i denne sammenhæng relateres til eksempelvis aktiviteten boring, der kan være en fysisk boring af et hul i hvert emne. Aktiviteter på serieniveauet er eksempelvis omstilling og kundeordrebehandling. Endvidere er der det tredje niveau, det produktbevarende niveau, som kan relateres til aktiviteter, der kan være udarbejdelse af styklister og andre aktiviteter, der ikke er forbundet med volumen og mix i produktsammensætningen. 32 Det sidste niveau, som er det virksomhedsbevarende niveau, skal der tages særligt hensyn til, da der her ikke foretages en viderefordelingen af omkostninger. Begrebet for omkostninger tildelt til dette niveau benævnes fællesomkostninger, hvilket betyder, at omkostningerne er fælles for en række objekter. 33 Eksempler på disse fællesomkostninger kan være omkostningsarterne; topledelse og forsikringspræmie. 27 Kaplan & Cooper(1998) s Kaplan & Cooper(1998) s Bukh & Israelsen(03) s Cooper & Kaplan(1991) s Cooper & Kaplan(1991) s Kaplan & Cooper(1998) s Bukh & Israelsen(04) s

20 Afsluttende for denne belysning af fordelingen under trin 1, skal der knyttes en kommentar til hvilke omkostninger, som der fordeles. Opfattelsen af hvilke omkostninger der ikke fordeles i et ABC-regnskab skal bero på den enkelte analyse og citatet fra Clark(1923) udtrykker situationen: different cost for different purposeses 1 Meningen med denne sætning kan forklares ved, at en virksomhedsledelse i ét konkret ABC-projekt kan opfattes som en fællesomkostning og derved ikke fordeles til objekterne, mens samme omkostning for et andet ABC-projekt kan være en direkte omkostning. Analyseobjektet bestemmer således omkostningsklassificeringen og derved hvilke omkostninger, som fordeles i en ABC-model, hvis den hierarkiske model tages i anvendelse..2 Trin 2: Fordeling fra aktivitet til omkostningsobjekt Når aktiviteterne er defineret og relationer imellem ressourcerne og aktiviteterne er klargjort, kan fordelingen i næste trin ned på omkostningsobjekterne foretages. Dette sker via aktivitetscostdrivere. Disse aktivitetscostdrivere kan eksempelvis være opstart for aktiviteten omstilling, og costdriverne er klassificeret i tre grupperinger; 1) transaktionsaktionsdriver, 2) varighedsdriver samt 3) direkte måling. Disse vil blive beskrevet i det følgende. Transaktionsdriver Transaktionsdriveren henleder til det antal gange en aktivitet bliver udført og kan anvendes i de situationer, hvor aktivitetsudførelsen er homogen for hvert omkostningsobjekt. Dette kan være tilfælde for enhedsrelaterede aktiviteter, der i sin udførelsesfase er ens i forhold til hvert omkostningsobjekt. 2 Varighedsdriver og direkte måling Den anden driver, varighedsdriveren, henviser til det estimerede tidsforbrug, der medgår aktiviteten for behandling af det konkrete omkostningsobjekt. Varighedsdriveren vil derved blive anvendt i de tilfælde, hvor aktivitetsudførelse er forskellig i tid, eksempelvis hvor omstillingen af maskinapparatet kræver differentieret udførsel. Det kan være ti minutter for én omstilling og seks timer for en anden omstilling. 34 I disse tilfælde kan en varighedsdriver blive anvendelig og afspejle det réelle træk, omkostningsobjekterne foretager på de forskellige aktiviteter. Selve valget af costdriver bliver et spørgsmål om detaljeringsgraden i modellen, og i særlige tilfælde kan en direkte måling af hver eneste gang aktiviteten bliver udført blive rele- 34 Kaplan & Cooper(1998) s

21 vant. Costdriveren direkte måling anvendes således i tilfælde, hvor aktiviteten er anset kostbar, og tidsforbruget af aktiviteten skal måles helt eksakt Kritik og forudsætninger for brug af ABC-modellen Kritikken mod ABC-modellen går blandt andet på, at den ikke kan anvendes som en driftsøkonomisk model. Den driftsøkonomiske tanke er således den, at når begrebet variable omkostninger tages i anvendelse for at analysere komme til- og falde bort-betragtninger, kan der fremføres en resultatmæssig effekt i regnskabet. I tilfælde hvor en kalkulationsanalyse fokuserer på disse variable omkostninger og dermed implicit indeholder en forudsætning om høj grad af variabilitet og reversibilitet for de angivne analyserede omkostninger, kan kalkulationsanalyser fremvise bundelinjeeffekter idet omkostningen réelt kan falde bort. Kendetegnet for de fordelte indirekte omkostninger i en ABC-model er derved, at de indirekte omkostninger ikke kommer til eller falder bort i samme takt som aktivitetsniveauet ændres i virksomheden. Kritikkerne af ABCmodellen vil derfor hævde, at modellen ikke kan anvendes som en driftsøkonomisk beslutningsmodel. Kaplan & Atkinson(1998) mener, at ABC skal kombineres med kapacitetsledelse for at opnå resultater med modellen. 36 Opfattelsen fra kritikkerne af ABC er således den, at de kapacitetsomkostninger, der indgår i kalkulationer kun må tilregnes omkostningsobjekter i de tilfælde hvor de varierer med produktionens størrelse. 37 En omkostning falder således ikke bort i et ABC-regnskab blot fordi det underliggende omkostningsobjekt bliver fjernet fra produktsortimentet. En forudsætning for anvendelse af ABC-modellen er yderligere, at de omkostningsobjekter, der ønskes analyseret i modellen, bør trække forskelligt på de indirekte omkostninger. Hvis de således ikke trækker forskelligt forsvinder formålet med at estimere et omkostningsforbrug. Et eksempel på dette kan være en maskine, der sætter kapsler på glasflasker, hvor der er sodavand i. Det ændrer ikke på omkostningstrækket hvorvidt indholdet(produktet) i flaskerne er cola, hindbær eller squash, da maskinen skal udføre samme bevægelse på samme tid ved samtlige flasker. I denne sammenhæng kan der derfor anvendes en mindre kompliceret omkostningsfordelingsmodel. Et andet kritikpunkt anført mod ABC er, at fordelingen af omkostningerne kan have visse fejl, som belyses via begreberne specifikationsfejl, aggressionsfejl samt målingsfejl. Antallet af aktiviteter i ABC-modellen har indflydelse på de nævnte fejl. Førstnævnte specifikationsfejl relaterer sig til problematikken vedrørende valget af costdrivere. 3 Bukh & Israelsen(04) s Kaplan og Atkinson(1998) s Bukh & Israelsen(04) s. 33

22 1 Næstkommende fejl, aggressionsfejl, relaterer sig til aggregeringen af ressourcepuljer og aktiviteter, hvor aggregeringerne ikke er retvisende for det træk, som omkostningsobjektet réelt trækker på ressourcen. Målingsfejl behæfter sig ved, at omkostningsobjekterne kan trække forskelligt, hvorfor en bredere aktivitetsdefinering skal finde sted. En aktivitet som salg kan således opsplittes i flere underaktiviteter for, at det réelle træk bliver belyst i fordelingen. Til denne bredere aktivitetsdefinering af ABC-modellen opstår der dog nye målingsfejl, idet en kompleks model medfører fejlmåling i beregningen af costdriverne. Cases har endvidere vist, at IT-systemer ikke har kunnet håndtere store komplekse ABC-modeller. 38 Til forsvar for generelle kritikpunkter anført mod ABC nævner Kaplan, at pointen med ABC ikke er, at det skal være en allokeringsmodel, men en estimationsmodel. 39 Et yderligere punkt, som er fremført mod ABC og andre full-cost modeller er, at en nedgang i produktionen, og derved også salget, medfører, at færre omkostningsobjekter tillægges en større mængde af de indirekte omkostninger. Dette er den såkaldte dødsspiral 40 og relaterer sig til, at en ABC-model i nedgangstider eksempelvis signalerer højere priser i tilbudsgivningssituationen, idet den uændrede kapacitetsomkostningsmasse per omkostningsobjekt indregnes. Metoden for at undgå problemet kan være at definere en ledig kapacitet og derved føre omkostninger, der er forbundet med den ledige kapacitet, udenom omkostningsobjekterne. I praksis er det dog vanskeligt at gennemføre. 41 I næste afsnit vil der vurderes hvorledes Madsens variabilitetsprincip kan integreres med ABC til en registrerings- og efterfølgende rapporteringsmodel. 38 Kaplan & Anderson(08) s Kaplan(1992) s Bukh & Israelsen(04) s Bukh & Israelsen(04) s. 8 21

23 6. Variabilitetsprincippet og ABC I henhold til opgaveformuleringen vil dette afsnit se på, hvad der skal til, for at variabilitetsprincippet og ABC kan interagere med hinanden som henholdsvis registrerings- og rapporteringsteknik. Afsnittet vil belyse de steder, hvor der er uoverensstemmelser imellem de to modeller for dermed at konkretisere, hvad der skal gøres for, at overgangen er mulig. Nogle af disse problemstillinger vil blive uddybet på de kommende sider. Direkte og indirekte omkostninger Manglende indtægter Manglende mængder 1 2 Designvalg af løsningsforslaget fra et økonomistyringsperspektiv 6.1 Direkte og indirekte omkostninger I Vagn Madsens oprindelige variabilitetsprincip blev omkostninger set som direkte i forhold til variabilitetsfaktoren, hvorimod ABC har en opdeling mellem direkte og indirekte omkostninger i forhold til kalkulationsobjekterne. Variabilitetsprincippet fordeler omkostningerne på art, sted og formål. Det vil sige, at omkostningerne kun fordeles direkte på et produktformål, når de med sikkerhed kan allokeres til et enkelt produkt. Variabilitetsprincippet fører således kun omkostningerne ned til produkterne, når omkostningerne varierer i takt med variabilitetsfaktoren, produkter, da det grundlæggende i Madsens variabilitetsprincip er at undgå en arbitrær fordeling af omkostningerne, jævnfør 4.1. De direkte omkostninger i ABC-modellen går ligesom i variabilitetsprincippet således direkte til objekterne, mens de indirekte fordeles i ressourcepuljer og derefter fordeles via costdrivere ned til de enkelte objekter. Således vil arbejdskraft, der direkte kan spores til et enkelt omkostningsobjekt være en direkte omkostning, hvorimod arbejdskraft, der udfører opgaver for flere omkostningsobjekter, vil være en indirekte omkostning. Til denne fremstilling kan der således siges, at variabilitetsprincippet kun indeholder direkte omkostninger, hvorimod ABC indeholder både direkte og indirekte omkostninger. De indirekte omkostninger i ABC-modellen opstår således først når omkostninger fra overliggende niveauer i Madsens variabilitetsprincip via den aktivitetsbaserede omkostningsfordelingsmodel skal fordeles til underliggende niveauer Manglende indtægter Når ABC i rapporteringsøjemed skal anvendes til for eksempel lønsomhedsberegning, er det nødvendigt, at modellen medtager indtægter. Som tidligere skrevet i afsnit 4.2 medtager variabilitetsprincippet ikke indtægter, da det udelukkende er et omkostningsregnskab. Disse indtægter medtager Vagn Madsen via finans- 22

24 regnskabet og har dem derfor ikke direkte medtaget i variabilitetsregnskabet, der omtales klasse 6, 7 og 8 i hans klassificeringer. Ønskes indtægterne inddraget i udtrækkene via ABC, er det derfor nødvendigt, at der tilknyttes nogle dimensioner, som også behandler indtægterne i forbindelse med registreringen. Sker dette ikke, er det ikke muligt at foretage visse beregninger, og ABC-rapporteringen udnytter dermed ikke sit fulde potentiale. Der er i modul 1 afgrænset fra indtægtsregistrering, hvorfor en lønsomhedsberegning på baggrund af variabilitetsprincippet og ABC må beregnes på baggrund af statiske listepriser Manglende mængder Endnu en væsentlig forskel på variabilitetsprincippet og ABC er, at variabilitetsprincippet ikke lægger op til en registrering af en omkostnings mængdeside i variabilitetsregnskabet, hvorimod ABC-modellen kan inddrage mængder. Løsningen herpå er, at tilføje en yderlige registrering af mængden i forbindelse med registrering af pris for dermed at tilknytte mængdedimensionen. Når denne er tilknyttet, er det dermed muligt at lave kalkulationer, hvor årsagssammenhængene også kan bedømmes på mængder. Problemet med manglende mængder i variabilitetsprincippet i forhold til ABC er, at det ikke vil være muligt at definere omkostningstrækket per produceret enhed, hvis antallet af producerede styk af et givet produkt ikke er registreret. Det vil endvidere være vanskeligt, at definere en aktivitets kapacitet, hvis den forbrugte mængde af kapaciteten er ukendt. Det vil derfor heller ikke være muligt at angive den ledige kapacitet. 6.4 Designvalg af løsningsforslaget fra et økonomistyringsperspektiv I Madsens fremførte grundregistreringer er fokus på arts-, steds- og formålsdimensionen. Disse dimensioner skal således lægge til grund for de analyser, som en virksomhed efterfølgende ville kunne ønske. 42 Madsens registreringer skal være objektive og ikke indeholde arbitrære fordelinger. Registreringen foretages således på det laveste niveau, som en ikke-arbitrær fordeling tillader. Kan omkostningen således ikke klassificeres direkte på en konto, må den tilregnes et overliggende niveau. I rapporteringssammenhæng vil ABC-udtræk således være en fordeling af de indirekte omkostninger i forhold til kalkulationsobjekterne. Når ABC integreres med registreringer fra variabilitetsprincippet skal der således tages stilling til begreberne indirekte omkostninger og direkte omkostninger i de to modeller, samt tages stilling til en opbygning af variabilitetsprincippets kontoplaner. Designfasen for at anvende ABCrapportering på variabilitetsprincippets registreringer vil således beskrives i fem trin. 43 Designvalg 1: Fastlæggelse af kalkulationsobjekter Designvalg 2: Fastlæggelse af aktiviteter i ABC-modellen 42 Madsen(191) s Designmodellen er konstrueret efter inspiration af Wiese(06) s. 408 samt Bukh & Israelsen(04) s

25 Designvalg 3: Henføring af omkostninger fra Madsens registreringer til aktiviteter Designvalg 4: Fastlæggelse af aktivitetsdrivere og deres satser Designvalg : Henføring af omkostninger til kalkulationsobjekter Designfase 1 Her fastlægges, hvilket kalkulationsobjekt analysen har fokus på. I dette tilfælde drejer det sig om et pro- dukt. Designfase 2 Efter at have fastsat, hvilket kalkulationsobjekt, analysen har fokus på, skal der fastlægges, hvilke aktiviteter kalkulationsobjektet trækker på. 1 2 Designfase 3 Denne fase vil blive uddybet, idet der i denne fase skal skabes en integration mellem Madsens variabilitetsprincip og ABC-rapporteringen. Hvis registreringer i en virksomhed (i nogle brancher) er udført meget detaljeret, vil andelen af indirekte omkostninger til et omkostningsobjekt ikke være stor. I sådan et tilfælde vil ABC-modellen sandsynligvis ikke tilføre væsentlig ny information, da omkostningerne på flere omkostningsobjekter allerede er registreret direkte i forhold til objekterne. 44 Men ABC-modellen kommer til sin ret i de tilfælde, hvor en tilstrækkelig stor andel af variabilitetsprincippets registreringer ikke er direkte i forhold til et konkret kalkulationsobjekt, der ønskes analyseret. I kalkulationsanalyser kan ABC-modellen således fordele omkostninger fra øvre hierarkier i grundregnskabet til lavere liggende hierarkier via den aktivitetsbaserede fordelingsmetode. Er virksomhedens registreringsgrundlag således opbygget med, at medarbejder 1 og medarbejder 2 s handlinger er registreret via et løbende timeforbrug, opnås en direkte henføring fra ressource til objekt. 4 Dette kan være tilfældet for virksomheder i rådgivnings- og IT-branchen. 46 Artsinddelingen, som i sådanne tilfælde er lang og indeholdende et utal af konti, vil tilmed indeholde handlingsregistreringer eller aktivitetsregistreringer. Værdiansættelsen af aktiviteten vil dermed fremgå direkte af selve registreringerne. Aktiviteter i artsdimensionen På baggrund af Madsens(191, side 37) fremførte eksempel, kan det siges, at arter kan være beskrevet så konkret, at de kan overføres direkte til aktiviteter i et ABC-system. I de tilfælde, hvor arterne er beskrevet konkret i forhold til en aktivitet kan der dermed ske en henføring af omkostningen direkte fra registrerin- 44 Bukh & Israelsen(04) s Bukh & Israelsen(04) s Bukh & Israelsen(04) s

26 gen til aktiviteten i ABC-modellen. Omkostningsarterne vil således være sambestemt direkte i forhold til aktiviteten. 47 Madsen fremfører således eksempler på kogning og transport af materialer som eksempler på artsdefinitioner. Anvendelsen af en minutiøs måling og timeregistrering i variabilitetsprincippet medfører således, at visse omkostninger kan henføres direkte til aktiviteter i ABC-modellen, hvis de konkrete aktiviteter fremgår af aktiviteterne i designfase 2. Forskellige rapporteringsformål Kan en omkostning ikke direkte relateres til et produktformål, og dermed ikke er direkte til omkostningsobjektet, vil omkostningen tilregnes et overliggende niveau. Herved opstår de indirekte omkostninger, som er indirekte i forhold til analysens kalkulationsobjekt. Nedenstående figur illustrerer tankegangen og udbygger fremstillingen med inddragelse af de omkostninger, der kaldes fællesomkostninger i et ABC-regnskab. Figur 4: Registreringsmodel efter variabilitetsprincippet Omkostningsarter Udsnit af Stedssiden Udsnit af Formålssiden 700 Hele virksomheden 800 Hele virksomheden (administration og fællesformål) 740 Hjælpeafdeling 8 Produktionsformål 7 Produktion 830 Produktformål 711 Afd Afd Produkt A Produkt B Produkt C 640 Løn - Ingeniør Løn - Ingeniør Løn - Ingeniør Kilde: Egen tilvirkning med inspiration af Madsen(191) s. 40 og 47 1 Eksemplet med registreringer i grundregnskabet er anvist i ovenstående figur. Summen af art, sted og formål skal her være ens i den samme periode. 48 De kr. fra grundregnskabet kan tilregnes omkostningsobjekterne i ABC-modellen direkte, når der er fokus på et produkt. Omkostningerne på et højere niveau, de kr. i produktionsformålsklassen, er sambestemte indirekte omkostninger i forhold til de aktiviteter, der er defineret i ABC-modellen. Registreringsposten kan indeholde lønninger til ingeniører, der foretager serierelateret aktivitet, såsom omstilling og inspektion. Af formålstabellen kan endvidere læses de eventuelle omkostninger, som benævnes fællesomkostninger, idet disse ikke har et specifikt formål udover at bevare virksomheden. Omkostningen til en renoveringsberegning på.000 kr. er et eksempel på en omkostning, der skal placeres i en klasse under formålsdimensionen. Omkostningerne i denne klasse skal ikke fordeles, idet de efter ABC-terminologi er virksomhedsbevarende Bukh & Israelsen(04) s Israelsen i Warming-Rasmussen(1989) s Bukh & Israelsen(04) s. 74 2

27 De angivne registreringsposter fra variabilitetsprincippet fra figur 4 kan integreres med Kaplans hierarkiske model, der kan anvendes til at klassificere hvilke omkostninger, der ikke burde fordeles til omkostningsobjektet. 1 Fra Madsens registreringer til værdiansættelse af aktiviteter ABC-modellen kræver, at virksomhedens aktiviteter bliver værdiansat. Til dette kan artstabellen blive anvendt for en videre fordeling. Stedstabellen er i denne sammenhæng sigende for, hvor i organisationen forbruget af omkostningen bliver forbrugt. Indføres et ABC-projekt med fokus på udførelsen af bestemte aktiviteter i en konkret afdeling, kan en sådan situation belyses ud fra overstående eksempel anvist i figur 4. I denne sammenhæng, hvor givne ressourcer i afdelingen fordeles, kan idéer fra Israelsen(1989) blive anvendt. 0 Det ene af to følgende forslag til henføring fra grundregnskabet til aktiviteterne tager udgangspunkt i Israelsens(1989) idéer for variabilitetsprincippets anvendelse. 1 Det senere anviste løsningsforslag 2, er en modificering af Bukh og Israelsens udlægning af henføring i afsnit.1. Løsningsforslag 1 Et forslag kan være, at arter i artstabellen ifølge Madsen 2 kan konteres på klasser med numre fra , mens steder skal konteres i stedstabellen i numrene , og til sidst kan formålstabellen konteres med numre fra , som tidligere er beskrevet. Herved kan der således konstrueres en konto for en art, på et sted, i forhold til et formål. Et eksempel er anvist i nedenstående figur: Figur : Registreringstabel Beskrivelse: Art Sted Formål Beløb Mængde Løn til ingeniør timer Løn til ingeniør timer Løn til ingeniør timer Egen tilvirkning med inspiration af Israelsen(1989) s. 190 Disse konti kan således summeres via en krydstabulering 3 for de omkostninger, hvor arts, steds- og formålskonti er ens. Herefter kan de summerede omkostninger viderefordeles til aktiviteter. En IT-integration på dette princip finder gruppen dog vanskelig, hvorfor følgende metode for henføringen af registreringer fra grundregnskabet til ABC-modellen vil blive anvist. 0 Israelsens eksempel er anvist i en sammenhæng, hvor Vagn Madsen variabilitetsprincip forenes med Zakken Worres styringsorienterede registreringsprincip for de variable omkostninger. 1 Israelsen i Warming-Rasmussen(1989) s Madsen(191) s Israelsen i Warming-Rasmussen(1989) s

28 1 2 Løsningsforslag 2 Alternativt kan der fordeles omkostninger alene fra artstabellen til ressourcepuljer ved at aggregere homogene omkostninger til samme ressourcegrupper, hvorefter en fordeling til aktiviteter kan finde sted. I så fald skal de enkelte artsbeskrivelser i artstabellen være tilstrækkelig specificeret, således, at der kan vurderes, hvorvidt den enkelte omkostning er direkte eller indirekte i forhold til analysens kalkulationsobjekt. Efterfølgende vil ressourceomkostningerne viderefordeles via ressourcecostdrivere til aktiviteterne med en estimeret procentsats. Endvidere gælder her udsagnet om, at ressourcepuljer bør have samme grad af homogenitet med hensyn til variabilitet og reversibilitet. 4 Løsningen på dette må være at have en lang række af arter, således at ressourcerne(arterne) med forskellig grader af variabilitet og reversibilitet ikke bliver konteret på samme konti i Madsens artstabel. Eksemplet kan være en nyansat medarbejder og en medarbejder med lang anciennitet, må konteres på forskellige konti, idet reversibiliteten på de to medarbejdere vil være forskellig. Fremgangsmåden kræver dog vurderingsmæssigt en meget lang kontostreng, der i registreringssammenhæng vil være meget omfattende. Det endelige løsningsforslag for henføringer fra variabilitetsprincippet til rapporteringen med ABCmodellen ud fra de to angivende løsningsforslag anvises dog først endeligt i afrapporteringsafsnittet, hvor en mulig metodefremgang via den relationelle database kan forklares. Løsningsforslaget for henføringen indeholder herved dele fra to fagområder, der i metodeafsnittet er angivet til at blive inddraget i den mængde, der findes relevant. Løsningsforslaget kan derfor ikke beskrives før den teoretiske relationelle databasestruktur er belyst. Dette vil ske i de næstkommende hovedafsnit. Designfase 4 og I designfase 4 sker der således en fastlæggelse af aktivitetscostdrivere samt satsfastlæggelse, og i designfase forekommer en henføring fra aktiviteterne til kalkulationsobjekterne. Variabilitetsprincippet er ikke skrevet i samme periode, som Kaplan og Cooper anfører deres idéer for den aktivitetsbaserede omkostningsfordeling, og desuden ligger kalkulationsopgaven udenfor, hvad Madsen anser for variabilitetsprincippets domæne. I spørgsmålet om at fordele omkostninger fra aktiviteterne lader ingen af Madsens tanker sig således anvendes. Her bliver Kaplan og Coopers fremførte metoder for fordelingen via aktivitetscostdri- 4 Bukh & Israelsen(04) s Madsen(1969) s

29 vere foretaget. 6 Registreringer for transaktionsdrivere, varighedsdrivere eller direkte målinger bør dog udtrækkes fra et registreringsgrundlag, der opfanger sådanne data i den konkrete organisation. 6. Opsamling I dette afsnit er områder indenfor en mulig integration af variabilitetsprincippet, og en efterfølgende rapportering med ABC-modellen blevet vurderet. Fokus for opgaven er i denne sammenhæng, at løsningsforslaget bør have fokus på en rapportering på et produkt. En sådan rapportering kan ske via en lønsomhedskalkulation, hvor indtægtsregistreringer skal forelægge. I afsnittet er begreberne indirekte og direkte omkostninger blevet vurderet i de to modeller, ligesom mængde- og indtægtsregistreringens betydning ligeledes er. Afsluttende blev et designvalg fra et økonomistyringsperspektiv beskrevet. I næstkommende afsnit vil den informatikmæssige teoretiske del blive beskrevet via en case, hvorefter det afsluttende løsningsforslag vil fremgå af afsnittet, afrapporteringen. 6 Kaplan & Cooper(1998) s

30 7. Informatik I dette afsnit vil vigtige elementer i relationsdatabasen blive belyst med henblik på senere udvikling af databasestruktur til registrering og afrapportering. Først belyses relationsdatabasens grundelementer, hvorefter forespørgselssproget SQL behandles. Endvidere belyses begreberne E/R diagram, integritet og normalformer, der er centrale elementer i databasestrukturen. Dette vil ske via en fiktiv case, kaldet Solipstolid, hvorigennem løsningsforlaget for registreringsopbygningen og afrapporteringen vil blive behandlet. Den informatikmæssige teori vil således blive belyst direkte gennem casen. Afsluttende vil fremgå et afrapporteringsafsnit der fremviser løsningsresultatet gennem programmet Application Express Relationsdatabaser Det første databasestyresystem, der blev udviklet var IMS, og det var en hierarkisk database. Den blev konstrueret således, at databasens sprog var i overensstemmelse med organiseringen af de fysiske data. 7 IMS blev opbygget på en struktur, der bliver betegnet som en hierarkisk- eller træstruktur. Med det menes, at datamængderne i den hierarkiske databasestruktur bliver formaliseret i et over/-underordningsforhold, som afspejler strukturen i virkeligheden. Da IMS er konstrueret efter organiseringen af de fysiske eksisterende data, har det medført problemer hver gang, der er blevet ændret på virksomhedens fysiske datastruktur. Det har udgjort et så stort problem, at der er arbejdet på at adskille det fysiske og logiske niveau. Der blev fremsat nogle tiltag, der skabte en vis uafhængighed mellem det fysiske og logiske niveau. I et forsøg på at adskille det fysiske og logiske niveau blev der udviklet en ny database; relationsdatabasen. 8 Databasen består af en model, der er delt op i fire niveauer, hvoraf det nederste niveau er den fysiske database, mens de tre øverste dele er den logiske database. De tre dele(schemaer) svarer til forskellige brugeres syn på databasen og består af det interne, det conceptuelle og det eksterne schema. Den fysiske database er i denne sammenhæng ikke så interessant, da idéen med denne model er, at der er et skel mellem det fysiske og logisk niveau, dog er skellet ikke større end, at der stadig er en forbindelse. Det nederste del af det logiske niveau, det interne schema, er bindeleddet over til det fysiske niveau og vil være en beskrivelse af tabeldefinitionen, hvordan data skal lagres, og hvilke indeks der findes. Det conseptuelle schema beskriver blandt andet elementer som databasens struktur, tabeller, kolonner, datatyper, primærnøgler, fremmednøgler, der vil blive belyst senere. Denne del kan siges, at repræsentere hele databasen og er typisk databaseadministrationens arbejdsområde. Den øverste del af databasemodellen, det 7 Vang(01) s Vang(01) s. 29

31 eksterne schema beskriver hvorledes en database kan betragtes. 9 Det er grænsefladen til brugerne, om det så er programmøren eller lagermedarbejderen, der skal anvende systemet. I og med, at de forskellige brugere skal se forskellige dele af databasen, er der oprettet skemaer nok til at opfylde de enkelte brugeres behov Structured Query Language Til relationsdatabasen skulle der udvikles et forespørgselssprog, der kunne kommunikere med den relationelle databasestruktur og samtidigt være brugervenligt, da det skulle kunne anvendes af andre end professionelle programmører. 60 Det endte med at blive SQL. Det er et program, der hele tiden bliver opdateret og videreudviklet, så det passer til de tidssvarende standarder. SQL anvendes til at kommunikere med databaser. Det kan udtrække og sammensætte data i tabeller og trække data mellem tabeller. SQL er et forespørgselssprog, der kan anvendes sammen med den relationelle databasestruktur. 61 Gennem SQL er det derfor muligt at udføre alle de handlinger, som er nødvendige for at relationsdatabasen kan eksistere og fungere. Her tænkes eksempelvis på kommandoerne CREATE, som er en del af SQL-sproginddelingen, DDL. 62 SQL kan således inddeles i flere delsprog, hvor DDL er sigende for Data Definition Language, som er sprog der opretter tabelstrukturer i databasen. En anden inddeling af SQL er DML, der står for Data Manipulation Language, som blandt andet er indsættelse og udtræk af data via kommandoerne INSERT og SE- LECT. Uden disse ville databasestrukturen ikke kunne udarbejdes. I det efterfølgende vil casen for projektet blive beskrevet. 9 Vang(01) s Vang(01) s Vang(01) s Vang(01) s

32 8. Case: Solipstoid 1 I det følgende vil casen vedrørende den fiktive virksomhed, Solipstoid, blive gennemgået. I forbindelse med Casen vil begreberne integritet og normalform inddrages, og det er således formålet med casen at forklare databaseteori. Da formålet er at inddrage databaseteori, udformes casen sådan, at tillærte SQL kundskaber bringes i brug herunder oprettelse og ændring af tabeller, samt oprettelse og brug af views. Først beskrives virksomheden Solipstoid, hvorefter en databasestruktur til registrering gennem variabilitetsprincippet og en afrapportering ved ABC konstrueres for virksomheden. Denne struktur forklares ligeledes. Solipstoid er en klassisk produktionsvirksomhed, som gennem en relativ enkel produktionsproces laver emner i hård plastik. Disse emner benyttes i videreforarbejdning i andre virksomheder, hvorfor virksomheden er en leverandørvirksomhed på B2B-markedet. Solipstoid producerer for tiden tre forskellige produkter; Dippedut, Mini og Spezial. Spezial er det seneste produkt, som Solipstoid er begyndt at producere, men efter en intens markedsføring af produktet gennem markedsføringsfirmaet M4U er ordrerne udeblevet. Solipstoids konkurrent indenfor samme marked har dog ingen problemer med at få solgt sine tilsvarende produkter, og samtidig kan Solipstoids produktion ikke følge med i produktionen af Dippedut og Mini på grund af en stigende efterspørgsel. Det er disse forhold, som har fået ledelsen i Solipstoid til at implementere en databasestruktur der kan afrapportere på ABC. Solipstoids organisation er en funktionsopdelt organisation, hvor virksomhedens ledelse er det øverste niveau, og alle større beslutninger går gennem ledelsen. Herunder findes der tre separate afdelinger med hvert sit funktionsområde. Dette er en administrationsafdeling, en produktionsafdeling og en salgsafdeling. Figur 6: Organisationsdiagram over Solipstoid Kilde: Egen tilvirkning 31

33 Af organisationsdiagrammet kan det ses, at salgsafdelingen er opdelt i en tysk og en dansk afdeling, som står for salg til hvert sit område. Herudover står administrationsafdelingen for alle praktiske opgaver, som bogføring og ansættelse samt afskedigelse af personale. I produktionsafdelingen gennemgår de forskellige produkter nogle forskellige processer, som kort beskrives i det følgende. Den første proces i produktionen er en formgivning af produkterne, hvilket sker ved hjælp af en maskine. Formgivningen er således en automatiseret proces, hvor produkterne trykkes i en maskine, og efterfølgende viderebehandles produkterne i produktionsafdelingen manuelt, i det omfang dette er nødvendigt. Efter denne proces bliver alle produkter renset, før de pakkes og sendes ud til kunderne. Virksomhedens kontoplan ser derfor således ud opdelt efter variabilitetsprincippet: 1 Omkostningsarter Løn til ledelsen Administrationsløn 600 Produktionsløn 600 Salgsløn Ingeniørløn Materialeforbrug 6000 Plastik 60 Sæbe 60 Pap 6300 Diverse 6400 Salgsfremmende omkostninger Figur 7: Kontoplan i Solipstoid Stedshierarki Hele virksomheden Administration 700 Produktion Salg Tyskland 770 Danmark 770 Formålshierarki Virksomhedens ledelse Administrationsformål 800 Produktionsformål Dippedut 840 Mini 840 Spezial Salgsformål Kilde: Egen tilvirkning Da der vil blive registreret efter variabilitetsprincippet er kontonumrene og opdelingen foretaget efter variabilitetsregnskabets klassifikationer Se afsnit om variabilitetsprincippet, afsnit 4.1. Da Solipstoid ønsker en afrapportering på produkterne er disse specificeret som rapporteringsobjekter, hvorfor aktiviteterne skal specificeres hertil, jævnfør designfase 1 og 2 i afsnit.4. I produktionsafdelingen har virksomheden afdækket tre hovedaktiviteter formgivning, rensning og pakning. Ydermere er ledelse en aktivitet, som indgår i administrationsafdelingen. Det vil derfor være en fordeling af trækket på disse aktiviteter, som igen skal allokeres til rapporteringsobjekterne. Inddelingen i ressourcepuljer sker i dette tilfælde direkte i relati- 32

34 on til omkostningsarterne. Det vil sige, at en artskonto også bliver en ressourcepulje. Dette skyldes, at omkostningsfordelingen til ressourcepuljer skal ske med omkostninger, som har tilnærmelsesvis samme grad af variabilitet og reversibilitet. For at undgå en inddeling, hvor omkostningerne réelt fordeles med forkerte satser ned på aktiviteterne gøres dette. Fremgangsmåden fremsætter således, at der ingen gruppering af artskonti finder sted, som er en modifikation af Bukh og Israelsens fremføring. Argumentationen for denne fremgangsmetode er den, at få artskonti ville indeholde samme grad af variabilitet og reversibilitet og derved vil grupperinger af arter til ressourcepuljer ikke finde sted. På denne baggrund er der nu udarbejdet en databasestruktur, der skal sikre en afrapportering på ABC Entitets-Relations diagram Et Entitets-Relations diagram(e/r diagram) består af entiteter, attributter og relationer. 63 Entitet er det objekt eller tabel, der skal registreres data i, mens attributterne er de elementer, der beskriver entiteterne. Endvidere beskriver relationen forholdet mellem entiteterne. I det følgende knyttes der således en kort kommentar til det udarbejdede E/R diagram for Solipstoid - Se bilag 1: E/R diagram. Hovedtabellen hedder S_REGISTRERING, og her registreres omkostningsforbruget i Solipstoid. Idet der registreres efter variabilitetsprincippet er S_REGISTRERING kædet sammen med en arts-, sted- og formålstabel gennem fremmednøglerne FK_ART_NAVN, FK_STED_NAVN og FK_FORMAAL_NAVN. Selve ABCrapporteringen foregår gennem views, men for at dette lader sig gøre, er det nødvendigt med en række ABC-data i designet. Dette er praktisk gjort ved at kæde ABC-strukturen på artstabellen. Der er kædet en fremmednøgleattribut, FK_RES_ID, på artstabellen, så hver artskonto kædes sammen med en tilsvarende primærnøgleværdi i S_RESSOURCEPULJER. Ved denne struktur vil det efterfølgende være muligt at fordele flere omkostningsarter til samme ressourcepuljer, hvis dette senere hen ønskes. Da der eksisterer mangetil-mange-relationer mellem ressourcepuljerne og aktiviteterne samt mellem aktiviteterne og omkostningsobjekterne, må der her laves mellemtabeller for, at allokeringen kan finde sted. En mange-til-mangerelation betyder, at en ressource kan allokeres til flere aktiviteter, og at en aktivitet kan trække på flere ressourcer - der er altså flere værdier tilknyttet en primærnøgleværdi. Det samme forhold gør sig gældende mellem aktiviteterne og omkostningsobjekterne. Mellemtabellerne hedder S_RES_SATS_AKT og S_AKT_CD_OMKOB, hvor S_RES_SATS_AKT er mellemtabellen mellem ressourcepuljerne og aktiviteterne, og S_AKT_CD_OMKOB er mellemtabellen mellem aktiviteterne og omkostningsobjekterne. Disse mellemtabeller løser mange-til-mange-relationerne ved brug af én-til-mange-relationer. Udover mellemtabellerne er ABC-hierarkimodellen kædet på aktiviteterne ved en fremmednøgleattribut, FK_HIERARKI, der refererer 63 Vang(01) s. 3 33

35 til S_HIERARKIER, der er en hierarkitabel. Hver aktivitet bliver derfor defineret efter, hvilket hierarki den vedrører I det følgende vil begreberne integritet og normalformer blive inddraget. Disse begreber inddrages, da databasestrukturens funktionalitet er afhængig af, at begge dele eksisterer. Begreberne forklares derfor ud fra E/R diagrammet for virksomheden Solipstoid. Integritet En databases tabeller kan ikke fungere uden brug af integritet. Integritet vedrører både den enkelte tabel og tabellerne i mellem. Ved brud på integriteten kan en database således ikke fungere optimalt, eller værre endnu, den kan slet ikke opfylde de formål, som den er konstrueret til. Grundlæggende findes der tre typer af integritet; entitetsintegritet, referentiel integritet og semantisk integritet - og disse vil blive gennemgået i det følgende. Entitetsintegritet For at en tabel skal kunne oprettes og bruges, er det et krav, at der oprettes en primærnøgle. Ved at oprette en unik primærnøgle sikres det, at alle enkeltelementer indenfor en entitet er identificerbare. 64 Dette ses eksempelvis i S_REGISTRERING, hvor hver registrering kan identificeres ud fra et unikt registreringsnum- mer, SK_REG_ID, som er fortløbende med en sequence. Hermed sikres det, at hvert nummer i PK_REG_ID er unikt. Hver primærnøgleværdi skal på denne måde referere til specifikke attributværdier indenfor den enkelte entitet (hvor nogle dog er primærnøgleværdier fra andre tabeller). Primærnøglen bliver således determinant for de andre attributter. Det er derfor også kun muligt at oprette en primærnøgle til hver tabel. Rent praktisk oprettes en primærnøgle ved hjælp af DDL på følgende måde: CREATE TABLE S_REGISTRERING (SK_REG_ID NUMBER NOT NULL PRIMARY KEY, REG_TEXT VARCHAR2 (0), DATO DATE, BELOB NUMBER NOT NULL, MAENGDE NUMBER, FK_ENHED NUMBER REFERENCES S_ENHEDER (PK_ENHEDS_ID), FK_ART_NAVN VARCHAR2 (0) NOT NULL REFERENCES S_ART (PK_ART_NAVN), FK_STED_NAVN VARCHAR2 (0) NOT NULL REFERENCES S_STED (PK_STED_NAVN), FK_FORMAAL_NAVN VARCHAR2 (0) NOT NULL 64 Vang(01) s

36 REFERENCES S_FORMAAL (PK_FORMAAL_NAVN)); SK_REG_ID bliver primærnøgle i tabellen. Ved at skrive PRIMARY KEY efter kolonnenavnet, som vist, bliver det automatisk primærnøglen. Tilsvarende fremgangsmåde er ligeledes benyttet ved oprettelsen af primærnøgler i alle andre tabeller. Til hver art, sted og formål eksisterer der eksempelvis således kun en værdi, som refererer til arten, stedet eller formålet - i dette tilfælde er denne værdi et navn, altså bogstaver. NOT NULL tilføjes kolonnerne, fordi foruden benævnelsen kan SK_REG_ID eksempelvis antage værdien NULL, hvilket betyder, at det ikke nødvendig, at angive en værdi ved indtastning af data i tabellen. Dette vil være uheldigt, da der dermed kan være flere posteringer med NULL, hvorfor identificeringen af de enkelte poster ikke vil være entydigt. Entitetsintegriteten vil i sådan et tilfælde derfor ikke være overholdt. Som tidligere nævnt er primærnøglerne i arts-, steds- og formålstabellen af typen VARCHAR2, hvilket skyldes, at der ikke kan oprettes flere poster med samme navn. Hvis kontonummeret havde været brugt som primærnøgle, ville det således have været muligt, at have flere kontonumre med ens navne. Referentiel integritet Den referentielle integritet skal sikre relationerne mellem tabeller. Dette gøres ved at kæde fremmednøgler og primærnøgler sammen. Det er således integriteten mellem tabellerne, som den referentielle integri- tet henviser til. 6 For at referentiel integritet kan eksistere, er tilstedeværelsen af fremmednøgler nødvendig. Dette skyldes, at den referentielle integritet, som nævnt, består mellem fremmednøgler og primærnøgler. Hvor en tabel kun kan have en primærnøgle, kan flere attributter godt være fremmednøgler. Dette forhold skyldes, at tabellerne kan referere til mere end en tabel. Dette ses eksemplificeret i bilag 1 for tabellen S_registrering, hvor der er én primærnøgle og fire fremmednøgler. En fremmednøgle kan modsat primær- nøglen ligeledes godt antage værdien NULL, idet en indtastning i denne attribut ikke altid vil være nødvendig i forhold til entitetens primærnøgle. Arts-, sted-, og formålstabellen er konstrueret til at referere til registreringstabellen, men samtidig sættes der en fremmednøgle på en parent i hver tabel. Parentattributten er lavet for at kunne konstruere et rekursivt hierarki indenfor tabellerne. I artstabellen kan der ved brug af parenten dermed laves et hierarki i ar- terne. Løn kan således være parent for ferieløn, overtidsbetaling og lignende. Det rekursive hierarki, også kaldet et parent-child hierarki, er således et naturligt hierarki indenfor den pågældende tabel. Da fremmednøglen, FK_ART_PARENT, refererer til primærnøglen i sin egen tabel, kan der ikke umiddelbart oprettes en fremmednøgle. Denne må tilføjes efter tabellen er konstrueret med en ALTER TABLE kommando. For artstabellen ser denne kommando således ud: 6 Vang(01) s. 13 3

37 ALTER TABLE s_art ADD CONSTRAINT con_fk_art_parent FOREIGN KEY (fk_art_parent) REFERENCE s_art (pk_art_navn); 1 Der er nu tilføjet en fremmednøgle til tabellen art. Denne fremmednøgleattribut hedder FK_ART_PARENT og refererer til PK_ART_NAVN. Da parenten ikke kan antage værdien NULL, skal der således angives en værdi i parenten. Den tidligere SQL-kode for S_REGISTRERING viser, hvordan fremmednøglerne til arts-, steds- og formålstabellen er oprettet. Her er det blot nødvendigt at skrive, hvilke tabeller attributterne skal referere til. Herefter oprettes fremmednøglerne automatisk. Semantisk integritet Den sidste type af integritet, semantisk integritet, refererer til integriteten af de enkelte attributter. Den semantiske integritet vedrører således betydningen af dataene i de enkelte attributter. Dette forhold spiller naturligvis også ind på den referentielle integritet, i det omfang at der ikke er semantisk integritet i en fremmednøgle. 66 I dette tilfælde vil det ikke være muligt at referere til primærnøglen. I ovenstående kan FK_ART_NAVN således ikke refereres til artstabellen med et nummer, men der skal derimod angives et navn, da primærnøgleværdien i artstabellen, PK_ART_NAVN, er af datatypen VARCHAR Normalformer Normaliseringen af tabeller afhænger af, hvilken normalform der bruges. I denne henseende findes der seks normalformer, hvor 1. normalform er den mest grundlæggende. Normalformer bruges til at få alle attributter, som ikke er en del af primærnøglen, til at afhænge af primærnøglen. 67 I det følgende vil de første tre normalformer blive gennemgået i og med, at disse er hyppigst forekomne. 1. normalform At en tabel er på 1. normalform vil sige, at der eksisterer én primærnøgle, og at der ikke er repeterende grupper. 68 Som tidligere beskrevet er en primærnøgle en entydig identifikation af tabellens data. Som eksemplet ovenfor er SK_REG_ID et godt eksempel på en primærnøgle. Uden denne attribut, vil der i registreringstabellen, i teorien, kunne have været registreringer som er helt ens, hvorfor der ikke vil kunne skelnes mellem disse. Uden SK_REG_ID i registreringstabellen vil der opstå det problem, at der ikke eksisterer en entydig primærnøgle, da alle andre attributter i tabellen sagtens kan forekomme flere gange. Det, at tabellen skal være uden repeterende grupper, betyder blot, at der til en primærnøgleværdi kun må fremkomme en værdi fra de andre attributter, 69 og dette sikres ved at knytte et nummer til hver registrering. Dette vil 66 Vang(01) s Vang(01) s Vang(01) s Vang(01) s

38 sige, at en registrering eksempelvis kun må have én beskrivelse, én dato, ét beløb og så videre. Problemet med repeterende grupper opstår eksempelvis i tilfælde af, at én medarbejder har flere telefonnumre. I sådan et tilfælde må tabellen splittes op i flere tabeller for at undgå flere værdier til samme primærnøgle normalform Efter 1. normalform kan tabellen udvides til ligeledes at gælde på 2. normalform. I dette ligger selvfølgelig, at en tabel på 2. normalform ligeledes er på 1. normalform. Herudover skal alle ikke-nøgleattributter være fuldt funktionelle afhængige af primærnøglen. Dette betyder, at ikke-nøgleattributter ikke kun må være afhængige af en delmængde af primærnøglen. 70 Dette fænomen kan kun eksistere, hvis der er en sammensat primærnøgle. Arts-, sted-, formåls- og registreringstabellen er derfor allerede på 2. normalform. Problematikken eksisterer altså kun i de tilfælde, hvor der er en sammensat primærnøgle, og nogle af entite- tens attributter kun relaterer til en del af primærnøglen. 3. normalform En videre normalisering af tabellen vil blive på 3. normalform. Den 3. normalform bygger, som 2. normalform gjorde, videre på den foregående normalform, hvorfor det er en betingelse for 3. normalform, at tabellen også er på 2. normalform. Herudover skal alle ikke-nøgleattributter være ikke-transitivt afhængige af primærnøglen. Dette vil sige, at alle ikke-nøgleattributter skal være gensidigt uafhængige af primærnøglen. 71 I en tabel hvor primærnøglen ikke er den eneste determinant opstår problematikken. I sådanne situationer må tabellen endnu engang dekomponeres ud i flere tabeller. Et tænkt eksempel kan være, at der i en medarbejdertabel både havde attributter på postnumre og bydele. I en sådan situation vil medarbejdernummer være determinant for postnummer for den pågældende medarbejder, men postnummer vil samti- dig være determinant for bydel, hvorfor tabellen må dekomponeres. I dette tilfælde skal der oprettes en ny postnummertabel med bydel som attribut, der refererer til medarbejdertabellen. 72 Da SK_REG_ID er determinant for alle ikke-nøgleattributter er registreringstabellen på 3. normalform. Dette forhold gør sig ligeledes gældende for arts-, sted- og formålstabellen Vang(01) s Vang(01) s Eksemplet er lånt fra Søren Vang. 37

39 9. Rapportering Efter at have opbygget en databasestruktur kan Solipstoid foretage rapporteringer efter ABC-princippet. Denne rapportering sker gennem brug af views. Disse vil efterfølgende blive forklaret. Grundlaget for at rapportere gennem views er den databasestruktur, der er blevet opbygget gennem E/R diagrammet. Hvis denne databasestruktur ikke var opbygget, kan der ikke afrapporteres. Rapporteringen beror altså på den opbyggede ABC-struktur, der er kædet på artstabellen. Før afrapporteringen vises vil begrebet views blive forklaret. Udover at benytte artstabellen bruges formålstabellen til at henføre de direkte omkostninger til rapporteringsobjektet. Views er ikke tabeller, hvor der kan indtastes data i. Views er derimod, som navnet antyder, visninger af data fra en databases tabeller. Et view er derfor en grænseflade til en database, hvor der sker en adskillelse af den conceptuelle database og den eksterne beskrivelse af databasen. 73 Adskillelsen imellem det conceptuelle schema og eksterne schema er forklaret tidligere i afsnittet, 7.1 Relationsdatabaser. På denne måde indeholder views ikke data, men viser data fra andre tabeller. Views kan således også indeholde data fra flere tabeller. Dette sker ved brugen af joins, hvor tabeller kædes sammen. 74 Sammenkædningen af flere tabeller sker gennem kommandoen WHERE i oprettelsen af viewet. Ved at benytte AND-funktionen kan der sammenkædes flere tabeller. Herudover kan der også oprettes materialiserede views, hvor dataoutputtet oprettes i en tabel. Rapporteringen beror på views med data fra flere tabeller. Idéen bag databasedesignet er, at beløbene og artskontiene kan trækkes fra registreringstabellen, hvorefter det vil være muligt at kæde artskontiene sammen med ressourcepuljerne gennem fremmednøglen i artstabellen. Herefter kædes ressourcepuljerne sammen med aktiviteterne gennem mellemtabellerne, og til sidst fordeles de omkostninger der er tildelt aktiviteterne ud på rapporteringsobjekterne. Herudover vil omkostninger fordelt til aktiviteter med hierarkibenævnelsen virksomhedsbevarende omkostninger ikke blive fordelt ud på rapporteingsobjekter. Dette sker praktisk ved ikke at kæde aktiviteten sammen med et rapporteringsobjekt. Først oprettes der altså et view med ressourcepuljerne. Dette view oprettes med følgende SQL-kode: CREATE VIEW vw_s_respul AS SELECT res_navn, sum(belob) as ressourcebelob FROM s_registrering, s_art, s_ressourcepuljer WHERE s_registrering.fk_art_navn = s_art.pk_art_navn AND s_art.fk_res_id = s_ressourcepuljer.pk_res_id GROUP BY res_navn; 73 Vang(01) s Vang(01) s

40 Ved at selektere res_navn og benytte sumfunktionen over belob fås der et view med ressourcerne og deres summerede beløb. Det kan ses, at der eksisterer fire ressourcepuljer i Solipstoid, hvor produktionsløn udgør den største med kr. Bilag 2 belyser det oprettede view Herefter skal ressourcerne deles ud på aktiviteter, hvilket sker gennem et nyt view. I forhold til ovenstående multipliceres beløbene blot med en driversats, og der tilføjes flere joins for at inddrage aktivitetstabel- len. Aktiviteterne i Solipstoid er formgivning, rensning, pakning og ledelse, hvor ledelse ikke fordeles til produkter som rapporteringsobjekter jævnfør hierarkimodellen. Det kan ses, at formgivning er den største aktivitet med kr. Aktiviteten ledelse udgør et beløb på kr., der altså ikke fordeles på omkostningsobjekterne - se bilag 3. Til at tjekke om de fordelte ressourcer er fordelt med en faktor 1 ned på aktiviteterne oprettes der et view til at tjekke dette. SQL-koden ser således ud: CREATE VIEW vw_s_driversatser AS SELECT res_navn, sum(driversats) FROM s_ressourcepuljer, s_res_sats_akt WHERE s_ressourcepuljer.pk_res_id = s_res_sats_akt.fk_res_id GROUP BY res_navn; Vw_s_driversatser har til formål at tjekke om fordelingen af ressourcer ned på aktiviteter er sket korrekt. I tilfælde af, der bliver en summeret driversats på over 1, må der undersøges, hvorfor fordelingen er mislykkedes og korrigere fejlen. Det kan ses, at ressourcerne er fordelt ned på rapporteringsobjekter korrekt. Se bilag 4. Næste skridt vil være, at fordele de omkostninger der er tildelt aktiviteterne ud på omkostningsobjekter. Der sker altså en fordeling af de indirekte omkostninger i det næste view. Dette sker praktisk ved at dividere ovenstående sum på aktiviteterne med en praktisk kapacitet, der er en attribut i aktivitetstabellen, hvorved et beløb fremkommer for hver gang aktiviteten udføres. Dette kan være antal gange eller timer - det er blot et spørgsmål om defineringen af kapaciteten. Herefter multipliceres dette beløb med den forbrugssats, som rapporteringsobjekterne benytter. Det vil altså sige antal gange eller timeforbrug, der er medgået til produktionen af det enkelte omkostningsforbrug. Denne sats er defineret i mellemtabellen mellem aktiviteterne og rapporteringsobjekterne. Viewet er kodet på følgende måde og fremstår i bilag. CREATE VIEW vw_s_omkobjekter AS SELECT pk_omk_ob_id, omk_ob_navn, sum(((belob*driversats)/praktisk_kap)*sats) as omkostningsforbrug FROM s_aktiviteter, s_registrering, s_res_sats_akt, s_ressourcepuljer, s_art, s_akt_cd_omkob, s_omk_objekt WHERE s_registrering.fk_art_navn = s_art.pk_art_navn 39

41 AND s_ressourcepuljer.pk_res_id = s_art.fk_res_id AND s_ressourcepuljer.pk_res_id = s_res_sats_akt.fk_res_id AND s_aktiviteter.pk_akt_id = s_res_sats_akt.fk_akt_id AND s_aktiviteter.pk_akt_id = s_akt_cd_omkob.fk_akt_id AND s_omk_objekt.pk_omk_ob_id = s_akt_cd_omkob.fk_omk_ob GROUP BY pk_omk_ob_id, omk_ob_navn Det kan ses, at der til produktionen af Spezial og Mini stort set bruges lige mange indirekte omkostninger, idet Spezial og Mini henholdsvis bruger 0.900,32 kr. og ,48 kr. Dippedut adskiller sig med et forbrug på 70.9,21 kr De direkte omkostninger fordeles ikke gennem artstabellen, men tages derimod fra formålstabellen. Dette forhold skyldes, at når formålet i S_REGISTRERING er et produkt, kan den tilsvarende værdi findes som rapporteringsobjekt. Dette betyder, at formålstabellen og omkostningsobjektstabellen kan joines. De direkte omkostninger findes således ved følgende SQL-kode: CREATE VIEW vw_s_direkteomk AS SELECT omk_ob_navn, sum(belob) as "direkte omkostninger" FROM s_registrering, s_formaal, s_omk_objekt WHERE s_registrering.fk_formaal_navn = s_formaal.pk_formaal_navn AND s_formaal.pk_formaal_navn = s_omk_objekt.omk_ob_navn GROUP BY omk_ob_navn Som det kan ses fra bilag 6, er de direkte omkostninger størst for Spezial, hvor de udgør kr. og mindst for Dippedut, hvor de kun udgør kr. De direkte omkostninger er altså dobbelt så store for Spezial i forhold til Dippedut. Herefter er det blot at ligge de indirekte og direkte omkostninger sammen for at finde det samlede omkostningstræk fra rapporteringsobjekternes - se bilag 7. Bemærk at det ikke her er nødvendigt med et GROUP BY udtryk, hvilket skyldes, at der ikke er brugt en sumfunktion. Dette view ser således ud: CREATE VIEW vw_s_samledeomk AS SELECT s_omk_objekt.omk_ob_navn, omkostningsforbrug+"direkte omkostninger" as "Samlede omkostninger" FROM s_omk_objekt, vw_s_omkobjekter, vw_s_direkteomk WHERE s_omk_objekt.omk_ob_navn = vw_s_omkobjekter.omk_ob_navn AND s_omk_objekt.omk_ob_navn = vw_s_direkteomk.omk_ob_navn Dette view siger dog kun noget om det samlede omkostningsforbrug fordelt på produkter. Der kan heraf ikke udledes nogen generelle karakteristika eller tendenser, da forbruget ikke er pr. produceret enhed. Det er derfor nødvendigt med et view mere til at definere omkostningsforbruget pr. produceret styk. For at finde en omkostning pr. enhed, divideres det totale omkostningstræk med antallet af producerede styk - se bilag 8. Det producerede antal fordelt på produkter ser således ud: 40

42 Dippedut Mini Spezial styk styk styk 1 Det kan nu ses, at Dippedut forbruger 3,26 kr., Mini forbruger 2,96 kr. og Spezial forbruger 7,6 kr. Da Solipstoid benytter sig af listepriser, vil det være muligt at finde profitten pr. produkt ved at trække omkostningsforbruget fra denne listepris. Listepriserne i Solipstoid ser således ud: Dippedut 6, kr. Min,0 kr. Spezial 13, kr. Udover listeprisen er det muligt for sælgerne at give forskellige rabatter til kunderne, hvorved profitten mindskes mere. Profitten ser således ud pr. styk: Dippedut 7, 3,26 = 3,94 kr. Mini,0 2,96 = 2,4 kr. Spezial, 7,6 = 12,4 kr. Meget tyder nu på, at ledelsen i Solipstoid har foretaget en forkert prisfastsættelse af produkterne. Profitten på Spezial er ligeledes betydelig større end på de andre produkter, hvilket kan forklare den manglende afsætning af dette produkt. Det vil være muligt for virksomheden at nedjustere salgsprisen og stadig tjene penge på at producere Spezial. Herudover kunne noget tyde på, at ledelsen i Solipstoid kan hæve priserne på Dippedut og Mini, i og med, at Solipstoid modtager for mange ordrer på disse produkter. De skal i hvert fald stoppe med at give rabatter på de disse produkter, da profitten derved bliver minimal. Solipstoid kunne derimod give større rabatter på Spezial med den nuværende prisfastsættelse. 41

43 . Afrunding - Modul 1 Der er i dette første projektmodul blevet gennemgået, hvorledes variabilitetsprincippet kan anvendes som registreringsgrundlag, og hvorledes ABC kan anvendes som rapporteringsteknik med produktet som omkostningsobjekt. 1 Efter en teoretisk beskrivelse af variabilitetsprincippet og ABC-modellen blev det klarlagt, hvilke muligheder der er for at få de to teknikker til at samarbejde. Problemstillinger vedrørende forskelle i definitionen af direkte og indirekte omkostninger blev diskuteret, ligesom problemstillingerne ved at variabilitetsprincippet hverken registrerer indtægter, eller en omkostnings mængdeside blev behandlet. Efterfølgende blev designvalget af løsningsforslaget for en ABC-rapportering på et registreringsgrundlag, der anvender variabilitetsprincippet, fremført. Variabilitetsprincippet vil i sin rene form således være et dårligt udgangspunkt for en applikation, der rapporterer på ABC. Der mangler således en række data for, at ABC-rapporteringen kan gennemføres. I forlængelse af registreringerne på art, sted og formål vil det eksempelvis være nødvendigt at registrere mængdeforbrug, samt hvad for en mængde der registreres. Herudover skal der også inddrages data om kapacitetsstørrelser og kapacitetsforbrug for at udregne aktivitetscostdrivere, som afspejler rapporteringsobjekternes træk. Disse data kan ikke findes i variabilitetsprincippet, og der kan som nævnt heller ikke findes indtægter, hvorfor ABC-lønsomhedsberegninger ikke kan foretages. I udarbejdelsen af en applikation er disse ovennævnte mangler derfor blevet inddraget. Ved at inddrage en mængdeside i registreringen muliggøres det, at det faktiske forbrug af nogle kapaciteter kan registreres. En summering af disse registreringer kan således danne udgangspunkt for tildelingen af indirekte omkostninger via aktivitetscostdrivere, hvilket dog ikke er benyttet i casen. Casens formål har derimod været at inddrage den brugte teori i et omfang, hvor dette har været muligt. De ovennævnte ændringer har således været nødvendige for, at applikationen kunne rapportere på casematerialet. 42

44 11. Indledning - Modul 2 Kravene til en virksomhed i det 21. århundrede er større end nogensinde. Omverdenen er meget dynamisk og omskiftelig, hvilket betyder, at virksomhederne skal være omstillingsparate og kunne tilpasse sig de skiftende markedsforhold. Disse krav er bestemt ikke blevet mindre aktuelle i forbindelse med den nuværende finanskrise. Krisen betyder, at virksomhederne nu må have større fokus på omkostningsstyring og derfor i højere grad har brug for fokus på økonomistyringsområdet for at hjælpe beslutningstagerne med at styre virksomheden i den rigtige retning. I modgangstider har virksomhederne i højere grad fokus på at standardisere processer og blive mere strømlinede. Dette betyder, at finanskrisen ikke nødvendigvis medfører mindre fokus på økonomistyring. Nærmere tværtimod. Topchef, hos ERP-leverandøren SAP, Jim Hagemann Snabe siger således til Børsen: 7 1 Vi har lige leveret de bedste resultater nogensinde i det seneste kvartalsregnskab, med meget høj vækst igen og det skyldes, som jeg ser det, at virksomheder specielt i situationer hvor marked er vanskeligt dér investerer de i effektivitet. Citatet viser, at Jim Hagemann Snabe mener, at virksomheder i et kritisk marked øger fokus på at effektivisere for på den måde at sikre virksomhedens fremtid. Derfor omhandler modul 2 et højaktuelt emne, med stor relevans for situationen, som virksomheder verden over befinder sig i. I nyere tid har det ikke været mere essentielt at have fokus på økonomistyring end det er netop nu. ERP-systemet og dets samspil med de øvrige teknikker er derfor i fokus. Mange virksomheder benytter således forskellige applikationer til rap- portering, som skal samarbejde med ERP-systemet. Muligheden for at uddrage beslutningsinformation fra ERP-systemets operative data er derfor blevet et vigtigt område at fokusere på, og specielt finansmarkedets nuværende situation nødvendiggør, at denne information er hurtig og præcis. 7 Larsen(08) 43

45 12. Det operative paradigme - Modul 2 Da modul 2 følger metoden fra modul 1, vil den metodiske fremgangsmåde ikke blive gengivet under dette afsnit. Der vil udelukkende blive beskrevet den arbejdsmetode, der ligger til grund for opbygningen i modul 2. Problemstillingen for modul 2 er: I hvilket omfang kan der findes relevante data i SAP Business One med henblik på at understøtte en ABC-kalkulation? Hvordan kan eventuelle databehov beskrives og udvikles som prototype i en applikation? Figur 8 herunder viser det operative paradigme, og hovedlinierne ned gennem modul 2, som besvarer problemstillingen. 1 2 For at besvare første del af problemstillingen tager modul 2 afsæt i ERP-systemer generelt, med en gennemgang af de muligheder ERP-systemer indeholder, og Figur 8: Det operative paradigme modul 2 hvilke fordele et ERP-system kan skabe for virksomhederne. Dette gøres ved at forklare ERP s historiske udvikling ERP generelt efterfulgt af en anskueliggørelse af ERP-systemet og den SAP Business One bagvedliggende tankegang. Herefter følger en gennem- ERP og ABC gang af SAP Business One(SBO), med udgangspunkt i datafangst af relevante informationer til brug i ABCkalkulationer. Derudover foretages en vurdering af hvilke Applikation Case data, der ikke er indeholdt i SBO, og hvordan disse kan Afrunding fremskaffes. Kilde: Egen tilvirkning For at besvare anden del af problemstillingen vil der blive udarbejdet en case med baggrund i de allerede registrerede data i SBO. På baggrund af ovenstående overvejelser udvikles der en applikation, som skal danne grundlag for ABC-rapporteringen. Denne applikation tager udgangspunkt i registreringsdata, som hentes fra SBO ind i en database via Microsoft Excel og Microsoft Access. Tabellerne til brug i applikationen er designet i Power Architect og danner grundlaget for den endelige applikation i Application Express. Til sidst vil der være en afrunding af Modul 2, hvor problemstillingen bliver holdt op imod den analyse, der er foretaget i dette projektforløb

46 13. Enterprise Resource Planning 1 I det følgende vil ERP-begrebet blive gennemgået. Efter en kort indledning om ERP-begrebet, vil historien bag udviklingen kort gennemgås for at skabe et udgangspunkt for forståelsen af ERP-begrebet. Begrebet vil derfor bagefter blive defineret, hvorefter en forklaring af ERP-systemets enkelte moduler vil følge. Herefter argumenteres der for fordelene ved ERP-systemer, og afslutningsvis vil afsnittet blive perspektiveret til SAP Business One, da resten af rapporten vil bygge på dette ERP-system. ERP-systemer benyttes i vid udstrækning af virksomheder til at registrere vigtige virksomhedsdata, som der senere hen kan benyttes i rapporteringsøjemed. I takt med, at flere virksomheder benytter ERP-systemer, er der kommet et behov for forskellige ERP-systemer, idet datamængden og diversiteten i dataene varierer fra den lille lokale virksomhed til den store nationale virksomhed. Flere ERP-leverandører har derfor for- skellige systemer, som kan tilpasses til virksomhedernes forskellige behov. ERP-systemerne er dog i bund og grund ens, idet systemerne er bygget på de samme principper. Følgende udsagn om ERP er et godt udgangspunkt for forståelsen af ERP-systemer: ERP is about bringing all (and only) the information that any manager needs to the manager for any decision whenever the manager needs it 76 Der rejser sig dog et par spørgsmål i relation til ovenstående citat. For det første må ERP-systemet opbygges, så der kan foretages de nødvendige rapporteringer på dataene. Det bliver altså interessant at undersøge, hvordan ERP-systemerne stiller informationerne til rådighed altså en granskning af ERP-systemets opbygning. I denne forbindelse vil det være relevant at forklare baggrunden for ERP-systemets opståen, da en nærmere granskning af denne kan være med til at forstå, hvordan systemet fungerer Historien bag ERP ERP-systemets historiske udvikling udspiller sig i høj grad parallelt med informationsteknologiens udvikling. I starten af 1960 erne blev de første MRP (Material Resource Planning) udregninger foretaget på computere, 77 hvilket betød, at det var muligt at lave beregninger på virksomhedernes materialeforbrug. Baggrunden for behovet for MRP udregningerne var, at der skete et skift i virksomhedernes konkurrencesituation. Tidligere blev der fokuseret meget på produktion til lager, da det var muligt at have store lagre og samtidig være konkurrencedygtig. Det blev dog i stigende grad klart, at det ikke var muligt at forblive konkurrencedygtige, hvis ikke de store lagre blev minimeret. 78 Fokus skiftede derfor fra at producere til lager til en effektiv produktionsproces, da det i langt højere grad blev muligt at planlægge produktionsprocessen ved hjælp af 76 Stenzel & Stenzel(02a) s Kapp(01) s Umble et al.(03) s

47 1 2 MRP-udregninger. Det blev derfor langt vigtigere, at effektivere produktionsprocessen således, at produktionstider mindskedes, og flaskehalse blev undgået. På tidspunktet var det ofte universiteter, der stod for computerudregningerne, da virksomhederne ikke besad den nødvendige computerkapacitet til at bistå sådanne udregninger. MRP-udregningerne blev derfor ofte kun foretaget én gang om ugen, og ofte langt færre gange end dette. Alle produktionsserier, der blev produceret mellem de foretagne MRP-udregninger, var således baseret på tidligere omkostningsudregninger, hvilket problematiserede udbyttet af MRPudregningerne. 79 Når der efterfølgende igen blev foretaget nye beregninger, kunne billedet således være et andet. Udregningerne var i sig selv simple, idet MRP var baseret på en afhængig efterspørgsel, hvilket betyder, at efterspørgslen efter et produkt vil medføre en efterspørgsel efter andre emner/produkter/råmaterialer. Eksempelvis vil efterspørgslen efter et givet antal blyanter medføre en efterspørgsel efter en givet mængde bly i produktionsprocessen. 80 Op gennem 1970 erne skete der en kontinuerlig forbedring af MRP-systemet, idet systemet udvikles til at også at inddrage andre produktionsfaktorer end blot materialer. MRP-systemer blev således udviklet til også at inddrage kapacitetsplanlægning. 81 De stigende teknologiske muligheder i starten af 1980 erne afstedkom udviklingen af MRP II (Manufacturing Resource Planning). MRP II indarbejdede virksomhedernes finanssystemer i MRP, hvorved det nu var muligt at kæde salg sammen med kreditorer, debitorer og så videre. 82 MRP II-systemets vigtigste del var således det gamle MRP-system, men effekten af MRP-beregninger blev større i MRP II-systemet, da flere aspekter af virksomheden blev inddraget gennem nye applikationer. 83 Denne udvikling betød réelt, at det blev muligt at kæde alle produktionsmæssige handlinger direkte sammen med virksomhedernes eksterne regnskab. MRP II blev derfor et langt mere udviklet system end dets forgænger. I 1990 erne udvikles informationsteknologien stadig, hvilket også fik betydning for MRP IIsystemerne. Der blev således udviklet mange standalone -applikationer, som med tiden er blevet integrerede dele af MRP II-systemerne. 84 Disse blev derfor hele virksomhedssystemer, hvor det ikke blot var muligt, at registrere produktionsdata, men også var muligt at registrere produktionsdesigndata, medarbejderdata og lignende. Navnet ændredes således til Enterprise Resource Planning (ERP) for at dække denne nye bredere systemfunktionalitet. 79 Kapp(01) s Kapp(01) s. 81 Umble et al.(03) s Umble et al.(03) s Palaniswamy & Frank(00) s Kapp(01) s

48 ERP-begrebet ERP s historie viser, at der ikke kan skabes et klart og entydigt begreb til at forklare ERP. Der er eksempelvis stor forskel på, om en virksomhed benytter en standardiseret løsning købt over internettet eller en virksomhedstilpasset løsning fra én af de store aktører på markedet for ERP-systemer. Der findes således mange forskellige syn på, hvad ERP er, og hvad det skal kunne. Kapp(01) fremsætter fem perspektiver på ERP. Den første opfattelse er, at ERP er et registreringssystem, som skal administrere en stor mængde data. 8 Denne opfattelse bakkes op af følgende citat: The fundamental benefits of ERP systems do not in fact come from their inherent planning capabilities but rather from their abilities to process transactions efficiently and to provide organized record keeping structures for such transactions 86 ERP-systemets mest grundlæggende opgave er således registreringsopgaven. Det vil simpelthen ikke være muligt at lave planlægning af fremtiden, uden at have registreringer om fortiden. Udgangspunktet for det meste planlægning vil således være den tidligere aktivitet i virksomheden. ERP kan også opfattes som en gruppe af moduler, der alle er samlet i en central database. Dette er en systemopfattelse, og denne opfat- telse relaterer sig til den relationelle database, og vil blive uddybet senere i afsnit Den tredje opfattelse af ERP er, at ERP er en produktionsfilosofi og ikke kun et softwareprogram. Et ERP-system er således ikke blot et registreringssystem, men samtidig en række antagelser om, hvordan produktionsprocessen er i virksomheden. Den næste opfattelse af ERP går endnu dybere end de foregående opfattelser, og ser ERPsystemet som et virksomhedskommunikationssystem, hvor virksomhedens overordnede strategier og filo- sofier kan kommunikeres ud igennem. Den sidste opfattelse af ERP opfatter ERP-systemet som et ledelsesinformationssystem. Målet med dette system er at stille relevant beslutningsinformation til rådighed for lederne. 87 Dette syn svarer således overens med det første citat af Stenzel & Stenzel(02a) i afsnit 13 s indledning. Ud fra disse forskellige perspektivers karakter vil det være hensigtsmæssigt at dele ERP-begrebet op i en konceptuel og strukturel definition. ERP som koncept vedrører de antagelser, der er gjort om virksomhedens processer, og specielt Kapps(01) tre sidste perspektiver kan siges at være konceptuelle perspektiver. ERP s struktur vedrører rent praktisk systemets opbygning. Denne struktur vil oftest være afhængig af, hvilke overvejelser der er gjort om ERP som koncept. Systemet skal således kunne realisere konceptet Kapp(01) s Jacobs & Bendoly(03) s Kapp(01) s Jacobs & Bendoly(03) s

49 Det efterfølgende citat beskriver problemstillingen, samt mulige konsekvenser af ikke at være bevidst om forskellen mellem systemet og konceptet. The logic of the system may conflict with the logic of the business, and either the implementation will fail, wasting vast sums of money and causing a great deal of disruption, or the system will weaken important sources of competitive advantage, hobbling the company 89 Det bliver således af stor vigtighed, at der eksisterer overensstemmelse mellem virksomhedens ERP-system og koncept. Den efterfølgende forklaring af ERP-begrebet vil derfor blive opdelt i en strukturel og konceptuel del. Først forklares den systemmæssige del, hvor de mest almindelige moduler og selve grundtanken bag et ERP-system forklares. Dette gøres for bagefter at inddrage, hvordan ERP-konceptet kan ændre sy- stemet ERP-systemet Ét ERP-system kan godt håndtere alle de perspektiver Kapp(01) nævner. Systemets udformning kan dog i sin mest basale udformning kun håndtere de to første perspektiver. For at systemet kan håndtere de andre perspektiver vil det være nødvendigt at kode systemet til det - ellers skal virksomhedens processer tilpasses systemets opbygning. Det vil selvsagt være uheldigt, da kernekompetencer kan gå tabt i tilpasningen. Det vil ligeledes være sværere at differentiere sig som virksomhed, hvis processerne i virksomheden tilpasses en forudbestemt opbygning. Hovedpointen er således, at der skal være sammenhæng mellem systemets opbygning og virksomhedens processer: Unless the various business processes are redesigned to suit the design of the modules of ERP, the system implementation may not yield the ecpected success 90 Enten skal systemet altså tilpasses virksomhedens processer, eller også må virksomhedens processer tilpasses til systemet. 2 Den grundlæggende registreringsopgave findes i alle ERP-systemer og danner grundlag for alle de andre opgaver. Systemets opbygning vil dog bestemme, hvorledes disse registreringer kan bruges til de andre perspektiver. Grundtanken bag alle ERP-systemer kan groft illustreres således: Davenport(1998) s Palaniswamy & Frank(00) s. 6 48

50 Figur 9: Opfattelse af ERP-systemet 1 Kilde: Egen tilvirkning efter inspiration fra Stenzel & Stenzel(02b) s. 6 Systemet uden relationer består af uafhængige moduler, som ikke har nogen relationer med hinanden. Dette giver nogle problemer rent praktisk, hvis det bliver opfattet som et registreringssystem. Da de enkelte moduler ikke kan trække data fra hinanden, vil der i registreringssystemet opstå store mængder af redundans. Dette er både uheldigt for systemet, da det bliver langsommere, og for medarbejderne, da registreringsmængden er større. Før indførslen af ERP-systemer har det således været tilfældet, at der har været flere forskellige systemer til at håndtere enkelte af virksomhedens opgaver, men et samlet virksomhedssystem uden nogle relationer mellem de enkelte moduler har næppe eksisteret. Derimod kan systemet uden relationer ses som et virksomhedssystem, hvor virksomhedens enkelte afdelinger eller divisioner benytter forskellige systemer. Dette vil gøre en sammenkobling af systemerne besværlig, da de enkelte systemer ofte vil være kodet forskelligt, hvorfor systemerne ikke vil kunne arbejde sammen. Mange virksomheder har således stillet til grund for indførslen af ERP, at inkompatibilitet systemerne imellem skulle undgås. 91 Systemet med relationer er derimod opbygget efter principperne for den relationelle database, hvorfor de enkelte moduler er kædet sammen af fremmednøgler. Dette betyder, at systemet vil kunne trække data fra mange moduler på engang, og det er dette princip, som ERP-systemer er opbygget efter. Selve ERPsystemet er således et funktionsopdelt system, hvor hvert modul varetager en specifik funktion. Sammenkædningen af modulerne sker derimod gennem forskellige processer, hvorfor systemet i høj grad kan siges at være procesorienteret. Hvor bredt et spektrum af funktioner systemet kan varetage afhænger af den enkelte virksomheds behov for informationer. Samtidig vil kompleksiteten i ERP-systemerne være forskel- 91 Palaniswamy & Frank(00) s. 6 49

51 lig. Mange ERP-systemer er derfor rent praktisk opsat således, at virksomhederne kan købe de moduler, de har behov for. ERP-systemet bliver derfor forskelligt fra virksomhed til virksomhed, men der kan dog opsættes nogle generelle karakteristika for ERP-systemer. Som udgangspunkt kan ERP-systemet anskues således: Figur : Anotomy of an Enterprise System At the heart of an enterprise system is a central database that draws data from and feeds data into a series of applications supporting diverse company functions. Using a single database dramatically streamhnes the flow of information throughout a business. 1 Kilde: Davenport(1998) s. 124 Ovenstående figur viser, hvordan de enkelte moduler danner en brugerflade til databasen. ERPsystemets enkelte moduler, applications i figur, vil endvidere være kædet sammen med hinanden, og gennem denne sammenkædning vil det eksempelvis være muligt at udgå redundans. Herudover er ERPsystemerne opbygget efter processer, som forekommer i virksomheder. ERP-systemet er som sagt bygget op af enkeltmoduler, men gennem denne procestankegang kædes de forskellige moduler sammen. Der vil således være en sammenhæng mellem de enkelte modulers funktionsområder gennem processerne i virksomheden. Fra at en sælger får en ordre i hus, til ordren er leveret, foregår der således en række processer i virksomheden. Selve salgsmodulet skal gennem ordreafgivelsen videreføre informationer til produktionsmodulet om, hvad der skal produceres og til hvilken dato. Herudover skal ordren også registreres i finansmodulet, så den resultatmæssige effekt af salget medtages i årsregnskabet. Hver enkelt modul udgør således en funktion i virksomhedens processer. 0

52 ERP som koncept - tankegangen bag ERP Som allerede beskrevet afhænger ERP-systemet af, hvordan virksomhedens forskellige processer udføres. Dette vil dog kun være gældende i det omfang, at virksomheden er opmærksom på, at der eksisterer en sammenhæng mellem ERP-systemets opbygning og virksomhedens processer. Det vil derfor være relevant at gøre sig nogle overvejelser inden implementeringen af et ERP-system. Indeværende afsnit fokuserer derfor på tankegangen bag ERP, fordi succesen af implementeringen af et ERP-system, i det lange løb, bliver et spørgsmål, om systemet stemmer overens med virksomhedens processer. Det drejer sig i høj grad om at være bevidst om egne processer internt i virksomheden, og derefter designe et ERP-system med baggrund i denne forståelse af virksomhedens processer. 92 Davenport(1998) lægger i denne forbindelse vægt på, at de mest succesfulde ERP-systemer er udviklet med baggrund i strategiske og organisatoriske overvejelser. Davenport skriver således: They stressed the enterprise, not the system Ved at fokusere på virksomhedens processer før en systemimplementering undgås problematikker vedrørende efterfølgende systemændringer. Samtidig vil der ved en undersøgelse af virksomhedens eksisterende processer kunne identificeres processer, som burde ændres for at gøre virksomheden mere konkurrencedygtig. En af de største fordele ved ERP er således omstruktureringen af virksomhedens nuværende måde at drive forretning på. 94 For mindre virksomheder vil det således være givtigt at indarbejde nogle af de best practices, som eksisterer i et ERP-system. Herved sker der en tilpasning af virksomheden til systemet. Ved valg af ERP-system bør virksomheden således være opmærksom på, hvordan netop dette system er sat sammen og hvilke aspekter af systemet, som ikke understøtter dens processer. De moduler, som ikke understøtter virksomhedens processer, må derefter ændres eller nye må tilføjes, så ERP-systemet er i overensstemmelse med dens processer. Efter implementering af ERP-systemet kan uoverensstemmelser mellem systemet og virksomhedens processer løses på to forskellige måder. Enten kan virksomheden tilpasse dens processer til systemet eller tilpasse systemet til virksomheden. I mange tilfælde vil en mellemløsning dog være at foretrække, da ERP-systemerne er opbygget efter best practice-princippet. Samtidig vil virksomhederne miste nogle af deres konkurrencemæssige fordele, hvis alle virksomheder tilpassede sig efter systemet, da procesgangene i virksomhederne ville blive ens. Der kan selvsagt være store forskelle på virksomheder, som selvfølgelig også afspejles af det ERP-system, som den enkelte virksomhed har implementeret. En stor virksomhed efter danske forhold vil eksempelvis 92 Jacobs & Bendoly(03) s Davenport(1998) s Al-Mashari et al.(03) s. 3 1

53 have flere og mere komplicerede forretningsprocesser end en lille enkeltmandsvirksomhed. Hvor den store virksomhed har brug for et stort system til sine processer, kan enkeltmandsvirksomheden højst sandsynligt klare sig med et simpelt bogføringssystem. Før et ERP-system vælges, vil virksomheden altså med fordel kunne gøre sig nogle overvejelser om, hvad systemet skal kunne, og hvordan dette rent praktisk gøres i virksomheden. Herefter vil det være muligt at finde en tilsvarende systemløsning eller eventuelt tilpasse en systemløsning til virksomhedens unikke processer. På denne baggrund bliver ERP mere end blot et system, det bliver en proces, hvor der identificeres og implementeres de bedste procedurer, arbejdsgange og værktøjer fra forskellige funktioner indenfor virksomheden med det mål at opnå maksimal organisatorisk performance gennem integration af virksomhedens processer Fordele ved ERP-systemer Efter at have beskrevet, hvad ERP er, og hvordan selve begrebet skal forstås, vil der nu argumenteres for, hvorfor ERP-systemer skaber fordele for virksomhederne. Selve systemforståelsen af ERP-begrebet vil danne baggrund for dette afsnit. Og det er med udgangspunkt i følgende citat, at den store fordel ved ERPsystemerne forklares. ERP provides two major benefits that do not exist in non-integrated departmental systems: (1) a unified enterprise view of the business that encompasses all functions and departments; and (2) an enterprise database where all business transactions are entered, recorded, processed, monitored, and reported. 96 Her ses det, at samlingen af alle virksomhedens data i et system danner udgangspunktet for en række muligheder. Registreringen kan siges at være den mest vigtige funktion i ERP-systemerne, da det er denne registrering, der skaber en række muligheder for virksomhederne. Samtidig muliggør en samling af data i en database, at rapporteringer kan foretages på basis af data fra flere forskellige afdelinger og lignende. Davenport(1998) skriver således: To put it bluntly: if a company s systems are fragmented, its business is fragmented For at forstå hvorfor ERP-systemer skaber fordele for virksomheder, må man også forstå, hvad det er, som skaber værdi for virksomhederne. Her tænkes ikke på det operationelle niveau, men på det strategiske og taktiske niveau. Udgangspunktet for en virksomhed vil altid være en mission og en vision. For at gå fra mis- 9 Mabert et al.(00) s Umble et al.(03) s Davenport(1998) s

54 sionen til visionen benyttes forskellige strategier. Det er disse strategier, som skal skabe værdien eller den fremtidige værdi for virksomhederne. Den store fordel ved ERP-systemerne er i denne sammenhæng, at de kan være med til at understøtte strategierne ved hjælp af planlægningsværktøjerne i ERP-systemerne. Herudover skaber ERP muligheden for, at de langsigtede strategier udformes i dag-til-dag-planer, for eksempelvis for produktionen. ERP-systemerne bliver derfor rigtig værdifulde, når de benyttes bevidst i relation til den langsigtede planlægning. Dette kan være i form af rapporteringer på omkostningsstrukturer, salgsprognoser eller ABC-analyser SAP Business One I dette projekt vil SBO blive benyttet som ERP-system. Derfor vil følgende afsnit kort redegøre for, hvad der kendetegner SBO, og hvad der adskiller SBO fra større ERP-systemer. SBO er SAP s løsning til små og mellemstore virksomheder, med op til ansatte. 98 SBO henvender sig primært til mindre virksomheder, da det både har den rette kompleksitet og rette omkostningseffektivitet i forhold til blandt andet SAP R/3, der ofte er overdimensioneret på alle niveauer i forhold til, hvor omkostningstung den er, og hvor kompliceret den er at implementere i virksomhederne. Som det fremgår af følgende citat, henvender SBO sig primært til små og mellemstore virksomheder: SAP Business One has gained favor in the mid-size market because it is both cost-effective and compact in size. Like larger enterprises, small and mid-size companies need an integrated software solution that adapts the overall document/process flow to the larger operational processes of the company. 99 SBO s fordel er dermed, at systemet ikke er så komplekst og omfattende som de største ERP-systemer på markedet, men samtidig indeholder systemet de standardfunktioner som små og mellemstore virksomheder efterspørger. En anden fordel for små og mellemstore virksomheder ved at anvende SBO er, at de traditionelt er mere sårbare over for ineffektive ERP-løsninger, da de har mere begrænsede ressourcer end store virksomheder. Ved at anvende SBO undgår virksomheder dermed, at bruge store ressourcer på et ERP- system, som de ikke er sikre på vil passe til deres virksomheds behov. SAP Business Ones brugerflade kan ses af nedenstående figur 11. Figuren viser således et screen shot af alle modulerne i SBO. Af figuren kan det ses, at der eksempelvis er et økonomimodul, et personalemodul, og et rapporteringsmodul. Der vil efterfølgende komme en kort redegørelse for de moduler, der bruges i besvarelsen af problemstillingen. 98 Teufel et al.(0) s. 99 Teufel et al.(0) s. 2 3

55 Figur 11: SBO s moduler Kilde: SAP Business One Fra økonomimodulet benyttes flere ting. Selve kontoplanen vil være at finde i dette modul, og de summerede regnskabsposter kan ligeledes aflæses her. I forretningspartnermodulet er det muligt at oprette og finde alle samarbejdspartnere, som en virksomhed måtte have. Fra dette modul findes alle kunderne for senere at kunne rapportere på dem. I lagerstyringsmodulet kan man oprette eller finde dataene på alle de produkter, der produceres eller sælges. Fra dette modul skal alle produkterne udtrækkes for at der kan afrapporteres på disse. Herudover vil der blive inddraget data fra salgsmodulet, hvor man kan udtrække omsætningsrapporter på produkter, kunder og salgsmedarbejdere. I indestående modul 2 vil der kun blive udtrukket data på kunder og produkter, da der vil blive rapporteret på disse. Udover de benyttede moduler findes en række andre muligheder i SBO. Det eneste dette kræver, er et kendskab til de enkelte moduler og deres indhold. 4

56 14. Forskellen mellem ERP og ABC 1 2 Efter en gennemgang af ERP samt en kort belysning af SBO, kædes ERP sammen med ABC. ABC-teorien er angivet i modul 1, så dette afsnit vil således omhandle sammenspillet mellem ERP og ABC. For at udnytte fordelene ved ABC-modellen til kalkulationer og lønsomhedsberegninger, ved brug af ERP-registreringer, er det vigtigt, at være opmærksom på de forskelle og forhindringer der ligger heri. Som beskrevet i modul 1, kan der på baggrund af ABC udarbejdes mange rapporter, der kan danne beslutningsgrundlag for ledelsen i virksomheden og dermed danne base for strategiske valg, som ledelsen foretager sig. ABC bliver dog i takt med en stigende detaljeringsgrad et mere ressourcekrævende system, og derfor er det en stor fordel, at mange af disse data allerede er indsamlet til anvendelse i ERP-systemet. Da ERP er et real-time system, bliver denne information opdateret på daglig basis, og det er derfor muligt at lave dag-til-dag-opfølgninger frem for de månedlige eller årlige opdateringer af ABC, der ellers er de gængse intervaller. 0 ERP-systemet er et præcist værktøj, hvor der lægges vægt på en korrekt dataregistrering. ABC lægger derimod mere vægt på en periodemæssig betragtning, der kan bruges, selv om der kommer små ændringer i de aktuelle data. Denne viden er vigtig, når der skal arbejdes med de to systemer, både som informationskilde og når de forsøges integreret. Der er således tre måder hvorpå ABC og ERP kan arbejde i forhold til hinanden. De kan holdes fuldstændigt adskilt, hvor de arbejder hver for sig, og dermed benytter sig af hver sine registreringer. Den anden mulighed er, at de interagerer med hinanden, hvor nogle data deles, og de data, der ikke kan findes i både ERP og ABC, indsamles til hvert sit system. Tredje mulighed er, at ABC er en integreret del af ERP-systemet, og dermed anvendes ERP som platform for alle ABC-beregningerne. 1 Problemstillingen i modul 2 lægger vægt på, at systemerne skal arbejde sammen. Dette skyldes, at de hver for sig skal indsamle ekstra data, hvilket skaber ekstra arbejde for virksomheden og dens medarbejdere. Alternativet, hvor ABC er fuldstændigt integreret, er ifølge ERP-leverandørerne en fuldendt løsning, men denne løsning vil ikke være tilgængelig for små og mellemstore virksomheder, som denne rapport sigter mod, grundet pris og kompleksitet. Gennemgående for rapporten bliver derfor et system, hvor ERP og ABC er i samspil, men ikke fuldt integrerede. I figuren herunder ses et eksempel på, hvordan ERP og ABC kan interagere i en virksomhed: 0 Cooper & Kaplan(1998) s Lahikanen et al.(00) s. 4

57 Figur 12: Integration mellem ERP-system og ABC i virksomheden 1 Kilde: Egen tilvirkning efter inspiration fra Emily Brodeur(00) s. 2 Figur 12 viser, at organisationens handlinger samles i et ERP-system i form af registreringsdata, hvorefter den tilknyttede ABC-model kan anvende dele af den finansielle og ikke-finansielle data. Disse data, samt yderligere informationer til brug i ABC-modellen, anvendes til udarbejdelse af periodiske resultater, der blandt andet kan anvendes til budgetopfølgning i ERP-systemet. Herudover vil der blive inddraget data i ABC-systemet, som ikke kan findes i ERP-systemet. Dette vil blive uddybet senere i afsnit Derudover generer ABC-modellen analyser, såsom kalkulations-, optimerings- og lønsomhedsanalyser, der kan sendes direkte videre til beslutningstagerne på det taktiske og strategiske niveau. Lederne kan benytte disse analyser sammen med rapporteringsdataene fra ERP-systemet til at tage vigtige strategiske valg, og dermed danner samspillet mellem ERP og ABC grundlag for, at ledelsen kan træffe bedre beslutninger om fremtidige strategiske valg. Virksomheder, der anvender begge teknikker, skal være opmærksomme på, om de data der anvendes i den aktuelle situation, generelt er brugbare, eller om de blot afspejler en kortsigtet trend. Det er derfor vigtigt, at virksomhederne er fuldstændig klar over, hvad de enkelte systemer og værktøjers forskelle og mål er, for ikke at anvende disse forkert og derved ikke få den ønskede effekt eller måske endda få direkte forkerte informationer. Derfor skal virksomhederne have for øje, at de enkelte systemer ikke kan udføre alle opgaverne hver for sig, men at systemerne skal bruges i interaktion med hinanden. ERP-systemet skal benyttes til registrering og daglig opfølgning på proces- og afdelingseffektivitet, hvorimod ABC kan generere strategisk omkostningsinformation. 2 Derfor virker det umiddelbart gavnligt at få systemerne til at interagere, 2 Cooper & Kaplan(1998) s. 1 6

58 1 men der opstår både problemer og fordele ved at bruge ABC og ERP sammen. En fordel er, at kildedata fra ERP-systemet sikrer et mere opdateret informationsgrundlag for ABC. Problemerne fremkommer, når de relevante steder at opsamle data i ERP-systemet skal findes. Da ERP- og ABC-systemet ikke er designet til samme formål, vil der ikke fremkomme de samme poster i begge systemer. Samtidigt er det vigtigt, at være opmærksom på problemstillingen vedrørende periodisering i forbindelse med udtræk af ERP-data til brug i ABC. Når der anvendes data fra ERP, benyttes registreringerne fra finansmodulet, og virksomhederne skal derfor være opmærksom på, at de enkelte poster hører til den periode, som ABC-kalkulationen forholder sig til. Et eksempel på en periodisering kan være en flybillet betalt i december, som først er anvendt - og dermed optræder som en omkostning - i februar året efter. I dette eksempel vil en ABC-kalkulation på omkostningsobjektet kunde være forskellig, i henhold til om kalkulationen er afgrænset til én måned, eller om der skal flere måneder med i kalkulationen. Udgiften, som ERP-systemet medtager, finder sted i december, mens forbruget først finder sted i februar. Vil virksomheden derfor lave en kalkulation på, om kunden er rentabel i februar, skal den være opmærksom på, at der er en omkostning, som skal medregnes. Disse poster skal behandles enkeltvist, og er der mange poster, kan ABC-kalkulationen blive en omfattende periodiseringsproblemstilling. Foretages der derimod ikke disse periodiseringer, bliver kalkulationerne ikke så retvisende og kan i værste fald danne grundlag for fejlagtige beslutninger. Derfor kræver det tilpasning af både ABC- og ERP-designet, samt behandlingen af data, for at de to systemer kan sammenkobles. Der findes dog allerede IT-systemer, der benyttes i større virksomheder, hvor der er en samlet løsning. Et eksempel på, hvor ABC-systemet er inkluderet i ERP-basisproduktet, er SAP R/3. Men dette og lignende systemer bliver ikke yderligere behandlet, da de ikke relaterer sig til problemstillingerne i denne rapport, samt ikke er blevet gennemgået i undervisningsforløbet. 7

59 1. Data fra SBO til ABC-kalkulation I det følgende vil der forestå en belysning af hvilke relevante data, der kan findes i SBO med henblik på understøttelse af en ABC-kalkulation, der er en besvarelse af første del af problemstillingen for dette modul. Denne belysning kræver således, at informationskilder fastslås, og at der, i forhold til et ABC-design, defineres et datagrundlag for selve ABC-kalkulationen. I det følgende fremgår det således, hvilke finansielle og ikke-finansielle data en ABC-kalkulation forudsætter. Fokus vil være på poster, som har en effekt på resultatopgørelsen. Aktiv- og passivkonti vil således ikke blive inddraget i den valgte kalkulation. 1.1 Information fra SBO Informationskilden og derigennem datagrundlaget til ABC-kalkulationen kan alene ske gennem et ERPsystem. ERP-systemet indeholder således data fra forskellige moduler, hvorfra forskellige informationer kan findes. I det følgende fokuseres der således på at finde finansielle og ikke-finansielle data i SBO til en ABCkalkulation. Informationsbehovet er angivet i nedenstående figur: Figur 13: Informationsbehov til et ABC-kalkulationsdesign 1 1)Rapporteringsobjekter og tidshorisont: Fastlæg rapporteringsobjekt og hvilken tidshorisont ABCkalkulationen skal udfylde. 2) Direkte omkostninger: Tildel rapporteringsobjekterne de direkte omkostninger, som kan defineres hertil. 3) Indirekte omkostninger og ressourcepuljer: Fordel de indirekte omkostninger i forhold til rapporteringsobjekterne fra SBO ud i ressourcepuljer. 4) Aktiviteter: Definér hovedaktiviteter i virksomheden, hvorom rapporteringsobjekterne trækker. ) Costdrivere: Fordel derefter indirekte omkostninger fra ressourcepuljer til aktiviteter via ressourcecostdrivere, hvorefter definerede aktivitetscostdrivere skal fordele omkostninger fra aktivitetspuljerne til rapporteringsobjekterne. 6) Kalkulationen: Udfør kalkulation Kilde: Egen tilvirkning efter inspiration fra Wiese(06) s. 406, samt Bukh og Israelsen(03) s Rapporteringsobjekter og tidshorisont Ifølge Wiese(06, s. 406) er det første, der må afklares, hvilke rapporteringsobjekter kalkulationsanalysen bør fokusere på. Disse rapporteringsobjekter er således de objekter, som virksomhedens omkostninger skal fordeles til via en ABC-kalkulation. Rapporteringsobjekterne vil være at finde i SBO i respektive tabeller i databasen, hvoraf eksempelvis produkter, som rapporteringsobjekt, vil være at finde i tabellen OITM i den underliggende database. Er det således produkter, der er i fokus for en kalkulation, vil bestemmelsen af hvilke omkostninger, der henholdsvis er direkte eller indirekte være anderledes, end hvis rapporteringsobjekterne var produktgrup- 8

60 per. Lahikainen et al.(00) argumenterer for, at definerede aktiviteter i virksomheden forbundet med rapportering på objekter er unik for hvert enkelt valgt rapporteringsobjekt. 3 In ABC every costing object has a unique activity structure. 4 1 Betydningen er derfor, at valget af rapporteringsobjekt er styrende for kalkulationens klassificeringer af både omkostninger og aktiviteter, når Wiese(06) og Lahikainen et al.(00) argumenter anvendes. Endvidere må der med kalkulationen inddrages en tidsdimension for hvilke omkostningsarter, der ønskes inddraget i kalkulationen og derved hvilke omkostninger, der skal findes i SBO, såsom afskrivninger eller renteomkostninger. Tidsdimensionen kan således inddeles i et oprationelt, taktisk og strategisk sigte. For afskrivninger kan der eksempelvis argumenteres for, at denne omkostningsart ikke skal medtages i en kalkulation på kort og mellemlangt sigt, da ressourcen i tilknytning til afskrivningen, ikke kan afdisponeres i denne tidshorisont. 6 Overvejelser om en tidshorisont på oprationelt eller strategisk niveau kan derved påvirke hvilke omkostningsarter, der medtages i kalkulationen. Opdelingen mellem hvilke omkostninger, der er direkte og indirekte til rapporteringsobjekterne, kan således ikke forventes at fremgå i ERP-systemet eller mere specifikt i SBO, som blandt andet er formålsbestemt i forhold til de konceptovervejelser, der ligger bag opbygningen af systemet. Her tænkes på, at den målgruppe, der er tænkt som brugere af SBO, vurderes til at være mindre virksomheder, som kan forventes at have et bestemt fokus og krav til systemets funktionsmuligheder. Cooper & Kaplan(1998) nævner i denne sammenhæng, at nogle omkostningssystemer løser visse opgaver, der ligger indenfor begrebet operationel control systems. Disse vurderes til at være opgaver i forhold til lagerstyring samt ekstern rapportering, altså den operationelle og lovpligtige rapportering. Følges endvidere Cooper & Kaplans udsagn om, at operationel control systems aggregerede poster i et omfang, så individuelle forhold ikke kan spores, må sådanne systemer udbygges til, at beslutningsgrundlaget kan blive mere nuanceret. Cooper & Kaplan(1998) skriver om disse operationel cost systems: 2 They report on outcomes but offer little insight into the cause of those outcomes. 7 For at imødekomme dette, mener Cooper & Kaplan(1998), at et nuanceret beslutningsgrundlag blandt andet kan skabes gennem en ABC-rapportering. 8 Forudsætningen må dog være, at datagrundlaget til en så- 3 Lahikanen et al.(00) s. 7 4 Lahikanen et al.(00) s. 7 Israelsen & Reeve(1998) s Israelsen & Reeve(1998) s Cooper & Kaplan(1998) s. 1 9

61 dan ABC-kalkulation er til stede i registreringsgrundlaget i SBO. Andre systemer som SAP R/3 kan have andre registreringsdimensioner indbygget i systemopsætningen, hvorfor datatilgangen til en ABC-applikation vil være en anden. SAP R/3 har i øvrigt i denne sammenhæng inkluderet ABC-kalkulationer i sin opsætning, som tidligere beskrevet. 9 Når konceptovervejelsen for et ERP-system tages op, kan der ikke forventes, at SBO har indbygget alle registreringsdimensioner. SBO kan således ikke understøtte alle tænkelige analyser af givne rapporteringsobjekter og anden relevant information til en ABC-kalkulation i en konkret virksomhed. Det kan dog foreslås, at der i registreringsøjeblikket for omkostningen, bliver defineret hvorvidt omkostningen er direkte eller indirekte i forhold til et af rapporteringsobjekterne. Her vil der dermed opstå et datagrundlag for fremtidige rapporteringer. Klassificeringen af direkte og indirekte omkostninger i forhold til rapporteringsobjekterne kan endvidere anvendes til andre kalkulationsanalyser end blot en ABC-analyse, jævnfør Israelsen & Reeve(1998) Direkte omkostninger Indledningsvis, til en bedømmelse af omkostningsbestemmelsen, må der til en direkte omkostningsklassificering i SBO anskues til omkostninger, der ligger i konti under vareforbrug, da disse er vurderet til at være direkte til rapporteringsobjekterne produkter og kunder. Materialeforbruget vil eksempelvis være både direkte til produkter, samt kunder, da kunderne aftager produkterne. Før en kalkulation på de registrerede data kan finde sted, må der dog vurderes, hvilken indflydelse prisfastsættelsen af lageret og vareforbruget kan medføre på en ABC-kalkulation. De direkte omkostninger belyses således i første omgang i forhold til vareforbruget og efterfølgende til andre omkostninger, der klassificeres direkte omkostninger. Direkte omkostninger i forhold til materialeforbruget Da en virksomhed kan have flere forskellige leverandører til de samme produkter, og der eksempelvis kan være forskel i kvantumsrabat, kan der over tid være forskel på indkøbspriserne på produkterne. Dermed kan ABC-kalkulationer på produkter få forskellige udfald afhængig af, hvilken indkøbsværdi det pågældende produkt bliver tildelt. Derfor skal virksomhederne vurdere og vælge imellem hvilken opgørelsesmetode, den skal anvende til værdisætning af varelagre og vareforbrug, og der vil i det følgende blive gennemgået tre forskellige metoder, der kan anvendes i SBO. 8 Cooper & Kaplan(1998) s. 1 9 Stenzel & Stenzel(02c) s

62 1 2 First in first out (FIFO) er kendetegnet ved, at det er den ældste indkøbte eller producerede vare, der først indregnes i resultatopgørelsen. 1 Glidende gennemsnitpris er den anden metode, der kan anvendes til prisfastsættelse af både varelager og vareforbrug. Hver gang virksomheden køber nye varer skal en gennemsnitspris beregnes ved anvendelse af et vejet gennemsnit. 111 Sidste mulighed i SBO er standardpriser som er en relativ simpel måde at prisfastsætte lager og vareforbrug på, idet der anvendes standardpriser. Modsat FIFO og glidende gennemsnitspris bliver standardpriserne ikke beregnet, men fastsat for en given periode. 112 Standardpriser er således virksomhedens forventninger til, hvad de enkelte varer vil blive indkøbt og forbrugt til i en fremtidig periode. For en strategisk ABC-kalkulation vil anvendelsen af standardpriser være en anvendelig metode. Idet andre metoder, ifølge Israelsen & Reeve(1998), kan give en tilfældighedsopgørelse af en kalkulation. 113 Denne vurdering af varelageret til FIFO, glidende gennemsnit eller standardpriser kan således foretages i SBO, hvorefter data for vareforbrugsopgørelsen kan eksporteres til ABC-applikationen. Denne eksport vil fremgå i et senere afsnit om applikationsopbygningen, hvor vurderingsprincippet glidende gennemsnit, vil blive den anvendte metode, da data liggende i demoregnskabet i SBO, er vurderet efter glidende gennemsnit. Andre direkte omkostninger Begrebet direkte omkostninger kan inddrages som dimension på konti, der har en kapacitetsrelateret status. Store dele af både direkte og indirekte lønomkostninger kan således defineres til at blive bogført på konti, der har denne status. Disse vil i SBO ligge under udgiftskonti, som er nummereret fra Alle udgifter vil således være at finde i tabellen OACT, da denne tabel indeholder alle de aktuelle summerede poster i finansmodulet. Definitionen af hvilke omkostningskonti, der er direkte i forhold til rapporteringsobjekterne, vil dog ikke være mulig at foretage i SBO for ex post-analyser af ABC-kalkulationer, idet registreringsgrundlaget, i forhold til adskillelsen mellem direkte og indirekte omkostninger, ikke vil være til stede. For ex-ante ABC-analyser kan der således indføres en konteringspolitik, hvor en attribut blev anført i konteringsøjeblikket. Metoden fremvises via et screen shot fra SBO, hvor en bogføring af et tænkt bilag fremvises i figur Andersen & Rohde(01) s. 111 Andersen & Rohde(01) s Andersen & Rohde(01) s Israelsen & Reeve(1998) s

63 Figur 14: Screen shot af finanspostering i SAP Business One Kilde: Egen tilvirkning 1 Figur 14 viser en registrering i SBO-finansmodulet af et bilag fra en sælger, der har været på kundebesøg hos en specifik kunde. I SBO under Hovedmenu Økonomi Finansbogføring vil situationen således være den, at omkostningen bliver konteret på kontoen: Travel expenses accomodation, hvilket på dansk svarer til rejseudgifter og indkvartering. I faktureringsøjeblikket kan der kobles en projektattribut på registreringen. Efterfølgende vil der, i den underliggende tabel i databasen bag SBO-brugerfladen, være en artskonto, hvor selve beløbet og de yderligere relationer til andre tabeller er lagret. Til senere udtræk fra SBO til en ABC-applikation vil projektattributten medføre, at et rapporteringsobjekt, eksempelvis en kunde, kan indlægges i DML-koden. I det øjeblik der kan udføres DML-sætninger, kan der udtrækkes information om hvilke omkostninger, der henholdsvis er direkte eller indirekte i forhold til rapporteringsobjektet. Dette belyses senere i applikationsopbygningen. Udvælgelsen af data vil ske fra tabellerne OACT og JDT1, som kan datamanipuleres via forespørgselsgeneratoren i SBO. Samme metode kan anvendes for andre rapporteringsobjekter, hvor en attribut er tilkoblet registreringen, hvorefter informationen, om omkostningerne enten er direkte eller indirekte til et givet rapporteringsobjekt, kan udtrækkes gennem DML-koder. En direkte omkostning kan således kun spores, hvis informationen er tilkoblet registreringen af omkostningen. 62

64 Indirekte omkostninger og ressourcepuljer De indirekte omkostninger vil i en ABC-kalkulation være de omkostninger, som er indirekte i forhold til det rapporteringsobjekt, kalkulationen har fokus på. Ud fra ovenstående bilagsregistrering kan der således opstå den situation, at en samlet finanskonto, der findes i SBO i tabellen OACT, kan indeholde summerede beløb i forhold til de posteringer, der er konteret på kontoen henover en given periode. Dette bevirker, at en del af disse omkostninger kan være direkte til de ønskede rapporteringsobjekter, og de resterende posteringer i den samlede summerede post kan være indirekte. Fastlæggelsen af vurderingen af direkte eller indirekte omkostninger kan derved ske ved anvendelse af en tvungen funktion i finansbogføringens brugerflade. Således vil der efterfølgende være mulighed for, at både direkte og indirekte omkostninger kan opspores fra summerede konti i OACT-tabellen. Andre konti vil yderligere have rene indirekte omkostninger, der kan være omkostningsarter såsom husleje og elektricitet, da disse arter antageligt har lav grad af målelighed. 114 Konti som husleje og elektricitet vil derved alene indeholde indirekte omkostninger, når omkostningsobjektet er produkter, som produceres under samme tag. Disse omkostninger vil sandsynligvis være vanskelige at henføre uden en arbitrær fordeling til rapporteringsobjekterne, idet disse omkostninger har en lav grad af målelighed i forhold til rapporteringsobjekterne. Omkostninger, som disse, vil dermed med deres summerede beløb henføres direkte til ressourcepuljer i en ABC-applikation, hvorefter disse omkostninger vil blive fordelt til rapporteringsobjekterne via costdrivere. En anden mulighed, end at anvende en ekstern applikation til fordelingen af de indirekte omkostninger til ressourcepuljer, er at bruge profitcenterfunktionen, som findes i SBO under Hovedmenu Økonomi Omkostningsregnskaber Profitcenter. 11 I profitcenterfunktionen er der mulighed for at få systemet til at fordele omkostninger fra finansposteringerne til oprettede profitcentre. Denne funktionsmulighed kan dermed anvendes til et andet formål end tiltænkt - nemlig at disse profitcentre bliver anset som ABCkalkulationens aktiviteter. Dermed kan virksomhedens definerede aktiviteter programmeres ind i SBO og efterfølgende kan omkostningerne fordeles til aktiviteter via fordelingsnøgler, der er fastlagt i SBO. Denne funktionsmulighed har gruppen dog fravalgt ud fra den betragtning, at systemopsætningen til denne funktionsmulighed er påtænkt et andet formål - nemlig at fordele omkostninger til profitcentre og derved omkostningssteder. 116 Funktionsmuligheden anvendes derfor ikke til fordelingen af indirekte omkostninger til aktiviteter, men funktionsmuligheden giver dog mulighed for at indlægge en stedsdimension i registreringen, jævnfør Madsens stedsbetragtning afsnit Andersen & Rohde(01) s Undervisningsnotat fra Aarhus Handelshøjskole(02) kap. 13, s Undervisningsnotat fra Aarhus Handelshøjskole(02) kap. 13, s. 8 63

65 Den næstsidste kommentar, der knyttes til indirekte omkostninger, er, at en omkostningsart, som gage på stedsdimensionen, ikke er at finde i SBO. Stedsdimensionen kan dog indlægges i registreringen, hvorefter omkostningerne kan adskilles til kalkulationsformål ud fra en stedsbetragtning. Den efterfølgende fordeling af data til ABC-modellens ressourcepuljer følger Cooper & Kaplans(1998) fremføring af hvilke monetære enheder, der fordeles via modellen, nemlig udgifter. 117 Modifikationen hvorpå udgiftsdata fra SBO bliver fordelt til den eksterne ABC-applikation, vil kræve en regnskabsdisciplinær behandling af data før videre behandling af omkostningsdata kan finde sted jævnfør afsnit Aktiviteter Når de indirekte omkostninger i SBO er defineret, kan de indirekte omkostninger fordeles til definerede aktiviteter i virksomheden. Aktiviteterne er endvidere determineret af hvilke rapporteringsobjekter, kalkulationen fokuserer på. Lahikainen et al.(00) argumenterer således for, at aktiviteterne forbundet med rapporteringen på objekter er unik for hvert valgt rapporteringsobjekt. 118 Konkrete aktiviteter vil derfor sandsynligvis være utilgængelige i SBO. Kaplan & Anderson(08) fremfører dog, at visse processer eller aktiviteter vil være at finde i moderne IT-systemer. 119 Flere andre forskere påpeger endvidere, at visse aktiviteter er at finde i moderne ERP-systemer. 1 Universelle standardaktiviteter som kundeforespørgsler og kundebesøg kan således være tilgængelige. Det lader dog ikke til, at konkrete aktiviteter for en specifik virksomhed kan spores i SBO, da konceptet bag systemet ikke har haft overvejelser vedrørende aktivitetsbeskrivelser. Definitionen af aktiviteter ligger således uden for SBO og vil blive defineret i en ekstern applikation Costdrivere Teoretisk set vil der for at udføre en ABC-kalkulation være behov for datainformation om aktiviteternes træk på ressourcer for, at fordelingen af omkostninger fra ressourcepuljerne ned til rapporteringsobjekterne gennem aktiviteterne kan finde sted. Til dette skal der defineres og beregnes to typer fordelingsnøgler, henholdsvis ressourcecostdrivere og aktivitetscostdrivere. Først skal der findes ressourcecostdrivere, der skaber forbindelsen mellem ressourcepuljerne og aktiviteterne. Derefter skal aktivitetscostdriverne defineres, så der kan fordeles omkostninger fra aktiviteterne ud på rapporteringsobjekterne. Til beregning af costdriverne kræves der en del nødvendige data, hvilket er et problem, når der anvendes SBO, da det giver begrænset mulighed for at registrere data, der kan anvendes til beregning af ressourcecostdrivere såvel som aktivitetscostdrivere i ABC-applikationen. Problemet i SBO er, at det ikke registrerer 117 Cooper & Kaplan(1998) s Lahikanen et al.(00) s Kaplan & Anderson(08) s Baxendale & Jama(03) s. 7 64

66 tidsforbruget af virksomhedens handlinger, eksempelvis hvor meget tid virksomhedens medarbejdere bruger på de forskellige aktiviteter. Eksempler fra danske virksomheder viser, at op mod 80 % af omkostningerne fra ressourcepuljerne fordeles videre til aktiviteterne ved hjælp af beregninger foretaget på baggrund af tidsforbrug, hvilket understreger nødvendigheden af tidsregistreringerne. 121 I tilfælde af, at der skal anvendes en transaktionsdriver som aktivitetscostdriver, kan der dog findes brugbare oplysninger i SBO, da systemet ofte registrerer mængdeoplysninger. Det kan blandt andet være oplysninger, som antal ordrer hver kunde har foretaget, eller hvor mange ordrelinjer der er på hver enkelt ordre. Eller eksempelvis hvor meget tid en sælger bruger på at besøge og afslutte salg til hver af sine kunder. Derfor kan det blive nødvendigt at udvikle en ekstra applikation, der skal registrere data, der kan anvendes til beregning af både ressourcecostdrivere og aktivitetscostdrivere. Dermed vil der være to datakilder til ABCkalkulationen, hvilket er illustreret i figur 1 herunder: Figur 1: Datakilder til ABC SBO Nyt Registreringssystemer registreringssystem ABC ABC 1 Kilde: Egen tilvirkning Til ABC-kalkulationer trækkes der data fra SBO til ressourcepuljerne, mens registreringssystemet bidrager med data til beregning af costdriverne. Registreringssystemet indhenter data ved blandt andet at få bestemte medarbejdere til at registrere deres tidsforbrug på konkrete arbejdsopgaver. Tidsforbruget kan ligeledes registreres ved at observere medarbejdere udføre en bestemt handling eller proces. I så fald undgås der, at en medarbejder, bevidst eller ubevidst, registrerer et forkert tidsforbrug. Registreringssystemet kan derudover også indsamle de mængdeoplysninger, som SBO ikke har mulighed for at indsamle. Mængdeoplysningerne kan således ikke forventes at blive opsporet i SBO i forhold til en given kapacitet, der anvendes i fordelingen af omkostninger fra aktiviteter til rapporteringsobjekterne. Denne kapacitet indgår i beregningen af aktivitetscostdriverraten. Beregningen af denne rate er tilmed anset som en central 121 Bukh & Israelsen(03) s

67 del i ABC-kalkulationerne, da effektivitet i aktivitetsudførelsen samt kapacitetsspørgsmål har høj relevans i beregningen af fordelingssatserne til rapporteringsobjekterne Indtægtsdata For en ABC-kalkulation, hvor formålet er at beregne lønsomheder på produkter eller kunder, vil information om omsætningen fra produkter og kunder være interessant. I SBO kan denne information udtrækkes via nogle af de standardrapporter, der findes i systemet. Under Hovedmenu Salg Omsætningsanalyse ligger således rapporter, hvor omsætning og bruttooverskud for artikler og kunder kan aflæses. I denne rapport fremgår indtægtsdata for rapporteringsobjekterne kunder og artikler. Indtægtsdata til ABClønsomhedskalkulationer vil således være tilgængelig i SBO. 122 Cooper & Kaplan(1998) s. 1 66

68 16. Case til Modul 2 I forhold til at demonstrere dataudtræk fra SBO vil der i det følgende beskrives en case, der kan belyse problematikkerne for modul 2. Data er således allerede indtastet i demoregnskabet i SBO. Eksisterende data og yderligere indtastet data danner således grundlag for en eksemplificeret ABC-kalkulation. Casen, der er beskrevet i det følgende, er således bygget på demoregnskabet. Casevirksomheden er en grossistvirksomhed, der sælger PC-artikler. Disse artikler indkøbes og sælges uden yderligere forarbejdning. Der er i virksomheden ansat sælgere, indkøbere samt administrative medarbejdere. Virksomheden har endvidere kapacitetsrelaterede omkostninger, som husleje og elektricitet. 1 På nuværende tidspunkt er der ti kunder, som virksomheden har handlet med siden virksomhedens opstart 1. januar 06. I det følgende vil fremgangsmåden for en ABC-kalkulation på kundelønsomhed blive beskrevet. Den valgte kalkulation foretages for perioden fra 1. januar 07 til 31. december 08, altså for to hele år. Der er i denne periode sammenhandlet med otte kunder, hvorfor der kan henføres indtægter og omkostninger til disse. Virksomhedens registreringsgrundlag er blevet vurderet til at være direkte eller indirekte i forhold til omkostningsobjektet kunder, og virksomhedens definerede aktiviteter er kundebesøg, kundeforespørgsel, fakturering samt ordrebehandling. Nedenstående figur 16 illustrerer situationen: Figur 16: ABC-system i case Sælger Indkøber Administration Elektricitet Ressourcecostdrivere Kundebesøg Kunde forespørgsel Fakturering Ordrebehandling Aktivitetscostdrivere Direkte omkostninger Omkostningsobjekt: Kunder Kilde: Egen tilvirkning 67

69 Denne figur afspejler et eksempel, hvor de direkte omkostninger er vareforbrug forbundet med salget til de otte kunder. Yderligere direkte og indirekte omkostninger fordeles endvidere til de otte kunder via DMLkoder, der er anvist i efterfølgende hovedafsnit 17. E/R diagram. 1 Den praktiske eksport til ABC-applikationen, der udarbejdes i Application Express er foregået ved, at et rapporteringsværktøj i SBO under Hovedmenu Salg Omsætningsanalyse kan generere en omsætningsanalyse, hvor både indtægter og variabelt forbrug kan aflæses. Disse data eksporteres herefter via en Excelfunktionen i SBO til Access. Herefter kan indtægter og et variabelt forbrug via en ODBC-opkobling fra Access til Oracle-databasen overføres. De yderligere omkostninger, foruden det variable forbrug, udtrækkes fra finansmodulet i SBO. Tabellerne OACT og JDT1 indeholder således alle posteringer, hvor det variable forbrug ikke er medtaget. Der vælges således at eksportere konterede beløb fra specifikke konti til ABC-applikationen. Konkret er der i DMLkoden blevet valgt at selektere udgiftskonti, hvor det variable forbrug, indtægter, aktiver og passiver er udeladt. Udtrækningen sker fra OACT- og JDT1 tabellerne via Forespørgselsgeneratoren i SBO, hvilket vist i nedenstående figur 17: Figur 17: Udtræk fra hovedbogen Kilde: Egen tilvirkning 68

70 17. Entitets-Relations diagram 1 Til at løse ABC-kalkulationsopgaven er følgende E/R diagram blevet udviklet. Tankegangen bag E/R diagrammet er i høj grad i overensstemmelse med ABC-princippet, idet der både kan rapporteres på ressourcepuljer og aktiviteter. Herudover udnyttes specielt rapporteringsmulighederne i SBO. Der er endvidere blevet arbejdet med sammensatte primærnøgler, hvilket er med til at mindske muligheden for redundans i designet, og forkerte fordelinger af omkostninger i forhold til ABC-princippet. Der skal samtidig knyttes en kort kommentar til den valgte datainddragelse fra SBO. Ved at benytte registreringerne i SBO opstår der et periodiseringsproblem ved det valgte design. Dette periodiseringsproblem opstår ved, at en inddragelse af alle dataene fra hovedbogen ligeledes vil inkludere de registrerede periodeafslutninger i resultatopgørelsen. Herved vil hovedbogen altid, ved at benytte en sumfunktion over differensen mellem debetbeløbene og kreditbeløbene, vise dagsdatos saldo. Det modsatte gør sig gældende ved at benytte omsætningsanalysedataene fra SBO. Her skal der afgrænses til sidste periodeafslutning for at disse data stemmer overens med dataene fra hovedbogen. Alternativet er at slette periodeafslutninger fra hovedbogstabellen, hvorved det samlede omkostningsbeløb på kontiene gennem hele virksomhedens levetid vil fremkomme. For ikke at ændre i datamaterialet fra SBO er det valgt at afgrænse omsætningsanalyserne til sidste periodeafgrænsning, hvilket betyder, at periodiseringen er fra 1. januar 07, da der ikke er foretaget en periodeafslutning for 07 i datamaterialet. Dette gøres for at have et så stort datamateriale som muligt. E/R diagrammet til ABC-kalkulationerne ser således ud: 69

71 Figur 18: E/R Diagram til ABC-kalkulationer 1 Kilde: Egen tilvirkning - Power Architect Tabelstrukturen er opbygget på en sådan måde, at det vil være nødvendigt, at data fra SBO skal indføres i to tabeller. Dette er i tabellerne hovedbog og omsaetningsanalyse. Herudover skal virksomhedens kontoplan også indtastes i en tabel, men denne tabel bliver uden nogle omkostningsdata eller omsætningsdata, hvorfor denne tabel ikke kan fortælle noget om aktiviteten i virksomheden alene. I hovedbogen er hver bogføring på kontiene i virksomheden registreret, og i tabellen omsaetningsanalyse findes salget bruttooverskuddet fordelt på produkter og kunder. I denne tabel kan det ligeledes ses, hvor stort vareforbruget har været. Vareforbruget er udregnet som en residual mellem omsætningen og bruttooverskuddet. Tallene fra hovedbogen bliver fordelt efter ABC s fordelingsprincipper, hvilket betyder, at de indirekte omkostninger fordeles gennem ressourcecostdrivere og aktivitetscostdrivere, og de direkte omkostninger fra hovedbogen henføres direkte til omkostningsobjekterne. Herudover henføres vareforbruget og omsætningen direkte til omkostningsobjekterne fra tabellen omsaetningsanalyse. Denne proces vil blive forklaret nedenfor. Tabellerne kontoplan, kontoplansfordeling, ressourcer, ressourcefordeling, aktiviteter, aktivitetsfordeling og omkostningsobjekter løser i samspil fordelingen af de indirekte omkostninger. Tabellerne kontoplansfordeling, ressourcefordeling og aktivitetsfordeling løser de mange-til-mange-relationer, der eksisterer 70

72 tabellerne imellem. Fordelingen af de indirekte omkostninger forklares ligeledes i det følgende. Der er udviklet en tilhørende applikation i APEX, hvor alle efterfølgende views kan findes. Applikationen kan ses ud fra bilag 9. Her er tanken bag applikationen også vist. Alle kunderapporteringens screen shots i applikationen er ligeledes vedlagt som bilag, og vil blive inddraget i teksten, når selve SQL-koderne gennemgås. Til applikationen er alle SQL-koderne for produktrapporteringen også vedlagt i bilag Rapportering på omkostningsobjekterne Rapporteringen på ABC foregår således ved, at de direkte omkostninger henføres direkte til omkostningsobjekterne, og de indirekte omkostninger gennem tabelstrukturen fordeles på omkostningsobjekter. De vigtigste tabeller er hovedbogstabellen og omsætningsanalysetabellen, idet alle de andre tabeller benytter dataene herfra. Dette sker ved, at virksomhedens kontoplan er indsat i en tabel, hvorved de enkelte regi- streringer fra hovedbogen bliver aggregeret ud på kontiene i kontoplanen. Samtidig henføres de direkte omkostninger fra hovedbogen direkte til omkostningsobjekterne, og de direkte omkostninger samt omsætninger fra omsætningsanalysetabellen henføres ligeledes direkte til omkostningsobjekterne Henføring af de direkte omkostninger Da henføringen af de direkte omkostninger foregår via views fra hovedbogen og omsætningsanalysetabel- len, sættes omkostningsobjekterne lig med enten produktkoden eller projektkoden i hovedbogstabellen. Herved vil de direkte omkostninger blive henført til omkostningsobjekterne. Henføringen fra hovedbogstabellen ser således ud: Create view vw_dirob as select omkostningsobjekter.projektkode, sum(debetbelob-kreditbelob) as direkteomk from hovedbog, omkostningsobjekter where hovedbog.projektkode = omkostningsobjekter.projektkode group by omkostningsobjekter.projektkode; Som det kan ses af bilag er der direkte omkostninger til tre kunder, hvor kunden med projektkoden Norm har flest direkte omkostninger med et beløb på 2.400,- Den direkte henføring af omsætning og omkostninger fra omsaetningsanalyse sker først i et senere view, hvor omsætningen og vareforbruget benyttes til en ABC-lønsomhedsberegning Fordeling af de indirekte omkostninger Efter de direkte omkostninger er henført til omkostningsobjekterne vil de indirekte omkostninger blive fordelt. Dette sker med udgangspunkt i de enkelte poster fra hovedbogstabellen, der aggregeres gennem kontoplanstabellen. Dette sker gennem et view, hvor de direkte omkostninger fravælges ved kun at medtage registreringer med værdien null i attributterne projektkode eller produktkode, alt efter om omkostningsob- 71

73 jektet er et produkt eller en kunde. Herved undgås det, at en registrering i hovedbogen belaster omkostningsobjektet mere end én gang Først henføres omkostningerne fra kontiene ud på ressourcer. I denne forbindelse må det klarlægges, hvilke konti der kan indgå i de samme ressourcepuljer for at gøre antallet af ressourcepuljer overskueligt. Kriteriet for denne aggregering på ressourcepuljer vil normalt være, at kontiene skal have nogenlunde ens grad af variabilitet og reversibilitet. Der kan i denne forbindelse argumenteres for, at netop på grund af dette fordelingskriterium vil alle konti have én tilsvarende ressourcepulje. I E/R diagrammet er der taget højde for, at flere konti skal kunne fordeles til samme ressourcepulje. Dette sker ved at angive et RegID som primærnøgle i tabellen kontoplansfordeling. Herved kan der laves en mange-til-mange relation mellem ressourcepuljerne og kontoplanen, og en ressourcepulje kan således indeholde flere konti. Ressourcepuljerne kan ses ud fra følgende view: Create view vw_ressourcer as Select pk_ressourceid, ressourcenavn, sum(debetbelob-kreditbelob) as belob From hovedbog, kontoplan, ressourcer, kontoplansfordeling Where hovedbog.fk_kontonavn =kontoplan.pk_kontonavn and hovedbog.projektkode is null and kontoplan.pk_kontonavn = kontoplansfordeling.fk_kontonavn and ressourcer.pk_ressourceid = kontoplansfordeling.fk_ressourceid group by pk_ressourceid, ressourcenavn; Af bilag 11 kan det ses, at sælgerlønninger udgør den klart største ressourcepulje i virksomheden. Denne ressourcepulje er på ,- hvor den næststørste ressourcepulje, indkøbslønninger, kun er på 12.00,-. Der er i alt fem ressourcepuljer, der skal fordeles til kundeaktiviteterne i virksomheden. Ressourcepuljerne fordeles ud på aktiviteterne gennem tabellen ressourcefordeling. Dette sker med udgangspunkt i virksomhedens egen vurdering af aktiviteternes træk på ressourcepuljerne. Det skal derfor angives i ressourcefordelingstabellen, hvordan hver enkelt aktivitets træk på ressourcepuljerne er. Dette gøres ved at angive en procentsats som fordelingsnøgle i ressourcefordelingstabellen Her kunne der være tilføjet et registreringssystem jævnfør afsnit Til denne tabel bør det også nævnes, at der er oprettet en sammensat primærnøgle af attributterne fk_ressourceid og fk_aktivitetsid, hvorved det sikres, at én aktivitet kun kan trække én gang på én ressourcepulje. Fordelingen til aktiviteterne udregnes gennem følgen- de view: create view vw_aktiviteter as Select pk_aktivitetsid, aktivitetsnavn, sum((debetbelob-kreditbelob)*fordelingsnogle/0) as belob From hovedbog, kontoplan, ressourcer, kontoplansfordeling, aktiviteter, ressourcefordeling Where hovedbog.fk_kontonavn =kontoplan.pk_kontonavn and hovedbog.projektkode is null 72

74 and kontoplan.pk_kontonavn = kontoplansfordeling.fk_kontonavn and ressourcer.pk_ressourceid = kontoplansfordeling.fk_ressourceid and ressourcer.pk_ressourceid = ressourcefordeling.fk_ressourceid and aktiviteter.pk_aktivitetsid = ressourcefordeling.fk_aktivitetsid group by pk_aktivitetsid, aktivitetsnavn; I virksomheden er der fire aktiviteter, hvor Kundebesøg og Kundeforespørgsel er de klart største med beløb på henholdsvis 83.62,- og ,-. De sidste to aktiviteter, Fakturering og Ordrebehandling, har henholdsvis beløbsstørrelser på 6.81,- og 7.660,-. Aktivitetspuljerne kan ses ud fra bilag 12. Det sidste trin er fordelingen til omkostningsobjekter. Dette trin foretages ved at benytte aktiviteternes praktiske kapacitet og et skønnet kapacitetsforbrug af omkostningsobjekterne. Cooper og Kaplan(1998, s. 112) anser denne beregning, som grundstenen i ABC-kalkulationer jævnfør afsnit Trinnet udføres med baggrund i følgende udregning: (aktivitetspulje/praktisk kapacitet)*kapacitetsforbrug Ved at dividere aktivitetspuljen med den praktiske kapacitet fås aktivitetscostdriveren, som herefter multipliceres med omkostningsobjektets træk på aktivitetscostdriveren. Ved at benytte skønnede tal for kapaci- tetsforbruget og den praktiske kapacitet sikres det, at alle omkostninger i aktivitetspuljen fordeles, men dette fordelingsbillede stemmer nødvendigvis ikke overens omkostningsobjekternes réelle træk. Omvendt vil virksomheden ikke nødvendigvis få fordelt alle omkostninger i aktivitetspuljen ved at benytte det faktiske kapacitetsforbrug fra SBO, hvis dette kan findes. Ved at benytte faktisk kapacitetsforbrug fra SBO kan der angives en ledig kapacitet, der ikke bliver fordelt. Hvis målet med ABC-kalkulationerne er, at skabe et beslutningsgrundlag vedrørende kapacitetens størrelse vil denne metode være at foretrække. Hvis virksomheden derimod ønsker at fordele alle dens indirekte omkostninger ud på omkostningsobjekter, vil det være nødvendigt at benytte skønnede tal. Fordelingen af indirekte omkostninger til omkostningsobjekterne forekommer gennem følgende view: create view vw_omkob as Select pk_omkostningsobjekt, omkostningsobjekter.projektkode, sum(((debetbelob-kreditbelob)*fordelingsnogle/0)*kapacitetsforbrug/praktiskkap) as indomk From hovedbog, kontoplan, ressourcer, kontoplansfordeling, aktiviteter, ressourcefordeling, aktivitetsfordeling, omkostningsobjekter Where hovedbog.fk_kontonavn =kontoplan.pk_kontonavn and hovedbog.projektkode is null and kontoplan.pk_kontonavn = kontoplansfordeling.fk_kontonavn and ressourcer.pk_ressourceid = kontoplansfordeling.fk_ressourceid and ressourcer.pk_ressourceid = ressourcefordeling.fk_ressourceid and aktiviteter.pk_aktivitetsid = ressourcefordeling.fk_aktivitetsid 123 Cooper & Kaplan(1998) s

75 and aktiviteter.pk_aktivitetsid = aktivitetsfordeling.fk_aktivitetsid and omkostningsobjekter.pk_omkostningsobjekt = aktivitetsfordeling.fk_omkostningsobjekt and omkostningsobjekter.produktkode is null group by pk_omkostningsobjekt, omkostningsobjekter.projektkode; Af bilag 13 kan det ses, at omkostningsobjekter trækker meget forskelligt på aktiviteterne. De kunder, som trækker mest på aktiviteterne, trækker dobbelt så meget, som de kunder der trækker mindst på aktiviteterne. Dette berettiger således en ABC-fordeling af omkostningerne i virksomheden, da omkostningernes størrelse direkte kan relateres til kundernes træk på aktiviteterne i virksomheden, og dette træk ikke er tilnærmelsesvist ens Det samlede omkostningstræk Det samlede omkostningstræk skabes gennem en addition af omkostningsobjektets indirekte omkostninger og direkte omkostninger. Hertil inddrages omsætningsdata fra SBO for at skabe et rentabilitetsbillede af kunderne. Ved at joine primærnøglerne i tabellerne omkostningsobjekter og omsaetningsanalyse kan omsætningen og vareforbruget tildeles omkostningsobjekterne. Ved samtidig at bruge de direkte omkostnin- ger fra view et vw_dirob og de indirekte omkostninger fra vw_omkob er det muligt at finde den samlede ABC-lønsomhed. For at det er muligt at lave udregningerne via det designede E/R diagram, er det nødvendigt at foretage udregningen gennem to views. Dette skyldes, at der ikke er registreret direkte omkostninger til alle omkostningsobjekter. Det første view indeholder således ikke de direkte omkostninger fra hovedbogen. Create view vw_samletk as select omkostningsobjekter.pk_omkostningsobjekt, omkostningsobjekter.projektkode, omsaetning, vareforbrug, bruttooverskud, indomk, (bruttooverskud-indomk) as ABC_lonsomhed from omkostningsobjekter, omsaetningsanalyse, vw_omkob where omkostningsobjekter.pk_omkostningsobjekt = omsaetningsanalyse.omkostningsobjekt and omkostningsobjekter.pk_omkostningsobjekt = vw_omkob.pk_omkostningsobjekt and omkostningsobjekter.produktkode is null order by ABC_lonsomhed; Dette view viser den samlede ABC lønsomhed uden fratrækning af de direkte omkostninger. Af bilag 14 kan det ses, at virksomheden kun har to profitable kunder. De direkte omkostninger fra hovedbogen fratrækkes gennem følgende view: Create view vw_dirk as select omkostningsobjekter.pk_omkostningsobjekt, omkostningsobjekter.projektkode, omsaetning, vareforbrug, bruttooverskud, direkteomk, indomk, (bruttooverskud-direkteomk-indomk) as ABC_lonsomhed from omkostningsobjekter, omsaetningsanalyse, vw_dirob, vw_omkob where omkostningsobjekter.pk_omkostningsobjekt = omsaetningsanalyse.omkostningsobjekt 74

76 and omkostningsobjekter.projektkode = vw_dirob.projektkode and omkostningsobjekter.pk_omkostningsobjekt = vw_omkob.pk_omkostningsobjekt order by pk_omkostningsobjekt; Af bilag 1 ses det, at billedet ikke ændrer sig, da de kunder med tilhørende direkte omkostninger i forvejen havde en negativ ABC-lønsomhed efter fordelingen af de indirekte omkostninger. Lønsomheden på disse omkostningsobjekter er således bare forværret. 7

77 18. Afrunding - Modul Efter at have arbejdet indgående med ERP og ABC gennem modul 2, er der blevet oparbejdet et teoretisk fundament indenfor disse to begreber. Samtidig er der arbejdet praktisk med begreberne i udarbejdelsen af en applikation. Der er gennem undervisningspensummet i ERP og andre relevante artikler oparbejdet en forståelsesramme for ERP-begrebet. Denne forståelsesramme er uddybet i relation til SAP Business One, da netop dette system er benyttet i indeværende projekt. ABC er beskrevet i modul 1, hvorfor den teoretiske baggrund for begrebet ikke er gengivet i indeværende modul 2, men den praktiske erfaring med ABC er blevet uddybet gennem arbejdet med applikationen. Der er ligeledes arbejdet i programmerne Microsoft Access og Microsoft Excel for at kunne overføre data fra SBO til applikationen gennem databasens tabeller. Den største udfordring i modul 2 har været, at finde de nødvendige data til ABC-kalkulationerne fra SBO. Det har således ikke været muligt at finde alle de nødvendige data i SBO til ABC-kalkulationerne. Det er specielt vareforbruget og udregningen af costdrivere, der mangler data om i SBO. Vareforbruget er fundet som en residual, men denne udregning bygger på en række forudsætninger, der muligvis er valide. Herudover registrerer SBO eksempelvis ikke medarbejdernes arbejdstimer, hvorfor beregningen af varighedsdrivere og direkte måling besværliggøres. Der er derfor anvendt estimerede tal i udviklingen af en applikation. Det er blevet tydeligt, at muligheden for at overføre data fra SBO til en ekstern applikation er betinget af brugerens kendskab til SBO s tabelstruktur. Det er således muligt at finde en række brugbare data til ABCkalkulationer i SBO, men disse data ligger ofte som beregnede felter. Anvendelsen af disse data afhænger således af, at brugeren ved, hvordan udregningen af de beregnede felter foretages. Afslutningsvis er der udarbejdet en applikation på baggrund af dataene fra SBO. Denne applikation rapporterer ABC-kalkulationer på produkter og kunder, som er registreret i SBO. Der inddrages ligeledes omsætning i kalkulationen, hvorfor der laves en ABC-lønsomhedsanalyse. Applikationsudviklingen har videreudviklet erfaringen i SQL, E/R diagrammering og APEX fra modul 1. Det er specielt brugen af sammensatte primærnøgler og oprettelsen af view, der er blevet udviklet gennem modul 2. Herudover er det blevet mere gennemskueligt, hvordan et E/R diagram skal opbygges for at understøtte en ABC-kalkulation. 76

78 19. Litteraturliste Bøger: Andersen, Michael & Rohde, Carsten(01). Virksomhedens økonomistyring. 2. udgave, Jurist- Økonomiforbundets Forlag Arbnor, I. & Bjerke, B. (1997). Methodogy for creating Business knowledge. 2. udgave, Sage Publications Bukh, Per Nikolaj & Israelsen, Poul(03). Aktivitetsbaseret økonomistyring danske virksomheders erfaringer med Activity Based Costing. Jurist- og Økonomforbundets Forlag Bukh, Nikolaj P. & Israelsen, P. (04). Activity Based Costing Dansk Økonomistyring under forvandling. 1. udgave. Jurist- og Økonomforbundets Forlag. Clarck, J.M.C. (1923). Studies in the Economics of Overhead Costs. The University of Chicago Press Christensen, Jens(red.) (04). Vidensgrundlag for handlen. Aalborg Universitetsforlag Illeris, Knud(1974). Problemorientering og deltagerstyring - Oplæg til en alternativ didaktik 1 Kaplan, Robert S. & Atkinson, Anthony(1998). Advanced Management Accounting. 3. udgave, Prentice Hall Kaplan, Robert S. & Cooper, Robin(1998). Cost and Effect: Using integrated cost systems to drive profitability and performance, Boston: Harvard Business School Press Kaplan, Robert & Anderson, Steven(08). Time-driven Activity Based Costing. 1. udgave, 1. oplag. Børsens forlag Kapp, Karl et al.(01). Integrated learning for ERP success. CRC press LCC Madsen, Vagn (191). Bidrag til belysning af rationaliseringsproblemerne i industrivirksomhederne. Kbh. Madsen, Vagn (1969). Regnskabsvæsenets opgaver og problemer i ny belysning. 2. Udgave, Kbh. Teufel, Thomas et al.(0). SAP Business One. Thompson Course Technology PTR Vang, Søren (01). Relationsdatabaser og SQL. Narayana Press, Gylling 2 Warming-Rasmussen, Bent og Nørreklit, Lennart (1989). Aktuelle forskningsprojekter i og omkring revision. Foreningen af yngre Revisorer, Nørhaven A/S. 30 Artikler: Al-Mashari, Majed et al.(03). Enterprise ressource planning: A taxonomy of critical factors. European Journal of Operational Research Anderson S.R. &.Kaplan, R.S.(04). Time-driven Activity Based Costing. HBR November Baxendale Sidney J og Jama, Farah(03). What ERP can offer ABC. Strategic Finance, Aug vol. 8 nummer 2 Cooper, R. & Kaplan, R. S. (1991). Profit Priorities from Activity Based Costing. Harvard Business Review. May/Jun, Vol. 69 Issue 3, s

79 Cooper, Robin & Kaplan, Robert S.(1998). The Promise and peril of integrated cost systems. Harvard Business Review Juli-August Davenport, Thomas H.(1998). Putting the Enterprise into the Enterprise System. Harvard Business Review Juli-August Jacobs, F. Robert & Bendoly, Elliot(03). Enterprise resource planning: Developments and directions for operations management research. European Journal of Operational Research Israelsen, Poul & Reeve, James(1998). Profit reporting and analysis in complex markets and manufacturing environments. Journal of cost management, Juli-August Kaplan, Robert S (1992). In Defense of Activity-Based Cost Management - Management Accounting. Nov 1992; 74, ; Lahikainen, Tommi et al.(00). Implementing activity-based costing in an enterprise ressource planning system. Preprints of the 11th International working Seminar on Production Economics, 1. Mabert, Vincent A. et al.(00). Enterprise Resource Planning Survey of U.S. Manufacturing Firms. Production and Inventory Management Journal Nørreklit, Nørreklit & Israelsen (06). The validity of management control topoi. Towards constructivist pragmatism. Palaniswamy, Rajagoppal & Frank, Tyler(00). Enhancing Manufacturing Performance with ERP Systems. Information Systems Management Stenzel, Catherine & Stenzel, Joe(02a). From the Editors. Journal of Cost Management March/April Volume 16 Stenzel, Catherine & Stenzel, Joe(02b). ERP System Opportunities and Limitations: An Interview with Eli Goldratt. Journal of Cost Management March/April, Volume 16 Stenzel, Catherine & Stenzel, Joe(02c). ERP from the designer and vendor perspective. Journal of Cost Management March/April Volume 16 Umble, Elisabeth J. et al.(03). Enterprise resource planning: Implementation procedures and critical success factors. European Journal of Operational Research Wiese, Lars Ole(06). Rapportering med ABC-modellen ændringsforslag til modellen baseret på metodiske erkendelse og empiriske erfaringer i Økonomistyring & informatik, 21. Årgang nr. 4. Jurist- og økonomiforbundets forlag. Internet: Brodeur, Emily (00). Integrating ABC and ERP systems. Focus Magazine - for the Performance Management Professional, Issue no. 2. Forefindes på: Larsen, Karina B. (08). Krisens år: Dansk SAP-superchef ser ingen krise. Forefindes på: og Aarhus Handelshøjskole(02). SAP Business One brugerhåndbog. Kapitel 13: Omkostningsregnskab, forefindes på: (Undervisningsnotat) 78

80 . Bilag Bilag 1: E/R diagram modul 1 79

81 Bilag 2: Ressourcepuljer Bilag 3: Aktivitetspuljer Bilag 4: Tjek af fordelte ressourcepuljer Bilag : Fordeling af indirekte omkostninger til produkter 80

82 Bilag 6: Henføring af direkte omkostninger Bilag 7: Produkternes samlede omkostningstræk Bilag 8: Det enkelte produkts omkostningstræk 81

83 Bilag 9: Applikation til ABC-kalkulationer med data fra SBO Kilde: Egen tilvirkning i APEX 82

84 Bilag : Direkte omkostninger fra hovedbogen Bilag 11: Ressourcepuljer 83

85 Bilag 12: Aktivitetspuljer Bilag 13: Fordeling af indirekte omkostninger gennem ABC 84

86 Bilag 14: ABC Lønsomhedsberegning uden henføring af direkte omkostninger fra hovedbogen Bilag 1: ABC Lønsomhedsberegning med henføring af direkte omkostninger fra hovedbogen 8