Kvalifikasjonsgrunnlag konkurranse med forhandling IKT-rammeavtale (2015 – 2019)

Miljødirektoratets hovedoppgaver er å redusere klimagassutslipp, forvalte norsk natur og hindre forurensning. Vi er underlagt Klima- og miljødepartementet og har mer enn 700 ansatte ved våre to kontorer i Trondheim/Oslo, og ved Statens naturoppsyn (SNO) sine mer enn 60 lokalkontorer i Norge.

I Trondheim ligger avdelingene med hovedansvar for naturforvaltning. I Oslo er avdelingene med hovedansvar for klima og forurensning.

1.1 Våre oppgaver

Regjeringen og Stortinget fastsetter ambisjonsnivået i miljøpolitikken. Miljøpolitikken er delt opp i ulike resultatområder med konkrete nasjonale mål. Vi har viktige oppgaver som skal bidra til å nå mål på disse områdene:

• Stabilt klima og styrket tilpasningsevne

• Mangfoldige skoger

• Storslåtte fjellandskap

• Frodige våtmarker

• Giftfritt miljø

• Aktivt friluftsliv

• Verdifulle kulturlandskap

• Levende hav og kyst

• Livskraftige elver og innsjøer

• Avfall og gjenvinning

• Ren luft og mindre støy

Les mer om Miljødirektoratet (lenke til vårt nettsted)

1.2 Organisasjonsstruktur

Fra 1.mars 2014 har vi følgende organisasjonsstruktur:

2 Direktoratets IKT-organisering og føringer

IKT-seksjonen (OIT) er plassert i organisasjonsavdelingen som en seksjon, med til sammen 31 ansatte. Det er 6 personer som er tilsatt sentralt i seksjonen (IKT-sjef og en stab på 5 rådgivere/ingeniører). Seksjonen er videre inndelt i 2 autonome enheter:

• Enhet for IKT-utvikling og forvaltning (OITU) med 11 medarbeidere

• Enhet for IKT-drift (OITD) med 15 medarbeidere

IKT-seksjonen har medarbeidere i både Oslo og Trondheim:

	Oslo	Trondheim	Samlet
IKT-seksjonen	3	2 + ikt-sjef	6
Enhet for IKT-utvikling	11	0 (p.t)	11
Enhet for IKT-drift	8	7	15
Samlet	22	9	31

Organiseringen av enhet for IKT-utvikling (med kun Oslo-tilsatte) preges av den nylige sammen- slåingen av Klima- og forurensningsdirektoratet (Klif) og Direktoratet for Naturforvaltning (DN) til Miljødirektoratet. Klif hadde en egen ikt-utviklingsseksjon og en driftsseksjon, mens DN hadde en driftsseksjon.

Nå er de to ikt-organisasjonene slått sammen til en seksjon, og drift og utvikling er organisert som to selvstendige enheter under seksjonen. Ledergruppen skal utgjøre 3 personer; ikt-sjef Xxxxx Xxxxxxxx, og xxxxxxxxxxx Xxxxxxx Xxxx. Leder for utviklingsenheten er ikke tilsatt, og ikt-sjef fungerer derfor.

2.1 Eierskap og forankring av IKT-løsninger (IT-governance)

Som beskrevet er Miljødirektoratet en sammenslutning mellom Klif og DN (fra 1. juli 2013). Harmoniseringsarbeid er pågående, og de forskjeller en ser i organisering ved kontorene i Oslo og Trondheim skyldes hvordan man tradisjonelt har arbeidet med IKT i de to etatene.

Miljødirektoratet (ved Klif i Oslo) har lang erfaring med sentrale ikt-rammeavtaler, mens DN ikke har benyttet slike. Det er ikke endelig avklart hvordan Trondheim skal løse fremtidige leverandørbehov, slik at denne rammeavtalen primært skal dekke Oslo' behov. Avtalen skal dog sikre at leveranser skal kunne skje i Trondheim. På sikt kan det bli kjørt en tilsvarende/liknende prosess for Trondheim.

2.1.1 IKT-styringsmekanismer

I dette avsnittet beskrives etatens IKT-styringsmekanismer (IT-governance) som målbilde1 på hvordan vi ønsker å organisere vår IKT-virksomhet på 5 sentrale områder:

• IKT-strategi og prinsipper (rammer og retning)

• IKT-investerings- og prioriteringsbeslutninger

• IKT-forretnings- og applikasjonsbehov

• IKT-arkitektur (organisering, standardisering og integrasjon)

• IKT-infrastruktur

2.1.2 IKT-strategi og prinsipper (rammer og retning)

Direktoratets direktørmøte består av etatsdirektør og avdelingsdirektørene (eg. toppledergruppen TLG) og de beslutter etatens forretningsstrategier (fagstrategier).

• Miljøsektoren har egne ikt-strategier/-planer utarbeidet av Klima- og miljødepartementet

• Etatene har årsbudsjetter/-planer som preges av årlige prioriteringsønsker fra Klima- og miljødepartementet

Sentrale beslutninger om ikt-strategi og prinsipper tas derfor på flere nivåer:

• På etatsnivå (TLG) der de har særlig prinsipiell betydning

• På avdelingsledernivå (typisk i organisasjonsavdelingen) for aktuelle tverrgående områder

• På seksjonsledernivå (typisk i ikt-seksjonen) for aktuelle operative/taktiske områder

IKT-seksjonen har en viktig rolle i saksforberedelse og rådgivning inn i de nevnte beslutningsfora. Organisasjonsavdelingen har videre en sentral rolle som premissleverandør for prinsipper og politikk på IKT-området, herunder sikkerhet, god praksis etc. Intranettet og SharePoint er i hovedsak stedet hvor vi gjør tilgjengelig prinsipper, rutiner, maler og dokumenter for organisasjonen.

2.1.3 IKT-investerings- og prioriteringsbeslutninger

Miljødirektoratet har som offentlig etat årlige budsjetter og virksomhetsplaner hvor rammene for etatens IKT-arbeid legges for hvert nye planår. Etatens budsjett fastsettes i Stortinget basert på regjeringens prioriteringer. Klima- og miljødepartementet gir i budsjett og tildelingsbrev konkrete mål og føringer for etatens arbeid innenfor planåret.

1 Målbildet er delvis realisert på noen områder, mens vi andre steder fortsatt har en vei å gå

Sentrale beslutninger om ikt-investeringer og prioriteringer tas på flere nivåer:

• På etatsnivå (TLG) prioriteres og tildeles ikt-midler i budsjett og virksomhetsplaner

• Organisasjonsavdelingen har et særlig ansvar for saksfremlegg og prioriteringsforslag

• Budsjetter tildeles seksjoner og disponeres i henhold til interne føringer og planer

Normalt forpliktes midler kun i forkant (ved oppstart) av nytt plan-/budsjettåret. Forpliktelser over flere år tas som hovedregel med forbehold om inndekning i de årlige budsjettprosesser (Klima- og miljødepartementet vs. Stortinget). Etaten har budsjettrevisjoner hvert tertial (dvs. primo mai og september) hvor det tas beslutninger om endringer i finansiering.

2.1.4 IKT-forretnings- og applikasjonsbehov

I Oslo har vi en praksis med desentralisert formelt eierskap til fagavdelingene (herunder O- avdelingen), kombinert med en delvis sentralisering av praktisk forvaltningskompetanse/-ressurser til IKT-seksjonen - enhet for IKT-utvikling og forvaltning. Forretningsbehovet oppstår i fagavdelingen

(linjen) og dekkes delvis med kompetanse og kapasitet fra sentral stab i o-avdelingen. Vi har rollen "systemeier" som er en avdelingsdirektør eller seksjonsleder og som formelt fyller rollen "seniorbruker". I prosjektfasen (utvikling) benevnes denne rollen "prosjekteier".

Formelt eierskap omfatter økonomisk ansvar samt overordnet beslutnings- og prioriterings- ansvar via systemforvalter/prosjektleder. Det formelle eierskapet vil i de fleste tilfeller ligge hos avdelingsdirektør i aktuell fagavdeling. Det finnes som hovedregel en systemeier bak hver etablert løsning, også standard- løsninger som arkiv, ERP-løsning etc.

Oppsummert tar Systemeier følgende ansvar:

• Faglig ansvar for systemet – herunder initiering av videreutvikling, finansiering og gevinstrealisering. Har også et ansvar for at deres system blir vurdert i en helhetlig sammenheng

Systemeier utpeker systemforvalter(e) som er de som i operativt utfører forvaltning av rollen (sikre at løsningen tilfredsstiller behov og realiserer gevinster). I utviklingsfasen finner vi ofte den fremtidige systemforvalter som intern prosjektleder. Systemforvaltningsansvaret er fokusert på oppfølging av arbeid og kontrakter. Systemforvalter har ansvaret for å tilrettelegge for daglig bruk, feilhåndtering, kontakt med leverandør, kontakt med de andre rollene i forvaltningsorganisasjonen. Systemforvalter kan være på seksjonsledernivå og/eller saksbehandlernivå. Vi finner forvaltere både i fagavdelingene og i organisasjonsavdelingen.

Oppsummert har Systemforvalter følgende oppgaver:

• Har ansvar for de løpende oppgavene knyttet opp mot et fagsystems livsløp – direkte, eller via bruk av spisskompetanse i eller utenfor egen enhet. Herunder anskaffelse, vedlikehold, dokumentasjon, videreutvikling, drift, opplæring, brukerstøtte/feilhåndtering og koordinering av datautveksling mot andre system.

Den sentrale enhet for ikt-utvikling og forvaltning samler de fleste (men ikke alle) forvaltere av ikt- løsninger i Oslo. Dette har vært en bevisst strategi for å kunne utnytte ressurser effektivt. Det er en del løsninger som har lokale forvaltere som sitter i noen fagavdelinger. IKT-seksjonen støtter systemeiere/-forvaltere og prosjekteiere/-ledere med tjenester i de ulike fasene av løsningers livsløp.

Videre er det andre brukerrepresentanter involvert i form av superbrukere. Dette er saksbehandlere eller fagpersoner som tar følgende oppgaver:

• Fagansvarlig

• Bindeleddet mellom systemforvalter, brukere og systemeier

2.1.5 IKT-arkitektur

IKT-seksjonen har et helhetlig koordineringsansvar for IKT-området, da systemeiere/-forvaltere med sine veivalg for fagapplikasjonene vil påvirke den samlede IKT-arkitekturen i direktoratet. Når nye behov skal dekkes har IKT-seksjonen en rolle for å sikre gjen-/merbruk samt konsekvensvurdering av ev. nye plattformer/verktøy etc. I forbindelse med ny organisering av IKT-seksjonen fra våren 2014 er IKT-arkitektur utpekt som ett av flere områder som seksjonen skal ha et særlig og styrket ansvar for.

Vi bruker leverandør av IKT-løsninger for å dekke spisskompetanse om gitte plattformer/verktøy, men vi har god generell egen kompetanse om de ulike elementene.

2.1.6 IKT-infrastruktur (sw-plattformer og hardware)

Beslutninger om infrastruktur tas i hovedsak av organisasjonsavdelingen/IT-seksjonen (enhet for ikt- drift) eller av denne i samarbeid med systemeiere/-forvaltere. Innføring av ny infrastruktur (sw/hw) besluttes i hovedsak i forbindelse med konkurranser i markedet hvor tilbydere foreslår løsninger basert på vårt behov, eller hvor vi forutsetter gjenbruk av plattformer/verktøy, konsepter, komponenter og rammeverk.

2.2 Prosjektgjennomføringsmetodikk

Vårt mål med IKT-leveranser er å få levert avtalt produkt (løsning) til avtalt tid, pris og kvalitet. Vi ønsker forutsigbarhet, ved at leverandører faktisk leverer alt det de har lovet i tilbudsfasen og som er nedfelt i kontrakten. På dette området er vi formalistiske – og vi har erfart at vi har måttet gå runder med leverandør i flere prosjekter om dette.

Vi ser at ulike kontraktsformer og gjennomføringsmetodikk har ulike tilnærminger som gir ulike styrker og svakheter. Vi har etter hvert en del egne erfaringer med ulike tilnærminger som vi skal redegjøre nærmere for i de etterfølgende avsnittene.

2.2.1 Erfaringer med klassisk fossefallsmetodikk

Som offentlig etat er det naturlig å velge en av DIFI' standardavtaler (SSA'er), eks SSA-U. SSA- utviklingsavtalen er laget for en tradisjonell flerfaset fossefallsmetodikk. Fordeler med et slikt rammeverk er at den underbygger en fastpristilnærming av oppgavene etter nærmere spesifikasjon, og at dette gir oss en ønsket trygghet/sikkerhet mot uventede kostnader.

Vi har erfaring i å kreve et forpliktende pristilbud (enten estimat eller fastpris) i fm inngåelse av kontrakt og at leverandørens anledning til å reestimere leveransen etter gjennomført detaljert spesifikasjon er oppad begrenset til en gitt prosent, eks 10 eller 20%.

Ulempen er at SSA-U fokuserer på leveranse kun av det som er detaljspesifisert, og at nye momenter, ideer, tilnærminger eller kunnskap som oppstår underveis blir håndtert som en risiko snarere enn en mulighet, og at dette ofte blir lagt under et omfattende og rigid endringshåndteringsregime. Som vi redegjorde for i avsnittet om Prince2® er vi ikke positive til omfattende tidsbruk på byråkrati og formalisme i gjennomføringen av selve prosjektet.

Vårt utgangspunkt (og leverandørenes dilemma) er at vi ønsker kontraktsmessig formalisme om omfang og kostnad og innholds- og gjennomføringsmessig smidighet i forhold til selve prosjektgjennomføringen.

2.2.2 Erfaringer med smidig metodikk (scrum/sprint)

Vi ser at leverandører i stadig større utstrekning ønsker å kjøre prosjekter etter smidig metodikk, og at det hevdes resultatene blir mye bedre med en slik metodikk. Vi har i noen prosjekter forsøkt å kjøre smidig - med ulike resultater, gjerne med både positive og negative erfaringer i samme prosjekt. Selv om samhandling kan være god og positiv, savner vi de virkelig gode erfaringene.

Som kunde er vi ikke profesjonelle i smidig metodikk, og vår organisering skaper utfordringer. Vi har en linjeorganisasjon hvor myndighet/penger er plassert i org.enheter og ikke i prosjektet. Våre prosjektledere har ikke styringsrett på penger, ressurser eller kritiske beslutninger. Våre hørings- og

beslutningsprosesser er ofte tidkrevende (det er mange som skal høres og beslutninger tas i linjen). Vi er ikke så raske/dynamiske som en smidig prosess ofte krever. Vi ser derfor klare utfordringer i å følge opp vår rolle som "product owner" i smidig metodikk på en god nok måte. Vi har videre observert at kompetanse i smidig metodikk er varierende også hos leverandørene og at manglende kompetanse i leveranseteam og teamledelse kan ha ødeleggende virkninger.

