Outsourcing onder Architectuur

Geen enkele professionele programmamanager/projectleider zal het nu nog in zijn hoofd halen te beginnen zonder een gedegen architectuur. Toch zie ik bij menige outsourcing deal dat er wordt begonnen zonder adequate architectuur. Is dat niet vreemd? Outsourcing is immers een ingewikkeld programma, met als extra complicatie dat er minimaal twee juridisch gescheiden organisaties betrokken zijn: de uitbesteder en de leverancier, ook wel aangeduid als provider.

Eigenlijk heeft het fenomeen outsourcing een valse start gemaakt. De uitbesteder had bijvoorbeeld zijn applicatielandschap een beetje verwaarloosd en kon het daarom niet meer voor een redelijke prijs onderhouden. Dus deed hij een fraai strikje om zijn legacy en zocht een externe partij die dat verouderde applicatielandschap tegen een scherpe prijs een aantal jaren voor hem in de lucht kon houden. Dat aantal jaren was meestal te kort en de prijs te scherp zodat de leverancier het applicatielandschap nauwelijks kon verbeteren. Dus na afloop krijgt de uitbesteder de chaos gewoon weer terug. ‘Garbage in, garbage out’.
De juiste manier van outsourcing: (1) stel eerst een architectuur op; (2) inventariseer vervolgens de benodigde functionaliteiten passend in die architectuur en (3) koop die functionaliteiten op de externe markt. Dit is veel slimmer en biedt uiteindelijk meer flexibiliteit. Daardoor wordt outsourcing in feite inkoop. In wezen is dit sourcing uit een public cloud.

Outsourcing zonder architectuur lijkt op het geven van een sigarendoos met ongeordende bonnetjes aan je boekhouder. Omdat je niet weet wat je geeft, kan die boekhouder met een mooi prijsje op de proppen komen. Als je de bonnetjes echter eerst uitsorteert en/of in de vorm van een spreadsheet aanlevert, dan is het duidelijk wat de omvang is van zijn werkzaamheden en zal hij een scherpe prijs moeten voorstellen.
Als outsourcing niet verankerd is in de architectuur van de organisatie, ligt het risico op de loer dat de deal afglijdt naar een soort uurtje-factuurtje detacheringsklus binnen een raamcontract.
Sommige leveranciers hebben het liefst een chaotische verzameling appliacties, want door een beetje rationaliseren kunnen ze al gauw 25% besparen op de uitvoering. En dat is voor die leverancier een snelle winst.

Bij outsourcing strekt de totale oplossing zich uit over de uitbesteder én de leverancier. Hoe functioneert de architectenpopulatie voor die totale oplossing? Welke soorten architecten horen bij welke organisatie aanwezig te zijn en wanneer gaan zij met elkaar overleggen?
De huidige praktijk laat zien dat architecten te laat worden betrokken, dat architecten te weinig mandaat krijgen en dat architectuur door de leveranciers nog te veel wordt gezien louter als een verkoopargument in de aanbestedingsfase.

Bij menige leverancier staat bij de totstandkoming van de deal een accountmanager centraal die slechts geïnteresseerd is in zijn hoge bonus voor het afsluiten van de deal. Nuanceringen door architecten kosten tijd en dit ziet hij als mogelijke belemmering bij het snel afsluiten van die deal. Architecten van de leverancier worden daarom vaak pas na het afsluiten van het contract ingezet. Veel leveranciers hebben wel degelijk bekwame architecten. Maar het blijkt dat architecten van informaticabureaus liever direct voor een klant werken dan in een offertetraject. Dat laatste wordt gezien als intern werk en dat heeft bij informaticabureaus nog altijd een minderwaardig luchtje. Het is daarom belangrijk dat een uitbesteder al bij de ‘request for information’ eist dat de leverancier architecten inschakelt en hun cv bij het antwoord op de ‘request for proposal’ laat opsturen.
Gerenommeerde adviesbureaus eisen tegenwoordig dat in de aanloopactiviteiten tot het contract architecten van beide kanten met elkaar spreken, waarbij de verkopers van de leverancier op de achterste rij zwijgend mogen luisteren. Dit om te voorkomen dat de vaak wat opportunistische houding van de verkopers het gesprek domineren.

Simpel gesteld staat architectuur voor ‘breng eens wat orde aan in de business en de bijbehorende IT’. Outsourcing klinkt meestal als ‘doe de was de deur uit’, het lijkt er dan op dat men zo van de hoofdpijn af komt. Maar iedereen weet ‘wat niet kan worden bestuurd, kan zeker niet worden aangestuurd’. Het is dus absoluut onverantwoord zaken te outsourcen waar men geen overzicht over heeft. Dan wordt de organisatie overgeleverd aan het vrije spel van de leveranciers, die – wellicht onbewust en onbedoeld – de missie, visie en strategie van de organisatie onderuit kunnen halen.
Legacy en slechte business-IT alignment waren de klassieke problemen binnen de eigen organisatie die de adaptiviteit beperkten. Na outsourcing kunnen diezelfde problemen ontstaan tussen de organisatie en de leverancier. Je loopt het risico dat je als organisatie niet kunt veranderen door een onwrikbaar back office van de leverancier. In plaats van gevangen te zijn in de dwangbuis van je eigen overjarige IT, hangt er nu een leverancier als een blok aan je been! Architectuur is daarom een absolute noodzaak bij outsourcing, en wel aan beide kanten. En die architecturen moeten ook nog naadloos op elkaar aansluiten.

De PON-werkgroep ‘Outsourcing onder Architectuur’ heeft de afgelopen twee jaar intensief gewerkt aan het onderhavige onderwerp met als resultaten enkele papers, twee seminars en eerstdaags een illustratief boek dat wordt uitgegeven bij van Haren. Hierin worden theorie, ervaringen en raadgevingen gebundeld vanuit ABN AMRO, UWV, RWS, IBM, Obvion, Ordina, Quion, Sogeti, VKA, Quint Wellington Redwood en het advocatenkantoor Vondst.

Daan Rijsenbrij, www.Rijsenbrij-Academy.nl