Hvad er samarbejdsforpligtelsen, som brugeren, der bestiller systemudvikling, skal bære?

Arbejdet med systemudvikling kræver, jo større systemet der udvikles er, en betydelig mængde arbejdskraft og tid. Derfor pålægges der en vis samarbejdspligt ikke kun for leverandøren, der påtager sig udviklingen, men også for brugeren, der bestiller systemudviklingen.

Dette er forskelligt fra normale køb-og-salg relationer. For eksempel, hvis du beder en skrædder om at lave en skræddersyet dragt, påtager kunden (brugeren), der bestiller, sig ikke nogen “pligt”. Det er udelukkende skrædderen (leverandøren), der påtager sig “pligten”. Det er netop på grund af det store antal mennesker og den tid, der kræves til IT-systemer, at brugeren også skal “samarbejde” med leverandøren.

I denne artikel vil vi forklare, hvilke juridiske forpligtelser der påhviler bestilleren i forbindelse med systemudvikling, som ikke kan overlades udelukkende til leverandøren.

Det er ikke nok bare at ‘overlade det hele’ til andre, når det er dit eget system

Selv i et enkelt systemudviklingsprojekt er der ofte mange mennesker og organisationer involveret. Det er selvfølgelig vigtigt med ingeniører og programmører, der er dygtige til kodning, men for at samle deres output til et enkelt resultat, er projektlederens rolle også afgørende.

Men uanset hvor høj teknisk og organisatorisk kapacitet leverandørsiden har, kan systemudvikling ikke gennemføres udelukkende med leverandørens kræfter. For eksempel, interne termer, der kun bruges inden for virksomheden, eller virksomhedsspecifik forretningsviden, kan ikke kendes gennem envejsindsats fra leverandørsiden alene. Jo større systemudviklingen er, jo mere almindeligt er det, at virksomheden, der bruger systemet, også er en stor virksomhed med mange mennesker og opgaver. For at lede et systemudviklingsprojekt til succes, er det faktisk ofte tilfældet, at organisering af denne type forretningslogik vejer tungere end selve computerarbejdet.

Derfor bør brugersiden ikke være passiv med begrundelsen “Jeg er ikke en IT-ekspert”, men snarere aktivt levere information, hvilket kan gøre projektets forløb mere smidigt. I denne forstand er den rolle, som brugersiden har i et systemudviklingsprojekt, faktisk ikke lille.

Hvad indebærer brugerens samarbejdspligt i lyset af retspraksis?

Så hvad indebærer brugerens samarbejdspligt konkret i et systemudviklingsprojekt? Der er mange hints at finde i tidligere retspraksis om dette emne.

I retssager har det været et stridspunkt, om brugeren (sagsøgeren) har en samarbejdspligt i udviklingen, når leverandøren (sagsøgte) er forsinket med leveringen, og der har været forsinkelser i brugerens beslutningstagning. I denne sag fastslog retten, at brugeren havde overtrådt sin samarbejdspligt, og afviste leverandørens ansvar for manglende opfyldelse af forpligtelser. (Selvom kontraktens ophævelse blev anerkendt, blev der også anerkendt en 60% fejlfordeling.)

I denne sag om udvikling af et computersystem, som er en såkaldt skræddersyet systemudviklingskontrakt, kan leverandøren ikke fuldføre systemet alene, og det er nødvendigt, at brugeren, i udviklingsprocessen, koordinerer interne meninger præcist, forener synspunkter, klart formidler til leverandøren, hvilke funktioner der ønskes, overvejer de ønskede funktioner sammen med leverandøren, endeligt bestemmer funktionerne, yderligere, bestemmer skærmbilleder og rapporter, og deler rollen med at acceptere det færdige produkt.

Tokyo District Court, March 10, 2004 (Heisei 16)

Denne dom er meget tankevækkende, ikke kun fordi den angiver, at systemudvikling i sig selv er et samarbejde med brugeren, men også fordi den angiver “hvilke specifikke punkter der skal samarbejdes om”.

Lad os prøve at oversætte ordlyden i ovenstående dom til IT-udtryk, der bruges i systemudvikling.

Disse kan alle organiseres på denne måde. Uanset hvor avanceret ekspertise man har i IT-systemer, kan disse ikke gøres alene uden brugerens samarbejde. Det er grundlæggende brugeren, der skal klargøre, hvilke funktioner og hvilket skærmlayout der ønskes, og kun brugeren kan bekræfte, om det, der er blevet bedt om, er blevet realiseret.

Desuden, ligesom leverandøren har en projektledelsespligt, har brugeren også en samarbejdspligt. Hvis brugeren overtræder sin samarbejdspligt i ovenstående processer, kan det tænkes, at leverandøren omvendt kan kræve erstatning for manglende opfyldelse af forpligtelser eller ulovlige handlinger fra brugeren.

Hvordan håndteres anmodninger om ændringer i specifikationer efterfølgende?

Hvis vi antager, at systemudviklingsprojekter er et fælles arbejde mellem brugeren og leverandøren, vil diskussionen udvikle sig til mere avancerede emner. Et sådant emne er spørgsmålet om, “hvem er ansvarlig, hvis brugeren anmoder om tilføjelser eller ændringer efterfølgende, hvilket gør det svært at overholde tidsfristen?”

