Om oppdraget

Formålet er å anskaffe en skybasert (SaaS) løsning som i størst mulig grad kan bidra til at Kunden kan ivareta lov- og forskriftskrav knyttet til Norgesmodellen, herunder kravene til elektronisk mannskapsliste i byggherreforskriften § 15, kontrollforpliktelsene knyttet til blant annet lønns- og arbeidsvilkår, samt oppfølging av Oslomodellens seriøsitetskrav.

Kunden skal i løpet av 2026 revidere seriøsitetskravene, hvilket kan medfører endringer i kommunens oppfølgingsbehov. Løsningen skal derfor være fleksibel og skalerbar for kommunen. Dette innebærer blant annet at Kunden:

* Kan anvende løsningen på de avtaleområder som er særlig utsatt i forhold til arbeidslivskriminalitet og sosial dumping, både nå og i fremtiden

* Kan samarbeide med andre offentlige myndigheter i oppfølgningen av arbeidslivskriminalitet og sosial dumping

* Kan ivareta andre behov som er nært knyttet til denne type oppfølgning

Løsningen skal være bygget for høy tilgjengelighet, ivaretakelse av personvern samt støtte automatisert databehandling i sanntid der det er mulig, slik at Kunden kan ivareta sitt ansvar på en effektiv og sikker måte. Løsningen bør samtidig være brukervennlig med lav responstid, enkel navigasjon og arbeidsflyt, begrenset risiko for feilregistreringer samt fleksibel ift. sammenstilling og visualisering av relevant data.

For mer informasjon om Kunden samt formål og omfang henvise det SSA-L, bilag 1.

Tjenesteområde

• Programvare, IT-systemer, software 48000000
• Bransjeprogramvare 48100000
• Software-related services 72260000
• Programvareverktøy 48700000
• Compliance software package 48170000

Tildelingskriterier

Tilbudsstrategi

• Pris teller 30 %. Prisbildet bør være konkurransedyktig og lett å kontrollere.
• Kvalitet teller 50 %. Bruk relevante referanser og beskriv konkret gjennomføring.
• Kvalitet teller 6.6 %. Bruk relevante referanser og beskriv konkret gjennomføring.
• Kvalitet teller 6.7 %. Bruk relevante referanser og beskriv konkret gjennomføring.
• Kvalitet teller 6.7 %. Bruk relevante referanser og beskriv konkret gjennomføring.
• Kvalitet – uvesentlig klimaavtrykk og miljøbelastning (begrunnes under) teller 0 %. Tallfest miljøeffekt, transport, materialvalg og andre målbare tiltak.

Historikk hos oppdragsgiver

Basert på strukturerte tildelingskunngjøringer i Anbudsradar. Listen kan være ufullstendig der eldre kunngjøringer mangler leverandørdata.

Se full oppdragsgiverprofil for Oslo Kommune v/ Økonomi- Og Forvaltningsetaten

Leverandører oppdragsgiver ofte har tildelt kontrakter til

• Culina Norge AS2 tildelinger · sist 22.05.2026 · Ikke oppgitt
• Manpower AS2 tildelinger · sist 13.04.2026 · Ikke oppgitt
• Adecco Norge AS2 tildelinger · sist 23.02.2026 · Ikke oppgitt
• Pedagogisk VikarSentral AS2 tildelinger · sist 23.02.2026 · Ikke oppgitt
• Studentconsulting Norge AS1 tildelinger · sist 13.04.2026 · Ikke oppgitt
• Randstad AS1 tildelinger · sist 13.04.2026 · Ikke oppgitt

Spørsmål du bør vurdere å stille oppdragsgiver

AI-genererte forslag basert på konkurransedokumentene. Still spørsmålene i spørsmålsrunden i konkurransegjennomføringsverktøyet før tilbudsfrist. Vurder selv hvilke som er relevante for ditt tilbud.

• I vedlegg 2 (Leverandørens beskrivelse av tjenesten) og Bilag 1 (Kundens kravspesifikasjon) fremgår det at alle krav skal besvares med «Ja» eller «Nei», og at eventuelle «X» i kolonnen for «Utvikling/tilpasning» påvirker pris og uttelling. Kan dere bekrefte hvordan leverandøren skal fylle ut krav som delvis løses (dvs. både standardfunksjonalitet og noe utvikling), og om leverandøren da skal svare «Ja» med utdyping, eller «Nei» dersom deler krever utvikling som går utover konfigurering?

  For å unngå feil svarsmåte i kravtabellen og risiko for avvisning eller lavere uttelling, må leverandøren forstå hvordan deloppfyllelse skal håndteres i «Ja/Nei»-logikken.

  Bilag 1, vedlegg 1 – «Leverandørens oppfyllelse (Oppfylt)», «Utvikling/tilpasning» samt Bilag 2 (fremgangsmåte for besvarelse).
