Activity Based Costing og relationelle databaser

Activity Based Costing og relationelle databaser 7. semester gruppe 1 Aalborg Universitet, Økonomistyring og informatik Side 1 af 104 21-12-2009

Titelblad Projektets titel: Activity Based Costing og relationelle databaser Aalborg Universitet, Institut for Erhvervsstudier Økonomistyring og informatik, 7. semester Afleveringsdato: 21. december 2009 Antal anslag: 146.626 svarende til 61,1 normalsider Vejledere: Lars Ole Wiese, vejleder økonomistyringsteori Jens Godik Højen, vejleder IT Henrik Find Fladkjær, IT og økonomistyringsteori Projektgruppe 1, bestående af: Mathias Bech Jensen Jacob Holst Sørensen Rasmus Ingstrup Side 2 af 104

Indholdsfortegnelse Titelblad... 2 Kapitel 1: Indledende afsnit... 5 Indledning... 5 Metode... 7 Metodisk procedure... 12 Kapitel 2: Variabilitetsprincippet og ABC... 14 Problemstilling... 14 Projektdesign... 16 Præsentation af variabilitetsprincippet og ABC... 18 Variabilitetsprincippet... 18 Activity Based Costing... 21 Variabilitetsregnskabet og ABC... 24 Case: Sødtand ApS... 25 Grundbetingelser for SQL/ APEX... 28 Normalformer... 28 Integritet... 30 Introduktion til analysen... 34 Analyse af problemstilling: Variabilitetsprincippet... 35 Problemstillinger ved overgangen til ABC... 39 Analyse af problemstilling: ABC... 43 Formål... 43 Trin 1 Ressourcer til aktiviteter... 46 Trin 2 Aktiviteter til omkostningsobjekter... 50 Opnået resultat ved brug af APEX... 55 Resume... 59 Kapitel 3: ERP og ABC... 60 Problemstilling... 60 Projektdesign... 61 Introduktion til ERP systemer... 64 ERP systemer generelt... 64 SAP Business One... 68 Analyse... 69 Side 3 af 104

ABC modellens databehov... 69 Ressourcer til aktiviteter... 71 Aktiviteter til omkostningsobjekter... 79 Resultat... 90 Resume... 94 Litteraturliste... 96 Bilag... 98 Bilag 1: ABC beregning foretaget i Excel... 98 Bilag 2: Screenshot fra Schemester... 101 Bilag 3: ABC kalkulationer... 102 Side 4 af 104

Kapitel 1: Indledende afsnit Indledning Dette projekt er et økonomistyringsprojekt, hvis hovedfokus er Activity Based Costing (ABC). Økonomistyring defineres i henhold til Michael Andersen og Carsten Rohde som bevidst målrettede beslutninger, specielt under hensyn til økonomi som målelement 1. ABC kan være medvirkende til at tilvejebringe information til relevante beslutningstagere og er således en central del af økonomistyringen. ABC er i dette projekt behandlet i sammenhæng med variabilitetsprincippet og anvendelsen af et Enterprise Ressource Planning (ERP) system. I første projekthalvdel (kapitel 2) anvendes Oracle Application Express (APEX) til opbygning af en relationel database for at understøtte dataindsamlingen i forbindelse med en ABC analyse. ERP systemet SAP Business One benyttes i anden halvdel (kapitel 3). Variabilitetsprincippet og ABC Variabilitetsprincippet løser virksomhedens registreringsopgave, og denne registrering ligger til grund for ABC, hvis primære hensigt er at løse den langsigtede kalkulationsopgave. Begge opgaver er inden for det interne regnskabs rammer, hvilke anvendes til internt brug i modsætning til det eksterne regnskab, som rapporterer til virksomhedens omverden i summeret form. ABC er en rapporteringsteknik, som har afsæt i registreringerne inden for det interne regnskab. I kapitel 2 vil vi behandle forholdet mellem variabilitetsprincippet og ABC, herindunder fremsætte et forslag til, hvordan principperne kan anvendes. En væsentlig del af kapitlet vil omfatte brugen af APEX til konstruktionen af et variabilitetsregnskab som grundlag for en ABC model, og vi vil ligeledes diskutere deres indbyrdes forhold og de komplikationer, der opstår i overgangen til ABC. ERP og ABC I tredje kapitel vil ERP systemet danne grundlag for udtræk af data til en ABC-model. Det primære formål med ERP systemet er integration af virksomhedens forretningsprocesser, hvor indsamling af data sker i én database. Hvor vi i kapitel 2 konstruerer et registrerings- og afrapporteringssystem, vil der i kapitel 3 lægges 1 Andersen, Michael & Rohde, Carsten - Virksomhedens økonomistyring side 1 Side 5 af 104

hovedfokus på identifikation af relevante data, som udtrækkes til analysebehov. Vi vil i den forbindelse fastlægge hvilke data, der har været mulige at udtrække, og dermed også hvilke begrænsninger SAP Business One sætter for at udvikle en ABC-model. Hovedessensen i kapitlet er, hvordan data fra relevante tabeller kan sammensættes og efterfølgende eksporteres til videre bearbejdning i Excel med henblik på en ABC-analyse. Side 6 af 104

Metode I dette afsnit vil der blive ført argumentation for de metodiske overvejelser, der er gjort i forbindelse med projektets tilblivelse. Metodeafsnittet er medtaget, eftersom det er styrende for måden, hvorpå vi arbejder, strukturer og inddrager problemstillingen. Dette skal sikre, at den røde tråd holdes gennem hele projektet. Samtidig hjælper en konkret skildring af metoden med til at belyse det enkelte gruppemedlems opfattelse af virkeligheden for derigennem at finde et fælles metodisk udgangspunkt for gruppen. Det fælles metodiske udgangspunkt er relevant at præsentere for læseren med det sigte at skabe forståelse for anvendelsen af de figurer, principper, modeller o.l., der benyttes, samt på hvilken baggrund konklusionerne drages. Metodesyn Det følgende afsnit vil tage udgangspunkt i figuren nedenfor, som er udarbejdet af Abnor og Bjerke. Modellen har rod i undersøgelsesområder, hvor formålet er skabelse af ny viden 2. For at skabe forståelse for de beslutninger og tanker, der gøres med henblik på at tilvejebringe viden, er modellen et nyttigt redskab. Figur 1 3 Ifølge Arbnor og Bjerke er der tre metodesyn: det analytiske syn, systemsynet og aktørsynet. Udgangspunktet for disse er fire paradigmedannende elementer, i figuren paradigm, som er henholdsvis virkelighedsopfattelsen, videnskabsopfattelsen, videnskabelige idealer og etik. Grundlæggende fremstår de som et sæt af arbejdsmetoder og antagelser om verden. Nedenfor vil de fire paradigmedannende elementer blive belyst, 2 Arbnor, Ingeman & Bjerke, Björn - Methodology for creating business knowledge side 17 3 Arbnor, Ingeman & Bjerke, Björn - Methodology for creating business knowledge side 17 Side 7 af 104

hvorefter vi vil diskutere fastlæggelsen af et decideret metodesyn i dette projekt. Diskussion udmønter sig i, at vi inddrager vi andre relevante metodiske overvejelser i forbindelse med projektet. Virkelighedsopfattelse Virkelighedsopfattelsen er gruppens filosofiske syn på, hvordan virkeligheden er konstrueret altså hvordan virkeligheden, i henhold til gruppen, hænger sammen 4. Virkelighedsopfattelsen er det videnskabsteoretiske udgangspunkt, som er et produkt af blandt andet den skoling, vi har gennemgået. Dertil har vores individuelle opdragelse og omgivelser gennem vores opvækst haft en stor indvirkning på den måde, vi opfatter virkeligheden. Et eksempel er måden, hvorpå vi konfliktløser problemstillinger i såvel forskellige lande, samfund som familier. Nogle kulturer har tendens til at opfatte visse problemstillinger bedst løst gennem fysiske slagsmål, hvorimod andre opfatter det bedst løst gennem verbale slagsmål. Det er i høj grad en funktion af den familiære opfattelse samt normerne i den enkelte kultur. Dette kan overføres på den måde, vi håndterer erhvervsøkonomiske problemstillinger altså har vi nogle grundlæggende antagelser om, hvordan verden hænger sammen, der i sidste ende påvirker vores tilgang til videnskabelse. For gruppens vedkommende er en fælles overordnet virkelighedsopfattelse ikke tilgængeligt, eftersom vores skoling og opdragelse givetvis har været forskelligt. Dog er fællesnævneren samfundskulturen, som vi alle er en del af, og som giver os nogle fælles værdier. Gruppen er af den primære opfattelse, at verden i høj grad er subjektivt og socialt konstrueret. Det er menneskeskabt, det vil sige skabt af individet, som anskuer verden. Dette bevirker også, at vi har forskellige virkelighedsopfattelser, og at vi må forsøge at forene disse. Foreningen forekommer i dette teoretiske projekt ved hjælp af semantikken og logikken, idet dette hjælper os at definere og forstå ord, begreber og sætninger ens. Semantik og logik uddybes umiddelbart i forlængelse af belysningen af de paradigmedannende elementer. Videnskabsopfattelse Videnskabsopfattelsen betyder, hvordan den viden vi har tilegnet os vurderes 5. 4 Arbnor, Ingeman & Bjerke, Björn - Methodology for creating business knowledge side 15 5 Arbnor, Ingeman & Bjerke, Björn - Methodology for creating business knowledge side 15 Side 8 af 104

Dette projekt vil udelukkende bygge på allerede kendt data, altså vil vi ikke selv forestå indsamling af empiri. Med brug af selvskabt data vil vi i andet kapitel fremsætte et forslag til anvendelse af to hovedområder, som er henholdsvis variabilitetsregnskabet og Activity Based Costing, og hvordan disse kan benyttes som registreringsgrundlag og rapportering. I tredje kapitel anvender vi ligeledes selvskabt data til at eksemplificere vores analyse. Den viden som gruppen ender ud med er subjektivt kreeret, idet vi har foretaget nogle valg, anvendt et konkret system og haft en bestemt semantisk tilgang, hvilke gør dette projekt afhængig af gruppen. Navnlig er semantikken bestemmende for det definitive produkt eller viden, eftersom vores specifikke semantiske tænkemåde sætter rammerne for forståelse og de handlinger, vi begår. Videnskabelige idealer De videnskabelige idealer udtrykker, hvad der ønskes opnået med projektet 6. I dette projekt ønsker vi i første projekthalvdel at opnå en forståelse for databaseteori og SQL, samt hvordan dette kan anvendes i forhold til variabilitetsregnskabet og ABC. Forståelsen skabes ved at udarbejde et forslag til, hvordan nævnte principper kan benyttes ved hjælp af en fiktiv case. Den viden der opnås gennem disse modeller, vil kunne anvendes til at belyse om vores casevirksomheds eksisterende omkostningsfordeling er retvisende det vil sige, om omkostningsfordelingen afspejler produkternes reelle træk på virksomhedens ressourceomkostninger. Samtidig vil idealet være at få så retvisende en omkostningsfordeling som muligt, således at de rette beslutningstagere kan handle på baggrund heraf. I anden projekthalvdel, kapitel 3, er målet at opnå en forståelse for, hvorledes ERP systemer kan bruges til at understøtte ABC. Hvor ABC i kapitel 2 belyser hvilke produkter i casevirksomheden, der er profitable, er målet i 3. kapitel at foretage en lignende analyse med kunderne som omkostningsobjekt. Den ideelle situation ville opstå, såfremt det lykkedes at udføre en komplet ABC kalkulation i SAP Business One. Alternativt vil det være at kunne finde alt relevant data i databasen til selv at kunne foretage denne kalkulation. Etik Da dette er et teoretisk projekt, er det vanskeligt at diskutere etik, da det oftest forekommer ved empiriske undersøgelser. Ved sådanne studier vil der opstå etiske overvejelser, da der vil opstå menneskelige forhold at tage hensyn til. Dog er der stadig moralske og etiske aspekter i dette projekt, hvilket vil være gruppens ansvar over for indholdet i og arbejdet med projektet. Hermed menes ansvar for de analyser, vi udarbejder, 6 Arbnor, Ingeman & Bjerke, Björn - Methodology for creating business knowledge side 15 Side 9 af 104

og de konklusioner vi drager, og den baggrund de drages på Det betyder, at vi kritisk skal overveje, hvilke kilder der benyttes, og hvordan vi bruger disse for dermed at sikre at vores analyser og konklusioner bliver valide. Metodisk problemstilling Efter at have diskuteret de fire ovenstående paradigmedannende elementer burde vi umiddelbart kunne antage vores metodiske tilgang (jf. methodological approach, figur 1). Paradigmerne leder frem til et konkret metodesyn (aktør-, system og det analytiske syn), men disse mener vi ikke er brugbare til dette projekts undersøgelsesområde. De tre metode syn er hovedsagligt tiltænkt undersøgelsesområder, hvor der indsamles empiri til videnskabelse. Dette gør sig imidlertid ikke gældende for dette projekt, der som nævnt er en teoretisk og teknisk diskussion. Derfor ser vi bort fra Arbnor og Bjerkes fremgangsmåde og vil derfor ikke fortsætte med at diskutere samt tage stilling til deres metodiske tilgang. I stedet har vi valgt at fokusere på andre metodiske områder som baggrund for projektets ræsonnementer og styring. De områder vi i stedet forholder os til som væsentlige metodiske elementer er logik og semantik. Følgende vil disse kort blive gennemgået. Logik og semantik Logik er et gammelt fænomen, som stammer tilbage fra den græske oldtid. Ledt an af Aristoteles er den klassiske opfattelse, at logikken er et værktøj eller redskab for al tænkning 7+8. Det er forudsætningen for al videnskab. Endvidere fortæller den klassiske opfattelse, at uden udsagn, ingen argumenter, ingen logik. På den måde er logik tæt knyttet til sproget, hvilket benævnes semantik. Dette er essentielt at forstå, da semantikken danner udgangspunkt for logisk tænkning. Sproget, udsagn og slutninger er i det hele taget noget den klassiske logik beskæftiger sig meget med. Logik er altså forbundet med påstande/udsagn. Fx hvis A B og B C, så er A C. Dette udledes af den simple årsag, at hvis A er det samme som B, B er det samme som C; ergo må A være det samme som C. Et andet eksempel er (1) Enhver der opholder sig i et land i flere år lærer at tale dette lands sprog ganske godt. (2) N. N har opholdt sig Frankrig i flere år. (3) N. N taler fransk ganske godt 9. I bogen Logik af Justus Hartnack fremsættes flere eksempler på sådanne logiske slutninger. Hartnack forklarer, at hvorvidt konklu- 7 Hartnack, Justus Logik - Klassisk og moderne side 7 8 Øhrstrøm, Peter Logisk set side 9 9 Hartnack, Justus Logik - Klassisk og moderne side 7 Side 10 af 104

sionerne eller slutningerne er valide, er uanfægtet af den kendsgerning, at påstandene leder frem til logiske slutninger. Det er jo ikke sikkert, at N. N taler fransk ganske godt, men det må sluttes ud fra de anførte påstande. Påstandene kaldes også præmisser, hvilke således ligger til grund for slutningen. Hvis man i ovenstående eksempel accepterer præmisserne, må man ligeledes acceptere konklusionen. Det vil være ulogisk og forkert at acceptere præmisserne og samtidig benægte konklusionen. Den moderne logik har i nyere tid vundet indpas, da videnskaben har fået brug for logikken, og ikke mindst inden for datalogi er denne særlig vigtig. Sproget og logikken er til stadighed en sammenkædet størrelse, og dialog har fået en stor betydning for logik i tysk tænkning - når vi argumenterer, begrunder vi og drager slutninger efterfølgende. I den moderne logik erkender man desuden ikke i al almindelighed gyldigheden af en slutning, hvis den er taget på baggrund af urigtige præmisser (tomme udsagn) 10. Stridsspørgsmålet er i og for sig, om det er logik at slutte noget ud fra urigtige udsagn for, at slutningen (logikken) er rigtig? Eksempelvis med N. N som har opholdt sig i Frankrig i flere år. Er det logisk at slutte, at han er ganske god til fransk, selv om udsagnene er ukorrekte? Det er logik i sig selv, da udsagnene angiver noget bestemt, men ikke en valid logisk slutning, da slutningen er ugyldig. I projektet vil vi anvende logikken til håndtering og anvendelse af relationelle databaser og SQL. SQL er et sprog, som knytter en database sammen med brugeren af denne. Databaser består af tabeller, hvor strukturen er logisk opbygget, det vil sige, at tabellerne er logiske sammenkoblinger. Det er først og fremmest her, at logikken indtræder som relevant i forhold til vores projekt. For at illustrere brugen af SQL og belyse problemstillingerne forudsættes det, at vi kan operere med tabeller; oprette, anvende, udtrække samt tolke disse. For at være i stand til at tilvejebringe et godt resultat kræver det, at vi kan tænke logisk og følge logikkens lovmæssigheder, som systemet er bygget op om. Måden hvorpå vi i projektet inddrager logik er specielt i forhold til de tabeller, vi opretter med senere behov for dataudtrækning. For eksempel er databaser bygget op omkring udsagnslogik 11. I udsagnslogik sondres mellem enkle og sammensatte udsagn, hvor det er sidstnævnte, som er interessante. De sammensatte udsagn kædes sammen ved hjælp af enkle domme (betingelser), hvorefter udsagnene søger at finde sandheden. Betingelserne er bindeord såsom og, eller samt hvis.. så... Fx en konjunktion (udsagn bundet sammen af og ) er kun sand, såfremt alle ud- 10 Øhrstrøm, Peter Logisk set side 26 11 Øhrstrøm, Peter Logisk set side 34 Side 11 af 104

sagn er sande. Udsagnslogik er et simpelt eksempel på, hvordan logik er indarbejdet og bliver anvendt i databaser og SQL 12. Udsagnslogikken giver os anledning til at diskutere et andet fokuspunkt inden for logik, som dette projekt i stor udstrækning bærer præg af; sætningslogikken. De to logikformer er tæt forbundet, hvor udsagnslogikken er bindeordene, hvorimod sætningslogikken er præmisserne tilknyttet bindeordene. Det er den logik, der vil blive anvendt indenfor semantikken, for såfremt logikken ikke er holdbar må vores udledninger falsificeres. Semantik omhandler studiet af ords og sætningers betydning. Hvordan vi opfatter ord, sætninger, begreber eller termer i projektet har betydning for den måde, vi ræsonnerer på og drager logiske slutninger. Derfor vil anvendelsen af nøgleord og begreber blive konkretiseret, eftersom disse ikke er givne, dvs. meningen er universel. Begreberne er brugt i forhold til vores mentale konstruktion og opfattelse, hvorfor det er betydningsfuldt at klargøre deres mening for dermed at lægge til grund for den logiske tænkning, som vi besidder. Eksempelvis kan opfattelsen af omkostninger eller variabilitet, som i dette projekt må anses for at være nøglebegreber, være mangfoldig og have forskellige meninger 13. Tvetydigheden bestræber vi os på at eliminere, således at det eksplicit fremgår, hvilken mening der ligger bag vores logiske slutninger. Metoden i projektet vil altså forekomme ved anvendelse af logik og semantik, som gennemgået oven for. Det afspejles først og fremmest i den logiske opbygning af tabeller, som danner grundlag for vores modelkonstruktioner. Foruden dette afspejles det gennemgående ved sætningsopbygning, hvor vi er bevidste om vores konklusioner og de præmisser, som ligger til grund. På den måde bruger vi logik og semantik i forhold til den kontekst, der gør sig gældende. Metodisk procedure Metodisk procedure forholder sig til, hvordan teknikker til dataindsamling med udgangspunkt i den metodiske tilgang kommer til udtryk i projektet 14. I dette projekt forekommer der, som anført, ikke dataindsamling, idet projektet er en teoretisk og anvendelsesteknisk diskussion. Da teorien således er kravspecificerende, betyder det, at teorien sætter rammerne for, hvordan projektet struktureres, og hvordan projektets IT-systemer anvendes. I projekter, hvor der indsamles empiri, kan det i højere grad være nødvendigt at 12 Øhrstrøm, Peter Logisk set side 34 13 Øhrstrøm, Peter Logisk set side 49-51 & 70 14 Arbnor, Ingeman & Bjerke, Björn - Methodology for creating business knowledge side 16-17 Side 12 af 104

