Wat is de juiste manier om verandermanagement in systeemontwikkeling te benaderen vanuit een juridisch perspectief?

In systeemontwikkelingsprojecten komt het vaak voor dat gebruikers de inhoud die ze vooraf hebben uitgelegd, in de loop van het werk veranderen. Daarom kan het als leverancier die het werk aanneemt, nodig zijn om in te stemmen met wijzigingen in het contract dat eenmaal is gesloten.

In dit artikel leggen we uit hoe we moeten omgaan met het fenomeen ‘wijzigingen’ die achteraf worden gemaakt vanuit een juridisch perspectief op systeemontwikkelingsprojecten die niet altijd volgens plan verlopen.

Waarom worden systeemontwikkelingsprojecten ‘gewijzigd’ na voltooiing?

Systeemontwikkeling is een gezamenlijke inspanning van leveranciers en gebruikers

Systeemontwikkeling verloopt doorgaans via een plannings- en voorstelfase, waarin de vereisten voor de ontwikkeling worden gedefinieerd en een contract wordt gesloten. Na het sluiten van het contract worden verschillende ontwerpen doorlopen, wordt de implementatie volgens het ontwerp voltooid en wordt ten slotte een test uitgevoerd. In dit hele proces is het vanzelfsprekend dat de leverancier, die de opdracht aanneemt, een breed scala aan verantwoordelijkheden op zich neemt als expert in systeemontwikkeling. Echter, er wordt ook een bepaalde mate van medewerking van de gebruikerskant verwacht. In het bijzonder bij het identificeren van de functies die het te ontwikkelen systeem moet hebben (= vereisten definitie), het uiterlijk en de bediening van het scherm (= basisontwerp), en het controleren of het resultaat voldoet aan de vereisten (= testen of acceptatie), is de medewerking van de gebruikerskant van cruciaal belang. Voor een algemene uitleg over de verantwoordelijkheden van de gebruiker in systeemontwikkeling, zie het volgende artikel.

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

Hoewel er een verplichting tot samenwerking is, vragen gebruikers vaak om veranderingen

Echter, het is niet altijd het geval dat gebruikers, die geen experts zijn in systeemontwikkeling, altijd in staat zijn om de informatie die nodig is voor systeemontwikkeling volledig en uitgebreid aan de leverancier te verstrekken. In werkelijkheid, omdat het een gedetailleerd en nauwkeurig werk is, is het vaak moeilijk voor gebruikers om te voorspellen welke feiten een cruciale betekenis kunnen hebben in latere stadia. Ironisch genoeg, hoe belangrijker de feiten, hoe meer ze de neiging hebben om later in kleine hoeveelheden naar voren te komen. Vanwege deze omstandigheden, hoewel het ideaal is om “van stroomopwaarts naar stroomafwaarts in één keer” in een echt project, is het belangrijk om te overwegen hoe “verandermanagement” te implementeren onder de veronderstelling dat verschillende veranderingen kunnen worden gemaakt na het feit.

Wat is een wijzigingsbeheerdocument?

Wanneer wordt een wijzigingsbeheerdocument gebruikt?

Een wijzigingsbeheerdocument is een document dat een gebruiker gebruikt om een leverancier te vragen om specificaties te wijzigen of functies toe te voegen vanuit de inhoud die vooraf is uitgelegd. Zoals eerder vermeld, hebben gebruikers tijdens fasen zoals vereistenbepaling en basisontwerp de plicht om samen te werken met de taken van de leverancier, maar het is mogelijk dat er later verschillende verzoeken worden gedaan in de volgende processen.

Voorbeelden van situaties waarin een wijzigingsbeheerdocument nodig is, zijn bijvoorbeeld:

• Als er iets over het hoofd is gezien in de vereistenbepaling of het basisontwerp, en je vraagt om een functie toe te voegen na het feit
• Als er tijdens de ontwikkeling een herziening van het bedrijfsbeleid plaatsvindt en er een wijziging van de specificaties nodig is

