• nøglen til vellykkede edb-projekter

Vejledning i

Kontraktstyring

• nøglen til vellykkede edb-projekter

Forfattere: Xxxxxxx Xxxx-Xxxxxx, Xxxxxxxx

Xxxxxx Xxxxxxxx, CRI Xxxxx Xxxx Xxxxxxxx, Datacentralen

Dette er en foreløbig arbejdskopi, som kun må kopieres efter aftale med en af forfatterne.

Denne pjece giver en introduktion på dansk til første udgave af Euromethod: Euromethod Version 0.

Euromethod version 0 består af følgende dokumenter på engelsk:

Euromethod Guides

2.3. Delivery Planning Guide

2.4. Method Bridging Guide Euromethod Concepts Manuals

4. Euromethod Dictionary

3.3.

Strategy Model

3.2.

Deliverable Model

3.1.

Transaction Model

2.5.

Case Study

2.2.

Supplier Guide

2.1.

Customer Guide

1. Euromethod Overview

Mere information om Euromethod kan fås ved henvendelse til: Xxxxx Xxxx Xxxxxxxx, Datacentralen

Tlf.: 00 00 00 00. Fax: 00 00 00 00. Internet: xxx@xx.xx.

Euromethod dokumenter kan rekvireres ved henvendelse til: Euromethod Information Office

Xxxxxxxxxxxx 00/00 1930 Zaventem Belgien

Tlf.: x00 0 000 0000. Fax: x00 0 000 0000.

Indholdsfortegnelse

1. Indledning 4

2. Før kontrakten 6

2.1. Afklaring af mål og fremgangsmåde (kunde) 6

2.2. Tilrettelæggelse af udbudsforretning (kunde) 11

2.3. Udformning af udbudsmateriale (kunde) 13

2.4. Udformning af tilbud (leverandør) 14

2.5. Vurdering af tilbud (kunde) 16

3. Kontrakten 18

3.1. Kontraktens omgivelser 18

3.2. Leveranceplan 19

3.3 Ansvarsfordeling 30

3.4. Redigering af kontrakt 31

4. Kontrakten som styringsværktøj 34

4.1. Etablering af projektorganisation 34

4.2. Hændelser vedrørende anvendelsesområdet 37

4.3. Hændelser vedrørende projektområdet 40

4.4. Håndtering af konflikter 41

4.5. Projektafslutning 42

5. Litteraturliste 43

1. Indledning

Formålet med denne pjece er at give praktisk vejledning i at udforme en skrift- lig kontrakt for et edb-projekt og i at anvende den effektivt til styring af projek- tet. Emnet kontraktstyring er vigtigt både for kunder og for leverandører. Ikke alene kan begge parter spare tid og reducere transaktionsomkostninger ved at vælge passende kontraktformer; i nogle tilfælde afhænger selve projektets gen- nemførlighed af, at der vælges egnede aftaleformer og -procedurer.

Traditionelt har aftaler om edb-projekter været baseret på købe- og entreprise- ret. Det fungerer godt i nogle tilfælde; men i andre tilfælde ligner et edb-pro- jekt ikke en vare eller en veldefineret konstruktionsopgave. Vanskelighederne opstår i edb-projekter med stor usikkerhed. Usikkerheden skyldes, dels at der er tale om væsentlig nyudvikling, dels at edb-projekter griber ind i komplicerede tekniske og organisatoriske sammenhænge. De traditionelle aftaler er ikke eg- nede til at håndtere disse situationer. Konsekvensen bliver både styringsmæssigt og økonomisk utilfredsstillende for såvel kunder som leverandører.

Denne pjece lægger op til nytænkning ved at foreslå en bredere og mere gene- relt anvendelig kontraktstyring, der rummer de traditionelle kontraktformer som en ægte delmængde. Pjecens hovedprincipper er:

• Situationen afgør, hvilken edb-strategi, og herunder hvilken projektstrategi, der er mest egnet, og dermed hvilken kontraktform og -styring, der bør vælges. Specielt skal der bevidst vælges mellem en traditionel alt-i-én løs- ning og mere trinvise løsninger.

• Kontrakten, der er grundlaget for styringen af projektet, skal også selv sty- res dynamisk. Der skal være en effektiv måde, hvorpå parterne kan revide- re de indgåede aftaler. Kontraktstyringen skal baseres på en leveranceplan med beslutningspunkter og milepæle.

Pjecen har form som en vejledning til kunder og leverandører. Hovedstrukturen er opbygget over de typiske situationer, der opstår før, under og efter kon- traktudarbejdelsen. Det er vores hensigt, at pjecen skal give en orientering om de væsentligste spørgsmål inden for emnet. Vi forventer ikke, at pjecen skal give et udtømmende svar på alle spørgsmål, derfor henvises der mange steder til uddybende litteratur, først fremmest til Euromethod's vejledninger.

Pjecen er udarbejdet som en del af Euromethod-projektet. Euromethod-projek- tet er et langsigtet og ambitiøst EU-projekt, der har til formål at forbedre den tekniske del af kontraktgrundlaget for edb-leverancer. Dette gøres ved at ud- vikle et fælles begrebsapparat for både kunde og leverandør i EU-udbuds- forretninger. Euromethod skal være grundlaget for at undgå tekniske handels- hindringer omkring brug af nationale metodestandarder, for eksempel ved at Euromethod i én eller anden udstrækning bliver gjort til europæisk eller inter- national standard.

Euromethod er udviklet for EU-Kommissionen med rådgivning fra PPG, Public Procurement Group, bestående af repræsentanter for de offentlige admi- nistrationer i EU-landene. Euromethod-projektet startede i 1988. Den første foreløbige udgave af Euromethod er, efter en EU-udbudsforretning i 1991, ud- viklet af et konsortium af virksomheder, Eurogroup, fra 8 EU-lande. Konsortiet er ledet af Sema Group fra Frankrig. Fra Danmark har Datacentralen deltaget. Eurogroup har udviklet Euromethod i en projektgruppe med repræsentanter fra konsortiet. Projektgruppen blev støttet af eksperter fra universiteter og andre private og offentlige virksomheder.

Version 0 af Euromethod skal afprøves i 1995. Det skal dels ske i 'live' edb-pro- jekter og dels ved simulering ud fra faktisk gennemførte projekter. Eurogroup yder konsulentbistand ved afprøvningen. I slutningen af 1995 skal erfaringerne fra afprøvningen systematiseres, og næste version af Euromethod skal udarbej- des af Eurogroup i starten af 1996 og gøres tilgængelig for alle virksomheder i EU. Desuden skal relevante dele af Euromethod indgå i arbejdet med standardi-

sering på edb-området. Xxxxxx dele, og hvordan, vil afhænge af afprøvningen og den offentlige reaktion i 1995.

Forfatterne vil gerne takke de personer, der undervejs har bidraget med gode ideer og kommentarer, idet vi understreger, at pjecens synspunkter kun udtryk- ker forfatternes egen mening.

København, maj 1995

Xxxxx Xxxx Xxxxxxxx, Datacentralen Xxxxxx Xxxxxxxx, CRI

Xxxxxxx Xxxx-Xxxxxx, Xxxxxxxx

2. Før kontrakten

Aftalestyring i et edb-projekt bygger normalt på en skriftlig kontrakt. Det er en udbredt misforståelse, at kontraktarbejdet er en isoleret fase efter udbuds- forretningen. Realiteten er en ganske anden. Med en fornuftig tilrettelæggelse af udbudsforretningen kan kontraktens indhold opbygges stille og roligt som et produkt af arbejdet med at kvalificere tilbudsgivere og udvælge det bedste til- bud.

I dette kapitel gives vejledning i det forberedende arbejde, før kontrakten en- delig udformes. Det omfatter følgende 5 hovedaktiviteter:

1. Afklaring af mål og fremgangsmåde. 2. Tilrettelæggelse af udbudsforretning. 3. Udformning af udbudsmateriale.

4. Udformning af tilbud. 5. Vurdering af tilbud.

I de to efterfølgende kapitler gives der vejledning i udformning af kontrakter og i styring af projektaftaler baseret på kontrakter.

2.1. Afklaring af mål og fremgangsmåde (kunde)

Et edb-projekt starter med, at en organisation ønsker at forbedre sine arbejds- processer ved brug af edb-teknologi. Organisationen ønsker med andre ord at forbedre sit informationssystem - at gennemføre en IS-tilpasning (Euromethod terminologi). Før projektet udbydes, skal kunden afklare sine mål og den ønskede overordnede fremgangsmåde. Denne aktivitet kaldes en for- undersøgelse eller udformning af en edb-strategi. Aktiviteten bør resultere i en rapport, der lægger op til en række afgrænsninger af betydning for det efter- følgende arbejde: Hvordan opdeles projektet i enkeltkontrakter, der kan karak- teriseres ved start- og sluttilstande? Hvilke kontrakter skal udbydes hvornår? Hvilken teknologi baserer man sig på? Hvilke leverandører henvender man sig til?

Kunden kan vælge at udbyde forundersøgelses- eller strategiopgaven som en første, afgrænset kontrakt.

En sekvens af kontrakter

Selv om kunden ser edb-projektet som én opgave, er det som regel en fordel for kunden at planlægge en sekvens af kontraktmæssige forhold med en eller flere leverandører, som vist i figur 1. Ved at operere med mindre kontrakter bliver den enkelte udbudte opgave mere præcis, og kunden kan derfor forvente at gøre en bedre handel. Edb-markedet har endvidere i en årrække været præget af stor fornyelse og faldende priser på standardprodukter. I den situation bør aftaler ikke indgås unødigt tidligt.

Nuværende informations- system

U

G

A

U G A U G A

En enkelt kontrakt

Ønsket informationssystem

=

Det langsigtede mål

En sekvens af kontrakter

Figur 1: Kunden kan bevæge sig fra start- til sluttilstanden gennem en kontrakt om et enkelt projekt (øverst) eller gennem en sekvens af kontrakter (nederst). (U: udbudsforretning; G: gennemførelse; A: afslutning)

Sekvensen af kontrakter skal vælges, så de enkelte kontrakter kan styres. Hver kontrakt skal karakteriseres af en starttilstand og en sluttilstand. Euromethod indeholder beskrivelser af typiske start- og sluttilstande for edb-projekter. End- videre giver Euromethod en anbefaling af, hvilke kombinationer der styrings- mæssigt er fornuftige, se figur 2.

Nedenfor gives eksempler på kontrakter, der ofte forekommer. Eksemplerne svarer til nogle af kombinationerne i figur 2. Numrene er angivet i figuren.

1. Analyse: Fra problembeskrivelse til edb-forandringsanalyse.

Opgaven er at analysere alternative muligheder for forbedret anvendelse af edb samt at udarbejde forslag til edb-teknisk arkitektur med scenarier for brug af edb. Kunden har udarbejdet en overordnet edb-strategi samt skitse- ret de anvendelsesområder, der skal analyseres. Projektrammerne vil typisk være fleksibel tid og rammebestemt økonomi.

2. Design: Fra anvendelsesorienteret design til teknisk design.

Kunden har, eventuelt i samarbejde med et konsulentfirma, udarbejdet et anvendelsesorienteret design (en kravspecifikation) af informations- systemet inden for et eller flere af de anvendelsesområder, der blev analy- seret under analysen. Opgaven består i at udarbejde et detaljeret design af edb-systemet, herunder design af anvendelsen af edb-systemet. Strategien for beskrivelse af edb-systemet kan være analytisk eller eksperimentel, og strategien kan være ekspertstyret eller deltagerstyret. Projektrammerne vil typisk være fleksibel tid og rammebestemt økonomi.

3. Indførelse: Fra teknisk design til indført informationssystem.

Xxxxxx har valgt og beskrevet et detaljeret design af et edb-system. Opga- ven er at konstruere og indføre dette edb-system. Strategien for indførelse kan være: alt-i-én, stykvis eller versionsvis. Projektrammerne vil typisk væ- re fast tid og fast pris. Fast tid og fast pris rammer kan ikke anvendes gene- relt i edb-projekter, idet det er svært at overskue alle muligheder og be- grænsninger i den valgte edb-teknologi før konstruktion og indførelse.

4. Tilpasning af standardsystem: Fra anvendelsesorienteret design til indført informationssystem.

Hvis edb-forandringsanalysen viser, at det er muligt at basere IS-tilpasnin- gen på indførelse af standardsystemer, vil design og konstruktion være simplere og måske kun bestå i tilretning af standardsystemerne. I disse til- fælde vil design og indførelse være omfattet af den samme kontrakt, og projektrammerne vil typisk være fast tid og fast pris.

5. Vedligeholdelse: Fra problembeskrivelse til indført informationssystem.

Kunden har beskrevet problemer i det eksisterende informationssystem samt ønsker til forbedringer. Opgaven består i at analysere ønskerne, de- signe et modificeret system samt at konstruere og indføre en ny version af informationssystemet. Projektrammerne vil typisk være fleksibel tid og rammebestemt økonomi.

