Wat liep technisch fout bij Phenix?

Er is al veel inkt gevloeid over het Phenix-debacle bij Justitie, maar over de precieze technische problemen bleven buitenstaanders in het duister tasten. Jan Deprest, de voorzitter van Fedict, licht voor het eerst een tipje van de sluier.

Fedict treedt sinds eind 2004 op als technische waakhond voor het Phenix-project, dat de dertien informaticasystemen van Justitie moest omvormen tot een geïntegreerd geheel. Na de rampzalige test bij het politieparket van Turnhout in april 2005 werd een compleet nieuwe planning opgemaakt. Maar ook dit tijdschema zou Unisys uiteindelijk niet halen.

IT Professional: Na de inmiddels beruchte -en misluktetest bij het Turnhoutse politieparket in 2005, kreeg Unisys een nieuwe planning opgelegd. Hoe werd die nu eigenlijk opgevolgd?
Jan Deprest: Niks is opgeleverd: dat is net het grote probleem. Voor alle duidelijkheid: wij verstaan onder een oplevering ook een ‘acceptatie’. Natuurlijk heeft Unisys een aantal zaken opgeleverd, maar die moeten uiteindelijk wel geaccepteerd worden door de gebruikers en door de ICTcommissie.

Daar bestaan toch heel strikte richtlijnen rond?
Jazeker. Ik geloof daarom dat we met ongeveer dezelfde vraagstekens zitten: hoe is het mogelijk dat we in zo’n situatie verzeild zijn geraakt?

Op een bepaald moment hebben we uiteindelijk aan Unisys gevraagd om zich expliciet te concentreren op één enkele applicatie (met name die voor de collectieve schuldenregeling, nvdr.). We wilden namelijk eindelijk eens iets concreets in handen krijgen. Nu moet je weten dat deze applicatie op basis van een 3-tier-architectuur hoorde te werken. Dat stond zo in het lastenboek en ook in de offerte van Unisys zelf. Maar wat bleek? Dat er ontwikkeld werd in een 2-tierarchitectuur die gericht was op een Microsoft-omgeving.

Ik heb niks tegen Microsoft, maar we hadden wel degelijk een Unix-omgeving gevraagd. Wanneer we Unisys hiermee confronteerden, vertelde men ons dat dit maar een kwestie van converteren was. Dat is waar, maar een conversie veroorzaakt altijd ergens een probleem. Wat moesten we dus met die technische analyse aanvangen?

Maar net bij die technische analyse had u toch al kunnen zien dat de juiste architectuur niet werd gebruikt?
Inderdaad en wij zijn daar blijven opmerkingen over maken totdat we Unisys uiteindelijk naar een resultaat hebben geduwd. Ook op de functionele analyse zijn er, vanuit de gebruikers, honderden opmerkingen gekomen. We konden de analyse wel voorwaardelijk goedkeuren, waarbij dan geen rekening werd gehouden met al die vragen vanuit de gebruikersgemeenschap, maar als die vragen dan ook niet worden verwerkt… Tja, dat was niet de afspraak natuurlijk.

Maar we spreken hier wel al over eind 2005?
We hebben de boel sowieso al de eerste keer stilgelegd in april 2005, na de test in Turnhout (die op een fiasco uitdraaide en ook uitgebreid in de pers verscheen, nvdr.).

Fedict is in oktober 2004 binnengehaald bij de heronderhandeling van het contract. Uiteraard vraag je dan onmiddellijk naar de planning, maar wij kregen toen gewoon één enkele slide. Voor een management is zo’n overzichtsslide ideaal, maar voor techneuten niet, natuurlijk. De eerste planning heeft Fedict daarom zelf opgesteld. Ondertussen is de omzetting naar 3-tier wel gebeurd. Met alle problemen van dien, want zoiets is geen copy-paste natuurlijk.

Bovendien veronderstelde Unisys dat er een aantal versies van de system libraries aanwezig waren, wat uiteraard niet het geval was. Eigenlijk voelden we aan dat hun softwarefabriek (waar de programmeurs een strakke structuur en goede omkadering hebben, nvdr.) er niet was. Dat hebben wij nooit mogen verifiëren. Contractueel was Unisys daartoe ook helemaal niet verplicht.

