Wat IT-leveranciers kunnen leren van een geschil over trams

Op 22 juli 2026 deed de Rechtbank Den Haag uitspraak in een omvangrijk geschil tussen HTM en Siemens Mobility. Siemens had op grond van een in 2011 gesloten overeenkomst uiteindelijk 70 trams aan HTM geleverd. Jaren later ontstond discussie over onder meer de classificatie van storingen, de daarvoor verschuldigde boetes en vertraging bij het herstel van corrosie. Voor de IT-contractenpraktijk is vooral interessant waarom partijen tegenover elkaar kwamen te staan.

Onduidelijke KPI- en SLA-definitie

In de overeenkomst waren drie typen storingen gedefinieerd:

• A-storing: "wagen niet meer rijdbaar";
• B-storing: "wagen rijdbaar tot einde rit of einde dienst met passagiers";
• C-storing: "wagen na de dienst in de werkplaats verhelpen".

Aan die categorieën waren verschillende contractuele boetes verbonden. Het probleem: partijen bleken fundamenteel anders te denken over wat die definities precies betekenden. HTM legde de nadruk op de inzetbaarheid voor het vervoer van passagiers. Siemens koos voor een meer technische benadering en keek naar technische functie-uitval tijdens een rit.

De parallel met SLA's
Wie IT-contracten opstelt, herkent dit onmiddellijk. Denk aan een SLA waarin staat: "P1 Critical Incident: systeem niet beschikbaar."

Dat lijkt duidelijk, totdat zich een incident voordoet. Is een applicatie "niet beschikbaar" als gebruikers nog kunnen inloggen maar de checkout niet werkt? Als één bedrijfskritisch proces stilligt? Als een workaround bestaat? Of alleen bij volledige technische uitval? Dat is vrijwel dezelfde discussie als "wagen niet meer rijdbaar".

De belangrijke les is daarom dat een SLA niet alleen moet bepalen welke categorieën incidenten bestaan, maar ook:

• Vanuit welk perspectief de ernst wordt bepaald;
• Welke functionaliteit relevant is;
• Wat het meetmoment is;
• Welke uitzonderingen gelden;
• Welke operationele gevolgen tot welke classificatie leiden.

Het verschil tussen technische beschikbaarheid en bedrijfsmatige inzetbaarheid verdient daarbij bijzondere aandacht.

Een technisch document wijzigt niet vanzelf een IT-overeenkomst 

Een tweede interessante kwestie ging over een later "Design Freeze"-document.

Siemens stelde dat de oorspronkelijke storingsdefinities daarmee in 2014 waren vervangen. De rechtbank gaat daar niet in mee. Uit de ondertekening van de Design Freeze bleek volgens de rechtbank niet dat partijen wilsovereenstemming hadden bereikt over nieuwe storingsdefinities. De oorspronkelijke definities bleven dus gelden. Het latere Bergingsconcept mocht wel worden gebruikt bij de uitleg daarvan.

Opnieuw opvallende parallel met IT
Bij IT-projecten bestaat de contractuele werkelijkheid zelden uit één document. Er zijn bijvoorbeeld:

• De hoofdovereenkomst;
• Een statement of work;
• Requirements;
• Functionele en technische ontwerpen;
• Backlog-items;
• Change requests;
• Acceptatiedocumentatie;
• Verslagen van stuurgroepen;
• E-mails;
• Een solution design.

Gaandeweg kan de feitelijke oplossing steeds verder afwijken van wat oorspronkelijk is gecontracteerd. Maar een gewijzigd ontwerp betekent niet automatisch dat ook de contractuele verplichting is gewijzigd. Dat onderscheid is essentieel. Een solution design kan uitstekend bewijs opleveren voor de wijze waarop partijen een requirement begrepen. Daaruit volgt nog niet zonder meer dat partijen die oorspronkelijke requirement ook juridisch hebben gewijzigd.

Praktijktip
Maak daarom expliciet welke documenten de overeenkomst daadwerkelijk kunnen wijzigen. Bijvoorbeeld door te bepalen dat een wijziging pas contractueel effect heeft wanneer deze overeenkomstig een afgesproken change-procedure door bevoegde vertegenwoordigers van beide partijen is goedgekeurd. Anders ontstaat jaren later de vraag die hier ook speelde: “hebben we het contract gewijzigd, of hebben we alleen nader beschreven hoe het contract wordt uitgevoerd?”.

