Den juridiska betydelsen av affärsmål och numeriska mål i systemutvecklingsprojekt

Systemutvecklingsprojekt är ofta nära kopplade till stora förbättringar i företag och arbetsplatser. I dessa sammanhang kan det krävas en inställning som bidrar till att lösa företagets ledningsproblem eller uppnå numeriska mål. Men är det verkligen en laglig skyldighet att engagera sig i dessa ledningsmål? Frågan blir vad den juridiska betydelsen av numeriska mål och ledningsmål är. I denna artikel kommer vi att diskutera juridiska frågor relaterade till olika “syften” och “mål” i systemutveckling.

Varför blir systemutvecklingsmål och mål en källa till konflikt?

Det är en utmaning som ligger mellan användarens samarbetsplikt och leverantörens diskretion

När man ser på affärstransaktioner, finns det några särdrag i systemutvecklingsprojekt. Ett av dessa är att ett systemutvecklingsprojekt som utförs av en leverantör inte kan genomföras enbart av leverantören, utan kräver samarbete från användarens sida. Denna skyldighet är tydligt definierad i prejudikat som “samarbetsplikt”. Användaren krävs att samarbeta i systemutvecklingen, främst i faserna för ① kravdefinition ② grundläggande design ③ godkännande av resultat.

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

En annan punkt är att leverantören vanligtvis krävs att utöva stor diskretion i sitt arbete. Det finns en juridisk term som sammanfattar vad leverantören bör göra i ett systemutvecklingsprojekt, kallat “projektledningsplikt”. Detta förklaras mer detaljerat i följande artikel.

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

Om vi sammanfattar ovanstående innehåll kan vi peka på två viktiga punkter här.

• Användaren krävs i praktiken att tillhandahålla nödvändig information till leverantören och samarbeta med leverantörens utvecklingsarbete.
• Leverantören krävs i praktiken att förstå projektets mål och mål för användaren och att genomföra åtgärder som överensstämmer med dessa.

På grund av dessa två punkter blir det ett problem hur långt leverantörens skyldighet att uppnå företagsmål och numeriska mål, som förklarats i förväg av användaren, kan sträcka sig juridiskt. Med andra ord, det finns en aspekt att det är användarens skyldighet att sammanfatta vad leverantören bör göra (inte något vagt som mål) i specifikationer och presentera dem, men det finns också en aspekt att leverantören har en skyldighet som expert att tillhandahålla vad användaren väsentligen begär (inte bara nöja sig med att göra vad som har sagts). Denna konflikt mellan de två motstridiga argumenten är en egenskap hos konflikter kring systemutvecklingens “mål” och “syfte”. Från en juridisk synvinkel är det en praktisk utmaning att presentera riktlinjer för att lösa konflikter på ett rättvist sätt för båda parter.

Specifika situationer där användarens mål påverkar projektet

Systemutvecklingsprojekt är ofta kopplade till stora förbättringar och effektiviseringar av företag och arbetsplatser, och det är ofta fallet att det finns en hearing om företagsproblem och företagsmål även i det preliminära planerings- och förslagsstadiet. Där kan det finnas diskussioner om kostnadseffektivitet i samband med systemutveckling och utbyten genom olika numeriska mål.

• Personalomkostnader som minskas genom rationalisering
• Ökning av försäljning och intäkter
• Kortare arbetstid

Till exempel, om de ovanstående punkterna är det slutliga målet för projektet, kan leverantören i förväg förklara investeringseffekterna av systemutveckling från en konsults position och överväga att göra affärer.

Exempel på rättsfall där användarens affärsmål har blivit ett problem

Men, leverantören är vanligtvis enbart en expert på systemutveckling. Om allt ansvar skulle falla på dem för användarens affärsmål, kan det bli en alltför hård belastning.

Fallet där förbättring av arbetsprocessens hastighet var målet

I det här fallet, som nämns i domstolsutlåtandet nedan, var syftet och målen för att starta systemutvecklingsprojektet angivna i projektplanen som skapades vid projektets start. Men när systemet var färdigt och började användas, kunde dessa syften och mål inte uppnås, vilket ledde till en tvist. I den ursprungliga projektplanen var det angivet att man efter att systemet var färdigt och började användas, strävade efter att uppnå följande tillstånd:

• Att minska tiden för manuell inmatning med 50%
• Att kunna slutföra administrativa uppgifter med hjälp av det aktuella IT-systemet inom en viss tidsperiod

Användarna kunde inte uppnå dessa resultat och försökte därför hålla leverantören ansvarig för kontraktsbrott och bristande garantiansvar. Men domstolen godkände inte detta argument (understrukna och fetstilade delar har lagts till av författaren).

