Markedsdialog

Formål med markedsdialogen

Markedsdialogen gjennomføres for å styrke virksomhetens forståelse av behov og legge til rette for en mest mulig effektiv og treffsikker konkurranse. Dialogen er ikke forpliktende, og selv om en markedsdialog ofte skjer i forkant av en konkurranse, kan virksomheten også velge å ikke gå videre med en konkurranse etter at dialogen er gjennomført. Dialogen skal bidra til å:

• Kartlegge markedsmuligheter og få innsikt i tilgjengelige løsninger, teknologisk modenhet og relevante trender.
• Sikre at kravene i kravspesifikasjonen er realistiske og fremtidsrettede, uten at de begrenser konkurransen.
• Identifisere risiko knyttet til sikkerhet, personvern og leverandøravhengighet.
• Få kunnskap om ulike priser og kostnadsdrivere for å sikre forutsigbarhet i kontraktsperioden.

Prosess og gjennomføring

En markedsdialog kan gjennomføres på mange måter og kan igangsettes på ulike tidspunkter. Enten i en helt tidlig fase, eller senere når man har mer innsikt i teknologiske muligheter. Den kan stille spørsmål på helt overordnet nivå rundt hva som finnes i markedet og den kan inkludere mer spesifikk informasjonsinnhenting om konkrete løsninger. Fra en enkel ringerunde med aktuelle leverandører, til en mer strukturert prosess med utsendelse av behov, brukercase og spørsmål.

Beskrivelsen under er en tilnærming som vi anbefaler. Dersom man benytter brukercase, er det ikke et krav at alle punkter i den foreslåtte strukturen fylles ut. Innholdet bør tilpasses hvor langt virksomheten har kommet i planleggingen sin.

Steg 1 – Forberedelse

En god forberedelse gjør dialogen mer effektiv og gir bedre utbytte. Det kan være nyttig å:

• Utarbeide en behovsbeskrivelse og et sett med brukercase som sendes til leverandørene i forkant. Ved komplekse behov er brukercase spesielt anbefalt for å gi leverandørene et konkret grunnlag for dialogen.
• Formulere konkrete spørsmål om tjenester, arkitektur, prising og sikkerhet.

Steg 2 – Gjennomføring av møter

Selve dialogen tilpasses behovets omfang, for eksempel gjennom individuelle møter med en fastlagt agenda. I møtene anbefales det å:

• Presentere virksomhetens behov, situasjon og risiko.
• Be leverandøren gjennomgå sine tjenestetilbud og svare på eventuelle brukercase.
• Stille spørsmål om prising, skalerbarhet, sikkerhet, databehandling og vilkår.

Steg 3 – Oppsummering og bruk av innspill

• Dokumenter sentrale funn og innspill fra hver leverandør.
• Bruk innspillene til å jobbe videre med kravspesifikasjonen og tildelingskriterier.
• Sikre at ingen leverandørspesifikk informasjon gir noen leverandør urimelig fordel i eventuell konkurranse.

Eksempler på brukercase

Under har vi inkludert flere brukercaser som beskriver ulike scenarioer for bruk av skybaserte tjenester. Virksomheten kan bruke casene som inspirasjon, som mal for nivå og struktur på egne beskrivelser, og som utgangspunkt for hva det kan være relevant å spørre leverandørene om.

For å illustrere at markedsdialog kan gjennomføres uavhengig av kunnskapsnivå på det tidspunktet man etterspør, har vi inkludert brukercase hvor vi både har fylt ut alle punktene i sin helhet, og et case hvor virksomheten er såpass tidlig i fasen at de fortsatt er noe usikre på hva de etterspør (ref. 'AI-dataplattform enkel').

[Tittel på brukercase]

[Dato] [Virksomhet] [Kontaktperson]

1. Bakgrunn og kontekst - Kort om virksomheten og dens rolle - Beskrivelse av dagens løsning/situasjon - Motivasjon for overgang til sky (f.eks. modernisering, kapasitet, kostnad)

2. Beskrivelse av scenario - Hva skal kjøre i skyen? (applikasjon, data, prosess) - Hvilken type tjeneste er relevant? (IaaS – compute/lagring, PaaS – databaser/containerplattform, etc.) - Spesielle krav til tilgjengelighet, geografisk plassering (norsk/europeisk region) eller skalering

3. Tekniske forutsetninger - Maskinvare: prosessorkraft og minne - Lagring: type og størrelse - Nettverkstrafikk (estimert inn- og utgående trafikk) - Tilgjengelighet (SLA) - Geografisk region/sone - Antall miljøer

4. Sikkerhet og personvern - Klassifisering av data som skal behandles (åpen / intern / sensitiv / særlig sensitiv) - Relevante krav til kryptering, tilgangsstyring og logging - Krav til lokalisering av data