• Kravet om at leverandøren innen første tilbudsfrist skal gi Kunden tilgang til demobrukere (min. 10 samtidige brukere) er nevnt i kravspesifikasjonen. Kan dere bekrefte: (1) når i tid demotilgangen må være tilgjengelig (dato/klokkeslett), (2) om det er krav til konkret demo-innhold/brukscenarier, og (3) om demomiljøet må være «låst» uten endringer etter frist, eller om oppdatert demo er tillatt så lenge vedlegget oppdateres?

  Leverandøren trenger dette for å planlegge ressursbruk, teknisk løsning og korrekt dokumentasjon rundt demo og eventuelle endringer etter frist.

  Bilag 1, vedlegg 1 – «Tilgang til løsning».
• I Bilag 3 (Plan for etableringsfasen) fremgår det at Kunden vil bruke 20 arbeidsdager til godkjenningsprøve (avviker fra standard 10 dager), og at oppstart av godkjenningsprøve forutsetter flere inngangskriterier (samlet test, leveransemelding, tilgjengelighet mv.). Kan dere presisere hvordan dere vurderer «avtalte kriterier for oppstart» (hvilken dokumentasjon/leveranser regnes som tilstrekkelig), og om det finnes en standard mal for leveransemelding som leverandøren må følge?

  For å unngå tvist om når godkjenningsprøven kan starte og hvem som er ansvarlig for manglende grunnlag, bør leverandøren få avklart forventet dokumentasjonsnivå og prosedyre.

  Bilag 3 – «Leveransefrist og leveransemelding» samt «Godkjenningsprøve og leveringsdag».
• Tilgjengelighetsgarantien i Bilag 4 er angitt som minst 99,7 % per kalendermåned. Kan dere bekrefte (1) hvilke hendelser som gir fratrekk/ikke fratrekk i beregningen av oppetid, (2) hvordan planlagt vedlikehold utenom ordinær arbeidstid behandles i målingen, og (3) hvordan dere måler/rapporterer tilgjengelighet (verktøy/kilde til statistikk) og om leverandøren må dokumentere historikk i et bestemt format?

  Oppetidsmåling og avgrensning av hendelser påvirker både risiko og prising av tjenestenivå/standardiserte kompensasjoner.

  Bilag 4 – «Garanti for tilgjengelighet-/oppetid».
• Bilag 4 omtaler responstider i løsningen (visning/uttrekk av oversiktslister og «enkelt datainnputt») og rutiner for feil/eskalering, men konkrete responstidsmål/satser og feilrettingsfrister ligger ikke i utdraget. Kan dere utdype hvilke konkrete SLA-/responstidsmål og frister dere vil evaluere og kompensere mot (med definisjoner av hva som er måltidspunkt, målenheter og hvilke samtidighetsforutsetninger som gjelder)?

  Leverandøren kan ikke prise korrekt eller dimensjonere kapasitet uten presise SLA-definisjoner og målverdier knyttet til konkrete hendelsestyper.

  Bilag 4 – «Garanti for responstider i løsningen» og «Øvrige garantier og tjenestenivå».
• Dere beskriver at løsningen skal støtte integrasjon til Entra ID/SSO og integrasjoner til «adgangskontrollsystemer» via API/datagrensesnitt, og at leverandøren skal sette opp og teste integrasjonene. Kan dere bekrefte hvilke konkrete integrasjonsgrensesnitt dere forventer (f.eks. REST/GraphQL, SAML/OIDC for SSO, datamodell/roller for adgangskontroll), og om det finnes dokumentasjon/maler for API-dokumentasjon og testkriterier som dere ønsker at leverandøren følger?

  Integrasjonsomfanget påvirker både utviklingsinnhold, testopplegg og risiko for forsinkelse og kostnader i etableringsfasen.

  Bilag 1 – Kundens krav/leveranser L3-L4 («Oppsett og test av integrasjon for sentral brukeradministrasjon (Entra ID) og SSO» og «Oppsett og test av integrasjoner til interne/eksterne adgangskontrollsystemer»), samt Bilag 3 og Bilag 9 (tredjepartsleveranser).
