Managed hosting door True

‘Overheid moet zich niet voordoen als ict-bedrijf’

Informatica-onderzoekers Universiteit Utrecht pleiten voor radicaal andere aanpak

 

Mislukking

Twee informatica-onderzoekers van de Universiteit Utrecht pleiten in een open brief aan minister Ronald Plassterk van Binnenlandse Zaken en Koninkrijksrelaties dat de Nederlandse overheid alleen een opdrachtgeversrol vervult als het op ict aankomt. Daarbij moeten structureel private partijen worden ingehuurd voor uitvoering en beheer. Alleen zo kunnen volgens prof. dr. Sjaak Brinkkemper en dr. Slinger Jansen, leerstoel Software Productie, hoofdpijndossiers als C2000 bij de politie, verouderde systemen bij de Belastingdienst en het Speer-systeem van Defensie voorkomen worden.

Begin juli beëindigde Minister Plasterk het programma voor de realisatie van de Basisregistratie voor Personen (BRP), de centrale database voor alle Nederlandse burgers. Kostenoverschrijdingen, ontbrekende functionaliteit en een oplevering pas over enkele jaren zijn de overwegingen waardoor het BRP-programma on hold is gezet en is een periode van bezinning afgekondigd. Informatica-onderzoekers Sjaak Brinkkemper en Slinger Jansen roepen in de open brief de overheid op om ict-ontwikkeling op een andere manier in te richten.

Miljarden euro’s

‘Ict-ontwikkeling door de overheid blijkt altijd problematisch te zijn’, menen de onderzoekers van de Universiteit Utrecht. ‘Het communicatiesysteem C2000 van de politie, de door de Rekenkamer vastgestelde veroudering van de systemen bij de Belastingdienst, het Speer-systeem voor materialen en transport voor Defensie. Het zijn enkele voorbeelden van hoofdpijndossiers bij de overheid, waarmee miljarden euro’s gemoeid zijn.’

Keer op keer dient volgens Brinkkemper en Jansen de vraag zich aan of de overheid wel geschikt is om dit soort systemen te ontwikkelen in eigen beheer. ‘Kan dit niet beter aan marktpartijen overgelaten worden? De overheid bouwt zelf geen kantoren, graaft geen Maasvlakte, legt geen straten aan. De overheid treedt op als opdrachtgever, en huurt private partijen in voor uitvoering en beheer. Zo zou dit ook moeten zijn voor de ict voor de overheid. En daarom stellen wij een radicaal andere aanpak voor.’

Radicaal andere aanpak

Die radicaal andere aanpak baseert het tweetal op vier basisprincipes:

Laat overheids-ict geschikt voor meerdere landen ontwikkelen door internationale marktpartijen. ‘Burgerregistratie verschilt nauwelijks van elkaar per land. Stel specificaties op in internationale of Europese context. Laat de open markt hierop inspringen, zodat de kosten gedeeld kunnen worden en veel meer technische capaciteit beschikbaar is. Zo zijn tenslotte de talloze standaardpakketten voor bijvoorbeeld boekhouding en personeelsadministratie ook ontwikkeld. Maatwerk is nu eenmaal duur en veel te onvoorspelbaar.’

Ontkoppel de softwareapplicaties van de data. ‘Cloudtechnologie maakt dit tegenwoordig goed mogelijk. De overheid kan dan de data van de burger beheren én beschermen in een centraal platform. Bedrijven in het ecosysteem bouwen vervolgens eigen applicaties op het platform onder regie van de overheid. Op deze manier is er meer mogelijkheid tot hergebruik en deling van software in het ecosysteem en worden de participanten daarbinnen beter in kaart gebracht. Data blijft eigendom van de staat, de software van het ict-bedrijf, met goed gedefinieerde koppelstandaarden. De overheid wordt de dirigent van haar eigen orkest.’

Implementeer nieuwe overheidssystemen op een incrementele wijze. ‘De stapsgewijze invoering van de OV-chipkaart is een goed voorbeeld. In de software-industrie is het gebruikelijk om systemen geleidelijk op te bouwen: eerst een minimale set basisfuncties, om deze vervolgens incrementeel aan te vullen. Op die manier kan een systeem zich bewijzen, alvorens het een probleemdossier wordt.’

