8. Udvikling og vedligeholdelse
Forside - Indhold - Forrige/ Næste
"Vejledning - Kontrakter om komplekse it-ydelser"
Nærværende kapitel er baseret på, at kunden lægger hele sin løbende vedligeholdelse og udvikling ud til én leverandør, dog selvfølgelig med respekt af EU-udbudsdirektiverne. Kapitlet prætenderer ikke at beskrive alle aspekter, der skal dækkes af en udviklingskontrakt, men de mest centrale emner, som kan strukturere en sådan kontrakt, er medtaget.
Kunden har typisk nogle individuelt udviklede applikationer, der løbende skal vedligeholdelse og videreudvikles. Hertil kan komme udvikling af nye applikationer, som eventuel har en tæt sammenhæng med de øvrige allerede eksisterende applikationer. Det kan være, at det er kundens egen udviklingsafdeling, der hidtil har forestået såvel vedligeholdelse som udviklingen. Det kan ligeledes være, at opgaverne er blevet varetaget at henholdsvis kundens egne medarbejdere og nogle leverandører. Endelig kan det være, at disse opgaver hidtil alle sammen har været varetaget af en anden leverandør.
Det er væsentlig at være opmærksom på, at afsnittet omhandler individuelt udviklet programmel for den pågældende kunden, og således ikke standardprogrammel. Vedligeholdelse af standardprogrammel vil typisk være omfattet af leverandørernes standardaftaler på disse områder, og være reguleret ved præcise beskrivelser af omfanget og hyppigheden af vedligeholdelse, samt et årligt fast vederlag herfor.
Det er ikke på samme måde ved individuelt udviklet programmel, herunder programmel der er udviklet af kunden selv eller af tredjepart, muligt at give et fast vederlag blot for vedligeholdelse. Den nye leverandør kan ikke vide, hvor mange fejl, der eventuelt fortsat måtte være i programmellet, eller i hvilket omfang kunden i øvrigt har brug for support i denne sammenhæng. Dertil kommer, at grænsen mellem hvilke opgaver, der er omfattet af vedligeholdelse og hvilke opgaver, der må betragtes som nyudvikling i forhold til programmellet, kan være ganske vanskeligt at drage præcist, for ikke at sige umulig, når der er tale om individuelt udviklet programmel. Dette vil ligeledes have en sammenhæng med, hvilke procedurer kunden hidtil har fulgt i forhold til sin interne udviklingsafdeling, eller en ekstern leverandør, såfremt der skal foretages vedligeholdelse eller udvikling af programmellet. Forslagene til kontraktsmæssige formuleringer nedenfor er baseret på, at det principielt alene er kunden, der styrer, hvilke konkrete opgaver kunden ønsker udført.
Teksterne er opdelt i henholdsvis en vedligeholdelsespulje, en udviklingspulje og udvikling efter tilbud, hvor tilbud tillige kan indhentes af kunden fra tredjemand. Er der tale om en offentlig kunde forudsættes det, at denne outsourcing af udviklingsopgaven, såfremt den overstiger EU-grænsen, har været i udbud. Potentielle leverandører vil konkurrere dels på den timepris, der vil være gældende for det pågældende arbejde, dels på parametre, som vedrører kvalitet, kompetence og produktivitet.
Såfremt kunden undtagelsesvis er i stand til meget præcist at beskrive indholdet af og omfanget af henholdsvis vedligeholdelsen og udviklingen for hele kontraktsperioden, vil det selvfølgelig være muligt tillige at estimere antallet af timer. Dette vil blot meget sjældent være muligt for en kunde, eftersom kunden ikke kan vide, hvilke fejl der stadigvæk måtte være i programmellet, og som ikke er dækket af en leverandørgaranti, og hvorvidt der vil fremkomme lovgivning, som vil medføre ændringer i programmellet. Samtidig kan organisatoriske ændringer udløse ændringer i programmel.
At lade vedligeholdelse og udvikling af kundens individuelt udviklede brugerprogrammel varetage af én leverandør, vil typisk have en effektiviseringsfordel for kunden i form af, at denne leverandør vil opnå kendskab til samtlige af kundens systemer, og dermed kan sikre, at der rettes samtidig på tværs af alle systemerne i det omfang det er relevant, samt at kunden simpelt hen sparer egen tid ved ikke at skulle koordinere flere leverandørers arbejde.
Omvendt vil kunden ved at vælge flere leverandører kunne opretholde konkurrencesituationen og undgå sårbarhed ved at være afhængig af én leverandør. I nogle sammenhænge giver det også kunden særlige muligheder for at vælge leverandører med spidskompetence på de enkelte områder.
Som puljerne er beskrevet nedenfor, er der fastsat en adgang til at regulere puljerne, såfremt kundens behov for bistand viser sig at være større, end det kunden oprindeligt har forventet. Denne reguleringsadgang, der kan være i såvel opad som nedadgående retning, skal, såfremt der er tale om en offentlig kunde, selvfølgelig ske med respekt af EU-udbudsreglerne. EU-udbudsreglerne rummer imidlertid i sig selv også ganske meget fleksibilitet. Tjenesteydelsesdirektivet omtaler udtrykkeligt, at et udbud kan omfatte optioner. Direktivet fortolkes endvidere således, at en udbudspligt kan løftes ved at sende rammeaftaler i udbud. Disse to kontraktformer giver kunden mulighed for at opnå forpligtende tilsagn fra en leverandør om en tjenesteydelse af en nærmere beskrevet kvalitet/enhedspris uden på forhånd at have lagt sig fast på en bestemt mængde. Dertil kommer, at i det omfang de yderligere opgaver, der skal løses, er af en sådan karakter, at det ikke umiddelbart er muligt at lade andre leverandører foretage det, uden at det vil have ekstraordinære store omkostninger, fordi det er nogle ændringer direkte inde i det system som den anden leverandør tager sig af, er der i henhold til EU-reglerne mulighed for at anvende undtagelsesbestemmelser, såfremt disse bestemmelsers krav er opfyldt. Det er inden for disse udbudsretlige rammer, at beskrivelsen af en løsning, der involverer etableringen af puljer til udvikling m. v. skal anskues.
Under såvel vedligeholdelsespuljen som udviklingspuljen er det væsentligt, at kunden beskriver, hvad det er for en type ressourcer, kunden ønsker stillet til rådighed. Dette sker typisk i form af, at kunden oplyser hvilke former for programmel, der skal vedligeholdes eller videreudvikles.
Under udviklingspuljen er som eksempel fastsat, at såfremt det vurderes, at det samlede tidsforbrug for en udviklingsopgave er på over et vist antal timer, er kunden berettiget til at få et tilbud fra leverandøren og indhente et fra en ekstern leverandør. Tallet kan meget vel være et helt andet, men er blot udtryk for, at opgaverne skal op over et vist omfang, før det for kunden kan betale sig at indhentes formelle tilbud blandt flere leverandører. Dertil kommer, at selvom udviklingen måtte være på mere end den fastsatte tærskel, kan det være, at det praktisk talt ikke er muligt for en anden leverandør at varetage opgaven på grund af tekniske sammenhænge.
I tekstforslagene nedenfor er der tillige givet adgang for, at kunden i et puljeår kan overflytte uforbrugte timer fra den ene pulje til den anden pulje. Noget af det meget væsentlige kunden sikrer sig ved disse puljeordninger er, at leverandøren er forpligtet til, uden varsel at have de aftalte puljer til rådighed indenfor de pågældende år. Kunden kan således få iværksat sit arbejde omgående og løbende, indenfor disse pulje.
Reguleringen af puljerne kan f.eks. ske for en 6 måneders periode af gangen. Denne regulering kan som nævnt ovenfor gå i såvel nedad- som opadgående retning.
Det er muligt, at denne reguleringsadgang skal være hyppigere eller skal være sjældnere. Det vil helt afhænge af den enkelte kundens behov, baseret på de programmer kunden har, samt det arbejdsmæssige miljø kunden befinder sig i.
Priserne for reguleringen skal selvfølgelig fremgå af kontraktens bilag indeholdende vederlag.
Opgaverne under puljerne vil typisk omfatte opgaver, hvor kunden "lige skal have udført det og det." Der er således sjældent tale om store og meget detaljerede projekter, der skal gennemføres. Dertil kan komme pludselig opståede hasteopgaver, f .eks. forårsaget af hastelovgivning, der ikke tidsmæssigt muliggøre et udbud, eller det ikke er muligt at overlade opgaven til en anden leverandør.
Som det fremgår af teksten, er der adgang for kunden til at indhente tilbud hos leverandøren, når udviklingsopgaverne er større end et vis antal timer, og i den sammenhæng ligeledes indhente tilbud fra tredjemand, såfremt kunden finder behov for dette. Er det en offentlig kunde og er opgaven omfattet af EU-direktiverne, uden mulighed for at anvende nogle af undtagelsesbestemmelserne, kan kunden selvfølgelig ikke anmode den eksisterende leverandør om at fremkomme med tilbud på opgaven, før der har været afholdt et (yderligere) EU-udbud.
Ligeledes skal kunden være yderst forsigt med at anmode denne leverandør om at bistå i noget af forarbejdet, således at leve randøren ikke bliver inhabil i forhold til et senere EU-udbud. En række kendelser fra Klagenævnet for Udbud viser ganske vist, at udbudsreglerne på dette punkt er mere fleksible end tidligere antaget, og at en leverandør ikke automatisk bliver diskvalificeret af medvirken i forberedelsesfasen. Da det imidlertid er leverandørens risiko, må leverandøren dog have mulighed for at sige nej til at deltage i forberedende opgaver, herunder forhåndstilbudsafgivelse.
Det kan rent faktisk ske, at den eksisterende leverandørs pris er højere, alene fordi han er bekendt med nogle kompleksiteter via sit løbende arbejde for kunden, som en anden tilbudsgiver er ubekendt med. Den eksisterende leverandør har dog i udgangspunktet en vis forpligtelse til loyalt at oplyse kunden om de faktiske tekniske forhold. Dette kan ske uden risiko for inhabilitet. Under alle omstændigheder er det vigtigt for kunden at være opmærksom på, at prisen ikke behøver at være det eneste konkurrenceparameter, og at den tekniske kvalitet af et tilbud derfor kan være udslaggivende. Er den eksisterende leverandør tillige driftsleverandør, eller er der tale om, at opgaven omhandler ændringer i en eksisterende applikation, som den eksisterende leverandør efter 12 måneders vederlagsfri afhjælpningsperiode skal fortsætte vedligeholdelsen af, er det vigtigt, at den eksisterende leverandørs sikkerhedsprocedure, dokumentationsstandard og kvalitetssikring følges. Disse krav skal således tillige tilkendegives overfor den tredjepart, som kunden anmoder om tilbud. Det er muligt, at disse standarder for sikkerhed, dokumentation og kvalitetssikring er fastsat af kunden i det oprindelige udbud af hele udviklingskontrakten. Det er så blot disse procedurer, der skal følges. Det vigtigste er, at det er fuldstændig ensartede procedurer, der følges.
Forestår den eksisterende leverandør tillige driften af kundens systemer, er det væsentligt at få klarlagt procedurerne for indkøringen af ændringerne af programmellet, samt den løbende vedligeholdelse. Indkøringen vil typisk ske af den eksisterende driftsleverandør, idet der af sikkerhedsmæssige årsager ikke gennemføres en indkøring på det anlæg, leverandøren har ansvaret for, af en tredjepart, men af driftsleverandørens driftsfolk. Dog er det som regel nødvendigt, at den nye leverandør bistår den eksisteren de leverandør i indkøringsforløbet. Det kan ligeledes være muligt, at den eksisterende leverandør skal bistå den nye leverandør under udviklingsforløbet, herunder med informationer. Dette skal være nøje aftalt med den eksisterende leverandør og kunden, samt vederlæggelsen herfor, hvilken bistand dog typisk kan fragå i en af puljerne.
Endvidere skal det på forhånd vurderes, hvilken betydning i relation til den eksisterende leverandørs forpligtelser, leverancen fra en anden leverandøren skal have. Dette bør allerede være klarlagt inden en anden leverandør vælges, eftersom der kan være nogle omkostninger for kunden, såfremt udviklingen hos tredjepart vil medføre omkostninger til den eksisterende leverandør eller i øvrigt påvirke den eksisterende leverandørs forpligtelser i henhold til kontrakten. Eksempelvis kan der være tale om, at det programmel, der udvikles, vil medføre øget kapacitetsbehov for kunden hos leverandøren.
Såfremt udbuddet er omfattet af EU's udbudsregler, er det dog udgangspunktet, at kunden ikke kan tage hensyn til sådanne følgeomkostninger, da det kan stride mod ligebehandlingsprincippet at foretage den slags reguleringer af et tilbud.
Kunden skal endvidere tage stilling til, i hvilket den nye leverandør skal forestå fejlrettelse efter de første 12 måneders fejlfri afhjælpning. Det er således et valg om, hvorvidt den eksisterende leverandør skal overtage fejlafhjælpningen i 12 måneder som en del af en vedligeholdelsespulje, eller kunden skal tegne vedligeholdelseskontrakt med den nye leverandør.
Valget vil afhænge af mange forskellige faktorer, herunder hvor integreret det pågældende programmel vil være i det, som den eksisterende leverandør allerede har ansvaret for at vedligeholde. Derudover vil det ligeledes have betydning, i hvilket omfang kunden ved, at der vil være behov for anden form for vedligeholdelse eller videreudvikling i det pågældende programmel. Når flere leverandører arbejder med ændringer til programmellet, skal de være særlig opmærksomme på at undgå at overlappe hinanden henholdsvis at være inkonsekvente i forhold til hinanden. Videre udvikler den eksisterende leverandør på programmellet og en ny leverandør kommer med ændringer til en funktion, som den eksisterende leverandør er i gang med at ændre for kunden, kan det blive et ganske komplekst forløb, og bevirke en såvel tidsmæssig forlængelse af det arbejde den eksisterende leverandør skal udføre, som øget ressourceforbrug, hvilket forøger kundens omkostninger.
Det er nødvendigt ved leverandørens overtagelse af kundens løbende udvikling, at der foretages en "stadeopgørelse" over pågående samt planlagte udviklingsprojekter. Denne indgår i kontraktens bilag 8. En sådan oversigt, i en mindre omfattende udformning, kan tillige være hensigtsmæssig ved leverandørens overtagelse af driftsopgaver, idet leverandøren derved bliver bekendt med hvilke implementeringer, der vil skulle ske indenfor for eksempel de første 12 måneder.
Det skal endvidere fastlægges, om vedligeholdelse og udvikling sker på maskinel, der stilles til rådighed af leverandøren eller af kunden. Ligeledes skal det aftales om test sker på maskinel, der stilles til rådighed af leverandøren eller kunden. Såfremt leverandøren i forvejen forestår drift for kunden, vil driftsmiljøet typisk være delt op i henhold til et udviklings-, vedligeholdelses, test- og produktionsmiljø, således at det hele foregår på dette miljø. Er det en, i forhold til driftsleverandøren, tredjepart, der skal udvikle, vil udviklingen typisk foregå på leverandørens eget maskinel, hvorimod kundetesten vil foregå på kundens sædvanlige driftsanlæg.
Den kontraktsmæssige formulering af disse forhold kan f.eks. være følgende:
- Vedligeholdelse
- Løbende udvikling
- Udvikling efter tilbud
De igangværende udviklingsopgaver og de i perioden fra den ... til den ... planlagte opgaver fremgår af bilag 8.
8.1 Vedligeholdelsespulje
Leverandøren påtager sig at udføre opgaverne omhandlende den løbende daglige opfølgning. Denne opfølgning består af:
- Fejlhåndtering, herunder eventuel fejlrettelse, jf. bilag 8
- Support til kundens superbrugere
- Driftsstøtte
- Databaseadministration
- Opfølgning og diagnosticering af atypiske situationer
- Nødvendige tilpasninger af programmer for at servicemål kan overholdes
Der er afsat en pulje til vedligeholdelse på .... timer pr. år i hele kontraktsperioden.
Typen af vedligeholdelsesressourcer, der stilles til rådighed under puljen er: [beskriv kort fagområderne]
Tidsforbruget dokumenteres på de månedlige statusmøder i henhold til de i bilag 8 angivne specifikationer.
8.2 Udviklingspulje
Leverandøren gennemfører udvikling af alle opgaver inden for kon trakten. [ Kontrakten kan indeholde bestemmelser om kundens adgang til at lade 3. mand udvikle.]
Der er afsat en pulje for gennemførelse af udvikling af disse opgaver på .... timer pr. år i hele kontraktperioden. Disse timer søges fordelt ligeligt over et kalenderår.
Typen af udviklingsressourcer, der stilles til rådighed under puljen er [beskriv kort fagområderne]
Vurderes det, at det samlede tidsforbrug for udvikling af en opgave er É timer, eller derunder, sker udviklingen under denne pulje. Tilsva rende vil tidsforbruget til løsning af ad-hoc prægede opgaver, forana lyse og analyse samt tidsforbruget til andre opgaver, som ikke speci fikt er medtaget i udvikling efter tilbud, blive taget fra denne pulje. Tidsforbruget dokumenteres på de månedlige møder i udviklingssta tusgruppen i henhold til bilag 5.
fortsættes på næste side
|
Elektronisk publikation fremstillet af J.H. Schultz Grafisk A/S efter Forskningsministeriets retningslinier |