Dit zijn enkele mogelijke scenario’s.

Wat betreft onderwerpen zoals het toevoegen van functies en het wijzigen van specificaties, wat de partij die het werk aanneemt het meest zal interesseren, is of het wettelijk is toegestaan om de geschatte kosten te wijzigen. We hebben dit punt in detail uitgelegd in een ander artikel.

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

Het wijzigingsbeheerdocument is de basis voor het beoordelen van de redelijkheid van de inhoud van de schatting bij het verhogen van de schatting na het feit. Het is belangrijk om een wijzigingsbeheerdocument op te stellen om ervoor te zorgen dat er geen geschillen ontstaan met de andere partij wanneer er kosten in rekening worden gebracht op basis van de verhoogde schatting (en om uw argumenten overtuigend te maken als er een geschil ontstaat).

Inhoud van het wijzigingsbeheerdocument

Wat zijn dan de zaken die wettelijk in een wijzigingsbeheerdocument moeten worden opgenomen? Het mechanisme van het contract om te reageren op specificatiewijzigingen en functietoevoegingen met behulp van een wijzigingsbeheerdocument is al algemeen bekend. Daarom, door het controleren van de sjablonen van contractclausules voorgesteld door overheidsinstanties, zoals het Ministerie van Economie, Handel en Industrie modelcontract, kunt u over het algemeen begrijpen welke zaken moeten worden vastgelegd.

(Wijzigingsbeheerprocedure)
Artikel 37 Als A of B een wijzigingsvoorsteldocument ontvangt van de andere partij op basis van artikel 34 (wijziging van systeemspecificatiedocumenten, enz.), artikel 35 (goedkeuring van tussentijdse documenten door de gebruiker), of artikel 36 (behandeling van onbepaalde zaken), zal hij/zij binnen X dagen na ontvangst van het document een schriftelijk document (hierna “wijzigingsbeheerdocument” genoemd) aan de andere partij overhandigen met de volgende zaken vermeld, en A en B zullen overleggen over de goedkeuring van de wijziging in de communicatievergadering zoals bepaald in artikel 12.
① Naam van de wijziging
② Verantwoordelijke voor het voorstel
③ Datum
④ Reden voor de wijziging
⑤ Details van de wijziging, inclusief de specificaties met betrekking tot de wijziging
⑥ Als er kosten nodig zijn voor de wijziging, het bedrag daarvan
⑦ Schema voor wijzigingswerk, inclusief de overwegingsperiode
⑧ Andere effecten van de wijziging op de voorwaarden van dit contract en individuele contracten (werkperiode of leveringsdatum, contractprijs, contractclausules, enz.)

Als je de tekst direct leest en de aanbevolen items controleert, heb je geen verdere uitleg nodig. Om later geen “Ik zei het, ik zei het niet” problemen te hebben, moet je de details en de specifieke omstandigheden van de wijziging vastleggen.

Door deze items duidelijk te vermelden en ze te combineren met de handtekening of het zegel van de verantwoordelijke of beslisser van zowel de leverancier als de gebruiker, krijgen ze dezelfde betekenis als een contract als bewijs, zelfs als er een rechtszaak zou ontstaan.

Wat u moet weten over verandermanagement

Verandermanagement wordt meestal uitgevoerd in combinatie met taakbeheer

De reden om een verandermanagementdocument te maken is om het project te leiden naar voltooiing door het beheren van de veranderingsgeschiedenis, of om ongerechtvaardigde verantwoordelijkheid te vermijden als het project niet kan worden voltooid. In de praktijk wordt het maken van een verandermanagementdocument vaak gedaan in combinatie met het maken en bijwerken van een taakbeheerlijst. Met andere woorden, zodra de veranderingsgeschiedenis wordt beheerd in de verandermanagementtabel, worden de overeengekomen veranderingen opgenomen als taken die in de toekomst moeten worden aangepakt in de taakbeheerlijst.