Bouw kennis op over de beste vorm voor systeemontwikkeling voor de publieke sector. ‘Wat Hansje niet leert, zal Hans nooit weten. Er vindt vrijwel geen kennisopbouw en onderzoek plaats naar de optimale inrichting van automatisering bij de overheid. Welke aanpak blijkt succesvol? Zo was in de jaren 80 de nieuwbouw van de Kinderbijslag zeer succesvol. En daarnaast: welke technologie werkt het beste voor grootschalige publieke systemen? In het onderwijs werken de leerlingenadministratie en leermiddelen, zelfs voor wiskunde, probleemloos via de cloud. Ook de Raad voor de Rechtspraak implementeert vanaf 2016 stapsgewijs het digitaal procederen waarin rechters en advocaten online toegang krijgen tot geheel digitale dossiers.’

Oververhitte markt

Het is volgens Brinkkemper en Jansen natuurlijk gemakkelijk om de zwarte piet eenzijdig neer te leggen, want de ict-industrie moet ook in de spiegel kijken. ‘Er is een groot tekort aan kennis en specialisten, en in een oververhitte markt is het lastig om een stapje terug te doen en te realiseren dat het onze gemeenschappelijke verantwoordelijkheid is. We moeten grote hoeveelheden oude systemen bij de overheid voorkomen, die alleen nog met externe kennis werkend gehouden kunnen worden. Er dient een markt gecreëerd te worden waarin ict-bedrijven lang blijvende producten kunnen leveren en onderhouden, terwijl de overheid zich bezighoudt met implementatie en beleid.’

De informatica-onderzoekers pleiten voor een open debat over een totaal andere insteek voor de automatisering bij de overheid. ‘Deze open brief is een aanzet. Samen met onze collega’s en studenten nemen we graag deel aan dit debat. Iedereen is uitgenodigd: we profiteren er tenslotte allemaal van.’

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

6,9


Lees meer over



Lees ook


 

Reacties

‘Kan dit niet beter aan marktpartijen overgelaten worden? De overheid bouwt zelf geen kantoren, graaft geen Maasvlakte, legt geen straten aan. De overheid treedt op als opdrachtgever, en huurt private partijen in voor uitvoering en beheer.'

De vergelijking gaat behoorlijk mank. Daardoor gaat ook het volledige pleidooi mank.
Bij de genoemde voorbeelden gaat het om harde producten, bij ICT gaat het meestal om cultuur en gedrag met daarmee gepaard gaande veranderende eisen en wensen. Waar je wel een bouwproject kunt hebben, kun je maar beter geen ICT-project hebben. Hooguit een veranderproject met ICT-componenten. Want: ICT-projecten komen in de problemen omdat het ICT-projecten zijn. Zie https://www.managementsite.nl/ict-projecten-falen-ict-projecten

Scope internationaal uitbreiden en dan incrementeel implementeren in een oververhitte markt met dirigent plasterk ?

"Ontkoppel de softwareapplicaties van de data". Het blijkt dat een mens nooit te oud is om te leren. Of misschien dat een geheel nieuwe generatie nodig is om de fouten van een (gemakzuchtige?) oude generatie in te zien en te verbeteren. Persoonlijk vind ik het (eindelijk) een "doorbraak" waar de meeste gebruikers al meer dan 50 jaar op wachten.

Encapsulation, de koppeling van data en (programma)functie, was een ontwikkeling die inzette in het begin van de jaren '70 van de vorige eeuw. Een groot deel van de ICT-cultuur is gebaseerd op de hieruit voortkomende OO (Object Orientation).

De PO (Proces Orientation) verdween hierdoor, immers, de ontwikkeling van statische programmatuur was (veel) eenvoudiger dan de dynamische procesbenadering. Dat begon al in de analysefase: de administratieve(!) procedures waren al geschreven en makkelijk te automatiseren. De real-time real-world processen waren ook gedocumenteerd, maar in een ander, specialistisch en niet begrepen (beeld)taalveld.

Het beste bewijs hiervoor is de autonome ontwikkeling van de SCADA (Supervisory Control and Data Aquisition) systemen na het midden van de jaren '70. De grote moeite die het nog steeds kost om deze "meet- en regel" applicaties te integreren in de mainstream van de automatisering zal met de het doorzetten van het IoT alleen maar toenemen.

De laatste aanbeveling, kennis opbouw, dient m.i. ontkoppeld te worden van de "oververhitte markt". Die markt levert niet de specialisten en dus de producten waar behoefte is: Control and Data Acquision. Wellicht is het nog belangrijker om het - relatief eenvoudige - management taalveld te verrijken de Real-Time Real-World (taal)aspecten...

Interessant artikel. Het is al jaren een trend om meer gebruik te maken van kennis en kunde van marktpartijen. Waar het artikel echter aan voorbij gaat is dat het uiteindelijke succes hiervan sterk afhankelijk is van het vermogen om opdrachtgeverschap goed in te vullen door een adequate regievoering over de integrale keten van interne organisatie tot en met ketenpartners. Bij afwezigheid daarvan is de overheid nog verder van huis!

