Bilag 7 vedlegg 2 prisberegninger

Transkript

1 Bilag 7 vedlegg 2 prisberegninger Informasjon for gjennomføring av prisberegninger i bilag 7 vedlegg 1 prisark Anskaffelse av analyse- og informasjonsplattform Anskaffelsesnummer Saksnummer /345746

2 Innledning til prisscenarier Vedlegg 1 til bilag 7 tjener flere formål. Dels er det spesifikke faner som vil benyttes til Prissammenligningsformål ("TCO beregning" og "Skalering lisenser"), dels skal Leverandøren beskrive enhetspriser på tilbudt programvare og maskinvare (i egen fane). Fanene for prissammenligning forplikter ikke kunden til å kjøpe spesifisert programvare og maskinvare. "TCO beregning" vil benyttes til å måle Løsningens levetidskostander basert på et sett mulige skaleringstrinn. Samtidig er det krav at Løsningens design som ligger til grunn for prisingen skal beskrives i bilag 2 (krav til beskrivelse ligger i bilag 1). Beskrivelsen av designet vil bli benyttet som en viktig del av evaluering av Løsningens egnethet/kvalitet. "Skalering lisenser" vil benyttes til å måle Løsningens skaleringskostnader, både gjennom et klarere bilde av lisenseringsmekanismene som tilbys samt gjennom tydeliggjøring av prising av skaleringstrinn med tilhørende kostnader. TCO beregning Det skal i utarbeidelsen av "TCO beregning", prises at Løsningen som anskaffes, tas i bruk etter følgende scenarier: 1. År 1 (Oppstart av prosjekter fra leveringsdag) a. Kunden gjennomfører prosjekter på levert løsning - fire stk totalt. Gjennom denne bruken tas all funksjonalitet i bruk, med en initiell skalering og en skalering i år 3 b. Modernisering av Skatteetatens datavarehus startes. Hovedtrekk er at det over en to års periode reimplementeres funksjonalitet fra dagens datavarehus over på Løsningen 2. År 3 (full produksjon og nytt prosjekt tar Løsningen i bruk) a. MVA, all funksjonalitet tas i bruk Hovedtrekk med hensyn til faktorer som antas å ha betydning for dimensjonering av Løsningen og påvirke priser er beskrevet nedenfor. Dersom Leverandøren ser at det mangler vesentlige faktorer for dimensjonering eller prising vil Kunden kunne fremskaffe eventuelle ytterligere grunnlagsdata. Enhver forutsetning som Leverandøren legger til grunn for pris skal fremgå. Leverandøren skal videre beskrive detaljert hvordan pris er fremkommet. Leverandøren skal beregne TCO for disse tre scenariene som separate beregninger. For alle scenarier skal det beregnes TCO for fire år. I TCO skal alle relevante forhold for pris inngå: - Programvarelisenser innkjøp/vedlikehold/årlig leie - Maskinvare investering + vedlikehold. Det skal fremgå levetid som er lagt til grunn for maskinvare og det skal legges inn kostnad for tilsvarende reinvestering når levetiden er omme - Driftskostnader (basert på prising av driftstjenester basert på krav i bilag 6) - Installasjons/klargjøringsarbeid ved skalering - Eventuelt andre kostnader Etableringskostnad, dvs kostnader leverandør/integrator legger til grunn for å sette opp og akseptanseteste løsningen initielt, skal holdes utenom og spesifiseres separat.

