IT-Gruk 5/2022: Bistandsavtalen SSA-B – enkelt og greit eller feilbruk?

Den er godt egnet for mange konsulentkjøp, og spesielt der det ikke er behov for et nevneverdig risikopåslag for verken leverandør eller kunde. Likevel vil jeg påstå at en for utstrakt bruk av SSA-B kan være kontraproduktivt. I dette «IT-gruket» adresserer jeg hva som kan vurderes av tilpasninger, uavhengig av om kunden er offentlig eller privat.

Hva er utgangspunktet for bruk av SSA-B?

Bistandsavtalen er i utgangspunktet beregnet for konsulentkjøp der kunden har behov for kompetanse, men ikke nødvendigvis vet hvordan sluttresultatet skal bli. Det kan være fordi kunden selv ikke innehar den ønskede kompetansen, eller fordi det ikke finnes en kravspesifikasjon som definerer sluttresultatet. Eller det kan være at kunden har sine egne dynamiske behov og en prosjektleder som kan lede prosjektet, forutsatt tilgang til kapasitet i form av eksterne ressurser. I mange tilfeller kan det også være at kunden ønsker større kontroll og ledelse av et prosjekt og dermed ikke ønsker å overlate ansvaret til leverandøren.

Bistandsavtalen er godt egnet for prosjekter hvor kunden er bevisst sitt ansvar med å styre og lede en oppgave, og leverandøren av kompetanse ikke har et resultatansvar. Dette er i motsetning til avtaler hvor leverandøren har et resultatansvar for et oppdrag, leveranse, sluttprodukt eller tilsvarende. Av den grunn finnes det heller ikke et bilag hvor kunden har beskrevet en løsningsspesifikasjon eller oppdragsbeskrivelse, som i de fleste andre av SSA-malene.

Fordeler og ulemper med SSA-B

Nå skal ikke fordelene med SSA-B undervurderes. Avtalen er en viktig mal som har stor betydning i de tilfeller der det viktigste nettopp er å sikre rask tilgang til ressurser i både kompetanse og omfang. I dette ligger at kunden må kunne stille krav til kompetanse eller erfaring som den eller de ønskede ressursene skal ha, og disse skal ytes til kunden innenfor en bestemt tid eller omfang som avtales. I avtalemalen så har kunden en rett til å si opp SSA-B med 30 dagers varsel. Dette gir en fleksibilitet og kapasitet for kunden til å både raskt bemanne opp eller ned et prosjekt med en begrenset risiko. Leverandøren, på sin side, tar heller ikke større risiko da det er kunden som sitter igjen med resultatansvaret for sin investering.

Hva er da utfordringen med SSA-B? Den første og største risikoen for feilbruk av avtalen er at den i enkelte tilfeller benyttes for de prosjekter hvor den ikke er egnet. Eksempelvis er ikke SSA-B egnet for utvikling av programvare eller andre leveranser hvor det er leverandøren som skal stå for den konkrete utviklingen, gjerne stiller med alle utviklingsressursene, og dermed er det leverandøren som i praksis kontrollerer sluttproduktet. Ettersom avtalen ikke har bestemmelser knyttet til testing, godkjenning eller annen form for aksept av leveranse eller resultatet, så står kunden oftest igjen med ansvaret. Kunden har dermed liten påvirkning på når leveransen er klar, og risikerer eksempelvis at budsjettet for prosjektet blir oppbrukt før leveransen er ferdig. Det kan ikke utelukkes at avtalen kan brukes på denne måten, gitt at partene er innforstått med konsekvensene, og i noen tilfeller er det ønskelig og riktig med en «time & material»-aktig tilnærming.

Et annet aspekt som ofte glemmes med SSA-B, er at avtalen krever en aktiv tilnærming til oppfølging av avtalen og leveransen. Avtalen pålegger ikke kunden en direkte plikt til å stille med egne kompetente ressurser, ut over at det presiseres at ytelsen til leverandøren skjer under kundens kontroll og ledelse. I dette ligger både en risiko for manglende leveranse ved kundens manglende ledelse og kontroll, men også en plikt til å følge opp leverandørens løpende ytelse for å kunne korrigere leveransen, fremdriften eller kvaliteten, hvis den ikke er tilfredsstillende.

