Rewind: april 2011

Raakvlakmanagement

Database helpt bij afstemming deelcontracten in groot project

Door: Frits Couwenberg (frits.couwenberg@movares.nl). Senior consultant bij ingenieursbureau Movares. Hij was de afgelopen tien jaar raakvlakmanager bij diverse projecten waaronder de HSL-Zuid, de Portugese Hogesnelheidslijnen, de Hoekse Lijn en de RijnGouwelijn-Oost.


Figuur 1: De contracten voor het gedeelte Gouda- Alphen van de RijnCouwelijn

Waarom projecten opknippen?

De verdeling van een project over meerdere contracten wordt vooral toegepast als:

● het project een lange doorlooptijd heeft en tussentijds inzetbare delen kunnen worden opgeleverd (zo kan het gedeelte Gouda-Alphen al in gebruik worden genomen terwijl het deel vanaf Alphen richting Leiden nog niet gereed is);

● het project specifieke onderdelen kent waarvoor een bepaald type aannemer nodig is (beveiligingssystemen of de afbouw van de haltes);

● het project te groot is om bij één aannemerspartij neer te leggen (het aantal mogelijke aannemers neemt af naarmate de omvang van het project toeneemt);

● de eisen aan de latere onderdelen nog niet beschikbaar zijn (de eisen aan de afbouw van de haltes zijn nog niet definitief, terwijl de ruwbouw van een aantal perrons al in uitvoering is).

Het opknippen van grote infraprojecten in meerdere uitvoeringscontracten brengt het risico met zich mee dat de projectdelen vervolgens niet goed op elkaar aansluiten. De opdrachtgever of manager van het projectconsortium is er verantwoordelijk voor dat die aansluitingen wel goed zijn. Hij dient de verschillende contractpartijen elk zo aan te sturen dat zij de werkzaamheden op de raakvlakken van hun projectdelen goed op elkaar afstemmen, zodat het integrale projectresultaat conform de afspraken gerealiseerd wordt. Met de inzet van raakvlakmanagement kunnen deze risico’s op aansluitingsproblemen en daarmee projectvertraging, extra kosten en verlies aan projectperformance verminderd en beheerst worden. Ingenieursbureau Movares heeft hiervoor een aanpak en gereedschap ontwikkeld.

Veel grote infraprojecten, zoals de lightrailverbinding RijnGouwelijn-Oost, worden opgeknipt in een aantal kleinere contracten. Redenen daarvoor zijn bijvoorbeeld de noodzaak of wenselijkheid om alvast een deel van het projectresultaat in gebruik te nemen of specifieke projectonderdelen die door gespecialiseerde firma’s gerealiseerd moeten worden (zie verder kader 1). Hierdoor ontstaan binnen het project interne raakvlakken, waarbij per raakvlak twee contractpartijen betrokken zijn. Daarnaast vormen zich externe technische raakvlakken tussen de projectdelen en de omgeving. In dit artikel ga ik eerst in op de projectrisico’s die ontstaan door het opknippen van een project in meerdere contracten en hoe deze beheerst kunnen worden door raakvlakmanagement. Vervolgens beschrijf ik aan de hand van voorbeelden uit het project RijnGouwelijn-Oost hoe de raakvlakken geïdentificeerd en de raakvlakeisen geformuleerd en beheerst kunnen worden. Hiertoe is binnen ingenieursbureau Movares een Raakvlak Database ontwikkeld met gegevens over verschillende raakvlakken en het aantal en de ernst van de risico’s die zich daarop kunnen voordoen. Deze Raakvlak Database (Interface Database) kan eenvoudig ook bij andere projecten worden ingezet (zie kader 2).

Grote risico’s bij opknippen

Bij het opknippen van grote projecten (met name in design&construct-contracten,) kan het volgende fout gaan:

  • Het knippen blijkt op een verkeerde plaats te zijn gedaan, waardoor complexe deelprojecten ontstaan waarvan de raakvlakken met andere deelprojecten moeilijk te realiseren en te testen zijn.
  • De projectdelen zijn vóór de contractering niet of onvoldoende uitgewerkt op de raakvlakken met andere deelprojecten. Dit leidt tijdens integratietesten vaak tot extra werk en soms zelfs tot een gedeeltelijk herontwerp.
  • Een wijziging in één contract leidt tot wijzigingen in andere contracten. Als dat niet tijdig wordt onderkend kunnen andere contracten pas in een laat stadium alsnog worden aangepast.
  • In de deelcontracten wordt niet duidelijk aangegeven dat de aannemers geacht worden samen te werken aan de raakvlakken en deze gezamenlijk te testen. Vaak blijkt dan pas tegen het einde van het project dat dit alsnog nodig is.