• I Bilag 1 (Kundens kravspesifikasjon) er det listet tilleggsbehov som kan utvides i avtaleperioden (integrasjon til kontraktadministrasjon og saks-/arkiv, innebygd arkivering, verifisering av seriøsitetsdokumentasjon, risikovurderinger, hendelser, miljø, månedsrapportering). Kan dere beskrive prosedyren for hvordan slike tilleggsbehov prioriteres og bestilles (f.eks. endringsavtale vs. bestilling etter tid), inkludert hvem som godkjenner estimat og når i tid dette skjer?

  Leverandøren må vite bestillings-/endringsmekanismen og godkjenningsløypa for å kunne prise og planlegge leveransekonsistens i avtaleperioden.

  Bilag 1 – «Tilleggsbehov» samt SSA-L/SSA-L punkt 3.6 («Ytterligere utvikling etter Leveringsdag») og Bilag 6 «Ytterligere utvikling etter Leveringsdag».
• Avtaleteksten og Bilag 6 beskriver prisfastsetting, prisendringer (KPI) og timepriser for bistand etter leveringsdag. Kan dere bekrefte (1) om det finnes pris-/volumtak eller andre kapper for løpende tjeneste eller bistand, (2) hvordan «skalerbarhet» ved reduksjon av antall brukere/funksjonalitet er ment å fungere i praksis (hvilke parametere som gir reduksjon og hvordan det avregnes), og (3) om det er separate priser for leverandører/underleverandører som bruker løsningen kostnadsfritt (i Bilag 6 står det kostnadsfritt, men vi ønsker avklart hvordan det håndheves i prisskjemaet)?

  Korrekt prising og modellering av fremtidige avrop/kapasitetsbehov krever avklaring av hvilke prisparametere som styrer kost og eventuell reduksjon ved lavere bruk.

  Bilag 6 – «Vederlag», «Prisendringer», «Ytterligere utvikling etter Leveringsdag» samt SSA-L punkt 5.2 (avbestilling) om skalerbarhet.
• I SSA-L (generell avtaletekst) og Bilag 7 er det lagt inn flere nye/endrede bestemmelser om revisjon og stedlig kontroll, krav til elektronisk betaling, elektronisk utbetaling av lønn, samt krav om begrensning i antall ledd underleverandører. Kan dere bekrefte hvordan dette skal forstås for en SaaS-leverandør (typisk dere vil ikke ha «medvirkende arbeideres» lønn/innkvartering mv.)—for eksempel hvilke deler av bestemmelsen som faktisk gjelder for leverandørens egne ansatte vs. eventuelle underleverandører med personell som medvirker?

  Leverandøren må avklare hvilke deler av seriøsitets-/arbeidslivkrav som faktisk operasjonaliseres hos SaaS-leverandøren for å unngå feil etterlevelse og unødige kostnader.

  Bilag 7 – Endringer i den generelle avtaleteksten (pkt. 11.2, 11.6-11.12) og SSA-L punkt 11.2 (lønns- og arbeidsvilkår).
• I vedlegg 2 Forpliktelseserklæring fremgår det at støttevirksomhet må levere inn egne ESPD-skjema ved støtte til kvalifikasjonskrav, og at støttevirksomheten bidrar til «Tekniske og faglige kvalifikasjoner – Styringssystem for informasjonssikkerhet». Kan dere bekrefte hvilke konkrete deler av kvalifikasjonskravet (og dokumentasjonsbehovet) som kvalifiseres gjennom støttevirksomheten, og om dere forventer at støttevirksomhetens ISO-/ISMS-dokumentasjon listes opp og signeres/vedlegges i søknad eller tilbud?

  Forpliktelseserklæringen påvirker leverandørens tilbuds-/kvalifiseringsstrategi og dokumentasjonsomfang; leverandøren må vite hva som faktisk må dokumenteres og på hvilket stadium.

  Vedlegg 2 – Forpliktelseserklæring (referanse til konkurransegrunnlag punkt 4.2 Kvalifikasjonskrav og «Styringssystem for informasjonssikkerhet»).

Konkurransedokumenter

Dokumentpakken er hentet automatisk fra ARTIFIK og samlet som ZIP-fil.

Registrer interesse i den opprinnelige dokumentportalen hvis konkurransen er aktuell. Da får du endringer, spørsmål og svar og eventuell supplerende informasjon direkte fra oppdragsgiver.

Åpne original dokumentportal

Egen dokumentvisning og automatisk dokumentanalyse rulles ut per dokumentportal. Originaldokumentene gjelder alltid ved tilbudsarbeid.