Vad är tillvägagångssättet för förändringshantering i systemutveckling från ett juridiskt perspektiv?

I systemutvecklingsprojekt händer det ofta att användare ändrar innehållet som de förklarade i förväg i processen när arbetet fortskrider. Därför, även som en leverantör som tar emot jobbet, kan det vara nödvändigt att anpassa sig till ändringar i kontraktet även efter att kontraktet har ingåtts en gång.

I denna artikel förklarar vi hur man ska hantera fenomenet “ändringar” som görs i efterhand ur ett juridiskt perspektiv för systemutvecklingsprojekt som inte alltid går enligt plan.

Varför ändras systemutvecklingsprojekt i efterhand?

Systemutveckling är ett samarbete mellan leverantör och användare

Systemutveckling innebär vanligtvis att man går igenom planerings- och förslagsstadiet, definierar utvecklingskraven och ingår ett avtal. Efter att avtalet har ingåtts, går man igenom olika designsteg, implementerar enligt designen, avslutar processen och genomför slutligen ett test. I hela processen är det självklart att leverantören, som tar emot uppdraget, har ett brett ansvar som expert på systemutveckling, men det finns också en viss samarbetsplikt för användaren. I processer som att identifiera de funktioner som det system som ska skapas bör ha (dvs. kravdefinition), utseendet och känslan av skärmen (dvs. grundläggande design), och att bekräfta om kraven har uppfyllts (dvs. testning eller godkännande), är användarens samarbete särskilt viktigt. För en mer detaljerad förklaring av de skyldigheter som användaren har i systemutveckling, se följande artikel.

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

Även om det finns en samarbetsplikt, tenderar användare att begära ändringar

Men det är inte alltid så att användare, som inte är experter på systemutveckling, kan förmedla all nödvändig information för systemutveckling till leverantören på ett planerat och heltäckande sätt. I verkligheten, eftersom det är ett detaljerat och noggrant arbete, är det ofta svårt för användaren att förutsäga vilka fakta som kan ha avgörande betydelse i senare steg. Ironiskt nog kan det hända att ju viktigare fakta är, desto mer sannolikt är det att de kommer fram bit för bit. På grund av dessa omständigheter, även om det idealiska i verkliga projekt är att “genomföra allt från uppströms till nedströms processer i ett svep”, är det viktigt att anta att olika ändringar kan göras i efterhand och att fokusera på hur man hanterar “ändringshantering”.

Vad är ett ändringshanteringsdokument?

När används ett ändringshanteringsdokument?

Ett ändringshanteringsdokument är ett dokument som används när en användare begär ändringar i specifikationer eller tillägg av funktioner från en leverantör, bort från det innehåll som förklarades i förväg. Som nämnt tidigare, under faser som kravdefinition och grundläggande design, har användaren en skyldighet att samarbeta med leverantörens arbete, men det är faktiskt möjligt att senare i processen uppstå olika önskemål.

Exempel på situationer där ett ändringshanteringsdokument kan behövas inkluderar:

• När det finns luckor i övervägandet under kravdefinition och grundläggande design, och en begäran om att lägga till funktioner görs efteråt
• När det under utvecklingens gång görs en översyn av företagets policy, vilket gör att specifikationsändringar behövs

Dessa är några av de möjliga scenarierna.

Notera att när det gäller ämnen som att lägga till funktioner och ändra specifikationer, är det som mest oroar de som tar emot jobbet om det är lagligt att ändra uppskattade kostnader. Vi förklarar detta i detalj i en separat artikel.

https://monolith.law/corporate/increase-of-estimate[ja]

Ett ändringshanteringsdokument blir grunden för att bedöma rimligheten i innehållet i en ökad uppskattning när en sådan ökning görs efteråt. När du gör en begäran baserad på en ökad uppskattning senare, är det viktigt att skapa ett ändringshanteringsdokument för att undvika konflikter med den andra parten (och för att ge ditt argument övertygelse om det blir en konflikt).

Vad ska anges i ett ändringshanteringsdokument?

Så, vilka punkter bör lagligen anges i ett ändringshanteringsdokument? Kontraktssystemet som använder ändringshanteringsdokument för att svara på ändringar i specifikationer och tillägg av funktioner är redan allmänt erkänt. Därför, genom att kontrollera mallar för kontraktsklausuler som presenteras av myndigheter, som det japanska ministeriet för ekonomi, handel och industri, kan du få en allmän uppfattning om vilka punkter som bör registreras.

(Ändringshanteringsförfarande)
Artikel 37 Om A eller B mottar ett ändringsförslag baserat på artikel 34 (ändring av systemspecifikationsdokument etc.), artikel 35 (godkännande av mellanliggande material av användaren), artikel 36 (hantering av osäkra frågor), ska de inom X dagar från mottagningsdagen överlämna ett dokument (nedan kallat “ändringshanteringsdokument”) som anger följande punkter till den andra parten, och A och B ska diskutera godkännandet av denna ändring vid kommunikationskommittén som definieras i artikel 12.
① Namnet på ändringen
② Ansvarig för förslaget
③ Datum
④ Orsaken till ändringen
⑤ Detaljer om ändringen, inklusive specifikationer relaterade till ändringen
⑥ Om det finns kostnader för ändringen, dess belopp
⑦ Schema för ändringsarbetet, inklusive övervägningstiden
⑧ Andra effekter som ändringen har på detta kontrakt och individuella kontraktvillkor (arbetsperiod eller leveransdatum, avgifter, kontraktsklausuler etc.)