foretage afvejninger mellem de krav teorien stiller, og de forventninger en eventuel projektvirksomhed har til projektet. Da vi endvidere ikke lægger os fast på en bestemt metodisk tilgang, men i stedet anvender logik og semantik, bærer den metodiske procedure også præg af dette. Frem for at tage de indenfor metodesyn tilgængelige teknikker i anvendelse, gør vi gennemgående brug af vores logiske tænkemåde og forståelse. I vores analyse og argumentation er vi i høj grad bevidste om den logiske opbygning af systemerne og prioriterer at fremhæve disse. Særligt gennem screenshots fra APEX og SAP Business One dokumenterer vi, hvordan vi kan tilvejebringe de data, der kan understøtte den interne økonomistyring. Vores metode bærer således i højere grad præg af at have fokus på fremgangsmåden (funktioner og applikationer) i APEX og SAP Business One end de endelige resultater, vi kommer frem til på baggrund af vores ABC analyser. Ved at holde fokus på fremgangsmåden i stedet for resultaterne er det i højere grad muligt at udarbejde en let skalerbar løsning, hvor netop forståelsen for den logiske opbygning kommer til udtryk. Side 13 af 104

Kapitel 2: Variabilitetsprincippet og ABC Problemstilling Siden Vagn Madsens variabilitetsregnskab fra 1958, er der sket en kraftig teknologisk udvikling, hvilket har medført nye muligheder indenfor økonomistyringsfaget. Registreringerne blev på daværende tidspunkt foretaget ved hjælp af hulkort, hvilket var en langsommelig og ressourcekrævende opgave i forhold til medarbejdertimer. I dag kan registreringerne foretages ved hjælp af IT, hvilket betyder, at de kan ske langt hurtigere og uden det samme antal medarbejdere som tidligere. I forlængelse af den øgede registrering kan afrapporteringsdelen ligeledes foretages hurtigere, og dette harmonerer godt med virksomheders omskiftelige omverden, der fordrer hurtigere stillingtagen. At benytte variabilitetsregnskabet som registreringsgrundlag og ABC som rapportering vanskeliggøres, da der er grundlæggende forskelle på de to principper. Det kommer blandt andet til udtryk ved de omkostninger, der medtages i de to principper. Eksempelvis medtager variabilitetsregnskabet ikke afskrivninger, da dette er en arbitrær fordeling, og modsat inddrager ABC idisse. Samtidig kræver ABC en lang række målinger på de enkelte aktiviteter, som der ikke tages højde for i variabilitetsregnskabet. Dette danner baggrund for den problemstilling, der vil søges løst i dette projekt. Den valgte problemstilling lægger op til, at rapporteringen både skal have afdeling og produkt som omkostningsobjekt. Vi har dog valgt kun at rapportere med produkt som omkostningsobjekt, eftersom dette er det mest traditionelle omkostningsobjekt inden for ABC 15. Desuden er ABC processen ens uanset hvilket omkostningsobjekt, vi fokuserer på. Den primære forskel ligger i hvilke aktiviteter samt ressourcepuljer, der opereres med. Derudover er det demonstration af kendskab til teknikkerne i APEX i forhold til ABC, vi lægger vægt på i projektet. Arbejdsspørgsmål Vi har valgt følgende seminaremne fra semesterkataloget: Et forslag til anvendelse af variabilitetsprincippet som registreringsgrundlag og ABC som rapporteringsteknik med afdelingen og produktet som omkostningsobjekt. 15 Wiese, Lars Ole Rapportering med ABC modellen side 387 Side 14 af 104

Afgrænsning I forbindelse med udarbejdelsen af dette projekt har vi foretaget visse afgrænsninger. Der er blandt andet foretaget afgrænsning i forhold til brugen af de programmer, som benyttes til opbygningen af vores database. Afgrænsningen betyder, at vi har valgt at oprette vores database ved hjælp af APEX i stedet for JB SQL, da APEX er mere brugervenligt at arbejde i. I forbindelse med det fiktive databrug har vi ligeledes valgt at afgrænse os. Afgrænsningen af sket ved, at vi først og fremmest gør brug af en fiktiv case som fundament for vores analyse. Hertil at vi kun benytter data omhandlende ét regnskabsår ex post. Dertil vil vi ikke fremhæve eller diskutere hvilke foranstaltninger, ledelsen kan iværksætte på baggrund af ABC-modellens informationsgivende bidrag. Hovedessensen i projektet er at fremskaffe de data, som beslutningstagere kan agere ud fra. Med andre ord afgrænser vi os fra Activity Based Management (ABM). Desuden vil vi i vores kortfattede gennemgang af ABC principperne se bort fra andre modeller end den af Kaplan og Cooper traditionelle model 16. 16 Kaplan, Robert S. & Cooper, Robin Cost & Effect, side 83 Side 15 af 104

Projektdesign Hvor det i første kapitel, blev diskuteret, hvilken metodisk tilgang gruppen har anlagt, vil dette afsnit fokusere på, hvordan der arbejdes med problemstillingen i kapitel 2. Projektdesignet er relevant, da den sikrer en rød tråd i projektet, hvorved der opnås en præcis og stringent analyse af problemstillingen. For at give et visuelt overblik over projektets opbygning har vi valgt at udarbejde nedenstående model. Problemstilling Projektdesign Principperne ABC Variabilitetsprincippet Case Analyse af problemstilling SQL/APEX Forslag til Variabilitetsprincippet Forslag til ABC Resume Figur 2: Egen tilvirkning Side 16 af 104

Indledningsvis i kapitel 2 redegjorde vi for den problemstilling, som projektet har til hensigt at belyse. Projektdesignet er essentielt, da det ellers ikke vil være muligt at arbejde struktureret med projektet. Samtidig vil afsnittet hjælpe læseren til at forstå vores valg og bevæggrunde for disse. Herefter vil ABC princippet samt variabilitetsprincippet blive gennemgået. Disse afsnit er relevante, da det sikrer en fælles forståelse for de to principper samtidig med, at en præsentation af disse vil spore os yderligere ind på problemstillingen, og hvilke udfordringer den består af. Efter præsentationen af de to principper, vil projektets gennemgående fiktive case blive fremlagt. Vi har valgt at inddrage en case, da vi mener det hjælper med til at konkretisere problemstillingen. Samtidig vil det lette arbejdet med at udarbejde et forslag til brugen af variabilitetsprincippet og ABC, da vi får nogle konkrete tal at bearbejde. Videre vil det give os mulighed for at foretage konkrete registreringer, samt bearbejdelse af disse, hvilket vil hjælpe med at eksemplificere det endelige forslag. Som indledning til analysen præsenteres SQL og APEX, som vil blive anvendt i forbindelse med udarbejdelsen af forslaget til, hvordan variabilitetsprincippet kan anvendes til registrering og ABC som rapportering. SQL er et programmeringssprog, som i projektet benyttes til at udarbejde vores database, mens APEX er det program, vi benytter til at oprette databasen i. Årsagen til, at SQL er væsentlig er altså, at APEX benytter SQL til at kommunikere med databasen. Desuden vil afsnittet fremhæve hvilke kriterier, der skal opfyldes for, at vi kan arbejde med SQL, og for dernæst at relatere det til, hvordan det kommer til udtryk i vores projekt. En forståelse for SQL s kriterier er en nødvendighed for, at gruppen kan udarbejde et brugbart produkt ved anvendelse af APEX. Ligeledes er det relevant at forstå de logiske sammenhænge, som SQL bygger på for at kunne oprette en database, der fungerer. Selve analysen (løsningsforslaget) vil først have fokus på variabilitetsregnskabet, hvor der udarbejdes et forslag til en database. Herefter vil analysen rette sig mod ABC med på fokus på et forslag til afrapportering i APEX. Det resultat, der fremkommer, vil blive sammenholdt med den model, som casevirksomheden oprindeligt har benyttet. Derved analyseres, om ABC-modellen kan forbedre virksomhedens informationsgrundlag og dermed styrke virksomhedens beslutningstagningsproces. Side 17 af 104

Præsentation af variabilitetsprincippet og ABC Variabilitetsprincippet Regnskabsvæsenets opgaver kan ifølge Vagn Madsen samles i seks regnskabsopgaver; registreringsopgaven, overskudsopgaven, kalkulations- og prisfastsættelsesopgaven, kontrolopgaven, alternativopgaven og budgetopgaven. Registreringsopgaven danner et fælles grundlag for de øvrige fem opgaver, som har et indbyrdes samspil 17. Endvidere kan de seks regnskabsopgaver deles ind i følgende tre grupper: Overskudsopgaven, der er hovedopgaven i det eksterne regnskab (overskudsopgaven bruges dog både i interne og eksterne regnskab), kalkulations-, kontrol-, alternativ- og registreringsopgaven som vedrører det interne regnskab og sidst budgetopgaven, som belyser de fremtidige konsekvenser af de beslutninger, der forventes at blive truffet 18. Registreringsopgaven i forbindelse med det interne regnskab løses, ifølge Vagn Madsen, med sit eget udviklede variabilitetsprincip (variabilitetsregnskab), der er levelbaseret. Variabilitetsregnskabet beskrives som et grundregnskab og skal danne datagrundlag for de øvrige opgaver i det interne regnskab 19. Ideen med variabilitetsregnskabet er at registrere omkostninger i forhold til deres variabilitet. Variabilitet, eller variabilitetsfaktorerne i Vagn Madsens terminologi, defineres som de faktorer, hvormed omkostningerne varierer. Det betyder, at alle omkostninger varierer proportionelt med den faktor, de er variable i forhold til. Da det i praksis vil være en stor opgave at registrere alle faktorer enkeltvis efter variabilitet, foreskriver Vagn Madsen, at disse samles i grupper med faktorer, der varierer nogenlunde ens 20. Det er endvidere væsentligt at definere, hvad omkostninger i forbindelse med ovenstående dækker over, idet omkostninger kan forstås på mange måder. Eksempelvis Atkinson & Kaplan der definerer omkostninger som en monetær værdi af varer og services forbrugt til at opnå værdi på forbrugstidspunktet eller i fremtiden 21. Denne definition mener vi er meget dækkende for omkostningsbegrebet, men da vi tilmed er af den opfattelse, at definitionen har en bestemt svaghed, anvender vi en anden definition: Vurderet forbrug af indsatte produktionsfaktorer beskrevet i monetære termer 22. Den markante forskel på disse definitioner er, at omkostninger er vurderet, det vil sige baseret på subjektivitet. Ved fastsættelsen af omkostninger må man altså vurdere forbruget, eftersom det ikke vil være muligt at kunne måle og veje forbruget 17 Madsen, Vagn - Regnskabsvæsenets opgaver og problemer i ny belysning side 18-19 18 Madsen, Vagn - Regnskabsvæsenets opgaver og problemer i ny belysning side 20 19 Madsen, Vagn - Regnskabsvæsenets opgaver og problemer i ny belysning side 131-133 20 Madsen, Vagn - Regnskabsvæsenets opgaver og problemer i ny belysning side 133 21 Atkinson, Anthony A., mfl. Management Accounting side 36 22 Wiese, Lars Ole forelæsning 1 Side 18 af 104

af produktionsfaktorerne. Det må ske efter skønsmæssige overvejelser. Nogle produktionsfaktorer vil da være mere kontroversielle at fastsætte end andre, idet nogle er flerperiodiske samt består af forholdsvis store beløb eksempelvis afskrivninger af materielle goder. Variabilitetsregnskabet bygger på to principper henholdsvis, at der ikke forekommer arbitrære fordelinger samt variabilitetsprincippet. At regnskabet ikke indeholder arbitrære fordelinger vil sige, at der ikke forekommer skønsmæssige fordelinger, men i stedet henføres omkostningerne direkte. Dermed inddrages afskrivninger og finansielle omkostninger ikke. Det er dog en tidskrævende og ressourcetung opgave at registrere omkostninger direkte til den enkelte omkostningsfaktor, hvorfor omkostninger er systematiseret og samlet i grupperne art, sted og formål. Ved variabilitetsprincippet registreres omkostningerne i forhold til den faktor, de varierer med. Det tager udgangspunkt i, at omkostningerne påvirkes af en mængdeændring af den enkelte faktor 23. Det kan eksempelvis være, hvis virksomheden producerer færre produkter, hvilket alt andet lige betyder en ændring i antallet af materialer til produktionen o. l. Dermed er udgangspunktet i variabilitetsprincippet, at alle omkostningerne er direkte i forhold til et givet niveau under sted- og formålsdimensionerne 24. Inddelingen i art, sted og formål henføres som en hierarkisk opdeling af sted og formålsdimensionerne. Et eksempel på dette ses i figur 3. Her fremgår det, hvordan sted og formål er fordelt, hvor omkostningerne fordeles efter, hvilket hierarkisk niveau de er forbundet med. Jo mere specifikt registreringen er på det enkelte produkt, jo mere præcise data vil det give. 23 Madsen, Vagn - Regnskabsvæsenets opgaver og problemer i ny belysning side 134 24 Madsen, Vagn - Regnskabsvæsenets opgaver og problemer i ny belysning side 133-134 Side 19 af 104

Figur 3: Egen tilvirkning på baggrund af Vagn Madsen 25 Omkostningsstedet er typisk registeret som de enkelte afdelingers omkostningsforbrug. Dog kan størstedelen af omkostninger henføres på produktions- og afsætningsområdet. Tages produktionsområdet som eksempel, kan omkostningerne henføres som omkostninger der vedrører afdelingen som helhed, fx fælles bygninger. Andre omkostninger henføres til de enkelte afdelinger, hvilket eksempelvis kan være en personaleomkostning i forhold til en konkret afdeling. En sådan omkostning, der vedrører den enkelte afdeling, kan altså henføres alt efter, om den vedrører afdelingen som helhed, eller om den decideret vedrører de enkelte steder i afdelingen. Derved opnås et detaljeret billede af hvilke niveauer, der forbruger hvilke omkostninger 26. Under omkostningsformål registreres omkostninger i forhold til deres formål. Det kan eksempelvis være produktionsformål, hvor omkostningerne kan henføres til det generelle produktionsformål. Videre kan omkostningerne henføres til enkelte produkter, såfremt omkostningerne er direkte i forhold hertil, eller endda længere ned på det enkelte delprodukt, hvis omkostningerne er direkte i forhold til dette niveau. Det afhænger i stor udstrækning af hvilke niveauer, der opereres med 27. Vagn Madsen skelner altså ikke mellem 25 Madsen, Vagn - Regnskabsvæsenets opgaver og problemer i ny belysning figur 20, 21 og 22 26 Madsen, Vagn - Regnskabsvæsenets opgaver og problemer i ny belysning side 136 27 Madsen, Vagn - Regnskabsvæsenets opgaver og problemer i ny belysning side 138-142 Side 20 af 104

indirekte og direkte omkostninger, ej heller mellem variable og faste omkostninger. Alle omkostninger er direkte i forhold til et bestemt niveau. Activity Based Costing Activity Based Costing blev introduceret sidst i 1980 erne af Robert S. Kaplan og Robin Cooper, hvilke havde til formål at udvikle en bedre og mere retvisende omkostningsmodel. På daværende tidspunkt var især den amerikanske omkostningsfordelingsmodel utilstrækkelig med anvendelse af en arbitrær Full Cost metode, hvilket var hovedårsagen til ABC s lancering. At tyskerne havde benyttet en lignende model igennem flere år var ikke kendt af amerikanerne. Følgelig var ABC en innovation for USA og resten af verden inden for økonomistyring 28. Ydermere skal det understreges, at ABC er et omkostningsregnskab, som følgelig ikke inddrager indtægter. Indtægterne for perioden kan sidestilles med omkostningerne i en særskilt analyse (fx alternativopgaven eller den indadrettede overskudsopgave). Kortfattet går ABC ud på at belaste omkostningsobjekter (produkter, kunder, afdelinger o.l.) med det disse reelt trækker på virksomhedens ressourceomkostninger. Det vil med andre ord sige, at ressourceomkostningerne skal henføres til fx produkter eller kunder alt efter, hvor meget disse faktisk forbruger en kausalitets tænkemåde. Omkostningerne i fokus er de indirekte omkostninger, som ikke er direkte i forhold til det valgte omkostningsobjekt. De direkte omkostninger vil naturligvis forbruges direkte af det enkelte omkostningsobjekt, hvorfor det er interessant at belyse, hvordan de sambestemte (såvel direkte som indirekte) omkostninger kan allokeres. Den traditionelle ABC model, som også benævnes fordelingsregnskabet, fremgår af figur 4 nedenfor: 28 Jævnfør forelæsning 3 i Virksomhedens Grundregnskab af Lars Ole Wiese Side 21 af 104

Figur 4 29 Måden hvorpå ressourceomkostningerne allokeres til omkostningsobjekter sker ved hjælp af virksomhedens aktiviteter. Rationalet i 2-trinsprocessen er, at ressourceomkostningerne er erhvervet med henblik på at udføre en række aktiviteter, som skal udføre virksomhedens primære opgave. Anderledes udtrykt kræver en produktion af virksomhedens produkter en lang række aktiviteter, såsom lagring, bestilling og indkørsel af råmaterialer, omstilling af produktionen og distribution af færdigvarer, og for at aktiviteterne kan finde sted, stiller det krav om indsættelse af ressourcer, fx medarbejdere, værktøj, maskiner, leje af bygninger til produktion osv. 30 ABC-modellen, der er fundamentet i dette projekt, er fra Kaplan og Coopers Cost and Effect (jf. figur 4) 31. Det første trin i ABC-modellen består i at henføre ressourceomkostningspuljer til aktiviteterne ved hjælp af Ressource Cost Drivers (RCD). Det kan eksempelvis ske ved, at virksomhedens medarbejdere vurderer, hvor meget tid disse bruger på de forskellige aktiviteter, hvorefter ressourceomkostningerne på baggrund heraf kan fordeles. Det andet trin anvender ligeledes cost drivers, her Activity Cost Drivers (ACD), til allokering af ressourceomkostningerne fra aktiviteterne til omkostningsobjekter. Driverne, eller fordelingsnøglerne, bliver også anvendt i forbindelse med Full Cost metoden, men distinktionen fra ABC er yderst essentiel. Den fejlallokering som Full Cost opererer med er, at fordelingsnøglen er for arbitrær og mangler præcision. Almindeligvis er de simple fordelingsnøgler direkte løn eller direkte maskintid, altså volumenproportionale fordelingsnøgler, som ikke afspejler omkostningsobjekterne reelle træk på virksomhedens ressourcer. I modsætning hertil står de ABC udviklede fordelingsnøgler: transaktionsdrivere, varighedsdrivere og direkte måling. Den umiddelbare mest præcise nøgle er direkte måling, der fordrer måling på, hvor lang tid en given aktivitet tager for et givet omkostningsobjekt. Såfremt et bestemt omkostningsobjekt forbruger flere ressourcer end gennemsnittet, vil dette fremgå. Dette ville ikke fremgå af hverken transaktionsdriveren eller varighedsdriveren (varighedsdriveren finder den gennemsnitlige omkostning pr. tidsenhed) 32. Konsekvensen af så præcis en fordelingsnøgle er et omfattende målearbejde, som kan være ressourcekrævende for virksomheden. Såfremt transaktionsdriveren, som er den mindst krævende, skønnes at kunne præcisere forbruget af ressourcer for omkostningsobjekter tilnærmelsesvis, ville denne være at foretrække. Det af- 29 Modellen er en rekonstruktion af Kaplan, Robert S. & Cooper, Robin Cost & Effect, side 84, Exhibit 6-3 30 Kaplan, Robert S., mfl. Advanced Mangement Accounting side 97-98 31 Kaplan og Cooper Cost & Effect side 83-85 32 Kaplan, Robert S., mfl. Advanced Mangement Accounting side 108-109 Side 22 af 104

hænger i høj grad af et cost-benefit estimat 33. Desuden vil en nærmere diskussion af ABC umiddelbart forekomme i forbindelse med overgangen fra variabilitetsregnskabet til ABC-modellen. 33 Kaplan, Robert S., mfl. Advanced Mangement Accounting side 108-109 Side 23 af 104

Variabilitetsregnskabet og ABC I dette afsnit skildres forholdet mellem variabilitetsregnskabet og ABC-modellen for at skabe en forbindelse mellem de to principper til senere anvendelse. Efter at have gennemgået begge principper kan følgende konstateres: Variabilitetsregnskabet er et grundregnskab, hvis hensigt ikke er at løse et specifikt formål, men at danne grundlag for formålsdedikerede regnskaber. Det skal således danne en registreringsramme for andre opgaver og være udgangspunkt for opbygningen af individuelle systemer. Variabilitetsregnskabet løser regnskabsvæsenets registreringsopgave uden brug af arbitrær allokering af omkostninger eller subjektive vurderinger. ABC s fordelingsregnskab er ikke generel, men en rapporteringsteknik som i høj grad tilstræber at allokere omkostninger ved hjælp af fordelingsnøgler. ABC s fordelingsregnskab har til formål at løse sin egen specifikke regnskabsopgave og gør dermed brug af estimater og subjektive betragtninger. ABC s fordelingsregnskab har det primære formål at løse den langsigtede kalkulationsopgave 34. Som det fremgår af ovenstående, virker variabilitetsregnskabet som et naturligt udgangspunkt for løsning af ABC s primære opgave. I tilknytning til denne relation vil vi, som nævnt, komme med forslag til anvendelse af variabilitetsprincippet og efterfølgende anvende dette til brug for ABC som rapporteringsteknik. Det skal dog tilføjes, at overgangen fra variabilitetsregnskabet til ABC ikke er så problemfrit, som det måske fremstår her. Dette bliver berørt i et senere afsnit. 34 Wiese, Lars Ole - Rapportering med ABC modellen, side 400 & Bukh, Per Nikolaj, mfl. - Activity Based Costing side 26-27 & Uddrag af Vang Madsen: Regnskabsvæsenets opgaver og problemer, side 24 Side 24 af 104