Bij de proefsite van de collectieve schuldenregeling, die er op 13 juli 2006 had moeten zijn, konden we alleen maar vaststellen dat er niks was (lees ook IT Professional nr. 6).

De voorzitter van het Hof van Cassatie, de heer Ivan Verougstraete, spreekt van een indrukwekkende lijst van gebreken. Kunt u dat wat concreter maken?
Dat zijn de vele bug rapporteringen en change requests. Alleen al voor de collectieve schuldenregeling liep dit op tot meer dan achthonderd openstaande punten. Nochtans is dit een relatief bescheiden applicatie met zeventig schermen en pop-ups en vier basistransacties. In ICT-termen hoeft dit niet zo’n complex traject te zijn.

Kunt u de vinger op de wonde leggen?
Waarom loopt een IT-project verkeerd af? Omdat de analyse niet gedetailleerd genoeg is, da’s duidelijk. Je kunt met de gebruikers wel businessprocessen afspreken, maar die processen moeten ook vertaald worden in functionele analyses.

We denken dat daar al een eerste fout is gemaakt. Daarnaast heb je natuurlijk ook de communicatie tussen de programmeurs, de functionele en technische analisten. Ik kan me soms echt niet van de indruk ontdoen -zonder dat ik dat kan bewijzen- dat die communicatie heel moeilijk liep. Het is zoals een auto bouwen: je moet ervoor zorgen dat, op een heel gestructureerde manier en op het juiste moment, alles precies bij de juiste persoon terechtkomt. En zo kom ik altijd terug bij die softwarefabriek.

Fedict had toch net de bewakingsfunctie voor de technische aspecten, de vooruitgang en de planning?
Dat klopt. Dus als wij zeggen dat er iets niet klopt, is het ook zo. Maar het blijft een adviserende functie.

Dus u heeft anderhalf jaar blijven herhalen: ‘Het klopt niet’?
Nu moet u ook niet overdrijven: bij een ICT-traject dat jaren duurt, is het helemaal niet zo abnormaal dat er ups en downs zijn. Als je bij het eerste moeilijke moment zou beginnen panikeren, kan je beter uit de business stappen, want dan ben je er niet voor gemaakt. Dat er problemen opduiken bij een IT-project is dus volstrekt normaal, want het blijft een gebeuren tussen mensen en tussen mensen en computersystemen.

Als we opnieuw de applicatie voor de collectieve schuldenregeling als voorbeeld nemen. Dit is opgestart na de grote problemen van april 2005. Er was dus nog geen analyse, want het ging om een volledig nieuwe bestelling. Toch kwam er geen levering. Ik heb daar een probleem mee. Dit kan geen toeval zijn.

Fedict had enkel een adviserende rol. Heeft de Rechterlijke Orde dan te laat gereageerd?
Goh, ik denk dat ze altijd wel geluisterd hebben. Maar goed, de plug eruit trekken doe je niet zomaar. Er zijn veel mensen die me vertellen dat dit vroeger had moeten gebeuren. Wel, ik nodig iedereen uit om naar hier te komen en het zelf maar eens te proberen. Een contractbeëindiging heeft enorm veel consequenties, niet alleen voor de leverancier maar ook voor de gebruiker. Feit is nu dat we met een oude toepassing zitten, Mammoeth, die we eigenlijk hebben laten uitdoven. Nu moeten we dat systeem hals over kop restaureren.

Vormde ook de gegevensoverdracht van dat oude systeem naar de Oracle 10g-database geen probleem?
Welnee, dat is technisch allemaal op te vangen. Wel had Unisys oude informatie doorgegeven aan de leverancier van Mammoeth (Axylis, nvdr.). Door alle veranderingen was namelijk ook de database zelf aangepast, waardoor sommige velden verdwenen waren. Maar eigenlijk zijn dat peanuts. Zoiets is louter een communicatiestoornis, niks meer.