Slut- tilstand Start- tilstand
Udokumenteret informationssystem	√	√	√	!	!	!	!
Dokumenteret informationssystem	√	√	√	!	!	!	!
Problem- beskrivelse	-	√	√(1)	√	!	!	!(5)
Design- skitse	-	√	√	√	√	!	!
Anvendelses- orienteret design	-	-	-	√	√(2)	√	√(4)
Teknisk design	-	-	-	-	√	√	√(3)
Testet informationssystem	-	-	-	-	-	√	√

Signaturer: √

!

Gennemføres normalt i én IS-tilpasning.

En sekvens af IS-tilpasninger bør overvejes.

Figur 2: Kombinationer af start- og sluttilstande i en kontrakt. Eksempler: 1. Analyse: Fra problembeskrivelse til edb-forandringsanalyse.

2. Design: Fra anvendelsesorienteret design til teknisk design.

3. Indførelse: Fra teknisk design til indført informationssystem.

4. Tilpasning af standardsystem: Fra anvendelsesorienteret design til ind- ført informationssystem.

5. Vedligeholdelse: Fra problembeskrivelse til indført informations- system.

Dette er eksempler på kontrakter for edb-projekter, mange andre varianter kan anvendes. Det vigtigste er at vælge den overordnede fremgangsmåde i form af en sekvens af kontrakter med leverandører, så den modsvarer situationen og minimerer risikoen for ikke at nå de ønskede mål. Fremgangsmåden skal væl- ges situationsbestemt, og således at de kritiske forhold afklares så hurtigt som muligt i forløbet. Sluttilstande for kontrakter skal vælges, så de er et godt grundlag for væsentlige beslutninger. Disse beslutninger kan vedrøre følgende forhold (sluttilstand er angivet i en parentes):

• Prioritering af områder, der skal forbedres (IS-forandringsanalyse).

• Valg af teknisk arkitektur (edb-forandringsanalyse).

• Grad af egenudvikling og brug af en eller flere eksterne leverandører (overordnet edb-strategi, forandringsanalyser).

• Brug af standard edb-systemer, tilrettede standardsystemer eller special- udviklede systemer (anvendelsesorienteret design).

• Valg af systemløsninger (teknisk design).

Ved valget af den overordnede fremgangsmåde som en sekvens af kontrakter skal man være opmærksom på, at arbejdet med at gennemføre en udbudsforret-

ning og indgå en kontrakt ikke er uden omkostninger. Som offentlig indkøber skal man endvidere følge EU's regler for udbudsforretninger, og de tager ret lang kalendertid - typisk et halv års tid. Man kan delvist omgå problemet ved at definere en udbudsforretning, der indeholder en sekvens af delkontrakter med mulighed for afbrydelse undervejs. Men det er et grundlæggende princip, at en udbudsforretning skal omhandle en så klar definition af opgaven, at det for alle udbydere er klart, hvad udbudsforretningen indebærer, så friheden har sine grænser.

En eller flere leverandører

Anbefalingen af en sekvens af kontrakter er samtidig et brud med ideen om én leverandør med et totalt ansvar for projektet. Denne ide er fremherskende i de danske standardkontrakter inden for det offentlige (K18 og K33). Her forud- sættes blandt andet, at leverandøren har forstand på anvendelsesområdet, kan levere såvel hardware som software, kan tage ansvar for det eksisterende system, kan påtage sig projektledelse og kan sikre fremtidig vedligeholdelse.

At basere strategien på en sådan ideel totalleverandør indebærer på den ene side en betydelig sikkerhed og bekvemmelighed for kunden. På den anden side er der betydelige omkostninger forbundet hermed. For det første indsnævres an- tallet af mulige leverandører meget, hvilket alt andet lige betyder en højere pris. For det andet kan kunden kun give leverandøren et totalansvar ved samtidigt at give leverandøren en betydelig indflydelse på kundens edb-anvendelse. For det tredje binder kunden sig stærkt til en enkelt leverandørs teknologi og kompe- tence. Det betyder, at det vil være meget dyrt og besværligt at skifte leverandør i forbindelse med efterfølgende modifikationer. Rygtet vil vide, at der findes leverandører, som har udnyttet denne situation.

Det er derfor en vigtig beslutning, om man vælger en totalleverandør eller en model med opdeling i flere kontrakter med forskellige leverandører. Denne beslutning afhænger af den aktuelle situation, herunder af opgavens størrelse, af kundens egen kompetence og af, om der findes et rimeligt antal leverandører, som er troværdige emner til rollen som totalleverandør.

Vurder risikofyldte forhold i situationen

Edb-projekter er erfaringsmæssigt ofte risikofyldte. Udfordringen er at være bevidst om de væsentligste risici og håndtere dem hensigtsmæssigt. Risici er knyttet til den kompleksitet og usikkerhed, der er forbundet med at komme fra udgangspunktet og til de langsigtede mål. Kompleksitet og usikkerhed kan analyseres systematisk med udgangspunkt i Euromethod's lister af forhold i situationen relateret til henholdsvis anvendelsesområdet (informationssystemet og edb-systemet) og projektområdet. Herved tages der stilling til blandt andet følgende:

• Er der store interesseforskelle blandt aktører?

• Hvor komplekse er forretningsprocesserne?

• Hvor stabile er omgivelserne?

• Er kravene afklarede og veldefinerede?

• Hvor ny er den foreslåede teknologi?

• Hvor stort er projektet?

• Er tidsrammer og budgetter særligt stramme?

• Er der mange underleverandører?

Euromethod indeholder skemaer med mange flere og mere detaljerede spørgs- mål af denne type.

Ud fra besvarelserne kan det vurderes, hvilke forhold der er særligt vanskelige og giver størst risiko. Den samlede risiko reduceres mest ved at rette strategien mod at ændre eller undgå de vanskeligste forhold. To tommelfingerregler kan anbefales:

• Hvis der generelt er stor usikkerhed i projektet, bør strategien være et ek- sperimentelt forløb med små trinvise kontrakter. Herved opnås, at erfarin- gerne fra starten af forløbet kan få indvirkning på de efterfølgende kon- trakter. Modsætningsvis kan det siges, at i en situation med stor usikkerhed er det katastrofalt at lave én, stor fastpriskontrakt for hele projektet.

• Hvis der generelt er stor kompleksitet i projektet, bør strategien være en detaljeret kontrakt og en tæt styring. Kompleksitet indebærer, at ressourcer, aktiviteter og resultater griber meget ind i hverandre. Det giver et styrings- mæssigt overhead, idet afvigelser skal tages i opløbet, for at de ikke skal få uoverskuelige følger. Hvis kunden og leverandøren ikke begge er forbe- redt på dette, vil projektarbejdet blive forsinket på grund af manglende be- slutninger omkring afvigelser.

Denne form for analyse af situationen bør gentages på forskellige tidspunkter under IS-tilpasningen for at udnytte, at kundens viden om situationen forbed- res.

Beskriv mål og fremgangsmåde

Afklaringen af mål og fremgangsmåde for IS-tilpasningerne skal resultere i føl- gende:

• Beskrivelse af udgangspunkt.

Status for det nuværende informationssystem med en oversigt over den nu- værende dokumentation. Dette omfatter en beskrivelse af muligheder for en forbedret anvendelse af edb.

• Beskrivelse af det langsigtede mål.

Krav og ønsker til forbedring af informationssystemet. Formålet med for- bedringer skal beskrives, og der kan opstilles konkrete målsætninger. For eksempel mål for arbejdssituationen for brugere og mål for ekspe- ditionshastighed.

• Vurdering af opgavesituationen.

Overordnet vurdering af de kritiske forhold i situationen ud fra en vurde- ring af kompleksitet og usikkerhed forbundet med at nå de langsigtede mål.

• Beskrivelse af en overordnet fremgangsmåde.

Strategi for inddragelse af eksterne leverandører via udbudsforretninger, for eksempel:

- Brug af en eller flere leverandører.

- Brug af konsulenter ved gennemførelse af udbudsforretninger.

- Faste eller fleksible tidsmæssige rammer.

- Faste, rammebestemte eller fleksible økonomiske rammer.

Skitse af start- og sluttilstande i kontrakter. Formålene med sluttilstandene skal beskrives.

2.2. Tilrettelæggelse af udbudsforretning (kunde)

Formålet med at lave en plan for udbudsforretningen er, at kunden med en fornuftig indsats får en god sikkerhed for den bedst mulige kontrakt.

Regler for offentlige udbud

For offentlige udbud gælder visse særlige regler dels på grund af Danmarks deltagelse i internationale handelsaftaler - EU og GATT - dels på grund af dansk lovgivning og "god forvaltningsskik"1. De offentlige regler sigter specielt

1 Det ligger uden for denne pjece nærmere at gennemgå disse regler - der kan henvises til Statens og Kommunernes Indkøbsservice, hvorfra de aktuelle regler kan rekvireres. Der

på at forhindre, at udbyderen (kunden) uretmæssigt tilgodeser en national til- budsgiver (leverandør), der i øvrigt ikke repræsenterede det bedste tilbud. Men uanset om man er en offentlig eller privat udbyder, så har man grundlæggende den samme - rent købmandsmæssige - interesse i at opnå og at vælge det bedst mulige tilbud.