@Nico Viergever, helaas zit dat artikel achter een betaalmuur.
Maar hier vond ik een relevant stuk: http://www.logistiek.nl/supply-chain/nieuws/2015/5/defensie-stopt-met-miljoenen-verslindend-speer-project-101133769

Daar is jouw quote sterker dan je reactie hier. Neemt niet weg dat misschien beide opmerkingen valide zijn - van jouw en die van Sander Hulsman.

Een tussen organisatie bij de overheid om ICT projecten te ontwikkelen voor de overheid is waarschijnlijk onwenselijk an sich. Maar dan ook nog in de vorm dat ICT vernieuwing kennelijk als doel wordt gezien ipv als middel om de proces en cultuur veranderingen te ondersteunen, is natuurlijk helemaal desastreus.

Geen enkele opdrachtgever of vorm van opdrachtgeverschap zal daar verandering in brengen ben ik bang. Hoe kunnen we dit als ICT Industrie samen met de overheid aanpakken? Met alleen de opmerkingen in dit artikel gaan we het niet redden.

Joost,
Geen betaalmuur, gratis registratie is voldoende.
Overigens eens met jouw mening.

Nog kort geleden onthulde Zembla de problemen die ontstaan op het moment dat een overheidsorgaan niet meer weet wat er in de eigen soft- en hardwareomgeving gebeurt omdat een bedrijf van buiten die kennis heeft. Die kennis moet in huis zijn en blijven en de overheid moet daarbij zelf aan het stuur zitten.
Het grootste probleem is de politiek, die vandaag iets besluit en wil dat het morgen geïmplementeerd is. Bovendien worden adviezen om rekening te houden met de IT gevolgen van een besluit veel te licht beoordeeld. Kijk maar naar de decentralisatie van het sociale domein, de PGB ellende, de toeslagen bij de Belastingdienst, het nieuwe GBA, etc., etc.

Er is een begin gemaakt met een centrale IT beoordeling, maar de stem van IT en de gevolgen moet veel zwaarder wegen om de waan van de politieke dag te smoren.
En dan EG tender procedures. Een kostbare plaag.

@nico, Gratis of niet, waarom moet ik registreren om jouw opinie te kunnen lezen. Plaats het dan gewoon publiekelijk. Maar dat terzijde.
Ik ben het volstrekt oneens dat ICT projecten mislukken omdat het ICT projecten zijn. En dat ICT projecten ineens heel anders zouden zijn dan een kantoorpand bouwen, omdat die eerste ineens om cultuur en gedrag zouden gaan. Ook bij kantoorpanden worden de eisen en wensen tijdens de bouw aangepast, veranderd en bijgewerkt. Ook daar ligt het gehele ontwerp niet vast als het gat voor de fundering gegraven wordt. En zelfs bepaalde onderdelen moeten nog ontworpen worden terwijl het beton al ligt te drogen. Maar daar waar we dat bij bouw en industrie onder controle hebben, en niet eerder beginnen voordat een aantal basale zaken afgekaart zijn, lijken we dat bij ICT Projecten nog lang niet onder de knie te hebben. Het is een gegeven dat het lastig is om een kantoorpand met een oppervlak van 500m2 te bouwen op een fundering van 200m2. Dus wordt er voor gezorgd dat voordat die fundering gestort wordt, dat het expliciet en impliciet vast staat dat het gebouw dat er op komt gedragen kan worden door de fundering. Want achteraf kan je dit niet meer wijzigen, alleen nog maar slopen en opnieuw beginnen. Maar bij ICT projecten laten we het toe dat het fundament slecht ontworpen en slecht gebouwd wordt, dat iedereen maar met nieuwe eisen kan komen die het noodzakelijk maken dat we aan het fundament gaan sleutelen, en iedereen mag het kantoorpand bijstellen zonder zich af te vragen wat dit met het fundament doet. Dat is waarom zoveel ICT projecten falen. Er zijn maar weinig kantoorpanden die er 'gereed' ineens heel anders uit zien dan de tekeningen van de architect. Maar er zijn maar heel weinig ICT projecten waarvan het resultaat in lijn is met de ontwerpen van de architect.

Ik heb eerlijk gezien nog geen enkel ICT Project gezien dat tot doel heeft Cultuur of Gedrag aan te passen. ICT zorgt voor automatisering en efficientiëring van processen. Dat heeft nul komma niks met cultuur te maken.

