Derk K. Kremer

Outsourcing versus partnership

Veel ICT leveranciers hebben het over het aangaan van een (strategisch) partnership zonder dat ze zelf weten waar ze het over hebben. Opdrachtgevers weten hier vaak ook geen weg in te vinden. 

In de literatuur zijn we onderstaande tabel tegengekomen. Deze geeft een aardige indruk over het verschil tussen een traditionele outsourcing en een strategisch partnership.

 

 TRADITIONELE OUTSOURCING

 STRATEGISCH PARTNERSHIP

 accent op beheersing IT  accent op innovatie van bedrijfsprocessen
 kosten als primaire insteek toegevoegde waarde als primaire insteek
 taakgericht procesgericht
IT is geen core business IT is core competence
statisch dienstverlenings overeenkomst flexibel contract
meetpunten zijn technische indicatoren meetpunten zijn businessdoelstellingen
uitbesteden is uitgangspunt van strategie sourcing is afweging binnen de strategie
taken competenties

bron: "de transformerende onderneming"

 

Investering-denken versus project-denken

Falende projecten zijn helaas nog steeds aan de orde van de dag. Vele onderzoeken zijn gedaan en veel conclusies worden getrokken. En de aanbevelingen en adviezen worden in groten getale gegeven. Dit proces is al decennialang gaande, maar heeft tot op heden niet geleid tot betere resultaten. Ondanks diverse initiatieven aan, voornamelijk, de de kant van het ict domein. Zie hierover de kritische beschouwingen van Wortmann en Kremer. Zie ook het model "Oorzaak en Gevolg".

Met name het Eindrapport van de Tijdelijke ICT Commissie Elias (15 oktober 2014) heeft ons aan het denken gezet wat betreft het referentiekader die de verschillende onderzoekers hanteren. Dit referentiekader is uitermate belangrijk bij het trekken van de conclusies en het geven van aanbevelingen. Dit is weer eens overduidelijk gebleken bij de Commissie Elias. Om de conclusies en aanbevelingen van de diverse onderzoeken beter te kunnen interpreteren, kan het nuttig zijn om een tweetal referentiekaders te onderscheiden. 

Wij maken dan ook onderscheid tussen de volgende twee referentiekaders:

  • het "investering-denken"
  • het "project-denken"

Een kort toelichting van elk van de referentiekaders. 

Het "investering-denken"

Bij het denken in investeringen gaan we uit van de volgende 3 stadia: initiatie, realisatie en exploitatie. Het zijn de stadia van een levenscyclus van een systeem. Elk van deze stadia kent zijn eigen verantwoordelijkheden en aandachtsgebieden. Onderkend wordt dat de 3 stadia een sterke afhankelijkheid hebben tot elkaar, maar onafhankelijk van elkaar worden uitgevoerd. Voor een succesvol investeringstraject, en dus ook het project, moet elk van deze stadia zorgvuldig worden doorlopen.  Het is een manier van denken die in de bouw en de engineering redelijk veel wordt gehanteerd. In de, relatief jonge bedrijfstak van de ict komt het helaas nog te weinig voor. Voor meer informatie zie het Investerings model.

Het "project-denken"

In tegenstelling tot de theorie van een project, gaat men bij het "project denken" vooral uit van het starten van een project waarbij er amper onderscheid gemaakt wordt in de verschillende stadia van een levenscyclus van een systeem. Alles wordt in het project "gestopt" onder verantwoordelijkheid van één persoon. Ook het ontstaan van een project is minder duidelijk omschreven en kan  zowel vanuit de businsess komen als dat van de interne ict afdeling (de interne opdrachtnemer). Het project wordt gezien als 'wondermiddel' om op een snelle manier een resultaat te bereiken in de vorm van een geautomatiseerd systeem. De borging van het project is minder duidelijk dan bij een investeringstraject het geval is. Veel verantwoordelijkheid wordt neergelegd bij de eigen ict afdeling. Rolvervaging komt bij deze manier van denken veelvuldig voor. 

Het "project-denken" komt bijzonder veel voor in organisaties in zowel de private als de publieke sector.  Het is een tamelijk traditionele manier van denken die geleidelijk aan is ontstaan vanaf het begin van de automatisering enkele decennia geleden. Niet in de laatste plaats wordt dit versterkt door het oneigenlijk gebruik van methodieken voor projectmanagement: te snel en te gemakkelijk worden verantwoordelijkheden naar het project doorgeschoven, ook daar waar het eigenlijk niet kan. Velen zitten min of meer "gevangen" in deze manier van denken. Het is in feite het standaard referentiekader voor iedereen die te maken heeft met ict.

