Kontrakt om fleksible utviklingstjenester
Kontrakt om fleksible utviklingstjenester
Veiledning for utarbeidelse og bruk av kontraktsstandarden
DEN NORSKE DATAFORENING
Versjon : 1.0
Dato oppdatert : 15.06.2018
INNHOLDSFORTEGNELSE
3
1.4 Forutsetninger for å velge denne kontrakten 5
5
3 KONTRAKTENS PROSESSER OG GJENNOMFØRINGSMODELL
6
3.2 Oppstartsaktiviteter og overgang til leveranser 7
4 ANSKAFFELSESPROSESS OG ETABLERING AV KONTRAKT
7
4.1 Forutsetninger for etablering av kontrakt 7
4.2 Konkurransegrunnlag og krav til utforming av tilbud 8
4.3 Leverandørens utfylling av tilbudstekst i kontrakt 9
4.4 Grunnlag for evaluering av tilbud 9
11
1 Innledning
1.1 Bakgrunn
Smidig gjennomføringsmodell er blitt stadig mer dominerende i systemutviklingsprosjekter, både i privat og offentlig sektor. Dataforeningens kontraktsstandarder for smidig systemutvikling (PS2000 Smidig og PS2000 SOL) er utformet for smidig utvikling av systemløsninger i tett samarbeid mellom kunde og leverandør. I disse kontraktsstandardene er det en fordelt risiko mellom partene for deler av arbeidet, og kontraktene har fokus på partenes ansvar innenfor ulike trinn av gjennomføringsmodellen. Dette gjør at partenes ressurser ikke arbeider i integrerte team, noe som gir noen begrensninger i graden av smidighet i gjennomføringsmodellen. Disse kontraktsstandardene tilrettelegger heller ikke for at kunden deltar aktivt i systemutviklingen i utviklingsteamene.
For å få et enda høyere grad av smidighet i gjennomføringen og et helt integrert samarbeid mellom partene, kan ikke risikoen fordeles mellom partene i ulike deler av arbeidet. Fokus må endres til partenes samarbeid om å bemanne, styre og kontinuerlig forbedre utviklingsteam, og dermed må kunden selv ta resultatansvaret.
Med stadig større fokus på innovative utviklingsprosesser med hyppig produksjonssetting og tett kobling mellom utvikling og forvaltning (DevOps), bør teamene i størst mulig grad kunne arbeide autonomt og selvstyrt. Dette stiller forholdsvis store krav til modenhet i utviklingsteam innenfor prosess/metode, effektiv verktøystøtte, god kommunikasjon og tett samarbeid innenfor utviklingsteam.
Ofte brukes timebaserte bistandsavtaler eller rammeavtaler for å leie inn konsulenter til smidig utvikling der kunden tar resultatansvaret selv. Imidlertid gir ikke slike kontrakter sikkerhet for at kunden får tak i ressursene med ønsket erfaring og kompetanse, og normalt inngår ikke krav til støtte fra leverandøren for etablering og kontinuerlig forbedring underveis.
Den fleksible utviklingskontrakten er et alternativ til bistandsavtaler eller rammeavtaler der kunden tar resultatansvaret selv. Standarden kjennetegnes ved at
- leverandøren er forpliktet til å levere avtalt kapasitet og ressurser med avtalt kompetanse til kundens utviklingsteam og kunden er forpliktet til å betale for den avtalte kapasiteten,
- gjennomføringsmodellen er basert på smidige prinsipper med definerte hovedprosesser og tjenester; herunder fokus på hyppig produksjonssetting og tett kobling mellom utvikling av forvaltning (såkalt DevOps),
- partene har et avtalt samarbeid gjennom regelmessige møter og rapportering xx
- leverandøren skal bistå kunden med
o å oppnå en god produktkøprosess
o effektiv realisering og forvaltning av systemløsninger
o kontinuerlig forbedring av utviklingsteamets prosesser, verktøystøtte og kompetanse.
For å kunne forstå og tolke spesielle ord og begreper som er benyttet i kontraktsstandarden, er det inkludert en definisjonskatalog i de generelle kontraktsbestemmelsene.
1.2 Formål med kontrakten
Dette dokumentet utgjør en veiledning for etablering og bruk av denne kontraktsstandarden for fleksible utviklingstjenester.
Kontraktsstandarden er en selvstendig og fullverdig avtale som omfatter
- oppstartsaktiviteter for kontrakten,
- hele livssyklusen for utvikling og forvaltning av systemløsninger og
- avslutningsaktiviteter for kontrakten
Kontrakten regulerer partenes overordnede forpliktelser og rettigheter i kontraktsperioden herunder leverandørens forpliktelse til en gitt kapasitet og bemanning. Avtale om bruk av ressurser fra leverandøren for å bemanne kundens utviklingsteam i avtaleperioden gjøres gjennom bestillinger.
Partene kan avtale at leverandøren har helt eller delvis tar ansvar for teknisk infrastruktur og utviklingsverktøy for arbeidet i utviklingsteamene.
Kontrakten forutsetter at kunden etablerer separate kontrakter med tredjeparter som leverer standard programvare og/eller skytjenester dersom dette skal inngå i de systemløsningene som skal realiseres og produksjonssettes. Kunden skal kunne skifte ut utviklingsleverandøren uten å miste tilgang til standardprodukter og/eller skytjenester som er integrert i systemløsningen.
Kontrakten er også utarbeidet med utgangspunkt i at det er kunden som har resultatansvaret. I visse situasjoner kan det være formålstjenlig for kunden at leverandøren har et avtalt ansvar for realisering og forvaltning innenfor definerte bestillinger. Veiledningen beskriver hvordan standarden kan utvides for å inkludere et slikt resultatansvar.
Kontrakten er også utarbeidet med utgangspunkt i å etablere kontrakt med en leverandør. Det er imidlertid enkelt å endre kontrakten slik at den blir en rammeavtale med to (eller eventuelt flere) leverandører, og beskrivelse av dette er også inkludert i denne veiledningen. Antall leverandører må imidlertid begrenses, i praksis til to, siden det er forutsatt en forholdsvis tett kontraktsrelasjon mellom kunde og leverandør.
1.3 Dataforeningens rolle
Dataforeningens Faggruppe for IT-kontrakter er ansvarlig både for denne kontrakten og for videreutvikling og forvaltning av PS2000-kontraktsstandardene og de øvrige, tilhørende kontraktsstandardene.
Utarbeidelse av denne kontraktsstandarden ble gjennomført i 2017 og 2018, slik at en første versjon kunne ferdigstilles i mars 2018. Arbeidet er utført av en arbeidsgruppe under ledelse av XXXXXX AS.
Arbeidsgruppen ble nedsatt av Dataforeningens styre for Faggruppen for IT-kontrakter, med tilnærmet lik representasjon fra både kunde-, leverandør- og rådgiversiden:
- PROMIS AS, ved Xxxxxx Xxxxxxxx (leder) og Xxx Xxxxxx Xxxxxxxxx
- Xxxxxxxxxxxxxx Xxxxxxxx Xxxx Xxxx AS, ved Xxxxx Xxxxx
- Arbeids- og velferdsetaten (NAV), ved Xxxx Xxxxxxxx
- Xxxx Consulting AS, ved Xxxxxxxx Xxxxxxxxxxx
- Capgemini Norge AS, ved Xxxxxx Xxxxxxxxx
- Computas AS, ved Xxxx Xxxxx Xxxxxx
- Departementenes sikkerhets- og serviceorganisasjon, ved Xxx Xxxx
- Direktoratet for forvaltning og IKT (Difi), ved Xxxx Xxxxxx
- Sopra Steria, ved Xxxx Xxxxxx Xxxxxxxxxxx og Xxxxxxxxx Xxxxxxx
- Statens vegvesen, ved Xxxxx Xxxxx
- Timebox AS, ved Xxxxxxxx Xxxxxxxx
Mer informasjon om Dataforeningen og faggruppens arbeid kan fås ved henvendelse til Den Norske Dataforening (xxx.xxxxxxxxxxxxxx.xx) eller PROMIS AS (xxx.xxxxxx.xx).
1.4 Forutsetninger for å velge denne kontrakten
Kontrakten forutsetter at kunden har erfaring med og modenhet innenfor smidig systemutvikling og at kunden har ressurser som kan dekke en del av rollene innenfor utviklingsteam. Det er en forutsetning at kunden
- har ressurser med god innsikt i de aktuelle forretningsprosessene og erfaring fra produkteierrollen med tilstrekkelig beslutningsmyndighet,
- har tilstrekkelig antall egne ressurser for å dekke premissgivende roller slik at kunden som utgangspunkt kan ta resultatansvaret for arbeidet i utviklingsteamene,
- har erfaring med og god modenhet innenfor smidig systemutvikling; det er en fordel med erfaring fra eierstyring av xxxxxxx initiativ/prosjekter og
- etablerer separate kontrakter med leverandører av eventuelle standardprodukter og skytjenester som skal konfigureres og integreres i systemløsningene.
2 Kontraktstruktur og innhold
2.1 Hovedinndeling
Kontrakten er delt inn i:
Del I Kontraktsdokument
Del II Generelle kontraktsbestemmelser Del III Bilag
Kontraktsdokumentet består av en forside med nøkkelinformasjon om kunde, leverandør og inngått kontrakt og er skilt ut som en egen del for å gi partene frihet til å velge form og innhold på dette overordnede dokumentet. Som et minimum må alle deler av kontrakten refereres og rangordningen mellom disse må beskrives i tillegg til å angi kontraktens varighet.
Kontraktsdokumentet utarbeides når partene har oppnådd enighet om kontraktsbestemmelsene. De generelle kontraktsbestemmelsene skal kunne brukes med få eller ingen endringer. Alle spesifikke vilkår for kontrakten reguleres derfor i bilagene.
Eventuelle endringer til de generelle kontraktsbestemmelsene skal fremgå klart av kontraktsdokumentet.
De generelle kontraktsbestemmelser inneholder beskrivelse av hvordan leverandørens ressurser og tjenester leveres igjennom etablering av bestillinger basert på krav og betingelser til følgende områder:
- partenes plikter,
- tjenester og prosesser innenfor gjennomføringsmodellen, og hvordan bestillinger etableres,
- økonomiske vilkår og
- juridiske bestemmelser, herunder sikkerhet, taushetsplikt, rettigheter, mislighold, avbestilling og endringer.
Kontrakten er bygget opp med ”halvfabrikata” bilag. Dette skal forenkle utarbeidelsen av bilagene og legge til rette regulering av alle forhold som de generelle kontraktsbestemmelsene foreskriver at skal være nærmere regulert i bilag. For ytterligere å forenkle avtaleinngåelsen, er det i bilagene inntatt forslag til detaljregulering av tjenestene, samt hvilke tjenester og forpliktelser som bør reguleres. Det presiseres at forslagene ikke er ment som førende fra Dataforeningens side.
Den preutfylte bilagsteksten må uansett kompletteres og gjennomgås grundig for å kunne benyttes til å regulere spesifikke kontraktsforhold. Primært skal spesifikke forhold legges inn i forhåndsdefinerte tabeller. Der det ikke er hensiktsmessig med tabeller, er behov for utfylling markert med <kursiv og klammeparenteser> og eventuelt forslag til tekst. Merk at bilagsteksten på enkelte områder primært fungerer som en kryssreferanse fra de generelle kontraktsbestemmelser og som eksempel (i kursiv) for mulig innhold, ikke som en standard.
Bilagene inneholder:
1. En overordnet beskrivelse av det aktuelle systemområdet og teknisk infrastruktur
2. Hvordan bestillinger etableres for å avtale leverandørens ressurser som skal inngå i utviklingsteamene, en overordnet beskrivelse av hovedprosesser og tjenester for gjennomføring av bestillinger, og videre gjennomføring av oppstarts- og avslutningsaktiviteter for kontrakten
3. Leverandørens kapasitet, ressurser og kompetansekrav til ressursene
4. Administrative bestemmelser, kontaktpersoner, faste møter og rapportering
5. Priser og vederlag for bestillinger
6. Sjekkliste for utforming av bestillinger
7. Oversikt over eventuell teknisk infrastruktur samt verktøy for utvikling, test og produksjonssetting som skal holdes av leverandør
3 Kontraktens prosesser og gjennomføringsmodell
3.1 Hovedprosesser
Kontrakten er skreddersydd for en gjennomføringsmodell basert på smidige prinsipper. Gjennomføringsmodellen består av tre hovedprosesser som i stor grad gjennomføres i parallell med fokus på kort gjennomløpstid for oppgaver som utviklingsteamet skal utføre, hyppig produksjonssetting og tett kobling mellom utvikling av forvaltning (DevOps).
Hovedprosessene er kun overordnet beskrevet siden de skal tilpasses oppgavene i hvert enkelt utviklingsteam og skal være gjenstand for kontinuerlig forbedring.
- Produktkøprosess
⇒ Etablering av produktkøen på overordnet nivå
⇒ Utdyping av innholdet i prioriterte deler av produktkøen
- Realiseringsprosess
⇒ Detaljert design, utvikling, test og produksjonssetting av produktkøen
⇒ Gjennomføres i iterasjoner eller som kontinuerlig prosess
- Forvaltningsprosess
⇒ Serviceperiode defineres for å sikre tilgjengelighet og kvalitet på programvaren i produksjon
⇒ Tjenestene omfatter, feilretting, overvåkning, tredjelinje brukerstøtte, opplæring og forebyggende vedlikehold
3.2 Oppstartsaktiviteter og overgang til leveranser
Ved inngåelse av kontrakt skal det samtidig signeres en bestilling for leverandørens deltagelse i arbeidet med å etablere partenes samarbeid i helt integrerte utviklingsteam. Xxxxxx har ansvaret for oppstartsprosjektet, men leverandøren kan ha ansvar for deloppgaver.
Beskrivelsen av oppstartsprosjektet omfatter normalt
- aktivitetsbeskrivelse og leveranser (omfatter normalt, men er ikke nødvendigvis begrenset til, etablering av samarbeidet mellom partene, etablering av de faste møteplassene og administrative rutiner for kontrakten samt etablering av opplegg for innrulling av konsulenter),
- utfordringer og risiko,
- ansvarsforhold,
- milepæler og fremdriftsplan,
- forutsetninger for avslutning av oppstartsaktivitetene og
- nødvendige avklaringer knyttet til bruk av metode og retningslinjer, blant annet en første definisjon av «ferdig».
Ofte vil arbeidet med de første leveransene foregå i parallell med deler av oppstartsprosjektet. Her er det viktig at forutsetninger for samarbeid og kommunikasjon mellom partene samt tekniske forutsetninger er etablert på et tilstrekkelig nivå før ordinært arbeidet med leveranser. Med god planlegging kan imidlertid oppstart av ordinære leveranser gi god synergi med oppstartsprosjektet.
3.3 Avslutningsaktiviteter
Ved avslutning av kontrakten er leverandøren forpliktet, innenfor en bestilling, å delta i et avslutningsprosjekt for overføring av kompetanse og erfaring til kunden eventuelt til ny leverandør. Avslutningsprosjektet kan vare i en periode på inntil 3 måneder etter avsluttet avtaleperiode.
Kunden eller en tredjepart utpekt av kunden, har ansvaret for prosjektet, og leverandøren plikter å stille relevante og kompetente ressurser til rådighet.
4 Anskaffelsesprosess og etablering av kontrakt
4.1 Forutsetninger for etablering av kontrakt
Sentrale forutsetninger for kundens bruk av fleksibel utviklingskontrakt er beskrevet i punkt 1.4.
Ut fra det systemområdet som kontrakten skal dekke, må kunden på høyt nivå planlegge det totale omfanget av ressursinnsats for utvikling og forvaltning av systemløsninger samt hvilken andel av dette som skal dekkes av interne ressurser og hva som skal etableres igjennom en eller flere fleksible utviklingskontrakter. Dersom omfanget som skal anskaffes er stort og kunden vil ha mer enn en leverandør for å sikre tilgang på ressurser, kan systemområdet deles opp i flere underområder med egne kontrakter, eller det defineres flere kontrakter for systemområdet ved å etablere parallelle rammeavtaler, som beskrevet i punkt Feil! Fant ikke referansekilden..
Det er en fordel for anskaffelsen dersom kunden kan definere en eller flere bestillinger som skal etablere samtidig med kontrakten siden dette gir et bedre grunnlag for tildeling av kontrakt. For å ha en viss fleksibilitet i en slik bestilling, kan deler av en slik initial bestilling defineres som opsjon.
4.2 Konkurransegrunnlag og krav til utforming av tilbud
Ved utsendelse av tilbudsforespørsel bør de generelle kontraktsbestemmelser og bilag, så langt de lar seg utfylle fra kundens side, være inkludert som grunnlag for potensielle leverandørers tilbud. I offentlige anskaffelser må dette ses i sammenheng med lov om offentlige anskaffelser med tilhørende forskrifter. Uansett bidrar kontraktsbestemmelser og bilag som er utfylt så komplett som mulig, til at leverandørenes tilbud mer effektivt kan sammenlignes, men også til at eventuelle uklarheter avdekkes og de blir mindre arbeidskrevende å ferdigstille som endelig kontrakt mellom partene.
Følgende punkter i bilagene bør forberedes av kunden så langt det er mulig i konkurransegrunnlaget:
- I bilag 1 skal kunden definere det aktuelle systemområdet. Her inngår normalt en overordnet beskrivelse av kundens behov og formål med systemområdet samt av arkitektur og ønsket løsningskonsept for utvikling av systemløsninger
- I bilag 2 kan kunden tilpasse kravene til oppstartsprosjektet. Kunden skal definere parametere i hovedprosessene og eventuelt gjøre tilpasninger i den overordnede beskrivelsen av hovedprosessene. For forvaltningsprosessen er det flere tjenester som forutsetter tilpasninger og tillegg fra kunden.
- I bilag 3 skal kunden definere krav til leverandørens kapasitet for bestillinger samt terskler for endring av kapasitet, og kunden skal definere antall års erfaring som skal legges til grunn for de ulike kompetansekategoriene. Kritiske ressurser skal angis og normalt skal andelen av ressursene som kategoriseres som kritiske være rundt 25 prosent av avtalt kapasitet.
Kunden skal også definere kompetansekrav til leverandørens ressurser innenfor det aktuelle systemområdet for alle relevante roller innenfor utviklingsteam.
Kompetansekravene kan omfatte standardprodukter og skytjenester som skal inngå i systemløsningene. Kompetansekravene bør også inneholde relevante krav til leverandørens representanter (leverandøren bemyndigede person og leverandørens operativ ansvarlige).
- I bilag 4 skal kundens kontaktpersoner være angitt. Videre kan krav til rapportering og møter tilpasses kundens behov.
- I bilag 5 skal kunden definere kommersielle vilkår for eventuell fast utvidelse av serviceperioden og for beredskap. Kunden skal definere forutsetninger for årlige prisreguleringer samt grenser for misligholdsbestemmelser. Kunden må ta stilling til størrelsen på sanksjoner dersom det er et negativt avvik mellom leverte timer i forhold til avtalt kapasitet. Videre må kunden ta stilling til størrelsen på sanksjoner dersom det er manglende ressurser som dekker kompetansekravene ved behov for økning av avtalt kapasitet.
- Bilag 6 er en mal/sjekkliste for bestillinger. Kunden kan ved behov gjøre tilpasninger i sjekklisten.
- I bilag 7 skal kunden stille eventuelle krav til teknisk infrastruktur samt verktøy for utvikling, test og produksjonssetting som skal holdes av leverandøren. Videre skal kundens eventuelle krav til godkjenning av fri programvare fremgå.
I tillegg til bilagene utarbeider kunden normalt et dokument som beskriver betingelser for konkurransen. Her defineres rammer for forventet omfang og kapasitet for kontraktsperioden samt plan og betingelser for gjennomføring av konkurransen.
4.3 Leverandørens utfylling av tilbudstekst i kontrakt
Det anbefales at kunden gjennom konkurransegrunnlaget stiller krav om at leverandøren som del av tilbudet utarbeider en utfylt versjon av kontraktens bilag. Følgende punkter i bilagene bør da minimum fylles ut:
- I bilag 2 skal aktiviteter, plan, risiko og andre forutsetninger for oppstart av kontraktsperioden beskrives. Leverandørene skal også utdype aktiviteter, plan og ansvar ved avslutning av kontraktsperioden.
- I bilag 3 skal den kapasitet som avtales mellom partene defineres. Leverandøren skal identifisere tilbudte ressurser samt andre definerte parametere for hver ressurs, blant annet hvilke ressurser som er kritiske. Leverandørens skal også identifisere eventuelle underleverandører.
- I bilag 4 skal leverandørens representanter defineres.
- I bilag 5 skal timepriser og betingelser for overtidsarbeid defineres.
- I tillegg skal den første bistandsavtalen med leverandørens oppstartsaktiviteter legges ved tilbudet i utfylt form.
Videre er det nødvendig med et utvidet grunnlag for å evaluere leverandøren i forhold til det som vil fremgå av bilagene og den første bistandsavtalen. Dette omtales i etterfølgende punkt.
4.4 Grunnlag for evaluering av tilbud
Evaluering av tilbud i en konkurranse om en fleksibel utviklingskontrakt vil i hovedsak basere seg på hovedområdene kompetanse for tilbudte ressurser, oppstartsprosjekt, timepriser og kontrakt. Selve evalueringen vil basere seg på leverandørenes besvarelse av kontrakten.
Dette må være definert i tildelingskriteriene som inngår i konkurransegrunnlaget.
Følgende områder kan inngå som grunnlag for evaluering av tildelingskriterier og dermed som krav til leverandørens besvarelse:
- Beskrivelse av kompetanse og erfaring for leverandørens tilbudte ressurser i forhold til kundens kompetansekrav. Dette kan være ressurser i initiale bestillinger som kunden spesifiserer for ressurser skal inngå i bestillinger som etableres samtidig med
- Beskrivelse av hvordan leverandøren vil håndtere endringer i kundens kapasitetsbehov i kontraktsperioden.
- Beskrivelse av hvordan leverandøren vil sikre stabilitet i den bemanningen som er hos kunden, og hvordan leverandøren vil sikre at disse ressursene får nødvendig kompetanseutvikling i kontraktsperioden.
- Beskrivelse av hvordan leverandøren vil samarbeide med kunden på høyere ledernivå og på operativt ledernivå slik at leverandøren bidrar til utvikling av kunden samt kontinuerlig forbedring av kvaliteten på tjenestene fra utviklingsteamene.
- Beskrivelse av leverandøren forståelse og eventuelle utdypning av hovedprosessene som er beskrevet i kontrakten.
- Beskrivelse av hvordan leverandøren vil håndtere bestillinger der leverandøren har resultatansvar.
- Beskrivelsen av oppstartsaktiviteter, ref. bilag 2.
- Priser gitt i bilag 5 og i de bestillingene som etableres samtidig med kontrakten.
- Leverandørens beskrivelser og eventuelle kommentarer og forbehold til øvrige punkter i bilagene.
For evaluering av tildelingskriterier for kostnader, bør det benyttes en simuleringsmodell for beregning av kostnader for leverandørens ressurser og andre aktiviteter basert på kontraktens varighet inklusive eventuelle opsjonsperioder.
5 Alternative mekanismer
Dersom kunden vil ha mulighet til å etablere bestillinger der leverandøren skal påta seg et resultatansvar for leveransene, oppfordrer vi til å ta kontakt med Dataforeningen om hvordan dette kan gjøres. Det samme gjelder dersom kunden ønsker benytte avtalen mot flere leverandører i form av parallelle rammeavtaler.