Case: Sødtand ApS I dette afsnit vil projektets gennemgående case kort blive præsenteret. For at eksemplificere vores forslag til anvendelse af variabilitetsprincippet til registrering og ABC til rapportering har vi valgt at opstille en fiktiv case, der løbende vil blive inddraget i projektet. Vi fokuserer i dette kapitel primært på produktionen og de problemstillinger, som kan foreligge i forbindelse med omkostningsfordelingen heri. Grunden til dette skyldes først og fremmest, at sigtet i kapitel 2 er på produkter som omkostningsobjekt, hvorfor det vil være mest nærliggende at rette fokus der, hvor omkostningerne til produkterne forbruges. Det skal understreges, at casen er fiktiv og eventuelle sammenfald med en eksisterende virksomhed er rent tilfældig. Der er ikke brugt tid og energi på at få produktionsstørrelser, pris eller lignende til at afspejle virkeligheden, men derimod har fokus været på at opstille casen så præcist som muligt i forhold til de pointer, vi ønsker at fremhæve, således det hænger sammen med projektets problemstilling. Casevirksomheden Sødtand ApS er en forholdsvis ny virksomhed fra år 2000, som har specialiseret sig i produktion af sundt slik til samfundsbevidste individer. Produktporteføljen, bestående af økologisk Vingummi og Lakrids, blev i år 2005 yderligere udvidet med sundt økologisk chokolade med hasselnødder. Chokoladen har vist sig at være en salgssucces og indtjener umiddelbart mere i forhold til vingummi og lakrids (brutto margin i %) vingummiens og lakridsens profitabilitet er sågar faldet. Derfor har virksomheden planer om at reducere fremstillingen af vingummi og/eller lakrids til fordel for chokoladen. Men inden virksomheden begynder at foretage produktionsmæssige og strategiske beslutninger, er en grundigere analyse af virksomhedens omkostningsmodel blevet sat i værk af nytilkomne medarbejdere, idet disse mistænker, at chokoladen rent faktisk belaster Sødtand mere end det fremgår af nedenstående regnskab (jf. figur 5). Figuren er udarbejdet efter Full-Cost princippet. Her fordeles samtlige omkostninger ud på de enkelte produkter 35. I dette tilfælde er omkostningerne fordelt ud på produkterne efter det enkelte produktets omsætning. Det vil med andre ord sige, at virksomheden har fordelt sine kapacitetsomkostninger efter en volumenbaseret fordelingsnøgle. Måden hvorpå lakrids og vingummi produceres og administrativt håndteres er nogenlunde det samme, og derfor har fokus aldrig været på allokering af omkostninger til produkterne. 35 Lynggaard, Peter - Driftsøkonomi side 191-192 Side 25 af 104

Figur 5: Egen tilvirkning Det nuværende produktionsanlæg har en produktionskapacitet på 3750 timer årligt og er i stand til at fremstille både vingummi, lakrids samt chokolade. Det kræver dog meget vedligeholdelse af anlægget for hvert produktionsskift for at få dette til at køre planmæssigt. Tilknyttet produktionsanlægget er et nyindkøbt ITsystem, som holder øje med produktionsforløbet, fremtidige ordrer o.l. Derudover er der ansat flere maskinoperatører og produktionsmedarbejdere til indkøring af materialer, inspektion og kvalitetskontrol hver gang en ny produktionsserie påbegyndes. Da chokoladen er det nyeste produkt i sortimentet, arbejder salgsafdelingen ekstra meget for at gøre opmærksom på produktet samt at få det positioneret. Dette medfører mere kundekontakt og flere reklameomkostninger forbundet med chokoladen. De tre produkter vingummi, lakrids og chokolade gennemgår de samme produktionsprocesser. Virksomhedens produktionsopbygning ser ud som vist nedenfor: Side 26 af 104

Omstilling Omstilling Omstilling Råvarehåndtering Blanding af råvarer/ Opvarmning Formning Nedkøling Pakning Distribution Afdeling 1 Afdeling 2 Afdeling 3 Afdeling 4 Figur 6: Egen tilvirkning Som figuren viser, gennemgår produktet seks procestrin i produktionen, hvor det første er råvarehåndtering. Produktionsprocessen kan betragtes af figuren. Som støttefunktioner til den værdiskabende produktion er råvarehåndtering, tre omstillinger samt maskinerne. Disse processer vil i øvrigt anvendes under forslaget til en ABC model, men inden analysen med anvendelse af APEX/SQL, vil vi skildre kriterierne for overhovedet at arbejde med SQL. Side 27 af 104

Grundbetingelser for SQL/ APEX Formålet med det følgende afsnit at få de grundlæggende betingelser fastslået, inden vi opsætter database til udarbejdelse af variabilitetsregnskabet og ABC. Betingelserne er endvidere analyseret i forhold til oprettede tabeller i forbindelse med konstruktionen af variabilitetsregnskabet. Normalformer Ved omgang med relationelle databaser forudsættes det, at tabelstrukturer indfrier en række kriterier. Kriterierne er nogle grundprincipper, som er medvirkende til at optimere den logiske struktur, vi ønsker at frembringe og senere hen at arbejde med. Disse grundprincipper kaldes også normalformer. Udgangspunktet er, at tabelstrukturen er på det fysiske niveau, men entiteterne er på det logiske niveau. For at tilvejebringe en optimal og logisk tabelstruktur skal entiteterne gennemgå en normaliseringsproces, som består af normalformerne. Dette sikrer både konsistens og et logisk design. Normaliseringsprocessen omfatter seks normalformer, hvoraf de tre sidste sjældent er i anvendelse, da disse kun opstår under særlige forhold 36. Af den grund vil vi følgende kort forklare de første tre normalformer, samt diskutere hvordan disse kommer til udtryk angående opbygningen af variabilitetsregnskabet (jf. figur 3). Nedenfor er vist figur 7, som er en visuel konstruktion af vores referentielle tabeller i forhold til variabilitetsregnskabet (yderligere forklaring omkring referencer kommer senere), og denne figur vil lægge til grund for vores forestående diskussion. Figur 7: Udtræk fra Schmester 36 Vang, Søren Relationsdatabaser og SQL side 41-46 & 56 Side 28 af 104

Første normalform Første normalform sætter betingelsen, at i enhver tabel skal der eksistere en primærnøgle. En primærnøgle har til formål at identificere tabellens data entydigt det vil sige, at primærnøglen skal være unik (dog ikke NULL) og skabe relationer til ikke-nøgle attributterne 37. Primærnøglen skal, hvis muligt, helst være simpel. Dersom primærnøglen er sammensat af flere attributter, gælder samme krav. Det vil sige, at alle attributterne, og ikke kun en delmængde heraf, skal fungere som primærnøgle. Derudover sætter første normalform betingelsen, at der ikke skal forekomme repeterende grupper, hvormed menes, at der ikke må findes flere værdier i flere attributter, som udtrykker det samme. Dette problem er imidlertid ikke særlig centralt, da man i de færreste tilfælde eksempelvis ikke vil skrive medarbejdernavn to eller flere gange i samme tabel. I projektet er vi i høj grad bevidste om hvilken primærnøgle, vi har angivet i hver tabel, og om hvorvidt denne opfylder de specifikke krav til en primærnøgle. Som det fremgår af figur 7, er ID_PK_STED en primærnøgle, da denne er unik (samme værdi forekommer kun én gang) og kan identificere NAVN_STED og CHILD_STED entydigt. Det gør sig ligeledes gældende for de øvrige tabeller. Særligt skal knyttes en kommentar til tabellen CASE_REGISTRERINGER, hvor fx primærnøglen ID_PK_STED refererer til denne tabel. ID_PK_STED kan ikke være primærnøgle her, eftersom denne ikke vil være entydigt identificerende. Værdierne kan nemlig forekomme flere gange (registreringer af omkostninger med fx ID_PK_STED = 1 kan optræde adskillige gange, såfremt der tilgår dette sted mange omkostningsregistreringer). På grund af dette har tabellen en primærnøgle ID_PK_REGNR, hvis attributværdier kun forekommer én gang. Anden normalform Betingelserne til anden normalform er først og fremmest, at første normalform skal være indfriet. Dernæst kræves det, at alle ikke-attributter skal være fuldt funktionelt afhængige af primærnøglen. Det gælder ligeledes, hvis primærnøglen er sammensat, hvilket betyder, at en delmængde af primærnøglen ikke entydigt må identificere ikke-nøgle attributter. Da vi i henhold til figur 7 benytter usammensatte primærnøgler, vil disse altid være på anden normalform 38. 37 Vang, Søren Relationsdatabaser og SQL side 46-47 38 Vang, Søren Relationsdatabaser og SQL side 51 Side 29 af 104

Tredje normalform Den tredje og sidste normalform, som vi vil komme ind på, bliver opfyldt, hvis en tabel er på anden normalform. Derudover skal alle ikke-nøgle attributter være ikke-transitivt afhængige af primærnøglen. Med andre ord skal ikke-nøgle attributterne være gensidigt uafhængige, og en ikke-nøgle attribut må altså ikke være bestemmende for en anden ikke-nøgle attribut. Dette optræder ikke i vores tabeller, da alle ikke-nøgle attributterne er uafhængige af hinanden. Såfremt CASE_REGISTRERINGER havde en supplerende attribut NAVN_STED, ville tredje normalform ikke være indfriet, da det er ID_FK_OMKSTED, som NAVN_STED ville være afhængig af. Derfor er NAVN_STED placeret under CASE_OMK_STED, da denne således har afhængighed af primærnøglen, som er fuldt ud tilforladeligt. Hver gang ID_FK_OMKSTED eksempelvis har værdien 1, ved vi, hvilket sted der henvises til, idet dette fremgår af CASE_OMK_STED. Herved undgås redundans. For at opsummere, så omhandler første normalform selve primærnøglen, anden normalform om forholdet mellem primærnøglen og ikke-nøgle attributterne og tredje normalform om forholdet mellem ikke-nøgle attributterne. Set i relation til figur 7 opfylder denne samtlige af de nævnte normalformer. Integritet I dette afsnit vil vi forsætte vores normalisering af data og diskutere tabellernes integritet. Når der arbejdes med SQL, er der en række grundbegreber, som er af stor betydning for arbejdet. I normaliseringsprocessen organiseres ustrukturerede data i logiske databasedesign, så bl.a. redundans undgås, hvilket er gennemgået i ovenstående afsnit. I dette afsnit præsenterer vi, hvordan tabellerne er opbygget med bl.a. referentiel integritet. Begrebet integritet dækker over, hvordan vi sikrer sammenhæng i databasen, at data indtastes det rigtige sted, og at der er overensstemmelse mellem virkelighed og data i databasen. Først gennemgås normalvis entitetsintegritet. Hermed forstås, at alle rækker i en tabel skal være identificerbare. Det sikres ved at have en primærnøgle i hver tabel, hvilket også er beskrevet under gennemgangen af de tre normalformer. Vi vil derfor koncentrere os om referentiel integritet og semantisk integritet. Side 30 af 104

Referentiel integritet Med referentiel integritet menes integriteten mellem tabeller, hvilket eksplicit kommer til udtryk ved relationen mellem primær- og fremmednøgler. Som vist i figur 7 har entiteten CASE_REGISTRERINGER følgende fremmednøgler: ID_FK_OMKART ID_FK_OMKSTED ID_FK_OMKFORMAAL De tre fremmednøgler optræder i tabellen CASE_REGISTRERINGER og er forbundet med de tre tabeller, henholdsvis art, sted og formål. Ved at opsplitte disse i forskellige tabeller frem for at have alt samlet i en, undgås redundans, da det kun er arts ID, steds ID og formåls ID, der indgår som kolonner i CA- SE_REGISTRERINGER. Havde vi eksempelvis i stedet for skrevet navnet på art, sted og formål ind under registreringer, ville vi med både et ID og et navn sandsynligvis opleve, at der vil opstå redundante data, da fx sted ville skrives på forskellig måde (jf. 3 normalform). Dette har vi sikret os imod ved at dekomponere tabellerne og oprette fremmednøgler. Centralt i variabilitetsprincippet er det levelbaserede hierarki, hvilket vi har indbygget i tabellerne ved hjælp af referentiel integritet. I programmet Schemester (som er brugt til at illustrere figur 7) kommer det til udtryk ved et lille griseøre på tabellerne. Det dækker over, at der i samme tabel er en fremmednøgle og en primærnøgle, som er forbundne. Et eksempel på måden hvor referentiel integritet bruges i forbindelse med hierarkier, er følgende figurer fra casen. Eksempel: Tabellen CASE_OMK_STED: Side 31 af 104

Hele virksomheden Produktionsafd. Forarbejdningsafd. Afd. 1 Råvarehåndteringssted Opvarmningssted Formningsafd. Afd. 2 Køleafd. Afd. 3 Teknikafd. Afd. 5 Salg- og distributionsafd. Pakke og forsendelse afd. 4 Pakkested Forsendelsessted Reklameafd. Salgsafd. ID_PK_STED NAVN_STED CHILD_STED 1 Hele virksomheden 1 2 Produktionsafd. 1 3 Salg- og distributionsafd. 1 4 Forarbejdningsafd. 2 5 Formningsafd. 2 6 Køleafd. 2 7 Teknikafd. 2 8 Råvarehåndteringssted 4 9 Opvarmningssted 4 Figur 8: Egen tilvirkning 10 Pakke og forsendelsesafd. 3 11 Reklameafd. 3 12 Salgsafd. 3 13 Pakkested 10 14 Forsendelsessted 10 De to figurer afspejler den samme hierarkiske struktur i Sødtand ApS. Figuren til venstre afspejler Vagn Madsens variabilitetsprincip, mens tabellen til højre er rækkerne i tabellen CASE_OMK_STED. CHILD_STED er fremmednøglen og afspejler referentiel integritet i forhold til primærnøglen ID_PK_STED, som er Father til Child. De to figurer giver begge udtryk for den samme hierarkiske struktur i casevirksomheden blot illustreret forskelligt. På tilsvarende måde er tabellerne CASE_OMK_ART og CASE_OMK_FORMAAL opbygget. Side 32 af 104

Semantisk integritet Semantisk integritet omfatter selve dataindholdet i modsætning til de forrige, som omfatter selve tabelstrukturerne. Helt konkret vedrører semantisk integritet...spørgsmålet om betydningen af det, der indskrives i tabellerne 39. Når vi angiver givne attributter på nogle bestemte måder, vil det automatisk føre til forventning af indholdet altså en betydningsholdning. Især dato formatet har vi været opmærksom på at præcisere, da netop dette kan skrives på en lang række forskellige måder fx dd-mm-åååå, åååå-mm-dd, ddmm-åå osv. Dette kan give anledning til fejl og misforståelser, hvis ikke det bliver understreget, hvordan datoen skal læses. En løsning kan desuden være at angive koden Alter session, således at databasen opfører sig efter bestemt datoformat. Derudover sikres konsistens og semantisk integritet i projektet ved at klargøre samt definere, hvad vi mener med de pågældende tabeller og dertilhørende attributter. I den forbindelse vil vi knytte en kommentar til vores attribut CHILD, som kan give anledning til fejlslutninger. Vi kalder den CHILD, netop fordi den er barnet til PARENT, det vil sige faderen, som er ID_PK. Det kunne forventes, at CHILD omvendt kunne benævnes PARENT, da den henviser til ID_PK, som jo er faderen. Det er altså et spørgsmål om semantik og vores opfattelse af sammenhænge og betydning. Vi har ligeledes sikret semantisk integritet ved blandt andet at præcisere vores datatyper. I de fire viste tabeller er anvendt følgende datatyper: NUMBER VARCHAR2 DATE 39 Vang, Søren Relationsdatabaser og SQL side 158 Side 33 af 104

Introduktion til analysen Forinden analysen af variabilitetsregnskabet og ABC, vil vi illustrere hensigten med samt strukturen af denne. Figuren viser, hvordan vi med brug af Vagn Madsens variabilitetsprincip vil udarbejde en ABC-model til løsning af kalkulationsopgaven (produktkalkulation i vores tilfælde). Omkostningerne allokeres til en given virksomheds aktiviteter, hvorefter de videre allokeres til omkostningsobjekterne efter en selekteret fordelingsnøgle. Desuden skal bemærkes fællesomkostningerne, som ikke allokeres til omkostningsobjekter. Årsagen hertil findes i, at virksomhedens omkostningsobjekter ikke har direkte relation til fællesomkostningerne, hvorfor det ikke kan retfærdiggøres at fordele disse. En nærmere forklaring og diskussion kommer senere i projekt. Figuren viser endvidere aktiviteter samt produkter, som opstillet i vores fiktive case. Vingummi Lakrids Chokolade ACDR x aktivitetstræk ACDR x aktivitetstræk ACDR x aktivitetstræk Maskinaktivitet ACDR x aktivitetstræk ACDR x aktivitetstræk ACDR x aktivitetstræk Omstilling køling Omkostninger Formål Sted Art ACDR x aktivitetstræk ACDR x aktivitetstræk ACDR x aktivitetstræk Omstilling formning ACDR x aktivitetstræk ACDR x aktivitetstræk ACDR x aktivitetstræk Omstilling opvarmning ACDR x aktivitetstræk ACDR x aktivitetstræk ACDR x aktivitetstræk Råvare- Håndtering Fællesomkostninger Vingummi Lakrids Chokolade Produktkalkulation Figur 9: Egen tilvirkning Side 34 af 104

Analyse af problemstilling: Variabilitetsprincippet Figur 7 illustrerer tabelstrukturen og hierarkiet i variabilitetsregnskabet, men denne grundstruktur viser ikke registreringerne på dimensionerne omkostningsart, omkostningssted og omkostningsformål. Omkostningsdata, som er registreret i tabellen CASE_REGISTRERINGER har relation til tabellerne CA- SE_OMK_ART, CASE_OMK_STED og CASE_OMK_FORMAAL via fremmednøglerne og primærnøglernes sammenspil. På den måde kan fremmednøglerne henvise til primærnøglerne i art, sted og formålstabellerne, hvor disse har tilknyttet et navn, som senere kan anvendes til mere overskuelig fremvisning af variabilitetsregnskabet. Henføringen af omkostninger til sted og formål betinger, at vi har en række posteringer/registreringer af virksomhedens omkostninger. Disse registreringer har i forhold til Sødtand ApS fundet sted i løbet af året 2008, og er som nævnt registreret i vores oprettede registreringstabel. Et udpluk af denne registreringstabel er vist i følgende figur: Figur 10: Udtræk fra APEX Der er her posteret, hvilken omkostningsart registreringen vedrører, til hvilket formål og på hvilket sted. Eksempelvis viser registrering af 20.000 kr. to gange (nederst på figuren i femte kolonne), at beløbet er i forhold til art 7, hvilken er vedligeholdelsesmaterialer, sted 2 som er den overordnede produktionsafdeling og til sidst formål 4, som er vedligeholdelsesformål. Ved registreringsarbejdet vil 7, 2 og 4 dog ikke skulle angives, men i stedet fremkommer deres tilknyttede navne som muligheder (jf. afsnittet formål ). Dette Side 35 af 104