Het is beter om ook regels op te stellen voor hoe veranderingsdiscussies moeten worden gevoerd

Niet alleen de manier van verandermanagement, maar ook de manier van discussiëren over veranderingen moet worden geregeld om een soepele afhandeling van veranderingen te verwachten. Dit is vooral belangrijk bij het gebruik van ontwikkelingsmethoden zoals Agile ontwikkeling, waarbij er vanuit wordt gegaan dat er achteraf verschillende veranderingen zullen worden aangebracht. In de praktijk zijn er veel voorbeelden van regels die bepalen wanneer de andere partij moet reageren op een verzoek om een discussie over verandermanagement.

Veranderingsdiscussie en plicht tot oprechtheid

Als er een verandering wordt aangebracht in een contract waarover beide partijen het eens zijn geworden, is dit in feite het aangaan van een nieuw contract. In principe heeft de leverancier geen verplichting om in te stemmen met een wijzigingscontract, aangezien het contract is gebaseerd op de vrije wil van de partijen. Echter, als dit recht te veel wordt benadrukt, kan het zijn dat het systeemontwikkelingsproject niet soepel verloopt.

Daarom wordt er vaak in contracten vermeld dat er een “plicht tot oprechte deelname aan veranderingsdiscussies” is, en er zijn gevallen waarin er wordt vermeld dat er schadevergoeding kan worden geëist als de leverancier niet oprecht reageert op de verandering.

Een voorbeeld van een dergelijke vermelding is het volgende (hieronder is een voorbeeld van een clausule geciteerd uit de “Basis/Individuele Contract Model Basis Contract Draft” officieel gemaakt door de onafhankelijke administratieve instelling Information Processing Promotion Agency).

Artikel 4, lid 3: Bij veranderingsdiscussies zullen beide partijen oprecht overleggen over het onderwerp van de verandering, de mogelijkheid van verandering, de impact van de verandering op de prijs en de leveringstermijn, en of de verandering moet worden doorgevoerd.

Regels voor veranderingsmethoden

Zoals eerder vermeld, is het juridisch “veiliger” om bij elke verandering een discussie over de verandering te houden. Echter, in het geval van kleinere projecten, is het misschien niet nodig om regels op te stellen voor hoe veranderingsdiscussies moeten worden gevoerd. In dat geval kan men overwegen om in plaats van regels voor discussies op te stellen, de verandering pas door te voeren nadat de verantwoordelijken van de gebruiker en de leverancier hun handtekening of zegel op het verandermanagementdocument hebben gezet. Als veranderingen te gemakkelijk kunnen worden gemaakt door mondelinge overeenkomsten, kan het onduidelijk worden of er veranderingen zijn aangebracht, wat later tot grote problemen kan leiden. Daarom is het belangrijk om documentbeheer grondig uit te voeren.

Echter, het kan zijn dat het voorbereiden van aparte documenten voor elke verandering te belastend is en dat men flexibeler wil kunnen reageren. In dat geval kan men overwegen om veranderingskwesties te documenteren in de notulen van vergaderingen. Hoe men de notulen van vergaderingen in systeemontwikkeling moet bijhouden, wordt in detail uitgelegd in het volgende artikel.

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

Samenvatting

In omgevingen waar specificaties vaak veranderen, is er inderdaad vaak een risico op problemen en geschillen. Echter, in dergelijke situaties waar flexibiliteit vereist is, kan het benadrukken van het belang van ‘beheer’ op een rigide manier het moeilijk maken om praktische maatregelen te nemen.

Het probleem van het balanceren tussen de snelheid die van het bedrijfsleven wordt geëist en de voorbereiding op onvoorziene omstandigheden, kan variëren afhankelijk van de situatie van het bedrijf en de inhoud van het project. Rekening houdend met de inhoud van dit artikel, is het belangrijk dat elk bedrijf en elk project hun eigen geschikte aanpak zoekt.