3 Heretter benevnes de overnevnte scenariene som 1a, 1b og 2a. Skatteetaten arbeider etter prinsippet devops/kontinuerlig idriftsettelse. Det betyr at det skal pris-settes produksjonsløsninger, test og utviklingsløsninger for alle tre scenarier. Bilag 3 beskriver hvordan dagens datavarehusutvikling foregår, hvordan eksisterende maskinvare er bestykket, samt hvordan maskinvare utnyttes på en mest mulig effektiv måte i dag. Som det fremgår har Skatteetaten en ganske utstrakt utviklingsaktivitet, med en rekke utviklings og stagingsmiljøer per prosjekt/anvendelsesområde. Det er antatt at dette også vil være tilfelle også for ny Løsning. Slik dagens løsning er satt opp benyttes virtualisering og kloningsteknikker for å gjøre det mulig for miljøene og prosjektene å oppleve omgivelsene som unike/spesifikke selv om de deler maskinvare med hverandre. Dette fører til vesentlige kostnadsbesparelser og gjør det mulig med høy utviklings og endringstakt. Teknikkene som er benyttet i dagens løsning, er gitt av dagens underliggende infrastruktur. I prisingen er det viktig at Leverandøren synliggjør hvordan Løsningen på en kostnadseffektiv måte kan ivareta behovet for mange testmiljøer / parallelle prosjekter på til dels like datasett. I bilag 2 skal underliggende teknisk design med lisens og maskinvaremessig skalering som ligger til grunn for prisingen av scenarioene, beskrives. Det skal fremgå hvordan designet ivaretar kravene i bilag 1. I bilag 7 + vedlegg 1 til bilag 7 skal skaleringsfaktorene for pris beskrives. Eventuelle begrensninger/forutsetninger skal spesifiseres. Leverandøren skal beskrive eventuelle begrensninger i skaleringsmuligheter, eksempelvis synliggjøre om maskinvare leveres med begrensninger i skaleringsmulighet. Kostnadskonsekvenser skal beskrives. Det er viktig for Kunden å ivareta investeringer over tid gjennom trinnvise skaleringer i takt med at behov utvikles. Scenario 1a nøkkeltall - Test og utvikling o 4 parallelle prosjekter Hvert prosjekt har 5 miljøer Til sammen 20 miljøer o 10 DVH utviklere totalt o 10 analytikere totalt o 100 Rapportutviklere/brukere o 150 maskinvarekontoer (for integrasjoner med andre systemer/programmer) o Det er antatt at mengde rådata er ca 1 TB. Rådata skal være tilgjengelig for alle miljøer. Leverandøren bes beskrive hvordan dette kostnadsmessig kan gjøres og valgt mekanisme skal ligge til grunn for prisestimat - Produksjon o 1 TB rådata o Kjøremiljø skalering er bekrevet i avsnittet " Scenario for kjøremiljø for scoring og regler (scenario 1a)" Scenario 1b nøkkeltall - Test og utvikling modernisering av datavarehus o Til sammen 10 miljøer o 20 DVH utviklere totalt o 50 maskinvarekontoer (for integrasjoner med andre systemer/programmer)

4 o Det er antatt at mengde rådata er ca 40 TB. Rådata skal være tilgjengelig for alle miljøer. Leverandøren bes beskrive hvordan dette kostnadsmessig kan gjøres og valgt mekanisme skal ligge til grunn for prisestimat Det er antatt at det i tillegg vil være 8 TB prosesserte data som er unike per miljø - Produksjon o 40 TB rådata, 360 TB prosesserte data Scenario 2a nøkkeltall - Test og utvikling nytt prosjekt o Til sammen 5 miljøer o 10 DVH utviklere totalt o 50 maskinvarekontoer (for integrasjoner med andre systemer/programmer) o Det er antatt at mengde rådata er ca 15 TB. Rådata skal være tilgjengelig for alle miljøer. Leverandøren bes beskrive hvordan dette kostnadsmessig kan gjøres og valgt mekanisme skal ligge til grunn for prisestimat - Produksjon o 15 TB rådata Tall felles for alle scenario % av mengden rådata prosesseres hvert døgn. Løsningen skal være dimensjonert til å håndtere opp til 20% - All funksjonalitet skal inngå - Det skal prises to vekstscenarier for datamengde: 1. 10% årlig datavekst 2. 20% årlig datavekst - Antall brukere i produksjon er felles for alle scenarier. DVH Utviklere: 20 Analytikere og modellbyggere: 400 Rapportutviklere/brukere: 4000 Applikasjonsdrift: 5 Maskinbrukere: 50 Det skal i beskrivelse av prismekanisme fremgår hvilke faktorer som skalerer pris. Faktorene/prisskalering skal være kvantifisert. Leverandøren står fritt til å basere pris på det som er gunstigst på Skatteetaten. Det skal klart fremgår hvorfor valgt alternativ er mest prisgunstig og fremgå kostnadsmessig effekt samt eventuelle forutsetninger/begrensninger i alternativ som er valgt. Brukerbasert prising Dersom enkeltpriser er basert på per brukerbasert prising, skal leverandør splitte pris i følgende: - Pris for brukere i test og utviklingsmiljøer som spesifisert over - Pris for brukere i produksjonsmiljø som spesifisert over - Pris for all bruk innenfor Skatteetatens virksomhetsområde Der Leverandøren ikke spesifikt har oppgitt brukerbasert prising, er pris for bruk i Skatteetatens virksomhetsområde uavhengig av antall brukere.