Telkens leiden deze problemen tot een grote kans op vertraging, extra kosten en mindere kwaliteit/performance van het totale project. Zo ontstond bij de afstemming van twee contracten binnen het project HSL-Zuid verschil van mening tussen de aannemers over de planning van hun deel van de onderbouw. Dit had uiteindelijk tot gevolg dat de opdrachtgever extra kosten kreeg toegeschoven omdat die afstemming tussen de aannemers niet van tevoren was opgelegd. Kortom, raakvlakproblemen vormen een ernstige bedreiging voor de aansturing en de kwaliteit van het project als geheel. Het is dan ook van cruciaal belang om de risico’s op deze problemen beheersbaar te maken door het managen van de raakvlakken.

Figuur 2: Deel van de N2-matrix met de raakvlakken tussen de contracten C11 en C2A

Risicobeheersing

Zoals gezegd, leidt iedere knip in het project tot raakvlakken. De opdrachtgever en stakeholders stellen echter geen eisen aan die raakvlakken zolang deze niet van invloed zijn op de invulling van hun klanteisen. Er worden hooguit wat eisen gesteld aan de raakvlakken met de omgeving. Toch moeten die eisen gesteld worden, zowel ‘projectintern’ (tussen de diverse contracten binnen het project) als ‘projectextern’ (tussen het project en de omgeving). Het is belangrijk om zich hierbij te blijven realiseren dat de raakvlakken hofleveranciers zijn van projectrisico’s. Met name de eis dat de prestaties van het project over de raakvlakken heen (bij een nieuwe spoorlijn voorbeeld de totale reistijd tussen begin- en eindpunt) niet worden beperkt door de tussenliggende contractgrenzen, is lastig en leidt tot diverse projectrisico’s. Naast een nauwkeurige omschrijving van de inhoud van elk contract dient voor elke aannemer dan ook zorgvuldig te worden vastgelegd aan welke raakvlakeisen hij dient te voldoen. Alleen op die manier kan de aansluiting van dat contract met de overige contracten vlekkeloos werken.

De opdrachtgever en zijn ingenieursbureau dienen daarom de beheersing van de raakvlakken zorgvuldig in te richten. Dat houdt in dat aan opdrachtgeverzijde iemand binnen het project verantwoordelijk moet zijn voor het aansturen van het proces rond de raakvlakken: de raakvlakmanager. Deze stelt een raakvlakplan op, draagt bij aan het contracteringsplan en heeft tools voor de beheersing van de raakvlakken tijdens de gehele doorlooptijd van het project. Ook wordt hij ingeschakeld bij wijzigingsvoorstellen, want een wijziging in één contract kan immers leiden tot wijzigingen in een aantal van de andere contracten.

RijnGouwelijn-Oost

De eerste fase van de RijnGouwelijn-Oost (RGL-O) loopt van NS-station Gouda tot en met Alphen aan den Rijn. De tramlijn krijgt op die route acht haltes in Gouda, Waddinxveen, Boskoop en Alphen. Opdrachtgever voor dit project is de Provincie Zuid-Holland die het ontwerp en de realisatie van de infra op het gedeelte Gouda-Alphen (bestaand spoor) heeft opgedragen aan ProRail, met ondersteuning vanuit ingenieursbureau Movares.


Het grootste deel van het project wordt gerealiseerd met design & construct-contracten, waarbij de aannemers dus relatief grote vrijheden hebben in de wijze waarop ze aan de gestelde eisen voldoen. Binnen deze fase van de RijGouwelijn werden een aantal contracten gedefinieerd, zoals in figuur 1 is geschetst. In het project wordt intensief met Systems Engineering gewerkt, maar ook voor anders aangepakt projecten blijft het managen van de raakvlakken vergelijkbaar een risicovol.


Managen van raakvlakken

In het project RijnGouwelijn worden, net als bij andere projecten, een groot aantal eisen geformuleerd. Per aan te besteden contract is een deelverzameling van die eisen van toepassing. In eerste instantie zijn hier geen raakvlakeisen bij, omdat die pas bepaald kunnen worden als er een opdeling in contracten is. Die raakvlakeisen hebben dan steeds betrekking op twee verschillende contracten die via het raakvlak van elkaar afhankelijk zijn.


Zodra er meer dan twee contracten of een groter aantal systemen of objecten zijn, is het handmatig actueel houden van de raakvlakeisen niet goed meer mogelijk. Daarom is binnen Movares een Raakvlak Database ontwikkeld door systems engineeringdeskundige Hans Ekelmans, met ondersteuning door Marcel van de Ven, Arjen Boon en Jantine Westerhuis. Hierin kunnen vanuit een algemene formulering van ieder raakvlak (bijvoorbeeld ‘De bovenleiding in het eerste contract dient vlekkeloos aan te sluiten op die in het tweede contract’) de verplichtingen van beide raakvlakpartijen worden opgesteld. Vanuit deze verplichtingen worden dan SMART-geformuleerde eisen per contract gedefinieerd.


