Managed hosting door True

Klassieke fouten nekten Logica-systeem Tax-i

 

De bouw van het belastingsysteem Tax-i voor de waterschappen liep al verkeerd vanaf dag één van de voorlopige gunning aan Logica. Te ambitieus, te complex en niet-realistisch. De evaluatiecommissie Taxi, dat het debacle door Twynstra Gudde liet onderzoeken, spreekt van een collectief falen van ict- en regie-organisatie Het Waterschapshuis, de waterschappen en automatiseerder Logica. Volgens het adviesbureau is het project mislukt door een combinatie van politieke, organisatorische en technische klassieke faalfactoren. Schadepost: 17,2 miljoen euro.

De evaluatiecommissie verwijst in de begeleidende brief aan het bestuur van de Unie van Waterschappen naar het rapport 'Lessen uit ict-projecten bij de overheid' van de Algemene Rekenkamer. Uit dit rapport blijkt dat de belangrijkste oorzaak voor het mislukken van ict-projecten bij de overheid ligt in een combinatie van politieke, organisatorische en technische factoren. Daardoor worden dergelijke projecten vaak te ambitieus en te complex en mislukken ze. Uit het onderzoek van Twynstra Gudde komt naar voren dat dergelijke 'klassieke' faalfactoren zich ook bij het project Taxi-i hebben voorgedaan.

Stekker eruit

In 2007 besloot het Waterschapshuis, de gezamenlijke ict-organisatie van de waterschappen, met Tax-i te starten. Logica werd als hoofdaannemer aangetrokken met Ordina en Oracle als partners. Het systeem, bestaande uit een centrale inning- en heffingtoepassing en een overheidsdatabase, kwam echter niet van de grond. In maart 2012 werd de stekker er definitief uitgetrokken. In het kader van de afbouw van Tax-i werden drie besluiten genomen: een schikking met Logica zodat een gang naar de rechter kon worden voorkomen, een verrekening van de intern gemaakte kosten en het opstellen van een evaluatie. Dit laatste punt is door Twynstra Gudde uitgevoerd.

Schadepost

Aan Tax-i zouden 24 van de 26 waterschappen meedoen. Het was begroot op 25 miljoen euro. Uiteindelijk leverde het stopzetten ervan een schadepost op van 17,2 miljoen euro: de werkzaamheden van Logica (6,6 miljoen), de projectkosten van het Waterschapshuis (4,4 miljoen) en de aangeschafte Oracle-licenties (6,2 miljoen voor een periode van vijf jaar). Deze kosten komen voor rekening van Het Waterschapshuis.

De evaluatie wordt vandaag besproken tijdens een algemene ledenvergadering van De Unie van Waterschappen.

Lees ook achtergrondverhaal Evaluatie Taxi-i: Collectief falen bij debacle

 

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

?


Lees meer over



Lees ook


 

Reacties

Gebruik dan ook postgresql of mysql scheelt alweer 6,2 miljoen....
En waarom eerst Oracle-licenties kopen als je nog geen programma hebt?
Volgens mij heb je die licenties pas nodig bij het uitrollen.
Iemand heeft dan toch zitten slapen lijkt me.

Ook dit is weer een typisch geval van ICT-verkopers die een lijstje met wensen onder hun neus krijgen en altijd "ja hoor tuurlijk kan dat "als antwoord hebben en vooral geen techneut mee nemen tijdens dat soort gesprekken omdat ze moeten scoren van hun baas kortom de problemen zijn er al voordat er uberhaupt 1 regel code is ingeklopt. Daarnaast heeft Corne een punt: pak dan ieder geval licenties voor een jaar met verlengopties - want juist in ict land geldt niet de huid verkopen voor je de beer hebt geschoten! - waarschijnlijk zullen de verkopers en managers er hard om lachen die hadden de buit al binnen in 2007 Jammer, op deze manier slaagt er geen enkel serieus project wat wel blijkt uit het aantal grote projecten die floppen!

Tja, 'Achteraf kan je een koe in de kont kijken' luidt het gezegde en dat gaat ook hier op. Ik ben regelmatig betrokken bij softwareprojecten (op immens veel kleinere schaal) waarbinnen ook deze fouten gemaakt dreigen te worden. Teveel aspecten tegelijk, geen overzicht op de uiteindelijke bedienbaarheid, wildgroei aan 'tussenoplossingen' die allemaal een eigen erfenis meebrengen en immer groeiende wensenlijsten van de eindgebruikers.
Daar komt dan bij dat de mensen 'in het veld' zich vaak gepasseerd voelen dat ze niet volledig betrokken zijn bij de ontwikkeling waardoor de implementatie van het pakket al op -1 begint.
Ben het wel met Corne eens, dat er iemand niet echt handig is ingesprongen op het Oracle-verhaal. Een werkende beta kan je inderdaad ook gewoon op een ander platform of een enkele licentie uitrollen....