Vi ønsker trygghet for å få avtalt leveranse (behov/krav) til avtalt pris og kvalitet, gjerne med en smidig og ikke-formalistisk gjennomføring av prosessen i forhold til endringer/tilpasninger. I mange tilfeller har vi skåret ned ambisjonsnivået i fm. tilbuds- og kontraktarbeid, og hvor vi har lite å gi (saldere) i en smidig prosess. Våre erfaringer er at smidig metode ikke leverer alt vi ønsket eller forventet å få. Vi har sett tendenser til at smidig prosess fra leverandørens side går ut på å sikre at alt utført arbeid kan faktureres selv om sluttleveransen avviker fra det opprinnelig avtalte, og at vi i prosessen har måttet akseptere/godkjenne dette. Slike målkonflikter er krevende å håndtere.

Med dette som bakteppe har vi i våre siste prosjekter forsøkt en ny tilnærming, som vi redegjør for her

2.2.3 Fossefallsfremdrift med dynamikk (smidige elementer)

Vi søker å kombinere det beste fra en klassisk og en smidig tilnærming, dvs. vi ønsker at leverandør leverer avtalt produkt (kvalitet) til rett tid og avtalt ramme/pris, og at prosjektet kan utnytte muligheter og ny kunnskap som oppstår underveis i gjennomføringsprosjektet (innen rimelighetens grenser). Vi erkjenner leverandørens usikkerhet (risiko) og har forsøkt å ta høyde for dette i følgende fremdrift:

• Vi krever begrunnede estimater for løsning/leveranse i tilbudene basert på vår spesifikasjon

• For hvert enkelt detaljert estimat skal det være tatt høyde for ev usikkerhet, og ev. tidsbruk for ytterligere spesifikasjoner, avklaringer/dialog, mindre endringer/justeringer, feilretting etc. Dvs. alle felles usikkerhet (risiko) skal enten være akseptert (inkludert) eller priset inn i estimater. Erfaringsmessig "snakker vi tidvis opp" lave estimater i forhandlingsfasen – hvis de synes lave eller udokumenterte, og hvor vi også aktivt stiller spørsmål om drivere bak høye estimater

• Endelige estimater etter forhandling tas inn i en initial kontrakt

• Kontrakt skisserer at det skal gjennomføres en detaljert spesifikasjon som en del av leveransen, men hvor anledning til prisøkning etter denne er oppad begrenset til en gitt prosent, eks. 10-20 %

• Detaljert spesifikasjonsfase reviderer estimater innenfor det som er avtalt, og endelige estimater håndteres (låses) som en fastprisleveranse

• I leveransen må prosjektleder fra Miljødirektoratet og leverandør i fellesskap forvalte de "frihetsgrader" i fastpris som er tatt inn i avtalen. Frihetsgraden kan etter avtale mellom partene brukes på mange måter; småendringer i design/funksjonalitet, ny funksjonalitet etc. Leverandøren har ansvar for å melde fra når prosjektet ikke lengre har rom for fleksibilitet /smidighet, enten for leveransen samlet sett eller for enkeltelementer/leveranser

• Der det er åpenbare tillegg eller større endringer som det ikke er rom for innenfor "frihetsgraden" kan dette avtales som tilleggsleveranser (i form av tradisjonell endringshåndtering)

• For å sikre effektiv dialog forutsetter vi mulighet for dialog direkte med "utførerne" i leveranseteamet (arkitekter og utviklere) slik at vi ikke alltid må snakke via en "proxy" (les leverandørens prosjektleder).

Med dette sikrer vi bruk av de klassiske SSA-avtaler med en fast avtalt øvre ramme (pris) og leveranse, samtidig som vi sikrer økonomisk fundament for å ha en smidig tilnærming til oppgaveløsning. Dette er krevende for begge parter, men med en god felles forståelse og smidighet og ansvarlighet fra begge sider vil dette kunne fungere utmerket. Vi ser at det er kritisk at den som skal være prosjektleder fra leverandørens side har en aktiv rolle i den merkantile tilbuds- og kontraktfasen, for å forstå scope og arbeidsmetodikk.

2.2.4 Steg-port modell for å sikre kontinuerlige leveranser

I tillegg til smidig fossefallsmetodikk ser vi behov for en tydeligere leveranseplan. Vi ser at klassiske forløp (SSA-U) ofte leverer testbare delleveranser sent, slik at problemer i fremdrift eller kvalitet identifiseres for sent. Vårt alternativ til "interne sprinter" er formelle steg-porter som tas inn i leveranseplanen i kontrakt (i eksemplet er de sekvensielle men kan også være delvis overlappende):

Vi forutsetter at kontrakten skal inneholde en stegvis leveransemodell med leveranse-tidspunkter og "verifikasjonssteg". Med mindre steget (delleveransen) blir levert og godkjent "åpner vi ikke porten" for arbeid med videre faser (delleveranser). Kun unntaksvis (der det ikke kan påvises avhengigheter eller hvor ressursbruk kan forsvares) kan arbeid med neste fase skje før forrige steg er godkjent.

2.2.5 Prince2® – rammeverk for prosjektaktiviteter

Klif har benyttet Målrettet Prosjektstyring siden 2001, men over tid så vi offentlige etater og leverandører i stadig større grad "standardiserte" på Prince2® metodikken. Miljødirektoratet har besluttet at våre prosjektrelaterte IKT-prosesser skal følge en Prince2® metodikk, og vi har sertifisert egne ressurser i "Prince2® Foundation". Som et resultat av dette - og for å sikre gjenkjenningseffekten forutsetter vi at leverandører benytter denne metodikken. Metodikken i en nedskalert versjon er lagt til grunn i DIFI' xxx.xxxxxxxxxxxxxxxxxx.xx

Vi ser særlige styrker i Prince2® i forhold til:

1. Forretningsmessig fokus (sikre gyldig begrunnelse gjennom hele prosjektlevetiden), og gode rammeverk for:

a. Prosjektmandat

b. Prosjektinitieringsdokumentasjon

c. Business Case

2. Fokus på læring (lære av tidligere eller liknende tidligere prosjekter og evaluere egne erfaringer)

3. Klare roller og ansvar (viktig identifisering av forretning, bruker og leverandør)

4. Faseinndeling (prosjektplan og detaljerte faseplaner), j fr steg-port modellen

5. Fokus på definerte produktbeskrivelser (produktleveranser heller enn aktiviteter)

6. Håndtering av usikkerhet (risiko), j fr smidig håndtering av handlingsrom mellom ekstern og intern prosjektleder

Miljødirektoratet har ikke kjørt fullverdige Prince2® IKT-prosjekter enda, så beskrivelser som følger er en "to-be" kombinasjon av eksisterende/nye prosesser.

I vår IT-styring er vi pragmatiske i forhold til hvor mye av rammeverk vi tar i bruk. Vi er generelt opptatt av formalisme i kunde-leverandør relasjonen og kontrakt, men innenfor prosjekter ønsker vi en mer pragmatisk holdning. En del av formalismen/rigiditeten i Prince2® i forhold til faser/-overganger krav til dokumentasjon og –oppdatering, usikkerhetsanalyse, endringshåndtering etc. er i overkant i forhold til vår eksisterende prosjektkultur. Ambisjonsnivå og bruk av verktøy/hjelpemidler må til en viss grad få preges av prosjektleders preferanser og prosjektets egenart.

2.3 Organisering av direktoratets ikt-prosesser

Her beskrives eierskap/roller for ulike faser i nye systemutviklingsprosjekter, fra organisering i idé- og spesifikasjonsfasen, via utviklingsfasen til forvaltning og videreutvikling av løsninger.

2.3.1 Idé- og spesifikasjonsfase (j fr Prince2® "Oppstart av prosjekt")

Fagavdelingen er ansvarlig for idé- og spesifikasjonsfasen. Dette kan både skje som en linjeoppgave (der fagsiden i hovedsak bemanner og leder arbeidet) eller et forprosjekt hvor fagsiden støttes av IKT- seksjonen og ev. ekstern leverandør(er). Triggeren er et "(prosjekt)mandat", og i denne fasen skal en:

• Verifisere at prosjektet en ønsker å utføre er lønnsomt og levedyktig, eg. beskrive det forretningsmessige grunnlaget i et grovt Business Case

• Definere prosjektets omfang (og tilnærming) i form av et prosjektforslag

• Organisering (definere roller og ansvar) av prosjekteier/-leder, teamleder(e), seniorbruker(e)

• Sikre at erfaringer fra tidligere/relevante prosjekter er nyttiggjort

• Faseplan for oppstart av prosjektet (initieringsfasen)

Vi finner i særlig grad følgende roller i spesifikasjonsfasen:

Prosjektstyre (j fr. "styringsgruppe") Behovseier (seniorbruker):

• Overordnet ansvar for at spesifikasjoner/dokumenter blir utarbeidet og for endelig omfang

Leder arbeidsgruppe (ev. prosjektleder):

• Lede det praktiske arbeidet med spesifikasjoner/dokumenter

Bidrag fra IKT-seksjonen:

• I de fleste tilfeller vil IKT-seksjonen delta med ressurser for å bidra med sin kompetanse (koordineres av IKT-sjef) som eksempel:

IKT-rådgivere

IT-seksjonen har flere rådgivere som fyller ulike roller i direktoratets IT-prosjekter, alt fra prosjekt-

/prosessledelse (Prince2®), prosess-støtte, IKT-faglig rådgivning, dokumentasjon etc.

IKT-anskaffelsesstøtte

IKT-seksjonen har betydelig erfaring fra anskaffelser. IKT-seksjonen har i de fleste tilfeller fremdriftsansvar for inngåelse av IKT-avtaler for egne løsninger

2.3.2 Utviklingsfasen (prosjekt)

Utviklingsfasen organiseres som et prosjekt - basert på aktuelle prosesser/faser i Prince2®. Prosjektets egenart avgjør hvor formelt og rigid eierstyring, samt ledelse av faser etc. blir foretatt. I mange prosjekter blir Prince2® fasene slått sammen til et en-fase eller to-fase leveranseprosjekt. Vi finner som oftest følgene roller:

Prosjektstyre (styringsgruppe):

• Prosjektstyret er et viktig forum for ”eiende” avdeling (seniorbruker) hvor de bidrar for å sikre at deres interesser blir godt ivaretatt av prosjektleder(e) og (senior)leverandør.

Prosjekteier:

• Overordnet ansvar for at spesifikasjoner/dokumenter blir utarbeidet og for endelig omfang

• IKT-sjef (leder av IKT-seksjonen eller IKT-enhetene) har ofte rollen som prosjekteier og koordinerer medvirkning fra IKT-seksjonen (herunder de to enhetene) og gjennom hele utviklingsprosjektet

Prosjektleder:

• Der vi benytter ekstern leverandør har vi alltid en intern prosjektleder som koordinerer egne ressurser og har kontakt med leverandørens prosjektleder. Dennes viktigste redskap er spesifikasjonene og dokumentasjonen som er utarbeidet i spesifikasjonsfasen.

• Rådgiverne i IKT-seksjonen tar ofte rollen som prosjektledere. Andre ganger engasjeres eksterne

prosjektledere, og i noen tilfeller benyttes fagpersoner til dette formålet.

Ekstern prosjektleder:

• I oppdrag med en tydelig risikoprofil skal vi ha en dedikert høyt kvalifisert ansvarlig prosjektleder fra leverandøren. Denne skal sikre at leverandør leverer på tid, penger og kvalitet, og sikre god og åpen kommunikasjon med direktoratets prosjektleder

Prosjekter benytter i hovedsak eksterne leverandører til å utvikle ikt-løsninger, og rollen seniorleverandør tas som oftest av leverandørens (ramme)avtaleforvalter og/eller ressurseier.

Miljødirektoratet har p.t ingen formaliserte føringer for å bemanne prosjektsikring, prosjektstøtte og

endringsansvarlig.

Avhengig av prosjektets egenart defineres en eller flere prosjekt/arbeidsgrupper (team) bestående av ev. ressurspersoner fra fagsiden og andre ressurspersoner i direktoratet. Vi har sjelden så store interne prosjektgrupper at en formell teamleder organisering har vært aktuell. Representanter fra fagavdelingen (seniorbrukere) involveres etter behov i denne fasen.

2.3.3 Avslutte et prosjekt

Prince2® fasen "å avslutte et prosjekt" skjer ofte som en del av en- eller to-trinns leveransen, dvs. som en avsluttende aktivitet.

2.3.4 Drift-/forvaltningsfasen

Når løsningen blir levert fra utviklingsprosjektet og går i produksjon overføres ansvaret

tilbake til (fag)avdelingen og det utpekes en systemforvalter, hvis denne ikke allerede er utpekt. Tidvis vil prosjektleder ta rollen som systemforvalter. Denne bygger opp en driftsorganisasjon bestående av superbrukere og andre ressurspersoner.

Enhet for IKT-utvikling og forvaltning

• Enheten har i denne fasen en støttende rolle og bistår ad-hoc ved feil eller andre behov

Enhet for IKT-drift

• IKT-drift har ansvaret for den tekniske driften av løsningene, dette gjelder servere med programvare, databaser, LAN/WAN og andre verktøy

• Vi har dedikerte ressurser på databasedrift som har stor kompetanse om vår databaseplattform og som jobber tett sammen med systemeiere og leverandører om våre løsninger.

2.4 Støttende roller i direktoratet (egne og eksterne)

I det følgende beskrives enkelte av de seksjoner (i ulike enheter) som har en spesifikk rolle i ikt- arbeid/prosesser.

2.4.1 Miljøstatusseksjonen (TMS)

Seksjonen har et overordnet ansvar for:

• Redaktør for "Miljøstatus i Norge"

• Koordinere og følge opp interne leveranser til Miljøstatus i Norge

• Følge opp eksterne samarbeidspartnere og leveranser til Miljøstatus i Norge

• Knutepunkt for koordinering av arbeidet mot EEA

• Oppfølging av Inngrepsfrie naturområder i Norge (INON)

Seksjonen har følgende sentrale løsninger:

• Miljøstatus: xxx.xxxxxxxxxxx.xx, herunder datafangstrutiner mot Miljødata-db og indikatorkatalog

• Miljøtall: database/rapporteringsfunksjonalitet for Miljøstatus

• Miljødata: Lagringsdatabase for diverse xml-baserte datasett fra ulike datakilder/-leverandører

2.4.2 Miljødataseksjonen (TMI)

Miljødataseksjonen har følgende oppgaver:

• Miljødata og Geodata (stedfestet informasjon)