Als we nou eens management methodologieen van de 'Maak' wereld gaan toepassen op de ICT wereld, dan denk ik dat we een stuk meer successvolle ICT projecten gaan zien.

Laat de overheid de opdracht-gever rol vervullen, de specificities en eisen vast stellen, en de enterprise architectuur opstellen en bewaken. Laat de markt het ontwerp en de implementatie verzorgen. Maar hou je aan je ontwerp, stel bij waar nodig maar bouw je pand niet groter dan je fundering aan kan.

@Rik, Als jij zelf achter het stuur van je auto zit, weet je dan precies wat er in de motor van je auto gebeurt, of hoe je navigatie de route berekend ? Nee toch ? want dat interesseert je niet, je eisen zijn dat je droog zit, en van A naar B komt.
Waarom zou de overheid moeten weten of er onder een financieel systeem software van SAP, Oracle, Exact of Microsoft zit. Waar het om gaat is dat de financiële verwerking correct en vlot verloopt.
De overheid moet de architectuur, de procesdefinitie en de functionaliteit in beheer houden, maar zich niet bemoeien met welke soft of hardware dit uiteindelijk gaat implementeren.

"Ontkoppel de softwareapplicaties van de data". Het blijkt dat een mens nooit te oud is om te leren. Of misschien dat een geheel nieuwe generatie nodig is om de fouten van een (gemakzuchtige?) oude generatie in te zien en te verbeteren. Persoonlijk vind ik het (eindelijk) een "doorbraak" waar de meeste gebruikers al meer dan 50 jaar op wachten.

Encapsulation, de koppeling van data en (programma)functie, was een ontwikkeling die inzette in het begin van de jaren '70 van de vorige eeuw. Een groot deel van de ICT-cultuur is gebaseerd op de hieruit voortkomende OO (Object Orientation).

De PO (Proces Orientation) verdween hierdoor, immers, de ontwikkeling van statische programmatuur was (veel) eenvoudiger dan de dynamische procesbenadering. Dat begon al in de analysefase: de administratieve(!) procedures waren al geschreven en makkelijk te automatiseren. De real-time real-world processen waren ook gedocumenteerd, maar in een ander, specialistisch en niet begrepen (beeld)taalveld.

Het beste bewijs hiervoor is de autonome ontwikkeling van de SCADA (Supervisory Control and Data Aquisition) systemen na het midden van de jaren '70. De grote moeite die het nog steeds kost om deze "meet- en regel" applicaties te integreren in de mainstream van de automatisering zal met de het doorzetten van het IoT alleen maar toenemen.

De laatste aanbeveling, kennis opbouw, dient m.i. ontkoppeld te worden van de "oververhitte markt". Die markt levert niet de specialisten en dus de producten waar behoefte is: Control and Data Acquision. Wellicht is het nog belangrijker om het - relatief eenvoudige - management taalveld te verrijken de Real-Time Real-World (taal)aspecten...

Het feit dat softwareontwikkeling en beheer bij bvb de politie compleet in eigen beheer is, heeft te maken met de vertrouwelijkheid van de opgeslagen data. Als systeembeheerder bij deze organisatie word ik dagelijks geconfronteerd met deze materie, het zou een slechte zaak zijn als deze, soms zeer vertrouwelijke data, in handen zou komen van de georganiseerde criminaliteit. Zelfs het feit dat naw gegevens van dienders in bepaalde gevallen in handen is van externe partijen zorgt voor veel onrust binnen het korps, de personen willen namelijk niet dat uitlekt waar men woonachtig is en wat men doet, deze informatie trekt namelijk de aandacht van bevolkingsgroepen die hiermee schade aan kunnen richten.

In de reacties op dit prima artikel is al een hoop gezegd, maar ik ben van mening dat de overheid de complexiteit van IT projecten onderschat en gewoonweg niet de kennis en ervaring in huis heeft om deze projecten succesvol in te vullen. IT is de afgelopen jaren steeds ingewikkelder geworden. IT projecten vereisen nu simpleweg speciale kennis enervaring. Het gezegde ' Schoenmaker, hou je bij jouw leest' is hierbij absoluut van toepassing. De overheid heeft helaas de vereiste kennis ern ervaring niet in huis, want het is simpelweg NIET hun 'core business'. Vroeger liepen sommige Ministeries weliswaar voorop in de IT ontwikkelingen (o.a. Defensie), maar de ontwikkelingen zijn zo snel gegaan met als gevolg dat op dit moment alleen nog (gespecialiseerde) commerciele bedrijven in staat zijn om deze ontwikkelingen te volgen (dit zijn vooral de bedrijven die IT transformaties/projecten tot hun core business hebben gemaakt). De overheid zou zich inderdaad moeten richten op goed 'opdrachtgeverschap' en moeten durven delegeren. Natuurlijk zijn er altijd commerciele bedrijven, die ook hun beloften niet kunnen nakomen, maar ik weet zeker dat er genoeg commerciele bedrijven die wel hebben bewezen om grote IT projecten tot een succes te maken. Er zijn genoeg (internationale) voorbeelden, maar helaas denk de overheid nog te vaak dat zij 'bijzonder en uniek' is en wil zelf de 'regie' behouden.....en dan gaat het fout (SPEER, PGB, GBA, Politie IT, etc.).
Ik ben het dus in grote lijnen eens met het artikel en vind dat de overheid zich 'bij haar core business moet houden' en geen IT regie moet voeren!

