Ontwikkelen van organisatiecompetenties

Dit hoofdstuk biedt een generiek raamwerk voor het ontwikkelen van organisatiecompetenties en kan daarmee ondermeer gebruikt worden voor het ontwikkelen van specifieke competenties die relevant zijn vanuit de i-Strategie en HORA. Het hoofdstuk start met een algemene beschrijving van competentie-ontwikkeling, waarna een vragenlijst wordt gepresenteerd die hierbij gebruikt kan worden. Het hoofdstuk eindigt met een voorbeeld van een specifieke competentie: het kunnen uitbesteden van IT-diensten.

Competentie-ontwikkeling

Om veranderingen door te voeren moeten organisaties bepaalde competenties ontwikkelen. Een competentie is het vermogen om iets te kunnen en daarvoor dienen verschillende zaken aanwezig te zijn. Organisaties zullen ervoor moeten zorgen dat processen zijn ingericht, informatie beschikbaar is, mensen competent zijn en dat noodzakelijke technologie aanwezig is. Voor mensen betekent dit vooral dat zij dienen te beschikken over de juiste kennis, vaardigheden en attitude/gedrag. Persoonlijke competenties zijn dus een randvoorwaarde voor organisatiecompetenties, maar niet voldoende. Competenties zijn in veel gevallen al in enige mate aanwezig in de huidige organisatie. De kans is echter reëel dat veranderingen ook hogere eisen stellen aan het gewenste competentieniveau. Om zicht te krijgen op het niveau waarop een organisatie bepaalde competenties heeft, kunnen vragen worden gesteld. Het gewenste competentie-niveau moet de instelling zelf kiezen en is bepalend voor de vragen die moeten worden gesteld.

Tabel 1 geeft inzicht in algemeen relevante vragen op verschillende competentieniveau’s. De tabel is afgeleid uit gangbare modellen zoals het CMMI van de Carnegie Mellon University, wat een generiek raamwerk voor volwassenheidsmodellen biedt (zie ook [4] voor een uitgebreidere beschrijving). De vaardigheidsniveaus van het CMMI zijn dan ook als uitgangspunt genomen. De tabel probeert een meer concrete lijst van vragen te bieden dan deze volwassenheidsmodellen zodat instellingen eenvoudiger zelf kunnen bepalen waar zij staan en waar zij zich verder moeten ontwikkelen, zonder daarbij afhankelijk te zijn van externe ondersteuning. De tabel laat de verschillende dimensies zien die relevant zijn om een bepaalde competentie te bezitten. Het is dus vooral belangrijk om al deze aspecten in samenhang te borgen. De tabel gaat verder dan veel andere volwassenheidsmodellen (incl. CMMI) die zich primair richten op de procesaspecten. Uitgangspunt is daarnaast dat parallel aan prestatieverbetering van individuele procesgebieden kan worden gewerkt. Dit in tegenstelling tot een stapsgewijze ontwikkeling waarbij er een sterkere koppeling is tussen de niveau’s van bepaalde procesgebieden.

# Processen Mensen Informatie Technologie
0 (incompleet)
1 (uitgevoerd)
  • Wordt het proces uitgevoerd?
  • Zijn er medewerkers beschikbaar voor de uitvoering van het proces?
  • Zijn de gegevens beschikbaar?
  • Zijn voor het proces noodzakelijke applicaties en infrastructuur beschikbaar?
2 (beheerst)
  • Is er een eigenaar voor het proces aangewezen?
  • Zijn de taken en verantwoordelijk- heden voor het proces beschreven?
  • Zijn er doelstellingen geformuleerd voor het proces?
  • Is er een procesbeschrijving?
  • Is er beleid geformuleerd voor de uitvoering van het proces?
  • Wordt de uitvoering van het proces expliciet gemonitord en gestuurd?
  • Wordt er gestuurd op werkprocessen,die over afdelingen heen lopen?
  • Zijn alle voor het proces relevante medewerkers en belanghebbenden geïdentificeerd en betrokken?
  • Zijn er voldoende medewerkers beschikbaar voor de uitvoering van het proces?
  • Zijn er competentieprofielen beschikbaar voor de belangrijkste rollen in het proces?
  • Worden medewerkers opgeleid om te voldoen aan de competenties?
  • Zijn medewerkers gericht op samenwerking tussen organisatie- onderdelen en in multidisciplinaire teams?
  • Zijn er voor organisatie-onderdelen en teams duidelijke doelstellingen gedefinieerd?
  • Is er een gemeenschappelijke visie en aanpak bij de organisatie- onderdelen teams die betrokken zijn in het proces?
  • Gebruiken medewerkers die betrokken zijn bij het proces een gezamenlijk begrippenstelsel?
  • Is er een eigenaar voor de gegevens en de functionaliteiten behorende bij het proces (informatiesysteem) aangewezen?
  • Zijn de taken en verantwoordelijkheden van de informatiesysteemeigenaar beschreven?
  • Is er een authentieke bron voor de gegevens aangewezen?
  • Is er een definitie van de gegevens en de gegevensstructuur?
  • Zijn de kwaliteits- en bedrijfsregels voor de gegevens beschreven?
  • Is er een applicatie beschikbaar die de processen in voldoende mate ondersteunt?
  • Zijn de gewenste serviceniveau’s beschreven?
  • Zijn de interfaces tussen applicaties beschreven?
  • Is er een eigenaar voor de applicatie aangewezen?
