Innoveren is ook…samenwerken opnieuw uitvinden

 
2 oktober 2016

CASE PRORAIL

Door een rigoureuze reset van de samenwerking met serviceproviders heeft ProRail afgerekend met een aantal oude gewoonten – aan beide kanten van de tafel. Mini-competities en agile werken zijn de nieuwe succesfactoren. Marcel Lacomblé, tendermanager bij ProRail, legt uit.

Bij ProRail bestaan vrijwel alle kernsystemen uit maatwerk software die mission critical is: als ze niet of niet goed functioneren komt alles letterlijk tot stilstand. Voor het veilig en tijdig laten rijden van treinen heb je – naast goed personeel – zowel een spoorboekje nodig als verschillende veiligheidssystemen. Het procesbesturingssysteem bevat de dienstregeling die bepaalt welke trein wanneer rijdt. Andere systemen zorgen voor de vertaling van de rijroute naar bijvoorbeeld de aansturing van wissels en seinen. En tot slot zijn er systemen voor de continue monitoring van de veiligheid op het spoor. Eind 2010 stond ProRail voor de uitdaging om verschillende verouderde systemen te vervangen door Astris, een nieuw te ontwikkelen geïntegreerde applicatie die verschillende treinbeheersingssystemen moest vervangen. Astris vormde mede de aanleiding om het proces van applicatieontwikkeling van ProRail opnieuw te ontwerpen.

foto-marcel-lamcomble

Marcel Lacomblé

Leuren met capaciteit

“Tot 2010 had ProRail een aantal huisleveranciers dat zich bezig hield met op beheer gericht ontwikkelwerk. Dat liep redelijk, maar met de vernieuwingsprojecten raakten we steeds meer achterop”, stelt Marcel Lacomblé. “Zo liep een Europese aanbesteding helemaal vast, omdat de gekozen leverancier niet kon leveren. Bij veel beheercontracten kwamen de leveranciers elk jaar langs om te vertellen dat het duurder werd, de tarieven werden geïndexeerd volgens de CBS-index. Ondertussen wist ik dat aan de leverancierszijde te weinig werd geïnvesteerd in kennis en kunde – ik heb namelijk ook aan de andere kant van applicatieontwikkeling gewerkt.”

Op dat moment zag de markt van IT-dienstverleners er niet bijzonder rooskleurig uit. Er was sprake van overcapaciteit; banken hadden hun IT-tarieven al gehalveerd. Omdat de IT-contracten binnen ProRail tot dan toe versnipperd waren georganiseerd, probeerden leveranciers die bij de ene projectleider geen extra werk kregen, het een paar deuren verderop gewoon opnieuw. “Regelmatig met succes”, aldus Lacomblé; “zelfs het verprutsen van projecten had geen negatieve consequenties. Niet de meest optimale omstandigheden om de ontwikkeling van het Astris-pakket op de reguliere wijze in de markt zetten.”

‘Je moet kennis hebben van wat je aanbesteedt, anders ben je volkomen afhankelijk van de markt’

Kennis herwinnen

“Uitbesteden is een van de uitgangspunten van de IT-strategie van ProRail. Er zat echter meer kennis over de systemen bij onze leveranciers dan bij onszelf. Wanneer wij als IT-afdeling iets wilden doen voor de business, dan hadden we daar vaak de leverancier bij nodig. Een belangrijke voorwaarde voor goed opdrachtgeverschap is dat ProRail zelf kan specificeren. Je moet kennis hebben van wat je aanbesteedt, anders ben je volkomen afhankelijk van de markt,” zegt Lacomblé. Omdat er grote tijdsdruk was, koos ProRail voor een opmerkelijke tussenstap: men besloot tijdelijk het werk te insourcen en zo tijd te winnen om nieuwe ontwikkelprojecten op een nieuwe manier in de markt te zetten. ProRail ging aan de slag met het opbouwen van een eigen applicatieontwikkelteam: er werden bureaus, laptops en servers aangeschaft en men ging op zoek naar de beste IT’ers. Een situatie die afweek van de uitbestedingsstrategie, maar die tijdelijk werd gedoogd.

De regie herpakken

Ondertussen ging Lacomblé aan de slag met het opnieuw uitvinden van de sourcingstrategie. Uitbesteden bleef het uitgangspunt, maar er moest gesleuteld worden aan snelheid en kwaliteit. Een van de eerste beslissingen was ‘het verlagen van de knip’. “Software bouwen is een commodity,” vindt Lacomblé, “het echte werk zit in het ontwerp en de specificatie. Voorheen namen leveranciers een relatief groot deel van het ontwikkeltraject voor hun rekening. We besloten het functioneel specificeren naar onszelf – en de interne klant, de verkeersleiding – toe te trekken.”

Een tweede beslissing was om de applicatieontwikkelomgeving te vereenvoudigen. “ProRail heeft gekozen voor standaardisatie van ontwikkelplatforms op basis van technologiestacks; per stack is er een ontwikkelomgeving gedefinieerd. Leveranciers die mee willen doen, moeten zich kwalificeren op verschillende stacks, bijvoorbeeld op basis van Java, C++ of .Net.”

Meer regie nemen, dat bleek een verstandige keuze. Al tijdens de marktconsultatie vroeg ProRail aan de leveranciers welke ontwikkelomgeving en ontwikkelprocessen zij gebruikten voor hun andere klanten. Lacomblé vertelt: “Op zo’n moment blijkt dat ze de meest mooie voorzieningen in huis hebben. Maar die werden tot dan toe niet bij ons ingezet. Ik begrijp het wel; een state of the art ontwikkelomgeving betekent minder ontwikkeluren. Tevens wilden we als opdrachtgever niet verantwoordelijk zijn voor de gereedschapskist van de leverancier. Om dit risico weg te managen zijn de kosten voor de ontwikkel- en testomgeving opgenomen in het uurtarief.”

Optuigen van mini-competities

Om te voorkomen dat leveranciers binnen ProRail zouden doorgaan met leuren, is de contractomvang groot genoeg gemaakt en is gekozen voor meervoudig concurrerende raamovereenkomsten. Binnen de raamcontracten wordt gewerkt met mini-competities, waarbij de leveranciers een aanbieding kunnen doen. “Een mini-competitie is niet vrijblijvend. Je moet inschrijven en als je aanbieding minder dan de helft van het puntenaantal behaalt, word je gediskwalificeerd.”

Bij de beoordeling kijkt ProRail naar de kwaliteit van het team dat wordt aangeboden, de aangeboden ontwikkelomgeving en het Plan van Aanpak (hoe de leverancier de applicatie gaat ontwikkelen of in beheer gaat nemen). Er worden fictieve kortingen berekend voor zaken als past-performance, CO2-reductie en kwaliteit van de aanbieding.

“Omdat het om de ontwikkeling van maatwerksoftware gaat, is het lastig vooraf nauwkeurig de werkomvang te bepalen. Daarom bepalen wij zelf het aantal uren voor een agile team; de leverancier bepaalt de samenstelling van het team: testers, ontwikkelaars, projectleiders, scrum masters, architecten.”

Tot slot zijn nieuwe, niet onderhandelbare inkoopvoorwaarden gespecificeerd. “Dat is iets waar grotere spelers niet akkoord mee zouden gaan. Wij waren echter op zoek naar dienstverleners die qua omvang en werkwijze goed aansluiten bij ProRail. De omvang van de dienstverleners hebben we ook een rol laten spelen in het beoogde ideale aandeel van het te verdelen werk.”

De wedstrijd

Bij iedere mini-competitie vindt een startbijeenkomst plaats en ontvangen de partijen die zich hebben gekwalificeerd voor de betreffende stack het dossier van de mini-competitie. “De omvang van dit soort projecten varieert. Sommige projecten lopen even lang als de raamovereenkomst – zes jaar plus vier verlengingsmogelijkheden van een jaar, het geval bij Astris met een budget van één miljoeneuro per jaar. Bij de kleinste projecten kan je denken aan een app met een budget van minder dan een ton,” legt Lacomblé uit. Na de beoordeling wordt het project gegund aan de Economisch Meest Voordelige Inschrijving (EMVI).

Het is misschien wel het belangrijkste onderdeel van de aanpak met mini-competities: de performance van een serviceprovider binnen een gegund project telt ook mee in de kans om een volgend mini-contract te krijgen. Alle contracten worden halfjaarlijks beoordeeld op meer dan twintig punten en door meerdere personen. De score kan een kwaliteitskorting opleveren. Om de snelheid er in te houden zijn de mogelijkheden om bezwaar aan te tekenen tegen prestatiemetingen en gunningen binnen de raamovereenkomst beperkt.

