Managed hosting door True

Rekenkamer: Speer kost Defensie 900 miljoen

'Trage invoering vormt gevaar voor benutten voordelen erp-systeem'

 

Het ict-programma Speer (Strategic process and enabled reengineering) gaat het ministerie van Defensie zo'n negenhonderd miljoen euro kosten. Dat is bijna een verdubbeling ten opzichte van de huidige 481 miljoen euro die het ministerie hiervoor vrijgemaakt heeft. Dat stelt de Algemene Rekenkamer. Ook moet Defensie veel meer werk maken van de voortgang ervan, want hoe langer gewacht wordt, hoe langer het duurt voor de voordelen van het nieuwe systeem benut kunnen worden. Defensie rechtvaardigt de hoge kosten voor Speer tot nu toe altijd omdat met de invoering ervan grote besparingen te behalen zouden vallen.

Het project Speer is een van de grootste en langstlopende ict-projecten van de rijksoverheid. In mei 2000 startte het ministerie van Defensie een aanbesteding voor de levering van materieel-logistieke programmatuur (zogeheten software voor erp: enterprise resource planning) en het onderhoud daarop. Alle krijgsmachtdelen stappen over op dit ict-systeem dat op SAP is gebaseerd. Ook werden er aanbestedingen uitgeschreven voor advies-, implementatie- en migratiepartners. Het project liep de afgelopen jaren diverse malen vertraging op. Afronding ervan, er zijn wel al delen in gebruik, staat nu gepland voor medio 2015 (was oorspronkelijk 2012). Daarbij gaat het om de basisfunctionaliteit.

Volgens Defensie liggen de kosten voor Speer inmiddels op 481 miljoen euro (was in 2004 165 miljoen euro, exclusief twintig miljoen euro licentiekosten). De Algemene Rekenkamer schat in dat de totale kosten tot halverwege 2013 ongeveer 650 miljoen euro bedragen. Voor het afronden van het implementatietraject en de noodzakelijke doorontwikkeling is naar schatting van de Algemene Rekenkamer nog eens 250 miljoen euro nodig (zie kader 1).

Complex

Minister Jeanine Hennis-Plasschaert laat in een reactie weten deze bedragen niet te herkennen waarbij zij zich beroept op het feit dat het ict-project van voor 2008 stamt. Voor het inzichtelijk maken van de integrale kosten geldt pas vanaf 2008 het Rapportagemodel voor grote ict-projecten van het ministerie van Binnenlandse Zaken en Koninkrijksrelaties, stelt zij. De Algemene Rekenkamer vindt dat dit argument anno 2014 moeilijk vol te houden is, zeker gezien de herijking van het project in 2010 en de nog komende periode van doorontwikkeling.

De Algemene Rekenkamer heeft Speer de afgelopen jaren zeer kritisch gevolgd. In december 2012 stelde de rekenkamer nog dat de reorganisatie bij de krijgsmacht en de verschillende verbeterplannen voor beheerzaken in toenemende mate op gespannen voet staan met een succesvolle invoering van het erp-project Speer. Ook het verregaande ict-uitbestedingstraject dat Defensie heeft opgestart, maakt de zaak extra complex. Een onderdeel daarvan is een perceel voor het uitbesteden aan de markt van het functioneel beheer en applicatie-onderhoud.

Omvangrijke migratie

In de recente eindrapportage over Speer (zie kader 2) geeft het ministerie aan dat ongeveer 50 procent van de defensieonderdelen al zijn overgegaan op het erp-systeem. Enkele belangrijke defensieonderdelen moeten echter nog migreren, zoals de onderhoudsbedrijven en de belangrijke wapensystemen van de Marine en de Luchtmacht. Bovendien zijn door de gekozen migratiestrategie gebroken ketens ontstaan, die het ministerie pas aan elkaar kan verbinden wanneer alle systemen en eenheden volledig op Speer over zijn.

 Het ministerie beoogt door het implementeren van een erp-systeem vier doelen te realiseren, te weten:

1. Een effectievere materieel-logistieke ondersteuning van operaties;

2. Het ondersteunen van het nieuwe besturingsmodel;

3. Het realiseren van een besparing van 1030 voltijdseenheden en een vermindering van de exploitatiekosten met tachtig miljoen per jaar;

4. Het verbeteren van de informatievoorziening door sanering van de vele Iegacy-systemen.

Vaart maken

In het huidige adviesrapport waarschuwt de rekenkamer de minister meer vaart te maken met het project en scherpere deadline te stellen dan medio 2015, waar Defensie het over heeft als het gaat om de invoering van de basisfunctionaliteit. Een degelijk plan van aanpak is nodig om het implementatieproject goed aan te sturen en te beheersen. Ook de plannen voor de doorontwikkeling moeten sneller opgepakt worden waarbij informatie over alle samenhangende kosten van de belangrijkste wapensystemen een plek krijgt. Hoe langer gewacht wordt, hoe langer het duurt voor de voordelen van het nieuwe systeem benut kunnen worden, aldus de Algemene Rekenkamer.

De minister zal in het voorjaar 2014 de Tweede Kamer informeren over het plan van aanpak van de uitgewerkte roadmap en over de planning en realisatie ervan in de voortgangsrapportages Speer (implementatie erp). Afgelopen oktober vond bij het Rijk nog een toets plaats van de basisimplementatie erp in het kader van een Gateway Review. De resultaten hiervan zijn daarna besproken in een rondetafelgesprek met de Algemene Rekenkamer. De risico's en aanbevelingen die tijdens deze review en het rondetafelgesprek zijn genoemd, zijn meegenomen in de uitwerking van de roadmap, aldus Hennis-Plasschaert.

Kosten

Het ministerie van Defensie heeft het programmabudget in de afgelopen jaren diverse malen herijkt en het budget steeds naar boven aangepast. Anno 2013 bestaat het programmabudget van circa 481 miljoen euro uit de volgende kostenposten:

• Investeringen in erp: 276 miljoen;

• Exploitatievoorbereiding: 125 miljoen

• Aanpassingen van Iegacy-systemen: 32 miljoen;

• Dubbele beheerslasten: 48 miljoen.

Volgens de Algemene Rekenkamer is de Tweede Kamer hierover steeds geïnformeerd via de halfjaarlijkse voortgangsrapportages Speer. Maar in deze voortgangsrapportages bleven verschillende kostenposten buiten beschouwing, waaronder:

• De kosten van de migratie van een volledig wapensysteem;

• De inzet van eigen personeel in de programmaorganisatie;

• De kosten voor opleiding en training;

• De doorontwikkeling van erp na beëindiging van het programma.

De Algemene Rekenkamer schat daardoor de totale kosten tot halverwege 2013 veel hoger in, op ongeveer 650 miljoen euro. Voor het afronden van het implementatietraject en de noodzakelijke doorontwikkeling is daarnaast nog ongeveer 250 miljoen euro nodig.

