Hva er den juridiske betydningen av forretningsmål og numeriske mål i systemutviklingsprosjekter?

Systemutviklingsprosjekter er ofte tett knyttet til omfattende forbedringer i bedrifter og arbeidsplasser. I slike tilfeller kan det være nødvendig med en holdning som bidrar til å løse ledelsesutfordringer i brukerbedriften, eller å oppnå numeriske mål. Men er det virkelig en juridisk forpliktelse å forplikte seg til slike ledelsesmål? Spørsmålet blir hva den juridiske betydningen av numeriske mål og ledelsesmål er. I denne artikkelen vil vi diskutere juridiske problemer knyttet til ulike “formål” og “mål” i systemutvikling.

Hvorfor blir mål og målsetninger for systemutvikling en kilde til konflikt?

Det er et problem som ligger mellom brukerens plikt til samarbeid og leverandørens begrensede skjønn

Når man ser på det fra et forretningsmessig perspektiv, er det noen særegenheter ved systemutviklingsprosjekter. En av dem er at et systemutviklingsprosjekt utført av en leverandør ikke kan gjennomføres av leverandøren alene, men krever samarbeid fra brukerens side. Denne plikten er kjent som “samarbeidsplikten” og er klart definert i presedensretten. Hovedsakelig er det i faser som ① kravdefinisjon ② grunnleggende design ③ godkjenning av leveranser, at brukeren også er forventet å samarbeide i systemutviklingen.

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

En annen er at leverandøren vanligvis forventes å utøve betydelig skjønn i sitt arbeid. Det er en juridisk term som oppsummerer hva leverandøren skal gjøre i et systemutviklingsprosjekt, kjent som “prosjektledelsesplikten”. Dette er forklart i detalj i artikkelen nedenfor.

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

Når vi oppsummerer innholdet ovenfor, kan vi peke på to viktige punkter her.

• Brukeren er forventet å gi nødvendig informasjon til leverandøren etter behov og samarbeide med leverandørens utviklingsarbeid i praksis.
• Leverandøren er forventet å forstå brukerens prosjektmål og målsetninger, og ta tiltak som er i tråd med disse i praksis.

På grunn av disse to forholdene, blir det et problem hvor langt leverandøren juridisk sett kan være forpliktet til å oppnå forretningsmål og kvantitative mål som er forklart på forhånd av brukeren. Det vil si, det er en side av saken der det er brukerens plikt å samle sammen hva leverandøren skal gjøre (ikke vage ting som mål, men spesifikasjoner) og presentere det, mens det på den annen side også er en side der leverandøren har en plikt som en ekspert til å levere det brukeren egentlig etterspør (ikke bare gjøre som de blir fortalt). Dette er en karakteristikk av konflikter rundt “mål” og “målsetninger” i systemutvikling, hvor begge parter med motstridende synspunkter kolliderer. Fra et juridisk synspunkt er det en praktisk utfordring å gi retningslinjer for konfliktløsning som er rettferdig for begge parter.

Spesifikke situasjoner der brukerens mål påvirker prosjektet

Systemutviklingsprosjekter er ofte knyttet til store forbedrings- og effektiviseringstiltak i bedrifter og arbeidsplasser, og det er ofte tilfeller der det blir gjennomført høringer om forretningsproblemer og forretningsmål selv i planleggings- og forslagsfasen. Der kan det være utveksling om kostnadseffektivitet knyttet til systemutvikling og utveksling gjennom ulike kvantitative mål.

• Reduksjon av personalkostnader på grunn av effektivisering
• Økning i salg eller inntekter
• Reduksjon av arbeidstid

For eksempel, hvis de ovennevnte elementene er det endelige målet for prosjektet, kan leverandøren på forhånd forklare investeringseffekten av systemutvikling fra en konsulentposisjon og drive salg.

Hva er rettspraksis der brukerens forretningsmål har blitt et problem?

Men, en leverandør er vanligvis bare en ekspert på systemutvikling. Hvis alt ansvar for brukerens forretningsmål skulle falle på dem, kunne det bli en altfor hard belastning.

Sak der målet var å forbedre arbeidsprosessen

I denne saken, som er sitert nedenfor, var målene og formålene med å starte systemutviklingsprosjektet skrevet i prosjektplanen som ble opprettet ved prosjektstart. Imidlertid, da systemet var ferdig og driftsstartet, kunne de ikke oppnå disse målene og formålene, noe som førte til en konflikt. I den opprinnelige prosjektplanen var det skrevet at de sikter mot å realisere følgende tilstander etter at systemet er ferdig og faktisk blir brukt:

• Redusere tiden for manuell inntasting med 50%
• Fullføre administrativ behandling ved bruk av det aktuelle IT-systemet innen en bestemt periode

Da brukerne ikke kunne oppnå disse resultatene, prøvde de å forfølge leverandøren for mislighold av kontrakten og mangelfull garanti. Men retten godtok ikke dette argumentet (understreket og fet skrift er lagt til av forfatteren).