In onze kritische beschouwingen over de rol van opdrachtgever van projecten, gaan wij uit van het referentiekader volgens het "investering-denken". Vanuit dit denken zijn dan ook vooral de verschillende modellen ontstaan die de rol van opdrachtgever binnen een organisatie kunnen verduidelijken. Voor degenen die uitgaan van het "project denken", zullen deze modellen moeilijk te interpreteren zijn. 

 

Vergelijking van de twee referentie kaders

Ter verduideling wordt hieronder een vergelijking gegeven van een aantal aspecten voor de verschillende referentiekaders:

 

ASPECT

"INVESTERING-DENKEN"

"PROJECT-DENKEN"

centrum van het denken het doen van een investering staat centraal en het project is een afgeleide hiervan het project staat centraal en het begrip investering staat op de achtergrond
doel met het resultaat van het project een bijdrage leveren aan de doelstelling van de organisatie het leveren van een resultaat
justificatie van het project gebeurt op een zo objectief mogelijke manier door de werkelijke eigenaar binnen de business wordt vaak gedaan als onderdeel van het project en gebeurt door de opdrachtnemer
opdrachtgever is iemand uit het lijnmanagement van de business is vaak iemand uit de interne ICT afdeling (bijvoorbeeld de CIO of IT manager)
opdrachtnemer de opdrachtnemer is vaak de interne ict afdeling een externe partij wordt gezien als de opdrachtnemer
rolverdeling er is sprake van een heldere rolverdeling met een juiste scheiding van verantwoordelijkheden en bevoegdheden zeer grote kans op rolvervaging, met daardoor veel ruis in de communicatie, onduidelijke beslissingsstructuren en verantwoording
inhoudelijke kennis ict het hebben van inhoudeljke kennis is amper een vereiste of noodzakelijk men verwacht veel inhoudelijke ict kennis bij alle stakeholders binnen de business
probleem of innovatie delegeren van de realisatie van de oplossing van het probleem naar de opdrachtnemer delegeren van het probleem naar de opdrachtnemer
focus de focus ligt vooral op de Return on Investment de focus ligt vooral op de besparing middels een scherpe  inkoop
stadia duidelijke scheiding in verantwoordelijkheid bij initiatie, realisatie en exploitatie de drie stadia lopen in elkaar over waarbij realisatie meeste aandacht
relatie tot externe leverancier wordt gezien als onderaannemer van interne opdrachtnemer, zijnde de ict afdeling wordt gezien als opdrachtnemer
kosten kosten voor rekening business en zelf budgethouder een sponsor wordt aangewezen bij de business, budgethouder is ICT afdeling
baten wordt expliciet gestuurd op toegevoegde waarde door iemand uit de business zelf is weinig of geen aandacht voor doordat projectmanager na het realiseren van het resultaat op het volgende project wordt gezet
initiatie  de initiatie ligt bij de business en is onderdeel van businessplan  initiatie ligt bij de eigen ICT afdeling als onderdeel van een IT-plan
realisatie actieve houding van de keyspelers in de business passieve houding van de keyspelers in de business
exploitatie nadruk op het behalen van de kwalitatieve of kwantitieve baten nadruk op het beheer en onderhoud van de ict systemen

 

Investering binnen de overheid

In de private sector kent men het fenomeen afschrijvingen. Binnen de publieke sector, waar meestal sprake is van een kasstelsel, hanteert men dit begrip niet of nauwelijks. De kosten van een project worden jaarlijks gebudgetteerd. Het is een vorm van financiering van het project die afwijkt van die in de private sector. Toch kan men in dit geval ook spreken van een investering. De kosten zijn op de korte termijn gemaakt en de kwalitatieve of kwantitatieve baten hiervan zullen op de langere termijn zichtbaar zijn. Ook nu gaat het om de bijdrage die geleverd wordt aan de doelstelling van de organisatie. In het borgingsmodel kennen we in dat geval het beleidsniveau, het uitvoerend niveau en het resultaatleverend niveau. Op dit laatste niveau heb je de realisatie van het project. In de twee andere speelt zich de investerings beslissing af. 