Evaluatie

Het ministerie heeft naar aanleiding van de uiterst moeizame invoering van Speer hierover een eindrapportage laten opstellen door adviesbureau HEC. De vijf hoofdconclusies hieruit zijn:

1. Bezuinigingsdruk stimuleerde de keuze voor een risico volle aanpak. Onder druk van bezuinigingen heeft het ministerie bij de start gekozen voor de meest risicovolle implementatiestrategie waarbij standaardisatie en integratie gelijktijdig plaatsvonden.

2. Ambitie en sturing sloten niet op elkaar aan. Aanvankelijk ontbrak een centrale sturing op het project en sloop de verzuiling van het ministerie het project binnen. Dit bemoeilijkte het standaardiseren van de werkprocessen.

3. Er ontbrak een visie op de samenhang tussen verschillende verandertrajecten. Een samenhangende besturing van de reorganisatietrajecten en de implementatie van erp ontbrak in het begin.

4. Oud en nieuw naast elkaar ondergroef het draagvlak. Het langdurig naast elkaar bestaan van een oude werkwijze ondersteund met de legacy-systemen en een nieuwe werkwijze ondersteund met het erp-systeem leidt er toe dat de voordelen van het nieuwe systeem niet zichtbaar worden en het draagvlak voor het nieuwe systeem afneemt.

5. Nieuw systeem dwingt innovatie niet af. Anders dan aanvankelijk werd verondersteld, dwingt het gekozen erp-pakket verbetering van de werkprocessen niet af. Innovatie van werkprocessen vindt alleen plaats als daar expliciet op wordt gestuurd.

Bron: Eindrapportage Programma Speer - Terugblik bij invoering erp bij Defensie. Ministerie van Defensie en PBLQ HEC (SDU, 2013).

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

8


Lees meer over



Lees ook


 

Reacties

600.000.000 euro
ha ha ha ha.
Waarom geen open ERP implententeren.
Is gratis...
Mogen ze mij inhuren om het te installeren en te configureren..
Zijn ze voor 50.000 euro klaar inclusief server.

Corne,

1 server lijkt mij voor Defensie ietwat aan de kleine kant.

Bij een project zoals dit komt natuurlijk wel wat meer kijken.

"Bezuinigingsdruk stimuleerde de keuze voor een risico volle aanpak"

Hmmm .. implicerend dat als er (nog) meer geld tegenaan was gegooid, het resultaat uiteindelijk goedkoper was geweest.

Klink als ambtenarenlogica.

@Corne
Dat je het bedrag heel hoog vindt kan ik mij goed voorstellen en een project wat al 14 jaar loopt is waarschijnlijk meerdere malen van scope veranderd waardoor het budget opgehoogd moest worden.

Maar om nu te beweren dat jij, in je eentje, voor 50K de juiste oplossing kan implementeren waar honderden specialisten je voor gingen, terwijl ze een organisatie van meer dan 10000 gebruikers moeten tevreden houden, vind ik wat kort door de bocht.

Goh, is ERP nu alweer in prijs vertienvoudigd?

Interessante Eindrapportage die veel verklaart.
Maar de Eindrapportage gaat helaas voorbij aan de echtere oorzaken waarom SPEER in de problemen is gekomen. Daarom ook deze reactie: http://www.viergever.info/nl/MinDefSpeer.aspx

Die bevindingen van het HEC waren bij het politie-debacle ook al zo grappig. Wat zullen ze een lol hebben als ze bij de totstandkoming elkaar lopen te overklassen. Wel een risico dat iemand de slappe lach krijgt bij de presentatie van zoiets. Dat iemand uit een of andere tweede Kamercommissie een vraag stelt en dat je het ineens niet meer houdt.

Daarbij wordt er binnen de overheid nog (zover ik weet) niet (veel) met Agile projecten gewerkt. Niet dat Agile de uitkomst is in hoge kosten. Maar zoals al was genoemd is de scope in de afgelopen (14 jaar!) meerdere malen aangepast. Verder speelt er denk ik nog een groot probleem. Aanbestedingen worden enkel verricht door bedrijven met een minimale omzet per jaar. De eisen daarvan zijn zo hoog dat maar enkele bedrijven hierop kunnen reageren. Gevolg is dat er amper marktwerking is en de prijzen hiervan ook gewoon hoog gehouden kunnen worden.

@Corne, er wordt zo vaak geroepen dat open source de uitkomst is. Dit is natuurlijk hardstikke naief. Je krijgt verzoeken van klanten voor aanpassingen naar hun wens (wordt stukje maatwerk omdat het afgestemd is op de wens van opdrachtgever). Daarnaast wil je niet altijd dat code makkelijk inzichtelijk is, het vormt een beveiligingsrisico. Ja het klopt, community kan vaak (door grote groep mensen) snel een update uitbrengen, maar op zo'n breed project met zoveel mensen is een update niet altijd direct uit te brengen, dit kan de nodige consequenties hebben bij implementatie (dat andere dingen niet werken).
De beste oplossing zou hierin zijn om vanaf een bepaald moment (release) de versie in eigen beheer te nemen. Toch kan ondanks het "wat sneller opzetten", een scope functionaliteit de structuur en architectuur zodanig aanpassen dat je meer tijd kwijt bent aan het doorvoeren van de wens (en daarop goed testen) als vanaf de grond zelf opbouwen.

Jammer dat de redactie de boel onnodig opklopt: 900 miljoen is niet vele malen meer dan 481 miljoen. Het is bijna twee maal zo veel. Dat is ernstig genoeg, maar stemmingmaken is een vak dat niet bij een objectieve redactie hoort.

"Het realiseren van een besparing van 1030 voltijdseenheden"

Vermoedelijk waren er 1030 redenen waarom dit project zo lang duurde/aangehouden werd. Ambtenaren zijn niet dom, maar het heeft er bij bezuinigingsvoorstellen telkens weer de schijn van dat ze hun eigen hachie redden.
Als ik de eerste delen van Nico zijn bevindingen lees ("zeer sterke zuilen die onderling niet altijd even bereid waren tot samenwerking"), is het project inmiddels beëindigd.
Helaas gaat dit wel om heel veel belastinggeld, waarvan een aantal grote jongens hebben kunnen snoepen ten koste van het resultaat.
Hoe kunnen we dat "ambtelijke" toch eens efficiënt maken?

Ruim 50.000 euro per werkplek? Absurd.
Ik onderschijf i.i.g. de visie dat men Open Source had moeten nemen. Zowel het OS als de softwarepakketten.
Dat had alvast 80% gescheelt op softwarekosten.
Die 20% kan dan worden gebruikt voor 't programmeren in Open Source. Voordeel is dan ook dat je bevriende landen die software ook kunt geven. En wellicht geven ze dan ook wel eens iets terug. Goed voor de wereldvrede.