Bij het opstellen van de raakvlakeisen zijn twee zaken cruciaal: álle raakvlakken dienen te worden geïdentificeerd en de eisen dienen zo te worden geformuleerd dat de eerste aannemer al aan ‘zijn helft’ van de raakvlakken kan voldoen nog voordat er een tweede partij is.

Frits Couwenberg


Met de inzet van een raakvlakmanager die gebruikmaakt van de Raakvlak Database en de bijbehorende Interface control Forms kunnen raakvlakken op een gestructureerde wijze geïdentificeerd worden en kunnen raakvlakeisen geformuleerd en beheerst worden.

Raakvlak matrices

Voor het compleet krijgen van alle raakvlakken wordt uitgegaan van een objectenboom per contract (steeds afgeleid uit de overall objectenboom voor het project). Verder wordt gebruikgemaakt van zogenoemde ‘raakvlakmatrices’ ofwel ‘N2-matrices’. Daarin staan langs de horizontale en verticale as de objectenbomen van twee elkaar rakende contracten. In elke cel van zo’n matrix wordt aangegeven of twee objecten met elkaar een raakvlak hebben en is een identificatienummer van dat raakvlak opgenomen. In figuur 2 is een deel van zo’n raakvlakmatrix afgebeeld.


Het invullen van zo’n raakvlakmatrix gebeurt op basis van kennis en ervaring van zowel specialisten van de klant als onze eigen deskundigen. Als afgeleide van de raakvlakmatrices wordt voor elke raakvlakeis allereerst in gewoon Nederlands geformuleerd wat er op dat raakvlak moet gebeuren. Bijvoorbeeld: “De locaties van de funderingen van de geluidsschermen tussen Gouda en Alphen dienen te worden afgestemd met de kabels en leidingen die opgenomen zijn in het beveiligingscontract tussen Gouda en Alphen”. Daaruit worden voor de beide raakvlakpartijen (in gewoon Nederlands geformuleerde) verplichtingen afgeleid, zoals: “De aannemer voor de geluidsschermen moet bij de plaatsing van de funderingen een afstand van minimaal Y meter vanaf het spoor vrijhouden”. En de aannemer van de beveiliging heeft als verplichting “om zijn kabels niet verder dan Y meter uit het spoor te leggen”.


Derde stap is het SMART-formuleren van de eisen die deel uit gaan maken van de contracten met de aannemers. In het contract voor de geluidsschermen zal worden opgenomen dat: “De funderingen van de geluidsschermen binnen een strook van Y tot Z meter uit het hart van het naastgelegen spoor gerealiseerd dienen te worden.” In het beveiligingscontract zal worden opgenomen: “De kabels en leidingen in de lengterichting van het spoor dienen binnen een zone tussen X en Y meter uit het hart van het dichtstbijzijnde spoor te worden gelegd.”


Op deze manier worden de raakvlakeisen ‘ontkoppeld’ zodat beide aannemers hun eigen deel kunnen realiseren en ze samen tot een werkend raakvlak komen. Een dergelijke ontkoppeling van eisen blijkt ook uit de eisen aan de raakvlakken in de lengterichting van het spoor. Daar wordt bijvoorbeeld van de eerste aannemer gevraagd om de nieuwe bovenleiding te bouwen tot aan kilometer X en daar een tijdelijke afspanning te realiseren. Van de tweede aannemer wordt gevraagd om vanaf kilometer X te bouwen, waarbij hij moet aansluiten op de reeds aanwezige bovenleiding en de tijdelijke afspanning moet verwijderen. Op die manier wordt voorkomen dat door bijvoorbeeld geringe verschillen in de hoogte van

de bovenleiding bij kilometer X een sprongetje in de bovenleiding komt.


Complexe raakvlakken

Bij meer complexe raakvlakken, zoals de koppeling van twee beveiligingssystemen, is een dergelijke aanpak niet mogelijk. Dan dienen de aannemers samen de invulling van het raakvlak uit te werken. Zij spreken wie welk deel van dat raakvlak realiseert, hoe elk deel getest kan worden en hoe beide delen samen worden getest. Ook moet worden afgesproken hoe aangetoond wordt dat het raakvlak niet leidt tot een lagere prestatie van het totale project. Als de tweede partij nog niet gekozen is, dient diens rol tijdelijk ingevuld te worden door een vertegenwoordiger van de opdrachtgever.


