2
oktober 2006: Sourcing: insourcing, outsourcing, offshore,
nearshore....
Het is
al weer even geleden dat ik in mijn column in het maandblad Informatie
(column 40: Outsourcing)
op het uitbesteden van werk aan derden ingegaan ben. Dat komt
omdat ik in mijn praktijk als informatiearchitect vaak erg weinig aanleiding
zie om outsourcing aan te bevelen. Jazeker, voor overzichtelijke, afgeronde
hoeveelheden werk waarvan je weet wat moet gebeuren zou je het kunnen
overwegen, maar dat is vaak niet wat gevraagd wordt.
Sourcing
is voor een informatiearchitect een simpel iets: zo lang het totaal
van de informatievoorziening van een organisatie er beter van wordt
is feitelijk mogelijk. Maar ja: zo lang het totaal er beter van wordt....
Wat is dat nu precies? En wat betekent het?
Stel je
voor dat je totale informatievoorziening een lappendeken is, waarbij
de "lappen" goed op elkaar aansluiten, de juiste diensten/services
leveren en dat de prijs daarvoor acceptabel is. Dan heb ik dus feitelijk,
vanuit deze invalshoek, geen probleem, want het is immers één
geheel. Het lastige zit in de "lapjes" die niet op elkaar
aansluiten en de "lapjes" die niet de gewenste dienst/service
leveren enz. Je kunt namelijk niet van externen verwachten dat zij kunnen
uitwerken hoe die aansluiting wel goed gemaakt moet worden, of hoe die
dienst/service aangepast moet worden om hem wel het juiste te laten
doen. Dat zult u hen immers zelf moeten vertellen, want u bent de enige
die weet wat u wilt.
Nu ken
ik weinig organisaties die goed weten wat ze hebben willen, laat staan
dat ze dat precies aan derden kunnen vertellen. Een vriend van me in
Engeland doet al jaren zaken met India en zijn ervaring was dat je een
specificatie gemiddeld 10 keer moet doorgeven voordat het juiste eruit
komt. Tegen een kwart van de prijs betaalt u dan dus nog 2,5 keer de
prijs.
Stel nu
eens dat een IT-leverancier (softwarehuis, systeemhuis, IT-adviesbureau)
goed weet wat ze doen en waar ze mee bezig zijn. Een total quality categorie
of een CMM level 5 van de organisatie laat zien dat de procedures in
ieder geval gevonden worden, maar dat zegt niet veel over waar die procedures
toe leiden. Maar stel dat ze dat ook weten, en dat zij goed in staat
zijn om een specificatie in een product of dienst om te zetten. Wat
dan nog overblijft is dat ik het nog precies en goed aan hen moet vertellen.
Ik weet
niet of je dat wel eens meegemaakt hebt, maar toen ik jong was hebben
we eens een proefje gedaan met het doorgeven van verhaaltjes. Zet een
aantal mensen naast elkaar, en de eerste vertelt aan de tweede een verhaaltje
die dat door moet geven aan een derde en ga zo maar door. De laatste
komt dan zeker met een ander verhaal dan de eerste verteld heeft. En
dat geldt ook als we iets moeten vertellen, mondeling of schriftelijk,
aan een leverancier. Zeker, we zijn vakmensen onder elkaar en we zouden
weinig uitleg van de basis nodig moeten hebben, maar toch doen we dit
net zo hard verkeerd. Zelfs als beide partijen veel van een onderwerp
weten. Leg maar eens uit aan een healthcare IT-specialist in India wat
je precies van je Elektronisch PatientenDossier, dat je hem/haar wil
laten programmeren, verwacht. Het is immers al moeilijk genoeg voor
de meeste informatieanalisten om met gebruikers te praten, laat staan
dat je wat zij willen nog eens heel precies in het Engels aan mensen
in India, Hongarije of Korea moet vertellen. Ongeacht of beide goed
bekend zijn in hetzelfde toepassingsgebied, of niet. En daar voeg ik
dan nog het feit aan toe dat de procedures en werkwijzen niet altijd
tot op total quality of CMM level 5 uitgewerkt zijn.
Algemener
probleem
Dit brengt
me bij het onderliggende, veel algemenere probleem: het als organisatie
weten wat je hebt en wat je hebben wilt. Dit is dé bottleneck,
en dit is sinds de uitvinding van IT altijd de bottleneck geweest. We
weten vrijwel nooit wat een organisatie nu precies wil. Laat staan dat
ik dat kan vertellen aan externen. Bij insourcing kunnen we het zelf
nog in de gaten houden, maar zodra het naar buiten gaat hebben we ook
die controle niet meer.
Wat moet
ik dan weten? Laat ik dit in 2 groepen opknippen:
- Bij
investeren (bijv in IT-projecten): welke nieuwe ondersteuning
heb ik nodig voor mijn organisatie? Want met die kennis kan een nieuw
product of een nieuwe dienst/service gerealiseerd worden.
- Bij
exploiteren: welke ondersteuning heb ik en op welk niveau (kwaliteit
en tijd) wil ik die ter beschikking hebben? Want dat bepaald
hoeveel ik ervoor moet betalen.
Bij investeren
zullen we dus over iets nieuws moeten praten, terwijl we bij exploiteren
het over het bestaande hebben. Laat ik een paar punten noemen:
- Bij
investeren moet je als organisatie precies kunnen aangeven wat je
hebben wilt, en hoe het nieuwe conceptueel past bij wat je al hebt.
Over de IT-architectuur het volgende:
- Bij
insourcing: zullen de IT-ers hier een oplossing voor moeten vinden,
maar dat zal in het project uitgewerkt kunnen worden.
- Bij
outsourcing: het is uiterst onhandig en het kan zeer kostbaar
zijn om een IT-architectuur op te leggen aan een IT-leverancier.
Jouw IT-ideeen zullen immers zelden binnen de ervaring van de
IT-leverancier passen, laat staan dat ze kunnen gebruiken wat
ze al hebben. En dat geldt natuurlijk vooral als het beheer ook
uitbesteed gaat worden, want als je het resultaat zelf wil gaan
beheren zal in het project uitgezocht moeten worden hoe e.e.a.
past.
- Bij
exploitatie wordt het nog anders:
- Bij
outsourcing. Als een leverancier zijn eigen kennis en ervaring
kan gebruiken, dan zal de prijs die voor de exploitatie gerekend
wordt lager kunnen zijn. Stel je eigen IT-eisen, dan kan de prijs
exorbitant oplopen.
- Bij
insourcing. Feitelijk idem, alleen nu is mijn eigen IT-infrastructuur
waar ik mee werk. Maar ook die hoeft niet vanuit de organisatie
zelf aangestuurd te worden met een IT-architectuur.
Kortom:
we moeten weten wat de organisatie wil, maar de IT zelf uitwerken is
feitelijk, buiten te stellen randvoorwaarden, vaker beperkend en kostenverhogend
dan andersom.
De
praktijk anno 2006
Organisaties
zijn de laatste decennia zo aan het worstelen geweest met hun IT dat
ze nauwelijks nog oog hebben voor het belang van wat de organisatie
wil. Rond het millennium-probleem is het probleem Alignment geboren
omdat de analyses van het millennium probleem de chaos die de IT-infrastructuur
vaak is tergend helder aan het licht bracht. We begrijpen het nog weer
een stapje beter sinds we over services denken en praten. Niet de waanzinnig
complexe discussies over het inrichten van services, brokers, middleware
en dat soort zaken, maar de discussie over het eenduidig laten bieden
van door de gebruiker gewenste services door de IT-infrastructuur. Want
voor die services wil de gebruiker betalen, vooral als het de juiste
services zijn.
Het probleem
is echter wel dat we nog steeds het belang van IT zo ontzettend overschatten.
Natuurlijk is IT belangrijk voor tegenwoordige organisaties, maar de
meeste organisaties handelen niet in IT maar in iets totaal anders:
boeken, geld, melkproducten, verkeerslichten, wetgeving, schone kleding,
geknipte haren en ga zo maar door. Als je een geautomatiseerde sportschool
hebt, dan moet je je als sportleraar toch niet hoeven bezighouden met
het synchroniseren van computers? De beslissingen over welk soort netwerk
aangelegd wordt is toch ook geen strategische beslissing voor een energiebedrijf?
Dat is het electriciteitsnet in hun gebouwen toch ook niet?
De crux
zit op de behoefte van organisaties aan informatie in termen van kwaliteit,
tijd en geld. En IT-ers onderschatten dat vaak volledig. En dit is waar
veel outsourcing op fout aan het lopen is. Je kunt niet een groot blok
IT uit je organisatie outsourcen en dan niet goed nadenken hoe je dat
gaat managen. Hoe je veranderingen van die IT voor elkaar gaat krijgen.
Hoe je die IT-leverancier precies gaat vertellen wat je wil dat anders
wordt. En daar waren we dus juist erg zwak in, en dat blijkt overal
in de dagelijkse praktijk.
Gedegen
kennis van je informatie is cruciaal
Als je
niet weet wat je waar en wanneer aan informatie wilt hebben van een
bepaalde kwaliteit, zal je IT-leverancier je dat dan kunnen vertellen?
Nee, en als je het hen vraagt om dat uit te zoeken krijg je een IT-beeld
van je behoefte, en daar heb je weinig aan. Het is precies waar alle
sourcing op fout loopt: een gebrek aan kennis van je informatie. Het
niet bestaan van een door de organisatie zelf beheerde informatiearchitectuur.
Een informatiearchitectuur die je precies kan vertellen wat je nodig
hebt als een IT-leverancier erom vraagt. Ongeacht of deze IT-leverancier
in Nederland of Nieuw-Zeeland zijn kantoor heeft. Sterker nog, feitelijk
ongeacht of je insourced of outsourced, want van IT-ers, ook als ze
intern zijn, mag je niet verwachten dat ze je informatiebehoefte goed
op een rij krijgen. Het is namelijk hun vak niet, dus het is hen ook
niet kwalijk te nemen.
Sourcing
adviezen
Als een
organisatie investeert in haar informatievoorziening, of als men die
exploiteert dan zullen sources gevonden moeten worden die het werk doen.
Dat kunnen eigen mensne zijn (insourcing), of je kunt externen of organisaties
inhuren om het werk te doen (outsourcing), maar het principe blijft
feitelijk hetzelfde. Alleen de verantwoording en de controle ligt anders.
In dit kader de volgende adviezen:
- Weet
zelf heel precies welke informatie u wilt hebben. Deze kennis van
uw informatie en de behoefte daaraan geeft mede het unieke gezicht
aan uw organisatie, en de verantwoording daarvoor kan onder geen beding
aan externen overgedragen worden. De informatiearchitectuur is van
de organisatie, en deze zal zodanig opgezet en ingericht moeten zijn
dat het als cruciale kennisbron van het strategische management gezien
wordt. Deze kennis geeft de organisatie namelijk de kracht om pro-actief
regie te voeren over, onder meer, uw investeringen in en uw exploitatie
van IT. Ontwikkel en beheer daarom deze kennis, en dat hoeft echt
niet veel tijd te kosten.
- "Outsource
niet wat u zelf niet zou kunnen doen". Een dubbele ontkenning,
en een oude wijsheid, maar wel één die zeer waardevol
is. Als u te weinig weet van wat u door anderen laat doen, dan betaalt
u binnen de kortste keren de hoofdprijs voor een vaak inferieure dienst
of product.
- Als
u dan wilt gaan outsourcen, zeker als dat offshore is, zoek dan een
betrouwbare makelaar die u kan adviseren over de markt en eventueel
het buitenland. Dat is niet een IT-leverancier (softwarehuis, systeemhuis
of IT-consultancy) of een makelaar die op de een of andere manier
verbonden is aan een IT-leverancier, het dient een echt onafhankelijke
persoon of organisatie te zijn die u met echte kennis en ervaring
snel verder helpt.
Afronding
Outsourcing
doen we al vele jaren. Offshore, nearshore enz. outsourcing doen we
ook al een jaar of 15, maar pas de laatste jaren is het als een hype
over de wereld gewaaid. Na 2 of 3 jaar hype worden de eerste problemen
nu echt zichtbaar. Die problemen kon je van het begin af zien aankomen
(zie bijvoorbeeld
de column Outsourcing uit 2003). We hebben namelijk onze mond
wel vol van Service Oriented werken, maar we doen het nog van geen kant.
We zien allemaal onze problemen als we precies moeten gaan vertellen
wat we willen en nodig hebben, maar denkt u dat er soort engeltje is
dat zo lief is om precies te vertellen wat we nodig hebben als we het
zelf niet precies kunnen formuleren? Denkt u dat IT-leveranciers zo
lief zijn om u een concurrerende prijs te vragen voor het beheren van
uw IT-infrastructuur als ze de kans krijgen om echt geld te gaan verdienen?
Laat u echt uw IT-leverancier in uw organisatie uitzoeken wat zij voor
u kunnen gaan doen ("outsourcing onder architectuur")?
Denk u echt dat een IT-leverancier voor u uw primaire bedrijfsproces
transactie verwerking kan overnemen, IT en organisatie eromheen, en
dat het daarmee zeker goedkoper, beter, betrouwbaarder enz. zal worden
("business process outsourcing")? Eén ding
is zeker: zo lang u dat soort opdracht nog op een groot bierviltje kunt
schrijven bent u kandidaat voor de hoofdprijs. Om hem te betalen, trouwens,
niet om hem te krijgen.
Daarom:
organisaties kom zo snel mogelijk echt goed te weten wat je wil met
je informatie. Wordt pro-actief. Ontwikkel en beheer uw kennis van uw
informatie. Het is een allesbepalende voorwaarden om überhaupt
voordeel uit sourcing te kunnen halen, en zeker als het om outsourcing
of zelfs offshoring gaat. Er zijn al vele schrijnende gevallen die niet
naar buiten komen omdat we er ons voor schamen, en er zullen er zeker
nog een groot aantal bijkomen. Voorkom dit soort problemen, als u kunt.