Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

SVB: Brand in het ecosysteem

 

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

René Veldwijk

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 artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5168040). © Jaarbeurs IT Media.

9


Lees meer over



Lees ook


 

Reacties

Nagekomen bericht: de Rijks ICT dashboard score blijkt nu verlaagd naar een 7+. Nog steeds een ruime voldoende.

René, mooi bij elkaar gebracht en samengevat. Weer een voorbeeld van een situatie waar de hoeveelheid betrokken personen en de complexiteit van de voorgelegde vraag hebben gezorgd voor een oplossingsrichting die leidt tot kapitaalvernietiging en tijdsverlies.

René,

Kennelijk hebben de beheerders van het dashboard je slotzin ter harte genomen. De eindscore is inmiddels bijgesteld naar een 6,6. Nog steeds een mooie voldoende voor dit drama. Kennelijk meet het dashboard niet de juiste zaken, maar daar is de commissie Elias al wel over uit.

Dit project is nu een 1.0 voor de moeite gegeven vanuit de belastingbetaler.

Het (oorspronkelijke) Herstruc-project all over again. Je zou denken dat ze daarvan hadden geleerd bij de SVB. Blij dat ik daar weg ben.

Prachtig artikel, vele vingers op al evenveel zere plekken...
Incompetente ambtenaren, ICT graai-cultuur, brabbel-programmeurs en los-zand-techniek...
De laatste zin vat de volstrekte verzamelde incompetentie samen...

De score op het Rijks ICT dashboard is gebaseerd op kosten en doorlooptijd. Het zegt niets over de mate waarin het project 'in control' is. Dat moet worden opgemaakt uit de bijgeleverde informatie.

Het perverse aan het dashboard is, dat wanneer een project wordt herijkt (nadat de kosten en doorlooptijd werd overschreden) de maatstaf ook wordt gewijzigd. Het dashboard geeft dan altijd mooi weer, als periodiek maar een herijking plaatsvindt.

Het zou beter zijn om niet het meetinstrumentarium te herijken, maar alleen de verwachtingen te actualiseren. Als die aanpak werd gehanteerd, dan zou al veel eerder de stekker uit het project zijn getrokken.

Mogelijk zijn er motieven om feiten te maskeren achter een mooi groen dashboard. En dan heb je nog de meer- en minderwerk discussie. Hoe wordt dat in het dashboard verwerkt. Misschien is herijken dan toch nodig. Omdat van een redelijk eenvoudige indicator gebruik wordt gemaakt, is het wellicht zinvol om meerdere indicatoren aan te houden:
1. op basis van de initiële business case (t=0 tot heden);
2. per iedere herijkingsdatum (t=1+h tot heden).

In feite niets nieuws! Gewoon een "druk op de knop"systeem!
Alleen de knop ontbreekt nog. Nog even (agile) en dan is het klaar.

Ik hoop dat de ICT-industrie zich eindelijk dit soort zaken gaat aantrekken. Zij zijn verantwoordelijk voor de bijzonder slechte ambachtelijke prestaties. Wat zo diep triest is, de geschiedenis blijft zich maar herhalen.

Waar zijn de vakmensen die weten hoe je een deugdelijk voortraject uitvoert, wat gevalideerde requirements zijn, hoe een bestek (design) wordt gemaakt...?

Dit artikel doet me te denken aan een opinie van Tom van Maanen die ook toevallig bij Cap werkt:

"De dode vis wordt duur betaald"

http://www.computable.nl/artikel/opinie/datamanagement/4990021/4445906/de-dode-vis-wordt-duur-betaald.html#reacties

Was hij niet geïnspireerd door dit traject bij SVB?


@Rene,
Fraai artikel! Veelzijdige informatie, mooie opbouw en mooi gevuld met je kennis en deskundigheid. DANK!

Ik vraag me alleen af waarom mensen zoals Rene niet betroken worden bij dit soort grote projecten! Hoe vaak en hoe lang moeten we dit soort mislukkingen bij grote trajecten zien geburen?

Wie dacht dat ezel zich geen tweemaal aan dezelfde steen stoot dan vergis zich blijkbaar. Kijk naar de mislukte (overheids)projecten!

Ik ben nog steeds benieuwd waarom Cap eea liet gebeuren! Wat deed Cap om schade voor haar naam en reputatie te beperken of te voorkomen?

