Hvad er den juridiske betydning af ledelsesmål og numeriske mål i systemudviklingsprojekter?

Systemudviklingsprojekter er ofte tæt knyttet til omfattende forbedringer af virksomheders og arbejdspladsers operationer. I disse tilfælde kan det være nødvendigt at bidrage til løsningen af virksomhedens ledelsesmæssige udfordringer eller opnåelse af kvantitative mål. Men er det virkelig en juridisk forpligtelse at forpligte sig til disse ledelsesmål? Spørgsmålet bliver, hvad den juridiske betydning af kvantitative mål og ledelsesmål er. I denne artikel vil vi diskutere de juridiske problemer forbundet med de forskellige “formål” og “mål” i systemudvikling.

Hvorfor bliver mål og formål med systemudvikling en kilde til konflikt?

Det er et problem, der ligger mellem brugerens samarbejdspligt og leverandørens skøn

Når man ser på det fra et kommercielt transaktionsperspektiv, er der flere karakteristiske punkter i et systemudviklingsprojekt. Et af dem er, at et systemudviklingsprojekt udført af en leverandør ikke kan gennemføres alene af leverandøren, men kræver samarbejde fra brugersiden. Denne forpligtelse er klart defineret i præcedensretten som “samarbejdspligt”. Primært er det i faser som ① kravspecifikation ② grundlæggende design ③ accept af leverancer, at brugeren også er forpligtet til at samarbejde i systemudviklingen.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Et andet punkt er, at leverandøren normalt forventes at udøve stor skøn i sit arbejde. Der er en juridisk term, der opsummerer, hvad leverandøren skal gøre i et systemudviklingsprojekt, kaldet “projektledelsespligt”. Dette er detaljeret forklaret i den følgende artikel.

https://monolith.law/corporate/project-management-duties[ja]

Når vi opsummerer ovenstående, kan vi pege på to vigtige punkter her.

• Brugeren forventes i praksis at give leverandøren den nødvendige information efter behov og samarbejde med leverandørens udviklingsarbejde.
• Leverandøren forventes i praksis at forstå brugerens projektformål og mål og tage tiltag, der er i overensstemmelse med disse.

På grund af disse to punkter bliver det et problem, hvor meget af opnåelsen af forretningsmål og kvantitative mål, der er forklaret af brugeren på forhånd, kan blive leverandørens juridiske forpligtelse. Det vil sige, på den ene side er det brugerens pligt at sammenfatte, hvad leverandøren skal gøre (ikke noget vagt som mål) i specifikationer og præsentere det, mens leverandøren også har en pligt som en ekspert til at levere, hvad brugeren i bund og grund kræver (ikke bare at være tilfreds med at gøre, hvad der er blevet sagt). Det er denne konflikt mellem de to modstridende synspunkter, der er karakteristisk for konflikter omkring “mål” og “formål” i systemudvikling. Fra et juridisk synspunkt er det en praktisk udfordring at præsentere retningslinjer for konfliktløsning, der gavner begge parter.

Specifikke situationer, hvor brugerens mål påvirker projektet

Systemudviklingsprojekter er ofte forbundet med store forbedringer og effektivisering af virksomheder og arbejdspladser, og der er ofte høringer om forretningsproblemer og forretningsmål selv i den indledende planlægnings- og forslagsfase. Her kan der være diskussioner om omkostningseffektiviteten af systemudvikling og forskellige kvantitative mål.

• Reducerede personaleomkostninger på grund af effektivisering
• Øget salg og indtjening
• Reduktion af arbejdstid

For eksempel, hvis de ovenstående punkter er det endelige mål for projektet, kan leverandøren på forhånd forklare investeringseffekten af systemudvikling fra en konsulentlignende position og overveje at gennemføre salg.

Retssager, hvor brugerens forretningsmål er blevet et problem

Men leverandører er normalt eksperter i systemudvikling. Hvis alt ansvar for brugerens forretningsmål skulle pålægges dem, kunne det blive en urimelig byrde.

En sag, hvor forbedring af arbejdshastigheden var et mål

I den dom, der citeres nedenfor, var formålet og målene med at starte et systemudviklingsprojekt angivet i forretningsplanen, der blev oprettet ved projektets start. Men da systemet var færdigt og operationerne begyndte, kunne de ikke opnå disse mål, og det førte til en konflikt. I den oprindelige forretningsplan var det angivet, at de efter systemet var færdigt og begyndte at blive brugt, sigtede mod at opnå følgende tilstande:

• Reducer tiden for manuel indtastning med 50%
• Gør det muligt at fuldføre administrative opgaver ved hjælp af det pågældende IT-system inden for en bestemt periode

Brugeren forsøgte at retsforfølge leverandøren for manglende opfyldelse af forpligtelser og mangelfuld garanti, fordi de ikke kunne opnå disse resultater. Men retten accepterede ikke dette argument (understreget og fed skrift er tilføjet af forfatteren).

