Outsourcing zou veel efficiënter kunnen

Het gaat nogal eens mis met outsourcingstrajecten. In veel gevallen worden de betrokken softwareontwikkelaars verantwoordelijk gehouden. Maar volgens Anton Greve, directeur innovatie bij Antares, is dat niet terecht. Zij doen meestal wat van hen wordt gevraagd, maar op basis van ondeugdelijke instructies. Meer aandacht voor het voortraject zou veel problemen kunnen voorkomen.

It-dienstverlener Antares Match4 Groep is vorig jaar ontstaan uit een fusie tussen Match4 en Antares. Na de fusie is Antares volgens directeur innovatie Anton Greve op zoek gegaan naar de onderdelen van het ict-tracject waar het hardst verbeteringen nodig waren. Greve: “We kwamen al snel tot de conclusie dat het voortraject nog steeds een rommeltje is. Steeds als er gebouwd gaat worden, blijkt dat te gebeuren op basis van specificaties die niet helder zijn.”
Dit is geen onbelangrijke constatering, omdat de kosten voor het ontwikkelen van een softwareapplicatie voor de helft worden bepaald door dat voortraject. Antares besloot daarom het zwaartepunt van de organisatie te verleggen naar het begin van ict-trajecten. “Er bestaan wel allerlei mooie instrumenten voor de bouwfase, maar niet zozeer voor het voortraject. De laatste jaren wordt dat pas iets beter. Dat is vooral in het geval van outsourcing interessant, omdat dit staat of valt met het voortraject.” In de vertaalslag bijvoorbeeld van een Nederlandse onderneming naar een dienstverlener in India moet veel gebeuren. Er zijn veel partijen bij betrokken, en er is veel werk te doen, zoals het aanpassen van processen en procedures. Dat alles vergt veel investeringen.
“Overal waar ik kom zie ik problemen met het voortraject. Regelmatig kom je berichten tegen dat een project is mislukt, maar je leest nooit waarom. Er wordt dan wel gezegd dat er iets mis is gegaan met de bouw, met de ontwikkeling of met de kosten, maar je leest nooit dat de requirements en specificaties vooraf niet goed waren. Toch is dat vaak wat er aan de hand is.”

HYPE
Helemaal nieuw is deze boodschap niet. Begin jaren negentig stond de kwaliteit van projecten en intelligente kwaliteitssystemen even hoog op de agenda. “Volgens mij is daar uiteindelijk weinig van terecht gekomen. Het zijn allemaal papieren tijgers geworden. De kwaliteitshype hield bovendien op toen de hausse kwam in het midden van de jaren negentig. Toen het goed ging verdween de aandacht voor het onderwerp”, denkt hij. “Gebrek aan kwaliteit heeft geleid tot veertig jaar frustratie over zaken als de eenzijdige focus op de realisatiekosten en op de prijs per functiepunt bij het ontwikkelen van systemen. Maar de zaak wordt niet bij de kop gepakt, dat wil zeggen: bij het voortraject. Dat betekent dat je juist ook de gebruikersorganisatie moet aanpakken.”
Het probleem werd erger door het uitbesteden van ict, wat bedrijven onverwacht veel geld heeft gekost. “Bedrijven maakten specificaties, en dachten vervolgens dat ze hun automatisering goedkoop konden uitbesteden, en de benodigde software goedkoop konden laten bouwen. Dat gebeurt tot op de dag van vandaag. Dat werkt echter niet. Tien jaar geleden niet, en nu nog steeds niet.”
Greve pleit voor een pragmatische en vooral praktische benadering van dit probleem. “Het is een simpele vaststelling dat we ons de afgelopen twintig jaar hebben gefocust op steeds nieuwere technologie om de prijs per functiepunt naar beneden te krijgen. Toen dat uiteindelijke niet lukte, zijn we gaan outsourcen. Dat is geen leuke boodschap voor it-managers, maar dat is wel zo. Vaak is dat ingegeven door angst.”
Als blijkt dat een ict-afdeling niet in staat is om binnen een bepaalde tijd en binnen een bepaald budget te bouwen, gaan bedrijven op zoek naar manieren om dat op te lossen. Outsourcing lijkt daarbij een voor de hand liggende oplossing. “Maar dat laat onverlet dat, of je het nu hier doet of in India, het voortraject vijftig procent van de kosten uitmaakt. En juist dat voortraject is nog lang niet zo gestructureerd als het realisatietraject. In die realisatie word je wel gedwongen in structuren, onder andere door de technologie, de databasestructuren, de software en de sjablonen. Maar in het voortraject is het nog steeds gebruikelijk dat iemand een mooi stuk proza schrijft, waarin weinig structuur te vinden is. Je moet de requirements er tussen de regels door uit halen. De relaties tussen de informatie-elementen en de structuren ontbreken, omdat ze niet worden afgedwongen door een structuur zoals bij een database.”
Het zou dan ook een goede aanpak zijn om te kijken wat de huidige technologie te bieden heeft. De voortgang in techniek heeft die mogelijkheden fors verruimd. “Vroeger wilden we graag een repository hebben voor dat soort dingen, maar stond de stand van de techniek dat niet toe. Maar daar is verandering in gekomen, onder meer door de toegenomen processorsnelheid en openheid. Dat maakt het mogelijk het voortraject nu technisch aan te pakken. Dus in plaats van het inschakelen van een programmeur die alleen maar nieuwe functiepunten maakt, kun je de zaak in het voortraject al structureren.”

