Managed hosting door True

Berkleef verliest Equihold-zaak tegen Capgemini

Oud-eigenaar: rechter tovert konijn uit hoge hoed

De rechtbank in Amsterdam heeft Kenneth Berkleef, oud-eigenaar van Equihold, in het ongelijk gesteld in de zaak die hij had aangespannen tegen Capgemini. Volgens de rechter heeft Equihold verzuimd Capgemini op tijd wegens wanprestatie formeel in gebreke te stellen. Was dat wel gebeurd dan had Capgemini nog kunnen besluiten de fouten in de softwarecode te herstellen of het sportinformatiesysteem opnieuw te bouwen. Berkleef overweegt sterk, ondersteund door de curator van Equihold, in hoger beroep te gaan. Capgemini toont zich heel tevreden over de uitspraak.

De Amsterdamse rechtbank stelt Berkleef in de ‘zaak Equihold’ in het ongelijk op formeel-technische gronden. Berkleef is dan ook zwaar teleurgesteld. ‘De rechter is inhoudelijk helemaal niet ingegaan op de zaak maar heeft ons in het ongelijk gesteld omdat een formele ingebrekestelling ontbreekt. Maar in de hele zaak is dit niet aan de orde gesteld, noch door ons noch door Capgemini. Het lijkt er op dat de rechter een vondst heeft gedaan om de zaak op deze manier af te hameren, zodat hij niet hoefde in te gaan op het vraagstuk van de belabberde softwarecode.’

0-1

Berkleef meldt het vonnis samen met de curator en de advocaat de komende dagen zorgvuldig te bestuderen. De kans dat Equihold in hoger beroep gaat, acht hij groot. Volgens Berkleef had de rechter zich van te voren goed ingelezen in deze zaak met aspecten als wel of niet deugdelijke kwaliteit van de softwarecode en het klacht- en plichtverzuim.

‘Wij hadden aangedragen dat een ingebrekestelling niet aan de orde was, omdat Capgemini onmogelijk het door ons geconstateerde verzuim kon herstellen. De rechter draait dit nu om: van verzuim is niets gebleken omdat er door Equihold niet op tijd een formele ingebrekestelling is ingediend. Door zo’n technische vormvereiste uit de hoge hoed te toveren, hoeft hij zich niet meer uit te laten over de inhoudelijke kant van de zaak. Het staat nu 1-0 voor Capgemini, maar ik verwacht niet dat wij het er bij laten zitten.’

Instemming

Capgemini op zijn beurt laat in een reactie het volgende weten: 'De Rechtbank Amsterdam heeft in de zaak van Kenneth Berkleef tegen Capgemini Nederland alle vorderingen van de heer Berkleef afgewezen. Capgemini heeft met instemming kennisgenomen van deze uitspraak. Deze uitspraak bevestigt het beeld dat Capgemini heeft van het verloop van het project. Pas ver na afloop van het project en bij enorme betalingsachterstanden werden door Equihold vermeende problemen ontdekt met de softwarecode. Zoals ook de rechtbank constateert, is Capgemini tijdens het project noch in gebreke gesteld, noch in de gelegenheid gesteld om de vermeende problemen direct op te lossen.'

Sport-erp

Berkleef, oud-eigenaar van het failliete softwarebedrijf Equihold, startte op 28 mei 2014 met steun van de curator een procedure tegen Capgemini Nederland waarin hij 43 miljoen van de ict-dienstverlener eist. Capgemini was in het verleden verantwoordelijk voor de oplevering van het softwarepakket 1-2Focus voor Equihold. Met dit systeem zouden sportclubs inzage kunnen krijgen in de prestaties van hun sporters.

Er kwam echter geen goed, werkend pakket van de grond, waardoor het project spaak liep. Gevolg: potentiële klanten, met name uit de voetbal- en hockeywereld, haakten af. Equihold kwam in geldnood en werd 21 februari 2013 failliet verklaard.