Systemudvikling sigter generelt mod at undgå tilbageskridt så meget som muligt ved at følge en rækkefølge, der starter med kravspecifikation, grundlæggende design, detaljeret design, produktion (programimplementering) og test (almindeligvis kendt som vandfaldsmodellen). Men i virkeligheden sker det ofte, at der opstår tilbageskridt i processen på grund af forskellige omstændigheder, der afslører mangler i de tidligere faser.

Hvordan skal vi tænke, hvis vi ikke kan overholde tidsfristen i sådanne sager? Ved at læse tidligere retsafgørelser ser det ud til, at konklusionen varierer afhængigt af, hvornår det ekstra arbejde opstod.

Hvis det ekstra arbejde opstod før specifikationerne blev klargjort i det eksterne design osv.

Den tidligere nævnte retsafgørelse indikerer, at det ikke er en overtrædelse af samarbejdsforpligtelsen at fremsætte sådanne anmodninger, hvis der var en anmodning om yderligere udvikling fra brugeren under det grundlæggende design (før programimplementeringsfasen).

Det er naturligt for brugeren at stille forskellige krav til systemet, der skal bygges, under det grundlæggende designarbejde, og det er svært for brugeren, der ikke har nogen teknisk viden, at afgøre præcist, om disse krav vil kræve ekstra gebyrer eller forlængelse af leveringstiden, eller om de vil forstyrre arbejdsprocessen. Derfor kan det ikke siges, at brugeren skulle have afholdt sig fra at stille krav, der ville medføre ekstra gebyrer eller forlængelse af leveringstiden. Tværtimod, hvis brugeren har stillet krav, der kræver ekstra gebyrer eller forlængelse af leveringstiden, skulle leverandøren, der har projektledelsesforpligtelsen, have informeret brugeren om dette og anmodet om diskussioner om tilbagetrækning af kravene eller forlængelse af leveringstiden, så der ikke opstår problemer med udviklingsarbejdet.

Tokyo District Court, dom af 10. marts 2004 (2004)

I denne dom blev det indikeret, at selvom brugeren har en vis samarbejdsforpligtelse, skal man tage hensyn til det faktum, at brugeren ikke er en ekspert i systemudvikling. Med andre ord, da brugeren, der bestiller, ikke er en ekspert i systemudvikling, er det ikke usædvanligt, at de kommer med forskellige ordrer i små portioner indtil systemindholdet er klart (nogle gange er de ikke engang vant til at bestille), og det er urimeligt at forvente, at de selv skal indse, at indholdet af deres ordrer kræver en revision af leveringstiden osv.

Imidlertid er den forpligtelse, der pålægges leverandøren her, i sidste ende en indsats for kommunikation, såsom at anmode om en forlængelse af leveringstiden (eller hvis leveringstiden ikke kan ændres, at foreslå, at de ekstra krav trækkes tilbage). Derfor skal det bemærkes, at det ikke betyder, at det inkluderer alle forpligtelser til at acceptere alle brugerens krav og levere på den oprindelige dato.

Hvis det ekstra arbejde opstod efter specifikationerne blev fastlagt i produktions- eller testfasen

Hvis vi vender indholdet af den ovennævnte dom, kan vi i nogen grad forudsige, hvad konklusionen ville have været, hvis det var yderligere udvikling efter at specifikationerne allerede var blevet fastlagt. I sådanne tilfælde ville det være svært for sådanne anmodninger at blive accepteret. Det er sandt, at der er en stor forskel i forståelsen af udviklingsarbejdet mellem brugeren og leverandøren, uanset om specifikationerne er fastlagt før eller efter.

Men at ændre eller tilføje til ordreindholdet efter at specifikationerne er blevet fastlagt, har en høj sandsynlighed for at kræve, at arbejdet skal gøres om. Det er ofte svært at forsvare forsinkelser i leveringstiden, der opstår i sådanne tilfælde, med argumentet om, at “det er naturligt for kunden at have forskellige anmodninger”. Desuden rejser situationen, hvor mange specifikationsændringer og funktionstilføjelser opstår efterfølgende, spørgsmålet om, hvorvidt der var en overtrædelse af brugerens samarbejdsforpligtelse i de opstrømsprocesser, der allerede skulle have været afsluttet.

Ud fra disse overvejelser er det urealistisk at betragte forsinkelser i leveringstiden forårsaget af specifikationsændringer, der blev foretaget efter at specifikationerne en gang var blevet fastlagt, som leverandørens ansvar. Det er rimeligt at læse denne betydning også fra den tidligere nævnte dom.

Desuden har sådanne afgørelser en tendens til at blive foretaget på baggrund af beviser som mødereferater, der er justeret i overensstemmelse med fremskridtene i systemudviklingen, ikke kun kontrakter. Mødereferater er detaljeret forklaret i den følgende artikel.

Relateret artikel: Hvordan man holder mødereferater i systemudvikling fra et juridisk perspektiv[ja]

Opsummering: Det er vigtigt ikke at glemme, at kravspecifikation er en proces på brugerens side

Kravspecifikation er på den ene side en mulighed for leverandøren til at vise sine evner, men det er vigtigt at være opmærksom på, at det i første omgang er en proces på brugerens side. Da det er et system, der skal bruges i virksomheden, bør det, selvom det er opbygget med hjælp fra eksterne eksperter, betragtes som et område, hvor virksomhedens governance gælder i henhold til loven.

Hvis brugeren ikke er samarbejdsvillig i udviklingsprocessen, er det vigtigt at være opmærksom på, at der er en stor chance for, at retten vil have en streng holdning over for brugeren, selvom projektet skulle gå op i flammer.