• Utvikling av databaser, fagsystem og publiseringsløsninger

• GIS-analyser, statistikk og kartproduksjon

• Standardisering og kvalitetssikring av miljødata

• Kontakt mot eksterne samarbeidsparter på miljødataområdet (Norge digitalt, Kartverket m.fl.)

Seksjonen har følgende sentrale løsninger:

• Miljøatlas: xxxx://xxx.xxxxxxxxxxx.xx/Xxxx-xx-xxxxxxxxx/xxxx/

• I tillegg et større antall løsninger som p.t kjøres i Trondheim og ikke beskrives ytterligere her

2.4.3 Nettseksjonen (EKON)

Er en seksjon i kommunikasjonsenheten (avdelingen) og har ansvar for en rekke av våre nettsteder:

• Intranett

• Vårt nettsted xxx.xxxxxxxxxxxxxxxxx.xx

• xxx.xxxxxxxxxxx.xx

2.4.4 Seksjon for vannforvaltning (AVA)

Oppgaver på seksjonen er knyttet til arbeidet med EUs vanndirektiv, nasjonal samordning av aktører i vannforvaltningen, plan- og prosessfaglig oppfølging av arbeidet med regionale vannforvaltnings- planer, miljøfaglig oppfølging av arbeidet med økologisk og kjemisk tilstand, overvåking og miljøtiltak i vann. Seksjonen skal sikre en helhetlig håndtering av vannarbeidet i Miljødirektoratet.

Sentrale løsninger seksjonen har ansvar for er:

• Vann-Nett

• Vannmiljø

• Xxxxxxxxxxxx.xx .

2.4.5 Dokumentasjonsseksjonen (ODO)

Seksjonen har ansvar for arkiv og dokumentforvaltning, bibliotek, sentralbord, konferansesenter, ekspedisjon, publikasjonsdistribusjon, bygningsdrift, utstyrs- og inventarkjøp, reiseområdet, renhold,

kantine, etatslagre og oppfølging av en rekke fellesavtaler for etaten. Sentrale løsninger seksjonen har ansvar for er:

• Ephorte elektronisk arkiv

Da denne seksjonen forvalter vårt elektroniske arkiv så vil de bli involvert i prosjekter som skal integrere arkivløsning inn mot fagapplikasjoner. De er involvert i rutiner for arkivering av elektroniske rapporter fra Altinn.

2.4.6 Økonomiseksjonen (OOK)

Seksjonen er ansvarlig for etatens budsjettarbeid, planlegging, regnskap og rapportering, samt regelverket for offentlige anskaffelser. Seksjonen bistår også avdelingene i deres arbeid på området. Sentrale løsninger seksjonen har ansvar for er:

• Plan&Rapport

• Økonomisystemet Agresso (herunder Lønn/personal og Business World Portal m/elektronisk fakturabehandling)

Plan&Rapport skal inngå i vedlikeholdsavtalen som skal inngås for våre egenutviklede løsninger. Videre er integrasjon med Agresso aktuell fra nåværende eller fremtidige fagapplikasjoner.

2.4.7 Superbrukere (i direktoratet og hos fylkesmannen)

Superbrukerne er de som skal ha best kunnskap om bruken av løsningene på sitt område og som skal hjelpe andre brukere som har problemer. I dette ligger å gi bistand til brukerstøtte-personer hos fylkesmannen, hvis de står fast i veiledningen av ”sine” brukere.

2.4.8 Eksterne utviklere

Direktoratet har som hoved politikk at utvikling av våre løsninger skal skje med bruk av eksterne samarbeidspartnere, fortrinnsvis innenfor vår IKT-rammeavtale. Tidsvis tegner vi vedlikeholdsavtale med utviklingspartneren av løsningen i en overgangsperiode etter utvikling for å skjerme/ivareta domenekunnskap om løsningen. Vi har også en generell vedlikeholdsavtale (innenfor denne ramme- avtalen) som et antall eksisterende løsninger benytter.

2.5 Teknisk/fysisk infrastruktur

2.5.1 Utviklingsmiljø