Selv om de formelle procedurer specielt dækker offentlige edb-projekter, er såvel formålet med disse procedurer som deres hovedindhold umiddelbart for- nuftige og anvendelige også for private edb-projekter af en vis størrelse (EU's formelle grænser ligger omkring 1 1/2 mio. kr., og det svarer normalt godt til, at behovet for en formaliseret procedure for udbudsforretningen bliver påtræn- gende, skønt edb-projektets karakter også spiller en vigtig rolle. De formelle grænser justeres løbende. I forbindelse med et konkret edb-indkøb skal de ak- tuelle tærskelværdier anvendes).

Prækvalifikation

Den fremgangsmåde, som foreskrives i de offentlige udbudsregler2, er at opdele udbudsforretningen i to faser. Den første fase (prækvalifikation) har til formål at finde en kreds af kvalificerede tilbudsgivere, medens den anden fase (udbud- tilbud) skal resultere i det bedst mulige tilbud.

Baggrunden for denne opdeling er, at et kvalificeret tilbud fra en leverandør repræsenterer en betragtelig arbejdsindsats fra leverandørens side, og at en kva- lificeret gennemgang hos udbyder af et tilbud også er ressourcekrævende. Det er derfor spild af alle parters tid at indhente tilbud fra leverandører, man i øvrigt ikke mener er kvalificerede til at løfte opgaven. Hertil kommer, at sandsynlig- heden for at få kvalificerede tilbud øges betragteligt, når tilbudsgiverne kan se, at de tilhører en snæver kreds af udvalgte, hvorfor de må vurdere deres chance for at vinde som rimelig høj.

Kvalificering af tilbudsgivere

En prækvalifikation omfatter fire aktiviteter: Annoncering af udbudsforretning, potentielle tilbudsgivere rekvirerer materiale, interesserede tilbudsgivere indsen- der prækvalifikationsmateriale, og udbyder udvælger kvalificerede tilbudsgivere og giver meddelelse herom.

Annoncering er for offentlige udbydere et opslag med en helt fast disposition i EF-tidende. Private udbydere kan vælge at sende en kort orientering til en bred kreds af mulige tilbudsgivere.

Potentielle tilbudsgivere kan rekvirere materiale hos udbyderen. Dette materiale bør omfatte:

• Præsentation af kunden

• Præsentation af projektet (formål og indholdsmæssig afgrænsning).

• Tidsplan for udbudsforretningen.

• Forventninger til leverandørens rolle og kvalifikationer.

• Forventninger til den potentielle tilbudsgivers besvarelse (årsregnskaber, kompetenceprofil, referencer).

• Angivelse af vurderingskriterier.

For offentlige udbydere er det et krav - og for private en god ide - at føre pro- tokol over alle henvendelser og besvarelser under udbudsforretningen.

Herefter indsender interesserede tilbudsgivere prækvalifikationsmateriale.

tænkes specielt på EU's direktiver for indkøb og for tjenesteydelser, se [Indkøb] i litte- raturlisten i kapitel 5.

2 Der tages udgangspunkt i EU-direktivernes bestemmelser om begrænset udbud. Det er den fremgangsmåde, der som regel er den mest hensigtsmæssige ved edb-projekter.

Ud fra den strategi, der er lagt, udvælger kunden de bedste leverandører. Der bør vælges 3 til 5. Ved kun at vælge 2 gør kunden sig meget sårbar over for afbud. Hvis der vælges mange, forsvinder fordelen ved prækvalifikation.3

Efter udvælgelsen meddeler kunden resultatet til indsenderne.

2.3. Udformning af udbudsmateriale (kunde)

Kunden fremstiller udbudsmaterialet og sender det til de prækvalificerede til- budsgivere. Udbudsmaterialet omfatter følgende hovedpunkter: Hoved- leverance, andre leverancer, kontrakt, tilbuddets udformning og plan for ud- budsforretningen.

Hovedleverance

Hovedleverancen beskrives først og fremmest ved sluttilstanden. Sluttilstanden kan være et dokument, der har bragt kundens IS-tilpasning et skridt videre. I så fald skal dette dokument karakteriseres ved sin type (for eksempel forunder- søgelsesrapport, kravspecifikation og designdokument) og en afgrænsning af det system, dokumentet skal handle om. Euromethod omfatter en metode- neutral begrebsramme til at karakterisere dokumenter, der optræder som mel- lemprodukter i en edb-systemudvikling.

I et traditionelt konstruktionsprojekt er sluttilstanden et fungerende system. Dette bør være beskrevet i en kravspecifikation. En kravspecifikation skal be- skrive systemet med hensyn til arkitektur, dataindhold, funktioner og bruger- grænseflade. Kravspecifikationen skal også angive driftsmæssige krav vedrø- rende for eksempel kapacitet, sikkerhed, miljø og modificérbarhed samt krav til opfyldelse af standarder, se [Standard] i litteraturlisten i kapitel 5.

Hensigten med at beskrive opgaven ved krav til en sluttilstand er, at kunden skal beskrive opgaven, og at leverandøren skal foreslå løsningen. Der er altid en flydende overgang mellem opgave og løsning; men ideen er, at kunden ikke skal må låse sig unødigt fast på en bestemt teknologi i udbudsmaterialet. Gør man det, afskærer man sig fra et antal gode løsninger, eller man roder sig ud i formelle problemer ved senere at afvige fra udbudsmaterialet.

I beskrivelsen af hovedleverancen indgår også en beskrivelse af starttilstanden. Starttilstanden er kundens organisation og forretningsgange, kundens eksiste- rende edb-systemer og de foreliggende dokumenter. Det er væsentligt at be- skrive starttilstanden. Dels viser den de forudsætninger for edb-projektet, som kunden er ansvarlig for tilstedeværelsen af ved starten af projektet. Dels giver den baggrundsinformation, hvoraf en erfaren leverandør bør kunne udlede naturlige krav, som ikke eksplicit er nævnt i kravene til sluttilstanden.

Endelig kan beskrivelsen af hovedleverancen omfatte krav til processen, herun- der projektledelse, rapportering og brugerinddragelse.

Andre leverancer

Udbudsmaterialet bør beskrive andre leverancer for at klargøre, om disse skal være omfattet af tilbuddet, eller i hvilket omfang leverandøren skal medvirke til at definere og planlægge disse leverancer. Typiske supplerende leverancer ved et konstruktionsprojekt kan være:

• Uddannelse.

• Konvertering.

• Ombygning og tekniske installationer.

3 Hvis man på forhånd formelt har besluttet, hvor mange der skal prækvalificeres, skal antallet angives i udbudsannonceringen. I så fald skal antallet ifølge EU's direktiver være mindst 5 og højest 20.

• Vedligeholdelse.

Kontrakt

Udbudsmaterialet skal indeholde et forslag til kontrakt. Det kan anbefales at henvise til en standardkontrakt, for eksempel [K18] eller [K33], og opfordre tilbudsgiver til at anføre, på hvilke punkter han har forbehold hertil. Så må de vilkår, hvorpå leverandøren vil levere, indgå i den samlede tilbudsvurdering. Rent praktisk har man også fået sat en dagsorden for eventuelle udestående afklaringer ved etablering af kontrakten.

Tilbuddets udformning

Udbudsmaterialet skal beskrive krav til tilbud. Formålet hermed er at sikre, at tilbuddene indeholder de oplysninger, kunden skal bruge, og at leverandørerne stilles lige.

Disse krav omfatter en disposition for tilbuddet. Hertil hører krav til angivelse af priser og tider samt krav om tilbuddets gyldighedsperiode.

Plan for udbudsforretningen

Kunden skal beskrive en tidsplan for udbudsforretningen. Tidsplanen kan in- deholde følgende punkter:

• Leverandøren bekræfter, at tilbud vil blive afgivet. Hermed sikrer kunden sig, at materialet er nået frem, og at der vil indkomme tilstrækkeligt mange tilbud.

• Leverandørerne får besvaret supplerende spørgsmål. Dette kan foregå skriftligt inden en vis forudannonceret frist, hvorefter alle spørgsmål og svar kan tilsendes alle leverandører. Herved stilles alle lige.

• Tilbuddene indsendes. Kunden fører fortsat protokol over væsentlige hæn- delser i udbudsforretningen. At modtage et tilbud er en af de vigtigste be- givenheder, som bør bekræftes skriftligt.

2.4. Udformning af tilbud (leverandør)

Før leverandøren afgiver et tilbud på en opgave, skal det vurderes, om det i det hele taget kan betale sig at bruge ressourcer på at udarbejde tilbuddet. I det omfang, det er muligt, skal denne analyse gennemføres, før leverandøren ind- sender prækvalifikationsmateriale.

Tilbudsforanalyse

Tilbudsforanalysen, der bør gennemføres i løbet af højst 2 dage, bør omfatte en analyse af udbyders forhold, udbudsmaterialet, leverancens karakter, leveran- dørens egne forhold og konkurrence situationen, blandt andet vedrørende:

• Kendskab til og samarbejdsrelationer til udbyder.

• Kvalitet af udbudsmaterialet.

• Realistiske krav til leverancen.

• Krav til investeringer.

• Tilgængelige ressourcer.

• Konsekvenser af at få henholdsvis ikke få opgaven.

Udarbejdelse af tilbud

Gode råd:

• Inddrag den fremtidige kontraktansvarlige og den fremtidige projektan- svarlige i udarbejdelse af tilbuddet. De skal være "visionsbærere" af det til- budte løsningsforslag.

• Nærlæs opgavebeskrivelsen i udbudsmaterialet og afdæk uklarheder. Om muligt præciseres disse uklarheder sammen med udbyder og doku- menteres eksplicit i tilbuddet. Hvis uklarheder ikke kan præciseres, bør forbehold og tolkninger beskrives som en del af tilbuddet.

• Anvend et systematisk grundlag for vurdering af risici, for eksempel Eu- romethod's liste over forhold i situationen.

• Lav aftaler med alle parter, der skal medvirke ved gennemførelse af opga- ven.

• Gennemfør review af tilbuddet, hvor det kontrolleres at:

- Grundlag og omfang er defineret og dokumenteret.

- Mulige risici er erkendt og vurderet.

- Ophavsret og brugsret er defineret og beskyttet.

- Afvigelser fra udbudsmaterialet er beskrevet.

- Lovgivnings- og myndighedskrav er afklaret.

- De nødvendige ressourcer er tilgængelige.

- Aftaler med partnere er afklaret.

- Kundens ressourceindsats og ansvar er afklaret.

- Afleveringsforhold er afklaret.

- Ændringsforhold er afklaret.

Kritisk vurdering af tilbud

Når tilbuddet er udarbejdet, skal der ske en vurdering af, om tilbuddet skal af- sendes. Denne afgørelse bør træffes på baggrund af en kritisk vurdering af tilbuddet, der omfatter en vurdering af relationer til eventuelle partnere, kon- traktlige forhold, pris, økonomi og risici, blandt andet vedrørende:

• Aftaler med underleverandører.

• Anvendelse af kendt standardkontrakt.

• Tilbudsgaranti.

• Omkostninger og pris.

• Betalingsplan.

• Kendskab til den foreslåede teknologi.

• Økonomisk risiko i tilfælde af misligholdelse.

• Offentlig interesse omkring projektet.

2.5. Vurdering af tilbud (kunde)

Arbejdet med vurderingen bør foregå efter en på forhånd lagt plan og tage ud- gangspunkt i de krav, man har beskrevet i udbudsmaterialet. Den fremtidige kontraktansvarlige og den fremtidige projektansvarlige bør være udpeget og deltage i vurderingen af tilbuddene.

Præsentation af tilbud

Det er rimeligt i forbindelse med tilbudsvurderingen at give leverandørerne mulighed for på et møde mundtligt at præsentere tilbuddene. Man bør - ud fra lighedsprincippet - lægge nogle tidsmæssige rammer for disse møder, så til- budsgiverne behandles i rimelig grad ens. Det kan være nyttigt, at man har haft tid til en foreløbig gennemlæsning, så man ved samme lejlighed kan få opklaret småproblemer ved læsningen; men møderne bør ikke udvikle sig til "diskussio- ner". Det er præsentation af tilbud, ikke forhandling. Adgangen til, at tilbudsgi-

xxxxx efterfølgende kan fremsende supplerende oplysninger, skal holdes i me- get kort snor.

Årsagen til denne restriktive politik er, at tilbud skal være sammenlignelige. Hvis et tilbud reelt modificeres under forløbet baseret på supplerende oplys- ninger, kompromitteres sammenligneligheden. Hertil kommer, at en ikke-valgt tilbudsgiver senere vil kunne hævde, at han - hvis han havde fået de samme oplysninger, uanset hvor små detaljer der reelt er tale om - ville have kunnet give et langt bedre tilbud. For tilbud indhentet i henhold til EU's regler vil afvi- gelse fra en meget restriktiv politik give formelle problemer.

Referencebesøg

Det kan ofte være en god idé at gennemføre referencebesøg efter aftale med tilbudsgiverne.

Vurdering af alle aspekter

Det er vigtigt, at konklusionen baseres på en samlet vurdering. Der kan opstå det problem, at nogle af de medarbejdere, der deltager i vurderingsarbejdet, og som skal belyse bestemte aspekter, finder grund til meget bestemt at mene, at et bestemt tilbud er "klart" det bedste, hvilket kan være fuldstændigt rigtigt ud fra de kriterier, som den pågældende ser på.

Det kan anbefales, at anvende vurderingskriterierne fra udbudsmaterialet syste- matisk i selve vurderingsprocessen. Man kan lade forskellige personer eller arbejdsgrupper behandle de enkelte aspekter og aflevere en skriftlig indstilling. Når man har sørget for, at alle aspekter er belyst, kan man foretage den samlede vurdering. På den måde bliver såvel vurderingen af de enkelte aspekter som den samlede afvejning eksplicit, og det kan gøre det lettere at håndtere de interesse- konflikter, som ofte vil forekomme.

Forhandling af kontrakt

Når man har valgt det tilbud, man mener er det bedste, kan det være en god idé ikke at låse sig fast, før kontrakten er underskrevet. Der kunne vise sig proble- mer - og den tilbudsgiver, man forhandler med, må godt mærke konkurrencens kolde vind.

Der ses eksempler på, at man har valgt at gennemføre den forberedende kon- traktforhandling med to tilbudsgivere parallelt. Det er en meget tidskrævende og besværlig fremgangsmåde, som kun bør vælges, hvis der er meget tungtve- jende grunde hertil.

Når spidskandidaten er udpeget - og leverandørvalget formentlig er truffet - bør meddelelse herom gå til alle tilbudsgivere. Forsøg på hemmelighedskræmmeri i denne fase vil kun give besvær.

Næste kapitel giver vejledning i udformning af kontrakten. Har man gennem- ført arbejdet indtil dette punkt ordentlig og metodisk, bør selve arbejdet med kontraktudformningen kun bestå i redigering samt planlægning af leverance- forløbet, se afsnittet om "leveranceplan".

Ud over det rent praktiske i at minimere arbejdet med udformning af kontrak- ten, skal man - hvis man arbejder efter EU's regler - være opmærksom på et formelt problem. For at sikre ens behandling af alle tilbudsgivere lægges der i EU's regler stor vægt på, at det, som blev udbudt, er det samme, som der indgås kontrakt om at levere. Der har været forsøg på at drive denne argumentation så langt, at der slet ikke måtte "forhandles", men at det eneste, der måtte mangle, når tilbuddet forelå og var valgt, var selve underskriften. I praksis er denne fremgangsmåde ikke anvendelig. Der kan være specifikke forhold og alternati- ve forslag fra leverandørens side, som må behandles nærmere. Formelt er det tilladt at føre drøftelser med "teknisk afklaring". Reelt er udbudsmateriale og

tilbud sjældent så præcise, at en drøftelse af afklarende karakter helt kan eller bør undgås4.

Resultat

Tilbuddene er vurderet og prioriteret. Kontraktforhandlinger kan startes med spidskandidaten.

Når den endelige beslutning er truffet, og kontrakten er underskrevet, bør man meddele dette til de øvrige tilbudsgivere. For offentlige udbydere er der også krav i EU's direktiver om, at beslutningen skal offentliggøres.

4 Forbuddet mod forhandling af tilbud er formuleret som grundprincip nummer 8 i [Indkøb]-bind 1 og forklaret nærmere på side 68-70 og 176-177.

3. Kontrakten

Dette kapitel giver råd og vejledning i selve kontraktskrivningen med udgangs- punkt i statens standardkontrakter K18 og K33 samt Euromethod's principper for udformning af leveranceplaner. Kontrakten består af en kombination af kundens udbudsmateriale (opgavebeskrivelse) og leverandørens tilbud (løs- ningsforslag) med de aftalte ændringer og tilføjelser.

Indledningsvis vil vi introducere nogle af de juridiske begreber og tankebaner, som er grundlæggende ved arbejdet med kontrakter for edb-projekter. Dette er kontraktens omgivelser. Dernæst præsenterer vi Euromethod's principper for udformning af leveranceplaner, og vi giver råd om, hvorledes ansvars- fordelingen mellem kunde og leverandør skal fastlægges i kontrakten. Til sidst giver vi vejledning i redigering af kontrakten, herunder brugen af K18 og K33.

3.1. Kontraktens omgivelser

En kontrakt dokumenterer en aftale. Udgangspunktet for at indgå en aftale er, at begge parter kan opnå en fordel herved. Dette skal afspejle sig i kontrakten. Set fra kundens side skal kontrakten indeholde krav til IS-tilpasningen, som sikrer den største nytteværdi af investeringen. Leverandørens synspunkt er, at kontrakten skal indeholde krav til IS-tilpasningen, som sikrer et forretnings- mæssigt udbytte af projektet. En kontrakt skal derfor indeholde en sådan ba- lance mellem kunde- og leverandørinteresser, at leverancerne ikke unødigt for- dyres og besværliggøres for parterne.

En aftale, der ikke er forstået af begge parter, er ikke en aftale. Ingen kontrakt er bedre end brugernes forståelse af den. Det drejer sig ikke om, via smarte formuleringer og juridiske spidsfindigheder, at spille sig kort i hænde til et ret- ligt efterspil. Det skaber kun besvær på langt sigt at skrive "smartheder" i kon- trakten. En kontrakt skal svare til det aftalte og forståede.

En kontrakt fungerer inden for en samfundsmæssig praksis, der er udtrykt i aftaleretten. Aftaleretten består dels af nogle love, dels af en århundredgammel tradition.

Det grundlæggende princip i aftaleretten er, at indgåede aftaler skal holdes5. Dette princip modificeres og suppleres i en række situationer:

• Man må ikke fuppe andre ind i klart urimelige aftaler. Sådanne aftaler kan ophæves af en domstol.

• Hvis man ikke kan overholde sin del af en aftale, skal man holde sin mod- part skadesløs. Men man har også en ret til at søge at afhjælpe skaden, og modparten skal loyalt søge at begrænse skaden.

• Leverandøren kan være "lovlig undskyldt", hvis en leverance ikke kan gen- nemføres på grund af, at køberen har forsømt at etablere aftalte forud- sætninger for leverancen. I så fald siges køberen at være kommet i "for- dringshavermora" og kan blive gjort ansvarlig for ekstra-omkostninger, som denne situation påfører leverandøren.

• Hvis parterne intet har aftalt om en situation, hersker der ikke retsløshed, hvis situationen alligevel opstår. Retspraksis udfylder aftalen.

Hvis der opstår uenighed om aftalens indhold eller fortolkning - eller om an- vendelse af generelle retsprincipper - i en given situation, kan parterne indled- ningsvis forsøge at løse problemerne som beskrevet i afsnit 4.4 (eskalering). Er

5 Danske Lov fra 1683, som stadig er gældende ret i Danmark og Norge, formulerer i ka- pitel 5.1.1 princippet således: "Een hver er pligtig at efterkomme hvis hand med Mund, Xxxxx og Xxxx, lovet og indgaaet haver."

der fortsat uenighed, kan sagen afgøres ved voldgift eller domstol. Ofte inde- holder standardkontrakterne en bestemmelse om, at hver af parterne kan for- lange, at sagen afgøres ved voldgift - sædvanligvis uden appelmulighed. Så- fremt aftalen indgås mellem parter i forskellige lande skal det eksplicit aftales, efter hvilken lovgivning og domstolssystem sagen skal afgøres. Som regel skal en dansk køber sikre sig, at sagen skal behandles ved en dansk domstol og efter dansk ret.

3.2. Leveranceplan

Leveranceplanen er kernen i kontrakten. Leveranceplanen skal beskrive opga- ven, strategien og beslutningspunkterne. En disposition for en leveranceplan er vist i figur 3.

Opgaven karakteriseres ved start- og slutsituationen. Strategien er den over- ordnede fremgangsmåde, der benyttes i edb-projektet. Beslutningspunkterne angiver de tidspunkter, hvor væsentlige delleverancer skal godkendes, og hvor kunden eventuelt skal vælge mellem alternativer.

Leveranceplanen bør kunne sammenstykkes ud fra udbudsmaterialet og tilbud- det. Arbejdet under kontraktskrivningen består i at redigere og præcisere de foreliggende tekster. Det anbefales at lade leveranceplanen være et bilag til kontrakten. I kontrakten skal det klart anføres, at leveranceplanen er en del af aftalen mellem parterne.

Euromethod anbefaler at leveranceplanen skal fastlægges ud fra en projekt- strategi, og at leveranceplanen skal fokusere på beslutninger og leverancer. Hensigten er, at kunden skal have kontrol over alle væsentlige beslutninger un- der gennemførelsen af projektet.

1. Beskrivelse af opgavesituation

1.1. Udgangspunkt: Starttilstand

1.2. Mål: Sluttilstand

1.3. Vurdering af opgavesituation 2. Projektstrategi

2.1. Ændring af forhold i situationen

2.2. Strategi for udvikling

(beskrivelse, konstruktion og indførelse)

2.3. Strategi for projektstyring

3. Beslutningspunkter med tidsplan.

Figur 3: Indhold i en leveranceplan (Euromethod).

Beskriv opgavesituation

Råd:

• Beskriv starttilstanden og sluttilstanden systematisk.

• Vurder risikofyldte forhold i opgavesituationen.

Erfaringsmæssigt bliver især starttilstanden for en kontrakt beskrevet for løst. Det er imidlertid vigtigt at klargøre grundlaget for projektgruppens arbejde. Det vil effektivisere projektarbejdet, blandt andet ved at forebygge misforståelser

undervejs i projektforløbet. Figur 4 giver en generel oversigt over de elementer i start- og sluttilstandene, der skal beskrives:

• Informationssystemet i drift og beskrivelser af dette.

• Beskrivelser af et fremtidigt informationssystem.

• Udstyr, programmel, håndbøger og lignende, der er klar til at blive taget i brug.

• Planer for fremtidige tilpasninger af informationssystemet.

Planer for fremtidige

IS-tilpasninger

Planer for

IS-tilpasning:

• Leveranceplan

• Projektplaner

IS-beskrivelser af et fremtidigt informations- system

IS-beskrivelser af et fremtidigt informations- system

IS-beskrivelser af det færdige informations- system

IS-beskrivelser af det oprindelige informations- system

Starttilstand i IS-tilpasning Sluttilstand i IS-tilpasning

Det oprindelige informations- system:

• Informations- ressource

• Processer

• Aktører

- Edb- system

Krav til

IS-tilpasning

IS-tilpasning

• Gennemførelse

• Afslutning

Det færdige informations- system:

• Informations- ressource

• Processer

• Aktører

- Edb- system

IS-leverancer endnu ikke taget i brug:

• Udstyr

• Programmel

• Håndbøger

IS-leverancer endnu ikke taget i brug

Figur 4: Start- og sluttilstande i en kontrakt (Euromethod).

Efter afklaring af start- og sluttilstande skal følgende spørgsmål besvares:

• Hvilke andre forhold i situationen har væsentlig betydning for udformning af projektstrategi og sekvensen af beslutningspunkter?

De risikofyldte forhold i situationen, for eksempel vedrørende stabilitet i krav og omgivelser, projektets økonomiske og tidsmæssige rammer samt projekt- gruppens ydeevne, skal vurderes. Euromethod indeholder skemaer med for- hold, der kan bruges som checklister ved denne vurdering. De mest betydnings- fulde forhold skal fremhæves, og den samlede kompleksitet og usikkerhed i opgavesituationen skal vurderes. Det skal vurderes, om der er risiko for et uhen- sigtsmæssigt projektforløb, for eksempel:

• Mangelfuld styring af projektforløbet: forsinkelser, dårlig kvalitet.

• Uforudsigelige eller stigende omkostninger.

• Usikkerhed omkring grænseflader til andre systemer.

• Løbende ændringer af krav til projektet.

• Uhensigtsmæssigt informationssystem.

• Det nye system accepteres ikke af brugerne.

De mest kritiske risici skal identificeres ud fra en vurdering af sandsynligheden for et uhensigtsmæssigt projektforløb samt konsekvenserne af det uhensigts- mæssige forløb. De forhold i situationen, der vil være de væsentligste årsager,

skal ligeledes afklares. Dette er grundlaget for at udforme en situationsbestemt projektstrategi og en sekvens af beslutningspunkter.

Nogle standardkontrakter - herunder K18 og K33 - lægger op til at løse pro- blemet ved per definition at gøre leverandøren ansvarlig for alle risici. I pro- jekter af blot nogen kompleksitet er en sådan strategi uanvendelig. For det før- ste giver den i praksis ikke det nødvendige styringsgrundlag. For det andet gi- ver den heller ikke nogen juridisk sikkerhed. Hvis der reelt er usikkerheds- momenter, som leverandøren senere vil kunne påstå burde have været oplyst, eller leverandøren kan påstå, køberen burde have gjort noget ved, har man blot placeret sig i den udefinerede situation, godt kontraktarbejde skal afværge. For at forberede en effektiv projektstyring, skal man nøje sørge for at få de kritiske forhold i situationen klarlagt så tidligt som overhovedet muligt, så parterne kan blive eksplicit enige om, hvordan de skal håndteres.

Fastlæg projektstrategi

Råd:

• Fastlæg en projektstrategi, der tager højde for projektets kompleksitet og usikkerhed, det vil sige brug en situationsbestemt og risikostyret frem- gangsmåde.

• Fastlæg en særskilt strategi for indførelse.

Xxxxxx har allerede truffet et antal strategiske beslutninger forud for udbuds- forretningen. Leverandøren har også overvejet, hvordan opgaven skal gribes an. Disse strategier skal nu flettes sammen til en fælles fremgangsmåde i edb- projektet.

Projektstrategien omfatter beslutninger om fremgangsmåden ved indførelse, konstruktion, beskrivelse og projektstyring. Figur 5 viser de afgørende pro- jektstrategiske valg.

Euromethod giver en række tommelfingerregler for valg af generelle strategier:

• Strategi for indførelse:

- Anvend alt-i-én indførelse når tidsrammen er normal og opgave- situationen hverken er kompleks eller usikker. En alt-i-én indførelse kræver færre beslutningspunkter og er lettere at planlægge og styre.

- Anvend en stykvis indførelse når opgavesituationen er kompleks, men ikke usikker. Brug opdelingen i delsystemer til at mindske komplek- siteten i hver enkelt indførelse.

- Anvend en versionsvis indførelse når opgavesituationen er usikker. Brug opdelingen i systemversioner til at mindske usikkerheden i hver enkelt indførelse.

- Anvend en trinvis geografisk indførelse til at håndtere kompleksitet i opgavesituationen skabt af for eksempel et stort anvendelsesområde, en høj grad af distribution eller kompleks teknologi i anvendelsesom- rådet.

• Strategi for konstruktion:

- Anvend alt-i-én, stykvis eller versionsvis konstruktion efter de samme tommelfingerregler som ved valg af strategi for indførelse.

Der er følgende afhængigheder mellem strategi for indførelse og strategi for konstruktion:

- Alt-i-én indførelse og stykvis indførelse kan kombineres med alle strategier for konstruktion.

- Versionsvis indførelse forudsætter en versionsvis konstruktion, idet de- sign kan ændres ud fra erfaringer fra brug af tidligere system- versioner.

• Strategi for beskrivelse:

- Anvend analytisk arbejdsform når opgavesituationen hovedsagelig er kompleks.

- Anvend eksperimentel arbejdsform når opgavesituationen hoved- sagelig er usikker.

- Anvend primært en ekspertstyret samarbejdsform når der er:

° Store interesseforskelle blandt aktører.

° En stram tidsramme.

° Begrænsede kvalifikationer hos aktørerne.

- Anvend primært en deltagerstyret samarbejdsform når der er:

° En negativ holdning hos aktører.

° Tilstrækkelige kvalifikationer hos aktører.

° Stor usikkerhed og kompleksitet omkring information og forretningsprocesser.

° Stor usikkerhed om krav til edb-systemet.

° Stor betydning af organisatoriske og teknologiske forandringer.

Projektstrategi	Projektstrategiske valgmuligheder
Strategi for indførelse	1. Alt-i-én indførelse: hele systemet indføres på én gang. 2. Stykvis indførelse: delsystemer indføres et ad gangen. Krav og specifikationer er fastfrosset før indførelse af første delsystem. 3. Versionsvis indførelse: systemversioner indføres en ad gangen. Krav og specifikationer kan ændres ud fra erfaringer fra brug af foregående versioner. Geografisk omfang: 1. Total indførelse. 2. Trinvis indførelse.
Strategi for konstruktion	1. Alt-i-én konstruktion: hele systemet accepttestes på én gang. 2. Stykvis konstruktion: delsystemer accepttestes et ad gangen. Krav og specifikationer er fastfrosset før konstruktion af første delsystem. 3. Versionsvis konstruktion: systemversioner accepttestes en ad gangen. Krav og specifikationer kan ændres ud fra erfaringer med foregående versioner.
Strategi for beskrivelse	Arbejdsform: 1. Analytisk: brug af abstraktioner og specifikationer. 2. Eksperimentel: brug af eksperimenter og prototyper. Samarbejdsform: 1. Ekspertstyret: gennemførelse og vurdering er adskilt. 2. Deltagerstyret: gennemførelse og vurdering udføres i fællesskab.
Strategi for projektstyring	Systemudviklingsstyring: A. Hyppighed: ofte eller sjældent. B. Formaliseringsgrad: formelt eller uformelt. C. Kundeansvar: defineret/ej-defineret. Kvalitetsstyring: De samme muligheder som under systemudviklingsstyring. Konfigurationsstyring De samme muligheder som under systemudviklingsstyring.

Figur 5: Projektstrategiske valgmuligheder (Euromethod).

• Strategi for projektstyring:

- Anvend tæt opfølgning på systemudviklingen (hyppighed = ofte) når opgavesituationen er usikker, specielt når tids- og økonomirammen er stram, de organisatoriske forandringer har stor betydning eller kvali- teten af de eksisterende beskrivelser er dårlig.

- Anvend altid formel kvalitetsstyring, for eksempel i form af reviews.

Procedurerne omkring kvalitetsstyring kan være mere eller mindre komplekse afhængig af projektets størrelse og betydning.

- Definer altid kundens ansvar i projektforløbet, især vedrørende:

° Håndtering af konflikter og holdninger hos aktører.

° Gennemførelse af organisatoriske forandringer.

° Tilførsel af viden samt beslutningstagning.

° Konfigurationsstyring af krav til edb-projektet.

Generelt er leverandøren ansvarlig for alt vedrørende projektstyring med mindre andet er aftalt.

Eksempler på specifikke strategiske valg i forhold til kompleksitet og usikker- hed i situationen:

• Kompleksitet:

- Hvis anvendelsesområdet er stort, så bør det deles op i mindre områ- der, og projektet kan eventuelt deles op i en række mindre projekter.

- Hvis der er mange grænseflader til andre systemer (stor kompleksitet af funktioner), så bør disse grænseflader afklares tidligt i projektforlø- bet, og grænsefladerne bør testes omhyggeligt så tidligt som muligt.

- Hvis konverteringen er kompleks, så bør konverteringen deles op i trin med midlertidige grænseflader mellem nye og gamle systemer. Det vil sige, at strategien for indførelse skal enten være stykvis eller versions- vis.

• Usikkerhed:

- Hvis der er en risiko for mange løbende ændringer af krav til edb- systemet, så bør der i design og konstruktion sættes fokus på fleksibi- liteten af edb-systemet. Vedligeholdelsesmuligheder og udvidelses- muligheder bør indgå som kvalitetskriterier.

- Hvis der er en risiko for uforudsigelige omkostninger, så bør de første beslutningspunkter omfatte stillingtagen til estimater af omkostninger.

Standardkontrakterne K18 og K33 forudsætter en alt-i-én strategi for kon- struktion og indførelse. Det vil sige, at et valg af andre strategier vil kræve til- pasning af standardkontrakterne. Generelt er K18 og K33 ikke indrettet til at understøtte faseopdelte leverancer.

Fastlæg beslutningspunkter

Råd:

• Fastlæg en strategibestemt sekvens af beslutningspunkter.

• Fastlæg beslutningspunkter med leverancer i bestemte tilstande.

Strategien bestemmer arten og rækkefølgen af beslutningspunkter. Er der for eksempel valgt en alt-i-én strategi, så er der stort set kun en vigtig beslutning, og det er at godkende løsningen. Er der derimod en mere trinvis og eksperimentel strategi, så er der lagt op til en lang række beslutninger. Euromethod giver en række tommelfingerregler for, hvordan man vælger beslutningspunkter ud fra en projektstrategi for indførelse, konstruktion, beskrivelse og projektstyring:

• Indførelse og konstruktion:

Afhængigt af de valgte strategier bliver følgende beslutningspunkter væ- sentlige:

- Alt-i-én strategi:

° Godkendelse af testet informationssystem.

° Godkendelse af indført informationssystem.

- Stykvis strategi:

For hvert delsystem:

° Godkendelse af testet delsystem.

° Godkendelse af indført delsystem.

Efterfulgt af en samlet godkendelse af det nye system.

- Versionsvis strategi: For hver systemversion:

° Godkendelse af teknisk design af systemversionen.

° Godkendelse af testet systemversion.

° Godkendelse af indført systemversion.

Efterfulgt af en samlet godkendelse af det nye system.

I alle tilfælde er det vigtigt at aftale proceduren for behandling af fejlrap- porter i forbindelser med kundens test af systemleverancer. Hvornår er ret- telse af 'fejl' omfattet er kontrakten, og hvornår skal det betragtes som en tillægsydelse, for eksempel på grund af ændring af kravene?

• Beskrivelse:

- Når strategien for beskrivelse er analytisk og ekspertstyret, skal se- kvensen af beslutningspunkter fastlægges ud fra følgende principper:

° Først beslutninger om udformning af arbejdsprocesser, dernæst beslutninger om udformning af edb-systemet.

° Først beslutninger om den abstrakte udformning af systemerne, dernæst beslutninger om den konkrete udformning.

° Først beslutninger om den totale løsning, dernæst beslutninger om delløsninger.

° Planlæg med et minimum antal beslutningspunkter.

- Når strategien for beskrivelse er eksperimentel og deltagerstyret, skal sekvensen af beslutningspunkter fastlægges ud fra følgende princip- per:

° Tag beslutninger om udformning af arbejdsprocesser parallelt med beslutninger om udformning af edb-systemet.

° Træf beslutninger om den konkrete udformning af systemerne, som grundlag for beslutning om den abstrakte udformning.

° Tag beslutninger om den totale løsning parallelt med beslutninger om delløsninger.

° Planlæg med beslutningspunkter, der er tilstrækkelige til at understøtte et tæt kunde-leverandør samspil.

• Projektstyring:

Beslutninger om processen træffes som regel sammen med nogle af oven- nævnte beslutninger om anvendelsesområdet. Indholdet i statusrapporter og planer skal være bestemt af den valgte strategi for projektstyring.

Beskriv beslutninger

Når de enkelte beslutningspunkter er fastlagt, skal det beskrives, hvad de om- fatter. Det vil sige, hvilke leverancer der skal foreligge, og hvilke typer beslut- ninger, der skal træffes.

Leverancerne til de enkelte beslutningspunkter skal indeholde den rette in- formation som grundlag for at tage de nødvendige beslutninger, men ikke mere end det. Det koster at producere for meget information, og det vil be- sværliggøre beslutningstagningen.

Grundlæggende kan der træffes to slags beslutninger: Beslutninger vedrørende projektområdet og beslutninger vedrørende anvendelsesområdet.

Beslutninger vedrørende projektområdet drejer sig om at styre fremdriften af projektet og eventuelt om at ændre kontrakten. De forudsætter især leverancer

af projektrelaterede dokumenter: Statusrapport og ændringsforslag til kontrakt, herunder ændringsforslag til leveranceplan.

Beslutninger vedrørende anvendelsesområdet kan deles i tre typer: investerings- beslutninger, designbeslutninger og systemgodkendelse. Euromethod giver følgende karakteristik af leverancer, der understøtter de tre typer af beslutnin- ger:

• Investeringsbeslutninger:

En investeringsbeslutning fastlægger ambitionsniveauet i systemløsningen: omfanget af funktionalitet i et system og om et system skal udvikles eller ej. Hele projektet er igangsat af en principiel investeringsbeslutning. Den indledende investeringsbeslutning kan revideres på basis af mere viden fra projektarbejdet. Grundlaget for investeringsbeslutninger skal indeholde vurderinger af for eksempel: muligheder (herunder design af systemet), nytteværdi, omkostninger, risici, leveranceplan.

• Designbeslutninger:

En designbeslutning godkender eller udvælger en beskrivelse af et system, som skal realiseres. Grundlaget for designbeslutninger er beskrivelser af edb-systemet og brugerorganisationen.

• Systemgodkendelse:

Denne beslutning skal baseres på et testet eller indført informationssystem, men bør også bygge på rapporter om for eksempel den gennemførte kva- litetsstyring og konfigurationsstyring.

De seks perspektiver på informationssystemet, der er skitseret i figur 6, kan un- derstøtte en karakterisering af det nødvendige grundlag for investerings- og designbeslutninger.

Det skal understreges, at denne måde at karakterisere systembeskrivelser på er nødvendig, men ikke tilstrækkelig. Hvis kravspecifikationer og designdoku- menter udgør en væsentlig del af en leverance, skal de beskrives mere detaljeret i leveranceplanen. Deres indhold skal karakteriseres i forhold til den aktuelle opgave. Dokumenternes form kan beskrives ved henvisning til en doku- mentstandard.

Informations- ressource

Informationssystem

bruger

Processer

er et syn på

er et syn på

Informationssystem perspektiver

Forretningsproces- perspektiv

repræsenterer den automati- serede del af

Edb-system perspektiver

Edb-data- perspektiv

Informations- perspektiv

Edb-funktions- perspektiv

udfører bruger

Aktører

Edb-arkitektur- perspektiv

Arbejdsproces- perspektiv

er et syn på

understøtter eller erstatter

Edb-system

er et syn på strukturen af

repræsenterer implementering og distribution af

Figur 6: Seks perspektiver for beskrivelse af informationssystemet (Euromet- hod).

Euromethod indeholder lister med de systemegenskaber, der sættes fokus på i de forskellige perspektiver. Disse systemegenskaber kan bruges til at karakteri-

sere indholdet i leverancer. Derudover anbefaler Euromethod, at leverancer, der består af beskrivelser, karakteriseres med hensyn til:

• Kvalitet,

for eksempel vedrørende reviews før levering.

• Detaljeringsgrad,

for eksempel vedrørende graden af dekomponering og specialisering i be- skrivelserne.

• Omfang,

for eksempel vedrørende de dele af systemet, der beskrives.

• Formalisering,

for eksempel vedrørende brug af diagrammeringsteknikker.

Euromethod giver følgende tommelfingerregler for planlægning af indholdet i grundlaget for beslutninger:

• Når beslutninger drejer sig om forandringer i forretningsprocesser, så bør grundlaget omfatte informations- og forretningsproces-perspektiverne.

Ud fra disse perspektiver beskrives organisationens informationsressource og forretningsprocesser uafhængigt af, hvorledes arbejdet udføres. Dette kan for eksempel gøres ved hjælp af objektorienterede modellerings- teknikker, entitets-relationsteknikker og business-process-reenginee- ringsteknikker.

• Når beslutninger drejer sig om forandringer i arbejdsprocesser, herunder anvendelse af edb og menneske-maskin grænseflader, så bør grundlaget omfatte arbejdsproces-perspektivet.

Ud fra arbejdsproces-perspektivet beskrives, hvorledes arbejdet udføres, herunder hvad edb-systemet udfører, og hvorledes menneske-maskin grænsefladen er udformet. Dette kan for eksempel gøres ved hjælp af or- ganisationsdiagrammer, work-flow beskrivelsesteknikker, skærm- og rap- portlayoutbeskrivelser samt prototyper til afprøvning af menneske-maskin dialoger.

• Når beslutninger drejer sig om de data, der skal automatiseres, så bør grundlaget omfatte edb-data-perspektivet.

Ud fra edb-data-perspektivet beskrives den del af informationsressourcen, der er automatiseret, uafhængigt af hvilken datamaskine dataene er lagret på. Dette kan for eksempel gøres ved hjælp af objektorienterede teknikker og entitets-relationsteknikker.

• Når beslutninger drejer sig om de funktioner, der skal automatiseres, så bør grundlaget omfatte edb-funktions-perspektivet.

Ud fra edb-funktions-perspektivet beskrives de arbejdsfunktioner, der er automatiseret, uafhængigt af hvilken datamaskine funktionerne udføres på. Herunder beskrives den opdeling af edb-funktionerne, der giver det bedste overblik og den letteste vedligeholdelse. Dette kan for eksempel gøres ved hjælp af data-flow diagrammeringsteknikker.

• Når beslutninger drejer sig om edb-systemets tekniske udformning, så bør grundlaget omfatte edb-arkitektur-perspektivet.

Ud fra edb-arkitektur-perspektivet beskrives den fysiske struktur af edb- systemet, for eksempel opdelingen i client og server datamaskiner samt datakommunikationens udformning. Herunder beskrives den opdeling af edb-data og edb-funktioner, der giver den mest effektive og sikre afvikling af edb-systemet. Dette kan for eksempel gøres ved hjælp af maskin- konfigurationsdiagrammer samt data- og funktionsstrukturdiagrammer.

3.3 Ansvarsfordeling

Kontrakten skal - eventuelt i et bilag - definere projektorganisationen i form af roller for grupper og personer. Euromethod anbefaler, at man definerer to grupper, som vist i figur 7: En styregruppe og en projektgruppe. Hermed op-

deles ansvaret for styringen af edb-projektet i to niveauer af samspil mellem kunden og leverandøren.

IS-tilpasning

Krav

Kontrakt- niveau (Styre- gruppe)

Opfyldelse af krav

Kunde

Formål Vilkår

Leverandør

Information

Produkter

Ydelser

Projekt- niveau (Projekt- gruppe)

Færdigheder

Viden

Figur 7: To niveauer af kunde-leverandør samspil (Euromethod).

Styregruppen forvalter rammerne for projektet. Den træffer beslutninger om godkendelse af leverancer og ændringer af kontrakten. Projektgruppen udfører arbejdet. Den træffer beslutninger inden for kontraktens rammer. Euromethod definerer forskellige roller, som vist i figur 8. De primære roller er kunden og leverandøren. Begge disse udpeger personer som henholdsvis projekt- og kon- traktansvarlig.

Kunde kontrakt- ansvarlig

Transaktioner

Leverandør kontrakt- ansvarlig

Understøtter

Kunde projekt- ansvarlig

Understøtter

Leverandør projekt- ansvarlig

Figur 8: Nøgleroller i IS-tilpasningsprojekter (Euromethod)

3.4. Redigering af kontrakt

Med beskrivelsen af leveranceplanen og projektorganisationen indeholder kon- trakten de væsentligste aftaler. Hertil skal tilføjes aftaler om et antal andre for- hold. Disse aftaler kan ofte med fordel indføjes i de strukturer, som udgøres af

leveranceplanen og projektorganisationen. I andre tilfælde kan aftalerne beskri- ves ved en særskilt paragraf eller et kontraktbilag.

I det følgende kommenteres brugen af standardkontrakterne K18 og K33 inden for nogle udvalgte aspekter, som ofte viser sig at give vanskeligheder i praksis.6

Afleveringsforretning

En afleveringsforretning skal godtgøre, at det leverede lever op til aftalen. Afle- veringsforretningen omfatter de vigtigste beslutningspunkter i normal kon- traktstyring.

K18 har en detaljeret opskrift på en afleveringsforretning for en totalleverance. Denne omfatter tre faser: En overtagelsesprøve, hvor funktionaliteten kontrol- leres; en driftsprøve, hvor kapacitet og pålidelighed kontrolleres; og en garanti- periode, inden for hvilken fejl og mangler kan kræves rettet.

I forhold til denne opskrift kan der ud fra Euromethod's filosofi gøres tre be- mærkninger. For det første, at der er fuld enighed om betydningen af afleve- ringsforretningen. For det andet, at beskrivelsen af afleveringsforretningen vil passe fint ind i en leveranceplan. For det tredje, at hvis der ikke, som forudsat i K18, er tale om en totalleverance, er K18's opskrift uanvendelig. I de tilfælde - og det vil sige, når leverancen er en del af et samlet system eller er et dokument, som beskriver et kommende system - skal leverancen selvfølgelig også kontrol- leres; men her må benyttes andre metoder, såsom reviews og tests.

Totalleverandørrollen

Allerede under udformningen af edb-strategien forud for udbudsforretningen skal kunden vælge, om der ønskes en totalleverandør. Fordelen herved er især, at kontraktstyringen forenkles. Ulempen er, at kunden afskæres fra en lang række trinvise og parallelle forløb, som kan være at foretrække, når opgaven indebærer mere end en minimal risiko. Såvel K18 som K33 lægger klart op til en totalleverandørrolle. K33 giver plads til en hvis faseopdeling af det indle- dende arbejde, men begge kontrakter forudsætter en samlet leverance.

Ved opdeling af opgaven på flere leverandører har kunden et større reelt ansvar for den samlede koordinering, såvel teknisk som i forhold til styringen af kon- trakterne. Hertil kommer, at man ikke uden videre kan anvende K18 og K33. Man må selv sørge for at udbygge kontrakten med de nødvendige tilføjelser.

Opgavebeskrivelse og tekniske specifikationer

K18 giver opgavebeskrivelsen i udbudsmaterialet første rang over leverandørens tilbud. Tankegangen er, at leverandøren naturligvis skal levere det specificerede; men at dette ikke ændrer ved, at den udbudte opgave skal løses. Dette sikrer kunden mod, at der i de tekniske beskrivelser af løsningen tilføjes ting, som er svære at forstå eller overskue, og som fratager leverandøren for en del af ansva- ret i forhold til at løse den udbudte opgave.

Dette udmærkede princip kan opretholdes gennem brug af en disciplineret stil i leveranceplanen, hvorved først og fremmest opgaven, karakteriseret ved start- og sluttilstanden, beskrives.

En udbygning af dette princip er, at det er vigtigt at anføre, hvor opgave- beskrivelsen helt eller delvis ikke opfyldes med nøjagtig angivelse af, hvad der ikke opfyldes.

6 Beskrivelsen af standardkontrakterne i [K18] og [K33] indeholder kommentarer, som giver en vejledning i brug af kontrakterne. Betegnelserne "K18" og "K33" stammer fra antallet af sider i kontrakterne: K18 er efterfølgeren for K17, som var på 17 sider, og K33 er i originaludgaven på 33 sider.

Derudover indeholder [FM] en vejledning specifikt rettet mod opgaver, der hovedsage- ligt omfatter drift af edb-systemer.

Sikring mod tvangssituationer

K18 lægger op til at sikre kundens adgang til at øge kapaciteten gennem aftale om bestemte priser ved senere køb af supplerende udstyr. Dette kan være rele- vant, når der er tale om meget specielt udstyr. Hvis der derimod er tale om stan- dardudstyr, for hvilket der findes et marked, er sådanne aftaler overflødige. Dette gælder i særdeleshed, når priserne på markedet er faldende.

Sikring af kontraktens status

K18 lægger op til, at der skal føres en ændringsliste over ændringer til kon- trakten. Dette er en naturlig aktivitet i kontraktstyring.

Eksisterende systemer og infrastruktur

K18 lægger op til, at det er leverandørens ansvar at integrere eksisterende sy- stemer og infrastruktur i løsningen. Dette er en yderligere udbygning af prin- cippet om en totalleverandør. Et princip, der som nævnt ovenfor kun har be- grænset anvendelighed.

Kundens forpligtelser

Bortset fra enkelte punkter nævner K18 ikke kundens forpligtelser; men de eksisterer alligevel. I forbindelse med hver eneste leverance vil kunden have forpligtelser til at levere information og til at deltage i afleveringskontrollen. For at skabe en fælles og klar forståelse af projektets forudsætninger bør kun- dens forpligtelser beskrives. Ligeledes bør konsekvenserne af kundens mislig- holdelse fastlægges.

Vedligeholdelse og nye versioner

K18 giver leverandøren en forpligtelse til at vedligeholde det leverede i 7 år. Samtidigt skal kunden tilbydes nye versioner af standardprogrammel; men kunden kan nægte at købe de nye versioner.

Det er K18's forslag, at kunden skal kunne kræve at få vedligeholdt gamle ver- sioner. Dette er ikke altid hensigtsmæssigt. Dels er det dyrt for en leverandør at opretholde et beredskab i forhold til gamle versioner, dels gør kunden ofte sig selv en bjørnetjeneste ved at sakke agterud i forhold til den tekniske udvikling - på et eller andet tidspunkt skal man jo tage et så meget større versionsskift. I stedet kan man aftale, at leverandøren skal give mindst 1 års varsel før vedlige- holdelsen af en bestemt version ophører.

Standardprogrammel

I K18 betragtes alt programmel som ens, og leverandøren - i sin egenskab af totalleverandør - pålægges ansvaret for sine underleverandørers produkter, her- under standardprogrammel. Det er imidlertid absurd at forestille sig standard- programmel rettet i en enkelt installation. I praksis rettes det i form af nye relea- ses og versioner. Det der realistisk kan aftales er "hot-line adgang", det vil sige, at leverandøren stiller eksperter til rådighed for kunden, som kan afhjælpe pro- blemer med standardprogrammel.

Tider

Det skal understreges, at der skal aftales leveringstidspunkt for alle leverancer i leveranceplanen.

Priser

Kontrakten skal indeholde aftale om tider, forudsætninger og rater for betaling.

Standardkontrakt K33

K33 er på nogle punkter anderledes end K18. Det meste afspejler, at den er ældre. Den principielle forskel er, at K33 dækker projekter med udviklings- arbejde, medens K18 hovedsageligt omhandler standardiserede produkter. Men

K33 har ligesom K18 den væsentlige begrænsning, at den forudsætter en total- leverandør og en samlet leverance.

4. Kontrakten som styringsværktøj

En kontrakt indeholder en plan med angivelse af en serie handlinger, der skal udføres. Denne plan skal klart angive, hvem af kontraktens parter der har ansva- ret for de enkelte handlinger. Kontrakten skal have nogle bestemmelser om, hvilke reaktioner den ene part kan gribe til, hvis den anden part ikke gen- nemfører sine handlinger.

Kontraktens karakter af plan betyder, at arbejdet med at følge op på en kontrakt grundlæggende er det samme som at følge op på en plan. Parterne skal sikre sig, at planen holdes - og såfremt der måtte opstå grundlag for at ændre planen, skal de gennemføre konsekvensændringer, så de til stadighed har en plan, de faktisk kan arbejde efter.

Det er en ofte anvendt talemåde, at en kontrakt, når den endelig er færdigfor- handlet, helst skal ligge i skuffen og blive dér. Denne talemåde henter sin logik fra, at der ofte i kontraktudformninger er stor fokus på de ubehageligheder, parterne kan pådrage hinanden, hvis en part ikke lever op til sine forpligtelser. Ved at fokusere på misligholdelsen skabes en stemning af mistænkeliggørelse, som man i det praktiske arbejde kan have god grund til at lægge så langt ned i skuffen som muligt.

Men selvom man - for at befordre det gode samarbejde - ønsker at lægge mis- ligholdelsesaspekterne så langt væk som muligt, så står tilbage, at kontrakten er en plan - og som sådan et helt afgørende grundlag for det praktiske arbejde.

En anden udbredt misforståelse er, at en kontrakt er en plan, der ikke kan æn- dres og justeres - at der automatisk foreligger "misligholdelse" og dermed "juri- diske ubehageligheder", hvis planen ikke følges 100%. Men kontrakten har ikke større autoritet, end de to parter giver den. Hvis parterne er enige om at justere planen, så kan parterne til enhver tid gøre det.

Dette kapitel handler om, hvordan parterne bruger kontrakten aktivt som grundlag for styringen, og herunder sørger for, at eventuelle aftaler om ju- steringer dokumenteres, så der ikke på et senere tidspunkt opstår usikkerhed om, hvad det faktisk er for en plan, parterne arbejder efter.

4.1. Etablering af projektorganisation

Som nævnt i afsnit 3.3 og illustreret med figur 7 og 8, anbefaler Euromethod en bestemt rollefordeling, som giver et godt grundlag for projektstyringen. Det skal beskrives, hvordan disse roller kan udøves under styringen af arbejdet med at realisere kontrakten.

Opdeling i styregruppe og projektgruppe

Det anbefales, at organisationen består af to led, en styregruppe og en projekt- gruppe.

Den afgørende årsag til denne anbefaling er, at de ledelsesmæssigt og økono- misk-juridisk ansvarlige (styregruppen) skal kunne udføre deres hverv med et minimum af tidsforbrug. Samtidig giver det de praktisk udførende en klar ramme for at udføre dette arbejde uden unødig indblanding fra "højere sted". Det drejer sig altså om at økonomisere med styringsressourcerne og skabe størst mulig effektivitet i arbejdet. Denne model kan også anvendes i forbindelse med løsning af konfliktsituationer.

Styregruppen

Styregruppens opgave er at forestå den overordnede ledelse af projektet, herun- der træffe beslutning vedrørende:

• Godkendelse af leverancer, herunder beslutninger om valg af alternativer.

• Ændringer af leveranceplan.

Herudover er det styregruppens opgave at overvåge projektets forløb.

Styregruppen består af den kunde-kontraktansvarlige og den leverandør-kon- traktansvarlige. Det kan aftales, at yderligere personer fra såvel kunde- som leverandørside deltager i styregruppens møder.

Enhver beslutning i projektet, som har karakter af fortolkning eller justering af den indgåede kontrakt, træffes af styregruppen.

Styregruppen fastsætter en "forretningsorden". Den kan for eksempel udformes som skitseret i figur 9.

Projektgruppen

Projektgruppens opgave er at gennemføre projektet inden for de rammer, som er givet med kontrakten og styregruppens beslutninger. Projektgruppen har endvidere til opgave at udarbejde forslag til styregruppens beslutninger samt at udarbejde det materiale, som styregruppen ønsker.

Projektgruppen udarbejder en projektplan med angivelse af de aktiviteter, der skal gennemføres. Denne projektplan skal tage udgangspunkt i leverance- planen. Denne projektplan kan løbende detaljeres og justeres.

Etablering

Det kan anbefales, at styregruppen på sit første møde bruger god tid til at drøfte sin arbejdsform og sin rolle, og herunder supplerer forretningsordenen.

Projektplanen

Projektplanen er en detaljering af leveranceplanen. Projektplanen er arbejds- planen for projektgruppen, og den skal således ikke forelægges styregruppen.

Projektplanen bør struktureres kronologisk, så beslutningspunkterne beskrives i den rækkefølge, de skal indtræffe.

Intervallet mellem to beslutningspunkter kaldes en fase. Faser beskrives ved de aktiviteter, de består af. For hver aktivitet skal beskrives, hvem der udfører den, hvordan den i hovedtræk udføres, hvornår den udføres, og hvad den resulterer

i. Det kan give en god oversigt at opsummere alle parters forpligtelser i hver fase.

Beslutningspunkterne bør være beskrevet ved leverancerne i leveranceplanen. Beskrivelserne kan eventuelt detaljeres. Det skal bemærkes, at kontrolaktivite- terne knyttet til hver leverance skal indgå i den forudgående fase. En tidsfrist er altså ikke overholdt ved, at der afleveres et utestet program.

Mødefrekvens	Som udgangspunkt holder styregruppen møde hver måned (tidspunkt), første gang den (dato). Såfremt en af parterne ønsker det, kan der herudover afholdes supplerende møder. Såfremt kunden har begæret supplerende møde afholdt, er leverandøren berettiget til at fakturere medgået tid og di- rekte omkostninger (for eksempel rejser) for den le- verandør-kontraktansvarlige, såfremt andet ikke er aftalt.
Mødereferat	Der udarbejdes et beslutningsreferat fra styregruppens mø- der. Dette referat udarbejdes af den leverandør-kontraktan- svarlige. Referatet skal sædvanligvis foreligge 3 arbejdsdage efter mødets afholdelse, og eventuelle indvendinger skal sædvanligvis meddeles skriftligt inden for yderligere 5 ar- bejdsdage. Endelig godkendelse af referat foretages på ef- terfølgende møde.
Deltagere	Styregruppen består af den kunde-kontraktansvarlige og den leverandør-kontraktansvarlige. Den kunde-kontrakt- ansvarlige leder som styregruppens formand møderne. I styregruppens møder deltager endvidere den kunde-pro- jektansvarlige og den leverandør-projektansvarlige. Hver part har ret til at medtage yderligere en person, hvis sag- kundskab vedkommende part anser for væsentlig for styre- gruppens arbejde.
Sted	Møderne holdes hos kunden.
Materiale til møderne	Xxx møderne foreligger en dagsorden og en statusrapport fra projektgruppen. Denne rapport indeholder: • status i henhold til leveranceplan • vurdering af problemer og risici, • redegørelse for forhold, som projektgruppen ikke har kunnet nå til enighed om, for eksempel beslutninger om ambitionsniveau, • forslag til beslutninger vedrørende leveranceplanen, • forslag til tiltag, som projektgruppen anbefaler iværk- sat.

Figur 9: Eksempel på forretningsorden for en styregruppe.

4.2. Hændelser vedrørende anvendelsesområdet

Styregruppens kontraktstyring udløses af to typer hændelser vedrørende hen- holdsvis projektområdet og anvendelsesområdet. En projektområdehændelse har ikke umiddelbart noget at gøre med indholdet i de aftalte leverancer, men kan for eksempel være en forsinkelse i arbejdet. Anvendelsesområdehændelser drejer sig om leverancerne. Disse hændelser kræver beslutninger af forskellig type. De beslutninger, som vedrører anvendelsesområdet, er godkendelse af leverancer, beslutning om nye eller ændrede projekter og stillingtagen til de- signforslag.

Gennemførelse af en beslutning

Styregruppen - og det vil i denne sammenhæng sige kundesiden - skal have rimelig tid til at gennemføre sin evaluering, ofte baseret på projektgruppens indstilling. Det skal imidlertid noteres, at styregruppen ikke kan give sig ube- grænset god tid til denne proces, da en manglende beslutning skaber vanskelig- heder for det videre arbejde. Derfor skal der aftales tidsmæssige rammer for beslutningsprocessen.

De beslutninger, en styregruppe typisk kan træffe, er:

1. Godkendelse af leverance,

idet den tilfredsstiller de stillede forventninger, eller idet eventuelle mangler er uden praktisk betydning.

2. Accept af leverance med mangler,

med krav om, at de nærmere angivne mangler udbedres.

3. Forkastelse af leverance,

idet den indeholder mangler af væsentlig betydning for det videre arbejde.

4. Investeringsbeslutning.

Beslutning om at igangsætte arbejde, som kræver en selvstændig ny kon- trakt.

5. Designbeslutning.

Beslutning om valg af en bestemt løsning, som derefter bliver retnings- givende for det efterfølgende arbejde.

6. Ændre kontrakt,

eller rettere tage skridt til ændring af kontrakten.

Det skal bemærkes, at der er en glidende overgang mellem disse beslutnings- typer. Man kan for eksempel lave sådanne kontraktændringer, at det reelt en investeringsbeslutning, eller man kan lade en designbeslutning fremstå som en accept med en mangelliste. Hensigten med denne klassificering af beslutninger er ikke lægge bånd på styregruppens adfærd. Den kan beslutte, hvad den vil, inden for det mandat medlemmerne har med hjemmefra. Hensigten med at tale om de forskellige beslutningstyper er at skærpe opmærksomheden om de for- udsætninger og den adfærd, hver beslutning kræver.

I det følgende vil de enkelte beslutningsmuligheder blive kommenteret.

1. Godkendelse af leverance

Denne beslutning skulle gerne være den normale og enkleste at administrere. Ved denne beslutning tager kunden et væsentligt medansvar for den pågælden- de leverance. Dette udelukker dog ikke, at kunden senere kan påberåbe sig mangler ved leverancen og kræve udbedrende handlinger eller reduktion i pris gennemført.

Det anbefales derfor, at der inden en godkendelse gennemføres en grundig evaluering. Senere konstaterede mangler vil ofte være sværere at håndtere i projektet. Heri ligger ikke en anbefaling til at ofre uvæsentlige detaljer stor opmærksomhed - men til at være omhyggelig med at afklare, om der er reelle problemer.

2. Accept af leverance med mangler

Konstateres det under evalueringen, at der faktisk er reelle mangler, må der skelnes mellem væsentlige og uvæsentlige mangler.

En væsentlig mangel er defineret som en mangel, der forhindrer, at leverancen kan bruges efter sit formål.

Ved uvæsentlige mangler anbefales (som generel retningslinie), at leverancen accepteres. Det er styregruppens opgave at nå til enighed om, hvilke punkter der med rette indgår i mangellisten.

En evaluering kan ofte give anledning til, at der afdækkes elementer, som kun- dens repræsentanter mener bør omfattes af leverancen, uanset om disse punkter indgår i den karakteristik af leverancen, som indgår i leveranceplanen og aftale- grundlaget. Det kan ofte være uoverskueligt for en bruger - eller anden sag- kyndig - at gennemføre evalueringen strengt i forhold til kontrakten. Ofte vil en bruger vurdere leverancen intuitivt ud fra egne forventninger og forståelse af anvendelsessituationen.

Det anbefales, at evalueringen tilrettelægges, så der i første omgang ikke skelnes nøje mellem mangler i kontraktens forstand og de intuitivt opfattede mangler. Begge typer af information kan være nyttig, og det vil ofte være hensigtsmæs- sigt, at de personer, der indgår i evalueringen, alene forholder sig til "sagens indhold", medens styregruppen må afklare det kontraktuelle spørgsmål.

I forbindelse med "accept med mangler" kan der indgås to principielt forskelli- ge aftaler, nemlig en suppleringsleverance og en reduktion af prisen.

For det første kan der aftales en suppleringsleverance. Det mest almindelige er, at der udarbejdes en mangelliste, og at der indgås en aftale om supplerings- leverancen. Denne aftale om suppleringsleverance skal indeholde en klar defi- nition af leverancens indhold, tid og sted for levering samt kriterier for godken- delse. Endvidere skal leveranceplanen ajourføres.

Det anbefales, at en sådan suppleringsleverance - hvor det er muligt - håndteres isoleret, således at den kan leveres og godkendes, såfremt den opfylder de fast- lagte kriterier. I nogle tilfælde er det dog i praksis nødvendigt at foretage en ny, samlet evaluering af den oprindelige leverance7.

I princippet kan også en suppleringsleverance accepteres med mangler - men man bør være opmærksom på den styringsmæssige kompleksitet, der derved kan opstå. Som hovedregel anbefales det, at der foretages en samlet godkendel- se af en suppleringsleverance.

For det andet kan der aftales en reduktion af pris. Styregruppen kan beslutte, at de konstaterede mangler ikke skal udbedres. Det kan ud fra en samlet vurdering af situationen være bedre at reducere projektets omfang svarende til en eller flere af de konstaterede mangler, hvorefter der aftales en tilsvarende reduktion af prisen.

Sædvanligvis kan kunden ikke ensidigt forlange denne løsning anvendt. Leve- randøren bør have en vis mulighed for udbedring. Men parterne kan i forståelse og gensidig interesse aftale en sådan løsning.

3. Forkastelse af en leverance

En leverance kan forkastes, hvis den indeholder væsentlige mangler i forhold til leveranceplanen.

I forbindelse med en sådan forkastelse skal der i styregruppen indgås aftale om, hvornår fornyet leverance skal gennemføres. Dermed ajourføres leverance- planen.

7 Dette er ikke ensbetydende med, at beslutningen dermed er defineret som en forkastelse. Forskellen har blandt andet betydning for, om der kan gøres misligholdelsesbeføjelser gældende under påberåbelse af forsinkelse.

4. Investeringsbeslutning

En investeringsbeslutning er beslutning om iværksættelse af et nyt projekt, der på sigt skal resultere i et forbedret informationssystem. En investerings- beslutning kræver en afvejning af fordele og omkostninger og indebærer normalt en prioritering af flere mulige investeringer.

En investeringsbeslutning kræver oplæg, der beskriver både fordele og ulemper ved det givne forslag. Et sådant oplæg kan være en foranalyserapport. Investeringsbeslutninger kan også træffes på et mere udførligt grundlag, for eksempel på grundlag af et designdokument og et tilhørende estimat. Det er også en investeringsbeslutning at beslutte at afbryde et udviklingsforløb, fordi vurderingen af fordele og ulemper har ændret sig.

Investeringsbeslutninger træffes af kunden alene. Men der er grund til at nævne dem i denne sammenhæng for at advare mod, at en kunde og en leverandør i en godt samarbejdet styregruppe reelt træffer investeringsbeslutninger i fællesskab, idet de dermed sætter markedsmekanismen ud af kraft.

5. Designbeslutning

En designbeslutning er et valg mellem alternative løsninger. En designbeslut- ning kan være forudset i leveranceplanen. Hvis der eksempelvis er usikkerhed om en i øvrigt attraktiv løsnings gennemførlighed, kan det aftales, at der hurtigt udføres eksperimenter for at afklare spørgsmålet, og hvis svaret er negativt, kan man falde tilbage på en mere sikker løsning. En designbeslutning kan også være uforudset. Hvis der for eksempel viser sig at være inkonsistens i de specificerede krav, kan det være nødvendigt, at styregruppen skærer igennem.

En designbeslutning kræver oplæg, der beskriver alternativer og deres system- mæssige og økonomiske konsekvenser. En designbeslutning indebærer ofte en justering af leveranceplanen.

6. Ændre kontrakt

Endelig kan styregruppen beslutte at ændre kontrakten. Denne beslutning er normalt udløst af en hændelse i projektområdet, og derfor vil vi diskutere den i det næste afsnit.

4.3. Hændelser vedrørende projektområdet

Edb-projekter er kendetegnet ved stor usikkerhed. Derfor skal der skabes og opretholdes et beredskab til at håndtere uforudsete situationer. En styregruppe, der er velinformeret om projektet, og som er parat til at ændre aftaler for at få det bedste ud af situationen, er en væsentlig del af dette beredskab.

Forudsætningerne for et projekt kan grundlæggende ændres på to måder. Den ene måde er, at kundens krav ikke længere afspejler brugernes reelle situation og ønsker. Den anden er, at der opstår tvivl om det mulige i at gennemføre projektet til tiden. Begge situationer kræver beslutninger i styregruppen.

Ændringer i kundens forhold

Som nævnt er opgavesituationen og projektstrategien en del af leveranceplanen og som sådan en del af kontrakten. Der kan imidlertid ske ændringer i opgavesituationen - som igen kan føre til en revurdering af projektstrategien. Opgavesituationen kan for eksempel ændres ved, at kunden omstrukturerer sin virksomhed, eller ved organisationsændringer.

Kunden kan derfor fremsætte ønske om ændringer i systemindhold og leveranceplan. Initiativet til en ændring kan også komme fra leverandøren, der forelagt en ændret opgavesituation kan anbefale ændringer. I begge tilfælde skal styregruppen træffe beslutning om ændringerne.

Forsinkelser

Ved forsinkelse af projektet vil der ofte foreligge misligholdelse fra leve- randørens side, og kontrakten vil indeholde bestemmelser om kundens beføjel- ser i den situation.

Der kan imidlertid også opstå den situation, at der rejses tvivl om mulighederne for at gennemføre projektet.

Denne tvivl kan skyldes aktuelle svigt fra leverandørens side eller begivenheder, som giver anledning til påstand om anticiperet misligholdelse, eksempelvis i forbindelse med leverandørens betalingsstandsning eller andre drastiske begivenheder.

Men tvivlen kan også skyldes projekt-problemer, som ikke på denne enkle måde kan lastet den ene part og give anledning til veldefinerede, juridiske handlinger. Som eksempel kan anføres længere tids sygdom hos nøglepersoner i projektet. Også i disse tilfælde er det styregruppens ansvar at træffe forholdsregler.

Kontrol af projektforløbet

Den organisatoriske opdeling i styregruppe og projektgruppe indebærer, at styregruppen skal føre kontrol med projektarbejdet. Dette er en vigtig og van- skelig aktivitet.

Vanskelighederne må ikke undervurderes. Det er nemt nok at sige, at "styregruppen løbende skal informeres om alle væsentlige forhold". Hvis den slags floskler overhovedet har nogen effekt er det, at styregruppen dænges til med ligegyldig information. Effektiv kontrol består i at stille de rigtige spørgs- mål og i at foretage de rigtige kontrolhandlinger.

Effektiv kontrol forudsætter stor indsigt i edb-projekter. Ved større kontrakter bør en mindre erfaren kunde hyre sine egne eksperter som kontrollanter, på samme måde som en bygherre har en rådgivende ingeniør til at kontrollere entreprenøren.

Projektkontrol skal ikke udføres "løbende", idet projekters tilstand ikke meningsfuldt lader sig måle på vilkårlige tidspunkter. Projektkontrol skal udføres i forbindelse med beslutningspunkter. Ønskes en intens kontrol, må man lægge beslutningspunkterne tættere, hvilket indebærer, at antallet af delleverancer forøges. Kontrol er bestemt ikke gratis.

Ved et beslutningspunkt skal projektet levere en statusrapport, der udtaler sig om:

• Forbrugte ressourcer.

Dette forhold er nemt at kontrollere.

• Fremdrift.

Dette kan kun dokumenteres ved test- og reviewrapporter. Er der ikke af- holdt formelle vurderinger af resultatet, er udsagn om fremdrift reelt udo- kumenterede, med mindre styregruppemedlemmerne selv kan vurdere de foreliggende resultater.

• Muligheden for at gennemføre projektet til tiden.

Dette skal dokumenteres ved et aktuelt estimat. Foreligger der ikke et re- view af estimatet, er udsagn om projektets fremtid i princippet udokumen- terede.

Man skal være opmærksom på, at projektansvaret ofte er leverandørens alene, og at projektkontrollen derfor ikke hører hjemme i den fælles styregruppe. På den anden side kan kundens ratebetalinger være afhængig af etablerede mel- lemresultater i projektet. I så fald skal kunden udøve en vis kontrol. Hertil kommer, at kunden i vigtige projekter har en naturlig interesse i at kontrollere leverandørens arbejde. Dette skal da aftales og afspejles i leveranceplanen.

4.4. Håndtering af konflikter

Når et projekt løber ind i et problem - en særlig teknisk vanskelighed eller blot en forsinkelse - bringes leverandørens projektansvarlige ofte i en position som den "skyldige" med hvad deraf følger af psykologiske reaktioner: dårlig stem- ning, forsvarsposition og lignende. På den ene side vil kunden naturligvis for- vente, at den projektansvarlige tager problemet alvorligt og tager det på sig per- sonligt. På den anden side har hverken kunden eller projektet noget at bruge dårlig stemning og skyldfølelse til. Faktisk er det en nøgle i al ledelse - herun- der projektledelse - at få "professionaliseret" dette sæt af menneskelige og emo- tionelle reaktionsmønstre. I den forbindelse må kontrakten aldrig bruges som en trussel. Kontrakten skal kunne bruges til at "objektivisere" mulige konflikt- situationer. Den er en beskrivelse af de regler, man anvender - i fællesskab - når en given type af situation opstår.

En uenighed er ikke en konflikt

Situationen kan kompliceres af, at der ikke blot foreligger et problem, men også hersker uenighed om, hvori problemet består. Der er naturligvis fra begge sider væsentlige interesser på spil, så motivationen til at opfatte problemet på lidt for- skellig måde kan være nærliggende. Alligevel anbefales det, at man gør meget for at undgå dette komplicerende element. Så længe man har en fælles opfattel- se af de faktiske forhold, har man gode muligheder for at holde situationen under kontrol.

Og selv når man må konstatere, at parterne notorisk har afvigende opfattelse af de faktiske forhold, må det anbefales, at man forsøger at indkapsle problemet: altså være enige om, hvad man er uenige om. Så kan man aftale at lade det spørgsmål afgøre af andre for eksempel ved eskalering: man pakker et problem sammen og sender det "opad". Typisk vil de projektansvarlige sende et problem op til behandling i styregruppen.

Det er en ofte anvendt praksis at give kundens og leverandørens projektansvar- lige beføjelser til at beslutte alt, hvad de kan blive enige om inden for kontrak- tens rammer, så de kun bringer uenigheder til afgørelse i styregruppen. Men uenigheder skal behandles udramatisk i styregruppen. Ellers vil problemerne blive gjort unødvendigt konfliktfulde og derved komplicerede at løse.

Begrænsning af konfliktområde

Det er vigtigt at begrænse et specifikt problem, så det ikke smitter sunde dele af et projekt. Hvis leverandøren for eksempel inden for et område leverer noget, der er ringere end det burde være, og kunden i øvrigt kan leve med det, som det er, så bør der vælges en løsning, der hedder forholdsmæssigt nedslag i prisen. Hvis der ikke kan laves en hurtig aftale om nedslagets størrelse, så stop ved den vigtige beslutning: valg af forholdsmæssig nedslag i prisen som straf, og overlad fastsættelse af beløbet til andre. Det er en teknisk detalje, som ikke haster, og som man kan få nogen til at tage sig af ved lejlighed.

Brug kontrakten til at navigere med, også - og netop - når der er problemer.

Lad være med at putte kontrakten af vejen og så "finde ud af det".

4.5. Projektafslutning

Et projekt skal afsluttes, så både kunde og leverandør kan få frigjort deres udviklingsressourcer til nye opgaver. Projektafslutning forudsætter en kon- struktiv indstilling fra alle parter. Der er to væsentlige elementer i en vellykket afslutning: En endelig mangelliste og en forvaltningsorganisation.

Mangelliste

Når alle leverancer er accepteret med mangler (eller er godkendt), udgør mang- lerne alt, hvad der udestår i projektet. Der kan ikke tilføjes flere mangler, og en mangel kan ikke byttes med en anden mangel.

Parterne skal nu nidkært søge at udrydde manglerne, enten gennem udviklings- arbejde eller ved at aftale kompensation.

At mangellisten er endelig ændrer ikke ved garantibestemmelserne. Senere op- dukkede fejl og mangler skal rettes i henhold til aftalen; men det skal ske i for- valtningsorganisationen ikke i projektet. Det samme gælder ændringsønsker.

Forvaltningsorganisation

Der skal være nogen at overdrage systemet til ved projektafslutningen. På kun- dens side kan det være et brugerservicecenter, en superbruger eller en driftsaf- deling. På leverandørens side kan det være en vedligeholdelsesafdeling.

Kundens organisation skal have et budget til mindre ændringer.

5. Litteraturliste

[Indkøb] Offentlige indkøb i praksis - Internationale og nationale udbudsregler, bind 1: Brugervejledning, bind 2: Regelsamling.

Statens Indkøb 1993.

Dette er "bibelen" for offentlige indkøbere samt en værdifuld vejledning for private indkøbere. Vejledningen giver et overblik over relevante regler, blandt andet EU-direktiver. Den tager desuden udgangspunkt i og forklarer nogle grundlæggende indkøbsprincipper, som bruges i praksis. I vejledningen lægges der vægt på, at reglerne bruges i overensstemmelse med de bagvedliggende forudsætninger.

I et særskilt kapitel behandles nogle forhold, som har særlig betydning i for- bindelse med indkøb af edb. Det understreges, at der ved edb-indkøb er behov for en meget detaljeret kravspecifikation med udgangspunkt i standarder, der er godkendt i EU. Generelt anbefales det at bruge ekstern konsulentbistand ved udarbejdelse af udbudsmateriale og vurdering af tilbud eller at benytte sig af allerede etablerede edb-rammekontrakter. Desuden anbefales det, at edb- standardkontrakt K18 bruges som kontraktgrundlag ved indkøb af standardise- rede edb-systemer. Der henvises til, at edb-standardkontrakt K33 med visse begrænsninger (som ikke præciseres) kan anvendes ved indkøb af specialud- viklet programmel.

[K18] K18 - Statens standardkontrakt for standardiserede edb-systemer.

Statens Indkøb 1992.

Standardkontrakt K18 har som formål at fastsætte vilkår ved anskaffelse af edb- systemer, der ikke i større omfang kræver specialudviklet eller tilrettet program- mel.

Standardkontrakten er suppleret med vejledende kommentarer til hvert afsnit i kontrakten. Det understreges dog, at det ikke er en udtømmende vejledning i udformningen af det samlede udbudsmateriale. Det anbefales, at standard- kontrakten vedlægges udbudsmaterialet, således at den enkelte tilbudsgiver kan få lejlighed til at fremsætte forbehold til de kontraktmæssige vilkår.

[K33] Statens standardkontrakt for edb-totalleverancer - Samtidig anskaffelse af maskinel, special- og standardudviklet programmel.

Administrationsdepartementet 1987.

Denne standardkontrakts anvendelsesområde er skræddersyede og nøgle- færdige edb-systemer, herunder vedligeholdelse. Det understreges, at kontrak- ten skal betragtes som et forhandlingsoplæg, som ikke uden ændringer kan anvendes i forbindelse med prototypeudvikling eller faseopdelte edb- anskaffelser.

[Standard] Edb-køb i EF - Nyttig viden om edb-standarder, direktiver og andre EF- beslutninger.

Xxxx Xxxxxxxx, Kommunedatas Forlag 1991.

Bogen beskriver de forskellige typer standarder, der har relevans vedrørende kommunikation og flytbarhed. Bogen indeholder eksempler, der illustrerer, hvorledes et kommunalt behov suppleres med henvisninger til standarder. Der gives desuden en vejledning i udarbejdelse af en strategi for overgang til stan- dardiserede løsninger. Det er et EU-krav, at enhver myndighed, der ønsker at fortsætte med ikke-standardiserede indkøb, skal kunne begrunde hvorfor samt præstere en strategi for en senere overgang til den standardiserede verden.

[FM] Facility management - Vejledning om udbud og udlicitering af statens IT- opgaver,

Forskningsministeriet 1995.

Vejledningen er et supplement til Finansministeriets generelle vejledning om udbud og udlicitering: "Udlicitering - effektivisering gennem konkurrence" fra

1992. Forudsætningerne for en nyttig anvendelse af facility management skitse- res, og der gives vejledning i gennemførelse af udbudsforretning, etablering af kontrakt samt opfølgning på kontrakten. Der henvises til vejledningen i [Ind- køb] samt til bestemmelserne i [K18] og [K33]. Derudover gives en checkliste for specielle kontraktbestemmelser for blandt andet specificering af leverandø- rens ydelser med hensyn til drift af kundens installation, test og installering af nyt programmel, teknisk optimering, konfigurationsstyring, sikkerhed med mere.