@Rene Leuk artikel alleen blijft er bij mij wel een vraag over na het lezen van dit stuk: hoe dan wel? Dat wordt helaas niet beantwoord. Een aantal artikelen op de site richten zich nu allemaal tegen Cap maar het gaat niet om Cap alleen, het gaat om een ICT cultuurtje wat je alom ziet, bij overheid en in het bedrijfsleven. De cultuur van aanbesteden en uitbesteden, kennis en regie van buitenaf binnengehaald, zeer ambitieuze alles-moet-anders projecten, beslissingen die zelden gebasseerd zijn op ICT inhoudelijke gronden en projecten uitgevoerd door een onwaarschijnlijke hoeveelheid mensen.

Dus ik ben benieuwd: hoe dan wel? Hoe reken je af met dit cultuurtje?

Gall's Law is a rule of thumb for systems design from Gall's book Systemantics: How Systems Really Work and How They Fail. It states:

"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system." – John Gall (1975, p.71)

Geweldig artikel. Illustreert goed wat er met een ict-bedrijf gebeurt als je het laat besturen door boekhouders.

Artikel is tendentieus genoeg, daar niet van, maar wel doorspekt met niet te onderbouwen (inhoudelijk) rammelende uitspraken.

"... een zogenaamde 'rule engine' waarin je zonder te programmeren bedrijfsregels kunt opgeven. Jammer genoeg is dat een theoretische onmogelijkheid ..." : Echt waar, puur logisch onmogelijk want er zijn geen randvoorwaarden aan te geven waarbinnen dit toch toegepast kan worden?

"Zo hebben overheidsorganen recent tientallen bedragen gespendeerd aan Be Informed" : Echt waar, tientallen keren iets overgemaakt?

"... want geschreven door deskundige ict'ers en niet goed gescreend door de ambtenaren (bewijs: het staat vol met spelfouten)." : Echt waar, en hoe meer spelfouten des te deskundiger?

QED.

Haha Rene,
't Was een kwestie van tijd dat jij over dit onderwerp een artikel zou plaatsen.

Toch begrijp ik dit hele verhaal niet helemaal.
De oplossing is toch zo simpel.
Stel, je hebt 40 meloenen over de balk te gooien.
Nu dan, je vraagt aan tien leuke bedrijfjes om iets leuks in elkaar te knutselen. Elk van die bedrijfjes geef je 1 meloen voor de moeite.
Er zit vast een clubje bij die het werk wel serieus neemt en die iets bruikbaars oplevert.
Nu die geef je nog eens 10 meloenen om de hele rotzooi op te leveren, te implementeren en weet ik veel waar je dat geld nog meer aan moet verbrassen.
Van de overgebleven poen ga je met zijn allen lekker een keer uit eten en de rest stop je netjes terug in de staatsruif.

Voordelen:
- Er wordt eens een ict-project wel fatsoenlijk opgeleverd.
- Er ontstaan kansen voor kleinere bedrijfjes die enkel kunnen voortbestaan doordat zij wel behoorlijk werk leveren en kunnen leveren.
- Voldoet aan aanbesteding
- Je kunt eens lekker duur uit eten.
- Je bespaart de staat geld

Zo moeilijk is het toch allemaal niet.

OMG! zit nu een link uit het stuk te lezen :
(http://www.ockham.nl/ocp/downloads/overige-publicaties/schrijven-ockham-aan-de-tijdelijke-cie-ict-ihkv-hoorzitting-12-mei-2014)

En hier gaan mijn haren van overeind staan, het is dus duidelijk dat er een aanbesteding gewonnen wordt op strategische (lees: valse) wijzen en voorkennis. Dit is ronduit *evil*. Met voorbedachte raden word er een bod gedaan wat een kleinere en eerlijkere partij kansloos maakt, is dit niet gewoon strafbaar? Lees op pagina 6 :


k) Capgemini wint in 2004 de Europese aanbesteding Polisadministratie. Het aanneembedrag zou
beneden de acht miljoen euro liggen, wat volgens de meeste ingewijden onder de kostprijs ligt.
Mw. Wildvank noemde in een e-mail die in uw bezit is zelfs een bedrag van 1,5 miljoen euro.
Duiding: Het kopen van ICT-projecten door absurd laag in te schrijven is niet abnormaal, zeker
niet bij Europese aanbestedingen waar de opdrachtgever na gunning geen kant meer op kan. Bij
de Polisadministratie speelde dit in hoge mate. Er was sprake van een ketenproject met de
Belastingdienst met een deadline (eerst begin 2005 later begin 2006) die algemeen werd gezien
als onhaalbaar.
Een andere reden om een strategisch ICT-project te kopen is het verwerven van een
sleutelpositie in een informatieketen. Bij de Polisadministratie speelde ook dit effect sterk mee.
Dit systeem zou immers 1) de kern worden van zowel de informatiehuishouding van UWV, 2) een
groot aantal publieke en private afnemers bedienen en 3) op termijn een officiële
basisadministratie zoals de GBA worden: Basisadministratie Lonen, Arbeids- en
Uitkeringsverhoudingen (BLAU).
Dergelijke marktkarakteristieken laten ook zien waarom, ondanks dat het aantal ICT-aanbieders
dat mag meedingen naar overheidsopdrachten klein is, er geen marktverdeling plaatsvindt zoals
in de bouwsector het geval was. Bouwprojecten zijn veel transparanter dan ICT-projecten. De
aanbestedingspraktijk versterkt de intransparantie van de gunning van ICT-projecten nog verder

