Vad är flerstegsavtal i systemutveckling? En förklaring inklusive skälen till varför det rekommenderas

I systemutvecklingsprojekt är det ofta så att kontraktspraxis drivs framåt med en metod som kallas flerstegskontrakt. I denna artikel kommer vi att förklara flerstegskontrakt inom systemutveckling, inklusive skälen till varför det rekommenderas.

Vad är flerstegsavtal?

Vanligtvis sker avtalsslutande genom ett kontrakt. Det vill säga, den part som betalar (användaren i systemutveckling) åtar sig att betala ersättning, och den part som tar emot jobbet (leverantören i systemutveckling) lovar att tillhandahålla motsvarande tjänster skriftligt. På detta sätt är det väsentliga i ett avtal att båda parter lovar att uppfylla sina åtaganden.

Slutgiltiga avtal baserade på naturen av varje process och slutför arbetet

Men i fallet med systemutvecklingsprojekt, är projektinnehållet självt något som fortskrider genom flera processer, och dess innehåll tenderar att bli komplicerat. Med tanke på denna typ av arbetskaraktär, kan det vara lämpligt att även avtalet genomförs i flera steg. Med andra ord, det är bättre att strukturellt sammanställa idéer och skapa själva kontraktet som hanterar hela projektet. Till exempel, det är mycket föredraget i praktiken att förnya kontraktet för varje process. Denna typ av kontraktsmetod kallas också för flerstegsavtal. Modellkontraktet som tillhandahålls av det japanska ministeriet för ekonomi, handel och industri (経済産業省) är också baserat på dessa flerstegsavtal.

Typer av kontrakt som ingås i varje projekt

I systemutveckling används ofta två typer av kontrakt, entreprenadkontrakt och konsultkontrakt. Beroende på karaktären av varje steg i processen, används dessa två kontraktstyper omväxlande för att hantera hela projektet. Till exempel, i systemutvecklingsprocessen är det vanligt att använda entreprenadkontrakt för detaljerad design, programimplementering och enhetstestning. Anledningen till att dessa steg passar bra med entreprenadkontrakt är att de betonar “slutförandet av arbetet” som ett krav för att uppfylla skulden, och det är lätt att konkretisera kravet på “slutförande” i dessa steg. För mer detaljerad information om “slutförandet av arbetet” i entreprenadkontrakt, se följande artikel.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Å andra sidan, i de tidiga stadierna av systemutveckling, som planering och kravdefinition, tenderar konsultkontrakt att användas ofta. Karaktären av dessa steg är att det ofta är svårt att klargöra kravet på “slutförandet av arbetet”, och att kontraktet ofta baseras på en förtroenderelation mellan parterna. I steg som grundläggande design och integrationstestning kan antingen konsult- eller entreprenadkontrakt användas beroende på projektets karaktär. En viktig punkt att överväga när man väljer vilket kontrakt som ska användas i dessa steg är hur mycket samarbete som krävs från användaren.

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

Om det är en typ av arbete där leverantören ensidigt kräver “slutförandet av arbetet” som en skuld, kan det vara enklare att välja ett entreprenadkontrakt. Men om det i praktiken är nödvändigt med ett gemensamt arbete mellan användaren och leverantören, kan det vara mer realistiskt att ge juridiskt skydd till den relation som bygger på ömsesidigt förtroende. För mer information om skillnaderna mellan entreprenadkontrakt och konsultkontrakt, se följande artikel.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

I denna artikel förklaras det att entreprenadkontrakt tenderar att användas mer för saker som programimplementering, där det är lätt att specifikt identifiera resultatet, och att konsultkontrakt tenderar att användas mer för saker där denna tendens är mindre. På detta sätt ses hela projektet som en helhet av entreprenadkontrakt och konsultkontrakt som ingås över flera steg, vilket är kännetecknande för kontraktspraxis baserad på flerstegskontrakt. Dessutom kan man säga att ett “grundkontrakt” är något som sammanfattar gemensamma punkter så att man inte behöver upprepa samma saker om och om igen. Detta liknar mycket att samla gemensamma element i klasser eller funktioner vid programimplementering.

Exempel på saker som ofta skrivs samman i ett grundkontrakt inkluderar:

• Definitioner av termer som används om och om igen
• Metoden för att ingå individuella kontrakt
• Metoden för att ändra specifikationer som ska realiseras i efterhand
• Metoden för leverans och godkännande av resultat för varje steg
• Hur sekretess ska hanteras