1 aspect mis ik in het verhaal.

De rol van de opdrachtgever. Waar in commerciële omgevingen als projecten ontsporen de boel op scherp gezet wordt, er gesneden wordt in functionaliteit of een leverancier vanwege wanprestaties verzocht wordt het pand te verlaten lijkt dat in overheidsland zelden te gebeuren.

Complexiteit komt uit Den Haag, en met nagenoeg elke wet wordt er meer complexiteit en uitzonderingen toegevoegd, die vaak binnen een half jaar al effectief moeten zijn. Waarbij in de Tweede Kamer zelden gekeken wordt wat de impact en risico's zijn van de bijbehorende ICT aanpassingen.

En als dan een project gestart is, dan is er geen weg meer terug, want Den Haag zegt dat het moet. En gaat men er alles aan doen om te voorkomen dat men zelf niet degene is in de keten die met de billen bloot moet, omdat er niet geleverd kan worden. Want moeilijke en harde keuzes maken wordt vaak gewaardeerd in het bedrijfsleven (men begrijpt het belang) maar bij de overheid werkt het niet.

De ICT (nog) meer op afstand zetten gaat die kloof vrees ik alleen maar vergroten. Maar de andere optie is een cultuurverandering (gevolgen overzien van de gemaakte keuzes en verantwoordelijkheid nemen) en wellicht is die nog lastiger.

Het doen alsof ICT net zoiets als een zwaar gestandaardiseerd product als een auto is, is kul. De vervlechting van ICT in het organisatieproces gaat zo ver, dat je echt niet los van elkaar zit. Een ander aspect bij de vergelijking van een auto (of videorecorder of scheerapparaat) is helaas dat veel mensen thuis een computer hebben, of op hun werk op hun bureau. Daar hebben ze wel eens een Acces programmaatje in elkaar geknutseld. Dat zie ik iemand niet zo snel met het de chip die het motormanagement van je auto regelt doen.
Maar het grootste cruciale verschil is dat ICT helemaal niet gestandaardiseerd is: dat suggereren alle vierkleurenfolders wel, maar mijn ervaring is dat dat gewoonweg niet zo is. Er gebeurt veels te veel tussen het stuur en de motorkap (die staat soms wagenwijd open). Dat is voornamelijk het gevolg van de hevige concurrentie binnen het ICT vakgebied. Zodra de marges dalen, zal de gehele keten, vanwege lijfsbehoud uiteindelijk wel moeten standaardiseren. Er moet nog heel veel water door iets gaan lopen, willen we daar eindigen.

"Laat overheids-ict geschikt voor meerdere landen ontwikkelen door internationale marktpartijen."
staat gelijk voor: start een monsterlijk Europees breed project. Wat nationaal niet lukt, zal met 26 landen wel lukken. ik geloof er niet in...sorry...

"Implementeer nieuwe overheidssystemen op een incrementele wijze."
"Bouw kennis op over de beste vorm voor systeemontwikkeling voor de publieke sector"
One size fits all bestaat niet in de IT. Helaas....teveel 'incrementele projecten' gezien die maar oneindig doorgingen zonder ooit naar productie te gaan. Bovendien, als je een bestaand toeslagsysteem vervangt , kun je niet beginnen met minimum viable product.
Nieuwe architecturen (BPM/SOA, realtime) zijn niet compatible met oude architecturen (mainframe, batch oriented). Je kunt dus niet incrementeel vervangen zonder het erg complex te maken.

De overheid blijft verantwoordelijk voor de regie: portfolio, budget, projectmanagement, architectuur, businessanalyse, integratie, beveiliging, procesontwerp, testmanagement, kwaliteit, acceptatie, implementatie etc. Blijft het programmeerwerk over om uit te besteden. Welk probleem los je daarmee op? Vervangen programmeren door configureerbare tools (procesengines, rules engines, Model-driven development). Lijkt mij eenvoudiger

