Y5 Kontrakter og aftaler

Formål

Formålet med denne aktivitet er knyttet til behov i forbindelse med anskaffelse, udvikling og levering af produkter og services.

I forhold til EA overblikket er formålet, at udarbejde en oversigt over de indgåede aftaler, der er relevante at tage i betragtning ved udviklingen og implementeringen af en enterprise arkitekturs it-elementer. Med sådan en oversigt kan man nemlig bedre tilrettelægge planen for implementeringen af enterprise arkitekturen – både drage nytte af eksisterende aftaler, og sikre at man ikke bryder indgåede aftaler.

I forhold til et konkret anskaffelses- eller leveranceprojekt er formålet at etablere de nødvendige aftalegrundlag for udvikling og drift. 

Input

På EA-niveau: For at lave EA-relaterede oversigter opsamles samtlige aftaler vedrørende it, både konkrete aftaler og rammeaftaler.

På løsningsniveau: For at lave konkrete projektrelaterede udbud, aftaler og kontrakter anvendes f.eks. standardkontrakter som K01, K02 eller K03 med tilhørende skabeloner.

I forhold til udbud se også Konkurrencestyrelsen vejledning om udbudsreglerne og konkurrenceloven.

Såvel udbudsmateriale og aftaler kan beriges med forskellige typer af arkitekturdokumentation, som f.eks. dem der indgår i OIO EA (arkitektur)dokumentationstyper

Output

Output er Kontraktforhold (Y5.1). 

På EA niveau: En oversigt over kontrakter og andre aftaler der kan påvirke udviklingen og implementeringen af en ny enterprise arkitektur.

På projektniveau: Konkrete udbudsmaterialer, kontrakt eller aftale. Desuden kan det omfatte tjeklister og evalueringer vedr. samarbejdet. Disse kan have stor værdi både i projektet og fremadrettet i forhold til kommende projekter.

 

Metode

På EA niveau:

Med hensyn til oversigten indsamler man de eksisterende aftaler, og opsamler for hver af dem essensen af aftalen. 

Det er uhyre relevant også at få beskrevet sammenhænge mellem forskellige aftaler! Eksempelvis vil et licenseret økonomisystem ofte basere sig på en database og et operativsystem der er licenseret fra andre leverandører, og man kan derfor ikke blot ændre i én aftale uden at tage højde for de bindinger der er til andre aftaler. Bindingen kan for eksempel være sådan at man forpligter sig til løbende at opgradere sin database og operativsystem, før supportaftalen med økonomisystemet gælder.

De aftaler der kan være relevante at opsamle / udarbejde, omfatter:

  • Driftsaftaler. Disse dækker aftaler mellem to eller flere parter med hensyn til driftskapacitet, support og konsulentydelser mv.
  • Licensaftaler. Disse omfatter typisk support- og opgraderingsomkostninger til operativsystemer, database-systemer, ERP-systemer og andre løsninger. Se også bemærkning i gode råd.
  • Leverandøraftaler. Disse dækker kontrakter mellem rekvirent og leverandør vedr. leverance af ydelser og/eller systemer. Dette kan omfatte SKI-aftaler, hvor et antal leverandører er udvalgt indenfor forskellige leverancekategorier, og timepriser allerede aftalt.
  • Kontraktudkast dækker forslag til kontrakt og udkast til kontraktbilag mellem myndighed/virksomhed og it-leverandør. Der kan for eksempel være tale om aftaler under SKI, hvor kontrakterne er fastlagte, bortset fra de bilag der specificerer den konkrete ydelse.
  • SLA-aftaler (Service Level Agreement) dækker aftaler mellem en aktør (intern eller ekstern), som leverer en it-ydelse og en bruger/forretningsenhed som anvender ydelserne.
  • Web-serviceaftale. Disse dækker aftaler mellem serviceudbyder og servicekonsument om tilvejebringelse af web-service baseret snitflade i Service Orienteret Arkitektur (SOA). De beskrives via en WSDL.
  • Udbudsannoncer. Disse dækker udbudsannoncer, jfr. EU's udbudsdirektiv.
  • Anskaffelsesprocesser.  Disse dækker beskrivelser af processer som har til formål at anskaffe et it-system (fx EU udbudsproces).  Der vil i disse være kontraktmæssige bindinger til hvordan et sådant anskaffelsesforløb skal ske.
  • Fler-parts aftaler. Disse dækker aftaler mellem to eller flere, som stiller web-services og andre it-grænseflader til rådighed for hinanden – som system-system snitflader eller som brugergrænseflader.

På løsningsniveau:

 

Mht udforming af kontrakter anbefaler Digitaliseringsstyrelsen tre typer standardkontrakter:

  • K01 er målrettet leverance af standardprodukter, hvortil der kun i begrænset omfang skal ske specialtilpasninger.
  • K02 er velegnet til større komplekse it-projekter, som indebærer faseopdelte delleverancer.
  • K03 er velegnet til it-projekter, hvori der anvendes agile udviklingsmetoder. Kontrakten er under udarbejdelse.

Du kan downloade og læse mere om standardkontrakterne på Digitaliseringsstyrelsens hjemmeside.

Gode råd

Man bør udvikle enterprise arkitekturen (A1 til C4) uafhængigt af eksisterende aftaler. I gap analysen (D og ikke mindst i D1. Restriktioner), kan man så tage højde for de eksisterende aftaler, således at en migrationsplan (E2) også tilgodeser disse (eksempelvis at aftaler udløber på givne tidspunkter, og med fordel kan erstattes af andre).

Open source software er de senere år blevet meget relevant i mange sammenhænge. Man bør dog være opmærksom på at open source også har nogle kontraktuelle licens-forpligtelser. Nogle open source licenser – for eksempel GPL (GNU General Public License) – stiller krav om at man offentliggør de ændringer til kildekoden man har foretaget. Hvis man integrerer open source med et proprietært system, kan dette indebære at dele af det proprietære systems kildekode også skal offentliggøres, hvilket man nok ikke har rettighederne til. Så man bør undersøge disse forhold, og sikrer sig at man ikke påtager forpligtelser man ikke ønsker.

Man bør generelt sikre sig så meget ejerskab over kildekode som muligt.  It-leverandører af integrationer mellem systemer bør så vidt muligt give ejerskabet af kildekoden til integrationerne videre, således at man selv fremover kan vedligeholde integrationen.

Den fællesstatslige it-projektmodel indeholder en guide, som du kan anvende til at forbedre samarbejdet i dit it-projekt. Desuden indeholder den ledelsesprodukter i form af en samarbejdstjekliste til løbende at følge op på samarbejdet og et slutevalueringsskema til at evaluere samarbejdet med.  Hent guide, tjekliste og skema her.

Permanent URL til denne artikel: http://arkitekturguiden.digitaliser.dk/node/67