Bilag til avtale om løpende tjenestekjøp over internett
Bilag til avtale om løpende tjenestekjøp over internett
Statens standardavtaler for IT-anskaffelser bilag til SSA-L - versjon 2018
Saksnr. 24/00947
SSA-L-2018
Bilag til SSA-L – Avtale om løpende tjenestekjøp over internett– versjon 2018
Innhold:
Bilag 1: Kundens kravspesifikasjon 3
Bilag 2: Leverandørens beskrivelse av tjenesten 19
Bilag 3: Plan for etableringsfasen 34
Bilag 4: Tjenestenivå med standardiserte kompensasjoner 35
Bilag 5: Administrative bestemmelser 36
Bilag 6: Samlet pris og prisbestemmelser 37
Bilag 7: Endringer i den generelle avtaleteksten 39
Bilag 8: Endringer av tjenesten etter avtaleinngåelsen 40
Bilag 9: Vilkår for Kundens tilgang og bruk av tredjepartsleveranser 41
Bilag 1: Kundens kravspesifikasjon
1.1. Oppdragsgiver
Oppdragsgiver er:
Norsk helsenett (xxx.xx. 994 598 759).
Norsk helsenett (NHN) er et statlig foretak, eid av Helse- og omsorgsdepartementet. NHNs oppgave er å utvikle, forvalte og drifte nasjonale e-helseløsninger og infrastruktur. Videre har NHN rolle som innkjøpssentral for anskaffelser i den statlige helseforvaltningen.
For mer informasjon om oppdragsgiver, se xxx.xxx.xx
1.2.1 Formål
Oppdragsgiver skal anskaffe en standard hyllevare for å innhente, sammenstille, analysere og få relevant innsikt slik at dette kan brukes som styringsinformasjon. Styringsinformasjonen skal baseres på flere kilder med flere parametere.
Løsningen som anskaffes skal være ferdig utviklet og testet, og skal fremstå som ett samlet verktøy. Verktøyet skal blant annet ha følgende funksjonalitet:
- støtte til innkjøps- og forbruksanalyse på avtalenivå basert på for eksempel
regnskapsdata, avtaleinformasjon og fakturainformasjon
- mulighet for å sammenstille, berike, klassifisere/kategorisere, analysere og visualisere innkjøpsdata fra ulike kilder
- presentasjon av innkjøps- og spendanalyser, herunder måling og oppfølging av avtaledekning og avtalelojalitet
- støtte til avtaleforvaltning gjennom å måle avtalelojalitet og eventuelt lekkasjer
- kunne lese informasjon på faktura- og artikkellinje nivå fra EHF fakturaer (fra blant annet aksesspunkter)
- bidra til kategoristyring innenfor innkjøp gjennom profesjonelle analyser
- leverandør- og avtaleoversikter og analyse av disse
Løsningen som anskaffes skal gi systemstøtte for aktsomhetsvurderinger av leverandørkjeden i tråd med åpenhetsloven. Med dette menes støtte for risikovurdering av brudd på menneskerettigheter og anstendige arbeidsforhold basert på anerkjente kriterier, og støtte for oppfølging av leverandørene.
I tillegg skal løsningen gi systemstøtte for klimagassberegninger i tråd med GHG-protokollen og CSRD/ESRS, etter anerkjente og oppdaterte utslippsfaktorer.
Det skal inngås avtale med én leverandør. Opsjon:
NHN har som langsiktig mål å hente inn forbruksdata fra helseforvaltningen for avtalene
NHN inngår på vegne av helseforvaltningen. Dette ligger frem i tid. I dag mottar helseforvaltningen opp mot 50 000 fakturaer pr år.
1.2.2 Omfang
Estimert omfang er vist i tabellen nedenfor.
Omfang | Anslått volum |
Brukere | 35 |
Administratorer hos NHN | 5 |
Antall fakturaer per år i NHN | 11 000 |
Antall fakturaer per år i helseforvaltningen (opsjon) | 50 000 |
Antall leverandører NHN | 1 200 |
Antall leverandører helseforvaltningen (opsjon) | 1 200 |
Antall kontrakter NHN | 550 |
Antall kontrakter helseforvaltningen (opsjon) | 550 |
Datakilder forbruk/spend NHN | 2 |
Datakilder forbruk/spend helseforvaltningen (opsjon) | 2 |
Datakilder - kundens data NHN | 5 |
Datakilder – kundens data helseforvaltningen (opsjon) | Inkludert i NHN |
1.2. Klassifisering av krav
Hvordan de ulike kravene er klassifisert, fremgår av kravtabellene. Kravtypene er som følger:
A-krav er absolutte krav som må innfris. Dersom ett eller flere A-krav ikke er oppfylt, vil tilbudet bli avvist.
B-krav er viktige krav, og vil bli evaluert.
For A-krav er ordlyden "Skal" og for B er ordlyden "Bør". I de tilfeller det er uklarheter, er det klassifisering (A, B) av kravet som gjelder.
I kolonnen JA/NEI skal leverandøren svare om kravet er oppfylt.
Der det står <x> i kolonnen Dokumentasjonskrav, er det krav til utfyllende kommentar eller utfylt vedlegg fra leverandøren.
<Tekst i kursiv> i kolonnen Dokumentasjonskrav er instruksjoner til tilbyderen i tilbudsfasen og erstattes med tilbyderens besvarelse i bilag 2.
Der leverandøren gir sin besvarelse i eget vedlegg, skal nøyaktig plassering oppgis (kapittel, avsnitt, punkt etc.).
1.3. KRAV TIL LØSNINGEN
Leverandøren skal besvare kravene i SSA-L Bilag 2 Leverandørens løsningsspesifikasjon. Der leverandøren i sin besvarelse refererer til sin egen vedlagte dokumentasjon skal nøyaktig plassering oppgis (kapittel, avsnitt, punkt etc.).
Nr. | Krav | Kravtyp e A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
Generelt | ||||
1.3.1 | Drifts- og forvaltningsmodell Den tilbudte løsningen skal leveres som en skytjeneste (SaaS). | A | <Leverandøren bes bekrefte at kravet er oppfylt, og beskrive hvilken driftsmodell som tilbys.> | |
1.3.2 | Tilbudt løsning Den tilbudte løsningen skal fremstå som ett samlet verktøy for brukere av løsningen. | A | <Leverandøren bes beskrive hvordan kravet er oppfylt> | |
1.3.3 | Webbasert løsning Løsningen bør være fullt ut webbasert, og det bør ikke være behov for at kundens brukere installerer plugins eller annen lignende programvare lokalt på kundens eget utstyr for å kunne benytte alle deler av løsningen fullt ut. | B | <Leverandøren bes beskrive hvordan kravet er oppfylt> | |
1.3.4 | Brukergrensesnitt og plattformuavhengighet Kunden benytter PC med nettleser som brukergrensesnitt for produksjon og databehandling. Løsningen bør være tilpasset alle digitale flater, samt støtte ulike nettlesere. | B | <Beskriv hvordan dette er ivaretatt i løsningen, og eventuelle ulike muligheter på PC og nettbrett/mobiltelefon.> | |
1.3.5 | Tilgangsstyring og administrasjon Løsningen bør ha fleksibel og oversiktlig tilgangsstyring/rollestyring og administrasjon av brukere, roller, brukerkontoer og tilganger/visninger. | B | <Beskriv hvordan dette er løst.> | |
Nr. | Krav | Kravtyp e A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.3.6 | Tredjeparts programvare Dersom den tilbudte tjenesten inkluderer standard tredjeparts programvare som må leveres under standard lisensbetingelser og avtalevilkår, bør dette være uttrykkelig angitt i Bilag 2. Kopi av lisensbetingelsene vedlegges i så fall tilbudet som Bilag 9. | B | <Dersom aktuelt: Beskrives i Bilag 2 og vedlegges i Bilag 9 Dersom tilbudt produkt inkluderer standard tredjeparts programvare som må leveres under standard lisensbetingelser og avtalevilkår, skal dette angis her. Kopi av lisensbetingelsene skal i så fall vedlegges tilbudet som Bilag 9.> | |
1.3.7 | Språk Alle tekster en bruker av løsningen eksponeres for, eller benytter bør være på norsk språk. | B | <Beskriv språket som benyttes i løsningen> | |
1.3.8 | Språk Alle tekster en administrator av løsningen eksponeres for eller benytter bør være på norsk, skandinavisk eller engelsk språk. | B | <Beskriv språket som benyttes i løsningen> | |
1.3.9 | Integrasjon regnskapssystem Det skal være mulig å integrere løsningen med kundens regnskapssystem (per i dag Unit4ERP) gjennom REST-API. | A | <Beskriv mulighetene> | |
1.3.10 | Krav til integrasjonsgrensesnitt Det er ønskelig at løsningen på en enkel måte kan integreres med andre systemer. | B | <Beskriv mulighetene for Integrasjoner> | |
1.3.11 | Prismodell Leverandøren bør ha en oversiktlig og forutsigbar prismodell. | B | Besvares i bilag 6: ✓ leverandøren bes beskrive hvordan prisen påvirkes av volum, herunder hvordan prisen påvirkes av antall aksesspunkter, fakturaer, kontrakter, leverandører, brukere etc., ✓ skalering av tjenesten, ✓ hvor snart prisendringer trer i kraft ved endringer, ✓ integrasjoner og ✓ hvordan prisen påvirkes av nyutviklet funksjonalitet bestilt av kunden |
Nr. | Krav | Kravtyp e A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.3.12 | EHF-felt i faktura fra leverandøren til kunden Leverandøren bør oppfylle kundens krav til bruk av EHF-felter i fakturering til kunden, jf. bilag 6, punkt 5.2 og 5.3. | B | <Beskriv hvilke EHF-felt under punkt 5.2 og 5.3 i bilag 6 som er mulig per i dag, hvilke alternativer leverandøren har for felt som mangler, og hvilke fremtidige planer leverandøren har for å oppfylle kravene til felt som mangler> | |
1.3.13 | Universell utforming Løsningen skal ivareta krav til universell utforming, jf. Forskrift om universell utforming av informasjons- og kommunikasjonsteknologiske | A | < Leverandøren skal beskrive hvordan kravene til universell utforming ivaretas i den tilbudte løsningen | |
Etablering | ||||
1.3.14 | Etablering - erfaring Leverandøren bør har god erfaring med etablering av tjenesten. | B | Leverandøren beskriver sin etableringsplan i bilag 3. Planen bør minimum inneholde: ✓ tidsplan med milepæler for etablering, konfigurering og levering ✓ planer for test, ✓ plan for opplæring, ✓ aktivitetsbeskrivelse ✓ planlagt fremdrift og ✓ anslått timeforbruk for leverandør og kunde i de ulike fasene ✓ plan med milepæler for betaling som er knyttet til leveranser i etableringsprosjektet Pris for den foreslåtte planen oppgis i bilag 6. | |
1.3.15 | Historiske data fra andre systemer Løsningen må kunne importere historiske data fra andre systemer som en del av implementeringen. Tjenesten prises som en tilleggstjeneste etter medgått tid. | A | <Beskriv løsningens muligheter og begrensninger> | |
Feilhåndtering | ||||
Nr. | Krav | Kravtyp e A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.3.16 | Feilsøk Leverandøren skal bekrefte at ved en eventuell feilsituasjon forplikter leverandøren seg til å samarbeide og feilsøke med kunden og eventuelt andre leverandører så lenge det er behov for det, selv om feilen ikke er Leverandørens ansvar. | A | <Leverandøren bes beskrive hvordan kravet oppfylles.> | |
1.3.17 | Logge feil Løsningen skal logge feil på en strukturert måte. | A | <Leverandøren bes beskrive hvordan kravet er oppfylt.> | |
SLA - Tjenestenivå | ||||
1.3.18 | Tjenestenivåavtale Leverandøren bør tilby god oppetid og gode responstider gjennom en tjenestenivåavtale. | B | <Leverandøren bes beskrive sin standard tjenestenivåavtale i bilag 4.> | |
1.3.19 | Kompensasjon ved brudd Ved brudd på tjenestenivå bør kunden har rett på kompensasjon. | B | <Leverandøren bes oppgi standardiserte kompensasjoner for brudd på tjenestenivå i bilag 4> | |
1.3.20 | Brukerstøtte Leverandøren skal ha brukerstøtte tilgjengelig for Kunden. | A | <Beskriv hvordan kravet er oppfylt.> | |
1.3.21 | Brukerstøtte – språk / løsning Leverandøren bør ha brukerstøtte tilgjengelig som snakker skandinavisk, og som er kjent med kundens løsning. | B | <Leverandøren bes beskrive sin tilbudte brukerstøtte, herunder åpningstider, responstider, oppfølging av saker, eskalering, tilbakemelding til kunde, hvordan kundens løsning gjøres kjent for brukerstøtte etc.> | |
1.3.22 | Responstid Løsningen bør ha god responstid på alle vanlige transaksjoner og handlinger. | B | <Beskriv løsningens responstider i normal drift. Angi eventuelle forutsetninger knyttet til Kundens utstyr, enheter eller nettverk.> | |
Nr. | Krav | Kravtyp e A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
Sikkerhet og personvern | ||||
1.3.23 | Tjenesten Tjenesten bør ivareta konfidensialitet, tilgjengelighet, robusthet og integritet. | B | <Leverandøren bes om å beskrive hvordan man sikrer konfidensialitet, tilgjengelighet og integritet i tjenesten. Områder som ønskes beskrevet er følgende (listen er ikke uttømmende): ✓ Sporbarhet ✓ Segregering ✓ Tilgangsstyring ✓ Tilgangskontroll ✓ Autentisering ✓ Kryptering av data (data at rest, data in use, data in transit) ✓ Nøkkelhåndtering ✓ Patching og vedlikehold Dersom Leverandøren anser det som nødvending, kan det vedlegges utvidet besvarelse.> | |
1.3.24 | Sårbarheter Leverandøren bør sørge for at tjenesten ikke inneholder kjente sårbarheter. | B | <Leverandøren bes beskrive hvordan tjenesten, til enhver tid, holdes oppdatert mot kjente sårbarheter> | |
1.3.25 | Cyberangrep Leverandøren bør ha etablerte tiltak og rutiner for å motvirke, detektere og håndtere cyberangrep. Eksempler på dette kan være: ✓ sikkerhetslogging ✓ overvåking og deteksjon ✓ rutiner for backup, restore ✓ hendelses- kontinuitets- og kriseplaner | B | <Leverandøren bes om å beskrive hvordan kravet er oppfylt>. | |
1.3.26 | Autentisering Tilbudt løsning bør støtte godkjent flerfaktor autentisering (MFA). SMS er ikke en godkjent metode for flerfaktorautentisering. | B | <Leverandøren bes om å beskrive hvilken type flerfaktorer (MFA) som oppfyller kravet> | |
1.3.27 | Backup Tjenesten bør tilby backup og lagring. | B | <Leverandøren bes om å beskrive hvordan lagring og backup håndteres i tjenesten> | |
Nr. | Krav | Kravtyp e A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.3.28 | Behandling av personopplysninger Dersom personopplysninger behandles utenfor EU/EØS, skal dette gjøres i henhold til gyldig overføringsgrunnlag, f.eks. sertifisert i henhold til DPF (Data Privacy Framework) eller SCC 2021 (Standard Contractual Clauses 2021). | A | <Vedlegg 5 Spørsmål – overføring personopplysninger skal besvares som dokumentasjon for kravoppfyllelsen> | |
1.3.29 | Sikkerhetstesting Kunden skal kunne gjennomføre sikkerhetstesting av løsningen i hele avtaleperioden. Leverandøren forplikter seg til å legge til rette for Kundens gjennomføring av sikkerhetstesting. Med sikkerhetstesting, menes: ✓ sårbarhetsscanning ✓ penetrasjonstesting ✓ web applikasjonstesting | A | <Leverandøren bes om å bekrefte at kravet er akseptert> | |
1.3.30 | Revisjoner Kunden skal kunne gjennomføre revisjoner av krav knyttet til sikkerhet og personvern i tjenesten i avtalens levetid. Leverandøren forplikter seg til å legge til rette for gjennomføring av Xxxxxxx rett til revisjoner. Revisjoner av Leverandørens etterlevelse av sikkerhet og personvern kan gjennomføres på følgende måter: ✓ revisjon gjennomføres av kunden ✓ revisjon gjennomføres av uavhengig tredjepart | A | <Leverandøren bes om å bekrefte at kravet er akseptert> |
Nr. | Krav | Kravtyp e A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.3.31 | Varsel om sikkerhetshendelser Leverandøren skal varsle Kunden uten ugrunnet opphold ved sikkerhetshendelser. Dette inkluderer alvorlige sårbarheter, dataangrep, datalekkasjer og personvernbrudd. Varsling skjer til oppgitt kontaktperson/kontaktpunkt hos kunden (oppgis i forbindelse med avtalsesignering). | A | <Leverandøren bes om å bekrefte at kravet er akseptert> |
1.4. Funksjonelle krav til løsningen
Nr. | Krav | Krav- type A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
Data | ||||
1.4.1 | Dataimport via aksesspunkt Løsningen må kunne hente inn data fra aksesspunkt(er) som kunden ønsker. | A | <Leverandøren bes om å beskrive hvordan kravet er oppfylt.> | |
1.4.2 | Hente ut datafeil i XML-fatkura Løsningen må ha funksjonalitet for å hente ut datafelt fra XML-faktura og matche dette mot en avtale. | A | <Leverandøren bes om å beskrive hvordan kravet er oppfylt.> | |
1.4.3 | Databerikelse og sammenstilling – forbruk/spend Løsningen må ha funksjonalitet for å sammenstille ulike datakilder (f.eks. Excel eller tilsvarende og XML- faktura fra aksesspunkt) for å kunne se forbruk på avtale- og rammeavtalenivå. | A | <Leverandøren bes om å beskrive hvordan kravet er oppfylt.> | |
Nr. | Krav | Krav- type A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.4.4 | Kategorisering - kategorier Løsningen skal kategorisere data på avtalenivå i kundens ønskede hoved- og underkategorier. | A | <Leverandøren bes om å beskrive hvordan kravet er oppfylt> | |
1.4.5 | Kategorisering – annen klassifisering Løsningen bør ha gode muligheter for klassifisering som følger en anerkjent standard for klassifisering av varer og tjenester (f.eks. UNSPSC). | B | <Leverandøren bes om å beskrive løsningens muligheter for klassifisering> | |
1.4.6 | Datakilder / dataimport Det er ønskelig at løsningen kan innhente data fra mange ulike datakilder. Blant annet fra følgende kilder: ✓ leverandørreskontro fra kundens økonomisystem (per i dag Agresso) ✓ regnskapsdata fra kundens økonomisystem ✓ avtaleinformasjon fra kontraktsarkiv ✓ kategori-definisjoner ✓ fakturadata (eksempelvis fakturabeløp og antall) i EHF- format, både dagens og det til enhver tid gjeldende EHF- format. ✓ eksterne offentlige kilder, eksempelvis innhenting av regnskapsdata og organisasjonsnummer ✓ utenlandske organisasjonsnummer | B | <Beskriv: ✓ hvilke datakilder løsningen kan hente data fra, samt ✓ det prinsipielle i metoden for import til løsningen ✓ hvilke filformater løsningen kan importere data fra> |
Nr. | Krav | Krav- type A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.4.7 | Fisjoner, fusjoner og oppkjøp av selskaper Det er ønskelig at løsningen har funksjonalitet for sammenstilling og spend/fakturering etter endringer, eksempelvis ✓ sammenstilling av spend/fakturering fra organisasjonsnummer før og etter en fusjon mellom to virksomheter og ✓ organisasjonsnummer under et felles konsern. Det er ønskelig at funksjonaliteten er knyttet opp mot Brønnøysundregisteret, og tilsvarende registre i utlandet. | B | <Leverandøren bes om å beskrive hvordan kravet er oppfylt.> | |
1.4.8 | Databehandling - vasking av data Løsningen bør kunne vaske og behandle/rette feil i data, eksempelvis leverandørnavn som i inn-data er stavet på forskjellige måter. Databehandling kan også være å hente ut deler av tekststreng. | B | <Beskriv mulighetene> | |
1.4.9 | Databehandling – krediteringer Det er ønskelig at løsningen håndterer krediteringer for å kunne justere spend. Dette gjelder også på varelinje-nivå (beløp, antall) ved helkreditering av faktura. | B | <Beskriv mulighetene> | |
1.4.10 | Databerikelse - generelt Det er ønskelig at løsningen tilbyr en fleksibel og omfangsrik mulighet for databerikelse med flere ulike kilder, for eksempel: ✓ data fra kunden og offentlig tilgjengelig leverandørinformasjon ✓ leverandører og avtaler med kritikalitet-klassifisering. | B | <Beskriv funksjonalitet for databerikelse som tilbys i løsningen.> |
Nr. | Krav | Krav- type A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.4.11 | Datahistorikk Løsningen bør ha funksjon for historikk og sporbarhet av leverandørdata og innkjøpsdata i form av PDF og XMLM-faktura. | B | <Beskriv hvordan kravet er oppfylt, og eventuelle begrensninger i antall år med historikk.> | |
Analyser/Rapporter/Dashboard | ||||
1.4.12 | Analyser/rapporter Det er ønskelig at løsningen gir et bredt tilbud av forhåndsdefinerte analyser og rapporter, herunder: ✓ kategorianalyse basert på kundens kategorier ✓ innkjøpenes sammensetning og utvikling (f.eks. per avtale/rammeavtale, kunde/kjøper, innkjøpskategori, leverandør og varelinje med tilhørende detaljer). ✓ avtaler (f.eks. varighet, verdi, kategori) ✓ leverandører (f.eks. avtaler, andeler, kategorier) ✓ som bidrar til å identifisere, planlegge og følge opp mulige kostnadsbesparelser. Løsningen bør ha ulike muligheter for søk, filtrering, samt å zoome inn/drille ned til detaljert informasjon. | B | <Beskriv analyse- og rapportfunksjonene i løsningen> | |
1.4.13 | Analyser/rapporter Det er ønskelig at løsningen gir mulighet for å definere egne analyser og rapporter. | B | <Beskriv mulighetene> | |
Nr. | Krav | Krav- type A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.4.14 | Dashboard Løsningen bør ha et brukervennlig dashboard som synliggjør relevante perspektiver på innkjøp i virksomheten. Det bør være mulig å velge forhåndsdefinerte dashboard som kan tilpasses den enkelte brukers behov. | B | <Beskriv løsningens dashboard. Beskriv forhåndsdefinerte dashboard, samt i hvilken grad disse kan tilpasses den enkelte brukers behov> | |
1.4.15 | Eksport Løsningen bør ha mulighet for eksport av data, f.eks. grunndata, analyser, dashboard og rapporter. Aktuelle formater er f.eks. PDF og Excel-lesbare formater. | B | <Beskriv hvilke muligheter løsningen har for eksport av data, og i hvilke formater> | |
1.4.16 | Leverandør- og avtalestyring Det bør være funksjonalitet i løsningen som legger til rette for leverandør- og avtalestyring med blant annet: ✓ leverandøroversikter og analyser av disse. ✓ avtaleoversikter og analyser av disse. ✓ måling og oppfølging av avtaledekning, avtalelojalitet og lekkasjer mm. ✓ mulighet for rapporter med varighet på avtaler, gjerne med eventuelle opsjoner. ✓ rapporter som bruker kundens egne klassifiseringer av både kategorier, leverandører og avtaler. | B | <Beskriv mulighetene i løsningen> | |
1.4.17 | Innkjøpsplan Det er ønskelig med en funksjonalitet som gir oversikt over planlagte og pågående anskaffelser. Datagrunnlaget kan f.eks. være kombinasjon av informasjon fra kunden. | B | <Beskriv mulighetene i løsningen> |
Nr. | Krav | Krav- type A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.4.18 | Prognoser på spend Det er ønskelig at løsningen har prognoser for spend på leverandører og avtaler fremover i tid, basert på historisk forbruk. | B | <Beskriv mulighetene i løsningen> | |
1.4.19 | Rapporter for manglende felt/data i data-sett Det er ønskelig at løsningen har mulighet for rapporter som viser manglende felt/data i ett datasett, og hvor mangelen er. Dette kan f.eks. være at det ikke står oppført en leverandør på en avtale, kontraktsverdi i ett ikke lesbart format samt andre formatfeil. | B | <Beskriv mulighetene i løsningen> |
1.5. Krav til aktsomhetsvurderinger
Nr. | Krav | Krav- type A/B | Krav oppfylt? ja/nei | Dokumentasjonskrav |
1.5.1 | Risikovurdering Løsningen må ha funksjon for vurdering av risiko for brudd på menneskerettigheter og anstendige arbeidsforhold i tråd med åpenhetsloven. | A | <Beskriv mulighetene i løsningen> | |
1.5.2 | Risikovurdering Løsningens kriterier for bør være etter anerkjent standard, og det bør i tillegg være mulighet for å legge til egne risikokriterier. | B | <Beskriv risikokriteriene som brukes, eksempelvis landrisiko, produktrisiko, leverandørrisiko, tjenesterisiko. Beskriv muligheten for å legge til egne risikokriterier.> | |
1.5.3 | Historikk og sporbarhet Løsningen bør ha funksjon for historikk og sporbarhet av aktsomhetsvurderingene. | B | <Beskriv mulighetene i løsningen> |
Nr. | Krav | Krav- type A/B | Krav oppfylt? ja/nei | Dokumentasjonskrav |
1.5.4 | Leverandøroppfølging Løsningen bør inneholde malverk/spørreskjema for oppfølging av leverandører, og muligheten for å legge til eget malverk for oppfølging av leverandørene. | B | <Beskriv mulighetene i løsningen> | |
1.5.5 | Leverandøroppfølging Løsningen bør kunne lagre dokumenter og svar fra leverandørene. | B | <Beskriv mulighetene i løsningen> |
1.6. Krav til klimagassberegninger
Nr. | Krav | Krav- type A/B | Krav oppfylt? ja/nei | Dokumentasjonskrav |
1.6.1 | Klimagassberegninger Løsningen må ha funksjon for å beregne klimagassutslipp i tråd med GHG-protokollen og ESRS. | A | <Beskriv mulighetene i løsningen> | |
1.6.2 | Klimagassberegninger av innkjøp Løsningen bør ha funksjon for automatisk utregning av klimagassutslipp koblet mot kundens innkjøp (spend- og aktivitetsbasert). | B | <Beskriv mulighetene i løsningen> | |
1.6.3 | Historikk og sporbarhet Løsningen bør ha funksjon for historikk og sporbarhet av tidligere registrerte klimagassutslipp. | B | <Beskriv mulighetene i løsningen> | |
1.6.4 | Utslippsfaktorer Løsningen bør benytte anerkjente og oppdaterte utslippsfaktorer. | B | <Beskriv hvilke kilder løsningen henter utslippsfaktorene fra og hvor ofte de oppdateres> |
1.7. Opplevd brukervennlighet
Nr. | Krav | Kravtype A/B | Krav oppf ylt? ja/nei | Dokumentasjonskrav |
1.7.1 | Navigering Den tilbudte tjenesten bør ha et moderne og intuitivt grensesnitt, med enkel og logisk navigering mellom felter og mellom ulike skjermbilder som følger hendelser. | B | <Leverandørens produktdemonstrasjon > |
Bilag 2: Leverandørens beskrivelse av tjenesten
<I tabellen nedenfor skal Leverandøren beskrive hvordan han oppfyller Kundens krav og behov beskrevet i Bilag 1. Instruksjonene til tilbyderen i kolonnen "Dokumentasjonskrav" erstattes med tilbyderens besvarelse.>
Avtalens punkt 1.1 Avtalens omfang
[Eventuell tekst]
Dersom det etter Leverandørens mening er åpenbare feil eller uklarheter i Kundens kravspesifikasjon skal Leverandøren påpeke dette her.
1.3. KRAV TIL LØSNINGEN
Nr. | Krav | Kravtyp e A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
Generelt | ||||
1.3.1 | Drifts- og forvaltningsmodell Den tilbudte løsningen skal leveres som en skytjeneste (SaaS). | A | <Leverandøren bes bekrefte at kravet er oppfylt, og beskrive hvilken driftsmodell som tilbys.> | |
1.3.2 | Tilbudt løsning Den tilbudte løsningen skal fremstå som ett samlet verktøy for brukere av løsningen. | A | <Leverandøren bes beskrive hvordan kravet er oppfylt> | |
1.3.3 | Webbasert løsning Løsningen bør være fullt ut webbasert, og det bør ikke være behov for at kundens brukere installerer plugins eller annen lignende programvare lokalt på kundens eget utstyr for å kunne benytte alle deler av løsningen fullt ut. | B | <Leverandøren bes beskrive hvordan kravet er oppfylt> | |
1.3.4 | Brukergrensesnitt og plattformuavhengighet Kunden benytter PC med nettleser som brukergrensesnitt for produksjon og databehandling. Løsningen bør være tilpasset alle digitale flater, samt støtte ulike nettlesere. | B | <Beskriv hvordan dette er ivaretatt i løsningen, og eventuelle ulike muligheter på PC og nettbrett/mobiltelefon.> | |
Nr. | Krav | Kravtyp e A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.3.5 | Tilgangsstyring og administrasjon Løsningen bør ha fleksibel og oversiktlig tilgangsstyring/rollestyring og administrasjon av brukere, roller, brukerkontoer og tilganger/visninger. | B | <Beskriv hvordan dette er løst.> | |
1.3.6 | Tredjeparts programvare Dersom den tilbudte tjenesten inkluderer standard tredjeparts programvare som må leveres under standard lisensbetingelser og avtalevilkår, bør dette være uttrykkelig angitt i Bilag 2. Kopi av lisensbetingelsene vedlegges i så fall tilbudet som Bilag 9. | B | <Dersom aktuelt: Beskrives i Bilag 2 og vedlegges i Bilag 9 Dersom tilbudt produkt inkluderer standard tredjeparts programvare som må leveres under standard lisensbetingelser og avtalevilkår, skal dette angis her. Kopi av lisensbetingelsene skal i så fall vedlegges tilbudet som Bilag 9.> | |
1.3.7 | Språk Alle tekster en bruker av løsningen eksponeres for, eller benytter bør være på norsk språk. | B | <Beskriv språket som benyttes i løsningen> | |
1.3.8 | Språk Alle tekster en administrator av løsningen eksponeres for eller benytter bør være på norsk, skandinavisk eller engelsk språk. | B | <Beskriv språket som benyttes i løsningen> | |
1.3.9 | Integrasjon regnskapssystem Det skal være mulig å integrere løsningen med kundens regnskapssystem (per i dag Unit4ERP) gjennom REST-API. | A | <Beskriv mulighetene> | |
1.3.10 | Krav til integrasjonsgrensesnitt Det er ønskelig at løsningen på en enkel måte kan integreres med andre systemer. | B | <Beskriv mulighetene for Integrasjoner> |
Nr. | Krav | Kravtyp e A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.3.11 | Prismodell Leverandøren bør ha en oversiktlig og forutsigbar prismodell. | B | Besvares i bilag 6: ✓ leverandøren bes beskrive hvordan prisen påvirkes av volum, herunder hvordan prisen påvirkes av antall aksesspunkter, fakturaer, kontrakter, leverandører, brukere etc., ✓ skalering av tjenesten, ✓ hvor snart prisendringer trer i kraft ved endringer, ✓ integrasjoner og ✓ hvordan prisen påvirkes av nyutviklet funksjonalitet bestilt av kunden | |
1.3.12 | EHF-felt i faktura fra leverandøren til kunden Leverandøren bør oppfylle kundens krav til bruk av EHF-felter i fakturering til kunden, jf. bilag 6, punkt 5.2 og 5.3. | B | <Beskriv hvilke EHF-felt under punkt 5.2 og 5.3 i bilag 6 som er mulig per i dag, hvilke alternativer leverandøren har for felt som mangler, og hvilke fremtidige planer leverandøren har for å oppfylle kravene til felt som mangler> | |
1.3.13 | Universell utforming Løsningen skal ivareta krav til universell utforming, jf. Forskrift om universell utforming av informasjons- og kommunikasjonsteknologiske | A | < Leverandøren skal beskrive hvordan kravene til universell utforming ivaretas i den tilbudte løsningen | |
Etablering | ||||
1.3.14 | Etablering - erfaring Leverandøren bør har god erfaring med etablering av tjenesten. | B | Leverandøren beskriver sin etableringsplan i bilag 3. Planen bør minimum inneholde: ✓ tidsplan med milepæler for etablering, konfigurering og levering ✓ planer for test, ✓ plan for opplæring, ✓ aktivitetsbeskrivelse ✓ planlagt fremdrift og ✓ anslått timeforbruk for leverandør og kunde i de ulike fasene ✓ plan med milepæler for betaling som er knyttet til leveranser i etableringsprosjektet Pris for den foreslåtte planen oppgis i bilag 6. | |
Nr. | Krav | Kravtyp e A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.3.15 | Historiske data fra andre systemer Løsningen må kunne importere historiske data fra andre systemer som en del av implementeringen. Tjenesten prises som en tilleggstjeneste etter medgått tid. | A | <Beskriv løsningens muligheter og begrensninger> | |
Feilhåndtering | ||||
1.3.16 | Feilsøk Leverandøren skal bekrefte at ved en eventuell feilsituasjon forplikter leverandøren seg til å samarbeide og feilsøke med kunden og eventuelt andre leverandører så lenge det er behov for det, selv om feilen ikke er Leverandørens ansvar. | A | <Leverandøren bes beskrive hvordan kravet oppfylles.> | |
1.3.17 | Logge feil Løsningen skal logge feil på en strukturert måte. | A | <Leverandøren bes beskrive hvordan kravet er oppfylt.> | |
SLA - Tjenestenivå | ||||
1.3.18 | Tjenestenivåavtale Leverandøren bør tilby god oppetid og gode responstider gjennom en tjenestenivåavtale. | B | <Leverandøren bes beskrive sin standard tjenestenivåavtale i bilag 4.> | |
1.3.19 | Kompensasjon ved brudd Ved brudd på tjenestenivå bør kunden har rett på kompensasjon. | B | <Leverandøren bes oppgi standardiserte kompensasjoner for brudd på tjenestenivå i bilag 4> | |
1.3.20 | Brukerstøtte Leverandøren skal ha brukerstøtte tilgjengelig for Kunden. | A | <Beskriv hvordan kravet er oppfylt.> | |
1.3.21 | Brukerstøtte – språk / løsning Leverandøren bør ha brukerstøtte tilgjengelig som snakker skandinavisk, og som er kjent med kundens løsning. | B | <Leverandøren bes beskrive sin tilbudte brukerstøtte, herunder åpningstider, responstider, oppfølging av saker, eskalering, tilbakemelding til kunde, hvordan kundens løsning gjøres kjent for brukerstøtte etc.> | |
Nr. | Krav | Kravtyp e A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.3.22 | Responstid Løsningen bør ha god responstid på alle vanlige transaksjoner og handlinger. | B | <Beskriv løsningens responstider i normal drift. Angi eventuelle forutsetninger knyttet til Kundens utstyr, enheter eller nettverk.> | |
Sikkerhet og personvern | ||||
1.3.23 | Tjenesten Tjenesten bør ivareta konfidensialitet, tilgjengelighet, robusthet og integritet. | B | <Leverandøren bes om å beskrive hvordan man sikrer konfidensialitet, tilgjengelighet og integritet i tjenesten. Områder som ønskes beskrevet er følgende (listen er ikke uttømmende): ✓ Sporbarhet ✓ Segregering ✓ Tilgangsstyring ✓ Tilgangskontroll ✓ Autentisering ✓ Kryptering av data (data at rest, data in use, data in transit) ✓ Nøkkelhåndtering ✓ Patching og vedlikehold Dersom Leverandøren anser det som nødvending, kan det vedlegges utvidet besvarelse.> | |
1.3.24 | Sårbarheter Leverandøren bør sørge for at tjenesten ikke inneholder kjente sårbarheter. | B | <Leverandøren bes beskrive hvordan tjenesten, til enhver tid, holdes oppdatert mot kjente sårbarheter> | |
1.3.25 | Cyberangrep Leverandøren bør ha etablerte tiltak og rutiner for å motvirke, detektere og håndtere cyberangrep. Eksempler på dette kan være: ✓ sikkerhetslogging ✓ overvåking og deteksjon ✓ rutiner for backup, restore ✓ hendelses- kontinuitets- og kriseplaner | B | <Leverandøren bes om å beskrive hvordan kravet er oppfylt>. | |
Nr. | Krav | Kravtyp e A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.3.26 | Autentisering Tilbudt løsning bør støtte godkjent flerfaktor autentisering (MFA). SMS er ikke en godkjent metode for flerfaktorautentisering. | B | <Leverandøren bes om å beskrive hvilken type flerfaktorer (MFA) som oppfyller kravet> | |
1.3.27 | Backup Tjenesten bør tilby backup og lagring. | B | <Leverandøren bes om å beskrive hvordan lagring og backup håndteres i tjenesten> | |
1.3.28 | Behandling av personopplysninger Dersom personopplysninger behandles utenfor EU/EØS, skal dette gjøres i henhold til gyldig overføringsgrunnlag, f.eks. sertifisert i henhold til DPF (Data Privacy Framework) eller SCC 2021 (Standard Contractual Clauses 2021). | A | <Vedlegg 5 Spørsmål – overføring personopplysninger skal besvares som dokumentasjon for kravoppfyllelsen> | |
1.3.29 | Sikkerhetstesting Kunden skal kunne gjennomføre sikkerhetstesting av løsningen i hele avtaleperioden. Leverandøren forplikter seg til å legge til rette for Kundens gjennomføring av sikkerhetstesting. Med sikkerhetstesting, menes: ✓ sårbarhetsscanning ✓ penetrasjonstesting ✓ web applikasjonstesting | A | <Leverandøren bes om å bekrefte at kravet er akseptert> |
Nr. | Krav | Kravtyp e A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.3.30 | Revisjoner Xxxxxx skal kunne gjennomføre revisjoner av krav knyttet til sikkerhet og personvern i tjenesten i avtalens levetid. Leverandøren forplikter seg til å legge til rette for gjennomføring av Xxxxxxx rett til revisjoner. Revisjoner av Leverandørens etterlevelse av sikkerhet og personvern kan gjennomføres på følgende måter: ✓ revisjon gjennomføres av kunden ✓ revisjon gjennomføres av uavhengig tredjepart | A | <Leverandøren bes om å bekrefte at kravet er akseptert> | |
1.3.31 | Varsel om sikkerhetshendelser Leverandøren skal varsle Kunden uten ugrunnet opphold ved sikkerhetshendelser. Dette inkluderer alvorlige sårbarheter, dataangrep, datalekkasjer og personvernbrudd. Varsling skjer til oppgitt kontaktperson/kontaktpunkt hos kunden (oppgis i forbindelse med avtalsesignering). | A | <Leverandøren bes om å bekrefte at kravet er akseptert> |
1.4 Funksjonelle krav til løsningen
Nr. | Krav | Krav- type A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
Data | ||||
1.4.1 | Dataimport via aksesspunkt Løsningen må kunne hente inn data fra aksesspunkt(er) som kunden ønsker. | A | <Leverandøren bes om å beskrive hvordan kravet er oppfylt.> | |
Nr. | Krav | Krav- type A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.4.2 | Hente ut datafeil i XML-fatkura Løsningen må ha funksjonalitet for å hente ut datafelt fra XML-faktura og matche dette mot en avtale. | A | <Leverandøren bes om å beskrive hvordan kravet er oppfylt.> | |
1.4.3 | Databerikelse og sammenstilling – forbruk/spend Løsningen må ha funksjonalitet for å sammenstille ulike datakilder (f.eks. Excel eller tilsvarende og XML- faktura fra aksesspunkt) for å kunne se forbruk på avtale- og rammeavtalenivå. | A | <Leverandøren bes om å beskrive hvordan kravet er oppfylt.> | |
1.4.4 | Kategorisering - kategorier Løsningen skal kategorisere data på avtalenivå i kundens ønskede hoved- og underkategorier. | A | <Leverandøren bes om å beskrive hvordan kravet er oppfylt> | |
1.4.5 | Kategorisering – annen klassifisering Løsningen bør ha gode muligheter for klassifisering som følger en anerkjent standard for klassifisering av varer og tjenester (f.eks. UNSPSC). | B | <Leverandøren bes om å beskrive løsningens muligheter for klassifisering> |
Nr. | Krav | Krav- type A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.4.6 | Datakilder / dataimport Det er ønskelig at løsningen kan innhente data fra mange ulike datakilder. Blant annet fra følgende kilder: ✓ leverandørreskontro fra kundens økonomisystem (per i dag Agresso) ✓ regnskapsdata fra kundens økonomisystem ✓ avtaleinformasjon fra kontraktsarkiv ✓ kategori-definisjoner ✓ fakturadata (eksempelvis fakturabeløp og antall) i EHF- format, både dagens og det til enhver tid gjeldende EHF- format. ✓ eksterne offentlige kilder, eksempelvis innhenting av regnskapsdata og organisasjonsnummer ✓ utenlandske organisasjonsnummer | B | <Beskriv: ✓ hvilke datakilder løsningen kan hente data fra, samt ✓ det prinsipielle i metoden for import til løsningen ✓ hvilke filformater løsningen kan importere data fra> | |
1.4.7 | Fisjoner, fusjoner og oppkjøp av selskaper Det er ønskelig at løsningen har funksjonalitet for sammenstilling og spend/fakturering etter endringer, eksempelvis ✓ sammenstilling av spend/fakturering fra organisasjonsnummer før og etter en fusjon mellom to virksomheter og ✓ organisasjonsnummer under et felles konsern. Det er ønskelig at funksjonaliteten er knyttet opp mot Brønnøysundregisteret, og tilsvarende registre i utlandet. | B | <Leverandøren bes om å beskrive hvordan kravet er oppfylt.> |
Nr. | Krav | Krav- type A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.4.8 | Databehandling - vasking av data Løsningen bør kunne vaske og behandle/rette feil i data, eksempelvis leverandørnavn som i inn-data er stavet på forskjellige måter. Databehandling kan også være å hente ut deler av tekststreng. | B | <Beskriv mulighetene> | |
1.4.9 | Databehandling – krediteringer Det er ønskelig at løsningen håndterer krediteringer for å kunne justere spend. Dette gjelder også på varelinje-nivå (beløp, antall) ved helkreditering av faktura. | B | <Beskriv mulighetene> | |
1.4.10 | Databerikelse - generelt Det er ønskelig at løsningen tilbyr en fleksibel og omfangsrik mulighet for databerikelse med flere ulike kilder, for eksempel: ✓ data fra kunden og offentlig tilgjengelig leverandørinformasjon ✓ leverandører og avtaler med kritikalitet-klassifisering. | B | <Beskriv funksjonalitet for databerikelse som tilbys i løsningen.> | |
1.4.11 | Datahistorikk Løsningen bør ha funksjon for historikk og sporbarhet av leverandørdata og innkjøpsdata i form av PDF og XMLM-faktura. | B | <Beskriv hvordan kravet er oppfylt, og eventuelle begrensninger i antall år med historikk.> |
Nr. | Krav | Krav- type A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
Analyser/Rapporter/Dashboard | ||||
1.4.12 | Analyser/rapporter Det er ønskelig at løsningen gir et bredt tilbud av forhåndsdefinerte analyser og rapporter, herunder: ✓ kategorianalyse basert på kundens kategorier ✓ innkjøpenes sammensetning og utvikling (f.eks. per avtale/rammeavtale, kunde/kjøper, innkjøpskategori, leverandør og varelinje med tilhørende detaljer). ✓ avtaler (f.eks. varighet, verdi, kategori) ✓ leverandører (f.eks. avtaler, andeler, kategorier) ✓ som bidrar til å identifisere, planlegge og følge opp mulige kostnadsbesparelser. Løsningen bør ha ulike muligheter for søk, filtrering, samt å zoome inn/drille ned til detaljert informasjon. | B | <Beskriv analyse- og rapportfunksjonene i løsningen> | |
1.4.13 | Analyser/rapporter Det er ønskelig at løsningen gir mulighet for å definere egne analyser og rapporter. | B | <Beskriv mulighetene> | |
1.4.14 | Dashboard Løsningen bør ha et brukervennlig dashboard som synliggjør relevante perspektiver på innkjøp i virksomheten. Det bør være mulig å velge forhåndsdefinerte dashboard som kan tilpasses den enkelte brukers behov. | B | <Beskriv løsningens dashboard. Beskriv forhåndsdefinerte dashboard, samt i hvilken grad disse kan tilpasses den enkelte brukers behov> | |
Nr. | Krav | Krav- type A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.4.15 | Eksport Løsningen bør ha mulighet for eksport av data, f.eks. grunndata, analyser, dashboard og rapporter. Aktuelle formater er f.eks. PDF og Excel-lesbare formater. | B | <Beskriv hvilke muligheter løsningen har for eksport av data, og i hvilke formater> | |
1.4.16 | Leverandør- og avtalestyring Det bør være funksjonalitet i løsningen som legger til rette for leverandør- og avtalestyring med blant annet: ✓ leverandøroversikter og analyser av disse. ✓ avtaleoversikter og analyser av disse. ✓ måling og oppfølging av avtaledekning, avtalelojalitet og lekkasjer mm. ✓ mulighet for rapporter med varighet på avtaler, gjerne med eventuelle opsjoner. ✓ rapporter som bruker kundens egne klassifiseringer av både kategorier, leverandører og avtaler. | B | <Beskriv mulighetene i løsningen> | |
1.4.17 | Innkjøpsplan Det er ønskelig med en funksjonalitet som gir oversikt over planlagte og pågående anskaffelser. Datagrunnlaget kan f.eks. være kombinasjon av informasjon fra kunden. | B | <Beskriv mulighetene i løsningen> | |
1.4.18 | Prognoser på spend Det er ønskelig at løsningen har prognoser for spend på leverandører og avtaler fremover i tid, basert på historisk forbruk. | B | <Beskriv mulighetene i løsningen> |
Nr. | Krav | Krav- type A/B | Krav oppfylt ? ja/nei | Dokumentasjonskrav |
1.4.19 | Rapporter for manglende felt/data i data-sett Det er ønskelig at løsningen har mulighet for rapporter som viser manglende felt/data i ett datasett, og hvor mangelen er. Dette kan f.eks. være at det ikke står oppført en leverandør på en avtale, kontraktsverdi i ett ikke lesbart format samt andre formatfeil. | B | <Beskriv mulighetene i løsningen> |
1.5 Krav til aktsomhetsvurderinger
Nr. | Krav | Krav- type A/B | Krav oppfylt? ja/nei | Dokumentasjonskrav |
1.5.1 | Risikovurdering Løsningen må ha funksjon for vurdering av risiko for brudd på menneskerettigheter og anstendige arbeidsforhold i tråd med åpenhetsloven. | A | <Beskriv mulighetene i løsningen> | |
1.5.2 | Risikovurdering Løsningens kriterier for bør være etter anerkjent standard, og det bør i tillegg være mulighet for å legge til egne risikokriterier. | B | <Beskriv risikokriteriene som brukes, eksempelvis landrisiko, produktrisiko, leverandørrisiko, tjenesterisiko. Beskriv muligheten for å legge til egne risikokriterier.> | |
1.5.3 | Historikk og sporbarhet Løsningen bør ha funksjon for historikk og sporbarhet av aktsomhetsvurderingene. | B | <Beskriv mulighetene i løsningen> | |
1.5.4 | Leverandøroppfølging Løsningen bør inneholde malverk/spørreskjema for oppfølging av leverandører, og muligheten for å legge til eget malverk for oppfølging av leverandørene. | B | <Beskriv mulighetene i løsningen> |
Nr. | Krav | Krav- type A/B | Krav oppfylt? ja/nei | Dokumentasjonskrav |
1.5.5 | Leverandøroppfølging Løsningen bør kunne lagre dokumenter og svar fra leverandørene. | B | <Beskriv mulighetene i løsningen> |
1.6 Krav til klimagassberegninger
Nr. | Krav | Krav- type A/B | Krav oppfylt? ja/nei | Dokumentasjonskrav |
1.6.1 | Klimagassberegninger Løsningen må ha funksjon for å beregne klimagassutslipp i tråd med GHG-protokollen og ESRS. | A | <Beskriv mulighetene i løsningen> | |
1.6.2 | Klimagassberegninger av innkjøp Løsningen bør ha funksjon for automatisk utregning av klimagassutslipp koblet mot kundens innkjøp (spend- og aktivitetsbasert). | B | <Beskriv mulighetene i løsningen> | |
1.6.3 | Historikk og sporbarhet Løsningen bør ha funksjon for historikk og sporbarhet av tidligere registrerte klimagassutslipp. | B | <Beskriv mulighetene i løsningen> | |
1.6.4 | Utslippsfaktorer Løsningen bør benytte anerkjente og oppdaterte utslippsfaktorer. | B | <Beskriv hvilke kilder løsningen henter utslippsfaktorene fra og hvor ofte de oppdateres> |
1.7 Opplevd brukervennlighet
Nr. | Krav | Kravtype A/B | Krav oppf ylt? ja/nei | Dokumentasjonskrav |
1.7.1 | Navigering Den tilbudte tjenesten bør ha et moderne og intuitivt grensesnitt, med enkel og logisk navigering mellom felter og mellom ulike skjermbilder som følger hendelser. | B | <Leverandørens produktdemonstrasjon > |
Bilag 3: Plan for etableringsfasen
Avtalens punkt 3.1 Plan for etableringsfasen
<Leverandøren beskriver sin etableringsplan her, jf. krav 1.3.14:
Planen bør minimum inneholde
✓ Tidsplan med milepæler for etablering, konfigurering og levering,
✓ planer for test,
✓ plan for opplæring,
✓ aktivitetsbeskrivelse,
✓ planlagt fremdrift og
✓ anslått timeforbruk for Leverandør og Kunde i de ulike fasene,
✓ plan med milepæler for betaling som er knyttet til leveranser i etableringsprosjektet.>
Avtalens punkt 3.3 Godkjenningsprøve og leveringsdag
Henvisning til avtalens punkt og evt. avsnitt | Erstattes med |
3.3 Godkjenningsprøve og leveringsdag, 1. avsnitt | Dersom ikke annet er avtalt i bilag 3, skal Kunden undersøke tjenesten i en periode på 20 (tjue) virkedager fra første virkedag etter at Leverandøren har sendt leveransemelding til Kunden (godkjenningsprøven). |
Bilag 4: Tjenestenivå med standardiserte kompensasjoner
<Leverandøren bes beskrive sin standard tjenestenivåavtale her, jf. krav 1.3.18>
<Leverandøren bes oppgi standardiserte kompensasjoner for brudd på tjenestenivå her, jf. krav 1.3.19 >
Bilag 5: Administrative bestemmelser
Avtalens punkt 1.5 Partenes representanter
[Eventuell tekst]
Fylles ut i forbindelse med avtalesignering.
Avtalens punkt 6.2 Personopplysninger
[Eventuell tekst]
Xxxxxx Xxxxxx godkjenner at personopplysninger behandles av Leverandørens underleverandør(er), skal navnene på underleverandør(er) fremkomme her.
Avtalens punkt 11.2. Lønns- og arbeidsvilkår
[Eventuell tekst]
Dersom det foreligger allmenngjort tariffavtale eller landsomfattende tariffavtale for den aktuelle bransje kontrakten gjelder skal dokumentasjon av Leverandørens oppfyllelse av forpliktelser som nevnt i avtalens punkt 11.2 (Lønns- og arbeidsvilkår) fremkomme her.
Dokumentasjonen kan bestå av en egenerklæring eller en tredjepartserklæring om at det er samsvar mellom aktuell tariffavtale og faktiske lønns- og arbeidsvilkår for oppfyllelse av Leverandørens og eventuelle underleverandørers forpliktelser.
Dersom Kunden ønsker å angi nærmere presiseringer om gjennomføring av avtalens punkt 11.2, skal dette fremkomme av bilag 5.
Bilag 6: Samlet pris og prisbestemmelser
1 PRISER
Enhet | Pris ekskl. mva. |
Pris etablering, jf. krav 1.3.14 | <NOK> |
Årlig kostnad for bruk av løsningen – tjenesteavgift, jf. punkt 1.2.2 Omfang. | <NOK> |
Opsjon: Årlig kostnad per ekstra bruker | <NOK> |
Opsjon: Etableringskostnad ekstra datakilde - kundens data | <NOK> |
Opsjon: Årlig kostnad ekstra datakilde - kundens data | <NOK> |
Opsjon: Etableringskostnad ekstra aksesspunkt/datakilde | <NOK> |
Opsjon: Årlig kostnad ekstra aksesspunkt/datakilde | <NOK> |
Opsjon: Årlig kostnad innhenting av forbruksdata fra helseforvaltningen, jf. punkt 1.2.2 Omfang | <NOK> |
<Alle eventuelle moduler, samt pris per modul som inngår i tilbudet oppgis her>
<Xxxxxx inkluderte aksesspunkter oppgis her>
2 PRISMODELL
<Leverandøren beskriver sin prismodell her, jf. kravtabellens punkt 1.3.11. Leverandøren bes beskrive hvordan prisen påvirkes av
✓ volum, herunder hvordan prisen påvirkes av antall aksesspunkter, fakturaer, kontrakter, leverandører, brukere etc.
✓ skalering av tjenesten,
✓ hvor snart prisendringer trer i kraft ved endringer,
✓ integrasjoner og
✓ hvordan prisen påvirkes av nyutviklet funksjonalitet bestilt av kunden.
3 TILLEGGSTJENESTER
Enhet | Pris ekskl. mva. |
Timepris seniorkonsulent (minimum 4 års relevant erfaring) | <NOK> |
Timepris konsulent (minimum 2 års relevant erfaring) | <NOK> |
4 PRISREGULERING
Prisregulering kan tidligst skje ett år etter kontraktsinngåelse. Se for øvrig den punkt 4.5 i den generelle avtaleteksten.
5 Fakturering
5.1 Adressering
Faktureringen skal følge standardiserte formater og kommunikasjonsløsning for E-faktura. Elektronisk adresse er: 994 598 759 (NHN Organisasjonsnummer)
For leverandører utenfor Norge benyttes prefix 9908 for adressering av NHN i PEPPOL.
5.2 Fakturahode for varer og tjenester
Fakturainformasjonen skal fremkomme både i PDF-vedlegget til e-faktura og i EHF3.0-filen (XML). Felt innhold (markert i grønt) oppgis etter signering.
Faktura merking | Felt innhold | Spesifikasjon av felt i EHF 3.0 |
Bestillingsreferanse, referanseperson | Bestillingsnummer og/eller fornavn og etternavn på bestiller | OrderReference/ID |
NHN Avtalenummer | <24/00000> | ContractDocumentReference/ID * |
Fakturaperiode, start | <YYYY-MM-DD) | InvoicePeriod/StartDate |
Fakturaperiode, slutt | <YYYY-MM-DD) | InvoicePeriod/End |
* Dersom leverandøren ikke har mulighet umiddelbart til å benytte ContractDocumentReference/ID, er det mulighet for å benytte BuyerReference.
5.3 Fakturalinjer ifm. fakturering av varer og tjenester
Fakturainformasjonen skal fremkomme både i PDF-vedlegget til e-faktura og i EHF3.0-filen (XML).
Faktura merking | Felt innhold | Spesifikasjon av felt i EHF 3.0 |
Tjeneste/varenummer | <Produsentens SKU / Leverandørens vnr.> | InvoiceLine/Item/SellersItemIdentification |
Beskrivelse | <Navn på levert vare/tjeneste> | InvoiceLine/Item/Description |
Antall | <Fakturerte enheter> | InvoiceLine/InvoicedQuantity |
Pris | <Avtalt pris> | InvoiceLine/Price/PriceAmount |
Beløp | <Pris * Antall timer> | InvoiceLine/AllowanceCharge/Amount |
Bilag 7: Endringer i den generelle avtaleteksten
Ikke relevant.
Bilag 8: Endringer av tjenesten etter avtaleinngåelsen
Avtalens punkt 1.4 Endringer av tjenesten etter avtaleinngåelsen
Eksempel på endringskatalog:
[Eventuell tekst]
Dette bilaget skal ikke fylles ut før avtaleinngåelse, men må ligge ved selv om det foreløpig er tomt.
Dersom Kunden og Leverandøren har kommet til enighet om en endringsavtale (både i forhold til innhold, eventuelt endring i vederlag og endring i tidsplan), skal endringen (innhold, justert vederlag og justert tidsplan) fremkomme her.
Hver endring skal være underskrevet av bemyndiget representant for partene.
Det er Leverandøren som er ansvarlig for at det føres en fortløpende katalog over endringene som utgjør bilag 8. Leverandøren er også ansvarlig for at Kunden uten ugrunnet opphold gis en oppdatert kopi. Kunden må selv holde oversikt over hvilke endringsanmodninger de har sendt og hvilke endringsoverslag de har mottatt.
Xxxxxx er ansvarlig for at endringene det er anmodet om ikke er i strid med regelverket for offentlige anskaffelser. Endringer som anses som vesentlige vil kunne bli betraktet som en ulovlig direkte anskaffelse. Ulovlige direkteanskaffelser er sanksjonsbelagt med et overtredelsesgebyr på inntil 15 % av den ulovlige anskaffelsens verdi. Kontrakten kan også kjennes «uten virkning»
Endringsnummer | Beskrivelse av endringen samt eventuell vederlagsjustering og justering av tidsplan | Ikraftsettelsesdato |
Bilag 9: Vilkår for Kundens tilgang og bruk av tredjepartsleveranser
Avtalens punkt 2.2 Leverandørens ansvar for tredjepartsleveranser
[Eventuell tekst]
I den grad tredjepartsleveranser er inkludert i tjenestene fra Leverandøren, skal kopi av vilkårene for Kundens tilgang og bruk av tredjepartsleveransene være vedlagt her. Alternativt kan Leverandøren angi en lenke til vilkårene her. Vilkårene er bindende for Kunden. I en anskaffelse kan vilkårene gjøres til gjenstand for evaluering.
Eksempel på tabell over tredjepartsleveranser
Tredjepart | Kort beskrivelse av tjenesten som leveres fra tredjepart | Referanse til vilkår som er bindende for kunden (kan være en lenke) |
Leverandøren skal her, så godt som man kan forvente av en profesjonell leverandør, beskrive hvilke forpliktelser vilkårene pålegger Kunden og hvilke ansvarsbegrensninger tredjepart forbeholder seg. Dette skal ikke være urimelig byrdefullt for Leverandøren og må tilpasses den enkelte leveranses kompleksitet. Det må også tilpasses den enkelte tredjepartsleveranse og hvor kritisk/risikofull denne er inn i leveransen. Leverandøren skal spesielt påpeke i hvilken grad og i hvilke situasjoner tredjepart vil foreta feilretting, samt hvilke garantier og SLA-krav som gjelder. Det er også viktig å påpeke eventuelle uvanlige eller byrdefulle reguleringer.