Likevel er den viktigste utfordringen med SSA-B, som jeg mener ofte glemmes, de tilfeller der SSA-B brukes som et alternativ til en utviklingsavtale/smidigavtale. Det samme er i de tilfeller SSA-B benyttes for å understøtte større driftsprosjekter/skytjenesteprosjekter hvor leverandøren, ofte alene, leverer kompetansen til kunden. Dette er gjerne tilfeller hvor det er brukt en rammeavtale som på en side sikrer kunden tilgang til eksempelvis lisenser eller skytjenester, og på den andre siden sikrer tilgang til et vidt spekter av ressurser ved bruk av SSA-B. Det er min påstand at kundene i slike tilfeller risikerer å stå igjen med en mangelfull leveranse hvor det er benyttet store midler og hvor IT-kompetansen eller realiseringen hos kunden ikke har økt.

Hvilke kontraktsvilkår kan kunden stille til leverandøren?

Kunden kan løse noen av utfordringene som nevnt over ved å benytte en oppdragsavtale med resultatansvar istedenfor en bistandsavtale. Hvis det likevel fortsatt er uklart hva som er målet, og bistandsavtalemodellen er ønskelig, så er et alternativ å gjøre tilpasninger i SSA-B eller eventuelt i tilhørende rammeavtale. Kunden bør vurdere hvilke vilkår som en nødvendige for å oppfylle avtalens formål. I offentlige anskaffelser har kunden en plikt å begrense seg til kontraktsvilkår som er relevante og proporsjonale.  Eksempler på vilkår eller krav som kan være relevante i dette tilfeller er:

• Riktig faglige kompetansen og erfaring hos konsulentene (både type kompetanse og lengden på erfaringen, samt sammensetning av team).
• Krav til leverandørens opplæring av egne ressurser (eksempelvis som et oppstartprosjekt og deretter løpende ha tilstrekkelig antall ressurser som er kjent med kunden).
• Kapasitetskrav hos leverandøren (eksempelvis gjennom en ressurspool).
• Byttefrister (eksempelvis svare opp henvendelse om ressursbehov innen en gitt frist, eller evne til å bemanne opp eller ned med et gitt antall ressurser innenfor en frist).
• Kompetanseoverføring hos leverandøren (plikt for at leverandøren sikrer kompetanseoverføring/overlapp ved endring av egne ressurser).
• Bøter knyttet til bytte av ressurser (enten som engangsbøter eller progressive bøter ved bytte uten kundens samtykke).
• Krav til rutine for kompetanseoverføring fra leverandøren til kunde (eksempelvis modell for overføring, kurs og opplæring av ressurser hos kunden, for å sikre kjennskap til leveransen).
• Skygging av leverandørens arbeid (en rett for både kunde og eventuell tredjepart/ny leverandør, og spesielt mot slutten av en leveranse hvis leveransen skal over til forvaltning).
• Tilpasse riktig bytte- eller termineringsrett for kunden (eksempelvis kortere frist enn 30 dagers avbestillingsrett og dets konsekvenser).
• Rapporteringsplikter underveis i prosjektet for å sikre fremgang og kvalitet opp mot definerte milepæler, samt eventuell eskaleringsmodell ved avvik.
• Krav til estimering av oppdrag, og oppfølging av avviket fra estimatet.
• Prisjusteringsmekanismer – for å sikre riktig pris for ressurser (eksempelvis rabatter ved økt bruk av ressurser).

Merk at tiltak som nevnt over kan innebære en risiko for leverandøren som igjen kan medføre økte kostnader. Listen over er ikke uttømmende, men er forhold som kan vurderes for bedre å utnytte et lengre avtaleforhold.

GRETTE TEKNOLOGI OG DIGITALISERING: NYHETSBREV | FROKOSTMØTE: Ønsker du å få tilsendt våre korte nyhetsbrev innen IT og personvern, så send en melding til pele@grette.no. Vi har stående og kostnadsfritt tilbud om morgenmøte over telefon eller Teams for våre rammeavtaleklienter.