5. Spørsmål til leverandøren - Hvilke tjenester anbefaler dere for dette scenariet, og hvorfor? - Hvordan dekker løsningen kravene til sikkerhet og personvern beskrevet over? - Hva er estimert månedlig kostnad for det beskrevne behovet? (Spesifiser alle kostnadskomponenter) - Hva er minimums-/maksimumskapasitet for skalering, og hva koster opp-/nedskalering? - Hvilke forpliktelser hviler på kunden (medvirkning, opplæring, integrasjoner)? - Hvordan håndteres avhengigheter til tredjepart/underleverandør?

6. Ønsket svarformat Leverandøren bes besvare brukercaset i tilbudet med: - Løsningsbeskrivelse (maks X sider) - Arkitekturskisse - Prisoversikt (per tjeneste/komponent, månedlig og totalt for kontraktsperioden) - Beskrivelse av sikkerhetstiltak - Avvik fra casebeskrivelsen (dersom dette er aktuelt)

Eksempler på scenarioer i forbindelse med infrastruktur og plattformtjenester

Migrere fra en plattform til en annen

Brukercase: Migrering av medlemsportal til skyplattform

[Dato: 14.04.2026] [Virksomhet: Eksempelorganisasjonen] [Kontaktperson: Navn Navnesen]

1. Bakgrunn og kontekst En medlemsorganisasjon med 50 000 medlemmer som leverer digitale selvbetjeningsløsninger og faglig innhold. Portalen kjører i dag på fysiske servere i eget datasenter. Løsningen består av en webapplikasjon (NET), en SQL-database og en filserver for dokumentlagring. Maskinvaren nærmer seg på å bli utdatert. Ønske om økt driftssikkerhet, enklere skalering ved trafikktopper (f.eks. ved kontingentutsendelse) og utfasing av behovet for vedlikehold av egen maskinvare.

2. Beskrivelse av scenario Web-frontend for medlemsportalen, API-lag, samt tilhørende database og dokumentarkiv. Primært PaaS (Managed SQL-database og App Services/Containers) for å redusere driftsansvar, men IaaS kan vurderes dersom det er tekniske avhengigheter i eldre programvare. Løsningen må ha høy tilgjengelighet i arbeidstiden (08–17) og kunne skalere automatisk ved økt pågang.

3. Tekniske forutsetninger Estimert behov tilsvarer 4 vCPU og 16 GB RAM for web/app-lag i normalsituasjon. Database på ca. 200 GB. Dokumentlager (PDF/bilder) på ca. 1 TB. - Estimert 500 GB utgående trafikk per måned. - Ønsket oppetid på 99,9 %. - Data skal lagres innenfor EU/EØS (fortrinnsvis Norge hvis tilgjengelig). - 3 miljøer (Utvikling, Test og Produksjon).

4. Sikkerhet og personvern - Intern og Sensitiv (inneholder personopplysninger om medlemmer, inkludert betalingsinformasjon og kontaktdata). - Kryptering av data "at rest" og "in transit". Krav om støtte for Azure AD/ID-porten for autentisering. Fullstendig logging av administrative tilganger. - Leverandør må kunne signere virksomhetens standard databehandleravtale.

5. Spørsmål til leverandøren - Hvilke tjenester anbefaler dere for dette scenariet (f.eks. Containers vs. App Services), og hvorfor? - Hvordan dekker løsningen kravene til sikkerhet og personvern beskrevet over? - Hva er estimert månedlig kostnad for det beskrevne behovet inkludert backup og trafikk? - Hvordan håndteres automatisk skalering, og hvilke kostnadsmekanismer trer i kraft ved en økt belastning? - Hvilke forpliktelser hviler på kunden under selve migreringsprosessen (f.eks. nettverksoppsett, refaktorering av kode)? - Hvordan sikrer dere redundans dersom en hel datasentersone skulle gå ned?

6. Ønsket svarformat Leverandøren bes besvare brukercaset i tilbudet med: - Løsningsbeskrivelse: Maks 3 sider som forklarer arkitekturvalg og migreringsstrategi. - Arkitekturskisse: Visuelt diagram over foreslått oppsett i skyen. - Prisoversikt: Spesifisert per komponent (compute, lagring, database, nettverk) per måned. - Beskrivelse av sikkerhetstiltak: Hvordan tilgangsstyring og kryptering håndteres i praksis. - Avvik: Tydelig liste over eventuelle krav i caset som ikke kan oppfylles.

AI-dataplattform

Brukercase: Etablering av fundament for AI- og dataplattform

[Dato: 14.04.2026] [Virksomhet: Eksempelorganisasjonen] [Kontaktperson: Navn Navnesen]