IT projecten mislukken in grote organisaties, doordat organisatie zijn opgeknipt in domeinen. De domeinen zijn afhankelijk van elkaar, maar hebben ieders een eigen budget, prioriteitstelling en 'roadmap'. Vervolgens sluit het geheel niet op elkaar aan en is 50% van de IT organisatie bezig met onderling 'afstemmen'. Met uitbesteden los je dat niet op.

De overheid in de 'regierol': google eens op 'belastingdienst ETPM '
korte samenvatting: 10 jaar ellende, 203 miljoen verloren.

Commerciele ICT leveranciers verdienen overigens meer aan mislukte projecten dan aan geslaagde projecten.

Sjaak en Slinger, zo lang het echt om "bouwen" gaat kan dit misschien nog wel werken, Maar laat IT-leveranciers alsjeblieft niet voor je uitzoeken wat je wil hebben. En als je dan goed weet wat je hebben wil, dan zal duidelijk zijn dat het bouwen en het daarop volgende beheren veel sneller en goedkoper kan. Waarmee de inzet van IT-leveranciers, nationaal of internationaal, automatisch minimaal kan blijven. Zo wordt ook gelijk de huidige scrum/agile hype gerelativeerd (en dus jullie incrementeel advies).

Het draait er voor de overheid om als opdrachtgever zelf heel goed te blijven weten wat gebeurt. Hou altijd zelf regie, en wordt een goed opdrachtGever. Dat je dan geen "ICT-bedrijf" wordt is vooral logisch en kan haast niet anders.

Ps. Het scheiden van programmatuur en data is al vele decennia bekend, maar dat principe wordt systematisch genegeerd door de IT-wereld. Als je dat wel zou hanteren heeft dat immers grote consequenties. Bijvoorbeeld de keuze van "software" wordt dan altijd tweede plan, omdat je data/informatie uitgangspunt is en als opdrachtgever ben je de enige die kunt bepalen wat informatie is. Dat haalt veel IT-leveranciers uit de markt, want die verkopen SAP, Oracle..... software.

@Fred Streefland, zijn stelling: "...vind dat de overheid zijn bij haar core business moet houden en geen IT regie moet voeren.."

Het klopt dat IT kennis en kunde steeds gespecialiseerder wordt vanwege innovatie, complexiteit en snelheid. Dus uiteraard moet de overheid gebruik maken van marktpartijen.
Echter, de kern van van de digitale transformatie is dat IT juist onderdeel is van de core business en je die twee steeds moeilijker kunt scheiden. Multi disciplinaire teams (MDT's) zijn nodig om oa steeds veranderende eisen, prioriteiten en (on)mogelijkheden snel en goed goed op elkaar af te stemmen. Elke klantorganisatie is daarbij minimaal verantwoordelijk voor de kaders (zoals architectuur, security, privacy,..), behoeftestelling, prioriteiten, budgetten, sourcing. Dat is een onderdeel van goede regievoering!
Mijn stelling is dat door digitale transformatie juist de noodzaak vanuit de core business onstaat voor integrale (en functionele) regievoering over ketens die lopen over zowel interne en externe partijen. Dat vraagt om nieuwe competenties!

In aanvulling op de vele reacties. M.i. ligt de belangrijkste oplossing voor het falen van ICT-projecten bij de (lokale) overheid in verder dereguleren. In de V.S. en de U.K. lachen ze zich ongetwijfeld dijenkletsend om het falende BRP-project en de bovenliggende drang om alles van ons vast te leggen (beide landen hebben geen GBA). De 'waarom' vraag voor die drang voor het registreren ligt voor een belangrijk deel in al die (sociale en belasting) voorzieningen die we gestapeld hebben. Er zijn nog steeds gemeenten die hondenbelasting heffen, zucht.... En daar dus een ICT-systeem voor moeten hebben. En we weten allemaal dat de administratie van de Postcodeloterij betrouwbaarder is dan de GBA. Een wetgeving of regel opheffen is weer een ICT-systeem minder. Geen OZB>geen WOZ-administratie. Wat je niet registreert>kun je niet lekken. Daarbij wil ik pleiten voor nog een stap verder: In veel gevallen is ICT bij de overheid nodig voor de uitvoering van taken die ook door de private sector kunnen worden uitgevoerd. Krimp de overheid tot een politiek orgaan (even de zwaailichtsectoren en defensie buiten beschouwing gelaten) en de bijbehorende ICT is geen overheidsprobleem meer, ook niet in de regie, want daar blinkt de overheid nou ook niet bepaald op uit. Pas dan kun je ook internationaal oplossingen delen. Deze trend is overigens ook al langer ingezet in het bedrijfsleven: ICT niet als kernactiviteit>ICT outsourcen. Net als de loodgieter.

Goede resultaten vereisen goed opdrachtgeverschap: correct. En laat dat nu precies het grote probleem bij de overheid zijn....
Want dat vereist kennis die (nog) niet aanwezig is.
NB. Hierin verschilt de overheid niet echt veel van veel andere grote instellingen trouwens...
Maar gelukkig heeft de overheid zich dit enkele jaren geleden ook al gerealiseerd (weliswaar onder dwang van buiten) met als resultaat: Bureau ICT-Toetsing (BIT).
https://www.rijksoverheid.nl/onderwerpen/digitale-overheid/toetsing-ict-projecten-overheid

Helaas zijn de aanbevelingen nog niet dwingend, maar het is een goede stap. :-)

