Met een besluit tot uitbesteding zijn de gesignaleerde problemen niet zomaar van tafel. Reengineering blijkt namelijk vaak een noodzakelijke voorwaarde voor het welslagen van de operatie. Daarmee treedt tevens een verschuiving van de oorspronkelijke doelstellingen op, waardoor het geheel volgens A.P. Kuiper trekken krijgt van evolutionair ontwikkelen.
Menige automatiseringsafdeling kampt met een fors onderhoudsprobleem. De achterstand van enkele jaren wordt groter en groter. Vaak is de operationele programmatuur tien tot vijftien jaar oud, reeds vele malen gemigreerd naar andere omgevingen en even zovele malen gewijzigd ten gevolge van wensen van gebruikers, EDP-afdelingen, functioneel/technisch ontwerpers en soms ook programmeurs.
De structuur van een dergelijk systeem is in het algemeen compleet zoek en de documentatie – als deze al bestaat – is geheel niet up to date. De programmeurs die de code ooit hebben geschreven, zijn al lang doorgestroomd naar andere functies of andere bedrijven, en de huidige programmeurs kunnen niet meer ontdekken wat de ideeën of concepten achter de vroegere programma’s waren.
Aangezien software te kostbaar is om zomaar weg te gooien en volledig opnieuw te beginnen, denkt men vaak aan reengineering/(ver)nieuwbouw of uitbesteden. Eenmaal gestart met de reengineering, blijkt dit een zeer moeizaam traject te zijn. Van een worst maak je geen varken meer. Met als gevolg, pas op de plaats om te kijken of er andere oplossingen bestaan. De laatste tijd komt de gedachte aan uitbesteding steeds vaker op. Om duidelijk te maken wat precies de relatie is tussen reengineering en uitbesteding, eerst een nadere beschouwing van deze beide begrippen.
Reengineering
Bij reengineering komt vaak het begrip restructureren voor. Hieronder verstaat men in het algemeen het transformeren van een produkt van de ene naar de andere vorm. De doelstelling hierbij is dat de functionaliteit niet verandert (denk bijvoorbeeld aan het omzetten van ‘spaghetti’-code programma naar een gestructureerd programma). Het begrip restructureren komt men ook wel tegen bij de ‘software-fabriek’, waar men zoekt naar herbruikbare bouwstenen.
In het geval van reengineering – ook renovatie genoemd – stelt men uit de bestaande informatiesystemen een repository samen, van waaruit informatie(deel)systemen en documentatie opnieuw zijn te genereren. Hierdoor wordt onderhoud eenvoudiger, efficiënter en effectiever. In de generatieslag wordt veelal gesproken van verandering van functionaliteiten.
Reengineering bestaat in feite uit drie componenten. Allereerst zou men iets moeten doen aan reverse engineering om de applicatie op te trekken naar een wat hoger niveau. Vervolgens dienen de nodige veranderingen te worden aangebracht, opdat de applicatie conform de nieuwe methodologie kan worden ontworpen. Tenslotte dient men hierop forward engineering toe te passen.
Denk bij het begrip reverse engineering aan het uit elkaar rafelen van code om op deze wijze achter de specificaties van het ontwerp te komen. Het resultaat is een abstracte/formele beschrijving van het systeem. Het doel van reverse engineering is divers. Allereerst wil men de complexiteit van het systeem onder controle krijgen, waarbij het natuurlijk belangrijk is om zoveel mogelijk (verloren) informatie onder ogen te krijgen. Daarnaast zal het noodzakelijk zijn om de rode draad weer duidelijk te maken en deze te scheiden van allerlei neveneffecten ten gevolge van de vele wijzigingen in de loop der tijd. Met behulp van grafische programmatuur is de rode draad aanschouwelijker te maken. Tenslotte kan reverse engineering bijdragen aan hergebruik (softwarefabriek/bouwstenenfilosofie) van bepaalde componenten uit reeds geschreven code (zie ook restructurering).
Met name door het herhaaldelijk screenen van de code met behulp van een reverse-engineeringtool kan men overeenkomst in functionaliteit in de code ontdekken. Dit alles leidt tot een resultaat dat op een hoger niveau weergeeft wat de programmatuur doet of beoogde te doen.
Bedrijfsgegevensmodel
Reverse engineering is te onderscheiden in data reverse engineering en process reverse engineering. Deze laatstgenoemde techniek is nog zeer pover. In de praktijk blijkt volledige design recovery in slechts zeer beperkte mate mogelijk te zijn. In het algemeen betekent dit handwerk, en dus hoge kosten. Aangezien de data het meest stabiele deel is van de applicatie, kan deze op zich redelijk goed gescand worden. Indien men meerdere applicaties scant, zou men er zelfs toe kunnen overgaan om een soort bedrijfsgegevensmodel te genereren. Dit gegevensmodel zou vervolgens zo geconstrueerd moeten worden dat elk object uit de werkelijkheid slechts eenmaal in het uiteindelijke schema wordt weergegeven. Vervolgens vindt er van elk objecttype een vertaling plaats naar een overeenkomstig objecttype van een project, systeem of deelsysteem. Zo kan bijvoorbeeld het objecttype ‘Persoon’ in het bedrijfsgegevensmodel voor het ene systeem worden overgezet naar het object ‘Klant’ en voor het andere systeem naar het objecttype ‘Debiteur’/’Crediteur’.
Een schema-integratie zoals hiervoor beschreven blijkt in de praktijk al bijna onmogelijk op papier, om maar niet te spreken over een database-generatie vanuit een bedrijfsgegevensmodel.
De oorzaak ligt met name in het feit dat het uiteindelijke entiteiten-schema zeer ingewikkeld is en dat toegevoegde data-redundantie (in verband met hoge responstijden, krappe batchwindows en dergelijke) vaak niet voldoende onderkend is. Automatische normalisatie van het bedrijfsgegevensmodel is dus bijna niet mogelijk.
Een tweede probleem dat zich hierbij voordoet vormt de structurering van de gegevens. Deze is afhankelijk van het gebruik, en daarvoor heeft men een (volledig) inzicht nodig in het deel process reverse engineering. Neem bijvoorbeeld het object ‘Klomp’, met als eigenschappen: maat, prijs en kleur. Dit zijn de generieke eigenschappen van dit object. Impliciet hebben we dan aangenomen dat het object ‘Klomp’ gebruikt wordt als schoeisel, terwijl dat niet hoeft. Veel mensen hangen een klomp op om deze te gebruiken als bloempot, en dan blijkt ineens dat ditzelfde object andere eigenschappen heeft.
Een derde probleem bij het scannen van DDL (descriptive design language)-statements en dergelijke, is dat men over het algemeen niet exact de betekenis van de diverse attribuut-/entiteittypen kent. Dit betekent dat er met name op semantisch niveau diverse problemen kunnen ontstaan, wanneer men overgaat tot het samenstellen van een corporatief gegevensmodel. Reverse engineering betekent kortom nog steeds zeer veel handwerk. Indien het uiteindelijk toch lukt om een gedeelte van een systeem reversed te engineeren, dan is eventueel de formele syntaxis aan te passen aan de (nieuwe) gewenste functionaliteit en kan forward reengineering worden toegepast.
Uitbesteding
Quinn [9] behandelt het begrip uitbesteding vanuit het perspectief van het creëren van een intelligente organisatie. Hij doet dit met name in het kader van een service-based strategie. Een en ander is direct gerelateerd aan de waardenketen-theorie van Porter, onder andere beschreven door Kotler [3].
Deze theorie betreft twee soorten activiteiten in een organisatie, namelijk de primaire en de ondersteunende activiteiten. Voor elk van haar activiteiten berekent de onderneming de toegevoegde waarde en de daarbij behorende concurrentiepositie. Die activiteiten/diensten/produkten die in beginsel geen toegevoegde waarde hebben of niet leiden tot een goede concurrentiepositie, dienen feitelijk niet door de onderneming te worden verzorgd. Elke onderneming zal zo haar eigen core-business hebben, waarbij de niet-kern-activiteiten/diensten/produkten door een andere onderneming worden verzorgd. Hiervoor gaat men op zoek naar value adding partnerships (ook Broekstra noemt dit fenomeen het creëren van dynamische netwerkorganisaties).
Hierop doorgaand stelt Quinn dat het juist in een snel veranderende omgeving (zowel technologisch als economisch) veel makkelijker is om, als een technologie plotseling verandert, een andere leverancier te zoeken die zich gespecialiseerd heeft in deze technologie, dan in de eigen organisatie alles te moeten veranderen. Dit laatste is een veel duurdere investering. "Als activiteiten moeten worden geëlimineerd, is het gemakkelijker de organisatie platter te maken, hetgeen een essentieel ingrediënt is van snel responderende en klant-georiënteerde strategieën(…) Als nieuwe technologieën plotseling opkomen, is het gemakkelijker te schakelen tussen buiten het bedrijf gelegen resources dan het pad te betreden van interne investeringen en opleidingen(…) Door investeringen in verticale integratie te voorkomen en door intellectuele systemen te managen, kunnen ondernemingen zich meer substantieel bezighouden met hun core-business en minder met werknemers/machines(…)".
Wel dient men ondermeer rekening te houden met een mogelijke mismatch tussen de huidige vaardigheden van de eigen organisatie en de vaardigheden die nodig zijn voor de toekomst. Quinn waarschuwt voor het verlies van vaardigheden die van essentieel belang zijn voor projecten en andere werkzaamheden, en voor het potentiële verlies van controle over kritische leveranciers (over-afhankelijkheid van de leverancier). Verder is het altijd mogelijk dat de leveranciers hun plaats in de waardeketen veranderen, waardoor het bedrijf wordt gepasseerd, en dat er op cruciale momenten conflicten over prioriteiten ontstaan tussen bedrijf en leverancier.
Quinn wijst erop dat men dit vaak vergeet bij het overwegen van uitbesteding. Veel bedrijven gaan over tot uitbesteding omdat interne activiteiten dermate gebureaucratiseerd, conservatief of moeilijk in beweging te krijgen zijn, dat uitbesteding de enige oplossing lijkt. Nu is de redenering van Quinn niet zaligmakend. Grinwin [4] stelt dan ook : "De zwakste schakel in Quinn’s redenering ligt in de intensieve en grootschalige uitbesteding. Uit onderzoek is gebleken dat 70 procent van strategische allianties niet langer duurt dan vijf jaar. Het bewust scheppen van externe afhankelijkheid door het besef van interne tekortkomingen geeft een groot controleprobleem(…)"
Bewuste keuze
Er bestaan legio voorwaarden waaraan de relaties onderling dienen te voldoen. Denk bijvoorbeeld aan congruentie van doelen en aan strategische compatibiliteit, wederzijds vertrouwen, connecties tussen de twee ondernemingen op de drie niveaus (strategisch, tactisch en operationeel), bescherming van de eigen kerncompetentie, managen van grootteverschillen (wanneer de een vele malen groter is dan de andere, leidt dit onherroepelijk tot problemen), compatibiliteit in systemen, enzovoort.
Hoogeveen [2] geeft enkele voor- en nadelen van uitbesteding die als criteria kunnen dienen bij de besluitvorming, zie figuur 1. 
Vanuit deze gedachte valt het aan te bevelen om alleen informatiesystemen uit te besteden met meetbare, concrete, onmiddellijke resultaten, en met een lage specificiteit in plaats, middelen, personeel en software. Verder verdient het aanbeveling om het management van de informatievoorziening, en strategische en concurrerende informatiesystemen niet uit te besteden.
Magrassi [4] geeft de plaats aan van uitbesteding in het continuüm van de ‘maak-/koop’beslissing, zie figuur 2.
Het is verrassend om te zien dat men, bij een volwassener wordende systeemontwikkeling, van een ‘koop’-beslissing via uitbesteding naar een ‘maak’-beslissing gaat. Dit heeft te maken met het feit dat de volwassenheid van de systeemontwikkeling zelf afhankelijk is van de graad van structuur en van de technologische stand van zaken binnen de organisatie. 
Uitbesteding moet alleen worden overwogen als de systeemontwikkeling een hoge graad van structuur heeft, onafhankelijk van de stand van de technologie binnen de organisatie. "Een uitbesteding die plaats vindt met weinig of geen kennis van het te managen proces kan nooit wat worden".
Kelley [5] geeft een kostenmodel, aan de hand waarvan vaak besloten wordt om uit te besteden (figuur 3).
In eerste instantie lijkt dit een win-win situatie. De kosten van de eigen organisatie worden steeds hoger, echter door het afsluiten van een contract zijn deze kosten vastgezet op een bepaald bedrag. Door economies of scale kan de leverancier steeds goedkoper produceren. Kelley waarschuwt echter voor feit dat de vaste kosten zijn gebaseerd op een standaard abonnement. 
Elke extra wens kost in het algemeen meer dan het gemiddelde. Daarnaast is het erg moeilijk om het kostenpatroon binnen de organisatie voor de komende tien jaar te voorspellen. Hij merkt hierbij verder op dat de voordelen voor kleinere ondernemingen groter zullen zijn (door economies of scale-effect van de leverancier) dan voor een grotere onderneming. Laatstgenoemde zou in beginsel goedkoper moeten kunnen produceren dan de leverancier. Daar zijn een aantal redenen voor. Binnen de organisatie wordt geen sales/marketing en dergelijke meegerekend in de prijs, de interne IT-afdeling is een bekende entiteit en de interne staf kent de eigen procedures vele malen beter.
Uitbesteding moet een bewuste keuze zijn voor bepaalde typen informatiesystemen en de organisatie moet er gereed voor zijn. Deze informatiesystemen moeten vaak eerst gereengineerd zijn, voordat men zinvol en met in achtneming van de onafhankelijkheid tot uitbesteden kan overgaan.
Reengineering en uitbesteding samen vormen dan ook een paradox met verschuiving van doelen; onlosmakelijk verbonden en toch los.
Verschuiving doelstellingen
Het voorgaande maakt duidelijk dat reengineering vaak een moeizaam en handmatig proces is, en dat uitbesteding een operatie is waar een organisatie gereed voor moet zijn. Men zal het aandachtsgebied en de verantwoordelijkheden/bevoegdheden van managers immers gelijk moeten veranderen. Voor een minimale kans op fouten bij uitbesteding is in de organisatie een sterk management nodig dat de uitbestedingscontracten redelijk nauw in de gaten houdt. Alle eisen die de eigen organisatie moet stellen aan de applicatie, dient de leverancier te kennen in verband met de oplevering. Uitbesteding wil dan ook niet alleen zeggen dat een externe partij een gedeelte van het gehele management zal gaan doen, maar dat de interne organisatie duidelijk moet veranderen in een uitbestedingsorganisatie met een krachtig management op strategisch en tactisch niveau. Alle criteria ten aanzien van methoden, technieken, exploitatie en technische infrastructuur moeten klaar liggen voor ‘alle’ platformen en ontwikkelmethoden. Contractvoorbeelden, juristen, begeleiding inzake (tijdelijk) uitbesteed personeel dienen gereed te zijn.
Indien men kiest voor uitbesteding, dan is reengineering vaak een noodzakelijk kwaad en dient de organisatie ervoor gereed te zijn.
Wat blijkt nu echter? Is het onderwerp van uitbesteding eenmaal gedefinieerd en de organisatie gereed, dan is uitbesteden vaak niet meer nodig op de oorspronkelijke gronden (zoals eerder beschreven). De onbeheersbaarheid is opgelost, de eisen ten aanzien van de applicatie zijn in kaart gebracht, de organisatie is klaar. Er treedt een verschuiving van het doel op. Het gaat niet langer om de slechte structuur, de documentatie, het vertrek van programmeurs en dergelijke. Nieuwe doelen zijn het vrijmaken van eigen mensen voor nieuwere technologieën en het hanteren van resultaatverplichting in plaats van inspanningsverplichting, waardoor de grip op de leveranciers vergroot wordt. Voorts het verlagen van inhuurkosten, het helpen van het management bij het concentreren op de core-business, het uitbesteden van de inzetproblematiek, het inkopen van technische of innovatieve competentie, het verkrijgen van numerieke flexibiliteit enzovoort.
Naast deze ‘harde’ doelen, kan uitbesteding helpen bij ‘zachte’ doelen.’ Te denken valt aan het veranderen van de cultuur door over en weer personeel uit te wisselen in een soort joint-project waarin uitbestede projecten worden beheerd, het bewust maken van de medewerker dat het ook anders kan, het bewerkstelligen van een gedragsverandering vanuit de dreiging van uitbesteding enzovoort.
Feitelijk komen dan de doelstellingen naar boven die de prioriteit verdienen, indien men denkt aan uitbesteding.
Literatuur
1. G. Broekstra, Het creëren van intelligente organisaties, Eburon, 1989.
2. D. Hoogeveen, De praktijk van outsourcing, Kluwer Bedrijfswetenschappen, 1994.
3. Ph. Kotler, Marketing management, analysis, planning, implementation and control, Prentice Hall, 1991.
4. P. Grinwin, De intelligente onderneming, FEM, 1993.
5. R. Kelley, M. Light en R. Terdiman, Outsourcing is here to stay, Gartner Group, december 1993.
6. P. Magrassi, Make, Buy or Outsource : Who decides what?, Gartner Group, september 1993.
7. G. McDermed en R. Terdiman, Outsourcing : One way to accelerate the transition, Gartner Group, januari 1994.
8. K. McGee, Network outsourcing : Finally ready to come of Age?, Gartner Group, januari 1994.
9. J.B. Quinn, Intelligent enterprise, Free Press, 1992.
Drs. A.P. Kuiper is afdelingsmanager Systeemontwikkeling voor Ondernemingen bij het Belastingdienst Automatiseringscentrum te Apeldoorn.