1. Bakgrunn og kontekst En virksomhet i tidlig fase av sin datareise som ønsker å rigge seg for fremtidig bruk av kunstig intelligens og maskinlæring. I dag er data lagret i isolerte kildesystemer og regneark, uten en felles kilde for analyse. Det er behov for å etablere en moderne "landing zone" som muliggjør sikker innsamling og strukturering av data. Motivasjon er å legge til rette for datadrevet beslutningsstøtte, automatisering av manuelle oppgaver og testing av AI-modeller (f.eks. LLM eller prediktiv analyse) i et kontrollert miljø uten store investeringer i egen infrastruktur.

2. Beskrivelse av scenario Sentral lagring av rådata (Data Lake), prosesseringslag for vasking av data, samt et analyse- og eksperimenteringsmiljø for AI. Det er primært ønskelig med PaaS-tjenester (Managed Data Lake, Serverless SQL/Spark, AI-tjenester/Sandkasse) for å sikre lav terskel for oppstart og minimalt behov for manuell serverdrift. Løsningen må være fleksibel nok til at man kan starte smått, men ha arkitektur som tillater rask utvidelse av antall brukere og datakilder etter hvert som virksomheten modnes.

3. Tekniske forutsetninger Behov for elastisk regnekraft som kan skalere etter behov (f.eks. tunge analyser hver natt). I startfasen estimeres dette til moderat kapasitet tilsvarende 2–4 noder for dataprosessering ved behov. - Innledende lagringsbehov på ca. 500 GB, med støtte for både strukturerte og ustrukturerte data. - Estimert lav trafikk i starten, primært nattlig innlasting fra 2–3 eksterne API-er/kildesystemer. - Krav om lagring i europeisk region (Norge foretrekkes hvis tilgjengelig). - 2 miljøer (Utvikling/Sandkasse og Produksjon).

4. Sikkerhet og personvern - Intern og Sensitiv (vil inneholde virksomhetsdata og potensielt personopplysninger som krever GDPR-etterlevelse). - Krav til rollebasert tilgangsstyring (RBAC). Data skal krypteres under lagring og transport. Det kreves sporbarhet (audit logging) på hvem som har aksessert hvilke datasett. - Løsningen må støtte isolering av datasett slik at AI-modeller kun trener på godkjente data.

5. Spørsmål til leverandøren - Hvilke tjenester anbefaler dere for dette scenariet (f.eks. AWS Glue eller Google BigQuery), og hvorfor passer disse for en bedrift i startfasen? - Hvordan dekker løsningen kravene til sikkerhet og personvern, spesielt med tanke på beskyttelse av sensitive data i et AI-miljø? - Hva er estimert månedlig kostnad for en "startpakke" inkludert lagring, prosessering og nødvendige sikkerhetskomponenter? - Hvordan fungerer kostnadskontroll i løsningen slik at man unngår uforutsette utgifter ved skalering eller eksperimentering? - Hvilken kompetanse kreves av kundens ansatte for å ta i bruk plattformen vs. hva som håndteres av leverandør? - Hvordan kan vi enkelt koble på nye datakilder eller tredjeparts AI-verktøy i den foreslåtte arkitekturen?

6. Ønsket svarformat Leverandøren bes besvare brukercaset i tilbudet med: - Løsningsbeskrivelse: Maks 3 sider som forklarer den tekniske plattformen og hvordan den støtter AI-ambisjoner. - Arkitekturskisse: Diagram som viser dataflyt fra kilde til analyse/AI-modell. - Prisoversikt: Estimert månedskostnad for startfasen, samt eksempler på kostnad ved økt bruk. - Beskrivelse av sikkerhetstiltak: Hvordan tilgangsstyring og dataseparering er ivaretatt. - Avvik: Tydeliggjøring av eventuelle begrensninger i foreslått løsning.

AI-dataplattform (enkel)

Brukercase: Etablering av fundament for AI- og dataplattform

[Dato: 14.04.2026] [Virksomhet: Eksempelorganisasjonen] [Kontaktperson: Navn Navnesen]

1. Bakgrunn og kontekst En virksomhet i tidlig fase av sin datareise som ønsker å rigge seg for fremtidig bruk av kunstig intelligens og maskinlæring. Det er behov for å systematisere og strukturere data for å kunne dra nytte av dette på en effektiv måte. Motivasjon er å legge til rette for datadrevet beslutningsstøtte, automatisering av manuelle oppgaver og testing av AI-modeller i et kontrollert miljø uten store investeringer i egen infrastruktur.

2. Beskrivelse av scenario Har ikke inkludert scenario. Løsningen må være fleksibel nok til at man kan starte smått, men ha arkitektur som tillater rask utvidelse av antall brukere og datakilder etter hvert som virksomheten modnes.

3. Tekniske forutsetninger Ønsker innspill fra leverandørmarkedet.

