English version


Nederlandse versie

Steven's Weblog (Nederlands)

Iedereen kan informatie van deze weblog overnemen onder de voorwaarde dat hij/zij blijft verwijzen naar deze weblog.

 

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.

 

Uw naam:
Uw E-mail:
Uw reactie: