De Commissie Elias blijft geluk houden, want nu stort het nieuwe ict-gebouw van de Sociale Verzekeringsbank (SVB) ineen. En het lijkt erop dat dit gestaakte project bijna alles heeft dat de ict-faalindustrie te bieden heeft.
Vorige week brak het nieuws: de SVB stopt definitief met het ict-deel van het grote en langlopende verbeterprogramma Tien. De schade loopt op tot boven de honderd miljoen; alleen Capgemini zou al voor tientallen miljoenen hebben gefactureerd.
Ik volg SVB Tien al jarenlang op afstand. De Kamer deed dat ook, want Tien staat op de lijst van grote projecten waarover jaarlijks aan de Kamer wordt gerapporteerd. Tot 2009 werden de budgetten ‘onderschreden’. Dan vertrekt de verantwoordelijke bestuurder en volgt na de onvermijdelijke Europese aanbesteding een ict-orgie in grote stijl: honderden mensen op één monsterproject, werkend aan een MRS (Multi Regelingen Systeem) waarvan al snel iedereen weet dat het er nooit gaat komen. De vraag is alleen wanneer de bom barst. (Hier een bestuurlijk feitenrelaas vanaf pagina 10.)
SVB verslaat iedereen
Toch, als je dieper kijkt, is het project MRS wel degelijk interessant. Zo is MRS gebaseerd op dubieuze en in essentie onbewezen technologie. En daar bovenop lijkt SVB in één project alle ellende te hebben samengebald die we kennen bij geflopte ict-projecten van die andere twee grote automatiseerders, het UWV en de Belastingdienst. Fianancieel zijn er grotere faals maar kwalitatief verslaat de SVB iedereen.
Eerst de technologie. Die is van Oracle, dus goed. Alleen heeft Oracle de laatste jaren allerlei overnames gedaan en productsuites samengesteld die technisch gezien weinig samenhang vertonen. Koop je alles en gebruik je alles dan mag je zelf aan elkaar knopen wat Oracle (nog) niet heeft gedaan. Zoiets lijkt bij SVB te zijn gebeurd. MRS was dus een heel innovatief project.
Ik hoor je denken: ‘Zijn die ict-architecten bij de SVB zo gek?’ Vermoedelijk wel. Ikzelf heb elders meegemaakt hoe specialisten van Gartner vertelden over het verschijnsel van los zand softwaresuites. Men noemt dit een ‘ecosysteem’. Het is verbijsterend wat zo’n woord teweegbrengt. Oracle heeft toch alles aan elkaar geknoopt? Not! Dat mag je zelf doen. Maar wie wil er geen ecosysteem kopen? Zoiets voelt toch als een permanent verblijf in Burgers’ Bush? Dit niveau dus.
Absurde claims
Je begrijpt dat een compleet ecosysteem alles doet wat je wilt. Je hoeft dus niet te programmeren – inrichten en implementeren volstaat. De flexibele kern van het systeem is een gespecialiseerd stuk software, een zogenaamde ‘rule engine’ genaamd OPA waarin je zonder te programmeren bedrijfsregels kunt opgeven. Jammer genoeg is dat een theoretische onmogelijkheid die echter elke tien jaar of zo weer terugkomt en slachtoffers maakt. We leven nu weer in zo’n tijd waarin absurde claims worden geloofd. Zo hebben overheidsorganen recent tientallen bedragen gespendeerd aan Be Informed, ook zo’n inregelproduct.
Terug naar SVB. Die hoeven dus niet te programmeren, maar ook voor inrichten heb je een groot, betrouwbaar softwarehuis nodig. Het wordt Capgemini en die noem je ‘implementatiepartner’, weer zo’n misleidend woord. Omdat iedereen weet dat het MRS een heel risicovol project wordt, trekt men een externe programmamanager aan. De SVB-mensen zijn te groen.
De systeemontwikkeling vindt plaats bij Capgemini India. Zonder heel goede ontwerpen is dat een gegarandeerde ramp. Zo ook hier. Onder meer UWV is er vol mee op het gezicht gegaan bij de bouw van de polisadministratie, ook met de groeten van Capgemini India. (Hier op pagina 12 het verhaal.)
Misselijkmakend
Hoe vanuit Nederland aansturing van en controle op systeemontwikkeling in India gaat, was mij tot voor kort een groot raadsel. Hoe weet je dat er echt, zeg, tweehonderd Indiërs voor je aan het werk zijn? Hoe stuur je tweehonderd mensen aan zonder heel goed Engelstalig ontwerp? Recent kreeg ik uit twee bronnen antwoorden. Een software auditor vertelde mij vertrouwelijk dat zij soms projecten tegenkomen waar aan de software weinig of niets gebeurt, terwijl er wel factuurstromen lopen. En op dit moment loopt er ook een rechtszaak tegen Capgemini van een privaat bedrijf dat beweert door extreme wanprestatie in India failliet te zijn gegaan. Capgemini verweert zich heftig, maar in gerechtelijke stukken die ik heb mogen inzien lees ik mails die neigen naar chantage. ‘Als u negatief oordeelt over onze Indiase collega’s, dan zwaait er wat voor die mensen en dat wilt u toch niet op uw geweten hebben.’ Misselijkmakend.
Kortom, offshoring lijkt een beerput die erop wacht om te worden geopend. Laat ik hier volstaan met de retorische vraag of SVB of Capgemini kan garanderen dat de gedeclareerde uren werkelijk zijn besteed. Overigens suggereert Staatssecretaris Klijnsma in een Kamerbrief dat de Capgemini-werkzaamheden plaatsvonden onder fixed price condities, maar dergelijke beweringen zijn zoals bijna altijd onwaar, of dacht je dat Capgemini zelf de kosten van de uitloop voor zijn rekening neemt?
Capgemini vrijuit laten gaan
In de wakkere dagbladpers is naar aanleiding van een bizar persbericht van SVB de vraag gesteld of SVB/SZW/mevrouw Klijnsma niet hard bezig zijn om Capgemini juridisch vrijuit te laten gaan. SVB suggereert immers doodleuk dat het mislukte MRS al was achterhaald. Indirecte schade claimen kun je dan wel vergeten, nog afgezien van de vraag of je als organisatie toerekeningsvatbaar bent als je blijft doorbouwen aan een systeem waarvan je weet dat het is achterhaald.
Hoe grotesk het MRS-project was en hoezeer er is gewanpresteerd, wordt duidelijk wanneer je als deskundige het zelfonderzoek leest dat begin dit jaar is geproduceerd door KPMG, Capgemini en SVB gezamenlijk. Dat is een fascinerend stuk, want geschreven door deskundige ict’ers en niet goed gescreend door de ambtenaren (bewijs: het staat vol met spelfouten). Voorbeeld: men maakt er bezwaar tegen dat iedere gebruiker van het systeem alle gegevens van alle SVB-klanten kan inzien, ondanks dat dit de officiële SVB-policy is. Ai, dat kan zomaar een rel worden.
Error hospitaal
Voor mij als deskundoloog is het rapport een feest van herkenning. SVB wilde ‘multirealiteit’, de nachtmerrie van iedere database-ontwerper. Totaalfaal, net als bij de UWV-polisadministratie. SVB wilde één systeem, maar kreeg een verzameling van naast elkaar staande ecosysteem-deelgegevensbankjes zonder garantie dat die onderling sporen, zie Belastingdienst Toeslagen. Ondertussen zijn alle deelprocessen synchroon aan elkaar gekoppeld, met als gevolg nog grotere performanceproblemen dan bij nodeloos complexe software gebruikelijk is. Men heeft de gedachte opgegeven dat software gewoon moet werken. In plaats daarvan moeten berichten gewoon beheerst uitvallen om dan door SVB-medewerkers te worden opgepakt. Bij de Belastingdienst-toeslagen heet dit ‘uitworp’, maar bij SVB het ‘error hospitaal’, vermoedelijk omdat SVB werkt met een ‘SOA Suite’.
En flexibiliteit? Die is er niet, al was het maar omdat Capgemini grootschalig werkt met hard uitgekraste waarden in de, eh, programmatuur, de zogenaamde ‘magic strings’. Het lijkt er overigens op dat ze daar in India een handje van hebben, want het is ook onderdeel van de genoemde rechtszaak. Die magische strings lijken overigens in de plaats te komen van de briljante regelinterpretatiesoftware, dus vermoedelijk is het lood om oud ijzer.
MRS ten dode opgeschreven
Het MRS van SVB en Capgemini lijkt al met al het voorlopige hoogtepunt van ict-falen met publiek geld en een ’textbook case’ voor hoe het niet moet. Het genoemde KPMG-rapport laat impliciet zien dat iedereen bij SVB begin dit jaar allang wist dat het MRS ten dode was opgeschreven, maar zoals gezegd ligt zo’n moment er feitelijk al veel eerder. En tenzij er voor de verandering nu wel eens recht wordt gehaald en verantwoordelijken de consequenties gaan voelen, gaat er in de publieke ict echt niets veranderen, want iedereen heeft vijf jaar feest gevierd. Jammer dat ook mevrouw Klijnsma een Plasterkje doet.
En voor de volledigheid: op het inmiddels beruchte Rijks ICT Dashboard scoort SVB MRS een 9,8. Erger kun je niet ontsporen.
René Veldwijk, partner bij Ockham Groep
Dit opiniestuk bevestigt mijn vermoeden dat de huidige ict-faalindustrie kan worden herleid tot de formule: SOA+BPM+BRM; voluit: Service Oriënted Architecture + Business Process Management + Business Rule Management; in gewoon Nederlands: “services” + bedrijfsprocessen + bedrijfsregels.
Allereerst leiden de “services” in SOA in deze formule tot een uitwaaiering van procesjes, waarvoor je dus blijkbaar zo’n 200 programmeurs in India aan het werk kunt zetten onder aanvoering van een implementatiepartner in Nederland. En laat mij raden: voor de implementatie van die “services” wordt een 3GL als Oracle Java toegepast.
Vervolgens moeten al die procesjes aan elkaar worden geknoopt, en dat kun je doen met BPM-flowcharts en/of BRM-rules; de gescheiden werelden van “de know en de flow”. De angel zit hem vooral in dat “en/of”; het zijn visies die elkaar aanvullen, maar elkaar ook bestrijden, aangezien ze in dezelfde vijver (genaamd: bedrijfstechnologie) zitten te vissen.
Vanuit de BRM/bedrijfsregelvisie wordt nu wel terecht gesteld dat het enkel toepassen van BPM nogal snel leidt tot overdreven complexe en onoverzichtelijke processchema’s waarin iedere regel tot een nieuwe vertakking (nieuw ‘wiebertje’) leidt.
In de praktijk blijken die rule engines echter niet te werken (zoals de auteur ook zeer terecht stelt), en dan komt de ‘know’ toch weer in die oude, vertrouwde 3GL’s terecht.
Het is dus zaak om in de eerder gegeven faal-formule de doodlopende wegen weg te snijden. Wat je dan overhoudt is: SOA, waarbij de S nu echt staat voor services en niet meer voor processen.
Dat hier dan sprake is van 5GL heb ik in voorgaande reactie’s al uitgewerkt.
@Louis,
Hoewel Cobol inderdaad veel leesbaarder, robuuster, etc. is dan Java is deze taal evenmin geschikt voor het formuleren van bedrijfsregels; beide zijn tenslotte 3GL talen, bestemt voor ICT-ers en niet voor bedrijfsmedewerkers. Maar die hele business-IT-alignment problematiek kom je ook weer tegen in de verschillende business cases voor het toepassen van bedrijfsregel-technologie: op businessniveau wordt gesproken van de “business rules approach” (Ross) en The Decision Model (Goldberg/von Halle); op ICT-niveau komen de diverse rule engines om de hoek kijken (zoals Be Informed, Oracle Policy Automation, Drools en IBM ILOG).
Saillant detail is dat The Decision Model voor het formuleren van bedrijfsregels zwaar leunt op het gebruik van…. beslissingstabellen; hier uiteraard niet decision tables maar rule families genoemd. Van de weeromstuit is de voorman van de business rules approach inmiddels ook naar deze techniek opgeschoven, wat heeft geleid tot een heuse stammenstrijd; zie bijvoorbeeld:
http://vianovaarchitectura.nl/group/business-rules-en-architectuur/forum/topics/is-een-business-rule-altijd-onderdeel-van-een-beslissing-decision
Het gebruik van beslissingstabellen is hier echter geen aanleiding om te stoppen met procesdenken; de tabellen worden dus datagericht verwerkt. Onder het motto: Simplify your process model by modeling decisions.
@Jack Je reactie heeft me aangezet tot een avondje surfen en mijn conclusie over Cobol en business regels was fout. Ik denk dat Cobol geschikt en prettig is voor het uitvoeren voor dataverwerking en berekeningen maar dat is het. Als ik je verhaal en de links lees: business regels en beslissingstabellen zijn weer van een andere orde. Dat is wat de producten die je noemt doen naar mijn idee: het is een manier om je business logica (bv business regels, beslisboom, rekenregels) te specificeren of bij elkaar te klikken om er vervolgens een werkend ‘programma’ uit te laten rollen. Ik denk dan aan een ondersteunende GUI en de achterliggende code, misschien een passend DB erbij.
Ik kwam in een paar beschrijvingen van deze producten ook het woord agile weer tegen en dat is niet gek, als het om instanties gaat die te maken krijgen met veranderende wet en regelgeving of berekeningen dan is het prettig voor de functionele beheerders als die op een begrijpelijk en toepasselijke manier zijn gespecificeerd. Het aanpassen is (hopelijk) een fluitje van een cent om er vervolgens een werkend programma uit te laten rollen. Alles automagisch. Dat is prettiger dan als de bussiness logica verstopt zit in een berg code.
Waar ik benieuwd ben is in hoeverre deze producten voldoen. Want het genereren van efficiente code lijkt me nog geen sinecure, zo hoorde ik laatst van een iemand die ook met zo een product te maken had als beheerder en het te stellen had met hele ongelukkige sql queries die achteraf nog even door gehaktmolen moesten om ze efficient en werkbaar te krijgen. Een sloom java product. Verder ben ik wel benieuwd in hoeverre dit soort producten dekkend zijn: zijn ze krachtig genoeg om het aan te laten sluiten jouw business logica en kan je er alles in uitdrukken? Ik neem aan dat het in de praktijk een combinatie zal zijn: een gedeelte van de business logica ondersteunt door procedures en andere delen geautomatiseerd.
Daarom twijfel ik ook of er die alles dekkende 5GL taal bestaat waar je ieder business probleem kan specificeren. Ik kwam de term domeinspecifieke specificatietalen tegen en daar kan ik me al iets meer bij voorstellen. Heb in het verleden hier ook een paar maal te maken gehad, een eigen taal om je probleem in uit te drukken om het vervolgens te vertalen naar een programma en code. Voor mij was dat toen met behulp van yacc, lex en C. En zo kom je toch altijd weer op een laag niveau uit.
Louis, dank voor je uitgebreide, genuanceerde reactie; op basis hiervan heb ik weer enkele inzichten kunnen aanscherpen.
Mijns inziens ben je vooral sceptisch ten aanzien van nieuwe ontwikkelingen in softwareontwikkeling als gevolg van een technische (ICT-) invalshoek. En vanuit deze visie maak je beslist enkele interessante opmerkingen.
Dat jouw standpunt zeer technisch is blijkt wel uit het veelvuldig gebruik van de term “business logica”; deze aanduiding tel ik precies 4x in je reactie. Wat dat betreft zou jij je kunnen thuisvoelen in academische benaderingen als BPM en BRM. Maar bespaar je de moeite, want het zijn doodlopende wegen, zoals ik in mijn eerste reactie al heb aangegeven.
Technisch georiënteerde opiniestukken worden gekenmerkt door het veelvuldig gebruik van begrippen als data, logica en proces, die uiteraard ook kunnen voorkomen in samengestelde begrippen als data architectuur, bedrijfslogica en procesflows.
Eigenlijk zijn BPM en BRM pogingen om een technische manier van denken, een denken in feiten, regels (lees ook: logica) en processen, door te voeren in het businessdomein, en dus ook in bedrijfstechnologie.
Je scepsis ten aanzien van dit soort benaderingen is dus terecht (en Veldwijk spreekt hier ook zeer terecht van “onbewezen technologie”); je scepsis ten aanzien van de mogelijkheden van het door mij voorgestelde alternatief, namelijk 5GL/SOA is nu (!) ook nog terecht (want eigenlijk ook “onbewezen technologie”).
Dat jij pessimistisch bent ten aanzien van de mogelijkheden van 5GL (en ik dus optimistisch) komt mijns inziens vooral door jouw technische invalshoek. Het formuleren van een alternatief voor dit technische denken is een lang en moeilijk verhaal, maar misschien helpt de volgende aanwijzing: denk niet meer in feiten/data, regels/logica en processen, maar in objecten, functionaliteit en diensten (en bovendien in architectuur, ruimte en ervaring/beleving).
Vergelijk het met de architectuur van de menselijke psyche: als je uitgaat van neuronenwerking kun je niets zinnigs meer zeggen over bewustzijn, vrijheid, verantwoordelijkheid, etc.
Waar wij het gewoon met elkaar over eens kunnen zijn is dat de overheid zeer terughoudend moet zijn in het toepassen van “onbewezen technologie”.
Jack, Louis, Leuke aanvullingen, geeft te denken.
Jack,
“Vergelijk het met de architectuur van de menselijke psyche: als je uitgaat van neuronenwerking kun je niets zinnigs meer zeggen over bewustzijn, vrijheid, verantwoordelijkheid, etc.”
Ik denk dat “onbewezen technologie” een verkeerde benadering is. Of veel te abstract. Uiteindelijk is het niet moeilijk: Je moet verder bouwen op “simple working systems”. Waarbij een system niet alleen de techniek is, maar het geheel van handelingen door mens en computer.
Jouw eerder genoemde motto “Simplify your process model by modeling decisions.” vind ik een fijne, die hou ik erin, al zou ik hem wel willen aanvullen met “actions of in Nederlands; handelingen. Een beslissing dekt maar een stukje.