Och, (utelämnat) enligt hela argumentationen, ① syftet med detta fall är “effektivisering av arbetsprocesser”, “grundläggande CRM”, “genomförande av synlig ledning” etc., vilket är abstrakt, och målvärdena är också “öka kontaktpunkterna med kunder”, “omfördela administrativa arbetsuppgifter till intern kontroll och försäljningsstöd”, “göra mer exakta försäljningsprognoser”, “kontrollera överdriven försäljningsrabatt” etc., vilket är mycket abstrakt, och “minska inmatningstiden med 50%”, “minska offertberedningstiden med 50%”, “genomföra lagstadgad offentliggöring inom lagstadgade dagar” etc., sådana målvärden beror på ledning och arbetsmetoder efter införandet av SBO, och det är inte något som systemutvecklingsföretaget, som stöder införandet av paketprogramvara, kan åta sig att uppnå, ② i mötesprotokollet efter starten av detta projekt finns det ingen anteckning om att man specifikt diskuterade uppnåendet av detta syfte och målvärden, ③ i projektplanen för detta fall finns uttryck som “bli ett börsnoterat företag” etc., vilket inte kan sägas ha karaktären av ett kontrakt i sig, (utelämnat) med hänsyn till dessa omständigheter, det erkänns att den ursprungliga krävaren skapade beskrivningen av syftet med detta fall i projektplanen baserat på svarandens förklaring, för att förhindra att detta projekt misslyckas, det var för att få en gemensam förståelse för syftet och resultaten av detta projekt, och det kan inte erkännas att svaranden, till den ursprungliga krävaren, uppdrar utvecklingen av ett system för att uppnå detta syfte. (utelämnat) Därför kan det inte erkännas att den ursprungliga krävaren har åtagit sig att utveckla ett system för att uppnå syftet med detta fall från svaranden, (utelämnat) det finns ingen anledning till påståendet om ansvar för kontraktsbrott och bristande garantiansvar.

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

Vad är den juridiska betydelsen av affärs- och kvantitativa mål utifrån rättsfall?

Som nämnts i detta domslut är det vanligt att olika faktorer, såsom företagsinsatser från användarens sida, påverkar om målen för systemutveckling och kvantifierade mål kan uppnås. Därför bör vi anta att tröskeln för att hålla leverantören ansvarig är mycket hög. För det första, om leverantörens ansvar för kontraktsbrott eller felansvar erkänns, innebär det att uppfyllandet av “mål” eller “mål” har införlivats som en del av kontraktet. Men i detta fall var “målet” och “målet”

• För abstrakta och vaga saker, är det svårt att betrakta dem som en del av kontraktet eftersom de inte passar in i naturen av juridiska skyldigheter
• För saker som kräver självhjälpsinsatser från användarens sida, särskilt från företagsledningen, är det olämpligt att skylla på leverantören eftersom leverantören inte har kontroll över dem, och det är svårt att betrakta dem som en del av kontraktsförpliktelserna

Detta var den juridiska bedömningen som mottogs.

Ytterligare insikter från denna dom

Det finns flera intressanta punkter i denna dom.

• Domstolen tar hänsyn till att det att dela ‘syftet’ och ‘målen’ för ett systemutvecklingsprojekt kan vara bara en del av ansträngningarna att uppnå ‘gemensam förståelse’ mellan användare och leverantör.
• Domstolen tar hänsyn till mötesprotokoll och liknande dokument när den bedömer hur väsentliga dessa ‘syften’ och ‘mål’ var i hela projektet.

För juridiska frågor som rör systemutvecklingsprojekt, från perspektivet av vikten av dokumenthantering och mötesprotokoll, har vi förklarat i följande artikel.

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

Rättsliga frågor kring företagsmål och kvantitativa mål

Det är dock viktigt att notera följande punkter när det gäller juridiska frågor kring dessa “mål”.

Frågan ändras beroende på om konsultationen är betald eller gratis

Om du inte bara har ett systemutvecklingsprojekt, men också har ingått ett betalt konsultavtal, kan situationen ändras avsevärt. Om det finns omständigheter där en genomförandeplan med liten genomförbarhet har utarbetats utan att ta hänsyn till hur mycket företagsresurser användaren har, kan det vara möjligt att förfölja ansvar för kontraktsbrott i den betalda konsultdelen.

Frågor om produktfel och inkonsekvenser i funktion och specifikationskrav är separata

Om det finns fel i själva utvecklingsprojektet, det vill säga om det finns buggar eller problem i produkten, måste dessa frågor förstås separat. I sådana fall är frågan om överensstämmelse mellan produkten och de krävda funktionskraven och specifikationerna, snarare än diskussioner om företagsmål och mål. Till exempel, vi har förklarat användarens åtgärder när ett fel upptäcks i systemet efteråt i följande artikel.

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

Det finns också relaterade ämnen, såsom saker som inte ingår i kraven, men som leverantören kan anses ha en skyldighet att implementera efter eget gottfinnande. Detta förklaras i detalj i följande artikel.

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

I båda fallen bör dessa förstås som saker som liknar men skiljer sig från tvister kring “mål”.

En grundläggande förståelse av ansvar och kontrakt ifrågasätts

Vi har nu diskuterat juridiska frågor kring “syftet” och “målet” med systemutveckling. I tvister kring dessa frågor tror vi att domstolarna förstår att det ofta krävs gemensamma ansträngningar mellan användare och leverantörer för att samordna sina steg, som en del av kommunikationsinsatserna. Även om slutsatsens giltighet kan förstås fullt ut genom praktisk erfarenhet på fältet, ifrågasätts en grundläggande förståelse av “ansvar” och “kontrakt” i processen för att nå denna punkt. Vi diskuterar dessa frågor i följande artikel.

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

Det är viktigt att få en mer grundläggande förståelse med tanke på att juridiskt ansvar skiljer sig från vagt moraliskt ansvar, och att en klar “överensstämmelse av viljor” mellan båda parter ger upphov till kontraktsansvar.