Dat proces wordt geleid door de raakvlakmanager, namens de opdrachtgever. Hij kan dan de prestatie van het raakvlak bewaken en waar nodig besluiten nemen over de juiste uitwerkingsrichting. Bij de uitwerking van complexe raakvlakken wordt gebruikgemaakt van een zogenoemd Interface Control Form (ICF). Hierin is opgenomen welke informatie en documenten opgesteld en uitgewerkt moeten worden. Ook kan daarin worden vastgelegd hoe de interface stapsgewijs wordt getoetst. Verder wordt op dat formulier de voortgang van het raakvlakontwerp gevolgd en bevestigen beide raakvlakpartijen schriftelijk dat een bepaalde ontwerpstap succesvol is uitgevoerd. Een deel van de informatie op het ICF is afkomstig uit de Raakvlak Database, waarin een link is opgenomen naar het ICF (zie figuur 3).

Raakvlak database

De Raakvlak Database heeft als startpunt de objectenboom van het gehele project en de opleiding van die objecten naar de contracten. Hiermee ontstaat voor elk contract een specifieke deelobjectenboom. De indeling van de objecten naar contracten kan in de database snel en eenvoudig worden gewijzigd, waarmee dan meteen de bijbehorende raakvlakken worden aangepast.


Uit de Raakvlak Database kunnen de volgende zaken worden geëxporteerd:

  • De raakvlakmatrices per twee contracten (zie figuur 2), waarin is aangegeven welk object in het ene contract een raakvlak heeft met het andere. Dit is meteen ook een andere manier om de raakvlakken tussen twee contracten duidelijk te maken: door het plaatsen van een kruisje wordt een raakvlakdefinitie opgestart.
  • Raakvlakoverzichten per contract, waarin zichtbaar is met welke andere contracten er raakvlakken zijn en welke eisen daaraan gesteld worden (zowel in gewoon Nederlands als met een verwijzing naar de SMART-geformuleerde eisen in PKM Relatics).
  • De volledige objectenboom van alle contracten samen.
  • Links naar de Raakvlak Control Forms.
  • Links naar de SMART-eisen in de contracten.

Indien er in de loop van het project wijzigingen ontstaan, kan met behulp van de Raakvlak Database snel worden bepaald op welke andere contracten dit eventueel invloed heeft. Die wijzigingen kunnen vervolgens eenvoudig worden verwerkt.

Figuur 3: Het Interface Control Form

Gereedschap voor raakvlakmanagement

Ten behoeve van het raakvlakmanagement is bij Movares een tool ontwikkeld waarmee de raakvlakken op gestructureerde wijze geïdentificeerd, geformuleerd en beheerst kunnen worden. De essentie van de tool is een database, met behulp waarvan zowel de projectinterne als projectexterne raakvlakken van contracten gemanaged kunnen worden en desgewenst ook de raakvlakken tussen meerdere projecten.

In de Raakvlak Database wordt aangegeven welke objecten deel uitmaken van het project (of de projecten), hoe per contract de objectenboom eruitziet en welke objecten elkaar raken (fysiek en/of functioneel). Verder is opgenomen welke objecteisen aan weerszijde van de raakvlakken gesteld worden en hoe deze geverifieerd dienen te worden.

Tot de uitvoer van deze database behoren overzichten van de objectenbomen per contract, zogenoemde N2-matrixen (schema’s in spreadsheetvorm waarin zichtbaar is welke objecten elkaar raken), raakvlakoverzichten per contract en de eisen per raakvlak. Ook bevat de database gegevens voor het bijhouden van de voortgang in ontwerp, uitvoering en test van de raakvlakken.

Door de schematische en flexibele opbouw van dit gereedschap kunnen snel wijzigingen worden doorgevoerd. Bijvoorbeeld als besloten wordt om een klein contract onder te brengen in een groter contract of als eenniet eerder onderkend raakvlak alsnog wordt toegevoegd.


Conclusie

Met de inzet van een raakvlakmanager die gebruikmaakt van de Raakvlak Database en bijbehorende Interface Control Forms kunnen raakvlakken op een gestructureerde wijze geïdentificeerd worden en kunnen raakvlakeisen geformuleerd en beheerst worden. Dit komt tot uiting in:

● een optimaal contracteringsplan;

● betere contractstukken;

● de zekerheid van goed ontworpen interfaces;

● een betere integraliteit van het project;

● tijdwinst tijdens de uitvoering;

● beheersing van de faseverschillen tussen contracten;

● succesvolle integratietesten.

Op deze manier wordt een stevige grip verkregen op zowel de projectinterne als projectexterne raakvlakken, waardoor het aantal en de impact van de raakvlakrisico’s sterk gereduceerd wordt. De Raakvlak Database kan ook voor andere projecten snel worden ingezet en is flexibel aan te passen aan wijzigingen in de contractstructuur binnen het project.

Volgende artikel: Column