Ik ben het er helemaal me eens! Ik denk dat grote bedrijven graag kiezen voor systemen zoals Oracle en microsoft. Het maken van zulken systemen kan een stuk goedkopen en beter denk ik, wanneer je geen gebruik maakt van complexe en dure oplossingen van bijv. Oracle. Echter is dit nog steeds een beetje taboe.

Gezien de kostenverdeling - de kosten komen allemaal op het bordje van Het Waterschapshuis - lijkt het alsof Logica geen enkele blaam treft. Omdat Logica na een aantal naamswijzigingen en overnames volgens mij al meer dan veertig jaar bestaat moet zij over een schat aan ervaring en expertise beschikken. Hoe is het dan mogelijk dat een 'klassieke fout' alleen op het bordje van de opdrachtgever komt?

Simpel antwoord op een complexe vraag ... uurtje factuurtje ipv resultaatverplichting ... eitje

Dat hele aanbestedingscircus leidt bepaald niet tot kwaliteit, er wordt alleen maar op geld gelet en gestuurd...aan beide kanten. Geldt niet alleen voor ICT, maar ook Openbaar Vervoer, Bouw etc.

Om te beginnen hebben de door Bart Nelissen genoemd verkopers volkomen gelijk. Alles kan. Ze moeten er alleen bij vermelden dat de Logica's, en Cap Gemini's onder ons alleen jonge goedkope en onervaren mensen in dienst hebben, die als ze te duur worden eruit worden gegooid of als ze goed zijn door een eindklant worden overgenomen. De expertise en ervaring die ze willen verkopen hebben ze dus niet. Verder moet de klant een mandaat geven aan de regisseurs. En ja, vaak weet de werkvloer het beter dan het middelmanagement. En nee, een platvorm is maar een platvorm en heeft niets te maken met de oplossing. Het ene platvorm is alleen stabieler, beter en efficienter te onderhouden dan het andere maar dat is systeembeheer (IBM vs. Microsoft).
Geef mij 2 miljoen, 2 jaar de tijd en eerder genoemde mandaat en de klus is geklaard. Keep it simple, lukt alleen met een normaal denkende regisseur, in het bezit van tact en empathisch vermogen, projectmanagement ervaring, zonder schroom en weet hoe je een DB opbouwt. Ik heb dit een aantal keer bewezen (zonder schroom). Tevens is de pest bij dit soort projecten dat de eigenaar van het geld niet aanspreekbaar en/of te lokaliseren is. Het is in dit geval belastinggeld, en in andere gevallen grootaandeelhouders die zich buiten de onderneming bevinden, of aandeelhouders/directie die weggehouden worden bij de regisseurs, en blind varen op de info die ze krijgen en niet gaan halen.
Over het algemeen gaat het altijd goed als de eigenaar van een onderneming zelf zich bemoeid en oplet waar het geld heengaat, het is tenslotte echt hun geld.
Uitzonderingen daargelaten, neem een voormalig bestuurder als Wim Dik bij KPN, die paste goed op de centjes van KPN.
Uurtje faktuurtje gaat alleen op bij de analyse en ontwerp daarna afrekenen per behaalde mijlpaal. Anders weet je zeker als overheid dat je uurtje faktuurtje de mijlpalen overschreiden zal.

Tip voor de opdrachtgevers. Zorg dat de projectmanager/regisseur een rol heeft als liaison tussen de opdrachtgever en de uitvoerende partij. De manager mag nooit door de uitvoerder worden geleverd en liever niet uit de organisatie komen (politieke druk van beide partijen uitsluiten). Hij/zij moet sterk en slim genoeg zijn zich niet door de uitvoerder te laten gebruiken of laten truken, en zich bewust zijn geen vrienden te moeten maken maar een project af te ronden. Een goede manager vertrekt met nieuwe goede kontakten. Zet vervolgens project organisatie voor de duur van het project naast de organisatie met een mandaat, en laat wekelijks rapporteren over de voortgang. Deze werkwijze scheelt een hoop geld en slachtoffers.

Veel is al gezegd. En verder: klinkt misschien als een cliché, maar agile werken (bijvoorbeeld met scrum) kan veel van de genoemde problemen voorkomen. In meerdere sprints steeds werkende software opleveren. Simpel, down to earth, en het werkt. Beter voorspelbare resultaten, lagere kosten. Wat nou uurtje factuurtje, uiteindelijk wel, maar wel met een commitment per sprint.
Het zal eens tijd worden dat ook het overheidslandschap zich dat gaat realiseren, in plaats van toe te staan dat belastinggeld wordt verkwanseld.

@Oskar Hendriks,