Contractdocumenten moet je in samenhang lezen

In deze kwestie waren de definities in de SLA van de verschillende prioriteiten opvallend kort. Zo was bijvoorbeeld één begrip gedefinieerd als: “A-storing: wagen niet meer rijdbaar”. De rechtbank moest daarop dit begrip verder uitleggen.

De rechtbank kijkt daarbij niet geïsoleerd naar één definitie of één document. Zij betrekt verschillende contractstukken bij haar uitleg en sluit uiteindelijk zelfs aan bij externe VDV-definities. Daarbij speelt mee dat de oorspronkelijke definities zeer summier waren. De stap van summiere definities naar een extern document lijkt bij eerste lezing overigens opvallend; zeker ook nu de rechtbank zelf vaststelt dat aanbestede documenten letterlijk en contra preferentem moeten worden gelezen. Wat hier echter lijkt mee te wegen is dat juist uit andere documenten lijkt te volgen dat de (wel erg) compacte definities hun inspiratie lijken te hebben gevonden in die externe VDD-definities. Ook het later door Siemens opgestelde Bergingsconcept speelt een rol, omdat de daarin gebruikte definities aansluiten bij de door de rechtbank gekozen uitleg.

Dat is voor IT-contracten een waarschuwing tegen het klakkeloos kopiëren van definities, KPI's en requirements naar verschillende bijlagen. Een begrip als "Availability", "Incident", "Defect", "Severity 1" of "Acceptance Criterion" komt gemakkelijk in vijf documenten terug, soms net anders geformuleerd. Hoe langer een project duurt, hoe groter vervolgens het risico dat die documenten ieder voor zich een plausibel verhaal vertellen, maar gezamenlijk geen eenduidig contract meer vormen.

Dit maakt ook dat een rangordebepaling of een hiërarchiebepaling uiteindelijk zeker geen loze ‘boiler plate’ is te noemen. Als het erop aan komt, dan kan een rangorde heel bepalend zijn. Toch zou ik uiteindelijk liever niet willen ‘gokken’ op een technische bepaling als een boilerplate, maar liever willen borgen dat het geheel aan documenten eenduidig en volledig is.

Vage SLA? De rechtbank kan helpen

Zoals hiervoor besproken komt de rechtbank in deze kwestie uiteindelijk tot een uitleg van enkele belangrijke begrippen uit de SLA.

Juridisch-technisch interessant is dat die uitleg uiteindelijk ook als een verklaring voor recht wordt toegewezen. Siemens had nog betoogd dat een dergelijke verklaring voor recht niet zou kunnen, omdat de rechtbank daarmee de overeenkomst zou herschrijven. Dat verweer wordt door de rechtbank uitdrukkelijk verworpen. De rechtbank geeft de gevraagde verklaring voor recht en stelt daarmee bindend vast hoe de SLA-definities nu gelezen moeten worden.

Voor zover mij bekend komt het heel weinig voor dat een SLA op deze manier wordt uitgelegd. Daarvoor zijn de doorlooptijden van een bodemprocedure toch wat lang. Toch zou de relatief korte procedure van artikel 96 Rv hier wellicht nog uitkomst kunnen bieden, of bijvoorbeeld de route van arbitrage.

Let op met KPI's, drempelwaarden en service credits

Een andere discussie ging over de boetes voor storingen. Siemens beriep zich op een onzekerheidsmarge van 5 procent die elders in de contractdocumentatie stond. Volgens Siemens waren pas boetes verschuldigd als die drempel werd overschreden. De rechtbank volgt dat niet.

De overeenkomst bevatte twee afzonderlijke boeteregimes. De onzekerheidsmarge hoorde bij de boetes die verband hielden met het LCC-model, terwijl daarnaast een boeteregime gold voor andere tekortkomingen. Voor iedere storing binnen die tweede categorie kon afzonderlijk een boete verschuldigd zijn. Ook bevatte de regeling een bepaling over cumulatie van beide categorieën.

Ook dit thema heeft een duidelijke IT-rechtelijke parallel. In allerlei vormen van IT-contracten, waaronder outsourcing- en cloudcontracten, komen verschillende mechanismen vaak naast elkaar voor:

• Beschikbaarheids-KPI's;
• Incident-SLA's;
• Responstijden;
• Oplostijden;
• Service credits;
• Boetes;
• Eventueel afzonderlijke schadevergoeding.