@NormanvanEs
Om je vraag te beantwoorden:
"Waar zijn de vakmensen die weten hoe je een deugdelijk voortraject uitvoert, wat gevalideerde requirements zijn, hoe een bestek (design) wordt gemaakt...?"
Die vindt je niet van 24 jaar oud en met 20 jaar ervaring, dan zou je ook eens kunnen kijken naar 50-plussers die zijn zeker te vinden en ook in staat een goede ambachtelijke prestatie te leveren.

@Pascal De gebruikers zien ze al komen al die bedrijfjes en dan mag de gebruiker voor de 10de keer gaan uitleggen wat hij nu precies wil. Zou het niet beter zijn om zelf maar de ict kennis en kunde in huis te halen? Net zoals de regie en verantwoordelijkheid? En alleen bij gelegenheid wat extra externe krachten? Maar misschien moet er ook maar afgestapt worden van het fenomeen ict-project. Uiteindelijk is je ondersteunende ict een doorlopend verhaal wat met de tijd verandert.

@Henri Bouwprojecten zijn veel transparanter? Daar herinner ik me ook heel iets anders van, daar is het fenomeen prijsafspraken zo een beetje uitgevonden. Wel, een huis, weg of metro is concreet en daar heb je een beeld bij. Itt iets abstracts als een ICT systeem. Ik denk overal waar veel geld te verdelen is gelden andere wetten.

Hulde aan René Veldwijk voor het schrijven van dit artikel, dat op 9 van de 10 overheids ICT-projecten van toepassing is. Heel goed dat iemand met verstand van zaken, onafhankelijk van de grote ICT "dienstverleners" dit iedere keer weer opschrijft (http://www.computable.nl/artikel/achtergrond/overheid/5085768/1277202/ictstelsel-bij-de-overheid-is-rot.html) of vertelt (https://www.youtube.com/watch?v=SWpkjOq5K2M).

Alleen jammer dat het falen ingebouwd zit in het stelsel, en de IT opleidingen in Nederland zover zijn geinfantiliseerd dat er niets zal veranderen.

Infantilisering van het (reguliere) informatica onderwijs lijkt mij geen waterdichte oorzaakduiding. Eerder zien we nu vaker en vaker het eindeffect van 25 jaar lang computerhobbyisten in dienst nemen door het (om automatiseringspersoneel verlegen zittende) bedrijfsleven en betreffende lieden daar "carriere" te laten maken.

-Meer openheid bij aanbestedingen.
-Het ontwerp moet gekeurd worden door een 3de partij, liefst een concurrerende aanbesteder.
-Tijdens de bouw diverse momenten voor terugkoppeling om rekening te houden met veranderingen. Zo als vernieuwd inzicht, wetten of technische ontwikkelingen. En uiteraard ook weer met terugkoppeling van een 3e partij.
-Als het project op het punt staat om afgerond te worden en het resultaat is minder als verwacht zal de pijn gedeeld moeten worden aan alle partijen.
-Na de bouw zal de gemaakte code en relevante kennis beschikbaar moeten komen om als voorbeeld te dienen voor opvolgende projecten.

Ach meneer Veldwijk de constatering aangaande vertragende software werd in 1995 al door Niklaus Wirth gedaan en in een wet gevangen: de tijd van een programmeur is duurder dan een computer. Windows 95 zat dan wel boordevol functionaliteiten en was makkelijker te gebruiken maar ook veel trager dan het oude 8-bits DOS.

Als u de klassiekers van Nederlandse literatuur eens leest dan ziet u gewoon een herhaling van zetten als het de overheid betreft. Overheid is namelijk ook een ecosysteem wat zich krampachtig in stand probeert te houden. Van decentraal naar centraal en weer terug is als de 'torens van Hanoi' om niet al te ver off-topic te gaan, een recursie die steeds meer klokcycli - lees geld - vraagt als het aantal regels groter wordt.

Of het nu Crap Gemini of Gockham groep is die de blinde gaat leiden lijkt mij pas lood om oud ijzer. Conclusie aangaande 5 jaar feest vieren is dus onjuist - u beperkt zich tot één specifiek geval - het is namelijk eerder 20 jaar. En let wel dat ik het hier over de overheid heb en niet de marktpartijen die min of meer gewoon leveren wat gevraagd wordt. De wetten van de vrije markt en betreffende de genoemde 'magic strings' zou u eens moeten kijken wat er allemaal met regex aan elkaar geplakt wordt.

Zeker heeft u gelijk aangaande vreemde keus voor Oracle maar wel om een heel andere reden. Wie in plaats van krant (of Libelle) ook meters aan rapporten doorneemt komt tot conclusie dat 'magic strings' bij overheid vooral meer weg hebben van incestieuze verhoudingen. In de snelheid van digitaliseren wordt normaliseren namelijk nog vaak vergeten. Die peperbus van de VVD stelt niet voor niks dat 'Big Data' de toekomst heeft als we het over 'magic strings' gaan hebben.

Als 'mister edge case' schaak ik graag langs de randen, nogal rafelige randen als het om ICT projecten bij de overheid gaat. Vanuit dat spel constateer ik dat de opsomming dus nog niet tot de kern van het probleem komt. Wat dat betreft wordt die programmeur du heel wat goedkoper als er dus minder geld rondgepompt wordt door die kerstboom aan toeslagen te verminderen. Best grappig dat Weekers moest 'Wieberen' toen zijn ambtenaren de zaak van de toeslagen fraude uit de doeken deden.

Aangaande Rijks ICT-dashboard trapt u wat mij betreft ook een 'open deur' in aangezien ik deze volksverlakkerrij al in 2011 aan de kaak stelde naar aanleiding van een journalistiek onderzoek. En laten we vooral niet vergeten dat deze 'windows dressing' net als rijks-CIO tot stand kwam na allereerste onderzoek van rekenkamer naar aanleiding van mislukkende ICT projecten. En de tussentijdse evaluatie door rekenkamer kwam trouwens ook tot venietigende conclusie dat het gehele dashboard gewoon onzin is. Als ik me niet vergis was het probleem hier ook de normalisatie, van de cijfers notabene.

Als ik me niet vergis heeft KPMG al geconstateerd dat de versplintering van de overheid zorgt dat veel informatie onjuist of oncontroleerbaar is. Onvermeld maar niet onbelangrijk is dat de wens van flexibiliteit in regels komt door de constant wisselende coalities die zich vooral druk maken om virtuele inkomsten. Uw nieuwtje aangaande de facturen voor niet uitgevoerd werk hoorde ik al eens bij IBM, idee van de participatie maatschappij is van dezelfde orde. Puur hypothetische vraag dringt zich dan ook aan mij op wat er gebeurt als we in plaats van de opgedrongen Euro een groot deel van de diensten in kudos ofzo gaan betalen.

Volgens mij gaat (heide)brand in het ecosysteem niet zo zeer om één marktpartij maar het hele kaartenhuis van de dienstenmaatschappij. De verkoop van 'magic strings' is namelijk niet veel anders dan woekerpolis. Er is dan ook niets mis met los zand software als je de kennis van koppelen maar niet verliest. Euh.... heb ik al wat over belangenverstrengeling gezegd als het om kennis of kennissen gaat?

Ewout,
Ook jij zult ongetwijfeld je huiswerk hebben gedaan.
Wat mij echter aanspreekt bij Rene, is dat hij zijn zegje ook gedaan heeft bij de comissie Elias. zodat zijn relaas niet aleen hier op computable staat maar ook nog ergens in een stoffige lade gaat verdwijnen.
Want zoals diverse andere kandidaten in de diverse interviews van deze commissie hebben aangegeven is dat de belangen van de leveranciers en ambtenaren zwaarder wegen dan het slagen van het project.
Dit gecombineerd met hun conclusie dat het voor genoemde partijen het meest gunstig is als een project mislukt (toegegeven, die snap ik nog niet helemaal) tel uit je winst.

'Zijn die ict-architecten bij de SVB zo gek?'
Nou, je vergeet: Die ICT-architecten wisten het wél beter maar moesten onder het dictaat van anderen (hogerop, met minder (van whatever tot nul) verstand van zaken) het onmogelijke doen. Enig idee hoeveel stress dat opleverde ..?

@Jurgen Bekend verhaal, jij schrijft het, zelf meegemaakt en hoor het ook van anderen die in de uitvoerende ICT werken: ICT inhoudelijke beslissing worden op hoog niveau genomen waarbij je denkt: hoe is het mogelijk? Het enige wat je kan denken: heb je er echt geen verstand van of gaat het om belangen? Ik denk een combinatie van. Niet leuk, frustrerend en het geeft stress. Maar het is ook een belangrijke reden dat een project zoals hierboven faalt.

René,

Betrouwbaarheid van een publicist is belangrijk. Blijkbaar had jij inside information gezien je Tweet (http://goo.gl/k04v7z) op 18 augustus, vraag me af of jouw informant blij was met deze tweet. Aantreden in de ICT-enquêtecommissie als ervaringsdeskundige, en dit soort voortijdige ontboezemingen kan ik niet rijmen met elkaar. Maar goed, zal wel aan mij liggen.

Op een paar punten gaat jouw analyse gebasseerd op rapportonderzoek mank. Ten eerste: welke Oracle technologie is volgens jou "onbewezen"? Ten tweede: waaruit concludeer jij dat de rules-engine debet aan het MRS debâcle is? Ten derde: waarom is synchrone integratie een duivel, beiden hebben hun eigen voordelen waarbij asynchrone integratie doorgaans juist complexere software oplevert, en synchrone meer resourcebeslag vraagt.

Goed als ik dezelfde rapporten lees die jij hebt gelezen, lees ik inderdaad dat het "MRS" een enorme innovatie zou zijn in geval dat het van de grond was gekomen. Misschien was het programma als geheel te grotesk van opzet, maar waarom alle innovatie weghalen? Ik ben van mening dat je zonder falen niet vooruit komt. Falen hoort bij innovaties. Two steps forward, one step back. Dus maak programma's minder grotesk van opzet, dan zijn de fails kleiner (one step back) maar zijn er ook successen (two steps forard).

In dit verband ook graag nog even een stapje zijwaarts heren deskundici: is dat Indigo van de Immigratie- en Naturalisatie Dienst IND (een kennis- c.q. rule-based systeem, jawel) is dat nu wel of geen succes?

NASCHRIFT

Dank voor de vele reacties. Zoals aangegeven volg ik het SVB dossier op afstand, dus het kon zijn dat ik op onderdelen de plank mis sloeg. N.a.v. de vele reacties (ook direct per mail) weet ik nu vrij zeker dat dit niet het geval is.

Ik acht de kans overigens wel groot dat er zaken van wezenlijk belang zijn waarvan ik geen kennis heb. Je weet natuurlijk nooit wat je niet weet, maar op basis van de berichtgeving van SVB en SZW naar de Kamer mocht worden verwacht dat staatssecretaris Klijnsma vol zou inzetten op bagatelliseren van het debacle, zowel de schade in euro's als de effecten op de dienstverlening.

Deze verwachting is in een Algemeen Overleg met de Cie SZW vanmiddag ook waargemaakt en nog sterker dan verwacht: de schade is nu teruggebracht tot ruim 10 miljoen euro omdat er componenten van het MRS- ecosysteem worden hergebruikt. Door het maximaal toerekenen van de gemaakte kosten aan die werkende componenten ontstaat dan een situatie waarbij de schade optisch zeer beperkt blijft.

Indien en voor zover [!] dit beeld klopt is er hier sprake van misleiding en (markt)bederf door de overheid zelf. Ook dat is bepaald niet zonder precedent maar de timing, kort voor de presentatie van het rapport van de Cie. Elias, is pikant.

VERZOEK:
Ik wil langs deze weg een beroep doen op Computable- lezers met meer kennis dan waarover ik beschik. Ik zoek concreet antwoorden op de volgende vragen:
1- Hoeveel is er aan niet terugvorderbare licentiekosten aan [Oracle] "ecosysteem software" uitgegeven, indien mogelijk per onderdeel?
2- Welke ecosysteem-componenten worden hergebruikt en welke jaarlijkse kosten brengt dit met zich mee?
3- Welke kosten brengt het het met zich mee om deze componenten in de gewijzigde omstandigheden te gebruiken?
4- Brengt het hergebuik van ecosysteemcomponenten structurele kosten en/of risico's met zich mee waarvan geen sprake zou zijn indien SVB volledig afscheid zou nemen van MRS.
5- Kan Capgemini voor wat betreft de ecosysteemcomponenten waarmee SVB verder gaat op basis van haar contracten met SVB eisen dat zij de ICT leverancier blijft?

Natuurlijk zijn er veel meer interessante vragen, maar de antwoorden hierop geven het scherpste antwoord op de vraag of er sprake is van misleiding & bedrog.

Email kan op het Google adres renePUNTveldwijk. Informatie wordt vanzelfsprekend vertrouwelijk behandeld.

Rene Veldwijk

@Rene Ik vraag me af wat nu de zin is om na te gaan of we met misleiding en bedrog te maken hebben. Die vraag ga je nooit beantwoorden ook al kun je je vermoedens hebben met deze old-boys-netwerk deals. Het lijkt me iedereen wel duidelijk dat er niet veel van deugt. Zou mooi zijn als de overheid, de minister of wie dan ook daar open in zouden zijn, dit is de puinhoop en dat heeft het gekost. Ik zou denken, vergeet het, gedane zaken nemen geen keer en nu vooruit. Niet meer op deze manier met deze te grote en op alle fronten uitbestede projecten waarbij het bouwen de sluitpost is. Interessanter is het antwoord op de vraag: hoe dan wel? Daar zou het SVB meer bij gebaat zijn.

@Pascal
Inderdaad liggen er dus vele rapporten stof te happen, neem bijvoorbeeld 'Lessen uit ICT projecten bij de overheid' van de rekenkamer uit 2007 wat in gaat op alle politieke-, organisatorische en technische krachten. Betreffende laatste heeft dit rapport een paragraaf over enthousiasme voor IT, voor elk probleem een ap(p)i.....

Meneer Veldwijk vergeet te vermelden dat vrijwel iedereen feest vierde met mogelijkheden van ICT annex Internet. Vanuit dat perspectief is het ook wel grappig om te zien welke verwachtingen burgers hebben aangaande privacy. Ik schreef in een eerdere opinie: "Magistrale verkooptruc is zoals Jort Kelder de werking van de markt uitlegde door aan Matthijs van Nieuwkerk zijn pen, iets van weinig waarde te vragen. En toen Jort deze had vroeg hij aan Matthijs om zijn naam op te schrijven. En hoe verrassend had Matthijs daar een pen voor nodig die Jort hem wel wilde verhuren, voor een belachelijk hoge prijs uiteraard."

Als het om schrijven met een vork gaat is het goed om ook eens wat andere stukken te lezen, samenvattingen in de krant zijn namelijk dus nog weleens politiek gekleurd. In dat kader is het ook typerend om naar kosten van Oracle te vragen maar kosten van andere 'suite' leveranciers te vergeten. Dit getuigd van dezelfde tunnelvisie als de 'boycot' van Rusland terwijl nu blijkt dat veel Europese landen met winter in aankomst erg afhankelijk zijn van Russisch gas. Toen ik Poetin laatst hierover belde vroeg hij mij schamperend hoeveel tanks Nederland had.......

Met laatste reactie lijkt meneer Veldwijk steeds meer op die 'Excel Socialisten' van de SP die ook 999 (luftballons) meldpunten hebben, notabene een goedkoop Google mailaccount nog wel. Meneer van Gockham heeft het over firma list & bedrog waarmee hij naar ik aanneem dus de politiek bedoeld en waarin hij blijkbaar net als Ton Elias nu zijn geluk lijkt te gaan zoeken. Ja, ja hij heeft zijn zegje gedaan bij parlementaire commissie maar ik heb toch liever dat die producten van Donner's hansworstenfabriek eens wat meer gaan luisteren naar de werkvloer zelf.

In opinie 'ICT is een nationaal belang' haalde ik een quote aan van Eduard Douwes Dekker: "Men kan evenmin iets goeds voortbrengen door 't volgen van modellen, als zich voeden met de spijs die 'n ander gegeten heeft." Case van SVB is zoals uit de vele rapporten blijkt namelijk geen op zichzelf staand incident, de regels tegen wetmatigheden in verbuigen lijkt me weinig integer. Dat is namelijk net zoiets als een bureau integriteitsbevordering in plaats van -bewaking, de gebruikelijke mosterd na de maaltijd dus.

Grappige is dat uit al die oude rapporten prima een trend te halen is waar je als marktpartij weer op kunt acteren. Beetje lobbist weet namelijk beter wat er precies speelt bij de overheid dan de verantwoordelijke minister. Steeds vaker is dat trouwens een oud-minister of top-ambtenaar als ik kijk naar de incestieuze verhoudingen die er allemaal zijn, want hadden we het nu over een corporatie of democratie?

@ITnerdje
Aangaande asynchrone en synchrone software is dat min of meer recursie probleem waar ik het in eerste reactie over had. Organisatorisch kun je formule namelijk doortrekken, probleem van toenemende hiërarchie is nu eenmaal niet iets wat je op kunt blijven lossen met technologie als je niet eerst een normalisatie doet. Hele wetenschappelijke verhandelingen zijn er geschreven over scheduling in distributed systems, hoe langer de keten hoe groter de kans op fouten.

Decentralisatie van uitvoer met centraal toezicht klinkt heel erg als al jaren falende oplossingen van SAP-er-de-flap verkeerstorensystemen als men vergeet dat de afhandeling van alle bagage nog altijd in de kelder plaats vindt;-)

@HJK,

25 Jaar geleden waren er nog geen ICT opleidingen.
Nu zijn ze er wel maar hebben ze geen niveau.
Ik heb de infantilisering pas echt zien opkomen toen werkelijk ieder amateur die een muis kon oppakken zich met automatisering ging bezighouden.

@Pascal
Vanaf ca. 1980 was het probleemloos mogelijk om (op basis van een VWO-diploma, of equivalent, of desnoods via een colloquium doctum) aan een universiteit informatica te gaan studeren (in Twente vanaf 1981 zelfs aan een zelfstandige faculteit Informatica). Je kon daar reeds in het eerste jaar echt harde feiten leren over o.a. imperatieve programmatuur (zoek voor de aardigheid het begrip "invariant" eens op; ter motivatie: "a*a+b*b=c*c" is nog veel ouder en ook niet minder waard geworden in de loop der eeuwen).
Laten we zeggen dat 1980 (zeker) 25 jaar geleden is en laten we zo'n traject een academische ICT opleiding noemen (lijken mij geen verkeerde kwalificaties).
Natuurlijk, bedoelde opleiding levert je geen Microsoft, Oracle of SAP certificaten op; maar daar prikt het bedrijfsleven toch wel doorheen?

De pagina https://www.rijksictdashboard.nl/content/project/veranderprogrammasvb-tien is verdwenen (“Rijks ICT-dashboard Pagina niet gevonden De gevraagde pagina werd niet gevonden”).
Is het niet verbazingwekkend dat een superproject opeens niet meer kan worden gevonden? Er zijn immers zoveel herbruikbare dure elementen van het Multi Regelingen Systeem. Dit zijn Russische toestanden.

René Veldwijk, ik heb je brief aan de tijdelijke commissie ICT gelezen. Wat een bedorven sfeer en wat een kinnesinne. De samenvoeging van uitkeringsinstanties in één organisatie is op zich een mislukking. Het is moeilijk om daar enig rendement te bereiken op welk gebied dan ook.

Met betrekking tot je verzoek om onderzoekgegeven over MRS. Ik ben bang dat de verantwoordelijken de doofpot gebruiken en hun medewerkers onder druk zetten om daaraan mee te werken. Kijk maar naar hun eerdere rapportages. Die zijn geschreven met wel heel veel “gevoel voor politieke verhoudingen”, omdat - zoals Pascal schreef - “de belangen van de leveranciers en ambtenaren vaak zwaarder wegen”. Er kan door het management gekozen worden voor laten we ons verlies nemen (d.w.z. laten we de belastingbetaler er maar voor opdraaien) en we gaan alleen verder vooruit kijken (we weigeren om ergens van leren).

Heb zelf vele jaren geleden ook zoiets meegemaakt dat een project bij een overheid een half miljoen te duur was uitgevallen doordat leverancier extra winst wilden maken. Met harde bewijzen ging ik naar mijn baas. Die vond het heel interessant, maar ik mocht het onderzoek niet zelf verder uitvoeren, ik had veel belangrijkere taken te doen. Hij zou dat onderzoek wel met de vorige projectleider uitvoeren. Nooit meer wat van gehoord dus.
De bewuste leverancier werd bij een later Europese aanbesteding met een nogal kromme redenering geweerd. Ze gingen vreemd genoeg niet in beroep, ook al was het budget veel groter.

@JvVoren Ik denk dat er niet veel anders mogelijkis dan het verlies te nemen en verder te gaan. Wat is er anders mogelijk? Peperduur juridische gesteggel of er nog maar eens onderzoekje van KPMG tegen gooien? Bespaar je de moeite en lessen trekken uit dit soort veelvoorkomende debacles is en fluitje van een cent. Eentje ligt er vlak voor je: stoppen met het uit en aanbestedingscircus en als overheid de ICT in eigen handen te nemen.

Helaas, het is inderdaad zonde van het belastinggeld maar die burger draait ook op voor de puinhopen in de zorgsector en je draait er als klant weer voor op als er in de private sector een (ICT) debacle plaatsvindt. Zo een onbegrijpelijk miljoen verslindend debacle heb ik weer meegemaakt. Je moet maar denken als troost, er zijn aantal mensen heel erg gelukkig van geworden.

Louis Kossen, we zijn het eens, beide partijen zullen hun verliezen moeten nemen. De één wel meer dan de ander. Een onderzoek door bijvoorbeeld KPMG is niet betrouwbaar. Daar zijn te veel grote schandalen en affaires geweest vanaf de jaren tachtig omdat mensen meerdere petten combineerden en omdat ze adviezen gaven met een reeds eerder door de klant bepaalde uitkomst. Big four - bad four. Laten studenten onder leiding van een ervaren onderzoeker maar eens kijken naar deze case.

Dat wil niet zeggen dat je niet relatief gemakkelijk kan onderzoeken wanneer het mis gegaan is, of wie de (deel)verantwoordelijkheid niet kon dragen en dus wie gevraagd moet worden om wat anders te gaan doen, dan wel niet opnieuw ingehuurd moet worden. Het enige wat je hier moet hebben is commitment van de minister.

Zelf doen kan in principe, maar alleen als je het ook zelf kan. Is de SVB wel zover dat ze een MRS kan ontwikkelen? Denk van niet, want als je een zo’n extern uitgevoerd project niet kan aansturen, dan lukt het intern ook niet.

En de financiële schade? Gaan ze die nu verhalen op de betrokken partijen en ambtenaren, of draait de burger hier voor op?

Of is deze vraag het bewijs dat domme vragen toch echt bestaan?

@JvVoren Nee, de SVB is zeker niet zover dat ze het zelf kan doen maar is er niet zoiets als de OAD (Overheids Automatiserings Dienst)? Het zal tijd kosten om zelf het heft in handen te nemen, maar ik denk verstandig. En ik begrijp, men redt zich nog met de oude Cobol spulletjes.

@LK: En ik begrijp dat "het zich zgn. kunnen redden met Cobol" de diepere oorzaak van alle ellende is.

@hjk Ik ben benieuwd waarom je denkt dat dit de diepere oorzaak van de ellende is. Ik lees dat het een uitkomst bij een falend bouwproject.

Nou ja, DE diepere oorzaak, ik had eigenlijk willen schrijven een van de diepere oorzaken.
En dan doel ik op hoe enorm remmend die technologie is, via uiteraard vooral haar kortzichtige supporters/beoefenaars, op de evolutie van het vakgebied der softwareontwikkeling. N.B. Het formalisme Cobol werd reeds 40 jaar geleden als volstrekt onvoldoende gekwalificeerd (door deskundige academici, waaronder de tamelijk prominente Nederlander Prof. E.W. Dijkstra).

@hjk Ik moest even zoeken maar ik las de quote van Dijkstra dat hij Cobol betiteld als misdadig maar ik lees evengoed ook enthousiastere verhalen over de leesbaarheid en dat het goed voldoet om bussinessrules in uit te drukken. Ben nog op zoek waarom het misdadig genoemd wordt door Dijkstra. Ik geloof niet dat het iets over de beoefenaren van Cobol zegt. Het is een taal gericht op het verwerken van data, oud en nog veel gebruikt. Zouden die bussiness regels zich gemakkelijker laten uitdrukken in bijvoorbeeld Java? Ik geloof het niet en over bijvoorbeeld Java las ik ook een hele lelijke quote van Dijkstra. Ik denk als het doet wat het moet doen dan is dat al heel wat.

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.

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

×
×