Dossier

Computable heeft de zaak Equihold op de voet gevolgd en aan experts gevraagd hun licht te laten schijnen op wat er nu precies fout is gegaan aan opdrachtgevers- en -nemerskant. Daar zijn de afgelopen jaren diverse bijdragen over geschreven. Zie daarvoor het bedrijfsdossier van Equihold.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5790560). © Jaarbeurs IT Media.
?

 

Reacties

Ik heb het vonnis gelezen en de Amsterdamse rechtbank stelt Berkleef in de ‘zaak Equihold’ inderdaad in het ongelijk op formeel-technische gronden.

Capgemini stelt triomfantelijk dat 'De Rechtbank Amsterdam heeft in de zaak van Kenneth Berkleef tegen Capgemini Nederland alle vorderingen van de heer Berkleef afgewezen. Nee, de rechtbank is niet zo ver gekomen om alle vorderingen stuk voor stuk te beoordelen. Eén vordering is procedureel ongegrond verklaart, de rest werd daarmee als niet ter zake doende gezien.

Capgemini stelt ook ‘Deze uitspraak bevestigt het beeld dat Capgemini heeft van het verloop van het project.’ Dat slaat natuurlijk nergens op. En dat weten ze heel goed, want waarom heeft Capgemini als financieel sterkere partij dan een schikkingsvoorstel gedaan?
Bovendien zijn ook allerlei (tegen)vorderingen van Capgemini verworpen.

De hamvraag is blijkbaar: heeft Equihold/Berkleef bijtijds (binnen bekwame tijd) duidelijk genoeg geklaagd. De rechtbank is blijkbaar hiervan niet wettig overtuigd. Dat verbaast me, als ik naar de onderliggende stukken kijk. Maar ik kom hierop nog terug op deze zaak als ik de uitspraak nog een paar keer heb gelezen. De rechtbank moet je immers serieus nemen.

Ik vind de kop van het artikel zelf een beetje gechargeerd, maar vooruit. Ik moet mijn voorganger Jaap van Belkum bijvallen. Het is gewoon een onderdeel van het hele proces dat je, als je vindt dat je op welke wijze dan ook bent benadeeld, in een juridische procedure, of het nu verzekeringstechnisch of juridisch is, de allereerste stap zal moeten zetten.

Aansprakelijkheid
Een aansprakelijkheid stelling is namelijk de eerste stap die getoetst zal worden en wanneer die er niet is, dan heb je namelijk de tegenpartij, geen mogelijkheid gegeven ordentelijk te ageren of te corrigeren met deze uitkomst als gevolg.

Zoals Jaap al stelt, zul je in de motivering van de uitspraak moeten duiken om het werkelijke antwoord te vinden.

Niettemin iets anders,
Dit geld natuurlijk niet alleen voor beide partijen hier in deze publicaties maar iets wat je steeds vaker ziet gebeuren. Klaarblijkelijk is het in software ontwikkeltrajecten steeds weer de gemene deler dat er conflicten uitbreken tussen opdrachtgever en opdrachtnemer. Ik blijf stellen dat wanneer de IT-opdrachtnemer, in dit geval, het niet in zich heeft een duidelijk communicatieve basis te realiseren als eerste, waarbij voor beide partijen verwachtingen en wensen helder zijn, dit een hiaat is van de kant van de IT-opdrachtnemer.

Het is nu eenmaal een gegeven dat de materie IT, jargon, manier van werken, nu eenmaal zeer lineair van karakter is welke telkens weer botst met de dynamiek van de mens. Het is, vind ik, een zorg van de IT-opdrachtnemer er op toe te zien dat dit stukje word afgedekt juist omdat zij met de materie ter zake kundig dient te zijn.

Dat dit gegeven telkens weer achterwege blijft en dit soort situaties in de hand werkt, meermaals, dat vind ik dan weer een akte van onvermogen. Maar daar is geen enkele juridische grondslag voor dus on topic, de zaak is niet verloren maar er is hier sprake van een 'procedureel hiaat' van de kant van de eiser.