5 Scenario for kjøremiljø for scoring og regler (scenario 1a) Kunden har i bliag 1 beskrevet krav knyttet til utvikling, forvaltning og kjøring av ulike typer regler og modeller. I forhold til valg av produkter og prising legger vi til grunn at de bruksmønsterne og volum som beskrevet for øvrige scenarier dekker utvikling og forvaltning av regler og modeller. Denne beskrivelsen skal beskrive grunnlag for å dimensjonere og prise kjøremiljø for scoring og regler. Beskrivelsen dekker et scenario for situasjonen ved oppstart av leveransen og et mulig scenario som representerer tre år frem i tid. Scenario fra oppstart i år 1 Det er etablert fire ulike prediktive eller ekspertmodeller som skal kjøres for noen avgifter. Modellene er etablert slik at: Det prepareres ca 100 historiske variable pr modell som hentes fra ulike deler av informasjonsplattformen. Disse oppdateres på daglig basis. For kjøring av modellene mottas det ytterligere ca 30 variable fra utløsende hendelse, som sammenstilles med historiske variabler. De fire modellene kjøres i nær sanntid basert når etaten mottar avgiftsoppgaver som skal behandles. Dette styres fra produksjonssystemene som mottar oppgavene I tillegg skal 10 analytikere ha anledning til å kjøre samme modeller manuelt ved behov Innleveringsmønster for avgiftene er ulikt og sammenfaller ikke slik at peakbelastning kommer på ulike tidspunkt. Avgift med det høyest peak har en belastning der det mottas ca oppgaver seks ganger pr år med en fordeling der mønsteret de siste fire dagene før frist er som vist nedenfor. Dag -4 Dag - 3 Dag 2 Dag Skalert scenario i år 3 Etaten ser for seg en utvidet bruk av modeller i fremtiden for alle skatte- og avgiftsarter. De som skal utvikle og vedlikeholde modeller vil være innenfor de analytikerne og DVH-utviklerne som er spesifisert i øvrige scenarier. Det samlede påtrykket på scoringsløsningen vil øke i dette scenariet ved at vi ser for oss at det vil være ca 50 ulike modeller som er etablert for etatens skatte- og avgiftarter. For skalering av kjøremiljø legger vi følgende til grunn: Hendelsen som har medfører høyest peakbelastning er at det skal mottas og scores oppgaver som skal scores i sanntid pr time. Modell som skal kjøres består av ca 100 historiske variabler som prepareres en gang pr time. Innholdet i oppgaven som skal scores er variabelt, men vil i snitt være på 100 variabler. Øvrige modeller kjøres i hovedsak etter tilsvarende kjøremønster, men med lavere volum i peakbelastning I tillegg skal 400 analytikere ha anledning til å kjøre samme modeller manuelt ved behov samme gruppe som er nevnt i øvrige scenarier.

