\nhttps:\/\/monolith-law.jp\/corporate\/project-management-duties\n<\/div><\/figure>\n\n\n\n
For det andre har brukeren, selv om de er kunden, ogs\u00e5 omfattende forpliktelser til \u00e5 samarbeide med leverand\u00f8rens arbeid. Siden systemet skal brukes internt i selskapet, er det ikke tilstrekkelig \u00e5 bare overlate alt til leverand\u00f8ren. Det er en plikt til \u00e5 samarbeide fra selskapets side slik at leverand\u00f8ren kan ut\u00f8ve sin ekspertise. Vi forklarer dette i detalj i f\u00f8lgende artikkel.<\/p>\n\n\n\n\nhttps:\/\/monolith-law.jp\/corporate\/user-obligatory-cooporation\n<\/div><\/figure>\n\n\n\n
For \u00e5 oppsummere, mellom leverand\u00f8ren og brukeren er det b\u00e5de et forhold som “ekstern leverand\u00f8r” som utvikler systemet og “kunde” som betaler for tjenesten, men samtidig er de ogs\u00e5 “partnere” som skal samarbeide mot det felles m\u00e5let om \u00e5 fullf\u00f8re prosjektet. Denne kompleksiteten i forholdet er en stor egenskap ved kontrakter for systemutvikling, som ikke finnes i enkle skreddersydde tjenester som for eksempel en skredder. P\u00e5 grunn av denne kompleksiteten kan tvister om systemutvikling, n\u00e5r de f\u00f8rst oppst\u00e5r, bli kompliserte og vanskelige \u00e5 l\u00f8se juridisk.<\/p>\n\n\n\n
\u00c5 vurdere hvordan man skal forst\u00e5 rettighetene og forpliktelsene til begge parter n\u00e5r brukeren plutselig bestemmer seg for at “systemet ikke lenger er n\u00f8dvendig, s\u00e5 prosjektet trenger ikke \u00e5 fortsette”, gir et eksempel p\u00e5 juridisk tenkning i m\u00f8te med slike komplekse kontraktsforhold. Nedenfor organiserer vi de sakene som b\u00f8r vurderes i slike tilfeller.<\/p>\n\n\n\n
<\/span>F\u00f8rst, organiser \u00e5rsakene til oppsigelsen<\/span><\/h2>\n\n\n\nBekreft \u00e5rsakene til prosjektavbruddet.<\/figcaption><\/figure>\n\n\n\nSelv om leverand\u00f8ren oppfatter det som at “brukeren ensidig \u00f8nsker \u00e5 avbryte prosjektet”, er det ikke alltid sikkert at denne oppfatningen deles med brukeren. For eksempel, la oss anta at et prosjekt for \u00e5 utvikle et system for \u00e5 administrere personalet til ansatte stasjonert i utlandet ble startet, men senere ble hele planen om \u00e5 ekspandere til utlandet kansellert, og utviklingen av et slikt system ble un\u00f8dvendig. Ut fra denne forklaringen alene kan det virke som en ensidig beslutning fra brukerens side.<\/p>\n\n\n\n
Men hva om beslutningen ble tatt fordi leverand\u00f8ren ogs\u00e5 hadde brutt sine prosjektledelsesforpliktelser, som forsinkelser i ulike faser, og dette bidro til vanskeligheter med fremdriften av utviklingen, noe som igjen p\u00e5virket selskapets beslutning om \u00e5 endre sin strategi?<\/p>\n\n\n\n
Som nevnt tidligere, inneb\u00e6rer systemutvikling at b\u00e5de leverand\u00f8ren og brukeren har betydelige forpliktelser og m\u00e5 samarbeide tett. Derfor, selv om brukeren initierte avbruddet og leverand\u00f8ren oppfattet det som en oppsigelse av brukerens egne grunner, b\u00f8r man v\u00e6re klar over at leverand\u00f8ren kan bli anklaget for brudd p\u00e5 sine forpliktelser, og at brukeren kan hevde at det er en oppsigelse basert p\u00e5 mislighold eller en gjensidig avtalt oppsigelse.<\/p>\n\n\n\n
Skillet mellom en oppsigelse av egne grunner, en oppsigelse basert p\u00e5 mislighold, eller en gjensidig avtalt oppsigelse, vurderes ofte individuelt basert p\u00e5 prosjektets fremdrift og forhandlingshistorikken. Derfor, hvis leverand\u00f8ren \u00f8nsker \u00e5 behandle det som en oppsigelse av brukerens egne grunner, er det viktig \u00e5 tydelig dokumentere dette i m\u00f8tereferater og andre steder for \u00e5 unng\u00e5 fremtidige tvister.<\/p>\n\n\n\n
<\/span>Deretter bekrefter vi grunnlagsbestemmelsene for krav om honorar og erstatning<\/span><\/h2>\n\n\n\nHva er flyten av bekreftelses- og vurderingspunkter i tilfelle av brukerens egen bekvemmelighet?<\/figcaption><\/figure>\n\n\n\nMed tanke p\u00e5 de ovennevnte punktene, hvis det er mulig \u00e5 fortsette samtalen som en kansellering p\u00e5 grunn av brukerens egen bekvemmelighet, vil vi deretter vurdere om det er mulig for leverand\u00f8ren \u00e5 kreve honorar i henhold til fullf\u00f8ringsgraden eller kreve erstatning fra brukeren.<\/p>\n\n\n\n
Bestemmelsene som skal refereres til i slike tilfeller varierer avhengig av kontraktstypen. Kontrakter knyttet til systemutvikling kan grovt sett deles inn i oppdragskontrakter og semi-oppdragskontrakter.<\/p>\n\n\n\n\nhttps:\/\/monolith-law.jp\/corporate\/contract-and-timeandmaterialcontract\n<\/div><\/figure>\n\n\n\n
For semi-oppdragskontrakter og oppdragskontrakter fastsetter den japanske sivilretten f\u00f8lgende:<\/p>\n\n\n\n
\na.) I tilfelle av semi-oppdragskontrakter
b.) I tilfelle av oppdragskontrakter
<\/p>\n
<\/p>\n
Omfanget av erstatning i henhold til Japansk sivilrett artikkel 641 (1896) inkluderer ikke bare de allerede p\u00e5l\u00f8pte kostnadene, men ogs\u00e5 “fortjenesten som ville blitt oppn\u00e5dd hvis kontrakten ikke hadde blitt sagt opp.” Dette er fordi det er meningsl\u00f8st \u00e5 tvinge fullf\u00f8ring av arbeidet som har blitt un\u00f8dvendig for bestilleren, og i slike tilfeller er det mer rasjonelt \u00e5 sikre oppdragstakerens fortjeneste ved \u00e5 betale tilsvarende vederlag.<\/p>\n
<\/p>\n
<\/p>\n
Imidlertid, n\u00e5r det gjelder erstatning i henhold til Japansk sivilrett artikkel 641 (1896), er det ikke uvanlig at individuelle kontrakter mellom leverand\u00f8ren og brukeren ekskluderer erstatning. I slike tilfeller vil de individuelle avtalene mellom partene (dvs. kontrakten) ha forrang, og de sivilrettslige bestemmelsene vil ikke gjelde, s\u00e5 det er viktig \u00e5 v\u00e6re oppmerksom p\u00e5 dette.<\/p>\n
<\/span>Videref\u00f8ring av bevis for utf\u00f8rt arbeid og skader<\/span><\/h2>\n<\/p>\n
<\/p>\n
Ved oppsigelse fra brukerens side av personlige \u00e5rsaker, er det vanlig i kontrakter at man kan kreve betaling for utf\u00f8rt arbeid (dvs. fullf\u00f8rte deler) og erstatning for skader. Derfor er det vanligvis n\u00f8dvendig for leverand\u00f8ren \u00e5 bevise utf\u00f8rt arbeid og skader for \u00e5 kunne fremme et erstatningskrav.<\/p>\n
<\/p>\n
<\/p>\n
Imidlertid kan det \u00e5 bevise utf\u00f8rt arbeid, alts\u00e5 fullf\u00f8ringsgraden, v\u00e6re en sv\u00e6rt krevende oppgave i praksis. Dette skyldes at det kan v\u00e6re betydelig arbeid \u00e5 bekrefte fremdriften, spesielt n\u00e5r det er flere underleverand\u00f8rer involvert. Dette inneb\u00e6rer ofte omfattende h\u00f8ringer for \u00e5 fastsl\u00e5 hvor mye av hvert arbeidsoppdrag som er fullf\u00f8rt. I tillegg m\u00e5 man utarbeide dokumentasjon som st\u00f8tter resultatene av disse h\u00f8ringene, samt dokumentere selve innholdet av h\u00f8ringene, noe som kan v\u00e6re sv\u00e6rt tidkrevende. Selv etter alt dette arbeidet er det en risiko for at bevisene kan bli ansett som utilstrekkelige, noe som kan gj\u00f8re alt arbeidet forgjeves.<\/p>\n
<\/p>\n
<\/p>\n
Som en mottiltak kan man i kontraktsfasen p\u00e5 forh\u00e5nd spesifisere at ved oppsigelse skal beregningen gj\u00f8res pro rata basert p\u00e5 antall dager frem til oppsigelsen, for \u00e5 forenkle beregningen. Videre, gitt at bevis for utf\u00f8rt arbeid kan v\u00e6re tidkrevende, kan man vurdere \u00e5 avst\u00e5 fra \u00e5 kreve betaling for utf\u00f8rt arbeid og i stedet kreve betaling for kostnadene ved utviklingen av de fullf\u00f8rte delene. For interne utviklingskostnader kan dette ofte enkelt beregnes ved hjelp av en enkel formel som “arbeidstimer \u00d7 timepris”. Spesielt for prosjekter med lav fortjenestemargin kan det v\u00e6re mer praktisk \u00e5 prioritere krav basert p\u00e5 kostnader fremfor utf\u00f8rt arbeid, da dette kan gj\u00f8re det lettere \u00e5 inndrive kravene og dermed kompensere for tapene. Dette kan ofte v\u00e6re en mer realistisk l\u00f8sning.<\/p>\n
<\/span>Hva b\u00f8r vurderes fra brukerens side?<\/span><\/h2>\n<\/p>\n
<\/p>\n
For \u00f8vrig, brukere som \u00f8nsker \u00e5 si opp avtalen av egne grunner, b\u00f8r ogs\u00e5 vurdere noen punkter p\u00e5 forh\u00e5nd. Det inkluderer \u00e5 bekrefte en omtrentlig sum for erstatningsbel\u00f8pet som m\u00e5 betales til leverand\u00f8ren. Her refererer “omtrentlig” til \u00e5 ha en grov id\u00e9 om bel\u00f8pet for \u00e5 kunne planlegge videre forhandlinger (det er tilstrekkelig med en omtrentlig sum, da en forsinkelse i \u00e5 uttrykke oppsigelsesintensjonen ville v\u00e6re kontraproduktivt).<\/p>\n
<\/p>\n
<\/p>\n
Hvis den bekreftede omtrentlig summen virker urimelig h\u00f8y, b\u00f8r man be om en forklaring. Men hvis man pr\u00f8ver \u00e5 forhandle p\u00e5 en urimelig m\u00e5te for \u00e5 redusere bel\u00f8pet, kan det f\u00f8re til meningsl\u00f8se rettssaker og ytterligere komplikasjoner. Hvis forhandlingene mellom de to partene ser ut til \u00e5 bli vanskelige, kan det v\u00e6re en god id\u00e9 \u00e5 konsultere en advokat.<\/p>\n
<\/p>\n
<\/p>\n
For \u00f8vrig, denne artikkelen forutsetter at en kontrakt om systemutvikling er inng\u00e5tt, men i virkeligheten er det ikke uvanlig at det oppst\u00e5r tvister om hvorvidt kontrakten er gyldig inng\u00e5tt i det hele tatt. Dette er detaljert forklart i artikkelen nedenfor.<\/p>\n
<\/p>\n
<\/p>\n\n\nhttps:\/\/monolith-law.jp\/corporate\/system-development-contract\n<\/div>\n<\/figure>\n
<\/p>\n
<\/span>Oppsummering<\/span><\/h2>\n<\/p>\n
<\/p>\n
I denne artikkelen har vi forklart prosessen for \u00e5 h\u00e5ndtere tilfeller der et prosjekt blir avbrutt p\u00e5 grunn av brukerens forhold. Det viktigste poenget i denne artikkelen er imidlertid behovet for \u00e5 vurdere om det virkelig kan sies \u00e5 v\u00e6re brukerens egen skyld, og om leverand\u00f8ren virkelig ikke har gjort noen feil.<\/p>\n
<\/p>\n
<\/p>\n
Systemutviklingsprosjekter kjennetegnes ved at b\u00e5de leverand\u00f8ren og brukeren har store forpliktelser. Derfor b\u00f8r man n\u00f8ye vurdere p\u00e5 forh\u00e5nd om det virkelig er mulig \u00e5 ensidig tillegge den andre parten skylden, ellers kan situasjonen forverres ytterligere.<\/p>\n
<\/p>","protected":false},"excerpt":{"rendered":"
Systemutvikling er ofte et langtidsprosjekt. S\u00e5 hva kan leverand\u00f8ren gj\u00f8re hvis brukeren ensidig sier: “Vi trenger ikke lenger dette systemet, s\u00e5 dere trenger ikke \u00e5 lage det” etter at utv […]<\/p>\n","protected":false},"author":32,"featured_media":81974,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[19,31],"acf":[],"_links":{"self":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70847"}],"collection":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/comments?post=70847"}],"version-history":[{"count":2,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70847\/revisions"}],"predecessor-version":[{"id":81978,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70847\/revisions\/81978"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media\/81974"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media?parent=70847"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/categories?post=70847"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/tags?post=70847"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}