giver en mere overskuelig måde at registrere på, og minimerer antallet af fejl, da angivelse af tal kan give anledning til fejlindtastning. Da samtlige registreringer er registreret i forhold til art, sted og formål, vil det efterfølgende være muligt at aggregere registreringerne til et komplet variabilitetsregnskab i APEX. Det betyder med andre ord, at vi kan fremvise de summerede omkostninger på samtlige af Sødtands arter, steder og formål. Men for at vise denne summerede fordeling udarbejdes først et view (visning) i APEX. Et view er ikke en tabel, som er opbygget tidligere 40, men en visning af data afhængig af vores forespørgsel. Såfremt vi blot ønsker at få vist de registrerede omkostninger i forhold til formål, kan art og sted fravælges, og et nyt view giver os netop disse forespurgte oplysninger. Ydermere opdateres views automatisk fx i de tilfælde hvor der foretages ændringer eller tilføjelser i tabellerne. Et view viser imidlertid ikke tilføjede kolonner fra forespurgte tabeller, idet vi ikke har forespurgt disse det er udelukkende data forbundet med de bestilte kolonner. I bestræbelserne på at oprette et variabilitetsregnskab er oprettet et view, som danner baggrund for vores udtræk. Udtrækkene fremgår af følgende figurer, som er henholdsvis omkostningerne summeret på art, sted og formål. Figur 11: Udtræk fra APEX Omkostningsregistreringerne i forhold til arter er som vist i figuren. Værd at bemærke ved figuren er, at de overordnede artstyper udgøres af underkategorier. Gager er fx opdelt i kontrol, rengøring, administration og ledelse samt øvrige funktionærer, og disse beløber sig til 1.100.000 kr. samlet (kontrol: 370.000 + øvrige 40 Forta, Ben - SQL i praksis side 51 Side 36 af 104

funktionærer: 240.000 + rengøring: 390.000 + administration og ledelse: 100.000). Ved vedligeholdelses- og rengøringsmaterialer skal forstås omkostninger anvendt til vedligeholdelse (udskiftning af udstyr ved omstilling og rengøring af produktionsapparatet) Disse arter er ligeledes henført til sted, som fremgår af nedenstående figur. Figur 12: Udtræk fra APEX Efter principperne i variabilitetsregnskabet henføres arterne forskelligt til stedsdimensionen. Eksempelvis vil arten produktionsmaterialer tilgå flere steder i virksomhedens produktionsproces, og de vurderede gager vil tillige forbruges flere steder i virksomheden. Endvidere er alle salgsfremmende omkostninger fordelt til reklameafdelingen (150.000 kr. + 10.000 kr. til rengøring), hvilket er i trit med, at disse omkostninger består af tv-spots, markedsføring i blade osv. Dermed forbruges omkostningerne altså i reklameafdelingen. Side 37 af 104

Figur 13: Udtræk fra APEX Id Navn Child 1 Virk. adm. og fælles formål 1 2 Produktionsformål 1 3 Salg og distributionsformål 1 4 Vedligeholdelsesformål 1 5 Lakridsformål 2 6 Vingummiformål 2 7 Chokoladeformål 2 8 Reklameformål 3 9 Pakkeformål 3 10 forsendelsesformål 3 Figur 14: Egen tilvirkning Desuden er omkostningsregistreringerne henført til formål (jf. figur 13), hvor det blandt andet fremgår af ovenstående, at omkostninger til virksomheden som helhed, fx gager til administration og ledelse, bliver henført hertil. Det er gager, som hverken er direkte i forhold til produktionsformålet eller salgs- og distributionsformålet, men som dermed skal posteres under virksomheden som helhed. Derudover tilgår der omkostninger direkte til lakrids, vingummi og chokolade. Her er det primært direkte løn og materialer, som kan henføres direkte til produktformålet. Side 38 af 104

Variabilitetsregnskabet som grundregnskab er altså tilvejebragt ved hjælp af APEX, som det er fremgået af de tre figurer. Det skal igen understreges, at dette er et forslag til, hvordan omkostningerne kan registreres under art, sted og formål. Det bagvedliggende formål er primært at illustrere kendskab til brugen af APEX og til relationelle databaser og disses anvendelse. Tilsvarende gør sig gældende med næste afsnit, som er oprettelse af en ABC model som genstand for afrapportering. Forinden dette finder sted, vil vi konkretisere nogle af de komplikationer, som opstår med udgangspunkt i variabilitetsregnskabet som grundregnskab. Her er blandt andet inddragelsen af afskrivninger i ABC afvigende set i forhold til variabilitetsregnskabet. Problemstillinger ved overgangen til ABC Virksomhedens registreringer er foretaget i forbindelse med variabilitetsregnskabet, og problemstillingen består i at benytte disse registreringer til at foretage en ABC-model. Ifølge Vagn Madsen står registreringsopgaven, i dette tilfælde som variabilitetsregnskabet, som det fælles grundlag for overskudsopgaven, kalkulations- og prisfastsættelsesopgaven, kontrolopgaven, alternativopgaven og budgetopgaven 41. Idet ABC danner fundamentet for en alternativ-, kalkulations- og prisfastsættelsesopgave burde det være muligt at udarbejde en ABC-model på baggrund af variabilitetsregnskabet, hvilket imidlertid ikke er tilfældet. Årsagen hertil skal findes i, at variabilitetsregnskabet er en grundmodel, som danner grundlag for virksomhedens andre interne opgaver. Hertil gælder nogle bestemte regler og retningslinjer, som ikke gælder for ABC. Mængder Først og fremmest er udarbejdelse af en ABC-model begrænset af, at variabilitetsregnskabet ikke inddrager relevante mængdeforhold i forhold til omkostningerne. Ved designet af ABC-modellen er dette en nødvendighed, da omkostningsobjekterne trækker på mængder (fx tidsenheder), hvortil der er tilknyttet omkostningsbeløb. Mængdedataene må derfor hentes fra andre steder i databasen, såsom hvor mange produktionsforløb virksomheden har registreret, eller virksomhedens maskinkapacitet udtryk ved produktionstimer til disposition. Det antages, at virksomheder har kendskab til sådanne data, hvilket tillige forudsættes i projektet. 41 Madsen, Vagn - Regnskabsvæsenets opgaver og problemer i ny belysning side 18-20 Side 39 af 104

Afskrivninger En anden problemstilling er, at variabilitetsregnskabet ikke medtager afskrivninger af den årsag, at disse bygger på en arbitrær fordeling. ABC inddrager derimod afskrivninger. Forskellen afføder, at de samlede omkostninger der forekommer i variabilitetsregnskabet ikke vil være lig omkostningerne i ABC og Full Cost fordelingsregnskabet. Måden hvorpå problemstillingen løses i dette projekt, er ved at placere afskrivninger som en samlet post på 400.000 kr. under omkostningsart afskrivninger. Alternativet til ikke at medregne afskrivninger, vil være at udelade afskrivninger fra ABC analysen, og i stedet placere afskrivningsomkostningerne som fællesomkostninger (omkostninger som ikke allokeres til omkostningsobjekter mere herom senere). Derved ville problemstillingen om afskrivninger være undgået. Det anses dog for værende uhensigtsmæssigt, da det vil resultere i, at fordelingsmodellen ikke viser maskinforbrug i forhold til omkostningsobjekter, hvilket kan give et fejlagtigt resultat. Det kan eksempelvis være tilfældet, hvis ét omkostningsobjekt i højere grad trækker på maskinerne end de øvrige, hvilket ikke vil komme til udtryk i ABC analysen. Af ovenstående grunde mener vi, at det bedste resultat opnås ved at medtage afskrivninger i variabilitetsregnskabet som grundlag for ABC analysen på trods af det faktum, at det er modstridende med Vagn Madsens principper. Som afsluttende bemærkning kan det konstateres, at variabilitetsregnskabets indhold ikke er nok til at anvende ABC som afrapporteringsteknik. Ved afrapporteringen bryder vi med variabilitetsprincippet, og henter og tilføjer de tilstrækkelige data ad hoc. Ledig kapacitet En problemstilling, der eksplicit vedrører ABC, er ledig kapacitet. I variabilitetsprincippet bliver der ikke taget hensyn til, i hvilket omfang virksomheden udnytter den kapacitet, der er til rådighed. Det bliver der derimod i ABC, hvor ledig kapacitet anses som en problemstilling, som ledelsen skal forholde sig til. Ud fra den praktiske kapacitet for en given ressource kan det beregnes, om kapaciteten bliver fuldt udnyttet. Er der ved periodens slutning en kapacitetsudnyttelse på 90 % og dermed 10 % ledig kapacitet, er de 10 % en omkostning, der ikke kan fordeles på de enkelte omkostningsobjekter. Derfor skal omkostningen for den ledige kapacitet placeres som en fælles omkostning for hele virksomheden. Ræsonnementet for denne placering er, at det er et ledelsesmæssigt ansvar, at der er ledig kapacitet, og derfor er det ledelsen, der skal håndtere denne omkostning og ikke de enkelte omkostningsobjekter 42. Der kan imidlertid være andre omstændigheder, som forårsager ledig kapacitet, såsom kundeønsker eller sæsonudsving. Hvis det er et 42 Kaplan, Robert. S & Cooper, Robin Cost & Effects, side 131 Side 40 af 104

kundeønske, skal kunden eller den kundeansvarlige enhed tildeles omkostningerne, eftersom det ikke er andre omkostningsobjekter, der er skyld i den ledige kapacitet 43. Forskning og udvikling Et andet område der behandles i ABC er henføring af udviklingsomkostninger, som placeres under fællesomkostninger for virksomheden ligesom ledig kapacitet. Årsagen hertil er, at udviklingsomkostninger ikke kan fordeles ud på omkostningsobjekterne, da omkostningerne ofte er forbrugt med henblik på lancering af fremtidige produkter eller ydelser. Måden omkostningerne bliver allokeret på kan være i form af fremtidige afskrivninger til de produkter eller ydelser, som er et resultat af udviklingen. Udviklingsomkostninger kan dog forekomme i forbindelse med eksisterende produkter, hvorfor disse skal allokeres til pågældende produkter. Variabilitet og reversibilitet Slutteligt vil vi kort kommentere på begreberne variabilitet og reversibilitet i forbindelse med ABC, da navnlig variabilitet er en vital faktor i variabilitetsprincippet. ABC, som er et formålsspecifikt regnskab, vil ikke tillægge omkostningernes variabilitet samme betydning, og dette afstedkommer, at ABC ophæver den fundamentale forudsætning, som ligger i variabilitetsprincippet. Reversibilitet er et begreb, som i høj grad bruges, når der diskuteres om ressourcers bortskaffelse. Reversibilitet indebærer ganske kort, i hvilket omfang allerede anskaffet kapacitet kan afskaffes 44. Reversibiliteten er heller ikke relevant i en ABC analyse. Dog er det relevant at kende såvel kapacitetens variabilitet som reversibilitet i forhold til beslutningsovervejelser efter gennemførslen af ABC. Dersom virksomheden planlægger at fjerne et urentabelt produkt fra porteføljen efter en ABC analyse, vil overvejelser, om hvorvidt kapaciteten varierer nok, få ledelsen til at tænke på bortskaffelsesmuligheder. Det kunne tænkes, at en given medarbejder har 100 omstillingstimer pr. måned, og det urentable produkt har krævet 70 timer pr. måned. Hvis virksomheden afskaffer produktet vil den stadig skulle bruge medarbejderen. Såfremt det urentable produkt kræver 100 omstillingstimer pr. måned, vil det være nærliggende at afskaffe medarbejderen (hvis reversibiliteten er høj vel at mærke). Hvis reversibiliteten ikke er høj (fx medarbejderen har forhandlet sig til en gunstig ansættelseskontrakt) vil virksomheden have svært ved at afskaffe kapaciteten. 43 Kaplan, Robert. S & Cooper, Robin Cost & Effects, side 131-132 44 Andersen, Michael & Rohde, Carsten Virksomhedens økonomistyring, side 32 Side 41 af 104

Derfor er variabilitet og reversibilitet afgørende begreber at være opmærksomme på, når informationen fra ABC-systemet skal anvendes 45. At fjerne et omkostningsobjekter betyder således ikke nødvendigvis, at indtjeningen forbedres. De diskuterede problemstillinger oven for ser vi bort fra i vores forsimplede case. 45 Bukh, Per Nikolaj & Isralsen, Poul Activity Based Costing, side 46-48 Side 42 af 104

Analyse af problemstilling: ABC Formål I de foregående afsnit har vi præsenteret et bud på et variabilitetsregnskab. I dette afsnit vil vi behandle problemstillingens anden del; et forslag til anvendelse af ABC. For at give en mere klar retning vil vi i første instans præsentere formålet med forslaget til at løse problemstillingen, der er opsat i APEX. Vi vil opbygge et system, hvor virksomheden kan håndtere følgende: - Registrere omkostninger efter art, sted og formål - Registrere produktionslinjer - Udtrække omkostninger fordelt på art, sted og formål - Udtrække omkostninger fordelt på produkter på baggrund af ABC kalkulationen Målet er således, at virksomheden på baggrund af sin løbende registrering af omkostninger og produktionslinjer med oplysninger om hvilket produkt og i hvilken mængde der er produceret, vil kunne udtrække en rapport med oplysninger om de enkelte omkostningsobjekters omkostningstræk. Sødtand har i forvejen registreret virksomhedens omkostninger og produktionsforløb, og der er således ikke det store ekstra arbejde i at hente de oplysninger. For casevirksomheden handler det i højere grad om at strukturere dens registreringer på en sådan måde, at det efterfølgende er muligt at udtrække de nødvendige oplysninger, der skal lægge til grund for en ABC-model. Det ser således ud i APEX Application Builder: Side 43 af 104

Figur 15: Udtræk fra APEX Figur 16: Udtræk fra APEX I de viste sider på figur 15 og 16 er det muligt at registrere henholdsvis omkostninger og produktlinjer. Bemærk at der ved valg af art, sted og formål på siden Registrer omkostninger er anvendt select list, så en drop down box med valgmuligheder kommer frem. Registrer omkostninger skriver direkte i databasen i tabellen CASE_REGISTRERINGER og select list ID_FK_OMKART er en fremmednøgle, som henviser til primærnøglen i CASE_OMK_ART. Som tidligere beskrevet under normalformer undgås således bl.a. redundans med oprettelsen af flere tabeller. Tilsvarende er anvendt på Registrer produktlinjer, hvor der vælges mellem vingummi, lakrids og chokolade som produktionsserie. Side 44 af 104

Tidligere konstruerede vi et Full Cost regnskab (jf. figur 5), og dette regnskab fungerer som udgangspunkt for ABC-analysen. Først ønskes et mere retvisende billede af kapacitetsomkostningerne. Dette fremgår af nedenstående tabel, hvilket også er inkluderet i figur 11. Kapacitetsomkostninger Tabel 2 Vedligeholdelsesmaterialer kr 200.000,00 Rengøringsmaterialer kr 100.000,00 Gager kontrol kr 370.000,00 Gager vedligeholdelsesrengøring kr 234.000,00 Gager øvrige funktionære kr 240.000,00 Afskrivninger kr 400.000,00 Administration og ledelse kr 100.000,00 Gager - rengøring kr 156.000,00 Salgsfremmende kr 150.000,00 Administrationsmaterialer kr 100.000,00 Total kr 2.050.000,00 Figur 17: Egen tilvirkning I dette tilfælde er det produktionen, vi fokuserer på. Det vil sige, at det er følgende kapacitetsomkostninger vi arbejder videre med i ABC beregningen: Vedligeholdelsesmaterialer, rengøringsmaterialer, gager kontrol, gager vedligeholdelsesrengøring, gager øvrige funktionærer og afskrivninger. Nævnte omkostninger fordeles ud på omkostningsobjekterne, hvorimod de resterede omkostninger foreligger som værende fællesomkostninger (sambestemte indirekte omkostninger). Fællesomkostningerne er omkostninger, som ikke umiddelbart kan allokeres til valgte omkostningsobjekter. Grunden hertil er, at der ikke er nogen direkte kobling mellem produkterne og disse omkostninger der er ingen årsags-virkningsrelation. Vi er imidlertid bekendt med, at så vidt muligt bør alle omkostninger henføres til omkostningsobjekter, men i dette tilfælde mener vi ikke, at det er retvisende at foretage en sådan fordeling. Derfor samle disse fællesomkostninger i en pulje, hvilket senere vil komme til udtryk i form af en ekstra aktivitet der oprettes i APEX (jf. analyse af ABC). Som uddybet i beskrivelsen af casen har projektets fokus ikke været på at få casevirksomhedens produktionsstørrelse og omkostninger til at være fuldstændig retvisende for en virksomhed inden for denne branche, men derimod at bruge Sødtand til eksemplificering af opsætningen i APEX. Side 45 af 104

Trin 1 Ressourcer til aktiviteter Det første trin i ABC processen er reelt at opdele virksomhedens ressourcer i homogene ressourcepuljer i vores tilfælde efter artstyper. I vores terminologi er det første trin (fordelingstrin) at allokere ressourcepuljer til aktiviteter (jf. figur 4). For at gøre dette er det afgørende at kende virksomhedens ressourcer og de dertilhørende omkostninger. I projektet er dette allerede kendt, da disse er registeret i variabilitetsregnskabet under omkostningsart. Dog er der ikke medtaget afskrivninger, hvorfor vi tilføjer denne som en ekstra omkostningsart, som diskuteret i afsnittet om problemstilling mellem variabilitetsregnskabet og ABC. På den måde danner registreringerne i variabilitetsregnskabet grundlag for rapporteringen i form af ABC. Aktiviteternes træk på ressourcerne kan findes ved hjælp af RCD. Det kan blandt andet gøres gennem interviews af medarbejdere, målinger eller lignende. Da der benyttes fiktiv case, er aktiviteternes træk på ressourcerne forudbestemt af gruppen. Som præsenteret i casen har Sødtand fundet seks aktiviteter, som udføres af virksomhedens ressourcer: Omstilling_forarbejdning, omstilling_formning, omstilling_køling, råvarehåndtering, maskinetid samt fælles omkostninger. Figur 18: Udtræk fra APEX Figuren der ses nedenfor er oprettet i forbindelse med udarbejdelsen af ABC-modellen. Formålet med tabellen er, at den skal danne informationsgrundlag for ressourcefordelingen på de enkelte aktiviteter: Side 46 af 104

Figur 19: Udtræk fra APEX Figuren viser, at hver gang der registreres en given art, vil dette fordele sig i henhold til fordelingsnøglen. Det kan eksempelvis ses ved arten vedligeholdelsesmaterialer (ID_FK_ART = 7), der fordeles til de tre omstillingsaktiviteter ID_FK_AKTIVITET = 1,2,3, hvor aktivitet 1 tildeles 30 % af ressourcen, aktivitet 2, 30 %, mens aktivitet 3 tildeles 40 %. Det kan endvidere ses, at afskrivninger er direkte i forhold til aktivitet 5 (maskine), hvor fordelingen sker ved en fuldstændig fordeling til aktivitet 5. Med kendskab til hvilke aktiviteter hver registrering/art forholdsmæssigt tilgår, er det muligt at udregne hver aktivitets samlede omkostninger. Figur 20 viser, hvilke omkostninger der er forbundet med de enkelte aktiviteter efter den fordeling, der blev vist i figur 19. Figuren er et view, der er udarbejdet med det formål at finde frem til fordelingsbeløbet for på den måde at kunne fordele ressourceomkostningerne til aktiviteterne. Figur 20 viser dog kun et udsnit af det samlede view på over 200 rækker: Side 47 af 104

Figur 20: Udtræk fra APEX Ligesom i figur 19 kan det anslås, hvordan fordelingen af omkostninger tildeles procentvis til aktiviteterne, men i figur 20 kan det videre ses, hvilke omkostninger denne fordeling påfører aktiviteterne. Ses der på registrering 59 forekommer den som konsekvens af, at der sker omstillinger. Omkostningerne for disse omstillinger er samlet set på 20.000 kr., men på grund af den fordeling, der er bestemt, er omkostningerne tildelt hver af de tre omstillingsaktiviteter ikke det samme. Det indebærer, at aktivitet 1 og 2 begge skal påføres omkostninger på 6.000 kr., mens aktivitet 3 skal påføres 8.000 kr. ved denne registrering. Kolonerne i figur 20 stammer fra de tabeller, som viewet er bygget på dog er kolonnen fordelingsbeløb en kolonne, der er udregnet i dette view ved brug af en indsat SQL kildekode. SQL kildekoden for viewet fremgår nedenfor, og det eneste vi har tilføjet er oprettelsen af kolonnen Fordelingsbeløb, som er markeret med gult. Side 48 af 104

Select "CASE_REGISTRERINGER"."ID_PK_REGNR" as "ID_PK_REGNR", "CASE_OMK_ART"."NAVN_ART" as "NAVN_ART", "CASE_AKTIVITETER"."NAVN_AKTIVITET" as "NAVN_AKTIVITET", "CASE_AKTIVITETER"."ID_PK_AKTIVITETER" as "ID_PK_AKTIVITETER", "CASE_RESSOURCEFORDELING"."FORDELING" as "FORDELING", "CASE_REGISTRERINGER"."BELOEB" as "BELOEB", "CASE_RESSOURCEFORDELING"."FORDELING" * "CASE_REGISTRERINGER"."BELOEB" as "FORDELINGSBELOEB", "CASE_OMK_ART"."ID_PK_ART" as "ID_PK_ART", "CASE_REGISTRERINGER"."ID_FK_OMKFORMAAL" as "ID_FK_OMKFORMAAL", "CASE_REGISTRERINGER"."ID_FK_OMKSTED" as "ID_FK_OMKSTED" from "CASE_REGISTRERINGER" "CASE_REGISTRERINGER", "CASE_OMK_ART" "CASE_OMK_ART", "CASE_RESSOURCEFORDELING" "CASE_RESSOURCEFORDELING", "CASE_AKTIVITETER" "CASE_AKTIVITETER" where "CASE_OMK_ART"."ID_PK_ART"="CASE_RESSOURCEFORDELING"."ID_FK_ART" and and "CASE_OMK_ART"."ID_PK_ART"="CASE_REGISTRERINGER"."ID_FK_OMKART" "CASE_AKTIVITETER"."ID_PK_AKTIVITETER"= "CASE_RESSOURCEFORDELING"."ID_FK_AKTIVITET" Figur 21: Udtræk fra APEX For at finde fordelingsbeløbet inddrages værdierne i kolonnen Fordeling i tabellen CA- SE_RESSOURCEFORDELING, som er de værdier, der er angivet i figur 19, og som viser, hvordan aktiviteterne trækker på ressourcerne. De værdier er således multipliceret med værdierne fra kolonnen Beloeb i samme tabel. Resultatet ses i den linje, der er markeret med gult. as kommandoen er sat på for at navngive kolonnen, der skal oprettes, hvilken benævnes Fordelingsbeloeb. Næste skridt er, at fordelingsbeløbene for aktiviteterne summeres sammen, og derved findes de samlede omkostninger, som er allokeret til hver aktivitet. Omkostningerne forbundet med ressourcerne er nu henført til aktiviteterne, hvilket betyder, at omkostningerne kan fordeles fra aktiviteterne til omkostningsobjekterne. Denne proces vil blive gennemgået i det kommende afsnit. Side 49 af 104