Word vervolgd?

De uitspraak is nog niet gepubliceerd op Rechtspraak.nl
Maar vooruitlopend daarop, voor de liefhebbers, lees het mooie artikel van Dirkzwager Advocaten op http://dirkzwagerieit.nl/2010/05/04/ingebrekestelling-vaak-struikelblok-in-it-geschillen/

Interessant dat mijn UN is weggevallen, zelfs niet 'Anoniem'. Da's nog eens anoniem!

Enfin. @Jaap : uiteraard plaats ik uitsluitend 'nuttige' links. En daarbij gaat het niet om 'interessant' maar om 'relevant'.
Zo is niet lezen van alle tekst op een pagina een reden waarom contracten en projecten mislukken. I.c. : de linkjes onderaan die nog veel meer relevante info geven over ingebrekestelling.
In ieder geval moge duidelijk zijn dat een ingebrekestelling 'relevant' is, niet uitsluitend 'interessant'. Net zomin als een Exception Report dat is.

(Business) Risk Management dient ten grondslag te liggen aan elk contract en dus ook aan elk project. 'Wat doen we als ... ?' en 'Wat doen we dán?'.
En wie denkt dat project risk management voldoende is - laat staan hetzelfde - mag zijn toegangspasje inleveren bij de receptie.

Er lopen *altijd* minimaal 3 proceslijnen naast elkaar, met onderlinge interactie :
* Business Process Line
* Risk Management Process Line
* Project Process Line
En alle drie (of meer) vallen onder de overkoepeling van 'Governance & Compliance'.
Die essentie missen is vragen om ellende.

Jammer dat in de uitspraak verwezen wordt naar formeel technische gronden en daardoor niet verder wordt ingegaan op de inhoudelijke kant van de zaak. Hopelijk lukt een hoger beroep want het gaat nu uit als een nachtkaars.

@I, nuttig betekent ook zinvol, relevant, ...... . We zijn het dus met elkaar eens; heldere communicatie is voor klanten en leveranciers belangrijk, ook juridisch.

@Kurt, inderdaad, dit had een goede testcase kunnen zijn voor de gehele industrie. De inhoudelijke kant is slechts beperkt meegenomen. De rechtbank heeft m.i. daarbij onlogisch geredeneerd door de inhoudelijke kant half te behandelen. Waarom waren ze van mening dat "Capgemini nog (had) kunnen besluiten de fouten in de softwarecode te herstellen of het sportinformatiesysteem opnieuw te bouwen". Hoe kom je als rechtbank tot die gedachte? En zou dat systeem dan wel deugdelijk zijn en op tijd klaar zijn? Het eerste is nog maar de vraag gezien de geschiedenis van Capgemini, het tweede is een duidelijk nee.

@Jaap ; er lijkt sprake te zijn van een Computable-hik waardoor ook van diverse personen de gebruikersnaam wegvalt.

Bij gebrek aan een gepubliceerde uitspraak : ik ben wél nieuwsgierig of door hetzij Equihold hetzij Capgemini een ingebrekestelling is gesteld of ontkend. Danwel dat de rechter dit heeft zelfstandig heeft aangevuld (art.24/25 Rv).

"Capgemini nog (had) kunnen besluiten de fouten in de softwarecode te herstellen of het sportinformatiesysteem opnieuw te bouwen"?

In een gebruikelijk software-ontwikkeltraject is dit een Contradictio in Terminis. De exit-criteria van het Test- & Acceptatieproces bepalen immer wat er moet gebeuren. Hooguit vindt daarover nog nadere besluitvorming plaats tussen Opdrachtgever en Opdrachtnemer.
Dit is één van de onderdelen van mijn 'donkerbruin vermoeden' van 8 maart vorige jaar over het verwachte rechterlijk doordeel.

