Peter Hidas skriver i siste Computerworld (fredag 28. februar 2014) om kompleksiteten i datasystemer og deres iboende tekniske feil. Tittelen er "dykkersyke". Nå kunne jeg først ha brukt mye tid på å irritere meg over at Peter også benytter anledningen til å stikke litt mot jurister som meg selv: "Kompleksiteten drives av alle unntak og spesialtilfeller som det er mange av i offentlig forvaltning. If...then...else... Innholdet ligger nedgravd i ugjennomtrengelige lover, skrevet av jurister som sjelden har noe imot kompleksitet." Jeg har definitivt ikke noe imot kompleksitet, men jeg ønsker også å skape en logisk og oversiktelig kompleksitet. På studiet husker jeg flere professorer som uttalte at: "Det er ikke noe som er så vanskelig som å skrive slik at det er lett å forstå, og det er ikke noe som er så lett som å skrive slik at det er vanskelig å forstå."
Men så til innholdet i artikkelen til Peter Hidas. At han har rett betviler jeg ikke. Det som fremstår likevel interessant er perspektivet på at (nesten) all kode inneholder en eller annen for for feil. Når jeg våger å skrive nesten i parentes så er det fordi jeg faktisk håper det finnes noe kode som ikke inneholder feil. Dette betyr at så lenge du har et IT-system så er det bare et spørsmål om tid før det vil kunne oppstå en feil og ingen kan garantere 100 % oppetid eller 100 % leveranse uten feil eller mangler.
Under årets (2014) IT-kontraktsrettskurs i Sandefjord så holdt advokat Arne Engesæth et svært interessant foredrag hvor han fokuserte på det han valgte å kalle "avvik" i IT-leveranser. Avvik fordi dette var et mer dekkende begrep enn mangels- eller forsinkelsesbegrepet i kjøpsrettens forstand. Slik jeg forstod det så kom det av flere forhold. Et aspekt er at i IT-leveranser, og spesielt komplekse systemutviklingsprosjekter, så vil det være en stor grad av avhengighet mellom partene. Leverandøren kan ikke levere og utvikle et system for kunden uten at denne enten ned i minste detalj har spesifisert leveransen uten unntak eller så må kunden underveis i prosessen bistå med avklaringer, spesifiseringer eller annen bistand slik at leveransen kan utvikles, data migreres, løsningen testes og til slutt produksjonssettes. Det er en stor grad av avhengigheter som øker "ligningen". Avviket kan her oppstå på begge sider av kontrakten og avviket kan oppstå lenge før leveransen er overlevert. Dermed så vil det først være interessant å stille spørsmålet om det foreligger et avvik. Dernest kan partene vurdere om det foreligger et avvik som kan defineres som en mangel fra et kjøps/kontraktsrettslig perspektiv, og om mangelen skal eller kan ha en (økonomisk) konsekvens.
Det interessante spørsmålet er i hvilken grad partene er oppmerksom på å skape en god balanse i kontrakten for IT-prosjektets iboende avvikspotensiale. Hvis det aksepteres at det foreligger et iboende avvikspotensiale, så er dette vanskelig å gardere seg imot. Aksepterer partene dette så er det min oppfatning at denne type avvik sjelden vil kunne danne grunnlag for mislighold etter kontrakt. Her vil jeg anta at funksjonelle krav er testet og har passert uten feil. Misligholdet må da relateres til noe annet enn feil eller mangler i kode. Nettopp den gjensidige avhengighheten vil gjøre det vanskelig å synliggjøre om det er kunden som ikke har spesifisert godt nok sine krav eller funksjonelle behov eller om det er leverandøren som ikke har utført konstruksjonen godt nok. Det kan sammenlignes med to parter som ror en firersculler (eller en Cambridge-Oxford-båt). For at denne skal ro fort og rett frem så må båtens mannskap, bestående av både leverandør og kunde, være godt koordinert for å nå sitt ønskede resultat.
Hvordan er dette løst i dagens standardavtaler? Vel, etter Statens Standardavtaler (SSA) så legges det faktisk opp til at leveranser vil inneholde feil. Hvis ikke, så hvorfor ligger det ibakt i standarden et krav om garantiperiode som skal rette feil og mangler? Hvorfor har kunden i de fleste SSA-avtalene en opsjon på å løse vedlikeholdsavtale med mål om å rette feil som oppstår? Jo, det må ligge i at partene aksepterer en risiko ved IT-systemer for at det verken vil være 100 % oppetid eller at programkode vil inneholde feil. Kanskje burde vi minne oss på dette når vi klager på alle IT-systemene. Og kanskje burde vi være glad for at det oppstår så lite feil som det faktisk gjør.
Men så til innholdet i artikkelen til Peter Hidas. At han har rett betviler jeg ikke. Det som fremstår likevel interessant er perspektivet på at (nesten) all kode inneholder en eller annen for for feil. Når jeg våger å skrive nesten i parentes så er det fordi jeg faktisk håper det finnes noe kode som ikke inneholder feil. Dette betyr at så lenge du har et IT-system så er det bare et spørsmål om tid før det vil kunne oppstå en feil og ingen kan garantere 100 % oppetid eller 100 % leveranse uten feil eller mangler.
Under årets (2014) IT-kontraktsrettskurs i Sandefjord så holdt advokat Arne Engesæth et svært interessant foredrag hvor han fokuserte på det han valgte å kalle "avvik" i IT-leveranser. Avvik fordi dette var et mer dekkende begrep enn mangels- eller forsinkelsesbegrepet i kjøpsrettens forstand. Slik jeg forstod det så kom det av flere forhold. Et aspekt er at i IT-leveranser, og spesielt komplekse systemutviklingsprosjekter, så vil det være en stor grad av avhengighet mellom partene. Leverandøren kan ikke levere og utvikle et system for kunden uten at denne enten ned i minste detalj har spesifisert leveransen uten unntak eller så må kunden underveis i prosessen bistå med avklaringer, spesifiseringer eller annen bistand slik at leveransen kan utvikles, data migreres, løsningen testes og til slutt produksjonssettes. Det er en stor grad av avhengigheter som øker "ligningen". Avviket kan her oppstå på begge sider av kontrakten og avviket kan oppstå lenge før leveransen er overlevert. Dermed så vil det først være interessant å stille spørsmålet om det foreligger et avvik. Dernest kan partene vurdere om det foreligger et avvik som kan defineres som en mangel fra et kjøps/kontraktsrettslig perspektiv, og om mangelen skal eller kan ha en (økonomisk) konsekvens.
Det interessante spørsmålet er i hvilken grad partene er oppmerksom på å skape en god balanse i kontrakten for IT-prosjektets iboende avvikspotensiale. Hvis det aksepteres at det foreligger et iboende avvikspotensiale, så er dette vanskelig å gardere seg imot. Aksepterer partene dette så er det min oppfatning at denne type avvik sjelden vil kunne danne grunnlag for mislighold etter kontrakt. Her vil jeg anta at funksjonelle krav er testet og har passert uten feil. Misligholdet må da relateres til noe annet enn feil eller mangler i kode. Nettopp den gjensidige avhengighheten vil gjøre det vanskelig å synliggjøre om det er kunden som ikke har spesifisert godt nok sine krav eller funksjonelle behov eller om det er leverandøren som ikke har utført konstruksjonen godt nok. Det kan sammenlignes med to parter som ror en firersculler (eller en Cambridge-Oxford-båt). For at denne skal ro fort og rett frem så må båtens mannskap, bestående av både leverandør og kunde, være godt koordinert for å nå sitt ønskede resultat.
Hvordan er dette løst i dagens standardavtaler? Vel, etter Statens Standardavtaler (SSA) så legges det faktisk opp til at leveranser vil inneholde feil. Hvis ikke, så hvorfor ligger det ibakt i standarden et krav om garantiperiode som skal rette feil og mangler? Hvorfor har kunden i de fleste SSA-avtalene en opsjon på å løse vedlikeholdsavtale med mål om å rette feil som oppstår? Jo, det må ligge i at partene aksepterer en risiko ved IT-systemer for at det verken vil være 100 % oppetid eller at programkode vil inneholde feil. Kanskje burde vi minne oss på dette når vi klager på alle IT-systemene. Og kanskje burde vi være glad for at det oppstår så lite feil som det faktisk gjør.
Kommentarer
Legg inn en kommentar