1. Hvordan designe og å utvikle en
fleksibel og vedlikeholdbar
prismodell for "..." ifm ny
tjenestekatalog (ITIL v3)?
Anbefaling ifm ønsket prinsippbeslutning fra "..."
Styringsgruppe

2. Innhold
•Hovedhensikt - områder
•Hvorfor
•Utfordringer
•Mål for prismodellen
•Kort sikt
• Top down
•Lang sikt
• Bottom up delvis via CMDB
•Lang sikt (II)
• Andre org modeller for IT

3. Hovedhensikt - områder
"..." vil i fremtiden, i hovedsak, ikke motta en budsjettramme fra "..." sentralt. "..."
må derfor fakturere sine kunder for de tjenester som leveres slik at kostnadene
for å levere disse tjenestene kan bli betalt.
Utvikling av en prisingsmodell for dette kan ha mange fordeler, og vil bla bli brukt
av "..." og kundene til bla styringsinformasjon og for beslutningsunderlag i mange
sammenhenger.
Prismodellen har tre funksjoner; cost accounting, prissetting og
(intern)fakturering. Cost accounting følger prinsippet om selvkost og ellers de
regler/forordninger som Rikshosp"..."lets eller "..."s ledelse har besluttet, dvs med
de begrensninger som ligger innenfor de kostelementer som til enhver tid tas inn
i driftsbudsjettet, og har som formål å avdekke et så langt som mulig objektivt
estimat over kostnadene ved å levere tjenestene. I en overgangsfase nå ifm "..."
prosjektet, er det nok vanskelig å få til en god nok cost accounting funksjon på
kort sikt uten en populert CMDB, avtaleoversikter mm. Prissetting er ofte
avhengig av en balanse mellom den objektive kostnadsanalysen og de mer
subjektive områder som markedsføring og prognostisering av etterspørsel etter
de tjenester som skal prises. Faktureringen innebærer selve
transaksjonshåndteringen av debet/kredit for leverte tjenester, samt presentasjon
av underlag for det som har blitt fakturert.

4. Hvorfor
•Å sørge for en tilstrekkelig finansiering av sentraliserte leveranser av IT tjenester på "..."
•Å oppmuntre kundene til å bruke "..."s tjenester effektivt ved å gjøre det mulig for kundene
å bestemme uttak og kostnad for hver enkelt tjeneste de forbruker, og å påvirke kundenes
bruk av disse tjenestene
•Å etablere en prisingsmekanisme som er i tråd med retningslinjer fra "..."let, som igjen vil
fasilitere predikerbarhet på fremtidige totale budsjettrammer for fortsatt å kunne levere IT
tjenester sentralt
•Å gi kundene en mulighet til å benchmarke "..."s priser mot andre leverandører av
tilsvarende tjenester ved å tilgjengeliggjøre rapporter på uttak, kost og servicenivåer
•Å sørge for at "..." får informasjon om utvikling i bruk av enkelte tjenester for å kunne
verdsette IT tjenester og for å kunne vurdere investeringer innenfor tilhørende områder
•Å kunne sørge for en inndekning av "..."s kostnader på en mest mulig rettferdig, konsistent
og automatisert måte uten at det reises tvil om kvaliteten på tilhørende datagrunnlag
•Påvirke kunders etterspørsel og forbruk av tjenester slik at underliggende teknologi kan
utnyttes på en mest mulig effektiv måte.

5. Utfordringer
Gitt at prosessen for å sette pris på tjenester vanskelig helt kan
”nedfelles på steinheller”, og at prisen på "..."s tjenester er en viktig
forbindelse mellom "..." og kundene, så er det slik at det er et konstant
press fra kundene og "..." ledelse på pris og kostnadsnivå gitt deres
individuelle forventninger til "..."s leveranser.
Mange av disse forventningene er sikkert gjensidig ekskluderbare, og
det er slik at "..."s innsats på å møte noen av disse, kan medføre at vi
faller igjennom på oppfyllelsen av noen av disse overfor enkelte
kundegrupper.