6 Skalering lisenser Skaleringsmekanismer for programvare Vedlegg 1 til bilag 7 inneholder fanen "Skalering lisenser" der det skal fremkomme hvordan Leverandørens programvare er priset og skalerer. Tabellen inneholder normaliserte typiske måter å lisensiere programvare. I noen tilfeller har Skatteetaten beskrevet en foretrukket lisensieringsmetode med eventuelle alternative lisensieringsmetoder. Dette er basert på erfaring med lisensieringsbetingelser i ulike anvendelsesområder. Leverandøren står fritt til å foreslå andre lisensieringsmekanismer som måtte være gjeldende for produktene som tilbys. Basert på etatens erfaring med programvare og tenkte bruk av Løsningen, vil noen lisensieringsmekanismer være uønsket. Disse er spesifisert. Dersom leverandøren tilbyr pris basert på en slik mekanisme, vil det i noen tilfeller være en ønsket forutsetning fra etaten på lisensiering. Eksempelvis, dersom det er brukerbasert lisensiering, vil det i noen tilfelle være ønskelig med ubegrenset bruk. Leverandøren står imidlertid fritt til å tilby lisensieringstrinn også her. For noen funksjonsområder vil en lagringsorientert lisensiering være svært lite ønskelig og hensiktsmessig. Det er så langt ikke vært mulig å estimere relevante lagringsvolumer. Dersom det likevel tilbys lagringsorienterte lisenser, vil det under evaluering legges inn skjønnsmessig volumer kalkulert med Leverandørens oppgitte priser Leverandøren skal fylle ut bilaget. Der elementer mangler eller der prisskalering er bygd på andre mekanismer, skal leverandøren legge dette til som egne linjer. Det dette gjelder også dersom Skatteetatens normaliserte verdier for lisensieringsform ikke passer for tilbudt lisensiering. Skaleringstrinn med priser skal fremgå. Det er også lagt inn noen volumeksempler som skal prises. Det skal fremkomme om prise er kjøp pluss vedlikehold eller årlig leie. Sum årlig vedlikehold skal fremkomme. Leverandøren skal ikke beskrive maskinvarekostnad, kun kostnad knyttet til at programvaren kan kjøre på egnet maskinvare. Det forutsettes at maskinvare innenfor et funksjonsområde er den samme uavhengig av lisensieringsform. Kostnader for maskinvare måles dels gjennom enhetspriser og dels gjennom TCO beregninger. Alle kolonner markert med sort er utfylt av Skatteetaten. Kolonner merket med gult skal fylles ut av Leverandøren. Fanen "Instruksjoner" inneholder forklaring til de enkelte kolonner. Utfyllende informasjon knyttet til normaliserte lisensieringsformer: Maskinvarebasert. Lisenser er direkte knyttet til mengde maskinvare som er nødvendig for gitte skaleringstrinn Lagringsvolum. Lisenser er direkte knyttet til mengde lagring nødvendig for gitte skaleringstrinn Bruker produsent Lisenser er knyttet til det antall identifiserte brukere i Skatteetatens interne katalogtjenester som produserer innhold Bruker konsument Lisenser er knyttet til det antall identifiserte brukere i Skatteetatens interne katalogtjenester som konsumerer innhold

7 Bruker 3.part. I stadig større grad leverer Skatteetaten innsyns og korrigeringstjenester for samfunnet. Dette omfatter både borgere og virksomheter samt ansatte i virksomheter. Det er svært lite ønskelig med lisensieringsformer som setter noen form for begrensning i slik bruk. Det skal klart fremgå om det er lisensvilkår som settes noen form for slik begrensning. Dersom slike begrensninger ikke er eksplisitt beskrevet, skal lisensieringsbetingelser avtalemessig oppfattes å ikke ha slike begrensninger Når det gjelder Skatteetatens interne katalogtjenester så vil det være identiteter både knyttet til ansatte i Skatteetaten, ansatte i offentlige virksomheter og andre eksterne. Det er svært lite ønskelig med lisensmessige begrensninger i forhold til hvilke ansettelsesforhold en bruker definert i Skatteetatens katalogtjenester kan ha som bruker av Løsningen. Det skal klart fremgå om det er lisensvilkår som settes noen form for slik begrensning. Dersom slike begrensninger ikke er eksplisitt beskrevet, skal lisensieringsbetingelser avtalemessig oppfattes å ikke ha slike begrensninger. Dersom deler av funksjonaliteten i bilag 1 kan leveres som opsjon, kan dette synliggjøres i kolonnen "Tilbudt som opsjon". Inndelingen i funksjonsområder er i henhold til bilag 1 men forventes ikke å være i henhold til leverandørens faktiske produktinndeling. Leverandøren skal forklare hvilke produkter som tilbys og hvilke funksjonsområder de dekker. I prisingen av volumer bør Leverandøren unngå "dobbeltprising", dvs prising av samme modul flere ganger. Leverandøren bør synliggjøre der en modul dekker flere funksjonsområder. Fanen "Eksempel lisens utfylling" er ment som et hjelpemiddel for å forstå hvordan fanen "Skalering lisenser" kan fylles ut. Eksemplet som er beskrevet er et rent teoretisk eksempel uten kobling til noen reelle produkter i markedet. Eksemplet viser et use case der et funksjonsområde dekkes av flere produkter.

8