Om du läser texten direkt och bekräftar de rekommenderade punkterna att notera, behövs ingen ytterligare förklaring. För att undvika “sade-inte-sade” problem senare, bör du registrera detaljerna och den specifika processen för ändringen.

Genom att tydligt ange dessa punkter och inkludera signaturer eller stämplar från ansvariga och beslutsfattare från både leverantören och användaren, kommer det att ha samma betydelse som ett kontrakt som bevis, även om det skulle bli en rättegång.

Vad du bör veta om förändringshantering

Förändringshantering bör oftast utföras i kombination med uppgiftshantering

Skälet till att skapa ett dokument för förändringshantering är att genom att hantera förändringshistoriken kan du leda projektet till framgång (eller undvika orättvis ansvarsskyldighet om du inte kan leda det till framgång). För att uppnå dessa mål i praktiken skapas och uppdateras dokumentet för förändringshantering ofta i kombination med att skapa och uppdatera uppgiftshanteringstabellen. Med andra ord, när du har hanterat förändringshistoriken i förändringshanteringstabellen, kommer de överenskomna förändringspunkterna att införlivas i uppgiftshanteringstabellen som uppgifter att ta itu med i framtiden.

Det är bäst att också fastställa hur förändringsdiskussioner ska genomföras

Inte bara hur man hanterar förändringar, utan också hur man diskuterar förändringar bör regleras för att förvänta sig att förändringsåtgärder kommer att gå smidigt. Detta är särskilt viktigt när du använder utvecklingsmetoder som agil utveckling, där det förutsätts att olika förändringar kommer att göras efteråt. I praktiken finns det många exempel på att regler fastställs för när den andra parten bör svara på en begäran om diskussion om förändringshantering.

Förändringsdiskussioner och skyldigheten att agera i god tro

När båda parter har kommit överens om ett kontrakt och sedan vill ändra det, är det i princip som att ingå ett nytt kontrakt. Eftersom kontraktet baseras på parternas fria vilja, finns det i princip ingen skyldighet för leverantören att godkänna ändringskontraktet. Men om denna rättighet betonas för mycket, kan det finnas oro för att systemutvecklingsprojektet inte kommer att gå smidigt i praktiken.

Därför anges det ofta i kontrakt att det finns en “skyldighet att agera i god tro vid förändringsdiskussioner”, och det finns exempel på att om leverantören inte svarar ärligt på förändringen kan det bli möjligt att begära skadestånd.

Ett exempel på formuleringen är följande (nedan är ett exempel på en klausul, citerad från “ff Basic/Individual Contract Model Basic Contract Draft” officiellt skapat av den oberoende administrativa institutionen Information Processing Promotion Agency).

Artikel 4, paragraf 3 Vid förändringsdiskussioner ska båda parter ärligt diskutera om förändringen ska genomföras, efter att ha övervägt ämnet för förändringen, möjligheten till förändring, effekterna av förändringen på priset och leveranstiden, etc.

Bestämmelser om förändringsmetoder

Som nämnts ovan är det juridiskt “säkert” att hålla diskussioner om varje förändring när du gör en förändring. Men för mindre projekt kanske du inte behöver fastställa hur du ska genomföra förändringsdiskussioner. I sådana fall kan du överväga att istället för att ha bestämmelser om diskussioner, göra det så att förändringar endast görs när användarens och leverantörens ansvariga personer har signerat och stämplat förändringshanteringsdokumentet. Om du tillåter förändringar att göras lättvindigt bara genom muntligt samtycke, kan det bli oklart om förändringar har gjorts, vilket kan leda till stora problem senare. I det avseendet bör dokumenthantering vara noggrann.

Å andra sidan kan det vara en börda att förbereda separata dokument för varje förändringshantering, och du kanske vill prioritera flexibla åtgärder. I sådana fall kan det vara en lösning att dokumentera förändringsfrågor i mötesprotokollen. Hur man behåller mötesprotokoll i systemutveckling beskrivs mer detaljerat i följande artikel.

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

Sammanfattning

I miljöer där specifikationsändringar sker ofta, är det sant att det kan vara en risk för problem och konflikter. Men i sådana situationer där flexibilitet krävs, kan det ofta vara svårt att vidta praktiska åtgärder genom att bara betona “viktigheten av förvaltning” på ett strikt sätt.

Frågan om hur man ska balansera den hastighet som krävs i affärer och beredskapen för oväntade situationer varierar ofta beroende på företagets situation och projektets innehåll. Med tanke på innehållet i denna artikel, tror vi att det är viktigt att varje företag och projekt söker efter lämpliga metoder för sin situation.