Nu was het Test- & Acceptatieproces niet zo klip-en-klaar gedefinieerd.
Maar indien het raamcontract tussen de partijen qua vorm gericht op detachering/outsourcing zoals van Belkum stelt ('Capgemini 1-2Focus: falen Quality Assurance') dan víel er voor Capgemini überhaupt niets te besluiten. Die bevoegdheid zou immers uitsluitend aan Equihold toekomen, zoniet in de rol van regievoerder dan wel in die van Opdrachtgever.

Het pad van ingebrekestelling is doornig.
Het lijkt erop dat dit óók voor de rechter geldt.

@JP Westerhof, Capgemini heeft voor het raamcontract met Equihold een detacheringstemplate gebruikt en in een bijlage aangegeven dat het toch om outsourcing ging. Het was dus outsourcing. Dat is net zoiets als een operationele leasecontract template gebruiken en dan in een bijlage aangeven dat het toch om financiële lease gaat. Wie is dan de economische eigenaar van de auto? In dit geval de leasenemer/lessee. Maar Capgemini heeft daar vast een andere stekelige mening over.

Mijn meer uitgebreide reactie staat nu op Computable. Zie
https://www.computable.nl/artikel/opinie/ict-branche/5794837/1509029/vraagtekens-bij-uitspraak-capgemini-equihold.html

@Jaap : "een detacheringstemplate gebruikt en in een bijlage aangegeven dat het toch om outsourcing ging".
Daarmee ben je er dus niet.

Oók detachering is een vorm van uitbesteding ('handjes inhuren').
Hamvraag bij uitbesteding is altijd 'Wat&Wie;' ; 'Wat' moet er gedaan worden en 'Wie' is daarvoor verantwoordelijk.
Met 'Hoe&Wanneer;' vul je vervolgens het service level in.

Dát is wat het contract duidelijk (had) moet(en) maken, en is hetgeen wij vorig jaar al bediscussieerden.

Bij het onderzoek heb ik het contract kunnen inzien waarbij mijn eerste reactie na het lezen was: 'Dit zou IK niet getekend hebben'. Te veel onduidelijkheden en gebrek aan eenduidigheid. Overigens vind ik het ook een redelijk vodje contract zoals Cap dit heeft opgesteld.
Berkleef met zijn juridische achtergrond had hier zeker wat kritischer naar mogen kijken (achteraf concluderend)

Kurt, ja het raamcontract met bijlagen was een vodje. Ik zou het in die vorm ook niet getekend hebben (we kennen ons wereldje). Aan de andere kant stond er in, wat erin moest staan. Juristen schrijven wel vaker stukken die je als niet-jurist pas na herhaaldelijk lezen snapt (of dan nog niet). De 9 pagina's van de rechtbank heb ik ook herhaaldelijk moeten lezen. Daarin staan naast heldere argumenten, verwijzingen conclusies, ook veel gedachtesprongetjes die je maar zelf verder moet invullen via een soort re-engineering. Zie ook https://www.computable.nl/artikel/opinie/ict-branche/5794837/1509029/vraagtekens-bij-uitspraak-capgemini-equihold.html.
In ieder geval leek tijdens de eerste besprekingen en eerste opleveringen van documentatie alles nog duidelijk te zijn en normaal wordt het tijdens een project steeds duidelijker wat er moet gebeuren. De valkuil was dat beide partijen er snel mee wilden beginnen en de communicatie binnen Capgemini en tussen Cap en Equihold een rommeltje was, zodat het project al snel ver van de bedoelingen af kwam te staan.

De uitspraak is inmiddels online gepubliceerd:
http://uitspraken.rechtspraak.nl/inziendocument?id=ECLI:NL:RBAMS:2016:4111

Goede tip P.J Westerhof h. De uitspraak is gisteren publiek gemaakt. Iedereen kan nu zelf bepalen wat ze er van vinden en of ze mijn conclusies kunnen volgen.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×