Og, (omitted) ifølge hele argumentet, ① dette prosjektets formål er “effektivisering av arbeid”, “grunnleggende CRM”, “gjennomføring av synlig ledelse”, etc., som er abstrakte, og målverdiene er også “øke kundekontaktpunkter”, “omfordele administrativ arbeidskraft til intern kontroll og salgsstøtte”, “gjøre salgsprognoser mer nøyaktige”, “begrense overdreven salgsrabatter”, etc., som er for det meste abstrakte, og “redusere inntastingstiden med 50%”, “redusere estimert opprettelsestid med 50%”, “gjennomføre lovbestemt avsløring innen lovbestemte dager”, etc., er målverdier som avhenger av hvordan saksøkte driver sin virksomhet og arbeidsmetoder etter SBO-implementering, og det er ikke noe som systemutviklingsfirmaet, som er saksøker, kan påta seg å oppnå, ② det er ingen omtale av at de spesifikt diskuterte oppnåelsen av dette prosjektets formål og målverdier i møtereferatene etter dette prosjektets kickoff, ③ i dette prosjektets prosjektplan er det uttrykk som “bli et børsnotert selskap”, etc., som ikke i seg selv har kontraktsmessig karakter, (omitted) gitt disse omstendighetene, er det anerkjent at saksøker opprettet beskrivelsen av dette prosjektets formål i dette prosjektets prosjektplan basert på saksøktes forklaring for å forhindre at dette prosjektet mislykkes, for å få felles forståelse av dette prosjektets formål og resultater, og det kan ikke anerkjennes at saksøkte har betalt saksøker for systemutvikling for å oppnå dette prosjektets formål. (omitted) Derfor, siden det ikke kan anerkjennes at saksøker har påtatt seg systemutvikling fra saksøkte for å oppnå dette prosjektets formål, (omitted) er det ingen grunn til påstandene om mislighold av kontrakten og mangelfull garanti.

Tokyo District Court, December 28, 2010 (Heisei 22)

Hva er den juridiske betydningen av forretningsmål og numeriske mål som kan leses fra rettspraksis?

Som nevnt i denne dommen, er det vanlig at forskjellige faktorer, som for eksempel ledelsesinnsats fra brukerens side, påvirker om målet for systemutvikling eller kvantifiserte mål kan oppnås. Derfor bør det antas at terskelen for å holde leverandørsiden ansvarlig er svært høy. Først og fremst, hvis leverandørens ansvar for kontraktsbrudd eller mangelfull garanti anerkjennes, betyr det at oppnåelsen av “mål” eller “mål” var innarbeidet som en del av kontraktsinnholdet. Imidlertid, i dette tilfellet, ble “mål” eller “mål” vurdert juridisk som følger:

• For abstrakte og vage ting, er det urimelig å betrakte dem som en del av kontraktsinnholdet, da de ikke passer med naturen til juridiske forpliktelser.
• For ting som krever selv-hjelps innsats, spesielt fra ledelsessiden av brukeren, er det urimelig å holde leverandørsiden ansvarlig og betrakte dem som en del av kontraktsforpliktelsene, da de er utenfor leverandørens kontroll.

Dette er den juridiske vurderingen som ble mottatt.

Ytterligere innsikt fra denne dommen

Denne dommen inneholder også flere interessante punkter.

• Retten tar hensyn til at det å dele ‘mål’ og ‘målsetninger’ i et systemutviklingsprosjekt kan være bare en del av kommunikasjonsinnsatsen for å oppnå ‘felles forståelse’ mellom brukere og leverandører.
• I vurderingen av hvor vesentlige disse ‘målene’ og ‘målsetningene’ var i en serie prosjekter, har retten også tatt hensyn til møtereferater og lignende.

For øvrig, når det gjelder juridiske spørsmål knyttet til systemutviklingsprosjekter, har vi diskutert viktigheten av dokumentstyring og møtereferater i følgende artikkel.

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

Rettslige hensyn rundt forretningsmål og kvantitative mål

Det er imidlertid viktig å merke seg følgende tilleggspunkter når det gjelder juridiske spørsmål rundt slike “mål” og “målsettinger”.

Konsultasjonen kan endre seg avhengig av om den er betalt eller gratis

Hvis du ikke bare har et systemutviklingsprosjekt, men også en betalt konsulentavtale, kan situasjonen endre seg betydelig. Uavhengig av hvor mye forretningsressurser brukersiden har, hvis det er omstendigheter som å utarbeide en gjennomføringsplan med liten sannsynlighet for realisering, kan det være mulig å bli forfulgt for ansvar for mislighold av den betalte konsulentavtalen.

Feil i resultatene, og inkonsekvenser i funksjoner og spesifikasjonskrav er separate problemer

Hvis det er feil i selve “utviklings” prosjektet, det vil si hvis det er feil eller bugs i resultatene, må du forstå dette som et separat problem. I så fall vil spørsmålet være om det er samsvar mellom resultatene og de nødvendige funksjonskravene og spesifikasjonene, uavhengig av forretningsmålene og målene. For eksempel, vi forklarer brukerens mottiltak i tilfelle feil blir oppdaget i systemet etterpå i følgende artikkel.

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

Det er også relaterte emner, som ting som ikke er inkludert i kravene, men som leverandøren har en plikt til å implementere etter eget skjønn. Vi forklarer dette i detalj i følgende artikkel.

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

I begge tilfeller bør du forstå dem som ting som ligner, men er forskjellige fra konflikter rundt “mål” og “målsettinger”.

En grunnleggende forståelse av ansvar og kontrakter er nødvendig

Vi har nå gjennomgått juridiske problemer knyttet til “mål” og “målsettinger” i systemutvikling. I konflikter rundt disse problemene, tror vi at domstolene forstår at det ofte er et felles initiativ mellom brukere og leverandører for å koordinere deres innsats, som en del av deres kommunikasjonsarbeid. Selv om gyldigheten av konklusjonen i seg selv kan forstås godt nok gjennom praktisk erfaring, er det i prosessen som fører til dette at en grunnleggende forståelse av “ansvar” og “kontrakter” blir utfordret. Vi forklarer disse punktene i artikkelen nedenfor.

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

Det er viktig å forstå at juridisk ansvar er forskjellig fra en vag moralsk forpliktelse, og at en klar “samstemmighet i intensjon” mellom begge parter er det som skaper kontraktsmessig ansvar. Med dette i bakhodet, mener vi det er viktig å oppnå en mer grunnleggende forståelse.