Ik begrijp je sentiment, echter je probeert je nu ook te verkopen als een "ik kan alles tegen de laagste kosten"-figuur die je eerder beschrijft als zojuist door Bart Nelissen genoemd. Je kunt alles, en dat allemaal op basis van een half verhaal. Kennelijk heb je ook inzicht in de samenstelling en de ervaring van zowel Logica (in de diverse verschijningsvormen) en de Cap Gemini's.
Om vervolgens af te sluiten met een advies die in de afgelopen jaren juist bewezen heeft niet te werken: waterval. En als klap op de vuurpijl ook nog eens het ontwikkelteam (uitvoerende partij) ook nog eens geheel afsluit van de partij die de gebruikers vertegenwoordigt (en daarmee dus de enige lijn van praktijkkennis) door er een projectmanager tussen te zetten. Hiermee verhoog je alleen maar de ceremoniele praktijken om vragen te beantwoorden.
Even een schets van wat er gaat ontstaan (een ontwikkelaar heeft een vraag omtrend een stuk op te leveren functionaliteit):
1. Eerst een vergadering plannen met de regisseur om de vragen voor te leggen
2. Dan moet de regisseur een overleg plannen met de opdrachtgever om de vragen direct te beantwoorden
3. De opdrachtgever weet het ook niet en plant een overleg met de chef van de afdeling die de vraag zou moeten weten te beantwoorden
4. De vraag wordt doorgenomen en zo goed als mogelijk beantwoord
5. Het antwoord wordt aan de opdrachtgever gegeven
6. Het antwoord wordt aan de regisseur gegeven
7. Het antwoord wordt aan de ontwikkelaar gegeven....

Ken je het spelletje "chinese whispers" (of op z'n Nederlands telefoontje)? De kans is groot dat in de eerste stap de regisseur de vraag al verkeerd doorgeeft aan de opdrachtgever (de regisseur geeft al dan niet bewust er toch zijn/haar interpretatie aan) en dat gaat zo door.
Denk je echt dat dit beter gaat werken, en goedkoper?

In complexe en technisch innovatieve projecten is het juist de waterval-project benadering en de vele overlegschijven die hebben geleid tot grote overschrijdingen van budgetten en grote onschrijdingen van de benodigde functionaliteit. De praktijk heeft bewezen dat in dit soort grote ICT projecten het juist kostenbesparend werkt als je werkt volgens een Agile methode (zoals Hans Michiels ook aangeeft).

Let wel: Agile is geen Haarlemmer olie, er zijn projectvormen die juist wel met een meer waterval benadering moeten worden gedaan; in de ICT echter zal je veel meer projecten op een Agile manier moeten benaderen.

@Cpt. Hier leg je wel wat bloot, "chinese whispers". Nu komt een groot probleem om de hoek kijken. Ik ken Cap met name in de hoedanigheid van leverancier van maatwerk. Ik heb ervaren als er iets niet helemaal duidelijk is, ik gewoon als ontwerper of ontwikkelaar naar de werkvloer van de klant ga met een vraag en ik direct het enige en juiste antwoord kreeg (getoetst). Dat mag een Capper niet want daar zit een heel circus Cappers omheen en er is contractueel vastgelegd wat er geleverd gaat worden en dat moet dan ook nog weer worden opengebroken. Daarnaast ontbreekt vaak bij de Cap programmeur/ontwerper de specifieke klant-/bedrijfskennis en weet niet eens dat er een probleem zou kunnen zijn. Verder wil het management van de klant grip kunnen houden op het project en wil dus precies weten en kunnen sturen op alle issues die boven komen. Zeker bij grote projecten kom je niet weg met alleen een telefoontje, daarmee haal je de sturende functie van het klantmanagement volledig onderuit. 1 wijziging zou gevolgen kunnen hebben voor een afdeling 5 processen verderop. De klant zelf heeft al moeite dat totaal overzicht te hebben/houden laat staan een aannemer, ongeachte vooropleiding en/of ervaring, wat wel helpt is specifieke branche kennis en ervaring. Het is mij opgevallen dat sales medewerkers van de detacheerders met nog tig klanten, vaak pretenderen (gesteund door hun management), klantkennis te hebben, en weten wat er bij de klant 'allemaal' speelt. Een enkele vak idioot van Cap die 60 uur per week met de klant bezig is (ook in het informele circuit), die weet het meest, maar heeft vaak onvoldoende tijd en vind geen gehoor bij zijn/haar officiele werkgever. En daar wringt alweer een schoen, de opdrachtgever/klant mag soms tegen een belachelijke vergoeding de werknemer overnemen, reden is niet de continuiteit maar het snelle geld van de aannemer, en dan hebben we nog de arbeidsvoorwaarden van de werknemer die vaak niet strookt, neem bijvoorbeeld het eeuwige gedoe over de auto van de zaak. De auto is gereedschap wat detacheringspersoneel nodig heeft en bij een dienstbetrekking bij een eindklant niet meer, maar ziet het gereedschap als verkapt inkomen, tot de bijtelling te sprake komt:-). Al met al veel complexe, specifieke en grijze gebieden, dus.

Vacatures bij Ordina
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

×
×