@ Atilla:
Het doen alsof ICT net zoiets als een zwaar gestandaardiseerd product als een auto is, is kul. De vervlechting van ICT in het organisatieproces gaat zo ver, dat je echt niet los van elkaar zit.

Helemaal mee eens. Maar dat betekent ook dat je een ICT project niet als een ICT project moet zien, maar als een project dat je organisatieprocess of je bedrijfsproces gaat aanpakken (en dat kan Verbeteren, Versnellen, Automatiseren, of wat dan ook zijn).

Maar als je naar de overheids-ICT-debacles van de laatste tijd kijkt, dan zie je dat deze ICT projecten er helemaal niet op gericht zijn een overheids process aan te pakken, maar puur om technologie naar binnen te kruien dat dan magisch het procesprobleem zou gaan oplossen. En daar wringt de schoen.

SPEER zou iets dat process-ologen binnen Defensie al decaden niet lukte (stroomlijnen van processen) wel effetjes oplossen door er SAP tegenaan te gooien. Het BRP project zou hetzelfde effetjes doen met de gefragmenteerde persoonsregistraties. Noem ze maar op.

Begin nou eens eerst met goed te definieren welk problem je wilt oplossen, en hoe je dat wilt doen. Als je dat beschreven hebt, kijk dan terug of je oplossing ook daadwerkelijk het problem aan gaat pakken (for which problem is this a solution). En begin dan simpel en bij de basis.

@Erwin, helemaal mee eens.
Probleem in een politieke en silo gerichte organisatie als defensie zal vermoedelijk gelegen zijn dat men geen gemeenschappelijk belang ziet. Wat mij betreft een paar van die generaals in een hok en de koppen tegen elkaar, anders word het aardappels schillen.

@Dick van Elk,

In mijn optiek geef je een onjuiste voorstelling van zaken in je reactie.

In de eerste plaats suggereer je dat bij object oriëntatie geen sprake zou zijn van ontkoppeling, aangezien encapsulatie juist een sterke koppeling van data en (programma)functie bewerkstelligt. Object oriëntatie maakt echter wel degelijk ontkoppeling mogelijk; niet van data, maar van functionaliteit: programmacode wordt uit de bedrijfsapplicaties gehaald en uniek vastgelegd binnen de objectklassen (of bottom up wordt bedrijfsfunctionaliteit direct al binnen de objectklassen vastgelegd).

Binnen bedrijfsapplicaties kreeg Object Oriëntatie (OO) haar vervolg met Service Oriënted Architecture, hetgeen een ontkoppeling mogelijk maakt van bedrijfsobjecten, functionaliteit, flow en presentatie en heel basaal dus leidt tot een 4-lagen architectuur.

Ontkoppeling, juist opgevat, leidt dus niet tot een scheiding van programma en data (en daarmee dus een bestendiging van het procesdenken), maar tot zwak gekoppelde bedrijfsobjecten en applicaties, zie bijvoorbeeld: https://en.wikipedia.org/wiki/Loose_coupling.

En daarmee kom ik op de tweede onjuistheid in je visie, namelijk je stelling dat door het toepassen van de object oriëntatie binnen IT de proces oriëntatie is verdwenen. Nu ben ik het met je eens dat object oriëntatie ten koste gaat van proces oriëntatie (en vice versa); echter, de object oriëntatie is inderdaad beperkt gebleven tot de programmamodulen van ICT (door toepassing van programmeertalen als C++, Java, etc.) en heeft zich binnen SOA niet adequaat doorgezet richting het businessdomein als gevolg van.... een aanhoudende proces oriëntatie door architecten en management. Op bedrijfsniveau is het procesdenken wat de klok slaat: Business Process Management, Event Driven Architecture, Straight Through Processing, Orkestratie, Ecosystemen, Microservices, noem maar op. Precies door dit aanhoudende procesdenken is SOA nog steeds niet voldoende van de grond gekomen, aangezien het, in combinatie met BPM en/of EDA, nog steeds in de markt wordt gezet als een vorm van procestechnologie en niet als een vorm van kennistechnologie.