Het verbaast mij vooral dat er een eindrapportage opgeleverd is, terwijl naar verwachting de afronding van het project pas in 2015 zal zijn. Betekent dit dat er tot de afronding geen rapportages meer zullen zijn en men dus in feite carte blanche heeft?

Het lijkt er in ieder geval op dat er een paar basisregels uit de projectmanagementtheorie (Prince2 in het geval van defensie) niet gehanteerd zijn....

Er zijn een aantal partijen die veel aan Defensie gefactureerd hebben (Cap, IBM/Ordina, Atos, Logica). Niet dat het veel heeft opgeleverd, op dit moment (na zo'n 10 jaar) is nog geen 30% van de geplande functionaliteit opgeleverd. Alleen de accountmanagers hebben de zakken gevuld.

Verbeteringen doorvoeren om te bezuinigen, bijvoorbeeld op 1030 arbeidsplaatsen, is nooit een goede motivatie voor intern betrokken partijen. Het traject is dan van meet af aan geen kans, maar een bedreiging. Super belangrijk dus om aan het begin van zo’n traject uit te leggen hoe je die bezuiniging wilt realiseren zonder dat de betrokken mensen direct het risico lopen hun positie te verliezen. Het maakt daarbij niet uit of het ambtenaren zijn of niet. Meestal zijn mensen in een organisatie het wel eens met de doelstelling, maar zelden zijn zij het eens met de (wijze van) realisatie.

Een dergelijk ingrijpend traject als hier beschreven hakt er van meet af aan dus behoorlijk in. Als er geen duidelijke perspectieven worden geschetst gaat het nog tien jaar duren voor het klaar is, of alsnog wordt afgeschoten. Tegen die tijd zijn de belangrijkste potentiële “slachtoffers” inmiddels met pensioen. De meeste issues zijn dan op natuurlijk wijze opgelost. Traject geslaagd (?).

@Nico:
Uit uw link:
"Daarnaast de Eindrapportage duidelijk dat de Supervisor niet voldoende macht had om zijn taak naar behoren uit t"e voeren13:"
Volgens mij ontbreekt daar een woordje in uw PDFje :).

"Van de organisatie wordt verwacht dat hun doelen worden aangepast aan het middel. Dit is de belangrijkste reden voor mislukkende IT projecten en daarmee ook voor de problemen van SPEER. IT projecten duwen tegen een touw en proberen daarmee degene die het touw aan de andere kant vasthoudt, in beweging te krijgen."
Inderdaad denk ik dat doel en middel teveel met elkaar zijn verward. Dat is regelmatig "common practice" bij grote ICT-projecten, i.p.v. "best practice".

Probleem is dat verantwoordelijken voor het falen van zulke projecten nooit gestraft worden.

@Corne:
900 Miljoen is weliswaar absurd, maar 50000 is ook verre van reëel voor een nieuw te implementeren totaal aan programmatuur voor een heel ministerie.

@mmm Maar ik denk dat de kosten niet in de software zitten. Overheid, een hele lastige organisatie. Van de grote dienstverleners had je de kennis mogen verwachten om een goede oplossing te bieden. En bij de overheid had je de kennis mogen verwachten om de geboden oplossingen te boordelen. Vraag is of dat het geval is geweest. Het zijn bizarre hoeveelheden geld al gaat dat heel hard met het inhuren van paar consultants en andere sturende IT professionals. Dan is een miljoen helemaal niets. Maar als er nog eens 250 miljoen bij moet dan zou ik het maar laten. Samen met het EPD bij het IT afval.

