Zeven managers van systeemontwikkelafdelingen van top-100 bedrijven kwamen aan het begin van de lente bijeen in Huis ter Duin te Noordwijk om van gedachten te wisselen over hun ervaringen en frustraties.
Schuilend bij elkaar, tussen teakhout en damast, was er eindelijk begrip voor problemen waar niet alleen de buitenwacht, maar ook het eigen bedrijf doorgaans aan voorbijgaat: de spanning tussen topmanagement en gebruikers, de spagaatstand die krappe financiën en IT-vraag moet overbruggen, maar tot verkrampte arbeidsverhoudingen leidt, de onrealistische meerjarenplannen van een opgejaagde directie, uitbesteding tot in India toe, de luidere roep van de commerciële afdeling en vooral het permanente gevoel de kop van Jut te zijn.
In hetzelfde hotel waar het Nederlands voetbalelftal zich voorbereidt op de volgende wedstrijd, discussieerden zeven managers van grote systeemontwikkelafdelingen over de uitdagingen op h�n terrein. Onder voorzitterschap van Tony Hassan (Kpmg, Londen) en Paul Teeuwen (Kpmg, Utrecht) wisselden G. Ensing (ABN-Amro), L. van Berkum (HBG), E. Duijvesteijn (Philips Components), T. van der Meer (KLM Information Systems), B. Paping (PTT Telecom), F.Lenssinck (Belastingdienst) en H. Holtkamp (Kadaster) ervaringen uit en trachtten zij een antwoord te vinden op een aantal belangrijke vragen uit hun branche. Cruciale kwesties zijn: de relatie tussen organisatie en klanten; de verantwoordelijkheid van de gebruikersorganisatie; het time-to-market-probleem; nieuwe systemen en vaardigheden; uitbesteding; ontwikkelstrategie; en het delen van kennis.
1. Relatie met de klanten
Tegenwoordig spitsen de knelpunten zich volgens de deelnemers aan de ronde-tafelconferentie toe op het middenmanagement en op de gebruikers zelf. Bij grote projecten is het vaak moeilijk een goed samengestelde afvaardiging te krijgen van de gebruikersorganisatie. Vaak verliezen de afgevaardigden enigszins het contact met hun achterban, wat vooral in internationale projecten ingewikkeld is. Overigens signaleert men op dit punt een interessant cultuurverschil: buiten Nederland wordt veel makkelijker geaccepteerd dat een systeem nu eenmaal is ontworpen zoals het ontworpen is.
De IT-kosten blijven een gevoelig punt. Vaak blijven ze in absolute zin stijgen, terwijl de klant ze niet ziet als investeringen. Waar het echter om gaat, is hoe de kosten zich verhouden tot de baten. In hoeverre neemt de totale prestatie van de organisatie toe?
De deelnemers signaleren een gevaar voor IT-organisaties in het algemeen en systeemontwikkeling in het bijzonder. Men stelt de IT-organisatie verantwoordelijk voor het kostenniveau van IT, terwijl de verantwoordelijkheid voor de vraag bij de gebruikers ligt. Het topmanagement gaat uit van een financieel plafond, dat gebaseerd is op macro-economische overwegingen. Het vraagt zich echter niet af wat dat moet betekenen voor de IT-vraag van de verschillende afdelingen of business units.
De deelnemers menen dat de IT-organisatie pertinent moet weigeren in deze spagaat van verantwoordelijkheden terecht te komen. Vanuit die positie verliest zij altijd: het IT-budget wordt overschreden, terwijl de gebruikers nog lang niet tevreden zijn. Als men de IT-kosten wil beperken, moet dat consequenties hebben voor de vraag van de verschillende afdelingen. Uiteraard blijft de IT-organisatie verantwoordelijk voor levering van de gevraagde diensten op een efficiënte manier.
Interessant is de constatering van enige deelnemers dat de klant vrijwel altijd ontevreden is als je de enige leverancier bent (gedwongen winkelnering). Het regelmatig (laten) doen van een benchmark is dan een must. Daarmee kan men laten zien dat de prestaties van de eigen afdeling vergelijkbaar of zelfs beter zijn dan die van concurrerende organisaties.
Conclusies:
- De tevredenheid van de klant wordt even sterk bepaald door zijn verwachting als door het ontwikkelde systeem.
- IT-kosten beperken betekent óók: de vraag in de hand houden.
- De klant is zich scherp bewust van de IT-kosten, terwijl over de IT-baten weinig bekend is. De IT-organisatie heeft dan ook behoefte aan objectieve gegevens over die baten. Dit is zeker het geval als in de verhouding tussen klant en ontwikkelaar sprake is van gedwongen winkelnering.
Tevredenheid is uitkomst minus verwachting. Werken aan de verwachting heeft derhalve evenveel effect op de klanttevredenheid als werken aan de uitkomst. Hier liggen talrijke kansen voor de IT-afdeling. Het aantoonbaar maken van IT-baten door benchmarking is eveneens een ingrediënt.
2. Gebruikers verantwoordelijk
De stelling dat ieder IT-project in feite bestaat uit verschillende projecten, werd door de deelnemers in grote lijnen onderschreven. Men ziet het algemene projectmanagement voor IT-projecten als de verantwoordelijkheid van de bedrijfsorganisatie.
Uitgangspunt is dat er geen IT-projecten zijn, alleen bedrijfsprojecten. Deze moeten dan ook worden geleid door een projectleider uit de bedrijfsorganisatie. Dat garandeert de directe betrokkenheid van de klant. In het verleden is door IT-organisaties vaak geklaagd over het ontbreken van deze betrokkenheid. De deelnemers melden veel verbetering op dit punt.
De projectleider moet overzicht hebben over wat de bedrijfsorganisatie met het project beoogt en weten welke consequenties dat heeft voor het verandermanagement (MOC) en de inrichting van de processen. Dit geheel wordt programmamanagement genoemd, een rol die wezenlijk uitgebreider is dan die van de traditionele IT-projectmanager. De systeemontwikkelafdeling heeft de verantwoordelijkheid om de IT-aspecten van een project in goede banen te leiden. Daartoe stelt men vaak een IT-deelprojectmanager aan onder de programmamanager.
Een belangrijke rol van de systeemontwikkelmanager is het afdwingen van de juiste projectstructuur. Hij moet er op toezien dat er een stuurgroep komt met daarin een vertegenwoordiging van het bedrijfsmanagement. Vanuit de gebruikersorganisatie moeten de taken binnen het project op de juiste manier zijn ingevuld. Met het eisen van deze structuur gaat de systeemontwikkelmanager misschien buiten zijn boekje, maar in de praktijk krijgt hij de schuld als het project niet succesvol is. Een thema dat regelmatig terugkwam in de discussie, is dat de IT-afdeling zich zeker niet ‘slaafs’ moet opstellen.
De deelnemers maken niet in alle gevallen systematisch onderscheid tussen verandering van de administratieve processen (AO) en organisatie-ontwikkeling (MOC). Men ziet deze aspecten hoe dan ook als de verantwoordelijkheid van de klantorganisatie, in het bijzonder die van de programmamanager.
Conclusies:
De bedrijfsorganisatie moet de algemene leiding op zich nemen bij de uitvoering van IT-projecten. In feite bestaan er geen IT-projecten, maar uitsluitend bedrijfsprojecten, geleid door een programmamanager.
Aanbevelingen:
De systeemontwikkelmanager moet de juiste projectstructuur desnoods afdwingen. Laat hij dit na, dan zal hij verantwoordelijk worden gehouden voor tegenvallende projectresultaten.
3. Time-to-market
Het commerciële management heeft dikwijls de klacht dat de IT-organisatie een knelpunt vormt bij de introductie van nieuwe producten op de markt. Alle aanwezigen herkennen deze kritiek. Nadat men al stappen heeft genomen om de complexiteit van de IT-organisatie te reduceren, komt men tot twee soorten mogelijke oplossingen.
De eerste luidt: om de time-to-market te reduceren, is de betrokkenheid van de IT-organisatie in een vroeg stadium van de discussie over nieuwe producten de meest aangewezen weg.
Ten tweede is het mogelijk om de onderneming de keuze te geven tussen ‘gewone’ ontwikkeling tegen ‘normale’ kosten en ‘extra snelle’ ontwikkeling tegen hogere kosten.
Nieuwe producten komen in werkelijkheid zelden uit de lucht vallen. Als ineens een ‘kant en klare’ vraag wordt gedropt bij de systeemontwikkelorganisatie, zijn afdelingen voor marketing of productmanagement daar al vaak een jaar mee bezig. Eerdere betrokkenheid van de IT-organisatie biedt grote voordelen. De kunst is om in overleg te blijven.
Vroege betrokkenheid helpt de klantorganisatie de IT-vraag op een meer praktische manier te stellen. Kleine wijzigingen kunnen de realisatie van het plan veel eenvoudiger en goedkoper maken. Soms zijn al vroeg voorwaarden te scheppen die de uitvoering kunnen bespoedigen. Goede voorbeelden hiervan zijn uitbreiding van het telecommunicatienetwerk of het maken van een interface.
Verder wijzen de deelnemers erop dat de realisatietijd van een systeem geen vast gegeven is. Het bespoedigen van de ontwikkeling is doorgaans mogelijk, maar kost geld. Enkele organisaties beschikken over (in de loop van de tijd verzamelde) gegevens, die het voor de klantorganisatie mogelijk maken deze kosten/baten-afweging te maken.
Conclusies:
Hoe eerder in overleg, hoe meer kansen op een bevredigend resultaat. Bij een uitdrukkelijke vraag naar snellere ontwikkeling vormt de berekening van hogere kosten hiervoor een mogelijkheid. De klant kan dan zelf de afweging maken. De afgesproken termijn moet dan uiteraard wel worden gehaald.
Aanbevelingen:
Vroeg meepraten en -denken blijkt zowel de IT- als de klantorganisatie voordeel op te leveren. Als het dan toch nog extra snel moet, verheldert het de verhoudingen als de IT-organisatie over een ‘prijslijst’ beschikt voor die extra snelheid. Voorwaarde om hierover afspraken te kunnen maken is dat de klant vertrouwen heeft in de IT-organisatie. Dat vertrouwen kan alleen worden verdiend door waar te maken wat je belooft en niet door onder druk beloften te doen die niet zijn na te komen.
Ook bij deze discussie blijken prestatiemetingen waardevol te zijn in de onderhandeling met de klantorganisatie.
4. Systemen en programmeurs
Anders dan verwacht maakten de deelnemers zich weinig zorgen over wat te doen met de programmeurs die al jaren het fundament van de systeemontwikkelafdeling vormen. Zeker, er komen nieuwe client/server-systemen bij, maar dat is ‘extra’, niet ‘in plaats van’. Een nieuw callcenter voor effectentransacties bijvoorbeeld blijkt niet te leiden tot een afname van de traditionele manier van effectenhandel.
Daarnaast moeten er vaak nog interfaces worden geschreven en is er de ‘jaar 2000’-problematiek. Kortom, de komende vijf jaar is er voor de ‘oudere’ programmeur nog ruim voldoende werk. Hoe het daarna gaat is moeilijk te zeggen – dat vindt men buiten de planningshorizon liggen.
Conclusie:
Nieuwe systemen gebruikt men naast de oude en niet in plaats van. Voor ’traditionele’ programmeurs is voorlopig nog volop werk.
Aanbeveling:
Als aanbeveling geldt hier: wees zuinig op uw huidige programmeurs.
5. Outsourcing
Het vraagstuk van outsourcing is altijd goed voor de nodige discussie, zo ook bij deze bijeenkomst. Het blijkt dat de term verschillende betekenissen heeft en dat de aanwezigen er sterk wisselende ervaringen mee hebben. Eén van de deelnemers heeft een contract in de initiële fase zien sneuvelen. Bij een ander kwam het ook tot diensten aan derden, maar deze strategie is daar inmiddels verlaten.
Inhuur beschouwt men vaak niet als uitbesteden, maar dat is het in feite wel. De meeste deelnemers streven ernaar de afhankelijkheid van ingehuurde derden te beperken door meer eigen personeel aan te nemen. Echter, in de praktijk stijgt de vraag naar personeel vaak sneller dan men mensen kan aannemen.
Soms gooien onrealistische meerjarenplannen van de directie roet in het eten. De situatie kan zich voordoen dat de directie voorschrijft dat de personeelsbezetting van de systeemontwikkelafdeling terug moet van honderd naar zestig personen, terwijl de business units juist méér eisen op het gebied van systeemontwikkeling. De bizarre en ongewenste uitkomst kan zijn dat op een bepaald moment zestig eigen mensen systemen ontwikkelen, naast negentig externen.
Alle deelnemers zien de controle over hoge percentages externen (meer dan 25 procent) als een probleem, zeker als daaronder ook managementfuncties zijn. Op een gegeven moment heb je externen die externen aansturen die externen aansturen.
Als oplossing zoekt men soms partnerschappen met de softwarehuizen op de Nederlandse markt. Men heeft echter nog niet een samenwerkingsvorm gevonden waarbij risico en profijt op een evenwichtige manier zijn verdeeld tussen het eigen bedrijf en het softwarehuis.
Bij nieuwbouwprojecten vragen vooral twee punten de aandacht. Als ook externen het systeem moeten onderhouden, moet dat geprogrammeerd worden met behulp van technische standaarden. Alleen dan is het mogelijk het onderhoud ook daadwerkelijk uit te voeren. Verder moet bij de overdracht van het systeem ook kennisoverdracht plaatsvinden. Vaak wordt dit opgelost door een aantal interne medewerkers met de uitbesteder te laten meewerken.
Het tweede punt is dat een systeem dat door derden wordt gemaakt, eerder en veel eenduidiger moet worden gespecificeerd. De eigen programmeurs begrijpen onduidelijke specificaties vaak nog wel, maar externen niet.
Het uitbesteden van het onderhoud van oude systemen blijkt een riskante zaak. Vaak hebben maar enkele mensen verstand van deze systemen. Als zij vertrekken naar een uitbesteder, bestaat het risico dat hun kennis verloren gaat. Zeker nu de problematiek van het jaar 2000 erbij komt, moet een systeemontwikkelafdeling zich wel tweemaal bedenken alvorens het onderhoud van bestaande applicaties uit te besteden.
Dikwijls echter zit deze kennis al bij externen, vaak bij verschillende bedrijfjes. Dan rest niets anders dan op de huidige voet door te gaan tot het systeem aan vervanging toe is.
Is uitbesteding naar landen waar de arbeidskosten lager zijn wellicht een optie? De deelnemers blijken hier positief tegenover te staan. Men denkt met name aan India. Wel moeten in zo’n geval de condities goed zijn en aan enkele voorwaarden zijn voldaan. De specificaties moeten aanzienlijk duidelijker en eenduidiger zijn dan gewoonlijk en het management van een op die wijze uitbesteed project moet zeer strikt zijn. Niets mag aan het toeval worden overgelaten.
Alle deelnemers benadrukken hoe belangrijk het is de bedrijfseigen bedrijfsprocessen te kennen als men gaat uitbesteden. Wat je ook uitbesteedt, je moet zorgen dat je begrijpt wat je uitbesteedt.
Conclusies:
Onder outsourcing verstaat men in de praktijk zowel inhuur van individuele IT-specialisten als het uitbesteden van projecten. In beide betekenissen wordt het ervaren als een moeilijk beheersbaar, maar onvermijdelijk fenomeen: een onzekere factor voor zowel de financiële als de technische resultaten. Aan het management van uitbesteding valt het nodige te verbeteren.
Aanbevelingen:
Bij uitbesteding moet altijd de vraag zijn wat wordt uitbesteed. Zowel jegens de directie als voor de eigen afweging is het nodig drie situaties te onderscheiden.
- Gaat het om algemene processen zoals die in alle bedrijven worden uitgevoerd en die doorgaans weinig specifiek zijn, bijvoorbeeld salarisadministratie of grootboek? Die zijn over het algemeen goed uit te besteden.
- Daarnaast zijn er processen die alle bedrijven in een bepaalde bedrijfstak uitvoeren en waarin de klant weinig onderscheid waarneemt of waar weinig toegevoegde waarde inzit. Denk aan de distributie van verschillende kranten, of, volgens sommigen, betalingsverkeer. Een gezamenlijke dochter, zoals Interpay, is in staat deze processen uit te voeren. Een andere mogelijkheid is het intern uitvoeren van de processen met een standaard branchepakket.
- Processen die concurrentievoordeel opleveren, zijn alleen op basis van exclusiviteit uit te besteden. Daarbij brengt het eigen bedrijf de kennis van het proces in en de uitbesteder de voor dat proces benodigde IT-kennis.
6. Welke ontwikkelstrategie
Alle deelnemers erkennen dat de markt snelle introductie van nieuwe producten eist van de bedrijfsorganisatie. Als IT een belangrijk deel van zo’n product is, is de druk van de bedrijfsorganisatie op de IT-organisatie om snel te leveren legitiem.
In de discussie werden vier ontwikkelmethoden onderkend, die aansluiten bij verschillende eisen aan een systeem en de verschillende emoties hierover in de bedrijfsorganisatie. De aansluiting tussen de ontwikkelstrategie en de eisen van de klant, ook in emotionele zin, vond men van groot belang. Bij het vaststellen van de optimale ontwikkelstrategie zou ook de verwachte levenscyclus van de applicatie moeten worden beschouwd.
Een concreet voorbeeld hiervan was de aanbeveling om bij experimentele ventures de technische normen en standaarden enigszins los te laten. De prioriteit ligt dan bij de snelheid van ontwikkeling. Indien zo’n venture succesvol is en naar verwachting langere tijd en voor grotere volumes gebruikt gaat worden, treedt een andere fase in. Dan is het moment aangebroken om het opnieuw te ontwikkelen met inachtneming van normen en standaarden. Is het product op de markt geen succes, dan moeten zowel product als applicatie worden afgevoerd.
Op de bevinding uit onderzoeken dat de optimale efficiëntie van de systeemontwikkeling werd bereikt met projecten voor acht personen die maximaal een half jaar duren, werd ietwat meewarig gereageerd. De deelnemers onderschrijven deze bevinding, maar hun gemiddelde project is nu eenmaal veel groter. Het streven om projecten zo klein mogelijk te houden is er bij iedereen. Of men het streven haalt, hangt af van de aanwezigheid van een goede IT-architectuur.
Echter, in de praktijk is een IT-architectuur iets vloeibaars. Je kan niet spreken van het wel of niet hebben van een IT-architectuur. Eerder is sprake van het al dan niet hebben van een raamwerk dat zich ontwikkelt. Bij elke wijziging of aanvulling wordt een stuk IT-architectuur verder ontwikkeld – of om zeep geholpen. In alle gevallen moeten men kiezen tussen ‘praktische’ oplossingen die op gespannen voet staan met een heldere architectuur en ‘ingewikkelde’ oplossingen die zich beter aan dat raamwerk houden. In de praktijk heeft deze taak nog geen duidelijke vorm in de organisatie. Uiteindelijk zullen de cio (chief information officer) en de informatiemanagers van de business-unit deze verantwoordelijkheid moeten nemen.
Als ander punt brengen de deelnemers naar voren dat het niet langer adequaat is te spreken over systeemontwikkeling. Steeds meer is sprake van simultaan ontwikkelen van systemen en infrastructuur. Praktisch gesproken leidt dit tot de noodzaak om de architectuur van de infrastructuur in de plannen mee te nemen, en tot de eis om gezamenlijk met de beheer- en exploitatie-afdelingen te ontwikkelen.
Conclusie:
Vasthouden aan technische standaarden moet op basis van inzicht gebeuren. Hetzelfde geldt voor het al dan niet inpassen van een nieuwe applicatie in het raamwerk van de bestaande IT-architectuur. Inzicht in de emotionele waarde die de bedrijfsorganisatie aan een nieuw te ontwikkelen systeem toekent, helpt hier de juiste keuze te maken.
Aanbevelingen:
Een ‘beste’ ontwikkelstrategie bestaat niet. De keuze welke ontwikkelstrategie de optimale is, valt niet te nemen op basis van uitsluitend technische argumenten. Ook hier is communicatie met de bedrijfsorganisatie de enige goede basis voor een beslissing.
7. Kennis met elkaar delen
Elke systeemontwikkelaar weet dat het wiel regelmatig opnieuw wordt uitgevonden. Sommige deelnemers streven naar verbetering door een database aan te leggen van methoden, technieken en oplossingen. Het probleem is alleen waar te beginnen. Het is gemakkelijk om een dergelijke database van ’tips en trucs’ te raadplegen, maar nog niet zo makkelijk om er een op te zetten.
Sommige softwarehuizen, zoals Volmac en SHL, stellen hun kennis op commerciële basis ter beschikking. Dat kan het startpunt zijn voor het aanleggen van een eigen database.
Soms blijken verrassend eenvoudige wegen naar Rome te leiden. Een praktijkvoorbeeld is een gemakkelijke en effectieve manier van kennis delen met behulp van een interne website met ‘vaak gevraagde vragen’. Deze intranet-site verminderde in enkele maanden tijd het aantal telefoontjes naar de helpdesk met 20 procent. Zo’n oplossing valt ook voor de ondersteuning van de systeemontwikkelaars in te zetten.
8. Epiloog en stappenplan
Wat kunt u als manager van de systeemontwikkelorganisatie op dit moment concreet doen? Uit de discussie kwam het onderstaande stappenplan naar voren, waar een manager op kan inhaken. Let wel, de stappen bouwen op elkaar voort. Het heeft dus geen zin om met de zesde stap te beginnen als de voorgaande niet zijn gerealiseerd.
Tot slot: één en ander mag wat instrumenteel lijken, in de ogen van de aanwezige managers biedt dit stappenplan een houvast om binnen de dagelijkse realiteit het overzicht te houden.
STAPPENPLAN
Stap 1
Actie manager: alleen beloven wat u kunt waarmaken.
Opmerkingen: als dit niet wordt geaccepteerd, zoek dan een andere werkkring.
Stap 2
Actie manager: maak duidelijk wat u precies belooft. De gebruiker (is de klant) moet goed begrijpen wat hij wanneer kan verwachten.
Opmerkingen: volg een communicatiecursus.
Stap 3
Actie manager: zorg dat projecten volgens plan worden afgerond. Als de planning realistisch was (zie boven), moet dat kunnen. Het invoeren van projectmanagement is een must voor een goede systeemontwikkelorganisatie.
Opmerkingen: dit moet de hoogste prioriteit krijgen.
Stap 4
Actie manager: voer een systeemontwikkelmethodiek in met de bijbehorende tools, bijvoorbeeld SDM en SDW.
Opmerkingen: dit zal in de praktijk altijd een geleidelijke invoering zijn.
Stap 5
Actie manager: zie erop toe dat ook de gebruikersorganisatie haar verantwoordelijkheid neemt in projecten (zie de discussie over programmamanagement en de instelling van een stuurgroep).
Opmerkingen: start niet met het desbetreffende project als hieraan niet is voldaan.
Stap 6
Actie manager: biedt gedifferentieerde methoden aan voor systeemontwikkeling, met verschillende prijs/kwaliteit/snelheid-verhoudingen.
Opmerkingen: selectieve uitbesteding kunt u eveneens als oplossing aanbieden.
Stap 7
Actie manager: zoek een optimale balans tussen wat de klant nodig heeft en wat de systeemontwikkelafdeling kan. Het in stap 3 opgebouwde vertrouwen is nodig om hierover met de klant te kunnen onderhandelen.
Opmerkingen: zwaai zonodig met de portefeuille. Anders valt u terug naar stap 1.
Paul Teeuwen is senior consultant bij Kpmg Management Consulting te Utrecht.