Trin 2 Aktiviteter til omkostningsobjekter Efter at have allokeret ressourceomkostningerne til Sødtands aktiviteter er næste trin i ABC processen at fordele omkostningerne til omkostningsobjekterne alt afhængig af disses individuelle træk på aktiviteterne. Aktiviteterne optræder i denne forbindelse som pejlemærke mellem ressourceomkostningerne og omkostningsobjekterne. Helt specifikt vil processen bestå i at udregne en Activity Cost Driver Rate (ACDR) for hver aktivitet (i vores tilfælde fem aktiviteter fællesomkostningerne allokeres ikke), og herefter belaste produkterne i forhold til, hvor meget produkterne trækker på aktiviteterne. Dette er i korte træk processen i trin 2, hvilket vi i forlængelse af trin 1 vil demonstrere ved hjælp af APEX. Vi vil desuden forklare de problemstillinger, vi er stødt på undervejs i trin 2, og de tanker vi har gjort os derom. Som sagt er aktiviteterne bindeled mellem omkostningsobjekternes træk på ressourceomkostningerne. Måden vi i projektet vil allokere omkostningerne til produkterne på, er ved hjælp af ACDR s for hver aktivitet. Fremgangsmåden kan ses af nedenstående kalkuler: (Omkostninger henført til omstilling 1 / samlede tid forbrugt på omstilling 1) x individuelle produkter (Omkostninger henført til omstilling 2 / samlede tid forbrugt på omstilling 2) x individuelle produkter (Omkostninger henført til omstilling 3 / samlede tid forbrugt på omstilling 3) x individuelle produkter (Omkostninger henført til råvarehåndtering / antallet af produktionslinjer) x individuelle produkter (Omkostninger henført til maskine / samlede tid forbrugt på maskinen) x individuelle produkter Efter at have kalkuleret produkternes tildelte omkostninger for hver aktivitet er opgaven endvidere at aggregere disse omkostninger for hvert produkt. Dermed opnås de respektive produkters samlede træk på Sødtands indirekte omkostninger. For at opsummere det hidtidige forløb i ABC-modellen ganske kort: I viewet RESSOUR- CER_TIL_AKTIVITETER er omkostningerne fordelt ud på aktiviteter betinget af fordelingsnøglen. Udtrækket heraf kan ses af figur 22. Side 50 af 104

Figur 22: Udtræk fra APEX Den ACDR vi ønsker at udregne er i forhold til den femte Aktivitet Maskine (ID_PK_AKTIVITET = 5). Hertil har vi ved hjælp af en SQL tilføjelse oprettet et view, som viser de samlede maskintimer anvendt i hele perioden. De samlede maskintimer er fremfundet ved hjælp af kendskab til produkternes kapacitetstræk. Figuren nedenfor viser, at der fx kan produceres 50 stk. af produkt 1 (chokolade) pr. time. Når vi i tabellen Produktionslinjer ved, hvor meget der samlet er produceret af produkt 1, 2 og 3, kan vi dividere antallet af producerede produkter med PRODUKTION_TIME, hvorefter der fås et udtryk for det samlede anvendte maskintimer. Figur 23: Udtræk fra APEX Det fremgår af nedenstående figur, at Sødtand eksempelvis har produceret 1000 stk. 6 gange, og at det tager virksomheden 20 timer at gennemføre hver serie. Figuren viser blot et udpluk, og det vises kun for chokolade. Måden hvorpå vi finder frem til FORBRUGT_MASKINTID er ved at indsætte en SQL sætning, hvor vi dividerer ANTAL med PRODUKTION_TIME. Side 51 af 104

Figur 24: Udtræk fra APEX På nuværende tidspunkt har vi forudsætningerne for at kalkulere en ACDR for aktiviteten maskine ; de samlede ressourcer tilgået aktivitet med id nummer 5 og de samlede maskintimer: SUM (Omkostninger tilgået maskine ) = aktivitet 5 SUM (Samlede maskintimer eller FORBRUGT_MASKINTID ) Men allerede her må vi sande den første forhindring i APEX. Ved at indtaste SQL kildekoden: Select SUM ("FORDELINGSBELOEB") / SUM ("FORBRUGT_MASKINTID") as "ACD_AKT_MASKINE" from "RESOURCE_TIL_AKTIVITET" "RESOURCE_TIL_AKTIVITET", "FORBRUGT_MASKINTIMER3" "FORBRUGT_MASKINTIMER3" where "ID_PK_AKTIVITETER" = 5 Figur 25: Udtræk fra APEX fås et beløb, som ikke harmonerer med forespørgslen. Resultatet bliver et urimelig højt tal præcist 18 gange så meget, som den ACDR der burde fremkomme (ACDR = 294,4). Derfor prøver vi særskilt at fremstille views for både SUM (FORDELINGSBELOEB) for aktivitet = 5, og for SUM (FORBRUGT_MASKINTID) og derefter at dividere de resulterende SUM forekomster fra de to views. Summen fra FORDELINGSBELOEB bliver 1.104.000 kr. og summen fra FORBRUGT_MASKINTID bliver 3.750 timer (det vil sige Sødtand har anvendt alt kapacitet til disposition). Disse summer fra de to nye oprettede views anvendes til at udregne ACDR for aktiviteten maskine, så vi får resultatet, som fremgår nedenfor: Side 52 af 104

Figur 26: Udtræk fra APEX Problemstillingen består i, at vi har oprettet to unødvendige og overflødige views for at komme frem til et tredje view (ACDR_maskintimer). Vi må erkende, at hvis samme fremgangsmåde ligeledes er aktuel, når vi skal finde ACDR for de andre aktiviteter, så bliver antallet af views så mange, at det bliver uoverskueligt at præsentere for læseren. For at rekapitulere: Vi måtte oprette to særskilte views (SUM af ressourceomkostninger og SUM af forbrugt maskintimer) for derigennem at få to resultater i hvert sit view, hvorefter vi dividerede disse til et tredje view: ACDR for maskinaktiviteten, hvilket var vores endelig mål. Herefter drejer det sig om at multiplicere, hvor meget Sødtands tre produkter individuelt trækker på aktiviteten. Dette gør vi ved benyttelsen af et group by kriterium. Det vil sige, at vi vil udtrække ACDR * SUM (FORBRUGT_MASKINTID) as OMK_FORDELING med gruppering af group by efter ID_FK_PRODUKT (jf. figur 27 og figur 28): select from group by "ACDR_MASKINTIMER" * SUM ("FORBRUGT_MASKINTID") as "OMK_FORDELING", "ID_FK_PRODUKT "FORBRUGT_MASKINTIMER3" "FORBRUGT_MASKINTIMER3", "ACDR_MASKINTIMER1" "ACDR_MASKINTIMER1" "ID_FK_PRODUKT Figur 27: Udtræk fra APEX Side 53 af 104

Figur 28: Udtræk fra APEX I SQL kommandoen vil vi altså her gruppere de tre produkters ID_FK_PRODUKT, således at alle 1 ernes (chokolade), 2 ernes (lakrids) og 3 ernes (vingummi) OMK_FORDELING sammenlægges, altså hvor vi ønsker at vise chokolades, vingummiens og lakridsens belastning af omkostninger på aktivitet 5. I vores tilfælde får vi ikke lov til denne gruppering, hvorfor vi ser os nødsaget til at oprette tre views med de tre produkters individuelle forbrugte tid og herefter multiplicere den forbrugte tid med ACDR_MASKINTIMER. Således for chokolade: Figur 29: Udtræk fra APEX I stedet for ét samlet view indeholdt de tre produkters omkostningstræk må vi igen oprette flere views end umiddelbart nødvendigt. Figuren oven for viser eksempelvis, hvordan chokoladen i sit særskilte view trækker på maskinaktiviteten (1000 timer ud af 3750 timer), og hvilken ACDR vi skal multiplicere maskintiden med for at få det endelige resultat på 294.400 kr. Side 54 af 104

På dette tidspunkt vil vi evaluere den proces, vi netop har været igennem for at udregne produkternes træk på aktivitet 5 maskine og de dertilhørende omkostninger. Først og fremmest har vi måtte oprette mange views, når vi skulle: 1) kalkulere ACDR for aktivitet 5, 2) allokere omkostningerne fra aktiviteterne til produkterne ved hjælp af ACDR. Vores hensigt med ABC-modellen - at denne opdaterer sig selv - vil ad denne omvej kunne opfyldes, hvis vi gør tilsvarende for de øvrige aktiviteter. Med den fremgangsmåde vil vi kunne finde produktomkostningerne for chokolade, lakrids og vingummi i APEX for alle aktiviteter og aggregere disse med intentionen om at foretage en produktkalkule. Dette vil vi ikke virkeliggøre, efter vi er kommet frem til en brugbar fremgangsmåde med henblik på at oprette en ABC-model i APEX. Ændres forudsætningerne (fordelingsnøgler, registreringsbeløb osv.) vil disse automatisk opdateres i forhold til produkter. Såfremt Sødtands afskrivninger i stedet blev fastsat til 500.000 i stedet for 400.000, ville dette få indvirkning på de samlede ressourceomkostninger henført til aktiviteten maskiner og dermed også ADCR og omkostningsbeløbet, som de individuelle produkter tildeles. Dette ville ske som følge af de relationer, vi har etableret og de views, som henviser til hinanden. Så straks selve strukturen er på plads, vil registreringerne efterfølgende automatisk blive henført. Den ideelle situation ville forekomme, dersom det var muligt at kalkulere aktiviteternes ACDR ved hjælp af ét enkelt view (SUM/SUM). Derefter at multiplicere denne fremfundne ACDR med de respektive produkters belastning (1000 timer for chokolade, 1250 timer for vingummi og 1500 timer for lakrids) og få omkostningsfordelingen for produkter i alt kun to views frem for over ti views pr. aktivitet. Med dette gjort på samtlige aktiviteter ville vi endeligt kunne summere produkternes omkostningstræk på aktiviteterne; eksempelvis chokoladens omkostningstræk på henholdsvis aktivitet 1, 2, 3, 4 og 5 til sidst adderet som alle omkostninger henført til chokoladen. Således ville de samlede kalkulerede omkostninger kunne findes på henholdsvis chokolade, vingummi og lakrids. Ressourceomkostningernes allokering til produkterne via aktiviteterne ville efterfølgende kunne sammenholdes med produkternes direkte omkostninger, hvorefter en samlet omkostningskalkulation pr. produkt ville være en realitet. Konklusionen bliver efter vores erkendelse, at vi er nået frem til et brugbart forslag til, hvordan ABC kan etableres i APEX med en komplet ABC struktur. På trods af de besværlige omveje kan de nødvendige udtræk findes, og hermed kan ABC-kalkulationen foretages. Opnået resultat ved brug af APEX Dette afsnit vil sammenfatte, hvad det er lykkedes at opsætte i APEX, og hvilke konsekvenser dette har for virksomhedens Full Cost regnskab. Side 55 af 104

Det er lykkedes at opsætte en database i APEX, således at ressourcerne fordeles til aktiviteter og efterfølgende fra aktiviteter til de enkelte produkter. Tilføjes der eksempelvis en ekstra registrering eller produktionslinje, har dette konsekvens for relevante tabeller, så der ved et nyt udtræk vil fremkomme et opdateret billede af de forskellige omkostninger fordelt til produkter som omkostningsobjekt. Det er imidlertid kun ved registrering af omkostninger, der fordeles til aktiviteten maskine, dette er opsat. Grunden hertil er, at vi har præsenteret et løsningsforslag til, hvordan en ABC-model kan opsættes i APEX, og fremgangsmåden for de øvrige aktiviteter vil være den samme. Hvilke omkostninger der allokeres til hvilke omkostningsobjekter, kan således efterfølgende betragtes af nedenstående figur fremstillet i Application Builder: Figur 30: Udtræk fra APEX Antallet af maskintimer for produktet chokolade er summen af timer registreret på dette produkt på siden Registrer produktionslinjer, hvor tabellen CASE_PRODUKTIONSLINJER er udgangspunkt. ACDR for aktivitet 5 multipliceres med chokoladens forbrugte maskintimer, der ligeledes udregnes automatisk hver gang, der registreres en omkostning eller registreres en produktionslinje, der indgår i denne beregning. På baggrund af dette udregnes Activity Expenses for chokolade (294.400 kr.), som fremgår af virksomhedens nye fordelingsregnskab fremstillet i Excel: Side 56 af 104

Figur 31: Udtræk fra Excel Fordelingsregnskab efter implementering af ABC Vi vil ganske kort fremhæve hovedkonklusionerne, vi kan drage efter implementering af ABC i virksomheden. Kapacitetsomkostningerne er i ovenstående figur delt i to. Hovedparten af omkostningerne (1.664.000 kr.) er fordelt efter ABC-principperne, mens de resterende 386.000 kr. er samlet som fællesomkostninger. Virksomhedens samlede resultat vil naturligvis være det samme både før og efter ABC implementeringen med en overskudsgrad på 9 %. Men efter implementeringen er virksomhedens bruttomargin imidlertid steget, da flere omkostninger nu fremstår som fællesomkostninger, der ikke allokeres til de enkelte produkter. Produkterne havde før implementering af ABC følgende brutto margin: Vingummi på 146.736 kr. (8,2 %), lakrids 162.755 kr. (9,0 %) og chokolade 60.160 kr. (12,0 %). Det nye produkt chokolade var således det produkt med den højeste brutto margin. Efter implementering af ABC og et ændret fordelingsregnskab er billedet et andet: Vingummi 461.505 kr. (25,6 %), lakrids 558.335 (30,8 %) og chokolade -264.210 kr. (-52,8 %). I Sødtand viser fordelingsregnskabet efter implementering af ABC, at chokolade bidrager negativt til resultatet. Side 57 af 104

De salgsfremmende omkostninger er ikke fordelt efter en ABC kalkulation. Vi har valgt at forudsætte, at det faktisk var muligt for virksomheden at fordele en række af salgsomkostningerne direkte til produkterne ved at se nærmere på modtagne fakturaer fra tilknyttede eksterne reklamebureauer. Den resterende del der ikke kan fordeles direkte, som fx fælles produktkatalog og virksomhedsbranding, placeres under fællesomkostninger og allokeres således ikke til produkterne som en arbitrær fordeling. Da det er opsætningen af en database i APEX og anvendelse af variabilitetsprincippet og ABC i forbindelse hermed, der er i fokus, vil vi ikke redegøre yderligere for virksomhedens fordelingsregnskab. Alle tabeller fra Excel til ABC kalkulationen er vedlagt som bilag. Afdelingen som omkostningsobjekt Vi har fokuseret på produktet som omkostningsobjekt, men i princippet vil det være muligt at foretage lignende beregninger med afdelingen som omkostningsobjekt. Vi har tidligere beskrevet, at ved opbygning af databasen er det i vores eksempel muligt at tilføje de ekstra tabeller eller kolonner, der gør det muligt at have forskellige omkostningsobjekter, og dette gør sig også gældende for afdelingen som omkostningsobjekt. Side 58 af 104

Resume Oracles database, SQL og Application Express Fokus i dette kapitel har været på anvendelse af relationelle databaser i en erhvervsøkonomisk kontekst med udgangspunkt i en Oracle database. I dette kapitel demonstrerer vi kendskab til en række databaseværktøjer, såsom at opsætte tabeller, primærnøgler, fremmednøgler og funktionelle afhængigheder. Vi redegør ligeledes for, hvordan disse lever op til de tre første normalformer og diskuterer vores tabellers integritet. SQL kommandoer til at oprette tabeller og lignende er generelt udeladt, men medtaget såfremt vi finder dette relevant. Det er primært tilfældet, hvor vi har multipliceret og divideret forskellige kolonner og anvendt Query Builder funktionen i APEX, der lægger ud over simple kommandoer. Økonomistyringsteori I denne seminarrapport er der arbejdet med et forslag til anvendelse af variabilitetsprincippet til registrering og Activity Based Costing som rapportering. Seminarrapporten indeholder således en kort præsentation af principperne og et forslag til anvendelse med særlig fokus på de problemstillinger der opstår ved overgangen fra variabilitetsregnskabet til ABC, eksempelvis diskussionen om afskrivninger. I APEX er der opbygget en relationel database, hvor der kan registreres omkostninger efter variabilitetsprincippet i en registreringstabel og registreres produktionslinjer i en produktionslinjetabel. På baggrund af dette kan dannes et overblik over omkostninger efter Vagn Madsens dimensioner art, sted og formål og en rapportering på baggrund af ABC. Der inddrages i kapitlet en gennemgående fiktiv casevirksomhed til at eksemplificere vores forslag, som kaldes Sødtand Aps. I casen beskrives tre produkter, og netop produktet anvendes som omkostningsobjekt. Side 59 af 104

Kapitel 3: ERP og ABC Problemstilling I anden del af projektet vil vi behandle ABC-principperne i forhold til et Enterprise Ressource Planning (ERP) system her SAP Business One som grundlæggende er et komplet informationssystem, der integrerer mange af virksomhedens funktioner. ABC har til hensigt at løse virksomhedens kalkulationsopgave, men for at løse opgaven fordrer det først og fremmest, at data foreligger i den form og mængde, som økonomistyringsmodellen forespørger. Et af ERP systemets mest fundamentale funktioner er lagring af virksomhedens data, hvoriblandt centrale data i forhold til udarbejdelsen af en ABC analyse skal kunne findes. I kapitlet er problemstillingen, hvorledes en ABC analyse kan foretages i SAP Business One, og hvorledes de nødvendige data er at finde og bearbejde i systemet? Den erhvervsøkonomiske problemstilling i semesterkataloget er: I hvilket omfang kan der findes relevante data i SAP Business One mhp. at understøtte en ABC kalkulation? Hvordan kan eventuelle databehov beskrives og udvikles som prototype i en applikation? Det er en generel antagelse, at 20 % af en virksomheds kunder genererer 80 % af virksomhedens indtjening 46. Kunder der intuitivt er rentable, eksempelvis på grund af stor omsætning, kan belaste virksomhedens ressourcer meget i form af store forventninger (fx Just in Time) eller store krav til services, hvorfor disse kan være urentable. En bidragsmodel eller Full-cost model, som flere virksomheder har anvendt eller til stadighed anvender, vil ikke afspejle denne realitet, men en ABC-analyse kan derimod give et mere retvisende billede af kundeprofitabiliteten. Med ABC som analyseredskab er det dermed muligt at identificere både de produkter og kunder, som udgør virksomhedens eksistensgrundlag. Med ERP systemer i mange større danske virksomheder vil det være hensigtsmæssigt at kunne finde de data, der skal anvendes, samt bearbejde og afrapportere netop i disse systemer 47. På nuværende tidspunkt kan vi allerede bekendtgøre, at ABC ikke eksplicit kan gennemføres i SAP Business One, men de fleste data kan imidlertid hentes fra dette ERP system. Vi gør opmærksom på, at det optimale 46 Kaplan, Atkinson Advanced management accounting, side 186 47 Rikhardsson, Pall ERP, side 34-35 Side 60 af 104

vil være at kunne finde samtlige data i SAP business One og efterfølgende afrapportere. Alternativt at udtrække bestemte data fra ERP systemet samt andre relevante systemer og/eller databaser for derved at konvertere og lagre disse i én samlet database, jf. figur 32. Når dataene er lageret i databasen med et fælles format, kan dataene nemmere analyseres og afrapporteres ved hjælp af analyse-værktøjer. Som anført under projektdesign i næste afsnit vil vi dog udelukkende anvende ERP systemet i form af SAP Business One samt anvende det i kapitel 2 benyttede APEX (Oracle Application Express) og bruge Excel til at udtrække data til illustreret ved de tynde linjer i figuren nedenfor. ERP Optimal Vej Optimal Vej Datawarehouse Optimal Vej Excel APEX Figur 32: Egen tilvirkning Afgrænsning Vi ser bort fra praktisk kapacitet og betragter udelukkende ACDR (Activity Cost Driver Rate) i forhold til faktisk kapacitet. Diskussionen om, hvilken kapacitet, der skal ligge til grund for kalkulation af ACDR foreligger i kapitel 2, hvorfor vi ikke vil komme yderligere ind på dette område. Altså antager vi, at virksomheden udnytter sin kapacitet fuldt ud (faktisk kapacitet = praktisk kapacitet). Ligesom i kapitel 2 vil vi heller ikke tage stilling til de resultater ABC kalkulationen medfører, men holde fokus på ERP systemet og ABC. Projektdesign Som i kapitel 2, er der tilsvarende i kapitel 3 udarbejdet en figur/studieplan, der illustrerer projektdesignet (jf. figur 33). Det skal dog understreges, at på trods af udarbejdelsen af to selvstændige projektdele, skal Side 61 af 104

projektet ses som en helhed. Dermed menes, at anden del af projektet inddrager samme paradigmedannende elementer og metodiske overvejelser (metodisk udgangspunkt), hvor projektdesignet skal ses i forlængelse heraf. Den teoretiske gennemgang af ABC-modellen der blev præsenteret i første halvdel af projektet, bliver ligeledes anvendt og refereret til i anden halvdel af projektet. For at forsimple det samlede projekt vil vi fortsat overordnet gøre brug af casen, som blev præsenteret i foregående projekthalvdel. Navnene på produkter bliver således genbrugt, hvorimod andre oplysninger er tilføjet, hvor det har været nødvendigt. Casen bliver ikke tillagt samme betydning, som i foregående projekt, da vi ikke anser en decideret case som et nødvendigt udgangspunkt for at forståelsen og brugen af ERP. Projektdesignet fremgår af nedenstående figur. Problemstilling Projektdesign ERP/SBO Ressourcer til aktiviteter Aktiviteter til omk.objekter Resultat Resume Figur 33: Egen tilvirkning Projektet er blevet indledt med en problemstilling, hvor de væsentligste problemstillinger blev fremlagt. Herefter følger nærværende afsnit, som er medtaget for at sikre, at den røde tråd bibeholdelse igennem projektet. Det er endvidere medtaget både for at sikre et overblik over projektet samt sikre en stringent belysning af problemstillingen. Projektdesignet er også med til at sikre retning og fokus i bearbejdelsen af problemstillingen, samtidig med at det sikrer, at der bliver svaret på den opstillede problemstilling. Herefter følger en præsentation af ERP og SAP Business One. Afsnittet er medtaget for at belyse hvilke muligheder og begrænsninger, der eksisterer i ERP systemet. Samtidig skal det medvirke til at give en grundlæggende forståelse for ERP systemet og SAP Business One. Side 62 af 104

Efter denne gennemgang vil det blive illustreret, hvorledes SAP Business One kan understøtte en ABC kalkulation. For at sikre en overskuelig gennemgang af dette, er analysen delt i tre afsnit, som strukturelt følger ABC-modellen. Først vil det blive belyst, hvorledes virksomhedens indirekte omkostninger kan identificeres i SAP Business One, og tilsvarende hvordan virksomhedens aktiviteter kan findes i systemet. Herefter vil omkostningerne blive fordelt til aktiviteter. Når disse er fundet vil det sidste trin i ABC-modellen fordele omkostningerne til de enkelte omkostningsobjekter. Under hele processen vil de fornødne data enten blive fundet i SAP Business One eller APEX, mens de endelige kalkuler foretages i Excel. Kun hvor vi opfatter SAP Business One som værende mangelfuld, inddrager vi APEX til at udtrække data. Projektet vil blive afrundet med et resume, hvor de væsentligste slutninger i projektet vil blive opsummeret. Side 63 af 104

Introduktion til ERP systemer Indledningsvis vil vi give et generelt indblik i ERP systemet, hvorefter vi konkret vil specificere SAP Business One, som er et ERP system udbudt til mindre virksomheder. Hensigten med at give indblik i ERP systemet generelt er at forklare hvilke forretningsprocesser og moduler, som kan anvendes af virksomheder. Der er imidlertid meget forskel på ERP systemer, og mange udbydere afsætter løsninger af divergerende størrelse. SAP Business One er et eksempel på et ERP system, der i dette projekt benyttes til at belyse vores problemstilling. ERP systemer generelt I enhver virksomhed findes et eller flere systemer, som tilvejebringer data til forskellige formål. Banebrydende ved ERP er, at dette system integrerer virksomhedens forskellige systemer, således at dataindsamlingen sker i én database. Førhen kunne virksomhedens produktions- og materialeplanlægning eksempelvis blive foretaget ved hjælp af MRP (Material Requirements Planning) og al kundehåndtering ved hjælp af CRM (Customer Relationship Management). Data bliver hermed registreret i forskellige databaser med forskellige måder at afrapportere på. Desuden kan systemerne ligge i forskellige lande i hvert deres sprog 48. Såfremt virksomheden opretter en ny kunde og effektuerer ordrer til denne, vil dette ske i ét system. I et andet system registreres indkøb af materialer, nedskrivning af lageret, produktionsplanlægningen mv. ved denne ordre. En transaktion består således af mange registreringer og opdateringer i de individuelle systemer 49. Det kan være en omkostningstung opgave at skulle operere med flere systemer, og lagre data i forskellige databaser for til sidst at transformere dataene til et fælles sprog, dersom systemerne ikke harmonerer med hinanden. Fordelen ved at have forskellige forretningsprocesser integreret i ERP systemet er, at der i højere grad sikres konsistens mellem data. Det giver virksomheden mulighed for en lettere afrapportering, da alle data befinder sig i én database organiseret på samme måde. Da virksomhedens forretningsprocesser (indkøb, produktion, salg, administration, personale, økonomi m.fl.) findes i ERP systemet vil fx en ordreafgivelse overflødiggøre manuel opdatering i flere funktioner. ERP systemet håndterer automatisk nedskrivning af lageret, giver overblik over lagerstatus, fremsætter forslag til/bestiller råvarer hos underleverandører, registrerer salget i økonomifunktionen og så fremdeles. Selv om ERP samler virksomhedens grundlæggende 48 Palaniswamy, Rajagopal & Frank, Tyler Enhancing manufacturing performance with ERP systems side 2-3 49 Rikhardsson, Pall ERP, side 17-19 Side 64 af 104

processer i et system, kan der tillige være behov for andre systemer, eller blot at virksomheden vælger at besidde ERP og et selvstændigt kundesystem afhængig af den pågældende virksomhed. ERP kan i den anledning kommunikere med andre systemer, også uden for virksomheden (fx kundens ordresystem) 50. ERP systemet kan være bygget op på følgende vis: Online opkobling Moduler til rapportering og analyse Moduler til materiale-, produktions- og lagerstyring Økonomimoduler ERP Online opkobling Online opkobling Moduler til salg og distribution Moduler til personalestyring Moduler til indkøb og logistik Figur 34: egen tilvirkning med inspiration fra Rikhardsson, Pall ERP side 19 Generelt foreligger der følgende elementer i et ERP system 51 : - En central database: En relationel database, hvis entiteter, relationer mv. er etableret og er samhørende, samt hvor data (transaktioner) og opdateringer dagligt modtages i realtid. - Økonomistyringsmoduler: Modulet som varetager debitor, kreditor, aktiver, budgetter, investeringer, omkostningsregnskaber og så videre. - Materiale-, produktions- og lagerstyring: Styrer flowet af materialer og varer i og uden for virksomheden, herunder ruteplanlægning, styklister, kvalitetskontrol samt styring af lagre. 50 Rikhardsson, Pall ERP side 17 51 Rikhardsson, Pall ERP side 23-24 Side 65 af 104

- Personalestyring: Administrerer personaleforhold, fx tager sig af kompetenceudvikling samt uddannelse af medarbejdere mv. - Customer relationship management: Styring af data om kunder, afgivning af tilbud og generel salgsarbejde. Endvidere anvendes modulet til at undersøge lagerstatus, kreditter mv. - E-business: ERP systemer understøtter opsætning til online forbindelse og integration af fx produktionsplanlægning med leverandører og kunder. - Workflow: Funktionaliteter, som sikrer koordinering af aktiviteter, transaktioner og hændelser mellem virksomhedens aktører. Fx sikres, at medarbejderen som skal godkende en rekvisition, får denne i tide. - Customisering: virksomheden kan i høj grad tilpasse systemet til dennes behov. Det skal hermed fremhæves, at ERP understøtter hele virksomhedens værdikæde, det vil sige samtlige processer lige fra indkøb til salg og service. Nogle virksomheder vil imidlertid vægte nogle processer højere end andre afhængig af de individuelle behov. Det er brugeren (virksomheden) af ERP systemet, som selekterer hvilke forretningsprocesser, den ønsker at anvende, og hvilke systemer virksomheden eventuelt ønsker at fortsætte med selvstændigt at administrere. ERP er dermed et rammesystem, som giver opsætningsmuligheder inden for nogle fastsatte grænser. Først når denne konfigurationsproces af ERP systemet er gennemført kan systemet optræde som standardsystem inden for de af brugeren valgte opsætninger og funktionaliteter 52. Kritik af ERP Mangfoldigheden i ERP systemet, kompatibiliteten med andre systemer og det bedre informationsflow giver virksomheder mulighed for at få styr på deres interne processer på en effektiv måde. Der er imidlertid rejst en del kritik af ERP systemet, og flere virksomheder har sågar forladt ideen om et fuldstændig integreret system 53. Kritikkerne anklager ERP for at være for standardiseret og ikke skræddersyet nok til at kunne håndtere virksomheders individuelle behov. I stedet for at ERP systemet tilpasses virksomheden er det i højere grad virksomheden, som tilpasses systemet. Logikken i ERP systemet er altså ikke altid overensstemmende med logikken i forretningssystemet. Såfremt en virksomheds interne processer er signifikante konkurrenceparametre, og disse må tilpasses et standardiseret system, så vil det alt andet lige give et nega- 52 Pall Rikhardsson ERP side 21 53 Thomas H. Davenport Putting the Enterprise into the Enterprise System, side 122 Side 66 af 104

tivt udslag. Derudover er det tekniske spektrum kritiseret, da ERP er et komplekst softwaresystem, og implementering fordrer meget likviditet, tid og ekspertise 54. ERP som interface ERP er også en grafisk brugergrænseflade. En grænseflade er en flade, som grænser op imod noget andet, hvilket i vores tilfælde er databasen indeholdt allerede oprettede tabeller, hvori vi kan indskrive data. ERP hjælper således brugeren på en overskuelig måde til at registrere, indsamle, hente og opdatere data. ERP angiver indirekte, hvilke kildekoder der ønskes indtastet, blot på en brugervenlig måde. Der er adskillige firmaer, som udbyder ERP systemer til organisationer. Tyske SAP er den største leverandør, men Oracle, Baan og Peoplesoft er også store udbydere på markedet. Som tidligere anført vil vi i projektet benytte SAP business One, som primært forbeholdes mindre virksomheder 55+56. Oracles APEX, som blev benyttet i første projekthalvdel, blev tilsvarende beskrevet som et program, der kommunikerer med en database. Skal der drages en kobling til APEX, så var dette et mere simpelt program til at kommunikere med databasen, og APEX benyttes hovedsagligt til at bygge webapplikationer (brugervenlige grænseflader) 57. Det skal bemærkes, at SAP udbyder færdiglavede løsninger, hvorimod der i APEX selvstændigt skal opbygges og defineres entiteter, skabes relationer mellem disse samt sikres integritet med det sigte at bygge applikationer til registrering og dataudtræk. Derudover er APEX ikke en integration af forretningsprocesser, som opdateres automatisk, fx hver gang en transaktion foretages. Dette gøres manuelt i de berørte tabeller, hvilket sammenlignet med SAP Business One gør SAP systemet til et mere fleksibelt og effektiv system. Slutteligt skal det pointeres, at SAP skriver i Microsoft SQL og APEX i Oracle SQL det vil sige, at det er forskellige koder, SAP og APEX gør brug af for at kommunikere med databasen 58. 54 Davenport, Thomas H. Putting the Enterprise into the Enterprise System, side 122 55 Davenport, Thomas H. Putting the Enterprise into the Enterprise System, side 121-122 56 www.sap.com - link1 57 www.oracle.com link2 58 www.sap.com link3 & www.oracle.com link4 Side 67 af 104

SAP Business One Som nævnt i foregående afsnit er der flere leverandører af ERP systemer. I dette projekt vil der kun være fokus på et enkelt af disse, nemlig SAP og dets produkt SAP Business One. Årsagen til dette er, at vi har modtaget undervisning i dette system, og der ligger således ikke dybere overvejelser bag dette valg. SAP blev grundlagt i 1972, og virksomheden betegner sig selv i dag som værende blandt verdens førende leverandører af ERP systemer 59. SAP tilbyder forskellige løsninger alt efter virksomhedstype (service-, handels- eller produktionsvirksomhed), og hvor stor organisationen er (antal medarbejdere og afdelinger). SAP Business One er blot en af tre løsninger, SAP tilbyder til mindre og mellemstore virksomheder. Løsningen er hovedsageligt rettet mod mindre virksomheder med færre end 100 medarbejdere. De øvrige løsninger er SAP Business ByDesign, som er rettet mod virksomheder med 100-500 medarbejdere, og SAP Business Allin-one der er egnet til virksomheder med op til 2500 medarbejdere 60. Der findes derudover flere SAP systemer end førnævnte, men disse vil ikke blive medtaget her. Som anført udmærker SAP Business One sig ved at være målrettet mod mindre virksomheder i modsætning til mange andre ERP systemer udbudt af SAP, der er målrettet mod store virksomheder. Sådanne systemer er ofte for komplekse i forhold til det mindre virksomheder efterspørger samtidig med, at sådanne systemer er økonomisk uoverskuelige for mindre virksomheder 61. SAP Business One indeholder altså de standardfunktioner mindre virksomheder kunne forventes at efterspørge. Virksomheder har tilmed mulighed for at vælge funktioner til og fra, så systemet derved bliver mere skræddersyet til den enkelte virksomhed, og de opgaver den skal løse. Det kunne være: administration, økonomi, salg, indkøb, produktion, service e.l. Det er ligeledes muligt at udarbejde moduler i SQL og tilknytte SAP Business One systemet disse moduler. Det kan fx være nødvendigt, hvis systemet ikke indeholder de data, der er nødvendige for at udarbejde en given rapportering. Der skal dog her gøres opmærksom på, at SAP Business One benytter Microsoft SQL, hvilket betyder at de moduler, der er udarbejdet i kapitel 2, ikke kan eksporteres til SAP Business One 62. 59 www.sap.com link5 60 www.sap.com link6 61 www.sap.com link7 62 www.sap.com link8 Side 68 af 104

Analyse ABC modellens databehov I dette afsnit vil vi danne et overblik over, hvilke databehov en ABC-model stiller særligt med fokus på de indirekte omkostninger. Vi har tidligere gennemgået principperne bag denne model, og vi vil i dette afsnit sætte fokus på SAP Business One, og hvilke data vi med afsæt i ABC-modellen ønsker at udtrække fra systemets database. Afsnittet er struktureret således, at der først skabes et overordnet billede af, hvilke data ABC-modellen forespørger, hvorefter det kortfattet angives, hvordan vi vælger at oprette samt finde dataene i SAP Business One. Altså vil vi give en præsentation af vores databehov og kort forklare hvordan vi håndterer ressourcer, Ressource Cost Drivere, aktiviteter, Activity Cost Drivere og omkostningsobjekter i den forestående analyse. Som gennemgået tidligere er princippet i ABC modellen, at ressourcer fordeles til aktiviteter, som fordeles til omkostningsobjekter. I første halvdel af projektet brugte vi produktet som omkostningsobjekt og viste med hjælp fra den fiktive casevirksomhed Sødtand ApS, hvordan et tilsyneladende profitabelt produkt viste sig at have en negativ profitmargin. I denne anden halvdel af projektet har vi valgt at bruge kunder som omkostningsobjekt, da virksomheder i mange tilfælde har behov for at vide, hvilke kunder der bidrager og ikke bidrager til virksomhedens nettoresultat (jf. problemstilling kapitel 2). Behovet for relevante data til at understøtte ABC giver overordnet følgende udfordringer i SAP Business One: Ressourcer I ABC modellens første trin består opgaven i at finde virksomhedens samlede ressourceomkostninger, hvilket vi løser ved at finde relevante konti i kontoplanen. I kontoplanen findes en oversigt over artskonti, det vil sige, at ressourceomkostningerne er grupperet efter art. For overskuelighedens skyld oprettes i analysen kun en artskonto, som ønskes fordelt til aktiviteter. Det er arten løn, som dog yderligere grupperes i henholdsvis løn til funktionærer og løn til sælgere. Side 69 af 104

Det er desuden en udfordring at fordele ressourcerne efter en retvisende fordelingsnøgle (Ressource Cost Driver) til de forskellige aktiviteter og efterfølgende finde omkostningerne tilgået de pågældende aktiviteter. Fordelingsnøglen i analysen har til formål at allokere lønomkostningerne til oprettede aktiviteter. I dette tilfælde er det at fordele medarbejdernes tid og dertilhørende omkostninger til de forskellige aktiviteter. Aktiviteter Herefter er udfordringen at identificere aktiviteterne og tilhørende Activity Cost Drivere. I dette eksempel oprettes følgende tre aktiviteter med følgende drivere: - Aktiviteten: Kundebesøg o Transaktionsdriveren: Antal kundebesøg - Aktiviteten Salg o Transaktionsdriveren: Antal ordrer - Aktiviteten Telefonbesvarelser o Direkte måling: Antal minutter Den næste opgave består i at udregne ACDR på baggrund af aktivitetsomkostningerne også kaldet Activity Expenses samt ACDQ (Activity Cost Driver Quantity). På omkostningssiden består næste opgave i at udtrække de samlede Activity Expenses på de tre aktiviteter: Kundebesøg, Salg og Telefonbesvarelse. På aktivitetssiden er udfordringen at udtrække det samlede antal transaktioner, det vil sige antal kundebesøg og antal ordrer, som udtrykkes ved ACDQ. Data til direkte måling Antal minutter hentes fra en anden database oprettet i APEX. Når disse databehov er opfyldt anvendes Excel som analyseværktøj, som tidligere anført under projektdesign. Formålet er udregning af ACDR, i dette tilfælde omkostninger pr. kundebesøg, pr. ordrer og pr. min. telefonbesvarelse. Omkostningsobjekt På baggrund af ACDR er det muligt at beregne de enkelte omkostningsobjekters træk på ressourcerne, i dette tilfælde kunder. Der oprettes to kunder i databasen (Dansk Supermarked og Coop Danmark), som aktivitetsomkostningerne henføres til ved hjælp af ACDR. Første opgave er således at udtrække de enkelte Side 70 af 104

kunders antal transaktioner for kundebesøg og salg samt kundernes træk på telefonbesvarelse. Ved at multiplicere ACDR og ACDQ for de to kunder får vi således de enkelte omkostningsobjekters Activity Expenses. Efter at have givet et samlet overblik, vil vi nu give en mere uddybende forklaring på, hvordan vi helt konkret finder de relevante data i SAP Business One. Ressourcer til aktiviteter I det første trin vil det som anført være ressourcepuljer, som determineres, der skal allokeres til aktiviteter. Det vil naturligvis være uhensigtsmæssigt at fordele samtlige ressourceomkostninger en bloc til virksomhedens aktiviteter, da der dermed vil opstå stor unøjagtighed på et så aggregeret niveau. Ressourcepuljerne er i vores tilfælde determineret efter art. For at forsimple eksemplet vil blot én art allokeres til aktiviteter. Det er nærmere betegnet løn, som yderligere er specificeret i to underarter (løn til funktionærer og løn til sælgere) for at få en så præcis omkostningsfordeling som muligt. Argumentet består i, at dersom den samlede løn blev fordelt til aktiviteter, ville fordelingen ikke afspejle aktiviteternes brug af ressourcer. Specifikationen medfører, at løn til funktionærer og løn til sælgere særskilt vil kunne fordeles ved hjælp af RCD, og dermed opnås en nøjagtigere fordeling til aktiviteter. Løn til funktionærer og løn til sælgere har vi derfor oprettet i kontoplanen under kategorien Løn. Virksomhedens ressourceomkostninger kan i SAP Business One lokaliseres under økonomifunktionens kontoplan. Her er vist virksomhedens omkostninger sorteret efter art. Hvis ressourceomkostningerne via en fordelingsnøgle skal kunne henføres til aktiviteter, skal aktiviteterne først identificeres. Der er umiddelbart to måder at gøre det på. En mulighed er at oprette projekter, og en anden mulighed er at oprette profitcentre, som begge udtrykker aktiviteter i ABC terminologi. Projekter: Når virksomheden registrerer omkostninger i forbindelse med et forbrug vil omkostningerne kunne henføres til én aktivitet (100 % allokering til en aktivitet). Hvis der i vores tilfælde blev registreret lønomkostninger til sælgere, vil denne omkostning kunne henføres til en aktivitet. Ulempen er umiddelbart, hvis sælgeren har anvendt tid på forskellige aktiviteter, hvilket ikke er urealistisk. Side 71 af 104

