Activity Based Costing og MBS-Navision vs. 4.00

Transkript

1 Activity Based Costing og MBS-Navision vs Hovedopgave ved HD(R)-studiet Handelshøjskolen i Århus Foråret 2005 Forfatter: Peder Lars Knudsen Vejleder: Bent Høgsted Studienr

2 1. INDHOLDSFORTEGNELSE 2. ABSTRACT (ENGLISH) PROBLEMFORMULERING INDLEDNING OPGAVENS FORMÅL OG HOVEDSPØRGSMÅL OPGAVENS STRUKTUR ØKONOMISTYRING AFGRÆNSINGER ACTIVITY BASED COSTING OPBYGNING OG STRUKTUR OPERATIONEL OG STRATEGISK ABC...17 OPERATIONEL ABC...17 STRATEGISK ABC DATASTRUKTUR KOSTHIERARKI OG ABC-POSTER NAVISION VS ØKONOMISTYRING I NAVISION VARE- OG VÆRDIPOSTER...26 LØNSOMHEDSANALYSE PÅ FAKTURANIVEAU...28 DIMENSIONER OMKOSTNINGSPULJER OVERFØRSEL AF OMKOSTNINGER TIL RESSOURCEKOSTPULJER...31 CRONUS CASE 1. SALGSASSISTENAFDELINGEN...31 RESSOURCEOMKOSTNINGSKILDER OVERFØRSEL AF DIREKTE OMKOSTINGER...36 VAREKOSTPRISER...36 IKKE SPECIFICERBARE DIREKTE AKTIVITETSOMKOSTINGER...37 SPECIFICERBARE DIREKTE OMKOSTNINGER

3 6.3. OVERVEJELSER VED FORDELINGER TIL RESSOURCEKOSTPULJER...38 AFSKRIVNINGER...38 PERIODISERINGER...40 ALLOKERING AF OMKOSTINGER FRA AKTIVITETER TIL RESSOURCEKOSTPULJER...41 SEKUNDÆRE OMKOSTNINGER VIA AKTIVITETER ELLER RESSOURCEKOSTDRIVERE?...42 CRONUS CASE 2. ALLOKERING AF RESSOURCEOMKOSTNINGER TIL SALGSASSISTENTAFDELINGEN AKTIVITETER AKTIVITETSBIBLIOTEK AKTIVITETSKOSTDRIVERE...49 DRIVERTYPER...50 TIDSREGNSKAB OG IKKE-SEPCIFICERBARE DIREKTE OMKOSTNINGER...51 DIREKTE OMKOSTNINGER OG INDTÆGTER OMKOSTNINGER VED IKKE-FORBRUGTE RESSOURCER...57 CRONUS CASE 3. ABC-OMKOSTNINGER OG INDTÆGTER I SALGSASSISTENTAFDELINGEN ABC I NAVISION - MULIGHEDER OG BEGRÆNSNINGER KUNDE- OG PRODUKTLØNSOMHEDSANALYSE VED HJÆLP AF ABC OMKOSTNINGERNES VARIABILITET OG REVERSIBILITET AFDELINGSREGNSKAB MED ABC TEKNISKE KOMMENTARER ABC-MODULET...68 UDVIKLINGSTID, -TEST OG -OMFANG...68 OBJEKTPRISER KONKLUSION LITTERATURLISTE OVERSIGT OVER FIGURER

4 BILAG A - KUNDE-/VARESTATISTIKKER I NAVISION...79 BILAG B FAKTURASTATISTIK I NAVISION...81 BILAG C - EKSEMPLER PÅ VAREANALYSER I NAVISION...82 BILAG D - TABELLER MED KUNDENR. OG/ELLER VARENR...83 BILAG E ABC-POSTENS RECORD STRUKTUR

5 2. ABSTRACT (ENGLISH) Microsoft Business Solutions-Navision is one of Denmarks most widely known and used Enterprise Resource Planning (ERP) applications with modules in General Ledger, Sales and Purchase, Inventory and Warehouse Management, Manufacturing and Resource Planning, Fixed Assets, Service, HRM, CRM and WEB-integration. But MBS-Navision has been developed in order to fulfill legislative requirements regarding companies financial statements, and it is in this paper questioned if the system can deliver relevant data and analysis tools of appropriate quality to support a modern day Cost Accounting system. Activity Based Costing appeared in the 1980s and tried to establish itself as a far better alternative to the traditional contribution margin and full cost absorbing methods applied in Cost Accounting until then. The objective of this paper is to examine (i) if, and under what conditions, Activity Based Costing can improve Cost Accounting and Management compared to the data structure, tools and analysis reports and -views supplied by MBS-Navision, and (ii) if it is possible to make use of existing data in Navision, to automatically create an operational and fully integrated Activity-Based Costing system within Navision. While writing this report, a prototype of an integrated ABC-module has been developed for Navision. Using a specific case concerning a department of sales assistants, and this prototype, problems, processes and tasks regarding setting up, using and interpret ting an ABC-system and -calculation have been analyzed. Furthermore, developing the prototype module allowed for reflections as to the technical problems associated with developing such a module. The standard Navision customer and product profit analysis are primarily based on 2 reports, both listing and accumulating sales income and direct costs (plus indirect production overhead costs) associated with customers and products, thereby showing contribution margins for both dimensions. The underlying data that these 2 reports are based on, are ITEM LEDGER ENTRIES and VALUE ENTRIES. The purpose of these tables in Navision is to generate automatic inventory and C.O.G.S. postings in the general ledger. Depending on the chosen costing method (FIFO, LIFO, Average, Standard or Specific), and the treatment of Overhead Rates, this means that (i) customer and product profit analysis in Navision are based on Overhead-distributed cost prices (not clean contribution margin or full absorbing costs methods), and (ii) item ledger entries and value entries - 5 -

6 can not always be used to determine the direct costs at the unit level in an ABC-analysis. Furthermore it must be pointed out, that Navision does not have sufficient data registered on which to perform an analysis of indirect costs, apart from the possibility of using the Dimension feature to further detail an analysis of the general ledger, e.g. on the department level. The paper then presented a structure-model of an ABC-based profitability analysis (a revenue/cost matrix), with a description of the underlying data (ABC-entries) such a matrix must have in order to fulfill the analysis objectives. Then, the paper examined the structure of an Activity Based Costing setup and calculation using the prototype ABC-module; how costs are allocated to activity based cost pools using resource cost drivers, and further allocated to activities and cost objects using activity cost drivers. At the same time examples on how existing data in Navision can be used when calculating resource costs and cost drivers, where given. Throughout this, a range of specific ABC-related problems associated directly to the profitability analysis where discussed; the treatment of direct costs, depreciations, accruals, allocation of costs to resource cost pools from activities and secondary resource cost pools, different activity driver types, non-traceable direct costs, and the use of Time-Driven activity driver rates which make the updating of activity cost driver rates and activity costs more efficient. Besides, using this Time-Driven approach enables the system to calculate the costs of unused capacity not only at the monetary level, but also at the time level (hours and minutes). An ABC-calculation results in the creation of ABC-entries; that is, entries of cost and revenue information stored with information regarding (i) which resource cost pool, the costs are to be subtracted from, (ii) which activity caused the cost, and (iii) at which level the cost/revenue is placed in the cost hierarchy and, in so doing, in the customer/product profitability matrix. The traditional profitability analysis, which is used in standard Navision, gives a clear and definitive answer in relation to the contribution margins of customers and products. This margin may be either based on revenue less direct costs ( pure contribution margin), or calculated using overhead (as with Navision) or full cost absorbing methods. The distribution of overhead or full costs is done based on arbitrary allocation rates, not taking into account any casual relationship between the allocated indirect costs and the actual resources consumed by the product or customer. So, even if the answer seems definitive, it is rarely the right answer

7 An ABC-based profitability analysis may also give a kind of definitive answer. This paper gives an example of such a profitability analysis, showing the contribution margin at the customer level, calculated as revenue less ABC-allocated and direct costs at the Unit, Order and Customer levels. The range of possible profitability analysis is far wider using ABC than standard Navision (or any other traditional allocation method). At the end it all comes down to asking the right questions and looking for answers in the ABC entries (the revenue/cost matrix). But ABC-based profitability analysis really wont payoff until the analyst starts looking deeper, asking questions about the underlying activities and costs. Going from what do we make on customers and products to why do we make a profit/loss on customers and products. Using the data and tools available in Navision really won t get you any answer to this question, as a closer look and analysis of indirect costs are barely possible. But ABC may give you answers as to which and how many activities the individual customers and products are using, and how much performing these activities will cost the company. It is, however, not without difficulties; trying to get a closer look at the underlying resource costs and especially their degree of variability and reversibility will give the analyst problems. Neither Activity Based Costing in general, or the prototype ABC-module specifically can give the analysts such direct insight using one tool only. The variability and reversibility of resource costs are important, because it tells the analysts of the cost behavior in case of activities being abolished (maybe due to the phasing out of products or customers) or activities being performed more efficiently. If it is not possible to cash in on such initiatives they are hardly worth implementing. In this paper 4 tools are presented, that combined will give the analyst insight into the underlying resource characteristics: 1. Grouping activities according to the short-term variability of the activity costs. Some activity costs may be considered fixed with respect to the short-term variation in demand, while others may be considered variable. 2. Grouping resource as either Flexible or Committed. Flexible resources may be deployed and redeployed on short notice, while the expenses for committed resources are incurred - 7 -

8 whether the resources are used or not. One activity driver may be set up to handle the fully flexible resources, and one driver to handle all others, giving the analyst insight into the 2 different types. 3. Using the direct (but not directly traceable) cost feature on the activity driver card. Thereby indicating and being able to handle the fact, that some costs are fully variable with the activity level. 4. A report showing an exploded resource cost pool, listing the underlying cost sources (e.g. salary, rent, office supplies, etc.). Take notice of the fact, that activities attached to the same resource cost pool, may consume resources differently (see paragraph 1, above). An example was also given, showing an activity based department report. Compared to a traditional, general ledger view of the department spending, an ABC-based department report shows what activities have been performed at the costs incurred. Furthermore, the ABC-based report will show direct revenues the individual activities may have produced. On the basis of the ABC-prototype and the examination of its elements, and the examples produced using the sales assistant case, it can be concluded, that it is possible to develop a fully integrated og operational ABC-module for Navision re-using the vast amount of data already registered in the database during everyday operations. But at the same time it must be emphasized that developing such a module may involve technical problems and great cost, if the module must be user operated only, that is, it can be set up and operated without the involvement of a Navision developer. In the prototype ABC-module the user may key in data manually or import data from using a simple text file. But the advantages of integrating an ABC-module in Navision must come from being able to re-use data automatically. Otherwise a company may as well acquire an external, non-integrated application, herein entering or importing the necessary data

9 3. PROBLEMFORMULERING 3.1. INDLEDNING Navision er et af Danmarks mest udbredte ERP-systemer med moduler indenfor et stadigt voksende antal funktionsområder i en moderne virksomhed, som f.eks. finans, salg og køb, lager og logistik, produktions- og kapacitetsstyring, time-/sagsstyring, HRM, anlægsaktiver, CRM og WEBintegration. På trods af en løbende udbygning af programmet i både bredden og dybden, er det tvivlsomt om et system, der primært er udviklet for at kunne opfylde kravene til det eksterne regnskab, kan levere data og værktøjer af tilstrækkelig kvalitet til brug for dagens økonomistyring. ABC fik i forbindelse med sin fremkomst i begyndelsen af 1980 erne stor opmærksomhed som et brugbart og (hævder opfinderne bag ABC-tankegangen) oftest langt bedre alternativ til de da eksisterende fordelings- og kalkulationsprincipper indenfor økonomistyringen. Den forventede hurtige og omfangsrige udbredelse af tankegangen når dette måles på konkrete ABC-projekter og initiativer lader dog vente på sig. Specielt synes mindre og mellemstore virksomheder endnu ikke at have taget tankegangen til sig og ladet den manifestere sig i konkrete ABC-handlingsplaner og initiativer 1. Men i mit daglige arbejde som Økonomi- og IT-konsulent møder jeg en stadig spirende interesse for den tankegang, der ligger bag ABC-teorien, specielt begrundet i de utilstrækkeligheder de oftest benyttede dækningsbidrags- og fuldfordelingsmetoder indebærer. En del af forklaringen på den i Danmark begrænsede udbredelse af praktiske ABC-projekter skal måske findes i at kun meget få ERP-systemer indeholder integrerede ABC-moduler 2. I langt de fleste tilfælde er virksomheder, der ønsker at arbejde med ABC-kalkulationer, derfor nødsaget til at benytte 3. parts produkter, der ikke direkte er udviklet til brug for et specifikt ERP-system, og som i sagens natur derfor heller ikke fuldt ud vil kunne udnytte den meget store (og stadig stigende), dybe og bredde datamængde, der er indeholdt i dagens ERP-systemer. I forlængelse heraf, vil det ofte være besværligt og dyrt for virksomhederne at få ny-udviklet eller tilrettet funktionaliteten i disse eksterne produkter, hvis funktionaliteterne ikke svarer til brugernes forventninger og behov. 1 De 6 cases, der er gennemgået i Bukh og Israelsen (2003) omhandler således ABC projekter i Danske Bank, DSB, Milliken Denmark A/S, Novozymes A/S, Post Danmark, samt SonionMicrotronic A/S alle pænt store virksomheder. 2 Positivt kendes kun til et integreret ABC-modul i SAP, se Cokins (2004)

10 En ofte set løsning herpå, er at virksomhederne vælger at benytte eksempelvis Excel til databearbejdningen. Det giver så en række andre ulemper; f.eks. fejlmulighederne ved manuel indtastning af data, Excels problemer med at håndtere store datamængder, ligesom fejlmulighederne i Excel er betydelig større i store løsninger end i et database værktøj. Af samme grund vælger mange derfor at benytte Acces eller et andet database værktøj til (en del af) databehandlingen. Navision er basalt set kun et databaseværktøj som Acces dog med den betydelige forskel, at der fra Microsoft Business Solutions (MBS) side er udviklet en stor del standard funktionalitet til håndtering af en række af virksomhedens daglige regnskabs- og styringsmæssige opgaver. Derudover er alle Navisions standard funktionaliteter og udviklingsmiljø åben for forhandlernes certificerede udviklere, som der i parentes bemærket findes flere hundrede af i Danmark OPGAVENS FORMÅL OG HOVEDSPØRGSMÅL Denne opgave har til formål (i) at undersøge om og under hvilke forudsætninger Activity Based Costing kan forbedre økonomistyringen i forhold til det datagrundlag og de standard redskaber, der er til rådighed i MBS Navision vs. 4.00, samt i forlængelse heraf, (ii) om man med fordel kan benytte og automatisere udnyttelsen af de oplysninger, der ligger i Navision s database, til et brugbart Activity Based Costing-system. Formålet vil forsøges nået gennem besvarelsen af følgende hovedspørgsmål: I hvilket omfang opfylder standard Navision den moderne økonomistyringsfunktions behov for præcise data og økonomistyringsværktøjer? Er det fra både en teknisk og en brugermæssig synsvinkel - muligt og formålstjenstligt at udvikle et integreret ABC-modul til Navision? Herunder: o I hvilket omfang kan eksisterende data og værktøjer fra Navision genbruges i et ABC-modul? o I hvilket omfang vil det være muligt at udvikle et ABC-modul, der efterfølgende alene vil kunne opsættes og benyttes på brugerniveau? På hvilke områder vil et ABC-modul kunne forbedre økonomistyringen i en virksomhed med et Navision system?

11 Til hjælp for besvarelsen af ovenstående spørgsmål, er der sideløbende med udarbejdelsen af denne opgave, udviklet en prototype på et decideret ABC-modul til Navision. Udviklingen af denne protype har haft 2 overordnede formål 1 : 1. At undersøge de problemer, der er forbundet med udviklingen af et integreret ABC-modul i Navision vs Det har altså ikke været formålet ifm. denne opgave, at udvikle et fuldt integreret ABC-modul, men alene at arbejde med en prototype for på den måde at få identificeret og undersøgt de tekniske, udviklingsmæssige problemstillinger ved udviklingen af et sådan modul. 2. Benytte prototypen til illustration af, hvorledes et ABC-system opsættes og efterfølgende kan benyttes i analyseøjemed. Denne illustrationen foretages ved inddragelse af praktiske case baserede eksemplificeringer af, hvorledes udviklingen af et ABC-kalkulationssystem i en virksomhed 2 kan foretages. Derudover har selve opgaven og ikke mindst arbejdet hermed haft til formål at skabe det teoretiske fundament for udviklingen af modulet OPGAVENS STRUKTUR Opgaven indeholder 4 overordnede analyser/afsnit: 1. Første trin er en kort introduktion til ABC, og herunder en stillingtagen til den afsluttende datastruktur, et internt ABC-regnskab kræver. Når det er valgt at begynde med en introduktion af ABC skyldes det, at kendskab til principperne i ABC-tankegangen er nødvendige for vurderingen af, hvorvidt data i standard Navision kan genbruges i ABC-modulet. En vurdering, der foretages i trin 2: 1 Ud over ønsket om på sigt at få udviklet et fuldt funktionsdygtigt ABC-modul. 2 Det skal bemærkes at betegnelserne udvikling af et ABC-modul og udvikling af et ABC-system i denne opgave benyttes ifm. hhv. det arbejde der fra Navision udviklerens (moduludviklerens/-designerens) side er forbundet med analyse af standard Navision, samt system- og applikationsudviklingen af ABC-modulet, og det arbejde, der fra virksomhedens side (udføres af systemudvikleren/designeren) er forbundet med analyse af virksomhedens aktiviteter og processer og den efterfølgende opsætning og gennemførelse af beregninger ifm. en ABC-kalkulation i Navision (ved brug af det udviklede ABC-modul). Mao. benyttes ABC-MODUL om selve det Navision integrerede ABC-modul, mens ABC- SYSTEM refererer til det ABC-kalkulationssystem, den enkelte virksomhed opstiller