Wat betreft de baten blijken er ook veel misverstanden te zijn. Bij baten denken veel mensen aan kwantitatieve baten (bijvoorbeeld geld). Maar uiteraard gaat het in veel gevallen ook om de andere baten: kwalitatieve baten of toegevoegde waarde van een investering. De laatste soort baten kunnen voortkomen uit een wettelijke verplichting of een beleidsmaatregel. Ook in dergelijke gevallen is het de moeite waard de baten te benoemen. Dat maakt de communicatie naar de verschillende stakeholders beter. 

 

Ilities

checks & balances

Hoe gebruikt een opdrachtgever zijn eigen kennis en ervaring om effectief invulling te geven aan zijn rol met een minimum aan tijd en zonder zich in de inhoud te verdiepen? De processtappen zoals genoemd in het regiemodel kunnen hem hierbij helpen. Maar ook een speciaal voor dit doel, door Wortmann en Kremer, ontwikkeld model dat gebaseerd is op het principe van ‘checks & balances’ kan hem hierbij helpen. De achtergrond van het ‘checks & balances‘ model wordt gegeven elders op deze website

In het model van ‘checks & balances’ gebruiken we drie partijen die de gebruikers, de specialisten van de opdrachtnemer en het management vertegenwoordigen. De laatste partij uiteraard in zijn rol van opdrachtgever. Als voorbeeld wordt hier gebruikt de processtap van het opstellen van de businesscase. In de doelstelling van een organisatie wordt in feite vastgelegd wat een organisatie wil. Deze behoefte (of noodzaak) wordt, onder leiding van een eigen projectmanager, door de eigen medewerkers verder uitgewerkt in specifieke eisen en wensen. Op enig moment zal hierbij gebruik gemaakt gaan worden van de kennis en kunde van specialisten. Dit kan zijn de eigen ICT afdeling, maar ook een externe dienstverlener. Op dit niveau vindt in zekere zin een confrontatie plaats tussen het pakket aan eisen en wensen en wat de techniek eventueel kan bieden om dit te realiseren. Het gaat dan primair om de functionele eisen. Door deze confrontatie zal blijken welke mogelijkheden er zijn. Deze worden gedefinieerd als een aantal mogelijke scenario’s of oplossingen. De rol van de opdrachtgever is op deze manier beperkt tot degene die het proces bewaakt en de voorwaarden stelt. Dit laatste heeft dan vooral te maken met de impact die de oplossingen of scenario’s hebben op de organisatie. Het gaat dan om het definiëren en het beoordelen van niet-functionele eisen en criteria (de zogenaamde ’ilities’), maar ook om de omgevingsfactoren die van invloed zijn op de scenario’s. Het gaat bijvoorbeeld om de beschikbaarheid en de doelmatigheid. Maar ook om eisen op het gebied van de schaalbaarheid, de betrouwbaarheid en de haalbaarheid. Uiteraard zijn er nog meer niet-functionele eisen, maar we gaan daar verder niet op in. Hieronder wordt een voorbeeld gegeven van de ‘ilities’ in een ict omgeving.

De uitkomsten van de beoordeling van de niet-functionele eisen en criteria van elk scenario zijn bepalend voor de besluitvorming. De eerdergenoemde omgevingsfactoren maken duidelijk welke eisen er aan een goede regievoering moeten worden gesteld. Belangrijk is te weten wie de spelers zijn die het project positief of negatief kunnen beïnvloeden en welke acties vervolgens nodig blijken. Tussen de mogelijke scenario’s kan vervolgens een afweging worden gemaakt door de belangrijkste stakeholders: dit kan een keuze zijn maar ook een bijstelling van wat een organisatie wil. In het laatste geval begint een volgende ronde. De opdrachtgever heeft in dit proces een centrale rol maar is minimaal betrokken bij de inhoud. Op enig moment zal er voor een scenario worden gekozen. Dit scenario vormt de basis voor de businesscase en daarmee voor de goedkeuring van het project. Maar het gekozen scenario vormt ook de basis voor een goede regievoering door de opdrachtgever richting overige stakeholders. De rol van opdrachtgever is zo beperkt tot degene die het proces bewaakt en de voorwaarden stelt.

Een overzicht van te gebruiken Ilities