3 (gedefinieerd)
  • Heeft de proceseigenaar voldoende mandaat en middelen voor de uitvoering van zijn verantwoordelijkheden?
  • Is de samenhang van dit proces met andere processen gedefinieerd?
  • Wordt het proces uitgevoerd volgens de organisatiebrede procesbeschrijving?
  • Is het proces op een standaard wijze beschreven?
  • Is de relatie tussen het proces en de informatievoorziening beschreven?
  • Wordt de interne procesketen (van klant tot klant) bestuurd?
  • Zijn er standaard organisatiebrede competentieprofielen gedefinieerd?
  • Beschikken medewerkers over alle noodzakelijke competenties?
  • Weten medewerkers en betrokkenen wat er van ze wordt verwacht?
  • Zijn medewerkers en betrokkenen gemotiveerd?
  • Zijn medewerkers gericht op het verbeteren van de samenwerking met andere organisatie-eenheden en teams?
  • Zijn bedrijfsdoelstellingen doorvertaald naar doelstellingen voor organisatie-onderdelen en teams?
  • Heeft iedereen die dat nodig heeft voor zijn taak in het proces toegang tot de functionaliteit en gegevens?
  • Is de kwaliteit van de gegevens voldoende voor het uitvoeren van het proces?
  • Is de samenhang van de gegevens met andere gegevens gedefinieerd?
  • Worden de gegevensdefinities op een standaard wijze beschreven?
  • Gebruiken medewerkers een gezamenlijk begrippenstelsel dat is afgestemd met andere organisatie-onderdelen en teams?
  • Is er een standaard applicatie aangewezen en beschikbaar?
  • Gebruikt iedereen de standaard applicatie?
  • Zijn er actuele functionele en technische ontwerpen beschikbaar van de interfaces met andere applicaties?
  • Heeft de applicatie interfaces met alle andere applicaties die voor het proces relevante gegevens of functionaliteit bevatten?
  • Zijn de gebruikers tevreden over de applicatie?
  • Zijn applicaties, interfaces en infrastructuur op een standaard wijze beschreven?
  • Voldoet de infrastructuur aan de gewenste serviceniveau’s?
4 (kwantitatief beheerst)
  • Zijn er kwantitatieve indicatoren gedefinieerd voor het proces?
  • Wordt ook gemeten of het proces voldoet aan de prestatie- en kwaliteitsindicatoren?
  • Is de proceseigenaar ook verantwoordelijk voor de uitvoering en het resultaat van het proces?
  • Wordt er op het niveau van de interne procesketen gestuurd?
  • Hebben medewerkers persoonlijke kwantitatieve doelstellingen?
  • Wordt ook gemeten of medewerkers voldoen aan de persoonlijke kwantitatieve doelstellingen?
  • Wordt er effectief samengewerkt met andere organisatie-onderdelen en teams?
  • Zijn de procesindicatoren vertaald naar de bijdrage van organisatie- onderdelen en teams?
  • Wordt de kwaliteit van de gegevens continu bewaakt?
  • Gebruiken medewerkers een gezamenlijk begrippenstelsel dat is afgestemd met de omgeving?
  • Heeft de applicatie realtime interfaces voor gegevens waarvan hoge actualiteit wordt verwacht?
  • Wordt de functionele en technische waarde van de applicatie periodiek geëvalueerd?
  • Worden de serviceniveau’s van de infrastructuur gemonitord?