Heel concreet: is de functionele analyse voor de collectieve schuldenregeling nog herbruikbaar?
Ik denk het wel. Al moet je alles wel in het juiste perspectief plaatsen. Behoeftes evolueren. Als blijkt dat meer dan 40 procent moet veranderd worden, kunnen we beter helemaal opnieuw beginnen. Al zal eerst nog juridisch moeten blijken wie nu eigenlijk de eigenaar is van al die informatie – in het geval Justitie van plan zou zijn om een rechtzaak aan te spannen en de contractwaarde terug te eisen.

In haar verklaring zei minister Onkelinx dat ook de aangekochte servers nog rendabel konden worden gemaakt. Valt die uitspraak serieus te nemen?
Natuurlijk. Een
computer blijft een computer. U gaat nu toch niet vertellen dat de aangekochte servers de specifi caties hebben van een webserver bijvoorbeeld? Een box blijft een box. Ik zie geen enkel probleem: die machines zijn perfect lineair uitbreidbaar. Ze dateren ook nog maar van 2006.

Kunt u een concreet voorbeeld geven waarvoor ze kunnen dienen?
Om het oude Mammoeth-systeem nieuw leven in te blazen. Dit is een systeem dat nog altijd draait op RS 6000-machines van IBM. In totaal zijn er een 220-tal, waarvan we er 26 vervangen hebben omdat ze volledig in de soep draaiden. In afwachting van ‘een nieuw Phenix-systeem’ zetten we nu -als overbruggingsscenario- alles over naar de oude Bull-omgeving die we nog hadden staan.

Is alleen het bedrijf Axylis in staat om dit te doen?
De Mammoeth-toepassing komt van hen… Dus ja.

U bent per definitie aangewezen op dit ene bedrijf?
Gezien het crash-scenario, vrees ik van wel.

Wordt dit dan geen openbare aanbesteding?
Er zijn verschillende pistes denkbaar, waaronder het fameuze artikel 17 dat ons toelaat om in dergelijke penibele omstandigheden, wanneer er slechts één kandidaat is, toch naar die kandidaat te stappen. Maar ik kan u verzekeren dat dergelijke procedures heel streng worden gecontroleerd. Dit kan trouwens alleen met goedkeuring van de ministerraad.

Hoe lang zullen die palliatieve zorgen aanhouden?
We moeten realistisch zijn. We zitten nu met verkiezingen, zodat we sowieso moeten wachten wie de nieuwe minister van Justitie wordt. Vooraleer je echt een nieuw traject kunt opstarten, zijn we wellicht twee à drie jaar verder. En dan ben ik eigenlijk nog zeer optimistisch.

Eén van de verwijten is dat Unisys te weinig terreinkennis had. Gaat u hiermee akkoord?
Ik denk het wel.

Bent u dan niet tekort geschoten in uw waakhondfunctie?
Wij kunnen toch alleen maar op de fouten wijzen in de functionele analyse? Al geef ik toe dat we ooit het voorstel hebben gelanceerd om het project over te nemen, want er is een groot verschil tussen de rol van waakhond en die van de voorzitter van de raad van bestuur.

Was het lastenboek wel specifiek genoeg?
Ik geloof het wel. Zeker in het geval van het 3-tier-verhaal en de omgeving waarin we zouden werken. Op een bepaald moment hebben we er een eigen applicatie-architect op gezet, die eigenlijk constant aangaf welke zaken niet klopten. Een 2-tieromgeving zou goed kunnen werken bij een gesloten omgeving, wanneer men het aantal gebruikers kent. Maar bij het Phenixsysteem krijgen ook mensen van buitenaf, zoals advocaten, toegang. Dan weet iedereen dat je een 3-tier moet gebruiken.

Hoe groot schat u eigenlijk de collaterale schade bij de Rechterlijke Orde door de vele vertragingen van het Phenix-project?
De juristen zijn dit nu aan het berekenen. Wij hebben zelf onze input geleverd, maar ik denk niet dat het gepast is om dit in de pers te zeggen. Dat is meer iets voor de rechtbank.