Dessa egenskaper är konsekventa och samma innehåll, oavsett om kontrakten är separerade steg för steg, eftersom de är en del av ett sammanhängande projekt. På detta sätt extraheras mer generella och universella överenskommelser som grundkontrakt, och saker som bör bestämmas individuellt för varje steg placeras under grundkontraktet som individuella kontrakt. Detta är kännetecknande för flerstegskontrakt. Flerstegskontrakt används ofta inte bara i systemutveckling, utan också i affärstransaktioner som kännetecknas av stor skala och komplexitet. Det motsatta konceptet till flerstegskontrakt med denna komplexa struktur är enstaka kontrakt. Om ämnet inte var systemutveckling, utan att beställa en skräddarsydd kostym, skulle ett enstaka kontrakt vanligtvis vara tillräckligt.

Fördelarna med flerstegsavtal

Så, vad är fördelarna med att medvetet välja att använda flerstegsavtal? Om vi organiserar detta lite mer konkret, kan vi nämna följande fördelar.

Fördel 1 med flerstegsavtal: Hanterar lättare rörligheten i utvecklingsprojekt

En av fördelarna med flerstegsavtal är att det är relativt enkelt att hantera rörligheten i utvecklingsprojekt. Normalt sett går en serie systemutvecklingsprojekt framåt med design och programimplementering enligt fördefinierade krav, och processen fortskrider i ett svep utan fram- och tillbakagång eller återgång. Men på grund av komplexiteten i det som skapas, sträcker sig tidsramen normalt över en lämplig period, och det är inte ovanligt att innehållet i specifikationerna som ska realiseras ändras efteråt. För mer information om hur man hanterar ändringsförfrågningar efter specifikationsändringar, se följande artikel.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Med andra ord, vid starten av projektet är det slutliga målet inte nödvändigtvis klart. Särskilt i projekt som innehåller sådana osäkra element kan det vara svårt att lova alla skyldigheter på en gång vid kontraktstidpunkten. Det är lättare att dela upp det i varje steg, vilket undviker onödiga risker för båda parter och gör det också lättare att smidigt driva affärstransaktioner.

Fördel 2 med flerstegsavtal: Lättare att göra korrekta kostnadsförslag

Den ovan nämnda fördelen, att “man kan undvika att göra bindande åtaganden för osäkra saker”, leder också till att man kan göra mer exakta kostnadsförslag. Om specifikationerna ändras efteråt, kan det mycket väl vara nödvändigt att ändra kostnadsförslaget efteråt. För mer information om hur man omberäknar kostnadsförslag i sådana fall, se följande artikel.

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

Även om tankesättet kring ändringar i kostnadsförslag på grund av efterföljande specifikationsändringar är som beskrivet i ovanstående artikel, är det inte särskilt önskvärt för både användare och leverantörer att behöva hantera sådana ändringar efteråt. Det är bäst att inte göra ett kostnadsförslag som behöver korrigeras från början, utan att göra det korrekt på en gång. Med flerstegsavtal kan man förvänta sig att det blir lättare att göra korrekta kostnadsförslag för varje steg, och att det blir mindre sannolikt att kostnadsförslag ändras efteråt.

Fördel 3 med flerstegsavtal: Lättare för den betalande parten att förstå rimligheten i beloppet

Dessutom, genom att dela upp kostnadsförslaget i varje steg, blir det lättare för användaren, som betalar ersättningen, att förstå rimligheten i beloppet för hela projektet. Som nämnt tidigare är det inte alls enkelt att närma sig en serie projekt med perfekt planering. Därför är det ofta så att man går igenom olika ändringar och även ändrar det ursprungliga kostnadsförslaget. I ett engångsavtal antas möjligheten att förklara kostnadsförslaget endast vid kontraktstidpunkten. För användaren kan det vara svårt att förstå varför det finns en skillnad mellan det ursprungliga kostnadsförslaget och det faktiska betalningsbeloppet vid betalningstidpunkten. Med detta i åtanke kan man säga att flerstegsavtal också har vissa fördelar för användaren.

Sammanfattning

Flernivåavtal är lämpliga för att forma en rättvis och tydlig överenskommelse mellan parterna och är också effektiva för att förebygga framtida problem. Dock kan det finnas de som undrar om det finns några nackdelar med flernivåavtal och om det i vissa fall kan vara bättre med individuella avtal. I detta avseende kan man säga att om verksamheten är liten och det är uppenbart att den kommer att slutföras snabbt, kan det vara lämpligt med ett samlingsavtal på grund av det extra arbete som krävs för att ingå ett avtal varje gång. Men snarare än att fokusera på de mycket begränsade nackdelarna med flernivåavtal, är det viktigare att fullt ut förstå fördelarna med denna noggranna och förändringsresistenta metod. För projekt av en viss storlek bör denna metod användas som en självklarhet.