Dan moet glashelder zijn hoe die regimes zich tot elkaar verhouden.

Een maandelijkse availability van 99,9% kan bijvoorbeeld worden gehaald, terwijl tegelijkertijd meerdere Priority 1-incidenten hebben plaatsgevonden. Kan de leverancier daarvoor afzonderlijk worden aangesproken? En mogen service credits worden gecumuleerd?

De les uit deze uitspraak: laat niet impliciet welke remedies naast elkaar bestaan en welke drempels waarop van toepassing zijn.

Een aangekondigde vertraging verandert een fatale termijn niet 

Ook de discussie over de herstelwerkzaamheden is zeer herkenbaar.

Partijen hadden voor herstel van corrosie afgesproken dat 30 juni 2024 de uiterste datum was. Siemens liep achter op de planning en had HTM al geruime tijd verteld dat die datum niet zou worden gehaald.

Volgens Siemens had die gang van zaken betekenis voor het fatale karakter van de deadline.

De rechtbank oordeelt anders. Uit de overeenkomst bleek voldoende duidelijk dat 30 juni 2024 een fatale termijn was. Het enkele feit dat Siemens vooraf aankondigde dat zij die deadline niet zou halen, maakte die termijn niet minder fataal. Siemens had geen nieuwe einddatum of aanvullende afspraken met HTM gemaakt. Vanaf 1 juli 2024 was Siemens daarom zonder ingebrekestelling in verzuim.

Zeer relevant voor vertraagde IT-implementaties
Dit is een bekend patroon in de IT: "Iedereen wist toch dat de go-live van 1 januari niet meer haalbaar was?". Contractueel is dat lang niet altijd voldoende.

Net een laag genuanceerder zien we dit ook veel voorkomen. Het komt veel voor dat op werkvloerniveau al lang en breed andere afspraken worden verkend, of zelfs al zijn gemaakt. Dit terwijl het contract nog steeds uitgaat van een andere (daarmee illusoire?) werkelijkheid. Dit kan soms hele ‘grijze’ discussies opleveren, zeker als op dat operationele niveau ook de feitelijk beslissers aan het meepraten zijn.

Daarom is bij een vertraagd IT-project steeds de vraag:

Is alleen de operationele planning aangepast, of hebben partijen óók de contractuele milestone gewijzigd? Een statusrapport waarin staat "expected go-live: March" bewijst niet noodzakelijk dat de contractuele deadline van 1 januari is losgelaten.

Voor leveranciers is dat een belangrijk risico. Voor opdrachtgevers is het omgekeerd verstandig om bij het meewerken aan een aangepaste planning rechten uitdrukkelijk voor te behouden.

Een tekortkoming betekent nog niet dat er vergoedbare schade is 

Ook het schadegedeelte van de uitspraak bevat een heel interessante les.

HTM stelde onder meer schade te hebben geleden omdat werksporen en trams door de vertraging langer niet beschikbaar waren. HTM probeerde de waarde van dat gemiste gebruik onder meer te relateren aan huurprijzen en afschrijvingskosten. Daar gaat de rechtbank niet in mee.

Omdat de werksporen en trams zijn bestemd voor het behalen van economische voordelen, moet HTM volgens de rechtbank voldoende aannemelijk maken dat zij door het gemiste gebruik daadwerkelijk extra kosten heeft gemaakt of inkomsten of een reële kans op voordelen is misgelopen. Anders gezegd: het gaat er niet om of HTM de werksporen in theorie had kunnen verhuren, maar of die verhuur daadwerkelijk een reële optie was. En dat laatste bleek ergens uit. Voor de trams geldt bovendien dat afschrijvingskosten ook zonder de tekortkoming zouden zijn gemaakt.

De IT-parallel: downtime is nog geen schadebedrag
Voor IT-geschillen is dit bijzonder relevant.

Stel dat een ERP-systeem een week niet goed bruikbaar is. Een opdrachtgever kan dan niet zonder meer redeneren:

systeem kost € 3 miljoen per jaar → één week niet bruikbaar → schade bedraagt 1/52 × € 3 miljoen.

Er moet worden gekeken naar de vermogenspositie met en zonder tekortkoming.

Denk bijvoorbeeld aan aantoonbare:

