{"id":61298,"date":"2023-12-08T19:16:12","date_gmt":"2023-12-08T10:16:12","guid":{"rendered":"https:\/\/monolith.law\/nl\/?p=61298"},"modified":"2024-03-14T03:37:02","modified_gmt":"2024-03-13T18:37:02","slug":"howto-manage-change-in-system-development","status":"publish","type":"post","link":"https:\/\/monolith.law\/nl\/it\/howto-manage-change-in-system-development","title":{"rendered":"Wat is de juiste manier om verandermanagement in systeemontwikkeling te benaderen vanuit een juridisch perspectief?"},"content":{"rendered":"\n<p>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.<\/p>\n\n\n\n<p>In dit artikel leggen we uit hoe we moeten omgaan met het fenomeen &#8216;wijzigingen&#8217; die achteraf worden gemaakt vanuit een juridisch perspectief op systeemontwikkelingsprojecten die niet altijd volgens plan verlopen.<\/p>\n\n\n\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_53 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<span class=\"ez-toc-title-toggle\"><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/monolith.law\/nl\/it\/howto-manage-change-in-system-development\/#Waarom_worden_systeemontwikkelingsprojecten_%E2%80%98gewijzigd%E2%80%99_na_voltooiing\" title=\"Waarom worden systeemontwikkelingsprojecten &#8216;gewijzigd&#8217; na voltooiing?\">Waarom worden systeemontwikkelingsprojecten &#8216;gewijzigd&#8217; na voltooiing?<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/monolith.law\/nl\/it\/howto-manage-change-in-system-development\/#Systeemontwikkeling_is_een_gezamenlijke_inspanning_van_leveranciers_en_gebruikers\" title=\"Systeemontwikkeling is een gezamenlijke inspanning van leveranciers en gebruikers\">Systeemontwikkeling is een gezamenlijke inspanning van leveranciers en gebruikers<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/monolith.law\/nl\/it\/howto-manage-change-in-system-development\/#Hoewel_er_een_verplichting_tot_samenwerking_is_vragen_gebruikers_vaak_om_veranderingen\" title=\"Hoewel er een verplichting tot samenwerking is, vragen gebruikers vaak om veranderingen\">Hoewel er een verplichting tot samenwerking is, vragen gebruikers vaak om veranderingen<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/monolith.law\/nl\/it\/howto-manage-change-in-system-development\/#Wat_is_een_wijzigingsbeheerdocument\" title=\"Wat is een wijzigingsbeheerdocument?\">Wat is een wijzigingsbeheerdocument?<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/monolith.law\/nl\/it\/howto-manage-change-in-system-development\/#Wanneer_wordt_een_wijzigingsbeheerdocument_gebruikt\" title=\"Wanneer wordt een wijzigingsbeheerdocument gebruikt?\">Wanneer wordt een wijzigingsbeheerdocument gebruikt?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/monolith.law\/nl\/it\/howto-manage-change-in-system-development\/#Inhoud_van_het_wijzigingsbeheerdocument\" title=\"Inhoud van het wijzigingsbeheerdocument\">Inhoud van het wijzigingsbeheerdocument<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/monolith.law\/nl\/it\/howto-manage-change-in-system-development\/#Wat_u_moet_weten_over_verandermanagement\" title=\"Wat u moet weten over verandermanagement\">Wat u moet weten over verandermanagement<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/monolith.law\/nl\/it\/howto-manage-change-in-system-development\/#Verandermanagement_wordt_meestal_uitgevoerd_in_combinatie_met_taakbeheer\" title=\"Verandermanagement wordt meestal uitgevoerd in combinatie met taakbeheer\">Verandermanagement wordt meestal uitgevoerd in combinatie met taakbeheer<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/monolith.law\/nl\/it\/howto-manage-change-in-system-development\/#Het_is_beter_om_ook_regels_op_te_stellen_voor_hoe_veranderingsdiscussies_moeten_worden_gevoerd\" title=\"Het is beter om ook regels op te stellen voor hoe veranderingsdiscussies moeten worden gevoerd\">Het is beter om ook regels op te stellen voor hoe veranderingsdiscussies moeten worden gevoerd<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/monolith.law\/nl\/it\/howto-manage-change-in-system-development\/#Veranderingsdiscussie_en_plicht_tot_oprechtheid\" title=\"Veranderingsdiscussie en plicht tot oprechtheid\">Veranderingsdiscussie en plicht tot oprechtheid<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/monolith.law\/nl\/it\/howto-manage-change-in-system-development\/#Regels_voor_veranderingsmethoden\" title=\"Regels voor veranderingsmethoden\">Regels voor veranderingsmethoden<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/monolith.law\/nl\/it\/howto-manage-change-in-system-development\/#Samenvatting\" title=\"Samenvatting\">Samenvatting<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Waarom_worden_systeemontwikkelingsprojecten_%E2%80%98gewijzigd%E2%80%99_na_voltooiing\"><\/span>Waarom worden systeemontwikkelingsprojecten &#8216;gewijzigd&#8217; na voltooiing?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Systeemontwikkeling_is_een_gezamenlijke_inspanning_van_leveranciers_en_gebruikers\"><\/span>Systeemontwikkeling is een gezamenlijke inspanning van leveranciers en gebruikers<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>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.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/user-obligatory-cooperation\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/user-obligatory-cooperation[ja]<\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hoewel_er_een_verplichting_tot_samenwerking_is_vragen_gebruikers_vaak_om_veranderingen\"><\/span>Hoewel er een verplichting tot samenwerking is, vragen gebruikers vaak om veranderingen<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>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 &#8220;van stroomopwaarts naar stroomafwaarts in \u00e9\u00e9n keer&#8221; in een echt project, is het belangrijk om te overwegen hoe &#8220;verandermanagement&#8221; te implementeren onder de veronderstelling dat verschillende veranderingen kunnen worden gemaakt na het feit.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Wat_is_een_wijzigingsbeheerdocument\"><\/span>Wat is een wijzigingsbeheerdocument?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith.law\/wp-content\/uploads\/2019\/07\/pixta_40395256_M-1024x682.jpg\" alt=\"\" class=\"wp-image-2910\" \/><figcaption class=\"wp-element-caption\">Hoe ga je om met &#8216;wijzigingsbeheer&#8217; dat zich voordoet tijdens systeemontwikkeling?<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Wanneer_wordt_een_wijzigingsbeheerdocument_gebruikt\"><\/span>Wanneer wordt een wijzigingsbeheerdocument gebruikt?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>Voorbeelden van situaties waarin een wijzigingsbeheerdocument nodig is, zijn bijvoorbeeld:<\/p>\n\n\n\n<ul>\n<li>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<\/li>\n\n\n\n<li>Als er tijdens de ontwikkeling een herziening van het bedrijfsbeleid plaatsvindt en er een wijziging van de specificaties nodig is<\/li>\n<\/ul>\n\n\n\n<p>Dit zijn enkele mogelijke scenario&#8217;s.<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/increase-of-estimate\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/increase-of-estimate[ja]<\/a><\/p>\n\n\n\n<p>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).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Inhoud_van_het_wijzigingsbeheerdocument\"><\/span>Inhoud van het wijzigingsbeheerdocument<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>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.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>(Wijzigingsbeheerprocedure)<br>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 &#8220;wijzigingsbeheerdocument&#8221; 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.<br> \u2460 Naam van de wijziging<br> \u2461 Verantwoordelijke voor het voorstel<br> \u2462 Datum<br> \u2463 Reden voor de wijziging<br> \u2464 Details van de wijziging, inclusief de specificaties met betrekking tot de wijziging<br> \u2465 Als er kosten nodig zijn voor de wijziging, het bedrag daarvan<br> \u2466 Schema voor wijzigingswerk, inclusief de overwegingsperiode<br> \u2467 Andere effecten van de wijziging op de voorwaarden van dit contract en individuele contracten (werkperiode of leveringsdatum, contractprijs, contractclausules, enz.)<\/p>\n<\/blockquote>\n\n\n\n<p>Als je de tekst direct leest en de aanbevolen items controleert, heb je geen verdere uitleg nodig. Om later geen &#8220;Ik zei het, ik zei het niet&#8221; problemen te hebben, moet je de details en de specifieke omstandigheden van de wijziging vastleggen.<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Wat_u_moet_weten_over_verandermanagement\"><\/span>Wat u moet weten over verandermanagement<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith.law\/wp-content\/uploads\/2019\/07\/pixta_54572310_M-1024x434.jpg\" alt=\"\" class=\"wp-image-2907\" \/><figcaption class=\"wp-element-caption\">Zodra een verandermanagementdocument is gemaakt, wordt dit ook weerspiegeld in de taakbeheerlijst.<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Verandermanagement_wordt_meestal_uitgevoerd_in_combinatie_met_taakbeheer\"><\/span>Verandermanagement wordt meestal uitgevoerd in combinatie met taakbeheer<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Het_is_beter_om_ook_regels_op_te_stellen_voor_hoe_veranderingsdiscussies_moeten_worden_gevoerd\"><\/span>Het is beter om ook regels op te stellen voor hoe veranderingsdiscussies moeten worden gevoerd<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Niet alleen de manier van verandermanagement, maar ook de manier van discussi\u00ebren 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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Veranderingsdiscussie_en_plicht_tot_oprechtheid\"><\/span>Veranderingsdiscussie en plicht tot oprechtheid<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>Daarom wordt er vaak in contracten vermeld dat er een &#8220;plicht tot oprechte deelname aan veranderingsdiscussies&#8221; is, en er zijn gevallen waarin er wordt vermeld dat er schadevergoeding kan worden ge\u00ebist als de leverancier niet oprecht reageert op de verandering.<\/p>\n\n\n\n<p>Een voorbeeld van een dergelijke vermelding is het volgende (hieronder is een voorbeeld van een clausule geciteerd uit de &#8220;Basis\/Individuele Contract Model Basis Contract Draft&#8221; officieel gemaakt door de onafhankelijke administratieve instelling Information Processing Promotion Agency).<\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>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.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Regels_voor_veranderingsmethoden\"><\/span>Regels voor veranderingsmethoden<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Zoals eerder vermeld, is het juridisch &#8220;veiliger&#8221; 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.<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/the-minutes-in-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/the-minutes-in-system-development[ja]<\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Samenvatting\"><\/span>Samenvatting<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>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 &#8216;beheer&#8217; op een rigide manier het moeilijk maken om praktische maatregelen te nemen.<\/p>\n\n\n\n<p>Het probleem van het balanceren tussen de snelheid die van het bedrijfsleven wordt ge\u00ebist en de voorbereiding op onvoorziene omstandigheden, kan vari\u00ebren 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.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>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, n [&hellip;]<\/p>\n","protected":false},"author":32,"featured_media":63289,"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\/nl\/wp-json\/wp\/v2\/posts\/61298"}],"collection":[{"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/comments?post=61298"}],"version-history":[{"count":2,"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/posts\/61298\/revisions"}],"predecessor-version":[{"id":63290,"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/posts\/61298\/revisions\/63290"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/media\/63289"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/media?parent=61298"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/categories?post=61298"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/tags?post=61298"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}