12 2. Dernæst gennemgås og analyseres standard Navisions økonomistyringsværktøjer og grundlæggende principper. Denne analyse har 3 hovedformål: At påpege eventuelle mangler i Navision på økonomistyringsområdet. At danne grundlag for en efterfølgende vurdering af, hvorvidt og eventuelt i hvilket omfang et ABC-modul vil kunne forbedre økonomistyringen i Navision. At danne grundlag for eventuel genbrug af standard funktionalitet og værktøjer i ABCmodulet. 3. Herefter gennemgås de enkelte elementer i opsætningen af en ABC-kalkulation ved hjælp af det Navision integrerede ABC-modul. Afsnittet har til formål dels (i) at redegøre dybere for Activity Based Costing og de valg og fravalg, der fra moduludviklerens side er foretaget med hensyn til funktionalitet og design af ABC-modulet, dels (ii) at danne grundlag for en konklusion fsva. ABC-modulets anvendelighed vis-a-vis Navisions standard økonomistyringsfunktionalitet og principper. 4. Et afsnit, der beskriver de forbedringer, muligheder og begrænsninger, der ligger i at benytte et integreret ABC-modul i Navision ift. applikationens standard økonomistyringsfunktionalitet. Afsnittet tager udgangspunkt i ovenstående afsnit, og indeholder en analyse af de faktorer og betingelser under hvilke, brugen af ABC medfører øget informationsmæssig værdi for virksomhedens ledelse. Afsnittet indeholder endvidere et kort oprids af de tekniske og udviklingsmæssige problemer, der er blevet identificeret ifm. udviklingen af ABC-prototypen. Dette sidste punkt er ligeledes af betydning for en vurdering af de afledte problemer, brugerne af systemet vil opleve og dermed i sidste ende hvorvidt et integreret ABC modul set fra brugernes synspunkt vil være anvendeligt ØKONOMISTYRING AFGRÆNSINGER Økonomistyring er mange ting og involverer mange formål, metoder og sågar fagområder. Nedenstående Figur 3-1 gengiver et eksempel på økonomistyringens opgaver (den strategiske), fokusområder og metoder. Kaplan og Cooper 1 beskriver hvorledes ABC kan benyttes ifm. en lang række af de øvrige metoder, der er nævnt i Figur 3-1; eksempelvis Target og Quality Costing, samt Costdriver analysis. Og brugen af ABC som et element i eller grundlag for en lang række andre analyser øges næsten hverdag. 1 Kaplan & Cooper (1998)

13 Opgave 1. Indsamle og præsentere data om omkostninger, priser, mængder, markedsandele, pengestrømme, ressourceudnyttelse, kapacitetsbelægning, etc. 2. Forbedring af beslutningsprocessen ved at tilvejebringe information med formål at træffe bevidste målrettede belutninger med økonomisk konsekvens. Fokus Metoder 1. Internt 2. Eksternt 3. Information 4. Finansielle data 5. Non-finansielle data 6. Konkurrenter 7. Kunder 8. Produkter 9. Langsigtet 10. Struktur 1. Target costing 2. Quality costing 3. Balanced Scorecard (BSC) 4. Activity Based Costing / Management (ABC/ABM) 5. Competitor analysis 6. Product attribute analysis 7. Valuechain analysis 8. Strategic positioning analysis 9. Costdriver analysis 10. Lifecycle costing FIGUR 3-1. FOKUS, OPGAVER OG METODER I PARAPLYKONCEPTET STRATEGISK ØKONOMISTYRING 1 Det står derfor umiddelbart klart, at der må ske en afgrænsning af begrebet økonomistyring, hvorfor det er valgt at tage udgangspunkt i den opgave, ABC primært hævder direkte at medvirke til løsningen af, og som har det primære fokus i ABC-tankegangen nemlig Produkt/Kundelønsomhedsanalyse (strategisk ABC) 2. ABC kan i lige så høj grad rette sig mod lønsomhedsanalyse af projekter, ydelse, geografiske områder, etc. eller eksempelvis mod omkostninger ved indkøb af råvarer, kreditorer, etc. Det afhænger af de valgte kostobjekter. Principperne i udviklingen og brugen af et ABC-system er det samme, uagtet hvilke kostobjekter, der er valgt. Men af praktiske og 1 Mejer (2002). 2 Se eksempelvis Kaplan & Narayana (2001), Kaplan & Anderson (2003), Cooper & Kaplan (1988) og Cooper & Kaplan (1991)

14 tekniske grunde (ift. sammenligningen med og udviklingen af ABC-modulet i Navision) er det valgt alene at fokusere og udvikle modulet til håndtering af Produkter og Kunder som kostobjekter. Det ses, at opgavens analyser dermed tager udgangspunkt i ABC, og de redskaber denne tilbyder at analysen så at sige sker på ABC-tankegangens præmisser. En sådan tilgangsvinkel synes dog nødvendig for at kunne opfylde denne opgaves rammer (her tænkes specielt på sideantallet), men samtidig er det dog i god overensstemmelse med opgavens hovedformål at undersøge om og under hvilke forudsætninger Activity Based Costing kan forbedre økonomistyringen. Gennem opgaven vil en række af ABC s andre elementer og muligheder/formål dog også blive berørt, men det er på evnen til at frembringe en detaljeret og brugbar Kunde/Produktlønsomhedsanalyse, ABC (og det udviklede ABC-modul) i sidste ende vil blive vurderet

15 4. ACTIVITY BASED COSTING OPBYGNING OG STRUKTUR Nedenstående Figur 4-1 gengiver den overordnede struktur i ABC-tankegangens fordeling af indirekte og direkte omkostninger til aktiviteter og kostobjekter. Inddirekte (faste) omkostninger Ressourcekostdrivere $ Ressourcekostpulje 1 $ Ressourcekostpulje 2 $ Ressourcekostpulje N Aktivitetskostdrivere Aktivitet 1 Aktivitet 2 Aktivitet 3 Aktivitet 4 Aktivitet N Direkte omkostninger: - arbejdsløn - materialer - andre direkte omkostninger Kostobjekter: Produkter, Services/Ydelser, Kunder, etc. FIGUR 4-1. DET AKTIVITETSBASEREDE REGNSKABS GRUNDSTRUKTUR 1 1 Lettere bearbejdet pba. Kaplan & Cooper (1998), p

16 2 forhold skal dog understreges i forhold til Figur 4-1: 1. Der er netop tale om den overordnede struktur. Som det bliver belyst senere er strukturen ikke så åbenlys stringent og ren som figuren giver indtryk af. Men det er et udmærket udgangspunkt for præsentation af tankegangen bag ABC. 2. Modellen er tilrettet i forhold til den standard model der kendes primært fra Kaplan & Cooper 1, så den viser opgaveskrivers opfattelse af fordelingsmekanismerne og -elementerne, og understøtter den overordnede struktur i ABC-modulet 2. Den grundlæggende struktur/tankegang bag ABC er, at det er de aktiviteter, virksomheden udfører, der medfører omkostninger 3. Virksomhedens omkostninger allokeres på baggrund af ressourcekostdrivere til ressourcekostpuljer (cost pools). En sådan ressourcekostpulje vil sædvanligvis være (men er ikke begrænset til) en afdeling, da aktiviteter jo oftest er forankret i afdelinger. Som eksempel på oftest benyttede ressourcekostdrivere kan nævnes antal ansatte (i afdelingen), antal kvadratmeter, etc. Med andre ord; indirekte omkostninger fordeles først til ressourcekostpuljer efter hvor mange ansatte, der er i afdelingen (IT-udgifter, kantineordning, og lign.), hvor mange kvadratmeter afdelingen ligger beslag på (el, varme, husleje, og lign.), etc. De aktiviteter virksomheden udfører er forbundet med et ressourcetræk fra disse ressourcekostpuljer og omkostningerne allokeres derfor fra ressourcekostpuljerne til aktiviteter. Allokeringen sker på baggrund af aktivitetskostdrivere, og som eksempel herpå kan nævnes antal oprettede kunder (til aktiviteten Oprette nye kunder ), antal salgsordrelinier (til aktiviteten Modtage og behandle salgsordrer), etc. Endelig fordeles aktivitetsomkostningerne på kostobjekter; som tidligere nævnt, i denne opgave produkter og kunder, for på den måde at kunne opstille en produkt/kundelønsomhedsanalyse. Denne fordeling sker ved at undersøge hvilket eller hvilke kostobjekter og elementer herindenfor, der specifikt har forårsaget de forskellige ressourcetræk. 1 Kaplan & Cooper (1998, p. 84). 2 Hos Kaplan & Cooper (1998) er det første element INDIREKTE (FASTE) OMKOSTNINGER ikke medtaget, ligesom RESSOURCEKOSTDRIVER og AKTIVITETSDRIVER elementerne knytter sig til elementerne mellem hhv. RESSOURCEKOSTPULJE og AKTIVITET, samt AKTIVITET og KOSTOBJEKT. Kaplan & Cooper s model er faktisk udarbejdet under den forudsætning at omkostninger ved hjælp af ressourcekostdrivere kan allokeres til aktiviteter, fordi eksempelvis én afdeling alene udfører én aktivitet en forudsætning, der selvfølgelig ikke holder i praksis, om som de da også ophæver senere i kapitel 13 (1998). 3 Faktisk er det anskaffelsen af de ønskede ressourcer, der medfører omkostninger. Hvorvidt disse ressourcer udnyttes fuldt ud, er et af de helt centrale spørgsmål ABC søger at besvare se senere afsnit 7.3 om udnyttede og ikke-udnyttede ressourcer

17 Så selvom retningen i Figur 4-1 går fra toppen mod bunden, fra ressourceomkostningerne mod kostobjekterne er der i virkeligheden tale om en modsatrettet bevægelse; det er kostobjekterne (produkter og kunder), der forudsætter gennemførelsen af forskellige aktiviteter i virksomheden aktiviteter, der trækker eller kræver tilstedeværelsen af ressourcer, sluttelig medførende en række ressourceomkostninger. Som vi vil opleve gennem denne opgave, vil ABC og arbejdet hermed kunne danne grundlag for en stor del forskelligartede analyser. Det er derfor af største vigtighed, at selve formålet med udviklingen af et ABC-system defineres og præciseres. Derudover er et vigtigt element (som ikke direkte fremgår af figuren), at opbygningen af et ABC-system bør starte med en procesgennemgang, - analyse og -beskrivelse, med det formål først at få defineret de vigtigste aktiviteter indenfor de områder, der ønskes analyseret. Med udgangspunkt i aktiviteterne identificeres herefter de ressourceomkostningsgrupper, der danner det omkostningsmæssige grundlag for aktiviteterne - heraf navnet Activity Based Resourcepools, som bruges i visse engelsksprogede bøger og artikler om emnet OPERATIONEL OG STRATEGISK ABC. Normalt skelner man mellem strategisk og operationel ABC populært sagt henholdsvis at gøre de rigtige ting og gøre tingene rigtigt. Eller med Svendsen & Christensens 1 ord; Hvad koster ting? og Hvorfor koster ting (cost objects) noget? OPERATIONEL ABC Operationel ABC retter sig mod (en effektivisering af) aktiviteter og processer både indenfor virksomheden, men også ifm. grænsefladerne til eksterne leverandører, kunder og lignende interessenter. Det drejer sig altså her om at: Få omkostningsbestemt aktiviteterne gennem en fastlæggelse af disses ressourcetræk. Få identificeret og beskrevet processor som en række sammenhængene aktiviteter, og dermed omkostningsbestemt disse processor. Nærmere at analysere omkostningsstrukturen i virksomheden fsva. de enkelte aktiviteter og processor. 1 Svendsen & Christensen (2005)

18 Formålet med et sådan operationel ABC regnskab kan eksempelvis være: Benchmarking af aktiviteter og processor. For eksempel med henblik på en vurdering af om aktiviteter og processor skal outsources, eller om der kan opnås effektiviseringsgevinster gennem en målrettet indsats. Fastlæggelse af effektiviseringsmålsætning, med efterfølgende mulighed for opfølgning på disse målsætninger. Vurdere om aktiviteter er overflødige/værdiskabende eller med fordel kan overdrages til andre aktører i værdikæden gennem et øget og tættere samarbejde. I henhold til Figur 4-1 retter operationel ABC (også kaldet ABM Activity Based Management) sig altså primært mod aktiviteterne og fordelingen af de indirekte omkostninger hertil. STRATEGISK ABC Inspirationen til det strategiske arbejde skabes primært gennem fordelingen af aktivitets- og direkte omkostninger på kostobjekter - som det er gældende for denne opgave; produkter og kunder. Men fordelingen kan ligeledes ske til projekter, indkøbte varer ( Cost of supplying i modsætning til rene indkøbspriser), etc. Men modsat hvad der kendes fra fuldfordelingsmetoden, fordeles indirekte omkostninger ikke nødvendigvis helt ned på enhedsniveauet, men indplaceres gerne højere i kosthierarkiet, så arbitræer fordelinger så vidt muligt undgås. Omkostninger som følge af en reklamekampagne for en enkelt af virksomhedens produktlinier, forsøges altså ikke allokeret til de enkelte produkter (enhedsniveauet), men indplaceres på Produktlinie-niveauet. Nedenfor er i Figur 4-2 gengivet et eksempel på et sammenkoblet produkt- og kundehierarki, med indplacerede aktiviteter tilhørende de respektiver niveauer

19 Virksomhedens ledelse Visse ledelsesfunktioner Vedligehold af bygninger Forsikringer Aktiviteter på virksomhedsniveau Aktiviteter på markedsniveau Markedsundersøgelser Annnoncering Forskning og udvikling Teknologi Lagre Overskydende kapacitet Produktliniespecifik promotion Aktiviteter på produktlinieniveau Aktiviteter på salgsregionsniveua Transportmidler Specifik annoncering Design af liniespecifik emballage Brochurer og kataloger Vedligehold af processpecifikation Sælgere/repræsentantbesøg Produktforbedringer Produktspecifik markedsføring Aktiviteter på produktniveau Aktiviteter på kundeniveau Indpakning Returneringer og klager Vedligehold styklistespecifikation Kreditter og betalingssystem Setup/opstilling Ordreregistreringer Materialeflytninger Indkøbsordrer Aktiviteter på serieniveau Aktiviteter på ordreniveau Forsendelser Fakturering Kontrol/inspektion Håndtering Direkte omkostninger: - arbejdsløn - materialer - andre direkte omkostninger Aktiviteter på (produkt-) enhedsniveau FIGUR 4-2. EKSEMPEL PÅ SIMULTANE KUNDE- OG PRODUKTHIERARKIER MED FORDELTE AKTIVITETER 1. Når Figur 4-2 kaldes et eksempel skal det ses i lyset af, at virksomheder kan vælge forskellige hierarkier afhængig af deres organisatoriske og markedsmæssige situation. Kostobjekt hierarkierne bør tage udgangspunkt i en kombination af analysebehovet, de identificerede aktiviteter og mulighederne for i det hele taget at henføre omkostninger til det pågældende niveau. Det er ovenstående kosthierarki, der danner grundlaget for ABC-kalkulens Kunde-/Produktlønsomhedsanalyse. 1 Egen tilvirkning pba. Bukh & Israelsen (2004), p. 51 og p

20 4.2. DATASTRUKTUR KOSTHIERARKI OG ABC-POSTER Det er indenfor systemdesign og udvikling af IT programmer god skik at starte med slutningen, det vil i dette tilfælde sige, at få defineret den datastruktur, kost- og omsætningsoplysningerne sluttelig skal ende i. Denne struktur er gengivet i nedenstående Figur 4-3, der viser hvorledes en indtægts-/omkostningsmatrix til brug for en lønsomhedsanalyse og baseret på kosthierarkiet i Figur 4-2 skal se ud. KUNDEPERSPEKTIV Kunde 1 Kunde 2 Kunde 3 Kunde 4 Seriebestemte indtægter og omkostninger Produktseriebidrag Produkbestemte indtægter og omkostninger Produktseriebidrag Produktlinie indtægter og omkostninger Produktliniebidrag Virksomhedens indtægter og omkostninger Virksomhedsbidrag Prod PRODUKTPERSPEKTIV Prod 2 Prod 3 Prod Prod 5 Ordredirekte indtægter og omkostninger 2 Ordrebidrag Kunde indtægter og omkostninger 4 Kundebidrag Region indtægter og omkostninger Regionsbidrag Markeds indtægter og omkostninger Markedsbidrag FIGUR 4-3. INDTÆGTS- OG OMKOSTNINGSMATRIX TIL BRUG FOR ABC PRODUKT/- KUNDELØNSOMHEDSANALYSEN 1 1 Kilde: Egen tilvirkning, dog med tydelig inspiration fra Israelsen & Reeve (1998)

21 Det skal nævnes og understreges at Figur 4-3 faktisk mangler en dimension. Se eksempelvis på celle 3. Det fremgår her, at produktserie indtægterne og omkostningerne er kunde-uafhængig. Det er ikke nødvendigvis tilfældet i en ordreproducerende virksomhed. De omkostninger på serieniveau, der kan henføres til en produktionsordre, kan ligeledes henføres til kunden! Med andre ord burde figuren være 3-dimensionel for på den måde at markere disse muligheder. Men for at bevare overskueligheden, er dette dog ikke gjort! Beregningen af totalværdien for de enkelte celler i figuren sker som en summation af de underliggende poster, ABC-modulet gerne skulle generere her kaldet ABC-poster. Man skal altså forestille sig, at der for hvert salg af Produkt 1 til Kunde 1, dannes en ABC-post med oplysninger om kostog salgsværdi. På samme måde vil der blive dannet én post med oplysninger om aktivitetsomkostninger og eventuelle indtægter for hver salgsordre, der dannes i systemet, etc. En sådan post skal som udgangspunkt have nedenstående felter, for at kunne opfylde analyseformålet: FELT LØBENR. PRODUKTHIERARKINIVEAU PRODUKTHIERARKIKODE KUNDEHIERARKINIVEAU KUNDEHIERARKIKODE BESKRIVELSE En entydig identifikation af den enkelte post, som er nødvendig i alle databaseprogrammer Her gemmes oplysning om det niveau i produkthierarkiet, den pågældende omsætning/omkostning tilhører. I vores gennemgående eksempel vil der her være tale om Enhed, Serie, Produkt, Produktlinie og Virksomhed (selvom der kun er én værdi på dette sidste niveau). For Enhed, Serie og Produkt vil koden være VARENUMMERET, for Produktlinien PRODUKTKLINIEKODEN, og endelig vil den for Virksomheden bare være en VIRKSOMHEDSKODE (som der altså kun er defineret én af i systemet). Her gemmes oplysning om det niveau i kundehierarkiet, den pågældende omsætning/omkostning tilhører. I vores gennemgående eksempel vil der her være tale om Enhed, Ordre, Kunde, Region og Marked. For Enhed, Ordre og Kunde vil koden være KUNDENUMMERET, for Regionen vil det være en REGIONSKODE, og endelig vil den for Marked bare være en MARKEDSKODE