6. Utfordringer (II)
Kunder:
• Vil ha så mye som mulig av tjenester til den laveste kostnad de kan få (gitt et kvalitetsnivå)
• Noen kunder vil ha tilleggstjenester uten å betale ekstra for dette
• Kunder vil ikke betale for tjenester de ikke mottar
• Kunder forventer at "..." kan fremvise prismodellen for de tjenester de mottar
Interne kunder (kundekontakter, SLM):
Kostnader og inntekter er noen av de viktigste KPI for suksessfulle leveranser av enhver art, og de må
kunne forvente at de prinsipper som er blitt lagt til grunn for å etablere disse mekanismer er fornuftige.
… og Økonomidirektør:
Forventer nok at prisen på tjenester er tett koblet til kostnaden ved å levere disse, men de vil nok også
ha en forståelse for strategisk prissetting for å kunne styre kostnadsutviklingen på noe lengre sikt.
….:
Legger nok opp til en harmonisering av IT tjenester på mellomlang sikt, og vil nok i den sammenheng
ha samme ønsker for en åpen prismodell som også kan brukes i tilhørende budsjettprosesser.
Skattebetalere:
Forventer at skatten de betaler blir brukt effektivt for å levere etterspurte helsetjenester.

7. Mål for prismodellen
•Enkel å vedlikeholde, ifh endringer (for eksempel nye
tjenester) og nye brukere/kompetanse
•Fleksibel, ikke ”Excel helvete”
•Hvordan unngå budsjettrevisjon ved innføring av nye
tjeneste(r)/priser i løpet av året? Ikke mulig?
•Priser må oppfattes som rettferdige
•Modellen må være kommuniserbar ifh innsyn og kontroll
•Må også kunne brukes/leses av "..." og "..."s kunder, dvs ”ikke
økonomer og lignende”

8. Mål…
Teori ved internprising: Justerte markedspriser
Ulempe: hvordan finne markedsprisen på tilsvarende
tjeneste?
Anbefales i hovedsak ikke pga at dette er
vanskelig/tidkrevende og det blir alltid diskusjoner,
sannsynligvis vanskelig salgbart på RH også. Merk unntak
for tekniske/infrastruktur tjenester
Anbefaling: Priser i hovedsak basert på budsjettert selvkost
("..." driftsbudsjett) som regnes ut i en Excel modell. Mål er
såklart at pris * enheter = "..." budsjettert selvkost

9. Kort sikt
Fom budsjett 2009
Tekniske/infrastruktur/konsulent tjenester prises til justert markedspris.
Er avhengig av et estimat på volum. ”Sum” reduserer budsjettbase for
applikasjonsorienterte tjenester (resten)
Forutsetninger for applikasjonsorienterte tjenester:
Direkte kost: vedlikeholdskostnader på applikasjoner/systemer som brukes
av kundene
Indirekte kost: Personalkostnader inkl ledergruppe og andre driftskostnader
(vanskelig å koble til applikasjoner, spesielt over noe tid pga variabilitet.
Kobles IKKE til applikasjonsorienterte tjenester, men til antall brukere og
PCer

10. Kort sikt
Modell for pris for tjenestepakker kan da bli:
Tjenestepakke 1
Appl 1
Appl 2
Appl 3
Appl 4
Appl 5
Appl 6
Appl 7
Tjenestepakke 2
Appl 1
Appl 2
Appl 3
Sum
Antall applikasjoner i tjenestepakken
Estimert antall kjøpere av tjenestepakken
Innbyrdes vekt basert på antall applikasjoner
Felles kostnadsbase (sum vedlikeholdskostnad)
"Kost" pr tjenestepakke
Pris pr kjøper av tjenestepakken
7
100
70,00 %
3
300
30,00 %
700,00
7,00
10
300,00
1,00
100,00 %
1000
Må likevel ha mulighet for strategisk styring av pris for for eksempel
lightbruker (sannsynligvis avhengig av … beslutning)

11. Kort sikt
Modell for prising av indirekte kost:
Strategisk valg: pr bruker eller PC(arbeidsstasjon)
eller begge?
Anbefaling: Pr bruker pga mye bedre mulighet for
kontroll på datakvalitet
Pris = sum indirekte kost / estimert antall brukere

12. Lang sikt
Vedlikeholdskostnad/lisensmodell registrert som
attributt på applikasjon
Kostnadsbase for applikasjoner blir faktisk direkte
kostnad og ”riktigere”.
Ikke mulig å få til før CMDB er populert på dette
nivå. Når? I hvert fall ikke i tide til budsjettprosess
2009
Anbefaler ellers modell uforandret ifh ”kort sikt”

13. Lang sikt (II)
Andre organisasjonsmodeller, for eksempel AS vil
ihvertfall bety følgende:
Kapitalslit må prognostiseres hvert år pr assetgruppe
(attributt på CI i CMDB) og kobles til tjenester. Bør i
størst mulig grad behandles som direkte kostnader
knyttet til tjenestepakker
Andre kostnader som ikke er i budsjett pr i dag må
inkluderes (husleie, strøm, etc). Bør behandles som
indirekte kostnader
Unngår eller minimerer effekten av en budsjettrevisjon
på endring/nye tjenester i løpet av året