• Extra personeelskosten;
• Kosten voor een tijdelijk alternatief;
• Omzetderving;
• Kosten voor herstel of workarounds;
• Verlies van een voldoende concrete economische mogelijkheid.

De uitspraak laat daarmee mooi het verschil zien tussen operationele hinder en juridisch vergoedbare vermogensschade.

Ook interne personeelskosten zijn niet automatisch vertragingsschade

HTM vorderde daarnaast personeelskosten omdat medewerkers langer betrokken waren bij onder meer het rangeren en inspecteren van de trams. Ook dat strandt.

De rechtbank constateert dat die werkzaamheden sowieso moesten worden uitgevoerd. Door de vertraging waren dezelfde werkzaamheden alleen over een langere periode verspreid. Het aantal uren in de hypothetische situatie zonder tekortkoming was daarom niet lager geweest.

Ook dit zien we bij IT-projecten. Bij een mislukte implementatie wordt al snel een spreadsheet gemaakt met:

10 medewerkers × 100 uur × intern uurtarief = € X schade.

Maar de cruciale vraag is dan niet alleen hoeveel uren medewerkers aan het project hebben besteed. De vraag is welke kosten of economische nadelen juist dóór de tekortkoming zijn veroorzaakt.

Het juridische verschil tussen "uren besteed aan het project" en "extra uren veroorzaakt door de tekortkoming" kan financieel enorm zijn.

Een aansprakelijkheidsbeperking kan ook gelden voor aanvullende overeenkomsten 

Een laatste interessante parallel betreft de beperking van aansprakelijkheid (exoneratie).

De oorspronkelijke overeenkomst beperkte de aansprakelijkheid van Siemens onder meer tot directe schade. De latere aanvullende overeenkomst over het corrosieherstel bevatte zelf geen algemene aansprakelijkheidsbeperking.

Toch oordeelt de rechtbank dat de oorspronkelijke aansprakelijkheidsregeling ook daarop van toepassing is. Van belang is onder meer dat partijen hadden bepaald dat de oorspronkelijke en aanvullende overeenkomst één onverbrekelijk geheel vormden en dat de oorspronkelijke overeenkomst kon worden beschouwd als een raamovereenkomst met algemene afspraken. Als partijen daarvan hadden willen afwijken, hadden zij dat volgens de rechtbank specifiek moeten regelen.

Voor IT-contracten is dit meteen herkenbaar bij:

MSA → SOW → Change Request → aanvullende opdracht.

Bij iedere volgende opdracht moet worden vastgesteld welke bepalingen uit de hoofdovereenkomst doorwerken. Met name bij aansprakelijkheid is vertrouwen op impliciete samenhang riskant.

Schrijf liever expliciet:
"De aansprakelijkheidsregeling in artikel X van de Master Services Agreement is onverkort van toepassing op deze Change Request."

Of juist het tegenovergestelde, als voor een specifieke opdracht een afwijkend risicoprofiel is afgesproken.

Van tram naar IT-project: lessen voor de praktijk

Het aardige aan deze uitspraak is dat zij laat zien dat complexe technische contracten, ongeacht wat er technisch wordt geleverd, steeds langs dezelfde juridische breuklijnen kunnen lopen.

Een tram en een ERP-systeem hebben technologisch weinig met elkaar gemeen. Contractueel verrassend veel.

De belangrijkste lessen voor IT-projecten zijn wat mij betreft:

• Definieer vanuit de businessimpact, niet alleen vanuit de techniek. "Niet beschikbaar" is zonder context net zo problematisch als "niet rijdbaar".
• Maak duidelijk wanneer technische documentatie contractuele betekenis krijgt. Een design freeze of solution design is niet automatisch een contractwijziging.
• Regel de documenthiërarchie. Voorkom dat SLA, requirements, ontwerp en hoofdovereenkomst verschillende antwoorden geven.
• Maak de verhouding tussen KPI's, service credits en boetes expliciet.
• Verwar een aangepaste projectplanning niet met een gewijzigde contractuele deadline.
• Maak bij vertraging het verschil tussen hinder en aantoonbare vermogensschade.
• Leg bij vervolgopdrachten expliciet vast welke aansprakelijkheidsregeling doorwerkt.

Daarmee is de kwestie uiteindelijk veel meer dan een zaak over defecten en corrosie aan Haagse trams. Het is een aardige checklist van waar langdurige IT-contracten eveneens op kunnen vastlopen.