22 FELT ANTAL OMSÆTNING OMKOSTNING BESKRIVELSE Her angives antallet, f.eks. antal solgte produkter, eller antal gennemførte aktiviteter. Her registreres indtægten. Her angives omkostningen, som kan være enten direkte eller allokeret via en aktivitet. Derudover vil man vælge at knytte en række andre oplysninger til ovenstående ABC-poster afhængig af den analysedybde, der ønskes. Skal det eksempelvis være muligt at opgøre de samlede indtægter og omkostninger for hver enkelt ordre (celle 2), eller er det tilstrækkeligt at kunne opgøre de samlede indtægter og omkostninger for kunden på dette niveau? I førstnævnte tilfælde skal tabellen udvides med data om kilden (ordrenr., fakturanr. eller lignende). I afsnit 6 og 7, samt Bilag E er den struktur, der er valgt for ABC-modulet og posten nærmere gennemgået. Her ses det, at ABC-posten netop indeholder en række andre oplysninger, der muliggør yderligere analyser og kalkulationer. De celler, der i Figur 4-3 er nummererede refererer til nedenstående eksempel-gennemgang. I eksemplerne er ligeledes gengivet, hvorledes en post tilhørende de respektive celler vil kunne se ud. 1. I dette felt er (direkte) indtægter og omkostninger forbundet med ét salg af ét enkelt produkt til én enkelt kunde angivet. FELT INDHOLD LØBENR. 1 PRODUKTHIERARKINIVEAU ENHED PRODUKTHIERARKIKODE VARENR. KUNDEHIERARKINIVEAU ENHED KUNDEHIERARKIKODE KUNDENR. ANTAL 20 OMSÆTNING OMKOSTNING

23 FELT INDHOLD LØBENR. 2 PRODUKTHIERARKINIVEAU PRODUKTHIERARKIKODE KUNDEHIERARKINIVEAU ENHED KUNDEHIERARKIKODE KUNDENR. ANTAL 1 OMSÆTNING OMKOSTNING Her registreres de indtægter og omkostninger, der er forbundet med håndteringen af den enkelte salgsordre til kunden. Som et eksempel på en indtægt kan nævnes fakturagebyr. I Navision er det muligt automatisk at få allokeret sådanne indtægter til de enkelte vareposter dannet ifm. bogføring af fakturaen. ABCsystemdesigneren skal altså være opmærksom på dette, så sådanne indtægter ikke medtages 2 gange. 3. Her er de indtægter og omkostninger, der er forbundet med produktionen af en serie af produktet. Er der tale om en ren handelsvirksomhed, vil det være de omkostninger, der er forbundet med køb og modtagelse af produkterne. FELT INDHOLD LØBENR. 3 PRODUKTHIERARKINIVEAU SERIE PRODUKTHIERARKIKODE VARENR. KUNDEHIERARKINIVEAU KUNDEHIERARKIKODE ANTAL 1 OMSÆTNING OMKOSTNING Aktiviteter (eller direkte omkostninger/indtægter) på kundeniveauet kan være oprettelse af kunden, den periodiske håndtering af kunden (rykkere, rentenota og kontoudtog), håndtering af indbetalinger, reklamationer, etc. FELT INDHOLD LØBENR. 4 PRODUKTHIERARKINIVEAU PRODUKTHIERARKIKODE KUNDEHIERARKINIVEAU KUNDE KUNDEHIERARKIKODE KUNDENR. ANTAL 1 OMSÆTNING OMKOSTNING

24 FELT INDHOLD LØBENR. 5 PRODUKTHIERARKINIVEAU PRODUKTLINIE PRODUKTHIERARKIKODE PRODUKTLINIEKODE KUNDEHIERARKINIVEAU KUNDEHIERARKIKODE ANTAL 1 5. En omkostning, der alene relaterer sig til produktlinieniveauet. Igen hvis en produktlinie alene afsættes til én kunde, vil disse omkostninger (og eventuelle indtægter) endvidere blive knyttet til kunden, og dermed ligeledes medgå i beregningen af Kundebidraget. OMSÆTNING OMKOSTNING For virksomhedsniveauet gælder at der alene er én dimensionsværdi, i dette tilfælde kaldet Cronus. FELT INDHOLD LØBENR. 6 PRODUKTHIERARKINIVEAU VIRKSOMHED PRODUKTHIERARKIKODE CRONUS KUNDEHIERARKINIVEAU KUNDEHIERARKIKODE ANTAL 1 OMSÆTNING OMKOSTNING 225 Det skal afslutningsvis nævnes, at denne datastruktur forudsætter, at der i systemet, er skabt relation mellem Kundenr., Region og Marked, samt mellem Varenr., Produktlinie og Virksomhed. Vi vender tilbage til dette punkt senere i afsnit

25 5. NAVISION VS Navision er et såkaldt 80/20 produkt, dvs. det hævder at kunne dække 80% af de behov, en virksomhed måtte have indenfor de tilbudte moduler. De resterende 20% forudsættes tilrettet og udviklet af certificerede udviklere i Navisions udviklingsmiljø kaldet C/SIDE. Udviklingen af ny funktionalitet sker på 3 niveauer; først og fremmest af MBS, dvs. den stadige videreudvikling af standard Navision. Derudover har en række Navision forhandler- og konsulenthuse udviklet og vedligeholder deres egne integrerede vertikale og horisontale moduler. Payment Management (integration til Office- Banking), EDI, Lønmodul og integration til e-faktura er eksempler herpå. Endelig er der foretaget kundespecifikke tilpasninger til praktisk talt samtlige solgte Navision løsninger her i landet. Det drejer sig om alt lige fra tilpasning af faktura- og kreditnotaudskriften, automatisk hensættelse til markedsføringsbidrag ifm. fakturering af udvalgte debitorer, modul til håndtering af kreditorafstemninger, konsolidering, eller hvad virksomheden nu måtte have brug for. Modulerne indgår som en integreret del af den kundespecifikke Navision løsning, uden at det i princippet er muligt at se, hvad der er standard Navision funktionalitet og hvad der er specialudviklet. C/SIDE udviklingsmiljøet er for den overvejende dels vedkommende lukket for almindelige brugere 1, hvorfor målet med enhver udvikling af ny og supplerende funktionalitet er, at funktionaliteten skal kunne anvendes udelukkende gennem applikationsobjekterne. Det vil sige brugeren skal kunne foretage tilvalg og ændring af funktionalitet gennem ændring af opsætningsdata i systemet og uden involvering fra en udvikler. 1 Almindelige brugere har alene adgang til at tilføje nye og flytte eksisterende felter på tabeller, skærmbilleder og rapporter. Der er ikke adgang til selve koden, dvs. funktioner, triggers, og lign

26 5.1. ØKONOMISTYRING I NAVISION Standard Navision vs indeholder en række udskrifter og skærmbilleder, der på den ene eller anden måde relaterer sig til Kunde-/Produktlønsomhedsnalayse. Nedenfor er udvalgt 3 områder, som i særdeleshed benyttes hertil. Udover at belyse og præsentere de specifikke værktøjer er hovedformålet med nedenstående afsnit at beskrive de data og deres kvalitet, disse værktøjer baserer deres analyser på. VARE- OG VÆRDIPOSTER I Navision giver specielt 2 rapporter et overblik over kunde- og produktlønsomheden; Kunde-/varestatistikken og Vare-/Kundestatistikken. Forskellen på de 2 består i, at rapporterne summerer avancerne på hhv. kunde- og varenummerniveau. Man kan altså af rapporten se hhv. avancen pr. kunde og pr. vare. Eksempler på disse 2 udskrifter er gengivet i Bilag A. Kunde-/varestatistikken og Vare-/kundestatistikken baserer sig begge på samme data i systemet kaldet værdiposter. Vareposter i Navision registrerer de fysiske bevægelser på lageret. Værdiposter knytter sig til én enkelt varepost, og vedrører de økonomiske bevægelser på lageret i relation til den varepost, værdiposten er knyttet til. Til én varepost, f.eks. købet af 10 stk. af et varenummer (se Figur 5-1), kan sagtens knytte sig en række værdiposter: I forbindelse med lagertilgangen registreres eksempelvis den på det tidspunkt kendte (forventede) kostværdi for de indkøbte varer. Denne kan efterfølgende blive reguleret, f.eks. (i) ifm. fordeling af fragt- eller toldomkostninger til leveringen, (ii) regulering af lagerværdien, når kreditorfakturaen modtages og bogføres (prisen på varerne kan være forskellig fra den på modtagelsestidspunktet kendte kostpris), (iii) tillæg af evt. indirekte produktionsomkostninger (IPO). Ved hjælp af denne datastruktur er der til Navision udviklet en speciel Vare-analyse funktionalitet med henblik på nærmere analyse af vare- og værdiposter. Der er tale om et meget avanceret modul, der muliggør analyse af varekøb, -lager og -salg, lagerreguleringer og overførsler, etc. på både beløbs-, pris- og antalsniveau. Analyserne kan endvidere udføres på udvalgte debitorer og kreditorer. Bilag C gengiver et par eksempler på denne analysefunktionalitet

27 FIGUR 5-1. ET EKSEMPEL PÅ VARE- OG VÆRDIPOSTER I NAVISION På trods af disse avancerede værktøjer skinner det klart igennem, at der er i Navision kun er ét kostsystem det system, der registrerer og vedligeholder kostværdier til brug for det eksterne regnskab. Det betyder eksempelvis, at systemet ikke kan benyttes til samtidig håndtering af fuldfordelte eller direkte kostværdier ( ren dækningsbidragsanalyse). Og det betyder at kunde-/varestatistikken trækkes pba. direkte omkostninger + eventuelle IPO ere, hvilket ledelsen selvfølgelig skal være opmærksom på ifm. umiddelbar og videre analyse af tallene. I ABC-kalkulen indgår i kostobjektet PRODUKT, de direkte produktomkostninger 1. Ifm. genbrug af kostdata i ABC-modulet betyder det, at nævnte data kun i nogle tilfælde vil kunne trækkes direkte fra systemet. Dette vil dog afhænge af både virksomhedens lagermetode 2, og hvorledes IPO ere håndteres. Som tidligere nævnt er evt. IPO ere specificeret i værdiposterne, men kun hvis der er tale om direkte IPO ere, dvs. et IPO-tillæg, der er tillagt produktet direkte på varekortet. Evt. 1 Jf afsnit I Navision er det muligt at benytte følgende lagermetoder: FIFO, LIFO, Gennemsnit, Standard eller Specifik

28 IPO-tillæg på komponenter, maskine- og medarbejderressourcer opsummeres ikke på den producerede vare, og dermed heller ikke på evt. færdigvarer senere i produktionshierarkiet. Derudover skal man være opmærksom på at nogle råvarer og produkter kan have meget volatile købspriser. Man kan med rette stille spørgsmålstegn ved, om en Produkt-/Kundelønsomhedsanalyse skal påvirkes af sådanne prisudsving, der i princippet (ganske uberettiget) kan forringe/forbedre lønsomheden på specielt kundedimensionen alt afhængig af, hvor heldig kunden er med kostprisen på netop den vare, de har købt. Normalt vil en virksomhed tage højde for sådanne volatile priser ved at benytte GENNEMSNIT som lagermetode, og derved søge at udjævne sådanne store indkøbsprisforskelle. Men GENNEMSNIT er ingen garanti for at dette vil ske. Endelig skal der i ABC-modulet være mulighed for at tillægge kostværdien andre direkte omkostninger, f.eks. afskrivninger (se afsnit 6.3), hvis det ønskes. Denne mulighed findes ikke i dag. Med andre ord; Navisions vare- og værdiposter kan altså ikke fuldt ud håndtere og levere oplysninger om direkte omkostninger som krævet af et ABC-modul. LØNSOMHEDSANALYSE PÅ FAKTURANIVEAU Navision giver også mulighed for statistik på den enkelte fakturas avancebeløb og procent. Denne analyse benytter sig dog ikke af værdiposterne, men af kostoplysninger kopieret fra varekortet i det øjeblik en ordre oprettes 1 - oplysninger, der ikke opdateres yderligere. Det betyder, at der ikke beregnes samme avance på faktura og Kunde-/Varestatistikken nævnt i forrige afsnit. Et eksempel herpå er gengivet i Bilag B. Avancen for Ravel Møblers køb af 1 stk. ATHEN Skrivebord kan her sammenlignes med beløbet vist i Bilag A. DIMENSIONER I Navision er det muligt at benytte et uendeligt antal dimensioner med et tilhørende uendeligt antal dimensionværdier. Disse dimensioner gør det muligt at udarbejde eksempelvis afdelings- eller bilregnskaber uden at skulle udvide kontoplanen betragtelig, ved at forsyne hver enkelt finansposte- 1 Kostoplysninger, der opdateres løbende ifm. brugen af lagermodulet i Navision. Der er altså ikke tale om oplysinger, som evt. kunne benyttes i ABC-modulet, jf. forrige afsnit

29 ring 1 med en eller flere dimensionsværdier (dog kun én værdi for hver dimension). Nedenfor er i Figur 5-2 gengivet strukturen for dimensionen Marked brugt senere i Cronus A/S Casen (Se afsnit 7.2.) FIGUR 5-2. DEFINERING AF DIMENSIONER OG DIMENSIONSVÆRDIER I NAVISION Dimensioner giver mulighed for allerede i registreringsregnskabet at fordele beløb efter specifikke kriterier, både ifm. registrering af et bilag (f.eks. en omkostning) eller efterfølgende ved en fordeling af beløb mellem konti, dimensioner og dimensionsværdier. Som eksempel på sidstnævnte kan nævnes fordelingen af fællesomkostninger til virksomhedens afdelinger efter bestemte kriterier en fordelingsteknik, der oftest benyttes i de traditionelle afdelingsregnskaber. Ved brug af dimensioner er det altså muligt at sikre at registreringsregnskabet (finansbogholderiet) danner en fornuftig basis for ABC-regnskabet, både fsva. fordeling af omkostninger til ressourcekostpuljer, og fordeling af direkte omkostninger til kostobjekterne, hvor dette er muligt. Ved at bruge dimensionen REGION (jf. Figur 5-2) er det altså muligt allerede i registreringsregnskabet at få (direkte) omkostninger indplaceret direkte i kosthierarkiet. 1 Dimensioner kan ligeledes benyttes på eksempelvis debitor- og kreditorposter. På den måde begrænses antallet af debitorer, overblikket over debitor/kreditor (saldo, ordrebeholdning, etc.) øges, mens det samtidigt er muligt at holde styr på eksempelvis forskellige afdelinger eller profitcentres transaktioner med debitoren/kreditoren

30 Faktisk bør man tilstræbe at benytte dimensionerne mest muligt - brugen af ressourcekostdrivere til fordeling af indirekte omkostninger vil aldrig kunne have en ligeså høj grad af fordelingsmæssig nøjagtighed som en, om mulig, korrekt kontering i registreringsøjeblikket. Det skal understreges, at der i så fald skal være høj datadisciplin, da en detaljeret og nøjagtig registrering i nogle tilfælde og en lempeligere registrering i andre tilfælde, vil kunne underminere registreringsregnskabets værdi. Har man eksempelvis været pligtopfyldende med registrering af markedsføringsomkostninger til én kundegruppe, men udeladt denne dimension ved registreringer til andre grupper, står man efter at have fordelt de direkte omkostninger med en rest, hvis fordeling man da er nød til at foretage ved hjælp af de forskellige ABC-værktøjer og procedurer. Det vil kunne afstedkomme en for høj samlet fordeling til den pligtopfyldende gruppe, end til de resterende. Afslutningsvis skal det således også fremhæves at Navision ikke indeholder redskaber (eller for den sags skyld data) til nærmere analyse af de indirekte omkostninger. Undtagelsen er her opstilling af et artsopdelt afdelingsregnskab ved hjælp af dimensioner, som netop gennemgået 1. Figur 8-4 (p. 67) giver et eksempel på et sådan regnskab. 1 Det er dog ikke helt rigtigt. Rundt omkring i systemet kan findes data, der vedrører indirekte omkostninger, f.eks. registreres Opstillings-, Vente- og Transporttid på produktionsordrer. Men dette er i denne forbindelse virkelig i småtings-afdelingen

31 6. OMKOSTNINGSPULJER Ovenfor blev det i afsnit 4 beskrevet, hvorledes opbygningen af et ABC-system bør starte med identificeringen af aktiviteterne. I denne gennemgang er det dog valgt at starte med omkostningspuljerne, da det giver et mere ensrettet og trods alt logisk flow i gennemgangen. Nedenfor beskrives således først hvorledes realiserede omkostninger overføres og grupperes i ressourceomkostningspuljer (cost pools). Derudover diskuteres det, hvorledes omkostninger kan overføres direkte til aktiviteter/omkostningshierarkiet, ligesom en række mere teoretisk funderede overvejelser omkring fordelingen af omkostninger til ressourcekostpuljerne analyseres. Endelig vil afsnittet afslutningsvis gennemgå et eksempel på, hvorledes man i det udviklede ABCmodul kan definere og allokere omkostninger til ressourcekostpuljer pba. data i Navision OVERFØRSEL AF OMKOSTNINGER TIL RESSOURCEKOSTPULJER Som tidligere nævnt bør omkostningspuljer først defineres efter at de vigtigste aktiviteter i virksomheden er identificeret. Nedenstående Cronus Case 1 illustrerer ganske godt hvorfor. CRONUS CASE 1. SALGSASSISTENAFDELINGEN Salgsafdelingen i CRONUS A/S ledes af salgsdirektør Søren Christensen. Under sig har han i afdelingen 6 sælgere, der servicerer og opdriver kunder i hver deres geografiske distrikt. På lokationen i København sidder endvidere 3 salgsassistenter; Hanne Jensen, Katrine Holm Andersen og Henrik Bertelsen. Der er identificeret nedenstående 5 aktiviteter, som de 3 assistenter primært varetager. Derudover er der til hver aktivitet vist en beregnet standard tidsanvendelse for udførelse af aktiviteten: Oprettelse af nye debitorer, herunder evt. indhentning af fuldstændige fakturerings- og leveringsadresseoplysninger, kreditvurdering og fastlæggelse af kreditmaksimum efter virksomhedens retningslinier, samt indtastning af øvrige debitoroplysninger i virksomhedens Navision system. Tidsanvendelse: 2 timer/debitor