5 (optimaliserend)
  • Worden de resultaten van de metingen gebruikt voor de verbetering van het proces?
  • Wordt er op het niveau van de externe procesketen gestuurd?
  • Worden medewerkers ontwikkeld en gestuurd op basis van de mate waarin zij voldoen aan kwantitatieve doelstellingen?
  • Zijn de organisatie-onderdelen en teams gericht op continue verbetering?
  • Zijn teamprestaties bij te sturen op basis van strategische wijzigingen?
  • Worden kwaliteits- en bedrijfsregels voor gegevens ook bijgesteld op basis van nieuwe inzichten?
  • Dragen medewerkers actief bij aan een gezamenlijk begrippenstelsel dat de organisatie overstijgt?
  • Wordt er pro-actief gestuurd op aanpassing of vervanging van applicaties op basis van periodieke evaluaties?
  • Wordt er pro-actief gestuurd op bijstellen van de infrastructuur zodat deze blijft voldoen aan de serviceniveau’s?

Tabel 1 Competentieniveau’s en relevante vragen

Het is belangrijk om het toepassingsgebied en de beperkingen van de tabel goed te begrijpen. De intentie is vooral om een pragmatische lijst van vragen te bieden die organisaties snel zelf kunnen beantwoorden. De tabel is niet gebaseerd op een uitgebreid onderzoek, maar is een selectie uit een aantal algemene referentiemodellen aangevuld met persoonlijke inzichten. De tabel is daarnaast vooral gericht op de meer “harde” inrichtingsaspecten die vanuit een architectuurperspectief relevant zijn. Naast deze harde aspecten spelen vooral ook allerlei “zachte” aspecten zoals cultuur en belangen. Deze aspecten spelen in veel gevallen een minstens even belangrijke rol, maar zijn lastiger in concrete vragen te vertalen en vragen ook andere competenties om te beoordelen. Uitgangspunt van de tabel is verder dat sturing op resultaten en samenhang leidt tot verbetering.

De competenties die op dit moment relevant zijn voor instellingen kunnen worden afgeleid uit de strategie van de instelling en de ontwikkelingen die daaraan ten grondslag liggen. Daarnaast biedt ook de in dit project ontwikkelde i-Strategie en referentie-architectuur indicaties voor gewenste competenties. Ook de in het project opgestelde lijst van ontwikkelingen kan als inspiratiebron worden gebruikt. De referentie-architectuur biedt een houvast bij het concreet maken van gewenste competenties doordat het een overzicht geeft van alle belangrijke inrichtingselementen (bedrijfsfuncties, bedrijfsprocessen, informatie, applicaties en applicatie-infrastructuur). Organisaties kunnen de modellen in de referentie-architectuur gebruiken als checklist om de relevante inrichtingselementen voor een competentie te vinden. Daarnaast wordt bij de in dit document expliciet benoemde competenties ook al een indicatie gegeven van de relevante inrichtingselementen.

Voor alle gevonden elementen kunnen de vragen in Tabel 1 worden beantwoord die horen bij de gewenste competentieniveau’s. Als alle vragen op een bepaald competentieniveau positief kunnen worden beantwoord dan is een bepaald competentieniveau bereikt. Voor alle vragen die niet positief kunnen worden beantwoord is het belangrijk om duidelijk te maken wat er nog moet gebeuren om deze vraag wel positief te kunnen beantwoorden. Dit leidt tot een lijst van acties die zullen moeten worden uitgevoerd om het competentieniveau alsnog te bereiken. Het is belangrijk dat al deze acties geborgd worden in de juiste plannen. Naast de tabel in dit document kan ook gebruik gemaakt worden van volwassenheidsmodellen voor specifieke procesgebieden als er een meer uitgebreide en onderbouwde meting van het huidige competentieniveau noodzakelijk is. Zo is er bijvoorbeeld voor informatiebeveiliging door SURFaudit een specifiek volwassenheidsmodel ontwikkeld [19]. Er zijn in het algemeen veel volwassenheidsmodellen beschikbaar in de markt die gebruikt kunnen worden. Het gebruik van deze volwassenheidsmodellen vraagt echter wel specifieke kennis en daardoor in veel gevallen ook externe ondersteuning voor het uitvoeren van de analyse. Voor sourcing is er om die reden ook een meer pragmatische en specifieke vragenlijst ontwikkeld die instellingen kunnen gebruiken om snel op specifiek dat gebied inzicht te krijgen in volwassenheid [31].