4. Sikkerhet og personvern - Intern og Sensitiv

5. Spørsmål til leverandøren - Hva anbefaler dere at vi bør fokusere på? - Hvilken informasjon er relevant for dere å få fra oss? - Hvordan håndterer dere beskyttelse av sensitive data i et AI-miljø? - Hva bør vi fokusere på når det gjelder pris/kostnadsmodeller? - Hvordan sikre kontroll på kostnadene? - Hva er forventningene til oss som virksomhet ved bruk av deres tjenester? - Hva må vi tenke på når det kommer til integrasjoner mellom våre systemer og AI-løsninger?

6. Ønsket svarformat PDF/Word-format med: - Maks en halv side per spørsmål. - Prismodeller for anbefalte tjenester. - Beskrivelse av sikkerhetstiltak

Eksempler på andre scenarioer

Opprette ny dataplattform

Brukercase: Etablering av ny sentral dataplattform

[Dato: 14.04.2026] [Virksomhet: Eksempelorganisasjonen] [Kontaktperson: Navn Navnesen]

1. Bakgrunn og kontekst Virksomheten har i dag utfordringer med "datasiloer", der informasjon om kunder, salg og drift ligger i separate systemer uten innbyrdes kommunikasjon. Beslutninger tas ofte basert på utdaterte rapporter som krever mye manuelt arbeid å ferdigstille. Vi ønsker å gå bort fra manuelle prosesser og over til en moderne løsning som sikrer én felles kilde til data. Motivasjonen er å få bedre innsikt i sanntid, redusere personavhengighet ved rapportering og sikre at ledelsen har et korrekt beslutningsgrunnlag til enhver tid.

2. Beskrivelse av scenario Etablering av en skybasert dataplattform levert som en ferdig tjeneste (SaaS). Plattformen skal fungere som et sentralt knutepunkt som automatisk henter data fra kildesystemer (ERP, CRM og fagsystem), transformerer disse og gjør dem tilgjengelige for visualisering. Vi ønsker en løsning med minst mulig behov for teknisk oppsett og vedlikehold av infrastruktur. Fokus skal ligge på verdiøkning gjennom datamodellering og rapportutvikling, fremfor drift av databaser eller integrasjonsmotorer. Løsningen må være brukervennlig nok til at forretningssiden selv kan utforske dataene.

3. Tekniske forutsetninger - Tjenestemodell: Foretrukket SaaS-løsning for minimal konfigurasjon. - Datavolum: Startvolum på ca. 200 GB strukturerte data, med forventet vekst på 20 % årlig. - Integrasjoner: Behov for standardkoblinger mot vanlige skybaserte kildesystemer (REST API-er). - Ytelse: Plattformen må håndtere at 50–100 brukere henter ut rapporter samtidig i morgenmøter uten forsinkelse. - Geografisk plassering: Data skal lagres innenfor EØS for å overholde juridiske rammeverk. - Antall miljøer: Logisk skille mellom produksjonsdata og utvikling/test.

4. Sikkerhet og personvern - Klassifisering: Intern og Sensitiv (inneholder kundedata og finansielle tall). - Krav om Single Sign-On (SSO) via virksomhetens eksisterende påloggingsløsning. Tilganger må kunne styres basert på roller (f.eks. at en avdelingsleder kun ser data for sin avdeling). - Innebygde funksjoner for sletting og anonymisering i tråd med GDPR.

5. Spørsmål til leverandøren - Hvilken SaaS-plattform anbefaler dere for dette behovet, og hvordan skiller denne seg fra tradisjonelle PaaS-løsninger? - Hvordan sikrer plattformen datakvalitet og sporbarhet fra kilde til ferdig rapport? - Hva er den totale månedlige kostnaden (lisens, lagring og eventuell trafikk)? - Hvor raskt kan vi forvente å ha de første datasettene og rapportene operative i den foreslåtte løsningen? - Hvilke ferdigutviklede koblinger (connectors) finnes for vanlige kontor- og fagsystemer? - Hvordan håndteres oppgraderinger og vedlikehold av plattformen uten at det påvirker våre rapporter?

6. Ønsket svarformat Leverandøren bes besvare brukercaset i tilbudet med: - Løsningsbeskrivelse: Kort forklaring av plattformens funksjonalitet og brukervennlighet. - Arkitekturskisse: Logisk oversikt over datastrømmen fra kildesystem til sluttbruker. - Prisoversikt: Tydelig oversikt over faste lisenskostnader og eventuelle bruksavhengige kostnader. - Beskrivelse av sikkerhetstiltak: Hvordan rolletilgang og datasikkerhet er ivaretatt i SaaS-modellen. - Avvik: Eventuelle begrensninger i løsningen sammenlignet med caset.