32 Ordremodtagelse og afsluttende fakturering. Virksomhedens lagerpersonale sørger for at salgsordrer leveres og evt. forsendelsesomkostninger påføres ordren. Herefter er ordren klar til fakturering. Tidsanvendelse: 0,25 time/ordrehoved, samt 0,05 time/ordrelinie. Reklamationer, herunder videresendelse til sagsbehandler (oftest sælgeren), udfærdigelse af evt. kreditnota, og lign. Tidsanvendelse: 2 timer/reklamation. Oprettelse, gennemgang, udstedelse og afsendelse af Rykkere, Rentenotaer og Kontoudtog. Herunder tilbageførsler af rykker og rentenotaer efter henvendelse fra kunder. Tidsanvendelse: 0,01 time/rykker, 0,01 time/rentenota, 0,005 time/kontoudtog. Kundeforespørgsler vedr. CRONUS A/S produktsortiment. Tidsanvendelse: 0,1 time pr. henvendelse, 0,2 time pr. henvendelse, der kræver forsendelse af materiale. Af Cronus Case 1 ses det, at det vil være en klar fordel, at etablere en ressourceomkostningspulje indeholdende de omkostninger, der kan henføres til salgsassistentafdelingen, da de aktiviteter der her udføres, er klart afgrænsede til denne afdeling. RESSOURCEOMKOSTNINGSKILDER Hvis man kigger på den grundlæggende ABC-model (jf. Figur 4-1), får man umiddelbart det indtryk, at allokeringen af ressourceomkostninger sker direkte fra eksempelvis finansregnskabet eller tilknyttede kartoteker, som eksempelvis Anlægskartoteket, Lønkartoteket, etc. Men dette er ingenlunde alene tilfældet. Omkostninger kan således allokeres fra følgende fem kilder : 1. Direkte fra finansbogholderiet og tilknyttede specificeringskartoteker. 2. En anden ressourcepulje. I det udviklede Navision ABC-modul skelnes der mellem sekundære og primære omkostningspuljer. Fra primære omkostningspuljer er det muligt at allokere omkostninger videre i systemet, dvs. til aktiviteter eller direkte til omkostningsobjekter. Fra sekundære omkostningspuljer kan der alene allokeres omkostninger til andre

33 omkostningspuljer ikke nødvendigvis primære 1. Eksempelvis kan det være en fordel at have en ressourceomkostningsgruppe til hjælp til opsamling af de kontorholdsomkostninger, der er påført hele virksomheden og/eller hele salgsafdelingen. Herfra kan så efterfølgende ske en yderligere fordeling til relevante puljer; f.eks. salgsassistentafdelingen. 3. En aktivitet. Det gælder specielt de aktiviteter som hjælpefunktionerne i virksomheden udfører. Et eksempel her kunne være aktiviteten ANSÆTTELSE AF EN NY MEDARBEJDER, som udføres af personaleafdelingen. Aktiviteten kan indeholde omkostninger til stillingsbeskrivelse og opstilling af ønsket ansøgerprofil, annoncering, bekræftelse på modtagelse af ansøgninger, første screening af ansøgninger, udsendelse af afslag, indkaldelse til første samtale, etc. Skal der ansættes en ny medarbejder i salgsafdelingen, vil det altså være muligt at allokere omkostningerne ved dette ressourcetræk til afdelingen. 4. Et kostobjekt. På samme vis kan omkostningerne til en omkostningspulje trækkes fra et omkostningsobjekt. 5. Manuel. Endelig skal det være muligt mere eller mindre manuelt at angive omkostninger til en ressourcepulje. Det kan gøre sig gældende i de tilfælde, hvor eksempelvis grunddatabasen ikke indeholder tilstrækkelig detaljerede data om de omkostninger, der ønskes allokeret til en ressourcepulje. Et eksempel her kunne netop være salgsafdelingen i Cronus A/S. Hvis Navision databasen ikke indeholder et lønkartotek med oplysninger om medarbejdernes bruttoløn, og finansbogholderiet ikke indeholder oplysninger om netop denne afdelings lønomkostninger, kan det blive nødvendigt at indtaste disse oplysninger manuelt. Der skal dog stadig være mulighed for at summere de indtastede data til efterfølgende sandsynliggørelse af ABC-modellens totale omkostninger ved eksempelvis at angive hvilken finanskonti, de indtastede omkostninger er bogført på i registreringsregnskabet. Med andre ord; ABC-modellens første trin er nu ikke længere så simpel. Med ovenstående følger at ABC-modellen i langt højere grad er et netværk af ressourcer, aktiviteter og omkostningsobjekter 2. Hvilket jo igen understreger vigtigheden af at udarbejde en procesbeskrivelse før man forsøger at opsætte sit ABC-system. 1 Bemærk at denne definition på primære og sekundære ressourcepuljer er teknisk funderet, dvs. med rod i, hvorledes systemet kan håndtere allokeringen. Lignende definitioner findes hos Kaplan & Cooper (1998, p ) og Bukh & Israelsen (2004). Disse har dog alle et strukturelt/organisatorisk udgangspunkt for klassificeringen af puljer (afdelinger). Resultatet skulle dog gerne blive det samme, da ABC-modulet til fulde understøtter sidstnævnte klassificering. 2 Svendsen og Christensen (2004)

34 Det skal nævnes, at det udviklede ABC-modul ikke medtager muligheden for at allokere omkostninger fra kosthierarkiet, se Figur 6-1. Ovenstående 5 omkostningskilder, koblet med de muligheder, der er for specificering og sporing af omkostninger i Navisions database giver ABC-system designeren næsten uanede muligheder manipulering, behandling og analyse af data. Blandt disse muligheder er faren ved at opsætte et system, der kommer til at køre i en uendelig løkke, dvs. omkostninger fordeles til en kostpulje, hvorfra omkostningerne fordeles til en anden pulje, for til sidst at blive fordelt til den første pulje igen. Det er ABC-systemdesignerens opgave at designe et system, hvor dette ikke finder sted. Figur 6-1 viser det netværk af ressourcepuljer, aktiviteter og allokeringsmuligheder, ABCprototypen dermed åbner op for. Fra Navisions grunddata kan omkostninger allokeres til sekundære og primære omkostningspuljer vha. såkaldte filtre. Filtre er begrænsninger i data fra et kartotek; som eksempel på et simpelt filter kan nævnes Kontonr. på kartoteket med finansposteringer. Ved at bruge et sådan filter kan omkostningerne registreret på et eller flere finanskonti summeres i en omkostningspulje. Et andet eksempel på et filter, er en eller flere dimensionsværdier, der sikrer at alene omkostninger registreret på et kontonr. og én eller flere specifikke afdelinger allokeres til puljen. Senere i dette afsnit vises et praktisk eksempel på brugen af sådanne filtre. Derudover er det muligt at fordele omkostninger til primære ressourcepuljer vha. ressourcekostdrivere; ANTAL ANSATTE, ANTAL ANSATTE M/PC, BENYTTEDE KVADRATMETRE, etc, er eksempler på sådanne ressourcekostdrivere. Hvis virksomhedens samlede omkostninger til kontormøbler skal fordeles til en afdeling (en primær kostpulje), syntes førstnævnte driver er være god. Har afdelingen 3 ansatte ud af i alt 60 ansatte i administrationen, vil altså 5% (3/60) af de samlede omkostninger til kontormøbler blive allokeret til afdelingen. Endelig er det muligt at allokere omkostninger til en ressourcepulje pba. specifikke aktivitetsomkostninger; et eksempel er her de omkostninger, der er forbundet med ansættelse af nye folk. Til Figur 6-1 skal det endvidere bemærkes, at det i ABC-prototypen ikke er muligt at allokere omkostninger fra sekundære til primære kostpuljer vha. af filtre. Skulle dette være muligt, skulle der således ikke bare beregnes ét omkostningsbeløb til en sekundær kostpulje, men ét beløb for hver af

35 de dimensionskombinationer, der efterfølgende skulle kunne sætte filter på! Det vil give en (alt for) stor mængde data i systemet. Navision Grunddata (Finans-, debitor-, kreditor-, vare-, anlægsposter, salgsfakturaer og -kreditnotaer, etc.) Filtre Filtre Filtre Sekundær omkostningspulje I Sekundær omkostningspulje II Sekundær omkostningspulje III Filtre Ressourceomk. driver Ressourceomk. driver Ressourceomk. driver Ressourceomk. driver Primær omkostningspulje I Ressourceomk. driver Primær omkostningspulje II Primær omkostningspulje III Ressourceomk. driver Aktivitet I Aktivitet II FIGUR 6-1. ALLOKERINGEN AF RESSOURCER TIL PRIMÆRE RESSOURCEKOSTPULJER I ABC PROTOTYPEN. Det er i forbindelse med allokeringen af omkostningerne til aktiviteterne kun være muligt at allokere omkostninger fra en primær omkostningspulje. Dette valg er foretaget for ikke øge kompleksiteten i løsningen unødigt og indføre unødvendige arbitrære fordelinger mellem puljerne

36 6.2. OVERFØRSEL AF DIREKTE OMKOSTINGER Direkte omkostninger kan groft deles i 3 grupper, alt efter hvorledes, de behandles i ABC-modulet. VAREKOSTPRISER Som det tidligere blev understreget vil der i nogle tilfælde kunne være betydelige problemer med at benytte de kostpriser, der er registreret på de enkelte salgsvareposter i Navision. I ABC-modulet er disse problemer forsøgt løst gennem indførelsen af en kostpristabel, se nedenfor. Tabellen kan udfyldes på 2 måder; enten (i) ved hjælp af en specialudviklet kørsel, der eksempelvis genbruger kostoplysninger fra varekortet, eller vare- og værdiposterne, eller (ii) ved manuel udfyldelse af tabellen. Derved sikres det, at virksomheder, der kan genbruge kostdata får denne mulighed, samtidig med at der også er mulighed for manuel oprettelse, sletning og justering af kostdata. I første omgang er det ikke så vigtig, hvorledes tabellen udfyldes (ABC-system designeren vil sikkert mene noget andet!), men mere at den er der og kan benyttes som beskrevet nedenfor. Selv om der her er tale om direkte omkostninger og det ikke fremgår af Figur 4-1, skal der dog defineres en ressourcekostpulje, hvortil alle de direkte produktionsomkostninger fra finansbogholderiet allokeres. Det er dog ikke det til puljen allokerede beløb, der allokeres videre i systemet til kostobjekterne. Disse beløb beregnes i stedet pba. af salgsvareposterne i Navision kombineret med varekostpristabellen resultatet af denne beregning placeres i en ABC-post, se Figur 6-2. Men ved at allokere de direkte produktomkostninger fra finansbogholderiet til en ressourcekostpulje, og knytte ovenstående ABC-poster til denne ressourcekostpulje, bliver det muligt dels (i) at foretage en afstemning af de kostpriser, der er indsat i varekostpristabellen med de i finansbogholderiet registrerede beløb, og (ii) få allokeret evt. difference (ikke-forbrugte ressourceomkostninger) til det virksomhedsbevarende niveau. På plussiden skal endvidere fremhæves, at metoden løser det før nævnte problem med volatile købspriser, da ensartede direkte kostværdier dermed sikres. Så selvom samme datastruktur benyttes til håndtering af disse direkte omkostninger, benyttes altså en speciel rutine til fordeling af ressourceomkostningerne

37 FIGUR 6-2. RELATIONERNE MELLEM VAREPOST-, VAREKOST- OG ABC-POSTTABELLERNE IKKE SPECIFICERBARE DIREKTE AKTIVITETSOMKOSTINGER Som det gennemgås mere detaljeret i afsnit 7.2, er det også muligt på den enkelte aktivitetskostdriver, at angive et beløb til (ellers ikke identificerbare) direkte omkostninger forbundet med aktiviteten. Der kan eksempelvis være tale om omkostninger til konvolutter og porto, eller til indhentning af kreditoplysninger på nye debitorer. Alle sammen oplysninger, det via registreringsregnskabet ikke er muligt at identificere på et specifikt og tilpas detaljeret kosthierarkiniveau. SPECIFICERBARE DIREKTE OMKOSTNINGER Andre direkte omkostninger skal enten kunne identificeres og beregnes automatisk af systemet, eller indtastes direkte af brugeren. Lad os først se på det mere tekniske aspekt i håndteringen af disse andre direkte omkostninger. I ABC-modulet er der lagt op til, at omkostningerne samles i en ressourcekostpulje. Puljen kan indeholde såvel direkte som indirekte omkostninger, dvs. omkostninger, der hhv. kan og ikke kan henføres direkte til et kostobjekt

38 Som det tidligere blev understreget bliver der pr. ressourcekostpulje alene beregnet ét samlet beløb. Med andre ord, er det ikke muligt at tage udgangspunkt i dette beløb, for at få identificeret evt. direkte omkostninger. I stedet må man (igen) trække disse direkte omkostninger fra kilden, dvs. primært fra finansbogholderiet, hvor disse oplysninger er gemt. Det kræver at ABC-system designeren konstruerer sin ABC-kalkule korrekt, dvs. trækker de samme omkostninger til ressourcekostpuljen, som til de direkte omkostninger hvis man vel og mærke ønsker at kunne afstemme disse oplysninger og opgøre omkostningerne ved ikke-forbrugt kapacitet. I afsnit 7.2. gennemgås, hvorledes ABC-modulet håndterer disse direkte omkostninger, men det er her værd at opsummere, at samtlige direkte og indirekte omkostninger skal allokeres til en ressourcekostpulje OVERVEJELSER VED FORDELINGER TIL RESSOURCEKOSTPULJER Afsnittet herover beskrev de tekniske muligheder ifm. allokering af omkostninger til ressourcekostpuljer. Nærværende afsnit beskriver nærmere, en række af de overvejelser og beslutninger ABC-system designeren bør gøre sig, inden ABC-kalkulationssystemet opsættes. AFSKRIVNINGER Afskrivninger på materielle som immaterielle aktiver (eller rettere forbruget af disse aktiver) frembyder (ligesom indenfor en række andre områder indenfor økonomistyringen), nogle specielle problemer, ABC-systemdesigneren skal forholde sig til. Specielt 2 forhold gør sig her gældende; omkostningernes fordeling og omkostningernes størrelse. For det første punkts vedkommende er fordelings problematikken ikke særegen for afskrivninger, men ligeledes for en række andre mere eller mindre faste omkostninger; husleje, elektricitet, varme, etc. Omkostningernes fordeling. Der kan identificeres i hvert fald 3 forskellige måder, hvorpå afskrivninger kan håndteres: 1 Fordeles ikke, dvs. betragtes som fællesomkostninger. I dette tilfælde vil sådanne omkostninger henføres til det virksomhedsbevarende niveau i produktkosthierarkiet, men kan i visse tilfælde også henføres til et lavere niveau. F.eks. hvis der er tale om afskrivninger på en maskine eller et udviklingsprojekt, der alene knytter sig til ét produkt eller produkter i én produktlinie. Argumentationen for denne tilgangsvinkel findes i, at omkostningerne jo

39 ikke falder bort ved afgang af en kunde eller et produkt det er derfor ikke en omkostning på enhedsniveau! Men samme argumentation vil man kunne bruge om f.eks. en salgsassistent, der (alt andet lige) ikke afskediges fordi en enkelt kunde eller produkt afvikles. Denne vil dog om muligt kunne sættes til andet arbejde (andre aktiviteter) det er svært med afskrivningerne/maskinerne. 2 Fordeling direkte til enhedsniveau. Denne metode synes umiddelbart ikke forenelig med ABC-tankegangen, da der lægges op til allokering via arbitrærer fordelingsnøgler til et (for) lavt niveau i kosthierarkiet. Men et vigtigt argument for denne praksis, opstår, hvis man forudsætter at en maskine kan producere et vist antal emner, eller benyttes et vist antal timer. Da vil der være raison i denne metode. Det betyder dog også, at man ikke her kan tale om omkostninger ved ikke-forbrugte ressourcer. Ikke forbrugte produktionstimer forventes som udgangspunkt benyttet i en senere periode. Det får med andre ord betydning for de samlede omkostningers størrelse, så afsnittet herunder. Derudover benyttes metoden ofte, hvis formålet med analysen er skaffe et omkostningsmæssigt udgangspunkt for prisfastsættelsen for eksempel også i situationer, hvor interne afregningspriser skal fastsættes. 3 Fordeling til sekundære og primære ressourcekostpuljer. Herfra allokeres omkostningerne til aktiviteter og kosthierarkier ved hjælp af de fordelingsprincipper der er gældende herfor. Omkostningerne vil herefter kunne ende på forskellige niveauer i kosthierarkiet, afhængig af den afdeling, der får allokeret omkostningerne, f.eks. vil omkostninger til direktionen ende på det virksomhedsbevarende niveau, mens omkostninger til produktionsafdelingen kan ende på enhedsniveauet. Det ses altså at valget af fordelingsmetode i høj grad afhænger af aktiverne (og omkostningernes) type og formålet med ABC-kalkulationen. Omkostningernes størrelse. Afskrivninger fastsættes iht. Årsregnskabslovens anvisninger, og er således ikke nødvendigvis det bedste udtryk for det ressourcetræk, der har været over perioden. Cooper og Kaplan 1 foreslår da også en alternativ metode, hvor omkostninger fordeles til enhedsniveauet udfra aktivets forventede kapacitet, og periodens forbrug heraf 2. Som det beskrives herun- 1 Kaplan & Cooper (1998). 2 Evt. finanseringsomkostninger behandles ikke i den traditionelle ABC-model, hvor der alene medtages omkostninger og indtægter før finansindtægter- og udgifter, samt skatter. Dette område er dog også under udvikling se eksempelvis Roztocki & Needy (200Xa), Roztocki (200Xb), samt Kaplan & Cooper (1998, s )

40 der, er det faktisk muligt at benytte Navisions funktionalitet omkring anlægsaktiver til håndtering af dette forhold. PERIODISERINGER Periodiseringen af almindelige driftsomkostningerne foretages jo normalt i finansbogholderiet. Så hvis finansbogholderiet benyttes som basis for allokeringen til sekundære og primære ressourcekostpuljer skulle der være taget højde herfor hvis man vel og mærke husker de rette dimensionsværdier ifm. periodiseringen. ABC-systemudvikleren skal endvidere være opmærksom på, at man i ABC-modulet registrerer ressourcetrækket ifm. gennemførelsen af aktiviteterne. Men aktiviteters effekt kan sagtens strække sig over flere perioder. Tag blot en aktivitet som opstilling af en maskine til produktion af en færdigvare. De produkter der bliver et resultat af produktionen kan blive afsat i en efterfølgende periode. Men omkostningen til Opstillingsaktiviteten fremkommer i nærværende periode i ABCregnskabet. I den lidt mere alvorlige ende kan nævnes tid og andre ressourcer forbrugt på udviklingen af et nyt produkt, eller en markedsføringskampagne. Det er ikke sikkert man i sine ABC-kalkuler ønsker at benytte samme regler for udgiftsførelse og aktivering som er gældende for det eksterne regnskab. Det gælder eksempelvis udgifter ifm. implementering af nye IT-systemer, forsknings- og udviklingsprojekter, etc. Navision indeholder muligheden for at knytte flere forskellige afskrivningsprofiler til et aktiv, hvoraf dog kun en af disse profiler kan integreres med finansbogholderiet, dvs. medfører posteringer i finansbogholderiet. Normalt vil man benytte en ekstra afskrivningsprofil til håndtering af de skattemæssige værdier og afskrivninger. Men det vil altså være muligt også at tilknytte en profil til håndtering af afskrivninger til brug for ABC-regnskabet, og lade ressourcekostpuljerne trække omkostningerne fra anlægskartoteksposterne i stedet for finansbogholderiet! Det skal bemærkes at ovenstående selvfølgelig giver nogle afstemningsmæssige problemer, ABCog det eksterne regnskab i mellem. Ganske vist lægger ABC ikke op til, at der skal kunne foretages deciderede afstemninger (heller ramme 80% rigtig end 100% forkert er en ofte benyttet linie fra ABC-bøgerne), men en eller anden form for sandsynliggørelse af ABC-kalkulens resultater, vil der altid skulle foretages, om ikke andet så for at teste validiteten af den opstillede ABC-kalkule

41 ALLOKERING AF OMKOSTINGER FRA AKTIVITETER TIL RESSOURCEKOSTPULJER I afsnit 6.1 blev det vist, hvorledes de omkostninger, der bliver opsamlet i en primær kostpulje, ud over andre sekundære ressourcekostpuljer, kunne stamme fra aktiviteter. Der blev her ligeledes givet et eksempel på det træk, der vil forekomme på HR-afdelingens ressourcer, og de deraf følgende omkostninger, der vil være forbundet med ansættelse af en ekstra/ny person i salgsassistentafdelingen. Hvis dette ressourcetræk beløber sig til kr ,- bør det så medføre at omkostningerne ved gennemførelse af de enkelte aktiviteter i salgsassistentafdelingen øges? Eller er disse kr ,- et udtryk for ekstraordinære omkostninger i afdelingen, som ikke kan fordeles fordi der netop ikke er tale om ekstraordinære omkostninger? Og hvis en fordeling foretages, er det så ikke bare et forsøg på at allokere omkostninger fra det virksomhedsbevarende niveau ned til lavere niveauer uden baggrund i nogen form for årsagssammenhæng? Der er ingen tvivl om at værdien af afdelingsregnskabet øges betragtelig, hvis allokeringen gennemføres. Udover det artsbaserede afdelingsregnskab fra finansbogholderiet (hvis der vel og mærke kan produceres et sådan), øges værdien ved at de omkostninger, der er forbundet med afdelingens træk på andre støtte-afdelingers ressourcer nu medtages. Ledelsen vil altså nu få et mere reelt billede af, hvad det koster at drive afdelingen. På samme vis ville afdelingen jo også blive allokeret forholdsvis flere omkostninger, hvis arbejdsklimaet i afdelingen var dårligt, med deraf følgende øget medarbejderomsætning. Med andre ord; et kontant signal om, hvad et dårligt arbejdsmiljø koster. Som argument for at omkostningerne ved ikke-udnyttede ressourcer som udgangspunkt ikke skal allokeres til aktiviteter og i sidste ende til produktlinie-, serie eller produktomkostninger, fremfører Kaplan & Cooper: 1 One can think about the assignment of unused capacity costs using the rational customer rule. This rule states that unused capacity costs should only be assigned to a customer if that customer, acting rationally under cost plus contract, would accept that cost. For example, a customer that orders on a predictable, regular basis, without making any changes, would not accept the costs of unused capacity. Nothing in the way the customer acts requires its supplier to maintain unused capacity. 1 Kaplan & Cooper (1998, p. 131)

42 Men Kaplan & Cooper 1 foreslår også at omkostningerne ved, hvad de kalder sekundære aktiviteter, altså aktiviteter udført af støttefunktionerne, allokeres til primære aktiviteter (ressourcepuljer): If operational and strategic ABM decrease the ressources required for primary activities, products, and customers, excess capacity wil be realized not only in the primary activities but also in the secondary activities that support them. Konklusionen må være, at hvis der er tale om omkostninger som er en naturlig del af den daglige drift af virksomheden, bør disse allokeres til primære ressourcekostpuljer. I tilfældet, hvor der er tale om en unormal høj medarbejderomsætning, er det tvivlsomt, om den rationelle kunde, derfor vil og skal betale herfor. Omkostningerne forbundet med dette overnormale træk på HRafdelingens ressource bør altså ikke allokeres videre til andre primære aktiviteter. De bør dog allokeres til den afdeling, der har forårsaget ressourcetrækket, og dermed vise, dels hvad støttefunktionen bruger sin tid og penge til, dels hvor store omkostninger, der har været forbundet med sådanne overnormale omkostninger. Herfra kan omkostningerne efterfølgende allokeres til det virksomhedsbevarende niveau. Der vil dog altid være tale om en ren subjektiv vurdering, hvorvidt omkostninger skal betragtes som overnormale. Ingen afdelingsleder ønsker sikkert sådanne påklæbet deres afdeling, da det jo er en problem-indikator. Det skal bemærkes at denne funktionalitet ikke er indarbejdet i ABC-prototypen. SEKUNDÆRE OMKOSTNINGER VIA AKTIVITETER ELLER RESSOURCEKOSTDRIVERE? Som det er fremgået er det muligt at fordele omkostninger fra sekundære ressourcekostpuljer enten (i) direkte til andre ressourcekostpuljer ved hjælp af ressourcekostdrivere eller (ii) via de aktiviteter den sekundære (støtte-)afdeling udfører, og herfra til andre afdelinger afhængig af disses træk på den sekundære afdelings ressourcer. Men hvilken allokeringsmetode skal ABC-systemdesigneren vælge? Hvis vi videre forfølger eksemplet med HR afdelingen i Cronus A/S, kunne man her vælge at fordele de til denne afdeling fordelte omkostninger, til de andre afdelinger efter det antal medarbejde- 1 Kaplan & Cooper (1998, p. 264)

43 re (ressourcekostdriveren), der er ansat i hver enkelt afdeling 1. En enkelt løsning, der dog som konsekvens har at HR-omkostningerne pr. medarbejder i en afdeling stiger og falder dels med udviklingen i HR-afdelingens generelle omkostningsniveau, dels med det samlede antal medarbejdere i virksomheden. Det er dog den metode mange virksomheder (uden et ABC-system) i dag fordeler omkostningerne fra støttefunktionerne på. Alternativt kan virksomheden forsøge at allokere HR-omkostingerne til de enkelte afdelinger, afhængig af deres træk på HR-afdelingens ressourcer. For det første kræver dette, at der er foretaget en identificering og kvantificering af aktiviteterne i HR-afdelingen og en registrering af aktivitetstrækket (faktisk i alle støtteafdelingerne/-funktionerne i virksomheden). Specielt i forbindelse med pilotprojekter og gennemførelsen af de første ABCkalkulationer i en virksomhed, er denne forudsætning ikke nødvendigvis opfyldt. Derudover vil en ressourcekostpulje kunne blive påvirket af svingende forbrug. Et eksempel herpå er kontormøbler. Hvis der til en afdeling alene hjemkøbes kontormøbler én gang hver 5. år, vil afdelingsregnskabet dette år blive kraftig påvirket. Ved at fordele virksomhedens totale årlige omkostninger til kontormøbler på samtlige medarbejdere i administrationen vil disse svingende omkostninger udjævnes. Et sidste alternativ, er benyttelse af anlægsmodulet i Navision som beskrevet i forrige afsnit. Men med allokering via aktiviteter sker der en mere nøjagtig fordeling af omkostningerne til de afdelinger, der rent faktisk trækker på HR-afdelingens ressourcer det er jo trods alt hele idéen med ABC-tankegangen. Derudover vil, som nævnt i forrige afsnit, en allokering via aktiviteter medføre, at eventuelle tiltag rettet mod et mindsket træk på HR-afdelingens ressourcer afspejle sig i den primære afdelings samlede omkostninger, og dermed faktorprisen for deres ydelser/aktiviteter. Disse tiltag kunne bestå i selv at gennemføre eller outsource aktiviteterne, eller tiltag, der (specifikt i henhold til det behandlede eksempel) mindsker medarbejderomsætningshastigheden i afdelingen. 1 Der er i praksis tale om at få fastsat en intern afregningspris, for hvilket der findes utallige modeller og muligheder. Man kunne således også tænke sig, at HR-omkostningerne på den ene eller den anden måde blev sat til et bestemt beløb pr. medarbejder. HR-afdelingen havde da ansvaret for at holde sig indenfor dette budget. For en yderligere diskussion af interne afregningspriser, se Nørreklit (1999), samt ikke mindst Kaplan, Weiss & Desheh (1997), der beskriver en interessant ABC-baseret model for fastlæggelse af interne afregningspriser

44 Med andre ord; allokering via aktiviteter skaber en mere direkte sammenhæng mellem indsats og omkostninger. Nedenfor forfølges Cronus Casen videre mht. allokering af omkostninger til afdelingen. CRONUS CASE 2. ALLOKERING AF RESSOURCEOMKOSTNINGER TIL SALGSASSISTENT- AFDELINGEN Som tidligere nævnt, vil det være en fordel at definere en (primær) ressourcekostpulje kaldet Salgsassistentafdelingen. Til denne pulje allokeres omkostninger direkte og indirekte via sekundære ressourcekostpuljer fra Navisions grunddata, som vist i nedenstående Figur 6-3. Omkostninger allokeres til Salgsassistenafdelingen fra 4 kilder: 1 1 Kontoromkostninger (fysiske). Her opsamles alle de omkostninger, der kan henføres til de fysiske lokaliteter; husleje (afskrivning på grunde og bygninger), rengøring, el og varme, reparation og vedligehold, etc. 2 Administrationsomkostninger. Dækker over omkostninger til kontorhold, telefon og fax, samt porto. 3 IT-omkostninger. ABC-systemdesigneren har besluttet af omkostningerne til støttefunktionen IT, skal fordeles mellem de andre afdelinger, uagtet forskelle mellem de forskellige afdelingers træk på IT-afdelingens ressourcer. Det skyldes at man i Cronus A/S i første omgang ikke er interesseret i, hvem der trækker på de forskellige IT-ressourcer, og hvor meget. Man mener, at uagtet hvem der foretager ressourcetrækket, bør omkostningerne fordeles ligeligt, da der jo er tale om et beredskab alle kan trække på. Som sådan burde omkostningerne måske kategoriseres som en fællesomkostning, men da allokeringen omkostningerne varierer med antallet af medarbejdere med PC er i afdelingen, er det valgt at fordele omkostningerne over de primære afdelinger. Et alternativt hertil ville være at samle de omkostninger, der kan allokeres til IT-afdelingen i en ressourcekostpulje, og fordele disse på de aktiviteter, afdelingen er involveret i, og herefter fordele disse aktivitetsomkostninger til de forskellige afdelinger i Cronus efter netop deres træk på ressourcerne i IT-afdelingen. I begge tilfælde skal man huske på, at IT afdelingen først skal have allokeret deres del af administrations- og de fysiske kontoromkostninger før en fordeling til salgsassistentafdelingen kan finde sted det fremgår ikke af Figur Der er alene tale om et eksempel til illustration af ABC systematikken og -modulet. I virkeligheden ville der helt sikkert være tale om langt flere ressourcekostkilder

45 4 Lønomkostninger. Navision databasen indeholder alene oplysninger om lønomkostningerne på afdelingsniveau (dvs. for salgsafdelingen), hvorfor det er nødvendigt, manuelt at indtaste de for salgsassistentafdelingen gældende løndata. Navision Samlede kontoromkostninger (fysiske) CRONUS A/S København Samlede administrationsomkostninger CRONUS A/S København Samlede IT-omkostninger CRONUS A/S København Ressourcedriver: kvadratmeter Lønomkostninger (manuelt) Ressourcedriver: antal ansatte Ressourcedriver: antal ansatte m/ PC arbejdsplads Omkostningspulje, Salgsassistenter, CRONUS A/S København FIGUR 6-3. ALLOKERING AF RESSOURCEOMKOSTNINGER TIL SALGSASSISTENTAFDELINGEN (STRUKTUR)

46 Nedenstående Figur 6-4 viser dels ressourcekostpulje-kortet for Salgsassistentafdelingen (oplysningerne herpå gennemgås mere detaljeret senere), dels hvorledes de samlede ressourceomkostninger er allokeret fra forskellige kilder. Det skal bemærkes, at der i dette tilfælde alene benyttes manuelle ressourcekostdrivere, dvs. drivere hvor både det totale fordelingsgrundlag (KOSTDRIVER ANTAL) og grundlaget for salgsassistentafdelingen (PULJE ANTAL) indtastes og vedligeholdes af brugeren. FIGUR 6-4. ALLOKERINGEN AF OMKOSTNINGER TIL SALGSASSISTENTAFDELINGEN (ABC-MODULET)

47 Nedenfor vises i Figur 6-5 opsætningen af ressourcekostpuljen Kontoromkostninger, herunder brugen af et simpelt filter til brug for beregningen. FIGUR 6-5. BRUG AF FILTRE VED OPSÆTNING AF RESSOURCEKOSTPULJER

48 7. AKTIVITETER I første trin blev ressourceomkostningerne fordelt på de primære ressourcekostpuljer. Nu skal fordelingen ske videre til aktiviteter og kostobjekter så (i) de samlede omkostninger ved gennemførelse af aktiviteterne kan beregnes, og (ii) omkostningerne for de enkelte kostobjekter og på de enkelte hierarkiniveauer kan bestemmes. Som tidligere bemærket foretages disse to beregninger dog på baggrund af data fra samme kartoteket (ABC-posten), som en summation af beløbsfelterne på disse poster indenfor forskellige afgrænsninger. Alt dette bliver dog gennemgået senere i dette afsnit AKTIVITETSBIBLIOTEK Samtlige aktiviteter samles og listes normalt i et såkaldt Aktivitetsbibliotek. Her er det muligt nærmere at beskrive den enkelte aktivitet og knytte den med aktivitetskostdrivere, kosthierarkiet og ressourcekostpuljer. Sammenhængen forklares bedst ved at kigge på Figur 7-1, der viser et par skærmbilleder fra ABC-modulet. For fuld forståelse af figuren skal det bemærkes, at Navision sletter fuldt leverede og fakturerede ordrer, hvorfor data om netop ordrer må hentes fra de bogførte fakturaer, med de problemer det afstedkommer. En aktivitet kan alene trække ressourcer fra én ressourcekostpulje. Ellers skulle det også være muligt at definere hvorfra og efter hvilken fordeling, der skulle trækkes fra den en eller den anden pulje sikkert efter en mere eller mindre arbitrær fordelingsnøgle. I Cronus casen ville en sådan situation opstå, hvis en person fra en anden afdeling (Ressourcekostpulje) hjalp med eksempelvis oprettelse af ordrer og fakturering: Hvis det er muligt at identificere, hvilke ordrer og fakturaer, denne 4. person har arbejdet med, er der intet problem. Begge afdelinger får tilknyttet en aktivitet der hedder ORDREMODTAGELSE OG AFSLUTTENDE FAKTURERING og ved hjælp af filtre afgrænses ordrer/fakturaer til de ordrer/fakturaer, der er behandlet af de respektive afdelinger. Der overføres et beløb og et antal timer (se senere) svarende til det estimere forbrug fra den ene ressourcekostpulje til den anden 1. Samle de 2 ressourcekostpuljer til én. Men dette er nok den mindst brugbare løsning. 1 Det giver et lidt teknisk/praktisk problem, da det tidligere blev understreget, at der alene kan allokeres omkostninger fra en primær kostpulje til aktiviteter og at en primær kostpulje, netop er defineret ved, at der ikke allokeres beløb til andre ressourcekostpuljer. I praksis ville man kunne løse dette problem ved først at oprette den anden afdeling som en sekundær kostpulje, og overføre omkostninger herfra dels til Salgsassistentafdelingen, dels til en ny primær ressourcekostpulje for den anden afdeling

49 FIGUR 7-1. SAMMENHÆNGET MELLEM AKTIVITETER OG AKTIVITETSKOSTDRIVERE I ABC-MODULET 7.2. AKTIVITETSKOSTDRIVERE Fordelingen af omkostninger fra ressourcekostpuljerne til aktiviteter og kostobjekter kræver brugen af fordelingsnøgler indenfor ABC kaldet aktivitetskostdrivere. Med inspiration fra Kaplan & Anderson 1, er ABC-prototypen konstrueret på en sådan måde, at en aktivitet kan have flere aktivitetskostdrivere, f.eks. indeholder aktiviteten ORDREMODTAGELSE OG AFSLUTTENDE FAKTURERING fra Cronus casen 2 drivere; ANTAL SALGSORDREHOVEDER og ANTAL SALGSORDRELINIER. Sammen bestemmer de omkostningen ved aktiviteten. 1 Se Kaplan & Anderson (2003) for en nærmere gennemgang af, hvad de kalder Time-Driven Activity Based Costing

50 Denne struktur muliggør også differentierede aktivitetskostdrivere. Hvis eksempelvis aktiviteten ORDREMODTAGELSE OG AFSLUTTENDE FAKTURERING er speciel tidskrævende for en bestemt kundegruppe, eller hvis nogle specielle produkter pr. tradition viser sig at tage længere tid at ordrebehandle, så er der mulighed for at oprette flere aktivitetskostdrivere til håndtering af disse forskelle. Rent teknisk beskrives forskellen ved hjælp af filtre (som det kendes fra allokering af omkostninger til ressourcekostpuljerne) på den tabel, hvorpå beregningen skal foretages. DRIVERTYPER Der findes i princippet 3 kostdrivertyper: 1. Transaktionsdriver. Ved hjælp af transaktionsdrivere fordeles omkostningerne efter det antal gange, en bestemt aktivitet udføres. Det klassiske eksempel er her transaktionsdriveren Antal salgsordrelinier, hvor omkostningen for behandlingen af én salgsordre opgøres som aktivitetsdriveromkostninger gange med antallet af linier på salgsordren. Antal opstillinger for en maskine er et andet eksempel på en transaktionsdriver. Der fordeles altså en omkostningsmæssigt beløb for hver opstilling, der foretages på maskinen. Under normale omstændigheder vil man i sidstnævnte eksempel dog brugen en anden driver en driver, der tager hensyn til, at opstillingstiden kan være forskellig fra produkt til produkt: 2. Varighedsdriver. Hvis gennemførelsen af en aktivitet varierer med det tidsforbrug der er forbundet med udførelsen af aktiviteten (og altså ikke alene det antal gange aktiviteten udføres), kan en varighedsdriver med fordel benyttes. Som nævnt ovenfor, er opstillingen af en maskine et glimrende eksempel herpå, da opstillingstiden ofte vil variere fra produkt til produkt. Man skal her huske på at der dog ikke er tale om at der i forbindelse med hver opstilling af maskinen skal ske en måling af tidsforbruget, men alene at der for hver produkt fastlægges én opstillingstid som bestemmer faktortrækket pr. gennemførelse af aktiviteten. Foretages der direkte måling ved hver opstilling, benyttes den sidste driver: 3. Direkte måling. Her bestemmes faktorforbruget pba. af en direkte måling heraf. Måles (og registreres) eksempelvis tiden forbrugt på opstilling ifm. hver enkelt produktion, vil denne måling direkte kunne benyttes til fastlæggelse af omkostningen ved aktiviteten. Denne driver er dog oftest den mindst benyttede, da driveren netop kræver direkte registrering af tidsforbruget (eller et andet faktorforbrug). Valget af aktiviteteskostdriver og -type skal ske som en afvejning af de omkostninger og den værdi brugen af den enkelte driver indebærer, primært pba. driverens større nøjagtighed. Omkostningerne indbefatter faktor/tidsforbruget ved måling og registrering af data, men også ifm. tilvejebringelse

51 og brug af data ifm. opstilling af ABC-systemet. Selvom data kan registreres i Navision, er det ikke sikkert de direkte er anvendelige i ABC-modulet uden omfattende opsætning eller tilretninger til systemet. TIDSREGNSKAB OG IKKE-SEPCIFICERBARE DIREKTE OMKOSTNINGER Kaplan & Cooper 1 viser hvorledes man ved at estimere et tidsforbrug for gennemførelsen af en aktivitet, hurtigt og effektivt kan vedligeholde de forskellige aktivitetskostdriveromkostninger ved også at estimere den praktiske kapacitet 2 udtrykt i tid (timer) for hver ressourcekostpulje. De realiserede omkostninger allokeres herefter til aktiviteterne efter deres estimerede tidsforbrug ift. ressourcekostpuljens praktiske kapacitet 3. Metoden er en praktisk konstatering af, at det er tidsforbruget, og ikke omkostningerne ifm. gennemførelse af en aktivitet, der (alt andet lige) bør være konstant over tid. Metoden medfører en række fordele ifm. vedligeholdelsen af ABC-systemet: Forøges eller mindskes ressourcepuljens samlede omkostninger isoleret set (f.eks. stigende lønninger), medfører det automatisk en forøgelse af aktivitetsdriveromkostningerne; f.eks. omkostningerne ved at oprette en ny kunde. Effektiviseres aktiviteterne så det medfører et lavere estimeret tidsforbrug for én eller flere af aktiviteterne, rettes den estimerede tid på kostdriveren tilknyttet den specifikke aktivitet med en lavere (og automatisk beregnet) aktivitetsomkostning til følge. Øges timekapaciteten i ressourcekostpuljen isoleret set, falder omkostningerne pr. time, og medfører (automatisk beregnede) faldende omkostninger for alle aktiviteterne. Problemet med denne metode opstår, hvis der indgår andre produktionsfaktorer end tid. Her tænkes primært på direkte variable, men ikke-specificerbare omkostninger. Et eksempel herpå er de omkostninger til konvolutter og porto, der er forbundet med udsendelse af rykkere, rentenotaer og kontoudtog til kunderne. Eller de omkostninger, der er forbundet med at indhente kreditoplysninger om nye kunder. Disse omkostninger er formentlig ikke bogført i registreringsregnskabet på en så- 1 Kaplan & Cooper (1998, kapitel 14), samt Kaplan (200X). 2 Kaplen & Cooper (1998) argumenterer ligeledes for, at det den praktiske kapacitet, der skal benyttes til denne beregning ikke den maksimale, normale eller den budgetterede. 3 Et tidsforbrug, der ikke (selv om Kaplan og Cooper kalder det således) er en varigheds- men en transaktionsdriver. Driveren er beregnet på baggrund af et estimeret tidsforbrug, men dette forbrug er det samme for gennemførelse af aktiviteten uagtet evt. karakteristika ved den driver, der trækker omkostningerne

52 dan måde, at en forbindelse mellem omkostningerne og de specifikke kunder kan identificeres, og vil derfor blive opsamlet i salgsassistent-ressourcekostpuljen, påvirke omkostningen pr. time og dermed fordeles til samtlige aktiviteter, der trækker på salgsassistent-ressourcekostpuljen. Det på trods af, at der jo er tale om direkte, variable omkostninger. Samtidig vil selve tidsestimatet for gennemførelse af nævnte aktiviteter, skulle forøges, så de beregnede omkostninger tager højde for såvel tidsforbruget som de direkte omkostninger (frimærkeforbruget), og det vil medføre misvisende tidsangivelser på de enkelte aktivitetskostdrivere, samt ifm. bestemmelsen af den praktiske kapacitet. Problemet er her, at ABC ikke indeholder et produktionsfaktorregnskab for produktionsfaktoren TID 1. Dette er derfor søgt indført i ABC-modulet ved dels (i) at give mulighed for at definere disse direkte ikke-specificerbare omkostninger på aktivitetsdriver-kortet, og (ii) at beregne både de beløbs- og tidsmæssige kapaciteter og forbrug. Som det er fremgået af tidligere figurer med skærmbilleder fra ABC-modulet (se også Figur 7-3), indeholder ressourcekostpulje-kortet oplysninger om den praktiske tidsmæssige kapacitet i puljen. Samtidig indeholder de forskellige aktivitetskostdrivere, der er tilknyttet de aktiviteter, der trækker på ressourcekostpuljens ressourcer, ligeledes oplysninger om det forbrugte timeantal. Når aktivitetsomkostningerne skal kalkuleres, summeres på ressourcekostpulje-niveau først de direkte omkostninger, som fradrages de realiserede omkostninger, hvorefter en pris pr. tidsenhed kan beregnes. ABC-post tabellen opdateres herefter med denne timepris, hvorefter aktivitetsomkostningerne endeligt kan beregnes. Ovenstående har medført en udvidelse af tabelstrukturen i ABC-posten i forhold til det i afsnit 4.2. præsenterede. Bilag E gennemgår de enkelte felter i denne tabel mere detaljeret. Det er dog vigtigt at forstå, at man ved hjælp af disse ABC-poster kan beregne de totale omkostninger, indtægter og timeforbrug på 3 niveauer; ressourcepulje, aktivitets- og aktivitetsdriverniveau, foruden de muligheder der er for beregninger på de forskellige kunde- og produkthierarkiniveauer. Alle disse oplysninger indgår som felter i tabelstrukturen og dermed som dimensioner i matrixen. 1 Det er tidligere fremhævet at ABC mere er en tankegang og et sæt værktøjer, hvorfor det er forkert at skrive at ABC ikke indeholder et produktionsfaktorregnskab. Men denne opgaves forfatter er ikke i sin litteratursøgning stødt på et sådan eksplicit Tidsfaktorregnskab i en ABC-kalkule

53 ABC-posterne er grundlaget for alle disse beregninger. Det betyder også at man ved evt. indlæsning af data til ABC-systemet (f.eks. i de tilfælde, hvor man har registreret kunde forespørgsler i et regneark og ikke ønsker at taste dem igen), alene skal benytte én struktur ved indlæsning af data i Navision. Endvidere betyder det, at det også er muligt i ét og det samme skærmbillede at indtaste nye ABCposter, i de tilfælde hvor data skal angives manuelt. I forlængelse heraf, er det selvfølgelig også muligt at redigere allerede indtastede, indlæste og beregnede data 1. Ovenstående gennemgang af anvendelsen af tidsfaktoren i ABC, danner grundlag for den måde, hvorpå ABC-modulet beregner aktivitetsomkostningerne for hver enkelt aktivitet afhængig af aktivitetskostdrivertypen: Transaktionsdriver. Aktivitetsomkostninger 1 Antalposter ( ADOT Antal TA F ) ( DO Antal) ADOT = AktivitetsDriverOmkostinger pr. Time. Beregnes automatisk pba. af de timer der er til rådighed for den pågældende ressourcekostpulje, samt puljens samlede realiserede omkostninger med fradrag for puljens samlede direkte omkostninger Antal = Antal poster i den gennemløbede tabel (f.eks. salgsordrelinier), dvs. antal gange aktiviteten udføres. TA F = Tidsforbrug for aktiviteten. Er Fast for hver enkelt gennemførelse af aktiviteten og angivet på Aktivitetskostdriver-kortet. DO = Direkte omkostninger ved gennemførelse af aktiviteten. Angives på Aktivitetskostdriverkortet. 1 Det er måske mere korrekt at skrive teknisk muligt at redigere., da der selvfølgelig kan indlægges forskellige spærringer og godkendelsesprocedurer for manuel manipulering med data i systemet

54 Varighed Aktivitetsomkostninger 1 Antalposter ( ADOT Antal TA V ) ( DO Antal) TA V = Tidsforbrug for aktiviteten. Er Variabel for hver enkelte kosttype/hierarkiniveau, f.eks. kunde- eller varenr. Findes ved opslag i en tabel i Navision, f.eks. er det forventede tidsforbrug ifm. opstillingen af en maskine til produktion af en færdigvare, i Navision angivet på Rutekortet. Direkte måling (tid): Aktivitetsomkostninger 1 Antalposter ( ADOT TA S ) ( DO Antal) TA S = Tidsforbrug for aktiviteten. Er resultatet af en Summation på et tids-felt i en given tabel i Navision. F.eks. er (kan!) alle realiserede opstillingstider på maskiner registreres på produktionsordrerne i systemet. Direkte måling (beløb) (se næste afsnit): Aktivitetsomkostninger 1 Antalposter ( DOMK S ) ( DO Antal) DOMK S = Direkte omkostning for aktiviteten. Er resultatet af en Summation på et beløbs-felt i en given tabel i Navision. F.eks. indeholder alle udstedte rykkere oplysninger om bilagets opkrævningsbeløb (rykkergebyr). For hver drivertype gælder det, at aktivitetsomkostningerne beregnes for hver kombination af det produkt- og kundehierarkiniveau aktiviteten er tilknyttet, f.eks. kundenr. og varenr. Det ses endvidere, at varighedsdriveren er unik i og med, at der her for at kunne beregne aktivitetsomkostningerne, skal ske læsning i 2 Navision kartoteker; dels et kartotek, hvor Antal sammentælles, dels et opslag i et andet kartotek, hvor tidsforbruget for den aktuelle aktivitet (TA v ) aflæses

55 DIREKTE OMKOSTNINGER OG INDTÆGTER Det skal bemærkes, at det i ABC-modulet er muligt at vælge mellem 4 forskellige drivertyper ud over de 3 præsenteret tidligere, kan man ligeledes vælge DIREKTE MÅLING (BELØB). Drivertypen DIREKTE MÅLING (TID) summere indholdet af et givet tids-felt i en filtreret tabel og ganger denne med en KOST PR. TIME. Det vil derfor ikke være særlig problematisk fra en modul-udviklers synsvinkel at summere indholdet af et beløbsfelt i stedet. At der er valgt at definere endnu en drivertype skyldes udelukkende at den datamæssige behandling af de to typer (tid og beløb) adskiller sig fra hinanden. Tidsfaktorfelterne på ABC-posten skal således ikke benyttes ifm. sidstnævnte. Det ses endvidere af aktivitetsdriverkortet, at det er muligt (for drivertypen DIREKTE MÅLING (BELØB)), at få de summerede beløb registrerede som en indtægt i stedet for en omkostning. Et eksempel er her de gebyrer og renteindtægter, der er afledt af udstedelsen af rykkere og rentenotaer. Det er i Navision muligt via en række forskellige kartoteker, at identificere disse indtægter. Indtægterne skal i dette tilfælde registreres på Kunde-niveau under kostobjektet Kunde. Sådanne direkte omkostninger og indtægter vil for Enheds-, Serie- og Produktniveauet, samt Enheds-, Ordre- og Kundeniveauet kunne identificeres ved hjælp af hhv. vare- og kundenr. på den record, hvorfra omkostnings-/indtægtsdata hentes. Som vi så tidligere er begge disse oplysninger registrerede på en salgsvarepost, ligesom eksempelvis Kundenr. er registreret på en rykker (sammen med oplysningerne om et eventuelt rykkergebyr), og finansposter kan have oplysninger om den debitor, der har givet anledning til posteringen. Men hvorledes identificeres direkte omkostninger på Regions-, Markeds-, Produktlinie- og Virksomhedsbevarende niveau? ABC-modulet gør her brug af DIMENSIONER til håndtering af automatisk identifikation af sådanne direkte omkostninger. Man kunne også tænke sig at Bogføringsgrupper, Sælgerkode, Distriktskoder blev benyttet hertil, men DIMENSIONER er langt mere fleksibelt 1. 1 Det er også betydelig lettere for en udvikler kun at skulle benytte DIMENSION, ligesom DIMENSIONER benyttes ifm. flere kartoteker end de andre nævnte felter

56 FIGUR 7-2. OPSÆTNING AF KOSTHIERARKIER I ABC-MODULET Det blev tidligere vist (Figur 5-2), hvorledes MARKED blev defineret som en dimension ved hjælp af Navisions standard funktionalitet, og hvorledes dimensionsværdier blev opsat hertil. Ved at tilknytte denne dimension til et specifikt kostobjekt (Se Figur 7-2), bliver det altså muligt at få disse direkte omkostninger/beløb identificeret og registreret som en ABC-post med de rette karakteristika. Hver enkelt debitor kan ligeledes tilknyttes en af de dimensionsværdier, der er gældende for dimensionen Marked, for dermed at knytte kunden til en region. Skulle Kundenr. og en dimensionsværdi for MARKED begge være givet på én og samme post, allokeres omkostningen selvfølgelig til kunden, da denne befinder sig lavest i hierarkiet. Den eneste form for direkte omkostning, vi så mangler at behandle, er omkostninger man ønsker allokeret direkte til en kunde. Det kan her blive nødvendigt manuelt at indlægge poster på ressourcekostpuljen og ABC-post kartoteket til håndtering af disse. Dimensionen MARKED er endvidere defineret med en værdi kaldet 999 Direkte (Kunde), som kan bruges ved registrering af omkostninger, som man positivt ved skal allokeres en kunde. Men det er stadig op til ABCsystemdesigneren at håndtere allokeringen i ABC-modulet manuelt! 1 1 Et andet alternativ ville være at oprette en dimensionsværdi for hver kunde denne løsning synes dog ikke særlig operationel

57 Men generelt må man sige, at man altså ved brug af Navision standard Dimensions funktionalitet kan knytte Kunde- og Varenumre til det overliggende hierarkiniveau, samt få mulighed for at registrere og senere igen identificere direkte omkostninger på alle hierarkiniveauer OMKOSTNINGER VED IKKE-FORBRUGTE RESSOURCER Omkostninger ved ikke-forbrugte ressourcer er et meget vigtigt element i ABC 1. Man bør huske på, at de omkostninger, der er fordelt til ressourcekostpuljerne er kapacitetsomkostninger, dvs. omkostninger forbundet med at stille et ressourceberedskab til rådighed for virksomheden, og som virksomheden kan udnytte eller lade være. Kaplan og Cooper 2 argumenterer for at omkostningerne ved ikke-forbrugt kapacitet skal fordeles til det virksomhedsbevarende niveau altså ikke på produkterne eller andre højere niveauer. Dette dels fordi kunderne ikke forventes at ville acceptere sådanne omkostninger (jf. det tidligere citat fra Kaplan & Cooper, side 41), dels for at modvirke en spiralvirkning, hvor omkostninger til ikke forbrugte ressourcer fordeles på produktniveau, og derved giver højere produktomkostninger med fare for højere produktpriser. Derudover er det selvfølgelig vigtigt, at omkostningerne ligeledes kan identificeres på ressourcekostpulje-niveau, så man fra ledelsens side ved, hvor de ledige ressourcer befinder sig. CRONUS CASE 3. ABC-OMKOSTNINGER OG INDTÆGTER I SALGSASSISTENTAFDELINGEN Som beskrevet tidligere indeholder aktiviteten DEBITOR ADMINISTRATION udstedelse og fremsendelse af rykkere, rentenotaer og kontoudtog. Til de 2 førstnævnte har man i Cronus A/S ønsket ligeledes at få registreret de gebyr- og renteindtægter, der er forbundet med aktiviteterne. Figur 7-3 viser nederst de 5 aktivitetskostdrivere, det er nødvendigt at oprette for at håndtere de indtægter og omkostninger, der er forbundet med debitoradministration i Salgsassistentafdelingen. Samtidig viser figuren et eksempel på et aktivitetsdriverkort, hvor de netop gennemgåede felter og oplysninger alle fremgår. 1 Faktisk skriver Kaplan og Cooper (1998, p.111) at Measuring, creating, and managing unused capacity are the heart of activity-based costing. One can view the entire ABC approach as giving managers insights about the existence, creation, and deployment af capacity, both used and unused. 2 Kaplan & Cooper (1998)

58 FIGUR 7-3. AKTIVITETSKOSTDRIVERE IFM. DEBITORADMINISTRATIONEN I SALGSASSISTENTAFDELINGEN Når ABC-kalkulen er opsat, gennemføres beregningskørslen, dvs. den kørsel, der blandt meget andet beregner ressourcekostpuljeomkostningerne, omkostningerne pr. time og aktivitet (jf. figuren ovenfor), og ikke mindst ABC-posterne 1. Som tidligere omtalt er et af de primære formål med hele ABC-kalkulen netop at få oprettet disse ABC-poster, på basis af hvilke man kan (i) opstille Indtægts- og omkostningsmatrixen til brug for ABC produkt/-kundelønsomhedsanalysen (jf. Figur 4-3), (ii) beregne forbrugt tid, time- og direkte omkostninger på aktivitets- og ressourcepuljeniveau, og dermed ikke-forbrugte ressourcer ligeledes på ressourcepuljeniveau. 1 Selvom det her betegnes som én kørsel, vil beregningerne med fordel kunne gennemføres af flere omgange, for på den måde at lette afstemning/sandsynliggørelse af beregningernes validitet. Man må ligeledes påregne, at beregningerne tager lang tid at gennemføre, hvilket yderligere taler for en opdelt beregningskørsel

59 Figur 7-3 herunder viser et udsnit af de ABC-poster, der genereres til del-aktiviteten Opret rykkere. Der henvises til Bilag E for en nærmere gennemgang af ABC-post felternes indhold. Oplysningerne i højre side af Aktivitetsdriverkortet er summationer af de tilsvarende felter i ABC-posterne. FIGUR 7-4. ABC-POSTER TIL DEL-AKTIVITETEN 'OPRET RYKKERE' I SALGSASSISTENAFDELINGEN