Profitcentre: Ved oprettelsen af profitcentre vil virksomheden kunne henføre registrering af omkostninger til flere aktiviteter ved hjælp af en fordelingsregel (fordelingsnøgle). Eksempelvis vil lønomkostninger til sælgere kunne allokeres til flere aktiviteter efter en allerede bestemt fordelingsnøgle. Den i projektet valgte metode er oprettelsen af profitcentre, idet vi mener denne giver et mere virkelighedsnært billede det må i overvejende grad forventes, at virksomhedens ressourcer skal allokeres til flere aktiviteter. Desuden kan en omkostning henføres til én aktivitet/et profitcenter efter en valgt fordeling på 100 procent. Profitcentrene skal oprettes i økonomimodulet under omkostningsregnskab. Efter oprettelsen af hvert profitcenter determineres hvilke fordelingsregler, der skal vedrøre disse. Det vil med andre ord sige, at ressourceomkostningernes relative fordeling til aktiviteter fastsættes, og disse konkrete fordelingsnøgler vælges, når der foretages omkostningsregistreringer. I økonomimodulet under finanspostering er registreret lønomkostninger til funktionærer samt til sælgere. I samme registrering er der allokeret omkostningerne til aktiviteter efter den fordelingsnøgle, som på forhånd er oprettet (jf. figur 35). Der er her defineret tre aktiviteter, som er henholdsvis kundebesøg, salg og telefonbesvarelse. Dertil har vi oprettet en fordelingsnøgle Administration Løn, hvilket betyder, at når der konteres løn til funktionærer, vil lønomkostningen allokeres til aktiviteter efter nøglens specifikationer. I figuren nedenfor konteres 50.000 $ i form af lønomkostninger til funktionærer. I dette tilfælde gælder det, at 80 % allokeres til aktiviteten telefonbesvarelse og 20 % allokeres til aktiviteten salg. Denne fordelingsnøgle er oprettet i forvejen i SAP Business One, som skitseret nedenfor, og ved at vælge fordelingsreglen 4 Administration Løn fås altså en 80/20 fordeling. Ved denne fremgangsmåde kan virksomheden, hver gang den registrerer omkostninger til funktionærer selektere den pågældende fordelingsnøgle, hvis det forudsættes, at fordelingen er den samme. Side 72 af 104

Figur 35: Screen shot fra SAP Business One De oprettede fordelingsnøgler mellem ressourcer og aktiviteter fremgår af figur 36. Her ses det i række 4, at netop 4 har en fordeling på 20 % til 2 - salg og 80 % til 3 - telefonbesvarelse. Det fremgår også, at 5 har en anden fordeling; 70 % til 1 kundebesøg og 30 % til 2 salg. Desuden bemærkes, at række 1-3 har 100 procent fordeling til en pågældende aktivitet. Centr_z er en automatisk oprettet attribut, som har til hensigt at opfange de omkostninger, som ifølge fordelingsreglerne ikke henføres til et profitcenter. Eksempelvis hvis fordelingen til profitcentre var følgende: 30, 40, 20. Ud af 100 mangler altså 10, som bliver fordelt til Centr_z. På den facon kan Centr_z anses som en fællesomkostning, der ikke allokeres til omkostningsobjekter. Side 73 af 104

Figur 36: Screen shot fra SAP Business One I stedet for at vælge hvilken fordelingsregel, som skal gøre sig gældende for hver kontering, kan det i kontoplanen også vælges, hvilken regel som skal gælde generelt. Dette betyder, at for hver transaktion som vedrører løn funktionærer eller løn sælgere, så er fordelingsreglen på forhånd fastsat som standard. Fx vil løn funktionærer som standard få fordelingsregel 4, hvilket indebærer, at der ikke skal søges efter den rette nøgle i listen ved finanspostering herved minimeres risikoen for fejl. Efter at have konteret tilstrækkelige omkostninger for at understøtte vores analyse, kan det betragtes i hvilket omfang ressourceomkostningerne tilgår de oprettede aktiviteter. Hvor mange omkostninger der tilgår henholdsvis kundebesøg, salg samt telefonbesvarelse kan ses af figur 37 nedenfor. Af figuren fremgår det, at kundebesøg tildeles 42.000 $, salg 30.000 $ og telefonbesvarelse af 48.000 $. Tilligemed kan der for hver aktivitet vises en detaljeret oversigt over hvilke ressourceomkostninger fra hver art, som er fordelt til denne. Eksempelvis ønskes at få en oversigt over omkostningernes sammensætning under salg. Af de tildelte 30.000 $ til aktiviteten udgøres 40 % af lønomkostninger til funktionærer og 60 % af lønomkostninger til sælgere. Side 74 af 104

Figur 37: Screen shot fra SAP Business One Data til brug for første trin i ABC-analysen er nu identificeret i SAP Business One, men disse skal ligeledes gøres operationaliserbare, således dataene kan bearbejdes efter en ABC tankegang. For at fuldende det første trin kræver det, at vi trækker de fundne data ud af ERP systemet og behandler dem i Excel, hvilken samme fremgangsmåde også vil finde sted i det andet trin i ABC-analysen. Som redskab til at trække data ud fra databasen, har vi benyttet en forespørgselsgenerator. Denne kommunikerer med databasen og henter de forespurgte data i de aktuelle tabeller. Først og fremmest skal vi kende hvilke tabeller og kolonner, vi ønsker data udtrukket fra, dernæst skal tabellerne sammensluttes (joines), og til sidst kan dataene filtreres, så specifikke dataønsker imødekommes. I dette tilfælde ønskes at identificere aktiviteter og fordelte omkostninger til aktiviteterne. I forespørgselsgeneratoren anmoder vi som det første om at finde tabellerne: JDT1 (Økonomi- kontoplan- kontosaldo), OOCR (Økonomiomkostningsregnskab- fordelingsregler), OPRC (Økonomi- omkostningsregnskab- opret profitcenter) og OCR1 (Økonomi- omkostningsregnskab- fordelingsregler) og foretage et joint mellem disse. Dernæst om at udtrække navnet på aktiviteten (profitcenternavn), fordelingsstørrelsen til aktiviteten (total i center), og selve beløbet som skal fordeles (debetbeløb), jf. figur 38. Desuden tilføjes en SQL kode i form af total i center x debetbeløb, hvorved fordelingsbeløbet findes til hver aktivitet (fordelt). Altså har vi fundet de påkrævede data i databasen, hvorfor vi efterfølgende kan eksportere disse til Excel til videre analysebrug. Side 75 af 104

Figur 38: Screen shot fra SAP Business One Tilsvarende ses outputtet i Excel: Figur 39: Screen shot fra SAP Business One Side 76 af 104

Opsummering I ABC-modellens første trin vil ressourcepuljer skulle allokeres til aktiviteter afhængig af, hvor meget ressourcerne benytter aktiviteterne. I dette forsimplede eksempel oprettedes to ressourcepuljer, som er løn til funktionærer og løn til sælgere, og disse ressourcepuljer har vi ved hjælp af fordelingsnøgler allokeret til tre aktiviteter. Aktiviteterne i SAP Business One fremkommer ved at oprette profitcentre, og fordelingsnøglerne fremkommer i nær tilknytning hertil ved at udarbejde fordelingsregler til aktiviteterne. Ud fra disse elementer har det været muligt at fordele ressourceomkostningerne til aktiviteter, hvor resultatet sidst i dette afsnit blev præsenteret med en rapport over omkostninger tilgået aktiviteterne. Slutteligt er de relevante data udtrukket ved hjælp af forespørgselsgeneratoren, hvorefter disse data er blevet eksporteret til Excel. Kritik I stedet for at fordele omkostningerne ved registrering vil det være nemmere på et givet tidspunkt (fx efter endt regnskabsperiode) at samle samtlige ressourcepuljer og herefter allokere disse til aktiviteter ved hjælp af en fordelingsnøgle for hver ressourcepulje. I vores analyse i SAP Business One har vi for hver kontering fordelt omkostningsbeløbet efter en oprettet fordelingsnøgle til aktiviteter. Det er ikke utænkeligt, at en virksomhed opererer med talrige aktiviteter og fordelingsnøgler, og at selektere netop den rigtige fordelingsnøgle for hver kontering kan være en besværlig opgave. SAP Business One har imidlertid en løsning på dette med standardiseringen af fordelingsreglerne på artskonti under kontoplanen, men fastsættelse af fordelingsreglen i kontoplanen fungerer ikke med tilbagevirkende kraft. Det betyder, at i det øjeblik fordelingsreglen fastsættes for hver artskonti, vil reglen kun virke ex ante. Et andet kritikpunkt er i forbindelse med egne oprettede profitcentre, som kan forekomme for aggregeret. Såfremt konteringen løn funktionærer optræder for en bestemt medarbejder, som ikke har den fordelingsprocent, vi angiver, vil ressourceomkostningen til aktiviteterne ikke afspejle den reelle situation. Altså bliver nogle aktiviteter enten belastet for lidt eller for meget i forhold til, hvor meget aktiviteterne bruger af ressourcen, det vil sige medarbejderen. Alternativet kan være at oprette underkategorier for løn funktionærer, hvor det defineres, hvilke typer funktionærer det drejer sig om. På den måde dannes mere homogene ressourcepuljer, men det kræver derimod mere tid og flere omkostninger at administrere flere ressourcepuljer, ligesom det på tilsvarende vis kan være mere tids- og omkostningskrævende at definere flere Side 77 af 104

aktiviteter for at få et mere præcist billede af omkostningsobjekternes rentabilitet. Det er i høj grad en cost-benefit betragtning, der må anlægges. Side 78 af 104

Aktiviteter til omkostningsobjekter Næste skridt i ABC analysen består i at fordele aktivitetsomkostningerne til omkostningsobjekterne i forhold til disses træk på aktiviteterne. Aktivitetsomkostningerne er allerede fordelt på de tre aktiviteter kundebesøg, salg og telefonbesvarelse (jf. figur 38). Omkostningerne ved disse tre aktiviteter skal fordeles til omkostningsobjekter (kunder), men for at det er muligt, skal disse først oprettes i SAP Business One. Oprettelse af omkostningsobjekter I anden halvdel af projektet er kunder valgt som omkostningsprojekt. Med kunden som omkostningsobjekt i en ABC analyse får virksomheden et konkret billede af, hvor mange ressourceomkostninger der tilgår den enkelte kunde, og på den baggrund kan virksomheden fakturere kunden for de ydelser, den reelt modtager. I SAP Business One er oprettet to kunder som omkostningsobjekter, henholdsvis Coop Danmark og Dansk Supermarked. Disse er oprettet under menuen Forretningspartneren og undermenuen hertil Forretningspartner-stamdata. Heri er muligt at indtaste en lang række oplysninger vedrørende kunden. Vi har dog valgt kun at indtaste de oplysninger, der er nødvendig for udarbejdelsen af ABC systemet. Samtidig fastlægges salgsprisen her i dette tilfælde er valgt Base price, hvilket betyder en salgspris 50 % højere end kostprisen. Oprettelse af Activity Cost Drivers Omkostningsobjekterne er nu oprettet, og der kan derfor fordeles omkostninger fra aktiviteterne til omkostningsobjekterne, men for at det er muligt skal ACDR bestemmes. Der er tre ACDR i virksomheden, hvoraf de to er transaktionsdrivere og en direkte måling for aktiviteten telefonbesvarelse. Da det ikke umiddelbart er muligt at lave løbende tidsregistreringer i SAP Business One, er vi nødsaget til at lave tidsregistreringen i et andet system, og derefter sammenholde de herved opnåede data med dataene fundet i SAP Business One. Der er oprettet en tidstabel i APEX, og denne benyttes til at registrere tidsforbruget for hver telefonbesvarelse. Det er dog ikke muligt, i dette projekt, at integrere APEX tabeller i SAP Business One, da APEX arbejder i Oracle SQL, mens SAP Business One arbejder i Microsoft SQL. Det skal dog nævnes, at det er muligt ved hjælp af datawarehouse, men at vi på nuværende tidspunkt ikke har det fornødne kendskab på området til at anvende det i dette projekt. På trods af denne problemstilling mener vi, at det Side 79 af 104

bedste resultat opnås ved oprettelse af tidstabellen i APEX, og derefter samle dataene fra APEX og SAP Business One i Excel, for derved at færdiggøre ABC kalkulen. Til de to første aktiviteter, som begge fordeles ved hjælp af transaktionsdrivere, kan dataene findes i SAP Business One. For aktiviteten kundebesøg findes ACDR ved følgende udregning: Omkostninger henført til aktiviteten kundebesøg/antal kundebesøg= ACDR pr. kundebesøg. Ved aktiviteten salg er ACDR bestemt af antal ordre, der er afgivet, hvilket giver følgende formel: Omkostninger henført til aktiviteten salg/antal ordre = ACDR pr. ordre. For at finde de to ACDR skal der først oprettes kundebesøg og ordrer i SAP Business One. Ordreoprettelse For at oprette ordrerne er det grundlæggende nødvendigt at oprette varer at afgive ordrer på. Derfor oprettes tre varer, nemlig chokolade, vingummi og lakrids. Det gøres under fanebladet produktion, hvor varerne kan oprettes. Kostprisen for varen vælges til 2 $ for henholdsvis lakrids og vingummi, samt 3 $ for chokolade. Varerne skal endvidere bestilles til virksomheden hos en eller flere leverandører. Dette gøres under fanebladet indkøb. Her bestiller vi et vilkårligt antal af de tre varer. Herefter åbnes fanebladet levering, hvor varerne registreres som modtaget og på lager. Slutteligt kan indkøbet faktureres, hvorefter indkøbet af varerne er definitivt afsluttet og registreret. De er nu på lager og salgsordrerne, der skal anvendes i forbindelse med beregningen af ACDR, kan oprettes. Oprettelsen af ordrerne sker under fanebladet salg, og underpunktet ordre. Her vælges det hvilken kunde, der har afgivet ordren, samt hvilke varer og mængde kunden ønsker. Salgsprisen for varerne udregner SAP Business One på baggrund af de oplysninger, der blev indtastet i forbindelse med kundeoprettelsen, hvor det blev valgt, hvilken salgspris der blev fastsat. Efter ordreafgivelsen fremgår det af udgående faktura, at kunden har modtaget varen, og følgende er salget en realitet. Side 80 af 104

Oprettelse af kundebesøg Der mangler nu kun at blive oprettet kundebesøg i SAP Business One, før de første to ACDR kan beregnes. Kundebesøg findes under fanebladet forretningspartnere, og underpunktet aktivitet (jf. figur 40). Figur 40: Screen shot fra SAP Business One Det ses af figuren, at mødet er planlagt til at starte d. 24/11 kl. 13:48, samt har en varighed på 15 min. Videre kan det ses, at det er en telefonsamtale, der omhandler salg. I FP-kode fremkommer en liste over virksomhedens kunder, hvor den pågældende kunde vælges. Samlet antal kundebesøg og ordre Forudsætningen for beregning af ACDR er, at henholdsvis det samlede antal kundebesøg og ordrer er kendt, hvilket betyder, at de mængdedata vi netop har indtastet i SAP Business One skal findes i systemet. Det vil både blive vist, hvor informationen kan findes i SAP Business One, samt hvordan dataene alternativt kan forefindes, så der er mulighed for at overføre disse til Excel. Da det ikke har været muligt at få SAP Business One til at summere antallet af ordrer og kundebesøg for kunder, vil optællingen af disse blive foretaget i Excel. Nedenfor vil det først blive illustreret, hvorledes dataene kan forefindes i SAP Business One, og derefter hvordan de kan findes og overføres til Excel via forespørgselsgeneratoren. Side 81 af 104

Kundebesøg For at finde antallet af kundebesøg vælges fanebladet Forretningspartnere, Forretningspartnerrapporter, Aktivitetsoversigt : Figur 41: Screen shot fra SAP Business One Fremgangsmåden er denne samme uanset, hvorvidt der ønskes at finde antal kundebesøg for én kunde eller for samtlige kunder. Forskellen består i den FP-kode, hvor det i figuren ovenfor er valgt Coop Danmark, som har FP-kode 12345. Her vælges feltet fra at være 12345 og feltet til 12345, hvilket betyder, at det kun er Coop Danmark, der vises. Ønskes det samlede antal for Coop Danmark og Dansk Supermarked skrives der i stedet 12345 i til feltet 12346, hvor sidstnævnte dermed er FP-koden for Dansk Supermarked. I vinduet vælges endvidere, at det skal være møde, der vises i feltet aktivitet, samt typen salgsmøde. Gennemføres den første forespørgsel med FP-kode 12345 fremkommer nedenstående vindue. Side 82 af 104

Figur 42: Screen shot fra SAP Business One På samme vis vil der fremkomme en oversigt med det samlede antal møder for såvel Coop Danmark som for Dansk Supermarked, hvis dette var blevet forespurgt. Disse data kan dog ikke direkte eksportere over i Excel, hvorfor vi til dette formål gør brug af forespørgselsgeneratoren. I forespørgselsgeneratoren ønsker vi at udtrække data fra tabellerne OCLG (Forretningspartnere- aktivitet) samt OCRD (Forretningspartnere- forretningspartner stamdata), hvor det fra OCRD tabellen er virksomhedernes navn og FP-kode, der skal forespørges, mens det fra OCLG er den foretagende aktivitet, der forespørges i dette tilfælde kundemøder. For at det udelukkende er kundemøder, og ikke samtlige aktiviteter, der forespørges, betinger vi, at aktiviteten skal være lig m. For at gøre udtrækket overskueligt, sorteres dataene efter virksomhedens navn. Det giver følgende output i SAP Business One. Figur 43: Screen shot fra SAP Business One Side 83 af 104

Her ses antallet af kundemøder for henholdsvis Coop Danmark og Dansk Supermarked. Som nævnt tidligere har det ikke været muligt at få SAP Business One til at summere antallet af møder for de to kunder, hvilket derfor gøres i Excel (group by). Dataene eksporteres ved hjælp af Excel funktionen, som forefindes i menu linjen. Herefter vælges det, at dataene skal gemmes med separate kolonner. Årsagen er, at der herved kan laves beregninger med dataene. Det ville ikke være muligt, hvis ikke der blev valgt separate kolonner. I Excel summeres det samlede antal kundebesøg for hver enkelt kunde og det samlede antal i funktionen subtotal, jf. figur 44. # FP-kode FP-navn Aktivitet 1 12345 Coop Danmark M 2 12345 Coop Danmark M 3 12345 Coop Danmark M 4 12345 Coop Danmark M Coop Danmark Count 4 5 12346 Dansk Supermarked M 6 12346 Dansk Supermarked M 7 12346 Dansk Supermarked M Dansk Supermarked Count 3 I ALT 7 Figur 44: Screen shot fra Excel Af ovenstående figur fremgår det, at der har været fire kundemøder med Coop Danmark og tre med Dansk Supermarked. Vi har nu både omkostningerne for aktiviteten Kundebesøg, de samlede antal kundemøder, samt antallet af kundebesøg pr. kunde derved kan ACDR udregnes, og hver kundes omkostningstræk på denne aktivitet kan bestemmes. Det vil blive gjort i et senere afsnit, efter vi har determineret antallet af ordre og fundet telefonbesvarelsestiden i APEX. Antal ordrer Som det var tilfældet ved kundebesøg, skal vi forespørge både det samlede antal ordrer for alle kunder, og antallet af afgivne ordrer for hver kunde. For at finde de afgivende antal ordrer vælges fanebladet omsætningsrapport, som findes i salgsmodulet. Herved fremkommer figuren nedenfor: Side 84 af 104

Figur 45: Screen shot fra SAP Business One Da det kun er de to kunder Dansk Supermarked og Coop Danmark, der er interessante i dette tilfælde, vælges kunderne fra kode 12345 (Coop Danmark) til kode 12346 (Dansk Supermarked): Figur 46: Screen shot fra SAP Business One Tabellen viser, at Coop Danmark har afgivet fire ordrer, mens Dansk Supermarked har afgivet tre ordrer. Videre kan det ses, at Dansk Supermarked har afgivet ordrer for omtrent det dobbelte beløb i forhold til Side 85 af 104