ENTHOUSIAST
Greve is nog niet zo lang met deze boodschap op pad, maar heeft ondertussen met een aantal cio’s en techneuten gesproken die volgens Greve zonder uitzondering enthousiast reageren. Ze zijn aanvankelijk cynisch, want ze hebben slechte ervaringen met procedures die al snel verzanden in administratieve rompslomp. Maar ze herkennen de problemen wel.
“Er bestaat een duidelijke behoefte aan goedkopere informatiesystemen en goedkoper onderhoud, en er is behoefte aan een snellere time-to-market. Daar komt bij dat gebruikersorganisaties de afgelopen jaren steeds sterker zijn geworden. De belangen van de gebruikersorganisaties zijn zwaarwegender geworden dan die van de ict, waar vroeger nog vaak vanuit de technologie werd gezegd dat iets niet kon.”
Om in het voortraject goed te kunnen structureren en bepalen wat belangrijk is, is het noodzakelijk een duidelijke visie te ontwikkelen. Greve: “Mijn stelling is: niets meer over de muur gooien, maar houdt voortdurend contact met de bouwfase. De scheiding tussen voortraject en bouwfase moet eruit. En niet alleen in naam, maar ook ècht. En dat realiseer je door product levenscyclusmanagement in te voeren. De basis daarvoor is goed requirements management.”
Dat kun je zien als een platform bestaande uit tools, waarmee je het voortraject en het projectmanagement integreert, en het architectuur- en bouwproces met het change management-proces. “Het is belangrijk daar nu goede afspraken over te maken. We moeten stoppen met alleen maar te kijken naar nog mooiere en snellere applicatiegeneratoren. In het voortraject zit de sleutel voor goed beheer van de levenscyclus, daar zit je time-to-market. Daar zit je werkelijke kostenbesparing.”

GEZOND VERSTAND
Dit verhaal geldt in algemene zin, maar nog veel meer bij outsourcing. Want juist bij outsourcing ontstaan alle problemen in het voortraject. “Ik heb eens met de directeur van een multinational gesproken die mij off the record vertelde dat hij het eigenlijk zelf goedkoper in eigen huis kon doen. Maar dat kon hij niet hardop zeggen in de organisatie, dat zou hem zijn baan kosten. Dat had alles te maken met de manier waarop het voortraject en de overdrachtsorganisatie was geregeld. Wat bovendien meespeelde was dat hij weliswaar een contract had voor vijf jaar, maar dat hij er daarna niet vanaf kon. De prijs ging dan waarschijnlijk omhoog, maar hij kon niet weg omdat hij dan niet meer de juiste kennis en mensen in eigen huis heeft.”
Requirements based product life cycle management is goed toepasbaar op grote legacy applicaties. Het voordeel is dat de implementatiekosten laag zijn, meent Greve. “Begin gewoon kleinschalig, met kleinschalige implementaties tegen lage kosten, en kijk eens hoe je je change management en je traceability kunt verbeteren. Het is eigenlijk gewoon gezond verstand. Meer is het niet. Door de techniek die nu beschikbaar is, kun je er nu mee aan de slag. De businessmensen zitten dichter bij de IT en stellen meer en hogere eisen. Je kunt ze daarom nu ook makkelijker duidelijk maken dat ze mee moeten doen. Die programmeurs zijn niet dom, het ligt niet aan de bouw. Daar is niets mis mee. Als je de zaak niet goed specificeert dan krijg je niet wat er zou moeten komen.”
Het begint met begrijpen dat je het voortraject serieus moet nemen. De ontwikkelmethode moet aansluiten op de moderne tooling voor requirements management. En wat je vooral moeten begrijpen, is dat alle stukken proza gestructureerd moeten worden. Proza moet worden opgeknipt in eenduidige informatie-elementen, waarvan de life cycle kan worden bewaakt en gemanaged. Vervolgens kan iedereen verder naar eigen inzicht zijn informatiesets modelleren. Het maakt dan niet uit welke tool je gebruikt. “Met name bij iteratieslagen die plaatsvinden tijdens het bouwen van applicaties zit veel terugkoppeling naar de gebuikersorganisatie. Hetzelfde geldt voor het acceptatietesten. Fouten en omissies zijn snel traceerbaar. Zo krijg je transparantie over de gehele life cycle.”