accesibility

toegankelijkheid

accountability

aansprakelijkheid

adaptability

mate van de mogelijkheid een oplossing, systeem, dienst, product of omgeving aan te passen

adoptability

mate waarin de omgeving in staat is een product, dienst of oplossing te adopteren of accepteren

auditability

analyseerbaarheid of het vermogen om audits uit te voeren op het systeem, de omgeving, scenario, product of dienst

compatibility

configurability

correctness

juistheid

customizability

dependability

distributability

effectiveness

extensibility

faultdurability

foutbestendigheid

flexibility

integrety

inspectability

installability

installeerbaarheid

learnibility

leerbaarheid

linkability

koppelbaarheid

maintainability

onderhoudbaarheid

manageability

mogelijkheid de oplossing, scenario, product, omgeving of dienst te managen.

modularity

operability

bedrijfszekerheid

performance

mate van snelheid

predictability

recoverability

herstelbaarheid

relevance

reliability

reusability

resourcebility

mate van beslag op de middelen

safety

securability

beveiligbaarheid

simplicity

stability

stabiliteit

suitability

geschiktheid

sustainability

supportability

tailorability

mate van inpasbaarheid

testability

testbaarheid

understandability

begrijpelijkheid

usability

gebruiksgemak van de omgeving, het systeem, scenario, product of dienst

Stuurgroep

Dit deel is in ontwikkeling

 

De taken, verantwoordelijkheden, bevoegdheden en samenstelling van een stuurgroep worden in een zo vroeg mogelijk stadium vastgesteld door de leidinggevenden van de opdrachtgever van een project. Een voorbeeld is hieronder gegeven.

 

Doel

een stuurgroep controleert en ondersteunt de manager die de rol van opdrachtgever vervult binnen een goedgekeurd investeringstraject

Taken

  • toezien op de aanwezigheid van een voldoende groot draagvlak
  • toezien op mandaat opdrachtgever
  • toezien dat voortgang investeringstraject conform afspraken
  • toezien op capaciteitstoedeling conform afspraken
  • toezien op de kwaliteit van de opdrachtgever

Verantwoordelijkheden

  • goedkeuring geven aan volgende stap van een investeringstraject
  • bewaken project bijdrage aan doelstellingen organisatie
  • signaleren afwijkingen project conform de toleranties die vooraf zijn bepaald

Bevoegdheden

  • geeft goedkeuring aan budget- en scopewijzigingen binnen de toleranties van de stuurgroep
  • kan een project (tijdelijk) stilzetten
  • prioriteiten bepalen wat betreft inzetten medewerkers voor project

Samenstelling

  • waarborging van de verschillende rollen in de stuurgroep inclusief de beslisrol;
  • vertegenwoordigers in de stuurgroep die de juiste beslissingsbevoegdheid hebben.

Voorzitter

In principe is de opdrachtgever de voorzitter van de stuurgroep

 

 

verschillen Opdrachtgever - Projectmanager

 OPDRACHTGEVER

 PROJECTMANAGER

eigenaar van de businesscase eigenaar van het projectplan
nadruk meer op leiderschap nadruk meer op managen
levert met het projectresultaat een bijdrage aan bedrijfsdoelstelling(en) gericht op het leveren van een projectresultaat binnen de daarvoor afgesproken budgetten
handelt vanuit ownership handelt in opdracht
primair te maken met stakeholders primair te maken met specialisten
status door positie status door professionaliteit
horizon opdrachtgever is minimaal de duur van het investeringstraject horizon projectmanager is maximaal de duur van de realisatie van het project
voert de regie over stakeholders en interne groeperingen werkt aan teambuilding binnen het project
opdrachtgever zijn is een rol projectmanager zijn is een functie
   

Contact Informatie

+ 31 621 805 668
Groningen
derk.kremer@eestum.eu
 

Nieuwsbrief

wij versturen geen nieuwsbrieven, mailings, e.d. Wil je op de hoogte blijven? Volg ons dan via Twitter of LinkedIn.

Wie is online

We hebben 212 gasten en geen leden online

×

Ondanks dat deze website veel bezocht wordt en blijkbaar in een behoefte voorziet, gaat deze website op 31 december 2018 uit de lucht.. Alle informatie gaat dan verloren. 

Hebt u belangstelling om deze website over te nemen? Neem dan contact op.