Als er bij Defensie een probleem is (en Speer lijkt me een probleem te zijn) is de eerste vraag: "Komt er bloed uit?" Zo ja, dan is het een geweldige organisatie die bijzondere prestaties kan leveren.
Zo neen, dan is het een ambtenarij onder druk en handelt ieder naar het motto "Je me maintiendrai" (Ik zal mij handhaven). De mensen die door Speer overbodig worden (1030 FTE's?) en zij die van hun vertrouwde software afscheid moeten nemen, hebben weinig redenen om van harte mee te werken.
In PRINCE2-termen: de Executive wil het, de Suppliers vinden het prachtig (Kassa!), alleen de Users…
Overigens: Wie was die Executive eigenlijk? De minister, een staatssecretaris (politici, na een paar jaar weer weg en elke keer andere prioriteiten) of een ambtenaar?

Het woord Agile viel hierboven. Misschien is het een idee om overheidsprojecten nooit langer te laten duren dan één jaar en te starten voor het einde van het eerste jaar van een kabinet. Met de onvermijdelijke uitloop is zo'n project klaar in het derde jaar, tegen de tijd dat het kabinet in kwestie valt.
(Voor lagere overheden, waar verkiezingen elke vier jaar plaatsvinden, kun je iets meer speling geven, als projecten maar voor de verkiezingen klaar zijn.)

@Karel Ja, die las ik ook al, Agile (wat is dat eigenlijk?) als het antwoord op alles, de u vraagt wij draaien IT. Van de hak op de tak, maar het idee een jaar vind ik een hele goede. Kan het niet in een jaar, niet doen. Overigens dacht ik bij Speer niet aan een wapen maar aan de bekende Duitse architect. Bouwen voor eeuwigheid maar niet in dit geval.

Grote dienstverleners bewijzen te vaak te groot te zijn voor dergelijke trajecten. Bovendien moeten te veel mensen eerst worden ingewerkt en grip krijgen op de omgeving en de materie. Het grootste deel van projectkosten betreft overhead i.p.v. productie.
Het zou veel verstandiger zijn interne mensen te betrekken bij de beoogde verbeteringen. Organisaties, ook de overheid, moeten hun eigen ervaren mensen serieus nemen: laat ze hun kennis en ervaring vastleggen. Laat ze vervolgens helpen om op basis daarvan verbeterde procedures te beschrijven en deze te implementeren in de organisatie (want vaak hebben zij die ideeën wel, maar beschermen zij hun positie – zoals in meerdere reacties wordt bevestigd). Vanuit deze praktijk kunnen zij wezenlijk bijdragen aan het leggen van een basis voor de ondersteunende software, zonder dat zij direct risico lopen. Immers, als het traject is afgerond kunnen zij afvloeien. Dat zouden zij zonder dat traject ook al doen, maar het verschil is dat zij op deze wijze een waardevolle erfenis kunnen achterlaten, in plaats van dat hun kennis verloren is gegaan en er een resultaatloos traject is gelopen met veel stress en kosten.

@Karel: er is in SPEER nauwelijks een spoortje te vinden van PRINCE2. Overigens had Agile (net als Open Source trouwens) geen verschil uitgemaakt. Het probleem lag niet in de uitvoering maar in de richting. Zie mijn reactie achter de hierboven ingediende link.

Het idee van kleinere projecten? Geen goed idee. In een discussie met een CIO heb ik dit ooit vergeleken met een bom. Een grote bom richt veel schade aan en is voor iedereen zichtbaar. Een clusterbom bestaat uit veel kleine bommetjes. Samen richten ze veel meer schade aan dan de grote bom maar elk kleiner incident komt niet over het voetlicht (aardig voorbeeld trouwens in de relatie tot Defensie).

Alleen die 14 jaar al zorgt ervoor dat de tijd elke doelstelling links en rechts inhaalt en het oorspronkelijke doel nooit gehaald zal worden. Het is triest dat de tijd dit teweeg brengt maar niet voor de ICT bedrijven want die kunnen lekker uurtje factuurtje bedrijven. .

Buiten alle eerder genoemde, vaak zeer terechte, argumenten...
het zoveelste drama op basis van SAP. En een aantal uitvoerende partijen die zich een slag in de rondte lachen

Zoals heel gewoon is bij Defensie heb je een minister die 'niets herkend' en getallen die niet verifieerbaar zijn. De waarde van het artikel? Alleen voor de ICT toeleverancier. Oh ja, en de belastingbetaler dan natuurlijk.

Tragisch.

Defensie wil graag dat de jaarrekening door de Algemene Rekenkamer goedgekeurd gaat worden. In het bijzonder de life cycle cost van de wapensystemen is een belangrijk onderwerp in deze. Gevolg vele top IT leveranciers en generaals ontmoeten elkaar op de hei. Strategische plannen en tactische keuzes het gevolg. Maar elke ERP docent stelt dat de bedrijfsprocessen eerst in kaart dienen te zijn gebracht en dat de organisatie in balans dient te zijn. (Taken en Middelen). Vele verandering managers bevolken het Haagse, plan over plan rolt over elkaar heen. Inmiddels reorganiseert Defensie driftig verder en de werkzame informele organisatie verdwijnt. De dienstverleners van Defensie (CDC en DMO) dienen paarse processen in te richten, maar er is geen enkele paarse klant (OPCO). Elke OPCO heeft zijn eigen, culture doelen en kent geen samenhang, ook niet in de missies. De BC volgens Prince 2 is geslaagd, immers de 1030 vte's zijn weg of doen (hopelijk) iets ander binnen Defensie. Open Source is een middel en Agile, Scrum, Waterval, V-model, enz. zijn methoden voor projectmanagement en software development ondersteuning.
Hoe nu verder ? Je verlies nemen. Financiële en Logistieke taken (bevoorrading) kan je de huidige modules blijven gebruiken. Systeemlogistiek uit SAP halen, ( SAP is hier helemaal niet voor geschikt en belangrijk is hanteer KIS ( Keep It Simpel.)

Een mooi overzicht van het Speer project al mis ik in de evaluatie te ambitieus al slaat risicovol waarschijnlijk op hetzelfde.

@NicoViergever Interessant rapport, daarin zeg je eigenlijk ook dat men voor een verkeerde weg gekozen werd door voor nieuwbouw te gaan. Over het idee dat projecten niet langer dan een jaar te duren. Het gaat niet om dat jaar maar over het kiezen voor kleinere en haalbare projecten met een overzichtelijke doorlooptijd. Ik denk dat het veel verstandiger is om bestaande systemen als uitgangspunt te nemen. Legacy is geen synoniem voor slecht! Natuurlijk is het voor de leveranciers financieel veel interessanter om voor de volledige nieuwbouw te gaan. Je schrijft ook dat het project een IT focus had en hier (nieuwbouw) ook op aangestuurd werd. Slechte zaak, de tunnelvisie. Het lijkt er wel op dat al die hele ambitieuze projecten bij de overheid waarvoor complete nieuwbouw gegaan wordt slecht verlopen. Denk overigens ook dat de opdrachtgever de inhoudelijke (technische) regie zou moeten hebben. Niet de IT leveranciers.

@DeHervormer De zin over 'werkzame informele organisatie' spreekt me aan, een zeer onderschatte factor. Het zijn de niet de procedures en regels die systemen maken en draaiende houden maar veel eerder die informele organisatie. Je conclusie is mooi, je verlies nemen en huidige onderdelen blijven gebruiken.

@Louis: Nee, ik zeg zeker niet dat het verkeerd was om voor nieuwbouw te gaan. Ik zeg dat IT een middel en geen doel is. Ik zeg dat SPEER ten onrechte SAP als doel zag. Dat SPEER geen zelfstandig programma had moeten zijn maar een ondergeschikt onderdeel van reorganisaties in de gebieden waar ERP als ondersteunend middel nuttig had kunnen zijn.

@DeHervormer: De BC volgens Prince 2 is geslaagd???
Dan snap je dus niets van PRINCE2.

Politieke bezuiningsdruk gecombineerd met punt 3 van evaluatie, gebrek aan visie. Dat kost nou eenmaal veel.
Alleen al die projectnamen.
Speer : Strategic process and enabled reengineering
Zo had je ook
vtsPN : Voorziening Tot Samenwerking Politie Nederland
Als ICT ZZP-er zie je al snel de kans op succesvol slagen ervan, maar kun je het beter sportief opnemen. Meedoen is belangrijker dan winnen.

@Nico Dan heb ik dat niet goed begrepen en ik vond het ook al vreemd want ik kon het ook niet helemaal rijmen met je opmerking over bommen en bommetjes hierboven. De focus op de techniek (SAP) en dat het onderdeel van het proces van de organisatieverandering moet zijn. Dat laatste helemaal niet begrepen ik had mezelf ingeprent dat Samson een bestaand systeem was... Overigens besluiten voor nieuwbouw is ook al een beslissing met een IT focus. Want dat ben ik met je eens, IT is een middel en geen doel. Vanuit mijn ervaring, in de techniek en wat ik daarin gezien heb, weet ik dat nieuwbouw risicovol en lastig is. Zeker in een complexe organisatie gecombineerd met de neiging heel erg veel maar dan ook echt heel erg veel mensen in te zetten met ook nog meer dan 1 leverancier dan heb je een garantie op ellende. Al kunnen hier ook mensen belang bij hebben, ellende. Want dat is toch altijd weer het mooie aan dit vak, hoe groter de puinhopen zijn die er van gemaakt wordt hoe meer er aan te verdienen valt.

@mauwerd Ja, meedoen is belangrijker winnen en ja het is ook goed voor de werkverschaffing en met werken op arbeidstherapeutisch basis is ook niets mis. Dit klinkt als een hele duurbetaalde sociale werkplaats. Ik kom toch terug op die hele belangrijke vraag die hier al veel malen gesteld is: waarom automiseren wij? Daar zit wat in, deze vraag van Numo.

SPEER kost 900 miljoen? Dan heeft u het rapport van de Rekenkamer niet goed gelezen. Interne kosten zijn namelijk niet meegenomen in de rapportages. SPEER kost dus een veelvoud van de gerapporteerde 900 miljoen.
Zie versie 2 van mijn analyse: http://www.viergever.info/nl/MinDefSpeer.aspx

Prive automatiseren we
- om dingen sneller, efficienter, betrouwbaarder, controleerbaarder enzo te laten verlopen
- of omdat het algoritme op zich al zo mooi is
- omdat het steeds weer zelfde algoritme zonder automatisering doen, erg saai is
- omdat het dus saaie arbeid bespaart
Professioneel automatiseren we voor brood op plank en bezigheidstherapie.

Jong geleerd oud gedaan:
Deze vuist op deze vuist, deze vuist op deze vuist.
Deze trend op deze trend en zo klim ik naar boven.
Luister even wat de business vraagt, luister wat die vraagt vandaag.
Zeg maar ja of zeg maar nee, doe maar mee.

In het licht bezien van de strijd tussen de publieke en private sector is dit project toch wel een eclatant succes voor de bedrijven Cap, IBM/Ordina, Atos en Logica. Denk eens in hoeveel nieuwe keukens, IKEA items en voertuigen zijn verkocht van die 900 miljoen. Het positieve secundaire effect van al die mislukte overheidsprojecten is immers ook niet te verwaarlozen !

De discussie richt zich steeds meer op de "hoe" en "waarmee" vraag. Feitelijk moeten we onderzoeken "wat" Defensie beoogt, met het programma SPEER. De invloed en de reikwijdte van de dis-benefits zijn onderschat, maar ook het ontbreken aan leiderschap ( niemand is er van !) heeft binnen Defensie geen goed gedaan. Prince 2, MSP en IPMA konden als Programma/Project management methode dit proces niet meer keren. Ik vind persoonlijk het advies van de algemene rekenkamer een juiste, zo snel mogelijk de werkende delen implementeren en accepteren. Daarnaast communiceren, het houden van workshops en vooral werken aan draagvlak.

Het meest pregnante aan dit soort artikelen is dat het telkens weer zo eenvoudig aanwijsbaar is waar en waarom het fout gaat. Het zijn eigenlijk klassiekers waar men telkens weer aan voorbij gaat.

J.A. Hennis-Plasschaert Geen kennis/affiniteit met IT
14-10-2010/05-11-2012 drs. J.S.J. Hillen Geen kennis/affiniteit met IT
22-02-2007/14-10-2010 E. van Middelkoop Geen kennis/affiniteit met IT
27-05-2003/22-02-2007 H.G.J. Kamp Geen kennis/affiniteit met IT
12-12-2002/27-05-2003 H.G.J. Kamp (interim) Geen kennis/affiniteit met IT
22-07-2002/12-12-2002 mr. A.H. Korthals Geen kennis/affiniteit met IT
03-08-1998/22-07-2002 mr. F.H.G. de GraveGeen kennis/affiniteit met IT

Zij zullen stuk voor stu bezweren wat voor geweldige bestuurders zij wel toch niet zijn.... op kosten van de belastingbetaler. Dicht bij de materie te hebben gezeten enkele malen kwam je de klassiekers gewoon weer tegen.

Geen kennis van Lineaire Wetmatigheden
Wanneer je je begeeft op het terrein van lineair project management, en je hebt er topambtenaren bij die van alles wensen en willen, ook op momenten dat dit volkomen contra is op tijd en wijze, dan krijg je dit soort trajecten.

Verlies door inertie
Een aanzienlijk deel van de verliezen zit hem eveneens zit hem in de ambtelijke inertie. Men gaat op elkaar wachten op cruciale momenten of wacht even met het nemen van noodzakelijke beslissingen waardoor er steeds vaker vertraging plaats neemt.

Project verloop
Een drama is ook het verloop van IT professionals op de projecten tijdens. Daardoor word kennis onvoldoende geborgd waardoor er vaak dezelfde stappen weer opnieuw moeten worden gedaan.

Falende commercie
Aansluitend op vorige is het dan ook regelmatig zo dat de nieuw aangetredene vind dat de voorganger daar en daar het niet goed heeft gedaan dus bepaalde stappen over moeten worden gedaan.

Het is in ieder geval stuitend om te moeten zien dat een traject uiteindelijk dertien jaar aan het duren is en dat het meten van resultaten klaarblijkelijk te ingewikkeld geworden is.

Tragisch.

Grappig hoe altijd de sales overal de schuld krijgt. In elk respecterend ict-bedrijf tekent de delivery altijd mee voordat een offerte de deur uitgaat. Sales bepaalt idd de doelprijs maar daar ligt altijd een technische calculatie onder, afkomstig van de technisch specialisten. Oftewel de marge is de speelruimte, niet de benodigde tijd.

Met veel verbazing lees ik de vele (onnozele) reacties van mensen (bv nr1) die denken dat je dit soort grote veranderingstrajecten als een soort hobby kan aanpakken. Alsof een stratenmaker wel even een nieuwe rondweg om Amsterdam ontwerpt, alle stadsdelen op 1 lijn weet te brengen en te houden, de bezwaarschriften weet af te handelen en deze weg ook nog eens op tijd in zijn eentje weet op te leveren. Kortom, schoenmaker blijf bij je leest!

Overigens zeg ik niet dat het niet beter kan. In elk traject worden fouten gemaakt en de kunst is om ervan te leren. Waar ik mij wel bij aansluit is dat sommige projecten zo groot zijn dat het bijna onmogelijk is om deze binnen tijd en geld succesvol af te sluiten. Dit zie je in de ICT maar ook in de bouw.

Precies, Accountmanager.
Probeer niet als stratenmaker een rondweg te ontwerpen. En probeer ook niet als IT-er een organisatie te veranderen. De essentie waarom SPEER zo is gelopen.

@ Accountmanager
Sprekende uit ervaring is het niet altijd zomaar de accountmanager maar meerderen in de organisatie, alleen even IT wise sprekend dan, die de plank zo eenvoudig mis kunnen slaan waar het verkoop betreft. Men kan dan te makkelijk bepaalde onhaalbare concessies doen met alle gevolgen van dien.

We hebben het hier overigens ook over de klassieker niet kundig genoeg zijn de vertaalslag IT-NON IT te kunnen maken of het verkeerd managen van verwachtingen.

Wanneer processen en procedures niet conform de materie, waarop je IT neerzet, zijn, dan heb je pas werkelijk iets waar je tegen aan kijkt dat lijkt op..... Speer?

Grappig dat 80% van degenen die in IT werken niet eens schijnen te begrijpen met welke wetmatigheden je te maken hebt laat staan dat zij zich daar aan kunnen conformeren.

Niet persoonlijk bedoeld maar wel als signaal.

Grappig dat SAP projecten bij de overheid, steeds duurder uitvallen dan vooraf gepland.
Weten ze bij de overheid niet wat ze willen?
Of is de aanbestedingsprocedure een procedure die aan alle kanten rammelt?

@Mauwerd Prive automatiseren is natuurlijk je ook bezighouden met de computer omdat een leuk ding is, de systemen en talen kunnen mooi zijn kortom een bron van vermaak. En je hebt gelijk over het automatiseren al werk, het is ook brood op de plank. Het is bezigheidstherapie, je werkt hopelijk met leuke mensen en als het even meezit doe je ook nog leuke dingen met de computer en raak je niet verstrikt in de IT apenrots. Helaas is dat niet altijd zo, ik heb in het verleden ook ervaringen gehad waar ik echt de lol in de computer kwijtgeraakt was en weer moest ervaren dat het niet aan het ding ligt.

@NicoViergever Interne kosten worden toch zelden meegenomen bij het noemen van de kosten van een project?

@Accountmanager: Natuurlijk krijgt de sales de schuld. Hoe verklaar je anders dat op freelance.nl verschillende Speer rollen worden gezocht. Het tarief voor een senior Programma Manager is 70-75 Euro/uur. Dat zijn IBM/Ordina die niemand hebben! En dat terwijl ze al bijna tien jaar bij Speer rondlopen. Dus sales heeft iets verkocht en kan de gevraagde service niet leveren (en wil er wel lekker aan verdienen)

@iedereen.
Aardig wat reacties op mijn provocerende opmerkingen.
Natuurlijk is 50.000 euro geen reëel bedrag en kan ik dit niet in mijn eentje. Of er meer dan 1 server nodig is weet ik niet. Een uitgebreid ziekenhuis systeem draaide ook op 1 linuxserver. Veel heeft te maken met de technische keuzes.
Maar om 900 miljoen euro op te maken ben je toch wel met heel veel man geld aan het verstoken.
Om te beginnen lijkt mij een niet al te groot team werkbaarder en moeten de doelen te realiseren zijn binnen 1 jaar. Dit door middel van agile sprints. Na 1 jaar zet je dan weer nieuwe doelen uit.
14 jaar geleden hadden we nog tanks en al helemaal geen drones. was er geen cyber afdeling dus te ver vooruit kijken ook met de huidige politiek heeft geen zin.

En als basis een opensource ERP pakket lijkt me een goede keuze als er toch heel veel aangepast moet worden. Want blijkbaar heeft SAP voor defensie geen standaardoplossingen anders was het allang klaar geweest..

Waarschijnlijk wordt tegelijkertijd met de implementatie van het nieuwe systeem een machtsverschuiving beoogd. 1 ivp 3 erp's (marine, landmacht en luchtmacht).
Altijd een foute combinatie techniek inzetten om een reorganisatie erdoor te drukken ...

@Corne Smiesing
SAP heeft wel degelijk standaardoplossingen voor Defensie : http://www.sap.com/solution/industry/defense-security.html
De problemen zitten dan ook vermoedelijk in het maatwerk en het totale functionele eisenpakket van Defensie, alsmede "menselijke" factoren.

@CorneSmiesing Ik ben het eens met je opmerking om met een niet al te groot (wmb klein) team te werken, je ziet het zelden. Een ICT project heeft vaker weg van een Poolse landdag.

De bedrijfsvoering bij Defensie is al meer dan tien jaar niet op orde. Elk jaar gaf de Rekenkamer het ministerie een onvoldoende. De invoering van een defensiebreed ICT-systeem moest daarin verandering brengen.
Het zou een geweldig project worden, SPEER (Strategic Process and Enabled Reengineering), dat ook nog eens meer dan duizend werkplekken zou besparen.
Megaproject
De Nederlandse defensie-organisatie was de eerste ter wereld die defensiebreed een ERP-systeem (bedrijfssoftware) zou gaan gebruiken voor alle activiteiten; de medicijnen voor geneeskundige troepen, het onderhoud aan vliegtuigen, de missies in Afghanistan, het wereldwijd bevoorraden van marineschepen en de personele planning van de missies. Geen enkele andere krijgsmacht had dit nog vertoond.
Alle artikelen, al het materieel en alle manschappen moesten in dat ene enkele systeem passen. Het zou bovendien een van de grootste SAP-implementaties (bedrijfssoftware) ooit worden. Toch rinkelden de alarmbellen op de Haagse staven niet.
De externen vallen binnen
Een leger aan externen werd ingehuurd om de klus te klaren. De betrokken militairen, die voor twee of drie jaar aan het project werden toegevoegd, vonden het vooral ‘verplicht corvee’. Het leverde wel altijd een extra ‘streep’ op.
Experts hesen de stormbal bij de opeenvolgende staatsecretarissen en ministers. Die laveerden echter handig om de vragen van de vaste Kamercommissie heen.
Sterren plakken
Als het project niet de voortgang toonde die nodig was, dan werd de zittende éénsterrengeneraal vervangen door een tweesterrengeneraal en daarna zelfs door een driesterrengeneraal; SPEER moet! Die laatste generaal meldde trots in de vakbladen dat ‘SPEER weer spits was’ om vervolgens een mooie baan te accepteren bij de externe hoofdaannemer van SPEER.
Het mocht allemaal niet baten. Het SPEER project kwam niet vooruit, terwijl de kosten uit de bocht vlogen. De initiële begroting van iets meer dan 100 miljoen euro, werd al snel 185 miljoen euro, zelfs 400 miljoen euro en nu schat de rekenkamer het eindbedrag op 900 miljoen euro.
Terwijl het project nog lang niet klaar was, werd al wel de projectorganisatie in 2013 ontmanteld. De overbelaste ‘staande organisatie’ moest het overnemen. De Rekenkamer maakt zich daarom terecht zorgen over de voortgang nu de werkvloer de onoplosbare problemen moet oplossen.
Noodzaak
Een betrouwbaar en stabiel ICT-systeem is van levensbelang voor de krijgsmacht. Het delen van informatie is noodzakelijk voor samenwerking met de industrie en coalitiepartners om effectief, efficiënt en veilig onze vredesmissies te ondersteunen. SPEER moet inderdaad.
Defensie moet al jaren bezuinigen. Maar ik vraag me af of ze wel weten waar het geld vandaag aan opgaat. Goed zicht op de bijdrage die ICT kan leveren aan een beter bestuur en betaalbaarheid van de krijgsmacht ontbreekt, stelde Defensie zelf al eerder en nu ook de Rekenkamer.
Niet klaar
De Rekenkamer concludeert dat Defensie nog veel werk moet verzetten om de voordelen van het nieuwe ICT-systeem te kunnen benutten. De Rekenkamer stelt ook dat het nu wel lang genoeg heeft geduurd, dat er nog veel functionaliteit niet is opgeleverd en dat de randvoorwaarden voor doorontwikkeling er niet zijn.
De functionaliteit voor het slimmer uitvoeren, plannen en besturen van processen ontbreekt. Wat moet dat worden als straks een complex vliegtuig als de JSF wordt ingevoerd?
Innovatie?
Defensie zelf concludeert dat met een nieuw systeem innovatie niet vanzelf komt. Anders dan aanvankelijk werd verondersteld, dwingt het gekozen ERP-pakket verbetering van de werkprocessen niet af. Innovatie van werkprocessen vindt alleen plaats als daar expliciet op wordt gestuurd.
De leiding bij Defensie mag zich dus niet verschuilen achter de ‘staande organisatie’ die nu zelf maar voor de ICT moet zorgen. Het ERP-project is simpelweg nog niet klaar. Dan kun je nog zoveel sterren plakken, maar dan gaat het uiteindelijk toch niet werken.
Pijnlijke lessen
Er zijn veel pijnlijke lessen te leren bij Defensie. Gedwongen innoveren met ICT? Vergeet het maar. Defensie probeerde in 2013 met een zelfevaluatie uit te leggen waarom het zo lang heeft moeten duren, het zoveel heeft moeten kosten en waarom het nog niet klaar is.
Het rapport leest als een jongensboek en is voor iedereen die betrokken is bij grote ICT-implementatie verplichte kost.

Een duidelijk en eerlijk verhaal van @Walter, die feitelijk de 7W/1H vragen beantwoord. Een project bij Defensie is altijd complex, vanwege de macht van de vlag-officieren, waarbij rang en positie belangrijker zijn, dan de missie. Ik heb dit eerder gememoreerd met de opmerking gebrek aan "leiderschap". Ik ben het met @Walter eens dat elke doelmatige bedrijfsvoering een ERP/CRM ondersteuning nodig heeft. De inrichting strategieën en de architectuur vraagstukken waren in het begin van het project al niet op orde. Geen de-ployed server aan boord of bij de compound. De beperkte bandbreedte van de SATCOM verdraagt geen terminal sessie. Toch heeft SAP bijgedragen aan een betere financiële (budget) bewaking, maar voor de werkprocessen heb je toch echt een opzet als BAAN nodig. Tot groot ongenoegen van @Nico (terecht), stelde ik dat de zakelijke rechtvaardiging , de BC , was geslaagd, omdat de 1030 medewerkers al weg zijn. Dit komt , mijn inzien , dat Defensie zo snel mogelijk afscheid wil nemen van het oudere/ duurdere personeel. Bij de laatste reorganisatie, n.a.v. de beleidsbrief Hillen van april 2011 is de laatste ronden ingegaan voor de ondersteunende onderdelen DMO en CDC. Het Joint Informatie Voorziening Commando (JIVC) is vooral met het Vraag en Aanbod Management (VAM) een tanden loze papieren tijger geworden. Begin 2010 had DMO, dankzij de implementatie van het 1ste SAP module geen grip meer op het materieellogistiek proces. De Operationele Commando's hebben bij straf de systeem logistieke onderdelen (4100 vte) weer teruggenomen van DMO. De BC van Hillen wederom geslaagd, 12.000 functies (met taken ?) vermindert en ruim 6.000 medewerkers (vrijwillig/verplicht) minder in de organisatie. Dat taken en middelen niet meer in balans zijn, dat begrijpt iedereen, maar alleen de werkvloer zegt dit hardop. Het is dan ook een goed geoliede geautomatiseerde chaos in het IV landschap van Defensie. Voordeel is je kan de Informatie Voorziening nog altijd outsourcen, was dit niet het oorspronkelijke plan ?

@Walther, sterke analyse. Bill Gates zei het al in de 80'er jaren: "Een tien keer zo groot project laat zich honderd keer moeilijker managen". Toch laten overheden zich iedere keer weer verleiden tot zo groot mogelijke - alles omvattende - projecten. De kolchoze/sovchoze mentaliteit (à la hoe groter de schaal, hoe efficiënter/effectiever het project) sla je er bij de overheid nooit meer uit. Goede projecten laten zich microscopisch uitrollen en lenen zich voor fractale opschaling. Of dat ook daadwerkelijk plaatsvindt, hangt af van de organisatie (en verder van heel veel toevalsfactoren). Maar als het niet gebeurt, ben je dan tenminste geen 900 miljoen kwijt.

Maar Walther heeft zelf bij Defensie gewerkt. In die jaren heeft ie het project van dichtbij meegemaakt. Dit lijkt wel een beetje op achteraf gepraat. Waarom komt deze analyse nu en niet in 2006?

@Frits
Er was eens een relletje met waarschuwende ambtenaren en niet luisterende bestuurders, de rol in het rollenspel is dus belangrijk om een wending te geven aan het plot.

Oeps !, @Ewout je slaat de spijker op z'n kop. Bij beide automatiseringsbedrijven van Defensie, hebben zich mens onterende gevallen voorgedaan. Er zitten mensen ziek thuis en veel mensen zijn beschadigd. En de top ? o.a. de Secretaris Generaal en de Minister Hillen , hadden maar een opdracht om hun eigen hachje te redden. Ik heb ontzettend veel respect voor @Walther, ook als je dit publiekelijk in 2014 durft te melden.

Ik vraag me soms wel eens af of we ook niet allemaal een te mechanisch denkbeeld hebben bij het bouwen van software. Vergeef de lichte zweverigheid hier, maar we hebben nog een typisch moderne (lees jaren 50) visie op het ontwikkelen van software. Alsof we een auto aan het bouwen zijn; we hebben het over architectuur alsof het een star iets is en oplossingen moeten compleet en geheel zijn. Alles moet een afgesloten sarcofaag zijn, zoals communisme ooit tegenover kapitalisme stond (ook typisch - met alle mechanische denkbeelden van toen).

In die zin vraag ik me wel eens af of we niet flexibeler en (ja, de architectuur wordt daardoor ook complexer) meer module achtig zouden moeten bouwen en wat meer moeten zoeken in de uiteindelijke ontsluiting van die verschillende aspecten. Ontsluiting veel meer 'houwtje touwtje' ogend, maar uiteindelijk sterker omdat modules ook makkelijker eruit gesloopt kunnen worden; minder plakkerige legacy. Misschien moeten we accepteren dat IT te snel gaat om het nog als een gebouw te zien dat stevig moet staan, maar veel meer vraagt om tenten die snel op en afgebroken kunnen worden. Er schijnt een volk te zijn geweest die daar toch de halve wereld mee heeft veroverd.

Met mijn persoonlijke ervaring met defensie en - achtige structuren zit de pijn hem niet bij de IT professional. Gelukkig niet. Waar dan wel? eigenlijk is dat tweeërlei. Bij de toeleverancier die het telkens maar niet lukt IT goed en helder over het voetlicht te tillen en daarbij nog veel concreter te zijn dan telkens maar te luisteren en te voegen naar de wensen van defensie.

Je krijgt daar hele rare kruisbestuivingen van, het betaalt lekker maar je komt vervolgens nergens. De andere kant zit bij defensie zelf. Die hebben met regelmaat geen eenduidige visie op standaard waardoor je multidisciplinair IT-wise, heel hard achter feiten aan aan het lopen ben.

We hebben het dan nog maar even niet over de 'overgangsfase' waar defensie zich mee bezig houd, namelijk dat men ook daar heel druk bezig is oude senior staff er uit te werken en die te vervangen door jonger bloed.

Het is bijkomende probleem hier is dat het waarschijnlijk een generatie zal gaan duren voor je IT uiteindelijk weer echt slagvaardig is. Men houd er in ieder geval geen generalisten aan over die het in zich hebben proces en procedure overstijgend te kunnen kijken en werken. Ik denk dat daar het grootste gevaar van het verhaal zit.

Tja, ik word droevig van zoveel verspilling van belastinggeld. En dan te bedenken dat dit bij lange na niet het enige 'mislukte' traject is. De burger gaat voor miljarden het schip in. Geld dat we voor mooie orkesten, sport, ondernemers, et cetera hadden kunnen gebruiken. De oorzaken zijn de bekende open deuren waarbij ik er 2 aan wil stippen:
1) Aanbestedingstraject werkt averechts. Enkel de grote IT partijen kunnen er aan mee doen en dus nul concurrentie en innovatie. Deze partijen worden slapen rijk en er is geen enkele prikkel voor ze om haast te maken. Mislukt het, dan komt er weer het volgende project van de overheid, uiteraard via aanbesteding en uiteraard komt dit weer bij de grote IT partijen terecht. En zo is de circel rond.
2) Veel te groot en omvangrijk project: werk lean & mean, in stapjes en met minimal viable products. Kan je met hele mooie innovatieve partijen werken.

Kernvraag is: Hoe gaan we wel succesvolle projecten bij de overheid bereiken? En hoe gaan we dit bereiken, wie gaat het voortouw nemen? Zelf stel ik voor een open brief aan de 2e kamer, getekend door enkele innovatieve ondernemers die helemaal klaar zijn met de verspilling. En we eisen een IT&Innovatie minister. IT is nu al zeer belangrijk en wordt nog veel belangrijker de komende jaren. En aan de brief ligt een stukje grondig research ten grondslag icm ideeen en voorstellen hoe wel tot succesvolle projecten te komen.

@Alexander, samenwerking moet van onderaf komen. Je moet dus afdelingshoofden e.d. een budget geven waarmee ze eventueel kunnen opteren voor gezamenlijke ontwikkeling maar vooral hun eigen gang moeten gaan als ze dat niet zien zitten en iets veel beters weten. Door de laagste regionen budgetverantwoordelijk te maken weten de gebruikers precies wie ze moeten aanspreken en zal de 'commitment' veel groter zijn. Verder explodeert daardoor het lerend vermogen van zo'n organisatie als geheel. Beslissingen worden ook veel gefundeerder genomen of op plekken geblokkeerd omdat allerlei detailkennis in het veld veel beter voor handen zijn en feedback-traject zo kort mogelijk blijven. Waar iets niet goed dreigt te gaan, gooit vanzelf wel iemand de kont tegen de krib omdat hij/zij geen zin heeft z'n geld in de sloot te gooien zodat de omvang van mislukkingen in allerlei stadia nog geminimaliseerd wordt.