Coop Danmark. Samtidig kan det samlede antal ordrer, der er afgivet, beregnes ud fra oplysningerne i tabellen, hvor det i figuren viser, at der er afgivet syv ordrer. Vi ønsker ligeledes at udtrække dataene til Excel, hvilket som nævnt ovenfor, håndteres på samme måde som tidligere gennem forespørgselsgeneratoren. Figur 47: Screen shot fra SAP Business One Der anmodes om tabellerne OCRD (Forretningspartnere- forretningspartner stamdata) og ORDR (Salg- kundeordre), hvor der fra OCRD er valgt FP-kode og FP-Navn, mens der fra ORDR er valgt bilagsnummer (nummeret på ordren). I boksen hvor vælges, at det kun er de to virksomheder med FP-kode 12345 (Coop Danmark) og FP-kode 12346 (Dansk Supermarked), der ønskes udtrukket. Outputtet kan ses af følgende figur. Som tidligere anvendes SAP Business One s Excelfunktion til eksportering af data. Problemet med gruppering (group by) finder vi igen ved denne forespørgsel, hvor vi ønsker en oversigt over de samlede antal ordre for hver kunde samt antallet af ordre summeret. Problemet løses på samme vis som tidligere i Excel: # FP-kode FP-navn Bilagsnummer 1 12345 Coop Danmark 83 2 12345 Coop Danmark 84 3 12345 Coop Danmark 85 Side 86 af 104

4 12345 Coop Danmark 86 Coop Danmark Count 4 5 12346 Dansk Supermarked 87 6 12346 Dansk Supermarked 88 7 12346 Dansk Supermarked 89 Dansk Supermarked Count 3 I ALT 7 Figur 48: Screen shot fra Excel Oprettelse af telefonbesvarelser Den tredje aktivitet, hvor vi ønsker at oprette mængder for, er telefonbesvarelser. I princippet vil det være muligt at fremskaffe dataene, der skal benyttes til udregning af den sidste ACDR i SAP Business One. Dette kan forekomme under samme modul som oprettelsen af møder, hvor vi i stedet kunne vælge telefonmøde. Da aktiviteten telefonbesvarelser er tiltænkt som akut supportservice, vil telefonmøde, der optræder som et større planlagt møde, hvor mødets dagsorden er kendt, ikke være brugbar. I stedet tages APEX i anvendelse, hvor der oprettes tre tabeller kunder, aktiviteter og registreringer. Relationerne, primærnøgler, fremmednøgler o.l. vil ikke diskuteres her, men der henvises derimod til forrige kapitel. Imidlertid skal knyttes en kommentar til tabellen registreringer, hvor det forudsættes, at medarbejderne har noteret tidsforbruget udtrykt i minutter for hver telefonsamtale med hver kunde (direkte måling), jf. figur 49. Desuden er denne tabel pejlemærket for det output, vi ønsker at fremskaffe. Side 87 af 104

Figur 49: Screen shot fra APEX På baggrund af de nævnte oprettede tabeller har vi udarbejdet views, som angiver det samlede forbrug på kunder udtrykt i minutter. Som det fremgår nedenfor i figur 50, har det samlede minutforbrug på kunder været 545. Tallet er et resultat af den kildekode skrevet i SQL: select from SUM ("FORBRUG") as "SAMLET_FORBRUG" "SAP_REGISTRERINGER" "SAP_REGISTRERINGER" Derudover er det ønskeligt at finde kundernes særskilte træk på aktiviteten telefonbesvarelse. Hertil er anvendt kildekoderne: select from SUM ("FORBRUG") as "SAMLET_FORBRUG_COOP" "SAP_REGISTRERINGER" "SAP_REGISTRERINGER" where "ID_FK_KUNDE" = 1 select from SUM ("FORBRUG") as "SAMLET_FORBRUG_DK_S" "SAP_REGISTRERINGER" "SAP_REGISTRERINGER" where "ID_FK_KUNDE" = 2 Figur 50: Udtræk fra APEX Outputtet giver 375 minutter anvendt til servicering af Coop Danmark og 170 minutter anvendt til servicering af Dansk Supermarked. Dataene er ligesom for SAP Business One eksporteret til Excel, hvor disse vil benyttes til kalkulation af ACDR og slutteligt kundetrækket samt kundeprofitabiliteten. Side 88 af 104

Omkostningsobjekternes træk på aktiviteter I de to foregående afsnit er diskuteret, hvorledes data vedrørende ressourcer og aktiviteter er udtrukket. Nedenstående figur sammenfatter opgørelsen over de forskellige kunders træk på aktiviteter på baggrund af dataudtræk fra SAP Business One og APEX. Antal kundebesøg og antal ordrer fordelt på Coop Danmark og Dansk Supermarked er hentet fra SAP Business One og opgørelsen over antal minutters telefonbesvarelse er fra APEX: Activity Cost Drivers Tabel 5 Coop Danmark Dansk Supermarked Total Kundebesøg Antal kundebesøg 4 3 7 Salg Antal ordrer 4 3 7 Telefonbesvarelse Antal min 375 170 545 Figur 51: Egen tilvirkning Med kendskab til omkostningerne fordelt på de tre aktiviteter og deres ACDQ, er det simpelt at udregne ACDR. ACDR for de forskellige aktiviteter kan beregnes ved at dividere Activity Expense med ACDQ (jf. figur 52). Activity Cost Driver Rates Tabel 6 Activity Expense Activity Cost Driver ACDQ ACDR Kundebesøg kr 42.000,00 Antal kundebesøg 7 kr 6.000,00 Salg kr 30.000,00 Antal ordrer 7 kr 4.285,71 Telefonbesvarelse kr 48.000,00 Antal min 545 kr 88,07 pr. kundebesøg pr. ordre pr. min Figur 52: Egen tilvirkning Side 89 af 104

Sammensættes de to figurer er det således muligt at beregne kundernes træk på de forskellige aktiviteter. Eksempelvis multipliceres ACDR for kundebesøg på 6000 kr. med Coop Danmarks fire besøg, og simpelt får vi således Activity Expense for denne kunde på 24.000 kr. 63. Activity Expenses Tabel 7 ACDR ACDQ for: Acticity Expense: ACDQ for: Acticity Expense: Coop Danmark Coop Danmark Dansk Supermarked Dansk Supermarked Kundebesøg kr 6.000,00 4 kr 24.000,00 3 kr 18.000,00 Salg kr 4.285,71 4 kr 17.142,86 3 kr 12.857,14 Telefonbesvarelse kr 88,07 375 kr 33.027,52 170 kr 14.972,48 Figur 53: Egen tilvirkning ABC kalkulationen er hermed fuldendt. Sideløbende med opsætningen i SAP Business One er der foretaget en kontroludregning i Excel og samtlige figurer (tabel 1 tabel 8) er vedlagt som bilag 3. Den fiktive virksomhed er meget forsimplet, men de anvendte metoder er let skalérbare. Det er forholdsvis enkelt at anvende samme metode med udtræk fra SAP og foretage de endelige beregninger i Excel ved et større antal aktiviteter, ressourcepuljer, transaktioner o.l. Resultat Efter at have færdiggjort ABC kalkulation vil vi i dette afsnit, som afslutning på analysen, opstille et regnskab, der også inkluderer omsætningen og de direkte omkostninger. De direkte omkostninger er produktomkostninger, og ved salg af produkter til kunder, vil disse omkostninger tillige være direkte i forhold til kunder. Når dette aspekt medtages er det muligt at beregne de forskellige kunders profitabilitet. Omsætning Ved hjælp af forespørgselsgeneratoren foretages følgende udtræk fra SAP Business One, jf. figur 54. Her forefindes mængden, salgsprisen og dermed hvilken omsætning de forskellige salgsordrer genererer fordelt 63 Vi er bevidste om, at det monetære beløb i SAP Business One er udtrykt i $, men vi anser valutaen, som værende irrelevant i forhold til at understrege vores pointer. Side 90 af 104

pr. kunde. Vi henter data fra tabellerne INV1 (Salg- udgående faktura- ordre linjer) og OCRD (Forretningspartnere- forretningspartner stamdata) og multiplicerer mængde og pris og benævner dette omsætning. Vi begrænser søgningen til de to kunder, der er interessant for dette projekt, nøjagtigt som tidligere foretaget. Figur 54: Screen shot fra SAP Business One Outputtet fra forespørgslen eksporterer vi til Excel, hvor der efterfølgende kan foretages beregninger til brug i regnskabet. Ved hjælp af Excels Subtotal funktion kan vi simpelt kalkulere omsætningen for de to kunder. På omsætningssiden er således fundet relevant data til den samlede beregning. Direkte omkostninger Udover omsætning kræver rentabilitetsanalysen også et overblik over de direkte omkostninger, det vil sige produkternes kostpriser, der teoretisk også dækker over direkte løn samt indirekte omkostninger. I forespørgselsgeneratoren anvendes tabellerne INV1 og ORCD igen. Denne gang er det mængden og basisprisen, der danner udgangspunkt for beregningen af de direkte omkostninger, som naturligt kaldes Direkte_omkostninger i SAP Business One. Side 91 af 104

Figur 55: Screen shot fra SAP Business One Vi eksporterer herefter dataene til Excel på fuldstændig tilsvarende måde som tidligere berørt. Det er herved muligt at beregne de direkte omkostninger pr. kunde. I dette fiktive eksempel havde virksomheden før implementering af ABC ikke overblik over, i hvilket omfang de individuelle kunder trækker på virksomhedens ressourcer. Opgørelsen over omsætningen fordelt på kunder, samt de direkte omkostninger er opstillet i nedenstående fordelingsregnskab. Regnskabet kan være et eksempel på den måde virksomheder håndterer fordeling af indirekte omkostninger. Her fordeles de indirekte omkostninger efter omsætning (volumenbaseret fordelingsnøgle), og det er således svært at se hvilke af kunderne, der er profitable, og hvilke der ikke er profitable. Regnskabet giver indtrykket, at begge kunder er lige uprofitable. Side 92 af 104

Regnskab før implementering af Activity Based Costing Tabel 1 Coop Danmark Dansk Supermarked Total Omsætning kr 84.000,00 kr 166.800,00 kr 250.800,00 Direkte omk. kr 56.000,00 kr 111.200,00 kr 167.200,00 Indirekte omk. kr 40.191,39 kr 79.808,61 kr 120.000,00 Totale omkostninger kr 96.191,39 kr 191.008,61 kr 287.200,00 Brutto margin kr (12.191,39) kr (24.208,61) kr (36.400,00) Brutto margin i % -14,5% -14,5% -14,5% Resultat Overskudsgrad *) Overhead: Fordeles med udgangspunkt i omsætning kr (36.400,00) -14,5% Figur 56: Screen shot fra Excel På baggrund af ABC kalkulationen er det muligt at opstille et fordelingsregnskab, der fordeler de indirekte omkostninger på en mere retvisende måde. De resultater som er opstået som konsekvens af ABC-analysen fremgår af figur 57. Det viser sig nu, at Coop Danmark trækker væsentlig mere på de indirekte omkostninger end Dansk Supermarked. Da salget til Dansk Supermarked i denne case tilmed også er større, er det tydeligt, at det er Coop Danmark, der er en uprofitabel kunde, og Dansk Supermarked forekommer nu som værende rentabel. Fordelingsregnskab efter implementering af Activity Based Costing Tabel 8 Coop Danmark Dansk Supermarked Total Omsætning kr 84.000,00 kr 166.800,00 kr 250.800,00 Direkte omk. kr 56.000,00 kr 111.200,00 kr 167.200,00 Kundebesøg kr 24.000,00 kr 18.000,00 kr 42.000,00 Salg kr 17.142,86 kr 12.857,14 kr 30.000,00 Telefonbesvarelse kr 33.027,52 kr 14.972,48 kr 48.000,00 Totale omkostninger kr 130.170,38 kr 157.029,62 kr 287.200,00 Brutto margin kr (46.170,38) kr 9.770,38 kr (36.400,00) Brutto margin (%) -55,0% 5,9% -14,5% Resultat Overskudsgrad kr (36.400,00) -14,5% Figur 57: Screen shot fra Excel Side 93 af 104

Resume SAP Business One Andet seminarprojekt har fokus på økonomistyringsmodeller og anvendelse af relevante IT systemer i forbindelse hermed. Centralt i dette kapitel er ERP systemet SAP Business One. Vi demonstrerer i kapitlet en grundlæggende viden om systemets funktionsmåde og anvendelse af en række moduler såsom økonomi og salg. Udover en kortfattet præsentation af ERP systemet indeholder kapitel 3 tilmed en analyse af, hvordan SAP Business One kan understøtte en ABC kalkulation. SAP Business One s forespørgselsgenerator-funktion er det centrale værktøj i dette projekt, da vi i højere grad udtrækker data, end vi skriver i databasen. Ved hjælp af dette værktøj er det muligt at udtrække grundlæggende databehov med henblik på en fordeling af ressourceomkostninger til aktiviteter og videre fordeling til de enkelte omkostningsobjekter. Vi har generelt udeladt skærmbilleder og SQL kommandoer, hvor der er anvendes basisfunktioner såsom oprettelse af kunder, salgsordre o.l. I stedet inddrages disse, når vi målrettet foretager forespørgsler i forespørgselsgenerator-funktionen. Kunder som omkostningsobjekt Kunder er valgt som omkostningsobjekt, og på baggrund af ABC kalkulationen er det muligt at opstille et fordelingsregnskab, hvor de enkelte kunders profitabilitet beregnes. Dette kræver udover ABC kalkulationen af indirekte omkostninger, at der inddrages omsætning og direkte omkostninger. Vi demonstrerer derfor også kendskab til udtræk af disse data ved hjælp af forespørgselsgeneratoren. I analysen anvendes foruden SAP Business One også en simpel database i APEX, hvilket har til formål at illustrere, at en ABC kalkulation kan kræve data fra forskellige systemer, der løser forskellige behov. Selvom ERP systemets styrke er, at det samler en række traditionelt forskellige systemer som MRP, CRM o.l. i én database, vil det givetvis stadig være aktuelt at skulle inddrage andre databaser især på aktivitetssiden i en ABC-analyse. Et mål med analysen har været at udarbejde en let skalerbar løsning. Herved skal forstås, at løsningen forbliver intakt uafhængigt af antallet af produkter, kunder, salgsordre, kundemøder eller andre parametre, som har indvirkning på resultatet. Med udgangspunkt i en fiktiv casevirksomhed er vi kommet frem til denne løsning. Der er dog ikke prioriteret ressourcer til at få casevirksomhedens omsætningsstørrelse, antal Side 94 af 104

ordrer eller lignende til at afspejle en virkelig virksomhed, men derimod har fokus været på at fremhæve relevante pointer i forhold til løsningen af den valgte problemstilling. Side 95 af 104

Litteraturliste Bøger Andersen, Michael & Rohde, Carsten, (2007), Virksomhedens Økonomistyring, 3. Udgave, Jurist- og Økonomforbundets Forlag Arbnor, Ingeman & Bjerke, Björn, (1997), Methodology for creating business knowledge, 2. Udgave, Sage publication Atkinson, Anthony A., Kaplan, Robert S. & Young, Mark S., (2004), Management Accounting, 4. Udgave, Prentice Hall Bukh, Per Nikolaj & Israelsen, Poul, (2004), Activity Based Costing Dansk økonomistyring under forvandling, 1. Udgave, Jurist- og Økonomforbundet Forta, Ben, (2007), SQL i praksis, 1. Udgave, 3. Oplag, Forlaget Libris Hartnack, Justus, (1996), Logik Klassisk og moderne, 8. Udgave, C. A. Reitzel Kaplan, Robert S. & Atkinson, Anthony A., (1998), Advanced Management Accounting, 3. Udgave, Prentice Hall Kaplan, Robert S. & Robin Cooper (1998), Cost & effect using integrated cost systems to drive profitability and performance, Harvard Business School Press Lynggaard, Peter (2006), Driftsøkonomi, 6. Udgave, Handelshøjskolens forlag Madsen, Vagn, (1959), Regnskabsvæsenets opgaver og problemer i ny belysning, 2. Udgave, Gyldendal Rikhardsson, Pall m.fl. (2004), ERP, Børsens Forlag A/S Vang, Søren, (2001), Relationsdatabaser og SQL, 3. Udgave, Ingeniøren bøger Øhrstrøm, Peter, (1998), Logisk Set, 2. Udgave, Forlaget Systime Artikler Wiese, Lars Ole, (2005/2006), Rapportering med ABC modellen, Økonomistyring & Informatik 21. Årgang 2005/2006 nr. 4 Side 96 af 104

Palaniswamy, Rajagopal & Frank, Tyler (2000), Enhancing manufacturing performance with ERP systems, CRC PRESS LLC Davenport, Thomas H. (1998), Putting the Enterprise into the Enterprise System, Hardvard Business Review Internet henvisninger Link 1: http://www.sap.com/denmark/solutions/sme/index.epx Link 2: http://www.oracle.com/technology/products/database/application_express/index.html Link 3: http://www.sdn.sap.com/irj/sdn/mss Link 4: http://www.oracle.com/technology/products/database/application_express/html/what_is_apex.html Link5: http://www.sap.com/denmark/about/index.epx Link 6: http://www.sap.com/denmark/solutions/sme/solution_comparison/index.epx Link 7: www.sap.com/denmark Link 8: http://www.sdn.sap.com/irj/sdn/mss Side 97 af 104

Bilag Bilag 1: ABC beregning foretaget i Excel Kapacitetsomkostninger Tabel 2 Vedligeholdelsesmaterialer kr 200.000,00 Rengøringsmaterialer kr 100.000,00 Gager kontrol kr 370.000,00 Gager vedligeholdelsesrengøring kr 234.000,00 Gager øvrige funktionære kr 240.000,00 Afskrivninger kr 400.000,00 Administration og ledelse kr 100.000,00 Gager - rengøring kr 156.000,00 Salgsfremmende kr 150.000,00 Administrationsmaterialer kr 100.000,00 Total kr 2.050.000,00 Side 98 af 104

Activity Cost Drivers Tabel 3 Aktivitet Omk. hierarki Cost driver Omstilling forarbejdning Serierelateret Omstillingstid i min Omstilling formning Serierelateret Omstillingstid i min Omstilling køling Serierelateret Omstillingstid i min Råvarerhåndtering Serierelateret Antal transaktioner Maskine Enhedsniveau Maskin timer Activity Expenses Tabel 4 Omstilling forarbejdning Omstilling formning Omstilling køling Råvarerhåndtering Maskine Vedligeholdelsesmaterialer 30% 30% 40% 0% 0% Rengøringsmaterialer 0% 0% 0% 0% 100% Gager kontrol 0% 0% 0% 0% 100% Gager vedligeholdelsesrengøring 0% 0% 0% 0% 100% Gager øvrige funktionære 0% 0% 0% 100% 0% Afskrivninger 0% 0% 0% 0% 100% Activity Expenses kr 60.000,00 kr 60.000,00 kr 80.000,00 kr 240.000,00 kr 1.104.000,00 Activity Cost Drivers Tabel 5 Vingummi Lakrids Chokolade Total Omstilling forarbejdning Productions runs 200 200 50 Min/ run 25 20 60 Total omstillingstimer pr. produkt 5000 4000 3000 12000 Omstilling formning Productions runs 200 200 50 MIn/ run 20 15 40 Total omstillingstimer pr. produkt 4000 3000 2000 9000 Omstilling køling Productions runs 200 200 50 Min/ run 10 15 50 Total omstillingstimer pr. produkt 2000 3000 2500 7500 Råvarerhåndtering Antal råvarerbestillinger årligt 12 12 52 76 Maskine Antal enheder pr. time 0,005 0,005 0,02 Total maskinetimer pr. produkt 1500 1250 1000 3750 Side 99 af 104

Activity Cost Driver Rates Tabel 6 Activity Expense Activity Cost Driver ACDQ ACDR Omstilling forarbejdning kr 60.000,00 Antal omstillings min 12000 kr 5,00 Omstilling formning kr 60.000,00 Antal omstillings min 9000 kr 6,67 Omstilling køling kr 80.000,00 Antal omstillings min 7500 kr 10,67 Råvarerhåndtering kr 240.000,00 Antal transaktioner 76 kr 3.157,89 Maskine kr 1.104.000,00 Antal maskin timer 3750 kr 294,40 pr. omstillings min pr. omstillings min pr. omstillings min pr. transaktion pr. maskintime Activity Expenses Tabel 7 ACDR ACDQ for: Acticity Expense: ACDQ for: Acticity Expense: ACDQ for: Acticity Expense: Vingummi Vingummi Lakrids Lakrids Chokolade Chokolade Omstilling forarbejdning kr 5,00 5000 kr 25.000,00 4000 kr 20.000,00 3000 kr 15.000,00 Omstilling formning kr 6,67 4000 kr 26.666,67 3000 kr 20.000,00 2000 kr 13.333,33 Omstilling køling kr 10,67 2000 kr 21.333,33 3000 kr 32.000,00 2500 kr 26.666,67 Råvarerhåndtering kr 3.157,89 12 kr 37.894,74 12 kr 37.894,74 52 kr 164.210,53 Maskine kr 294,40 1500 kr 441.600,00 1250 kr 368.000,00 1000 kr 294.400,00 Side 100 af 104