Hva er loven når betaling for systemutvikling ikke er gjort?
For en leverandør som tar på seg systemutviklingsoppgaver, kan det i en viss forstand være den største risikoen når brukeren ikke betaler for tjenesten, til tross for at den er levert. Kostnadene for systemutvikling består ofte av dyktige fagfolk som programmerere, og det er ofte tilfeller der personalkostnadene er høye. Det kan være en liv-og-død-situasjon hvis inntektsgenereringen blir forsinket. I denne artikkelen vil vi diskutere juridiske aspekter som leverandøren bør vurdere i tilfeller der brukeren ikke svarer på betaling av honoraret.
Først, bekreft om det er mulig å kreve betaling
- En situasjon der leverandøren har levert produktet til brukeren, men brukeren aksepterer ikke leveransen, noe som fører til forsinkelser i faktureringsprosessen.
- Til tross for at man trodde at inspeksjonen var fullført, er det en eller annen uoverensstemmelse mellom brukerens forståelse, og de nekter å betale.
Dette er situasjoner som realistisk sett kan oppstå.
For øvrig, når brukeren inspiserer spesifikasjonene til det ferdige systemet og aksepterer leveransen, kalles dette “inspeksjon” i systemutviklingsterminologi. Betydningen av denne inspeksjonen og hva man bør vurdere når fremdriften ikke er tilfredsstillende, er forklart i detalj i artikkelen nedenfor.
Relatert artikkel: Anvendelsesområder for inspeksjons- og antatt inspeksjonsklausuler i systemutvikling
En generell forklaring på inspeksjonen selv er overlatt til artikkelen ovenfor, men fra et juridisk perspektiv, om brukerens inspeksjon kan sies å være fullført eller ikke, må vurderes med tanke på bestemmelsene om “antatt inspeksjonsklausuler”.
Med dette i bakhodet, er det første punktet som bør vurderes når brukeren nekter å betale, som følger:
- Er jobben fullført i utgangspunktet, eller er den fortsatt uferdig?
- Er det mulig å anvende garantiansvaret for mangler (Artikkel 635 i den japanske sivilloven)?
Grunnen til at vi først bør bekrefte de to punktene ovenfor, er at hvis jobben ikke er fullført i utgangspunktet, og det ikke er noen anvendelse av garantiansvaret for mangler (Artikkel 635 i den japanske sivilloven), vil det ikke være mulig å forvente betaling, selv om en rettssak blir anlagt.
Så, hva bør leverandørens representant undersøke for å vurdere de to punktene ovenfor? La oss se på hvilke dokumenter som bør bekreftes nedenfor.
Dokumenter som skal sjekkes for å undersøke om det er mulig å kreve betaling
| Leveringsdokument Hvis det ikke finnes et leveringsdokument, antas det at leveringen ikke er fullført og at arbeidet ikke er ferdig. |
| Dokument som varsler resultatet av inspeksjonen Dette er det viktigste dokumentet når man skal avgjøre om arbeidet kan betraktes som fullført. I tillegg, hvis inspeksjonen er utsatt på grunn av brukerens omstendigheter, er det også lurt å sjekke hvordan “antatt inspeksjonsklausul” er beskrevet i kontrakten. |
| Oppgaveadministrasjonsoversikt Dette dokumentet gir informasjon om hvilke oppgaver som har blitt identifisert så langt, og hvilke tiltak som har blitt tatt. Det gir også informasjon om tilstanden til feil og problemer som har oppstått etter levering, og status for reparasjoner. |
| Kravspesifikasjonsdokument, design-dokument og endringsstyringsdokument, møtereferater, etc. Ved å klargjøre hvilken forståelse brukeren og leverandøren hadde i utgangspunktet, blir dette dokumentet som avklarer hva som skal kalles feil og problemer. |
For mer informasjon om hvordan du håndterer endringer i systemspesifikasjoner og hvordan du lager endringsstyringsdokumenter, se en annen artikkel.
Relatert artikkel: Juridisk perspektiv på hvordan håndtere endringsstyring i systemutvikling
| Oppsigelsesvarsel eller dokument som beskriver brukerens intensjon Dette er en metode for å forstå hva brukeren har tenkt med hensyn til å ikke fortsette med inspeksjonen (eller ikke betale belønningen). |
Neste, bekreft hvor mye du kan kreve i honorar
Prinsippet er at beløpet som kan kreves, skal være angitt i kontrakten. Men det kan være tilfeller der det ikke er en ordentlig kontrakt (eller et dokument som tilsvarer dette) igjen hvis det er gjort endringer i spesifikasjonene osv. etterpå. Hvordan man beregner på nytt estimatet basert på etterfølgende grunner som endring av spesifikasjoner, tillegg av funksjoner, osv., er forklart i detalj i artikkelen nedenfor.
Relatert artikkel: Er det mulig å øke estimatbeløpet for systemutvikling etterpå?
Metoden for å beregne estimatet på nytt er som beskrevet i denne artikkelen, men spesielt fra perspektivet av å vurdere om det er mulig å øke beløpet som skal kreves, vil vi se på:
- Tilgjengeligheten og innholdet i estimatet for tilleggsutvikling og funksjonskorrigeringer
- Reaksjonen fra brukersiden til estimatet
- Tilgjengeligheten av enighet om beløpet i forhold til situasjonen som forårsaket tilleggsutvikling og funksjonskorrigeringer som er oppført i problemstyringslisten
Det sentrale punktet er å undersøke om det var enighet mellom brukersiden og “bestilling av arbeid for det beløpet” (med andre ord, om kontrakten kan sies å være inngått).
Til slutt, vurdering av viktige spørsmål ved faktisk rettssak
Vær oppmerksom på muligheten for motsøksmål
I systemutvikling er det ikke uvanlig at når enten brukeren eller leverandøren saksøker den andre parten, kan det komme et motsøksmål. Det vil si, det kan være noen argumenter fra brukerens side i situasjoner der betalingen ikke blir gjort.
Først og fremst, selv om brukeren har forskjellige samarbeidsforpliktelser i systemutvikling, bør man ikke glemme at leverandøren, som en ekspert i systemutvikling, har et bredt skjønn og stort ansvar. Vi har en detaljert forklaring på prosjektledelsesforpliktelsene som leverandøren har for systemutvikling i følgende artikkel.
Relatert artikkel: Hva er prosjektledelsesforpliktelser i systemutvikling?
Med andre ord, det er nødvendig å nøye vurdere på forhånd om det er mulig å legge skylden på brukeren som ensidig nekter å betale. Hvis vi ser på tidligere rettsavgjørelser, er det mange tilfeller der leverandøren opprinnelig saksøkte for betaling, men brukeren motsøkte med krav om gjenoppretting til den opprinnelige tilstanden eller erstatning for skade.
Vurder også om det virkelig er fordelaktig for virksomheten
Selv om leverandørens argumenter blir akseptert og det er anerkjent i retten at det er mulig å kreve betaling, hvis situasjonen eskalerer til rettssak, kan det forventes at det vil være vanskelig å fortsette transaksjonene i fremtiden. I tillegg, selv om dine argumenter blir akseptert i retten, bør du være forberedt på at det kan ta ganske lang tid før du faktisk mottar betaling. Hvis du også tar i betraktning at tid og kostnader for å gå til retten ikke er små, kan det ofte være bedre å heller gjøre en innsats for å finne et kompromiss.
Oppsummering
Hvis en bruker ikke overholder betalingsforpliktelsene, vil det være nødvendig å gjennomgå flere typer dokumenter for å vurdere problemet juridisk. I tillegg er det ikke nok å bare ha god dokumenthåndtering, man må også vurdere hvilke organisatoriske risikoer og ulemper man kan stå overfor hvis man til slutt bestemmer seg for å gå til søksmål.
Det er sant at grundig dokumenthåndtering i det daglige vanligvis hører til på operativt nivå. Men hvis man bestemmer seg for å gå til søksmål basert på lagrede dokumenter og materialer, kan det bli en alvorlig ledelsesbeslutning. I slike uvanlige situasjoner bør man forstå hele prosessen, samtidig som man anerkjenner at det er her samholdet og organisasjonsevnen mellom ledelsen og de operative blir satt på prøve.
Category: IT
Tag: ITSystem Development