Alhoewel het mogelijk is om tegelijkertijd aan de ontwikkeling van meerdere competenties te werken is het wel belangrijk om voldoende focus aan te brengen in de verbetering. Als er een groot verschil is tussen het huidige competentieniveau en het gewenste competentie-niveau dan is het verstandig de ontwikkeling in fasen uit te voeren, waarbij in elke fase alleen wordt gewerkt aan elementen op één competentieniveau. Organisaties moeten nu eenmaal door een bepaalde ontwikkeling heen en ontwikkelingsfasen kunnen niet zomaar worden overgeslagen. Dit leidt dan al snel tot een meerjarenplanning waarbij er minimaal een jaar, maar veelal 2 of 3 jaar wordt genomen om één competentieniveau te kunnen stijgen. Het is belangrijk om te beseffen dat veranderingen niet noodzakelijkerwijs vragen om een hoger competentieniveau. Het kan ook voldoende zijn om procesdefinities aan te passen om de nieuwe omstandigheid te faciliteren; een ander proces impliceert niet automatisch ook een hoger competentieniveau.

Samengevat is de aanbevolen aanpak voor de ontwikkeling van organisatiecompetenties:

  1. Vaststellen van de gewenste competenties
    1. Gebaseerd op de strategie van de instelling
    2. Gebaseerd op de i-Strategie zoals opgesteld in het project Regie in de Cloud Gebaseerd op de relevante ontwikkelingen
  2. Bepalen van de relevante processen, informatie en technologie per competentie
    1. Gebaseerd op het bedrijfsfunctiemodel, bedrijfsprocesmodel, informatiemodel, applicatiemodel en applicatieplatformmodel in de referentie-architectuur
  3. Bepalen van het gewenste competentieniveau per competentie
  4. Bepalen van het huidige competentieniveau per competentie
    1. Gebaseerd op de vragen in Tabel 1
    2. Gebaseerd op een specifiek volwassenheidsmodel
  5. Bepalen van de acties die gewenst zijn om het gewenste competentieniveau te bereiken en het borgen ervan in plannen

Voorbeeld competentie: uitbesteden van IT-diensten

In deze paragraaf geven we een voorbeeld van een competentie en hoe de referentie-architectuur gebruikt kan worden om meer zicht te geven op de relevante aspecten van de competentie. Het voorbeeld dat we nemen is het kunnen uitbesteden van IT-diensten, wat goed aansluit bij het project “Regie in de Cloud”. Cloudsourcing kan namelijk gezien worden als een specifieke vorm van outsourcing, waarbij IT-diensten in de cloud worden geplaatst. Het is duidelijk dat hier allerlei zaken voor moeten worden ingeregeld voordat strategisch wordt ingezet op cloudsourcing.

In Figuur 1 is de impact van de competentie op het bedrijfsfunctiemodel in de HORA weergegeven, ondermeer op basis van de SURF sourcing maturity model [31]. De bedrijfsfuncties die worden geraakt en die een voldoende mate van volwassenheid moeten hebben zijn geel gemarkeerd. Op een aantal plaatsen zijn de functies zoals beschreven in het bedrijfsfunctiemodel nog te abstract om scherp genoeg aan te geven waar aandacht gewenst is. In de figuur is om die reden op een aantal bedrijfsfuncties verder ingezoomd. Zo is wat minder de algemene enterprise-architectuurfunctie relevant voor uitbesteding; het gaat vooral om informatie-architectuur. Er is namelijk vooral een goed zicht nodig op de informatievoorziening; competenties rondom businessarchitectuur of infrastructuurarchitectuur zijn een stuk minder relevant.

Ih hoofdstuk4 figuur1.png
Figuur 1 Impact van competentie "uitbesteden van IT-diensten" op bedrijfsfunctiemodel

Figuur 2 geeft de impact van de competentie weer op het informatiemodel. Hieruit wordt duidelijk dat vooral de architectuur en de administratie van applicaties goed op orde dient te zijn (anders weet je als organisatie niet wat je uitbesteedt), dat er een goede administratie van werkactiviteiten nodig is (anders weet je als organisatie niet of het goedkoper is om uit te besteden) en dat er goede inkoopcontracten dienen te zijn (er moeten goede afspraken met leveranciers worden gemaakt).

Ih hoofdstuk4 figuur2.png
Figuur 2 Impact van competentie "uitbesteden van IT-diensten" op informatiemodel