Direktoratet bruker Microsoft Team Foundation Server (TFS) og Visual SourceSafe (historikk) for kildekodekontroll. Løsningen blir utviklet på direktoratets maskiner med Visual Studio (C#) som foretrukket utviklingsverktøy. Direktoratet forestår MSDN lisenser. MS SQL Server 20nn, EpiServer CMS 6.x/7.x og ESRI kartserver er tilgjengelig.

2.5.2 Testmiljø

Miljødirektoratet har egne testmiljøer. Dette er i all hovedsak satt opp likt med produksjonsmiljøet. All ferdigutviklede applikasjoner skal legges ut her for uttesting før endelig produksjonssetting. Dette utføres av enhet for IKT-drift i samarbeid med leverandør.

2.5.3 Produksjonsmiljø

Miljødirektoratet har egne produksjonsmiljøer. All ferdigtestede applikasjoner/løsninger legges ut her for endelig produksjonssetting. Dette utføres av it-drift i samarbeid med leverandør. Direktoratet benytter Microsoft på webplattform og databaseplattform (inkl. Report Builder, Reporting/Analysis/Federation Services), i tillegg til kartprogramvare fra ESRI.

2.5.4 Standardisering

Miljødirektoratet er som offentlig etat pålagt å følge føringer fra sentralt hold. Dette omfatter f eks prosjektgjennomføring (xxx.xxxxxxxxxxxxxxxxxx.xx) og andre forhold:

• Nasjonale felleskomponenter (lenke til DIFIs prosjektveiviser) som ID-porten, Altinn etc

• Øvrige standarder (lenke til DIFIs standardportal) for layout, design,

Nettsiden xxxx://xxx.xxxxxxxx.xxxx.xx/xxxxxxxxxxxxxxxxxxxxxx gir en komplett oversikt over aktuelle standarder som våre rammeavtalepartenere må forholde seg til i våre prosjekter.

2.6 Status for IKT-plattform og føringer for videreutvikling

Vi ønsker å bygge sentraliserte web-baserte løsninger med vekt på effektiv distribusjon og drift, samt med gode brukergrensesnitt for ulike brukergrupper (hovedsakelig differensiert internt og eksternt).

Vi ønsker å basere oss på teknologi og løsninger som i stor grad bygger opp under leverandør- uavhengighet og fleksibilitet i å velge samarbeidspartner ut fra de utfordringer som søkes løst. Vi prioriterer driftsstabilitet, og velger således anerkjente velprøvd teknologi/løsninger.

2.6.1 Standardiserte utviklingsplattformer

Helt fra da vi tok i bruk PC’er i direktoratet har vi hatt et rent Microsoft-miljø på klienter og servere. Dette er begrunnet i intern kompetanse og det faktum at våre samarbeidspartnere i sektoren i all hovedsak kjører tilsvarende plattform.

Siden 2001/2002 har vi målrettet bygget nye løsninger på en ensartet dotNET teknisk plattform, og i henhold til en foretrukket målarkitekturbeskrivelse (som p.t er foreldet). En konsekvens av dette har vært at vi har tatt i bruk stadig flere standard elementer (services) i vår Microsoft utviklings-

/databaseplattform. Vår Geodata plattform fra ESRI (Arc*) er siden sent 90-tall gradvis utviklet i samarbeid med de andre aktørene i miljøsektoren som også bruker samme plattform.

Når våre retningslinjer ikke har utpekt en gitt plattform for et nytt behov har vi inkludert verktøy/- plattform valg i offentlig konkurranse om oppdrag/prosjekt. Nye plattformer er således valgt etter helhetlige kost-/nytte vurderinger. Nye verktøy-/plattformvalg er deretter tatt inn i vår foretrukne web-baserte målarkitektur og blitt lagt som premiss for mer-/gjenbruk ved senere behov. Vi har investert betydelige beløp (lisenser/maskinvare/opplæring) i våre plattformer og våre ressurspersoner har betydelig kompetanse på disse. Vi har tatt ut mye synergi ved disse premissene, og vi har et ensartet miljø. Det er sterke økonomiske incentiver for å utnytte disse bedre og mer da vi har ”ledig kapasitet” på sw/hw.

2.6.2 Sentrale IKT-veivalg og milepæler de siste 10 årene

Følgende oversikt viser i tilnærmet kronologisk rekkefølge sentrale veivalg siden 2001:

• Valg av utviklingsplattform/-verktøy (.NET/Visual Studio/C#) og DB (MS SqlServer 200n)

• dotNET basert foretrukket målarkitektur for webapplikasjoner og bruk av Team Foundation Server (FTS)

• Innføring av webapplikasjonen Fellesinfo som sentral kodeverks- og tilgangsstyringsdatabase

• Valg av gruppevare/epostløsning (Exchange/Outlook)

• Innføring av Forurensning som ny dotNET-baserte klient/tjener fagapplikasjon (på Citrix)

• Valg av EpiServer som publiseringsplattform og etablering av xxx.xxxxxxxxxxx.xx

• Innføring av Miljøatlas karttjenester/-modul ved xxx.xxxxxxxxxxx.xx på ESRI-plattform

• Valg av ePhorte som elektronisk arkivløsning og Agresso som virksomhetsportal for ERP og fakturahåndtering

• Valg av xxx.xxxxxx.xx som plattform for virksomheters innrapportering til oss og senere etablering av 6+ lenketjenester til vår egen innrapporteringstjeneste "Klifinn"

• Konvertering av vårt etatsnettsted xxx.xxx.xx til EPiserver-plattform og senere nye nettsteder

• Etablering av datavarehusløsning (m/ Report Builder/Xxx.xxxxxxxx) for Forurensning

• Innføring av miljødatabasen Miljødata og Reporting Services ved xxx.xxxxxxxxxxx.xx

• Utvikling av den web-baserte Plan&Rapport som vp- og rapporteringsløsning

• Tilknytning av Fellesinfo til enhetsregisteret i Brønnøysund og matrikkelen hos Kartverket

• Utvikling av webapplikasjonen Adgang for desentralisert tilgangsstyring for eksterne brukere

• Utvikling av nettstedet xxx.xxxxxxxxxxxxx.xx som ”Forurensning på nett” (mot datavarehus)

• Utvikling av kartapplikasjonen Vannmiljø basert på dotNET / ArcGis-server

• Etablering av Altinn2 lenketjenester basert på Active Directory Federation Services

• Utvikling av rapporterings/graftjenesten Miljøtall basert på dotNET

• Utvikling av saksbehandlingsløsningen Klimatall basert på dotNET webteknologi

• Utvikling av innrapporteringsløsningen Kjemdekl basert på dotNET webteknologi

• Utvikling av ws og fødereringstjenester for eksternt kjørte løsninger, eks xxx.xxxxxxxxxxxxxxxxxx.xx

2.6.3 Målarkitektur, dotNET rammeverk og krav til kompetanse

I perioden 2001-2014 har vi konvertert/modernisert flesteparten av våre webapplikasjoner, klient-

/tjenerapplikasjoner og nettsteder til moderne dotNET baserte IKT-utviklings-/driftsplattformer. P.t er det kun løsningen Grunnforurensning som kjører på en gammel ASP-plattform fra tidlig 2000 tall,

men denne løsningen er i prosess for nyutvikling. Flere av våre løsninger er laget av samme leverandør i perioden 2003-2007 og har visse elementer av gamle dotNET rammeverk i seg (som gradvis blir fjernet ved vedlikehold/videreutvikling). De fleste løsninger er bygget omkring tilgangsstyrings- og kodeverksdatabasen Fellesinfo. Konsulenter vil se klare likheter mellom løsningene i GUI, bruk av felleskomponenter, tilgangsstyring etc.

Vi søker å lage ny funksjonalitet/løsninger baserte på beste-praksis innen dotNET/C# utvikling. Nye løsninger er i større grad basert på moderne beste praksis.

2.6.4 Føringer for IKT-utvikling de nærmeste årene

Vi er i dag i en konsolideringsfase hvor vi for å skape merverdi prioriterer videreutvikling av løsninger vi allerede har laget (dvs. gjen-/merbruk). Vi bruker f eks. store beløp på vedlikehold/videreutvikling av løsningen Forurensning samt på "Klifinn", som er vår egen innrapporteringsplattform/-løsning. De senere årene har det blitt brukt mye ressurser på løsningene Forurensning, Klimatall og Kjemdekl, og det forventes at videreutvikling av disse vil kreve mye ressurser videre.

I fm sammenslåingen mellom DirNat og Klif i 2013 er det forventninger fra departementet om effektiviseringsgevinster, og IKT har også fått kutt på 2014-budsjettet. Det er derfor en viss usikkerhet om nivået på ikt-satsing i de neste årene.

Vi tror at fremtiden vil gi mer kompliserte og sammensatte løsninger; Nettsteder får avanserte innholdstjenester med datavarehus, avanserte rapporter, integrerte kartløsninger, integrasjon med økonomisystem og bank etc. Fagapplikasjoner blir på samme måte mer kompliserte og funksjonsrike. Løsningene blir i større grad ”hybrider”. Når et nytt behov oppstår vil vi primært vurdere om behovet (best) kan dekkes ved en utvidelse av en av de eksisterende løsningene, sekundært om det er mulig å kopiere deler av kodeverk/konsepter fra eksisterende løsninger for raskt å få opp et rammeverk i en ny løsning. Dette inkluderer også å trekke synergi fra flere ulike løsninger eller lage ”hybrider” basert på flere plattformer. Først når de nevnte vurderinger ikke har gitt føringer om gjenbruk vil vi vurdere nye plattformer/verktøy.

Vi har i hovedsak våre fagapplikasjoner installert på egne servere, men det finnes unntak:

• EE-registeret

• Deklarasjon av farlig avfall og radioaktivt avfall (utvikles p.t)

Disse løsningene er laget av ekstern oppdragstaker som også drifter og forvalter løsningen.

Det kan være ulike grunner til at vi velger å outsource en løsning, eks krav til oppetid som overgår vår egen "SLA", at vi ønsker tilgang til kompetanse/ferdigheter som ikke finnes på rammeavtalen etc.

Den nye rammeavtalen åpner for at leveranser kan gjøres i Trondheim, eller at det lages en løsning som skal kjøres hos en 0.xxxxx tjenesteyter (webhotell eller liknende).

2.6.5 Utvikling/vedlikehold utføres i våre lokaler på våre maskiner

Vår politikk tilsier at utviklere sitter fysisk i våre lokaler i Xxxxxxxxxxx 00 (på Helsfyr i Oslo) og bruker vår infrastruktur (utviklings-pc og test-/produksjonsservere) og er tilknyttet våre servicebaserte tjenester og felles infrastruktur når de løser oppdrag for oss. Så fremt vi har tilstrekkelig kontorplass. Dette gjelder både ved lengre utviklingsløp og ved ad-hoc feilretting/videreutvikling.

Årsaken er å sikre at fellestjenester (spesielt bruker-/tilgangsdatabase og felles kodeverk) brukes og at løsningen fungerer feilfritt i alle ledd i utviklings- og test- og produksjonssettingslinjen. Videre fordi vi har en praksis med utstrakt direkte kommunikasjon mellom bruker-representanter og utviklere.

Oppdrag er av varierende lengde og intensitet. Dette avtales med leverandør i hvert enkelt tilfelle. Ved lengre utviklingsløp ser vi for oss at konsulenten sitter hos oss i fulltid, med fratrekk av ca. ½ dag i uken for å ivareta kontakt med egen organisasjon (møter, oppfølging, kompetanse-ivaretakelse mm). Ved tilkalt bistand ser vi for oss tilkallingstid som reguleres i avtale, og som varierer fra umiddelbart oppmøte (ved akutte feil) til planlagt oppmøte med dagers varsel. Mer om dette beskrives i konkurransegrunnlaget i neste fase.

3 Ny rammeavtale – mål og tanker om organisering

I det følgende beskrives våre erfaringer med dagens rammeavtale (som løper 2011-2014) og våre målsetninger for en ny rammeavtale fra 2015-2019.

3.1 Dagens rammeavtale

Vi er i siste år av en 4 års rammeavtaleperiode (3+1 år) med 4 partnere:

• 3 parallelle partneravtaler på teknologi områdene .NET/Sharepoint og EpiServer

• 1 separat partneravtale på teknologiområdet ESRI/Arc* (geodata-/kartløsninger)

Rammeavtalen ble etablert i 2010 (av Klima- og forurensningsdirektoratet) og gjelder kun for tjenester levert i våre kontorlokaler i Oslo – på løsninger som kjøres på servere fysisk plassert i Oslo.

Rammeavtalen dekker følgende tjenesteområder (leveranseelementer):

1. Merkantil forvaltning og rammeavtaleforvaltning - kostnadsfrie administrative tjenester

2. Ledelse av prosjekt og mindre oppdrag

3. Verdiøkende rådgivning - relatert til de teknologier og løsninger vi har

4. Analyse og konseptutvikling - "frivillig", men dekkes av alle partnere

5. Behovsorienterte tjenester - krav-/behovsspesifisering, planlegging etc.

6. Brukerorienterte tjenester - design, brukertesting, brukervennlighet etc.

7. Utvikling av løsninger innenfor teknologiområdene

8. Test-/produksjonssetting av løsninger

9. Drift og forvaltning – vedlikehold og videreutvikling av eksisterende løsninger

10. IKT-arkitektur - relatert til de teknologier og løsninger vi har

11. Dokumentasjonsarbeid – relatert til de teknologier og løsninger vi har

Vi har hatt kontrakt med følgende leverandører (rammeavtalepartnere) for teknologiområdene:

	Microsoft .NET/SharePoint Utv.plattform klient/tjener og web	EpiServer publiserings- plattform for nett	ESRI/Arc Utv.plattform for geodataløsninger
CGI (tidligere Logica)	✓	✓	🗶
Evry (tidligere EDB)	✓	✓	🗶
Itera Consulting	✓	✓	🗶
Geodata	🗶	🗶	✓

3.1.1 Mål og ønskede gevinster i dagens rammeavtale

Vi evaluerte erfaringene fra rammeavtalen (2007-2010) og definerte målsetninger og ønskede gevinster i en bred intern prosess. Pris, kompetanse og bredde/fleksibilitet i løsninger og leveranser var viktig for oss. Vi definerte en leverandørmodell som best underbygget ønskede mål/resultater, og konkurransegrunnlaget ble utformet spesifikt for å nå våre mål. Erfaringene fra anskaffelsen er at vi i høy grad oppnådde ønskede resultater i kontraktene. I særlig grad fikk vi:

• God dekning av teknologiområdene dotNET/Sharepoint og EpiServer med 3 parallelle fullservice-leverandører

• Kompetent/erfaren leverandør valgt for de faste vedlikeholds-/videreutviklingskontraktene til lav ressursleiepris

• Generelt gode pris- og leveransebetingelser fra alle leverandører

3.1.2 Noen nøkkeltall om bruk av rammeavtalen så langt

Vi har brukt ca. 10-12 mill. kr pr. år i ikt-utvikling og forvaltning. En betydelig andel av midlene har gått via IKT-rammeavtalen. Våre tall viser et forhold i utgiftene på ca. 3:1 mellom utvikling av fagsystemer vs. nettsteder. Siden 2011 har vi gjort et høyt antall avrop (nye kontrakter). Følgende opplisting gir en overordnet oversikt over aktivitet frem til i dag:

	Når	Partner	Xxxxxx (timer)
Vedlikehold av eksisterende fagapplikasjoner (->2014)	Initialt	Logica (nå CGI)	3000-4000 timer pr år
Vedlikehold av eksisterende nettsteder (->2014)	Initialt	Logica (nå CGI)	-> 1000 timer pr år
Vedlikehold av eksisterende GEO dataløsninger/-infrastruktur	Initialt	Geodata	<= 1700+ timer pr år
Nytt intranett	Initialt	Logica (nå CGI)	Ca. 1500 timer
Kommuneveileder på nett	2011->	Itera	2000+ timer
Klimatall (Klimakur 2020)	2011->	Itera	7000++ timer
Innføring av kjemikaliedeklarasjon og mottaksløsning	2012->	Evry	8000+ timer
Miljøtall (en tjeneste på xxx.xxxxxxxxxxx.xx)	2012->	Itera	500+ timer?
Forstudie deklarasjonsløsning farlig avfall	2011->	Evry	1000+ timer
xxx.xxxxxxxxxxxxxxxxx.xx	2013	Itera	1200+ timer
Forstudie saksbehandlingsstøtte på biocidområdet	2013	Itera	300+ timer
Div. arbeid med brukertilpasning/brukertesting	2012->	CGI (15 Meanings)	500+ timer
Fødereringsløsning mot ID-porten og Altinn	2013/14	Evry og CGI	Ca. 500 timer

3.1.3 Erfaringer fra dagens rammeavtaleperiode 2010-2014

Gode priser og stor bredde i leveranseområdene har medført bruk av rammeavtalen til mange små og store prosjekter. Det har vært en fin oppgavefordeling mellom partnerne, og det er positive tilbakemeldinger fra partnerne på vår rolle, og også intern tilfredshet med rammeavtalen.

Vi fikk gode personressurser og leveransebetingelser fra alle leverandører. Rammeavtalene har medført tidsbesparelser i anskaffelsesprosessen. Vi har stort sett hatt kontinuitet i leverandørenes domenekompetanse om oss, men dessverre har de merkantile ressurspersoner ofte blitt byttet ut – noe som har vært uheldig da domenekunnskapen disse må ha om oss/avtalen er tidkrevende å bygge.

Vi observerer at rammeavtalen også har hatt noen uønskede/negative effekter. Vi fikk kun store fullservice-leverandører på rammeavtalen som en konsekvens av våre krav om stor bredde i leveranseområder og at vi kun ønsket 3 parallelle rammeavtaler. I etterkant har de 3 aktørene blitt enda større (og "tyngre") grunnet sammenslåinger/oppkjøp etc. Vi ser at størrelsen på noen områder er positivt, men også at ensrettingen av leverandører har medførte mindre mangfold i tilbud. At en leverandør er stor og dekker "alle" områder, er ingen garanti for at de er "best" på alle områder.

Tidlig i rammeavtaleperioden så vi sterk konkurranse mellom partnerne, men etter hvert har vi sett mer "strategiske" tilbyderne, og at tilbud er mindre bearbeidede og "svakere". Vi har sett at 1-3 tilbud ikke har vært tilstrekkelig til å belyse en leveranse tilstrekkelig, dvs. at tilbud har vært "for like" eller at alternative angrepsmåter ikke har blitt belyst/vurdert.

3.2 Føringer for ny rammeavtaleperiode 2015-2019

Vi har i dag et realisert prisnivå mellom 1100 og 1200+ kr. pr time inkl. mva., og det er akseptabelt. Vi vil i ny rammeavtaleperiode fortsatt være opptatt av at timepris skal være lav, dvs. at eksklusiv leveranseadgang, betydelig volum og til dels redusert risiko for leverandør må gi betydelig prisavslag. I særlig grad må dette gjelde der vi gjør ressursleie i kortere eller lengre tidsperioder.

Vi har i hovedsak hatt gode personressurser, og vi har sett god kontinuitet over tid fra partnerne. Vi ser at tilgang til dyktige/erfarne ressurser er kritisk og det delvis kan sikres fra vår side med langsiktighet/volum i faste kontrakter, men også ved at tilbydere garanterer navngitte ressurspersoner (eller tilsvarende) og gode leveringsbetingelser. Vi er ikke interessert i at prosjekter bemannes med nyutdannede eller "ferske" konsulenter.

Rammeavtalen har medført administrative besparelser hos oss og leverandørene. De kostnadsfrie administrative leveranseområdene fungerer godt og skal videreføres – og vi ønsker at partnere skal etterstrebe kontinuitet i de merkantile/administrative ressursene for å hindre at erfaringer går tapt.

Når det gjelder gjennomføringsmodell ser vi at vi som hovedregel ønsker å kjøre en klassisk fossefallsmetode (steg-port), men hvor smidighet er tatt høyde for i plan/budsjett. Vi bør etterstrebe en mix av ulike leverandører for å ha fleksibilitet i prosjekttilnærming. Vi har svært god erfaring med at partnerne sitter i våre lokaler under oppdragene i tett dialog med våre egne folk, og dette er en basisbetingelse. Men vi åpner for at leverandør periodisk kan sitte i egne lokaler (ved plassmangel hos oss), eller at de kan levere deler av tjenestene ved vårt kontor i Trondheim.

Bredde og dybde i leveranseområdene bør opprettholdes, men med en annen innretting både i innhold og i relasjon til antall partnere. På dotNET/SharePoint og EpiServer har vi hatt (for) få og (for) like leverandører. Det er et ønske å ha et høyere antall tilbydere på hvert leveranseområde (med noe variasjon i antall). Vi vil ikke kreve at partnere har fullservicetilbud, men vi ønsker heller ikke en for fragmentert mix av leverandører. Enkelte leveranseområder vil derfor åpnes for spesialiserte "nisjeleverandører", eks. konseptutvikling og spesifikasjonsarbeid, samt behovs-/brukertilpasning.

Det økte antallet leverandører kan bli benyttet proaktivt av oss for (styring av) leverandørsamarbeid i leveranser, ved at vi selv tidvis kan ønske å styre/"sette sammen" leveranser og kompetanse. Vi ønsker som hovedregel ikke partnere med egne underleverandører, da dette monopoliserer kompetanse og gjør den vanskelig tilgjengelig på tvers.

3.2.1 Visjon for velfungerende rammeavtale 2015-2019

Vår visjon for en velfungerende rammeavtale(-partner) er:

• Merkantil oppfølging – vi ønsker leverandører med faste merkantile kontaktpersoner som tar en proaktiv og konstruktiv rolle for å løse våre utfordringer i samarbeid med våre egne ressurspersoner. Grunnet langsiktighetene i rammeavtalen bør det etterstrebes at ressurspersoner er faste i avtaleperioden

• Ledelse – ledelse/styring av leveranser må være av høy kvalitet, og at den kan skaleres ut fra størrelse/kompleksitet i oppgave som skal løses (herunder risikobilde) og at flere gjennomføringsmodeller kan benyttes

• Erfaring – vi må ha tilgang til erfarne seniorressurser med betydelig erfaring fra relevant arbeid/-former

• Kompetanse - vi ønsker seniorressurser med bred/dyp kompetanse om våre løsninger/teknologier, som kan jobbe på tvers av løsninger over tid og som raskt er i stand til å omstille seg til nye utfordringer og kompetanseområder (nye verktøy/ plattformer) der som dette blir nødvendig

• Stabilitet (kontinuitet) i bemanning er viktig da vi verdsetter en fast ressurspool som lærer seg å kjenne oss, våre måter å arbeide på, våre løsninger, sammenhenger etc.

• Fleksibilitet – vi må sikres god og rask tilgang til avtalte tjenester/ressurser når behov oppstår. Vi ønsker konsulenter med evne og ønske om å jobbe både med større dedikerte utviklingsoppgaver og samtidig med ad-hoc feilretting/service, gjerne på tvers av løsninger. Fleksibilitet i samarbeid med andre leverandører er også viktig da våre løsninger blir mer og mer kompliserte og sammensatte

Vi håper dette "målbildet" vil hjelpe interessenter til å vurdere om vi er riktig kunde, og hvordan de best mulig kan være en positiv bidragsyter til å nå våre visjoner.

3.2.2 Teknologier i neste rammeavtaleperiode

Det har ikke skjedd endringer i vår basisplattform siden sist rammeavtale. Som beskrevet har vi en Microsoft plattform i bunnen (operativsystemer på klienter og servere), og på MS-SQL database og dotNET utviklingsplattform. Vi bruker ulike services fra Microsoft i form av Reporting/Analysis services og Federation services. Vi benytter SharePoint og ePhorte for dokumenthåndtering (og arkiv) og EpiServer for publisering. Vi benytter Agresso økonomisystem og elektronisk fakturahåndtering. Vi har noen få mobile løsninger (apps). På geodataområdet benytter vi standardprodukter fra ESRI (Arc* produkter).

Våre løsninger er installert og driftes på våre egne servere/hardware i Oslo og Trondheim. Vi har egne driftsressurser for våre teknologier. De tilbydere som ønsker anledning til å levere på de teknologirelaterte leveranseområdene må i kvalifiseringsfasen vise at de har tilstrekkelig teknisk kompetanse og erfaring på våre eksisterende teknologier.

3.2.3 Leveranseområder i neste rammeavtaleperiode

Vi har satt opp en ny modell for våre leveranseområder (som kan endres noe i tilbudsfasen). Modellen består av obligatoriske leveranseområder som alle partnere må dekke og det er 8 valgfrie områder hvor tilbydere kan be om anledning til å levere på. Vi har for hvert område beskrevet hvor mange partnere vi ønsker, antallet varierer fra 3 til 10 partnere. Vi tildeler kontrakt til de tilbydere med best tilbud pr. leveranseområde. Der det er flere enn ønsket antall tilbydere på et område tildeles kontrakt til de beste. Selv om en leverandør ønsker å levere på alle 8 valgfrie områder, så kan resultatet bli at de tildeles kontrakt på alt fra 2 til 8 stk. Med en slik modell er samlet antall partnere svært vanskelig å anslå, men et guesstimate er 10-15 stk, dvs betydelig flere enn dagens 4.

Det må tilbys leveranse på minimum 2 valgfrie områder i tillegg til de obligatoriske. Tilbud på de obligatoriske områdene må stå i forhold til2 antall og hvilke leveranseområder det ønskes å leveres på.

	Leveranseområde	Obligatorisk?	Maksimalt antall partnere	Kommentar
O1	Merkantil rammeavtaleforvaltning (som kostnadsfri tjeneste) – relatert til V1-V8	Obligatorisk	Alle	Må dekkes av alle
O2	Prosjekt-/oppdrags-/arbeidsledelse – relatert til V1-V8	Obligatorisk	Alle	Må dekkes av alle
V1	Analyse/konseptutvikling og kravspesifisering	Valgfritt	6	Tildeles de 6 beste tilbud
V2	Behovs-/brukerorienterte tjenester	Valgfritt	10	Tildeles de 10 beste tilbud
V3	Utviklingstjenester for web- og klient/tjenerløsninger i dotNET (C#) teknologi, herunder mobile løsninger3 -arkitektur -utvikling -test/produksjonssetting	Valgfritt	8	Tildeles de 8 beste tilbud

2 Leverandør må kunne skalere (kapasitet/kompetanse) i forhold til antall leveranseområder

3 Utvikling av applikasjoner (apps) for smarttelefoner/nettbrett inngår i dette leveranseområdet

	-drift og forvaltning -dokumentasjon av løsninger
V4	Utviklingstjenester for dokumentdelings- og portalløsninger i SharePoint teknologi -underpunkter som over	Valgfritt	6	Tildeles de 6 beste tilbud
V5	Utviklingstjenester for publiseringsløsninger i EpiServer v.6/7/* CMS teknologi -underpunkter som over	Valgfritt	6	Tildeles de 6 beste tilbud
V6	Utviklingstjenester for kartløsninger i ESRI/Arc* teknologi -underpunkter som over	Valgfritt	3	Tildeles de 3 beste tilbud
V7	Utviklingstjenester for grensesnitt/integrasjoner mot Ephorte	Valgfritt	4	Tildeles de 4 beste tilbud
V8	Utviklingstjenester for grensesnitt/integrasjoner mot Agresso	Valgfritt	4	Tildeles de 4 beste tilbud

3.2.4 Leveranse Oslo/Trondheim

Miljødirektoratet har kontorer i Oslo og Trondheim. Denne rammeavtalen skal erstatte Klifs rammeavtale (2010-2014) hvor alle tjenester utføres i Oslo-lokalene. Vurderingen av om Trondheim skal ha en egen rammeavtale er igangsatt, men ikke avsluttet, og vi kan derfor ikke fullt ut ta høyde for behovet nå. Rammeavtalen vil primært gjelde leveranser i våre lokaler i Oslo, men vi ønsker opsjon fra tilbyderne om å kunne motta tjenester ved Trondheimskontoret. Vi krever ikke at tilbydere har egne kontorer/leveranseapparat i Trondheim – vi ønsker at partnere etter avtale kan gjøre hele/deler av leveranse i Trondheim i stedet for Oslo. SSA-R legger generelle føringer for dekning av reisetid/ utgifter. Vi vil ta inn følgende betingelser i bilag til rammeavtalene:

• Tjenester er ”fritt levert” vår kontoradresse i Oslo, verken reisetid/utgifter T/R vår adresse er fakturerbare (iht. SSA-R)

• Ved behov skal tjenester som en opsjon leveres i Trondheim.

• Der partner har kontor/leveranseapparat i Trondheim skal tjenester også der være fritt levert. Der partner ikke har stedlig representasjon i Trondheim dekkes reisekostnader etter avtale etter statens satser

3.3 Antall leverandører som kvalifiseres og kan delta i konkurransen

Regelverket tilsier at vi skal kvalifisere et antall leverandører vi mener er tilstrekkelig til å oppnå en god bredde og dybde i konkurransen, slik at vi har et tilstrekkelig antall tilbud å velge blant ved tildeling av rammeavtalene. Grunnet vår leveransemodell og ønsket antall partnere har vi kommet til at det ikke er hensiktsmessig å sette noen øvre grense for antall leverandører som vil bli invitert til å delta i konkurransen. Vi er dog i henhold til en fortolkning av artikkel 44 i anskaffelsesdirektivet (j fr anskaffelsesveileder punkt 9.4.2) forpliktet til å angi et minsteantall. I lys av antall leveranseområder og ønsket antall partnere setter vi minsteantall til 15 leverandører som vil bli invitert til å inngi tilbud.

Vi plikter også å opplyse om hvilke kriterier som vil bli benyttet ved utvelgelse av leverandører som inviteres til å inngi tilbud. Vi har satt opp spesifikke dokumentasjonskrav for tilbyderne på de ulike leveranseområdene (jfr eget kapittel) – som vil avklare om leverandør er kvalifisert og ev. grad av kvalifikasjoner. Vi ber om dokumentasjon av kvalifikasjoner pr leveranseområde og vil innenfor hver av disse invitere de best kvalifiserte samt vurdere hvilken sammensetning av leverandører som vil gi den beste konkurransedynamikken.

3.4 Samarbeid mellom partnere (etter inngåelse av rammeavtale)

Vi ønsker å være tydelig på at samarbeid mellom partnerne (etter tildeling av rammeavtaler) vurderes som ønskelig og nødvendig. Med det antallet partnere vi forventer at det kan bli, er det naturlig at de vil ha individuelle styrker og svakheter. Vi ønsker å ha en proaktiv rolle i å sikre "den beste leverandørmiks" til ulike oppgaver. Vi ser for oss å bruke ulike virkemidler:

• For kortere eller lengre tidsrom å tildele avtaler til en eller flere leverandører som får en særlig rolle i å støtte oss på utvalgte områder – i samarbeid med andre partnere (eks. vedlikehold og arkitektur)

• Vi åpner også for at partnere som har svake områder, kan bli utfordret til å samarbeide med andre partnere for å styrke en samlet leveranse

Vi har i dagens avtale tidvis latt partner som har støttet oss i kravspesifisering også konkurrere om implementering. Selv om vi sørget for å gi tilstrekkelig tid og all relevant dokumentasjon til de øvrige partnere så vi at dette medførte svak (eller ingen) konkurranse. I denne rammeavtaleperioden vil vi ikke tillate en slik praksis. Vi vil skille mellom behovs-/spesifikasjonsfase og implementering4, og

4 Et implementeringsprosjekt vil ofte ha en "klassisk" fase med detaljert spesifikasjon som en del av leveransen

bruke ulike partnere til disse. Vi ser også for oss at utforming av brukerdialog/-grensesnitt kan være en frittstående fase, og hvor vi enten kan tildele leveransen til implementeringspartner eller til en av "nisjeleverandørene".

4 Avtaleform for rammeavtale og tildelingsavtaler

4.1 SSA-R som rammeverk for rammeavtalen

I dagens rammeavtale brukes standardavtalen SSA-R Konsept for rammeavtale. SSA-R er utviklet av Statskonsult (nå DIFI), og er ikke endret siden 2007 og er p.t tatt bort fra DIFIs anskaffelsesnettsted: xxx.xxxxxxxxxxxx.xx . DIFI har der lagt ut et nøytralt rammeverk fra 2010, som primært er innrettet på varekjøp. Dette dekker ikke tjenestekjøp på en god måte slik som SSA-R gjør. Vi har vært i kontakt med DIFI, og de sier at SSA-R fortsatt kan lastes ned og benyttes: xxx.xxxxxxxxxxxxxxxxxxxxxx.xx/xx/XXX-X-000000_xxx0.xxx .

I lys av våre positive erfaringer med SSA-R legger vi til grunn at denne fortsatt skal brukes i ny rammeavtaleperiode, og at dette vil sikre følgende verdier:

• Er spesifikt laget for rammeavtaler og tjenestekjøp (for offentlige kunder)

• Har med hell vært benyttet av oss i flere rammeavtaleperioder med samme innretting/scope

• Er enkel, men en dekkende overbygning for de tildelingsavtaler (i form av andre nye og oppdaterte SSA'er) som blir inngått for avrop

• Følger bilagsinndeling som øvrige SSA'er, og har et godt utgangspunkt for innhold i de ulike bilag

• Er konsekvent i regulering av timebasert bistand, men hvor vi som kunde kan be om fast totalpris

• Er ryddig på betalingsbetingelser

• Er tydelig på disponering av personell (tilbudt kompetanse)

4.2 SSA-avtaler for tildelingsavtaler

SSA-R legger opp til at det for hvert avrop skal etableres en egen tildelingsavtale med valgt rammeavtalepartner. Vi har gjort dette i tidligere rammeavtaler, og det fungerer godt. Vi forbeholder oss rett til å bruke statens standardavtaler for de ulike avrop som gjøres initialt og underveis i rammeavtalens varighet. Dagens SSA' er beskrevet på xxxx://xxxxxxxxxxxx.xx/xxx/xxxxxxxxx/xxxxxxx- standardavtaler-ssa .

Vi tror følgende SSA'er vil være mest aktuelle:

• Konsulenttjenester: SSA-O og SSA-B (og SSA-B enkel)

• Programutviklingsavtalen: SSA-U

• Vedlikeholdsavtalene: SSA-V og SSA-V lille

• Kjøpsavtalene: SSA-K og SSA-K lille

• Mulig: Tilpasningsavtale: SSA-T

• Mulig: Smidigavtalen: SSA-S

• Mulig: Driftsavtalen: SSA-D

4.3 Tildeling av initiale avrop til et utvalg rammeavtalepartnere

Samtidig med at tilbydere konkurrerer om generell anledning om å levere på gitte områder, vil vi ha konkrete oppdrag (avrop) det konkurreres om. Vi har god erfaring med dette fra tidligere rammeavtaler. Det sikrer både en riktig prising av avtalene samt at leverandørene får et ”utstillingsvindu” hvor de kan vise sine spesifikke fortrinn i konkrete leveranser.

Vi ser for oss "bundling" av eksisterende løsninger/nettsteder i ulike vedlikeholdsavtaler som konkurranseutsettes i initiale avrop ved inngåelsen av rammeavtalen. Vi ser for oss fire slike:

1. Vedlikehold/videreutvikling av eksisterende dotNET baserte webapplikasjoner og klient/tjener applikasjoner, rapporteringsløsninger og datavarehus med mer.

2. Vedlikehold/videreutvikling av eksisterende EpiServer baserte nettsteder og publiseringsløsninger

3. Vedlikehold/videreutvikling av eksisterende SharePoint baserte dokumentasjonshåndteringsløsninger

4. Vedlikehold/videreutvikling av eksisterende ESRI/Arc* baserte kartløsninger

Prosessen vil være slik at vi tildeler rammeavtalene ut fra tildelingskriteriene, og deretter umiddelbart tildeler kontrakter for de initiale avropene til beste tilbud - innenfor partnere som er tildelt rammeavtale. Kontrakter for avrop må derfor være ferdig forhandlet sammen med rammeavtalene før tildeling foretas.

4.3.1 Vedlikehold/videreutvikling dotNET web+klient/tj. applikasjoner Enhet for IKT-utvikling og forvaltning OITU har en egen fast tilsatt utvikler som arbeider med noen av de nevnte løsningene. Vårt behov er utviklingsressurs(er) fra 0,5 til 1,5 årsverk (avhengig av

finansiering) som skal arbeide sammen med vår egen utvikler.

Følgende faglige- og administrative løsninger inngår i avtalen:

- Fellesinfo – webapplikasjon for intern administrasjon av sentralt kodeverk mm

o Herunder intern og ekstern Active Directory tilgangsstyringsløsning

o Grensesnitt mot API’er fra DIFI, Brønnøysund og Statens Kartverk mfl.

o Active Directory Federation Services for å håndtere autentisering av Altinn lenketjeneste brukere både for egne løsninger og for enkelte eksterne tjenester

- Adgang – webapplikasjon for desentral administrasjon av våre brukergrupper

- Forurensning – klient/tjener basert saksbehandlingsløsning for direktoratet og eksterne brukere

o Inkl. datavarehus og rapporteringsløsninger (Report Builder)

o Inkl. xxx.xxxxxxxxxxxxx.xx (EpiServer-site med dotNET kode rett mot datavarehus)

- "Klifinn" – vår egen skjemaportal hvor vi tilbyr innrapportering for næringslivet

- Plan og rapport – webapplikasjon for planlegging, tidsregistrering og rapportering inkl. rapporteringsløsning basert på Reporting/services

Det skal være opsjon om innfasing av andre/nye løsninger etter hvert, disse er aktuelle:

o Klimatall – en analyseløsning for klimaeffekt/kostnader

o Kjemdekl – en deklarasjonsløsning og mottakssystem for farlige kjemikalier

Valgt leverandør vil på grunn sin sentrale rolle i våre sentrale fellesløsninger også være en hovedsamarbeidspartner for arkitekturmessige veivalg/forhold i forhold til disse.

4.3.2 Vedlikehold/videreutvikling EpiServer nettsteder

Miljødirektoratet har en nyansatt webmaster med bakgrunn som systemutvikler. Det er behov for tilleggsressurser for å støtte opp med vedlikehold og videreutvikling av våre eksisterende EpiServer baserte nettsteder. Følgende nettsteder er aktuelle for å inngå i avtalen:

• Vårt intranett

• xxxx://xxx.xxxxxxxxxxxxxxxxx.xx/ med underliggende nettsider/funksjoner

• xxx.xxxxxxxxxxx.xx / xxx.xxxxxxxxxxx.xx, herunder tjenesten "Miljøtall"

• xxx.xxxxxxxxxxxx.xx

• xxx.xxxxxxxxxxx.xx

• xxx.xxx.xx

Det skal være opsjon om innfasing av andre/nye nettsteder etter hvert. Valgt leverandør vil være en hovedsamarbeidspartner for arkitekturmessige veivalg/forhold for disse.

Nettstedene deler samme teknologiske plattform, men har ulik fordypning og funksjonalitet. Aktuelle tjenester som vil bli tatt ut er eks:

• Mindre funksjonelle endringer på eksisterende sidetyper, evt nye sidetyper

• Mindre designendringer

• Nye funksjoner og retting av feil i dagens løsninger

• Søkefunksjonalitet

• Oppgradering til nye versjoner av plattform

På samme måte som avrop for faglig-/administrative løsninger kan det være en fordel at det er samme personer/team som dekker inn denne avtalen. Hvor stor omsetningen i avtalen vil være er vanskelig å si noe generelt om da det avhenger av årlige planer og budsjetter.

4.3.3 Vedlikehold/videreutvikling SharePoint dokumentasjonsløsninger

Miljødirektoratet har en fast ansatt webmaster med bakgrunn som systemutvikler, som primært arbeider med EpiServer, men som også har noe kompetanse på SharePoint. Vi bruker SharePoint (p.t 2010-ed) til prosjekt-/arbeidsrom og dokumentdeling internt og eksternt. Det er behov for tilkalt bistand til feilretting/småendringer samt spesialistbistand og hjelp til oppgraderinger og generell videreutvikling. Omfang vil variere over tid.

4.3.4 Vedlikehold/videre utvikling av Geodata (kart)løsninger

Direktoratet har spesialutviklede kartbaserte løsninger som spenner fra eks kartpresentasjoner ved Miljøstatus xxxx://xxx.xxxxxxxxxxx.xx/xxxx/ (”Miljøatlas”) basert på ArcGIS Server og Javascript for å betjene karttjenester, over mot tung kartbasert fagapplikasjon xxxx://xxxxxxxxx.Xxxxxxxxxxxxxxxxx.xx/ som kombinerer saksbehandling gjennom vanlig webapplikasjon kombinert med kartbruk. I tillegg er lett kartapp-klient bygget på ESRI Java script API mobilt rammeverk, eks Xxxxxxxxx.xxxxxxxxxxx.xx

Vi ser for oss at valgt leverandør for dette avropet gjør vedlikehold og videreutvikling av nevnte løsninger. Det kan bli aktuelt å innlemme andre løsninger/nettsteder inn i denne kategorien senere.

4.3.5 Nye tjenestebehov – nyutvikling av løsninger

Nyutvikling skjer som minikonkurranse og avrop mellom de partnere som har rammeavtale på aktuelle leveranseområder. I konkurransegrunnlaget for en minikonkurranse beskriver vi hvilke leveranseområder som omfattes og inviterer vi de partnere som har kontrakt på disse områdene til å gi tilbud. Ved nye behov vil vi kjøre arbeid etter to ulike mønstre:

• Faseinndelt arbeid (ett eller et ad-hoc utvalg leveranseområder)

Vi bruker oversikten over de leverandører som har avtale på områdene og kjører minikonkurranse der aktuelt, og ved neste fase gjør vi ev. ny minikonkurranse

• Helhetlig arbeid (totalentreprise eller større mer sammensatte prosjekter)

Vi gir alle partnere anledning til å vurdere hvordan de best kan tilfredsstille våre behov/krav ved å gjennomføre en minikonkurranse

5 Detaljering av leveranseområdene (tjenester)

I dagens avtale har vi 11 leveranseområder, og i den nye avtalen planlegger vi å ha 10 områder. Vi gjør flere endringer i leveranseområdemodellen i den nye rammeavtalen. De viktigste endringene:

• Introduksjon av nye og mer tydelige teknologiområder

• Reorganisering av leveranseområdene, herunder at de er valgfrie (men med minimumskrav)

• Vi åpner for flere rammeavtalepartnere, herunder for mer spesialiserte "nisjeleverandører"

5.1 Obligatoriske leveranseområder

Områder som skal tilbys av alle tilbydere er:

• Merkantil rammeavtaleforvaltning

• Prosjekt-/oppdrags-/arbeidsledelse

Obligatoriske områder skal sikre at tilbyderne har et profesjonelt ledelses- og oppfølgingsapparat, både merkantilt og kommersielt. Dette er basert på de tjenester vi har hatt i tidligere rammeavtaler. I det følgende utdypes våre forventinger til respektive ytelser. Nivået på tilbudte tjenester må stå i forhold til det antallet (og hvilke) leveranseområder det ønskes å konkurrere om. Dvs. kapasitet og nivå på tjenester må skalere med antall leveranseområder.

5.1.1 Merkantil rammeavtaleforvaltning (O1)

De merkantile rammeavtaleforvaltningstjenestene skal være kostnadsfrie for oss, og skal sikre at vi får gode salgs- og oppfølgingstjenester for rammeavtalen og de tildelingsavtaler som inngås. Vi forventer at ressursen(e) som innehar rollen har et overordnet ansvar for at partner oppfyller sine kontrakts- messige forpliktelser.

Merkantil oppfølging av rammeavtalen og tildelingsavtaler:

• Tilbudsarbeid og forhandling (herunder minikonkurranse)

• Kontraktarbeid herunder endringshåndtering

• Status-/oppfølgingsmøter

• Sikre kontraktoppfyllelse

• Forvaltning av JIRA eller tilsvarende løsning der vi ikke benytter vår egen JIRA-installasjon

Spesifikt for tildelingsavtaler:

• Estimering *)

• Rapportering/oppfølging av fremdrift **)

• Deltakelse i prosjektstyre og avvikshåndtering

• Fakturering

*) Nødvendig estimering for at partner skal kunne legge frem et forpliktende pristilbud er kostnadsfritt merkantilt arbeid

**) Primært vedlikeholdsavtaler => overordnet ressurs- og statusrapportering med frekvens pr uke, 14'dag eller månedlig

5.1.2 Prosjekt-/oppdrags-/arbeidsledelse (O2)

Ledelsestjenestene er betalbare etter nærmere avtale i tildelingsavtaler, og skal sikre at leverandører leverer avtalt tjenester med avtalt kvalitet til avtalt tid, ressursbruk og kostnad.

Vi trenger profesjonell ledelse av visse typer oppdrag/prosjekter, avstemt mot arbeidets risikoprofil. Vi har definert ledelsesområdet slik at det favner bredt fra ledelse av prosjekter, via ledelse av avgrensede oppdrag over mot eks. "spillende trener" innenfor en vedlikeholdsavtale. Tjenestene skal være skalert i forhold til de leveranseområder det er gitt leveranse-avtale på, samt den avtaleform det er snakk om.

Som vi har skrevet om tidligere har vi standardisert på Prince2® metodikk, slik at det dette bør støttes.

Vårt krav og leverandørenes utfordring blir å bemanne denne rollen med rett kompetanse til rett tid (ofte på kort varsel). Tilbydere bes også merke seg at denne rollen vil bli brukt når det ev er samarbeid mellom flere av partnere, der en av partnere må ta et ansvar for å koordinere andre. Ved behov, og dersom partnerens ledelsesressurser besitter nødvendig kompetanse, kan det også være aktuelt med spesifikke ledelsestjenester innen:

• Metode – f.eks. MSF, EA, ITIL, kvalitetssikring, testmetodikk mm.

• Prosesskartlegging/-modellering

• IKT-strategi

• IT-governance

• Etc.

5.2 Valgfrie leveranseområder

I denne rammeavtaleperioden gjør vi justeringer i (de for leverandøren) valgfrie leveranseområdene. Vi gjør endringer i leveranseområdene og antallet ønskede partnere, for å imøtekomme erfaringer vi har fra dagens rammeavtale (se eget avsnitt). Det er 8 valgfrie leveranseområder, men vi har besluttet at tilbydere må tilby leveranse på minimum 2 av de valgfrie områdene for å unngå en for fragmentert og spesialisert sammensetning av partnere. For hvert leveranseområde har vi beskrevet antall ønskede partnere. Antallet varierer mellom 3 og 10 partnere.

Vi ber tilbydere lese grundig våre forventninger om de respektive leveranseområdene, for å unngå tidsbruk på en søknadsprosess som ikke vil kunne nå frem. Søknaden må være tydelig på hvilke leveranseområdet det ønskes å konkurrere om, og for hvert av områdene må kvalifikasjoner/kapasitet dokumenteres.

5.2.1 Analyse/konseptutvikling og kravspesifisering (V1)

Leveranseområdet skal sikre tilgang til kompetanse innen:

• Gjennomføre ide-/forprosjektfase

• Beskrive og detaljere en ide (ide-/mulighetsskisser)

• Behovs-/målgruppeanalyse

• Utvikle et konsept

• Beskrive og dokumentere behov og krav til en fremtidig løsning

• Fremlegge et beslutningsgrunnlag for gjennomføring av implementering

Leveranseområdet må sees i relasjon til de teknologispesifikke leveranseområdene V3-V8, da det er innenfor disse teknologiene som konsept skal realiseres og krav skal dekkes.

Vi ser for oss å ha 6 partnere, og at vi trolig vil se både spesialiserte tjenesteytere og fullservicepartnere med avtale på dette området. Merk at vi i rammeavtaleperioden - der vi har en faseinndelt prosess - ikke tillater partner som har levert på V1 å konkurrere om implementering av løsningen, dvs. V3-V8. Der det er snakk om en sammensatt leveranse er situasjonen en annen.

5.2.2 Behovs-/brukerorienterte tjenester (V2)

Dette leveranseområdet skal sikre at våre løsninger er forankret i behov og at de er godt brukertilpasset. Det er en forlengelse og videreføring av leveranseområde konseptutvikling og

kravspesifisering (V1). Leveranseområdet er mangslungent og kan bestå av et utall tjenester, isolert eller i sammenheng:

• Brukergrupper (roller/personas)

• Brukeropplevelse (user experience "UX")

• Brukskvalitet (usability)

• Trådskisser

• Informasjonsarkitektur (-struktur)

• Interaksjonsdesign (IxD)

• Grafisk design (profil)

• Brukergrensesnitt

• Papirprototyping/klikkbare prototyper

• Brukertesting

• Funksjonell (detaljert) løsningsspesifikasjon

• Søk (søkemotoroptimalisering)

• Bruk av sosiale medier

• Emnekart

Leveranseområdet må sees i relasjon til de teknologispesifikke leveranseområdene V3-V8, da det er innenfor disse teknologiene som konsept skal realiseres og krav skal dekkes.

Tjenester kan enten leveres isolert (i en fase eller forprosjekt) eller som en del av en totalleveranse. Vi ser for oss inntil 10 partnere med avtale på området, og at vi blant disse vil finne både spesialiserte tjenesteytere og fullservicepartnere. Merk at vi i rammeavtaleperioden - der vi har en faseinndelt prosess - ikke tillater partner som har levert på V2 å konkurrere om implementering av løsningen, dvs. V3-V8. Der det er snakk om en sammensatt leveranse er situasjonen en annen.

5.2.3 Utviklingstjenester for web og kl/tj i dotNET (C#) teknologi (V3)

dotNET er et av de store leveranseområdene i rammeavtalen. Det omfatter både vedlikehold/videre- utvikling av eksisterende løsninger og ev. nyutvikling. Løsningene våre er i hovedsak utviklet på web- plattform, men vi har en klient/tjener applikasjon som kjøres i Citrix miljø for en gruppe brukere i fylkesmannsembetet. Nye løsninger vil bli laget på web-teknologi i ASP dotNET med bruk av C# kode, ofte basert på MVC mønster og i henhold til beste praksis anbefalinger fra Microsoft.

Direktoratet benytter MS SQL server databaseplattform.

Leveranseområdet skal dekke alle typer utviklingstjenester og tilhørende støttetjenester:

• Arkitekturarbeid og – rådgivning, herunder støtte til Miljødirektoratets arkitekturansvarlige

• Funksjonell (detaljert) løsningsspesifikasjon (der det inngår som en naturlig del av en fase)

• Databaseutvikling, tuning/optimalisering

• Oppsett av utviklingsmaskiner og servere

• Utvikling av tynne/tykke klienter, brukergrensesnitt, web-services, DLL, SOA, SOAP, (REST) API etc.

• Testing og feilretting

• Vedlikehold og videreutvikling

• Installasjon, oppsett og konfigurering i test og produksjon

• Støtte til Miljødirektoratets IKT-driftsressurser

• Dokumentasjon av løsninger, kode, sammenhenger etc.

Tjenester på området kan enten leveres isolert (i en fase eller vedlikeholdsavtale) eller som en del av en totalleveranse. Vi ser for oss inntil 8 partnere med avtale på dette området.

5.2.4 Utviklingstjenester for dok.delings- og portalløsninger i SharePoint (V4)

SharePoint er et leveranseområde med lite/middels uttak av timer. Det omfatter både vedlikehold/ videreutvikling av eksisterende dokumentdelingssteder og ev. nyutvikling. Mulig ny-/videreutvikling kan være integrasjon av ePhorte dokumentarkiv i en SharePoint overbygning eller bruk av SharePoint som kjøreflate/plattform for fremtidige faglige saksbehandlingsløsninger. Ev. tilpasninger utover kjernen skal primært gjøres vha. våre øvrige foretrukne plattformer jfr. dotNET/C#, MS SQL etc.

eller vedlikeholdsavtale) eller som en del av en totalleveranse. Vi ser for oss inntil 6 partnere med avtale på dette området.

5.2.5 Utviklingstjenester for publ.løsninger i Episerver CMS v.6/7/* (V5) EpiServer er et leveranseområde med et betydelig uttak av timer. Det omfatter både vedlikehold/ videreutvikling av eksisterende nettsteder og ev. nyutvikling. Ev. tilpasninger utover kjernen skal

primært gjøres vha. våre øvrige foretrukne plattformer jfr. dotNET/C#, MS SQL etc.

Leveranseområdet skal dekke alle typer utviklingstjenester og tilhørende støttetjenester, i henhold til opplisting som er gitt for område V3. Tjenester på dette området kan enten leveres isolert (i en fase eller vedlikeholdsavtale) eller som en del av en totalleveranse. Vi ser for oss inntil 6 partnere med avtale på dette området. Grunnet våre krav til kvalifikasjoner tror vi at vi fortrinnsvis finner leverandører blant de sertifiserte EpiServer-partnere .

5.2.6 Utviklingstjenester for kartløsninger i ESRI/Arc* teknologi (V6)

ESRI/Arc* er et leveranseområde med betydelig uttak av timer. Det omfatter både vedlikehold/videre- utvikling av eksisterende kartbaserte løsninger/nettsteder og ev. nyutvikling. Ev. tilpasninger utover kjernen skal primært gjøres vha. våre øvrige foretrukne plattformer jfr. dotNET/C#, MS SQL etc.

Leveranseområdet skal dekke alle typer utviklingstjenester og tilhørende støttetjenester, i henhold til opplisting som er gitt for område V3. Tjenester på området kan enten leveres isolert (i en fase eller vedlikeholdsavtale) eller som en del av en totalleveranse. Vi ser for oss å ha 3 partnere på området.

5.2.7 Utviklingstjenester for grensesnitt/integrasjoner mot Ephorte (V7)

Vi benytter ePhorte som elektronisk arkiv og våre ansatte bruker webklienten. Vi har kjøpt API- lisenser, men så langt ikke gjort noen store integrasjoner utover fil-import fra ulike kilder. Vi ser at stadig flere av våre løsninger har et behov for dokumenthåndterings-/arkiveringsgrensesnitt, og at fremtiden kan bety en sterkere integrasjon via API eller via en mulig Sharepoint saksbehandling overbygning.

Leveranseområdet skal sikre oss kompetanse og bistand i å sette opp integrasjonsgrensesnitt mellom ePhorte og våre eksisterende/fremtidige administrative og faglige saksbehandlingsløsninger. I stor grad er aktuelle tjenester i henhold til opplisting under område V3. Tjenester på dette området kan enten leveres isolert (i en fase eller vedlikeholdsavtale) eller som en del av en totalleveranse. Vi ser for oss inntil 4 partnere med avtale på området.

5.2.8 Utviklingstjenester for grensesnitt/integrasjoner mot Agresso (V8)

Vi benytter Agresso økonomisystem og elektronisk fakturahåndtering. Vi ser at stadig flere av våre saksbehandlingsløsninger har behov for et en- eller toveis grensesnitt (API) eks. for overføring av fakturagrunnlag og innlesing av betalingsstatus, samt synkronisering av kunde-/leverandør- opplysninger og annet kodeverk.

Leveranseområdet skal sikre tilgang til kompetanse og bistand i å sette opp integrasjonsgrensesnitt mellom Agresso og våre eksisterende og fremtidige administrative og faglige saksbehandlings- løsninger. I stor grad er aktuelle tjenester i henhold til opplisting under område V3. Tjenester på dette området kan enten leveres isolert (i en fase eller vedlikeholdsavtale) eller som en del av en totalleveranse. Vi ser for oss inntil 4 partnere med avtale på området.

5.3 Partnere og ev. underleverandører

Vi ser at partnere tidvis ønsker å sikre spisskompetanse eller sikre tilstrekkelig kapasitet ved å benytte underleverandør. I en rammeavtale kan slik spisskompetanse bli monopolisert, og gi suboptimale effekter. For å motvirke slike effekter har vi nå omarbeidet leveranseområdene og modellen for antall partnere, slik at mer spesialiserte (nisje)leverandører selv kan finne en rolle som partner.

Regelverket sier at det er opp til leverandørene å vurdere hvordan våre behov best kan dekkes, herunder ved å bruke underleverandører der dette er hensiktsmessig. Vi mener at vår leveransemodell

har redusert behov for underleverandører, og signaliserer at vi helst ser at leverandører unngår bruk av underleverandører.

Obs: Ved prekvalifisering må leverandør vise hvordan de vil tilby ressurser for de leveranseområder det ønskes å leveres på. Hvis leverandører ønsker å delta med underleverandører må dette presiseres i søknaden om å delta i konkurransen. Ev. underleverandører skal prekvalifiseres sammen med søkeren, og kan ikke endres etter prekvalifiseringsfasen. Merk at det gjelder samme krav til dokumentasjon for underleverandør som for tilbyder!

6 Føringer for rammeavtalen

Dette er føringer som er relevante for tilbudsfasen/kontrakt, men som vi synes det er rimelig at tilbydere får innsyn i allerede nå, for å vurdere om rammeavtalen er interessant.

6.1 Varighet på rammeavtalen

Dagens rammeavtale gjelder for 3+1 år. Vi ønsker at den nye rammeavtalen skal ha en varighet på 2 år + opsjoner på 3 forlengelser av 1 år, dvs. til sammen 5 år. Vi ser at vi etter år 2 vil gjøre en individuell evaluering i forhold til fornyelse for hver partner, basert på erfaringer så langt.

Vi ser for oss at vi i avtalen må sikre gjensidig anledning til terminering av avtalen før kontraktsperioden utløp dersom det skulle oppstå situasjoner som tilsier dette (saklig grunn).

6.2 Omfang på rammeavtalen i timer

Det er vanskelig å anslå verdi på rammeavtalen når den både er bred (mange løsninger/nettsteder) og dyp (dekker vedlikehold/videreutvikling og nyutvikling). Ut fra erfaringer kjøper vi ikt-utviklings- tjenester (vedlikehold/videreutvikling og nyutvikling) for ca. 10 millioner kroner i året. Det er rimelig å anta at vi vil bruke rammeavtalen til en stor andel av disse. Vi må gjøre oppmerksom på at vårt aktivitetsnivå styres av de årlige budsjett tildelinger via statsbudsjettet, og at vi eks i 2014 fikk budsjettkutt som også har påvirket våre ikt-budsjetter.

6.3 Timepris

Timepris er en viktig del av tildelingskriteriene og blir fastsatt i forhandlinger med tilbyderne. Våre timeanslag er forhåpentligvis tilstrekkelig for at leverandører kan anslå det økonomiske potensialet i respektive avtaler.

Ved nyutvikling har vi tradisjonelt ønsket å kjøre kontrakter basert på forpliktende timebaserte estimater. Våre vedlikeholdsavtaler har også vært timebaserte, enten ressursleie (full tid) i kortere eller lengre perioder eller tilkalt bistand. Vi har tradisjonelt vært uvillig til å binde oss til vedlikeholds- avtaler med faste kostnader/administrasjonselementer.

Avtaleformen SSA-R legger føringer på at timebasert arbeid, dvs. at en time bestilles, leveres, faktureres/dokumenteres måned for måned. SSA-R åpner for at vi kan be om fast pris på et oppdrag, men da basert på kalkulert antall timer. Denne avtaleformen er derfor passende for våre ønsker/behov.

Timepris skal dekke leverandørens forutsigbare administrasjonskostnader (herunder merkantil forvaltning) og kostnader for ivaretakelse av kunnskap om vår standardteknologi. Generelt høy kompetanse om standard verktøy/teknologier forventes å være dekket av timepris. Vi ønsker kun seniorressurser, med minimum 5-6 års erfaring, slik at prisdifferensiering på junior-/seniorkompetanse er uaktuelt.

Et gitt nivå på uttak av tjenester, og SSA-R avtalens føringer om at allerede benyttede ressurser skal tilbys på nytt vil sikre at leverandøren ivareta kundespesifikk kompetanse om våre løsninger.

I rammeavtalene frem til i dag har vi ikke akseptert prisdifferensiering pr. leveranseområde, slik at vi har hatt en flat timepris for alle typer betalbare tjenester. Dette er fortsatt et premiss i ny rammeavtale.

6.4 Introduksjon av nye ressurser

Ved bytte av ressurser innenfor en tildelingsavtale er SSA-R tydelig på at det er leverandørens ansvar (og økonomiske risiko) å sikre kompetanseheving på nytt personell. Dette er først og fremst aktuelt der ressurspersoner har sluttet, eller at vi i et fåtall situasjoner har bedt leverandør bytte ut ressurspersoner som ikke har fungert godt nok i team/prosjektarbeid. For å sikre at kompetanseheving skjer på en forutsigbar måte for oss og leverandørene har vi frem til i dag hatt en egen "introduksjonstimepris" for nye seniorressurser, og at det har vært en dialog og enighet om "når" ressursen har vært produktiv og kunne fakturere ordinær timesats. Dette har fungert, men skapt noe usikkerhet om varighet.

I denne rammeavtaleperioden ønsker vi klare føringer for hvordan kostnader skal bæres for kompetanseoverføring. Vi har derfor et forslag til et nytt "introduksjonsprogram". I stedet for at leverandøren bærer kostnaden for en "diffus kompetanseoverføring" foreslår vi at nye ressurser som introduseres (uavhengig av årsak) går for en lavere timesats i en avgrenset tidsperiode, for å kompensere for lavere produktivitet ved at de må sette seg inn i oppgaver de skal løse og lære oss (og teamet) å kjenne. Vårt forslag er at tidsperioden differensieres slik:

• Introduksjonstiden er 3 ukesverk (>= 90 timer) ved fulltids prosjektarbeid/ressursleie og 6 ukesverk (>=180 timer) ved vedlikeholds/videreutviklingskontrakter (f eks initiale avrop). Vi regner kun en introduksjonsperiode for en konsulent i rammeavtaleperioden

Denne modellen kompenserer oss for ulempen ved nye konsulenter og bytte av ressurser, og gir leverandør et økonomisk insitament for å sikre kontinuitet i bemanning etter introduksjonsperioden.

6.5 Premisser for bruk av rammeavtalen

Vi vil ikke pålegge intern bruk av rammeavtalen, men alle interne kjøpere av IKT-tjenester blir involvert og informert om avtalen og er internt forpliktet til å vurdere om sin anskaffelse best kan foretas ved å bruke rammeavtalen. Det kan ligge forpliktelser i konkrete avrop, eks vedlikeholdsavtale.

Generelt

• Kontrakt tildeles etter ”minikonkurranse” iht. tildelingskriteriene

• Tildelingskriterier ved avrop (etter minikonkurranse) vil i hovedsak være samme kriterier som i rammeavtalen

• Vi kan legge premisser eks. om teknologivalg/øk. rammer/samarbeid der det er saklig grunn

Kjøp av tjenester der det er flere partnere med leveranseavtale

• Der flere leverandører kan levere samme tjeneste/ytelse gir vi alle anledning til å gi tilbud, og gjennomfører en ”minikonkurranse” hvor avrop tildeles leverandør ut fra tildelingskriteriene

• Vi forutsetter at rammeavtalepartnere der aktuelt samarbeider med hverandre på tvers for å dekke vårt behov på en helhetlig og god måte

Kjøp av tjenester der kun en leverandør kan levere

• Ett leveranseområde vil ha en partner med eksklusiv rett til å levere tjenester. Her kan vi forhandle/kjøpe direkte hvis dette er ønskelig

• Der det for oss vil gi merverdi (fremme konkurranse og sikre helhetlige løsninger) å benytte en slik tjeneste opp mot andre leverandørers tilbud så ser vi ikke for oss at leverandør har anledning til å motsette seg dette

Oppdrag som gjennomføres i flere faser

• Leveranseområdene er organisert for å gjøre faseinndelt arbeid mulig, og vi forbeholder oss rett til å kjøpe enkelte deler, der vi tror dette er fornuftig

• Leverandører med kontrakt på aktuelle leveranseområder inviteres til å gi tilbud

• Der vi kjører en prosess i flere faser og bruker en leverandør på leveranseområde V1 og V2, vil dette diskvalifisere leverandør i å delta i konkurranse om implementering av ev. løsning (V3-V8)

Helhetlige leveranser (som dekker flere faser og/eller flere leveranseområder)

• Hvis vi ønsker en helhetlig leveranse med en partner beskriver vi behov og inviterer de partnere med kontrakt på relevante leveranseområder til å levere tilbud

• Hvis vi er åpen for ideer/forslag av partnere kun med kontrakt på spesifikke områder vil vi gi beskjed om dette, og forbeholder oss rett til fritt å velge elementer fra tilbydernes ulike tilbud (ved at vi orkestrerer en helhetlig leveranse med delbidrag fra flere)

7 Ønskede kvalifikasjoner for tilbydere

I kvalifikasjonsgrunnlaget beskriver vi hvordan vi arbeider med IKT-problemstillinger og hvilke egenskaper vi ønsker hos fremtidige rammeavtalepartnere. Dette for at leverandørene best kan vurdere om, og i tilfelle med hva, de kan tilby oss i rammeavtaleperioden. Vi håper dette er relevant og tilstrekkelig for å vurdere om det bør søkes om deltakelse i konkurransen om rammeavtalene, og i så fall med hvilken organisering.

Vi er pålagt i regelverket å sette minimumskrav for kvalifikasjoner (såkalte kvalifikasjonskrav). Disse knytter seg til leverandørens egnethet til å levere den aktuelle anskaffelsen, og skal sikre at leverandøren generelt har teknisk, organisatorisk, økonomisk og finansielt grunnlag for å gjennomføre kontrakten. Manglende oppfyllelse av disse leder til avvisning av søknad om deltakelse i konkurransen.

7.1 Kvalifikasjonskrav for konkurranse om rammeavtalen

Her beskriver vi kriteriene som vil vektlegges når vi skal avgjøre om leverandøren er kvalifisert for å delta i konkurransen om rammeavtalene. Vi bruker følgende oppsett for kravene innenfor hvert tema:

Vårt krav:

Her formuleres hva leverandøren skal kunne synliggjøre/dokumentere etc.

Vår eventuelle begrunnelse/lov/forskriftshjemmel for kravet:

Flere krav er hjemlet i lov/forskrift om offentlige anskaffelser. Andre krav berettiges av kontrakten.

Hvordan leverandøren skal dokumentere at krav tilfredsstilles:

Her beskrives dokumenter/dokumentasjon som vi ber tilbyder levere for å beskrive oppfyllelse av kravene

7.1.1 Skatt og merverdiavgift

Vårt krav:

Leverandøren (inkludert eventuelle underleverandører) skal ikke ha restanser på skatt og merverdiavgift

Hvordan leverandøren skal dokumentere at krav tilfredsstilles:

Fremleggelse av gyldige skatte- og momserklæringer, ingen eldre enn 6 måneder.

7.1.2 HMS-arbeid

Vårt krav:

Leverandøren (inkludert eventuelle underleverandører) skal oppfylle krav til arbeid innen helse, miljø og sikkerhet

Hvordan leverandøren skal dokumentere at krav tilfredsstilles:

Fremleggelse av gyldig HMS-egenerklæring.

7.1.3 Økonomisk/finansiell kapasitet og soliditet

Vårt krav:

Leverandøren (samt ev. underleverandører) skal ha tilstrekkelig økonomisk/finansiell kapasitet og soliditet

Hvordan leverandøren skal dokumentere at krav tilfredsstilles:

Fremleggelse av foretakets årsregnskap eller utdrag fra det, samt en redegjørelse for omsetning innenfor det/de områder som omfattes av kontrakten for de 2 siste regnskapsår (der tilgjengelig).

7.1.4 Generell organisering for å oppfylle kontrakten

Vårt krav:

Leverandøren skal der de støtter seg på andre foretaks kapasitet (dvs. underleverandører) dokumentere at de har rådighet over de nødvendige ressursene. De skal videre kommentere konsekvens av ev. bortfall av

underleverandør innenfor rammeavtalens varighet.

Hvordan leverandøren skal dokumentere at krav tilfredsstilles:

Merk at vi helst ser at partnere ikke benytter underleverandører. Der dette likevel gjøres må det fremlegges forpliktelseserklæring for forholdet mellom leverandørene og det må beskrives hvordan bortfall av

underleverandør i rammeavtaleperioden er tenkt håndtert.

Og i tillegg:

Vårt krav:

Leverandøren skal som hovedregel gjennomføre alle tjenester ved personlig oppmøte av konsulenter i våre kontorlokaler i Grensesvingen 7* på Helsfyr i Oslo, på vårt IKT-utstyr tilknyttet vår egen felles infrastruktur.

Dette gjelder både ved:

o Ad-hoc situasjoner (ulike typer hurtighet på tilkallingstid – rød/gul/grønn)

o Planlagt arbeid (fra periodisk til fulltid for flere personer i flere år)

*) 1. desember 2014 flytter Miljødirektoratet "over veien" fra Strømsveien 96 til Grensesvingen 7.

Leverandøren skal, dersom det i kortere eller lengre tidsrom oppstår plassmangel i våre kontorer, kunne tilby kontorplass til egne konsulenter i Oslo, som via VPN eller annet utstyr/software tilrettelagt fra oss skal arbeide mot våre ikt-løsninger. Det skal være mulig for oss å delta i møter etc. med konsulentene der. Kontorplasser skal tilbys kostnadsfritt for oss.

Leverandøren skal, dersom behovet tilsier det, kunne levere tjenester ved våre kontorlokaler i Trondheim (på Brattørkaia).

Til informasjon vil det være følgende kontraktbetingelser i rammeavtalen:

• Tjenester skal være ”fritt levert” vår kontoradresse i Oslo

• Tjenester skal kunne leveres ved vår kontoradresse i Trondheim, reiseutlegg dekkes etter statens satser for de partnere som ikke har eget leveranseapparat i området (hvis de har det er tjenester også fritt levert der)

• Alle leverandørens konsulenter og ressurspersoner skal være i stand til å kommunisere direkte med våre brukerrepresentanter på norsk.

• Bemanningen skal kunne lese, bruke og utarbeide all dokumentasjon på norsk

Vår begrunnelse eller lov-/forskriftshjemmel for kravet:

Kontraktens gjenstand er IKT-tjenester mot våre eksisterende løsninger/nettsteder samt nyutvikling. Vår program-/maskin-infrastruktur er på plass og bruk betinger at man sitter fysisk i våre lokaler.

Hvordan leverandøren skal dokumentere at krav tilfredsstilles:

Bekreftelse på at våre krav vil bli oppfylt, og en kort beskrivelse av hvordan.

Vi skal prekvalifisere tilbydere for de leveranseområder de ønskes å levere på. Leverandørene må dokumentere faglige/tekniske kvalifikasjoner5 og kapasitet for de obligatoriske og valgfrie leveranseområdene det søkes om anledning til å levere på. Som en konsekvens kan en leverandør som ikke leverer tilstrekkelig dokumentasjon for et gitt leveranseområde risikere å ikke få anledning til å inngi tilbud på dette området. Leverandør må minimum søke og bestå prekvalifisering for 2 valgfrie områder for å få anledning til å levere tilbud. Vi ber derfor leverandørene være nøye med å dokumentere ikt-faglige og ikt-tekniske kvalifikasjoner og kapasitet i henhold til denne modellen.

Særlig gjelder dette de som kun søker på minimumsantallet (2) for antall valgfrie områder – hvor svak dokumentasjon på ett av de ødelegger leverandørens mulighet til å kunne konkurrerer på det andre.

	Leveranseområde	IKT-faglige kvalifikasjoner og kapasitet	IKT-tekniske kvalifikasjoner og kapasitet
O1	Merkantil rammeavtaleforvaltning	✓	Ikke relevant
O2	Prosjekt-/oppdrags-/arbeidsledelse	✓	Ikke relevant
V1	Analyse/konseptutvikling og kravspesifisering	✓	Ikke relevant
V2	Behovs-/brukerorienterte tjenester	✓	Ikke relevant
V3	dotNET (C#)	✓	✓
V4	SharePoint	✓	✓
V5	Episerver v.6/7/n	✓	✓
V6	ESRI/Arc*	✓	✓
V7	Ephorte	✓	✓
V8	Agresso	✓	✓
Avrop 1-4	Initialt avrop vedlikehold/videreutvikling av fagapplikasjoner	✓	Ikke relevant, dekkes av v3- v6

7.1.5 Generelle IKT-faglige kvalifikasjoner for å gjennomføre kontrakten

Vi har beskrevet to obligatoriske leveranseområder (O1 og O2) og 8 frivillige (V1-V8). Vi viser til tabellen overfor som sammenstiller hvordan leverandør skal vise kvalifikasjoner og kapasitet. Det er

5 Vær særlig obs på nyanseforskjellen mellom ikt-faglig og ikt-tekniske kvalifikasjoner/kompetanse og krav om at tilbyder dokumenterer begge

kun de områder og ev. avrop det ønskes å konkurrere om det er nødvendig å dokumentere på våre krav. For eksempel bør leverandør på O2 redegjøre for hvordan de kan bemanne opp og sikre vårt behov på ledelsesområdet. Antall ressurser, deres utdanning/sertifiseringer, erfaringer, metodikk etc. er relevant.

Vårt krav:

Leverandøren (inkludert eventuelle underleverandører) skal ha tilstrekkelig faglige kvalifikasjoner og kapasitet til å gjennomføre leveranser på alle leveranseområder de ønsker å levere på. Dette gjelder også for ev. tild.avtaler (initiale avrop) de ønsker å konkurrere om.

Hvordan leverandøren skal dokumentere at krav tilfredsstilles:

Beskrivelse av organisasjonsenheter som disponeres for å oppfylle kontrakten enten de tilhører foretaket eller ikke. Der det må brukes underleverandør skal dette tydeliggjøres. Merk: vi etterspør ikke redegjørelser om navngitte personer! Detaljnivå avgrenses til:

• Kort beskrivelse av viktigste relevante oppdrag for hvert av de aktuelle leveranseområdene de siste årene med avgivelse av omfang/verdi, tidspunkt og navn på kunde

• Generelle redegjørelser om kapasitet (antall konsulenter) med relevant kompetanse/erfaring for hvert av de aktuelle leveranseområdene.

7.1.6 Generelle tekniske kvalifikasjoner for å gjennomføre kontrakten

Miljødirektoratet har alle aktuelle plattformer, teknologier og standarder på plass, inkludert teknisk infrastruktur. Rammeavtalen omfatter konsulenttjenester innen vedlikehold/videre-utvikling av våre eksisterende løsninger/nettsteder samt nyutvikling, fortrinnsvis basert på mer-/gjenbruk av det vi har fra før. Kontraktens gjenstand berettiger derfor at vi stiller verktøy-/plattformspesifikke krav til tekniske kvalifikasjoner for de konsulenter som skal levere disse tjenestene (dvs. V3-V8). Vi har beskrevet to obligatoriske leveranseområder (O1 og O2) og 8 frivillige (V1-V8). Vi viser til tabellen foran avsnitt 7.1.5 som sammenstiller hvordan leverandør skal vise kvalifikasjoner og kapasitet. Det er kun de områder og ev. avrop det ønskes å konkurrere om hvor våre krav skal dokumenteres.

Vårt krav:

Leverandøren (inkludert ev. underleverandører) skal ha tilstrekkelig teknisk kvalifikasjon og kapasitet til å levere tjenester på våre eksisterende ikt-plattformer. Dokumentasjonen må fremlegges for de nevnte leveranseområdene leverandør ønsker å levere på.

Hvordan leverandøren skal dokumentere at krav tilfredsstilles:

Fremleggelse av generelle (men plattformspesifikke) beskrivelser av leverandørens tekniske personell som disponeres for å oppfylle kontrakten. Der det må brukes underleverandør skal dette tydeliggjøres. Merk: vi etterspør ikke redegjørelser om navngitte personer! Detaljnivå:

• Kort beskrivelse av relevante oppdrag for hvert av de aktuelle leveranseområdene de siste to år med avgivelse av omfang/verdi, tidspunkt og navn på kunde

• Generelle redegjørelser om kapasitet, (antall konsulenter) med angivelse av relevant utdanning (herunder sertifiseringer) og antall års erfaring

7.2 Kommunikasjon med tilbydere

Direktoratet har en egen innkjøperprofil på Doffin, og det er mulig å laste ned kvalifikasjons- grunnlaget for kunngjøringen av denne anskaffelsen på Doffin.

All formell kontakt mellom direktoratet og leverandør som søknader, invitasjoner, tilbud etc. skal håndteres skriftlig på papir av begge parter. Søknader kun på e-post aksepteres ikke. All skriftlig korrespondanse registreres i vårt elektroniske arkiv. Vår elektroniske journal er offentlig tilgjengelig. Som hovedregel skal mest mulig informasjon inn/ut hos oss være offentlig. Dette betyr at leverandør må være tydelig hvis en gitt informasjon i søknaden ønskes unntatt offentlighet. Vi vil da vurdere om hele eller deler av dokumentet skal unntas offentlighet, men vår egen vurdering kan fravike fra leverandørens ønske.

7.3 Spørsmål fra interessenter/tilbydere

Spørsmål skal stilles skriftlig pr. e-post til xxxx@xxxxxxxx.xx merket tydelig med vår ansvarlige person som referanse: Seniorrådgiver Xxxxx Xxxxxx i IKT-seksjonen. Spørsmål som har generell relevans blir lagt ut på xxxxxx.xx (i anonym form) og blir besvart generelt slik at alle leverandører kan dra nytte av spørsmål/svar.

7.4 Mottak av søknad om deltakelse i konkurransen

Siste frist for mottak av søknad om deltakelse i konkurransen er mandag 16. juni kl. 12.00. Søknad skal være på papir i 2 komplette eksemplarer i ringperm og være fysisk mottatt av direktoratet innen angitte frist (enten kvittert av betjeningen i vår resepsjon i Oslo eller sendt pr post slik at det er fysisk mottatt/registrert i vårt elektroniske arkiv innen fristen). Søknader på e-post blir ikke godtatt!

Søknaden skal være pakket/forseglet ved levering, og være tydelig merket:

Søknad – sak 2014/4340 – IKT-rammeavtale v/Xxxxx Xxxxxx

Åpnes kun av adressat!

I søknaden skal det ligge et følgebrev undertegnet av ansvarlig person hos leverandøren.

Det skal også legges ved en USB-minnepenn med komplett dokumentasjon lesbart av MS-Office (word, excel, powerpoint) eller Adobe Reader (PDF). Søknaden og alle vedlegg skal være utformet på norsk.

Leverandøren bærer risikoen for å innlevere komplett dokumentasjonen direktoratet etterspør.

Vi må minne om at regelverket for offentlige anskaffelser pålegger oss plikt til å avvise eller anledning til å avvise søknader ved manglende informasjon eller at informasjon ikke blir levert som forespurt.

7.4.1 Behandling av søknader

Vi ser for oss at vi ved søknadsfristens utløp har konkurransegrunnlaget klart slik at vi raskt etter å ha vurdert søkernes kvalifikasjoner kan invitere kvalifiserte leverandører til å inngi tilbud. Der søker ber om anledning til å levere på flere områder, og kvalifikasjonsdokumentasjonen ikke er tilstrekkelig på enkeltområder (av de valgfrie), vil vi likevel gi leverandør anledning til å konkurrere på de områder hvor de blir kvalifisert. De eventuelle leverandører som ikke oppfyller kvalifikasjonskravene for noen av områdene eller for nødvendig antall vil få en umiddelbar tilbakemelding om dette.

8 Prosessen etter kvalifikasjonsfasen er gjennomført

8.1 Tentativ tidsplan for gjennomføring av konkurransen

Vi jobber ut fra følgende tidsplan:

Nr	Milepæl	Foreløpig frist
1	Frist for mottak av søknader	16 juni kl. 12
2	Prekvalifisering av tilbydere (senest)	5 juli
3	Utsending av konkurransegrunnlaget (senest)	5 juli
4	Tilbudsfrist og åpning	15 september
5	Gjennomlesning av alle tilbud og evt. avvisning	1 oktober
6	Plan for forhandling og tilbakemeldinger til tilbydere	7 oktober
7	Faseinndelte forhandlinger avsluttet	15 november
8	Tildeling av avtaler og avrop, feedback og ev klagehåndtering	22 november
9	Kontrakt arbeid gjennomført og kontrakter signert	15 desember
10	Oppstart av arbeid på initiale avrop (typisk vedlikehold)	1 januar 2015

8.2 Valgt prosedyre

Kontrakten inngås etter prosedyre for konkurranse med forhandling over terskelverdi med utlysning ved Doffin og TED. Vi kjører i to trinn - først en prekvalifisering og så tilbudsfase. Kontrakten som ønskes inngått er en såkalt "rammeavtale for flere leverandører hvor alle vilkår ikke er fastsatt". Derfor må det gjøres forhandlinger (minikonkurranse) og avklaringer før det inngås avrop (kontrakter) for bruk av rammeavtalen. For noen av de kjente behovene vil det være initiale avrop hvor det leveres tilbud sammen med rammeavtaletilbudet.

Les mer på xxx.xxxxxxx.xx og hos FAD samt xxx.xxxxxxxxxxxx.xx, for oppdatert informasjon om det gjeldende regelverket, avtaleformer etc.

8.3 Hva vi vil legge særlig vekt på ved tildeling av rammeavtale

Vi kommer tilbake med tildelingskriteriene i konkurransegrunnlaget, men ut fra tidligere erfaring vil vi legge vekt på følgende:

• Timepris

• Rutiner for å sikre at vi får tilgang til høy oppdragsspesifikk kompetanse (seniorkompetanse)

• Begrunnede beskrivelser av leveransene (vise til relative kvaliteter)

• Dokumenterte gjennomføringsevne (tilstrekkelig kapasitet, levere på tid, penger og kvalitet)

• Generelle leveringsbetingelser (leveringstid, tilkallingstid etc.)

8.4 Tilbudsfasen

8.4.1 Utsendelse av konkurransegrunnlag

Tidspunkt fremgår av tentativ tidsplan. Vi sender ut brev med invitasjon til å inngi tilbud til kvalifiserte leverandører. Vi tar sikte på å bruke vår SharePoint dokumentdelingsløsning for å dele dokumenter med tilbyderne under tilbudsfasen. Mer informasjon gis i invitasjonsbrev.

8.4.2 Tilbud utformet som et kontraktsforslag

Vi forventer at tilbud utformes som forslag til rammeavtalekontrakt SSA-R m/ev. avtaleforslag for avrop (SSA-V lille etc.) Ved at tilbud utformes som konkrete bilag til kontrakt blir det enklere for oss å sammenstille/-likne og det spares også vesentlig tid som går med til å ”brekke om” tilbud til ferdig kontrakt.

8.5 Forhandlingsfasen

Forskrift for offentlige anskaffelser beskriver hvordan prosessen frem til valg av leverandør og tildeling av kontrakt skal foretas. Forhandlingen vil dreie seg om det materielle og prosessuelle i kontrakten, med utgangspunkt i grunnlaget fra tilbudet. Vi vil benytte anledningen forskriften gir til en gradvis reduksjon av antall tilbyder (før og etter) forhandlinger for å effektivisere prosessen med å tildele kontrakter. Mer informasjon gis i konkurransegrunnlaget som sendes ut til de leverandører som blir prekvalifisert til å delta i konkurransen.

Document Metadata

Table of Contents

Kvalifikasjonsgrunnlag konkurranse med forhandling IKT-rammeavtale (2015 – 2019)

Document Metadata