60 8. ABC I NAVISION - MULIGHEDER OG BEGRÆNSNINGER 8.1. KUNDE- OG PRODUKTLØNSOMHEDSANALYSE VED HJÆLP AF ABC Først skal det nævnes, at man under normale omstændigheder formentlig ikke vil benytte Navision til analyse af ABC-posterne, men i stedet gøre brug af et Business Intelligence (BI) værktøj. Fordelen herved er at et sådan program er designet til dels (i) at behandle meget store datamængder, og (ii) give brugeren et sæt meget stærke, intuitivt let forståelige og grafisk baserede analyseværktøjer, der ved hjælp af eksempelvis drag n drop-, lagkage-, Pivot tabel funktionalitet hurtigt kan give detaljerede svar på mange forskelligartede spørgsmål. Brugeren vil i langt højere grad selv kunne danne sine egne analyser og rapporter i et sådan BI-system uden hjælp fra en udvikler 1. Og som det ses herunder er der mange tilgangsvikler og formål med en analyse af ABC-posterne, hvilket understreger behovet for brugen af et BI-system. Vores primære fokus her er i første omgang strategisk ABC og lønsomhedsanalyse, som tidligere nævnt et spørgsmål om Hvad koster/tjener vi på ting (kunder/produkter)? Lønsomhedsanalyse i standard Navision er relativ simpel; der kan beregnes avancer på vare- og kundenumre, i kombination eller summeret på overordnede niveauer. Men som understreget tidligere, er at de data, der ligger til grund for Navisions beregning af avancerne, dannet med henblik på at løse de problemstillinger der i det eksterne regnskab er forbundet med opgørelse af lagerværdi og vareforbrug. Metoden kan bedst betegnes som en IPO-fordelingsmetode! Derudover er der til både en ren dækningsbidrags-, samt en sådan IPO- og såmen også en fuldfordelingsmetode, knyttet en række problemer, som er beskrevet vidt og bredt gennem de sidste 20 års faglitteratur 2. Metoderne giver hverken det rigtige eller dækkende svar på hvad ting koster og hvad der tjenes derpå, og efterfølgende hvilke faktorer, der er bestemmende for, hvorfor der tjenes/tabes hvad der gør. Problemet er brugen af arbitrære (eller slet ingen) fordelingsnøgler. I ABC-sprog ville man herom sige, at der ikke er nogen forbindelse mellem det tillæg, et produkt allokeres via eksempelvis fuldfordelingsmetoden, og det træk på virksomhedens ressourcer, der er et resultat af fremstillingen af 1 Husk på i modsætning til selve ABC-kalkulationen, er der her alene tale om én tabel, nemlig ABC-posterne, hvilket muliggør øget brugerdefinering af output (rapporter, etc.). 2 Nok bedst beskrevet i Relevance Lost, Johnson & Kaplan (1987)

61 produktet. Blandt andet vokser disse problemer i takt med at virksomhedens andel af indirekte omkostninger (og dermed tillægget) stiger. Cokins 1 har opstillet en liste over virksomhedskarakteristika, der skal være opfyldt for at man kan betegne de traditionelle fordelingsmetoder som brugbare (Se Figur 8-1). Listen trækker nok fronterne lidt stærkt op, men dækker alligevel en række af de forhold en virksomhed bør overveje ifm. en vurdering af, hvorvidt de traditionelle allokeringsmetoder bør udskiftet med ABC. Traditionelle omkostningsfordelingsmetoder virker når... Der er få og meget ens produkter/serviceydelser Lave indirekte produktionsomkostninger Homogene produktions- og fremstillingsprocesser Homogene kunder, efterspørgselsmønstre og salgskanaler Lave salgs-, distributions- og administrative omkostninger Meget høje dækningsgrader Er det en virksomhed du kender? FIGUR 8-1. TRADITIONELLE METODER TIL OMKOSTNINGSALLOKERING ER FORÆLDEDE 1 Et kig på Figur 4-3, samt record strukturen i ABC-posten (Bilag E), viser at der er muligheder for at gennemføre mange forskellige lønsomhedsanalyser afhængig af interesser og formål. Man kan anlægge forskellige synsvinkler; kunder og/eller produkter, hierarki niveau, foretage yderligere summeringer og, som det ses herunder, yderligere allokeringer. Så med de mange muligheder øges altså også kompleksiteten og behovet for at definere formålet med analysen (det bør dog allerede være gjort ifm. designet af ABC-kalkulationen). En Kundelønsomhedsanalyse kunne se ud som vist i Figur 8-2. Det skal bemærkes, at man sagtens kan tænke sig analysen udfoldet mere, så resultatet af de enkelte underliggende aktivitetsdrivere specificeres. 1 Cokins (1996)

62 FIGUR 8-2. EKSEMPEL PÅ KUNDELØNSOMHEDSANALYSE Som det ses af Figur 8-2, indeholder lønsomhedsanalysen fordelte omkostninger fra regions- og markedsniveau. Normalt er denne allokering af omkostninger ned gennem hierarkiet ikke helt i ABC-ånden, men der kan være argumenter for at foretage en sådan allokering 1. Man skal dog være opmærksom på, at en sådan allokering jo sker pba. arbitrære fordelingsnøgler (ellers var omkostningerne jo formentlig allerede fordelt til de underliggende niveauer), og forstå niveau forskellen i kosthierarkierne og deres betydning. Eller som Cooper & Kalplans fremhæver det; ABC is a powerful tool but only if managers resist the instinct to view expenses at the unit level 2. Det er endvidere værd at bemærke, at (i) omkostningerne som udgangspunkt er fordelt til det rette niveau og allokeringen først foretages ifm. efterfølgende analyser, og (ii) det rene kundebidrag stadig fremgår af figuren en eventuel sammenligning og vurdering af individuelle kunder skal ske på dette niveau, renset for arbitrære fordelinger. 1 Det gælder specielt, hvis omkostningerne skal danne grundlag for intern eller ekstern prissætning, Se eksempelvis Kaplan, Weiss & Desheh (1997), og Cooper & Kaplan (1991). 2 Cooper & Kaplan (1991)

63 Derudover fremgår det at, hvad der er kaldt kundens markedsbidrag er pænt stort. For det første er det ikke sikkert ABC-kalkulationen omfatter alle virksomhedens indirekte omkostninger. Men derudover er omkostninger på Serie-, Produkt-, Produktlinie- og Virksomhedsbevarende niveau (fra kostobjektet PRODUKT) ikke medtaget i analysen 1. Disse kan selvfølgelig ligeledes allokeres til Enhedsniveauet og dermed medgå i Kundelønsomhedsanalysen, men så begynder man for alvor at udvande ABC-kalkulen i søgen efter det ene endegyldige svar på spørgsmålet; Hvad tjener vi på kunden? En effektiv lønsomhedsanalyse er derfor ikke så meget et spørgsmål om svar, men om de rette spørgsmål. Og i det tilfælde er ABC-kalkulen en guldgrube af information; måske stammer indtjeningsproblemerne i en region ikke fra regionens kunder, men fra omkostninger på regionsniveauet! Det finder vi ikke ud af, hvis vi allokerer omkostningerne til kundeniveauet. Og hvad hjælper det at et produkt har lave enhedsomkostninger og et deraf følgende stort enhedsbidrag, hvis de indirekte omkostninger på serie og produktniveau for netop dette produkt mere end udhuler dette bidrag? 2 Med en lønsomhedsanalyse, som den viste, er man allerede på vej fra det strategiske niveau til decideret analyse af Hvorfor man tjener/taber på de enkelte kostobjekter og i tråd hermed mod en undersøgelse af konsekvenserne ved at afvikle produkter eller kunder, effektivisere processer og aktiviteter, etc. Men selvom ABC-regnskabet umiddelbart synes stærkt hertil, er det netop her de største problemer ved Activity Based Costing findes OMKOSTNINGERNES VARIABILITET OG REVERSIBILITET Indførelse af et timeregnskab, og herunder ikke mindst de direkte ikke-specificerbare omkostninger, skal også ses som et forsøg på at rette lidt op på et af ABC-regnskabets store svagheder; manglende overblik over de underliggende omkostningers karakteristika. Det er altid ledelsens opgave at minimere virksomhedens omkostninger ved ikke-forbrugte ressourcer, herunder de omkostninger, som måtte blive et resultat at fremtidige, planlagte effektivise- 1 Det skal også bemærkes at ABC-modulet ikke indeholder muligheden for direkte at foretage disse allokeringer. Målet har som tidligere nævnt været, at danne ABC-posterne, altså grundlaget for analyse og eventuel re-allokering af omkostninger, som vist i Figur Lønsomhedsanalysen vil selvfølgelig også kunne gennemføres på kostobjektet Produkt, jf. Indtægts-/omkostningsmatrixen i Figur

64 ringsinitiativer og lignende 1. Overblik over ressourceomkostningernes karakteristika, herunder specielt variabilitet og reversibilitet, er et vigtigt element hertil. At det i ABC-modulet er muligt at angive direkte variable omkostninger til en aktivitet, og dermed på ressourcekostpulje-niveau få summeret de direkte omkostningers andel af ressourceomkostningerne, hjælper brugeren et stykke af vejen, da disse omkostninger samtidig er 100% variable med aktivitetsniveauet 2. MEN man skal være opmærksom på, at dette ikke fortæller noget om disse omkostningers reversibilitet der kan jo være hjemkøbt store forsyninger af konvolutter med firma-logo eller indgået en flerårig aftale med en kreditvurderingsvirksomhed. Et andet eksempel, der illustrerer problemerne med sammenhængen mellem aktiviteterne og omkostningerne, er indførelse af EDI (eller e-faktura) i salgsassistenafdelingen. Dette vil på de kunder, der kan sende og modtage EDI ordrer og fakturaer, betyde en tilsyneladende besparelse, da tidsforbruget (og de direkte omkostninger) på aktiviteten ORDREMODTAGELSE OG AFSLUTTENDE FAKTURERING vil kunne nedsættes betydelig 3. Men disse besparelser skal også kunne realiseres, og ikke bare medføre at omkostningerne til ikke-forbrugte ressourcer stiger tilsvarende. Med andre ord; fra ledelsens side skal man kunne: 1. Nedsætte time-kapaciteten i salgsassistenafdelingen, eksempelvis gennem afskedigelser eller nedsættelse af arbejdstiden for en eller flere medarbedjere, eller 2. Benytte medarbejderne til andre opgaver. Kaplan & Cooper opstiller 2 redskaber til brug for en beskrivelse af omkostningernes karakteristika 4 : 1. En gruppering af aktiviteterne efter aktivitetsomkostningernes (kortsigtede) variabilitet vel vidende at det ikke er aktiviteterne, men de underliggende omkostningers variabilitet, der er af interesse. Kaplan & Cooper argumenterer for at nogle aktiviteter trækker på meget variable omkostninger (som f.eks. energi), mens det modsatte er gældende for andre aktiviteter, der i højere grad lægger beslag på næsten faste omkostninger 1 Man kan selvfølgelig også vælge at opretholde et vist ressourceberedskab med de omkostninger dette måtte medføre i så fald er der dog tale om et bevidst valg. 2 Direkte omkostninger er ikke nødvendigvis 100% variable. Det er de dog her. 3 Der skal selvfølgelig indregnes en investering i køb, implementering og drift af EDI-systemet. Omkostninger, der, alt andet lige, bør allokeres til det virksomhedsbevarende niveau. 4 Kaplan & Cooper (1998)

65 (som eksempelvis omkostninger til husleje, afskrivninger 1 og lign.). Grupperingen kræver indsigt i de underliggende omkostningernes variabilitet og det træk, de enkelte aktiviteter forøger herpå. Netop ved indførelse af direkte ikke-specificerbare omkostninger forsøger ABC-modulet at tage højde for den viden om nogle af omkostningernes variabilitet, der findes hos ABC-systemdesigneren. 2. Fleksible og committede ressourcer. Dette er Kaplan & Coopers måde at inddele ressourcer efter deres reversibilitet, hvor fuldt ud fleksible ressourcer kan anskaffes efter behov, mens de committede ressourcer er stærkt ireversible. Kaplan & Cooper s forslag til håndtering af sådanne situationer består i oprettelse af 2 aktivitetsdrivere, hvor den ene håndterer de committede ressourcer, og den anden de fleksible. Dermed opdeles den samlede kostdriver-kostpris ligeledes i 2; en committed og en fleksibel del. Der tages altså ikke hensyn til forskellige grader af irreversibilitet. Derudover må løsningen ikke forveksles med ABC-modulets DIREKTE OMKOSTNINGER (på aktivitetsdriveren), der ikke omhandler omkostningernes reversibilitet, men deres variabilitet. I ABC-modulet består det beløb, der er allokeret til en ressourcekostpulje af en summation af de underliggende omkostningselementers omkostninger. Det er med andre ord muligt at dissekere en ressourcekostpuljes omkostninger i mindre bider, indtil samtlige omkostninger er ført tilbage til kilden, dvs. en manuel indtastning eller et eller flere Navision kartoteker. Nedenfor er i Figur 8-3 vist en sådan udfoldelse af omkostningerne i salgsassistentafdelingen. 1 Alt efter (selvfølgelig) hvorledes man har valgt at behandle afskrivningerne

66 FIGUR 8-3. UDFOLDEDE OMKOSTNINGER FOR SALGSASSISTENTAFDELINGEN Hvor Figur 8-3 giver et overblik over de underliggende ressourcekost-elementer, giver den dog ikke et direkte overblik over sammenhæng mellem aktiviteterne/aktivitetsniveauet og de enkelte ressourcer. De tilknyttede aktiviteter sagtens kan trække forskelligt på ressourcerne i en pulje, som det eksempelvis gør sig gældende med de DIREKTE OMKOSTNINGER og de øvrige (TIME OMKOSTNINGERNE). Dette forhold fremgår af sagens natur ikke af rapporten! Det er med andre ord op til læseren af figuren at sikre sig det nødvendige overblik. Man kunne sagtens forestille sig ABC-systemet udvidet yderligere, så man forsøger at danne de nødvendige sammenhæng, f.eks. ved at indføje specifikke mål for ressourceomkostningernes variabilitet. Men da hver enkelt aktivitets træk på de enkelte ressourcer er helt unikt, vil det i sidste ende svare til at skulle allokere ressourcerne direkte til aktiviteter i modsætning til (primære) ressourcekostpuljer. ABC-modulet stiller altså 4 værktøjer til brug for virksomhedens nærmere analyse af og indsigt i de underliggende ressourceomkostninger, og dermed til et beslutningsgrundlag ift. eventuelle konsekvenser af virksomhedens beslutninger fsva. effektivisering, afvikling eller outsourcing af aktiviteter, samt af- og udvikling af produkt- og kundegrundlaget

67 Svagheden er at der netop er tale om 4 forskellige værktøjer der er ikke ét endegyldigt værktøj, der præcist giver en ledelse svar på de ressource- og omkostningsmæssige konsekvenserne af deres beslutninger AFDELINGSREGNSKAB MED ABC ET ABC-afdelingsregnskab vil, i modsætning til det traditionelle artsopdelte afdelingsregnskab vise omkostningerne fordelt på de aktiviteter, afdelingen udfører, se Figur 8-4 herunder. Bemærk her, at der er gengivet 2 artsopdelte og ét aktivitetsopdelt afdelingsregnskab for Salgsassistentafdelingen. I det ene artsopdelte regnskab er IT-udgifter specificerede. I det andet er de til Salgsassistentafdelingen allokerede IT-omkostninger udfoldede på de underliggende kilder (arter). Artsopdelt afdelingsregnskab (Traditionelt) ABC-afdelingsregnskab (Aktiviteter) Konto Omkostninger Spec. IT Udfold. IT Aktivitet Omkostning Indtægt Lønomkostninger , ,34 Oprettelse af nye debitorer 5.643,56 Rengøring, El og Varme Husleje Kontormøblement Kontorhold Telefon og Fax Porto , , , , , , , , , , , ,33 Ordremodtagelse og -fakturering Reklamationsbehandling Debitor administrion Kundeforespørgsler Ikke-forbrugte ressourcer , , , , , ,92 IT-udgifter (allokerede) ,24 FIGUR 8-4. ARTS- OG AKTIVITETSOPDELT AFDELINGSREGNSKAB FOR SALGSASSISTENTAFDELINGEN 1 Begge regnskaber vil have interesse for ledelsen i en virksomhed. Ofte vil fordelingen på omkostningsarter fortælle regnskabslæseren mere om omkostningernes variabilitet og reversibilitet, mens det aktivitetsopdelte regnskab giver læseren langt større operationelt indblik i, hvad pengene er brugt til. 1 Den opmærksomme læser bemærker naturligvis hurtigt, at det beløb der i finansbogholderiet er posteret under Porto, på ingen måde dækker det beløb der er registreret som Direkte omkostninger (ikke-specificerbare) på de forskellige aktivitetsdrivere, der trækker fra ressourcekostpuljen. Det er selvfølgelig et punkt, ABC-systemdesigneren hurtigst må få analyseret, afklaret og eventuel ændret i kalkulationen eller registreringsregnskabet!!

68 Derudover kunne man tænke sig det aktivitetsopdelte regnskab udvides med oplysninger om direkte omkostninger og tidsforbruget på de enkelte aktiviteter, ligesom det naturligvis er muligt at udfolde aktiviteterne ned på aktivitetsdriverniveau. Endelig skal det fremhæves at et traditionelt regnskab alene vil kunne levere det artsopdelte regnskab, hvorimod ABC vil kunne levere begge, primært fordi det baserer sig på et (og bliver mest nøjagtig, hvis man har et godt) traditionelt artsopdelt afdelingsregnskab TEKNISKE KOMMENTARER ABC-MODULET Nærværende afsnit har til formål at gengive en række af de mere udviklings- og programmeringstekniske erfaringer, der fra opgaveskrivers side er gjort ifm. udviklingen af ABC-prototypen, for på den måde at vurdere brugbarheden og relevansen af et Navision integreret ABC-modul. UDVIKLINGSTID, -TEST OG -OMFANG Målet om at skabe et ABC-modul, der alene skal kunne betjenes og opsættes af brugeren uden involvering af en udvikler, er relativ simpel at opnå i og med, at modulet kan udvikles på en sådan måde, at det er muligt at foretage samtlige beregninger i systemet på manuelt indtastede oplysninger (omkostningskilder, drivere, etc.), ligesom strukturen i ABC-posten muliggør både indtastning og indlæsning af data fra eksterne kilder under relativt simple krav til fil-strukturen. Men argumentet for et integreret ABC-modul skal knytte sig til muligheden for hurtigt og effektivt at kunne genbruge data fra Navision databasen, og ikke være nødsaget til at taste disse igen. Bilag D viser en liste over de Navision kartoteker, hvor hhv. Kunde- og Varenr. indgår. En række af disse kartoteker har ikke interesse i ABC-sammenhæng, det gælder eksempelvis kladder og andre mere eller mindre temporære kartoteker, hvor data alene gemmes i kortere tid. Alligevel vil langt størstedelen af de listede tabeller kunne bruges i en ABC-kalkule, som kilde til ressourceomkostninger eller kostdrivere. Netop den store mængde mulige brugbare data, er her det store problem; for at opfylde ovenstående krav til ingen-udvikler-involvering ifm. opsætning af de enkelte ABCkalkulationer, skal ABC-modul udvikleren for hver tænkelig mulig kostkilde, kostdriver, filter, beregning, etc. programmere de nødvendige funktionaliteter, skærmbilleder, etc. Derudover gør en række andre specielle forhold sig gældende; f.eks. slettes ordrer i Navision efter den afsluttende levering og fakturering. Der er altså ikke direkte historik over gamle ordrer. Men da ordrenummeret overføres til fakturaen kan antallet af originale ordrer og ordrelinier altså allige