Og, (udeladt) ifølge det samlede indhold af argumenterne, ① formålet med denne sag er “forbedring af arbejdseffektivitet”, “opbygning af CRM-fundament”, “udførelse af synlig ledelse”, osv., som er abstrakte, og målene er også “øge kontaktpunkter med kunder”, “omfordele arbejdskraften i administrationen til intern kontrol og salgsstøtte”, “gøre salgsprognoser mere præcise”, “begrænse overdreven salgsrabatter”, osv., som er for det meste abstrakte, og “reducere indtastningstiden med 50%”, “reducere estimeringstiden med 50%”, “gøre lovpligtig offentliggørelse inden for lovens tidsramme”, osv., er mål der afhænger af den anklagedes forretningsstyring og arbejdsmetoder efter implementeringen af SBO, og er ikke af en art, som den sagsøgende, et systemudviklingsfirma, der støtter implementeringen af pakkesoftware, kan påtage sig at opnå, ② i mødereferaterne efter kickoff af dette projekt er der ingen omtale af specifikke diskussioner om opnåelsen af dette formål og mål, ③ i projektplanen for denne sag er der udtryk som “at blive et børsnoteret selskab”, osv., som ikke i sig selv har karakteren af en kontrakt, (udeladt) under hensyntagen til disse omstændigheder, kan det anerkendes, at den sagsøgende oprettede beskrivelsen af dette formål i projektplanen for denne sag baseret på den anklagedes forklaring for at forhindre, at dette projekt mislykkes, og for at opnå en fælles forståelse af formålet og resultaterne af dette projekt, og det kan ikke anerkendes, at den anklagede har betroet den sagsøgende med systemudviklingen for at opnå dette formål. (udeladt) Derfor kan det ikke anerkendes, at den sagsøgende har påtaget sig systemudviklingen for at opnå dette formål fra den anklagede, så (udeladt) der er ingen grund til påstanden om manglende opfyldelse af forpligtelser og mangelfuld garanti.

Tokyo District Court, December 28, 2010 (2010)

Hvad er den juridiske betydning af forretningsmål og kvantitative mål, som kan læses fra retspraksis?

Som nævnt i denne dom er det normalt, at forskellige faktorer, såsom brugerens forretningsindsats, er involveret i, om formålet med systemudvikling og kvantitative mål, der er kvantificeret i tal, kan opnås. Derfor bør det antages, at det er meget svært at gøre leverandøren ansvarlig. Først og fremmest, hvis leverandørens ansvar for manglende opfyldelse af forpligtelser og mangelfuld garanti anerkendes, betyder det, at opnåelsen af “formål” og “mål” er indarbejdet som en del af kontraktindholdet. Men i denne sag blev “formål” og “mål” juridisk vurderet som følger:

• For abstrakte og vage ting er det svært at se dem som en del af kontraktindholdet, fordi de ikke passer til naturen af juridiske forpligtelser
• For ting, der kræver brugerens, især ledelsens, selvindsats, er det upassende at tilskrive dem til leverandøren, da de er uden for leverandørens kontrol, og det er svært at se dem som en del af kontraktforpligtelserne

Sådan blev det juridisk vurderet.

Hvad mere kan vi lære fra denne dom?

Denne dom indeholder også flere interessante punkter.

• Retten tager højde for, at deling af “formål” og “mål” for et systemudviklingsprojekt kan være blot en del af kommunikationsindsatsen for at opnå en “fælles forståelse” mellem brugeren og leverandøren.
• Retten tager højde for mødereferater osv. når den overvejer, hvor essentielle disse “formål” og “mål” var i hele projektet.

For øvrigt, med hensyn til juridiske problemer forbundet med systemudviklingsprojekter, har vi forklaret vigtigheden af dokumentstyring og mødereferater i følgende artikel.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Retlige overvejelser omkring forretningsmål og kvantitative mål

Det er dog vigtigt at tage højde for følgende yderligere punkter vedrørende juridiske spørgsmål omkring “formål” og “mål”.

Historien ændrer sig afhængigt af om konsultationen er betalt eller gratis

Hvis du ikke kun har et systemudviklingsprojekt, men også har indgået en betalt konsulentkontrakt, kan situationen ændre sig markant. Uanset hvor mange forretningsressourcer brugeren har, hvis der er omstændigheder, såsom at have udarbejdet en gennemførlighedsplan med begrænset gennemførlighed, kan du blive holdt ansvarlig for manglende opfyldelse af forpligtelser i den betalte konsulentkontrakt.

Fejl i output, og uoverensstemmelser i funktion og specifikationskrav er separate problemer

Desuden, hvis der er fejl i selve “udviklings” projektet, det vil sige, hvis der er fejl eller bugs i outputtet, skal du forstå dette som et separat problem. I sådanne tilfælde er spørgsmålet om overensstemmelse mellem output og de krævede funktionskrav og specifikationer, snarere end forretningsmæssige “formål” og “mål”. For eksempel, vi forklarer brugerens modforanstaltninger i tilfælde af at fejl opdages i systemet efterfølgende i følgende artikel.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Der er også relaterede emner, såsom ting, der ikke er inkluderet i kravene, men som leverandøren er forpligtet til at implementere efter eget skøn. Vi forklarer dette i detaljer i følgende artikel.

https://monolith.law/corporate/system-development-specs-function[ja]

I begge tilfælde skal du forstå, at konflikter omkring “formål” og “mål” er lignende, men forskellige ting.

En grundlæggende forståelse af ansvar og kontrakter er også nødvendig

Vi har nu gennemgået juridiske spørgsmål omkring ‘formål’ og ‘mål’ i systemudvikling. I konflikter omkring disse emner, mener vi, at domstolene forstår, at det ofte er nødvendigt med en fælles indsats fra både brugere og leverandører for at sikre kommunikation. Selvom konklusionens gyldighed kan forstås ud fra en praktikers praktiske fornemmelse, er en grundlæggende forståelse af ‘ansvar’ og ‘kontrakter’ nødvendig i processen, der fører til dette. Vi forklarer disse punkter i artiklen nedenfor.

https://monolith.law/corporate/responsibility-system-development[ja]

Det er vigtigt at forstå, at juridisk ansvar er forskelligt fra en vag moralsk forpligtelse, og at en klar ‘samstemmighed i intentioner’ mellem begge parter er det, der skaber kontraktligt ansvar. Med dette i tankerne, mener vi, at det er vigtigt at opnå en mere essentiel forståelse.