Je pleidooi voor meer proces oriëntatie is dus rampzalig, aangezien de gerichtheid op processen nu al als hoofdoorzaak van de, miljarden kostende, ICT-faalindustrie kan worden aangewezen.

Toch formuleer je in je reactie een schitterende uitweg uit de huidige malaise:
“immers, de ontwikkeling van statische programmatuur was (veel) eenvoudiger dan de dynamische procesbenadering”.

Zijn is blijkbaar eenvoudiger dan worden!

En dat heb je in het verleden ook al eens schitterend verwoord:
“Een architect ontwerpt een ruimte waarin het aangenaam is om te leven...”.

"Overheid moet zich niet voordoen als ict bedrijf".
Private partijen zouden moeten worden ingehuurd, lezen we.

Dan vraag ik me af : Dick of Jack ? Of om de beurt ? Of samen, multidisciplinair zegmaar ;-)

Ik krijg alweer hoofdpijn.

Ik kan me de voorstelling van de auteur, en de aangehaalde doctoren wel een beetje uit tekenen maar ook die maken meteen weer de cruciale fouten die je telkens weer ziet opdoemen. Je benoemt een volkomen voorspelbaar faalscenario om dan even verder op, te komen met een discipline specifiek scenario of oplossing en de onderbouwing waarom je dat dan op die manier toch zou moeten doen.

We kunnen zo maar twee dingen concluderen.
Er zijn twee 'common denominators', van de vijf, die telkens weer aan de basis liggen van grotere en kleinere falen, genaamd commercie en politiek, en die twee die versterken elkaar wanneer die samen aan 'iets' beginnen. Dat zie je overigens ook in het bedrijfsleven gebeuren alleen acteert het bedrijfsleven eens stuk sneller en concistenter. Een Atos, Yacht, BT, Centric, Caps, Michael Pages, die zo zouden acteren als nu bij overheden zouden in het bedrijfsleven nooit meer aan de bak komen of meteen tot failliet worden geprocedeerd.

Digitaal automatiseren, 0 Fault Tolerance
Bij de overheid lopen er allemaal ambtelijke baasjes, van hoog tot laag, die van alles in de melk te brokkelen hebben waar het hun eigen IT aan gaat, en als klant kan ik me daar wel in vinden, maar niemand daar blijkt verstand te hebben van digitaal automatiseren. Aan de andere kant hebben wij de conmecriele toeleveranciers, die met hyperig hijgen zich een weg baant door de niet aflatende stroom van overheids aanbestedingen, wetende dat dat voor hen vrijwel altijd KASSA is. In de commerciele sector schijnt iedereen het ei van columbus te bezitten maar heel erg weinig die begrijpen wat digitaal automatiseren nou eigenlijk in houd en hoe dat nou werkt. Gezien het BIT debacle van een commissie Ton Elias, is men niet in staat gebleken de angel uit het probleem te trekken.

Een leverancier zal zijn toekomstige opdrachtgever niet benadelen en de betreffende falende ambtenaar heeft uiteraard zelf nooit ergens schuld aan en doet niet aan nestbevuiling en zou houden beiden het probleem gewoon in stand. Op naar het volgende IT debacle bij de overheid die, 100% gegarandeerd, vast wel weer in de maak is.

Het eenvoudige antwoord,
Tenminste, my 3cts 'worth, befin eerst eens met de basis definitie van digitaal automatiseren over te brengen op je klant. Er zitten namelijk nogal wat regeltjes en do's en don'ts aan, regetjes die door beide partijen met grote regelmaat met voeten worden getreden. ALs je dat hebt vast gelegd, begin dan met je IT opnouw, u weet wel, de poppetjes, tools, trucjes, processen en procedures waarmee je digitale automatisering bedrijft.....

Gaat u nu een lampje branden?

Mooi...

Jouw reactie


Je bent niet ingelogd. Je kunt als gast reageren, maar dan wordt je reactie pas zichtbaar na goedkeuring door de redactie. Om je reactie direct geplaatst te krijgen, moet je eerst rechtsboven inloggen of je registreren

Je naam ontbreekt
Je e-mailadres ontbreekt
Je reactie ontbreekt
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

×
×