‘Je moet niet bang zijn de samenstelling van een team te wijzigen als dat nodig is’

Schrikreactie

ill-spokenDeze nieuwe aanpak leidde tot de nodige schrik, zowel binnen ProRail als in de markt, aldus Lacomblé: “Het heeft veel tijd gekost om iedereen voldoende uitleg te geven en mee te krijgen. Intern heb ik regelmatig een stap terug moeten zetten alvorens ik weer een stap vooruit kon maken. Vooral het opnieuw aanbesteden van de huidige werkpakketten leidde tot grote schrik: iedereen moest zijn bestaande leveranciers loslaten ‘die al twintig jaar voor ons werken!’. Ook inhoudelijk heeft het formuleren van alle dossiers, templates, protocollen, prestatiemetingen, rapportages en SLA’s veel voorbereidingstijd gekost: bijna twee jaar. Wat leveren wij, wat verwachten wij, hoe ziet de ontwikkel- en teststraat er uit?”

Uiteraard riep de nieuwe aanpak ook vragen en bezwaren op bij de leveranciers: hoe werkt dat met die mini-competities? “Er was veel ge-jamaar en er werden allerlei pogingen ondernomen om het tij te keren: ‘we werken al zo lang met jullie samen, het kan toch niet zo zijn dat we opnieuw moeten inschrijven? Dat geldt toch niet voor ons?’ Er werd tot op hoog niveau in de ProRail-organisatie gelobbyd”, zegt Lacomblé. “Maar kijk om je heen: in allerlei sectoren verandert de samenwerking met leveranciers.”

Nieuwe spelregels, nieuwe spelers

Aan de gesloten aanbesteding deden acht partijen mee, waarvan er uiteindelijk vier zijn geselecteerd. Met deze vier partijen heeft ProRail raamovereenkomsten gesloten voor twee of meerdere technologiestacks. Alle vier de partijen kunnen bijvoorbeeld met Java en .Net werken. Lacomblé is helder over de resultaten. “We hebben letterlijk de hit-and-run aanpak weten uit te bannen en hebben in plaats daarvan rust gecreëerd. Leveranciers blijven hun best doen om binnen het raamcontract zo goed mogelijk te presteren – het risico is anders dat ze er na een paar jaar uitliggen. Het aanpassingsvermogen verschilt tussen de leveranciers: niet alle vier partijen slagen er in om tijdens de minicompetities contracten binnen te halen. Aan de andere kant zijn er binnen het viertal ook partijen die elkaar op bepaalde aspecten versterken en die dit succesvol weten uit te venten bij andere opdrachtgevers.”

Ook binnen ProRail is vrijwel iedereen behoorlijk enthousiast. Het opzetten van een nieuw spel met nieuwe regels heeft veel tijd gekost, maar levert nu transparantie, gemak en tijdwinst op, omdat processen gestandaardiseerd zijn.

Samenwerken, om hulp vragen: moeilijk

“Het overleg is nu gestructureerd op operationeel, tactisch en strategisch niveau. Iedere maand spreekt de service level manager van het contract de rapportages van de leverancier door met die leverancier. Bij agile doe je dat het liefst op de locatie van de leverancier. Het vraagt de nodige aandacht om projectleiders, ontwikkelaars en ontwerpers zo ver te krijgen om echt samen te werken als een team. Samenwerken en delen, dat zit niet bij iedereen in de genen – dat geldt ook voor de leveranciers. Vooraf bespreken wat je gaat doen, sommige mensen vinden dat maar niks. Nu staan we wekelijks voor een bord en vertelt iedereen waar hij mee bezig is. Wat heb je gedaan, waar ben je tegenaan gelopen, welke hulp heb je nodig? Hulp vragen is moeilijk: het voelt als toegeven dat je hebt ‘gefaald’. We hebben zelfs een puntensysteem ingevoerd: op een niet afgehandeld issue moet je iedere week een stipje zetten. Na drie stipjes vragen we door: waarom han
gt dat issue nog steeds op de muur? Je moet ook niet bang zijn de samenstelling van een team te wijzigen als dat nodig is. Zeker als de samenwerking met de leverancier niet goed verloopt, is het verstandig gebleken andere medewerkers in te zetten. Ook aan de leverancierszijde werd dit gebaar sterk gewaardeerd.”