69 vel godt identificeres. Det kræver dog (endnu) en speciel udviklet beregningskørsel. Man kunne også tænke sig en tilretning til standard Navision, så færdigleverede og fakturerede ordrer ikke blev slettede men i stedet overført til et nyt kartotek. Da vil ordrehistorikken være direkte til stede. Men det kræver som sagt en tilretning til standard Navision, og som udgangspunkt bør et selvstændigt, dog integreret modul som ABC-modulet ikke involverer tilretninger i standard applikationen, da det besværliggør arbejdet med opgraderinger af programmet, når sådanne udsendes af Microsoft. Og er der først én gang taget hul på dette punkt og lavet tilretninger til standarden, har sådanne tiltag det med at udvikle sig til flere. Vælger man alene at allokere omkostninger fra finansbogholderiet, begrænser programmeringsarbejdet sig selvfølgelig men det gør fleksibiliteten og brugbarheden af systemet også. Gennem opgaven er brugbarheden af eksempelvis Anlægskartoteket blevet fremhævet, hvorfor tilsvarende funktionalitet også bør udvikles til dette kartotek. Med hensyn til omkostningsallokeringen fra kilde-tabellerne er arbejdet dog rimelig overkommeligt det er formentlig begrænset hvor mange kartoteker, man med rimelighed vil kunne forvente ABC-systemdesigneren vil gøre brug af data fra. Lidt anderledes ser det ud, når det drejer sig om de beregninger og filtre, der er nødvendige til brug for ressource- og aktivitetskostdriverne. Her må man påregne, at de områder (tabeller og felter), der fra brugers side forventes dækket er meget større. Nu kan man selvfølgelig stille spørgsmålstegn ved opgaveskrivers C/SIDE udviklingsmæssige spidskompetence, men det er mit klare indtryk at man for at udvikle et fuldt funktionsdygtigt ABCmodul skal lægge endog mange udviklingstimer heri, og skrive mange tusinde kodelinier. OBJEKTPRISER I forlængelse af ovenstående skal Microsoft s prispolitik på området ligeledes fremhæves. Ved udvikling af ekstra kundespecifik funktionalitet skal der anskaffes licens til de nødvendige kartoteker, skærmbilleder, codeunits, etc. Den helt store kostdriver er priserne for ekstra kartoteker. Disse er pt. prisfastsat til kr. 550,- pr. stk. 1, mens de øvrige objekter koster 1/10 af denne pris. 1 Hertil kommer en årlig 10% afgift til et opgraderingsabonnement

70 Da der eksempelvis skal bruges ét kartotek og en form (skærmbillede) for hver af de i Bilag E listede kartoteker, til registrering af Filterdata, vil et fuldt udbygget ABC-modul uden problemer komme over de kr ,- Alene for objekterne. En pris der i Navision sammenhæng er meget høj. Alternativet er her at få modulet autoriseret samtidig et omfattende udviklings-, test og dokumentationsarbejde. det medfører langt lavere objektpriser, men kræver

71 9. KONKLUSION Denne opgave har haft til formål at undersøge hvorvidt og under hvilke forudsætninger Activity Based Costing kan forbedre økonomistyringen (herunder specifikt Kunde-/Produktlønsomhedsanalysen) i MBS-Navision vs i forhold til de data og værktøjer, der er til rådighed i dette ERP-system. I forlængelse heraf er det belyst hvorledes man med fordel kan benytte og automatisere udnyttelsen af de oplysninger, der ligger i Navision s database, til et brugbart Activity Based Costing-system. Sideløbende med udarbejdelsen af denne rapport, er der udviklet en prototype på et decideret, integreret ABC-modul til Navision. Sammen med en gennemgående case, blev denne prototype brugt til eksemplificering og nærmere undersøgelse af (i) de problemstillinger, arbejdsprocessor og - opgaver opstillingen af en ABC-kalkule kan medføre, samt (ii) de problemstillinger udvikleren af et fuldt ABC-modul står overfor. Navisions Kunde-/Produktlønsomhedsanalyser udgøres primært af 2 rapporter, der med udgangspunkt i og totalsummationer på hhv. kunder og produkter opgør avancerne på de solgte produkter. Det datagrundlag Navision baserer sine Kunde-/produktlønsomhedsanalyser (og som altså avancerne beregnes) på baggrund af, er de såkaldte vare- og værdiposter. Disse poster har først og fremmest til formål at danne basis for de automatiske lagerreguleringskørsler i Navision, dvs. danne det grundlag lagerværdier og vareforbrug opgøres og bogføres på. Alt afhængig af den valgte lagermetode (FIFO, LIFO, Gennemsnit, Standard og Specifik), samt tillæg af Indirekte ProduktionsOmkostninger (IPO), betyder det at (i) Kunde-Produktlønsomhedsanalysen baserer sig på hvad man kan kalde IPO-fordelte kostpriser, (ii) vare- og værdiposterne ikke altid kan danne grundlag for opgørelsen af de direkte enhedsomkostninger i en ABC-kalkule. Endvidere skal det understreges at Navision ikke indeholder hverken data eller redskaber til analyse af de indirekte omkostninger ud over mulighederne for opstilling af dimensionsbaserede artsopdelte regnskaber eksempelvis et afdelingsregnskab. Rapporten opstillede en model for strukturen i en ABC-baseret lønsomhedsanalyse (indtægts- /omkostningsmatrix), og i forlængelse heraf, den datastruktur underliggende poster (de såkaldte ABC-poster) til en sådan analyse som minimum skal have for at kunne opfylde analyseformålet. Rapporten gennemgik herefter opbygningen af den udviklede ABC-prototype; allokeringen af omkostninger til ressourcekostpuljer ved hjælp af ressourcekostdrivere og den videre fordeling af omkostninger til aktiviteter og kostobjekter ved hjælp af aktivitetskostdrivere. Samtidig blev der givet

72 en række eksempler på, hvorledes allerede eksisterende data fra Navision kan genbruges i forbindelse med beregning af ressourceomkostninger og ressource- og aktivitetskostdrivere. I forlængelse heraf diskuteredes en række specifikke ABC-relaterede problemstilinger med direkte indflydelse på lønsomhedsanalysen; behandlingen af direkte omkostninger, afskrivninger, periodiseringer, allokering af omkostninger til ressourcekostpuljer fra aktiviteter og sekundære ressourcekostpuljer, aktivitetsdrivertyper, ikke-specificerbare direkte omkostninger og ikke mindst et integreret tids-regnskab på baggrund af hvilket vedligeholdelsen af aktivitetskostdriveromkostningerne i systemet blev væsentlig effektiviseret og omkostningerne ved ikke-forbrugte ressourcer nu kan udtrykkes i både tid og beløb. Resultatet af en ABC-kalkulation er først fremmest dannelsen af ABC-poster, dvs. records i en tabel, hvor oplysninger om omkostninger og indtægter gemmes, sammen med en række karakteristika (dimensioner); (i) hvilken ressourcekostpulje, omkostningen er trukket fra, (ii) hvilken aktivitet, der har forårsaget omkostningen, samt (iii) nærmere oplysninger om omkostningens/indtægtens indplacering i kosthierarkiet og dermed i Kunde-/Produktlønsomhedsmatrixen. I den traditionelle lønsomhedsanalyse, som benyttes i standard Navision, gives et entydigt svar på, hvilken avance, der er på de enkelte produkter og kunder. Denne avance kan enten være ren (dvs. være et produkt af en ren dækningsbidragsanalyse) eller beregnet på baggrund af IPO- eller fuldfordelte omkostninger. Men metoden er ikke dækkende for det træk de enkelte produkter eller kunder måtte have på virksomhedens ressourcer, ud over de direkte omkostninger. Er der foretaget en allokering af indirekte omkostninger (enten IPO eller fuldfordelt) sker dette på baggrund af arbitrære fordelingsnøgler, hvor årsagssammenhængen ikke eller kun i ganske svag grad er til stede. Så selv om svaret umiddelbart kan synes entydigt, er det sjældent det rigtige svar. På samme måde kan en ABC-baseret lønsomhedsanalyse give en form for entydigt svar der blev givet eksempel på en lønsomhedsanalyse, der bl.a. opgjorde bidrag fra en enkelt kunde, dvs. et beløb opgjort som indtægter fratrukket de til kunden på Enheds,- Ordre- eller Kundeniveau ABCallokerede direkte og indirekte omkostninger. Men på samme måde kan bidrags analyser udarbejdes for alle niveauerne i kosthierarkiet. Mulighederne for lønsomhedsanalyser er langt større med ABC end i standard Navision det drejer sig i sidste ende om at stille de rigtige spørgsmål og søge svarene i ABC-posterne

73 Men en ABC-baseret lønsomhedsanalyse får først rigtig værdi, når man begynder en nærmere analyse af tallene når man begynder at stille spørgsmål til de underliggende aktiviteter og omkostninger. Dermed er det ikke bare et spørgsmål hvad man tjener på de enkelte kunder og produkter, men også hvorfor man tjener på disse. Her kommer Navisions datagrundlag og værktøjer til kort, da der netop ikke er de store muligheder for nærmere analyse af de indirekte omkostninger. ABC kan derimod give svar på hvilke og hvor mange aktiviteter, de enkelte kunder og produkter trækker på i virksomheden og hvor meget disse koster at gennemføre. Det er dog ikke helt problemfrit; Et ønske om en endnu dybere analyse heraf til også at omfatte de underliggende ressourceomkostninger og ikke mindst deres variabilitet og reversibilitet kan give problemer. Der er således ikke i ABC ét redskab, der kan give dette overblik. I stedet foreslås i rapporten 4 værktøjer, der samlet set giver et overblik over dette. 1. En gruppering af aktiviteterne efter aktivitetsomkostningernes kortsigtede variabilitet. Nogle aktiviteter trækker meget variable omkostninger, men andre lægger beslag på næsten faste omkostninger. 2. En gruppering af ressourceomkostninger som enten fleksible eller committede. I praksis kan dette gøres ved at oprette 2 aktivitetskostdrivere, hvor den en håndterer de fleksible ressourcer, og den anden de committede 3. Angivelse af direkte, variable (men ikke-specificerbare) omkostninger på den enkelte aktivitetsdriver. 4. En udfoldelse af de til en ressourcekostpulje bagvedliggende omkostningskilder. Vel vidende at aktiviteter tilknyttet den samme ressourcekostpulje, ikke nødvendigvis yder det samme (fordelingsmæssige) træk på ressourcerne (se pkt. 1). Endelig gav rapporten et eksempel på et aktivitetsbaseret afdelingsregnskab. I modsætning til et traditionelt artsopdelt regnskab, der viser hvad omkostningerne er brugt til, viser det aktivitetsopdelte regnskab, hvad (hvilke aktiviteter) virksomheden har fået for pengene. Endvidere indeholder det aktivitetsbaserede regnskab en opgørelse over de direkte indtægter, de enkelte aktiviteter har genereret

74 På baggrund af ABC-prototypen, gennemgangen af dens elementer og eksemplificeringen heraf ved hjælp af den gennemgående case, blev det vist, at det er muligt at udvikle et fuldt integreret og fungerende ABC-modul til Navision, der gør brug af den meget store mængde data, der allerede er til rådighed i et dagligt fungerende system. Men samtidig blev det understreget, at der er store rent tekniske og omkostningsmæssige problemstillinger forbundet med udviklingen af et sådan modul, hvis det forudsættes at det alene skal kunne bruger-betjenes, opsættes og drives uden efterfølgende indblanding fra en udvikler. ABC er basalt set kun en tankegang og mulighederne for at definere ressourcekostpuljer og kilder, aktiviteter og drivere er næsten uendelige og afhængig af den enkelte virksomhed. Det udviklede ABC-modul indeholder muligheden for manuelt at indtaste eller indlæse data, men forudsætningen for et integreret modul, må ligge i muligheden for automatisk at genbruge eksisterende data. Ellers vil en potentielle kunde i stedet lige så godt kunne købe et uafhængigt ABC-program og indtaste, indlæse eller overføre data hertil

75 10. LITTERATURLISTE Andersson, John Eli. Activity Based Costing/Management Forlaget Thomson implementering i teori og praksis. Andersson, John Eli. Activity Based Costing indhentes fra opgaveløser. teori og praksis. Kilde ukendt Kopi kan Bukh, Per Nikolaj og Poul Israelsen (red.). Aktivitetsbaseret Økonomistyring. Danske virksomheders erfaringer med Activity Based Costing. Jurist- og Økonomforbundets Forlag, Bukh, Per Nikolaj og Poul Israelsen. Activity Based Costing. Dansk økonomistyring under forvandling. Jurist- og Økonomforbundets Forlag, Cokins, Gary. Activity Based Cost Management. Making it Work. McGraw-Hill Cokins, Gary. Activity-Based Cost Management White Paper. SAS Institute, The foundation for shared services. A SAS Cooper, Robin og Robert S. Kaplan. Measure Costs Right: Make the Right Decisions. Harvard Business Review, September-October Cooper, Robin og Robert S. Kaplan. Profit Priorities from Activity-Based Costing. Harvard Business Review, Maj-juni, Cooper, Robin og Robert S. Kaplan. Activity-Based Systems: Measuring the Costs of Ressource Usage. Acounting Horizons, September Innes, John og Falconer Mitchell. A Practical Guide To Activity-Based Costing. Kogan Page Limited Israelsen, Poul og James M. Reeve. Resultatrapportering og analyse i komplekse markeds- og fremstillingssituationer. Kapitel 7 (p ) i Håndbog i Økonomistyring, Jan Mouritsen (Red.). Udgivet af Foreningen af Yngre Revisorer,

76 Johnson, H.T. og Robert S. Kaplan. Relevance Lost Accounting. Harvard Business Scholl Press, The Rise and Fall of Management Kaplan, Robert S. Activity-Based Costing: Modified Approach. Kilde ukendt. 200X. Kopi kan indhentes fra opgaveløser. Kaplan, Robert S, Dan Weiss og Eyal Desheh. Tranfer Pricing with ABC. Management Accounting, May Kaplan, Robert S. og Robin Cooper. Cost & Effect. Using Integrated Cost Systems to Drive Profitability and Performance. Harvard Business School Press, Kaplan, Robert S. og V.G. Narayanan. Measuring and Managing Customer Profitability. Journal of Cost Management, September/October Kaplan, Robert S. og Steven R. Anderson. Drive Growth With Customer Profitability Management. How Time-Driven Activity Based Costing Delivers on the Promise of ABC. Kilde ukendt. July Madsen, Vagn. Regnskabsvæsenets opgaver og problemer. I ny belysning. 2. udgave. Gyldendal Mejer, Carsten. En introduktion til strategisk økonomistyring It is alive! Ledelse & Erhvervsøkonomi, nr. 2 p , Nørreklit, Hanne. Interne afregningspriser i multinationale virksomheder. Forlaget Thomson A/S Roztocki, Narcyz og Kim LaScola Needy. An Integrated Activity-Based Costing and Economic Value Added System as an Engineering Management Tool for Manufacturers. Kilde ukendt. 200Xa. Kopi kan indhentes fra opgaveløser. Roztocki, Narcyz. An Integrated Activity-Based Costing and Economic Value Added Information. Kilde ukendt. 200Xb. Kopi kan indhentes fra opgaveløser

77 Svendsen, Katja M. og Cuno Bille Christensen. Økonomi på processer. Fra: 2.dk/artikel8.asp, MICROSOFT BUSINESS SOLUTIONS WHITEPAPERS: Advanced Costing. Whitepaper. Microsoft Business Solutions-Navision. Published Inventory Management: Analyzing Inventory to Maximize Profitability. Microsoft Business solutions-navision. Af Jon Schreibfeder. Published Agility and Manufacturing Whitepaper. Microsoft Business Solutions-Navision. Published Manufacturing Foundation. Whitepaper. Microsoft Business Solutions-Navision. Published June

78 11. OVERSIGT OVER FIGURER Figur 3-1. Fokus, opgaver og metoder i paraplykonceptet strategisk økonomistyring...13 Figur 4-1. Det aktivitetsbaserede regnskabs grundstruktur...15 Figur 4-2. Eksempel på simultane kunde- og produkthierarkier med fordelte aktiviteter...19 Figur 4-3. Indtægts- og omkostningsmatrix til brug for ABC produkt/-kundelønsomhedsanalysen20 Figur 5-1. Et eksempel på vare- og værdiposter i Navision...27 Figur 5-2. Definering af dimensioner og dimensionsværdier i Navision...29 Figur 6-1. Allokeringen af ressourcer til primære ressourcekostpuljer i ABC prototypen Figur 6-2. Relationerne mellem varepost-, Varekost- og ABC-posttabellerne...37 Figur 6-3. Allokering af ressourceomkostninger til salgsassistentafdelingen (struktur)...45 Figur 6-4. Allokeringen af omkostninger til Salgsassistentafdelingen (ABC-modulet)...46 Figur 6-5. Brug af filtre ved opsætning af ressourcekostpuljer...47 Figur 7-1. Sammenhænget mellem aktiviteter og aktivitetskostdrivere i ABC-modulet...49 Figur 7-2. Opsætning af kosthierarkier i ABC-modulet...56 Figur 7-3. Aktivitetskostdrivere ifm. debitoradministrationen i Salgsassistentafdelingen...58 Figur 7-4. ABC-poster til del-aktiviteten 'Opret rykkere' i salgsassistenafdelingen...59 Figur 8-1. Traditionelle metoder til omkostningsallokering er forældede...61 Figur 8-2. Eksempel på kundelønsomhedsanalyse...62 Figur 8-3. Udfoldede omkostninger for Salgsassistentafdelingen...66 Figur 8-4. Arts- og aktivitetsopdelt afdelingsregnskab for Salgsassistentafdelingen

79 Bilag A - Kunde-/Varestatistikker i Navision

80 - 80 -

81 Bilag B Fakturastatistik i Navision

82 Bilag C - Eksempler på vareanalyser i Navision