We gaan toch ook boeren niet meer vertellen wat ze moeten verbouwen (om geen tekort van het een en overschot van het ander te krijgen of ze verbieden zelf nog combines e.d. te kopen of huren bij het loonbedrijf, maar de staat één geweldige machine laten ontwikkelen voor alle boeren? Als er dan fouten worden gemaakt gaat het ook goed mis en heb je met een beetje pech een hongersnood. Fractale structuren van zo klein mogelijke autonome eenheden werkt het best. Schaalvergroting moet je aanmoedigen en krijg je vanzelf wel op die onderdelen waarvoor het geen bezwaar is en waar het daadwerkelijk schaalvoordeel oplevert. Leve de WMO.

900 miljoen. Dat is een heleboel geld. Bij zulke bedragen vind ik het onmogelijk om nog een koppeling te maken met de werkelijkheid. Overheid en ICT blijkt helaas nog maar al te vaak een faal. Wellicht een beetje off-topic, maar misschien dat de nieuwe regels voor ambtenaren (geen ontslagbescherming) hier wat aan gaan veranderen. Bij dergelijke projecten zijn natuurlijk tientallen/honderden fouten gemaakt, maar de verantwoordelijken hoeven nooit op te stappen/kunnen niet ontslagen worden.

@NumoQuest, het is nog een stuk erger dan je beschrijft.

De bewindslieden bij Defensie hebben ook geen affiniteit met defensie. Waren de bewindslieden decennia geleden vaak oud officieren, nu hebben vrijwel alle Defensie-bewindslieden nog nooit voor defensie gewerkt, ook niet als dienstplichtige. En Middelkoop heeft zelfs publiekelijk aangegeven een hekel aan defensie te hebben. Niemand van de andere kandidaat-ministers wilde toen bij Defensie werken.
Ook de controlerende kamerleden die defensie- of ict-woordvoerder zijn, hebben doorgaans geen enkele defensie- of ict-expertise. Die zit bij de betere de fractieassistenten, maar niet elke fractie heeft dat soort mensen.

Overigens bijna elk project of programma van defensie heeft een ict-element. Sowieso hebben alle grote wapensystemen belangrijke ict-componenten en zijn ze gekoppeld aan de Informatievoorziening, Command and Control systemen. Google glas, wat nu opzien baart bij consumenten, heeft al een paar decennia defensievoorgangers.

Ik was ook betrokken bij de voorfase van dit speerproject. FYI, ik ben al 17 jaar SAP expert/professional project manager. Die budgetten die nu genoemd worden, zijn krankzinnig. En ook al was het waar, dan moet je nooit zulke grote projecten doen, omdat het eindigt als een 2e Betuwe Route project. Gewoon niet te managen!!!
Inmiddels heb ik OpenERP geïmplementeerd bij de Royal Thai Air Force!! Natuurlijk aardig wat aanpassingen om een customer fit te maken, maar het kan ook eenvoudig met dit flexibele ERP-pakket. Kosten liggen in de buurt van 50 KEuro...
Geintereseerden kunnen mij emailen voor details op jakhoeblal@gmail.com

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

×
×