Als de systeemontwikkelorganisatie de uitdaging aanneemt en zich transformeert tot architectenbureau, kan ze ook in de toekomst een belangrijke bijdrage leveren aan het realiseren van de bedrijfsdoelstellingen van haar klanten, betoogt Paul Laagland
Zeven managers van grote systeemontwikkelafdelingen mochten in een ronde-tafel conferentie eens grondig hun hart luchten over de onmogelijke positie waarin ze door de bedrijfstop, hun eigen directie en hun klanten zijn geplaatst (Automatiseren tussen hamer en aambeeld, 13 juni 1997). Uit het verslag van deze bijeenkomst heb ik vijf knelpunten opgetekend.
De IT-organisatie is verantwoordelijk voor het kostenniveau van IT. Het topmanagement gaat uit van een financieel plafond gebaseerd op macro-economische overwegingen. De klanten van de IT-organisatie vragen echter om steeds meer IT in hun bedrijfsprocessen. Omdat sprake is van gedwongen winkelnering lopen de wachttijden op of krijgt de klant niet waar hij om vraagt. Dit resulteert uiteraard in ontevreden klanten.
Uitbesteden van onderhoud is riskant, omdat deze activiteit veelal afhankelijk is van een beperkt aantal medewerkers met kennis van de betreffende systemen. Uitbesteden van nieuwbouw biedt weinig soelaas, omdat toch ook eigen medewerkers op het project moeten worden ingezet. Die moeten immers zowel toezicht houden op de technische standaarden als de benodigde kennis opdoen om het systeem in onderhoud te kunnen nemen.
De IT-vraag van de organisatie kan onvoldoende worden opgevangen met eigen medewerkers. Om daarin toch te kunnen voorzien, huurt de organisatie steeds meer externen in, waaronder managers. Dit doorkruist het streven van de systeemontwikkelorganisatie om de afhankelijkheid van ingehuurde derden te beperken.
De time-to-market van nieuwe producten is vaak afhankelijk van de snelheid waarmee de IT-ondersteuning te realiseren valt. De IT-organisatie wordt echter pas in een laat stadium bij de productontwikkeling betrokken. De doorlooptijd van de systeemontwikkeling valt te bekorten als de klant bereid is daar extra voor te betalen.
De toekomst van de ’traditionele’ programmeur wordt niet gezien als een knelpunt. De komende vijf jaar is er voor hen nog ruim voldoende werk. Aanbevolen wordt zelfs om de huidige programmeurs te koesteren.
Gedwongen winkelnering
Ik ben me ervan bewust dat veel systeemontwikkelorganisaties vandaag de dag geen eenvoudige opdracht hebben en onder hoge druk moeten werken. Dit mag echter geen excuus zijn om niet eens fundamenteel de eigen organisatie tegen het licht te houden. Dat de bedrijfstop de IT-kosten omlaag wil brengen is niet nieuw. In de laatste vijf jaar heeft het topmanagement van veel bedrijven acties in gang gezet die ertoe moeten leiden dat de organisatie als geheel veel flexibeler kan reageren op veranderingen in de markt, en dat tegen lagere kosten.
Hoewel IT daarbij steevast wordt genoemd als van belang om dat mogelijk te maken, is de werkwijze bij systeemontwikkeling sinds het begin van de jaren zeventig vrijwel niet gewijzigd. De doelmatigheid is verbeterd door het inzetten van IT in de eigen werkprocessen, maar verbeteringen die worden uitgedrukt in procenten volstaan niet meer. Net als bij een bpr-traject (business proces redesign) voor de bedrijfsprocessen moet de systeemontwikkelorganisatie op zoek naar verbeteringen die zijn uit te drukken in factoren. Dat is de enige manier om de genoemde knelpunten blijvend te verhelpen.
Enkele deelnemers aan de ronde-tafel conferentie constateren dat de klant vrijwel altijd ontevreden is als je de enige leverancier bent. Regelmatig een benchmark laten uitvoeren is echter geen oplossing. Je laat alleen maar zien dat vergelijkbare IT-organisaties dezelfde problemen hebben en even goed (of slecht) presteren. Er is maar één echte oplossing: een eind maken aan de gedwongen winkelnering.
Liberalisering
In een bredere maatschappelijke context zie je dat dit resulteert in betere dienstverlening (zie de liberalisering van de telecom-markt). Er zijn veel argumenten aan te voeren tegen liberalisering van systeemontwikkeling op dit moment, zoals het bewaken van de integriteit van de informatie-infrastructuur en de onvolwassenheid van de markt van andere aanbieders. Daartegenover staat dat veel systeemontwikkeltaken ook elders in de bedrijfstak worden uitgevoerd. Het openbreken van de markt geeft de IT-organisatie de ruimte om zich te kunnen concentreren op dié zaken waarin zij echt een toegevoegde waarde heeft ten opzichte van de andere IT-dienstverleners.
Als kader voor deze liberalisering wordt een driedeling voorgesteld in: ondersteunende bedrijfsprocessen, primaire bedrijfsprocessen en IT-infrastructuur.
Informatiesystemen voor de ondersteunende bedrijfsprocessen zijn niet uniek voor een organisatie. Er zijn dan ook specialisten in de markt die daar meer ervaring mee hebben. De systeemontwikkelorganisatie doet er goed aan de klant hierop te wijzen en daarmee duidelijk te maken dat zij niet de geschiktste partij is om deze projecten uit te voeren. Ze verkeert wel in een goede positie om de klant te adviseren bij de selectie van een andere IT-dienstverlener, ondermeer vanwege haar kennis van de huidige systemen en de noodzaak de interfaces met andere systemen goed te specificeren.
Voor de primaire bedrijfsprocessen geldt dat de systeemontwikkelorganisatie een duidelijke kennis- en ervaringsvoorsprong heeft op andere IT-dienstverleners. Daar komt soms bij dat de organisatie door een gerichte inzet van informatietechnologie een concurrentievoordeel kan opbouwen in de markt. Uitbesteding van IT-taken zal dan met de nodige waarborgen omkleed moeten worden. Een goede reden om ervoor te knokken deze opdrachten zonder dwang van boven voor de organisatie te behouden.
De IT-infrastructuur, waaronder ik ook de informatie-architectuur reken, is van strategisch belang voor het functioneren van de gehele organisatie. Als het topmanagement besluit dat deze taken binnen de eigen organisatie moeten worden belegd, is het aan te raden een splitsing aan te brengen tussen de beleids- en de uitvoeringsfunctie. De beleidsfunctie is dan voor deze onderwerpen verantwoordelijk voor het budget. De systeemontwikkelorganisatie zorgt voor een efficiënte uitvoering van deze IT-taken. De cio (chief information officer) die de KLM onlangs heeft aangesteld is een voorbeeld van zo’n beleidsfunctie (KLM benoemt eerste IT-topmanager, 6 juni 1997).
Spanningsveld
De laatste 25 jaar is er niet veel veranderd in de manier waarop informatiesystemen worden gerealiseerd. Het proces van systeemontwikkeling is zo ingericht, dat het vrijwel onmogelijk is taken af te bakenen waarop een externe partij volledig valt af te rekenen. De praktijk is dan ook dat ontwikkelcapaciteit wordt ingehuurd van externe IT-dienstverleners, maar dat de verantwoordelijkheid voor de projectresultaten geheel berust bij de eigen systeemontwikkelorganisatie.
Al eerder werd in Computable betoogd dat een splitsing nodig is tussen het ontwerp van systemen en het bouwen van de componenten waarmee deze worden gerealiseerd (Nieuwe IT-organisatie werkt als architectenbureau, 15 november 1996). Bij de IT-infrastructuur is dit de gewoonste zaak van de wereld; het is lang geleden dat een systeemontwikkelafdeling besloot een eigen besturingssysteem te schrijven omdat geen product beschikbaar was dat voldeed aan de eisen. Eén van de criteria bij het ontwerpen van de IT-infrastructuur is juist dat nieuwe ontwikkelingen gemakkelijk zijn in te passen: een nieuw model computer, een nieuwe versie van een besturingssysteem, een andere databasemanager. De ontwerper volgt daarbij zowel de veranderende vraag van de klanten als de ontwikkelingen in de IT en probeert daarin steeds de juiste balans te vinden. In feite is meer sprake van het beheer van de IT-infrastructuur, waarbinnen projectmatig (kleine) aanpassingen worden gerealiseerd.
Ook bij de informatiesystemen is feitelijk sprake van een beheerfunctie. De gebruikers vragen om aanpassing van deze systemen, omdat zij de bedrijfsprocessen beter willen afstemmen op de ontwikkelingen in de markt. De veranderingen in IT bieden nieuwe mogelijkheden, maar maken ook aanpassingen noodzakelijk omdat hardware en software niet langer meer worden ondersteund. In dit spanningsveld zou een team van IT-architecten een lange-termijn perspectief moeten ontwikkelen van informatiesystemen en IT-infrastructuur, als kader waarbinnen de ontwikkeling en het onderhoud van systemen kunnen plaatsvinden.
Van zelfbouw naar beheer
De huidige systeemontwikkelorganisatie besteedt veel tijd en energie aan het realiseren van software. Omdat iedere vraag van de klant weer anders is, worden steeds unieke software-oplossingen gerealiseerd. De klantgerichte opstelling van de applicatieprogrammeur vormt in feite de grootste belemmering voor het dramatisch verhogen van de productiviteit van systeemontwikkeling. Bedrijven die software-ontwerp wel als kernactiviteit hebben, investeren fors in de ontwikkelinfrastructuur en proberen zoveel mogelijk te werken met standaard softwarebouwstenen.
De taak van het IT-architectuurteam is om daar goed gebruik van te maken. Immers, door een softwarecomponent vijf keer te gebruiken, stijgt de productiviteit van systeemontwikkeling met een factor vijf.
In een moderne visie op systeemontwikkeling zijn het ontwerp en het beheer van de IT-architectuur en het ontwerp en de bouw van softwarecomponenten dus twee schakels die onafhankelijk van elkaar zijn in te richten. De realisatie van software komt daarbij het meest in aanmerking om te worden uitbesteed aan externe IT-dienstverleners.
Als de systeemontwikkelorganisatie verschuift van zelfbouw naar beheer van de architectuur, is ook duidelijk in welke richting de verhouding tussen interne en externe medewerkers moet worden bijgesteld. De leden van de architectuurteams zijn bij voorkeur eigen medewerkers die een lange-termijnperspectief kunnen ontwikkelen ten aanzien van de IT-architectuur en die, op projectbasis, in kleine stappen de huidige architectuur in de gewenste richting kunnen bijstellen. Het zal altijd wel nodig zijn om specialistische deskundigheid van externe adviesbureaus te betrekken, maar hierbij zal veelal geen sprake zijn van detachering.
De software-ontwerpers die de bouwstenen voor de IT-architectuur leveren, hebben geen specifieke affiniteit met de bedrijfsprocessen van de eigen organisatie. Ze zijn eerder gericht op een specifieke ontwikkelomgeving, waarbij ze software realiseren voor een breed scala aan toepassingen. Ze kunnen dan ook beter op afstand worden geplaatst van het bedrijf. Uitbesteding behoort dan ook tot de mogelijkheden. Als er nog geen voldoende gekwalificeerde partij in de markt is om een deel van de software-ontwerpactiviteiten volledig over te nemen, kan men tijdelijk kiezen voor een model waarbij deze activiteiten worden ondergebracht in een joint venture tussen de systeemontwikkelorganisatie en een externe IT-dienstverlener. Op de korte termijn worden de risico’s gedeeld en op de lange termijn kan de externe partij de aandelen van de systeemontwikkelorganisatie overnemen.
Deze beschouwing maakt het vraagstuk van de verhouding intern/extern minder relevant: bij de software-organisatie is het streven juist naar een grotere betrokkenheid van de externe dienstverlener, dus ook in het management.
De ‘oudere’ programmeur
De deelnemers aan de ronde-tafel conferentie vinden dat ze te laat worden ingeschakeld als de organisatie een nieuw product op de markt wil brengen. Ze spelen met de gedachte een prijsdifferentiatie aan te brengen: de klant betaalt meer voor een snellere bediening. Ook opperen ze de mogelijkheid dan maar weer het principe van quick-and-dirty in ere te herstellen, en eventueel later het gestabiliseerde systeem opnieuw en dan conform de standaarden te realiseren. Deze benadering komt voort uit een wederzijdse afhankelijkheid tussen klant en IT-organisatie (gedwongen winkelnering) en een groot verantwoordelijkheidsgevoel van de systeemontwikkelorganisatie. Uiteindelijk is het voor beide partijen beter wanneer ieder zijn eigen verantwoordelijkheid neemt.
Een commerciële afdeling die IT als gereedschap te laat inschakelt, loopt het risico op de blaren te zitten. Door ze de vrijheid te geven zelf hun IT-leverancier te kiezen, ontstaat duidelijkheid. Deze partij kan al dan niet tegen een acceptabele prijs de gewenste ondersteuning leveren. Zo niet, dan heeft de commerciële afdeling een wijze les geleerd en zal men daar in de toekomst beter rekening mee houden. Zo ja, dan is het de systeemontwikkelorganisatie duidelijk dat ze in deze situatie onvoldoende toegevoegde waarde biedt. De prijs die voor de dienst wordt gevraagd, is afhankelijk van de waarde die aan deze dienst wordt gehecht.
Tot slot de ‘oudere’ programmeur, voor wie er voorlopig nog genoeg werk is. Hij werkt in de organisatie die software-ontwerp als kernactiviteit in haar vaandel heeft staan en die op termijn wordt uitbesteed. Het knelpunt ligt hier niet bij de programmeurs van middelbare leeftijd, maar bij de nieuwe generatie IT-professionals die hun carrière starten als ’traditioneel’ programmeur. Vele van hen hebben een gedegen opleiding op hbo- of universitair niveau, maar krijgen nu vaak een beperkte beroepsopleiding en gedurende drie tot vijf jaar een beperkte ervaringsopbouw. Juist deze eerste jaren van hun loopbaan zouden de fundamenten moeten leggen voor hun functioneren als IT-architect of software-engineer.
Als ze zich over enige jaren verder willen ontwikkelen, hebben ze op dit punt een achterstand opgelopen die in een aantal gevallen moeilijk overbrugbaar zal blijken te zijn. Het getuigt van een goed human resources-beleid en van een bewuste en gerichte investering in de toekomst als een IT-organisatie daarop inspeelt door ook in de eerste jaren deze programmeurs voldoende breed op te leiden en ook buiten het traditionele programmeren ervaring te laten opdoen.
Als de systeemontwikkelorganisatie de uitdaging aanneemt en zich transformeert tot architectenbureau, kan ze ook in de toekomst een belangrijke bijdrage leveren aan het realiseren van de bedrijfsdoelstellingen van haar klanten. In dit transformatieproces zal ze moeten samenwerken met externe IT-dienstverleners, zodat binnen de hierboven geschetste kaders gericht software-realisatietaken zijn over te dragen.
Prof. dr. Paul T.M. Laagland,
directeur van Ises International,
hoogleraar Bestuurlijke Informatiekunde aan de Katholieke Universiteit Brabant
